Las identidades no humanas se han convertido en la mayor superficie de ataque sin gestionar en la seguridad en la nube

En un entorno cloud empresarial típico de hoy, las identidades de máquina — cuentas de servicio, API keys, tokens OAuth, credenciales de CI/CD e identidades de workload — superan a las cuentas de usuario humano en proporciones que suelen citarse entre 45:1 y 90:1. Los equipos de seguridad han pasado dos décadas construyendo gestión de identidad y acceso en torno a las personas: onboarding, offboarding, autenticación multifactor, revisión periódica de accesos. Casi ninguna de esas infraestructuras se construyó para máquinas, y se nota. Las identidades no humanas (NHIs) se han convertido silenciosamente en la mayor superficie de ataque sin gestionar en la seguridad cloud, y la mayoría de las organizaciones no pueden responder una pregunta básica: cuántas credenciales de máquina existen en su entorno, quién o qué es el propietario de cada una, y cuándo se usó por última vez.

Por qué el IAM tradicional no cubre las máquinas

La gobernanza de identidad humana se basa en supuestos que no se sostienen para las máquinas. Una persona tiene un manager que puede dar fe de la necesidad continuada de acceso. Una persona tiene una entrevista de salida y un checklist de offboarding cuando se va. La solicitud de acceso de una persona pasa por un ciclo de revisión. Las cuentas de servicio, en cambio, se crean con frecuencia de forma ad hoc por un desarrollador que aprovisiona un nuevo microservicio, se les otorgan permisos amplios para evitar depurar errores de permisos más adelante, y luego nunca se revisan. La credencial sobrevive al proyecto, al desarrollador que la creó y, a menudo, a la razón por la que existía en primer lugar. Multiplique ese patrón por cada pipeline de CI/CD, cada integración SaaS de terceros, cada servicio interno que llama a otro servicio interno, y el problema de inventario se vuelve enorme.

Cómo se comprometen realmente las credenciales de máquina

Los patrones de brecha son sorprendentemente consistentes en los informes de incidentes. Las API keys de larga duración se suben a repositorios públicos de GitHub por desarrolladores que olvidan añadirlas a un archivo .gitignore — los escáneres automatizados las encuentran y explotan en cuestión de minutos tras la exposición. Las cuentas de servicio con privilegios excesivos, a las que se les otorgó acceso de nivel admin porque era más rápido que delimitar los permisos correctamente, convierten una única credencial comprometida en acceso total al entorno. Los tokens OAuth obsoletos de una integración SaaS que se dio de baja hace dieciocho meses siguen siendo válidos porque nadie los revocó. Y en entornos cloud-native, las identidades de workload que deberían ser de corta duración y estar limitadas a un solo pod o función se incrustan en imágenes de contenedor como secretos estáticos de larga duración.

Ninguna de estas son técnicas de ataque exóticas. Son fallos básicos de higiene a escala, y los atacantes lo saben. Los ataques basados en credenciales contra identidades de máquina se han convertido en uno de los vectores de acceso inicial más fiables precisamente porque las herramientas defensivas que detectarían un inicio de sesión humano sospechoso — geografía anómala, hora de acceso inusual, fingerprinting de dispositivo — a menudo no se aplican limpiamente a un script que llama a una API desde un centro de datos a las 3 a.m., lo cual es un comportamiento de máquina completamente normal.

Qué está cambiando realmente

Ha surgido una nueva categoría de herramientas de seguridad específicamente para abordar esta brecha, con proveedores como Astrix Security, Entro, Oasis Security y Token Security que construyen productos para descubrir, inventariar y monitorizar NHIs en entornos cloud y SaaS de formas que las herramientas IAM de propósito general nunca fueron diseñadas para hacer. Estas plataformas suelen empezar construyendo un inventario completo — algo que la mayoría de las organizaciones nunca han tenido — y luego añaden una capa de scoring de riesgo basado en el nivel de privilegio, la antigüedad de la credencial y los patrones de uso, y finalmente automatizan la remediación, como la rotación de credenciales o la delimitación de accesos.

Los proveedores de cloud también han avanzado en esto. AWS, Google Cloud y Azure ahora ofrecen workload identity federation, que permite a un servicio autenticarse usando tokens de corta duración rotados automáticamente y vinculados a su identidad de runtime real en lugar de una clave estática de larga duración. Esto elimina toda una categoría de riesgo — la credencial estática filtrada — por diseño, pero la adopción requiere re-arquitecturar las integraciones existentes, razón por la cual la migración ha sido lenta a pesar de que las herramientas llevan disponibles varios años.

Qué deberían hacer realmente los equipos de seguridad

Empiece por el descubrimiento, no por la remediación. No se puede asegurar lo que no se puede ver, y la mayoría de las organizaciones subestiman su recuento de NHIs por un orden de magnitud hasta que ejecutan un escaneo adecuado en cuentas cloud, consolas de administración SaaS, sistemas de CI/CD y repositorios de código fuente. Una vez que tenga un inventario, priorice por radio de explosión: una credencial con acceso admin al cloud importa más que una API key de solo lectura para una herramienta interna de baja sensibilidad, independientemente de cuál sea más antigua o más visible.

Muévase hacia credenciales de corta duración dondequiera que la plataforma lo soporte — workload identity federation para autenticación cloud-a-cloud, tokens OIDC para pipelines de CI/CD en lugar de secretos estáticos almacenados en la configuración del pipeline. Para las credenciales que deben permanecer de larga duración, imponga rotación en un calendario fijo en lugar de depender de que alguien recuerde hacerlo manualmente, y establezca fechas de expiración como opción predeterminada en lugar de excepción. Finalmente, asigne propiedad. Cada credencial de máquina debería mapearse a una persona o equipo responsable de ella, igual que cada cuenta humana se mapea a un empleado. Una credencial sin propietario es una credencial que nadie notará que se vuelve obsoleta, que nadie marcará por uso sospechoso, ni pensará en revocar cuando el sistema al que sirve se dé de baja — que es exactamente la brecha que los atacantes están explotando actualmente a escala.