PQC för molnmiljöer: Delat ansvar mellan AWS, Azure och Google Cloud

Snabbt svar: Molnets delade ansvar för postkvantkryptografi delas tydligt upp längs en välbekant linje, men detaljerna varierar kraftigt mellan leverantörer och tjänster. AWS har publicerat den tydligaste operativa bilden: AWS KMS, ACM och Secrets Manager stöder redan ML-KEM hybridnyckelavtal på icke-FIPS-slutpunkter, symmetrisk kryptering i vila (som AWS KMS standardkryptering) är redan kvantresistent, och att uppdatera kundägda resurser som lastbalanserare till en PQ-aktiverad TLS-policy är uttryckligen kundens ansvar enligt AWS modell för delat ansvar. Azure och Google Cloud rör sig var och en enligt sina egna tidslinjer och är inte enhetligt vid samma beredskapspunkt för varje tjänst. Den praktiska uppgiften för alla multimolnkunder är att granska varje leverantör separat, tjänst för tjänst, snarare än att ställa en enda ja-eller-nej-fråga "stöder detta moln PQC" som ingen leverantör ärligt kan svara på med ett ord.

Molnleverantörer migrerar snabbt, och det är verkligen frestande att anta att migreringen täcker dina arbetsbelastningar automatiskt. Det gör den inte på ett enhetligt sätt. Den här guiden bryter ner vad varje större leverantör migrerar åt dig, vad som förblir ditt ansvar och hur du granskar gapet korrekt snarare än genom antaganden.

Key Takeaways

• AWS KMS, ACM och Secrets Manager stöder redan ML-KEM hybrid post-quantum key agreement på icke-FIPS-slutpunkter i alla AWS-regioner i standardpartitionen.
• Att uppdatera kundägda nätverksresurser, som lastbalanserare, till en PQ-aktiverad TLS-policy ligger uttryckligen på kundsidan av AWS modell för delat ansvar, inte något som AWS gör automatiskt.
• Symmetrisk kryptering i vila, inklusive AWS KMS standardnyckelkryptering, anses redan vara kvantresistent och kräver ingen migrering i sig.
• Leverantörsberedskapen är inte enhetlig över olika tjänster inom samma moln, än mindre mellan olika leverantörer; en generell fråga om "stöds PQC" belyser inte de luckor mellan tjänster som är viktiga under en revision.
• En användbar molnövergripande PQC-beredskapsgranskning testar faktiskt förhandlings- och API-beteende, hybridnyckelutbyte, skapande av KMS-signeringsnycklar och valideringsgränser för HSM, snarare än att förlita sig på marknadsföringspåståenden om generellt stöd.

AWS: Vad som migreras kontra vad som är ditt ansvar

AWS har publicerat den mest operativt specifika PQC-migreringsvägledningen från de största leverantörerna. Från och med publiceringen av denna guide stöder AWS KMS, AWS Certificate Manager och AWS Secrets Manager-slutpunkter ML-KEM för hybrid post-quantum key agreement på icke-FIPS-slutpunkter över alla AWS-regioner i standard AWS-partitionen, en funktion som AWS levererar transparent och inte kräver någon kundåtgärd för att dra nytta av den på dessa specifika slutpunkter. Symmetriska algoritmer som används för kryptering i vila, inklusive standard AWS KMS-nyckelkryptering, anses redan vara kvantresistenta och behöver inte migreras på egna meriter.

Det som återstår som kundansvar framgår tydligt av AWS egen vägledning: uppdatering av kundägda nätverksresurser, såsom lastbalanserare, till en PQ-aktiverad TLS-policy ligger på kundens sida av den delade ansvarsmodellen. AWS tillhandahåller uppdaterade TLS-policyer som stöder ML-KEM hybridnyckelutbyte och IAM-resurskontrollpolicyer för att tillämpa en önskad TLS-policy vid framtida resursskapande, men att tillämpa den policyn på befintliga resurser är en kundåtgärd, inte en automatisk ändring på AWS-sidan. AWS Private CA och AWS KMS stöder tillsammans post-kvantumfunktioner för certifikat- och nyckelinfrastruktur, återigen som verktyg som kunden konfigurerar snarare än en standard som tillämpas utan åtgärd.

Azure och Google Cloud: Olika tidslinjer, inte frånvarande

Azure och Google Cloud investerar båda i post-quantum-beredskap, men inte enhetligt vid samma tidpunkt som AWS över alla tjänstekategorier från och med 2026. Oberoende molnövergripande granskningar har funnit att Azures hanterade HSM-dokumentation, till exempel, fortfarande är centrerad kring RSA, elliptisk kurva och AES-nyckeltyper snarare än ML-KEM eller ML-DSA, även om Microsoft har levererat post-quantum-kapacitet på andra ställen i Windows-plattformen, inklusive ML-DSA-stöd i Active Directory Certificate Services. Detta är en tjänstespecifik lucka, inte ett uttalande om Azures övergripande PQC-ställning, vilket är anledningen till att verifiering tjänst för tjänst är viktigare än en bedömning på enskild leverantörsnivå.

Google Cloud har publicerat sin egen detaljerade PQC-färdplan som täcker konfidentialitetsmigrering, signaturintegritet och milstolpar tjänst för tjänst. Vi tar upp den färdplanen och dess specifika konsekvenser för företagskunder i en dedikerad guide, eftersom den förtjänar en egen detaljerad behandling snarare än en sammanfattning här.

Revisionsfrågorna som faktiskt spelar roll

”Stöder detta moln postkvantkryptografi” är en alltför bred fråga att granska mot, eftersom en leverantör ärligt kan svara ja eftersom ett TLS-bibliotek någonstans i stacken förhandlar fram en hybrid KEM medan en helt annan tjänst i samma moln fortfarande bara utfärdar klassiska nycklar. De frågor som faktiskt visar på verkliga luckor under en granskning är mer specifika:

• Kan jag upprätta en NIST-standardiserad post-quantum delad hemlighet på den här specifika tjänstens TLS-slutpunkt?
• Kan moln-KMS skapa en ML-DSA-signeringsnyckel, och utförs den nyckelgenereringen och signeringsåtgärden inuti en validerad HSM?
• Är post-quantum TLS bara tillgängligt som ett alternativ, eller förhandlas det automatiskt i den klientsökväg som mitt program faktiskt använder i produktion?
• Vilka FIPS 140-2- eller FIPS 140-3-certifikatberoenden har den här specifika tjänsten, och hur påverkas det av att FIPS 140-2 upphör att gälla i september 2026?

Testa snarare än anta: registrera den faktiska TLS-handskakningen och nyckelutbytesförhandlingen för tjänster du är beroende av, utöva KMS-signering, verifiering, inkapsling och dekapsling direkt, och testa alternativa beteenden när en post-kvantumförhandling inte är tillgänglig, snarare än att förlita sig på en leverantörs allmänna marknadsföringspåstående om PQC-stöd.

Bygga upp ditt inventarium om delat ansvar

En komplett PQC-inventering i molnet täcker mer än TLS: certifikatutfärdare, server- och klientcertifikat, KMS- och HSM-nycklar, SSH-beroenden, kodsigneringsnycklar, VPN-konfigurationer, TLS-terminatorer, tjänstnät och alla externa nyckelhanterare som läggs ovanpå molnets egna. För varje objekt, kartlägg vilken sida av den delade ansvarsgränsen den faktiskt faller på, vilken molnleverantören migrerar som standard, vilket kräver en konfigurationsändring på kundsidan och vilken som är beroende av en leverantörskapacitet som ännu inte har levererats. Långlivade, känsliga data behöver också ett eget spårningslager, oberoende av infrastrukturkategori, eftersom data med ett flerårigt sekretesskrav har exponering för skörd-nu-dekryptera-senare oavsett vilken molntjänst som för närvarande lagrar eller överför den.

Vad vi egentligen skulle rekommendera

Granska varje molnleverantör du använder separat och på tjänstenivå, inte som en enda organisationsomfattande kryssruta för "är vi moln-PQC-redo" (eller "är vi moln-PQC-redo"). Tillämpa AWS redan tillgängliga hybrid-TLS-policyer på dina kundägda resurser nu istället för att anta att AWS egna tjänstesidesframsteg täcker dem automatiskt. Spåra Azure och Google Cloud tjänst-för-tjänst-beredskap enligt deras egna tidslinjer istället för att anta funktionsparitet med AWS, och bygg ditt inventering för att explicit skilja leverantörshanterade beroenden från kundkonfigurerade, eftersom den skillnaden är vad en verklig granskning av delat ansvar faktiskt handlar om.

Hur krypteringskonsulting kan hjälpa

Den tjänst-för-tjänst-inventering som den här guiden argumenterar för, och som skiljer vad varje molnleverantör migrerar automatiskt från vad som förblir ditt konfigurationsansvar, är precis vad CBOM Secure är byggt för att producera över multimoln- och hybridmiljöer, och mappar certifikat, nycklar och TLS-konfigurationer till deras leverantörshanterade eller kundhanterade status.

Våra PQC-rådgivningstjänster kör granskningsfrågorna som den här guiden beskriver mot er faktiska molnmiljö, testar verklig TLS-förhandling och KMS API-beteende snarare än att förlita sig på leverantörers marknadsföringspåståenden, och bygger in de resulterande luckorna i en prioriterad åtgärdsplan på kundsidan. Där certifikatutfärdande omfattar flera molnleverantörer hanterar CertSecure Manager klassiska, hybrid- och post-kvantumcertifikat från ett enda policyplan över AWS, Azure och Google Cloud.

Verifiera linjen, anta den inte

Molnleverantörer går över till postkvantkryptografi, och AWS i synnerhet har publicerat en verkligt tydlig operativ bild av vad de migrerar automatiskt kontra vad de lämnar till kundkonfigurationen. Den tydligheten sträcker sig inte jämnt över varje leverantör och varje tjänst, vilket är just därför "stöder mitt moln PQC" är fel fråga. Den rätta är tjänstespecifik och testbar: förhandlar just denna slutpunkt om ett validerat hybridnyckelutbyte idag, i den klientväg som min applikation faktiskt använder, och vem ansvarar för att aktivera det.

Vanliga frågor om partihandel med mat och dryck

Aktiverar AWS automatiskt post-quantum TLS på mina resurser?

Inte enhetligt. AWS levererar ML-KEM hybridstöd transparent på AWS KMS-, ACM- och Secrets Manager-slutpunkter, men att uppdatera kundägda resurser som lastbalanserare till en PQ-aktiverad TLS-policy ligger uttryckligen på kundens sida av modellen för delat ansvar.

Behöver jag migrera data krypterad med AWS KMS standard symmetriska kryptering?

Nej. Symmetriska krypteringsalgoritmer som används för kryptering i vila anses redan vara kvantresistenta och kräver inte en post-kvantmigrering i sig.

Ligger Azure efter AWS på postkvantkryptografi?

Det varierar beroende på tjänst. Oberoende granskningar har hittat luckor inom specifika områden, till exempel stöd för Azure-hanterade HSM-nyckeltyper, medan Microsoft har levererat post-quantum-funktioner till andra områden, inklusive ML-DSA-stöd i Active Directory Certificate Services. Verifiera beredskapen tjänst för tjänst snarare än att bedöma en leverantörs övergripande status utifrån en tjänst.

Vilket är det bästa sättet att testa om en molntjänst faktiskt stöder post-quantum key exchange?

Registrera den faktiska TLS-handskakningen för den specifika slutpunkten med hjälp av ett verktyg som Wireshark eller din webbläsares inbyggda utvecklingsverktyg, snarare än att förlita dig på en leverantörs allmänna marknadsföringspåstående. För KMS-tjänster, använd direkt signerings-, verifierings-, inkapslings- eller dekapslings-API:et för att bekräfta stöd för post-kvantumalgoritmer snarare än att anta enbart utifrån dokumentationen.

Vad bör ett PQC-inventering för flera moln innehålla?

Certifikatutfärdare, server- och klientcertifikat, KMS- och HSM-nycklar, SSH-beroenden, kodsigneringsnycklar, VPN-konfigurationer, TLS-terminatorer och tjänstnät, var och en mappad till om den är leverantörshanterad, kundkonfigurerad eller beroende av en funktion som ännu inte har levererats.