Sophos Mobile: Compliance-Vorfall eingrenzen und WLAN-Zugriff prüfen

Bei einem Compliance-Alarm zuerst lesen, nicht sofort erneut prüfen oder sperren. Sophos Mobile allein sperrt kein Netz; eine WLAN-Einschränkung hängt von der Konfiguration in Sophos Wireless ab. Dieser Leitfaden ist ein Prüf- und Entscheidungsweg, keine Freigabe für Befehle in einer konkreten Sophos-Umgebung.

Entscheidung im Vorfall: lesen, einordnen, weitergeben

1. Nur lesen – Befund sichern: Betroffenes Gerät und zugewiesene Richtlinie, Regelverstoss und Zeitstempel unter Compliance feststellen; Events getrennt prüfen. Nur genehmigte Gerätekennungen, Regel-/Ereigniszeiten, relevante Richtlinie und den minimal nötigen technischen Befund im freigegebenen Vorfallkanal mit dessen Zugriffs- und Aufbewahrungsregeln festhalten. Keine privaten Dateiinhalte, App-Inventare, Screenshots oder umfassenden Geräteexporte ohne gesonderte Notwendigkeit und Freigabe.
2. Nur lesen – Wirkung einordnen: App-Fund nicht mit Compliance-Verstoss oder tatsächlicher WLAN-Sperre gleichsetzen. Plattform, Verwaltungsmodus, bestätigte Lizenz/Edition, Regelaktion, Integrationsstatus und MAC-Zuordnung prüfen; WLAN-Wirkung nur anhand des betroffenen Geräts und des passenden AP/Clients beurteilen.
3. Stopp vor Änderungen: Check now, Richtlinienkorrekturen und tenantweite NAC-Aktivierung sind keine Ersttriage; an den zuständigen Richtlinien- beziehungsweise Wireless-/Netzwerk-Owner geben. Manuelle Übersteuerungen (Overrides) nur nach gerätebezogener Freigabe, dokumentiertem Ausgangswert und erwarteter Wirkung erwägen. Nach einer freigegebenen Massnahme Gerätestatus und tatsächlichen AP-/Client-Zugriff getrennt bestätigen.

Nur lesen: Regel und Ereignisse unterscheiden

Das freigegebene Zielgerät, die zugewiesene Person und – getrennt davon – den Geräteeigentümer, Plattform, Sophos-Mobile-Lizenz und Edition, Registrierungs- und Verwaltungsmodus, Gerätegruppe, Richtlinie und letzte Synchronisierung feststellen. Bei privaten Geräten nur im genehmigten Verwaltungsumfang prüfen.

In Sophos Fusion > My Environment > Mobile Devices auf den Namen des freigegebenen Geräts klicken und den Tab Compliance öffnen. Bei einem von Sophos Mobile verwalteten Gerät zeigt dieser Tab die Details der Compliance-Verstösse, wenn das Gerät nicht konform ist. Ein Gerät wird nicht konform, wenn es eine Regel seiner Compliance-Richtlinie verletzt. Für das Zielgerät gilt die Richtlinie, die seiner Gerätegruppe für die entsprechende Eigentumsart zugewiesen ist: Compliance policy (corporate) für Firmen- und Compliance policy (personal) für Privatgeräte. Die Eigentumsart des Geräts mit der passenden Gruppenzuweisung nur lesend abgleichen; die beiden Felder können unterschiedliche Richtlinien enthalten.

In der Liste bezeichnet Severity den Schweregrad des Compliance-Verstosses mit den Werten High, Medium oder Low. Type nennt den Regelverstoss, Info enthält dessen Details. Created at gibt an, wann der Compliance-Verstoss erkannt wurde. Enthält die Richtlinie beispielsweise die Regel Minimum OS version und ist die OS-Version des Geräts älter als gefordert, steht unter Type der Wert OS version too old. Unter Info stehen die erforderliche und die tatsächliche OS-Version. So kann man die Vorgabe mit dem Gerätestand vergleichen, ohne die Mindestversion als Erstreaktion zu senken.

Das Refresh-Symbol oben rechts lädt die Informationen im Tab Compliance neu. Es belegt weder einen neuen Gerätescan noch eine zugestellte Massnahme. Die Compliance-Liste bei Bedarf über die Schweregradfilter oberhalb der Liste eingrenzen; Auswahl nach dem konkreten Vorfall treffen, nicht die Beispielauswahl übernehmen.

Auf derselben Geräteseite den Tab Events öffnen. Er zeigt die Ereignisse, die dem von Sophos Mobile verwalteten Gerät zugeordnet sind. Event enthält den Ereignistext, Severity den Ereignis-Schweregrad mit den Werten High, Medium, Info oder None. Diese Werte sind nicht die Compliance-Skala. Created at gibt an, wann Sophos Mobile das Ereignis erstellt hat, nicht wann ein Compliance-Verstoss erkannt wurde. Dieser Zeitpunkt belegt keine Behebung. Prüfergebnis und tatsächlichen Gerätestatus zusätzlich auseinanderhalten.

Das Refresh-Symbol oben rechts lädt die Informationen im Tab Events neu; auch hier belegt es keinen neuen Gerätescan und keine zugestellte Massnahme. Die Events-Liste bei Bedarf über die Filter oberhalb der Liste nach Erstellungsdatum eingrenzen und den gewählten Zeitbezug im Befund festhalten. Für Ereignisse aller Geräte unter Reports > General Logs > Events nachsehen.

Android Enterprise mit vollständiger Geräteverwaltung: Wird ein solches Gerät nicht konform, werden laut Sophos alle Apps deaktiviert. Das gilt nicht pauschal für Android mit Arbeitsprofil oder reine Mobile Threat Defense. Verwaltungsmodus und mögliche Regelaktionen vor jeder erneuten Prüfung feststellen.

Check now ist kein Refresh: Die Compliance-Prüfung in Sophos Mobile und Mobile Threat Defense prüft alle registrierten Geräte und führt konfigurierte Aktionen aus. Die Richtliniendokumentation für Sophos Mobile Device Management und die kombinierte Edition Sophos Mobile beschreibt unter anderem Aufgaben-Bundle-Transfer; falsch eingesetzte Bundles können Geräte löschen. Die Richtlinien-Erstellseite von Sophos Mobile Threat Defense zeigt dagegen Create alert. Vor jeder Aktion tatsächliche Lizenz, Administrationsoberfläche, Rolle, Plattform und Modus mit dem Richtlinien-Owner klären; Check now nicht als spontanen Test auslösen.

Nur lesen: App-Fund und WLAN-Wirkung getrennt prüfen

App-Fund: Bei durch Sophos Mobile verwaltetem Sophos Intercept X for Mobile unter Android zwischen schädlicher App, potenziell unerwünschter App (PUA), Datei und App mit niedriger Reputation unterscheiden. Eine erkannte schädliche App wird gesperrt; bei einer PUA wird standardmässig auf dem Gerät gewarnt, wobei Richtlinie und Ausnahmen das Verhalten beeinflussen. Die Prüfung niedriger Reputation ist standardmässig aus; falls aktiviert, steuert Apps with low reputation Warnung oder Zugriffssperre. Ob App-/PUA-Funde die Konformität beeinflussen, bestimmen gesondert Malware apps allowed und PUAs allowed. Diese Android-Erkennungsfolgen nicht auf iOS übertragen.

Für die lesende Prüfung der einzelnen Einstellungen dient die Android-Schutzrichtlinie. Ist Detect PUAs ausgeschaltet, findet keine PUA-Prüfung statt. Enable user to allow PUAs erlaubt Benutzerfreigaben, durch die eine App bei späteren PUA-Scans ignoriert wird. Die gewählte App group kann einzelne Apps von der PUA- oder Reputationsprüfung ausschliessen. Solche Ausnahmen beheben keinen Fund und sind keine Erstreaktion im Vorfall. Konkreten Fund, Regel und Richtlinieneinstellungen vergleichen: Ein PUA-Hinweis belegt weder Malware noch eine WLAN-Sperre.

Schädliche Dateien: Scan storage ist standardmässig aus. Ist es eingeschaltet, warnt IXM bei einem Fund auf dem Gerät, blockiert die Datei aber nicht und bereinigt sie nicht automatisch. Zum Entfernen muss die betroffene Person die Datei manuell löschen. Verdächtige Dateien nicht pauschal entfernen lassen; eine etwaige Entfernung durch die betroffene Person erst nach gerätespezifischer Freigabe, Prüfung des nötigen Belegs und des möglichen Datenverlusts anleiten. Private Dateiinhalte nicht als Routinebeleg sammeln.

Ist die Integration aktiv? Bei Synchronized Security tauschen Sophos-Produkte sicherheitsrelevante Informationen über den Security Heartbeat aus. Sophos Wireless kann den Sophos-Mobile-Compliance-Status von Android- und iOS-Geräten für eine Einschränkung des Netzwerkzugriffs verwenden; eine solche Einschränkung setzt eine dort konfigurierte gesundheitsbasierte Zugriffsregel voraus. Für diesen dokumentierten Wireless-Pfad nennt Sophos ausschliesslich APX 320, APX 530 und APX 740. Nur wenn eine bestehende Umgebung diese Integration verwendet, die dort registrierten Access Points in Sophos Fusion, die Wireless-Regel, eingeschaltete NAC-Integration und eine der Gerätegruppe zugewiesene Compliance-Richtlinie prüfen. Diese Legacy-APX-Abhängigkeit liegt ausserhalb der Mobile-Prüfung und ist keine Empfehlung für eine neue APX-Installation. Ein Mobile-Gesundheitsstatus oder eine eingeschaltete Mobile-NAC-Integration belegt weder diese Integration auf AP6 noch deren Unterstützung dort. Die Einstellung Setup > Sophos setup > Network Access Control > Sophos Wireless > Save ist eine tenantweite Änderung, kein Schritt der lesenden Triage.

Ist dieses Gerät zuordenbar? Synchronized Security kann auch bei Geräten mit Registrierung über Drittanbieter-EMM verwendet werden: Dafür muss die benutzerdefinierte App-Konfiguration von Intercept X for Mobile die MAC-Adresse des Geräts enthalten, damit der Sophos APX Series Access Point es identifizieren kann. Das nicht als Nachweis einer funktionierenden Zuordnung im konkreten WLAN verstehen. Fehlende oder netzspezifische MAC-Adressen verhindern die vorgesehene Zuordnung. Die Dokumentation für Device Management/kombiniertes Mobile nennt Chromebooks, Apple User Enrollment und Geräte mit Private address oder Randomized MAC als Einschränkungen; die Threat-Defense-Seite nennt Chromebooks und private/randomisierte MAC-Adressen, aber Apple User Enrollment nicht ausdrücklich. Daraus keine Unterstützung für diesen Modus in Threat Defense ableiten. Set network access in der Dokumentation für Device Management/kombiniertes Mobile schliesst zudem Macs und Apple User Enrollment aus.

Welche Edition und Regelaktion sind belegt? Laut Synchronized-Security-Seite wird in der Compliance-Richtlinie der Gesundheitsstatus festgelegt, den ein Gerät bei Nichtkonformität erhält; für einzelne Regeln können unterschiedliche Gesundheitsstatus gesetzt werden. Die Richtlinien-Erstellseite von Sophos Mobile Threat Defense zeigt dagegen nur Create alert. Eine automatische MTD-Regel-zu-Gesundheitsstatus-zu-WLAN-Sperre ist hier nicht belegt und darf nicht als Vorfallmassnahme vorausgesetzt werden. Lizenz/Edition, Administrationsoberfläche und tatsächlich verfügbare Regelaktion mit Richtlinien- und Wireless-/Netzwerk-Owner klären.

Nur nach Freigabe: eng begrenzte Änderungen

Vor einer Änderung durch die jeweils berechtigte Rolle Zielgerät, Lizenz/Edition, Plattform und Modus, vorhandene manuelle Übersteuerungen, Ausgangswerte beider Einstellungen, erwartete Wirkung, Zustellung und Prüfmethode dokumentieren. Richtlinienänderungen und Check now gehören zum Richtlinien-Owner; der Leitfaden zur Planung und Prüfung von Compliance-Richtlinien beschreibt diese separate Aufgabe, erteilt aber keine operative Freigabe. NAC-Integration und Wireless-Regeln gehören zum Wireless-/Netzwerk-Owner. Eine gerätebezogene Freigabe für die folgenden Einstellungen ist keine pauschale Freigabe für solche tenantweiten Änderungen.

Tenantweite NAC-Änderung: Nur wenn der dokumentierte Wireless-Pfad auf die bestehende Umgebung zutrifft, öffnet der zuständige Wireless-/Netzwerk-Owner nach gesonderter Freigabe unter Setup > Sophos setup den Tab Network Access Control. Vor jeder Änderung hält er die dort tatsächlich gespeicherte bisherige Integrationsauswahl und die genehmigte Zielauswahl im Änderungsnachweis fest – getrennt von den gerätebezogenen Netzwerkzugriffs- und Gesundheitsstatus-Overrides. Die Sophos-Anleitung Turn on Synchronized Security dokumentiert nur das Einschalten, keinen Rückweg. Deshalb bereits vor dem Einschalten prüfen, ob die bisherige Auswahl in der tatsächlichen Oberfläche wieder wählbar ist und ihre Wiederherstellung für diese Umgebung dokumentiert unterstützt wird. Fehlt ein solcher Rückweg oder ist er unklar, nicht aktivieren, sondern mit dem Wireless-/Netzwerk-Owner und Sophos Support klären. Sind diese Voraussetzungen erfüllt, Sophos Wireless auswählen und mit Save speichern; danach den Tab Network Access Control erneut öffnen und die gespeicherte Auswahl mit dem genehmigten Ziel vergleichen. Den tatsächlichen Zugriff der betroffenen Wireless-Clients am passenden AP/Client separat prüfen: Weder Save noch ein Gesundheitsstatus belegt die WLAN-Wirkung.

NAC-Rücknahme: Bei einer Abweichung weitere Änderungen stoppen. Nur nach Freigabe und bei bestätigtem, dokumentiert unterstütztem Rückweg im selben Tab exakt die zuvor festgehaltene Integrationsauswahl wieder wählen, mit Save speichern und nach erneutem Öffnen mit dem Ausgangswert vergleichen; den betroffenen AP-/Client-Zugriff nochmals getrennt prüfen. Ist die frühere Auswahl nicht verfügbar oder ihre Wiederherstellung nicht dokumentiert unterstützt, keine Abwahl, keinen Ausschalter und keinen Reset als Rückweg unterstellen, sondern zum Wireless-/Netzwerk-Owner und Sophos Support eskalieren. Auto mode und die Rücknahme von Geräte-Overrides stellen die tenantweite NAC-Auswahl nicht wieder her. Diese Sicherungen sind ein vorsorglicher Prüf- und Rücknahmeplan, nicht in einem Tenant oder Labor getestet und kein Nachweis erfolgreicher Wiederherstellung.

• Netzwerkzugriff (Dokumentation für Sophos Mobile Device Management/kombiniertes Mobile; Verfügbarkeit in der konkreten Umgebung bestätigen): Nach gerätebezogener Freigabe und Dokumentation des Ausgangswerts:
  1. Devices öffnen und auf der Geräteliste ausschliesslich das identifizierte und freigegebene Zielgerät auswählen. Die Auswahl mit der Freigabe abgleichen; Mehrfachauswahl nur mit ausdrücklich geprüfter Geräteliste und Freigabe.
  2. Actions > Set network access wählen.
  3. Den freigegebenen Wert auswählen: Allow erlaubt Zugriff unabhängig vom Compliance-Status, Deny verweigert ihn unabhängig davon; Auto mode koppelt ihn an die Konformität. Allow kann eine Sicherheitsregel übersteuern und behebt keinen Regelverstoss.
  4. Zielauswahl und gewählten Wert nochmals prüfen, dann mit Yes speichern. Anschliessend den gespeicherten Netzwerkzugriffswert, den Gerätestatus und den tatsächlichen AP-/Client-Zugriff getrennt prüfen; die Bestätigung allein belegt keine WLAN-Wirkung.
• Gesundheitsstatus (Mobile oder Threat Defense mit eingeschalteter Synchronized Security; Berechtigung und Verfügbarkeit bestätigen): Nach gerätebezogener Freigabe und Dokumentation des Ausgangswerts:
  1. In der Menüleiste Devices öffnen und auf den Namen des identifizierten und freigegebenen Geräts klicken.
  2. Auf der Seite Show device die Aktion Actions > Set health status wählen.
  3. Den freigegebenen Gesundheitsstatus auswählen. Manuelles Red kann unabhängig vom Compliance-Status gesetzt werden; Auto mode nimmt nur diese manuelle Gesundheitsstatus-Übersteuerung zurück und berechnet den Status aus der Konformität.
  4. Sophos Mobile meldet den Gesundheitsstatus des Geräts an Sophos Wireless. Die Wireless-Regel bestimmt eine mögliche Sperre; deshalb den tatsächlichen Gerätestatus und den AP-/Client-Zugriff getrennt prüfen. Für mehrere Geräte auf der Seite Devices die Geräte auswählen und Actions > Set health status wählen. Das ist nur mit ausdrücklich geprüfter Geräteliste und Freigabe zulässig.

Rücknahme der Geräte-Overrides: Für jede der beiden Geräteeinstellungen den zuvor dokumentierten Wert wiederherstellen – Auto mode nur dann, wenn es dort der Ausgangswert war. Für den Netzwerkzugriff auf Devices dieselbe geprüfte Zielauswahl treffen, Actions > Set network access öffnen, den dokumentierten Ausgangswert wählen und nach erneuter Prüfung von Auswahl und Wert mit Yes speichern. Anschliessend den gespeicherten Netzwerkzugriffswert und den tatsächlichen AP-/Client-Zugriff erneut prüfen. Die Rücknahme eines Gesundheitsstatus-Overrides hebt keinen separaten Allow/Deny-Override auf und beseitigt keinen Regelverstoss. Zustellung, tatsächlichen Gerätestatus und AP-/Client-Zugriff separat beobachten; ein grüner Status beweist keine WLAN-Verbindung.

Ursache und Ergebnis nachverfolgen – destruktive Schritte ausklammern

Bei Sophos Mobile Control kann die betroffene Person eine Benachrichtigung und im Dashboard Verstösse mit Fix it sehen. Der Link im Self Service Portal ist nur für unterstützte Gerätetypen sichtbar; die Dokumentation nennt die ausgeschlossenen Typen nicht. Ein fehlender Link beweist keine Konformität. Verwaltetes Intercept X für Android oder iOS kann Verstoss und Hinweise anzeigen; Einschränkungen von Netz oder Funktionen sind möglich, nicht garantiert. Benutzeranweisungen erst mit der konkreten Regel abgleichen. Ein Klick in der App hebt keinen administrativen Override auf.

Compliance-Verstösse in Intercept X unter Android und iOS anzeigen

Wenn Sophos Intercept X for Mobile unter Android oder iOS von Sophos Mobile verwaltet wird, zeigt das lokale App-Dashboard den Compliance-Status anhand der Richtlinie der Organisation. Die betroffene Person öffnet die Hinweise auf ihrem Gerät wie folgt:

1. Im Dashboard auf die Kachel Corporate management tippen. Bei Compliance-Verstössen hat diese Kachel ein rotes Symbol.
2. Auf den einzelnen Compliance-Verstoss tippen, um dessen Anweisungen zu öffnen. Vor dem Befolgen die Hinweise mit der konkreten Regel und der gerätespezifischen Freigabe abgleichen. Unklare oder riskante Massnahmen mit dem Richtlinien-Owner klären. Sind die Massnahmen freigegeben, die angezeigten Anweisungen zur Behebung dieses Verstosses befolgen.

Das rote Symbol gehört zur Corporate management-Kachel. Unter Android ist es von der Bewertung Insecure unter Device security zu unterscheiden; auf beiden Plattformen belegt es weder einen manuell gesetzten Gesundheitsstatus Red noch eine tatsächliche WLAN-Sperre. Das Öffnen der Hinweise behebt keinen Verstoss und nimmt keinen administrativen Override zurück. Auch das Befolgen der Anweisungen garantiert weder die Behebung noch einen wiederhergestellten WLAN-Zugriff; die unten beschriebenen Ergebnisprüfungen bleiben erforderlich. Dieser Klickpfad gilt für die verwaltete Android- und iOS-App, nicht für Sophos Mobile Control oder das Self Service Portal.

Compliance-Verstösse im Self Service Portal anzeigen

Dieser Weg ist für die betroffene Person im Self Service Portal vorgesehen, nicht für Aktionen in Mobile Admin:

1. Die betroffene Person meldet sich im Sophos Central Self Service Portal an, öffnet Mobile und wählt ihr eigenes betroffenes Gerät aus.
2. Neben Compliance Status klickt sie auf den Link Noncompliant, um die Compliance-Verstösse anzuzeigen. Der Link ist nur verfügbar, wenn das Gerät nicht konform ist. Die oben genannte Einschränkung auf unterstützte Gerätetypen gilt zusätzlich.

Damit das Gerät wieder konform wird, muss die betroffene Person die notwendigen Massnahmen auf ihrem Gerät durchführen. Bevor man sie dazu anleitet, gleicht man die angezeigten Verstösse mit der konkreten Regel ab und klärt die gerätespezifische Freigabe. Das Öffnen des Links behebt keinen Verstoss, hebt keinen administrativen Override auf und belegt keinen wiederhergestellten WLAN-Zugriff. Unklare oder riskante Massnahmen mit dem zuständigen Richtlinien-Owner klären, statt Schutzvorgaben zu umgehen oder destruktive Schritte auszulösen. Die anschliessenden Ergebnisprüfungen bleiben separat erforderlich.

Bei möglichem Fehlalarm Regel, Ausnahmen, Gruppenzuordnung, OS-Schwelle, minimal nötigen App-Fund, Synchronisierung, relevante Berechtigungen, MAC-Zuordnung und vorhandene Overrides mit den freigegebenen Vorfalldaten vergleichen. Eine falsche Richtlinienbewertung nur durch den Richtlinien-Owner gezielt korrigieren lassen. Nach einer freigegebenen Korrektur unter Compliance, Events und gegebenenfalls in der Benutzer-App erneut nachsehen; den tatsächlichen WLAN-Zugriff am passenden AP/Client separat prüfen. Bleibt der Status widersprüchlich, vor weiteren Änderungen eskalieren.

Stopp vor destruktiven Schritten: Wipe, Factory Reset, Löschen des Geräteeintrags, Unenroll, Entfernen des Arbeitsprofils und Aufgaben-Bundle-Transfer sind keine Erstreaktion und nicht durch Auto mode rückgängig zu machen. Sie gehören in einen separaten, autorisierten Prozess: Bei Geräteverlust dient der Entwurf zur Lost-Device-Sicherheitsentscheidung der Abwägung vor einer Freigabe; bei Benutzerwechsel oder -löschung ist die Benutzerzuweisung und das Offboarding separat zu prüfen. Keiner dieser Verweise erteilt eine gerätespezifische Freigabe. Der jeweilige Prozess erfordert die Prüfung von Eigentum und Privatdaten, Verwaltungsmodus, Backup und Datenverlust-Freigabe, Android FRP beziehungsweise Apple Activation Lock, Wiederherstellungszugängen sowie Auftragszustellung und beobachtetem Abschluss. Ein erneuter Löschversuch ist besonders gefährlich: Das Löschen eines registrierten, vollständig verwalteten Android-Enterprise-Geräts kann einen Werksreset auslösen. Der Wipe-Umfang hängt von Konsole und Modus ab; bei Android mit Arbeitsprofil beschreibt Fusion das Entfernen des Arbeitsprofils, nicht einen generischen Werksreset. Ein fernbedientes Lock ist kein Test bei einem Compliance-Vorfall: Bei einem Android-Enterprise-Gerät mit Arbeitsprofil sperrt es das ganze Gerät, nicht nur das Arbeitsprofil; ein per Fernzugriff gesperrter Mac kann danach nicht per Wipe gelöscht werden. Ohne gerätespezifische Freigabe hier stoppen.