Azure Resource Locks Configuratie Verificatie

Zonder systematische verificatie van Resource Lock configuraties lopen organisaties aanzienlijke risico's op het gebied van beveiliging en compliance. Het meest kritieke risico is dat organisaties ten onrechte aannemen dat hun resources beschermd zijn, terwijl in werkelijkheid locks ontbreken, incorrect zijn geconfigureerd, of per ongeluk zijn verwijderd zonder dat dit wordt opgemerkt. Deze valse veiligheid kan leiden tot catastrofale gevolgen wanneer een resource daadwerkelijk wordt verwijderd, omdat organisaties erop vertrouwen dat locks de verwijdering zouden voorkomen, terwijl dit niet het geval is. Bovendien kunnen locks per ongeluk worden verwijderd tijdens routineonderhoud, wijzigingsbeheerprocessen, of door geautomatiseerde scripts die niet correct zijn geconfigureerd, zonder dat organisaties zich hiervan bewust zijn totdat het te laat is. Compliance-frameworks zoals de CIS Azure Benchmark, ISO 27001 en de BIO-normen vereisen expliciet dat organisaties kunnen aantonen dat zij adequate maatregelen hebben geïmplementeerd om kritieke resources te beschermen. Zonder verificatie kunnen organisaties niet bewijzen dat Resource Locks daadwerkelijk zijn geconfigureerd en actief zijn, wat kan leiden tot het falen van audits en mogelijke boetes. Auditors verwachten concrete bewijzen dat locks aanwezig zijn op alle kritieke resources, dat locks correct zijn geconfigureerd met de juiste lock levels, en dat er processen zijn voor het monitoren en verifiëren van lock configuraties. Het ontbreken van verificatie kan worden geïnterpreteerd als een gebrek aan governance-maturiteit en kan leiden tot negatieve audit-bevindingen. Beveiligingsrisico's nemen exponentieel toe wanneer organisaties geen systematische verificatie uitvoeren van Resource Lock configuraties. Zonder verificatie kunnen nieuwe resources worden aangemaakt zonder locks, bestaande locks kunnen per ongeluk worden verwijderd zonder dat dit wordt opgemerkt, of locks kunnen worden geconfigureerd met verkeerde lock levels die niet voldoen aan de beveiligingsvereisten. Deze problemen blijven vaak onopgemerkt totdat een beveiligingsincident plaatsvindt of een audit wordt uitgevoerd, op welk moment het te laat is om preventieve maatregelen te nemen. Bovendien maakt het ontbreken van verificatie het onmogelijk om trends te identificeren, zoals een toename in het aantal resources zonder locks, wat kan wijzen op systematische problemen in het provisioning-proces of in de manier waarop locks worden beheerd. Een systematische verificatieaanpak biedt organisaties volledige zichtbaarheid en controle over hun Resource Lock configuraties. Door regelmatig te verifiëren dat locks correct zijn geconfigureerd kunnen organisaties garanderen dat alle kritieke resources daadwerkelijk worden beschermd, dat locks actief blijven gedurende de levenscyclus van resources, en dat nieuwe resources automatisch worden beschermd wanneer ze worden aangemaakt. Deze verificatie maakt het mogelijk om proactief te reageren op problemen voordat ze escaleren tot beveiligingsincidenten, en om trends te identificeren die kunnen wijzen op systematische problemen in het lock-beheerproces. Bovendien biedt verificatie de documentatie die nodig is voor audit-doeleinden, waarbij organisaties kunnen aantonen dat zij proactief monitoren en verifiëren dat hun beveiligingsmaatregelen correct functioneren. Voor Nederlandse overheidsorganisaties en organisaties die moeten voldoen aan de BIO-normen is systematische verificatie van Resource Lock configuraties niet alleen een best practice maar een compliance-vereiste. Thema 17.01 van de BIO vereist dat organisaties kunnen aantonen dat zij maatregelen hebben geïmplementeerd om de beschikbaarheid van IT-voorzieningen te waarborgen, en verificatie van Resource Locks vormt een essentieel onderdeel van deze vereiste. Zonder verificatie kunnen organisaties niet bewijzen dat zij voldoen aan BIO-vereisten, wat kan leiden tot het verlies van certificeringen of het falen van audits.

Implementatie

Het verifiëren van Azure Resource Lock configuraties omvat een complete set van activiteiten die garanderen dat locks correct zijn geplaatst, actief blijven, en alle kritieke resources adequaat beschermen. Deze verificatie begint met het inventariseren van alle resources die locks zouden moeten hebben, gebaseerd op organisatorische criteria zoals omgevingstype, kritiek niveau, of specifieke tags. Deze inventarisatie vormt de basis voor alle volgende verificatiestappen en moet regelmatig worden bijgewerkt wanneer nieuwe resources worden aangemaakt of wanneer bestaande resources worden gewijzigd. De verificatie omvat het controleren of locks daadwerkelijk aanwezig zijn op alle resources die volgens het beleid locks zouden moeten hebben. Dit vereist het uitvoeren van queries tegen Azure Resource Graph of het gebruik van PowerShell-scripts om alle resources te identificeren die locks zouden moeten hebben, en vervolgens te verifiëren of deze resources daadwerkelijk locks hebben. Voor resources zonder locks moet worden bepaald of dit een legitieme uitzondering is of een probleem dat moet worden opgelost. Deze verificatie moet worden uitgevoerd op regelmatige basis, bijvoorbeeld wekelijks of maandelijks, afhankelijk van de snelheid waarmee nieuwe resources worden aangemaakt en de kritiek van de omgeving. Naast het verifiëren van de aanwezigheid van locks moet verificatie ook controleren of locks correct zijn geconfigureerd met de juiste lock levels. CanNotDelete locks zijn de standaard keuze voor de meeste productieomgevingen omdat ze voorkomen dat resources worden verwijderd terwijl configuratiewijzigingen nog steeds mogelijk zijn. ReadOnly locks zijn slechts zelden nodig en worden alleen gebruikt voor werkelijk onveranderbare resources. Verificatie moet controleren of de lock levels correct zijn geconfigureerd voor elk type resource, en of er geen locks zijn geplaatst met verkeerde lock levels die operationele problemen kunnen veroorzaken of die niet voldoen aan beveiligingsvereisten. Verificatie moet ook controleren of locks actief blijven gedurende de levenscyclus van resources. Locks kunnen per ongeluk worden verwijderd tijdens routineonderhoud, wijzigingsbeheerprocessen, of door geautomatiseerde scripts. Verificatie moet daarom controleren of locks die eerder aanwezig waren nog steeds actief zijn, en waarschuwingen genereren wanneer locks worden verwijderd zonder voorafgaande goedkeuring. Deze verificatie moet worden geïntegreerd met monitoring-systemen zodat lockverwijderingen onmiddellijk worden gedetecteerd en geëscaleerd naar het security operations team. Een essentieel onderdeel van verificatie is het documenteren van alle bevindingen voor audit-doeleinden. Deze documentatie moet informatie bevatten over welke resources locks hebben, welke resources locks zouden moeten hebben maar deze niet hebben, welke locks zijn verwijderd sinds de laatste verificatie, en welke uitzonderingen zijn goedgekeurd. Deze documentatie helpt bij audits, troubleshooting, en het identificeren van trends in lock-beheer. Regelmatige rapporten moeten worden gegenereerd die een overzicht bieden van de lock coverage, trends over tijd, en aanbevelingen voor verbetering. Tot slot moet verificatie geautomatiseerd worden waar mogelijk om ervoor te zorgen dat het regelmatig en consistent wordt uitgevoerd zonder handmatige interventie. Geautomatiseerde verificatie kan worden geïmplementeerd via Azure Automation runbooks, Azure Policy compliance checks, of geplande PowerShell-scripts die regelmatig worden uitgevoerd. Deze automatisering zorgt ervoor dat verificatie niet wordt vergeten of overgeslagen, en maakt het mogelijk om snel te reageren op problemen wanneer ze worden gedetecteerd. Geautomatiseerde verificatie moet worden geïntegreerd met monitoring- en waarschuwingssystemen zodat problemen onmiddellijk worden geïdentificeerd en geëscaleerd naar de juiste teams.

Vereisten voor Resource Lock Configuratie Verificatie

Voordat Resource Lock configuratie verificatie kan worden uitgevoerd, moeten verschillende essentiële vereisten worden vervuld die de basis vormen voor effectieve verificatie. De eerste vereiste is een duidelijk gedefinieerd beleid dat beschrijft welke resources locks zouden moeten hebben, welke lock levels moeten worden gebruikt, en onder welke omstandigheden uitzonderingen zijn toegestaan. Dit beleid moet expliciet definiëren welke omgevingen locks vereisen, zoals alle productieomgevingen, welke resources als kritiek worden beschouwd en daarom locks vereisen, en welke naamgevingsconventies of tags worden gebruikt om resources te identificeren die locks zouden moeten hebben. Zonder een duidelijk beleid is het onmogelijk om te bepalen welke resources locks zouden moeten hebben en of verificatie succesvol is.

Vanuit technisch perspectief zijn de juiste PowerShell-modules een absolute vereiste voor het uitvoeren van verificatie. De Az.Resources module moet zijn geïnstalleerd en bijgewerkt naar de nieuwste versie om toegang te hebben tot alle benodigde cmdlets voor het queryen van Resource Locks. Deze module biedt de functionaliteit om locks te queryen, te controleren of locks aanwezig zijn op specifieke resources, en om informatie te verkrijgen over lock configuraties. Zonder deze module kan verificatie niet volledig worden uitgevoerd, of kunnen bepaalde functionaliteiten ontbreken.

Toegang tot alle Azure-abonnementen en Resource Groups binnen de organisatie is essentieel voor complete verificatie. Het verificatieproces moet kunnen worden uitgevoerd op alle cloud-resources, wat vereist dat de personen of service principals die verificatie uitvoeren, de juiste rechten hebben op alle relevante abonnementen. Voor grote organisaties met honderden abonnementen kan dit betekenen dat toegang moet worden verkregen via Management Groups of dat een service principal moet worden geconfigureerd met tenant-brede rechten. Bovendien moeten de juiste beheerdersrollen worden toegewezen, zoals Reader voor het queryen van locks, en mogelijk Contributor voor het plaatsen van locks wanneer problemen worden gedetecteerd.

Een geautomatiseerd platform voor verificatie is belangrijk voor het efficiënt uitvoeren van regelmatige verificatie. Dit platform kan bestaan uit Azure Automation voor het uitvoeren van geautomatiseerde scripts, Azure Policy voor compliance checks, of een dedicated verificatie systeem. Het platform moet de mogelijkheid hebben om regelmatig verificatie uit te voeren, waarschuwingen te genereren wanneer problemen worden gedetecteerd, en rapporten te genereren voor audit-doeleinden. Voor organisaties die continue verificatie willen, moet het platform kunnen worden geconfigureerd om automatisch verificatie uit te voeren op een geplande basis, bijvoorbeeld dagelijks of wekelijks, en waarschuwingen te genereren wanneer resources zonder locks worden gedetecteerd.

Een rapportage- en documentatieproces is essentieel om verificatie-resultaten vast te leggen voor audit-doeleinden. Dit proces moet duidelijk beschrijven hoe verificatie-resultaten worden gedocumenteerd, waar deze documentatie wordt opgeslagen, en hoe lang ze wordt bewaard. Voor compliance-doeleinden moeten verificatie-rapporten vaak minimaal zeven jaar worden bewaard, wat betekent dat een geschikt archiefsysteem moet worden geconfigureerd. Documentatie moet gedetailleerde informatie bevatten over welke resources locks hebben, welke resources locks zouden moeten hebben maar deze niet hebben, welke locks zijn verwijderd sinds de laatste verificatie, en welke uitzonderingen zijn goedgekeurd. Deze informatie is essentieel voor auditors om te begrijpen hoe organisaties hun Resource Lock configuraties verifiëren en handhaven.

Ten slotte moet een proces worden gedefinieerd voor het beheren van uitzonderingen wanneer bepaalde resources legitiem geen locks kunnen hebben vanwege technische beperkingen of bedrijfsvereisten. Dit proces moet beschrijven hoe uitzonderingen worden voorgesteld, gereviewed, goedgekeurd en gedocumenteerd. Uitzonderingen moeten worden beoordeeld door de juiste autoriteiten, zoals security officers of compliance managers, voordat ze worden goedgekeurd. Bovendien moeten uitzonderingen regelmatig worden herbeoordeeld, bijvoorbeeld elk kwartaal of halfjaar, om te bepalen of de uitzondering nog steeds gerechtvaardigd is. Als de reden voor de uitzondering niet langer geldig is, moet de uitzondering worden ingetrokken en moeten locks worden geplaatst op de betreffende resources.

Implementatie van Resource Lock Configuratie Verificatie

De implementatie van Resource Lock configuratie verificatie begint met het ontwikkelen van een gestructureerde inventarisatie van alle resources die locks zouden moeten hebben. Deze inventarisatie moet worden gebaseerd op het gedefinieerde beleid dat beschrijft welke resources locks vereisen, en moet gebruik maken van tags, naamgevingsconventies, of andere identificatiemethoden om resources te identificeren. Voor productieomgevingen kunnen resources bijvoorbeeld worden geïdentificeerd door tags zoals 'Environment=Production' of door naamgevingsconventies die 'prod' bevatten. Deze inventarisatie vormt de basis voor alle volgende verificatiestappen en moet regelmatig worden bijgewerkt wanneer nieuwe resources worden aangemaakt.

Na het ontwikkelen van de inventarisatie moeten geautomatiseerde scripts worden ontwikkeld die systematisch controleren of alle geïdentificeerde resources daadwerkelijk locks hebben. Deze scripts moeten gebruik maken van Azure Resource Graph queries of PowerShell-cmdlets om alle resources te identificeren die locks zouden moeten hebben, en vervolgens te verifiëren of deze resources daadwerkelijk locks hebben. Scripts moeten ook controleren of locks correct zijn geconfigureerd met de juiste lock levels, en of locks actief blijven gedurende de levenscyclus van resources. Voor resources zonder locks moeten scripts bepalen of dit een legitieme uitzondering is of een probleem dat moet worden opgelost.

Waarschuwingen moeten worden geconfigureerd om teams onmiddellijk te informeren wanneer resources zonder locks worden gedetecteerd of wanneer locks worden verwijderd zonder voorafgaande goedkeuring. Deze waarschuwingen moeten worden geconfigureerd met verschillende prioriteitsniveaus, waarbij resources zonder locks op productieomgevingen de hoogste prioriteit krijgen. Waarschuwingen moeten worden doorgestuurd naar de juiste teams, zoals security officers voor beveiligingsgerelateerde problemen en compliance managers voor compliance-gerelateerde problemen. Het is belangrijk om waarschuwingsmoeheid te voorkomen door waarschuwingen te configureren op een manier die alleen relevante en actievereiste meldingen genereert.

Regelmatige rapporten moeten worden gegenereerd die een overzicht bieden van de lock coverage over alle abonnementen en resources. Deze rapporten moeten niet alleen de huidige status weergeven, maar ook trends over tijd, waardoor organisaties kunnen zien of de lock coverage verbetert of verslechtert. Rapporten moeten worden geëxporteerd in verschillende formaten voor distributie aan stakeholders en voor archivering voor audit-doeleinden. Voor organisaties die moeten voldoen aan compliance-vereisten zoals ISO 27001 of de BIO-normen, zijn deze rapporten vaak een vereiste voor certificering.

Geautomatiseerde verificatie moet worden geïntegreerd met bestaande monitoring- en waarschuwingssystemen zodat problemen onmiddellijk worden geïdentificeerd en geëscaleerd naar de juiste teams. Deze integratie maakt het mogelijk om verificatie te integreren in bestaande security operations workflows, zodat problemen snel kunnen worden opgelost. Geautomatiseerde verificatie moet ook worden geconfigureerd om regelmatig te worden uitgevoerd, bijvoorbeeld dagelijks of wekelijks, afhankelijk van de snelheid waarmee nieuwe resources worden aangemaakt en de kritiek van de omgeving.

Documentatie van alle verificatie-activiteiten is cruciaal voor audit-doeleinden en voor het begrijpen van de geschiedenis van lock configuraties. Alle verificatie-resultaten, geïdentificeerde problemen, en uitgevoerde remediaties moeten worden vastgelegd in een changelog die duidelijk aangeeft wat er is gecontroleerd, wanneer de verificatie heeft plaatsgevonden, welke problemen zijn geïdentificeerd, en hoe deze problemen zijn opgelost. Deze documentatie is essentieel tijdens externe audits en helpt organisaties om te verantwoorden waarom bepaalde resources wel of geen locks hebben. Bovendien maakt deze documentatie het mogelijk om trends te identificeren en het verificatieproces continu te verbeteren.

Monitoring en Verificatie van Resource Lock Configuraties

Effectieve monitoring van Resource Lock configuraties is essentieel om te garanderen dat verificatie daadwerkelijk werkt en dat organisaties op de hoogte blijven van hun lock coverage. Het monitoringproces moet verschillende aspecten omvatten, waaronder het bijhouden van de verificatiestatus, het monitoren van lock coverage over tijd, het identificeren van trends in resources zonder locks, en het detecteren van lockverwijderingen die kunnen wijzen op problemen in het lock-beheerproces.

Het bijhouden van de verificatiestatus maakt het mogelijk om te verifiëren dat verificatie regelmatig wordt uitgevoerd en dat alle geïdentificeerde problemen worden opgelost. Dit omvat het controleren of verificatie-scripts correct worden uitgevoerd, of waarschuwingen correct worden gegenereerd wanneer problemen worden gedetecteerd, en of geïdentificeerde problemen binnen de gestelde tijdlijnen worden opgelost. Door regelmatig de verificatiestatus te controleren kunnen organisaties snel identificeren waar verificatie niet correct functioneert, en corrigerende maatregelen nemen voordat problemen escaleren tot beveiligingsincidenten of compliance-overtredingen.

Het monitoren van lock coverage over tijd maakt het mogelijk om trends te identificeren en te bepalen of de beveiligingspostuur van de organisatie verbetert of verslechtert. Door historische data te analyseren kunnen security officers zien of het percentage resources met locks toeneemt of afneemt, of nieuwe resources consistent locks hebben wanneer ze worden aangemaakt, en of bestaande resources hun locks behouden. Deze trendanalyse is waardevol voor het identificeren van systematische problemen, zoals wanneer nieuwe resources consistent worden aangemaakt zonder locks, wat kan wijzen op een probleem in het provisioning-proces of in de manier waarop locks worden beheerd.

Waarschuwingen moeten worden geconfigureerd om teams onmiddellijk te informeren wanneer kritieke resources zonder locks worden gedetecteerd of wanneer locks worden verwijderd zonder voorafgaande goedkeuring. Deze waarschuwingen moeten worden geconfigureerd met verschillende prioriteitsniveaus, waarbij resources zonder locks op productieomgevingen de hoogste prioriteit krijgen. Waarschuwingen moeten worden doorgestuurd naar de juiste teams, zoals security officers voor beveiligingsgerelateerde problemen en compliance managers voor compliance-gerelateerde problemen. Het is belangrijk om waarschuwingsmoeheid te voorkomen door waarschuwingen te configureren op een manier die alleen relevante en actievereiste meldingen genereert.

Maandelijkse compliance-rapporten moeten worden gegenereerd die een overzicht bieden van de lock coverage over alle abonnementen en resources. Deze rapporten moeten niet alleen de huidige status weergeven, maar ook trends over tijd, waardoor organisaties kunnen zien of de lock coverage verbetert of verslechtert. Rapporten moeten worden geëxporteerd in verschillende formaten voor distributie aan stakeholders en voor archivering voor audit-doeleinden. Voor organisaties die moeten voldoen aan compliance-vereisten zoals ISO 27001 of de BIO-normen, zijn deze rapporten vaak een vereiste voor certificering.

Het monitoren van nieuwe resources is bijzonder belangrijk omdat deze vaak worden aangemaakt zonder locks. Het monitoringproces moet specifiek controleren op nieuwe resources en waarschuwingen genereren wanneer nieuwe resources worden gedetecteerd die locks zouden moeten hebben maar deze niet hebben. Dit maakt het mogelijk om snel te reageren en locks te plaatsen voordat resources operationeel worden en beveiligingsrisico's introduceren. Voor organisaties met een hoog volume van nieuwe resources kan het nuttig zijn om geautomatiseerde remediatie te implementeren die automatisch locks plaatst wanneer nieuwe resources worden aangemaakt die locks zouden moeten hebben.

Compliance en Auditing

Resource Lock configuratie verificatie draagt bij aan naleving van verschillende cybersecurity frameworks en standaarden die relevant zijn voor Nederlandse overheidsorganisaties. De implementatie van verificatie is expliciet vereist door de CIS Azure Benchmark, die richtlijnen bevat voor resource bescherming controls. Deze benchmark beschouwt verificatie als een fundamentele governance-activiteit voor alle productieomgevingen en raadt aan om regelmatig te verifiëren dat locks correct zijn geconfigureerd. Naleving van de CIS Azure Benchmark is vaak een vereiste voor organisaties die werken met gevoelige gegevens of kritieke infrastructuren, en verificatie vormt een essentieel onderdeel van deze naleving.

ISO 27001 bevat verschillende controls die relevant zijn voor Resource Lock configuratie verificatie. Control A.12.3.1 (Information backup) vereist dat organisaties back-ups maken van belangrijke informatie en software, en dat deze back-ups regelmatig worden getest. Verificatie helpt bij het naleven van deze control door te verifiëren dat kritieke resources daadwerkelijk worden beschermd tegen verwijdering voordat back-ups kunnen worden gemaakt of hersteld. Daarnaast adresseert ISO 27001 control A.17.2.1 (Availability) de beschikbaarheid van informatieverwerkingsfaciliteiten. Verificatie draagt bij aan beschikbaarheid door te verifiëren dat locks correct zijn geconfigureerd om te voorkomen dat kritieke productieresources worden verwijderd, wat zou leiden tot uitval van diensten en verlies van beschikbaarheid. Organisaties die ISO 27001 gecertificeerd willen worden of blijven, moeten kunnen aantonen dat adequate maatregelen zijn getroffen om de beschikbaarheid en integriteit van kritieke resources te waarborgen, en verificatie biedt het bewijs dat deze maatregelen daadwerkelijk functioneren.

De NIS2 richtlijn, die is omgezet in Nederlandse wetgeving, vereist dat essentiële entiteiten en belangrijke entiteiten passende technische en organisatorische maatregelen treffen om de beveiliging en beschikbaarheid van hun netwerk- en informatiesystemen te waarborgen. Artikel 21 van de NIS2 richtlijn behandelt specifiek beschikbaarheidsmaatregelen en vereist dat organisaties maatregelen implementeren om de beschikbaarheid van hun systemen te beschermen tegen bedreigingen zoals onbedoelde verwijderingen of kwaadwillige acties. Verificatie is een concrete implementatie van deze vereisten en helpt organisaties om te voldoen aan de NIS2 verplichtingen door te verifiëren dat locks correct zijn geconfigureerd. Nederlandse organisaties die onder de NIS2 vallen, moeten kunnen aantonen dat zij adequate maatregelen hebben geïmplementeerd om kritieke resources te beschermen, en verificatie vormt een essentieel onderdeel hiervan.

Het BIO (Baseline Informatiebeveiliging Overheid) framework bevat specifieke controls voor beschikbaarheid die relevant zijn voor Resource Lock configuratie verificatie. BIO Thema 17.01 (Beschikbaarheid) vereist dat organisaties maatregelen treffen om de beschikbaarheid van IT-voorzieningen te waarborgen. Verificatie draagt direct bij aan deze vereisten door te verifiëren dat locks correct zijn geconfigureerd om te voorkomen dat kritieke productieresources worden verwijderd, wat zou leiden tot uitval van diensten. Nederlandse overheidsorganisaties moeten voldoen aan de BIO baseline, en verificatie is een concrete manier om aan te tonen dat adequate maatregelen zijn genomen om de beschikbaarheid te beschermen. Compliance audits zullen controleren of alle productieresources adequaat zijn beschermd tegen onbedoelde verwijdering, en verificatie vormt hiervoor een duidelijke en verifieerbare implementatie.

Voor auditdoeleinden moeten organisaties uitgebreide documentatie bijhouden over hun Resource Lock configuratie verificatie. Deze documentatie moet een complete inventarisatie bevatten van alle verificatie-activiteiten, inclusief welke resources zijn gecontroleerd, wanneer verificatie heeft plaatsgevonden, welke problemen zijn geïdentificeerd, en hoe deze problemen zijn opgelost. Daarnaast moet er documentatie zijn over het verificatieproces, inclusief hoe verificatie wordt uitgevoerd, hoe vaak verificatie plaatsvindt, en wie verantwoordelijk is voor verificatie. Alle verificatie-activiteiten moeten worden gelogd, en deze logs moeten worden bewaard voor de vereiste retentieperiode zoals gespecificeerd in de compliance frameworks. Regelmatige auditrapporten moeten worden gegenereerd die aantonen dat verificatie regelmatig wordt uitgevoerd en dat alle geïdentificeerde problemen worden opgelost.

Remediatie

Gebruik PowerShell-script resource-locks-configured.ps1 (functie Invoke-Remediation) – Herstelt ontbrekende Resource Locks op resources die deze zouden moeten hebben.

Compliance & Frameworks

• CIS M365: Control Resource bescherming (L1) - Verificatie van Resource Locks op kritieke resources
• BIO: 17.01.01, 17.02.01 - Beschikbaarheid van IT-voorzieningen - Verificatie
• ISO 27001:2022: A.12.3.1, A.17.2.1 - Informatie back-up en beschikbaarheid - Verificatie
• NIS2: Artikel - Beschikbaarheidsmaatregelen - Verificatie van bescherming

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

Het verifiëren van Azure Resource Lock configuraties omvat een complete set van activiteiten die garanderen dat locks correct zijn geplaatst, actief blijven, en alle kritieke resources adequaat beschermen. Verificatie begint met het inventariseren van alle resources die locks zouden moeten hebben, controleert of locks daadwerkelijk aanwezig zijn, verifieert of locks correct zijn geconfigureerd met de juiste lock levels, en monitort of locks actief blijven. Geautomatiseerde verificatie moet worden geïntegreerd met monitoring- en waarschuwingssystemen zodat problemen onmiddellijk worden geïdentificeerd. Implementatie vereist ongeveer 12 uur voor ontwikkeling, documentatie en configuratie. Verificatie is essentieel voor organisaties die moeten voldoen aan compliance-vereisten zoals CIS, ISO 27001, BIO en NIS2.

• Implementatietijd: 12 uur
• FTE required: 0.1 FTE