Přehled bezpečnostní architektury Mandraki

Poznámka: Tento článek popisuje architekturu a design Mandraki. Některé zde diskutované funkce se zavádějí postupně a nemusí být ještě k dispozici ve všech plánech.

Bezpečnostní architektura není seznam funkcí. Je to soubor strukturních rozhodnutí, která určují, jak se systém chová, když se věci pokazí — když útočník získá přístup, když vláda vydá předvolání, když zaměstnanec udělá chybu, když je pevný disk украден. Tento příspěvek poskytuje komplexní přehled bezpečnostní architektury Mandraki, včetně principů, které vedou naše rozhodování, kryptografických systémů, které používáme, a provozních ovládacích prvků, které to všechno spojují.

Návrhářské principy

Čtyři principy podporují každé bezpečnostní rozhodnutí v Mandraki.

Obrana do hloubky. Žádný jediný ovládací prvek by neměl být rozdílem mezi bezpečností a kompromisem. Šifrování v klidu, šifrování v přenosu, end-to-end šifrování, přístupové ovládací prvky, auditní logging a segmentace sítě pracují v souhlasu. Selhání v jedné vrstvě by mělo být obsaženo ostatními.

Princip nejmenšího privilegia. Uživatelé, služby a komponenty infrastruktury mají minimální přístup požadovaný pro jejich funkci. Server databáze není přístupný z veřejného internetu. SFU zpracovává média, ale nemá přístup k databázi aplikace. Endpointy API vyžadují ověření a autorizaci na úrovni organizace.

Transparentnost. Bezpečnostní tvrzení by měla být ověřitelná. Dokumentujeme naše formáty šifrování, praktiky správy klíčů a volby protokolu v technickém detailu. Nemusíme se spoléhat na neurčitost.

Suverenita podle designu. Každá komponenta — infrastruktura, aplikace, právní entita — spadá do jurisdikce EU. To není konfigurace nasazení; je to strukturní vlastnost systému.

Hierarchie třívrstvého šifrování

Mandraki používá obálky šifrování se třemi vrstvami, vzorec běžně používaný poskytovateli cloudu a finančními institucemi pro jeho rovnováhu bezpečnosti, výkonu a flexibility správy klíčů.

Vrstva 1: Hlavní klíč. Kořen hierarchie klíčů. V standardních nasazeních je to 256bitový AES klíč odvozený z proměnné prostředí MASTER_KEY. V nasazeních BYOK je to nahrazeno klíčovým materiálem zákazníka (AWS KMS ARN, Azure Key Vault reference, nebo ručně importovaný klíč). Hlavní klíč nikdy nešifruje data přímo — obaluje Organisační klíče.

Vrstva 2: Organisační klíče. Jeden na organizaci. Každý klíč Org je 256bitový AES klíč vygenerovaný Mandraki a uložený v databázi zabalen (zašifrován) hlavním klíčem. Aby se používal klíč Org, je rozbalit v paměti, uložen v LRU cache s TTL pět minut a vyřazen po použití. Nerozbalené klíče nejsou nikdy zapsány na disk nebo uloženy v Redis. Organisační klíče obalují Data Encryption Keys.

Vrstva 3: Data Encryption Keys (DEK). Více na organizaci, jeden na účel: zprávy, soubory, nahrávky, přepisy. Každý DEK je zabalen klíčem Org své organizace. DEK provádějí skutečné šifrování dat pomocí AES-256-GCM. Formát šifrovaného výstupu je [version:1B][iv:12B][authTag:16B][ciphertext], zapacked do jediného binárního pole.

Tato hierarchie umožňuje efektivní rotaci klíčů. Rotace klíče Org vyžaduje znovu zabalení DEK (operace zabalení klíče), ale ne znovu zašifrování všech základních dat. Rotace DEK znamená, že nová data používají nový klíč, zatímco stará data zůstávají čitelná prostřednictvím zachovaného předchozího DEK (označeného jako ROTATED).

End-to-end šifrování

Hierarchie třívrstvého šifrování popsaná výše je šifrování na straně serveru — chrání data v klidu na infrastruktuře Mandraki. End-to-end šifrování jde dále tím, že zajišťuje, že server nikdy nevidí otevřený text.

Messaging (MLS). Používáme protokol Messaging Layer Security (RFC 9420) pro šifrované messaging. MLS byl navržen konkrétně pro scénáře skupinového messagingu a nabízí několik výhod oproti starším přístupům.

MLS používá strukturu dohody klíčů založenou na stromě nazvanou TreeKEM, která umožňuje skupině účastníků efektivně vytvořit sdílený tajemství. Když se člen připojí nebo opustí skupinu, klíčový materiál se aktualizuje prostřednictvím zprávy Commit, která postoupí epochu skupiny. To poskytuje forward secrecy — ohrození klíčů člena v jednom bodě času neodhálí zprávy z dřívějších epoch — a post-compromise security — skupinu se obnoví bezpečnost po kompromisu, jakmile se klíčový materiál ovlivněného člena otočí.

Každé zařízení uživatele nahraje jednodenní MLS klíče balíčky na server. Jedná se o jednodenní kryptografické svazky, které umožňují jiným zařízením přidat je do skupiny bez vyžadování, aby bylo zařízení online v daný čas. Když je klíčový balíček spotřebován, musí zařízení nahrát nové. Server ukládá a distribuuje tyto balíčky, ale nikdy nemá přístup k privátnímu klíčovému materiálu, který obsahují.

Skupiny MLS v Mandraki mapují kanály a vlákna přímých zpráv. Když pošlete zprávu v zašifrovaném kanálu, váš klient ji zašifruje pomocí aktuální epochy skupiny. Server přijímá ciphertext, ukládá jej a distribuuje členům skupiny. Jejich klienti jej dešifrují místně.

SFrame pro šifrování médií

Šifrování mediálních dat v reálném čase — audio a video ve skupinovém hovoru — představuje jiné výzvy než messaging. Tolerance latence se měří v milisekundách, ne sekundách. Datové sazby jsou řádově vyšší. A média procházejí Selective Forwarding Unit (SFU), která potřebuje směrovat pakety správným účastníkům bez schopnosti vidět obsah.

Používáme SFrame (RFC 9605) pro šifrování médií, aplikované prostřednictvím WebRTC Encoded Transform API. Toto API umožňuje kódu JavaScript zachytit kódovaná mediální snímky po kódování, ale před packetizací, zašifrovat je a předat ciphertext přenosové vrstvě. Na přijímací straně se snímky dešifrují po změně montáže, ale před dekódováním.

Klíčová výhoda SFrame v architektuře SFU je, že SFU stále může provádět svou funkci směrování — přeposílání paketů od jednoho účastníka ostatním, provádění rozhodnutí o přizpůsobení šířky pásma, které vrstvy přeposílat — bez toho, aby měl přístup k mediálním datům v otevřeném textu. SFU vidí šifrované snímky a přeposílá je jako neprůhledné bloby.

Ověření a autorizace

Mandraki používá JWT-based ověření s krátkodobými access tokeny (patnáct minut) a dlouhodobějšími refresh tokeny (sedm dní). Access tokeny obsahují identitu uživatele, aktivní kontext organizace a roli.

Autorizace je vynucena na více úrovních. Ochranné prvky na úrovni routy ověřují ověření a kontrolují členství v organizaci. org-access.guard ověřuje, že ověřený uživatel je členem organizace specifikované v požadavku. Ochranné prvky založené na rolích (OWNER, ADMIN, MEMBER) omezují přístup k administrativním operacím.

Pro uživatele s více organizacemi je kontext organizace nastaven při přihlášení nebo prostřednictvím endpointu přepnutí organizace. JWT tokeny jsou omezeny na jednu organizaci, takže přepnutí organizací vydává nový token.

Multi-tenancy a izolace dat

Mandraki je multi-tenant platforma, kde je izolace dat mezi organizacemi vynucena na aplikační vrstvě. Každý dotaz na databázi obsahuje filtr ID organizace. Vzory dotazů Prisma ORM zajišťují, že přístup dat mezi tenanty je strukturálně zabráněn.

Členství v organizaci se sleduje prostřednictvím tabulky OrgMembership, která zaznamenává vztah mezi uživatelem a organizací spolu s rolí uživatele a vlajkou primární organizace. Automatické zadávání ověřené doménou automaticky směruje nové registrace do příslušné organizace na základě jejich domény e-mailu.

Auditní logging

Bezpečnost není jen o prevenci — je o detekci a odpovědnosti. Mandraki udržuje auditní logy pro bezpečnostně relevantní operace: ověřovací události (přihlášení, odhlášení, aktualizace tokenu, neúspěšné pokusy), změny členství v organizaci (připojení, odchod, změny rolí), operace šifrování (generování klíčů, rotace, import BYOK, zrušení), administrativní akce (změny nastavení, ověření domény, žádosti federace) a životní cyklus hovorů (vytvoření, připojení, odchod, ukončení, spuštění a zastavení nahrávání).

Auditní protokoly jsou uloženy s časovými razítky, identitou aktéra, typem akce a relevantními metadaty. Jsou přístupné správcům organizace prostřednictvím rozhraní správy a lze je exportovat pro integraci s externími systémy SIEM.

Architektura sítě

Produkční infrastruktura je segmentována podle funkce. Servery databáze a Redis se nacházejí v soukromé síti bez veřejného přístupu do internetu. Aplikační servery přistupují datové vrstvě prostřednictvím soukromých IP adres. SFU má veřejně přístupné porty pro WebRTC mediální provoz (UDP 40000-49999) a TURN relay (UDP/TCP 3478, TLS 5349). Provoz HTTPS je ukončen na reverzní proxy nginx s certifikáty Let’s Encrypt.

SSH přístup na servery používá ověření klíče Ed25519 bez fallbacku hesla. Datový server je přístupný pouze přes jump host z aplikačních serverů.

Hlediska odezvy na incidenty

Naše architektura je navržena tak, aby podporovala rychlou odezvu na incidenty. Organizace BYOK mohou zrušit svůj hlavní klíč, aby okamžitě učinily všechna data nepřístupná. Refresh tokeny mohou být zrušeny, aby vynutil znovu ověření ve všech relacích. Členství v organizaci může být zrušeno, aby okamžitě ukončilo přístup uživatele. Vztahy federace mohou být přerušeny, aby izolovala organizaci od externích spolupracovníků.

Tyto ovládací prvky poskytují mechanismy, které bezpečnostní týmy potřebují, aby reagovaly na scénáře kompromisu rozhodně.

Neustálé zlepšování

Bezpečnostní architektura se nikdy nekončí. Neustále vyhodnocujeme náš design proti vznikajícím hrozbám, novým kryptografickým standardům a vyvíjejícím se regulačním požadavkům. Náš závazek je udržovat transparentnost o naší architektuře, upřímnost o jejích omezeních a bedlivost v jejím zlepšování.

Vítáme otázky a zpětnou vazbu od bezpečnostních týmů vyhodnocujících Mandraki. Detailní pochopení naší architektury není jen povoleno — je podporováno.