Continuïteit en herstel: De restore die niemand heeft getest

Elk backup-dashboard toont groene vinkjes. Jobs voltooid, retentiebeleid gehandhaafd, opslag gebruikt zoals verwacht. Niets daarvan zegt iets over de vraag of je een domeincontroller in minder dan vier uur vanaf blanco metaal kunt terugbrengen tijdens een werkelijk incident. De kloof tussen "backup geslaagd" en "restore geslaagd" is waar de meeste continuïteitsplannen stilletjes falen.

Waarom het vinkje liegt

Backup-software rapporteert succes wanneer het klaar is met het schrijven van bytes naar een bestemming. Het weet niet of die bytes bruikbaar zijn. Een SQL Server backup kan schoon worden voltooid en toch onherstelbaar zijn omdat de transactielogketen drie dagen eerder is verbroken en niemand dat opmerkte. VM-snapshots kunnen er prima uitzien in de console terwijl de onderliggende VSS writer stilletjes is mislukt in het gastbesturingssysteem, wat resulteert in een crash-consistent (niet application-consistent) image.

Ransomware-operatoren weten dit. Groepen die in eerdere incidenten Conti-achtige playbooks uitvoerden, kozen er doelbewust voor om backup-infrastructuur aan te vallen — shadow copies verwijderen met vssadmin delete shadows /all /quiet, Veeam-opslagplaatsen uitschakelen, NAS-gebaseerde backupdoelen versleutelen die bereikbaar waren via SMB. Als je backups op hetzelfde netwerkSegment staan als productie met domeinreferenties die ze kunnen aanraken, zijn ze een doelwit, niet een vangnet.

Maak een restore-runbook, geen backup-beleid

Een continuïteitsplan heeft stap-voor-stap restore-instructies nodig geschreven voor iemand die niet de persoon is die het normaal doet. Documenteer:

• Exact herstelorder (domeincontrollers en DNS eerst, dan kernappels, dan al het rest)
• Waar referenties voor de backup-console zich bevinden als je wachtwoordkluis ook uitvalt
• Het specifieke restore-commando of console-pad, niet "gebruik Veeam om de VM te herstellen"
• Verwachte duur per systeem, gebaseerd op werkelijk gemeten tests, niet op verkoopnummers van leveranciers

Voor Veeam Backup & Replication betekent dat het documenteren van de werkelijke stappen: open de console, navigeer naar Backups > Disk, klik met de rechtermuisknop op het restore point, kies Instant VM Recovery of Full VM Restore afhankelijk van het scenario, en selecteer de doelhost met voldoende vrije capaciteit. Als je primaire host ook is gecompromitteerd, heb je een tweede, geïsoleerde host al geïdentificeerd en gelicentieerd nodig.

Test restores volgens een schema, niet naar believen

Kies een rotatie. Elke maand, herstellen van één kritisch systeem naar een geïsoleerd VLAN en valideren dat het opstart, verifieert en correct gegevens levert. Elk kwartaal een volledige test: herstellen van je domeincontroller, je bestandsserver en je primaire database naar geïsoleerde infrastructuur, en laat vervolgens iemand buiten het backup-team inloggen en een rapport ophalen.

Voor databases, niet alleen het .bak-bestand herstellen — verifieer het:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

Herstel het dan daadwerkelijk naar een test-instantie en voer DBCC CHECKDB erop uit. Een backup die VERIFYONLY doorstaat, kan nog steeds logische corruptie bevatten die alleen verschijnt wanneer je dit opvraagt.

Voor Linux-systemen met iets als Bacula of restic, test het werkelijke restore-pad:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

Vergelijk vervolgens de herstelde configuratiebestanden met productie om te bevestigen dat niets stilletjes is verloren gegaan.

Onveranderbare kopieën en de 3-2-1-1-regel

De klassieke 3-2-1-regel (drie kopieën, twee mediatypen, één offsite) heeft een update nodig voor het ransomware-tijdperk: 3-2-1-1, waarbij de extra "1" een onveranderbare of air-gapped kopie is. Object lock op S3-compatibele opslag (Wasabi, Backblaze B2, of AWS S3 met Object Lock ingeschakeld) voorkomt verwijdering of wijziging gedurende een gedefinieerd bewaartermijn, zelfs door een account met admin-referenties. Configureer het met:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

COMPLIANCE-modus betekent dat niemand, ook niet de root-account, retentie kan verkorten of objecten voortijdig kan verwijderen. Dat is belangrijk wanneer de aanvaller domeinadmin heeft.

Meet RTO en RPO met werkelijke nummers, niet gissen

Recovery Time Objective en Recovery Point Objective klinken als administratieve oefeningen totdat een leidinggevende vraagt "hoeveel gegevens verliezen we en hoe lang zijn we down". Tijd je laatste drie test-restores. Als je RPO-doel één uur is, maar je backup-job slechts elke zes uur draait, heb je een gedocumenteerde kloof, en het is beter die kloof in een tabletop-oefening te vinden dan tijdens een werkelijk versleutelingsevenement om 2 uur 's ochtends op zaterdagochtend.

Voer de test uit, noteer de werkelijke klok tijd, en vergelijk deze met wat je in het disaster recovery-document hebt beloofd. Het verschil tussen die twee nummers is de werkelijke status van je continuïteitsplan.

Voor meer informatie over het beveiligen van de systemen die je beschermt en het opbouwen van incident response-workflows, zie de gerelateerde Blue Team en Digital Forensics segmenten op Korra Studio.