Sleutelbeheer – Aanbevelingen en best practices

Sleutelbeheer omvat alle procedures voor het genereren, opslaan, roteren en buiten gebruik stellen van cryptografische sleutels. Het is het zwakke punt in elk encryptiesysteem dat erop gebouwd is. Dit is belangrijk omdat een gecompromitteerde of slecht beheerde sleutel de encryptie die deze beschermt volledig tenietdoet, ongeacht de sterkte van het algoritme. Aanbevolen actie: volg de huidige richtlijnen voor cryptoperiodes en algoritmen van NIST SP 800-57 Deel 1 Revisie 5, wijs één sleutel per doel toe en plan nu alvast voor de aanstaande wijzigingen in Revisie 6.

Gepubliceerd: september 2020. Bijgewerkt: augustus 2026. Beoordeeld door het Cloud Key Management Team van Encryption Consulting.

Voor een fundamentele definitie van sleutelbeheer, zie ons artikel in het Educatiecentrum: Wat is sleutelbeheer? Hoe werkt sleutelbeheer? . Voor meer informatie over hoe deze werkwijzen zich uitstrekken over verschillende cloudproviders, zie Wat is sleutelbeheer in meerdere clouds? en Wat is een hybride sleutelbeheersysteem (KMS)? . Voor cloudspecifieke implementaties, zie AWS KMS versus Azure Key Vault versus GCP KMS , de gegevensversleutelingstools van Google Cloud Platform en Google Cloud Security – Sleutelbeheerservices.

Wat is sleutelmanagement en waarom is het belangrijk?

Sleutelbeheer is het proces waarbij standaarden worden vastgesteld voor het aanmaken, uitwisselen, opslaan, verwijderen en roteren van cryptografische sleutels binnen een organisatie, evenals voor wie er toegang toe heeft. Cryptografische sleutels worden gebruikt voor alles, van encryptie en decryptie tot gebruikersauthenticatie. Een gecompromitteerde sleutel kan een aanvaller in staat stellen gevoelige gegevens te decoderen, zich te authenticeren als een gebruiker met beheerdersrechten of toegang te krijgen tot andere vertrouwelijke bronnen. Goed sleutelbeheer is essentieel om dit risico te beperken.

Hoe verhouden symmetrische en asymmetrische sleutelsystemen zich tot elkaar?

Symmetrische sleutels beschermen doorgaans data in rust, terwijl asymmetrische sleutelparen doorgaans data beschermen die in beweging is. Dit komt doordat symmetrische encryptie snel genoeg is voor herhaalde toegang tot opgeslagen data, terwijl asymmetrische encryptie een veilige uitwisseling tussen partijen mogelijk maakt zonder een vooraf gedeeld geheim.

Systeem	Typisch gebruik	Waarom
Symmetrische sleutels	Gegevens in rust (databases, opslag)	Snel en efficiënt voor herhaalde versleutelings-/ontsleutelingsbewerkingen door dezelfde partij.
Asymmetrische sleutelparen	Gegevens in beweging (TLS, digitale handtekeningen, sleuteluitwisseling)	Hiermee kunnen twee partijen veilig met elkaar communiceren zonder vooraf een geheim te hebben gedeeld.

Een typische aanvraagstroom met symmetrische sleutels werkt als volgt:

1. Een gebruiker neemt contact op met het opslagsysteem (een database of objectopslag) en vraagt ​​om versleutelde gegevens.
2. Het opslagsysteem vraagt ​​de dataversleutelingssleutel (DEK) op bij de sleutelbeheerder-API, die de certificaten van zowel de sleutelbeheerder-API als de sleutelbeheerder zelf verifieert.
3. een veilige TLS De verbinding wordt tot stand gebracht en de sleutelbeheerder gebruikt een sleutelversleutelingssleutel (KEK) om de DEK te ontsleutelen, die vervolgens via de API van de sleutelbeheerder wordt teruggestuurd.
4. De gegevens worden gedecodeerd en als platte tekst aan de gebruiker teruggegeven.

Een typische asymmetrische sleuteluitwisseling werkt anders, omdat deze gebruikmaakt van sleutelparen in plaats van één gedeelde sleutel:

1. De verzender en ontvanger valideren elkaars certificaten via een privé-systeem. certificeringsinstantie (CA) of een externe validatie-instantie (VA).
2. De ontvanger stuurt zijn publieke sleutel naar de afzender, die de gegevens versleutelt met een eenmalige symmetrische sleutel, die zelf ook versleuteld is met de publieke sleutel van de ontvanger, en stuurt beide naar de ontvanger.
3. De ontvanger decodeert de eenmalige symmetrische sleutel met zijn eigen privésleutel en gebruikt deze vervolgens om de gegevens te decoderen.

Wat zijn de huidige aanbevelingen van NIST voor sleutelbeheer?

NIST SP 800-57 Deel 1 Revisie 5, gepubliceerd in 2020, is de huidige, officiële standaard voor sleutelbeheer. Deze standaard is opgesteld om gevoelige, maar niet-geclassificeerde federale informatie te beveiligen en wordt algemeen beschouwd als een basis voor best practices, ook voor niet-gouvernementele organisaties. Een daaropvolgend concept van Revisie 6 werd vrijgegeven voor openbare commentaar, met een deadline van 5 februari 2026. Op het moment van schrijven is Revisie 6 nog niet definitief, dus Revisie 5 blijft de standaard waarnaar verwezen moet worden. Organisaties die momenteel een sleutelbeheerprogramma opzetten, dienen de projectpagina van NIST over de richtlijnen voor sleutelbeheer in de gaten te houden voor de definitieve versie van Revisie 6, in plaats van conceptaanbevelingen als vaststaande richtlijnen te beschouwen.

Welke cryptografische algoritmen worden door NIST goedgekeurd?

De NIST-normen keuren een specifieke, beperkte set algoritmen goed, in plaats van elke symmetrische of asymmetrische optie die in gebruik is.

• Blokcijfergebaseerde symmetrische algoritmen zoals AES, dat een reeks bits (blokken) herhaaldelijk door bewerkingen zoals XOR voert over meerdere rondes om versleutelde tekst te produceren.
• op hashfuncties gebaseerde algoritmen zoals SHA-256, die gebruikmaken van eenrichtingsfuncties om hashgegevens te genereren (SHA-1 is verouderd voor de meeste beveiligingstoepassingen en moet niet worden gekozen voor nieuwe systemen).
• Asymmetrische algoritmen Over het algemeen geldt de voorwaarde dat de privésleutel uitsluitend in het bezit blijft van de entiteit die het sleutelpaar bezit.
• Willekeurige bitgeneratoren (RBG's), Gebruikt voor het genereren van sleutelmateriaal, en cryptografische hashfuncties, die zelf geen cryptografische sleutels gebruiken. Volledige lijsten met goedgekeurde algoritmen zijn te vinden in FIPS 180 (hashfuncties) en SP 800-90 (RBG's).

Hoe moeten cryptoperioden worden ingesteld?

Een cryptoperiode is de tijdsspanne waarin een sleutel voor het beoogde doel gebruikt mag worden voordat deze vernieuwd of, bij voorkeur, vervangen moet worden door een nieuwe sleutel. De kernaanbeveling van NIST is dat voor elk afzonderlijk doel een unieke sleutel wordt aangemaakt; een sleutel die voor authenticatie wordt gebruikt, mag nooit ook voor decryptie worden gebruikt. Voor asymmetrische sleutelparen heeft elke sleutel in het paar zijn eigen cryptoperiode: de gebruiksperiode voor de afzender bepaalt de sleutel die gebruikt wordt om een ​​digitale handtekening te creëren, en de gebruiksperiode voor de ontvanger bepaalt de bijbehorende verificatiesleutel. NIST adviseert dat beide perioden tegelijkertijd ingaan, maar de gebruiksperiode voor de ontvanger mag langer duren dan de gebruiksperiode voor de afzender, nooit andersom, aangezien een handtekening verifieerbaar moet blijven nadat de ondertekenende sleutel niet meer geldig is.

Hoe verandert sleutelbeheer in multi-cloud- en hybride omgevingen?

De richtlijnen van NIST zijn bewust leveranciersneutraal, maar multi-cloud- en hybride implementaties voegen praktische vragen toe die NIST niet direct beantwoordt: welke cloud de eigen KMS beheert, hoe sleutelhiërarchieën worden gemapt tussen providers die geen gemeenschappelijke vertrouwensbasis delen, en hoe toegangsbeleid consistent blijft wanneer dezelfde gegevens tussen omgevingen worden verplaatst. Zie Wat is multi-cloud sleutelbeheer? en Wat is een hybride sleutelbeheersysteem (KMS)? voor hoe deze vragen in de praktijk worden beantwoord, en onze vergelijking AWS KMS versus Azure Key Vault versus GCP KMS voor de verschillen tussen de drie belangrijkste clouds op het gebied van rotatie, IAM en kosten.

Wat zijn de beperkingen van het uitsluitend volgen van de NIST-richtlijnen?

• NIST SP 800-57 bevat aanbevelingen voor cryptoperiodes en algoritmen, maar schrijft geen specifieke IAM-, logging- of kostenafwegingen voor van een bepaalde cloud-KMS-implementatie.
• Revisie 6 bevindt zich nog in de conceptfase; organisaties die aanbevelingen in conceptfase als definitief overnemen, lopen het risico hun kernmanagementprogramma opnieuw te moeten herzien zodra Revisie 6 is gepubliceerd.
• De NIST-richtlijnen behandelen de sleutelhiërarchie voor meerdere clouds of de consistentie van toegangsbeleid tussen providers niet; deze aspecten moeten afzonderlijk worden ontworpen.
• Het volgen van de NIST-standaarden behandelt de selectie van algoritmen en cryptoperiodes; het omvat op zichzelf geen operationele procedures zoals automatische sleutelrotatie of incidentrespons bij een gecompromitteerde sleutel.

Besluitchecklist: Toepassing van de belangrijkste managementaanbevelingen van NIST

1. Gebruik elke sleutel slechts voor één doel; hergebruik nooit een sleutel voor zowel authenticatie als decryptie.
2. Selecteer voor elk nieuw systeem uitsluitend door NIST goedgekeurde algoritmen (AES voor symmetrische encryptie, SHA-256 of sterker voor hashing).
3. Stel per sleutel een gedocumenteerde cryptoperiode in, met aparte gebruiksperioden voor de afzender en de ontvanger voor asymmetrische paren.
4. Verwijs naar revisie 5 als de huidige standaard en wijs iemand aan om de afronding van revisie 6 te bewaken in plaats van deze te negeren.
5. Breid de basislijn van NIST uit met cloudspecifieke IAM-, logging- en rotatiepraktijken voor elke multi-cloud- of hybride implementatie.

Wat zou Encryption Consulting aanbevelen?

De meeste organisaties die we beoordelen, hebben een sleutelbeheerbeleid op papier dat niet overeenkomt met de daadwerkelijke implementatie. Dit komt vaak doordat het nog steeds verwijst naar een verouderde NIST-revisie of nooit is bijgewerkt voor een multi-cloudomgeving. De Cloud Key Management-services van Encryption Consulting vergelijken uw huidige sleutelbeheerpraktijken met NIST SP 800-57 Deel 1 Revisie 5, ontwerpen cryptoperioden en toegangsscheiding voor uw specifieke omgeving, en onze HSM-as-a-Service- oplossing biedt u hardwarematig ondersteunde sleutelbewaring zonder dat u zelf HSM's hoeft te beheren.

Veelgestelde Vragen / FAQ

Is NIST SP 800-57 Deel 1 Revisie 6 de huidige standaard?

Nee. Revisie 6 is nog steeds een eerste openbaar ontwerp; de commentaarperiode sloot op 5 februari 2026, maar het is nog niet definitief. Revisie 5, gepubliceerd in 2020, blijft de huidige officiële standaard.

Wat is een cryptoperiode?

Een cryptoperiode is de tijdsduur dat een specifieke sleutel voor het beoogde doel gebruikt mag worden voordat deze vernieuwd of, bij voorkeur, vervangen moet worden door een nieuwe sleutel.

Zou dezelfde sleutel ooit gebruikt moeten worden voor zowel authenticatie als decryptie?

Nee. NIST adviseert een unieke sleutel voor elk afzonderlijk doel; het gebruik van één sleutel voor meerdere doeleinden vergroot de impact als die ene sleutel wordt gecompromitteerd.

Waarom hebben asymmetrische sleutelparen twee verschillende cryptoperiodes?

De gebruiksperiode voor de afzender heeft betrekking op de ondertekeningssleutel, terwijl de gebruiksperiode voor de ontvanger betrekking heeft op de verificatie. De gebruiksperiode voor de ontvanger kan langer zijn dan de gebruiksperiode voor de afzender, zodat een handtekening nog steeds kan worden geverifieerd nadat de ondertekeningssleutel zelf niet meer geldig is.

Omvat de NIST-richtlijn specifiek het beheer van sleutels in meerdere clouds?

Niet direct. NIST SP 800-57 stelt leveranciersneutrale richtlijnen vast voor algoritmen en cryptoperioden; de specifieke vragen over de sleutelhiërarchie tussen clouds en de consistentie van toegangsbeleid moeten worden aangepakt door middel van een hybride en multi-cloud sleutelbeheerontwerp bovenop die basis.

Heeft u hulp nodig bij het benchmarken van uw sleutelbeheerprogramma aan de hand van de huidige NIST-richtlijnen? Neem dan contact op met het Cloud Key Management-team van Encryption Consulting.

Referenties

Projectpagina van de NIST Key Management Guidelines – csrc.nist.gov

NIST SP 800-57 Deel 1 Revisie 5 (definitieve publicatie) – csrc.nist.gov