TL;DR: Die meisten Organisationen steuern ihre Zertifikate gut. Dieselbe Disziplin erstreckt sich jedoch selten auf API-Token, Service-Zugangsdaten und gemeinsam genutzte Secrets, die gleichwertiges Vertrauen tragen. Diese Lücke zu schließen ist der Kern von Trust Lifecycle Management – und es entwickelt sich schnell zu einer Kategorie, die CISOs verantworten müssen.
Die größte Lücke vieler Unternehmen liegt nicht bei den Tools. Sie liegt in der Governance. Außerdem umfasst sie eine deutlich größere Bandbreite an Trust-Artefakten, als traditionelles Certificate Lifecycle Management je abgedeckt hat.
Ein interner Auditor betritt das Büro eines CISO und stellt zwei Fragen. Erstens: Wer hat Zugriff auf die Produktionsumgebung und wann laufen diese Zugangsdaten ab? Bei Zertifikaten kommt die Antwort meist schnell. Typischerweise listet die Zertifikatsmanagement-Plattform jedes ausgestellte Zertifikat, seinen Eigentümer, sein Erneuerungsdatum und seinen Widerrufsstatus auf. Die zweite Frage stellt dasselbe für API-Token, Service-Account-Zugangsdaten und Signaturschlüssel. Diese Artefakte verteilen sich über Vault, AWS Secrets Manager, Kubernetes und zwölf verschiedene CI-Pipelines. Deshalb folgt auf diese Frage meist eine längere Pause.
Diese Pause ist eine Governance-Lücke, und Regulierungsbehörden beginnen sie wahrzunehmen. Sowohl NIS2 als auch DORA verlangen Nachweise über Lifecycle-Kontrollen für kryptografisches Material und Authentifizierungsdaten. Diese Formulierung umfasst weit mehr als X.509. Auch die operative Realität entspricht dem regulatorischen Druck. Die meisten Vorfälle mit Zugangsdaten betreffen heute offengelegte oder gestohlene Secrets und nicht gebrochene Kryptografie. Dennoch unterscheiden sich die Tools und Governance-Ansätze, die die meisten Organisationen auf diese beiden Kategorien anwenden, erheblich.
Das Umfangsproblem: Zertifikate sind nur eine Klasse von Trust-Artefakten
Betrachten wir zunächst, was in einem modernen Unternehmen tatsächlich Vertrauen trägt. X.509-Zertifikate sind der offensichtliche Fall. Sie erfüllen jedoch denselben Zweck wie mehrere andere Artefakttypen. Beispiele sind OAuth-Client-Secrets, API-Token, Service-Account-Zugangsdaten, Webhook-Signatur-Secrets, Datenbankpasswörter, SSH-Schlüssel, JWT-Signaturschlüssel und Code-Signing-Materialien. Jedes davon ist eine Behauptung: Der Inhaber darf bis zu einem bestimmten Zeitpunkt im Namen einer Identität und für einen bestimmten Zweck handeln.
Die kryptografische Form ist unterschiedlich. Die Zielgruppe ist unterschiedlich. Laufzeiten reichen von Minuten bis Jahren. Die Lifecycle-Primitiven bleiben jedoch erstaunlich konsistent. Jedes Artefakt benötigt vier Dinge: unter einer Richtlinie erstellen, zu jedem Verbraucher synchronisieren, nach einem vorhersehbaren Zeitplan rotieren und bei Vertrauensverlust unverzüglich widerrufen. Bei jedem Schritt muss jemand verantwortlich bleiben.
Zertifikate als Sonderfall zu behandeln und alles andere in eine locker gesteuerte Kategorie namens „Secrets“ zu werfen, schafft eine künstliche Trennung, die Governance schwieriger statt einfacher macht.
Was Trust Lifecycle Management tatsächlich bedeutet
In der Praxis ist Trust Lifecycle Management die Disziplin, einheitliche Governance auf jedes Artefakt anzuwenden, das innerhalb einer Organisation Vertrauen verleiht. Wichtig ist: Es ersetzt HashiCorp Vault, AWS Secrets Manager oder Kubernetes Secrets nicht durch ein neues System. Diese Tools lösen Speicherung und Verteilung bereits gut. Was fehlt, ist die darüberliegende Governance-Ebene. Diese Schicht weiß, dass jedes Artefakt existiert, unabhängig vom Backend, und wendet konsistente Richtlinien auf alle an.
Die gemeinsamen Primitiven gelten daher einheitlich für jedes Trust-Artefakt. Unter kontrollierter Richtlinie erstellen. Zu den Verbrauchern synchronisieren, die das Artefakt benötigen. Nach einem vorhersehbaren Zeitplan rotieren. Bei Vertrauensverlust unverzüglich widerrufen. Gegenüber traditioneller PKI ändert sich also der Umfang, nicht die Primitiven selbst. Vor allem für regulierte Unternehmen ist diese Sichtweise wichtig. Unser früherer Beitrag über den Weg von Compliance zu Trust Lifecycle Management erläutert die Gründe.
Die Governance-Lücke durch isolierte Secrets-Tools
Gehen Sie durch die IT-Landschaft eines beliebigen Unternehmens, und Sie finden dasselbe Muster. Secrets liegen in mehreren Systemen. Jedes hat sein eigenes Zugriffsmodell, seine eigene Rotationslogik und seinen eigenen Audit-Trail.
| Tool | Typischer Umfang | Richtlinienmodell | Audit-Trail |
|---|---|---|---|
| HashiCorp Vault | Anwendungs-Secrets, PKI | HCL-Richtliniendokumente | Audit Devices |
| AWS Secrets Manager | AWS-native Zugangsdaten | IAM-Richtlinien | CloudTrail |
| Kubernetes Secrets | Zugangsdaten auf Pod-Ebene | RBAC | Kubernetes-Audit-Log |
| GitHub Actions Vault | Pipeline-Zugangsdaten | Repository-Berechtigungen | CI-Logs |
| Fest codierte Werte | Legacy-Workloads, Ad-hoc-Skripte | Keine | Keine |
Dadurch werden drei operative Fragen sehr schwer mit Sicherheit zu beantworten:
- Inventar. „Listen Sie alle Zugangsdaten mit Zugriff auf unsere Produktionsdatenbank auf – einschließlich Eigentümer, Rotationsrichtlinie und Zeitpunkt der letzten Rotation.“ Diese Informationen über fünf oder sechs Systeme zusammenzuführen dauert Tage.
- Richtlinie. „Werden alle Produktions-Secrets mindestens alle 90 Tage rotiert?“ Die Antwort hängt vom Backend und vom jeweiligen Team ab, ohne zentralen Durchsetzungspunkt.
- Audit. „Zeigen Sie mir jedes Mal, wenn dieses API-Token in den letzten 90 Tagen abgerufen wurde, wer es angefordert hat und ob dessen Zugriff zu diesem Zeitpunkt noch gültig war.“ Die Nachweisspur verteilt sich auf mehrere Logsysteme mit jeweils eigenem Schema und eigener Aufbewahrungsrichtlinie.
In der Praxis stoppen diese Lücken den Betrieb nicht. Sie machen Audits lediglich teuer und die Reaktion auf Sicherheitsverletzungen langsam. Beides ist angesichts heutiger regulatorischer Erwartungen zunehmend inakzeptabel. Und beides weist auf dieselbe Ursache hin: Es gibt keine einheitliche Governance-Ebene.
Was einheitliches Trust Lifecycle Management erfordert
Kurz gesagt hat eine Plattform, die Trust Lifecycle Management wirklich vereinheitlicht, vier Eigenschaften. Zusammen schließen sie die oben beschriebenen Governance-Lücken.
Unter allen vier Punkten liegt eine architektonische Voraussetzung: Backend-Agnostik. Die Plattform muss mit den Tools funktionieren, die Organisationen bereits einsetzen. Vault oder AWS Secrets Manager zwangsweise zu ersetzen, ist weder realistisch noch wünschenswert. NIST SP 800-57 Part 1 Revision 5 behandelt Zertifikate und anderes Schlüsselmaterial bereits unter einem konsistenten Richtlinienrahmen – siehe die Empfehlungen für Key Management. Diesen Rahmen auf Token und Zugangsdaten auszuweiten ist der logische nächste Schritt und keine neue Erfindung.
Wie OmniTrust einheitliches Trust Lifecycle Management umsetzt
Auf der RSA Conference 2026 startete OmniTrust die branchenweit erste einheitliche Trust-Lifecycle-Management-Plattform. Die Positionierung ist bewusst gewählt. OmniTrust ist überzeugt, dass CISOs diese Kategorie verantworten müssen. Die Plattform operationalisiert zudem das oben beschriebene Capability-Modell.
ILM, die Open-Source-Plattform für Identity Lifecycle Management, bildet die Grundlage des Angebots. In früheren Versionen steuerten ihre Richtlinien-, Inventar- und Audit-Primitiven Zertifikate. Heute decken dieselben Primitiven auch Secrets, Schlüssel und Zugangsdaten ab. Das Modul Secrets Management bindet HashiCorp Vault und ähnliche Backends in die Governance-Ebene von ILM ein. Es ersetzt sie nicht.
Dieselbe Richtliniensprache, die Zertifikatsrotation definiert, legt nun auch die Rotation von Zugangsdaten fest. Ebenso deckt derselbe Audit-Stream beides ab. Für einen CISO ist das praktische Ergebnis einfach: Beide Fragen vom Anfang dieses Beitrags haben nun dieselbe Antwort. Und diese Antwort kommt aus einer einzigen Konsole. Ein Auditor kann sie nutzen, ohne Logs aus mehreren Systemen zusammenzufügen.
Wichtigste Erkenntnisse
- Zertifikate sind eine Klasse von Trust-Artefakten; Secrets, Token und Schlüssel tragen gleichwertiges Vertrauen und verdienen gleichwertige Governance.
- Trust Lifecycle Management wendet einen konsistenten Satz von Lifecycle-Primitiven – Create, Sync, Rotate, Revoke – einheitlich auf jedes Artefakt an, das Vertrauen trägt.
- Die größte Lücke vieler Unternehmen liegt nicht bei den Tools, sondern in der Governance: mehrere Backends ohne gemeinsame Richtlinie, gemeinsames Inventar oder gemeinsame Audit-Ebene.
- Die richtige Architektur föderiert vorhandene Backends wie Vault und AWS Secrets Manager, statt einen Austausch zu erzwingen.
- Regulatorische Rahmenwerke wie NIS2 und DORA erwarten zunehmend Nachweise über Governance für alle Trust-Artefakte und nicht nur für Zertifikate.
Um die ILM-Plattform und das Modul Secrets Management im Detail kennenzulernen, besuchen Sie die Plattformseite zu Secrets Management. Für den Kontext zur Positionierung lesen Sie außerdem die Ankündigung zur RSA Conference 2026. Sie erklärt, warum OmniTrust diese Kategorie eingeführt hat und was einheitliches Trust Lifecycle Management in der Praxis leistet.
