Firewall-Logs und DSGVO: Personenbezug, Aufbewahrung und Löschkonzept für die Sophos XGS

Firewall-Logs und DSGVO — ein Thema, zu dem es erstaunlich wenig technik-nahes Material gibt, und die Kurzantwort vorab: Ja, XGS-Protokolle enthalten personenbezogene Daten — IP-Adressen, Benutzernamen, besuchte Ziele, Anmeldezeiten —, und deshalb gelten für sie dieselben Spielregeln wie für jede andere Verarbeitung: Rechtsgrundlage, Zweckbindung, begrenzte Aufbewahrung, geregelter Zugriff, dokumentierte Löschung. Das Dilemma dahinter ist real: Wer Logs unbegrenzt hortet, hat ein DSGVO-Problem — wer sie zu früh löscht, ein forensisches, denn Angriffe werden oft erst nach Wochen entdeckt. Die gute Nachricht: Zwischen beiden Klippen liegt ein bewährter Korridor, und der lässt sich mit der XGS, einem Syslog-Ziel und einem schlanken Konzept sauber umsetzen. Dieser Artikel liefert die Strecke komplett: was tatsächlich in den Logs steht, die Rechtsgrundlagen, den Fristen-Korridor, die technische Umsetzung, Zugriffs- und Löschkonzept — und den Umgang mit dem Auskunftsersuchen, wenn ein Mitarbeiter seine Log-Daten sehen will. Eine Einordnung vorweg: Das ist Praxiswissen aus Projekten, keine Rechtsberatung — die Abstimmung mit dem Datenschutzbeauftragten gehört bei diesem Thema fest dazu.

Was in XGS-Logs tatsächlich drinsteht

Bevor über Fristen geredet wird, gehört die Inventur auf den Tisch — denn »die Firewall-Logs« sind keine homogene Masse, sondern ein Bündel sehr unterschiedlich heikler Datenarten, wie die Landkarte in der Skizze zeigt. Die Spitzengruppe beim Personenbezug: das Web-Filter-Protokoll (Benutzername plus besuchte Ziele — eine Surf-Historie kann Gesundheitsrecherchen, religiöse Interessen oder Privates offenbaren und verdient die höchste Schutzstufe), die VPN- und Anmeldeprotokolle (Benutzer, private Anschluss-IPs, Zeitstempel — technisch taugt das zur Arbeitszeitkontrolle, weshalb hier die Mitbestimmung mit am Tisch sitzt, siehe [LINK: C3]) und, oft übersehen, jede Zeile eines benutzerbasierten Regelwerks, die konstruktionsbedingt einen Namen trägt. Das Mittelfeld: Verbindungsprotokolle mit internen IPs (über DHCP-Lease und Inventar einer Person zuordenbar — personenbezogen mit Umweg) sowie IPS- und ATP-Ereignisse. Und selbst die »harmlose« Ecke ist nicht leer: Das Admin-Audit-Protokoll dokumentiert das Handeln der Administratoren — personenbezogen für die IT selbst, und als Nachweisquelle gerade deshalb unverzichtbar. Merksatz aus der Landkarte: »Kein Personenbezug« gibt es in Firewall-Logs praktisch nicht — nur Abstufungen, und an denen orientieren sich Fristen und Zugriffe.

Skizze 1: Die Datenarten-Ampel — je röter, desto strenger gehören Zweck, Zugriff und Frist; die Tabellen dieses Artikels folgen ihr.

Rechtsgrundlagen der Protokollierung: berechtigtes Interesse und Co.

Die beruhigende Nachricht zuerst: Sicherheitsprotokollierung ist datenschutzrechtlich gut begründbar — sie braucht nur eine saubere Herleitung statt eines Schulterzuckens. Der Anker ist das berechtigte Interesse (Art. 6 Abs. 1 lit. f DSGVO): Die Erwägungsgründe der DSGVO nennen die Gewährleistung der Netz- und Informationssicherheit ausdrücklich als berechtigtes Interesse — Angriffe erkennen, abwehren und aufklären ist damit kein Graubereich, sondern der Musterfall. Dazu treten je nach Lage rechtliche Verpflichtungen als eigene Grundlage — wer unter NIS2 fällt, muss protokollieren ([LINK: C1]), und die vermeintliche Kollision löst sich elegant: Die Pflicht zur Protokollierung und die Pflicht zur Begrenzung widersprechen sich nicht, sie definieren gemeinsam den Korridor des nächsten Kapitels. Im Beschäftigtenkontext kommt der Beschäftigtendatenschutz hinzu, und mit ihm die entscheidende Leitplanke: Zweckbindung. Protokolliert wird zur Sicherheit — nicht zur Leistungs- und Verhaltenskontrolle; wo die Grenze verläuft und was der Betriebsrat dazu sagt, ist das Kernthema des Nachbar-Artikels. Formal gehören drei Dinge in die Akte: die dokumentierte Interessenabwägung, der Eintrag im Verarbeitungsverzeichnis — und bei eingriffsintensiven Konstellationen die DSFA-Prüfung. Klingt nach Papier, ist aber je ein Absatz — wenn man ihn schreibt, bevor jemand fragt.

Aufbewahrungsfristen: der praktikable Korridor

Die Fristenfrage ist der Kern des Themas, und sie hat zwei Klippen: Zu kurze Aufbewahrung reißt ein forensisches Loch — Kompromittierungen werden häufig erst nach Wochen entdeckt, und wer dann keine Protokolle mehr hat, kann weder Ausmaß noch Einstiegspunkt rekonstruieren, was nebenbei die NIS2-Nachweisfähigkeit ruiniert. Zu lange, pauschale Aufbewahrung kippt die Erforderlichkeit — »man weiß ja nie« ist keine Begründung, sondern das Eingeständnis, dass keine existiert. Dazwischen liegt der Korridor aus der Skizze, den der Faktenkasten zitierfähig zusammenfasst: 90 Tage als bewährter Regelwert, bis sechs Monate mit dokumentierter Sicherheitsbegründung, darüber hinaus nur anlassbezogen. Wichtig ist die Differenzierung nach der Datenarten-Ampel: Ein Korridor heißt nicht eine Frist für alles — die heikle Web-Filter-Ebene verträgt kürzere Fristen als das Verbindungsprotokoll, und das Admin-Audit-Log darf als Nachweisquelle bewusst länger leben. Die Tabelle liefert den Fristen-Vorschlag je Kategorie als Diskussionsgrundlage für die DSB-Abstimmung — denn erst die Abstimmung plus Dokumentation plus technische Automatisierung machen aus einer Zahl eine verteidigbare Frist.

Skizze 2: Unter 30 Tagen forensisch riskant, 30–90 Tage Regelkorridor, bis sechs Monate begründet, darüber nur mit Anlass — und je Datenart differenziert.

Technische Umsetzung: Retention auf XGS, Syslog-Ziel und SIEM

Jetzt zur Mechanik, und die beginnt mit einer ehrlichen Feststellung: Auf der XGS selbst lässt sich Aufbewahrung kaum steuern — die lokalen Protokolle rotieren speicherabhängig, nicht fristgenau. Deshalb hat die Architektur drei Bausteine. Baustein eins, auf der XGS: die Log-Einstellungen als Datenminimierungs-Hebel — hier wird entschieden, was überhaupt entsteht; die Regel aus der Sentinel-Anbindung ([LINK: B8]) gilt datenschutzrechtlich doppelt: erlaubten Standardverkehr gar nicht erst protokollieren, denn was nicht entsteht, muss weder begründet noch gelöscht werden. Baustein zwei, der Transport: Syslog über TLS an ein zentrales Ziel — Collector oder SIEM —, womit die Firewall-Box aus dem Fristen-Spiel weitgehend raus ist und die lokale Kopie nur als kurzlebiger Puffer dient. Baustein drei, das Ziel: Dort lebt die eigentliche Retention — im SIEM als konfigurierte Aufbewahrung je Tabelle beziehungsweise Datenquelle (in Sentinel etwa auf Arbeitsbereichs- und Tabellenebene einstellbar), auf einem schlichten Collector als geplanter Löschjob mit Protokoll. Damit bildet die Technik exakt die Tabelle aus Kapitel 3 ab: unterschiedliche Fristen je Kategorie, automatisiert statt handgepflegt — und der Löschnachweis fällt als Jobprotokoll gleich mit an.

Skizze 3: Fünf Stationen, fünf DSGVO-Prinzipien — und die Vorfalls-Ausnahme als dokumentierter Seitenweg. Jede Station ist eine Audit-Frage mit vorbereiteter Antwort.

Zugriffskonzept: Wer darf in die Logs schauen

Fristen begrenzen die Zeit — das Zugriffskonzept begrenzt die Augen, und es ist der Teil, der im Audit am häufigsten fehlt. Die Grundsätze: Zugriff nach Rollen statt nach Neugier, personalisierte Konten statt Sammelzugängen, und eine klare Trennung zwischen dem technischen Betriebsblick (Verbindungen, Fehlerbilder, Systemzustand) und der benutzerbezogenen Auswertung, die nur anlassbezogen, dokumentiert und — je nach Betriebsvereinbarung — im Vier-Augen-Prinzip mit Betriebsrats- oder DSB-Beteiligung stattfindet. Die Tabelle zeigt das Muster: Der Firewall-Administrator arbeitet täglich mit technischen Protokollen, der Sicherheitsanalyst wertet bei Verdacht aus, der Datenschutzbeauftragte liest prüfend, und die Geschäftsführung hat schlicht keinen Log-Zugang — Führung heißt Berichte lesen, nicht Rohdaten durchstöbern. Und die Klammer über allem: Auch der Zugriff auf Logs wird protokolliert — das Admin-Audit dokumentiert, wer wann hineingeschaut hat, womit die Kontrolle selbst kontrollierbar bleibt.

Das Löschkonzept dokumentieren

Das Löschkonzept ist kein Prosa-Roman, sondern eine strukturierte Seite, die fünf Fragen beantwortet — und die sich an der bewährten Systematik für Löschkonzepte (Stichwort DIN 66398) orientieren darf, ohne sie zu zelebrieren. Erstens: Welche Datenarten gibt es? — die Landkarte aus Kapitel 1 als Liste. Zweitens: Welche Frist gilt je Art und warum? — die Tabelle aus Kapitel 3 samt Begründungen. Drittens: Wie wird gelöscht? — die technischen Mechanismen aus Kapitel 4 (Retention-Einstellung, Löschjob) mit Verantwortlichem je Mechanismus. Viertens: Wie wird die Löschung nachgewiesen? — Jobprotokolle und eine jährliche Stichprobe, dass die Fristen real greifen (die Prüfung, ob das Konfigurierte auch geschieht, ist der Schritt, den fast alle auslassen). Fünftens: Welche Ausnahmen gelten? — die anlassbezogene Sicherung bei Vorfällen mit definiertem Ende. Das fertige Dokument wandert als Anlage zum Verarbeitungsverzeichnis und in den Nachweis-Ordner aus dem NIS2-Kontext — womit dieselbe Seite gleich zwei Prüfungen bedient. Bleibt ein Sonderfall, den der Hinweis-Kasten würdigt: die Backups.

Auskunftsersuchen: Wenn ein Mitarbeiter seine Log-Daten will

Artikel 15 DSGVO gilt auch hier: Jeder Betroffene — also auch jeder Mitarbeiter und Ex-Mitarbeiter — kann Auskunft verlangen, welche seiner Daten verarbeitet werden, und Firewall-Logs sind davon nicht ausgenommen. Der geordnete Ablauf: Identität des Anfragenden prüfen, den DSB einbinden, dann die Suche — praktisch über Benutzername und die dem Betroffenen zugeordneten Geräte-IPs im Aufbewahrungszeitraum. Bei der Aufbereitung gelten zwei Leitplanken: Auskunft umfasst die Daten des Betroffenen, nicht das Rohlog mit den Daten Dritter — Fremdes wird entfernt oder geschwärzt; und die Rahmenauskunft (Zwecke, Kategorien, Fristen, Empfänger) ist bei sauberem Konzept ein Auszug aus den vorhandenen Dokumenten. Die Frist: unverzüglich, spätestens binnen eines Monats. Und die unterschätzte Pointe, die die Praxis-Geschichte illustriert: Ein diszipliniertes Löschkonzept ist die beste Auskunfts-Vorbereitung — wer nur 90 Tage vorhält, hat wenig herauszusuchen, und »Daten aus früheren Zeiträumen sind gemäß Löschkonzept nicht mehr vorhanden« ist eine vollkommen rechtmäßige und wunderbar kurze Antwort.

FAQ — häufige Fragen zu Firewall-Logs und DSGVO

Wie lange darf ich Firewall-Logs aufbewahren?

So lange, wie es für den Sicherheitszweck erforderlich ist — und die bewährte Übersetzung dieser Formel ist der Korridor aus diesem Artikel: 90 Tage als Regelwert für Sicherheitsprotokolle, 30 Tage als forensische Untergrenze, bis sechs Monate mit dokumentierter Sicherheitsbegründung, und darüber hinaus nur anlassbezogen — bei einem konkreten Vorfall werden die betroffenen Protokolle gezielt gesichert und bis zum Abschluss vom Löschlauf ausgenommen. Wichtig sind drei Präzisierungen: Erstens differenziert die Frist nach Datenart — benutzerbezogene Web-Filter-Details eher kürzer, das Admin-Audit-Protokoll als Nachweisquelle bewusst länger (gern zwölf Monate, es dokumentiert die IT, nicht die Belegschaft). Zweitens wird aus der Zahl erst durch drei Zutaten eine verteidigbare Frist: Abstimmung mit dem Datenschutzbeauftragten, schriftliche Begründung im Löschkonzept, technische Automatisierung. Drittens ist die Gegenrichtung genauso falsch: Wer aus Datenschutz-Übervorsicht nach sieben Tagen löscht, reißt ein forensisches Loch und gefährdet die eigene Nachweisfähigkeit — der Korridor hat zwei Wände, nicht eine.

Sind IP-Adressen personenbezogene Daten?

Ja — diese Frage ist seit Jahren entschieden, auch wenn sie in jedem zweiten Projekt neu diskutiert wird. Die Rechtsprechungslinie: Der EuGH hat schon 2016 festgestellt, dass selbst dynamische IP-Adressen personenbezogen sind, wenn der Verantwortliche rechtliche Mittel hat, die dahinterstehende Person bestimmen zu lassen — und Aufsichtsbehörden wie Gerichte wenden diese Linie seither gefestigt und tendenziell streng an. Für die Unternehmens-Firewall ist die Lage noch eindeutiger, weil der Umweg über Dritte entfällt: Interne Adressen sind über DHCP-Leases, Geräteinventar und Anmeldeprotokolle unmittelbar zuordenbar, öffentliche Quell-IPs im VPN-Log gehören zum privaten Anschluss des Mitarbeiters, und in benutzerbasierten Regelwerken oder im Web-Filter steht der Klarname ohnehin daneben. Die praktische Konsequenz: Es gibt keine »anonyme« Ecke in den Firewall-Logs, hinter die man sich zurückziehen könnte — die gesamte Protokollierung ist eine Verarbeitung personenbezogener Daten und braucht die volle Ausstattung: Rechtsgrundlage, Zweckbindung, Fristen, Zugriffskonzept, Löschnachweis. Das klingt nach viel und ist mit den Bausteinen dieses Artikels ein überschaubares Paket.

Brauche ich eine Rechtsgrundlage für die Protokollierung?

Ja — jede Verarbeitung personenbezogener Daten braucht eine, und die gute Nachricht ist: Für Sicherheitsprotokollierung liegt sie bereit. Der Anker ist das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DSGVO — die DSGVO selbst nennt die Gewährleistung der Netz- und Informationssicherheit in ihren Erwägungsgründen ausdrücklich als berechtigtes Interesse, womit die Abwehr und Aufklärung von Angriffen der dokumentierte Musterfall ist. Wer unter NIS2 oder vergleichbare Regelwerke fällt, hat mit der gesetzlichen Protokollierungspflicht zusätzlich eine rechtliche Verpflichtung als Grundlage — Pflicht und Begrenzung widersprechen sich dabei nicht, sondern definieren gemeinsam den Aufbewahrungskorridor. Im Beschäftigtenverhältnis flankiert der Beschäftigtendatenschutz mit der zentralen Leitplanke der Zweckbindung: erhoben zur Sicherheit, nicht zur Verhaltenskontrolle. Formal zu erledigen sind drei kompakte Dinge: die Interessenabwägung schriftlich festhalten (warum überwiegt das Sicherheitsinteresse, welche mildernden Maßnahmen greifen), der Eintrag ins Verarbeitungsverzeichnis, und die DSFA-Prüfung mit dem DSB. Drei Dokumente, ein Nachmittag — und die Grundlage steht schriftlich statt gefühlt.

Muss der Datenschutzbeauftragte eingebunden werden?

Ja — und zwar nicht als Formalie am Ende, sondern als Mitgestalter von Anfang an, denn genau dafür ist die Rolle da. Die Einbindungspunkte entlang dieses Artikels: bei der Rechtsgrundlage (Interessenabwägung und VVT-Eintrag prüft der DSB ohnehin, DSFA-Frage inklusive), bei den Fristen (der Korridor wird gemeinsam festgelegt — eine mit dem DSB abgestimmte und begründete Frist ist gegenüber der Aufsicht ein völlig anderes Kaliber als eine einsam gewählte), beim Zugriffskonzept (der DSB gehört als prüfende Rolle hinein und bei anlassbezogenen benutzerbezogenen Auswertungen an den Tisch), beim Löschkonzept (Dokumentations- und Nachweisfragen sind sein Heimspiel) und beim Auskunftsersuchen (Fristenwahrung, Schwärzungsfragen, Kommunikation). Wo ein Betriebsrat existiert, läuft die Mitbestimmungsschiene parallel — sie ersetzt die DSB-Einbindung nicht und umgekehrt; das Dreieck IT, DSB, Betriebsrat samt Fahrplan ist Thema des Nachbar-Artikels. Der pragmatische Rat: den DSB mit einem Konzeptentwurf ansprechen statt mit einer offenen Frage — konkrete Vorlagen beschleunigen die Abstimmung um Wochen.

Wie setze ich Löschfristen auf der XGS technisch um?

Die ehrliche Antwort vorweg: kaum auf der XGS selbst — und genau das ist die Architektur-Erkenntnis. Die lokalen Protokolle der Firewall rotieren speicherabhängig; eine granulare, datenart-spezifische Fristensteuerung bietet die Box nicht, und sie muss es auch nicht, denn ihr Job in einem sauberen Konzept ist ein anderer: Erstens die Datenminimierung an der Quelle — in den Protokolleinstellungen festlegen, was überhaupt entsteht (erlaubten Standardverkehr nicht mitschreiben: spart Datenschutz-Aufwand und SIEM-Kosten in einem). Zweitens der sichere Abtransport — Syslog über TLS an das zentrale Ziel, womit die lokale Kopie zum kurzlebigen Puffer wird. Die eigentliche Fristensteuerung lebt am Ziel: im SIEM als konfigurierte Aufbewahrung (in Sentinel etwa auf Arbeitsbereichs- und Tabellenebene — die differenzierten Fristen der Tabelle lassen sich direkt abbilden), auf einem schlichten Collector als geplanter Löschjob mit Protokoll. Dazu die zwei Vollständigkeits-Häkchen: die Backup-Kette des Log-Systems auf einen kurzen Zyklus begrenzen (sonst leben gelöschte Logs in Sicherungen weiter) und einmal jährlich per Stichprobe prüfen, ob die konfigurierte Löschung tatsächlich greift — der Nachweis, den fast alle vergessen.

Was gebe ich bei einem Auskunftsersuchen heraus?

Die Daten des Betroffenen plus die Rahmenauskunft — und nichts darüber hinaus. Konkret: Erstens die zum Anfragenden gespeicherten Protokolldaten im aktuellen Aufbewahrungszeitraum — gefunden über Benutzername und die ihm zugeordneten Geräte beziehungsweise Adressen; herausgegeben in verständlicher Form (ein aufbereiteter Auszug, kein Rohdaten-Export im Firewall-Dialekt). Dabei gilt die Dritten-Regel: Zeilen und Felder mit Daten anderer Personen — fremde Benutzer, fremde Adressen — werden entfernt oder geschwärzt, denn das Auskunftsrecht des einen ist keine Einsicht in die Daten der anderen. Zweitens die Rahmenauskunft nach Art. 15: Verarbeitungszwecke, Datenkategorien, Aufbewahrungsdauer beziehungsweise Fristkriterien, Empfänger — bei einem sauberen Konzept ist das ein Auszug aus VVT und Löschkonzept, also Textbausteine statt Rechercheprojekt. Die Frist: unverzüglich, spätestens ein Monat. Drei Praxis-Hinweise: Identität des Anfragenden vorher verifizieren (sonst wird die Auskunft selbst zur Datenpanne); den DSB von Beginn an einbinden; und für fristgerecht gelöschte Zeiträume gilt die kürzeste aller Antworten — »gemäß Löschkonzept nicht mehr vorhanden« ist rechtmäßig, vollständig und der schönste Lohn der Fristen-Disziplin.

Fazit: Der Korridor ist machbar — und schützt in beide Richtungen

Firewall-Protokollierung und DSGVO sind keine Gegner, sondern zwei Anforderungen mit einer gemeinsamen Lösung: dem dokumentierten Korridor. Die Zutaten sind überschaubar — die Datenarten-Inventur mit ehrlicher Personenbezug-Ampel, die schriftliche Rechtsgrundlage (das berechtigte Interesse an Netzsicherheit trägt), differenzierte Fristen um den 90-Tage-Regelwert, die technische Umsetzung mit Datenminimierung an der Quelle und Retention am Syslog-Ziel, ein Zugriffskonzept mit Anlass-Prozess statt Neugier-Zugang, ein Löschkonzept von einer Seite samt Backup-Klausel — und der DSB als Mitgestalter von Anfang an. Wer das stehen hat, ist in beide Richtungen geschützt: gegenüber der Aufsicht und dem Auskunftsersuchen, weil jede Frist begründet und jede Löschung nachweisbar ist — und gegenüber dem Angreifer, weil im Ernstfall neunzig Tage Rückblick bereitliegen statt eines leeren Ordners. Datenschutz und Forensik streiten hier nicht. Sie teilen sich einen Korridor.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Mitbestimmung, Betriebsvereinbarung und die datensparsame Web-Filter-Konfiguration vertieft [LINK: C3]. Die technische Log-Pipeline Richtung Sentinel samt Kostenlogik steht in [LINK: B8]. Und wie aus Protokollen belastbare Nachweisketten für Prüfungen werden, zeigt [LINK: C4].