Android (N) for Work


29.07.2016 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

Android wird zunehmend auch in Unternehmen eingesetzt. Seit ein paar Versionen ist das sogar möglich, ohne dass der Sicherheitsbeauftragte dafür mit einem Fuß im Gefängnis steht. In diesem Beitrag gibt es einen Rückblick, einen aktuellen Featureumfang und eine Übersicht, was mit dem kommenden Release Android "N" möglich sein wird.

Vorgeschichte

Schon seit langem gibt es das Bestreben Android multiuserfähig zu machen. Seine Anfänge hatte das Anfang 2011 mit Android 3.x "Honeycomb". Diese Version von Android war speziell für hochauflösende Geräte - damals also Tablets - entworfen und schnell wurde der Bedarf seitens der Anwender laut mehrere getrennte UserAccounts einrichten zu können. Völlig verständlich eigentlich, da ein Gerät, das für den Wohnzimmertisch prädestiniert ist, von verschiedenen Personen genutzt wird, gleichzeitig aber hoch personalisiert sein soll. Dabei geht es nicht nur um Komfortfunktionen; beispielsweise Kindern den Zugriff auf Arbeits-, Finanz- und sonstige nicht geeignete Apps zu entziehen, macht ein Tablet erst wohnzimmertauglich.

Erst fast zwei Jahre später mit Android 4.1.2 "Jelly Bean" wurde das Benutzer-Konten Feature in Android umgesetzt, allerdings zunächst nur für Tablets. Mit Android 5.0 "KitKat" folgte dann die Umsetzung für alle Geräteklassen, die über genug Arbeitsspeicher verfügen und deren Hersteller es zulassen.

Mit Benutzerkonten ist es nun möglich, das Endgerät individuell zu nutzen. Beispielsweise Launcher, Hintergrundbild, Einstellungen und installierte Apps und deren Datenhaltung sind benutzerspezifisch. Zugriff auf das Konto lässt sich über ein Sperrmuster, PIN oder Passwort schützen.

Unternehmenseinsatz

Für den Einsatz im Unternehmen eignen sich solche Benutzerkonten aber nur bedingt. Da immer nur ein Nutzer aktiv ist, kommen Notifications über eingehende Mails nicht an, wenn man im persönlichen Nutzerprofil eingeloggt ist. Statt dem verbreiteten Smartphone-Sandwich (privates + geschäftliches Phone in der Hosentasche), hätte man ein Telefon das aber immer nur eine Rolle wahrnehmen kann.

Enterprise Features in Android findet man erstmals in Android 2.2. "Froyo". Seitdem ist es möglich, als sogenannter "Device Administrator" Richtlinien (Policies) umzusetzen, die beispielsweise festlegen, welchen Kriterien der Lockscreenschutz (Wischen, Muster, PIN, Passwort) entsprechen muss und die Remote-Lock und -wiping ermöglichen. Für die Vielzahl an Anforderungen von Unternehmen, die Sicherheit und Konfiguration der Apps betreffen, war dies aber nicht ausreichend. Von Blackberry und auch iPhones war man hier mehr gewohnt.

Bevor Google hier im Android Betriebssystem selbst nachbessern konnte entstanden herstellerspezifische Lösungen. EMM bzw. MDM-Provider wie Citrix, BlackBerry, VMware, IBM oder MobileIron lieferten proprietäre Umsetzungen von Work-Containern, in denen Enterprise Apps parallel zu privaten Apps ausgeführt und dabei stärker geschützt und administriert werden konnten. Diese Lösungen hatten aber wesentliche Nachteile, zum Beispiel Vendor-Lock-In, App-Wrapping und teilweise für den Nutzer eher mittelmäßige UX.

Samsung liefert mit KNOX eine umfassende Lösung für die Integration mobiler Endgeräte in die Unternehmensinfrastruktur. Zuvor bot Samsung mit SAFE (Samsung Approved for Enterprise) Geräte an, die erweiterte Remote Management Features boten; beispielsweise das automatische installieren von Unternehmens Apps ohne Nutzerinteraktion (silentInstall). Allerdings gab es einen Haken: Diese Lösungen waren nur auf Samsung Endgeräten möglich.

Android Lollipop

Nachdem Samsung einen Großteil der KNOX-Features an das AOSP spendete, war es Google mit Android 5.0 "Lollipop" im November 2014 möglich, grundlegend wichtige Features anzubieten, die Android für den Unternehmenseinsatz erstmals salontauglich machten:

  • Die bereits oben genannten Benutzerkonten

  • ManagedProfile - Ermöglicht die gleichzeitige Verwendung des Main/Personal-Kontos sowie eines Work-Kontos

  • Android for Work - APIs zum Administrieren von App- und Gerätefeatures im ManagedProfile

  • Device Encryption - wurde mit 5.0 verpflichtend für Hardwarehersteller

  • SE Linux im "Enforcing Mode" - schützt vor dem ungewünschten Zugriff zwischen Apps oder interaktion mit Systemdiensten

  • Modularisierung und Entbündelung von Kerndiensten - Viele der wichtigsten Apps können inzwischen unabhängig vom Betriebssystem aktualisiert und damit mit Sicherheitspatches versorgt werden. Eines der wichtigsten Module ist wohl das System WebView

  • Ein weiterer wesentlicher Bestandteil, der bereits mit Android 4.4 “KitKat” eingeführt wurde, ist verified boot. Damit kann verifiziert werden, dass das Betriebssystem in einem unmodifizierten und sicheren Zustand gestartet wurde. Analog zu Secure Boot bei Desktop PCs oder Laptops mit aktuellem UEFI Bios.

Einsatzarten

Sehen wir uns aber zunächst einmal die grundsätzlichen Arten an, wie Geräte in einem Unternehmen betrieben werden können:

COBO - Corporate owned, business only

Bei dieser Art der Nutzung "gehört" das Gerät dem Unternehmen. Nicht nur was Kosten anbelangt (Kaufpreis, Mobilfunkvertrag), sondern auch was die Berechtigungen betrifft, das Gerät remote zu managen, hat hier der MobileManager die größte Kontrolle über das Endgerät. Er ist der DeviceOwner (DO) und kann Features wie USB-Debugging, Installationen von unbekannten Quellen oder Gerätefeatures wie Mikrofon oder Lautsprecher regulieren. Gleichzeitig ist damit eine persönliche Nutzung meist ausgeschlossen oder sehr stark eingeschränkt. Der primäre Googleaccount ist ein Firmenaccount und über diesen erfolgt auch der Zugriff auf den "Google Play for Work" Appstore und die darin freigeschalteten Apps.

BYOD - Bring your own device

Smartphones sind plötzlich im Privatbesitz vorhanden und moderner als Unternehmensmobiltelefone. Deshalb gibt es Versuche auch private Telefone mit ins Unternehmen zu integrieren. Zu kämpfen hat der MobileManager hier mit einer unglaublichen Vielzahl an zu unterstützenden Hardware- und Betriebssystem-Kombinationen, verschiedenen Patchlevels und herstellerspezifischen Implementierungen. Um die nötige Isolation von Arbeitsanwendungen herzustellen, bietet Android mit dem "MangedProfile" eine Möglichkeit Arbeits-Apps getrennt von den persönlichen Apps zu betreiben. Die DPC App (DevicePolicyController; Management-Endpunkt im Mobilgerät) ist dabei lediglich ProfileOwner und hat einen schmäleren Berechtigungsumfang als der DeviceOwner.

COPE - Company owned, personal enabled

COPE entstand als Reaktion auf Probleme mit dem BYOD-Ansatz. So soll mehr Kontrolle über das Gerät und gleichzeitig die persönliche Nutzung möglich sein. Teilweise überschneidet sich dies aber schon mit den in Android enthaltenen Rechten, über die ein ProfileOwner verfügen kann. So kann ein ProfileOwner auch für das persönliche Profil festlegen, wie der Lockscreen Schutz auszusehen hat, ob die Kamera funktioniert oder welche Eingabemethoden (Softkeyboards) verwendet werden dürfen. Kontrolle über Mikrofon, Lautsprecher, Launcher-Wallpaper, Lockscreen-Nachricht, USB-Debugging oder das Installieren aus unbekannten Quellen im persönlichem bzw. Hauptprofil bleiben jedoch dem DeviceOwner vorbehalten.

Einerseits ist dies löblich im Sinne der Freiheit des Nutzers, insbesondere wenn es sich um sein privates Endgerät handelt, andererseits stellt es Firmen mit hohem Sicherheitsbedarf vor eine nicht einfach zu lösende Aufgabe. Insbesondere dann, wenn Unternehmen ihren Mitarbeitern personal-use freundliche Endgeräte zur Verfügung stellen möchten, dabei aber nicht auf umfangreiche Schutzmechanismen verzichten wollen.

Weiterhin muss man wissen, dass ein DeviceOwner noch vor Ersteinrichtung des Gerätes angelegt werden muss und DeviceOwner und ein ManagedProfile mit ProfileOwner nicht gleichzeitig möglich sind. Eine Umkehr (DeviceOwner = Unternehmen, ProfileOwner = privater Nutzer) ist unter anderem daher technisch nicht möglich. Weiterhin widersprechen die voreingestellten Berechtigungen was zwischen den Profilen ausgetauscht werden darf bzw. in welche Richtung Daten übertragen werden dürfen, diesem Ansatz.

Neuerungen mit Android N

Gleich Vorweg - auch Android N löst nicht die Probleme, die sich beim Versuch ein COPE-Model zu betreiben stellen. Es bringt aber solide Erweiterungen mit sich, die den Unternehmenseinsatz komfortabler und sicherer machen.

Bisher bekannte Änderungen finden sich hier.

Bekannte Bugs, die in der aktuellen Developer Preview 3 identifiziert, aber noch vorhanden sind (und daher hoffentlich bis zum Release behoben werden), sind hier aufgelistet.

Für DeviceOwner

  • Remote Bug Reports
    Es können nun Bugreports von Remote angefordert werden. Da in diesen aber auch persönliche Informationen enthalten sind, ist die Zustimmung des Benutzers erforderlich.
  • Datenroaming unterbinden
    Die Datenroaming Einstellung kann nun dauerhaft deaktiviert werden.
  • Remote Reboot
    Es kann ein Reboot des Geräts von Remote ausgelöst werden. Das ist insbesondere hilfreich, wenn das Gerät fest verbaut ist und kein Zugang zum Powerbutton möglich ist.
  • Prozesslogging
    DeviceOwner können auffällige Aktivitäten von Remote tracken, Informationen wie App-Ausführung, ADB-Ereignisse oder das Entsperren des Bildschirms landen zukünftig nach Aufruf von DevicePolicyManager.setSecurityLoggingEnabled() in einem eigenen Log und können abgerufen werden.
  • Wallpaper sperren
    Es ist nun möglich den Bildschirmhintergrund zu sperren, so dass der Nutzer ihn nicht mehr selbstständig ändern kann. So kann der Launcher- bzw. Lockscreen-Hintergrund zum Beispiel auf ein Firmenlogo festgesetzt werden.
  • Anpassbare Lockscreen-Nachricht
    Über DevicePolicyManager#setDeviceOwnerLockScreenInfo() lässt sich eine Lockscreen Nachricht setzen, die ggf. eine vom User definierte LockScreenInfo überschreibt. So kann der DeviceOwner Informationen wie Firmenadresse, Telefonnummer etc. anzeigen, die bei Verlust eines Gerätes für den Finder hilfreich sein können.
  • QR Code Provisioning
    Um ein Gerät im Corporate-Owned-Modus zu provisionieren, kann nun neben NFC auch ein QR-Code verwendet werden. Dies ermöglicht es Administratoren die Geräteprovisionierung inklusive einrichten der WLAN-Zugangsdaten und Download der DPC-App in einem einzigen Schritt durchzuführen.

Für ProfileOwner / ManagedProfiles

  • Work Profile Lockscreen
    ProfileOwner können nun einen getrennten Lockscreen für den Arbeitsbereich einrichten. Das Arbeitsprofil und dessen Apps sind so lange gesperrt, bis der Lockscreen erfolgreich entsperrt wurde. Es gibt APIs um ein neues Password für den Arbeitsbereich oder für das Hauptprofil vom User setzen zu lassen. Der Lockscreen des Arbeitsbereichs kann dabei anderen Passwordpolicies unterliegen als das Hauptprofil. So kann es als ausreichend erachtet werden das Hauptprofil mit einem Muster zu schützen, im Arbeitsprofil aber ein alphanumerisches Passwort mit einer Mindestlänge zu fordern. Weiterhin lässt sich der Lockscreen des Arbeitsprofils anpassen, indem eine Unternehmensfarbe und -name definiert wird, der dort angezeigt wird.
  • Arbeitsprofil abschalten
    Wenn ein ManagedProfile eingerichtet ist, können Benutzer dies nun an- und abschalten - beispielsweise am Wochenende oder im Urlaub. Wenn es abgeschaltet ist, werden sämtliche Apps dieses Profils vorrübergehend deaktiviert. Hintergrundübertragungen, Services und Notifizierungen sind währenddessen abgeschaltet, selbst die ProfileOwner / DevicePolicyManager-App ist nicht mehr aktiv. Der Nutzer wird mit einem Notification-Icon darauf aufmerksam gemacht, dass das Arbeitsprofil derzeit deaktiviert ist, Arbeits-Icons im Launcher sind ausgegraut.
  • WorkProfile ConnectionService
    ProfileOwner können eine eigene Dialer App festlegen, die auch nur Arbeitsanrufe und Arbeitskontakte anzeigt. Dazu kann ein arbeitsbezogener ConnectionService implementiert werden, der auch andere Parameter verwendet (calling accounts). Eingehende Anrufe über den Firmenaccount enthalten dann auch das Flag android.telecom.Call.PROPERTY_WORK_CALL
  • Standortbestimmung abschalten
    Benutzer können die Standortdienste selektiv für das Arbeitsprofil abschalten. Somit bleibt die private Nutzung von Standortbasierten Apps möglich, ohne den Standort dabei für Apps im Arbeitsprofil bekannt zu machen.
  • Integration der Arbeitskontakte
    ProfileOwner können Arbeitskontakte auch aus dem primären Profil heraus durchsuchbar machen. Beispielsweise könnte ein Benutzer so persönliche und Arbeitskontakte in einer Dialer- oder Kontakt-App zusammengefasst sehen.

Allgemein

  • Always-On VPN
    Im Arbeitsprofil oder im Corporate Owned Device kann nun eine Richtlinie erstellt werden, die festlegt, dass Apps nur noch über eine VPN-Verbindung kommunizieren können. Eine Kommunikation ohne die VPN-Verbindung ins Netz ist dann nicht mehr möglich. Falls dies konfiguriert ist, wird die VPN-Verbindung nach Systemstart automatisch hergestellt.
  • Apps deaktivieren
    Apps können nun temporär deaktiviert werden. Im Unterschied zu setApplicationHidden() wird die App dabei weiterhin angezeigt, allerdings ausgegraut und ist für den Nutzer nicht startbar. Dies ist beispielsweise eine gute Möglichkeit, um Backendwartungen auch im Frontend sichtbar zu machen, oder Zugriff auf Systeme nur zu bestimmten Uhrzeiten zu erlauben.
  • Darstellung aktiver Einschränkungen und Policies
    Im System-UI werden die Einstellungen, die dem Benutzer nicht mehr oder nur noch in eingeschränkter Art zur Verfügung stehen deutlicher gekennzeichnet. Neben einem "Action not allowed", können nun auch eine kurze und lange Supportnachricht definiert werden, in der beispielsweise Kontaktinformationen zum IT-Support hinterlegt werden können.
  • Angepasste Provisionierungsscreens
    Der Wizard, der bei Erstellung des DeviceOwners oder ManagedProfiles durchlaufen wird, kann nun im Aussehen angepasst werden.Über DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR kann die Firmenfarbe gesetzt werden. Über DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI kann ein quadratisches Firmenlogo eingestellt werden (hierbei sollte das URI-Schema "android.resource" verwendet werden)
  • AppRestrictions in dedizierter App managen
    Über DevicePolicyManager.setApplicationRestrictionsManagingPackage() lässt sich nun eine eigene App definieren, die Apps über das Restrictions-API konfigurieren kann. Somit lassen sich die Bereiche des DeviceManagement und AppManagement besser modularisieren
  • UserIcon sperren
    Das Icon des Userprofils kann gesperrt werden. Ein ProfileOwner kann natürlich nur das Icon des Profils sperren, das er verwaltet.
  • Hardwaremonitor
    Mit dem HardwarePropertiesManager können Geräteinfos wie die Temperatur der CPU, GPU und der Batterie, Auslastung der CPU oder Lüftergeschwindigkeiten (i. d. R. bisher bei den meisten Androidgeräteklassen nicht vorhanden) ausgelesen werden.
  • Mehrere WLAN-CA-Zertifikate
    Für eine bestehende WLAN Konfiguration können mehrere CA Zertifikate hinterlegt werden. Wenn Firmen-WLANs verschiedene CAs für unterschiedliche AccessPoints mit gleicher SSID verwenden, können diese von einem Administrator nun über WifiEnterpriseConfig.setCaCertificates() konfiguriert werden.

Fazit

Mit Android "N" wertet Google sein Betriebssystem nochmals deutlich auf, was die Verwendung im Unternehmen angeht und macht so den Einsatz für manche Firmen erst interessant. Mit Features wie "Work Profile Lockscreen", "Arbeitsprofil abschalten" und "Standortbestimmung abschalten" werden gleichzeitig die Rechte von Privatpersonen an ihrem Gerät im BYOD-Szenario gestärkt.

Eine echte Unterstützung für einen COPE-Modus, bei dem die Firma das Gerät stellt und dafür weiterreichende Rechte erlangen möchte, ohne dabei jedoch eine private Nutzung gänzlich zu unterbinden, findet man aber noch nicht. Es bleibt spannend, ob dies künftig implementiert wird.

 

 

Diesen Artikel bewerten
 
 
 
 
 
 
 
0 Bewertungen (0 %)
Bewerten
 
 
 
 
 
 
1
5
0
 

Artikel im Warenkorb:

0