Hur säkra är Amazons nyckelhanteringstjänster (AWS KMS)?

AWS Key Management Service (AWS KMS) är ryggraden för kryptografisk nyckelhantering för över 100 AWS-tjänster och är det mest distribuerade moln-KMS:et globalt. Det är viktigt eftersom säkerheten för varje krypterat S3-objekt, EBS-volym, RDS-databas och Lambda-hemlighet beror på hur KMS-nycklar är konfigurerade och vem som kontrollerar dem. Det rekommenderade utvärderingsramverket för alla arbetsbelastningar är: verifiera den FIPS-valideringsnivå som ditt efterlevnadsramverk kräver, bekräfta att kundhanterade nycklar används (inte AWS-hanterade eller AWS-ägda), se till att CloudTrail Data Access-loggar är aktiverade och bestäm om standardmodellen för flera hyresgäster, KMS, eller ett dedikerat CloudHSM-kluster, är rätt för din hotmodell.

Snabbt svar: Hur säkert är AWS KMS?

AWS KMS är kryptografiskt säkert för de allra flesta företags- och reglerade arbetsbelastningar. Nyckelmaterial genereras och lagras i FIPS 140-2 nivå 2-validerade HSM:er och lämnar aldrig HSM-gränsen i klartext. Nycklar är regionbundna och kan inte exporteras eller användas utanför AWS-regionen där de skapades. Varje kryptografisk operation loggas i CloudTrail med den begärande identiteten, nyckel-ARN, tidsstämpel och käll-IP. Den primära säkerhetsgränsövervägningen är att standard AWS KMS är en hanterad tjänst med flera hyresgäster, vilket innebär att AWS driver den underliggande HSM-hårdvaran. För arbetsbelastningar som kräver noll AWS-operativ åtkomst till nyckelmaterial bör BYOK (importerat nyckelmaterial) eller HYOK (klientsideskryptering) utvärderas. För arbetsbelastningar som kräver FIPS 140-2 nivå 3 dedikerad hårdvara för en enda hyresgäst krävs AWS CloudHSM.

Key Takeaways

• Standard AWS KMS använder FIPS 140-2 nivå 2-validerade HSM:er: Nyckelmaterial genereras och används inuti HSM:er med flera hyresgäster som är FIPS 140-2 nivå 2-validerade. CloudHSM tillhandahåller nivå 3-hårdvara för en enda hyresgäst när det krävs enligt föreskrifter.
• AWS kan inte använda dina kundhanterade nycklar utan ett autentiserat API-anrop: Kundhanterade KMS-nycklar kan endast användas för kryptografiska operationer när en autentiserad begäran klarar både nyckelpolicy- och IAM-policykontrollerna. AWS kan inte initiera nyckelanvändning åt dig.
• Kundhanterade nycklar är den enda typen som tillhandahåller en granskningslogg per operation: Endast kundhanterade nycklar genererar CloudTrail-händelser för varje GenerateDataKey- och Decrypt-anrop som är kopplade till en specifik IAM-identitet. AWS-hanterade och AWS-ägda nycklar ger inte denna granularitet.
• BYOK ger dig nyckelproveniens och omedelbar återkallelse; HYOK exkluderar AWS helt: BYOK (importerat nyckelmaterial) uppfyller kraven för kundgenererat nyckelmaterial. HYOK (klientsideskryptering före uppladdning) innebär att nyckeln aldrig kommer in i AWS alls. Det är den starkaste suveränitetsmodellen men har den högsta operativa komplexiteten.
• S3 Bucket Key minskar KMS API-kostnaderna med upp till 99 % för S3-arbetsbelastningar: Att aktivera S3 Bucket Key innebär att S3 genererar DEK:er på objektnivå lokalt istället för att anropa KMS för varje objekt som läses och skrivs, vilket dramatiskt minskar KMS API-anropsvolymen och kostnaden utan att ändra säkerhetsegenskaperna.

Vad är AWS Key Management Service (KMS)?

AWS Key Management Service (AWS KMS) är en hanterad tjänst som skapar och kontrollerar de kryptografiska nycklar som används för att skydda data i AWS-tjänster och -applikationer. AWS KMS är nyckelhanteringsryggraden för AWS-molnet: när du aktiverar kryptering på en S3-bucket, en EBS-volym, en RDS-databas eller en Secrets Manager-hemlighet genererar, lagrar och skyddar AWS KMS de nycklar som gör krypteringen meningsfull.

AWS KMS lagrar allt nyckelmaterial i hårdvarusäkerhetsmoduler (HSM) som är validerade enligt FIPS 140-2 nivå 2. Nyckelmaterial som genereras i AWS KMS lämnar aldrig HSM-gränsen i klartext under några driftsförhållanden. AWS KMS integreras direkt med över 100 AWS-tjänster, inklusive Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda, AWS Secrets Manager, Amazon Redshift och Amazon EFS. Nycklar som lagras i flera tillgänglighetszoner säkerställer hög tillgänglighet. Själva KMS-tjänsten ger cirka 99.999 % hållbarhet för nyckelmaterial.

AWS KMS säkerhetsarkitektur: Vad gör den säker

För att förstå hur säker AWS KMS är krävs det att man förstår den förtroendegräns den verkar inom och de invarianter den upprätthåller.

HSM-hårdvarugräns: Allt KMS-nyckelmaterial genereras och används inuti FIPS 140-2 nivå 2-validerade HSM:er. HSM:erna är utformade så att nyckelmaterial inte kan extraheras i klartext av någon part, inklusive AWS-anställda. Nyckeloperationer (GenerateDataKey, Encrypt, Decrypt, Sign, Verify) utförs inom HSM-gränsen och endast resultatet returneras till anroparen. Inget nyckelmaterial i klartext lämnar någonsin HSM:en.

Regionisolering: Nycklar som skapats i en AWS KMS-region kan inte användas eller nås från en annan region. En nyckel som skapats i us-east-1 kan inte användas för att dekryptera data i eu-west-1. Denna regionala isolering är en systemnivåinvariant som tillämpas på hårdvaru- och mjukvarulagret, inte bara en policykontroll.

Nyckelpolicy som obligatorisk åtkomstkontroll: Varje kundhanterad KMS-nyckel har en nyckelpolicy som är den primära och obligatoriska åtkomstkontrollmekanismen. Om nyckelpolicyn inte uttryckligen ger en principal behörighet att använda nyckeln, kan den principalen inte använda den oavsett IAM-identitetspolicy. Detta innebär att inte ens en AWS-kontorotanvändare kan använda en kundhanterad nyckel för att utföra kryptografiska operationer om inte nyckelpolicyn uttryckligen tillåter det.

Vad AWS kan och inte kan göra: AWS driver HSM-hårdvaran och hanterar KMS-tjänstinfrastrukturen. AWS kan inte anropa din kundhanterade nyckel åt dig för att utföra kryptografiska operationer. Det kräver en autentiserad API-begäran som klarar både nyckelpolicy- och IAM-policykontrollerna. AWS har inte insyn i klartextnyckelmaterialet för kundhanterade nycklar. Men som operatör av den underliggande HSM-hårdvaran ligger AWS inom förtroendegränsen för nyckelmaterialets fysiska säkerhet. Detta är den grundläggande skillnaden mellan standardarkitekturer för AWS KMS och BYOK/HYOK.

AWS KMS-nyckeltyper: Kundhanterade, AWS-hanterade och AWS-ägda

AWS KMS organiserar nycklar i tre typer med fundamentalt olika säkerhets-, kontroll- och efterlevnadsegenskaper. AWS döpte om "Customer Master Keys (CMKs)" till "KMS nycklar" år 2021, men de tre underliggande typerna förblir desamma.

Kundhanterade KMS-nycklar skapas av dig i ditt AWS-konto. Du definierar nyckelpolicyn, kontrollerar vem som kan använda och hantera nyckeln, konfigurerar automatisk rotation och kan inaktivera eller schemalägga nyckeln för radering. Varje GenerateDataKey- och Decrypt-anrop genererar en CloudTrail-händelse med nyckel-ARN, som begär IAM-identitet, käll-IP och tidsstämpel. Denna revisionslogg per operation är den efterlevnadsfunktion som kundhanterade nycklar tillhandahåller och andra nyckeltyper inte. Kundhanterade nycklar kostar 1 USD per nyckel per månad plus 0.03 USD per 10 000 API-anrop.

AWS-hanterade KMS-nycklar skapas automatiskt av AWS-tjänster första gången du aktiverar kryptering utan att ange en kundhanterad nyckel. De följer aliasmönstret aws/service-name (till exempel, aws/s3, aws/ebsDu kan visa deras metadata men inte ändra deras nyckelpolicy, inaktivera dem, schemalägga borttagning eller kontrollera rotation. AWS roterar dem automatiskt vart tredje år. De genererar begränsade CloudTrail-granskningsposter och tillhandahåller inte den identitetslänkade granskningsloggen per operation som efterlevnadsramverk kräver.

AWS-ägda KMS-nycklar ägs och hanteras helt av AWS och delas mellan flera kundkonton. De är osynliga i ditt AWS-konto, genererar inga CloudTrail-händelser i ditt konto och du har ingen kontroll över dem. De är lämpliga för icke-känslig data där noll hanteringskostnader är prioriterade, men är olämpliga för någon reglerad arbetsbelastning.

Kuvertkryptering: Hur AWS KMS skyddar data

AWS KMS använder kuvertkryptering för att effektivt skydda stora mängder data. AWS KMS krypterar inte dina data direkt. KMS-nycklar kan bara kryptera data upp till 4 KB i storlek direkt. Istället använder AWS KMS kuvertkrypteringsmönstret: en KMS-nyckel (Key Encryption Key, eller KEK) krypterar en datakrypteringsnyckel (DEK), och DEK krypterar själva informationen.

Skydda själva krypteringsnyckeln: DEK:n krypteras med KMS-nyckeln (CMK) så att den krypterade DEK:n kan lagras säkert tillsammans med den krypterade informationen. Ingen av dem kan användas utan den andra, och KMS-nyckeln som behövs för att packa upp DEK:n är skyddad inuti KMS HSM:erna.

Effektivitet i stor skala: Istället för att anropa KMS för varje enskild dataoperation anropar applikationen KMS en gång för att generera och kryptera en DEK, använder den klartextbaserade DEK:n lokalt för att kryptera potentiellt gigabyte data och kasserar sedan den klartextbaserade DEK:n. Endast den krypterade DEK:n behöver lagras med data. Detta minskar KMS API-anrop dramatiskt jämfört med direkt KMS-kryptering av varje datapost.

Algoritmstyrka: Kuvertkryptering möjliggör kombination av symmetriska och asymmetriska algoritmer. DEK för datakryptering är vanligtvis AES-256 (snabb och stark för bulkdata). KEK i KMS kan vara en asymmetrisk RSA- eller ECC-nyckel för specifika användningsfall, eller en symmetrisk AES-256-nyckel för de flesta användningsfall för datakryptering.

Datanycklar och datanyckelpar

Datanycklar är de krypteringsnycklar som används för att faktiskt kryptera data och andra datakrypteringsnycklar. AWS KMS genererar datanycklar men lagrar, hanterar eller spårar dem inte. Datanycklar används och hanteras utanför AWS KMS av applikationen eller AWS-tjänsten.

Skapa en datanyckel: Ring upp GenerateDataKey anger vilken KMS-nyckel som ska användas som KEK. KMS returnerar två kopior: en klartextdatanyckel för omedelbar användning och en krypterad datanyckel (omsluten av den angivna KMS-nyckeln). Lagra den krypterade datanyckeln. Applikationen krypterar data med klartextnyckeln och tar sedan bort klartextnyckeln från minnet.

Kryptera data med en datanyckel: Använd datanyckeln i klartext för att kryptera data utanför AWS KMS och radera sedan nyckeln i klartext från minnet. Lagra den krypterade datanyckeln tillsammans med chiffertexten.

Dekryptera data med en datanyckel: Ring Decrypt operation för att dekryptera den krypterade datanyckeln, vilket returnerar datanyckeln i klartext. Använd datanyckeln i klartext för att dekryptera informationen och ta sedan bort den från minnet omedelbart.

Datanyckelpar är asymmetriska nyckelpar (RSA eller ECC) som genereras av AWS KMS för kryptering, signering och verifiering på klientsidan utanför AWS KMS. Den privata nyckeln för varje datanyckelpar skyddas av en symmetrisk KMS-nyckel. Stödda specifikationer för asymmetriska nyckelpar inkluderar RSA 2048, 3072 och 4096 bitar för kryptering och dekryptering, och ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521 och ECC_SECG_P256K1 för signering och verifiering.

Kryptera med ett datanyckelpar: Den publika nyckeln krypterar data; den privata nyckeln (dekrypterad från sin krypterade form av KMS) dekrypterar den.

Signering och verifiering med ett datanyckelpar: Den privata nyckeln i klartext (återställd genom att anropa Decrypt på den krypterade privata nyckeln) signerar ett meddelande. Vem som helst med motsvarande publika nyckel kan verifiera signaturen. Den privata nyckeln i klartext måste tas bort från minnet efter användning.

Följande tabell sammanfattar AWS KMS kryptografiska operationer efter nyckeltyp och nyckelanvändning:

Drift	KMS-nyckeltyp	Nyckelanvändning
Avkryptera	Symmetrisk / Asymmetrisk	KRYPTERA_DEKRYPTERA
Kryptera	Symmetrisk / Asymmetrisk	KRYPTERA_DEKRYPTERA
Generera datanyckel	Symmetrisk	KRYPTERA_DEKRYPTERA
GenereraDataKeyUtanOformateradText	Symmetrisk	KRYPTERA_DEKRYPTERA
GenereraDataKeyPair	Symmetrisk (skyddar asymmetriska par)	KRYPTERA_DEKRYPTERA
GenereraDataKeyPairUtanOformateradText	Symmetrisk (skyddar asymmetriska par)	KRYPTERA_DEKRYPTERA
Kryptera om	Symmetrisk / Asymmetrisk	KRYPTERA_DEKRYPTERA
Anmäl	Asymmetrisk	SIGN_VERIFY
Verifiera	Asymmetrisk	SIGN_VERIFY
GenereraMac	HMAC	GENERERA_VERIFIERA_MAC
VerifieraMac	HMAC	GENERERA_VERIFIERA_MAC

IAM-modell: Nyckelpolicy och identitetspolicy för åtkomstkontroll

AWS KMS-åtkomstkontroll är den oftast felkonfigurerade aspekten av KMS-distributioner. Felkonfiguration är också den vanligaste faktiska säkerhetsrisken för AWS KMS: HSM-gränsen skyddar mot nyckelutvinning, men en alltför tillåtande nyckelpolicy eller IAM-policy kan ge obehöriga principaler möjligheten att använda nyckeln för kryptografiska operationer.

Nyckelpolicy (obligatorisk resursbaserad policy): Varje kundhanterad KMS-nyckel har en nyckelpolicy. Nyckelpolicyn är den primära och obligatoriska åtkomstkontrollmekanismen. Till skillnad från de flesta AWS-resurspolicyer måste KMS-nyckelpolicyn finnas och uttryckligen bevilja behörigheter. Ingen nyckelpolicy betyder ingen åtkomst. Om nyckelpolicyn innehåller satsen som beviljar root-kontots nyckelhanteringsbehörigheter (standardnyckelpolicyn som skapats av konsolen), kan IAM-identitetspolicyer i det kontot också bevilja nyckelhanteringsbehörigheter till principaler. Utan den rotdelegeringssatsen kan IAM-policyer inte bevilja åtkomst till nyckeln oavsett deras innehåll.

IAM-identitetspolicy (sekundärt lager): En IAM-policy som är kopplad till en användare, roll eller grupp kan bevilja KMS-behörigheter, men bara om nyckelpolicyn också tillåter principalen. För dataplansåtgärder (Kryptera, Dekryptera, GenereraDataKey, Signera), tillämpa lägsta behörighet i både nyckelpolicyn och IAM-identitetspolicyn: bevilja endast de specifika operationsbehörigheterna, endast på det specifika nyckel-ARN, endast till det specifika tjänstkonto som kräver dem.

Separation av nyckeladministratör från nyckelanvändare: Den viktigaste IAM-säkerhetsprincipen för KMS är att separera nyckeladministratörsrollen (som kan hantera nyckelpolicyer, rotera, inaktivera, ta bort) från nyckelanvändarrollen (som kan anropa Kryptera, Dekryptera, GenereraDataKey). Applikationstjänstkonton ska endast ha de kryptografiska driftsbehörigheter de behöver för specifika nycklar, aldrig nyckelhanteringsbehörigheter. En säkerhetsdriftsroll hanterar nycklar; applikationstjänstkonton använder dem.

Tjänstkontrollpolicyer (SCP:er): Om dina AWS-konton finns i en AWS-organisation tillhandahåller SCP:er ett skyddslager ovanför IAM. Använd SCP:er för att neka borttagning av produktions-KMS-nycklar, kräva specifika krypteringsstandarder över tjänster eller förhindra inaktivering av KMS-relaterad CloudTrail-loggning. SCP:er kan inte bevilja behörigheter. De begränsar bara de maximala behörigheterna som är tillgängliga för alla principaler i kontot.

Beviljanden: Beviljanden är tillfälliga, programmatiska behörigheter som kan skapas, användas och tas bort utan att ändra nyckelpolicyn eller IAM-policyn. De är användbara för att ge AWS-tjänster (som AWS Lambda eller Amazon S3) behörighet att använda en KMS-nyckel åt dig för en specifik operation eller ett tidsfönster utan att ändra den permanenta nyckelpolicyn. Beviljanden ingår i utvärderingen av åtkomstkontroll tillsammans med nyckelpolicyer och IAM-policyer.

BYOK och HYOK: När inbyggd KMS inte räcker

Standardmodellen för AWS KMS (AWS genererar och hanterar nyckelmaterial i HSM:er med flera hyresgäster) är lämplig för de flesta reglerade arbetsbelastningar. Två modeller finns för organisationer som behöver starkare garantier för nyckelsuveränitet.

BYOK (Bring Your Own Key): Du genererar AES-256-nyckelmaterial i din egen HSM eller nyckelhanteringssystem, omsluter det med en omslutande nyckel som laddats ner från ett AWS KMS-importjobb och importerar det till en KMS-nyckel med Ursprung inställt på EXTERN. AWS KMS använder ditt importerade nyckelmaterial för alla kryptografiska operationer. Du behåller det ursprungliga nyckelmaterialet i din egen HSM. Om du omedelbart och permanent tar bort den importerade kopian från KMS återkallas AWS möjlighet att använda nyckeln. BYOK ger dig nyckelproveniens (du kan bevisa att nyckeln genererades i en FIPS-validerad HSM som du kontrollerar) och omedelbar oberoende återkallelse. AWS har fortfarande operativ åtkomst till nyckelmaterialet under användning, och automatisk rotation är inte tillgänglig för importerade nycklar.

HYOK (Hold Your Own Key): Krypteringsnyckeln kommer aldrig in i AWS alls. Din applikation krypterar data innan den laddas upp till någon AWS-tjänst. AWS lagrar endast chiffertext och kan inte dekryptera dina data under några omständigheter, inklusive en rättslig begäran riktad mot AWS. Detta är den enda modellen som helt exkluderar AWS från nyckelförtroendekedjan. Varje läsning och skrivning kräver ett anrop till ditt externa nyckelhanteringssystem, vilket måste vara mycket tillgängligt. Encryption Consultings HSM as a Service tillhandahåller den externa FIPS 140-2 Level 3-nyckelhanteringsinfrastrukturen för HYOK-implementeringar på AWS.

Dimensionera	Native KMS (AWS-genererad)	BYOK (Importerat nyckelmaterial)	HYOK (klientsidan, nyckel utanför AWS)
Nyckel genererad av	AWS KMS HSM	Kundens HSM (importerad till KMS)	Kund (kommer aldrig in i AWS)
AWS-åtkomst till nyckel under användning	Ja (HSM-gräns för flera hyresgäster)	Ja (operativ åtkomst)	Nej
CloudTrail-granskningslogg	Ja (per operation)	Ja (per operation)	Nej (endast externa KMS-loggar)
Oberoende återkallelse	Inaktivera/ta bort nyckel via API	Ta bort importerat material (omedelbart)	Återkalla vid extern KMS
Automatisk nyckelrotation	Ja (90 dagar till 7 år)	Nej (manuell återimport krävs)	Helt kundstyrd
Viktigt proveniensbevis	AWS intygar generering i FIPS HSM	Kunden kan bevisa sin egen HSM-generering	Helt kundstyrd
FIPS-nivå	Nivå 2 (standard) / Nivå 3 (CloudHSM)	Nivå 2 eller 3 (beroende på målbutik)	Beror på externt KMS
Operationell komplexitet	Låg	Medium	Hög
Bäst för	De flesta reglerade arbetsbelastningar	Arbetsbelastningar som kräver kundnyckelns ursprung	Hemligstämplat, suveränitetsmandat, nollförtroende

CloudTrail-granskningsloggning: Efterlevnadsgranskningsspåret

AWS KMS-integration med CloudTrail är en av dess starkaste säkerhetsfunktioner för reglerade arbetsbelastningar. Varje AWS KMS API-anrop genererar en CloudTrail-händelse som registrerar nyckel-ARN, operationen, den begärande IAM-identiteten, käll-IP-adressen, AWS-regionen och tidsstämpeln. Denna revisionslogg per operation är det som gör att du kan bevisa för en PCI DSS QSA- eller HIPAA-revisor exakt vem som åtkom vilka data och när.

CloudTrail-hanteringshändelser (nyckelskapande, nyckelpolicyändringar, nyckelrotationshändelser, ScheduleKeyDeletion, DisableKey) är aktiverade som standard och kan inte inaktiveras. CloudTrail-datahändelser (GenereateDataKey- och Decrypt-anrop per objekt, per operation) måste aktiveras separat, eftersom de kan generera hög volym och kostnad. För reglerade arbetsbelastningar är det obligatoriskt att aktivera KMS-datahändelser i CloudTrail: detta är loggen som registrerar varje dekrypteringsoperation mot specifika data, kopplade till den begärande identiteten.

Viktiga säkerhetsaviseringar att konfigurera från CloudTrail KMS-händelser: avisering omedelbart vid ScheduleKeyDeletion och DisableKey för alla produktionsnycklar; avisering vid dekrypteringsanrop från IAM-principaler som inte finns i den godkända rolllistan för den nyckeln; avisering vid dekrypteringshändelser med hög volym som kan indikera dataexfiltrering; och avisering vid PutKeyPolicy-ändringar på alla produktionsnycklar som kan utöka åtkomsten.

Nyckelrotation i AWS KMS

Automatisk nyckelrotation i AWS KMS genererar nytt kryptografiskt material för en kundhanterad nyckel enligt ett konfigurerbart schema. Det nya nyckelmaterialet blir den primära versionen för alla nya krypteringsåtgärder. Tidigare nyckelversioner behålls permanent så att data som krypterats med dem fortfarande kan dekrypteras. Nyckel-ARN och alla alias förblir oförändrade. Rotationen är helt transparent för applikationer. Du behöver inte kryptera om några befintliga data.

Rotationsperioden kan konfigureras mellan 90 dagar och 7 år. För de flesta efterlevnadsarbetsbelastningar är 90 dagar till 1 år standardintervallet. PCI DSS-krav 3.7.4 hänvisar till periodiska symmetriska nyckelkryptoperioder; kontakta din QSA för det specifika kravet i din scoped-miljö. Varje rotationshändelse genererar en RotateKey CloudTrail-händelse för efterlevnadsbevis. Rotation på begäran (utanför det automatiska schemat) är tillgänglig via RotateKeyOnDemand API, användbart efter en misstänkt nyckelkomprometteringshändelse.

För BYOK-nycklar med importerat material är automatisk rotation inte tillgänglig. Du måste generera nytt nyckelmaterial i din externa HSM, importera det som en ny nyckelversion och ange det som primärversion. Du måste planera detta inom din definierade kryptoperiod för att upprätthålla efterlevnad.

AWS KMS-kostnad och S3 Bucket Key-optimering

Kundhanterade KMS-nycklar kostar 1 dollar per nyckel och månad. AWS-hanterade och AWS-ägda nycklar har ingen nyckellagringsavgift. Alla KMS API-anrop kostar 0.03 dollar per 10 000 förfrågningar. För S3-arbetsbelastningar med hög volym som använder kundhanterade nycklar kan kostnaden för KMS API-anrop per objekt (en GenerateDataKey per PutObject, en Decrypt per GetObject) ackumuleras avsevärt.

S3 Bucket Key är lösningen. När S3 Bucket Key är aktiverat på en bucket genererar S3 en kortlivad datanyckel på bucketnivå från din KMS-nyckel och använder den för att kryptera enskilda objektdatanycklar lokalt inom S3, istället för att anropa KMS för varje objekt. Detta minskar KMS API-anrop med upp till 99 % för S3-arbetsbelastningar. En arbetsbelastning som genererar 10 miljoner S3-operationer per månad skulle normalt generera 10 miljoner KMS API-anrop (~30 USD/månad i KMS-avgifter); med Bucket Key aktiverad sjunker det till nästan noll i KMS-avgifter. S3 Bucket Key ändrar inte krypteringens säkerhetsegenskaper: objekt skyddas fortfarande av AES-256-GCM-kryptering under en nyckelhierarki som spåras tillbaka till din kundhanterade KMS-nyckel.

Skapa kundhanterade KMS-nycklar

Skapa en kundhanterad symmetrisk KMS-nyckel via AWS Management Console:

1. Logga in på AWS Management Console och öppna AWS KMS-konsolen.
2. Välj AWS-regionen i det övre högra hörnet.
3. Välj Kundhanterade nycklar i navigeringsfönstret.
4. Välj Skapa nyckel.
5. I Nyckeltyp väljer du Symmetrisk. I Nyckelanvändning väljer du Kryptera och dekryptera.
6. Klicka på Nästa.
7. Skapa ett alias för nyckeln (ett namn som är läsbart för människor, t.ex. prod/s3/data-lake).
8. Lägg till en beskrivning. (Valfritt men rekommenderas för styrning)
9. Klicka på Nästa.
10. Lägg till taggar för kostnadsallokering och åtkomstkontroll. (Valfritt)
11. Klicka på Nästa.
12. Välj IAM-användare och roller som kan administrera nyckeln (nyckeladministratörer som hanterar nyckelns livscykel men inte använder den för dataoperationer).
13. Om du inte vill att nyckeladministratörer ska kunna ta bort den här nyckeln avmarkerar du kryssrutan Tillåt nyckeladministratörer att ta bort den här nyckeln.
14. Klicka på Nästa.
15. Välj IAM-användare och roller som kan använda nyckeln för kryptografiska operationer (nyckelanvändare, vanligtvis applikationstjänstkonton).
16. För att tillåta andra AWS-konton att använda den här nyckeln, lägg till deras konto-ID:n i avsnittet Andra AWS-konton.
17. Klicka på Nästa.
18. Granska den viktigaste policyn som genererats från dina val.
19. Klicka på Slutför för att skapa nyckeln.

Att skapa en kundhanterad asymmetrisk KMS-nyckel följer samma steg förutom: i steg 5 väljer du Asymmetrisk för Nyckeltyp; i Nyckelanvändning väljer du antingen Kryptera och dekryptera eller Signera och verifiera; och i Nyckelspecifikation väljer du algoritmspecifikationen (RSA_2048, RSA_3072, RSA_4096, ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521 eller ECC_SECG_P256K1).

AWS CloudHSM: När FIPS 140-2 nivå 3 krävs

AWS CloudHSM är en kundägd HSM-tjänst med en enda hyresgäst som tillhandahåller FIPS 140-2 nivå 3-validerade hårdvarusäkerhetsmoduler i din egen Amazon VPC. Till skillnad från standard AWS KMS, som är multi-tenant och hanteras helt av AWS, tillhandahåller CloudHSM dedikerad fysisk HSM-hårdvara exklusivt för din organisation. Inga andra kunders nycklar eller kryptografiska operationer delar hårdvaran med din.

Med CloudHSM hanterar AWS den fysiska infrastrukturen (racking, nätverk, strömförsörjning, firmwareuppdateringar) men har ingen åtkomst till dina nycklar eller dina HSM-partitioner. Du hanterar HSM-programvaran, partitionerna och nyckelmaterialet direkt via HSM:s eget hanteringsgränssnitt med hjälp av hårdvarutokens (PED) eller smartkortsautentisering. Detta är den viktigaste skillnaden från standard KMS: med CloudHSM kan AWS inte komma åt ditt nyckelmaterial ens i drift.

Användningsfall för CloudHSM inkluderar: skydd av privata CA-nycklar för PKI-infrastruktur, privata nycklar för kodsignering och dokumentsignering, huvudnycklar för transparent datakryptering (TDE) för databaser, BYOK-källa för nycklar importerade till KMS eller andra system, och kryptering av PIN-koder för betalningar. CloudHSM nås via PKCS#11, JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation) eller OpenSSL Dynamic Engine API:er.

AWS CloudHSM-prissättning: cirka 1.45 USD per timme per HSM-instans, cirka 2 100 USD per månad för ett HA-kluster med två instanser (rekommenderat minimum för produktion).

Anpassad nyckelbutik: CloudHSM-stödda KMS-nycklar

AWS KMS anpassade nyckelarkiv kombinerar KMS API med CloudHSM Level 3-hårdvara. När du skapar en KMS-nyckel i ett anpassat nyckelarkiv genererar KMS en 256-bitars AES-GCM-nyckel i ditt CloudHSM-kluster. Nyckelmaterialet kan inte exporteras och lämnar aldrig CloudHSM HSM:erna i klartext. Alla kryptografiska operationer på nycklar i ett anpassat nyckelarkiv utförs i ditt CloudHSM-kluster, inte i standard KMS HSM-infrastruktur för flera hyresgäster.

Anpassade nyckelarkiv kräver minst två aktiva HSM:er i olika tillgänglighetszoner. Om CloudHSM-klustret blir otillgängligt kan KMS inte utföra åtgärder på nycklar i det anpassade nyckelarkivet. Din applikations tillgänglighet beror på ditt CloudHSM-klusters tillgänglighet. Anpassade nyckelarkiv är lämpliga för FedRAMP High-arbetsbelastningar som kräver FIPS 140-2 nivå 3, för eIDAS-kvalificerade signaturåtgärder eller för organisationer som behöver använda befintlig CloudHSM-infrastruktur som KMS-nyckelstöd. Se vår dedikerade guide om AWS KMS-djupdykning för den fullständiga nyckelhierarkins mekanik.

AWS KMS vs. CloudHSM: Vilken ska du välja?

Fast egendom	AWS KMS (Standard)	AWS CloudHSM
Hyresmodell	Flerhyresgäster (delad HSM-hårdvara)	Enskild hyresgäst (dedikerad HSM-hårdvara)
FIPS 140-2-validering	Nivå 2	Nivå 3
AWS-åtkomst till viktigt material	Ja (som HSM-operatör)	Nej (kunden kontrollerar HSM-partitioner)
Huvudansvarigt ledningsansvar	AWS hanterar helt	Delat: AWS hanterar hårdvara, kunden hanterar HSM-programvara och nycklar
API-integration	AWS KMS API, 100+ inbyggda tjänsteintegrationer	PKCS#11, JCE, CNG, OpenSSL (ej inbyggt i de flesta AWS-tjänster utan anpassad nyckellagring)
Automatisk nyckelrotation	Ja (90 dagar till 7 år)	Nej (manuellt, kundstyrt)
Hög tillgänglighet	AWS-hanterad, inbyggd	Kräver minst 2-HSM-kluster i flera AZ:er
CloudTrail-integration	Ja (fullständig loggning per operation)	Begränsad (HSM-åtgärder loggade i HSM-granskningsloggen, inte direkt i CloudTrail)
Pris	1 USD/nyckel/månad + 0.03 USD/10 000 API-anrop	~1.45 USD/timme per HSM (~2 100 USD/månad för 2-HSM HA-kluster)
Bäst för	De flesta reglerade arbetsbelastningar, hanterad efterlevnad, bred AWS-tjänstintegration	FIPS nivå 3-krav, PKI CA-nycklar, ingen AWS-nyckelåtkomst, anpassade PKCS#11-applikationer

Arkitektur för nyckelhantering i flera moln

AWS KMS är AWS-nativt och omfattar inte Azure, GCP eller lokala system. Organisationer med arbetsbelastningar i flera moln behöver en explicit nyckelstyrningsstrategi för alla leverantörer. Tre mönster hanterar AWS KMS i ett multimolnkontext:

• KMS per moln med enhetlig styrning: Använd AWS KMS för AWS-arbetsbelastningar, Azure Key Vault för Azure och GCP Cloud KMS för GCP, med en centraliserad plattform för nyckellivscykelhantering som aggregerar inventering, rotationsstatus och granskningsloggar för alla tre. Detta bevarar inbyggd prestanda och integration samtidigt som det ger insyn i molnöverskridande efterlevnad.
• Centraliserad BYOK från en extern HSM: Generera allt nyckelmaterial från en enda extern HSM eller HSM som en tjänst som är oberoende av alla molnleverantörer. Importera härledda nycklar till AWS KMS för AWS-arbetsbelastningar, Azure Key Vault för Azure och GCP Cloud KMS för GCP. All kryptering spåras tillbaka till en enda auktoritativ nyckelkälla. Krypteringskonsultföretag HSM som en tjänst tillhandahåller den externa FIPS 140-2 nivå 3 HSM-infrastrukturen för den här modellen, åtkomlig från AWS, Azure och GCP samtidigt.
• Klientsideskryptering (HYOK): Kryptera all data innan den når någon molnleverantör med hjälp av en nyckel som finns i ditt eget externa nyckelhanteringssystem. Alla moln lagrar endast chiffertext. Starkaste suveränitetsmodell för flera moln men kräver att applikationer hanterar alla kryptografiska operationer på klientsidan och att ditt externa KMS har hög tillgänglighet.

Efterlevnad: PCI DSS, FedRAMP, HIPAA och DORA

PCI DSS v4.0.1 (obligatoriskt sedan 31 mars 2025): Kundhanterade KMS-nycklar uppfyller krav 3.5.1 (skydd av lagrade PAN:er med stark kryptografi). KMS med CloudHSM anpassad nyckellagring uppfyller krav 3.7.1 (nyckelgenerering med en HSM). CloudTrail Data Access-händelser för KMS uppfyller krav 10 (granskningsloggning). Automatisk rotation stöder krav 3.7.4 (hantering av kryptoperioder). AWS-hanterade nycklar ensamma uppfyller inte PCI DSS eftersom de inte tillhandahåller någon identitetslänkad granskningslogg per operation och ingen kundnyckelkontroll.

FedRAMP: Standard AWS KMS (FIPS 140-2 Nivå 2) uppfyller FedRAMP Moderate SC-12 (Cryptographic Key Establishment and Management). FedRAMP High kräver FIPS 140-2 Nivå 3-validerade moduler under SC-12 och SC-28; detta kräver antingen en anpassad nyckellagring för CloudHSM eller direkt AWS CloudHSM. Både AWS KMS och CloudHSM ingår i AWS FedRAMP High-auktoriseringspaket.

HIPAA: Kundhanterade KMS-nycklar uppfyller HIPAA:s tekniska skyddsåtgärd för kryptering och dekryptering (45 CFR 164.312(a)(2)(iv)) för ePHI i vila. AWS Business Associate Agreement (BAA) täcker AWS KMS, vilket gör det kvalificerat för ePHI-arbetsbelastningar. CloudTrail Data Access-händelser uppfyller HIPAA:s revisionskontrollstandard (45 CFR 164.312(b)).

DORA (Digital Operational Resilience Act, tillämplig på finansiella enheter i EU sedan den 17 januari 2025): DORA-artiklarna 9 och 10 kräver IKT-riskhantering och tester av operativ motståndskraft, inklusive motståndskraft för nyckelhantering. AWS KMS:s replikering av flera AZ-nyckelringar, automatisk rotationskapacitet och CloudTrail-granskningsloggning stöder DORA:s krav på nyckelhantering. Finansiella enheter i EU som använder AWS KMS bör verifiera att deras KMS-nyckelregion ligger inom EU för att uppfylla kraven på datalagring och säkerställa att CloudTrail-loggar lagras i EU-baserad lagring.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är ett företag inom tillämpad kryptografi med ISO/IEC 27001:2022- och SOC 2-certifieringar. Vi hjälper organisationer att utvärdera, designa, implementera och granska AWS KMS-konfigurationer från initial säkerhetsbedömning till kontinuerlig generering av efterlevnadsbevis.

• AWS KMS säkerhetsbedömning: Vi utvärderar er nuvarande AWS KMS-konfiguration mot er hotmodell och efterlevnadskrav, och identifierar luckor (AWS-ägda eller AWS-hanterade nycklar där kundhanterade nycklar krävs, nyckelpolicyer som beviljar bred åtkomst, saknad CloudTrail Data Access-loggning, avsaknad av rotationsscheman, S3-buckets utan Bucket Key aktiverad). Vi utformar målarkitekturen inklusive nyckelhierarki per tjänst och dataklassificering, IAM-separation av administratör från användare, SCP-skydd och routning av granskningsloggar. Se vår molnrådgivningstjänster.
• HSM som en tjänst för BYOK och HYOK: För BYOK-implementeringar som kräver FIPS 140-2 Level 3-nyckelgenerering utanför AWS, eller för klientsidiga HYOK-arkitekturer som kräver ett externt nyckelhanteringssystem, Encryption Consultings HSM som en tjänst tillhandahåller dedikerad HSM-infrastruktur som integrerar med AWS KMS-nyckelimportarbetsflöden. Lämplig som BYOK-källa för AWS, Azure och GCP samtidigt.
• CBOM Säker för AWS KMS Discovery: AWS-miljöer med många konton ackumulerar ofta inkonsekventa KMS-konfigurationer: vissa tjänster använder AWS-ägda nycklar, andra använder AWS-hanterade nycklar, andra använder kundhanterade nycklar med inkonsekventa policyer. Krypteringskonsultföretagets CBOM-säkerhet upptäcker och inventerar alla KMS-nyckelkonfigurationer, åtkomstpolicyer, rotationsstatusar och CloudTrail-loggningsgap över AWS-konton, och genererar en kryptografisk materiallista (CBOM) i CycloneDX-format som stöder efterlevnadsdokumentation för PCI DSS v4.0.1 krav 12.3.3.
• PCI DSS och FedRAMP-efterlevnadsrådgivning: Vi kartlägger er AWS KMS-konfiguration enligt de specifika kraven i PCI DSS v4.0.1, FedRAMP High, HIPAA, DORA och NIST SP 800-53 Rev. 5. Vi identifierar kontrollbrister, tar fram ett paket med bevis för efterlevnad och bistår med QSA- och bedömarförfrågningar. Se vår Rådgivning om efterlevnad.
• PQC-beredskap för AWS KMS: NIST slutförde postkvantkryptografistandarderna FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) i augusti 2024. NIST IR 8547 pekar mot att RSA och ECC avskrivs för nya användningsområden runt 2030. Asymmetriska nycklar för AWS KMS RSA och ECC som används för signering och nyckelutbyte kommer att behöva migreras. Encryption Consultings PQC-beredskap Tjänsten mappar din AWS KMS-nyckelfastighet mot tidslinjen efter kvantmigreringen och utformar nyckelrotation och algoritmövergångssekvens.

För att diskutera er AWS KMS-säkerhetsställning eller efterlevnadskrav, kontakta Encryption Consulting.

Slutsats

AWS KMS är kryptografiskt korrekt för de allra flesta företags- och reglerade arbetsbelastningar. Nyckelmaterial stannar kvar i FIPS 140-2 nivå 2-validerade HSM:er och lämnas aldrig i klartext. Varje operation på en kundhanterad nyckel loggas i CloudTrail. Nyckelpolicyn och IAM-policyn ger en skiktad, obligatorisk åtkomstkontroll som AWS inte kan kringgå för att använda din nyckel utan en autentiserad API-begäran.

De ärliga säkerhetsbegränsningarna för standard AWS KMS är: det är en tjänst med flera hyresgäster där AWS driver den underliggande hårdvaran; den tillhandahåller inte FIPS 140-2 Level 3-hårdvaruisolering utan ett anpassat CloudHSM-nyckellager; och AWS-hanterade och AWS-ägda nycklar tillhandahåller ingen revisionslogg per operation och ingen kundnyckelkontroll. För arbetsbelastningar där dessa begränsningar är viktiga (FedRAMP High, sekretessbelagda data, suveränitetsmandat eller nolltrust-arkitekturer där molnleverantören själv finns i hotmodellen) är svaret CloudHSM, BYOK eller HYOK.

Att få rätt nyckeltyp, nyckelpolicydesign, IAM-separation, CloudTrail Data Access-loggning och rotationsschema från början är betydligt enklare än att åtgärda en stor AWS-egendom efter att en efterlevnadsrevision identifierat luckor. För den operativa mekaniken i AWS KMS utöver säkerhetsutvärderingen, se vår djupgående granskning av AWS Key Management Service.

Vanliga frågor om partihandel med mat och dryck

Hur säkert är AWS KMS?

AWS KMS är mycket säkert för de flesta företags- och reglerade arbetsbelastningar. Nyckelmaterial genereras och lagras i FIPS 140-2 nivå 2-validerade HSM:er med flera hyresgäster och lämnar aldrig HSM:en i klartext. Nycklar är regionbundna. Varje kundhanterad nyckeloperation loggas i CloudTrail. Den primära säkerhetsgränsövervägningen är att AWS driver den underliggande HSM-hårdvaran, vilket gör AWS till en operativ part i nyckelförtroendekedjan. För arbetsbelastningar som kräver nivå 3-hårdvara för en enda hyresgäst eller ingen AWS-nyckelåtkomst krävs CloudHSM eller HYOK.

Kan AWS komma åt mina KMS-nycklar?

AWS driver HSM-hårdvaran som lagrar KMS-nyckelmaterial och som ligger inom den fysiska förtroendegränsen. AWS kan inte anropa din kundhanterade nyckel åt dig för att utföra kryptografiska operationer utan en autentiserad API-begäran som klarar dina nyckelpolicy- och IAM-policykontroller. För arbetsbelastningar där ingen AWS-operativ åtkomst till nyckelmaterial är ett krav bör BYOK (importerat nyckelmaterial, där du behåller originalet utanför AWS och kan ta bort den importerade kopian) eller HYOK (klientsideskryptering, där nyckeln aldrig kommer in i AWS alls) användas.

Vad är skillnaden mellan AWS KMS och AWS CloudHSM?

AWS KMS är en fullständigt hanterad nyckelhanteringstjänst för flera hyresgäster med FIPS 140-2 nivå 2-validerade HSM:er. AWS hanterar hårdvaran. Du kontrollerar nyckelpolicyer och rotation. AWS CloudHSM tillhandahåller dedikerad fysisk HSM-hårdvara för en enda hyresgäst, validerad enligt FIPS 140-2 nivå 3, inom din VPC. AWS hanterar endast den fysiska infrastrukturen; du hanterar HSM-programvaran, partitionerna och nyckelmaterialet själv. AWS har ingen åtkomst till dina CloudHSM-nycklar. CloudHSM krävs när dedikerad hårdvara på nivå 3 är obligatorisk eller när AWS måste undantas från nyckelförtroendegränsen.

Vad är BYOK i AWS KMS och hur påverkar det säkerheten?

BYOK innebär att generera AES-256-nyckelmaterial i din egen HSM, omsluta det med en importnyckel för jobbomslutning och importera det till en KMS-nyckel (ursprung: EXTERN). AWS använder ditt importerade material för alla kryptografiska operationer. Du behåller originalet utanför AWS; om du tar bort den importerade kopian från KMS återkallas åtkomsten omedelbart. BYOK lägger till kontroll av nyckelprovenien och oberoende återkallelse, men AWS har fortfarande operativ åtkomst till nyckelmaterialet under användning. Automatisk rotation är inte tillgänglig för importerade nycklar.

Uppfyller AWS KMS kraven för PCI DSS och FedRAMP?

Standard AWS KMS med kundhanterade nycklar uppfyller PCI DSS v4.0.1-kraven 3.5.1, 3.7.4 och 10 när CloudTrail Data Access-loggning är aktiverad. PCI DSS-krav 3.7.1 (HSM-nyckelgenerering) kräver ett anpassat CloudHSM-nyckellager (nivå 3). För FedRAMP High uppfyller inte standard KMS (nivå 2) FIPS 140-2 nivå 3-kravet enligt SC-12; anpassat CloudHSM-nyckellager krävs. Både AWS KMS och CloudHSM finns i AWS FedRAMP High-auktoriseringspaket.

Hur fungerar nyckelrotation i AWS KMS och påverkar det befintlig krypterad data?

Automatisk rotation genererar nytt nyckelmaterial för en kundhanterad nyckel enligt ett schema som du konfigurerar (90 dagar till 7 år). Det nya materialet blir primärt för nya krypteringsåtgärder. Tidigare versioner behålls permanent för att dekryptera äldre data. Nyckel-ARN förblir detsamma; rotationen är transparent för applikationer och ingen omkryptering av data behövs. För BYOK-nycklar med importerat material är automatisk rotation inte tillgänglig; du måste manuellt generera och importera nytt nyckelmaterial som en ny nyckelversion.