AWS Systems Manager — Session Manager

AWS Systems Manager Session Manager (SSM) es un servicio nativo de AWS que permite acceder a instancias EC2 sin abrir puertos de red, sin gestionar claves SSH y con auditoría completa de cada sesión. Reemplaza el modelo tradicional de bastion host con un enfoque más seguro, auditable y sin costos adicionales de infraestructura.

El Problema del Bastion Host

El modelo tradicional de acceso a servidores en AWS funciona así: creas una instancia EC2 llamada bastion host (o jump box) en una subnet pública, abres el puerto 22 (SSH) en el security group y distribuyes claves SSH a los ingenieros. Para acceder a cualquier máquina en la subnet privada, el ingeniero primero se conecta al bastion y desde ahí hace un segundo SSH al servidor de destino.

Este modelo funciona, pero crea varios problemas operacionales y de seguridad:

• Superficie de ataque expuesta: El bastion host necesita ser accesible desde internet (puerto 22 abierto). Cualquier vulnerabilidad en él compromete toda la red interna.
• Gestión de claves SSH: Distribuir, rotar y revocar claves SSH para decenas o cientos de ingenieros es una pesadilla operacional.
• Falta de auditoría granular: Saber quién accedió a qué servidor y qué hizo durante la sesión requiere configuraciones adicionales de logging.
• Costo operacional: El bastion host necesita ser mantenido, actualizado y monitoreado — es un servidor más que gestionar.
• Acceso permanente: Una vez que el ingeniero tiene la clave SSH, tiene acceso continuo hasta que la clave sea revocada manualmente.

Cómo Funciona el SSM

El SSM funciona a través de un agente instalado en la instancia EC2 (el SSM Agent) que se comunica con el servicio de AWS vía HTTPS. En lugar de abrir una conexión SSH directa, el ingeniero inicia una sesión vía consola de AWS, CLI o SDK, y el SSM Agent en la instancia crea un canal seguro de comunicación.

El flujo en la práctica:

1. El ingeniero ejecuta aws ssm start-session --target i-0abc123def (o hace clic en "Connect" en la consola).
2. El servicio SSM verifica si el usuario IAM tiene permiso para iniciar sesiones en esa instancia.
3. El SSM Agent en la EC2 recibe la instrucción y abre un canal seguro.
4. El ingeniero recibe un shell interactivo en la máquina — sin SSH, sin clave, sin puerto abierto.
5. Toda la sesión puede ser grabada automáticamente en S3 o CloudWatch Logs.

Prerrequisitos

Para que el SSM funcione en una instancia EC2, tres componentes son necesarios:

1. SSM Agent Instalado y Activo

El SSM Agent es el software que corre dentro de la EC2 y se comunica con el servicio AWS Systems Manager. Es responsable de recibir comandos, iniciar sesiones y reportar el estado de la instancia.

• Amazon Linux 2/2023, Ubuntu 20.04+: El SSM Agent viene preinstalado por defecto. En la mayoría de los casos, no es necesario hacer nada.
• Otras AMIs: Puede ser necesario instalar manualmente vía yum install amazon-ssm-agent o snap install amazon-ssm-agent.
• Verifica el estado con: systemctl status amazon-ssm-agent.

2. IAM Role en la Instancia (Instance Profile)

Una instancia EC2 no puede tener un IAM role directamente asociado. Para que la instancia asuma un role, AWS utiliza un recurso intermediario llamado Instance Profile. El Instance Profile es un "contenedor" que encapsula un IAM role y permite que la EC2 asuma esa identidad. Es lo que aparece en la configuración de lanzamiento de la instancia (en el campo "IAM Instance Profile"). Cuando asocias un Instance Profile a una EC2, cualquier proceso corriendo dentro de la instancia (incluyendo el SSM Agent) puede asumir el role automáticamente y obtener credenciales temporales vía metadata service, sin necesidad de access keys hardcodeadas.

En la consola de AWS, al crear o editar una EC2, el campo aparece como "IAM role", pero por debajo, AWS está creando y asociando un Instance Profile automáticamente. Vía CLI o Terraform, la distinción es más visible: creas el role, creas el Instance Profile, asocias el role al Instance Profile y luego asocias el Instance Profile a la instancia.

La instancia EC2 necesita un IAM role (vía Instance Profile) que permita al SSM Agent comunicarse con el servicio de AWS. La policy administrada AmazonSSMManagedInstanceCore contiene todos los permisos necesarios.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ssmmessages:CreateControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:OpenDataChannel"
      ],
      "Resource": "*"
    }
  ]
}

En la práctica, basta con adjuntar la policy administrada AmazonSSMManagedInstanceCore al role de la instancia. No es necesario crear una policy personalizada, ya que la policy administrada ya incluye todos los permisos listados arriba y es mantenida por AWS.

3. Conectividad con el Servicio SSM

El SSM Agent necesita alcanzar los endpoints del servicio Systems Manager vía HTTPS (puerto 443). Existen dos formas:

Método	Cuándo usar
Internet (NAT Gateway)	La subnet privada tiene acceso a internet vía NAT. El Agent se comunica directamente con los endpoints públicos de SSM.
VPC Endpoints (PrivateLink)	La subnet no tiene acceso a internet. Creas VPC endpoints para ssm, ssmmessages y ec2messages, y el tráfico permanece dentro de la red de AWS.

Para entornos que exigen cero acceso a internet en las instancias, los VPC Endpoints son obligatorios. Necesitarás tres Interface Endpoints:

• com.amazonaws.<región>.ssm
• com.amazonaws.<región>.ssmmessages
• com.amazonaws.<región>.ec2messages

Para más detalles sobre tipos de endpoints, DNS privado, costos y configuración, consulta el artículo dedicado sobre VPC Endpoints.

Permisos del Usuario

Además de la configuración en la instancia, el usuario que inicia la sesión también necesita permisos IAM. El permiso mínimo necesario es:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:<región>:<cuenta>:instance/i-0abc123def"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ssm:TerminateSession",
        "ssm:ResumeSession"
      ],
      "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
    }
  ]
}

Esta policy permite al usuario iniciar sesiones solo en instancias específicas (definidas por ARN) y gestionar solo sus propias sesiones. Es aquí donde el principio de privilegio mínimo se aplica: en lugar de dar acceso a todas las instancias, controlas exactamente qué máquinas cada usuario puede acceder.

Ventajas del SSM sobre el Bastion Host

Aspecto	Bastion Host	SSM
Puertos de red	Puerto 22 abierto (SSH)	Ningún puerto de entrada
Claves SSH	Necesarias y difíciles de gestionar	No utiliza claves SSH
Auditoría	Requiere configuración adicional	Nativa (CloudTrail + grabación de sesión)
Costo	Instancia EC2 dedicada	Sin costo adicional (servicio incluido)
Control de acceso	Basado en claves e IPs	Basado en permisos IAM (granular)
Mantenimiento	Patches, updates, monitoreo	Cero mantenimiento de infraestructura

El SSM es la base sobre la cual herramientas de gestión de acceso Just-in-Time como Apono actúan — controlando quién recibe el permiso ssm:StartSession y por cuánto tiempo, automatizando el ciclo de concesión y revocación que antes dependía de acción manual.

Consideraciones de Seguridad: Port Forwarding

El SSM Session Manager ofrece una funcionalidad de port forwarding que permite redirigir puertos de una instancia EC2 a la máquina local del ingeniero. Aunque útil en escenarios legítimos (como acceder a una base de datos RDS o una interfaz web interna), esta funcionalidad introduce riesgos de seguridad que necesitan ser evaluados.

El Problema

En el modelo tradicional de bastion host, una práctica común de hardening es restringir la transferencia de archivos entre la máquina local y el bastion, bloqueando SCP, SFTP y túneles SSH. Esto limita la exfiltración de datos e impide que archivos no autorizados sean enviados al ambiente interno.

Con el SSM, el port forwarding puede reintroducir este riesgo. Un ingeniero con permiso de port forwarding puede:

• Redirigir puertos de bases de datos a la máquina local, accediendo a datos directamente sin pasar por capas de control.
• Crear túneles hacia servicios internos, exponiendo aplicaciones que no deberían ser accesibles fuera de la VPC.
• Facilitar la exfiltración de datos, transfiriendo información sensible a través del túnel establecido.

# Ejemplo de port forwarding vía SSM — redirige el puerto 5432 (PostgreSQL) de la EC2 a localhost
aws ssm start-session \
  --target i-0abc123def \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["5432"],"localPortNumber":["5432"]}'

Cómo Mitigar

AWS permite controlar el port forwarding vía IAM policies y SSM Session Documents. La estrategia recomendada es denegar por defecto y liberar solo para quien realmente lo necesite.

1. Bloquear Port Forwarding vía IAM

Esta policy debe ser aplicada en el IAM del usuario (o en el role asumido por él, como en el caso de SSO), y no en el role de la instancia EC2. Esto se debe a que es el usuario quien ejecuta la acción ssm:StartSession y la instancia solo recibe la conexión. Por lo tanto, el control de quién puede o no hacer port forwarding está del lado de quien inicia la sesión:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPortForwardingFromSSOToAponoInstances",
      "Effect": "Deny",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:*:*:instance/*",
        "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession",
        "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost"
      ],
    }
  ]
}

El documento AWS-StartPortForwardingSession redirige puertos de la propia instancia, mientras que AWS-StartPortForwardingSessionToRemoteHost permite redirigir puertos de otros hosts accesibles por la instancia (como un RDS en otra subnet). Ambos deben ser bloqueados si el objetivo es impedir cualquier tipo de túnel.

Esta policy puede ser aplicada como Service Control Policy (SCP) en AWS Organizations, garantizando que el bloqueo de port forwarding se aplique a todas las cuentas e instancias EC2 de la organización, independientemente de los permisos individuales de cada cuenta. Como las SCPs funcionan como guardrails de denegación, incluso si un administrador de cuenta concede permiso de port forwarding, la SCP impide la ejecución.

2. Monitorear con CloudTrail

Toda sesión SSM, incluyendo port forwarding, es registrada en CloudTrail. Configura alertas para detectar el uso de documentos de port forwarding:

• Monitorea eventos StartSession donde el DocumentName contenga PortForwarding.
• Crea alarmas en CloudWatch para notificar al equipo de seguridad cuando se utilice port forwarding.
• Mantén los logs de sesión habilitados en S3 o CloudWatch Logs para auditoría completa.

Cuándo Permitir Port Forwarding

El port forwarding no es inherentemente malo, ya que reemplaza prácticas aún más riesgosas, como exponer servicios directamente en internet. Escenarios donde tiene sentido permitirlo:

• Acceso a bases de datos en desarrollo: Los ingenieros necesitan conectar herramientas locales (como DBeaver o pgAdmin) a un RDS en una subnet privada.
• Debugging de aplicaciones internas: Acceder temporalmente a interfaces web de monitoreo o dashboards internos.
• Ambientes no productivos: En ambientes de desarrollo y staging, el riesgo es menor y la productividad es prioridad.

La recomendación es aplicar el principio de privilegio mínimo: bloquear port forwarding por defecto en producción y liberar bajo demanda con herramientas de acceso Just-in-Time como Apono.