Pátý Apple Admin Day jsme tentokrát postavili kolem tří témat, která dnes do správy firemních Maců zasahují čím dál víc: automatizace, digitální suverenita a governance.
Během dne jsme se dostali od správy zařízení a telemetrie přes macOS compliance až k reálné zkušenosti s nasazením Maců pro vývojáře v bankovním prostředí. A protože se svět enterprise IT rychle mění, v závěru došlo i na AI governance a lokální AI běžící přímo na Apple Silicon.
Nebudeme tady přepisovat několik hodin přednášek a diskusí. Vybrali jsme témata, která podle nás nejlépe ukazují, kam se dnes správa Apple zařízení ve firmách posouvá a co může být zajímavé i pro ty, kteří tentokrát na Apple Admin Day nedorazili.
Celým programem provázel obchodní ředitel System4u Ondřej Kubeček
Kdo na #5 Apple Admin Day vystoupil
Pozvání tentokrát přijali dva zahraniční hosté a součástí programu byla také případová studie z reálného enterprise prostředí.
Spencer Pitts, Partner CTO ve společnosti Omnissa, se věnoval tomu, jak se mění klasický endpoint management a proč už nestačí zařízení jen spravovat pomocí jednotlivých příkazů. Mluvil o Autonomous Workspace, telemetrii, automatizaci a o tom, jak udržet zařízení dlouhodobě v požadovaném stavu.
Henry Stamerjohann, Solution Consultant ve Fleet Device Management a aktivní člen Mac Admin open source komunity, přivezl téma macOS Security Compliance Projectu (mSCP). Ukázal, jak pracovat s bezpečnostními baseline, CIS benchmarky a compliance tak, aby z nich nevznikl jen další checklist pro audit.
Tomáš Jesenský z ČSOB Slovensko se podělil o zkušenosti se zaváděním Maců do prostředí banky. Macy tam používají především vývojáři a právě jejich požadavky dobře ukázaly, kde se může potkat bezpečnost velké organizace s potřebou lidí pracovat rychle a bez zbytečných překážek.
Závěrečný workshop připravili Ladislav Blažek, technický ředitel System4u, a Martin Tvrdý, vedoucí UEM týmu System4u. Tématem byla Apple Intelligence, AI governance a také lokální AI. Nezůstalo jen u slidů – k dispozici byl i cluster ze dvou Mac Studio a několik MacBooků, na kterých si bylo možné lokální modely vyzkoušet.
Spencer Pitts: zařízení má vědět, v jakém stavu má být
Spencerova přednáška začala u poměrně známého problému.
Klasická správa zařízení je do velké míry založená na příkazech. Administrátor nastaví konfiguraci, pošle ji na zařízení a následně kontroluje, jestli se opravdu aplikovala. Když se stav později změní, musí na to přijít další reakce.
U několika zařízení to není zásadní problém. U tisíců endpointů už ano.
Omnissa proto svou vizi Autonomous Workspace staví na trochu jiném principu. IT definuje, jak má zařízení vypadat, a platforma se ho snaží v tomto stavu udržet. Pokud se něco změní, telemetrie změnu zachytí a automatizace může zařízení vrátit tam, kde má být.
Spencer pro tento přístup používal pojem desired state management.
Apple jde podobným směrem prostřednictvím Declarative Device Managementu (DDM). Zařízení dostane informaci o požadovaném stavu a část práce, kterou dříve musel neustále řídit MDM server, se přesouvá přímo na něj.
Pro správce Apple zařízení je to poměrně zásadní změna. Ne proto, že by ze dne na den zmizely klasické MDM příkazy, ale protože se mění samotný způsob uvažování o správě.
Neřeším každou jednotlivou akci. Řeším výsledek, kterého chci dosáhnout.
Telemetrie není jen pro helpdesk
Aby něco takového fungovalo, potřebuje IT vědět, co se na zařízení opravdu děje.
Spencer proto hodně času věnoval telemetrii a Digital Employee Experience. Nejen tomu, jestli je zařízení přihlášené do UEM nebo má správnou verzi macOS, ale i tomu, jak se na něm uživateli reálně pracuje.
Může jít o stav baterie, problémy konkrétní aplikace, výkon nebo opakující se technické potíže.
Tohle je zajímavé například při obměně hardwaru.
Ve firmách se často pracuje s jednoduchým pravidlem: notebook je určitý počet let starý, takže se vymění. Jenže starší Mac může pořád bez problémů zvládat svou práci, zatímco novější zařízení může uživatele každý den brzdit kvůli konkrétnímu problému.
Pokud má IT kvalitní data, nemusí rozhodovat jen podle data nákupu.
A stejná telemetrie může posloužit bezpečnosti. Změní se stav zařízení, přestane splňovat podmínku a na událost může automaticky navázat další krok.
Tady se klasické UEM postupně propojuje s bezpečností a principy Zero Trust.
Henry Stamerjohann: compliance by neměla žít ve čtyřech různých souborech
Dopolední část pokračovala macOS Security Compliance Projectem.
Pokud někdo spravuje Macy ve větší organizaci, následující situaci asi zná. Bezpečnostní politika říká jednu věc, MDM obsahuje konkrétní konfiguraci, auditní dokumentace popisuje totéž ještě jednou a k tomu existuje několik skriptů, kterými se stav kontroluje.
Dokud je všechno aktuální, funguje to.
Jenže pak někdo změní jednu hodnotu v MDM. Dokument zůstane starý. Skript také. Po pár podobných změnách už není úplně jasné, která verze vlastně platí.
Jednou z velkých výhod mSCP je možnost držet pravidla na jednom místě a z nich následně vytvářet další artefakty – například konfigurační profily, deklarativní konfigurace, compliance skripty nebo podklady pro audit.
Henry to ukázal na obyčejném nastavení zamykání obrazovky.
Pokud se firma rozhodne, že místo původní hodnoty použije jinou, změna se může propsat do profilu, kterým se nastavení vynucuje, do skriptu, který jej kontroluje, i do dokumentace pro auditora.
Nemusí se třikrát ručně přepisovat stejná věc.
Pokud se navíc pravidla verzují v Gitu, zůstává po změně historie. Za několik měsíců lze dohledat, proč byla konkrétní hodnota zvolená, kdo změnu provedl a kdo ji schválil.
Má firma prostě převzít CIS benchmark a nasadit ho beze změny?
Nemá.
A to byla jedna z věcí, které Henry během přednášky zdůrazňoval nejvíc.
Bezpečnostní baseline a benchmark nejsou totéž. Baseline říká, co by mělo být řízené. Benchmark už obvykle přidává konkrétní hodnoty, které někdo na základě určitého rizikového profilu vybral.
Jenže rizikový profil každé organizace je jiný.
CIS benchmark může například doporučovat určitou dobu, po které se má zamknout obrazovka. To ale ještě neznamená, že stejná hodnota bude automaticky správná pro každý typ uživatele a každé prostředí.
Firma si musí vyhodnotit vlastní rizika a pravidla upravit.
Nejde o hledání výmluvy, proč bezpečnostní doporučení nedodržet. Jde o to vědět, proč máme nastavení právě takové, jaké ho máme.
A být schopný své rozhodnutí později doložit.
mSCP samo o sobě zařízení nespravuje
V debatě kolem compliance bylo důležité ještě jedno rozlišení.
macOS Security Compliance Project není náhrada MDM nebo UEM platformy.
mSCP připraví pravidla a příslušné artefakty. Ty je ale stále potřeba na zařízení dostat, kontrolovat jejich stav a případně řešit nápravu.
K tomu dál slouží nástroje jako Jamf, Workspace ONE, Fleet a další systémy pro správu Apple zařízení.
Podobně compliance nenahrazuje EDR nebo vulnerability management. Každý z těchto nástrojů odpovídá na jinou otázku. Smysl dostávají ve chvíli, kdy spolupracují.
DDM a suverenita: dvě témata, která se vracela i v diskusi
Po dopoledních přednáškách následovala panelová diskuse Spencera Pittse, Henryho Stamerjohanna a Ladislava Blažka.
Declarative Device Management se během ní vracel opakovaně.
Apple do DDM postupně přesouvá další části správy. Pro administrátory to neznamená, že mají okamžitě zahodit všechny klasické konfigurační profily. Ve firemním prostředí budou oba přístupy ještě nějakou dobu existovat vedle sebe.
Dává ale smysl začít s DDM pracovat už dnes a nespoléhat na to, že jeho řešení přijde až někdy v budoucnu.
Druhé větší téma bylo digitální suverenita.
Z diskuse dobře vyplynulo, že suverenita není jednoduchá volba mezi cloudem a vlastním serverem. Pro každou organizaci může znamenat něco jiného.
Jedna potřebuje mít jistotu, že její data neopustí určitou zemi. Jiná řeší, kde běží samotná služba. Další chce mít pod kontrolou šifrovací klíče nebo možnost přejít k jinému poskytovateli.
Nejdřív je tedy potřeba určit, nad čím přesně chce firma kontrolu mít. Teprve potom se dá rozumně rozhodovat o technologii.
Tomáš Jesenský: jak dostat Macy k vývojářům v bance
Po obědě přišel na řadu příběh ČSOB Slovensko.
A byl zajímavý hlavně tím, že nešlo o ideální laboratorní prostředí. Tomáš Jesenský otevřeně popisoval, co bylo při zavádění Maců složité a proč celý projekt vůbec vznikl.
Vývojáři mají v enterprise prostředí trochu specifické postavení.
Potřebují nástroje, které běžný uživatel nepotřebuje. Chtějí jejich nové verze rychle a často pracují s technologiemi, které nejsou v běžném firemním katalogu.
Tradiční packaging proces přitom může trvat týdny.
To je pro člověka, který nový nástroj potřebuje dnes, jednoduše příliš dlouho.
Jedním z dřívějších řešení proto bylo dát vývojářům administrátorská práva. Tím se problém s instalacemi vyřeší, ale vytvoří se problém jiný – tentokrát bezpečnostní.
ČSOB navíc původně fungovalo převážně jako Windows prostředí a vývojářská stanice byla kvůli bezpečnosti oddělená od části produkčních firemních služeb.
V praxi to znamenalo další zařízení, virtuální desktop nebo přepínání mezi prostředími.
Macy měly pomoci tenhle model změnit.
Bez admin práv, ale také bez čekání na každou aplikaci
Při návrhu nového prostředí se řešilo několik platforem včetně Microsoft Intune, Workspace ONE a Jamfu.
Výběr ale nebyl jen porovnáním funkcí jednotlivých produktů.
Bylo potřeba řešit také identity, skupiny v Microsoft Entra ID, přístup k firemním službám, instalaci aplikací, bezpečnostní monitoring a to, jak bude celé prostředí zapadat do stávající architektury banky.
Výsledné řešení vzniklo kolem Jamfu a dalších navazujících nástrojů.
Uživatelé mohou získávat schválené aplikace standardní cestou, využívá se také Homebrew. Pokud vývojář potřebuje provést operaci s vyššími oprávněními, nemusí kvůli tomu mít permanentní lokální admin účet.
Oprávnění lze zvýšit na omezenou dobu a akce zůstává dohledatelná.
To je podstatný rozdíl.
Když má uživatel administrátorská práva pořád, má je v případě kompromitace k dispozici také útočník. U dočasné a kontrolované elevace je prostor pro zneužití menší.
Zároveň se ale vývojář nemusí kvůli každé nestandardní operaci obracet na podporu.
Když se do bezpečnosti započítá i čas uživatele
Tomáš během prezentace ukázal také konkrétní zkušenost s výkonem při vývoji.
V jednom z jejich scénářů trval build v původním prostředí desítky minut. Na Macu se stejný proces dostal přibližně ke třem minutám.
Není to univerzální srovnání Windows a macOS a ani tak nebylo prezentované.
Zajímavý je ale pohled na celkové náklady.
Při nákupu pracovního zařízení se dobře počítá cena hardwaru a licencí. Hůř už se do tabulky dostává čas člověka, který několikrát denně čeká, než počítač dokončí jeho práci.
U vývojářů může právě tenhle rozdíl hrát poměrně velkou roli.
ČSOB tak nepoužilo Mac jen jako jiný typ notebooku. Šlo o změnu celého pracovního modelu – od instalace aplikací přes oprávnění až po přístup k firemním službám.
AI governance: nejdřív zjistit, co lidé používají
Poslední část dne patřila AI.
Martin Tvrdý a Ladislav Blažek začali u Apple Intelligence a možností, které administrátorům přináší Declarative Device Management. Z pohledu firem je zajímavá hlavně možnost řídit některé AI funkce poměrně detailně, místo jednoduchého přístupu „všechno povolit“ nebo „všechno zakázat“.
Diskuse se ale rychle dostala ještě dál.
ChatGPT v prohlížeči je dnes jen malá část celého problému. Zaměstnanci mohou používat desktopové aplikace, AI asistenty přímo ve vývojových nástrojích, různé coding agenty nebo lokální modely.
A firma nemusí vůbec vědět, že je používají.
Je tedy nejbezpečnější AI ve firmě prostě zakázat?
Ve většině případů ne.
Podobnou situaci už IT zažilo při nástupu cloudových služeb. Když zaměstnanci nedostali nástroj, který potřebovali, začali používat vlastní Dropbox, vlastní cloudová úložiště a další služby mimo kontrolu firmy.
Vzniklo shadow IT.
U AI může být situace velmi podobná.
Pokud firma pouze zakáže přístup k vybranému nástroji, neznamená to, že lidé AI přestanou používat. Mohou si jednoduše najít jinou cestu.
AI governance proto začíná viditelností.
Jaké nástroje lidé používají? Na kterých zařízeních? Kam z nich odcházejí data? A existuje bezpečná alternativa, kterou jim firma může nabídnout?
Během workshopu jsme si ukázali, jak k získávání takového přehledu přistupují Fleet, Omnissa i Jamf.
Teprve když IT ví, co se v prostředí děje, může začít rozumně nastavovat pravidla.
Co zvládne lokální AI na Macu
Poslední část byla výrazně praktičtější.
Na místě jsme měli připravené MacBooky s lokálními modely a také dvě Mac Studio, každé se 128 GB unified memory. Stroje byly propojené přes Thunderbolt 5 a pomocí technologie Exo Labs bylo možné jejich prostředky spojit.
Důvod je jednoduchý: větší AI model potřebuje více paměti, než kolik jí může nabídnout jeden stroj.
V clusteru už bylo možné spustit model, který by se na samostatné Mac Studio nevešel.
Nešlo o pokus dokázat, že několik Maců nahradí datacentrum s GPU servery. Zajímavé bylo něco jiného – jak daleko se za poměrně krátkou dobu posunulo to, co je možné provozovat lokálně.
Menší model může dnes běžet přímo na MacBooku. Větší na Mac Studio. A pokud nestačí jeden stroj, některé workloady lze rozdělit mezi více zařízení.
Pro firmu to otevírá zajímavou možnost hlavně tam, kde nechce určitá data posílat do veřejné AI služby.
Cloud bude dál dávat smysl pro řadu scénářů. Lokální AI ale přidává další variantu, se kterou se ještě před pár lety v běžném enterprise prostředí příliš nepočítalo.
Od MDM až k AI: správa Maců se rozšiřuje
Když jsme Apple Admin Day začínali pořádat, byla velká část diskusí přirozeně kolem MDM – jak zařízení zaregistrovat, nakonfigurovat, zabezpečit a dostat na ně aplikace.
Tohle všechno samozřejmě zůstává.
Jen se kolem toho objevila spousta dalších vrstev.
Správce dnes potřebuje vědět, jestli zařízení odpovídá požadovanému stavu, jakou má uživatel zkušenost, jestli bezpečnostní konfigurace skutečně sedí s firemní politikou a co se stane, když se zařízení od tohoto stavu odchýlí.
Do toho přichází AI a s ní další typ aplikací, datových toků a oprávnění.
Pátý Apple Admin Day proto nebyl jen o nových funkcích macOS nebo konkrétních MDM platformách. Mnohem víc se řešilo, jak celé prostředí poskládat tak, aby se dalo dlouhodobě řídit.
Automatizace má odstranit zbytečnou ruční práci. Compliance má být dohledatelná a obhajitelná. Uživatelé mají dostat nástroje, které potřebují, aniž by kvůli tomu IT ztratilo kontrolu.
Ať už jde o firemní Mac, bezpečnostní baseline nebo AI nástroj, nakonec se pořád vracíme ke stejné věci: potřebujeme vědět, co se v prostředí děje, a být schopni na změnu rozumně reagovat.
Potřebujete vyřešit správu Apple zařízení ve firmě?
V System4u pomáháme firmám s návrhem, nasazením i dalším rozvojem prostředí pro Apple zařízení. Neřešíme přitom jen samotné Apple MDM, ale i návaznost na firemní identity, aplikace, bezpečnostní pravidla a stávající infrastrukturu.
Každé prostředí je trochu jiné. Jinak se budou spravovat Macy pro běžné kancelářské uživatele, jinak zařízení vývojářů a jinak platforma ve společnosti s přísnými regulatorními požadavky.
Technologie proto vybíráme až podle toho, co firma a její uživatelé skutečně potřebují.
