Was die PQC-Roadmap von Google Cloud bis 2029 für Unternehmenskunden bedeutet

Kurz gesagt: Googles Post-Quantum-Roadmap für Cloud, die erstmals am 25. März 2026 angekündigt wurde, gliedert sich in drei Bereiche mit unterschiedlichen Fristen: Vertraulichkeit und der Schutz vor Daten, die erst gespeichert und später entschlüsselt werden sollen, sind bis Ende 2027 geplant; Integrität und Nichtabstreitbarkeit (digitale Signaturen, Zertifikate, Identität) sollen bis Ende 2028 abgeschlossen sein; und kryptografische Grundlagen (Schlüsselmanagement, Hardware, Agilität) sollen ebenfalls bis Ende 2028 fertiggestellt und bis 2029 vollständig einsatzbereit sein. Einige Komponenten sind bereits im Einsatz: Cloud KMS ist allgemein verfügbar für ML-KEM, ML-DSA und SLH-DSA, und Google Cloud API-Endpunkte sowie unterstützte Load Balancer ermöglichen bereits den hybriden ML-KEM-Schlüsselaustausch. Die wichtigste Kundenabhängigkeit: Google migriert seine eigene Infrastruktur und seine verwalteten Dienste, aber die kundenseitige TLS-Konfiguration, die Kryptografie auf Anwendungsebene und jede Clientbibliothek, die noch ausschließlich auf klassischen Algorithmen basiert, bleibt in der Verantwortung des Kunden – die gleiche Aufteilung der gemeinsamen Verantwortung, die auch in unserem umfassenderen Cloud-PQC-Leitfaden behandelt wird.

Eine Roadmap mit dem Datum 2029 wird leicht als „noch nicht dringlich“ interpretiert. Diese Interpretation verkennt jedoch den Sinn einer gestaffelten Roadmap: Der Abschnitt zur Vertraulichkeit wird Ende 2027 als erster abgeschlossen, da das Risiko des „Speicherns und späteren Entschlüsselns“ bereits heute besteht. Dieser Leitfaden erläutert die Roadmap und zeigt auf, was sie tatsächlich umfasst, was bereits umgesetzt ist und was Unternehmenskunden unabhängig von Googles Zeitplan unternehmen müssen.

Wichtige Erkenntnisse

• Der Fahrplan gliedert sich in drei Bereiche: Vertraulichkeit (Ende 2027), Integrität und Nichtabstreitbarkeit (Ende 2028) sowie kryptografische Grundlagen (Ende 2028), wobei die vollständige Einsatzbereitschaft für 2029 angestrebt wird.
• Cloud KMS unterstützt bereits generell ML-KEM, ML-DSA und SLH-DSA für Verschlüsselungs- und Signaturschlüssel; Google Cloud API-Endpunkte und unterstützte Load Balancer verhandeln bereits einen hybriden ML-KEM-Schlüsselaustausch.
• Google verfolgt die Entwicklung von Merkle-Tree-Zertifikaten in Zusammenarbeit mit Industriepartnern als Alternative zur direkten Einbettung großer Post-Quantum-Signaturen in X.509-Zertifikate.
• Googles eigene Verantwortung umfasst den Netzwerkverkehr, globale Frontends, das interne ALTS-Protokoll sowie die zugrunde liegende Hardware und die Betriebssysteme; vom Kunden konfigurierte TLS-Richtlinien, Kryptografie auf Anwendungsebene und Clientbibliotheken bleiben in der Verantwortung des Kunden.
• Googles Ziel, die Technologie im Jahr 2029 fertigzustellen, deckt sich nun mit dem von Cloudflare und einem überarbeiteten, beschleunigten Zeitplan von Microsoft. Damit ist 2029 ein gemeinsamer Branchenmaßstab und nicht mehr das isolierte Datum eines einzelnen Anbieters.

Die drei Handlungsstränge und warum die Vertraulichkeit an erster Stelle steht

Google Cloud priorisiert in seiner Roadmap bewusst die Vertraulichkeit vor der Integrität. Diese Begründung ist entscheidend für die Priorisierung der eigenen Arbeit durch die Kunden. Das Risiko, Daten zu speichern und später zu entschlüsseln – ein Angreifer, der verschlüsselten Datenverkehr abfängt, um ihn mit einem kryptografisch geeigneten Quantencomputer zu entschlüsseln –, ist bereits real. Daher hat der Bereich Vertraulichkeit, der Netzwerkverschlüsselung und Schlüsselaustausch umfasst, die früheste Frist: Ende 2027. Integrität und Nichtabstreitbarkeit – digitale Signaturen, Zertifikate und Authentifizierungsmechanismen, die gefälschte Identitäten oder manipulierte Daten verhindern – haben hingegen bis Ende 2028 Zeit. Dies spiegelt sowohl die geringere unmittelbare Dringlichkeit wider (eine gefälschte Signatur erfordert einen aktiven Angriff, nicht nur abgefangene Daten) als auch die deutlich komplexere technische Herausforderung, die die Migration von Signaturen in einem Zertifikatsökosystem darstellt. Grundlagenarbeit – Schlüsselverwaltungsbibliotheken, Hardware-Sicherheitsmodule, Integration externer Schlüsselmanager und kryptografische Flexibilität – wird ebenfalls bis Ende 2028 fortgesetzt, da sie die Grundlage für die beiden anderen Bereiche bildet und nicht isoliert betrachtet werden kann.

Was bereits live ist

Einige Punkte der Roadmap sind keine zukünftigen Verpflichtungen; sie sind bereits ab 2026 allgemein verfügbare Funktionen:

• Cloud KMS: Allgemein verfügbare Unterstützung für ML-KEM, ML-DSA und SLH-DSA sowohl für Verschlüsselungs- als auch für Signaturschlüssel, wobei die zugrunde liegenden Implementierungen als Open Source über Googles BoringCrypto- und Tink-Bibliotheken zur Gewährleistung der Nachvollziehbarkeit gepflegt werden.
• Google Cloud API-Endpunkte und Load Balancer: google.com und *.googleapis.com sowie unterstützte Anwendungs- und Proxy-Loadbalancer verhandeln bereits einen hybriden ML-KEM-Schlüsselaustausch, einschließlich X25519MLKEM768 für TLS 1.3.
• ALTERNATIVEN: Googles internes Anwendungsschicht-Transportprotokoll schloss den Übergang zur Post-Quanten-Vertraulichkeit im Jahr 2025 ab.
• Quantensicherer Schlüsselimport in Cloud KMS: Ziel ist das Jahr 2026 im Rahmen des Grundlagenprogramms.

Noch in der nahen Zukunft auf der Roadmap: Cloud VPN und Interconnect (2026-2027), Private CA über Certificate Authority Service (2027) und Cloud HSM und Confidential Computing Post-Quantum-Unterstützung (2028).

Merkle-Baum-Zertifikate: Ein anderer Ansatz für PKI

Eine strukturelle Entscheidung in Googles Roadmap verdient besondere Beachtung: Anstatt Post-Quanten-Signaturen direkt in das bestehende X.509-Zertifikatformat einzubetten – ein Ansatz, der die Zertifikats- und Kettengrößen erheblich vergrößert –, entwickelt Google gemeinsam mit Industriepartnern Merkle-Baum-Zertifikate. Diese alternative Zertifikatsarchitektur ist von Grund auf auf die Anforderungen der Post-Quanten-Technologie ausgelegt und nicht nur eine nachträgliche Anpassung des klassischen Formats. Es handelt sich hierbei noch um einen sich entwickelnden Ansatz und nicht um einen direkten Ersatz für X.509. Kurzfristig ändert sich dadurch nichts an den Anforderungen der Kunden hinsichtlich ihrer eigenen Zertifikatsinfrastruktur. Das Ergebnis ist jedoch ein Zeichen dafür, dass die größten Cloud- und CDN-Betreiber bei der Signaturentwicklung nicht nur Algorithmen, sondern auch Innovationen im Zertifikatsformat selbst in den Vordergrund stellen.

Was bleibt in der Verantwortung des Kunden?

Googles Darstellung der Aufteilung der Verantwortung ist eindeutig: Google verwaltet die Sicherheit der Cloud, einschließlich Netzwerkverkehr, globaler Frontends, ALTS sowie der zugrunde liegenden Hardware und Betriebssysteme. Die Hardwareintegrität wird durch quantensichere Silizium-Grundlagen wie Caliptra und OpenTitan gewährleistet. Kunden sind weiterhin für die Konfiguration ihrer Workloads verantwortlich, um die von Google bereitgestellten Post-Quanten-Funktionen zu nutzen, die TLS-Konfiguration auf Anwendungsebene, Clientbibliotheksversionen und jegliche im eigenen Code implementierte Kryptografie, anstatt sie an einen verwalteten Google-Dienst zu delegieren. Dies entspricht der Unterscheidung, die in unserem Leitfaden zur Cloud-Verantwortlichkeit allgemeiner erläutert wird : Ein Anbieter, der seine eigene Infrastruktur migriert, migriert nicht automatisch die Abhängigkeiten der Anwendungsebene eines Kunden.

Was wir tatsächlich empfehlen würden

Priorisieren Sie Ihre eigenen Maßnahmen zur Gewährleistung der Vertraulichkeit, die TLS-Konfiguration und den Schlüsselaustausch vor den Maßnahmen zur Signaturerstellung und orientieren Sie sich dabei an Googles eigener Sequenzierungslogik, da die Gefahr einer Offenlegung von Daten durch Speicherung und spätere Entschlüsselung das kurzfristigste Risiko darstellt. Prüfen Sie, welche Cloud-KMS-Schlüssel in Ihrer Umgebung bereits ML-KEM oder ML-DSA verwenden und welche noch auf klassischen Algorithmen basieren, da die allgemeine Verfügbarkeit dieser Funktionen nicht automatisch bedeutet, dass Ihre bestehenden Schlüssel entsprechend umgestellt wurden. Verfolgen Sie die Meilensteine ​​für Googles Private CA und Cloud HSM nach der Quantenintegration, insbesondere wenn Ihre Architektur von einem dieser beiden abhängt, da diese erst später im Fahrplan veröffentlicht werden als die API- und Load-Balancer-Funktionen.

Wie Verschlüsselungsberatung helfen kann

Zu wissen, welche Ihrer Google Cloud KMS-Schlüssel, Load-Balancer-TLS-Richtlinien und Zertifikatsabhängigkeiten bereits Post-Quantum-fähig sind und bei welchen Sie noch aktiv werden müssen, ist genau die Bestandslücke, die CBOM Secure schließen soll, indem es Ihren kryptografischen Fußabdruck in der Cloud mit dem abgleicht, was Google Cloud bereits migriert hat und was noch nicht.

Unsere PQC-Beratungsdienste erstellen eine kundenseitige Roadmap, die auf den dreistufigen Zeitplan von Google Cloud abgestimmt ist. So werden Ihre Maßnahmen zur Gewährleistung der Vertraulichkeit rechtzeitig vor dem kritischen Zeitpunkt der Datenspeicherung und -entschlüsselung abgeschlossen, und Ihre Signaturmaßnahmen sind fertig, bevor die Meilensteine ​​für Googles private Zertifizierungsstelle und Zertifikate erreicht sind. Wenn die Zertifikatsausstellung Google Cloud und andere Umgebungen umfasst, verwaltet CertSecure Manager klassische, hybride und Post-Quantum-Zertifikate über eine zentrale Richtlinienebene.

Ein Zeitplan des Anbieters, keine Frist für den Kunden.

Die Roadmap von Google Cloud gibt an, wann die Google-Infrastruktur selbst für Post-Quantum-Computing bereit sein wird. Sie sagt jedoch nicht aus, wann Ihre Anwendung, Ihre Zertifikatskette oder Ihre spezifische Cloud-KMS-Schlüsselkonfiguration bereit sein werden, da dies weiterhin in der Verantwortung des Kunden liegt, unabhängig davon, wie schnell Google Fortschritte erzielt. Die dreistufige Priorisierung – Vertraulichkeit an erster Stelle, Signaturen und Grundlagen im Anschluss – ist der beste Weg, die Roadmap eines Anbieters in Ihren eigenen Migrationsplan zu übersetzen.

Häufig gestellte Fragen

Wann hat Google Cloud seine Roadmap für die Zeit nach der Quantentechnologie bekannt gegeben?

Google kündigte das unternehmensweite Ziel für 2029 erstmals am 25. März 2026 an; die detaillierte dreigleisige Roadmap und die eigenen Meilensteine ​​wurden kurz darauf veröffentlicht.

Warum hat das Verfahren zur Vertraulichkeit eine frühere Frist als das Verfahren zur Unterzeichnung?

Das Risiko, verschlüsselten Netzwerkverkehr zu speichern und später zu entschlüsseln, stellt eine akute Bedrohung dar, da ein Angreifer den Datenverkehr abfangen und später entschlüsseln kann. Die Fälschung einer Signatur oder eines Zertifikats erfordert hingegen einen aktiven Angriff zum Zeitpunkt der Nutzung, was ein später auftretendes Risiko darstellt und der Signaturverfolgung bis Ende 2028 mehr Zeit einräumt.

Wird meine Anwendung automatisch durch die PQC-Migration von Google Cloud abgedeckt?

Nicht vollständig. Google migriert zwar seine eigene verwaltete Infrastruktur, den Netzwerkverkehr und die Dienste, aber die vom Kunden konfigurierten TLS-Richtlinien, die Kryptografie auf Anwendungsebene und die Clientbibliotheken bleiben in der Verantwortung des Kunden, zu aktualisieren und zu aktivieren.

Was sind Merkle-Tree-Zertifikate?

Google entwickelt gemeinsam mit Industriepartnern eine alternative Zertifikatsarchitektur, die von Grund auf auf die Anforderungen von Post-Quanten-Speicherung hinsichtlich Größe und Leistung ausgelegt ist, anstatt große Post-Quanten-Signaturen in das bestehende X.509-Format einzubetten. Es handelt sich um einen neuen Ansatz, der X.509 derzeit nicht direkt ersetzen kann.

Welche Post-Quantum-Funktionen von Google Cloud sind bereits allgemein verfügbar?

Cloud KMS-Unterstützung für ML-KEM, ML-DSA und SLH-DSA; hybrider ML-KEM-Schlüsselaustausch auf Google Cloud API-Endpunkten und unterstützten Load Balancern; und Post-Quantum-Vertraulichkeit für Googles internes ALTS-Protokoll, abgeschlossen im Jahr 2025.