Ir al contenido
Avanet

Acceso RDP y SSH sin agente con Sophos Protected Browser

Sophos Workspace Protection

Sophos Protected Browser permite acceder a hosts RDP y SSH internos sin un agente ZTNA en el dispositivo del usuario. Sophos enumera estos dos casos de uso en Agentenlose RDP-Anwendungen y Agentenlose SSH-Anwendungen. El acceso sigue limitado a Protected Browser: una conexión creada como recurso RDP o SSH sin agente no se puede abrir con un cliente RDP o SSH convencional.

El procedimiento seguro es el mismo para ambos protocolos: primero se preparan la identidad, la puerta de enlace y la conectividad; después se crea una política ZTNA sin agente y un recurso para cada host. En Protected Browser, el recurso se añade a un grupo de aplicaciones y se autoriza mediante una política de Internet. Solo entonces se realizan las pruebas con un grupo reducido de usuarios.

Requisitos, licencia y roles

Se deben cumplir los siguientes puntos antes de la configuración:

  • Protected Browser está instalado en un dispositivo Windows o macOS compatible. El ejemplo utiliza un dispositivo Windows con el estado de integridad en verde.
  • Los usuarios y grupos están sincronizados, hay un proveedor de identidad configurado y la puerta de enlace ZTNA está operativa.
  • La puerta de enlace puede llegar al host interno RDP o SSH. Esta conexión se verifica antes de crear el recurso.
  • Existe el grupo de usuarios más pequeño posible para el recurso. Un objeto compartido para todos los empleados no es adecuado para el acceso administrativo.
  • La persona que realiza el procedimiento puede gestionar políticas y recursos en Meine Produkte > ZTNA, así como objetos de política y políticas de Internet en Meine Produkte > Protected Browser.

La información del producto aprobada para este procedimiento no especifica un nombre de rol ni un SKU de licencia independiente. No se debe deducir la autorización únicamente porque un menú sea visible ni conceder permisos generales de superadministrador. Antes del cambio, compruebe en su tenant que ZTNA y Protected Browser están disponibles y que la cuenta administradora puede crear los objetos indicados. Si falta una página o un botón, solicite al responsable de licencias o roles del tenant que lo revise antes de continuar.

Local Gateway y Sophos Cloud Gateway son posibles modos de implementación de ZTNA. Su aprovisionamiento, sincronización de identidades y usuarios, dominios, certificados y DNS son parte de la base común de ZTNA. El orden correcto se explica en Configuración de Sophos ZTNA. Esta guía no repite intencionalmente estos procedimientos comunes.

Comprobar previamente el DNS y los certificados

El dominio de la puerta de enlace, el certificado y la resolución DNS pública e interna requerida ya deben estar funcionando. El propietario de ZTNA establece esta base común de acuerdo con las instrucciones de ZTNA vinculadas; aquí no se duplica ni se modifica.

Los recursos RDP y SSH descritos aquí utilizan un formulario específico: introduzca el valor en Interner FQDN/IP-Adresse der Ressource; no es posible añadir Externen FQDN. Por lo tanto, los ejemplos generales de DNS para aplicaciones web ZTNA no se deben copiar en este campo. El propietario de ZTNA prepara los dominios y los certificados antes de crear el recurso RDP o SSH.

Preparar valores de ejemplo

Los siguientes nombres hacen reconocibles los objetos relacionados. No son una especificación de producto y deben adaptarse a su propia convención de nomenclatura:

  • Política ZTNA: Agentenloser Zugriff
  • Recurso RDP: Agentenloses RDP
  • Recurso SSH: Agentenloses SSH
  • Estado del dispositivo: Grünes Windows
  • Grupo de aplicación: Agentenlose RDP-Gruppe o Agentenlose SSH-Gruppe
  • Política de Internet: Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität o la variante SSH
  • Host interno: por ejemplo rdp01.intern.example o ssh01.intern.example

Un FQDN es más fácil de gestionar que una dirección IP cambiante, pero debe resolverse correctamente desde la puerta de enlace. Si prueba ambos protocolos, cree recursos y grupos de aplicaciones separados para poder rastrear las asignaciones, la validación y la posterior retirada.

Agregar política ZTNA sin agente

Se puede reutilizar una política sin agentes existente y adecuadamente delineada. Sin embargo, tener una política piloto propia reduce el riesgo de impactar involuntariamente los recursos productivos.

  1. Abra Meine Produkte > ZTNA > Richtlinien.
  2. Haga clic en Richtlinie hinzufügen.
  3. En Richtlinie hinzufügen, seleccione el tipo Agentenlos. En otras vistas de ZTNA, este tipo aparece como Ohne Agent. El aviso Agent anfordern corresponde a la ruta basada en agente; esta política no requiere esperar a un agente.
  4. En Neue Richtlinie, introduzca un nombre, por ejemplo Agentenloser Zugriff.
  5. Abra Richtlinie durchgesetzt y active Richtlinie wird durchgesetzt.
  6. Haga clic en Speichern.

El tipo de política ZTNA Agent y sus túneles no forman parte de este flujo. Además, el Zeitüberschreitung wegen Inaktivität des Agent-Tunnels global se aplica al túnel del agente y no es un temporizador de sesión RDP o SSH para el Protected Browser. El propietario de ZTNA aún debe conocer el Mindestzeit, bevor die Geräte-Integrität eine Regel auslöst global si se utiliza la integridad del dispositivo en el entorno general.

Agregar recurso RDP o SSH

Abra Meine Produkte > ZTNA > Ressourcen und Zugriff y haga clic en Ressource hinzufügen. Complete el formulario con los valores del protocolo correspondiente.

Recurso RDP

  1. Por ejemplo, ingrese Agentenloses RDP como Ressourcenname. Una descripción es opcional.
  2. Elija la puerta de enlace que pueda alcanzar rdp01.intern.example.
  3. En Zugriffsmethode seleccione el valor Agentenlos.
  4. Elija la política Agentenloser Zugriff.
  5. En Ressourcentyp, seleccione RDP. El puerto 3389 y el tipo de puerto de acceso TCP se configuran automáticamente y no se pueden cambiar en este formulario.
  6. En Interner FQDN/IP-Adresse der Ressource, introduzca el host interno. No se puede añadir un FQDN externo para este tipo de recurso.
  7. En Benutzergruppen zuweisen, mueva únicamente el grupo piloto necesario de Verfügbar a Zugewiesen.
  8. Haga clic en Speichern.

Recurso SSH

Para SSH utilice el mismo flujo con estos valores específicos del protocolo:

  1. Ressourcenname: por ejemplo Agentenloses SSH.
  2. Zugriffsmethode: Agentenlos.
  3. Richtlinie: Agentenloser Zugriff.
  4. Ressourcentyp: SSH. El puerto 22 y el tipo de puerto de acceso TCP se configuran automáticamente y no se pueden cambiar.
  5. Interner FQDN/IP-Adresse der Ressource: por ejemplo ssh01.intern.example; un FQDN externo no está disponible.
  6. Benutzergruppen zuweisen: mueva solo el grupo piloto previsto a Zugewiesen y, a continuación, haga clic en Speichern.

Los recursos basados en agentes y las aplicaciones web ofrecen otras funciones. Por ejemplo, el agente puede tener en cuenta el estado del dispositivo en la política de acceso de ZTNA y controlar aplicaciones locales. En el procedimiento descrito aquí, el recurso sigue siendo Ohne Agent. Si se necesita una comprobación adicional del dispositivo, configúrela en la política de Internet de Protected Browser.

Limitar el acceso al navegador protegido

Crear estado de dispositivo opcional

Agregar el estado de un dispositivo es opcional. Sin este objeto, el grupo piloto debe ser especialmente reducido. Para el ejemplo documentado con dispositivos Windows administrados:

  1. Abra Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Haga clic en Objekt hinzufügen > Gerätestatus.
  3. Introduzca Grünes Windows como nombre.
  4. En OS-Plattform seleccione el valor Windows.
  5. En Endpoint Protection, seleccione Prüfen, ob Gerät durch Sophos Endpoint geschützt ist y, a continuación, el estado de integridad Grün.
  6. Haga clic en Speichern.

Las comprobaciones adicionales aumentan la seguridad, pero también pueden excluir más dispositivos. Por lo tanto, cada condición adicional se prueba primero con el grupo piloto.

Crear grupo de aplicaciones

  1. Permanezca en Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Haga clic en Objekt hinzufügen > Anwendungsgruppe.
  3. Introduzca un nombre exclusivo, por ejemplo Agentenlose RDP-Gruppe.
  4. Expanda ZTNA-Ressourcen.
  5. En Verfügbar, seleccione el recurso creado anteriormente y muévalo a Zugewiesen.
  6. Haga clic en Speichern.

Para SSH, cree Agentenlose SSH-Gruppe y asigne Agentenloses SSH. Los grupos separados evitan que un cambio posterior en el acceso SSH pase desapercibido y cambie el acceso RDP.

Agregar política de Internet

  1. Abra Meine Produkte > Protected Browser > Internetrichtlinie y seleccione la pestaña Richtlinien.
  2. Haga clic en Richtlinie hinzufügen.
  3. Introduzca un nombre exclusivo, por ejemplo Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
  4. Asegúrese de que esté seleccionado Zulassen.
  5. Si se utiliza, seleccione el estado del dispositivo Grünes Windows.
  6. Seleccione el grupo de aplicaciones Agentenlose RDP-Gruppe.
  7. Haga clic en Speichern.

Para SSH, cree la política correspondiente con el grupo de aplicaciones SSH. Así queda claro qué protocolo y qué condición del dispositivo abarca cada autorización.

Verificar la conexión y el resultado esperado

Primero, realice la prueba con exactamente un usuario autorizado y un dispositivo que cumpla con la condición del dispositivo seleccionado.

Prueba RDP

  1. Inicie Sophos Protected Browser e identifíquese.
  2. En la parte superior de la barra de herramientas, haga clic en el ícono Conexión a Escritorio remoto y luego haga clic en + Neuer Host.
  3. Asigne un nombre para mostrar e introduzca en Host el mismo FQDN interno o la misma dirección IP del recurso ZTNA. El puerto 3389 se configura automáticamente.
  4. Ingrese el nombre de usuario y la contraseña del sistema de destino y haga clic en Verbinden.

La prueba es exitosa si la sesión de escritorio remoto se abre en Protected Browser. Un cliente RDP normal no es una verificación cruzada válida porque solo se puede acceder a los recursos RDP sin agente a través de Protected Browser.

Prueba SSH

  1. Inicie Protected Browser, identifíquese y haga clic en SSH-Symbol en la barra de herramientas.
  2. Seleccione + Neuer Host, asigne un nombre para mostrar e ingrese el valor del recurso SSH en Host. El puerto 22 se configura automáticamente.
  3. Ingrese el nombre de usuario y la contraseña del sistema de destino y haga clic en Verbinden.

La prueba es satisfactoria si la sesión SSH se abre en el navegador. A continuación, realice una prueba negativa con un usuario que no pertenezca al grupo asignado y confirme que se deniega el acceso.

Controlar la transferencia de archivos

Una vez establecida la conexión se utilizan diferentes controles según el protocolo:

  • RDP: Expanda el menú superior y seleccione Dateiübertragung > Hochladen para la carga. Para descargar, utilice el símbolo de descarga de la entrada deseada.
  • SSH: Abra el elemento de control a continuación y seleccione Dateiübertragung > In Ordner hochladen para la carga. Utilice el símbolo de descarga para descargar.

Durante la prueba piloto, utilice únicamente un archivo inofensivo que no contenga datos confidenciales. Los archivos se analizan y solo se cargan en el host si están limpios. La carga se completa cuando aparece Datei erfolgreich gescannt y, después, el mensaje de confirmación. Compruebe la descarga por separado: se completa correctamente si el archivo seleccionado llega íntegro al dispositivo de prueba y se puede abrir.

Solucionar problemas por síntoma

Falta la acción RDP/SSH o un host creado manualmente no se conecta

Compruebe lo siguiente en este orden:

  1. ¿Se seleccionó + Neuer Host usando el símbolo RDP o SSH y el FQDN interno exacto o la dirección IP del recurso asociado ingresado en Host?
  2. ¿El usuario de prueba es miembro del grupo seleccionado en Benutzergruppen zuweisen?
  3. ¿Está el recurso ZTNA correcto en el grupo de aplicaciones bajo Zugewiesen?
  4. ¿La política de Internet que permite el acceso utiliza exactamente este grupo de aplicaciones?
  5. ¿El dispositivo de prueba cumple con el estado del dispositivo opcional, específicamente Windows, Sophos Endpoint Protection y estado de salud Grün?

Los cambios en un grupo de usuarios de ZTNA pueden tardar hasta una hora en ser visibles en la puerta de enlace. Por lo tanto, no debería crear objetos nuevos inmediatamente mientras el cambio de grupo esté pendiente.

Si el host introducido manualmente es correcto, compruebe si la puerta de enlace seleccionada puede alcanzar el host de destino. RDP utiliza TCP fijo 3389, SSH fijo TCP 22; un servicio en un puerto diferente no coincide con estos tipos de recursos.

Si el error persiste, el diagnóstico pasa al propietario del ZTNA. El tiempo de vencimiento de los tokens de soporte se configura en la configuración global de ZTNA. El token Sophos-Support für Gateway-Instanz se crea para la instancia afectada en Gateway > Gateway-Einstellungen. Un token de soporte solo se libera para un caso específico y con un tiempo de vencimiento deliberadamente corto.

El acceso solo falla con el estado del dispositivo activado

No elimine sin control la condición del dispositivo de una política de producción. Primero, compare la plataforma, la protección del terminal y el estado de salud informado del dispositivo piloto con el objeto Grünes Windows. Para una comparación aislada, se puede utilizar una política piloto de Internet separada sin estado del dispositivo; el grupo de usuarios sigue siendo muy limitado.

El archivo no se carga

La carga sólo se realiza después de un escaneo exitoso. Si falta el mensaje Datei erfolgreich gescannt o el archivo no está clasificado como limpio, la carga no se considera exitosa. En lugar de omitir el análisis, utilice un archivo de prueba inofensivo y escale el análisis fallido con la hora, el usuario, el host de destino y el nombre del archivo.

Reversión segura y retirada

La información del producto aprobada no documenta un procedimiento completo para eliminar todos los objetos de Protected Browser implicados. Por tanto, no elimine la puerta de enlace, el DNS, los certificados ni las políticas compartidas como si esa acción fuera una reversión.

Para una detención de acceso inmediata y reversible, se puede abrir una política ZTNA dedicada en Meine Produkte > ZTNA > Richtlinien. En la pestaña Richtlinie durchgesetzt, se configura como Richtlinie umgangen. En este estado, los usuarios no pueden acceder a los recursos administrados por esta política.

Antes de hacerlo, compruebe que solo los recursos RDP o SSH previstos estén asignados a esta política. Después, confirme con el usuario piloto que ya no se puede establecer la conexión. Para restaurar el acceso, vuelva a establecer la misma política dedicada en Richtlinie wird durchgesetzt y repita la prueba de conexión. Si otros recursos utilizan la política, detenga el procedimiento antes del cambio y páselo al propietario de ZTNA.

Para desmantelar permanentemente, primero documente el recurso, la puerta de enlace, la política, los grupos de usuarios, el grupo de aplicaciones y la política de Internet. A continuación, el propietario respectivo elimina las asignaciones y los objetos en orden de dependencia. Sin un flujo de eliminación compartido y específico del producto, el límite seguro se alcanza antes de que se eliminen los objetos ZTNA, DNS o de certificado compartidos.

Operación y ciclo de vida

Al menos cada vez que hay un cambio en los grupos de usuarios, puertas de enlace, nombres de host internos o condiciones del dispositivo, se repite una prueba positiva y negativa. Además, el propietario deberá comprobar periódicamente:

  • si los hosts RDP y SSH son accesibles desde la perspectiva de la puerta de enlace;
  • si sólo se asignan los grupos requeridos;
  • si los recursos, los grupos de aplicaciones y las políticas de Internet todavía van de la mano;
  • si los dominios y certificados son válidos y están asignados a la puerta de enlace correcta;
  • si el tiempo mínimo global para las reglas de salud del dispositivo coincide con el comportamiento deseado;
  • si un token de soporte generado ha caducado y no existe más tiempo del necesario.

Los recursos RDP y SSH sin agente siguen siendo una vía de acceso independiente. Por tanto, los cambios en los tiempos de espera del túnel del agente o en la implementación basada en agentes no sustituyen una nueva comprobación en Protected Browser. Esta guía tampoco establece fechas de transición, retirada ni fin de vida. Cuando cambie el producto, el propietario deberá revisar la configuración visible en el tenant y repetir el proceso piloto.