Cloudbasierte PKI – GCP, AWS und Azure

Cloudbasierte PKI betreibt Teile oder die gesamte Zertifizierungsstellenhierarchie (CA-Hierarchie) auf AWS-, Azure- oder GCP-Infrastruktur anstatt auf lokaler Hardware. Dies ist wichtig, da die Gültigkeitsdauer von Zertifikaten gemäß dem Gültigkeitszyklus des CA/Browser Forums rapide abnimmt und manuelle, hardwaregebundene PKI nicht mithalten kann. Die empfohlene Vorgehensweise: Halten Sie Ihre Stammzertifizierungsstelle (und idealerweise auch Ihre Richtlinienzertifizierungsstelle) unabhängig von der verwendeten Cloud offline und wählen Sie die Hybridarchitektur, die Ihrem Kontrollbedarf über die ausstellende Zertifizierungsstelle entspricht.

Veröffentlicht: Oktober 2020. Aktualisiert: August 2026. Geprüft vom PKI-Beratungsteam von Encryption Consulting.

Wenn Sie diese Architektur nicht selbst aufbauen und betreiben möchten, vergleicht unser Leitfaden zu PKIaaS-Bereitstellungsmodellen die vollständig verwaltete Alternative. Und falls Sie sich noch bezüglich der HSM-Verwaltung unsicher sind, bietet der Artikel „Dedizierte vs. gemeinsam genutzte HSMs in PKIaaS“ eine detailliertere Betrachtung dieses Abwägungsprozesses.

Was ist Cloud-basierte PKI?

Die Public-Key-Infrastruktur (PKI) umfasst Hardware, Software, Richtlinien und Verfahren zur Erstellung, Verteilung und zum Widerruf digitaler Zertifikate, die die Identität einer Person, eines Geräts oder eines Dienstes in einem Netzwerk nachweisen. Die Kernaufgabe einer PKI ist die Authentifizierung und Vertraulichkeit: Sie ermöglicht es zwei Parteien, einander hinsichtlich ihrer Identität zu vertrauen und die ausgetauschten Daten zu verschlüsseln. Dies wird durch die drei Eigenschaften der sogenannten CIA-Triade gewährleistet : Vertraulichkeit (nur der beabsichtigte Empfänger kann die Daten lesen), Integrität (die Daten wurden während der Übertragung nicht verändert) und Verfügbarkeit (die Systeme zur Ausstellung und Validierung von Zertifikaten sind bei Bedarf verfügbar).

Cloudbasierte PKI bedeutet, dass eine oder mehrere Ebenen der Zertifizierungsstellenhierarchie, meist die ausstellende Zertifizierungsstelle (Issuing CA), auf AWS-, Azure- oder GCP-Infrastruktur anstatt auf eigener Hardware ausgeführt werden. Einige Begriffe tauchen in diesem Vergleich immer wieder auf: Eine Root-CA ist der Vertrauensanker der Hierarchie und wird normalerweise offline gehalten; eine Issuing CA (manchmal auch Subordinate CA genannt) ist die Zertifizierungsstelle, die Endbenutzerzertifikate signiert; eine Policy CA ist eine optionale Zwischenebene, die die von einer Issuing CA auszustellenden Zertifikate einschränkt; ein HSM (Hardware Security Module) ist die manipulationssichere Hardware, die den privaten Schlüssel einer Zertifizierungsstelle generiert und schützt; und CDP, AIA und OCSP sind die Dienste für den Zertifikatssperrungs- und Zertifikatskettenaufbau (CRL Distribution Point, Authority Information Access und Online Certificate Status Protocol), mit denen vertrauende Parteien die Gültigkeit eines Zertifikats überprüfen können.

Warum verlagern Unternehmen ihre PKI in die Cloud?

Unternehmen verlagern ihre Zertifizierungsstellen in die Cloud, um den kapitalintensiven und aufwendigen Hardware-Management-Aufwand gegen einen bedarfsgerecht skalierbaren Service einzutauschen, der den Wartungsaufwand deutlich reduziert. Im Gegensatz zu einer On-Premises-Lösung müssen Sie bei einer Cloud-basierten Zertifizierungsstelle weder ein Hardware-Service-Modul (HSM) installieren noch Betriebssysteme patchen oder Hardware-Aktualisierungszyklen planen. Der Cloud-Anbieter kümmert sich um Verfügbarkeit, Skalierung und die zugrundeliegende Infrastruktur, sodass Sie sich auf die Zertifikatsrichtlinien und die Ausstellung konzentrieren können. Dieser Umstieg ist besonders wichtig für Unternehmen mit unvorhersehbarem Zertifikatswachstum, da eine Cloud-basierte Zertifizierungsstelle einen Anstieg der Registrierungen (z. B. durch eine neue Geschäftseinheit, eine IoT-Flotte oder die Skalierung eines Kubernetes-Clusters) ohne zusätzliche Hardwarebeschaffung bewältigen kann.

Was sind die häufigsten Herausforderungen von Cloud-basierter PKI?

Die meisten Probleme mit Cloud-PKI lassen sich auf fünf wiederkehrende Lücken zurückführen: unklares Design, Ignorieren von HSMs, Auswahl der falschen Cloud für die Anforderungen, schlechte Integration mit der bestehenden Infrastruktur und das Fehlen eines echten Zertifikatslebenszyklusprozesses.

• Schwache PKI-Grundlagen. Teams, die eine echte Entwurfsphase überspringen, neigen auch dazu, Compliance-Anforderungen zu verpassen, wie zum Beispiel die Richtlinien für das kryptografische Schlüsselmanagement gemäß NIST SP 800-57, die vor der Bereitstellung angewendet und nicht erst im Nachhinein entdeckt werden sollen.
• HSMs als optional behandeln. Verzichtet man auf die Speicherung des privaten Schlüssels einer Zertifizierungsstelle auf ein HSM, bedeutet dies, dass die Zertifizierungsstelle nicht FIPS 140 Level 3-konform ist. Punkt. Diese Aussage kann eine rein softwarebasierte Schlüsselspeicherung unabhängig vom Cloud-Anbieter nicht treffen.
• Eine Wolke nach Bequemlichkeit statt nach Passform auswählen. AWS, Azure und GCP unterstützen deutlich unterschiedliche CA-Dienste und HSM-Optionen; die richtige Wahl hängt davon ab, wo Ihre Workloads bereits gehostet werden und welche Compliance-Vorgaben gelten, und nicht davon, mit welcher Konsole Ihr Team zufällig am besten vertraut ist.
• Mangelhafte Integration mit der bestehenden PKI. Eine Cloud-Ausstellungszertifizierungsstelle, die nicht korrekt mit Ihren bestehenden Stamm- und Richtlinienzertifizierungsstellen verknüpft ist, erzeugt eine zweite, voneinander getrennte Hierarchie, anstatt die bereits vertrauenswürdige Hierarchie zu erweitern.
• Kein Zertifikatslebenszyklusprozess. Die Wahl der richtigen Werkzeuge für Erkennung, Ausstellung, Verlängerung und Widerruf ist genauso wichtig wie die CA-Architektur selbst; ein unkontrollierter Zertifikatslebenszyklus führt zu Ausfällen, unabhängig davon, wie gut die zugrunde liegende PKI konzipiert ist.

Wie unterscheiden sich native und externe Schlüsselverwaltungsmodelle für Cloud-PKI?

Verwenden Sie native Cloud-HSM-Speicherung für die ausstellende Zertifizierungsstelle, die skalierbar sein und sich in Cloud-Dienste integrieren muss, und behalten Sie die externe, lokale Speicherung für die Stammzertifizierungsstelle (und in der Regel auch für die Richtlinienzertifizierungsstelle) bei, deren privater Schlüssel niemals über ein Netzwerk erreichbar sein sollte.

Modell	Wo sich der private Schlüssel befindet	Typische Verwendung
Native (Cloud-HSM-Verwahrung)	Generiert und gespeichert innerhalb von AWS CloudHSM (hinter einer privaten ACM-Zertifizierungsstelle), Azure Managed HSM oder GCP Cloud HSM.	Ausstellende Zertifizierungsstelle, die skalierbar sein, sich in Cloud-native Dienste integrieren und große Mengen ausstellen muss.
Importiert (BYOK-Äquivalent)	Schlüsselmaterial, das auf Ihrem eigenen HSM generiert und anschließend in das Cloud-HSM oder eine auf einer Cloud-VM installierte Zertifizierungsstelle importiert wird, die von einem lokalen HSM unterstützt wird.	Die Migration der Identität einer bestehenden Zertifizierungsstelle in die Cloud ohne erneute Vertrauensbildung oder die Erfüllung einer Richtlinie, die vom Kunden generiertes Schlüsselmaterial erfordert
Extern (HYOK-Äquivalent)	Wird niemals in die Cloud importiert; verbleibt auf einem vom Internet getrennten, lokalen HSM, das nur während geplanter Signierstunden verwendet wird.	Root-CA und oft auch Policy-CA sind in jeder Architektur unten aufgeführt.

Der Kompromiss spiegelt die allgemeine Vorgehensweise beim Schlüsselmanagement wider: Die native Cloud-Verwahrung ermöglicht flexible Skalierbarkeit und enge Integration mit Cloud-IAM und -Protokollierung, während die externe Verwahrung die höchste Garantie bietet – ein kompromittiertes Cloud-Konto kann den Schlüssel Ihrer Stammzertifizierungsstelle nicht erreichen –, allerdings auf Kosten eines manuellen, zeremoniellen Prozesses bei jeder Schlüsselverwendung. Unser Leitfaden zur Stammzertifizierungsstellen-Zeremonie beschreibt diesen Prozess in der Praxis.

Wie steuert IAM den Zugriff auf private Cloud-PKI-Schlüssel?

Das IAM-Design einer Cloud-PKI muss die Personen, die die Zertifizierungsstelle selbst verwalten, von den Personen und Systemen trennen, die lediglich ein Zertifikat anfordern müssen, und zwar mit dem Identitätssystem, das die zugrunde liegende Cloud bereits bereitstellt.

• AWS: IAM-Richtlinien steuern, wer die ACM Private CA und CloudHSM APIs aufrufen darf, während CloudHSM zusätzlich eigene Krypto-Beauftragten- und Krypto-Benutzerrollen innerhalb des HSM durchsetzt. Daher reicht eine AWS IAM-Berechtigung allein nicht aus, um den Schlüssel zu verwenden.
• Zu: Azure RBAC regelt, wer die unterstützenden Ressourcen der Zertifizierungsstelle verwalten darf, während Managed HSM ein separates, lokales RBAC-Modell erzwingt, das selbst Azure-Abonnementadministratoren systembedingt nicht überschreiben können.
• GCP: Cloud IAM-Rollen mit Geltungsbereich Cloud HSM und Certificate Authority Service steuern sowohl administrative Aktionen (Erstellen oder Deaktivieren einer CA) als auch Ausstellungsaktionen (Anfordern eines Zertifikats), und Google empfiehlt, diese beiden Rollensätze getrennt zu halten.

Ein praktischer Ansatz nach dem Prinzip der minimalen Privilegien folgt auf allen drei Cloud-Typen denselben fünf Schritten:

1. Erstellen Sie ein Verzeichnis aller Identitäten, ob Personen oder Dienste, die aktuell über irgendeine Berechtigung verfügen, die mit der CA oder ihrem HSM in Berührung kommt.
2. Die Rolle „kann die Zertifizierungsstelle verwalten“ (erstellen, deaktivieren, rotieren) und die Rolle „kann ein Zertifikat anfordern“ sollen getrennt werden. Beiden Rollen soll keine Identität zugewiesen werden.
3. Jede Förderung muss auf die jeweilige CA- oder HSM-Ressource beschränkt sein, niemals darf ein Platzhalter für alle CAs im Konto, Abonnement oder Projekt verwendet werden.
4. Für jede Aktion, die eine Zertifizierungsstelle deaktivieren oder löschen kann, ist ein Workflow mit privilegiertem Zugriff und idealerweise die Zustimmung mehrerer Parteien erforderlich.
5. Überprüfen Sie CA-bezogene IAM-Zuweisungen in einem festen vierteljährlichen Rhythmus, da eine Abweichung von den Zugriffsrechten hier direkt zu einer fehlerhaften Zertifikatsausstellung führen kann.

Was sind die Cloud-basierten PKI-Architekturmodelle?

Vier Architekturen decken den Großteil der Cloud-PKI-Implementierungen ab und unterscheiden sich hauptsächlich darin, wie viele Ebenen existieren und wie viel der Hierarchie lokal verbleibt.

Modell	Struktur	Optimale Bildschirmwahl
Einfaches Modell	Root-CA lokal und offline; eine einzelne ausstellende CA in der Cloud, unterstützt durch ein Cloud-HSM	Kleinräumige Implementierungen, bei denen eine ausstellende Zertifizierungsstelle alle Zertifikatsanfragen bearbeiten kann.
Zweistufiges Hybridmodell	Root-CA lokal und offline; zwei ausstellende CAs, eine lokal und eine in der Cloud, beide online	Organisationen, die neben Cloud-Workloads noch über eine bedeutende lokale Infrastruktur (Arbeitsplatzauthentifizierung, Domänenzertifikate) verfügen
Dreistufiges Modell	Root-CA lokal und offline; eine Policy-CA (ebenfalls offline) schränkt explizit ein, was die ausstellende Cloud-CA ausstellen kann.	Teams, die eine strenge, nachvollziehbare Kontrolle über die Ausstellungsrichtlinien benötigen und gleichzeitig die Cloud-Infrastruktur für die ausstellende Zertifizierungsstelle nutzen möchten.
Dreistufiges Hybridmodell	Root-CA und Policy-CA lokal und offline; zwei ausstellende CAs, eine lokal und eine in der Cloud, die jeweils von derselben Policy-CA verwaltet werden	Organisationen, die eine Kontrolle auf Richtlinienebene sowohl für die lokale als auch für die Cloud-basierte Ausstellung benötigen

Einfaches Modell:

Zweistufiges Hybridmodell:

Dreistufiges Modell:

Dreistufiges Hybridmodell:

Eine auf AWS Certificate Manager Private CA basierende ausstellende Zertifizierungsstelle speichert beispielsweise ihren privaten Schlüssel im Hintergrund in AWS CloudHSM; das gewählte Modell bestimmt, ob es sich um die einzige Zertifizierungsstelle in der Hierarchie handelt (Simple) oder um eine von mehreren, von denen jede einen definierten Geltungsbereich hat (die Hybrid- und die dreistufige Variante).

Wie sollte die Zertifikats- und CA-Schlüsselrotation in einer Cloud-PKI gehandhabt werden?

Die Gültigkeitsdauer des Blattzertifikats und die Rotation des CA-Schlüssels laufen auf völlig unterschiedlichen Uhren, und es ist ein häufiger Planungsfehler, sie als das gleiche Problem zu behandeln.

• Gültigkeit des Blattzertifikats Die Gültigkeitsdauer wird durch den vom CA/Browser Forum veröffentlichten Ablaufplan festgelegt: maximal 200 Tage heute, sinkend auf 100 Tage am 15. März 2027 und auf 47 Tage am 15. März 2029. Bei einer Gültigkeitsdauer von 47 Tagen ist eine manuelle Verlängerung in nennenswertem Umfang nicht praktikabel, weshalb eine ACME-basierte Automatisierung für jede ausstellende Zertifizierungsstelle gemäß diesem Zeitplan praktisch obligatorisch ist.
• CA-Tastenrotation Der Vorgang folgt einem deutlich längeren Zyklus, der an die Gültigkeitsdauer der Stamm- oder ausstellenden Zertifizierungsstelle (üblicherweise 10 bis 20 Jahre für eine Stammzertifizierungsstelle, 3 bis 5 Jahre für eine ausstellende Zertifizierungsstelle) und die Kosten für die Durchführung einer neuen Schlüsselerneuerung gekoppelt ist, nicht an den Zertifikatszyklus des CA/Browser-Forums. Die Rotation eines CA-Schlüssels erfordert die Generierung eines neuen Schlüsselpaares, die Ausstellung eines neuen CA-Zertifikats und die erneute Verkettung aller abhängigen Zertifikate. Daher ist sie bewusst geplant und nicht wie die Erneuerung von Endzertifikaten automatisiert.

Was sollte in einer Cloud-basierten PKI protokolliert und überwacht werden?

Jede Ebene einer Cloud-PKI – die Zertifizierungsstelle selbst, das HSM zum Schutz ihres Schlüssels und die Cloud-Plattform, auf der beide gehostet werden – benötigt eine eigene Protokollierung, bevor das erste Zertifikat ausgestellt wird.

• Protokolle auf CA-Ebene: Jede Ausstellung, jeder Widerruf und jede Richtlinienänderung sollte unter Angabe der anfragenden Identität protokolliert werden, unabhängig davon, in welcher Cloud die Zertifizierungsstelle gehostet wird.
• Protokolle auf HSM-Ebene: AWS CloudTrail erfasst CloudHSM- und ACM Private CA-API-Aufrufe, Azure Monitor erfasst Managed HSM-Operationen über seine Diagnoseeinstellungen und GCP Cloud Audit Logs erfasst Cloud HSM- und Zertifizierungsstellendienstaktivitäten. In allen drei Fällen müssen diese Daten explizit an ein SIEM weitergeleitet werden und dürfen nicht im Standard-Aufbewahrungszeitraum verbleiben.
• Kontrollen mit Publikumskontakt: Certificate Transparency Logs bieten Ihnen eine unabhängige, nur erweiterbare Aufzeichnung aller öffentlich vertrauenswürdigen Zertifikate, die unter Ihren Domains ausgestellt wurden. Es lohnt sich, diese auch für Zertifikate zu überwachen, die Sie nicht ausstellen wollten.

Warnungen sollten insbesondere bei Exportversuchen von CA-Schlüsseln, unerwarteter Zertifikatsausstellung außerhalb des normalen Registrierungsworkflows und jeder Änderung der Ausstellungsbeschränkungen einer Policy-CA ausgegeben werden, da dies Ereignisse sind, die den routinemäßigen PKI-Betrieb in einen Vorfall verwandeln.

Wie schneiden AWS, Azure und GCP im Kostenvergleich für Cloud-basierte PKI ab?

Cloudbasierte PKI ersetzt den Großteil der hohen Vorabkosten einer On-Premises-Implementierung durch wiederkehrende HSM- und CA-Servicegebühren, die sich nach der Nutzung richten und nicht nach der Mitarbeiterzahl oder Hardware-Erneuerungszyklen.

Kostentreiber	Näherungsmodell
AWS (ACM Private CA + CloudHSM)	ACM Private CA berechnet die Gebühren pro Zertifizierungsstelle und Monat zuzüglich der Ausstellungsgebühren pro Zertifikat; CloudHSM berechnet die Gebühren pro HSM-Instanz und Stunde, falls Sie eine dedizierte HSM-Steuerung benötigen, die über die verwaltete Option von ACM PCA hinausgeht.
Azure (Managed HSM)	Die Abrechnung erfolgt pro HSM-Pool und Stunde statt pro Schlüssel. Üblicherweise liegen die Kosten für den Standardtarif bei etwa 3 bis 3.20 US-Dollar pro Stunde, unabhängig vom Zertifikatsvolumen.
GCP (Cloud HSM + Zertifizierungsstellendienst)	Ein Cloud-HSM für einen einzelnen Mandanten kostet pauschal etwa 3,500 US-Dollar pro Monat und beinhaltet eine große Anzahl wichtiger Versionen ohne zusätzliche Kosten; der Zertifizierungsstellendienst erhebt zusätzlich eigene Gebühren pro Zertifizierungsstelle und Zertifikat.
Lokale PKI (zum Vergleich)	Unser eigenes Aufschlüsselung der internen PKI-Kosten Die Gesamtkostenlücke beläuft sich damit auf etwa 300,000 US-Dollar mehr als bei einem vergleichbaren Managed Service, wenn HSMs, PKI-Engineering-Personal, Root-Zeremonien und Audits berücksichtigt werden.

Die oben genannten Cloud-Zahlen sind als Richtwerte zu verstehen. Bitte prüfen Sie die aktuellen regionalen Preise, bevor Sie ein Budget erstellen. Der aussagekräftigere Vergleich ist struktureller Natur: Cloudbasierte PKI wandelt die meisten PKI-Kosten in eine vorhersehbare, nutzungsabhängige Gebühr um, während On-Premises-PKI die Kosten auf große, seltene Investitionsereignisse konzentriert (HSM-Käufe, Root-Zeremonien, Hardware-Aktualisierungen).

Wie sieht eine Multi-Cloud-PKI-Architektur auf Cloud-Basis aus?

Die gleichzeitige Ausführung von PKI über GCP, AWS und Azure hinweg erweitert das dreistufige Hybridmodell, anstatt es zu ersetzen: Eine Offline-Root-CA und eine Policy-CA bilden weiterhin den Anker der Hierarchie, und jede Cloud erhält ihre eigene Issuing CA, die auf die dort tatsächlich ausgeführten Workloads beschränkt ist.

Der häufigste Fehler, den wir beobachten, ist nicht architektonischer Natur, sondern liegt in der Governance: Drei unabhängig voneinander von drei verschiedenen Cloud-Teams bereitgestellte Zertifizierungsstellen (CAs) mit jeweils eigenen Zertifikatsprofilen, Rotationsgewohnheiten und Protokollierungseinstellungen driften auseinander, bis ein Auditor (oder ein Ausfall) eine Angleichung erzwingt. Die vollständige Referenzarchitektur und Informationen zur Vermeidung dieser Abweichung finden Sie in unserem Leitfaden zur Multi-Cloud-PKIaaS-Architektur für AWS, Azure und GCP.

Was sind die Einschränkungen von Cloud-basierter PKI?

• Die Sicherheit der Stammzertifizierungsstelle hängt weiterhin vom Prozess ab, nicht von der Cloud. Die Verlagerung einer ausstellenden Zertifizierungsstelle in die Cloud trägt nicht zur Sicherheit einer Stammzertifizierungsstelle bei, die weiterhin nachlässig vor Ort verwaltet wird; die Offline- und zeremonienorientierte Disziplin muss unabhängig davon beibehalten werden, wo sich der Rest der Hierarchie befindet.
• Cloudübergreifende Konsistenz ist nicht automatisch. AWS, Azure und GCP stellen CA- und HSM-Dienste jeweils unterschiedlich bereit, daher müssen Zertifikatsprofile, Rotationsrichtlinien und Protokollierungsformate über alle Clouds hinweg bewusst standardisiert werden; dazu wird Ihnen nichts gezwungen.
• Anbieterabhängigkeit auf der HSM-Ebene. Die in einem HSM einer Cloud generierten Schlüsseldaten einer Zertifizierungsstelle lassen sich nicht einfach in ein HSM einer anderen Cloud übertragen; eine spätere Migration erfordert eine neue Schlüsselzeremonie, kein einfaches Lift-and-Shift.
• Der 47-tägige Gleitpfad ist eine zwingende Voraussetzung für die Automatisierung, keine bloße Präferenz. Jedes Cloud-PKI-Design, das von einer manuellen Zertifikatserneuerung ausgeht, wird scheitern, sobald die kürzeren Gültigkeitsdauern des CA/Browser-Forums in Kraft treten.

Entscheidungscheckliste: Auswahl einer Cloud-basierten PKI-Architektur

1. Vergewissern Sie sich, dass Ihre Stammzertifizierungsstelle (und gegebenenfalls Ihre Richtlinienzertifizierungsstelle) unabhängig vom unten gewählten Modell lokal, offline und zeremoniell gesteuert bleibt.
2. Wenn Ihre Infrastruktur vollständig cloudnativ ist, beginnen Sie mit dem einfachen Modell; wenn Sie noch über eine sinnvolle On-Premises-Infrastruktur verfügen, verwenden Sie stattdessen das zweistufige Hybridmodell.
3. Fügen Sie eine Policy-CA (das Drei-Tier- oder Drei-Tier-Hybridmodell) nur dann hinzu, wenn Sie explizite, überprüfbare Einschränkungen für das benötigen, was eine ausstellende CA ausstellen kann, nicht standardmäßig.
4. Ordnen Sie Ihren Zertifikatserneuerungsprozess der aktuellen Gültigkeitsdauer des CA/Browser Forums zu und betrachten Sie die ACME-basierte Automatisierung als Voraussetzung und nicht als zukünftige Verbesserung.
5. Wenn Sie heute mehr als eine Cloud betreiben oder dies planen, entwerfen Sie die Multi-Cloud-Governance-Schicht, die gemeinsamen Zertifikatsprofile, die konsistente Rotationsrichtlinie und die einheitliche Protokollierung, bevor jedes Cloud-Team seine eigene ausstellende Zertifizierungsstelle unabhängig bereitstellt.

Was würde Encryption Consulting empfehlen?

Für die meisten Organisationen empfehlen wir den Einstieg mit dem dreistufigen Hybridmodell: Eine Offline-Root- und Policy-CA bildet das Fundament der Hierarchie, ergänzt durch Cloud-basierte Issuing-CAs, die pro Workload und Cloud-Umgebung konfiguriert sind. Der häufigste Fehler liegt nicht in der Wahl von AWS, Azure oder GCP, sondern im Verzicht auf die Policy-CA und die damit verbundene Governance. Diese verhindert jedoch, dass eine Multi-Cloud-PKI in drei voneinander getrennte und inkonsistent verwaltete Hierarchien zerfällt. Wenn Sie Ihre Infrastruktur selbst aufbauen, übernehmen unsere PKI-as-a-Service- und HSM-as-a-Service -Angebote die risikoreichsten Komponenten wie HSM-Verwaltung, Root-Zeremonien und Zertifikatsprofil-Governance, während Sie die Kontrolle über die Ausstellungsrichtlinien behalten.

Häufig gestellte Fragen

Kann ich eine einzige Stammzertifizierungsstelle für AWS, Azure und GCP verwenden?

Ja, und das ist die empfohlene Vorgehensweise. Ihre Stammzertifizierungsstelle bleibt lokal und offline, unabhängig von der Cloud. Jede Cloud erhält dann ihre eigene ausstellende Zertifizierungsstelle, die mit derselben Stammzertifizierungsstelle verknüpft ist (gegebenenfalls über eine Richtlinienzertifizierungsstelle). Dadurch ist das Vertrauen einheitlich, obwohl die Ausstellung an drei separaten Orten erfolgt.

Benötige ich ein dediziertes HSM, wenn ich bereits einen verwalteten CA-Dienst wie AWS ACM Private CA verwende?

Nicht unbedingt. ACM Private CA speichert seinen privaten Schlüssel bereits im Hintergrund in AWS CloudHSM, sodass Sie HSM-gestützte Verwahrung erhalten, ohne einen separaten CloudHSM-Cluster bereitstellen zu müssen. Ein dediziertes HSM ist sinnvoll, wenn Sie die Kontrolle über das HSM selbst benötigen, beispielsweise aufgrund spezifischer Compliance-Vorgaben, benutzerdefinierter Schlüsselzeremonien oder Workloads außerhalb von ACM Private CA, die dasselbe HSM nutzen müssen.

Wie oft sollte ich den privaten Schlüssel meiner Zertifizierungsstelle im Vergleich zu den Zertifikaten meiner Endbenutzer austauschen?

Diese Zertifikate haben unterschiedliche Gültigkeitsdauern und sollten nicht verwechselt werden. Endbenutzerzertifikate folgen nun dem verkürzten Gültigkeitszyklus des CA/Browser-Forums (derzeit 200 Tage, bis März 2029 nur noch 47 Tage) und müssen automatisch erneuert werden. Der Schlüssel einer Zertifizierungsstelle (CA) selbst wird in der Regel deutlich seltener, etwa alle Jahre, erneuert. Dies hängt von der Gültigkeitsdauer des Zertifikats und den Kosten für die Durchführung einer neuen Schlüsselerneuerung ab.

Ist die Cloud-basierte PKI FIPS 140-3-konform?

Das ist möglich, die Konformität hängt jedoch von der gewählten HSM-Option ab, nicht generell vom Cloud-Anbieter. Die Verwendung eines rein softwarebasierten Schlüsselspeichers anstelle einer HSM-gestützten Zertifizierungsstelle (CA) bedeutet, dass die CA unabhängig vom verwendeten Cloud-Anbieter nicht FIPS 140 Level 3-konform ist. Prüfen Sie daher den spezifischen Validierungsgrad des von Ihnen eingesetzten HSM-Dienstes (CloudHSM, Managed HSM oder Cloud HSM).

Was geschieht mit meiner PKI, wenn ich später eine vierte Cloud hinzufüge oder eine Arbeitslast wieder lokal verschiebe?

Wenn Ihre Stammzertifizierungsstelle (und Richtlinienzertifizierungsstelle) von Anfang an lokal und offline betrieben wurde, ist das Hinzufügen einer neuen ausstellenden Zertifizierungsstelle – egal ob in einer vierten Cloud oder wieder lokal – lediglich eine Frage der Verknüpfung einer neuen untergeordneten Zertifizierungsstelle mit Ihrer bestehenden Stammzertifizierungsstelle, ohne dass das Vertrauen von Grund auf neu aufgebaut werden muss. Dies ist der Hauptgrund, warum wir empfehlen, den Vertrauensanker von vornherein nicht auf eine einzelne Cloud zu beschränken.

Haben Sie eine konkrete Frage zur Cloud-PKI-Architektur oder -Migration? Kontaktieren Sie unser Team unter [email protected].