Skip to main content

Sécurité fédérée ou spam ?

Dans le domaine des applications de messagerie sécurisée, il existe deux types distincts de "fédération". Il est essentiel de connaître la différence et les implications entre les deux si votre priorité est une communication privée, protégée et conforme.

Lorsque vous envisagez la fédération, si vous avez affaire à des communications sensibles, précieuses, réglementées ou classifiées, il n'y a qu'un seul choix légitime à faire. Chez Wire, notre approche de la fédération, comme tout ce que nous faisons, est conçue pour offrir la meilleure sécurité possible tout en la rendant délicieusement invisible pour les utilisateurs finaux, ce qui permet une productivité et une agilité maximales.

La conception des applications révèle ses priorités

Lorsqu'il s'agit de produits liés à la sécurité, il est facile de se perdre dans une mer de termes techniques sophistiqués. C'est d'autant plus vrai lorsqu'il s'agit de cryptographie, que seule une infime partie des personnes, même techniques, comprennent vraiment. Cependant, on oublie souvent que la conception d'une application a un impact significatif sur la sécurité. En examinant la façon dont l'application est conçue - les choix qu'elle fait - vous pouvez comprendre ce qu'elle privilégie et si cela correspond ou non aux priorités de votre organisation.

SignalGate nous a fourni une étude de cas sur le rôle joué par les choix de conception des applications (par opposition à la cryptographie). Signal utilise un protocole d'échange de clés cryptographiques très compétent et un chiffrement de bout en bout, mais il a tout de même permis l'une des violations les plus scandaleuses de l'histoire récente. Pourquoi ? Tout simplement parce que Signal n'est pas conçu pour créer et protéger des frontières dans le but de sécuriser les communications des entreprises ou des gouvernements. C'est pourquoi il n'y a pas de notion de membres "internes" par rapport aux membres "externes" ou "invités" dans un groupe. Il est conçu pour une utilisation occasionnelle par les consommateurs, avec un vaste bassin mondial ouvert de participants pour encourager l'adoption virale, similaire à une application de média social. Le choix d'utiliser Signal pour des communications classifiées est une faute grave, car il est clair qu'il n'a jamais été conçu pour cela. On pourrait dire la même chose de WhatsApp, et c'est pourquoi il est terriblement risqué d'en autoriser l'utilisation dans tout cadre organisationnel sensible à la sécurité.

Gardez cette notion de choix de conception d'application à l'esprit lorsque vous examinez la fédération.

Fédération : Ouverte ou modérée - pour quoi faire ?

Techniquement parlant, la fédération, dans ses termes les plus simples, signifie que deux serveurs ou plus qui sont administrativement autonomes peuvent communiquer et échanger des informations à l'aide d'un protocole commun. Il existe deux façons très différentes de faire fonctionner une fédération : ouverte et fermée.

Fédérations ouvertes : conçues pour la croissance, pas pour la sécurité

La fédération "ouverte" est un choix de conception visant à déployer la fédération de manière à ce que tout serveur puisse librement se connecter et communiquer avec n'importe quel autre serveur, sans approbation préalable. Cela signifie que la fédération est

  • décentralisée (désagrégée) et sans permission
  • N'importe qui peut mettre en place un serveur et rejoindre le réseau.
  • Les serveurs peuvent automatiquement découvrir d'autres serveurs et se fédérer avec eux.

Les exemples de fédérations ouvertes sont le courrier électronique alimenté par SMTP et, dans le cas des "communications sécurisées", Matrix/Element.

L'objectif d'une fédération ouverte est de donner la priorité à la croissance de l'écosystème en abaissant la barrière à l'entrée. Toutefois, cet objectif s'oppose à la priorité donnée à la sécurité, puisque, par nature, il est impossible d'empêcher le spam, le phishing et d'autres abus et menaces. La modération et la protection des données incombent aux administrateurs de serveurs individuels, et il est impossible de faire en sorte que le modèle global réponde aux normes de sécurité ou de conformité de manière prévisible.

Il convient de noter que cet objectif de conception est très similaire à l'orientation des médias sociaux de Signal ou de WhatsApp : créer une communauté mondiale et virale. Et les dangers sont similaires. Dans le cas d'Element et de Matrix, il existe une différence fascinante par rapport à Signal. Signal est un service unique et non une fédération ouverte, il ne souffre donc pas de problèmes de spam et de phishing, alors que le modèle de fédération ouverte de Matrix/Element, à l'instar de l'email/SMTP, en souffre très certainement. Le serveur domestique par défaut de Matrix n'exige même pas que vous utilisiez un courriel pour valider votre compte, ce qui permet à n'importe qui de s'inscrire et de mettre en place un serveur, et c'est pourquoi, comme pour le courrier électronique, Matrix a connu tant de problèmes de spam et de phishing.

La fédération ouverte est ouverte à la croissance virale, mais aussi au spam, au phishing et aux autres menaces qui l'accompagnent. Si vous êtes une entreprise à la recherche d'une messagerie et d'une collaboration sécurisées à des fins de communication hors bande ou de crise, ou si vous traitez des informations sensibles, précieuses ou classifiées, vous ne devriez jamais opter pour un modèle de fédération ouverte. Tout comme Signal est un choix inapproprié pour ces cas d'utilisation organisationnels, toute application déployée avec un modèle d'exploitation de fédération ouverte l'est également, même si, comme Signal, elle utilise un chiffrement de bout en bout compétent (E2EE).

Fédérations modérées - conçues pour la sécurité, la confidentialité et la conformité

Lafédération modérée signifie que l'application est conçue pour protéger les frontières et tout ce qui se trouve à l'intérieur de ces frontières. En règle générale, cela signifie que la fédération est.. :

  • configurée manuellement ou basée sur une liste blanche
  • L'interopérabilité est basée sur des serveurs connus
  • Basée sur un modèle de confiance contrôlé

Un excellent exemple de modèle de fédération modérée qui donne la priorité à la sécurité et répond aux critères ci-dessus est la fédération SSO utilisant SCIM, OAuth2 ou OIDC, car ils fonctionnent toujours dans une relation de confiance prédéfinie entre un fournisseur d'identité (IdP) et un fournisseur de services (par exemple GitHub ou toute autre application). Dans la fédération SSO, il n'y a pas de découverte automatique, pas de connexions ouvertes ou sans permission. En fait, il n'y a aucun moyen pour un tiers de participer à une fédération sans autorisation préalable. Et c'est tout à fait approprié, car l'objectif du SSO est d'offrir aux utilisateurs finaux une expérience d'accueil et de connexion aux applications qui soit à la fois simple et hautement sécurisée.

Si votre organisation cherche à utiliser une messagerie sécurisée ou une application de collaboration dans le but de protéger des données sensibles ou classifiées, un modèle de fédération modérée est la seule considération possible pour vous. C'est pourquoi Wire met en œuvre un modèle de fédération modérée, avec des tonnes de contrôles administratifs, et avec une échelle de classe entreprise, y compris le routage SSO automatisé basé sur le domaine entre les instances de Wire fédérées à travers notre Wire Cloud, cloud privé, et les back-ends de Wire sur site.

En outre, le service public et gratuit de Wire est exploité avec une éthique de conception similaire. Contrairement à la création de comptes anonymes dans le homeserver de Matrix, Wire exige au minimum un courriel pour la validation du compte, de sorte qu'il n'y a pas d'inscriptions anonymes, ce qui décourage les bots et les comptes sockpuppet. Wire permet aux utilisateurs d'un même serveur de se retrouver s'ils connaissent l'identifiant de l'autre utilisateur, mais les administrateurs peuvent configurer des règles pour limiter la visibilité de la recherche. Wire a utilisé des essais en conditions réelles pour trouver le moyen le plus sûr d'activer les demandes de contact, de sorte que même dans le nuage Wire, avec une communauté de millions d'utilisateurs mondiaux disposant d'un compte gratuit, les possibilités de pollupostage sont réduites. Il n'y a pas d'annuaires ou de salles globales, de sorte que les spammeurs ne peuvent pas facilement récupérer des noms d'utilisateur ou diffuser des messages indésirables. Wire évite le spam par ses choix de conception, même dans son service gratuit.

Les fédérations fermées sont conçues pour la sécurité, pas pour le spam 😉 .

Il est possible de construire un modèle de fédération " modérée " et de le rendre de toute façon peu sûr.

Voici une excellente étude de cas sur la conception d'applications contradictoires, appliquée aux fédérations. Microsoft Teams prend en charge les fédérations entre les instances Teams dans le service cloud Microsoft 365. De par sa conception, il a été conçu pour être fermé. Cependant, Microsoft configure intentionnellement par défaut toutes les instances Teams avec la fédération activée et ouverte pour accepter toute connexion de manière permissive ( !). Si vous ne désactivez pas explicitement cette fonction, votre messagerie d'entreprise est fortement menacée. Malheureusement, cela a eu des implications dans le monde réel, car des pirates ont mis en place des instances Teams, analysé d'autres instances Teams, identifié des configurations non corrigées, établi des fédérations et se sont fait passer pour des membres du personnel informatique d'entreprises, exploitant ainsi leurs données. C'est incroyable, mais vrai.

Il n'y a pas de différence inhérente entre les fédérations ouvertes et les fédérations modérées.

Un mythe véhiculé par certains fournisseurs du secteur est que seule une fédération ouverte peut évoluer.

L'exemple ultime d'une fédération modérée qui est massivement évolutive est l'Internet. Le routage sur l'internet est un système fédéré à autorisation. Tout d'abord, pour annoncer des itinéraires sur l'internet, en tant qu'organisation, vous devez vous enregistrer et obtenir une autorisation avec un numéro de système autonome (ASN). Ensuite, vous devez vous mettre d'accord avec d'autres organisations autorisées à exploiter des systèmes autonomes, afin d'échanger des routes avec elles. Il n'y a pas de peering ouvert par défaut. Le routage Internet est manifestement très évolutif. Il n'y a pas de problème. Il est modéré de par sa conception, car un modèle de fédération ouverte reproduirait les problèmes de sécurité du courrier électronique, mais d'une manière beaucoup plus grave et dommageable. Il rendrait l'internet peu fiable en tant qu'infrastructure de communication.

Dans le monde de la messagerie sécurisée et des applications de collaboration qui n'est pas lié à Internet, la plupart des serveurs (y compris Wire, Element, etc.) utilisent une certaine forme de TLS pour communiquer entre eux à des fins de fédération. Il n'y a pas de différence inhérente à l'évolutivité.

Bannissons donc l'idée qu'un système de fédération modérée ne peut pas évoluer. Cependant, vous devez faire un choix de conception, comme dans le routage Internet, pour utiliser un modèle de fédération modérée afin de maintenir la sécurité.

La mise à l'échelle des fédérations ne doit pas être synonyme d'insécurité

Si la réponse d'un fournisseur à l'extensibilité consiste à ouvrir toutes grandes les portes du Far West de la fédération ouverte, vous obtenez l'"extensibilité" de la commodité, mais au prix de risques de sécurité élevés. Si vous construisez un système fédéré de serveurs à grande échelle pour les communications entre joueurs, c'est très bien. Mais si vous essayez d'établir des communications sécurisées entre des filiales ou des organisations de la chaîne d'approvisionnement dans un secteur critique ou réglementé, c'est une démarche risquée.

Dans le cas de Wire, nous avons été choisis par certaines des plus grandes organisations du monde pour sécuriser des ensembles à grande échelle d'organisations filiales fédérées et même des fournisseurs tiers de la chaîne d'approvisionnement, en raison de notre évolutivité. Wire vous permet de fédérer de nombreuses instances sur site, dans un nuage privé et dans Wire Cloud sans aucun problème de mise à l'échelle. En outre, en vous fédérant avec Wire Cloud, vous pouvez également accéder à des millions d'utilisateurs gratuits et payants dans le monde entier.

Notre évolutivité va au-delà de la fédération. Wire est la seule plateforme de collaboration sécurisée qui utilise la norme Internet Messaging Layer Security, ce qui permet d'augmenter considérablement l'échelle des communications de groupe E2EE par rapport aux protocoles précédents tels que Signal, Olm/Megolm, etc.

Une fédération ouverte s'accompagne souvent d'une authentification faible

Une autre considération concernant la sécurité de la fédération et les choix de conception est la rigueur de l'authentification. La barre plus basse qui est généralement fixée pour les modèles de fédération ouverte affecte le calibre des mesures de sécurité telles que l'authentification. Par exemple, dans Matrix, l'authentification de la fédération se fait par vérification de la clé publique découverte via des URL, des serveurs de clés ou des enregistrements DNS bien connus. Cette méthode est considérée comme vulnérable au détournement de DNS, sujette à des configurations erronées et à des retards dans la révocation des clés. Un autre exemple est que les fédérations ouvertes autorisent généralement le "tout" par défaut. Par exemple, avec Matrix, tout serveur peut tenter de se fédérer à moins d'être explicitement bloqué, ce qui signifie qu'il est possible de lancer des exploits centrés sur la fédération.

Les modèles de fédération modérée favorisent des mesures de sécurité plus rigoureuses. Par exemple, Wire fonctionne dans un mode de refus de toutes les fédérations par défaut, de sorte qu'un administrateur doit spécifiquement autoriser la fédération avec un domaine particulier. Une fois cette autorisation configurée, l'administrateur de Wire doit fournir le certificat de l'autre domaine, émis par une autorité de certification de confiance. Cela permet d'éviter les attaques par détournement de DNS et rend les attaques de type "man-in-the-middle" (MITM) presque impossibles.

Comparaison de la sécurité d'une fédération modérée et d'une fédération ouverte

Voici une analyse des dimensions de sécurité et du comportement des fédérations modérées par rapport aux modèles de fédérations ouvertes.

Dimension

Fédération modérée

Fédération ouverte

Contrôle des limites de confiance

Seuls les serveurs pré-approuvés sont autorisés, les limites de confiance sont étroitement définies et appliquées.

Tout serveur peut se joindre à la fédération, mais chaque participant doit évaluer et gérer individuellement la confiance.

Vérification de l'identité

L'identité fédérée est authentifiée et souvent validée de manière centralisée (par exemple, SSO).

Les revendications d'identité sont souvent non vérifiées, les utilisateurs peuvent provenir de sources inconnues ou non fiables.

Chiffrement de bout en bout (E2EE)

Peut appliquer les politiques E2EE à tous les nœuds de confiance ; garantit que les points d'extrémité connus respectent les normes de chiffrement.

Prend techniquement en charge l'E2EE, mais est plus difficile à appliquer ; certains nœuds peuvent rétrograder ou mal gérer l'E2EE.

Résidence et souveraineté des données

Garantit que les données restent au sein d'une infrastructure conforme ou alignée sur la juridiction.

Les données peuvent transiter par des serveurs inconnus situés dans des juridictions différentes, ce qui pose des problèmes de conformité.

Contrôle d'accès et application des politiques

Application centralisée des politiques de sécurité (par exemple, MFA, confiance dans les appareils, restrictions d'utilisation).

L'application des politiques est fragmentée et repose sur des configurations d'instances individuelles.

Auditabilité et journalisation

Visibilité totale sur toutes les communications inter-serveurs et les actions des utilisateurs ; les journaux sont fiables et centralisés.

Les journaux peuvent être incomplets, incohérents ou inaccessibles sur les serveurs fédérés.

Confinement des vulnérabilités

L'attaque ou la compromission d'un nœud est plus facile à isoler, les nœuds de confiance sont régulièrement contrôlés.

Une faille dans un nœud fédéré peut propager des risques dans toute la fédération (spam, logiciels malveillants, etc.).

Défense contre les serveurs malveillants

Un contrôle rigoureux empêche les serveurs malveillants de se connecter.

Il faut s'appuyer sur des listes de blocage/heuristiques pour détecter et isoler les mauvais acteurs après coup.

Alignement sur la conformité

Conçu pour les besoins réglementaires : HIPAA, GDPR, CJIS, ISO 27001, etc.

L'application de la conformité est décentralisée, plus difficile à garantir pour tous les participants.

"Communications sécurisées" et "fédération ouverte" : une contradiction dans les termes. Choisissez judicieusement.

Envisageriez-vous un jour un système SSO permettant à n'importe quelle entité d'installer un serveur, puis de découvrir et de se connecter automatiquement à votre instance Salesforce et de laisser des personnes aléatoires se balader dans vos données de vente ? Espérons que non.

De même, vous ne devriez pas choisir une application de "communication sécurisée" qui fonctionne sur la base d'une fédération ouverte. Vous vous exposeriez ainsi au spam, au phishing, voire à pire encore.

Découvrez comment Wire fournit les communications E2EE les plus sûres, basées sur le MLS, qui s'adaptent aux exigences des entreprises et des gouvernements.

Télécharger le livre blanc.

Wire

As a leader in secure communication, we empower businesses and government agencies with expert-driven content that helps protect what matters. Stay ahead with industry trends, compliance updates, and best practices for secure digital exchanges.

Articles similaires

Abonnez-vous à notre newsletter