L1 BIO 13.01 CIS 3.8

Opslagfirewall Geconfigureerd

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

💼 Management Samenvatting

Azure Storage-accounts moeten worden beveiligd met een firewall die standaard alle toegang weigert, tenzij deze expliciet is toegestaan via virtuele netwerken of specifieke IP-adresbereiken.

Aanbeveling
IMPLEMENTEER OPSLAGFIREWALL
Risico zonder
Critical
Risk Score
9/10
Implementatie
4u (tech: 2u)
Van toepassing op:
✓ Azure

Zonder deze beveiligingsmaatregel kunnen er significante beveiligingsrisico's ontstaan die leiden tot gegevenscompromittering, nalevingsschendingen en reputatieschade voor de organisatie. Azure Storage-accounts die zonder firewallregels worden geconfigureerd, zijn standaard toegankelijk vanaf elke locatie op internet, wat een kritiek beveiligingslek vormt. Aanvallers kunnen misbruik maken van zwakke authenticatiemethoden, gestolen toegangstokens of kwetsbaarheden in de configuratie om ongeautoriseerde toegang te verkrijgen tot gevoelige gegevens.

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

Implementatie

Deze controle implementeert beveiligingsbest practices via Azure Policy, ARM-templates of Microsoft Intune om cloudresources en eindpunten te beschermen volgens actuele complianceframeworks. De firewallconfiguratie zorgt ervoor dat alleen geautoriseerde netwerken en IP-adressen toegang hebben tot de opslagaccounts, waardoor de aanvalsoppervlakte aanzienlijk wordt verkleind en de organisatie voldoet aan de vereisten van CIS Benchmark 3.8 en BIO-norm 13.01 voor netwerktoegangscontrole. De implementatie van deze beveiligingsmaatregel vormt een fundamenteel onderdeel van een gelaagde beveiligingsstrategie die meerdere verdedigingslagen combineert om gevoelige gegevens te beschermen tegen zowel externe als interne bedreigingen.

Vereisten

Voor een effectieve implementatie van de Azure Storage-firewall zijn verschillende technische en organisatorische vereisten van toepassing. Ten eerste moet de organisatie een volledig overzicht hebben van alle netwerkcomponenten die toegang nodig hebben tot de opslagaccounts. Dit omvat een inventarisatie van virtuele netwerken (VNets), subnetten, IP-adresbereiken en specifieke IP-adressen die legitieme toegang vereisen. Daarnaast moeten alle Azure-services die toegang nodig hebben tot de opslagaccounts worden geïdentificeerd, zoals Azure Functions, Logic Apps of andere PaaS-services die binnen hetzelfde Azure-abonnement opereren.

Vanuit technisch perspectief vereist de firewallconfiguratie dat beheerders beschikken over de juiste Azure RBAC-machtigingen, specifiek de rol van Storage Account Contributor of hoger. De organisatie moet ook beschikken over een centraal netwerkbeheerproces dat wijzigingen in IP-adresbereiken en virtuele netwerken kan beheren en documenteren. Dit is essentieel omdat wijzigingen in de netwerktopologie directe impact hebben op de firewallregels en mogelijk kunnen leiden tot serviceonderbrekingen als niet correct wordt geconfigureerd.

Een kritieke vereiste is de implementatie van een toegestane-lijst-benadering waarbij alleen expliciet goedgekeurde netwerken en IP-adresbereiken toegang krijgen. De standaardactie moet altijd 'Weigeren' zijn, wat betekent dat alle verkeer wordt geblokkeerd tenzij het expliciet is toegestaan. Deze zero-trust-benadering zorgt ervoor dat de organisatie volledige controle heeft over wie toegang heeft tot de opslagaccounts en voorkomt dat onbevoegde partijen gebruik kunnen maken van onbeveiligde eindpunten. Voor organisaties die gebruik maken van hybride cloudomgevingen of externe partners die toegang nodig hebben, moet een gestructureerd proces worden opgezet voor het aanvragen, goedkeuren en implementeren van nieuwe firewallregels. Dit proces moet voldoen aan de principes van minimale bevoegdheden en regelmatige toegangsreviews om te voorkomen dat oude of onnodige regels blijven bestaan. Het proces moet ook voorzien in een mechanisme voor het automatisch intrekken van toegang wanneer deze niet langer nodig is, bijvoorbeeld wanneer een project wordt afgerond of een externe partner de samenwerking beëindigt.

Vanuit complianceperspectief moet de organisatie kunnen aantonen dat alle firewallregels zijn gedocumenteerd, goedgekeurd en regelmatig worden gecontroleerd. Dit vereist integratie met bestaande wijzigingsbeheerprocessen en auditlogging van alle wijzigingen aan de firewallconfiguratie. Elke wijziging moet worden vastgelegd met informatie over wie de wijziging heeft aangevraagd, wie deze heeft goedgekeurd, wat de businessjustificatie was, en wanneer de wijziging is doorgevoerd. Voor Nederlandse overheidsorganisaties betekent dit ook dat de configuratie moet voldoen aan de BIO-normen voor netwerksegmentatie en toegangscontrole, waarbij specifieke aandacht wordt besteed aan de scheiding tussen verschillende classificatieniveaus van gegevens. Organisaties die werken met gegevens met een hoog classificatieniveau, zoals staatsgeheimen of zeer gevoelige persoonsgegevens, moeten extra voorzorgsmaatregelen treffen om ervoor te zorgen dat deze gegevens alleen toegankelijk zijn vanaf specifiek goedgekeurde en beveiligde netwerkomgevingen. Dit kan betekenen dat er aparte firewallregels worden geconfigureerd voor verschillende classificatieniveaus, met strengere toegangscontroles voor gevoeligere gegevens.

Bewaking

Gebruik PowerShell-script storage-firewall-configured.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve bewaking van de Azure Storage-firewallconfiguratie vereist een gestructureerde aanpak die zowel proactieve controles als reactieve waarschuwingen omvat. De primaire bewakingstaak bestaat uit het regelmatig verifiëren dat alle opslagaccounts zijn geconfigureerd met firewallregels en dat de standaardactie is ingesteld op 'Weigeren'. Dit betekent dat voor elk opslagaccount moet worden gecontroleerd of de eigenschap DefaultAction daadwerkelijk is ingesteld op Deny, wat ervoor zorgt dat alleen expliciet toegestane netwerken toegang hebben.

Naast de basiscontrole op de standaardactie moeten beheerders ook regelmatig de lijst van toegestane IP-adresbereiken en virtuele netwerken controleren. Dit omvat het verifiëren dat alle regels nog steeds legitiem zijn, dat er geen onnodige of verouderde regels bestaan, en dat nieuwe regels correct zijn geïmplementeerd volgens het goedgekeurde wijzigingsbeheerproces. Het is essentieel om een baseline te hebben van alle verwachte firewallregels en deze regelmatig te vergelijken met de werkelijke configuratie om afwijkingen te detecteren.

Voor continue bewaking moeten organisaties gebruik maken van Azure Policy om automatisch te controleren of nieuwe opslagaccounts worden geconfigureerd met de juiste firewallinstellingen. Deze beleidsregels kunnen worden geconfigureerd om automatisch te waarschuwen wanneer een nieuw opslagaccount wordt aangemaakt zonder de vereiste firewallconfiguratie, of om zelfs te voorkomen dat dergelijke accounts worden aangemaakt totdat de juiste beveiligingsinstellingen zijn geconfigureerd. Daarnaast kunnen Azure Monitor-waarschuwingen worden geconfigureerd om direct te worden geïnformeerd wanneer wijzigingen worden aangebracht aan de firewallconfiguratie van bestaande opslagaccounts. Deze waarschuwingen moeten worden geïntegreerd met het Security Information and Event Management (SIEM) systeem van de organisatie voor centrale correlatie en analyse van beveiligingsgebeurtenissen. Door deze integratie kunnen beveiligingsteams snel reageren op verdachte activiteiten en kunnen ze patronen identificeren die wijzen op geavanceerde bedreigingen of interne bedreigingen. Het SIEM-systeem kan ook worden gebruikt om automatische responsacties te triggeren, zoals het tijdelijk blokkeren van toegang vanaf specifieke IP-adressen wanneer er verdachte activiteiten worden gedetecteerd.

Een belangrijk aspect van bewaking is het analyseren van toegangspogingen die worden geblokkeerd door de firewall. Deze informatie kan waardevolle inzichten opleveren over potentiële aanvalspogingen, misconfiguraties in netwerkregels, of onverwachte toegangspogingen van onbekende bronnen. Wanneer de firewall regelmatig toegangspogingen blokkeert vanaf specifieke IP-adressen of netwerkbereiken, kan dit wijzen op een georganiseerde aanval of op een misconfiguratie waarbij legitieme gebruikers of systemen niet correct zijn geconfigureerd in de firewallregels. Door regelmatig de Azure Storage-logboeken te analyseren kunnen beveiligingsteams patronen identificeren die wijzen op geavanceerde persistente bedreigingen of interne bedreigingen. Deze analyse moet niet alleen kijken naar individuele gebeurtenissen, maar ook naar trends over langere perioden om subtiele aanvallen te detecteren die zich over meerdere dagen of weken uitstrekken. Het is aanbevolen om deze logboeken minimaal wekelijks te beoordelen en automatische waarschuwingen in te stellen voor ongebruikelijke toegangspatronen of herhaalde mislukte toegangspogingen vanaf specifieke IP-adressen. Deze waarschuwingen moeten worden geconfigureerd met verschillende drempelwaarden voor verschillende scenario's, waarbij rekening wordt gehouden met factoren zoals het aantal mislukte pogingen, de geografische locatie van de bron, en het tijdstip van de pogingen.

Voor compliance-doeleinden moet de organisatie kunnen aantonen dat de firewallconfiguratie regelmatig wordt gecontroleerd en dat alle wijzigingen zijn gedocumenteerd. Dit vereist het bijhouden van een controlelogboek dat alle wijzigingen aan firewallregels vastlegt, inclusief wie de wijziging heeft aangebracht, wanneer deze is doorgevoerd, en wat de businessjustificatie was. Deze informatie moet minimaal zeven jaar worden bewaard volgens de Nederlandse archiefwetgeving en moet beschikbaar zijn voor interne en externe controles.

Herstel

Gebruik PowerShell-script storage-firewall-configured.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer een opslagaccount wordt gedetecteerd zonder correct geconfigureerde firewallregels, moet onmiddellijk actie worden ondernomen om de beveiligingspostuur te herstellen. De remediatieprocedure begint met een grondige analyse van de huidige configuratie en het identificeren van alle legitieme netwerkbronnen die toegang nodig hebben tot het opslagaccount. Dit is een kritieke stap omdat het onjuist configureren van firewallregels kan leiden tot serviceonderbrekingen voor legitieme gebruikers en applicaties.

De primaire remediatieactie bestaat uit het configureren van de netwerkregelset via de Azure PowerShell-cmdlet Update-AzStorageAccountNetworkRuleSet. Deze cmdlet maakt het mogelijk om de standaardactie in te stellen op Weigeren en specifieke IP-adresbereiken, virtuele netwerken en Azure-services toe te voegen aan de toegestane lijst. Het is essentieel om deze wijziging eerst te testen in een niet-productieomgeving om te verifiëren dat alle benodigde netwerkbronnen correct zijn geconfigureerd en dat er geen onverwachte serviceonderbrekingen optreden. Tijdens deze testfase moeten alle gebruikte scenario's worden getest, inclusief toegang vanaf verschillende netwerklocaties, verschillende Azure-services die toegang nodig hebben, en verschillende authenticatiemethoden. Alleen wanneer alle tests succesvol zijn voltooid, moet de wijziging worden doorgevoerd in de productieomgeving. Het is ook belangrijk om een rollback-plan te hebben voor het geval er onverwachte problemen optreden na de implementatie.

Voor organisaties met een groot aantal opslagaccounts is het aanbevolen om een gestandaardiseerde remediatiescript te ontwikkelen dat automatisch alle opslagaccounts kan scannen en corrigeren. Dit script moet eerst een inventarisatie maken van alle bestaande firewallregels, deze vergelijken met een goedgekeurde baseline-configuratie, en vervolgens alleen wijzigingen aanbrengen voor accounts die afwijken van de gewenste staat. Het script moet ook uitgebreide logging bevatten van alle uitgevoerde acties voor auditdoeleinden. Deze logging moet informatie bevatten over welke accounts zijn gecontroleerd, welke afwijkingen zijn gevonden, welke wijzigingen zijn aangebracht, en of deze wijzigingen succesvol zijn doorgevoerd. Het script moet ook een dry-run modus hebben waarmee beheerders kunnen zien welke wijzigingen zouden worden aangebracht zonder deze daadwerkelijk door te voeren. Dit geeft beheerders de mogelijkheid om de impact van de wijzigingen te beoordelen voordat ze worden geïmplementeerd. Voor zeer grote omgevingen met honderden of duizenden opslagaccounts kan het script worden uitgevoerd in batches om de impact op de Azure-infrastructuur te beperken en om te voorkomen dat er te veel gelijktijdige wijzigingen worden doorgevoerd.

Tijdens de remediatieprocedure moet speciale aandacht worden besteed aan het voorkomen van serviceonderbrekingen. Dit betekent dat wijzigingen bij voorkeur moeten worden doorgevoerd tijdens onderhoudsvensters wanneer de impact op gebruikers en systemen minimaal is. Er moet ook een herstelprocedure beschikbaar zijn voor het geval er onverwachte problemen optreden, zodat wijzigingen snel kunnen worden teruggedraaid zonder dat dit leidt tot langdurige serviceonderbrekingen. Deze herstelprocedure moet worden getest voordat deze wordt gebruikt in een productieomgeving om ervoor te zorgen dat deze correct werkt en dat beheerders bekend zijn met de stappen die moeten worden genomen. Voor kritieke productiesystemen is het aanbevolen om eerst een testaccount te configureren met de nieuwe firewallregels en deze uitgebreid te testen voordat de wijzigingen worden toegepast op productieaccounts. Deze test moet alle gebruikte scenario's omvatten, inclusief toegang vanaf verschillende netwerklocaties, verschillende Azure-services, en verschillende authenticatiemethoden. Alleen wanneer alle tests succesvol zijn voltooid en er geen onverwachte problemen zijn opgetreden, moeten de wijzigingen worden doorgevoerd in de productieomgeving. Het is ook belangrijk om gebruikers en applicatie-eigenaren te informeren over geplande wijzigingen en om hen te voorzien van duidelijke instructies over wat ze kunnen verwachten en wat ze moeten doen als ze problemen ondervinden.

Na het implementeren van de firewallregels moet de organisatie een verificatieproces uitvoeren om te bevestigen dat alle legitieme toegang nog steeds functioneert en dat ongeautoriseerde toegang daadwerkelijk wordt geblokkeerd. Dit omvat het testen van toegang vanaf goedgekeurde netwerken, het verifiëren dat geblokkeerde toegangspogingen correct worden gelogd, en het controleren van de impact op afhankelijke services en applicaties. Het verificatieproces moet uitgebreid zijn en alle gebruikte scenario's omvatten, inclusief toegang vanaf verschillende netwerklocaties, verschillende Azure-services, en verschillende authenticatiemethoden. Het is ook belangrijk om te verifiëren dat de logging correct werkt en dat alle toegangspogingen, zowel succesvolle als geblokkeerde, correct worden vastgelegd in de Azure Storage-logboeken. Deze logboeken moeten regelmatig worden gecontroleerd in de eerste weken na de implementatie om te verifiëren dat alles correct werkt en om eventuele problemen snel te kunnen identificeren en oplossen. Het is ook belangrijk om gebruikers en applicatie-eigenaren te informeren over de wijzigingen en hen te voorzien van duidelijke instructies over hoe zij toegang kunnen verkrijgen indien nodig. Deze instructies moeten informatie bevatten over welke netwerken zijn goedgekeurd, hoe nieuwe toegangsverzoeken kunnen worden ingediend, en wat de verwachte verwerkingstijd is voor dergelijke verzoeken.

Compliance en Audit

De implementatie van Azure Storage-firewallregels is een verplichte vereiste voor naleving van verschillende beveiligingsstandaarden en complianceframeworks die relevant zijn voor Nederlandse overheidsorganisaties. De belangrijkste compliancevereisten worden gesteld door de CIS Microsoft Azure Foundations Benchmark, specifiek controle 3.8, en de Baseline Informatiebeveiliging Overheid (BIO), met name norm 13.01 voor netwerktoegangscontrole en authenticatie.

CIS Benchmark controle 3.8 vereist expliciet dat opslagaccounts zijn geconfigureerd met netwerkregels die de toegang beperken tot specifieke netwerken. Deze controle is geclassificeerd als Level 1, wat betekent dat het een fundamentele beveiligingsmaatregel is die moet worden geïmplementeerd door alle organisaties, ongeacht hun grootte of complexiteit. De controle richt zich op het voorkomen van ongeautoriseerde toegang tot gevoelige gegevens door het beperken van de netwerktoegang tot alleen geautoriseerde bronnen. Voor Nederlandse organisaties die werken met geclassificeerde informatie is naleving van deze controle niet alleen een best practice, maar vaak ook een wettelijke vereiste.

De BIO-norm 13.01 stelt specifieke eisen aan netwerktoegangscontrole en authenticatie voor systemen die worden gebruikt door Nederlandse overheidsorganisaties. Deze norm vereist dat organisaties passende maatregelen treffen om ongeautoriseerde toegang tot informatiesystemen te voorkomen, waarbij netwerksegmentatie en toegangscontrole een centrale rol spelen. De implementatie van firewallregels voor Azure Storage-accounts draagt direct bij aan het voldoen aan deze norm door ervoor te zorgen dat alleen geautoriseerde netwerken en systemen toegang hebben tot gevoelige gegevens. Dit is met name relevant voor organisaties die werken met persoonsgegevens en moeten voldoen aan de Algemene Verordening Gegevensbescherming (AVG).

Voor auditdoeleinden moeten organisaties kunnen aantonen dat alle opslagaccounts zijn geconfigureerd met de juiste firewallregels en dat deze configuratie regelmatig wordt gecontroleerd en bijgewerkt. Dit vereist uitgebreide documentatie van de firewallconfiguratie, inclusief een overzicht van alle toegestane IP-adresbereiken en virtuele netwerken, de businessjustificatie voor elke regel, en de datum waarop de regel is toegevoegd of gewijzigd. Daarnaast moeten alle wijzigingen aan de firewallconfiguratie worden gelogd in een centraal auditlogboek dat minimaal zeven jaar wordt bewaard volgens de Nederlandse archiefwetgeving.

Tijdens externe audits moeten organisaties kunnen demonstreren dat de firewallconfiguratie effectief is geïmplementeerd en wordt gehandhaafd. Dit omvat het kunnen tonen van bewijs dat alle opslagaccounts zijn geconfigureerd met de standaardactie 'Weigeren', dat er een gestructureerd proces bestaat voor het aanvragen en goedkeuren van nieuwe firewallregels, en dat regelmatige controles worden uitgevoerd om te verifiëren dat de configuratie nog steeds voldoet aan de compliancevereisten. Deze controles moeten worden gedocumenteerd en moeten aantonen dat er een systematische aanpak is voor het identificeren en oplossen van afwijkingen. Het is ook belangrijk om te kunnen aantonen dat er procedures bestaan voor het reageren op beveiligingsincidenten waarbij de firewallconfiguratie mogelijk is aangepast door onbevoegde personen. Deze procedures moeten duidelijk beschrijven welke stappen moeten worden genomen wanneer een dergelijk incident wordt gedetecteerd, inclusief het isoleren van getroffen systemen, het onderzoeken van de omvang van het incident, en het herstellen van de juiste configuratie. De procedures moeten ook voorzien in het documenteren van het incident en het rapporteren ervan aan relevante stakeholders, inclusief management, compliance officers, en indien nodig externe autoriteiten zoals de Autoriteit Persoonsgegevens of andere relevante toezichthouders.

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 Storage Firewall Configured .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.27 Controleert of storage firewall is geconfigureerd. .NOTES Filename: storage-firewall-configured.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.27 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Storage Firewall Configured" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue $result = @{ TotalAccounts = $storageAccounts.Count; FirewallConfigured = 0 } foreach ($account in $storageAccounts) { if ($account.NetworkRuleSet.DefaultAction -eq 'Deny') { $result.FirewallConfigured++ } } 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 "Firewall Configured: $($r.FirewallConfigured)" -ForegroundColor $(if ($r.FirewallConfigured -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nFirewall Configured: $($r.FirewallConfigured)/$($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 "Firewall Configured: $($r.FirewallConfigured)" -ForegroundColor $(if ($r.FirewallConfigured -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nFirewall Configured: $($r.FirewallConfigured)/$($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: Onbeperkte toegang tot opslagaccounts resulteert in wereldwijde blootstelling via internet. Iedereen met een Shared Access Signature-token kan vanaf elke locatie ter wereld toegang verkrijgen tot de gegevens. Dit maakt opslagaccounts kwetsbaar voor brute force-aanvallen, credential stuffing-aanvallen en andere geavanceerde bedreigingen. Naleving: CIS 3.8, BIO 13.01. Het risico is KRITIEK - netwerkisolatie is essentieel voor het beschermen van gevoelige gegevens tegen ongeautoriseerde toegang.

Management Samenvatting

Opslagfirewall geconfigureerd: Beperk opslagtoegang tot specifieke IP-adresbereiken, virtuele netwerken en vertrouwde Azure-services alleen (standaard weigeren). Blokkeert ongeautoriseerde netwerktoegang. Activering: Opslagaccount → Netwerken → Firewall: Geselecteerde netwerken. Gratis. Verplicht CIS 3.8, BIO 13.01. Implementatie: 2-4 uur (IP-inventarisatie en testen). Essentiële netwerkbeveiliging voor opslag.