Aplicación distribuida, políticas centrales, conmutación y recuperación automáticas.
El mismo motor que se ejecuta en una sola máquina en modo autónomo se ejecuta en sus concentradores en modo SASE. Los radios se conectan sobre una superposición cifrada. Las políticas se aplican en la entrada. La identidad viaja con el usuario. La conmutación es automática: la consola espera un umbral de silencio configurable, lo confirma con una comprobación de salud y después mueve todos los radios en una sola operación.
Cuatro formas, una superposición. El parque decide cuál.
Sin protocolos nuevos que aprender: el motor de Zedmos que ya conoce, envuelto en una superposición administrada que conecta sucursales, puntos de salida a la nube y personas remotas con un plano de políticas compartido. La forma que adopte es una elección sobre el lienzo: un concentrador, una pareja de concentradores, túneles directos entre los radios que los necesiten, o todas las sedes con todas. Cuando los dos extremos de una pareja están tras un NAT que reescribe puertos, un repetidor de la propia pila de la consola transporta los paquetes sin llegar nunca a tener una clave.
Radial
Todo llega a un mismo sitio. Empiece aquí salvo que tenga un motivo para no hacerlo.
El tráfico entre dos sedes da un rodeo, y se inspecciona por el camino.
Doble concentrador
Una caída en la sede del concentrador no debe llevarse por delante a las demás.
Un segundo concentrador a la escucha que hay que mantener. Solo guarda rutas de host hasta que se le necesita.
Atajo entre radios
Dos sedes hablan tanto entre sí que el rodeo cuesta tiempo de verdad.
El tráfico de esa pareja deja de pasar por el concentrador, así que deja de inspeccionarse allí.
Malla completa
Cada pareja habla con todas las demás. Con un límite de ocho sedes.
Cada sede mantiene un par por cada una de las demás, y un nodo sigue intermediando entre las parejas.
Cuando el concentrador principal deja de responder, la consola mueve las sedes, y las devuelve.
El monitor de la consola vigila el enlace del agente de cada concentrador principal. Pasado el umbral de silencio de la topología, mueve todos los radios al concentrador de reserva en una sola operación, y los devuelve cuando el principal lleva sano una ventana estable. También puede disparar el cambio usted mismo, con una vista previa exacta de lo que va a cambiar.
Cuatro preguntas sobre cada conexión, no una.
Una clave demuestra que hay un dispositivo, y nada más. Aquí el acceso remoto responde en cambio a cuatro cosas: quién es la persona, qué puede alcanzar, si eso sigue siendo cierto hoy y en qué estado está la máquina. Son cuatro de las cinco afirmaciones que el sector archiva bajo ZTNA 2.0; la quinta —una política de datos única que alcance los tenants SaaS— no la hacemos: la inspección es en línea, así que lo que pasa por el concentrador se inspecciona y lo que ya reposa en un tenant SaaS, no.
Quién es la persona
La inscripción puede exigir un inicio de sesión en su propio proveedor antes de que se genere ninguna clave, con el segundo factor requerido mediante la declaración amr del token. El dispositivo lleva esa identidad después, y el concentrador puede nombrar a la persona que hay detrás de un paquete.
Qué puede alcanzar
Un grupo de acceso concede aplicaciones concretas —una dirección y los puertos en los que responde— en lugar de la red en la que vive el servicio. El concentrador escribe una regla por aplicación y persona y descarta el resto, y al cliente se le indica que solo enrute lo que tiene permitido alcanzar.
Si sigue siendo cierto
Un plazo pone al dispositivo en reautenticación, se envía un recordatorio y, cuando vence, el dispositivo se apaga en el concentrador hasta que la persona vuelve a iniciar sesión. Un directorio que informa de que la cuenta está deshabilitada hace lo mismo, sin esperar al plazo.
En qué máquina está
El estado del dispositivo se lee del sistema de gestión que ya utiliza —Microsoft Intune o CrowdStrike Falcon— y nunca de un agente nuestro. Una máquina declarada no conforme se apaga y vuelve a entrar por sí sola en cuanto está sana; una máquina de la que nadie puede responder conserva su acceso, salvo que pida la lectura estricta.
Lo que esto no es: no hay proxy inverso ni acceso solo por navegador, así que cada persona se conecta con un cliente WireGuard estándar y las concesiones son por aplicación y no por URL. Nada puntúa el comportamiento. El tráfico permitido se sigue inspeccionando en el concentrador —prevención de intrusiones, filtrado de URL, inspección TLS, prevención de fuga de datos—, que es justo la parte que la mayoría de los intermediarios de acceso deja fuera.
Cinco pasos hasta una superposición SASE en marcha
Un orquestador endurecido gestiona la topología, la distribución de políticas, la correspondencia de identidades y la conmutación por error. Se ejecuta en un solo nodo para despliegues pequeños o como pareja redundante en producción.
- Modelo de topología preparado para multiinquilino
- Almacén de datos endurecido con acceso basado en roles
- Fuente central de verdad para las políticas y la identidad
Los nodos concentradores alojan el motor de Zedmos en postura enrutada, con una interfaz cifrada dedicada. Cada flujo de un radio pasa por DPI, políticas, inspección TLS y registro en el concentrador.
- El mismo motor que en Console: un binario, un comportamiento
- DPI en línea y aplicación de políticas en la entrada
- Los concentradores principal y de reserva se entregan como pareja activo-pasivo
Un radio puede ser un equipo OPNsense o pfSense de una sucursal, una pasarela Linux compacta o un usuario remoto con un cliente WireGuard estándar. Los equipos se registran con un token; los usuarios remotos se inscriben con un enlace de un solo uso.
- Registro con token para los equipos de sucursal
- Clientes WireGuard estándar para los usuarios remotos
- Reconexión y renovación de claves automáticas
Los servicios de directorio alimentan al concentrador con usuarios, grupos y dispositivos reconocidos. Cada flujo se etiqueta en el momento de la inspección, de modo que la política puede distinguir entre personas y no solo entre direcciones. Una conexión aparte vincula a una persona remota en la inscripción: su propio proveedor OpenID Connect, con una declaración de segundo factor exigida antes de que exista una clave.
- Active Directory mediante un agente en el controlador de dominio
- Entra / Azure AD mediante Microsoft Graph
- Integración SCIM con Okta y proveedores de identidad compatibles
- Su propio proveedor OpenID Connect para la inscripción, con MFA obligatorio
- Estado del dispositivo desde Microsoft Intune o CrowdStrike Falcon
Se activa por topología: la consola vigila el enlace del agente del concentrador principal y, tras el umbral de silencio y una comprobación de salud, mueve todos los radios al concentrador de reserva. La vuelta es automática en cuanto el principal se estabiliza.
- Umbral de silencio y periodo de enfriamiento por topología
- Vista previa antes de un cambio manual
- Vuelta automática al concentrador preferido