Audit-Logs: was aufzuzeichnen ist, wie man sie unverändert hält und wer sie lesen darf

Worum es geht

Das (zitierte) OWASP Logging Cheat Sheet verlangt, dass jeder Eintrag festhält, wann, wo, wer und was: Ereignis- und Log-Zeitstempel, Anwendung und Host, die handelnde Benutzer- oder Maschinenidentität samt Quelladresse, die Art des Ereignisses, das betroffene Objekt, das Ergebnis und den Grund. Seine Liste der stets zu protokollierenden Ereignisse umfasst erfolgreiche und fehlgeschlagene Authentifizierungen, Autorisierungsfehler, Aktionen der Benutzerverwaltung, die Nutzung administrativer Rechte, Zugriffe auf sensible Daten, Schlüsselnutzung und -rotation sowie Konfigurationsänderungen. Ein Audit-Log ist der Teil davon, der Aktionen im Auftrag eines Principals dokumentiert und als Aufzeichnung geführt wird, nicht als Ausgabe zur Fehlersuche.

Warum es wichtig ist

Ein Audit-Log ist nur dann etwas wert, wenn es für die relevanten Aktionen vollständig ist und nicht von der Person, deren Handlungen es aufzeichnet, unbemerkt verändert werden kann. Die eigene Liste der Angriffe auf Logs im Cheat Sheet nennt unter anderem, dass ein Angreifer Schreibvorgänge verhindert oder das Log beschädigt, um Spuren zu verwischen, und dass die falsche Identität protokolliert wird, um die verantwortliche Partei zu verschleiern.

So wird es angewendet

• Audit-Ereignisse aus der Anwendungsschicht heraus auslösen, wo Principal und Objekt bekannt sind, als strukturierte Datensätze mit stabilem Schema: Akteur, Akteurstyp, Aktion, Objekttyp und -id, Ergebnis, Grund, Request-id, Zeitstempel in UTC.
• Den Akteur als Kennung erfassen, nicht als Anzeigename, und Impersonation („Admin X handelt als Benutzer Y“) ausdrücklich einschliessen.
• Keine Session-Kennungen, Zugriffstoken, Passwörter, Schlüssel oder vollständigen Personendaten schreiben; das Cheat Sheet führt diese unter den Daten auf, die auszuschliessen oder zu maskieren sind.
• Einträge zügig an einen Speicher übertragen, den die Anwendung nicht verändern kann: eine Append-only-Tabelle unter einer reinen Schreibrolle in der Datenbank oder Objektspeicher mit Aufbewahrungssperre. Das (zitierte) Amazon S3 Object Lock beschreibt ein Write-once-read-many-Modell, dessen Compliance-Modus das Überschreiben oder Löschen durch jeden Benutzer während der Aufbewahrungsfrist verhindert.
• Manipulationsnachweise ergänzen, zum Beispiel eine Hash-Kette oder periodisch signierte Prüfsummen, und diese nach Zeitplan verifizieren.
• Den Lesezugriff auf eine namentlich benannte Gruppe beschränken, jeden Lesezugriff protokollieren und die Berechtigungsliste periodisch überprüfen, wie es das Cheat Sheet verlangt.
• Die Aufbewahrungsdauer im Voraus festlegen und nach Zeitplan löschen; Audit-Daten über ihren Zweck hinaus zu behalten, ist selbst ein Risiko.

Stolpersteine

Audit-Datensätze mit Anwendungslogs vermischen, die nach einer Woche rotieren. Die Absicht protokollieren („Löschung angefordert“), aber nicht das Ergebnis. Freitextmeldungen, die sich nicht abfragen lassen. Einer vom Client mitgelieferten Benutzer-id im Ereignis vertrauen. Ein unveränderliches Log, das bis zum Vorfall nie jemand liest.