Gestión de identidades no humanas: guía para equipos

La gestión de identidades no humanas (NHIM) es la disciplina de gobernar las credenciales y los derechos de acceso de los actores de máquina (cuentas de servicio, claves de API, tokens OAuth, identidades de cargas de trabajo y, cada vez más, agentes de IA) con el mismo rigor que ya aplicas a los empleados humanos. La razón por la que se ha convertido en una categoría con nombre propio, en lugar de una nota al pie de tu programa de IAM, es la escala: las identidades no humanas superan ya en número a las humanas en la mayoría de los entornos en la nube, y suelen tener un privilegio permanente más amplio, con peor rotación y monitorización que las cuentas humanas. Dicho de otro modo, la población de identidades más grande y menos vigilada de tu entorno es la que nadie usa para iniciar sesión. Este artículo explica qué son estas identidades, por qué se comportan de forma distinta a las humanas y cómo ponerlas bajo control.

¿Qué cuenta como identidad no humana?

Una identidad no humana (a veces escrita «nonhuman identity» o NHI) es cualquier entidad autenticable de tus sistemas que no es una persona. Se autentica con un secreto o un certificado en lugar de una contraseña más MFA, y normalmente actúa en nombre de código, infraestructura u otro sistema. Ejemplos concretos que casi seguro tienes funcionando ahora mismo:

• Cuentas de servicio: la identidad que usa una tarea en segundo plano, una tarea cron o un servicio de backend para llegar a una base de datos o a otra API.
• Claves de API y tokens de acceso: cadenas de larga duración que conceden acceso programático a plataformas SaaS, proveedores de pago o APIs en la nube.
• Aplicaciones OAuth e integraciones de terceros: una herramienta de marketing con permiso de lectura/escritura sobre tu Google Workspace o Salesforce.
• Identidades de cargas de trabajo en la nube: roles de AWS IAM, identidades administradas de Azure, cuentas de servicio de GCP asociadas a recursos de cómputo.
• Cuentas de servicio y secretos de Kubernetes: identidades a nivel de pod usadas en las llamadas entre servicios.
• Credenciales de pipelines de CI/CD: los tokens que usa tu sistema de compilación para desplegar en producción.
• Agentes de IA: la categoría más reciente y de crecimiento más rápido: procesos autónomos o semiautónomos que tienen sus propias credenciales y llaman a herramientas en tu nombre.

El hilo común: ninguna tiene a una persona detrás en el momento de autenticarse, lo que rompe la mayoría de las suposiciones integradas en la IAM tradicional.

Por qué las identidades no humanas son más difíciles de proteger que las personas

La gestión de identidades humanas se apoya mucho en controles que sencillamente no se aplican a las máquinas. No puedes enviar una notificación push a una clave de API. No puedes hacerle una pregunta de seguridad a un pod de Kubernetes. Ese desajuste produce tres debilidades estructurales, todas recogidas en la realidad de que las NHI «tienen un privilegio permanente más amplio, con peor rotación y monitorización que las cuentas humanas»:

• Privilegio permanente. Las cuentas de servicio se aprovisionan con exceso con frecuencia «para que funcione» y nunca se recortan. Una credencial de pipeline que necesitaba acceso de escritura a un bucket de S3 acaba con privilegios de administrador en toda la cuenta porque era la forma más rápida de desbloquear un despliegue.
• Rotación débil. Las contraseñas de las personas caducan y la MFA atenúa el robo. Las claves de API y los tokens de larga duración a menudo viven durante años, se copian en archivos de configuración y acaban subidos a Git o pegados en Slack.
• Monitorización escasa. Un inicio de sesión desde un país nuevo de una persona dispara alertas. Una cuenta de servicio que llama a las 3 de la madrugada a una API que nunca había tocado normalmente no dispara nada, porque nadie construyó una línea base de comportamiento para las máquinas.

Combina «superan en número a las identidades humanas» con «privilegio más amplio y controles más débiles» y obtienes el panorama real del riesgo: tu mayor población privilegiada es también la menos gobernada. Por eso las NHI son una vía favorita de movimiento lateral en las brechas en la nube: un atacante que se hace con una clave filtrada a menudo hereda mucho más privilegio del que tendría un empleado víctima de phishing.

Los cinco pilares de la IAM y cómo se trasladan a las máquinas

La IAM suele describirse en cinco pilares. Recorrerlos para las identidades no humanas deja al descubierto exactamente dónde fallan los programas:

• 1. Identificación: establecer una identidad única y descubrible para cada entidad. Para las máquinas es el primer paso más difícil: la mayoría de las organizaciones no pueden producir un inventario completo de sus cuentas de servicio y tokens. No puedes gobernar lo que no ves.
• 2. Autenticación: demostrar que la identidad es quien dice ser. Para las NHI significa secretos, certificados o federación de identidades de cargas de trabajo de corta duración en lugar de contraseñas y MFA.
• 3. Autorización: decidir qué puede hacer la identidad. Aquí es donde hay que imponer el mínimo privilegio de forma agresiva, porque los roles de máquina con alcance excesivo son la norma.
• 4. Administración: el ciclo de vida: aprovisionamiento, rotación y baja. Las cuentas humanas se dan de baja cuando alguien se va; las identidades de máquina no tienen un desencadenante equivalente, así que las credenciales huérfanas se acumulan.
• 5. Auditoría y monitorización: verificar de forma continua el comportamiento y el acceso. Este pilar está casi siempre poco desarrollado para las máquinas.

El patrón es constante: los controles que funcionan en los pilares 1–5 para las personas faltan o son manuales para las máquinas. La NHIM consiste, en el fondo, en cerrar esa brecha pilar a pilar.

Un método práctico para poner bajo control las NHI

No intentes abarcarlo todo. Trabaja en este orden, porque cada paso hace posible el siguiente:

• Descubre e inventaría. Enumera las cuentas de servicio, los roles IAM, las claves de API, las concesiones OAuth y las credenciales de CI/CD en tus proveedores de nube, consolas de administración SaaS y almacenes de secretos. Etiqueta cada una con un responsable. Una identidad sin responsable es tu primer objetivo de limpieza.
• Asigna responsables. Cada NHI necesita una persona o un equipo que responda de ella. La asignación de responsables es el control que arregla después la rotación y la baja, porque ahora a alguien se le pregunta «¿sigue haciendo falta que esto exista?».
• Ajusta el privilegio. Obtén los registros de uso real y recorta los permisos a lo que se usó en los últimos 90 días. Los proveedores de nube exponen datos de «último uso» de roles y claves: úsalos. Esto ataca directamente el problema del privilegio permanente.
• Elimina los secretos de larga duración. Sustituye las claves de API estáticas por credenciales federadas de corta duración allí donde la plataforma lo permita (federación de identidades de cargas de trabajo, autenticación de CI/CD basada en OIDC). Donde tengas que conservar secretos, guárdalos en un almacén e impón la rotación.
• Establece una línea base y monitoriza el comportamiento. Construye un perfil sencillo por identidad (qué APIs, qué IP de origen, qué horas) y alerta ante las desviaciones. Es el pilar de monitorización que la mayoría de los equipos se saltan.

Un ejemplo práctico: priorizar 4.000 cuentas de servicio

Supón que tu análisis de descubrimiento encuentra 4.000 identidades no humanas. No puedes remediarlas todas este trimestre, así que puntúalas. Clasifica cada identidad como de alto riesgo si cumple dos o más de estas condiciones: (1) tiene privilegios de administrador o de escritura amplios, (2) usa un secreto estático de más de 90 días, (3) no tiene responsable asignado, (4) accedió a datos de producción en los últimos 30 días. Una cuenta sin responsable con una clave de dos años y acceso de escritura a producción es tu máxima prioridad: combina el máximo radio de impacto con la máxima exposición. En la práctica, esta puntuación suele sacar a la luz unas pocas docenas de identidades que concentran la mayor parte del riesgo real, lo que permite a un equipo pequeño avanzar de forma medible en semanas en lugar de años. Da de baja las que están muertas, rota y vuelve a acotar las activas, y pon monitorización a lo que quede.

Si quieres una forma rápida de valorar dónde está tu organización en exposición de identidades de máquina y humanas antes de construir el inventario completo, la Identity Risk Calculator gratuita de PlayCISO te guía por los factores de riesgo clave y te da un punto de partida priorizado en pocos minutos.

Preguntas frecuentes

¿Qué cuenta como identidad no humana?

Una identidad no humana (a veces escrita «nonhuman identity» o NHI) es cualquier entidad autenticable de tus sistemas que no es una persona. Se autentica con un secreto o un certificado en lugar de una contraseña más MFA, y normalmente actúa en nombre de código, infraestructura u otro sistema.

¿Por qué las identidades no humanas son más difíciles de proteger que las personas?

La gestión de identidades humanas se apoya mucho en controles que sencillamente no se aplican a las máquinas. No puedes enviar una notificación push a una clave de API. No puedes hacerle una pregunta de seguridad a un pod de Kubernetes. Ese desajuste produce tres debilidades estructurales, todas recogidas en la realidad de que las NHI «tienen un privilegio permanente más amplio, con peor rotación y monitorización que las cuentas humanas»: Privilegio permanente.

¿Cómo se trasladan los cinco pilares de IAM a las máquinas?

La IAM suele describirse en cinco pilares. Recorrerlos para las identidades no humanas deja al descubierto exactamente dónde fallan los programas: 1. Identificación: establecer una identidad única y descubrible para cada entidad. Para las máquinas es el primer paso más difícil: la mayoría de las organizaciones no pueden producir un inventario completo de sus cuentas de servicio y tokens.

¿Qué método práctico hay para poner bajo control las NHI?

No intentes abarcarlo todo. Trabaja en este orden, porque cada paso hace posible el siguiente: Descubre e inventaría. Enumera las cuentas de servicio, los roles IAM, las claves de API, las concesiones OAuth y las credenciales de CI/CD en tus proveedores de nube, consolas de administración SaaS y almacenes de secretos.