Einleitung#
Seitdem ich, vor langer Zeit, mit dem Konzept Secrets-Manager in Kontakt gekommen bin, hatte ich ehrlich gesagt immer nur eine vage Vorstellung davon, was für einen Vorteil diese eigentlich bieten, wo doch das System, welches ein Secret abfragen darf, sich dafür bereits authentifizieren muss. Wie genau autorisiert sich also z.B. ein Webserver gegenüber einem Secrets-Manager, um dort Datenbank-Zugangsdaten abzurufen, und warum ist das besser, als diesem System mit derselben Authentifikation direkt auf die Datenbank Zugriff zu gewähren? In diesem Artikel möchte ich dieses Thema etwas beleuchten.
Wozu Secrets-Manager im Rahmen der Informationssicherheit dienen#
In einem Informationssicherheitskontext – egal ob unter ISO 27001, NIS2 oder anderen Standards – stehen drei Schutzziele im Mittelpunkt:
Vertraulichkeit
Integrität
Verfügbarkeit
Zudem muss dieser Schutz nachweisbar sein und Verletzungen erkannt werden können.
Secrets-Manager adressieren vor allem die ersten beiden Ziele. Statische Passwörter in Konfigurationsdateien oder Git-Repositories untergraben die Vertraulichkeit sofort, und ihre Verbreitung macht Rotation nahezu unmöglich – was wiederum die Integrität schwächt.
Ein Secrets-Manager stellt sicher, dass:
Secrets zentralisiert statt verteilt gespeichert werden.
Secrets verschlüsselt abgelegt werden.
Zugriff nur über klar definierte Berechtigungen erfolgt.
Auditierbarkeit gegeben ist (wer hat wann welches Secret abgerufen?).
Secrets rotierbar sind, ohne Deployments auszulösen.
Maschinen nicht mit statischen Passwörtern bootstrappen müssen.
Aus Sicht der Informationssicherheit reduziert ein Secrets-Manager somit:
das Risiko von Leaks,
die Angriffsfläche durch Kopien,
und den Missbrauch unkontrollierter Zugangsdaten.
Für welche Arten von Accounts ein Secrets-Manager verwendet wird#
Besonders wichtig ist für mich die Unterscheidung der Account-Typen:
1. Menschliche Accounts#
Für Benutzerkonten eignet sich ein Secrets-Manager nur indirekt. Hauptsächlich, um:
API-Tokens abzulegen,
SSH-Schlüssel sicher zu verwalten,
oder hochprivilegierte „Break-Glass-Zugänge“ zu schützen.
Für Passwörter menschlicher Benutzer ist ein Passwortmanager geeigneter.
2. Maschinenaccounts#
Der eigentliche Kern ist die Maschinen-zu-Maschine-Kommunikation:
Datenbank-Benutzerkonten
API-Accounts für Microservices
TLS-Zertifikate und private Schlüssel
Service-Tokens
Zugangsdaten für externe Systeme
interne Systemidentitäten für Automatisierungsprozesse
Maschinen benötigen Secrets, um automatisch starten, skalieren oder sich verbinden zu können – und genau dafür sind Secret Stores optimiert.
Warum ein Server überhaupt an Secrets kommt – das Bootstrapping-Problem#
Einer der größten Aha-Momente war:
Ein Server kann niemals „gar nichts“ besitzen. Er braucht eine grundlegende Identität.
Das führt zum sogenannten First-Secret-Problem: Wie weist sich der Server beim Secrets-Manager aus?
Dafür existieren verschiedene Mechanismen, die nicht auf kopierbaren Passwörtern basieren:
hardwaregebundene Schlüssel (z. B. TPM),
kontextsensitive Identitäten (nur gültig auf bestimmter Hardware/VM),
einmalige, kurzlebige Tokens,
Cloud-basierte Instanzidentitäten,
Zertifikate mit starker Bindung.
Damit wird das Grundproblem entschärft, ohne es vollständig zu eliminieren. Aber der Effekt ist entscheidend: Maschinen speichern kein dauerhaftes Passwort, sondern eine nicht klonbare Identität.
Warum ein Administrator dennoch Secrets sehen kann – und warum das unvermeidbar ist#
Ein wichtiger Punkt war die Erkenntnis:
Ein Administrator mit Root-Rechten auf einem Server kann die Secrets sehen, die dieser Server im laufenden Betrieb verwendet.
Aber:
Er kann nicht automatisch andere Secrets abfragen.
Alle Zugriffe sind auditierbar.
Die Identitäten sind nicht kopierbar.
Secrets können kontextgebunden sein (nur auf dieser Maschine gültig).
Secrets sind rotierbar und oft kurzlebig.
Ein Secrets-Manager kann also keinen Insider vollständig ausschließen, aber er kann Missbrauch einschränken, sichtbar machen und zeitlich begrenzen.
Advanced-Konzepte, die ich verstanden habe#
Kontextgebundene Secrets#
Ein Secret ist nur dann gültig, wenn bestimmte Bedingungen erfüllt sind:
richtige Hardware,
richtige VM oder Container,
richtige Netzwerkzone,
richtige Softwareintegrität (z. B. gemessener Hash).
Das macht ein kopiertes Secret wertlos.
Ephemere Secrets#
Hier bekommen Maschinen Zugangsdaten, die nur Sekunden oder Minuten gültig sind.
Missbrauch lohnt sich nicht, weil die Daten praktisch sofort ablaufen.
Secrets müssen nicht mehr ausgeliefert werden#
Statt Secrets zu geben, kann der Manager Operationen durchführen:
Signaturen,
Entschlüsselungen,
Aufbau einer Session.
Die Maschine erhält nur das Ergebnis, nie das Secret selbst.
Trusted Execution Environments (TEE)#
Secrets laufen nur innerhalb isolierter Enklaven:
SGX, SEV, ARM Realm, Secure Enclave,
Micro-VMs für isolierte Kryptographie.
Selbst Root kommt nicht an die Klartexte.
Grenzen des Systems#
Ich habe auch gelernt, dass Secrets Management keine Magie ist:
Ein kompromittierter Server kann seine Secrets im RAM preisgeben.
Ein Root-Admin kann laufende Prozesse manipulieren.
Perfekter Schutz ist unmöglich.
Aber: Die Angriffsfläche und der mögliche Schaden werden massiv reduziert.
Schlussgedanke#
Secrets Management ist ein zentraler Baustein moderner Informationssicherheit. Nicht nur, um Passwörter zentral zu halten, sondern um das gesamte System kontrollierbarer, auditierbarer und widerstandsfähiger zu machen.
Für mich persönlich war der Schlüssel:
Nicht verhindern, dass ein System seine eigenen Secrets sieht – sondern verhindern, dass es mehr sieht als nötig.
Und: alles, was passiert, muss nachvollziehbar sein.
Dieser Artikel ist Teil meines eigenen Lernprozesses. Er soll dokumentieren, wie ich die theoretische Seite des Secrets-Managements verstanden habe – ohne Anspruch auf Vollständigkeit oder Perfektion.
Warum man die Maschinen-Identität nicht direkt als Zugangsdaten verwenden sollte#
Während meiner Beschäftigung mit Secrets-Management kam mir irgendwann die Frage, warum man überhaupt separate Zugangsdaten für Dienste verwaltet. Könnte man nicht einfach die Maschinen-Identität – also den hardwaregebundenen Schlüssel oder das Host-Zertifikat – direkt verwenden, um auf Zielsysteme wie Datenbanken zuzugreifen? Immerhin muss sich der Server sowieso beim Secrets-Manager authentifizieren. Warum nicht diesen Schritt überspringen?
Was ich gelernt habe: Das würde mehr Probleme schaffen, als es löst. Eine Maschinen-Identität gehört immer zum physischen oder virtuellen Host, nicht zur Anwendung. Datenbanken oder APIs sollen jedoch nicht erkennen, welche Maschine sie anspricht, sondern welcher Dienst oder welches Deployment dahintersteht. Wenn man dem Host selbst weitreichende Berechtigungen gibt, verlieren Microservices ihre Trennung, Container-Isolation wird ausgehebelt, und jeder Exploit eines einzelnen Prozesses hätte weitreichende Folgen. Außerdem wären solche Berechtigungen kaum rotierbar, während Secrets bewusst kurzlebig und leicht austauschbar sind. Maschinen-Identitäten sind langlebig, schwer zu erneuern und repräsentieren eine völlig andere Ebene (Hardware statt Logik).
Der Secrets-Manager dient genau dazu, diese Ebenen zu entkoppeln: Der Host beweist lediglich, dass er eine vertrauenswürdige Umgebung ist. Die Anwendung bekommt dann ein spezifisches Secret, das ihre logische Identität darstellt und das unabhängig vom Host rotiert, entzogen oder geändert werden kann. Dadurch bleibt das System granular, auditierbar und sicher – und genau dafür ist Secrets Management überhaupt erst notwendig.