Sophos Mobile Compliance-Richtlinien sicher planen und prüfen

Eine Compliance-Richtlinie ist kein Zertifikat und kein Geräteprofil. Sie bewertet ausgewählte Regeln für eingeschriebene Geräte und kann bei Verstössen Aktionen auslösen. Entscheidend sind die tatsächliche Produktausgabe (Sophos Mobile oder Sophos Mobile Threat Defense), Plattform und OS-Version, Firmen- oder Privatgerät, Enrollment-/Verwaltungsmodus, gegebenenfalls die von Sophos Mobile verwaltete Intercept-X-for-Mobile-App (IXM) sowie die zugewiesene Gerätegruppe. Eine sichtbare Regel oder PCI-/HIPAA-Vorlage belegt weder ihre Anwendbarkeit auf jedes Gerät noch eine Zertifizierung.

Vor jedem produktiven Eingriff: Check now prüft alle eingeschriebenen Geräte und führt konfigurierte Aktionen aus. Auch das Anlegen oder Ändern einer Richtlinie und ihre Gruppenzuweisung sind nicht bloss Leseschritte. Zuerst die vollständige Zielmenge und den Rückweg klären; keine produktive Flotte zum Ausprobieren verwenden.

Was wird überhaupt bewertet?

Zuerst die Produktausgabe wählen, dann Plattform, OS und Enrollment-Modus prüfen: Bei Android Enterprise fully managed verwaltet MDM das ganze Gerät; bei Apple User Enrollment werden private Apple-Geräte mit eingeschränktem Verwaltungsumfang eingebunden; supervised bezeichnet beaufsichtigte iPhones/iPads. Eine durch Sophos Mobile verwaltete IXM-App ist noch kein Beleg für vollständiges Mobile Device Management (MDM). Im eigenen Mandanten die verfügbaren Regeln der tatsächlich eingesetzten Ausgabe und des Modus abgleichen; Regelumfang und Aktionen von Sophos Mobile und Sophos Mobile Threat Defense nicht vermischen.

Regeln legen fest, welche Gerätefunktionen oder Zustände erlaubt, verboten oder erforderlich sind. Die Reaktion auf einen Verstoss wird separat gewählt; ein Compliance-Kriterium allein ist kein Beleg dafür, dass eine Geräteeinstellung aktiv geändert oder erzwungen wird.

Zum Anlegen einer Richtlinie in Sophos Mobile oder in der eigenständigen Ausgabe Sophos Mobile Threat Defense das Menü Compliance policies öffnen, Create compliance policy anklicken und die Default-, PCI- oder HIPAA-Vorlage auswählen. Einen Namen und optional eine Beschreibung eingeben; die Vorlagenwahl begrenzt spätere Einstellungen nicht. Nur die Default-Vorlage hat keine voreingestellten Aktionen; PCI/HIPAA können bereits Aktionen enthalten. Sophos beschreibt die Regeln und Aktionen der PCI-/HIPAA-Vorlagen als auf HIPAA und PCI DSS basierend. Die Reihenfolge der Vorlagen und Standards in der Dokumentation ist jedoch uneindeutig; daraus hier keine Zuordnung einer einzelnen Vorlage zu einem Standard ableiten. Die Plattform-Registerkarte muss mit Enable platform aktiviert sein: Ohne Häkchen findet für Geräte dieser Plattform keine Compliance-Prüfung statt. Die Schweregrade high, medium, low sind den Regeln fest zugeordnet; sie sind nicht mit einer frei wählbaren Reaktionsaktion gleichzusetzen. Bei der Richtlinienplanung helfen sie, die Wichtigkeit jeder Regel einzuschätzen und eine angemessene Reaktion auf einen Verstoss auszuwählen. Das erteilt keine Freigabe zur Ausführung einer Aktion im Vorfall. Highlight rules in der Vollausgabe hilft beim Hervorheben eines Managementtyps, ist aber kein Nachweis, dass eine Regel auf jedem Gerät dieses Typs wirksam ist.

Erst wenn für alle benötigten Plattformen die Regeln und zugehörigen Reaktionen eingestellt und geprüft sind, Save anklicken. Damit wird die Richtlinie unter dem eingegebenen Namen gespeichert; die anschliessende Gruppenzuweisung folgt separat nach den unten beschriebenen Prüfungen.

Sophos Mobile (Vollausgabe/MDM): Neben plattformabhängigen Verwaltungs- und OS-Regeln sind IXM-Signale möglich, wenn Sophos Mobile die App verwaltet. Als Reaktionen pro Regel stehen Deny email, Lock container, Set health, Create alert und Transfer task bundle zur Auswahl; Plattform und Voraussetzungen der jeweiligen Aktion gelten weiterhin.
Sophos Mobile Threat Defense (eigene Produktausgabe): Der getrennte Regelumfang umfasst unter anderem Android-IXM-Berechtigungen und Malware-/App-Erkennungen, iOS-Web-Filtering sowie Chromebook-Sicherheitsregeln. Für diese Ausgabe ist Create alert als Reaktion beschrieben, nicht die MDM-Aktionen für E-Mail, Container, Health oder Task-Bundles.

In der eigenständigen Ausgabe gelten Installed apps und Mandatory apps nur für Chromebooks. Bei Installed apps zuerst Allowed apps oder Forbidden apps wählen und danach die App-Gruppe mit den erlaubten beziehungsweise verbotenen Apps oder Erweiterungen. Bei Mandatory apps die App-Gruppe mit den Apps oder Erweiterungen wählen, die installiert sein müssen. Die weiter unten beschriebenen Android-, iOS- und Mac-Zuordnungen sowie die Hinweise zu System-Apps und Android-App-Updates gehören zum allgemeinen Katalog der Vollausgabe Sophos Mobile, nicht zu diesen beiden Regeln der eigenständigen Threat-Defense-Ausgabe.

Der separate Mobile Threat Defense compliance rules-Katalog innerhalb der Sophos-Mobile-Hilfe beschreibt eine Teilmenge für Android-/iOS-Geräte, deren IXM-App von Sophos Mobile verwaltet wird: etwa Root/Jailbreak, OS-Grenzen, IXM-Synchronisierung und Android-App-Scans. Eine verwaltete App allein beweist keine vollständige MDM-Geräteverwaltung; diese Teilmenge ist auch nicht der Regelkatalog der eigenständigen Produktausgabe Sophos Mobile Threat Defense. Die Regel Intercept X for Mobile permissions can be denied legt unter Android fest, ob verweigerte IXM-App-Berechtigungen das Gerät nicht konform machen. Sie kann bei verweigertem Accessibility Service einen Ausfall des Web Filtering als Verstoss sichtbar machen; Sophos empfiehlt bei Nutzung von Web Filtering den Wert No. Die iOS-Regel Web Filtering turned on steht im allgemeinen Sophos-Mobile-Regelkatalog und im Katalog der eigenständigen Threat-Defense-Ausgabe, nicht in der genannten IXM-Teilmenge. Sie verlangt auf iPhones und iPads, dass die Web Filtering-Funktion von Intercept X for Mobile eingeschaltet ist; das ist ein eigenes Kriterium, nicht die Android-Berechtigungsregel. Chromebook-Regeln sind nicht automatisch Android-/iOS-Regeln.

Die verwaltete IXM-Teilmenge ist in beiden Hilfen dokumentiert, für Sophos Mobile und für Sophos Mobile Threat Defense. Für Geräte, deren IXM-App Sophos Mobile verwaltet, nennt sie diese Zuordnungen:

Managed required gilt für Android und iOS. Die Regel legt die Reaktion fest, wenn ein Gerät nicht mehr verwaltet wird. Sie ist nicht mit Device administrator management allowed gleichzusetzen und belegt keine vollständige MDM-Verwaltung.
Minimum OS version und Maximum OS version gelten in dieser Teilmenge für Android und iOS. Sie legen die früheste erforderliche beziehungsweise neueste zulässige OS-Version fest. Die fehlende Plattformliste im allgemeinen Katalog weiter unten ändert diese Zuordnung nicht.
Malware apps allowed gilt hier nur für Android. Mit dieser Regel legt man fest, ob von IXM erkannte schädliche Apps zulässig sind.
PUAs allowed gilt hier nur für Android. Mit dieser Regel legt man fest, ob von IXM erkannte potenziell unerwünschte Apps zulässig sind.

Die beiden App-Regeln bewerten Konformität. Sie sind weder Scan-Einstellungen noch eine Freigabe, erkannte Apps zu entsperren oder von künftigen Scans auszunehmen. Erkennungsfolgen und Ausnahmen werden bei der unten verlinkten Reaktion auf einen Compliance-Vorfall getrennt geprüft.

Eine Maximum interval between … synchronizations-Regel ist eine konfigurierbare Compliance-Regel für die jeweilige Synchronisierungsquelle: die native MDM-Software des Betriebssystems, Sophos Mobile Control, IXM oder Sophos Chrome Security. Im allgemeinen Katalog gilt folgende Zuordnung:

Native MDM: iPhones/iPads ohne Sophos Mobile Control oder IXM sowie Macs und Windows-Computer.
SMC (Sophos Mobile Control): Android-Geräte und iPhones/iPads.
Intercept X for Mobile: Android-Geräte und iPhones/iPads.
Sophos Chrome Security: Chromebooks.

Jede dieser Regeln begrenzt den maximal zulässigen Abstand zwischen Synchronisierungen des jeweiligen Agenten mit Sophos Fusion; Agenten und Zeitwerte nicht austauschen. Maximum interval between Intercept X for Mobile scans begrenzt dagegen unter Android den Abstand zwischen IXM-Malware-Scans, nicht zwischen Synchronisierungen. Eine überschrittene Grenze ist nur anhand der tatsächlich aktivierten und verletzten Regel sowie der zugehörigen Synchronisierungs- oder Scan-Zeit zu beurteilen. Davon getrennt kann eine verzögerte oder fehlgeschlagene Synchronisierung bewirken, dass ein angezeigter Compliance-Status nicht mehr aktuell ist; sie beweist für sich allein weder einen Regelverstoss noch Konformität. Ein dem EAS Proxy unbekannter Status ist nochmals ein anderer Fall im gesondert konfigurierten Exchange-Quarantäneablauf, nicht automatisch ein Verstoss gegen die Maximum-Intervall-Regel.

Regeln nach Prüfaufgabe auswählen

Die folgenden Gruppen ordnen den allgemeinen Regelkatalog der Vollausgabe Sophos Mobile für die Planung ein. Sie sind keine Liste empfohlener Standardwerte. Zuerst Ausgabe und Verwaltungsmodus abgleichen, dann nur die passenden Kriterien auswählen und für jede Regel ihre Reaktion separat prüfen.

Verwaltungsstatus, Versionen und Updates

Managed required / Device administrator management allowed: Die erste Regel betrifft Geräte, die nicht mehr verwaltet werden; die zweite legt Aktionen für Android-Geräte fest, auf denen Sophos Mobile selbst als Device Administrator eingesetzt ist. Dieser Verwaltungsmodus ist bei Sophos Mobile veraltet und nur für Android 9 oder älter verfügbar; für Android 10 oder neuer kann er nicht verwendet werden. Sophos empfiehlt die Migration zu Android Enterprise. Das ist eine Grenze dieses Sophos-Mobile-Verwaltungsmodus, keine Aussage, dass Android-Device-Administrator-APIs generell entfernt wurden, und keine Anleitung zur Neuaufnahme solcher Geräte.
Minimum SMC version: Früheste zulässige Version der Sophos Mobile Control-App, für Android und iPhones/iPads. Nicht mit der IXM- oder OS-Version verwechseln.
Minimum OS version / Maximum OS version: Früheste beziehungsweise neueste zulässige Betriebssystemversion. Der Katalog nennt bei diesen beiden Einträgen keine eigene Plattformliste; die Verfügbarkeit in der jeweiligen Plattform-Registerkarte prüfen.
Mandatory OS updates: Für beaufsichtigte iPhones/iPads, nicht für Apple User Enrollment. Latest available update verlangt das neueste verfügbare Update; Latest critical update das neueste von Apple als kritisch eingestufte Update. Das neueste verfügbare Update kann neuer sein als das neueste kritische. Latest critical update ist ab iOS/iPadOS 27 nicht verfügbar. Für die Update-Verwaltung dieser Geräte nennt Sophos eine deklarative Richtlinie mit Software update settings oder Enforced software update; daraus keine unveränderte Wirkung der bisherigen Compliance-Auswahl ableiten. Software update settings setzt iOS/iPadOS 26 oder neuer, den Verwaltungsmodus Apple Device Enrollment und ein beaufsichtigtes Gerät voraus. Für Enforced software update nennt Sophos iOS/iPadOS 26 oder neuer und Apple Device Enrollment als Voraussetzungen, jedoch keine zusätzliche Beaufsichtigungspflicht. Diese Mindestversion 26 ist von der Grenze 27 für die bisherige Auswahl Latest critical update zu unterscheiden.

Apple-Updateinformationen benötigen einen eigenen Netzpfad: Für Informationen über verfügbare Updates auf iPhone, iPad und Mac muss mesu.apple.com über HTTPS 443 erreichbar sein. Ist dieses Ziel nicht erreichbar, hat Sophos Mobile keine Updateinformationen; Compliance-Regeln zu verpflichtenden Updates haben dann keine Wirkung. Mit der Netzwerkadministration den tatsächlichen Pfad prüfen, bevor ein solcher Regelstatus als verlässlich eingeordnet wird. Das erweitert nicht die oben genannten Plattform-, OS- oder Enrollment-Grenzen von Mandatory OS updates und behauptet nicht, dass sämtliche Apple-Updateinstallationen ausfallen.

Geräteschutz und Trennung der Arbeitsdaten

Root access allowed (Android): Festlegen, ob Geräte mit Root-Rechten zulässig sind. Die dokumentierte Erlaubnis umfasst auch vom Betriebssystem als unsicher eingestufte Sony-Geräte mit Enterprise API Level 4 oder neuer sowie Samsung-Geräte mit Knox Standard SDK 5.5 (API Level 17) oder älter. Das sind historische Qualifikationen der Regelhilfe, keine Empfehlung für den heutigen Einsatz dieser Geräte.
Android Debug Bridge (ADB) allowed (Android): Festlegen, ob die Debug-Schnittstelle ADB erlaubt oder verboten ist.
Allow jailbreak (iPhone/iPad): Separat festlegen, ob Geräte mit Jailbreak zulässig sind; nicht die Android-Root-Regel übertragen.
Screen lock required (Android, iPhone/iPad, Windows): Festlegen, ob ein Gerätepasswort oder ein anderer Sperrmechanismus erforderlich ist. Unter Android zählen Pattern, PIN und Password, nicht Swipe. Bei Apple User Enrollment ist die Regel erfüllt, wenn die zugewiesene Richtlinie eine Password policies-Konfiguration enthält.
Encryption required (Android, Mac, Windows): Verschlüsselung verlangen; unter macOS bezieht sich die Regel auf FileVault-Vollverschlüsselung. iPhones und iPads sind laut Regelhilfe immer verschlüsselt und stehen nicht in der Anwendbarkeitsliste dieser Regel.
Container configured (Android): Ein Container muss eingerichtet und aktiviert sein, etwa ein Android-Arbeitsprofil oder ein Samsung-Knox-Container. Das ist ein Zustandskriterium, nicht die Reaktion Lock container.
Data roaming allowed: Datenroaming erlauben oder verbieten, für Android sowie iPhones/iPads ohne Apple User Enrollment.

Android-Verschlüsselung nicht pauschal reparieren: Die aktuelle Regelhilfe enthält noch den Hinweis auf Require PIN to start device oder Require Password to start device beim Einrichten einer Bildschirmsperre. Das belegt nicht, dass diese Start-PIN-/Start-Passwort-Option auf aktuellen Android-Versionen oder in jedem Android-Enterprise-Modus verfügbar ist. Die gesonderte KBA-000004067 beschreibt einen Fehlerfall mit dem angezeigten Standard-Verschlüsselungsschlüssel und nennt Start-PIN und manuelle Synchronisierung als Abhilfe, ohne OS-Version oder Enrollment-Modus zu spezifizieren; sie ist keine universelle Abhilfe für aktuelle Android-Versionen oder Android-Enterprise-Modi. Vor jedem Geräteeingriff den tatsächlich beobachteten Fehler, unterstützte OS-Version und Enrollment-Modus klären; keine pauschale PIN-Umstellung oder Synchronize now empfehlen.

Apps, Profile und Berechtigungen

Installed apps: Zuerst Allowed apps oder Forbidden apps wählen, dann die App-Gruppe mit den erlaubten beziehungsweise verbotenen Apps. Gilt für Android, iPhones/iPads ohne Apple User Enrollment, Macs und Chromebooks. Android-System-Apps sind immer erlaubt; Chrome-OS-App-Gruppen können Apps und Erweiterungen enthalten.
Mandatory apps: Aus der Liste die App-Gruppe auswählen, deren Apps installiert sein müssen. Chrome-OS-Gruppen können auch Erweiterungen enthalten. Unter iOS keine System-Apps als Pflicht-Apps eintragen: Sophos Mobile kann deren Installation nicht erkennen und setzt laut Regelhilfe alle betroffenen Geräte auf nicht konform. Für Android beschreibt Sophos in SMCAND-3159, dass parallele App-Updates während einer Synchronisierung der Control-App mit dem Mobile-Backend den Status kurzzeitig auf nicht konform und wieder auf konform wechseln lassen können, besonders bei älteren Geräten. Zur lesenden Einordnung die tatsächlich verletzte Regel, den Zeitpunkt der Updates und der Synchronisierung sowie den danach beobachteten Status vergleichen. Das ist kein Grund, die Pflicht-App-Regel abzuschwächen. Aus einem später konformen Status weder folgenlosen Betrieb noch wiederhergestellten App-, Mail- oder Wireless-Zugriff ableiten; die dokumentierte automatische Rückkehr zur Konformität ist kein hier beobachtetes Ergebnis und keine garantierte Frist.
Suspicious apps allowed (Android): Festlegen, ob von IXM erkannte verdächtige Apps zulässig sind. Das ist eine eigene Compliance-Auswahl, nicht automatisch gleichbedeutend mit Scan-Einstellungen für Apps mit geringer Reputation.
Third-party profiles allowed (iPhone/iPad, ohne Apple User Enrollment): Festlegen, ob Konfigurationsprofile zulässig sind, die nicht von Sophos Mobile verwaltet werden.
Unmanaged apps from unknown sources allowed (iPhone/iPad): Festlegen, ob manuell über eine IPA-Datei installierte, selbst entwickelte Apps zulässig sind, die mit einem Ad-hoc-Provisioning-Profil signiert sind. Nicht mit der Chromebook-Regel für Apps ausserhalb des Chrome Web Store gleichsetzen.
SMC permissions can be denied (Android): Die Control-App benötigt für ihre Funktion Berechtigungen, die bei der Installation erteilt werden müssen. Die Regel legt fest, ob deren Verweigerung einen Compliance-Verstoss auslöst. Das ist eine andere App als bei Intercept X for Mobile permissions can be denied oben.
Locate permission required (Android): Für die Funktion Locate festlegen, ob die bei der Installation erteilte Berechtigung der Control-App zum Abrufen von Standortdaten für Konformität erforderlich ist.
App is able to locate (iPhone/iPad): Standortdienste müssen eingeschaltet sein und die Control-App muss sie nutzen dürfen. Diese Kombination ist vom Android-Installationskriterium getrennt. Keine der Standortregeln erteilt eine organisatorische oder rechtliche Freigabe zur Standorterfassung.

Chromebook, Mac und Windows gezielt prüfen

Chromebooks: Die folgenden Regeln betreffen Sophos Chrome Security, nicht die Android-Control-App:

Tamper protection turned off: Reaktionen für den Fall auswählen, dass die Chrome Security policy manipuliert wurde.
Minimum Sophos Chrome Security version: Früheste zulässige Version der Chrome-Security-Erweiterung festlegen.
Apps from unknown sources allowed: Festlegen, ob Apps und Erweiterungen ausserhalb des Chrome Web Store zulässig sind.

Macs: Die Kriterien beziehen sich auf den jeweiligen eingeschalteten Schutz, nicht auf einen Nachweis, dass die Compliance-Regel ihn selbst einschaltet:

Firewall required: Die macOS-Firewall muss eingeschaltet sein.
System Integrity Protection required: SIP muss eingeschaltet sein. Diese macOS-Schutzfunktion begrenzt die Aktionen des Root-Benutzers; ihre Konfiguration ist beim Start aus macOS Recovery möglich. Hieraus folgt keine Freigabe, SIP im laufenden Betrieb zu ändern.
Security updates required: Die automatische Installation von macOS-Sicherheitsupdates muss eingeschaltet sein. Die Regelhilfe begrenzt dies auf macOS 26 (Tahoe) oder älter; diese Grenze ist nicht die iOS/iPadOS-27-Grenze der mobilen Update-Regel.

Windows-Computer: Drei getrennte Defender-Kriterien auswählen und nicht aus einem einzigen Status ableiten:

Windows Defender must be turned on: Der Echtzeitschutz von Windows Defender muss eingeschaltet sein. Dieses beabsichtigte Kriterium bleibt bestehen. Für Windows 10 beschreibt Sophos in SMCSRV-13801 jedoch eine Prüfgrenze: Die Regel prüft nur, ob der Defender-Dienst läuft, nicht ob der Echtzeitschutz eingeschaltet ist. Ein Gerät kann deshalb trotz ausgeschaltetem Schutz als konform erscheinen. Bevor man sich auf den Schutz verlässt, den tatsächlichen Echtzeitschutz am betreffenden Windows-10-Gerät separat und nur lesend prüfen, ohne Schutzschalter oder Richtlinien zu ändern. Ein laufender Dienst und der Compliance-Status ersetzen diese Geräteprüfung nicht.
Clean status from Windows Defender required: Das Gerät ist nicht konform, wenn Windows Defender Warnungen anzeigt.
Up-to-date Windows Defender definitions required: Windows Defender muss die neuesten Spyware-Definitionen verwenden.

Reaktionen nicht mit der Regel verwechseln

Create alert erstellt in der Vollausgabe ein auf der Gerätedetailseite sichtbares Ereignis und einen Alarm; Threat Defense beschreibt Alarme in Sophos Fusion. Alarmierung ist keine konfigurierte E-Mail- oder Containersperre. Nur Create alert auszuwählen garantiert aber weder unveränderte Geräte-Health noch unveränderten Wireless-Zugang; auch andere Folgen einer Nichtkonformität sind möglich.
Deny email ist eine konfigurierte Reaktion auf eine verletzte Richtlinienregel in der Vollausgabe; sie setzt eine konfigurierte Verbindung zum Sophos Mobile EAS Proxy voraus und ist für Android, iPhone/iPad und Windows vorgesehen. Ein vorhandener EAS Proxy allein beweist weder die Authentifizierung des jeweiligen Maildienstes noch die tatsächlich unterbrochene oder wiederhergestellte Zustellung. Davon getrennt beschreibt Sophos eine Exchange-Quarantäne für nicht eingeschriebene Geräte nur bei EAS Proxy im PowerShell-Modus und entsprechend konfigurierter Exchange-Standardzugriffsregel. Dort können auch eingeschriebene Geräte in Quarantäne geraten, wenn dem Proxy ihr Compliance-Status nach zu langer Synchronisierung oder wegen fehlender Verbindung zu Sophos Mobile unbekannt ist. Die von Exchange im Quarantäneablauf verschickte Einschreibungsbenachrichtigung ist weder Create alert noch ein Beleg für ausgelöstes Deny email. Weder allgemeine Quarantäne noch automatischen Mail-Rückweg aus einer Regelverletzung oder einem Alarm ableiten; die Untersuchung gehört zur Incident-Reaktion, nicht zu dieser Richtlinienplanung.
Lock container ist in der aktuellen Vollausgabe für Android Enterprise vorgesehen, nicht als gesicherte iOS-Containersperre. Die Compliance-Aktion der Vollausgabe wird in der allgemeinen Aktionstabelle als Sperre aller Apps ausser Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages und Phone beschrieben. Diese allgemeine Beschreibung klärt die Wirkung auf Apps im privaten BYOD-Profil nicht; weder die sechs Ausnahmen noch das nachstehende Arbeitsprofil-Beispiel belegen, dass private Apps zugänglich bleiben. Für ein unterstütztes Android-Arbeitsprofil dokumentiert Sophos bei der separaten Zugriffssteuerung Auto (Standard ohne manuelle Zugriffsberechtigung: Arbeitsprofil gesperrt, wenn eine verletzte Compliance-Regel Lock container enthält), Deny (Arbeitsprofil gesperrt) und Allow (Arbeitsprofil entsperrt). Bei Sperre sind Apps und Daten des Arbeitsprofils nicht zugänglich; die Einstellung wird erst nach Gerätesynchronisierung angewendet. Diese Arbeitsprofil-Zugriffssteuerung ist vom Befehl zur Sperre des ganzen Geräts zu unterscheiden; sie belegt weder die Wirkung der konfigurierten Compliance-Aktion auf private Apps noch deren Verfügbarkeit für jedes BYOD-/Enrollment-Szenario oder einen getesteten Rückweg. Zielbereich und Wirkung am autorisierten Gerät vor einer Freigabe prüfen.
Set health und berechnete Health auseinanderhalten: Set health ist in der Vollausgabe eine ausdrücklich gewählte Aktion pro Regel: Bei deren Verletzung wird der gewählte Wert Rot/Gelb/Grün zugeordnet; bei mehreren verletzten Regeln gilt der schlechteste zugeordnete Health-Wert. Die Aktion setzt für Android, iPhone und iPad eingeschaltete Synchronized Security voraus; für eine beabsichtigte Wireless-Wirkung müssen ausserdem der Health-Wert für Nichtkonformität in der Richtlinie und die Wireless-Regeln konfiguriert sein. Daneben zeigt Fusion eine auf Compliance-Regelverletzungen beruhende Geräte-Health an; bei eingeschalteter Synchronized Security kann sie manuell überschrieben werden, während Auto zur Berechnung aus dem Compliance-Status zurückkehrt. Nicht geklärt ist, welcher Wert ohne Set-health-Aktion in jeder Ausgabe und jedem Modus entsteht oder wie eine manuelle Überschreibung und eine gleichzeitige Regelaktion priorisiert werden; weder eine automatische Rot-/Gelb-Zuweisung noch unveränderte Health aus Create alert ableiten. Verletzte Regel/Nichtkonformität, gespeicherte Set-health-Aktion, angezeigte Health samt manuell/Auto, an Wireless gemeldeter Wert und tatsächlicher Zugang sind getrennt zu prüfen. Sophos Wireless kann je nach Konfiguration den Netzwerkzugang beschränken; eine Konsolenanzeige allein beweist keine bestimmte Wireless-Wirkung.
Transfer task bundle kann Geräte fehlkonfigurieren oder sogar löschen. Keine Wipe-/Reset-Aufgaben oder automatische Task-Bundles als Standardreaktion hinterlegen; None bedeutet hier nur, dass kein Task-Bundle übertragen wird, nicht dass Nichtkonformität folgenlos bleibt.

Sonderfall: Bei einem nicht konformen Android Enterprise fully managed-Gerät werden in der Vollausgabe automatisch alle Apps deaktiviert, unabhängig von der gewählten Reaktion pro Regel. Das ist weder mit der konfigurierbaren Aktion Lock container gleichzusetzen noch ein belegter Effekt für Android-BYOD-/Work-Profile-Geräte, MTD-only oder andere Android-Modi. Bei Android BYOD bleibt die Wirkung von Lock container vom tatsächlich unterstützten Verwaltungsmodus und der Konfiguration abhängig; keine Gerätesperre aus einer möglichen Arbeitsbereichs-Sperre ableiten. Zugänglichkeit von Telefon, Arbeitsbereich, Recovery und kritischen Apps vor jeder Freigabe am autorisierten Testgerät prüfen.

Synchronized Security ist nicht für alle Geräte verfügbar: Sophos schliesst Chromebooks, Apple User Enrollment und Geräte mit netzwerkspezifischer/privater bzw. randomisierter MAC-Adresse aus, weil sie ihre MAC-Adresse nicht an Sophos Mobile melden. Die separate Möglichkeit, bei einem Drittanbieter-EMM die MAC-Adresse per IXM-App-Konfiguration zu übergeben, belegt keine Ausnahme für private/randomisierte MAC-Adressen. Einen Wireless-Pilot nur für einen tatsächlich unterstützten Geräte-/Enrollment-Modus mit geprüfter MAC- und Synchronized-Security-Konfiguration planen; eine Health-Anzeige allein ersetzt keinen Zugangstest.

Stufenweise zuweisen statt global testen

Bestand und Voraussetzungen erfassen: Mandant, Lizenz/Ausgabe, Verwaltungsmodus, Plattform/OS, Eigentum, IXM-Verwaltungsstatus, letzte Synchronisierung, bisherige Regeln und aktive Abhängigkeiten zu EAS Proxy und Sophos Wireless festhalten. Synchronized-Security-Eignung und MAC-Grenzen, angezeigte Geräte-Health samt manuell/Auto, vorhandene Wireless-Regeln sowie Richtlinien und Zuordnungen dokumentieren.
Regel und Aktion einzeln bewerten: Den aktuellen Regelkatalog der richtigen Produktausgabe öffnen; für jede aktivierte Plattform jede aus der Vorlage übernommene oder manuell gesetzte Regel samt Reaktion inventarisieren. Signal, Modus und Aktionsvoraussetzung vor Save und vor Zuweisung prüfen; PCI/HIPAA nicht für passiv halten. Für einen genehmigten Pilot eine neue, isolierte Richtlinie ohne sperrende/destruktive Aktionen planen und ihre tatsächlich gespeicherten Aktionen erneut kontrollieren. Fehlt Set health, ist damit weder unveränderte berechnete/manuelle Health noch unveränderter Wireless-Zugang nachgewiesen. Wichtig: Auch Create alert allein oder None bei einem Task-Bundle verhindert bei einem nicht konformen Android Enterprise fully managed-Gerät nicht die dokumentierte automatische App-Deaktivierung. Solche Geräte aus diesem Pilot ausschliessen, bis ein gerätespezifischer Test von App-Zugänglichkeit und Recovery für die tatsächliche Version und den Modus autorisiert und vorbereitet ist.
Begrenzte Pilotgruppe auswählen: Die geplanten Firmen- und Privatgeräte getrennt betrachten. Falls für den genehmigten Pilot eine neue Gruppe nötig ist, zuerst die Gerätegruppe vorbereiten und ihren Scope abgleichen. Werden beide Eigentumsarten verwaltet, empfiehlt Sophos eigene Compliance-Richtlinien für Firmen- und Privatgeräte; zwei getrennte Zuweisungsfelder allein bedeuten noch nicht, dass unterschiedliche Richtlinien verwendet werden. Unter Device groups > [Gruppe] > Compliance policies werden corporate und personal getrennt zugewiesen. Vor Save für jedes Zielgerät seine genau eine aktuelle Gerätegruppe (auch die vorhandene Default-Gruppe, falls zugeordnet), die Eigentumsart (corporate/personal) und die Richtlinienzuweisung dieser Gruppe auf unbeabsichtigte Reichweite prüfen. Nach Auswahl der Richtlinien für corporate und personal und Prüfung der Reichweite Save anklicken, um die Gruppenzuweisung zu speichern. Anschliessend auf der Seite Device groups für die gewählte Gruppe beide Spalten Compliance policy (corporate) und Compliance policy (personal) mit der geplanten Zuweisung vergleichen. Vor Änderung einer bestehenden, geteilten Richtlinie alle Gruppen mit dieser Richtlinienzuweisung prüfen; die Änderung kann weitere Gruppen treffen, nicht weil ein Gerät mehreren Gruppen angehört. Ein neuer isolierter Pilot darf keine gemeinsam genutzte Richtlinie stillschweigend verändern.
Wirkung im autorisierten Pilot prüfen: Vor einem absichtlich erzeugten Verstoss erneut sicherstellen, dass kein Android Enterprise fully managed-Gerät im alert-only-/aktionsfreien Pilot enthalten ist; Create alert oder None schützt dessen Apps nicht. Erst die Gruppenzuordnung und das konkrete Gerät samt neuem Compliance-Wert, verletzter Regel, Synchronisierungszeit und gegebenenfalls Alarm/Ereignis vergleichen. Am unterstützten Testgerät vor und nach dem Verstoss die tatsächlich gespeicherte Set-health-Aktion, angezeigte Health und manuell/Auto-Modus sowie bei aktivierter Synchronized Security gemeldete Health, Wireless-Regel und tatsächlichen Wireless-Zugang getrennt beobachten; Mailfluss und App-Zugänglichkeit bei relevanter Konfiguration ebenfalls prüfen. Auch ohne Set-health-Aktion keinen unveränderten Netzwerkzugang voraussetzen; eine verzögerte oder ausbleibende Synchronisierung nicht als konform deuten. Einen absichtlich erzeugten Verstoss nur mit bestätigtem Rückweg und ohne produktive Datengefährdung testen. Vor Ausweitung auf vollständig verwaltete Android-Enterprise-Geräte erst am autorisierten Gerät prüfen, ob die dokumentierte automatische Folge in der tatsächlichen Version und im Modus eintritt und ob der Rückweg funktioniert.
Erst nach Abnahme erweitern: Gegenüber dem Ausgangszustand die betroffenen Geräte und unerwartete Verstösse vergleichen. Bei Abweichungen Erweiterung stoppen, die dokumentierte frühere Gruppenzuordnung/Regel-/Aktionskonfiguration nach Freigabe wiederherstellen und die Wiederherstellung auf Gerät und externen Diensten erneut prüfen. Das Entfernen einer Regel macht bereits ausgeführte Task-Bundles, Wipes oder externe Zugriffssperren nicht automatisch rückgängig.

Nicht als Test verwenden: Compliance policies > Check now betrifft alle eingeschriebenen Geräte und führt die dort hinterlegten Aktionen aus – auch wenn nur eine kleine Gruppe beabsichtigt war. Vor einem geplanten Gesamtabgleich müssen alle Gruppen und Reaktionen geprüft und der Change genehmigt sein; dieser Artikel gibt keine Freigabe, den Knopf im Produktivmandanten zu betätigen.

Nur als Planungsbeispiel, nicht getestet: Eine eigens genehmigte Gruppe mit einem Firmen-iPhone (kein Apple User Enrollment und kein Android Enterprise fully managed), einer zuvor als anwendbar geprüften, nicht destruktiven Regel und Create alert könnte als begrenzter Pilot dienen. Vor Zuweisung alle Regel-/Aktionspaare, Gruppenmitgliedschaften und, falls Wireless Teil des Tests ist, Synchronized-Security-Eignung, MAC- und Wireless-Konfiguration erfassen. Bei einem autorisierten, reversiblen Testverstoss in der Vollausgabe Verletzung/Nichtkonformität und das Ereignis auf der Gerätedetailseite in der Konsole sowie den Konsolenalarm prüfen; in der eigenständigen Ausgabe Sophos Mobile Threat Defense den Alarm auf der Seite Alerts in Sophos Fusion prüfen. Getrennt davon die angezeigte Health (manuell/Auto) sowie am Zielgerät Mailfluss, App-Zugänglichkeit und tatsächlichen Wireless-Zugang vor und nach der Synchronisierung prüfen. Keine Erwartung unveränderter Health oder unveränderten Netzwerks allein aus Create alert ableiten. Stopp, wenn weitere Geräte betroffen sind, die Synchronisierung ausbleibt oder Health/Zugang unerwartet abweichen; keine Ausweitung, frühere Zuweisung nach Freigabe wiederherstellen und die Wirkung erneut prüfen. Das ist ein Prüfplan, kein beobachtetes Testergebnis.

Abgrenzung und Voraussetzungen für den Einsatz

Die Untersuchung eines bereits auffälligen oder gesperrten Geräts, Alarm-Triage, Fehlalarmbehandlung sowie die Wiederherstellung von E-Mail-/Wireless-Zugriff sind kein Teil dieser Anleitung zur Richtlinienplanung. Sie ersetzt keine Incident- oder Reset-Anleitung. Eine Android-Start-PIN-Massnahme oder manuelle Synchronisierung aus KBA-000004067 ist ohne Prüfung des konkreten Fehlers und der unterstützten Geräte-/Enrollment-Kombination keine allgemeine Reparatur. Für die lesende Ersttriage und die Prüfung des WLAN-Zugriffs dient die Anleitung zur Reaktion auf einen Compliance-Vorfall; auch sie erteilt keine operative Freigabe.

Die beschriebenen Abläufe sind nicht an Geräten oder in einem Mandanten validiert. Dieser Artikel erteilt keine operative Freigabe. Die Beziehung zwischen gewählter Set-health-Aktion, automatisch berechneter/manuell überschriebener Health und Wireless-Wirkung ist hier nicht für jeden Modus aufgelöst. Regel-/Aktionskombinationen pro Produktausgabe, OS und Modus sowie Rückwege für EAS/Wireless und Android-App-Zugänglichkeit müssen vor operativer Übernahme autorisiert und gerätespezifisch geprüft werden.