Configurar Sophos ZTNA: runbook de configuración completo

Sophos Zero Trust Network Access, o ZTNA, controla el acceso a aplicaciones y sitios web internos mediante identidades, grupos y políticas. Una configuración completa requiere un servicio de directorio, un proveedor de identidad, un gateway, un concepto de certificados y DNS, políticas y recursos. El acceso nativo a aplicaciones locales utiliza el agente ZTNA; las aplicaciones web pueden ofrecerse sin agente. Además, existe una vía independiente de RDP/SSH sin agente mediante Protected Browser completo, con recursos y políticas propios. La extensión del navegador no basta para ello; esto no implica compatibilidad general con cualquier protocolo de aplicaciones locales.

Este runbook describe la arquitectura global y el orden de configuración correcto. No sustituye la planificación detallada de un gateway ni los runbooks especializados para controladores de dominio, RDP o SSH. Empiece con una sola aplicación, un grupo piloto y una vía de retorno documentada. Amplíe el alcance únicamente cuando las pruebas positiva y negativa sean correctas.

Respuesta directa: el orden correcto

Configure Sophos ZTNA en este orden:

Compruebe la licencia, el acceso de administrador, las plataformas y la aplicación de destino.
Defina el tipo de acceso y el modo del gateway.
Sincronice usuarios y grupos de seguridad desde Microsoft Entra ID o Active Directory.
Configure el proveedor de identidad y pruebe su conexión.
Proporcione el certificado wildcard, el dominio y el gateway.
Configure la resolución DNS pública y privada.
Cree una política ZTNA pequeña.
Despliegue el agente ZTNA solo donde lo requiera el tipo de acceso.
Cree el recurso con exactamente una política y los grupos previstos.
Pruebe el acceso autorizado y no autorizado, así como los registros.
Solo entonces migre más usuarios, aplicaciones y ubicaciones.

Sophos Fusion es el nivel de administración. El gateway, el agente, el servicio de directorio, el proveedor de identidad, el certificado, DNS, la política y el recurso siguen siendo dependencias técnicas separadas. Por ello, un inicio de sesión correcto no demuestra que la aplicación sea accesible o esté restringida correctamente.

Requisitos, licencia y roles

Licencia y operación de prueba

Sophos ZTNA forma parte de Sophos Workspace Protection. La licencia está disponible como suscripción independiente, mediante MSP Flex o en el paquete Sophos Endpoint Plus Workspace Protection. En Workspace Protection, la cantidad necesaria se basa en el consumo más alto de los productos incluidos; en ZTNA se cuentan los usuarios autenticados únicos durante 30 días. El mismo tipo de licencia cubre el acceso con y sin agente, y los gateways locales y Sophos Cloud Gateway.

La licencia independiente de Workspace Protection no incluye una licencia de Sophos Endpoint. El despliegue con agente requiere además una licencia Endpoint aplicable y capacidad para instalar Sophos Endpoint Agent. Esto es independiente de que la licencia ZTNA cubra ambos métodos de acceso.

Sophos Cloud Gateway tiene además un límite medio de transferencia de 15 GB por usuario y mes. Una licencia de prueba dura normalmente 30 días. En un tenant de prueba se permiten como máximo 1.000 entradas por tipo de objeto, por ejemplo usuarios, grupos o dispositivos. Cuando caduca la licencia, los productos de Workspace Protection dejan de estar disponibles en Sophos Fusion; la configuración se conserva y vuelve a aparecer tras la renovación.

Active y compruebe la licencia mediante el icono de perfil > Licensing. Para una prueba estructurada, utilice Iniciar y evaluar de forma segura una prueba de Sophos Fusion.

Responsabilidades

Antes de realizar cambios deben estar claros, como mínimo, estos roles:

Administrador de Sophos Fusion: puede configurar fuentes de directorio, proveedores de identidad, gateways, políticas y recursos. Para configurar una fuente de directorio AD se requiere un administrador de la consola de administración de Sophos Central.
Administrador de identidad: crea el registro de la aplicación, Client Secret, grupos, Redirect URI y, en su caso, cuentas de invitado en el proveedor de identidad.
Responsable de DNS y certificados: puede crear registros DNS públicos e internos, confirmar la propiedad del dominio y renovar certificados.
Administrador de red o firewall: proporciona el enrutamiento, las conexiones salientes, NAT y las reglas de firewall para el modo de gateway elegido.
Application Owner: conoce el FQDN interno o la IP de destino, los puertos, la autenticación, las redirecciones y el criterio de aceptación funcional.
Responsable de endpoints: distribuye Sophos Endpoint Agent con el componente ZTNA y comprueba los sistemas operativos compatibles.

No guarde Client Secrets, contraseñas de bind ni claves privadas en el ticket o el runbook. Documente en su lugar el responsable, la ubicación de almacenamiento, la fecha de caducidad y el proceso de rotación.

Comprobación técnica previa

Antes del primer clic, compruebe:

Host del gateway: VMware ESXi 6.5 o posterior, o Hyper-V en Windows Server 2016 o posterior. En ambos casos, Sophos indica al menos 2 núcleos de CPU, 4 GB de RAM y 80 GB de almacenamiento; se recomienda SSD. La fecha y la hora deben ser correctas y la zona horaria debe ser UTC.
Sophos Firewall como gateway: SFOS 19.5 MR3 o posterior y administración mediante Sophos Fusion. Se admiten firewalls de hardware, cloud, virtuales y de software. Algunas funciones nuevas pueden requerir una versión de SFOS posterior.
Certificado: certificado wildcard de Let’s Encrypt o de una CA de confianza. Se admiten RSA de 2048 bits como mínimo y ECDSA, pero no P-384 ni P-521.
Directorio: Microsoft Entra ID o Active Directory local con grupos mantenidos. Los grupos de Entra para ZTNA deben estar habilitados para seguridad.
Proveedor de identidad: Microsoft Entra ID, Okta o Active Directory local.
Plataforma del agente: Windows 10 1803 o posterior, o macOS 11 Big Sur o posterior.
Aplicación: puertos estáticos y conocidos. No se admiten aplicaciones con asignación dinámica de puertos o rangos de puertos muy grandes, como productos VoIP antiguos.
Red: accesibilidad interna y resolución privada de nombres desde el gateway hasta la aplicación. En gateways locales también deben ser accesibles los destinos salientes exigidos por Sophos; la inspección SSL/TLS no debe interrumpir las conexiones necesarias del gateway.

Para la arquitectura, el dimensionamiento y las reglas de red del gateway, consulte Planificar y crear un gateway Sophos ZTNA.

Valores de ejemplo para este runbook

Sustituya todos los valores por los suyos. No mezcle dominios de prueba y producción.

Finalidad	Valor de ejemplo
Grupo piloto	`ZTNA-Pilot-Finance`
FQDN del gateway	`ztna.example.net`
FQDN externo del recurso	`wiki.example.net`
Destino interno	`wiki.intern.example.net`
Puerto web	`443/TCP`
Política	`ZTNA-Pilot-Healthy`
Recurso	`Wiki-Pilot`
PoP principal	`Europe (Frankfurt) Region`
Usuario de prueba permitido	`ztna-allow@example.net`
Usuario de prueba bloqueado	`ztna-deny@example.net`

1. Elegir la vía de acceso y el modo del gateway

Sin agente o con agente

La tabla siguiente compara el acceso web clásico sin agente con el acceso nativo mediante el agente ZTNA. El caso de despliegue independiente con Protected Browser completo se explica debajo:

Requisito	Sin agente	Con agente
Aplicación web o sitio web	Sí	Sí
Aplicación local, por ejemplo una aplicación TCP nativa	No	Sí
Comprobar el estado del dispositivo	No	Sí
Sophos Endpoint Agent necesario	No	Sí
FQDN externo del recurso resoluble públicamente	Sí	No
Aviso si el recurso no está disponible	Solo en este modo	No

El acceso web clásico sin agente descrito aquí controla aplicaciones y sitios web; no evalúa el estado del dispositivo. Una política con agente puede comprobar el estado de seguridad y restringir todos los tipos de recurso compatibles. Las políticas y los recursos con agente no funcionan hasta que el componente ZTNA esté instalado en los dispositivos.

Protected Browser completo y su extensión no son equivalentes: la extensión utilizada en otro navegador no evalúa el estado de integridad del endpoint. Por ello, las condiciones de protección del endpoint solo se aplican al tráfico de Protected Browser completo. Las sesiones RDP y SSH sin agente mediante Protected Browser son casos de despliegue independientes; cree para ellas una política ZTNA sin agente, un recurso estrictamente limitado y los objetos correspondientes de Protected Browser. No copie sin más una política de aplicación web en destinos administrativos RDP o SSH.

Gateway local o Sophos Cloud Gateway

Gateway local: el appliance virtual reside en el centro de datos propio y es accesible desde Internet. Usted administra la instancia y necesita puertos de firewall y reglas NAT adecuados.
Sophos Cloud Gateway: Sophos opera el plano de datos cloud. Una instancia de gateway en el centro de datos conecta ese plano con los recursos internos; no se requieren exposición directa a Internet, aperturas de puertos entrantes ni reglas NAT para la vía de acceso.

Los modos son intercambiables y se puede migrar. Aun así, trate la migración como un cambio controlado: DNS, certificado, PoP, nombres externos y pruebas deben ajustarse a la nueva ruta de datos.

En el modo cloud, elija el Point of Presence (PoP) próximo al centro de datos, no automáticamente próximo a los usuarios. Hay regiones disponibles en Irlanda, Fráncfort, Ohio, Oregón, Mumbai y Sídney. Desde ZTNA 2.1 se configura de forma predeterminada un PoP secundario vecino para la conmutación por error automática. Cambie el PoP en My Products > ZTNA > Gateways: abra el gateway, seleccione Edit, cambie la región en Points of Presence y guarde.

2. Preparar el servicio de directorio y los grupos

ZTNA autoriza mediante grupos de usuarios sincronizados. Cree primero un grupo piloto pequeño y habilitado para seguridad, y añada solo al usuario de prueba permitido. Para la prueba negativa se necesita un segundo usuario ajeno al grupo.

Sincronizar Microsoft Entra ID

La guía paso a paso Sincronizar Microsoft Entra ID con Sophos Fusion sigue siendo la referencia detallada. Para ZTNA son especialmente importantes estos puntos:

Registre la aplicación ZTNA en Entra ID.
Para gateways ESXi y Hyper-V, añada https://<gateway-fqdn>/oauth2/callback; para gateways Sophos Firewall, añada https://<gateway-fqdn>/ztna-oauth2/callback como Redirect URI. Se admiten varios FQDN de gateway.
Anote Client ID, Tenant ID y el valor de Client secret al crearlo. El valor del secreto no puede volver a mostrarse después.
Conceda únicamente los permisos Microsoft Graph necesarios y el consentimiento de administrador requerido.
Cree o seleccione grupos habilitados para seguridad. Compruébelo expresamente en grupos importados desde el portal de Microsoft 365 o desde AD.
En Sophos Fusion, abra Global Settings > Directory service o Access control > Sign-in & identity y añada Microsoft Entra ID.
Configure el dominio, Client ID, Client secret, su periodo de validez y la programación Hourly, Daily, Weekly, Monthly o None.
Limite los usuarios y grupos que se sincronizarán al alcance realmente necesario. Guarde y compruebe el resultado en My Environment > Users & groups.

No se pueden sincronizar varias fuentes de Entra ID del mismo dominio. Office 365 GCC High no es compatible con esta sincronización. Si el UPN y el inicio de sesión del endpoint no coinciden, pueden crearse usuarios duplicados o no vinculados. Si más tarde cambia el nombre de un grupo Entra ya asignado, el nombre no se actualiza automáticamente en la asignación; vuelva a asignar el grupo.

Sincronizar Active Directory local

Para AD, descargue Active Directory Synchronization Setup en Global Settings > Directory service. Los requisitos son .NET Framework 4.6.2 en el equipo de sincronización, credenciales de API de Sophos con el rol Service Principal Directory Sync indicado en la ayuda de sincronización de AD en inglés, usuarios y direcciones de correo únicos, y las reglas de firewall o proxy necesarias. La guía de configuración en alemán utiliza Service Principal Active Directory Sync; contraste la aclaración sobre el nombre del rol de AD Sync con el rol real del tenant, sin presuponer IDs de rol idénticos ni permisos adicionales.

Valide Client ID y Client Secret en el programa de configuración.
Para LDAP, utilice una cuenta con acceso de lectura al bosque y el mínimo de permisos posible.
Mantenga activado Use LDAP over SSL connection siempre que sea posible. Son habituales el puerto 636 para LDAPS y el 389 para una conexión no segura.
Seleccione conjuntamente usuarios y grupos de usuarios. Lo mismo se aplica a dispositivos y grupos de dispositivos.
Limite el alcance con Base Distinguished Names y filtros LDAP, por ejemplo OU=Finance,DC=example,DC=net.
Tras la configuración inicial o un cambio de filtros, ejecute primero una vista previa y sincronización manual. Una sincronización manual puede tardar hasta 15 minutos.

No sincronice al mismo tiempo usuarios y grupos del mismo dominio desde AD y Entra ID. Los grupos primarios de usuarios de AD no se sincronizan para ZTNA; los usuarios afectados deben pertenecer además a otro grupo de AD. Los cambios en Base DN o filtros pueden retirar objetos importados del ámbito de búsqueda y eliminarlos de Sophos Fusion. Elimine las cuentas inactivas del directorio de origen en vez de ocultarlas solo de la sincronización.

Acceso de invitados

Para usuarios externos puede utilizar Microsoft Entra B2B. Compruebe previamente si el tenant permite la colaboración externa, qué dominio puede invitarse y quién aprueba las invitaciones. Los invitados pueden añadirse individualmente o mediante una operación por lotes controlada. Cree un grupo de invitados independiente, sincronícelo con Sophos Fusion y asigne solo los recursos necesarios. El Application Owner debe conocer la fecha de salida y el patrocinador de cada cuenta de invitado.

Añadir manualmente un usuario

Si un usuario no se sincroniza desde un directorio, abra My Environment > Users & groups, seleccione Add user e introduzca First and last name, Email address y, cuando proceda, Role, Manager, Exchange login y Add to groups (optional). Asigne un rol administrativo solo si es necesario; User solo da acceso al portal de autoservicio. Active Email setup link únicamente si el usuario debe proteger su propio dispositivo y dispone de derechos de administrador local y acceso a Internet. Guarde y compruebe que aparece en la lista y en el grupo ZTNA previsto. Si no, revise el correo, el filtro de grupos y si el directorio debe ser la fuente autoritativa.

3. Configurar el proveedor de identidad

Abra Sophos Central > My Products > ZTNA > Identity providers > Add identity provider o My Products > ZTNA > Identity providers. Solo puede haber una entrada por proveedor de identidad. Evite caracteres especiales como ., @ o # en el nombre, ya que la configuración podría no guardarse.

Microsoft Entra ID

Seleccione Microsoft Entra ID (Azure AD).
Introduzca nombre, descripción, Client ID, Tenant ID y Client secret.
Pruebe la conexión.
Guarde solo después de una prueba correcta.

Active Directory local

Seleccione Microsoft AD (on-prem).
Introduzca el host y el puerto del servidor AD principal y, opcionalmente, un servidor secundario del mismo dominio.
Active TLS o StartTLS. Si selecciona Verify SSL certificate, cargue un certificado .pem, .crt o .cer de 10 KB como máximo.
Introduzca Bind DN, la contraseña de bind y el Base DN para usuarios y grupos de usuarios.
Opcionalmente, active Captcha y una contraseña de un solo uso por correo electrónico con configuración SMTP.
Asigne el proveedor de identidad a un gateway. Después, vuelva a abrir el proveedor, seleccione el gateway en Test Connection y, opcionalmente, un nombre de usuario. Si se indica un usuario, la prueba muestra también sus grupos.

Para usar AD como proveedor de identidad, un gateway ESXi o Hyper-V debe utilizar al menos ZTNA 2.1; en Sophos Firewall se requiere como mínimo SFOS 19.5 MR3. El campo de correo electrónico del usuario de prueba debe ser válido. En este escenario, ZTNA solo admite un dominio, no varios dominios secundarios de un bosque. Con AD local, los usuarios deben autenticarse la primera vez que accedan a recursos detrás de cada gateway y solo pueden estar autenticados en un dispositivo a la vez.

Okta

Para Okta necesita grupos sincronizados y un servidor de autorización OIDC. El gateway debe usar como mínimo la versión 1.1. Cree en Okta una aplicación web OIDC, active Client Credentials y Refresh Token, use la ruta de callback adecuada y asigne los grupos. Después introduzca Client ID, Client Secret e Issuer URI en ZTNA. Un servidor de autorización Okta propio requiere una licencia API Access Management.

Inicio de sesión federado en Sophos Fusion

El inicio federado de la administración de Sophos Fusion es una ruta distinta del proveedor ZTNA anterior. Necesita derechos de Super Admin y debe verificar primero el dominio en Access control > Sign-in & identity > Sophos sign-in con el TXT record generado. Después abra Access control > Sign-in & identity > Federated identity providers y seleccione Add identity provider:

Introduzca nombre y descripción sin ., @ ni #.
Elija Microsoft Entra ID, OpenID Connect o Microsoft AD FS. Entra requiere Tenant ID; OIDC, Client ID, Issuer, Authorization endpoint y JWKS URL; AD FS, su URL de metadatos.
Asigne el dominio verificado. Puede añadir varios, pero cada usuario solo puede pertenecer a uno.
Elija conscientemente IdP-enforced MFA o No IdP-enforced MFA; con la segunda opción, Sophos Fusion exige MFA después de autenticar el IdP.
Guarde y active el proveedor. Los datos incompletos o no válidos impiden activarlo.

Active el inicio federado solo cuando todos los administradores y usuarios afectados tengan dominio y proveedor. Pruebe una cuenta administrativa limitada en una ventana privada y conserve abierta una sesión funcional de Super Admin como retorno. Si falla, desactive el proveedor desde esa sesión y revise dominio, endpoints, confianza del certificado y MFA.

Seleccionar un proveedor de identidad en Sophos ZTNA

4. Proporcionar el gateway, los dominios y el certificado

Planifique y cree el gateway según Planificar y crear un gateway Sophos ZTNA. Utilice un certificado wildcard para varios recursos del mismo dominio. Para Let’s Encrypt, consulte Crear un certificado wildcard de Let’s Encrypt.

Para la vía Let’s Encrypt administrada por Sophos Fusion, abra My Products > ZTNA > Settings > Domains and certificates y seleccione Add domain. Fusion genera un CNAME para _acme-challenge.<domain>. Publique exactamente nombre y destino en el DNS público, conserve el CNAME para renovaciones y seleccione Verify. El estado debe quedar verificado. Copie el destino completo; algunos proveedores requieren un punto final. Cambie al CNAME actual cualquier dominio validado antes con TXT. Después de añadir un dominio, regenere el único certificado administrado de la cuenta para incluirlo.

La verificación DNS manual de Certbot para un wildcard propio es independiente: solo en ella se publica el TXT solicitado por Certbot. Cargue certificado, cadena completa y clave privada y compruebe dominio y Subject Alternative Names. Solo estará operativo cuando un cliente externo confíe en toda la cadena. La emisión completa permanece en el runbook enlazado.

5. Configurar DNS

Gateway local

Para una configuración sin agente necesita públicamente:

un registro A para el FQDN del gateway, por ejemplo ztna.example.net,
un CNAME por recurso dirigido al FQDN del gateway, por ejemplo wiki.example.net,
el gateway y los recursos sin agente en el mismo dominio.

Para el acceso con agente basta con el registro A público del gateway; los recursos no necesitan CNAME público. El gateway debe poder resolver internamente el FQDN de destino. Como alternativa, introduzca la IP interna de destino al crear el recurso.

Sophos Cloud Gateway

Confirme la propiedad del dominio con el CNAME generado por Sophos. Publique después el CNAME del alias del gateway. Para cada recurso sin agente, añada otro CNAME al alias de recurso mostrado. Los recursos con agente no necesitan un CNAME público de recurso.

Compruebe cada nombre desde tres perspectivas:

públicamente desde una red externa,
internamente desde la red del gateway,
desde el dispositivo piloto en el modo de acceso previsto.

El agente intercepta el tráfico por FQDN, no por dirección IP. Si una aplicación web redirige a otro FQDN, cree también el FQDN de redirección como recurso.

6. Crear una política

Abra Sophos Central > My Products > ZTNA > Policies > Add policy o My Products > ZTNA > Policies.

Seleccione Add policy.
Elija Agent o Agentless según el recurso.
Asigne un nombre único, por ejemplo ZTNA-Pilot-Healthy.
En una política con agente, mantenga activado Use access control conditions en Access rules.
En Allow access, seleccione el estado de seguridad necesario.
Guarde.

Una política define el método de acceso y las condiciones. Los grupos de usuarios se asignan al recurso, no a la política. Solo es posible una política por recurso; una nueva asignación sustituye a la anterior.

Las políticas sin agente no tienen reglas de estado del dispositivo. Si aparece Request agent en la página de la política, ya puede crearla, pero para las pruebas con agente debe esperar al aprovisionamiento e instalación del agente.

7. Agente y casos de acceso especiales

Instale el componente ZTNA mediante Sophos Endpoint Agent únicamente en el grupo piloto. Compruebe después en el endpoint que el agente está configurado y ha recibido la política esperada.

En My Products > ZTNA > Settings puede establecer el tiempo de inactividad del túnel del agente en 5, 15 o 30 minutos, o 1 hora; el valor predeterminado es 5 minutos. El túnel se restablece automáticamente al aparecer tráfico nuevo. El tiempo mínimo antes de que un cambio de estado del dispositivo active una regla evita bloqueos innecesarios por problemas breves de estado.

En Windows, Do not monitor local traffic puede evitar el hairpinning en la oficina. Requiere al menos Sophos Core Agent 2025.2.1.709. Introduzca un FQDN y una IP en Sophos Fusion y la misma asociación en el DNS interno. Si la resolución coincide, el agente envía el tráfico local directamente por la LAN. Active esta opción solo si los recursos deben ser accesibles por LAN sin ZTNA; según la documentación asignada del producto, aún no está disponible en macOS.

Planifique por separado los casos especiales:

Granja RDS: Complete primero la granja y su pertenencia al dominio según la documentación actual de Microsoft. En My Products > ZTNA > Resources & access > Add resource, elija gateway, Access method: Agent, Resource type: Remote Desktop Protocol (RDP), FQDN externo del RD Gateway, puertos necesarios (el ejemplo documentado usa 3389, 443 y 80), FQDN interno o IP y grupo piloto. Desde el equipo piloto con Windows abra https://<rd-gateway-fqdn>/rdweb, descargue el RDP y conecte. Debe abrirse una sesión en un Session Host. Una captura debe mostrar tráfico ZTNA en TAP/TUN y ningún tráfico directo al RD Gateway o Session Host en la interfaz principal. Si no, revise agente, tipo, puertos, DNS y broker/gateway RDS antes de ampliar.
Control SaaS: Úselo solo si SaaS admite listas de IP. Añada la aplicación como recurso, asigne solo el grupo necesario y deje vacío Internal FQDN/IP address para usar el FQDN externo. En SaaS permita únicamente la IP o rango público de la interfaz NAT anterior al gateway. El piloto debe entrar por ZTNA; un usuario no autorizado o ruta directa fuera del rango debe fallar. Si no, compare el NAT de salida real con la lista y revise grupo, FQDN y ruta.
Windows Hello: Esta vía sin contraseña basada en claves exige Microsoft Entra ID, licencia Azure Premium, Windows 10 u 11, ZTNA ya configurado y servidor de aplicaciones en el mismo dominio que el dispositivo. En Azure active la unión en Devices > Device settings. En Intune active Hello en Devices > Windows enrollment > Windows Hello for Business para todos, o cree en Devices > Configuration profiles > Create profile un perfil Windows 10 and later > Templates > Identity protection para el piloto. Una el dispositivo en Settings > Accounts > Access work or school > Connect > Join this device to Azure Active Directory, reinicie, entre con Entra y configure MFA y PIN o biometría. Instale después el agente. El acceso directo a una app con agente, incluidos CIFS o RDP, no debe volver a pedir el IdP; Sophos Endpoint debe mostrar ZTNA configurado y usuario autenticado. Si no, revise unión, perfil, login Hello, dominio común y agente. Confirme los menús con la documentación actual de Microsoft.
En la oficina: elija conscientemente entre la misma ruta ZTNA externa y el acceso LAN directo. Evite el hairpinning involuntario.
Controlador de dominio: créelos como recursos con agente para dispositivos Windows. Desde Endpoint 2026.1, Sophos admite varios controladores de dominio; la prioridad y ponderación de los registros SRV generados automáticamente permiten conmutación por error y equilibrio de carga. Para una configuración concreta de tres DC, utilice Configurar varios controladores de dominio con Sophos ZTNA en vez de recrear el failover en un recurso web general.

8. Crear un recurso y asignar acceso

Abra Sophos Central > My Products > ZTNA > Resources & access > Add resource o My Products > ZTNA > Resources & access.

Documente previamente:

nombre del recurso y Application Owner,
gateway,
aplicación web, sitio web o aplicación local,
FQDN interno o IP interna,
FQDN externo,
protocolo y puerto,
acceso con o sin agente,
política,
grupos permitidos,
FQDN de redirección,
pruebas positiva y negativa.

Para aplicaciones y sitios web utilice un FQDN. Conecte las aplicaciones locales mediante una dirección IP. En el acceso sin agente, el FQDN externo debe estar disponible públicamente. En el acceso con agente, el FQDN externo no debe estar disponible públicamente; de lo contrario, el recurso no será accesible.

Seleccione Add resource.
Elija el gateway y el tipo de acceso.
Introduzca los nombres interno y externo, el protocolo y el puerto.
Seleccione la política creada anteriormente.
Asigne únicamente el grupo piloto.
Guarde y abra el resumen del recurso para comprobarlo.

Los cambios de pertenencia a grupos pueden tardar hasta una hora en surtir efecto en el gateway. Espere ese periodo antes de volver a modificar la configuración.

Validación y resultado esperado

Comprobar la configuración

En My Products > ZTNA > Dashboard no aparecen alertas High o Medium inesperadas.
La prueba de conexión del proveedor de identidad finaliza correctamente y, en una prueba AD, muestra el grupo esperado.
El dominio y el certificado son válidos; los navegadores externos no muestran errores de certificado.
Los registros DNS públicos apuntan al gateway esperado o al alias generado por Sophos.
El gateway resuelve el destino interno y alcanza su puerto.
El tipo de política, el tipo de recurso y el estado del agente coinciden.
El recurso muestra exactamente la política y el grupo piloto previstos.

Probar el acceso

Abra la aplicación como usuario piloto autorizado mediante su FQDN externo, no por la dirección IP.
Confirme el inicio de sesión con el proveedor de identidad configurado.
Pruebe la función real de la aplicación, no solo la página inicial: deben funcionar el inicio de sesión, la navegación y una operación de lectura inocua.
Pruebe con un usuario ajeno al grupo autorizado. El acceso debe rechazarse de forma trazable.
En una política con agente, cambie el estado del dispositivo relevante solo durante una ventana de prueba controlada. La condición definida debe aplicarse.
Compruebe los registros de ZTNA, gateway, proveedor de identidad, DNS y firewall para la misma marca de tiempo.
Documente usuario, dispositivo, FQDN, hora, resultado esperado y resultado real.

Los usuarios pueden abrir las aplicaciones web directamente o mediante el portal de usuario ZTNA. La dirección del portal es el FQDN configurado en el gateway. Con el tipo de plataforma Sophos Firewall, un administrador debe configurar primero un recurso para acceder al portal. El portal muestra las aplicaciones sin agente permitidas de todos los gateways; las aplicaciones con agente no aparecen. Tras siete días sin acceder a recursos se requiere un nuevo inicio de sesión. Cinco autenticaciones fallidas consecutivas bloquean los demás recursos durante 60 minutos.

Resolución de problemas por síntoma

Falla el inicio de sesión

Pruebe la conexión en My Products > ZTNA > Identity providers.
Compruebe Client ID, Tenant ID, caducidad del secreto y Redirect URI.
Verifique que el usuario y el grupo estén sincronizados y habilitados para seguridad.
En AD, compruebe Bind DN, Base DN, puerto, certificado TLS y que el campo de correo del usuario de prueba sea válido.
Tras cinco intentos fallidos, espere el bloqueo de 60 minutos en vez de generar más pruebas.

Un proveedor no puede activarse mientras la configuración esté incompleta o contenga datos no válidos. Ante el mensaje Verification failed due to invalid Client ID, compruebe el ID de la aplicación y si el inicio de sesión de usuarios está habilitado para la aplicación en Entra ID.

El inicio de sesión funciona, pero la aplicación no

Abra exactamente el FQDN externo del recurso.
Compruebe las redirecciones y cree cada FQDN adicional como recurso.
Pruebe la resolución interna y el puerto de destino desde la red del gateway.
Compare el tipo de recurso, el tipo de política y la instalación del agente.
Compruebe que el FQDN externo del recurso sea resoluble públicamente en el acceso sin agente y que precisamente no lo sea en el acceso con agente.
Compruebe si una política nueva sustituyó la asignación anterior del recurso.
Si funciona el acceso directo pero no el portal en Sophos Firewall, compruebe que exista el recurso de portal necesario y esté asignado al grupo correcto.

Un usuario no obtiene acceso inesperadamente

Compruebe la pertenencia efectiva al grupo, no solo la esperada.
Espere hasta una hora tras cambiar un grupo.
Vuelva a asignar los grupos Entra renombrados.
En AD, asegúrese de que el usuario no pertenezca únicamente a un grupo primario.
Compruebe si filtros o Base DN retiraron al usuario del alcance de sincronización.

DNS o certificado defectuoso

Compare A y CNAME carácter por carácter con Sophos Fusion. Revise TXT solo para Certbot manual o para verificar el dominio del inicio federado de Fusion.
En el certificado administrado, compruebe el CNAME de _acme-challenge.<domain>, consérvelo para renovaciones y regenere el certificado tras cambiar dominios.
Compruebe si el proveedor DNS añadió su propio dominio al CNAME.
Revise la cadena del certificado, el alcance wildcard, la caducidad y el tipo de clave compatible.
Pruebe por separado pública e internamente. Una prueba LAN correcta no demuestra la resolución pública.

El agente está instalado, pero el túnel o el estado del dispositivo no se aplica

Compruebe el sistema operativo, la versión de Endpoint y el componente ZTNA instalado.
Asegúrese de que la política y el recurso sean ambos con agente.
Tenga en cuenta el tiempo mínimo configurado para el estado del dispositivo.
Con Do not monitor local traffic, el FQDN y la IP del DNS interno deben coincidir exactamente con la configuración de Central.
La extensión de Protected Browser no proporciona el estado de integridad del endpoint; pruebe esas condiciones en Protected Browser completo o con el agente ZTNA.

Escalación a Sophos Support

En Global Settings > Products and Services > ZTNA, establezca la caducidad del acceso de soporte. Genere después un token de soporte temporal en la configuración del gateway. No transmita credenciales permanentes y revoque el token o deje que caduque al finalizar.

Vía de retorno segura y offboarding

Revertir un piloto fallido

Detenga la ampliación a más usuarios.
Retire el grupo piloto del recurso o establezca la política en Policy bypassed. Atención: así los usuarios no podrán acceder a los recursos administrados.
Restaure la vía de acceso documentada anteriormente, por ejemplo VPN o acceso LAN directo. No la retire hasta que ZTNA haya sido aceptado.
Quite el componente ZTNA únicamente de los dispositivos piloto si ningún otro recurso con agente lo necesita.
Retire los CNAME públicos de recursos solo después de confirmar el retorno a la ruta anterior. No elimine precipitadamente el DNS del gateway ni el certificado mientras otros recursos los utilicen.
Compruebe con pruebas positiva y negativa que la ruta anterior funciona y que no queda ninguna exposición pública involuntaria.

No desactive Use access control conditions como supuesto bypass de emergencia: eliminaría la comprobación del estado del dispositivo. Si no puede restablecer un acceso seguro, deténgase y escale el problema en vez de ampliar la política.

Dar de baja a un usuario o invitado

Retire la pertenencia al grupo en el directorio autoritativo o desactive la cuenta en el proveedor de identidad.
Prevea hasta una hora para que el cambio llegue al gateway. Después, la desactivación en el proveedor de identidad fuerza el cierre de sesión y bloquea los recursos.
Compruebe que ningún segundo grupo sincronizado otorgue el mismo acceso.
Revise los registros ZTNA con una prueba negativa tras retirar el acceso.
Elimine del sistema de origen cuentas de invitado huérfanas, invitaciones y grupos temporales.

En principio, los usuarios permanecen conectados hasta que llevan siete días inactivos. Actualmente solo un administrador puede provocar un cierre de sesión inmediato. Téngalo especialmente en cuenta en dispositivos compartidos.

Retirar un recurso o gateway

Inventaríe todos los grupos, políticas, recursos, nombres DNS y dependencias de certificados asignados.
Retire primero el acceso de los usuarios y observe los registros.
Elimine después el recurso.
Retire los registros DNS públicos solo cuando ninguna otra vía de acceso los necesite.
Elimine un gateway únicamente cuando todos los recursos se hayan migrado y se haya validado la ruta nueva.
Revoque secretos y certificados innecesarios y elimine reglas antiguas de firewall o NAT.

Operación, revisión y ciclo de vida

Realice una revisión al menos trimestralmente y después de cada cambio importante:

usuarios activos y consumo de licencia en los últimos 30 días,
pertenencias a grupos y de invitados,
asignación de recurso a política y Application Owner,
caducidad de certificados y rotación de secretos,
versiones de gateway, agente, SFOS e hipervisor,
PoP, failover y mensajes de estado actuales,
recursos sin agente no accesibles y tendencias de alertas,
excepciones de firewall salientes, NAT y registros DNS antiguos,
prueba positiva y negativa para cada aplicación crítica,
vía documentada de emergencia y retorno.

El panel ZTNA muestra el número de alertas y las cinco aplicaciones con mayor transferencia de datos en las últimas 24 horas. Utilice los informes Gateway bandwidth y Resource bandwidth para seguir los usuarios autenticados y el volumen de datos.

Una licencia ZTNA activa incluye versiones de funciones y mantenimiento, soporte 24x7 y las funciones asociadas de Sophos Fusion. Sophos prevé versiones de funciones aproximadamente cada seis a doce meses y versiones de mantenimiento cada uno a tres meses. Se mantienen la versión de funciones actual y otra seleccionada; para cada versión mantenida deberían admitirse las dos últimas versiones de mantenimiento. El periodo de soporte previsto para una versión de funciones es de unos 24 meses, normalmente con 90 días de aviso público antes del fin de soporte.

Trate estos datos como planificación de versiones, no como garantía de una fecha concreta. Antes de actualizar, compruebe las notas de versión actuales de ZTNA, las limitaciones conocidas, la compatibilidad del agente y el estado de los PoP utilizados. Las afirmaciones históricas de transición, entitlement, migración o EOL sin un anuncio actual del producto no deben formar parte del plan operativo.