Key Vault RBAC Ingeschakeld

Het inschakelen van RBAC voor Azure Key Vault is essentieel voor het handhaven van een veilige cloudomgeving en voorkomt bekende aanvalsvectoren door het afdwingen van moderne beveiligingsbest practices. De traditionele Access Policies methode wordt door Microsoft beschouwd als legacy technologie en biedt minder flexibiliteit en granulair beheer dan het RBAC-model. Organisaties die nog gebruik maken van Access Policies lopen het risico op beveiligingslekken en voldoen niet aan moderne compliance-eisen zoals BIO en ISO 27001.

Implementatie

Deze regel past de benodigde beveiligingsinstellingen toe via Azure Policy om ervoor te zorgen dat alle Key Vault instanties gebruik maken van het RBAC-autorisatiemodel in plaats van de verouderde Access Policies. Dit beschermt systemen volgens actuele beveiligingsframeworks zoals CIS Benchmarks, BIO en ISO 27001 en zorgt voor consistente toegangscontrole binnen de gehele Azure-omgeving.

Vereisten

Voor het implementeren van RBAC voor Azure Key Vault zijn verschillende technische en organisatorische vereisten van toepassing. Deze vereisten zorgen ervoor dat de migratie naar RBAC soepel verloopt en dat de beveiliging van gevoelige gegevens zoals certificaten, sleutels en geheimen niet in gevaar komt tijdens het transitieproces. Het is van cruciaal belang dat organisaties deze vereisten grondig begrijpen en voorbereiden voordat zij beginnen met de implementatie, omdat een onzorgvuldige migratie kan leiden tot toegangsproblemen voor kritieke systemen en applicaties. Technisch gezien moet de organisatie beschikken over een actieve Azure Key Vault instantie. Dit kan zowel een standaard Key Vault zijn als een Premium Key Vault, afhankelijk van de specifieke behoeften van de organisatie. De Key Vault moet zich bevinden in een Azure-abonnement waar de organisatie voldoende rechten heeft om wijzigingen door te voeren. Daarnaast is het essentieel dat de Azure-omgeving gebruik maakt van Azure Active Directory, nu bekend als Microsoft Entra ID, voor identiteitsbeheer. RBAC is volledig afhankelijk van Entra ID voor het toekennen en beheren van rollen, wat betekent dat organisaties zonder een goed geconfigureerde Entra ID-omgeving niet kunnen profiteren van de voordelen van RBAC. De Entra ID-omgeving moet beschikken over een gezonde directory structuur met correct geconfigureerde gebruikers, groepen en service principals. Vanuit organisatorisch perspectief moet de organisatie beschikken over een duidelijk gedefinieerd rollenmodel. Dit betekent dat er vooraf moet worden bepaald welke gebruikers, service principals of beheerde identiteiten toegang nodig hebben tot de Key Vault en welke specifieke acties zij mogen uitvoeren. Microsoft biedt verschillende ingebouwde RBAC-rollen voor Key Vault die organisaties kunnen gebruiken. De Key Vault Secrets Officer rol is bedoeld voor gebruikers die geheimen moeten beheren, zoals wachtwoorden, verbindingsstrings en API-sleutels. De Key Vault Crypto Officer rol is specifiek voor het beheren van cryptografische sleutels die worden gebruikt voor versleuteling en digitale handtekeningen. De Key Vault Administrator rol biedt volledige beheerrechten en is bedoeld voor beheerders die de Key Vault configureren en onderhouden. Organisaties moeten deze rollen evalueren en bepalen of deze voldoen aan hun behoeften of dat er aangepaste rollen moeten worden gecreëerd om aan specifieke organisatorische vereisten te voldoen. Bovendien vereist de implementatie van RBAC dat de organisatie beschikt over de juiste Azure-abonnement rechten. Ten minste één gebruiker of service principal moet beschikken over de rol van Key Vault Administrator of een hogere rol zoals Subscription Administrator om de RBAC-configuratie te kunnen activeren. Deze rechten zijn nodig omdat het inschakelen van RBAC een wijziging is aan de fundamentele configuratie van de Key Vault, wat alleen kan worden uitgevoerd door gebruikers met voldoende bevoegdheden. Het is belangrijk om te benadrukken dat tijdens de migratie van Access Policies naar RBAC er een zorgvuldige planning nodig is om te voorkomen dat bestaande applicaties en services hun toegang verliezen. Organisaties moeten daarom een gedetailleerde inventarisatie maken van alle systemen en applicaties die momenteel gebruik maken van Key Vault toegang via Access Policies. Deze inventarisatie moet informatie bevatten over welke applicaties welke geheimen, sleutels of certificaten gebruiken, zodat organisaties kunnen verifiëren dat alle benodigde toegang wordt behouden na de migratie naar RBAC. Ten slotte is het raadzaam om vooraf te testen in een niet-productie omgeving. Dit stelt organisaties in staat om het RBAC-model te valideren, eventuele problemen te identificeren en het migratieproces te oefenen zonder risico voor productiesystemen. De testomgeving moet zo veel mogelijk lijken op de productieomgeving om realistische resultaten te verkrijgen. Dit betekent dat de testomgeving dezelfde Key Vault configuratie moet hebben, dezelfde rollen en toegangstoewijzingen, en indien mogelijk dezelfde applicaties die gebruik maken van de Key Vault. Door uitgebreid te testen kunnen organisaties vertrouwen opbouwen in het migratieproces en eventuele problemen identificeren voordat zij de migratie uitvoeren in de productieomgeving.

Monitoring

Gebruik PowerShell-script rbac-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van de RBAC-configuratie voor Azure Key Vault is een kritieke activiteit die ervoor zorgt dat alle Key Vault instanties binnen de organisatie gebruik maken van het moderne autorisatiemodel. Regelmatige controle voorkomt dat nieuwe Key Vaults worden aangemaakt met de verouderde Access Policies methode en helpt organisaties om te voldoen aan compliance-eisen en beveiligingsstandaarden. Monitoring vormt een essentieel onderdeel van een proactieve beveiligingsstrategie en stelt organisaties in staat om snel te reageren op configuratiewijzigingen die mogelijk de beveiligingspostuur van de organisatie beïnvloeden. Het monitoringproces begint met het identificeren van alle Key Vault instanties binnen de Azure-omgeving. Dit kan worden gedaan door gebruik te maken van Azure Resource Graph queries, een krachtige service die organisaties in staat stelt om complexe queries uit te voeren op alle resources binnen hun Azure-abonnementen. Resource Graph queries kunnen worden gebruikt om alle Key Vaults te vinden, ongeacht in welk abonnement of welke resourcegroep zij zich bevinden. Alternatief kunnen organisaties het PowerShell script uitvoeren dat specifiek is ontwikkeld voor deze controle. Het script controleert voor elke Key Vault instantie welk autorisatiemodel actief is door de eigenschappen van de Key Vault te onderzoeken. Wanneer een Key Vault gebruik maakt van Access Policies in plaats van RBAC, wordt dit gemarkeerd als een afwijking die aandacht vereist. Het script genereert een rapport dat duidelijk aangeeft welke Key Vaults nog gebruik maken van het verouderde model en welke reeds zijn gemigreerd naar RBAC. De controle van het autorisatiemodel kan worden uitgevoerd door te kijken naar de eigenschappen van de Key Vault. In Azure wordt het autorisatiemodel opgeslagen als een eigenschap van de Key Vault resource, specifiek de EnableRbacAuthorization eigenschap. Wanneer deze eigenschap is ingesteld op true, betekent dit dat de Key Vault gebruik maakt van RBAC. Wanneer deze eigenschap false is of niet is ingesteld, betekent dit dat de Key Vault nog gebruik maakt van Access Policies. Het script dat beschikbaar is voor deze controle gebruikt de Azure PowerShell module om programmatisch te bepalen of RBAC is ingeschakeld door deze eigenschap te lezen voor elke Key Vault in de omgeving. Dit proces kan worden geautomatiseerd door het script te integreren in een Azure Automation runbook, wat organisaties in staat stelt om regelmatig en geautomatiseerd controles uit te voeren zonder handmatige interventie. Alternatief kunnen organisaties het script opnemen in een CI/CD pipeline voor continue monitoring, wat ervoor zorgt dat elke wijziging aan de Azure-infrastructuur automatisch wordt gecontroleerd. Naast het controleren van het autorisatiemodel zelf, is het belangrijk om ook te monitoren welke rollen zijn toegewezen aan gebruikers en service principals. Dit helpt organisaties om te identificeren of er mogelijk overmatige rechten zijn verleend of dat er gebruikers zijn met toegang die niet langer nodig is. Het principe van least privilege vereist dat gebruikers alleen de minimale rechten krijgen die zij nodig hebben om hun werk uit te voeren. Door regelmatig te controleren welke rollen zijn toegewezen, kunnen organisaties identificeren wanneer gebruikers meer rechten hebben dan nodig is, wat een beveiligingsrisico vormt. Azure biedt verschillende ingebouwde rapportage mogelijkheden voor RBAC-toewijzingen, waaronder de Azure Portal interface en de Azure PowerShell cmdlets. Organisaties kunnen ook gebruik maken van Azure Policy om automatisch te controleren of RBAC-toewijzingen voldoen aan organisatorische richtlijnen. Azure Policy kan bijvoorbeeld worden geconfigureerd om te controleren of bepaalde rollen niet worden toegewezen aan gebruikers, of om te controleren of alle Key Vaults gebruik maken van specifieke rollen. Voor continue monitoring is het aanbevolen om deze controle wekelijks of maandelijks uit te voeren, afhankelijk van hoe dynamisch de Azure-omgeving is. Organisaties die regelmatig nieuwe Key Vaults aanmaken, bijvoorbeeld als onderdeel van een DevOps-proces of omdat zij regelmatig nieuwe applicaties implementeren, moeten vaker monitoren dan organisaties met een stabiele omgeving waar Key Vaults zelden worden aangemaakt of gewijzigd. Het is ook mogelijk om Azure Monitor alerts te configureren die automatisch een melding genereren wanneer een nieuwe Key Vault wordt aangemaakt zonder RBAC, hoewel dit vereist dat er een Azure Policy is geconfigureerd die dit detecteert. Deze alerts kunnen worden geconfigureerd om e-mailberichten te sturen naar beheerders of om te integreren met incident management systemen zoals ServiceNow of Jira. De resultaten van de monitoring moeten worden gedocumenteerd en gerapporteerd aan relevante stakeholders, waaronder security officers, compliance managers en IT-beheerders. Dit helpt om transparantie te waarborgen en zorgt ervoor dat eventuele afwijkingen snel worden geïdentificeerd en aangepakt. De rapporten moeten informatie bevatten over het totale aantal Key Vaults in de omgeving, hoeveel daarvan gebruik maken van RBAC, hoeveel nog gebruik maken van Access Policies, en welke specifieke Key Vaults aandacht vereisen. Bovendien kunnen deze rapporten worden gebruikt tijdens audits om aan te tonen dat de organisatie proactief werkt aan het handhaven van beveiligingsstandaarden. Auditors verwachten dat organisaties kunnen aantonen dat zij regelmatig controleren of hun systemen voldoen aan de vereiste configuraties, en gedetailleerde monitoringrapporten vormen een essentieel onderdeel van dit bewijs.

Compliance en Audit

Het inschakelen van RBAC voor Azure Key Vault draagt direct bij aan het voldoen aan verschillende belangrijke compliance- en beveiligingsstandaarden die relevant zijn voor Nederlandse overheidsorganisaties. Deze standaarden vereisen dat organisaties gebruik maken van moderne, granulair toegangsbeheer methoden en dat toegang tot gevoelige systemen en gegevens wordt beheerd volgens het principe van least privilege. Compliance is niet alleen een kwestie van het voldoen aan regelgeving, maar vormt ook een essentieel onderdeel van een effectieve beveiligingsstrategie die organisaties beschermt tegen zowel interne als externe bedreigingen. De Baseline Informatiebeveiliging Overheid (BIO) controle 09.01 richt zich specifiek op toegangscontrole en authenticatie. Deze controle vereist dat organisaties passende maatregelen treffen om toegang tot informatiesystemen te beheren en te controleren. De controle stelt dat organisaties moeten beschikken over een systeem voor toegangsbeheer dat ervoor zorgt dat alleen geautoriseerde personen toegang hebben tot informatiesystemen en dat deze toegang wordt gecontroleerd en geaudit. RBAC voor Key Vault voldoet aan deze eis door een gestructureerd en controleerbaar systeem te bieden voor het beheren van toegang tot gevoelige gegevens zoals certificaten, sleutels en geheimen. Het RBAC-model maakt het mogelijk om zeer specifieke rechten toe te kennen aan gebruikers en service principals, wat beter aansluit bij het least privilege principe dan de traditionele Access Policies methode. Bovendien biedt RBAC betere integratie met andere Azure-beveiligingsservices, wat organisaties in staat stelt om een holistische beveiligingsstrategie te implementeren die voldoet aan alle BIO-controles. De ISO 27001:2022 standaard, specifiek controle A.5.15, behandelt toegangscontrole en vereist dat organisaties toegang tot informatie en gerelateerde assets beheren volgens bedrijfs- en beveiligingsvereisten. Deze controle stelt dat organisaties moeten beschikken over een toegangsbeheerbeleid dat definieert wie toegang heeft tot welke informatie en onder welke omstandigheden. Het beleid moet regelmatig worden gecontroleerd en bijgewerkt om ervoor te zorgen dat het nog steeds relevant is en voldoet aan de huidige bedrijfsvereisten. RBAC voor Key Vault ondersteunt deze controle door een gestandaardiseerd en auditbaar systeem te bieden voor toegangsbeheer. Het RBAC-model integreert naadloos met Azure's ingebouwde audit logging mogelijkheden, waardoor organisaties een volledig overzicht hebben van wie toegang heeft tot welke Key Vault resources en welke acties zijn uitgevoerd. Deze audit logs kunnen worden gebruikt om te voldoen aan de ISO 27001-vereisten voor het monitoren en controleren van toegang tot informatiesystemen. Vanuit een auditperspectief biedt RBAC significante voordelen ten opzichte van Access Policies. Alle RBAC-toewijzingen worden automatisch gelogd in Azure Activity Logs, wat betekent dat auditors een compleet overzicht kunnen krijgen van alle wijzigingen in toegangsrechten. Deze logs bevatten gedetailleerde informatie over wie welke rol heeft toegewezen, wanneer deze toewijzing heeft plaatsgevonden, en welke gebruiker of service principal de toewijzing heeft uitgevoerd. Deze informatie is essentieel voor auditors die moeten verifiëren dat organisaties voldoen aan compliance-vereisten en dat toegang wordt beheerd volgens het principe van least privilege. De logs kunnen worden geëxporteerd naar Azure Log Analytics of externe SIEM-systemen voor langetermijnopslag en analyse, wat organisaties in staat stelt om historische toegangspatronen te analyseren en trends te identificeren die mogelijk wijzen op beveiligingsproblemen. Bovendien maakt RBAC het mogelijk om toegangstoewijzingen te beheren via Azure Policy, wat betekent dat organisaties automatisch kunnen controleren of alle Key Vaults voldoen aan de vereiste configuratie. Azure Policy kan worden geconfigureerd om automatisch te rapporteren over afwijkingen of om zelfs automatisch corrigerende maatregelen te nemen wanneer een Key Vault niet voldoet aan de vereiste configuratie. Voor Nederlandse overheidsorganisaties is het ook belangrijk om te voldoen aan de Algemene Verordening Gegevensbescherming (AVG). Hoewel Key Vault zelf geen persoonsgegevens opslaat, kunnen de certificaten, sleutels en geheimen die in Key Vault worden beheerd worden gebruikt voor het versleutelen of beveiligen van persoonsgegevens. Het gebruik van RBAC zorgt ervoor dat alleen geautoriseerde personen toegang hebben tot deze beveiligingsmiddelen, wat bijdraagt aan de algehele beveiliging van persoonsgegevens. Artikel 32 van de AVG vereist dat organisaties passende technische en organisatorische maatregelen treffen om persoonsgegevens te beveiligen, en het gebruik van RBAC voor het beheren van toegang tot beveiligingsmiddelen vormt een essentieel onderdeel van deze maatregelen. Bovendien vereist de AVG dat organisaties kunnen aantonen wie toegang heeft gehad tot persoonsgegevens, en de audit logs die RBAC genereert helpen organisaties om aan deze vereiste te voldoen. Tijdens audits moeten organisaties kunnen aantonen dat zij gebruik maken van moderne toegangsbeheer methoden en dat alle Key Vault instanties correct zijn geconfigureerd. Auditors verwachten dat organisaties kunnen aantonen dat zij regelmatig controleren of alle systemen voldoen aan de vereiste configuraties en dat afwijkingen worden geïdentificeerd en gecorrigeerd. Het hebben van een geautomatiseerd monitoringproces, zoals beschreven in de monitoring sectie, helpt organisaties om snel en accuraat te rapporteren over de compliance status. Auditors verwachten doorgaans dat organisaties kunnen aantonen dat zij proactief werken aan het handhaven van beveiligingsstandaarden en dat zij beschikken over processen voor het identificeren en oplossen van beveiligingsproblemen. Gedetailleerde monitoringrapporten en audit logs vormen een essentieel onderdeel van het bewijs dat organisaties kunnen presenteren tijdens audits. Het is belangrijk om te benadrukken dat compliance niet alleen gaat om het voldoen aan technische vereisten, maar ook om het hebben van de juiste processen en documentatie. Organisaties moeten daarom documenteren hoe zij RBAC hebben geïmplementeerd, welke rollen zij gebruiken, wie toegang heeft tot welke Key Vaults, en hoe zij regelmatig controleren of de configuratie nog steeds correct is. Deze documentatie moet worden bijgewerkt wanneer er wijzigingen worden aangebracht aan de RBAC-configuratie, en moet regelmatig worden gecontroleerd om ervoor te zorgen dat deze nog steeds accuraat is. Deze documentatie vormt een essentieel onderdeel van het auditbewijs en helpt organisaties om aan te tonen dat zij serieus omgaan met beveiliging en compliance. Bovendien helpt goede documentatie organisaties om hun beveiligingsprocessen te verbeteren door inzicht te geven in hoe toegang wordt beheerd en welke verbeteringen mogelijk zijn.

Remediatie

Gebruik PowerShell-script rbac-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring heeft aangetoond dat een Azure Key Vault nog gebruik maakt van Access Policies in plaats van RBAC, moet er een gestructureerd remediatieproces worden gevolgd om de Key Vault te migreren naar het moderne autorisatiemodel. Dit proces vereist zorgvuldige planning en uitvoering om te voorkomen dat bestaande applicaties en services hun toegang verliezen tijdens de migratie. Een onzorgvuldige migratie kan leiden tot service-onderbrekingen en kan de beveiliging van de organisatie in gevaar brengen, daarom is het essentieel dat organisaties een gestructureerde aanpak volgen die alle risico's minimaliseert. Het remediatieproces begint met een grondige analyse van de huidige Access Policies configuratie. Voor elke Key Vault die nog gebruik maakt van Access Policies moet worden geïnventariseerd welke gebruikers, service principals en beheerde identiteiten momenteel toegang hebben en welke specifieke rechten zij hebben. Deze inventarisatie moet gedetailleerd zijn en moet informatie bevatten over welke geheimen, sleutels en certificaten elke gebruiker of service principal kan benaderen, en welke acties zij kunnen uitvoeren, zoals lezen, schrijven, verwijderen of beheren. Deze informatie is essentieel om te bepalen welke RBAC-rollen moeten worden toegewezen om dezelfde functionaliteit te behouden. Het PowerShell script dat beschikbaar is voor remediatie kan helpen bij het automatisch identificeren van de huidige configuratie door alle Access Policies te lezen en te analyseren, maar het is belangrijk om deze informatie handmatig te verifiëren om ervoor te zorgen dat niets over het hoofd wordt gezien. Tijdens deze verificatie moeten organisaties ook controleren of er gebruikers of service principals zijn met toegang die niet langer nodig is, wat een goede gelegenheid is om het principe van least privilege toe te passen. Na het inventariseren van de huidige toegang, moet er een migratieplan worden opgesteld. Dit plan moet specificeren welke RBAC-rollen zullen worden gebruikt voor elke gebruiker of service principal, en moet ook een tijdlijn bevatten voor wanneer de migratie zal plaatsvinden. Het plan moet rekening houden met de beschikbaarheid van applicaties en services, en moet voorkomen dat migraties plaatsvinden tijdens kritieke bedrijfsperioden. Microsoft biedt verschillende ingebouwde rollen voor Key Vault die organisaties kunnen gebruiken. De Key Vault Secrets Officer rol is bedoeld voor gebruikers die geheimen moeten beheren, zoals wachtwoorden, verbindingsstrings en API-sleutels. Deze rol geeft gebruikers de mogelijkheid om geheimen te lezen, schrijven en verwijderen, maar geeft hen geen toegang tot cryptografische sleutels of certificaten. De Key Vault Crypto Officer rol is specifiek voor het beheren van cryptografische sleutels die worden gebruikt voor versleuteling en digitale handtekeningen. Deze rol geeft gebruikers toegang tot sleutels maar niet tot geheimen. De Key Vault Administrator rol biedt volledige beheerrechten en is bedoeld voor beheerders die de Key Vault configureren en onderhouden. In sommige gevallen kan het nodig zijn om aangepaste rollen te creëren als de ingebouwde rollen niet precies aansluiten bij de vereisten van de organisatie. Aangepaste rollen kunnen worden gecreëerd met behulp van Azure RBAC en kunnen specifieke acties toestaan of weigeren op basis van de behoeften van de organisatie. Voordat de daadwerkelijke migratie wordt uitgevoerd, is het cruciaal om te testen in een niet-productie omgeving. Dit stelt organisaties in staat om het migratieproces te valideren en te verifiëren dat alle applicaties en services na de migratie nog steeds correct functioneren. De testomgeving moet zo veel mogelijk lijken op de productieomgeving, inclusief dezelfde Key Vault configuratie, dezelfde Access Policies, en indien mogelijk dezelfde applicaties die gebruik maken van de Key Vault. Tijdens de test moet worden gecontroleerd of alle bestaande functionaliteit behouden blijft en dat er geen onverwachte toegangsproblemen optreden. Organisaties moeten ook testen of applicaties correct kunnen authenticeren en of zij nog steeds toegang hebben tot alle benodigde geheimen, sleutels en certificaten. Als er problemen worden geïdentificeerd tijdens de test, moeten deze worden opgelost voordat de migratie wordt uitgevoerd in de productieomgeving. De daadwerkelijke migratie kan worden uitgevoerd met behulp van het PowerShell script dat beschikbaar is voor remediatie. Dit script kan automatisch de RBAC-rollen toewijzen op basis van de huidige Access Policies configuratie. Het script analyseert de Access Policies en bepaalt welke RBAC-rollen het beste aansluiten bij de huidige configuratie. Echter, het is belangrijk om te benadrukken dat dit proces niet automatisch de Access Policies verwijdert. Organisaties moeten expliciet kiezen om Access Policies te verwijderen nadat zij hebben geverifieerd dat RBAC correct werkt. Dit kan worden gedaan door de EnableRbacAuthorization eigenschap van de Key Vault in te schakelen, wat automatisch alle Access Policies uitschakelt. Het is aanbevolen om eerst RBAC-rollen toe te wijzen en te verifiëren dat alles correct werkt voordat Access Policies worden verwijderd, zodat organisaties indien nodig kunnen terugvallen op Access Policies als er onverwachte problemen optreden. Tijdens en na de migratie is het essentieel om de functionaliteit van alle applicaties en services te monitoren die gebruik maken van de Key Vault. Organisaties moeten een monitoringperiode instellen waarin zij nauwlettend controleren of alle applicaties en services nog steeds correct functioneren. Eventuele problemen moeten onmiddellijk worden geïdentificeerd en opgelost. Als er onverwachte problemen optreden, kan het nodig zijn om tijdelijk terug te vallen op Access Policies, hoewel dit niet wordt aanbevolen voor de lange termijn. Als organisaties moeten terugvallen op Access Policies, moeten zij een plan opstellen om de problemen op te lossen en opnieuw te proberen de migratie naar RBAC uit te voeren. Na een succesvolle migratie moeten organisaties ervoor zorgen dat alle nieuwe Key Vaults automatisch worden geconfigureerd met RBAC. Dit kan worden bereikt door gebruik te maken van Azure Policy om te controleren dat nieuwe Key Vaults altijd RBAC gebruiken en door standaard templates te gebruiken voor het aanmaken van nieuwe Key Vaults. Azure Policy kan worden geconfigureerd om automatisch te controleren of nieuwe Key Vaults RBAC gebruiken, en kan zelfs automatisch corrigerende maatregelen nemen wanneer een Key Vault wordt aangemaakt zonder RBAC. Bovendien moeten organisaties hun documentatie bijwerken om te reflecteren dat RBAC nu de standaard methode is voor toegangsbeheer en moeten zij hun teams trainen in het gebruik van RBAC in plaats van Access Policies. Deze training moet informatie bevatten over hoe RBAC-rollen worden toegewezen, hoe toegang wordt beheerd, en wat de verschillen zijn tussen RBAC en Access Policies. Door teams te trainen kunnen organisaties ervoor zorgen dat alle nieuwe Key Vaults correct worden geconfigureerd en dat bestaande Key Vaults correct worden beheerd.

Compliance & Frameworks

• BIO: 09.01 - Toegangscontrole en authenticatie
• ISO 27001:2022: A.5.15 - Toegangscontrole en authenticatie

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

Azure Key Vault ondersteunt twee autorisatiemodellen: de verouderde Access Policies en het moderne RBAC-model. Organisaties worden sterk aangeraden om te migreren naar RBAC voor betere beveiliging, compliance en beheerbaarheid. Deze migratie is optioneel maar wordt aanbevolen voor moderne cloudomgevingen.

• Implementatietijd: 5 uur
• FTE required: 0.05 FTE