Dein Team speichert DB-Passwörter als Klartext-Umgebungsvariablen in der Deployment-Config, die ins Repo eingecheckt ist. Besserer Ansatz?
Kurzantwort
Geheimnisse gehören in einen verwalteten Speicher mit Zugriffskontrolle, Audit und Rotation, zur Laufzeit injiziert – niemals in die Versionskontrolle eingecheckt. Nutze einen Secrets Manager (AWS Secrets Manager, HashiCorp Vault) und entferne die eingecheckten Werte aus der Historie, dann rotiere sie, weil sie als kompromittiert gelten müssen. Base64 ist Kodierung, kein Schutz – jeder kann es dekodieren. Ein privates Repo verteilt das Geheimnis weiterhin an alle mit Clone-Zugriff sowie an CI-Systeme und Forks. Es ins Binary zu kompilieren versteckt nur ein Geheimnis, das weiterhin trivial extrahierbar ist.
Ein eingechecktes Geheimnis ist einer der häufigsten Vorfälle der realen Welt, und diese Frage prüft, ob du den Unterschied zwischen einem Geheimnis verstecken und es schützen kennst. Die einzig richtige Antwort entfernt das Geheimnis vollständig aus der Versionskontrolle und verwaltet es ordentlich.
Warum ein Secrets Manager die Antwort ist
Ein Secrets Manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) liefert dir die drei Dinge, die Versionskontrolle nicht kann: Zugriffskontrolle (nur die Rolle der Workload kann das Geheimnis lesen), Audit (jeder Abruf wird protokolliert) und Rotation (das Passwort lässt sich automatisch und auf Abruf ändern). Die Anwendung holt das Geheimnis zur Laufzeit – über ihre IAM-Rolle oder einen Sidecar –, sodass nie etwas Sensibles eingecheckt wird. Entscheidend: Weil das Passwort bereits im Repo lag, musst du es als kompromittiert behandeln: aus der Historie entfernen und rotieren.
Warum die Distraktoren scheitern
- Base64-kodieren. Base64 ist Kodierung, keine Verschlüsselung. Jeder kann es mit einem Befehl umkehren. Das Geheimnis ist genauso exponiert, jetzt mit falschem Sicherheitsgefühl.
- In ein privates Repo verschieben. Ein privates Repo gibt das Geheimnis weiterhin an jeden Entwickler mit Clone-Zugriff, jeden CI/CD-Runner, jeden Fork und lokalen Klon und an jeden, der später Lesezugriff erhält. „Privat“ ist nicht „geheim“, und die Anmeldung bleibt für immer in der Git-Historie.
- Ins Binary einkompilieren. Strings in einem kompilierten Binary lassen sich trivial mit
stringsoder einem Disassembler extrahieren. Du hast Build-Reibung hinzugefügt, ohne Schutz hinzuzufügen, und kannst weiterhin nicht ohne Redeploy rotieren.
Das Historie-Problem
Die Datei aus HEAD zu löschen reicht nicht: Das Geheimnis bleibt in der Git-Historie und in jedem Klon. Genau deshalb ist Rotation Pflicht – gehe davon aus, dass es geleakt ist, und mache es ungültig.
Worauf Interviewer achten
Einen verwalteten Secrets-Speicher mit Laufzeit-Injektion zu nennen, auf Rotation, weil das Geheimnis bereits kompromittiert ist, zu bestehen und herauszustellen, dass base64 und private Repos kein Schutz sind. Starke Kandidaten ergänzen eine Pre-Commit-/Secret-Scanning-Leitplanke, damit es nicht wieder passiert.
Wahrscheinliche Anschlussfragen
- Das Geheimnis stand in der Git-Historie – warum reicht es nicht, die Datei aus HEAD zu löschen?
- Wie erreicht die Laufzeit-Injektion aus einem Secrets Manager die App konkret ohne eingechecktes Geheimnis?
- Warum musst du das Passwort rotieren, selbst nachdem du es aus dem Repo entfernt hast?