Escuchamos esto a menudo:
«Tenemos cientos de cuentas de servicio y agentes de IA ejecutándose en segundo plano. No creamos la mayoría de ellas. No sabemos a quién pertenecen. ¿Cómo vamos a protegerlos?»
Hoy en día, todas las empresas funcionan con más que usuarios. Entre bastidores, miles de identidades no humanas, desde cuentas de servicio hasta tokens de API y agentes de inteligencia artificial, acceden a los sistemas, transfieren datos y ejecutan tareas las 24 horas del día.
No son nuevas. Pero se están multiplicando rápidamente. Y la mayoría no se crearon pensando en la seguridad.
Las herramientas de identidad tradicionales asumen la intención, el contexto y la propiedad. Las identidades no humanas no tienen nada de eso. No inician ni cierran sesión. No se bajan del barco. Y con el auge de los agentes autónomos, están empezando a tomar sus propias decisiones, a menudo con amplios permisos y poca supervisión.
Ya está creando nuevos puntos ciegos. Pero solo estamos al principio.
En esta publicación, analizaremos cómo está evolucionando el riesgo de identidad no humana, dónde la mayoría de las organizaciones siguen expuestas y cómo un tejido de seguridad de identidad ayuda a los equipos de seguridad a avanzar antes de que la escala se vuelva inmanejable.
El auge (y el riesgo) de las identidades no humanas
Las arquitecturas que dan prioridad a la nube aumentaron la complejidad de la infraestructura y provocaron un aumento de las identidades en segundo plano. A medida que estos entornos crecen, la cantidad de identidades en segundo plano aumenta con ellos, muchas de las cuales se crean automáticamente, sin una propiedad ni supervisión claras. En muchos casos, estas identidades superan en número a los usuarios humanos por más de 80 a 1 .
Lo que lo hace especialmente arriesgado es lo poco que la mayoría de los equipos saben sobre ellos. Los NHIs suelen crearse automáticamente durante el despliegue o el aprovisionamiento, y luego desaparecen del radar, no son rastreados, no tienen dueño y, a menudo, tienen permisos excesivos.
Las cuentas de servicio, en particular, están en todas partes. Mueven datos entre sistemas, ejecutan trabajos programados y autentican los servicios independientes. Sin embargo, su expansión rara vez es visible y sus permisos rara vez se revisan. Con el tiempo, se convierten en vehículos perfectos para el movimiento lateral y la escalada de privilegios.
Sin embargo, las cuentas de servicio son solo una parte del panorama. A medida que crece la adopción de la IA, una nueva categoría de identidad no humana presenta un riesgo aún más impredecible.
Por qué los agentes de IA se comportan de manera diferente y por qué es importante
A diferencia de la mayoría de las identidades de máquinas, los agentes de IA inician acciones por sí mismos: interactúan con las API, consultan datos y toman decisiones de forma autónoma.
Esa autonomía tiene un coste. Los agentes de inteligencia artificial suelen necesitar acceder a datos confidenciales y API, pero pocas organizaciones tienen barreras que les impidan lo que pueden hacer o cómo revocar ese acceso.
Peor aún, la mayoría de los agentes de IA carecen de una propiedad clara, no siguen un ciclo de vida estándar y ofrecen poca visibilidad de su comportamiento en el mundo real. Los desarrolladores pueden implementarlos, integrarlos en las herramientas o llamarlos a través de API externas. Una vez activas, pueden ejecutarse indefinidamente, a menudo con credenciales persistentes y permisos elevados.
Además, dado que no están vinculados a un usuario o a una sesión, los agentes de IA son difíciles de supervisar mediante señales de identidad tradicionales, como la IP, la ubicación o el contexto del dispositivo.
El costo del acceso invisible
Los secretos se codifican. Los tokens se reutilizan. Las identidades huérfanas permanecen activas durante meses, a veces años.
Estos riesgos no son nuevos, pero las credenciales estáticas y el acceso abierto pueden haber sido manejables cuando tenía unas pocas docenas de cuentas de servicio. Sin embargo, dado que miles o decenas de miles de NHIs funcionan de forma independiente en los servicios en la nube, el seguimiento manual simplemente no es escalable.
Por eso, muchos equipos de seguridad están revisando la forma en que definen la identidad en primer lugar. Porque si un agente de IA puede autenticarse, acceder a los datos y tomar decisiones, es una identidad. Y si esa identidad no está gobernada, es una responsabilidad.
Desafíos comunes de seguridad de NHI
Entender que las identidades no humanas representan un riesgo creciente es una cosa; gestionar ese riesgo es otra. El problema principal es que las herramientas y los procesos creados para la gestión de la identidad humana no se traducen en el mundo de las API, las cuentas de servicio y los agentes de inteligencia artificial. Esta desconexión crea varios desafíos de seguridad distintos y peligrosos a los que muchas organizaciones apenas están empezando a enfrentarse.
No puedes proteger lo que no puedes ver
El desafío más fundamental para proteger los NHIs es la visibilidad. La mayoría de los equipos de seguridad no tienen un inventario completo de todas las identidades no humanas que operan en su entorno. Con frecuencia, los desarrolladores o los sistemas automatizados crean estas identidades de forma dinámica para cumplir una función temporal específica. Se configuran para admitir un nuevo microservicio, ejecutar un script de implementación o integrar una aplicación de terceros.
Sin embargo, una vez creadas, rara vez se documentan o rastrean en un sistema central de administración de identidades. Se convierten en identidades «ocultas», activas y funcionales, pero completamente invisibles para la seguridad y la TI. Sin una visión integral de qué NHIs existen, quién (o qué) las creó y a qué acceden, es imposible crear una estrategia de seguridad significativa. Lo único que tienes que hacer es intentar proteger una superficie de ataque de un tamaño desconocido.
Por qué «configúralo y olvídate» es un pasivo de seguridad
Una práctica habitual para los desarrolladores y los equipos de operaciones es asignar amplios permisos a las NHIs para garantizar que un servicio o una aplicación funcionen sin interrupciones. Piense en ello como instalar una aplicación que solicita el acceso al álbum de la cámara, al micrófono y a la ubicación. Tocas «Permitir» solo para que funcione y luego te olvidas de ello.
Por el momento, es más rápido y práctico, pero presenta riesgos innecesarios. Del mismo modo, asignar permisos demasiado amplios a los NHIs puede facilitar la configuración, pero crea importantes brechas de seguridad y deja los sistemas vulnerables a la explotación.
El principio del mínimo privilegio a menudo se sacrifica en aras de la rapidez y la comodidad. Es posible que un NHI solo necesite leer los datos de una tabla de base de datos, pero se le concede acceso de escritura a toda la base de datos para evitar futuros errores relacionados con los permisos.
Este enfoque crea una enorme responsabilidad de seguridad. Estas identidades con permisos excesivos se convierten en objetivos de gran valor para los atacantes. Si un agente de amenazas pone en peligro a un NHI con privilegios excesivos, puede moverse lateralmente entre los sistemas, ampliar su acceso y filtrar datos confidenciales sin necesidad de contar con las credenciales de un usuario humano.
Debido a la poca frecuencia con la que se revisan o se desaprovisionan los NHIs, estas cuentas permisivas pueden permanecer activas y vulnerables durante meses o incluso años, a la espera de ser explotadas.
Sin contexto, sin controles modernos
La seguridad de identidad moderna se basa en el contexto. Cuando un usuario inicia sesión, podemos verificar su identidad mediante señales como su ubicación, dispositivo y red, y a menudo solicitamos la autenticación multifactor (MFA) si algo parece inusual. Los suyos no tienen nada de este contexto. Son solo código que se ejecuta en un servidor. No tienen un dispositivo, una ubicación geográfica ni patrones de comportamiento que puedan monitorearse fácilmente.
Como se autentican con credenciales estáticas de larga duración, la MFA no se aplica. Esto significa que si se roba una credencial, no hay un segundo factor que impida que un atacante la utilice. La ausencia de controles de acceso que tengan en cuenta el contexto hace que sea increíblemente difícil distinguir entre la actividad legítima y la maliciosa del NHI hasta que ya es demasiado tarde.
Identidades huérfanas y fantasmas digitales
¿Qué ocurre cuando el desarrollador que creó una cuenta de servicio deja la empresa? ¿O cuando se retira una aplicación que utilizaba un token de API específico? En la mayoría de las organizaciones, los NHIs asociados se quedan atrás. Estas identidades «huérfanas» o «persistentes» permanecen activas, con sus permisos intactos, pero sin que ningún propietario sea responsable de su ciclo de vida.
Estos fantasmas digitales son una pesadilla para el cumplimiento y un riesgo para la seguridad. Abarrotan el entorno y dificultan la identificación de las identidades legítimas y activas. Y lo que es más importante, representan un punto de entrada abandonado y sin supervisión a sus sistemas. Un atacante que descubre una identidad huérfana con credenciales válidas ha encontrado una puerta trasera perfecta, una puerta trasera que nadie está vigilando.
Cómo están recuperando el control los equipos de seguridad
Ante una superficie de ataque que se expande y se hace más autónoma, los principales equipos de seguridad están pasando de las soluciones reactivas a la gobernanza proactiva. Ese cambio comienza con el reconocimiento de cada sistema, script y agente acreditados como una identidad que vale la pena controlar.
Descubra e inventarie todos los NHIs
Las plataformas de identidad modernas pueden escanear entornos como AWS, GCP y la infraestructura local para descubrir los tokens ocultos, las cuentas de servicio no administradas y las funciones con permisos excesivos.
Estas herramientas sustituyen las hojas de cálculo y las conjeturas por un inventario unificado en tiempo real de identidades humanas y no humanas. Sin esta base, la gobernanza es solo una conjetura. Gracias a él, los equipos de seguridad pueden por fin pasar de jugar a la porquería con las cuentas de servicio a tener un control real.
Clasifique y aborde primero las identidades de alto riesgo
Con un inventario completo, el siguiente paso es reducir el radio potencial de explosión. No todos los NHIs presentan el mismo nivel de riesgo. La clave es priorizar la remediación en función de los permisos y el acceso. La administración de privilegios basada en el riesgo ayuda a identificar qué identidades están peligrosamente sobreautorizadas.
A partir de ahí, los equipos pueden ajustar sistemáticamente el tamaño del acceso para alinearlo con el principio del mínimo privilegio. Esto también implica implementar controles más estrictos, como la rotación automatizada de secretos y credenciales. En el caso de los NHIs más potentes, como los agentes de IA autónomos, es fundamental disponer de «interruptores de desconexión automática» que permitan la finalización inmediata de la sesión si se detecta un comportamiento anómalo.
Automatice la gobernanza y el ciclo de
Las identidades humanas tienen políticas de ciclo de vida: incorporación, cambios de rol, desincorporación. Las identidades no humanas necesitan el mismo rigor.
Las organizaciones líderes están automatizando estos procesos de principio a fin. Cuando se crea un nuevo NHI, se le asigna un propietario, se le otorgan permisos específicos y se agrega a un inventario auditable. Cuando se retira una herramienta o un desarrollador se marcha, las identidades asociadas se desaprovisionan automáticamente, lo que cierra la puerta a las cuentas huérfanas y garantiza que el acceso no se prolongue indefinidamente.
Por qué un tejido de seguridad de identidad cambia la ecuación
Muchos de los riesgos relacionados con las identidades no humanas tienen menos que ver con las identidades en sí mismas y más con los sistemas fragmentados que intentan gestionarlas.
Cada proveedor de nube, herramienta de CI/CD y plataforma de IA maneja la identidad de manera diferente. Algunas utilizan fichas estáticas. Algunos emiten credenciales durante la implementación. Algunas no caducan en absoluto el acceso. Sin un sistema compartido para definir la propiedad, asignar permisos y hacer cumplir las barreras, la expansión crece sin control.
Un tejido de seguridad de identidad unificado cambia esta situación al consolidar todas las identidades, humanas y no humanas, en un único plano de control. Y con Okta, eso significa:
- Detecte automáticamente las brechas de identidad y postura con Identity Security Posture Management (ISPM)
- Aplicar el acceso con privilegios mínimos con rotación y almacenamiento en bóveda para secretos confidenciales
- Definir políticas de ciclo de vida para cada identidad, incluidos los agentes y las cuentas de servicio
- Ampliación de los patrones de identidad de la carga de trabajo (tokens de corta duración, credenciales de cliente) y acceso adaptativo a los servicios y trabajos en segundo plano
- Regula el acceso a los servicios de AWS, como Bedrock y Amazon Q, mientras que AWS IAM emite y aplica las credenciales subyacentes del agente o la carga de trabajo
En lugar de combinar soluciones alternativas, los equipos pueden definir los controles de identidad una vez y aplicarlos en todas partes. Esto significa menos puntos ciegos, tiempos de respuesta más rápidos y una superficie de ataque más pequeña, sin necesidad de diez herramientas diferentes para lograrlo.
No dejes que el suyo se convierta en tu mayor punto ciego
Los agentes de IA y las identidades no humanas ya están remodelando tu superficie de ataque. Se están multiplicando más rápido de lo que la mayoría de los equipos pueden rastrear y son demasiados los que siguen operando sin una propiedad clara, sin controles estrictos ni una visibilidad real.
No necesitas reconstruir tu estrategia desde cero. Pero tú hacer necesitan tratar las identidades no humanas como lo que son: puntos de acceso críticos que merecen la misma gobernanza que cualquier usuario.
Con una plataforma de identidad unificada, los equipos de seguridad pueden hacer un inventario de lo que se está ejecutando, aplicar controles escalables y cortar el acceso riesgoso antes de que se explote, no después.
Descubra cómo Okta y AWS ayudan a las organizaciones a poner orden en la expansión del NHI. [ Descargar la guía ] para empezar.