Auto-hébergement

Lantern DSSE 0.4.2 apporte le réseau zéro confiance expérimental aux laboratoires à serveur unique

La nouvelle version open source de Lantern DSSE permet aux administrateurs système de déployer un réseau zéro confiance et une passerelle web sécurisée sur un seul serveur Linux à des fins de test.

Un rack de serveurs à l'intérieur d'une sphère de verre avec des cadenas numériques, symbolisant la sécurité zéro confiance.
Illustration créée pour cet article

Traduit automatiquement depuis l’original en anglais.

Lantern Networks a publié la version 0.4.2 de sa plateforme DSSE open source, permettant aux développeurs et aux administrateurs système d'héberger eux-mêmes une architecture réseau zéro confiance. Publiée le 12 novembre 2026, cette version expérimentale se concentre sur la simplification du déploiement de l'accès réseau zéro confiance (ZTNA) et des passerelles web sécurisées sur un seul serveur Linux. Bien qu'elle soit conçue pour les environnements de laboratoire plutôt que pour la production, elle offre un moyen concret de tester les stratégies de défense contre les ransomwares et le contrôle granulaire du trafic sans dépendre de services cloud tiers.

Ce qui s'est passé

La dernière version propose un processus d'installation simplifié permettant d'exécuter l'ensemble de la pile DSSE sous forme de conteneurs sur une seule machine. Le guide montre comment configurer le système sur une instance Ubuntu 24.04 avec Docker Engine et Compose v2. L'installateur gère la création des autorités de certification, des fichiers de configuration et de l'orchestration des conteneurs en une séquence de six étapes automatisées. Cette approche réduit la complexité généralement associée aux implémentations zéro confiance, qui nécessitent souvent plusieurs serveurs pour les plans de contrôle, les nœuds de bordure et les fournisseurs d'identité.

Une fois le serveur opérationnel, le système connecte les appareils clients, tels que les PC Windows, via un agent signé. L'architecture renforce la sécurité en interceptant le trafic interne et sortant. Les connexions internes sont limitées à des applications spécifiques via des connecteurs qui se connectent au Edge, tandis que l'accès Internet sortant est régi par des règles d'autorisation ou de refus. Chaque décision est journalisée, offrant une visibilité sur le comportement des appareils. Le système prend également en charge l'authentification hors bande, maintenant les connexions telles que SSH ou RDP jusqu'à ce que l'utilisateur vérifie son identité via un fournisseur d'identité externe utilisant OIDC.

Détails clés

  • Version et licence : La version est la 0.4.2-experimental et est distribuée sous la licence open source Apache-2.0.
  • Configuration requise : La configuration nécessite un serveur Linux x86-64 avec Docker Engine et Compose v2, spécifiquement testé sur une instance AWS de 4 vCPU et 16 GiB.
  • Temps d'installation : L'installateur automatisé complète le processus de déploiement en six étapes en environ quatre minutes, y compris le téléchargement des images.
  • Prise en charge des clients : Le guide détaille la connexion d'un PC Windows à l'aide de l'installateur DsseAgent-0.4.2-windows-x64.msi et la vérification des signatures avant l'enrôlement.
  • Fonctionnalités de sécurité : La plateforme inclut l'inspection TLS utilisant une autorité de certification personnalisée, le filtrage du trafic sortant et des journaux d'audit détaillés pour toutes les demandes autorisées et refusées.
  • Statut expérimental : Les auteurs indiquent explicitement que cette configuration à serveur unique est destinée uniquement aux tests, notant que si le serveur s'arrête, l'ensemble du service réseau s'arrête.

Contexte

L'accès réseau zéro confiance (ZTNA) est un modèle de sécurité qui suppose qu'aucun utilisateur ni appareil n'est fiable par défaut, même s'ils se trouvent à l'intérieur du périmètre du réseau de l'entreprise. Au lieu d'accorder un large accès basé sur l'emplacement réseau, le ZTNA vérifie l'identité et le contexte avant d'autoriser l'accès à des applications spécifiques. Une passerelle web sécurisée (SWG) complète cela en appliquant des politiques de sécurité pour le trafic web, en bloquant les sites malveillants et en empêchant les fuites de données. Traditionnellement, la mise en œuvre de ces technologies nécessite une infrastructure complexe ou des abonnements cloud coûteux. L'auto-hébergement de ces outils permet aux organisations de maintenir un contrôle total sur leurs données et leurs politiques de sécurité, bien que cela augmente la charge opérationnelle pour les équipes informatiques internes.

Pourquoi c'est important

Pour les équipes qui gèrent leur propre infrastructure, cette version offre un point d'entrée à faible barrière pour évaluer les principes zéro confiance. En exécutant toute la pile sur un seul serveur, les ingénieurs peuvent expérimenter des contrôles d'accès granulaires et l'inspection TLS sans s'engager dans un cluster multi-nœuds. Cela est particulièrement précieux pour les petites et moyennes entreprises qui doivent démontrer leur conformité ou tester des mécanismes de défense contre les ransomwares. La capacité d'inspecter le trafic chiffré et de journaliser chaque décision d'accès fournit la visibilité nécessaire pour détecter les appareils compromis avant qu'ils ne puissent se déplacer latéralement sur le réseau.

Cependant, la nature expérimentale de cette version signifie qu'elle n'est pas adaptée aux environnements de production critiques. La conception à point de défaillance unique implique que toute panne du serveur entraîne une interruption totale du réseau pour les appareils connectés. De plus, la gestion des clés privées pour l'autorité de certification racine du déploiement nécessite une sécurité opérationnelle stricte. Les équipes doivent peser les avantages des tests pratiques contre les risques liés à l'exécution de logiciels non éprouvés dans des environnements actifs. Elle sert mieux comme outil d'apprentissage ou prototype pour des déploiements futurs plus robustes.

Ce que vous pouvez faire

  • Mettre en place un environnement de laboratoire : Provisionnez un serveur Linux avec Docker pour tester le processus d'installation et vous familiariser avec la console DSSE et les fichiers de configuration.
  • Tester le filtrage du trafic : Configurez des règles d'autorisation et de refus pour des domaines spécifiques afin d'observer comment le système journalise les décisions et bloque le trafic sortant indésirable.
  • Évaluer l'inspection TLS : Importez le certificat racine du déploiement dans un client de test pour comprendre comment le système déchiffre et inspecte le trafic chiffré pour l'application des politiques.
  • Examiner les journaux d'audit : Analysez les journaux générés pour voir le niveau de détail des rapports concernant à la fois l'accès aux applications internes et les activités de navigation Internet.
  • Fournir des commentaires : Si vous testez le logiciel, signalez toute divergence entre le comportement attendu et votre expérience dans les issues GitHub du projet, en excluant les données sensibles.
  • Planifier la redondance : Utilisez cette expérience pour identifier les composants que vous devriez séparer sur différents serveurs pour une configuration de production à haute disponibilité.

Autres actualités

Toutes les actualités