Brauchen Sie ein VPN für Apple MDM? Drei Zugriffsbedarfe, eine Antwort
Apple MDM läuft über APNs und vom Gerät initiiertes HTTPS, nicht über einen LAN-Tunnel. Trennen Sie Verwaltung, Bildschirmfreigabe und Zugriff auf private Apps, bevor Sie ein VPN hinzufügen.
Die Frage lautet selten, ob die Verwaltung von Apple-Geräten Verschlüsselung braucht, denn das tut sie. Die eigentliche Frage ist, ob Ihr Gerätebestand ein Allzweck-VPN braucht, bevor ein Mac oder iPad überhaupt verwaltet werden kann, und für die meisten über das Internet verwalteten Installationen lautet die Antwort nein. Apple lässt das Gerät einen Verwaltungsdienst nach seinem eigenen Zeitplan erreichen, und der entscheidende Verkehr ist ein signierter Befehlskanal, keine Desktop-Sitzung. Ob das für Sie funktioniert, hängt an drei Bedingungen, und sie sind leicht zu verwechseln, weil sie von außen alle wie Fernzugriff aussehen.
Benennen Sie den Bedarf, bevor Sie einen Transport wählen
Verwaltungsbefehle und Konfigurationsprofile sind ein Bedarf, interaktive Bildschirmfreigabe ist ein zweiter, und der Zugriff auf eine private interne Anwendung ist ein dritter. Sie haben unterschiedliche Verantwortliche, unterschiedliche Authentifizierung und oft sehr unterschiedliche akzeptable Exposition. Sie alle über einen Kamm zu scheren, führt dazu, dass ein Gerätebestand eine öffentliche Portliste bekommt, die niemand verteidigen kann.
Die drei Bedarfe teilen sich keinen 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 |
Die Verwirrung beginnt meist mit einer alten Server-Checkliste. Ein historisches Dokument zu OS X Server listet eine lange Portliste auf, und jemand leitet alle am Rand weiter, weil der Verwaltungsdienst irgendwo darin steckt. Das ist keine Verwaltungsarchitektur, und es erweitert die exponierte Oberfläche weit über die Steuerungsebene hinaus, die Sie veröffentlichen wollten.
Was die Push-Benachrichtigung tatsächlich tut
Im dokumentierten Ablauf von Apple sendet der Verwaltungsserver eine APNs-Benachrichtigung, um dem Gerät mitzuteilen, dass Arbeit wartet. Das Gerät öffnet dann eine Verbindung zum Verwaltungsserver und fragt nach seinen Befehlen. Der Push ist eine Türklingel, kein Tunnel: Er trägt keine beliebige Nutzlast, keine Remotedesktop-Sitzung und keinen Verkehr anderer Apps.
Das Gerät muss also beim vorgesehenen Dienst registriert sein, den erwarteten Endpunkten vertrauen und sowohl den Verwaltungsdienst als auch die Apple-Dienste erreichen können, von denen der Ablauf abhängt. Apples Anleitung zur Netzwerkvorbereitung listet diese Abhängigkeiten auf, und sie sind keine verhandelbaren Teile des Ablaufs. Ein Verwaltungsserver, der nur in Ihrem Netzwerk existiert, braucht weiterhin einen unterstützten Pfad, den das Gerät tatsächlich nutzen kann. Ihn MDM zu nennen macht einen unerreichbaren Endpunkt nicht erreichbar.
Halten Sie die erlaubten Pfade explizit, einschließlich jeder Proxy- und TLS-Inspektionsrichtlinie dazwischen. Eine Inspektionsappliance, die die erwartete Zertifikatskette bricht, sieht genau wie eine kaputte Registrierung aus.
Wann das VPN die falsche Antwort ist
Wenn Ihr Verwaltungsdienst mit einem korrekten Zertifikat im Internet veröffentlicht ist und das Gerät jede Verbindung initiiert, fügt ein VPN einen Sprung hinzu, ohne eine Kontrolle hinzuzufügen. Das Gerät authentifiziert sich bereits mit seiner Registrierungsidentität, und der Server entscheidet bereits, welche Befehle er akzeptiert. Ein Tunnel davor ändert den Netzwerkpfad, nicht die Vertrauensentscheidung.
Dieselbe Steuerungsebene kann auch das VPN-Profil selbst ausliefern. Diese Reihenfolge ist wichtig: Eine verwaltete VPN-Konfiguration kommt als bloß eine weitere Nutzlast an, also braucht das Gerät den Tunnel nicht, bevor es das Profil erhalten kann, das ihn erzeugt.
Wann das VPN die richtige Antwort ist
Es gibt Gerätebestände, in denen der Verwaltungsendpunkt niemals aus dem Internet erreichbar sein sollte, und das ist ein legitimes Design und kein Mangel an Mut. Regulierte Umgebungen, kleine interne IT-Teams und Server, die auch andere administrative Schnittstellen hosten, landen oft dort. In diesem Fall ist ein geschützter Zugriffspfad vor dem Verwaltungsdienst bewusste Architektur, kein Notbehelf.
Bildschirmfreigabe und Zugriff auf private Anwendungen gehören meist ebenfalls auf diese Seite der Linie. Beide legen weit mehr offen als ein Befehlskanal, und beide verdienen ihre eigene Authentifizierung, statt auf der Registrierungsidentität mitzufahren.
Die Bootstrap-Falle, die die Wiederherstellung bricht
Hier ist der Fehler, gegen den ich entwerfen würde: Der einzige Pfad zum Verwaltungsdienst führt über ein VPN, und das VPN-Profil oder die Anmeldedaten auf dem Gerät sind abgelaufen. Das Gerät kann den Server nicht erreichen, um einen Ersatzbefehl zu holen, und der Server kann nichts durch einen Tunnel schieben, der nicht hochkommt. Die Wiederherstellung hängt nun von einem Benutzer ab, der Hunderte von Kilometern entfernt sein kann.
Halten Sie einen zweiten, unabhängigen Pfad für die Wiederherstellung bereit, sei es ein Out-of-Band-Verwaltungskanal, ein lokaler Administrator oder ein Verwaltungsdienst, der ohne den Tunnel erreichbar bleibt. Testen Sie ihn, solange alles funktioniert, denn während eines Vorfalls bekommen Sie keinen sauberen Test.
Schreiben Sie dann auf, welchen der drei Bedarfe jeder Pfad bedient, und entfernen Sie die Portweiterleitungen, die keinem davon dienen. Ein Gerätebestand, der ohne einen allgemeinen Tunnel verwaltet werden kann und sich noch reparieren lässt, wenn der Tunnel das ist, was kaputtging, ist das Ergebnis, für das es sich zu entwerfen lohnt.