PQC voor cloudomgevingen: gedeelde verantwoordelijkheid voor AWS, Azure en Google Cloud

Kort antwoord: De gedeelde verantwoordelijkheid voor post-kwantumcryptografie in de cloud is duidelijk verdeeld langs een bekende lijn, maar de details verschillen sterk per provider en dienst. AWS heeft het meest heldere operationele beeld gepubliceerd: AWS KMS, ACM en Secrets Manager ondersteunen al ML-KEM hybride sleuteluitwisseling op niet-FIPS-eindpunten, symmetrische encryptie in rust (zoals de standaardencryptie van AWS KMS) is al kwantumresistent en het bijwerken van door de klant beheerde resources zoals loadbalancers naar een PQ-compatibel TLS-beleid is expliciet de verantwoordelijkheid van de klant volgens het gedeelde verantwoordelijkheidsmodel van AWS. Azure en Google Cloud volgen elk hun eigen tijdschema en bevinden zich niet uniform in hetzelfde stadium van gereedheid voor elke dienst. De praktische taak voor elke multi-cloudklant is om elke provider afzonderlijk te controleren, dienst voor dienst, in plaats van één ja-of-nee-vraag te stellen als "ondersteunt deze cloud PQC?", een vraag die geen enkele provider eerlijk met één woord kan beantwoorden.

Cloudproviders migreren snel en het is heel verleidelijk om aan te nemen dat de migratie uw workloads automatisch omvat. Dat is echter niet altijd het geval. Deze gids legt uit wat elke grote provider voor u migreert, wat uw eigen verantwoordelijkheid blijft en hoe u de hiaten nauwkeurig kunt vaststellen in plaats van op aannames af te gaan.

Key Takeaways

• AWS KMS, ACM en Secrets Manager ondersteunen al ML-KEM hybride post-quantum sleutelovereenkomst op niet-FIPS-eindpunten in alle AWS-regio's in de standaardpartitie.
• Het bijwerken van door de klant beheerde netwerkbronnen, zoals loadbalancers, naar een PQ-compatibel TLS-beleid valt expliciet onder de verantwoordelijkheid van de klant binnen het gedeelde verantwoordelijkheidsmodel van AWS, en is niet iets wat AWS automatisch doet.
• Symmetrische encryptie in rust, inclusief de standaard sleutelencryptie van AWS KMS, wordt al beschouwd als kwantumresistent en vereist op zichzelf geen migratie.
• De mate waarin een provider klaar is voor een bepaalde dienst is niet uniform binnen dezelfde cloud, laat staan ​​tussen verschillende providers. Een algemene vraag als "wordt PQC ondersteund?" brengt niet de specifieke tekortkomingen per dienst aan het licht die tijdens een audit van belang zijn.
• Een nuttige PQC-gereedheidsaudit voor meerdere clouds test het daadwerkelijke onderhandelings- en API-gedrag, de uitwisseling van hybride sleutels, het aanmaken van KMS-ondertekeningssleutels en de HSM-validatiegrens, in plaats van te vertrouwen op marketingclaims over algemene ondersteuning.

AWS: Wat is gemigreerd en wat is jouw verantwoordelijkheid?

AWS heeft de meest operationele specifieke PQC-migratierichtlijnen van de grote aanbieders gepubliceerd. Op het moment van publicatie van deze richtlijnen ondersteunen AWS KMS-, AWS Certificate Manager- en AWS Secrets Manager-eindpunten ML-KEM voor hybride post-quantum sleutelovereenkomst op niet-FIPS-eindpunten in alle AWS-regio's in de standaard AWS-partitie. Deze functionaliteit wordt door AWS transparant aangeboden, waardoor klanten geen actie hoeven te ondernemen om er op deze specifieke eindpunten van te profiteren. Symmetrische algoritmen die worden gebruikt voor encryptie in rust, inclusief standaard AWS KMS-sleutelencryptie, worden al als quantumresistent beschouwd en hoeven op zichzelf niet te worden gemigreerd.

Wat de verantwoordelijkheid van de klant blijft, is expliciet vastgelegd in de richtlijnen van AWS zelf: het bijwerken van door de klant beheerde netwerkbronnen, zoals load balancers, naar een PQ-compatibel TLS-beleid valt onder de verantwoordelijkheid van de klant in het gedeelde verantwoordelijkheidsmodel. AWS levert bijgewerkte TLS-beleidsregels die ML-KEM hybride sleuteluitwisseling ondersteunen, en IAM-resourcebeheerbeleidsregels om een ​​gewenst TLS-beleid af te dwingen bij het aanmaken van toekomstige resources. Het toepassen van dat beleid op bestaande resources is echter een actie van de klant, geen automatische wijziging aan de kant van AWS. AWS Private CA en AWS KMS ondersteunen samen post-quantum mogelijkheden voor certificaat- en sleutelinfrastructuur, wederom als tools die de klant configureert in plaats van een standaardinstelling die zonder actie wordt toegepast.

Azure en Google Cloud: verschillende tijdlijnen, maar niet afwezig.

Azure en Google Cloud investeren beide in voorbereiding op het post-kwantumtijdperk, maar niet uniform in dezelfde mate als AWS voor elke servicecategorie in 2026. Onafhankelijke audits van verschillende cloudomgevingen hebben bijvoorbeeld aangetoond dat de documentatie van Azure's beheerde HSM's zich nog steeds richt op RSA-, elliptische-curve- en AES-sleuteltypen in plaats van ML-KEM of ML-DSA, terwijl Microsoft elders in het Windows-platform al post-kwantumfunctionaliteit heeft geïmplementeerd, waaronder ML-DSA-ondersteuning in Active Directory Certificate Services. Dit is een servicespecifieke tekortkoming en zegt niets over Azure's algehele PQC-aanpak. Daarom is verificatie per service belangrijker dan een oordeel op providerniveau.

Google Cloud heeft een eigen gedetailleerde PQC-roadmap gepubliceerd met daarin de migratie van vertrouwelijkheid, de integriteit van digitale handtekeningen en mijlpalen per service. We behandelen die roadmap en de specifieke implicaties ervan voor zakelijke klanten in een aparte handleiding, omdat deze een eigen, gedetailleerde beschrijving verdient in plaats van een samenvatting hier.

De auditvragen die er echt toe doen

"Ondersteunt deze cloud post-kwantumcryptografie?" is een te algemene vraag om te toetsen aan een audit, aangezien een provider eerlijk gezegd "ja" kan antwoorden omdat een TLS-bibliotheek ergens in de stack een hybride KEM onderhandelt, terwijl een volledig andere service in dezelfde cloud nog steeds alleen klassieke sleutels uitgeeft. De vragen die daadwerkelijk tekortkomingen aan het licht brengen tijdens een audit zijn specifieker:

• Kan ik een door NIST gestandaardiseerd gedeeld geheim na de kwantumfase instellen op het TLS-eindpunt van deze specifieke service?
• Kan het cloud-KMS een ML-DSA-ondertekeningssleutel genereren, en vindt die sleutelgeneratie- en ondertekeningsbewerking plaats binnen een gevalideerde HSM?
• Is post-quantum TLS slechts een optie, of wordt het automatisch onderhandeld in het clientpad dat mijn applicatie daadwerkelijk in productie gebruikt?
• Welke FIPS 140-2- of FIPS 140-3-certificaatvereisten heeft deze specifieke dienst, en welke invloed heeft het afschaffen van FIPS 140-2 in september 2026 hierop?

Test in plaats van aannames te doen: leg de daadwerkelijke TLS-handshake en sleuteluitwisselingsonderhandeling vast voor services waarvan u afhankelijk bent, test de KMS-API's voor ondertekening, verificatie, inkapseling en uitkapseling rechtstreeks en test het terugvalgedrag wanneer een post-quantum-onderhandeling niet beschikbaar is, in plaats van te vertrouwen op de algemene marketingclaim van een provider over PQC-ondersteuning.

Het opbouwen van uw inventaris van gedeelde verantwoordelijkheid

Een complete PQC-inventarisatie van de cloud omvat meer dan alleen TLS: certificeringsinstanties, server- en clientcertificaten, KMS- en HSM-sleutels, SSH-afhankelijkheden, code-ondertekeningssleutels, VPN-configuraties, TLS-terminators, service meshes en alle externe sleutelbeheerders die bovenop die van de cloud zelf zijn geïmplementeerd. Breng voor elk item in kaart aan welke kant van de gedeelde verantwoordelijkheid het zich bevindt, welke items de cloudprovider standaard migreert, welke een configuratiewijziging aan de klantzijde vereisen en welke afhankelijk zijn van een functionaliteit van de provider die nog niet beschikbaar is. Langdurig gevoelige data heeft ook een eigen trackinglaag nodig, onafhankelijk van de infrastructuurcategorie, aangezien data met een meerjarige vertrouwelijkheidsvereiste het risico met zich meebrengt van 'nu verzamelen, later decoderen', ongeacht welke cloudservice deze data momenteel opslaat of verzendt.

Wat we daadwerkelijk zouden aanbevelen

Audit elke cloudprovider die u gebruikt afzonderlijk en op serviceniveau, en niet als één algemene controle op de 'cloud-PQC-gereedheid' voor de hele organisatie. Pas de reeds beschikbare hybride TLS-beleidsregels van AWS nu toe op uw resources in eigendom van de klant, in plaats van ervan uit te gaan dat de voortgang aan de servicezijde van AWS dit automatisch dekt. ​​Volg de gereedheid van Azure en Google Cloud per service op basis van hun eigen tijdlijnen, in plaats van uit te gaan van gelijke functionaliteit als AWS, en stel uw inventaris zo samen dat u provider-beheerde afhankelijkheden expliciet onderscheidt van door de klant geconfigureerde afhankelijkheden, aangezien dat onderscheid essentieel is voor een echte audit van gedeelde verantwoordelijkheid.

Hoe encryptieconsultancy kan helpen

De service-voor-service inventarisatie die in deze handleiding wordt bepleit, waarbij onderscheid wordt gemaakt tussen wat elke cloudprovider automatisch migreert en wat uw configuratieverantwoordelijkheid blijft, is precies wat CBOM Secure beoogt te realiseren in multi-cloud- en hybride omgevingen. Het brengt certificaten, sleutels en TLS-configuraties in kaart en koppelt ze aan hun status als door de provider beheerd of door de klant beheerd.

Onze PQC Advisory Services toetsen de in deze handleiding beschreven auditvragen aan uw daadwerkelijke cloudomgeving. Hierbij wordt het echte gedrag van TLS-onderhandelingen en KMS API's getest, in plaats van af te gaan op marketingclaims van providers. De geconstateerde tekortkomingen worden vervolgens verwerkt in een prioriteitsplan voor herstel aan de klantzijde. Wanneer certificaatuitgifte meerdere cloudproviders omvat, beheert CertSecure Manager klassieke, hybride en post-quantumcertificaten vanuit één beleidslaag voor AWS, Azure en Google Cloud.

Controleer de lijn, ga er niet zomaar vanuit.

Cloudproviders stappen over op post-kwantumcryptografie, en AWS heeft met name een helder operationeel overzicht gepubliceerd van wat automatisch wordt gemigreerd en wat aan de klantconfiguratie wordt overgelaten. Die helderheid is echter niet bij elke provider en elke service gelijk, en dat is precies de reden waarom "ondersteunt mijn cloud PQC?" de verkeerde vraag is. De juiste vraag is servicespecifiek en testbaar: onderhandelt dit specifieke eindpunt momenteel over een gevalideerde hybride sleuteluitwisseling in het clientpad dat mijn applicatie daadwerkelijk gebruikt, en wie is verantwoordelijk voor het inschakelen ervan?

Veelgestelde Vragen / FAQ

Schakelt AWS automatisch post-quantum TLS in voor mijn resources?

Niet uniform. AWS biedt transparante ondersteuning voor ML-KEM-hybride op AWS KMS-, ACM- en Secrets Manager-eindpunten, maar het bijwerken van door de klant beheerde resources zoals load balancers naar een PQ-compatibel TLS-beleid ligt expliciet bij de klant in het model van gedeelde verantwoordelijkheid.

Moet ik gegevens migreren die zijn versleuteld met de standaard symmetrische versleuteling van AWS KMS?

Nee. Symmetrische encryptiealgoritmen die worden gebruikt voor encryptie van data in rust worden al als kwantumresistent beschouwd en vereisen op zichzelf geen post-kwantummigratie.

Is Azure achter op AWS als het gaat om post-kwantumcryptografie?

Dit verschilt per dienst. Onafhankelijke audits hebben lacunes in specifieke gebieden aan het licht gebracht, zoals de ondersteuning voor Azure managed HSM-sleuteltypen, terwijl Microsoft elders al functionaliteit na de kwantumupdate heeft geïmplementeerd, waaronder ML-DSA-ondersteuning in Active Directory Certificate Services. Controleer de gereedheid per dienst in plaats van de algehele status van een provider te beoordelen op basis van één dienst.

Wat is de beste manier om te testen of een cloudservice daadwerkelijk post-quantum sleuteluitwisseling ondersteunt?

Leg de daadwerkelijke TLS-handshake voor het specifieke eindpunt vast met een tool zoals Wireshark of de ingebouwde ontwikkelaarstools van uw browser, in plaats van af te gaan op de algemene marketingclaim van een provider. Gebruik voor KMS-services de API voor ondertekening, verificatie, inkapseling of decapsulatie direct om de ondersteuning voor post-quantumalgoritmen te bevestigen, in plaats van dit alleen op basis van documentatie aan te nemen.

Wat moet een PQC-inventaris voor meerdere clouds omvatten?

Certificeringsinstanties, server- en clientcertificaten, KMS- en HSM-sleutels, SSH-afhankelijkheden, codeondertekeningssleutels, VPN-configuraties, TLS-terminators en service meshes, elk gekoppeld aan de vraag of het door de provider wordt beheerd, door de klant wordt geconfigureerd of afhankelijk is van een functionaliteit die nog niet is uitgebracht.