Autoalojamiento

Lantern DSSE 0.4.2 lleva la red de confianza cero experimental a laboratorios de un solo servidor

La nueva versión de código abierto de Lantern DSSE permite a los administradores de sistemas desplegar una red de confianza cero y una pasarela web segura en un único servidor Linux con fines de prueba.

Un rack de servidores dentro de una esfera de vidrio con cerraduras digitales, simbolizando la seguridad de confianza cero.
Ilustración creada para este artículo

Traducido automáticamente del original en inglés.

Lantern Networks ha lanzado la versión 0.4.2 de su plataforma DSSE de código abierto, que permite a desarrolladores y administradores de sistemas alojar por sí mismos una arquitectura de red de confianza cero. Publicado el 12 de noviembre de 2026, esta compilación experimental se centra en simplificar el despliegue del Acceso a Red de Confianza Cero (ZTNA) y las pasarelas web seguras en un único servidor Linux. Aunque está diseñado para entornos de laboratorio y no para producción, ofrece una forma tangible de probar estrategias de defensa contra ransomware y control granular del tráfico sin depender de servicios en la nube de terceros.

Qué ha ocurrido

El último lanzamiento proporciona un proceso de instalación simplificado para ejecutar todo el stack DSSE como contenedores en una sola máquina. La guía demuestra cómo configurar el sistema en una instancia de Ubuntu 24.04 con Docker Engine y Compose v2. El instalador gestiona la creación de autoridades de certificación, archivos de configuración y orquestación de contenedores en una secuencia de seis pasos automatizados. Este enfoque reduce la complejidad típicamente asociada con las implementaciones de confianza cero, que a menudo requieren múltiples servidores para planos de control, nodos de borde y proveedores de identidad.

Una vez que el servidor está operativo, el sistema conecta dispositivos cliente, como PCs Windows, mediante un agente firmado. La arquitectura impone seguridad interceptando el tráfico interno y saliente. Las conexiones internas están limitadas a aplicaciones específicas mediante conectores que marcan hacia el Edge, mientras que el acceso a Internet saliente se rige por reglas de permitir o denegar. Cada decisión se registra, proporcionando visibilidad sobre el comportamiento del dispositivo. El sistema también admite autenticación fuera de banda, manteniendo conexiones como SSH o RDP hasta que el usuario verifica su identidad a través de un proveedor de identidad externo usando OIDC.

Detalles clave

  • Versión y Licencia: El lanzamiento es la versión 0.4.2-experimental y se distribuye bajo la licencia de código abierto Apache-2.0.
  • Requisitos del Sistema: La configuración requiere un servidor Linux x86-64 con Docker Engine y Compose v2, probado específicamente en una instancia AWS de 4 vCPU y 16 GiB.
  • Tiempo de Instalación: El instalador automatizado completa el proceso de despliegue de seis pasos en aproximadamente cuatro minutos, incluyendo la descarga de imágenes.
  • Soporte de Clientes: La guía detalla cómo conectar un PC Windows utilizando el instalador DsseAgent-0.4.2-windows-x64.msi y verificar las firmas antes de la inscripción.
  • Características de Seguridad: La plataforma incluye inspección TLS utilizando una autoridad de certificación personalizada, filtrado de tráfico saliente y registros de auditoría detallados para todas las solicitudes permitidas y denegadas.
  • Estado Experimental: Los autores declaran explícitamente que este diseño de un solo servidor es solo para pruebas, señalando que si el servidor se detiene, todo el servicio de red se detiene.

Contexto

El Acceso a Red de Confianza Cero (ZTNA) es un modelo de seguridad que asume que ningún usuario o dispositivo es confiable por defecto, incluso si están dentro del perímetro de la red corporativa. En lugar de otorgar acceso amplio basado en la ubicación de la red, ZTNA verifica la identidad y el contexto antes de permitir el acceso a aplicaciones específicas. Una Pasarela Web Segura (SWG) complementa esto al imponer políticas de seguridad para el tráfico web, bloqueando sitios maliciosos y previniendo fugas de datos. Tradicionalmente, implementar estas tecnologías requiere infraestructuras complejas o suscripciones costosas a la nube. Alojar estas herramientas por sí mismos permite a las organizaciones mantener el control total sobre sus datos y políticas de seguridad, aunque aumenta la carga operativa para los equipos internos de TI.

Por qué importa

Para los equipos que gestionan su propia infraestructura, este lanzamiento ofrece un punto de entrada de baja barrera para evaluar los principios de confianza cero. Al ejecutar todo el stack en un solo servidor, los ingenieros pueden experimentar con controles de acceso granulares e inspección TLS sin comprometerse con un clúster multinodo. Esto es particularmente valioso para empresas pequeñas y medianas que necesitan demostrar cumplimiento o probar mecanismos de defensa contra ransomware. La capacidad de inspeccionar tráfico cifrado y registrar cada decisión de acceso proporciona la visibilidad necesaria para detectar dispositivos comprometidos antes de que puedan moverse lateralmente a través de la red.

Sin embargo, la naturaleza experimental de este lanzamiento significa que no es adecuado para entornos de producción críticos. El diseño de punto único de fallo implica que cualquier caída del servidor resulta en tiempo de inactividad total de la red para los dispositivos conectados. Además, gestionar las claves privadas para la autoridad de certificación raíz del despliegue requiere una seguridad operativa estricta. Los equipos deben sopesar los beneficios de las pruebas prácticas frente a los riesgos de ejecutar software no probado en entornos activos. Sirve mejor como herramienta de aprendizaje o prototipo para futuros despliegues más robustos.

Qué puedes hacer

  • Configurar un entorno de laboratorio: Aprovisiona un servidor Linux con Docker para probar el proceso de instalación y familiarizarte con la consola DSSE y los archivos de configuración.
  • Probar el filtrado de tráfico: Configura reglas de permitir y denegar para dominios específicos para observar cómo el sistema registra decisiones y bloquea tráfico saliente no deseado.
  • Evaluar la inspección TLS: Importa el certificado raíz del despliegue en un cliente de prueba para entender cómo el sistema descifra e inspecciona el tráfico cifrado para la aplicación de políticas.
  • Revisar los registros de auditoría: Analiza los registros generados para ver el nivel de detalle de los informes tanto para el acceso a aplicaciones internas como para actividades de navegación por Internet.
  • Proporcionar comentarios: Si pruebas el software, reporta cualquier discrepancia entre el comportamiento esperado y tu experiencia en los issues de GitHub del proyecto, excluyendo datos sensibles.
  • Planificar la redundancia: Usa este experimento para identificar los componentes que necesitarías separar en diferentes servidores para una configuración de producción de alta disponibilidad.

Más noticias

Todas las noticias