Automatisierung der Zertifikatsverwaltung in Azure Key Vault

Azure Key Vault ist ein sicherer Speicherort für Geheimnisse, Schlüssel und Zertifikate und hat sich für Unternehmen, die Microsoft Azure nutzen, zum Standardspeicherort für TLS-Zertifikate und die zugehörigen privaten Schlüssel entwickelt. Azure Key Vault sichert die Zertifikatsspeicherung, doch die Verwaltung des Zertifikatslebenszyklus – also das Erkennen, Ausstellen, Bereitstellen und Rotieren von Zertifikaten in allen Umgebungen – erfordert eine darüberliegende Orchestrierungsschicht, insbesondere da die Gültigkeitsdauer öffentlicher TLS-Zertifikate auf etwa 47 Tage sinkt. Die Diskrepanz zwischen der Speicherung und der Verwaltung eines Zertifikats droht zu einem ernsthaften betrieblichen Problem zu werden.

Dieser Leitfaden behandelt die Grenzen der integrierten Funktionen von Key Vault, die Voraussetzungen und den schrittweisen Arbeitsablauf für die Implementierung einer Certificate Lifecycle Management (CLM)-Plattform darüber sowie wie PKI-, Sicherheits-, Plattform- und Compliance-Teams diese Lücke in einen geregelten, automatisierten Prozess verwandeln können.

Wichtige Erkenntnisse

• Azure Key Vault speichert Zertifikate und private Schlüssel sicher und kann Zertifikate von seinen integrierten CA-Partnern automatisch erneuern, kann jedoch keine Zertifikate auf Nicht-Azure-Endpunkten bereitstellen, Zertifikate außerhalb von Key Vault einsehen oder eine einheitliche Richtlinie in einer Multi-Cloud-Umgebung durchsetzen.
• Der Wahlvorschlag SC-081v3 des CA/Browser Forums verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage bis März 2026, 100 Tage bis März 2027 und 47 Tage bis März 2029, was bei einem Bestand von 1,000 Zertifikaten zu etwa 20 Zertifikatsoperationen pro Werktag führt.
• Die Trust Pulse Survey von DigiCert (2. Juli 2025) ergab, dass 45 % der Unternehmen im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten hatten, und 37.5 % konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen.
• Eine CLM-Plattform, die über Key Vault platziert wird, bietet intelligente Erkennung, CA-unabhängige Closed-Loop-Automatisierung und einheitliche Richtliniendurchsetzung und schließt damit die Lücke bei der Bereitstellung auf der letzten Meile, die die meisten Zertifikatsausfälle verursacht.
• Die Teams für PKI, Sicherheit, Plattform und Compliance sind jeweils für eine bestimmte Aktion zuständig; die untenstehende Verantwortlichkeits-/Aktionsmatrix und die Tabelle der Voraussetzungen für die Aktion zeigen genau, was und wer dafür verantwortlich ist.

Direkt zu: Zusammenfassung | Voraussetzungen | Implementierungsablauf | Vorher/Nachher-Ablauf | Häufige Fehler und Rollback | Erfolgskennzahlen | Verantwortlichkeits-/Aktionsmatrix | Nächste Schritte | FAQ

Zusammenfassung für die Teams PKI, Sicherheit, Plattform und Compliance

Wenn Sie eine dieser Funktionen leiten, finden Sie hier die in diesem Artikel unterstützte Entscheidung und eine Kurzübersicht zur Umsetzung.

• PKI-Teams: Azure Key Vault soll als sicherer Speicher beibehalten werden, aber er soll mit einer CA-unabhängigen CLM-Plattform verbunden werden, sodass Zertifikate von jeder CA, nicht nur von den integrierten Partnern von Key Vault, automatisch erneuert und bereitgestellt werden.
• Sicherheitsteams: Die Lücke bei der Bereitstellung auf der letzten Meile muss geschlossen werden; ein Zertifikat, das zwar im Key Vault erneuert wurde, aber nicht an den Load Balancer oder Ingress Controller, der es verwendet, übertragen wurde, stellt immer noch eine potenzielle Ausfallgefahr dar.
• Plattform-/DevSecOps-Teams: Die Automatisierung der Wire-Erkennung und -Bereitstellung in Azure, anderen Clouds, On-Premises-Umgebungen und Kubernetes vor Ablauf der 100-tägigen Gültigkeitsphase macht eine manuelle Bereitstellung unhaltbar.
• Compliance-Teams: bestätigen, dass die Orchestrierungsschicht einen einheitlichen Satz von Richtlinien, zugelassenen Zertifizierungsstellen, Schlüssellängen und Algorithmen in jeder Umgebung durchsetzt, nicht nur in dem, was sich im Key Vault befindet.

Was Azure Key Vault gut kann

Key Vault hat sich seinen Ruf als sicherer Speicherort redlich verdient. Er bietet gehärteten, zugriffskontrollierten Speicher für Zertifikate und private Schlüssel, lässt sich nahtlos in andere Azure-Dienste integrieren und bietet einige echte Komfortfunktionen für Zertifikate, die vollständig innerhalb des Azure-Ökosystems verbleiben.

Für Zertifikate, die über einen der integrierten Zertifizierungsstellenpartner von Key Vault ausgestellt wurden, können Sie die automatische Verlängerung konfigurieren. Key Vault übernimmt dann die Neuausstellung gemäß Ihrem festgelegten Zeitplan. Benachrichtigungen werden versendet, sobald ein Zertifikat einen bestimmten Prozentsatz seiner Gültigkeitsdauer erreicht hat, sodass Teams rechtzeitig vor Ablauf informiert werden. Für Organisationen, deren Zertifikatsbestand vollständig in Azure verwaltet wird und die eine integrierte Zertifizierungsstelle nutzen, decken diese Funktionen einen Großteil der täglichen Anforderungen ab.

Der entscheidende Punkt ist jedoch die Formulierung „vollständig innerhalb des Azure-Ökosystems“. An diesem Punkt beginnen die Grenzen sichtbar zu werden.

Wo die integrierten Verwaltungsfunktionen von Key Vault an ihre Grenzen stoßen

Azure Key Vault vereinfacht zwar die Zertifikatsverwaltung in Azure, doch stoßen Unternehmen im großen Maßstab schnell an Grenzen hinsichtlich der Flexibilität der Zertifizierungsstelle, der Bereitstellungsautomatisierung, der Transparenz und der Governance. Die folgenden Bereiche verdeutlichen, wo die integrierte Verwaltung an ihre Grenzen stößt:

Begrenzte Flexibilität der Zertifizierungsstelle

Die komfortable automatische Zertifikatserneuerung von Key Vault funktioniert reibungslos nur mit den integrierten Zertifizierungsstellenpartnern. Sobald Sie ein Zertifikat von einer nicht integrierten Zertifizierungsstelle benötigen – sei es eine interne private PKI , eine kommerzielle Zertifizierungsstelle außerhalb der Partnerliste oder eine im Rahmen einer Übernahme übernommene Zertifizierungsstelle –, ist diese nahtlose Integration nicht mehr möglich. Sie müssen das neue Zertifikat dann selbst abrufen und es mithilfe von Skripten oder manuellen Schritten in Key Vault importieren. Für Organisationen, die aus Gründen der Ausfallsicherheit, der Kosten oder der Compliance bewusst mehrere Zertifizierungsstellen betreiben, stellt dies eine strukturelle Einschränkung und keine geringfügige Unannehmlichkeit dar.

Keine Bereitstellung auf der letzten Meile jenseits von Azure

Dies ist die gravierendste Lücke. Die Speicherung eines erneuerten Zertifikats im Key Vault ist nicht dasselbe wie dessen Bereitstellung auf den Systemen, die es tatsächlich verwenden. Zertifikate befinden sich nicht nur im Key Vault. Sie sind auf Load Balancern, Application Gateways, NGINX- und Apache -Servern, Kubernetes-Ingress-Controllern, Service Meshes, Firewalls und unzähligen anderen Endpunkten vorhanden, von denen viele vollständig außerhalb der Automatisierungsgrenzen von Azure liegen.

Der Key Vault kann zwar das Zertifikat speichern, überträgt es aber nicht an einen F5 Load Balancer, bindet es nicht an einen Nicht-Azure-Webserver und aktualisiert auch keinen Ingress-Controller in einem Cluster, der an anderer Stelle ausgeführt wird, und überprüft anschließend nicht den erfolgreichen Abschluss der Bereitstellung. Genau bei diesem letzten Schritt – der Installation des Zertifikats am richtigen Endpunkt und der Bestätigung, dass der Dienst es erkannt hat – treten häufig Zertifikatsausfälle auf. Die Verwendung von benutzerdefinierten Skripten und manuellem Aufwand offenbart genau diese Anfälligkeit, die durch den 47-tägigen Bereitstellungszyklus deutlich wird.

Fragmentierte Sichtbarkeit in einer realen Umgebung

Die meisten Unternehmen setzen nicht ausschließlich auf Azure. Ihre Workloads verteilen sich auf mehrere Clouds, lokale Infrastrukturen und Hybridumgebungen. Key Vault bietet zwar Einblick in die in Key Vault gespeicherten Zertifikate, jedoch nicht in die Zertifikate, die sich in AWS, Google Cloud, auf physischen Servern in Rechenzentren oder in einem Kubernetes-Cluster außerhalb von Azure befinden. Dies führt zu einem fragmentierten Bild, und diese fragmentierte Transparenz begünstigt Schattenzertifikate und unerwartete Ablaufdaten. Ein Zertifikat, das man nicht einsehen kann, lässt sich weder verwalten, erneuern noch schützen.

Eine Governance, die sich nicht über das gesamte Anwesen erstreckt

Die Verwaltung von Unternehmenszertifikaten erfordert einheitliche Richtlinien, wie z. B. zugelassene Zertifizierungsstellen, Mindestschlüssellängen, zulässige Algorithmen, Gültigkeitsregeln und rollenbasierte Zugriffskontrolle, die gemäß Best Practices der Branche einheitlich überall durchgesetzt werden. Key Vault kann zwar den Inhalt verwalten, aber keine einheitliche Richtlinie für jede Cloud, jede Zertifizierungsstelle und jeden lokalen Endpunkt Ihres Unternehmens erzwingen. Ohne diese Einheitlichkeit wird die Governance inkonsistent, und Inkonsistenzen sind die Grundlage für Beanstandungen bei Audits.

Die Daten hinter der Dringlichkeit

Zwei unabhängig voneinander erhobene Datenpunkte quantifizieren, was passiert, wenn die Zertifikatsverwaltung bei der Speicherung stoppt und nie zur automatisierten Bereitstellung führt:

• 45 % der Unternehmen erlebten im vergangenen Jahr Serviceausfälle aufgrund von Zertifikatsproblemen, und 37.5 % konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen., laut DigiCert Vertrauens-PulsumfrageVeröffentlicht am 2. Juli 2025.
• Die maximale Gültigkeitsdauer des öffentlichen TLS wird schrittweise auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029 reduziert., bestätigt durch die Abstimmung SC-081v3 des CA/Browser Forums und Sectigos Analyse vom 14. April 2025 des gleichen Zeitplans.
• Schätzung des Arbeitsaufwands für die Erneuerung: Bei einer Gültigkeitsdauer von 47 Tagen wird ein Zertifikat etwa achtmal im Jahr erneuert; bei einem Bestand von 1,000 Zertifikaten entspricht dies ungefähr 20 Zertifikatsvorgängen pro Arbeitstag – ein Volumen, das kein manueller oder teilautomatisierter Key Vault-Workflow bewältigen kann.
• Keine der beiden Umfrageergebnisse bezieht sich speziell auf Key Vault, aber beide beschreiben genau den Fehlermodus, den das reine Speichermodell von Key Vault zulässt: ein erneuertes Zertifikat, das im Tresor verbleibt und nie auf dem Endpunkt bereitgestellt wird, der es tatsächlich benötigt.

Voraussetzungen vor der Implementierung

Bevor Sie eine CLM-Plattform mit Azure Key Vault verbinden, vergewissern Sie sich, dass Folgendes gegeben ist:

• Azure-Zugriff: ein Azure AD-Dienstprinzipal oder eine verwaltete Identität mit Key Vault-Zertifikat und geheimen Berechtigungen (Abrufen, Auflisten, Erstellen, Aktualisieren), die auf die entsprechenden Tresore beschränkt sind.
• Zertifikatsinventar: eine aktuelle Liste oder ein abgeschlossener Discovery-Scan aller verwendeten Zertifikate, einschließlich derer außerhalb von Key Vault, damit die Plattform eine Grundlage für den Abgleich hat.
• CA-Zugangsdaten und Integrationsdetails: API-Zugriffs- oder Konnektordetails für jede verwendete Zertifizierungsstelle, öffentliche und private, die über die integrierte Partnerliste von Key Vault hinausgeht.
• Endpunktinventar: Eine Liste der Load Balancer, Ingress Controller, Webserver und anderer Endpunkte, die Zertifikate verwenden, mit den Anmeldeinformationen oder Agenten, die benötigt werden, um ein Zertifikat an jeden einzelnen zu übertragen.
• Richtliniendefinitionen: Genehmigte Algorithmen, Mindestschlüssellängen, Gültigkeitsdauern und Namenskonventionen werden vor der Inbetriebnahme der Automatisierung mit den Bereichen Sicherheit und Compliance abgestimmt.
• Änderungs- und Rollback-Fenster: Ein Wartungsfenster und ein Rollback-Plan für den ersten automatisierten Erneuerungszyklus, damit eine fehlgeschlagene Bereitstellung ohne Ausfall rückgängig gemacht werden kann.

Schrittweiser Implementierungsablauf

Sind die Voraussetzungen erfüllt, lassen sich eine CLM-Plattform und Azure Key Vault in sechs Schritten verbinden, um die letzte Lücke zu schließen.

1. Verbinde Discovery mit Key Vault und darüber hinaus. Registrieren Sie die CLM-Plattform für jede Azure Key Vault-Instanz mithilfe des Dienstprinzipals aus den Voraussetzungen und erweitern Sie dann denselben Erkennungsscan auf andere Clouds, lokale Server und Kubernetes-Cluster, damit das Inventar vollständig ist und nicht nur Azure umfasst.
2. Den Lagerbestand abgleichen. Vergleichen Sie die von der Plattform gefundenen Zertifikate mit Ihrem bestehenden Bestand aus dem Schritt „Voraussetzungen“. Untersuchen Sie alle gefundenen Zertifikate, die noch nicht erfasst wurden; dies sind sogenannte Schattenzertifikate, die unerwartete Ablaufdaten verursachen.
3. Verbinde alle CAs. Konfigurieren Sie die CA-Integrationen der Plattform, die integrierten Partner von Key Vault sowie jede private PKI oder kommerzielle CA außerhalb dieser Liste, unter Verwendung eines Protokolls wie ACME, SCEP oder EST, sofern unterstützt, oder einer direkten API-Integration.
4. Richtlinien anwenden. Laden Sie die genehmigten Algorithmen, Schlüssellängen und Gültigkeitsregeln aus den Voraussetzungen in die Richtlinien-Engine der Plattform, damit jede zukünftige Ausstellung und Verlängerung automatisch überprüft wird, bevor sie einen Endpunkt erreicht.
5. Konfiguration der Bereitstellung auf der letzten Meile. Ordnen Sie jeden Endpunkt aus den Voraussetzungen, Load Balancern, Ingress Controllern und Webservern dem von ihm verwendeten Zertifikat zu und konfigurieren Sie die Plattform so, dass sie ein erneuertes Zertifikat an diesen Endpunkt sendet und die Bindung automatisch überprüft.
6. Pilot, dann erweitern. Führen Sie den gesamten geschlossenen Kreislauf aus, erkennen Sie das Ablaufdatum, fordern Sie die Zertifikate bei der Zertifizierungsstelle an, speichern Sie sie im Key Vault, stellen Sie sie auf dem Endpunkt bereit und überprüfen Sie sie zunächst an einem kleinen, nicht kritischen Zertifikatssatz innerhalb des Änderungszeitraums der Voraussetzungen. Bestätigen Sie den Erfolg, bevor Sie die Aktualisierung auf alle Zertifikate ausweiten.

Screenshot-Platzhalter: Dashboard der CLM-Plattform mit einer verbundenen Key Vault-Instanz, den erkannten Zertifikaten und deren Ablaufstatus. Alternativtext: „Dashboard für die Zertifikatslebenszyklusverwaltung mit Anzeige der in Azure Key Vault erkannten Zertifikate und deren Ablaufdatum.“

Screenshot-Platzhalter: Konfigurationsbildschirm der Richtlinien mit den genehmigten Schlüssellängen- und Algorithmusregeln, die für alle CA-Integrationen gelten. Alternativtext: „Konfigurationsbildschirm der Zertifikatrichtlinien-Engine mit den genehmigten Algorithmen und den Regeln für die minimale Schlüssellänge.“

Das richtige Modell: Orchestrierung über dem Schlüsseltresor, nicht anstelle dessen

Die Lösung besteht nicht darin, Azure Key Vault aufzugeben. Key Vault ist ein zuverlässiger Zertifikatsspeicher, und es gibt keinen Grund, ihn zu ersetzen. Die Lösung liegt vielmehr darin, eine Plattform für das Zertifikatslebenszyklusmanagement darüber zu implementieren. Diese fungiert als Orchestrierungsschicht und macht Key Vault zu einer gut verwalteten Komponente eines umfassenderen, automatisierten und CA-unabhängigen Zertifikatsökosystems.

In diesem Modell übernimmt die CLM-Plattform Aufgaben, für die Key Vault nie konzipiert wurde. Drei Funktionen definieren, was ein gutes Ergebnis ausmacht.

Intelligente Erkennung über alle Ressourcen hinweg. Effektive Automatisierung beginnt mit vollständiger Transparenz. Die Plattform sollte Zertifikate kontinuierlich überall dort erkennen, wo sie gespeichert sind – in Azure Key Vault, anderen Clouds, lokal und in Containerumgebungen – und sie in einem einzigen, mit Aussteller, Ablaufdatum, Schlüssellänge, Algorithmus und Speicherort angereicherten Inventar konsolidieren. Unternehmen entdecken regelmäßig deutlich mehr Zertifikate als erwartet, sobald sie einen korrekten Scan durchführen. Das Aufspüren der unbekannten Zertifikate ist der erste Schritt zu deren Kontrolle.

CA-unabhängig, protokollflexibel, mit geschlossener Automatisierungsschleife. Die Plattform führt den gesamten Erneuerungsprozess ohne menschliches Eingreifen durch, unabhängig davon, welche Zertifizierungsstelle (CA) das Zertifikat ausstellt: Erkennung des bevorstehenden Ablaufs, Prüfung der Richtlinien, Generierung der Signaturanforderung, Aufruf der CA, Abruf des Zertifikats, Speicherung im Key Vault und anschließende Übertragung an den korrekten Endpunkt sowie Überprüfung der Bindung. Die Unterstützung von Protokollen wie ACME , SCEP und EST sowie die direkte Integration von CAs ermöglichen den reibungslosen Betrieb in heterogenen IT-Umgebungen. Dadurch wird die Lücke geschlossen, die Key Vault allein hinterlässt.

Richtliniendurchsetzung und Governance überall. Die Plattform sollte einheitliche kryptografische Richtlinien, zugelassene Zertifizierungsstellen, Schlüsselstärken, Algorithmen und Gültigkeitsregeln konsistent in jeder Umgebung durchsetzen – mit rollenbasierter Zugriffskontrolle und revisionssicheren Berichten. Dies gewährleistet eine einheitliche Governance und den Compliance-Nachweis, den die auf den Tresor beschränkten Kontrollen von Key Vault allein nicht erbringen können.

Mit dieser Architektur kann Key Vault weiterhin seine Stärken ausspielen – sichere Speicherung und enge Azure-Integration –, während die CLM-Plattform die Transparenz, die umgebungsübergreifende Automatisierung und die Governance bietet, die für die Verwaltung von Zertifikaten im Unternehmensmaßstab unter einem 47-Tage-Mandat erforderlich sind.

Vorher/Nachher-Betriebsablauf

Die folgende Tabelle stellt den reinen Key-Vault-Workflow dem in diesem Leitfaden beschriebenen orchestrierten Workflow gegenüber.

Praktikum	Vorher (nur Schlüsseltresor)	Nach (CLM-Orchestrierung oberhalb des Schlüsseltresors)
Bewertung	Nur sichtbar für Zertifikate, die bereits im Key Vault gespeichert sind.	Kontinuierliche Erkennung über Key Vault, andere Clouds, On-Premises-Umgebungen und Container hinweg
Ausstellung/Verlängerung	Automatisch nur für integrierte CA-Partner von Key Vault	Geschlossene Automatisierung für jede CA über API, ACME, SCEP oder EST
Einsatz	Manueller Export und Installation auf Nicht-Azure-Endpunkten	Automatisierte Übertragung an Load Balancer, Ingress Controller und Server mit Verifizierung
Politik	Wird nur innerhalb jedes Tresors durchgesetzt.	Eine einzige Richtlinien-Engine wird für jede Zertifizierungsstelle und jede Umgebung durchgesetzt.
Prüfnachweis	Auf verschiedene Tresore und manuelle Protokolle verteilt	Zentralisierte, revisionssichere Berichterstattung für das gesamte Portfolio

Häufige Fehler und Hinweise zum Zurücksetzen

Achten Sie beim Verbinden einer CLM-Plattform mit Key Vault auf diese wiederkehrenden Fehlerquellen und halten Sie für jeden Fehler einen Rollback-Pfad bereit.

• Unzureichende Berechtigungen für den Schlüsseltresor: Ein Dienstprinzipal ohne Zertifikat oder Berechtigungen für geheime Geheimnisse schlägt bei der Erneuerung stillschweigend fehl. Überprüfen Sie die Zugriffsrechte (Abrufen/Auflisten/Erstellen/Aktualisieren) vor dem ersten automatisierten Zyklus und halten Sie den vorherigen manuellen Prozess während der Pilotphase als Ausweichmöglichkeit bereit.
• Nicht entdeckte Endpunkte: Wird ein Endpunkt, der ein Zertifikat verwendet, während der Einrichtung nicht zugeordnet, erreicht die automatisierte Bereitstellung ihn nicht, und das alte Zertifikat läuft ab. Überprüfen Sie vor der Produktivsetzung die Endpunktliste aus den Voraussetzungen anhand der Produktionsdatenverkehrsprotokolle.
• Politische Konflikte: Eine Zertifizierungsstelle oder ein Zertifikatsmuster, das nicht den konfigurierten Richtlinien entspricht, wird abgelehnt. Testen Sie die Richtlinienregeln anhand eines repräsentativen Zertifikats jeder verwendeten Zertifizierungsstelle, bevor Sie sie unternehmensweit anwenden.
• Fehler bei der Bereitstellungsprüfung: Kann die Plattform nicht bestätigen, dass ein Zertifikat von einem Endpunkt empfangen wurde, wird dies als fehlgeschlagene und nicht als erfolgreiche Erneuerung behandelt. Stattdessen wird auf das letzte als gültig bekannte Zertifikat zurückgegriffen, anstatt den Endpunkt in einem unbekannten Zustand zu belassen.
• Rollback-Pfad: Das vorherige Zertifikat und der zugehörige private Schlüssel müssen so lange beibehalten werden, bis das neue Zertifikat auf jedem zugeordneten Endpunkt live verifiziert wurde. Das manuelle Erneuerungs-Runbook muss so lange aktiv bleiben, bis mindestens ein vollständiger automatisierter Zyklus erfolgreich abgeschlossen wurde.

Erfolgskennzahlen

Verfolgen Sie diese Kennzahlen nach der Implementierung, um die Funktionsfähigkeit der Orchestrierungsschicht zu bestätigen und den Stakeholdern über den Fortschritt zu berichten. Encryption Consulting veröffentlicht keine einheitlichen Benchmark-Ergebnisse für alle Azure Key Vault-Implementierungen, da die eingesparte Erneuerungszeit und die vermiedenen Tickets je nach Größe und Reifegrad der Umgebung variieren. Teams sollten daher vor dem Rollout eigene Kennzahlen ermitteln und diese vierteljährlich anhand der unten aufgeführten Kategorien überprüfen.

• Zeitersparnis bei der Erneuerung: Durchschnittliche Stunden pro Zertifikat von der Ablauferkennung bis zur verifizierten Bereitstellung, vor und nach der Automatisierung.
• Anzahl der verwalteten Zertifikate: Gesamtzahl der unter Plattformverwaltung stehenden Zertifikate, einschließlich derjenigen, die außerhalb des Key Vaults entdeckt wurden und zuvor nicht erfasst waren.
• Bereitstellungserfolgsrate: Prozentsatz der Verlängerungen, die automatisch ohne manuelles Eingreifen durchgeführt und verifiziert wurden.
• Reduzierung manueller Tickets: Anzahl der Support-Anfragen oder Änderungstickets im Zusammenhang mit Zertifikaten pro Quartal, vor und nach der Automatisierung.
• Ausfallrate: Ausfälle im Zusammenhang mit Zertifikaten pro Quartal, verglichen mit den oben genannten Branchenbasiswerten von 45 % und 37.5 %.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Schlüsselaktion
PKI-Team	Besitzt CA-Integrationen und die Zertifikatsrichtlinie	Verbinden Sie jede verwendete Zertifizierungsstelle mit der Plattform und laden Sie die genehmigten Richtlinienregeln.
Sicherheits Team	Trägt das Risiko aus nicht eingesetzten oder abgelaufenen Zertifikaten.	Stellen Sie sicher, dass die Bereitstellungsbestätigung erzwungen wird und nicht nur die Erneuerung im Key Vault.
Plattform-/DevSecOps-Team	Verantwortlich für Endpunktzuordnung und Bereitstellung auf der letzten Meile	Erstellen Sie eine Liste aller Load Balancer, Ingress-Controller und Server, die ein Zertifikat verwenden.
Compliance-Team	Besitzt die Prüfungsnachweise für das gesamte Portfolio.	Bestätigen Sie, dass die zentrale Berichterstattung Zertifikate außerhalb von Key Vault umfasst, nicht nur innerhalb.

Was macht man als nächstes

• PKI-Teams: Vor Ablauf der 100-tägigen Gültigkeitsphase im März 2027 ist eine Bestandsaufnahme aller im Einsatz befindlichen Zertifizierungsstellen durchzuführen und zu bestätigen, welche davon nicht in die integrierte Partnerliste von Key Vault aufgenommen wurden.
• Sicherheitsteams: Prüfen, ob jemals bestätigt wurde, dass ein im letzten Quartal im Key Vault erneuertes Zertifikat auf seinem Endpunkt bereitgestellt wurde.
• Plattformteams: Führen Sie in diesem Quartal ein Pilotprojekt zur automatisierten Bereitstellung auf der letzten Meile auf Ihrem am stärksten frequentierten Nicht-Azure-Endpunkt durch.
• Compliance-Teams: Bestätigen Sie, dass Ihre Prüfnachweise bereits Zertifikate außerhalb von Key Vault umfassen, oder beheben Sie die Lücke jetzt.

Wie Verschlüsselungsberatung helfen kann

Genau das ermöglicht Encryption Consulting: den Aufbau dieser Orchestrierungsschicht. Wir verfügen sowohl über die Plattform als auch über das Fachwissen, um Azure Key Vault in eine robuste, automatisierte Zertifizierungspraxis zu integrieren.

CertSecure Manager ist unsere Lösung für das Zertifikatslebenszyklusmanagement und wurde als Orchestrierungsschicht über Speichersystemen wie Azure Key Vault entwickelt. Auf G2 hat CertSecure Manager aktuell eine Gesamtbewertung von 4.8 von 5 Sternen basierend auf 3 Rezensionen (Stand: August 2026). Da es sich um ein neueres Angebot mit einer geringen Anzahl an Rezensionen handelt, sollte diese Bewertung eher als Richtwert denn als aussagekräftiger Vergleich betrachtet werden. Die Lösung bietet intelligente Erkennung in Azure, anderen Clouds, On-Premises-Umgebungen und Containerumgebungen und konsolidiert alle Zertifikate in einem zentralen Inventar, sodass keine Informationen verloren gehen.

Die CA-unabhängige, geschlossene Automatisierung übernimmt die Ausstellung, Verlängerung und den Widerruf von Zertifikaten unabhängig davon, welche CA das Zertifikat ausgestellt hat, und transportiert das Zertifikat bis zum Endpunkt, sei es eine Azure-Ressource, ein F5- oder NGINX-Loadbalancer, ein Kubernetes-Ingress oder ein lokaler Server, und validiert anschließend die Bereitstellung.

Die zentrale Richtlinien-Engine setzt genehmigte Zertifizierungsstellen, Schlüssellängen, Algorithmen und Gültigkeitsregeln einheitlich für Ihre gesamte IT-Umgebung durch – inklusive rollenbasierter Zugriffskontrolle und Audit-Trails, die für die Einhaltung der Compliance-Vorgaben erforderlich sind. Dank dieser durchgängigen Automatisierung wird im Rahmen der 47-Tage-Frist ein bisher unüberschaubares Volumen an Verlängerungen zu einem routinemäßigen, automatisierten Prozess, während Key Vault weiterhin als Ihr sicherer Speicher dient.

Um den Schutz weiter auszubauen, erweitert CBOM Secure die Analyse über Zertifikate hinaus auf Ihre gesamte kryptografische Landschaft aus Algorithmen, Schlüsseln und Protokollen. So entsteht die kryptografische Stückliste, die Compliance unterstützt und Sie auf den Übergang nach der Quantentechnologie mit kürzeren Lebensdauern vorbereitet. Unser Leitfaden „CBOM: Vom Inventar zur Analyse “ zeigt Ihnen, wie Sie dieses Inventar in ein kontinuierliches Programm für kryptografische Agilität umwandeln.

Für Organisationen, die Zertifikate von einer Zertifizierungsstelle außerhalb der integrierten Partner von Key Vault benötigen, bietet PKI-as-a-Service eine moderne, skalierbare private Zertifizierungsstelle ohne On-Premises-Overhead oder Anbieterbindung. HSM-as-a-Service schützt die privaten Schlüssel Ihrer Zertifikate durch hochsichere Hardware-Isolation. Die heute getroffenen Entscheidungen bezüglich des Registrierungsprotokolls wirken sich auch auf die Zeit nach der Quantencomputer-Umstellung aus: Unser PQC Center of Excellence und unser 9-phasiger PQC-Readiness -Plan unterstützen Sie bei der Planung Ihrer Krypto-Agilität für die von Ihnen standardisierten Zertifizierungsstellen und Protokolle.

Auf der Beratungsseite hilft unser PKI-Services- Team bei der Konzeption und Modernisierung der unternehmensweiten und Microsoft-PKI, die der Zertifikatsausstellung zugrunde liegt. Unsere Cloud-Datenschutzdienste helfen Ihnen, Daten und Schlüssel in Azure und anderen Clouds zu sichern, und unsere Compliance-Beratungsdienste gewährleisten, dass Ihre Zertifizierungspraktiken PCI-DSS, HIPAA, NIST und anderen Rahmenwerken entsprechen.

Ob Sie mit Verlängerungen zu kämpfen haben, die Key Vault nicht bearbeiten kann, sich auf die 47-Tage-Frist vorbereiten oder eine einheitliche Multi-Cloud-Zertifikatsstrategie entwickeln möchten – Encryption Consulting unterstützt Sie. Kontaktieren Sie uns, um Ihre Azure-Zertifikatprozesse zu analysieren und skalierbare Automatisierungslösungen zu entwickeln.

Weiterführende Lektüre von Encryption Consulting

• Auswahl eines Zertifizierungsregistrierungsverfahrens: ACME vs. EST vs. SCEP vs. CMP umfasst die oben genannten automatisierten Protokolle zur Anbindung von Zertifizierungsstellen außerhalb der integrierten Partnerliste von Key Vault.
• Persistente DCV- und DNS-Konnektoren Beinhaltet die Automatisierung des Domainvalidierungsschritts, der der automatisierten Ausstellung vorausgeht, vor Ablauf der 47-tägigen Frist für das TLS-Zertifikat.
• Der richtige Zeitpunkt, um eine CSR-Meldung zu erstellen umfasst den CSR-Schritt, von dem jede Zertifikatsanforderung in diesem Workflow abhängt.
• Leitfaden zur Migration der Post-Quanten-Kryptographie (9 Phasen) legt den Fahrplan für Krypto-Agilität dar, der auf CA und Protokollstandardisierung folgt.

Fazit

Azure Key Vault eignet sich hervorragend zur Speicherung von Zertifikaten, doch Speicherung ist nicht gleich Verwaltung. Die integrierten Funktionen sind ideal für Zertifikate, die vollständig in Azure gespeichert sind und eine integrierte Zertifizierungsstelle (CA) nutzen. Sobald Ihre Umgebung jedoch weitere CAs, andere Clouds, lokale Systeme oder Endpunkte umfasst, die Zertifikate übertragen und verifizieren müssen – was auf praktisch jedes Unternehmen zutrifft –, stoßen sie an ihre Grenzen.

Die immer kürzer werdende Gültigkeitsdauer von Zertifikaten verwandelt diese Lücke von einem tolerierbaren Ärgernis in ein operatives Risiko. Wenn Zertifikate achtmal jährlich auf Tausenden von Endpunkten erneuert werden müssen, wird jeder manuelle Schritt und jeder nicht erreichbare Endpunkt zu einem potenziellen Ausfall. Die Lösung besteht nicht darin, Key Vault zu ersetzen, sondern es zu optimieren und eine CA-unabhängige CLM-Plattform darüber zu platzieren, um die im Zeitalter der 47-Tage-Zertifikatserneuerung erforderliche Erkennung, durchgängige Automatisierung und einheitliche Governance zu gewährleisten.

Key Vault sollte sich weiterhin auf seine Kernkompetenzen konzentrieren. Eine Orchestrierungsschicht übernimmt den Rest, und die rasante Entwicklung der Kryptographie in den nächsten Jahren wird zu einer routinemäßigen Automatisierung statt zu einem ständigen Problem.

Diese Richtlinien werden alle sechs Monate für dauerhaft gültige Erklärungen wie diese überprüft und sofort aktualisiert, sobald das CA/Browser Forum, Microsoft Azure oder eine wichtige Zertifizierungsstelle die Anforderungen an diese Prozesse ändert.

Häufig gestellte Fragen

Was ist der wichtigste Nutzen der Automatisierung der Zertifikatsverwaltung in Azure Key Vault?

Azure Key Vault bietet zwar sicheren Schutz für die Zertifikatsspeicherung, kann aber keine Zertifikate auf Nicht-Azure-Endpunkten bereitstellen, Zertifikate außerhalb von Azure einsehen oder eine einheitliche Richtlinie in einer Multi-Cloud-Umgebung durchsetzen. Um diese Lücke zu schließen, ist eine CA-unabhängige CLM-Plattform erforderlich, die über Key Vault positioniert ist und die Erkennung, die Automatisierung im geschlossenen Regelkreis sowie die einheitliche Verwaltung übernimmt.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig?

Der Wahlvorschlag SC-081v3 des CA/Browser Forums reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage im Jahr 2026, 100 Tage im Jahr 2027 und 47 Tage im Jahr 2029. Bei diesem Rhythmus generiert ein Bestand von 1,000 Zertifikaten etwa 20 Zertifikatsoperationen pro Tag. Laut der Trust Pulse Survey von DigiCert hatten bereits 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten aufgrund von Zertifikatsproblemen. Ein reiner Speicheransatz kann dieses Volumen nicht bewältigen.

Welche Teams sind für die Umsetzung dieser Richtlinien verantwortlich?

PKI-Teams sind für die CA-Integrationen und die Zertifikatsrichtlinien zuständig; Sicherheitsteams tragen die Verantwortung für das Risiko von Zertifikaten, die zwar erneuert, aber nie bereitgestellt werden; Plattform- und DevSecOps-Teams sind verantwortlich für das Endpunkt-Mapping und die Automatisierung der Bereitstellung auf der letzten Meile; und Compliance-Teams sind für die Audit-Nachweise im gesamten Netzwerk verantwortlich, nicht nur für die im Key Vault gespeicherten Daten. Die obige Verantwortlichkeits-/Aufgabenmatrix zeigt die Aufschlüsselung nach Teams.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle Bereitstellung außerhalb des Key Vaults führt zu Zertifikaten, die zwar im Vault erneuert werden, aber nie den Load Balancer oder Ingress Controller erreichen, der sie benötigt. Zudem ist die Transparenz fragmentiert, wodurch Schattenzertifikate unentdeckt bleiben, und die Richtliniendurchsetzung ist über verschiedene Zertifizierungsstellen und Clouds hinweg inkonsistent. Laut der Trust Pulse Survey von DigiCert waren 37.5 % der Ausfälle direkt auf abgelaufene Zertifikate zurückzuführen – ein Risiko, das mit sinkenden Gültigkeitsdauern steigt.

Wie reduziert Automatisierung das Risiko von Zertifikatsausfällen?

Die Automatisierung schließt die letzte Lücke, indem sie das Ablaufdatum erkennt, die Erneuerung bei der zuständigen Zertifizierungsstelle anfordert, das Zertifikat im Key Vault speichert und es anschließend an den Endpunkt überträgt und die Bindung überprüft – alles ohne einen einzigen manuellen Schritt, der übersehen werden könnte. Die Überprüfung der Bereitstellung wird als integraler Bestandteil einer erfolgreichen Erneuerung und nicht erst im Nachhinein betrachtet. Dadurch wird verhindert, dass ein erneuertes, aber nicht bereitgestelltes Zertifikat einen Ausfall verursacht.

Welche Kennzahlen sollten Teams nach der Implementierung verfolgen?

Erfassen Sie die eingesparte Zeit von der Ablauferkennung bis zur verifizierten Bereitstellung, die Gesamtzahl der verwalteten Zertifikate (einschließlich der außerhalb des Key Vaults gefundenen), die Erfolgsquote der Bereitstellung ohne manuelle Eingriffe, die Reduzierung der Support-Tickets im Zusammenhang mit Zertifikaten sowie die Ausfallrate aufgrund von Zertifikaten im Vergleich zu den Branchenstandards von 45 % bzw. 37.5 %. Berichten Sie diese Ergebnisse vierteljährlich.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Der Zeitplan des CA/Browser-Forums verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage am 15. März 2026, 100 Tage am 15. März 2027 und 47 Tage am 15. März 2029. Da Key Vault allein keine erneuerten Zertifikate für Nicht-Azure-Endpunkte bereitstellen kann, wird eine Umgebung, die bis zum 100-Tage-Zeitpunkt keine Orchestrierungsschicht hinzugefügt hat, nicht mehr mithalten können, sobald der Aktualisierungszyklus 47 Tage erreicht.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Setzen Sie auf eine CA-unabhängige Plattform für den Zertifikatslebenszyklus, wie beispielsweise CertSecure Manager, die Zertifikate in Azure Key Vault, anderen Clouds, lokalen Systemen und Kubernetes-Clustern über eine zentrale Konsole erkennt. Dadurch wird vermieden, Key Vault als alleinige Lösung zu betrachten, und die Transparenz von Richtlinien, Bereitstellung und Auditierung bleibt in hybriden oder Multi-Cloud-Umgebungen einheitlich.

Welche Voraussetzungen müssen vor der Implementierung erfüllt sein?

Vor der Implementierung sollten Sie die Berechtigungen des Azure AD-Dienstprinzipals für jeden relevanten Key Vault, ein aktuelles Zertifikatsinventar einschließlich Zertifikaten außerhalb des Key Vault, CA-Anmeldeinformationen und Integrationsdetails für jede verwendete CA, ein zugeordnetes Endpunktinventar, vereinbarte Richtliniendefinitionen sowie ein definiertes Änderungs- und Rollback-Fenster für den ersten automatisierten Zyklus bestätigen.

Welche Screenshots oder Konfigurationsbeispiele sollten enthalten sein?

Dokumentieren Sie das Dashboard der CLM-Plattform, das die gefundenen Zertifikate und deren Ablaufstatus anzeigt, den Konfigurationsbildschirm für Richtlinien, auf dem die genehmigten Algorithmen und Schlüssellängen festgelegt werden, die CA-Verbindungseinstellungen für jede integrierte CA sowie den Bildschirm für die Endpunktzuordnung, der die Zertifikate mit den Load Balancern oder Ingress Controllern verknüpft, die sie verwenden. Jede dieser Darstellungen enthält einen beschreibenden Alternativtext für Barrierefreiheit und Suchfunktionen.