Beveiliging en compliance

Authenticatie

• Toegangstokens zijn kortlevende JWT’s (15 minuten), gecontroleerd bij de API-gateway; vernieuwingstokens blijven 30 dagen geldig bij inactiviteit en maximaal 90 dagen, worden bij elk gebruik geroteerd en worden opgeslagen in een HttpOnly-, Secure- en SameSite-cookie. Hergebruik van een geroteerd vernieuwingstoken trekt de hele keten in.
• Ondertekeningssleutels worden elke 90 dagen met overlap geroteerd; publieke sleutels worden gepubliceerd op /.well-known/jwks.json.
• Rechten zijn niet in tokens ingebed: ze worden per verzoek gelezen, zodat een rolwijziging direct ingaat en elke sessie centraal kan worden ingetrokken.
• Tweestapsverificatie (TOTP) kan optioneel zijn, verplicht voor Eigenaars en Beheerders, of verplicht voor iedereen. Single sign-on met Google Workspace en Apple is beschikbaar in elk abonnement. SAML 2.0, passkeys en SCIM-provisioning staan gepland en zijn nog niet beschikbaar.
• API-sleutels worden één keer getoond, opgeslagen als SHA-256-hash, afgebakend vanuit een gesloten catalogus, begrensd door de rechten van de eigenaar en direct in te trekken. Zie Authenticatie.
• Inloggen is in snelheid beperkt per IP-adres en per e-mailadres; tien mislukte pogingen blokkeren het account voor 30 minuten; mislukte pogingen vanaf één IP-adres worden geteld en vastgelegd, maar dat adres wordt standaard niet geblokkeerd. Elke inlogpoging, mislukking, vernieuwing, rechtenwijziging en beheeractie komt in het auditlogboek.

Tenantisolatie

Elke rij in elke service bevat het account waartoe ze behoort, en elke query wordt daar automatisch op gefilterd; het filter uitschakelen vereist een expliciete aanroep op een toelatingslijst die alleen voor tenantoverschrijdende handelingen van medewerkers wordt gebruikt en door tests wordt gedekt. Rollen per site voegen daar een sitefilter aan toe. Een verzoek om een resource van een ander account antwoordt met 404, nooit met 403, zodat ID’s niet kunnen worden opgesomd. Elk schrijfendpoint gebruikt een strikte toelatingslijst voor velden. Een test op toegang tussen accounts is verplicht voor elk nieuw endpoint.

De header X-Account-Id bij elk verzoek wordt gecontroleerd tegen het token, zodat een bug in een client of een opnieuw afgespeeld token nooit ongemerkt gegevens van een andere tenant kan lezen.

Versleuteling

TLS 1.2 of nieuwer naar elk openbaar endpoint, wederzijdse TLS tussen services, TLS naar elke datastore, versleutelde volumes in rust, en envelopversleuteling per account voor gevoelige velden. Publieke certificaten worden automatisch uitgegeven en vernieuwd; interne certificaten zijn kortlevend.

Geheimen

Alle geheimen, inclusief je eigen providersleutels (BYOK) en webhookgeheimen, staan in een aparte geheimenbeheerder, versleuteld, afgebakend per service en geaudit. Niets staat in versiebeheer (afgedwongen door een scan vóór elke commit) of in containerimages (gecontroleerd in CI). Ontwikkelaars hebben standaard geen toegang tot productiegeheimen; noodtoegang vereist twee goedkeuringen, is kortlevend en wordt gelogd naar een kanaal dat niet kan worden gedempt.

Webhooks

Uitgaande leveringen worden ondertekend met HMAC-SHA256 over het tijdstempel en de ruwe body, bevatten een nonce en een gebeurtenis-ID, worden buiten een venster van vijf minuten geweigerd en worden met backoff opnieuw geprobeerd tot in een dead-letter-wachtrij. Geheimen worden met een overlapvenster geroteerd en kunnen direct worden ingetrokken. Inkomende webhooks van providers worden met het schema van elke provider geverifieerd voordat er iets wordt verwerkt. Details: Webhooks.

Snelheidslimieten

Vier lagen: DDoS- en botbescherming aan de rand van het netwerk, limieten per IP-adres bij de reverse proxy, token buckets per account en per identiteit bij de API-gateway, en domeinlimieten binnen de services. De limieten staan in het API-overzicht.

Audit

Elke wijziging wordt geschreven naar een auditlogboek dat alleen kan worden aangevuld en met een hashketen is beveiligd, met twee bewaarklassen: algemene gebeurtenissen en compliancegebeurtenissen (verzoeken van betrokkenen, datalekken, subverwerkers en KYC-registraties). De klasse wordt toegekend zodra een vermelding wordt geschreven; het logboek kan door niemand worden bewerkt of verwijderd, en een automatische opschoning per klasse is nog niet actief. Eigenaars en Beheerders kunnen het filteren en exporteren. Wachtwoorden, tokens en sleutels worden nooit gelogd; de logginglaag maskeert bekende gevoelige sleutels.

Gegevensbescherming

• Verzoeken van betrokkenen onder de AVG, de UK GDPR, de CCPA en de LGPD (inzage, export, verwijdering) worden ontvangen en gevolgd in de compliance-console, met deadlines. Verwijdering wordt uitgevoerd door medewerkers van RolChat en het verzoek wordt pas gesloten nadat zij dat hebben bevestigd; automatische verwijdering over alle modules heen is nog niet beschikbaar.
• Gegevenslocatie: gegevens worden opgeslagen in de EU. De regio wordt bij het aanmelden niet op land gekozen; de regio-instelling in de accountinstellingen wordt alleen vastgelegd en verplaatst nog geen gegevens.
• Bewaartermijn volgens abonnement: 1, 2 of 3 jaar. Het verwijderen van een gesprek of contact verbergt dat tot het einde van die termijn; het verwijderen van een account is een verzoek met 30 dagen bedenktijd, waarna medewerkers de gegevens wissen; een onbetaald account wordt 90 dagen bewaard en daarna gewist. De automatische opschoning die deze termijnen afdwingt, wordt uitgerold.
• Een Verwerkersovereenkomst, een lijst met subverwerkers, een privacybeleid en een cookiebeleid zijn gepubliceerd op rolchat.com; de verwerkersovereenkomst wordt bij het aanmelden geaccepteerd.
• Melding van datalekken binnen 72 uur, zoals vereist door artikel 33 van de AVG.

Kwetsbaarhedenbeheer

Afhankelijkheden worden continu gemonitord; lockbestanden worden gecommit; basisimages zijn vastgepind op digest; CI-acties zijn vastgepind op commit. Vanaf de bèta staat er jaarlijks een penetratietest door een externe partij gepland, voor de API, de widget en de openbare pagina’s, plus een intern scenario waarin een inbraak wordt verondersteld. Bij algemene beschikbaarheid volgt een privé bugbountyprogramma. Meld beveiligingsproblemen aan security@rolchat.com.

Beschikbaarheid

Het platform draait op meerdere nodes met automatische failover voor stateless services en beheerde replicatie voor databases. Uptimedoelen per abonnement staan in je overeenkomst.

Incidentrespons

Runbooks voor elke service, een piketrooster, een externe pager die werkt wanneer onze eigen infrastructuur dat niet doet, en verplichtingen om klanten te informeren die in het proces zijn ingebouwd.