Was ist Secrets Management?
Secrets Management ist der organisatorische und technische Prozess, mit dem technische Geheimnisse kontrolliert erzeugt, gespeichert, bereitgestellt, rotiert und widerrufen werden.
Technische Einordnung: Zu den verwalteten Secrets können Passwörter, API-Schlüssel, Tokens und kryptografische Schlüssel gehören. Entscheidend ist nicht ein bestimmtes Vault-Produkt, sondern der kontrollierte Lebenszyklus einschließlich sicherer Auslieferung. Diese allgemeine Einordnung stützt sich auf NIST SP 800-204C, insbesondere das Abstract sowie die Abschnitte 2 und 3.
Für wen ist Secrets Management relevant?
Relevant ist der Prozess für Organisationen, die Anwendungen, Infrastruktur, CI/CD-Pipelines oder Dienst-zu-Dienst-Kommunikation mit technischen Geheimnissen entwickeln oder betreiben. Der Auslöser liegt vor, sobald Menschen, Anwendungen, Workloads oder Dienste ein Secret zur Authentisierung, Autorisierung oder zum Schutz von Daten benötigen. Der konkrete Umfang richtet sich nach Secret-Typen, Identitäten und Bereitstellungswegen; er ist nicht an ein bestimmtes Produkt gebunden. Grundlage dieser technischen Einordnung sind die Abschnitte 1, 3 und 4 von NIST SP 800-204C.
Wann sollte ein Secret kontrolliert bereitgestellt werden?
Sobald ein Secret einer Anwendung, Pipeline oder einem Workload bereitgestellt werden muss, sollte es nicht im Quellcode oder in unkontrollierten Konfigurationen abgelegt werden. Der Abruf setzt voraus, dass der Workload beziehungsweise Dienst authentisiert und für das konkrete Secret autorisiert ist. Das Modalwort ist bewusst „sollte“: NIST und CISA formulieren hier technische Empfehlungen, keine universelle Verpflichtung.
Behördenempfehlung: CISA empfiehlt für Produkte und Entwicklungsprozesse, Secrets aus Quellcode fernzuhalten, Anwendungen und CI/CD-Pipelines einen sicheren Abruf über einen dafür vorgesehenen Manager zu ermöglichen und ergänzend nach enthaltenen Secrets oder Zugangsdaten zu scannen. Ein Scan ist eine zusätzliche Kontrolle; er ersetzt den authentisierten und autorisierten Abruf nicht.
Welche Kontrollen gehören zum Lebenszyklus?
Die technische Gesamtbetrachtung umfasst kontrollierte Erzeugung und Ablage, authentisierte und für das einzelne Secret autorisierte Abrufe, Schutz bei Übertragung und Speicherung, Rotation, Widerruf, Überwachung und Protokollierung. Kurzlebige oder dynamisch erzeugte Credentials können die Folgen kompromittierter langlebiger Werte begrenzen, sofern das Zielsystem sie unterstützt und Workload-Identität, Berechtigungsmodell sowie Abrufweg belastbar ausgestaltet sind. NIST SP 800-204C beschreibt diese Bedingungen in den Abschnitten 3.2, 4 und 5.
Welche Grenzen hat ein Secrets-Manager?
Ein zentraler Secrets-Manager beseitigt das Risiko nicht. Ein berechtigter Workload muss ein Secret zur Nutzung verarbeiten können. Wird dieser Dienst kompromittiert, kann sein Abrufrecht missbraucht werden. Für Cloud-Umgebungen beschreibt CISA außerdem, dass ausreichende Cloud-Berechtigungen einen Abruf beim Secrets-Manager ermöglichen können. Deshalb bleiben minimale Abrufrechte, Schutz der abrufenden Dienste, Rotation, Widerruf und Protokollierung erforderlich.
Auch ist nicht jeder Konfigurationswert ein Secret. Öffentliche, nicht schutzbedürftige Werte werden nicht allein durch ihren Speicherort zu Secrets. Die Einstufung hängt vom Verwendungszweck und davon ab, welche Sicherheitsfolgen eine Offenlegung oder Veränderung hätte.
Welche Fristen oder Schwellenwerte gelten für Rotation und Widerruf?
Die herangezogenen allgemeinen technischen Leitlinien nennen keine einheitliche Frist oder numerische Schwelle für Rotation, Ablauf oder Widerruf sämtlicher Secrets. Regeln sind nach Secret-Typ, Risiko, Lebenszyklus und unterstütztem Zielsystem festzulegen. Produktspezifische, vertragliche oder anderweitig anwendbare Vorgaben können davon unabhängig konkrete Parameter bestimmen.
Für kompromittierte kryptografische Schlüssel gilt ein engeres Spezialregime: NIST SP 800-57 Part 1 Revision 5 behandelt kompromittierte symmetrische geheime und asymmetrische private Schlüssel im Zusammenhang mit dem zerstörten Zustand. Die zitierte Passage nennt dafür keine bezifferte Frist. Diese Schlüsselbehandlung darf nicht pauschal auf Passwörter, Tokens oder API-Schlüssel übertragen werden.
Wie unterscheidet sich Secrets Management von Verschlüsselung und Key Management?
Verschlüsselung schützt gespeicherte oder übertragene Werte, bildet aber nicht deren vollständigen Lebenszyklus und kontrollierte Auslieferung ab. Secrets Management ist außerdem weiter als kryptografisches Key Management, weil es auch Passwörter, API-Schlüssel und Tokens erfasst. Die in NIST SP 800-57 beschriebenen vorbetrieblichen, betrieblichen, nachbetrieblichen und zerstörten Phasen gelten speziell für kryptografisches Schlüsselmaterial; nichtkryptografische Secrets müssen nicht dieselben Zustände durchlaufen.
Häufige Fehlannahmen
Vier Abgrenzungen verhindern, dass ein einzelnes Werkzeug oder eine Spezialregel mit dem gesamten Prozess verwechselt wird:
- „Ein Vault löst das Problem vollständig.“ Nein. Authentisierung, Autorisierung, Schutz der Workloads, Rotation, Widerruf und Protokollierung bleiben notwendig.
- „Secret-Scanning ersetzt sichere Ablage und Bereitstellung.“ Nein. Scans können offengelegte Werte entdecken, schaffen aber keinen kontrollierten Abrufweg.
- „Jeder Konfigurationswert ist ein Secret.“ Nein. Maßgeblich sind Schutzbedarf, Verwendungszweck und mögliche Sicherheitsfolgen einer Offenlegung oder Veränderung.
- „Für alle Secrets gilt derselbe feste Rotationszeitraum.“ Nein. Die allgemeinen Leitlinien enthalten keine universelle Frist oder Zahl; Regeln müssen zum jeweiligen Secret-Typ, Risiko, Lebenszyklus und Zielsystem passen.
- „Die NIST-Schlüsselzustände gelten auch für Passwörter und Tokens.“ Nein. Diese Zustände betreffen kryptografisches Schlüsselmaterial und dürfen nicht verallgemeinert werden.
Was die Geschäftsleitung tun sollte
Die folgenden Schritte sind technische Praxisempfehlungen. Ihre Ausgestaltung sollte zu Architektur, Schutzbedarf, Secret-Typen und unterstützten Zielsystemen passen:
- Ein Inventar technischer Secrets sowie eindeutige Eigentümerschaften festlegen.
- Secrets aus Quellcode und unkontrollierten Konfigurationen entfernen und für bereits offengelegte Werte Rotation oder Widerruf prüfen.
- Einen kontrollierten Abruf mit authentisierten Workloads und minimalen Berechtigungen für jedes Secret einführen.
- Rotation, Ablauf und Widerruf risikobasiert je Secret-Typ und Zielsystem definieren.
- Abrufe überwachen und protokollieren sowie Berechtigungen regelmäßig überprüfbar machen.
- Secret-Scans in Entwicklungs- und CI/CD-Prozesse integrieren, ohne sie als Ersatz für sichere Bereitstellung zu behandeln.
Für die Geschäftsleitung
Secrets Management betrifft alle betriebenen oder entwickelten Systeme, in denen technische Geheimnisse für Authentisierung, Autorisierung oder Datenschutz benötigt werden. Zu entscheiden sind Eigentümerschaft, kontrollierte Abrufwege, minimale Berechtigungen sowie risikogerechte Regeln für Rotation und Widerruf. Als Nachweis eignen sich ein aktuelles Secret-Inventar, dokumentierte Verantwortlichkeiten und Berechtigungen, Scan-Ergebnisse sowie überprüfbare Abruf-, Rotations- und Widerrufsprotokolle. Ein beschaffter Vault allein belegt keinen vollständigen Prozess.
Quellen
- NIST SP 800-204C: Implementation of DevSecOps for a Microservices-based Application with Service Mesh, Abstract sowie Abschnitte 1 bis 5.
- CISA: Product Security Bad Practices, Seite 7, Punkt 8.
- CISA: T1555.006 – Cloud Secrets Management Stores, Description.
- NIST SP 800-57 Part 1 Revision 5, Abschnitte 7.5 und 8, Seiten 87 bis 90.
