Azure Storage Account: Private Endpoints Configureren Voor Netwerkisolatie

Standaard zijn Azure Storage Accounts toegankelijk via publieke internet endpoints met een wereldwijd oplosbare URL (bijvoorbeeld myaccount.blob.core.windows.net) die vanaf elke locatie ter wereld bereikbaar is met de juiste toegangssleutels of SAS-tokens. Deze publieke blootstelling creëert aanzienlijke beveiligingsrisico's die directe invloed hebben op de beveiligingspostuur van organisaties. Geautomatiseerde scanning tools voeren continu brute-force aanvallen uit op opslagaccount namen en toegangssleutels, waarbij ze systematisch proberen toegang te krijgen tot opslagaccounts. Wanneer opslagaccount toegangssleutels per ongeluk worden gelekt in GitHub repositories of configuratiebestanden, biedt dit onmiddellijk wereldwijde toegang tot alle blobs en bestanden zonder geografische beperkingen. Bovendien is geen echte netwerksegmentatie mogelijk omdat opslag fundamenteel internetgericht blijft, ongeacht firewall-regels. Op IP-adres gebaseerde firewall-regels zijn complex om te beheren bij dynamische client IP-adressen en bieden beperkte bescherming tegen geavanceerde aanvallen. Compliance-vereisten zoals NIS2 Artikel 21 voor netwerkisolatie van kritieke data-opslag en ISO 27001 controle A.13.1.1 voor netwerkcontroles kunnen niet worden voldaan met publiek toegankelijke opslag. Private Endpoints transformeren deze architectuur fundamenteel door opslag volledig binnen een VNet te plaatsen met privé IP-adressen uit het VNet-adresbereik. Deze architectuur maakt toegang uitsluitend mogelijk vanuit het VNet of verbonden netwerken zoals on-premises omgevingen via ExpressRoute of VPN-verbindingen. Network Security Group (NSG) controles worden mogelijk gemaakt voor granulaire verkeersbeheer op netwerkniveau, waardoor organisaties precies kunnen bepalen welke resources toegang hebben tot de opslagaccounts. Publieke DNS-resolutie wordt geëlimineerd, waardoor opslag niet meer via het internet vindbaar is. Verkeer wordt gerouteerd via het Azure Backbone-netwerk, wat niet alleen sneller maar ook aanzienlijk veiliger is door gebruik te maken van Microsoft's beveiligde netwerkinfrastructuur. Deze architectuur wordt sterk aanbevolen voor opslagaccounts met vertrouwelijke gegevens, persoonsgegevens of andere compliance-vereisten die strikte netwerkisolatie vereisen.

Implementatie

Deze maatregel implementeert Private Endpoints voor Azure Storage Accounts waarbij afzonderlijke endpoints worden gecreëerd voor elk opslag servicetype. Azure Storage bestaat uit vier verschillende servicetypen: Blob storage voor objectopslag, File storage voor bestandsdelingen, Table storage voor NoSQL-tabellen, en Queue storage voor berichtenwachtrijen. Elk servicetype vereist zijn eigen Private Endpoint omdat elk servicetype zijn eigen Private DNS Zone nodig heeft voor correcte DNS-resolutie. De implementatie omvat het aanmaken van Private Endpoint-resources voor blob service met de Private DNS Zone privatelink.blob.core.windows.net, file service met privatelink.file.core.windows.net, table service met privatelink.table.core.windows.net, en queue service met privatelink.queue.core.windows.net. Tijdens het aanmaakproces krijgt elke endpoint automatisch een privé IP-adres toegewezen uit een gespecificeerd VNet-subnet, waardoor de opslag volledig binnen het virtuele netwerk wordt geplaatst. Private DNS Zones moeten worden geconfigureerd voor elk servicetype en gekoppeld aan het VNet om automatische DNS-resolutie van opslag FQDNs naar privé IP-adressen mogelijk te maken. Zonder deze DNS-configuratie zouden applicaties en workloads nog steeds proberen verbinding te maken via publieke endpoints, wat de netwerkisolatie teniet zou doen. Na de implementatie van alle Private Endpoints moet de eigenschap publicNetworkAccess worden ingesteld op 'Disabled' om publieke endpoint-toegang volledig uit te schakelen. Deze kritieke stap zorgt ervoor dat het opslagaccount niet langer toegankelijk is via publieke internet endpoints. Voor specifieke Azure platform-services die toegang nodig hebben tot het opslagaccount ondanks de uitgeschakelde publieke toegang, kunnen vertrouwde services worden geconfigureerd zoals beschreven in trusted-services-enabled.json. De implementatie brengt kosten met zich mee van €6 per endpoint per maand, wat resulteert in €24 per maand voor alle vier servicetypen bij een volledige implementatie. De technische implementatie vereist ongeveer 4 tot 6 uur werk, afhankelijk van de complexiteit van de netwerkinfrastructuur en het aantal opslagaccounts dat moet worden geconfigureerd. Deze maatregel wordt sterk aanbevolen voor opslagaccounts die gevoelige gegevens bevatten of onderworpen zijn aan compliance-regelgeving zoals NIS2, ISO 27001, of BIO. De implementatie voldoet aan CIS Azure Benchmark controle 3.8 op Level 2, die specifiek eist dat opslagaccounts gebruik maken van Private Endpoints voor netwerkisolatie, en aan BIO controle 13.01 die betrekking heeft op netwerkbeveiliging en segmentatie.

Vereisten

Voor de succesvolle implementatie van Private Endpoints voor Azure Storage Accounts zijn verschillende technische en organisatorische vereisten essentieel. Deze vereisten vormen de fundering waarop de netwerkisolatie wordt gebouwd en bepalen in grote mate het succes van de implementatie. Zonder een grondige voorbereiding en het voldoen aan alle vereisten kan de implementatie falen of leiden tot onverwachte onderbrekingen in de beschikbaarheid van opslagservices. De primaire technische vereiste betreft de aanwezigheid van een Azure Virtual Network (VNet) met voldoende adresruimte. Het VNet moet beschikken over een subnet dat specifiek is gereserveerd voor Private Endpoints, waarbij rekening moet worden gehouden met de benodigde IP-adressen. Elke Private Endpoint vereist een privé IP-adres uit het subnet-adresbereik, en voor een volledige implementatie met alle vier de opslag servicetypen (Blob, File, Table en Queue) zijn minimaal vier IP-adressen nodig. Organisaties moeten daarom een subnet configureren met voldoende capaciteit, waarbij een /27 subnet (32 IP-adressen) of groter wordt aanbevolen om ruimte te bieden voor toekomstige uitbreidingen en andere Private Endpoints. Het is belangrijk om te realiseren dat het subnet-adresbereik niet kan worden gewijzigd nadat resources zijn geïmplementeerd, waardoor vooruitdenken over de benodigde capaciteit cruciaal is. Daarnaast moet het subnet worden geconfigureerd zonder Network Security Group (NSG) regels die de verbinding met Private Endpoints blokkeren, tenzij specifieke beveiligingsvereisten dit rechtvaardigen. Een tweede kritieke vereiste betreft de configuratie van Private DNS Zones. Azure Private DNS Zones zijn essentieel voor de automatische DNS-resolutie van opslag FQDNs naar private IP-adressen binnen het VNet. Zonder correct geconfigureerde DNS Zones zouden applicaties en workloads nog steeds proberen verbinding te maken via publieke endpoints, waardoor de netwerkisolatie volledig wordt ondermijnd. Voor elk opslag servicetype moet een specifieke Private DNS Zone worden geconfigureerd: privatelink.blob.core.windows.net voor Blob storage, privatelink.file.core.windows.net voor File storage, privatelink.table.core.windows.net voor Table storage, en privatelink.queue.core.windows.net voor Queue storage. Deze DNS Zones moeten worden gekoppeld aan het VNet door middel van virtual network links, waardoor alle resources binnen het VNet automatisch de juiste DNS-resolutie krijgen voor opslagaccounts. Het is belangrijk om te begrijpen dat deze DNS Zones regionaal zijn en moeten worden aangemaakt in dezelfde Azure-regio als het VNet en de opslagaccounts. Daarnaast moeten organisaties overwegen om deze DNS Zones te centraliseren in een gedeelde resource group voor betere beheerbaarheid, vooral wanneer meerdere opslagaccounts en VNets betrokken zijn. Naast deze technische vereisten zijn er ook organisatorische overwegingen die aandacht vereisen. Organisaties moeten een duidelijk beeld hebben van welke opslagaccounts in aanmerking komen voor Private Endpoints, waarbij prioriteit wordt gegeven aan accounts die gevoelige data bevatten, persoonsgegevens verwerken, of onderworpen zijn aan compliance-vereisten zoals NIS2 of ISO 27001. Het uitvoeren van een grondige inventarisatie van alle opslagaccounts en het classificeren van de data die zij bevatten is een essentiële eerste stap. Daarnaast moet er overleg plaatsvinden met netwerkbeheerders en beveiligingsteams om ervoor te zorgen dat de implementatie van Private Endpoints past binnen de bredere netwerkarchitectuur en beveiligingsbeleid van de organisatie. Dit overleg moet ook betrekking hebben op de impact op bestaande netwerkconnectiviteit, routing-configuraties, en eventuele wijzigingen die nodig zijn in firewall-regels of andere netwerkbeveiligingsapparatuur. Het is ook belangrijk om te bepalen welke workloads en applicaties toegang nodig hebben tot de opslagaccounts, aangezien deze na de implementatie alleen nog toegankelijk zijn vanuit het VNet of verbonden netwerken zoals on-premises omgevingen via ExpressRoute of VPN-verbindingen. Applicaties die momenteel toegang hebben via publieke endpoints moeten worden geïdentificeerd en geëvalueerd om te bepalen of zij kunnen worden gemigreerd naar het VNet of dat alternatieve connectiviteitsoplossingen nodig zijn. Dit kan betekenen dat applicaties moeten worden hergeconfigureerd, workloads moeten worden verplaatst naar Azure, of dat aanvullende netwerkconnectiviteit moet worden geïmplementeerd. Het is cruciaal om deze impactanalyse uit te voeren voordat de implementatie begint, om te voorkomen dat kritieke applicaties onverwacht hun toegang tot opslag verliezen. Daarnaast moeten organisaties rekening houden met de kosten van de implementatie. Private Endpoints brengen kosten met zich mee van €6 per endpoint per maand, wat resulteert in €24 per maand voor alle vier servicetypen bij een volledige implementatie per opslagaccount. Voor organisaties met meerdere opslagaccounts kunnen deze kosten snel oplopen, waardoor een kosten-batenanalyse belangrijk is. Echter, deze kosten moeten worden afgewogen tegen de beveiligingsvoordelen en de compliance-vereisten die de organisatie moet naleven. Voor opslagaccounts met gevoelige data of persoonsgegevens zijn deze kosten meestal gerechtvaardigd gezien de significante verbetering in beveiligingspostuur en het voldoen aan compliance-vereisten.

Implementatie

Gebruik PowerShell-script storage-private-endpoints.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van Private Endpoints voor Azure Storage Accounts is een gestructureerd proces dat zorgvuldige planning en uitvoering vereist. Het proces begint met de voorbereiding van de netwerkinfrastructuur, waarbij eerst wordt gecontroleerd of het VNet en de benodigde subnetten correct zijn geconfigureerd. Vervolgens worden de Private DNS Zones aangemaakt en gekoppeld aan het VNet, waarna de daadwerkelijke Private Endpoints worden gecreëerd voor elk opslag servicetype. De eerste stap in de implementatie betreft het aanmaken van de Private DNS Zones. Deze zones moeten worden geconfigureerd voordat de Private Endpoints worden aangemaakt, omdat de endpoints tijdens het aanmaakproces automatisch DNS-records toevoegen aan deze zones. Voor elk servicetype wordt een aparte Private DNS Zone aangemaakt met de juiste naamgeving conform Azure-standaarden. De zones worden vervolgens gekoppeld aan het VNet door middel van virtual network links, waardoor alle resources binnen het VNet automatisch de juiste DNS-resolutie krijgen voor opslagaccounts. Na de DNS-configuratie volgt het aanmaken van de Private Endpoints zelf. Voor elk opslag servicetype (Blob, File, Table en Queue) wordt een aparte Private Endpoint-resource aangemaakt. Tijdens het aanmaakproces wordt het opslagaccount geselecteerd, het juiste subnet gekozen, en de resource group en locatie gespecificeerd. Azure wijst automatisch een privé IP-adres toe uit het subnet-adresbereik en registreert dit adres in de bijbehorende Private DNS Zone. Het is belangrijk om tijdens dit proces te controleren dat het juiste servicetype wordt geselecteerd, aangezien elk endpoint specifiek is voor één servicetype. Na het aanmaken van alle Private Endpoints volgt de kritieke stap van het uitschakelen van publieke toegang. Dit gebeurt door de eigenschap publicNetworkAccess van het opslagaccount in te stellen op 'Disabled'. Deze actie zorgt ervoor dat het opslagaccount niet langer toegankelijk is via publieke internet endpoints, waardoor alle toegang uitsluitend via de Private Endpoints verloopt. Het is belangrijk om deze stap pas uit te voeren nadat alle Private Endpoints succesvol zijn aangemaakt en getest, om te voorkomen dat toegang tot het opslagaccount wordt geblokkeerd. Na de implementatie moet uitgebreide testing worden uitgevoerd om te verifiëren dat alle functionaliteit correct werkt. Dit omvat het testen van toegang vanuit resources binnen het VNet, het controleren van DNS-resolutie, en het valideren dat publieke toegang daadwerkelijk is uitgeschakeld. Daarnaast moeten applicaties en workloads die gebruik maken van het opslagaccount worden getest om ervoor te zorgen dat zij nog steeds correct functioneren via de Private Endpoints.

Compliance en Audit

De implementatie van Private Endpoints voor Azure Storage Accounts speelt een cruciale rol in het voldoen aan verschillende compliance-vereisten en beveiligingsframeworks die relevant zijn voor Nederlandse overheidsorganisaties en organisaties die werken met gevoelige data. Deze maatregel adresseert specifieke controles uit meerdere frameworks en draagt bij aan een robuuste beveiligingspostuur. Binnen het CIS Azure Benchmark framework wordt deze implementatie gedekt door controle 3.8 op Level 2, die specifiek eist dat opslagaccounts gebruik maken van Private Endpoints om netwerkisolatie te waarborgen. Deze controle maakt deel uit van de Identity and Access Management-sectie van het framework en richt zich op het beperken van de attack surface door publieke exposure te elimineren. De implementatie van Private Endpoints voldoet volledig aan deze controle door opslagaccounts volledig binnen een VNet te plaatsen en publieke toegang uit te schakelen. Organisaties die streven naar CIS Level 2 compliance moeten deze maatregel implementeren voor alle opslagaccounts die gevoelige data bevatten. Voor Nederlandse overheidsorganisaties is de BIO (Baseline Informatiebeveiliging Overheid) van bijzonder belang. Binnen het BIO-framework wordt deze implementatie gedekt door controle 13.01, die betrekking heeft op netwerkbeveiliging. Deze controle vereist dat organisaties passende maatregelen treffen om netwerkverkeer te beveiligen en te isoleren, met name voor systemen en data die als kritiek worden beschouwd. Private Endpoints voor opslagaccounts dragen direct bij aan het voldoen aan deze controle door netwerksegmentatie te implementeren en ervoor te zorgen dat opslagaccounts niet langer publiek toegankelijk zijn via het internet. Dit is met name relevant voor opslagaccounts die persoonsgegevens bevatten of andere gevoelige overheidsinformatie. Naast deze specifieke frameworks draagt de implementatie ook bij aan het voldoen aan NIS2-vereisten, met name Artikel 21 dat betrekking heeft op netwerkisolatie en segmentatie van kritieke infrastructuren. Door opslagaccounts volledig binnen een VNet te plaatsen en publieke toegang te elimineren, voldoen organisaties aan de vereisten voor netwerkisolatie zoals gespecificeerd in de NIS2-richtlijn. Dit is met name relevant voor organisaties die worden aangemerkt als essentiële of belangrijke entiteiten onder NIS2. Voor auditdoeleinden is het belangrijk om documentatie bij te houden van de implementatie, inclusief de configuratie van Private Endpoints, DNS Zones, en de status van publicNetworkAccess-instellingen. Deze documentatie moet worden bewaard gedurende de gespecificeerde retentietijd en moet beschikbaar zijn voor interne en externe audits. Daarnaast moeten regelmatige compliance-checks worden uitgevoerd om te verifiëren dat de implementatie nog steeds voldoet aan de vereisten en dat er geen regressies zijn opgetreden.

Monitoring

Gebruik PowerShell-script storage-private-endpoints.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Private Endpoints voor Azure Storage Accounts is essentieel om te waarborgen dat de netwerkisolatie blijft functioneren zoals bedoeld en om tijdig te kunnen reageren op eventuele problemen of configuratiewijzigingen. Monitoring moet zich richten op verschillende aspecten: de status en beschikbaarheid van de Private Endpoints zelf, de DNS-configuratie en resolutie, de netwerkconnectiviteit, en de compliance-status van de opslagaccounts. De primaire monitoringtaak betreft het regelmatig controleren van de status van alle Private Endpoints. Dit omvat het verifiëren dat alle endpoints in een 'Approved' status staan, wat aangeeft dat de verbinding met het opslagaccount succesvol is geconfigureerd. Endpoints in een 'Pending' of 'Rejected' status vereisen onmiddellijke aandacht, aangezien dit wijst op configuratieproblemen of verbindingsfouten. Daarnaast moet worden gemonitord of alle verwachte endpoints aanwezig zijn voor elk opslagaccount, waarbij specifiek wordt gecontroleerd of alle vier de service types (Blob, File, Table, Queue) zijn geconfigureerd waar van toepassing. DNS-monitoring is eveneens kritiek, aangezien een falende DNS-resolutie kan leiden tot connectiviteitsproblemen voor applicaties en workloads. Het is belangrijk om regelmatig te verifiëren dat de Private DNS Zones correct zijn gekoppeld aan het VNet en dat de DNS-records correct zijn geconfigureerd. Dit kan worden gedaan door DNS-queries uit te voeren vanuit resources binnen het VNet en te controleren of de opslagaccount FQDNs correct worden omgezet naar de private IP-adressen van de endpoints. Eventuele afwijkingen in DNS-resolutie moeten onmiddellijk worden onderzocht, aangezien deze kunnen wijzen op problemen met de DNS-configuratie of de Private Endpoints zelf. Een derde belangrijk aspect van monitoring betreft het controleren van de publicNetworkAccess-instelling van opslagaccounts. Deze instelling moet consistent 'Disabled' zijn voor alle opslagaccounts die Private Endpoints gebruiken, om te waarborgen dat publieke toegang daadwerkelijk is uitgeschakeld. Regelmatige checks moeten worden uitgevoerd om te detecteren of deze instelling per ongeluk is gewijzigd of is teruggedraaid, wat een significant beveiligingsrisico zou vormen. Automatische alerting kan worden geconfigureerd om onmiddellijk te waarschuwen wanneer publicNetworkAccess wordt gewijzigd naar 'Enabled'. Daarnaast moet netwerkconnectiviteit worden gemonitord om te verifiëren dat applicaties en workloads nog steeds correct kunnen verbinden met opslagaccounts via de Private Endpoints. Dit kan worden gedaan door middel van connectivity tests vanuit verschillende resources binnen het VNet, waarbij wordt gecontroleerd of de verbindingen succesvol zijn en binnen acceptabele latency-tijden blijven. Eventuele connectiviteitsproblemen moeten worden onderzocht in samenhang met de DNS-configuratie en de status van de Private Endpoints. Voor compliance-doeleinden moet regelmatig worden geverifieerd dat de implementatie nog steeds voldoet aan de vereisten van relevante frameworks zoals CIS Azure Benchmark en BIO. Dit omvat het controleren of alle opslagaccounts die gevoelige data bevatten daadwerkelijk Private Endpoints gebruiken en of er geen regressies zijn opgetreden in de configuratie. Deze compliance-checks moeten worden gedocumenteerd en beschikbaar zijn voor auditdoeleinden.

Remediatie

Gebruik PowerShell-script storage-private-endpoints.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring of compliance-checks aangeven dat Private Endpoints niet correct zijn geconfigureerd of dat opslagaccounts nog steeds publiek toegankelijk zijn, moet onmiddellijk remediatie worden uitgevoerd om de beveiligingspostuur te herstellen. Remediatie-acties variëren afhankelijk van de specifieke bevindingen, maar volgen over het algemeen een gestructureerde aanpak die begint met het identificeren van de root cause en vervolgens de juiste correctieve maatregelen implementeert. Een veelvoorkomende bevinding betreft opslagaccounts die nog steeds publiek toegankelijk zijn omdat publicNetworkAccess is ingesteld op 'Enabled' of 'EnabledForAzureServices'. In dergelijke gevallen moet onmiddellijk worden gecontroleerd of Private Endpoints correct zijn geconfigureerd voor het betreffende opslagaccount. Als de endpoints aanwezig zijn en correct functioneren, moet publicNetworkAccess worden gewijzigd naar 'Disabled' om publieke toegang uit te schakelen. Het is belangrijk om deze wijziging te coördineren met applicatie-eigenaren en workloads om ervoor te zorgen dat alle systemen nog steeds correct kunnen functioneren via de Private Endpoints na het uitschakelen van publieke toegang. Een andere veelvoorkomende situatie betreft opslagaccounts die Private Endpoints missen voor een of meer service types. In dergelijke gevallen moeten de ontbrekende endpoints worden aangemaakt volgens het standaard implementatieproces. Het is belangrijk om te identificeren welke service types daadwerkelijk worden gebruikt door applicaties en workloads, zodat prioriteit kan worden gegeven aan het aanmaken van endpoints voor deze services. Voor service types die niet actief worden gebruikt, kan worden overwogen om deze over te slaan om kosten te besparen, hoewel het aanbevolen wordt om alle service types te configureren voor volledige netwerkisolatie. Problemen met DNS-resolutie vereisen specifieke remediatie-acties. Als DNS-queries niet correct worden omgezet naar private IP-adressen, moet worden gecontroleerd of de Private DNS Zones correct zijn gekoppeld aan het VNet en of de DNS-records correct zijn geconfigureerd. In sommige gevallen kan het nodig zijn om de virtual network links opnieuw te configureren of om de DNS-records handmatig te verifiëren en indien nodig te corrigeren. Het is ook belangrijk om te controleren of er geen conflicterende DNS-configuraties zijn, zoals custom DNS-servers die mogelijk de resolutie beïnvloeden. Wanneer Private Endpoints in een 'Pending' of 'Rejected' status staan, moet worden onderzocht wat de oorzaak is van het probleem. Dit kan variëren van onvoldoende IP-adresruimte in het subnet tot problemen met de verbinding tussen het Private Endpoint en het opslagaccount. Remediatie omvat het oplossen van de onderliggende oorzaak, zoals het uitbreiden van het subnet-adresbereik of het opnieuw configureren van de Private Endpoint-verbinding. In sommige gevallen kan het nodig zijn om de Private Endpoint te verwijderen en opnieuw aan te maken met de juiste configuratie. Na het uitvoeren van remediatie-acties moet uitgebreide verificatie worden uitgevoerd om te bevestigen dat de problemen daadwerkelijk zijn opgelost. Dit omvat het testen van connectiviteit, het verifiëren van DNS-resolutie, en het controleren van de compliance-status. Daarnaast moeten de remediatie-acties worden gedocumenteerd, inclusief de bevindingen, de uitgevoerde acties, en de verificatieresultaten. Deze documentatie is belangrijk voor auditdoeleinden en voor het leren van incidenten om toekomstige problemen te voorkomen.

Compliance & Frameworks

• CIS M365: Control 3.8 (L2) - privé endpoints (privé eindpunten)
• BIO: 13.01 - Netwerkbeveiliging

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

Alternatieve verificatie voor Storage Private Endpoints. Zie private-endpoints-storage-accounts.json voor volledige implementatie (VNet-only access, €6/maand/endpoint). Verplicht CIS 3.9.

• Implementatietijd: 6 uur
• FTE required: 0.1 FTE