Serve una VPN per Apple MDM? Tre esigenze di accesso, una risposta
Apple MDM si basa su APNs e su HTTPS avviato dal dispositivo, non su un tunnel LAN. Separate gestione, condivisione dello schermo e accesso alle app private prima di aggiungere una VPN.
La domanda raramente è se la gestione dei dispositivi Apple richieda la crittografia, perché la richiede. La vera domanda è se il vostro parco abbia bisogno di una VPN generica prima che un Mac o un iPad possa essere gestito, e per la maggior parte delle installazioni gestite via internet la risposta è no. Apple consente al dispositivo di raggiungere un servizio di gestione secondo il proprio calendario, e il traffico che conta è un canale di comandi firmato, non una sessione desktop. Se questo funzioni per voi dipende da tre condizioni, ed è facile confonderle perché dall'esterno sembrano tutte un accesso remoto.
Nominate l'esigenza prima di scegliere un trasporto
I comandi di gestione e i profili di configurazione sono un'esigenza, la condivisione interattiva dello schermo è la seconda, e raggiungere un'applicazione interna privata è la terza. Hanno proprietari diversi, autenticazione diversa e spesso un'esposizione accettabile molto diversa. Metterle tutte insieme è il modo in cui un parco finisce con un elenco di porte pubblico che nessuno può difendere.
Le tre esigenze non condividono un trasporto:
| 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 confusione di solito inizia con una vecchia lista di controllo del server. Un documento storico su OS X Server elenca una lunga serie di porte, e qualcuno le inoltra tutte sul bordo perché il servizio di gestione è da qualche parte lì dentro. Non è un'architettura di gestione, e allarga la superficie esposta ben oltre il piano di controllo che stavate cercando di pubblicare.
Che cosa fa davvero la notifica push
Nel flusso documentato da Apple, il server di gestione invia una notifica APNs per dire al dispositivo che c'è lavoro in attesa. Il dispositivo apre quindi una connessione verso il server di gestione e chiede i propri comandi. Il push è un campanello, non un tunnel: non trasporta alcun payload arbitrario, nessuna sessione desktop remota e nessun traffico di altre app.
Il dispositivo deve quindi essere iscritto al servizio previsto, fidarsi degli endpoint attesi e poter raggiungere sia il servizio di gestione sia i servizi Apple da cui dipende il flusso. La guida di Apple per la preparazione della rete elenca queste dipendenze, e non sono parti negoziabili del flusso. Un server di gestione che esiste solo dentro la vostra rete ha comunque bisogno di un percorso supportato che il dispositivo possa davvero usare. Chiamarlo MDM non rende raggiungibile un endpoint irraggiungibile.
Mantenete espliciti i percorsi consentiti, inclusa qualsiasi politica di proxy e ispezione TLS nel mezzo. Un'appliance di ispezione che spezza la catena di certificati attesa apparirà esattamente come un'iscrizione rotta.
Quando la VPN è la risposta sbagliata
Se il servizio di gestione è pubblicato su internet con un certificato corretto e il dispositivo avvia ogni connessione, una VPN aggiunge un salto senza aggiungere un controllo. Il dispositivo si autentica già con la propria identità di iscrizione, e il server decide già quali comandi accetterà. Un tunnel davanti a questo cambia il percorso di rete, non la decisione di fiducia.
Lo stesso piano di controllo può anche distribuire il profilo VPN stesso. Quest'ordine conta: una configurazione VPN gestita arriva come l'ennesimo payload, quindi il dispositivo non ha bisogno che il tunnel esista prima di ricevere il profilo che lo crea.
Quando la VPN è la risposta giusta
Ci sono parchi in cui l'endpoint di gestione non dovrebbe mai essere raggiungibile da internet, e questa è una progettazione legittima, non una mancanza di coraggio. Ambienti regolamentati, piccoli team IT interni e server che ospitano anche altre interfacce amministrative finiscono spesso lì. In quel caso un percorso di accesso protetto davanti al servizio di gestione è architettura deliberata, non un aggiramento.
La condivisione dello schermo e l'accesso alle applicazioni private di solito appartengono anch'essi a quel lato della linea. Entrambi espongono molto più di un canale di comandi, ed entrambi meritano un'autenticazione propria invece di cavalcare l'identità di iscrizione.
La trappola di bootstrap che spezza il ripristino
Ecco il guasto contro cui progettare: l'unico percorso verso il servizio di gestione passa da una VPN, e il profilo o la credenziale VPN sul dispositivo è scaduto. Il dispositivo non può raggiungere il server per ritirare un comando sostitutivo, e il server non può spingere nulla attraverso un tunnel che non salirà. Il ripristino ora dipende da un utente che può essere a centinaia di chilometri.
Mantenete un secondo percorso indipendente per il ripristino, che sia un canale di gestione fuori banda, un amministratore locale o un servizio di gestione che resta raggiungibile senza il tunnel. Testatelo mentre tutto funziona, perché durante un incidente non avrete un test pulito.
Poi annotate quale delle tre esigenze serve ciascun percorso, e rimuovete gli inoltri di porta che non servono a nessuna di esse. Un parco che può essere gestito senza un tunnel generale, e che può ancora essere riparato quando è il tunnel ciò che si è rotto, è il risultato per cui vale la pena progettare.