10 best practices voor het beheer van enterprise-encryptiesleutels

Enterprise-sleutelbeheer voor encryptie regelt hoe cryptografische sleutels binnen een organisatie worden gegenereerd, opgeslagen, gedistribueerd, geroteerd en vernietigd. Zoals NIST SP 800-57 Deel 1 Rev. 5 stelt, hangt de beveiliging van informatie die door cryptografie wordt beschermd direct af van de sterkte van de sleutels en de bescherming die ze bieden. Een gecompromitteerde encryptiesleutel vereist geen kraken van het algoritme: het geeft directe toegang tot alle gegevens die door die sleutel worden beschermd. De aanbevolen actie: implementeer formele sleutelbeheerprocessen die de volledige levenscyclus van de sleutel omvatten, dwing hardwarematige sleutelopslag af voor zeer gevoelige sleutels, automatiseer de rotatie en zorg voor continue auditbewijs.

Kort antwoord: Waarom is bedrijfssleutelbeheer belangrijk?

Versleuteling beschermt gegevens; sleutelbeheer beschermt de mogelijkheid om te versleutelen en te ontsleutelen. Een gecompromitteerde versleutelingssleutel stelt een aanvaller in staat om beschermde gegevens te ontsleutelen, documenten of software namens u te ondertekenen, uw systemen te imiteren of toegang te krijgen tot uw netwerk. De meeste cryptografische fouten in de praktijk zijn fouten in het sleutelbeheer, niet in het algoritme: hardgecodeerde sleutels in de broncode, niet-geroteerde referenties, achtergebleven sleutels van voormalige medewerkers en handmatige beheerprocessen die niet schaalbaar zijn. De 10 onderstaande best practices pakken deze faalmodi systematisch aan. Voor meer context over sleuteltypen, zie onze artikelen over Best Practices voor openbaar en privé sleutelbeheer en HSM's en sleutelbeheer.

Moet u uw encryptiesleutels beheren?

Kortom, ja. Zoals vermeld in NIST SP 800-57 Deel 1, Rev. 5:

Uiteindelijk hangt de beveiliging van cryptografische informatie rechtstreeks af van de sterkte van de sleutels, de effectiviteit van de cryptografische mechanismen en protocollen die bij de sleutels horen, en de bescherming die de sleutels bieden. Geheime en privésleutels moeten worden beschermd tegen ongeautoriseerde openbaarmaking, en alle sleutels moeten worden beschermd tegen wijziging.

Het compromitteren van encryptiesleutels kan aanvallers in staat stellen om:

• Gegevens die op servers zijn opgeslagen, extraheren of manipuleren; versleutelde documenten of e-mails lezen.
• Het ondertekenen van aanvragen of documenten in de naam van uw organisatie maakt de verspreiding van malware mogelijk.
• Maak phishingwebsites die zich voordoen als uw legitieme sites en daarbij gebruikmaken van uw TLS-certificaten.
• Navigeer door uw bedrijfsnetwerk door u voor te doen als een geautoriseerde identiteit.

10 belangrijke beste managementpraktijken

1. Volg de beste praktijken voor sleutelgeneratie.

Cryptografische beveiliging begint bij het genereren van sleutels. Gebruik een hardwarematige True Random Number Generator (TRNG) die voldoet aan NIST SP 800-90A voor al het sleutelmateriaal. Selecteer algoritmen en sleutellengtes die geschikt zijn voor het gebruiksscenario en de vereiste beschermingsduur: RSA-3072 of hoger voor asymmetrische sleutels; AES-256 voor symmetrische sleutels; Ed25519 of ECDSA P-256 voor ondertekening. Sleutels die gegenereerd zijn met onvoldoende entropie of verouderde algoritmen zijn kwetsbaar vanaf het moment van creatie. Voor sleutels die gegevens beschermen die langdurig gevoelig zijn, selecteer algoritmen die veilig blijven gedurende de verwachte levensduur van de gegevens, waarbij rekening wordt gehouden met de migratietijdlijnen van algoritmen na de kwantumtechnologie.

2. Gebruik een gecentraliseerd sleutelbeheersysteem.

Een gecentraliseerd sleutelbeheersysteem (KMS) vormt de beheerslaag voor alle cryptografische sleutels. Het zorgt voor consistent beleid binnen de hele organisatie: standaarden voor sleutelgeneratie, rotatieschema's, toegangscontrole en auditregistratie. Zonder centralisatie beheren teams sleutels onafhankelijk van elkaar met behulp van ad-hocmethoden (spreadsheets, lokale bestanden, omgevingsvariabelen), wat leidt tot een wildgroei aan sleutels die onmogelijk systematisch te controleren of te roteren is. Het KMS vervangt de HSM-hardware voor sleutelbescherming niet; het is de beheerslaag, terwijl de HSM de opslag- en uitvoeringslaag vormt.

3. Gebruik sleutelversleutelingssleutels (KEK's)

Sleutelversleutelingssleutels (KEK's) beschermen andere versleutelingssleutels in plaats van de gegevens zelf. In een sleutelhiërarchie worden gegevens versleuteld met gegevensversleutelingssleutels (DEK's); DEK's worden versleuteld (omwikkeld) door KEK's; KEK's worden opgeslagen in een HSM of een beveiligde hardwareomgeving. Deze hiërarchie beperkt de blootstelling: DEK's kunnen in versleutelde vorm in algemene opslag aanwezig zijn, terwijl alleen de KEK hardwarematige bescherming vereist. Als een enkele DEK wordt gecompromitteerd, lopen alleen de met die DEK versleutelde gegevens risico; de KEK en alle andere DEK's blijven beschermd. Deze isolatie vormt de basis van alle schaalbare sleutelbeheerarchitecturen voor bedrijven.

4. Stel toegangsbeheer voor de sleutels in

Sleuteltoegangscontroles bepalen wie (en welke systemen) elke sleutel mag genereren, gebruiken, roteren, back-uppen en vernietigen. Toegangscontroles moeten op sleutelniveau worden geïmplementeerd, niet alleen op systeemniveau. Controles omvatten: op rollen gebaseerde toegangscontrole (RBAC) die het principe van minimale bevoegdheden afdwingt; multifactorauthenticatie voor sleutelbeheerbewerkingen; functiescheiding die ervoor zorgt dat niemand een gevoelige sleutelbewerking eenzijdig kan uitvoeren; en auditregistratie van elke toegangsgebeurtenis. PCI DSS-vereiste 3.7.6 vereist gedeelde kennis en dubbele controle voor handmatige sleutelbeheerbewerkingen; HSM M-of-N-quorummechanismen voldoen aan deze vereiste op hardwareniveau.

5. Centraliseer gebruikersrollen en toegang

Niet elke medewerker of elk systeem hoeft toegang te hebben tot elke sleutel. Definieer sleutelbeheerders, sleutelgebruikers en sleuteladministrators als afzonderlijke rollen met gedocumenteerde verantwoordelijkheden. Sleutelbeheerders beheren de levenscyclus van de sleutel (generatie, rotatie, intrekking); sleutelgebruikers voeren cryptografische bewerkingen uit met de sleutel; sleuteladministrators beheren de infrastructuur van het sleutelbeheersysteem. Zorg ervoor dat geen enkele administrator exclusieve toegang heeft tot sleutelmateriaal: als een administrator vertrekt of zijn of haar inloggegevens worden gecompromitteerd, moet de organisatie de sleutelbewerkingen kunnen voortzetten zonder afhankelijk te zijn van die persoon. Gecentraliseerd rolbeheer biedt ook het auditspoor dat nodig is als bewijs van naleving.

6. Gebruik Key Backup and Recovery

Het verlies van een cryptografische sleutel die gegevens beschermt en die niet kan worden hersteld, is een dataverliesgebeurtenis. Een goede back-up van de sleutel zorgt ervoor dat versleutelde gegevens kunnen worden ontsleuteld, zelfs als de primaire sleutelopslag uitvalt. Sleutelback-ups moeten zelf versleuteld zijn (met behulp van het back-upmechanisme van de HSM, niet met een softwarewachtwoord); opgeslagen worden op een geografisch gescheiden locatie van de primaire sleutelopslag; beveiligd worden met M-van-N-beheerdersreferenties, zodat niemand de back-up zelfstandig kan herstellen; en jaarlijks getest worden door middel van een herstelprocedure op een secundair systeem. Een niet-geteste back-up is gelijk aan geen back-up voor noodhersteldoeleinden.

7. Gebruik sleutelvervaldatum (cryptoperiodebeheer)

Elke sleutel moet een gedefinieerde cryptoperiode hebben: de periode waarin deze is geautoriseerd voor gebruik. NIST SP 800-57 beveelt cryptoperiodes aan op basis van het algoritme, de sleutelgrootte en de gevoeligheid en het volume van de beschermde gegevens. Sleutelvervalbeperkingen beperken de blootstelling: een sleutel die niet langer wordt gebruikt, kan niet worden misbruikt. Definieer cryptoperiodes in het beleid vóór de implementatie; configureer het sleutelbeheersysteem om deze automatisch af te dwingen. Voor TLS-certificaten schrijft het CA/Browser Forum momenteel een maximale levensduur van 398 dagen voor, met verlagingen naar 200 dagen (maart 2026), 100 dagen (2027) en 47 dagen (2029), waardoor geautomatiseerd lifecyclemanagement essentieel is. Zie CertSecure Manager voor automatisering van de certificaatlifecycle.

8. Gebruik sleutelintrekking

Het intrekken van een sleutel maakt deze onmiddellijk ongeldig, waardoor deze niet langer kan worden gebruikt voor het decoderen van gegevens of authenticatie. Intrekking is vereist wanneer: een sleutel is bevestigd of vermoed wordt gecompromitteerd te zijn; een medewerker met toegang tot de sleutel de organisatie verlaat; een systeem dat de sleutel gebruikt, buiten gebruik wordt gesteld; of het algoritme dat de sleutel gebruikt, verouderd is. De intrekking moet worden doorgevoerd in elk systeem dat de sleutel vertrouwde: voor certificaten betekent dit het publiceren van CRL's en het bijwerken van OCSP-reacties; voor SSH-sleutels betekent dit het verwijderen van de publieke sleutel uit authorized_keys op alle servers waartoe de gebruiker toegang had; voor symmetrische sleutels betekent dit het markeren van de sleutel als ingetrokken in het KMS en het blokkeren van het gebruik ervan voor nieuwe bewerkingen.

9. Gebruik automatisering in uw voordeel

Handmatig sleutelbeheer is niet schaalbaar in bedrijfsomgevingen. Gemiste rotatiedeadlines, inconsistente toegangscontroles, vergeten intrekkingen en menselijke fouten bij het genereren van sleutels zijn de belangrijkste oorzaken van mislukt sleutelbeheer. Automatisering pakt deze risico's aan: geautomatiseerde sleutelrotatie volgens beleidsmatige schema's zorgt ervoor dat rotatie daadwerkelijk plaatsvindt; geautomatiseerde certificaatvernieuwing voorkomt storingen als gevolg van verlopen certificaten; geautomatiseerde verspreiding van intrekkingen zorgt ervoor dat voormalige medewerkers geen toegang meer kunnen behouden; geautomatiseerde inventarisdetectie voorkomt dat ongebruikte sleutels zich ophopen. Zie CertSecure Manager voor automatisering van certificaatbeheer ; zie SSH Secure voor automatisering van de levenscyclus van SSH-sleutels.

10. Bereid je voor op het afhandelen van incidenten

Ondanks correct beleid en adequate controles kunnen er zich incidenten voordoen waarbij belangrijke systemen worden gecompromitteerd. Organisaties moeten voorbereid zijn met een gedocumenteerd incidentresponsplan voor dergelijke incidenten, voordat een incident plaatsvindt. Veelvoorkomende incidenten zijn onder andere:

• De gebruiker is de toegang tot zijn sleutels kwijt.
• Een medewerker vertrekt of wordt ontslagen terwijl er nog toegangsbewijs voor de sleutel openstaat.
• Een gebrekkig encryptiealgoritme is geïdentificeerd als verouderd of defect.
• Menselijke fout: privésleutel per ongeluk gepubliceerd in een openbare codeopslagplaats.
• In de auditlogboeken is een vermoedelijke ongeautoriseerde toegang tot de sleutel gedetecteerd.

Het incidentresponsplan moet het volgende omvatten: onmiddellijke intrekking van de vermoedelijk gecompromitteerde sleutel; generatie en distributie van vervangend sleutelmateriaal; impactanalyse om vast te stellen welke gegevens of systemen door de gecompromitteerde sleutel werden beschermd; kennisgeving aan belanghebbenden; en evaluatie na het incident om de hoofdoorzaak te achterhalen en de beveiligingsmaatregelen bij te werken. Controleer uw beveiligingsinfrastructuur regelmatig om de frequentie en impact van incidenten te minimaliseren.

Belangrijkste verantwoordelijkheden gedurende de levenscyclus: Wie is verantwoordelijk in elke fase?

Levenscyclusfase	Activiteit	Eigenaar	Controleer:
Generatie	Maak een sleutelpaar aan met behulp van TRNG; selecteer het algoritme en de sleutellengte.	Sleutelbeheerder of geautomatiseerd KMS	Algoritmebeleid; HSM-grensvereiste
Distributie	Lever publieke sleutels aan vertrouwende systemen; distribueer symmetrische sleutels veilig met behulp van KEK-wrapping.	KMS; PKI voor certificaatgebaseerde publieke sleutels	Beveiligd kanaal; certificaatvalidatie
Opslag	Bescherm privé- en symmetrische sleutels in een HSM of een goedgekeurde beveiligde kluis.	HSM-operator; sleutelbeheerder	FIPS 140-2 Level 3+ hardware; geen platte tekst buiten de grenzen
Gebruik	Cryptografische bewerkingen uitvoeren (versleutelen, ontsleutelen, ondertekenen, verifiëren)	Applicatie of dienst geautoriseerd door KMS	RBAC; auditlogboek van alle bewerkingen
Rotatie	Genereer een vervangende sleutel; distribueer deze; versleutel of onderteken opnieuw indien nodig; trek de oude sleutel in.	Geautomatiseerd KMS of sleutelbeheerder	Beleidsmatig gedefinieerde cryptoperiode of gebeurtenistrigger
herroeping	Maak de sleutel onmiddellijk ongeldig bij een inbreuk, vertrek of veroudering van het algoritme.	Sleutelbeheerder of geautomatiseerde trigger	Doorgifte naar alle afhankelijke systemen; auditregistratie
Vernietiging	Veilige verwijdering met FIPS 140-conforme nulstelling; auditbewijs van vernietiging	Belangrijkste beheerder; KMS	Nulstelling volgens NIST SP 800-88; vernietigingslogboek

Aanleidingen voor rotatie: Wanneer buiten het rooster te rouleren

Tijdsgebonden rotatieschema's vormen de basis; gebeurtenisgebonden triggers zijn het vangnet. Elk van de volgende gebeurtenissen moet onmiddellijke sleutelrotatie activeren, ongeacht waar de sleutel zich in de geplande cryptoperiode bevindt:

• Vertrek van een medewerker of functieverandering: Bij vertrek of functieverandering moeten de sleutels van belangrijke materialen van elke medewerker die deze in bezit had of er toegang toe had, onmiddellijk worden vervangen en de toegang daartoe worden ingetrokken.
• Vermoedelijke of bevestigde inbreuk: Elke aanwijzing dat belangrijk materiaal is blootgesteld (gelekt naar een codeopslagplaats, geraadpleegd door een onbevoegde partij, gevonden in een geheugendump) vereist onmiddellijke intrekking en vervanging.
• Algoritme wordt afgeschaft: Wanneer een cryptografisch algoritme door NIST als verouderd wordt beschouwd (bijvoorbeeld SHA-1 voor handtekeningen, RSA-1024, DSA), moeten alle sleutels die dat algoritme gebruiken, worden vervangen.
• Systeemontmanteling: Wanneer een systeem dat een sleutel gebruikte buiten gebruik wordt gesteld, moet de sleutel worden ingetrokken en moet ervoor worden gezorgd dat deze niet opnieuw in een ander systeem wordt gebruikt.
• Beëindiging van toegang door derden: Wanneer een leverancier, aannemer of partner wiens systemen de sleutel gebruikten de relatie beëindigt, moet de toegang worden ingetrokken en de sleutel worden vervangen.

Platformvergelijking: KMS versus HSM versus Cloud Key Service

Afmeting	Software KMS	On-premises HSM	Cloud Key Service (KMS)	Cloud HSM (HSMaaS)
Beveiliging van sleutelopslag	Softwarematig beveiligd; kwetsbaar voor inbreuken door het besturingssysteem.	FIPS 140-2 Level 3 hardwaregrens; sleutels nooit in platte tekst buiten	Door de provider beheerde software of gedeelde hardware	FIPS 140-2 Level 3 dedicated hardware; klant-exclusieve partitie
Toegang tot de providersleutel	Niet van toepassing (ter plaatse)	Niet van toepassing (ter plaatse)	De aanbieder heeft mogelijk toegang tot belangrijk materiaal.	De provider heeft geen toegang tot het sleutelmateriaal van de klant.
Compliant	Afhankelijk van softwarebesturingselementen	FIPS 140-3 gevalideerd; voldoet aan PCI HSM, overheids-PKI	Geschikt voor de meeste commerciële werkzaamheden.	Gevalideerd volgens FIPS 140-3; voldoet aan de eisen voor hoge betrouwbaarheid.
Operationele overhead	Laag (softwarematig beheerd)	Hoog (hardware, firmware, fysiek)	Zeer laag (beheerd door de aanbieder)	Gemiddeld (aanbieder beheert de hardware; klant beheert de sleutels)
Best voor	Beleids- en levenscyclusbeheerlaag (te gebruiken met HSM)	CA-rootsleutels, betalings-HSM, geclassificeerde omgevingen	De meeste cloudworkloads gebruiken encryptie van data in rust.	Beveiligde cloudopslag van sleutels zonder hardware op locatie.

Praktische implementatieworkflow

1. Inventariseer alle bestaande sleutels: Ontdek alle sleutels die binnen de organisatie in gebruik zijn. Koppel elke sleutel aan de eigenaar, het algoritme, de sleutellengte, de aanmaakdatum, de vervaldatum (indien ingesteld) en de systemen en gegevens die ermee worden beschermd. Sleutels waarvan geen eigenaar is of die niet gedocumenteerd zijn, vormen een direct risico.
2. Classificeer sleutels op basis van risico: Segmenteer sleutels op basis van gevoeligheid (CA-rootsleutels, betaalsleutels, TLS-privésleutels, SSH-sleutels, database-DEK's) en wijs beveiligingsvereisten en rotatieschema's toe aan elke categorie.
3. Implementeer een gecentraliseerd KMS: Implementeer een sleutelbeheersysteem dat beleid afdwingt, de levenscyclusfasen bijhoudt en auditlogboeken biedt voor alle sleutelbewerkingen.
4. Bescherm zeer gevoelige sleutels in HSM-hardware: Migreer CA-sleutels, KEK's, betaalsleutels en codeondertekeningssleutels naar HSM-opslag die voldoet aan FIPS 140-2 niveau 3 of hoger. Zie HSM als een service voor beheerde HSM-opties.
5. Definieer en implementeer belangrijke toegangscontroles: Wijs belangrijke beheerders aan; documenteer rollen en verantwoordelijkheden; handhaaf RBAC en MFA voor alle belangrijke beheertaken; implementeer functiescheiding.
6. Automatiseer de rotatie en de levenscyclus van certificaten: Configureer het KMS om cryptoperioden af ​​te dwingen en automatische rotatie te activeren; integreer met een geautomatiseerd CLM-platform voor de vernieuwing van TLS-certificaten voordat de vereiste levensduur van 47 dagen ingaat.
7. Stel auditregistratie en -monitoring in: Registreer alle belangrijke bewerkingen (aanmaken, toegang, gebruik, rotatie, intrekking, vernietiging) in een centraal systeem; waarschuw bij afwijkende patronen (onverwachte toegangstijden, ongebruikelijke bewerkingsvolumes, toegang vanaf ongeautoriseerde systemen).
8. Documenteer en test het incidentresponsplan: Beschrijf de procedure voor het reageren op een beveiligingsincident; test deze minstens jaarlijks in een simulatieoefening; bevestig dat de intrekking correct wordt doorgegeven aan alle systemen die ervan afhankelijk zijn.

Auditbewijs: Wat vereisen belangrijke managementaudits?

Compliancekaders zoals PCI DSS, HIPAA, NIST en ISO/IEC 27001 vereisen dat organisaties aantonen, en niet alleen beweren, dat belangrijke beheersmaatregelen aanwezig en effectief zijn. Controleerbaar bewijs omvat:

• Belangrijkste inventaris: Een actueel overzicht van alle relevante sleutels, hun algoritme, sleutellengte, aanmaakdatum, vervaldatum, eigenaar en de systemen die ze gebruiken.
• Belangrijke ceremoniedocumentatie: Ondertekende verslagen van de ceremonies voor het genereren van de root CA- en HSM-hoofdsleutels, inclusief de aanwezigheid van beheerders, de validatie van de hardware en de voltooide stappen.
• Bewijs van toegangscontrole: Documentatie van roltoewijzingen, RBAC-configuratie en verslagen van toegangscontrolebeoordelingen.
• Bewijs voor rotatie: Logboeken waaruit blijkt dat sleutels volgens schema zijn geroteerd; registraties van door gebeurtenissen geactiveerde rotaties met onderbouwing.
• Bewijs van intrekking: Auditregistraties van belangrijke intrekkingen, de reden voor elke intrekking en de tijd tussen het moment van intrekking en de voltooiing ervan.
• Testresultaten van back-up en herstel: Gedateerde rapporten van HSM-back-uphersteltests bevestigen dat back-ups geldig zijn en dat de herstelprocedures werken.

Conclusie

Het beheer van encryptiesleutels binnen een onderneming is geen eenmalige configuratie. Het is een continu proces dat de kwaliteit van sleutelgeneratie, gecentraliseerd beheer, hardwarematige opslag voor zeer gevoelige sleutels, toegangscontrole, rotatie, intrekking, back-up, automatisering en incidentparaatheid omvat. De 10 beste praktijken hierboven behandelen de faalmodi die daadwerkelijke cryptografische incidenten veroorzaken. De meeste van deze incidenten zijn geen algoritmebreuken, maar fouten in het sleutelbeheer. Zie voor meer informatie onze artikelen over openbaar en privé sleutelbeheer , HSM's en sleutelbeheer en SSH-sleutelrotatiebeleid.

Veelgestelde Vragen / FAQ

Wat is het beheer van encryptiesleutels voor bedrijven?

De verzameling processen, beleidsregels en technologische beheersmaatregelen die bepalen hoe cryptografische sleutels binnen een organisatie worden gegenereerd, gedistribueerd, opgeslagen, gebruikt, geroteerd en vernietigd. NIST SP 800-57 stelt dat de beveiliging van versleutelde gegevens direct afhangt van de bescherming van de sleutels waarmee deze gegevens zijn versleuteld.

Hoe vaak moeten encryptiesleutels worden geroteerd?

De rotatiefrequentie moet gebaseerd zijn op risico's. Zeer gevoelige sleutels (CA-root, ondertekening) moeten mogelijk elke 1-3 jaar of bij organisatorische gebeurtenissen worden geroteerd. Sleutels voor gegevensversleuteling moeten jaarlijks of vaker worden geroteerd. TLS-certificaten zullen naar verwachting in 2029 een levensduur van 47 dagen hebben. Gebeurtenisgestuurde triggers (inbreuk, vertrek, afschaffing van algoritme) moeten voorrang hebben op schema's.

Wat is een KEK en waarom wordt deze gebruikt?

Een sleutelversleutelingssleutel (KEK) versleutelt andere cryptografische sleutels (DEK's) in plaats van de gegevens zelf. Gegevens worden versleuteld door DEK's; DEK's worden omhuld door KEK's; KEK's worden beschermd in HSM-hardware. Als een DEK wordt gecompromitteerd, lopen alleen de met die DEK versleutelde gegevens risico; de KEK en andere DEK's blijven beschermd. Deze hiërarchie beperkt de blootstelling en is schaalbaar naar een groot aantal sleutels.

Wat is het verschil tussen een KMS en een HSM?

Een KMS (Key Management System) is software die de levenscyclus van sleutels beheert: beleid, toegangscontrole, rotatieplanning en auditregistratie. Een HSM (Hardware Security Module) is hardware die sleutels opslaat en gebruikt binnen een FIPS-gecertificeerde, fraudebestendige beveiliging. Ze vullen elkaar aan: KMS biedt governance; HSM biedt hardwarematige sleutelbescherming. De beste werkwijze is om beide te combineren: KMS voor levenscyclusbeheer en HSM-hardware voor sleutelopslag.

Welke compliance-raamwerken vereisen formeel sleutelbeheer?

PCI DSS v4.0 Vereiste 3.7 (gesplitste kennis, dubbele controle, rotatie, versleutelde opslag); HIPAA-beveiligingsregel Technische waarborgen voor ePHI-versleutelingssleutels; NIST SP 800-57 (waarnaar wordt verwezen door FedRAMP, FISMA, DoD); AVG Artikel 32 (passende technische maatregelen); ISO/IEC 27001:2022 Controle 8.24 (gebruik van cryptografie).

Wat moet een incidentresponsplan voor een beveiligingslek met gecompromitteerde sleutels omvatten?

Onmiddellijke intrekking van de sleutel; genereren en distribueren van een vervangende sleutel; beoordeling van de impact op de gegevens (welke gegevens werden beschermd door de gecompromitteerde sleutel); kennisgeving aan belanghebbenden; en evaluatie na het incident om de hoofdoorzaak te achterhalen en de beheersmaatregelen bij te werken. Documenteer en test het plan minstens jaarlijks voordat een incident het vereist.