Panoramica dell'architettura di sicurezza di Mandraki

Nota: Questo articolo descrive l’architettura e la progettazione di Mandraki. Alcune feature discusse vengono rollout progressivamente e potrebbero non essere ancora disponibili in tutti i piani.

L’architettura di sicurezza non è un elenco di feature. È l’insieme delle decisioni strutturali che determinano come un sistema si comporta quando le cose vanno male — quando un attaccante guadagna accesso, quando un governo emette un mandato, quando un dipendente fa un errore, quando un disco rigido viene rubato. Questo articolo fornisce una panoramica completa dell’architettura di sicurezza di Mandraki, inclusi i principi che guidano la nostra progettazione, i sistemi crittografici che utilizziamo e i controlli operativi che legano tutto insieme.

Principi di progettazione

Quattro principi sottendono ogni decisione di sicurezza in Mandraki.

Difesa in profondità. Nessun singolo controllo dovrebbe essere la differenza tra sicurezza e compromesso. La crittografia a riposo, la crittografia in transito, la crittografia end-to-end, i controlli di accesso, l’audit logging e la segmentazione della rete lavorano in concerto. Un fallimento in uno strato dovrebbe essere contenuto dagli altri.

Privilegio minimo. Gli utenti, i servizi e i componenti dell’infrastruttura hanno il minimo accesso richiesto per la loro funzione. Il server del database non è accessibile da internet pubblico. L’SFU gestisce i media ma non ha accesso al database dell’applicazione. Gli endpoint API richiedono autenticazione e autorizzazione a livello di organizzazione.

Trasparenza. Le affermazioni di sicurezza dovrebbero essere verificabili. Documentiamo i nostri formati di crittografia, le pratiche di gestione delle chiavi e le scelte di protocollo in dettaglio tecnico. Non fare affidamento sull’oscurità.

Sovranità by design. Ogni componente — infrastruttura, applicazione, entità aziendale — cade entro la giurisdizione UE. Non è una configurazione di distribuzione; è una proprietà strutturale del sistema.

La gerarchia di crittografia a tre strati

Mandraki utilizza crittografia a busta con tre strati, un pattern comunemente usato dai provider cloud e dalle istituzioni finanziarie per il suo equilibrio di sicurezza, performance e flessibilità di gestione delle chiavi.

Strato 1: Master Key. La radice della gerarchia delle chiavi. Nelle distribuzioni standard, è una chiave AES a 256 bit derivata dalla variabile d’ambiente MASTER_KEY. Nelle distribuzioni BYOK, è sostituita dal materiale chiave del cliente (ARN AWS KMS, riferimento Azure Key Vault o chiave importata manualmente). La Master Key non cripta mai i dati direttamente — avvolge le Organisation Keys.

Strato 2: Organisation Keys. Una per organizzazione. Ogni Org Key è una chiave AES a 256 bit generata da Mandraki e archiviata nel database avvolta (crittografata) dalla Master Key. Per usare una Org Key, viene sviluppata in memoria, cacheata in una cache LRU con TTL di cinque minuti e scartata dopo l’uso. Le chiavi sviluppate non vengono mai scritte su disco o archiviate in Redis. Org Keys avvolgono Data Encryption Keys.

Strato 3: Data Encryption Keys (DEK). Multipli per organizzazione, uno per scopo: messaggi, file, registrazioni, trascrizioni. Ogni DEK è avvolto dalla Org Key della sua organizzazione. I DEK eseguono l’effettiva crittografia dei dati usando AES-256-GCM. Il formato di output crittografato è [version:1B][iv:12B][authTag:16B][ciphertext], impacchettato in un singolo campo binario.

Questa gerarchia consente una rotazione efficiente delle chiavi. La rotazione di una Org Key richiede il ri-wrapping dei DEK (un’operazione di key-wrapping) ma non la ri-crittografia di tutti i dati sottostanti. La rotazione di un DEK significa che i dati nuovi usano la nuova chiave mentre i dati vecchi rimangono leggibili attraverso il DEK precedente conservato (marcato come ROTATED).

Crittografia end-to-end

La gerarchia a tre strati descritta sopra è crittografia lato server — protegge i dati a riposo sull’infrastruttura di Mandraki. La crittografia end-to-end va oltre assicurando che il server non veda mai il testo in chiaro.

Messaggistica (MLS). Utilizziamo il protocollo Messaging Layer Security (MLS), standardizzato come RFC 9420 dall’IETF. MLS è stato progettato specificamente per scenari di messaggistica di gruppo e offre molti vantaggi rispetto agli approcci più vecchi.

MLS utilizza una struttura di accordo delle chiavi basata su albero chiamata TreeKEM, che consente a un gruppo di partecipanti di stabilire un segreto condiviso in modo efficiente. Quando un membro entra o esce da un gruppo, il materiale chiave viene aggiornato tramite un messaggio Commit che avanza l’epoch del gruppo. Questo fornisce forward secrecy — compromettere le chiavi di un membro in un momento non rivela messaggi da epoch precedenti — e post-compromise security — il gruppo recupera la sicurezza dopo un compromesso non appena il materiale chiave del membro interessato viene ruotato.

Ogni dispositivo utente carica pacchetti di chiavi MLS al server. Questi sono bundle crittografici usa e getta che consentono ad altri dispositivi di aggiungerli a un gruppo senza richiedere che il dispositivo sia online in quel momento. Quando un pacchetto di chiavi viene consumato, il dispositivo deve caricarne di freschi. Il server conserva e distribuisce questi pacchetti ma non ha mai accesso al materiale chiave privato che contengono.

I gruppi MLS in Mandraki mappano a canali e thread di messaggi diretti. Quando invii un messaggio in un canale crittografato, il tuo client lo cripta usando la chiave dell’epoch corrente del gruppo. Il server riceve il testo cifrato, lo archivia e lo distribuisce ai membri del gruppo. I loro client lo decriptano localmente.

Crittografia dei media con SFrame

La crittografia dei media in tempo reale — audio e video in una chiamata di gruppo — presenta sfide diverse dalla messaggistica. La tolleranza di latenza si misura in millisecondi, non secondi. I dati rate sono ordini di grandezza superiori. E i media passano attraverso una Selective Forwarding Unit (SFU), che ha bisogno di instradare i pacchetti ai partecipanti giusti senza poter vedere il contenuto.

Utilizziamo SFrame (RFC 9605) per la crittografia dei media, applicata tramite l’API WebRTC Encoded Transform. Questa API consente al codice JavaScript di intercettare i frame media codificati dopo la codifica ma prima del pacchettizzazione, crittarli e passare il testo cifrato al livello di trasporto. All’estremità ricevente, i frame vengono decrittografati dopo il riassemblaggio ma prima della decodifica.

Il vantaggio chiave di SFrame in un’architettura SFU è che l’SFU può ancora eseguire la sua funzione di routing — inoltramento di pacchetti da un partecipante a altri, prendendo decisioni adattative della larghezza di banda su quali livelli inoltrare — senza mai avere accesso ai media in testo in chiaro. L’SFU vede frame crittografati e li inoltra come blob opachi.

I compromessi di cui siamo onesti

La crittografia end-to-end non è gratuita. Introduce veri vincoli che crediamo valga la pena riconoscere.

La ricerca lato server non è possibile su contenuto E2EE. Se i messaggi vengono crittografati con chiavi che il server non possiede, il server non può indicizzarli per la ricerca. Mandraki affronta questo mantenendo un indice di ricerca crittografato locale sul client usando IndexedDB. Questo fornisce ricerca per dispositivo ma non supporta la ricerca cross-device della cronologia dei messaggi per i messaggi ricevuti prima che un dispositivo fosse aggiunto al gruppo.

Le feature IA lato server si escludono mutuamente con E2EE. Le nostre feature di trascrizione IA e riassunzione richiedono accesso lato server all’audio in testo in chiaro. Una chiamata o un canale non può avere sia E2EE che feature IA abilitate contemporaneamente. Questo è applicato architettonicamente, non solo da policy. Le organizzazioni scelgono a livello di chiamata o canale quale modello preferiscono.

I nuovi dispositivi vedono messaggi solo dal punto di join in poi. Quando aggiungi un nuovo dispositivo al tuo account, può decriptare messaggi dal momento in cui entra nel gruppo MLS in avanti. I messaggi storici crittografati sotto epoch precedenti non sono accessibili sul nuovo dispositivo. Questa è una proprietà fondamentale della forward secrecy. Stiamo esplorando meccanismi di backup sicuro che consentirebbero agli utenti di esportare la cronologia dei messaggi crittografata a un nuovo dispositivo, ma questo rimane un lavoro in corso.

La gestione delle chiavi aggiunge complessità. Ogni dispositivo deve mantenere il materiale chiave, caricare i pacchetti di chiavi freschi e elaborare gli aggiornamenti dello stato del gruppo. Investiamo uno sforzo di ingegneria significativo nel renderlo invisibile agli utenti. L’obiettivo è che la crittografia non sia qualcosa che configuri o su cui pensi — semplicemente accade.

E2EE e crittografia lato server coesistono

Vale la pena notare che il livello E2EE di Mandraki e la nostra crittografia lato server (la gerarchia di chiavi a tre strati descritta nella nostra architettura di sicurezza) servono scopi complementari. La crittografia lato server protegge i dati a riposo sulla nostra infrastruttura — se un disco viene rubato o un backup del database viene compromesso, i dati sono illeggibili senza le chiavi di crittografia. E2EE va oltre assicurando che il server non veda mai il testo in chiaro in primo luogo.

Per le organizzazioni che abilitano E2EE, entrambi gli strati sono attivi simultaneamente. I dati vengono crittografati end-to-end dai client e anche crittografati a riposo sul server. Cintura e bretelle.

Continuiamo a migliorare la nostra architettura di sicurezza contro minacce emergenti, nuovi standard crittografici e requisiti normativi in evoluzione. Il nostro impegno è mantenere trasparenza sulla nostra architettura, onestà sui suoi limiti e diligenza nel suo miglioramento.

Accogliamo con favore domande e feedback dai team di sicurezza che valutano Mandraki. Comprendere la nostra architettura in dettaglio non è solo permesso — è incoraggiato.