Sophos Protected Browser: solucionar problemas de acceso e inicio de sesión

Este runbook permite acotar los problemas de acceso con Protected Browser y recursos RDP/SSH sin agente de ZTNA. En Sophos Central, se abre Meine Produkte > Protected Browser y se empieza por el síntoma visible. Solo se corrige la causa confirmada durante la comprobación. Los cambios generales en DNS, el directorio de usuarios o ZTNA dificultan el diagnóstico.

Procedimiento rápido: Si ya falla la adición o edición de un recurso, se comprueban las direcciones de correo de todos los miembros del grupo de usuarios utilizado. Si un recurso existente no está accesible sin mostrar un mensaje de error concreto, se prueba primero el portal de usuario de ZTNA y después la resolución DNS del FQDN del gateway ZTNA. Si aparece «Netzwerk nicht erreichbar» o «Verbindung konnte nicht hergestellt werden», se compara directamente el proveedor de identidad configurado en ZTNA con el método de inicio de sesión de la sesión de Protected Browser. Si falla el inicio de sesión en Protected Browser, se comprueban el acceso a Self Service Portal y que la dirección de correo sea única entre tenants. El mensaje «Hostschlüsselüberprüfung fehlgeschlagen» se trata por separado.

Requisitos previos y límites de trabajo seguros

Estas comprobaciones requieren un entorno de Protected Browser y ZTNA ya configurado, además de un usuario afectado claramente delimitado. La ausencia de menús o permisos no permite deducir un problema concreto de licencia o rol. En ese caso, la comprobación se deriva al administrador responsable de Sophos Central.

Para comprobar el usuario en Sophos Central se necesita acceso a Meine Umgebung > Benutzer und Gruppen > Benutzer. Para la prueba de conectividad deben conocerse el FQDN del gateway ZTNA realmente configurado y el tipo de gateway: Sophos Cloud Gateway o gateway local. En el comando, el marcador se sustituye por el FQDN del gateway ZTNA, no por el nombre de un recurso RDP/SSH de destino.

Durante el diagnóstico solo se cambia un valor cada vez y después se repite la prueba con el mismo usuario y dispositivo. Si algún requisito previo no está claro o no se tiene acceso a la gestión de usuarios, se detiene el diagnóstico y se deriva el caso al administrador responsable de Sophos Central, del servicio de directorio o de ZTNA.

Solución de problemas por síntoma

Falla la adición o edición de un recurso RDP/SSH sin agente

Causa probable: Al menos un miembro del grupo de usuarios utilizado no tiene una dirección de correo válida. Esto puede afectar tanto a un recurso ZTNA como a un recurso RDP/SSH de un grupo de aplicaciones de Protected Browser.

Comprobación:

1. Se abre Meine Umgebung > Benutzer und Gruppen > Benutzer.
2. En la columna E-Mail, se comprueban todos los usuarios del grupo que se va a asignar al recurso o al grupo de aplicaciones.

Resultado esperado: Todos los usuarios del grupo afectado tienen una dirección de correo válida. Una entrada vacía confirma el estado de error.

Medida segura: La dirección que falta se añade en el servicio de directorio principal. Solo se añade directamente en Sophos Central para usuarios creados manualmente allí. No se cambian por sospecha las direcciones existentes.

Volver a validar: Se repite la adición o edición del mismo recurso sin cambiar el grupo. Si sigue fallando aunque la columna E-Mail esté completa, esta causa no queda confirmada. En vez de modificar más datos de identidad, se registran el tipo de recurso, el grupo, la hora y el mensaje visible, y se escala el caso.

No se puede acceder al recurso RDP/SSH sin agente mediante Protected Browser

Causa probable: El dispositivo no puede resolver correctamente el FQDN del gateway ZTNA. Sin embargo, el primer punto para aislar el problema es el portal de usuario de ZTNA: si tampoco se puede acceder a él mediante Protected Browser, el problema se produce antes del recurso RDP/SSH concreto.

Comprobación:

1. En el mismo dispositivo y con el mismo usuario, se intenta abrir el portal de usuario de ZTNA mediante Protected Browser.
2. Si no se puede acceder al portal, se realiza una consulta DNS en el dispositivo afectado:

nslookup <ZTNA-Gateway-FQDN>

<ZTNA-Gateway-FQDN> se sustituye por el nombre de gateway realmente configurado. nslookup es una prueba de solo lectura y no cambia ninguna configuración.

Resultado esperado: Con un Sophos Cloud Gateway, el nombre del gateway se resuelve a la dirección del proxy del gateway. Con un gateway local, se resuelve a la dirección del gateway ZTNA configurada en el servidor DNS propio. La respuesta se compara con el destino realmente configurado para el modelo de gateway correspondiente. Si falla la resolución, debe comprobarse la configuración DNS. Una respuesta diferente solo confirma un error si no coincide con el destino configurado. Si se desconoce el destino previsto, no se cambia DNS y la comprobación se deriva al responsable de DNS/ZTNA.

Medida segura: La configuración DNS se corrige siguiendo el procedimiento de DNS/ZTNA previsto. La zona y el destino correctos dependen del modelo de gateway; por tanto, aquí no se realizan cambios generales de DNS.

Volver a validar: Cuando el responsable de DNS/ZTNA confirme que ha realizado una corrección mediante el procedimiento previsto, se repite la misma consulta nslookup. A continuación se abre el portal de usuario de ZTNA y solo entonces se prueba el recurso RDP/SSH original. Si la respuesta DNS es la esperada y el portal está accesible, pero el recurso sigue sin estarlo, se documentan estos dos controles positivos y se escala la comprobación de ZTNA específica del recurso.

«Netzwerk nicht erreichbar» o «Verbindung konnte nicht hergestellt werden»

Causa probable: ZTNA utiliza un proveedor de identidad como Okta o Entra ID, pero el usuario ha iniciado sesión en Protected Browser con su Sophos ID o como usuario local. Al acceder a una aplicación SSH o RDP detrás del gateway ZTNA pueden aparecer los mensajes indicados.

Comprobación: Se identifica qué proveedor de identidad está configurado en ZTNA y se compara con el método de inicio de sesión de la sesión actual de Protected Browser.

Resultado esperado: La causa se confirma si ZTNA utiliza un proveedor de identidad, pero la sesión de Protected Browser no se ha autenticado mediante ese proveedor.

Medida segura: Se cierra la sesión afectada y se inicia sesión para el usuario en Protected Browser mediante el proveedor de identidad configurado en ZTNA. No se cambia el proveedor de identidad de ZTNA para eludir un único error de inicio de sesión.

Volver a validar: En la nueva sesión autenticada se abre la misma aplicación SSH o RDP. Si el mensaje persiste aunque coincidan los métodos de inicio de sesión, se registran el proveedor de identidad, el usuario, el recurso y la hora, y se deriva el caso al responsable de ZTNA.

El usuario no puede iniciar sesión en Protected Browser

Aquí se comprueban dos causas independientes. No se corrigen al mismo tiempo, para que quede claro cuál era la causa real.

Falta acceso a Self Service Portal

Comprobación: Se abre Meine Umgebung > Benutzer und Gruppen > Benutzer y se comprueba la columna Rolle del usuario afectado. Como alternativa, se selecciona el nombre de usuario y se comprueba el texto bajo la foto del perfil.

Resultado esperado: Si existe acceso a Sophos Central Self Service Portal, aparece SelfService en la columna Rolle o bajo la foto del perfil.

Medida segura: Si falta SelfService, la concesión del acceso a Self Service Portal se deriva al administrador responsable de Sophos Central.

Volver a validar: Primero se confirma que aparece SelfService y después se repite el inicio de sesión exactamente con ese usuario.

La dirección de correo está vinculada a varias cuentas de Sophos Central

Comprobación: Se determina si la dirección de correo del usuario afectado está asignada a varias cuentas de Sophos Central.

Resultado esperado: La dirección no debe estar vinculada a varias cuentas de Sophos Central.

Medida segura: Se solicita al administrador responsable del tenant o de identidades que corrija la asignación. Sin un tenant de destino confirmado, no se elimina ningún usuario ni se cambia una dirección de producción.

Volver a validar: Una vez confirmada la asignación única, se repite el inicio de sesión en Protected Browser. Si sigue fallando, se documentan SelfService, la asignación de correo, la hora y el mensaje visible para la escalada.

SSH muestra «Hostschlüsselüberprüfung fehlgeschlagen»

Causa probable: La clave almacenada en el cliente SSH ya no coincide con la clave del host. Esto puede suceder tras un cambio legítimo, como una reinstalación, pero el mismo mensaje también puede indicar un cambio inesperado.

Comprobación: Se obtiene la huella digital esperada de la clave de host mediante un canal independiente y de confianza a través del responsable del sistema, y se compara con la huella del host de destino correcto. No se confía ni en la conexión SSH fallida ni en la nueva clave que se ofrece en ella. Si la huella esperada no se ha confirmado de forma independiente, no coincide o el cambio no puede explicarse, se detiene el procedimiento en este punto y se escala como incidente de seguridad.

Resultado esperado: El host de destino, el cambio legítimo de clave y la huella esperada se han confirmado de forma independiente e inequívoca.

Medida segura: Antes de borrar nada, se determina qué entradas elimina la función ofrecida por el cliente SSH. Sophos cita Bekannte Hosts löschen como ejemplo, pero no confirma que esta función elimine solo el host afectado. Si se desconoce el alcance del borrado o no puede confirmarse de forma independiente la huella esperada, no se realiza ningún reset y se escala. La clave almacenada solo se elimina cuando se conoce el alcance y se ha confirmado la huella. En la siguiente conexión, únicamente se acepta la clave cuya huella coincida con la confirmación independiente.

Volver a validar: Se vuelve a establecer la conexión. La comprobación de la clave de host debe completarse correctamente con la clave recién aceptada. Si el mensaje reaparece o la clave vuelve a cambiar de forma inesperada, no se borran entradas repetidamente; se escala con el nombre de host, la hora y el cliente SSH.

Reversión, escalada y límites operativos

No existe un rollback universal para estos errores. Para volver de forma segura, no se realizan cambios generales y se documenta el valor inicial de cualquier asignación de usuario modificada de forma específica. Si la medida no resuelve el problema, se detiene el procedimiento en el punto de escalada correspondiente. Borrar claves de host SSH conocidas no es un reset general y solo resulta aceptable con la huella confirmada de forma independiente y con un alcance de borrado conocido.

Para una escalada interna o a soporte, se registran al menos el síntoma, el usuario, el dispositivo, el tipo de recurso, el modelo de gateway, el FQDN del gateway ZTNA, la hora y el resultado de la comprobación directamente relacionada. Las credenciales, claves privadas y tokens no deben incluirse en el ticket.

Solo se repite la comprobación asociada a la medida realmente realizada o a la derivación confirmada: volver a añadir o editar el recurso tras corregir el correo; iniciar sesión tras confirmar el acceso a Self Service Portal o la asignación única de cuenta; abrir el recurso tras iniciar sesión mediante el proveedor de identidad configurado; o establecer la conexión SSH después del reset controlado de la clave de host. Tras derivar el caso al responsable de DNS/ZTNA, solo se vuelven a probar nslookup, el portal de usuario y el recurso original cuando dicho responsable confirme una corrección según su procedimiento.

Delimitación respecto a otras guías

Este runbook trata exclusivamente los síntomas de Protected Browser descritos aquí. La configuración de Protected Browser o de la extensión, así como la configuración general de DNS y ZTNA, corresponden a las guías de configuración respectivas. Cuando sea necesaria una configuración de este tipo, el caso se deriva al administrador responsable.