Geheimnisse ausserhalb des Repositorys verwalten

Ziel

Zugangsdaten aus Orten heraushalten, die kopiert, geteilt oder indexiert werden, und den Ersatz eines kompromittierten Zugangsdatums zu einem Routinevorgang machen.

Voraussetzungen

Ein Ablageort für Geheimnisse mit Zugriffskontrolle (ein Secrets-Manager oder mindestens Umgebungsdateien mit eingeschränkten Rechten auf dem Host) sowie ein Deployment-Weg, der sie einspielt.

Schritte

1. Geheimnisse inventarisieren: Datenbankpasswörter, API-Schlüssel, Signaturschlüssel, Tokens. Jedem eine verantwortliche Stelle und ein Rotationsintervall geben.
2. Geheimnisse aus der Repository-Historie entfernen, falls vorhanden, und danach rotieren; ein entfernter Commit ist kein widerrufenes Zugangsdatum.
3. Geheimnisse zur Laufzeit über die Umgebung oder eingebundene Dateien einspielen, nach der Twelve-Factor-Trennung von Konfiguration und Code; eine Beispieldatei mit leeren Werten im Repository belassen.
4. Zugangsdaten eng abgrenzen: je Dienst und Umgebung ein eigenes, mit minimalen Rechten.
5. Geheimnisse nie protokollieren; Log-Einträge aus zugelassenen Feldern aufbauen und prüfen, dass Fehlerbehandlungen keine Request-Header oder Umgebung ausgeben.
6. Rotation einüben, damit sie ein dokumentiertes, geprüftes Verfahren ist statt ein Notfall.

Erwartetes Ergebnis

Ein frischer Klon enthält kein Zugangsdatum; ein geleaktes Log oder Backup gibt keines preis; die Rotation läuft ohne Ausfallzeit durch.

Grenzen und Prüfbasis

Umgebungsvariablen sind für den Prozess und seine Kindprozesse sichtbar und können von Absturzberichten erfasst werden; Dateien mit strikten Rechten oder ein Manager sind stärker. Secret-Scanning in der CI fängt Unfälle ab, keine Designfehler. Die Anleitung folgt den zitierten Quellen.