Avez-vous besoin d'un VPN pour Apple MDM ? Trois besoins d'accès, une réponse
Apple MDM repose sur APNs et sur du HTTPS initié par l'appareil, pas sur un tunnel LAN. Séparez la gestion, le partage d'écran et l'accès aux applications privées avant d'ajouter un VPN.
La question est rarement de savoir si la gestion des appareils Apple a besoin de chiffrement, car elle en a besoin. La vraie question est de savoir si votre parc a besoin d'un VPN générique avant qu'un Mac ou un iPad puisse seulement être géré, et pour la plupart des déploiements gérés par internet, la réponse est non. Apple laisse l'appareil joindre un service de gestion selon son propre calendrier, et le trafic qui compte est un canal de commandes signé, pas une session de bureau. Que cela fonctionne chez vous tient à trois conditions, et il est facile de les confondre parce que de l'extérieur elles ressemblent toutes à un accès distant.
Nommez le besoin avant de choisir un transport
Les commandes de gestion et les profils de configuration sont un besoin, le partage d'écran interactif en est un deuxième, et l'accès à une application interne privée un troisième. Ils ont des propriétaires différents, une authentification différente et souvent une exposition acceptable très différente. Les mettre dans le même sac, c'est ainsi qu'un parc finit avec une liste de ports publique que personne ne peut défendre.
Les trois besoins ne partagent pas un même 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 confusion commence généralement par une vieille liste de contrôle de serveur. Un document historique sur OS X Server énumère une longue série de ports, et quelqu'un les redirige tous en périphérie parce que le service de gestion se trouve quelque part là-dedans. Ce n'est pas une architecture de gestion, et cela élargit la surface exposée bien au-delà du plan de contrôle que vous cherchiez à publier.
Ce que fait réellement la notification push
Dans le flux documenté par Apple, le serveur de gestion envoie une notification APNs pour dire à l'appareil que du travail l'attend. L'appareil ouvre ensuite une connexion vers le serveur de gestion et demande ses commandes. Le push est une sonnette, pas un tunnel : il ne transporte aucune charge arbitraire, aucune session de bureau à distance et aucun trafic d'une autre application.
L'appareil doit donc être inscrit auprès du service prévu, faire confiance aux points de terminaison attendus et pouvoir joindre à la fois le service de gestion et les services Apple dont dépend le flux. Le guide d'Apple pour la préparation du réseau énumère ces dépendances, et elles ne sont pas des parties négociables du flux. Un serveur de gestion qui n'existe qu'à l'intérieur de votre réseau a toujours besoin d'un chemin pris en charge que l'appareil peut réellement utiliser. L'appeler MDM ne rend pas un point de terminaison injoignable joignable.
Gardez les chemins autorisés explicites, y compris toute politique de proxy et d'inspection TLS au milieu. Un équipement d'inspection qui casse la chaîne de certificats attendue ressemblera exactement à une inscription cassée.
Quand le VPN est la mauvaise réponse
Si votre service de gestion est publié sur internet avec un certificat correct et que l'appareil initie chaque connexion, un VPN ajoute un saut sans ajouter de contrôle. L'appareil s'authentifie déjà avec son identité d'inscription, et le serveur décide déjà quelles commandes il acceptera. Un tunnel devant cela change le chemin réseau, pas la décision de confiance.
Le même plan de contrôle peut aussi livrer le profil VPN lui-même. Cet ordre compte : une configuration VPN gérée arrive comme une charge utile de plus, donc l'appareil n'a pas besoin que le tunnel existe avant de recevoir le profil qui le crée.
Quand le VPN est la bonne réponse
Il existe des parcs où le point de terminaison de gestion ne devrait jamais être joignable depuis internet, et c'est une conception légitime, pas un manque de courage. Les environnements réglementés, les petites équipes informatiques internes et les serveurs qui hébergent aussi d'autres interfaces d'administration y arrivent souvent. Dans ce cas, un chemin d'accès protégé devant le service de gestion est une architecture délibérée, pas un contournement.
Le partage d'écran et l'accès aux applications privées appartiennent généralement aussi à ce côté de la ligne. Les deux exposent bien plus qu'un canal de commandes, et les deux méritent leur propre authentification au lieu de rouler sur l'identité d'inscription.
Le piège d'amorçage qui casse la reprise
Voici la panne contre laquelle je concevrais : le seul chemin vers le service de gestion passe par un VPN, et le profil ou l'identifiant VPN de l'appareil a expiré. L'appareil ne peut pas joindre le serveur pour récupérer une commande de remplacement, et le serveur ne peut rien pousser à travers un tunnel qui ne montera pas. La reprise dépend désormais d'un utilisateur qui peut être à des centaines de kilomètres.
Gardez un second chemin indépendant pour la reprise, que ce soit un canal de gestion hors bande, un administrateur local ou un service de gestion qui reste joignable sans le tunnel. Testez-le pendant que tout fonctionne, car vous n'aurez pas de test propre pendant un incident.
Ensuite, notez à lequel des trois besoins chaque chemin répond, et supprimez les redirections de ports qui ne servent aucun d'eux. Un parc qui peut être géré sans tunnel général, et qui peut encore être réparé quand c'est le tunnel qui a lâché, est le résultat pour lequel il vaut la peine de concevoir.