Djupdykning i AWS Key Management Service

AWS Key Management Service (AWS KMS) är det centraliserade nyckelhanteringslagret för AWS-molnet, som kontrollerar krypteringsnycklarna som skyddar data i mer än 100 AWS-tjänster och kundapplikationer. Detta är viktigt eftersom säkerheten för varje krypterat S3-objekt, EBS-volym, RDS-databas och Lambda-hemlighet beror på vem som kontrollerar KMS-nycklarna som skyddar dem och hur dessa nycklar styrs. Den rekommenderade utgångspunkten är att skapa kundhanterade KMS-nycklar med en explicit nyckelpolicy, som möjliggör automatisk rotation och konfigurerar CloudTrail för att fånga varje krypterings- och dekrypteringshändelse som är kopplad till en autentiserad identitet.

Snabbt svar: Vilken AWS KMS-nyckeltyp ska du använda?

För reglerade arbetsbelastningar: använd alltid kundhanterade KMS-nycklar. De är den enda typen som ger dig en oberoende revisionslogg per operation i CloudTrail, en nyckelpolicy som du kontrollerar, möjligheten att inaktivera eller ta bort nyckeln oberoende och stöd för BYOK (importerat nyckelmaterial). För allmänna arbetsbelastningar där efterlevnad inte kräver kundnyckelkontroll: AWS-hanterade nycklar är acceptabla och kräver ingen driftsomkostnad. AWS-ägda nycklar ger ingen revisionslogg och ingen kundinsyn; undvik dem för känsliga data. För det högsta nyckelskyddskravet (FIPS 140-2 Nivå 3 med dedikerad hårdvara): använd en anpassad nyckelarkiv som backas upp av AWS CloudHSM.

Key Takeaways

• KMS-nyckelmaterial lämnar aldrig HSM i klartext: Alla KMS-nycklar genereras och används i FIPS 140-2-validerade HSM:er. Standard-KMS använder nivå 2; anpassade nyckelarkiv som stöds av CloudHSM använder nivå 3.
• AWS KMS använder kuvertkryptering för allt dataskydd: KMS genererar och skyddar datakrypteringsnycklar (DEK). KMS-nyckeln krypterar DEK:n; DEK:n krypterar data. Själva KMS-nyckeln krypterar aldrig data direkt.
• Kundhanterade nycklar krävs för efterlevnadsgranskningsspår: Endast kundhanterade nycklar genererar CloudTrail-händelser per operation (GenereateDataKey, Decrypt) kopplade till specifika IAM-identiteter.
• Både nyckelpolicy och IAM-policy måste tillåta en åtgärd: AWS KMS-åtkomstkontroll kräver både nyckelresurspolicyn och den anropande principalens IAM-identitetspolicy för att tillåta åtgärden. Ingetdera ensamt är tillräckligt i de flesta konfigurationer.
• Automatisk rotation kräver inte att befintliga data krypteras om: När en KMS-nyckel roteras behåller KMS tidigare nyckelversioner för att dekryptera data som krypterats före rotationen. Nyckelns ARN förblir densamma; applikationer behöver inte uppdateras.

Vad är AWS Key Management Service?

AWS Key Management Service (AWS KMS) är en hanterad kryptografisk nyckelhanteringstjänst som skapar, lagrar och kontrollerar åtkomst till krypteringsnycklarna som skyddar AWS-arbetsbelastningar. När du aktiverar kryptering på en S3-bucket, en EBS-volym, en RDS-instans eller en Secrets Manager-hemlighet genererar och skyddar AWS KMS de nycklar som gör krypteringen meningsfull.

AWS KMS lagrar allt nyckelmaterial i hårdvarusäkerhetsmoduler (HSM) validerade enligt FIPS 140-2 nivå 2 för standard KMS-nycklar. Nyckelmaterial som genereras i AWS KMS lämnar aldrig HSM-gränsen i klartext. När en AWS-tjänst eller applikation behöver kryptera eller dekryptera data anropas KMS API:et, KMS utför nyckeloperationen i HSM och returnerar endast resultatet. 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, Amazon EFS och AWS Systems Manager Parameter Store.

Hur AWS KMS använder kuvertkryptering

AWS KMS krypterar inte dina data direkt. Den använder kuvertkryptering: en huvudnyckel (KMS-nyckeln) skyddar en datakrypteringsnyckel (DEK), och DEK krypterar själva informationen. Kuvertkryptering håller datakrypteringen lokal samtidigt som nyckeln skyddas i hårdvaran, eftersom KMS-nycklar aldrig lämnar HSM och stora datanylaster inte kan skickas till KMS för direkt kryptering.

Skrivoperation: applikationsanropen kms:GenerateDataKeyKMS genererar en ny DEK inuti HSM och returnerar en klartext-DEK och en krypterad DEK. Applikationen krypterar data med klartext-DEK:n, kasserar klartext-DEK:n omedelbart och lagrar den krypterade DEK:n tillsammans med chiffertexten. Den krypterade DEK:n kan bara packas upp av KMS med den ursprungliga KMS-nyckeln.

Läsoperation: applikationen skickar den krypterade DEK:n till KMS via kms:DecryptKMS packar upp den inuti HSM och returnerar DEK i klartext. Applikationen dekrypterar data och kasserar omedelbart DEK i klartext. KMS-nyckeln lämnar aldrig HSM; endast DEK flyttas mellan KMS och applikationen.

AWS KMS-nyckeltyper: AWS-hanterad, kundhanterad och AWS-ägd

AWS KMS organiserar nycklar i tre typer med avsevärt olika kontroll-, synlighets- och efterlevnadsegenskaper. Namnet ändrades 2021 från CMK (Customer Master Key) till KMS-nyckel, men de underliggande typerna förblir desamma.

Kundhanterade KMS-nycklar

Kundhanterade nycklar skapas av dig i ditt AWS-konto. Du definierar nyckelpolicyn, kontrollerar vem som kan använda och hantera nyckeln, aktiverar eller inaktiverar nyckeln, schemalägger borttagning och konfigurerar automatisk rotation. GenerateDataKey och Decrypt Anropet genererar en CloudTrail-händelse med nyckel-ARN, den begärande IAM-principalen, käll-IP:n och en tidsstämpel. Denna revisionslogg per operation är den centrala efterlevnadsfunktionen som kundhanterade nycklar tillhandahåller och andra nyckeltyper inte gör. Kundhanterade nycklar kostar 1 USD per nyckel per månad plus 0.03 USD per 10 000 API-anrop. De stöder tre viktiga materialursprung: AWS-genererad, BYOK (importerad) och anpassad nyckellagring (CloudHSM-baserad).

AWS-hanterade KMS-nycklar

AWS-hanterade nycklar skapas automatiskt av AWS-tjänster första gången du aktiverar kryptering utan att ange en kundhanterad nyckel. Aliaset följer mönstret aws/service-name (till exempel, aws/s3, aws/ebs, aws/rds). Du kan visa nyckelmetadata men kan inte ändra nyckelpolicyn, inaktivera nyckeln, schemalägga borttagning eller styra rotation. AWS roterar automatiskt AWS-hanterade nycklar vart tredje år. Ingen extra kostnad utöver standardavgifter för API-anrop.

AWS-ägda KMS-nycklar

AWS-ägda nycklar ägs och hanteras helt av AWS och delas mellan flera kundkonton. De är inte synliga i din KMS-konsol, du har ingen kontroll över dem och de genererar inga CloudTrail-händelser i ditt konto. Lämplig för icke-känsliga data där noll hanteringskostnader är prioriterade, men olämplig för reglerade arbetsbelastningar som kräver en revisionslogg eller kundnyckelkontroll.

Fast egendom	Kundhanterad nyckel	AWS-hanterad nyckel	AWS-ägd nyckel
Skapad av	Kund	AWS-tjänst	AWS
Synlig i ditt konto	Ja	Ja	Nej
Viktig policykontroll	Fullständig kundkontroll	Ingen	Ingen
Inaktivera/ta bort funktionen	Ja	Nej	Nej
CloudTrail-händelser per operation	Ja (varje GenerateDataKey och Decrypt)	Begränsad	Nej
Automatisk rotation	Valfritt (90 dagar till 7 år)	Ja (vartannat år)	Varierar
BYOK-stöd	Ja	Nej	Nej
Pris	1 USD/nyckel/månad + 0.03 USD/10 000 API-anrop	0.03 USD/10 000 API-anrop endast	Utan kostnad
Bäst för	Reglerade arbetsbelastningar, efterlevnad, revisionskrav	Allmänna arbetsbelastningar, låga omkostnader	Icke-känsliga scenarier utan hantering

Symmetriska, asymmetriska och HMAC KMS-nycklar

Symmetriska KMS-nycklar använder en enda 256-bitars AES-GCM-nyckel för både kryptering och dekryptering. Nyckelmaterialet lämnar aldrig AWS KMS i klartext. Symmetriska nycklar är korrekta för de flesta användningsområden för dataskydd: kryptering av S3-objekt, EBS-volymer, RDS-databaser och Secrets Manager-hemligheter. De flesta AWS-tjänster som integreras med KMS stöder endast symmetriska nycklar.

Asymmetriska KMS-nycklar innehåller ett offentligt/privat nyckelpar. Den privata nyckeln lämnar aldrig KMS i klartext. Den offentliga nyckeln kan laddas ner och användas utanför KMS. Asymmetriska KMS-nycklar stöder RSA (för kryptering/dekryptering eller signering/verifiering) och ECDSA (endast för signering/verifiering). Använd asymmetriska nycklar när du behöver en offentlig nyckel att distribuera till externa parter medan den privata nyckeln förblir skyddad i KMS. AWS-tjänster som krypterar data i vila använder uteslutande symmetriska nycklar.

HMAC KMS-nycklar genererar och verifierar hashbaserade meddelandeautentiseringskoder för tokenvalidering, API-förfrågningssignering och verifiering av dataintegritet. De använder symmetriskt nyckelmaterial men tjänar autentisering snarare än krypteringsändamål.

IAM-modell: Hur åtkomstkontroll fungerar i AWS KMS

AWS KMS-åtkomstkontroll är den vanligaste felkonfigurerade aspekten av KMS-distributioner. Den tvåskiktade policymodellen kräver både nyckelresurspolicyn och den anropande principalens IAM-identitetspolicy för att tillåta en åtgärd.

Nyckelpolicy (resursbaserad policy): Varje kundhanterad KMS-nyckel har en obligatorisk nyckelpolicy som är den primära åtkomstkontrollmekanismen. Om nyckelpolicyn inte uttryckligen ger en IAM-principal behörighet att använda nyckeln, kan den principalen inte använda nyckeln oavsett dess IAM-identitetspolicy. Om nyckelpolicyn innehåller satsen som ger rotkontots nyckelhanteringsbehörigheter, kan IAM-policyer i det kontot ge nyckelhanteringsbehörigheter till principaler i kontot. Detta är standardpolicyn som skapas av KMS-konsolen.

IAM-identitetspolicy: En IAM-identitetspolicy 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.

Separation av nyckelhantering från nyckelanvändning: Separera rollen nyckeladministratör (som kan hantera nyckelpolicyer, rotation, borttagning och inaktivera/aktivera) från rollen nyckelanvändare (som kan anropa Kryptera, Dekryptera, GenereraDataKey). Programtjänstkonton ska endast ha de specifika kryptografiska operationsbehörigheter de behöver för specifika nycklar, aldrig nyckelhanteringsbehörigheter.

Tjänstkontrollpolicyer (SCP:er): I en AWS-organisation tillhandahåller SCP:er ett skyddslager ovanför IAM-policyer. Använd en SCP för att neka borttagning av KMS-nycklar i produktionen, kräva kryptering på specifika tjänster eller förhindra att KMS-loggning inaktiveras via CloudTrail. SCP:er fungerar som en maximal behörighetsgräns; de kan inte bevilja behörigheter, bara begränsa dem.

BYOK i AWS KMS: Ta med ditt eget nyckelmaterial

BYOK (Bring Your Own Key) i AWS KMS innebär att man importerar nyckelmaterial som genererats utanför AWS till en KMS-nyckel. BYOK används när regelverk eller intern policy kräver att krypteringsnyckelmaterial genereras i kundstyrd infrastruktur och att kunden behåller det ursprungliga nyckelmaterialet oberoende av AWS.

BYOK-importprocessen: skapa en KMS-nyckel utan nyckelmaterial (Ursprung: EXTERNAL); ladda ner den omslutande publika nyckeln och importera token från KMS; generera 256-bitars AES-nyckelmaterial i din egen HSM; kryptera ditt nyckelmaterial med den omslutande publika nyckeln (RSA_OAEP_SHA_256); ladda upp det krypterade nyckelmaterialet och importera token till KMS. KMS dekrypterar nyckelmaterialet inuti HSM och lagrar det som KMS-nyckelns nyckelmaterial.

BYOK-begränsningar: du kan ange ett utgångsdatum för importerat nyckelmaterial, varefter KMS automatiskt tar bort det. Du kan manuellt ta bort importerat nyckelmaterial utan att ta bort nyckeln, vilket omedelbart gör all data som krypterats med det oåtkomlig tills den importeras på nytt. Automatisk rotation är inte tillgänglig för BYOK-nycklar; du måste generera nytt material externt och importera det på nytt.

HYOK: Håll din egen nyckel

HYOK (Hold Your Own Key) går längre än BYOK: krypteringsnyckeln kommer aldrig in i AWS KMS alls. Din applikation krypterar data på klientsidan innan den laddas upp till någon AWS-tjänst, med hjälp av en nyckel som genereras och lagras i din egen infrastruktur. AWS lagrar endast chiffertext och kan inte dekryptera dina data under några omständigheter, inklusive vid rättsliga krav riktade mot AWS.

HYOK är lämpligt för sekretessbelagda data, suveränitetskrav där AWS-infrastrukturen ligger utanför din förtroendegräns eller arbetsbelastningar där din hotmodell inkluderar AWS självt. Varje läsning och skrivning kräver en tur och retur 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 som behövs för att implementera HYOK för AWS-arbetsbelastningar.

Dimensionera	Native KMS (AWS-genererad nyckel)	BYOK (Importerat nyckelmaterial)	HYOK (klientsidan, nyckel utanför AWS)
Nyckel genererad av	AWS KMS HSM	Kund (importerad till KMS)	Kund (kommer aldrig in i AWS)
AWS-åtkomst till nyckel under användning	Ja	Ja (i drift)	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 rotation	Ja (90 dagar till 7 år)	Nej (manuell återimport krävs)	Helt kundstyrd
Operationell komplexitet	Låg	Medium	Hög
Bäst för	De flesta AWS-arbetsbelastningar	Reglerad: kundens nyckelproveni krävs	Hemligstämplat, nollförtroende, suveränitetsmandat

KMS Anpassad Nyckelförvaring: FIPS 140-2 Nivå 3 med CloudHSM

Ett anpassat KMS-nyckelarkiv associerar AWS KMS med ett AWS CloudHSM-kluster som du äger och hanterar. KMS-nyckelmaterial genereras och lagras i ditt CloudHSM-kluster på FIPS 140-2 nivå 3, snarare än standardinfrastrukturen för KMS nivå 2. Nycklar i ett anpassat nyckelarkiv är 256-bitars AES-GCM, kan inte exporteras och lämnar aldrig CloudHSM HSM:erna i klartext. Alla kryptografiska operationer utförs inuti ditt CloudHSM-kluster.

Anpassade nyckelarkiv kräver minst två aktiva HSM:er i olika tillgänglighetszoner. Om klustret blir otillgängligt kan KMS inte utföra åtgärder på dessa nycklar, vilket innebär att din applikationstillgänglighet beror på ditt CloudHSM-kluster. Anpassade nyckelarkiv är lämpliga för FedRAMP High-arbetsbelastningar som kräver FIPS 140-2 nivå 3, eIDAS-kvalificerade signaturåtgärder eller organisationer med befintlig CloudHSM-infrastruktur som vill ha nivå 3-validering inom KMS API-upplevelsen.

Nyckelrotation i AWS KMS

AWS KMS-nyckelrotation genererar nytt kryptografiskt material för en KMS-nyckel och markerar den som aktiv version för nya krypteringsoperationer, samtidigt som alla tidigare nyckelversioner för dekryptering av data som krypterats före rotationen behålls. Nyckel-ARN, nyckel-ID och alla alias förblir oförändrade. Applikationer fortsätter att fungera efter rotationen utan några konfigurationsändringar.

För kundhanterade nycklar med AWS-genererat material kan automatisk rotation konfigureras mellan 90 dagar och 7 år. När rotation sker genererar KMS nytt nyckelmaterial inuti HSM, markerar det som aktivt och loggar en RotateKey CloudTrail-händelse. Tidigare materialversioner behålls på obestämd tid.

För BYOK-nycklar med importerat material är automatisk rotation inte tillgänglig. Du måste hantera rotationen manuellt: generera nytt 256-bitars AES-nyckelmaterial utanför AWS, importera det som en ny nyckelversion och ange det som primärt material. Rotation på begäran för kundhanterade nycklar med AWS-genererat material är tillgänglig när som helst via RotateKeyOnDemand API, användbart efter en misstänkt nyckelexponeringshändelse.

CloudTrail-loggning för AWS KMS

Varje AWS KMS API-anrop genererar som standard en CloudTrail-hanteringshändelse. Varje kryptering, dekryptering, nyckelskapande, nyckelborttagning och policyändring loggas med den begärande identiteten, nyckel-ARN, tidsstämpel och käll-IP. Viktiga händelser att övervaka och varna för:

• GenereraDataKey: Loggas när en tjänst eller applikation skapar en ny datakrypteringsnyckel. Avisering om oväntade principaler som genererar datanycklar.
• Avkryptera: Loggas när en tjänst eller applikation dekrypterar en datakrypteringsnyckel. Avisering vid alla dekrypteringsanrop från en principal som inte finns i listan över godkända roller. Dekrypteringsanrop med hög volym kan tyda på dataexfiltrering.
• Schemalägg nyckelborttagning: Avisera omedelbart om en produktionsnyckel som är schemalagd för radering. KMS tillämpar en väntetid på minst 7 dagar.
• Avaktivera nyckel: Avisera omedelbart. En inaktiverad nyckel stoppar alla krypterings- och dekrypteringsåtgärder, vilket orsakar omedelbara avbrott.
• PutKeyPolicy: Aviseringar om alla ändringar i nyckelpolicyn för produktionsnycklar. Policyändringar kan utöka eller begränsa åtkomst till nyckeln.
• RoteraKey / RoteraKeyPåBegäran: Logga för bevis på efterlevnad. Oväntade rotationshändelser bör undersökas.

Dirigera CloudTrail-loggar till en separat, skrivskyddad S3-bucket i ett dedikerat säkerhetskonto. Aktivera integritetsvalidering av CloudTrail-loggfiler. Aktivera S3-datahändelser separat eftersom objektnivååtgärder inte registreras i hanteringshändelseloggar som standard.

AWS KMS-kostnad: Prissättning och optimering

Kundhanterade 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 ackumuleras KMS API-kostnader eftersom varje S3 PutObject genererar ett GenerateDataKey anrop och varje GetObject genererar ett Decrypt anrop. En S3-arbetsbelastning med 10 miljoner PUT- och GET-operationer per månad genererar cirka 60 dollar per månad i KMS API-avgifter.

Funktionen S3 Bucket Key minskar denna kostnad med upp till 99 %. När den är aktiverad genererar S3 en kortlivad datanyckel på bucket-nivå från din KMS-nyckel och använder den för att generera individuella objekt-DEK:er lokalt inom S3, istället för att anropa KMS för varje objekt. Säkerhetsegenskaperna är oförändrade; objekten förblir krypterade med AES-256-GCM under en nyckelhierarki som spåras tillbaka till din KMS-nyckel. För anpassade nyckellagringsnycklar som backas upp av CloudHSM kostar klustret cirka 1.45 USD per timme per HSM-instans, cirka 2 100 USD per månad för ett HA-kluster med två instanser, utöver standard KMS-avgifter.

AWS KMS i multimoln- och hybridarkitekturer

AWS KMS är AWS-nativt och kan inte utökas direkt till Azure, GCP eller lokala system. Tre mönster hanterar AWS KMS i ett multimolnkontext:

• KMS per moln med enhetlig styrning: Använd AWS KMS för AWS, Azure Key Vault för Azure och GCP Cloud KMS för GCP, men distribuera en centraliserad plattform för nyckellivscykelhantering som aggregerar nyckelinventering, rotationsstatus och granskningsloggar över alla tre. Detta bevarar inbyggd molnprestanda 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. Importera härledda nycklar till AWS KMS som BYOK-nycklar, till Azure Key Vault och till GCP Cloud KMS. 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.
• Klientsideskryptering med en delad nyckel (HYOK): Kryptera all data innan den når någon molnleverantör. AWS KMS är inte inblandat; molnet lagrar endast chiffertext. Starkast suveränitetsmodell för flera moln men kräver att applikationer hanterar kryptografiska operationer på klientsidan och att ditt externa KMS har hög tillgänglighet.

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 designa, implementera och granska AWS KMS-konfigurationer från initial nyckelarkitektur till kontinuerlig generering av efterlevnadsbevis.

• Råd om molndataskydd: Vi utvärderar er AWS KMS-konfiguration, identifierar luckor (AWS-ägda nycklar där kundhanterade nycklar krävs, saknade nyckelpolicyer, frånvarande CloudTrail-datahändelser, S3-buckets utan Bucket Key-optimering, överpermissiva nyckelpolicyer) och utformar målnyckelhierarkin, IAM-modellen, rotationsschemat och revisionskonfigurationen. Se vår molnrådgivningstjänster.
• HSM som en tjänst: För BYOK- och HYOK-arkitekturer som kräver FIPS 140-2 Level 3-nyckelgenerering utanför AWS, Encryption Consultings HSM som en tjänst tillhandahåller dedikerad HSM-infrastruktur som integrerar med AWS KMS-nyckelimportflöden, lämplig som BYOK-källa över AWS, Azure och GCP samtidigt.
• CBOM-säker: Krypteringskonsulttjänster CBOM-säkerhet upptäcker och inventerar alla KMS-nyckelkonfigurationer, åtkomstpolicyer och rotationsstatusar över AWS-konton, och genererar en kryptografisk materiallista i CycloneDX-format som stöder efterlevnadsdokumentation för PCI DSS v4.0.1 krav 12.3.3.
• PKI som en tjänst: För AWS-arbetsbelastningar som använder ömsesidig TLS mellan tjänster eller driftsättning av AWS Private CA för intern certifikatutfärdande, Encryption Consultings PKI som en tjänst tillhandahåller en hanterad privat CA med ACME-automatiserad certifikatlivscykelhantering och KMS-baserad CA-nyckellagring. Se även vår guide om AWS S3-klient- och serversideskryptering.
• PQC-beredskap: 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 kommer att behöva migreras. Encryption Consultings PQC-beredskap Tjänsten mappar din AWS KMS-nyckelfastighet mot tidslinjen efter kvantmigreringen.
• Efterlevnadsrådgivning: Vi mappar er AWS KMS-konfiguration till kraven i PCI DSS v4.0.1, FedRAMP, HIPAA, DORA, NIST CSF 2.0 och NIST SP 800-53 Rev. 5, identifierar luckor, bygger en åtgärdsplan och tar fram ett revisionsbevispaket. Se vår Rådgivning om efterlevnad.

För att diskutera er AWS KMS-arkitektur eller efterlevnadskrav, kontakta Encryption Consulting.

Slutsats

AWS KMS är nyckelhanteringsgrunden för AWS-molnet. Valet mellan AWS-hanterade, kundhanterade och BYOK-nycklar är ett beslut om efterlevnad och suveränitet som avgör om din organisation har en oberoende revisionslogg, oberoende återkallningsfunktion och oberoende nyckelproveni.

De vanligaste felkonfigurationerna för KMS är användning av AWS-hanterade eller AWS-ägda nycklar där efterlevnad kräver kundhanterade nycklar, alltför tillåtande nyckelpolicyer som ger bred KMS-åtkomst till applikationsroller, frånvarande eller felkonfigurerade CloudTrail-datahändelser som lämnar luckor i revisionsloggen, och saknad S3 Bucket Key-konfiguration som i onödan ökar kostnaderna för KMS API. Att få dessa rätt från början är betydligt enklare än att åtgärda dem i en stor AWS-egendom efter att en efterlevnadsrevision har avslöjat dem.

Vanliga frågor om partihandel med mat och dryck

Vad är AWS Key Management Service (AWS KMS)?

AWS Key Management Service (AWS KMS) är en hanterad tjänst som skapar och kontrollerar krypteringsnycklar som används för att skydda data i AWS-tjänster och applikationer. AWS KMS lagrar nyckelmaterial i FIPS 140-2-validerade HSM:er (nivå 2 för standardnycklar, nivå 3 för anpassade nyckellagringsnycklar). Nyckelmaterial lämnar aldrig HSM:en i klartext. AWS KMS integreras direkt med över 100 AWS-tjänster, inklusive S3, EBS, RDS, Lambda och Secrets Manager.

Vad är skillnaden mellan AWS-hanterade nycklar, kundhanterade nycklar och AWS-ägda nycklar?

AWS-hanterade nycklar skapas automatiskt av AWS-tjänster; du kan visa dem men inte ändra deras policy, inaktivera dem eller styra rotation. Kundhanterade nycklar skapas av dig med fullständig kontroll över nyckelpolicyer, CloudTrail-granskningslogg per operation och möjligheten att inaktivera eller ta bort; de kostar 1 dollar per nyckel och månad. AWS-ägda nycklar är osynliga för dig, delas mellan konton och genererar inga CloudTrail-händelser. För reglerade arbetsbelastningar krävs kundhanterade nycklar.

Hur fungerar kuvertkryptering i AWS KMS?

AWS KMS genererar en datakrypteringsnyckel (DEK) när den anropas av en tjänst eller applikation, och returnerar en klartext-DEK och en krypterad kopia. Applikationen krypterar data med klartext-DEK:n, kasserar den och lagrar endast den krypterade DEK:n tillsammans med chiffertexten. För att dekryptera skickar applikationen den krypterade DEK:n till KMS, som dekrypterar den inuti HSM:n och returnerar klartext-DEK:n. KMS-nyckeln lämnar aldrig HSM:n; endast DEK:n flyttas mellan KMS och applikationen.

Vad är BYOK i AWS KMS och hur fungerar det?

BYOK innebär att generera nyckelmaterial i din egen HSM och importera det till en AWS KMS-nyckel med Origin inställt på EXTERNAL. Du laddar ner en wrapper-nyckel från KMS, krypterar ditt nyckelmaterial med den och laddar upp det krypterade materialet. AWS KMS använder ditt material för kryptografiska operationer men du behåller originalet utanför AWS. Du kan ta bort det importerade materialet från KMS för att omedelbart återkalla användbarheten. Automatisk rotation är inte tillgänglig för BYOK-nycklar.

Hur fungerar nyckelrotation i AWS KMS?

Automatisk rotation genererar nytt nyckelmaterial inuti KMS HSM enligt ett schema som du konfigurerar (90 dagar till 7 år för kundhanterade nycklar). Tidigare materialversioner behålls för att dekryptera data som krypterats före rotationen. Nyckel-ARN och nyckel-ID förblir oförändrade. För BYOK-nycklar är automatisk rotation inte tillgänglig; du genererar nytt material externt och importerar det om manuellt. Rotation på begäran är tillgänglig när som helst via RotateKeyOnDemand API.

Vilka AWS KMS-händelser visas i CloudTrail och hur bör man övervaka dem?

Varje KMS API-anrop genererar en CloudTrail-händelse. Avisera omedelbart vid ScheduleKeyDeletion och DisableKey för alla produktionsnycklar, vid dekrypteringsanrop från principaler som inte finns i den godkända rollistan och vid dekrypteringshändelser med hög volym som föreslår exfiltrering. Avisera vid PutKeyPolicy-ändringar för produktionsnycklar. Dirigera CloudTrail-loggar till en skrivskyddad S3-bucket i ett dedikerat säkerhetskonto. Aktivera S3-datahändelser separat eftersom objektnivååtgärder inte registreras i hanteringshändelseloggar som standard.