Verwaltung digitaler Zertifikate und Schlüssel in DevOps

Zertifikats- und Schlüsselmanagement in DevOps bezeichnet die automatische Ausstellung, Speicherung, Rotation und den Widerruf digitaler Zertifikate und kryptografischer Schlüssel in CI/CD-Pipelines, Containern und Cloud-Infrastrukturen. Bei korrekter Umsetzung erhält jede Workload eine vertrauenswürdige Identität, ohne die Bereitstellung zu verlangsamen.

Die Verwaltung digitaler Zertifikate und Schlüssel in DevOps bedeutet die Automatisierung der Ausstellung, Speicherung, Rotation und des Widerrufs von TLS-Zertifikaten, Codesignaturschlüsseln, SSH-Schlüsseln und Geheimnissen in CI/CD-Pipelines und Cloud-Workloads. Die Automatisierung durch das ACME-Protokoll (Automatic Certificate Management Environment), Plattformen für das Zertifikatslebenszyklusmanagement und Geheimnismanager gewährleistet eine schnelle Bereitstellung und verhindert gleichzeitig abgelaufene Zertifikate und den Verlust privater Schlüssel.

Wichtige Erkenntnisse

• Zertifikate und Schlüssel authentifizieren jede Maschine in einer Pipeline: TLS für Client-Verbindungen, gegenseitiges TLS zwischen Diensten, Codesignierung für Build-Artefakte und SSH für den Zugriff auf Repository und Server.
• Die Abstimmung im CA/Browser Forum (SC-081v3) verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Die Erneuerung wird zu einem monatlichen Vorgang, der nur automatisiert bewältigt werden kann.
• ACME, im März 2019 als IETF RFC 8555 standardisiert, automatisiert Validierung, Ausstellung und Verlängerung von Zertifikaten. cert-manager, dessen CNCF-Zertifizierung für November 2024 angekündigt wurde, wendet dieselbe Automatisierung innerhalb von Kubernetes an.
• Bei dem Equifax-Datendiebstahl im Jahr 2017 wurden Daten von etwa 147 Millionen Menschen offengelegt, und der Datenabfluss blieb 76 Tage lang unentdeckt, weil ein Zertifikat auf einem Gerät zur Überwachung des Datenverkehrs abgelaufen war.
• Private Schlüssel gehören in einen Geheimnismanager oder ein Hardware-Sicherheitsmodul (HSM), niemals in Quellcode-Repositories. Der Uber-Datendiebstahl von 2016, bei dem 57 Millionen Datensätze offengelegt wurden, begann mit Zugangsdaten, die in einem privaten GitHub-Repository gefunden wurden.

Welche Funktion haben Zertifikate und Schlüssel in einer DevOps-Pipeline?

Zertifikate und Schlüssel verleihen jeder Maschine, jedem Dienst und jedem Artefakt, das eine DevOps-Pipeline berührt, eine vertrauenswürdige Identität. Digitale Zertifikate sichern den Client-Datenverkehr über HTTPS , und gegenseitige TLS-Zertifikate authentifizieren Microservices innerhalb des Clusters. Codesignaturschlüssel beweisen, dass ein Build-Artefakt oder ein Container-Image aus Ihrer Pipeline stammt und nachträglich nicht verändert wurde. SSH-Schlüssel steuern den Zugriff auf Repositories und Server, und API-Token authentifizieren jeden automatisierten Aufruf dazwischen.

Das Ergebnis ist, dass die Anzahl der Maschinenidentitäten in einer Pipeline die der ausführenden Personen bei Weitem übersteigt. Jeder Build-Server, Container und jede kurzlebige Testumgebung benötigt Anmeldeinformationen, und jede Anmeldeinformation hat einen Lebenszyklus: Sie wird erstellt, verwendet, rotiert und schließlich gelöscht. Zertifikats- und Schlüsselmanagement bedeutet, diesen Lebenszyklus bewusst zu steuern, anstatt ihn zufällig ablaufen zu lassen.

Warum DevOps die manuelle Zertifikatsverwaltung überflüssig macht

Manuelle Zertifizierungsprozesse scheitern im DevOps-Umfeld, da sich die Infrastruktur mittlerweile schneller ändert, als eine Ticketwarteschlange reagieren kann. Ein herkömmlicher Zertifikatsantrag benötigte Tage für Validierung und Genehmigung, was akzeptabel war, als Server noch jahrelang liefen. Ein Container, der nur zwanzig Minuten existiert, kann kein Ticket öffnen.

Bei langsamer Zertifikatsausstellung greifen Entwickler auf Umwege zurück. Sie erstellen selbstsignierte Zertifikate, verwenden ein Wildcard-Zertifikat für Dutzende von Diensten oder speichern Schlüssel in einem Repository, damit die Pipeline sie findet. Jeder dieser Workarounds erzeugt Kryptografie, die weder im Inventar erfasst noch durch einen Erneuerungsprozess abgedeckt wird. Jedes Zertifikat, das eine Pipeline außerhalb des Inventars erstellt, stellt einen potenziellen Ausfall oder eine Sicherheitslücke dar.

So sieht Scheitern aus: Equifax und Uber

Zwei gut dokumentierte Vorfälle zeigen, was passiert, wenn die Zertifikats- und Schlüsselhygiene hinter der Liefergeschwindigkeit zurückbleibt.

Im Jahr 2017 wurde Equifax Opfer eines Datenlecks aufgrund einer ungepatchten Sicherheitslücke in Apache Struts (CVE-2017-5638), wodurch die persönlichen Daten von rund 147 Millionen Menschen offengelegt wurden. Die Lehre aus dem Zertifikatsproblem liegt im Versagen der Erkennung: Die Untersuchung des US Government Accountability Office ergab, dass das Zertifikat des Geräts, mit dem Equifax den Netzwerkverkehr überwachte, abgelaufen war. Dadurch konnte der Datenabfluss 76 Tage lang unbemerkt bleiben. Das abgelaufene Zertifikat war zwar nicht die Ursache des Datenlecks, verhinderte aber, dass die entsprechenden Tools es erkannten.

Im Jahr 2016 erlangten Angreifer Zugangsdaten von Uber aus einem privaten GitHub-Repository und nutzten diese, um auf einen Cloud-Speicher mit Daten von 57 Millionen Fahrgästen und Fahrern zuzugreifen – ein Sicherheitsvorfall, den Uber 2017 öffentlich machte. Schlüssel und Zugangsdaten, die in der Versionsverwaltung hinterlegt sind, gelten als Geheimnisse und werden von Angreifern als erstes überprüft. Uber reagierte mit strengeren Zugriffskontrollen und Multi-Faktor-Authentifizierung für den Codezugriff; die kostengünstigere Lösung wäre, Schlüsselmaterial gar nicht erst in einem Repository zu speichern.

Die 47-tägige Gültigkeitsdauer erhöht den Einsatz.

Die Gültigkeitsdauer öffentlicher TLS-Zertifikate wird bis März 2029 gemäß der im April 2025 verabschiedeten Abstimmung SC-081v3 des CA/Browser Forums auf 47 Tage verkürzt . Die Reduzierung erfolgt schrittweise:

Datum des Inkrafttretens	Maximale Gültigkeitsdauer des TLS-Zertifikats
Bis 14. März 2026	398 Tage
15. März 2026	200 Tage
15. März 2027	100 Tage
15. März 2029	47 Tage

Nach 47 Tagen erneuern alle öffentlich zugänglichen Dienste ihre Zertifikate etwa monatlich. Teams, die die Erneuerung noch manuell durchführen, investieren mehr Zeit, als der Nutzen der Erneuerungen rechtfertigt. Für DevOps-Teams ist damit die Frage der Automatisierung geklärt: Die Pipeline, die den Dienst bereitstellt, muss auch in der Lage sein, ihr Zertifikat zu erneuern. Unternehmen können ihr Risiko jetzt durch eine 47-tägige Überprüfung der Zertifikatsbereitschaft bewerten , anstatt bis zur 100-Tage-Phase im März 2027 zu warten, um die Erneuerung zu erzwingen.

Sechs Best Practices für die Verwaltung von Zertifikaten und Schlüsseln in DevOps

Sechs Praktiken decken den Großteil des Risikos im DevOps-Zertifikats- und Schlüsselmanagement ab, und jede einzelne kann eingeführt werden, ohne die Auslieferung zu unterbrechen.

1. Erstellen und pflegen Sie ein Zertifikats- und Schlüsselinventar: Erfassen Sie jedes Zertifikat und jeden Schlüssel in der Umgebung: Typ, Inhaber, Ablaufdatum, Speicherort und ausstellende Behörde. Dieses Inventar bildet die Grundlage für alles Weitere, denn was Sie nicht einsehen können, lässt sich weder erneuern, rotieren noch widerrufen. Die Ermittlung muss kontinuierlich erfolgen; eine einmalige Prüfung ist bereits am Tag der nächsten Pipeline-Ausführung veraltet.
2. Automatisierte Ausstellung und Verlängerung: Verwenden Sie das ACME-Protokoll (IETF RFC 8555, März 2019) oder eine Plattform für das Zertifikatslebenszyklusmanagement, damit Zertifikate ohne Tickets ausgestellt und erneuert werden können. In Kubernetes Zertifizierungsmanager Die Automatisierung der Ausstellung und Erneuerung von TLS- und gegenseitigen TLS-Zertifikaten sowie die im November 2024 angekündigte CNCF-Zertifizierung verdeutlichen, wie weit diese Automatisierung bereits zum Standard geworden ist.
3. Schützen Sie private Schlüssel in einem HSM oder Geheimnismanager: Schlüssel gehören niemals in Quellcode-Repositories, Container-Images oder einfache Pipeline-Variablen. Speichern Sie sie in einem Hardware-Sicherheitsmodul oder einem Geheimnismanager und lassen Sie Workloads sie zur Laufzeit über kurzzeitigen, protokollierten Zugriff abrufen.
4. Zugriff nach dem Prinzip der minimalen Berechtigungen durchsetzen: Beschränken Sie, wer und was Zertifikate anfordern, Schlüssel lesen oder Ausstellungsrichtlinien ändern darf, und protokollieren Sie jeden Zugriff. Rollenbasierte Kontrollen der Zertifizierungsstelle und des Geheimnisspeichers begrenzen die Auswirkungen eines Datenlecks einzelner Anmeldeinformationen.
5. Ablaufdatum überwachen und frühzeitig alarmieren; Verfolgen Sie jedes Zertifikat hinsichtlich seines Ablaufdatums und benachrichtigen Sie rechtzeitig vor der Erneuerung, auch bei Zertifikaten auf der Sicherheitsausrüstung selbst. Equifax zeigt, warum: Überwachung, die Sie nicht entschlüsseln können, ist praktisch nicht vorhanden.
6. Bevorzugen Sie kurzlebige Akkreditierungen: Kurzlebige Zertifikate und Token verkürzen das Zeitfenster, in dem Angreifer gestohlene Zugangsdaten nutzen können, und reduzieren die Abhängigkeit von deren Widerruf. Die Branche bewegt sich ohnehin in diese Richtung; die frühzeitige Einführung kurzer Gültigkeitsdauern macht die 47-Tage-Frist irrelevant.

Integration von Zertifikatssicherheit in CI/CD

Zertifikatssicherheit bewährt sich in DevOps, wenn sie wie die übrige Infrastruktur als Code definiert wird. Ausstellungsrichtlinien, Zertifikatsprofile und Vertrauenskonfigurationen gehören in die Versionskontrolle, wo sie wie Anwendungscode geprüft und gegebenenfalls zurückgesetzt werden. Die Überprüfung geheimer Schlüssel in der Pipeline sollte jeden Build fehlschlagen lassen, der einen privaten Schlüssel oder fest codierte Anmeldeinformationen enthält. Dadurch wird der Fehlerfall von Uber zu einer blockierten Zusammenführung anstatt zu einem Sicherheitsvorfall. Kontinuierliche Überwachung schließt den Kreislauf und leitet Ereignisse über Zertifikatsablauf und anomale Zertifikatsausstellungen an dasselbe Warnsystem weiter, das auch die Anwendung überwacht.

Wie Verschlüsselungsberatung hilft

CertSecure Manager ist die Zertifikatslebenszyklusmanagement-Plattform von Encryption Consulting. Sie erkennt und inventarisiert Zertifikate in Ihrer gesamten Umgebung und automatisiert deren Ausstellung, Verlängerung und Widerruf. So werden Pipeline-Zertifikate planmäßig und nicht per Ticket erneuert. Für Teams, die ihre Pipeline-Sicherheit umfassender gestalten, deckt die Securing DevOps Practice das zugehörige Schlüsselmanagement und die PKI- Architektur ab. Die Plattform basiert auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Häufig gestellte Fragen

Warum ist die Zertifikatsverwaltung in DevOps schwieriger als in der traditionellen IT?

DevOps-Infrastrukturen sind kurzlebig. Container und Cloud-Instanzen werden innerhalb von Minuten erstellt und gelöscht, und jede benötigt eine vertrauenswürdige Identität. Daher wächst das Zertifikatsvolumen weit über die Kapazität eines ticketbasierten Ausstellungsverfahrens hinaus. Traditionelle IT-Abteilungen erneuerten einen bekannten Satz von Zertifikaten einmal jährlich; eine Pipeline kann Hunderte von Zertifikaten pro Tag anfordern und kann nicht tagelang auf jedes einzelne warten.

Was ist ACME und wie hilft es DevOps-Teams?

ACME (Automatic Certificate Management Environment) ist das im März 2019 in IETF RFC 8555 standardisierte Protokoll. Es automatisiert die Domänenvalidierung, Zertifikatsausstellung und -erneuerung zwischen Client und Zertifizierungsstelle – ganz ohne menschliches Eingreifen. Tools wie cert-manager nutzen ACME, um Zertifikate für Kubernetes-Workloads automatisch auszustellen und zu erneuern. So arbeiten öffentliche Zertifizierungsstellen wie Let's Encrypt im großen Maßstab.

Wie wirkt sich die 47-tägige Gültigkeitsdauer von Zertifikaten auf DevOps-Pipelines aus?

Die Abstimmung des CA/Browser Forums (SC-081v3) reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate schrittweise: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Bei einer Gültigkeitsdauer von 47 Tagen erneuern alle öffentlich zugänglichen Dienste ihre Zertifikate etwa monatlich. Eine manuelle Erneuerung kann mit diesem Tempo nicht mithalten, daher ist die automatisierte Ausstellung und Erneuerung innerhalb des Prozesses eine Notwendigkeit und keine Optimierung mehr.

Wo sollten private Schlüssel in einer CI/CD-Pipeline gespeichert werden?

Private Schlüssel gehören in einen Geheimnismanager oder ein Hardware-Sicherheitsmodul (HSM), niemals in Quellcode-Repositories, Container-Images oder einfache Pipeline-Variablen. Der Uber-Datendiebstahl von 2016 begann mit Zugangsdaten, die in einem privaten GitHub-Repository gefunden wurden. Pipelines sollten Schlüssel zur Laufzeit über kurzzeitige, protokollierte Zugriffe abrufen, und die Suche nach Geheimnissen sollte jeden Build abbrechen, der Schlüsselmaterial im Code enthält.

Worin besteht der Unterschied zwischen einem Geheimnismanager und einer Plattform für das Zertifikatslebenszyklusmanagement?

Ein Secrets Manager speichert und rotiert sensible Daten wie private Schlüssel, API-Token und Passwörter und stellt sie den Workloads zur Laufzeit zur Verfügung. Eine Certificate Lifecycle Management (CLM)-Plattform verwaltet das Zertifikat selbst: Erkennung, Inventarisierung, Ausstellung durch eine Zertifizierungsstelle, Verlängerung und Widerruf. Beide ergänzen sich. Die CLM-Plattform legt fest, wann und wie ein Zertifikat existiert; der Secrets Manager schützt die zugrunde liegenden Schlüsseldaten.

Automatisieren Sie Zertifikatslebenszyklen, bevor die Zeit knapp wird

Die 200-Tage-Frist trat am 15. März 2026 in Kraft, und das Tempo beschleunigt sich von nun an. Erleben Sie CertSecure Manager in Aktion , um die Erkennung, Ausstellung und Verlängerung von Zertifikaten in Ihren gesamten Prozessen zu automatisieren, oder erstellen Sie mit dem kostenlosen CSR-Generator eine Testanfrage, um Ihren aktuellen Ausstellungsprozess zu überprüfen.