Auf iOS-Geräten konnte man bislang lediglich firmennahe Ausgabeverfahren für Mobilgeräte wie COPE (Corporate Owned, Personally Enabled) oder COBO (Corporate Owned, Business Only) ohne Sorgenfalten umsetzen. Das wurde mit dem Device Enrollment Program (DEP), welches Ende 2019 durch Apple Business Manager abgelöst wird, auch automatisiert möglich. Die Geräte bekamen dank Volumen Purchase Program (VPP) zudem Software aufgespielt, ohne dass der Anwender das Geld vorstrecken und kompliziert rückvergütet werden musste.
Foto: GaudiLab - shutterstock.com
Für den Einsatz von BYOD (Bring your own Device), bei dem es dem Mitarbeiter freigestellt ist, sein privates Gerät zu verwenden, hatte iOS nur die oben gezeigte Geräteregistrierung vorgesehen. Das Problem dabei: Obwohl der Anwender sein Gera¨t sowohl privat als auch beruflich nutzt, wird es in Gänze administrativ verwaltet. Auch wenn diese Geräte nur selten im Betreuungsmodus (Supervised) betrieben werden, der sehr tiefgreifende administrative Vorgaben erlaubt, sind die technischen Möglichkeiten der Administratoren mit dem Datenschutz der Anwender und dem gewünschten Komfort selten oder gar nicht vereinbar. So erhält der Geräte-Admin etwa potenziell Einsicht in installierte Apps, kann die PIN-Sperre und die Verknüpfung mit einer Apple-ID aufheben, diverse Apps verbieten oder das Gerät sogar remote löschen.
Eine Alternative stellen Lösungen für Mobile Application Management (MAM) dar. Hier unterliegen nur spezifische, beruflich genutzte Apps einer Verwaltung. Damit soll sichergestellt werden, dass bestimmte Firmen-Policies eingehalten werden und sensible geschäftliche Daten nicht in falsche Hände geraten.
Auch dies ist im iOS-Umfeld nicht der Weisheit letzter Schluss. Während ein Mobile-Device-Management-System es erlaubt, die Anwendungen auf mobilen Endgeräten zwischen einem Firmenbereich (durch die Firma verteilte, Managed Apps) und einem Anwenderbereich (durch den Anwender installierte private Apps) zu unterscheiden, können MAM-Apps nur durch den Anwender selbst installiert werden. Die Trennung und Konfiguration erfolgen hier auf App-Ebene, etwa bei Microsoft-Office-Apps mit jeweils dienstlichem und privatem Umfeld. Auch der Schutz vor Datenabfluss muss in MAM-Szenarien in den jeweiligen Apps aufwändig durch die Hersteller realisiert werden. Orientiert man sich an den Microsoft Apps, gehören dazu etwa:
Steuern der Möglichkeit von Benutzern, Unternehmensdateien zu verschieben;
Konfigurieren von Einschränkungen für die Zwischenablage;
Erzwingen der Verschlüsselung von gespeicherten Daten (iOS: AES256, Android: OpenSSL128bitAES);
Remote-Zurücksetzung von Unternehmensdaten;
Erzwingen der Verwendung eines verwalteten Browsers;
Erzwingen einer PIN-Richtlinie;
Überprüfen der Geräteintegrität und -konformität (z.B. Routing/Jailbreak Detection);
Unterstützung mehrerer Identitäten.
Um keine Missverständnisse aufkommen zu lassen: Microsoft und andere Anbieter haben diese Funktionen sehr vorbildlich und umfangreich implementiert. Auch die Möglichkeit der Zwei-Faktor-basierten Anmeldung (modernAuth) durch den Microsoft Authenticator ist - meiner Meinung nach - einmalig am Markt. Er versorgt die installierten Apps mit Einmal-Kennwörtern zur Anmeldung und hält diese selbst mit einem 30 Tage gültigen Dauer-Token bereit.
Aber das Ganze führt nicht an dem eigentlichen Problem vorbei, denn nicht alle Apps stammen von Microsoft und die MAM-Apps der unterschiedlichen Hersteller sind unter einander (meist) nicht kompatibel.
iOS 13 macht BYOD massentauglich
Mit iOS 13 setzt Apple nun auf die Verwaltung per Benutzerregistrierung (User Enrollment). Es handelt sich hierbei um eine sehr tiefgreifende architektonische Veränderung, die jedem Anwender zugutekommt, der seine persönlichen Geräte verwenden möchte, um auf Arbeitsinformationen zuzugreifen. Das Interesse der Firmen nach Datensicherheit wird gleichermaßen eingehalten.
So liefert das MDM-Protokoll bei einer Aktivierung per Benutzerregistrierung keine persistente verfügbare Identifizierungsmöglichkeiten für ein Gerät, etwa Identifier wie UDID, IMEI und dergleichen, an den Administrator beziehungsweise das MDM-System. Zur Identifikation wird stattdessen eine individuelle User-Enrollment-ID bei jeder Aktivierung generiert und anschließend für die Kommunikation zum MDM-Server genutzt. Im Umfeld von Exchange ActiveSync wird ein spezieller EASDeviceIdentificer erstellt.
Bei der Aktivierung der Benutzerregistrierung legt iOS 13 ein Managed APFS Volumen mit einem eigenen abgeleiteten Verschlüsselungsschlüssel an. Verwaltete Apps legen ihre Daten im Anschluss ausschließlich auf diesem Volumen ab. Dieses ist Speicherort für:
verwaltete, der Managed-Apple-ID zugewiesene Apps;
Daten der Notizen-App;
Dokumente des Enterprise iCloud Drive;
dienstliche Schlüsselbund-Einträge;
E-Mail-Anhänge und Mail-Body (restliche Metadaten bleiben im normalen System);
Kalender-Anhänge.
Hebt der Anwender (oder Admin) die Benutzerregistrierung auf, wird der zugehörige Verschlüsselungsschlüssel von iOS 13 nachhaltig vernichtet. Das Volumen ist damit unbrauchbar und steht nicht mehr zur Einsicht zur Verfügung. Ein neuer Rollout per Benutzerregistrierung legt einen neuen Schlüssel und ein neues Volumen an.
Technisch ist dies jedoch kein Multi-User-Ansatz, sondern ein Multi-Account-Ansatz. Denn die Benutzerregistrierung erfolgt nicht auf Basis der privat persönlichen Apple-ID des Anwenders, vielmehr muss hierzu eine "Managed-Apple-ID" für ihn angelegt werden. Administratoren (und Personenverantwortliche) können dies im Apple Business Manager (ABM) vornehmen. Die Zuordnung verwalteter Apps erfolgt an diese Managed-Apple-ID. Die Eigentumsverhältnisse bleiben so immer bei der Firma.
Auf die Geräte selbst, die per Benutzerregistrierung aktiviert werden, haben Firmen nur noch geringen Einfluss. So sind Administratoren etwa nicht in der Lage, diese Devices aus der Ferne zu löschen und detaillierte persönliche Daten wie zum Beispiel installierte Apps einzusehen. Kennwortregeln können nicht mehr mit (extremer) Komplexität eigefordert werden. Auch das Entfernen einer PIN (falls der Anwender die PIN vergessen hat) geht nicht mehr. Wird eine komplexe PIN benötigt, kann der Administrator das einfordern. Die "Definition", was eine komplexe PIN ist, gibt allerdings Apple vor.
Die VPN-Konfigurationen beschränken sich auf AppVPN-Konfigurationen. Nur der Zugriff auf definierte (verwaltete) Domänen, beispielsweise über verwaltete Apps, kann ein VPN aufbauen. Ein FullVPN, bei dem der komplette Datenfluss umgeleitet wird sowie das Konfigurieren genereller Proxys, ist technisch nicht mehr möglich.. Betreuungsmodus-Konfigurationen zu nutzen ist gänzlich unmöglich.
Trotzdem können Geräteadministratoren weiterhin etwa:
dienstliche Apps und dienstliche Konten installieren und konfigurieren (siehe AppConfig);
einen Passcode im Gerät erzwingen;
Daten abfragen, die sich auf die dienstlichen Apps, Zertifikate und Konfigurationsprofile beziehen;
per-App-VPN konfigurieren.
Viele MDM-Anbieter haben hinsichtlich des Datenschutzes einiges an Auswertungen von Vornherein proaktiv bei sich eingeschränkt. Allerdings waren das nicht alle Hersteller und "technisch möglich" war viel mehr als das, was Administratoren gesehen haben. Das Vertrauensverhältnis zwischen Anwendern und Administratoren war daher oft gestört. Die Benutzerregistrierung kann das ändern.