Audit-Beweise auf AWS: Logs sind nicht gleich Nachweise

Der Satz fällt in fast jedem Vorgespräch: «Wir loggen alles.» Das stimmt meistens sogar. CloudTrail läuft, die Anwendung schreibt in CloudWatch, die Datenbank hat ihr Audit-Log. Und trotzdem beginnt die eigentliche Arbeit genau hier, denn ein Auditor prüft nicht, ob Daten existieren. Er prüft, ob sie als Nachweis taugen.

Drei Eigenschaften, die ein Nachweis braucht

Aus einer Logzeile wird erst dann ein Beweis, wenn drei Dinge zutreffen:

1. Vollständigkeit. Der Zeitraum hat keine Lücken, und niemand kann eine Lücke erzeugen, ohne dass das auffällt.
2. Integrität. Der Inhalt lässt sich nachträglich nicht ändern, und diese Behauptung ist technisch prüfbar statt nur organisatorisch zugesichert.
3. Aufbewahrung. Die Daten überleben die geforderte Frist, auch wenn jemand mit weitreichenden Rechten etwas anderes möchte.

Ein Log in CloudWatch, dessen Retention eine Zahl ist, die eine Handvoll Leute jederzeit ändern können, erfüllt Punkt zwei und drei nicht. Für den Betrieb ist es trotzdem wertvoll. Als Nachweis ist es angreifbar, und genau darauf zielen die Fragen im Audit.

Ein Ort für Beweise, nicht viele

Der erste Architekturentscheid ist deshalb kein technischer, sondern ein organisatorischer: Es gibt genau einen Ort, an dem Nachweise liegen. Ein separater S3-Bucket, dessen einzige Aufgabe die Aufbewahrung von Audit-Artefakten ist, mit eigenen Zugriffsregeln und ohne jede andere Nutzung.

Die Immutabilität kommt von S3 Object Lock. Wichtig für die Planung: Object Lock setzt Versionierung auf dem Bucket voraus, und man sollte diese Entscheidung möglichst früh treffen, statt sie später in eine gewachsene Struktur nachzuziehen.

Governance oder Compliance, und warum das keine Formalie ist

Object Lock kennt zwei Modi, und die Wahl dazwischen ist die interessanteste Entscheidung im ganzen Aufbau.

Im Compliance-Modus kann niemand ein Objekt vor Ablauf der Frist löschen. Auch der Root-Account nicht. Das ist die stärkste Zusicherung, die AWS technisch anbietet, und zugleich ein Versprechen, das man nicht zurücknehmen kann.

Im Governance-Modus existiert ein Notausgang: Wer die Berechtigung s3:BypassGovernanceRetention besitzt, kann die Sperre umgehen. Das klingt zunächst wie ein Weichspüler, ist aber praxistauglicher, als es aussieht. Entscheidend ist, was daraus folgt: Der Bypass ist eine explizite, eng vergebene Berechtigung, und jede Nutzung erzeugt selbst wieder ein CloudTrail-Ereignis. Aus einer stillen Löschung wird ein dokumentierter Vorgang mit Namen und Zeitstempel.

Für eine Umgebung, die erstmals auf ein Zertifizierungsaudit zugeht, ist Governance in der Regel der richtige Startpunkt. Compliance ist der stärkere Modus, aber er verzeiht keine Fehlkonfiguration bei der Aufbewahrungsdauer. Wer versehentlich zehn Jahre einträgt, lebt zehn Jahre damit.

CloudTrail: der Unterschied zwischen Protokoll und Beweis

CloudTrail zeichnet auf, wer welchen API-Aufruf gemacht hat. Ohne aktivierte Log File Validation ist das Ergebnis allerdings eine Textdatei im Bucket, und eine Textdatei beweist nichts über sich selbst.

Mit aktivierter Validierung erzeugt CloudTrail zusätzlich Digest-Dateien: Hashes über die ausgelieferten Logdateien, signiert und miteinander verkettet. Damit lässt sich später prüfen, ob eine Datei verändert oder aus der Kette entfernt wurde. Das ist der Punkt, an dem aus einem Protokoll ein Nachweis wird, und es ist ein Häkchen, das erstaunlich oft fehlt.

Die Lücke, die fast immer offen bleibt

Bis hierhin ist die Infrastrukturebene abgedeckt. Die Datenbank ist es nicht.

Das Audit-Log einer verwalteten MariaDB-Instanz landet in CloudWatch Logs. Dort ist es gut aufgehoben für Betrieb und Fehlersuche, unterliegt aber wieder einer Retention-Einstellung statt einer echten Sperre, und es liegt ausserhalb des Beweisspeichers. Im Audit führt das zu einer unangenehmen Situation: Für die Infrastruktur gibt es lückenlose, prüfbare Nachweise, für Zugriffe auf die eigentlichen Daten nur ein Log mit weicheren Garantien.

Die Lücke lässt sich mit wenig Code schliessen. Eine periodisch laufende Lambda-Funktion holt die Audit-Einträge aus CloudWatch ab und schreibt sie in denselben Evidence-Bucket, unter dieselbe Object-Lock-Regel. Der Aufwand ist überschaubar, der Effekt im Audit ist gross: Alle Nachweise liegen an einem Ort und unterliegen denselben Regeln, unabhängig davon, auf welcher Ebene das Ereignis entstanden ist.

Womit anfangen

Wer eine bestehende Umgebung in diese Richtung bewegen will, kommt mit dieser Reihenfolge am schnellsten voran:

• CloudTrail prüfen, bevor irgendetwas Neues gebaut wird. Läuft ein organisationsweiter Trail? Ist Log File Validation aktiv? Das sind zwei Einstellungen und der grösste Einzelgewinn.
• Den Evidence-Bucket separat aufsetzen, mit Versionierung und Object Lock im Governance-Modus, und die Bypass-Berechtigung an genau eine Rolle binden.
• Aufbewahrungsfristen mit den Fachbereichen klären, nicht schätzen. Eine zu kurze Frist fällt im Audit auf, eine zu lange kostet dauerhaft Geld und lässt sich im Compliance-Modus nicht korrigieren.
• Erst danach die Lücken schliessen, also Datenbank-Audit-Logs und alles andere, was noch ausserhalb des Beweisspeichers liegt.

Der eigentliche Gewinn zeigt sich nicht am Audittag, sondern in den Wochen davor: Wenn die Nachweise durchgängig an einem Ort liegen und ihre Integrität technisch prüfbar ist, wird aus der Vorbereitung ein Export statt einer Suche.