Przegląd architektury bezpieczeństwa Mandraki

Uwaga: Ten artykuł opisuje architekturę i projekt Mandraki. Niektóre omówione funkcje są wdrażane progresywnie i mogą być jeszcze niedostępne we wszystkich planach.

Architektura bezpieczeństwa nie jest listą funkcji. To zestaw decyzji strukturalnych, które określają, jak system zachowuje się, gdy coś pójdzie nie tak — gdy atakujący uzyska dostęp, gdy rząd wyda wezwanie, gdy pracownik popełni błąd, gdy dysk twardy zostanie skradziony. Ten post zawiera kompleksowy przegląd architektury bezpieczeństwa Mandraki, w tym zasady, które kierują naszym projektowaniem, systemy kryptograficzne, które zatrudniamy, oraz kontrole operacyjne, które wszystko łączą razem.

Zasady projektowania

Cztery zasady leżą u podstaw każdej decyzji dotyczącej bezpieczeństwa w Mandraki.

Obrona w głęb. Żadna pojedyncza kontrola nie powinna być różnicą między bezpieczeństwem a kompromisem. Szyfrowanie w spoczynku, szyfrowanie w tranzycie, szyfrowanie end-to-end, kontrole dostępu, rejestrowanie audytu i segmentacja sieci działają w koncercie. Awaria w jednej warstwie powinna być zawarta przez inne.

Najmniejszy przywilej. Użytkownicy, usługi i komponenty infrastruktury mają minimalny dostęp wymagany do ich funkcji. Serwer bazy danych nie jest dostępny z publicznego internetu. SFU obsługuje media, ale nie ma dostępu do bazy danych aplikacji. Punkty końcowe API wymagają uwierzytelniania i autoryzacji na poziomie organizacji.

Przejrzystość. Roszczenia bezpieczeństwa powinny być weryfikowalne. Dokumentujemy nasze formaty szyfrowania, praktyki zarządzania kluczami i wybory protokołów ze szczegółami technicznymi. Nie polegamy na niejasności.

Suwerenność przez projekt. Każdy komponent — infrastruktura, aplikacja, jednostka korporacyjna — falls within EU jurisdiction. To nie jest konfiguracja wdrażania; to strukturalna właściwość systemu.

Trójwarstwowa hierarchia szyfrowania

Mandraki używa szyfrowania koperty z trzema warstwami, wzoru powszechnie używanego przez dostawców chmury i instytucje finansowe ze względu na jego równowagę bezpieczeństwa, wydajności i elastyczności zarządzania kluczami.

Warstwa 1: Klucz główny. Korzeń hierarchii kluczy. W standardowych wdrożeniach, to jest klucz AES 256-bitowy pochodzący ze zmiennej środowiskowej MASTER_KEY. W wdrożeniach BYOK, to jest zastąpione materiałem klucza klienta (ARN AWS KMS, odwołanie Azure Key Vault lub ręcznie zaimportowany klucz). Klucz główny nigdy nie szyfruje danych bezpośrednio — zapakowuje Kluczy organizacji.

Warstwa 2: Kluczy organizacji. Jeden na organizację. Każdy Klucz Org jest kluczem AES 256-bitowym wygenerowanym przez Mandraki i przechowywany w bazie danych opakowanym (zaszyfrowanym) przez Klucz główny. Aby użyć Klucza Org, jest rozpakowany w pamięci, buforowany w cache LRU z pięciominutowym TTL i odrzucony po użyciu. Rozpakowane klucze nigdy nie są zapisywane na dysku ani przechowywane w Redis. Kluczy organizacji zapakowują Klucze szyfrowania danych.

Warstwa 3: Klucze szyfrowania danych (DEK). Wiele na organizację, jeden na cel: wiadomości, pliki, nagrania, transkrypcje. Każdy DEK jest opakowany kluczem Org swoją organizacją. DEK-i wykonują rzeczywiste szyfrowanie danych za pomocą AES-256-GCM. Format wyjściowego szyfrowania to [version:1B][iv:12B][authTag:16B][ciphertext], upakowany w jedno pole binarne.

Ta hierarchia umożliwia efektywną rotację klucza. Obracanie Klucza Org wymaga przyzapakowywania DEK-ów (operacja zapakowywania klucza), ale nie ponownego szyfrowania wszystkich danych bazowych. Obracanie DEK oznacza, że nowe dane używają nowego klucza, podczas gdy stare dane pozostają czytelne za pośrednictwem zatrzymanego poprzedniego DEK (oznaczonego jako ROTATED).

Szyfrowanie end-to-end

Trójwarstwowa hierarchia opisana powyżej to szyfrowanie po stronie serwera — chroni dane w spoczynku w infrastrukturze Mandraki. Szyfrowanie end-to-end idzie dalej, zapewniając, że serwer nigdy nie widzi zwykłego tekstu.

Komunikacja (MLS). Używamy protokołu Messaging Layer Security (RFC 9420) do szyfrowanej komunikacji. MLS zapewnia tajność przyszłości i bezpieczeństwo po kompromisie poprzez strukturę zgodności TreeKEM. Grupy MLS mapują na kanały i wątki wiadomości bezpośrednich. Każde urządzenie przesyła pakiety kluczy do jednorazowego użytku, które pozwalają na asynchroniczne operacje grupowe.

Media (SFrame). Media w czasie rzeczywistym w połączeniach są szyfrowane przy użyciu SFrame (RFC 9605) za pośrednictwem Encoded Transform API WebRTC. Ramki multimediów są szyfrowane po kodowaniu i przed pakietyzacją na nadawcy i odszyfrowane po ponownym zmontowaniu i przed dekodowaniem na odbiorcy. SFU przesyła zaszyfrowane ramki bez dostępu do zwykłego tekstu.

Szyfrowanie po stronie serwera i E2EE współistnieją. Gdy E2EE jest włączony, dane są szyfrowane end-to-end przez klientów i również szyfrowane w spoczynku na serwerze. Te dwie warstwy dotyczą różnych modeli zagrożeń: szyfrowanie po stronie serwera chroni przed kompromisem infrastruktury fizycznej, podczas gdy E2EE chroni przed kompromisem serwera.

Uwierzytelnianie i autoryzacja

Mandraki używa uwierzytelniania opartego na JWT z krótkowiecznymi tokenami dostępu (piętnaście minut) i długowiecznymi tokenami odświeżającymi (siedem dni). Tokeny dostępu zawierają tożsamość użytkownika, aktywny kontekst organizacji i rolę.

Autoryzacja jest wymuszana na wielu poziomach. Strażnicy na poziomie trasy weryfikują uwierzytelnianie i sprawdzają członkostwo w organizacji. org-access.guard weryfikuje, że uwierzytelniony użytkownik jest członkiem organizacji określonej w żądaniu. Strażnicy oparte na rolach (OWNER, ADMIN, MEMBER) ograniczają dostęp do operacji administracyjnych.

Dla użytkowników z wieloma organizacjami, kontekst organizacji jest ustawiany przy logowaniu lub za pośrednictwem punktu końcowego przełączania org. Tokeny JWT są ograniczone do jednej organizacji, więc przełączanie organizacji wystawia nowy token.

Multi-tenancy i izolacja danych

Mandraki jest platformą multi-tenant, gdzie izolacja danych między organizacjami jest wymuszana na warstwie aplikacji. Każde zapytanie bazy danych zawiera filtr ID organizacji. Wzory zapytań Prisma ORM zapewniają, że dostęp danych między dzierżawcami jest strukturalnie uniemożliwiony.

Członkostwo w organizacji jest śledzone za pośrednictwem tabeli OrgMembership, która rejestruje relację użytkownika-organizacji wraz z rolą użytkownika i flagą organizacji głównej. Automatyczne przechwycenie zweryfikowane domenie automatycznie kieruje nowe logowania do odpowiedniej organizacji na podstawie ich domeny e-mail.

Rejestrowanie audytu

Bezpieczeństwo nie polega tylko na zapobieganiu — polega na detekcji i odpowiedzialności. Mandraki utrzymuje dzienniki audytu dla operacji związanych z bezpieczeństwem: zdarzenia uwierzytelniania (logowanie, wylogowanie, odświeżenie tokena, nieudane próby), zmiany członkostwa w organizacji (joins, leaves, zmiany ról), operacje szyfrowania (generowanie klucza, rotacja, import BYOK, odwołanie), działania administracyjne (zmiany ustawień, weryfikacja domeny, żądania federacji) i zdarzenia cyklu życia połączenia (tworzenie, dołączenie, wyjście, koniec, uruchomienie i zatrzymanie nagrania).

Dzienniki audytu są przechowywane ze znacznikami czasu, tożsamością aktora, typem akcji i istotną metadaną. Są dostępne dla administratorów organizacji za pośrednictwem interfejsu zarządzania i mogą być eksportowane do integracji z zewnętrznymi systemami SIEM.

Architektura sieci

Produkcyjna infrastruktura jest podzielona na funkcje. Serwery bazy danych i Redis znajdują się w sieci prywatnej bez dostępu do publicznego internetu. Serwery aplikacji uzyskują dostęp do warstwy danych za pośrednictwem prywatnych adresów IP. SFU ma porty skierowane do publiczności do ruchu mediów WebRTC (UDP 40000-49999) i retransmisji TURN (UDP/TCP 3478, TLS 5349). Ruch HTTPS jest przerwany na odwrotnym proxy nginx z certyfikatami Let’s Encrypt.

Dostęp SSH do serwerów używa uwierzytelniania klucza Ed25519 bez powrotu do hasła. Serwer danych jest dostępny tylko za pośrednictwem skoku hosta z serwerów aplikacji.

Zagadnienia dotyczące reagowania na incydenty

Nasza architektura jest zaprojektowana, aby wspierać szybkie reagowanie na incydenty. Organizacje BYOK mogą odwołać Klucz główny, aby natychmiast uczynić wszystkie dane niedostępne. Tokeny odświeżające mogą być odwołane, aby wymusić ponowne uwierzytelnianie we wszystkich sesjach. Członkostwo w organizacji może być odwołane, aby natychmiast zakończyć dostęp użytkownika. Relacje federacyjne mogą być przerwane, aby odizolować organizację od współpracowników zewnętrznych.

Te kontrole zapewniają mechanizmy, które zespoły bezpieczeństwa potrzebują, aby odpowiadać scenariuszom kompromisu decyzyjnie.

Ciągłe ulepszanie

Architektura bezpieczeństwa nigdy się nie kończy. Ciągle oceniamy nasz projekt w stosunku do pojawiających się zagrożeń, nowych standardów kryptograficznych i ewoluujących wymagań regulacyjnych. Nasze zobowiązanie jest utrzymane przejrzystości dotyczącej naszej architektury, szczerości na temat jej ograniczeń i sumienności w jej ulepszeniu.

Zapraszamy pytania i opinie od zespołów bezpieczeństwa oceniających Mandraki. Szczegółowe zrozumienie naszej architektury jest nie tylko dozwolone — jest to zachęcane.