Sicurezza e conformità

Autenticazione

• Gli access token sono JWT di breve durata (15 minuti), verificati sul gateway API; i refresh token durano 30 giorni di inattività e al massimo 90 giorni, ruotano a ogni utilizzo e sono conservati in un cookie HttpOnly, Secure, SameSite. Il riutilizzo di un refresh token già ruotato revoca l’intera catena.
• Le chiavi di firma ruotano ogni 90 giorni con un periodo di sovrapposizione; le chiavi pubbliche sono pubblicate su /.well-known/jwks.json.
• I permessi non sono incorporati nei token: vengono letti a ogni richiesta, quindi un cambio di ruolo ha effetto immediato e qualsiasi sessione può essere revocata centralmente.
• L’autenticazione a due fattori (TOTP) può essere facoltativa, obbligatoria per Proprietari e Amministratori oppure obbligatoria per tutti. Il single sign-on con Google Workspace e Apple è disponibile in ogni piano. SAML 2.0, passkey e provisioning SCIM sono pianificati e non ancora disponibili.
• Le chiavi API vengono mostrate una sola volta, conservate come hash SHA-256, con scope scelti da un catalogo chiuso, limitate dai permessi del proprietario e revocabili all’istante. Vedi Autenticazione.
• L’accesso è soggetto a limiti per IP e per email; dieci tentativi falliti bloccano l’account per 30 minuti; i tentativi falliti da uno stesso indirizzo IP vengono conteggiati e registrati, ma per impostazione predefinita non bloccano quell’indirizzo. Ogni accesso, errore, refresh, cambio di permessi e azione amministrativa finisce nel log di audit.

Isolamento dei tenant

Ogni riga in ogni servizio riporta l’account a cui appartiene, e ogni query viene filtrata automaticamente in base a esso; disattivare il filtro richiede una chiamata esplicita e in allow-list, usata solo dalle operazioni dello staff tra tenant e coperta da test. I ruoli per sito aggiungono un filtro per sito. Una richiesta per una risorsa di un altro account risponde 404, mai 403, così gli ID non possono essere enumerati. Ogni endpoint di scrittura usa una allow-list rigida dei campi. Un test di accesso tra account è obbligatorio per ogni nuovo endpoint.

L’intestazione X-Account-Id in ogni richiesta viene confrontata con il token, così un bug del client o un token riutilizzato non possono mai leggere in silenzio i dati di un altro tenant.

Cifratura

TLS 1.2 o superiore verso ogni endpoint pubblico, mutual TLS tra i servizi, TLS verso ogni datastore, volumi cifrati a riposo e cifratura envelope per account per i campi sensibili. I certificati pubblici vengono emessi e rinnovati automaticamente; i certificati interni hanno breve durata.

Segreti

Tutti i segreti, comprese le tue chiavi dei provider BYOK e i segreti dei webhook, si trovano in un secrets manager dedicato, cifrati, limitati per servizio e sottoposti ad audit. Nulla finisce nel controllo di versione (imposto tramite una scansione prima di ogni commit) né nelle immagini dei container (verificato in CI). Gli sviluppatori non hanno accesso ai segreti di produzione per impostazione predefinita; l’accesso di emergenza richiede due approvazioni, ha breve durata e viene registrato in un canale che non può essere silenziato.

Webhook

Le consegne in uscita sono firmate con HMAC-SHA256 su timestamp e corpo grezzo, riportano un nonce e un ID evento, vengono rifiutate fuori da una finestra di cinque minuti e vengono ritentate con backoff fino a una dead-letter queue. I segreti ruotano con una finestra di sovrapposizione e possono essere revocati all’istante. I webhook in entrata dei provider vengono verificati con lo schema di ciascun provider prima di qualsiasi elaborazione. Dettagli: Webhook.

Limiti di frequenza

Quattro livelli: protezione DDoS e anti-bot sulla rete edge, limiti per IP sul reverse proxy, token bucket per account e per identità sul gateway API e limiti di dominio all’interno dei servizi. I limiti sono riportati nella panoramica dell’API.

Audit

Ogni modifica viene scritta in un log di audit append-only con catena di hash e due classi di conservazione: eventi generali ed eventi di conformità (richieste degli interessati, violazioni, sub-responsabili e registrazioni KYC). La classe viene assegnata al momento della scrittura; nessuno può modificare o eliminare il log, e una pulizia automatica per classe non è ancora attiva. Proprietari e Amministratori possono filtrarlo ed esportarlo. Password, token e chiavi non vengono mai registrati; il livello di logging oscura le chiavi note come sensibili.

Protezione dei dati

• Le richieste degli interessati ai sensi di GDPR, UK GDPR, CCPA e LGPD (accesso, esportazione, cancellazione) vengono ricevute e monitorate con le relative scadenze nella console di conformità. La cancellazione è eseguita dal personale di RolChat e la richiesta si chiude solo dopo la loro conferma; una cancellazione automatica in tutti i moduli non è ancora disponibile.
• Residenza dei dati: i dati sono conservati nell’UE. La regione non viene scelta in base al paese in fase di registrazione; l’impostazione della regione nelle impostazioni dell’account viene solo registrata e per ora non sposta i dati.
• Conservazione in base al piano: 1, 2 o 3 anni. Eliminare una conversazione o un contatto lo nasconde fino alla fine di quel periodo; eliminare un account è una richiesta con 30 giorni per annullarla, dopodiché il personale cancella i dati; un account non pagato viene conservato 90 giorni e poi cancellato. La pulizia automatica che fa rispettare questi termini è in fase di introduzione.
• Un Accordo sul trattamento dei dati, l’elenco dei sub-responsabili, l’informativa sulla privacy e la cookie policy sono pubblicati su rolchat.com; il DPA si accetta alla registrazione.
• Notifica delle violazioni entro 72 ore, come richiesto dall’articolo 33 del GDPR.

Gestione delle vulnerabilità

Le dipendenze sono monitorate di continuo; i lock file vengono committati; le immagini di base sono fissate tramite digest; le azioni CI sono fissate tramite commit. Un penetration test di terze parti è previsto ogni anno a partire dalla beta, e copre l’API, il widget e le pagine pubbliche, oltre a uno scenario interno di violazione presunta. Un bug bounty privato seguirà alla disponibilità generale. Segnala i problemi di sicurezza a security@rolchat.com.

Disponibilità

La piattaforma gira su più nodi con failover automatico per i servizi stateless e replica gestita per i database. Gli obiettivi di uptime per piano sono indicati nel tuo contratto.

Risposta agli incidenti

Runbook per ogni servizio, una rotazione di reperibilità, un sistema di allerta esterno che funziona anche quando la nostra infrastruttura non funziona, e obblighi di notifica ai clienti integrati nel processo.