Vorstellung iOS BYOD und Vergleich zu Android

  • 3 Minuten zum Lesen

Apple hat eine neue Aktivierung angekündigt: User Enrollment. Diese Aktivierung soll BYOD (Bring Your Own Device) abbilden. Google hat hier meiner Meinung nach mit Work Profile Maßstäbe gesetzt. Wie sieht es also im Vergleich aus?!

User Enrollment

Auf iOS Geräten konnte man bisher COBO (Corporate Owned, Business Only) und COPE (Corporate Owned, Personally Enabled) korrekt umsetzen. Auf Wunsch auch automatisch per DEP (Device Enrollment Program), welches Ende 2019 durch Apple Business Manager abgelöst wird. BYOD ist derzeit eine MDM Aktivierung, bedeutet dass ein MDM Profil installiert wird und Admins weitreichende Befugnisse auf dem Gerät haben. Oder man setzt eine MAM-only (Mobile Application Management – only) Aktivierung ein.

Für BYOD setzt Apple nun die Aktivierung User Enrollment um. Technisch ist dies kein Multi-User Ansatz, sondern ein Multi-Account. Der Nutzer meldet sich auf dem Gerät zusätzlich zu seiner privaten auch mit seiner Managed Apple ID an. Folglich müssen Admins die eigene Domain bei Apple Business Manager (ABM) anmelden bzw den DEP Account upgraden auf ABM.
Wird das Gerät deaktiviert, wird automatisch die Managed Apple ID vom Gerät gelöscht.

Apps sind fest an eine Apple ID gebunden und können auch nur mit dieser genutzt werden. Ausgenommen sind Apps, welche auf Konten zugreifen. Diese bekommen dann über die Konten die Daten von verwalteten und nicht verwalteten Quellen.

Bei der Aktivierung wird ein Managed APFS Volumen mit eigenen Schlüsseln erstellt. Verwaltete Quellen schreiben die Daten nur in dieses Volume: App Container, Notizen, iCloud Drive Dateien, Keychain, Mail Anhänge und Bodies, Kalenderanhänge. Bei Deaktivierung wird dieses und die dazugehörigen Schlüssel gelöscht.

Das MDM Protokoll liefert bei einer User Enrollment Aktivierung keine persistenten Daten wie UDID, IMEI und dergleichen. Zur Identifikation wird ein User-Enrollment-ID genutzt und an die MDM Server gemeldet, für einen Exchange wird eine EASID erstellt. Bei einer Deaktivierung werden diese dann gelöscht und ein Gerät bekommt bei einer erneuten Aktivierungen neue IDs.

Es wird für den Admin keine Möglichkeit geben, den Gerätepasscode zurückzusetzen oder einen Remote Wipe durchzuführen. Auch die Payloads sind an sich beschränkt. So muss zum Beispiel die Second Level Domain für VPN identisch sein mit der Second Level Domain des Unternehmens.

Admins können bei User Enrollments nur IT-Richtlinien umsetzen, welche kein Supervised Gerät vorsehen.

Vergleich mit Android Enterprise Work Profile

Die neue Aktivierung für iOS Geräte ist folgerichtig. Doch in Bezug auf Android Enterprise Work Profile gibt es einen gravierenden Unterschied: Es ist basiert nicht auf Multi-User.

Dadurch hat man auf iOS Geräte einige Einschränkungen, welche man auf Android nicht hat:

  • Eine Android App kann simultan sowohl als private und als geschäftliche App genutzt werden.
  • Mit Google PlayStore for Work hat man einen eigenen App Store für geschäftliche Apps. Dadurch können geschäftliche Apps auch optional verteilt werden.
  • Das Work Profile kann globale Einstellungen umsetzten wie zum Beispiel VPN. Somit nutzt jede geschäftliche App die VPN Verbindung (solange man keine Ausnahmen definiert).
  • Man hat auf Android keine Einschränkung des Gerätezugangs wie auf iOS (nur 6-Ziffern-Pin oder komplex).
  • Auf Android gibt es keine Abhängigkeit von VPN und Domain.
  • Das Work Profile kann im Sinne von Erreichbarkeit deaktiviert werden. Somit kann der Nutzer bei Feierabend den gesamten geschäftlichen Bereich ausschalten und am nächsten Tag wieder einschalten.

Schreibe einen Kommentar