Seguridad at compliance

Authentication

• Ang mga access token ay mga panandaliang JWT (15 minuto), bine-verify sa API gateway; tumatagal ang mga refresh token nang 30 araw kapag idle at 90 araw nang pinakamatagal, nire-rotate sa bawat paggamit, at iniimbak sa HttpOnly, Secure, SameSite na cookie. Ang muling paggamit ng na-rotate na refresh token ay nagre-revoke sa buong chain.
• Nire-rotate ang mga signing key bawat 90 araw nang may overlap; ina-publish ang mga public key sa /.well-known/jwks.json.
• Hindi naka-embed sa mga token ang mga pahintulot: binabasa ang mga ito kada request, kaya agad na umiiral ang pagbabago ng role, at puwedeng i-revoke nang sentral ang anumang session.
• Puwedeng opsyonal ang two-factor authentication (TOTP), required para sa mga Owner at Admin, o required para sa lahat. Available sa bawat plan ang single sign-on gamit ang Google Workspace at Apple. Nakaplano ang SAML 2.0, mga passkey at SCIM provisioning, at hindi pa available ang mga ito.
• Isang beses lang ipinapakita ang mga API key, iniimbak bilang SHA-256 hash, naka-scope mula sa saradong katalogo, limitado ng mga pahintulot ng may-ari nito, at agad na nare-revoke. Tingnan ang Authentication.
• May rate limit ang pag-sign in kada IP at kada e-mail; sampung bigong pagtatangka ang nagla-lock sa account nang 30 minuto; ang mga bigong pagtatangka mula sa iisang IP address ay binibilang at itinatala, pero bilang default ay hindi nito binabara ang address na iyon. Napupunta sa audit log ang bawat pag-sign in, pagkabigo, refresh, pagbabago ng pahintulot at aksyon ng admin.

Paghihiwalay ng tenant

Dala ng bawat row sa bawat serbisyo ang account na kinabibilangan nito, at awtomatikong fina-filter dito ang bawat query; ang pag-off ng filter ay nangangailangan ng hayag na tawag na nasa allow-list, na ginagamit lang ng mga cross-tenant na operasyon ng staff at saklaw ng mga test. Nagdadagdag ng site filter sa ibabaw nito ang mga role kada site. Ang request para sa resource ng ibang account ay sumasagot ng 404, hindi kailanman 403, para hindi mabilang-bilang ang mga ID. Gumagamit ang bawat write endpoint ng mahigpit na allow-list ng field. Mandatory ang cross-account na access test para sa bawat bagong endpoint.

Sinusuri laban sa token ang header na X-Account-Id sa bawat request, kaya hindi kailanman tahimik na makakabasa ng ibang tenant ang bug sa client o ang na-replay na token.

Encryption

TLS 1.2 o mas bago sa bawat pampublikong endpoint, mutual TLS sa pagitan ng mga serbisyo, TLS sa bawat datastore, mga naka-encrypt na volume at rest, at envelope encryption kada account para sa mga sensitibong field. Awtomatikong ibinibigay at nire-renew ang mga pampublikong certificate; panandalian ang mga internal na certificate.

Mga secret

Lahat ng secret, kasama ang mga BYOK provider key at webhook secret mo, ay nasa nakalaang secrets manager, naka-encrypt, naka-scope kada serbisyo, at naa-audit. Walang nasa source control (ipinapatupad sa pamamagitan ng scanning bago ang bawat commit) o sa mga container image (sinusuri sa CI). Walang access sa production secret ang mga developer bilang default; ang break-glass na access ay nangangailangan ng dalawang pag-apruba, panandalian at nila-log sa channel na hindi mapapatahimik.

Mga webhook

Naka-sign ang mga palabas na delivery gamit ang HMAC-SHA256 sa timestamp at raw body, may dalang nonce at event ID, tinatanggihan kapag lampas sa limang minutong window, at nire-retry nang may backoff papunta sa dead-letter queue. Nire-rotate ang mga secret nang may overlap window at puwedeng i-revoke agad. Bine-verify ang mga papasok na webhook ng provider gamit ang scheme ng bawat provider bago iproseso ang kahit ano. Mga detalye: Mga webhook.

Rate limiting

Apat na layer: proteksyon laban sa DDoS at bot sa edge network, mga limitasyon kada IP sa reverse proxy, mga token bucket kada account at kada pagkakakilanlan sa API gateway, at mga limitasyon ng domain sa loob ng mga serbisyo. Nasa pangkalahatang-ideya ng API ang mga limitasyon.

Audit

Isinusulat ang bawat mutation sa append-only at hash-chained na audit log na may dalawang retention class: mga pangkalahatang event at mga compliance event (mga data-subject request, breach, sub-processor at KYC record). Itinatakda ang class kapag isinulat ang entry; walang makapag-eedit o makakabura sa log, at wala pang awtomatikong paglilinis ayon sa class. Puwedeng i-filter at i-export ito ng mga Owner at Admin. Hindi kailanman nila-log ang mga password, token at key; nire-redact ng logging layer ang mga kilalang sensitibong key.

Proteksyon ng data

• Natatanggap at sinusubaybayan sa compliance console, kasama ang mga deadline, ang mga data-subject request sa ilalim ng GDPR, UK GDPR, CCPA at LGPD (access, export, pagbura). Ang pagbura ay ginagawa ng mga tauhan ng RolChat, at isinasara lang ang request kapag kinumpirma nila ito; wala pang awtomatikong pagbura sa bawat module.
• Lokasyon ng data: ang data ay iniimbak sa EU. Hindi pinipili ang rehiyon ayon sa bansa sa pag-sign up; ang setting ng rehiyon sa mga setting ng account ay itinatala lamang at hindi pa naglilipat ng data.
• Retention ayon sa plan: 1, 2 o 3 taon. Ang binurang conversation o contact ay itinatago hanggang matapos ang terminong iyon; ang pagbura ng account ay isang request na may 30 araw para magkansela, pagkatapos ay buburahin ng mga tauhan ang data; ang account na hindi nabayaran ay iniimbak nang 90 araw at saka binubura. Inilulunsad pa ang awtomatikong paglilinis na nagpapatupad ng mga terminong ito.
• Naka-publish sa rolchat.com ang Data Processing Agreement, listahan ng mga sub-processor, privacy policy at cookie policy; tinatanggap ang DPA sa pag-sign up.
• Abiso sa breach sa loob ng 72 oras gaya ng hinihingi ng GDPR Article 33.

Pamamahala ng vulnerability

Tuloy-tuloy na mino-monitor ang mga dependency; kino-commit ang mga lock file; naka-pin ayon sa digest ang mga base image; naka-pin ayon sa commit ang mga CI action. Nakaiskedyul taon-taon mula sa beta ang penetration test ng third party, na sumasaklaw sa API, sa widget at sa mga pampublikong pahina, kasama ang internal na senaryong assumed-breach. Susunod ang pribadong bug bounty sa general availability. Iulat ang mga isyu sa seguridad sa security@rolchat.com.

Availability

Tumatakbo ang platform sa maraming node na may automated na failover para sa mga stateless na serbisyo at managed na replication para sa mga database. Nakasaad sa kasunduan mo ang mga target na uptime ayon sa plan.

Pagtugon sa insidente

Mga runbook para sa bawat serbisyo, on-call rotation, panlabas na pager na gumagana kahit hindi gumagana ang sarili naming imprastraktura, at mga obligasyon sa pag-abiso sa customer na nakapaloob sa proseso.