Zo beschermen we je gegevens — elke dag, in de praktijk

De grootste beveiligingsfout die systemen maken is een inlog die eeuwig geldig blijft: wie één keer binnenkomt, blijft binnen. HotsaCity werkt daarom met korte, hernieuwbare toegang. Na het inloggen krijg je een access-token dat maar 15 minuten geldig is; een refresh-token (30 dagen) vernieuwt dat op de achtergrond, zodat jij er niets van merkt. Wordt een token toch ooit onderschept, dan is het binnen een kwartier waardeloos.

En het kan nog directer: via de token-blacklist wordt een sessie per direct ingetrokken — bij uitloggen, of wanneer jij zelf in je sessie-overzicht een apparaat wegstuurt. Elke wijziging die je doet is daarnaast beschermd met een CSRF-token (double-submit cookie), zodat een kwaadaardige website niet stiekem namens jouw browser acties kan uitvoeren.

Wil je een extra slot op de deur, dan zet je multi-factor authenticatie aan: naast je wachtwoord is dan een 6-cijferige code uit een authenticator-app nodig (TOTP, zoals Google Authenticator). Een gestolen wachtwoord alleen is dan niet meer genoeg.

De gevoeligste gegevens in je bedrijf zijn de persoonsgegevens van je mensen: BSN- en ID-documentnummers. Die worden in HotsaCity versleuteld opgeslagen met AES-256-GCM — een van de sterkste gangbare encryptiestandaarden — met een unieke salt en IV per veld. Dat laatste betekent: zelfs twee identieke waarden leveren totaal verschillende versleutelde data op, dus er valt ook niets af te leiden uit patronen.

Praktisch gezegd: wie op wat voor manier dan ook ruwe databasebestanden in handen zou krijgen, kijkt naar onleesbare brij — geen BSN's, geen ID's. Wachtwoorden worden apart behandeld: gehasht met bcrypt, een bewust traag algoritme dat massaal wachtwoorden raden onbetaalbaar maakt. Ook wij kunnen je wachtwoord dus niet inzien — niemand kan dat.

Beveiliging is niet alleen aanvallen buiten houden; het is ook snel kunnen handelen als er iets gebeurt. Telefoon kwijt? Laptop gestolen? In je sessie-overzicht zie je op welke apparaten je bent ingelogd en trek je een sessie met één handeling in — het token gaat op de blacklist en dat apparaat komt er per direct niet meer in. Je hoeft niet te wachten tot iets “vanzelf verloopt”.

Het systeem let ondertussen zelf mee: verdachte gebeurtenissen zoals een plots ander IP-adres, een andere browser of een nieuw apparaat op een bestaande sessie worden als security-event geregistreerd.

Alles wat tussen jouw browser en het platform reist, reist versleuteld: HTTPS is verplicht, en HSTS zorgt dat je browser nooit meer per ongeluk een onversleutelde verbinding probeert. In de browser zelf beschermt een Content Security Policy (CSP) tegen het binnensmokkelen van kwaadaardige scripts, en X-Frame-Options voorkomt dat je pagina onzichtbaar in een kwaadaardige site wordt ingebed (clickjacking).

De sessie-cookies zijn httpOnly — scripts in de browser kunnen er niet bij, dus zelfs een geslaagde scriptinjectie kan je sessie niet stelen. De refresh- en CSRF-cookies zijn extra strikt (SameSite=Strict), waardoor ze niet meeliften met verzoeken vanaf vreemde websites.

In elk bedrijf komt het moment dat je wilt weten wat er precies gebeurd is. Wie heeft die factuur aangepast? Wanneer is dat personeelsdossier geopend? Waarom klopt dit bedrag ineens niet meer? De audit trail van HotsaCity legt alle admin-acties vast met gebruiker, tijdstip en IP-adres — niet als straf, maar als geheugen. Discussies over “wie heeft dat gedaan” eindigen in seconden.

Voor de boekhouding gaat dat nog een stap verder: het grootboek kent zijn eigen audit trail met terugboekingen. Een fout wordt niet stilletjes overschreven maar zichtbaar teruggeboekt en opnieuw geboekt — precies zoals een accountant het wil zien. En de IP-registratie is privacyvriendelijk opgezet: voor normale controles wordt een gehashte vorm gebruikt.

De meeste aanvallen op systemen zijn niet slim maar massaal: duizenden wachtwoordpogingen, geautomatiseerd formulier-spam, scrapers die data leegtrekken. Daartegen werkt rate limiting: elk deel van het platform heeft een limiet op het aantal verzoeken, per IP-adres voor anonieme bezoekers en per gebruiker voor wie is ingelogd. Inlogpogingen zijn het strengst begrensd — brute force op wachtwoorden loopt daardoor al na een handvol pogingen vast.

Ook op MFA zit brute-force-bescherming: na herhaalde foute codes volgt een lockout die bij elke reeks mislukkingen langer wordt. Raden op de 6-cijferige code is daarmee praktisch kansloos.

Bedrijven, klanten en platformbeheer zijn op HotsaCity drie volledig gescheiden gebruikerstypen, elk met eigen tokens en eigen sessies. Een klant-login geeft dus per definitie geen toegang tot bedrijfsschermen, en andersom — die scheiding zit in de architectuur, niet in een instelling die per ongeluk uit kan staan.

En je gegevens blijven van jou. Accounts kunnen volledig verwijderd worden inclusief data-opruiming, en het dataretentiebeleid zorgt dat gegevens niet langer bewaard blijven dan nodig. Hoe dat zich verhoudt tot de AVG en andere standaarden lees je op de pagina over compliance — hier is het genoeg om te weten: het kán, en het is zo gebouwd.