Veiligheid zit in het fundament
Jullie portaal draait op de gegevens waar je bedrijf op leunt. Daarom is beveiliging bij ons geen losse optie of extra module, maar onderdeel van het fundament dat wij leveren en onderhouden. Op deze pagina lees je hoe — eerst in gewone taal, daaronder de technische details.
Inloggen met Microsoft 365
Iedereen logt in met het bestaande Microsoft-account van jullie organisatie. Microsoft verzorgt de inlog, en het beveiligingsbeleid van jullie eigen organisatie — zoals tweestapsverificatie — geldt automatisch ook voor het portaal. Het portaal slaat zelf geen wachtwoorden op.
Bij de inrichting krijgt de eerste beheerder een tijdelijke, persoonlijke inloglink om alvast in te loggen voordat de Microsoft-koppeling is afgerond.
Werkt iemand niet met Microsoft 365? Dan logt die persoon in als gast, met een code die per mail wordt toegestuurd.
Iedereen ziet alleen wat nodig is
Iedereen krijgt een rol, en die rol bepaalt wat iemand ziet en mag. De namen van de rollen stemmen we af op jullie organisatie. Beheerders bepalen wie toegang heeft en met welke rol, en nieuwe gebruikers kunnen eerst goedgekeurd worden voordat ze iets zien. Wijzigingen in rollen en toegang worden vastgelegd, zodat altijd terug te zien is wie wat heeft aangepast.
Gebouwd tegen veelvoorkomende aanvallen
Het platform volgt de gangbare beveiligingsstandaarden voor moderne webapplicaties. Het remt geautomatiseerde aanvallen af, controleert de gegevens die binnenkomen en geeft bij een storing nooit technische details prijs waar een aanvaller iets aan heeft.
Back-ups buiten de omgeving
Elke dag wordt er een versleutelde back-up gemaakt en buiten de omgeving zelf bewaard. De sleutel waarmee de back-up is versleuteld, is per bedrijf uniek.
Waar jullie gegevens staan, wat AI er wel en niet mee doet en wat je meekrijgt als je weggaat, staat op één A4: zo gaan we met je gegevens om.
Wij houden het bij — ook morgen
Beveiliging is nooit af. Wij bewaken of de klantomgevingen bereikbaar zijn en krijgen een melding als dat niet zo is. Beveiligingsupdates voeren wij uit, in elke klantomgeving; platformcode en jullie eigen maatwerk staan daarvoor in gescheiden mappen. Aanpassingen aan het platform worden automatisch gecontroleerd op fouten en op kwetsbare bouwstenen.
Een eerlijk verhaal
Honderd procent veiligheid bestaat niet — wie dat belooft, moet je wantrouwen. Wat wij wél beloven: een fundament dat volgens de huidige standaarden is gebouwd en dat we actief bijhouden. Vragen over hoe iets precies werkt? We leggen het graag uit, inclusief de keuzes en de grenzen.
Voor wie het naadje van de kous wil weten
Ben jij — of je IT-partner — technisch onderlegd? Dit is wat er concreet in het platform zit.
Authenticatie & sessies
- Single sign-on via Microsoft Entra ID (OAuth 2.0 / OpenID Connect, authorization-code flow, vergrendeld op jullie tenant). Het platform slaat geen wachtwoorden op.
- Tijdens de inrichting ontvangt de eerste beheerder een tijdelijke, HMAC-ondertekende inloglink; daarna verloopt inloggen via Microsoft.
- Gebruikers zonder Microsoft 365 loggen in als gast, met een code die per mail wordt toegestuurd.
- Server-side sessies in de database; sessiecookies met httpOnly, Secure en SameSite; de sessie wordt vernieuwd bij het inloggen (bescherming tegen session fixation).
- Nieuwe gebruikers kunnen optioneel eerst door een beheerder worden goedgekeurd voordat ze toegang krijgen.
Bescherming van verkeer & invoer
- CSRF-bescherming via double-submit cookie met HMAC-ondertekende tokens en timing-safe vergelijking, op alle muterende API-aanroepen.
- Rate limiting op de API en op mislukte Microsoft-inlogpogingen (per IP).
- Invoer wordt met Zod-schema's gevalideerd; database-toegang via Drizzle ORM met geparametriseerde queries; een lintregel blokkeert directe innerHTML-manipulatie en waarschuwt bij raw SQL.
- Security-headers: HSTS, Content Security Policy (o.a.
frame-ancestors 'none'), X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Permissions-Policy.
Autorisatie & verantwoording
- Rolgebaseerde toegang met vaste rollen (weergavenamen per klant in te stellen), server-side afgedwongen; beheerders kunnen per onderdeel toegang vastleggen, desgewenst tijdgebonden met een vervaldatum.
- Een append-only logboek van beheermutaties (wie kreeg welke rol of toegang, en van wie).
- Centrale foutsanitisatie: geen stacktraces of technische details naar de gebruiker, wel correlation-ID's om incidenten te herleiden.
- Gestructureerde logging met correlation-ID's, waarin tokens, sleutels en wachtwoorden automatisch worden gemaskeerd.
Beheer & continuïteit
- Beschikbaarheidsmonitoring van alle klantomgevingen (health-check elke vijf minuten) met een webhook-melding, bijvoorbeeld naar Teams, bij aanhoudende storing.
- Versleutelde off-site back-ups (AES-256-GCM), met een eigen versleutelingssleutel per klantomgeving.
- Elke wijziging aan het platform doorloopt een CI-pipeline met typecheck, tests, security-lint, dependency-audit en secrets-scan; kwetsbare transitieve dependencies zijn gepind.
- Platformcode en klantspecifieke code staan in gescheiden mappen; platformreleases zijn genummerd en gedocumenteerd, en beveiligingsupdates voeren wij per klantomgeving uit.
Wat we níét claimen
We claimen geen certificeringen die we niet hebben, en we noemen een geautomatiseerde oppervlaktescan geen pentest. Heb je een securityvraag, of wil je dit door je IT-partner laten toetsen? Mail ons via sytze@rsitsolutions.nl — we laten graag zien hoe het werkt.