Een server die uitvalt.
Een ransomware-aanval waardoor bestanden niet meer toegankelijk zijn.
Een storing bij een datacenter.
Beschadigde databases.
Een foutieve software-update.
Brand, waterschade of stroomuitval.
Of een menselijke fout waardoor belangrijke bedrijfsgegevens verdwijnen.
Een ernstig IT-incident kan op veel manieren ontstaan.
De belangrijkste vraag is vervolgens:
Hoe snel kan de organisatie weer verder?
Daar draait disaster recovery IT om.
Met een goede disaster recovery-strategie bereid je vooraf voor hoe belangrijke IT-systemen, applicaties, infrastructuur en gegevens na een ernstige verstoring worden hersteld.
Niet pas nadenken wanneer de systemen al platliggen.
Maar vooraf bepalen:
wat kritiek is;
wat als eerste moet worden hersteld;
welke back-ups beschikbaar zijn;
waar deze worden opgeslagen;
wie verantwoordelijk is;
hoe snel herstel moet plaatsvinden;
en hoe je controleert of het herstel daadwerkelijk werkt.
In deze uitgebreide gids lees je wat disaster recovery IT is, waarom het belangrijk is en hoe organisaties een betrouwbare IT-herstelstrategie kunnen opbouwen.
Wat is disaster recovery IT?
Disaster recovery IT is het geheel aan maatregelen, technologie, procedures en verantwoordelijkheden waarmee een organisatie haar IT-omgeving na een ernstige verstoring kan herstellen.
Het doel is om belangrijke IT-diensten zo snel en gecontroleerd mogelijk weer beschikbaar te krijgen.
Denk bijvoorbeeld aan:
servers;
databases;
bedrijfsapplicaties;
cloudomgevingen;
netwerken;
werkplekken;
bestandsopslag;
identiteitssystemen;
en andere digitale voorzieningen.
Disaster recovery wordt vaak afgekort als DR.
Wat betekent disaster recovery?
Letterlijk betekent disaster recovery:
herstel na een ramp of ernstige verstoring.
Binnen IT hoeft een “disaster” niet letterlijk een natuurramp te zijn.
Ook een ernstige technische of digitale verstoring kan een disaster recovery-scenario veroorzaken.
Bijvoorbeeld:
ransomware;
serveruitval;
opslagproblemen;
databasecorruptie;
cyberaanval;
stroomstoring;
brand;
overstroming;
menselijke fout;
of uitval van een belangrijke leverancier.
Waarom is disaster recovery belangrijk?
Vrijwel iedere moderne organisatie is afhankelijk van IT.
Zonder IT kunnen medewerkers mogelijk niet:
inloggen;
e-mailen;
klanten helpen;
orders verwerken;
factureren;
productie aansturen;
voorraden bekijken;
bestanden openen;
of belangrijke applicaties gebruiken.
Een grote IT-storing kan daardoor direct invloed hebben op de bedrijfsvoering.
IT-uitval kost meer dan alleen IT-tijd
Wanneer een server een paar uur niet beschikbaar is, is niet alleen de IT-afdeling bezig.
Ook andere medewerkers kunnen stilvallen.
Daarnaast kunnen gevolgen ontstaan zoals:
gemiste omzet;
productiviteitsverlies;
klachten;
vertragingen;
contractuele problemen;
reputatieschade;
en extra herstelkosten.
Hoe afhankelijker een organisatie van digitale systemen is, hoe belangrijker disaster recovery wordt.
Disaster recovery is voorbereiding
Het belangrijkste principe is eenvoudig:
Je wilt niet tijdens een calamiteit voor het eerst bedenken hoe je moet herstellen.
Juist onder druk worden fouten gemaakt.
Daarom wordt vooraf vastgelegd:
welke systemen kritiek zijn;
welke afhankelijkheden bestaan;
waar back-ups staan;
hoe herstel werkt;
wie beslissingen neemt;
en welke volgorde wordt gevolgd.
Disaster recovery plan
Deze afspraken worden meestal vastgelegd in een disaster recovery plan, vaak afgekort als DRP.
Een disaster recovery plan beschrijft hoe de IT-omgeving na een ernstige verstoring wordt hersteld.
Het plan kan onder andere bevatten:
kritieke systemen;
contactpersonen;
leveranciers;
back-uplocaties;
herstelprocedures;
technische afhankelijkheden;
prioriteiten;
communicatie;
RTO;
RPO;
en testprocedures.
Een disaster recovery plan is geen document voor de kast
Een veelgemaakte fout is dat een organisatie één keer een plan opstelt en dit daarna nauwelijks meer bekijkt.
Ondertussen verandert de IT-omgeving.
Er komen:
nieuwe applicaties;
andere medewerkers;
nieuwe leveranciers;
cloudsystemen;
andere servers;
nieuwe koppelingen;
en gewijzigde bedrijfsprocessen.
Het disaster recovery plan moet daarom regelmatig worden bijgewerkt.
Disaster recovery versus back-up
Disaster recovery en back-up worden regelmatig door elkaar gehaald.
Ze zijn echter niet hetzelfde.
Een back-up is een kopie van gegevens of systemen.
Disaster recovery gaat over het volledige proces waarmee de bedrijfsomgeving na een incident wordt hersteld.
Een back-up is onderdeel van disaster recovery
Stel dat je iedere nacht een back-up maakt.
Dat is nuttig.
Maar weet je ook:
waar de back-up staat;
of deze intact is;
hoe lang terugzetten duurt;
wie toegang heeft;
welke server eerst moet worden opgebouwd;
welke configuratie nodig is;
en of applicaties daarna daadwerkelijk functioneren?
Dat zijn disaster recovery-vragen.
Een back-up zonder herstelprocedure
Een organisatie kan uitstekende back-ups hebben en toch langdurig uitvallen.
Bijvoorbeeld omdat:
niemand weet hoe ze moeten worden teruggezet;
inloggegevens ontbreken;
de benodigde infrastructuur niet beschikbaar is;
de back-up beschadigd blijkt;
of afhankelijkheden niet zijn meegenomen.
Daarom moeten back-ups en herstelprocedures samen worden ontworpen.
Back-ups testen
Alleen controleren of een back-uptaak “succesvol” is uitgevoerd, is niet voldoende.
De belangrijke vraag is:
Kunnen we er daadwerkelijk mee herstellen?
Test daarom periodiek het terugzetten van gegevens en systemen.
Disaster recovery versus business continuity
Ook business continuity en disaster recovery worden regelmatig als hetzelfde gezien.
Er is echter een verschil.
Business continuity kijkt breder naar hoe de organisatie tijdens en na een verstoring kan blijven functioneren.
Disaster recovery richt zich vooral op herstel van IT en digitale dienstverlening.
Business continuity
Business continuity kan bijvoorbeeld ook gaan over:
alternatieve werkplekken;
telefonische bereikbaarheid;
personeelsplanning;
handmatige processen;
leveranciers;
communicatie;
en alternatieve locaties.
IT is daar één onderdeel van.
Disaster recovery
Disaster recovery richt zich specifieker op:
data;
systemen;
servers;
netwerken;
applicaties;
cloudomgevingen;
en technische dienstverlening.
Beide onderwerpen horen wel sterk bij elkaar.
Disaster recovery versus incident response
Ook incident response is iets anders.
Incident response richt zich vooral op:
detecteren;
analyseren;
beheersen;
en bestrijden
van een incident.
Disaster recovery richt zich daarna sterk op het gecontroleerd herstellen van systemen en dienstverlening.
Voorbeeld bij ransomware
Stel dat ransomware een bedrijfsnetwerk raakt.
Incident response richt zich bijvoorbeeld op:
besmette systemen identificeren;
systemen isoleren;
verdere verspreiding voorkomen;
onderzoek uitvoeren;
en de oorzaak vaststellen.
Disaster recovery richt zich vervolgens op vragen zoals:
Welke systemen herstellen we eerst?
Welke back-up is veilig?
Welke infrastructuur bouwen we opnieuw op?
Hoe herstellen we applicaties?
Wanneer kunnen gebruikers weer werken?
Disaster recovery bij ransomware
Ransomware heeft disaster recovery extra belangrijk gemaakt.
Een aanvaller kan bestanden versleutelen en proberen ook toegankelijke back-ups te beschadigen.
Daarom moeten organisaties nadenken over de scheiding tussen productieomgeving en herstelvoorzieningen.
Back-ups beschermen tegen ransomware
Een back-up die permanent vanuit de productieomgeving bereikbaar is, kan eveneens risico lopen.
Daarom kunnen organisaties gebruikmaken van maatregelen zoals:
offline back-ups;
gescheiden opslag;
immutable opslag;
verschillende accounts;
aparte beveiligingslagen;
en meerdere kopieën.
De precieze inrichting hangt af van de organisatie en gebruikte technologie.
Immutable backup
Immutable betekent dat gegevens gedurende een bepaalde periode niet zomaar gewijzigd of verwijderd kunnen worden.
Dit kan helpen voorkomen dat een aanvaller die toegang tot een omgeving heeft ook direct alle herstelkopieën verwijdert.
Het is echter geen vervanging voor een complete disaster recovery-strategie.
Offline back-up
Een offline back-up is niet voortdurend verbonden met de normale productieomgeving.
Daardoor kan deze beter beschermd zijn tegen bepaalde aanvallen die via het netwerk verspreiden.
Ook hierbij blijft testen belangrijk.
Cloud disaster recovery
Steeds meer organisaties gebruiken cloudomgevingen.
Daardoor verandert disaster recovery.
Je hoeft misschien geen tweede fysiek datacenter meer te bouwen.
Maar je moet nog steeds nadenken over:
regio’s;
beschikbaarheid;
accounts;
configuraties;
back-ups;
cloudopslag;
netwerken;
identiteit;
en applicatieafhankelijkheden.
Cloud betekent niet automatisch disaster recovery
Een veelgemaakte aanname is:
“Onze systemen staan in de cloud, dus disaster recovery is geregeld.”
Dat hoeft niet zo te zijn.
Een cloudprovider kan de infrastructuur beschikbaar houden, terwijl je als organisatie zelf verantwoordelijk blijft voor bepaalde:
data;
configuraties;
gebruikers;
back-ups;
applicaties;
en herstelprocedures.
Controleer daarom altijd het verantwoordelijkheidsmodel van de gebruikte clouddiensten.
SaaS en disaster recovery
Ook bij Software as a Service moet je nadenken over herstel.
Denk bijvoorbeeld aan:
Microsoft 365;
CRM;
boekhoudsoftware;
HR-systemen;
projectsoftware;
en andere online diensten.
Vraag jezelf af:
Wat gebeurt er als gegevens worden verwijderd?
Hoe lang worden gegevens bewaard?
Welke herstelmogelijkheden biedt de leverancier?
Hebben we aanvullende back-ups nodig?
Hoe krijgen we gegevens terug?
On-premises disaster recovery
Heeft een organisatie eigen servers?
Dan kunnen aanvullende herstelvraagstukken spelen.
Bijvoorbeeld:
hardware;
virtualisatie;
storage;
netwerkapparatuur;
firewalls;
stroomvoorziening;
en fysieke locatie.
Valt de volledige serverruimte uit, dan moet mogelijk elders worden hersteld.
Hybride IT-omgeving
Veel organisaties hebben tegenwoordig een combinatie.
Bijvoorbeeld:
lokale servers;
Microsoft 365;
cloudapplicaties;
SaaS;
Azure of AWS;
lokale werkplekken;
en externe datacenters.
Disaster recovery moet al deze onderdelen meenemen.
Inventariseer eerst de IT-omgeving
Je kunt geen goed herstelplan maken wanneer je niet weet wat er aanwezig is.
Begin daarom met een inventarisatie.
Denk aan:
servers;
virtuele machines;
databases;
applicaties;
cloudservices;
netwerkcomponenten;
back-upsystemen;
werkplekken;
identiteitsdiensten;
en externe leveranciers.
Breng afhankelijkheden in kaart
Dit is minstens zo belangrijk.
Een applicatie werkt misschien alleen wanneer verschillende andere systemen beschikbaar zijn.
Bijvoorbeeld:
database;
DNS;
internet;
identity provider;
fileserver;
API;
licentieserver;
en netwerkverbinding.
Herstel je alleen de applicatieserver?
Dan werkt de applicatie mogelijk nog steeds niet.
Welke systemen zijn kritiek?
Niet ieder systeem hoeft binnen vijf minuten terug te zijn.
Maak daarom onderscheid tussen:
bedrijfskritieke systemen;
belangrijke systemen;
en systemen die tijdelijk gemist kunnen worden.
Dit helpt prioriteiten te stellen.
Business Impact Analysis
Een Business Impact Analysis, vaak afgekort als BIA, helpt bepalen welke processen en systemen het belangrijkst zijn.
Je onderzoekt bijvoorbeeld:
wat gebeurt er als een systeem één uur uitvalt?
Wat gebeurt er na vier uur?
Na één dag?
Na drie dagen?
Welke klanten worden geraakt?
Welke medewerkers kunnen niet werken?
Welke financiële gevolgen ontstaan?
Daarmee kun je herstelprioriteiten onderbouwen.
Kritieke bedrijfsprocessen
Begin niet alleen vanuit technologie.
Vraag ook aan de organisatie:
Welke processen moeten absoluut blijven functioneren?
Bijvoorbeeld:
orderverwerking;
productie;
klantenservice;
betalingen;
logistiek;
planning;
of zorgverlening.
Koppel vervolgens de benodigde IT-systemen aan deze processen.
RTO: Recovery Time Objective
Een belangrijke term binnen disaster recovery is RTO.
RTO staat voor Recovery Time Objective.
Dit geeft aan binnen welke beoogde tijd een systeem of dienst na een verstoring hersteld moet worden.
Bijvoorbeeld:
een kritieke applicatie moet binnen vier uur weer beschikbaar zijn.
Dan is vier uur de RTO.
Niet ieder systeem dezelfde RTO geven
Een zeer korte RTO kan technisch ingewikkeld en kostbaar zijn.
Daarom is het niet logisch om ieder systeem dezelfde hersteltijd te geven.
Een bedrijfskritisch systeem kan bijvoorbeeld een veel kortere RTO krijgen dan een intern archiefsysteem.
RPO: Recovery Point Objective
Een tweede belangrijke term is RPO.
RPO staat voor Recovery Point Objective.
Dit gaat over hoeveel gegevensverlies acceptabel is, uitgedrukt in tijd.
Stel dat iedere vier uur een back-up wordt gemaakt.
Bij een storing kan mogelijk een aantal uren aan nieuwe gegevens verloren gaan.
RTO versus RPO
Het verschil kun je eenvoudig onthouden:
RTO = hoe snel moet het systeem weer werken?
RPO = hoeveel recente data mag maximaal verloren gaan?
Beide hebben grote invloed op de technische oplossing.
RPO van 24 uur
Wanneer maximaal één dag gegevensverlies acceptabel is, kan een dagelijkse back-up in sommige situaties voldoende zijn.
Maar alleen wanneer deze daadwerkelijk betrouwbaar en herstelbaar is.
RPO van één uur
Mag maximaal één uur aan gegevens verloren gaan?
Dan moeten gegevens veel vaker worden beschermd.
Dat vraagt andere technieken en mogelijk hogere kosten.
Bijna geen gegevensverlies
Voor zeer kritieke systemen kan de organisatie een zeer lage RPO verlangen.
Dan kan bijvoorbeeld replicatie of continue gegevensbescherming nodig zijn.
Maar hoe strenger de eisen, hoe complexer en duurder de infrastructuur meestal wordt.
Herstelprioriteiten bepalen
Na het bepalen van RTO en RPO kun je systemen indelen.
Bijvoorbeeld:
Prioriteit 1: direct noodzakelijk.
Prioriteit 2: binnen enkele uren nodig.
Prioriteit 3: binnen een werkdag nodig.
Prioriteit 4: mag later worden hersteld.
Maak deze classificatie passend bij de eigen organisatie.
Disaster recovery architectuur
Op basis van de eisen kun je een technische herstelarchitectuur ontwerpen.
Mogelijkheden zijn bijvoorbeeld:
back-up en restore;
replicatie;
stand-by systemen;
alternatief datacenter;
cloud recovery;
of combinaties hiervan.
Backup en restore
Dit is een relatief eenvoudige herstelstrategie.
Bij een incident worden:
nieuwe systemen opgebouwd;
gegevens teruggezet;
configuraties hersteld;
en applicaties opnieuw beschikbaar gemaakt.
Dit kan geschikt zijn wanneer langere hersteltijden acceptabel zijn.
Replicatie
Bij replicatie worden gegevens of systemen naar een andere omgeving gekopieerd.
Hierdoor kan sneller worden hersteld.
Maar replicatie is niet automatisch hetzelfde als back-up.
Wanneer corrupte of ongewenste wijzigingen worden gerepliceerd, kunnen deze ook in de tweede omgeving terechtkomen.
Stand-by omgeving
Een organisatie kan een tweede omgeving beschikbaar hebben die gedeeltelijk of volledig voorbereid is.
Bij uitval wordt deze geactiveerd.
Hoe meer deze omgeving al actief en bijgewerkt is, hoe sneller failover mogelijk kan zijn.
Daar staan meestal hogere kosten tegenover.
Cold site
Een cold site is een alternatieve locatie waar nog relatief veel moet worden opgebouwd voordat systemen kunnen draaien.
Dit is goedkoper, maar herstel duurt langer.
Warm site
Een warm site is verder voorbereid.
Een gedeelte van infrastructuur en configuratie is al beschikbaar.
Daardoor kan herstel sneller verlopen.
Hot site
Een hot site is sterk voorbereid op snelle overname.
Systemen en data kunnen grotendeels gereedstaan.
Dit kan zeer snelle recovery mogelijk maken, maar vraagt aanzienlijk meer investering en beheer.
Disaster Recovery as a Service
Organisaties kunnen ook kiezen voor Disaster Recovery as a Service, vaak afgekort als DRaaS.
Een externe dienstverlener helpt dan met een technische herstelomgeving.
Bijvoorbeeld via cloudinfrastructuur.
Voordelen van DRaaS
Mogelijke voordelen zijn:
minder eigen tweede infrastructuur;
schaalbaarheid;
automatisering;
specialistische ondersteuning;
en mogelijk sneller herstel.
Maar ook hier moet duidelijk zijn:
wat wordt beschermd;
hoe herstel werkt;
wie verantwoordelijk is;
en welke RTO/RPO daadwerkelijk haalbaar zijn.
Disaster recovery datacenter
Organisaties met eigen datacenterinfrastructuur kunnen kiezen voor geografisch gescheiden locaties.
Dat voorkomt dat één lokaal incident beide omgevingen tegelijk raakt.
Geografische spreiding
Wanneer productie en herstelomgeving zich in hetzelfde gebouw bevinden, kunnen beide worden geraakt door:
brand;
water;
stroomuitval;
diefstal;
of andere fysieke incidenten.
Geografische spreiding verkleint dat risico.
Netwerkverbindingen
Een tweede datacenter helpt weinig wanneer alle verbindingen via hetzelfde kwetsbare punt lopen.
Bekijk daarom ook:
internetverbindingen;
WAN;
VPN;
firewalls;
DNS;
en telecom.
Identiteit als kritieke afhankelijkheid
Moderne organisaties zijn sterk afhankelijk van identity-systemen.
Wanneer gebruikers zich niet kunnen aanmelden, kunnen herstelde applicaties alsnog onbruikbaar zijn.
Neem daarom ook authenticatie en autorisatie mee in disaster recovery.
Active Directory
Bij organisaties met Active Directory kan herstel daarvan cruciaal zijn.
Denk aan:
domeincontrollers;
DNS;
gebruikers;
groepen;
rechten;
en gekoppelde applicaties.
Documenteer hoe herstel werkt.
Microsoft 365
Microsoft 365 kan eveneens onderdeel zijn van de continuïteitsstrategie.
Denk aan:
e-mail;
Teams;
SharePoint;
OneDrive;
en identiteiten.
Onderzoek welke herstelmogelijkheden standaard beschikbaar zijn en welke aanvullende maatregelen de organisatie nodig vindt.
Netwerkherstel
Zonder netwerk kunnen systemen onbereikbaar blijven.
Disaster recovery moet daarom ook rekening houden met:
switches;
routers;
firewalls;
internet;
VPN;
wifi;
DNS;
DHCP;
en configuratieback-ups.
Firewallconfiguratie
Een firewall opnieuw opbouwen zonder recente configuratieback-up kan veel tijd kosten.
Maak daarom ook back-ups van infrastructuurconfiguraties.
Hardware
Bij fysieke infrastructuur moet je weten hoe vervangende hardware beschikbaar komt.
Vraag bijvoorbeeld:
Hebben we reservehardware?
Hoe snel kan een leverancier leveren?
Kunnen virtuele machines op andere hardware draaien?
Zijn onderdelen nog verkrijgbaar?
Verouderde systemen
Legacy-systemen kunnen disaster recovery extra lastig maken.
Misschien draait een kritieke applicatie op:
oude hardware;
een oud besturingssysteem;
verouderde database;
of niet meer ondersteunde software.
Test daarom of deze systemen daadwerkelijk opnieuw kunnen worden opgebouwd.
Softwarelicenties
Ook licenties kunnen herstel blokkeren.
Misschien moet een applicatie na herstel opnieuw worden geactiveerd.
Bewaar daarom informatie over:
licentiecodes;
contracten;
installatiemedia;
accounts;
en leveranciers.
Documentatie
Goede documentatie is essentieel.
Denk aan:
netwerkdiagrammen;
serveroverzicht;
IP-adressen;
applicatiearchitectuur;
contactgegevens;
accounts;
herstelstappen;
en leveranciers.
Bewaar documentatie niet alleen in het systeem dat kan uitvallen
Een klassiek probleem:
het disaster recovery plan staat op de fileserver.
De fileserver valt uit.
Niemand kan het disaster recovery plan openen.
Zorg daarom voor een veilig beschikbare kopie buiten de primaire omgeving.
Contactgegevens
Tijdens een calamiteit moet snel duidelijk zijn wie gebeld moet worden.
Leg daarom contactgegevens vast van:
interne IT;
management;
IT-leverancier;
cloudprovider;
internetprovider;
softwareleveranciers;
securityspecialisten;
en andere relevante partijen.
Rollen en verantwoordelijkheden
Iedereen moet weten wie wat doet.
Bijvoorbeeld:
wie coördineert het incident?
Wie beslist over failover?
Wie herstelt servers?
Wie communiceert met medewerkers?
Wie neemt contact op met leveranciers?
Wie informeert klanten?
Disaster recovery team
Grotere organisaties kunnen een formeel disaster recovery-team samenstellen.
Kleinere bedrijven kunnen dezelfde rollen verdelen over enkele medewerkers en externe IT-partners.
Het belangrijkste is dat verantwoordelijkheden vooraf duidelijk zijn.
Escalatieprocedure
Niet iedere storing is een disaster.
Definieer daarom wanneer het disaster recovery plan wordt geactiveerd.
Bijvoorbeeld op basis van:
duur van de storing;
aantal getroffen systemen;
impact;
veiligheidsrisico;
of verwachte hersteltijd.
Communicatie tijdens een incident
Technisch herstel is maar één gedeelte.
Medewerkers willen weten:
wat er gebeurt;
wat ze wel en niet mogen doen;
en wanneer systemen terugkomen.
Klanten kunnen eveneens informatie nodig hebben.
Neem communicatie daarom mee in het plan.
Alternatieve communicatie
Wat gebeurt er wanneer e-mail zelf is uitgevallen?
Zorg voor alternatieve mogelijkheden.
Bijvoorbeeld:
telefoon;
sms;
externe communicatietool;
of vooraf afgesproken contactstructuur.
Disaster recovery en cybersecurity
Disaster recovery en cybersecurity horen sterk bij elkaar.
Preventieve beveiliging probeert incidenten te voorkomen.
Disaster recovery accepteert dat volledige preventie onmogelijk is en bereidt herstel voor wanneer er toch iets misgaat.
Zero Trust en disaster recovery
Ook sterk beveiligde omgevingen kunnen uitvallen.
Een beveiligingsmodel vervangt daarom geen herstelstrategie.
Andersom mag disaster recovery ook geen reden zijn om beveiliging minder serieus te nemen.
Beide vullen elkaar aan.
Disaster recovery na cyberaanval
Bij herstel na een cyberaanval moet je voorzichtig zijn.
Je wilt niet simpelweg een besmette omgeving opnieuw activeren.
Onderzoek eerst:
wat er is gebeurd;
welke systemen geraakt zijn;
hoe de aanvaller binnenkwam;
welke accounts mogelijk zijn gecompromitteerd;
en of de hersteldata betrouwbaar zijn.
Clean recovery
Bij ernstige securityincidenten kan het nodig zijn systemen opnieuw op te bouwen vanuit een bekende betrouwbare toestand.
Daarbij worden bijvoorbeeld:
schone images;
veilige configuraties;
gecontroleerde back-ups;
en nieuwe credentials
gebruikt.
Wachtwoorden wijzigen
Wanneer accounts mogelijk zijn gecompromitteerd, kan credential reset onderdeel zijn van recovery.
Denk niet alleen aan gebruikersaccounts.
Ook:
serviceaccounts;
beheeraccounts;
API-sleutels;
certificaten;
en andere secrets
kunnen aandacht nodig hebben.
Disaster recovery testen
Een plan dat nooit is getest geeft weinig zekerheid.
Test daarom regelmatig.
Restore-test
De eenvoudigste test is een restore.
Neem een back-up en probeer:
een bestand;
database;
server;
of applicatie
terug te zetten.
Controleer vervolgens of deze daadwerkelijk functioneert.
Tabletop exercise
Bij een tabletop-oefening doorloopt het team een fictief incident.
Bijvoorbeeld:
“Het datacenter is niet bereikbaar. Wat doen we?”
Iedere deelnemer bespreekt welke stappen worden uitgevoerd.
Dit is een relatief eenvoudige manier om hiaten in het plan te ontdekken.
Technische recovery-test
Een uitgebreidere test herstelt daadwerkelijk systemen in een alternatieve omgeving.
Daarmee ontdek je praktische problemen die op papier niet zichtbaar zijn.
Volledige disaster recovery test
Bij een uitgebreide oefening kan een groot gedeelte van de IT-omgeving worden hersteld.
Dit vraagt voorbereiding, maar geeft veel inzicht in de echte hersteltijd.
Meet de werkelijke RTO
Staat in het plan dat een applicatie binnen twee uur kan worden hersteld?
Test dat.
Misschien blijkt in de praktijk dat het vijf uur duurt.
Dan moet je:
de procedure verbeteren;
de infrastructuur aanpassen;
of de RTO realistischer maken.
Test de RPO
Controleer eveneens hoeveel gegevens daadwerkelijk verloren zouden gaan.
Komt dit overeen met de afgesproken RPO?
Zo niet, dan moet de back-up- of replicatiestrategie worden aangepast.
Test afhankelijkheden
Een server succesvol herstellen betekent nog niet dat de bedrijfsapplicatie werkt.
Test daarom de volledige keten.
Bijvoorbeeld:
login;
database;
applicatie;
netwerk;
integraties;
en eindgebruikersfunctionaliteit.
Test zonder vaste beheerder
Een interessante test is om te kijken of herstel mogelijk is wanneer de belangrijkste systeembeheerder niet beschikbaar is.
Een disaster kan immers plaatsvinden tijdens:
vakantie;
ziekte;
nacht;
of weekend.
Documentatie moet voldoende duidelijk zijn voor andere bevoegde medewerkers.
Hoe vaak disaster recovery testen?
Er bestaat geen universele frequentie voor iedere organisatie.
De juiste frequentie hangt onder andere af van:
risico;
complexiteit;
veranderingen;
kritieke processen;
en regelgeving.
Belangrijk is vooral dat testen structureel gebeurt en opnieuw plaatsvindt na grote wijzigingen.
Test na veranderingen
Een nieuwe server?
Nieuwe cloudomgeving?
Grote applicatiemigratie?
Nieuwe firewall?
Andere back-upsoftware?
Controleer dan of het disaster recovery plan nog klopt.
Disaster recovery voor kleine bedrijven
Ook kleine bedrijven hebben disaster recovery nodig.
Het plan hoeft alleen niet dezelfde omvang te hebben als bij een multinational.
Een klein bedrijf kan beginnen met:
inventarisatie;
goede back-ups;
duidelijke herstelprioriteiten;
contactgegevens;
documentatie;
en periodieke restore-tests.
MKB en disaster recovery
MKB-bedrijven zijn vaak sterk afhankelijk van enkele systemen.
Bijvoorbeeld:
boekhouding;
CRM;
Microsoft 365;
ERP;
bestandsopslag;
en brancheapplicaties.
Valt één daarvan langdurig uit, dan kan een groot gedeelte van de organisatie stilvallen.
Geen eigen IT-afdeling
Heeft het bedrijf geen interne IT-afdeling?
Leg dan duidelijke afspraken vast met de IT-dienstverlener.
Vraag:
Wie reageert bij een calamiteit?
Binnen welke tijd?
Wie heeft toegang tot back-ups?
Wie voert herstel uit?
Welke kosten kunnen ontstaan?
Managed disaster recovery
Een IT-partner kan een gedeelte van disaster recovery beheren.
Bijvoorbeeld:
back-ups;
monitoring;
cloudreplicatie;
herstelomgeving;
tests;
en documentatie.
De organisatie blijft echter verantwoordelijk voor het bepalen van bedrijfsprioriteiten.
Een IT-leverancier kan niet zelfstandig bepalen hoeveel downtime voor jouw bedrijf acceptabel is.
Disaster recovery voor grote organisaties
Grotere organisaties hebben vaak complexere omgevingen.
Denk aan:
meerdere locaties;
honderden applicaties;
internationale infrastructuur;
hybride cloud;
datacenters;
OT;
en uitgebreide leveranciersketens.
Daarom zijn formele governance en duidelijke classificatie belangrijk.
Disaster recovery voor webshops
Een webshop kan sterk afhankelijk zijn van:
website;
database;
betalingen;
voorraad;
ERP;
orderverwerking;
en logistieke koppelingen.
Bij uitval kan omzet direct stoppen.
Bepaal daarom welke onderdelen als eerste hersteld moeten worden.
Disaster recovery voor productiebedrijven
Productieomgevingen kunnen naast IT ook OT gebruiken.
Denk aan:
machines;
PLC’s;
SCADA;
productiesystemen;
en industriële netwerken.
Herstel van OT vraagt vaak andere procedures dan traditionele kantoor-IT.
OT disaster recovery
Bij Operational Technology kunnen beschikbaarheid en veiligheid extra belangrijk zijn.
Maak back-ups van relevante:
configuraties;
programmatuur;
instellingen;
en systemen.
Test ook of deze daadwerkelijk op vervangende apparatuur kunnen worden teruggezet.
Disaster recovery voor zorg
Zorgorganisaties kunnen sterk afhankelijk zijn van digitale dossiers, planning, communicatie en andere kritieke systemen.
Daarbij kunnen naast continuïteit ook privacy en regelgeving een belangrijke rol spelen.
Herstelprioriteiten moeten daarom zorgvuldig worden bepaald.
Disaster recovery voor financiële organisaties
Financiële organisaties kunnen zeer lage toleranties hebben voor:
downtime;
dataverlies;
en inconsistente transacties.
Hierdoor kunnen strengere RTO- en RPO-eisen nodig zijn.
Disaster recovery voor gemeenten en overheid
Ook overheidsorganisaties zijn afhankelijk van digitale dienstverlening.
Een herstelstrategie moet rekening houden met:
kritieke processen;
dienstverlening;
data;
identiteit;
en communicatie.
Disaster recovery voor SaaS-bedrijven
Voor een SaaS-aanbieder is beschikbaarheid onderdeel van het product.
Klanten verwachten toegang tot de dienst.
Disaster recovery moet daarom vanaf de architectuur worden meegenomen.
Disaster recovery en leveranciers
Een organisatie is vaak afhankelijk van externe partijen.
Bijvoorbeeld:
cloudprovider;
datacenter;
internetprovider;
softwareleverancier;
IT-beheerder;
en telecomprovider.
Neem deze afhankelijkheden mee in het plan.
SLA controleren
Bekijk Service Level Agreements.
Controleer bijvoorbeeld:
beschikbaarheid;
reactietijden;
hersteltijden;
support;
en verantwoordelijkheden.
Een SLA is echter niet automatisch hetzelfde als jouw disaster recovery-plan.
Leveranciersrisico
Wat gebeurt er wanneer juist de leverancier uitvalt?
Heb je:
alternatieve contactgegevens;
exportmogelijkheden;
lokale kopieën;
andere leveranciers;
of een exitstrategie?
Voor kritieke diensten is dit belangrijk.
Single point of failure
Zoek naar onderdelen waarvan het uitvallen de hele omgeving raakt.
Dit worden single points of failure genoemd.
Bijvoorbeeld:
één internetverbinding;
één firewall;
één fysieke server;
één storageomgeving;
of één beheeraccount.
Niet ieder risico hoeft volledig dubbel uitgevoerd te worden, maar het moet wel bewust worden beoordeeld.
Redundantie
Redundantie kan beschikbaarheid verhogen.
Bijvoorbeeld door:
dubbele voedingen;
meerdere netwerkverbindingen;
clusters;
replicatie;
of meerdere locaties.
Maar redundantie vervangt geen back-up.
High availability versus disaster recovery
High availability, vaak HA genoemd, is gericht op het beperken van uitval bij technische problemen.
Disaster recovery gaat verder en houdt rekening met grotere verstoringen.
Een cluster kan bijvoorbeeld beschermen tegen het uitvallen van één server.
Maar wanneer het hele datacenter verloren gaat, is een andere herstelstrategie nodig.
Failover
Failover betekent dat dienstverlening wordt overgenomen door een andere omgeving of component.
Dit kan automatisch of handmatig gebeuren.
Automatische failover kan downtime beperken, maar vraagt zorgvuldige inrichting en testen.
Failback
Na herstel moet de organisatie mogelijk terug naar de primaire omgeving.
Dit heet failback.
Ook hiervoor moet een procedure bestaan.
Anders kan het terugschakelen zelf een nieuw incident veroorzaken.
Disaster recovery kosten
De kosten van disaster recovery hangen sterk af van de gewenste zekerheid en snelheid.
Een eenvoudige back-upstrategie kost minder dan een volledig gerepliceerde tweede omgeving.
Belangrijke kostenfactoren zijn:
opslag;
cloudresources;
licenties;
hardware;
netwerk;
beheer;
testen;
en externe dienstverlening.
Sneller herstel kost vaak meer
Een systeem dat binnen twee dagen mag worden hersteld heeft andere eisen dan een systeem dat binnen enkele minuten beschikbaar moet zijn.
Hoe lager RTO en RPO worden, hoe meer technologie en redundantie meestal nodig zijn.
Kosten afzetten tegen downtime
De juiste vraag is daarom niet:
“Wat kost disaster recovery?”
Maar ook:
“Wat kost het wanneer dit systeem één dag niet beschikbaar is?”
Wanneer één dag uitval enorme schade veroorzaakt, kan een betere herstelvoorziening economisch logisch zijn.
Risicogebaseerde aanpak
Niet ieder systeem hoeft maximale bescherming te krijgen.
Gebruik een risicogebaseerde aanpak.
Investeer het meest in systemen waarbij uitval de grootste impact heeft.
Disaster recovery audit
Een periodieke audit kan controleren of de herstelvoorzieningen nog aansluiten op de werkelijkheid.
Bekijk bijvoorbeeld:
back-ups;
restore-tests;
documentatie;
RTO;
RPO;
contactpersonen;
architectuur;
en testresultaten.
Veelgemaakte fouten bij disaster recovery IT
Alleen back-ups maken
Back-ups zonder getest herstelproces geven onvoldoende zekerheid.
Back-ups nooit terugzetten
Je weet pas of herstel werkt wanneer je het test.
Alle back-ups online bereikbaar houden
Hierdoor kunnen bepaalde cyberincidenten ook herstelkopieën raken.
Geen prioriteiten bepalen
Wanneer alles prioriteit één is, is uiteindelijk niets prioriteit één.
RTO en RPO niet vastleggen
Zonder doelen kun je moeilijk bepalen of de technische oplossing voldoende is.
Afhankelijkheden vergeten
Een applicatie kan afhankelijk zijn van tientallen andere componenten.
Cloud als automatische oplossing zien
Ook cloudsystemen vragen om herstelplanning.
Documentatie verouderd laten raken
Een plan voor een IT-omgeving van drie jaar geleden kan tijdens een incident onbruikbaar zijn.
Eén persoon alle kennis laten hebben
Die medewerker kan tijdens een calamiteit niet beschikbaar zijn.
Alleen techniek testen
Ook communicatie, besluitvorming en verantwoordelijkheden moeten worden geoefend.
Geen failback testen
Teruggaan naar de normale omgeving is eveneens onderdeel van recovery.
Leveranciers vergeten
Externe diensten kunnen cruciale afhankelijkheden vormen.
Disaster recovery IT opzetten: stappenplan
Stap 1: inventariseer bedrijfsprocessen
Welke processen zijn essentieel?
Stap 2: inventariseer IT-systemen
Welke technologie ondersteunt deze processen?
Stap 3: breng afhankelijkheden in kaart
Welke systemen hebben elkaar nodig?
Stap 4: voer een impactanalyse uit
Wat gebeurt er bij verschillende duur van uitval?
Stap 5: bepaal prioriteiten
Welke systemen moeten als eerste terug?
Stap 6: stel RTO vast
Hoe snel moet ieder systeem worden hersteld?
Stap 7: stel RPO vast
Hoeveel gegevensverlies is acceptabel?
Stap 8: ontwerp de back-upstrategie
Welke gegevens en systemen worden beschermd?
Stap 9: bescherm de back-ups
Voorkom dat één incident productie én alle herstelkopieën raakt.
Stap 10: ontwerp de recovery-omgeving
Waar worden systemen hersteld?
Stap 11: documenteer procedures
Leg concrete herstelstappen vast.
Stap 12: verdeel verantwoordelijkheden
Wie doet wat?
Stap 13: leg leverancierscontacten vast
Zorg dat belangrijke partijen snel bereikbaar zijn.
Stap 14: maak communicatieprocedures
Hoe informeer je medewerkers en andere betrokkenen?
Stap 15: voer restore-tests uit
Controleer of data werkelijk teruggezet kan worden.
Stap 16: test complete applicaties
Niet alleen bestanden, maar de volledige dienstverlening.
Stap 17: oefen calamiteiten
Voer scenario’s en technische tests uit.
Stap 18: meet de resultaten
Zijn RTO en RPO gehaald?
Stap 19: verbeter tekortkomingen
Pas techniek en procedures aan.
Stap 20: houd het plan actueel
Werk disaster recovery bij wanneer de IT-omgeving verandert.
Checklist disaster recovery IT
Gebruik onderstaande checklist om te beoordelen hoe voorbereid de organisatie is.
Bedrijfsimpact
Zijn kritieke processen bekend?
Is duidelijk wat downtime kost?
Zijn herstelprioriteiten vastgesteld?
Systemen
Zijn alle belangrijke servers bekend?
Zijn applicaties geïnventariseerd?
Zijn databases meegenomen?
Zijn cloudservices opgenomen?
Zijn netwerkcomponenten opgenomen?
Afhankelijkheden
Zijn technische afhankelijkheden gedocumenteerd?
Zijn externe leveranciers bekend?
Is identiteit meegenomen?
RTO en RPO
Heeft ieder kritisch systeem een RTO?
Heeft ieder kritisch systeem een RPO?
Zijn deze eisen technisch haalbaar?
Back-ups
Worden kritieke gegevens geback-upt?
Zijn er meerdere herstelkopieën?
Zijn back-ups voldoende gescheiden?
Worden back-ups beschermd?
Recovery
Is bekend waar systemen worden hersteld?
Zijn installatiebestanden beschikbaar?
Zijn configuraties beschikbaar?
Zijn licenties beschikbaar?
Documentatie
Bestaat een disaster recovery plan?
Is dit actueel?
Is een kopie buiten de primaire omgeving beschikbaar?
Mensen
Zijn verantwoordelijkheden verdeeld?
Zijn contactpersonen actueel?
Is vervanging geregeld wanneer iemand afwezig is?
Testen
Worden restore-tests uitgevoerd?
Worden scenario’s geoefend?
Wordt complete recovery getest?
Worden resultaten vastgelegd?
Verbetering
Worden problemen uit tests opgelost?
Wordt het plan aangepast na grote IT-wijzigingen?
Wanneer op meerdere onderdelen geen duidelijk antwoord bestaat, is er waarschijnlijk ruimte om disaster recovery verder te professionaliseren.
Veelgestelde vragen over disaster recovery IT
Wat is disaster recovery IT?
Disaster recovery IT omvat de technische en organisatorische maatregelen waarmee IT-systemen en gegevens na een ernstige verstoring worden hersteld.
Wat is een disaster recovery plan?
Een disaster recovery plan beschrijft welke systemen moeten worden hersteld, in welke volgorde, door wie en met welke procedures en middelen.
Is een back-up hetzelfde als disaster recovery?
Nee. Een back-up is een kopie van gegevens. Disaster recovery omvat het volledige herstelproces van systemen, infrastructuur, applicaties en data.
Wat is RTO?
RTO staat voor Recovery Time Objective en geeft aan binnen welke beoogde tijd een systeem na een verstoring hersteld moet worden.
Wat is RPO?
RPO staat voor Recovery Point Objective en geeft aan hoeveel gegevensverlies, uitgedrukt in tijd, acceptabel is.
Wat is het verschil tussen RTO en RPO?
RTO gaat over hersteltijd. RPO gaat over acceptabel gegevensverlies.
Is disaster recovery alleen voor grote bedrijven?
Nee. Ook kleine bedrijven zijn afhankelijk van IT en kunnen grote problemen krijgen wanneer kritieke systemen langdurig niet beschikbaar zijn.
Heb ik disaster recovery nodig als alles in de cloud staat?
Ook cloudomgevingen moeten worden meegenomen in herstelplanning. Welke verantwoordelijkheden bij de organisatie en welke bij de leverancier liggen, verschilt per dienst.
Is Microsoft 365 automatisch voldoende beschermd?
Microsoft 365 beschikt over verschillende beschikbaarheids- en herstelvoorzieningen, maar een organisatie moet zelf bepalen of deze aansluiten op haar eisen rond retentie, herstel en continuïteit.
Hoe bescherm ik back-ups tegen ransomware?
Mogelijke maatregelen zijn gescheiden, offline of immutable back-ups, aparte toegangsrechten en regelmatige hersteltests.
Hoe vaak moet ik disaster recovery testen?
Dat hangt af van risico, complexiteit en veranderingen binnen de organisatie. Test in ieder geval structureel en opnieuw na belangrijke wijzigingen.
Wat is een disaster recovery test?
Tijdens een disaster recovery test wordt gecontroleerd of systemen, applicaties en gegevens volgens het plan kunnen worden hersteld.
Wat is DRaaS?
DRaaS staat voor Disaster Recovery as a Service. Hierbij wordt een externe dienst gebruikt om herstelvoorzieningen te leveren of ondersteunen.
Wat is een hot site?
Een hot site is een sterk voorbereide alternatieve omgeving die snel kan worden ingezet wanneer de primaire omgeving uitvalt.
Wat is een cold site?
Een cold site is een alternatieve locatie waar nog relatief veel infrastructuur en systemen moeten worden opgebouwd voordat herstel mogelijk is.
Wat is een warm site?
Een warm site bevindt zich qua voorbereiding tussen een cold en hot site.
Wat is failover?
Failover is het overschakelen van dienstverlening naar een alternatieve omgeving of component.
Wat is failback?
Failback is het gecontroleerd terugschakelen naar de normale of primaire omgeving nadat deze weer beschikbaar is.
Wat is het verschil tussen disaster recovery en business continuity?
Disaster recovery richt zich vooral op herstel van IT-systemen en data. Business continuity kijkt breder naar het voortzetten van de bedrijfsactiviteiten tijdens een verstoring.
Wat is het verschil tussen disaster recovery en incident response?
Incident response richt zich op het detecteren, analyseren en beheersen van een incident. Disaster recovery richt zich vooral op het herstel van getroffen dienstverlening.
Waarom moeten back-ups getest worden?
Omdat het bestaan van een back-up niet garandeert dat deze volledig, bruikbaar en binnen de gewenste tijd kan worden teruggezet.
Conclusie: disaster recovery IT bepaalt hoe voorbereid je bent wanneer IT echt uitvalt
Organisaties investeren veel tijd en geld in het voorkomen van IT-problemen.
Dat is belangrijk.
Maar geen enkele IT-omgeving is volledig immuun voor:
technische storingen;
menselijke fouten;
cyberaanvallen;
ransomware;
hardwareproblemen;
softwarefouten;
stroomuitval;
of fysieke calamiteiten.
Daarom is disaster recovery IT noodzakelijk.
Het uitgangspunt is eenvoudig:
Als een belangrijk IT-systeem morgen volledig uitvalt, weten we dan precies hoe we verder moeten?
Een volwassen disaster recovery-strategie geeft daar een concreet antwoord op.
Je weet:
welke systemen kritiek zijn;
hoe snel ze terug moeten zijn;
hoeveel gegevensverlies acceptabel is;
waar hersteldata staat;
welke afhankelijkheden bestaan;
wie verantwoordelijk is;
en welke stappen uitgevoerd moeten worden.
Back-ups vormen daarvan een belangrijk onderdeel.
Maar alleen back-ups maken is niet voldoende.
Je moet ook weten of deze back-ups:
bruikbaar;
bereikbaar;
veilig;
en daadwerkelijk herstelbaar
zijn.
Daarom zijn testen en oefenen zo belangrijk.
Voer restore-tests uit.
Oefen verschillende scenario’s.
Meet de werkelijke hersteltijd.
Controleer of de RTO en RPO gehaald worden.
En pas het plan aan wanneer de IT-omgeving verandert.
Voor kleine organisaties kan disaster recovery relatief eenvoudig beginnen.
Voor grote organisaties kan het uitgroeien tot een uitgebreide combinatie van:
replicatie;
meerdere locaties;
cloud recovery;
automatische failover;
DRaaS;
en gespecialiseerde recoveryteams.
De omvang verschilt.
Het principe blijft hetzelfde.
Disaster recovery IT draait niet om de vraag óf er ooit iets misgaat, maar om de mate waarin je organisatie voorbereid is om systemen, data en bedrijfsactiviteiten gecontroleerd te herstellen wanneer een ernstige IT-verstoring daadwerkelijk plaatsvindt.