Der Fund beim Umzug

Beim Aufräumen der Dokumentation — verstreute Dateien in eine saubere Struktur überführen — lief zur Sicherheit ein Muster-Scan über die verschobenen Dateien. Das Ergebnis war unangenehm: In alten Anleitungen standen echte Zugangsdaten im Klartext. Datenbank-Passwörter, OIDC-Client-Secrets, ein API-Schlüssel — allesamt beim Aufsetzen einmal per Copy-&-Paste aus einer .env in eine „So habe ich das eingerichtet"-Notiz gewandert und dann committet.

Warum das passiert

Niemand schreibt bewusst Passwörter in die Doku. Es passiert schleichend: Beim Einrichten dokumentiert man die Schritte „wie sie waren" — inklusive der konkreten Werte, die man gerade in der Hand hatte. Die Notiz landet im Repo, wird nie wieder angefasst, und der Wert veraltet im Kopf, aber nicht in der Historie. Ein Pre-Commit-Hook, der bekannte Secret-Muster blockiert, hätte das früh verhindert — und tut es ab jetzt.

Der Denkfehler: Scrubben ≠ Entfernen

Der erste Reflex ist, die Werte durch Platzhalter zu ersetzen und zu committen. Das ist richtig und gehört gemacht — aber es beseitigt die Werte nur aus dem aktuellen Stand. In der Historie (und auf jedem geklonten Rechner, jedem Backup, jedem Spiegel-Remote) bleiben sie erhalten. Wer nur scrubbt und sich dann sicher fühlt, hat ein falsches Sicherheitsgefühl.

Aktueller Stand:   Platzhalter  ✔  (Scrubben)
Historie:          echter Wert  ✘  (bleibt bis Rotation/Rewrite)
Klone / Backups:   echter Wert  ✘

Rotation ist die eigentliche Behebung

Die einzige Maßnahme, die den exponierten Wert wirklich wertlos macht, ist die Rotation: einen neuen Wert erzeugen, auf beiden Seiten setzen — beim Aussteller und beim Nutzer — und den Dienst den neuen Wert übernehmen lassen. Danach ist es egal, wie oft der alte Wert noch irgendwo in einer Historie steht: Er öffnet nichts mehr.

Für ein OIDC-Client-Secret heißt das konkret: neuen Wert im Identity-Provider hinterlegen, denselben Wert in der Konfiguration des Dienstes setzen, den Provider-Cache leeren und den Dienst neu starten. Wichtig ist die Reihenfolge und Verifikation — beide Seiten müssen exakt denselben Wert tragen, sonst schlägt der Login fehl.

Wenn ein Schlüssel nicht rotierbar ist

Nicht jeder Schlüssel lässt sich einfach tauschen. Ein Verschlüsselungs-Schlüssel, mit dem ein Dienst seine gespeicherten Zugangsdaten chiffriert, ist so ein Fall: Ändert man ihn naiv, sind alle damit verschlüsselten Daten unlesbar. So etwas braucht einen bewussten Re-Key-Vorgang (mit dem alten Schlüssel entschlüsseln, mit dem neuen wieder verschlüsseln) und gehört nicht in eine schnelle Nacht-und-Nebel-Aktion, sondern in einen geplanten, getesteten Schritt.

Privat ≠ egal — aber ändert die Dringlichkeit

Ein wichtiger Faktor für die Priorisierung: Ist das Repository öffentlich oder privat? Ist es öffentlich, ist jeder exponierte Wert sofort ein Notfall. Ist es privat und einbenutzt, sinkt die Dringlichkeit deutlich — das Risiko beschränkt sich auf jemanden mit Zugriff auf das private Repo, einen Klon oder ein Backup. Das rechtfertigt keine Nachlässigkeit, aber es entscheidet, ob man einen aufwändigen History-Rewrite (mit Werkzeugen wie git filter-repo) überhaupt braucht — und der lohnt ohnehin erst nach der Rotation. Solange die alten Werte noch gültig sind, ist ein Rewrite verschenkte Mühe.

Checkliste

Der unangenehme Fund hatte am Ende etwas Gutes: Er hat einen blinden Fleck beleuchtet, einen Pre-Commit-Schutz etabliert und die riskantesten Werte tot gemacht. Aufräumen zahlt sich aus — manchmal anders als erwartet.