Potřebujete VPN pro Apple MDM? Tři potřeby přístupu, jedna odpověď
Apple MDM běží na APNs a HTTPS iniciovaném zařízením, ne na tunelu v LAN. Oddělte správu, sdílení obrazovky a přístup k soukromým aplikacím, než přidáte VPN.
Otázka málokdy zní, zda správa zařízení Apple potřebuje šifrování, protože ho potřebuje. Skutečná otázka je, zda vaše flotila potřebuje univerzální VPN dřív, než lze Mac nebo iPad vůbec spravovat, a u většiny nasazení spravovaných přes internet je odpověď ne. Apple umožňuje zařízení dosáhnout služby správy podle vlastního rozvrhu a provoz, na kterém záleží, je podepsaný kanál příkazů, nikoli relace plochy. Zda to u vás bude fungovat, závisí na třech podmínkách a je snadné si je splést, protože zvenčí všechny vypadají jako vzdálený přístup.
Pojmenujte potřebu, než zvolíte přenos
Příkazy správy a konfigurační profily jsou jedna potřeba, interaktivní sdílení obrazovky druhá a dosažení soukromé interní aplikace třetí. Mají různé vlastníky, různé ověřování a často velmi různou přijatelnou expozici. Jejich slévání dohromady je způsob, jak flotila skončí s veřejným seznamem portů, který nikdo nedokáže obhájit.
Ty tři potřeby nesdílejí jeden přenos:
| Need | What actually carries it |
|---|---|
| Management commands and profiles | The enrolled device pulls from a service it can reach; APNs only wakes it |
| Interactive screen sharing | A remote-support tool or private desktop path with its own authentication |
| Private application access | That application's permitted network path, which may well be a VPN |
Zmatek obvykle začíná starým kontrolním seznamem serveru. Historický dokument pro OS X Server uvádí dlouhou sadu portů a někdo je všechny přesměruje na okraji, protože služba správy je někde tam. To není architektura správy a rozšiřuje vystavenou plochu daleko za řídicí rovinu, kterou jste se snažili publikovat.
Co push oznámení skutečně dělá
V dokumentovaném toku Apple posílá server správy oznámení APNs, aby zařízení řekl, že na něj čeká práce. Zařízení pak otevře spojení se serverem správy a vyžádá si své příkazy. Push je zvonek u dveří, ne tunel: nenese žádný libovolný obsah, žádnou relaci vzdálené plochy ani provoz jiné aplikace.
Zařízení tedy musí být zapsáno v zamýšlené službě, důvěřovat očekávaným koncovým bodům a být schopno dosáhnout jak služby správy, tak služeb Apple, na kterých tok závisí. Pokyny Apple k přípravě sítě tyto závislosti uvádějí a nejsou vyjednatelnými částmi toku. Server správy, který existuje jen uvnitř vaší sítě, stále potřebuje podporovanou cestu, kterou zařízení skutečně může použít. Nazvat to MDM neudělá z nedostupného koncového bodu dostupný.
Udržujte povolené cesty explicitní, včetně jakékoli politiky proxy a kontroly TLS uprostřed. Kontrolní zařízení, které rozbije očekávaný řetězec certifikátů, bude vypadat přesně jako rozbitá registrace.
Když je VPN špatná odpověď
Pokud je vaše služba správy publikována na internetu s řádným certifikátem a každé spojení iniciuje zařízení, VPN přidá skok, aniž by přidala kontrolu. Zařízení se již ověřuje svou identitou registrace a server již rozhoduje, které příkazy přijme. Tunel před tím mění síťovou cestu, ne rozhodnutí o důvěře.
Stejná řídicí rovina může doručit i samotný profil VPN. Na tom pořadí záleží: spravovaná konfigurace VPN přichází jako další obsah, takže zařízení nepotřebuje existující tunel, aby mohlo přijmout profil, který ho vytváří.
Když je VPN správná odpověď
Existují flotily, kde by koncový bod správy nikdy neměl být dostupný z internetu, a to je legitimní návrh, ne nedostatek odvahy. Regulovaná prostředí, malé interní IT týmy a servery, které hostují i další administrativní rozhraní, tam často skončí. V takovém případě je chráněná přístupová cesta před službou správy záměrnou architekturou, ne obchvatem.
Sdílení obrazovky a přístup k soukromým aplikacím obvykle patří také na tuto stranu linie. Obě odhalují mnohem více než kanál příkazů a obě si zaslouží vlastní ověřování místo toho, aby jely na identitě registrace.
Past při prvním spuštění, která láme obnovu
Tady je porucha, proti které bych navrhoval: jediná cesta ke službě správy vede přes VPN a profil nebo pověření VPN v zařízení vypršelo. Zařízení nemůže dosáhnout serveru, aby si vyzvedlo náhradní příkaz, a server nemůže protlačit nic tunelem, který nenaběhne. Obnova teď závisí na uživateli, který může být stovky kilometrů daleko.
Udržujte druhou, nezávislou cestu pro obnovu, ať je to mimopásmový kanál správy, místní správce nebo služba správy, která zůstává dostupná bez tunelu. Otestujte ji, dokud všechno funguje, protože během incidentu čistý test nedostanete.
Pak si zapište, které ze tří potřeb každá cesta slouží, a odstraňte přesměrování portů, která neslouží žádné z nich. Flotila, kterou lze spravovat bez univerzálního tunelu a kterou lze stále opravit, když se rozbije právě tunel, je výsledek, kvůli kterému stojí za to navrhovat.