Sophos Mobile Threat Defense auf Android: Schutzrichtlinie sicher planen

Entwurf – keine freigegebene Betriebsanweisung. Eine Mobile Threat Defense-Richtlinie für Android konfiguriert Sophos Intercept X for Mobile (IXM), wenn die App bei Sophos Mobile registriert ist. Sie ist weder eine Android-Enterprise-Geräterichtlinie noch ein Beleg für vollständige MDM-Verwaltung, Webfilterwirkung oder die Intune-MTD-Integration. Sophos Mobile Threat Defense berechtigt zur Verwaltung von IXM und Sophos Chrome Security, Sophos Mobile enthält die Funktionen von Device Management und Threat Defense. Sophos Mobile Device Management allein ist kein MTD-Anspruch: Für die hier beschriebene IXM-Verwaltung ist eine Sophos-Mobile- oder Sophos-Mobile-Threat-Defense-Lizenz erforderlich. Lizenz, Adminrechte, App-Registrierung und Gerätemodus im tatsächlichen Tenant feststellen. Die Mobile-Lizenzentscheidung erklärt den Abgleich unter Profile icon > Licensing in Sophos Fusion.

Auf durch Sophos Mobile verwalteten Android-Enterprise-Geräten installiert die MTD-Richtlinie IXM; vor ihrer Zuweisung muss die App in Sophos Mobile als verwaltete Google-Play-App hinzugefügt sein. Diese Voraussetzung gehört zum Mobile-Enterprise-Verwaltungsweg, nicht pauschal zu jedem App-only-Threat-Defense-Tenant. Den Play-Katalogeintrag, die Android-Enterprise-Anbindung und den begrenzten Installationsnachweis nach Managed Google Play vorbereiten und Apps bereitstellen prüfen; dabei keine gemeinsam genutzte App-Konfiguration ungeprüft verändern. Bei einem anderen Registrierungsweg die Installation und IXM-Registrierung getrennt prüfen; eine sichtbare App ist noch kein Nachweis beider Schritte.

Stopp vor Webfilter-Zuweisung: Bei Android Enterprise mit Arbeitsprofil gilt die Android-MTD-Konfiguration Web Filtering nicht: IXM im Arbeitsprofil kann den dafür erforderlichen Sophos Accessibility Service nicht erreichen. Weder ein gespeicherter Richtlinieneintrag noch eine sichtbare App macht sie dort wirksam. Ist Web Filtering auf einem geeigneten Gerät aktiviert, sperrt es alle Websites, wenn https://4.sophosxl.net/lookup nicht erreichbar ist. Zugriff auf den Klassifizierungsdienst, Accessibility-Freigabe, geeignete Browser, unabhängigen Rückkanal und engen Pilot vor dem Aktivieren prüfen. Keine Arbeitsprofil-Ausnahme durch ungeprüfte Verlagerung in den privaten Bereich behaupten.

Umfang und Entscheidung vor dem Ändern

1. Tenant, Edition und tatsächliche MTD-Lizenz, Rolle, Gerät/Android-Version, Android Enterprise vollständig verwaltet, Arbeitsprofil oder getrennt geprüfter App-Verwaltungsmodus, IXM-Registrierung bei Sophos Mobile und bestehenden Richtlinienstand erfassen. Persönliches Eigentum ist nicht gleich Arbeitsprofil, und MTD ist nicht automatisch MDM. Drittanbieter-EMM-Geräteregistrierung ersetzt die Sophos-Mobile-Registrierung der IXM-App nicht. Der separate Weg zur automatischen IXM-Registrierung über Drittanbieter-EMM setzt benutzerdefinierte App-Einstellungen, eine vorbereitete IXM-Enrollment-Konfiguration und einen Connection code voraus. Dieser Weg ist nicht mit bereits konfiguriertem Intune Mobile Threat Defense kombinierbar; das ist keine pauschale Sperre für jedes Intune-verwaltete Gerät. Den passenden Weg, die Code-/Benutzerzuordnung, Installation und Registrierung nach Intercept X for Mobile registrieren klären. Hier werden weder dieser EMM-Enrollment-Ablauf noch ein beliebiger EMM-Anbieter freigegeben. Die unterstützte Kombination aus Android-Version, Edition und App-Modus vor Ort bestätigen; nicht aus dem Richtlinientitel ableiten.
2. Nur für den freigegebenen Testkreis den betroffenen Policy-Typ, die Geräte- oder Gruppenmitgliedschaft, die nötigen App-Freigaben und den bisherigen Zustand aufnehmen. Erstellung, Zuweisung, Konflikt-/Gruppenlogik und Rückbau sind ein eigener Ablauf unter Richtlinien zuweisen: Policies > [Plattform] > Create, den passenden MTD-Typ wählen, Name und Beschreibung eingeben und die automatisch hinzugefügte Network-Konfiguration prüfen. Weitere geplante Bereiche über Add configuration ergänzen und deren Einstellungen öffnen; vor Save jede Konfiguration prüfen. Anschliessend nur den genehmigten Zielkreis zuweisen. Dieser Text legt keine universelle Priorität konkurrierender Policies fest. Registrierung und App-Verteilung bleiben getrennte Aufgaben.
3. Vor einem Webfilter-Pilot prüfen, ob IXM ausserhalb des nicht unterstützten Arbeitsprofil-Falls läuft, die Accessibility-Berechtigung tatsächlich bereitsteht und die Dienst-URL über die vorgesehenen Netze erreichbar ist. Geeignete Testseiten, geschäftskritische Browser/App-Abhängigkeiten, genehmigte Ausnahmen und eine erreichbare alternative Kommunikation vorbereiten. Wenn die Voraussetzungen nicht bestätigt sind: nicht zuweisen.

Antivirus: App-Scans und Ausnahmen

Die Android-Konfiguration Antivirus verwaltet den Malware-Schutz. Wird sie zugewiesen, kann die Person die entsprechenden IXM-Einstellungen nicht mehr selbst ändern. Die Felder einzeln beurteilen; ein eingeschalteter Scan ist keine Zusage, dass jedes Objekt erkannt oder ein Fund automatisch entfernt wird.

• Update mode bestimmt, wann IXM aktuelle Malware-Informationen lädt. Die gewählte Datenverbindung muss auf den vorgesehenen Geräten verfügbar sein; einen Aktualisierungsschalter nicht mit einem abgeschlossenen Update verwechseln.
• Scheduled scan interval bestimmt die Häufigkeit. Daily while charging führt erst nach mehr als 30 Minuten an einer Stromquelle zum Scan; es ist keine Zusage für einen täglich abgeschlossenen Scan.
• Installierte Apps werden standardmässig geprüft. Scan system apps nimmt die normalerweise ausgelassenen, von Android geschützten und durch Benutzer nicht deinstallierbaren System-Apps hinzu.
• Scan storage erfasst zusätzlich Dateien im internen gemeinsam genutzten Speicher, auf SD-Karten und angeschlossenen USB-Medien. Monitor storage überwacht Änderungen dort und prüft neu gespeicherte Dateien. Das erhöht mögliche Scanlast und berührt möglicherweise private Dateien: Gerätebesitz, Freigaben, Speichervolumen und Datenschutz vorab klären.
• Detect PUAs prüft potenziell unerwünschte Anwendungen: Sie sind nicht zwingend bösartig, können aber im Geschäftsumfeld Datenschutz-, Sicherheits- oder Nutzungsrisiken verursachen. Enable user to allow PUAs erlaubt Benutzerfreigaben; eine so erlaubte App wird bei späteren Scans ignoriert. Erkennung und Erlaubnis deshalb nicht als denselben Schalter behandeln.
• Unter Apps with low reputation > Mode deaktiviert Allow gerade diese Prüfung. Warn zeigt eine Warnung; Benutzer können die App erlauben und weitere Warnungen für sie unterdrücken. Block verhindert das Öffnen entsprechender Apps. Die Entscheidung muss zur genehmigten Ausnahmeregel passen, nicht nur zur Anzahl störender Meldungen.
• Scan notification steuert Meldungen nach einem App-Scan bei Installation. Ist das Häkchen entfernt, entstehen keine Meldungen für saubere Apps; das bedeutet nicht, dass sämtliche Fundmeldungen abgeschaltet oder die Apps ungeprüft sind.
• Die gewählte App group schliesst Apps vom Scan aus und ist damit eine Sicherheitsausnahme: klein und genehmigt halten, nicht pauschal eine ganze Business-App-Gruppe ausnehmen. Vor Änderung Mitglieder und fachlichen Grund dokumentieren; nach Rücknahme am gleichen Gerät erneut scannen und Ergebnisse prüfen.

Lokale Einstellungen, Scan und Datenschutz unterscheiden

In der App enthält Settings lokale Scan-, Benachrichtigungs- und Aktualisierungsoptionen. Lokale Änderungen nur nach Freigabe und soweit der Verwaltungszustand sie zulässt vornehmen; gesperrte Einstellungen über die zuständige Administration ändern lassen. Manage allowed apps zeigt erlaubte Apps, die nicht in den Scanergebnissen erscheinen; nach Entfernen aus dieser Liste können sie wieder unter Threats and PUAs erscheinen.

System-App-Freigabe ist kein verwalteter Bypass: Die Android-Client-Release-Notes zu 9.8.4125 beschreiben eine neue Möglichkeit, als Bedrohung erkannte System-Apps zu erlauben, um wiederholte Warnungen bei nicht entfernbaren Apps zu reduzieren. Diese Erweiterung gilt nur, wenn Sophos Mobile IXM nicht verwaltet, und nicht für Nicht-System-Apps. Sie begründet deshalb keine lokale Freigabe eines solchen Funds auf der hier behandelten verwalteten IXM-App. Eine unterdrückte Warnung beseitigt zudem nicht die erkannte Bedrohung.

Für den lokalen Scanumfang Scan system apps auswählen, wenn auch Android-System-Apps geprüft werden sollen. Die oben erläuterte standardmässige Auslassung dieser geschützten, durch Benutzer nicht deinstallierbaren Apps gilt auch hier. Detect PUAs schaltet lokal die Erkennung potenziell unerwünschter Apps ein, nicht deren Freigabe. App reputation aktiviert die Erkennung von Apps mit niedriger Reputation auf Basis von Sophos Live Protection-Daten. Dieser lokale Schalter ist nicht mit der zentralen Reaktion Allow/Warn/Block gleichzusetzen.

Scan storage auswählen, um SD-Karten und USB-Speicher in den lokalen Scan einzubeziehen. Monitor storage aktivieren, um neue Apps und Dateien zu prüfen, die auf diese Medien heruntergeladen oder kopiert werden. Dabei startet auch für neu angeschlossene Speichermedien automatisch ein Scan. Dieser dokumentierte lokale SD-/USB-Umfang erweitert sich nicht allein durch gleichnamige Felder auf den oben beschriebenen zentralen Umfang mit internem gemeinsam genutztem Speicher. Die Freigaben für Scanlast und mögliche private Dateien gelten weiterhin.

Der lokale Schalter Scan notification aktiviert Scanmeldungen für saubere Apps. Ohne Auswahl bleiben Meldungen für Malware, PUAs und Apps mit niedriger Reputation bestehen; die Scanprüfung wird dadurch nicht ausgeschaltet. IXM prüft Apps bei der Installation auf dem Android-Gerät sowie beim Start von SD-Karten oder USB-Speichern. Die Meldungen lassen sich im Notification Panel ansehen. Fehlende Meldungen für saubere Apps deshalb nicht als ausgebliebenen Scan werten.

Davon getrennt ist der Android-Benachrichtigungskanal Protection status. Der historische Release-Eintrag 9.7.3542 beschreibt die Statusmeldung Sophos Intercept X is protecting you und hält fest: Das Wegwischen der Meldung oder Abschalten dieses Kanals beeinträchtigt den Schutz nicht. Das ist keine Aufforderung, alle IXM-Benachrichtigungen abzuschalten. Scan notification, Fundmeldungen, Create events für Web Filtering und Meldungen an die Verwaltung sind andere Wege; ebenso sind User Activity Verification und das Fusion Notification Center davon zu unterscheiden. Weder das Vorhandensein noch das Fehlen der Statusmeldung belegt einen erfolgreichen Scan oder eine angewandte Richtlinie.

Unter Settings > Update mode die Datenverbindung für das Herunterladen der Viruserkennungsdaten festlegen, soweit lokal freigegeben. Zur Aktualitätskontrolle die Angaben Version für Antivirus-Engine und Antivirus-Daten sowie Last update prüfen. Last update nennt das Datum, an dem Antivirus-Daten von Sophos abgerufen wurden; Antippen prüft auf Updates. Das Datum ist weder der Zeitpunkt einer blossen Updateprüfung noch ein Beleg für einen gerade abgeschlossenen Scan.

Track data to help improve usability erlaubt anonyme Nutzungsdaten; Send log to Sophos teilt Trace-/Logdateien zunächst mit einer anderen App, um sie an Sophos Support zu senden. Beides sind getrennte Datenschutzentscheidungen, keine Scanvoraussetzung und keine Zusage “keine Telemetrie”. Vor einer Logweitergabe Inhalt, Empfänger, sicheren Übertragungsweg und Löschung nach Zweckende freigeben; nur notwendige Diagnosedaten weitergeben.

Ein lokaler manueller Scan wird über App security > Show scan details > Start gestartet. Die Übersicht App security issues und Show scan details zeigen Funde; unter Threats and PUAs > [App] > Object details lassen sich Installationsherkunft, angeforderte Berechtigungen und Bedrohungsbeschreibung prüfen. Von Object details aus kann man auch eine Webseite mit detaillierten Bedrohungsinformationen im Browser öffnen. Diese lokale Browseraktion ist vom später beschriebenen Fusion-Lookup getrennt. In Object details angebotene Allow-/Deinstallationsaktionen nicht reflexartig ausführen: Freigabe, Verwaltungszustand und Folgen für Geschäftsdaten zuerst klären.

Geplante lokale Scans werden, soweit nicht durch die Richtlinie gesperrt, in Settings durch Aktivieren von Scheduled scans und die Auswahl unter Scheduled scan interval eingestellt. Auch bei der lokalen Auswahl Daily while charging erfolgt ein Scan erst nach mehr als 30 Minuten an einer Stromquelle; ein täglich abgeschlossener Scan ist damit nicht zugesichert. IXM nutzt Online-Abfragen und eine lokale Scan-Engine; daraus folgt keine garantierte Erkennung aller Bedrohungen oder identische Wirkung ohne Netzverbindung.

Datierten Datenverbrauch einordnen: Die Sophos Sizing Considerations vom 14. April 2022 nennen für Intercept X for Mobile auf Android bei jedem Malware-Scan 256 Bytes pro App für Online-Abfragen der aktuellen Bedrohungsdaten in der SophosLabs-Datenbank. Für das Herunterladen der Datenupdates der Antivirus-Engine nennt die Quelle davon getrennt durchschnittlich 10-20 KB pro Tag. Diese datierten dokumentarischen Schätzwerte sind weder ein gemessener Verbrauch des eigenen Geräts noch Obergrenzen oder ein Budget für den gesamten Scan- oder Geräteverkehr; der Tagesdurchschnitt betrifft nur die genannten Datenupdates. Sie nicht auf iOS oder einen Offline-Scan übertragen. Vor einer Datenplanung den tatsächlichen Verbrauch für die vorgesehenen App-Bestände, Scanintervalle und Updatebedingungen in einem genehmigten Pilot prüfen; Schutz- oder Aktualisierungsfunktionen nicht allein zur Einhaltung dieser Schätzwerte abschalten.

Eine bereits legitim bezogene APK kann vor einer Installation im Dateimanager ausgewählt und über dessen Teilen-Funktion mit Scan with Intercept X geprüft werden. IXM prüft die ausgewählte APK auf Bedrohungen und zeigt das Ergebnis an. Dieses angezeigte Ergebnis für die ausgewählte Datei prüfen. Keine APK-Installation aus unbekannten Quellen als Testvoraussetzung verwenden: Installationen ausserhalb Google Play erhöhen das Risiko; auch ein unauffälliger APK-Scan beweist keine vertrauenswürdige Herkunft und erteilt keine Installationsfreigabe.

Zentralen Scan auslösen und den letzten Befund prüfen

In Sophos Fusion gilt für My Environment > Mobile Devices > [Testgerät] > Actions > Scan for malware eine Sophos-Mobile- oder Sophos-Mobile-Threat-Defense-Lizenz und eine von Sophos Mobile verwaltete IXM-App auf Android: Der Klick sendet eine Scan-Aufgabe, nicht sofort einen bestätigten Befund. Über Open in Sophos Mobile > Tasks den Aufgabenstatus prüfen. Fehlende Aktion zuerst auf Installation/Verwaltung prüfen, nicht blind wiederholt scannen.

Im Fusion-Gerätedetail unter Scan results mit Refresh aktualisieren. Die Liste zeigt den letzten Scan, keine vollständige Historie. Type unterscheidet Threat, Suspicious, PUA und Low reputation; Name, Identifier und Version identifizieren die App, Threat nennt gegebenenfalls die Bedrohung und Detected at deren Erkennungsdatum. Im Suchfeld nach Bedrohungs- oder App-Name, Version oder Identifier filtern; die Typfilter oberhalb der Liste grenzen den Fundtyp ein. Für zusätzliche Bedrohungsinformationen den Threat-Namen und anschliessend den gleichnamigen Treffer öffnen. Dadurch öffnet sich die Seite zur Bedrohung im Sophos Threat Center. Dort die Links für weiterführende Informationen nutzen. App-Kennungen und Funddetails nur berechtigten Personen zugänglich machen. Alte oder leere Ergebnisse belegen keinen neuen erfolgreichen Scan: Aufgabenstatus, Aktualität der Ergebnisse und App-Anzeige am selben Gerät zusammen prüfen, ohne automatische Bereinigung zu unterstellen.

Network: WLAN-Sicherheit statt WLAN-Konfiguration

Network > Man-in-the-middle protection verwaltet die IXM-Funktion Wi-Fi Security, insbesondere die Prüfung auf Man-in-the-Middle-Angriffe. Bei einem erkannten Angriff entsteht ein Ereignis in den Gerätedetails und ein Alert. Zugewiesene Network-Einstellungen lassen sich in der App durch Benutzer nicht mehr ändern; Extra settings nur auf Anweisung des Sophos Support setzen. Dies ist keine WLAN-SSID-, Zertifikats- oder VPN-Konfiguration.

Die Android-App fordert beim Einschalten von Wi-Fi Security wegen Androids Standort-Berechtigungsmodell präzisen Standort und Hintergrundstandort an: Ein WLAN-Name kann Rückschlüsse auf den Standort zulassen. Die Anforderung der Berechtigung bedeutet hier nicht, dass IXM den Standort abruft oder verfolgt; diese begrenzte Aussage ist keine Zusage, dass keine Netzwerk- oder Diagnosedaten verarbeitet werden. Die sensible Freigabe mit Datenschutz und Geräteinhaber vor dem Pilot abstimmen. Ohne bestätigte Berechtigungen keinen erfolgreichen WLAN-Schutz annehmen; verwaltete Einstellungen nicht durch private Benutzeränderungen umgehen.

In der App unter Network security > Wi-Fi Security prüft Check Wi-Fi das aktuell verbundene Netz. Background check prüft beim Verbinden mit WLAN, soweit der Verwaltungszustand die Einstellung zulässt. Die Prüfung umfasst Inhaltsmanipulation (veränderte Website-Inhalte, die zu schädlichen Handlungen verleiten), SSL-Interception (Abfangen über ein falsches Zertifikat, wobei sensible Daten trotz scheinbar sicherer, verschlüsselter Verbindung offengelegt werden können) und SSL-Stripping (Herabstufen von HTTPS auf HTTP). ARP-Spoofing (falsche Zuordnung des Gateways zur Angreifer-MAC) kann Wi-Fi Security auf Geräten mit Android 10 oder neuer wegen einer Android-Einschränkung nicht erkennen (Sophos Known Issue SMSECAND-4570). Auch legitime Captive Portals, etwa die Anmeldeseite eines öffentlichen WLANs, können zusätzliche Warnungen erzeugen, weil sie den gesamten Verkehr auf das Portal umleiten. Das ist keine Freigabe, Warnungen zu ignorieren oder Schutzfunktionen zu umgehen. Ein ausbleibender Alarm ist kein Beweis, dass jedes Netz sicher ist; App-Prüfergebnis, Berechtigungen und gegebenenfalls zentrales Ereignis getrennt beobachten, ohne einen echten Angriff zu inszenieren.

Android Web Filtering: Effekt, Listen und Berechtigungen

Die MTD-Konfiguration steuert über Filter malicious websites den Umgang mit schädlichen Websites und über Filter websites by category den Umgang mit Inhaltskategorien. Die Kategorien werden laufend aktualisiert; eine Einstufung ist kein unveränderlicher Stammdatensatz. Create events legt fest, ob nur blockierte Aufrufe oder auch Warnungen Ereignisse in den Gerätedetails erzeugen. Für einen freigegebenen Pilot den gewählten Ereignisumfang festhalten und dort die erwarteten Testereignisse prüfen; eine fehlende Warnungszeile bei block-only-Einstellung ist allein kein Schutzfehler.

Die Klassifizierung benötigt https://4.sophosxl.net/lookup; bei Nichterreichbarkeit blockiert Web Filtering alle Websites. Bei aktiviertem Filter werden besonders schwerwiegende kriminelle Inhalte immer gesperrt und deren URLs in Logs, Ereignissen und Berichten maskiert – nicht alle URLs. Solche Inhalte nicht für einen Test aufrufen. Bei Web Filtering die Compliance-Regel Intercept X for Mobile permissions can be denied auf No planen, damit ein durch abgeschalteten Accessibility Service ausgefallener Filter als nicht konform erkannt wird. Das ist keine automatische Wiederherstellung; Aktionen und mögliche Zugangs-/App-Folgen einer Compliance-Richtlinie separat prüfen und keine gefährliche Reaktion oder Statusänderung ohne Freigabe konfigurieren.

Ausnahmen eng halten und Reihenfolge prüfen

Ausnahmen sind keine harmlose Schnellreparatur: Eine Richtlinien-Allowlist hat Vorrang vor der Richtlinien-Blocklist; beide haben Vorrang vor der Benutzer-Allowlist. Danach folgt der Kategorie-Block. Für die Threat-Defense-Ausgabe ist zwischen Benutzer-Allowlist und Kategorie-Block zusätzlich eine Benutzer-Blocklist beschrieben; für die Vollausgabe ist dieser Zwischenschritt nicht geklärt. Deshalb vor einer Ausnahme die tatsächliche editions-/versionsabhängige Reihenfolge am Pilot prüfen, statt eine identische Reihenfolge vorauszusetzen. Eine lokale Benutzerfreigabe setzt eine Richtlinien-Blocklist nicht ausser Kraft; die erzwungene Sperre schwerwiegender krimineller Inhalte bleibt zu beachten.

Allowed domains erlaubt Seiten trotz gesperrter Kategorie, Blocked domains sperrt Seiten trotz erlaubter Kategorie. Beide Felder erlauben je einen Domainnamen, eine Wildcard-Domain, IPv4-/IPv6-Adresse oder ein Subnetz pro Zeile, ohne Trennzeichen und ohne Protokollpräfix wie https:// oder chrome://. Auch browserinterne Kennungen sind gültige Ausnahme-Einträge: bookmarks statt chrome://bookmarks ist ein Syntaxbeispiel, keine Empfehlung, Lesezeichen zu sperren. Ein Wildcard-* muss am Anfang stehen. Ein einzelnes * in Blocked domains sperrt alle Websites im Filterbereich.

Als Syntaxbeispiele sind www.example.com, *.example.com, 203.0.113.0/24 und 2001:db8::/32 gültige Formen, keine zum Kopieren vorgesehene Geschäftsausnahme. Für einen genehmigten Test zuerst einen konkreten, tatsächlich benötigten Domainnamen wählen und durch den eigenen geprüften Eintrag ersetzen. Eine Wildcard oder ein Subnetz umfasst einen breiteren Bereich als ein einzelner Name beziehungsweise eine einzelne Adresse; Reichweite und benötigte App-Abhängigkeiten deshalb vorab prüfen und breite Einträge nicht als Schnelllösung einsetzen.

Laut Sophos gilt Web Filtering auf unterstützten Geräten für den gesamten Webverkehr, einschliesslich des Webverkehrs von Drittanbieter- und System-Apps sowie externer Ressourcen, die Websites nachladen, etwa Schriften. Breite Wildcards können Geschäfts-Apps oder Websites unbrauchbar machen. Nur einen einzeln genehmigten, überprüfbaren Ausnahme-Eintrag mit protokollierter ursprünglicher Liste im isolierten Pilot ausprobieren; nach einem Test die Ausnahme gezielt entfernen und Block-/Allow-Wirkung erneut kontrollieren. Keine globale Allowlist als vermeintliche Lösung für einen ausgefallenen Klassifizierungsdienst.

Browser und lokale Bedienung kontrollieren

Unterstützte Browser sind Android web browser, Firefox, Google Chrome und Microsoft Edge; andere können funktionieren, sind aber nicht getestet. In der App ist Web Filtering unter Network security > Web Filtering sichtbar. Wenn die oben genannten Browser-, Accessibility-, Gerätemodus- und Erreichbarkeitsprüfungen erfüllt sind, die Änderung freigegeben ist und der Verwaltungszustand lokale Änderungen zulässt, auf dieser Seite Web Filtering einschalten. Anschliessend Malicious content antippen und Warn oder Block auswählen. Für jede gewünschte Inhaltskategorie die Kategorie antippen und ebenfalls Warn oder Block auswählen. Zentral gesteuerte Einstellungen stattdessen über den genehmigten Richtlinienablauf ändern lassen, nicht lokal umgehen.

Always allow access to this page im Warnungsdialog fügt eine lokale Ausnahme hinzu; Clear allowed pages list entfernt die lokalen Ausnahmen wieder. Das ist weder ein pauschaler Bypass zentraler Regeln noch der Rückbau einer MTD-Richtlinie. Eine breit wirkende Löschung lokaler Freigaben ebenfalls vorher abstimmen.

Unter Protected browsers den vorgesehenen Browser prüfen; Protected browsers (not tested) ist keine Abnahme für weitere Browser. Ist ein unterstützter Browser installiert, aber nicht unter Protected browsers aufgeführt, in den Android-Systemeinstellungen unter Accessibility kontrollieren, ob Sophos Accessibility Service eingeschaltet ist. Die Bedienoberfläche ist nicht der Nachweis einer tatsächlich angewandten Tenant-Richtlinie und ersetzt keine Kontrolle der Policy- und App-Wirkung. Die Arbeitsprofil-Grenze bleibt unabhängig von sichtbaren Schaltern bestehen.

Link Checker und Device security nicht als Richtlinienbausteine ausgeben

Link Checker ist eine eigene App-Funktion, mit der sich Links aus Nicht-Browser-Apps auf schädliche oder unangemessene Inhalte prüfen lassen. Intern in einer App geöffnete Links kann er nicht prüfen; Links müssen an den Browser übergeben werden. Das ist kein zusätzlicher Konfigurationsbaustein der drei hier behandelten MTD-Bereiche Antivirus, Network und Web Filtering und wird durch deren Zuweisung nicht automatisch eingeschaltet.

Achtung – der Standardbrowser ändert sich: Nur wenn diese getrennte App-Funktion gewünscht und freigegeben ist, den bisherigen Android-Standardbrowser dokumentieren. Dann unter Network security > Link Checker den Schalter neben Link Checker is turned off betätigen, den Hinweis mit OK bestätigen, Intercept X wählen und Set as default ausführen. Bei mehreren Browsern unter Checked links open in this browser den gewünschten Zielbrowser auswählen. Einen harmlosen extern übergebenen Link testen; bei Apps mit internem Browser die vorhandene Einstellung zum Öffnen im Browser separat beurteilen. Für Gmail ist dies die Option Open web links in Gmail: Nur nach Freigabe ausschalten, wenn Links an den Browser gehen sollen. Eine Änderung betrifft die Link-Bedienung dieser App und ist keine garantierte Abdeckung aller Links.

Wird in Android wieder ein anderer Standardbrowser gewählt, schaltet das Link Checker aus. Settings > Clear defaults beendet die Verwendung von IXM als Standard-App für unterstützte Links. Zum Rückweg den zuvor dokumentierten Standardbrowser und gegebenenfalls die geänderte In-App-Linkoption wiederherstellen und dieselbe harmlose Linkübergabe erneut prüfen; dadurch wird die zentrale Webfilterrichtlinie nicht entfernt.

Device security bewertet Android-Sicherheitseinstellungen und zeigt Empfehlungen. Grün mit Secure steht für die maximal mögliche Sicherheit bei der betreffenden Einstellung, nicht für vollständige Gerätesicherheit oder eine angewandte MTD-Richtlinie. Rot mit Insecure weist auf mögliche Sicherheitsprobleme hin. Die Empfehlung zu dieser Einstellung prüfen und eine freigegebene Änderung entsprechend umsetzen lassen.

Gelb mit Unknown bedeutet, dass IXM wegen Gerätemodell oder Android-Version nicht eindeutig feststellen kann, ob die Einstellung unsicher ist. Eine Änderung dieser Einstellung nach Prüfung und mit der zuständigen Administration erwägen, nicht allein wegen der Farbe erzwingen. Grau mit Turned off bedeutet, dass die Prüfung abgeschaltet ist und diese Einstellung nicht in den Gerätesicherheitsstatus eingeht. Daraus folgt nicht, dass die zugrunde liegende Android-Schutzfunktion ausgeschaltet ist. Gelb und Grau nicht als sicher interpretieren.

Unter Device security eine Einstellung antippen, um ihre Sicherheitsauswirkung näher zu lesen oder den angebotenen Änderungsweg zu öffnen. Nicht jedes Antippen führt zu einer Änderung oder erteilt eine Änderungsbefugnis. Bei durch Sophos Mobile verwalteter App werden sicherheitsrelevante Systemeinstellungen durch die Organisation konfiguriert. Benutzer deshalb nicht zum Übersteuern verwalteter Einstellungen auffordern; eine Empfehlung ist kein zusätzlicher Android-MTD-Policy-Baustein.

Release-Hinweise zur Gerätebewertung einordnen

Die folgenden Android-Client-Änderungen sind in den früheren Releases dokumentiert; ihre Nennung bestätigt weder die installierte Version noch eine am Gerät geprüfte Wirkung.

• Secure NFC: Für 9.8.4125 berücksichtigt Security Advisor die Android-Einstellung Require device unlock for NFC (Secure NFC). Eingeschaltetes NFC wird nicht mehr automatisch als unsicher bewertet, wenn Secure NFC unterstützt und eingeschaltet ist. Wird Secure NFC unterstützt, ist aber ausgeschaltet, erscheint eine Warnung mit der Empfehlung, es einzuschalten. Die Unterstützung und den tatsächlichen Zustand am vorgesehenen Gerät prüfen; die Aussage für unterstütztes Secure NFC nicht auf Geräte ohne diese Funktion übertragen oder NFC pauschal abschalten.
• Bedienungshilfen: 9.7.3829 führte eine Device-Security-Warnung bei eingeschaltetem Accessibility Service ein; 9.7.4013 ergänzte die Auswahl einzelner Dienste, die von diesen Warnungen ausgenommen werden können. Eine solche Warnungsausnahme ist weder das Abschalten des Diensts noch eine Android-MDM-Zulassung. Für Web Filtering bleibt der oben erläuterte Sophos Accessibility Service erforderlich. Allowed accessibility services in der Android-Enterprise-Geräterichtlinie regelt dagegen, welche Apps Bedienungshilfen bereitstellen dürfen; diesen separaten MDM-Bereich nach Android-Firmenrichtlinie prüfen. Aus dem Release-Hinweis keine verfügbare lokale Ausnahmeaktion für jede verwaltete App ableiten und den benötigten Sophos-Dienst nicht zur Beseitigung einer Warnung deaktivieren.
• Geräteintegrität: 9.7.3672 ersetzte für die Prüfung der Geräteintegrität Googles SafetyNet API durch die Play Integrity API. Das ist eine historische Änderung des Prüfverfahrens, kein zusätzlicher MTD-Richtlinienbaustein und keine Gleichsetzung mit einer bestimmten Compliance-Regel. Sie belegt weder eine erfolgreiche Integritätsprüfung auf dem konkreten Gerät noch eine Enrollment- oder Zugangsfreigabe; Compliance-Richtlinie und tatsächlichen Gerätebefund getrennt beurteilen.

Begrenzte Abnahme und Rückfall

1. Vorher: genehmigte kleine Pilotgruppe und ein erreichbares Testgerät je tatsächlich vorgesehenem Android-Modus; Policy-Version, IXM-Registrierung, Scan-/Berechtigungsstatus, letzte Ergebnisse, zulässige und gesperrte Testseiten, geschäftliche Browser/App-Abhängigkeiten sowie unabhängigen Rückkanal dokumentieren. Für Arbeitsprofilgeräte keinen Webfilter-Erfolg als Ziel definieren; Web Filtering dort nicht als wirksamen Schutz ausrollen.
2. Nach Zuweisung: auf nächste Verbindung/Synchronisierung warten, im Gerät die Richtlinie und App-Konfiguration kontrollieren und Funktion separat beobachten. Für Web Filtering nur freigegebene, harmlose Web-Security-&-Control-Testseiten öffnen; die Beispiele sind trotz ihrer Testklassifizierung inhaltlich harmlos. Erlaubte und gesperrte Web-Ziele, Accessibility-Status sowie WLAN-Prüfung auf einem bekannten Netz vergleichen. Antivirus-Scanstatus und letzte Ergebnisse getrennt prüfen; keinen echten Schädling als Test einsetzen. Unter Create events nur erwartete Webfilter-Testereignisse prüfen; Scan-Aufgabenstatus nicht mit Scanergebnis gleichsetzen. Eine erfolgreiche Zuweisung ist kein Wirksamkeitsbeleg. Auch ein vom Admin-Rechner erreichbarer Klassifizierungsdienst beweist nicht dessen Erreichbarkeit durch IXM im vorgesehenen Gerätenetz; den Gerätefall im genehmigten Pilot prüfen und keinen Produktionsausfall absichtlich herbeiführen.
3. Bei Fehlblockade oder ausbleibendem Schutz: Ausweitung stoppen, betroffene Geräte/Abhängigkeiten sichern und die Ursache eingrenzen: Dienst erreichbar? Accessibility noch freigegeben? Betrifft der Fehler eine Ausnahme, die Scan-Ausschlussgruppe oder die gesamte Richtlinie? Eine neue Ausnahme aus dem Pilot entfernen beziehungsweise die bisherige Liste wiederherstellen; bei Gruppenänderungen den ursprünglichen engen Zielkreis zurücksetzen. Wenn nötig nur einen für die vorliegende Störung geprüften Policy-Stand gezielt wiederherstellen oder eine zuvor geprüfte Alternative zuweisen. Bei Ausfall des Klassifizierungsdiensts darf die Rückfallrichtlinie nicht ebenfalls Web Filtering mit derselben unerreichbaren Dienstabhängigkeit aktivieren; ohne erreichbaren, freigegebenen Rückweg nicht weiter ändern, sondern über den unabhängigen Rückkanal eskalieren. Eine MTD-Richtlinie nicht wie eine Android-Geräterichtlinie blind „deinstallieren“ oder die IXM-App entfernen: Geänderte MTD-Einstellungen werden bei der nächsten Verbindung synchronisiert; der Rückweg ist die gezielte Policy-Änderung oder Zuweisung einer geprüften anderen Policy, nicht die MDM-Uninstall-Aktion. Auf demselben Testgerät nach der nächsten Verbindung zu Sophos Mobile die tatsächlich angewandte Richtlinie, App-/Berechtigungsstatus, erlaubte Geschäftsziele, Schutzfunktion und Ereignisse erneut prüfen. Weder Filter-Berechtigungen abschalten noch mit * oder globaler Allowlist einen unkontrollierten Test durchführen.

Offen vor Freigabe: Konkrete Lizenz, Adminrolle, unterstützte Android-Versionen, MDM-/App-Modus, Datenschutzfreigaben für Scan und Standort, tatsächliche Accessibility- und Dienst-Erreichbarkeit, Ausnahmewirkung, Gruppen-Zielkreis und Rückweg im Kundentenant sind nicht getestet. Der MTD-Richtlinien-Owner ersetzt weder die separate Zuweisungs-/Registrierungsanleitung noch iOS-Webfilter- oder Android-Enterprise-MDM-Policy. Vor einer produktiven Zuweisung müssen Lizenz, Richtlinienwirkung und Rückweg am freigegebenen Testgerät geprüft werden; ohne diesen Nachweis nicht ausrollen.