L1 BIO 11.02.01 ISO A.5.15 CIS 3.7

Public Blob Access Volledig Uitgeschakeld Op Opslagaccount Niveau

📅 2025-10-30
•
⏱️ 8 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Het structureel uitschakelen van openbare blobtoegang op het niveau van het opslagaccount vormt een harde veiligheidsbarriere die menselijke fouten absorbeert voordat data zichtbaar wordt op internet. Wanneer de instelling AllowBlobPublicAccess permanent op false staat, kan geen enkele ontwikkelaar, beheerder of geautomatiseerd proces per ongeluk een container delen met anonieme gebruikers. De maatregel werkt onafhankelijk van containerinstellingen en forceert elke lees- of schrijfbewerking via geauthenticeerde kanalen zoals Azure AD, SAS of gedeelde sleutels. Dit voorkomt dat backups, logbestanden, broncode of persoonsdossiers die tijdelijk in een werkmap staan, uitgroeien tot een nieuw datalek. Voor organisaties in de publieke sector, waar gevoeligheid en wettelijke verplichtingen samenkomen, betekent dit dat elk opslagaccount standaard het principe "privaat tenzij expliciet gepubliceerd via een gecontroleerd platform" volgt. Naast het afschermen van gegevens creeert de instelling duidelijkheid: securityteams hoeven niet langer duizenden containers na te lopen op zoek naar uitzonderingen, maar bewaken slechts een eigenschap per account. Dat reduceert beheerkosten, verkleint de kans op menselijke vergissingen en legt een aantoonbaar bewijs vast richting auditors en toezichthouders.

Aanbeveling
Implementeer
Risico zonder
Critical
Risk Score
10/10
Implementatie
2u (tech: 1u)
Van toepassing op:
✓ Azure opslag
✓ blob opslag
✓ Azure opslagaccounts

Azure Blob Storage lijkt onschuldig omdat een container met een klik gedeeld kan worden, maar in de praktijk veroorzaakt die knop een van de meest voorkomende clouddatalekken. Zodra een container anoniem leesbaar is, kan elke zoekmachine, crawler of kwaadwillende het volledige pad indexeren, inclusief configuratiebestanden, geheimen en persoonsinformatie. De afgelopen jaren zijn meerdere voorbeelden opgedoken waarbij Nederlandse gemeenten, internationale consultancybedrijven en cloudleveranciers miljoenen documenten kwijtraakten doordat een proefopstelling nooit is teruggezet naar prive. Het patroon is steeds hetzelfde: een ontwikkelaar activeert tijdelijk public access om een testbestand te delen, vergeet dit terug te draaien en binnen enkele uren is de url opgedoken in openbare lijsten. Omdat Azure standaard geen waarschuwing geeft wanneer een container plotseling van privaat naar openbaar gaat, valt dit vaak pas op nadat derden de data hebben gedownload of zoekmachines caches hebben gemaakt. Voor instellingen die onder de AVG, BIO en NIS2 vallen, vormt dit een dubbele dreiging: enerzijds directe reputatieschade richting burgers en ketenpartners, anderzijds formele meldplichten, boetes en forensische onderzoeken. Door op accountniveau de poort dicht te zetten verdwijnen al deze scenario's, omdat zelfs een onoplettende beheerder de blokkade niet kan omzeilen zonder bewuste wijziging op het hoogste niveau en bijbehorende logging.

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

Implementatie

De control configureert de eigenschap AllowBlobPublicAccess op elk Azure opslagaccount en houdt deze permanent op false, ongeacht of het account wordt gebruikt voor algemene workloads, data lakes of logarchieven. Wanneer de eigenschap op false staat, behandelen alle containers binnen het account anonieme verzoeken automatisch als verboden en dwingt het platform iedere client om zich te authenticeren via Azure AD, SAS, opslagsleutels of beheerde identiteiten. Het configureren gebeurt eenmalig per account maar kan via verschillende kanalen, zoals de Azure Portal, PowerShell (Set-AzStorageAccount -AllowBlobPublicAccess $false), Azure CLI (az storage account update --allow-blob-public-access false) of declaratief in ARM- en Bicep-sjablonen door properties.allowBlobPublicAccess op false te zetten. Best practices schrijven voor om deze instelling direct in het deployproces op te nemen, zodat nieuwe accounts nooit publiek kunnen worden en afwijkingen via Azure Policy automatisch worden afgewezen of hersteld. Voor scenario's waar publieke distributie nodig blijft, bijvoorbeeld voor statische websites of downloadportalen, adviseert de control om dedicated accounts te gebruiken die geen gevoelige data bevatten en waar aanvullende lagen zoals Front Door, CDN of Web Application Firewall het verkeer inspecteren. Zo blijft de hoofdomgeving van gevoelige workloads hermetisch gesloten, worden uitzonderingen traceerbaar vastgelegd en kunnen auditors aan de hand van beleidsrapportages controleren dat de maatregel consequent wordt toegepast.

Vereisten

Een robuuste uitvoering begint met een volledige inventarisatie van alle opslagaccounts binnen de tenant, inclusief tijdelijke projectomgevingen en vergeten labomgevingen. Voor elk account wordt vastgelegd welke workloads erop draaien, welke data-classificatie van toepassing is en of er historische incidenten zijn geweest met gedeelde containers. Deze inventarisatie vormt de basis voor het risicoprofiel: accounts met persoonsinformatie, strafrechtelijke gegevens of vertrouwelijke beleidsdocumenten krijgen een hogere prioriteit dan accounts met publieke brochures. Door de inventarisatie direct te verrijken met abonnement, resourcegroep, eigenaar en contactpersoon kan het securityteam later snel schakelen wanneer er vragen ontstaan over uitzonderingen of verstoringen.

Naast inventarisatie moet de organisatie formaliseren welke rollen en bevoegdheden noodzakelijk zijn voor de wijziging. Minimaal zijn de Azure-rollen Owner of Storage Account Contributor vereist, aangevuld met toegang tot de centrale beheeraccounts in Azure AD om scripts veilig uit te voeren. In overheidscontext worden wijzigingen bij voorkeur uitgevoerd door een controleerbaar duo: een beheerder voert de opdracht uit, een tweede persoon valideert de instelling via logging of schermopnames. Deze segregatie van taken voorkomt dat een kwaadwillende de instelling later terugdraait zonder dat iemand het merkt, en sluit aan bij de eisen van de Baseline Informatiebeveiliging Overheid (BIO).

Technisch gezien vereist de maatregel dat beheerders beschikken over up-to-date tooling. PowerShell 7 met de modules Az.Accounts en Az.Storage, de laatste versie van Azure CLI en toegang tot het Azure Portal moeten vooraf zijn getest in een gecontroleerde omgeving. Verder moet er een veilige werkplek zijn met Conditional Access en meervoudige authenticatie zodat de verbindingssessies niet kunnen worden overgenomen. De organisatie documenteert bovendien welke netwerksegmenten opslagaccounts mogen beheren, welke firewallregels eventueel tijdelijk moeten worden geopend voor API-verkeer en hoe logging naar Log Analytics of Sentinel wordt gecontroleerd tijdens de wijziging.

Ook de organisatorische voorwaarden mogen niet ontbreken. Elke afdeling die blobs publiceerde voor het delen van bestanden krijgt vooraf een communicatiepakket waarin staat waarom de functionaliteit verdwijnt en hoe zij voortaan bestanden kunnen delen via goedgekeurde kanalen zoals SharePoint, OneDrive of een CDN. De communicatie bevat voorbeeldscenario's, contactgegevens van het cloudteam en een besluit van het bestuur dat de maatregel verplicht stelt voor alle productie- en ontwikkelomgevingen. Door deze afstemming ontstaat draagvlak en worden escalaties tijdens de implementatie geminimaliseerd.

Tot slot hoort bij de vereisten een grondig test- en acceptatiepad. Applicatie-eigenaren moeten controleren of hun integraties probleemloos overstappen naar geauthenticeerde verbindingen, bijvoorbeeld via Managed Identities of SAS-tokens met beperkte levensduur. Testcases beschrijven zowel succespad (applicatie leest en schrijft data) als foutpad (anonieme toegang levert een 403-fout) zodat objectief kan worden aangetoond dat de beveiliging werkt zonder bedrijfsprocessen te hinderen. Alle bevindingen worden vastgelegd in een change-dossier, aangevuld met een fallbackplan voor het geval een kritieke dienst onverwacht stopt. Wanneer deze randvoorwaarden zijn ingevuld, kan de organisatie met vertrouwen aan de technische uitvoering beginnen.

Implementeeratie

De uitvoering start met een forensisch nauwkeurige audit van de huidige situatie. Beheerders verzamelen per abonnement de lijst met opslagaccounts, lezen de bestaande instelling van AllowBlobPublicAccess uit en koppelen die informatie aan data-classificaties. Tijdens deze stap worden ook alle containers met toegangsniveaus Blob of Container in kaart gebracht, inclusief de toepassingen die deze containers gebruiken. Het doel is om te begrijpen welke afhankelijkheden bestaan voordat de blokkade wordt geactiveerd en om vast te leggen welke diensten mogelijk een alternatief publicatiekanaal nodig hebben. Zonder dit inzicht kan een plotselinge wijziging leiden tot uitval van data-delende ketens of integraties met externe leveranciers.

Gebruik PowerShell-script public-blob-access-Schakel uitd.ps1 (functie Invoke-Monitoring) – PowerShell-script dat opslagaccounts inventariseert, AllowBlobPublicAccess controleert en afwijkingen kan herstellen.

Het aangehaalde script draait vanuit een beheerwerkplek met Just-In-Time toegang tot de benodigde abonnementen. De uitvoerder logt in via Connect-AzAccount, zet de juiste context en laat het script per account de actuele waarde van AllowBlobPublicAccess controleren. Deviaties worden direct gemarkeerd en opgeslagen in een rapport met tijdstempel, resource-id en eigenaar. Wanneer het script de parameter -Remediate meekrijgt, zet het de instelling automatisch op false en schrijft het de wijziging naar Log Analytics. Hierdoor ontstaat een reproduceerbaar proces dat zowel monitoring als correctie afdekt en waarvan auditors eenvoudig de logbestanden kunnen opvragen.

Met de inventarisatie afgerond verschuift de aandacht naar legitieme publicatiebehoeften. Sommige teams gebruiken blobopslag om softwarepakketten, datasets of kennisbankartikelen te delen. Deze workloads worden geherhuisvest naar architecturen die publieke distributie ondersteunen zonder het hoofdsysteem open te zetten. Opties zijn onder meer Azure Front Door met private origin, een CDN dat blobs benadert via SAS-tokens of een dedicated opslagaccount in een isolatiesubscriptie. Het projectteam documenteert per workload welke oplossing wordt gekozen, welke beveiligingslaag daarboven komt (bijvoorbeeld WAF of DDoS-bescherming) en hoe de operationele beheerders toegang houden tot logging en metrics.

Vervolgens wordt per opslagaccount de instelling via het Azure Portal aangepast. De beheerder opent het account, navigeert naar Configuration, zoekt de optie "Allow Blob public access" en zet deze op Disabled. Vlak voor het opslaan controleert de beheerder of er lopende data-overdrachten zijn en informeert hij het toepassingsbeheer over het exacte wijzigingsmoment. Na het opslaan wordt een functionele test uitgevoerd: een eerder openbaar bekende blob-url wordt bezocht en moet een 403- of 401-code teruggeven. Deze stap wordt vastgelegd met een screenshot of een Azure Activity Log export, zodat de audittrail compleet is.

Voor bulkoperaties is automatisering noodzakelijk. Met PowerShell kan een pipeline worden opgesteld waarin Get-AzStorageAccount alle accounts ophaalt, waarna een Where-Object filter alleen de afwijkende exemplaren selecteert. Set-AzStorageAccount zet de eigenschap vervolgens op false en geeft de status terug. Een vergelijkbare aanpak bestaat voor Azure CLI met az account set en az storage account update. Door deze commando's te verpakken in een Azure DevOps release of GitHub Actions workflow kan de organisatie wijzigingen herhalen, plannen buiten kantooruren en de uitvoer automatisch publiceren naar een gedeeld rapportagedashboard.

Organisaties die Infrastructure as Code gebruiken, passen gelijktijdig hun sjablonen aan. In Bicep en ARM wordt properties.allowBlobPublicAccess standaard op false gezet, terwijl Terraform-configuraties de parameter allow_blob_public_access op false definieren. Ook beleidspakketten, bijvoorbeeld landing zones in Azure Policy of Blueprint-definities, krijgen een Update- of Deny-effect zodat afwijkende deployments al tijdens provisioning worden geblokkeerd. Door IaC en beleid synchroon te houden, voorkomt men dat toekomstige teams het oude, onveilige patroon kopieren.

De implementatie sluit af met governance. Elk gewijzigd account wordt opgenomen in een configuratieregister met de datum van aanpassing, de verantwoordelijke afdeling, eventuele uitzonderingen en een verwijzing naar het goedkeuringsbesluit. Dit register voedt de maandelijkse risk-review, waar security officers bevestigen dat er geen terugval is naar publieke toegang. Tevens worden Azure Monitor en Microsoft Defender voor Cloud uitgerust met aangepaste regels die een waarschuwing sturen zodra een activiteit wordt gedetecteerd die AllowBlobPublicAccess opnieuw op true probeert te zetten. Zo blijft de controle geborgd over de hele levenscyclus.

monitoring

Gebruik PowerShell-script public-blob-access-disabled.ps1 (functie Invoke-Monitoring) – PowerShell-script dat periodiek controleert of AllowBlobPublicAccess op false blijft en bevindingen registreert.

Monitoring begint bij een centrale telemetriestroom waarin zowel configuraties als toegangsgebeurtenissen worden verzameld. Het aangewezen script draait wekelijks of dagelijks afhankelijk van de gevoeligheid van de data en schrijft de resultaten naar een Log Analytics workspace. Daarop draaien dashboards die per abonnement tonen welke accounts compliant zijn, wanneer de laatste controle plaatsvond en welke eigenaar verantwoordelijk is voor eventuele openstaande acties. Door de rapportage te combineren met data-classificaties ontstaat een prioriteitenlijst die direct zichtbaar maakt welke uitzonderingen onmiddellijk aandacht vragen.

Naast dashboards zijn real-time signalen nodig. Azure Policy compliance rapportages worden verbonden aan Action Groups die een waarschuwing sturen zodra een nieuw account wordt uitgerold zonder de juiste instelling. Microsoft Defender for Cloud levert aanvullende aanbevelingen: de ingebouwde controle "Storage account public access should be disallowed" wordt verplicht toegevoegd aan het Secure Score-programma en krijgt een lage ruisdrempel zodat het SOC de melding nooit overslaat. Event Grid events op het type Microsoft.Storage/storageAccounts/write worden gekoppeld aan een Logic App die direct controleert of de property AllowBlobPublicAccess tijdens de wijziging op true stond en, indien nodig, een incidentticket opent.

Compliance vereist dat uitzonderingen actief worden gevolgd. Elke uitzondering krijgt een vervaldatum en wordt opgenomen in een Power BI rapport waarin staat waarom de toegang tijdelijk nodig is, welke compenserende maatregelen zijn getroffen en wanneer de herbeoordeling plaatsvindt. Het monitoringproces checkt automatisch of de einddatum is bereikt en stuurt herinneringen naar zowel de data-eigenaar als het CISO-office. Wordt geen verlenging aangeleverd, dan start automatisch een runbook dat de instelling terugzet naar false en het resultaat aan het securityteam meldt.

Tot slot wordt monitoring periodiek getest door gecontroleerde aanvallen uit te voeren. Eens per kwartaal zet het cloudteam in een sandboxomgeving een proefaccount op true om te verifiëren of alle meldingen, dashboards en tickets daadwerkelijk worden geactiveerd. De resultaten worden besproken in het securityoverleg en leiden, indien nodig, tot verbeteringen zoals aanvullende logbronnen, meer context in meldingen of aangepaste escalatieroutes. Door de detectieketen actief te oefenen, blijft de organisatie paraat en wordt voorkomen dat de maatregel langzaam erodeert door stilte in de metrics.

Een volwassen monitoringsaanpak combineert bovendien toegangslogs met data-classificatieplatforms en DLP-oplossingen. Door Azure Storage logging te koppelen aan Microsoft Sentinel kunnen dreigingsjagers queries bouwen die anonieme of verdachte pogingen tot toegang onmiddellijk koppelen aan geopolitieke gebeurtenissen of aanmeldingen vanaf ongebruikelijke landen. Dezelfde dataset voedt machine-learningmodellen die afwijkende patronen herkennen, zoals een plotselinge piek in SAS-generatie of beheeracties buiten kantooruren. Elk gevonden patroon resulteert in een gedocumenteerde hypthese, een ingestelde jachtregel en een update van het kennisdossier, zodat de monitoringarchitectuur continu rijper wordt.

Remediatie

Gebruik PowerShell-script public-blob-access-disabled.ps1 (functie Invoke-Remediation) – PowerShell-script dat non-compliant opslagaccounts corrigeert, logging vastlegt en bewijsbestanden opslaat.

Wanneer monitoring een opslagaccount detecteert waarin AllowBlobPublicAccess onverwacht op true staat, wordt dit direct aangemerkt als een incident met prioriteit hoog. Het reageerteam beoordeelt binnen minuten of het account productiegegevens bevat, of er recente wijzigingen zijn aangevraagd en of er aanwijzingen zijn dat data al is uitgelezen. Indien de container publiek bereikbaar was, wordt het gedeelde endpoint onmiddellijk geblokkeerd door firewallregels of netwerkbeperkingen terwijl de wijziging wordt voorbereid. Tegelijkertijd worden toepassingsbeheerders geinformeerd zodat zij afhankelijkheden tijdelijk kunnen onderbreken of verkeer kunnen omleiden.

Het remediate-script dient als eerste technische maatregel. Vanuit een beveiligde beheerwerkplek voert het team het script uit met de functie Invoke-Remediation, waardoor het storageaccount op false wordt gezet, de configuratie wordt gevalideerd en er automatisch een logbestand in een onveranderbaar opslagaccount wordt opgeslagen. Het script vraagt eveneens om contextinformatie zoals incidentnummer, verantwoordelijke beheerder en reden van wijziging. Die metadata wordt meegeschreven naar het auditdossier, zodat later zichtbaar is wie welke actie heeft uitgevoerd.

Na de technische correctie volgt een grondige datakwalificatie. Het incidentteam inventariseert welke containers zich in het account bevonden, welke bestandssoorten erin staan en of er unieke persoons- of bedrijfsgegevens aanwezig waren. Logs van Storage Analytics, Content Delivery Networks en eventueel publieke mirrors worden veiliggesteld zodat kan worden bepaald of derden daadwerkelijk verbinding hebben gemaakt. Indien SAS-sleutels, gedeelde accountsleutels of clientsecretten mogelijk gelekt zijn, worden deze onmiddellijk ongeldig gemaakt en vervangen. Applicaties die deze sleutels gebruiken, krijgen een begeleide herconfiguratie om downtime te minimaliseren.

Omdat het vaak om gevoelige gegevens gaat, wordt parallel een communicatielijn opgezet. Het CISO-office beslist of het incident meldingsplichtig is richting Autoriteit Persoonsgegevens of andere toezichthouders binnen de Nederlandse overheid. Juridische adviseurs beoordelen contractuele verplichtingen richting leveranciers en ketenpartners. Belanghebbenden ontvangen een feitelijk rapport waarin staat welk datavolume mogelijk toegankelijk was, welke tegenmaatregelen zijn genomen en welke vervolgstappen worden verwacht van data-eigenaren, bijvoorbeeld aanvullende scans of het informeren van betrokken burgers. Deze gestructureerde communicatie voorkomt speculatie en versterkt het vertrouwen in het incidentproces.

Tijdens de nazorg wordt geleerd van het incident. Het projectteam analyseert welke processtap of technische voorziening heeft gefaald: ontbrak er een policy, werd een uitzonderingsaanvraag niet tijdig gesloten of was het script niet geïntegreerd in de CI/CD-pijplijn? Op basis van de root-cause wordt een verbeterplan opgesteld dat kan bestaan uit extra training, aangescherpte changeprocedures, het verplicht stellen van security reviews of het uitbreiden van geautomatiseerde tests. Elk verbeterpunt krijgt een eigenaar, een deadline en een meetbare uitkomst, zodat bestuurders kunnen volgen dat de organisatie daadwerkelijk beter wordt beschermd tegen herhaling.

Alle stappen worden afgesloten met uitgebreide documentatie in het centrale risicoregister. Het incidentrapport bevat verwijzingen naar de uitgevoerde scripts, screenshots van configuraties, hashwaarden van logbestanden en bewijzen van sleutelrotatie. Deze documenten worden minimaal zeven jaar bewaard, conform de bewaartermijn voor auditmateriaal binnen de Nederlandse publieke sector. Door het dossier meteen compleet te maken, is de organisatie in staat om tijdens externe audits of parlementaire vragen direct aan te tonen hoe snel en zorgvuldig is gereageerd.

Compliance en Auditing

De maatregel is rechtstreeks gekoppeld aan verschillende normenkaders. Onder CIS Azure Foundations Benchmark v3.0.0 adresseren we control 3.7, waarin expliciet staat dat het openbare toegangsniveau moet zijn uitgeschakeld voor alle opslagaccounts. De BIO vertaalt dit naar maatregel 11.02.01 over toegangsbeveiliging: alleen bevoegde gebruikers mogen bij data. ISO 27001:2022 A.5.15 en A.8.11 benadrukken dezelfde principes door toegangsrechten te beperken en vertrouwelijkheid te borgen. Door AllowBlobPublicAccess op false te forceren, legt de organisatie objectief vast dat deze normatieve eisen zijn vertaald naar concrete configuraties.

Auditors verwachten aantoonbaar bewijs. Daarom hoort bij deze control een set standaard artefacten: exporten uit Azure Policy die laten zien dat elk opslagaccount compliant is, PowerShell-rapportages met datumstempels en hashwaarden, screenshots van portalconfiguraties en een register van uitzonderingen met handtekeningen van de CISO of functionaris gegevensbescherming. Wanneer deze documenten centraal worden opgeslagen in een onveranderbare documentbibliotheek, kan de auditor steekproeven uitvoeren zonder extra werk voor het beheerteam. Bovendien maken deze stukken duidelijk dat de borging niet alleen op procesbeschrijvingen rust, maar daadwerkelijk op technisch afdwingbare instellingen.

Vanuit juridische optiek sluit de control aan op AVG-artikelen 5 en 32, die organisaties verplichten passende technische maatregelen te treffen om integriteit en vertrouwelijkheid te garanderen. Door het risico van onbevoegde openbaarmaking te minimaliseren, dalen de kans en impact van datalekken substantieel. De maatregel ondersteunt eveneens de verplichtingen uit NIS2 artikel 21, waar expliciet wordt gevraagd om sterke toegangscontrole en continue risicobeoordeling. Met een gedocumenteerde instelling en actief toezicht kan de organisatie aantonen dat zij deze richtlijnen serieus neemt en dat er een cyclisch verbeterproces is ingericht.

Dezelfde controledoelstelling komt terug in andere domeinen, zoals PCI-DSS requirement 1.3 en NIST CSF PR.AC-4, waarin staat dat directe publieke toegang tot systemen met kaartgegevens en kritieke assets verboden moet worden. Hoewel Azure Blob Storage niet altijd betaalkaartdata bevat, laat het aantonen van deze maatregel zien dat de organisatie een uniforme visie hanteert: ieder platform, ongeacht het type data, krijgt dezelfde strenge basisbeveiliging. Dit voorkomt discussies over dubbel beleid en maakt het eenvoudiger om multi-compliance programma's te onderhouden.

Om compliant te blijven, is het essentieel om wijzigingen in de normenkaders te volgen. Het cloudteam plant halfjaarlijks een review waarin wordt bekeken of er nieuwe versies van CIS, BIO-profielen of Microsoft-beleidsregels zijn verschenen die aanvullende logging, langere bewaartermijnen of andere configuraties vereisen. Bevindingen uit deze review worden vertaald naar backlog-items en, indien nodig, naar updates van scripts en documentatie. Zo blijft de control niet een momentopname, maar een levend onderdeel van het totale informatiebeveiligingsmanagementsysteem.

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 Blob Access Disabled .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.17 Controleert of public blob access is uitgeschakeld. .NOTES Filename: public-blob-access-disabled.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.17 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Public Blob 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; PublicAccessDisabled = 0 } foreach ($account in $storageAccounts) { if ($account.AllowBlobPublicAccess -eq $false) { $result.PublicAccessDisabled++ } } 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 "Public Access Disabled: $($r.PublicAccessDisabled)" -ForegroundColor $(if ($r.PublicAccessDisabled -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nPublic Access Disabled: $($r.PublicAccessDisabled)/$($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 "Public Access Disabled: $($r.PublicAccessDisabled)" -ForegroundColor $(if ($r.PublicAccessDisabled -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nPublic Access Disabled: $($r.PublicAccessDisabled)/$($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: Het open laten van public blob access is een directe route naar dataverlies. Een enkele container die per ongeluk publiek wordt gezet, kan binnen minuten door zoekmachines worden geïndexeerd, waarna logbestanden, broncode, persoonsgegevens en sleutelmateriaal voor altijd buiten de organisatie circuleren. Voor instellingen die onder de AVG, BIO en NIS2 vallen leidt dit tot verplichte meldingen, dure forensische onderzoeken, bestuurlijke boetes en langdurig reputatieherstel. Daarnaast dwingt elk incident tot het vervangen van sleutels en tokens in tal van applicaties, wat tientallen uren productietijd kost. Door AllowBlobPublicAccess niet af te dwingen, accepteert de organisatie dus bewust een hoog risico op financiële schade, juridische claims en verlies van vertrouwen bij burgers en ketenpartners.

Management Samenvatting

Forceer AllowBlobPublicAccess = false op ieder opslagaccount, migreer legitieme publieke scenario's naar gecontroleerde kanalen zoals CDN of Front Door en borg naleving via scripts, beleid en monitoring; zo verdwijnen spontane datalekken en voldoen we aantoonbaar aan CIS, BIO, AVG en NIS2.