En cloud, la mayoría de compromisos serios que he visto en empresa no empiezan con un 0-day ni con un puerto expuesto. Empiezan con una identidad y un token que “encajan” en el flujo normal: un pipeline que despliega, un conector SaaS que sincroniza datos, una cuenta de servicio que firma peticiones, o un rol asumido por automatización. El atacante no necesita romper el sistema si puede entrar por la misma puerta que usan los procesos.
El cambio clave es operativo: el perímetro ya no es la red. La unidad de control real es la identidad y el material de autenticación (tokens/keys) asociado. Y cuando hablamos de identidades no humanas, el riesgo se multiplica porque son persistentes, están muy distribuidas (CI/CD, runners, integraciones) y suelen tener permisos amplios por “comodidad”.
Superficie de ataque real: identidades no humanas y tokens que se comportan como llaves maestras
Las identidades no humanas (NHI) tienen un patrón común: son difíciles de “ver” como un usuario, pero operan todo el día. En un entorno corporativo típico hay decenas o cientos: cuentas de servicio, roles de automatización, integraciones con proveedores, webhooks, bots, agentes de monitorización. Cada una necesita autenticarse, y eso termina materializándose en un secreto: una API key, un refresh token, un client secret, un certificado, o credenciales temporales emitidas por un STS.
En incidentes reales, el punto de ruptura suele ser la gestión del token, no la lógica del sistema. Un token filtrado en logs de un job, en un artefacto de build, en variables de entorno mal protegidas, o en un repositorio privado que “no era tan privado”. La consecuencia práctica es que el atacante puede operar como si fuera esa automatización: listar secretos, leer buckets, pivotar entre cuentas/proyectos, o incluso crear nuevas identidades para persistir.
- Tokens de larga vida en integraciones SaaS
Un conector SaaS que usa refresh tokens sin rotación real se convierte en una credencial estable. Si se exfiltra, el atacante no necesita mantener un canal: renueva acceso y se mezcla con el tráfico normal del conector.
- Automatización con permisos amplios “para evitar tickets”
Cuando un pipeline tiene permisos de administración “por si acaso”, el atacante no busca escalar: ya entra escalado. En empresa esto se traduce en impacto rápido (borrado de recursos, creación de accesos, cambios en logging) y un MTTR mayor porque cuesta separar acciones legítimas de maliciosas.
Escenarios de abuso que se repiten: no rompen, inician sesión
El primer escenario típico es el robo de credenciales en la cadena de entrega. Un runner de CI comprometido (o mal aislado) extrae variables de entorno que contienen tokens de nube o de SaaS. Desde ahí, el atacante asume un rol, obtiene credenciales temporales y empieza a enumerar: “qué puedo leer”, “qué puedo modificar”, “qué puedo crear”. Nada de esto requiere explotar una vulnerabilidad del proveedor cloud: es IAM funcionando como fue diseñado.
El segundo escenario es el abuso de flujos legítimos de federación. Muchas empresas conectan identidad corporativa con cloud y con SaaS; eso es correcto, pero si un token de sesión, un refresh token o un client secret de una app se filtra, el atacante entra por la ruta “oficial”. En logs se ve como autenticación exitosa y llamadas API estándar. El daño aparece después: cambios en políticas, creación de access keys, desactivación de alertas o movimientos laterales hacia datos.
- Persistencia vía creación de nuevas identidades no humanas
Una vez dentro, es frecuente crear una nueva cuenta de servicio/rol “de mantenimiento”, asignarle permisos y dejarlo como backdoor. En organizaciones grandes, un nombre parecido a los existentes pasa desapercibido si no hay higiene de inventario y revisiones periódicas.
- Exfiltración silenciosa usando permisos de lectura
Con permisos de lectura sobre buckets, colas, bases gestionadas o secretos, el atacante puede extraer datos de forma paulatina. El tráfico puede parecer un job más de sincronización si no se correlaciona identidad-origen-volumen-objetivo.
Señales tempranas y telemetría: lo que delata a un token robado
La detección efectiva casi siempre empieza por una pregunta: “¿esta identidad no humana está actuando como siempre?”. Las NHI deberían ser predecibles: mismos endpoints, mismas regiones, mismos horarios, mismos recursos. Cuando hay un compromiso por token, el atacante rompe esa predictibilidad. No porque “cometa errores”, sino porque necesita explorar y ampliar permisos o alcance.
En operación real, las señales más útiles no son genéricas; son desviaciones contra baseline. Por ejemplo: un rol de CI que de repente llama a APIs de IAM para crear políticas; una integración SaaS que empieza a enumerar buckets; un token de acceso usado desde una región donde nunca se opera; una identidad que hace List* masivo cuando normalmente hace llamadas puntuales.
- Cambios en el patrón de llamada API
Si una cuenta de servicio normalmente ejecuta 3–4 acciones (por ejemplo, leer un secreto y desplegar), cualquier aparición de acciones administrativas (crear roles, adjuntar políticas, deshabilitar logging) debe tratarse como sospecha prioritaria.
- Anomalías de contexto: región, IP, user-agent, proveedor
Los tokens robados suelen usarse desde infra distinta a la corporativa. Si no se valida el contexto (red, geografía, proveedor, encabezados consistentes), un atacante puede operar “legítimamente” desde cualquier sitio.
Cómo hacerlo en la práctica: guardrails de IAM y control de tokens para NHI (con ejemplos en AWS)
La mitigación útil no es “poner MFA a todo” (muchas NHI no pueden). Es diseñar la emisión y el uso de tokens para que sean cortos, acotados y atribuibles. En AWS, el objetivo es que casi ninguna automatización use claves de larga vida, y que los roles asumidos tengan condiciones que impidan usos fuera del contexto esperado.
El punto de partida práctico es inventariar NHI por función (qué hace), método de autenticación (cómo obtiene token) y radio de impacto (qué puede tocar). Con eso se puede imponer: duración de sesión baja, permisos mínimos y condiciones de confianza (trust policy) que limiten quién y cómo puede asumir roles.
- Restringir el rol de CI/CD a OIDC y bloquear claves largas
Si usas GitHub Actions o un proveedor similar, prioriza OIDC para asumir roles en AWS. El trust policy debe exigir sub/aud esperados (repositorio, rama, workflow). Así, aunque alguien robe un token de otro entorno, no podrá asumir el rol si no cumple condiciones.
- Forzar contexto y reducir superficie con condiciones
Introduce condiciones como aws:RequestedRegion, aws:PrincipalArn, o tags de sesión cuando aplique. El objetivo es que “el rol solo funcione” desde el flujo previsto. Esto reduce el valor de un token exfiltrado.
Ejemplo de trust policy (AWS IAM) para OIDC con GitHub Actions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:mi-org/mi-repo:ref:refs/heads/main"
}
}
}
]
}
Validación en AWS (qué revisar, no solo “configurar”):
- CloudTrail: verifica que las llamadas de CI entran como
AssumeRoleWithWebIdentityy no como access keys de IAM User. Si aparecenAccessKeyIdde usuarios, todavía hay credenciales largas en juego. - Duración de sesión: revisa el
SessionDurationdel rol y en eventos STS elsessionContext. Sesiones excesivamente largas aumentan ventana de abuso. - Acciones IAM inesperadas: crea alertas cuando identidades de automatización llamen a
iam:Create*,iam:Attach*,cloudtrail:StopLoggingo cambios en políticas. Si tu pipeline no administra IAM, esas acciones deberían ser “imposibles”.
Un anti-patrón que veo con frecuencia: “como el runner está dentro de nuestra VPC, es seguro”. Si el token sale del runner (logs, artefactos, variables), la VPC no protege nada. El control debe estar en el emisor (IAM/IdP) y en el alcance del token.
Recomendaciones para entornos corporativos
Los compromisos cloud actuales se explican mejor por identidad y tokens que por fallos de red. En particular, las identidades no humanas concentran riesgo porque operan de forma continua, se apoyan en secretos reutilizables y suelen acumular permisos. Cuando un atacante obtiene un token válido, la actividad se confunde con operación normal: no “rompe”, inicia sesión y usa APIs.
En la práctica, la mejora más tangible viene de tratar los tokens como material crítico: reducir vida útil, eliminar claves de larga duración donde sea posible, acotar permisos a la función real y añadir condiciones de confianza que impidan usos fuera de contexto. A nivel de operación, detectar compromisos exige baselines por identidad no humana y alertas sobre desviaciones claras (contexto, región, acciones IAM anómalas), porque es ahí donde un token robado empieza a delatarse.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.