Come Spun crittografa i tuoi dati, dalla crittografia di WhatsApp alle chiamate di gruppo
Dettagli onesti, scenario per scenario, sulla crittografia di WhatsApp, sulle chiamate e sui dati archiviati: cosa è crittografato end-to-end, cosa è crittografato solo in transito e cosa deve essere leggibile da Spun perché il prodotto funzioni.
In sintesi
Crittografia per scenario
Qui sotto trovi ogni tipo di dato che Spun gestisce e come esattamente è protetto. Contrassegniamo E2EE con Sì solo quando nessun sistema di Spun può leggerne il contenuto.
| Scenario | E2EE | Note |
|---|---|---|
Chiamata vocale 1:1 (Spun → Spun) DTLS-SRTP (WebRTC) | Sì | WebRTC puramente peer-to-peer. Le chiavi vengono negoziate tra i due endpoint: Spun non le possiede mai. |
Videochiamata 1:1 (Spun → Spun) DTLS-SRTP (WebRTC) | Sì | Come per le chiamate vocali. I relay TURN vedono solo pacchetti crittografati quando la connessione P2P diretta non riesce. |
Chiamata di gruppo (3 o più partecipanti) TLS 1.2+ verso la SFU, DTLS-SRTP per i media | No | La SFU di LiveKit Cloud decrittografa i media per instradarli agli altri partecipanti. È l'architettura standard di una SFU. |
Stanza di traduzione (modalità P2P, al massimo 2 partecipanti) DTLS-SRTP (WebRTC) | Sì | Passa alla SFU se entra un terzo partecipante (vedi la riga sopra). |
Stanza di traduzione (modalità SFU, 3 o più partecipanti) TLS 1.2+ verso la SFU | No | La SFU di LiveKit ha accesso ai media per tradurli e rimixarli. |
Messaggi WhatsApp (all'interno di WhatsApp) Signal Protocol (Meta) | Parziale | WhatsApp stesso è crittografato end-to-end tra i partecipanti. Ma una volta che il tuo fornitore di gateway riceve per tuo conto i messaggi in arrivo, il gateway e Spun vedono il testo in chiaro: è così che funziona la posta in arrivo. |
Messaggi WhatsApp (in Spun) TLS 1.2+ | No | Necessario per la visualizzazione nella posta in arrivo, la ricerca, le funzioni di IA e le automazioni. |
Spun Chat e messaggi del team TLS 1.2+ | No | In chiaro a riposo, così i messaggi sono ricercabili e possono essere elaborati dalle funzioni di IA che attivi. |
Allegati multimediali (immagini, video, documenti) TLS 1.2+ (Cloudflare R2 + S3 SigV4) | No | R2 gestisce le chiavi. Spun firma URL a breve scadenza per controllare l'accesso per organizzazione. |
Dati delle carte di pagamento TLS 1.2+ direttamente verso Stripe | Parziale | Stripe Elements raccoglie i dati della carta direttamente nel browser: non raggiungono mai i server di Spun. Riceviamo solo un ID cliente opaco. |
Prompt e risultati dell'IA TLS 1.2+ verso il fornitore di IA | No | Inviati tramite TLS a OpenAI / AssemblyAI / ecc. L'oscuramento dei dati personali (PII), quando è attivo, rimuove i campi sensibili prima della trasmissione. |
Backup del database TLS 1.2+ | No | Crittografia standard dei backup gestiti. |
E2EE = crittografato end-to-end. “Sì” significa che nemmeno Spun può leggere i dati. “Parziale” significa crittografato end-to-end all'interno di una terza parte (Stripe, WhatsApp), ma visibile a Spun per la parte che gestiamo.
In transito
Tutto ciò che viaggia tra il tuo browser, i nostri server e i nostri sub-responsabili del trattamento è crittografato con TLS.
TLS 1.2+ su ogni connessione
Tutto il traffico browser ↔ Spun, Spun ↔ gateway WhatsApp, Spun ↔ OpenAI / AssemblyAI / Deepgram / Sarvam / Azure e Spun ↔ Stripe è crittografato con TLS. Le versioni più vecchie del protocollo sono disattivate sul load balancer.
Edge gestito da Cloudflare
Cloudflare termina il TLS sull'edge e crittografa di nuovo la connessione verso l'origine. I certificati di origine vincolano le richieste ai nostri server Hetzner. WAF e protezione DDoS sono sempre attivi.
URL firmati a breve scadenza
I download dei media usano URL prefirmati S3 SigV4 limitati a un singolo oggetto, con una scadenza fissa. Anche un URL finito nelle mani sbagliate smette di funzionare quando scade.
A riposo
I dati archiviati sono isolati per organizzazione tramite la sicurezza a livello di riga di PostgreSQL, e i media sono raggiungibili solo tramite URL firmati e limitati a un singolo oggetto.
PostgreSQL con sicurezza a livello di riga
Ogni tabella che contiene dati dei clienti ha criteri di sicurezza a livello di riga (RLS) di PostgreSQL che impongono l'isolamento tra organizzazioni. Anche una query a cui per errore manca un filtro per organizzazione viene respinta a livello di database.
Prima la Germania, con una cella negli Stati Uniti
La cella principale (piano di controllo, server applicativi, PostgreSQL e Redis) gira presso Hetzner a Norimberga (Germania, UE). Una seconda cella gira a Manassas, in Virginia. Ogni organizzazione risiede su una sola cella, e ogni nuova organizzazione viene creata sulla cella UE.
Cloudflare R2 per i media
Immagini, video, audio e documenti sono memorizzati su Cloudflare R2. L'accesso non avviene mai tramite l'indirizzo pubblico di un bucket, ma solo tramite un URL firmato limitato a un singolo oggetto.
Chiamate vocali e videochiamate
Cosa è davvero E2EE, cosa non lo è e perché. Non presentiamo le chiamate di gruppo come crittografate end-to-end, perché non lo sono.
Voce e video 1:1: vero E2EE
Quando due utenti Spun si chiamano, l'audio e il video sono crittografati end-to-end con DTLS-SRTP tra i due browser. Il server di Spun inoltra solo la segnalazione SDP. Anche quando Cloudflare TURN deve fare da relay (NAT simmetrici, firewall), vede solo pacchetti crittografati.
Chiamate di gruppo (3 o più): crittografate in transito, non E2EE
Le chiamate audio e video di gruppo e le stanze di traduzione con più partecipanti usano LiveKit Cloud come SFU (selective forwarding unit). I media sono crittografati con DTLS-SRTP tra ciascun client e la SFU, ma la SFU li decrittografa alla ricezione per instradarli agli altri partecipanti. È l'architettura standard di una SFU e non è crittografata end-to-end.
Stanze di traduzione: prima P2P, quando possibile
Le stanze di traduzione provano prima il P2P (E2EE) quando sono presenti solo due partecipanti, e passano alla SFU quando entra un terzo partecipante o quando i dispositivi sono troppo limitati per il P2P. La modalità di connessione è visibile nell'interfaccia della chiamata.
Perché non dichiariamo un E2EE completo per le chiamate di gruppo
LiveKit supporta una modalità facoltativa di crittografia end-to-end (tramite la Encoded Insertable Streams API) che protegge i media anche dalla SFU. Al momento non è attiva sulle chiamate di gruppo di Spun: aggiungerla richiede un meccanismo di scambio delle chiavi tra i partecipanti e una compatibilità verificata di browser e codec per ogni client supportato.
Se l'E2EE per intere chiamate di gruppo è un requisito per te, scrivici a [email protected]: è nella roadmap e ti aggiorneremo sullo stato.
Pagamenti e identità
I dati più sensibili sono gestiti da fornitori specializzati, così Spun non li vede né li memorizza mai.
I dati della carta vanno direttamente a Stripe
Stripe Elements raccoglie numeri di carta, CVC e date di scadenza in un iframe che li invia direttamente a Stripe, scavalcando completamente i server di Spun. Riceviamo solo un ID opaco del cliente o del metodo di pagamento. Stripe è certificata PCI-DSS Level 1.
Le password sono sottoposte a hash con Argon2
Gli account con email e password usano Argon2id con un salt diverso per ogni utente. Non conserviamo né registriamo password in chiaro. Con l'accesso tramite Google l'autenticazione è delegata interamente a Google: per questi account in Spun non esiste mai una password.
Chiavi API e webhook firmati
Tutti i payload dei webhook di terze parti (WhatsApp, Stripe, webhook delle estensioni) sono firmati con HMAC-SHA256 e verificati lato server. I token API delle estensioni sono JWT a breve scadenza (RS256) con un endpoint JWKS pubblicato.
Messaggi WhatsApp: i limiti dell'E2EE
L'E2EE di WhatsApp protegge i messaggi finché si trovano all'interno dell'infrastruttura di WhatsApp. Nel momento in cui il tuo fornitore di gateway riceve un messaggio per tuo conto, il gateway vede il testo in chiaro. Vale per ogni fornitore della WhatsApp Business API: è così che funzionano le caselle di posta aziendali.
Altre domande?
Per dettagli tecnici specifici (cipher suite, autorità di certificazione, criteri di rotazione delle chiavi, ecc.) o per richiedere la compilazione di un questionario di sicurezza, scrivi a [email protected].