Precisa unha VPN para Apple MDM? Tres necesidades de acceso, unha resposta
Apple MDM funciona con APNs e HTTPS iniciado polo dispositivo, non cun túnel de LAN. Separe a xestión, a compartición de pantalla e o acceso a aplicacións privadas antes de engadir unha VPN.
A pregunta raramente é se a xestión de dispositivos Apple necesita cifrado, porque o necesita. A pregunta real é se a súa frota necesita unha VPN de propósito xeral antes de que un Mac ou un iPad se poida xestionar, e para a maioría dos despregamentos xestionados por internet a resposta é non. Apple permite que o dispositivo chegue a un servizo de xestión segundo o seu propio calendario, e o tráfico que importa é unha canle de ordes asinada, non unha sesión de escritorio. Que isto funcione para vostede depende de tres condicións, e é doado confundilas porque desde fóra todas parecen acceso remoto.
Nomee a necesidade antes de escoller un transporte
As ordes de xestión e os perfís de configuración son unha necesidade, a compartición interactiva de pantalla é unha segunda, e chegar a unha aplicación interna privada é unha terceira. Teñen propietarios distintos, autenticación distinta e a miúdo unha exposición aceptable moi distinta. Xuntalas é como unha frota acaba cunha lista de portos pública que ninguén pode defender.
As tres necesidades non comparten un transporte:
| 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 confusión adoita comezar cunha lista de verificación antiga do servidor. Un documento histórico de OS X Server enumera un conxunto longo de portos, e alguén os redirixe todos na beira porque o servizo de xestión está nalgún lugar aí dentro. Iso non é unha arquitectura de xestión, e amplía a superficie exposta moito máis alá do plano de control que intentaba publicar.
Que fai realmente a notificación push
No fluxo documentado por Apple, o servidor de xestión envía unha notificación APNs para dicir ao dispositivo que hai traballo agardando. Despois o dispositivo abre unha conexión co servidor de xestión e pide as súas ordes. O push é un timbre, non un túnel: non transporta ningunha carga arbitraria, nin unha sesión de escritorio remoto, nin o tráfico doutra aplicación.
Así que o dispositivo debe estar inscrito no servizo previsto, confiar nos extremos agardados e poder chegar tanto ao servizo de xestión como aos servizos de Apple dos que depende o fluxo. A guía de Apple para preparar a rede enumera esas dependencias, e non son partes negociables do fluxo. Un servidor de xestión que só existe dentro da súa rede segue necesitando unha ruta compatible que o dispositivo poida usar de verdade. Chamarlle MDM non fai que un extremo inalcanzable sexa alcanzable.
Manteña explícitas as rutas permitidas, incluída calquera política de proxy e inspección TLS que haxa no medio. Un equipo de inspección que rompe a cadea de certificados agardada parecerá exactamente unha inscrición rota.
Cando a VPN é a resposta equivocada
Se o seu servizo de xestión está publicado en internet cun certificado correcto e o dispositivo inicia cada conexión, unha VPN engade un salto sen engadir un control. O dispositivo xa se autentica coa súa identidade de inscrición, e o servidor xa decide que ordes aceptará. Un túnel diante diso cambia a ruta de rede, non a decisión de confianza.
O mesmo plano de control tamén pode entregar o propio perfil de VPN. Ese orde importa: unha configuración de VPN xestionada chega como unha carga máis, así que o dispositivo non necesita que o túnel exista antes de recibir o perfil que o crea.
Cando a VPN é a resposta correcta
Hai frotas nas que o extremo de xestión nunca debería ser alcanzable desde internet, e iso é un deseño lexítimo e non unha falta de valor. Os contornos regulados, os equipos de TI internos pequenos e os servidores que tamén aloxan outras interfaces administrativas adoitan acabar aí. Nese caso, unha ruta de acceso protexida diante do servizo de xestión é arquitectura deliberada, non unha solución improvisada.
A compartición de pantalla e o acceso a aplicacións privadas adoitan pertencer tamén a ese lado da liña. Ambas expoñen moito máis que unha canle de ordes, e ambas merecen a súa propia autenticación en lugar de viaxar sobre a identidade de inscrición.
A trampa de arranque que rompe a recuperación
Aquí está o fallo contra o que eu deseñaría: a única ruta ao servizo de xestión pasa por unha VPN, e o perfil ou a credencial de VPN do dispositivo caducou. O dispositivo non pode chegar ao servidor para recoller unha orde de substitución, e o servidor non pode empurrar nada por un túnel que non vai levantarse. A recuperación agora depende dun usuario que pode estar a centos de quilómetros.
Manteña unha segunda ruta independente para a recuperación, sexa unha canle de xestión fóra de banda, un administrador local ou un servizo de xestión que siga sendo alcanzable sen o túnel. Próbea mentres todo funciona, porque durante un incidente non terá unha proba limpa.
Despois anote cal das tres necesidades serve cada ruta, e elimine as redireccións de portos que non serven a ningunha delas. Unha frota que se pode xestionar sen un túnel xeral, e que aínda se pode reparar cando o túnel é o que se rompeu, é o resultado polo que paga a pena deseñar.