Im Zusammenhang mit Apple-Geräten ist ein Mobile Device Management (MDM) ein Bereitstellungsmechanismus für die Verteilung von Daten und Einstellungen an Apple-Geräte. Dazu gehören Macs, iPhones, iPads, Apple TVs und seit 2023 auch die Apple Watch. Genauer gesagt ist ein MDM eine Zentrale zum Senden von Befehlen zur Geräteverwaltung. Dabei sind nicht alle dieser Befehle abwärtskompatibel, sodass MDM-Befehle für eine bestimmte OS-Version und spätere Versionen nicht mit früheren Releases funktionieren. Daher ist es wichtig, eine möglichst homogene Betriebssystemlandschaft im Unternehmen zu erhalten.

Apple hat die MDM-APIs erstmals mit iOS 4 eingeführt und mit macOS X 10.7 Lion auf die Mac-Plattform gebracht. Auch tvOS, initial eine Weiterentwicklung von iOS 9, ermöglichte die Nutzung von MDM von Anfang an. Administratoren können seither MDM-Systeme nutzen, um E-Mails, Sicherheitseinstellungen, Apps, App-Einstellungen, Zertifikate und sogar Medieninhalte auf Apple-Geräte zu übertragen. Da das deklarative Device Management eine Erweiterung für das bestehende MDM-Protokoll darstellt, betrachten wir zunächst die MDM-Grundlagen.

Für den Betrieb eines MDM-Systems sind zwei Hauptkomponenten erforderlich. Dies ist zum einen der Apple Push Notification Service (APNS) und zum anderen der MDM-Server selbst zur Verwaltung der Endgeräte.

Werfen wir daher zunächst einen Blick auf den APNS. Hierbei handelt es sich um einen Dienst, mit dem Benachrichtigungen in Echtzeit an iOS-, macOS-, tvOS- und watchOS-Geräte gesendet werden können. APNS fungiert dabei als eine Art Nachrichtenvermittler zwischen dem (MDM-)Server und dem Endgerät des Benutzers. Dieser Dienst ist dabei auch für jede App auf Apple-Geräten unerlässlich und muss daher von der ersten Sekunde der Nutzung des Geräts an bekannt und zugänglich sein [1].

Wenn ein Benutzer sein neues Apple-Gerät aus der Verpackung nimmt und zum ersten Mal einschaltet, weiß dieses bisher nicht, wie es sich mit APNS verbinden kann. Das liegt daran, dass das Gerät vielleicht schon eine Weile in der Verpackung gelegen hat und Apple sicherstellen möchte, dass es die neuesten Informationen erhält. Das Apple-Gerät kennt lediglich die Adresse "http://init-p01st.push.apple.com/ bag" des Initialisierungsservers, mit dem es kommunizieren kann, um eine Bag-Datei zu erhalten. Diese enthält eine Property-List (Plist) mit einem eingebetteten Schlüssel, kodierte Zertifikate und eine Plist-Datei mit APNS-Parametern, die in Base64-kodiert sind. Darin enthalten sind Informationen wie:

- APNS-Courier-Hostname,

- Anzahl der verfügbaren Courier-Server,

- Einstellungen zur Aufrechterhaltung der Verbindung,

- Timeout und Geschwindigkeitskontrolle und weitere.

Da das Apple-Device nun weiß, wie und wo es mit APNs kommunizieren kann, öffnet dieses eine Verbindung und sagt "hello". Der APNS sendet ebenfalls ein "hello" zurück und stellt zusätzlich ein Zertifikat zur Verfügung. Das Gerät überprüft das Zertifikat und prüft dessen Gültigkeit. Das Device selbst besitzt auch ein (Geräte-)Zertifikat und sendet dieses indessen an den APNS. Der APNS wiederum überprüft genau dieses vom Gerät gesendete Zertifikat. Nachdem beide Seiten jetzt wissen, dass die Kommunikation mit der jeweiligen Gegenseite vertrauenswürdig ist, tauschen sie kryptografische Chiffren aus und beginnen eine sichere Kommunikationsverbindung.

Wenden wir uns jetzt der anderen Hälfte des Gerätemanagements zu, dem MDM-Server. Genau genommen handelt es sich dabei um einen klassischen HTTP-Server, der auf Kommunikation antwortet, entweder mit einer Plist-Datei, die Befehle enthält, oder mit HTTP 200, der OK-Antwort. Der Großteil des Datenverkehrs zwischen einem Endgerät und dem MDM-Server besteht aus Plists, die hin- und hergesendet werden. Ein MDM-Server benötigt für diese Kommunikation mit dem Endgerät, aber auch über den APNs-Dienst, entsprechende Zertifikate. Hierfür gibt es zwei Arten von Zertifikaten, auf die speziell MDM-Server zurückgreifen: das APNS-Anbieterzertifikat und das APNS-Push-Zertifikat [2].

Das spezielle APNS-Anbieterzertifikat kommt zum Einsatz, um die Signierungsanforderung für ein APNS-Push-Zertifikat zu erstellen, bevor die Anforderung für ein APNS-Zertifikat an Apples Push-Zertifikatportal "identity.apple.com" gesendet werden kann. Jeder MDM-Hersteller ermöglicht es seinen Kunden, dieses Anbieterzertifikat für sein MDM-System anzufordern. Der Administrator kann damit im Anschluss sein APNS-Push-Zertifikat bei Apple selbst beantragen. Dabei handelt es sich um ein spezielles Zertifikat, das von MDM-Servern zur Kommunikation mit APNS verwendet wird, analog zum eingangs erwähnten Gerätezertifikat.

Das Generieren des Push-Zertifikats über das Apple-Portal erfordert eine Apple-ID. Bezüglich dieser ID, die für APNS-Zertifikate verwendet werden soll, gibt es einige Punkte für Sie als Administrator zu beachten. Wenn möglich sollten Sie versuchen, eine Apple-ID pro APNS-Zertifikat zu verwenden, um später Verwechslungen zu vermeiden. Ferner sollten Sie sicherstellen, dass Sie keine persönliche Apple-ID verwenden. Die Empfehlung lautet, jeweils eine durch den Apple Business Manager verwaltete Apple-ID zu nutzen.

Das im Portal generierte Push-Zertifikat muss anschließend in das MDM-System eingespielt werden. Zu beachten ist, dass dieses Zertifikat jährlich zu aktualisieren ist. Hier gewährt Apple bei Bedarf eine Karenzzeit von 30 Tagen. Verpassen Sie diesen Termin inklusive der Karenzzeit, verliert das MDM-System jegliche Kontrolle über die Endgeräteflotte des Unternehmens. Gleiches gilt, wenn Sie das Zertifikat mit einer anderen Apple ID erneuern möchten.

Mit diesem Wissen schauen wir uns nun an, wie der MDM-Server mit APNS kommuniziert, um ein vollständiges Bild zu erhalten. Der MDM-Server öffnet jetzt die Verbindung zum APNs und meldet ein "hello" [3]. APNS grüßt ebenfalls mit "hello" und sendet sein eigenes Zertifikat. Der MDM-Server prüft das Zertifikat und sendet danach das generierte APNS-Push-Zertifikat, das eben im Apple-Push-Zertifikatportal erstellt wurde. Sobald auch hier beide Seiten wissen, dass die Gegenseite vertrauenswürdig ist, tauschen diese kryptografischen Chiffren aus und beginnen eine sichere Konversation.

Bis zu diesem Zeitpunkt sind nur der MDM-Server und die Geräte mit dem APNs verbunden. Die Registrierung des Geräts am MDM selbst (Enrollment) steht noch aus. Im Rahmen der MDM-Registrierung über den Apple Business Manager (Automated Device Enrollment), als Benutzerregistrierung (User Enrollment) oder über eine App aus dem AppStore (Agend-based Enrollment) verbindet sich das Gerät mit dem MDM-Server und sendet eine Registrierungsanfrage an diesen. An dieser Stelle ist anzumerken, dass seit 2023 die Bedeutung von Agenten-Apps auf den Geräten zurückgegangen ist. Diese sind zwar nach wie vor nutzbar, wurden aber 2023 durch die Integration der zugrundeliegenden Funktionen innerhalb der Einstellungen-App, analog der Benutzerregistrierung, weitestgehend überflüssig. Es dürfte nur eine Frage der Zeit sein, bis Apple die Agenten-Apps nicht mehr und nur noch die Variante über die Einstellungen-App unterstützt.

Im Rahmen der Registrierung wird das MDM-Konfigurationsprofil auf das Gerät geladen. Nachdem das MDM-Profil auf dem Gerät installiert wurde, ist noch ein Gerätetoken zu generieren. Dabei handelt es sich um die gleiche Art von Token, die APNS auch jeder auf dem Gerät installierten Anwendung zuweist, um Push-Benachrichtigungen nutzen zu können. Diese Token sind für jedes Gerät eindeutig, entsprechen aber nicht dessen UDID. Die Token sind auch für jede Anwendung (in unserem Fall MDM) eindeutig. Der APNS erzeugt diese und sendet sie an das Endgerät. Dieses wiederum schickt den Token an den Anwendungsserver, in unserem Beispiel den MDM-Server. Es ist zu beachten, dass die Token nach wichtigen Systemereignissen wie einer Neuinstallation des Betriebssystems neu generiert werden. Nach jeder (Neu-)Generierung sendet das Gerät den Token an den entsprechenden Applikationsserver.

Das APNS generiert also diesen Gerätetoken, der auf der Kombination von Geräte-ID und MDM-Topic basiert. Sobald der MDM-Server das Token letztendlich erhalten hat, verknüpft er diesen mit dem Datensatz für das Gerät im MDM-System. Zusammen mit dem von APNS generierten Token erzeugt das Endgerät zusätzlich eine eindeutige Zeichenfolge, die als PushMagic bekannt ist. Dieser String ist in der Regel eine zufällig generierte Zeichenfolge. Wichtig ist, dass er einzigartig und sicher ist, um eine effektive Kommunikation zwischen dem MDM-Server und dem registrierten Gerät zu gewährleisten. Der PushMagic-String ist also ein wesentlicher Bestandteil, um sicherzustellen, dass die Kommunikation und die Befehle korrekt an das jeweilige registrierte Gerät gesendet werden. Der MDM-Server verwendet letztlich den Gerätetoken, um das Zielgerät für die Benachrichtigung zu identifizieren, und den PushMagic-String, um die Authentizität des Geräts zu bestätigen.

Mit dem Enrollment sind alle beteiligten Systeme in der Lage, Befehle an die verwalteten Geräte zu senden. Der erste Schritt besteht darin, dass der MDM-Server eine Benachrichtigungs-Payload mit dem Token und PushMagic des Geräts erstellt, an das er etwas senden möchte. Anschließend leitet APNS die Benachrichtigung an das Gerät weiter.

Das Device prüft, ob Topic, Token und PushMagic übereinstimmen und akzeptiert in dem Fall die Benachrichtigung. Es sendet über APNS eine Rückmeldung, dass es die Benachrichtigung erfolgreich empfangen und dekodiert hat. Als Reaktion auf die Benachrichtigung meldet sich das Gerät beim MDM an und erhält als PLIST-Datei alle Befehle oder Konfigurationseinstellungen, die das MDM für dieses bereithält [4].

Es ist wichtig zu wissen, dass über APNS keine Verwaltungsdaten fließen. Der APNS dient nur als Auslösemechanismus, um das Gerät zu veranlassen, Befehle von seinem MDM anzufordern. Der APNS ist auch aufgrund seines Verifizierungsschemas relativ sicher. Wenn eine APNS-Benachrichtigung das Zielgerät erreicht, müssen das Push-Benachrichtigungszertifikat, das Topic, der Token und der magische Push-String gültig sein. Ist einer dieser Punkte nicht gültig, weist das Endgerät die Benachrichtigung automatisch zurück.

Bei der Installation einer App auf vielen Geräten über ein MDM-System erfolgt eine Kommunikation zwischen dem MDM-System und dem APNS. Angenommen, Sie verwalten eine Flotte von 25.000 Endgeräten. Für jede Installation gibt es eine Kommunikation zum APNS. Das bedeutet, für die Installation auf allen Geräten hätte es ursprünglich 25.000 einzelne Kommunikationen gebraucht. Zusätzlich gibt es für jede Installation die Notwendigkeit, eine Rückmeldung über den Erfolg der Installation einzufordern, was weitere 25.000 Kommunikationen bedeutet.

Apple hat jedoch eine Optimierung vorgenommen. Jetzt ist es möglich, bis zu 25 Installationsanweisungen in einer einzigen Kommunikation für bis zu 1000 Geräte zu bündeln. Das reduziert die Anzahl der Kommunikationen erheblich. Für 25.000 Geräte brauchen Sie nun anstatt Tausende nur noch etwa zehn Kommunikationen. Auch wenn sich diese Anzahl gering anhört, können die Häufigkeit und das kontinuierliche Abfragen des Installationsstatus das MDM-System dennoch vor Herausforderungen stellen, vor allem bei großen Geräteflotten.

In einem herkömmlichen MDM-System ist der MDM-Server für die gesamte Logik und die daraus resultierenden Aufgaben verantwortlich. MDM-Systeme arbeiten mit diesem Push-Kommunikationsstil für jede Konfiguration und Inventarisierungsanfrage. Das bedeutet, dass ein Endgerät solange passiv bleibt, bis ein MDM-System einen Befehl sendet, zum Beispiel für eine App-Installation [5].

Erst, wenn die Push-Nachricht das Endgerät erreicht, meldet sich dieses am MDM-System an und verarbeitet die erhaltene Anweisung. Gerade das Installieren einer App kann hier einige Zeit in Anspruch nehmen. Möchte das MDM-System wissen, ob die Installationsanweisung für eine App abgearbeitet wurde, muss dieses stetig das Endgerät neu anfragen. Diese Architektur erzeugt einen erheblichen Overhead, der mit der Anzahl der Geräte zunimmt.

Die Verwaltung mobiler Devices in Unternehmen steht mit diesem Vorgehen vor komplexen Herausforderungen, insbesondere in Bezug auf Skalierbarkeit und Effizienz. Das deklarative Device-Management (DDM) stellt ein neues und durchaus revolutionäres Datenverwaltungsparadigma für MDM- Systeme (auch "imperatives Management" genannt) dar, das diese Probleme lösen möchte. Das DDM ist dabei keine neue Protokollschicht, sondern eine Erweiterung des bestehenden Mobile-Device-Management-Protokolls. DDM verhält sich im Wesentlichen umgekehrt zum bisher beschriebenen Vorgehen. Der MDM-Server gibt zwar immer noch vor, welche Anweisungen gelten. Das Endgerät kontaktiert jedoch den MDM-Server aktiv mit Änderungen und muss nicht mehr danach gefragt werden [6].

Dies wird durch das Verwenden eines deklarativen Datenmodells erreicht und umgeht damit die inhärenten Leistungs- und Skalierungsprobleme von MDM. Der deklarative Ansatz verlagert den unnötig aufwendigen Teil der Verwaltungslogik vom zentralen MDM-Server auf die Endgeräte selbst, was drei wesentliche Vorteile mit sich bringt:

1. Reduzierung des Netzwerkverkehrs: Ein effizientes Protokoll optimiert Datenübertragungen und führt zu einer signifikanten Reduzierung des Datenvolumens, das zwischen den Endgeräten und dem Verwaltungsserver fließt. Dies entlastet nicht nur das Netzwerk, sondern erhöht auch die Geschwindigkeit und Effizienz der Geräteverwaltung.

2. Entlastung des Verwaltungsservers: Ein skalierbares Protokoll ermöglicht es dem Verwaltungsserver, sich auf kritischere Aufgaben zu konzentrieren, da weniger Verarbeitung und Datenmanagement erforderlich sind. Dies führt zu einer verbesserten Leistung des Servers und einer höheren Gesamteffizienz des MDM-Systems.

3. Zeitersparnis im Verwaltungsprozess: Durch die Bereitstellung von Echtzeitinformationen direkt auf den Endgeräten können Administratoren schneller auf Änderungen reagieren und Verwaltungsentscheidungen effizienter treffen. Dies verringert die Verzögerungen im Managementprozess und ermöglicht eine schnellere Implementierung von Richtlinien und Updates auf den Geräten.

Insgesamt steigert dieser Ansatz so die Flexibilität und Reaktionsfähigkeit von MDM-Systemen erheblich, was für Organisationen, die eine große Anzahl von Geräten verwalten müssen, besonders hilfreich ist. Das deklarative Management ist dabei so konzipiert, dass es nahtlos mit dem bestehenden MDM-Protokoll koexistiert. Das bedeutet, dass MDMs eine schrittweise Einführung der neuen Funktionalitäten ohne Unterbrechung der bestehenden Funktionalitäten übernehmen können.

Mit dem DDM hält eine intelligentere Aufgabenverteilung Einzug in die Geräteverwaltung. Die Endgeräte erhalten mehr Verantwortung und Autonomie. Sie melden sich nur dann beim MDM-Server zurück, wenn es wirklich notwendig ist, was den gesamten Managementprozess effizienter und aktueller gestaltet. Für die deklarativen Richtlinien kommt dabei JSON anstelle von XML zum Einsatz. Jede Deklaration enthält einen "TYPE", der den Typ der Richtlinie identifiziert, und einen "Identifier" für eindeutige Zuweisungen. Zusätzlich enthält sie ein "ServerToken" für die Versionskontrolle und eine "Payload" mit den eigentlichen Einstellungen.

Es gibt vier Arten von Deklarationen:

1. Configurations: Diese ähneln den vorhandenen Konfigurationsprofilen und lassen sich zum Einrichten von Konten, Einstellungen und Einschränkungen verwenden.

2. Assets: Dies sind Ressourcen wie Benutzername, E-Mail-Adresse, Passwörter oder Zertifikate, die von allen Konfigurationen genutzt (referenziert) werden können. Derartige Assets lassen sich für mehrere Konfigurationen nutzen und eine Änderung wirkt sich somit automatisch auf alle verbundenen Einstellungen aus.

3. Activations: Diese sind quasi "Schablonen" für die Konfigurationen und ermöglichen es, eine komplexe Logik abzubilden, um beispielsweise zu bestimmen, wann einzelne Konfigurationen Anwendung finden. Dadurch sind Administratoren beispielsweise in der Lage, eine Reihe von Richtlinien festzulegen, die nur dann auf Geräten angewendet werden, wenn diese eine bestimmte Betriebssystemversion einsetzen. Ändert sich der Gerätestatus, ändert sich die damit verbundenen Konfigurationen. Dies stellt ein Schlüsselelement von DDM dar, da Geräte aktiv und autonom auf Änderungen reagieren können.

4. Management: Diese Art der Deklaration entspricht der heutigen Inventarisierung und dient dazu, Informationen über ein Gerät zu ermitteln.

Die Statusberichterstattung ermöglicht es einem Device, Informationen über seinen aktuellen Status zu teilen. Dadurch gestaltet sich der gesamte Verwaltungsprozess weniger bandbreitenintensiv und effizienter. Treten Änderungen auf einem Endgerät auf, melden diese sich eigenständig beim MDM-Server, ohne dass der Server das Endgerät stetig nach Aktualisierungen abfragen muss [7]. Diese Statusmeldungen können neben Geräteeigenschaften auch der Status für das Vorhandensein und die Einhaltung von Passcodes oder auch der Fortschritt von App-Installationen sein [8].

Durch die deklarative Vorgehensweise des Systems können sowohl Endgeräte als auch MDM-Server einander ihre Fähigkeiten mitteilen, was die Integration neuer Funktionen erleichtert. Dies sollte das Verfahren für zukünftige Anforderungen rüsten.

Das DDM bietet einen eleganten und effizienten Ansatz in Sachen Verwaltung mobiler Geräte. Der dezentrale Ansatz schont sowohl Netzwerkressourcen als auch Serverkapazitäten und erhöht gleichzeitig die Reaktionsfähigkeit des Systems. Damit stellt DDM einen Paradigmenwechsel im MDM-Kontext dar, der sich insbesondere für skalierende Unternehmensstrukturen als äußerst vorteilhaft erweisen dürfte. Organisationen und MDM-Entwickler haben dabei auch die Option, um ein Profil mit Deklarationen aus den Einstellungen (iOS und iPadOS) und den Systemeinstellungen (macOS) zu Testzwecken manuell zu installieren. Diese Option lässt sich nutzen, um Konten, Legacy-Profile, Pass- und Bildschirmfreigabekonfigurationen sowie Zertifikate und Identitäten zu installieren.