Identidades no humanas (NHIs) explicadas y cómo asegurarlas

La mayoría de las organizaciones no pueden producir un inventario completo de las identidades no humanas (NHIs) que se ejecutan en su entorno. Las cuentas de servicio, las claves API y las credenciales de aplicación se acumulan en Active Directory (AD) y en plataformas en la nube, a menudo sin una propiedad clara, un propósito documentado o un ciclo de revisión definido.

Esa brecha conlleva un riesgo real. Según el Informe sobre Tendencias de Ciberseguridad de Netwrix 2025, el 46% de las organizaciones experimentaron compromisos de cuentas el año pasado, frente al 16% en 2020. Las identidades máquina a máquina, como las cuentas de servicio y los tokens, son un factor creciente en esa tendencia, y la mayoría de los equipos de TI de medianas empresas no tienen la visibilidad para gestionarlas de manera efectiva.

¿Qué son las identidades no humanas en ciberseguridad y por qué son importantes?

Las identidades no humanas (NHIs) son credenciales digitales que permiten a máquinas, aplicaciones y procesos automatizados autenticar y acceder a recursos sin intervención humana. Las cuentas de servicio, las claves API, las identidades gestionadas, los tokens OAuth y los agentes de IA caen bajo el paraguas de NHI.

Sus números están creciendo rápidamente. Cada recurso en la nube, pipeline de CI/CD, flujo de trabajo de automatización e integración de IA crea nuevas NHIs que necesitan credenciales y permisos. En la mayoría de las organizaciones, las identidades de máquina superan en número a los usuarios humanos en un factor de 10:1 o más.

Cuando su software de respaldo se conecta a una base de datos a las 2 a.m., no escribe una contraseña. Se autentica utilizando una cuenta de servicio con credenciales almacenadas. Eso es un NHI. Lo mismo se aplica a la clave API que su sistema de tickets utiliza para extraer datos de CRM, o al token OAuth que sincroniza los registros de empleados con Entra ID.

Como señaló Jeff Warren, Director de Producto en Netwrix, en el Informe de Tendencias de Ciberseguridad 2025, es probable que los ataques impulsados por la identidad dominen aún más, con "el abuso de identidades de máquina a máquina como cuentas de servicio y tokens" entre los vectores emergentes.

Identidades humanas vs. identidades no humanas

Las identidades humanas y no humanas difieren en cómo se poseen, autentican, gestionan y monitorean:

• Propiedad: Las identidades humanas tienen propietarios claros. Las NHIs a menudo tienen una propiedad compartida o poco clara, lo que dificulta hacer cumplir la responsabilidad.
• Autenticación: Los humanos utilizan contraseñas combinadas con MFA. Los NHIs utilizan claves, tokens y certificados, y MFA no se aplica.
• Ciclo de vida: Las identidades humanas siguen procesos impulsados por recursos humanos (incorporación, cambios de rol, desvinculación). Las NHIs se crean ad hoc por desarrolladores y administradores, sin una gestión de ciclo de vida equivalente.
• Comportamiento: El acceso humano es interactivo y variable. El acceso NHI es programático y repetitivo, lo que hace que la detección de anomalías sea más fácil de establecer como base y más difícil de revisar a gran escala.

Las políticas de contraseñas, MFA, SSO y las revisiones de acceso no se traducen bien a las identidades de máquina. Por eso, las identidades de máquina requieren su propio enfoque de gobernanza.

El término relacionado “identidad de máquina” se refiere específicamente a identidades a nivel de infraestructura como servidores, VMs y certificados. NHI es más amplio, abarcando esos más credenciales a nivel de aplicación como claves API, tokens y bots.

Métodos de autenticación de identidad no humana

Los NHIs se autentican programáticamente en lugar de a través de un inicio de sesión interactivo, utilizando cuatro métodos principales:

• Basado en token: claves API, tokens portadores y tokens JWT
• Basado en clave: claves SSH y claves de cuentas de servicio
• Basado en certificados: Certificados X.509 y TLS mutuo (mTLS)
• Federación de identidad de carga de trabajo: Mecanismos nativos de la nube como roles de AWS IAM, identidades administradas de Azure y cuentas de servicio de GCP

El riesgo crítico en los cuatro es que MFA y SSO no se aplican. Cuando una credencial se ve comprometida, no hay un segundo factor para prevenir la explotación, y el atacante hereda cualquier acceso que tenga esa identidad.

Tipos comunes de identidades no humanas

Entender los diferentes tipos de NHIs en su entorno es el primer paso para gestionarlos de manera efectiva. Las siguientes categorías representan las identidades no humanas más comunes que encontrará en entornos locales y en la nube.

1. Cuentas de servicio e identidades de aplicación

Las cuentas de servicio son cuentas especializadas que permiten a las aplicaciones realizar tareas sin credenciales humanas. Su software de copia de seguridad utiliza una para acceder a bases de datos de SQL Server, y sus herramientas de monitoreo las utilizan para recopilar datos de rendimiento. En entornos de AD, estas se identifican por el atributo ServicePrincipalName (SPN).

El desafío de seguridad principal es que las contraseñas rara vez cambian. La mejor práctica moderna es migrar a Cuentas de Servicio Administradas por Grupo (gMSAs), que proporcionan gestión automática de contraseñas a través de Active Directory y eliminan la intervención manual del administrador.

Las identidades de las aplicaciones amplían este concepto a entornos nativos de la nube, donde las plataformas en la nube asignan identidades dedicadas a las aplicaciones para acceder a APIs, bases de datos y otros recursos en la nube.

2. Claves API y secretos

Las claves API y los secretos cumplen la misma función básica: permiten que un sistema se autentique con otro sin la intervención de un humano. Están integrados en herramientas internas, integraciones de SaaS y conexiones de servicios de terceros para otorgar acceso programático sin requerir que alguien inicie sesión.

Esa categoría de terceros es más amplia de lo que la mayoría de los equipos se da cuenta. Cuando una impresora se comunica con su fabricante para el monitoreo de suministros, o cuando el equipo de fabricación envía telemetría a un OEM para mantenimiento remoto, esas conexiones dependen de claves API o credenciales incrustadas que autentican a través de límites organizacionales. Estos NHIs gestionados por el proveedor a menudo caen fuera de la gobernanza de identidad estándar porque son provisionados por el proveedor, no por su equipo de TI.

El desafío en todos estos es su naturaleza estática. A diferencia de las contraseñas vinculadas a cuentas de usuario, las claves API no caducan por defecto en la mayoría de los sistemas y tienden a terminar en archivos de configuración, repositorios de código, variables de entorno e incluso registros de chat.

Lo mismo ocurre con los secretos almacenados en bóvedas o archivos de configuración, incluidos contraseñas, cadenas de conexión y claves de cifrado. Estas credenciales conllevan el mismo riesgo de acceso que cualquier clave de API, pero a menudo reciben menos escrutinio.

Una vez filtradas, cualquiera de estas credenciales es inmediatamente explotable, y las organizaciones a menudo no saben que una ha sido expuesta hasta que ya ha sido utilizada. Cuando la credencial comprometida pertenece a una integración de terceros, el radio de explosión se extiende más allá de su entorno hacia relaciones con proveedores gobernadas por marcos como NIS2 y DORA, ambos de los cuales exigen controles de riesgo de la cadena de suministro para las dependencias de servicios digitales.

3. Identidades gestionadas

Las identidades administradas representan el enfoque moderno de Microsoft para la autenticación NHI en Azure. Las identidades administradas asignadas por el sistema se vinculan directamente a recursos específicos de Azure y eliminan la necesidad de almacenar credenciales por completo. Las identidades administradas asignadas por el usuario se pueden compartir entre múltiples recursos.

Sin embargo, las identidades administradas solo resuelven el problema dentro del ecosistema de Azure. Las organizaciones que ejecutan entornos híbridos aún necesitan visibilidad sobre las cuentas de servicio locales y las credenciales multiplataforma que las identidades administradas no cubren.

4. Tokens de OAuth

Tokens de OAuth habilitan el acceso delegado entre aplicaciones. Cuando tu plataforma de recursos humanos sincroniza los datos de los empleados con tu proveedor de identidad, o tu herramienta de informes extrae registros de un CRM SaaS, esas conexiones dependen de los tokens de actualización de OAuth para mantener el acceso persistente.

Estos tokens a menudo tienen una vida útil más larga de lo previsto y se acumulan en sus integraciones de SaaS a medida que los equipos conectan más herramientas.

5. Identidades de carga de trabajo en la nube y contenedores

Las identidades de carga de trabajo abarcan las credenciales asignadas a aplicaciones en contenedores, funciones sin servidor y cargas de trabajo en la nube. Sus implementaciones de Kubernetes, Azure Container Instances y funciones de AWS Lambda requieren credenciales para acceder a otros servicios.

Las plataformas en la nube asignan identidades a estas cargas de trabajo, incluyendo VMs, contenedores, funciones sin servidor y pods de Kubernetes, para acceder a recursos en la nube, almacenamiento y APIs. Estas identidades de carga de trabajo se crean y destruyen rápidamente, a menudo superando la capacidad de los equipos de seguridad para rastrearlas.

6. Identidades de máquinas y dispositivos

Las máquinas físicas y virtuales, los dispositivos IoT y los componentes de infraestructura tienen sus propias identidades. Los certificados autentican frecuentemente estas identidades de máquina, creando una capa de gobernanza de NHI que se superpone pero se extiende más allá de las credenciales a nivel de aplicación. A medida que la adopción de IoT crece, también lo hace esta población de identidades.

7. Bots y agentes de IA

Los bots y agentes de IA representan la categoría más nueva y de más rápido crecimiento de identidades no humanas. Por ejemplo:

• Microsoft Copilot necesita acceso a tus archivos y correos electrónicos para ser útil
• Los bots de automatización de procesos robóticos (RPA) necesitan credenciales para interactuar con aplicaciones empresariales
• Los bots de CI/CD necesitan acceso para desplegar código
• Las herramientas de orquestación y los agentes de IA operan como identidades no humanas, a menudo con acceso amplio para habilitar flujos de trabajo de automatización

Cada uno de estos crea relaciones de identidad que requieren la misma gobernanza que cualquier otro NHI, pero a menudo son provisionados rápidamente por equipos de negocio sin revisión de seguridad.

El riesgo añadido es que las herramientas de IA interactúan con repositorios de código y entornos de desarrollo. Esto puede exponer inadvertidamente credenciales en mensajes, salidas y registros, creando vectores de fuga que el escaneo de secretos tradicional no siempre detecta.

Cada uno de estos tipos de identidad requiere diferentes enfoques de gestión, pero todos comparten desafíos comunes de gobernanza: seguimiento de la propiedad, rotación de credenciales y desactivación cuando ya no se necesiten.

Cómo descubrir identidades no humanas en su entorno

Antes de que puedas gobernar los NHI, necesitas encontrarlos. Un proceso de descubrimiento estructurado te ayuda a entender el alcance del problema, pero la mayoría de las organizaciones se da cuenta rápidamente de que los enfoques manuales solo rascan la superficie.

Comienza con tu proveedor de identidad

Consulta Active Directory para cuentas con Nombres de Principales de Servicio, cuentas de servicio gestionadas independientes y cuentas de servicio gestionadas por grupos.

Para entornos en la nube, obtén un inventario de los principales servicios, registros de aplicaciones e identidades gestionadas desde la consola de administración de tu proveedor de identidad. Concéntrate en cuatro atributos para cada identidad: qué aplicación la utiliza, qué credenciales posee, qué recursos puede acceder y quién la posee.

Expande a tu capa de código y automatización

Trabaja con tu equipo de DevOps para identificar credenciales almacenadas en configuraciones de canalizaciones CI/CD, plantillas de infraestructura como código y variables de entorno. Las herramientas de escaneo de repositorios pueden señalar credenciales codificadas y claves API comprometidas en el control de versiones. A menudo, aquí es donde viven los NHIs más no rastreados.

Audita tus integraciones SaaS

Revise las concesiones de OAuth y las conexiones API en sus aplicaciones SaaS. Muchas organizaciones descubren docenas de tokens de OAuth activos de integraciones que se configuraron hace meses o años por personas que desde entonces han dejado el equipo o la empresa.

Documenta lo que encuentres

Por cada NHI que descubras, registra al propietario (una persona, no un equipo), la justificación comercial, el tipo de credencial y el estado de rotación, y la última vez que alguien validó que aún se necesita. Este inventario se convierte en la base para todo lo que sigue.

Una advertencia importante: el descubrimiento manual te da una instantánea en un momento dado, no un inventario vivo. Los entornos cambian a diario, y una exportación trimestral no capturará la cuenta de servicio que alguien creó el martes pasado.

El descubrimiento continuo y automatizado es lo que separa a las organizaciones que conocen su población NHI de aquellas que solo piensan que lo hacen.

Cómo asegurar y gobernar identidades no humanas

La gestión de identidades no humanas (NHIM) es la práctica de descubrir, gobernar y asegurar identidades de máquinas que la gestión de identidades tradicional (IAM) y el Privileged Access Management (PAM) no estaban diseñados para manejar.

Eso significa gobernar el acceso sin un actor humano, gestionar credenciales que no pueden usar MFA y rastrear la propiedad de identidades creadas por desarrolladores y automatización en lugar de procesos de recursos humanos.

Una vez que hayas identificado lo que existe en tu entorno, la gobernanza asegura que se mantenga bajo control. La seguridad efectiva de NHI trata las identidades de las máquinas como ciudadanos de primera clase en tu programa de seguridad de identidad, con políticas definidas para cada etapa de su ciclo de vida.

Así es como se ve en la práctica:

• Asigne un propietario a cada NHI al momento de la creación: No debe existir ninguna identidad sin un individuo nombrado (no una lista de distribución, no un alias de equipo) responsable de su acceso y ciclo de vida. Haga que la propiedad sea un campo obligatorio en su proceso de aprovisionamiento.
• Aplica el principio de menor privilegio desde el primer día: Otorga solo los permisos específicos que cada NHI necesita para su función, limitados al nivel de recurso más estrecho posible. Evita permisos a nivel de suscripción o de dominio para cuentas de servicio que solo necesitan acceso a una sola aplicación.
• Automatiza la rotación de credenciales siempre que sea posible: gMSAs manejan esto automáticamente para cargas de trabajo de AD locales. Para principales de servicio en la nube y claves API, incorpora la rotación en tus tuberías de implementación o utiliza una solución de gestión de secretos.

La cadencia correcta depende del tipo de credencial y del riesgo de exposición, ya que marcos importantes como NIST, CIS, y PCI DSS no exigen un período de rotación universal para las cuentas privilegiadas.

• Monitorear anomalías de comportamiento: Una cuenta de servicio que de repente accede a recursos fuera de su patrón normal, o una clave API que se autentica desde una ubicación desconocida, debería activar una alerta. Enfoque el monitoreo en la desviación de las líneas base establecidas en lugar de intentar revisar cada evento.
• Descomisionar agresivamente: Los NHIs obsoletos son una de las debilidades más explotables en cualquier entorno. Incorpora desencadenantes de descomisión en tu proceso: si una identidad no se ha autenticado en 90 días, márcala para revisión. Si el propietario no puede justificarlo, desactívala. Si nadie lo nota durante 30 días más, elimínala.
• Certificar el acceso en un horario recurrente: Requerir que los propietarios de NHI vuelvan a validar que cada identidad aún necesita sus permisos actuales. Las revisiones anuales son un punto de partida, pero trimestrales son mejores para identidades privilegiadas.

Estos controles se mapean directamente a los requisitos ya incorporados en los principales marcos de cumplimiento:

• El Nivel 2 de CMMC requiere control de acceso y gestión de cuentas para todas las identidades, incluidas las no humanas
• Los criterios de servicio de confianza SOC 2 requieren controles de acceso que se extiendan a identidades no humanas
• HIPAA exige registros de auditoría para todo acceso a Información de Salud Protegida, incluido el acceso por procesos automatizados y cuentas de servicio
• NIS2 (UE) requiere que las organizaciones gestionen los riesgos de la cadena de suministro de TIC, incluidas las credenciales de servicios de terceros y las identidades gestionadas por proveedores que acceden a su entorno
• DORA (sector financiero de la UE) exige la gestión de riesgos de terceros en TIC con requisitos específicos para monitorear y gobernar las dependencias de servicios digitales, incluidas las identidades de máquina que esos servicios utilizan

Si estás construyendo la gobernanza de NHI, al mismo tiempo estás construyendo evidencia de cumplimiento.

Cómo Netwrix apoya la seguridad de identidades no humanas

Cada práctica de gobernanza mencionada anteriormente depende de una cosa: saber qué identidades no humanas existen en su entorno y qué están haciendo. Esa es la brecha que la mayoría de las organizaciones luchan por cerrar por su cuenta, y es donde Netwrix encaja.

La plataforma Netwrix 1Secure proporciona visibilidad continua sobre la postura de identidad en Active Directory y entornos en la nube. Para identidades no humanas específicamente, muestra cuentas inactivas, cuentas obsoletas y configuraciones de acceso excesivamente permisivas que violan la política organizacional, brindando a los equipos de seguridad una imagen del estado actual en lugar de una instantánea trimestral.

Donde las consultas manuales te dan una exportación en un momento dado, 1Secure mantiene una vista continua a medida que se crean nuevas identidades y las existentes cambian.

Para Active Directory específicamente, Netwrix Auditor rastrea los cambios en las cuentas de servicio, monitorea los eventos de autenticación y audita las modificaciones de la Política de Grupo, llenando los vacíos de visibilidad que las herramientas nativas dejan abiertos.

Cuando alguien crea una nueva cuenta de servicio, cambia su membresía de grupo o intenta un inicio de sesión interactivo, Auditor lo señala. Los equipos pueden comenzar a responder preguntas de auditoría sobre la actividad de NHI con informes legibles por humanos que se mapean directamente a marcos de cumplimiento como HIPAA, SOC 2, y CMMC.

Para identidades no humanas privilegiadas que requieren acceso elevado, Netwrix Privilege Secure elimina privilegios permanentes a través de la provisión justo a tiempo con grabación completa de sesiones para auditorías. En lugar de que las cuentas de servicio mantengan acceso administrativo persistente las 24 horas, Privilege Secure otorga permisos elevados solo cuando se necesitan y los revoca automáticamente cuando la tarea está completa.

¿Listo para cerrar la brecha de visibilidad en identidades no humanas?Reserva una demostración para ver cómo Netwrix funciona en tu entorno.