Android hat einen globalen Anteil von rund 80%. Das ehemals für Kühlschränke entwickelte Betriebssystem ist aber längst auch im Enterprise Bereich angekommen und Google arbeitet aktiv an der Weiterentwicklung.

Auf dieser Seite werden wir alle Informationen rund um Android Enterprise und dessen Ökosystem bereitstellen.

Google Ankündigungen

Android Enteprise Ankündigungen

Kommende Android Enterprise Funktionen

Android Zertifizierungen, Bewertungen und Whitepaper

Der wichtigste Punkt zuerst: Viele denken immer noch an eine schlechte Sicherheitsbewertung von Android. Dies hat sich komplett umgekehrt:

Android Enterprise Sicherheit von Gartner bewertet.

Dazu hat Managed Google Play die ISO 27001, SOC2 und SOC3 Zertifizierung erhalten.

Android Enterprise Whitepaper

Apps vor der Veröffentlichung scannen

Im Google Play Store sollte keine Schadsoftware gelistet werden. Dazu ist Google eine Partnerschaft eingegangen und scannt Apps mit Hilfe der Partner vor der Veröffentlichung im Store: Google, ESET, Lookout und Zimperium bilden App Defense Alliance.

Android Versionen

Android ist nicht gleich Android.

Android Updates – Project Treble / Project Mainline / GKI

Android ist stark fragmentiert auf dem Markt. So haben viele Hersteller weitreichende Änderung am System implementiert. Um die Updateversorgung zu straffen, hat Google unter anderem Treble und Mainline ins Leben gerufen.

Damit Updates nicht mehr die lange Anpassungsphase auf die Hard- und Softwareanpassungen der jeweiligen Hersteller durchlaufen müssen, müssen ab Android Oreo alle Updates auf AOSP laufen:

Project Mainline hingegen wird Systemkomponenten aus dem Systembuild ziehen und in Module zusammenfassen, welche dann per Google Play Store einmal im Monat aktualisiert werden.

Dank der Vielzahl an Herstellern und dementsprechender Anzahl an Geräten hat Android mit einer starken Fragmentierung zu kämpfen. Der Kernel soll in Zukunft schneller und einfacher evtl über Play System Updates aktualisiert werden.

Was ist Android Enterprise und wie kam es dazu?!

Android ist streng genommen eine Ansammlung von Open Source Software und wurde von Andy Rubin im Jahre 2003 erdacht. Zunächst war die Software als Betriebssystem für Kameras gedacht, doch als zwei Jahre später Google das Unternehmen käuflich erstand, hatte es andere Pläne. 2008 kam das erste Smartphone mit dem Betriebssystem auf den Markt und so wurde das E-Mail Konto auch auf einem Smartphone mobil.

Microsoft Exchange hatte mit ActiveSync ein MDM light implementiert. Die Kunden nutzten dies gerne für die Verwaltung ihrer Flotten an mobilen Geräten. Schließlich war der Exchange vorhanden, warum also dann nicht die kostenlose Funktion auch einsetzen?! So konnte man Geräterichtlinien voraussetzen wie zum Beispiel ein Gerätekennwort, ob Speicherkarten zulässig sind oder ob der der Anwender die Kamera benutzen darf.

Um diese Richtlinien umsetzen zu können, wurde in Android 2.2 Froyo der Geräteadministrator eingeführt. Diese Funktion erlaubt einer Anwendung beziehungsweise des dazugehörigen Kontos diese Richtlinien einzufordern und umzusetzen.

Der Geräteadministrator und ActiveSync haben jedoch einen Nachteil:
Es fehlen komplexere Funktionen wie Anwendungs-Container und -Wrapping zum Schutz und zur Isolation von Anwendungen auf den Geräten. Besonders kritisch ist dies, wenn Mitarbeiter ihre Privatgeräte nutzen.
Des Weiteren kann der ActiveSync Server keinen Mechanismus zur Überprüfung der Geräte an sich, denn es wird im Protokoll davon ausgegangen, dass der Client vertrauenswürdig ist.

Auch EMM Systeme haben die Berechtigung des Geräteadministrators genutzt, um darüber MDM Richtlinien auf dem Gerät durchzusetzen. Ach Samsung Knox Workspace wurde mit dieser Berechtigung eingerichtet. Doch die Möglichkeiten waren sehr limitiert und es gab keine strikte Trennung von Daten im BYOD (Bring Your Own Device) oder COPE (Corporate Device Personally Enabled) Einsatz.

Mit Android 5 Lollipop kommt Android for Work.

Google reagierte und führte mit Android 5.1 Lollipop Android Enteprise, damals noch unter dem Namen Android for Work, ein. Die Funktion war für Gerätehersteller optional, mit Android 6 Marshmallow wurde die Implementierung der Lösung verpflichtend.

Android konnte schon relativ früh mehrere Benutzer und dessen Konten einbinden. Genau diese Fähigkeit wurde nun für die geschäftliche Anbindung genutzt. Die Administratorrolle hing ab da an dem geschäftlichen Nutzer und dessen geschäftlichen Google Konto. Somit kann auf Android Geräten sauber getrennt werden: Bei einer BYOD Aktivierung zum Beispiel haben der private und der berufliche Nutzer ihre komplett eigene Umgebung, dies gilt auch für Google Play Store und alle Apps. Des Weiteren kann dieselbe App einmal privat und simultan auch beruflich genutzt werden.

Ist der geschäftliche Nutzer alleine eingerichtet, spricht man von einer COBO Aktivierung (Corporate Owned Business Only). Voraussetzung war, dass das Gerät im Werkszustand aktiviert wurde. Ausgenommen ist hier noch der Samsung Knox Workspace bis zur Version 2.

Ab Android 7 Nougat wird Android Enterprise weiter ausgebaut.

Google arbeitet(e) immer weiter an möglichen Einsatzszenarien. So wird mit Android 7 Nougat der Kiosk-Modus COSU (Corporate Owned Single Use) eingeführt. Diese Aktivierung erlaubt es zum Beispiel Android Geräte auszustellen, welche dann aber nur eine vorher definierte App anzeigen. In Android 9 Pie wird die Aktivierung noch um einen Multi-User Support erweitert.

Mit Android 8 Oreo wurde eine von Unternehmen lang erwartete Aktivierung für Android Enterprise seitens Google eingeführt: COPE. Unternehmen können so Geräte bestellen und diese direkt an die Endanwender versenden lassen. Der Administrator hinterlegt im EMM System eine COPE Aktivierung und der Anwender geht zunächst vor wie bei einer COBO Aktivierung wenn er das Gerät erhält. Doch in dieser Aktivierung darf er dann seine persönlichen Konto auf dem Gerät hinzufügen.

Mit Android 9 Pie und Q hat Google aber noch mehr im System geändert. So wird nun nur noch eine einzige API angesprochen: AMAPI (Android Management API). Dies erleichtert die Verwaltung und auch die Anwender wird es freuen: alle geschäftlichen Funktionen werden nativ in Android eingebunden und sind somit leichter auffindbar.

OEMConfig gibt Geräteherstellern die Möglichkeit, spezifische Geräterichtlinien per AppConfig auf die Geräte zu verteilen. Somit muss nicht auf die EMM Hersteller gewartet werden, bis diese die Richtlinien implementiert haben.

Ab Android 11 wird der Datenschutz für persönliche Daten auf COPE Geräten gestärkt und Admins haben nicht mehr weitreichende Berechtigungen. Auch wird zwischen den Aktivierungswegen unterschieden, ob ein Gerät persönlich oder geschäftlich gekennzeichnet wird.

Diese “Reise” geht mit Android 12 weiter und es werden weitere Sicherheitsmechanismen etabliert. Android 13 erweitert die Funktionen der Management API und führt die Trennung von persönlich zu geschäftlich weiter fort und bietet für Work Profiles neue Funktionen an.

Dank der Vielzahl an Herstellern und dementsprechender Anzahl an Geräten hat Android mit einer starken Fragmentierung zu kämpfen. Google arbeitet am GKI (Generic Kernel Image), um Kernelupdates schneller und auch zentraler ohne OS Update verteilen zu können.

Aktivierungen in Android Enteprise

Samsung und Android Enterprise

Bis Knox v2.x setzte Samsung auf den Geräteadministrator, um den eigenen Work Bereich auf Geräten zu implementieren bzw diesen zu steuern. Da der Geräteadministrator abgekündigt ist, wird ab Knox v3.x Android Enterprise als technische Basis genutzt. Samsung nennt dies Harmonization.

Da man auf die eigenen erweiterten APIs nicht verzichten will, werden diese im Rahmen von Knox Platform for Enterprise (KPE) weiter angeboten:

Daraus ergibt sich aber, dass gewisse IT-Richtlinien doppelt vergeben sind. Das will Samsung abschaffen.

In Android 11 hat sich einiges geändert. So bietet Samsung zum Beispiel mit Separated Apps einen weiteren optionalen Zusatzcontainer an, basierend auf den Änderungen seitens Google:

Auch ab Android 11: Samsung wird in Android Enterprise Recommended aufgenommen:

BYOD, COBO, COPE – Wie bitte?!

BYOD – Bring Your Own Device
Private Geräte werden in die unternehmenseigene Umgebung eingebunden. Dabei haben Administratoren keinen Zugriff auf die privaten Daten.
Android Enterprise: Work Profile
Samsung KNOX 3: Profile Owner

COBO – Corporate Owned Business Only
Unternehmenseigene Geräte werden eingebunden und stellen dem Nutzer lediglich den geschäftlichen Bereich zur Verfügung. Administratoren dürfen globale IT-Richtlinien auf dem Gerät umsetzen.
Android Enteprise: Work managed device
Samsung KNOX3: Device Owner

COPE – Corporate Owned Personally Enabled
Unternehmenseigene Geräte werden eingebunden und Nutzer dürfen diese privat nutzen. Im Gegensatz zu BYOD dürfen Administratoren aber globale Geräterichtlinien umsetzen.
Ab Android 11 werden die Adminrechte auf Android 11 eingeschränkt. Weitere Informationen
Android Enterprise: Work Profile on fully managed device
Samsung KNOX3: COMP (Corporate Owned Managed Profile)

COSU – Corporate Owned Single Use
Unternehmenseigene Geräte, welche nur eine bestimmte Umgebung / App anzeigen dürfen.

Wie man BYOD, COBO und COPE aktiviert

Änderungen für COPE Aktivierung ab Android 11

Biometriedaten hinterlegen für Android Enterprise

Zero Touch und KME

Was Apple mit DEP anbietet, kann man auch von Google und Samsung bekommen: Ein Tool zum Enrollment und Bindung von Unternehmensgeräten an die eigene Firmierung. So können Geräte vom Distributor direkt an die Endanwender verschickt werden. Dieser packt sein Gerät aus, schaltet es ein, stellt eine Internetverbindung per SIM oder WiFi her und das Gerät beginnt sofort mit der Aktivierung.

Google bietet dazu das Zero Touch Portal an:

Leichter wird es ab 2021, dann können die UEM Systeme selbst die Konfiguration übernehmen:

Doch Datenschutzbeauftragte haben einen Einwand: Sind private Daten wirklich privat bei COPE Aktivierungen? Google hat reagiert und in Android 10 wird es eine Work Profile Aktivierung per Zero-Touch geben:

Samsung hat sein eigenes Set an Cloud Services. Das MassEnrollment übernimmt hier KME: Knox Mobile Enrollment.

Damit man nicht neben dem UEM noch zwei weitere Portale bedienen muss als Admin, arbeiten Samsung und Google an einer gemeinsamen Lösung:

ManagementAPI

Google hat alle Enterprise APIs zu einer zusammengeschlossen: ManagementAPI.

OEMConfig – per AppConfig IT-Richtlinien umsetzen

Bisher war man an UEM Hersteller und deren Willen und Bearbeitungszeit gebunden bis man neue IT-Richtlinien auf Geräten umsetzen kann. Wird eine neue Schnittstelle geschaffen, mussten UEM Server Hersteller erst die eigenen Produkte anpassen, zur Verfügung stellen und Administratoren mussten diese Version installieren. Dies erübrigt sich mit OEMConfig.

Dazu stellt der Gerätehersteller eine App zur Verfügung, welche dann per AppConfig mit IT-Richtlinien betankt wird und diese auf dem Gerät umsetzt.
Da man im Google Play Store for Work diesen Apps ein automatisches Update erlauben kann, hat man so einen 0Day-Support für neue IT-Richtlinien.

Samsung und OEMConfig – KSP

Samsung bietet gewisse Clouddienste an, um noch weiter reichende Policies und Anpassungsmöglichkeiten an die Kunden weitergeben zu können. Doch Dienste wie Configure können nicht mehr in das Work Profile schreiben. Daher nutzt auch Samsung die Möglichkeit von OEMConfig und bietet ein eigenes Tool an: Knox Service Plugin.

Android Enterprise Recommended

Wie soll man sich bei der Fülle der EMM und Geräteanbieter denn bitte entscheiden? Und dann gibt es da ja noch Dienstleister.

Dem ist Google entgegengekommen und hat das Android Enterprise Recommended Programm gestartet. Die in diesem Programm gelisteten Anbieter sind zu bestimmten Dienstleistungen und Services verpflichtet. So bekommen Rugged Device 5 Jahre lang Updates.

Demo und One Pager Dokumente

Google bietet eine Demo Plattform an:

Work Profile manuell löschen

Es kann vorkommen, dass nach einer Deaktivierung das Work Profile nicht gelöscht wird.

Dazu:

• ADB herunterladen und installieren
• USB Debugging in den Entwicklereinstellungen aktivieren
• Gerät per USB mit dem PC verbinden
• Folgenden Befehl zur Abfrage der User ausführen:

adb shell pm list users

• Der User, welcher nicht User 0 ist, entfernen mit (in diesem Beispiel User 10):

adb shell pm remove-user 10

Android Enterprise und Kerberos

Nativ kann Android kein SSO per Kerberos, aber die Kollegen von Hypergate können helfen:

iOS BYOD im Vergleich zu Android Enterprise

iOS und Android sind grundlegend verschieden. So baut Android auf ein Multi-User-System auf und erleichtert so die Bereitstellung eines globalen beruflichen Perimeters: Work Profile. iOS13 erhält auch einen BYOD Modus, muss sich aber Android Enterprise geschlagen geben:

Google Chrome Enterprise

Effektive Laptops mit Chrome OS für Enterprise Kunden: