Mandraki-beveiligingsarchitectuuroverzicht

Opmerking: Dit artikel beschrijft Mandraki’s architectuur en ontwerp. Sommige besproken functies worden geleidelijk uitgerold en zijn mogelijk niet in alle abonnementen beschikbaar.

Beveiligingsarchitectuur is geen functielijst. Het is de set structurele beslissingen die bepalen hoe een systeem zich gedraagt wanneer dingen fout gaan — wanneer een aanvaller toegang krijgt, wanneer een regering een dagvaarding geeft, wanneer een werknemer een fout maakt, wanneer een harde schijf wordt gestolen. Dit artikel biedt een uitgebreid overzicht van Mandraki’s beveiligingsarchitectuur, inclusief de principes die onze ontwerp leiden, de cryptografische systemen die we gebruiken en de operationele controles die alles aan elkaar binden.

Ontwerpprincipes

Vier principes liggen aan de basis van elke beveiligingsbeslissing in Mandraki.

Verdediging in diepte. Geen enkel controle hoort het verschil tussen beveiliging en compromis te zijn. Versleuteling in rust, versleuteling in transit, end-to-end-versleuteling, toegangscontroles, controlelogging en netwerkssegmentatie werken samen. Een uitval in een laag hoort ingeperkt te worden door de anderen.

Minste bevoegdheid. Gebruikers, services en infrastructuuronderdelen hebben de minimum-toegang vereist voor hun functie. De databaseserver is niet toegankelijk van het openbare internet. De SFU handelt media af maar heeft geen toegang tot de toepassingsdatabase. API-eindpunten vereisen authenticatie en organisatie-autorisatie.

Transparantie. Beveiligingsverantwoordingen zouden verifieerbaar moeten zijn. We documenteren onze versleutelingsindelingen, sleutelbeheer praktijken en protocolkeuzes in technische detail. We vertrouwen niet op duisternis.

Soevereiniteit door ontwerp. Elk onderdeel — infrastructuur, toepassing, bedrijfsentiteit — valt binnen de EU-rechtsmacht. Dit is geen implementatieconfiguratie; het is een structureel eigendom van het systeem.

De drielaagse versleutelingshiërarchie

Mandraki gebruikt envelopversleuteling met drie lagen, een patroon dat veel wordt gebruikt door cloudproviders en financiële instellingen vanwege haar balans van beveiliging, prestatie en flexibiliteit in sleutelbeheer.

Laag 1: Sleutel Beheerder. De wortel van de sleutelhiërarchie. In standaardimplementaties is dit een 256-bits AES-sleutel afgeleid van de MASTER_KEY-omgevingsvariabele. In BYOK-implementaties wordt dit vervangen door het sleutelmateriaal van de klant (AWS KMS ARN, Azure Key Vault-referentie of handmatig geïmporteerde sleutel). De Sleutel Beheerder versleutelt nooit gegevens direct — het omhult Organisatie-sleutels.

Laag 2: Organisatie-sleutels. Een per organisatie. Elke Org-sleutel is een 256-bits AES-sleutel gegenereerd door Mandraki en opgeslagen in de database omhulset (versleuteld) door de Sleutel Beheerder. Om een Org-sleutel te gebruiken, wordt het omhuld in geheugen, in de cache opgeslagen in een LRU-cache met een vijf-minuut TTL en na gebruik weggegooid. Niet-omhulde sleutels worden nooit naar schijf geschreven of in Redis opgeslagen. Org-sleutels omhullen Gegevensversleutelingssleutels.

Laag 3: Gegevensversleutelingssleutels (DEKs). Meerdere per organisatie, een per doel: berichten, bestanden, opnamen, transcripties. Elke DEK wordt omhuld door de Org-sleutel van zijn organisatie. DEKs voeren de werkelijke gegevensversleuteling uit met behulp van AES-256-GCM. De versleutelde uitvoerindeling is [versie:1B][iv:12B][authTag:16B][ciphertext], ingepakt in een enkel binair veld.

Deze hiërarchie maakt efficiënte sleutelrotatie mogelijk. Het roteren van een Org-sleutel vereist het omhullen van de DEKs (een sleutel-omhulseling-bewerking) maar niet opnieuw te versleutelen van alle onderliggende gegevens. Het roteren van een DEK betekent dat nieuwe gegevens de nieuwe sleutel gebruiken terwijl oude gegevens via de behouden vorige DEK (gemarkeerd als ROTATED) leesbaar blijven.

End-to-end-versleuteling

De drielaagse hiërarchie die hierboven wordt beschreven is versleuteling aan serverzijde — het beschermt gegevens in rust op Mandraki’s infrastructuur. End-to-end-versleuteling gaat verder door ervoor te zorgen dat de server nooit leesbare tekst ziet.

Berichten (MLS). We gebruiken het Messaging Layer Security-protocol (RFC 9420) voor versleutelde berichten. MLS biedt forward secrecy en post-compromisbeveiliging door zijn TreeKEM-sleutelovereenkomststructuur. MLS-groepen kaarten naar kanalen en DM-threads. Elk apparaat laadt eenmalige-gebruikssleutelpakketten op die asynchrone groepsbewerkingen toestaan.

Media (SFrame). Real-time media in oproepen wordt versleuteld met behulp van SFrame (RFC 9605) via de WebRTC Encoded Transform API. Mediaframes worden versleuteld na codering en vóór verpakking op de afzender, en ontsleuteld na herassemblage en vóór decodering op de ontvanger. De SFU stuurt versleutelde frames door zonder toegang tot leesbare tekst.

Server-zijde versleuteling en E2EE bestaan naast elkaar. Wanneer E2EE is ingeschakeld, worden gegevens end-to-end door clients versleuteld en ook versleuteld in rust op de server. De twee lagen beantwoorden aan verschillende bedreigingsmodellen: server-zijde versleuteling beschermt tegen fysieke infrastructuurcompromis, terwijl E2EE beschermt tegen servercompromis.

Verificatie en autorisatie

Mandraki gebruikt JWT-gebaseerde verificatie met kortlevende toegangstokens (vijftien minuten) en langlevende vernieuwingstokens (zeven dagen). Toegangstokens bevatten de identiteit van de gebruiker, actieve organisatiecontext en rol.

Autorisatie wordt op meerdere niveaus afgedwongen. Routebeveiliging valideert verificatie en controleert organisatielidmaatschap. De org-access.guard controleert dat de geverifieerde gebruiker lid is van de organisatie die in het verzoek is opgegeven. Op rollen gebaseerde bewakers (OWNER, ADMIN, MEMBER) beperken toegang tot beheersbewerkingen.

Voor multi-organisatiegebruikers wordt organisatiecontext ingesteld bij aanmelden of via het org-schakelaar-eindpunt. JWT-tokens zijn gericht op een enkele organisatie, dus schakelaars organisaties geven een nieuw token uit.

Multi-tenancy en gegevensisolatie

Mandraki is een multi-tenant platform waarbij gegevensisolatie tussen organisaties wordt afgedwongen op het applicatieniveau. Elke databasequery bevat een organisatie-ID-filter. De querypatronen van de Prisma ORM zorgen ervoor dat cross-tenant gegevenstoegang structureel wordt voorkomen.

Organisatielidmaatschap wordt bijgehouden via de OrgMembership-tabel, die de gebruiker-organisatierelatie registreert samen met de rol van de gebruiker en de vlag voor primaire organisatie. Domein-geverifieerde auto-capture routeert automatisch nieuwe aanmeldingen naar de juiste organisatie op basis van hun e-maildomein.

Controlelogging

Beveiliging gaat niet alleen om preventie — het gaat om detectie en verantwoordelijkheid. Mandraki onderhoudt controlelogboeken voor beveiligingsrelevante bewerkingen: verificatiegebeurtenissen (aanmelden, afmelden, token vernieuwen, mislukte pogingen), organisatielidmaatschapsveranderingen (toetredingen, vertrekken, rolveranderingen), versleutelingsbewerkingen (sleutelgeneratie, rotatie, BYOK-import, intrekking), beheersacties (instellingen wijzigen, domeinverificatie, federatieverzoeken) en oproeplevensgebeurtenissen (creatie, toetreding, vertrek, einde, opnamestarten en stoppen).

Controlelogboeken worden opgeslagen met tijdstempels, identiteit van de actor, actietype en relevante metagegevens. Ze zijn toegankelijk voor organisatiebeheerders via de beheerinterface en kunnen worden geëxporteerd voor integratie met externe SIEM-systemen.

Netwerkarchitectuur

De productieinfrastructuur is gesegmenteerd naar functie. De database- en Redis-servers bevinden zich op een particulier netwerk zonder openbare internettoegang. Toepassingsservers krijgen toegang tot de gegevenslaag via particuliere IP-adressen. De SFU heeft openbare poorten voor WebRTC-mediaverkeer (UDP 40000-49999) en TURN-relay (UDP/TCP 3478, TLS 5349). HTTPS-verkeer wordt beëindigd bij de nginx reverse proxy met Let’s Encrypt-certificaten.

SSH-toegang tot servers gebruikt Ed25519-sleutelverificatie zonder wachtwoord fallback. De gegevensserver is alleen toegankelijk via springhost van de toepassingsservers.

Incidentresponsoverwegingen

Onze architectuur is ontworpen om snelle incidentrespons te ondersteunen. BYOK-organisaties kunnen hun Sleutel Beheerder intrekken om onmiddellijk alle gegevens ontoegankelijk te maken. Vernieuwingstokens kunnen ingetrokken worden om herverificatie in alle sessies af te dwingen. Organisatielidmaatschap kan worden ingetrokken om onmiddellijk de toegang van een gebruiker te beëindigen. Federatierelaties kunnen worden verbroken om een organisatie van externe medewerkers te isoleren.

Deze controles bieden de mechanismen die beveiligingsteams nodig hebben om compromisscenario’s beslist te beantwoorden.

Continue verbetering

Beveiligingsarchitectuur is nooit voltooid. We evalueren ons ontwerp voortdurend tegen opkomende bedreigingen, nieuwe cryptografische standaarden en zich ontwikkelende regelgevingsvereisten. Onze inzet is transparantie over onze architectuur behouden, eerlijkheid over zijn beperkingen en zorgvuldigheid in zijn verbetering.

We verwelkomen vragen en feedback van beveiligingsteams die Mandraki evalueren. Onze architectuur in detail begrijpen is niet alleen toegestaan — het wordt aangemoedigd.