Zum Inhalt springen
Avanet

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 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 Vier-Augen-Prinzip vorbereiten

Beim Aktivieren werden Administratoren als Authorizer ausgewählt. Diese Rolle darf anonymisierte Identitäten nach erneuter Authentifizierung sichtbar machen. Sophos empfiehlt mindestens zwei Authorizer. Ist der aktuell angemeldete Administrator selbst als Authorizer eingetragen, wird die Zustimmung mindestens eines weiteren Authorizers benötigt.

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.

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ähiger Administrator vorhanden ist oder der zweite Authorizer noch nicht positiv getestet wurde.

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 Sophos verlangte Zustimmung mit dem zweiten Authorizer erteilen.
  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

  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 keine Einblendung möglich ist.

Ein erfolgreicher Authorizer-Test beweist nur diesen konkreten WebAdmin-Pfad. Er beweist noch nicht, dass PDF, CSV, Central, 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 und externe Datenpfade abnehmen

In einem HA-Cluster wird Data Anonymization nach einem kontrollierten Failover erneut geprüft. Dazu wird am dann aktiven Node eine neue Testsitzung erzeugt und der Log-Viewer-Ablauf wiederholt. Eine bestehende WebAdmin-Sitzung oder ein Test nur auf dem früheren Primary ist kein ausreichender Nachweis.

Remote-Syslog, Central 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 und die eigenen aktuellen Authentifizierungsdaten verwendet werden. Ist der angemeldete Administrator selbst Authorizer, wird die notwendige Freigabe durch einen weiteren Authorizer eingeplant.

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 Central, 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 die bisherigen Einstellungen dokumentiert. Falls die neue Konfiguration den vereinbarten Betrieb nicht erfüllt, wird unter System services > Data anonymization der vorherige Zustand mit einem autorisierten Change wiederhergestellt. Danach werden ein neues Logevent, die Authorizer-Sicht, ein CSV-Export und bei Bedarf ein PDF erneut geprüft.

Ausnahmen werden zuerst entfernt oder auf den 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, Central, CTR und Shell-Logs separat bewertet
  • HA-Failover mit neuem Event abgenommen
  • 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 Central 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 Central, 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, wird mindestens ein weiterer Authorizer für die Zustimmung benötigt. Für einen lockout-sicheren Betrieb werden deshalb zwei persönliche und getestete Konten verwendet.