Zugangsdaten aus Protokollen heraushalten

Protokolle helfen bei Fehlern und Sicherheitsvorfällen. Speichern sie Passwörter, API-Schlüssel oder Sitzungstoken, entsteht eine neue Angriffsfläche. Deshalb müssen die Daten vor dem Schreiben eines Ereignisses gefiltert werden.

Typische Leckstellen finden

Prüfen Sie Anmelde- und Integrationsabläufe, fehlgeschlagene API-Aufrufe, Webhooks und Fehlerbehandlung. Zugangsdaten können in Anfragekörpern, Headern, URL-Parametern oder Ausnahmetexten stehen. In vielen No-Code-Werkzeugen erscheinen bei fehlgeschlagenen Schritten standardmäßig Ein- und Ausgaben. Prüfen Sie, was davon in der Ausführungshistorie für andere Nutzer sichtbar bleibt.

Passwörter, Zugangstoken, Verschlüsselungsschlüssel und andere Geheimnisse sollten nicht in Protokollen gespeichert werden. Entfernen oder maskieren Sie diese Werte vor der Speicherung. Ein späteres Löschen im Dashboard genügt nicht, wenn die Rohdaten bereits weitergeleitet oder gesichert wurden.

Genug Kontext ohne Geheimnis erhalten

Ein brauchbares Ereignis enthält Zeitpunkt, Workflow oder Aktion, Ergebnis, Fehlerklasse und eine geeignete Vorgangskennung. Es braucht normalerweise keinen vollständigen Anfragekörper und keinen Tokenwert. Nutzen Sie eine erlaubte Feldliste für technische Protokolle und maskieren Sie bekannte geheime Felder auch in Fehlermeldungen. Vermeiden Sie sensible Werte in URLs, weil diese in mehreren Systemen protokolliert werden können.

Testen Sie mit harmlosen Test-Zugangsdaten: Lösen Sie einen Fehler aus und suchen Sie anschließend in Ausführungshistorie, Exporten, Alarmen und zentralen Logs nach dem Testwert. Wenn er auftaucht, korrigieren Sie die Protokollregel und prüfen Sie bereits gespeicherte Kopien. Verwenden Sie für diesen Test keine echten Schlüssel.

Zugriff und Rotation mitdenken

Beschränken Sie, wer Protokolle lesen und exportieren darf. Ein Log mit maskierten Werten kann immer noch personenbezogene oder geschäftliche Informationen enthalten. Falls ein echter Schlüssel bereits protokolliert wurde, behandeln Sie ihn als möglicherweise offengelegt: zuständige Sicherheitsstelle informieren, Schlüssel nach dem vorgesehenen Verfahren ersetzen und die Leckstelle schließen. Dokumentieren Sie die Ursache, damit derselbe Fehler nicht beim nächsten Workflow wiederkehrt.

Zugriffs- und Rotationspraktiken nach best Practices