Por qué los hosts bastión aumentan el riesgo

Para administrar servidores dentro de una red privada, los equipos usaban tradicionalmente un host bastión (también llamado jump box): una instancia reforzada y expuesta a Internet a la que se conecta mediante SSH primero, para después saltar a las máquinas internas. Aunque es un patrón habitual, amplía la superficie de ataque de varias formas que el examen SCS-C02 espera que reconozca y elimine.

Un host bastión se encuentra en una subred pública con un puerto (normalmente el 22 para SSH o el 3389 para RDP) abierto a Internet o a un rango de IP corporativas. Los administradores se conectan a él y después acceden a las instancias privadas. Es la única puerta protegida al entorno, lo que lo convierte a la vez en un componente crítico y en un objetivo prioritario.

El mayor riesgo es el puerto entrante abierto. Los atacantes escanean y someten constantemente a ataques de fuerza bruta cualquier puerto SSH o RDP accesible desde Internet. Incluso con autenticación basada en claves, un puerto expuesto invita a los ataques, y una sola configuración incorrecta o vulnerabilidad sin parchear en el bastión puede proporcionar a los atacantes un punto de apoyo en toda la red.

El acceso al bastión suele depender de pares de claves SSH de larga duración distribuidos entre los administradores. Estas claves pueden copiarse, perderse o quedar en los portátiles de antiguos empleados. Rotarlas en toda una flota resulta complicado y rara vez existe un registro claro de qué clave abrió cada sesión, lo que debilita la trazabilidad.

Es difícil hacer un seguimiento de quién hizo qué a través de un bastión. SSH nativo ofrece pocos registros centralizados de los comandos ejecutados en los hosts posteriores. Investigar un incidente implica unir los registros de varios hosts, y un bastión comprometido podría permitir que un atacante borrara sus propios rastros, precisamente la falta de visibilidad que los auditores señalan.

El propio bastión es una instancia que debe actualizar y reforzar continuamente. Si se retrasa con las actualizaciones, se convierte en el eslabón más débil. Mantener un jump box con alta disponibilidad y siempre seguro supone una carga operativa constante que añade costes y riesgos sin aportar valor empresarial.

Como todo el tráfico administrativo pasa por el bastión, este es tanto un único punto de fallo como un objetivo de gran valor. Si deja de funcionar, los administradores pierden el acceso; si es vulnerado, el atacante obtiene una plataforma de lanzamiento. Concentrar el riesgo en un único host expuesto es una arquitectura que el examen quiere que evite.

Systems Manager (SSM) de AWS, mediante SSM Session Manager, elimina por completo la necesidad de bastiones. Proporciona acceso de shell a las instancias a través del servicio SSM con ningún puerto entrante abierto, ninguna IP pública y ninguna clave SSH. IAM controla el acceso y cada sesión queda registrada, lo que resuelve de una vez todas las debilidades del modelo de bastión.

SSM funciona porque la instancia ejecuta un SSM Agent que establece una conexión saliente con el servicio SSM; no se abre ninguna conexión entrante. Los grupos de seguridad pueden denegar todo el tráfico entrante y la administración seguirá funcionando. Esta inversión del flujo, saliente en lugar de entrante, es la idea clave que vuelve obsoletos los bastiones.

En el examen, cualquier escenario que describa puertos SSH/RDP abiertos, pares de claves distribuidos o un jump box casi siempre tiene una respuesta mejor: sustituir el bastión por Session Manager. Esto reduce la superficie de ataque, centraliza el control de acceso en IAM y genera un registro de auditoría completo: el diseño seguro y de mínimo privilegio que recomienda AWS.

Un host bastión expone un puerto entrante, depende de claves SSH permanentes, ofrece una auditoría deficiente y debe recibir parches constantemente, por lo que se convierte en un objetivo concentrado y atractivo. El reemplazo recomendado es SSM Session Manager, que concede acceso de shell controlado por IAM y completamente registrado, sin puertos abiertos, IP pública ni claves.

Compruebe por qué los bastiones son arriesgados.

Un host bastión abre un puerto SSH/RDP entrante, depende de claves SSH de larga duración, ofrece una auditoría deficiente y exige aplicar parches constantemente, concentrando el riesgo en un único objetivo expuesto. SSM Session Manager lo sustituye por acceso controlado mediante IAM y completamente registrado a través de una conexión saliente del agente, sin necesidad de puertos abiertos, IP pública ni claves.