Mandrakis säkerhetsarkitektur — en översikt

Säkerhetsarkitektur är inte en funktionell lista. Det är den uppsättning strukturella beslut som bestämmer hur ett system beter sig när saker går fel — när en angripare får åtkomst, när en myndighet utfärdar en stämning, när en anställd gör ett misstag, när en hårddisk stjäls. 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 i djupled. Inga enskilda kontroller ska vara skillnaden mellan säkerhet och kompromiss. Kryptering i vila, kryptering under överföring, end-to-end-kryptering, åtkomstkontroller, granskningsloggning och nätverkssegmentering arbetar i samverkan. Ett fel i ett lager ska inneslutas av de andra.

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

Transparens. Säkerhetsanspråk ska vara verifierbara. Vi dokumenterar våra krypteringsformat, nyckelhanteringspraxis och protokollval i teknisk detalj. Vi förlitar oss inte på oklarhet.

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

Den tre-lagers krypteringshierarkin

Mandraki använder kuvertkryptering med tre lager, ett mönster som vanligtvis används av molnleverantörer och finansiella institutioner för sin balans mellan säkerhet, prestanda och nyckelhanteringsflexibilitet.

Lager 1: Huvudnyckel. Roten till nyckelhierarkin. I standarddistributioner är detta en 256-bitars AES-nyckel som härrör från MASTER_KEY-miljövariabeln. I BYOK-distributioner ersätts detta av kundens nyckelmaterial (AWS KMS ARN, Azure Key Vault-referens eller 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. För att använda en organisationsnyckel, avslutas den i minnet, cachelagras i en LRU-cache med en femminuters TTL och kasseras efter användning. Avslutna nycklar skrivs aldrig till disk eller lagras i Redis. Organisationsnycklar omsluter datakrypteringsnycklar.

Lager 3: Datakrypteringsnycklar (DEK). Flera per organisation, en per syfte: meddelanden, filer, inspelningar, transkriptioner. Varje DEK är omsluten av organisationsnyckeln. DEK utför den faktiska datakrypteringen med hjälp av 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 om-omslutning av DEK (en nyckelomslutningsoperation) men inte om-kryptering av all underliggande data. Att rotera en DEK innebär att ny data använder den nya nyckeln medan gammal data förblir läsbar genom den behållna tidigare DEK (markerad som ROTATED).

End-to-end-kryptering

Den tre-lagers hierarki som beskrivs ovan är server-sidig kryptering — 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 Messaging Layer Security-protokollet (RFC 9420) för krypterade meddelanden. MLS tillhandahåller framåtriktad sekretess och post-kompromiss-säkerhet genom sin TreeKEM-nyckelöverenskommelsestruktur. MLS-grupper mappar 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 hjälp av SFrame (RFC 9605) via WebRTC Encoded Transform API. Media-ramar krypteras efter kodning och före paketering på avsändaren och dekrypteras efter omkonstruktion och före avkodning på mottagaren. SFU vidarebefordrar krypterade ramar utan åtkomst till klartext.

Server-sidig kryptering och E2EE samexisterar. När E2EE är aktiverat, krypteras data end-to-end av klienter och också krypteras i vila på servern. De två lagren hanterar olika hotmodeller: server-sidig kryptering skyddar mot fysisk infrastrukturkompromiss, medan E2EE skyddar mot serverkompromiss.

Autentisering och auktorisering

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

Auktorisering är påtvingad 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 åtkomst till administrativa operationer.

För användare med flera organisationer, ställs organisationskontexten in vid inloggning eller via organisationsväxlings-slutpunkten. JWT-token är begränsade till en enda organisation, så att växling av organisationer utfärdar en ny token.

Multitenancy och dataisolering

Mandraki är en multitenantplattform där dataisolering mellan organisationer är påtvingad på applikationslagret. Varje databasfråga innehåller en organisations-ID-filter. Prisma ORM:s frågemönster säkerställer att tvär-organisationsdataåtkomst är strukturellt förhindrad.

Organisationsmedlemskap spåras genom OrgMembership-tabellen, som registrerar användar-organisationsrelationen tillsammans med användarens roll och primär organisationsflagga. Domän-verifierad auto-capture dirigerar automatiskt nya registreringar till rätt organisation baserat på deras e-postdomän.

Granskningsloggning

Säkerhet är inte bara förebyggande — det handlar om upptäckt och ansvar. Mandraki underhåller granskningsloggar för säkerhetsrelevanta operationer: autentiseringshändelser (inloggning, utloggning, token-återställning, misslyckade försök), organisationsmedlemskapsändringar (inträden, utträden, rolländringar), krypteringsoperationer (nyckelgenerering, rotation, BYOK-import, återkallande), administrativa åtgärder (inställningsändringar, domänverifiering, federationsbegäran) och samtalslivscykelhändelser (skapande, anslutning, utträde, slut, inspelning start och stopp).

Granskningsloggar lagras med tidsstämplar, aktöridentitet, aktionstyp och relevant metadata. De är tillgängliga 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 finns på ett privat nätverk med ingen offentlig internetåtkomst. Applikationsservrar har åtkomst till datalagret via privata IP-adresser. SFU har offentliga portar för WebRTC-mediatrafik (UDP 40000-49999) och TURN-relä (UDP/TCP 3478, TLS 5349). HTTPS-trafik avslutas vid nginx-reverseproxyn med Let’s Encrypt-certifikat.

SSH-åtkomst till servrar använder Ed25519-nyckelautentisering utan lösenordsåterställning. Dataservern är endast tillgänglig via jump-host från applikationsservrar.

Incidenthanteringsöverväganden

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örnyelse-token kan återkallas för att tvinga om-autentisering över 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 tillhandahåller de mekanismer som säkerhetsteam behöver för att svara på kompromisscenarioer beslutsamt.

Kontinuerlig förbättring

Säkerhetsarkitektur är aldrig färdig. Vi utvärderar kontinuerligt vår design mot nya hot, nya kryptografiska standarder och utvecklande regulatoriska krav. Vårt åtagande är att upprätthålla transparens om vår arkitektur, ärlighet om dess begränsningar och flit i dess förbättring.

Vi välkomnar frågor och feedback från säkerhetsteam som utvärderar Mandraki. Att förstå vår arkitektur i detalj är inte bara tillåtet — det uppmuntras.