Sicherheitsarchitektur-Übersicht von Mandraki

Hinweis: Dieser Artikel beschreibt die Architektur und das Design von Mandraki. Einige besprochene Funktionen werden schrittweise ausgerollt und sind möglicherweise noch nicht in allen Plänen verfügbar.

Sicherheitsarchitektur ist nicht eine Funktionsliste. Es ist die Menge struktureller Entscheidungen, die bestimmen, wie sich ein System verhält, wenn Dinge schiefgehen — wenn ein Angreifer Zugriff bekommt, wenn eine Regierung einen Subpoena ausstellt, wenn ein Angestellter einen Fehler macht, wenn eine Festplatte gestohlen wird. Dieser Beitrag bietet einen umfassenden Überblick über die Sicherheitsarchitektur von Mandraki, einschließlich der Prinzipien, die unser Design leiten, der kryptografischen Systeme, die wir nutzen, und der operativen Kontrollen, die alles zusammenhält.

Design-Prinzipien

Vier Prinzipien unterliegen jeder Sicherheitsentscheidung in Mandraki.

Verteidigungsteifen. Keine einzelne Kontrolle sollte der Unterschied zwischen Sicherheit und Kompromiss sein. Verschlüsselung im Ruhezustand, Verschlüsselung in Transit, End-to-End-Verschlüsselung, Zugriffskontrolle, Audit-Protokollierung und Netzwerk-Segmentierung arbeiten konzertiert. Ein Fehler in einer Schicht sollte von den anderen enthalten sein.

Least Privilege. Benutzer, Dienste und Infrastruktur-Komponenten haben den minimalen Zugriff, der für ihre Funktion erforderlich ist. Der Datenbankserver ist nicht vom öffentlichen Internet erreichbar. Der SFU handhabt Medien, aber hat keinen Zugriff auf die Anwendungs-Datenbank. API-Endpunkte erfordern Authentifizierung und Organisations-Level-Autorisation.

Transparenz. Sicherheits-Ansprüche sollten verifizierbar sein. Wir dokumentieren unsere Verschlüsselungsformate, Schlüssel-Verwaltungs-Praktiken und Protokoll-Wahlen in technischem Detail. Wir verlassen uns nicht auf Verborgenheit.

Souveränität durch Design. Jede Komponente — Infrastruktur, Anwendung, Unternehmensteilnehmer — fällt in die EU-Gerichtsbarkeit. Das ist keine Bereitstellungs-Konfiguration; es ist eine strukturelle Eigenschaft des Systems.

Die dreischichtige Verschlüsselung-Hierarchie

Mandraki nutzt Umschlag-Verschlüsselung mit drei Schichten, ein Muster, das üblicherweise von Cloud-Providern und Finanzinstitutionen für sein Gleichgewicht von Sicherheit, Leistung und Schlüssel-Verwaltungs-Flexibilität verwendet wird.

Schicht 1: Master-Schlüssel. Die Wurzel der Schlüssel-Hierarchie. In Standard-Bereitstellungen ist das ein 256-Bit-AES-Schlüssel, der aus der MASTER_KEY-Umgebungsvariablen abgeleitet ist. In BYOK-Bereitstellungen wird das durch das Schlüsselmaterial des Kunden ersetzt (AWS-KMS-ARN, Azure-Key-Vault-Referenz oder manuell importierter Schlüssel). Der Master-Schlüssel verschlüsselt niemals Daten direkt — er umhüllt Organisations-Schlüssel.

Schicht 2: Organisations-Schlüssel. Einer pro Organisation. Jeder Org-Schlüssel ist ein 256-Bit-AES-Schlüssel, der von Mandraki generiert und in der Datenbank, umhüllt (verschlüsselt) durch den Master-Schlüssel, gespeichert wird. Um einen Org-Schlüssel zu nutzen, wird er im Speicher ausgewickelt, in einem LRU-Cache mit fünf Minuten TTL gecacht und nach Gebrauch verworfen. Ausgewickelte Schlüssel werden niemals auf die Festplatte geschrieben oder in Redis gespeichert. Org-Schlüssel umhüllen Datenverschlüsselungs-Schlüssel.

Schicht 3: Datenverschlüsselungs-Schlüssel (DEKs). Mehrere pro Organisation, einer pro Zweck: Nachrichten, Dateien, Aufzeichnungen, Transkripte. Jeder DEK wird durch den Organisations-Schlüssel seiner Organisation umhüllt. DEKs führen die tatsächliche Datenverschlüsselung mit AES-256-GCM durch. Das verschlüsselte Ausgabeformat ist [version:1B][iv:12B][authTag:16B][ciphertext], in einem einzigen Binärfeld gepackt.

Diese Hierarchie ermöglicht effiziente Schlüssel-Rotation. Einen Org-Schlüssel zu rotieren erfordert, die DEKs neu zu umhüllen (eine Schlüssel-Umhüllungs-Operation), aber nicht alle zugrunde liegenden Daten neu zu verschlüsseln. Einen DEK zu rotieren bedeutet, neue Daten nutzen den neuen Schlüssel, während alte Daten leesbar bleiben durch die behaltenen vorherigen DEK (markiert als ROTATED).

End-to-End-Verschlüsselung

Die oben beschriebene dreischichtige Hierarchie ist serverseitige Verschlüsselung — sie schützt Daten im Ruhezustand auf Mandraki-Infrastruktur. End-to-End-Verschlüsselung geht weiter, indem sie sicherstellt, dass der Server nie Klartext sieht.

Messaging (MLS). Wir nutzen das Messaging-Layer-Security-Protokoll (RFC 9420) für verschlüsseltes Messaging. MLS bietet Forward Secrecy und Post-Compromise Security durch seine TreeKEM-Schlüssel-Vereinbarungs-Struktur. MLS-Gruppen bilden auf Kanäle und DM-Threads ab. Jedes Gerät lädt einmalige Schlüssel-Pakete hoch, die asynchrone Gruppen-Operationen erlauben.

Medien (SFrame). Echtzeit-Medien in Anrufen werden mit SFrame (RFC 9605) via der WebRTC-Encoded-Transform-API verschlüsselt. Medien-Frames werden nach dem Codieren und vor der Packetisierung auf dem Sender verschlüsselt und nach Wiederversammlung und vor dem Decodieren auf dem Empfänger entschlüsselt. Der SFU leitet verschlüsselte Frames weiter, ohne Zugriff auf Klartext zu haben.

Serverseitige Verschlüsselung und E2EE koexistieren. Wenn E2EE aktiviert ist, werden Daten von Clients End-zu-End verschlüsselt und auch im Ruhezustand auf dem Server verschlüsselt. Die zwei Schichten adressieren unterschiedliche Bedrohungsmodelle: Serverseitige Verschlüsselung schützt gegen physische Infrastruktur-Kompromisse, während E2EE gegen Serverkompromisse schützt.

Authentifizierung und Autorisation

Mandraki nutzt JWT-basierte Authentifizierung mit kurzlebigen Zugriff-Token (fünfzehn Minuten) und länger lebigen Refresh-Token (sieben Tage). Zugriff-Token enthalten die Benutzer-Identität, den aktiven Organisations-Kontext und die Rolle.

Autorisation wird auf mehreren Ebenen durchgesetzt. Route-Level-Behörden validieren Authentifizierung und überprüfen Organisations-Mitgliedschaft. Die org-access.guard verifiziert, dass der authentifizierte Benutzer ein Mitglied der in der Anfrage spezifizierten Organisation ist. Rollengestützte Behörden (OWNER, ADMIN, MEMBER) beschränken den Zugriff auf administrative Operationen.

Für Multi-Organisations-Benutzer wird der Organisations-Kontext beim Login oder via dem Organisations-Wechsel-Endpunkt eingestellt. JWT-Token werden auf eine einzelne Organisation begrenzt, so dass der Organisations-Wechsel einen neuen Token ausstellt.

Multi-Tenancy und Datenisolation

Mandraki ist eine Multi-Tenant-Plattform, wo Datenisolation zwischen Organisationen auf der Anwendungs-Schicht durchgesetzt wird. Jede Datenbankabfrage umfasst einen Organisations-ID-Filter. Die Prisma-ORM-Abfrage-Muster sichern, dass Cross-Tenant-Datenzugriff strukturell verhindert wird.

Organisations-Mitgliedschaft wird durch die OrgMembership-Tabelle verfolgt, die die Benutzer-Organisations-Beziehung zusammen mit der Benutzer-Rolle und dem Primär-Organisations-Flag aufzeichnet. Domain-verifizierte Auto-Capture leitet automatisch neue Anmeldungen zur angemessenen Organisation basierend auf ihrer E-Mail-Domain.

Audit-Protokollierung

Sicherheit ist nicht nur über Prävention — es ist über Detektion und Verantwortung. Mandraki führt Audit-Protokolle für Sicherheits-relevante Operationen: Authentifizierungs-Ereignisse (Login, Logout, Token-Refresh, fehlgeschlagene Versuche), Organisations-Mitgliedschafts-Änderungen (Beitritt, Austritt, Rollen-Änderungen), Verschlüsselungs-Operationen (Schlüssel-Generierung, Rotation, BYOK-Import, Widerruf), administrative Aktionen (Settings-Änderungen, Domain-Verifizierung, Föderations-Anfragen) und Anruf-Lebenszyklen-Ereignisse (Erstellung, Beitritt, Austritt, Ende, Aufzeichnungs-Start und Stopp).

Audit-Protokolle werden mit Zeitstempel, Actor-Identität, Aktions-Typ und relevantem Metadaten gespeichert. Sie sind für Organisations-Administratoren via die Management-Schnittstelle erreichbar und können für Integration mit externen SIEM-Systemen exportiert werden.

Netzwerk-Architektur

Die Produktions-Infrastruktur wird nach Funktion segmentiert. Die Datenbank und Redis-Server befinden sich auf einem privaten Netzwerk ohne öffentlichen Internet-Zugang. Anwendungs-Server greifen auf die Datenschicht via private IP-Adressen zu. Der SFU hat öffentlich zugewandte Ports für WebRTC-Medien-Verkehr (UDP 40000-49999) und TURN-Relay (UDP/TCP 3478, TLS 5349). HTTPS-Verkehr wird am nginx-Reverse-Proxy mit Let’s-Encrypt-Zertifikaten beendet.

SSH-Zugriff zu Servern nutzt Ed25519-Schlüssel-Authentifizierung ohne Passwort-Fallback. Der Datenserver ist nur via Jump-Host von den Anwendungs-Servern erreichbar.

Incident-Response-Überlegungen

Unsere Architektur ist entworfen, um schnelle Incident-Response zu unterstützen. BYOK-Organisationen können ihren Master-Schlüssel widerrufen, um alle Daten sofort unzugänglich zu machen. Refresh-Token können widerrufen werden, um Neu-Authentifizierung über alle Sitzungen zu erzwingen. Organisations-Mitgliedschaft kann widerrufen werden, um den Benutzer-Zugriff sofort zu beendet. Föderations-Beziehungen können durchtrennt werden, um eine Organisation von externen Mitarbeitern zu isolieren.

Diese Kontrollen bieten die Mechanismen, die Sicherheits-Teams brauchen, um auf Kompromiss-Szenarien entscheidend zu reagieren.

Kontinuierliche Verbesserung

Sicherheitsarchitektur ist nie fertig. Wir evaluieren kontinuierlich unser Design gegen auftauchende Bedrohungen, neue Kryptografie-Standards und sich entwickelnde Regulierungs-Anforderungen. Unser Commitment ist, Transparenz über unsere Architektur zu erhalten, Ehrlichkeit über ihre Einschränkungen und Sorgfalt in ihrer Verbesserung.

Wir begrüßen Fragen und Feedback von Sicherheits-Teams, die Mandraki evaluieren. Unsere Architektur im Detail zu verstehen ist nicht nur erlaubt — es wird ermutigt.