El primer paso siempre es descubrir. Las NHI viven repartidas entre tenants cloud, gestores de secretos, conectores SaaS, pipelines de despliegue y código fuente. Sin un inventario consolidado, cualquier intento de gobierno parte ciego.
Qué es NHI
NHI (Non-Human Identities, identidades no humanas) es el conjunto de identidades que utilizan los sistemas para hablar entre sí: cuentas de servicio, tokens de aplicación, claves API, certificados de máquina, identidades de pipelines CI/CD, conectores SaaS y, cada vez más, agentes autónomos basados en IA. En cualquier organización con cierta madurez tecnológica las identidades no humanas superan a las humanas en proporciones que van de 20 a 1 hasta más de 50 a 1. A pesar de esa proporción, suelen estar peor gobernadas: secretos incrustados directamente en el código de repositorios, claves que llevan años sin rotarse, permisos heredados que nadie revisa y propiedad difusa entre equipos. NHI es el concepto que pone foco en gobernarlas como activo de identidad de primer orden y no como un detalle de despliegue.
Por qué importa
Cuando un incidente serio toca el plano de identidad, la víctima suele ser una identidad no humana: un token expuesto en un repositorio público, una clave API de una integración SaaS comprometida en un proveedor, una cuenta de servicio con permisos sobre todo el tenant y sin rotación. Para un atacante, las NHI son objetivos privilegiados: tienen permisos amplios, no usan MFA, no rotan, no notifican uso anómalo y suelen estar olvidadas en el inventario. Para un equipo de seguridad, gobernarlas exige descubrirlas, asignar propiedad, rotar secretos, aplicar mínimo privilegio y monitorizar uso. Para marcos como NIS2, DORA o ISO 27001 que exigen control de identidades y de accesos, ignorar las NHI deja una de las puertas más usadas sin tapar.
Puntos clave
Cada NHI debe tener un propietario humano explícito y nombrado. Sin propietario, los hallazgos de rotación, mínimo privilegio o revocación quedan sin destinatario. La propiedad debe revisarse al menos una vez al año y disparar reasignación inmediata cuando el responsable cambia de rol.
La rotación de credenciales es uno de los controles más críticos y más incumplidos. Cualquier token, clave API o secreto debe tener fecha de caducidad y mecanismo automatizado de rotación. Lo manual no funciona a escala.
El uso de gestores de secretos es condición necesaria, no suficiente. Una NHI con su token en el gestor pero también escrito directamente en el código de cinco repositorios sigue siendo vulnerable. La integración correcta es «sólo desde el gestor» y validada con escaneo continuo de secretos en el código.
El mínimo privilegio es especialmente importante para NHI porque sus permisos no se cuestionan en revisiones periódicas. Plataformas CIEM bien aplicadas reducen significativamente los permisos efectivos de identidades de servicio comparando lo otorgado con lo usado en logs.
Los agentes autónomos basados en IA son la generación más reciente de NHI y la que más rápido crece. Heredan los mismos problemas (permisos amplios, falta de rotación, propiedad difusa) y añaden uno nuevo: pueden tomar decisiones de acción por sí mismos, lo que hace que cada permiso otorgado tenga consecuencias amplificadas.
Ejemplo: programa de gobierno de NHI en una empresa cloud-first
Una organización con producto en cloud, varios SaaS críticos integrados y pipelines CI/CD que despliegan veinte veces al día decide aplicar un programa de gobierno de identidades no humanas. El primer barrido —combinando inventarios de los proveedores cloud, gestores de secretos, conectores SaaS y escaneo de secretos en repositorios— descubre 2.300 identidades no humanas activas. De ellas, 420 tienen permisos amplios sobre datos críticos, 180 no se han rotado en más de 12 meses, 90 son secretos escritos directamente en el código y 30 son cuentas heredadas de empleados que ya no están en la empresa.
El equipo establece tres acciones inmediatas: revocación de las 30 cuentas huérfanas con notificación a los equipos afectados, sustitución de los 90 secretos escritos directamente en el código por consumo desde gestor con rotación automática, y plan de reducción de permisos sobre las 420 identidades sobre-permisionadas usando CIEM con base en uso real. A los tres meses el inventario tiene propiedad explícita en el 98 por ciento de las NHI, la rotación está automatizada en el 85 por ciento y los permisos efectivos se han reducido un 60 por ciento. La métrica clave que se entrega al comité no es ya 'tenemos gestor de secretos' sino 'la edad media de credencial es de 28 días y bajando'.
Errores habituales
- Tratar las identidades no humanas como detalle de despliegue. Mientras las humanas pasan por procesos formales (alta, baja, revisión periódica), las NHI suelen nacer en un script y morir en otro. Sin gobernanza explícita, acaban siendo la puerta más usada en incidentes serios.
- Confiar en que el gestor de secretos basta. Un secreto en el gestor que también vive escrito directamente en el código de repositorios no es un secreto. La integración debe ser exclusiva («sólo desde gestor») y validada con escaneo continuo de secretos en el código.
- No asignar propietario humano. Sin un responsable nombrado por NHI, los hallazgos quedan en una lista. La propiedad debe revisarse al menos anualmente y reasignarse de forma inmediata cuando el responsable cambia de rol.
- Aplicar rotación manual. Cualquier rotación que dependa de que un humano se acuerde de hacerla, no se hará. La rotación debe estar automatizada y la métrica de éxito es la edad media de credencial.
- Olvidar que los agentes de IA son también NHI. Cada vez se conceden más permisos a agentes autónomos y, con frecuencia, sin propietario, sin rotación y con privilegios excesivos. Las consecuencias de un agente con permisos amplios y mal gobernado son superiores a las de una NHI tradicional porque toman decisiones de acción.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Cuántas identidades no humanas tiene una empresa típica?
Depende de la madurez tecnológica, pero en organizaciones con presencia en cloud, varios SaaS integrados y pipelines CI/CD activos las identidades no humanas suelen superar a las humanas en proporción de 20 a 1 hasta 50 a 1. Una primera estimación honesta sólo se obtiene tras un descubrimiento que cruce inventario cloud, gestores de secretos, conectores SaaS y escaneo de secretos en repositorios.
¿Por qué son objetivo preferente de los atacantes?
Porque combinan permisos amplios, ausencia de MFA, rotación inexistente, propiedad difusa y monitorización pobre. Comprometer una cuenta de servicio o un token de aplicación equivale a entrar con un usuario humano administrador sin que nadie note nada inusual. Es la forma más eficiente de moverse por un entorno sin disparar alertas.
¿Qué papel juega CIEM en el gobierno de NHI?
CIEM se centra en los permisos efectivos en cloud y compara lo otorgado con lo usado realmente en logs. Para identidades no humanas esa comparación es especialmente útil, porque rara vez justifican los permisos amplios que se les concedieron en su origen. Un buen programa de gobierno de NHI usa CIEM como motor de reducción al mínimo privilegio.
¿Cómo se gobierna a un agente de IA como identidad no humana?
Los agentes basados en IA siguen siendo identidades no humanas y se gobiernan con los mismos principios: propietario explícito, secretos en gestor con rotación automatizada, mínimo privilegio basado en uso real y monitorización del comportamiento. La diferencia clave es que ejecutan acciones de forma autónoma, por lo que cualquier permiso excesivo amplifica el daño potencial. La regla operativa es 'concede sólo lo que el agente necesita para esa decisión concreta y por el tiempo justo'.