Hoe wij de software van onze klanten beveiligen
In de systemen die wij bouwen staan gegevens van klanten, huurders, patiënten of medewerkers. Daar hoort een eerlijk verhaal bij over hoe we die beschermen — zonder technisch jargon, en zonder mooiere beloftes dan we waar kunnen maken.
Waarom inloggen met tweestapsverificatie zo veilig is
Je wachtwoord is als de sleutel van je voordeur. Handig — maar een sleutel kan gekopieerd, geraden of gestolen worden. Tweestapsverificatie (ook wel 2FA of tweestaps-inloggen genoemd) zet er een tweede slot op. En dat tweede slot kun alleen jij openen.

Hoe werkt het?
Bij het inloggen vragen we niet één, maar twee dingen:
- Iets wat je weet — je wachtwoord.
- Iets wat je hebt — meestal je telefoon, waarmee je een extra code invoert.
Pas als allebei kloppen, ben je binnen.
Waarom is dat zo veilig?
Stel dat iemand je wachtwoord te pakken krijgt — door een datalek, een phishingmail of gewoon door te raden. Zonder die tweede stap staat hij nog steeds buiten, want de code komt binnen op jóuw telefoon, niet op de zijne. Het zwakke punt van bijna elk account is nu eenmaal het wachtwoord; tweestapsverificatie dicht precies dat gat.
Zoals een ouderwetse bankkluis
Je komt binnen en zegt tegen de baliemedewerker: “Ik ben Jansen, ik wil bij mijn kluisje.” Je legt je pasje neer — iets wat je hebt. Maar dan pakt de medewerker een tweede sleutel uit de la. De kluis heeft namelijk twee sloten: één sleutel heb jij, de andere ligt achter de balie. Pas als jullie ze allebei tegelijk omdraaien, gaat het deurtje open.
Steelt iemand jouw sleutel? Dan staat hij voor een kluis die niet opengaat. Werkt er een gewetenloze bediende achter de balie? Ook die komt er niet in, want hij mist jouw helft. Twee sloten, twee eigenaren — en alleen samen werkt het.
En het wachtwoord van vanavond

Nog dichter bij hoe die tijdelijke code werkt, is dit: een chique club met een portier. Je noemt je naam bij de deur — je wachtwoord — maar de portier vraagt ook om het wachtwoord van vanavond. Een woord dat elke avond verandert en dat alleen de leden per koerier hebben gekregen. Wie gisteren meeluisterde, heeft er vandaag niets aan. Precies zoals een code die na dertig seconden vervalt.
Of, in het klein: de kaartjescontroleur bij een concert. Eén persoon scant je ticket, de ander kijkt of het bandje om je pols zit. Twee onafhankelijke bewijzen dat je bent wie je zegt — met een vervalst ticket alléén kom je er niet langs.
De manieren om die tweede code te ontvangen
Je kunt de extra code op verschillende manieren krijgen. Ze zijn allemaal veiliger dan alléén een wachtwoord, maar de een is sterker dan de ander.
Authenticator-app — het veiligst
Een app op je telefoon (zoals Google Authenticator of Microsoft Authenticator) maakt elke 30 seconden een nieuwe code aan. Die code wordt nergens verstuurd — hij ontstaat op je toestel zelf — en is daardoor vrijwel niet te onderscheppen.
Sms
Je ontvangt de code per sms. Snel en makkelijk, en voor de meeste mensen prima. Wel iets kwetsbaarder, omdat een sms in theorie omgeleid of onderschept kan worden.
Vergelijkbaar met sms, maar via een versleuteld bericht. Veilig zolang je WhatsApp en je telefoon zelf goed beveiligd zijn.
De code komt in je mailbox. Handig, maar zo veilig als je e-mailaccount zelf is. Zorg dus dat je juist dáár de toegang goed beschermt — het liefst óók met tweestapsverificatie.
Waarom onze software veiliger is gebouwd
De meeste websites draaien op WordPress. Dat is niet slecht — het is populair omdat het snel en makkelijk werkt. Maar wij hebben bewust gekozen voor een andere aanpak: volledig op maat gebouwd met Laravel. Dat scheelt aanzienlijk in veiligheid. Hieronder leggen we uit waarom, zonder technisch jargon.
Het verschil in één beeld
Stel je twee huizen voor. Het ene is een standaard woning uit een catalogus, met een voordeur waar overal dezelfde sleutel op past. Handig, want je kunt er van alles aan vastschroeven: een uitbouw, een serre, een carport — allemaal van verschillende leveranciers. Maar elke uitbouw heeft zijn eigen deur, zijn eigen slot en zijn eigen zwakke plek. En omdat half Nederland in datzelfde huis woont, weten inbrekers precies waar ze moeten zoeken.
Het andere huis is speciaal voor jou gebouwd. Er zitten alleen deuren waar jij ze wilde, en elke deur is er bewust neergezet. Een inbreker die het standaardhuis vanbuiten kent, staat hier voor een plattegrond die hij niet herkent. Zo verhoudt op maat gebouwde software zich tot een standaardpakket.
Waarom dat concreet veiliger is
Geen losse onderdelen van onbekende makers
Bij een standaardsite komen extra functies uit kleine uitbreidingen — plug-ins — die vaak door verschillende, soms onbekende partijen zijn gemaakt. Verreweg de meeste inbraken op zulke sites komen niet door de site zelf, maar via zo’n uitbreiding die niet goed onderhouden wordt. Bij ons zit alle functionaliteit in één samenhangend geheel, gebouwd en onderhouden door één team.
Minder deuren, minder sloten die kapot kunnen
Elke toegevoegde functie is een mogelijke ingang. Wij bouwen alleen wat er echt nodig is. Daardoor is er simpelweg minder om binnen te komen.
Wij bepalen wanneer er iets verandert
Bij standaardsites installeren uitbreidingen soms vanzelf updates, en gaat er zomaar iets stuk — of open. Bij ons gebeurt er niets zonder dat wij het weten, testen en goedkeuren.
Minder een doelwit
Op standaardsites worden massaal geautomatiseerde aanvallen losgelaten: computers die het hele internet afstruinen naar bekende zwakke plekken. Een op maat gebouwd systeem past niet in dat rijtje en wordt daardoor veel minder vaak geraakt.
De basisbeveiliging zit ingebouwd
Het fundament waarop we bouwen is gemaakt met beveiliging als uitgangspunt: bescherming tegen de bekendste aanvalsvormen zit standaard ingebakken, niet als iets wat je er later bij moet zoeken. Denk aan het versleuteld opslaan van wachtwoorden, en aan controles die voorkomen dat iemand via een formulier of een adresbalk ongewenste opdrachten aan het systeem kan geven.
Toegang is precies geregeld
We bepalen tot in detail wie wat mag zien en doen, en beveiligen die toegang met tweestapsverificatie. Iemand die alleen een wachtwoord bemachtigt, komt er dus nog steeds niet in.
Hoe wij naar beveiliging kijken
Bij veel software wordt beveiliging er achteraf bij gezocht: eerst bouwen, dan kijken of het veilig genoeg is. Wij draaien dat om. Bij ons is beveiliging een ontwerpkeuze die aan het begin wordt gemaakt en in elke laag terugkomt — van de eerste regel code tot het moment dat een gebruiker inlogt.
Het uitgangspunt is eenvoudig: we gaan ervan uit dat er ooit iets misgaat. Een wachtwoord lekt, een laptop raakt zoek, iemand klikt op de verkeerde link. Goede software is niet software waarin dat nooit gebeurt, maar software waarin één fout niet meteen alles opent.
Vier principes die je terugziet in ons werk
Zo min mogelijk toegang
Iedereen — mens én systeem — krijgt precies de rechten die nodig zijn om het werk te doen, niet meer. Een medewerker die alleen facturen inziet, kan niet bij gebruikersgegevens. Raakt zo’n account gecompromitteerd, dan blijft de schade beperkt tot dat kleine stukje.
Meerdere lagen
We vertrouwen nooit op één maatregel. Een wachtwoord wordt aangevuld met tweestapsverificatie, versleuteling, logging en scheiding van omgevingen. Valt er één laag weg, dan staan de andere er nog.
Alleen bouwen wat nodig is
Elke extra functie is een extra mogelijke ingang. Door bewust klein en overzichtelijk te bouwen, is er simpelweg minder om aan te vallen. Dat is meteen de reden dat we werken met maatwerk in plaats van een stapel kant-en-klare uitbreidingen van onbekende makers.
Standaard veilig, niet standaard open
Nieuwe functies staan bij ons dicht tot ze bewust worden opengezet. Vergeten iets af te schermen kan dus niet leiden tot een open deur.
Hoe dat er in de praktijk uitziet
Wachtwoorden slaan we versleuteld op, nooit leesbaar. Gegevens gaan versleuteld over de lijn en worden versleuteld bewaard. Inloggen kan met tweestapsverificatie. Alle invoer van buiten wordt gecontroleerd, zodat niemand via een formulier of een webadres ongewenste opdrachten aan het systeem kan geven. Belangrijke handelingen worden vastgelegd, zodat achteraf te zien is wie wat deed. Test- en productieomgevingen zijn strikt gescheiden. En updates komen er niet ongemerkt in: wij bepalen zelf wanneer er iets verandert, na testen.
De standaarden waarop we ons baseren
We vinden het belangrijk dat “wij doen aan beveiliging” geen loze belofte is. Daarom volgen we internationaal erkende kaders als leidraad.
OWASP Top 10
De wereldwijde lijst van de meestvoorkomende beveiligingsrisico’s in webapplicaties. Dit is de praktische lat waarlangs we onze code leggen: bescherming tegen de aanvalsvormen die het vaakst misgaan.
ISO/IEC 27001
De internationale norm voor informatiebeveiliging. Die beschrijft niet één maatregel, maar een compleet werkproces: risico’s in kaart brengen, maatregelen nemen, controleren en blijven verbeteren. Wij hanteren die denkwijze als leidraad in ons werk.
AVG (GDPR)
De Europese privacywetgeving. Persoonsgegevens verzamelen we alleen als het nodig is, we bewaren ze niet langer dan nodig, en we ontwerpen systemen met privacy als uitgangspunt.
NIS2 / Cyberbeveiligingswet
Europese regelgeving die de digitale weerbaarheid van bedrijven in belangrijke sectoren aanscherpt en in Nederland in wetgeving wordt omgezet. Ook als leverancier krijg je hiermee te maken, via de eisen die opdrachtgevers in de keten doorgeven.
Vragen over beveiliging?
Stel ze gerust. We leggen liever uit hoe iets werkt dan dat we er vaag over doen — ook als het antwoord “dat weten we nog niet” is.