Sleutelrotatiebeleid Voor Azure Key Vault En Cryptografische Assets

Zonder een gestructureerd sleutelrotatiebeleid blijven cryptografische sleutels, certificaten en geheimen jarenlang ongewijzigd in gebruik, wat aanzienlijke beveiligingsrisico's met zich meebrengt. Hoe langer een sleutel in gebruik is, hoe groter de kans dat deze wordt gecompromitteerd door insider threats, externe aanvallen, configuratiefouten of kwetsbaarheden in de onderliggende cryptografische algoritmes. Bovendien neemt de potentiële schade toe naarmate een gecompromitteerde sleutel langer actief blijft: een aanvaller die toegang heeft verkregen tot een sleutel kan deze gebruiken om data te ontsleutelen, authenticatie te omzeilen of integriteit te manipuleren, en dit risico blijft bestaan zolang de sleutel niet wordt vervangen. Voor Nederlandse overheidsorganisaties die gevoelige data verwerken, inclusief persoonsgegevens, bedrijfsgevoelige informatie en nationale veiligheidsgevoelige data, is dit onacceptabel. Daarnaast vereisen compliance-kaders zoals NIS2, BIO en ISO 27001 dat organisaties kunnen aantonen dat zij passende maatregelen hebben getroffen voor key management, inclusief regelmatige rotatie van cryptografische assets. Zonder een gedocumenteerd en geïmplementeerd sleutelrotatiebeleid kunnen organisaties niet voldoen aan deze eisen en lopen zij het risico op sancties, reputatieschade en verlies van vertrouwen van burgers en stakeholders.

Implementatie

Dit artikel beschrijft een concrete implementatie van sleutelrotatiebeleid voor Azure-omgevingen, specifiek toegespitst op de context van Nederlandse overheidsorganisaties. Het beleid is gebaseerd op vijf fundamentele pijlers: inventarisatie en classificatie van cryptografische assets, rotatie-intervallen op basis van risico en compliance-vereisten, geautomatiseerde rotatieprocessen met Azure Key Vault en Azure Automation, monitoring en alerting voor rotatie-events en compliance-status, en documentatie en audit trails voor aantoonbare compliance. De eerste pijler betreft inventarisatie en classificatie waarbij alle cryptografische assets – inclusief sleutels, certificaten, geheimen en managed identities – worden geïnventariseerd en geclassificeerd op basis van gevoeligheid, gebruik en compliance-vereisten. De tweede pijler richt zich op rotatie-intervallen waarbij verschillende assets verschillende rotatie-intervallen krijgen op basis van risico: kritieke sleutels voor encryptie van gevoelige data worden bijvoorbeeld jaarlijks geroteerd, terwijl minder kritieke sleutels om de twee jaar kunnen worden geroteerd. De derde pijler adresseert geautomatiseerde rotatieprocessen waarbij Azure Key Vault automatic key rotation, Azure Automation runbooks en Azure Functions worden gebruikt om rotaties automatisch uit te voeren zonder handmatige interventie. De vierde pijler betreft monitoring en alerting waarbij Azure Monitor, Log Analytics en Azure Sentinel worden gebruikt om rotatie-events te monitoren, compliance-status te rapporteren en alerts te genereren wanneer rotaties falen of wanneer assets de rotatiedatum naderen. De vijfde pijler richt zich op documentatie en audit trails waarbij alle rotatie-events worden vastgelegd in audit logs, compliance-rapportages worden gegenereerd en documentatie wordt bijgehouden voor auditdoeleinden. Het artikel beschrijft voor elke pijler concrete implementatiestappen, best practices, Azure-native services die kunnen worden ingezet, en hoe de pijlers onderling samenwerken om een robuust sleutelrotatiebeleid te creëren. Daarnaast wordt uitgelegd hoe dit beleid aansluit bij NIS2-verplichtingen, BIO-normen en Microsoft's key management best practices.

Inventarisatie en classificatie van cryptografische assets

Een effectief sleutelrotatiebeleid begint bij een volledige inventarisatie van alle cryptografische assets die worden gebruikt in de Azure-omgeving. Zonder een compleet overzicht is het onmogelijk om te bepalen welke assets moeten worden geroteerd, met welke frequentie en welke risico's er bestaan wanneer rotaties worden overgeslagen. Deze inventarisatie moet niet alleen technische details bevatten – zoals welke sleutels, certificaten en geheimen er zijn, waar deze worden opgeslagen, welke services deze gebruiken en wanneer deze zijn aangemaakt – maar ook functionele context: welke assets zijn kritiek voor de dienstverlening, welke data wordt beschermd, wat is de classificatie van deze data, welke compliance-vereisten gelden en wat zijn de business impact en recovery time objectives wanneer een asset wordt gecompromitteerd. Deze informatie vormt de basis voor het bepalen van de prioritering en de intensiteit van rotatieprocessen per asset. Na inventarisatie worden alle cryptografische assets geclassificeerd op basis van gevoeligheid, gebruik en compliance-vereisten. Binnen Nederlandse overheidsorganisaties wordt typisch een classificatieschema gebruikt dat aansluit bij de BIO-classificatie: Openbaar, Intern, Vertrouwelijk, Geheim en Zeer Geheim. Assets die worden gebruikt voor encryptie van Geheime of Zeer Geheime data krijgen de hoogste prioriteit voor rotatie en worden jaarlijks of zelfs vaker geroteerd. Assets die worden gebruikt voor Vertrouwelijke data krijgen een middelmatige prioriteit en worden om de twee jaar geroteerd. Assets die worden gebruikt voor Interne of Openbare data krijgen een lagere prioriteit en kunnen om de drie tot vijf jaar worden geroteerd, afhankelijk van de specifieke risico's en compliance-vereisten. Daarnaast worden assets geclassificeerd op basis van gebruik: assets die worden gebruikt voor high-volume encryptie-operaties, assets die worden gebruikt voor authenticatie van kritieke services, assets die worden gebruikt voor signing van belangrijke documenten, en assets die worden gebruikt voor backup-encryptie krijgen verschillende rotatie-intervallen op basis van hun specifieke risicoprofiel. Een belangrijk onderdeel van classificatie is het bepalen van de cryptografische sterkte en levensduur van assets. Oudere cryptografische algoritmes zoals RSA-1024 of SHA-1 worden als onveilig beschouwd en moeten worden vervangen door moderne algoritmes zoals RSA-2048 of hoger, ECDSA of EdDSA, en SHA-256 of hoger. Assets die gebruikmaken van verouderde algoritmes krijgen de hoogste prioriteit voor rotatie, ongeacht hun classificatie, omdat deze assets een direct beveiligingsrisico vormen. Daarnaast worden assets geëvalueerd op basis van hun cryptografische levensduur: certificaten hebben bijvoorbeeld een beperkte geldigheidsduur en moeten worden vervangen voordat zij verlopen, terwijl sleutels theoretisch onbeperkt kunnen worden gebruikt maar praktisch gezien regelmatig moeten worden geroteerd om het risico van compromittering te beperken. Door assets te classificeren op basis van gevoeligheid, gebruik, cryptografische sterkte en levensduur ontstaat een gestructureerd kader voor het bepalen van rotatie-intervallen en prioriteiten.

Rotatie-intervallen op basis van risico en compliance

Rotatie-intervallen worden bepaald op basis van risicoanalyse, compliance-vereisten en best practices voor key management. Binnen Nederlandse overheidsorganisaties worden typisch de volgende rotatie-intervallen gehanteerd: kritieke sleutels voor encryptie van Geheime of Zeer Geheime data worden jaarlijks geroteerd, sleutels voor encryptie van Vertrouwelijke data worden om de twee jaar geroteerd, sleutels voor encryptie van Interne data worden om de drie jaar geroteerd, en sleutels voor encryptie van Openbare data worden om de vijf jaar geroteerd. Daarnaast worden certificaten geroteerd op basis van hun geldigheidsduur: certificaten met een korte geldigheidsduur (bijvoorbeeld één jaar) worden automatisch geroteerd voordat zij verlopen, terwijl certificaten met een langere geldigheidsduur (bijvoorbeeld drie jaar) worden geroteerd op basis van een risicoanalyse die rekening houdt met de specifieke gebruikssituatie en compliance-vereisten. Voor Azure Key Vault-specifieke assets worden aanvullende rotatie-intervallen gehanteerd: customer-managed keys voor Azure Storage worden bijvoorbeeld jaarlijks geroteerd voor Vertrouwelijke en Geheime data, en om de twee jaar voor Interne data. Customer-managed keys voor Azure SQL worden jaarlijks geroteerd voor alle classificaties, omdat database-encryptie kritiek is voor data protection. Azure Disk Encryption keys worden jaarlijks geroteerd voor alle classificaties, omdat disk encryption essentieel is voor bescherming van data at rest. Azure Key Vault secrets worden om de zes maanden geroteerd voor kritieke secrets zoals API-keys en connection strings, en jaarlijks voor minder kritieke secrets. Azure Managed Identities worden niet geroteerd, maar worden regelmatig geëvalueerd op basis van toegangsrechten en gebruik. Rotatie-intervallen worden niet alleen bepaald op basis van classificatie, maar ook op basis van specifieke risico's en compliance-vereisten. Assets die worden gebruikt voor high-volume encryptie-operaties worden bijvoorbeeld vaker geroteerd dan assets die worden gebruikt voor low-volume operaties, omdat high-volume assets een groter aanvalsoppervlak vormen. Assets die worden gebruikt voor authenticatie van kritieke services worden vaker geroteerd dan assets die worden gebruikt voor authenticatie van minder kritieke services, omdat compromittering van kritieke services een grotere business impact heeft. Assets die worden gebruikt voor signing van belangrijke documenten worden vaker geroteerd dan assets die worden gebruikt voor signing van minder belangrijke documenten, omdat compromittering van signing keys kan leiden tot vervalsing van belangrijke documenten. Door rotatie-intervallen te baseren op risicoanalyse en compliance-vereisten ontstaat een gestructureerd kader dat zowel beveiliging als compliance waarborgt.

Geautomatiseerde rotatieprocessen met Azure Key Vault en Azure Automation

Gebruik PowerShell-script key-rotation-policies.ps1 (functie Invoke-Implementation) – Valideert en implementeert sleutelrotatiebeleid controles voor Azure Key Vault en cryptografische assets.

Geautomatiseerde rotatieprocessen zijn essentieel voor een effectief sleutelrotatiebeleid, omdat handmatige rotatieprocessen foutgevoelig zijn, tijdrovend zijn en het risico lopen dat rotaties worden overgeslagen of vergeten. Azure Key Vault biedt verschillende mechanismen voor geautomatiseerde rotatie: automatic key rotation voor Azure Key Vault keys, automatic certificate renewal voor Azure Key Vault certificates, en event-driven rotation voor Azure Key Vault secrets via Azure Event Grid en Azure Functions. Daarnaast kunnen Azure Automation runbooks worden gebruikt voor complexere rotatieprocessen die meerdere services omvatten of specifieke business logic vereisen. Voor Azure Key Vault keys wordt automatic key rotation geïmplementeerd door Azure Key Vault automatic key rotation in te schakelen, waarbij Azure Key Vault automatisch nieuwe key versions genereert op basis van een geconfigureerd rotatie-interval. Deze functionaliteit is beschikbaar voor RSA, EC en oct keys, en kan worden geconfigureerd via Azure Portal, Azure CLI of Azure PowerShell. Voor Azure Key Vault certificates wordt automatic certificate renewal geïmplementeerd door Azure Key Vault automatic certificate renewal in te schakelen, waarbij Azure Key Vault automatisch nieuwe certificaatversies genereert voordat certificaten verlopen. Deze functionaliteit is beschikbaar voor certificaten die zijn uitgegeven door geïntegreerde certificate authorities zoals DigiCert, GlobalSign en Microsoft Certificate Authority. Voor Azure Key Vault secrets wordt event-driven rotation geïmplementeerd door Azure Event Grid te configureren voor Key Vault events, waarbij Azure Functions worden getriggerd wanneer secrets moeten worden geroteerd. Deze aanpak is flexibeler dan automatic rotation en kan worden aangepast aan specifieke business requirements. Azure Functions kunnen bijvoorbeeld secrets roteren door nieuwe waarden te genereren, oude waarden te archiveren, en services te notificeren over nieuwe secret values. Daarnaast kunnen Azure Automation runbooks worden gebruikt voor complexere rotatieprocessen die meerdere services omvatten, zoals het roteren van customer-managed keys voor Azure Storage en Azure SQL, waarbij nieuwe keys worden gegenereerd, oude keys worden gearchiveerd, en services worden geconfigureerd om nieuwe keys te gebruiken. Een belangrijk onderdeel van geautomatiseerde rotatieprocessen is het testen en valideren van rotatieprocedures voordat deze in productie worden geïmplementeerd. Rotatieprocessen moeten worden getest in een testomgeving om te verifiëren dat zij correct functioneren, dat services correct worden geconfigureerd om nieuwe keys te gebruiken, en dat oude keys correct worden gearchiveerd. Daarnaast moeten rotatieprocessen worden gemonitord om te verifiëren dat zij succesvol zijn voltooid en dat er geen fouten zijn opgetreden. Door geautomatiseerde rotatieprocessen te implementeren, te testen en te monitoren ontstaat een robuust sleutelrotatiebeleid dat zowel beveiliging als compliance waarborgt.

Monitoring en alerting voor rotatie-events en compliance-status

Gebruik PowerShell-script key-rotation-policies.ps1 (functie Invoke-Monitoring) – Monitort de status van sleutelrotatiebeleid controles en compliance-status.

Effectieve monitoring en alerting zijn essentieel voor een succesvol sleutelrotatiebeleid, omdat zij ervoor zorgen dat rotaties tijdig worden uitgevoerd, dat rotaties succesvol zijn voltooid, en dat compliance-status wordt gerapporteerd aan stakeholders. Monitoring richt zich niet alleen op individuele rotatie-events, maar vooral ook op de algehele compliance-status van het sleutelrotatiebeleid: hoeveel assets zijn compliant met rotatie-intervallen, hoeveel assets naderen hun rotatiedatum, hoeveel assets zijn niet-compliant, en wat zijn de trends over tijd. In de praktijk betekent dit dat de organisatie een beperkt aantal kernindicatoren definieert – Key Rotation Compliance Indicators (KRCI's) – die periodiek worden gemeten en gerapporteerd aan CISO, CIO en bestuur. Voor rotatie-events worden metrics gemeten zoals het aantal succesvolle rotaties per periode, het aantal gefaalde rotaties per periode, de gemiddelde tijd voor rotatie-uitvoering, het aantal assets dat de rotatiedatum nadert, en het aantal assets dat de rotatiedatum heeft overschreden. Voor compliance-status worden metrics gemeten zoals het percentage assets dat compliant is met rotatie-intervallen, het percentage assets dat niet-compliant is, het aantal assets per classificatie die compliant zijn, en de trend in compliance-status over tijd. Voor Azure Key Vault-specifieke assets worden aanvullende metrics gemeten zoals het aantal keys met automatic rotation ingeschakeld, het aantal certificates met automatic renewal ingeschakeld, het aantal secrets met event-driven rotation geconfigureerd, en het aantal customer-managed keys die zijn geroteerd. Alerting wordt geconfigureerd voor kritieke events zoals gefaalde rotaties, assets die de rotatiedatum naderen, assets die de rotatiedatum hebben overschreden, en assets die niet-compliant zijn met rotatie-intervallen. Alerts worden verzonden naar security teams, operations teams en compliance officers, zodat tijdig actie kan worden ondernomen. Daarnaast worden periodieke compliance-rapportages gegenereerd die de status van het sleutelrotatiebeleid samenvatten, trends identificeren, en aanbevelingen doen voor verbetering. Deze rapportages worden gedeeld met bestuur en directie, zodat zij weloverwogen keuzes kunnen maken over risicoacceptatie, prioritering van verbeteracties en benodigde middelen. Een belangrijk onderdeel van monitoring is het creëren van geïntegreerde dashboards die de status van het sleutelrotatiebeleid samenbrengen in één overzichtelijk beeld. In plaats van afzonderlijke dashboards per asset-type, wordt informatie samengebracht in een centraal key rotation compliance dashboard dat laat zien hoe verschillende assets presteren ten opzichte van rotatie-intervallen, waar potentiële risico's bestaan, en welke acties vereist zijn om compliance te waarborgen. Dit dashboard moet niet alleen technische details tonen, maar vooral ook risico-indicatoren die begrijpelijk zijn voor bestuurders en niet-technische stakeholders. Binnen Nederlandse overheidsorganisaties sluit dit aan bij de behoefte aan overzichtelijke rapportages die voldoen aan NIS2- en BIO-verplichtingen voor security reporting.

Documentatie en audit trails voor aantoonbare compliance

Documentatie en audit trails zijn essentieel voor aantoonbare compliance met sleutelrotatiebeleid, omdat auditors en toezichthouders verwachten dat organisaties kunnen aantonen dat zij passende maatregelen hebben getroffen voor key management en cryptografische beveiliging. Documentatie moet niet alleen technische details bevatten – zoals welke assets er zijn, welke rotatie-intervallen worden gehanteerd, en hoe rotatieprocessen zijn geïmplementeerd – maar vooral ook governance-context: wie is verantwoordelijk voor sleutelrotatie, hoe worden beslissingen genomen over rotatie-intervallen, hoe worden risico's geëvalueerd, en hoe wordt compliance gemonitord en gerapporteerd. Deze documentatie vormt de basis voor audit trails die laten zien dat het sleutelrotatiebeleid daadwerkelijk wordt geïmplementeerd en gevolgd. Audit trails worden gegenereerd door alle rotatie-events vast te leggen in Azure Key Vault audit logs, Azure Monitor logs en Log Analytics workspaces. Deze logs bevatten informatie over wanneer rotaties zijn uitgevoerd, wie rotaties heeft geïnitieerd, welke assets zijn geroteerd, of rotaties succesvol zijn voltooid, en welke fouten zijn opgetreden. Daarnaast worden compliance-rapportages gegenereerd die de status van het sleutelrotatiebeleid samenvatten, trends identificeren, en aanbevelingen doen voor verbetering. Deze rapportages worden opgeslagen in een centrale locatie, zoals Azure Storage of SharePoint, en worden regelmatig herzien en bijgewerkt. Voor auditdoeleinden is het essentieel dat de organisatie kan laten zien dat: er een formeel vastgesteld sleutelrotatiebeleid is dat ook voor Azure geldt; alle cryptografische assets zijn geïnventariseerd en geclassificeerd; rotatie-intervallen zijn bepaald op basis van risicoanalyse en compliance-vereisten; geautomatiseerde rotatieprocessen zijn geïmplementeerd en getest; monitoring en alerting zijn geconfigureerd; en dat uitgevoerde maatregelen en resterende risico's traceerbaar zijn naar concrete besluiten en acties. Het gebruik van gestandaardiseerde formats, centrale opslag van configuraties en systematische koppeling met compliance-dashboards is hierbij onmisbaar. Het PowerShell-script uit dit artikel kan aanvullend worden gebruikt als bron van objectief bewijsmateriaal over de technische inrichting van de Azure-tenant, bijvoorbeeld om te onderbouwen dat er daadwerkelijk sleutelrotatiebeleid is geïmplementeerd en dat deze correct functioneert.

Remediatie van niet-compliant assets en gefaalde rotaties

Gebruik PowerShell-script key-rotation-policies.ps1 (functie Invoke-Remediation) – Identificeert en herstelt niet-compliant assets en gefaalde rotaties.

Wanneer uit audits, monitoring of incidenten blijkt dat assets niet-compliant zijn met rotatie-intervallen of dat rotaties zijn gefaald, is een gestructureerd remediatieproces noodzakelijk om het beveiligingsniveau snel en gecontroleerd te verhogen. De eerste stap in dit proces is het uitvoeren van een gap-analyse ten opzichte van het gewenste sleutelrotatiebeleid: welke assets zijn compliant, welke assets zijn niet-compliant, welke rotaties zijn succesvol voltooid, en welke rotaties zijn gefaald? Deze gap-analyse wordt idealiter uitgevoerd door een multidisciplinair team bestaande uit CISO, security engineers, operations engineers en compliance officers. Het resultaat is een overzicht van concrete tekortkomingen per asset, geprioriteerd op basis van risico en compliance-impact. Vervolgens wordt per tekortkoming een gerichte remediatiestrategie bepaald. Zijn assets niet-compliant omdat rotaties niet zijn uitgevoerd, dan is de remediatie het alsnog uitvoeren van rotaties, het configureren van geautomatiseerde rotatieprocessen, en het monitoren van compliance-status. Zijn rotaties gefaald omdat geautomatiseerde processen niet correct zijn geconfigureerd, dan ligt de nadruk op het herstellen van rotatieprocessen, het testen van rotatieprocedures, en het verbeteren van monitoring en alerting. In situaties waarin meerdere assets niet-compliant zijn – wat zeker bij versneld gecreëerde Azure-omgevingen vaak voorkomt – moet een gefaseerde aanpak worden gevolgd waarbij eerst kritieke assets worden geroteerd, gevolgd door minder kritieke assets. Een belangrijk remediatiepad betreft het herstellen van gefaalde rotaties voor customer-managed keys. Wanneer rotaties falen voor customer-managed keys voor Azure Storage of Azure SQL, kunnen services niet meer toegang krijgen tot encrypted data, wat kan leiden tot service-uitval en dataverlies. Remediatie betekent in dit geval het herstellen van rotatieprocessen, het testen van rotatieprocedures in een testomgeving, en het implementeren van fallback-mechanismen voor het geval rotaties falen. Daarnaast moeten procedures worden opgesteld voor het reageren op gefaalde rotaties, inclusief escalatiepaden, communicatieplannen en recovery-procedures. Technisch gezien kan remediatie ook bestaan uit het herstructureren van cryptografische assets om rotatieprocessen beter te kunnen afdwingen. Denk aan het centraliseren van key management via Azure Key Vault, het implementeren van Azure Policy om rotatie-intervallen consistent af te dwingen, of het migreren van verouderde cryptografische algoritmes naar moderne algoritmes. Deze stappen moeten altijd worden uitgevoerd op basis van een gedetailleerd migratieplan, inclusief impactanalyse, fallbackscenario's en communicatie met betrokken teams. Sleutelrotatie betekent in dit verband dat herstructurering niet alleen wordt bekeken vanuit technische optimalisatie, maar vooral vanuit de vraag: vergroot dit de beveiliging en compliance van cryptografische assets? Tot slot moet elke remediatie-inspanning worden afgesloten met een expliciete evaluatie en bijstelling van het sleutelrotatiebeleid. De lessen uit incidenten en audits – bijvoorbeeld gefaalde rotaties die hebben geleid tot service-uitval of niet-compliant assets die hebben geleid tot compliance-risico's – moeten structureel worden verwerkt in het beleid, configuraties en procedures. Het is raadzaam om na afronding van een remediatieprogramma een integrale security assessment te laten uitvoeren door een interne auditdienst of een onafhankelijke derde, zodat kan worden vastgesteld of het nieuwe niveau van sleutelrotatie daadwerkelijk in lijn is met NIS2, BIO en de verwachtingen van het bestuur. De uitkomsten hiervan worden vastgelegd in beveiligingsdocumentatie en vormen het nieuwe vertrekpunt voor de reguliere cyclus van monitoring en verbetering.

Compliance & Frameworks

• BIO: 6.01.01, 6.02.01, 12.01.01 - Cryptografische beveiliging met sleutelrotatiebeleid voor key management en compliance
• ISO 27001:2022: A.10.1.1, A.10.1.2, A.12.2.1 - Cryptographic controls, key management en operations security met sleutelrotatiebeleid
• NIS2: Artikel - Passende technische en organisatorische maatregelen voor risicobeheersing en beveiliging op basis van risicoanalyse voor cryptografische assets

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Implementeer sleutelrotatiebeleid met vijf pijlers: inventarisatie en classificatie, rotatie-intervallen, geautomatiseerde rotatie, monitoring en alerting, en documentatie en audit trails. Essentieel voor NIS2 en BIO compliance. Implementatie: 200 uur.

• Implementatietijd: 200 uur
• FTE required: 0.8 FTE