Sophos Firewall Data Anonymization einrichten

Data anonymization verschlüsselt identifizierende Angaben in Logs und Reports der Sophos Firewall. Dazu gehören insbesondere Benutzernamen, IP-Adressen, MAC-Adressen und E-Mail-Adressen. Ein autorisierter Administrator kann diese Angaben bei einer berechtigten Analyse wieder einblenden.

Der sichere Ablauf ist kurz:

1. Zweck, betroffene Ausgaben und Freigabeprozess dokumentieren.
2. Zwei persönliche Administratorkonten als Authorizer vorbereiten.
3. Unter System services > Data anonymization die Funktion aktivieren und beide Authorizer auswählen.
4. Mit einem kontrollierten Testevent prüfen, ob Log Viewer und Suche weiterhin funktionieren.
5. Die Identität mit einem Authorizer gezielt einblenden und den nicht autorisierten Zugriff negativ testen.
6. Ausnahmen nur für begründete Einzelfälle anlegen.
7. CSV-Exporte und tatsächlich erzeugte PDF-Reports separat kontrollieren.

⚠️ Data Anonymization ist keine Datenlöschung und keine Garantie für jeden externen Datenpfad. Remote-Syslog, Sophos Fusion (ehemals Sophos Central), CTR, Advanced-Shell-Dateien und Backups werden separat geprüft. Ein Export wird erst weitergegeben, nachdem die konkrete Datei auf sensible Identitäten kontrolliert wurde.

Was Data Anonymization schützt

Sophos beschreibt die Funktion als Verschlüsselung von Identitäten in Logs und Reports. Genannt werden:

• Benutzernamen;
• IP-Adressen;
• MAC-Adressen;
• E-Mail-Adressen.

Das reduziert die unnötige Offenlegung bei täglicher Auswertung und Reporting. Ein NOC kann beispielsweise einen Fehler nach Zeitpunkt, Regel und Aktion untersuchen, ohne sofort jede Benutzer- oder Clientidentität zu sehen. Für einen berechtigten Security- oder Datenschutzfall bleibt eine kontrollierte Einblendung möglich.

Die Funktion ersetzt trotzdem keine Zugriffsrechte, Aufbewahrungsregeln oder geschützte Übertragung. Ein anonymisierter Report kann weiterhin Firewallnamen, URLs, Regelbezeichnungen, Zeitstempel und Sicherheitsereignisse enthalten. Auch diese Informationen können vertraulich sein.

Was nicht pauschal vorausgesetzt wird

Die aktuelle Sophos-Hilfe bestätigt die Wirkung für Logs und Reports sowie das Einblenden im Log Viewer. Sie beschreibt aber nicht jeden möglichen Ausgabeweg mit derselben Genauigkeit. Deshalb wird die On-box-Einstellung nicht automatisch auf folgende Datenpfade übertragen:

• Remote-Syslog oder SIEM;
• Sophos Central Firewall Reporting;
• Consolidated Troubleshooting Reports und einzelne Support-Logs;
• Dateien unter /log in der Advanced Shell;
• Backups und Konfigurationsexporte;
• bereits versendete E-Mails oder gespeicherte PDF- und CSV-Dateien.

Für Remote-Syslog gilt weiterhin der eigene Schutz- und Abnahmeablauf unter Sophos Firewall Syslog sicher an ein SIEM senden. Zentrale Reports werden getrennt unter Sophos Central Firewall Reporting geprüft.

Authorizer und Freigabegrenze vorbereiten

Beim Aktivieren werden ein oder mehrere Administratoren als Authorizer ausgewählt. Diese Zuordnung berechtigt zum Deanonymisieren; im Log Viewer muss ein Authorizer dafür seine Authentifizierungsdaten eingeben. Sophos empfiehlt mindestens zwei Authorizer. Ist der aktuell angemeldete Administrator selbst als Authorizer eingetragen, verlangt Sophos die Zustimmung mindestens eines weiteren Authorizers.

Für die Planung wichtig: Damit ist kein technisch erzwungenes Vier-Augen-Prinzip für jede Einblendung belegt. Die SFOS-22.0-Hilfe bestätigt im Log Viewer nur Autorisierung und erneute Authentifizierung. Verlangt die eigene Richtlinie zwei Personen für jede Analyse, muss dieser organisatorische Prozess zusätzlich durchgesetzt und bei der Abnahme getrennt von der Produktauthentifizierung geprüft werden.

Vor der Aktivierung werden deshalb zwei persönliche Konten vorbereitet, zum Beispiel:

• privacy.authorizer1
• privacy.authorizer2

Die Namen sind Muster und werden durch zwei eindeutig zugeordnete Administratorkonten ersetzt. Ein geteiltes Teamkonto wäre ungeeignet, weil Einblendung, Freigabe und spätere Prüfung nicht mehr einer Person zugeordnet werden können. Die sichere Einrichtung persönlicher Konten und begrenzter Profile erklärt Administratoren und Device-Access-Profile sicher einrichten.

Authorizer ist kein eigenes Device-Access-Profil. Profile steuern rollenbasiert den Zugriff auf WebAdmin und API mit None, Read-only oder Read-write; ein lokaler Benutzer wird unter Authentication > Users mit dem Typ Administrator und einem Profil angelegt. Sophos nennt für Data Anonymization kein minimales Profil. Deshalb wird nicht pauschal ein Profil behauptet, sondern vor dem Change geprüft, ob beide vorgesehenen Konten die benötigte Seite und den Log Viewer tatsächlich erreichen.

Zusätzlich wird vorab festgelegt:

• für welche Support-, Security- oder Datenschutzfälle eine Einblendung zulässig ist;
• wer die Analyse anfordert und genehmigt;
• wie Ticket, Zweck, Zeitraum und betroffene Identitäten dokumentiert werden;
• wann eine Ausnahme abläuft und erneut geprüft wird;
• welcher lokale Recovery-Admin verfügbar bleibt, falls ein Authorizer nicht funktioniert.

Die Aktivierung wird gestoppt, wenn nur ein funktionsfähiges Administratorkonto vorhanden ist oder der normale WebAdmin-Login des zweiten vorgesehenen Authorizers nicht erfolgreich geprüft wurde. Seine Authorizer-Funktion lässt sich erst nach der Zuordnung testen.

Data Anonymization aktivieren

1. Mit einem persönlichen Administrator am WebAdmin anmelden.
2. System services > Data anonymization öffnen.
3. Enable data anonymization auswählen.
4. Mindestens die zwei vorbereiteten Authorizer auswählen.
5. Apply auswählen.
6. Ist der angemeldete Administrator selbst als Authorizer ausgewählt, die von der Oberfläche verlangte Zustimmung mindestens eines weiteren Authorizers einholen.
7. Seite neu laden und prüfen, ob die aktivierte Einstellung weiterhin angezeigt wird.

Die Änderung wird nicht zusammen mit einer Umstellung von Adminprofilen, MFA oder Logzielen durchgeführt. Ein einzelner Change ist leichter zu prüfen und zurückzunehmen.

Kontrolliertes Testevent erzeugen

Für die Abnahme wird ein bekannter Pilotclient verwendet, beispielsweise 10.20.30.25, sowie ein eindeutig zugeordneter Testbenutzer wie privacy.test. Die private IP-Adresse ist ein Muster. Sie wird durch einen realen Pilotclient aus dem Management- oder Testnetz ersetzt, damit das erzeugte Event im eigenen Log Viewer eindeutig wiedererkannt wird.

Der Test wird mit Uhrzeit, Source, Destination, Dienst und erwarteter Firewall Rule ID dokumentiert. Danach erzeugt der Pilotclient eine kurze, erlaubte Verbindung, deren Regel Log firewall traffic aktiviert hat. So lässt sich unterscheiden, ob die Anonymisierung wirkt oder lediglich kein passendes Event vorhanden ist.

Fehlt das Event vollständig, wird zuerst der normale Logging-Pfad geprüft. Dafür hilft Sophos Firewall Service-Logs richtig zuordnen. Data Anonymization repariert kein deaktiviertes Rule Logging und keinen stehenden Log Viewer.

Log Viewer positiv und negativ testen

In SFOS 22.0 öffnet man die Ansicht über Log viewer oben rechts im WebAdmin. In SFOS 23.0 heisst dieser Einstieg Logs and policy test. Die folgende Prüfung erfolgt weiterhin im Log Viewer.

1. Log viewer öffnen und das fachlich passende Modul wählen.
2. Zeitraum und Filter auf das dokumentierte Testevent begrenzen.
3. Prüfen, ob Benutzer- und Adressfelder anonymisiert erscheinen.
4. Eine Freitextsuche mit den sichtbaren anonymisierten Informationen ausführen. Sophos bestätigt, dass die Suche auch mit anonymisierten Daten funktioniert.
5. Als eingetragener Authorizer die Schaltfläche Data anonymization verwenden und die eigenen Authentifizierungsdaten eingeben.
6. Prüfen, ob die erwartete Identität für die Analyse sichtbar wird.
7. Danach die autorisierte Ansicht schliessen und mit einem nicht als Authorizer eingetragenen Testadmin negativ prüfen, dass die Identitäten nicht offengelegt werden. Das konkrete Fehlerbild kann je nach Berechtigung variieren; Erfolg bedeutet allein, dass der Testadmin keinen Klartext erhält.

Ein erfolgreicher Authorizer-Test beweist nur diesen konkreten WebAdmin-Pfad. Er beweist noch nicht, dass PDF, CSV, Sophos Fusion, Syslog oder Supportarchive dieselbe Darstellung verwenden.

Ausnahmen nur begründet anlegen

Eine Ausnahme verhindert die Verschlüsselung der ausgewählten Identität in Logs und Reports. Sie kann für Benutzer, IP-Adressen, MAC-Adressen oder E-Mail-Adressen definiert werden. Das ist keine bequemere Suchfunktion, sondern eine bewusste Offenlegung.

Ein vertretbarer Fall kann eine technische Serviceidentität sein, die ein automatisierter Betriebsprozess zwingend im Klartext unterscheiden muss. Auch dann braucht die Ausnahme:

• einen dokumentierten Zweck;
• den kleinstmöglichen Identitätsumfang;
• einen Owner;
• ein Ablauf- oder Review-Datum;
• einen positiven Test der Ausnahme und einen negativen Test einer weiterhin anonymisierten Identität.

Der dokumentierte Bedienweg lautet:

1. Unter System services > Data anonymization die konkrete Ausnahme hinzufügen.
2. Apply auswählen.
3. Benutzername und Passwort eines Authorizers eingeben.
4. Save auswählen.
5. Ein neues Testevent erzeugen und die tatsächliche Anzeige kontrollieren.

Nach erfolgreicher Authentifizierung werden die ausgewählten Identitäten nicht verschlüsselt. Eine breite Netzrange, eine ganze Benutzergruppe ohne Einzelfallbegründung oder eine dauerhaft offene Ausnahme wird nicht als Standard verwendet.

PDF und CSV tatsächlich kontrollieren

Die WebAdmin-Anzeige ist nur ein Teil der Abnahme. Ausgaben können später ausserhalb der Firewall gespeichert, per E-Mail versendet oder in ein Ticketsystem kopiert werden.

Geplanten PDF-Report prüfen

Bei lokalen E-Mail-Reports wird nach der Aktivierung nicht bis zum nächsten regulären Termin gewartet. Der Zeitplan wird mit Generate now ausgeführt und das tatsächlich empfangene PDF kontrolliert. Der vollständige Versand- und Prüfablauf steht unter Sophos Firewall Reports planen und per E-Mail versenden.

Geprüft werden mindestens:

• Benutzer-, IP-, MAC- und E-Mail-Felder;
• beabsichtigte Ausnahmen;
• URLs, Regelbezeichnungen und weitere sensible Inhalte;
• Empfänger, Mailtransport und Aufbewahrung im Postfach.

Ein bereits früher erzeugtes PDF wird durch eine spätere Einstellungsänderung nicht zu einem neuen Prüfnachweis. Für die Abnahme wird eine frische Datei erzeugt.

Log-Viewer-CSV prüfen

Der Log Viewer kann die aktuelle Ansicht als CSV exportieren. Die aktuelle Sophos-Hilfe bestätigt den Export, beschreibt den Anonymisierungsumfang der Datei aber nicht separat. Deshalb wird ein kleiner Export des kontrollierten Testevents geöffnet und Feld für Feld geprüft.

Erst wenn sowohl anonymisierte Identitäten als auch beabsichtigte Ausnahmen korrekt erscheinen, darf dieser Exportpfad produktiv verwendet werden. Die Datei wird danach geschützt gespeichert oder gelöscht. Ein Dateiname ohne Identität verhindert nicht, dass der Inhalt sensible Daten enthält.

HA, Backups und externe Datenpfade abgrenzen

Die SFOS-22.0-Seite zu Data Anonymization macht keine funktionsspezifische Aussage zur HA-Synchronisierung oder zum Inhalt eines Backups. Beides wird daher nicht als garantiert dargestellt. In einem vorhandenen HA-Cluster ist ein neues Testevent nach einem geplanten Failover eine sinnvolle betriebliche Abnahme, aber keine von Sophos dokumentierte Voraussetzung dieser Funktion.

Sophos bestätigt allgemein, dass ein Backup die gesamte Firewall-Konfiguration enthält und verschlüsselt ist. Beim Restore ersetzt es die aktuelle Konfiguration, löscht das auf der Firewall gespeicherte Backup und startet die Firewall neu; neuere Änderungen gehen beim Restore eines älteren Stands verloren. Daraus lässt sich ohne weiteren Nachweis nicht ableiten, wie historische anonymisierte Identitäten behandelt werden. Nach einem Restore werden deshalb Einstellung, Authorizer, Ausnahmen und ein neues Logevent erneut geprüft.

Für HA-Restores gilt zusätzlich: Das Backup wird auf dem aktuellen Primary wiederhergestellt und anschliessend zum Auxiliary synchronisiert; der Neustart erfolgt ohne Failover und verursacht Downtime. Ein Backup ohne HA-Konfiguration deaktiviert HA. Ein Backup-Restore ist daher kein leichtgewichtiger Rückweg nur für Data Anonymization.

Remote-Syslog, Sophos Central Firewall Reporting, CTR und Advanced-Shell-Logs werden als eigene Datenpfade behandelt:

1. Ziel und Verantwortlichkeit festlegen.
2. Einen kontrollierten Testevent erzeugen.
3. Die tatsächlich empfangene oder heruntergeladene Ausgabe prüfen.
4. Zugriff, Aufbewahrung und sichere Löschung dokumentieren.

Falls ein externer Datenpfad weiterhin Klartext enthält, wird das nicht durch eine breite Ausnahme oder das Abschalten des lokalen Loggings kaschiert. Stattdessen werden Zugriff und Übertragung des betroffenen Systems gehärtet oder der Export gestoppt, bis der Datenschutzbedarf geklärt ist.

Fehler systematisch eingrenzen

Identitäten erscheinen weiterhin im Klartext

Zuerst wird geprüft, ob Enable data anonymization weiterhin aktiv ist und das sichtbare Event nach der letzten Änderung neu erzeugt wurde. Danach werden Ausnahmen auf Benutzer, IP, MAC oder E-Mail kontrolliert. Ein Event kann mehrere Identitäten enthalten; eine Ausnahme für die Source-IP erklärt nicht automatisch einen sichtbaren Benutzernamen.

Anschliessend Log Viewer zurücksetzen, neues Testevent erzeugen und die Ansicht erneut prüfen. Alte PDFs, Browserdownloads oder Screenshots sind kein verlässlicher Nachweis für die aktuelle Einstellung.

Ein Authorizer kann die Identität nicht einblenden

Prüfen, ob das persönliche Konto tatsächlich als Authorizer ausgewählt ist, sein Device-Access-Profil den benötigten Zugriff erlaubt und die eigenen aktuellen Authentifizierungsdaten verwendet werden. Ist der angemeldete Administrator selbst Authorizer, wird die von Sophos genannte Zustimmung eines weiteren Authorizers berücksichtigt; eine zusätzliche Zweitfreigabe für jeden Log-Viewer-Aufruf wird ohne sichtbare Aufforderung nicht vorausgesetzt.

Adminprofile, MFA und Login-Quelle werden nicht gleichzeitig verändert. Bleibt die Einblendung trotz korrekter Auswahl und positivem normalen Login erfolglos, werden Zeitpunkt, Browser, Konto und sichtbare Meldung dokumentiert. Authorizer werden nicht entfernt, bevor ein zweiter geprüfter Zugriff und ein Recovery-Weg bestehen.

PDF oder CSV zeigt ein anderes Ergebnis als der Log Viewer

Dann werden die Wege getrennt bewertet. Für PDF werden Reporttyp, Erzeugungszeitpunkt und Generate now dokumentiert. Für CSV werden Modul, Filter und Exportzeitpunkt festgehalten. Bei Sophos Fusion, Syslog oder Supportarchiven wird keine lokale Anonymisierung versprochen, sondern die konkrete Zieldatei beziehungsweise Plattform geprüft.

Keine Reporting- oder Logging-Dienste neu starten und keine Reportdaten löschen, nur weil eine Ausgabe anders dargestellt wird. Zuerst wird ein reproduzierbarer Test mit einer neuen Datei erstellt.

Sicher zurückbauen

Vor dem Pilot werden unter System services > Data anonymization drei Zustände festgehalten: Enable data anonymization, die Authorizer-Liste und jede Ausnahme. Falls der Change den vereinbarten Betrieb nicht erfüllt, werden genau diese Werte in einem autorisierten Change auf den dokumentierten Stand zurückgesetzt und mit Apply übernommen. Ein Backup-Restore ist dafür wegen Konfigurationsersatz, Neustart und möglichem HA-Unterbruch unverhältnismässig.

Die Sophos-Hilfe dokumentiert keine separate Reset-Funktion und sagt nicht, ob ein Abschalten bereits gespeicherte Identitäten rückwirkend anders darstellt. Der Rückweg wird deshalb mit einem neuen Logevent, der Authorizer-Sicht, einem CSV-Export und bei Bedarf einem frisch erzeugten PDF geprüft; über historische Einträge wird ohne Sichtprüfung keine Aussage getroffen.

Ausnahmen werden auf ihren früheren Scope zurückgesetzt. Bereits exportierte Dateien bleiben separat bestehen und müssen nach der geltenden Aufbewahrungs- und Löschregel behandelt werden. Ein Rückbau der Firewall-Einstellung entfernt keine Kopien aus Postfächern, SIEM, Tickets oder Supportfällen.

Checkliste für den Betrieb

• Zweck, Owner und Freigabeprozess dokumentiert
• zwei persönliche Authorizer positiv getestet
• lokaler Recovery-Admin verfügbar
• Enable data anonymization aktiv und nach Reload bestätigt
• kontrolliertes Logevent anonymisiert sichtbar
• Authorizer-Einblendung positiv und nicht autorisierter Zugriff negativ getestet
• Ausnahmen klein, begründet und mit Review-Datum versehen
• frisches PDF und Log-Viewer-CSV kontrolliert
• Syslog, Sophos Fusion, CTR und Shell-Logs separat bewertet
• HA-Verhalten bei vorhandenem Cluster mit neuem Event geprüft
• vor einem Restore Authorizer und Ausnahmen dokumentiert; Restore nicht als Standard-Rollback verwendet
• bereits exportierte Dateien geschützt und nach Retention behandelt

Häufige Fragen

Löscht Data Anonymization personenbezogene Daten?

Nein. Sophos beschreibt die Funktion als Verschlüsselung von Identitäten in Logs und Reports. Ein autorisierter Administrator kann die Angaben nach Authentifizierung wieder sichtbar machen. Das ist nicht dasselbe wie Löschung oder unumkehrbare Anonymisierung.

Sind Remote-Syslog und Sophos Fusion automatisch anonymisiert?

Das wird für diese Datenpfade in der aktuellen Featurebeschreibung nicht ausdrücklich bestätigt. Deshalb wird mit einem kontrollierten Event geprüft, was am tatsächlichen Syslog-Ziel, in Sophos Fusion, im CTR oder in einer heruntergeladenen Datei sichtbar ist.

Reicht ein einzelner Authorizer?

Die Oberfläche erlaubt einen oder mehrere Authorizer, Sophos empfiehlt jedoch mindestens zwei. Ist der angemeldete Administrator selbst Authorizer, ist die Zustimmung mindestens eines weiteren Authorizers erforderlich. Die Hilfe belegt aber keine zwingende Zweitfreigabe für jede einzelne Einblendung im Log Viewer. Für einen belastbaren Betrieb werden trotzdem zwei persönliche und getestete Konten verwendet.