Sikkerhed og compliance

Godkendelse

• Adgangstokens er kortlivede JWT’er (15 minutter), der verificeres i API-gatewayen; opdateringstokens lever 30 dage ved inaktivitet og højst 90 dage, roteres ved hver brug og gemmes i en HttpOnly-, Secure- og SameSite-cookie. Genbrug af et roteret opdateringstoken tilbagekalder hele kæden.
• Signeringsnøgler roteres hver 90. dag med et overlap; de offentlige nøgler offentliggøres på /.well-known/jwks.json.
• Tilladelser er ikke indlejret i tokens: de læses ved hver anmodning, så en rolleændring træder i kraft med det samme, og enhver session kan tilbagekaldes centralt.
• Tofaktorgodkendelse (TOTP) kan være valgfri, påkrævet for ejere og administratorer eller påkrævet for alle. Single sign-on med Google Workspace og Apple er tilgængelig på alle planer. SAML 2.0, adgangsnøgler (passkeys) og SCIM-provisionering er planlagt og endnu ikke tilgængelige.
• API-nøgler vises én gang, gemmes som en SHA-256-hash, afgrænses ud fra et lukket katalog, begrænses af ejerens tilladelser og kan tilbagekaldes med det samme. Se Godkendelse.
• Login er hastighedsbegrænset pr. IP og pr. e-mail; ti mislykkede forsøg låser kontoen i 30 minutter; mislykkede forsøg fra én IP-adresse tælles og registreres, men spærrer som standard ikke den adresse. Hvert login, hver fejl, opdatering, tilladelsesændring og administratorhandling går til revisionsloggen.

Lejeradskillelse

Hver række i hver tjeneste angiver den konto, den tilhører, og hver forespørgsel filtreres automatisk efter den; at slå filteret fra kræver et eksplicit kald på en tilladelsesliste, som kun bruges af medarbejderoperationer på tværs af lejere og er dækket af tests. Roller pr. websted lægger et webstedsfilter ovenpå. En anmodning om en anden kontos ressource svarer 404, aldrig 403, så id’er ikke kan opregnes. Hvert skrive-endpoint bruger en streng tilladelsesliste over felter. En test af adgang på tværs af konti er obligatorisk for hvert nyt endpoint.

Headeren X-Account-Id på hver anmodning kontrolleres mod tokenet, så en klientfejl eller et genafspillet token aldrig ubemærket kan læse en anden lejers data.

Kryptering

TLS 1.2 eller nyere til alle offentlige endpoints, gensidig TLS mellem tjenester, TLS til alle datalagre, krypterede volumener i hvile og kuvertkryptering pr. konto for følsomme felter. Offentlige certifikater udstedes og fornyes automatisk; interne certifikater er kortlivede.

Hemmeligheder

Alle hemmeligheder, herunder dine BYOK-udbydernøgler og webhookhemmeligheder, ligger i en dedikeret hemmelighedsmanager, krypteret, afgrænset pr. tjeneste og revideret. Intet ligger i versionsstyringen (håndhæves af scanning før hvert commit) eller i containerbilleder (kontrolleres i CI). Udviklere har som standard ingen adgang til hemmeligheder i produktion; nødadgang kræver to godkendelser, er kortvarig og logges til en kanal, der ikke kan gøres tavs.

Webhooks

Udgående leveringer signeres med HMAC-SHA256 over tidsstemplet og den rå body, indeholder en nonce og et hændelses-id, afvises uden for et vindue på fem minutter og forsøges igen med backoff, indtil de ender i en kø for døde beskeder. Hemmeligheder roteres med et overlapningsvindue og kan tilbagekaldes med det samme. Indgående webhooks fra udbydere verificeres med hver udbyders metode, før noget behandles. Detaljer: Webhooks.

Hastighedsbegrænsning

Fire lag: beskyttelse mod DDoS og bots i edge-netværket, grænser pr. IP i reverse proxyen, token buckets pr. konto og pr. identitet i API-gatewayen og domænegrænser inde i tjenesterne. Grænserne står i API-oversigten.

Revision

Hver ændring skrives til en revisionslog, der kun kan tilføjes til og er hash-kædet, med to opbevaringsklasser: generelle hændelser og compliancehændelser (anmodninger fra registrerede, brud, underdatabehandlere og KYC-poster). Klassen tildeles, når en post skrives; ingen kan redigere eller slette loggen, og en automatisk oprydning efter klasse er endnu ikke i drift. Ejere og administratorer kan filtrere og eksportere den. Adgangskoder, tokens og nøgler logges aldrig; logningslaget skjuler kendte følsomme nøgler.

Databeskyttelse

• Anmodninger fra registrerede efter GDPR, UK GDPR, CCPA og LGPD (indsigt, eksport, sletning) modtages og følges i compliancekonsollen med frister. Sletning udføres af RolChats medarbejdere, og anmodningen lukkes først, når de bekræfter den; en automatisk sletning på tværs af alle moduler er endnu ikke tilgængelig.
• Dataplacering: data lagres i EU. Regionen vælges ikke efter land ved oprettelsen; regionsindstillingen i kontoindstillingerne registreres kun og flytter endnu ikke data.
• Opbevaring efter plan: 1, 2 eller 3 år. Sletning af en samtale eller en kontakt skjuler den til udgangen af den periode; sletning af en konto er en anmodning med 30 dages fortrydelsesfrist, hvorefter medarbejdere sletter dataene; en ubetalt konto opbevares i 90 dage og slettes derefter. Den automatiske oprydning, der håndhæver disse frister, er under udrulning.
• En databehandleraftale, en liste over underdatabehandlere, en privatlivspolitik og en cookiepolitik er offentliggjort på rolchat.com; databehandleraftalen accepteres ved tilmeldingen.
• Underretning om brud inden for 72 timer som krævet i GDPR artikel 33.

Sårbarhedsstyring

Afhængigheder overvåges løbende; lock-filer committes; basisbilleder fastlåses via digest; CI-handlinger fastlåses via commit. En penetrationstest udført af en tredjepart planlægges årligt fra og med beta og dækker API’et, widgetten og de offentlige sider plus et internt scenarie med antaget brud. Et privat bug bounty-program følger ved generel tilgængelighed. Rapportér sikkerhedsproblemer til security@rolchat.com.

Tilgængelighed

Platformen kører på flere noder med automatisk failover for tilstandsløse tjenester og administreret replikering for databaser. Oppetidsmål pr. plan fremgår af din aftale.

Håndtering af hændelser

Runbooks for hver tjeneste, en vagtordning, en ekstern alarmtjeneste, der virker, når vores egen infrastruktur ikke gør, og forpligtelser til at underrette kunder indbygget i processen.