Wie verwaltet man Secrets sicher in der Cloud?

Secrets-Management ist der Ort, an dem gute Absichten auf die Realität treffen: Entwickler wollen, dass die App das Datenbankpasswort „einfach hat", und die einfachen Wege — eine .env im Repo, eine Konstante im Code, eine in ein Image eingebackene Umgebungsvariable — lecken alle. Das Interview will das sichere Muster und die Begründung.

Das richtige Muster

• Ein dedizierter Secrets-Speicher. Nutze Secrets Manager, SSM Parameter Store (SecureString) oder HashiCorp Vault. Sie halten Secrets aus der Versionsverwaltung heraus und geben dir Versionierung, Rotation und Zugriffsprotokolle.
• Verschlüsselung über KMS. Der Speicher verschlüsselt Secrets mit einem KMS-Schlüssel über Umschlagverschlüsselung — KMS hält den Hauptschlüssel und legt ihn nie offen; ein Datenschlüssel pro Secret erledigt die Hauptverschlüsselung. Schlüssel-Richtlinien steuern, wer überhaupt entschlüsseln darf.
• Zugriff über IAM-Rollen, nicht statische Schlüssel. Die Workload nimmt eine Rolle an und ruft das Secret zur Laufzeit ab. Kombiniert mit kurzlebigen Rollen-Anmeldedaten gibt es kein langlebiges Secret, das im Ruhezustand in der App gestohlen werden könnte.
• Rotation und Audit. Aktiviere automatische Rotation, sodass ein geleaktes Anmeldedatum eine kurze nutzbare Lebensdauer hat, und protokolliere jeden GetSecretValue-Aufruf, sodass Abrufe zuordenbar sind.

Warum die einfachen Wege scheitern

Eine eingecheckte .env lebt für immer im Git-Verlauf. Ein in einen Docker-Image-Layer eingebackenes Secret bleibt in diesem Layer, selbst wenn ein späteres RUN rm die Datei löscht — jeder, der das Image zieht, kann es extrahieren. Schlichte Umgebungsvariablen tauchen in Crash-Dumps, Kindprozessen und im Logging auf.

Worauf Interviewer achten

Einen verwalteten Speicher nennen, die KMS-Umschlagverschlüsselung und Schlüsselrichtlinien erklären, auf IAM-Rollen-Zugriff plus Rotation bestehen und wissen, warum Image-Layer und Git-Verlauf „später löschen" nutzlos machen.