Mandraki-sikkerhedsarkitektur Oversigt

Bemærk: Denne artikel beskriver Mandraki’s arkitektur og design. Nogle funktioner, der diskuteres, bliver implementeret progressivt og er muligvis ikke endnu tilgængelige i alle planer.

Sikkerhedsarkitektur er ikke en feature-liste. Det er sættet af strukturelle beslutninger, der afgør, hvordan et system opfører sig, når tingene går galt — når en angriber får adgang, når en regering udsteder en stævning, når en medarbejder gør en fejl, når en harddisk bliver stjålet. Dette indlæg giver en omfattende oversigt over Mandraki’s sikkerhedsarkitektur, herunder principperne, der styrer vores design, de kryptografiske systemer, vi anvender, og de operationelle kontroller, der binder alt sammen.

Designprincipper

Fire principper understøtter hver sikkerhedsbeslutning i Mandraki.

Defense in depth. Ingen enkelt kontrol bør være forskellen mellem sikkerhed og kompromis. Kryptering i hvile, kryptering under transit, end-to-end-kryptering, adgangskontreller, revisionslogging og netværkssegmentering arbejder i koncert. En fejl i et lag bør være indeholdt af de andre.

Mindsterettighedsprincippet. Brugere, tjenester og infrastrukturkomponenter har den minimale adgang, der kræves for deres funktion. Datakserver er ikke tilgængelig fra det offentlige internet. SFU’en håndterer medier, men har ikke adgang til applikationsdatabasen. API-slutpunkter kræver godkendelse og organisations-niveau autorisation.

Transparens. Sikkerhedskrav bør være verificerbare. Vi dokumenterer vores krypteringsformater, nøglestyrings-praksis og protokol-valg i teknisk detalje. Vi stoler ikke på dunkelheden.

Suverænitet efter design. Hver komponent — infrastruktur, applikation, virksomhedsenheden — falder inden for EU-jurisdiktion. Dette er ikke en implementerings-konfiguration; det er en strukturel egenskab af systemet.

Hierarkiet for trelags-kryptering

Mandraki bruger envelope-kryptering med tre lag, et mønster, der almindeligvis bruges af cloud-udbydere og finansielle institutioner for dets balance af sikkerhed, ydeevne og nøglestyrings-fleksibilitet.

Lag 1: Hovednøgle. Roden af nøglehierarkiet. I standard-implementeringer er det en 256-bit AES-nøgle afledt fra MASTER_KEY-miljøvariablen. I BYOK-implementeringer erstattes det af kundens nøglemateriale (AWS KMS ARN, Azure Key Vault-reference eller manuelt importeret nøgle). Hovednøglen krypterer aldrig data direkte — den indpakker Organisations-nøgler.

Lag 2: Organisations-nøgler. En pr. organisation. Hver Org-nøgle er en 256-bit AES-nøgle genereret af Mandraki og gemt i databasen indpakket (krypteret) af Hovednøglen. For at bruge en Org-nøgle, pakkes den ud i hukommelsen, cachelagres i en LRU-cache med en fem-minutters TTL og kasseres efter brug. Uindpakkede nøgler skrives aldrig til disk eller lagres i Redis. Org-nøgler indpakker Data-kryptering-nøgler.

Lag 3: Data-kryptering-nøgler (DEK’er). Flere pr. organisation, en pr. formål: beskeder, filer, optagelser, transskriptioner. Hver DEK er indpakket af sin organisations Org-nøgle. DEK’er udfører den faktiske data-kryptering ved hjælp af AES-256-GCM. Det krypterede output-format er [version:1B][iv:12B][authTag:16B][ciphertext], pakket ind i et enkelt binært felt.

Dette hierarki tillader effektiv nøglerotation. Rotere en Org-nøgle kræver at re-indbakke DEK’erne (en nøgle-indpaknings-operation), men ikke re-kryptere alle underliggende data. Rotere en DEK betyder, at nye data bruger den nye nøgle, mens gamle data forbliver læsbare gennem den gemte tidligere DEK (markeret som ROTATED).

End-to-end-kryptering

Hierarkiet for trelags-kryptering beskrevet ovenfor er server-side-kryptering — det beskytter data i hvile på Mandraki’s infrastruktur. End-to-end-kryptering går længere ved at sikre, at serveren aldrig ser klartekst.

Beskeder (MLS). Vi bruger Messaging Layer Security-protokollen (RFC 9420) til krypteret beskeder. MLS giver fremadrettet hemmelighed og post-kompromis-sikkerhed gennem dens TreeKEM-nøgle-aftale-struktur. MLS-grupper kortlægges til kanaler og DM-tråde. Hver enhed uploader one-time-use-nøgle-pakker, der tillader asynkrone gruppe-operationer.

Medier (SFrame). Realtidsmedier i opkald bliver krypteret ved hjælp af SFrame (RFC 9605) via WebRTC Encoded Transform API. Medieframes blir krypteret efter kodning og før pakkemeddeling på afsenderen og dekrypteret efter samling og før dekodning på modtageren. SFU’en viderestiller krypterede frames uden adgang til klartekst.

Server-side-kryptering og E2EE eksisterer sammen. Når E2EE er aktiveret, bliver data krypteret end-to-end af klienter og også krypteret i hvile på serveren. De to lag behandler forskellige trusselmodeller: server-side-kryptering beskytter mod fysisk infrastruktur-kompromis, mens E2EE beskytter mod server-kompromis.

Godkendelse og autorisation

Mandraki bruger JWT-baseret godkendelse med kortvarige adgangs-tokens (femten minutter) og længerevarende refresh-tokens (syv dage). Adgangs-tokens indeholder brugerens identitet, aktiv organisations-kontekst og rolle.

Autorisation håndhæves på flere niveauer. Route-niveau-værn validerer godkendelse og kontrollerer organisations-medlemskab. org-access.guard verificerer, at den godkendte bruger er medlem af den organisation, der er angivet i anmodningen. Rolle-baserede værn (OWNER, ADMIN, MEMBER) begræns adgangen til administrative operationer.

For multi-organisations-brugere bliver organisations-kontekst sat ved login eller via org-skift-slutpunktet. JWT-tokens er omfanget til en enkelt organisation, så skift af organisationer udsteder et nyt token.

Multi-lejet-virksomhed og dataisolation

Mandraki er en multi-lejet-platform, hvor dataisolation mellem organisationer håndhæves på applikationslaget. Hver databaseforespørgsel inkluderer et organisations-id-filter. Prisma ORM’s forespørgsels-mønster sikrer, at tværs-lejer-dataaccesser strukturelt forhindres.

Organisations-medlemskab spores gennem OrgMembership-tabellen, som registrerer bruger-organisations-forholdet sammen med brugerens rolle og primær organisations-flag. Domæne-verificeret auto-capture ruter automatisk nye sign-ups til den passende organisation baseret på deres email-domæne.

Revisionslogging

Sikkerhed handler ikke blot om prævention — det handler om detektion og ansvarlighed. Mandraki vedligeholder revisionslogger til sikkerhed-relevante operationer: godkendelses-begivenheder (login, logout, token-refresh, mislykkede forsøg), organisations-medlemskabs-ændringer (joins, leaves, rolle-ændringer), kryptering-operationer (nøgle-generation, rotation, BYOK-import, revokation), administrative operationer (indstillinger-ændringer, domæne-verificering, føderation-anmodninger) og opkald-livscyklus-begivenheder (oprettelse, join, leave, end, optagelse-start og stop).

Revisionslogger lagres med timestamps, aktør-identitet, handling-type og relevant metadata. De er tilgængelige for organisations-administratorer gennem administrations-grænsefladen og kan eksporteres for integration med eksterne SIEM-systemer.

Netværksarkitektur

Produktions-infrastrukturen er segmenteret efter funktion. Database- og Redis-serverne befinder sig på et privat netværk uden offentlig internet-adgang. Applikationsservere får adgang til data-laget gennem private IP-adresser. SFU’en har offentligt vendte porte til WebRTC-medietrafik (UDP 40000-49999) og TURN-relay (UDP/TCP 3478, TLS 5349). HTTPS-trafik afsluttes ved nginx-omvendt proxy med Let’s Encrypt-certifikater.

SSH-adgang til servere bruger Ed25519-nøgle-godkendelse uden passwordfaldback. Data-serveren er tilgængelig kun via jumphost fra applikationsserverne.

Incident Response-overvejelser

Vores arkitektur er designet til at understøtte hurtig incident-response. BYOK-organisationer kan tilbagekalde deres Hovednøgle for øjeblikkeligt at gøre alle data utilgængelige. Refresh-tokens kan tilbagekaldes for at tvinge re-godkendelse på tværs af alle sessioner. Organisations-medlemskab kan tilbagekaldes for øjeblikkeligt at afslutte en brugers adgang. Føderation-forhold kan seres for at isolere en organisation fra eksterne samarbejds-partnere.

Disse kontroller giver de mekanismer, som sikkerhedsteams har brug for for at reagere på kompromis-scenarier afgørende.

Kontinuerlig forbedring

Sikkerhedsarkitektur er aldrig færdig. Vi evaluerer kontinuerligt vores design mod nye trusler, nye kryptografiske standarder og skiftende lovgivningsmæssige krav. Vores forpligtelse er at opretholde transparens omkring vores arkitektur, ærlighed omkring dens begrænsninger og flid i dens forbedring.

Vi ønsker spørgsmål og feedback fra sikkerhedsteams, der evaluerer Mandraki. At forstå vores arkitektur i detaljer er ikke blot tilladt — det tilskyndes.