Ga uit van een inbraak: zo houd je een SaaS-platform veilig

Elk SaaS-bedrijf doet zijn klanten dezelfde belofte, uitgesproken of niet: jouw data is bij ons veilig. In de bouw, waar onze platformen koperskeuzes, contracten en projectdata bevatten die in jaren zijn opgebouwd, ís die belofte het product. Het loont dus om precies te zijn over wat "veilig" eigenlijk betekent — want de meeste gesprekken over SaaS-beveiliging stoppen bij het inlogscherm, en precies daar begint het echte werk.

De belangrijkste mentaliteitsverandering is simpel: ga ervan uit dat er ooit iemand binnenkomt. Perimeterbeveiliging faalt. Een wachtwoord wordt gephisht, een token lekt, een dependency bevat een kwetsbaarheid. Dat zijn geen exotische gebeurtenissen — het is een doordeweekse dinsdag. De vraag die weerbare platformen onderscheidt van kwetsbare is niet "hoe voorkomen we elk incident", maar "hoe zorgen we dat geen enkele fout catastrofaal kan zijn".

Begin bij back-ups, want daar beginnen moderne aanvallen ook. Ransomware-operators versleutelen niet eerst je productiedatabase — ze richten zich op je back-ups, want een slachtoffer dat kan herstellen, betaalt niet. Daarom moeten back-ups immutable zijn: eenmaal geschreven en daarna vergrendeld, zodat niemand — geen aanvaller met gestolen beheerdersgegevens, zelfs je eigen operationsteam niet — ze kan wijzigen of verwijderen totdat de bewaartermijn verstrijkt. Een back-up die een beheerdersaccount kan verwijderen is geen vangnet, maar een single point of failure met extra stappen.

Retentie verdient dezelfde scherpte. Eén nachtelijke back-up die elke dag wordt overschreven, beschermt je tegen de fout van gisteren en verder tegen niets. Inbraken worden regelmatig pas weken of maanden na de eerste toegang ontdekt. Een serieus retentiebeleid is daarom gelaagd: dagelijkse snapshots voor de recente geschiedenis, wekelijkse en maandelijkse die verder teruggaan — lang genoeg bewaard om te kunnen herstellen naar een staat van vóórdat de aanvaller binnenkwam, niet alleen van vóórdat je het merkte.

Tussen die snapshots zit point-in-time recovery. Met continue transactielogging herstel je niet naar "vannacht om 02:00", maar naar 14:31 — twee minuten voordat de foute migratie draaide of het kwaadaardige script afging. Voor een platform waar kopers de hele dag woningen configureren en verkoopteams contracten tekenen, is het verschil tussen twaalf uur werk verliezen en twee minuten het verschil tussen een incident en een anekdote.

En het telt allemaal pas als je het getest hebt. Een back-up die nog nooit is teruggezet, is een hoop, geen garantie. Hersteloefeningen — de omgeving daadwerkelijk opnieuw opbouwen vanaf back-up, volgens schema, met de stopwatch erbij — zijn de enige manier om te weten dat je herstelpunt en hersteltijd echte getallen zijn in plaats van ambities in een document.

Dan zijn er de accounts die dit alles kunnen omzeilen: beheerders. Beheerdersgegevens zijn de moedersleutel van een SaaS-platform en verdienen een strenger regime dan al het andere. Tweefactorauthenticatie voor beheerders moet beleidsmatig worden afgedwongen, niet als optie worden aangeboden — en phishing-bestendig zijn: hardwaresleutels of passkeys in plaats van sms-codes die onderschept of afgetroggeld kunnen worden. Daarbovenop: geen gedeelde beheerdersaccounts, beheerdersidentiteiten gescheiden van dagelijkse accounts, en permanente productietoegang voor niemand. Verhoogde rechten worden just-in-time toegekend, beperkt tot de taak, en gelogd.

Logging is een eigen pijler. Je kunt niet reageren op wat je niet ziet, en je kunt logs die een aanvaller kan bewerken niet vertrouwen. Elke beheeractie, elke authenticatie, elke data-export hoort te belanden in een append-only audittrail die buiten het systeem leeft dat hij observeert. Als er iets misgaat, is dat spoor het verschil tussen het incident in uren reconstrueren en weken gissen.

De onglamoureuze basis draagt de rest: dependencies die snel gepatcht worden, secrets in een vault in plaats van in code, versleuteling onderweg en in rust, en strikte isolatie tussen tenants zodat het incident van de ene klant nooit dat van de andere kan worden. Niets hiervan is een feature die je één keer oplevert. Het is een houding — jaar na jaar herzien, geoefend en begroot.

Zo benaderen wij beveiliging in Alpha en in elk maatwerkplatform dat we bouwen: niet als vinkje op een verkoopsheet, maar als architectuurbeslissing die genomen wordt vóór de eerste regel code. Want de eerlijke versie van "jouw data is bij ons veilig" is langer en minder pakkend: zelfs op onze slechtste dag overleeft je data, blijft je geschiedenis intact, en kunnen we dat aantonen.