Anpassning till NIST:s cybersäkerhetsramverk i AWS-molnet

Att anpassa sig till NIST:s cybersäkerhetsramverk i AWS Cloud innebär att systematiskt mappa AWS-nativa tjänster och era egna kontroller till alla sex CSF 2.0-funktioner, bestämma hur mycket nyckelkontroll ni behåller och samla in de bevis som revisorer faktiskt behöver. Organisationer som gör detta rätt minskar risken för dataintrång, förenklar myndighetsrevisioner och bygger en molnsäkerhetsposition som de kan försvara. Den rekommenderade utgångspunkten: använd AWS Organizations och Control Tower för att operationalisera den nya Govern-funktionen, mappa sedan varje återstående funktion till AWS-tjänsterna i tabellen nedan och bestäm tidigt om nativ AWS KMS, BYOK eller HYOK-nyckelhantering passar era suveränitets- och efterlevnadskrav.

Snabbt svar: Hur anpassar man AWS till NIST CSF 2.0?

NIST CSF 2.0 har sex kärnfunktioner: Styrning, Identifiera, Skydda, Detektera, Svara och Återställa. I AWS uppfyller du dessa funktioner genom att distribuera rätt nativa tjänster för var och en (AWS Organizations and Control Tower for Govern, AWS Config and Security Hub for Identify, AWS KMS och IAM for Protect, GuardDuty och Inspector for Detect, CloudWatch och Lambda for Respond, AWS Backup och CloudFormation for Recover), välja en nyckelkontrollmodell (nativ KMS, BYOK eller HYOK) som matchar dina suveränitets- och efterlevnadskrav, aktivera CloudTrail för en komplett revisionslogg och dokumentera en CSF-profil som mappar dina nuvarande kontroller till ramverkets underkategoriresultat. AWS tillhandahåller verktygen; kunden äger konfigurationen, nyckelhanteringsbesluten och insamlingen av efterlevnadsbevis.

Vad är NIST CSF 2.0 och vad har ändrats från version 1?

NIST Cybersecurity Framework (CSF) är ett frivilligt, riskbaserat ramverk som publicerats av National Institute of Standards and Technology (NIST) för att hjälpa organisationer att hantera och minska cybersäkerhetsrisker. Det tillhandahåller ett gemensamt språk, en taxonomi för resultat och korsreferenser till mer än 50 andra cybersäkerhetsstandarder och riktlinjer.

NIST CSF 2.0 släpptes officiellt den 26 februari 2024. Den gör fyra betydande förändringar från CSF 1.1:

• Ny styrningsfunktion tillagd: CSF 2.0 introducerar en sjätte kärnfunktion, Govern, som står i centrum för ramverket och hanterar organisatoriskt sammanhang, riskstrategi, roller, policyer och riskhantering i leveranskedjan. Denna funktion återspeglar erkännandet att styrning av cybersäkerhet är en förutsättning för att de andra fem funktionerna ska fungera konsekvent.
• Bredare omfattning: CSF 1.1 utformades främst kring kritisk infrastruktur. CSF 2.0 gäller uttryckligen organisationer av alla storlekar och sektorer, från stora företag till små ideella organisationer och skolor.
• Starkare fokus på leveranskedjan: CSF 2.0 lägger till dedikerade underkategorier under Styrning och Identifiering för riskhantering i leveranskedjan, vilket återspeglar verkligheten efter SolarWinds gällande hot mot mjukvara och leverantörers leveranskedja.
• Utökade implementeringsresurser: NIST släppte snabbstartsguider, communityprofiler och en sökbar informativ referenskatalog tillsammans med CSF 2.0, vilket gör det enklare att operationalisera i specifika miljöer, inklusive molndistributioner.

Ramverket består fortfarande av tre avsnitt: kärnan (de sex funktionerna och deras kategorier och underkategorier av resultat), nivåer (som beskriver mognaden hos en organisations riskhanteringspraxis från partiell till adaptiv) och profiler (som fångar en organisations nuvarande och målinriktade cybersäkerhetsposition för ett specifikt användningsfall eller en specifik miljö).

De sex kärnfunktionerna i NIST CSF 2.0 förklarade

Varje funktion representerar ett övergripande resultatområde för cybersäkerhet. I en AWS-miljö kopplas specifika tjänster till varje funktion, och kundens ansvar varierar mellan dem.

Govern (GV) är den nya funktionen i CSF 2.0. Den täcker organisatorisk kontext, riskstrategi, roller och ansvar, policyer, tillsyn och cybersäkerhet i leveranskedjan. I AWS mappas detta till AWS Organizations (kontohierarki och tjänstekontrollpolicyer), AWS Control Tower (automatiserade landningszoner och skyddsräcken), AWS Service Catalog (kurerade godkända tjänsteportföljer), AWS Audit Manager (automatiserad insamling av efterlevnadsbevis) och dina interna styrningsprocesser för godkännande av molnpolicyer och riskbedömning av leverantörer. Kunden äger nästan helt Govern.

Identify (ID) omfattar tillgångshantering, riskbedömning, analys av affärsmiljön och identifiering av risker i leveranskedjan. AWS-tjänster som stöder Identify inkluderar AWS Security Hub (aggregerade säkerhetsresultat), AWS Config (konfigurationsinventering och detektering av efterlevnadsavvikelser), AWS Systems Manager (hanterad instansinventering), AWS Trusted Advisor (resursutnyttjande och säkerhetskontroller) och Amazon Inspector (automatiserad sårbarhetsbedömning för EC2- och containeravbildningar).

Protect (PR) omfattar åtkomstkontroll, datasäkerhet, plattformssäkerhet och motståndskraft. Detta är den funktion som har den mest direkta mappningen till kryptering och nyckelhantering. AWS-tjänster inkluderar AWS IAM (identitets- och åtkomsthantering), AWS KMS (krypteringsnycklarhantering), AWS CloudHSM (dedikerade FIPS 140-2 nivå 3 HSM:er), AWS Certificate Manager (TLS/SSL-certifikatprovisionering), AWS Shield (DDoS-skydd), AWS WAF (brandvägg för webbapplikationer), AWS Macie (identifiering och klassificering av känsliga data), Amazon VPC (nätverkssegmentering) och AWS Direct Connect (privat nätverksanslutning).

Detect (DE) omfattar kontinuerlig övervakning, avvikelsedetektering och detektering av negativa händelser. AWS-tjänster inkluderar Amazon GuardDuty (intelligent hotdetektering med hjälp av maskininlärning), Amazon Macie (detektering av exponering för känslig data i S3), Amazon Inspector (sårbarhetsskanning), AWS Security Hub (centraliserad aggregering av säkerhetsfynd) och Amazon Detective (utredning av säkerhetsincidenter och rotorsaksanalys).

Respond (RS) omfattar planering, kommunikation, analys, riskreducering och förbättringar av incidentresponser. AWS-tjänster inkluderar AWS CloudWatch (övervakning och varningar), AWS Lambda (automatiserade respons-runbooks som utlöses av säkerhetshändelser), AWS Step Functions (orkestrering av incidentresponser i flera steg), AWS Systems Manager (operativa runbooks och automatisering), AWS CloudTrail (granskningslogg för utredning) och Amazon Detective (korrelation av resultat för incidentomfattning).

Recover (RC) omfattar återställningsplanering, förbättringar och kommunikation. AWS-tjänster inkluderar AWS Elastic Disaster Recovery (tidigare CloudEndure), AWS Backup (centraliserad säkerhetskopieringspolicy och hantering), Amazon S3 Glacier (långsiktigt säkerhetskopieringsarkiv), AWS CloudFormation (infrastruktur-som-kod för miljöåteruppbyggnad) och AWS OpsWorks (konfigurationshantering).

AWS-tjänster mappade till NIST CSF 2.0-kärnfunktioner

Tabellen nedan mappar AWS-tjänster till NIST CSF 2.0-kärnfunktioner. AWS publicerar en detaljerad AWS-tjänst- och kundansvarsmatris för CSF-anpassning på aws.amazon.com/compliance/nist/ för detaljerad mappning av underkategorier.

#	Styra	identifiera	Skydda	Upptäcka	Svara	Recover
1	Organisationer	Säkerhetsnav	IAM	GuardDuty	CloudWatch	Elastisk DR
2	Kontrolltorn	Konfig	KMS	Macie	Lambda	AWS backup
3	Revisionschef	Betrodd rådgivare	CloudHSM	Inspector	Detektiv	CloudFormation
4	Servicekatalog	Systemansvarig	Certificate Manager	Säkerhetsnav	CloudTrail	S3 Glaciär
5	Konfiguration (policyer)	Inspector	Sköld / WAF	-	Steg funktioner	Ögonblicksbild / Arkiv
6	-	VPC-flödesloggar	Macie, Direct Connect, Brandväggshanterare, IAM-identitetscenter	-	Systemansvarig	OpsWorks

Native AWS Key Management kontra extern nyckelhantering: Vad CSF Protect-funktionen kräver

NIST CSF Protect-funktionens underkategorier för datasäkerhet kräver att data skyddas i vila och under överföring, att krypteringsnycklar hanteras i enlighet med policyn och att nyckellivscykeloperationer loggas och är granskningsbara. Hur du uppfyller dessa krav beror på vilken nyckelkontrollmodell du väljer. Det finns tre praktiska alternativ i AWS-miljöer.

Alternativ 1: Inbyggd AWS KMS (AWS-hanterade nycklar)

AWS skapar, lagrar och hanterar dina krypteringsnycklar helt inom AWS KMS. Tjänsten använder FIPS 140-2 Level 2-validerade HSM:er. Nyckelmaterial lämnar aldrig AWS KMS okrypterat. Rotationen kan ställas in på automatisk (årlig för symmetriska nycklar). Varje kryptografisk operation genererar en CloudTrail-loggpost.

Den här modellen är lämplig för de flesta AWS-arbetsbelastningar. Den uppfyller NIST CSF:s krav på dataskydd och loggning direkt ur lådan med minimal konfiguration. Nackdelen: AWS har tekniskt sett tillgång till nyckelmaterialet som en del av den hanterade tjänsten, vilket kanske inte uppfyller strikta krav på datasuveränitet eller vissa reglerade sektorer (försvar, sekretessbelagda tjänster, vissa finansiella tjänster).

Alternativ 2: Ta med egen nyckel (BYOK)

BYOK innebär att du genererar ditt nyckelmaterial externt (i en lokal HSM eller ett externt nyckelhanteringssystem), importerar det till AWS KMS som en kundhanterad nyckel med importerat nyckelmaterial, och AWS använder det importerade materialet för krypteringsåtgärder. Du behåller det ursprungliga nyckelmaterialet och kan ta bort den importerade nyckeln från AWS KMS om det behövs, vilket i praktiken återkallar AWS möjlighet att dekryptera data som skyddas av den nyckeln.

BYOK uppfyller ett starkare krav på arbetsuppdelning: organisationen som genererade nyckeln behåller ursprunget över nyckelmaterialet. Under aktiv användning inom AWS är dock nyckelmaterialet i klartext tillgängligt för AWS KMS för krypterings- och dekrypteringsoperationer. BYOK roterar inte automatiskt genom AWS KMS; du måste hantera nyckellivscykeln externt och importera uppdaterat nyckelmaterial igen.

Alternativ 3: HYOK (Håll din egen nyckel)

HYOK innebär att krypteringsnyckeln aldrig kommer in i AWS. Istället hanteras AWS-krypteringsåtgärder via ditt externa nyckelhanteringssystem med proxy. AWS-tjänster som stöder externa nyckellagrar (som AWS KMS XKS, External Key Store, funktionen som släpptes 2022) skickar nyckelförfrågningar till din externa nyckelhanteringsproxy, som utför kryptografiska operationer med din nyckel som finns kvar i din lokala eller privata moln-HSM, och returnerar endast resultatet till AWS.

HYOK erbjuder den starkaste formen av nyckelsuveränitet: AWS kan inte komma åt din klartextnyckel under några omständigheter, inklusive juridisk tvång. Avvägningarna är verkliga: varje AWS-krypteringsoperation lägger till latensen för ett externt anrop till ditt nyckelhanteringssystem, din nyckelhanteringsinfrastruktur måste ha hög tillgänglighet och svarstider på under 50 ms för att undvika att påverka applikationens prestanda, och den operativa komplexiteten är betydligt högre.

Tabell för nyckelkontrollbeslut

Dimensionera	Inbyggd AWS KMS	BYOK (Importerad nyckel)	HYOK (Extern nyckelförvaring)
Viktigt materials placering	AWS KMS HSM (FIPS 140-2 L2)	Genererad externt, lagrad i AWS KMS	Alltid i din externa HSM
AWS-åtkomst till klartextnyckel	Ja, för kryptografiska operationer	Ja, vid aktiv användning	Nej
FIPS-valideringsnivå	140-2 Nivå 2 (KMS) eller Nivå 3 (CloudHSM)	Beror på var du genererar det	Beror på din externa HSM
Automatisk rotation	Ja (årligen för symmetriska nycklar)	Nej, du hanterar externt	Nej, hanteras helt externt
CloudTrail-loggning	Fullständig granskningslogg för KMS API	Fullständig granskningslogg för KMS API	Delvis (XKS-proxy måste också logga)
Återkalla åtkomst till data omedelbart	Nyckelborttagning (7–30 dagars väntetid)	Ta bort importerat nyckelmaterial (omedelbart)	Koppla bort XKS-proxy (omedelbart)
Operationell komplexitet	Låg	Medium	Hög
Latenspåverkan	Minimal	Minimal	Lägger till tur- och returresefunktioner till extern KMS
Bäst för	De flesta arbetsbelastningar; prioritet för kostnad och driftseffektivitet	Reglerade sektorer som behöver viktig proveniens utanför AWS	Suveränitetsmandat; hemligstämplat; nollförtroendekontroll

IAM-modell för NIST CSF Protect: Minst möjliga privilegier i AWS

NIST CSF Protect-funktionens underkategorier för åtkomstkontroll (PR.AA) kräver att identiteter autentiseras, åtkomstbehörigheter återspeglar lägsta möjliga privilegium och att åtkomst granskas regelbundet. I AWS innebär detta att du utformar din IAM-modell kring tre principer.

Separera KMS-nyckelpolicyer från IAM-policyer: En KMS-nyckelpolicy är den primära åtkomstkontrollen för en KMS-nyckel. En IAM-policy ensam är otillräcklig om inte nyckelpolicyn också ger huvudåtkomst. Denna separation ger ett ytterligare lager: inte ens en IAM-administratör kan komma åt en KMS-nyckel om det inte uttryckligen är tillåtet i nyckelpolicyn. Strukturera nyckelpolicyer för att separera nyckeladministratörer (som kan rotera och hantera nyckeln) från nyckelanvändare (som kan kryptera och dekryptera). Ingen enskild identitet bör ha båda funktionerna.

Använd tjänstekontrollpolicyer i AWS-organisationer: Tjänstekontrollpolicyer (SCP) som tillämpas på organisationsenhetsnivå kan förhindra att alla principaler i dessa konton använder obehöriga nyckelhanteringsåtgärder, skapar icke-kompatibla nyckelkonfigurationer eller inaktiverar CloudTrail. SCP:er fungerar som skyddsräcken som AWS utvärderar innan IAM-policyer, vilket gör dem till en stark mekanism för att upprätthålla policyer på styrningsnivå över alla konton.

Tillämpa åtkomst för flera parter för känsliga nyckeloperationer: För nyckelborttagning, nyckelimport och replikering över flera regioner av känsliga KMS-nycklar, använd ett godkännandearbetsflöde som kräver en andra auktoriserad identitet för att bekräfta åtgärden. AWS tillämpar inte detta internt för alla operationer, men det kan implementeras via IAM-villkorsnycklar och godkännandearbetsflöden i AWS Step Functions eller AWS Systems Manager Automation.

Nyckelrotation och revisionsloggning för NIST CSF-efterlevnad

NIST SP 800-57 Del 1, som CSF informativt refererar till för hantering av kryptografisk nyckel, fastställer att kryptoperioder (den period under vilken en nyckel är auktoriserad för användning) bör begränsas och att nycklar bör roteras när kryptoperioden löper ut eller när misstanke om kompromettering föreligger.

I AWS KMS är automatisk rotation tillgänglig för kundhanterade symmetriska nycklar. När den är aktiverad genererar AWS nytt kryptografiskt material årligen, markerar det nya materialet som aktiv nyckelversion och behåller alla tidigare versioner för dekryptering av data som krypterats med tidigare versioner. Det betyder att du aldrig behöver kryptera om befintliga data för att aktivera rotation, och nyckel-ARN och nyckel-ID förblir konstanta så inga applikationsändringar krävs. Rotationshändelsen loggas i CloudTrail under händelsetypen RotateKey.

För BYOK-importerade nycklar är automatisk rotation inte tillgänglig via AWS KMS. Ditt externa nyckelhanteringssystem måste hantera rotationsschemat, och du importerar nytt nyckelmaterial manuellt. Encryption Consultings HSM as a Service och rådgivningstjänster för molndataskydd kan hjälpa till att utforma och automatisera detta arbetsflöde för reglerade miljöer.

Varje KMS API-anrop genererar en CloudTrail-post som innehåller nyckel-ID, uppringaridentitet, förfrågningsparametrar och svarsstatus. För NIST CSF Detect and Respond-funktioner bör CloudTrail-loggar vidarebefordras till Amazon CloudWatch-loggar och matas in i din SIEM. Konfigurera CloudWatch-larm för avvikande mönster: oväntade förfrågningar om nyckelborttagning, ovanliga krypteringsvolymtoppar, misslyckade dekrypteringsanrop från okända principaler eller DisableKey-händelser.

Kostnadsöverväganden för AWS-nyckelhantering i stor skala

Prissättningen för AWS KMS har två komponenter: en avgift per nyckel och månad för kundhanterade nycklar (CMK:er) och en avgift per API-anrop för kryptografiska operationer. Från och med 2025 debiterar AWS KMS 1 USD per CMK och månad och 0.03 USD per 10 000 API-anrop. AWS-hanterade nycklar (de som har prefixet aws/) har ingen avgift per nyckel, men du betalar fortfarande för API-anrop.

För arbetsbelastningar med krypteringsoperationer med hög volym (S3-serversideskryptering, RDS-kryptering, EBS-volymkryptering i stor skala) kan kostnaden per samtal ackumuleras. Kuvertkryptering, där en datakrypteringsnyckel (DEK) krypteras av en KMS CMK och cachas lokalt av din applikation, minskar antalet KMS API-anrop avsevärt och därmed kostnaden. AWS-tjänster som S3, RDS och EBS hanterar kuvertkryptering automatiskt.

AWS CloudHSM prissätts per HSM-instans och timme (cirka 1.45 USD per timme och HSM från och med 2025), plus kostnader för dataöverföring. Minst två HSM:er i separata tillgänglighetszoner krävs för hög tillgänglighet, vilket gör att baskostnaden blir ungefär 2 100 USD per månad för ett kluster med två HSM. CloudHSM är lämpligt för arbetsbelastningar som kräver FIPS 140-2 nivå 3 HSM-isolering, kundhantering av partitionsuppgifter eller anpassade kryptografiska operationer som inte stöds av KMS.

Att använda AWS KMS External Key Store (XKS) minskar inte kostnaderna för AWS KMS API, men ökar infrastrukturkostnaden för ditt externa nyckelhanteringssystem och dess krav på hög tillgänglighet. Den operativa omkostnaden är betydande; ta hänsyn till personaltid för att hantera XKS-proxyn, ditt externa HSM-kluster och integrationen med AWS-tjänster.

Överväganden gällande multimoln och hybridarkitektur

Organisationer som arbetar i AWS tillsammans med andra molnleverantörer (Azure, GCP) eller hybrida lokala miljöer står inför en specifik NIST CSF-utmaning: CSF-resultaten gäller för hela din miljö, inte bara ditt AWS-fotavtryck. Detta skapar ett problem med konsekvens i nyckelhanteringen. AWS KMS är AWS-specifikt; Azure Key Vault är Azure-specifikt; GCP Cloud KMS är GCP-specifikt. Utan ett molnöverskridande nyckelhanteringslager får du tre separata nyckelinventarier, tre separata revisionsspår och tre separata rotationspolicyer.

Tre mönster åtgärdar detta:

• Molnbaserad federation med enhetlig CLM: Behåll inbyggda nyckeltjänster per moln (AWS KMS, Azure Key Vault, GCP Cloud KMS) men distribuera en enhetlig plattform för hantering av certifikat och nyckellivscykel som aggregerar inventering, tillämpar rotationspolicy och tillhandahåller en enda revisionslogg för alla leverantörer. Detta undviker latensen och komplexiteten hos HYOK samtidigt som det ger styrningsinsyn över hela multimolnområdet.
• Centraliserad extern nyckelhantering med BYOK i varje moln: Använd ett enda externt nyckelhanteringssystem som din auktoritativa nyckellagring och exportera BYOK-nyckelmaterial till varje molnleverantörs KMS. Detta centraliserar nyckelgenerering och livscykelpolicy samtidigt som inbyggda molnkrypteringsfunktioner används för prestanda.
• HYOK med en delad extern HSM: För de högsta suveränitetskraven, använd ett enda externt HSM-kluster som auktoritativ nyckellagring och konfigurera varje molns externa nyckellagringsintegration för att anropa din centraliserade HSM. Detta är det mest operativt komplexa alternativet och kräver ett externt HSM-kluster som kan hantera den kombinerade krypterings-API-anropsvolymen från alla molnleverantörer.

Encryption Consultings rådgivningstjänster för molndataskydd och HSM as a Service kan stödja vart och ett av dessa mönster. För organisationer som bygger en CBOM (Cryptographic Bill of Materials) som en del av sin implementering av NIST CSF Govern and Identify-funktioner, tillhandahåller CBOM Secure automatiserad identifiering och inventering av kryptografiska tillgångar i moln- och hybridmiljöer.

AWS Cloud Adoption Framework och NIST CSF-anpassning

Innan du bygger en CSF-anpassad säkerhetsarkitektur i AWS, använd AWS Cloud Adoption Framework (CAF) för att identifiera kapacitetsluckor. AWS CAF:s säkerhetsperspektiv omfattar identitets- och åtkomsthantering, detektivkontroller, infrastruktursäkerhet, dataskydd och incidenthantering, som alla mappas direkt till NIST CSF-funktioner.

AWS CAF Security Perspectives grundläggande funktioner och AWS Security Reference Architecture (SRA) ger föreskrivande vägledning om hur man strukturerar AWS-konton (med hjälp av AWS-organisationer), vilka säkerhetstjänster som ska distribueras i vilken kontotyp (ett dedikerat Security Tooling-konto för GuardDuty, Security Hub, CloudTrail-aggregering) och hur man tillämpar grundläggande kontroller i hela organisationen. Att granska AWS CAF och SRA innan man implementerar CSF-kontroller förhindrar vanliga felkonfigurationer och anpassar din AWS-arkitektur till AWS-rekommenderade säkerhetsmönster.

NIST CSF Delat ansvar: Kundägt kontra AWS-ägt

AWS arbetar enligt en modell för delat ansvar som delar säkerhetsansvaret mellan AWS och kunden. För att uppfylla NIST CSF-kraven innebär detta att din bevisinsamling måste omfatta båda parter.

AWS-ägda ansvarsområden inkluderar säkerhet för fysiska datacenter, patchning av hypervisorer och värdoperativsystem för hanterade tjänster, tillgängligheten och hållbarheten hos hanterade tjänster (S3, RDS, KMS) och FIPS-validering av AWS KMS- och CloudHSM-hårdvara. AWS tillhandahåller revisionsartefakter som täcker dessa kontroller genom AWS Artifact (SOC-rapporter, PCI DSS-attesteringar, ISO-certifieringar), som kunder kan ladda ner och referera till i sina egna efterlevnadsdokumentationspaket.

Kundägda ansvarsområden inkluderar IAM-konfiguration (vem som kan komma åt vilka AWS-resurser och under vilka villkor), konfiguration av krypteringsnycklar (vilka KMS-nycklar skyddar vilka data, vad nyckelpolicyerna tillåter), nätverkskontroller (regler för säkerhetsgrupper, konfiguration av VPC-flödesloggar, NACL:er), härdning av arbetsbelastning (OS-patchning på EC2-instanser du hanterar, säkerhet för containeravbildningar), övervakningskonfiguration (vilka CloudWatch-larm som är inställda, vilka GuardDuty-fynd som dirigeras till incidentrespons) samt dataklassificering och hanteringsprocedurer.

AWS publicerar en detaljerad matris för AWS-tjänster och kundansvar för CSF-anpassning på aws.amazon.com/compliance/nist/ . Denna matris kartlägger var och en av de 108 CSF-resultatbaserade säkerhetsaktiviteterna utifrån om de är AWS-ägda, kundägda eller delade, vilket ger säkerhets- och efterlevnadsteam en utgångspunkt för gapbedömning mot er nuvarande kontrollimplementering.

Referensdiagrammet för AWS NIST CSF-arkitekturen illustrerar mappningen av alla sex CSF 2.0-kärnfunktioner till AWS-nativa tjänster och uppdelningen mellan kundägda och AWS-ägda ansvarsområden. Den fullständiga mappningen finns tillgänglig i AWS-vitboken "Aligning to the NIST Cybersecurity Framework in the AWS Cloud" (uppdaterad januari 2025) och den nedladdningsbara AWS Services and Customer Responsibility-matrisen på aws.amazon.com/compliance/nist/.

Hur man implementerar NIST CSF 2.0 i AWS: En strukturerad startsekvens

För team som börjar eller uppdaterar sin NIST CSF-anpassning i AWS, minskar en strukturerad implementeringssekvens omarbete och avslöjar de luckor med högst risk först.

1. Etablera Government-stiftelsen: Konfigurera AWS-organisationer med en definierad kontohierarki. Implementera AWS Control Tower för att automatisera grundläggande skyddsräcken. Definiera din CSF-profil för denna AWS-miljö genom att dokumentera vilka CSF-underkategorier som ingår, vad ditt nuvarande tillstånd är och vad ditt måltillstånd är. Tilldela ägarskap för varje funktion till namngivna individer eller team.
2. Fyll i tillgångs- och kryptografiska inventeringen (Identifiera): Använd AWS Config, Systems Manager och Security Hub för att inventera alla AWS-resurser. CBOM-säkerhet för att upptäcka och klassificera alla kryptografiska tillgångar, inklusive KMS-nycklar, certifikat, SSH-nycklar och hemligheter. Denna baslinjeinventering är indata för din riskbedömning och ditt nuvarande tillstånd för NIST CSF-profilen.
3. Välj din nyckelkontrollmodell (Protect): Baserat på dina myndighetskrav, datakänslighet och operativa kapacitet, välj mellan inbyggd AWS KMS, BYOK eller HYOK för varje dataklassificeringsnivå. Dokumentera detta beslut i din nyckelhanteringspolicy, som är en del av CSF Govern-funktionens policykrav.
4. Konfigurera åtkomstkontroller (Protect): Designa och distribuera KMS-nyckelpolicyer, IAM-policyer och SCP:er som implementerar åtkomst med lägsta behörighet. Tillämpa MFA för känsliga konsoloperationer och nyckelhanteringsåtgärder. Konfigurera IAM Identity Center (tidigare AWS SSO) för federerad åtkomst med din företagsidentitetsleverantör.
5. Aktivera övervakning och detektering (Detektera): Aktivera AWS CloudTrail i alla regioner med loggfilsvalidering och leverans till ett dedikerat Security Tooling-konto. Aktivera GuardDuty för alla konton och aggregera resultat i Security Hub. Konfigurera CloudWatch-larm för nyckelhanteringsavvikelser. Aktivera VPC-flödesloggar för insyn på nätverksnivå.
6. Bygg svars-runbooks (Respond): Dokumentera och automatisera incidentrespons för de fynd som dina detektionsverktyg visar. Bygg Lambda-baserade eller Step Functions-baserade automatiserade svar för GuardDuty-fynd med hög tillförlitlighet. Dokumentera eskaleringsvägar, kommunikationsmallar och externa anmälningskrav (tidslinjer för anmälan av intrång, rapportering av myndigheter).
7. Testa och validera återställning (Recover): Testa AWS Backup-återställningsprocedurer, dokumentera återställningstidsmål (RTO) och återställningspunktsmål (RPO) för varje kritisk arbetsbelastning och bekräfta att återställningsprocedurerna återställer tjänsterna till säkerhetsläget före incidenten, inte bara till den operativa tillgängligheten.
8. Bedöm mot CSF-profilen och iterera: Jämför dina implementerade kontroller med din mål-CSF-profil. Dokumentera bevis för varje underkategori. Använd AWS Audit Manager för att automatisera bevisinsamling för AWS-kontrollerbara underkategorier. Identifiera återstående luckor och prioritera åtgärdande efter riskpåverkan.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är ett företag inom tillämpad kryptografi och cybersäkerhet med ISO/IEC 27001:2022- och SOC 2-certifieringar. Vi hjälper organisationer att utforma, utvärdera och driva krypterings- och nyckelhanteringsprogram som uppfyller NIST CSF, NIST SP 800-53, CMMC, FedRAMP, PCI DSS, HIPAA och andra efterlevnadskrav i AWS och multimolnmiljöer.

• Rådgivning om molndataskydd och nyckelhantering: Vi utvärderar er nuvarande AWS-nyckelkontrollmodell, identifierar luckor mot NIST CSF Protect-krav och utformar rätt nyckelhanteringsarkitektur för er regelverk och risktolerans. Oavsett om ni behöver nativ KMS-optimering, automatisering av BYOK-nyckelimport eller HYOK-design med AWS KMS XKS, bygger vi arkitekturen och dokumentationen. Se vår rådgivningstjänster.
• HSM som en tjänst: För arbetsbelastningar som kräver FIPS 140-2 Level 3 HSM-nyckellagring utanför AWS KMS, Encryption Consultings HSM som en tjänst tillhandahåller dedikerad HSM-infrastruktur med hanterad drift, facilitering av nyckelceremonier och integration med AWS CloudHSM och tredjepartssystem för nyckelhantering.
• CBOM säker för kryptografisk inventering: NIST CSF 2.0:s funktioner för styrning och identifiering kräver att man vet vilka kryptografiska tillgångar man har och var de finns. CBOM-säkerhet automatiserar upptäckt och klassificering av krypteringsnycklar, certifikat, SSH-nycklar, hemligheter och användning av kryptografiska algoritmer i din AWS-miljö och genererar en kryptografisk materiallista (CBOM) i CycloneDX-format för efterlevnadsrapportering.
• Efterlevnadsrådgivning (NIST CSF, CMMC, FedRAMP): Vi faciliterar workshops om NIST CSF-profiler, mappar era nuvarande AWS-kontroller till CSF-underkategorier, identifierar luckor och bygger en åtgärdsplan och ett bevispaket för er revision. Rådgivning om efterlevnad täcka NIST CSF 2.0, NIST SP 800-53 Rev. 5, CMMC nivå 2 och nivå 3, och FedRAMP-krav.
• PQC-beredskap i AWS: NIST slutförde postkvantkryptografistandarderna FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) i augusti 2024, och NIST IR 8547 pekar mot att RSA och ECC avvecklas runt 2030. Våra PQC-beredskap Tjänsten utvärderar din AWS-kryptografiska status mot tidslinjen efter kvantmigreringen och utformar algoritmövergångsplanen för dina KMS-nyckelkonfigurationer, certifikatprofiler och TLS-konfigurationer.

För att diskutera era NIST CSF-justeringskrav i AWS, kontakta Encryption Consulting.

Slutsats

NIST CSF 2.0 representerar en betydande mognad av ramverket. Tillägget av Govern-funktionen sätter organisatoriskt ansvar och risker i leveranskedjan i centrum för cybersäkerhetspraxis snarare än att behandla dem som sekundära problem. För AWS-miljöer innebär detta att efterlevnadsarbetet börjar innan du konfigurerar en enskild säkerhetstjänst: du måste definiera din kontohierarki, tilldela ägarskap och dokumentera din riskstrategi innan du mappar tjänster till de återstående fem funktionerna.

Det viktigaste kontrollbeslutet, särskilt huruvida man ska använda AWS KMS, BYOK eller HYOK, är det mest betydande tekniska valet för Protect-funktionen. Det påverkar din förmåga att återkalla åtkomst direkt, din operativa komplexitet, dina revisionsbevis och din kostnad. Fatta detta beslut medvetet baserat på dina faktiska myndighetskrav och operativa kapacitet, inte på antagandet att mer kontroll alltid är bättre.

AWS tillhandahåller en omfattande uppsättning tjänster som mappas till varje CSF 2.0-funktion. Kundens jobb är att konfigurera dem korrekt, ansluta dem till ett sammanhängande övervaknings- och responsarbetsflöde och underhålla bevisspåret som visar att kontrollerna fungerar effektivt över tid. Det bevisspåret, i kombination med CSF-profilen du dokumenterar och underhåller, är det som förvandlar en bra AWS-säkerhetsarkitektur till en försvarbar, revisionsklar efterlevnadspolicy.

Vanliga frågor om partihandel med mat och dryck

Vad är NIST CSF 2.0 och hur skiljer det sig från CSF 1.0?

NIST CSF 2.0 släpptes den 26 februari 2024. Den lägger till en sjätte kärnfunktion som kallas Styrning till de ursprungliga fem (Identifiera, Skydda, Detektera, Svara, Återställa), utökar omfattningen från kritisk infrastruktur till alla organisationer, stärker riskhanteringen i leveranskedjan och introducerar kompletterande implementeringsguider och snabbstartsresurser. Styrningsfunktionen hanterar organisatoriskt sammanhang, riskstrategi, roller, policyer och tillsyn av leveranskedjan.

Vad är skillnaden mellan BYOK och HYOK i AWS?

BYOK (Bring Your Own Key) innebär att du genererar nyckelmaterial externt och importerar det till AWS KMS. AWS använder den nyckeln för krypteringsoperationer, så AWS har åtkomst till nyckeln under användning. HYOK (Hold Your Own Key) innebär att nyckeln aldrig kommer in i AWS; krypteringsoperationer hanteras via proxy via din externa HSM via AWS KMS External Key Store (XKS). AWS vidrör aldrig klartextnyckeln i HYOK, vilket ger den starkaste nyckelsuveräniteten på bekostnad av betydande driftskomplexitet och ökad latens.

Vilka AWS-tjänster stöder NIST CSF 2.0 Govern-funktionen?

AWS-organisationer (kontohierarki och tjänstkontrollpolicyer), AWS Control Tower (automatiserade skyddsräcken och landningszoner), AWS Service Catalog (godkända tjänsteportföljer), AWS Config (policy-as-code-efterlevnadsregler) och AWS Audit Manager (automatiserad insamling av efterlevnadsbevis) är de primära tjänsterna som stöder Govern-funktionen. Kunden behåller fullt ägande av Govern-resultaten; AWS tillhandahåller verktygen för att operationalisera styrning i stor skala.

Hur stöder AWS KMS NIST CSF-nyckelhanteringskrav?

AWS KMS tillhandahåller FIPS 140-2 nivå 2-validerad HSM-baserad nyckellagring, automatisk årlig rotation för kundhanterade symmetriska nycklar, finjusterade nyckelpolicyer och IAM-baserad åtkomstkontroll, samt CloudTrail-integrationsloggning av varje kryptografisk operation. För FIPS 140-2 nivå 3-krav tillhandahåller AWS CloudHSM dedikerad HSM-hårdvara för en enda hyresgäst. Båda tjänsterna uppfyller NIST CSF Protect-funktionens underkategorier för datasäkerhet och nyckelhantering.

Vad är modellen för delat ansvar för NIST CSF-efterlevnad i AWS?

AWS säkrar den fysiska infrastrukturen, hypervisorn och tillgängligheten för hanterade tjänster (molnets säkerhet). Kunderna ansvarar för IAM-konfiguration, hantering av krypteringsnycklar, nätverkskontroller, arbetsbelastningshärdning, övervakningskonfiguration, dataklassificering och incidentrespons (säkerhet i molnet). AWS tillhandahåller granskningsartefakter genom AWS Artifact; kunderna måste samla in bevis för sin del av kontrollerna oberoende. AWS Services and Customer Responsibility-matrisen för CSF på aws.amazon.com/compliance/nist/ kartlägger ansvaret för alla 108 CSF-resultatbaserade aktiviteter.

Hur ska jag rotera krypteringsnycklar i AWS för att uppfylla NIST CSF-kraven?

Aktivera automatisk rotation för kundhanterade symmetriska nycklar i AWS KMS. Detta roterar nyckelmaterial årligen samtidigt som nyckel-ARN och alla befintliga behörigheter bevaras, vilket uppfyller NIST SP 800-57-rotationsriktlinjerna utan att kräva omkryptering av data. För BYOK-importerade nycklar, hantera rotationen externt och importera uppdaterat nyckelmaterial igen. Övervaka rotationshändelser i CloudTrail under händelsetypen RotateKey och avisera om rotationsfel.

Referensprojekt

1. NIST Cybersecurity Framework 2.0. National Institute of Standards and Technology. Släppt 26 februari 2024. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
2. Anpassning till NIST:s cybersäkerhetsramverk i AWS Cloud (uppdaterad för CSF 2.0). Amazon Web Services. Januari 2025. https://d1.awsstatic.com/whitepapers/compliance/NIST_Cybersecurity_Framework_CSF.pdf
3. AWS-tjänster och kundansvarsmatris för anpassning till CSF. Amazon Web Services. https://aws.amazon.com/compliance/nist/
4. NIST SP 800-53 Rev. 5, Säkerhets- och integritetskontroller för informationssystem och organisationer. NIST. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
5. NIST SP 800-57 Del 1 Rev. 5, Rekommendation för nyckelhantering. NIST. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
6. NIST IR 8547, Övergång till postkvantkryptografistandarder. NIST. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
7. ISO/IEC 27001:2022, Informationssäkerhetsledningssystem. ISO. https://www.iso.org/standard/27001