Thema: logging
-
Audit-Logs: was aufzuzeichnen ist, wie man sie unverändert hält und wer sie lesen darf
Ein Audit-Log beantwortet, wer was an welchem Objekt getan hat, wann und mit welchem Ergebnis; es wird von der Anwendung für jede sicherheitsrelevante Aktion geschrieben, getrennt von Debug-Logs gehalten, durch zügiges Verschieben in einen Append-only- oder Write-once-Speicher vor Veränderung geschützt und nur unter protokolliertem, eingeschränktem Zugriff gelesen.
-
Log-Sampling bei Ereignissen mit hohem Volumen: jeden Fehler behalten, die repetitiven Zeilen sampeln
Sampling verwirft absichtlich einen Teil ähnlicher Log-Ereignisse; die nützlichen Formen sind Eins-von-N, Burst-dann-Rate je Zeitraum, Regeln je Level, die Warnungen und Fehler unangetastet lassen, sowie Pipeline-Sampling anhand einer Request-ID, sodass eine ganze Anfrage gemeinsam behalten oder verworfen wird, wobei die angewandte Rate in die überlebenden Ereignisse geschrieben wird.
-
Zugriffslogs für personenbezogene Daten: festhalten, wer welchen Datensatz gelesen hat
Ein Zugriffslog für personenbezogene Daten erfasst Lesezugriffe, nicht nur Schreibzugriffe: Akteur, betroffene Person, Objekt, Grund und Zeitpunkt, ausgelöst im Lesepfad der Anwendung und abgeglichen mit Statement-Logging auf Datenbankebene für Pfade, die daran vorbeiführen; es muss personenzentrierte Fragen beantworten wie: Wer hat sich im letzten Jahr den Datensatz dieser Person angesehen?
-
Personendaten in Belegen minimieren
Den kleinstmöglichen Belegdatensatz aufbewahren, der nötig ist, um eine Entscheidung nachzuvollziehen, unter Ausschluss unbeteiligter Identitäts- und Nutzdaten.
-
Datenminimierung als Disziplin für Schema und Protokollierung
Nur die Personendaten speichern, die ein Feature benötigt, in der gröbsten Genauigkeit, die dem Zweck genügt, und Kennungen durch Allowlisting von Feldern aus Logs heraushalten; jede Spalte, jedes Logfeld und jeder abgeleitete Speicher, der Personendaten trägt, ist eine Designentscheidung mit einem Zweck, einer verantwortlichen Person und einem Ablaufdatum, kein Standardfall.
-
Geheimnisse schwärzen, bevor Logs geschrieben werden
Einen per Allowlist definierten Diagnosedatensatz protokollieren statt roher Tool-Anfragen, und die Schwärzung an jedem Ausgabeziel überprüfen.
-
JSON Lines: ein Wert pro Zeile für Logs, Datensätze und gestreamte Antworten
JSON Lines (auch NDJSON genannt) setzt einen vollständigen JSON-Wert pro Zeile, UTF-8 ohne Byte Order Mark und mit Zeilenumbruch abgeschlossen; Dateien lassen sich anhängen, aufteilen, mit grep durchsuchen und komprimieren, und ein abgeschnittener Stream verliert nur seine letzte Zeile. RFC 7464 JSON Text Sequences fügen ein Record-Separator-Byte zur Wiederherstellung hinzu. Beides anstelle eines einzigen grossen JSON-Arrays verwenden, sobald Datensätze einzeln erzeugt oder konsumiert werden.
-
Carrying a request ID end to end: edge, logs, downstream calls and the response
Generate a request identifier at the edge (nginx offers $request_id, 16 random bytes in hex), pass it to the application in a header, keep it in request-scoped context so every log line and every outbound call carries it, and return it in the response so that a user's report can be matched to the logs of every service it touched; where tracing exists, the W3C trace ID is that identifier.
-
How much request detail should a small service log for security forensics without hoarding personal data?
Open question: the OWASP Logging cheat sheet lists events that should be logged and data that should not be, but between them lie query strings, request bodies, client addresses and user agents, which incident reconstruction wants and data minimisation argues against; which field sets, masking rules and retention tiers have small teams found workable?
Maschinenlesbar: JSON