BSI-Richtlinien für sichere Protokollierung: Sensible Daten in Logs vermeiden

Protokolldaten sind für Betrieb, Fehlersuche und Angriffserkennung unverzichtbar. Gleichzeitig können Logs selbst zum Risiko werden: Zugangsdaten, Tokens, personenbezogene Daten oder vollständige Nutzereingaben landen häufig unbemerkt in zentralen Speichern. BSI-Richtlinien zur Protokollierung verlangen deshalb nicht einfach „mehr Logs“, sondern verbindliche Regeln für Inhalt, Schutz, Bereitstellung und Löschung.

Die praktische Herausforderung lautet: Wie lassen sich sicherheitsrelevante Informationen erfassen, ohne unnötige sensible Daten zu sammeln oder die Beweiskraft der Originalprotokolle durch nachträgliches Umschreiben zu gefährden?

Der BSI-Rahmen für sichere Protokollierung

Der IT-Grundschutz-Baustein OPS.1.1.5 Protokollierung sieht eine Sicherheitsrichtlinie vor, in der geregelt wird, was, wie und wo protokolliert wird. Außerdem müssen rechtliche Rahmenbedingungen, Persönlichkeitsrechte, Speicherfristen und geregelte Löschung berücksichtigt werden. Für die zentrale Auswertung ist zugleich wichtig, benötigte Originalinformationen geschützt und nachvollziehbar bereitzustellen.

Auch der BSI-Mindeststandard zur Protokollierung und Detektion, Version 2.0 betont Planung, Dokumentation und einen kontrollierten Umgang mit Protokolldaten.

Eine automatische Prüfung auf Secrets oder personenbezogene Daten wird dort nicht als konkretes Produkt vorgeschrieben. Ein „LogPolicyGate“ ist deshalb eine sinnvolle Produktableitung. Es kann eine definierte Richtlinie technisch durchsetzen, ersetzt aber nicht die juristische Bewertung, den Schutzbedarf, die Entscheidung über erforderliche Originaldaten oder ein vollständiges Berechtigungskonzept.

Warum sensible Daten in Logs landen

Das Problem entsteht häufig nicht im zentralen SIEM, sondern deutlich früher:

• Entwickler protokollieren komplette Request- oder Response-Objekte.
• Fehlermeldungen enthalten Sitzungs-IDs, Tokens oder Verbindungszeichenfolgen.
• Debug-Protokollierung bleibt nach einer Störung dauerhaft aktiviert.
• Anwendungen übernehmen Freitextfelder ungefiltert in Logs.
• Unterschiedliche Teams verwenden widersprüchliche Maskierungsregeln.
• Produktiv-, Support- und Sicherheitslogs haben dieselben Zugriffsrechte.

Nach der zentralen Speicherung sind diese Daten meist mehrfach repliziert: im Collector, im SIEM, im Archiv, in Exporten und möglicherweise in Tickets. Eine späte Bereinigung ist dadurch teuer und riskant.

Eine direkte Lösung: Richtlinien vor der Speicherung durchsetzen

Ein wirksamer Ansatz verbindet organisatorische Vorgaben mit Kontrollen an mehreren Stellen. Die wichtigste Maßnahme ist nicht eine einzelne Erkennungstechnologie, sondern ein klarer Entscheidungsprozess.

1. Protokollierungszwecke festlegen: Für jeden Ereignistyp wird dokumentiert, warum er benötigt wird – etwa Betrieb, Sicherheit, Nachweis oder Fehleranalyse.
2. Erlaubte und verbotene Felder definieren: Eine Positivliste beschreibt notwendige Felder. Explizite Verbote gelten beispielsweise für Passwörter, private Schlüssel und vollständige Zugriffstokens.
3. Kontrollen in der Entwicklung einbauen: Statische Prüfungen suchen nach riskanten Logging-Aufrufen. Tests speisen markierte Beispieldaten ein und kontrollieren die Ausgabe.
4. Laufzeitdaten überwachen: Stichproben oder regelbasierte Scanner erkennen Muster, die erst im Betrieb auftreten.
5. Ausnahmen steuern: Jede Ausnahme benötigt Zweck, Verantwortliche, Schutzmaßnahmen und Ablaufdatum.
6. Speicherung und Zugriff trennen: Unveränderte Originaldaten werden – falls erforderlich – besonders geschützt. Für breitere Auswertungen können minimierte oder maskierte Sichten verwendet werden.
7. Löschfristen technisch abbilden: Fristen müssen je Logklasse nachvollziehbar umgesetzt und kontrolliert werden.

Drei praktische Testfälle

Testfall 1: Token im Fehlerpfad

Eine Testanwendung erzeugt kontrolliert einen Fehler, während ein eindeutig markiertes Testtoken verarbeitet wird. Der Test prüft Anwendungslog, Container- oder Systemlog, Collector und SIEM. Erwartet wird, dass das Token entweder gar nicht erscheint oder entsprechend der Richtlinie sicher maskiert wird.

Testfall 2: Personenbezogene Freitextdaten

Ein Formular erhält synthetische Namen, Telefonnummern und E-Mail-Adressen. Danach wird geprüft, welche Bestandteile in normalen Betriebslogs, Sicherheitslogs und Fehlerberichten auftauchen. Wichtig ist die getrennte Bewertung: Nicht jede Zeichenfolge mit einem entsprechenden Muster ist tatsächlich personenbezogen, und nicht jede sensible Information lässt sich mit regulären Ausdrücken zuverlässig erkennen.

Testfall 3: Ablauf einer Löschfrist

Eine Test-ID wird in einer definierten Logklasse gespeichert. Nach Ablauf der vorgesehenen Frist wird kontrolliert, ob sie aus Primärspeicher, Suchindex und vorgesehenen Replikaten entfernt wurde. Backups und unveränderliche Archive benötigen eigene, fachlich abgestimmte Regeln; eine sofortige physische Einzellöschung ist dort nicht immer technisch möglich.

Originaldaten nicht unkontrolliert überschreiben

Ein häufiger Fehler besteht darin, vorhandene Protokolldaten nachträglich pauschal umzuschreiben. Das kann Integrität, Nachvollziehbarkeit und forensische Nutzbarkeit beeinträchtigen. Besser ist eine abgestufte Architektur:

• notwendige Originaldaten in einem besonders geschützten Bereich,
• minimierte oder maskierte Arbeitskopien für breitere Nutzergruppen,
• klar geregelte Freigaben für den Zugriff auf Originale,
• unveränderliche Dokumentation der angewendeten Transformationen.

Welche Variante zulässig und erforderlich ist, hängt von Zweck, Rechtsgrundlage, Schutzbedarf und der konkreten Systemlandschaft ab. Das ist keine Entscheidung, die ein Scanner allein treffen kann.

Welche Nachweise im Audit helfen

Ein belastbarer Nachweis verbindet Richtlinie und technische Umsetzung. Sinnvoll sind eine Liste der Logklassen, genehmigte Feldschemata, dokumentierte Verbote, Ergebnisse der Entwicklungs- und Laufzeitprüfungen, eine Übersicht aktiver Ausnahmen, Zugriffsprotokolle sowie Nachweise über umgesetzte Löschfristen.

Zusätzlich sollte dokumentiert werden, wie Fehlalarme behandelt werden. Ein Erkennungssystem, das ständig unkritische Zeichenfolgen meldet, wird im Alltag umgangen. Regeln brauchen deshalb Verantwortliche, Tests, Versionen und einen nachvollziehbaren Änderungsprozess.

Fazit

BSI-orientierte Protokollierung bedeutet, Sicherheitsnutzen und Datensparsamkeit gemeinsam zu steuern. Die beste Stelle zur Vermeidung sensibler Logdaten liegt möglichst früh – in Architektur, Entwicklung und Konfiguration. Automatische Prüfungen können dabei sehr wirksam sein, wenn sie auf einer freigegebenen Richtlinie beruhen und Originaldaten nicht unkontrolliert verändern.

Offizielle BSI-Quellen

• IT-Grundschutz OPS.1.1.5 Protokollierung
• BSI-Mindeststandard Protokollierung und Detektion von Cyber-Angriffen, Version 2.0

AI Governance Freelancer

Unterstützung bei AI Governance, KI-Code-Prüfung und sicherer Automatisierung

Ich unterstütze Unternehmen bei der sicheren Einführung von ChatGPT, Copilot, KI-Agenten und moderner Enterprise-Automatisierung. Mein Fokus liegt auf AI Governance, Compliance, sicherer KI-Nutzung und der strukturierten Kontrolle von KI-generiertem Code.

Zusätzlich verfüge ich über eigene Softwarelösungen zur automatisierten Analyse von Code, Skripten und KI-generierten Automatisierungen, um Risiken, unsichere Muster und Governance-Themen frühzeitig sichtbar zu machen.

Gerne tausche ich mich mit Ihnen in einem unverbindlichen virtuellen Kaffee über AI Governance, sichere KI-Einführung und Governance-Strategien im Enterprise-Umfeld aus.

Virtuellen Kaffee vereinbaren

Bildquelle: OpenAI