Je laat een website bouwen en denkt vooral aan design, functionaliteit en de lanceringsdatum. Maar wie is er verantwoordelijk als er iets misgaat met de beveiliging? Die vraag stellen de meeste opdrachtgevers pas als het al te laat is.
Wat valt er eigenlijk onder IT-security bij een webproject?
Veel mensen denken bij beveiliging aan hackers en virussen. Dat klopt, maar het beeld is te smal. IT-security bij een webproject gaat over alles wat de integriteit, beschikbaarheid en vertrouwelijkheid van je website en de bijbehorende data raakt.
Dat begint al bij de keuze voor een hostingpartij. Hoe worden back-ups gemaakt? Hoe snel reageert de partij bij een incident? Worden updates automatisch doorgevoerd of ligt dat bij jou? Dit zijn vragen die je vóór de oplevering moet stellen, niet erna.
Daarnaast speelt de configuratie van de website zelf een grote rol. Denk aan verouderde plugins, zwakke wachtwoorden voor het CMS, ontbrekende HTTPS-certificaten of formulieren die niet goed worden afgeschermd. Een bureau dat een mooie site oplevert maar de basisinstellingen niet op orde heeft, laat je met een risico achter dat je niet ziet totdat het misgaat.
Een derde onderdeel is toegangsbeheer. Wie heeft er inloggegevens? Zijn er nog accounts actief van voormalige medewerkers of freelancers? Dit klinkt triviaal, maar het is een van de meest voorkomende oorzaken van beveiligingsincidenten bij kleine en middelgrote organisaties.
Hoe bespreek je security met je webbouwer?
Het lastige is dat beveiliging zelden spontaan ter sprake komt in offertetrajecten. Bureaus focussen op wat zichtbaar is: het ontwerp, de snelheid, de integraties. Security is onzichtbaar als het goed gaat, en dat maakt het makkelijk om het te vergeten.
Toch is dit precies het moment om er wél over te beginnen. Vraag bij het opvragen van offertes expliciet wat er standaard gedaan wordt aan beveiliging. Niet als losse vraag achteraf, maar als onderdeel van je briefing. Zo maak je duidelijk dat het voor jou een serieus criterium is bij de keuze voor een bureau.
Stel concrete vragen. Wat is het updatebeleid voor het CMS en de plugins? Wie beheert de SSL-certificaten en worden die automatisch verlengd? Hoe worden inloggegevens opgeslagen en gedeeld? Wat gebeurt er bij een datalek? Is er een herstelplan?
Bureaus die hier vaag over zijn of het afdoen als ‘standaard geregeld’, geven je onvoldoende houvast. Een goed bureau legt dit vast in het contract of in de opleverdocumentatie. Als dat niet gebeurt, heb je niets om op terug te vallen als het misgaat.
Beveiliging is ook een contractkwestie. Leg vast wie na oplevering verantwoordelijk is voor het bijhouden van updates en het monitoren van beveiligingslekken. Valt dat onder het onderhoudscontract? Wat kost het extra? En wat zijn de reactietijden bij een incident? Partijen zoals Ictivity hanteren daarvoor serviceniveaus die je als referentie kunt gebruiken bij het beoordelen van wat een realistisch aanbod is.
Zorg ook dat je bij oplevering een beveiligingscheck laat uitvoeren. Dat hoeft geen duur extern audit te zijn. Veel bureaus bieden dit zelf aan, of je kunt een eenvoudige scan laten draaien via tools die openbare kwetsbaarheden in kaart brengen. Het gaat erom dat je niet blind vertrouwt op wat er is opgeleverd.
Wat moet je zelf op orde hebben als opdrachtgever?
Beveiliging is geen eenrichtingsverkeer. Ook als opdrachtgever heb je verantwoordelijkheden, en het helpt om die helder te hebben voordat je een project start.
Eigendom van je domein is het eerste punt. Zorg dat het domein op jouw naam staat, in een account dat alleen jij beheert. Niet in het account van het bureau, niet gedeeld met een hostingpartij waar je geen directe toegang tot hebt. Als de relatie met een bureau eindigt, wil je zonder gedoe verder kunnen. Dat kan alleen als je zelf de sleutels in handen hebt.
Hetzelfde geldt voor de broncode van je website. Als je een maatwerk website laat bouwen, moet contractueel vastliggen dat de broncode na oplevering aan jou toebehoort. Zonder die afspraak kun je in een situatie terechtkomen waarin je afhankelijk blijft van één partij voor elke aanpassing.
Hier is een overzicht van wat je als opdrachtgever zelf moet regelen of controleren:
- Zorg dat het domein op jouw naam staat bij een registrar die jij beheert
- Houd zelf de inloggegevens voor het CMS bij in een wachtwoordmanager
- Vraag bij oplevering om een lijst van alle externe accounts die zijn aangemaakt voor jouw project
- Laat contractueel vastleggen wie verantwoordelijk is voor updates na oplevering
- Sla de broncode op in een repository die jij kunt inzien of downloaden
- Controleer of het SSL-certificaat automatisch wordt verlengd en door wie
- Vraag hoe back-ups worden gemaakt en hoe je ze terugkrijgt bij een incident
Dit zijn geen technische taken. Het zijn organisatorische afspraken die je maakt voordat het project begint of uiterlijk bij de oplevering. Als je ze later probeert te regelen, is het vaak veel moeilijker om medewerking te krijgen.
Een punt dat opdrachtgevers onderschatten, is wachtwoordhygiëne binnen de eigen organisatie. Het heeft weinig zin dat een bureau de website netjes beveiligt als medewerkers aan jouw kant eenvoudige wachtwoorden gebruiken of inloggegevens via e-mail delen. Zet tweestapsverificatie aan voor het CMS en maak dat een vereiste voor iedereen met beheerderstoegang.
Tot slot: houd bij wie er toegang heeft. Maak een lijst van alle accounts met beheerdersrechten en verwijder accounts van mensen die niet meer bij het project betrokken zijn. Dit klinkt simpel, maar het wordt zelden gedaan. En het is precies het soort gat waar kwaadwillenden gebruik van maken.
Veelgestelde vragen over IT-security bij webprojecten
Wie is er verantwoordelijk als mijn website wordt gehackt?
Dat hangt af van wat er in het contract staat. Als er niets is afgesproken over onderhoud en beveiliging na oplevering, is de verantwoordelijkheid bij jou als opdrachtgever komen te liggen op het moment van oplevering. Bureaus zijn in principe niet aansprakelijk voor wat er daarna gebeurt, tenzij ze aantoonbaar fouten hebben gemaakt in de bouw. Zorg daarom altijd voor een onderhoudscontract waarin staat wie updates uitvoert, wie reageert bij een incident en binnen welke termijn. Zonder die afspraken sta je er alleen voor.
Wat is het verschil tussen een SSL-certificaat en echte beveiliging?
Een SSL-certificaat zorgt voor een versleutelde verbinding tussen de browser van de bezoeker en jouw webserver. Dat is goed en noodzakelijk, maar het is geen volledige beveiliging. Het beschermt het dataverkeer, maar niet de website zelf. Een gehackte website kan gewoon een groen slotje hebben. Echte beveiliging gaat over het up-to-date houden van de software, sterke toegangscontrole, regelmatige back-ups en monitoring op verdacht gedrag. Het certificaat is een basisvereiste, geen garantie.
Moet ik een apart beveiligingsaudit laten uitvoeren bij oplevering?
Dat is niet altijd nodig, maar het hangt af van wat je website doet. Als je persoonsgegevens verwerkt, betalingen afhandelt of gevoelige informatie opslaat, is een externe controle zeker het overwegen waard. Voor een eenvoudige informatiesite volstaat vaak een grondige interne check door het bureau, mits je daar een verslag van krijgt. Vraag in elk geval om een overzicht van de beveiligingsmaatregelen die zijn getroffen en laat dat onderdeel zijn van de opleverdocumentatie. Zo heb je een beginpunt als je later iets wilt laten controleren.
Leave a Reply