Het ergste wat een bedrijf jaren geleden kon overkomen was dat er brand uit zou breken waardoor alle ‘assets’ van het bedrijf verloren zouden gaan. Of, afhankelijk van de ligging, een overstroming of zelfs een aardbeving. Van alle disasters die een bedrijf tegenwoordig kunnen overkomen zijn dit, zeker in Nederland, de meest onwaarschijnlijke. De grootste dreiging is onzichtbaar en digitaal, en de belangrijkste asset die daardoor geraakt kan worden is data.
Zo lezen we bijna dagelijks in het nieuws over ransomware-aanvallen die organisaties van allerlei formaten en in vrijwel alle industrieën treffen. Bedrijfskritische data is hierdoor niet meer toegankelijk en pas na het betalen van een aanzienlijke som geld weet je of deze snel, onbeschadigd en volledig is vrijgegeven. Een ander voorbeeld is die boze collega die zich onrechtmatig behandeld voelt, die toegang heeft tot gevoelige gegevens en besluit deze te wissen vlak voor zijn/haar vertrek. Twee voorbeelden van moderne rampen die elke organisatie kan overkomen.
Aangezien de meeste moderne rampen externe oorzaken hebben, waar organisaties minimale invloed op hebben, is het niet realistisch er vanuit te gaan dat het nooit zal voorkomen. Het is belangrijker dan ooit om van tevoren goed na te denken wat er moet gebeuren na een ‘dataramp’. Een best practice als het gaat om het veiligstellen van data is het opstellen van een Disaster Recovery-draaiboek. Dat klinkt voor sommigen wellicht ingewikkeld en onnodig, maar is in wezen niets meer dan een duidelijk stappenplan dat je volgt wanneer data in gevaar is. Het is een document dat elke onderneming die zijn eigen data beheert, zeker wanneer dat on premises gebeurt, zou moeten hebben.
Inhoud Data Recovery-draaiboek
Een Disaster Recovery (DR)-draaiboek biedt organisaties helderheid en structuur op een moment dat paniek, onzekerheid en chaos vaak de overhand hebben. Er zijn geen vaste regels waaraan een DR-draaiboek moet voldoen, maar er zijn wel best practices van zaken die daar idealiter in staan. Bijvoorbeeld:
- Belangrijke contactpersonen en -gegevens – In het draaiboek moet iedereen worden benoemd die een actieve functie heeft na een ‘disaster’ én mensen die op de hoogte moeten zijn, zowel intern als extern. Contactgegevens zijn daarbij van cruciaal belang. Denk bijvoorbeeld aan het opzetten van een e-mailalias met alle betrokkenen of een app-groep speciaal voor calamiteiten.
- Uitleg van definities en afkortingen – Je kunt er niet vanuit gaan dat iedere betrokkene de juiste kennis heeft van technische zaken, afkortingen en definities. Het is daarom raadzaam om het handboek zo te maken dat voor iedereen duidelijk en helder is waar het over gaat en wat er moet gebeuren.
- Verantwoordelijkheden per persoon – Wanneer er beslissingen genomen moeten worden die consequenties hebben voor de bedrijfsvoering of andere vergaande zaken, moet duidelijk zijn welke mensen gemachtigd zijn om dergelijke beslissingen te nemen.
- Helder stappenplan, inclusief flowchart – Denk van tevoren goed na wat logische stappen zijn en wie die moet zetten. Geef die stappen vervolgens grafisch weer in een duidelijke flowchart die mensen stap voor stap kunnen volgen. Dit onderdeel zal ervoor zorgen dat de gevolgen van een ramp tot een minimum worden beperkt, omdat je nu niet meer vanuit paniek handelt, maar op basis van een werkbaar plan.
- Overzicht van de infrastructuur – Hoe ziet de infrastructuur er in grote lijnen uit, welke machines draaien en hoeveel VM’s, applicaties etc.
- Uitwijk- en inwijkprocedure – Wanneer de primaire datalocatie niet meer beschikbaar is, moet duidelijk zijn waar gebruikers de data wel kunnen halen. Wanneer de infrastructuur weer klaar is om de data terug te zetten, zal er een inwijkprocedure starten. Beschrijf in het DR-draaiboek hoe deze procedures eruit moeten zien.
SaaS-applicaties
Je kunt een DR-draaiboek zo uitgebreid maken als je wilt. Je kunt het enkel laten gelden voor je on premises-omgeving, maar het is verstandig om ook te kijken naar je private en/of public-cloud-infrastructuur. En – wat vaak over het hoofd wordt gezien – controleer ook wat de backup-policies zijn van je SaaS-leverancier. De meeste SaaS-oplossingen, waaronder Microsoft Office 365 en de Google Business Suite, bieden namelijk geen standaard backup en recovery!
Controleren en testen
Het is aan te raden om jaarlijks te controleren of het DR-draaiboek nog klopt. Staan de juiste contactpersonen en contactgegevens er nog in, werken we nog met dezelfde leveranciers? Is er nieuwe regelgeving die we in het draaiboek moeten verwerken en zijn er aanzienlijke wijzigingen in de infrastructuur die belangrijk zijn om te noemen (niet elke additionele VM of laptop is hier relevant)? Het jaarlijks checken van dergelijke documentatie is een ITIL best practice en zorgt ervoor dat je op het moment suprême niet met achterhaalde informatie werkt.
Om zeker te zijn dat processen gesmeerd lopen en natuurlijk dat de backup zo draait dat volledige recovery mogelijk is, is het aan te raden regelmatig een ‘fire drill’ te doen. Met moderne backup- en recovery-oplossingen is het mogelijk deze oefeningen ook in real life uit te voeren, zonder dat de primaire data en omgeving daar hinder van ondervinden. Tijdens zo’n oefening zie je hoe de processen lopen en waar mogelijke hiaten in het draaiboek zitten. Ook het oefenen en testen maken deel uit van de noodzakelijke voorbereidingen op een mogelijke ramp. Een goede voorbereiding, waar een Disaster Recovery-draaiboek zeker onderdeel van moet uitmaken, zorgt dat de impact van een ramp op de bedrijfscontinuïteit zo klein mogelijk is.
Dit is een ingezonden bijdrage van Lloyd Hopper, Senior Director Technical Sales Benelux & ACH bij Veeam. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.
19 uur geleden
