Skip to main content

Acceso SSM vía Apono

Uno de los motivos más comunes para adoptar Apono es resolver el problema del acceso directo a máquinas en AWS. En la mayoría de las organizaciones, los ingenieros necesitan acceder a instancias EC2 para troubleshooting, deploys manuales o investigación de incidentes, y el modelo tradicional de permisos permanentes genera riesgos de seguridad significativos.

Antes de entender cómo Apono automatiza este acceso, es importante dominar cómo funciona AWS Systems Manager Session Manager (SSM), el servicio nativo de AWS que reemplaza a los bastion hosts y las claves SSH. Si aún no conoces SSM, lee primero el artículo sobre AWS Systems Manager — Session Manager.

El Problema de los Permisos Permanentes​

Con SSM configurado en la infraestructura, el control de acceso a las instancias se realiza mediante permisos IAM. El usuario necesita tener la policy ssm:StartSession para iniciar sesiones en instancias específicas.

El problema es cómo se concede este permiso en la práctica:

  1. Un ingeniero solicita acceso a una EC2.
  2. Un administrador agrega manualmente la policy ssm:StartSession al usuario o grupo IAM.
  3. El ingeniero utiliza el acceso.
  4. Nadie recuerda eliminar el permiso.

El acceso que debería ser temporal se vuelve permanente. Con el tiempo, cada ingeniero acumula permisos en decenas de instancias a las que ya no necesita acceder, ampliando la superficie de ataque y violando el principio de privilegio mínimo.

Cómo lo Resuelve Apono​

Apono gestiona los permisos IAM que controlan quién puede iniciar sesiones SSM y en qué instancias. No reemplaza a SSM — la infraestructura (Agent, Instance Profile, VPC Endpoints) sigue funcionando normalmente. Lo que cambia es que el permiso del usuario para iniciar sesiones pasa a ser temporal y auditado.

El flujo con Apono:

El connector de Apono gestiona esto agregando y eliminando policies IAM inline o administradas en el usuario/grupo/role. Cuando el tiempo expira, la policy se elimina automáticamente — el ingeniero pierde inmediatamente la capacidad de iniciar nuevas sesiones SSM.

Qué Cambia en la Práctica​

Con Apono gestionando el acceso SSM, el ciclo de vida del permiso pasa a ser:

  • Solicitud explícita: El ingeniero debe pedir el acceso (vía portal, Slack o CLI), indicando qué instancia y por qué.
  • Aprobación por política: La solicitud se aprueba automáticamente (si la política lo permite) o se envía a un aprobador humano.
  • Alcance granular: La policy concedida es para instancias específicas, no para "todas las EC2".
  • Duración definida: El acceso tiene un plazo (ej: 2 horas) y se revoca automáticamente al expirar.
  • Auditoría completa: Quién solicitó, cuándo, para qué instancia, quién aprobó, cuándo expiró — todo queda registrado.

La infraestructura SSM (Agent instalado, Instance Profile configurado, VPC Endpoints activos) debe estar funcionando antes de que Apono entre en escena. Apono no configura SSM — solo controla quién tiene permiso para usarlo y por cuánto tiempo.