32-7 · Kapitel 32 · 4 Min. Lesezeit

Wer hat dieses Secret gesehen? Warum Audit-Logs wichtiger sind als du denkst

Erfahre, warum Audit-Logs für Secrets unverzichtbar sind – von der Erkennung von Sicherheitsvorfällen bis zur gezielten Rotation. Mit praktischer Checkliste für DevOps und SRE.

Wer hat dieses Secret gesehen? Warum Audit-Logs wichtiger sind als du denkst

Du bekommst um 3 Uhr morgens eine Benachrichtigung. Jemand hat mit einer Produktionsdatenbank-Credential eine destruktive Abfrage ausgeführt. Der Schaden ist da. Deine erste Frage ist nicht „Wie sind sie reingekommen?“, sondern „Wer hatte Zugriff auf dieses Passwort?“

Wenn dein Team diese Frage nicht innerhalb von Minuten beantworten kann, hast du ein Problem, das keine noch so gute Verschlüsselung oder Rotation beheben kann. Ohne Audit-Logs fliegst du blind. Ein Secret könnte seit Wochen leaken, und du hättest keine Möglichkeit zu wissen, ob es ein externer Angriff oder jemand aus dem eigenen Team war.

Die Überwachungskamera für deine Secrets

Stell dir Audit-Logs für Secrets wie eine Sicherheitskamera am Gebäudeeingang vor. Jedes Mal, wenn jemand oder etwas ein Secret abruft, zeichnet der Tresor auf, wer die Anfrage gestellt hat, welches Secret angefragt wurde, die genaue Uhrzeit und woher die Anfrage kam. Diese Aufzeichnung nennt man Audit-Trail.

Die entscheidende Regel: Normale Benutzer können diese Logs weder deaktivieren noch löschen. Nur Administratoren mit speziellen Berechtigungen dürfen das. Wenn Benutzer ihre eigene Zugriffshistorie löschen könnten, wäre das gesamte Auditsystem nutzlos. Du hättest nur Logs, die zeigen, was andere sehen sollen.

Was jeder Audit-Trail erfassen muss

Ein brauchbarer Audit-Trail benötigt mindestens vier Informationen:

Wer hat zugegriffen. Das kann ein Benutzername, ein Servicekonto oder ein Anwendungsname sein. Du musst genau wissen, welche Identität die Anfrage gestellt hat – nicht nur „jemand vom Backend-Team“.

Auf welches Secret wurde zugegriffen. Erfasse den Namen oder Pfad des Secrets, nicht seinen Wert. Du musst das eigentliche Passwort nicht im Log speichern. Du musst nur wissen, dass „Produktionsdatenbank-Passwort“ abgerufen wurde.

Wann ist es passiert. Zeitstempel benötigen Sekundengenauigkeit. Bei der Untersuchung eines Vorfalls kann eine Abweichung von wenigen Minuten die gesamte Geschichte verändern. War der Zugriff fünf Minuten vor dem Vorfall oder fünf Minuten danach?

Das Ergebnis. War die Anfrage erfolgreich oder fehlgeschlagen? Wenn sie abgelehnt wurde, warum? Ein fehlgeschlagener Zugriffsversuch kann genauso wichtig sein wie ein erfolgreicher. Er könnte darauf hindeuten, dass jemand gestohlene Credentials testet.

Moderne Tresore wie HashiCorp Vault, AWS Secrets Manager und Azure Key Vault stellen diese Logs standardmäßig bereit. Die Logs können an ein SIEM-System oder einen zentralen Log-Speicher wie Elasticsearch gesendet werden. Wichtig ist nicht, wo die Logs leben, sondern wer sie lesen kann. Sicherheitsteams und Incident-Responder sollten Lesezugriff haben. Normale Entwickler müssen in der Regel nicht den Audit-Trail durchsuchen.

So sieht ein echter Audit-Log-Eintrag von HashiCorp Vault aus:

{
  "time": "2025-03-15T02:34:12.847Z",
  "type": "response",
  "auth": {
    "client_token": "hmac-sha256:abc123...",
    "display_name": "deploy-bot",
    "policies": ["deploy", "default"]
  },
  "request": {
    "path": "secret/data/production/db-password",
    "operation": "read",
    "remote_address": "10.0.1.42"
  },
  "response": {
    "data": {
      "data": null
    },
    "warnings": null
  }
}

Logs zu lesen erfordert Übung

Audit-Logs sind nicht nur für die forensische Analyse nach einem Vorfall da. Sie helfen dir, normale Muster zu verstehen, damit du Anomalien erkennen kannst.

Betrachten wir dieses Szenario: Dein Audit-Log zeigt, dass das Konto „deploy-bot“ um 2:34 Uhr auf das Secret „db-production-password“ zugegriffen hat. Ist das normal? Das kommt darauf an. Wenn deine Pipeline nachts regelmäßig Deployments durchführt, ist dieser Zugriff zu erwarten. Aber wenn für diese Nacht kein Deployment geplant war, musst du nachfragen. Vielleicht hat jemand einen manuellen Pipeline-Lauf ausgelöst. Oder die Credentials des deploy-bot wurden kompromittiert.

Hier sind häufige verdächtige Muster, die in Audit-Logs auftauchen:

Wiederholter Zugriff auf dasselbe Secret innerhalb eines kurzen Zeitfensters
Zugriff von einer IP-Adresse, die nicht zum üblichen Bereich deines Teams gehört
Ein Entwickler, der normalerweise nur auf Staging-Secrets zugreift, ruft plötzlich Produktions-Credentials ab
Zugriff auf Secrets in Umgebungen, die nicht zur Rolle des Benutzers passen

Der letzte Punkt ist knifflig. Manchmal braucht ein Entwickler tatsächlich Produktionszugriff für einen dringenden Fix. Aber wenn es ohne Erklärung wiederholt vorkommt, könnte es auf Missbrauch hindeuten. Das Audit-Log liefert dir die Daten, um dieses Gespräch zu führen.

Audit-Logs helfen auch bei der Wiederherstellung

Wenn du den Verdacht hast, dass ein Secret kompromittiert wurde, zeigen dir Audit-Logs, wie weit der Schaden reicht. Du kannst genau sehen, welche Identitäten dieses Secret innerhalb eines bestimmten Zeitfensters abgerufen haben. Das hilft dir, die Rotation zu priorisieren. Wenn nur ein Servicekonto auf das kompromittierte Secret zugegriffen hat, musst du nur die Credentials für dieses Konto rotieren. Wenn zwanzig verschiedene Benutzer und Anwendungen es abgerufen haben, hast du eine deutlich größere Aufräumarbeit vor dir.

Ohne Audit-Logs musst du vom Schlimmsten ausgehen und alles rotieren. Das verursacht unnötige Arbeit und Ausfallzeiten. Mit Audit-Logs rotierst du nur das, was rotiert werden muss.

Eine praktische Checkliste für Secret-Audit-Logs

Wenn du heute Secret-Management einrichtest, hier eine kurze Checkliste, um deine Audit-Abdeckung zu überprüfen:

Jeder Secret-Zugriff wird mit Identität, Secret-Name, Zeitstempel und Ergebnis protokolliert
Logs können von normalen Benutzern weder gelöscht noch geändert werden
Audit-Logs werden an einen zentralen Ort gesendet, den Sicherheitsteams abfragen können
Du hast einen Prozess, um Logs regelmäßig zu überprüfen, nicht nur bei Vorfällen
Du weißt, wie normale Zugriffsmuster für jede Umgebung aussehen

Das Fazit

Audit-Logs verhindern nicht, dass Secrets leaken. Aber sie geben dir die Fähigkeit, die wichtigste Frage nach einem Vorfall zu beantworten: Wer hat was gesehen und wann? Ohne diese Antwort rätst du nur. Und Raten in der Sicherheit ist der Weg, aus kleinen Vorfällen große Katastrophen zu machen.