Kell VPN az Apple MDM-hez? Három hozzáférési igény, egy válasz
Az Apple MDM APNs-en és az eszköz által indított HTTPS-en fut, nem LAN-alagúton. Válassza szét a felügyeletet, a képernyőmegosztást és a privát alkalmazások elérését, mielőtt VPN-t ad hozzá.
A kérdés ritkán az, hogy az Apple-eszközök felügyeletének kell-e titkosítás, mert kell. A valódi kérdés az, hogy a flottájának kell-e általános célú VPN, mielőtt egy Mac vagy iPad egyáltalán felügyelhető lenne, és a legtöbb interneten keresztül felügyelt telepítésnél a válasz nem. Az Apple engedi, hogy az eszköz a saját ütemezése szerint érje el a felügyeleti szolgáltatást, és a fontos forgalom egy aláírt parancscsatorna, nem asztali munkamenet. Hogy ez önnél működik-e, három feltételen múlik, és könnyű összekeverni őket, mert kívülről mindegyik távoli hozzáférésnek tűnik.
Nevezze meg az igényt, mielőtt szállítást választ
A felügyeleti parancsok és a konfigurációs profilok egy igény, az interaktív képernyőmegosztás a második, és egy privát belső alkalmazás elérése a harmadik. Különböző tulajdonosaik, különböző hitelesítésük és gyakran nagyon különböző elfogadható kitettségük van. Ezek egy kalap alá vétele az az út, ahogy egy flotta olyan nyilvános portlistához jut, amelyet senki sem tud megvédeni.
A három igény nem osztozik egyetlen szállításon:
| 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 |
A zavar általában egy régi kiszolgáló-ellenőrzőlistával kezdődik. Egy történelmi OS X Server dokumentum hosszú portkészletet sorol fel, és valaki mindet továbbítja a peremen, mert a felügyeleti szolgáltatás valahol ott van benne. Ez nem felügyeleti architektúra, és a kitett felületet messze a közzétenni kívánt vezérlősík fölé tágítja.
Mit tesz valójában a push értesítés
Az Apple dokumentált folyamatában a felügyeleti kiszolgáló APNs-értesítést küld, hogy jelezze az eszköznek, munkát vár rá. Ezután az eszköz kapcsolatot nyit a felügyeleti kiszolgálóval, és kéri a parancsait. A push egy ajtócsengő, nem alagút: nem szállít tetszőleges adattartalmat, távoli asztali munkamenetet és más alkalmazás forgalmát sem.
Az eszköznek tehát regisztrálva kell lennie a szándékolt szolgáltatásnál, meg kell bíznia a várt végpontokban, és el kell érnie mind a felügyeleti szolgáltatást, mind azokat az Apple-szolgáltatásokat, amelyektől a folyamat függ. Az Apple hálózatelőkészítési útmutatója felsorolja ezeket a függőségeket, és ezek nem megtárgyalható részei a folyamatnak. Egy csak a hálózatán belül létező felügyeleti kiszolgálóhoz is támogatott útvonal kell, amelyet az eszköz valóban használhat. MDM-nek nevezni nem tesz elérhetővé egy elérhetetlen végpontot.
Tartsa kifejezetten az engedélyezett útvonalakat, beleértve a középen ülő proxy- és TLS-ellenőrzési szabályzatot. Egy olyan ellenőrző berendezés, amely megtöri a várt tanúsítványláncot, pontosan úgy fog kinézni, mint egy törött regisztráció.
Amikor a VPN a rossz válasz
Ha a felügyeleti szolgáltatása megfelelő tanúsítvánnyal elérhető az interneten, és minden kapcsolatot az eszköz indít, a VPN egy ugrást ad hozzá vezérlés nélkül. Az eszköz már a regisztrációs identitásával hitelesít, és a kiszolgáló már eldönti, mely parancsokat fogad el. Egy alagút előtte a hálózati útvonalat változtatja meg, nem a bizalmi döntést.
Ugyanaz a vezérlősík magát a VPN-profilt is szállíthatja. Ez a sorrend számít: a felügyelt VPN-konfiguráció csupán újabb adattartalomként érkezik, így az eszköznek nincs szüksége arra, hogy az alagút létezzen, mielőtt megkapja az őt létrehozó profilt.
Amikor a VPN a helyes válasz
Vannak flották, ahol a felügyeleti végpontnak soha nem szabadna internetről elérhetőnek lennie, és ez legitim tervezés, nem bátorsághiány. A szabályozott környezetek, a kis belső IT-csapatok és a más adminisztratív felületeket is futtató kiszolgálók gyakran ott kötnek ki. Ebben az esetben a felügyeleti szolgáltatás előtti védett hozzáférési útvonal szándékos architektúra, nem kerülőmegoldás.
A képernyőmegosztás és a privát alkalmazások elérése általában szintén ehhez az oldalhoz tartozik. Mindkettő sokkal többet tár fel egy parancscsatornánál, és mindkettő saját hitelesítést érdemel ahelyett, hogy a regisztrációs identitáson lovagolna.
Az indítási csapda, amely megtöri a helyreállítást
Íme a hiba, amely ellen terveznék: a felügyeleti szolgáltatáshoz vezető egyetlen útvonal VPN-en keresztül megy, és az eszközön lévő VPN-profil vagy hitelesítő adat lejárt. Az eszköz nem érheti el a kiszolgálót, hogy pótló parancsot szerezzen, és a kiszolgáló nem tud semmit átnyomni egy olyan alagúton, amely nem jön fel. A helyreállítás most egy olyan felhasználótól függ, aki lehet, hogy több száz mérföldre van.
Tartson fenn egy második, független útvonalat a helyreállításhoz, akár sávon kívüli felügyeleti csatorna, akár helyi rendszergazda, akár olyan felügyeleti szolgáltatás, amely alagút nélkül is elérhető marad. Tesztelje, amíg minden működik, mert incidens közben nem kap tiszta tesztet.
Aztán írja le, hogy az egyes útvonalak a három igény közül melyiket szolgálják, és távolítsa el azokat a porttovábbításokat, amelyek egyiket sem szolgálják. Az a flotta, amely általános alagút nélkül felügyelhető, és akkor is javítható, amikor éppen az alagút tört el, az az eredmény, amelyért érdemes tervezni.