Continuïteit – overleven wanneer alles faalt¶

Machinevertaling van het Franse origineel.

Preventie, detectie en reactie kunnen allemaal mislukken. Wat dan overblijft, is het vermogen om weer op te bouwen. De vraag die hier beantwoord moet worden, is dus niet: "Is de back-up geslaagd?" maar: "Kan ik herstellen, en binnen welke tijd?" – twee vragen die verschillende antwoorden hebben.

De technische termen verwijzen naar de glossaris.

Vier niveaus van back-up¶

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef bk fill:#1e40af,stroke:#1e40af,color:#fff
    classDef off fill:#0f766e,stroke:#0f766e,color:#fff

    subgraph hotes["Hôtes du parc"]
        h["Hôtes de conteneurs · machines virtuelles<br/>hôte GPU · serveur hors site"]:::src
    end

    cli["Client de sauvegarde par hôte<br/>restic · chiffré AVANT l'envoi"]:::bk
    rest["Serveur de dépôt, sur le NAS<br/>ajout seul : aucune suppression<br/>depuis les hôtes"]:::bk
    snap["Instantanés du NAS"]:::bk
    rep["Réplication hors site"]:::off
    o1["Fournisseur hors site n° 1"]:::off
    o2["Fournisseur hors site n° 2"]:::off
    git["Configuration et décisions<br/>git, deux dépôts distants"]:::off

    h --> cli --> rest
    rest --> snap
    snap --> rep
    rep --> o1
    rep --> o2
    h --> git

Niveau	Tegen wat beschermd
1 · Versleutelde back-up per host	Verlies van een host, verwijdering, applicatiecorruptie
2 · Instanties van de NAS	Menselijke fout bij het opslaan, corruptie van de back-up zelf
3 · Twee back-ups op verschillende locaties, bij twee verschillende leveranciers	Verlies van de hele site – ramp, diefstal, ransomware die de NAS bereikt
4 · Git op twee externe repositories	Verlies van de configuratie, bestanden, beslissingen

Het versleutelen gebeurt door de gebruiker, voordat het wordt verzonden: geen van de back-up servers heeft de sleutels van de data die ze opslaan. Elke host heeft zijn eigen client, zijn eigen repository en een herstelplan; de integriteit van de repositories wordt gecontroleerd.

Immuabiliteit – de vraag van ransomware¶

Een moderne ransomware doet niet alleen data versleutelen: het zoekt naar back-ups, met de toegang die het op de gecompromitteerde machine vindt. De vraag die belangrijk is, is dus:

Kan iemand die een host heeft overgenomen, ook de back-ups vernietigen?

Het concept dat hier wordt bedoeld, heet immuabiliteit: een back-up die je niet kunt wijzigen of verwijderen vanaf de oorspronkelijke host.

De back-up server werkt met alleen toevoegingen. Een gebruiker kan nieuwe instanties maken; hij kan deze niet verwijderen of herschrijven. Het verwijderen van oude instanties gebeurt echter wel, met andere toegangspogingen.
Buiten het netwerk, wordt de onveranderlijkheid door de leverancier zelf gegarandeerd – bijvoorbeeld door middel van object locking, of door instanties die replicatie-toegang niet kunnen bereiken.

Hoe je dit kunt controleren: door te proberen

De onveranderlijkheid staat niet in een configuratie. Het wordt geconstateerd: door de toegangspogingen die de host daadwerkelijk heeft, probeer je een verwijdering, en wacht je op een afwijzing. Een test voert dit regelmatig uit. Een positief antwoord – de verwijdering is gelukt – is een mislukking van de test, niet een succes.

Waarom 'vers' niet voldoende is

Controles op versheid beantwoorden de vraag: "Is de back-up recent?" Een ransomware maakt recente back-ups – van gecodeerde inhoud, op een bepaald tijdstip, zonder fouten. Alleen de onveranderlijkheid en een test van het herstellen, beantwoorden de vraag: "Kan ik opnieuw beginnen?"

Echte herstel – de tijdmeting{ #exercice }¶

Een back-up die nooit is hersteld, is een aanname. Het herstelproces maakt dit een daadwerkelijke actie:

Kies een representatieve stack – een database, bestanden, een cache;
Maak een nieuwe, herbruikbare virtuele machine, die de stack nog nooit heeft gezien;
Herstel alleen vanuit de back-ups, zonder iets van de originele machine te kopiëren;
Meet de tijd totdat de API van de applicatie normaal reageert;
Noteer de leeftijd van de herstelde data;
Vernietig de machine.

De eerste oefening resulteerde in een RTO van ongeveer drie minuten, en een RPO van ongeveer één dag – meer dan twee in het slechtste geval, afhankelijk van het moment van de storing ten opzichte van de laatste back-up. Dit zijn gemeten waarden, niet doorgestelde doelen uit een plan.

Elke oefening wordt gedocumenteerd in een register. Een indicator gaat rood als de laatste back-up meer dan 90 dagen oud is: een succesvolle herstel van een jaar geleden zegt niets over de back-ups van vandaag.

Het gemeten RTO is een bodem, niet een scenario van een ramp

De variabelen van een stack worden nooit expliciet opgeslagen: ze zijn gecodeerd in de repository, en worden tijdens het opstarten ontsleuteld. Na het herstellen, zijn ze dus beschikbaar als een link naar een bestand dat niet meer bestaat.

Het herstellen van een stack vereist dus twee extra stappen dan het back-uppen: het geheime sleutel en de sleutel om de code te ontsleutelen. De oefening werd uitgevoerd met de beschikbare sleutel. Deze is voldoende voor een normaal incident; niet voor een ramp waarbij de sleutel verloren zou zijn. Daarom de volgende sectie.

De master sleutel – het enige scenario van totale verlies¶

Alle geheimen van de stacks zijn gecodeerd met één sleutel. Het verliezen van deze sleutel betekent het verliezen van alle geheimen – ook in de Git-historie, waar de gecodeerde versies permanent en onleesbaar blijven.

En de afhankelijkheid is circulair: het geheime sleutel is zelf een stack. Het ophalen van de sleutel uit een sleutel die je niet meer kunt gebruiken, is een eindeloze lus.

De oplossing is een offline kopie: op papier, bewaard buiten de omgeving, zonder enige netwerkverbinding.

Een kopie die nooit opnieuw wordt gelezen, is niet beter dan helemaal geen kopie. Maar het opnieuw lezen van een privé sleutel, is hetzelfde als deze openbaar maken. Het verificatiepakket lost beide problemen op:

een testgeheim, gecodeerd voor de hoofd sleutel en versiebeheerd;
een script dat de sleutel leest vanaf de standaard invoer — nooit als argument, nooit op het scherm, nooit in een bestand — probeert het testgeheim te decoderen en geeft pass of fail;
bewezen in beide richtingen: een valse sleutel geeft fail, de echte sleutel geeft pass, inclusief invoer via het papier.

Het complete oefening wordt uitgevoerd op een systeem dat is gestart vanaf een USB-stick, zonder netwerk, en direct vanaf het papier. Het is gedateerd en gevalideerd, en de validatie vervalt na een bepaalde tijd. Een controlemechanisme herinnert je eraan wanneer het ontbreekt.

Wat deze keuzes gemeenschappelijk hebben¶

De eigenschap testen, niet de configuratie. De onveranderlijkheid wordt vastgesteld door te proberen te verwijderen; de herstelbaarheid wordt vastgesteld door te herstellen.
Het geheim zo dicht mogelijk bij de data coderen. De client versleutelt; de servers bewaren octetten die ze niet kunnen lezen.
Afhankelijkheden opsporen voordat het probleem zich voordoet. De sleutel in de kluis, de kluis in het park, het park achter de sleutel: dit is het soort lus die je pas ontdekt als je probeert opnieuw te beginnen.

Om verder te lezen¶

Conformiteit en bewijs — hoe deze maatregelen bewijs vormen.
Antwoord — wat voorafgaat aan het herstellen.
Een geheim uit de kluis lezen.

Dernière vérification de cette page : 2026-09-11