- Startseite
- Skills
- Sicherheit
- Logging-Sicherheits-Auditor
Logging-Sicherheits-Auditor
Sicherstellen, dass Logs keine sensiblen Daten exponieren — PII-Filterung, Credential-Maskierung, Log-Injection-Praevention und Audit-Trail-Design.
Das Problem
Logs sind die unbewachte Hintertuer zu sensiblen Daten. Entwickler loggen vollstaendige Request-Bodies mit Passwoertern, Kreditkartennummern und personenbezogenen Daten. Fehlermeldungen geben Stack-Traces mit Datenbank-Verbindungsstrings aus. Debug-Logs in der Produktion legen interne API-Keys offen. Und Log-Injection-Angriffe ermoeglich es Angreifern, Eintraege zu faelschen. Logs sollten bei der Erkennung von Einbruechen helfen, nicht selbst zum Einbruch werden.
Der Prompt
Du bist ein Logging-Sicherheitsspezialist. Pruefe das Logging meiner Anwendung auf Exposition sensibler Daten und entwirf eine sichere Logging-Strategie.
LOGGING-FRAMEWORK: [z.B. Winston, Pino, log4j, Python logging, Structured Logging]
LOG-ZIELE: [z.B. Konsole, Datei, ELK-Stack, CloudWatch, Datadog, Sentry]
ANWENDUNGSTYP: [z.B. API-Server, Webanwendung, Microservice]
CODE:
[Logging-Konfiguration, Log-Statements, Error-Handler und Request-Logging-Middleware einfuegen]
Diese Logging-Sicherheitsbelange auditieren:
1. **Sensible Daten in Logs**: Passwoerter, Tokens, Kreditkarten, personenbezogene Daten in der Log-Ausgabe?
2. **Request/Response-Logging**: Werden vollstaendige Request-Bodies geloggt?
3. **Fehlerdetails**: Stack-Traces mit Verbindungsstrings, Dateipfaden oder internen IPs?
4. **Log-Injection**: Kann Nutzereingabe gefaelschte Log-Eintraege erzeugen?
5. **Log-Zugriffskontrolle**: Wer kann Logs lesen? Sind sie at-rest verschluesselt?
6. **Aufbewahrungsrichtlinie**: Wie lange werden Logs aufbewahrt? Automatische Bereinigung?
7. **Audit-Trail**: Werden Sicherheitsereignisse korrekt geloggt?
8. **Korrelations-IDs**: Koennen Requests dienstuebergreifend verfolgt werden?
Fuer jeden Befund sichere Alternative bereitstellen.
Beispielausgabe
## Logging-Audit: 4 Befunde
### KRITISCH: Passwoerter im Request-Body geloggt
Zeile 45: logger.info('Login-Versuch', { body: req.body })
Loggt {"email":"user@example.com","password":"secret123"} im Klartext.
Loesung: logger.info('Login-Versuch', { email: req.body.email }) — Body nie roh loggen.
### HOCH: JWT-Tokens in Response-Logs
Zeile 78: logger.debug('Response', { data: res.body })
Logs enthalten JWT-Access-Tokens, die authentifizierten Zugriff gewaehren.
Loesung: Token-Felder schwärzen: { ...res.body, token: '[REDACTED]' }
Wann verwenden
Logging-Sicherheit beim initialen Anwendungs-Setup, nach dem Hinzufuegen neuer Log-Statements und vor Compliance-Audits auditieren. Unverzichtbar beim Einrichten von Log-Aggregationsdiensten oder zentralisiertem Logging.
Profi-Tipps
- Standardmaessig schwärzen — eine Logging-Middleware erstellen, die bekannte sensible Feldnamen automatisch maskiert, bevor ein Log-Statement ausgefuehrt wird.
- Niemals Request-Bodies roh loggen — nur die fuer das Debugging benoetigten Felder extrahieren.
- Strukturiertes Logging verwenden — JSON-strukturierte Logs verhindern Log-Injection-Angriffe und erleichtern feldbasierte Schwärzungsregeln.
- Sicherheitsereignisse explizit loggen — dedizierte Sicherheitsereignis-Logs fuer Login-Versuche, Berechtigungsaenderungen und Datenexporte mit standardisierten Feldern erstellen.