Back-ups tegen ransomware: een herstelplan voor je webshop

Een back-up die je niet kunt terugzetten, is geen back-up. En een back-up die een aanvaller kan wissen, beschermt je niet tegen een aanvaller.

Bij ransomware draait het om één vraag: hoe snel ben je weer online, en met hoeveel verlies? Dit artikel helpt je dat vooraf te beantwoorden.

Waarom back-ups bij ransomware vaak falen

Aanvallers weten dat je een back-up hebt. Moderne ransomware zoekt er daarom actief naar. Wie toegang heeft tot je server, heeft vaak ook toegang tot de plek waar de back-ups staan.

De gebruikelijke fouten:

• Back-ups staan op dezelfde server als de webshop
• De back-up-schijf is gemount en schrijfbaar vanaf de applicatie
• Het account dat back-ups maakt kan ze ook verwijderen
• Back-ups worden nooit getest
• Er is niet genoeg bewaartijd, dus ook de besmette versie is al overschreven

Het gevolg: aanvaller versleutelt je data, wist de back-ups en vraagt losgeld. Betalen is geen garantie dat je je data terugkrijgt, en het financiert de volgende aanval. Wij raden het nooit als plan aan.

3-2-1 als uitgangspunt

De 3-2-1-regel is oud en bruikbaar:

• 3 kopieën van je data
• 2 verschillende opslagmedia of -locaties
• 1 kopie offsite

Voor een webshop vertaalt zich dat bijvoorbeeld naar: de live data, een back-up op een aparte opslagdienst en een offsite kopie bij een andere aanbieder.

Veel teams voegen een vierde letter toe: immutable of offline. Dat is de kopie die niemand kan aanpassen of wissen, ook niet met beheerdersrechten, binnen een ingestelde periode. Juist die kopie redt je bij ransomware.

Wat immutable betekent

Immutable opslag laat je data schrijven, maar niet wijzigen of verwijderen tot de bewaartermijn voorbij is. Veel object-opslagdiensten bieden dit aan onder namen als object lock of retention lock. Controleer bij je aanbieder wat precies wordt ondersteund en hoe je het instelt.

Het idee is simpel. Ook als een aanvaller je beheerdersaccount overneemt, kan hij de beschermde back-ups niet wissen.

Een goedkoper alternatief is een back-upaccount dat alleen kan toevoegen en niet kan verwijderen, of een offline kopie die niet permanent verbonden is. Het werkt minder strak, maar het is beter dan niets.

Wat je moet back-uppen

Een database-dump alleen is niet genoeg. Een webshop bestaat uit meer onderdelen.

Code in git, niet op de server

Je broncode hoort in een versiebeheersysteem. Dan is de server vervangbaar. Bij Magento deploy je vanuit git en composer.lock; bij Laravel idem.

Gebruik je shared hosting met FTP-uploads zonder git? Dan is je code een kwetsbaar punt, want de enige kopie staat op de server die je kwijtraakt.

Geheimen en .env

Het .env-bestand of app/etc/env.php bevat database-gegevens en sleutels. Zonder deze gegevens heb je een database zonder bruikbare applicatie, en bij Magento bovendien een crypt key voor versleutelde data. Bewaar ze versleuteld en apart van de gewone back-up. Een wachtwoordmanager voor teams of een secrets-oplossing past hier.

Magento-specifiek

Voor Magento is een volledige back-up groot en ingewikkeld, dus denk bewust na:

• De database is het belangrijkste.
• pub/media bevat uploads die je niet kunt regenereren.
• Gegenereerde bestanden zoals generated/ en pub/static kun je opnieuw bouwen, die hoef je niet te bewaren.
• app/etc/env.php en config.php bewaar je zeker.

Hosting op Hypernode regelt een deel hiervan, maar je moet nog steeds zelf weten wat je terugkrijgt en hoe snel. Zie /magento/hosting.

RPO en RTO in omzet uitgedrukt

Twee afkortingen sturen je plan.

• RPO (recovery point objective): hoeveel data mag je maximaal kwijtraken, uitgedrukt in tijd.
• RTO (recovery time objective): hoe lang mag je shop maximaal offline zijn.

Laat ze niet in techniek achter. Reken ze door naar geld.

Een voorbeeldberekening

Dit is een rekensom met verzonnen getallen ter illustratie. Vervang ze door je eigen cijfers.

Stel dat je shop gemiddeld 2.000 euro omzet per uur doet, en dat er per uur gemiddeld 15 orders binnenkomen.

• Is je RTO 24 uur, dan loop je ongeveer 48.000 euro omzet mis, zonder rekening te houden met imagoschade.
• Is je RPO 24 uur, dan raak je tot 24 uur aan orders en klantaccounts kwijt. Dat zijn in dit voorbeeld ruim 300 orders die je moet reconstrueren via betaalprovider, mail en logs.

Met zulke getallen is de discussie over back-upfrequentie direct concreet. Is een dagelijkse dump genoeg, of kost de extra frequentie minder dan de potentiële schade? Voor veel shops is dagelijks plus binlog-gebaseerd herstel of vaker dumps een redelijke keuze, maar dat hangt af van jouw omzet.

Betalingen zijn een vangnet

Als je orders verliest, helpt het dat je betaalprovider een eigen overzicht heeft. Met dat overzicht kun je betaalde orders na herstel controleren en ontbrekende alsnog aanmaken. Dit werkt niet voor alles, maar het is beter dan gokken.

Back-ups die een aanvaller kan wissen

Test de volgende vraag: als iemand de beheerder van mijn server is, kan hij dan mijn back-ups verwijderen?

Is het antwoord ja, dan beschermt je back-up je alleen tegen een kapotte schijf, niet tegen een aanvaller. Voorkom dat zo:

1. Gescheiden credentials. Het back-upsysteem heeft eigen inloggegevens die niet op de webserver staan.
2. Pull in plaats van push. Laat een aparte back-upserver de data ophalen, in plaats van de webserver die naar de back-up schrijft met rechten om te wissen.
3. Immutable of append-only opslag. Zie hierboven.
4. Aparte account of omgeving. Zet de back-ups in een ander account bij je cloudaanbieder, met streng beperkte toegang.
5. 2FA op de beheerportalen van hosting en opslag.
6. Alerting. Krijg je een melding als een back-up mislukt of als er ineens veel verwijderd wordt?

Een back-up die stilletjes drie weken niet draait, merk je pas als je hem nodig hebt. Zorg dat een mislukte back-up een alarm veroorzaakt.

Restore-tests: de enige echte controle

Je weet pas of een back-up werkt als je hem terugzet. Plan dat vooraf en schrijf het op.

Een bruikbare testroutine:

1. Kies een back-up van een willekeurige dag, niet de laatste.
2. Zet database en media terug op een aparte omgeving.
3. Start de applicatie en controleer belangrijke flows: inloggen, product bekijken, bestellen.
4. Meet de tijd die het kostte. Dat is je echte RTO, niet de geschatte.
5. Noteer wat er ontbrak of misging, en pas het plan aan.

Doe dit minimaal één keer per jaar, en na grote wijzigingen in je infrastructuur. Voor een shop met veel omzet vaker.

Eerlijk: de eerste keer duurt het langer dan je dacht en loopt er iets mis. Dat is de reden om het te doen. Liever een mislukte test op een rustige dinsdag dan een mislukt herstel tijdens een crisis.

Een herstelplan op papier

Schrijf een stappenplan dat niemand hoeft te bedenken onder druk. Het hoeft niet lang te zijn.

• Wie beslist? Een eindverantwoordelijke en een plaatsvervanger.
• Wie doet wat? Techniek, communicatie met klanten, contact met betaalprovider en hosting.
• Eerst isoleren: de besmette server van het netwerk of de shop in onderhoudsmodus. Bij Magento kan dat met bin/magento maintenance:enable.
• Niet herstellen op dezelfde besmette omgeving. Bouw een schone omgeving en zet daar je data terug.
• Controleer de back-up op besmetting voor je hem terugzet. Draait er al weken een webshell, dan zet je die anders gewoon terug.
• Wijzig alle wachtwoorden, sleutels en tokens na herstel.
• Zoek de oorzaak. Anders gebeurt het opnieuw.
• Meld waar nodig. Zijn persoonsgegevens geraakt, lees dan datalek melden bij de AP. Geen juridisch advies, wel een verplicht onderdeel van je plan.

Dit past in een breder incident response plan. Een voorbeeld van de technische kant bij een gehackte shop staat in Magento gehackt: wat nu?.

Voorkomen is ook een plan

Back-ups herstellen schade. Ze voorkomen geen aanval. Verklein daarom de kans dat ransomware binnenkomt:

• Houd je platform en pakketten bijgewerkt, zie Magento security patches zonder downtime.
• Beperk toegang tot beheer en servers, zie Magento admin beveiligen.
• Gebruik sleutelauthenticatie voor SSH en schakel wachtwoord-login uit.
• Geef medewerkers en leveranciers alleen de toegang die ze nodig hebben.
• Monitor ongebruikelijke activiteit, zoals plotselinge versleutelingsactiviteit en veel bestandswijzigingen.

Een algemeen overzicht staat in de Magento 2 security checklist en op /security.

Wanneer is dit overkill?

Een kleine shop met lage omzet en een hostingpartij die dagelijks back-ups maakt, hoeft geen multi-cloud-architectuur. Een offsite, immutable kopie en een jaarlijkse restore-test zijn wel altijd te rechtvaardigen. Ze kosten weinig en dekken het scenario waar het echt om gaat.

Heb je een groot assortiment, hoge omzet of veel integraties? Dan loont het om RPO en RTO serieus uit te rekenen en daar je infrastructuur op af te stemmen.

Veelgestelde vragen

Is een back-up van mijn hostingpartij genoeg?

Vaak niet alleen. Een hostingback-up is een goed begin, maar controleer waar hij staat, hoe lang hij bewaard wordt, wie hem kan verwijderen en hoe snel je kunt terugzetten. Voeg bij voorkeur een eigen offsite kopie toe.

Wat is het verschil tussen RPO en RTO?

RPO is hoeveel data je maximaal mag kwijtraken, in tijd. RTO is hoe lang je shop maximaal offline mag zijn. Reken ze om naar omzet, dan weet je hoeveel een extra back-up of snellere herstelroute waard is.

Hoe vaak moet ik een restore testen?

Minstens één keer per jaar en na grote wijzigingen aan je infrastructuur. Bij hoge omzet vaker, bijvoorbeeld per kwartaal.

Moet ik losgeld betalen als de back-up niet werkt?

Wij raden het niet aan. Betalen garandeert geen herstel en maakt je een herhaald doelwit. Schakel hulp in, onderzoek of er een andere route naar herstel is en meld waar nodig. Overleg bij juridische vragen met een jurist.

Wat is een immutable back-up?

Een kopie die gedurende een ingestelde periode niet gewijzigd of verwijderd kan worden, ook niet door een beheerder. Daarmee kan een aanvaller met overgenomen rechten je back-ups niet wissen.

Wil je weten of jouw herstelplan standhoudt? Wij kijken mee naar je back-ups, je restore-tijd en de rechten rond je opslag, en vertellen eerlijk wat er moet gebeuren. Je praat direct met degene die het uitvoert. Neem contact op via /contact of bekijk wat we doen op het gebied van /security/gehackt.