Key Vault Publieke Toegang Uitgeschakeld

💼 Management Samenvatting

Deze beveiligingsmaatregel is essentieel voor het waarborgen van een veilige cloudomgeving en beschermt tegen ongeautoriseerde toegang en datalekken.

Aanbeveling
Implementeer na configuratie van private endpoints
Risico zonder
Medium
Risk Score
6/10
Implementatie
2u (tech: 1u)
Van toepassing op:
Azure Key Vault

Zonder deze beveiligingsmaatregel kunnen er significante beveiligingsrisico's ontstaan die leiden tot gegevenscompromittering, nalevingsschendingen en reputatieschade voor de organisatie. Azure Key Vault bevat vaak gevoelige informatie zoals certificaten, geheimen en cryptografische sleutels die cruciaal zijn voor de beveiliging van applicaties en services. Wanneer publieke netwerktoegang is ingeschakeld, zelfs met private endpoints geconfigureerd, ontstaat er een dual-mode toegangsscenario waarbij de beveiligingsvoordelen van private endpoints kunnen worden omzeild via het publieke eindpunt. Dit schendt het Zero Trust-principe waarbij netwerkisolatie een fundamentele verdedigingslaag vormt. Organisaties die voldoen aan Nederlandse baseline-vereisten zoals de BIO-normen moeten kunnen aantonen dat gevoelige systemen volledig geïsoleerd zijn van publieke netwerken, tenzij expliciet noodzakelijk voor de bedrijfsvoering.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.KeyVault

Implementatie

Deze beveiligingsmaatregel schakelt publieke netwerktoegang uit voor Azure Key Vault nadat private endpoints (privé-eindpunten) zijn geconfigureerd. Hierdoor wordt toegang tot de Key Vault uitsluitend mogelijk via het virtuele netwerk (VNet), waardoor de beveiligingspostuur aanzienlijk wordt verbeterd en voldaan wordt aan Zero Trust-principes en Nederlandse baseline-vereisten voor netwerkisolatie.

Vereisten

Het uitschakelen van publieke netwerktoegang voor Azure Key Vault is een kritieke beveiligingsmaatregel die zorgvuldig moet worden voorbereid om te voorkomen dat de beschikbaarheid en functionaliteit van de Key Vault wordt verstoord. Voordat deze belangrijke wijziging kan worden doorgevoerd, moeten er verschillende technische en organisatorische vereisten worden vervuld die essentieel zijn om te garanderen dat de Key Vault na het uitschakelen van publieke toegang nog steeds betrouwbaar en veilig bereikbaar blijft voor alle geautoriseerde applicaties en services binnen de organisatie. Deze vereisten vormen de basis voor een succesvolle implementatie en voorkomen dat organisaties worden geconfronteerd met onverwachte downtime of toegankelijkheidsproblemen die de bedrijfsvoering kunnen verstoren.

De primaire en meest kritieke technische vereiste is dat private endpoints, ook wel privé-eindpunten genoemd, volledig zijn geconfigureerd, operationeel zijn en correct functioneren voordat publieke toegang wordt uitgeschakeld. Private endpoints vormen de technische ruggengraat van deze beveiligingsmaatregel door het mogelijk te maken om Azure Key Vault op een veilige en geïsoleerde manier te verbinden met een specifiek virtueel netwerk via een privé IP-adres dat alleen toegankelijk is binnen dat netwerk. Dit betekent dat alle communicatie tussen de Key Vault en de resources binnen het virtuele netwerk plaatsvindt via het Microsoft-backbonenetwerk, een privé en beveiligd netwerk dat volledig is geïsoleerd van het publieke internet. Deze architectuur zorgt ervoor dat verkeer nooit het publieke internet hoeft te passeren, waardoor het risico op onderschepping, manipulatie of andere vormen van netwerkaanvallen aanzienlijk wordt verminderd. De private endpoint moet niet alleen correct zijn gekoppeld aan het virtuele netwerk waar de applicaties en services zich bevinden, maar moet ook voldoende capaciteit hebben om alle verwachte verkeersvolumes te kunnen verwerken zonder prestatieproblemen te veroorzaken.

Naast de technische configuratie van private endpoints zelf, moeten organisaties ook zorgen voor adequate en betrouwbare netwerkconnectiviteit die ervoor zorgt dat alle benodigde resources toegang hebben tot de Key Vault via de private endpoints. Dit betekent dat alle resources die toegang nodig hebben tot de Key Vault, zoals applicaties, services, en automatiseringsscripts, zich binnen hetzelfde virtuele netwerk moeten bevinden waar de private endpoints zijn geconfigureerd. Voor organisaties met complexere netwerkarchitecturen waarbij resources zich in verschillende virtuele netwerken bevinden, moet er een netwerkverbinding zijn geconfigureerd via VNet-peering, wat een directe en veilige verbinding maakt tussen virtuele netwerken binnen dezelfde Azure-regio of tussen verschillende regio's. Alternatief kunnen organisaties gebruikmaken van VPN-verbindingen of Azure ExpressRoute voor on-premises connectiviteit, waarbij het essentieel is dat deze verbindingen robuust zijn en voldoende bandbreedte bieden om de verwachte workloads te ondersteunen. Dit is cruciaal omdat na het uitschakelen van publieke toegang, alle toegangspogingen van buiten het geconfigureerde virtuele netwerk onherroepelijk zullen falen, wat kan leiden tot verstoringen in kritieke bedrijfsprocessen als de netwerkconnectiviteit niet adequaat is voorbereid en getest.

De organisatorische vereisten voor het uitschakelen van publieke toegang zijn minstens zo belangrijk als de technische vereisten en omvatten het uitvoeren van een grondige en uitgebreide impactanalyse voordat publieke toegang wordt uitgeschakeld. IT-teams moeten een complete inventarisatie maken van alle applicaties, services, scripts, en gebruikers die momenteel toegang hebben tot de Key Vault via publieke endpoints, waarbij het essentieel is om niet alleen de primaire gebruikers te identificeren, maar ook alle secundaire en achtergrondprocessen die mogelijk niet direct zichtbaar zijn. Voor elke geïdentificeerde afhankelijkheid moet worden bepaald of deze volledig kan worden gemigreerd naar private endpoint-toegang zonder functionaliteitsverlies, of dat er alternatieve oplossingen nodig zijn zoals het herconfigureren van applicaties of het implementeren van aanvullende netwerkcomponenten. Dit proces vereist nauwe samenwerking tussen security teams die verantwoordelijk zijn voor het beveiligingsbeleid, netwerkbeheerders die de netwerkinfrastructuur beheren, applicatie-eigenaren die de functionele vereisten begrijpen, en operationele teams die inzicht hebben in de dagelijkse gebruikspatronen. Deze multidisciplinaire aanpak zorgt ervoor dat alle aspecten van de wijziging worden overwogen en dat er geen onverwachte problemen ontstaan tijdens of na de implementatie.

Een andere belangrijke vereiste die niet mag worden onderschat is het uitgebreide testen van de private endpoint-configuratie voordat publieke toegang wordt uitgeschakeld. Organisaties moeten een uitgebreide teststrategie ontwikkelen die uitgebreide functionele tests omvat om te verifiëren dat alle kritieke applicaties en services nog steeds correct en betrouwbaar kunnen communiceren met de Key Vault via de private endpoints zonder prestatieverlies of functionaliteitsproblemen. Dit testproces moet verschillende scenario's omvatten die representatief zijn voor de werkelijke gebruikspatronen binnen de organisatie, zoals het ophalen van geheimen door verschillende applicaties, het automatisch vernieuwen van certificaten wanneer deze bijna verlopen zijn, het uitvoeren van complexe cryptografische operaties zoals versleuteling en ontsleuteling, en het monitoren van de performance en latency van deze operaties om te verifiëren dat ze binnen acceptabele grenzen blijven. Daarnaast moeten organisaties ook testen hoe de Key Vault zich gedraagt onder verschillende belastingsomstandigheden, wat essentieel is om te voorkomen dat de private endpoints een bottleneck worden wanneer meerdere applicaties gelijktijdig toegang nodig hebben. Alleen wanneer alle tests succesvol zijn voltooid en er geen kritieke problemen zijn geïdentificeerd, kan publieke toegang veilig worden uitgeschakeld zonder risico op verstoring van de bedrijfsvoering.

Ten slotte moeten organisaties zorgen voor adequate monitoring en logging capaciteiten voordat de wijziging wordt doorgevoerd, omdat dit het mogelijk maakt om eventuele problemen snel te identificeren, te analyseren en te verhelpen na het uitschakelen van publieke toegang. Monitoring moet een uitgebreide dekking omvatten die zowel de beschikbaarheid en gezondheid van de Key Vault zelf monitort, als de prestaties en betrouwbaarheid van de private endpoint-verbindingen die cruciaal zijn voor de toegankelijkheid. Dit omvat het monitoren van metriek zoals de response times van Key Vault operaties, de throughput van requests via private endpoints, eventuele foutmeldingen of timeouts, en de algemene beschikbaarheid van de service. Daarnaast moeten organisaties ervoor zorgen dat er adequate logging is geconfigureerd die alle toegangspogingen, zowel succesvolle als mislukte, vastlegt voor security en compliance doeleinden, waarbij het belangrijk is dat deze logs gemakkelijk toegankelijk zijn voor analyse en auditing.

Monitoring

Gebruik PowerShell-script public-access-disabled-private-endpoint.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van de publieke netwerktoegangsstatus van Azure Key Vault vormt een fundamentele en kritieke beveiligingsactiviteit die continu en regelmatig moet worden uitgevoerd om te verifiëren dat de beveiligingsconfiguratie consistent blijft met de organisatorische vereisten, compliance-standaarden en best practices voor cloudbeveiliging. Deze monitoringactiviteit is essentieel omdat beveiligingsconfiguraties niet statisch zijn en kunnen veranderen door verschillende factoren zoals updates, wijzigingen in het netwerk, migraties, of onopzettelijke wijzigingen door beheerders. De monitoring omvat het systematisch controleren van de PublicNetworkAccess-eigenschap van elke Key Vault in de Azure-omgeving om te verifiëren dat deze correct is ingesteld op 'Disabled' nadat private endpoints zijn geconfigureerd en operationeel zijn. Deze eigenschap bepaalt of de Key Vault toegankelijk is via publieke netwerkverbindingen, wat een belangrijk beveiligingsrisico vormt wanneer het niet correct is geconfigureerd.

De monitoringprocedure begint met het grondig inventariseren van alle Azure Key Vaults binnen de organisatie, waarbij het belangrijk is om niet alleen Key Vaults in productie-omgevingen te identificeren, maar ook die in ontwikkel-, test- en acceptatie-omgevingen, omdat beveiligingskwetsbaarheden in elke omgeving kunnen worden uitgebuit. Dit inventarisatieproces kan worden uitgevoerd via verschillende methoden afhankelijk van de voorkeuren en mogelijkheden van de organisatie, zoals de Azure Portal die een gebruiksvriendelijke interface biedt voor handmatige controles, Azure CLI voor geautomatiseerde scripts, of PowerShell-scripts die kunnen worden geïntegreerd in bestaande monitoring en automatisering workflows. Voor elke geïdentificeerde Key Vault moet systematisch worden gecontroleerd of de PublicNetworkAccess-eigenschap de waarde 'Disabled' heeft, waarbij het essentieel is om niet alleen de huidige status te verifiëren, maar ook de historische trends te analyseren om te identificeren of er onverwachte wijzigingen zijn geweest. Daarnaast moet worden geverifieerd dat er private endpoints zijn geconfigureerd voor elke Key Vault waar publieke toegang is uitgeschakeld, omdat het uitschakelen van publieke toegang zonder private endpoints zou resulteren in een volledig ontoegankelijke Key Vault die alle afhankelijke applicaties en services zou verstoren.

Het is cruciaal om te begrijpen dat de PublicNetworkAccess-eigenschap kan worden ingesteld op drie verschillende waarden die elk verschillende beveiligingsimplicaties hebben. Wanneer de waarde 'Enabled' is ingesteld, betekent dit dat publieke netwerktoegang expliciet is toegestaan, wat betekent dat de Key Vault bereikbaar is via het publieke internet, zelfs wanneer private endpoints zijn geconfigureerd, wat resulteert in een dual-mode toegangsscenario dat de beveiligingsvoordelen van private endpoints ondermijnt. Wanneer de waarde 'Disabled' is ingesteld, betekent dit dat publieke netwerktoegang expliciet is uitgeschakeld, maar dat private endpoints nog steeds kunnen worden gebruikt voor toegang binnen het virtuele netwerk, wat de gewenste configuratie is voor de meeste organisaties die een Zero Trust-beveiligingsmodel willen implementeren. De waarde 'None' betekent dat zowel publieke als private toegang zijn uitgeschakeld, wat resulteert in volledige netwerkisolatie en alleen wordt gebruikt in zeer specifieke scenario's waar geen netwerktoegang is vereist. Voor de meeste organisaties is 'Disabled' met geconfigureerde private endpoints de ideale configuratie omdat het de beveiligingsvoordelen van netwerkisolatie combineert met de noodzakelijke toegankelijkheid via gecontroleerde private netwerken.

Monitoring moet niet alleen worden gezien als een eenmalige controle of periodieke activiteit, maar moet worden geïmplementeerd als een continu en proactief proces dat automatisch afwijkingen detecteert en reageert voordat ze kunnen worden uitgebuit of kritieke problemen veroorzaken. Organisaties moeten daarom geautomatiseerde monitoring oplossingen implementeren die regelmatig, bijvoorbeeld dagelijks of wekelijks, de status van alle Key Vaults controleren en onmiddellijk reageren wanneer afwijkingen worden gedetecteerd. Dit kan worden gerealiseerd door middel van verschillende technologieën en services, zoals Azure Policy die enforcement en compliance kan afdwingen op organisatieniveau, Azure Monitor die geavanceerde monitoring en alerting mogelijkheden biedt, of aangepaste PowerShell-scripts die periodiek worden uitgevoerd door Azure Automation of andere orchestratie tools. Wanneer een afwijking wordt gedetecteerd, bijvoorbeeld wanneer publieke toegang onverwacht is ingeschakeld na een wijziging of update, moeten er automatisch waarschuwingen worden gegenereerd en moeten de verantwoordelijke teams, zoals het security team of netwerkbeheer team, onmiddellijk worden geïnformeerd zodat corrigerende maatregelen snel kunnen worden genomen voordat de beveiligingspostuur verder wordt gecompromitteerd.

Naast het monitoren van de PublicNetworkAccess-eigenschap zelf, moeten organisaties ook uitgebreide monitoring implementeren voor de status, gezondheid en prestaties van alle geconfigureerde private endpoints, omdat deze essentieel zijn voor de toegankelijkheid van de Key Vault nadat publieke toegang is uitgeschakeld. Deze monitoring moet omvatten het continu controleren of private endpoints actief zijn en correct functioneren, of ze correct zijn gekoppeld aan de juiste virtuele netwerken en subnetten, of er geen configuratiefouten zijn die de toegankelijkheid van de Key Vault kunnen beïnvloeden, en of er geen problemen zijn met DNS-resolutie die kunnen voorkomen dat resources de Key Vault vinden via de private endpoints. Daarnaast moeten organisaties ook monitoring implementeren voor netwerkconnectiviteit en latency via private endpoints, waarbij het belangrijk is om te meten hoeveel tijd het kost voor requests om de Key Vault te bereiken via de private endpoints, of er timeouts optreden, en of de throughput voldoende is voor de verwachte workloads. Deze monitoring helpt bij het identificeren van potentiële problemen, zoals netwerkcongestie, configuratiefouten, of capaciteitsproblemen, voordat ze kritiek worden en de beschikbaarheid of prestaties van de Key Vault beïnvloeden.

Voor compliance-doeleinden en auditing is het essentieel dat alle monitoringresultaten worden gedocumenteerd, gearchiveerd en bewaard volgens de organisatorische bewaartermijnen en compliance-vereisten, waarbij het belangrijk is om niet alleen de huidige status vast te leggen, maar ook de historische trends en wijzigingen die inzicht geven in hoe de beveiligingsconfiguratie in de loop van de tijd is geëvolueerd. Dit bewijs is cruciaal voor interne en externe audits en kan worden gebruikt om aan te tonen dat de organisatie proactief toezicht houdt op de beveiligingsconfiguratie van kritieke resources zoals Azure Key Vault, dat er adequate processen en procedures zijn geïmplementeerd om afwijkingen te detecteren en te verhelpen, en dat de organisatie voldoet aan relevante compliance-standaarden zoals BIO, ISO 27001, of andere frameworks die vereisen dat beveiligingsconfiguraties worden gemonitord en gedocumenteerd. De monitoringrapporten moeten duidelijk en gestructureerd zijn en moeten aangeven welke Key Vaults voldoen aan de vereisten en volledig zijn geconfigureerd volgens de best practices, welke eventueel aandacht nodig hebben vanwege configuratiewijzigingen of potentiële problemen, en welke corrigerende maatregelen zijn genomen wanneer afwijkingen zijn gedetecteerd.

Compliance en Auditing

Het uitschakelen van publieke netwerktoegang voor Azure Key Vault na het configureren van private endpoints vormt een essentiële en fundamentele beveiligingsmaatregel die direct en substantieel bijdraagt aan het voldoen aan verschillende belangrijke compliance-standaarden, frameworks en regelgevingsvereisten die relevant zijn voor Nederlandse overheidsorganisaties, publieke instellingen en bedrijven die werken met gevoelige, vertrouwelijke of geclassificeerde gegevens. Deze beveiligingsmaatregel is niet alleen een technische configuratiewijziging, maar een strategische investering in compliance en risicobeheer die organisaties helpt om te voldoen aan zowel nationale als internationale standaarden voor informatiebeveiliging en gegevensbescherming. Door deze maatregel te implementeren, demonstreren organisaties hun commitment aan het implementeren van defense-in-depth strategieën en het volgen van het principe van least privilege, waarbij netwerktoegang wordt beperkt tot alleen wat strikt noodzakelijk is voor de bedrijfsvoering.

Voor Nederlandse overheidsorganisaties en instellingen die onder de overheidsregelgeving vallen, is de Baseline Informatiebeveiliging Overheid (BIO) van cruciaal en verplicht belang, omdat dit het primaire framework is dat wordt gebruikt om informatiebeveiliging te beoordelen en te certificeren binnen de Nederlandse publieke sector. Binnen het BIO-framework valt deze specifieke beveiligingsmaatregel onder controle 13.01, die expliciet betrekking heeft op netwerkisolatie en vereist dat organisaties adequate en effectieve maatregelen treffen om netwerken te isoleren, te segmenteren en te scheiden, waarbij gevoelige systemen en gegevens worden beschermd tegen ongeautoriseerde toegang via publieke netwerken of andere onbeveiligde kanalen. Deze controle vereist dat organisaties kunnen aantonen dat zij netwerksegmentatie hebben geïmplementeerd die verhindert dat onbevoegden toegang krijgen tot kritieke systemen, en dat gevoelige gegevens alleen worden blootgesteld aan geautoriseerde en gecontroleerde netwerkverbindingen. Door publieke toegang expliciet uit te schakelen en uitsluitend private endpoints te gebruiken voor toegang tot Azure Key Vault, voldoen organisaties volledig aan het principe van netwerkisolatie zoals beschreven in BIO 13.01, waarbij het belangrijk is dat deze implementatie wordt gedocumenteerd en kan worden geverifieerd tijdens audits. Dit draagt bovendien substantieel bij aan het creëren en onderhouden van een verdediging-in-diepte-strategie waarbij meerdere beveiligingslagen, waaronder netwerkisolatie, toegangscontrole, versleuteling en monitoring, worden gecombineerd om kritieke assets te beschermen tegen zowel externe als interne bedreigingen.

De ISO 27001:2022 standaard, die wereldwijd wordt erkend en gerespecteerd als de leidende internationale norm voor informatiebeveiligingsmanagementsystemen en die wordt gebruikt door organisaties in zowel de publieke als private sector om hun informatiebeveiligingsprocessen te certificeren en te verbeteren, bevat ook specifieke en expliciete vereisten die direct relevant zijn voor deze beveiligingsmaatregel. Binnen deze standaard valt controle A.8.20, genaamd Networks security, die vereist dat organisaties hun netwerken adequaat beveiligen tegen bekende en opkomende bedreigingen, kwetsbaarheden en risico's, waarbij het essentieel is dat netwerkarchitecturen zijn ontworpen en geïmplementeerd met beveiliging als primaire overweging. Deze controle vereist dat organisaties netwerksegmentatie implementeren die logische scheidingen creëert tussen verschillende delen van het netwerk, dat netwerktoegang wordt beperkt tot alleen wat strikt noodzakelijk is voor de bedrijfsvoering en operationele vereisten, en dat alle netwerkactiviteiten worden gemonitord, gelogd en geanalyseerd om afwijkingen te detecteren en te reageren op beveiligingsincidenten. Het uitschakelen van publieke netwerktoegang voor Azure Key Vault en het gebruik van private endpoints is een concrete en effectieve implementatie van deze ISO 27001:2022 vereisten, omdat het de netwerktoegang beperkt tot geautoriseerde en gecontroleerde kanalen binnen het virtuele netwerk, waarbij alle communicatie plaatsvindt via beveiligde en geïsoleerde netwerkverbindingen die niet toegankelijk zijn vanaf het publieke internet.

Naast BIO en ISO 27001:2022 zijn er tal van andere relevante en belangrijke compliance-frameworks, regelgevingsvereisten en best practices waaraan deze beveiligingsmaatregel substantieel bijdraagt en die organisaties helpen om te voldoen aan hun verplichtingen op het gebied van informatiebeveiliging en gegevensbescherming. De Algemene Verordening Gegevensbescherming (AVG), die van toepassing is op alle organisaties die persoonsgegevens verwerken binnen de Europese Unie en die specifieke technische en organisatorische maatregelen vereist om persoonsgegevens te beschermen tegen ongeautoriseerde toegang, verlies of vernietiging, vereist dat organisaties passende en proportionele technische maatregelen treffen om persoonsgegevens te beveiligen. Het isoleren van systemen die gevoelige gegevens verwerken, zoals Azure Key Vault die cryptografische sleutels en geheimen bevat die cruciaal zijn voor het versleutelen en beveiligen van persoonsgegevens in andere systemen, vormt een belangrijke en essentiële technische maatregel die direct bijdraagt aan AVG-naleving en die organisaties helpt om te voldoen aan artikel 32 van de AVG dat vereist dat passende technische maatregelen worden getroffen om persoonsgegevens te beveiligen. Daarnaast ondersteunt en versterkt deze maatregel het Zero Trust-beveiligingsmodel, dat gebaseerd is op het principe dat geen enkel netwerkverkeer, gebruiker of systeem standaard wordt vertrouwd en dat alle toegang, ongeacht de oorsprong, moet worden geverifieerd, geautoriseerd en gecontroleerd voordat toegang wordt verleend tot kritieke resources. Door publieke toegang uit te schakelen en private endpoints te gebruiken, implementeren organisaties een belangrijk aspect van Zero Trust door ervoor te zorgen dat toegang tot Azure Key Vault alleen mogelijk is via geautoriseerde en gecontroleerde netwerkpaden die kunnen worden gemonitord en geaudit.

Voor auditing-doeleinden, zowel interne als externe audits die worden uitgevoerd om te verifiëren dat organisaties voldoen aan relevante compliance-standaarden en regelgevingsvereisten, moeten organisaties kunnen aantonen en documenteren dat de beveiligingsconfiguratie correct is geïmplementeerd, wordt gehandhaafd en wordt gemonitord om te verifiëren dat afwijkingen worden gedetecteerd en verholpen. Dit vereist uitgebreid en gedocumenteerd bewijs van de configuratiestatus van alle Azure Key Vaults binnen de organisatie, inclusief de actuele waarde van de PublicNetworkAccess-eigenschap, de status en configuratie van alle geconfigureerde private endpoints, en historische gegevens die aantonen hoe de configuratie in de loop van de tijd is geëvolueerd en of er wijzigingen zijn geweest die mogelijk de beveiligingspostuur hebben beïnvloed. Auditors zullen tijdens hun beoordelingen willen verifiëren dat er geen Key Vaults zijn met publieke toegang ingeschakeld wanneer private endpoints beschikbaar zijn en operationeel zijn, omdat dit zou aangeven dat er een beveiligingskwetsbaarheid bestaat die moet worden aangepakt. Daarnaast zullen auditors willen zien dat er adequate en effectieve monitoring en controlemechanismen zijn geïmplementeerd die automatisch afwijkingen detecteren, waarschuwingen genereren wanneer afwijkingen worden gedetecteerd, en dat er processen zijn voor het snel verhelpen van geïdentificeerde problemen voordat ze kunnen worden uitgebuit of kritieke gevolgen hebben voor de beveiliging van de organisatie.

Het is belangrijk en cruciaal om te benadrukken dat compliance niet alleen gaat om het voldoen aan de letter van de wet, regelgeving of standaard, maar ook om het begrijpen en internaliseren van de onderliggende beveiligingsprincipes, risico's en bedreigingen, en het implementeren van maatregelen die daadwerkelijk en substantieel bijdragen aan het verbeteren van de beveiligingspostuur en het verminderen van de blootstelling aan risico's en bedreigingen. Het uitschakelen van publieke netwerktoegang voor Azure Key Vault is niet alleen een compliance-vereiste die moet worden nageleefd om te voldoen aan relevante standaarden en frameworks, maar ook een fundamentele best practice die de algehele beveiliging van de cloudomgeving versterkt en verbetert door het verminderen van de aanvalsoppervlakte, het beperken van de mogelijkheden voor aanvallers om toegang te krijgen tot kritieke resources, en het verhogen van de barrières die aanvallers moeten overwinnen om succesvol te zijn. Deze maatregel vermindert het risico op datalekken en ongeautoriseerde toegang aanzienlijk door ervoor te zorgen dat alleen geautoriseerde en gecontroleerde netwerkverbindingen kunnen worden gebruikt om toegang te krijgen tot Azure Key Vault, waarbij alle communicatie plaatsvindt via beveiligde en geïsoleerde kanalen die niet toegankelijk zijn vanaf het publieke internet.

Remediatie

Gebruik PowerShell-script public-access-disabled-private-endpoint.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring, audits, of beveiligingsbeoordelingen aantonen dat een Azure Key Vault nog steeds publieke netwerktoegang heeft ingeschakeld terwijl private endpoints beschikbaar zijn en operationeel zijn, moet er onmiddellijk en zonder onnodige vertraging actie worden ondernomen om deze beveiligingskwetsbaarheid te verhelpen, omdat elke dag dat publieke toegang is ingeschakeld de organisatie blootstelt aan potentiële beveiligingsrisico's en aanvallen. Het remediatieproces moet zeer zorgvuldig en systematisch worden uitgevoerd om te voorkomen dat de beschikbaarheid, prestaties of functionaliteit van de Key Vault wordt verstoord en om ervoor te zorgen dat alle applicaties, services, scripts en automatiseringsprocessen die afhankelijk zijn van de Key Vault blijven functioneren zonder onderbrekingen of degradatie van de service. Deze balans tussen beveiliging en beschikbaarheid vereist een gestructureerde aanpak die alle aspecten van de wijziging overweegt en die ervoor zorgt dat alle stakeholders betrokken zijn bij het proces.

Het remediatieproces begint met een grondige en uitgebreide voorbereidingsfase die essentieel is voor het succesvol en veilig uitvoeren van de wijziging. Voordat publieke toegang wordt uitgeschakeld, moet eerst worden geverifieerd en bevestigd dat private endpoints correct zijn geconfigureerd, volledig operationeel zijn, en betrouwbaar functioneren onder verschillende belastingsomstandigheden. Dit omvat het systematisch controleren van de status en gezondheid van alle private endpoints die zijn gekoppeld aan de Key Vault, waarbij het belangrijk is om niet alleen te verifiëren dat de endpoints actief zijn, maar ook dat ze correct zijn gekoppeld aan de juiste virtuele netwerken en subnetten, dat er geen configuratiefouten zijn die de functionaliteit kunnen beïnvloeden, en dat DNS-resolutie correct werkt zodat resources de Key Vault kunnen vinden via de private endpoints. Daarnaast moet worden geverifieerd dat de netwerkconnectiviteit vanuit alle resources die toegang nodig hebben tot de Key Vault correct functioneert via de private endpoints, wat betekent dat er tests moeten worden uitgevoerd vanuit verschillende locaties en resources om te bevestigen dat toegang werkt zoals verwacht. Tot slot moeten er uitgebreide functionele tests worden uitgevoerd om te bevestigen dat alle kritieke operaties, zoals het ophalen van geheimen, het vernieuwen van certificaten, het uitvoeren van cryptografische operaties, en het monitoren van de prestaties, nog steeds correct en betrouwbaar kunnen worden uitgevoerd via de private endpoints zonder prestatieverlies of functionaliteitsproblemen.

Een belangrijk en cruciaal onderdeel van de voorbereidingsfase is het tijdig en effectief communiceren met alle stakeholders die mogelijk worden beïnvloed door de wijziging, omdat transparante communicatie essentieel is voor het succesvol doorvoeren van beveiligingswijzigingen zonder verrassingen of weerstand. Dit omvat applicatie-eigenaren die verantwoordelijk zijn voor applicaties die gebruikmaken van de Key Vault, ontwikkelteams die applicaties bouwen en onderhouden die afhankelijk zijn van de Key Vault voor toegang tot geheimen en sleutels, operationele teams die verantwoordelijk zijn voor de dagelijkse werking van services die de Key Vault gebruiken, en beveiligingsteams die verantwoordelijk zijn voor het beveiligingsbeleid en compliance. Alle stakeholders moeten tijdig worden geïnformeerd over de geplande wijziging, het tijdstip waarop deze zal plaatsvinden, de verwachte impact op hun systemen en processen, en wat zij kunnen verwachten tijdens en na de wijziging. Deze communicatie helpt om eventuele verrassingen of onzekerheden te voorkomen en zorgt ervoor dat alle teams adequaat voorbereid zijn op mogelijke impact, hoewel deze minimaal zou moeten zijn wanneer private endpoints correct zijn geconfigureerd en getest. Daarnaast maakt deze communicatie het mogelijk voor stakeholders om potentiële problemen of afhankelijkheden te identificeren die mogelijk niet zijn overwogen in de initiële planning, wat helpt om problemen te voorkomen voordat ze ontstaan.

De daadwerkelijke remediatie, waarbij publieke toegang wordt uitgeschakeld voor de Key Vault, kan worden uitgevoerd via verschillende methoden en tools, afhankelijk van de voorkeuren, mogelijkheden en infrastructuur van de organisatie. De Azure Portal biedt een gebruiksvriendelijke en intuïtieve interface waarbij beheerders naar de specifieke Key Vault kunnen navigeren, het tabblad 'Networking' of 'Netwerkinstellingen' kunnen selecteren, en de optie 'Public access' of 'Publieke toegang' kunnen instellen op 'Disabled' of 'Uitgeschakeld', waarbij het belangrijk is om te verifiëren dat de wijziging succesvol is doorgevoerd en dat de nieuwe configuratie correct wordt weergegeven. Alternatief kunnen beheerders gebruikmaken van Azure CLI commando's of PowerShell-scripts voor geautomatiseerde remediatie, wat vooral nuttig en efficiënt is wanneer meerdere Key Vaults moeten worden bijgewerkt als onderdeel van een bredere beveiligingsinitiatief, of wanneer de remediatie moet worden geïntegreerd in bestaande automatisering, orchestratie, of infrastructure-as-code processen die worden gebruikt voor het beheer van de Azure-omgeving. Geautomatiseerde remediatie biedt bovendien het voordeel dat de wijziging kan worden gepland, gescript en uitgevoerd op een consistente en reproduceerbare manier, wat helpt om menselijke fouten te voorkomen en ervoor zorgt dat alle Key Vaults op dezelfde manier worden geconfigureerd volgens de organisatorische standaarden en best practices.

Na het uitschakelen van publieke toegang is het essentieel en kritiek om onmiddellijk en uitgebreid te verifiëren dat alle kritieke applicaties, services, scripts en automatiseringsprocessen nog steeds correct en betrouwbaar functioneren zonder onderbrekingen of degradatie van de service. Dit verificatieproces moet verschillende scenario's omvatten die representatief zijn voor de werkelijke gebruikspatronen binnen de organisatie, zoals het ophalen van geheimen door verschillende applicaties en services, het automatisch vernieuwen van certificaten wanneer deze bijna verlopen zijn, het uitvoeren van complexe cryptografische operaties zoals versleuteling en ontsleuteling van gegevens, en het monitoren van de prestaties en latency van deze operaties om te verifiëren dat ze binnen acceptabele grenzen blijven en niet zijn verslechterd als gevolg van de wijziging. Monitoring moet worden verhoogd en geïntensiveerd gedurende de eerste uren en dagen na de remediatie om snel eventuele problemen te kunnen identificeren, analyseren en verhelpen voordat ze kritiek worden en de bedrijfsvoering verstoren. Als er onverwachte problemen optreden, zoals applicaties die niet meer kunnen communiceren met de Key Vault of prestatieproblemen die de operationele efficiëntie beïnvloeden, moet er een gedocumenteerde en geteste rollback-procedure beschikbaar zijn die snel kan worden uitgevoerd om de vorige configuratie te herstellen. Het is echter belangrijk om te benadrukken dat rollback alleen als laatste redmiddel moet worden gebruikt en alleen na zorgvuldige overweging van de beveiligingsimplicaties, omdat het herstellen van publieke toegang de beveiligingspostuur onmiddellijk zou verzwakken en de organisatie opnieuw zou blootstellen aan de risico's die de remediatie probeerde te verhelpen.

Voor organisaties die werken met meerdere Azure-abonnementen, resourcegroepen of omgevingen, zoals ontwikkel-, test-, acceptatie- en productie-omgevingen, is het belangrijk en aanbevolen om een gestructureerde en gefaseerde aanpak te volgen voor remediatie die risico's minimaliseert en ervoor zorgt dat eventuele problemen worden geïdentificeerd en opgelost voordat ze impact hebben op kritieke productiesystemen. Dit kan betekenen dat eerst een test- of ontwikkelomgeving wordt bijgewerkt waar geen kritieke bedrijfsprocessen afhankelijk zijn van de Key Vault, gevolgd door acceptatieomgevingen die worden gebruikt voor gebruikersacceptatietests, en ten slotte productieomgevingen waar kritieke bedrijfsprocessen draaien en waar verstoringen de grootste impact zouden hebben. Elke fase moet grondig worden geëvalueerd en gevalideerd voordat wordt overgegaan naar de volgende fase, waarbij het belangrijk is om niet alleen te verifiëren dat de technische configuratie correct is, maar ook dat alle afhankelijke applicaties en services blijven functioneren, dat er geen prestatieproblemen zijn ontstaan, en dat er geen onverwachte afhankelijkheden of gebruikspatronen zijn geïdentificeerd die moeten worden aangepakt voordat de volgende fase wordt gestart. Deze gefaseerde aanpak helpt om risico's te minimaliseren en zorgt ervoor dat eventuele problemen worden geïdentificeerd en opgelost in omgevingen waar de impact beperkt is, voordat wijzigingen worden doorgevoerd in kritieke productieomgevingen.

Na succesvolle remediatie en verificatie dat alle systemen correct functioneren, moet de wijziging uitgebreid worden gedocumenteerd voor compliance, auditing en kennisbeheer doeleinden, waarbij alle relevante informatie moet worden vastgelegd die nodig is om het proces te begrijpen en te reproduceren indien nodig. Deze documentatie moet omvatten het exacte tijdstip en de datum waarop de remediatie is uitgevoerd, de methode en tooling die zijn gebruikt voor de remediatie, de resultaten van alle verificatietests die zijn uitgevoerd om te bevestigen dat de wijziging succesvol was, eventuele problemen die zijn ondervonden en hoe deze zijn opgelost, en de namen en rollen van de personen die betrokken waren bij het proces. Deze documentatie is belangrijk voor compliance-doeleinden omdat het aantoont dat de organisatie proactief actie heeft ondernomen om geïdentificeerde beveiligingskwetsbaarheden te verhelpen, en het helpt bij toekomstige audits door duidelijk te maken wanneer en hoe de wijziging is doorgevoerd. Daarnaast moet de monitoring worden gecontinueerd en mogelijk worden geïntensiveerd om te verifiëren dat de configuratie correct blijft en dat er geen onverwachte wijzigingen plaatsvinden die de beveiligingspostuur kunnen compromitteren, waarbij het belangrijk is om niet alleen te monitoren of publieke toegang opnieuw wordt ingeschakeld, maar ook om te verifiëren dat private endpoints blijven functioneren en dat er geen degradatie van de service plaatsvindt die zou kunnen wijzen op problemen met de netwerkconfiguratie.

Compliance & Frameworks

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 Public Access Disabled Private Endpoint .DESCRIPTION CIS Azure Foundations Benchmark - Control 8.14 Controleert of public access is disabled wanneer private endpoints zijn geconfigureerd. .NOTES Filename: public-access-disabled-private-endpoint.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 8.14 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.KeyVault, Az.Network [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Public Access Disabled Private Endpoint" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $vaults = Get-AzKeyVault -ErrorAction SilentlyContinue $result = @{ TotalVaults = $vaults.Count; Compliant = 0 } foreach ($vault in $vaults) { $vaultDetail = Get-AzKeyVault -VaultName $vault.VaultName -ErrorAction SilentlyContinue $privateEndpoints = Get-AzPrivateEndpointConnection -PrivateLinkResourceId $vault.ResourceId -ErrorAction SilentlyContinue if ($privateEndpoints -and $vaultDetail.NetworkAcls.DefaultAction -eq 'Deny') { $result.Compliant++ } } return $result } try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total Key Vaults: $($r.TotalVaults)" -ForegroundColor White Write-Host "Compliant: $($r.Compliant)" -ForegroundColor $(if ($r.Compliant -gt 0) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nPublic Access Disabled: $($r.Compliant)/$($r.TotalVaults) vaults" } } catch { Write-Error $_; exit 1 } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total Key Vaults: $($r.TotalVaults)" -ForegroundColor White Write-Host "Compliant: $($r.Compliant)" -ForegroundColor $(if ($r.Compliant -gt 0) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nPublic Access Disabled: $($r.Compliant)/$($r.TotalVaults) vaults" } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
Medium: Wanneer publieke toegang is ingeschakeld terwijl private endpoints zijn geconfigureerd, ontstaat er een dual-mode toegangsscenario waarbij de beveiligingsvoordelen van private endpoints kunnen worden omzeild via het publieke eindpunt. Dit schendt het Zero Trust-principe en de defense-in-depth-strategie. Het risico wordt beoordeeld als medium, omdat het een belangrijke beveiligingslaag compromitteert die essentieel is voor het beschermen van gevoelige cryptografische sleutels en geheimen. Organisaties die niet voldoen aan deze vereiste lopen het risico op nalevingsschendingen en kunnen tijdens audits worden geconfronteerd met bevindingen die corrigerende maatregelen vereisen.

Management Samenvatting

Publieke toegang uitschakelen: Schakel publieke netwerktoegang uit voor Azure Key Vault nadat private endpoints zijn geïmplementeerd, zodat toegang uitsluitend mogelijk is via het virtuele netwerk. Activeren: Navigeer naar Key Vault → Networking → Publieke toegang: Uitgeschakeld. Geen extra kosten. Implementatietijd: 1-2 uur (test eerst de private endpoint-configuratie). Dit zorgt voor toegang uitsluitend via het virtuele netwerk en versterkt de netwerkisolatie.