PQC für Cloud-Umgebungen: Gemeinsame Verantwortung für AWS, Azure und Google Cloud

Kurz gesagt: Die gemeinsame Verantwortung für Post-Quanten-Kryptografie (PQC) in der Cloud lässt sich zwar klar nach bekannten Kriterien aufteilen, die Details variieren jedoch stark je nach Anbieter und Dienst. AWS bietet die klarste Übersicht: AWS KMS, ACM und Secrets Manager unterstützen bereits die hybride ML-KEM-Schlüsselvereinbarung auf Nicht-FIPS-Endpunkten, symmetrische Verschlüsselung ruhender Daten (wie die Standardverschlüsselung von AWS KMS) ist bereits quantenresistent, und die Aktualisierung kundeneigener Ressourcen wie Load Balancer auf eine PQ-fähige TLS-Richtlinie liegt gemäß dem gemeinsamen Verantwortungsmodell von AWS explizit in der Verantwortung des Kunden. Azure und Google Cloud verfolgen jeweils ihre eigenen Zeitpläne und sind nicht einheitlich auf dem gleichen Stand der Bereitschaft für alle Dienste. Für Multi-Cloud-Kunden besteht die praktische Aufgabe darin, jeden Anbieter separat und Dienst für Dienst zu prüfen, anstatt eine einfache Ja/Nein-Frage zu stellen wie „Unterstützt diese Cloud PQC?“, die kein Anbieter ehrlich mit einem Wort beantworten kann.

Cloud-Anbieter migrieren rasant, und es ist verlockend anzunehmen, dass die Migration Ihre Workloads automatisch abdeckt. Das ist jedoch nicht einheitlich der Fall. Dieser Leitfaden erläutert, was die einzelnen großen Anbieter für Sie migrieren, wofür Sie weiterhin verantwortlich sind und wie Sie die Lücken präzise statt auf Basis von Annahmen ermitteln können.

Wichtige Erkenntnisse

• AWS KMS, ACM und Secrets Manager unterstützen bereits die hybride Post-Quantum-Schlüsselvereinbarung von ML und KEM auf Nicht-FIPS-Endpunkten in allen AWS-Regionen in der Standardpartition.
• Die Aktualisierung von kundeneigenen Netzwerkressourcen, wie z. B. Load Balancern, auf eine PQ-fähige TLS-Richtlinie liegt explizit in der Verantwortung des Kunden im Rahmen des Shared-Responsibility-Modells von AWS und ist keine Aufgabe, die AWS automatisch übernimmt.
• Symmetrische Verschlüsselung ruhender Daten, einschließlich der standardmäßigen Schlüsselverschlüsselung von AWS KMS, gilt bereits als quantenresistent und erfordert daher keine separate Migration.
• Die Bereitschaft der Anbieter ist nicht einheitlich für alle Dienste innerhalb derselben Cloud, geschweige denn für alle Anbieter; eine allgemeine Frage „Wird PQC unterstützt?“ deckt nicht die dienstspezifischen Lücken auf, die bei einem Audit relevant sind.
• Ein sinnvolles PQC-Readiness-Audit für verschiedene Cloud-Umgebungen testet die tatsächliche Aushandlung und das API-Verhalten, den hybriden Schlüsselaustausch, die Erstellung von KMS-Signaturschlüsseln und die HSM-Validierungsgrenzen, anstatt sich auf Marketingaussagen über allgemeine Unterstützung zu verlassen.

AWS: Was wurde migriert vs. Was liegt in Ihrer Verantwortung?

AWS hat die bisher betriebsspezifischste PQC-Migrationsanleitung aller großen Anbieter veröffentlicht. Zum Zeitpunkt der Veröffentlichung dieser Anleitung unterstützen AWS KMS-, AWS Certificate Manager- und AWS Secrets Manager-Endpunkte ML-KEM für die hybride Post-Quantum-Schlüsselvereinbarung auf Nicht-FIPS-Endpunkten in allen AWS-Regionen der Standard-AWS-Partition. Diese Funktion wird von AWS transparent bereitgestellt und erfordert keine Maßnahmen seitens des Kunden, um sie auf diesen spezifischen Endpunkten zu nutzen. Symmetrische Algorithmen, die für die Verschlüsselung ruhender Daten verwendet werden, einschließlich der standardmäßigen AWS KMS-Schlüsselverschlüsselung, gelten bereits als quantenresistent und müssen daher nicht migriert werden.

Die verbleibende Kundenverantwortung ist in den AWS-Richtlinien klar definiert: Die Aktualisierung kundeneigener Netzwerkressourcen, wie z. B. Load Balancer, auf eine PQ-fähige TLS-Richtlinie fällt in den Verantwortungsbereich des Kunden im Rahmen des Modells der geteilten Verantwortung. AWS stellt aktualisierte TLS-Richtlinien bereit, die den hybriden ML-KEM-Schlüsselaustausch unterstützen, sowie IAM-Ressourcenkontrollrichtlinien, um eine gewünschte TLS-Richtlinie bei der zukünftigen Ressourcenerstellung durchzusetzen. Die Anwendung dieser Richtlinie auf bestehende Ressourcen ist jedoch eine Kundenaktion und keine automatische Änderung seitens AWS. AWS Private CA und AWS KMS unterstützen gemeinsam Post-Quantum-Funktionen für Zertifikats- und Schlüsselinfrastruktur – auch hier handelt es sich um vom Kunden konfigurierbare Tools und nicht um eine Standardeinstellung, die ohne weiteres Zutun angewendet wird.

Azure und Google Cloud: Unterschiedliche Zeitpläne, aber nicht abwesend

Azure und Google Cloud investieren zwar beide in die Vorbereitung auf die Zeit nach der Quantenzertifizierung, jedoch nicht einheitlich und im gleichen Umfang wie AWS über alle Servicekategorien hinweg (Stand: 2026). Unabhängige Cloud-übergreifende Audits haben beispielsweise ergeben, dass die Dokumentation der verwalteten HSMs von Azure weiterhin auf RSA-, Elliptische-Kurven- und AES-Schlüsseltypen fokussiert ist und nicht auf ML-KEM oder ML-DSA. Dies, obwohl Microsoft bereits an anderer Stelle in der Windows-Plattform Post-Quantenzertifizierungsfunktionen implementiert hat, darunter ML-DSA-Unterstützung in den Active Directory-Zertifikatdiensten. Diese Lücke betrifft einzelne Dienste und sagt nichts über die allgemeine Post-Quantenzertifizierungs- und Zertifizierungsstrategie von Azure aus. Daher ist die Überprüfung jedes einzelnen Dienstes wichtiger als eine Bewertung auf Anbieterebene.

Google Cloud hat einen eigenen detaillierten PQC-Fahrplan veröffentlicht, der die Migration der Vertraulichkeit, die Integrität der Signaturen und die Meilensteine ​​für die einzelnen Dienste umfasst; wir behandeln diesen Fahrplan und seine spezifischen Auswirkungen auf Unternehmenskunden in einem separaten Leitfaden, da er eine eigene detaillierte Betrachtung verdient und nicht nur eine Zusammenfassung hier.

Die wirklich wichtigen Prüfungsfragen

Die Frage „Unterstützt diese Cloud Post-Quanten-Kryptographie?“ ist für ein Audit zu allgemein, da ein Anbieter sie durchaus bejahen kann, weil eine TLS-Bibliothek irgendwo im Stack einen hybriden KEM aushandelt, während ein völlig anderer Dienst in derselben Cloud weiterhin nur klassische Schlüssel ausgibt. Die Fragen, die bei einem Audit tatsächlich Schwachstellen aufdecken, sind spezifischer:

• Kann ich auf dem TLS-Endpunkt dieses spezifischen Dienstes ein NIST-standardisiertes, postquantenverschlüsseltes gemeinsames Geheimnis einrichten?
• Kann das Cloud-KMS einen ML-DSA-Signaturschlüssel erstellen, und wird diese Schlüsselerzeugung und Signierungsoperation innerhalb eines validierten HSM durchgeführt?
• Ist Post-Quantum-TLS lediglich als Option verfügbar oder wird es im Clientpfad, den meine Anwendung im Produktivbetrieb tatsächlich nutzt, automatisch ausgehandelt?
• Welche FIPS 140-2- oder FIPS 140-3-Zertifikatsabhängigkeiten bestehen für diesen spezifischen Dienst, und wie wirkt sich das Auslaufen von FIPS 140-2 im September 2026 darauf aus?

Testen statt annehmen: Erfassen Sie den tatsächlichen TLS-Handshake und die Schlüsselaustauschverhandlung für die von Ihnen genutzten Dienste, nutzen Sie die KMS-Signierungs-, Verifizierungs-, Kapselungs- und Entkapselungs-APIs direkt und testen Sie das Fallback-Verhalten, wenn eine Post-Quantum-Verhandlung nicht verfügbar ist, anstatt sich auf die allgemeine Marketingaussage eines Anbieters über die PQC-Unterstützung zu verlassen.

Erstellung Ihres Inventars gemeinsamer Verantwortung

Ein vollständiges PQC-Inventar für die Cloud umfasst mehr als TLS: Zertifizierungsstellen, Server- und Clientzertifikate, KMS- und HSM-Schlüssel, SSH-Abhängigkeiten, Codesignaturschlüssel, VPN-Konfigurationen, TLS-Terminatoren, Service Meshes und alle externen Schlüsselmanager, die auf den Cloud-eigenen Systemen aufsetzen. Für jedes Element ist zu ordnen, auf welcher Seite der gemeinsamen Verantwortung es liegt, welche Migrationen der Cloud-Anbieter standardmäßig übernimmt, welche eine Konfigurationsänderung beim Kunden erfordern und welche von einer noch nicht implementierten Anbieterfunktion abhängen. Langlebige, sensible Daten benötigen zudem eine eigene Tracking-Ebene, unabhängig von der Infrastrukturkategorie, da Daten mit mehrjährigen Vertraulichkeitsanforderungen unabhängig vom jeweiligen Cloud-Dienst, der sie speichert oder überträgt, dem Risiko des sofortigen Abfangens und späteren Entschlüsselns ausgesetzt sind.

Was wir tatsächlich empfehlen würden

Prüfen Sie jeden Cloud-Anbieter separat und auf Serviceebene, nicht als unternehmensweite Checkliste für die Cloud-PQC-Konformität. Wenden Sie die bereits verfügbaren hybriden TLS-Richtlinien von AWS jetzt auf Ihre Kundenressourcen an, anstatt davon auszugehen, dass die serviceseitigen Fortschritte von AWS diese automatisch abdecken. Verfolgen Sie die Service-für-Service-Bereitschaft von Azure und Google Cloud anhand ihrer jeweiligen Zeitpläne, anstatt Funktionsgleichheit mit AWS anzunehmen. Erstellen Sie Ihr Inventar so, dass Sie anbieterverwaltete Abhängigkeiten explizit von kundenkonfigurierten unterscheiden, denn genau diese Unterscheidung ist der Kern einer echten Prüfung auf gemeinsame Verantwortung.

Wie Verschlüsselungsberatung helfen kann

Die in diesem Leitfaden propagierte dienstbezogene Bestandsaufnahme, die zwischen den von den einzelnen Cloud-Anbietern automatisch migrierten Diensten und den Bereichen, für deren Konfiguration Sie weiterhin verantwortlich sind, unterscheidet, ist genau das, wofür CBOM Secure in Multi-Cloud- und Hybridumgebungen entwickelt wurde: die Zuordnung von Zertifikaten, Schlüsseln und TLS-Konfigurationen zu ihrem vom Anbieter oder vom Kunden verwalteten Status.

Unsere PQC-Beratungsdienste führen die in diesem Leitfaden beschriebenen Auditfragen anhand Ihrer tatsächlichen Cloud-Umgebung durch. Dabei testen wir die reale TLS-Aushandlung und das Verhalten der KMS-API, anstatt uns auf Marketingaussagen von Anbietern zu verlassen. Die so ermittelten Schwachstellen fließen in einen priorisierten, kundenseitigen Behebungsplan ein. Wenn die Zertifikatsausstellung mehrere Cloud-Anbieter umfasst, verwaltet CertSecure Manager klassische, hybride und Post-Quantum-Zertifikate über eine zentrale Richtlinienebene für AWS, Azure und Google Cloud.

Überprüfen Sie die Leitung, gehen Sie nicht davon aus, dass sie in Ordnung ist.

Cloud-Anbieter setzen zunehmend auf Post-Quanten-Kryptografie, und insbesondere AWS hat ein klares Bild davon veröffentlicht, was automatisch migriert wird und was der Kundenkonfiguration überlassen bleibt. Diese Transparenz ist jedoch nicht bei allen Anbietern und Diensten gleichermaßen gegeben. Genau deshalb ist die Frage „Unterstützt meine Cloud PQC?“ die falsche. Die richtige Frage ist dienstspezifisch und testbar: Verhandelt dieser spezielle Endpunkt heute einen validierten hybriden Schlüsselaustausch im Clientpfad meiner Anwendung, und wer ist für die Aktivierung verantwortlich?

Häufig gestellte Fragen

Aktiviert AWS automatisch Post-Quantum-TLS für meine Ressourcen?

Nicht einheitlich. AWS bietet ML-KEM-Hybridunterstützung transparent auf AWS KMS-, ACM- und Secrets Manager-Endpunkten, aber die Aktualisierung kundeneigener Ressourcen wie Load Balancer auf eine PQ-fähige TLS-Richtlinie liegt explizit in der Verantwortung des Kunden im Rahmen des Modells der geteilten Verantwortung.

Muss ich Daten migrieren, die mit der standardmäßigen symmetrischen Verschlüsselung von AWS KMS verschlüsselt wurden?

Nein. Symmetrische Verschlüsselungsalgorithmen, die für die Verschlüsselung ruhender Daten verwendet werden, gelten bereits als quantenresistent und benötigen von sich aus keine Post-Quanten-Migration.

Liegt Azure bei der Post-Quanten-Kryptographie hinter AWS zurück?

Dies variiert je nach Dienst. Unabhängige Prüfungen haben Lücken in bestimmten Bereichen festgestellt, beispielsweise bei der Unterstützung von Azure Managed HSM-Schlüsseltypen. Microsoft hingegen hat andernorts Funktionen nach der Quantenintegration bereitgestellt, darunter ML-DSA-Unterstützung in Active Directory Certificate Services. Prüfen Sie die Bereitschaft jedes einzelnen Dienstes, anstatt die Gesamtsituation eines Anbieters anhand eines einzelnen Dienstes zu beurteilen.

Wie lässt sich am besten testen, ob ein Cloud-Dienst tatsächlich den Post-Quantum-Schlüsselaustausch unterstützt?

Erfassen Sie den tatsächlichen TLS-Handshake für den jeweiligen Endpunkt mithilfe eines Tools wie Wireshark oder den integrierten Entwicklertools Ihres Browsers, anstatt sich auf allgemeine Marketingaussagen eines Anbieters zu verlassen. Bei KMS-Diensten sollten Sie die API für Signierung, Verifizierung, Kapselung oder Entkapselung direkt nutzen, um die Unterstützung von Post-Quanten-Algorithmen zu bestätigen, anstatt dies allein aus der Dokumentation anzunehmen.

Was sollte ein Multi-Cloud-PQC-Inventar umfassen?

Zertifizierungsstellen, Server- und Clientzertifikate, KMS- und HSM-Schlüssel, SSH-Abhängigkeiten, Codesignaturschlüssel, VPN-Konfigurationen, TLS-Terminatoren und Service-Meshes, jeweils zugeordnet der Frage, ob sie vom Anbieter verwaltet, vom Kunden konfiguriert oder von einer noch nicht ausgelieferten Funktion abhängig sind.