Backup & Disaster Recovery

Herstel Zonder Heldendrama

In netwerkbeveiliging wint structuur van improvisatie: duidelijke paden, minder privileges en expliciete trust-grenzen.

Bij Backup & Disaster Recovery is herstel pas geloofwaardig als restore-tests aantonen dat tijdsdoelen haalbaar zijn.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Backup & Disaster Recovery is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

De 3-2-1-1-0 Regel

De klassieke 3-2-1-regel stamt uit de fotografie — Peter Krogh formuleerde hem in 2005 voor het beheer van digitale foto’s. Drie kopieën van je data, op twee verschillende mediatypen, waarvan een offsite. Het was goed advies. Het is niet meer genoeg.

In het tijdperk van ransomware is de regel uitgebreid tot 3-2-1-1-0:

Die laatste — nul fouten bij restore — is waar de meeste organisaties falen. Ze maken backups. Ze testen ze nooit. En dan, op de dag dat het ertoe doet, ontdekken ze dat de backup corrupt is, incompleet is, of een configuratie mist die cruciaal is voor het opstarten.

Backup Strategieën

RPO en RTO

Twee getallen die je disaster recovery-plan definiëren:

• RPO (Recovery Point Objective): hoeveel dataverlies is acceptabel? Een RPO van 4 uur betekent dat je maximaal 4 uur aan data kwijtraakt. Dit bepaalt hoe vaak je backupt.
• RTO (Recovery Time Objective): hoe snel moet je weer operationeel zijn? Een RTO van 8 uur betekent dat het herstel binnen 8 uur afgerond moet zijn. Dit bepaalt hoe je backupt.

De fout die iedereen maakt: RPO en RTO worden bepaald door het management op basis van wat ze willen, niet op basis van wat technisch haalbaar is. “We willen een RPO van 15 minuten en een RTO van 1 uur” klinkt prachtig in een vergadering. De realiteit is dat het herstellen van een domain controller uit een system state backup alleen al zes uur kan duren.

Immutable Backups

Een backup die de aanvaller kan wissen, is geen backup. Het is een uitgestelde teleurstelling.

S3 Object Lock (AWS)

{
    "Rules": [
        {
            "ID": "immutable-backup-rule",
            "Status": "Enabled",
            "Filter": {
                "Prefix": "backups/"
            },
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 90
            }
        }
    ]
}

# Object Lock inschakelen op de bucket (moet bij aanmaak)
aws s3api create-bucket \
    --bucket backup-immutable-2026 \
    --object-lock-enabled-for-object-lock-configuration

# Object Lock configuratie toepassen
aws s3api put-object-lock-configuration \
    --bucket backup-immutable-2026 \
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 90
            }
        }
    }'

COMPLIANCE-modus betekent dat niemand — zelfs de root-account niet — het object kan verwijderen gedurende de retentieperiode. GOVERNANCE-modus staat verwijdering toe met speciale permissions. Gebruik COMPLIANCE.

restic met append-only repository

# Initialiseer een restic repository met append-only backend
restic init --repo sftp:backup@vault:/restic-repo

# Maak een backup
restic backup --repo sftp:backup@vault:/restic-repo /etc /var/lib

# Op de backup-server: configureer de SFTP-gebruiker als append-only
# /home/backup/.ssh/authorized_keys:
command="restic-server --append-only --path /restic-repo",restrict ssh-ed25519 AAAA...

# De client kan backups aanmaken maar niet verwijderen
# restic forget en restic prune werken niet via append-only

Linux hardened backup repository

# Dedicated backup-gebruiker zonder shell
useradd -r -s /usr/sbin/nologin -d /backup backupuser

# Immutable filesystem met btrfs snapshots
btrfs subvolume snapshot -r /backup/current /backup/snapshots/$(date +%Y%m%d)
# De -r flag maakt de snapshot read-only

# Of met ZFS
zfs snapshot backup/data@$(date +%Y%m%d)
zfs hold keep backup/data@$(date +%Y%m%d)
# hold voorkomt automatische verwijdering

Active Directory Backup

Maersk verloor bijna alles omdat ze geen offline AD-backup hadden. Active Directory is het hart van een Windows-omgeving — zonder AD is er geen authenticatie, geen autorisatie, geen GPO’s, geen DNS (als je AD-integrated DNS draait, wat vrijwel iedereen doet).

System state backup

# Windows Server Backup installeren
Install-WindowsFeature Windows-Server-Backup

# System state backup naar dedicated schijf
wbadmin start systemstatebackup -backuptarget:E: -quiet

# Schema: dagelijks, naar een schijf die NIET aan het domein hangt
# Gebruik een lokaal account, niet een domain account

Wat zit er in een system state backup?

• Active Directory database (NTDS.dit)
• SYSVOL (Group Policy Objects, scripts)
• Registry
• Boot files
• Certificate Services database (als de DC ook CA is — wat het niet zou moeten zijn, maar vaak wel is)

DSRM (Directory Services Restore Mode)

# DSRM-wachtwoord instellen (doe dit NOW, niet tijdens een incident)
ntdsutil
  set dsrm password
  reset password on server null
  <wachtwoord>
  q
  q

# DSRM-wachtwoord documenteren en opslaan in een fysieke kluis
# Niet in een wachtwoordmanager die afhankelijk is van AD

Het DSRM-wachtwoord is je nooduitgang. Als AD corrupt is, start je de DC op in DSRM en herstel je vanuit de system state backup. Zonder DSRM-wachtwoord kun je niet bij de herstelprocedure. Bewaar het offline. Op papier. In een kluis.

Ransomware-bestendige Backup Architectuur

Moderne ransomware-groepen zijn niet dom. Ze weten dat backups hun verdienmodel ondermijnen. Daarom is een van de eerste acties na het verkrijgen van domain admin: de backups vernietigen.

Wat je moet afdekken

Architectuur die dit overleeft

PRODUCTIE-NETWERK                    BACKUP-NETWERK (apart VLAN)
+----------------+                   +----------------------+
| DC01, DC02     |                   | BACKUP-SRV           |
| Fileservers    +---[FW: alleen]--->| - Eigen credentials  |
| Applicaties    |   backup-poorten  | - Niet in het domein |
+----------------+                   | - Append-only repo   |
                                     +----------+-----------+
                                                |
                                     +----------+-----------+
                                     | OFFLINE / AIR-GAPPED |
                                     | - Tape / USB         |
                                     | - Wekelijks rotatie  |
                                     | - Fysieke kluis      |
                                     +----------------------+

Ontwerpprincipes:

1. Backup-server niet in het domein — een aanvaller met domain admin heeft geen automatische toegang
2. Aparte credentials — de backup-service draait met een lokaal account, niet een domain account
3. Netwerksegmentatie — alleen de backup-poorten zijn open, niets anders (zie hoofdstuk 15)
4. Append-only — de backup-agent kan schrijven maar niet verwijderen
5. Air-gapped kopie — minimaal wekelijks een kopie naar offline media

Recovery Testen

Een backup die je niet hebt getest, is een hypothese. En hypotheses zijn oncomfortabel wanneer het gebouw in brand staat.

Wat een full DR drill eruit ziet

Dag 0 (vrijdagavond):
  "Scenario: ransomware heeft alles versleuteld. Alle domain controllers,
   fileservers en applicatieservers zijn onbereikbaar. E-mail werkt niet.
   Telefoonlijsten staan op de fileserver (die ook versleuteld is).
   Begin met herstel."

Dag 1:
  - Wie belt wie? (Zonder e-mail, zonder telefoonlijsten op de server)
  - Waar zijn de backup-media fysiek?
  - Wie heeft het DSRM-wachtwoord?
  - In welke volgorde worden systemen hersteld?
  - DC eerst, dan DNS, dan fileserver, dan applicaties

Dag 2-3:
  - AD hersteld en operationeel?
  - DNS werkt?
  - Authenticatie werkt?
  - Kritieke applicaties draaien?

Evaluatie:
  - Wat ging goed?
  - Wat ging fout?
  - Wat ontbrak?
  - Hoe lang duurde het daadwerkelijk? (vergelijk met de beloofde RTO)

De meest voorkomende ontdekking bij een eerste DR drill: niemand weet waar de tapes liggen, het DSRM-wachtwoord is onbekend, en de herstelvolgorde is nooit gedocumenteerd. Beter om dat nu te ontdekken dan tijdens een echt incident.

Cloud Backup

Cloud backup is geen vervanging voor lokale backups — het is de offsite-component van de 3-2-1-1-0 regel.

Azure Backup immutable vault

# Maak een Recovery Services Vault met immutability
$vault = New-AzRecoveryServicesVault `
    -Name "backup-vault-immutable" `
    -ResourceGroupName "rg-backup" `
    -Location "westeurope"

# Schakel immutability in (LOCKED = onomkeerbaar)
Update-AzRecoveryServicesVaultProperty `
    -VaultId $vault.ID `
    -ImmutabilityState Locked

# Configureer soft delete (14 dagen extra bescherming)
Set-AzRecoveryServicesVaultProperty `
    -VaultId $vault.ID `
    -SoftDeleteFeatureState Enable

Waarschuwing over cloud-only backup

Cloud backup beschermt tegen lokale rampen. Het beschermt niet automatisch tegen een aanvaller die je cloud-credentials heeft gestolen. Als de aanvaller je Azure AD Global Administrator-account compromitteert, kan hij ook je Azure Backup verwijderen — tenzij je immutability hebt ingeschakeld. De incidentketen is niet hypothetisch: domain admin op on-premises leidt tot Azure AD Connect credential dump (zie ad_entra_connect), leidt tot Global Administrator in Azure, leidt tot toegang tot de backup vault.

Verdediging: immutability locks, aparte break-glass accounts voor backup-beheer met hardware MFA-tokens, en conditional access policies die backup-beheer beperken tot specifieke werkstations.

Samenvatting

Backup en disaster recovery zijn het verschil tussen “we zijn getroffen door ransomware en herstellen nu” en “we zijn getroffen door ransomware en betalen nu.” De 3-2-1-1-0 regel is het minimum: drie kopieën, twee mediatypen, een offsite, een offline of immutable, en nul fouten bij restore-tests. Immutable backups — via S3 Object Lock, append-only repositories, of locked vault policies — zijn de enige garantie dat een aanvaller met volledige netwerktoegang je backups niet kan vernietigen. Active Directory verdient speciale aandacht: een system state backup naar offline media, met een bekend en gedocumenteerd DSRM-wachtwoord, is het verschil tussen tien dagen herstel en een volledig verlies. De backup-server hoort niet in het domein, draait op eigen credentials, en staat in een apart netwerksegment (zie hoofdstuk 15). En bovenal: test je restores. Regelmatig. Volledig. Inclusief AD-herstel. Een backup die je nooit hebt getest, is een belofte die je nooit hebt waargemaakt. Maersk overleefde NotPetya dankzij een stroomstoring in Ghana. Dat is geen strategie. Dat is geluk. En geluk is eindig.