Azure Site Recovery Ingeschakeld

Zonder een goed geconfigureerd Azure Site Recovery-systeem lopen Nederlandse overheidsorganisaties het risico op langdurige uitval van kritieke diensten wanneer een datacenter, een volledige Azure-regio of de primaire cloudinfrastructuur wordt getroffen door calamiteiten. Hoewel Azure Backup bescherming biedt tegen gegevensverlies en ransomware, is het herstel van back-ups naar nieuwe infrastructuren vaak een proces van uren tot dagen. Voor essentiële diensten zoals burgerzaken, uitkeringssystemen, belastingadministratie of veiligheidsprocessen is dit onacceptabel; de maatschappelijke impact van een dergelijke uitval is enorm en leidt tot bestuurlijke verantwoordelijkheid, politieke druk en mogelijk juridische claims. Regionale Azure-storingen komen minder vaak voor, maar zijn niet ondenkbaar: datacenterbranden, stroomuitval, netwerkstoringen of zelfs menselijke fouten kunnen een hele regio offline brengen. Daarnaast vormen grootschalige cyberaanvallen zoals ransomware of DDoS-aanvallen een reëel risico waarbij snel kunnen uitwijken naar een schone omgeving cruciaal is. De Baseline Informatiebeveiliging Overheid (BIO) verlangt in paragraaf 17.03 expliciet dat organisaties maatregelen treffen voor continuïteit en beschikbaarheid, waarbij periodieke tests van disaster recovery-plannen verplicht zijn. ISO 27001:2022 control A.17.1.3 eist bovendien dat organisaties informatiebeveiligingsaspecten van bedrijfscontinuïteit beheren, inclusief testen en onderhoud van continuïteitsplannen. De aankomende NIS2-richtlijn, artikel 21, verplicht aanbieders van essentiële en belangrijke diensten om operationele continuïteit en incidentrespons te waarborgen, waarbij expliciet wordt genoemd dat organisaties moeten testen of herstelplannen daadwerkelijk werken. Zonder Azure Site Recovery mislukt iedere audit op deze onderdelen, wat kan resulteren in aanwijzingen, dwangsommen of zelfs intrekking van vergunningen. Bovendien kan het niet kunnen terugschakelen naar een secundaire omgeving bij een grootschalige incident leiden tot wekenlange stilstand, waarbij burgers, bedrijven en andere overheidsorganisaties afhankelijk zijn van de dienstverlening die niet beschikbaar is. Door Azure Site Recovery proactief in te richten, regelmatig testfailovers uit te voeren en failoverprocedures te documenteren, bouwt men een cultuur op waarin veerkracht en continuïteit net zo belangrijk zijn als functionaliteit en beveiliging.

Implementatie

Een solide Azure Site Recovery-configuratie start met het ontwerpen van een replicatiestrategie die past bij de RTO (Recovery Time Objective) en RPO (Recovery Point Objective) van kritieke workloads. Organisaties moeten bepalen welke virtuele machines, applicaties en databases als kritiek worden aangemerkt en welke maximale uitvaltijd en gegevensverlies acceptabel zijn. Vervolgens wordt een Recovery Services-kluis ingericht in de secundaire regio met Site Recovery-functionaliteit, worden replicatiebeleid gedefinieerd die de frequentie van synchronisatie, compressie-instellingen en netwerkconfiguratie vastleggen, en wordt voor elke workload replicatie geactiveerd. Daarna worden testfailovers gepland en uitgevoerd om te valideren dat failover binnen de afgesproken RTO haalbaar is, worden netwerkroutes en firewallregels geconfigureerd voor naadloze connectiviteit in de failover-regio, en worden geautomatiseerde runbooks opgesteld die bij een echte failover alle stappen orkestreren. Organisaties die volwassen willen werken, leggen deze stappen vast in hun crisisbeheersproces, automatiseren monitoring met PowerShell of Azure Automation, en publiceren dashboards in hun service management-portaal zodat bestuurders realtime inzicht hebben in de replicatiestatus. Hierdoor ontstaat een sluitende keten van preventie, detectie, replicatie en herstel die naadloos aansluit op de Nederlandse Baseline voor Veilige Cloud en aantoonbaar voldoet aan alle compliance-eisen.

Vereisten en Architectuurkeuzes

Het implementeren van Azure Site Recovery vereist een zorgvuldige planning en architectuurkeuzes die afgestemd moeten zijn op de specifieke bedrijfscontinuïteitsdoelstellingen en compliance-vereisten van Nederlandse overheidsorganisaties. Allereerst moet het architectuurteam per kritieke workload of applicatie vastleggen wat de Recovery Time Objective (RTO) en Recovery Point Objective (RPO) zijn. De RTO definieert hoeveel tijd maximaal acceptabel is tussen een calamiteit en het moment waarop de dienst weer beschikbaar is, terwijl de RPO bepaalt hoeveel gegevensverlies maximaal acceptabel is. Voor mission-critical systemen zoals uitkeringssystemen, belastingadministratie of burgerzaken gelden doorgaans zeer strikte eisen: een RTO van minder dan één uur en een RPO van maximaal vijftien minuten. Voor minder kritieke workloads kunnen deze eisen minder streng zijn, bijvoorbeeld een RTO van vier uur en een RPO van één uur. Deze keuzes bepalen direct welke replicatiemodus moet worden gebruikt: asynchroon voor langere RPO's of synchroon voor minimale gegevensverlies, waarbij synchrone replicatie technisch complexer is en hogere kosten met zich meebrengt.

Een actief Azure-abonnement met voldoende quota in zowel de primaire als secundaire regio is noodzakelijk, inclusief toegang tot Recovery Services-kluizen, virtuele netwerken, storage accounts en compute-resources. Leg in het abonnement een beheerder van dienst vast die verantwoordelijk is voor het Site Recovery-beheer en zorg dat change- en incidentprocessen bekend zijn met de replicatie-infrastructuur. Documenteer bovendien welke resourcegroepen en workloads onderdeel zijn van het replicatiebereik, zodat audits eenvoudig kunnen controleren of de juiste scope wordt beschermd, en stem dit overzicht af met het assetregister en het Business Continuity Plan. Voor hybride scenario's waarbij on-premises workloads worden gerepliceerd naar Azure, moet een Azure Site Recovery-configuratieserver worden ingericht die fungeert als coördinatiepunt tussen de on-premises omgeving en Azure. Deze server vereist een Windows Server-machine met voldoende resources en moet voldoen aan beveiligingseisen zoals toegangsbeperking, logging en monitoring. Voor VMware-omgevingen is bovendien een proces-server nodig die de replicatie- en compressietaken afhandelt, terwijl voor Hyper-V-omgevingen de replicatie direct vanuit Hyper-V Manager of System Center Virtual Machine Manager kan worden beheerd.

Functionele en technische beheerders hebben Contributor- of hoger rechten nodig op zowel de primaire resources als de Recovery Services-kluis en de doel-resourcegroepen, aangevuld met Reader-rollen voor auditors zodat configuraties kunnen worden gewijzigd terwijl scheiding van functies behouden blijft. Richt privileged access workstations in voor deze handelingen en log alle beheeracties via Azure Activity Logs en Defender for Cloud. Maak gebruik van just-in-time toegangsverlening zodat langdurige permanente rechten worden voorkomen. Daarnaast is netwerkconnectiviteit cruciaal: voor replicatie tussen Azure-regio's moeten virtuele netwerken worden gekoppeld via peering of via een hub-and-spoke-architectuur, terwijl voor hybride scenario's site-to-site VPN of Azure ExpressRoute vereist is. Firewallregels moeten worden geconfigureerd zodat Site Recovery-servers kunnen communiceren met Azure-eindpunten, en netwerksecurity groups moeten replicatieverkeer toestaan. Documenteer alle netwerkafhankelijkheden, bandbreedtevereisten en latentie-eisen in een netwerkarchitectuurdocument zodat duidelijk is welke beperkingen gelden en hoe deze worden opgelost bij een failover.

Er moet een formeel goedgekeurd disaster recovery-beleid bestaan waarin replicatiestrategie, failoverprocedures, testfrequentie, rollen en verantwoordelijkheden, communicatieprotocollen en acceptatiecriteria zijn beschreven en gekoppeld aan de risicoklasse van de betreffende applicaties. Het beleid hoort onderdeel uit te maken van het Business Continuity Plan en moet minimaal jaarlijks worden herzien of direct na een incident of wijziging in de infrastructuur. Gebruik een beslisboom voor uitzonderingen zodat afwijkingen altijd schriftelijk worden goedgekeurd door het management. Financiële dekking is nodig voor storage-kosten voor replicatiedata, compute-kosten voor testfailovers, netwerkdata-transfer-kosten en eventuele licentiekosten voor Site Recovery-extensies; reken op circa €0,10 tot €0,20 per gigabyte per maand voor replicatie-opslag, aangevuld met variabele kosten voor compute tijdens testfailovers en daadwerkelijke failovers. Neem deze bedragen op in meerjarenramingen en koppel ze aan cloudkostenbeheer zodat afdelingen tijdig bijsturen. Organisaties hebben een gedocumenteerd testplan nodig waarin minimaal per kwartaal een representatieve testfailover wordt gepland, inclusief rollen, testscenario's en evaluatiecriteria, zodat management bewijs krijgt dat disaster recovery daadwerkelijk werkt. Gebruik een lessons-learned-sjabloon en koppel verbetermaatregelen aan werkorders of user stories. Neem ook end-to-end scenario's op waarin afhankelijkheden zoals Key Vaults, DNS, load balancers en netwerkbeveiliging worden gecontroleerd.

Implementatie en Configuratie

Gebruik PowerShell-script site-recovery-enabled.ps1 (functie Invoke-Implementation) – Gebruik dit PowerShell-script om op schaal Recovery Services-kluizen met Site Recovery-functionaliteit, replicatiebeleid en VM-koppelingen uit te rollen binnen meerdere abonnementen met uniforme logging en foutafhandeling..

STAP 1 beschrijft het zorgvuldig inrichten van een Recovery Services-kluis in de secundaire regio die als centrale coördinatiepunt fungeert voor alle replicatieoperaties. Kies een duidelijke naamgevingsconventie zoals SiteRecoveryVault-WestEurope-DR, bepaal of geo-redundante opslag noodzakelijk is voor extra bescherming, en documenteer de gekozen regio zodat iedere beheerder direct ziet voor welke workloads de kluis bedoeld is. Selecteer dezelfde regio als de secundaire productie-resources of kies een gekoppelde regio wanneer de organisatie strikte geo-redundantie verplicht stelt; dit minimaliseert latency en voorkomt dat failover naar een niet-ondersteunde locatie moet plaatsvinden. Configureer versleuteling met door de klant beheerde sleutels (CMK) indien vereist door het dataclassificatiebeleid, zodat de organisatie volledige controle heeft over de encryptiesleutels en voldoet aan strikte compliance-eisen. Na het aanmaken van de kluis moet Site Recovery worden geactiveerd door naar het Site Recovery-gedeelte binnen de kluis te navigeren en de replicatierichting te selecteren: van Azure naar Azure, van on-premises naar Azure, of tussen on-premises locaties. Voor Azure-naar-Azure-scenario's wordt direct een replicatie-infrastructuur opgezet, terwijl voor hybride scenario's eerst een configuratieserver moet worden gedownload en geïnstalleerd.

STAP 2 bestaat uit het opstellen van replicatiebeleid die de frequentie van synchronisatie, crash-consistente en app-consistente snapshots, retentie-instellingen en compressie bepalen. Dit beleid vormt de contractuele afspraak tussen beveiliging, operations en de applicatie-eigenaar en moet aantoonbaar aansluiten bij de afgesproken RPO. Plan crash-consistente replicatie voor workloads waarbij gegevensintegriteit niet kritiek is, of app-consistente replicatie voor databases en applicaties waarbij transacties moeten worden behouden. App-consistente snapshots gebruiken Volume Shadow Copy Service (VSS) om ervoor te zorgen dat applicaties in een consistente staat worden vastgelegd voordat replicatie plaatsvindt, wat essentieel is voor databases zoals SQL Server, Exchange of Active Directory. Definieer de replicatiefrequentie: voor kritieke workloads kan dit zo vaak als elke dertig seconden, terwijl voor minder kritieke workloads een frequentie van vijf minuten of vijftien minuten volstaat. Houd er rekening mee dat frequentere replicatie meer netwerkbandbreedte en storage-kosten met zich meebrengt. Configureer compressie om netwerkverbruik te minimaliseren, vooral bij replicatie over langzame verbindingen, maar wees je ervan bewust dat compressie CPU-belasting met zich meebrengt op de bronmachines. Sla het beleid op met een duidelijke naam zoals ReplicationPolicy-15minRPO-prod en documenteer de versie en goedkeuringsdatum zodat audits kunnen verifiëren dat de instelling intentioneel is gekozen.

STAP 3 richt zich op het daadwerkelijk inschakelen van replicatie voor iedere virtuele machine of fysieke server. Dit omvat zowel portaalhandelingen als automatische controles via scripts, zodat geen enkele productie-workload per ongeluk buiten de replicatiestrategie valt. Voor Azure-naar-Azure-replicatie selecteert u de bron-VM, de Recovery Services-kluis, het replicatiebeleid en de doel-resourcegroep en het virtuele netwerk. Site Recovery maakt automatisch een replica-VM aan in de doel-regio, die standaard uitgeschakeld blijft totdat een failover wordt uitgevoerd. Tijdens de initiële replicatie wordt een volledige kopie van de VM-schijven gemaakt, wat afhankelijk van de grootte en netwerkbandbreedte uren tot dagen kan duren. Daarna worden alleen gewijzigde blokken gerepliceerd, wat de doorlooptijd en kosten aanzienlijk vermindert. Voor hybride scenario's moet eerst de Mobility Service-agent worden geïnstalleerd op de bronmachines, wat automatisch kan gebeuren via push-installatie vanuit de configuratieserver of handmatig via installatiepakketten. Controleer in het overzicht Gerepliceerde items of de VM expliciet wordt vermeld, inclusief de replicatiestatus, de laatst voltooide synchronisatie, de RPO-status en het gekoppelde beleid, en herhaal dit voor elke productie-workload. Gebruik het PowerShell-script of Azure Policy-rapportages om wekelijks te bevestigen dat nieuwe workloads automatisch in het replicatiebeleid zijn opgenomen en dat verwijderde workloads netjes uit de kluis zijn opgeruimd.

STAP 4 valideert dat de replicatie-infrastructuur niet alleen werkt, maar ook daadwerkelijk voldoet aan de afgesproken RTO en RPO. Zonder periodieke testfailovers blijft disaster recovery een papieren zekerheid en worden fouten in netwerkconfiguraties, DNS-instellingen, certificaten of applicatie-afhankelijkheden vaak pas ontdekt tijdens een echte calamiteit. Plan minimaal per kwartaal een testfailover waarbij een replica-VM wordt opgestart in een geïsoleerd testnetwerk zonder impact op productie. Voer functionele tests uit samen met applicatie-eigenaren om te valideren dat applicaties correct starten, databases toegankelijk zijn, en gebruikers kunnen inloggen. Controleer ook dat alle afhankelijkheden zoals Key Vaults, storage accounts, load balancers en firewallregels correct zijn geconfigureerd in de failover-regio. Leg iedere stap vast in een runbook inclusief schermopnamen, PowerShell-commando's en verwachte doorlooptijden zodat het crisisteam dit kan volgen zonder extra uitleg. Meet daadwerkelijke RTO door de tijd te registreren tussen het starten van een testfailover en het moment waarop alle services beschikbaar zijn, en vergelijk dit met de afgesproken doelstellingen. Documenteer eventuele afwijkingen en plan verbetermaatregelen om de RTO te verbeteren indien nodig. Plan ook scenario-gestuurde tests waarbij bijvoorbeeld een volledige resourcegroep of applicatiestack wordt getest, inclusief afhankelijkheden zoals identiteitsvoorziening, netwerkbeveiliging en monitoring-systemen; rapporteer bevindingen aan het CISO-office en het crisisbeheetteam.

Monitoring en Onderhoud

Gebruik PowerShell-script site-recovery-enabled.ps1 (functie Invoke-Monitoring) – Automatiseer dagelijkse controles van replicatiestatus, RPO-achterstanden en gezondheid van de replicatie-infrastructuur, en integreer de resultaten met SIEM- of ITSM-workflows zodat afwijkingen altijd een opvolgtaak genereren..

Controleer dagelijks in het dashboard van de Recovery Services-kluis of alle replicaties succesvol zijn voltooid en onderzoek afwijkingen direct zodat RPO-doelstellingen nooit worden overschreden. Registreer elke bevinding in het ITSM-systeem en sluit deze pas wanneer de volgende replicatiecyclus bewezen succesvol is uitgevoerd. Documenteer de oorzaak-analyse en deel deze met ontwikkelteams zodat structurele fouten al tijdens de releaseplanning worden opgelost. Gebruik tagging om kritieke systemen prioriteit te geven wanneer meerdere incidenten tegelijk optreden en leg per incident vast welke lessons learned zijn toegepast. Site Recovery biedt ingebouwde health monitoring die automatisch waarschuwingen genereert wanneer replicaties mislukken, RPO wordt overschreden, of infrastructuren niet beschikbaar zijn. Stel waarschuwingen in via Azure Monitor, e-mail en Microsoft Teams zodat de piketdienst onmiddellijk een melding ontvangt bij replicatiefouten, uitgeschakelde Mobility Service-agents of netwerkconnectiviteitsproblemen en verbind opvolgacties aan duidelijke runbooks. Test de meldingen maandelijks door een gecontroleerde fout te simuleren en verifieer dat alle communicatiestromen werken. Verbreed de alerting met webhook-integraties richting SIEM of SOAR zodat automatisering direct herstelacties kan starten. Evalueer per kwartaal de drempelwaarden en zorg dat deze aansluiten bij veranderende workloads en bedrijfscontinuïteitsdoelstellingen.

Gebruik wekelijks het overzicht Gerepliceerde items of een geautomatiseerd PowerShell-rapport om te bevestigen dat iedere productie-workload daadwerkelijk aan een replicatiebeleid is gekoppeld en corrigeer afwijkingen voordat nieuwe releases live gaan. Combineer dit met Azure Resource Graph zodat ook shadow-IT workloads zichtbaar worden. Publiceer de resultaten in een gedeeld dashboard zodat productowners inzicht hebben in de naleving van hun applicaties. Neem afwijkingen op in het risicoregister totdat aantoonbaar herstel is uitgevoerd. Controleer maandelijks of replicatie-instellingen overeenkomen met wettelijke en contractuele verplichtingen en of de replicatiestatus volgens planning wordt geëvalueerd zodat datahygiëne en kostenbeheersing aantoonbaar geborgd blijven. Documenteer eventuele afwijkingen inclusief compensatiemaatregelen en zorg dat de CISO deze aftekent. Houd een overzicht bij van alle uitzonderingen inclusief einddatum en verantwoordelijke zodat tijdelijke maatregelen niet permanent blijven bestaan. Werk dit overzicht bij in het ISMS zodat auditors een directe referentie hebben.

Monitor het opslagverbruik van de replicatiedata en vergelijk dit met begrotingen; significante groei kan wijzen op foutieve replicatie-instellingen, ongewenste dataretentie of nieuwe workloads die niet zijn geoptimaliseerd. Visualiseer trends in Power BI zodat besluitvorming over lifecyclemanagement wordt ondersteund. Stel drempelwaarden in die automatisch een kostendossier openen wanneer het verbruik een afgesproken percentage overschrijdt. Neem hier ook voorspellingen in op zodat toekomstige investeringen tijdig kunnen worden aangevraagd. Plan ieder kwartaal een integraal testfailover-scenario waarbij techniek, documentatie en communicatie worden getest; leg bevindingen vast en voer verbeteringen direct door in beleid en scripts. Betrek naast IT ook proceseigenaren, communicatieadviseurs en crisiscoördinatoren om de volledige keten te oefenen. Wissel scenario's af, bijvoorbeeld regionale uitval, datacenterbrand, cyberaanval of netwerkstoring, zodat teams flexibel blijven. Rapporteer doorlooptijden en RTO/RPO-prestaties aan het directieteam. Gebruik Azure Policy en Microsoft Defender for Cloud-aanbevelingen om realtime te meten of nieuwe of gewijzigde workloads voldoen aan de verplichte replicatiestandaard en lever rapportages aan het auditteam. Koppel deze inzichten aan het risicoregister en bespreek structurele afwijkingen in het beveiligingsoverleg. Vertaal de bevindingen naar concrete verbeteracties met eigenaar, deadline en meetmethode. Zorg dat audittrail-gegevens minimaal zeven jaar beschikbaar blijven voor forensisch onderzoek en controleer jaarlijks of de rapportage-indeling nog aansluit bij auditwensen.

Compliance en Framework Mapping

Azure Site Recovery-configuraties zijn geen optionele luxe maar een harde compliance-eis binnen vrijwel alle relevante normenkaders die Nederlandse overheidsorganisaties moeten volgen. De Baseline Informatiebeveiliging Overheid (BIO) concretiseert continuïteitsvereisten in hoofdstuk 17.03 door te eisen dat organisaties maatregelen treffen voor bedrijfscontinuïteit en dat deze maatregelen periodiek worden getest. ISO 27001:2022 control A.17.1.3 benadrukt bovendien dat organisaties niet alleen disaster recovery-plannen moeten hebben, maar ook de procedures, verantwoordelijkheden en testresultaten moeten documenteren en regelmatig evalueren. De aankomende NIS2-richtlijn, artikel 21, verplicht aanbieders van essentiële en belangrijke diensten om maatregelen te treffen die de operationele continuïteit garanderen, waarbij expliciet wordt genoemd dat organisaties hun bedrijfscontinuïteits- en disasterrecoverymaatregelen regelmatig moeten beproeven. Ook sectordpecifieke normen zoals de zorgsector (NEN 7510), de financiële sector (DNB-richtlijnen) en kritieke infrastructuur (ENSIA) verwijzen expliciet naar gedocumenteerde disaster recovery-procedures en regelmatige tests. In audits vragen toezichthouders standaard naar runbooks, testverslagen, replicatiestatus-overzichten en bewijs van uitgevoerde testfailovers. Een organisatie die deze bewijslast niet paraat heeft, loopt risico op aanwijzingen, dwangsommen of zelfs intrekking van vergunningen en subsidies.

Aangezien de Nederlandse publieke sector steeds meer afhankelijk is van digitale dienstverlening, kan het niet aantonen van functionerende Azure Site Recovery-configuraties leiden tot bestuurlijke maatregelen, politieke verantwoordelijkheid en verlies van vertrouwen bij burgers. Het inrichten, testen en monitoren van Azure Site Recovery is daarmee een onmisbare bouwsteen om naleving van wet- en regelgeving te waarborgen. Zorg daarom dat ieder replicatiebeleid wordt goedgekeurd door het informatiebeveiligingsberaad, dat uitzonderingen schriftelijk worden vastgelegd en dat evidence minimaal zeven jaar wordt bewaard. Combineer technische logging met verklaringen van proceseigenaren, zodat auditors zowel harde cijfers als managementcommitment zien. Leg per testfailover vast welke scenario's zijn geoefend, welke KPI's zijn gehaald en welke verbeteracties zijn geformuleerd, zodat trendanalyse over meerdere jaren mogelijk wordt. Maak gebruik van Azure Policy compliance-rapporten en exporteer deze naar het ISMS, zodat auditteams real-time inzicht hebben in de status van workloads. Beschrijf in de auditkalender welke datasets wanneer worden aangeleverd en wijs een eigenaar per rapport aan zodat deadlines nooit worden gemist. Houd daarnaast een mapping bij tussen iedere control en de specifieke Azure-resources waarop deze van toepassing is, zodat nieuwe collega's snel begrijpen waar bewijs te vinden is. Plan halfjaarlijkse gesprekken met de interne auditdienst en externe toezichthouders om verwachtingen af te stemmen en te laten zien welke verbeteringen zijn doorgevoerd.

Remediatie en Verbetering

Gebruik PowerShell-script site-recovery-enabled.ps1 (functie Invoke-Remediation) – Dit script heractiveert ontbrekende replicaties, koppelt workloads opnieuw aan het juiste replicatiebeleid en initieert direct een nieuwe replicatiecyclus zodat naleving snel wordt hersteld. Het remediation-proces voert in één run een volledige ketencontrole uit: detectie van niet-beschermde workloads op basis van tag- of resourcegroepselectie, validatie van rolrechten, herconfiguratie van replicatie-instellingen en het opnieuw toewijzen van het juiste replicatiebeleid. Vervolgens wordt de Mobility Service-agent geïnstalleerd of herstart waar nodig, worden pending replicaties opgeschoond en wordt een nieuwe initiële replicatie gestart zodat er direct een vers replicatiepunt beschikbaar is voor audits. Het script schrijft uitgebreide logging weg naar zowel het scherm als een Log Analytics-werkruimte, inclusief tijdstempels, betrokken resources, toegepaste policies en eventuele fouten, waardoor forensische traceerbaarheid gewaarborgd blijft. Voor productieomgevingen kan een dry-run vlag worden gebruikt die alleen rapportages genereert; hiermee kunnen beheerders de impact vooraf beoordelen en noodzakelijke onderhoudsvensters plannen. Indien er afhankelijkheden zijn, zoals netwerkconnectiviteit of configuratieservers, controleert de logica automatisch of deze bereikbaar zijn voordat er wijzigingen worden doorgevoerd. Na afloop ontvangt het SOC een samenvattende melding via webhook of e-mail zodat opvolgacties en ticketregistratie direct kunnen plaatsvinden. Het script voorziet bovendien in ingebouwde validatie van RPO- en RTO-parameters, zodat alleen beleid wordt toegepast dat voldoet aan de afgesproken eisen uit de Nederlandse Baseline voor Veilige Cloud. Herstelacties worden standaard voorzien van een change-identificatie die kan worden teruggeleid naar het CAB-dossier, waardoor governance geborgd blijft. Daarnaast worden alle aangebrachte wijzigingen gespiegeld naar een configuration management database zodat asset-, eigenaar- en impactinformatie automatisch wordt bijgewerkt. Bij fouten kan het script per workload een rollback uitvoeren waarbij de vorige configuratie wordt teruggezet en een incidentmelding wordt aangemaakt voor nadere analyse. Met parameterbestanden kunnen organisaties verschillende omgevingen (bijvoorbeeld OT, ontwikkel of productie) met één scriptversie herstellen terwijl specifieke policies, vaults en netwerkrestricties behouden blijven. Dankzij ingebouwde integratie met Azure Monitor kunnen herstelacties metrics publiceren zoals duur van de initiële replicatie, aantal herstelde workloads en resterende afwijkingen, wat helpt bij managementrapportages. Het script ondersteunt tevens staged deployments waarbij eerst een subset van workloads wordt hersteld en pas na succesvolle validatie de volledige scope wordt geactiveerd. Authenticatie verloopt via beheerde identiteiten of workloadidentiteiten, waardoor geheimen niet lokaal hoeven te worden opgeslagen en het script voldoet aan zero-trustprincipes. Daarnaast bevat het playbook een self-test modus die de belangrijkste functies doorloopt en de resultaten tegen de schema.json-validatieset houdt, zodat updates van het script eenvoudig gecontroleerd kunnen worden voordat het in productie gebruikt wordt. Voor kritieke workloads biedt het een optionele integratie met het change management-portaal waarbij automatisch een reviewtaak voor de applicatie-eigenaar wordt aangemaakt, inclusief bewijs van de uitgevoerde replicaties. Tot slot kan het script een overzichtsrapport genereren met alle aangepaste resources, gekoppelde policies en nieuwe replicatiestatus, zodat auditors in één document de volledige remedial scope kunnen beoordelen. Desgewenst kan het rapport automatisch aan het ISMS of het ENSIA-portaal worden toegevoegd zodat bewijs direct beschikbaar is voor inspecties. In combinatie met de documentatie bij het script vormt dit een volledig draaiboek voor herstel van niet-conforme Site Recovery-situaties binnen de context van de Nederlandse Baseline voor Veilige Cloud..

Compliance & Frameworks

• BIO: 17.03 - Bedrijfscontinuïteit - Maatregelen voor continuïteit en periodieke beproeving
• ISO 27001:2022: A.17.1.3 - Information security aspects of business continuity management - Testing, maintaining and reassessing
• NIS2: Artikel - Operationele continuïteit, incidentrespons en testen van bedrijfscontinuïteitsplannen

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Azure Site Recovery levert geautomatiseerde replicatie en failover-capaciteit voor virtuele machines en applicaties tussen Azure-regio's of van on-premises naar Azure. Met een investering van enkele euro's per workload per maand wordt voldaan aan BIO 17.03, ISO 27001 A.17.1.3 en NIS2 artikel 21. Configureer replicatiebeleid, voer kwartaalgewijze testfailovers uit en koppel monitoring aan het SOC om continuïteit te garanderen.

• Implementatietijd: 200 uur
• FTE required: 0.5 FTE