Een ransomware-aanval, serverstoring of incident op locatie kan een MKB-bedrijf binnen enkele minuten stoppen. Een disaster recovery-plan maakt van die onderbreking een gecontroleerde reeks: identificeer wat eerst moet terugkomen, kies betrouwbare herstelpunten, wijs verantwoordelijkheden toe en test het proces vóór een crisis.

Disaster recovery en bedrijfscontinuïteit zijn niet hetzelfde

Een bedrijfscontinuïteitsplan (BCP) zorgt ervoor dat essentiële activiteiten tijdens een incident blijven draaien, soms in een beperkte modus. Een disaster recovery plan (DRP) herstelt systemen, applicaties en gegevens, zodat de organisatie kan terugkeren naar de normale bedrijfsvoering.

De twee plannen versterken elkaar. Voor veel MKB-bedrijven is het nuttigste uitgangspunt een gerichte DRP die betrekking heeft op de applicaties en gegevens die rechtstreeks van invloed zijn op de omzet, klantenservice, veiligheid of wettelijke verplichtingen.

Begin met RPO en RTO

Twee doelstellingen bepalen de opzet van een herstelplan:

  • Recovery Point Objective (RPO): de maximaal aanvaardbare hoeveelheid gegevensverlies, uitgedrukt in tijd. Een RPO van vier uur betekent dat het back-upschema en het retentieontwerp een bruikbaar herstelpunt moeten bieden dat niet ouder is dan vier uur.
  • Recovery Time Objective (RTO): de maximaal aanvaardbare tijd voordat een systeem weer operationeel is. Een RTO moet detectie, besluitvorming, toegang tot schone back-ups, herstel en validatie omvatten, en niet alleen de kopieertijd.

Stel deze doelstellingen per toepassing vast. Een ERP, identiteitsdienst of productiedatabase kan een veel korter doel vereisen dan een intern archief. Eén doelstelling voor de volledige IT-omgeving beschermt systemen met een lage waarde doorgaans te veel en cruciale systemen te weinig.

Zes stappen voor een uitvoerbaar disaster-recoveryplan

1. Breng kritische systemen en afhankelijkheden in kaart

Maak een lijst van applicaties, servers, SaaS-services, identiteitssystemen en datastores. Documenteer vervolgens hun afhankelijkheden: DNS, netwerken, authenticatie, certificaten, databases en services van derden. Een server die wordt hersteld zonder de services waarvan deze afhankelijk is, is geen hersteld bedrijfsproces.

2. Prioriteit geven aan risico's en herstelvolgorde

Denk aan ransomware, hardwarestoringen, onbedoelde verwijdering, cloud- of leveranciersfouten en fysieke incidenten. Definieer de volgorde waarin services moeten terugkeren. Herstel moet de bedrijfsprioriteit volgen, en niet welke server het gemakkelijkst te herstellen is.

3. Wijs RPO en RTO toe per werklast

Spreek doelstellingen af met de proceseigenaren en maak deze meetbaar. De back-upfrequentie, retentie, netwerkcapaciteit en herstelplatform moeten in staat zijn om deze doelstellingen onder reële omstandigheden te bereiken.

4. Gebruik een 3-2-1-1 back-upontwerp

Bewaar drie kopieën van de gegevens op twee soorten media, waarvan één kopie offsite en één kopie offline of anderszins buiten bereik van de productieomgeving. De definitieve kopie is doorslaggevend tijdens het herstel van ransomware: deze moet bruikbaar blijven, zelfs als de productie- en administratieve inloggegevens in gevaar zijn gebracht.

5. Documenteer de herstelprocedure

Leg vast wie het incident meldt, wie toegang heeft tot back-upsystemen, welke systemen het eerst worden hersteld, waar encryptiesleutels en inloggegevens worden bewaard en hoe een hersteld systeem wordt gevalideerd. Bewaar een toegankelijke kopie buiten de productieomgeving.

6. Test en noteer de resultaten

Een plan dat nooit een echte werklast heeft hersteld, is slechts een hypothese. Voer regelmatig deeltests uit en voer een volledige oefening uit volgens een bepaald schema. Leg het gebruikte herstelpunt, de verstreken tijd, afhankelijkheden, storingen en corrigerende acties vast.

Waarom het herstelpunt belangrijker is dan de back-uptaak

Moderne aanvallers richten zich op back-ups voordat ze de productie versleutelen. Een voltooide taak is daarom niet voldoende: het resulterende herstelpunt moet worden geïsoleerd van de aangetaste omgeving en worden beschermd tegen overschrijven of verwijderen.

Met Oxibox worden gegevens bij de bron versleuteld en wordt elke back-up na overdracht losgekoppeld van de productie via een software-air gap. Vastgelegde herstelpunten gebruiken een append-only schrijfpad met een minimale bewaartermijn die alleen kan worden verlengd. Gedragsanalyse onderzoekt schrijfacties als extra verdediging; de bescherming van vastgelegde herstelpunten is niet afhankelijk van een AI-oordeel.

Dit onderscheid is essentieel in een DRP. Het team kan het herstel starten vanaf een punt waarvan de integriteit niet afhankelijk is van het productienetwerk of een niet-gecompromitteerde beheerconsole.

Plan voor herstel in alle omgevingen

Hardware- en virtualisatieplatforms zijn mogelijk niet beschikbaar na een groot incident. Het herstelontwerp moet daarom meer omvatten dan een terugkeer naar de oorspronkelijke host. Oxibox ondersteunt herstel in VMware ESXi-, Microsoft Hyper-V-, Proxmox VE-, Nutanix AHV- en KVM-gebaseerde omgevingen, evenals fysieke systemen via bare-metal-back-up.

Individuele systemen kunnen binnen enkele minuten opnieuw worden opgestart met R2V-herstel. Een compleet informatiesysteem duurt langer omdat services in afhankelijkheidsvolgorde moeten worden hersteld en gevalideerd; bij één echt ransomware-incident werd een volledig door Oxibox beschermd informatiesysteem binnen twee uur opnieuw opgestart.

Een praktische DRP-checklist

  • Kritische applicaties en hun eigenaren worden geïdentificeerd.
  • Afhankelijkheden en herstelvolgorde zijn gedocumenteerd.
  • RPO en RTO worden per werklast gedefinieerd.
  • Ten minste één herstelkopie is losgekoppeld van de productie.
  • Back-up-encryptiesleutels en noodreferenties zijn toegankelijk tijdens een storing.
  • Herstelprocedures zijn beschikbaar buiten de getroffen omgeving.
  • Tests omvatten zowel bestanden als complete systemen.
  • Testresultaten en herstelacties worden als bewijsmateriaal bewaard.
  • Leveranciers, MSP's en interne teams kennen hun verantwoordelijkheden.
  • Het plan wordt herzien na veranderingen in de infrastructuur of de bedrijfsvoering.

Van document naar herstelmogelijkheid

De waarde van een disaster-recoveryplan ligt niet in het document zelf. Het is het geverifieerde vermogen om vanaf een schoon herstelpunt te starten en kritieke services binnen de afgesproken tijd terug te brengen. Begin met de systemen die er het meest toe doen, test ze van begin tot eind en breid de dekking iteratief uit.

Voor de technische herstellaag raadpleegt u de Oxibox-implementatieopties en de gids over bare-metalback-ups.