Du entdeckst, dass die Anwendungsprotokolle vollständige Kreditkartennummern und Passwörter im Klartext enthalten. Was ist die Korrekturpriorität?
Kurzantwort
Sensible Daten sollten niemals in Logs gelangen: redigiere oder maskiere zuerst an der Quelle, um die Blutung zu stoppen, behebe dann die historischen Logs und verschärfe die Zugriffe. PCI DSS verbietet, vollständige PANs und CVVs so zu speichern, und Passwörter sollten überhaupt nie protokolliert werden. „Interne" Logs sind weiterhin ein erstrangiges Angriffsziel. Den Speicher zu verschlüsseln oder mit ACLs zu versehen lässt trotzdem Klartext-Geheimnisse in den Logs liegen, lesbar für jeden mit Lesezugriff — Backups, SIEM-Pipelines und Administratoren sehen sie alle.
Die Falle bei dieser Frage besteht darin, protokollierte Geheimnisse als Zugriffskontrollproblem zu behandeln, obwohl es in Wahrheit ein Problem der Datensparsamkeit ist. Die Daten sollten überhaupt nicht dort sein — der erste Schritt ist also, aufzuhören, sie zu erzeugen.
Warum Redaktion an der Quelle zuerst kommt
Logs sind kein privater Tresor. Sie werden an SIEMs verschickt, in Backups kopiert, über Regionen repliziert, von Suchwerkzeugen indexiert und von Bereitschaftsingenieuren gelesen. Jede dieser Kopien ist nun ein Klartext-Speicher für Anmeldedaten und Karteninhaberdaten. PCI DSS verbietet ausdrücklich, vollständige Primary Account Numbers in dieser Form zu speichern, und verbietet, sensible Authentifizierungsdaten wie CVVs nach der Autorisierung zu speichern; Passwörter sollten in keiner Form protokolliert werden. Schritt eins ist also, an der Quelle zu maskieren oder zu redigieren — die Anwendung daran hindern, die sensiblen Felder überhaupt zu schreiben. Das stoppt die Blutung. Erst dann behebst du die bestehenden Logs (historische Einträge purgen oder bereinigen, einschließlich Backups und nachgelagerter Kopien) und überprüfst/verschärfst, wer darauf zugreifen kann.
Warum die Ablenker falsch sind
- So lassen — die Logs sind intern. „Intern" ist keine Sicherheitsgrenze. Insider, ein kompromittiertes Konto, ein fehlkonfigurierter Bucket oder ein Einbruch machen aus diesen Logs eine Offenlegung. Das ist die Nichts-tun-Antwort.
- Den gesamten Server verschlüsseln, die Daten weiter protokollieren. Verschlüsselung im Ruhezustand schützt vor gestohlenen Festplatten, aber die Anwendung, das SIEM, jeder Administrator und jedes Backup lesen die Geheimnisse weiterhin im Klartext. Die Geheimnisse sind immer noch da. Du hast den Raum abgeschlossen, aber den Tresor darin offen gelassen.
- Einfach einschränken, wer die Logs lesen darf. ACLs zu verschärfen ist ein guter unterstützender Schritt, lässt aber allein lebende Geheimnisse in den Logs, die sich über Pipelines und Backups verbreiten — eine Fehlkonfiguration von der Offenlegung entfernt.
Was der Interviewer ergründet
Er will den Instinkt zur Datensparsamkeit: die Quelle vor den Symptomen beheben. Die starke Antwort nennt PCI DSS, erkennt, dass „intern" und „im Ruhezustand verschlüsselt" das Klartext-in-Logs-Problem nicht lösen, und ordnet korrekt — aufhören, es zu schreiben, dann bereinigen, was bereits da ist, dann den Zugriff härten.
Wahrscheinliche Anschlussfragen
- An welcher Stelle im Stack würdest du die Redaktion implementieren, damit nie etwas Sensibles geschrieben wird?
- Was sagt PCI DSS konkret zur Speicherung von PANs und Authentifizierungsdaten?
- Wie könnten sich die Daten über den Log-Server hinaus verbreitet haben, und wie bereinigst du das?