Securitate și conformitate

Autentificare

• Tokenurile de acces sunt JWT-uri de scurtă durată (15 minute), verificate la gateway-ul API; tokenurile de reîmprospătare sunt valabile 30 de zile de inactivitate și cel mult 90 de zile, se rotesc la fiecare utilizare și sunt stocate într-un cookie HttpOnly, Secure, SameSite. Reutilizarea unui token de reîmprospătare deja rotit revocă întregul lanț.
• Cheile de semnare se rotesc la fiecare 90 de zile, cu o perioadă de suprapunere; cheile publice sunt publicate la /.well-known/jwks.json.
• Permisiunile nu sunt incluse în tokenuri: sunt citite la fiecare cerere, așa că o schimbare de rol are efect imediat, iar orice sesiune poate fi revocată centralizat.
• Autentificarea în doi pași (TOTP) poate fi opțională, obligatorie pentru Proprietari și Admini sau obligatorie pentru toți. Autentificarea unică cu Google Workspace și Apple este disponibilă în toate planurile. SAML 2.0, passkey-urile și provizionarea SCIM sunt planificate și încă indisponibile.
• Cheile API sunt afișate o singură dată, stocate ca hash SHA-256, limitate la domenii dintr-un catalog închis, mărginite de permisiunile proprietarului lor și pot fi revocate instantaneu. Vezi Autentificare.
• Autentificarea are limite de rată per IP și per e-mail; zece încercări eșuate blochează contul timp de 30 de minute; încercările eșuate de la o adresă IP sunt numărate și înregistrate, dar implicit nu blochează acea adresă. Fiecare autentificare, eșec, reîmprospătare, schimbare de permisiuni și acțiune administrativă ajunge în jurnalul de audit.

Izolarea chiriașilor

Fiecare rând din fiecare serviciu poartă contul căruia îi aparține, iar fiecare interogare este filtrată automat după acesta; dezactivarea filtrului necesită un apel explicit, aflat pe o listă de permisiuni, folosit doar de operațiunile interne între chiriași și acoperit de teste. Rolurile per site adaugă în plus un filtru de site. O cerere pentru resursa altui cont primește răspunsul 404, niciodată 403, pentru ca ID-urile să nu poată fi enumerate. Fiecare endpoint de scriere folosește o listă strictă de câmpuri permise. Un test de acces între conturi este obligatoriu pentru fiecare endpoint nou.

Antetul X-Account-Id din fiecare cerere este comparat cu tokenul, așa că o eroare de client sau un token reutilizat nu pot citi niciodată pe tăcute datele altui chiriaș.

Criptare

TLS 1.2 sau mai nou către fiecare endpoint public, TLS mutual între servicii, TLS către fiecare depozit de date, volume criptate în repaus și criptare de tip envelope per cont pentru câmpurile sensibile. Certificatele publice sunt emise și reînnoite automat; certificatele interne au o durată de viață scurtă.

Secrete

Toate secretele, inclusiv cheile tale de furnizor BYOK și secretele webhook-urilor, se află într-un manager de secrete dedicat, criptate, izolate per serviciu și auditate. Nimic nu se află în controlul versiunilor (verificat prin scanare înainte de fiecare commit) sau în imaginile de containere (verificat în CI). Implicit, dezvoltatorii nu au acces la secretele de producție; accesul de urgență necesită două aprobări, este de scurtă durată și este înregistrat într-un canal care nu poate fi redus la tăcere.

Webhook-uri

Livrările către exterior sunt semnate cu HMAC-SHA256 peste marcajul de timp și corpul brut, conțin un nonce și un ID de eveniment, sunt respinse în afara unei ferestre de cinci minute și sunt reîncercate cu intervale crescătoare până într-o coadă de mesaje nelivrate. Secretele se rotesc cu o perioadă de suprapunere și pot fi revocate instantaneu. Webhook-urile primite de la furnizori sunt verificate după schema fiecărui furnizor înainte de orice procesare. Detalii: Webhook-uri.

Limitarea ratei

Patru niveluri: protecție împotriva DDoS și a boților la nivelul rețelei edge, limite per IP la reverse proxy, token bucket-uri per cont și per identitate la gateway-ul API și limite de domeniu în interiorul serviciilor. Limitele sunt descrise în prezentarea generală a API.

Audit

Fiecare modificare este scrisă într-un jurnal de audit în care se poate doar adăuga, înlănțuit prin hash, cu două clase de păstrare: evenimente generale și evenimente de conformitate (cereri ale persoanelor vizate, breșe, subprocesatori și înregistrări KYC). Clasa se atribuie la scrierea intrării; nimeni nu poate edita sau șterge jurnalul, iar curățarea automată pe clase încă nu funcționează. Proprietarii și Adminii îl pot filtra și exporta. Parolele, tokenurile și cheile nu sunt niciodată înregistrate; stratul de jurnalizare maschează cheile cunoscute ca sensibile.

Protecția datelor

• Cererile persoanelor vizate conform GDPR, UK GDPR, CCPA și LGPD (acces, export, ștergere) sunt primite și urmărite în consola de conformitate, cu termene. Ștergerea este făcută de personalul RolChat, iar cererea se închide doar după confirmarea lui; o ștergere automată în toate modulele încă nu există.
• Locația datelor: datele sunt stocate în UE. Regiunea nu se alege după țară la înregistrare; setarea de regiune din setările contului este doar înregistrată și nu mută încă datele.
• Păstrare în funcție de plan: 1, 2 sau 3 ani. Ștergerea unei conversații sau a unui contact îl ascunde până la sfârșitul acestui termen; ștergerea unui cont este o cerere cu 30 de zile pentru anulare, după care personalul șterge datele; un cont neplătit este păstrat 90 de zile și apoi șters. Curățarea automată care impune aceste termene este în curs de lansare.
• Acordul de prelucrare a datelor, lista subprocesatorilor, politica de confidențialitate și politica privind cookie-urile sunt publicate pe rolchat.com; Acordul de prelucrare a datelor este acceptat la înscriere.
• Notificarea încălcărilor securității datelor în 72 de ore, conform articolului 33 din GDPR.

Gestionarea vulnerabilităților

Dependențele sunt monitorizate continuu; fișierele lock sunt incluse în depozit; imaginile de bază sunt fixate prin digest; acțiunile CI sunt fixate prin commit. Un test de penetrare realizat de o terță parte este programat anual începând cu versiunea beta și acoperă API-ul, widgetul și paginile publice, plus un scenariu intern de compromitere presupusă. Un program privat de bug bounty va urma odată cu disponibilitatea generală. Raportează problemele de securitate la security@rolchat.com.

Disponibilitate

Platforma rulează pe mai multe noduri, cu failover automat pentru serviciile fără stare și replicare gestionată pentru bazele de date. Obiectivele de disponibilitate per plan sunt stabilite în contractul tău.

Răspunsul la incidente

Proceduri operaționale pentru fiecare serviciu, o rotație de gardă, un sistem extern de alertare care funcționează și atunci când propria noastră infrastructură nu funcționează, precum și obligații de notificare a clienților integrate în proces.