Aperçu de l'architecture de sécurité de Mandraki

Note : Cet article décrit l’architecture et la conception de Mandraki. Certaines fonctionnalités discutées sont déployées progressivement et peuvent ne pas encore être disponibles dans tous les plans.

L’architecture de sécurité n’est pas une liste de fonctionnalités. C’est l’ensemble des décisions structurelles qui déterminent le comportement d’un système quand les choses tournent mal — quand un attaquant gagne l’accès, quand un gouvernement émet une assignation, quand un employé fait une erreur, quand un disque dur est volé. Cet article fournit un aperçu complet de l’architecture de sécurité de Mandraki, incluant les principes qui guident notre conception, les systèmes cryptographiques que nous employons et les contrôles opérationnels qui lient tout ensemble.

Principes de conception

Quatre principes soutiennent chaque décision de sécurité dans Mandraki.

Défense en profondeur. Aucun contrôle unique ne devrait faire la différence entre la sécurité et le compromis. Le chiffrement au repos, le chiffrement en transit, le chiffrement de bout en bout, les contrôles d’accès, la journalisation d’audit et la segmentation du réseau travaillent de concert. Une défaillance dans une couche devrait être contenue par les autres.

Moindre privilège. Les utilisateurs, les services et les composants d’infrastructure ont l’accès minimum requis pour leur fonction. Le serveur de base de données n’est pas accessible depuis l’internet public. Le SFU gère les médias mais n’a pas accès à la base de données applicative. Les points de terminaison API requièrent l’authentification et l’autorisation au niveau organisationnel.

Transparence. Les allégations de sécurité doivent être vérifiables. Nous documentons nos formats de chiffrement, nos pratiques de gestion des clés et nos choix de protocoles en détail technique. Nous ne comptons pas sur l’obscurité.

Souveraineté par conception. Chaque composant — infrastructure, application, entité d’entreprise — relève de la juridiction de l’UE. Ce n’est pas une configuration de déploiement ; c’est une propriété structurelle du système.

La hiérarchie de chiffrement trois couches

Mandraki utilise le chiffrement d’enveloppe avec trois couches, un modèle couramment utilisé par les fournisseurs de cloud et les institutions financières pour son équilibre entre sécurité, performance et flexibilité de gestion des clés.

Couche 1 : Clé maître. La racine de la hiérarchie des clés. Dans les déploiements standard, c’est une clé AES 256-bit dérivée de la variable d’environnement MASTER_KEY. Dans les déploiements BYOK, cela est remplacé par le matériel de clé du client (ARN AWS KMS, référence Azure Key Vault ou clé importée manuellement). La clé maître ne chiffre jamais les données directement — elle enveloppe les clés organisationnelles.

Couche 2 : Clés organisationnelles. Une par organisation. Chaque clé d’organisation est une clé AES 256-bit générée par Mandraki et stockée dans la base de données enveloppée (chiffrée) par la clé maître. Pour utiliser une clé d’organisation, elle est désenveloppée en mémoire, mise en cache dans un cache LRU avec un TTL de cinq minutes et rejetée après use. Les clés désenveloppées ne sont jamais écrites sur disque ou stockées dans Redis. Les clés organisationnelles enveloppent les clés de chiffrement de données.

Couche 3 : Clés de chiffrement de données (DEKs). Plusieurs par organisation, une par purpose : messages, fichiers, enregistrements, transcriptions. Chaque DEK est enveloppé par la clé organisationnelle de son organisation. Les DEKs effectuent le chiffrement des données réelles en utilisant AES-256-GCM. Le format de sortie chiffrée est [version:1B][iv:12B][authTag:16B][ciphertext], emballé dans un single binary field.

Cette hiérarchie permet la rotation efficace des clés. Faire pivoter une clé d’organisation nécessite de ré-envelopper les DEKs (une opération de wrapping de clé) mais ne nécessite pas de ré-chiffrer toutes les données sous-jacentes. Faire pivoter une DEK signifie que les nouvelles données utilisent la nouvelle clé tandis que les anciennes données restent lisibles via la DEK précédente conservée (marquée comme ROTATED).

Chiffrement de bout en bout

La hiérarchie trois couches décrite ci-dessus est le chiffrement côté serveur — elle protège les données au repos sur l’infrastructure de Mandraki. Le chiffrement de bout en bout va plus loin en s’assurant que le serveur ne voit jamais du texte clair.

Messagerie (MLS). Nous utilisons le protocole de sécurité de la couche de messagerie (MLS), standardisé en tant que RFC 9420 par l’IETF. MLS fournit la secret de succession et la sécurité post-compromis via sa structure d’accord de clé TreeKEM. Les groupes MLS se mappent sur les canaux et les fils de messages directs. Chaque appareil télécharge des paquets de clés à usage unique qui permettent les opérations de groupe asynchrones.

Médias (SFrame). Les médias en temps réel dans les appels sont chiffrés en utilisant SFrame (RFC 9605) via l’API WebRTC Encoded Transform. Les trames médias sont chiffrées après l’encodage et avant la packetisation à l’expéditeur, et déchiffrées après le réassemblage et avant le décodage au récepteur. Le SFU transmet les trames chiffrées sans accès au texte clair.

Le chiffrement côté serveur et E2EE coexistent. Quand E2EE est activé, les données sont chiffrées de bout en bout par les clients et aussi chiffrées au repos sur le serveur. Les deux couches adressent des modèles de menace différents : le chiffrement côté serveur protège contre le compromis d’infrastructure physique, tandis que E2EE protège contre le compromis du serveur.

Authentification et autorisation

Mandraki utilise l’authentification basée sur JWT avec des jetons d’accès éphémères (quinze minutes) et des jetons de rafraîchissement de plus longue durée (sept jours). Les jetons d’accès contiennent l’identité de l’utilisateur, le contexte organisationnel actif et le rôle.

L’autorisation est appliquée à plusieurs niveaux. Les gardes au niveau des routes valident l’authentification et vérifient l’appartenance à l’organisation. La garder org-access.guard vérifie que l’utilisateur authentifié est un membre de l’organisation spécifiée dans la requête. Les gardes basées sur les rôles (OWNER, ADMIN, MEMBER) restreignent l’accès aux opérations administratives.

Pour les utilisateurs multi-organisations, le contexte organisationnel est défini à la connexion ou via le point de terminaison de changement d’organisation. Les jetons JWT sont scoped à une seule organisation, donc changer d’organisation émet un nouveau jeton.

Multi-location et isolement des données

Mandraki est une plateforme multi-tenant où l’isolement des données entre les organisations est appliqué au niveau de la couche applicative. Chaque requête de base de données inclut un filtre d’ID d’organisation. Les modèles de requête ORM de Prisma assurent que l’accès aux données entre tenants est structurellement prévenu.

L’appartenance à l’organisation est suivie via la table OrgMembership, qui enregistre la relation utilisateur-organisation ainsi que le rôle de l’utilisateur et le drapeau d’organisation primaire. L’auto-capture vérifié par domaine achemine automatiquement les nouvelles inscriptions vers l’organisation appropriée en fonction de leur domaine de messagerie.

Journalisation d’audit

La sécurité ne concerne pas seulement la prévention — elle concerne la détection et la responsabilité. Mandraki maintient les journaux d’audit pour les opérations pertinentes en matière de sécurité : événements d’authentification (connexion, déconnexion, rafraîchissement de jeton, tentatives échouées), changements d’appartenance organisationnelle (adhésions, départs, changements de rôle), opérations de chiffrement (génération de clé, rotation, importation BYOK, révocation), actions administratives (changements de paramètres, vérification de domaine, demandes de fédération) et événements du cycle de vie des appels (création, participation, départ, fin, début et arrêt de l’enregistrement).

Les journaux d’audit sont stockés avec timestamps, identité de l’acteur, type d’action et métadonnées pertinentes. Ils sont accessibles aux administrateurs de l’organisation via l’interface de gestion et peuvent être exportés pour intégration avec les systèmes SIEM externes.

Architecture du réseau

L’infrastructure de production est segmentée par fonction. Les serveurs de base de données et Redis se trouvent sur un réseau privé sans accès à l’internet public. Les serveurs d’application accèdent à la couche de données via des adresses IP privées. Le SFU a des ports publiques pour le trafic médias WebRTC (UDP 40000-49999) et le relais TURN (UDP/TCP 3478, TLS 5349). Le trafic HTTPS est terminé au proxy reverse nginx avec certificats Let’s Encrypt.

L’accès SSH aux serveurs utilise l’authentification par clé Ed25519 sans fallback de mot de passe. Le serveur de données est accessible uniquement via jump host depuis les serveurs d’application.

Considérations de réponse aux incidents

Notre architecture est conçue pour supporter la réponse rapide aux incidents. Les organisations BYOK peuvent révoquer leur clé maître pour rendre immédiatement toutes les données inaccessibles. Les jetons de rafraîchissement peuvent être révoqués pour forcer la ré-authentification sur toutes les sessions. L’appartenance à l’organisation peut être révoquée pour terminer immédiatement l’accès d’un utilisateur. Les relations de fédération peuvent être rompues pour isoler une organisation des collaborateurs externes.

Ces contrôles fournissent les mécanismes dont les équipes de sécurité ont besoin pour répondre aux scénarios de compromis de manière décisive.

Amélioration continue

L’architecture de sécurité n’est jamais terminée. Nous évaluons continuellement notre conception par rapport aux menaces émergentes, aux nouvelles normes cryptographiques et aux exigences réglementaires en évolution. Notre engagement est de maintenir la transparence sur notre architecture, l’honnêteté sur ses limitations et la diligence dans son amélioration.

Nous accueillons les questions et retours des équipes de sécurité évaluant Mandraki. Comprendre notre architecture en détail n’est pas seulement permis — c’est encouragé.