L1 BIO 11.02 ISO A.5.15 CIS 3.7

Azure Storage: Anonieme Toegang Tot Blob Containers Uitschakelen

📅 2025-10-29
•
⏱️ 4 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Het uitschakelen van anonieme toegang tot Azure Blob Storage-containers voorkomt dat gevoelige gegevens publiek toegankelijk worden via internet zonder authenticatie. Deze maatregel is essentieel voor het voorkomen van datalekken door verkeerd geconfigureerde publieke containers die een veelvoorkomende oorzaak zijn van grote datalekken.

Aanbeveling
IMPLEMENTEER - ZIE public-blob-access-disabled.json
Risico zonder
Critical
Risk Score
10/10
Implementatie
2u (tech: 1u)
Van toepassing op:
✓ Azure opslag

Anonieme toegang tot blob containers stelt iedereen wereldwijd in staat om gegevens te lezen zonder enige authenticatie, wat een kritiek beveiligingsrisico vormt. Verkeerd geconfigureerde publieke containers zijn verantwoordelijk geweest voor enkele van de grootste datalekken in de recente geschiedenis waarbij miljarden records zijn blootgesteld doordat opslagcontainers per ongeluk op 'publiek' waren gezet. Dit gebeurt vaak omdat ontwikkelaars containers publiek maken voor test- of ontwikkelingsdoeleinden en vergeten deze terug te zetten naar privé, geautomatiseerde scripts containers aanmaken met standaard publieke instellingen zonder beveiligingsbeoordeling, of beheerders niet begrijpen dat publieke containers echt wereldwijd toegankelijk zijn zonder inloggegevens. De gevolgen zijn catastrofaal: gevoelige bedrijfsgegevens zoals financiële rapporten, klantgegevens of contracten worden publiek toegankelijk en kunnen worden geïndexeerd door zoekmachines, persoonsgegevens worden blootgesteld wat AVG-schendingen oplevert met potentiële boetes tot €20 miljoen, aanvallers scannen systematisch Azure IP-bereiken op zoek naar publieke containers met tools zoals 'GrayhatWarfare', en compliance-audits falen omdat publieke gegevensexpositie niet kan worden gerechtvaardigd onder frameworks zoals ISO 27001 of NIS2. Het uitschakelen van anonieme toegang op accountniveau voorkomt deze risico's door een tenantbreed beleid af te dwingen waarbij GEEN ENKELE container publiek kan worden gemaakt ongeacht individuele containerinstellingen, alle toegang Azure AD-authenticatie vereist of Shared Access Signatures (SAS) met vervaldatums, en onbedoelde publieke blootstelling onmogelijk wordt gemaakt door configuratiefouten. Deze aanpak volgt defense-in-depth waarbij zelfs als een containerinstelling foutief wordt geconfigureerd, het accountniveau-beleid dit overschrijft. Voor publieke websites of CDN-scenario's moeten alternatieve patronen worden gebruikt zoals Azure CDN met origin-authenticatie of Static Website Hosting met juiste toegangscontroles. Deze maatregel is verplicht voor compliance met CIS Azure Benchmark controle 3.7 Niveau 1, AVG Artikel 32, en BIO 13.01.

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

Implementatie

Deze maatregel configureert de AllowBlobPublicAccess-eigenschap op false voor alle Azure Storage Accounts, wat anonieme toegang op accountniveau volledig blokkeert. De implementatie gebeurt via Azure Portal onder Storage account → Configuration → Allow Blob public access waar deze moet worden ingesteld op 'Uitgeschakeld', of via PowerShell Set-AzStorageAccount -AllowBlobPublicAccess $false voor geautomatiseerde implementatie. Wanneer deze instelling op false staat, kunnen individuele containers niet meer publiek worden gemaakt ongeacht hun containerniveau toegangsbeleid - alle toegang vereist authenticatie via Azure AD, opslagaccount sleutels, of SAS-tokens met vervaldatum. Bestaande publieke containers worden automatisch privé zonder gegevensverlies. Applicaties die publieke blob-URL's gebruiken krijgen HTTP 401 Unauthorized-fouten en moeten worden bijgewerkt om authenticatie te gebruiken. Voor legitieme publieke toegangsscenario's moeten alternatieven worden geïmplementeerd: Azure CDN met origin-authenticatie voor publieke bestandsserving, Azure Static Web App Hosting voor websites, of tijdelijke SAS-URL's met vervaldatum voor gecontroleerd publiek delen. De implementatie kost 1-2 uur voor configuratie plus mogelijke applicatieaanpassingen indien publieke URL's werden gebruikt. Deze maatregel is kosteloos, heeft geen prestatie-impact, en is een kritieke beveiligingscontrole voor alle Azure Storage Accounts. Dit is verplicht voor alle tenants en voldoet aan CIS Azure Foundations Benchmark v3.0.0 controle 3.7 Niveau 1.

Vereisten

Voor de implementatie van deze beveiligingsmaatregel zijn specifieke vereisten nodig om ervoor te zorgen dat de configuratie correct wordt toegepast en dat alle Azure Storage Accounts binnen de tenant worden beveiligd. De primaire vereiste is de aanwezigheid van Azure Storage Accounts binnen de organisatie. Deze opslagaccounts kunnen worden gebruikt voor verschillende doeleinden zoals het opslaan van applicatiegegevens, back-ups, logbestanden, of statische website-inhoud. Het is essentieel dat alle opslagaccounts worden geïdentificeerd voordat de maatregel wordt geïmplementeerd, omdat anonieme toegang op accountniveau wordt uitgeschakeld en dit gevolgen kan hebben voor applicaties die momenteel afhankelijk zijn van publieke blob-toegang. Naast de aanwezigheid van Azure Storage Accounts is het belangrijk dat de persoon die de implementatie uitvoert over de juiste machtigingen beschikt. Dit betekent dat er minimaal Contributor-rechten nodig zijn op het niveau van de resourcegroep of het opslagaccount, of Storage Account Contributor-rechten specifiek voor opslagaccounts. Voor tenantbrede implementaties is het aanbevolen om deze configuratie uit te voeren met een account dat over Tenant Administrator-rechten beschikt of via Azure Policy voor geautomatiseerde implementatie. Een andere belangrijke vereiste is de beschikbaarheid van Azure PowerShell-modules of de Azure CLI voor geautomatiseerde implementaties. Voor handmatige implementaties via de Azure Portal is alleen een webbrowser en toegang tot de Azure Portal nodig. Het is aanbevolen om de nieuwste versie van de Az.Storage PowerShell-module te gebruiken voor de meest actuele functionaliteit en beveiligingsupdates. Voor organisaties die gebruik maken van Infrastructure as Code (IaC) zoals ARM-templates, Bicep, of Terraform, is het belangrijk dat deze templates worden bijgewerkt om ervoor te zorgen dat nieuwe opslagaccounts automatisch worden geconfigureerd met AllowBlobPublicAccess ingesteld op false. Dit voorkomt dat nieuwe resources per ongeluk worden aangemaakt met onveilige standaardinstellingen. Ten slotte is het essentieel om een inventarisatie te maken van alle applicaties en services die mogelijk gebruik maken van publieke blob-URL's voordat de maatregel wordt geïmplementeerd. Dit helpt bij het identificeren van potentiële impact en het plannen van benodigde wijzigingen aan applicaties die mogelijk moeten worden bijgewerkt om authenticatie te gebruiken in plaats van anonieme toegang.

Monitoring

Gebruik PowerShell-script blob-anonymous-access-disabled.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van de AllowBlobPublicAccess-configuratie is een kritieke activiteit om ervoor te zorgen dat anonieme toegang tot blob-containers daadwerkelijk is uitgeschakeld en blijft uitgeschakeld. Regelmatige monitoring voorkomt dat configuratiewijzigingen per ongeluk worden teruggedraaid of dat nieuwe opslagaccounts worden aangemaakt met onveilige standaardinstellingen. Het monitoren van deze beveiligingscontrole moet worden geïntegreerd in de dagelijkse beveiligingsoperaties van de organisatie. De primaire monitoringactiviteit bestaat uit het controleren van de AllowBlobPublicAccess-eigenschap voor alle Azure Storage Accounts binnen de tenant. Dit kan worden uitgevoerd met behulp van het bijbehorende PowerShell-script dat systematisch alle opslagaccounts doorloopt en de status van deze configuratie-eigenschap verifieert. Het script genereert een rapport dat aangeeft welke accounts correct zijn geconfigureerd en welke mogelijk aandacht vereisen. Naast regelmatige controles is het belangrijk om proactieve monitoring in te stellen via Azure Policy of Azure Monitor. Azure Policy kan worden gebruikt om automatisch te detecteren wanneer een opslagaccount wordt aangemaakt of gewijzigd met AllowBlobPublicAccess ingesteld op true, en kan automatisch corrigerende acties ondernemen of waarschuwingen genereren voor het beveiligingsteam. Dit zorgt ervoor dat zelfs als een ontwikkelaar of beheerder per ongeluk een onveilige configuratie probeert toe te passen, dit onmiddellijk wordt gedetecteerd en gecorrigeerd. Azure Monitor kan worden geconfigureerd om waarschuwingen te genereren wanneer de configuratie wordt gewijzigd. Dit kan worden bereikt door Activity Log-alerts in te stellen die specifiek monitoren op wijzigingen aan de AllowBlobPublicAccess-eigenschap. Wanneer een dergelijke wijziging wordt gedetecteerd, ontvangt het beveiligingsteam onmiddellijk een melding zodat zij kunnen onderzoeken wie de wijziging heeft doorgevoerd en waarom, en indien nodig corrigerende maatregelen kunnen nemen. Voor organisaties die gebruik maken van compliance-frameworks zoals ISO 27001 of de BIO-normen, is het belangrijk om auditlogboeken bij te houden van alle monitoringactiviteiten. Dit betekent dat de resultaten van regelmatige controles moeten worden gedocumenteerd en bewaard voor auditdoeleinden. Het PowerShell-script kan worden uitgebreid om automatisch rapporten te genereren die kunnen worden opgeslagen in een gecentraliseerd loggingsysteem. Ten slotte moet monitoring ook rekening houden met de detectie van bestaande publieke containers, zelfs nadat AllowBlobPublicAccess is uitgeschakeld. Hoewel nieuwe publieke containers niet meer kunnen worden aangemaakt wanneer deze instelling is uitgeschakeld, kunnen bestaande containers die al publiek waren voordat de maatregel werd geïmplementeerd, mogelijk nog steeds toegankelijk zijn. Het is daarom belangrijk om periodiek te controleren of er containers zijn met publieke toegang en deze indien nodig te corrigeren.

Compliance en Auditing

Het uitschakelen van anonieme toegang tot Azure Blob Storage-containers is een fundamentele beveiligingsmaatregel die vereist is voor compliance met meerdere belangrijke beveiligings- en privacyframeworks die relevant zijn voor Nederlandse overheidsorganisaties en bedrijven. Deze maatregel draagt direct bij aan het voldoen aan verschillende controle-eisen en helpt organisaties om te demonstreren dat zij passende technische en organisatorische maatregelen hebben genomen om gegevens te beschermen. Voor de CIS Azure Foundations Benchmark is deze maatregel expliciet vereist onder controle 3.7 op Niveau 1. De CIS Benchmark is een internationaal erkende set van beveiligingsaanbevelingen die zijn ontwikkeld door het Center for Internet Security. Controle 3.7 specificeert dat anonieme toegang tot blob-containers moet worden uitgeschakeld om te voorkomen dat gevoelige gegevens per ongeluk publiek toegankelijk worden gemaakt. Niveau 1 controles zijn basisbeveiligingsmaatregelen die alle organisaties zouden moeten implementeren, ongeacht hun grootte of complexiteit. Het niet implementeren van deze controle resulteert in een niet-conforme status voor de CIS Azure Foundations Benchmark, wat kan leiden tot problemen tijdens externe audits of beveiligingsbeoordelingen. Voor Nederlandse overheidsorganisaties is compliance met de Baseline Informatiebeveiliging Overheid (BIO) verplicht. Deze maatregel draagt bij aan het voldoen aan BIO-controle 11.02, die betrekking heeft op toegangscontrole en authenticatie. De BIO vereist dat organisaties passende maatregelen nemen om ervoor te zorgen dat alleen geautoriseerde personen toegang hebben tot informatie en informatiesystemen. Door anonieme toegang uit te schakelen, wordt ervoor gezorgd dat alle toegang tot blob-containers wordt gecontroleerd via authenticatiemechanismen, wat direct bijdraagt aan het voldoen aan deze controle-eis. De ISO 27001:2022-standaard voor informatiebeveiligingsmanagementsystemen bevat controle A.5.15, die betrekking heeft op toegangscontrole. Deze controle vereist dat organisaties toegangsrechten en -beperkingen definiëren en toepassen voor gebruikers, externe partijen en systemen. Het uitschakelen van anonieme toegang is een concrete implementatie van deze controle-eis, omdat het ervoor zorgt dat toegang tot gegevens wordt beperkt tot geautoriseerde gebruikers en systemen. Voor organisaties die gecertificeerd zijn volgens ISO 27001 of die streven naar certificering, is het kunnen aantonen dat anonieme toegang is uitgeschakeld een belangrijk onderdeel van de auditdocumentatie. Vanuit het perspectief van de Algemene Verordening Gegevensbescherming (AVG) draagt deze maatregel bij aan het voldoen aan Artikel 32, dat vereist dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens te beschermen. Anonieme toegang tot blob-containers kan leiden tot onbedoelde blootstelling van persoonsgegevens, wat een schending van de AVG zou kunnen vormen. Door anonieme toegang uit te schakelen, wordt een belangrijke technische maatregel geïmplementeerd die helpt om te voorkomen dat persoonsgegevens onbedoeld toegankelijk worden voor onbevoegden. Dit is vooral belangrijk voor organisaties die persoonsgegevens verwerken, omdat een datalek als gevolg van onbeveiligde publieke containers kan leiden tot aanzienlijke boetes van de Autoriteit Persoonsgegevens, die kunnen oplopen tot €20 miljoen of 4% van de wereldwijde jaaromzet. Voor auditdoeleinden is het belangrijk om documentatie bij te houden die aantoont dat deze maatregel is geïmplementeerd en actief wordt gemonitord. Dit omvat configuratieschermafbeeldingen, uitvoer van PowerShell-scripts die de configuratie verifiëren, en logboeken van regelmatige controles. Deze documentatie moet worden bewaard voor de vereiste bewaartermijn zoals gespecificeerd in het auditbewijsgedeelte van deze maatregel, wat in dit geval zeven jaar is. Regelmatige audits moeten worden uitgevoerd om te verifiëren dat de configuratie correct blijft en dat er geen opslagaccounts zijn met anonieme toegang ingeschakeld.

Remediatie

Gebruik PowerShell-script blob-anonymous-access-disabled.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoringactiviteiten aangeven dat een Azure Storage Account AllowBlobPublicAccess heeft ingesteld op true, moet onmiddellijk corrigerende actie worden ondernomen om de beveiligingsrisico's te elimineren. De remediatieprocedure moet systematisch worden uitgevoerd om ervoor te zorgen dat alle opslagaccounts correct worden geconfigureerd en dat eventuele impact op bestaande applicaties wordt geminimaliseerd. De primaire remediatieactie bestaat uit het uitschakelen van anonieme toegang door de AllowBlobPublicAccess-eigenschap in te stellen op false. Dit kan worden uitgevoerd met behulp van het bijbehorende PowerShell-script dat automatisch alle niet-conforme opslagaccounts identificeert en corrigeert. Het script maakt gebruik van de Set-AzStorageAccount-cmdlet met de parameter -AllowBlobPublicAccess $false om de configuratie te wijzigen. Voor handmatige remediatie kan deze wijziging ook worden doorgevoerd via de Azure Portal door te navigeren naar het opslagaccount, de Configuration-sectie te openen, en de 'Allow Blob public access'-instelling te wijzigen naar 'Uitgeschakeld'. Voordat remediatie wordt uitgevoerd, is het belangrijk om een impactanalyse uit te voeren om te identificeren welke applicaties of services mogelijk afhankelijk zijn van publieke blob-toegang. Dit kan worden gedaan door te zoeken naar gebruik van publieke blob-URL's in applicatiecode, configuratiebestanden, of door te monitoren op HTTP 401-fouten na het uitschakelen van anonieme toegang. Applicaties die publieke blob-URL's gebruiken, moeten worden bijgewerkt om authenticatie te gebruiken voordat de remediatie wordt toegepast, of er moeten alternatieve oplossingen worden geïmplementeerd zoals SAS-tokens met vervaldatums of Azure CDN met origin-authenticatie. Na het uitschakelen van anonieme toegang op accountniveau worden bestaande containers die eerder publiek waren gemaakt automatisch privé zonder gegevensverlies. Dit betekent dat de gegevens zelf niet worden gewijzigd of verwijderd, maar dat de toegangsmethode wordt gewijzigd. Applicaties die deze containers proberen te benaderen zonder authenticatie zullen HTTP 401 Unauthorized-fouten ontvangen, wat aangeeft dat authenticatie vereist is. Voor organisaties die gebruik maken van Infrastructure as Code, moet de remediatie ook worden toegepast op de onderliggende templates of configuratiebestanden. Dit voorkomt dat toekomstige deployments opnieuw opslagaccounts aanmaken met onveilige standaardinstellingen. ARM-templates, Bicep-bestanden, of Terraform-configuraties moeten worden bijgewerkt om ervoor te zorgen dat AllowBlobPublicAccess standaard wordt ingesteld op false voor alle nieuwe opslagaccounts. Na het uitvoeren van de remediatie moet verificatie worden uitgevoerd om te bevestigen dat de wijziging succesvol is toegepast. Dit kan worden gedaan door het monitoring-script opnieuw uit te voeren en te verifiëren dat alle opslagaccounts nu AllowBlobPublicAccess hebben ingesteld op false. Daarnaast moet worden gemonitord op eventuele applicatiefouten of service-onderbrekingen die kunnen optreden als gevolg van de wijziging, zodat deze snel kunnen worden opgelost. Voor continue bescherming moet Azure Policy worden geconfigureerd om automatisch te voorkomen dat nieuwe opslagaccounts worden aangemaakt met AllowBlobPublicAccess ingesteld op true, of om automatisch corrigerende acties uit te voeren wanneer een dergelijke configuratie wordt gedetecteerd. Dit zorgt ervoor dat de beveiligingsmaatregel proactief wordt gehandhaafd zonder dat handmatige interventie nodig is voor elke nieuwe resource.

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 Blob Anonymous Access Disabled .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.3 Controleert of anonieme blob toegang is uitgeschakeld. .NOTES Filename: blob-anonymous-access-disabled.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.3 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Blob Anonymous Access Disabled" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue $result = @{ TotalAccounts = $storageAccounts.Count; AnonymousDisabled = 0 } foreach ($account in $storageAccounts) { if ($account.AllowBlobPublicAccess -eq $false) { $result.AnonymousDisabled++ } } 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 Storage Accounts: $($r.TotalAccounts)" -ForegroundColor White Write-Host "Anonymous Access Disabled: $($r.AnonymousDisabled)" -ForegroundColor $(if ($r.AnonymousDisabled -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nAnonymous Access Disabled: $($r.AnonymousDisabled)/$($r.TotalAccounts) accounts" } } 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 Storage Accounts: $($r.TotalAccounts)" -ForegroundColor White Write-Host "Anonymous Access Disabled: $($r.AnonymousDisabled)" -ForegroundColor $(if ($r.AnonymousDisabled -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nAnonymous Access Disabled: $($r.AnonymousDisabled)/$($r.TotalAccounts) accounts" } } 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
Critical: Publieke blob-toegang is de nummer één oorzaak van cloud datalekken. Capital One en Accenture datalekken zijn hier voorbeelden van. Compliance: CIS 3.7, AVG. Het risico is KRITIEK.

Management Samenvatting

Alternatieve verificatie voor anonieme blob-toegang. Zie public-blob-access-disabled.json voor volledige implementatie (AllowBlobPublicAccess=false). Verplicht CIS 3.7.