Kernel-Vorfall: Secrets und PII vor dem Logging schützen

Ein Log soll erklären, warum eine Anmeldung scheitert. Dafür braucht es den Fehlercode und eine Request-ID. Den mitgesendeten API-Schlüssel braucht es nicht. Wer vollständige Requests oder Konfigurationsobjekte protokolliert, legt schnell eine zusätzliche Sammlung von Zugangsdaten an. Beim Logging-Anbieter kann daraus ein weiterer Zugangsweg werden.

Der aktuelle Kernel-Vorfall ist ein Anlass, diese Grenze im eigenen Code zu prüfen. Logging-Bibliotheken bieten dafür bereits brauchbare Mechanismen. Teams sollten sie nutzen und die Schutzwirkung an der tatsächlichen Ausgabe testen.

Was Kernel über den Vorfall veröffentlicht hat

Kernel meldete den Vorfall am 4. November. Laut Unternehmen verschaffte ein kompromittierter API-Schlüssel Zugang zum Logging-Anbieter. Dort lagen weitere API-Schlüssel und Secrets. Am 3. November griff derselbe Angreifer mit einem kompromittierten Hosting-Zugang auf vier Server zu. Drei führten Browser-Sitzungen aus. Kernel nennt 0,28 Prozent betroffene Kunden und berichtet über gesperrte Zugänge sowie rotierte Schlüssel. Originalbericht von Kernel.

Die folgenden Code-Beispiele sind Empfehlungen für eigene Anwendungen. Sie rekonstruieren keine Kernel-Implementierung.

Sensible Daten vor dem Log-Aufruf kennzeichnen

Eine Empfehlung im Entwicklerhandbuch verhindert nicht, dass ein neues Fehlerobjekt morgen wieder ein Token enthält. Macht die sichere Darstellung deshalb zu einer Eigenschaft des Wertes.

In Go kann ein eigener Typ das Interface slog.LogValuer implementieren. Der JSON-Handler löst den Wert dann über dessen Log-Darstellung auf. Ein kurzer Auszug:

type Sensitive string

func (Sensitive) LogValue() slog.Value {
    return slog.StringValue("[REDACTED]")
}

logger.Info("request rejected",
    "request_id", requestID,
    "token", Sensitive(token),
)

Der Eintrag enthält weiterhin das Ereignis und die Request-ID. Anstelle des Tokens erscheint [REDACTED].

Der Schutz gilt für diesen Logging-Pfad. Wer den Wert vorher mit string(secret) umwandelt und in eine Nachricht einsetzt, übergibt dem Logger gewöhnlichen Freitext. Die Kennzeichnung ist dann verloren. Auch beliebige verschachtelte Objekte werden durch einen solchen Typ nicht automatisch bereinigt.

Zentrale Filter ergänzen die Kennzeichnung

Ein gemeinsamer Logger kann bekannte sensible Felder vor der Ausgabe entfernen. Für Go bietet HandlerOptions.ReplaceAttr einen passenden Eingriffspunkt. In .NET lassen sich Daten klassifizieren und über eine aktivierte Redaction-Pipeline behandeln. Das Attribut allein aktiviert noch keine Filterung.

Für Node.js unterstützt Pino strukturierte Feldpfade. Diese Beispielkonfiguration entfernt die angegebenen Felder:

const logger = pino({
  redact: {
    paths: [
      "req.headers.authorization",
      "req.headers.cookie",
      "user.email",
      "apiKey"
    ],
    remove: true
  }
});

Das ist keine universelle Filterliste. Pino unterscheidet Groß- und Kleinschreibung. Ein Feld unter request.headers.authorization passt nicht zum konfigurierten Pfad req.headers.authorization. Ein Schlüssel mitten im Nachrichtentext wird durch diese Pfadregeln ebenfalls nicht erkannt.

Definiert deshalb erlaubte Diagnosefelder für eure Ereignisse. Ergänzt bekannte Ausschlüsse, statt vollständige Objekte zu protokollieren und auf eine spätere Volltextsuche nach Geheimnissen zu hoffen.

PII braucht eine eigene Entscheidung

Personenbezogene Daten, häufig als PII bezeichnet, sind eine weitere Kategorie. Eine E-Mail-Adresse ist kein API-Schlüssel. Für die Fehleranalyse ist ihre vollständige Ausgabe trotzdem oft unnötig.

Legt pro Ereignis fest, welche Angaben gebraucht werden. Das kann beispielsweise so aussehen:

Auch eine interne Kennung kann einer Person zugeordnet werden. Ersetzen ist deshalb nicht automatisch Anonymisieren. Zweck, Rechtsgrundlage, Zugriffsrechte und Aufbewahrung müssen für personenbezogene Log-Daten geklärt sein. Die DSGVO verlangt insbesondere Datenminimierung und datenschutzfreundliche Voreinstellungen.

Ein Filter für bekannte Feldnamen und eine zusätzliche PII-Erkennung können zusammenarbeiten. Die Erkennung ist eine weitere Kontrolle, keine Garantie für beliebige Freitexte, Dateianhänge oder neue Datenformate.

Wenn Originalwerte benötigt werden, gezielt verschlüsseln

Manche Untersuchungen brauchen begründet den ursprünglichen Wert. Dafür kann eine Logger-Erweiterung ausgewählte Felder vor der Ausgabe mit Vault Transit verschlüsseln. Der verschlüsselte Wert liegt anschließend im Log-Speicher. Das ist eine eigene Integration, kein automatischer Schutz jeder Logging-Bibliothek.

Für ein SIEM empfehlen wir getrennte Rollen:

Würde das SIEM beim Import alles wieder entschlüsseln, stünden die Rohdaten erneut in seinen Indizes und Exporten. Für Korrelation eignen sich je nach Zweck interne Referenzen oder gesonderte HMAC-Werte. Die Transit-API unterstützt HMAC, aber HMAC-Werte lassen sich nicht entschlüsseln. Schlüsselversion und Rotation müssen bei der Korrelation berücksichtigt werden. Auch diese Werte sind nicht automatisch anonym.

Plant Latenz und Ausfälle ein. Ein synchroner Vault-Aufruf pro Log-Ereignis schafft eine zusätzliche Abhängigkeit. Die Transit-API bietet Batch-Verarbeitung; wertet dabei auch Fehler einzelner Einträge aus. Legt fest, ob die Pipeline bei Fehlern geschützt puffert, sensible Felder auslässt oder den betroffenen Vorgang blockiert. Bei zwingend erforderlichen Auditdaten muss die Entscheidung deren Vollständigkeit berücksichtigen. Ein stiller Klartext-Fallback ist keine sichere Lösung.

Für unnötige Passwörter und Zugriffstoken bleibt Weglassen die richtige Entscheidung. Verschlüsselung ist für begründet benötigte Originaldaten gedacht und ersetzt weder Datenminimierung noch Aufbewahrungs- und Zugriffsvorgaben.

Middleware und Extensions müssen denselben Schutz verwenden

Ein Logging-Wrapper, Handler oder Processor ist sinnvoll, wenn Anwendungen dadurch dieselbe Klassifikation und dieselben Ausgaberegeln nutzen. Der Schutz muss greifen, bevor sensible Rohdaten in eine lokale Datei, die Standardausgabe oder einen externen Export gelangen. Eine spätere Maskierung in der Suchoberfläche lässt bereits gespeicherte Rohdaten unberührt.

Prüft dabei auch Framework-Middleware, Fehlerdienste und Plugins. Sie können Requests selbst erfassen oder einen eigenen Logger anlegen. Ein konkretes Beispiel steht in der Pino-Dokumentation zu Child-Loggern: Eigene redact-Optionen überschreiben die geerbten Regeln. Mit redact: [] lässt sich der geerbte Schutz entfernen.

Eine gemeinsame Logger-Factory hilft. Zusätzlich braucht es klare Vorgaben für Erweiterungen und Prüfungen, die abweichende Ausgabewege erkennen. Das gilt auch für Debug-Modi, die nur während einer Störung eingeschaltet werden.

Logs auf jeder Netzwerkstrecke sicher übertragen

Auch bereinigte Logs können Betriebsinformationen oder personenbezogene Daten enthalten. Eine unverschlüsselte Übertragung ermöglicht Angreifern mit Zugriff auf die Netzwerkstrecke das Mitlesen. Wir empfehlen deshalb authentisierte, verschlüsselte Verbindungen für jede Netzwerkstrecke der Logging-Pipeline:

• Nutzt HTTPS für HTTP-basierte Log-Exporte und die Vault-API. Bevorzugt TLS 1.3; verbleibendes TLS 1.2 braucht eine Konfiguration nach dem jeweils anwendbaren aktuellen Kryptoprofil. Berücksichtigt die IETF-TLS-Empfehlungen einschließlich ihrer Aktualisierungen.
• Prüft Zertifikatskette und Identität des Zielsystems. Eine deaktivierte Zertifikats- oder Hostnamenprüfung untergräbt die Absicherung des Empfängers.
• Verwendet für Syslog einen gesicherten Transport, etwa Syslog über TLS nach RFC 5425, unter Beachtung der Krypto-Aktualisierung RFC 9662. Verhindert einen automatischen Rückfall auf unverschlüsseltes UDP oder TCP.
• Prüft Anwendung, Collector, Relays und SIEM einzeln. Nach einer TLS-Terminierung muss auch die nächste Netzwerkstrecke geschützt sein. mTLS ist eine Möglichkeit, zusätzlich den sendenden Dienst per Zertifikat zu authentisieren.

Transportverschlüsselung schützt die Verbindung. Die Regeln für Log-Inhalte, Zugriffsrechte und Speicherung bleiben zusätzlich nötig.

Prüft die Ausgabe mit künstlichen Testdaten

Verwendet für die Abnahme eindeutig erkennbare, künstliche Werte. Nutzt dabei keine echten Zugangsdaten oder Kundendaten.

1. Gebt einen Testschlüssel und eine synthetische E-Mail-Adresse als strukturierte Werte ein.
2. Wiederholt den Test über Fehlertexte, HTTP-Header, URLs und Bodies, die eure Anwendung tatsächlich verarbeitet.
3. Prüft jedes endgültige Ausgabeziel, einschließlich Konsole, Dateien und externer Fehler- oder Logging-Dienste.
4. Wiederholt die Prüfung mit Child-Loggern, neuer Middleware und aktivem Debug-Modus.
5. Prüft auch den verbleibenden Nutzen. Ereignis, Fehlercode und sichere Korrelationsdaten müssen die Diagnose weiterhin ermöglichen.
6. Testet Verbindungen zu nicht vertrauenswürdigen oder falsch benannten Gegenstellen. Sie müssen abgelehnt werden; ein Zertifikatsfehler darf keinen unverschlüsselten Ersatztransport auslösen.

Damit lässt sich ein Fehler reproduzierbar feststellen. Die bloße Existenz einer Filterkonfiguration belegt ihre Wirkung noch nicht. Die OWASP Logging Cheat Sheet behandelt sowohl auszuschließende Daten als auch die Prüfung und Absicherung der Log-Verarbeitung.

Bereits protokollierte Secrets brauchen eine Reaktion

Ein neuer Filter entfernt keine alten Kopien. Falls nutzbare Zugangsdaten in Logs gefunden werden, müssen die zuständigen Teams sie sperren oder rotieren, mögliche Zugriffe untersuchen und weitere Kopien einbeziehen. Dazu können Exporte, Tickets und Sicherungen gehören. Beweissicherung und Bereinigung müssen abgestimmt erfolgen.

Für personenbezogene Daten gehört zusätzlich eine Bewertung des Vorfalls durch die zuständigen Datenschutz- und Sicherheitsteams dazu. Eine pauschale Aussage über Meldepflichten lässt sich aus dem Fund allein nicht ableiten. Unser Incident Report hilft, Befunde, Auswirkungen und Entscheidungen strukturiert festzuhalten.

Wer schließt die Lücke und wer prüft das Ergebnis?

Eine Redaction-Regel ist erst umgesetzt, wenn sie im betroffenen Dienst wirksam ist. Ordnet den Befund einem Asset und einem Verantwortlichen zu. Haltet fest, welche Ausgabewege geprüft wurden und woran die Wirksamkeit erkennbar ist.

Bei einem externen Log-Dienst gehört dessen Zugang mit in die Lieferantenbewertung.

In Kopexa könnt ihr den Befund mit Risiken, Maßnahmen und Prüfnachweisen verbinden. Die technische Filterung bleibt in eurer Anwendung und Logging-Infrastruktur.