Een back-up staat naast de originele website

Begin niet bij de techniek, maar bij de vraag: welke sleutel opent welke deuren? Noteer per onderdeel van je website wie of wat er toegang toe geeft. Denk aan het hostingaccount, het domeinregistratieaccount, het cms, de e-mailbox waarmee je wachtwoorden herstelt, en de opslag waar back-ups terechtkomen.

Een gezamenlijk verlies ontstaat wanneer twee of meer van die onderdelen aan dezelfde sleutel hangen. Een bekend patroon: de back-upplug-in schrijft naar dezelfde server, of naar een clouddrive die met hetzelfde e-mailadres en wachtwoord is aangemaakt. Wie dat ene wachtwoord kent, bereikt dan origineel en kopie.

Test dit door je eigen afhankelijkheden uit te tekenen. Neem een blad, zet de website in het midden en trek een lijn naar elke plek waar een kopie staat. Schrijf bij elke lijn: welk account en welke herstelmethode? Komen twee lijnen bij dezelfde inlog uit, dan heb je geen onafhankelijke kopie, hoe vaak de back-up ook draait.

Een afzonderlijke kopie helpt pas echt als het account dat de kopie beheert zelf moeilijk over te nemen is. Google beschrijft tweestapsverificatie als een extra beveiligingslaag voor het geval je wachtwoord wordt gestolen: naast het wachtwoord heb je dan een tweede stap of een toegangssleutel nodig (tweestapsverificatie aanzetten). Dat geldt voor een Google-account, maar het principe pas je toe op elk account in je tekening: hosting, registrar, cms en opslag.

Let op de beperkingen. Ondersteunt een van je diensten geen tweede stap, dan blijft dat een zwakke schakel die je moet compenseren, bijvoorbeeld door er geen kopie van andere accounts aan te koppelen. Bij een account via werk of school kan een beheerder bepalen of je zelf instellingen mag wijzigen; dat controleer je bij die beheerder.

MDN raadt voor sites met inlog sterke authenticatie aan en noemt toegangssleutels als de veiligste methode, met tijdgebonden eenmalige codes als betere keuze dan alleen een wachtwoord (webbeveiliging). Die bron gaat over het beveiligen van websites, niet over back-upstrategie. De vertaling naar je eigen opzet blijft dus jouw afweging.

Loop per back-upkopie de onderstaande vragen na. Een ongunstig antwoord bij een van de eerste drie vragen wijst op onvoldoende scheiding. Bij vragen één en twee is 'nee' ongunstig; bij vraag drie is juist 'ja' ongunstig.

Bij vraag drie is de richting omgekeerd ten opzichte van de andere vragen. Een kopie is beter beschermd wanneer de website uitsluitend nieuwe versies mag aanleveren en bestaande versies niet kan overschrijven of wissen. Alleen een wisverbod volstaat niet als overschrijven nog kan. Of dat bij jouw aanbieder kan, zoek je uit in de documentatie of via de support van die aanbieder.

1. Inventariseer wat je nodig hebt om te herstellen. Bestanden en databank, maar ook DNS-instellingen, configuratiebestanden, licentiesleutels en de lijst met gebruikte plug-ins.
2. Kies een bewaarplek buiten de hosting. Een andere aanbieder, of een opslagdienst onder een apart account.
3. Maak voor die plek een eigen inlog aan. Gebruik een uniek wachtwoord uit een wachtwoordbeheerder en zet waar mogelijk een tweede stap of toegangssleutel aan.
4. Beperk de schrijfrechten. Laat de website alleen nieuwe versies aanleveren, zonder bestaande versies te overschrijven of te wissen, voor zover je aanbieder dat ondersteunt.
5. Bewaar meerdere versies. Alleen de laatste kopie bewaren is risicovol: een besmette site wordt dan bij de volgende run over de goede kopie heen gekopieerd.
6. Documenteer het herstel. Schrijf in gewone taal op wie wat doet, in welke volgorde, en waar de toegangsgegevens veilig liggen.
7. Stel een controlemoment in. Een vaste datum in de agenda om te kijken of de kopie nog binnenkomt en nog leesbaar is.

Exacte instellingen en rechten verschillen per aanbieder en kunnen wijzigen. De beheerder van de dienst controleert in de eigen documentatie welke opties beschikbaar zijn.

Een kopie die nooit is teruggezet, is een aanname. Doe daarom een herstelproef op een afgeschermde testplek, niet op de live site. Scherm de testomgeving vóór het herstel af, beperk toegang en schakel echte mails, betaalverzoeken en andere uitgaande acties uit; ook een kopie kan echte klantgegevens en actieve koppelingen bevatten.

1. Haal de kopie op via het afzonderlijke account, zonder de hostinginlog te gebruiken. Lukt dat niet, dan is de scheiding onvolledig.
2. Zet de kopie terug op een lege testomgeving.
3. Controleer of de startpagina, een productpagina, het contactformulier en de inlog van het beheerpaneel werken.
4. Noteer hoe lang de handelingen duurden en welke gegevens ontbraken, zoals DNS-instellingen of licenties.
5. Verwijder daarna de testomgeving en zorg dat die niet publiek bereikbaar blijft.

Een geslaagde proef bewijst dat deze kopie op dit moment bruikbaar was. Het is geen garantie voor de toekomst en geen belofte over hoe snel je bij een echte aanval weer online bent. Herhaal de proef na grote wijzigingen aan je website of aan je accounts.

Stel: een fictieve webshop wordt beheerd door één zaakvoerder, die ook de back-ups instelde. De plug-in bewaart kopieën op dezelfde server. Het wachtwoord van het hostingaccount is hetzelfde als dat van de bijbehorende mailbox.

Invoer: tekening van afhankelijkheden, lijst van accounts, huidige back-uplocatie, herstelprocedure (leeg).

Verwachte controles: (1) de kopie staat in een ander account dan de site; (2) dat account heeft een uniek wachtwoord en een tweede stap, en het wachtwoord van het hostingaccount wordt nergens anders gebruikt, ook niet voor de mailbox; (3) de site kan de kopie niet wissen; (4) een tweede persoon heeft de procedure doorgenomen; (5) een herstelproef op een testplek is gedocumenteerd. Een mislukte controle vraagt gericht herstel. Maak onderscheid tussen technische scheiding, toegang, overdracht en de beperkte bewijskracht van een herstelproef; een ontbrekende overdracht bewijst niet dat de opslag fysiek naast de website staat.

Wil je ook weten welke zichtbare signalen je website nu uitzendt, zoals beveiligingsinstellingen die van buitenaf waarneembaar zijn? Bekijk ze via Marketing Scan. Een publieke scan meet alleen wat van buitenaf zichtbaar is en toetst jouw back-upopzet of accountbeveiliging niet.