Android Enterprise: Geräterichtlinie für vollständig verwaltete Firmengeräte

Kurzantwort: Die Android-Enterprise-Geräterichtlinie von Sophos gilt für Geräte im Modus Android Enterprise full device. Dieser Beitrag behandelt die Richtlinie für vollständig verwaltete Firmengeräte, nicht die eigenständige Work-Profile-Richtlinie für Geräte im Modus Android Enterprise work profile (etwa BYOD; der Verwaltungsmodus ist nicht mit der Eigentumsform gleichzusetzen). Gleiche Namen einzelner Einstellungen begründen keine gleiche Wirkung in beiden Modi. Die hier beschriebenen Optionen sind Entscheidungshilfen, kein im Tenant getestetes Standardprofil.

Vor einer Richtlinienänderung

Prüfen, ob Geräte tatsächlich im Full-Device-Modus eingeschrieben sind, die benötigte Sophos-Mobile-Lizenz im Tenant vorhanden ist, welche Android-Version und welches Gerätemodell betroffen sind und welche Richtlinie dem Testgerät tatsächlich zugewiesen ist. Geplante Änderungen samt Ausgangszustand, Backup und Wiederherstellungsweg dokumentieren. Erst an einem repräsentativen Firmengerät beobachten, ob die gewünschte Einstellung wirksam ist und ob die Rücknahme funktioniert; erst dann einen breiteren Rollout freigeben. Weder eine angelegte Policy noch ihre Zuweisung beweist die Wirkung auf dem Gerät.

Richtlinie für den Pilot vorbereiten und zuweisen

In Sophos Mobile Admin unter Policies > Android > Create den Typ Android Enterprise device policy wählen oder die freigegebene Testrichtlinie bearbeiten. Beim Erstellen auf Edit policy einen Namen und eine Beschreibung eingeben. Restrictions gehört ebenfalls zu den verfügbaren Konfigurationen und wird von Sophos Mobile automatisch hinzugefügt; sie über ihren Namen zum Bearbeiten öffnen. Unter Add configuration nach Bedarf App Control, App permissions, App Protection oder Password policies hinzufügen und den Konfigurationsnamen öffnen. Bei Password policies anschliessend unter Password type den erlaubten Passworttyp auswählen. Wenn ein Mail-Konto eingerichtet werden soll, unter Add configuration > Email account die Konfiguration hinzufügen und ebenfalls über ihren Namen bearbeiten. Danach die Richtlinie mit Save speichern. Nicht versuchsweise eine gemeinsam produktiv verwendete Richtlinie verändern: Die Änderung betrifft deren bestehende Zuweisungen, nicht nur das gerade betrachtete Testgerät.

Für die gezielte Zuweisung unter Policies > Android das blaue Dreieck neben der gespeicherten Richtlinie > Assign öffnen. Unter Select devices das genehmigte Testgerät auswählen; für eine Testgruppe Select device groups verwenden und deren tatsächlichen Gerätebestand kontrollieren. Mit Finish abschliessen. Die hier genannte Gerätegruppe bestimmt die Zielgeräte; die nachfolgende App-Gruppe bestimmt dagegen die Apps innerhalb einer Konfiguration.

Android-Enterprise-Richtlinien gehören zum dauerhaft zugewiesenen, bei jeder Verbindung mit Sophos Mobile synchronisierten Richtlinientyp. Sophos beschreibt ihre Zuweisung als sofort wirksam; das ist keine Zusage, dass ein offline befindliches Gerät die Änderung sofort erhält. Änderungen benötigen nicht den Update devices-Pfad der älteren Android-Geräterichtlinien. Für eine Rücknahme die dokumentierte, freigegebene vorherige Konfiguration wiederherstellen und speichern oder über denselben Assign-Pfad eine zuvor geprüfte Ersatzrichtlinie zuweisen. Uninstall policy ist für diesen Android-Enterprise-Typ kein Rückweg. Nach der Geräteverbindung die tatsächliche Zuweisung und die jeweilige App-Wirkung erneut prüfen; eine gespeicherte Rücknahme ist noch kein nachgewiesener Rollback.

Apps und Berechtigungen

App-Gruppen für Startblockade und Passwortschutz

App Control und App Protection verwenden jeweils die unter App group ausgewählte App-Liste. Für beide lässt sich eine Android-App-Gruppe unter App groups > Android > Create app group anlegen. Einen unterscheidbaren Namen vergeben und Add app > App list öffnen. Dort eine App aus den aktuell auf verwalteten Geräten installierten Apps auswählen, mit Add übernehmen und für weitere Mitglieder wiederholen; abschliessend Save. Vor Auswahl in der Richtlinie den gespeicherten Mitgliederbestand mit den tatsächlich gewünschten Apps abgleichen. Für eine Hersteller-App ohne Store-Eintrag ist diese installierte App-Liste der passende dokumentierte Auswahlweg; nicht für jede OEM-App einen Google-Play-Link voraussetzen.

Bei manueller Aufnahme über Custom bezeichnet App name den eindeutigen Namen und Identifier die interne App-Kennung. Für eine Google-Play-App lässt sich unter Link > Obtain link deren Store-Seite öffnen; den Link übernehmen und mit Get data die Felder App name und Identifier befüllen. Der Android-Paketname steht in der Google-Play-URL hinter id=. Bei Apps aus Managed Google Play verlangt Sophos im Identifier die Zeichenfolge app: vor dem Paketnamen. Dieses Präfix nicht pauschal auf alle Android- oder OEM-Apps übertragen. Anzeigename, Kennung und gespeicherte Gruppenmitgliedschaft vor dem Pilot nochmals vergleichen: Eine ähnlich benannte App ist kein Nachweis für das richtige Gruppenmitglied.

App Control: Start blockieren, nicht deinstallieren

Unter App Control > App group die Gruppe der Apps auswählen, die Nutzer nicht starten dürfen. Das erfasst auch nicht deinstallierbare, vom Hersteller vorinstallierte Apps und ist keine Deinstallation. Bei betrieblich benötigten Apps zuerst deren Abhängigkeiten und einen nutzbaren Notfallzugang am Pilotgerät klären.

Nach der gezielten Zuweisung und Verbindung mit Sophos Mobile am Pilotgerät eine aufgeführte App direkt starten: Erwartet wird die Startblockade. Zum Vergleich eine nicht aufgeführte App öffnen, die zuvor funktionierte und nicht anderweitig gesperrt ist. Bei einer betroffenen OEM-App zusätzlich kontrollieren, dass sie weiterhin installiert ist; ein verschwundenes Symbol allein belegt weder Deinstallation noch die richtige Sperre. Für den Rücktest das Testmitglied aus der Gruppe entfernen und die Gruppe speichern oder die App-Control-Konfiguration gemäss freigegebenem Ausgangsstand zurücknehmen. Nach erneuter Synchronisation denselben Startversuch wiederholen. Weicht das Verhalten ab oder bleibt die Blockade bestehen, keine weiteren Geräte zuweisen: Kennung, Gruppenmitgliedschaft, effektive Richtlinie und Geräteverbindung mit dem Mobile-Verantwortlichen prüfen. Aus diesem direkten Starttest folgt keine Zusage zur Beendigung bereits laufender Prozesse oder zur Sperre aller Hintergrund- und indirekten Zugriffe.

App permissions: Rechte für konkrete Funktionen festlegen

App permissions steuert nur Laufzeitberechtigungen, also nicht jede von einer App angeforderte Freigabe. Unter Default response for runtime permission requests fordert Prompt Nutzer zur Freigabe auf; Auto-accept erteilt und Auto-deny verweigert die angefragten Laufzeitberechtigungen automatisch. Die beiden automatischen Optionen verhindern die spätere Bearbeitung dieser Berechtigungen durch Nutzer. Aufforderungen für Akkuoptimierung oder Bedienungshilfen bleiben möglich.

Unter App-specific runtime permissions > Add die betreffende App auswählen und für jede benötigte Berechtigung entscheiden: Selectable lässt Nutzer die Berechtigung bearbeiten, Granted gewährt sie und Denied verweigert sie. Nur die für die konkrete Funktion erforderlichen Rechte vorgeben. Die Standardantwort und die app-spezifischen Optionen sind dokumentiert, ihre Priorität bei widersprüchlichen Vorgaben jedoch nicht; für den Pilot keine solchen Konflikte einrichten. Der Feldname Default response belegt auch nicht, welche Option ab Werk ausgewählt ist.

Als nicht-destruktive Prüfung eine Test-App und eine Aktion wählen, die nachweislich eine bestimmte Laufzeitberechtigung benötigt. Nach Zuweisung und Synchronisation kontrollieren, ob eine Nutzerabfrage erscheint, ob die Funktion tatsächlich erlaubt oder verweigert wird und ob der Nutzer die Berechtigung ändern kann. Vorhandene Freigaben mit erfassen, damit eine ausbleibende Abfrage nicht allein als Erfolg gilt. Bleibt eine Abfrage zur Akkuoptimierung oder Bedienungshilfe bestehen, ist sie kein Beleg für eine fehlgeschlagene Laufzeitvorgabe. Nach Wiederherstellung der vorherigen Konfiguration oder Zuweisung der geprüften Ersatzrichtlinie und erneuter Verbindung dieselbe Funktion und Bearbeitbarkeit nochmals prüfen. Bei Abweichungen zuerst App, angeforderte Berechtigungsart und effektive Vorgaben klären, statt pauschal Auto-accept zu setzen.

App Protection: gemeinsames Passwort und Schonfrist

Unter App Protection > App group die Gruppe der zu schützenden Apps auswählen. Nutzer legen beim ersten Öffnen einer geschützten App ein gemeinsames Passwort für alle geschützten Apps fest. Password complexity bestimmt etwa Mindestlänge und erforderliche Buchstaben oder Ziffern; diese Anforderungen getrennt von der Geräte-Displaysperre auswählen. Grace period in minutes ist die Schonfrist nach dem Schliessen einer geschützten App: Innerhalb dieses Zeitraums kann auch eine andere geschützte App ohne Passworteingabe geöffnet werden. Allow fingerprint authentication erlaubt Fingerabdruck- statt Passworteingabe.

Zugriffe über andere Apps wie Google Assistant oder Android-Systemfunktionen und Mehrfenstermodi wie Split Screen, Floating Windows oder Tiny Windows können die Passwortabfrage umgehen. App Protection deshalb weder als Gerätesperre noch als umfassende Garantie für vertrauliche App-Inhalte einsetzen. Auch das manuelle Sperren beseitigt diese dokumentierten Android-Grenzen nicht.

Am autorisierten Pilotgerät nach Zuweisung und Synchronisation auf der Startseite von Sophos Mobile Control > App Protection unter Password-protected apps den angezeigten Bestand mit der ausgewählten App-Gruppe vergleichen. Mit zwei ausgewählten Apps und einer nicht ausgewählten Kontroll-App prüfen: Beim ersten geschützten Öffnen das gemeinsame Passwort anlegen, eine geschützte App schliessen und die andere innerhalb sowie nach Ablauf der eingestellten Schonfrist öffnen. So lässt sich die app-übergreifende Frist beobachten, statt nur dieselbe App erneut zu starten. Falls Fingerabdruck erlaubt ist, auch diesen Zugang gesondert prüfen. Nach Gerätesperre sowie nach App Protection > Lock protected apps die geschützten Apps erneut öffnen und die Passwort- beziehungsweise zugelassene Fingerabdruckabfrage kontrollieren. Lock protected apps sperrt alle geschützten Apps auf einmal, etwa vor einer Geräteübergabe; die Kontroll-App gehört nicht zu diesem Passwortschutz. Die beschriebenen Zugriffe über andere Apps/Systemfunktionen und Mehrfenstermodi getrennt berücksichtigen, statt eine lückenlose Sperre zu behaupten.

Für die Rücknahme App-Gruppe oder App-Protection-Konfiguration gemäss dokumentiertem Ausgangsstand ändern und speichern beziehungsweise die geprüfte Ersatzrichtlinie zuweisen. Nach der nächsten Verbindung sowohl Password-protected apps als auch das tatsächliche Öffnen der Test-Apps erneut prüfen. Bleiben unerwartete Apps geschützt oder fehlt der erwartete Schutz, die weitere Zuweisung stoppen und Gruppenbestand, Richtlinie und Synchronisation prüfen. Alle diese Kontrollen sind geplante Pilotprüfungen, keine hier ausgeführten Gerätetests.

Vergessenes App-Passwort: Zuerst prüfen, ob das Sophos Central Self Service Portal für den zugeordneten Nutzer verfügbar und die Aktion für ihn erlaubt ist. Dort unter Mobile das richtige Gerät auswählen und Actions > Reset App Protection password > Reset ausführen. Beim nächsten Öffnen einer geschützten App legt der Nutzer ein neues gemeinsames Passwort fest; diesen Schritt am vorgesehenen Gerät kontrollieren. Das ist weder ein Reset des Geräte-Displaysperrpassworts noch ein Wipe oder Werksreset.

Gmail und Google Play

Die Konfiguration Email account kann ein Exchange-Online- oder Exchange-Server-Konto in Gmail hinzufügen. Für %_USERNAME_% und %_EMAILADDRESS_% müssen Exchange Login und Email Address des zugeordneten Nutzers in Sophos Fusion gepflegt sein. Dazu unter My Environment > Users & Groups > Users den Namen des zugeordneten Nutzers öffnen und diese Angaben in den Benutzerdetails bearbeiten. Eine Policy mit diesen Platzhaltern lässt sich einem Gerät ohne Nutzerzuordnung nicht zuweisen.

Account name bezeichnet den Kontonamen, während User den Anmeldenamen festlegt. Email address ist die E-Mail-Adresse des Kontos, Sender dessen Absendername. Wird in einem dieser beiden letzten Felder %_EMAILADDRESS_% eingetragen, ersetzt der Server den Platzhalter durch die tatsächliche E-Mail-Adresse. Default email signature legt die Standard-E-Mail-Signatur fest.

Ist noch eine ältere verwaltete Gmail-Konfiguration vorhanden, ignoriert Gmail Email account – auch wenn die ältere Konfiguration leer ist; in neueren Versionen wird sie nicht mehr angeboten.

Für Exchange Online nennt Sophos outlook.office365.com nur für die weltweite Microsoft-365-Cloud; bei anderen Clouds den passenden Cloud-Endpunkt prüfen. Für Exchange Server ist die Server-URL erforderlich; wird dabei ein Sophos-Mobile-EAS-Proxy verwendet, stattdessen dessen URL eintragen. Als Nutzername dient für Exchange Online üblicherweise %_EMAILADDRESS_%, für Exchange Server %_USERNAME_%; einen erforderlichen Domänenpräfix nur ergänzen, wenn er nicht schon im Fusion-Feld Exchange Login steht. In diesem Fall unter User <domain>\%_USERNAME_% eintragen und <domain> durch die für die eigene Exchange-Server-Anmeldung erforderliche Domäne ersetzen.

Unter Authentication verwendet Basic authentication Benutzername und Kennwort. Die eigenständige Auswahl Modern authentication verwendet moderne Authentifizierung (OAuth 2.0). Basic and modern authentication verwendet moderne oder Basic-Authentifizierung entsprechend der Unterstützung durch Exchange. Für moderne Gmail-Authentifizierung (OAuth 2.0) muss Google Chrome auf dem Gerät installiert sein; die angebotenen Basic- und Mischoptionen sind keine Zusage zur Kompatibilität mit dem eigenen Exchange-Dienst. SSL/TLS sichert die Exchange-Verbindung mit SSL oder TLS, je nachdem, was der Server unterstützt; Sophos empfiehlt diese Option. Allow all certificates erweitert die Zertifikatsakzeptanz und erfordert eine bewusste Vertrauensentscheidung.

Allow unmanaged accounts erlaubt Nutzern, andere Exchange-Konten hinzuzufügen oder zu entfernen, nicht jedoch das in dieser Konfiguration festgelegte Konto. Bei aktivierter Option lässt sich die Datenweitergabe zwischen anderen Apps und von Nutzern hinzugefügten Exchange-Konten nicht verhindern. Bestehende Gmail-Konfiguration, Benutzerzuordnung, Authentifizierung, Zertifikatsvertrauen und Mail-Fluss im Pilot prüfen; Exchange-/EAS-Proxy-Migration ist ein eigenständiges Thema. Synchronization period begrenzt die synchronisierten E-Mails auf den ausgewählten Zeitraum; den Bedarf an älteren lokal verfügbaren Nachrichten prüfen. Client certificate bestimmt das Zertifikat für die Exchange-Verbindung; dessen Bereitstellung und Vertrauensstellung getrennt prüfen.

Die Google-Play-Konfiguration bestimmt auf vollständig verwalteten Geräten, auf welche Apps Nutzer im Play Store zugreifen können und wie automatische App-Updates erfolgen:

• Available apps: Approved apps from managed Google Play erlaubt den Zugriff nur auf die in Managed Google Play für die Organisation genehmigten Apps; Apps from Google Play erlaubt den Zugriff auf alle Google-Play-Apps.
• Auto update apps: Over any network aktualisiert Apps automatisch über jedes Netzwerk einschliesslich WLAN und mobiler Daten; Over Wi-Fi only nur über WLAN. Don’t update apps automatically bedeutet keine automatischen App-Updates. Bei Use device setting gilt die Geräteeinstellung; Nutzer können automatische Updates selbst in ihrer Play-Store-App konfigurieren.

App-Zugriff im Play Store und Updateverhalten bewusst für den Einsatzfall und die Update-/Datenkostenfolgen festlegen; eine Play-Store-Auswahl ist kein Ersatz für die gesonderte Bereitstellung verwalteter Apps.

Displaysperre und Passwortmanager nicht verwechseln

Password policies steuert die Geräte-Displaysperre. Unter Password type den erlaubten Typ auswählen: Pattern, PIN or password verlangt eine Displaysperre durch Muster, PIN oder Passwort ohne weitere Einschränkungen. Simple password verlangt eine Passwortsperre mit mindestens einem Buchstaben; Ziffern sind ebenfalls erlaubt. Weitere Typen sind PIN or password, Alphanumeric password (Buchstaben und Ziffern) und Complex password (Passwortsperre mit Buchstaben und Ziffern sowie zusätzlichen konfigurierbaren Zeichen-Mindestwerten).

Bei den letzten vier Typen werden Mindestlänge, maximale Inaktivitätszeit, maximales Passwortalter, Maximum sign-in attempts und Password history angezeigt. Das Gerät kann eine kürzere Inaktivitätszeit erzwingen; das Passwortalter reicht von 0 (kein Wechsel nötig) bis 730 Tagen. Password history verhindert, dass ein neues Passwort mit der konfigurierten Zahl zuvor verwendeter, in Sophos Mobile gespeicherter Passwörter übereinstimmt.

Nur bei Complex password erscheinen zusätzlich sechs getrennte Mindestanzahl-Felder: Minimum number of letters für alle Buchstaben, Minimum number of lowercase letters für Kleinbuchstaben, Minimum number of uppercase letters für Grossbuchstaben, Minimum number of non-alphabetic characters für nicht-alphabetische Zeichen, Minimum number of digits für Ziffern und Minimum number of special characters für Sonderzeichen. Nicht-alphabetische Zeichen und Sonderzeichen haben eigene Felder; sie nicht zu einem einzigen Mindestwert zusammenfassen.

Ein konfigurierter Schwellenwert bei Maximum sign-in attempts löscht das Gerät nach entsprechend vielen falschen Anmeldeversuchen. Vor Aktivierung Backup, freigegebenen Pilot und autorisierten Wiederherstellungsweg voraussetzen. Bei aktivierter Factory Reset Protection (FRP) zusätzlich prüfen, ob nutzbare Zugangsdaten für ein autorisiertes Google-Konto vorliegen, das zum Entsperren genau dieses Geräts unter FRP konfiguriert ist. Diese Richtlinienseite belegt nicht, welcher Resetweg FRP aktiviert; FRP-Konfiguration und Auswirkungen der Resetwege gehören zum eigenen FRP-Recovery-Owner. Eine spätere Policy-Rücknahme stellt gelöschte Daten nicht wieder her.

Password services regelt dagegen die Verwendung von Passwortmanagern. Unter App group die App-Gruppe mit den betreffenden Managern auswählen und unter Mode entscheiden: Allow erlaubt nur die genannten Manager, Block sperrt die genannten und erlaubt andere. Allow system apps ist nur verfügbar, wenn Mode auf Allow steht. Damit können optional die voreingestellten Passwortmanager des Geräteherstellers zugelassen werden; ohne ausgewählte App-Gruppe lässt diese Kombination nur jene Hersteller-Manager zu. Diese Konfiguration ist nicht die Displaysperre und dokumentiert keinen Löschvorgang nach fehlgeschlagenen Entsperrversuchen. Vor dem Sperren die benötigten Passwortmanager im Test inventarisieren.

Einschränkungen mit asymmetrischer Wirkung

Unter Restrictions lassen sich Funktionen vollständig verwalteter Geräte einschränken. Die folgenden Themen bündeln die betrieblich wichtigen Freigaben und ihre Grenzen; sie sind kein Standardprofil und keine vollständige Liste aller Einschränkungen.

Gerätezugriff und vertrauliche Inhalte

Force encryption verpflichtet Nutzer zur Geräteverschlüsselung. Allow factory reset erlaubt ihnen, das Gerät auf Werkseinstellungen zurückzusetzen; das ist eine Nutzerfreigabe, nicht der administrative Wipe-Ablauf oder eine Aussage zur FRP-Auslösung. Allow safe mode erlaubt den Start im abgesicherten Modus, Allow debugging das Einschalten der Debugging-Funktionen in den Android-Entwickleroptionen. Mit Allow user to configure credentials dürfen Nutzer Zertifikate installieren oder entfernen; diese Freigabe ist von der MDM-Bereitstellung von Zertifikaten zu unterscheiden.

Allow Smart Lock erlaubt situationsabhängiges automatisches Entsperren des Geräts. Die Einstellung wird bei separat konfigurierter Work-Profile-Sperre ignoriert. Allow unlocking device by fingerprint erlaubt die Geräteentsperrung per Fingerabdruck, nicht den gesonderten App-Protection-Zugang. Allow screen capture erlaubt Screenshots des Displays. Hide sensitive information on lock screen verbirgt sensible Benachrichtigungsinhalte, wenn Sperrbildschirmbenachrichtigungen eingeschaltet sind.

Allow changing the account picture erlaubt Nutzern, das Foto ihres Benutzerkontos zu ändern.

Allow location services erlaubt die Weitergabe des Gerätestandorts an Apps und Dienste. Wird die Option ausgeschaltet, sind die Ortungsdienste deaktiviert und Nutzer können sie nicht wieder einschalten. Auch Sophos Mobile kann das Gerät dann nicht orten.

System-Apps, Installation und App-Verwaltung

Im dokumentierten Ausgangszustand sind die meisten vom Hersteller vorinstallierten System-Apps deaktiviert. Apps für Grundfunktionen wie Telefon, Kontakte oder Nachrichten bleiben zugänglich; welche das sind, hängt vom Gerätemodell ab. Enable system apps schaltet alle System-Apps frei. Nach dem Aktivieren können diese System-Apps laut Sophos nicht wieder deaktiviert werden; den Schalter nicht als reversiblen Standardtest verwenden.

Ist Allow wallpaper change ausgeschaltet, können Nutzer das Hintergrundbild nicht ändern.

Ist Allow installing apps from unknown sources ausgeschaltet, können Nutzer Apps nur aus Google Play installieren, nicht aus unbekannten Quellen oder per Android Debug Bridge (ADB). Das ist eine andere Einschränkung als die Freigabe der Debugging-Funktionen.

Zwei Schalter betreffen die App-Verwaltung unterschiedlich: Allow app uninstall auszuschalten verhindert auch, dass Administratoren Apps über Sophos Mobile deinstallieren. Rückweg für notwendige App-Entfernungen vorab testen. Bei ausgeschaltetem Allow managing apps können Nutzer Apps weder deinstallieren, deaktivieren noch beenden. Sie können auch weder App-Cache noch App-Daten löschen oder die Einstellung Open by default zurücksetzen. Diese Einschränkung bei der Planung von Support und Fehlerdiagnose berücksichtigen.

Allow disabling Google security scans erlaubt Nutzern, Scan device for security threats abzuschalten. Sophos nennt dafür den Android-Hilfepfad Settings > Google > Security > Google Play Protect. Den Menüpfad am eigenen Gerät prüfen; die Freigabe ist keine Empfehlung, die Scans abzuschalten.

Systemupdates, Konten und Uhrzeit

Unter System update policy die Installationsplanung festlegen. No policy lässt Nutzer den Zeitpunkt bestimmen. Install automatically installiert Systemupdates automatisch, sobald sie verfügbar sind. Install within maintenance window verwendet ein tägliches automatisches Wartungsfenster; dafür Beginn und Ende als Uhrzeiten eingeben. Postpone blockiert Nicht-Sicherheitsupdates für 30 Tage, nicht Sicherheitsupdates. Die Update-Zeitplanung gesondert abstimmen; keine der genannten Optionen ist hier als vorgewählter Standard belegt.

Allow managing accounts erlaubt das Hinzufügen und Entfernen von Konten auf dem Gerät. Allow managing Google accounts erlaubt dies für Google-Konten und ist nur verfügbar, wenn Allow managing accounts eingeschaltet ist. Beim Ausschalten der übergeordneten Freigabe wird die Google-Konten-Option ebenfalls deaktiviert.

Allow setting date and time erlaubt Nutzern, Datum und Uhrzeit selbst einzustellen. Ohne diese Freigabe verwendet das Gerät Datum und Uhrzeit aus dem Netzwerk.

Kommunikation und Netzwerkeinstellungen

Ist Allow SMS ausgeschaltet, können Nutzer keine SMS senden. Allow outgoing phone calls erlaubt ausgehende Anrufe. Daraus folgt keine Aussage zur Behandlung eingehender Nachrichten oder Anrufe, zu Notrufen oder zu Carrier-Ausnahmen. Allow configuring cell broadcasts erlaubt, Cell-Broadcast-Nachrichten in der Nachrichten-App ein- oder auszuschalten; bestimmte Warnklassen werden damit hier nicht zugesichert.

Das Ausschalten von Allow mobile data connection while roaming deaktiviert mobile Datenverbindungen während des Roamings. Ohne Allow VPN können Nutzer keine VPN-Verbindungen verwenden; die Auswahl und Bereitstellung eines verwalteten VPN-Clients bleibt ein eigenes Thema. Allow Bluetooth auszuschalten verhindert Verbindungen zu neuen Bluetooth-Geräten; Verbindungen zu bereits gekoppelten Geräten bleiben möglich.

Enable Wi-Fi settings, Enable cellular networks settings und Enable tethering settings erlauben jeweils Nutzeränderungen an WLAN-, Mobilfunk- beziehungsweise Tethering- und mobilen Hotspot-Einstellungen. Allow network reset erlaubt das Zurücksetzen der Netzwerkeinstellungen auf ihre Standardwerte. Das ist nicht die Rücknahme einer Cloud-Richtlinie.

Bei ausgeschaltetem Allow sharing of managed Wi-Fi connections können Nutzer die durch Sophos Mobile konfigurierten WLAN-Verbindungen nicht teilen. Diese Einstellung betrifft Android 13 und neuer. Allow Android Beam betrifft dagegen nur Android 9 und älter, nicht andere Freigabetechnologien. Wirkung immer an der tatsächlich verwendeten Android-Version prüfen.

Kamera, Mikrofon und USB-Medien

Wird Allow camera beziehungsweise Allow microphone ausgeschaltet, ist die Kamera beziehungsweise das Mikrofon nicht verfügbar. Das sind geräteweite Einschränkungen, keine einzelnen Antworten auf App-Laufzeitberechtigungen. Allow external media erlaubt den Anschluss externer Medien wie USB-Speicher. Allow transferring files over USB erlaubt dagegen den Dateitransfer zwischen Gerät und externem USB-Speicher; Anschluss und Dateitransfer sind getrennte Freigaben.

Supporttexte und Bedienungshilfen

Short message ist der unternehmensspezifische Supporthinweis, den Nutzer bei deaktivierten Funktionen sehen. Text über 200 Zeichen kann gekürzt werden. Long message ergänzt diesen Hinweis, wenn Nutzer auf More details tippen, und erscheint zusätzlich auf der Android-Seite Device administrator für Sophos Mobile Control.

Unter Allowed accessibility services erlaubt All available apps alle Bedienungshilfen, Only system apps nur solche von System-Apps. Die App-Gruppen-Zulassung lässt die ausgewählten Gruppenmitglieder und weiterhin System-Apps zu. Anforderungen an Bedienungshilfen vor der Einschränkung gesondert prüfen.

Abgrenzung zu Compliance und anderen Richtlinien

Die Geräterichtlinie mit App Control oder App Protection ist keine Compliance-Aktion. Compliance-Regeln, Lock container und Transfer task bundle gehören einem anderen Owner; dieser Artikel belegt weder deren Ausnahmen, Vorrang, Löschwirkungen noch Auswirkungen auf private BYOD-Apps. Einen Geräterichtlinien-Pilot nicht als Test einer Compliance-Aktion verwenden. Vor jedem Eingriff die betreffende Compliance-Aktion, den Modus, den Wiederherstellungsweg und mögliche Datenverluste im gesonderten Compliance-Ablauf prüfen.

Für Kiosk mode, Bereitstellungsweg und die vorab nötige Prüfung des physischen Ausstiegs führt die Vorbereitung dedizierter Android-Geräte weiter; sie ersetzt keinen nachgewiesenen Ausstieg am eigenen Gerät. Wi-Fi, VPN und Global HTTP proxy benötigen den eigenen Ablauf für verwaltete Android-Verbindungen, insbesondere wenn eine Änderung den Managementzugang beeinträchtigen kann. Für den anderen Verwaltungsmodus gilt die Work-Profile-Richtlinie, nicht dieser Full-Device-Ablauf.

Bei Zertifikaten drei Konfigurationen auseinanderhalten: Root certificate stellt den Vertrauensanker bereit, Client certificate importiert ein PKCS-#12-Clientzertifikat (.pfx), und SCEP lässt das Gerät ein Zertifikat bei der CA anfordern. Die Android-spezifische Verfügbarkeit innerhalb derselben Richtlinie und die Trennung von SCEP-Server- und EAP-Serververtrauen erklärt der verlinkte Verbindungsartikel. Für SCEP zuerst das CA-Zertifikat des SCEP-Servers als Root certificate derselben Richtlinie bereitstellen. Die tenantseitigen Voraussetzungen – SCEP-fähige CA, Fusion-Zugriff auf Ausstellungs- und Challenge-Endpunkt, regionsabhängiger Netzwerkpfad und SCEP renewal interval – gehören zum SCEP-Verbindungs- und Zertifikatspilot. Dort Ausstellung, Erneuerung und Rückweg getrennt prüfen; eine SCEP-Konfiguration allein belegt keine funktionierende WLAN-/VPN-Zertifikatszuordnung. Die Aufzählung dieser Payloads in einer Geräterichtlinie ersetzt ihre jeweiligen Sicherheits- und Rolloutprüfungen nicht.