Guía del CISO para la seguridad de las identidades no humanas

¿Qué son las identidades no humanas?

A primera vista, el término "identidad no humana" parecería incluir cualquier cosa que no sea una persona, como servidores, dispositivos, cargas de trabajo, cuentas de servicio, etc. Sin embargo, la concepción de la identidad en el sector ha evolucionado. En entornos heredados, las identidades de máquina suelen referirse a certificados, claves SSH, cuentas de dispositivos o cuentas de servicio vinculadas a sistemas operativos o hardware. Estas eran relativamente estáticas, predecibles y estaban estrechamente alineadas con las pilas de infraestructura.

Sin embargo, en un entorno nativo de la nube e impulsado por API, esa definición ya no es suficiente. Las NHI abarcan un conjunto de identidades mucho más amplio y dinámico, que incluye lo siguiente:

• Identidades de cargas de trabajo. Estas representan cargas de trabajo en la nube —máquinas virtuales, contenedores, funciones sin servidor— a las que se les permite autenticarse en los recursos de la nube. Algunos ejemplos son los roles de gestión de identidades y accesos (IAM) de AWS para EC2 o Lambda, las identidades gestionadas de Azure y las cuentas de servicio de Google Cloud. Estas identidades suelen tener una vida útil de entre microsegundos y horas, y con frecuencia generan credenciales temporales.
• Cuentas de servicio. Estas incluyen cuentas de sistema operativo o de aplicación utilizadas por servicios internos, aplicaciones, bases de datos o sistemas de copia de seguridad. A menudo ejecutan procesos en segundo plano o tareas programadas. A pesar de ser una de las formas más antiguas de NHI, siguen siendo una de las menos reguladas y con mayores privilegios.
• Identidades de aplicación. Se trata de componentes de software, como API, microservicios y aplicaciones web, que se autentican en bases de datos, intermediarios de mensajes o API de terceros. Estas identidades pueden utilizar tokens de API, secretos de OAuth o claves integradas.
• Secretos y claves de API. Entre ellos se incluyen las credenciales utilizadas directamente por software, scripts, canalizaciones de automatización o plantillas de infraestructura como código. A menudo representan claves de API: SaaS, nube, pasarelas de pago; cadenas de conexión a bases de datos; secretos de cliente OAuth; tokens de GitHub y GitLab; y tokens de registro de contenedores.
• Identidades compuestas de IA y aprendizaje automático. Con el auge de los agentes de IA, los flujos de trabajo impulsados por modelos de lenguaje a gran escala y los procesos autónomos, los procesos basados en modelos crean y utilizan identidades para llamar a API, recuperar datos o realizar acciones automatizadas.
• Identidades de OT e IoT. Los sensores, los sistemas de control industrial, las cámaras, los dispositivos médicos y otros sistemas integrados se autentican en consolas de gestión o recopiladores de datos. A menudo utilizan credenciales débiles o predeterminadas de fábrica, a menos que se regulen explícitamente.

Si bien las identidades de máquina y las NHI se solapan, las NHI introducen las tres diferencias fundamentales siguientes:

• Escala. Las identidades de máquina tradicionales —certificados, cuentas de dispositivos— son relativamente pocas y de larga duración. Las NHI alcanzan escalas de decenas de miles o millones y se crean dinámicamente mediante pipelines de integración continua/entrega continua (CI/CD), cargas de trabajo autoescaladas, IA e infraestructura de autorreparación, y automatización basada en eventos. La mayoría de las herramientas heredadas de IAM y gestión de acceso privilegiado (PAM) nunca se diseñaron para gestionar ese nivel de volumen y rotación.
• Diversidad de métodos de autenticación. Las identidades de máquina han utilizado históricamente certificados o Kerberos para autenticarse. Las NHI se autentican utilizando una gama mucho más amplia de métodos, entre los que se incluyen tokens web JSON, roles de IAM en la nube, secretos de OAuth2/Open ID Connect, claves API de larga duración y más. Cada uno de ellos requiere una gobernanza, rotación, gestión del ciclo de vida y manejo de la telemetría únicos.
• Mayor autonomía. Las NHI suelen ser más autónomas que las identidades de máquina tradicionales y, en muchos casos, realizan acciones de forma independiente. Inician llamadas a la API, transfieren datos, activan recursos, ejecutan scripts e interactúan con sistemas críticos. Esta autonomía implica que las NHI pueden causar daños a gran escala con extrema rapidez si se ven comprometidas, y es posible que los controles de seguridad tradicionales no detecten el comportamiento de las NHI como anómalo.

Retos de la protección de las NHI

Las NHI representan una nueva clase de riesgos de identidad de gran impacto y en rápida evolución que no pueden abordarse fácilmente con las herramientas existentes ni con los modelos mentales utilizados para las identidades humanas. Este reto se agrava aún más a medida que las organizaciones aceleran la automatización y la adopción de la nube. La proliferación de las NHI también aumenta más rápidamente que la madurez de la gobernanza.

Los siguientes problemas hacen que los NHI sean especialmente difíciles de proteger:

• Falta de titularidad y responsabilidad. Los NHI suelen crearse automáticamente por equipos de infraestructura, procesos de DevOps, equipos de aplicaciones e integraciones SaaS. En muchos casos, no existe una idea clara de quién es el propietario de la identidad, quién controla y aprueba los permisos, o quién debe rotar las claves, etc. Este vacío de titularidad da lugar a identidades que persisten mucho más tiempo del previsto.
• Privilegios excesivos. Las NHI suelen recibir permisos amplios y sobredimensionados, entre los que se incluyen roles IAM comodín en la nube, cuentas de servicio con derechos completos de administrador de dominio y claves API con ámbitos completos de lectura/escritura. Dado que las NHI automatizan los procesos empresariales, los equipos temen interrumpir su funcionamiento y evitan reducir los privilegios. Como resultado, una amplia gama de identidades puede acceder a cantidades masivas de datos confidenciales o a la infraestructura.
• Credenciales de larga duración y codificadas de forma estática. Muchos NHI dependen de claves API que nunca se rotan, secretos codificados de forma estática en repositorios de código, credenciales almacenadas en archivos de configuración o scripts, y secretos compartidos que se reutilizan en diferentes aplicaciones. Esto genera una alta probabilidad de fuga de credenciales, a menudo como resultado de errores de los desarrolladores, configuraciones erróneas o registros de CI/CD que exponen secretos.
• Falta de referencias de comportamiento. El comportamiento de los usuarios humanos es relativamente predecible. Los inicios de sesión se ajustan al horario laboral, las cuentas de usuario rara vez realizan miles de llamadas a la API por minuto y los patrones de acceso suelen coincidir con las funciones del puesto. Las NHI son más difíciles de perfilar, con un uso de la API de alta frecuencia, picos de actividad automatizados, patrones irregulares impulsados por flujos de trabajo o desencadenantes, y una posible interacción con numerosos sistemas. Esto hace que la detección de anomalías sea más compleja y difícil de ajustar.
• Telemetría y supervisión limitadas. Las herramientas de seguridad se diseñaron en torno a los patrones de identidad humana. Los productos SIEM, de análisis del comportamiento de usuarios y entidades y PAM a menudo no analizan los registros de autenticación de las NHI ni modelan la puntuación de riesgo de las NHI, y pueden carecer de visibilidad sobre la comunicación entre servicios. Incluso en la nube, donde existen abundantes registros de IAM, estos archivos pueden ser ruidosos, prolijos y estar dispersos entre distintos servicios.
• Propagación de credenciales en integraciones multinube y SaaS. Dado que muchas organizaciones utilizan NHI para conectar entornos en la nube, herramientas de CI/CD, plataformas SaaS e infraestructura local tradicional, los secretos suelen duplicarse o reutilizarse en múltiples sistemas, lo que dificulta la corrección y la rotación si se ve comprometida una sola identidad.

Cómo proteger los NHI

El modelo zero trust, una técnica de seguridad preferida por muchas organizaciones, es difícil de aplicar a los escenarios de NHI. La confianza cero se basa en conceptos y controles como la autenticación continua, la verificación explícita y el acceso basado en el contexto. En el caso de las NHI, estos controles son más difíciles de implementar porque, en muchos casos, esas identidades no disponen de una sesión. Además, el estado del dispositivo es irrelevante; las señales de contexto, como la ubicación y el comportamiento, son más difíciles de definir y modelar; y los controles más recientes, como la MFA adaptativa, no suelen ser aplicables. Esto deja a las organizaciones con muchos menos mecanismos para controlar el acceso.

Para gestionar eficazmente la seguridad de las NHI, las organizaciones deben cambiar sus estrategias, utilizando un marco que gestione todo el ciclo de vida de las NHI, desde la creación hasta la supervisión y la retirada.

Establezca la clasificación y la propiedad de las NHI

Cree una taxonomía de NHI para toda la empresa, con categorías que incluyan cuentas de servicio, identidades de carga de trabajo, claves de API y tokens de aplicaciones y servicios. Cada identidad debe tener un propietario claro responsable de las aprobaciones de permisos, las políticas de rotación, las revisiones de uso y la eliminación o retirada.

Implemente los principios de privilegios mínimos para las NHI. Adopte las mejores prácticas nativas de la nube, como el uso de tokens de ámbito limitado con permisos mínimos, evitando los permisos comodín o los roles administrativos siempre que sea posible, utilizando roles de IAM en la nube en lugar de credenciales estáticas y aplicando la microsegmentación para limitar el alcance de los incidentes siempre que sea factible. En el caso de las cuentas de servicio, cambie de privilegios para todo el dominio a permisos específicos para cada tarea.

Centralice la gestión de secretos y credenciales

Sustituya las credenciales estáticas o codificadas de forma fija por:

• gestores de secretos, como AWS Secrets Manager, HashiCorp Vault o Azure Key Vault;
• intermediarios de credenciales;
• federación de identidades con tokens de corta duración; y
• flujos de trabajo de rotación automatizados.

Nunca almacene secretos en lugares como repositorios Git, registros de CI/CD, playbooks de Terraform o Ansible, o imágenes de contenedores. Las credenciales estáticas deben utilizarse como último recurso.

Si es posible, implemente la supervisión continua y el análisis de comportamiento para las NHI que comprenda los patrones de autenticación de servicio a servicio. Realice un seguimiento de la frecuencia de acceso a las NHI, las llamadas a la API y los picos de errores, y cree líneas de base de comportamiento para las cargas de trabajo y las cuentas de servicio. Las plataformas en la nube proporcionan registros, como AWS CloudTrail o los registros de inicio de sesión de Microsoft Entra ID, pero los equipos deben agregarlos e interpretarlos teniendo en cuenta el contexto de la organización.

Automatice, automatice, automatice

La gobernanza manual de identidades no es escalable. Utilice la automatización para realizar acciones comunes, como la aprobación automática de conjuntos de permisos de privilegios mínimos, la revocación automática de NHI no utilizados, la rotación automática de secretos según un calendario y la retirada de identidades cuando las cargas de trabajo se retiran. Los pipelines de CI/CD deben generar credenciales efímeras que desaparezcan con la carga de trabajo.

Trabaje hacia el modelo de confianza cero implementando lo siguiente:

• TLS mutuo entre servicios, malla de servicios o marcos de identidad de cargas de trabajo como SPIFFE/SPIRE.
• Verificación continua de la identidad en cada llamada a la API.
• Aplicación de políticas basada en el contexto de la identidad.

Estos controles ayudan a garantizar que la comunicación entre servicios esté autenticada, autorizada y sea auditable.

Pruebe la resiliencia y la respuesta a incidentes relacionados con los NHI

Realice ejercicios periódicos, como simulaciones de robo de tokens, pruebas de repetición de claves API y simulacros de compromiso de cargas de trabajo. Durante estos ejercicios, valide la visibilidad de los registros, determine el radio de impacto, pruebe la velocidad de revocación y rotación, y confirme si los sistemas posteriores detectan anomalías.

Las NHI ahora y en el futuro

A medida que las organizaciones aceleran la automatización, la comunicación entre máquinas, la adopción de la nube y la integración de la IA, la seguridad de los NHI cobrará mayor importancia. Este crecimiento conlleva una proliferación de credenciales, una propiedad poco clara, cuentas de servicio con privilegios excesivos, flujos de autenticación difíciles de supervisar y otros riesgos.

Los equipos de seguridad deben adaptar sus estrategias de gobernanza de identidades para abarcar esta nueva realidad. El futuro de la seguridad de identidades reside en la gestión automatizada del ciclo de vida, la aplicación del principio de privilegios mínimos, el análisis de comportamiento y una sólida gestión de credenciales adaptada a la naturaleza de las NHI, no a la de los seres humanos. Las organizaciones que adopten este cambio reforzarán su resiliencia, reducirán su superficie de ataque y estarán mucho mejor preparadas para un mundo en el que el trabajo lo realizan cada vez menos las personas y cada vez más los agentes digitales autónomos.

Dave Shackleford es fundador y consultor principal de Voodoo Security, además de analista, formador y autor de cursos de SANS, y director técnico de GIAC.