Audit-Logs: was aufgezeichnet wird, wie sie unversehrt bleiben und wer sie lesen darf

Worum es geht

Das (zitierte) OWASP Logging Cheat Sheet verlangt, dass jeder Eintrag Wann, Wo, Wer und Was festhält: Ereignis- und Log-Zeitstempel, Anwendung und Host, die handelnde Nutzer- oder Maschinenidentität samt Quelladresse, den Ereignistyp, das betroffene Objekt, das Ergebnis und den Grund. Die Liste der stets zu protokollierenden Ereignisse umfasst erfolgreiche und fehlgeschlagene Authentifizierungen, Autorisierungsfehler, Aktionen der Nutzerverwaltung, die Nutzung administrativer Rechte, den Zugriff auf sensible Daten, die Nutzung und Rotation von Schlüsseln sowie Konfigurationsänderungen. Ein Audit-Log ist der Teilbereich davon, der Aktionen im Namen einer Identität dokumentiert und als Aufzeichnung geführt wird statt als Ausgabe für die 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 möglicher Angriffe auf Logs im Cheat Sheet nennt unter anderem, dass Angreifende Schreibvorgänge verhindern oder das Log beschädigen, 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 ausgeben, dort wo die handelnde Identität und das Objekt bekannt sind, als strukturierte Datensätze mit stabilem Schema: handelnde Instanz, Art der handelnden Instanz, Aktion, Objekttyp und -ID, Ergebnis, Grund, Request-ID, Zeitstempel in UTC.
• Die handelnde Instanz als Kennung erfassen, nicht als Anzeigename, und Impersonation («Admin X handelt als Nutzer Y») explizit festhalten.
• Keine Sitzungskennungen, 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 in einen Speicher überführen, den die Anwendung nicht verändern kann: eine Append-only-Tabelle unter einer reinen Schreibrolle der Datenbank oder Objektspeicher mit Aufbewahrungssperre. Das (zitierte) Amazon S3 Object Lock beschreibt ein Write-once-read-many-Modell, dessen Compliance-Modus Überschreiben oder Löschen durch beliebige Nutzende 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 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 aufzubewahren, 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 Nutzer-ID im Ereignis vertrauen. Ein unveränderliches Log, das bis zum Vorfall niemand liest.