Die mobilen Geräte aus dem Hause Apple ermöglichen für den Einsatz im Unternehmen tiefgreifende Anpassungen. Administratoren können verschiedene Konfigurationen vornehmen, Geräte inventarisieren und ganzheitlich verwalten. Trotzdem ist das Management mobiler Endgeräte oft mit einem beachtlichen Zeitaufwand verbunden. Dieser Beitrag wirft einen Blick hinter die Kulissen und zeigt, wie Apples MDM-System entstand, wie es sich derzeit entwickelt und was Admins bei der mobilen Verwaltung des Apple-Fuhrparks beachten sollten.
Das Original-iPhone wurde 2007 von Steve Jobs vorgestellt und war ein reines Endkundenprodukt. Damals erfolgte die Verwaltung noch manuell über iTunes, das zu Beginn nur für macOS existierte. Zudem mussten mit iTunes Anwender ein iPhone zunächst bei Apple registrieren und es verbinden, um es verwenden zu können. Eine zentrale Verteilung von Software gab es ebenfalls nicht. Die einzige Möglichkeit, Software auf einem iPhone mit einem Computer zu verwalten, gelang per USB-Kabel und Drag-and-drop – ebenfalls in iTunes. Auch das Einsehen und Setzen von Einstellungen war über iTunes nur in homöopathischen Dosen möglich. Dies alles sollte sich über die Zeit jedoch gründlich ändern.
Ein Blick zurück
Für tiefere Eingriffe stand 2008 erstmalig ein Tool namens "iPhone Configuration Utility" (damals noch für Windows und macOS, heute als Apple Configurator nur für macOS) zur Verfügung. Damit war es erstmalig möglich, über ein Profil ausgefeilte Konfigurationen zu erstellen und auf ein bis n Geräten sequenziell anzuwenden. Ein solches Profil stellte damals wie heute eine kleine XML-Datei dar, die eine bestimmte Konfiguration auf einem iOS-Gerät aktivieren/verhindern konnte. Derartige Profile waren kabelgebunden oder per iMessage oder Webserver-Download verteilbar.
Als das iPhone OS 3.1 (der Name iOS kam erst später) im Jahr 2009 auf den Markt kam, wurde die Konfiguration mithilfe der Exchange-ActiveSync-Richtlinien (EAS) unterstützt. Diese wiederum führte Microsoft 2005 als Teil von Exchange 2003 SP2 zur Verwaltung von Windows-Mobile-Geräten ein. Damit konnten Administratoren erstmalig "over-the-air" Richtlinien auf ein iPhone bringen. So ließ sich etwa die Verwendung der Kamera einschränken oder die Nutzung eines Gerätekennworts erzwingen. Ein professionelles Gerätemanagement aus heutiger Sicht war dies jedoch alles nicht.
Das Original-iPhone wurde 2007 von Steve Jobs vorgestellt und war ein reines Endkundenprodukt. Damals erfolgte die Verwaltung noch manuell über iTunes, das zu Beginn nur für macOS existierte. Zudem mussten mit iTunes Anwender ein iPhone zunächst bei Apple registrieren und es verbinden, um es verwenden zu können. Eine zentrale Verteilung von Software gab es ebenfalls nicht. Die einzige Möglichkeit, Software auf einem iPhone mit einem Computer zu verwalten, gelang per USB-Kabel und Drag-and-drop – ebenfalls in iTunes. Auch das Einsehen und Setzen von Einstellungen war über iTunes nur in homöopathischen Dosen möglich. Dies alles sollte sich über die Zeit jedoch gründlich ändern.
Ein Blick zurück
Für tiefere Eingriffe stand 2008 erstmalig ein Tool namens "iPhone Configuration Utility" (damals noch für Windows und macOS, heute als Apple Configurator nur für macOS) zur Verfügung. Damit war es erstmalig möglich, über ein Profil ausgefeilte Konfigurationen zu erstellen und auf ein bis n Geräten sequenziell anzuwenden. Ein solches Profil stellte damals wie heute eine kleine XML-Datei dar, die eine bestimmte Konfiguration auf einem iOS-Gerät aktivieren/verhindern konnte. Derartige Profile waren kabelgebunden oder per iMessage oder Webserver-Download verteilbar.
Als das iPhone OS 3.1 (der Name iOS kam erst später) im Jahr 2009 auf den Markt kam, wurde die Konfiguration mithilfe der Exchange-ActiveSync-Richtlinien (EAS) unterstützt. Diese wiederum führte Microsoft 2005 als Teil von Exchange 2003 SP2 zur Verwaltung von Windows-Mobile-Geräten ein. Damit konnten Administratoren erstmalig "over-the-air" Richtlinien auf ein iPhone bringen. So ließ sich etwa die Verwendung der Kamera einschränken oder die Nutzung eines Gerätekennworts erzwingen. Ein professionelles Gerätemanagement aus heutiger Sicht war dies jedoch alles nicht.
Im Jahr 2010 führte Apple mit iOS 4 die Grundlagen für echtes Mobile Device Management (MDM) ein. Es basierte auf dem Apple Push Notification Service (APNs) und erlaubte die kabellose Auslieferung der bereits bekannten Profildateien. Hierzu stellte Apple selbst eine Referenzimplementierung mit dem Profile-Manager-Server für macOS bereit. Neben der Verteilung und Verwaltung von Profilen erlaubte dieses System drei weitere Aktionen: Das Auffinden, Sperren und Löschen einzelner Endgeräte. Seit dieser Veröffentlichung sind die Funktionen im MDM-Umfeld stetig gewachsen. Jedes Jahr aktualisiert Apple die gebotenen Möglichkeiten.
Begriffsklärung MDM
Im Laufe der vergangenen Jahre hat sich der Begriff MDM stetig gewandelt. Auch wenn weiterhin von MDM die Rede ist, ergibt die Unterscheidung der folgenden aufbauenden Abkürzungen im Alltag Sinn: Das sogenannte Enterprise Mobility Management (EMM) basiert auf MDM-Werkzeugen, befasst sich jedoch zusätzlich mit der Verwaltung von Anwendungen und Inhalten, die auf den Geräten installiert sind. Unified Endpoint Management (UEM) hingegen bezieht herkömmliche Laptops und Desktops in die Verwaltungsfunktion mit ein und beschränkt sich nicht auf mobile Endgeräte.
Apple Push Notification Service
Bevor ein Gerät sich mit Apples MDM-System verbinden kann, gilt es, ein paar Grundlagen zu schaffen. Zuallererst ist es wichtig zu verstehen, dass die Basis des Gerätemanagements, das Bindeglied zwischen MDM und iOS-Gerät, der APNs ist. Dieser übermittelt nicht die Konfigurationen selbst, er weist das Gerät vielmehr darauf hin, dass es sich beim MDM-System melden soll. Daher ist es essenziell, dass die Verbindung zum APNs sowohl für das iOS-Endgerät als auch für das eingesetzte MDM-Werkzeug selbst problemfrei funktioniert. Die folgenden Abschnitte erläutern deshalb den dahinterliegenden Mechanismus.
Nach dem Auspacken und Einschalten muss sich ein Gerät erstmalig mit dem APNs verbinden. Da ein Device eine (beliebig) lange Zeit in seiner Verpackung gewesen sein kann, muss es sich erstmalig initialisieren. Dies erreicht es durch eine sogenannte BAG-Datei, die unter "http:// init-p01st.push.apple.com/bag" bereitliegt. Der Einrichtungsassistent ruft die Datei ab, sobald das Gerät erstmalig eine Internetverbindung aufgebaut hat.
Diese BAG-Datei mit der Endung ".plist" liefert drei Schlüssel aus, deren Inhalt Base64-kodiert ist. Neben einem privaten Schlüssel ("key") und einigen Standard-SSL-Zertifikaten von Apple ("certs") befinden sich in der letzten Sektion ("bag") Auskünfte über den APNs-Dienst wie "APNsCourierHostname", "ClientConnectionRetryAttempts" und andere Parameter [1]. Nun ist die Grundlage geschaffen, dass das Gerät mit dem APNs direkt kommunizieren kann. Wie Bild 1 zeigt, baut das Device die Verbindung auf und sendet ein Signal ("hello") an den APNs. Dieser Dienst sendet nun seinerseits ein Zertifikat an das Endgerät, das von sich aus nach einer erfolgreichen Zertifikatsprüfung ein eigenes Gerätezertifikat generiert und an den APNs zurückliefert.
Nach diesem Zertifikatsaustausch sind beide Parteien in der Lage, eine kryptografisch abgesicherte und vertrauliche Kommunikationsverbindung aufzunehmen. Dieser Verbindungsaufbau ist unabhängig davon, ob später ein MDM-System die Verwaltung des Endgerätes übernehmen soll. Auch gewöhnliche Push-Nachrichten von Backend-Systemen eingesetzter Apps nutzen den APNs und laufen über die gleiche Infrastruktur von Apple.
Bild 1: Aufbau der Vertrauenskette zwischen APNs und iOS-Gerät.
Gerät an APNs bekanntmachen
Die in MDM-Systemen integrierte Funktionalität zur Inventarisierung und Verwaltung von Geräten verbessert sich ständig. Das gilt für alle Betriebssysteme mit Ausnahme von watchOS. Bei macOS hingegen nimmt parallel zu dieser Entwicklung die Möglichkeit, Geräte mithilfe von Skripten zu konfigurieren, jedes Jahr ab, sodass die MDM-basierte Verwaltung mit jeder neuen macOS-Version immer wichtiger wird.
Damit eine MDM-Software ein Gerät verwalten kann, ist auch diese an den APNs-Dienst anzubinden. Administratoren müssen hierzu zuerst über "https://identity. apple.com" ein Push-Zertifikat erstellen. Es ist an die Apple-ID gebunden, mit der der Prozess zur Generierung initial gestartet wurde. Nach der Erzeugung muss das Zertifikat in das MDM geladen werden. Mit ihm ist das MDM-System in der Lage, für die zu verwaltenden Geräte eigene Zertifikate auszustellen, um die Vertrauensketten mit den Geräten herzustellen.
Der Anmeldeprozess eines MDM-Systems am APNs (Bild 2) ist nun identisch zum iOS-Endgeräte-Verfahren. Anstatt des Gerätezertifikats findet jedoch das generierte Push-Zertifikat Verwendung und am Ende ist das MDM-System ebenfalls in der Lage, eine kryptografisch abgesicherte Verbindung zum APNs aufzubauen.
Bild 2: Aufbau der Vertrauenskette zwischen APNs und MDM-System.
Device in MDM einbinden
Ab jetzt kann ein Gerät am MDM-System eine Registrierungsanforderung stellen. Dabei ist es egal, ob diese Registrierung durch eine App, die einen MDM-Client bereitstellt (Agend Based Management), oder automatisiert per Apple Business Manager erfolgt – intern ist das Vorgehen identisch.
Eine Registrierungsanfrage durch ein Gerät wird von einem MDM-System immer mit einem Registrierungszertifikat beantwortet, in dem der Host-Name der MDM-Plattform fest eingebettet ist. Achten Sie darauf, dass dieses Zertifikat nicht abläuft. Nach der erfolgreichen Registrierung eines Geräts lässt sich der Host-Name des MDM-Systems und damit das MDM-System selbst nicht mehr ändern, ohne das Enrollment rückgängig zu machen.
Im Rahmen der Registrierung erfolgt der Ablauf eines sogenannten Check-in-Protokolls. So muss das Gerät auch dem APNs mitteilen, dass es ab jetzt von einem MDM-System verwaltet wird. Hierzu generiert der APNs einen APNs-Token (Trust Token), der mit dem MDM-System ausgetauscht wird. Zusätzlich erzeugt das Gerät einen eindeutigen Push-Magic-String zum Nachweis der Authentizität eines Kommandos per Push-Infrastruktur.
Einmal registriert, kann ein MDM-Server über eine HTTP/2-basierte API eine Benachrichtigung über APNs mit der PushMagic-Zeichenfolge als MDM-Schlüssel an ein Gerät senden. Die Anweisungen für das Gerät selbst werden auf dem MDM-System so lange vorgehalten, bis sich das Endgerät per HTTPS-Verbindung zurückmeldet.
Der MDM-Server stellt dann alle Befehle, die auf das Gerät warten, als Wörterbuchdatei (.plist) in eine Warteschlange. Dabei handelt es sich weitestgehend um die gleichen Profildateien, wie sie eingangs erwähnt wurden. Mögliche Kommandos beschreibt Apple im MDM Protocol Reference Guide [2] näher.
Hat ein mobiles Gerät eine Verbindung zu den Apple-Push-Benachrichtigungsservern etabliert, wird es über das Push-Thema angewiesen, seinen registrierten MDM-Server abzufragen. Hierzu stellt das Gerät eigenständig eine Verbindung her, um die die dort bereitgelegte Wörterbuchdatei zu empfangen.
Firewall richtig einstellen
Die Produkte von Apple erfordern für eine Vielzahl von Diensten den Zugriff auf ausgewählte Internet-Hosts. Alle Netzwerkverbindungen müssen sich dabei durch das Gerät initiieren lassen. Für die Kollegen aus der Sicherheitsabteilung sicherlich wichtig und interessant: Die von Apple betriebenen Hosts nehmen niemals eigenständig Kontakt zu einem MDM-System auf. Die nun folgende Kommunikation läuft über eine HTTPS-Verbindung und dar nicht durch eine Firewall, die sich sonst vielleicht per HTTPS Interception (SSL-Inspektion) dazwischen schaltet, überwacht werden.
Unterstützt die von Ihnen eingesetzte Firewall die Verwendung von Hostnamen, können Sie möglicherweise die meisten Apple-Dienste nutzen, indem Sie ausgehende Verbindungen zu "apple.com" erlauben. Wer eine vollständige Liste der Dienste und Funktionen benötigt, die sich dahinter verbergen, findet diese unter [3].
Um jedoch auf Nummer sicher zu gehen, sollten Sie Ihre Firewall so konfigurieren, dass ausgehende Verbindungen zum 17.0.0.0/8-Adressblock freigeschaltet sind. Haben Sie ein Problem mit der APNs-Kommunikation, können Sie die Erreichbarkeit des APNs aus Ihrem Netzwerk heraus zum Beispiel unter macOS mit der Anwendung "Push Diagnostics" [4] oder vom iOS-Gerät aus mit der App "Services Test" [5] prüfen.
Zur Entwicklerkonferenz in diesem Jahr hat Apple zudem weitere Veränderungen angekündigt. MDM-Anbieter müssen ihre Systeme anpassen, damit diese mit iOS / iPadOS 15 weiterhin funktionieren. Vereinfacht ausgedrückt erwartet das neue Betriebssystem, dass jeder Befehl mit einem eindeutigen Universally Unique Identifier (UUID) versehen ist. Früher ließen sich diese Identifier in einer Datei mehrfach verwenden, damit ist jetzt Schluss.
Wie bereits erläutert, wird jedes zu verwaltende Gerät individuell angesprochen. MDM-Systeme arbeiten mit einer Push-Kommunikation, was bedeutet, dass ein Endgerät passiv bleibt, bis ein MDM-System einen Befehl sendet. Apple gab unlängst bekannt, dass sich dieses Verfahren zumindest in Teilen umkehren lässt. Der MDM-Server gibt zwar immer noch vor, welche Anweisungen gelten. Das Endgerät kontaktiert jedoch den MDM-Server aktiv.
Die Umstellung dieses synchronen Vorgehens auf ein asynchrones Verhalten erlaubt, dass ein Gerät sich eigenständig am MDM-System meldet, wenn ein Befehl ausgeführt wurde (Bild 3). Hierzu muss der MDM-Hersteller einen sogenannten Notification-Service anbieten, den die Geräte adressieren können. Die Unterstützung von asynchronen Prozessen erlaubt eine effizientere und stressfreie Vorgehensweise gerade bei Umgebungen mit größerer Geräteanzahl. Die Funktion steht mit iOS/iPadOS 15 zur Verfügung, allerdings nur im Umfeld des Verteilens oder Veränderns von Apps und Lizenzen auf einem Endgerät oder für eine (verwaltete) Apple-ID.
Bild 3: Ab iOS/iPadOS 15 führt Apple ein neues, asynchrones Managementparadigma für seine mobilen Geräte ein.
Im Gegensatz zum kurzfristigen Handlungsbedarf bei der UUID, ohne die die Erreichbarkeit der Geräte nicht mehr gegeben ist, haben die Hersteller in diesem Umfeld jedoch Zeit, diese Funktion umzusetzen.
Die zukünftige Ausweitung auf andere Bereiche des Geräts wurde ebenfalls vorgestellt. Unter dem Begriff "Declarative Device Management" hebt Apple die Fesseln des MDM auf und bietet einige interessante (asynchrone) Vorgänge und Veränderungen an:
1. Die bisher bekannten Wörterbuchdateien für Konfigurationsprofile werden ersetzt. Waren diese bisher einer XML-Struktur unterworfen, gibt es mit dem neuen Verfahren nun JSON-Objekte.
2. Das neue Verfahren erlaubt, Referenzdaten (etwa Benutzername, E-Mail-Adresse oder Zertifikate) zentral bereitzustellen und in verschiedenen Konfigurationen zu referenzieren.
3. Auch das Erstellen von "Schablonen" in Umgebungen mit n-zu-n-Konfigurationen inklusive einer hinterlegten Logik ist erlaubt. Diese Logik kann definieren, wann bestimmte Konfigurationen greifen oder auch nicht – etwa abhängig von der Betriebssystemversion.
Die Erweiterung des asynchronen Prozesses bezeichnet Apple im neuen Verfahren generell als "Statuskanal". Geräte sind in der Lage, diesen Statuskanal zu befüllen, wenn etwa das Betriebssystem automatisiert oder durch den Anwender aktualisiert wurde. Wird eine solche Information zurückgespielt, ist das Verfahren in der Lage, neue Funktionen, die sich durch das Update ergeben, gleich zu konfigurieren. Das neue Verfahren räumt mit vielen in die Jahre gekommenen Problemen auf. Die Abwicklung von mehreren Geräten gestaltet sich effizienter und diese können aufgrund der wegfallenden stetigen Kommunikation sparsamer mit Rechenzeit und Netzwerkverkehr umgehen und verbrauchen damit weniger Batterie.
Das deklarative Management ist aktuell so konzipiert, dass es nahtlos mit dem bestehenden MDM-Protokoll koexistiert. Das bedeutet, dass die Hersteller von MDM-Lösungen eine schrittweise Einführung der neuen Funktionalitäten ohne Unterbrechung der bestehenden Funktionalitäten vornehmen können. Das MDM-System kann über das alte Protokoll einen Befehl senden, der die deklarativen Managementfunktionen aktiviert. Es gibt dabei jedoch noch eine Besonderheit zu beachten: Die deklarative Geräteverwaltung lässt sich aktuell nur innerhalb der iOS/iPadOS-15-Benutzerregistrierung aktivieren. Die vollständige Implementierung gerade für Geräte im "normalen" Management dürfte dabei sicherlich eine mehrjährige Anstrengung werden – seitens Apple, aber auch der MDM-Hersteller.
Fazit
Mit iOS 4 legte Apple den Grundstein für das heutige Gerätemanagement. So mächtig dies zwischenzeitlich wurde, so sehr ist das dahinter liegende technische Verfahren in die Jahre gekommen. Der in diesem Jahr eingeleitete Übergang zu neuen Paradigmen der Geräteverwaltung dürfte hier eine neue Ära einläuten. Auch wenn es sich momentan nur optional für Geräte mit "User Enrollment" nutzen lässt: Es wird interessant sein zu sehen, wie es sich im Apple-Ökosystem über die nächsten Jahre verbreitet.