Defense In Depth Implementatie Voor Azure Cloud Omgevingen

Moderne cloudomgevingen worden blootgesteld aan een breed scala aan bedreigingen, van gerichte aanvallen door geavanceerde persistent threats tot opportunistische ransomware-campagnes en insider threats. Het vertrouwen op een enkele beveiligingsmaatregel – zoals alleen netwerkfirewalls of alleen identity protection – creëert een kwetsbaar punt waar een succesvolle doorbraak directe toegang tot kritieke assets kan betekenen. In de praktijk zien we dat organisaties die slechts één of twee beveiligingslagen hebben geïmplementeerd, significant kwetsbaarder zijn voor aanvallen die specifiek gericht zijn op het omzeilen van die ene maatregel. Een aanvaller die bijvoorbeeld een gecompromitteerd beheerdersaccount heeft verkregen, kan zonder aanvullende beveiligingslagen direct toegang krijgen tot alle resources binnen een abonnement. Defense in Depth lost dit op door meerdere onafhankelijke beveiligingslagen te implementeren die elkaar aanvullen en versterken. Wanneer één laag faalt – bijvoorbeeld wanneer een identiteit wordt gecompromitteerd – blijven andere lagen zoals netwerksegmentatie, resource locks, logging en monitoring actief om verdere escalatie te voorkomen of te detecteren. Voor Nederlandse overheidsorganisaties is dit principe extra relevant omdat zij moeten voldoen aan strikte compliance-eisen vanuit NIS2, BIO en AVG, die allemaal vereisen dat passende technische en organisatorische maatregelen zijn genomen op basis van een risicoanalyse. Een goed geïmplementeerd Defense in Depth-raamwerk levert het bewijs dat organisaties proactief hebben geïnvesteerd in beveiliging op meerdere niveaus, wat essentieel is voor het aantonen van due diligence bij audits en toezicht.

Implementatie

Dit artikel beschrijft een concrete implementatie van Defense in Depth voor Azure-omgevingen, specifiek toegespitst op de context van Nederlandse overheidsorganisaties. Het raamwerk is opgebouwd uit zeven beveiligingslagen die elk een specifiek aspect van cloudbeveiliging adresseren. De eerste laag betreft identiteits- en toegangsbeheer, waarbij multi-factor authenticatie, privileged identity management, just-in-time toegang en role-based access control worden geïmplementeerd om te voorkomen dat onbevoegden toegang krijgen tot resources. De tweede laag richt zich op netwerkbeveiliging met private endpoints, network security groups, Azure Firewall, DDoS-bescherming en netwerksegmentatie om ongeautoriseerde netwerktoegang te blokkeren. De derde laag betreft compute-beveiliging met endpoint protection, vulnerability management, secure boot en host-based firewalls op virtuele machines en containers. De vierde laag focust op applicatiebeveiliging met web application firewalls, secure coding practices, API-beveiliging en runtime protection. De vijfde laag adresseert data-beveiliging met encryptie in transit en at rest, data classification, data loss prevention en backup-encryptie. De zesde laag betreft logging en monitoring met Azure Monitor, Log Analytics, Azure Sentinel en security information and event management om bedreigingen te detecteren en te reageren. De zevende en laatste laag richt zich op governance en compliance met Azure Policy, resource locks, compliance-dashboards en regelmatige audits. Het artikel beschrijft voor elke laag concrete implementatiestappen, best practices, Azure-native services die kunnen worden ingezet, en hoe de lagen onderling samenwerken om een robuuste beveiligingspostuur te creëren. Daarnaast wordt uitgelegd hoe dit raamwerk aansluit bij NIS2-verplichtingen, BIO-normen en Zero Trust-architectuurprincipes.

Vereisten

Een succesvolle implementatie van Defense in Depth in Azure vereist een grondige voorbereiding op zowel technisch als organisatorisch vlak. De eerste vereiste is een volledige inventarisatie van alle Azure-resources, abonnementen, management groups en workloads die onderdeel uitmaken van de omgeving. Zonder een compleet overzicht is het onmogelijk om te bepalen welke beveiligingslagen waar moeten worden toegepast en of er gaten in de beveiliging bestaan. Deze inventarisatie moet niet alleen technische details bevatten – zoals resourcegroepen, virtuele machines, storage accounts en netwerken – maar ook functionele context: welke workloads zijn kritiek voor de dienstverlening, welke data wordt verwerkt en wat is de classificatie daarvan, welke externe partijen hebben toegang en wat zijn de compliance-vereisten per workload. Deze informatie vormt de basis voor het bepalen van de prioritering en de intensiteit van beveiligingsmaatregelen per laag. Een tweede cruciale vereiste is het hebben van een duidelijk beveiligingsbeleid en risicokader dat specifiek is uitgewerkt voor cloud- en Azure-omgevingen. Dit beleid moet definiëren welke beveiligingslagen verplicht zijn voor welke typen workloads, welke data-classificaties welke aanvullende maatregelen vereisen, en wat de acceptabele restrisico's zijn na implementatie van de lagen. Binnen Nederlandse overheidsorganisaties moet dit beleid expliciet aansluiten bij het BIO-raamwerk, NIS2-verplichtingen en AVG-vereisten. Het beleid moet schriftelijk zijn vastgelegd, door het bestuur zijn goedgekeurd en regelmatig worden herzien op basis van veranderende dreigingen en nieuwe Azure-services. Zonder een dergelijk kader bestaat het risico dat beveiligingslagen ad hoc worden geïmplementeerd zonder duidelijke samenhang of dat bepaalde lagen worden overgeslagen omdat de noodzaak niet duidelijk is. Technisch gezien vereist Defense in Depth de beschikbaarheid van de juiste Azure-licenties en services. Voor identiteitsbeveiliging is Azure AD Premium P2 of Microsoft Entra ID P2 vereist voor geavanceerde functies zoals Privileged Identity Management, Identity Protection en Conditional Access. Voor netwerkbeveiliging zijn Azure Firewall, Network Watcher en DDoS Protection Standard nodig voor volledige bescherming. Voor logging en monitoring zijn Azure Monitor, Log Analytics en Azure Sentinel essentieel om bedreigingen te detecteren en te reageren. Voor governance zijn Azure Policy en Azure Blueprints nodig om beveiligingsconfiguraties consistent af te dwingen. Organisaties moeten ervoor zorgen dat zij over de benodigde licenties beschikken voordat zij beginnen met de implementatie, anders kunnen zij niet alle beveiligingslagen volledig inrichten. Daarnaast is er een duidelijke rol- en verantwoordelijkheidsverdeling nodig tussen verschillende teams en functies. De CISO of security officer is verantwoordelijk voor het opstellen van het beveiligingsbeleid en het toezicht op de implementatie, maar individuele teams blijven verantwoordelijk voor de concrete implementatie van beveiligingslagen binnen hun eigen workloads. Cloud architects zijn verantwoordelijk voor het ontwerpen van de beveiligingsarchitectuur en het zorgen dat lagen onderling goed samenwerken. Security engineers zijn verantwoordelijk voor de technische implementatie en configuratie van beveiligingsservices. Operations teams zijn verantwoordelijk voor het dagelijks beheer en monitoring van beveiligingslagen. Zonder deze duidelijke verdeling ontstaat verwarring over wie verantwoordelijk is voor welke laag, wat kan leiden tot gaten in de beveiliging of overlappende inspanningen. Tot slot vereist Defense in Depth een volwassen proces voor continue monitoring, evaluatie en verbetering. Beveiligingslagen zijn niet statisch maar moeten regelmatig worden geëvalueerd op effectiviteit, bijgewerkt op basis van nieuwe dreigingen en Azure-services, en getest om te verifiëren dat zij nog steeds functioneren zoals bedoeld. Dit vereist vaste planningsmomenten in de governancekalender, waarin beveiligingslagen worden gereviewd, nieuwe bedreigingen worden geëvalueerd en verbetermaatregelen worden geïdentificeerd. Daarnaast moeten er processen zijn voor het reageren op security incidents waarbij wordt geanalyseerd welke lagen hebben gefaald en hoe deze kunnen worden verbeterd. Alleen met een dergelijk continu verbeterproces blijft een Defense in Depth-implementatie effectief in de tijd.

Implementatie

Gebruik PowerShell-script defense-in-depth-implementation.ps1 (functie Invoke-Implementation) – Valideert en implementeert Defense in Depth beveiligingslagen.

De implementatie van Defense in Depth in Azure begint met het opstellen van een gedetailleerd implementatieplan dat alle zeven beveiligingslagen omvat en prioriteert op basis van risico en kritiekheid van workloads. Het plan moet per laag beschrijven welke Azure-services worden ingezet, welke configuraties worden toegepast, welke resources worden beschermd en in welke volgorde de implementatie plaatsvindt. In de praktijk wordt vaak begonnen met de fundamenten – identiteits- en toegangsbeheer en governance – omdat deze lagen de basis vormen voor alle andere beveiligingsmaatregelen. Vervolgens worden netwerk- en compute-beveiliging geïmplementeerd, gevolgd door applicatie- en data-beveiliging, en tot slot logging en monitoring om alle lagen te kunnen bewaken. De eerste laag – identiteits- en toegangsbeheer – wordt geïmplementeerd door Azure AD of Microsoft Entra ID te configureren met multi-factor authenticatie voor alle gebruikers, privileged identity management voor beheerdersrollen, conditional access policies die toegang beperken op basis van locatie, apparaat en risico, en just-in-time toegang voor beheerderstoegang tot virtuele machines. Daarnaast worden role-based access control policies geconfigureerd die het principe van least privilege afdwingen, zodat gebruikers alleen de minimale rechten hebben die nodig zijn voor hun functie. Break-glass accounts worden aangemaakt voor noodsituaties, en regelmatige access reviews worden ingericht om te verifiëren dat toegangsrechten nog steeds nodig zijn. Deze laag vormt de eerste verdedigingslinie tegen ongeautoriseerde toegang en is essentieel omdat gecompromitteerde identiteiten kunnen worden gebruikt om andere beveiligingslagen te omzeilen. De tweede laag – netwerkbeveiliging – wordt geïmplementeerd door private endpoints te configureren voor alle kritieke Azure-services, zodat deze niet via het publieke internet toegankelijk zijn. Network security groups worden geconfigureerd met restrictieve regels die alleen toegestaan verkeer toestaan, en Azure Firewall wordt ingezet voor gecentraliseerde netwerkbeveiliging en threat intelligence. DDoS Protection Standard wordt geactiveerd voor alle publieke endpoints om te beschermen tegen distributed denial-of-service aanvallen. Virtual networks worden gesegmenteerd met subnetten voor verschillende workload-tiers, en network watcher wordt ingeschakeld om netwerkverkeer te monitoren en te analyseren. Deze laag voorkomt dat aanvallers via het netwerk toegang krijgen tot resources, zelfs wanneer identiteiten zijn gecompromitteerd. De derde laag – compute-beveiliging – wordt geïmplementeerd door Microsoft Defender for Cloud in te schakelen voor alle virtuele machines en containers, wat endpoint protection, vulnerability scanning en threat detection biedt. Virtuele machines worden geconfigureerd met secure boot, trusted launch en host-based firewalls. Containers worden gescand op kwetsbaarheden voordat zij worden gedeployed, en alleen goedgekeurde container images mogen worden gebruikt. Automatic updates worden ingeschakeld voor operating systems en applicaties, en security baselines worden toegepast via Azure Policy. Deze laag beschermt de compute-laag tegen malware, kwetsbaarheden en andere bedreigingen op het niveau van virtuele machines en containers. De vierde laag – applicatiebeveiliging – wordt geïmplementeerd door web application firewalls te configureren voor alle publiek toegankelijke applicaties, met regels die beschermen tegen OWASP Top 10 kwetsbaarheden en andere bekende aanvallen. API Management wordt geconfigureerd met authenticatie, autorisatie, rate limiting en threat protection. Secure coding practices worden geïmplementeerd via development pipelines met security scanning, code analysis en dependency checking. Runtime application self-protection wordt ingezet waar mogelijk om aanvallen tijdens uitvoering te detecteren en te blokkeren. Deze laag beschermt applicaties tegen aanvallen op applicatieniveau, zelfs wanneer andere lagen zijn doorbroken. De vijfde laag – data-beveiliging – wordt geïmplementeerd door encryptie in transit te forceren via TLS 1.2 of hoger voor alle netwerkverbindingen, en encryptie at rest voor alle storage accounts, databases en back-ups met customer-managed keys waar mogelijk. Data classification wordt toegepast om gevoelige data te identificeren en te labelen, en data loss prevention policies worden geconfigureerd om te voorkomen dat gevoelige data onbedoeld wordt gedeeld of geëxporteerd. Back-ups worden versleuteld en opgeslagen in geografisch gescheiden locaties met immutable storage waar mogelijk. Deze laag beschermt data tegen ongeautoriseerde toegang, zelfs wanneer andere beveiligingslagen falen. De zesde laag – logging en monitoring – wordt geïmplementeerd door Azure Monitor en Log Analytics in te schakelen voor alle resources, met diagnostische instellingen die alle relevante logs verzamelen. Azure Sentinel wordt geconfigureerd als Security Information and Event Management oplossing, met detection rules voor bekende bedreigingen en anomalous gedrag. Security alerts worden geconfigureerd voor kritieke gebeurtenissen, met geautomatiseerde respons waar mogelijk. Regelmatige security assessments worden uitgevoerd om de effectiviteit van beveiligingslagen te evalueren. Deze laag zorgt ervoor dat bedreigingen worden gedetecteerd en dat er snel kan worden gereageerd op security incidents. De zevende laag – governance en compliance – wordt geïmplementeerd door Azure Policy te gebruiken om beveiligingsconfiguraties consistent af te dwingen over alle abonnementen en resources. Resource locks worden toegepast op kritieke resources om te voorkomen dat zij per ongeluk worden verwijderd of gewijzigd. Compliance-dashboards worden ingericht om de naleving van beveiligingsstandaarden te monitoren en te rapporteren. Regelmatige audits worden uitgevoerd om te verifiëren dat alle beveiligingslagen correct zijn geïmplementeerd en functioneren. Deze laag zorgt ervoor dat beveiligingsmaatregelen consistent worden toegepast en dat de organisatie kan aantonen dat zij voldoet aan compliance-vereisten.

Monitoring

Gebruik PowerShell-script defense-in-depth-implementation.ps1 (functie Invoke-Monitoring) – Monitort de status van alle Defense in Depth beveiligingslagen.

Effectieve monitoring van Defense in Depth in Azure is essentieel om te waarborgen dat alle beveiligingslagen correct blijven functioneren en dat bedreigingen tijdig worden gedetecteerd. Monitoring richt zich niet alleen op individuele lagen, maar vooral ook op de samenhang tussen lagen en de algehele beveiligingspostuur. In de praktijk betekent dit dat de organisatie een beperkt aantal kernindicatoren definieert – Key Security Indicators (KSI's) – die periodiek worden gemeten en gerapporteerd aan CISO, CIO en bestuur. Voor elke beveiligingslaag worden specifieke metrics gedefinieerd die aangeven of de laag effectief functioneert. Voor de identiteitslaag worden metrics gemeten zoals het percentage gebruikers met multi-factor authenticatie, het aantal privileged accounts onder PIM, het aantal failed login attempts, en het aantal accounts met excessive permissions. Voor de netwerklaag worden metrics gemeten zoals het percentage resources achter private endpoints, het aantal NSG rules die te permissief zijn, het aantal DDoS-aanvallen die zijn geblokkeerd, en het percentage netwerkverkeer dat wordt gecontroleerd door Azure Firewall. Voor de compute-laag worden metrics gemeten zoals het percentage virtuele machines met endpoint protection, het aantal gedetecteerde kwetsbaarheden, het percentage systemen met security updates, en het aantal containers met security scanning. Voor de applicatielaag worden metrics gemeten zoals het aantal WAF-blokkeringen, het aantal API-aanvallen die zijn gedetecteerd, en het percentage applicaties met security scanning in de pipeline. Voor de data-laag worden metrics gemeten zoals het percentage data met encryptie, het aantal DLP-violations, en de status van back-up-encryptie. Voor de logging-laag worden metrics gemeten zoals de dekking van diagnostische instellingen, het aantal security alerts, en de response times op incidents. Voor de governance-laag worden metrics gemeten zoals het percentage resources met policy-compliance, het aantal resources met resource locks, en de status van compliance-dashboards. Een belangrijk onderdeel van monitoring is het creëren van geïntegreerde dashboards die de status van alle beveiligingslagen samenbrengen in één overzichtelijk beeld. In plaats van afzonderlijke dashboards per laag, wordt informatie samengebracht in een centraal security dashboard dat laat zien hoe de verschillende lagen samenwerken en waar potentiële zwaktes bestaan. Dit dashboard moet niet alleen technische details tonen, maar vooral ook risico-indicatoren die begrijpelijk zijn voor bestuurders en niet-technische stakeholders. Binnen Nederlandse overheidsorganisaties sluit dit aan bij de behoefte aan overzichtelijke rapportages die voldoen aan NIS2- en BIO-verplichtingen voor security reporting. De monitoringfunctie moet ook concrete drempelwaarden en escalatiepaden definiëren. Voor elke KSI wordt vastgelegd bij welke waarde het risiconiveau verandert – bijvoorbeeld van 'aanvaardbaar' naar 'zorgelijk' of 'onacceptabel' – en welke acties dan vereist zijn. Dit kan variëren van het verplicht opstellen van een verbeterplan binnen een maand, via het tijdelijk blokkeren van nieuwe resources die niet voldoen aan beveiligingsstandaarden, tot het escaleren naar de CISO of het bestuurlijke crisisteam bij zeer ernstige afwijkingen. Deze drempelwaarden worden afgestemd op de bestaande risicobereidheid van de organisatie en op wettelijke vereisten vanuit NIS2 en BIO. Tot slot vereist monitoring een nauwe koppeling tussen de dagelijkse operationele securityprocessen – zoals SOC-monitoring, vulnerability management en incident response – en de meerjarige beveiligingssturing. Operationele teams leveren signalen over concrete incidenten, near misses en ontdekt misbruik van configuratiefouten. Deze signalen moeten systematisch worden geanalyseerd om te bepalen of zij duiden op structurele tekortkomingen in beveiligingslagen of de configuratie daarvan. Wanneer bijvoorbeeld meerdere incidenten wijzen op onvoldoende netwerksegmentatie of zwakke identity controls, moet dit leiden tot een herziening van de relevante beveiligingslagen en verbetermaatregelen. Het PowerShell-script dat bij dit artikel hoort, kan dienen als technisch hulpmiddel om op vaste momenten kernstatistieken uit Azure op te halen – zoals policy-compliance, security score, en de status van beveiligingsservices – en die als bijlage toe te voegen aan periodieke security rapportages. Zo ontstaat een gesloten feedbacklus tussen monitoring, analyse en bijsturing.

Compliance en Auditing

Defense in Depth is niet alleen een best practice voor cloudbeveiliging, maar een expliciete eis vanuit verschillende nationale en internationale kaders die gelden voor Nederlandse overheidsorganisaties en andere vitale of belangrijke entiteiten. De NIS2-richtlijn verlangt dat organisaties passende technische en organisatorische maatregelen treffen voor risicobeheersing en beveiliging, waarbij wordt benadrukt dat beveiliging op meerdere niveaus moet worden toegepast. Dit betekent concreet dat organisaties niet kunnen volstaan met een enkele beveiligingsmaatregel, maar moeten kunnen aantonen dat zij een gelaagde beveiligingsaanpak hebben geïmplementeerd die bescherming biedt tegen verschillende typen bedreigingen. Het hier beschreven Defense in Depth-raamwerk levert precies dat aantoonbare spoor: van identiteitsbeveiliging via netwerk- en compute-beveiliging tot data-protectie en governance. Het BIO-raamwerk benadrukt in meerdere thema's – met name thema 5 (Toegangsbeheer), thema 6 (Cryptografie), thema 7 (Logging en monitoring) en thema 12 (Beveiligingsmaatregelen) – dat overheidsorganisaties structureel moeten bepalen welke beveiligingsmaatregelen nodig zijn en hoe deze worden geïmplementeerd en gemonitord. In moderne omgevingen bevinden veel van deze maatregelen zich in Azure, en zonder een specifiek uitgewerkt Defense in Depth-kader is het vrijwel onmogelijk om aan te tonen dat de BIO-eisen voor gelaagde beveiliging daadwerkelijk zijn ingevuld voor deze platformlaag. Door Defense in Depth te integreren in hetzelfde beveiligingskader en dezelfde governancecyclus als on-premises systemen en andere IT-diensten, kan de organisatie aan auditors laten zien dat cloud niet als losstaand eiland wordt behandeld, maar als integraal onderdeel van de beveiligingsarchitectuur. Ook de AVG speelt een rol in Defense in Depth, met name waar het gaat om verwerking van persoonsgegevens in Azure-diensten. Artikel 32 verplicht organisaties tot het nemen van passende technische en organisatorische maatregelen op basis van een risicoanalyse, waarbij wordt benadrukt dat maatregelen moeten worden gelaagd om verschillende typen bedreigingen te adresseren. In de context van Azure betekent dit onder meer dat men moet beoordelen welke risico's er zijn voor verlies, ongeautoriseerde toegang of onbeschikbaarheid van persoonsgegevens door cloud-specifieke dreigingen, en welke gelaagde maatregelen hiervoor zijn gekozen (zoals encryptie, logging, toegangsbeperkingen, netwerksegmentatie en monitoring). Deze keuzes en de onderbouwing ervan moeten worden gedocumenteerd, zodat bij een datalek of audit kan worden aangetoond dat de organisatie weloverwogen en proportionele maatregelen heeft getroffen op meerdere niveaus. Auditors – zowel interne auditdiensten als externe toezichthouders – verwachten steeds vaker dat organisaties een consistente methode hanteren voor beveiligingsarchitectuur over alle technologieën heen, inclusief cloud. Het beschreven Defense in Depth-raamwerk biedt hiervoor een duidelijke kapstok. Voor auditdoeleinden is het essentieel dat de organisatie kan laten zien dat: er een formeel vastgesteld beveiligingskader is dat ook voor Azure geldt; alle zeven beveiligingslagen zijn geïmplementeerd en gemonitord; de resultaten zijn vastgelegd in beveiligingsdocumentatie met toegewezen eigenaarschap; en dat uitgevoerde maatregelen en resterende risico's traceerbaar zijn naar concrete besluiten en acties. Het gebruik van gestandaardiseerde formats, centrale opslag van configuraties en systematische koppeling met compliance-dashboards is hierbij onmisbaar. Het PowerShell-script uit dit artikel kan aanvullend worden gebruikt als bron van objectief bewijsmateriaal over de technische inrichting van de Azure-tenant, bijvoorbeeld om te onderbouwen dat er daadwerkelijk beveiligingslagen zijn geïmplementeerd en dat deze correct functioneren.

Remediatie

Gebruik PowerShell-script defense-in-depth-implementation.ps1 (functie Invoke-Remediation) – Identificeert en herstelt ontbrekende of zwakke beveiligingslagen.

Wanneer uit audits, incidenten of periodieke assessments blijkt dat Defense in Depth onvoldoende is geïmplementeerd of dat bepaalde beveiligingslagen zwak zijn, is een gestructureerd remediatieproces noodzakelijk om het beveiligingsniveau snel en gecontroleerd te verhogen. De eerste stap in dit proces is het uitvoeren van een gap-analyse ten opzichte van het gewenste Defense in Depth-raamwerk: welke beveiligingslagen zijn al aanwezig en correct geconfigureerd, welke lagen zijn gedeeltelijk geïmplementeerd maar hebben tekortkomingen, en welke lagen ontbreken volledig? Deze gap-analyse wordt idealiter uitgevoerd door een multidisciplinair team bestaande uit CISO, cloud architect, security engineers en vertegenwoordigers uit de business. Het resultaat is een overzicht van concrete tekortkomingen per beveiligingslaag, geprioriteerd op basis van risico en compliance-impact. Vervolgens wordt per tekortkoming een gerichte remediatiestrategie bepaald. Ontbreekt bijvoorbeeld de identiteitslaag volledig, dan is de remediatie het inrichten van een project waarin multi-factor authenticatie, PIM en conditional access worden geconfigureerd voor alle gebruikers en resources. Is de netwerklaag gedeeltelijk aanwezig maar ontbreken private endpoints voor kritieke services, dan ligt de nadruk op het migreren van publieke endpoints naar private endpoints. In situaties waarin meerdere lagen zwak zijn – wat zeker bij versneld gecreëerde cloudomgevingen vaak voorkomt – moet een gefaseerde aanpak worden gevolgd waarbij eerst de fundamenten (identiteit en governance) worden versterkt, gevolgd door netwerk- en compute-beveiliging, en tot slot applicatie- en data-beveiliging. Een belangrijk remediatiepad betreft het herstellen van ontbrekende of zwakke logging en monitoring. Wanneer de zesde laag onvoldoende is geïmplementeerd, kunnen andere beveiligingslagen niet effectief worden gemonitord en kunnen bedreigingen niet tijdig worden gedetecteerd. Remediatie betekent in dit geval het inschakelen van diagnostische instellingen voor alle resources, het configureren van Log Analytics workspaces, het inrichten van Azure Sentinel voor security monitoring, en het opstellen van detection rules voor bekende bedreigingen. Zonder adequate logging en monitoring blijven organisaties blind voor aanvallen en kunnen zij niet aantonen dat beveiligingslagen effectief functioneren. Technisch gezien kan remediatie ook bestaan uit het herstructureren van de Azure-tenant om beveiligingslagen beter te kunnen afdwingen. Denk aan het herinrichten van management groups en abonnementen om betere scheiding te creëren tussen verschillende workload-tiers, het centraliseren van netwerkbeveiliging via Azure Firewall, of het implementeren van Azure Policy om beveiligingsconfiguraties consistent af te dwingen. Deze stappen moeten altijd worden uitgevoerd op basis van een gedetailleerd migratieplan, inclusief impactanalyse, fallbackscenario's en communicatie met betrokken teams. Defense in Depth betekent in dit verband dat herstructurering niet alleen wordt bekeken vanuit technische optimalisatie, maar vooral vanuit de vraag: vergroot dit de beveiliging en maakt het de verschillende lagen effectiever? Tot slot moet elke remediatie-inspanning worden afgesloten met een expliciete evaluatie en bijstelling van het Defense in Depth-raamwerk. De lessen uit incidenten en audits – bijvoorbeeld een succesvolle aanval die meerdere lagen heeft doorbroken of onvoldoende detectie van bedreigingen – moeten structureel worden verwerkt in de beveiligingsarchitectuur, configuraties en procedures. Het is raadzaam om na afronding van een remediatieprogramma een integrale security assessment te laten uitvoeren door een interne auditdienst of een onafhankelijke derde, zodat kan worden vastgesteld of het nieuwe niveau van Defense in Depth daadwerkelijk in lijn is met NIS2, BIO en de verwachtingen van het bestuur. De uitkomsten hiervan worden vastgelegd in beveiligingsdocumentatie en vormen het nieuwe vertrekpunt voor de reguliere cyclus van monitoring en verbetering.

Compliance & Frameworks

• BIO: 5.01.01, 6.01.01, 7.01.01, 12.01.01 - Gelaagde beveiliging voor cloudomgevingen met meerdere beveiligingslagen
• ISO 27001:2022: A.9.1.1, A.9.2.1, A.12.1.1, A.12.2.1 - Access control, network security, operations security en information security management
• NIS2: Artikel - Passende technische en organisatorische maatregelen voor risicobeheersing en beveiliging

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

Implementeer Defense in Depth met zeven beveiligingslagen: identiteit, netwerk, compute, applicatie, data, logging en governance. Essentieel voor NIS2 en BIO compliance. Implementatie: 60 uur.

• Implementatietijd: 60 uur
• FTE required: 0.5 FTE