9.5 Disaster recovery en bedrijfscontinuïteit

Overzicht en motivatie

Vroeg of laat haalt iets waarvoor je niet had gepland een systeem neer: een uitval van een hele cloudregio, een met vette vingers getypte DROP TABLE, een overstroming in een datacentrum, een ransomware-ontploffing of een leverancier die van de ene op de andere nacht verdwijnt. De vraag is nooit of verstoring komt, maar hoe snel je herstelt en hoeveel je onderweg verliest. Dit hoofdstuk gaat over klaar zijn voor de slechte dag voordat die komt.

Twee disciplines beantwoorden die gereedheid, en ze zijn niet hetzelfde. Bedrijfscontinuïteitsplanning (BCP) houdt de hele organisatie functionerend door een verstoring heen: mensen, kantoren, communicatie, salarisadministratie en de kritieke bedrijfsprocessen waarvan klanten afhangen. Disaster recovery (DR) is de smallere, technische taak van IT-systemen en data herstellen nadat ze zijn gefaald. Continuïteit is het doel, herstel is een van de middelen. Je kunt elke server herstellen en toch je klanten teleurstellen als niemand wist wie een ramp mocht uitroepen of hoe ze te bereiken. Dit hoofdstuk behandelt DR als engineeringpraktijk en BCP als het bedrijfskader dat ze dient.

Voor grote teams schaalt de inzet met je mee. Een onderneming draagt wettelijke herstelverplichtingen, voetafdrukken over meerdere regio’s en concentratierisico in een handvol leveranciers. De overheid draagt een wettelijke plicht essentiële functies voor burgers in stand te houden, vastgelegd als continuïteit van operaties. Beide opereren onder toezicht waar een ongetest plan een verplichting is die je op het slechtst denkbare moment ontdekt. Herstel is waar betrouwbaarheid (hoofdstuk 9.1) en incidentrespons (hoofdstuk 9.3) de moeilijkere vraag ontmoeten van het overleven van de falen die je niet weg kunt ontwerpen.

Kernprincipes

Continuïteit is breder dan herstel. Servers herstellen is niet hetzelfde als het bedrijf laten draaien.
Twee getallen drijven alles. Recovery time objective (RTO) en recovery point objective (RPO), vastgesteld uit bedrijfsimpact, bepalen elke beslissing.
Een ongetest back-up is geen back-up. Een herstel dat je nooit hebt uitgevoerd is een hoop, geen vermogen.
Neem aan dat de back-up een doelwit is. Ransomware jaagt eerst op je back-ups, dus houd kopieën onveranderlijk en offline.
Herbouw uit code, niet uit geheugen. Als je infrastructuur niet uit bron kunt hercreëren, kun je haar niet betrouwbaar herstellen.
Breng in kaart waarvan je afhangt. Je herstelt alleen zo snel als je traagste upstreamafhankelijkheid.
Meet herstel zoals elk ander systeem. Werkelijke RTO en RPO uit echte oefeningen, niet de getallen die je op een dia schreef.

Aanbevelingen

Stel RTO en RPO vast uit een bedrijfsimpactanalyse

Elke herstelbeslissing stamt af van twee getallen, dus krijg ze eerst goed. De recovery time objective (RTO) is hoe lang een systeem down kan zijn voordat de schade onaanvaardbaar is. De recovery point objective (RPO) is hoeveel data je je kunt veroorloven te verliezen, gemeten als de leeftijd van de laatste goede kopie waarnaar je kunt herstellen. Een betalingsgrootboek kan een RTO van minuten en een RPO bijna nul eisen. Een intern analysedashboard kan een dag van elk verdragen. Je kunt deze niet in engineering vaststellen. Leid ze af uit een bedrijfsimpactanalyse (BIA) die bedrijfsprocessen rangschikt naar de kosten van hun verstoring en elk terugvoert naar de systemen en data die het nodig heeft. Strakkere doelen kosten meer, dus de BIA is wat je ervan weerhoudt een triviale service te vergulden en een kritieke onder te beschermen.

Doe back-ups goed: de 3-2-1-regel, onveranderlijkheid en testen

Back-ups zijn de bodem onder elke herstelstrategie, en de meeste organisaties doen ze slechter dan ze denken. Volg de back-updiscipline bekend als de 3-2-1-regel: houd minstens drie kopieën van je data, op twee verschillende media of systemen, met één kopie extern. Moderne dreigingen voegen twee eisen toe. Houd minstens één kopie onveranderlijk (eenmaal beschrijfbaar, niet te verwijderen gedurende een bewaarvenster) en bij voorkeur offline of air-gapped, omdat ransomware nu opzettelijk bereikbare back-ups versleutelt of verwijdert voordat het zich meldt. Test vooral herstel volgens schema. Een ongetest back-up is geen back-up, het is een ongetoetste aanname, en de falen die je in een oefening vindt (corrupte archieven, ontbrekende versleutelingssleutels, back-ups van het verkeerde volume) zijn precies degene die je in een echte gebeurtenis hadden beëindigd.

Kies een DR-strategie langs het spectrum van kosten tegenover snelheid

DR-strategieën ruilen geld tegen hersteltijd, en je moet per systeem kiezen op basis van zijn RTO en RPO in plaats van één laag voor alles te kopen. Vier patronen verankeren het spectrum. Back-up en herstel is het goedkoopst en traagst: je herbouwt uit back-ups wanneer de ramp toeslaat, met een RTO van uren tot dagen. Pilot light houdt een minimale kern (databases repliceren, kernconfiguratie op zijn plaats) warm maar afgeschaald, klaar om uit te breiden. Warm standby draait een kleinere altijd-aan kopie van de volledige stack die je bij failover opschaalt, wat de RTO tot minuten snijdt. Multi-site active-active draait volledige capaciteit op twee of meer locaties die live verkeer bedienen, wat een RTO bijna nul geeft tegen de hoogste kosten en complexiteit. Stem de laag af op het getal dat het bedrijf goedkeurde, en betaal geen active-activeprijzen voor een systeem dat een pilot light verdraagt.

Repliceer data met de consistentieafweging in gedachten

De hersteltijd hangt af van hoe actueel je standby-data is, en hier erf je de moeilijke problemen van gedistribueerde systemen (hoofdstuk 3.3). Synchrone replicatie bevestigt elke schrijfactie op een tweede locatie voordat ze wordt erkend, wat een RPO bijna nul geeft tegen extra schrijflatentie en een harde afstandsgrens. Asynchrone replicatie erkent lokaal en verstuurt wijzigingen daarna, dus ze is snel en geografisch flexibel maar laat een replicatievertragingsvenster dat je bij failover verliest. Er is geen gratis keuze: sterkere consistentie kost latentie, zwakkere consistentie kost data. Besluit per datastore uit zijn RPO, en ken je typische replicatievertraging, want die vertraging is je echte RPO op een slechte dag, niet het getal in het ontwerpdocument.

Herbouw uit code met infrastructure as code

Je kunt een omgeving die je met de hand inrichtte niet betrouwbaar herstellen, want niemand herinnert zich elke klik. Definieer je omgevingen als infrastructure as code (hoofdstuk 8.2) zodat een hele stack uit versiebeheerde bron in een bekend-goede toestand kan worden hercreëerd. Dit zet herstel om van een archeologieproject in een herhaalbare pijplijnrun, houdt je standbyregio eerlijk (ze drijft minder af wanneer beide uit dezelfde code zijn gebouwd) en geeft je een schone manier om herstelinfrastructuur in een nieuw account of regio op te zetten na een compromittering. Bewaar de code, verwijzingen naar geheimen en runbooks ergens waar ze het verlies van je primaire omgeving overleven.

Breng afhankelijkheden in kaart voordat je ze nodig hebt

Systemen falen in webben, niet geïsoleerd, en herstel loopt vast op de afhankelijkheid die je vergat. Breng in kaart wat elk kritiek systeem nodig heeft om te functioneren: upstreamservices, DNS, identiteit en authenticatie, certificaatautoriteiten, berichtenwachtrijen en API’s en SaaS-aanbieders van derden. Noteer de herstelvolgorde, want een applicatie opstarten vóór haar database of identiteitsprovider produceert slechts een tweede uitval. Besteed bijzondere aandacht aan externe leveranciers, aangezien je herstel wordt begrensd door het hunne en je mogelijk geen zicht erop hebt. Deze kaart sluit direct aan op veerkracht en soepele degradatie (hoofdstuk 3.5): hoe minder harde afhankelijkheden een systeem heeft, hoe sneller het terugkomt.

Test herstel als praktijk, niet als gebeurtenis

Een DR-plan dat je niet hebt geoefend is fictie. Bouw een ladder van tests. Een tabletopoefening loopt het team op papier door een scenario om gaten in rollen, beslissingen en communicatie te vinden. Een game day injecteert een echte gecontroleerde fout in een live-achtige omgeving. Een volledige failoveroefening schakelt werkelijk over naar de herstellocatie en draait erop. Doe deze volgens een ritme, wissel de scenario’s af (inclusief het verlies van een sleutelpersoon of leverancier) en meet de uitkomst: leg de werkelijke RTO en RPO vast die je haalde en vergelijk ze met het doel. Het gat tussen gemeten en beloofd herstel is de eerlijkste betrouwbaarheidsstatistiek die je bezit, en het sluiten ervan is het hele punt van de oefening.

Plan cyberherstel als eigen scenario

Ransomware en destructieve cyberaanvallen breken de aannames van gewone DR, dus behandel ze apart. Bij een natuurramp is je data elders intact. Bij een ransomwaregebeurtenis zijn je data en vaak je back-ups het wapen, en kan je herstelomgeving zelf gecompromitteerd zijn. Plan een clean-roomherstel: een geïsoleerde, vertrouwde omgeving waar je uit onveranderlijke kopieën herstelt, scant op de indringing en identiteit en inloggegevens herbouwt voordat je iets weer verbindt. Weet welke back-up je laatste bekend-schone punt is, en verwacht dat het vinden ervan forensische tijd kost die je gewone RTO nooit begrootte. Hier verdienen onveranderlijke, offline kopieën hun kosten terug, en het sluit nauw aan op incidentmanagement (hoofdstuk 9.3) en op compliance- en governanceverplichtingen voor inbreukafhandeling (hoofdstuk 4.6).

Afwegingen: voor- en nadelen

DR-strategie	Voordelen	Nadelen
Back-up en herstel	Goedkoopst. Eenvoudig. Lage lopende kosten	Trage RTO (uren tot dagen). Grotere RPO
Pilot light	Lage kosten. Kerndata warm en klaar	Handmatig opschalen. Herstel kost nog echte tijd
Warm standby	Snelle RTO (minuten). Volledige stack bewezen	Lopende kosten van een draaiende tweede omgeving
Multi-site active-active	RTO bijna nul. Geen enkelvoudige-locatiefalen	Hoogste kosten en complexiteit. Consistentie is moeilijk
Synchrone replicatie	RPO bijna nul	Schrijflatentie. Afstandsbeperkt. Strakkere koppeling
Asynchrone replicatie	Snel, flexibel, geografisch vrij	Dataverliesvenster gelijk aan replicatievertraging

De centrale spanning is dat hersteltijd en datavers zowel geld als complexiteit kosten, en geen van beide gratis is op enige laag. Los het per systeem op in plaats van per organisatie: laat de bedrijfsimpactanalyse elk kritiek systeem een RTO en RPO toewijzen, en koop dan precies de strategie die eraan voldoet. Active-activegeld besteden aan een rapportagetool laat het grootboek verhongeren dat het nodig had, en het omgekeerde is nalatigheid. De discipline is de uitgave afstemmen op het getal dat het bedrijf bezit, en die afstemming herzien naarmate systemen in belang veranderen.

Vragen om met je team te bespreken

Wat zijn de RTO en RPO voor elk van je kritieke systemen, en wie in het bedrijf heeft ze goedgekeurd? Als engineering deze getallen alleen verzon, zijn het gissingen, en gissingen worden te ruim gefinancierd of helemaal niet. De recovery time en recovery point objectives horen voort te komen uit een bedrijfsimpactanalyse die processen rangschikt naar de kosten van hun verstoring, zodat het grootboek minuten krijgt en de interne wiki een dag. Neem je huidige indeling mee en vraag of de persoon die verantwoordelijk is voor elk bedrijfsproces het dataverlies en de downtime waarvoor je ontwierp werkelijk zou accepteren. In een grote organisatie voorkomt dit gesprek de dure fout alles gelijk te beschermen, wat niets goed beschermt. Als niemand buiten engineering de getallen kan noemen, heb je nog geen doelstellingen, maar hoop.
Wanneer voerde je voor het laatst een echt herstel uit, en mat je de werkelijke RTO en RPO die je haalde? Een back-up die je nooit hebt hersteld is een ongetoetste aanname, en de faalwijzen die je doden (corrupte archieven, verloren versleutelingssleutels, een snapshot van het verkeerde volume, een afhankelijkheid die niet opkomt) verschijnen pas wanneer je het probeert. Neem de datum en uitkomst van je laatste volledige failoveroefening mee, niet je laatste tabletop, en het gat tussen het herstel dat je haalde en het herstel dat je beloofde. Voor een groot team bewijst één geslaagd herstel van één systeem de andere niet, dus vraag welk deel van de kritieke systemen het afgelopen jaar end-to-end is hersteld. Het gemeten gat is je eerlijkste betrouwbaarheidsgetal, en als je het niet kunt noemen, is je plan fictie tot het tegendeel bewezen is.
Als ransomware vannacht je productie versleutelde en je back-ups bereikte, wat is je laatste bekend-schone kopie en waar zou je herbouwen? Gewoon disaster recovery neemt aan dat je data ergens anders veilig is, en een destructieve cyberaanval breekt precies die aanname door je data en je back-ups het wapen te maken. Vraag of minstens één back-upkopie onveranderlijk en offline is, hoe je het laatste schone herstelpunt zou vaststellen en waar een vertrouwde clean-roomomgeving vandaan zou komen wanneer productie zelf is gecompromitteerd. Dit scenario vraagt forensische tijd die je normale RTO nooit begrootte, dus neem een eerlijke schatting mee van hoe lang een schoon punt vinden werkelijk duurt. Voor teams van onderneming en overheid is dit ook een compliancegebeurtenis (hoofdstuk 4.6) met parallel lopende meldingsklokken voor inbreuken. Als het antwoord “we zouden de laatste back-up herstellen” is, heb je hier helemaal niet voor gepland.
Welk van je systemen betaalt voor een herstellaag die zijn bedrijfsimpactanalyse niet rechtvaardigt, en welk is gevaarlijk onderbeschermd? Hersteltijd en datavers kosten op elke laag geld, dus een algemeen beleid verspilt óf active-activebudget aan een rapportagetool óf laat het grootboek verhongeren dat het werkelijk nodig had. De concurrerende trek is echt: één standaardlaag is voor veel teams veel eenvoudiger te bedienen, terwijl indeling per systeem de uitgave aan waarde koppelt maar doorlopend curatorschap vraagt naarmate het belang van een systeem verschuift. Neem de huidige DR-strategie voor elk kritiek systeem mee, de RTO en RPO die het beoogt, de maandelijkse kosten van zijn standby en replicatie en de datum waarop de indeling voor het laatst werd herzien aan een verse impactanalyse. In een omgeving van onderneming of overheid vermenigvuldigt een niet-passende laag zich over regio’s en zal audit vragen zowel het geld dat je uitgeeft als de blootstelling die je aanvaardt te verantwoorden, dus een onverklaarde active-activerekening en een onbeschermde kritieke service zijn even moeilijk te verdedigen.
Ken je werkelijk de herstelvolgorde van je kritieke systemen, en hoe ver hangt je herstel af van leveranciers die je niet kunt testen? Systemen falen in webben, niet geïsoleerd, en herstel loopt vast op de afhankelijkheid die niemand in kaart bracht: start een applicatie vóór haar database, identiteitsprovider of DNS en je produceert slechts een tweede uitval. Afhankelijkheden in kaart brengen is vervelend en de kaart veroudert, maar het alternatief is de herstelvolgorde live ontdekken tijdens een failover, en concentratierisico in een handvol SaaS-aanbieders blijft onzichtbaar tot ze samen falen en je herstel tot het hunne begrenzen. Neem een actuele afhankelijkhedenkaart mee, de gedocumenteerde herstelvolgorde en een lijst van externe leveranciers met hun vermelde herstelverbintenissen en of je er ooit een hebt gevalideerd. Voor een grote of publieke organisatie zijn leverancierscontinuïteit en concentratierisico steeds meer een aanbestedings- en regelgevingskwestie, dus die herstelverplichtingen horen in het contract in een vorm die je kunt auditen in plaats van in de marketing van een leverancier.
Als je vannacht elke server herstelde, zou het bedrijf dan werkelijk blijven draaien, en wie is bevoegd een ramp uit te roepen? Disaster recovery herstelt IT, maar bedrijfscontinuïteit houdt de organisatie functionerend: mensen, communicatie, salarisadministratie en de beslissingen die ervan afhangen dat iemand de bevoegdheid heeft ze te nemen. Je kunt elk systeem herstellen en toch je klanten teleurstellen als niemand wist wie een ramp kon uitroepen of hoe medewerkers te bereiken wanneer de normale kanalen ook down zijn. Engineering bezit herstel, maar continuïteit omspant faciliteiten, HR, communicatie en leiderschapsopvolging, en die naden tussen afdelingen zijn precies waar een plan stilletjes rot. Neem de uitroepbevoegdheid en escalatieketen mee, het terugvalcommunicatieplan, de benoemde opvolgers en alternatieve faciliteiten en de datum waarop de bedrijfskant (niet alleen IT) het plan voor het laatst oefende. De overheid draagt een wettelijke plicht tot continuïteit van operaties met benoemde opvolgers en essentiële functies, en ondernemingen kennen wettelijke continuïteitsverplichtingen, dus beide worden beoordeeld op of het bedrijf de slechte dag overleeft, niet slechts de servers.

Sectorperspectief

Startup. Met een klein team en weinig runway kun je je geen hete tweede regio veroorloven, dus wees bewust over de goedkope onderdelen die je nog steeds redden. Stel één eerlijke herstellaag in, volg de 3-2-1-regel met geautomatiseerde snapshots en minstens één onveranderlijke kopie die je eigen beheerders niet kunnen verwijderen, en houd de hele omgeving als infrastructure as code zodat je uit bron kunt herbouwen. Sla het uitgebreide plan over en voer in plaats daarvan elk kwartaal één echt herstel uit in een krabbelomgeving, want één getimede oefening leert je meer dan een ordner die niemand leest.

Kleinbedrijf. Zonder speciale continuïteitsspecialist en met een krap budget behandel je herstel als iets dat je koopt in plaats van bouwt. Leun op het beheerde back-up, snapshot en replicatie over regio’s van je cloudaanbieder in plaats van eigen DR-infrastructuur op te zetten, en kies leveranciers wier back-ups onveranderlijk zijn en wier herstelproces je zelf kunt uitvoeren. Kader de hele oefening rond twee vragen die je zonder specialist kunt beantwoorden: hoeveel data kunnen we verliezen en hoe lang kunnen we down zijn, en bewijs dat één herstel werkt voordat je het vertrouwt.

Grote onderneming. Op schaal is het probleem portfoliogovernance over veel teams: een bedrijfsimpactanalyse die elke service een RTO en RPO toewijst, herstelstrategieën getierd van back-up-en-herstel tot active-active en een centraal beeld van upstream- en leveranciersafhankelijkheden inclusief concentratierisico. Begroot de kosten van standby, replicatie en onveranderlijke kopieën expliciet, voer volgens ritme volledige failovers uit waar een toezichthouder getuige van is en meet werkelijk herstel tegen doel als gevolgde betrouwbaarheidsstatistiek. Onderhoud cyberherstel als eigen programma met onveranderlijke kluiskopieën en een clean-roomrunbook, onafhankelijk getest van de natuurrampoefeningen.

Overheid. Aanbestedingsregels, transparantie en publieke verantwoording geven elke keuze vorm, en continuïteit is vaak een wettelijke plicht in plaats van een voorkeur. Bouw een programma voor continuïteit van operaties dat essentiële functies identificeert, hun herstel ordent en opvolgers en alternatieve faciliteiten benoemt zodat beslissingen nooit stilvallen bij gebrek aan een bevoegd persoon, en stem het af op erkende richtlijnen zoals NIST SP 800-34 ter ondersteuning van FISMA-verplichtingen. Houd air-gapped back-upkopieën, definieer infrastructure as code voor herbouw in een alternatieve regio en voer een jaarlijkse volledige oefening plus ransomware-tabletopoefeningen uit waarvan je de gemeten resultaten aan toezichtsorganen rapporteert als bewijs dat essentiële diensten overleven.

Voorbeelden

Startup. Een SaaS-bedrijf van twaalf personen kan zich geen hete tweede regio veroorloven en is dus bewust over de goedkope onderdelen. Het stelt één eerlijke laag in: RTO van vier uur, RPO van vijftien minuten voor de klantendatabase. Het volgt de 3-2-1-regel met geautomatiseerde snapshots, één kopie gerepliceerd naar een tweede cloudregio en één onveranderlijke kopie met een vergrendeld bewaarvenster dat de eigen beheerders niet kunnen verwijderen. De hele omgeving is infrastructure as code (hoofdstuk 8.2), dus ze kan een verse stack uit bron opzetten. Eens per kwartaal voert ze op een vrijdagmiddag een echt herstel uit in een krabbelomgeving, timet het en legt een korte notitie vast. De eerste oefening duurde negen uur en vond een ontbrekende migratiestap. De reparatie is waarom de volgende drie uur duurde.

Grote onderneming. Een multinationale bank opereert onder wettelijke herstelvereisten die geteste continuïteit voor kritieke diensten voorschrijven. Ze draait warm standby in een tweede regio voor haar kernbankplatform, met synchrone replicatie binnen een metropaar voor een RPO bijna nul en asynchrone replicatie naar een verre regio om een regionale ramp te overleven. Een bedrijfsimpactanalyse wijst elke service een RTO en RPO toe, en een centraal team brengt upstreamafhankelijkheden in kaart inclusief twee SaaS-aanbieders gemarkeerd als concentratierisico. Tweemaal per jaar voert ze een volledige failover uit waar een toezichthouder getuige van is, meet werkelijk tegen doel en voedt de gaten in de volgende cyclus. Een apart cyberherstelprogramma onderhoudt onveranderlijke kluiskopieën en een clean-roomrunbook, onafhankelijk getest van de natuurrampoefeningen.

Overheid. Een nationaal agentschap dat uitkeringen levert onderhoudt een programma voor continuïteit van operaties (COOP) gebouwd om zijn essentiële functies bij elke verstoring in stand te houden. Volgens de praktijk van continuïteit van operaties en de NIST SP 800-34-richtlijnen voor noodplanning die zijn FISMA-verplichtingen ondersteunen identificeert het essentiële functies, ordent hun herstel en benoemt opvolgers en alternatieve faciliteiten zodat beslissingen nooit stilvallen bij gebrek aan een bevoegd persoon. Burgergerichte systemen dragen gedocumenteerde RTO en RPO, back-ups volgen de 3-2-1-regel met air-gapped kopieën en infrastructuur is als code gedefinieerd voor herbouw in een alternatieve regio. Een jaarlijkse volledige oefening, plus tabletopoefeningen voor een ransomwarescenario, toetst het plan aan gemeten herstel, en de resultaten worden aan toezichtsorganen gerapporteerd als bewijs dat essentiële diensten de slechte dag overleven.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het rendement van DR en continuïteit is vermeden catastrofe, wat echt moeilijk te waarderen is tot je het nodig hebt en pijnlijk concreet wanneer dat zo is. Formuleer het als risicobeheer: de verwachte kosten van een verstoring zijn haar waarschijnlijkheid maal haar impact, en impact voor een grote organisatie loopt van verloren omzet per uur downtime via wettelijke boetes en meldingskosten voor inbreuken tot de reputatieschade die de uitval overleeft. Eén onherstelbare ransomwaregebeurtenis heeft bedrijven beëindigd en in de publieke sector essentiële burgerdiensten wekenlang offline gehaald. Daartegenover zijn de kosten van een getest herstelvermogen bescheiden en kenbaar.

De total cost of ownership (TCO) is echt en doorlopend: standby-infrastructuur, replicatiebandbreedte, back-upopslag (vermenigvuldigd met onveranderlijke en offline kopieën) en de engineeringtijd om automatisering te bouwen en oefeningen te draaien. Dit is precies waarom je indeelt naar RTO en RPO in plaats van overal active-active te kopen, zodat de uitgave de waarde van elk systeem volgt in plaats van een algemeen beleid. Maak de zaak voor leiderschap door het plan in hun taal te vertalen: dit is de downtime en het dataverlies die we vandaag kunnen overleven, dit is het gat naar onze doelen, dit kost het sluiten ervan en dit is de blootstelling als we dat niet doen. Het meest overtuigende artefact is een gemeten oefening, want een herstel dat je hebt aangetoond is een getal dat leiderschap kan vertrouwen, en een ongetest plan is een verplichting vermomd als bezit.

Antipatronen en valkuilen

Ongetoetste back-ups. Een herstel dat je nooit hebt uitgevoerd is een hoop. De oefening is waar je de corruptie, de ontbrekende sleutel en het verkeerde volume vindt.
Back-ups bereikbaar vanuit productie. Als ransomware je back-ups kan versleutelen of verwijderen, heb je één kopie, geen drie. Houd er één onveranderlijk en offline.
Eén RTO en RPO voor alles. Algemene lagen beschermen het triviale te veel en het kritieke te weinig. Deel in vanuit een bedrijfsimpactanalyse.
DR verwarren met BCP. Elke server herstellen terwijl niemand weet wie een ramp uitroept of hoe medewerkers te bereiken is een hersteld systeem en een mislukt bedrijf.
Met de hand gebouwde herstelomgevingen. Infrastructuur die je niet uit code kunt herbouwen drijft af, en afdrijving wordt midden in de failover ontdekt.
Genegeerde afhankelijkheden. Een app herstellen vóór haar database, identiteitsprovider of DNS produceert slechts een tweede uitval.
Planverval. Een ordner die eenmaal is geschreven en nooit geoefend beschrijft een systeem dat niet meer bestaat.
Blinde vlekken bij leveranciers. Je herstel wordt begrensd door het herstel van je kritieke leveranciers, en concentratierisico is onzichtbaar tot ze samen falen.

Volwassenheidsmodel

Niveau 1, Initiëren: Herstel is ad hoc en reactief. Back-ups draaien misschien maar herstel is ongetest. Er zijn geen afgesproken RTO of RPO, geen bedrijfsimpactanalyse en herstel wordt tijdens het incident geïmproviseerd. Een ernstig dataverlies of ransomwaregebeurtenis zou waarschijnlijk onherstelbaar zijn.
Niveau 2, Ontwikkelen: Basispraktijken bestaan maar zijn inconsistent over teams. Sommige kritieke systemen hebben back-ups volgens de 3-2-1-regel en gedocumenteerde RTO en RPO voor de belangrijkste services, en een basaal DR-plan bestaat met af en toe geteste herstelacties. Dekking is gedeeltelijk, afhankelijkheden zijn niet in kaart gebracht, oefeningen zijn ad hoc en de discipline van het ene team impliceert niet die van het volgende.
Niveau 3, Standaardiseren: Herstelpraktijk is gedocumenteerd en organisatiebreed afgedwongen. Een bedrijfsimpactanalyse drijft getierde RTO en RPO over systemen, herstelstrategieën zijn op die lagen afgestemd, omgevingen zijn infrastructure as code, afhankelijkheden en herstelvolgorde zijn in kaart gebracht en geplande oefeningen (tabletop, game day en failover) lopen volgens een gedefinieerd ritme. Een cyberherstelplan met onveranderlijke, offline kopieën is gedocumenteerd en consistent toegepast in plaats van aan individuele teams overgelaten.
Niveau 4, Beheersen: Herstel wordt gemeten en beheerst tegen uitgangswaarden. Elke oefening legt de werkelijk behaalde RTO en RPO vast en volgt het gat naar het doel, en statistieken zoals herstelsuccespercentage, het deel van kritieke systemen dat het afgelopen jaar end-to-end is hersteld, back-updekking en onveranderlijkheid en bewaakte replicatievertraging als echte RPO worden op dashboards gerapporteerd. Afwijkingen triggeren actie, indeling wordt opnieuw afgeleid uit data over hoe systemen werkelijk worden gebruikt en go/no-go-beslissingen rusten op bewijs in plaats van op de getallen op een dia.
Niveau 5, Orkestreren: Herstel wordt continu verbeterd, over de organisatie geïntegreerd en adaptief. Failover en clean-room cyberherstel worden als routine gerepeteerd, leveranciers- en concentratierisico wordt actief beheerd en continuïteit is geïntegreerd met betrouwbaarheid (hoofdstuk 9.1) en incidentrespons (hoofdstuk 9.3) zodat de organisatie voorspelbaar herstelt van falen die ze nooit zag en haar herstelhouding opnieuw afbakent naarmate het systeemlandschap en het dreigingsbeeld verschuiven.

Ideeën voor discussie

Welk van je kritieke systemen is nooit end-to-end hersteld, en wat zou er nodig zijn om te bewijzen dat het kan?
Als je je primaire cloudregio een hele dag verloor, welke bedrijfsprocessen stoppen, en in welke volgorde zou je systemen terugbrengen?
Hoe veel van je herstel hangt af van leveranciers wier eigen herstel je niet kunt zien of testen?
Waar betaal je voor een herstellaag die de bedrijfsimpactanalyse niet rechtvaardigt, en waar bescherm je te weinig?
Als je back-ups vannacht bereikbaar en versleuteld waren, wat is je werkelijke laatste bekend-schone herstelpunt?
Wat is het eerlijke gat tussen je beloofde RTO en RPO en degene die je laatste oefening werkelijk haalde?

Belangrijkste inzichten

Continuïteit is het doel, herstel is een middel. Bedrijfscontinuïteitsplanning houdt de organisatie draaiend. Disaster recovery herstelt de IT-systemen waarvan ze afhangt.
RTO en RPO drijven alles, en beide komen uit een bedrijfsimpactanalyse, niet uit engineeringgissingen. Deel systemen in in plaats van alles gelijk te beschermen.
Een ongetest back-up is geen back-up. Volg de 3-2-1-regel, houd minstens één onveranderlijke en offline kopie tegen ransomware en test herstel volgens schema.
Stem de DR-strategie af op het getal: back-up-en-herstel, pilot light, warm standby of active-active, gekozen op de RTO en RPO van elk systeem.
Replicatie ruilt consistentie tegen versheid (hoofdstuk 3.3). Je echte RPO is je replicatievertraging, niet je ontwerpdocument.
Herbouw uit code met infrastructure as code (hoofdstuk 8.2), en breng je afhankelijkheden in kaart voordat je ze nodig hebt.
Test met tabletopoefeningen, game days en volledige failoveroefeningen, en meet werkelijke tegenover doel-RTO en -RPO.
Plan cyberherstel apart met clean-roomherstel, en verbind de hele praktijk met betrouwbaarheid (hoofdstuk 9.1), incidentrespons (hoofdstuk 9.3) en compliance (hoofdstuk 4.6).

Referenties en verder lezen

ISO 22301, Security and resilience: Business continuity management systems: Requirements (the international standard for BCP).
National Institute of Standards and Technology, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (RTO, RPO, and recovery strategies for government systems).
National Institute of Standards and Technology, SP 800-61 Rev. 2: Computer Security Incident Handling Guide (incident and cyber-recovery handling).
U.S. Federal Emergency Management Agency, Continuity Guidance Circular and federal COOP guidance (essential functions and continuity of operations).
Federal Financial Institutions Examination Council (FFIEC), Business Continuity Management booklet (regulatory recovery expectations for financial institutions).
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering: How Google Runs Production Systems (reliability and disaster testing).
Kelly Shortridge and Aaron Rinehart, Security Chaos Engineering (deliberately exercising failure and recovery).
Cybersecurity and Infrastructure Security Agency (CISA), #StopRansomware Guide (ransomware prevention and recovery practice).