💼 Management Samenvatting
Het configureren van toegangsbeleid voor Azure Key Vault vormt de fundamentele basis voor het beveiligen van encryptiesleutels, geheimen en certificaten binnen cloudomgevingen. Zonder adequaat toegangsbeleid kunnen onbevoegde gebruikers of systemen toegang krijgen tot kritieke beveiligingsmiddelen, wat kan leiden tot ernstige beveiligingsincidenten, datalekken en niet-naleving van compliance-vereisten.
Aanbeveling
IMPLEMENTEER KEY VAULT TOEGANGSBELEID
Risico zonder
Critical
Risk Score
9/10
Implementatie
6u (tech: 4u)
Van toepassing op:
✓ Azure Key Vault
Azure Key Vault fungeert als de centrale opslagplaats voor de meest gevoelige beveiligingsmiddelen van een organisatie, waaronder encryptiesleutels, wachtwoorden, API-sleutels en certificaten. Het onjuist configureren van toegangsbeleid kan catastrofale gevolgen hebben, omdat aanvallers die toegang krijgen tot een Key Vault in staat zijn om alle versleutelde gegevens te ontsleutelen, applicaties te compromitteren, en volledige controle over cloudinfrastructuur te verkrijgen. Voor Nederlandse overheidsorganisaties is het correct configureren van toegangsbeleid niet alleen een technische best practice, maar ook een wettelijke verplichting onder frameworks zoals de Baseline Informatiebeveiliging Overheid (BIO), de Algemene Verordening Gegevensbescherming (AVG), en de NIS2 richtlijn. Deze frameworks vereisen dat organisaties passende maatregelen treffen om toegang tot gevoelige gegevens te beperken tot alleen geautoriseerde personen en systemen, en dat zij kunnen aantonen dat deze maatregelen effectief zijn geïmplementeerd en worden gemonitord.
PowerShell Modules Vereist
Primary API: Azure API
Connection:
Required Modules: Az.Accounts, Az.KeyVault
Connection:
Connect-AzAccountRequired Modules: Az.Accounts, Az.KeyVault
Implementatie
Key Vault toegangsbeleid definieert wie toegang heeft tot welke beveiligingsmiddelen binnen een Key Vault en welke acties zij mogen uitvoeren. Azure Key Vault ondersteunt twee verschillende toegangsmodellen: het traditionele toegangsbeleid model en het op rollen gebaseerde toegangscontrole (RBAC) model. Het toegangsbeleid model biedt fijnmazige controle op het niveau van individuele objecten binnen een vault, waarbij beheerders specifieke machtigingen kunnen toewijzen voor sleutels, geheimen en certificaten afzonderlijk. Het RBAC-model maakt gebruik van Azure-rollen zoals Key Vault Secrets Officer, Key Vault Crypto Officer, en Key Vault Administrator om toegang te beheren op basis van rollen. Beide modellen hebben hun eigen voordelen: toegangsbeleid biedt meer granulariteit en is geschikt voor complexe scenario's waarbij verschillende teams verschillende niveaus van toegang nodig hebben, terwijl RBAC beter integreert met bestaande Azure-governance en compliance-tools. Ongeacht welk model wordt gebruikt, is het essentieel dat organisaties het principe van minimale privileges toepassen, waarbij gebruikers en systemen alleen de minimale toegang krijgen die zij nodig hebben om hun taken uit te voeren. Dit betekent dat beheerders zorgvuldig moeten evalueren welke machtigingen daadwerkelijk nodig zijn voor elke gebruiker of service principal, en dat zij regelmatig toegang moeten controleren en intrekken wanneer deze niet langer nodig is.
Vereisten
Voor het succesvol implementeren van Key Vault toegangsbeleid zijn verschillende technische, organisatorische en compliance-vereisten van essentieel belang. Deze vereisten vormen de basis voor een robuuste beveiligingsimplementatie die voldoet aan de hoogste standaarden voor toegangscontrole en gegevensbescherming binnen Azure omgevingen, en die organisaties in staat stelt om te voldoen aan relevante wet- en regelgeving zoals de BIO, AVG en NIS2 richtlijn.
De primaire technische vereiste betreft de aanwezigheid van een actief Azure Key Vault exemplaar dat is ingericht binnen het Azure-abonnement van de organisatie. Dit Key Vault moet operationeel zijn en toegankelijk via de Azure Portal, Azure PowerShell, Azure CLI, of programmatisch via de Azure REST API. Organisaties dienen te beschikken over de juiste Azure-abonnementen en licenties, waarbij het belangrijk is om te realiseren dat Key Vault beschikbaar is in verschillende service tiers met verschillende functionaliteiten en prijsmodellen. Voor productieomgevingen wordt aanbevolen om Premium tier te gebruiken vanwege de uitgebreide functionaliteiten zoals soft delete, purge protection, en ondersteuning voor hardware security modules (HSM).
Een kritieke vereiste betreft de definitie van gebruikers, groepen en service principals die toegang nodig hebben tot het Key Vault. Organisaties moeten vooraf een grondige inventarisatie uitvoeren van alle identiteiten die legitieme toegang vereisen, inclusief menselijke gebruikers zoals beheerders en ontwikkelaars, service principals voor applicaties en geautomatiseerde processen, en beheerde identiteiten voor Azure-services. Het is essentieel dat deze inventarisatie compleet en actueel is, omdat onvolledige informatie kan leiden tot het toekennen van onvoldoende toegang waardoor systemen niet functioneren, of het toekennen van te veel toegang waardoor het beveiligingsrisico toeneemt. Voor elke identiteit moet duidelijk zijn welke specifieke objecten binnen het Key Vault toegankelijk moeten zijn en welke acties moeten worden toegestaan, zoals lezen, schrijven, verwijderen, of beheren.
Daarnaast is het noodzakelijk dat organisaties beschikken over de juiste Azure-roltoewijzingen en machtigingen voor het configureren van toegangsbeleid. De implementatie van toegangsbeleid vereist minimaal de rol van Key Vault Administrator of een aangepaste rol met specifieke machtigingen voor het wijzigen van toegangsbeleid. Voor het RBAC-model zijn aanvullende rollen vereist zoals User Access Administrator voor het toewijzen van RBAC-rollen aan gebruikers en groepen. Beheerders moeten kunnen beschikken over voldoende rechten om wijzigingen door te voeren in de toegangsconfiguratie van het Key Vault, zonder dat dit conflicteert met bestaande beveiligingsbeleidsregels of governance-vereisten. Het is belangrijk om te realiseren dat het configureren van toegangsbeleid gevoelige bevoegdheden vereist, en dat deze taken alleen moeten worden uitgevoerd door vertrouwde beheerders die zijn getraind in beveiligingsbest practices.
Een belangrijke organisatorische vereiste betreft de coördinatie met verschillende afdelingen binnen de organisatie. IT-beheerders moeten samenwerken met security officers om beveiligingsvereisten te valideren en het principe van minimale privileges te waarborgen, met applicatie-eigenaren om te begrijpen welke systemen toegang tot het Key Vault nodig hebben en welke specifieke objecten zij moeten kunnen gebruiken, en met compliance officers om te verzekeren dat de configuratie voldoet aan relevante wet- en regelgeving. Deze coördinatie voorkomt dat kritieke systemen onbedoeld worden geblokkeerd en zorgt voor een soepele implementatie zonder verstoring van bedrijfsprocessen, terwijl tegelijkertijd wordt gewaarborgd dat beveiligings- en compliance-vereisten worden nageleefd.
Voor organisaties die moeten voldoen aan specifieke compliance-frameworks zijn aanvullende vereisten van toepassing. De Baseline Informatiebeveiliging Overheid (BIO) vereist bijvoorbeeld dat organisaties kunnen aantonen dat toegang tot gevoelige systemen is beperkt tot geautoriseerde personen en dat er regelmatige controles worden uitgevoerd. De AVG vereist dat organisaties passende technische en organisatorische maatregelen treffen om persoonsgegevens te beveiligen, wat onder andere betekent dat toegang tot encryptiesleutels die worden gebruikt voor het versleutelen van persoonsgegevens moet worden beperkt en gemonitord. De NIS2 richtlijn stelt eisen aan essentiële en belangrijke entiteiten met betrekking tot toegangscontrole en beveiligingsmonitoring. Organisaties moeten daarom beschikken over processen en documentatie die aantonen dat toegangsbeleid correct is geconfigureerd, dat regelmatige reviews worden uitgevoerd, en dat ongeautoriseerde toegang wordt gedetecteerd en aangepakt.
Tot slot is documentatie een essentiële vereiste. Organisaties moeten beschikken over of ontwikkelen van duidelijke documentatie die de gekozen toegangsconfiguratie, de rationale achter deze keuzes, de toegewezen gebruikers en service principals, en de procedures voor toekomstige wijzigingen beschrijft. Deze documentatie dient als referentie voor audits, compliance-controles, en toekomstig onderhoud van de toegangsconfiguratie. Het is aanbevolen om deze documentatie te onderhouden in een versiebeheersysteem en om wijzigingen te loggen voor audit-doeleinden.
Implementatie
De implementatie van Key Vault toegangsbeleid vereist een gestructureerde aanpak die begint met het kiezen van het juiste toegangsmodel, gevolgd door het configureren van toegangsrechten en het valideren van de configuratie. Organisaties moeten zorgvuldig overwegen welk model het beste past bij hun behoeften: het traditionele toegangsbeleid model biedt fijnmazige controle maar vereist meer beheer, terwijl het RBAC-model beter integreert met bestaande Azure-governance maar minder granulariteit biedt. In veel gevallen kiezen organisaties ervoor om het RBAC-model te gebruiken voor nieuwe implementaties vanwege de betere integratie met Azure Policy, Azure Blueprints, en andere governance-tools, terwijl bestaande Key Vaults die gebruik maken van toegangsbeleid geleidelijk worden gemigreerd naar RBAC.
De eerste stap in het implementatieproces betreft het uitvoeren van een grondige inventarisatie van alle gebruikers, groepen, service principals en beheerde identiteiten die toegang nodig hebben tot het Key Vault. Deze inventarisatie moet voor elke identiteit specificeren welke objecten binnen het Key Vault toegankelijk moeten zijn, welke acties moeten worden toegestaan, en wat de business justification is voor deze toegang. Het is belangrijk om tijdens deze inventarisatie het principe van minimale privileges toe te passen, waarbij alleen de minimale toegang wordt verleend die nodig is voor het uitvoeren van specifieke taken. Deze inventarisatie vormt de basis voor het configureren van toegangsbeleid en moet worden gedocumenteerd voor toekomstige referentie en compliance-doeleinden.
Voor het RBAC-model kunnen beheerders toegang configureren via de Azure Portal door naar het Key Vault te navigeren, te klikken op Access Control (IAM), en vervolgens rollen toe te wijzen aan gebruikers, groepen of service principals. Azure biedt verschillende ingebouwde rollen voor Key Vault, waaronder Key Vault Secrets Officer voor het beheren van geheimen, Key Vault Crypto Officer voor het beheren van sleutels, Key Vault Certificates Officer voor het beheren van certificaten, en Key Vault Administrator voor volledige beheertoegang. Beheerders kunnen ook aangepaste rollen maken wanneer de ingebouwde rollen niet voldoen aan specifieke vereisten. Het is aanbevolen om rollen toe te wijzen aan Azure AD-groepen in plaats van individuele gebruikers, omdat dit het beheer vereenvoudigt en ervoor zorgt dat wanneer gebruikers van groep veranderen, hun toegang automatisch wordt bijgewerkt.
Voor het traditionele toegangsbeleid model kunnen beheerders toegang configureren via de Azure Portal door naar het Key Vault te navigeren, te klikken op Access policies, en vervolgens voor elke gebruiker, groep of service principal specifieke machtigingen te configureren voor sleutels, geheimen en certificaten. Deze machtigingen omvatten acties zoals Get, List, Set, Delete, Backup, Restore, en Recover. Het is belangrijk om te realiseren dat wanneer een Key Vault is geconfigureerd voor RBAC, het traditionele toegangsbeleid model niet meer kan worden gebruikt, en vice versa. Organisaties moeten daarom vooraf beslissen welk model zij willen gebruiken en consistent blijven in hun keuze.
Na het configureren van toegangsbeleid moeten uitgebreide tests worden uitgevoerd om te verifiëren dat alle geautoriseerde gebruikers en systemen de verwachte toegang hebben en dat niet-geautoriseerde toegang daadwerkelijk wordt geblokkeerd. Dit omvat het testen van toegang vanaf verschillende geautoriseerde identiteiten, het verifiëren dat applicaties die afhankelijk zijn van het Key Vault nog steeds correct functioneren, en het testen dat toegang vanaf niet-geautoriseerde identiteiten inderdaad wordt geblokkeerd. Eventuele problemen die tijdens deze tests worden geïdentificeerd, moeten onmiddellijk worden opgelost door de toegangsconfiguratie aan te passen. Het is aanbevolen om deze tests te documenteren en regelmatig te herhalen, vooral na wijzigingen in de toegangsconfiguratie.
Voor organisaties die moeten voldoen aan compliance-vereisten is het belangrijk om toegangsbeleid te integreren met bestaande governance- en monitoring-tools. Azure Policy kan worden gebruikt om te controleren of Key Vaults correct zijn geconfigureerd met toegangsbeleid, en om te voorkomen dat nieuwe Key Vaults worden gemaakt zonder de juiste configuratie. Azure Monitor en Azure Sentinel kunnen worden gebruikt om toegangspogingen te monitoren en waarschuwingen te genereren voor verdachte activiteiten. Deze integratie zorgt ervoor dat organisaties proactief kunnen reageren op beveiligingsincidenten en kunnen aantonen aan auditors dat zij passende maatregelen hebben genomen om toegang te beveiligen.
Tot slot is documentatie een essentieel onderdeel van het implementatieproces. Alle genomen stappen, geconfigureerde toegangsrechten, en eventuele problemen die zijn opgetreden moeten worden gedocumenteerd voor toekomstige referentie, compliance-audits, en om te helpen bij het oplossen van vergelijkbare problemen in de toekomst. Deze documentatie dient ook als basis voor het opstellen van procedures voor toekomstige wijzigingen aan de toegangsconfiguratie en voor het trainen van andere beheerders in het beheer van Key Vault toegangsbeleid.
Compliance en Auditing
De implementatie van Key Vault toegangsbeleid speelt een cruciale rol bij het voldoen aan verschillende nationale en internationale compliance-standaarden die van toepassing zijn op Nederlandse overheidsorganisaties en bedrijven die met gevoelige gegevens werken. Deze compliance-vereisten stellen specifieke eisen aan toegangscontrole, gegevensbescherming, en de beveiliging van kritieke infrastructuren zoals key management systemen. Het niet voldoen aan deze vereisten kan leiden tot ernstige gevolgen, waaronder boetes, reputatieschade, en het verlies van certificeringen.
De CIS Microsoft Azure Foundations Benchmark versie 8.5 specificeert expliciet dat Key Vault toegangsbeleid moet worden geconfigureerd om toegang te beperken tot alleen geautoriseerde gebruikers en systemen. Deze controle is geclassificeerd als Level 1, wat betekent dat het verplicht is voor alle Azure-omgevingen. Organisaties die voldoen aan CIS-richtlijnen moeten kunnen aantonen dat hun Key Vault-exemplaren zijn beveiligd met adequaat toegangsbeleid, dat het principe van minimale privileges wordt toegepast, en dat er regelmatige controles worden uitgevoerd om te verifiëren dat de toegangsconfiguratie correct en actueel blijft. Het niet implementeren van deze controle resulteert in een failed audit finding, wat kan leiden tot compliance-problemen bij klanten of partners die CIS-compliance vereisen.
Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van bijzonder belang. BIO controle 12.01 richt zich specifiek op toegangscontrole en vereist dat organisaties maatregelen treffen om toegang tot informatiesystemen te beperken tot alleen geautoriseerde personen en systemen. De implementatie van Key Vault toegangsbeleid vormt een directe invulling van deze vereiste, omdat het toegang beperkt tot geautoriseerde identiteiten en daarmee een fundamentele beveiligingslaag biedt tegen ongeautoriseerde toegang. BIO vereist ook dat organisaties regelmatig toegang controleren en intrekken wanneer deze niet langer nodig is, wat betekent dat organisaties processen moeten implementeren voor het regelmatig reviewen van Key Vault toegangsbeleid en het verwijderen van onnodige toegangsrechten.
De ISO 27001:2022 standaard, specifiek controle A.9.1, behandelt toegangscontrole en vereist dat organisaties toegang tot informatiesystemen beheren en controleren. Deze controle benadrukt het belang van het principe van minimale privileges, regelmatige toegangsreviews, en het intrekken van toegang wanneer deze niet langer nodig is. Key Vault toegangsbeleid draagt direct bij aan het voldoen aan deze vereisten door toegang te beperken tot geautoriseerde identiteiten en door organisaties in staat te stellen om toegang te monitoren en te controleren. Het niet implementeren van adequate toegangscontrole kan leiden tot niet-naleving van ISO 27001, wat kan resulteren in het verlies van certificering en reputatieschade.
De Algemene Verordening Gegevensbescherming (AVG), Artikel 32, verplicht organisaties om passende technische en organisatorische maatregelen te treffen om persoonsgegevens te beveiligen. Key Vault toegangsbeleid vormt een belangrijke technische maatregel die bijdraagt aan de beveiliging van encryptiesleutels en andere gevoelige gegevens die in Key Vault worden opgeslagen. Het niet implementeren van adequate toegangscontrole kan leiden tot niet-naleving van de AVG, wat kan resulteren in boetes tot 4 procent van de wereldwijde jaaromzet of 20 miljoen euro, afhankelijk van wat hoger is. Daarnaast vereist de AVG dat organisaties kunnen aantonen dat zij passende maatregelen hebben genomen om gegevens te beveiligen, wat betekent dat organisaties moeten beschikken over documentatie en audit trails die aantonen dat toegangsbeleid correct is geconfigureerd en wordt gemonitord.
De NIS2 richtlijn, Artikel 10, stelt specifieke eisen aan essentiële en belangrijke entiteiten met betrekking tot toegangscontrole en beveiligingsmonitoring. Nederlandse organisaties die onder de reikwijdte van NIS2 vallen, moeten kunnen aantonen dat zij beschikken over adequate toegangscontrole mechanismen om ongeautoriseerde toegang te voorkomen en te detecteren. Key Vault toegangsbeleid draagt direct bij aan het voldoen aan deze vereisten door toegang te beperken tot geautoriseerde identiteiten en door organisaties in staat te stellen om toegangspogingen te monitoren en te loggen. Het niet implementeren van adequate toegangscontrole kan leiden tot niet-naleving van NIS2, wat kan resulteren in boetes en andere handhavingsmaatregelen door de Autoriteit Consument en Markt (ACM) of andere toezichthouders.
Voor auditing doeleinden moeten organisaties kunnen aantonen dat hun Key Vault toegangsbeleid correct is geconfigureerd en actief wordt gemonitord. Dit vereist gedocumenteerde procedures voor configuratiebeheer, regelmatige controles van toegangsrechten, en logboekregistratie van toegangspogingen en configuratiewijzigingen. Auditors zullen typisch verifiëren dat alleen geautoriseerde identiteiten toegang hebben, dat het principe van minimale privileges wordt toegepast, dat er regelmatige toegangsreviews worden uitgevoerd, en dat er mechanismen zijn om ongeautoriseerde toegang te detecteren en te voorkomen. Organisaties moeten daarom beschikken over uitgebreide documentatie die de toegangsconfiguratie beschrijft, de rationale achter toegangsbeslissingen uitlegt, en aantoont dat regelmatige reviews worden uitgevoerd.
Monitoring
Gebruik PowerShell-script key-vault-access-policies.ps1 (functie Invoke-Monitoring) – Controleert of Key Vault toegangsbeleid correct is geconfigureerd.
Effectieve monitoring van Key Vault toegangsbeleid vormt een cruciaal onderdeel van een robuuste beveiligingsstrategie. Door regelmatig de toegangsconfiguratie te controleren en te valideren, kunnen organisaties ervoor zorgen dat hun beveiligingsmaatregelen effectief blijven en voldoen aan compliance-vereisten. Monitoring omvat niet alleen het verifiëren van de huidige configuratie, maar ook het detecteren van ongeautoriseerde wijzigingen, het analyseren van toegangspogingen, het identificeren van potentiële beveiligingsrisico's, en het waarborgen dat het principe van minimale privileges wordt nageleefd.
Het monitoren van toegangsbeleid begint met het regelmatig controleren van de actieve configuratie. Beheerders moeten verifiëren dat alleen geautoriseerde gebruikers, groepen en service principals toegang hebben tot het Key Vault, dat toegangsrechten zijn beperkt tot de minimale benodigde machtigingen, en dat er geen onverwachte of ongeautoriseerde wijzigingen zijn aangebracht. Dit kan worden gedaan via de Azure Portal, Azure PowerShell, of de Azure CLI. Het is aanbevolen om deze controles wekelijks uit te voeren, of vaker in omgevingen met hoge beveiligingsvereisten of frequente configuratiewijzigingen. Voor organisaties die moeten voldoen aan compliance-vereisten zoals de BIO of ISO 27001, kunnen regelmatige toegangsreviews verplicht zijn, waarbij alle toegangsrechten worden geëvalueerd en onnodige toegang wordt ingetrokken.
Een belangrijk aspect van monitoring betreft het analyseren van toegangspogingen en geblokkeerde verzoeken. Azure Key Vault logboeken bevatten waardevolle informatie over wie probeert toegang te krijgen tot het Key Vault, welke objecten worden benaderd, welke acties worden uitgevoerd, en of deze pogingen succesvol waren of werden geblokkeerd door toegangsbeleid. Door deze logboeken regelmatig te analyseren, kunnen beheerders potentiële aanvallen detecteren, zoals brute force pogingen, ongeautoriseerde toegangspogingen vanaf verdachte identiteiten, of pogingen om toegang te krijgen tot objecten waarvoor geen autorisatie is verleend. Azure Monitor en Azure Sentinel kunnen worden gebruikt om geautomatiseerde waarschuwingen te configureren voor verdachte activiteiten, zoals herhaalde geblokkeerde toegangspogingen of toegangspogingen buiten normale bedrijfsuren.
Daarnaast is het essentieel om te monitoren op configuratiedrift, waarbij de werkelijke configuratie afwijkt van de gewenste of goedgekeurde configuratie. Dit kan gebeuren door handmatige wijzigingen, automatiseringsfouten, onjuiste implementaties, of kwaadaardige activiteiten. Door gebruik te maken van Azure Policy of infrastructure as code tools zoals ARM templates of Terraform, kunnen organisaties automatisch detecteren wanneer de toegangsconfiguratie afwijkt van de gedefinieerde standaard. Azure Policy kan ook worden gebruikt om te voorkomen dat nieuwe Key Vaults worden gemaakt zonder de juiste toegangsconfiguratie, of om automatisch toegangsbeleid toe te passen op nieuwe Key Vaults volgens gedefinieerde standaarden.
Monitoring moet ook aandacht besteden aan de naleving van het principe van minimale privileges. Beheerders moeten regelmatig evalueren of gebruikers en service principals nog steeds de minimale toegang hebben die zij nodig hebben om hun taken uit te voeren, of dat zij toegang hebben gekregen die niet langer nodig is. Dit kan worden gedaan door toegangsrechten te vergelijken met de werkelijke gebruikspatronen zoals vastgelegd in audit logs, en door regelmatige toegangsreviews uit te voeren waarbij applicatie-eigenaren en business owners worden gevraagd om te bevestigen dat toegangsrechten nog steeds nodig zijn. Azure AD Access Reviews kunnen worden gebruikt om geautomatiseerde toegangsreviews te configureren, waarbij gebruikers periodiek worden gevraagd om hun toegang te rechtvaardigen.
Voor geavanceerde monitoring kunnen organisaties gebruik maken van Azure Monitor en Azure Sentinel om geautomatiseerde waarschuwingen te configureren voor verdachte activiteiten, configuratiewijzigingen, of herhaalde geblokkeerde toegangspogingen. Deze tools bieden de mogelijkheid om complexe queries uit te voeren op loggegevens, trends te identificeren, en proactief te reageren op potentiële beveiligingsincidenten voordat deze escaleren tot ernstige problemen. Azure Sentinel kan ook worden gebruikt om gedragspatronen te analyseren en anomalieën te detecteren, zoals toegangspogingen vanaf ongebruikelijke locaties of op ongebruikelijke tijden, wat kan wijzen op gecompromitteerde accounts of insider threats.
Remediatie
Gebruik PowerShell-script key-vault-access-policies.ps1 (functie Invoke-Remediation) – Herstelt Key Vault toegangsbeleid naar de gewenste configuratie.
Wanneer een Key Vault niet is beveiligd met adequaat toegangsbeleid, vormt dit een significant beveiligingsrisico dat onmiddellijke remediatie vereist. Het herstellen van deze situatie omvat het implementeren van toegangsbeleid dat toegang beperkt tot alleen geautoriseerde identiteiten, het toepassen van het principe van minimale privileges, het valideren van de configuratie, en het verifiëren dat alle legitieme gebruikers en systemen nog steeds toegang hebben. Een gestructureerde aanpak voor remediatie voorkomt dat bedrijfskritieke processen worden verstoord en zorgt voor een soepele overgang naar een beveiligde configuratie.
De eerste stap in het remediatieproces betreft het uitvoeren van een grondige inventarisatie van alle gebruikers, groepen, service principals en beheerde identiteiten die toegang nodig hebben tot het Key Vault. Dit omvat het identificeren van alle identiteiten die legitieme toegang vereisen, het bepalen van welke specifieke objecten binnen het Key Vault toegankelijk moeten zijn voor elke identiteit, en het vaststellen van welke acties moeten worden toegestaan. Het is cruciaal dat deze inventarisatie compleet is, omdat onvolledige informatie kan leiden tot het blokkeren van legitieme toegang en daarmee verstoring van bedrijfsprocessen. Tijdens deze inventarisatie moeten beheerders ook evalueren of bestaande toegangsrechten nog steeds nodig zijn, en of het principe van minimale privileges wordt nageleefd.
Na het voltooien van de inventarisatie kunnen beheerders de toegangsconfiguratie implementeren via verschillende methoden. Voor het RBAC-model kunnen beheerders rollen toewijzen via de Azure Portal door naar het Key Vault te navigeren, te klikken op Access Control (IAM), en vervolgens de juiste rollen toe te wijzen aan gebruikers, groepen of service principals. Alternatief kunnen beheerders gebruik maken van Azure PowerShell of Azure CLI voor geautomatiseerde implementatie, wat vooral nuttig is wanneer meerdere Key Vaults moeten worden geconfigureerd of wanneer de configuratie moet worden geïntegreerd in bestaande deployment-pipelines. Voor het traditionele toegangsbeleid model kunnen beheerders toegang configureren via de Azure Portal door naar Access policies te navigeren en voor elke identiteit specifieke machtigingen te configureren.
Tijdens de implementatie is het belangrijk om te beginnen met een conservatieve configuratie die alleen de meest kritieke identiteiten en minimale benodigde machtigingen omvat. Dit minimaliseert het risico op het blokkeren van legitieme toegang en maakt het mogelijk om geleidelijk aanvullende toegangsrechten toe te voegen na verificatie dat alle systemen correct functioneren. Beheerders moeten ook overwegen om tijdelijk logging en monitoring te verhogen om te identificeren welke identiteiten mogelijk zijn overgeslagen in de inventarisatie, en om te detecteren of er onverwachte toegangspogingen plaatsvinden die kunnen wijzen op gecompromitteerde accounts of kwaadaardige activiteiten.
Na de implementatie van de toegangsconfiguratie moeten uitgebreide tests worden uitgevoerd om te verifiëren dat alle geautoriseerde identiteiten de verwachte toegang hebben en dat niet-geautoriseerde toegang daadwerkelijk wordt geblokkeerd. Dit omvat het testen van toegang vanaf verschillende geautoriseerde identiteiten, het verifiëren dat applicaties die afhankelijk zijn van het Key Vault nog steeds correct functioneren, en het testen dat toegang vanaf niet-geautoriseerde identiteiten inderdaad wordt geblokkeerd. Eventuele problemen die tijdens deze tests worden geïdentificeerd, moeten onmiddellijk worden opgelost door de toegangsconfiguratie aan te passen. Het is aanbevolen om deze tests te documenteren en de resultaten te bewaren voor toekomstige referentie en compliance-doeleinden.
Voor organisaties die moeten voldoen aan compliance-vereisten is het belangrijk om na remediatie te verifiëren dat de nieuwe configuratie voldoet aan relevante standaarden zoals CIS, BIO, ISO 27001, AVG en NIS2. Dit kan worden gedaan door gebruik te maken van Azure Policy om te controleren of Key Vaults correct zijn geconfigureerd, of door regelmatige audits uit te voeren waarbij de toegangsconfiguratie wordt geëvalueerd tegen compliance-vereisten. Het is ook belangrijk om te documenteren welke wijzigingen zijn doorgevoerd, waarom deze wijzigingen nodig waren, en hoe de nieuwe configuratie voldoet aan compliance-vereisten.
Tot slot is documentatie een essentieel onderdeel van het remediatieproces. Alle genomen stappen, geconfigureerde toegangsrechten, en eventuele problemen die zijn opgetreden moeten worden gedocumenteerd voor toekomstige referentie, compliance-audits, en om te helpen bij het oplossen van vergelijkbare problemen in de toekomst. Deze documentatie dient ook als basis voor het opstellen van procedures voor toekomstige wijzigingen aan de toegangsconfiguratie en voor het trainen van andere beheerders in het beheer van Key Vault toegangsbeleid.
Compliance & Frameworks
- CIS M365: Control 8.5 (L1) - Key Vault toegangsbeleid
- BIO: 12.01 - Toegangscontrole
- ISO 27001:2022: A.9.1 - Toegangscontrole
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).
PowerShell
<#
================================================================================
AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud
================================================================================
.SYNOPSIS
Key Vault Access Policies Configured
.DESCRIPTION
CIS Azure Foundations Benchmark - Control 8.5
Controleert of Key Vault toegangsbeleid correct is geconfigureerd.
Verifieert dat toegang is beperkt tot geautoriseerde gebruikers en systemen.
.NOTES
Filename: key-vault-access-policies.ps1
Author: Nederlandse Baseline voor Veilige Cloud
Version: 1.0
CIS Control: 8.5
#>
#Requires -Version 5.1
#Requires -Modules Az.Accounts, Az.KeyVault
[CmdletBinding()]
param(
[Parameter(Mandatory = $false)]
[switch]$Monitoring,
[Parameter(Mandatory = $false)]
[switch]$Remediation,
[Parameter(Mandatory = $false)]
[switch]$Revert,
[Parameter(Mandatory = $false)]
[switch]$WhatIf
)
$ErrorActionPreference = 'Stop'
$PolicyName = "Key Vault Access Policies Configured"
function Connect-RequiredServices {
if (-not (Get-AzContext)) {
Write-Host "Connecting to Azure..." -ForegroundColor Gray
Connect-AzAccount | Out-Null
}
}
function Test-Compliance {
<#
.SYNOPSIS
Controleert of Key Vaults correct zijn geconfigureerd met toegangsbeleid
#>
try {
$vaults = Get-AzKeyVault -ErrorAction SilentlyContinue
if ($null -eq $vaults -or $vaults.Count -eq 0) {
return @{
TotalVaults = 0
WithAccessPolicies = 0
WithoutAccessPolicies = 0
IsCompliant = $true
Details = @()
}
}
$result = @{
TotalVaults = $vaults.Count
WithAccessPolicies = 0
WithoutAccessPolicies = 0
IsCompliant = $true
Details = @()
}
foreach ($vault in $vaults) {
try {
$vaultDetail = Get-AzKeyVault -VaultName $vault.VaultName -ResourceGroupName $vault.ResourceGroupName -ErrorAction Stop
# Controleer of RBAC is ingeschakeld of dat toegangsbeleid is geconfigureerd
$hasAccessControl = $false
$accessMethod = "Unknown"
# Voor RBAC: controleer of er rollen zijn toegewezen
try {
$roleAssignments = Get-AzRoleAssignment -Scope $vault.ResourceId -ErrorAction SilentlyContinue
if ($null -ne $roleAssignments -and $roleAssignments.Count -gt 0) {
$hasAccessControl = $true
$accessMethod = "RBAC"
}
}
catch {
# RBAC check gefaald, mogelijk geen rechten
}
# Voor toegangsbeleid: controleer of er access policies zijn
if (-not $hasAccessControl) {
try {
$accessPolicies = Get-AzKeyVaultAccessPolicy -VaultName $vault.VaultName -ResourceGroupName $vault.ResourceGroupName -ErrorAction SilentlyContinue
if ($null -ne $accessPolicies -and $accessPolicies.Count -gt 0) {
$hasAccessControl = $true
$accessMethod = "Access Policy"
}
}
catch {
# Access policy check gefaald
}
}
if ($hasAccessControl) {
$result.WithAccessPolicies++
$result.Details += @{
VaultName = $vault.VaultName
ResourceGroup = $vault.ResourceGroupName
Status = "Compliant"
AccessMethod = $accessMethod
}
}
else {
$result.WithoutAccessPolicies++
$result.IsCompliant = $false
$result.Details += @{
VaultName = $vault.VaultName
ResourceGroup = $vault.ResourceGroupName
Status = "Non-Compliant"
AccessMethod = "None"
}
}
}
catch {
Write-Warning "Could not check vault $($vault.VaultName): $_"
$result.WithoutAccessPolicies++
$result.IsCompliant = $false
}
}
return $result
}
catch {
Write-Error "Error checking compliance: $_"
throw
}
}
function Invoke-Monitoring {
<#
.SYNOPSIS
Controleert de huidige configuratie status van Key Vault toegangsbeleid
#>
try {
Connect-RequiredServices
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "$PolicyName" -ForegroundColor Cyan
Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan
Write-Host "========================================`n" -ForegroundColor Cyan
$result = Test-Compliance
Write-Host "Overzicht:" -ForegroundColor White
Write-Host " Totaal Key Vaults: $($result.TotalVaults)" -ForegroundColor White
if ($result.TotalVaults -eq 0) {
Write-Host " [INFO] Geen Key Vaults gevonden in dit abonnement" -ForegroundColor Yellow
Write-Host "`n[OK] COMPLIANT (geen Key Vaults om te controleren)" -ForegroundColor Green
exit 0
}
Write-Host " Met toegangsbeleid: $($result.WithAccessPolicies)" -ForegroundColor $(if ($result.WithAccessPolicies -eq $result.TotalVaults) { 'Green' } else { 'Yellow' })
Write-Host " Zonder toegangsbeleid: $($result.WithoutAccessPolicies)" -ForegroundColor $(if ($result.WithoutAccessPolicies -eq 0) { 'Green' } else { 'Red' })
if ($result.Details.Count -gt 0) {
Write-Host "`nDetails per Key Vault:" -ForegroundColor White
foreach ($detail in $result.Details) {
$statusColor = if ($detail.Status -eq "Compliant") { "Green" } else { "Red" }
Write-Host " [$($detail.Status)] $($detail.VaultName) ($($detail.ResourceGroup))" -ForegroundColor $statusColor
Write-Host " Toegangsmethode: $($detail.AccessMethod)" -ForegroundColor Gray
}
}
if ($result.IsCompliant) {
Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green
Write-Host "Alle Key Vaults hebben toegangsbeleid geconfigureerd" -ForegroundColor Cyan
exit 0
}
else {
Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red
Write-Host "Sommige Key Vaults hebben geen toegangsbeleid geconfigureerd!" -ForegroundColor Red
Write-Host "Gebruik -Remediation om dit te herstellen" -ForegroundColor Yellow
exit 1
}
}
catch {
Write-Host "`n[FAIL] ERROR: $_" -ForegroundColor Red
Write-Host "Error Details: $($_.Exception.Message)" -ForegroundColor Red
exit 2
}
}
function Invoke-Remediation {
<#
.SYNOPSIS
Herstelt Key Vault toegangsbeleid naar de gewenste configuratie
.DESCRIPTION
Deze functie controleert Key Vaults zonder toegangsbeleid en waarschuwt beheerders.
Toegangsbeleid moet handmatig worden geconfigureerd omdat dit afhankelijk is van
specifieke organisatorische vereisten.
#>
try {
Connect-RequiredServices
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "Key Vault Access Policies Remediation" -ForegroundColor Cyan
Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan
Write-Host "========================================`n" -ForegroundColor Cyan
$result = Test-Compliance
if ($result.IsCompliant) {
Write-Host "[OK] Alle Key Vaults hebben al toegangsbeleid geconfigureerd" -ForegroundColor Green
Write-Host "`n[OK] Geen remediatie nodig" -ForegroundColor Green
exit 0
}
Write-Host "[WAARSCHUWING] Toegangsbeleid moet handmatig worden geconfigureerd" -ForegroundColor Yellow
Write-Host "De volgende Key Vaults hebben geen toegangsbeleid:" -ForegroundColor Yellow
Write-Host ""
$nonCompliantVaults = $result.Details | Where-Object { $_.Status -eq "Non-Compliant" }
foreach ($vault in $nonCompliantVaults) {
Write-Host " - $($vault.VaultName) (Resource Group: $($vault.ResourceGroup))" -ForegroundColor Red
}
Write-Host "`nAanbevolen acties:" -ForegroundColor Cyan
Write-Host "1. Identificeer alle gebruikers, groepen en service principals die toegang nodig hebben" -ForegroundColor White
Write-Host "2. Bepaal welke objecten (keys, secrets, certificates) toegankelijk moeten zijn" -ForegroundColor White
Write-Host "3. Kies tussen RBAC of Access Policy model" -ForegroundColor White
Write-Host "4. Configureer toegangsbeleid via Azure Portal of PowerShell" -ForegroundColor White
Write-Host "5. Test dat alle legitieme toegang nog werkt" -ForegroundColor White
Write-Host "6. Documenteer de configuratie voor compliance-doeleinden" -ForegroundColor White
Write-Host "`nVoorbeeld PowerShell commando's:" -ForegroundColor Cyan
Write-Host "# RBAC model:" -ForegroundColor Gray
Write-Host "New-AzRoleAssignment -RoleDefinitionName 'Key Vault Secrets Officer' -ObjectId <object-id> -Scope <vault-resource-id>" -ForegroundColor Gray
Write-Host ""
Write-Host "# Access Policy model:" -ForegroundColor Gray
Write-Host "Set-AzKeyVaultAccessPolicy -VaultName <vault-name> -ObjectId <object-id> -PermissionsToSecrets Get,List" -ForegroundColor Gray
Write-Host "`n[INFO] Remediatie vereist handmatige configuratie" -ForegroundColor Yellow
Write-Host "Zie de documentatie voor gedetailleerde instructies" -ForegroundColor Yellow
exit 0
}
catch {
Write-Host "`n[FAIL] ERROR: $_" -ForegroundColor Red
Write-Host "Error Details: $($_.Exception.Message)" -ForegroundColor Red
exit 2
}
}
function Invoke-Revert {
<#
.SYNOPSIS
Verwijdert toegangsbeleid (NIET AANBEVOLEN!)
.DESCRIPTION
Deze functie verwijdert toegangsbeleid van Key Vaults.
WAARSCHUWING: Dit is een beveiligingsrisico en wordt niet aanbevolen!
#>
try {
Write-Host "`n[WAARSCHUWING] Het verwijderen van toegangsbeleid is een BEVEILIGINGSRISICO!" -ForegroundColor Red
Write-Host "Dit kan leiden tot ongeautoriseerde toegang tot encryptiesleutels en geheimen!`n" -ForegroundColor Red
if (-not $WhatIf) {
$confirm = Read-Host "Weet u zeker dat u door wilt gaan? (type 'JA' om te bevestigen)"
if ($confirm -ne "JA") {
Write-Host "Operatie geannuleerd" -ForegroundColor Yellow
exit 0
}
}
Connect-RequiredServices
Write-Host "`n[INFO] Revert functionaliteit is beperkt vanwege beveiligingsrisico's" -ForegroundColor Yellow
Write-Host "Toegangsbeleid moet handmatig worden verwijderd via Azure Portal of PowerShell" -ForegroundColor Yellow
Write-Host "Gebruik: Remove-AzKeyVaultAccessPolicy of Remove-AzRoleAssignment" -ForegroundColor Gray
exit 0
}
catch {
Write-Host "ERROR: $_" -ForegroundColor Red
exit 2
}
}
# ================================================================================
# Main execution
# ================================================================================
try {
if ($Revert) {
Invoke-Revert
}
elseif ($Monitoring) {
Invoke-Monitoring
}
elseif ($Remediation) {
Invoke-Remediation
}
else {
Write-Host "Usage:" -ForegroundColor Yellow
Write-Host " -Monitoring Controleer of toegangsbeleid is geconfigureerd" -ForegroundColor Gray
Write-Host " -Remediation Toon instructies voor het configureren van toegangsbeleid" -ForegroundColor Gray
Write-Host " -Revert Verwijder toegangsbeleid (NIET AANBEVOLEN!)" -ForegroundColor Red
Write-Host ""
Write-Host "Voorbeelden:" -ForegroundColor Yellow
Write-Host " .\key-vault-access-policies.ps1 -Monitoring" -ForegroundColor Gray
Write-Host " .\key-vault-access-policies.ps1 -Remediation" -ForegroundColor Gray
}
}
catch {
Write-Host "`n[FAIL] FATAL ERROR: $_" -ForegroundColor Red
Write-Host "Stack Trace: $($_.ScriptStackTrace)" -ForegroundColor Red
exit 2
}
finally {
Write-Host "`n========================================`n" -ForegroundColor Cyan
}
Risico zonder implementatie
Risico zonder implementatie
Critical: Kritiek - Zonder adequaat toegangsbeleid kunnen onbevoegde gebruikers of systemen toegang krijgen tot encryptiesleutels, geheimen en certificaten, wat kan leiden tot volledige compromittering van cloudinfrastructuur, datalekken en niet-naleving van AVG, BIO en NIS2. Het risico is kritiek bij onbeperkte toegang.
Management Samenvatting
Key Vault Toegangsbeleid: Beperk toegang tot alleen geautoriseerde gebruikers, groepen en service principals. Pas het principe van minimale privileges toe. Gebruik RBAC of toegangsbeleid model. Verplicht voor CIS 8.5 L1, BIO 12.01, AVG Artikel 32. Implementatie: 4-6 uur (inventarisatie + configuratie + testen). Kritiek voor beveiliging.
- Implementatietijd: 6 uur
- FTE required: 0.05 FTE