Vergleich mit Android: Der Multi-User-Modus
Mit Android Q wird es nun möglich, Arbeitsprofile für Android Q per QR-Code oder einer dem iOS DEP ähnlichen Zero-Touch-Funktionalität zu aktivieren. Während der Bereitstellung eines firmeneigenen Geräts können nun Device Policy Controller Apps (DPCs) ein Work-Profil oder eine komplette Geräteverwaltung initiieren.
Android Enterprise Work Profile stellen eine Multi-User Umsetzung dar. Diese erlaubt es Android, ein paar Dinge anders zu handhaben. So können Apps unter Android in beiden "User-Kontexten" installiert werden und damit parallel als eine private und eine berufliche Version existieren. Ein Koffersymbol macht den Kontext deutlich.
Die Dual-Persona-Umsetzung hat außerdem den Vorteil, dass Anwender ihren dienstlichen Bereich zum Beispiel im Urlaub deaktivieren und am nächsten Tag wieder aktivieren können. Unter iOS gibt es diese Möglichkeit (noch) nicht.
Viele erwähnen an dieser Stelle den Google Play Store for Work und weisen darauf hin, dass es sich um einen eigenen App Store für geschäftliche Apps handelt. Unternehmen können hier eine verwaltete Version von Google Play nutzen und so geschäftlich genutzte Apps zu verteilen. Dies ist im Grunde mit dem VPP/ABM von Apple vergleichbar.
Apps, die von anderen Quellen als Google Play (oder anderen vertrauenswürdigen App-Stores) heruntergeladen werden, werden als Apps aus unbekannten Quellen bezeichnet. In Android Q können Administratoren von Arbeitsprofilen nun verhindern, dass solche Apps an beliebiger Stelle auf dem Gerät installiert werden können. Trotz dieser Einschränkung kann ein Anwender mit Gerätezugriff per Android Debug Bridge (adb) weiterhin Apps - auch aus unbekannter/nicht vertrauter Quelle - installieren.
Unter iOS kann dies komplett unterbunden werden, dafür gibt es bei iOS nur den AppStore als verlässliche Quelle beziehungsweise durch das MDM selbst verteilte Apps. Weitere AppStores, die in einer Firma durchaus existieren können, haben diese Möglichkeit nicht. Es muss somit alles über den AppStore und/oder das MDM gehen. Der Vollständigkeit halber sei gesagt, dass es natürlich auch MDM-Einstellungen im Company-Umfeld existieren, die Software aus fremder Quelle komplett erlauben. Diese Einstellungen ist jedoch nicht zu empfehlen.
OEMConfig soll MDM-Einstellungen unter Android vereinheitlichen
Bisher haben OEM-Hersteller "Plain Android" so angepasst und erweitert, dass ihre Endgeräte besser über ein MDM-System gesteuert und konfiguriert werden können. Die Hersteller von MDM-Systemen mussten diese Funktionen dann aufwändig in ihre Lösungen integrieren. Dies wird sich nun mit OEMConfig ändern. Zwar passen die Firmen weiterhin Android mit eigenen MDM-Erweiterungen an, die über die Fähigkeiten von Android Enterprise hinausgehen. Zusätzlich erstellen sie aber eine eigene OEMConfig-Anwendung, um diese neuen, selbst definierten APIs zu referenzieren und zu registrieren.
Der OEM-Hersteller lädt diese OEMConfig-Anwendung in Google Play und stellt sie so zur Verfügung. Ein Administrator einer Organisation kann nun diese App auf seinen Geräten verteilen und per App-Konfiguration ansprechen. Die App-Konfiguration übermittelt die Konfiguration an die OEMConfig-Anwendung und diese führt die Gerätekonfiguration durch. So erhält das Unternehmen sofort die neueste Version (Tag-0-Unterstützung) der referenzierten APIs, die der OEM hinzugefügt hat.
Bei OEMConfig handelt es sich um nichts anderes als eine kleine Anwendung, die vom Hersteller erstellt und vorinstalliert wird - quasi ein spezieller MDM-Client für die entsprechende Marke oder oft auch ein entsprechendes Gerät. Im Gegensatz zu iOS herrscht somit weiterhin je nach Hersteller und Device ein Unterschied in der "Mächtigkeit" von MDM-Kommandos.
Fazit
Mit iOS 13 ist Apple endlich an dem Punkt angelangt, den es sich viele Administratoren gewünscht haben. Ich bin mir sicher, dass Apple das Thema "Eine App doppelt installieren" zukünftig auch angehen wird. Im Grunde müsste Apple nur den "Bundle-Identifier" im dienstlichen Kontext ergänzen. Der Bundle-Identifier ist eine eindeutige Kennung für eine Anwendung und beginnt normalerweise mit einem Domainnamen in umgekehrter Reihenfolge der Wörter (z.B. de.computerwoche). Daran wird dann noch der Name der jeweiligen App angehängt. Apple könnte hier noch das Attribut ".managed" anfügen, um eine dienstlich genutzte App von der privaten Version zu unterscheiden. (mb)