Säkerhet och regelefterlevnad

Autentisering

• Åtkomsttokens är kortlivade JWT:er (15 minuter) som verifieras i API-gatewayen; förnyelsetokens lever 30 dagar vid inaktivitet och högst 90 dagar, roteras vid varje användning och lagras i en HttpOnly-, Secure- och SameSite-cookie. Återanvändning av en roterad förnyelsetoken återkallar hela kedjan.
• Signeringsnycklar roteras var 90:e dag med överlapp; publika nycklar publiceras på /.well-known/jwks.json.
• Behörigheter bäddas inte in i tokens: de läses vid varje förfrågan, så en rolländring gäller omedelbart och varje session kan återkallas centralt.
• Tvåfaktorsautentisering (TOTP) kan vara valfri, krävas för ägare och administratörer eller krävas för alla. Enkel inloggning med Google Workspace och Apple finns i alla planer. SAML 2.0, passkeys och SCIM-provisionering är planerade och finns ännu inte.
• API-nycklar visas en gång, lagras som en SHA-256-hash, avgränsas utifrån en sluten katalog, begränsas av ägarens behörigheter och kan återkallas omedelbart. Se Autentisering.
• Inloggning är hastighetsbegränsad per IP-adress och per e-postadress; tio misslyckade försök låser kontot i 30 minuter; misslyckade försök från en IP-adress räknas och registreras, men blockerar som standard inte den adressen. Varje inloggning, misslyckande, förnyelse, behörighetsändring och administratörsåtgärd hamnar i granskningsloggen.

Klientisolering

Varje rad i varje tjänst anger vilket konto den tillhör, och varje fråga filtreras automatiskt på det; att stänga av filtret kräver ett uttryckligt anrop på en tillåtelselista som bara används av personalens åtgärder över flera kunder och som täcks av tester. Roller per webbplats lägger till ett webbplatsfilter ovanpå. En förfrågan efter ett annat kontos resurs svarar 404, aldrig 403, så att ID:n inte kan räknas upp. Varje skrivande endpoint använder en strikt tillåtelselista för fält. Ett test av åtkomst mellan konton är obligatoriskt för varje ny endpoint.

Headern X-Account-Id i varje förfrågan kontrolleras mot tokenen, så att en bugg i klienten eller en återuppspelad token aldrig i tysthet kan läsa en annan kunds data.

Kryptering

TLS 1.2 eller nyare till varje publik endpoint, ömsesidig TLS mellan tjänster, TLS till varje datalager, krypterade volymer i vila och kuvertkryptering per konto för känsliga fält. Publika certifikat utfärdas och förnyas automatiskt; interna certifikat är kortlivade.

Hemligheter

Alla hemligheter, inklusive dina BYOK-leverantörsnycklar och webhook-hemligheter, finns i en särskild hemlighetshanterare, krypterade, avgränsade per tjänst och granskade. Inget finns i versionshanteringen (upprätthålls genom skanning före varje commit) eller i containeravbildningar (kontrolleras i CI). Utvecklare har som standard ingen åtkomst till hemligheter i produktion; nödåtkomst kräver två godkännanden, är kortlivad och loggas i en kanal som inte kan tystas.

Webhooks

Utgående leveranser signeras med HMAC-SHA256 över tidsstämpeln och den råa bodyn, har en nonce och ett händelse-ID, avvisas utanför ett fönster på fem minuter och görs om med backoff till en kö för döda meddelanden. Hemligheter roteras med ett överlappsfönster och kan återkallas omedelbart. Inkommande webhooks från leverantörer verifieras enligt respektive leverantörs metod innan något bearbetas. Detaljer: Webhooks.

Hastighetsbegränsning

Fyra lager: skydd mot DDoS och botar i kantnätverket, gränser per IP-adress i den omvända proxyn, tokenhinkar per konto och per identitet i API-gatewayen samt domängränser inuti tjänsterna. Gränserna finns i API-översikten.

Granskning

Varje ändring skrivs till en granskningslogg som bara kan utökas och är hashkedjad, med två lagringsklasser: allmänna händelser och efterlevnadshändelser (förfrågningar från registrerade, incidenter, underbiträden och KYC-poster). Klassen tilldelas när en post skrivs; loggen kan inte redigeras eller raderas av någon, och en automatisk rensning per klass är ännu inte i drift. Ägare och administratörer kan filtrera och exportera den. Lösenord, tokens och nycklar loggas aldrig; loggningslagret maskerar kända känsliga nycklar.

Dataskydd

• Förfrågningar från registrerade enligt GDPR, brittiska GDPR, CCPA och LGPD (åtkomst, export, radering) tas emot och spåras i efterlevnadskonsolen med tidsfrister. Radering utförs av RolChats personal, och ärendet avslutas först när de bekräftar det; en automatisk radering i alla moduler finns ännu inte.
• Dataplacering: data lagras i EU. Regionen väljs inte efter land vid registreringen; regioninställningen i kontoinställningarna sparas bara och flyttar ännu inga data.
• Lagring enligt plan: 1, 2 eller 3 år. En raderad konversation eller kontakt döljs till slutet av den perioden; radering av ett konto är en begäran med 30 dagar för att ångra sig, därefter raderar personalen data; ett obetalt konto behålls i 90 dagar och raderas sedan. Den automatiska rensningen som upprätthåller dessa perioder håller på att införas.
• Ett personuppgiftsbiträdesavtal (DPA), en lista över underbiträden, en integritetspolicy och en cookiepolicy publiceras på rolchat.com; DPA:n godkänns vid registreringen.
• Anmälan om personuppgiftsincidenter inom 72 timmar enligt artikel 33 i GDPR.

Sårbarhetshantering

Beroenden övervakas kontinuerligt; låsfiler checkas in; basavbildningar låses via digest; CI-åtgärder låses via commit. Ett penetrationstest av tredje part schemaläggs årligen från betan och omfattar API:et, widgeten och de publika sidorna samt ett internt scenario med antaget intrång. Ett privat bugg-bountyprogram följer vid allmän tillgänglighet. Rapportera säkerhetsproblem till security@rolchat.com.

Tillgänglighet

Plattformen körs på flera noder med automatisk reservväxling för tillståndslösa tjänster och hanterad replikering för databaser. Mål för drifttid per plan anges i ditt avtal.

Incidenthantering

Driftsinstruktioner för varje tjänst, ett jourschema, en extern personsökare som fungerar när vår egen infrastruktur inte gör det och skyldigheter att underrätta kunder inbyggda i processen.