Websitebeveiliging begint niet bij één ingewikkelde technische oplossing, maar bij een paar terugkerende gewoonten: software bijwerken, bruikbare back-ups maken en zorgvuldig omgaan met accounts. Na het lezen weet je welke keuzes daarbij belangrijk zijn en welke informatie je vooraf vastlegt om na een incident sneller te kunnen herstellen.
Website-updates plannen zonder onnodige risico’s
Verouderde software is een veelvoorkomende oorzaak van beveiligingsproblemen. Dat geldt voor het contentmanagementsysteem, maar ook voor thema’s, plug-ins, betaalmodules, servercomponenten en koppelingen. Een update kan een bekend lek dichten, maar tegelijk functies veranderen waarop je website leunt. Daarom is ‘alles automatisch bijwerken’ niet voor iedere omgeving de beste keuze.
Begin met een overzicht van onderdelen, versies en verantwoordelijken. Noteer ook welke onderdelen essentieel zijn voor bijvoorbeeld afrekenen, formulieren of voorraadkoppelingen. Stel vervolgens een ritme vast: controleer minimaal wekelijks op urgente beveiligingsupdates en plan reguliere updates op vaste momenten. Updates die een actief misbruikt lek verhelpen, vragen om snellere actie dan een kleine verbetering van een niet-kritieke plug-in.
Automatisch bijwerken kan voor goed ondersteunde, eenvoudige onderdelen praktisch zijn. Bij maatwerk, webshops of veel onderlinge afhankelijkheden is eerst controleren vaak verstandiger. Installeer updates op een testomgeving en bekijk daarna belangrijke pagina’s en processen. Houd bij wat is bijgewerkt en wanneer. Zo kun je een fout koppelen aan een wijziging, in plaats van achteraf te moeten raden welke update het probleem veroorzaakte.
Updates testen en problemen gecontroleerd terugdraaien
Een update is pas klaar wanneer de website erna nog doet wat bezoekers en medewerkers nodig hebben. Test daarom niet alleen de homepage. Controleer bijvoorbeeld of formulieren aankomen, producten te vinden zijn, winkelmandjes werken en betalingen goed worden verwerkt. Bij een koppeling kan ook een ogenschijnlijk kleine wijziging invloed hebben op artikelgegevens of orderstatussen. Een korte, vooraf bepaalde testlijst maakt controles herhaalbaar.
Een testomgeving helpt om fouten te ontdekken voordat ze bezoekers raken. Die omgeving moet wel voldoende lijken op de productieomgeving: dezelfde belangrijke extensies, vergelijkbare configuratie en representatieve testgegevens. Gebruik geen echte persoonsgegevens als dat niet noodzakelijk is. Leg bovendien vast wie de update goedkeurt en wie bij problemen kan ingrijpen. Zo blijft een wijziging niet hangen omdat niemand weet wie de volgende stap mag zetten.
Spreek vooraf af wat terugdraaien betekent. Soms kun je een vorige softwareversie terugzetten, maar bij databasewijzigingen of gewijzigde bestellingen kan dat onveilig zijn. Een herstelplan kan dan bestaan uit de fout herstellen, een back-up terugzetten of tijdelijk een functie uitschakelen. Bewaar update-informatie en foutmeldingen, zodat een ontwikkelaar gericht kan zoeken. Een rollback is geen vervanging voor testen, maar een noodoptie met bekende gevolgen en duidelijke grenzen.
Back-ups maken van bestanden, databases en instellingen
Een back-up is alleen bruikbaar als die de onderdelen bevat die nodig zijn om de website weer op te bouwen. Denk aan bestanden, afbeeldingen, databases, configuratie en eventuele aangepaste code. Voor een webshop kunnen ook gegevens over orders en klantaccounts belangrijk zijn. Breng daarom eerst in kaart waar gegevens staan: op de webserver, bij een externe dienst of in een gekoppeld systeem. Een kopie van alleen de websitebestanden herstelt geen database die intussen is gewijzigd.
De frequentie hangt af van hoe vaak gegevens veranderen en hoeveel verlies aanvaardbaar is. Een informatieve website die zelden wordt aangepast, kan met minder frequente gegevensback-ups toe dan een webshop met doorlopende bestellingen. Leg vast hoeveel gegevens je maximaal kwijt mag raken. Dat helpt kiezen tussen bijvoorbeeld dagelijkse, uurlijkse of bijna doorlopende back-ups. Denk ook aan bewaartermijnen: meerdere herstelpunten zijn nuttig als een probleem pas na enkele dagen wordt ontdekt.
Bewaar back-ups niet uitsluitend op dezelfde server als de website. Bij een serverstoring, inbraak of verwijdering kunnen beide verloren gaan. Kies een aparte opslaglocatie en beperk wie erbij kan. Controleer ook of de back-up versleuteld wordt opgeslagen wanneer er persoonsgegevens in zitten. Noteer hoe je bij de opslag komt, wie bevoegd is en hoe lang bestanden worden bewaard. Een automatische melding bij een mislukte back-up voorkomt dat een stilgevallen proces pas tijdens herstel opvalt.
Back-ups terugzetten en herstel regelmatig testen
Een geslaagde back-upmelding bewijst niet dat je website ermee kunt herstellen. Het bestand kan beschadigd zijn, essentiële configuratie missen of niet meer passen bij de huidige software. Test daarom periodiek een volledige terugzetting in een afgeschermde omgeving. Controleer of de site start, afbeeldingen beschikbaar zijn, beheerders kunnen inloggen en belangrijke processen werken. Voor een webshop hoort daar ook een veilige test van de order- en betaalstroom bij, zonder echte betalingen te veroorzaken.
Leg vast hoe lang herstel ongeveer duurt en welke stappen afhankelijk zijn van een hostingpartij, ontwikkelaar of leverancier. Dat maakt duidelijk of de beschikbare hersteltijd past bij de bedrijfsvoering. Spreek ook af welk herstelpunt je kiest. Een recente back-up kan al besmette bestanden bevatten; een oudere versie kan juist veel nieuwe bestellingen missen. Herstel vraagt dus soms om een technische keuze én een besluit over gegevens die opnieuw moeten worden verwerkt.
Maak de herstelprocedure concreet genoeg om onder druk te volgen. Beschrijf waar de back-ups staan, hoe je toegang krijgt, hoe je een schone omgeving klaarzet en hoe je controleert of de website veilig is voordat die weer publiek gaat. Noteer wie beslist over de omschakeling en wie klanten of medewerkers informeert. Werk de instructies bij na een test of grote wijziging. Een getest herstelproces verkleint de kans dat belangrijke stappen tijdens een incident worden vergeten.
Sterke websiteaccounts beveiligen met MFA
Een wachtwoord dat op meerdere websites wordt gebruikt, maakt een website kwetsbaar voor hergebruikte inloggegevens. Als een andere dienst wordt gehackt, kunnen aanvallers dezelfde combinatie proberen bij het CMS, hostingpaneel of een webshop. Gebruik daarom voor ieder account een uniek, lang wachtwoord. Een wachtwoordmanager kan die wachtwoorden aanmaken en veilig bewaren, zonder dat medewerkers ze hoeven te onthouden of in een gedeeld document zetten.
Schakel multifactorauthenticatie (MFA) in waar dat beschikbaar is, vooral voor beheeraccounts en hosting. Met MFA is naast het wachtwoord nog een tweede bewijs nodig, zoals een code uit een authenticator-app of een beveiligingssleutel. Dat maakt misbruik van een gelekt wachtwoord lastiger. Bepaal vooraf hoe herstel werkt als iemand zijn telefoon kwijtraakt. Bewaar herstelcodes op een afgeschermde plek en wijs niet één medewerker aan als enige persoon die toegang kan herstellen.
Beperk het gebruik van gedeelde accounts. Een persoonlijk account maakt zichtbaar wie een wijziging heeft gedaan en maakt het eenvoudiger om toegang van één vertrekkende medewerker in te trekken. Als een leverancier toch een gedeeld account vereist, registreer dan wie het gebruikt en wijzig het wachtwoord wanneer de toegang niet langer nodig is. Controleer ook oude beheerdersaccounts en accounts die bij een proefproject zijn aangemaakt. Ongebruikte toegang is geen handige reserve, maar een extra ingang die je moet beveiligen.
Toegangsrechten beperken tot wat iemand nodig heeft
Niet iedereen die aan een website werkt, hoeft alles te kunnen aanpassen. Een redacteur heeft meestal geen toegang nodig tot serverinstellingen, betaalconfiguratie of gebruikersbeheer. Geef accounts daarom de laagste rol waarmee iemand het werk kan doen. Dat beperkt de schade wanneer een account wordt misbruikt en verkleint de kans op onbedoelde wijzigingen. Controleer de beschikbare rollen in het CMS of de webshop; standaardrollen zijn niet altijd precies afgestemd op de taken van je organisatie.
Maak toegang taakgericht en tijdelijk waar dat kan. Een ontwikkelaar die een specifieke storing oplost, heeft mogelijk kort beheerrecht nodig, maar niet automatisch blijvende toegang tot alle systemen. Leg vast wie toegang mag aanvragen en goedkeuren, tot welke omgeving die toegang geldt en wanneer die eindigt. Houd daarbij ook rekening met hosting, domeinregistratie, analytics, betaalproviders en gekoppelde systemen. Een account in het ene platform kan meer invloed hebben dan de website zelf.
Controleer rechten op vaste momenten en bij veranderingen in het team. Trek accounts in zodra iemand uit dienst gaat of een opdracht eindigt; alleen het wachtwoord veranderen is niet genoeg als er nog actieve sessies of tokens bestaan. Bekijk periodiek wie beheerder is en waarom. Een overzicht met naam, rol, eigenaar en laatste controledatum maakt die beoordeling praktisch. Zo voorkom je dat oude accounts blijven bestaan omdat niemand zeker weet of ze nog nodig zijn.
Herstel na een incident vooraf organiseren
Bij een beveiligingsincident gaat tijd verloren wanneer niemand weet wie mag beslissen of waar essentiële informatie staat. Leg daarom vooraf contactgegevens vast van interne verantwoordelijken, hostingpartij, ontwikkelaars en leveranciers van belangrijke koppelingen. Noteer ook welk kanaal gebruikt wordt als de website of bedrijfs-e-mail niet beschikbaar is. Houd deze informatie buiten het systeem dat mogelijk getroffen wordt en beperk de toegang tot mensen die haar tijdens een incident nodig hebben.
Beschrijf welke keuzes niet automatisch bij de technische uitvoerder liggen. Moet de website offline als er mogelijk persoonsgegevens worden buitgemaakt? Wie beslist of een webshop tijdelijk geen bestellingen aanneemt? Wie beoordeelt of klanten, toezichthouders of andere partijen geïnformeerd moeten worden? De precieze verplichtingen hangen af van de situatie, dus leg vast wie verantwoordelijk is voor de beoordeling en waar juridisch of privacyadvies beschikbaar is. Vermijd aannames dat een technisch herstel meteen alle andere taken oplost.
Leg ook vast welke systemen en gegevens prioriteit hebben en hoeveel uitval aanvaardbaar is. Noteer de laatste bekende goede back-up, de stappen om toegang te herstellen en de contactroute voor accounts die mogelijk zijn buitgemaakt. Bewaar instructies niet alleen in een beheerpaneel waar je bij een incident misschien niet meer in kunt. Oefen het scenario bijvoorbeeld met een korte bespreking: wie doet wat als de website niet bereikbaar is en het beheeraccount verdacht gedrag vertoont? Zo ontdek je onduidelijkheden voordat de druk hoog is.
Logboeken en meldingen gebruiken om afwijkingen te vinden
Niet ieder incident begint met een website die zichtbaar uitvalt. Verdachte inlogpogingen, nieuwe beheerdersaccounts of onverwachte wijzigingen kunnen eerder aanwijzingen geven. Logboeken registreren zulke gebeurtenissen, maar zijn alleen nuttig als ze beschikbaar blijven en iemand weet waarnaar gekeken moet worden. Bepaal welke gebeurtenissen relevant zijn, zoals mislukte aanmeldingen, wijzigingen aan gebruikersrechten en updates van belangrijke onderdelen. Zorg dat logs niet eenvoudig door een aanvaller kunnen worden aangepast samen met de website.
Meldingen moeten leiden tot een passende reactie. Een waarschuwing bij iedere mislukte login kan zoveel berichten opleveren dat belangrijke signalen verloren gaan. Stel daarom grenzen in, bijvoorbeeld een melding bij veel pogingen binnen korte tijd of bij een wijziging van een beheeraccount. Wijs een eigenaar aan die meldingen bekijkt en bepaal hoe snel dat gebeurt. Een melding die alleen naar een mailbox gaat die niemand controleert, geeft schijnveiligheid.
Controleer daarnaast periodiek de beschikbaarheid van de website en belangrijke functies. Een automatische controle kan melden dat een pagina niet bereikbaar is, maar meet niet altijd of een bestelling correct wordt verwerkt. Combineer technische beschikbaarheidscontroles met gerichte controles van kritieke processen. Bewaar meldingen en relevante tijdstippen tijdens onderzoek, maar stel ook een bewaartermijn vast: logbestanden kunnen persoonsgegevens bevatten. Stem toegang en bewaartermijn af op het doel en de geldende privacyafspraken.