Azure Backup Geconfigureerd Voor Critical Resources

Het ontbreken van back-ups vormt een kritiek risico voor elke organisatie. Bij een ransomware-aanval resulteert het ontbreken van back-ups in totaal gegevensverlies zonder herstelmogelijkheid. Hardwarestoringen leiden tot permanent gegevensverlies wanneer geen back-ups beschikbaar zijn. Menselijke fouten, zoals per ongeluk verwijderde bestanden of databases, zijn onomkeerbaar zonder adequate back-upstrategie. Disaster recovery wordt onmogelijk wanneer kritieke gegevens niet kunnen worden hersteld. Azure Backup lost deze problemen op door geautomatiseerde dagelijkse back-ups te bieden die zowel in rust als tijdens overdracht versleuteld zijn. De onveranderlijke opslag zorgt ervoor dat ransomware-aanvallen back-ups niet kunnen verwijderen. Point-in-time recovery maakt het mogelijk om gegevens te herstellen naar een specifiek moment in de tijd. Cross-region replicatie via Geo-Redundant Storage (GRS) biedt bescherming tegen regionale uitval. Configureerbare retentiebeleid ondersteunt periodes van 7 tot 99.999 dagen. Soft delete biedt een extra beveiligingslaag door verwijderde back-ups 14 dagen te behouden, waardoor onbedoelde verwijderingen kunnen worden hersteld.

Implementatie

De implementatie van Azure Backup omvat het aanmaken van een Recovery Services Vault als centrale opslaglocatie voor alle back-ups. Binnen deze vault worden back-upbeleidsregels gedefinieerd die bepalen wanneer back-ups worden gemaakt (dagelijks of wekelijks) en hoe lang ze worden bewaard. Voor virtuele machines wordt een agent-gebaseerde back-up geconfigureerd die de volledige VM-inhoud vastlegt. SQL-databases maken gebruik van native integratie met Azure Backup, waardoor transactionele consistentie wordt gegarandeerd. Bestandsshares worden beschermd via Azure File Share Backup. Geo-Redundant Storage (GRS) replicatie wordt ingeschakeld voor cross-region disaster recovery, waardoor gegevens automatisch naar een secundaire regio worden gekopieerd. Soft delete wordt geactiveerd als extra bescherming tegen ransomware, waardoor verwijderde back-ups 14 dagen behouden blijven. Regelmatige restore-tests zijn essentieel om te valideren dat back-ups daadwerkelijk werken en gegevens kunnen worden hersteld. De kosten bestaan uit opslagkosten van ongeveer €0,05 per GB per maand en beschermde instanties die tussen €5 en €10 per instantie per maand kosten, afhankelijk van het type resource en de gekozen retentieperiode.

Vereisten

Voor een succesvolle implementatie van Azure Backup moeten verschillende technische en organisatorische vereisten worden vervuld voordat de daadwerkelijke configuratie kan beginnen. De basisvereiste is het aanmaken van een Recovery Services Vault per Azure-regio waarin kritieke resources zich bevinden. Deze vault fungeert als centrale opslaglocatie voor alle back-ups en moet worden geconfigureerd met de juiste beveiligingsinstellingen en replicatie-opties. Elke regio waarin productie-workloads draaien, vereist een eigen vault om lokale hersteltijden te optimaliseren en compliance-vereisten te ondersteunen die mogelijk regionale data-residentie vereisen. De keuze voor de primaire regio moet worden gebaseerd op de locatie van de productie-resources om latency te minimaliseren en om te voldoen aan eventuele wettelijke vereisten voor gegevensopslag. Organisaties moeten zich realiseren dat de keuze voor de replicatiemethode tijdens het aanmaken van de vault definitief is en later niet meer kan worden gewijzigd zonder alle bestaande back-ups te verliezen, waardoor zorgvuldige planning essentieel is.

Back-upbeleidsregels vormen het hart van de back-upstrategie en moeten zorgvuldig worden gedefinieerd op basis van de Recovery Time Objective (RTO) en Recovery Point Objective (RPO) van elke workload. Deze doelstellingen bepalen respectievelijk hoeveel tijd er maximaal mag zitten tussen een incident en het volledige herstel van de service, en hoeveel gegevensverlies acceptabel is. Voor productie-omgevingen wordt doorgaans een dagelijks back-upschema aanbevolen, waarbij back-ups worden uitgevoerd tijdens rustige uren om de impact op productiesystemen te minimaliseren. De retentieperiode voor productie-resources varieert meestal tussen 30 en 90 dagen, afhankelijk van compliance-vereisten en bedrijfsbeleid. Langere retentieperiodes zijn mogelijk maar verhogen de opslagkosten exponentieel. Het is essentieel om voor elke resourcegroep of workload specifieke beleidsregels te definiëren die aansluiten bij de kritikaliteit en veranderingsfrequentie van de gegevens. Kritieke databases met hoge transactievolumes kunnen bijvoorbeeld dagelijkse back-ups vereisen met een retentieperiode van 90 dagen, terwijl minder kritieke bestandsshares mogelijk voldoende hebben aan wekelijkse back-ups met een retentieperiode van 30 dagen. Deze differentiatie helpt om kosten te optimaliseren terwijl de benodigde bescherming wordt geboden.

Geo-Redundant Storage (GRS) replicatie moet worden ingeschakeld voor alle Recovery Services Vaults om disaster recovery mogelijk te maken. GRS zorgt ervoor dat back-ups automatisch worden gerepliceerd naar een secundaire Azure-regio die minimaal 400 kilometer verwijderd is van de primaire regio. Deze geografische spreiding biedt bescherming tegen regionale uitval, natuurrampen of grootschalige technische problemen die een hele Azure-regio kunnen treffen. Hoewel GRS de opslagkosten verdubbelt in vergelijking met Locally Redundant Storage (LRS), is dit een noodzakelijke investering voor kritieke workloads waar bedrijfscontinuïteit van het grootste belang is. Organisaties moeten de secundaire regio strategisch kiezen, rekening houdend met compliance-vereisten zoals data-residentie wetgeving, latency-overwegingen voor restore-operaties, en de beschikbaarheid van Azure-services in die regio. Voor Nederlandse organisaties kan dit betekenen dat de secundaire regio binnen de Europese Unie moet blijven om te voldoen aan AVG-vereisten, terwijl tegelijkertijd voldoende geografische spreiding wordt geboden. De automatische replicatie zorgt ervoor dat back-ups in beide regio's beschikbaar zijn zonder handmatige interventie, wat de betrouwbaarheid van de disaster recovery strategie aanzienlijk verhoogt.

Soft delete vormt een kritieke beveiligingsfunctie die moet worden ingeschakeld voor alle Recovery Services Vaults als onderdeel van een uitgebreide ransomware-bescherming strategie. Deze functie biedt bescherming tegen geavanceerde ransomware-aanvallen waarbij aanvallers proberen back-ups te verwijderen voordat de versleuteling wordt geactiveerd, om te voorkomen dat organisaties kunnen herstellen zonder losgeld te betalen. Wanneer soft delete is ingeschakeld, blijven verwijderde back-ups 14 dagen behouden in een verwijderde staat, waardoor ze kunnen worden hersteld zelfs nadat een aanvaller toegang heeft gekregen tot het Azure-account en de back-ups heeft proberen te verwijderen. Deze periode kan worden verlengd tot 180 dagen voor extra bescherming tegen geavanceerde persistent threats, hoewel dit aanzienlijke extra opslagkosten met zich meebrengt. Soft delete is met name belangrijk voor organisaties die het doelwit kunnen zijn van geavanceerde persistent threats die specifiek gericht zijn op het vernietigen van back-ups als onderdeel van een bredere aanval. Deze functie werkt op het niveau van individuele back-upitems, waardoor zelfs wanneer een aanvaller volledige beheerdersrechten heeft verkregen, verwijderde back-ups nog steeds kunnen worden hersteld binnen de geconfigureerde retentieperiode. Het is belangrijk om te realiseren dat soft delete alleen effect heeft op back-ups die worden gemaakt nadat de functie is ingeschakeld, waardoor het cruciaal is om deze functie zo vroeg mogelijk in het implementatieproces te activeren.

Een gestructureerd restore-test schema is essentieel om te valideren dat back-ups daadwerkelijk functioneren en gegevens kunnen worden hersteld binnen de gestelde tijd. Kwartaalrestore-tests worden aanbevolen als minimum voor alle kritieke workloads, waarbij voor elke kritieke workload een volledige restore wordt uitgevoerd in een geïsoleerde testomgeving. Deze tests moeten niet alleen de technische functionaliteit valideren door te bevestigen dat back-ups kunnen worden hersteld, maar ook de hersteltijden meten en documenteren om te verifiëren dat Recovery Time Objective (RTO) doelstellingen worden gehaald. Veel organisaties ontdekken tijdens restore-tests dat back-ups technisch geslaagd zijn maar dat de hersteltijd veel langer is dan verwacht, waardoor RTO-doelstellingen niet worden gehaald en bedrijfscontinuïteit plannen moeten worden aangepast. Testprocedures moeten worden gedocumenteerd in detail en geautomatiseerd waar mogelijk om consistentie te waarborgen en menselijke fouten te voorkomen. Testresultaten moeten worden geregistreerd in een centrale database en geanalyseerd om trends te identificeren, zoals langzaam toenemende hersteltijden of terugkerende problemen met specifieke resource types. Deze analyse helpt bij het proactief aanpakken van problemen voordat ze kritiek worden. Voor zeer kritieke workloads kunnen maandelijkse restore-tests worden overwogen, hoewel dit aanzienlijke tijd en resources vereist. De tests moeten ook worden gebruikt om het herstelteam te trainen en om restore-procedures te valideren en te verbeteren op basis van geleerde lessen.

Budgetplanning is cruciaal voor een duurzame back-upstrategie die op lange termijn haalbaar blijft. De kosten bestaan uit twee hoofdcomponenten: opslagkosten en kosten voor beschermde instanties. Opslagkosten bedragen ongeveer €0,05 per GB per maand voor LRS (Locally Redundant Storage) en €0,10 per GB per maand voor GRS (Geo-Redundant Storage). Beschermde instanties kosten tussen €5 en €10 per instantie per maand, afhankelijk van het type resource en de gekozen retentieperiode. Voor een middelgrote organisatie met 50 virtuele machines, 10 SQL-databases en 20 bestandsshares, met een gemiddelde back-upgrootte van 100 GB per resource, resulteren de maandelijkse kosten in ongeveer €500 tot €750 voor beschermde instanties en €500 tot €1000 voor opslag, afhankelijk van de retentieperiode en replicatiemethode. Deze kosten kunnen aanzienlijk toenemen wanneer retentieperiodes worden verlengd of wanneer soft delete wordt geconfigureerd met langere retentieperiodes. Organisaties moeten deze kosten opnemen in hun IT-budget en regelmatig monitoren om onverwachte kostenstijgingen te voorkomen die kunnen optreden wanneer back-upgrootten sneller groeien dan verwacht of wanneer nieuwe resources worden toegevoegd aan de back-upstrategie. Kostenoptimalisatie kan worden bereikt door retentieperiodes te optimaliseren op basis van werkelijke behoeften, door incrementele back-ups te gebruiken waar mogelijk, en door regelmatig te evalueren of alle geback-upte resources daadwerkelijk kritiek zijn en bescherming vereisen.

Implementatie

Gebruik PowerShell-script azure-backup-configured.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van Azure Backup begint met het aanmaken van een Recovery Services Vault in de primaire Azure-regio waar de kritieke resources zich bevinden. Deze vault fungeert als centrale opslaglocatie voor alle back-ups en moet worden geconfigureerd met de juiste beveiligingsinstellingen vanaf het moment van aanmaak. Tijdens het aanmaken van de vault moet direct Geo-Redundant Storage (GRS) replicatie worden ingeschakeld, omdat deze keuze later niet meer kan worden gewijzigd zonder alle bestaande back-ups te verliezen. Deze onomkeerbare beslissing maakt het cruciaal om de configuratie zorgvuldig te plannen voordat de vault wordt aangemaakt. GRS replicatie zorgt ervoor dat alle back-ups automatisch worden gekopieerd naar een secundaire regio die minimaal 400 kilometer verwijderd is van de primaire regio, wat essentieel is voor disaster recovery scenario's waarbij een hele Azure-regio uitvalt. De secundaire regio wordt automatisch gekozen door Azure op basis van geografische spreiding en beschikbaarheid, maar organisaties kunnen een voorkeursregio opgeven tijdens het configuratieproces om te voldoen aan specifieke compliance-vereisten zoals data-residentie wetgeving. Voor Nederlandse organisaties is het belangrijk om te verifiëren dat de secundaire regio binnen de Europese Unie blijft om te voldoen aan AVG-vereisten, terwijl tegelijkertijd voldoende geografische spreiding wordt geboden voor effectieve disaster recovery.

Soft delete moet worden ingeschakeld voor alle Recovery Services Vaults als onderdeel van de ransomware-bescherming. Deze functie kan worden geactiveerd via de beveiligingsinstellingen van de vault en biedt standaard 14 dagen bescherming tegen onbedoelde of kwaadwillende verwijdering van back-ups. Voor organisaties met een hoog risicoprofiel kan deze periode worden verlengd tot 180 dagen, hoewel dit aanzienlijke extra opslagkosten met zich meebrengt. Soft delete werkt op het niveau van de back-upitems, waardoor zelfs wanneer een aanvaller toegang krijgt tot het Azure-account en back-ups probeert te verwijderen, deze nog steeds kunnen worden hersteld binnen de geconfigureerde retentieperiode. Deze functie is met name waardevol omdat moderne ransomware-aanvallen vaak gericht zijn op het vernietigen van back-ups voordat de versleuteling wordt geactiveerd.

Back-upbeleidsregels vormen de kern van de back-upstrategie en moeten zorgvuldig worden geconfigureerd. Een standaard beleidsregel voor productie-workloads omvat dagelijkse back-ups die worden uitgevoerd om 2:00 uur 's nachts, wanneer de belasting op systemen doorgaans het laagst is. De retentieperiode wordt meestal ingesteld op 30 dagen voor standaard workloads, maar moet worden aangepast op basis van de specifieke Recovery Time Objective (RTO) en Recovery Point Objective (RPO) vereisten van elke workload. Kritieke databases kunnen bijvoorbeeld een retentieperiode van 90 dagen vereisen, terwijl minder kritieke bestandsshares mogelijk voldoende hebben aan 14 dagen. Het is belangrijk om te realiseren dat langere retentieperiodes exponentieel meer opslagruimte vereisen, waardoor kostenbeheer een belangrijke overweging wordt. Beleidsregels kunnen worden aangepast na implementatie, maar wijzigingen hebben alleen effect op nieuwe back-ups, niet op reeds gemaakte back-ups.

Voor virtuele machines wordt een agent-gebaseerde back-up geconfigureerd waarbij de Azure Backup-extensie wordt geïnstalleerd op elke VM. Deze extensie communiceert met de Recovery Services Vault en voert de back-ups uit zonder dat er een aparte back-upserver nodig is. De agent kan worden geïnstalleerd via de Azure Portal, Azure PowerShell of als onderdeel van de VM-implementatie via Infrastructure as Code. Na installatie van de agent moet elke VM worden gekoppeld aan een back-upbeleidsregel die bepaalt wanneer en hoe vaak back-ups worden gemaakt. Voor grote omgevingen met tientallen of honderden VM's wordt aanbevolen om de configuratie te automatiseren via PowerShell-scripts of Azure Resource Manager templates om consistentie te waarborgen en implementatiefouten te voorkomen.

SQL-databases maken gebruik van native integratie met Azure Backup, waardoor transactionele consistentie wordt gegarandeerd zonder dat er een agent nodig is. De back-up wordt uitgevoerd op database-niveau en maakt gebruik van de SQL Server backup API's, waardoor de back-ups volledig compatibel zijn met standaard SQL Server restore-procedures. Deze integratie zorgt ervoor dat back-ups transactioneel consistent zijn, wat betekent dat alle transacties die op het moment van de back-up actief waren, correct worden afgehandeld. Voor Always On beschikbaarheidsgroepen en failover cluster instances worden speciale overwegingen gemaakt om ervoor te zorgen dat back-ups worden uitgevoerd op de primaire replica. De configuratie wordt uitgevoerd via de Azure Portal of PowerShell, waarbij de SQL Server wordt geregistreerd in de Recovery Services Vault en vervolgens databases worden geselecteerd voor back-up.

Bestandsshares worden beschermd via Azure File Share Backup, een specifieke functie die is ontworpen voor Azure Files. Deze back-upmethode maakt gebruik van share-momentopnamen die incrementeel worden opgeslagen, waardoor alleen gewijzigde bestanden worden geback-upt in plaats van de volledige share. Dit resulteert in efficiëntere back-ups en lagere opslagkosten. De back-up kan worden geconfigureerd via de Azure Portal door de storage account te selecteren en de gewenste bestandsshares te kiezen. Net als bij VM's en SQL-databases moet een back-upbeleidsregel worden gekoppeld die bepaalt wanneer back-ups worden gemaakt en hoe lang ze worden bewaard. Voor grote bestandsshares met veel kleine bestanden kan de initiële back-up aanzienlijke tijd in beslag nemen, maar incrementele back-ups zijn doorgaans zeer snel.

Waarschuwingen moeten worden geconfigureerd voor alle kritieke gebeurtenissen, met name back-upfouten en restore-operaties. Back-upfouten moeten worden geconfigureerd als kritieke waarschuwingen die direct worden verzonden naar het security operations center of de IT-beheerders via e-mail, SMS of integratie met een SIEM-systeem. Restore-operaties moeten worden geconfigureerd als waarschuwingen met hoge prioriteit omdat deze kunnen wijzen op een security incident of dataverlies. Azure Monitor kan worden gebruikt om geavanceerde waarschuwingsregels te definiëren die bijvoorbeeld alleen waarschuwen wanneer meerdere back-ups achtereenvolgens falen, of wanneer back-ups langer duren dan verwacht. Deze waarschuwingen moeten worden getest tijdens de implementatiefase om ervoor te zorgen dat ze correct worden ontvangen en dat de ontvangers weten hoe ze moeten reageren.

Restore-procedures moeten worden gedocumenteerd voor elk type resource dat wordt geback-upt. Deze documentatie moet stap-voor-stap instructies bevatten voor het uitvoeren van een restore, inclusief hoe te kiezen tussen verschillende restore-opties zoals volledige restore, bestandsniveau restore of point-in-time restore. De documentatie moet ook informatie bevatten over geschatte hersteltijden, vereiste machtigingen en eventuele speciale overwegingen voor specifieke workloads. Deze procedures moeten regelmatig worden getest, minimaal elk kwartaal, om te valideren dat back-ups daadwerkelijk werken en dat het herstelteam bekend is met de procedures. Veel organisaties ontdekken tijdens deze tests dat back-ups technisch geslaagd zijn maar dat de hersteltijd veel langer is dan verwacht, waardoor RTO-doelstellingen niet worden gehaald. Deze tests moeten worden uitgevoerd in een geïsoleerde testomgeving om te voorkomen dat productiesystemen worden beïnvloed.

Het monitoren van back-up succespercentages is essentieel om problemen vroegtijdig te detecteren en te verhelpen. Azure Backup biedt een dashboard in de Azure Portal dat een overzicht geeft van alle back-upactiviteiten, inclusief succesvolle en mislukte back-ups. Dit dashboard moet regelmatig worden gecontroleerd, idealiter dagelijks voor kritieke workloads en wekelijks voor minder kritieke resources. Naast het dashboard kunnen Azure Monitor workbooks worden geconfigureerd om geavanceerde analyses uit te voeren op back-updata, zoals trends in back-upgrootte, gemiddelde back-uptijden en patronen in back-upfouten. Deze informatie kan worden gebruikt om back-upbeleidsregels te optimaliseren en problemen proactief aan te pakken voordat ze kritiek worden.

Monitoring

Gebruik PowerShell-script azure-backup-configured.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Azure Backup is essentieel om te waarborgen dat back-ups consistent worden uitgevoerd en dat problemen vroegtijdig worden gedetecteerd. Het Azure Backup dashboard in de Azure Portal biedt een centraal overzicht van alle back-upactiviteiten, inclusief succesvolle en mislukte back-ups, back-upgrootten en hersteloperaties. Dit dashboard moet regelmatig worden gecontroleerd, idealiter dagelijks voor kritieke workloads en wekelijks voor minder kritieke resources. Het dashboard toont real-time statusinformatie voor alle beveiligde items, waardoor beheerders snel kunnen identificeren welke resources problemen ondervinden. Naast het standaard dashboard kunnen Azure Monitor workbooks worden geconfigureerd om geavanceerde analyses uit te voeren, zoals trends in back-upgrootte over tijd, gemiddelde back-uptijden per resource type en patronen in back-upfouten. Deze geavanceerde monitoring helpt bij het identificeren van onderliggende problemen voordat ze kritiek worden.

Waarschuwingen voor back-upfouten moeten worden geconfigureerd als kritieke meldingen die direct worden verzonden naar het security operations center of de verantwoordelijke IT-beheerders. Deze waarschuwingen moeten worden geconfigureerd voor alle soorten back-upfouten, inclusief volledige mislukkingen, gedeeltelijke mislukkingen en back-ups die langer duren dan verwacht. Azure Monitor kan worden gebruikt om geavanceerde waarschuwingsregels te definiëren die bijvoorbeeld alleen waarschuwen wanneer meerdere back-ups achtereenvolgens falen, of wanneer back-ups langer duren dan een bepaalde drempelwaarde. Deze waarschuwingen moeten worden geïntegreerd met bestaande monitoring- en incident response-systemen, zoals SIEM-platforms of ticketing-systemen, om ervoor te zorgen dat problemen worden opgepikt en opgelost volgens de gestelde service level agreements. Het is cruciaal dat deze waarschuwingen worden getest tijdens de implementatiefase om ervoor te zorgen dat ze correct worden ontvangen en dat de ontvangers weten hoe ze moeten reageren.

Het volgen van back-upgrootte trends is belangrijk voor capaciteitsplanning en kostenbeheer. Back-upgrootten moeten regelmatig worden geanalyseerd om te identificeren of er onverwachte groei optreedt die kan wijzen op data groei, configuratiefouten of zelfs security incidents zoals ransomware-aanvallen die grote hoeveelheden data versleutelen. Azure Monitor kan worden gebruikt om historische trends te analyseren en voorspellingen te maken over toekomstige opslagbehoeften. Deze informatie kan worden gebruikt om back-upbeleidsregels te optimaliseren, bijvoorbeeld door retentieperiodes aan te passen voor resources waar de back-upgrootte sneller groeit dan verwacht. Daarnaast kunnen trends in back-upgrootte worden gebruikt om budgetplanning te ondersteunen en om stakeholders te informeren over de kostenontwikkeling van de back-upstrategie.

Kwartaalrestore-tests zijn een kritiek onderdeel van de monitoringstrategie en moeten worden uitgevoerd voor alle kritieke workloads. Deze tests valideren niet alleen dat back-ups technisch functioneren, maar ook dat de hersteltijden binnen de gestelde Recovery Time Objective (RTO) vallen. Tijdens deze tests moet een volledige restore worden uitgevoerd in een geïsoleerde testomgeving, waarbij alle stappen worden gedocumenteerd en de tijd wordt gemeten. Veel organisaties ontdekken tijdens deze tests dat back-ups technisch geslaagd zijn maar dat de hersteltijd veel langer is dan verwacht, waardoor RTO-doelstellingen niet worden gehaald. Deze tests moeten ook worden gebruikt om het herstelteam te trainen en om restore-procedures te valideren en te verbeteren. Testresultaten moeten worden geregistreerd in een centrale database en geanalyseerd om trends te identificeren en verbeterpunten te detecteren. Voor zeer kritieke workloads kunnen maandelijkse restore-tests worden overwogen, hoewel dit aanzienlijke tijd en resources vereist.

Het auditen van resources zonder back-ups is essentieel om te waarborgen dat alle kritieke resources daadwerkelijk worden beschermd. Regelmatige audits moeten worden uitgevoerd om te identificeren welke resources wel en niet worden geback-upt, en om te valideren dat nieuwe resources automatisch worden toegevoegd aan de back-upstrategie. Deze audits kunnen worden geautomatiseerd via PowerShell-scripts of Azure Policy om consistentie te waarborgen en menselijke fouten te voorkomen. Tijdens audits moeten ook de back-upconfiguraties worden gecontroleerd om te valideren dat ze voldoen aan de gestelde beleidsregels, bijvoorbeeld dat GRS replicatie is ingeschakeld en dat soft delete is geactiveerd. Auditresultaten moeten worden gedocumenteerd en gerapporteerd aan management en compliance-teams om te demonstreren dat de organisatie voldoet aan de gestelde back-upvereisten. Voor organisaties met strikte compliance-vereisten kunnen deze audits maandelijks of zelfs wekelijks worden uitgevoerd.

Compliance en Auditing

Azure Backup implementatie moet voldoen aan verschillende compliance-vereisten die van toepassing zijn op Nederlandse overheidsorganisaties en bedrijven die werken met gevoelige gegevens. ISO 27001 controle A.12.3.1 vereist dat organisaties regelmatige back-ups maken van informatie en software, en dat deze back-ups regelmatig worden getest om te waarborgen dat ze kunnen worden hersteld. Deze controle vereist dat back-ups worden opgeslagen op een veilige locatie, gescheiden van de primaire gegevensopslag, en dat er procedures zijn gedocumenteerd voor het maken, beheren en herstellen van back-ups. Azure Backup voldoet aan deze vereisten door geautomatiseerde back-ups te bieden die worden opgeslagen in een Recovery Services Vault, gescheiden van de productie-omgeving, met geconfigureerde retentiebeleidsregels en gedocumenteerde restore-procedures. Organisaties moeten kunnen aantonen dat back-ups regelmatig worden getest, idealiter elk kwartaal, en dat testresultaten worden gedocumenteerd voor audit-doeleinden.

ISO 27001 controle A.17.1.2 vereist dat organisaties bedrijfscontinuïteit procedures ontwikkelen, implementeren en onderhouden die zijn ontworpen om de continuïteit van bedrijfsprocessen te waarborgen tijdens en na een verstoring. Azure Backup speelt een cruciale rol in deze procedures door te waarborgen dat kritieke gegevens kunnen worden hersteld na een incident, waardoor bedrijfsprocessen kunnen worden hervat. De implementatie moet deel uitmaken van een bredere bedrijfscontinuïteit strategie die Recovery Time Objectives (RTO) en Recovery Point Objectives (RPO) definieert voor verschillende workloads. Deze doelstellingen moeten worden gebruikt om back-upbeleidsregels te configureren, bijvoorbeeld door de frequentie en retentieperiode van back-ups af te stemmen op de RPO-vereisten. Organisaties moeten kunnen aantonen dat back-ups zijn geconfigureerd in overeenstemming met de gedefinieerde bedrijfscontinuïteit doelstellingen en dat restore-procedures zijn getest en gevalideerd.

De NIS2-richtlijn, zoals geïmplementeerd in de Nederlandse wetgeving, vereist in Artikel 21 dat essentiële en belangrijke entiteiten passende maatregelen treffen voor back-up en herstel van systemen en gegevens. Deze vereiste is met name relevant voor organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg en financiële dienstverlening. Azure Backup voldoet aan deze vereiste door geautomatiseerde, versleutelde back-ups te bieden met cross-region replicatie voor disaster recovery. Organisaties moeten kunnen aantonen dat alle kritieke systemen en gegevens worden geback-upt, dat back-ups regelmatig worden getest, en dat er procedures zijn voor het herstellen van systemen en gegevens na een incident. De NIS2-richtlijn vereist ook dat organisaties incidenten rapporteren aan de relevante autoriteiten, waarbij back-up- en herstelcapaciteiten een belangrijk onderdeel vormen van de incident response strategie.

Het Baseline Informatiebeveiliging Overheid (BIO) framework vereist in Thema 17.01 (Continuïteitsbeheer) dat organisaties maatregelen treffen om de continuïteit van bedrijfsprocessen te waarborgen, inclusief back-up- en herstelprocedures. Het BIO-framework benadrukt het belang van regelmatige tests van back-up- en herstelprocedures, en vereist dat organisaties kunnen aantonen dat back-ups daadwerkelijk werken en dat gegevens kunnen worden hersteld binnen de gestelde tijd. Azure Backup implementaties moeten worden gedocumenteerd in het informatiebeveiligingsbeleid van de organisatie, en back-upconfiguraties moeten worden gecontroleerd tijdens interne en externe audits. Het BIO-framework vereist ook dat organisaties risicoanalyses uitvoeren om te identificeren welke systemen en gegevens kritiek zijn voor de bedrijfsvoering, en dat back-upstrategieën worden afgestemd op deze kritikaliteit. Voor zeer kritieke systemen kunnen aanvullende maatregelen nodig zijn, zoals meerdere back-upkopieën op verschillende locaties of langere retentieperiodes.

De Algemene Verordening Gegevensbescherming (AVG) vereist in Artikel 32 dat organisaties passende technische en organisatorische maatregelen treffen om persoonsgegevens te beschermen tegen verlies, vernietiging of ongeautoriseerde toegang. Back-ups vormen een belangrijk onderdeel van deze maatregelen door te waarborgen dat persoonsgegevens kunnen worden hersteld na een incident zoals een ransomware-aanval, hardwarestoring of menselijke fout. Azure Backup voldoet aan AVG-vereisten door versleuteling te bieden voor gegevens in rust en tijdens overdracht, en door toegangscontroles te implementeren die bepalen wie back-ups kan maken, beheren en herstellen. Organisaties moeten kunnen aantonen dat back-ups zijn geconfigureerd in overeenstemming met AVG-vereisten, en dat er procedures zijn voor het omgaan met verzoeken van betrokkenen om hun persoonsgegevens in te zien, te corrigeren of te verwijderen. Deze procedures moeten rekening houden met de mogelijkheid dat persoonsgegevens zich in back-ups bevinden, en moeten definiëren hoe dergelijke verzoeken worden afgehandeld, inclusief het verwijderen van persoonsgegevens uit back-ups wanneer dit vereist is.

Remediatie

Gebruik PowerShell-script azure-backup-configured.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer Azure Backup niet is geconfigureerd voor kritieke resources, vormt dit een directe bedreiging voor de bedrijfscontinuïteit en gegevensbescherming van de organisatie. Remediatie moet onmiddellijk worden gestart zodra wordt vastgesteld dat kritieke resources niet worden geback-upt. Het remediatieproces begint met een grondige inventarisatie van alle resources die bescherming vereisen, waarbij wordt gekategoriseerd op basis van kritikaliteit en data-classificatie. Virtuele machines die productie-workloads hosten, SQL-databases met bedrijfskritieke gegevens, en bestandsshares met belangrijke documenten moeten allemaal worden geïdentificeerd en geprioriteerd voor back-upconfiguratie. Deze inventarisatie moet worden uitgevoerd door een multidisciplinair team bestaande uit IT-beheerders, security officers en business stakeholders om te waarborgen dat alle kritieke resources worden geïdentificeerd en dat de prioritering aansluit bij de bedrijfsdoelstellingen.

Het eerste kritieke onderdeel van de remediatie is het aanmaken van een Recovery Services Vault in de juiste Azure-regio. Deze vault moet worden geconfigureerd met Geo-Redundant Storage (GRS) replicatie vanaf het moment van aanmaak, omdat deze keuze later niet meer kan worden gewijzigd zonder alle bestaande back-ups te verliezen. De keuze voor de primaire regio moet worden gebaseerd op de locatie van de productie-resources om latency te minimaliseren en compliance-vereisten te ondersteunen. De secundaire regio voor GRS replicatie moet strategisch worden gekozen, rekening houdend met geografische spreiding, compliance-vereisten zoals data-residentie, en de beschikbaarheid van Azure-services in die regio. Organisaties moeten zich realiseren dat GRS replicatie de opslagkosten verdubbelt, maar dat dit een noodzakelijke investering is voor kritieke workloads waar bedrijfscontinuïteit van het grootste belang is.

Soft delete moet onmiddellijk worden ingeschakeld voor alle Recovery Services Vaults als onderdeel van de ransomware-bescherming. Deze functie biedt bescherming tegen geavanceerde aanvallen waarbij aanvallers proberen back-ups te verwijderen om herstel te voorkomen. Wanneer soft delete is ingeschakeld, blijven verwijderde back-ups standaard 14 dagen behouden in een verwijderde staat, waardoor ze kunnen worden hersteld zelfs nadat een aanvaller toegang heeft gekregen tot het Azure-account. Voor organisaties met een hoog risicoprofiel kan deze periode worden verlengd tot 180 dagen, hoewel dit aanzienlijke extra opslagkosten met zich meebrengt. Het is belangrijk om te realiseren dat soft delete alleen effect heeft op back-ups die worden gemaakt nadat de functie is ingeschakeld, waardoor het cruciaal is om deze functie zo vroeg mogelijk in het remediatieproces te activeren.

Back-upbeleidsregels moeten worden gedefinieerd op basis van de Recovery Time Objective (RTO) en Recovery Point Objective (RPO) vereisten van elke workload. Voor productie-omgevingen wordt doorgaans een dagelijks back-upschema aanbevolen, waarbij back-ups worden uitgevoerd tijdens rustige uren om de impact op productiesystemen te minimaliseren. De retentieperiode voor productie-resources varieert meestal tussen 30 en 90 dagen, afhankelijk van compliance-vereisten en bedrijfsbeleid. Kritieke databases kunnen een retentieperiode van 90 dagen vereisen, terwijl minder kritieke bestandsshares mogelijk voldoende hebben aan 14 dagen. Het is essentieel om te realiseren dat langere retentieperiodes exponentieel meer opslagruimte vereisen, waardoor kostenbeheer een belangrijke overweging wordt. Beleidsregels kunnen worden aangepast na implementatie, maar wijzigingen hebben alleen effect op nieuwe back-ups, niet op reeds gemaakte back-ups, waardoor het belangrijk is om de initiële configuratie zorgvuldig te plannen.

Voor virtuele machines wordt een agent-gebaseerde back-up geconfigureerd waarbij de Azure Backup-extensie wordt geïnstalleerd op elke VM. Deze extensie communiceert met de Recovery Services Vault en voert de back-ups uit zonder dat er een aparte back-upserver nodig is. De agent kan worden geïnstalleerd via de Azure Portal, Azure PowerShell of als onderdeel van de VM-implementatie via Infrastructure as Code. Voor grote omgevingen met tientallen of honderden VM's wordt aanbevolen om de configuratie te automatiseren via PowerShell-scripts of Azure Resource Manager templates om consistentie te waarborgen en implementatiefouten te voorkomen. Na installatie van de agent moet elke VM worden gekoppeld aan een back-upbeleidsregel die bepaalt wanneer en hoe vaak back-ups worden gemaakt. Het is belangrijk om te valideren dat de agent correct is geïnstalleerd en dat de eerste back-up succesvol is voltooid voordat wordt overgegaan naar de volgende VM.

SQL-databases maken gebruik van native integratie met Azure Backup, waardoor transactionele consistentie wordt gegarandeerd zonder dat er een agent nodig is. De back-up wordt uitgevoerd op database-niveau en maakt gebruik van de SQL Server backup API's, waardoor de back-ups volledig compatibel zijn met standaard SQL Server restore-procedures. Deze integratie zorgt ervoor dat back-ups transactioneel consistent zijn, wat betekent dat alle transacties die op het moment van de back-up actief waren, correct worden afgehandeld. Voor Always On beschikbaarheidsgroepen en failover cluster instances worden speciale overwegingen gemaakt om ervoor te zorgen dat back-ups worden uitgevoerd op de primaire replica. De configuratie wordt uitgevoerd via de Azure Portal of PowerShell, waarbij de SQL Server wordt geregistreerd in de Recovery Services Vault en vervolgens databases worden geselecteerd voor back-up. Het is belangrijk om te valideren dat de eerste back-up succesvol is voltooid en dat transactionele consistentie wordt gegarandeerd.

Bestandsshares worden beschermd via Azure File Share Backup, een specifieke functie die is ontworpen voor Azure Files. Deze back-upmethode maakt gebruik van share-momentopnamen die incrementeel worden opgeslagen, waardoor alleen gewijzigde bestanden worden geback-upt in plaats van de volledige share. Dit resulteert in efficiëntere back-ups en lagere opslagkosten. De back-up kan worden geconfigureerd via de Azure Portal door de storage account te selecteren en de gewenste bestandsshares te kiezen. Net als bij VM's en SQL-databases moet een back-upbeleidsregel worden gekoppeld die bepaalt wanneer back-ups worden gemaakt en hoe lang ze worden bewaard. Voor grote bestandsshares met veel kleine bestanden kan de initiële back-up aanzienlijke tijd in beslag nemen, maar incrementele back-ups zijn doorgaans zeer snel. Het is belangrijk om de initiële back-up te monitoren en te valideren dat deze succesvol is voltooid voordat wordt overgegaan naar de volgende bestandsshare.

Waarschuwingen moeten worden geconfigureerd voor alle kritieke gebeurtenissen, met name back-upfouten en restore-operaties. Back-upfouten moeten worden geconfigureerd als kritieke waarschuwingen die direct worden verzonden naar het security operations center of de IT-beheerders via e-mail, SMS of integratie met een SIEM-systeem. Restore-operaties moeten worden geconfigureerd als waarschuwingen met hoge prioriteit omdat deze kunnen wijzen op een security incident of dataverlies. Azure Monitor kan worden gebruikt om geavanceerde waarschuwingsregels te definiëren die bijvoorbeeld alleen waarschuwen wanneer meerdere back-ups achtereenvolgens falen, of wanneer back-ups langer duren dan verwacht. Deze waarschuwingen moeten worden getest tijdens de remediatiefase om ervoor te zorgen dat ze correct worden ontvangen en dat de ontvangers weten hoe ze moeten reageren. Het is cruciaal dat deze waarschuwingen worden geconfigureerd voordat de back-upconfiguratie als compleet wordt beschouwd.

Na voltooiing van de remediatie moet onmiddellijk een restore-test worden uitgevoerd om te valideren dat back-ups daadwerkelijk functioneren en gegevens kunnen worden hersteld. Deze test moet worden uitgevoerd in een geïsoleerde testomgeving om te voorkomen dat productiesystemen worden beïnvloed. Tijdens de test moet een volledige restore worden uitgevoerd voor ten minste één resource van elk type (VM, SQL-database, bestandsshare), waarbij alle stappen worden gedocumenteerd en de tijd wordt gemeten. Veel organisaties ontdekken tijdens deze tests dat back-ups technisch geslaagd zijn maar dat de hersteltijd veel langer is dan verwacht, waardoor RTO-doelstellingen niet worden gehaald. Deze tests moeten ook worden gebruikt om het herstelteam te trainen en om restore-procedures te valideren en te verbeteren. Testresultaten moeten worden geregistreerd in een centrale database en geanalyseerd om trends te identificeren en verbeterpunten te detecteren. Alleen wanneer de restore-test succesvol is voltooid, kan de remediatie als compleet worden beschouwd.

Compliance & Frameworks

• BIO: 17.01.02, 17.01.03 - Continuïteitsbeheer - Back-up en herstel
• ISO 27001:2022: A.12.3.1, A.17.1.2 - Informatieback-up en bedrijfscontinuïteit
• NIS2: Artikel - Back-up- en herstelcapaciteiten

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 Backup voor kritieke resources omvat virtuele machines, SQL-databases, bestandsshares en Cosmos DB. Belangrijke functies zijn geautomatiseerde dagelijkse back-ups, versleuteling in rust, onveranderlijke opslag die ransomware-bescherming biedt doordat back-ups niet kunnen worden gewist, cross-region disaster recovery en soft delete met een herstelvenster van 14 dagen. Activatie gebeurt via een Recovery Services Vault waarbij back-ups per resourcetype worden geconfigureerd. De kosten bedragen €5 tot €15 per instantie per maand plus opslagkosten. Kwartaalrestore-tests zijn essentieel om te valideren dat herstel daadwerkelijk werkt. De implementatie vereist 6 tot 8 uur. Dit is absoluut niet-onderhandelbaar voor productie-omgevingen.

• Implementatietijd: 8 uur
• FTE required: 0.1 FTE