Wat de PQC-roadmap van Google Cloud voor 2029 betekent voor zakelijke klanten.

Kort antwoord: Google Cloud's roadmap voor na het kwantumtijdperk, die voor het eerst werd aangekondigd op 25 maart 2026, is opgesplitst in drie sporen met verschillende deadlines: vertrouwelijkheid en bescherming met 'nu opslaan, later decoderen', die naar verwachting eind 2027 voltooid zal zijn; integriteit en niet-afwijzing (digitale handtekeningen, certificaten, identiteit), die naar verwachting eind 2028 voltooid zal zijn; en cryptografische fundamenten (sleutelbeheer, hardware, flexibiliteit), die eveneens eind 2028 voltooid moeten zijn en in 2029 volledig gereed moeten zijn. Verschillende onderdelen zijn al operationeel: Cloud KMS is algemeen beschikbaar voor ML-KEM, ML-DSA en SLH-DSA, en Google Cloud API-eindpunten en ondersteunde load balancers onderhandelen al over hybride ML-KEM-sleuteluitwisseling. De belangrijkste afhankelijkheid van de klant: Google migreert zijn eigen infrastructuur en beheerde services, maar de TLS-configuratie aan de klantzijde, de cryptografie op applicatielaagniveau en elke clientbibliotheek die nog steeds uitsluitend gebruikmaakt van klassieke algoritmen, blijven de verantwoordelijkheid van de klant. Deze gedeelde verantwoordelijkheid wordt ook behandeld in onze bredere PQC-handleiding voor de cloud.

Een roadmap met een datum in 2029 is gemakkelijk te interpreteren als "nog niet urgent". Die interpretatie miskent echter het punt van een gefaseerde roadmap: het vertrouwelijkheidstraject wordt als eerste afgerond, tegen eind 2027, juist omdat het risico van 'nu opslaan en later decoderen' nu al bestaat. Deze handleiding splitst de roadmap op in wat er daadwerkelijk onder valt, wat er nu al actief is en wat zakelijke klanten zelf moeten doen, ongeacht de planning van Google.

Key Takeaways

• De routekaart is opgesplitst in drie onderdelen: vertrouwelijkheid (eind 2027), integriteit en niet-afwijzing (eind 2028) en cryptografische fundamenten (eind 2028), met als doel volledige gereedheid in 2029.
• Cloud KMS ondersteunt over het algemeen al ML-KEM, ML-DSA en SLH-DSA voor encryptie- en ondertekeningssleutels; Google Cloud API-eindpunten en ondersteunde load balancers onderhandelen al over hybride ML-KEM-sleuteluitwisseling.
• Google werkt aan Merkle Tree Certificates, ontwikkeld in samenwerking met partners uit de industrie, als alternatief voor het rechtstreeks inbedden van grote post-quantum signatures in X.509-certificaten.
• De verantwoordelijkheid van Google zelf omvat netwerkverkeer, wereldwijde front-ends, het interne ALTS-protocol en de onderliggende hardware en besturingssystemen; door de klant geconfigureerde TLS-beleidsregels, cryptografie op applicatielaagniveau en clientbibliotheken blijven de verantwoordelijkheid van de klant.
• Google's streefdatum van 2029 voor voltooiing sluit nu aan bij die van Cloudflare en een herziene, versnelde planning van Microsoft, waardoor 2029 een gedeelde benchmark voor de sector is geworden in plaats van een geïsoleerde datum voor één enkele aanbieder.

De drie sporen, en waarom vertrouwelijkheid als eerste wordt afgesloten.

De roadmap van Google Cloud geeft bewust prioriteit aan vertrouwelijkheid boven integriteit, en deze redenering is belangrijk voor hoe klanten hun eigen werk moeten prioriteren. Het risico van 'nu opslaan, later decoderen', waarbij een aanvaller vandaag versleuteld verkeer onderschept om het te decoderen zodra er een cryptografisch relevante kwantumcomputer bestaat, is al aanwezig. Daarom heeft het traject voor vertrouwelijkheid, dat netwerkversleuteling en sleuteluitwisseling omvat, de vroegste deadline: eind 2027. Integriteit en niet-afwijzing, digitale handtekeningen, certificaten en authenticatiemechanismen die vervalste identiteiten of gemanipuleerde gegevens voorkomen, heeft een langere looptijd tot eind 2028. Dit weerspiegelt zowel de lagere directe urgentie (een vervalste handtekening vereist vandaag een actieve aanval, niet alleen het onderscheppen van gegevens) als de daadwerkelijk complexere technische uitdaging die de migratie van handtekeningen binnen een certificaatecosysteem met zich meebrengt. Fundamenteel werk, zoals sleutelbeheerbibliotheken, hardwarebeveiligingsmodules, integratie met externe sleutelbeheerders en cryptografische flexibiliteit, loopt ook door tot eind 2028, omdat het de andere twee trajecten ondersteunt in plaats van op zichzelf te staan.

Wat is er al live?

Verschillende onderdelen van de roadmap zijn geen toekomstige toezeggingen; het zijn functionaliteiten die vanaf 2026 algemeen beschikbaar zullen zijn:

• Cloud KMS: Algemeen beschikbare ondersteuning voor ML-KEM, ML-DSA en SLH-DSA voor zowel encryptie- als ondertekeningssleutels, waarbij de onderliggende implementaties als open-source worden onderhouden via de BoringCrypto- en Tink-bibliotheken van Google voor controleerbaarheid.
• Google Cloud API-eindpunten en load balancers: google.com en *.googleapis.com, samen met ondersteunde applicatie- en proxy-loadbalancers, onderhandelen al over hybride ML-KEM-sleuteluitwisseling, inclusief X25519MLKEM768 voor TLS 1.3.
• ALTERNATIEVEN: Het interne transportprotocol van Google op de applicatielaag heeft in 2025 de overgang naar een vertrouwelijkheidsbeleid na de kwantumcomputertijdperk voltooid.
• Kwantumveilige sleutelimport naar Cloud KMS: beoogd voor 2026 binnen het kader van het stichtingsprogramma.

Op de korte termijn staan ​​nog de volgende projecten op de planning: Cloud VPN en interconnectie (2026-2027), privé-CA via certificeringsinstantiediensten (2027) en Cloud HSM en ondersteuning voor vertrouwelijke computersystemen na de kwantumfase (2028).

Merkle Tree-certificaten: een andere benadering van PKI

Eén structurele keuze in de roadmap van Google verdient op zichzelf al aandacht: in plaats van post-quantum handtekeningen direct in het bestaande X.509-certificaatformaat te integreren – een aanpak die de certificaat- en ketengrootte aanzienlijk vergroot – ontwikkelt Google samen met branchepartners Merkle Tree Certificates. Dit is een alternatieve certificaatarchitectuur die vanaf de grond af is ontworpen rond post-quantum beperkingen, in plaats van een aanpassing van het klassieke formaat. Dit is nog steeds een opkomende, zich ontwikkelende aanpak en geen directe vervanging voor X.509. Het verandert dan ook niets aan wat klanten op korte termijn moeten doen met hun eigen certificaatinfrastructuur, maar het geeft wel aan dat innovatie in certificaatformaten, en niet alleen vervanging van algoritmen, onderdeel is van de manier waarop de grootste cloud- en CDN-aanbieders de handtekeningkant van deze transitie benaderen.

Wat blijft de verantwoordelijkheid van de klant?

Googles eigen omschrijving van de gedeelde verantwoordelijkheid is duidelijk: Google beheert de beveiliging van de cloud, inclusief netwerkverkeer, wereldwijde front-ends, ALTS en de onderliggende hardware en besturingssystemen, en waarborgt de hardware-integriteit door middel van kwantumveilige siliciumchips zoals Caliptra en OpenTitan. Klanten blijven verantwoordelijk voor het configureren van hun eigen workloads om daadwerkelijk gebruik te maken van de post-kwantummogelijkheden die Google beschikbaar stelt, de TLS-configuratie op applicatieniveau, de versies van clientbibliotheken en eventuele cryptografie die in de eigen code van de klant is geïmplementeerd in plaats van te worden gedelegeerd aan een beheerde Google-service. Dit is hetzelfde onderscheid dat in meer algemene termen wordt behandeld in onze handleiding voor gedeelde verantwoordelijkheid in de cloud : een provider die zijn eigen infrastructuur migreert, migreert niet automatisch de applicatieafhankelijkheden van een klant.

Wat we daadwerkelijk zouden aanbevelen

Geef prioriteit aan uw eigen werkzaamheden met betrekking tot vertrouwelijkheid, zoals TLS-configuratie en sleuteluitwisseling, vóór werkzaamheden met betrekking tot digitale handtekeningen. Volg daarbij de volgordelogica van Google, aangezien blootstelling door 'nu opslaan, later decoderen' het risico op de korte termijn vormt. Controleer welke Cloud KMS-sleutels in uw omgeving al gebruikmaken van ML-KEM of ML-DSA en welke nog steeds gebruikmaken van klassieke algoritmen. De algemene beschikbaarheid van deze functionaliteit betekent namelijk niet dat uw bestaande sleutels er automatisch naar zijn overgezet. Houd de mijlpalen van Google voor Private CA en Cloud HSM na de kwantumimplementatie in de gaten, met name als uw architectuur daarvan afhankelijk is, aangezien deze later in de roadmap verschijnen dan de API- en load balancer-functionaliteiten die al beschikbaar zijn.

Hoe encryptieconsultancy kan helpen

Weten welke van uw Google Cloud KMS-sleutels, TLS-beleidsregels voor load balancers en certificaatafhankelijkheden al geschikt zijn voor post-quantum computing, en welke nog actie van uw kant vereisen, is precies de inventarislacune die CBOM Secure wil dichten. Het brengt uw cryptografische voetafdruk in de cloud in kaart en vergelijkt deze met wat Google Cloud wel en niet al heeft gemigreerd.

Onze PQC-adviesdiensten ontwikkelen een roadmap aan de klantzijde, afgestemd op de driestappenplanning van Google Cloud. Zo is uw werk op het gebied van vertrouwelijkheid gereed vóór de deadline voor het opslaan en later decoderen van gegevens, en is uw werk op het gebied van digitale handtekeningen klaar vóór de mijlpalen voor Google's Private CA en certificaten. Wanneer certificaatuitgifte plaatsvindt in Google Cloud én andere omgevingen, beheert CertSecure Manager klassieke, hybride en post-quantumcertificaten vanuit één centraal beleidsvlak.

Een tijdlijn van de aanbieder, geen deadline van de klant.

De roadmap van Google Cloud vertelt je wanneer de eigen infrastructuur van Google klaar zal zijn voor de post-quantumfase. Het vertelt je echter niet wanneer je applicatie, je certificaatketen of je specifieke Cloud KMS-sleutelconfiguratie dat zal zijn, aangezien dat werk aan de klantzijde blijft, ongeacht hoe snel Google te werk gaat. Het interpreteren van de driestappenplanning als prioriteringsrichtlijnen – vertrouwelijkheid eerst, handtekeningen en fundamenten daarna – is de meest nuttige manier om een ​​roadmap van een provider te vertalen naar je eigen migratieplan.

Veelgestelde Vragen / FAQ

Wanneer heeft Google Cloud zijn roadmap voor na het kwantumtijdperk aangekondigd?

Google kondigde de bedrijfsbrede doelstelling voor 2029 voor het eerst aan op 25 maart 2026, waarna de gedetailleerde routekaart met drie sporen en de bijbehorende mijlpalen kort daarna werden gepubliceerd.

Waarom heeft het vertrouwelijkheidstraject een eerdere deadline dan het traject voor handtekeningen?

Het risico van 'nu opslaan en later decoderen' bij versleuteld netwerkverkeer is een actieve, hedendaagse kwetsbaarheid, aangezien een aanvaller het verkeer nu kan onderscheppen en later kan decoderen. Het vervalsen van een handtekening of certificaat vereist een actieve aanval op het moment van gebruik, wat een risico is dat zich later manifesteert, waardoor het risico van het vervalsen van handtekeningen tot eind 2028 langer aanhoudt.

Is mijn applicatie automatisch gedekt door de PQC-migratie van Google Cloud?

Niet helemaal. Google migreert zijn eigen beheerde infrastructuur, netwerkverkeer en services, maar het bijwerken en inschakelen van door de klant geconfigureerde TLS-beleidsregels, cryptografie op applicatielaagniveau en clientbibliotheken blijft de verantwoordelijkheid van de klant.

Wat zijn Merkle Tree-certificaten?

Google ontwikkelt samen met partners uit het bedrijfsleven een alternatieve certificaatarchitectuur die vanaf de grond af is ontworpen rond de beperkingen op het gebied van omvang en prestaties na de kwantumcomputertijd, in plaats van grote, dergelijke handtekeningen in het bestaande X.509-formaat te integreren. Het is een opkomende aanpak en geen directe vervanging voor X.509.

Welke post-quantum mogelijkheden van Google Cloud zijn al algemeen beschikbaar?

Cloud KMS-ondersteuning voor ML-KEM, ML-DSA en SLH-DSA; hybride ML-KEM-sleuteluitwisseling op Google Cloud API-eindpunten en ondersteunde loadbalancers; en post-quantum-vertrouwelijkheid voor Google's interne ALTS-protocol, dat in 2025 wordt voltooid.