Cuando hablamos de seguridad en AWS, la conversación casi siempre empieza y termina en IAM.
Pero hay un escenario que muchas organizaciones enfrentan y que no siempre tiene una respuesta obvia: ¿qué pasa cuando el workload que necesita acceder a recursos en AWS no vive dentro de AWS?
Hay compañías con regulaciones estrictas de seguridad y cumplimiento que mantienen parte de su infraestructura detrás de data centers propios o firewalls corporativos. Hay equipos en medio de migraciones o modernizaciones que todavía tienen servidores tradicionales que necesitan hablar con servicios en la nube. En todos estos casos, la solución más obvia — usar access keys — trae consigo una lista de problemas conocidos: pueden olvidarse, necesitan rotarse periódicamente, hay que controlar cómo se exponen, y las sesiones expiran de formas que a veces nadie monitorea. Sin mencionar que la trazabilidad de quién usó qué credencial y cuándo se vuelve una pesadilla de auditoría.
La respuesta que propusimos es IAM Roles Anywhere, un servicio que permite emitir credenciales temporales de AWS para cargas de trabajo que viven fuera de la nube, ya sean servidores bare metal, contenedores on-prem o cualquier aplicación corriendo en un data center corporativo.
El mecanismo de verificación se basa en certificados X.509 y PKI, lo que significa que en lugar de manejar access keys estáticas, estás manejando una infraestructura de confianza basada en certificados — algo que los equipos de seguridad entienden y controlan mucho mejor.
Primero, una Certificate Authority emite certificados para cada carga de trabajo, confirmando que son entidades reconocidas dentro de tu infraestructura.
Luego se configura un Trust Anchor en AWS que referencia esa CA — usando AWS Private CA es la ruta más integrada, aunque también puedes usar Let's Encrypt u otra CA pública si entiendes las implicaciones de a quién le estás otorgando confianza.
Finalmente, cuando una carga de trabajo necesita credenciales, presenta su certificado firmado por la CA, firma la solicitud con su llave privada, y AWS devuelve credenciales temporales para el IAM Role asociado.
Todo esto orquestado por el aws_signing_helper, el credential helper oficial que hace que el proceso sea transparente para tus aplicaciones.
En Terraform, la implementación se divide en tres recursos principales: la aws_acmpca_certificate_authority para levantar la CA privada, el aws_rolesanywhere_trust_anchor que la referencia y sirve como punto de confianza, y el aws_rolesanywhere_profile que define qué IAM Role puede ser asumido por qué carga de trabajo. El IAM Role en sí se configura de la misma forma que cualquier otro, con la diferencia de que el principal en el assume role policy es rolesanywhere.amazonaws.com y las acciones incluyen sts:SetSourceIdentity para mejor trazabilidad.
Una de las cosas que más me gusta de esta arquitectura es que el monitoreo queda completamente integrado con los servicios nativos de AWS. CloudWatch Metrics te da visibilidad sobre expiración de certificados e intentos de login fallidos.
CloudTrail registra todos los eventos relevantes de API. Y con EventBridge puedes construir automatizaciones sobre cualquiera de esos eventos — por ejemplo, una alerta cuando un certificado está próximo a expirar o cuando hay un patrón anómalo de intentos fallidos.
En cuanto a mejores prácticas, la recomendación central es tratar esto exactamente como tratas cualquier estrategia de IAM: un rol por carga de trabajo, mínimo privilegio, y roles exclusivamente asumibles por rolesanywhere para no abrir superficies de ataque innecesarias.
IAM Roles Anywhere como servicio no tiene costo — lo que sí tiene costo es AWS Private CA, que vale la pena evaluar contra alternativas como usar una CA pública, siempre considerando el modelo de confianza que eso implica.
También es importante configurar soporte para CRL (Certificate Revocation Lists) desde el principio, porque si un certificado se pierde o se compromete, necesitas poder revocarlo sin tener que reconstruir toda la cadena de confianza.
Top comments (0)