Sikkerhet og samsvar

Autentisering

• Tilgangstokener er kortlivede JWT-er (15 minutter), verifisert i API-gatewayen; fornyelsestokener lever i 30 dager ved inaktivitet og maksimalt 90 dager, roteres ved hver bruk og lagres i en HttpOnly-, Secure- og SameSite-informasjonskapsel. Gjenbruk av et rotert fornyelsestoken tilbakekaller hele kjeden.
• Signeringsnøkler roteres hver 90. dag med overlapp; offentlige nøkler publiseres på /.well-known/jwks.json.
• Tillatelser bygges ikke inn i tokener: de leses ved hver forespørsel, så en rolleendring trer i kraft umiddelbart, og enhver økt kan tilbakekalles sentralt.
• Tofaktorautentisering (TOTP) kan være valgfri, påkrevd for eiere og administratorer eller påkrevd for alle. Enkel pålogging med Google Workspace og Apple er tilgjengelig i alle abonnementer. SAML 2.0, passnøkler og SCIM-klargjøring er planlagt og ikke tilgjengelig ennå.
• API-nøkler vises én gang, lagres som en SHA-256-hash, får tilgangsomfang fra en lukket katalog, begrenses av eierens tillatelser og kan tilbakekalles umiddelbart. Se Autentisering.
• Innlogging er hastighetsbegrenset per IP og per e-postadresse; ti mislykkede forsøk låser kontoen i 30 minutter; mislykkede forsøk fra én IP-adresse telles og registreres, men som standard blokkeres ikke den adressen. Hver innlogging, feil, fornyelse, endring av tillatelser og administratorhandling går til revisjonsloggen.

Kundeisolering

Hver rad i hver tjeneste angir kontoen den tilhører, og hver spørring filtreres automatisk på den; å slå av filteret krever et eksplisitt kall fra en tillatelsesliste, som bare brukes av RolChat-ansattes operasjoner på tvers av kunder og er dekket av tester. Roller per nettsted legger til et nettstedsfilter i tillegg. En forespørsel om en annen kontos ressurs svarer 404, aldri 403, slik at ID-er ikke kan listes opp. Hvert skriveendepunkt bruker en streng tillatelsesliste over felt. En test av tilgang på tvers av kontoer er obligatorisk for hvert nytt endepunkt.

Headeren X-Account-Id i hver forespørsel kontrolleres mot tokenet, så en klientfeil eller et gjenbrukt token kan aldri lese en annen kundes data i det stille.

Kryptering

TLS 1.2 eller nyere til alle offentlige endepunkter, gjensidig TLS mellom tjenester, TLS til alle datalagre, krypterte volumer for lagrede data og konvoluttkryptering per konto for sensitive felt. Offentlige sertifikater utstedes og fornyes automatisk; interne sertifikater er kortlivede.

Hemmeligheter

Alle hemmeligheter, inkludert BYOK-leverandørnøklene dine og webhook-hemmeligheter, ligger i en egen hemmelighetsbehandler, kryptert, avgrenset per tjeneste og revidert. Ingenting ligger i kildekodekontrollen (håndheves med skanning før hver commit) eller i containerbilder (kontrolleres i CI). Utviklere har som standard ikke tilgang til hemmeligheter i produksjon; nødtilgang krever to godkjenninger, er kortvarig og logges til en kanal som ikke kan dempes.

Webhooks

Utgående leveranser signeres med HMAC-SHA256 over tidsstempelet og den rå bodyen, har en nonce og en hendelses-ID, avvises utenfor et vindu på fem minutter og prøves på nytt med backoff inn i en dead-letter-kø. Hemmeligheter roteres med et overlappingsvindu og kan tilbakekalles umiddelbart. Innkommende webhooks fra leverandører verifiseres etter hver leverandørs ordning før noe behandles. Detaljer: Webhooks.

Hastighetsbegrensning

Fire lag: DDoS- og botbeskyttelse i kantnettverket, grenser per IP i den omvendte proxyen, token-bøtter per konto og per identitet i API-gatewayen, og domenegrenser inne i tjenestene. Grensene står i API-oversikten.

Revisjon

Hver endring skrives til en revisjonslogg som bare kan utvides og er hash-kjedet, med to lagringsklasser: generelle hendelser og samsvarshendelser (forespørsler fra registrerte, brudd, underleverandører og KYC-poster). Klassen settes når posten skrives; loggen kan ikke redigeres eller slettes av noen, og automatisk opprydding per klasse er ikke på plass ennå. Eiere og administratorer kan filtrere og eksportere den. Passord, tokener og nøkler logges aldri; logglaget maskerer kjente sensitive nøkler.

Databeskyttelse

• Forespørsler fra registrerte etter GDPR, britisk GDPR, CCPA og LGPD (innsyn, eksport, sletting) mottas og følges opp i samsvarskonsollen med frister. Slettingen utføres av RolChat-ansatte, og forespørselen lukkes først når de har bekreftet den; automatisk sletting på tvers av alle moduler er ikke tilgjengelig ennå.
• Dataplassering: data lagres i EU. Regionen velges ikke etter land ved registrering; regioninnstillingen i kontoinnstillingene blir bare registrert og flytter ikke data ennå.
• Lagring etter abonnement: 1, 2 eller 3 år. Når en samtale eller en kontakt slettes, skjules den til utløpet av denne perioden; sletting av en konto er en forespørsel med 30 dagers angrefrist, deretter sletter de ansatte dataene; en ubetalt konto beholdes i 90 dager og slettes deretter. Den automatiske oppryddingen som sikrer disse fristene, er under utrulling.
• En databehandleravtale, en liste over underdatabehandlere, en personvernerklæring og en erklæring om informasjonskapsler er publisert på rolchat.com; databehandleravtalen godtas ved registrering.
• Varsling om brudd innen 72 timer, slik GDPR artikkel 33 krever.

Sårbarhetshåndtering

Avhengigheter overvåkes kontinuerlig; låsefiler committes; basisbilder festes med digest; CI-handlinger festes med commit. En penetrasjonstest fra tredjepart er planlagt årlig fra beta, og dekker API-et, widgeten og de offentlige sidene, pluss et internt scenario med antatt innbrudd. Et privat bug bounty-program følger ved generell tilgjengelighet. Rapporter sikkerhetsproblemer til security@rolchat.com.

Tilgjengelighet

Plattformen kjører på flere noder med automatisk failover for tilstandsløse tjenester og administrert replikering for databaser. Oppetidsmål per abonnement er fastsatt i avtalen din.

Hendelseshåndtering

Driftshåndbøker for hver tjeneste, en vaktordning, en ekstern personsøker som fungerer når vår egen infrastruktur ikke gjør det, og forpliktelser til å varsle kunder som er bygd inn i prosessen.