Aveți nevoie de un VPN pentru Apple MDM? Trei nevoi de acces, un răspuns
Apple MDM rulează pe APNs și pe HTTPS inițiat de dispozitiv, nu pe un tunel LAN. Separați administrarea, partajarea ecranului și accesul la aplicații private înainte de a adăuga un VPN.
Întrebarea este rareori dacă administrarea dispozitivelor Apple are nevoie de criptare, pentru că are. Adevărata întrebare este dacă flota dumneavoastră are nevoie de un VPN general înainte ca un Mac sau un iPad să poată fi administrat, iar pentru majoritatea implementărilor administrate prin internet răspunsul este nu. Apple permite dispozitivului să ajungă la un serviciu de administrare după propriul program, iar traficul care contează este un canal de comenzi semnat, nu o sesiune de desktop. Dacă asta funcționează pentru dumneavoastră depinde de trei condiții, și este ușor să le confundați pentru că din exterior toate par acces de la distanță.
Numiți nevoia înainte de a alege un transport
Comenzile de administrare și profilurile de configurare sunt o nevoie, partajarea interactivă a ecranului este a doua, iar accesul la o aplicație internă privată este a treia. Au proprietari diferiți, autentificare diferită și adesea o expunere acceptabilă foarte diferită. Să le pui pe toate grămadă este felul în care o flotă ajunge cu o listă publică de porturi pe care nimeni nu o poate apăra.
Cele trei nevoi nu împart un singur transport:
| 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 |
Confuzia începe de obicei cu o listă de verificare veche a serverului. Un document istoric despre OS X Server enumeră un set lung de porturi, iar cineva le redirecționează pe toate la margine pentru că serviciul de administrare este undeva acolo înăuntru. Aceasta nu este o arhitectură de administrare și lărgește suprafața expusă mult dincolo de planul de control pe care încercați să îl publicați.
Ce face de fapt notificarea push
În fluxul documentat de Apple, serverul de administrare trimite o notificare APNs pentru a spune dispozitivului că îl așteaptă lucru. Dispozitivul deschide apoi o conexiune către serverul de administrare și își cere comenzile. Push-ul este un clopoțel de ușă, nu un tunel: nu transportă nicio încărcătură arbitrară, nicio sesiune de desktop la distanță și nici traficul altei aplicații.
Deci dispozitivul trebuie să fie înregistrat la serviciul dorit, să aibă încredere în punctele finale așteptate și să poată ajunge atât la serviciul de administrare, cât și la serviciile Apple de care depinde fluxul. Ghidul Apple pentru pregătirea rețelei enumeră aceste dependențe, și ele nu sunt părți negociabile ale fluxului. Un server de administrare care există doar în rețeaua dumneavoastră are în continuare nevoie de o cale acceptată pe care dispozitivul o poate folosi cu adevărat. Să îl numești MDM nu face un punct final inaccesibil accesibil.
Păstrați căile permise explicite, inclusiv orice politică de proxy și de inspecție TLS la mijloc. Un echipament de inspecție care rupe lanțul de certificate așteptat va arăta exact ca o înregistrare ruptă.
Când VPN-ul este răspunsul greșit
Dacă serviciul de administrare este publicat pe internet cu un certificat corect și dispozitivul inițiază fiecare conexiune, un VPN adaugă un salt fără a adăuga un control. Dispozitivul se autentifică deja cu identitatea sa de înregistrare, iar serverul decide deja ce comenzi va accepta. Un tunel în fața acestui lucru schimbă calea de rețea, nu decizia de încredere.
Același plan de control poate livra și profilul VPN propriu-zis. Această ordine contează: o configurație VPN administrată ajunge ca doar o altă încărcătură, așa că dispozitivul nu are nevoie ca tunelul să existe înainte de a primi profilul care îl creează.
Când VPN-ul este răspunsul corect
Există flote în care punctul final de administrare nu ar trebui să fie niciodată accesibil din internet, iar acesta este un design legitim, nu o lipsă de curaj. Mediile reglementate, echipele IT interne mici și serverele care găzduiesc și alte interfețe administrative ajung adesea acolo. În acest caz, o cale de acces protejată în fața serviciului de administrare este arhitectură deliberată, nu un ocol.
Partajarea ecranului și accesul la aplicații private aparțin de obicei tot acelei părți a liniei. Ambele expun mult mai mult decât un canal de comenzi, iar ambele merită propria autentificare în loc să se sprijine pe identitatea de înregistrare.
Capcana de pornire care rupe recuperarea
Iată defecțiunea împotriva căreia aș proiecta: singura cale către serviciul de administrare trece printr-un VPN, iar profilul sau acreditarea VPN de pe dispozitiv a expirat. Dispozitivul nu poate ajunge la server pentru a lua o comandă de înlocuire, iar serverul nu poate împinge nimic printr-un tunel care nu va porni. Recuperarea depinde acum de un utilizator care poate fi la sute de kilometri.
Păstrați o a doua cale independentă pentru recuperare, fie că este un canal de administrare în afara benzii, un administrator local sau un serviciu de administrare care rămâne accesibil fără tunel. Testați-o cât timp totul funcționează, pentru că în timpul unui incident nu veți avea un test curat.
Apoi notați care dintre cele trei nevoi este servită de fiecare cale și eliminați redirecționările de porturi care nu servesc niciuna. O flotă care poate fi administrată fără un tunel general și care poate fi încă reparată atunci când tunelul este cel care s-a stricat este rezultatul pentru care merită să proiectezi.