AWS KMS kontra Azure Key Vault kontra GCP KMS

AWS KMS, Azure Key Vault och GCP Cloud KMS är de tre största molnleverantörernas hanterade tjänster för att generera, lagra och använda krypteringsnycklar. Valet är viktigt eftersom var och en tillämpar en annan säkerhets- och åtkomstmodell under huven, och att byta senare innebär att du omstrukturerar din krypteringsstrategi. Den rekommenderade åtgärden: matcha tjänsten med ditt dominerande moln för inbyggda arbetsbelastningar och bestäm din nyckelkontrollmodell (inbyggd, BYOK eller HYOK) explicit innan du skalar bortom ett fåtal nycklar.

Publicerad: juli 2021. Uppdaterad: augusti 2026. Granskad av Encryption Consultings rådgivande team för molnnyckelhantering.

Om du bara kör AWS och Azure, utan planer på att lägga till GCP, går vår mer detaljerade jämförelse mellan AWS och Azure KMS djupare in på just det tvåmolnsbeslutet. Den här artikeln täcker alla tre leverantörer för team som utvärderar hela fältet.

Vad är AWS KMS, Azure Key Vault och GCP Cloud KMS?

AWS Key Management Service (KMS), Azure Key Vault och Google Cloud Key Management Service (Cloud KMS) är var och en molnleverantörs hanterade erbjudanden för att skapa, lagra och använda kryptografiska nycklar utan att behöva använda dina egna hårdvarusäkerhetsmoduler (HSM). Alla tre följer samma konceptuella mönster: en nyckelkrypteringsnyckel (KEK) som innehas av tjänsten skyddar datakrypteringsnycklar (DEK), vilka i sin tur skyddar dina faktiska data, och själva KEK:n returneras aldrig till dig utan problem. Där de skiljer sig åt är terminologin för nyckelhantering , IAM-integration, rotationsstandardvärden och hur långt du kan driva kontrollen över nyckelmaterialet utanför leverantören.

AWS döpte om sin ursprungliga terminologi från "Customer Master Key (CMK)" till KMS-nyckel för flera år sedan; nuvarande AWS-dokumentation skiljer på kundhanterade nycklar , AWS-hanterade nycklar och AWS-ägda nycklar . Azure Key Vault utfärdar nycklar från en standardnivå (programvaruskyddad, flera hyresgäster) eller premiumnivå (delad HSM-pool), plus en separat hanterad HSM- produkt för dedikerad hårdvara med en enda hyresgäst. GCP Cloud KMS prissätter PROGRAMVARA , HSM och EXTERNA nycklar som tre distinkta skyddsnivåer inom en tjänst.

Hur står sig nativa nyckellagringsmodeller i jämförelse?

Varje leverantör har som standard en annan hårdvaruvalideringsnivå och stöd för nyckeltyper, vilket avgör vad du kan göra utan att uppgradera till en premiumnivå.

Leverans	AWS KMS	Azure Key Vault	GCP Cloud KMS
Standardnyckelskydd	FIPS 140-2-validerad HSM (alla nycklar)	Programvara (Standard) eller delad HSM-pool (Premium)	Programvara, HSM eller extern, vald per nyckel
Dedikerat HSM-alternativ för en enda hyresgäst	Via CloudHSM-integration	Hanterad HSM (FIPS 140-3 Nivå 3, Marvell LiquidSecurity)	Moln-HSM för enskild hyresgäst
Nyckeltyper som stöds	Symmetrisk, asymmetrisk (RSA, ECC), HMAC	RSA och elliptisk kurva (asymmetrisk); ingen inbyggd symmetrisk nyckeltyp	Symmetrisk (AES-256) och asymmetrisk (RSA, ECC)
Nyckelportabilitet	Lämnar aldrig AWS-regionen där den skapades	Lämnar aldrig valvets gränser; Microsoft uppger att de inte kan se viktigt material	Lämnar aldrig nyckelknippans plats

Bör du använda nativa nycklar, BYOK eller HYOK i dessa moln?

Använd varje leverantörs inbyggda nycklar som standard, byt till BYOK när du behöver bevisa var en nyckel kommer ifrån och reservera HYOK för de specifika nycklar som en tillsynsmyndighet eller ett avtal säger aldrig får vidröra molnleverantörens infrastruktur. Alla tre moln stöder alla tre modellerna, men HYOK-mekaniken skiljer sig tillräckligt mycket åt för att ändra din arkitektur.

Modell	AWS KMS	Azure Key Vault	GCP Cloud KMS
Native	KMS-genererad nyckel, kan aldrig exporteras	Nyckel genererad av valv eller hanterad HSM	Cloud KMS-genererad nyckel
BYOK	Importera nyckelmaterial inslaget med RSA; AWS har en användbar kopia	Importera HSM-skyddat nyckelmaterial till hanterad HSM från en lokal HSM	Importera nyckelmaterial (AES-256-omslutet med RSA 3072-bitars)
HYOK	Extern nyckellagring (XKS): dubbel kryptering, nyckeln lämnar aldrig din externa nyckelhanterare	Extern nyckelhantering (förhandsvisning): omslag/utpackning delegerad till en kunddriven EKM-proxy; täcks inte av Managed HSM SLA	Cloud External Key Manager (EKM): kryptering med dubbla lager via Fortanix, Futurex eller Thales; en begäran misslyckas om den externa nyckeln inte kan nås

Varje HYOK-implementering delar samma avvägning: du får bevisbar kontroll över nyckeln och du tar på dig den operativa risken för din externa nyckelhanterares drifttid. Google är tydliga med nackdelen – specifikt för Cloud Spanner orsakar en EKM-nyckel som inte kan nås i mer än 30 dagar permanent dataförlust, eftersom Google uppger att de inte kan återställa data som skyddas av en nyckel de aldrig innehade. Se vår förklaring av Hybrid KMS för BYOK-vs-HYOK-avvägningen mer ingående, och Dedikerade vs. Delade HSM:er för hur val av nyckelisolering överförs till HSM-upphandling.

Hur skiljer sig IAM-modellen mellan AWS, Azure och GCP?

Alla tre använder sin plattforms generella identitetssystem för nyckelåtkomst, kombinerat med en KMS-specifik behörighets- eller policymodell – ingen av dem uppfann ett separat identitetssystem bara för nycklar.

• AWS KMS kombinerar IAM-identitetsbaserade policyer med en obligatorisk nyckelpolicy kopplad till varje KMS-nyckel, plus tillfälliga beviljanden för åtkomst mellan konton eller tjänster. Konfiguration med lägsta behörighet innebär att neka kms:CreateGrant förutom där ett krypteringskontextvillkor matchar ett godkänt nyckel-ARN.
• Azure Key Vault stöder både äldre valvåtkomstpolicyer och Azure RBAC; Managed HSM använder ett separat, lokalt RBAC-system som Azure-prenumerationsadministratörer inte kan åsidosätta, vilket är poängen – det är utformat så att inte ens Microsofts supportpersonal kan bevilja sig själva nyckelåtkomst.
• GCP Cloud KMS styrs helt av Cloud IAM-roller, såsom roles/cloudkms.cryptoKeyEncrypterDecrypter endast för användningsåtkomst och roles/cloudkms.admin för ledningen, där Google uttryckligen rekommenderar en uppdelning av arbetsuppgifterna mellan de två.

En installation med minsta behörighet som fungerar på alla tre områden följer samma fem steg oavsett leverantör:

1. Separera produktions- och icke-produktionsnycklar i olika konton, prenumerationer eller projekt så att en komprometterad testidentitet aldrig kan nå en produktionsnyckel.
2. Ge behörigheter för kryptering/dekryptering (användning) och nyckeladministration till olika roller – aldrig samma roll.
3. Omfånga varje beviljande till en specifik nyckelresurs, aldrig ett jokertecken, med hjälp av resurs-ARN:er (AWS), omfattade RBAC-tilldelningar (Azure) eller IAM-villkor (GCP).
4. Kräv MFA eller ett arbetsflöde med privilegierad åtkomst för alla åtgärder som kan ta bort eller schemalägga borttagning av en nyckel eller ett valv.
5. Granska åtkomsten kvartalsvis med hjälp av varje leverantörs inbyggda verktyg – IAM Access Analyzer (AWS), Azure AD Access Reviews (Azure) eller IAM Recommender (GCP).

Hur fungerar nyckelrotation i varje tjänst?

Rotationen är automatisk i alla tre tjänsterna för symmetriska nycklar, men det konfigurerbara intervallet och de hårda gränserna skiljer sig tillräckligt mycket åt för att påverka din efterlevnadsdokumentation.

• AWS KMSAutomatisk rotation för symmetriska nycklar kan konfigureras från 90 dagar till 2 560 dagar (ungefär sju år); asymmetriska och HMAC-nycklar är inte kvalificerade och måste roteras genom att en ny nyckel skapas. Importerat nyckelmaterial stöder rotation på begäran, upp till tio gånger under nyckelns livstid. De två första rotationerna för en nyckel lägger till 1 USD/månad vardera till dess kostnad; prisökningen begränsas därefter.
• Azure Key Vault Managed HSMAutorotationsprinciper är skapandebaserade eller utgångsbaserade, med ett minsta intervall på 28 dagar; Microsoft rekommenderar rotation minst vartannat år enligt NIST SP 800-57. Varje nyckel är begränsad till totalt 100 versioner, och rotationer räknas mot den gränsen. Standard- och Premium Key Vault (icke-hanterad HSM) erbjuder inte inbyggd autorotation på samma sätt och förlitar sig vanligtvis på Azure Automation eller Event Grid-utlöst rotation.
• GCP Cloud KMSAutomatisk rotation för symmetriska nycklar kan konfigureras från 1 dag till 100 år; asymmetriska signerings- och krypteringsnycklar är inte berättigade till automatisk rotation. Att rotera en nyckel inaktiverar eller omkrypterar inte data som skyddas av äldre nyckelversioner – dessa versioner måste inaktiveras manuellt eller förstöras när de tas ur bruk.

Vad bör du logga och övervaka i varje moln?

Aktivera loggning innan du skapar din första nyckel i någon av de tre tjänsterna, inte efter att en incident tvingar fram frågan.

• AWSCloudTrail fångar upp alla KMS-hanteringsanrop (skapa, rotera, inaktivera, policyredigera) och alla kryptografiska anrop (kryptera, dekryptera, generera datanyckel), inklusive anropsidentitet och käll-IP.
• AzureKey Vault avger en AuditEvent Diagnostisk loggkategori via Azure Monitor diagnostikinställningar, dirigeras till Log Analytics, en Event Hub eller lagring för långsiktig kvarhållning.
• GCPMolnrevisionsloggar registrerar både administratörsaktivitet (hanteringsåtgärder, alltid på, kan inte inaktiveras) och dataåtkomstloggar (nyckelanvändning, måste vara explicit aktiverad) för varje Cloud KMS-nyckel.

Oavsett vilket moln du standardiserar på, mata in dessa loggar i ett SIEM och meddela specifikt om nyckelborttagning, policyändringar och export- eller wrap-/pack-up-händelser mot HYOK-nycklar – det är dessa åtgärder som förvandlar en rutinmässig nyckelåtgärd till en incident.

Hur jämför sig AWS KMS, Azure Key Vault och GCP Cloud KMS kostnadsmässigt?

Ingen av de tre prismodellerna står sig tydligt mot varandra – AWS-avgifter per nyckel, GCP-avgifter per nyckelversion per skyddsnivå och Azure-avgifter per operation plus en separat HSM-nyckeltilläggsavgift.

Provider	Kostnad för basnyckel	Operationer	HYOK / externt alternativ
AWS KMS	1.00 USD/nyckel/månad, fast oavsett nyckeltyp	0.03 USD/10 000 förfrågningar (20 000 gratis/månad)	Extern nyckellagring: samma $1/månad, plus din egen kostnad för nyckelhanteringsinfrastrukturen
Azure Key Vault	Programvarunycklar: ingen separat lagringsavgift; HSM-skyddade nycklar: ungefär 1–5 USD/nyckel/månad, nedgraderat efter volym	~0.03 USD/10 000 operationer (programvara), ~0.15 USD/10 000 för avancerade tangentoperationer	Extern nyckelhantering: förhandsvisning, inget separat publicerat pris ännu
GCP Cloud KMS	0.06 USD/nyckelversion/månad (programvara), 1.00 USD/nyckelversion/månad (HSM)	0.03 USD/10 000 operationer (0.15 USD/10 000 USD för vissa HSM-operationer)	EXTERN/EXTERN_VPC (EKM): 3.00 USD/nyckelversion/månad

Azures exakta siffror varierar beroende på region och publiceras inte som fasta globala priser på Microsofts prissida i skrivande stund. Betrakta siffrorna ovan som riktlinjer och bekräfta aktuell regional prissättning innan du budgeterar. En moln-HSM med en enda hyresgäst på GCP kostar ungefär 3 500 dollar/månad och inkluderar 15 000 nyckelversioner utan extra kostnad, vilket kan vara billigare än HSM-priser per version i verklig skala.

Hur ser en arkitektur för nyckelhantering i flera moln ut?

Om du kör alla tre molnen, eller förväntar dig att köra dem, behandlar den säkrare designen varje leverantörs KMS som en regional verkställighetspunkt under ett centraliserat nyckel- och certifikatstyrningslager, snarare än tre oberoende sanningskällor som glider isär över tid. Det lagret spårar vilka nycklar som finns var, vilken skyddsnivå och rotationspolicy var och en använder, och vilket team som äger det – ett arbete som ingen av AWS KMS, Azure Key Vault eller GCP Cloud KMS gör åt dig mellan leverantörer.

För den fullständiga referensarkitekturen, se vår Multi-Cloud PKIaaS Architecture Guide för AWS, Azure och GCP . För bakgrundsinformation om varför detta är viktigt redan innan du når tre moln, täcker vårt utbildningscenter nyckelhantering för flera moln och de funktioner som kommersiella nyckelhanteringslösningar delar.

Vilka är begränsningarna för varje tjänst?

• AWS KMSEn nyckel lämnar aldrig den region där den skapades, så en strategi för flera regioner behöver explicita nycklar för flera regioner, inte en standardnyckel; KMS kan inte använda en datanyckel för att kryptera eller dekryptera åt dig, så applikationer måste hantera det själva.
• Azure Key VaultExtern nyckelhantering är fortfarande i förhandsgranskningsläge, täcks inte av Managed HSM SLA och stöder endast wrap/unwrap; Managed HSM begränsar varje nyckel till 100 versioner, och frekvent rotation räknas mot det taket.
• GCP Cloud KMSCloud EKM stöder idag endast tre namngivna externa nyckelhanteringspartners (Fortanix, Futurex, Thales); att rotera en nyckel krypterar aldrig data under gamla versioner automatiskt, så pensionerade versioner måste rensas manuellt för att kontrollera kostnader och risker.

Checklista för beslut: Att välja mellan AWS KMS, Azure Key Vault och GCP Cloud KMS

1. Börja med var dina arbetsbelastningar redan finns. Inbyggd integration med dina beräknings-, lagrings- och databastjänster uppväger marginella funktionsskillnader mellan de tre KMS-erbjudandena.
2. Bestäm din nyckelkontrollmodell per dataklassificering, inte en gång för hela organisationen — inbyggt för de flesta arbetsbelastningar, BYOK där viktig härkomst måste dokumenteras, HYOK endast där en tillsynsmyndighet eller ett avtal kräver det.
3. Anpassa din rotationspolicy till varje leverantörs faktiska begränsningar — Azure Managed HSM:s minimum på 28 dagar och gränsen på 100 versioner måste i synnerhet utformas kring i förväg, inte upptäckas under en granskning.
4. Modellkostnad vid din verkliga nyckel- och operationsvolym, inte rubriken per nyckel eller per åtgärd – GCP:s prissättning per skyddsnivå och Azures nivåindelade HSM-nyckelavgifter ändras båda avsevärt i stor skala.
5. Om du kör mer än ett moln idag, eller förväntar dig att göra det inom 18 månader, utvärdera ett centraliserat nyckel- och certifikathanteringslager innan du har tre oberoende, driftande KMS-konfigurationer att stämma av.

Vad skulle krypteringskonsulter rekommendera?

För en enda molnbutik, använd molnets inbyggda KMS och övertänk inte – alla tre är mogna, FIPS-validerade tjänster. Beslutet blir verkligen svårt i det ögonblick du kör två eller fler moln, eftersom inget av AWS KMS, Azure Key Vault eller GCP Cloud KMS byggdes för att ge dig en överblick över de andra. I våra engagemang är de organisationer som kämpar de som antog varje molns KMS oberoende och sedan försökte bygga ut styrningen i efterhand. Vi rekommenderar att du bestämmer din nyckelförvaringsmodell (inbyggd, BYOK eller HYOK) och dina rotations- och loggningsstandarder en gång, centralt, genom HSM-as-a-Service för FIPS-validerad förvaring som sträcker sig över leverantörer, innan enskilda team standardiserar vad deras molnkonsol än använder som standard. Om du behöver en extern bedömning av var din nuvarande nyckelposition för flera moln står, jämför vår Cloud Data Protection-bedömning AWS-, Azure- och GCP-miljöer mot NIST- och CIS-kontroller.

Vanliga frågor om partihandel med mat och dryck

Vilket är säkrast: AWS KMS, Azure Key Vault eller GCP Cloud KMS?

Alla tre är FIPS-validerade hanterade tjänster från leverantörer med mogna säkerhetsresultat, och ingen är kategoriskt mindre säker än de andra för standardanvändning med nativa nycklar. De betydande säkerhetsskillnaderna syns i detaljerna: hårdvaruvalideringsnivå per nivå, om HYOK är allmänt tillgängligt eller fortfarande i förhandsvisning, och hur noggrant du konfigurerar IAM och loggning – inte i vilken leverantörslogotyp som finns på tjänsten.

Kan jag använda samma krypteringsnyckel i AWS, Azure och GCP?

Inte direkt. Varje leverantörs inbyggda nyckel lämnar aldrig leverantörens gränser avsiktligt. Det närmaste man kommer en delad nyckel över moln är HYOK: att vara värd för nyckelmaterialet i din egen externa nyckelhanterare och att varje moln anropar det (AWS External Key Store, Azure External Key Management eller GCP Cloud EKM), vilket låter en nyckelmaterialkälla hantera flera moln på bekostnad av att göra din externa nyckelhanterare till en enda felpunkt för dem alla.

Är Azure Key Vault Managed HSM samma sak som HYOK?

Nej. Managed HSM är ett dedikerat hårdvarualternativ för en enda hyresgäst som fortfarande körs inuti Microsofts infrastruktur – det är ett starkare alternativ för native nyckelringar, inte ett externt. Azures faktiska HYOK-motsvarighet är External Key Management, en separat förhandsgranskningsfunktion som delegerar wrap/unwrap-åtgärder till en nyckelhanterare som du kör utanför Azure.

Varför tar GCP mer betalt för externa (EKM) nycklar än för HSM-nycklar?

Google prissätter EXTERNAL- och EXTERNAL_VPC-nyckelversionerna till 3.00 dollar/månad, tre gånger HSM-priset på 1.00 dollar/månad, eftersom varje kryptografisk operation mot en EKM-nyckel kräver en live nätverksresa till din externa nyckelhanterare snarare än ett lokalt HSM-anrop. Den ökade latensen och beroendet är också anledningen till att Google uttryckligen varnar för att förlust av åtkomst till en extern nyckel kan orsaka permanent, oåterkallelig dataförlust.

Behöver jag en strategi för nyckelhantering i flera moln om jag bara använder ett moln idag?

Inte omedelbart, men det är värt att bestämma din nyckelkontrollmodell, rotationspolicy och loggstandard som om du skulle lägga till ett andra moln, eftersom det är mycket mer störande att anpassa dessa beslut senare än att ställa in dem konsekvent från början. Om ett andra moln redan finns på din färdplan, starta det styrningslagret nu snarare än efter migreringen.

Kontakta [email protected] om du vill ha hjälp med granskning eller arkitektur av nyckelhantering i AWS, Azure och GCP.