Azure Opslag Security Design (Blob, File, Queue, Table)

Azure-opslagaccounts vormen het zenuwstelsel van applicaties: ze bevatten back-ups, diagnostische logboeken, wachtrijberichten voor integraties en statische webinhoud die burgers rechtstreeks kunnen raadplegen. Wanneer deze omgevingen onvoldoende zijn afgeschermd, leiden lekke containers, onderschepte HTTP-verzoeken of gelekte toegangssleutels onmiddellijk tot gegevensdiefstal, sabotage van processen en hoge meldingskosten op grond van de AVG. Door per account de zakelijke context, de gegevensclassificatie en de afhankelijkheid van publieke endpoints vast te leggen, kan het securityteam de juiste maatregelen koppelen aan de juiste omgeving en aantonen dat maatregelen in lijn zijn met BIO en ISO 27001.

Implementatie

Dit ontwerp combineert technische en organisatorische maatregelen: standaardversleuteling met eventueel klantbeheerde sleutels in Key Vault, netwerkisolatie via privé-eindpunten en streng ingestelde firewalls, Azure AD-gestuurde toegangscontrole en governance voor access keys en SAS-tokens, aangevuld met Defender for Storage, uitgebreide logging richting Log Analytics en herstelmechanismen zoals soft delete, versiebeheer en immutability policies.

Vereisten

1. Elke organisatie begint met een grondige inventarisatie van alle Azure-opslagaccounts, inclusief de bijbehorende containers, file shares, wachtrijen en tabellen, zodat duidelijk wordt welke workloads, tenant-afdelingen en gegevensclassificaties worden bediend en welke afhankelijkheden bestaan van andere platformdiensten zoals Azure Functions, Logic Apps of third-party integraties. Deze basisregistratie vormt de input voor het risicoprofiel en bepaalt welke maatregelen prioriteit krijgen.
2. Versleuteling van opgeslagen data wordt verplicht gesteld via Azure Storage Service Encryption met minstens AES-256, waarbij teams documenteren of Microsoft-beheerde sleutels volstaan of dat klantbeheerde sleutels in Azure Key Vault nodig zijn voor sectorspecifieke eisen; sleutelrotatie- en loggingprocedures worden gekoppeld aan het bredere cryptobeheerbeleid en blijven traceerbaar voor audits.
3. Het beleid voor veilige overdracht activeert Secure transfer required op elk account, blokkeert expliciet HTTP-verzoeken, vergrendelt de minimum TLS-versie op 1.2 en test applicaties en integraties op compatibiliteit. Daarnaast worden firewalllogboeken gecontroleerd op overtredingen zodat misconfiguraties direct worden hersteld en lessons learned in het changeproces terechtkomen.
4. Anonieme toegang tot Blob-containers wordt structureel verboden door AllowBlobPublicAccess uit te schakelen, gedeelde content te migreren naar Azure CDN of statische website-accounts met streng beheer en door in het change management-proces een expliciete toets op publieke exposure op te nemen zodat tijdelijk delen niet ongemerkt blijvend wordt.
5. Netwerksegmentatie wordt afgedwongen met privé-eindpunten per kritieke workload, gekoppeld aan subnets met Network Security Groups en centrale logging. Indien publieke endpoints noodzakelijk zijn, gelden restrictieve firewallregels op bron-IP, service tags en threat-intelligence signalen en wordt documentatie toegevoegd aan het architectuurdossier.
6. Authenticatie verloopt primair via Azure AD en Role Based Access Control zodat beheeracties kunnen worden voorzien van voorwaardelijke toegang, Privileged Identity Management en audittrails. Alleen in uitzonderingen worden account- of shared keys gebruikt; deze worden in Key Vault afgeschermd met strikte just-in-time procedures.
7. Microsoft Defender for Storage is standaard ingeschakeld op elk account en geïntegreerd met Microsoft Sentinel of de centrale SIEM, zodat malwaredetectie, ongebruikelijke gegevensoverdrachten en afwijkende locatiepatronen automatisch leiden tot waarschuwingen, ticketcreatie en waar nodig automatische isolatie van het betrokken account.
8. Soft delete voor blobs, containers, file shares en wachtrijen krijgt een bewaartermijn van minimaal dertig dagen, gecombineerd met versiebeheer en immutable opslag, zodat ransomware-aanvallen of foutieve scripts geen onherstelbare schade veroorzaken. De lifecycle policies beschrijven hoe hersteltests periodiek worden uitgevoerd en vastgelegd.
9. Beleid voor toegangssleutels schrijft voor dat primary en secondary keys elk kwartaal worden vernieuwd, dat rotatie wordt geautomatiseerd via PowerShell of Azure Automation, dat uitsluitsels worden goedgekeurd door de security officer en dat logging aantoont welke applicaties tijdig naar de nieuwe sleutel zijn overgezet.
10. Shared Access Signatures worden alleen uitgegeven door geautoriseerde beheerders via centraal beheerde templates met beperkte permissies, IP-filters en tijdsvensters van hoogstens vierentwintig uur; alle SAS-acties worden gelogd in Azure Monitor en gekoppeld aan externe leverancierscontracten zodat naleving van bewaartermijnen en privacyafspraken kan worden vastgesteld.

Implementatie

Start het traject met een ontwerpworkshop waarin solution architects, storagebeheerders en security officers gezamenlijk de scope bepalen. Zij verzamelen per opslagaccount de gegevensclassificatie, de gekoppelde applicaties, de vereiste beschikbaarheid en eventuele compliance-eisen zoals BIO 10.01 of specifieke AVG-gronden. Deze inventarisatie wordt vastgelegd in het architectuurdossier en vormt de basis voor een beslisboom die aangeeft welke accounts klantbeheerde sleutels vereisen, welke workloads binnen private netwerken moeten blijven en welke uitzonderingen tijdelijk mogen afwijken mits er een expliciete einddatum en goedkeuring is geregistreerd. Vervolgens configureert het team elk opslagaccount via Azure Policy en Infrastructure as Code. Secure transfer required wordt aangezet, AllowBlobPublicAccess wordt uitgezet en de minimale TLS-versie wordt ingesteld op 1.2 of hoger. Indien een workload publiek bereik nodig heeft, worden firewallregels beperkt tot bekende IP-ranges en worden diagnostische logboeken voor StorageRead, StorageWrite en StorageDelete naar een centrale Log Analytics-werkruimte gestuurd. Voor kritieke omgevingen maken beheerders privé-eindpunten aan in toegewezen subnets, koppelen zij Network Security Groups met strikte uitgaande regels en testen zij via Azure Private DNS of de naamresolutie correct naar het privé-IP verwijst. Voor versleuteling kiezen organisaties standaard voor Microsoft-beheerde sleutels, maar voor persoonsgegevens met een hoog profiel wordt Customer-Managed Keying ingericht. Key Vault-beheerders maken sleutelversies aan, activeren purge protection en configureren Managed Identities op de opslagaccounts zodat sleutelvernieuwing niet afhankelijk is van statische geheimen. Tegelijkertijd wordt Azure AD-autorisatie geactiveerd voor zowel data plane- als managementfuncties. Role assignments worden opgeschoond zodat alleen groepen met least privilege overblijven, terwijl Privileged Identity Management ervoor zorgt dat tijdelijke hogere rollen automatisch verlopen. Shared keys blijven beschikbaar voor noodgevallen, maar worden opgeslagen in Key Vault met toegangsbeleid op basis van just-in-time requests. SAS-beheer wordt geautomatiseerd via een GitOps-achtige workflow. Templates beschrijven exact welke resource types, permissies, netwerkfilters en tijdsduur zijn toegestaan. Wanneer een team een SAS nodig heeft, dient het een pull request in waarin ook wordt vastgelegd voor welke dataset en welke externe partij de toegang geldt. Een Azure Function genereert de SAS pas na goedkeuring door security en registreert de parameters in Application Insights. Voor databescherming worden soft delete, versiebeheer en immutable storage policies via Azure Resource Graph gecontroleerd, zodat afwijkingen onmiddellijk zichtbaar zijn en binnen het change window kunnen worden hersteld. Tijdens de implementatiefase wordt Microsoft Defender for Storage geactiveerd en gekoppeld aan Microsoft Sentinel, waarin analytics rules ongebruikelijke downloads, grote hoeveelheden deletions of onverwachte datacenters signaleren. Het script azure-storage-security.ps1 voert een geautomatiseerde validatie uit van ruim honderd configuratie-instellingen en publiceert de resultaten naar het projectdashboard. Tot slot organiseert het team een gecontroleerde failover- en hersteloefening: accounts worden tijdelijk geïsoleerd, herstel vanuit soft delete wordt getest en de logging wordt beoordeeld door de auditafdeling. Pas wanneer al deze stappen zijn vastgelegd in de operationele runbooks, wordt het opslagaccount als compliant aangemerkt.

Compliance en Auditing

Het beveiligingsontwerp sluit direct aan op de Baseline Informatiebeveiliging Overheid en ISO 27001 en vormt tevens bewijs voor PCI-DSS 4.0 requirement 3. Voor BIO 10.01, dat encryptiebeheer voorschrijft, documenteren we dat Azure Storage Service Encryption altijd is ingeschakeld, dat sleutelmaterialen in Key Vault worden beheerd met ingeschakelde purge protection en dat sleutelrotatie minstens jaarlijks wordt getest. Auditrapporten bevatten screenshots van de configuratie, exporten van Azure Policy compliance en change records waaruit blijkt wanneer sleutels zijn vernieuwd, wie de goedkeuring heeft verleend en welke controledoelen daarmee zijn afgedekt. BIO 13.02 vereist veilige netwerkdiensten en logging van overdrachten. Daarom tonen we per opslagaccount de configuratie van privé-eindpunten, de toegepaste firewallregels en eventuele uitzonderingen inclusief risicoanalyse en einddatum. De audittrail bevat een maandelijkse rapportage uit Azure Resource Graph waarin de status van AllowBlobPublicAccess, MinimumTlsVersion en Secure transfer required wordt vastgelegd, zodat achteraf aantoonbaar is dat configuraties niet ongemerkt zijn gewijzigd. Deze datasets worden gekoppeld aan het netwerksegmentatiebeleid en de changekalender van de organisatie, waarmee de relatie tussen ontwerpkeuzes en operationele controles wordt onderbouwd. ISO 27001-controle A.8.24 benadrukt cryptografie. Hier documenteren we de volledige key management lifecycle: aanmaak, sleutelvernieuwing, intrekking en logging. Omdat Azure Storage versleuteling afdwingt, verschuift de aandacht naar governance: wie mag de encryptieconfiguratie aanpassen, hoe worden wijzigingen beoordeeld en hoe garanderen we dat sleutelbeleid in lijn blijft met NCSC-richtlijnen. Voor controle A.13.2.1 leveren we netwerkdiagrammen waarin privé-eindpunten, Network Security Groups, route tables en ExpressRoute/VPN-koppelingen zichtbaar zijn, inclusief verwijzingen naar change records. Ook leggen we vast hoe Azure Policy-deny regels voorkomen dat onbevoegden deze instellingen wijzigen, waarmee scheiding der taken aantoonbaar is. De AVG (Artikel 32) vraagt om passende technische en organisatorische maatregelen en stelt eisen aan integriteit, vertrouwelijkheid en beschikbaarheid. Het dossier bevat daarom testresultaten van soft delete- en immutability-herstel, rapportages uit Microsoft Defender for Storage over blokkades van verdachte uploads en een beschrijving van het proces waarmee data subject requests worden beantwoord door logbestanden te correleren met Microsoft Purview Audit. Door het combineren van Azure Monitor-logs met Purview-audits kan de organisatie laten zien welke identiteiten gegevens hebben ingezien en of er uitzonderlijke downloads plaatsvonden, wat essentieel is voor de Meldplicht Datalekken. Om audits te versnellen bouwen we een vast bewijspakket dat direct door interne en externe auditors kan worden gebruikt. Het pakket bevat de uitvoer van azure-storage-security.ps1, de Azure Policy compliance-samenvatting, exports van RBAC-roltoewijzingen, het logboek van SAS-uitgiften inclusief goedkeuringen en screenshots van de Defender-configuratie. Elk document krijgt een revisiestempel, een verwijzing naar het verantwoordelijke team en een bewaartermijn van zeven jaar. Auditors krijgen daarnaast toegang tot backlogtickets waarin afwijkingen zijn opgelost, inclusief bewijs van peer review en her-test, zodat naleving niet alleen op papier maar ook in de praktijk wordt aangetoond.

Monitoring

Gebruik PowerShell-script azure-storage-security.ps1 (functie Invoke-Monitoring) – De monitoringaanpak draait om het script azure-storage-security.ps1 dat in de modus Invoke-Monitoring draait op een geplande Azure Automation-runbook en lokaal kan worden gedebugd voordat het naar productie wordt gepusht. Het script leest via Azure Resource Graph alle opslagaccounts uit, controleert de status van beveiligingsinstellingen en vergelijkt die met de gewenste configuratie. Door de resultaten als JSON naar een Log Analytics workspace te sturen, ontstaat een uniforme dataset waarop dashboards, alerts en compliance-rapportages kunnen worden gebaseerd zonder handmatige intervallen. In de praktijk voert het script controles uit op secure transfer, minimum TLS-versies, AllowBlobPublicAccess, privé-eindpuntbindingen, firewallregels, soft delete, versiebeheer, immutability policies, SAS-configuraties en Defender-licenties. Voor elk controlepunt wordt een ernstniveau toegekend: kritieke afwijkingen creëren direct een incident in het ITSM-systeem, terwijl waarschuwingen in backlog-sprints terechtkomen. Via PowerShell-parameters kunnen teams bepalen of alleen productieomgevingen worden meegenomen of dat ook ontwikkelaccounts worden beoordeeld; lokale debug-instellingen zorgen ervoor dat ontwikkelaars het script kunnen testen zonder echte wijzigingen aan te brengen. Naast configuratiecontroles verzamelt de monitoringlaag runtime signalen. Azure Monitor diagnostische instellingen sturen StorageRead, StorageWrite en StorageDelete events naar Microsoft Sentinel, waar gebruik wordt gemaakt van ingebouwde threat detection regels en maatwerk-Kusto queries. De beschrijving bij deze scriptreferentie fungeert als runbook: operators valideren dagelijks of de query StorageAccountHighVolumeDeletion resultaten oplevert, controleren of Defender-waarschuwingen binnen vijf minuten worden verwerkt en vergelijken de metrics met afgesproken service level indicators voor detectiesnelheid. Rapportages worden wekelijks gedeeld met CISO-teams via Power BI dashboards die de uitvoer van azure-storage-security.ps1 combineren met Sentinel-incidenten. Elk dashboard bevat trendlijnen voor het aantal compliant accounts, gemiddelde time-to-detect en openstaande bevindingen per organisatie-eenheid. Tijdens kwartaalreviews worden deze cijfers gekoppeld aan compliance-objectieven; afwijkingen leiden tot verbeterplannen met duidelijke verantwoordelijken en deadlines. Dankzij tagging kan het dashboard onderscheid maken tussen workloads met persoonsgegevens, kritieke bedrijfsprocessen en experimentele sandboxes. Om de betrouwbaarheid van de monitoring te waarborgen, voert het team maandelijks een lokale debug-run uit waarin het script met de -Debug switch draait en resultaten naar een tijdelijke workspace schrijft. Deze oefening bevestigt dat codewijzigingen geen regressies introduceren en dat authenticatiemechanismen zoals Managed Identities correct werken. Daarnaast worden failover-scenario's getest waarbij logbestemmingen wegvallen; de monitoringoplossing schakelt dan over op Event Hubs zodat er geen datavacuüm ontstaat. Alle bevindingen worden vastgelegd in het operationele logboek en gedeeld met de securitycommunity binnen de organisatie, zodat kennis continu beschikbaar blijft..

Remediatie

Gebruik PowerShell-script azure-storage-security.ps1 (functie Invoke-Remediation) – Hetzelfde script azure-storage-security.ps1 bevat de functie Invoke-Remediation waarmee beheerteams gecontroleerd configuraties kunnen herstellen. Voorafgaand aan productiegebruik wordt de functie lokaal getest met debug-instellingen en een dry-runparameter die precies toont welke API-calls worden uitgevoerd. De beschrijving van deze scriptreferentie fungeert als handleiding: operators volgen het runbook waarin wordt uitgelegd welke machtigingen nodig zijn, hoe changes worden geregistreerd, hoe de uitkomst wordt vastgelegd in het configuratieregister en hoe role-based parameters ervoor zorgen dat iedere beheerder alleen die resourcegroepen kan aanpassen waarvoor hij bevoegd is. Wanneer een afwijking wordt gedetecteerd, bijvoorbeeld een opslagaccount zonder secure transfer, start het script met een validatiefase. Het haalt het huidige beleid op, controleert of er lopende deployments of platformonderhoud zijn en bepaalt of er afhankelijkheden bestaan met legacy-clients. Daarna wordt een herstelplan gegenereerd waarin exacte ARM-acties staan, inclusief parameterwaarden en verwachte impact. Het team beoordeelt dit plan, koppelt het aan een change ticket en voert het vervolgens uit met Invoke-Remediation, dat elke stap logt in zowel de console als een centrale storage queue voor auditdoeleinden. Indien het om een bedrijfskritieke omgeving gaat, vraagt het script automatisch bevestiging van een tweede operator zodat het vier-ogenprincipe uit het securitybeleid wordt afgedekt. Voor sleutelgerelateerde afwijkingen voert het script geautomatiseerde rotaties uit. Het maakt een nieuwe sleutelversie in Key Vault, wijst Managed Identities toe aan de opslagaccounts en valideert dat de applicatieconfiguraties zijn bijgewerkt voordat de oude sleutel wordt ingetrokken. Bij mislukte automatische updates wordt het herstel onderbroken en ontvangt het team een escalatie zodat handmatige validatie mogelijk is. Elk rotatieproces resulteert in een rapport dat aan het cryptobeheerteam wordt gestuurd, inclusief hashes van de sleutelversies en de exacte tijdstempels waarop applicaties opnieuw verbinding hebben gemaakt. Een vergelijkbaar patroon geldt voor SAS-uitgiften: het script kan verlopen tokens intrekken, nieuwe tokens genereren met strengere parameters en de betrokken externe partij informeren via vooraf gedefinieerde e-mailsjablonen. Netwerkafwijkingen worden met hetzelfde zorgniveau gecorrigeerd. Wanneer een privékanaal ontbreekt, creëert het script een nieuw privé-eindpunt in het juiste subnet, koppelt het aan de Storage Account, werkt de Private DNS-zone bij en voert een connectiviteitstest uit met Test-AzPrivateLinkServiceConnection om zeker te weten dat naamresolutie en routebeleid kloppen. Firewallrestricties worden automatisch ingesteld op basis van het goedgekeurde IP-beleid. Mocht een workload tijdelijk publieke toegang nodig hebben, dan registreert het script een uitzonderingsrecord met vervaldatum, zodat beveiligingsteams weten wanneer de instelling moet worden teruggedraaid. Na elke herstelactie voert Invoke-Remediation een verificatiefase uit die het monitoringgedeelte opnieuw draait om te bevestigen dat de configuratie daadwerkelijk compliant is. De resultaten worden opgeslagen in een auditbestand met datum, tijd, operator, verwijzing naar het change ticket en de status van eventuele vervolgacties. Tevens wordt een samenvatting toegevoegd aan het lessons-learned register, zodat toekomstige configuratieaanpassingen sneller en consistenter verlopen. Wanneer verificatie onverwachte resultaten oplevert, markeert het script de status als Pending Review en opent het automatisch een ticket, zodat niets tussen wal en schip valt. Door deze werkwijze ontstaat een gesloten feedbacklus waarin detectie, herstel en documentatie naadloos op elkaar aansluiten en waarin elke stap aantoonbaar voldoet aan de Nederlandse overheidsnormen..

Compliance & Frameworks

• BIO: 10.01.01, 13.02.01 - versleuteling + veilige transfer
• ISO 27001:2022: A.8.24, A.13.2.1 - versleuteling + 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

Azure Storage Security Design: Encryption at rest (256-bit AES - verify enabled), Secure transfer required (HTTPS-only - block HTTP), Public blob access DISABLED (AllowBlobPublicAccess=false), Private Endpoints (VNet-only access), Azure AD authorization (prefer over shared keys), Defender for Storage (malware scanning + threat detection - €10/maand), Soft delete (blob/container/file share recovery), Storage firewall (IP restrictions), SAS token policies (short expiration). Activatie: Storage Account → Security hardening ALL layers. Kosten: Defender €10/maand. Verplicht BIO 10.01/13.02, ISO 27001, AVG, CIS 3.x. Implementatie: 8-16 uur. CRITICAL storage protection - prevents data leaks.

• Implementatietijd: 16 uur
• FTE required: 0.08 FTE