Jedes Team kommt irgendwann an den Punkt, an dem Zugangsdaten an zu vielen Orten liegen: eine .env auf jedem Laptop, eine angepinnte Nachricht in Slack, eine Tabelle namens „Logins“, eine CI-Variable, die jemand vor zwei Jahren gesetzt hat. Ein Cloud-Secret-Manager ist dafür da, all das an einem Ort zusammenzuführen, der verschlüsselt, zugriffsgeschützt und protokolliert ist.
Dieser Leitfaden erklärt, was ein Cloud-Secret-Manager tut, wie Sie zwischen den wichtigsten Optionen wählen, wie Sie ihn ohne lange Migration einführen und welche eine Aufgabe er nicht übernimmt: ein Geheimnis zu einem Menschen zu bringen, der nicht in Ihrem Cloud-Konto ist.
Was ein Cloud-Secret-Manager tut
Ein Secret-Manager speichert vertrauliche Werte und gibt sie auf Anfrage an berechtigte Identitäten heraus. Die Kernfunktionen sind bei allen Anbietern gleich:
- Verschlüsselte Speicherung im Ruhezustand, mit Schlüsseln im Key-Management-Dienst des Anbieters, und TLS bei der Übertragung.
- Identitätsbasierter Zugriff: Für jedes Geheimnis legt eine Richtlinie fest, welche Benutzer, Rollen oder Workloads es lesen, schreiben oder rotieren dürfen. Eine Anwendung authentifiziert sich mit ihrer eigenen Identität, nicht mit einem Master-Passwort.
- Audit-Logs für jedes Lesen, Schreiben und Rotieren, mit Angaben dazu, wer was wann getan hat.
- Versionierung und Rotation: Ein neuer Wert lässt sich vorab bereitstellen, dann werden die Anwendungen umgestellt und die alte Version stillgelegt. Viele Manager rotieren Datenbank-Zugangsdaten automatisch.
- Abruf zur Laufzeit: Die Anwendung holt das Geheimnis beim Start oder bei Bedarf ab, der Wert landet also nie in Code, Images oder Konfigurationsdateien.
Ein Geheimnis ist alles, was Zugriff gewährt. Konfiguration, die nur Verhalten beschreibt, etwa eine Portnummer oder ein Feature-Flag, gehört in die normale Konfiguration. Wer beides mischt, macht den Secret-Speicher unübersichtlich und den Konfigurationsspeicher gefährlich.
Wie Sie einen auswählen
Meist entscheidet, wo Ihre Workloads laufen und in wie vielen Clouds Sie sind.
| Option | Passt am besten | Darauf achten |
|---|---|---|
| AWS Secrets Manager / Parameter Store | Workloads, die schon auf AWS laufen, überall IAM-Identitäten | Preis pro Geheimnis beim Secrets Manager; Parameter Store ist für einfache Werte günstiger |
| Google Secret Manager | GCP-Projekte, Workloads auf Cloud Run und GKE | Optionen für die regionale Replikation |
| Azure Key Vault | Azure-Workloads, Bedarf an Zertifikatsverwaltung | Getrennte Vaults pro Umgebung, damit die Richtlinien einfach bleiben |
| HashiCorp Vault | Multi-Cloud oder On-Premises, dynamische kurzlebige Zugangsdaten | Eigener Betrieb, außer Sie nutzen die gehostete Version |
| Doppler, Infisical, 1Password Secrets Automation | Kleine Teams, die entwicklerfreundlich auf viele Plattformen synchronisieren wollen | Ein weiterer Anbieter in der Vertrauenskette |
Vier Fragen entscheiden die meisten Fälle. Lässt er sich ohne selbst gebauten Klebecode in Ihre Deployment-Tools und Laufzeitumgebung einbinden? Können sich Workloads mit der Identität authentifizieren, die sie bereits haben? Rotiert er die Arten von Zugangsdaten, die Sie tatsächlich haben? Und landen seine Audit-Logs dort, wo Ihr Sicherheitsteam ohnehin hinschaut? Preise, Regionen und Compliance-Nachweise kommen erst nach diesen vier.
Einführung ohne Sechs-Monats-Projekt
- Bestand aufnehmen und Verantwortliche festlegen. Listen Sie jedes Geheimnis auf: wo es liegt, was es nutzt und wer dafür verantwortlich ist. Die verantwortliche Person legt die Rotationsrichtlinie und die Zugriffsliste fest.
- Zuerst die Identitäten einrichten. Legen Sie die Rollen oder Service-Accounts für jeden Workload und jede Umgebung an, bevor Sie auch nur einen Wert verschieben. Um Zugriffsrichtlinien nach dem Muster „dieser Dienst, diese Umgebung, nur lesen“ geht es ja gerade.
- Nach Risiko migrieren. Zuerst Passwörter für Produktionsdatenbanken und Zahlungsschlüssel, dann API-Schlüssel von Drittanbietern, dann alles andere. Entfernen Sie jeden Wert beim Umzug aus Code, CI-Variablen und Konfigurationsdateien, und erneuern Sie ihn dabei, denn der alte Wert wurde längst herumkopiert.
- Ändern, wie Anwendungen Geheimnisse lesen. Ersetzen Sie fest eingetragene Werte und Umgebungsdateien durch einen Aufruf des SDK des Managers beim Start, oder injizieren Sie sie über die native Integration der Plattform.
- Rotation einschalten für alles, was der Manager selbst rotieren kann, und für den Rest eine Rotationsfunktion oder ein Runbook schreiben.
- Bei Ungewöhnlichem alarmieren. Ein Lesezugriff von einer neuen Identität, ein sprunghafter Anstieg der Lesezugriffe oder ein Zugriff aus einer Region, in der Sie nichts betreiben, ist einen Alarm wert.
Die typischen Fehler sind vorhersehbar: alte Kopien nach der Migration liegen lassen, einem Workload Lesezugriff auf den gesamten Speicher geben statt nur auf seine eigenen Geheimnisse, und den abgerufenen Wert in die Anwendungslogs schreiben.
Die Lücke, die ein Secret-Manager nicht schließt
Ein Secret-Manager ist für Maschinen gebaut und für Menschen innerhalb Ihres Identitätssystems. Er ist nicht für den Moment gebaut, in dem Zugangsdaten jemanden außerhalb erreichen müssen: einen externen Dienstleister, der vorübergehend ein Datenbankpasswort braucht, einen Kunden, der seinen ersten Admin-Zugang bekommt, einen Techniker eines Anbieters, der für einen Nachmittag ein Token braucht, eine neue Mitarbeiterin am ersten Tag, bevor ihr SSO-Konto existiert.
Diese Übergaben finden trotzdem statt. Ohne einen vorgesehenen Weg landen sie in E-Mail und Chat, also genau dort, wo Secret-Manager die Zugangsdaten eigentlich herausholen sollten. Der vorgesehene Weg ist ein Einmal-Link. Der Wert wird in Ihrem Browser verschlüsselt, bevor er gespeichert wird, die Nachricht enthält nur einen Link, die gespeicherte Kopie wird beim ersten Öffnen des Links vernichtet, und der Link läuft nach einer festen Zeit ab, wenn ihn niemand öffnet.
Das Muster, das funktioniert: Der Secret-Manager ist das führende System, und der Einmal-Link ist der Zustellweg, wenn ein Mensch außerhalb des Systems einen Wert einmal braucht. Erzeugen Sie die Zugangsdaten, speichern Sie sie im Manager, schicken Sie sie der Person über einen Einmal-Link und erneuern Sie sie, wenn ihr Zugang endet. Secret-Links oder Passwortmanager überträgt dieselbe Überlegung auf den Passwortmanager des Teams, und der Leitfaden zur Übergabe von Zugangsdaten zwischen Teams beschreibt den Ablauf im Alltag.
Eine kurze Checkliste
- Jedes Geheimnis hat eine verantwortliche Person, eine Zugriffsrichtlinie und eine Rotationsregel.
- Workloads authentifizieren sich mit ihrer eigenen Identität, nie mit einem geteilten Schlüssel.
- Nach der Migration steht kein Geheimnis mehr in Code, Images, CI-Variablen oder im Chat.
- Lesezugriffe werden dort protokolliert, wo tatsächlich jemand hinschaut.
- Menschen außerhalb des Identitätssystems bekommen Geheimnisse über einen Einmal-Link, nicht per Nachricht.
Setzen Sie diese fünf Punkte um, dann ist der Secret-Manager kein bloß gekauftes Produkt mehr. Er ist der Grund, warum keine Zugangsdaten mehr durchsickern.