Afstemming op het NIST Cybersecurity Framework in de AWS Cloud

Het afstemmen op het NIST Cybersecurity Framework in de AWS Cloud betekent dat u systematisch AWS-native services en uw eigen controles koppelt aan alle zes CSF 2.0-functies, bepaalt hoeveel controle u over de sleutels behoudt en het bewijsmateriaal verzamelt dat auditors daadwerkelijk nodig hebben. Organisaties die dit goed doen, verlagen het risico op datalekken, vereenvoudigen audits door regelgevende instanties en bouwen een cloudbeveiligingsstrategie op die ze kunnen verdedigen. Het aanbevolen startpunt: gebruik AWS Organizations en Control Tower om de nieuwe Govern-functie te operationaliseren, koppel vervolgens elke resterende functie aan de AWS-services in de onderstaande tabel en bepaal vroegtijdig of native AWS KMS, BYOK of HYOK-sleutelbeheer aansluit bij uw soevereiniteits- en compliancevereisten.

Kort antwoord: Hoe stem je AWS af op NIST CSF 2.0?

NIST CSF 2.0 heeft zes kernfuncties: Beheren, Identificeren, Beschermen, Detecteren, Reageren en Herstellen. In AWS voldoet u aan deze functies door de juiste native services voor elk te implementeren (AWS Organizations en Control Tower voor Beheren, AWS Config en Security Hub voor Identificeren, AWS KMS en IAM voor Beschermen, GuardDuty en Inspector voor Detecteren, CloudWatch en Lambda voor Reageren, AWS Backup en CloudFormation voor Herstellen), een sleutelbeheermodel te kiezen (native KMS, BYOK of HYOK) dat aansluit bij uw soevereiniteits- en compliancevereisten, CloudTrail in te schakelen voor een volledig auditspoor en een CSF-profiel te documenteren dat uw huidige beheersmaatregelen koppelt aan de resultaten van de subcategorieën van het framework. AWS levert de tools; de klant is verantwoordelijk voor de configuratie, de beslissingen over sleutelbeheer en het verzamelen van compliancebewijs.

Wat is NIST CSF 2.0 en wat is er veranderd ten opzichte van versie 1?

Het NIST Cybersecurity Framework (CSF) is een vrijwillig, risicogebaseerd raamwerk, gepubliceerd door het National Institute of Standards and Technology (NIST), om organisaties te helpen bij het beheren en verminderen van cyberbeveiligingsrisico's. Het biedt een gemeenschappelijke taal, een taxonomie van resultaten en verwijzingen naar meer dan 50 andere cyberbeveiligingsnormen en -richtlijnen.

NIST CSF 2.0 werd officieel uitgebracht op 26 februari 2024. Het bevat vier belangrijke wijzigingen ten opzichte van CSF 1.1:

• Nieuwe bestuursfunctie toegevoegd: CSF 2.0 introduceert een zesde kernfunctie, Besturen, die centraal staat in het raamwerk en betrekking heeft op de organisatorische context, risicostrategie, rollen, beleid en risicobeheer in de toeleveringsketen. Deze functie weerspiegelt de erkenning dat cybersecuritygovernance een voorwaarde is voor het consistent functioneren van de andere vijf functies.
• Bredere reikwijdte: CSF 1.1 was voornamelijk gericht op kritieke infrastructuur. CSF 2.0 is expliciet van toepassing op organisaties van elke omvang en in elke sector, van grote bedrijven tot kleine non-profitorganisaties en scholen.
• Sterkere nadruk op de toeleveringsketen: CSF 2.0 voegt specifieke subcategorieën toe onder 'Govern' en 'Identify' voor het beheer van risico's in de toeleveringsketen, waarmee de realiteit na het SolarWinds-debacle met betrekking tot bedreigingen voor de software- en leverancierstoeleveringsketen wordt weerspiegeld.
• De implementatiemiddelen zijn uitgebreid: NIST heeft tegelijk met CSF 2.0 snelstartgidsen, communityprofielen en een doorzoekbare informatieve referentiecatalogus uitgebracht, waardoor het gemakkelijker is om het in specifieke omgevingen, waaronder cloudimplementaties, te implementeren.

Het raamwerk bestaat nog steeds uit drie onderdelen: de Kern (de zes functies en hun categorieën en subcategorieën van resultaten), Niveaus (die de volwassenheid van de risicobeheerpraktijken van een organisatie beschrijven, van gedeeltelijk tot adaptief) en Profielen (die de huidige en beoogde cybersecuritypositie van een organisatie vastleggen voor een specifiek gebruiksscenario of omgeving).

De zes kernfuncties van NIST CSF 2.0 uitgelegd

Elke functie vertegenwoordigt een belangrijk resultaatgebied op het gebied van cyberbeveiliging. In een AWS-omgeving zijn specifieke services gekoppeld aan elke functie, en de verantwoordelijkheid van de klant verschilt per functie.

Govern (GV) is de nieuwe functie in CSF 2.0. Deze omvat de organisatorische context, risicostrategie, rollen en verantwoordelijkheden, beleid, toezicht en cybersecurity van de toeleveringsketen. In AWS komt dit overeen met AWS Organizations (accounthiërarchie en servicebeheerbeleid), AWS Control Tower (geautomatiseerde landingszones en beveiligingsmaatregelen), AWS Service Catalog (samengestelde en goedgekeurde serviceportfolio's), AWS Audit Manager (geautomatiseerde verzameling van bewijsmateriaal voor naleving) en uw interne governanceprocessen voor de goedkeuring van cloudbeleid en de risicobeoordeling van leveranciers. De klant is vrijwel volledig verantwoordelijk voor Govern.

Identify (ID) omvat assetmanagement, risicobeoordeling, analyse van de bedrijfsomgeving en identificatie van risico's in de toeleveringsketen. AWS-services die Identify ondersteunen, zijn onder andere AWS Security Hub (geaggregeerde beveiligingsbevindingen), AWS Config (configuratie-inventarisatie en detectie van afwijkingen van de compliance), AWS Systems Manager (beheerde instantie-inventarisatie), AWS Trusted Advisor (resourcegebruik en beveiligingscontroles) en Amazon Inspector (geautomatiseerde kwetsbaarheidsanalyse voor EC2- en containerimages).

Protect (PR) omvat toegangscontrole, gegevensbeveiliging, platformbeveiliging en veerkracht. Deze functie komt het meest direct overeen met encryptie en sleutelbeheer. AWS-services omvatten AWS IAM (identiteits- en toegangsbeheer), AWS KMS (encryptiesleutelbeheer), AWS CloudHSM (speciale FIPS 140-2 Level 3 HSM's), AWS Certificate Manager (TLS/SSL-certificaatvoorziening), AWS Shield (DDoS-bescherming), AWS WAF (webapplicatiefirewall), AWS Macie (detectie en classificatie van gevoelige gegevens), Amazon VPC (netwerksegmentatie) en AWS Direct Connect (connectiviteit met privénetwerken).

Detect (DE) omvat continue monitoring, anomaliedetectie en detectie van ongewenste gebeurtenissen. AWS-services omvatten Amazon GuardDuty (intelligente dreigingsdetectie met behulp van machine learning), Amazon Macie (detectie van blootstelling van gevoelige gegevens in S3), Amazon Inspector (kwetsbaarheidsscanning), AWS Security Hub (gecentraliseerde verzameling van beveiligingsbevindingen) en Amazon Detective (onderzoek naar beveiligingsincidenten en analyse van de hoofdoorzaak).

Respond (RS) omvat incidentresponsplanning, communicatie, analyse, mitigatie en verbeteringen. AWS-services omvatten AWS CloudWatch (monitoring en waarschuwingen), AWS Lambda (geautomatiseerde responsrunbooks die worden geactiveerd door beveiligingsincidenten), AWS Step Functions (orkestratie van incidentrespons in meerdere stappen), AWS Systems Manager (operationele runbooks en automatisering), AWS CloudTrail (auditlogboek voor onderzoek) en Amazon Detective (correlatie van bevindingen voor incidentafbakening).

Recover (RC) omvat herstelplanning, verbeteringen en communicatie. AWS-services omvatten AWS Elastic Disaster Recovery (voorheen CloudEndure), AWS Backup (gecentraliseerd back-upbeleid en -beheer), Amazon S3 Glacier (langetermijnback-uparchief), AWS CloudFormation (infrastructuur als code voor het herbouwen van omgevingen) en AWS OpsWorks (configuratiebeheer).

AWS-services gekoppeld aan de kernfuncties van NIST CSF 2.0

De onderstaande tabel koppelt AWS-services aan de kernfuncties van NIST CSF 2.0. AWS publiceert een gedetailleerde matrix met AWS-services en klantverantwoordelijkheden voor CSF-afstemming op aws.amazon.com/compliance/nist/ voor een gedetailleerdere koppeling per subcategorie.

#	Regeren	Identificeren	Beschermen	Opsporen	Reageren	Herstellen
1	organisaties	Beveiligingshub	IAM	Wachtdienst	CloudWatch	Elastische DR
2	Controle toren	Config	KMS	Macie	Lambda	AWS-back-up
3	Audit Manager	Vertrouwde adviseur	WolkHSM	Inspecteur	Detective	Wolkenvorming
4	Servicecatalogus	Systems Manager	Certificate Manager	Beveiligingshub	CloudTrail	S3 Gletsjer
5	Configuratie (beleid)	Inspecteur	Shield / WAF	NB	Stap Functies	Momentopname / Archief
6	NB	VPC-stroomlogboeken	Macie, Direct Connect, Firewall Manager, IAM Identity Center	NB	Systems Manager	OpsWorks

Native AWS-sleutelbeheer versus extern sleutelbeheer: wat de CSF Protect-functie vereist.

De subcategorieën voor gegevensbeveiliging van de NIST CSF Protect-functie vereisen dat gegevens zowel in rust als tijdens transport worden beschermd, dat encryptiesleutels consistent met het beleid worden beheerd en dat bewerkingen in de levenscyclus van sleutels worden gelogd en controleerbaar zijn. Hoe u aan deze vereisten voldoet, hangt af van het sleutelbeheermodel dat u kiest. In AWS-omgevingen zijn er drie praktische opties.

Optie 1: Native AWS KMS (AWS-Managed Keys)

AWS creëert, bewaart en beheert uw encryptiesleutels volledig binnen AWS KMS. De service maakt gebruik van FIPS 140-2 Level 2 gevalideerde HSM's. Sleutelmateriaal verlaat AWS KMS nooit onversleuteld. Rotatie kan worden ingesteld op automatisch (jaarlijks voor symmetrische sleutels). Elke cryptografische bewerking genereert een CloudTrail-logboekvermelding.

Dit model is geschikt voor de meeste AWS-workloads. Het voldoet direct aan de NIST CSF-vereisten voor gegevensbescherming en logboekregistratie met minimale configuratie. De keerzijde: AWS heeft technisch gezien toegang tot het sleutelmateriaal als onderdeel van de beheerde service, wat mogelijk niet voldoet aan strenge eisen op het gebied van gegevenssoevereiniteit of bepaalde gereguleerde sectoren (defensie, geclassificeerde informatie, sommige financiële diensten).

Optie 2: BYOK (Neem je eigen sleutel mee)

BYOK betekent dat u uw sleutelmateriaal extern genereert (in een on-premises HSM of een extern sleutelbeheersysteem), dit importeert in AWS KMS als een door de klant beheerde sleutel met geïmporteerd sleutelmateriaal, en dat AWS dat geïmporteerde materiaal gebruikt voor versleutelingsbewerkingen. U behoudt het originele sleutelmateriaal en kunt de geïmporteerde sleutel indien nodig verwijderen uit AWS KMS, waardoor AWS de mogelijkheid verliest om gegevens te decoderen die door die sleutel worden beschermd.

BYOK voldoet aan een strengere eis van functiescheiding: de organisatie die de sleutel heeft gegenereerd, behoudt de eigendom van het sleutelmateriaal. Tijdens actief gebruik binnen AWS is het onversleutelde sleutelmateriaal echter toegankelijk voor AWS KMS voor versleutelings- en ontsleutelingsbewerkingen. BYOK wordt niet automatisch geroteerd via AWS KMS; u moet de levenscyclus van de sleutel extern beheren en bijgewerkt sleutelmateriaal opnieuw importeren.

Optie 3: HYOK (Hold Your Own Key)

HYOK betekent dat de encryptiesleutel nooit AWS binnenkomt. In plaats daarvan worden AWS-encryptiebewerkingen via uw externe sleutelbeheersysteem uitgevoerd. AWS-services die externe sleutelarchieven ondersteunen (zoals de AWS KMS XKS, External Key Store, een functie die in 2022 is uitgebracht) sturen sleutelverzoeken naar uw externe sleutelbeheerproxy. Deze proxy voert de cryptografische bewerking uit met uw sleutel, die zich in uw on-premises of private cloud HSM bevindt, en stuurt alleen het resultaat terug naar AWS.

HYOK biedt de sterkste vorm van sleutelsoevereiniteit: AWS heeft onder geen enkele omstandigheid toegang tot uw onversleutelde sleutel, zelfs niet onder wettelijke dwang. De nadelen zijn reëel: elke AWS-versleutelingsbewerking voegt de latentie toe van een externe aanroep naar uw sleutelbeheersysteem, uw sleutelbeheerinfrastructuur moet een hoge beschikbaarheid en responstijden van minder dan 50 ms hebben om de applicatieprestaties niet te beïnvloeden, en de operationele complexiteit is aanzienlijk hoger.

Sleutelcontrole beslissingstabel

Afmeting	Native AWS KMS	BYOK (geïmporteerde sleutel)	HYOK (Externe sleutelopslag)
Locatie van het belangrijkste materiaal	AWS KMS HSM (FIPS 140-2 L2)	Extern gegenereerd, opgeslagen in AWS KMS.	Altijd in uw externe HSM
AWS-toegang tot de sleutel in platte tekst	Ja, voor cryptografische bewerkingen.	Ja, tijdens actief gebruik.	Nee
FIPS-validatieniveau	140-2 Niveau 2 (KMS) of Niveau 3 (CloudHSM)	Dat hangt ervan af waar je het genereert.	Dat hangt af van je externe HSM.
Automatische rotatie	Ja (jaarlijks voor symmetrische sleutels)	Nee, u regelt het extern.	Nee, het wordt volledig extern beheerd.
CloudTrail-logging	Volledig KMS API-auditspoor	Volledig KMS API-auditspoor	Gedeeltelijk (XKS-proxy moet ook loggen)
Trek de toegang tot gegevens direct in.	Sleutel verwijderen (wachttijd van 7-30 dagen)	Geïmporteerd sleutelmateriaal direct verwijderen	XKS-proxyverbinding verbreken (onmiddellijk)
Operationele complexiteit	Laag	Medium	Hoge
Impact van latentie	minimaal	minimaal	Voegt de heen- en terugreis toe aan de externe kilometerstand.
Best voor	De meeste werkzaamheden; kosten- en operationele efficiëntie hebben prioriteit.	Gereguleerde sectoren die belangrijke herkomstgegevens buiten AWS nodig hebben.	Soevereiniteitsmandaten; geheim; sleutelbeheer volgens het zero-trust-principe

IAM-model voor NIST CSF Protect: Minimale bevoegdheden in AWS

De subcategorieën voor toegangscontrole (PR.AA) van de NIST CSF Protect-functie vereisen dat identiteiten worden geverifieerd, dat toegangsrechten het principe van minimale bevoegdheden weerspiegelen en dat de toegang periodiek wordt gecontroleerd. In AWS betekent dit dat u uw IAM-model moet ontwerpen op basis van drie principes.

Scheid KMS-sleutelbeleid van IAM-beleid: Een KMS-sleutelbeleid is de primaire toegangscontrole voor een KMS-sleutel. Een IAM-beleid alleen is onvoldoende, tenzij het sleutelbeleid de gebruiker ook toegang verleent. Deze scheiding biedt een extra beveiligingslaag: zelfs een IAM-beheerder heeft geen toegang tot een KMS-sleutel, tenzij dit expliciet is toegestaan ​​in het sleutelbeleid. Structureer sleutelbeleid zodanig dat sleutelbeheerders (die de sleutel kunnen roteren en beheren) gescheiden zijn van sleutelgebruikers (die kunnen versleutelen en ontsleutelen). Geen enkele identiteit mag beide mogelijkheden hebben.

Service Control Policies gebruiken in AWS-organisaties: Service Control Policies (SCP's) die op organisatieniveau worden toegepast, kunnen voorkomen dat gebruikers in die accounts ongeautoriseerde sleutelbeheerbewerkingen uitvoeren, niet-conforme sleutelconfiguraties maken of CloudTrail uitschakelen. SCP's fungeren als vangrails die AWS evalueert voordat IAM-beleid wordt toegepast, waardoor ze een krachtig mechanisme vormen voor het afdwingen van beleid op governanceniveau voor alle accounts.

Dwing toegang door meerdere partijen af ​​voor gevoelige sleutelbewerkingen: Gebruik voor het verwijderen, importeren en repliceren van gevoelige KMS-sleutels tussen regio's een goedkeuringsworkflow die een tweede geautoriseerde identiteit vereist om de bewerking te bevestigen. AWS dwingt dit niet standaard af voor alle bewerkingen, maar het kan worden geïmplementeerd via IAM-conditiesleutels en goedkeuringsworkflows in AWS Step Functions of AWS Systems Manager Automation.

Sleutelrotatie en auditregistratie voor NIST CSF-naleving

NIST SP 800-57 Deel 1, waarnaar de CSF informatief verwijst voor het beheer van cryptografische sleutels, stelt dat cryptoperioden (de periode waarin een sleutel mag worden gebruikt) beperkt moeten zijn en dat sleutels moeten worden geroteerd wanneer de cryptoperiode afloopt of wanneer er een vermoeden van inbreuk bestaat.

In AWS KMS is automatische rotatie beschikbaar voor door de klant beheerde symmetrische sleutels. Wanneer deze functie is ingeschakeld, genereert AWS jaarlijks nieuw cryptografisch materiaal, markeert dit nieuwe materiaal als de actieve sleutelversie en bewaart alle eerdere versies voor het ontsleutelen van gegevens die met eerdere versies zijn versleuteld. Dit betekent dat u bestaande gegevens nooit opnieuw hoeft te versleutelen om rotatie in te schakelen, en dat de sleutel-ARN en sleutel-ID constant blijven, zodat er geen applicatiewijzigingen nodig zijn. De rotatiegebeurtenis wordt vastgelegd in CloudTrail onder het gebeurtenistype RotateKey.

Voor BYOK-sleutels is automatische rotatie via AWS KMS niet beschikbaar. Uw externe sleutelbeheersysteem moet het rotatieschema beheren en u moet nieuw sleutelmateriaal handmatig opnieuw importeren. De HSM as a Service- en cloudgegevensbeschermingsadviesdiensten van Encryption Consulting kunnen u helpen bij het ontwerpen en automatiseren van deze workflow voor gereguleerde omgevingen.

Elke KMS API-aanroep genereert een CloudTrail-record met de sleutel-ID, de identiteit van de aanroeper, de verzoekparameters en de responsstatus. Voor de NIST CSF Detect- en Respond-functies moeten CloudTrail-logboeken worden doorgestuurd naar Amazon CloudWatch Logs en worden opgenomen in uw SIEM. Configureer CloudWatch-alarmen voor afwijkende patronen: onverwachte verzoeken om sleutels te verwijderen, ongebruikelijke pieken in het versleutelingsvolume, mislukte Decrypt-aanroepen van onbekende principals of DisableKey-gebeurtenissen.

Kostenoverwegingen voor AWS-sleutelbeheer op grote schaal

De prijsstelling van AWS KMS bestaat uit twee componenten: een maandelijkse vergoeding per sleutel voor door de klant beheerde sleutels (CMK's) en een vergoeding per API-aanroep voor cryptografische bewerkingen. Vanaf 2025 rekent AWS KMS $1 per CMK per maand en $0.03 per 10,000 API-aanroepen. Voor door AWS beheerde sleutels (die met het voorvoegsel aws/) worden geen kosten per sleutel in rekening gebracht, maar u betaalt wel voor API-aanroepen.

Voor workloads met grote aantallen encryptiebewerkingen (server-side encryptie in S3, encryptie in RDS, grootschalige encryptie in EBS-volumes) kunnen de kosten per aanroep oplopen. Envelope-encryptie, waarbij een data-encryptiesleutel (DEK) wordt versleuteld door een KMS CMK en lokaal door uw applicatie wordt opgeslagen, reduceert het aantal KMS API-aanroepen en daarmee de kosten aanzienlijk. AWS-services zoals S3, RDS en EBS verzorgen envelope-encryptie automatisch.

AWS CloudHSM wordt per HSM-instantie per uur gefactureerd (ongeveer $ 1.45 per uur per HSM vanaf 2025), plus kosten voor gegevensoverdracht. Voor hoge beschikbaarheid zijn minimaal twee HSM's in aparte beschikbaarheidszones vereist, waardoor de basiskosten voor een cluster met twee HSM's ongeveer $ 2,100 per maand bedragen. CloudHSM is geschikt voor workloads die FIPS 140-2 Level 3 HSM-isolatie vereisen, klantbeheer van partitiereferenties of aangepaste cryptografische bewerkingen die niet door KMS worden ondersteund.

Het gebruik van de AWS KMS External Key Store (XKS) door HYOK verlaagt de AWS KMS API-kosten niet, maar voegt wel de infrastructuurkosten toe voor uw externe sleutelbeheersysteem en de bijbehorende hoge beschikbaarheidsvereisten. De operationele overhead is aanzienlijk; houd rekening met de benodigde personeelstijd voor het beheren van de XKS-proxy, uw externe HSM-cluster en de integratie met AWS-services.

Overwegingen bij multi-cloud- en hybride architecturen

Organisaties die AWS combineren met andere cloudproviders (Azure, GCP) of hybride on-premises omgevingen, staan ​​voor een specifieke uitdaging met betrekking tot de NIST CSF-standaarden: de CSF-uitkomsten zijn van toepassing op de volledige omgeving, niet alleen op de AWS-omgeving. Dit leidt tot een probleem met de consistentie van sleutelbeheer. AWS KMS is AWS-specifiek; Azure Key Vault is Azure-specifiek; GCP Cloud KMS is GCP-specifiek. Zonder een overkoepelende sleutelbeheerlaag voor alle clouds, resulteert dit in drie afzonderlijke sleutelinventarissen, drie afzonderlijke audit trails en drie afzonderlijke rotatiebeleidsregels.

Drie patronen pakken dit aan:

• Cloud-native federatie met uniforme CLM: Behoud de eigen sleutelservices per cloud (AWS KMS, Azure Key Vault, GCP Cloud KMS), maar implementeer een uniform platform voor certificaat- en sleutellevenscyclusbeheer dat de inventaris samenvoegt, het rotatiebeleid afdwingt en één auditspoor biedt voor alle providers. Dit voorkomt de latentie en complexiteit van HYOK en biedt tegelijkertijd inzicht in de governance van de volledige multi-cloudomgeving.
• Gecentraliseerd extern sleutelbeheer met BYOK in elke cloud: Gebruik één extern sleutelbeheersysteem als uw gezaghebbende sleutelopslag en exporteer BYOK-sleutelmateriaal naar het KMS van elke cloudprovider. Dit centraliseert de sleutelgeneratie en het levenscyclusbeleid, terwijl de native encryptiemogelijkheden van de cloud worden benut voor optimale prestaties.
• HYOK met een gedeelde externe HSM: Voor de hoogste eisen op het gebied van soevereiniteit kunt u één extern HSM-cluster gebruiken als gezaghebbende sleutelopslag en de integratie van de externe sleutelopslag van elke cloudprovider configureren om uw gecentraliseerde HSM aan te roepen. Dit is de meest operationeel complexe optie en vereist een extern HSM-cluster dat het gecombineerde volume aan encryptie-API-aanroepen van alle cloudproviders aankan.

De adviesdiensten van Encryption Consulting op het gebied van cloudgegevensbescherming en het HSM as a Service -aanbod kunnen elk van deze patronen ondersteunen. Voor organisaties die een CBOM (Cryptographic Bill of Materials) opstellen als onderdeel van hun NIST CSF Govern and Identify-implementatie, biedt CBOM Secure geautomatiseerde detectie en inventarisatie van cryptografische assets in cloud- en hybride omgevingen.

Afstemming tussen het AWS Cloud Adoption Framework en het NIST CSF

Voordat u een CSF-compatibele beveiligingsarchitectuur in AWS bouwt, gebruikt u het AWS Cloud Adoption Framework (CAF) om hiaten in de mogelijkheden te identificeren. Het beveiligingsperspectief van het AWS CAF behandelt identiteits- en toegangsbeheer, detectieve controles, infrastructuurbeveiliging, gegevensbescherming en incidentrespons, die allemaal rechtstreeks overeenkomen met de NIST CSF-functies.

De AWS CAF Security Perspective's Foundational Capabilities en de AWS Security Reference Architecture (SRA) bieden concrete richtlijnen voor het structureren van AWS-accounts (met behulp van AWS Organizations), het implementeren van de juiste beveiligingsservices in het juiste accounttype (een speciaal Security Tooling-account voor GuardDuty, Security Hub en CloudTrail-aggregatie) en het afdwingen van basisbeveiligingsmaatregelen binnen de organisatie. Door de AWS CAF en SRA te raadplegen vóór de implementatie van CSF-beveiligingsmaatregelen, worden veelvoorkomende configuratiefouten voorkomen en wordt uw AWS-architectuur afgestemd op de door AWS aanbevolen beveiligingspatronen.

NIST CSF Gedeelde verantwoordelijkheid: Klant-eigendom versus AWS-eigendom

AWS werkt volgens een model van gedeelde verantwoordelijkheid, waarbij de beveiligingsverantwoordelijkheid verdeeld is tussen AWS en de klant. Voor naleving van de NIST CSF-normen betekent dit dat uw bewijsmateriaal door beide partijen verzameld moet worden.

De verantwoordelijkheden van AWS omvatten de fysieke beveiliging van datacenters, het patchen van hypervisors en hostbesturingssystemen voor beheerde services, de beschikbaarheid en duurzaamheid van beheerde services (S3, RDS, KMS) en de FIPS-validatie van AWS KMS- en CloudHSM-hardware. AWS levert auditdocumenten die deze controles dekken via AWS Artifact (SOC-rapporten, PCI DSS-attestaties, ISO-certificeringen), die klanten kunnen downloaden en gebruiken in hun eigen compliance-documenten.

De verantwoordelijkheden van de klant omvatten IAM-configuratie (wie toegang heeft tot welke AWS-resources en onder welke voorwaarden), configuratie van encryptiesleutels (welke KMS-sleutels welke gegevens beschermen en wat het sleutelbeleid toestaat), netwerkbeheer (beveiligingsgroepregels, configuratie van VPC-flowlogboeken, NACL's), workloadbeveiliging (OS-patches op de door u beheerde EC2-instanties, beveiliging van containerimages), monitoringconfiguratie (welke CloudWatch-alarmen zijn ingesteld en welke GuardDuty-bevindingen worden doorgestuurd naar incidentrespons) en procedures voor gegevensclassificatie en -verwerking.

AWS publiceert een gedetailleerde matrix met verantwoordelijkheden voor AWS-services en klanten voor afstemming op de CSF-doelstellingen op aws.amazon.com/compliance/nist/ . Deze matrix koppelt elk van de 108 op resultaten gebaseerde beveiligingsactiviteiten van de CSF aan de vraag of ze eigendom zijn van AWS, eigendom zijn van de klant of gedeeld worden. Dit biedt beveiligings- en compliance-teams een startpunt voor het beoordelen van eventuele tekortkomingen ten opzichte van de huidige implementatie van beveiligingsmaatregelen.

Het referentiediagram van de AWS NIST CSF-architectuur illustreert de koppeling van alle zes CSF 2.0-kernfuncties aan AWS-native services en de verdeling tussen verantwoordelijkheden van de klant en die van AWS. De volledige koppeling is beschikbaar in de AWS-whitepaper "Aligning to the NIST Cybersecurity Framework in the AWS Cloud" (bijgewerkt in januari 2025) en de downloadbare matrix met AWS-services en klantverantwoordelijkheden op aws.amazon.com/compliance/nist/.

Hoe implementeer je NIST CSF 2.0 in AWS: een gestructureerde startprocedure?

Voor teams die hun NIST CSF-afstemming in AWS starten of vernieuwen, vermindert een gestructureerde implementatievolgorde de hoeveelheid herwerk en brengt de grootste risico's als eerste aan het licht.

1. Richt de Government-stichting op: Stel AWS Organizations in met een gedefinieerde accounthiërarchie. Implementeer AWS Control Tower om basisbeveiligingsmechanismen te automatiseren. Definieer uw CSF-profiel voor deze AWS-omgeving door te documenteren welke CSF-subcategorieën binnen het bereik vallen, wat uw huidige status is en wat uw gewenste status is. Wijs het eigenaarschap van elke functie toe aan specifieke personen of teams.
2. Voltooi de inventaris van activa en cryptografie (identificeer): Gebruik AWS Config, Systems Manager en Security Hub om een ​​inventarisatie te maken van alle AWS-resources. CBOM Secure Het doel is om alle cryptografische activa te ontdekken en te classificeren, waaronder KMS-sleutels, certificaten, SSH-sleutels en geheimen. Deze basisinventaris vormt de basis voor uw risicobeoordeling en de huidige status van uw NIST CSF-profiel.
3. Kies uw sleutelbeheermodel (Beschermen): Kies, op basis van uw wettelijke vereisten, de gevoeligheid van uw gegevens en uw operationele capaciteit, voor de native AWS KMS, BYOK of HYOK voor elke gegevensclassificatielaag. Leg deze keuze vast in uw sleutelbeheerbeleid, dat onderdeel uitmaakt van de beleidsvereisten van de CSF Govern-functie.
4. Configureer toegangsbeheer (Beveiligen): Ontwerp en implementeer KMS-sleutelbeleid, IAM-beleid en SCP's die toegang met minimale privileges implementeren. Dwing MFA af voor gevoelige consolebewerkingen en sleutelbeheeracties. Configureer IAM Identity Center (voorheen AWS SSO) voor gefedereerde toegang met uw bedrijfsidentiteitsprovider.
5. Monitoring en detectie inschakelen (Detecteren): Schakel AWS CloudTrail in alle regio's in met validatie van logbestanden en levering aan een speciaal Security Tooling-account. Schakel GuardDuty in voor alle accounts en verzamel bevindingen in Security Hub. Configureer CloudWatch-alarmen voor afwijkingen in sleutelbeheer. Schakel VPC Flow Logs in voor inzicht op netwerkniveau.
6. Ontwikkel respons-runbooks (Respond): Documenteer en automatiseer de incidentrespons voor de bevindingen die uw detectietools aan het licht brengen. Bouw op Lambda of Step Functions gebaseerde geautomatiseerde reacties op GuardDuty-bevindingen met een hoge mate van zekerheid. Documenteer escalatiepaden, communicatiesjablonen en vereisten voor externe meldingen (termijnen voor datalekken, wettelijke rapportage).
7. Test en valideer herstel (Herstellen): Test de AWS Backup-herstelprocedures, documenteer de hersteltijddoelstellingen (RTO) en herstelpuntdoelstellingen (RPO) voor elke kritieke workload en bevestig dat de herstelprocedures de services herstellen naar de beveiligingsstatus van vóór het incident, en niet alleen naar de operationele beschikbaarheid.
8. Beoordeel aan de hand van het CSF-profiel en herhaal het proces: Vergelijk de door u geïmplementeerde beheersmaatregelen met uw beoogde CSF-profiel. Documenteer het bewijsmateriaal voor elke subcategorie. Gebruik AWS Audit Manager om het verzamelen van bewijsmateriaal voor door AWS beheersbare subcategorieën te automatiseren. Identificeer resterende hiaten en prioriteer de herstelmaatregelen op basis van de impact op het risico.

Hoe encryptieconsultancy kan helpen

Encryption Consulting is een bedrijf gespecialiseerd in toegepaste cryptografie en cybersecurity, met ISO/IEC 27001:2022- en SOC 2-certificeringen. Wij helpen organisaties bij het ontwerpen, beoordelen en implementeren van encryptie- en sleutelbeheerprogramma's die voldoen aan de NIST CSF-, NIST SP 800-53-, CMMC-, FedRAMP-, PCI DSS-, HIPAA- en andere compliance-eisen in AWS- en multi-cloudomgevingen.

• Advies over cloudgegevensbescherming en sleutelbeheer: We beoordelen uw huidige AWS-sleutelbeheermodel, identificeren hiaten ten opzichte van de NIST CSF Protect-vereisten en ontwerpen de juiste sleutelbeheerarchitectuur voor uw regelgevingsomgeving en risicotolerantie. Of u nu native KMS-optimalisatie, BYOK-sleutelimportautomatisering of HYOK-ontwerp met AWS KMS XKS nodig hebt, wij bouwen de architectuur en leveren de bijbehorende documentatie. Bekijk onze adviesdiensten.
• HSM als een service: Voor workloads die FIPS 140-2 Level 3 HSM-sleutelopslag buiten AWS KMS vereisen, biedt Encryption Consulting de volgende oplossingen. HSM als een service Biedt een speciale HSM-infrastructuur met beheerde operationele processen, ondersteuning bij sleutelceremonies en integratie met AWS CloudHSM en sleutelbeheersystemen van derden.
• CBOM Secure voor cryptografische inventarisatie: De functies 'Govern' en 'Identify' van NIST CSF 2.0 vereisen kennis van de cryptografische activa die u bezit en hun locatie. CBOM Secure Automatiseert de ontdekking en classificatie van encryptiesleutels, certificaten, SSH-sleutels, geheimen en het gebruik van cryptografische algoritmen in uw AWS-omgeving en genereert een cryptografische materiaallijst (CBOM) in CycloneDX-formaat voor rapportage aan de compliance-afdeling.
• Advies over naleving van regelgeving (NIST CSF, CMMC, FedRAMP): Wij faciliteren NIST CSF Profile-workshops, koppelen uw huidige AWS-controles aan CSF-subcategorieën, identificeren hiaten en stellen het herstelplan en het bewijsmateriaal voor uw audit op. Nalevingsadviesdiensten Omvat de vereisten van NIST CSF 2.0, NIST SP 800-53 Rev. 5, CMMC Level 2 en Level 3, en FedRAMP.
• PQC-gereedheid in AWS: NIST heeft in augustus 2024 de post-kwantumcryptografiestandaarden FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) afgerond, en NIST IR 8547 wijst erop dat RSA en ECC rond 2030 zullen worden uitgefaseerd. PQC-gereedheid Deze service beoordeelt uw AWS-cryptografische status ten opzichte van de migratietijdlijn na de quantumovergang en ontwerpt het algoritme-overgangsplan voor uw KMS-sleutelconfiguraties, certificaatprofielen en TLS-configuraties.

Neem contact op met Encryption Consulting om uw NIST CSF-conformiteitsvereisten in AWS te bespreken.

Conclusie

NIST CSF 2.0 vertegenwoordigt een aanzienlijke verbetering van het raamwerk. De toevoeging van de functie 'Govern' plaatst organisatorische verantwoordelijkheid en risico's in de toeleveringsketen centraal in de cybersecuritypraktijk, in plaats van ze als secundaire aandachtspunten te beschouwen. Voor AWS-omgevingen betekent dit dat het compliancewerk begint voordat u ook maar één beveiligingsservice configureert: u moet uw accounthiërarchie definiëren, eigenaarschap toewijzen en uw risicostrategie documenteren voordat u services aan de overige vijf functies koppelt.

De belangrijkste beslissing over de beheermogelijkheden, met name of u gebruikmaakt van native AWS KMS, BYOK of HYOK, is de meest ingrijpende technische keuze voor de Protect-functie. Deze keuze heeft invloed op uw mogelijkheid om direct toegang in te trekken, uw operationele complexiteit, uw auditbewijs en uw kosten. Neem deze beslissing weloverwogen op basis van uw daadwerkelijke wettelijke vereisten en operationele capaciteit, en niet vanuit de aanname dat meer controle altijd beter is.

AWS biedt een uitgebreide set services die aansluiten op elke CSF 2.0-functie. De klant is verantwoordelijk voor de juiste configuratie, de koppeling met een samenhangende workflow voor monitoring en respons, en het bijhouden van het bewijsmateriaal dat aantoont dat de controles in de loop der tijd effectief functioneren. Dit bewijsmateriaal, in combinatie met het CSF-profiel dat u documenteert en onderhoudt, maakt van een goede AWS-beveiligingsarchitectuur een verdedigbare, auditklare compliance-positie.

Veelgestelde Vragen / FAQ

Wat is NIST CSF 2.0 en waarin verschilt het van CSF 1.0?

NIST CSF 2.0 werd uitgebracht op 26 februari 2024. Het voegt een zesde kernfunctie toe, genaamd 'Govern', aan de oorspronkelijke vijf (Identify, Protect, Detect, Respond, Recover), breidt de scope uit van kritieke infrastructuur naar alle organisaties, versterkt het risicomanagement in de toeleveringsketen en introduceert aanvullende implementatiehandleidingen en hulpmiddelen voor een snelle start. De functie 'Govern' behandelt de organisatorische context, risicostrategie, rollen, beleid en toezicht op de toeleveringsketen.

Wat is het verschil tussen BYOK en HYOK in AWS?

BYOK (Bring Your Own Key) betekent dat u extern sleutelmateriaal genereert en dit importeert in AWS KMS. AWS gebruikt die sleutel voor versleutelingsbewerkingen, waardoor AWS tijdens het gebruik toegang heeft tot de sleutel. HYOK (Hold Your Own Key) betekent dat de sleutel nooit AWS binnenkomt; versleutelingsbewerkingen worden via uw externe HSM uitgevoerd via de AWS KMS External Key Store (XKS). AWS raakt de onversleutelde sleutel in HYOK nooit aan, wat de sterkste sleutelsoevereiniteit biedt, maar wel ten koste van aanzienlijke operationele complexiteit en extra latentie.

Welke AWS-services ondersteunen de NIST CSF 2.0 Govern-functie?

AWS Organizations (accounthiërarchie en servicebeheerbeleid), AWS Control Tower (geautomatiseerde beveiligingsmechanismen en landingszones), AWS Service Catalog (goedgekeurde serviceportfolio's), AWS Config (beleid als code voor nalevingsregels) en AWS Audit Manager (geautomatiseerde verzameling van bewijsmateriaal voor naleving) zijn de belangrijkste services die de Govern-functie ondersteunen. De klant behoudt de volledige verantwoordelijkheid voor de resultaten van Govern; AWS levert de tools om governance op grote schaal te implementeren.

Hoe ondersteunt AWS KMS de NIST CSF-vereisten voor sleutelbeheer?

AWS KMS biedt FIPS 140-2 Level 2 gevalideerde, door HSM ondersteunde sleutelopslag, automatische jaarlijkse rotatie voor door de klant beheerde symmetrische sleutels, gedetailleerd sleutelbeleid en op IAM gebaseerde toegangscontrole, en CloudTrail-integratie die elke cryptografische bewerking registreert. Voor FIPS 140-2 Level 3-vereisten biedt AWS CloudHSM dedicated HSM-hardware voor één tenant. Beide services voldoen aan de subcategorieën gegevensbeveiliging en sleutelbeheer van de NIST CSF Protect-functie.

Wat is het model voor gedeelde verantwoordelijkheid voor NIST CSF-naleving in AWS?

AWS beveiligt de fysieke infrastructuur, de hypervisor en de beschikbaarheid van beheerde services (cloudbeveiliging). Klanten zijn verantwoordelijk voor de IAM-configuratie, het beheer van encryptiesleutels, netwerkbeheer, workloadbeveiliging, monitoringconfiguratie, gegevensclassificatie en incidentrespons (cloudbeveiliging). AWS levert auditdocumenten via AWS Artifact; klanten moeten zelf bewijsmateriaal verzamelen voor hun eigen beheersmaatregelen. De AWS Services and Customer Responsibility matrix voor CSF op aws.amazon.com/compliance/nist/ brengt de verantwoordelijkheid in kaart voor alle 108 op resultaten gebaseerde CSF-activiteiten.

Hoe moet ik encryptiesleutels in AWS roteren om te voldoen aan de NIST CSF-vereisten?

Schakel automatische rotatie in voor door de klant beheerde symmetrische sleutels in AWS KMS. Hierdoor wordt het sleutelmateriaal jaarlijks geroteerd, waarbij de ARN van de sleutel en alle bestaande machtigingen behouden blijven. Dit voldoet aan de NIST SP 800-57-richtlijnen voor rotatie zonder dat gegevens opnieuw versleuteld hoeven te worden. Voor BYOK-sleutels kunt u de rotatie extern beheren en het bijgewerkte sleutelmateriaal opnieuw importeren. Monitor rotatiegebeurtenissen in CloudTrail onder het gebeurtenistype RotateKey en stel een melding in bij mislukte rotaties.

Referenties

1. NIST Cybersecurity Framework 2.0. National Institute of Standards and Technology. Gepubliceerd op 26 februari 2024. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
2. Afstemming op het NIST Cybersecurity Framework in de AWS Cloud (bijgewerkt voor CSF 2.0). Amazon Web Services. Januari 2025. https://d1.awsstatic.com/whitepapers/compliance/NIST_Cybersecurity_Framework_CSF.pdf
3. AWS-services en klantverantwoordelijkheidsmatrix voor afstemming op het CSF. Amazon Web Services. https://aws.amazon.com/compliance/nist/
4. NIST SP 800-53 Rev. 5, Beveiligings- en privacycontroles voor informatiesystemen en -organisaties. NIST. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
5. NIST SP 800-57 Deel 1 Rev. 5, Aanbeveling voor sleutelbeheer. NIST. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
6. NIST IR 8547, Overgang naar post-kwantumcryptografiestandaarden. NIST. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
7. ISO/IEC 27001:2022, Informatiebeveiligingsmanagementsystemen. ISO. https://www.iso.org/standard/27001