SSH es el protocolo para el shell remoto seguro y la transferencia de archivos. Funciona en una amplia gama de equipos, desde servidores y equipamiento de red hasta las pasarelas y los controladores embebidos comunes en OT (una pasarela MOXA en este ejemplo). El canal ya está cifrado de extremo a extremo, de modo que el problema que SSH plantea en una red OT rara vez es la confidencialidad. Son otras dos cosas: la accesibilidad plana (cualquier elemento de la LAN puede llamar al puerto 22) y la proliferación de credenciales (dispositivos protegidos con una única clave o contraseña compartida, difícil de rotar). Access Gate aborda ambas, y ofrece dos formas distintas de hacerlo.
Cómo funciona realmente la seguridad de SSH
En cada sesión SSH intervienen tres elementos, y fallan de forma independiente:
- Clave de host (identidad del servidor). En la primera conexión, el cliente registra la clave de host del servidor. Esto es lo que detiene a un intermediario, y también lo que produce la advertencia "la clave de host ha cambiado" que los operadores están acostumbrados a ignorar con un clic. El gate, al intermediar la sesión, te da una identidad coherente que verificar en lugar de una clave por dispositivo.
- Autenticación del usuario. El usuario demuestra quién es con una clave SSH (preferida) o una contraseña (más débil, susceptible de phishing, a menudo compartida). En equipos OT suele ser una única credencial compartida incrustada en un runbook.
- Canal cifrado. Se negocia automáticamente. Esta parte ya es sólida, por eso el trabajo de seguridad de SSH se centra en los dos primeros puntos, no en el cifrado.
La conclusión: SSH no necesita ayuda para cifrar. Necesita ayuda con quién puede alcanzar el puerto y quién posee la credencial. Los dos modelos de acceso siguientes se diferencian precisamente en esa segunda pregunta.
Dos formas de intermediar SSH (elige una)
Modelo A: concesión por ruta de red
El modelo de enclave estándar de denegación por defecto. Escribes una regla allow para el protocolo ssh (puerto 22) desde un principal hacia el activo, y el operador se conecta con su propio cliente SSH y su propia clave. El gate aplica la identidad y la política y registra la sesión, pero la credencial SSH permanece entre el operador y el dispositivo.
- Añade el dispositivo como un activo y colócalo en un enclave, consulta Proteger un activo con enclaves.
- Añade una regla
allowparassh(otcp:{custom_port}si SSH no se ejecuta en el 22), limitada al usuario, grupo o activo par que deba conectarse. - El operador ejecuta
ssh user@<overlay-name-or-ip>. Nada cambia en el dispositivo.
Usa el Modelo A cuando los operadores son de confianza para gestionar sus propias claves, cuando un flujo máquina a máquina necesita SSH (un host de automatización que alcanza un controlador), o cuando quieres la ruta más ligera que aún proporciona denegación por defecto y registro. La limitación: la credencial del dispositivo sigue estando fuera, así que revocar el acceso significa revocar la concesión y, con el tiempo, rotar la clave.
Modelo B: proxy de acceso remoto
Cuando la credencial del dispositivo nunca debe salir del gate, usa el acceso remoto: el gate almacena la clave SSH o la contraseña, la inyecta en el inicio de sesión y sirve la sesión en una pestaña del navegador. El operador se autentica como sí mismo y nunca posee la credencial del dispositivo.
1. Crear el activo y su servicio SSH
Añade el dispositivo como un activo y declara su servicio SSH:22. Abre el activo, haz clic en Edit Network e introduce la información del servicio de acceso remoto (las credenciales que Access Gate usa en el inicio de sesión).
2. Crear un enclave
Crea un enclave que contenga el activo y el usuario o grupo al que desees conceder acceso.
3. Habilitar el acceso remoto en la concesión
Para conceder el acceso remoto, una sesión proxy que mantiene Access Gate, selecciona la opción Remote Access. Con esta opción, las credenciales almacenadas en Access Gate se usan en el inicio de sesión, sin exponerse al usuario final. Luego concede el acceso.
Del lado del usuario
El usuario se autentica a través de una pantalla de acceso y ve las sesiones de acceso remoto que puede activar.
Al hacer clic en el enlace se abre una sesión de navegador con acceso remoto a la máquina de destino.
Las credenciales no residen en la máquina del operador. La concesión (creds=...) se inyecta del lado del servidor, de modo que la persona ante el teclado nunca posee la clave SSH ni la contraseña del equipo MOXA. Revocar el acceso es revocar una concesión, no rotar una credencial del dispositivo. Para el modelo más amplio de sesión de administración (RDP, VNC, grabación de sesión), consulta Gestión de acceso privilegiado.
Notas de endurecimiento
- Prefiere las claves a las contraseñas, y en el dispositivo deshabilita la autenticación por contraseña una vez probado el acceso por clave. Con el Modelo B esto es irrelevante para el operador, el gate posee la credencial.
- SFTP y SCP usan la misma concesión. La transferencia de archivos es SSH, así que la misma regla que concede el shell también rige el movimiento de archivos. Delimítala deliberadamente si un operador debe obtener un shell pero no la copia masiva de archivos.
- La revocación difiere según el modelo. La revocación del Modelo A es inmediata en la capa de red, pero la clave del dispositivo permanece hasta que se rota. La revocación del Modelo B elimina en un solo paso la única ruta hacia la credencial.
Resumen
Tienes dos formas de intermediar SSH: una concesión por ruta de red (Modelo A) donde el operador posee su propia clave y el gate aplica la accesibilidad y el registro, o un proxy de acceso remoto (Modelo B) donde el gate posee la credencial y sirve una sesión por navegador para que el operador nunca toque la clave del dispositivo. Ambos se ejecutan sobre enclaves de denegación por defecto, y ninguno requiere cambiar el dispositivo.
Recurre al Modelo A cuando los operadores gestionan sus propias claves o para SSH máquina a máquina; recurre al Modelo B cuando una credencial compartida o no rotable nunca debe salir del gate.