Opslag Standaard Netwerkregel Weigeren

Deze instelling is essentieel voor het handhaven van een veilige cloud-omgeving en voorkomt bekende aanvalsvectoren door het afdwingen van beveiligingsbest practices volgens het principe van minimale bevoegdheden. Zonder deze configuratie staan opslagaccounts bloot aan het publieke internet, waardoor elke aanvaller met een Shared Access Signature (SAS) token ongeautoriseerde toegang kan verkrijgen tot gevoelige bedrijfsgegevens.

Implementatie

Deze beveiligingsregel past de benodigde netwerkbeveiligingsinstellingen toe via Azure Portal, Azure Policy of Azure Resource Manager templates om opslagaccounts te beschermen volgens actuele beveiligingsframeworks zoals CIS Benchmarks, BIO en ISO 27001. Door de standaard netwerkregel op 'Weigeren' in te stellen, wordt alleen verkeer vanaf expliciet toegestane IP-adressen of virtuele netwerken geaccepteerd.

Vereisten

De implementatie van standaard netwerkregel weigering voor Azure Storage-accounts vereist een zorgvuldige voorbereiding en een grondig begrip van de bestaande infrastructuur. Voordat u deze beveiligingsmaatregel kunt activeren, dient u te beschikken over een functioneel Azure Storage-account dat reeds in gebruik is. Deze accounts kunnen verschillende typen zijn, waaronder Blob Storage-accounts die specifiek zijn ontworpen voor het opslaan van ongestructureerde gegevens zoals afbeeldingen, documenten en mediabestanden, General Purpose v2-accounts die de meest recente versie vertegenwoordigen met geavanceerde functies en betere prestaties, of General Purpose v1-accounts die nog steeds worden ondersteund maar minder moderne mogelijkheden bieden. Het type opslagaccount heeft geen invloed op de mogelijkheid om netwerkregels te configureren, maar het is belangrijk om te begrijpen welke services en functies binnen uw account worden gebruikt.

Een kritieke vereiste voor het succesvol implementeren van deze beveiligingsregel is het bezitten van de juiste autorisaties binnen Azure. U moet minimaal beschikken over de rol Storage Account Contributor of Contributor op het niveau van het Azure-abonnement of de resourcegroep waar het opslagaccount zich bevindt. Deze rollen verlenen de benodigde rechten om netwerkinstellingen te wijzigen en firewallregels te configureren. Organisaties die gebruikmaken van op rollen gebaseerde toegangscontrole (RBAC) moeten ervoor zorgen dat de toegewezen persoon of service principal expliciet deze rechten heeft gekregen. In grotere organisaties met strikte scheiding van taken kan het nodig zijn om meerdere personen te betrekken, waarbij de ene persoon de netwerkconfiguratie wijzigt en een andere persoon de wijzigingen goedkeurt volgens wijzigingsbeheerprocedures.

Een van de meest cruciale voorbereidingsstappen is het uitvoeren van een uitgebreide inventarisatie van alle systemen, applicaties en netwerken die legitieme toegang vereisen tot het opslagaccount. Deze inventarisatie moet alle bronnen omvatten die momenteel toegang hebben tot het account of die in de toekomst toegang nodig hebben. Denk hierbij aan productieapplicatieservers die gegevens lezen of schrijven naar het opslagaccount, ontwikkel- en testomgevingen waar ontwikkelaars werken aan nieuwe functionaliteit, beheersystemen en monitoringtools die prestatie-indicatoren en logbestanden verzamelen, back-upsystemen die regelmatig reservekopieën maken van kritieke gegevens, externe partners en leveranciers die via beveiligde verbindingen toegang krijgen tot specifieke resources, en analytische tools die gegevens analyseren voor bedrijfsinformatiedoeleinden. Deze inventarisatie moet gedetailleerd zijn en per bron de IP-adressen, subnetten of virtuele netwerken documenteren die toegang vereisen.

Naast het documenteren van statische IP-adressen en vaste netwerken, moet u ook rekening houden met dynamische scenario's. Sommige Azure-services gebruiken mogelijk dynamische IP-adressen of service tags die periodiek kunnen wijzigen. Office 365 services die mogelijk toegang hebben tot uw opslagaccounts, Azure DevOps services die build artifacts opslaan, en andere Azure-native services vereisen speciale aandacht. Daarnaast moeten organisaties die werken met hybride cloud-omgevingen waar on-premises systemen verbinding maken met Azure Storage rekening houden met de publieke IP-adressen van hun on-premises gateways of VPN-endpoints. Dit is met name relevant voor organisaties die gebruikmaken van Azure ExpressRoute of site-to-site VPN verbindingen om hun on-premises netwerk te verbinden met Azure.

Voor organisaties die intensief gebruikmaken van Azure Virtual Networks en netwerksegmentatie, is het essentieel om Network Service Endpoints of Private Endpoints te configureren voordat de standaard netwerkregel weigering wordt geactiveerd. Network Service Endpoints stellen u in staat om specifieke Azure-services zoals Storage te integreren met uw virtuele netwerken, waardoor verkeer via de Azure-backbone loopt in plaats van via het publieke internet. Dit biedt niet alleen betere beveiliging door het isoleren van verkeer, maar ook betere prestaties door de geoptimaliseerde route. Private Endpoints gaan nog verder door privé IP-adressen toe te wijzen aan uw opslagaccount binnen uw virtuele netwerk, waardoor het account feitelijk privé wordt en niet meer toegankelijk is via het publieke internet. Deze aanpak is met name waardevol voor organisaties die zeer gevoelige data opslaan en maximale isolatie vereisen.

Een belangrijk aspect dat vaak over het hoofd wordt gezien is het effect van netwerkregels op integraties met andere cloudservices en externe systemen. Software-as-a-Service-oplossingen die gegevens synchroniseren naar Azure Storage, on-premises back-upsystemen die regelmatig reservekopieën uploaden, en monitoringtools van derde partijen die prestatie-indicatoren verzamelen kunnen allemaal worden beïnvloed door de implementatie van standaard netwerkregel weigering. Het is daarom essentieel om vooraf contact op te nemen met leveranciers van deze services om te verifiëren welke IP-adressen of IP-bereiken zij gebruiken en of deze kunnen worden geconfigureerd in uw firewallregels. Sommige services gebruiken zeer brede IP-bereiken die mogelijk grote delen van het internet omvatten, wat het beveiligingsdoel van netwerkregels kan ondermijnen. In dergelijke gevallen moet u alternatieve benaderingen overwegen, zoals het gebruik van Private Endpoints of service-specifieke authenticatiemethoden.

Om het risico op verstoringen van kritieke bedrijfsprocessen te minimaliseren, is het ten zeerste aanbevolen om een geïsoleerde testomgeving op te zetten die identiek is aan de productieomgeving. In deze testomgeving kunt u de configuratie van standaard netwerkregel weigering volledig valideren voordat u wijzigingen aanbrengt in productie. Deze testomgeving moet alle relevante componenten bevatten, inclusief testversies van applicaties, testgegevens die representatief zijn voor productiegegevens, en gesimuleerde verkeerpatronen. Door uitgebreide tests uit te voeren in deze gecontroleerde omgeving kunt u potentiële problemen identificeren en oplossen zonder impact op productiesystemen. Test alle kritieke bedrijfsprocessen die afhankelijk zijn van het opslagaccount, verifieer dat alle geautoriseerde systemen nog steeds toegang hebben, en controleer of nieuwe verbindingspogingen van niet-geautoriseerde bronnen daadwerkelijk worden geblokkeerd. Documenteer alle bevindingen en maak een gedetailleerd implementatieplan op basis van de geleerde lessen uit de testomgeving.

Documentatie is een fundamenteel onderdeel van het implementatieproces en moet worden gezien als een levend document dat regelmatig wordt bijgewerkt. Alle toegestane netwerken, IP-adressen, virtuele netwerken en de redenen waarom zij toegang hebben moeten worden gedocumenteerd in een centraal beheerd document of systeem. Deze documentatie moet ook contactgegevens bevatten van verantwoordelijken voor elk systeem, zodat bij problemen snel contact kan worden opgenomen. Naarmate de infrastructuur evolueert, met nieuwe applicaties die worden geïmplementeerd, bestaande systemen die worden gemigreerd, of netwerkconfiguraties die worden aangepast, moet deze documentatie worden bijgewerkt en moeten de firewallregels dienovereenkomstig worden aangepast. Implementeer een proces voor wijzigingsbeheer waarbij alle wijzigingen aan firewallregels worden beoordeeld en goedgekeurd voordat zij worden doorgevoerd, om te voorkomen dat onbevoegde of onjuiste configuraties worden geactiveerd die de beveiliging kunnen aantasten of bedrijfsprocessen kunnen verstoren.

Monitoring

Gebruik PowerShell-script default-network-rule-deny.ps1 (functie Invoke-Monitoring) – Automatische controle van de standaard netwerkregel configuratie.

Effectieve monitoring van netwerkbeveiligingsconfiguraties vormt de hoeksteen van een robuuste beveiligingsstrategie voor Azure Storage-accounts. Het monitoren van de standaard netwerkregelconfiguratie is niet alleen van cruciaal belang om te garanderen dat beveiligingsinstellingen correct blijven geconfigureerd, maar ook om te detecteren wanneer deze instellingen per ongeluk of opzettelijk worden gewijzigd door andere beheerders, geautomatiseerde processen, of in het ergste geval door kwaadwillende actoren. In moderne cloudomgevingen waar configuratiewijzigingen frequent voorkomen en waarbij meerdere teams en systemen toegang hebben tot beheertools, kan een enkele onbedoelde wijziging de gehele beveiligingspostuur van een organisatie aantasten. Daarom moet monitoring worden gezien als een continu proces dat geen moment van rust kent, waarbij geautomatiseerde systemen constant de staat van beveiligingsconfiguraties bewaken en direct waarschuwen bij afwijkingen.

De frequentie van monitoringcontroles moet worden afgestemd op de gevoeligheid van de opgeslagen gegevens en de nalevingsvereisten die voor uw organisatie gelden. Voor opslagaccounts die zeer gevoelige persoonsgegevens bevatten, zoals medische dossiers of financiële informatie, is dagelijkse of zelfs realtime monitoring aan te bevelen. Deze accounts vereisen de hoogste mate van bescherming en elke configuratiewijziging moet onmiddellijk worden gedetecteerd en geëvalueerd. Voor accounts met gemiddelde gevoeligheid kan wekelijkse monitoring voldoende zijn, terwijl accounts met lagere gevoeligheid mogelijk maandelijks gecontroleerd kunnen worden. Echter, zelfs voor minder gevoelige accounts is het raadzaam om minimaal wekelijks te controleren, omdat beveiligingsconfiguraties de eerste verdedigingslinie vormen tegen cyberaanvallen en een enkele inbreuk kan leiden tot toegang tot meerdere systemen binnen uw organisatie.

Het PowerShell-script dat bij deze beveiligingsregel hoort, vormt een krachtig instrument voor geautomatiseerde compliance-controles. Dit script controleert systematisch de eigenschap DefaultAction van alle opslagaccounts binnen een abonnement of resourcegroep en verifieert of deze correct is ingesteld op Deny. De DefaultAction eigenschap bepaalt het standaardgedrag van de netwerkfirewall wanneer een inkomende verbindingspoging niet expliciet wordt toegestaan door een firewallregel. Wanneer deze eigenschap is ingesteld op Allow, betekent dit dat het opslagaccount volledig toegankelijk is vanaf elk netwerk ter wereld, zolang de aanvrager beschikt over geldige authenticatiegegevens zoals een Shared Access Signature token. Dit vormt een extreem ernstig beveiligingsrisico, omdat kwaadwillende actoren met gestolen credentials of gecompromitteerde tokens vanaf elke locatie toegang kunnen verkrijgen tot gevoelige bedrijfsgegevens zonder enige netwerkbeperking.

Het monitoring-script genereert gedetailleerde rapporten die duidelijk aangeven welke opslagaccounts niet voldoen aan de beveiligingsvereisten en waarom. Deze rapporten bevatten essentiële informatie zoals de naam van het niet-compliant account, de resourcegroep waarin het zich bevindt, het abonnement waaronder het valt, de huidige waarde van de DefaultAction eigenschap, en de timestamp van wanneer de controle is uitgevoerd. Deze informatie stelt beveiligingsteams in staat om snel te identificeren welke accounts aandacht vereisen en prioriteiten te stellen op basis van de gevoeligheid van de opgeslagen gegevens. Voor grote organisaties met honderden of duizenden opslagaccounts kan het script worden geconfigureerd om alleen niet-compliant accounts te rapporteren, waardoor de output beheersbaar blijft en beveiligingsteams zich kunnen focussen op accounts die daadwerkelijk actie vereisen.

Naast de periodieke controles via het PowerShell-script, is het essentieel om real-time monitoring en alerting te implementeren met behulp van Azure Monitor en Azure Security Center. Azure Monitor biedt uitgebreide mogelijkheden om Activity Log events te bewaken die worden gegenereerd wanneer wijzigingen worden aangebracht aan de netwerkconfiguratie van opslagaccounts. U kunt log alerts configureren die direct worden geactiveerd wanneer een beheerder de DefaultAction eigenschap wijzigt van Deny naar Allow, of wanneer firewallregels worden toegevoegd, gewijzigd of verwijderd. Deze alerts kunnen worden doorgestuurd naar verschillende kanalen, zoals e-mail, SMS, Microsoft Teams kanalen, of geïntegreerde ticketing systemen, afhankelijk van de voorkeuren en workflows van uw organisatie. Door meerdere kanalen te configureren, zorgt u ervoor dat kritieke waarschuwingen nooit gemist worden, zelfs wanneer primaire communicatiekanalen tijdelijk niet beschikbaar zijn.

Azure Security Center, nu onderdeel van Microsoft Defender for Cloud, biedt een gecentraliseerd platform voor security posture management en threat protection. Deze service voert continu security assessments uit op alle resources binnen uw Azure-omgeving, inclusief opslagaccounts, en identificeert configuratiefouten en beveiligingsrisico's. Security Center kan automatisch detecteren wanneer opslagaccounts zijn geconfigureerd met onveilige netwerkinstellingen en genereert security recommendations die duidelijk aangeven welke accounts aandacht vereisen. Deze recommendations zijn geïntegreerd met Azure Policy, waardoor organisaties automatische remediatie kunnen implementeren die niet-compliant configuraties direct herstellen zonder handmatige interventie. Security Center biedt ook prioritering van recommendations op basis van de potentiële impact en de exploitability van beveiligingslekken, waardoor beveiligingsteams hun beperkte tijd en resources kunnen focussen op de meest kritieke problemen.

Voor een compleet en accuraat beeld van de netwerkbeveiliging van uw opslagaccounts moet u verder gaan dan alleen het monitoren van de DefaultAction-eigenschap. Het is eveneens essentieel om regelmatig een grondige beoordeling uit te voeren van alle geconfigureerde firewallregels om te verifiëren dat deze nog steeds legitiem en noodzakelijk zijn. Naarmate organisaties evolueren, kunnen applicaties worden gemigreerd naar andere omgevingen, externe partners hun toegangsvereisten wijzigen, of netwerken worden herstructureerd. In dergelijke scenario's kunnen firewallregels overbodig worden of verwijzen naar systemen die niet langer bestaan. Overbodige firewallregels vormen een onnodig vergroot aanvalsoppervlak, omdat elk toegestaan IP-adres of netwerk een potentiële toegangspunt vormt voor kwaadwillende actoren. Regelmatige beoordelingen moeten worden uitgevoerd waarbij elke firewallregel wordt geëvalueerd op basis van de vraag of deze nog steeds wordt gebruikt, of de bron nog steeds legitiem is, en of de toegang nog steeds noodzakelijk is voor bedrijfsdoeleinden.

Azure Storage Analytics biedt krachtige mogelijkheden om inzicht te krijgen in welke IP-adressen en netwerken daadwerkelijk toegang hebben tot uw opslagaccounts. Door deze analyses te analyseren, kunt u identificeren welke bronnen regelmatig verbinding maken met uw accounts en deze informatie vergelijken met uw geconfigureerde firewallregels. Deze vergelijking kan belangrijke inzichten opleveren, zoals het detecteren van firewallregels die zijn geconfigureerd maar nooit worden gebruikt, wat suggereert dat deze kunnen worden verwijderd om het aanvalsoppervlak te verkleinen. Omgekeerd kunt u ook toegangspogingen detecteren vanaf IP-adressen die niet zijn geconfigureerd in uw firewallregels, wat kan wijzen op geautoriseerde toegang via andere mechanismen zoals Private Endpoints, of mogelijk op onbevoegde toegangspogingen die verder onderzoek vereisen. Storage Analytics-logbestanden bevatten gedetailleerde informatie over elke toegangsaanvraag, inclusief het bron-IP-adres, de tijd van de aanvraag, de gebruikte authenticatiemethode, en het type operatie dat werd uitgevoerd, waardoor beveiligingsteams uitgebreide forensische analyses kunnen uitvoeren.

Voor organisaties met meerdere opslagaccounts die verspreid zijn over verschillende abonnementen en resourcegroepen, is handmatige monitoring niet schaalbaar en vatbaar voor menselijke fouten. In dergelijke scenario's is het sterk aanbevolen om Azure Policy te gebruiken voor gecentraliseerd nalevingsbeheer. Azure Policy stelt organisaties in staat om organisatiebrede beleidsregels te definiëren die automatisch worden geëvalueerd op alle resources binnen het bereik van de beleidsregel. U kunt een aangepaste beleidsdefinitie maken die specifiek controleert of alle opslagaccounts de DefaultAction-eigenschap hebben ingesteld op Deny, en deze beleidsregel toepassen op het niveau van beheergroepen, abonnementen, of resourcegroepen. Beleidsregels kunnen worden geconfigureerd om alleen te controleren en te rapporteren, of om automatische remediatie uit te voeren waarbij niet-nalevende configuraties worden hersteld zonder handmatige interventie. Deze aanpak zorgt niet alleen voor consistente beveiliging over alle accounts, maar vermindert ook aanzienlijk de operationele overhead van handmatige controles en verkleint het risico op configuratiefouten.

Naast het monitoren van configuraties, is het ook belangrijk om regelmatig de effectiviteit van uw beveiligingsmaatregelen te evalueren door middel van beveiligingstests en audits. Voer periodiek penetratietests uit waarbij getracht wordt om toegang te verkrijgen tot opslagaccounts via methoden die kwaadwillende actoren zouden kunnen gebruiken, en verifieer dat uw netwerkregels deze pogingen daadwerkelijk blokkeren. Test ook randgevallen, zoals toegangspogingen vanaf IP-adressen die net buiten uw geconfigureerde bereiken vallen, om te verifiëren dat de firewallregels correct worden toegepast. Externe beveiligingsaudits door gecertificeerde derde partijen kunnen onafhankelijke validatie bieden dat uw beveiligingsconfiguraties voldoen aan industriestandaarden en nalevingsvereisten. Documenteer alle monitoringactiviteiten, gevonden problemen, genomen acties, en auditbevindingen in een centraal beheerd systeem, zodat u tijdens externe audits en nalevingsbeoordelingen kunt aantonen dat u proactief monitoring uitvoert en beveiligingsrisico's beheert.

Compliance en Naleving

De implementatie van standaard netwerkregel weigering voor Azure Storage-accounts vertegenwoordigt een fundamentele beveiligingsmaatregel die niet alleen technische bescherming biedt, maar ook een kritieke vereiste is voor naleving van verschillende nationale en internationale beveiligingsstandaarden en wet- en regelgeving. In het huidige digitale landschap waar cyberaanvallen steeds geavanceerder worden en regelgevers striktere eisen stellen aan gegevensbescherming, kunnen organisaties zich geen zwakke punten in hun beveiligingspostuur veroorloven. De configuratie van netwerkregels vormt de eerste verdedigingslinie tegen onbevoegde toegang en is daarom een essentieel onderdeel van elke compliance-strategie. Voor Nederlandse overheidsorganisaties is deze beveiligingsmaatregel specifiek relevant omdat zij moeten voldoen aan de Baseline Informatiebeveiliging Overheid (BIO), een uitgebreid kader dat strikte eisen stelt aan netwerktoegangscontrole, het voorkomen van onbevoegde toegang tot informatie, en het implementeren van defense-in-depth strategieën die meerdere beveiligingslagen combineren om kritieke systemen te beschermen.

De CIS Microsoft Azure Foundations Benchmark, een wereldwijd erkende set van security best practices specifiek ontwikkeld voor Azure-omgevingen, specificeert in versie 3.6 controle 3.6 expliciet dat alle Azure Storage-accounts dienen te worden geconfigureerd met netwerkregels die alleen toegestane netwerken toestaan. Deze controle valt onder het niveau 2 (L2) classificatie, wat betekent dat het wordt aanbevolen voor organisaties met hogere beveiligingsvereisten die een uitgebreidere beveiligingspostuur nodig hebben dan de basisvereisten die worden beschreven in niveau 1 controles. L2 controles worden typisch geïmplementeerd door organisaties die gevoelige gegevens verwerken, werken in sterk gereguleerde industrieën, of opereren in omgevingen met verhoogde bedreigingsniveaus. Het niet implementeren van deze controle resulteert niet alleen in een verhoogd risico op datalekken en ongeautoriseerde toegang tot gevoelige informatie, maar kan ook leiden tot niet-naleving van contractuele verplichtingen, verlies van klantvertrouwen, en in sommige gevallen tot juridische aansprakelijkheid en boetes van toezichthouders.

Binnen het BIO-raamwerk, dat specifiek is ontwikkeld voor Nederlandse overheidsorganisaties om te voldoen aan de eisen van de Wet Digitale Overheid en de Algemene Verordening Gegevensbescherming, valt deze beveiligingsmaatregel onder controle 13.01, dat betrekking heeft op netwerktoegangscontrole en authenticatie. Deze controle vereist dat organisaties passende technische en organisatorische maatregelen treffen om te voorkomen dat onbevoegden toegang krijgen tot informatiesystemen via netwerken. De controle benadrukt het belang van defense-in-depth benaderingen waarbij meerdere beveiligingslagen worden gecombineerd, waarbij netwerktoegangscontrole slechts één component vormt van een uitgebreide beveiligingsstrategie. Door de standaard netwerkregel op Weigeren in te stellen en alleen specifieke, geautoriseerde netwerken toe te staan via expliciet geconfigureerde firewallregels, voldoen organisaties aan deze BIO-vereiste en demonstreren zij een proactieve aanpak van netwerkbeveiliging. Deze maatregel is met name kritiek voor opslagaccounts die persoonsgegevens bevatten, aangezien de Algemene Verordening Gegevensbescherming (AVG) in artikel 32 expliciet vereist dat organisaties passende technische en organisatorische maatregelen implementeren om persoonsgegevens te beschermen tegen ongeautoriseerde toegang, ongeautoriseerde verwerking, en verlies of vernietiging.

De AVG stelt verder dat organisaties rekening moeten houden met de stand van de techniek, de uitvoeringskosten, en de aard, de omvang, de context en de doeleinden van de verwerking, alsmede met de waarschijnlijkheid en de ernst van de risico's voor de rechten en vrijheden van natuurlijke personen. Netwerkregels vormen een kosteneffectieve en technisch bewezen maatregel die direct bijdraagt aan de bescherming van persoonsgegevens door het aanvalsoppervlak te verkleinen en onbevoegde toegang te voorkomen. Voor organisaties die persoonsgegevens verwerken, is het niet alleen een best practice om netwerkregels te implementeren, maar in veel gevallen een juridische verplichting om te kunnen aantonen dat passende maatregelen zijn genomen om gegevens te beschermen. Het niet implementeren van dergelijke maatregelen kan leiden tot AVG-boetes van de Autoriteit Persoonsgegevens, die kunnen oplopen tot vier procent van de wereldwijde jaaromzet of twintig miljoen euro, afhankelijk van wat hoger is.

De ISO 27001:2022 norm, een internationaal erkende standaard voor informatiebeveiligingsmanagement systemen (ISMS), vereist in controle A.8.20 dat organisaties netwerkbeveiliging implementeren om informatie te beschermen die via netwerken wordt uitgewisseld. Deze controle omvat niet alleen het gebruik van netwerkbeveiligingscontroles zoals firewalls en netwerksegmentatie, maar ook de implementatie van toegangscontrole lijsten, intrusion detection en prevention systemen, en regelmatige beveiligingsreviews. De Azure Storage firewall met standaard weigering vormt een essentiële component van deze netwerkbeveiliging door het implementeren van een whitelist benadering waarbij alleen geautoriseerde netwerken toegang hebben. Organisaties die ISO 27001 gecertificeerd willen worden of hun certificering willen behouden, moeten kunnen aantonen tijdens externe audits dat zij passende netwerkbeveiligingsmaatregelen hebben geïmplementeerd, gemonitord, en regelmatig geëvalueerd. Certificeringsauditors zullen specifiek controleren of netwerkbeveiligingsconfiguraties zijn gedocumenteerd, of er procedures bestaan voor het beheer van firewallregels, en of er monitoring en alerting is geïmplementeerd om wijzigingen te detecteren.

Voor Nederlandse organisaties in de publieke sector zijn er aanvullende compliance-vereisten die relevant zijn. De Wet openbaarheid van bestuur (Wob), nu Wet open overheid (Woo), vereist dat overheidsorganisaties transparant zijn over hun activiteiten, maar deze transparantie mag niet ten koste gaan van informatiebeveiliging. Netwerkregels helpen organisaties om deze balans te vinden door gevoelige informatie te beschermen terwijl tegelijkertijd toegankelijkheid wordt geboden voor geautoriseerde systemen. Daarnaast moeten Nederlandse overheidsorganisaties voldoen aan de Baseline Informatiebeveiliging Rijksdienst (BIR), die aanvullende eisen stelt voor rijksoverheidsorganisaties. Deze baseline bouwt voort op de BIO en voegt specifieke vereisten toe voor organisaties die kritieke infrastructuur beheren of zeer gevoelige informatie verwerken. Voor dergelijke organisaties is het implementeren van netwerkregels niet alleen een best practice, maar een absolute vereiste om te voldoen aan hun compliance-verplichtingen.

Voor auditdoeleinden is uitgebreide documentatie van cruciaal belang. U moet duidelijk documenteren wanneer de standaard netwerkregel is geconfigureerd, welke netwerken en IP-adressen zijn toegestaan, de redenen waarom deze toegang is verleend, en wie verantwoordelijk is voor het beheer van deze configuratie. Deze documentatie moet deel uitmaken van uw formele beveiligingsdocumentatie en regelmatig worden bijgewerkt wanneer wijzigingen worden aangebracht. Zorg ervoor dat alle wijzigingen aan firewallregels worden gelogd in Azure Activity Log en dat deze logs minimaal zeven jaar worden bewaard, conform de Nederlandse archiefwetgeving zoals vastgelegd in de Archiefwet 1995. Deze bewaarplicht is met name relevant voor overheidsorganisaties die moeten voldoen aan archiveringsvereisten, maar ook private organisaties kunnen contractuele verplichtingen hebben om logs voor langere perioden te bewaren. Implementeer een centraal log management systeem waarbij logs automatisch worden verzameld, gearchiveerd, en beschermd tegen onbevoegde toegang of wijziging.

Maak gebruik van Azure Policy om automatisch te controleren op compliance en genereer regelmatig rapporten die aantonen dat alle opslagaccounts voldoen aan de vereisten. Deze rapporten moeten worden gedeeld met relevante stakeholders, waaronder CISO's, compliance officers, en management, en moeten deel uitmaken van reguliere security posture reviews. Configureer compliance dashboards die real-time inzicht bieden in de compliance-status van alle opslagaccounts, zodat problemen snel kunnen worden geïdentificeerd en aangepakt. Tijdens externe audits door certificeringsinstanties, toezichthouders, of klanten, moet u kunnen aantonen dat de netwerkbeveiliging effectief is geconfigureerd, dat er adequate monitoring plaatsvindt om wijzigingen tijdig te detecteren, en dat er processen bestaan voor het beheer en onderhoud van firewallconfiguraties. Bereid audit trails voor die de volledige geschiedenis van configuratiewijzigingen documenteren, inclusief wie de wijziging heeft aangebracht, wanneer deze is gemaakt, de reden voor de wijziging, en de goedkeuring door relevante autoriteiten. Deze gedetailleerde documentatie demonstreert niet alleen compliance, maar ook volwassen beveiligingsprocessen en een proactieve aanpak van risicomanagement.

Remediatie

Gebruik PowerShell-script default-network-rule-deny.ps1 (functie Invoke-Remediation) – Automatisch herstellen van de standaard netwerkregel configuratie.

Wanneer monitoringtools of beveiligingsbeoordelingen aantonen dat een opslagaccount niet-nalevend is omdat de standaard netwerkregel niet correct is geconfigureerd, is onmiddellijke actie vereist om de blootgestelde beveiligingsrisico's te mitigeren. Een opslagaccount dat is geconfigureerd met DefaultAction ingesteld op Allow staat volledig open voor toegang vanaf elk netwerk ter wereld, zolang de aanvrager beschikt over geldige authenticatiegegevens. Deze configuratie vormt een extreem ernstig beveiligingsrisico omdat kwaadwillende actoren met gestolen inloggegevens, gecompromitteerde tokens, of brute-krachtaanvallen vanaf elke locatie toegang kunnen verkrijgen tot gevoelige bedrijfsgegevens zonder enige netwerkbeperking. Het remediatieproces moet daarom met de hoogste prioriteit worden uitgevoerd, maar tegelijkertijd uiterst zorgvuldig om te voorkomen dat legitieme applicaties en kritieke bedrijfsprocessen worden verstoord door het plotseling blokkeren van toegang. Een gebalanceerde aanpak is essentieel waarbij beveiligingsrisico's snel worden verminderd zonder operationele verstoringen te veroorzaken.

Het bijbehorende PowerShell-script biedt de mogelijkheid om automatisch de standaard netwerkregel in te stellen op Deny met een enkele commando-uitvoering, wat de snelheid van remediatie aanzienlijk kan verhogen. Echter, deze geautomatiseerde aanpak moet worden gebruikt met volledig begrip van de potentiële impact. Voordat u het script uitvoert, is het absoluut essentieel om eerst grondig te verifiëren welke netwerken, IP-adressen en virtuele netwerken toegang moeten hebben tot het opslagaccount. Het automatisch instellen van de standaard weigering zonder voorafgaande configuratie van firewallregels zal resulteren in onmiddellijke uitval van alle applicaties en services die afhankelijk zijn van het opslagaccount, wat kan leiden tot ernstige bedrijfsverstoringen, verlies van productiviteit, en potentiële financiële impact. Daarom moet geautomatiseerde remediatie altijd worden voorafgegaan door een zorgvuldige planning en impactanalyse, of worden uitgevoerd in een gecontroleerde omgeving waar de impact kan worden getest en gevalideerd voordat wijzigingen worden doorgevoerd in productie.

Voordat u het remediatieproces start, is het essentieel om een uitgebreide en gedetailleerde impactanalyse uit te voeren die alle aspecten van de mogelijke gevolgen omvat. Begin met het identificeren van alle applicaties, services, systemen en bedrijfsprocessen die direct of indirect afhankelijk zijn van het opslagaccount. Dit omvat niet alleen productieapplicaties, maar ook ontwikkel- en testomgevingen, back-upsystemen, monitoringtools, analyseplatforms, en externe integraties met partners of leveranciers. Maak een uitgebreide afhankelijkheidskaart die duidelijk weergeeft welke systemen verbinding maken met het opslagaccount, wat voor type gegevens zij lezen of schrijven, hoe frequent zij toegang hebben, en wat de bedrijfsimpact zou zijn als deze toegang wordt geblokkeerd. Deze informatie is kritiek voor het bepalen van de juiste timing voor remediatie, waarbij u mogelijk wilt kiezen voor een onderhoudsvenster of een gefaseerde aanpak waarbij eerst minder kritieke accounts worden geremedieerd voordat u overgaat tot productieaccounts.

Gebruik Azure Monitor-logbestanden en Azure Storage Analytics om historische toegangspatronen te analyseren en te identificeren welke IP-adressen, netwerken en geografische locaties daadwerkelijk toegang hebben gehad tot het opslagaccount gedurende de afgelopen periode. Deze analyses bieden waardevolle inzichten in het normale verkeerspatroon en helpen u om te identificeren welke bronnen legitieme toegang hebben versus welke mogelijk verdacht of ongebruikelijk zijn. Analyseer de logbestanden op toegangspatronen per IP-adres, inclusief de frequentie van toegang, de tijden waarop toegang wordt verkregen, en het type operaties dat wordt uitgevoerd. Deze informatie helpt u niet alleen om te bepalen welke firewallregels moeten worden geconfigureerd, maar kan ook onthullen of er mogelijk onbevoegde toegang heeft plaatsgevonden die verder onderzoek vereist. Maak een gedetailleerde lijst van alle legitieme bronnen die toegang nodig hebben, inclusief hun IP-adressen of IP-bereiken, de redenen waarom zij toegang nodig hebben, de eigenaar of verantwoordelijke voor elk systeem, en prioriteitsniveau op basis van de kritiekheid van de bedrijfsfunctie.

Het is ten zeerste aanbevolen om eerst een testomgeving te gebruiken om de volledige remediatieprocedure te valideren voordat u wijzigingen aanbrengt in productie. Configureer een testopslagaccount dat identiek is aan het productieaccount in termen van configuratie, firewallregels, en gebruikspatronen. Voer in deze testomgeving alle stappen uit van het remediatieproces, inclusief het instellen van de standaard netwerkregel op Deny, het configureren van firewallregels, en het testen van alle applicaties en services die toegang vereisen. Deze testomgeving stelt u in staat om potentiële problemen te identificeren en op te lossen zonder risico voor productiesystemen. Test alle kritieke bedrijfsprocessen, verifieer dat gegevens correct kunnen worden gelezen en geschreven, controleer of back-upprocessen nog steeds functioneren, en valideer dat externe integraties nog steeds werken. Documenteer alle bevindingen, inclusief welke firewallregels nodig waren, welke problemen werden aangetroffen, en hoe deze werden opgelost, zodat u deze kennis kunt toepassen bij de productieremediatie.

De remediatie kan worden uitgevoerd via twee primaire methoden: handmatige remediatie via de Azure Portal, wat meer controle en zichtbaarheid biedt maar meer tijd en handmatige inspanning vereist, of geautomatiseerde remediatie via het PowerShell-script, wat sneller en schaalbaarder is maar meer voorbereiding vereist. Voor handmatige remediatie navigeert u naar het opslagaccount in de Azure Portal, selecteert u de sectie Netwerken in het navigatiemenu, en wijzigt u de standaardactie van Allow naar Deny in de firewallconfiguratie. Vervolgens moet u systematisch alle benodigde firewallregels toevoegen voor IP-adressen, IP-bereiken, of virtuele netwerken die toegang nodig hebben. Deze aanpak geeft u volledige controle over het proces en stelt u in staat om elke regel individueel te configureren en te verifiëren voordat u doorgaat naar de volgende. Het is belangrijk om tijdens dit proces regelmatig te testen of de geconfigureerde regels daadwerkelijk werken door toegang te proberen vanuit de geautoriseerde netwerken.

Voor geautomatiseerde remediatie via het PowerShell-script kunt u het script uitvoeren dat automatisch de standaard netwerkregel instelt op Deny. Echter, dit script zal alleen de DefaultAction wijzigen en zal niet automatisch firewallregels configureren. Daarom moet u vooraf alle benodigde firewallregels voorbereiden en deze configureren voordat u de standaard weigering activeert, of u moet een aangepast script gebruiken dat beide stappen combineert. Geautomatiseerde remediatie is bijzonder waardevol voor organisaties met meerdere niet-compliant opslagaccounts, omdat het script kan worden uitgevoerd tegen meerdere accounts tegelijk, waardoor de tijd voor remediatie aanzienlijk wordt verkort. Echter, zorg ervoor dat u volledig begrijpt wat het script doet en welke impact het zal hebben voordat u het uitvoert, en overweeg om eerst een dry-run of test uit te voeren op een niet-kritiek account om te verifiëren dat het script correct werkt.

Na het uitvoeren van de remediatie is uitgebreide testing en validatie essentieel om te verifiëren dat alle kritieke applicaties en services nog steeds correct functioneren zonder degradatie van prestaties of functionaliteit. Test systematisch alle belangrijke bedrijfsprocessen die afhankelijk zijn van het opslagaccount, inclusief gegevens lezen en schrijven operaties, back-up en herstelprocessen, gegevenssynchronisatie tussen systemen, en rapportage en analysefuncties. Verifieer dat gebruikers nog steeds toegang hebben waar nodig en dat er geen onverwachte toegangsbeperkingen zijn geïntroduceerd. Monitor Azure Monitor, Application Insights, en andere monitoringtools intensief op fouten, uitzonderingen, of prestatieproblemen die kunnen wijzen op geblokkeerde verbindingen, time-outs, of andere netwerkgerelateerde problemen. Zet tijdelijke extra logboekregistratie aan om gedetailleerde informatie te verzamelen over alle toegangspogingen, zodat u snel problemen kunt identificeren en oplossen. Indien u toegangsproblemen constateert, voegt u onmiddellijk de benodigde IP-adressen of virtuele netwerken toe aan de firewallregels om serviceonderbrekingen te minimaliseren.

Houd een uitgebreid logboek bij van alle wijzigingen die tijdens het remediatieproces zijn gemaakt, inclusief welke firewallregels zijn toegevoegd, welke IP-adressen zijn geconfigureerd, wanneer de wijzigingen zijn doorgevoerd, wie de wijzigingen heeft geautoriseerd, en wat de resultaten waren van de testing. Deze documentatie is niet alleen waardevol voor toekomstige referentie en probleemoplossing, maar vormt ook belangrijk auditbewijs dat tijdens nalevingsbeoordelingen kan worden gebruikt om aan te tonen dat beveiligingsproblemen proactief zijn geïdentificeerd en opgelost. Documenteer ook alle problemen die zijn aangetroffen tijdens de remediatie, hoe deze zijn opgelost, en welke geleerde lessen zijn opgedaan, zodat toekomstige remediaties soepeler kunnen verlopen. Deze kennisbank kan ook worden gebruikt om beste praktijken te ontwikkelen en te documenteren voor het beheer van netwerkregels, wat helpt om consistentie te waarborgen over de organisatie en ervoor zorgt dat toekomstige configuraties vanaf het begin correct zijn geïmplementeerd.

Voor organisaties met meerdere opslagaccounts verspreid over verschillende abonnementen en resourcegroepen is handmatige remediatie niet schaalbaar en vatbaar voor menselijke fouten en inconsistenties. In dergelijke scenario's is het sterk aanbevolen om Azure Policy te gebruiken voor bulkremediatie en proactief nalevingsbeheer. U kunt een Azure Policy-definitie maken die automatisch controleert of alle opslagaccounts binnen het bereik van de beleidsregel de standaard netwerkregel hebben ingesteld op Deny, en deze beleidsregel kan worden geconfigureerd om automatisch remediatie uit te voeren wanneer niet-nalevende configuraties worden gedetecteerd. Deze automatische remediatie kan worden ingesteld om onmiddellijk te worden uitgevoerd wanneer een account niet-nalevend wordt, of volgens een geplande evaluatiecyclus. Deze aanpak zorgt ervoor dat nieuwe opslagaccounts automatisch nalevend zijn zodra ze worden gemaakt, dat bestaande accounts die per ongeluk worden gewijzigd automatisch worden hersteld, en dat de nalevingspostuur van de gehele organisatie wordt gehandhaafd zonder continue handmatige interventie.

Configureer ook proactieve waarschuwingen in Azure Monitor en Azure Security Center om direct te worden geïnformeerd wanneer een opslagaccount niet-nalevend wordt of wanneer wijzigingen worden aangebracht aan de netwerkconfiguratie. Deze waarschuwingen moeten worden geconfigureerd met de juiste prioriteitsniveaus, waarbij kritieke accounts die zeer gevoelige gegevens bevatten hogere prioriteit krijgen dan accounts met minder gevoelige informatie. Zorg ervoor dat waarschuwingen worden doorgestuurd naar de juiste teams en individuen, inclusief beveiligingsteams, cloudarchitecten, en nalevingsofficieren, zodat snelle actie kan worden ondernomen. Overweeg om automatische remediatiewerkstromen te implementeren die worden geactiveerd wanneer bepaalde types van configuratiewijzigingen worden gedetecteerd, waarbij het systeem automatisch de juiste acties onderneemt om de beveiliging te herstellen zonder dat handmatige interventie vereist is. Deze geautomatiseerde aanpak verkleint niet alleen de tijd tot remediatie, wat de blootstellingstijd aan beveiligingsrisico's minimaliseert, maar vermindert ook de operationele overhead en zorgt voor consistente beveiliging over alle accounts in uw organisatie.

Compliance & Frameworks

• CIS M365: Control 3.6 (L2) - Netwerkregels voor opslagaccounts
• BIO: 13.01 - Netwerktoegangscontrole en authenticatie
• ISO 27001:2022: A.8.20 - 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

Standaard Netwerkregel Weigering: Configureer de opslagaccountfirewall met standaard weigering waarbij alleen specifieke IP-adressen of virtuele netwerken expliciet worden toegestaan. Deze maatregel blokkeert onbevoegde netwerktoegang en voorkomt dat opslagaccounts blootgesteld worden aan het publieke internet. Activatie vindt plaats via: Opslagaccount → Netwerken → Firewalls: Standaard actie instellen op Weigeren. Deze configuratie brengt geen extra kosten met zich mee. De maatregel is verplicht voor naleving van CIS 3.6 en BIO 13.01. De implementatietijd bedraagt 2-3 uur inclusief inventarisatie van benodigde IP-adressen en uitgebreide testen. Dit vormt een essentiële beveiligingsmaatregel voor netwerkisolatie van opslagaccounts die kritiek is voor het beschermen van gevoelige bedrijfsgegevens tegen ongeautoriseerde toegang vanaf het internet.

• Implementatietijd: 3 uur
• FTE required: 0.03 FTE