Prezentare generală a arhitecturii de securitate Mandraki

Notă: Acest articol descrie arhitectura și designul Mandraki. Unele funcții discutate sunt în curs de implementare progresivă și pot să nu fie încă disponibile în toate planurile.

Arhitectura de securitate nu este o listă de funcții. Este setul de decizii structurale care determină cum se comportă un sistem când lucrurile merg prost — când un atacator câștigă acces, când un guvern emite o citație, când un angajat face o greșeală, când un hard disk este furat. Această postare oferă o prezentare generală cuprinzătoare a arhitecturii de securitate Mandraki, inclusiv principiile care ghidează designul nostru, sistemele criptografice pe care le folosim și controalele operaționale care leagă totul.

Principii de design

Patru principii susțin fiecare decizie de securitate în Mandraki.

Apărare în profunzime. Nicio singură control nu ar trebui să fie diferența dintre securitate și compromis. Criptare în repaus, criptare în tranzit, criptare end-to-end, controale de acces, jurnalizare de audit și segmentare de rețea lucrează în concert. O eșec în un strat ar trebui conținut de celelalte.

Privilegiu minim. Utilizatori, servicii și componente de infrastructură au accesul minim necesar pentru funcția lor. Serverul de baze de date nu este accesibil din internetul public. SFU-ul handled media dar nu are acces la baza de date aplicației. Punctele finale API necesită autentificare și autorizație la nivelul organizației.

Transparență. Pretenții de securitate trebuie să fie verificabile. Documentez formate de criptare, practici de management de chei și alegeri de protocol în detaliu tehnic. Nu ne bazez pe obscuritate.

Suveranitate prin design. Fiecare component — infrastructură, aplicație, entitate corporativă — se încadrează în jurisdicția UE. Aceasta nu este o configurare de implementare; este o proprietate structurală a sistemului.

Ierarhia de criptare cu trei straturi

Mandraki folosește criptare envelope cu trei straturi, un model obișnuit folosit de furnizori de cloud și instituții financiare pentru echilibrul său între securitate, performanță și flexibilitate de management de chei.

Strat 1: Cheie Master. Rădăcina ierarhiei de chei. În implementări standard, aceasta este o cheie AES de 256 biți derivată din variabila de mediu MASTER_KEY. În implementări BYOK, aceasta este înlocuită de materialul de cheie al clientului (ARN AWS KMS, referință Azure Key Vault sau cheie importată manual). Cheia Master nu criptează date direct — învelește Cheile de Organizație.

Strat 2: Cheile de Organizație. Una per organizație. Fiecare Org Key este o cheie AES de 256 biți generată de Mandraki și stocată în baza de date învelită (criptată) de cheia Master. Pentru a folosi o Org Key, este desrângată în memorie, cache-uitată într-o cache LRU cu o TTL de cinci minute și aruncată după utilizare. Cheile desrânduite nu sunt niciodată scrise pe disc sau stocate în Redis. Org Keys învelesc Cheile de Criptare a Datelor.

Strat 3: Cheile de Criptare a Datelor (DEKs). Multiple per organizație, una per scop: mesaje, fișiere, înregistrări, transcrieri. Fiecare DEK este înveluit de Org Key a organizației sale. DEK-urile efectuează criptarea reală a datelor folosind AES-256-GCM. Formatul ieșirii criptate este [versiune:1B][iv:12B][authTag:16B][ciphertext], împachetat într-un singur câmp binar.

Această ierarhie permite rotație de cheie eficientă. Rotirea unei Org Key necesită re-înveluire a DEK-urilor (o operație de înveluire de cheie) dar nu re-criptare a tuturor datelor de bază. Rotirea unui DEK înseamnă că datele noi folosesc noua cheie în timp ce datele vechi rămân lizibile prin DEK-ul anterior reținut (marcat ca ROTATED).

Criptare end-to-end

Ierarhia cu trei straturi descrisă mai sus este criptare server-side — protejează datele în repaus pe infrastructura Mandraki. Criptarea end-to-end merge mai departe asigurând că serverul nu vede niciodată text clar.

Mesagerie (MLS). Folosim protocolul Messaging Layer Security (RFC 9420) pentru mesageria criptată. MLS oferă secret înainte și securitate post-compromis prin structura sa de acord de cheie TreeKEM. Grupurile MLS se mapează la canale și fire DM. Fiecare dispozitiv încarcă pachete de cheie cu utilizare unică care permit operații de grup asincrone.

Media (SFrame). Media în timp real în apeluri este criptată folosind SFrame (RFC 9605) prin WebRTC Encoded Transform API. Cadrele media sunt criptate după codificare și înainte de pachetizare pe expeditor și decriptate după reassambly și înainte de decodificare pe receptor. SFU-ul forwarea cadre criptate fără acces la text clar.

Criptare server-side și E2EE coexistă. Când E2EE este activat, datele sunt criptate end-to-end de clienți și de asemenea criptate în repaus pe server. Cele două straturi abordează modele de amenințare diferite: criptarea server-side protejează împotriva compromisului infrastructurii fizice, în timp ce E2EE protejează împotriva compromisului serverului.

Autentificare și autorizație

Mandraki folosește autentificare bazată pe JWT cu tokeni de acces de scurtă durată (cincisprezece minute) și tokeni de reîmprospătare mai longevivi (șapte zile). Tokenii de acces conțin identitatea utilizatorului, contextul organizației active și rolul.

Autorizarea este aplicată la mai multe niveluri. Gardurile la nivelul rutei validează autentificarea și verifică apartenența la organizație. Gardurile org-access.guard verifică că utilizatorul autentificat este membru al organizației specificate în cerere. Garduri bazate pe rol (OWNER, ADMIN, MEMBER) restricționează accesul la operații administrative.

Pentru utilizatori cu mai multe organizații, contextul organizației este stabilit la logare sau prin punctul final de comutare org. Tokenii JWT sunt scopi la o singură organizație, deci comutarea organizațiilor emite un nou token.

Multi-tenancy și izolarea datelor

Mandraki este o platformă multi-tenant unde izolarea datelor între organizații este aplicată la nivelul aplicației. Fiecare interogare de bază de date include un filtru de ID de organizație. Modelele interogărilor ORM Prisma asigură că accesul de date cross-tenant este structuralmente prevenit.

Apartenența la organizație este urmărită prin tabelul OrgMembership, care înregistrează relația utilizator-organizație alături de rolul utilizatorului și steagul organizației primare. Auto-captură verificată de domeniu direcționează automat noile înscriări la organizația corespunzătoare pe baza domeniului lor de e-mail.

Jurnalizare de audit

Securitatea nu este doar despre prevenție — este despre detecție și responsabilitate. Mandraki menține jurnale de audit pentru operații relevante de securitate: evenimente de autentificare (logare, delogare, reîmprospătare de token, încercări eșuate), schimbări de apartenență la organizație (aderări, plecări, schimbări de rol), operații de criptare (generare de chei, rotație, import BYOK, revocație), acțiuni administrative (schimbări de setări, verificare de domeniu, cereri de federație) și evenimente de ciclu de viață de apel (creație, aderare, plecare, încheiere, început și oprire de înregistrare).

Jurnalele de audit sunt stocate cu timbre de timp, identitate actor, tip de acțiune și metadata relevantă. Sunt accesibile administratorilor organizației prin interfața de management și pot fi exportate pentru integrare cu sisteme SIEM externe.

Arhitectura de rețea

Infrastructura de producție este segmentată după funcție. Serverele de bază de date și Redis se află pe o rețea privată fără acces la internetul public. Serverele de aplicații accesează nivelul de date prin adrese IP private. SFU-ul are porturi cu fată publică pentru trafic media WebRTC (UDP 40000-49999) și releu TURN (UDP/TCP 3478, TLS 5349). Traficul HTTPS este terminat la reverse proxy-ul nginx cu certificate Let’s Encrypt.

Accesul SSH la servere folosește autentificare cu cheie Ed25519 fără cădere înapoi la parolă. Serverul de date este accesibil doar via jump host din serverele aplicațiilor.

Considerații privind răspunsul la incident

Arhitectura noastră este proiectată pentru a sprijini răspunsul rapid la incident. Organizațiile BYOK pot revoca cheia Master pentru a face imediat toate datele inaccesibile. Tokenii de reîmprospătare pot fi revocați pentru a forța re-autentificare în toate sesiunile. Apartenența la organizație poate fi revocată pentru a termina imediat accesul unui utilizator. Relațiile de federație pot fi tăiate pentru a izola o organizație de colaboratori externi.

Aceste controale oferă mecanismele pe care echipele de securitate le necesită pentru a răspunde scenariilor de compromis decisiv.

Îmbunătățire continuă

Arhitectura de securitate nu este niciodată gata. Evaluez continuu designul nostru împotriva amenințărilor emergente, standarde criptografice noi și cerințe reglementare în evoluție. Angajamentul nostru este de a menține transparență cu privire la arhitectura noastră, onestitate cu privire la limitări și diligență în îmbunătățirea acesteia.

Bine-venim întrebări și feedback de la echipele de securitate care evaluează Mandraki. Înțelegerea în detaliu a arhitecturii noastre nu este doar permisă — este încurajată.