{"id":17865,"date":"2026-04-27T10:35:17","date_gmt":"2026-04-27T17:35:17","guid":{"rendered":"https:\/\/www.omnitrust.com\/blog\/warum-trust-lifecycle-management-secrets-einschliessen-muss\/"},"modified":"2026-09-28T21:09:23","modified_gmt":"2026-09-29T04:09:23","slug":"warum-trust-lifecycle-management-secrets-einschliessen-muss","status":"publish","type":"post","link":"https:\/\/www.omnitrust.com\/de\/blog\/warum-trust-lifecycle-management-secrets-einschliessen-muss\/","title":{"rendered":"Warum Trust Lifecycle Management Secrets einschlie\u00dfen muss"},"content":{"rendered":" \n

TL;DR:<\/strong> 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\u00fccke zu schlie\u00dfen ist der Kern von Trust Lifecycle Management \u2013 und es entwickelt sich schnell zu einer Kategorie, die CISOs verantworten m\u00fcssen.<\/p> \n\r\n

\u00a0<\/div>\r\n\r\n
\n

Die gr\u00f6\u00dfte L\u00fccke vieler Unternehmen liegt nicht bei den Tools. Sie liegt in der Governance. Au\u00dferdem umfasst sie eine deutlich gr\u00f6\u00dfere Bandbreite an Trust-Artefakten, als traditionelles Certificate Lifecycle Management je abgedeckt hat.<\/p> \n<\/div>\r\n\r\n

\u00a0<\/div>\r\n
TRUST LIFECYCLE MANAGEMENTZERTIFIKATS-LIFECYCLEX.509SecretsAPI-TokenZugangsdatenSignaturschl\u00fcsselGEMEINSAME LIFECYCLE-PRIMITIVENCREATE SYNC ROTATE REVOKE\r\n
Certificate Lifecycle Management ist eine Klasse des Trust Lifecycle Management. Die Lifecycle-Primitiven sind dieselben; der Umfang ist gr\u00f6\u00dfer.<\/figcaption>\r\n<\/figure>\n\r\n
\u00a0<\/div>\r\n \n

Ein interner Auditor betritt das B\u00fcro 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\u00fcmer, sein Erneuerungsdatum und seinen Widerrufsstatus auf. Die zweite Frage stellt dasselbe f\u00fcr API-Token, Service-Account-Zugangsdaten und Signaturschl\u00fcssel. Diese Artefakte verteilen sich \u00fcber Vault, AWS Secrets Manager, Kubernetes und zw\u00f6lf verschiedene CI-Pipelines. Deshalb folgt auf diese Frage meist eine l\u00e4ngere Pause.<\/p> \n \n

Diese Pause ist eine Governance-L\u00fccke, und Regulierungsbeh\u00f6rden beginnen sie wahrzunehmen. Sowohl NIS2 als auch DORA verlangen Nachweise \u00fcber Lifecycle-Kontrollen f\u00fcr kryptografisches Material und Authentifizierungsdaten. Diese Formulierung umfasst weit mehr als X.509. Auch die operative Realit\u00e4t entspricht dem regulatorischen Druck. Die meisten Vorf\u00e4lle mit Zugangsdaten betreffen heute offengelegte oder gestohlene Secrets und nicht gebrochene Kryptografie. Dennoch unterscheiden sich die Tools und Governance-Ans\u00e4tze, die die meisten Organisationen auf diese beiden Kategorien anwenden, erheblich.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Das Umfangsproblem: Zertifikate sind nur eine Klasse von Trust-Artefakten<\/h2> \n \n

Betrachten wir zun\u00e4chst, was in einem modernen Unternehmen tats\u00e4chlich Vertrauen tr\u00e4gt. X.509-Zertifikate sind der offensichtliche Fall. Sie erf\u00fcllen jedoch denselben Zweck wie mehrere andere Artefakttypen. Beispiele sind OAuth-Client-Secrets, API-Token, Service-Account-Zugangsdaten, Webhook-Signatur-Secrets, Datenbankpassw\u00f6rter, SSH-Schl\u00fcssel, JWT-Signaturschl\u00fcssel und Code-Signing-Materialien. Jedes davon ist eine Behauptung: Der Inhaber darf bis zu einem bestimmten Zeitpunkt im Namen einer Identit\u00e4t und f\u00fcr einen bestimmten Zweck handeln.<\/p> \n \n

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\u00f6tigt vier Dinge: unter einer Richtlinie erstellen<\/strong>, zu jedem Verbraucher synchronisieren<\/strong>, nach einem vorhersehbaren Zeitplan rotieren<\/strong> und bei Vertrauensverlust unverz\u00fcglich widerrufen<\/strong>. Bei jedem Schritt muss jemand verantwortlich bleiben.<\/p> \n \n

\n
\n

Zertifikate als Sonderfall zu behandeln und alles andere in eine locker gesteuerte Kategorie namens \u201eSecrets\u201c zu werfen, schafft eine k\u00fcnstliche Trennung, die Governance schwieriger statt einfacher macht.<\/p> \n<\/blockquote> \n<\/figure> \n\r\n

\u00a0<\/div>\r\n \n

Was Trust Lifecycle Management tats\u00e4chlich bedeutet<\/h2> \n \n

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\u00f6sen Speicherung und Verteilung bereits gut. Was fehlt, ist die dar\u00fcberliegende Governance-Ebene. Diese Schicht wei\u00df, dass jedes Artefakt existiert, unabh\u00e4ngig vom Backend, und wendet konsistente Richtlinien auf alle an.<\/p> \n \n

Die gemeinsamen Primitiven gelten daher einheitlich f\u00fcr jedes Trust-Artefakt. Unter kontrollierter Richtlinie erstellen<\/strong>. Zu den Verbrauchern synchronisieren<\/strong>, die das Artefakt ben\u00f6tigen. Nach einem vorhersehbaren Zeitplan rotieren<\/strong>. Bei Vertrauensverlust unverz\u00fcglich widerrufen<\/strong>. Gegen\u00fcber traditioneller PKI \u00e4ndert sich also der Umfang, nicht die Primitiven selbst. Vor allem f\u00fcr regulierte Unternehmen ist diese Sichtweise wichtig. Unser fr\u00fcherer Beitrag \u00fcber den Weg von Compliance zu Trust Lifecycle Management<\/a> erl\u00e4utert die Gr\u00fcnde.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Die Governance-L\u00fccke durch isolierte Secrets-Tools<\/h2> \n \n

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.<\/p> \n \n

\n \n \n \n \n \n \n \n \n \n
Tool<\/th> \nTypischer Umfang<\/th> \nRichtlinienmodell<\/th> \nAudit-Trail<\/th> \n<\/tr> \n<\/thead> \n
HashiCorp Vault<\/td> \nAnwendungs-Secrets, PKI<\/td> \nHCL-Richtliniendokumente<\/td> \nAudit Devices<\/td> \n<\/tr> \n
AWS Secrets Manager<\/td> \nAWS-native Zugangsdaten<\/td> \nIAM-Richtlinien<\/td> \nCloudTrail<\/td> \n<\/tr> \n
Kubernetes Secrets<\/td> \nZugangsdaten auf Pod-Ebene<\/td> \nRBAC<\/td> \nKubernetes-Audit-Log<\/td> \n<\/tr> \n
GitHub Actions Vault<\/td> \nPipeline-Zugangsdaten<\/td> \nRepository-Berechtigungen<\/td> \nCI-Logs<\/td> \n<\/tr> \n
Fest codierte Werte<\/td> \nLegacy-Workloads, Ad-hoc-Skripte<\/td> \nKeine<\/td> \nKeine<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
F\u00fcnf Systeme, f\u00fcnf Governance-Ebenen. Jedes ist gut in seiner Aufgabe; keines sieht die anderen.<\/figcaption> \n<\/figure> \n \n

Dadurch werden drei operative Fragen sehr schwer mit Sicherheit zu beantworten:<\/p> \n \n