Android-Arbeitsprofil: Richtlinienwirkung und BYOD-Grenzen prüfen
Die Android Enterprise Arbeitsprofil-Richtlinie in Sophos Mobile gilt für Geräte im Verwaltungsmodus Android Enterprise work profile. Sie enthält unter anderem Passwort-, Einschränkungs-, App-, Google-Play- und E-Mail-Konfigurationen. Die Richtlinie ist für BYOD relevant, aber der Name garantiert nicht, dass jede Einstellung nur das Arbeitsprofil berührt. Dieser Entwurf ordnet dokumentierte Wirkungen ein; er ist keine freigegebene Richtlinienvorlage und enthält keine empfohlenen Schwellwerte.
BYOD-Stopp: Keine produktive Zuweisung einer Löschschwelle für Fehlversuche oder Freigaben für Kontakte und Daten zwischen Arbeits- und Privatbereich ohne Datenschutz- und Datenverlustfreigabe. Backups und Wiederherstellungswege vorab prüfen, verbleibendes Risiko für private Daten ausdrücklich akzeptieren und Wirkung auf den betroffenen Android-Versionen und Geräten testen. Die Sophos-Dokumentation garantiert weder ein Rollback noch den Erhalt privater Daten.
Kurz unterscheiden: Gerätesperre (Android 11 und älter): Eine dafür verfügbare und konfigurierte Fehlversuchsschwelle kann das ganze Gerät löschen. Arbeitsprofil-Sperre: Eine dafür verfügbare und konfigurierte Fehlversuchsschwelle löscht das Arbeitsprofil. Administrative Löschaktionen sind ein eigener, oberflächenabhängiger Kontext – keine Folge dieser Fehlversuchsschwellen.
Geräte- und Arbeitsprofil-Sperre: Was wird wann gelöscht?
Password policies – Device: Die Vorgaben betreffen die Displaysperre des gesamten Geräts. Für Android 12+ beschreibt Sophos Low/Medium/High-Komplexität, dort aber kein Feld Maximum sign-in attempts. Bevor man sich auf diese Gerätesperre verlässt, SMCAND-3170 beachten. Die ältere Password policy - Device fordert bei Arbeitsprofilgeräten mit Android 12 oder höher kein Gerätepasswort an, wenn noch keines eingerichtet ist. Sophos nennt die mit Sophos Fusion Mobile Release 2024.24 eingeführte Ersatzkonfiguration für Android 12 und die installierte Sophos-Mobile-Control-Version 9.7.10339 als Voraussetzung. Daraus folgt keine bestätigte Kompatibilität sämtlicher späterer Clientversionen. Vor der Freigabe die passende Konfiguration und Clientversion sowie die tatsächliche Aufforderung und Sperrwirkung am Testgerät prüfen; die gespeicherte Richtlinie allein belegt sie nicht. Bei Android 11 und älter zeigt Sophos dieses Feld nur für Simple password, PIN or password, Alphanumeric password und Complex password, nicht für Pattern, PIN or password: Nach der konfigurierten Anzahl falscher Anmeldungen wird das Gerät gelöscht – nicht nur das Profil. Für Privatgeräte keinen Fehlversuchswert als Standard empfehlen; persönliche Backups, mögliche Datenverluste, genaue OS-/Gerätewirkung und Zustimmung vorab klären.
Für die Gerätesperre sind die Einstellungen nach Android-Version zu trennen:
- Android 12+: Minimum password complexity hat feste Regeln: No requirements setzt keine Passwortrestriktionen; Low erlaubt Muster oder PIN. Medium erlaubt eine PIN mit mindestens vier Ziffern oder ein alphabetisches beziehungsweise alphanumerisches Passwort mit mindestens vier Zeichen. High erlaubt eine PIN mit mindestens acht Ziffern oder ein alphabetisches beziehungsweise alphanumerisches Passwort mit mindestens sechs Zeichen. Nur bei Medium und High sind PINs mit wiederholten oder geordneten Folgen ausgeschlossen, etwa
4444,1234,4321oder2468. Diese Stufen sind keine frei konfigurierbaren Legacy-Zählfelder. - Android 11 und älter: Unter Password type verlangt Pattern, PIN or password eine Displaysperre mit Muster, PIN oder Passwort ohne zusätzliche Einschränkungen. Simple password verlangt mindestens einen Buchstaben; Ziffern sind erlaubt. PIN or password erlaubt PIN oder Passwort; Alphanumeric password und Complex password verlangen sowohl Buchstaben als auch Ziffern.
- Nur bei den vier zuletzt genannten Typen erscheinen die gemeinsamen Felder: Minimum password length legt die Mindestzeichenanzahl fest. Maximum idle time before password prompt sperrt das unbenutzte Gerät nach der konfigurierten Zeit; das Passwort entsperrt es wieder. Das Gerät kann eine kürzere Zeit erzwingen. Maximum password age in days verlangt einen Wechsel im angegebenen Intervall von 0 bis 730 Tagen; 0 bedeutet, dass kein Wechsel erforderlich ist. Password history legt fest, wie viele zuvor verwendete Passwörter Sophos Mobile speichert; beim Festlegen eines neuen Passworts dürfen diese nicht wiederverwendet werden. Die oben beschriebene destruktive Grenze von Maximum sign-in attempts bleibt im selben Vier-Typen-Gate.
- Nur Complex password zeigt zusätzlich sechs getrennte Mindestzählfelder: Minimum number of letters, Minimum number of lowercase letters, Minimum number of uppercase letters, Minimum number of non-alphabetic characters, Minimum number of digits und Minimum number of special characters. Sie bestimmen jeweils die Mindestanzahl von Buchstaben, Kleinbuchstaben, Grossbuchstaben, nicht-alphabetischen Zeichen, Ziffern und Sonderzeichen.
Password policies – Work profile: Das Entsperrpasswort gehört zum Arbeitsprofil. Maximum sign-in attempts wird bei Simple password, PIN or password, Alphanumeric password und Complex password angezeigt, nicht bei Pattern, PIN or password oder Weak biometric recognition. Nach der dort konfigurierten Anzahl falscher Anmeldungen wird das Arbeitsprofil gelöscht, einschliesslich seiner Apps und Daten. Die tatsächliche Verfügbarkeit einzelner Einstellungen hängt auch von Gerät und Android-Version ab; Sophos verweist auf die Kennzeichnungen in Mobile Admin. Wiederherstellung von Arbeitsdaten und erneute Registrierung vorab planen; dies ist weder ein Geräte-Reset noch eine folgenlose Sperre.
Für die Arbeitsprofil-Sperre bietet Password type sechs Optionen:
- Pattern, PIN or password: Muster, PIN oder Passwort ohne zusätzliche Einschränkungen.
- Simple password: Passwort mit mindestens einem Buchstaben; Ziffern sind erlaubt.
- PIN or password: PIN oder Passwort.
- Alphanumeric password und Complex password: Passwort mit Buchstaben und Ziffern.
- Weak biometric recognition: schwache biometrische Verfahren wie Gesichtserkennung zum Entsperren des Arbeitsprofils. Sophos vergleicht deren Sicherheit mit einer dreistelligen PIN: Der englische Text nennt mögliches unberechtigtes Entsperren in einem von 1000 Versuchen, der deutsche ungefähr 1000 erforderliche Versuche. Das ist eine dokumentarische Einordnung, keine garantierte Erfolgszahl oder am Zielgerät getestete Wahrscheinlichkeit.
Nur bei Simple password, PIN or password, Alphanumeric password und Complex password erscheinen neben Maximum sign-in attempts die folgenden Felder: Minimum password length für die Mindestzeichenanzahl; Maximum idle time before password prompt für das Sperren des unbenutzten Arbeitsprofils, das per Passwort wieder entsperrt wird (das Gerät kann eine kürzere Zeit erzwingen); Maximum password age in days für den Wechsel nach 0 bis 730 Tagen (0: kein Wechsel erforderlich); Password history für die Anzahl gespeicherter früherer Passwörter, die beim Festlegen eines neuen Passworts nicht wiederverwendet werden dürfen. Nur Complex password ergänzt sechs getrennte Mindestzählfelder: Minimum number of letters, Minimum number of lowercase letters, Minimum number of uppercase letters, Minimum number of non-alphabetic characters, Minimum number of digits und Minimum number of special characters – für Buchstaben, Kleinbuchstaben, Grossbuchstaben, nicht-alphabetische Zeichen, Ziffern und Sonderzeichen. Diese Felder betreffen das Arbeitsprofil, nicht die geräteweite Displaysperre.
Administratives Offboarding:
- Sophos Mobile Admin: Ein kompletter Remote-Wipe ist für Arbeitsprofilgeräte nicht verfügbar. Wipe Android work profile entfernt das Arbeitsprofil samt Apps und Daten; danach zeigt Mobile Admin das Gerät als Unenrolled. War das Profil bereits vom Nutzer entfernt, kann das Gerät den Auftrag nicht mehr empfangen.
- Sophos Fusion Admin: Die dort Wipe genannte Aktion entfernt bei Arbeitsprofilgeräten laut Sophos nur das Profil. Auch der Android-Task-Bundle-Wipe hat eine profilspezifische Ausnahme. Beides ist keine Folge der Fehlversuchsschwelle der Gerätesperre.
Vor destruktiven Aktionen Oberfläche, Verwaltungsmodus, Task-Typ und Zielgerät mit dem Offboarding-Verantwortlichen klären; der Aktionsname garantiert keinen Erhalt privater Daten.
Eine vollständig verwaltete Android-Enterprise-Geräteverwaltung ist ein anderer Modus: Bei deren Abmeldung beschreibt Sophos einen Werksreset. Das ist kein BYOD-Arbeitsprofil-Standard.
Separate Compliance-Richtlinie: Diese Gerätekonfiguration ist keine Compliance-Richtlinie. Unabhängig zugewiesene Compliance-Regeln können über Deny email E-Mail-Zugriff verweigern (nur bei konfigurierter Verbindung zum Sophos Mobile EAS-Proxy verfügbar) oder ein Task-Bundle übertragen; Sophos warnt, dass falsch konfigurierte Bundles Geräte löschen können. Die allgemeine Compliance-Aktionsübersicht beschreibt Lock container für Android Enterprise als Sperre aller Apps mit sechs Ausnahmen; die gesonderte Aussage zu deaktivierten Apps betrifft ausdrücklich vollständig verwaltete Geräte. Für Arbeitsprofilgeräte beschreibt Sophos dagegen unter Set container access / Auto mode bei Verletzung einer Regel mit Lock container die Sperre des Arbeitsprofils und seiner Apps und Benachrichtigungen. Ob die Compliance-Aktion private Apps auf einem konkreten BYOD-Arbeitsprofilgerät sperrt oder sie nutzbar bleiben, ist damit nicht belegt. Auswirkungen auf private Apps des konkreten Arbeitsprofilgeräts vor einer Einwilligung und Durchsetzung prüfen. Die oben genannte Fehlversuchs-Löschfolge ist keine pauschale Compliance-Massnahme. Vor einem BYOD-Pilot die der Gerätegruppe zugewiesenen Regeln, Aktionen und Bundles separat mit den Zuständigen prüfen – hier keine automatische Behebung oder sichere Baseline ableiten.
Einschränkungen: Datenfluss statt pauschal «nur Arbeit»
Restrictions wird beim Anlegen der Arbeitsprofil-Richtlinie automatisch hinzugefügt und lässt sich nicht entfernen. Vor einer Änderung dokumentieren, welche Richtung der Datenfluss hat, wer betroffen ist und wie die Änderung beobachtet und zurückgenommen werden soll.
Zwischenablage und Weblinks
Allow work clipboard in personal apps erlaubt Kopieren von Arbeit nach privat; Kopieren von privat nach Arbeit bleibt laut Sophos immer möglich. Allow opening web links in personal apps erlaubt Öffnen von Arbeitslinks im privaten Browser. Beide Optionen brauchen eine Datenfluss- und Datenschutzentscheidung. Die gerichtete Arbeitsprofil-Freigabe ist nicht die ältere Kombination aus Zwischenablage-Hauptschalter und gemeinsamer beziehungsweise app-eigener Zwischenablage.
Kontakte und Anrufe
Allow work contact info for personal calls erlaubt der privaten Telefon-App, bei eingehenden Anrufen von Arbeitskontakten den Anrufernamen anzuzeigen. Das ist eine Freigabe über die Arbeitsprofil-Grenze hinweg.
Bluetooth-Anruferanzeige
Allow work contact info for Bluetooth devices erlaubt verbundenen Bluetooth-Geräten, bei eingehenden privaten Anrufen von Arbeitskontakten den Anrufernamen anzuzeigen. Die Einstellung steuert weder Bluetooth-Verbindungen noch einzelne Bluetooth-Profile; einen Bluetooth-Hauptschalter oder solche Profilsteuerungen führt die hier geprüfte Arbeitsprofil-Dokumentation nicht auf.
Kontaktsuche
Allow searches of work contacts in personal profile erlaubt der privaten Telefon-App, bei der Suche nach Anrufernamen auch Ergebnisse aus den Arbeitskontakten einzubeziehen. Wie die beiden Anruferanzeigen ist dies keine rein interne Arbeitsprofil-Einstellung.
Gerätesperre
Allow Smart Lock erlaubt das Aktivieren von Smart Lock, das das Gerät in bestimmten Situationen automatisch entsperrt. Die Einstellung betrifft die Gerätesperre und wird bei konfigurierter Arbeitsprofilsperre ignoriert. Allow unlocking device by fingerprint erlaubt die Geräteentsperrung über den Fingerabdrucksensor; das ist getrennt von Profil- oder App-Authentisierung.
Ortung
Allow location services regelt die Weitergabe des Gerätestandorts an Arbeitsprofil-Apps und -Dienste. Wird die Option deaktiviert, werden laut Sophos Ortungsdienste ausgeschaltet; Nutzer können sie nicht selbst wieder einschalten, und Sophos Mobile kann das Gerät nicht finden. Auswirkungen auf private Apps und Rücknehmbarkeit am konkreten Testgerät prüfen, nicht pauschal behaupten.
Screenshots
Allow screen capture erlaubt Benutzern Screenshots von Apps, die im Arbeitsprofil installiert sind. Daraus keine Aussage über Screenshots privater Apps ableiten.
Zertifikate
Allow user to configure credentials erlaubt Benutzern, Zertifikate im Arbeitsprofil zu installieren oder zu deinstallieren. Das ist keine Passwortmanager-Einstellung und ersetzt keine Zertifikatsbereitstellung.
Konten
Allow managing accounts erlaubt Benutzern, Konten im Arbeitsprofil hinzuzufügen oder zu entfernen; das ist nicht die Bereitstellung eines Exchange-Kontos über die Richtlinie. Separate ältere Felder für Mehrbenutzerbetrieb, Hinzufügen von E-Mail-Konten mit Ausnahme für richtlinienerstellte Konten, Entfernen des Google-Kontos und automatische gegenüber manueller Synchronisierung sind im hier geprüften Arbeitsprofil-Katalog nicht einzeln aufgeführt. Deren Ausnahmen und geräteweiten Wirkungen nicht übertragen.
VPN
Allow VPN erlaubt Benutzern VPN-Verbindungen für Apps im Arbeitsprofil. Daraus keine Freigabe oder Sperre des gesamten Geräteverkehrs ableiten; die VPN-Konfiguration separat prüfen.
Kamera
Allow camera erlaubt Apps im Arbeitsprofil den Kamerazugriff; Laufzeitberechtigungen bleiben ein eigener Prüfpunkt. Der hier geprüfte Arbeitsprofil-Katalog enthält weder ein separates Sperrbildschirm-Kamerafeld noch dessen ältere Abhängigkeit vom Kamera-Hauptschalter. Daraus keine geräteweite Kamera- oder Sperrbildschirm-Sperre ableiten.
App-Installation
Ist Allow installing apps from unknown sources deaktiviert, können Benutzer Apps im Arbeitsprofil nur aus Google Play installieren, nicht aus unbekannten Quellen oder über Android Debug Bridge (ADB). Das ist nicht die Startblockade von App Control und belegt keine vollständige USB-/ADB-Sperre. Allow debugging erlaubt Benutzern, Debugging-Funktionen in den Android-Entwickleroptionen einzuschalten; die ältere Sony-Kopplung ab Enterprise API Level 9 an sämtliche Entwickleroptionen ist hier nicht beschrieben.
Hersteller-System-Apps
Enable vendor-specific system apps macht solche Apps, etwa Samsung Kalender, im Arbeitsprofil verfügbar. Das belegt keine App-Bereitstellung oder Gleichwertigkeit mit älteren Herstellerfunktionen. Die ältere Knox-Einstellungsvoraussetzung sowie Aktivierungssperre, S Beam, S Voice und «Teilen über» sind in diesem Arbeitsprofil-Katalog nicht als entsprechende Felder dokumentiert.
App-Entfernung
Wird Allow app uninstall abgeschaltet, können auch Administratoren Arbeitsprofil-Apps nicht über Sophos Mobile deinstallieren.
App-Verwaltung
Ist Allow managing apps deaktiviert, können Benutzer Arbeitsprofil-Apps nicht deinstallieren, deaktivieren oder beenden, weder App-Cache noch App-Daten löschen und die Einstellung Open by default nicht löschen. Die separate Einstellung Allow app uninstall hat die oben genannte zusätzliche Grenze für Administratoren; diese nicht auf alle App-Verwaltungsaktionen übertragen.
Verwaltetes WLAN
Allow sharing of managed Wi-Fi connections gilt erst ab Android 13. Ist die Option deaktiviert, können Benutzer von Sophos Mobile konfigurierte WLAN-Verbindungen nicht mit anderen Geräten teilen. VPN-/WLAN-/Zertifikatskonfigurationen separat prüfen.
Google-Sicherheitsscans
Allow disabling Google security scans erlaubt Benutzern, Scan device for security threats unter Settings > Google > Security > Google Play Protect auszuschalten. Das beschreibt die Freigabe, ist aber keine Empfehlung zum Abschalten.
Supporthinweise
Short message ist ein Unternehmenssupporttext, der bei ausgeschalteter Funktion angezeigt wird; über 200 Zeichen kann er abgeschnitten werden. Long message ergänzt ihn über More details und erscheint auch auf der Android-Seite Device administrator für Sophos Mobile Control.
Allow Android Beam erlaubt das Teilen von Inhalten über Android Beam, das nur in Android 9 und älter verfügbar ist. Die Einstellung gilt nicht für Quick Share oder andere Sharing-Technologien und ist keine allgemeine Freigabe oder Sperre des Datenteilens. Der ältere Startschalter für Samsung S Beam ist ein anderes Feld; weder er noch Android Beam belegt eine Quick-Share-Steuerung. Android Beam deshalb nicht als moderne Pflichtkontrolle behandeln.
Diese Feldbedeutungen stammen aus dem hier geprüften dokumentierten Arbeitsprofil-Katalog. Nicht aufgeführte ältere Felder sind damit nicht auf jedem OS, Herstellergerät oder Tenant ausgeschlossen; die tatsächliche Verfügbarkeit bleibt separat zu prüfen.
Weitere Einstellungen und ihre Grenzen
Vor einer Zuweisung jeweils fragen: Was wirkt nur im Arbeitsprofil, und was muss separat bereitgestellt oder geprüft werden?
- App Control: Im Feld App group die vorgesehene gespeicherte Android-App-Gruppe auswählen. Deren Mitglieder sind die Apps, die nicht gestartet werden dürfen. Den Ablauf zum Anlegen der Gruppe zeigt der nächste Abschnitt. Das ist weder App-Installation noch eine belegte Sperre sämtlicher privater Apps; Mitgliedschaft und Startverhalten am Testgerät prüfen. Vor einer gezielten Sperre von Chrome die WebView-Abhängigkeiten der Arbeits-Apps prüfen. Sophos beschreibt in SMCAND-2931 ein Arbeitsprofil-Szenario ab Android 8, in dem die interne WebView-App standardmässig deaktiviert ist und erst durch aktiviertes Chrome aktiviert wird. Abhängige Apps können sonst nicht mehr funktionieren. Dieses Fehlerbild ist keine Aussage über jedes heutige Gerät oder jede spätere Android-Version; die betroffenen Apps am vorgesehenen Testgerät prüfen.
- App permissions: Nur Laufzeitberechtigungen von Arbeits-Apps sind steuerbar. Unter Default response for runtime permission requests fordert Prompt eine Benutzerfreigabe an, Auto-accept gewährt automatisch innerhalb der Plattformgrenzen und Auto-deny verweigert automatisch. Auto-accept/Auto-deny verhindert spätere Änderungen durch Nutzer. Unter App-specific runtime permissions mit Add eine App auswählen und jede Berechtigung einzeln konfigurieren: Selectable lässt Benutzer die Berechtigung ändern, Granted gewährt sie und Denied verweigert sie. Für beide Erteilungsoptionen gilt: Ab Android 12 kann die Verwaltung Standort, Kamera, Mikrofon, Körpersensoren und körperliche Aktivität nicht stellvertretend erteilen, wohl aber verweigern. Accessibility und Akku-Optimierung können weiterhin Nutzeranfragen auslösen. Voreinstellung und App-Ausnahmen je OS-Version prüfen.
- App Protection: Ein gemeinsames Passwort für ausgewählte Arbeits-Apps ist kein vollständiger Zugriffsschutz: Zugriffe über andere Apps/Systemfunktionen und Mehrfenstermodus können ohne diese Abfrage erfolgen. Benutzer legen das gemeinsame Passwort beim ersten Öffnen einer geschützten App fest. Password complexity bestimmt Anforderungen wie Mindestlänge und erforderliche Zeichen, ohne daraus eine bestimmte Kombination abzuleiten. Grace period in minutes ist der Zeitraum, in dem Benutzer eine geschützte App ohne Passwort öffnen können, nachdem sie eine geschützte App geschlossen haben. Allow fingerprint authentication erlaubt den Fingerabdruck anstelle des Passworts, nicht als zweites Pflichtmerkmal. Die unter App group ausgewählte gespeicherte Android-App-Gruppe bestimmt die geschützten Apps; für die Anlage den nächsten Abschnitt wiederverwenden und Mitgliedschaft sowie App-Identität prüfen. Die vorhandenen Add configuration/Edit/Save-Schritte im Freigabeabschnitt gelten auch für App Protection. App-Gruppe, Schonfrist und alternative Zugriffswege vor Einsatz testen. Falls Sony-Small-Apps im Testumfang vorkommen, diese Overlay-Apps gemäss SMCAND-2927 nicht als durch Sophos Mobile Control oder App Protection schützbar beziehungsweise kontrollierbar zusichern.
- Google Play: Available apps steuert den Zugriff im Play Store des Arbeitsprofils: Approved apps from managed Google Play beschränkt ihn auf für die Organisation genehmigte Apps; Apps from Google Play erlaubt dieselben Apps wie auf nicht verwalteten Geräten. Auto update apps bietet vier Optionen: Over any network aktualisiert automatisch über WLAN oder mobile Daten; Over Wi-Fi only nur bei WLAN-Verbindung; Don’t update apps automatically schaltet automatische Updates aus; Use device setting lässt Benutzer automatische Updates im Play Store einstellen. Freigabe, Bereitstellung und Entfernung von Apps sind getrennte Abläufe.
- Password services: Passwortmanager werden nur im Arbeitsprofil eingeschränkt. Unter Mode erlaubt Allow nur Manager aus der in App group ausgewählten Android-App-Gruppe; Block erlaubt alle verfügbaren Manager ausser den ausgewählten. Die Gruppe muss die vorgesehenen Passwortmanager enthalten; den nächsten Abschnitt zur Anlage wiederverwenden und Mitglieder sowie Identität prüfen. Allow system apps ist optional und nur bei Allow verfügbar: Es erlaubt zusätzlich die Standard-Passwortmanager des Geräteherstellers, nicht sämtliche System-Apps. Soll nur dieser Hersteller-Standard zulässig sein, Allow und Allow system apps wählen und unter App group keine Gruppe auswählen (Feld leer lassen, nicht eine Gruppe ohne Mitglieder wählen). Das garantiert keinen vorhandenen Hersteller-Manager. Vor restriktiven Listen Zugang und Wiederherstellung prüfen.
- Email account: Sophos konfiguriert ein Exchange-Konto in Gmail im Arbeitsprofil. Eine verwaltete Konfiguration der Gmail-App steht in neueren Sophos-Mobile-Versionen wegen des Konflikts mit Email account nicht zur Verfügung. Bereits vorhandene ältere verwaltete Gmail-Konfigurationen haben Vorrang, selbst wenn leer. Platzhalter benötigen Exchange-Login und E-Mail-Adresse in Sophos Fusion; für Gmail mit OAuth muss Chrome im Arbeitsprofil installiert sein. Vor der Bereitstellung die Felder des zugewiesenen Benutzers in Sophos Fusion unter My Environment > Users & Groups > Users > Summary > Edit prüfen: Email Address und Exchange Login, danach bei autorisierten, bearbeitbaren Änderungen Save. Der generell optionale Exchange Login ist für die hier verwendeten Platzhalter erforderlich. Bei AD-importierten Konten Kontodaten nicht im generischen Editor ändern, sondern die Verzeichnisverantwortung einschalten; daraus keine pauschale Editiersperre für alle Entra-ID-Benutzer ableiten. Nach einer Änderung des Exchange-Logins durch die ADSync Utility vor der Bereitstellung den Fusion-Wert mit dem tatsächlichen Mobile-Benutzerobjekt vergleichen. Die historischen Pfade People und Mobile > People sowie das Literal
$usernamestammen aus SMCSRV-15474; sie sind nicht die aktuelle Fusion-Benutzerführung. Den Mobile-seitigen Zugriff separat validieren, nicht aus dem Fusion-Pfad ableiten.$USERNAMEund$EMAILADDRESSsind Managed-App-Tokens,%_USERNAME_%und%_EMAILADDRESS_%Richtlinien-Tokens; diese nicht mit$usernameaustauschen. Laut SMCSRV-15474 kann Mobile den alten Wert behalten und dadurch falsche Platzhalterwerte übertragen. Bei abweichenden Werten die Bereitstellung stoppen und mit den Zuständigen klären. Sophos beschreibt einen wöchentlichen Abgleich zu tenantabhängigen Zeitpunkten, keine garantierte Behebungsfrist. Auch die Rücknahme ist begrenzt: Laut SMCAND-2929 bleibt ein übertragenes Exchange-Konto im Arbeitsprofil, wenn die Richtlinie entfernt wird. Eine andere Email-Konfiguration kann die bisherige ersetzen; das Konto selbst lässt sich laut diesem Fehlerbild nur durch Entfernen des gesamten Arbeitsprofils entfernen. Die oben genannte Vorrangregel für ältere Gmail-Konfigurationen bleibt dabei zu beachten. Dies ist keine Freigabe zur Profilentfernung; diese bleibt ein separat genehmigter, destruktiver Offboarding-Fall mit Verlust der Arbeitsprofil-Apps und -Daten. Den Cloud-Endpunkt, EAS-Kompatibilität und Zertifikatsprüfung gesondert mit der Mail-Verantwortung klären. Exchange Online akzeptiert keine Basic-Authentifizierung für EAS; die Sophos-Auswahl Basic bzw. Allow all certificates ist keine Freigabe, diese als Workaround zu nutzen.
Die Felder von Email account vorab mit der Mail-Verantwortung abstimmen:
| Feld | Bedeutung / Vorprüfung |
|---|---|
| Account name | Name des Kontos. |
| Server name | Für die weltweite Microsoft-365-Cloud outlook.office365.com; andere Clouds separat prüfen. Bei Exchange Server die eigene Server-URL verwenden, mit Sophos Mobile EAS-Proxy stattdessen dessen URL. |
| User | Anmeldename: bei Exchange Online gewöhnlich die E-Mail-Adresse, über %_EMAILADDRESS_% die Adresse des zugewiesenen Benutzers; bei Exchange Server über %_USERNAME_% dessen Exchange Login. Nur wenn ein Domänenpräfix erforderlich und der Domänenname nicht bereits im Exchange Login enthalten ist, <domain>\%_USERNAME_% verwenden. |
| Email address und Sender | E-Mail-Adresse des Kontos beziehungsweise Absendername. In beiden Feldern wird %_EMAILADDRESS_% durch die E-Mail-Adresse des zugewiesenen Benutzers ersetzt. |
| Default email signature | Standardsignatur für E-Mails. |
| Authentication | Modern authentication nutzt OAuth 2.0; Basic authentication Benutzername und Passwort; Basic and modern authentication den von Exchange unterstützten Typ. Die Auswahl legitimiert keinen Basic-Fallback für Exchange Online. |
| Synchronization period | Nur E-Mails innerhalb des gewählten Zeitraums werden in den Geräte-Posteingang synchronisiert. |
| SSL/TLS und Client certificate | SSL/TLS aktivieren, damit SSL oder TLS die Verbindung nach Serverunterstützung sichert; das Client-Zertifikat dient der Verbindung zum Exchange-Server. Zertifikatsprüfung nicht durch Allow all certificates umgehen. |
Die Richtlinien-Platzhalter werden bei der Zuweisung aus dem zugewiesenen Benutzer befüllt: %_EMAILADDRESS_% aus Email Address, %_USERNAME_% aus Exchange Login. Kontoname, Signatur und Tokenwerte vor der genehmigten Bereitstellung prüfen; gespeicherte Felder belegen keine erfolgreiche Anmeldung.
Android-App-Gruppe für App Control anlegen
Eine App-Gruppe ist eine Liste ausgewählter Apps für Richtlinien. Die folgenden englischen UI-Bezeichnungen entsprechen der dokumentierten Oberfläche; der Ablauf wurde nicht im Zieltenant ausgeführt.
- Unter App groups die Plattform Android wählen und auf Create app group klicken. Auf Edit app group einen eigenen Gruppennamen eingeben, zum Beispiel
BYOD-Test-Startblockade, und Add app öffnen. Der Beispielname ist frei wählbar und bezeichnet keine empfohlene Sperrliste. - Unter App list eine App aus der Liste der aktuell auf verwalteten Geräten installierten Apps auswählen. Für die manuelle Eingabe der App-Details stattdessen Custom wählen. Diese Inventarliste belegt keine Sichtbarkeit privater Apps.
- Bei Custom im Feld Link die URL der App in Google Play eintragen. Obtain link öffnet Google Play; dort die Seite der vorgesehenen App aufrufen und deren Link kopieren. Nach dem Einfügen mit Get data die Felder App name und Identifier automatisch ausfüllen lassen.
- App name ist ein eindeutiger Name zur Identifikation der App, Identifier ihre interne Kennung. Für Apps aus Managed Google Play für Android Enterprise muss vor dem Paketnamen das Präfix
app:stehen. Vor dem Hinzufügen prüfen, ob Link, Name und Kennung zur vorgesehenen App gehören. - Mit Add die ausgewählte oder manuell erfasste App hinzufügen. Für weitere Mitglieder die Schritte wiederholen und die Gruppe mit Save speichern.
Danach lässt sich die gespeicherte Gruppe im oben beschriebenen Feld App group von App Control auswählen. Diese Schritte beschreiben eine App-Liste, keine App-Bereitstellung. Eine Installationsverhinderung oder geräteweite Sperre ist durch die dokumentierte Startblockade nicht belegt. Nach dem Speichern der Richtlinie gelten weiterhin die Freigabe- und Geräteprüfungen im nächsten Abschnitt.
Freigabe nur nach Prüfung am Testgerät
Verwaltungsmodus, Android-Version, Geräte-/Herstellerverhalten, Sophos-Edition/Tenant, Zielgerät und -gruppe sowie separate Compliance-Regeln erfassen. Vor jeder Änderung bisherige Richtlinie, Einstellungen, Version und Zuweisung für den betroffenen Testumfang festhalten; Backups und Wiederherstellungswege prüfen. An einem einwilligenden, entbehrlichen Testgerät mit persönlichen Testdaten die Zustellung und Wirkung beobachten.
Eine Richtlinie für Android-Enterprise-Arbeitsprofile wird unter Policies > Android > Create als passender Richtlinientyp angelegt. Auf Edit policy einen Namen und eine Beschreibung eingeben. Mit Add configuration die benötigten Konfigurationen hinzufügen und jeweils auf deren Namen klicken, um die Einstellungen zu bearbeiten. Sind alle erforderlichen Konfigurationen hinzugefügt und bearbeitet, die Richtlinie mit Save speichern. Diese UI-Schritte sind dokumentiert, aber nicht im Zieltenant geprüft. Erst nach Freigabe gezielt einem ausgewählten Testgerät oder einer Testgruppe zuweisen: Unter Policies > Android das blaue Dreieck neben der Richtlinie öffnen, Assign wählen, auf Select devices das einwilligende Testgerät oder über Select device groups die freigegebene Testgruppe auswählen und mit Finish abschliessen. Vor dem Pilot das bereits verbundene Android-Enterprise-Unternehmenskonto und den Registrierungsmodus unter Setup > Google setup > Android Enterprise kontrollieren; fehlt die Verbindung, die Einrichtung separat übergeben. Die für den Pilot aktuellen Sophos-Mobile-Control-Anforderungen prüfen, nicht die möglicherweise abweichenden Intercept-X-Anforderungen als Nachweis für App Protection verwenden. Android Go ist nicht unterstützt; allgemeine Control-Unterstützung ist kein App-Protection- oder Fingerabdruck-Versprechen. Eine Konsolenzuweisung allein belegt keine Wirkung am Gerät: Verbindung/Synchronisation abwarten und Richtlinienversion sowie Status am Zielgerät prüfen, in Sophos Fusion gegebenenfalls getrennt für Google API und MDM-Agent. Profilentfernung nur als getrennten destruktiven Offboarding-Fall planen.
Rücknahme vorab festlegen: Eine Arbeitsprofil-Richtlinie lässt sich nicht über Uninstall policy deinstallieren; stattdessen die Richtlinie anhand der dokumentierten vorherigen Einstellungen aktualisieren oder eine andere zuvor geprüfte Richtlinie zuweisen. Änderungen an diesem Richtlinientyp werden bei der nächsten Verbindung des Geräts mit Sophos Mobile synchronisiert, nicht über den Update devices-Pfad für ältere Android-Geräterichtlinien. Nach dem Verbindungsereignis Zuweisung, Version, Komponentenstatus und tatsächliches Verhalten am Gerät erneut prüfen. Bleibt die Verbindung aus, meldet eine Komponente einen abweichenden Status oder bleibt die Wirkung bestehen, Rücknahme nicht als abgeschlossen melden und keine produktive Zuweisung vornehmen. Eine Richtlinienänderung holt bereits in den Privatbereich kopierte Daten nicht zurück und stellt gelöschte Arbeitsprofil- oder Gerätedaten nicht wieder her.
Nicht-destruktives Beispiel: Bei einer genehmigten Änderung der Zwischenablage-Freigabe Testtext von einer Arbeits-App in eine private App kopieren; nur der zuvor erwartete Datenfluss darf eintreten. Danach den festgelegten Aktualisierungs- oder Ersatzrichtlinienweg nutzen und nach bestätigter Synchronisation mit neuem Testtext erneut prüfen. Weicht das Verhalten ab oder bleibt die Freigabe wirksam, nicht produktiv zuweisen und mit Datenschutz- und Mobile-Verantwortlichen klären. Keine Fehlversuchs-Löschtests auf Privatgeräten.
Ohne nachgewiesene Wirkung, geprüfte Wiederherstellungswege und Akzeptanz verbleibender Datenverlustrisiken keine produktive Richtlinienzuweisung oder Empfehlung. Registrierung/BYOD-Einwilligung, App-Bereitstellung, WLAN/VPN/SCEP, Exchange-Authentisierung, Richtlinienzuweisung und destruktives Offboarding bleiben separate Verantwortungsbereiche.