Necessiteu una VPN per a Apple MDM? Tres necessitats d'accés, una resposta
Apple MDM funciona amb APNs i HTTPS iniciat pel dispositiu, no amb un túnel de LAN. Separeu la gestió, la compartició de pantalla i l'accés a aplicacions privades abans d'afegir una VPN.
La pregunta poques vegades és si la gestió de dispositius Apple necessita xifratge, perquè sí que en necessita. La pregunta real és si el vostre parc necessita una VPN d'ús general abans que un Mac o un iPad es pugui gestionar, i per a la majoria de desplegaments gestionats per internet la resposta és no. Apple permet que el dispositiu arribi a un servei de gestió segons el seu propi calendari, i el trànsit que importa és un canal d'ordres signat, no una sessió d'escriptori. Si això us funciona depèn de tres condicions, i és fàcil confondre-les perquè des de fora totes semblen accés remot.
Anomeneu la necessitat abans de triar un transport
Les ordres de gestió i els perfils de configuració són una necessitat, la compartició interactiva de pantalla és una segona, i arribar a una aplicació interna privada és una tercera. Tenen propietaris diferents, autenticació diferent i sovint una exposició acceptable molt diferent. Ajuntar-les és com un parc acaba amb una llista de ports pública que ningú no pot defensar.
Les tres necessitats no comparteixen un 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 |
La confusió sol començar amb una llista de verificació antiga del servidor. Un document històric d'OS X Server enumera un conjunt llarg de ports, i algú els redirigeix tots a la vora perquè el servei de gestió és en algun lloc allà dins. Això no és una arquitectura de gestió, i amplia la superfície exposada molt més enllà del pla de control que intentàveu publicar.
Què fa realment la notificació push
En el flux documentat per Apple, el servidor de gestió envia una notificació APNs per dir al dispositiu que hi ha feina pendent. Després el dispositiu obre una connexió amb el servidor de gestió i demana les seves ordres. El push és un timbre, no un túnel: no transporta cap càrrega arbitrària, ni cap sessió d'escriptori remot, ni el trànsit de cap altra aplicació.
Per tant, el dispositiu ha d'estar inscrit al servei previst, confiar en els punts finals esperats i poder arribar tant al servei de gestió com als serveis d'Apple dels quals depèn el flux. La guia d'Apple per preparar la xarxa enumera aquestes dependències, i no són parts negociables del flux. Un servidor de gestió que només existeix dins de la vostra xarxa encara necessita un camí compatible que el dispositiu pugui fer servir de debò. Anomenar-ho MDM no fa que un punt final inabastable sigui abastable.
Manteniu explícits els camins permesos, inclosa qualsevol política de proxy i d'inspecció TLS que hi hagi al mig. Un aparell d'inspecció que trenca la cadena de certificats esperada semblarà exactament una inscripció trencada.
Quan la VPN és la resposta equivocada
Si el vostre servei de gestió es publica a internet amb un certificat correcte i el dispositiu inicia cada connexió, una VPN afegeix un salt sense afegir cap control. El dispositiu ja s'autentica amb la seva identitat d'inscripció, i el servidor ja decideix quines ordres acceptarà. Un túnel al davant d'això canvia el camí de xarxa, no la decisió de confiança.
El mateix pla de control també pot lliurar el propi perfil de VPN. Aquest ordre importa: una configuració de VPN gestionada arriba com una càrrega més, així que el dispositiu no necessita que el túnel existeixi abans de rebre el perfil que el crea.
Quan la VPN és la resposta correcta
Hi ha parcs on el punt final de gestió no hauria de ser mai abastable des d'internet, i això és un disseny legítim i no una falta de valor. Entorns regulats, equips d'IT interns petits i servidors que també allotgen altres interfícies administratives sovint hi acaben. En aquest cas, un camí d'accés protegit davant del servei de gestió és arquitectura deliberada, no una solució improvisada.
La compartició de pantalla i l'accés a aplicacions privades solen pertànyer també a aquesta banda de la línia. Tots dos exposen molt més que un canal d'ordres, i tots dos mereixen la seva pròpia autenticació en lloc de viatjar sobre la identitat d'inscripció.
La trampa d'arrencada que trenca la recuperació
Aquí teniu la fallada contra la qual dissenyaria: l'únic camí cap al servei de gestió passa per una VPN, i el perfil o la credencial de VPN del dispositiu ha caducat. El dispositiu no pot arribar al servidor per recollir una ordre de substitució, i el servidor no pot empènyer res per un túnel que no s'aixecarà. La recuperació ara depèn d'un usuari que potser és a centenars de quilòmetres.
Manteniu un segon camí independent per a la recuperació, sigui un canal de gestió fora de banda, un administrador local o un servei de gestió que segueixi sent abastable sense el túnel. Proveu-lo mentre tot funciona, perquè durant un incident no tindreu una prova neta.
Després anoteu quina de les tres necessitats serveix cada camí, i elimineu les redireccions de ports que no serveixen a cap d'elles. Un parc que es pot gestionar sense un túnel general, i que encara es pot reparar quan el túnel és el que s'ha trencat, és el resultat pel qual val la pena dissenyar.