Mandrakis säkerhetsarkitektur — en översikt

Säkerhetsarkitektur är inte en lista över funktioner. Det är den uppsättning strukturella beslut som avgör hur ett system beter sig när saker går fel — när en angripare får åtkomst, när en myndighet utfärdar ett föreläggande, när en anställd gör ett misstag, när en hårddisk blir stulen. Detta inlägg ger en omfattande översikt av Mandrakis säkerhetsarkitektur, inklusive de principer som vägleder vår design, de kryptografiska system vi använder och de operativa kontroller som binder allt samman.

Designprinciper

Fyra principer ligger till grund för varje säkerhetsbeslut i Mandraki.

Försvar på djupet. Ingen enskild kontroll ska vara det som skiljer säkerhet från intrång. Kryptering i vila, kryptering under överföring, end-to-end-kryptering, åtkomstkontroller, granskningsloggning och nätverkssegmentering samverkar. Ett fel i ett lager ska fångas upp av de andra.

Minsta behörighet. Användare, tjänster och infrastrukturkomponenter har den minsta åtkomst som krävs för sin funktion. Databasservern är inte åtkomlig från det publika internet. SFU:n hanterar media men har inte åtkomst till applikationsdatabasen. API-slutpunkter kräver autentisering och behörighet på organisationsnivå.

Transparens. Säkerhetspåståenden ska vara verifierbara. Vi dokumenterar våra krypteringsformat, vår nyckelhantering och våra protokollval i teknisk detalj. Vi förlitar oss inte på dunkelhet.

Suveränitet i grunden. Varje komponent — infrastruktur, applikation och företag — ligger inom EU:s jurisdiktion. Detta är inte en driftskonfiguration; det är en strukturell egenskap hos systemet.

Krypteringshierarkin i tre lager

Mandraki använder kuvertkryptering i tre lager, ett mönster som ofta används av molnleverantörer och finansinstitut för dess balans mellan säkerhet, prestanda och flexibel nyckelhantering.

Lager 1: Huvudnyckel. Roten i nyckelhierarkin. I standardinstallationer är detta en 256-bitars AES-nyckel som härleds från miljövariabeln MASTER_KEY. I BYOK-installationer ersätts den av kundens nyckelmaterial (AWS KMS ARN, Azure Key Vault-referens eller en manuellt importerad nyckel). Huvudnyckeln krypterar aldrig data direkt — den omsluter organisationsnycklar.

Lager 2: Organisationsnycklar. En per organisation. Varje organisationsnyckel är en 256-bitars AES-nyckel som genereras av Mandraki och lagras i databasen omsluten (krypterad) av huvudnyckeln. När en organisationsnyckel ska användas packas den upp i minnet, cachelagras i en LRU-cache med fem minuters TTL och kasseras efter användning. Uppackade nycklar skrivs aldrig till disk och lagras aldrig i Redis. Organisationsnycklar omsluter datakrypteringsnycklar.

Lager 3: Datakrypteringsnycklar (DEK). Flera per organisation, en per ändamål: meddelanden, filer, inspelningar, transkriptioner. Varje DEK är omsluten av organisationsnyckeln. DEK:erna utför den faktiska datakrypteringen med AES-256-GCM. Det krypterade utdataformatet är [version:1B][iv:12B][authTag:16B][ciphertext], packat i ett enda binärfält.

Denna hierarki möjliggör effektiv nyckelrotation. Att rotera en organisationsnyckel kräver att DEK:erna omsluts på nytt (en nyckelomslutningsoperation) men inte att all underliggande data krypteras om. Att rotera en DEK innebär att ny data använder den nya nyckeln medan gammal data förblir läsbar via den bevarade tidigare DEK:en (markerad som ROTATED).

End-to-end-kryptering

Hierarkin i tre lager som beskrivs ovan är kryptering på serversidan — den skyddar data i vila på Mandrakis infrastruktur. End-to-end-kryptering går längre genom att säkerställa att servern aldrig ser klartext.

Meddelanden (MLS). Vi använder protokollet Messaging Layer Security (RFC 9420) för krypterade meddelanden. MLS ger framåtriktad sekretess och säkerhet efter intrång (post-compromise security) genom sin nyckelöverenskommelsestruktur TreeKEM. MLS-grupper mappas till kanaler och DM-trådar. Varje enhet laddar upp engångsnyckelpaket som möjliggör asynkrona gruppoperationer.

Media (SFrame). Realtidsmedia i samtal krypteras med SFrame (RFC 9605) via WebRTC Encoded Transform API. Mediaramar krypteras efter kodning och före paketering hos avsändaren, och dekrypteras efter ompaketering och före avkodning hos mottagaren. SFU:n vidarebefordrar krypterade ramar utan åtkomst till klartext.

Kryptering på serversidan och E2EE samexisterar. När E2EE är aktiverat krypteras data end-to-end av klienterna och krypteras dessutom i vila på servern. De två lagren hanterar olika hotmodeller: kryptering på serversidan skyddar mot fysiskt intrång i infrastrukturen, medan E2EE skyddar mot intrång i servern.

Autentisering och auktorisering

Mandraki använder JWT-baserad autentisering med kortlivade åtkomsttoken (femton minuter) och längre levande förnyelsetoken (sju dagar). Åtkomsttoken innehåller användarens identitet, aktiv organisationskontext och roll.

Auktorisering tillämpas på flera nivåer. Ruttbaserade vakter validerar autentisering och kontrollerar organisationsmedlemskap. org-access.guard verifierar att den autentiserade användaren är medlem i den organisation som anges i begäran. Rollbaserade vakter (OWNER, ADMIN, MEMBER) begränsar åtkomsten till administrativa operationer.

För användare med flera organisationer sätts organisationskontexten vid inloggning eller via slutpunkten för organisationsväxling. JWT-token är begränsade till en enda organisation, så ett byte av organisation utfärdar en ny token.

Multitenancy och dataisolering

Mandraki är en multitenant-plattform där dataisolering mellan organisationer tillämpas på applikationslagret. Varje databasfråga innehåller ett filter på organisations-ID. Frågemönstret i Prisma ORM säkerställer att dataåtkomst mellan organisationer är strukturellt förhindrad.

Organisationsmedlemskap spåras via tabellen OrgMembership, som registrerar relationen mellan användare och organisation tillsammans med användarens roll och flaggan för primär organisation. Domänverifierad automatisk tilldelning dirigerar nya registreringar till rätt organisation utifrån deras e-postdomän.

Granskningsloggning

Säkerhet handlar inte bara om förebyggande — den handlar också om upptäckt och ansvarsutkrävande. Mandraki för granskningsloggar över säkerhetsrelevanta operationer: autentiseringshändelser (inloggning, utloggning, återställning av token, misslyckade försök), förändringar i organisationsmedlemskap (inträden, utträden, rolländringar), krypteringsoperationer (nyckelgenerering, rotation, BYOK-import, återkallande), administrativa åtgärder (ändrade inställningar, domänverifiering, federationsbegäran) och händelser i samtalets livscykel (skapande, anslutning, lämnande, avslut, start och stopp av inspelning).

Granskningsloggar lagras med tidsstämpel, aktörsidentitet, åtgärdstyp och relevant metadata. De är åtkomliga för organisationsadministratörer via hanteringsgränssnittet och kan exporteras för integration med externa SIEM-system.

Nätverksarkitektur

Produktionsinfrastrukturen är segmenterad efter funktion. Databas- och Redis-servrar ligger i ett privat nätverk utan publik internetåtkomst. Applikationsservrar når datalagret via privata IP-adresser. SFU:n har publika portar för WebRTC-mediatrafik (UDP 40000–49999) och TURN-relä (UDP/TCP 3478, TLS 5349). HTTPS-trafik termineras vid nginx-omvändproxyn med Let’s Encrypt-certifikat.

SSH-åtkomst till servrarna använder Ed25519-nyckelautentisering utan lösenordsalternativ. Dataservern är endast åtkomlig via en jump-host från applikationsservrarna.

Överväganden kring incidenthantering

Vår arkitektur är utformad för att stödja snabb incidenthantering. BYOK-organisationer kan återkalla sin huvudnyckel för att omedelbart göra all data otillgänglig. Förnyelsetoken kan återkallas för att tvinga fram omautentisering i alla sessioner. Organisationsmedlemskap kan återkallas för att omedelbart avsluta en användares åtkomst. Federationsrelationer kan brytas för att isolera en organisation från externa samarbetspartner.

Dessa kontroller ger säkerhetsteam de mekanismer de behöver för att agera beslutsamt vid intrång.

Kontinuerlig förbättring

Säkerhetsarkitektur är aldrig färdig. Vi utvärderar kontinuerligt vår design mot nya hot, nya kryptografiska standarder och förändrade regulatoriska krav. Vårt åtagande är att vara transparenta om vår arkitektur, ärliga om dess begränsningar och noggranna i arbetet med att förbättra den.

Vi välkomnar frågor och synpunkter från säkerhetsteam som utvärderar Mandraki. Att sätta sig in i vår arkitektur i detalj är inte bara tillåtet — det uppmuntras.