Skip to content
NeuralSkills
Sicherheit

Logging-Sicherheits-Auditor

Sicherstellen, dass Logs keine sensiblen Daten exponieren — PII-Filterung, Credential-Maskierung, Log-Injection-Praevention und Audit-Trail-Design.

Einsteiger Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

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.