Los 10 principales riesgos de identidad no humana

Imagina que un atacante quisiera acceder a tus sistemas mañana. ¿Se molestaría en intentar engañar a uno de tus empleados con phishing? Probablemente no. La opción más sencilla es robar una clave que tu software haya dejado por ahí. Sin contraseña que descifrar ni solicitud de autenticación multifactor, simplemente encuentra una credencial y accede.

Estas credenciales pertenecen principalmente a una identidad no humana (NHI) . Se trata de programas informáticos que inician sesión en lugar de personas: una aplicación que se comunica con una base de datos, un script que llama a una API, un flujo de trabajo que ejecuta código, un agente de IA que realiza tareas. En lugar de una contraseña, cada uno de ellos contiene un secreto, como una clave API, un token o un certificado, y ese secreto es lo que prueba su identidad.

En entornos empresariales, un informe revela que las identidades no humanas superan en número a las personas en una proporción de aproximadamente 144 a 1, y la mayoría se crearon apresuradamente y luego se olvidaron. Por lo tanto, la verdadera pregunta no es si existe riesgo de identidad no humana, porque de hecho ya existe. La cuestión es qué riesgos abordar primero.

Estas cifras no surgieron por casualidad, y vale la pena comprender cómo crecieron. La nube dividió las grandes aplicaciones en numerosos servicios pequeños, cada uno de los cuales necesita una identidad; la automatización ahora crea credenciales por sí sola, y los agentes de IA son el tipo más reciente, creando accesos más rápido de lo que nadie puede rastrear. Las máquinas ahora se multiplican a la velocidad del software, mientras que nosotros todavía las gestionamos a la velocidad humana, y es precisamente en esa discrepancia donde radica el riesgo de la identidad no humana.

Un análisis más detallado de cada riesgo

Estos riesgos son bien conocidos en el sector. OWASP enumera los diez más importantes en su informe "Non-Human Identities Top 10 2025", y los analizaremos todos en el mismo orden. Cada sección explica el riesgo y cómo abordarlo.

Desvinculación inadecuada

Un NHI huérfano es aquel que aún existe, pero que ya no es necesario. Un proyecto finaliza, un servicio se retira o la persona que lo creó se va, y la credencial sigue funcionando sin que nadie la supervise. Esto es más común de lo que se piensa: una investigación reveló que el 91 % de los tokens de exempleados seguían activos.

Los atacantes se dirigen a estas identidades precisamente porque nadie las supervisa. La solución consiste en automatizar el apagado, de modo que al desactivar un servicio también se desactiven sus identidades. Asigne un propietario a cada NHI y realice una limpieza periódica para desactivar todo lo que ya no esté en funcionamiento.

Fuga secreta

Se produce una filtración de información confidencial cuando un token, clave o certificado termina en un lugar donde no debería; el ejemplo clásico es cuando se inserta directamente en el código fuente. También puede colarse en archivos de configuración, registros de eventos y, ocasionalmente, en mensajes de chat o tickets de soporte. Un estudio realizado en entornos reales reveló que el 44 % de los tokens se encontraban expuestos en lugares como confirmaciones de código, tickets y herramientas de chat.

Lo más preocupante es que no se necesita ninguna vulnerabilidad. Cualquiera que encuentre el secreto puede usarlo sin problemas. Esto ha afectado a empresas de renombre, no solo a equipos pequeños. Por lo tanto, mantenga los secretos completamente fuera del código y guárdelos en una bóveda o gestor de secretos. Analice sus repositorios y registros en busca de cualquier elemento expuesto y rote lo que pueda haber sido visto. Mejor aún, elimine por completo el secreto de larga duración, tema que abordamos en la sección «Secretos de larga duración» más adelante.

Información sanitaria de terceros vulnerable

El desarrollo moderno se basa en herramientas externas: aplicaciones SaaS, extensiones de IDE e integraciones. Cada herramienta suele tener su propia interfaz de seguridad de red (NHI) con acceso a tus sistemas. Esto resulta práctico, pero también significa que una vulnerabilidad en el software de otra persona puede convertirse silenciosamente en tu problema. Si una herramienta de terceros es pirateada o lanza una actualización defectuosa, los atacantes pueden acceder a tu entorno de inmediato. Así es como comienzan muchos ataques a la cadena de suministro .

No puedes arreglar el código de otra persona, pero puedes limitar los daños. Mantén una lista de todas las integraciones de terceros, verifica el alcance de cada una, limita los permisos al mínimo y elimina las que ya no uses.

Autenticación insegura

Cada NHI debe autenticarse ante el servicio al que se conecta antes de obtener acceso. Muchas aplicaciones aún dependen de mecanismos débiles u obsoletos para esto, como protocolos heredados o claves compartidas estáticas que son fáciles de interceptar. Cuando el mecanismo de autenticación es débil, un atacante puede suplantar la identidad o escalar sus privilegios sin ser detectado.

La solución consiste en abandonar los métodos antiguos y utilizar métodos robustos basados ​​en estándares. Cuando se configuran correctamente, OAuth, TLS mutuo y las identidades basadas en certificados de corta duración son mucho más seguras que una contraseña compartida obsoleta que nunca cambia.

NHI (Sistema Nacional de Salud) para personas con mayores privilegios

Este caso se da prácticamente en todas partes. Un sistema nacional de salud (SNS) con privilegios excesivos simplemente tiene más acceso del que necesita. Es tan común que un estudio reveló que el 97 % de los SNS gozan de privilegios excesivos. Esto tiene una razón de ser: otorgar un acceso amplio es la forma más rápida de que algo funcione, y nadie vuelve a limitarlo después.

Esto es crucial porque determina la gravedad de una brecha de seguridad. Si un atacante roba una identidad con permisos limitados, el daño es mínimo. Si roba una identidad con permisos excesivos, el atacante hereda todo ese alcance adicional, y un pequeño error se convierte en un incidente grave. Aplique el principio del mínimo privilegio otorgando a cada NHI solo el acceso necesario y audite esos permisos periódicamente para eliminar lo que ya no se utilice.

Configuraciones de implementación en la nube inseguras

Las canalizaciones de CI/CD requieren acceso al entorno de la nube para compilar, probar e implementar código automáticamente. El riesgo surge cuando dicho acceso se configura con credenciales estáticas, que pueden filtrarse a través de repositorios, registros de compilación o archivos de configuración. Una credencial de canalización comprometida tiene graves consecuencias, ya que otorga a un atacante acceso privilegiado y permanente directamente a producción.

La mejor opción es prescindir de las credenciales estáticas y usar OpenID Connect (OIDC). Con OIDC, la canalización utiliza su identidad verificada para obtener un token de corta duración, por lo que no hay ningún secreto permanente que pueda ser robado. Valide cuidadosamente las declaraciones del token, asegurándose de que solo las cargas de trabajo previstas puedan acceder a él.

Secretos que perduran

Un secreto de larga duración es una credencial que rara vez caduca. Los equipos recurren a este tipo de credenciales porque rotarlas manualmente es complicado, así que establecen una clave una sola vez y listo. El problema surge cuando una de ellas es robada. Dado que la credencial nunca caduca, el atacante puede seguir usándola indefinidamente. Una clave filtrada hace dos años puede seguir siendo válida y vulnerable hoy en día.

La solución consiste en que las claves secretas tengan una vida útil corta. En lugar de una clave estática, se deben distribuir credenciales que se generen bajo demanda y caduquen en minutos u horas. Los gestores del ciclo de vida de certificados y claves lo hacen automáticamente, y los certificados de corta duración cumplen la misma función para las conexiones entre máquinas. Cuanto menor sea la vida útil, menor será el margen de oportunidad para un atacante.

Aislamiento ambiental

Se recomienda mantener separados los entornos de desarrollo, pruebas y producción. Este riesgo surge cuando se reutiliza la misma identidad en diferentes entornos, especialmente entre pruebas y producción. Los entornos de pruebas suelen ser los menos protegidos, por lo que, al compartir una identidad con producción, una vulnerabilidad en el entorno de pruebas, más débil, puede extenderse directamente a producción.

Garantiza una estricta separación entre entornos. Crea identidades y claves secretas independientes para desarrollo, pruebas y producción, y almacénalas por separado. No compartas credenciales entre entornos, de modo que una credencial de prueba nunca pueda acceder al entorno de producción.

Reutilización de NHI

La reutilización de NHI se produce cuando la misma identidad o secreto se comparte entre diferentes aplicaciones, servicios o componentes, a menudo porque crear una identidad independiente para cada carga de trabajo requiere esfuerzo. Esta comodidad conlleva riesgos. Si esa identidad se ve comprometida en un solo lugar, un atacante puede usar las mismas credenciales para acceder a todos los demás sistemas que dependen de ella, por lo que una pequeña brecha se convierte rápidamente en una brecha de gran alcance.

Asigne a cada carga de trabajo su propia identidad y clave secreta, de modo que cualquier vulneración se limite a un solo servicio. Controle qué identidad pertenece a cada aplicación, evite compartir credenciales entre componentes y rote las credenciales de forma independiente. Además, las identidades distintas facilitan enormemente la revocación del acceso a un servicio sin afectar al resto.

Uso humano del NHI

El uso humano de la información no humana se produce cuando una persona utiliza una identidad no humana, como una cuenta de servicio o un token de API , para realizar tareas manuales que deberían ejecutarse con su propia cuenta. Esto resulta sencillo, ya que la cuenta de servicio suele tener amplios permisos de acceso. Dado que la mayoría de las plataformas no pueden diferenciar entre un usuario y una carga de trabajo que utilizan la misma identidad, su actividad parece prácticamente idéntica. El resultado son privilegios elevados en manos humanas, un registro de auditoría deficiente y acciones difíciles de atribuir cuando algo sale mal.

Mantenga separadas las identidades humanas y no humanas. Asigne a cada persona sus propias cuentas con roles adecuados para tareas manuales y de mantenimiento, y reserve las identidades no humanas para procesos automatizados. Supervise el uso de las identidades no humanas para que la actividad humana sea fácilmente identificable y aplique controles de acceso contextuales que marquen o bloqueen a las personas que inicien sesión con una cuenta de servicio.

Ya hemos analizado todos los riesgos relacionados con la identidad no humana, desde la filtración de secretos hasta la dependencia de identidades artificiales para tareas manuales. Es mucha información para asimilar de golpe, así que conviene tomar distancia y analizarlos en conjunto.

¿Notaste el patrón?

Al analizar los diez riesgos en conjunto, se observa un patrón claro. No se trata de diez problemas distintos, sino de los mismos tres hábitos que se presentan con diferentes apariencias: secretos que perduran demasiado tiempo, identidades con accesos excesivos e identidades que nadie elimina. Las filtraciones de secretos, las claves estáticas, las cuentas con privilegios excesivos y las cuentas huérfanas reflejan los mismos problemas fundamentales.

No necesitas diez herramientas diferentes. Necesitas unos pocos hábitos sólidos que se apliquen en todas partes: saber qué tienes, restringir el acceso, usar credenciales de corta duración y apagar los dispositivos cuando terminen de usarse. Y si quieres un punto de partida que te permita implementar varios de estos hábitos a la vez, fíjate en tus certificados. Los certificados son identidades de máquina que ya gestionas por miles, y se encuentran justo en el medio de esta lista. Si los dejas sin supervisión, se vuelven permanentes, provocan interrupciones del servicio cuando expiran sin que te des cuenta y se acumulan más rápido de lo que cualquiera puede controlarlos manualmente.

Si logras controlarlos, reducirás discretamente una gran parte del riesgo asociado a tu sistema nacional de salud. Gestionarlo a gran escala va más allá de una tarea manual , y es precisamente ahí donde una plataforma diseñada específicamente para este fin demuestra su valor.

Cómo puede ayudar la consultoría de cifrado

Poner en orden sus certificados es la forma más sencilla de reducir rápidamente gran parte del riesgo de NHI, y Encryption Consulting está aquí para ayudarle con su CertSecure Manager.

Uno de los mayores obstáculos en la gestión del ciclo de vida de los certificados es la visibilidad. Muchas organizaciones carecen de un inventario completo de sus certificados, lo que dificulta identificar la propiedad, supervisar las fechas de caducidad y evaluar los riesgos. Nuestro CertSecure Manager soluciona este problema mediante el descubrimiento continuo de certificados en servicios en la nube, servidores, aplicaciones, balanceadores de carga y otros sistemas empresariales, lo que ayuda a las organizaciones a identificar y gestionar certificados previamente desconocidos. Esto reduce el número de certificados desconocidos o no gestionados que suelen convertirse en puntos ciegos operativos.

Una vez descubiertos, los certificados se consolidan en un inventario centralizado que ofrece una visión unificada de su estado, propiedad, ubicación e información sobre su ciclo de vida. Esto facilita que los equipos de seguridad y operaciones comprendan qué certificados existen, quién es responsable de ellos y cuándo se requiere alguna acción.

Para ayudar a las organizaciones a gestionar el creciente volumen de renovaciones, nuestra plataforma admite flujos de trabajo automatizados que reducen el trabajo manual y agilizan la sustitución de certificados. Al automatizar los procesos del ciclo de vida, las organizaciones pueden disminuir el riesgo de interrupciones relacionadas con las renovaciones y reducir la carga administrativa de los equipos internos.

La plataforma también ofrece monitorización del riesgo de caducidad con alertas y notificaciones proactivas para los certificados próximos a expirar. Esto permite a los equipos centrarse en solucionar los problemas antes de que afecten a los servicios.

A medida que la duración de los certificados se acerca a los 47 días, la escalabilidad cobra cada vez más importancia. Nuestra plataforma está diseñada para admitir inventarios de certificados grandes y en constante crecimiento en entornos de nube, híbridos y locales, lo que ayuda a las organizaciones a mantener la visibilidad y el control incluso cuando la actividad de los certificados aumenta significativamente.

Al combinar descubrimiento, visibilidad, monitorización y automatización, nuestra plataforma proporciona un enfoque práctico para la gestión de certificados en un entorno donde la gestión manual del ciclo de vida de los certificados resulta cada vez más difícil de mantener.

Y si desea analizar la situación en su conjunto, Encryption Consulting también ofrece servicios de asesoramiento en cifrado . El equipo puede evaluar su situación actual y ayudarle a definir una estrategia y una hoja de ruta claras para que todo su programa de identidad de máquinas y cifrado avance de forma conjunta. CertSecure Manager le ayuda con la gestión del ciclo de vida de los certificados, y los servicios de asesoramiento en cifrado definen la estrategia general en torno a él.

Conclusión

Las identidades no humanas constituyen ahora el grupo más numeroso en tu entorno, y los diez riesgos mencionados anteriormente son los que los atacantes suelen aprovechar primero. La buena noticia es que todos se remontan a unos pocos hábitos fundamentales, por lo que puedes priorizarlos en lugar de intentar abordarlos todos a la vez.

No es necesario abordar todo a la vez. Un buen punto de partida es eliminar las identidades que ya nadie usa, ya que son las vulnerabilidades más fáciles de solucionar. A continuación, extraiga sus secretos del código fuente y guárdelos en una bóveda donde se roten periódicamente. Una vez hecho esto, restrinja cualquier acceso que exceda lo estrictamente necesario para el trabajo. Controlar sus certificados es la medida más eficaz, ya que elimina varios de estos riesgos de una sola vez. Si desea ayuda experta con este paso, podemos mostrarle cómo CertSecure Manager descubre, renueva y gestiona todos los certificados de su entorno.