Los ataques basados en la identidad están en aumento. Los ataques en los que los actores maliciosos asumen la identidad de una entidad para obtener fácil acceso a recursos y datos confidenciales han aumentado en número y frecuencia en los últimos años. Algunos informes recientes estiman que el 83% de los ataques involucran secretos comprometidos. Según informes como el Verizon DBIR, los atacantes usan más comúnmente credenciales robadas para obtener su punto de apoyo inicial, en lugar de explotar una vulnerabilidad o configación incorrecta.
Sin embargo, los atacantes no son solo después de las identidades humanas que pueden asumir. Más comúnmente, buscan identidades no humanas (NHIS), que superan en número a las identidades humanas en la empresa en al menos 50 a uno. A diferencia de los humanos, las máquinas no tienen una buena manera de lograr la autenticación multifactor, y nosotros, en su mayor parte, hemos dependido solo de las credenciales, en forma de claves API, tokens portadores y JWT.
Tradicionalmente, la gestión de identidad y acceso (IAM) se ha basado en la idea de rasgos humanos persistentes con el tiempo. Es raro que una persona cambie su nombre, huellas digitales o ADN. Podemos suponer que si pasó por un proceso de verificación de identidad, se confirma que es el humano que dice ser. En base a esto, puede obtener ciertos permisos que dependen de su papel dentro de la organización y su nivel de confianza.
Asegurar las identidades de la máquina significa manejar el rasgo único que los malos actores realmente les importan, a saber, sus claves de acceso. Si tratamos estos secretos altamente valorados como la forma de identificar de manera única las identidades que estamos protegiendo, entonces podemos aprovechar eso en una verdadera observabilidad sobre cómo se otorga y se usa el acceso en toda su empresa.
Contabilizar NHIS a través de una lente fracturada
Antes de analizar más profundamente los secretos como identificadores únicos, consideremos primero cómo hablamos actualmente de NHIS en la empresa.
La mayoría de los equipos luchan por definir NHIS. La definición canónica es simplemente «cualquier cosa que no sea humana», lo que es necesariamente un amplio conjunto de preocupaciones. NHIS se manifiesta de manera diferente entre proveedores de nubes, orquestadores de contenedores, sistemas heredados e implementaciones de borde. Una cuenta de servicio de Kubernetes ligada a un POD tiene características distintas en comparación con una identidad administrada de Azure o una cuenta de servicio de Windows. Cada equipo históricamente los ha manejado como preocupaciones separadas. Este enfoque de mosaico hace que sea casi imposible crear una política consistente, y mucho menos automatizar la gobernanza en todos los entornos.
El crecimiento exponencial de NHIS ha dejado una brecha en las herramientas de inventario de activos tradicionales, y los revisores de acceso no pueden mantener el ritmo. La aplicación de permisos consistentes o controles de seguridad en un conjunto de identidades tan variados parece casi imposible. Esto está además de los sistemas heredados de envejecimiento que no han girado o auditado sus contraseñas en años.
Comprobar este problema es la falta de metadatos y la propiedad en torno a NHIS. Preguntas como «¿Para qué sirve esta identidad?» o «¿Quién posee este token?» Con frecuencia, queda sin respuesta, ya que la persona que creó y liberó esa identidad en el sistema ha avanzado. Este vacío de responsabilidad hace que sea difícil aplicar prácticas básicas del ciclo de vida, como rotación o desmantelamiento. Los NHI que fueron creados para fines de prueba a menudo persisten mucho después de que los sistemas a los que estaban atados se descontinúan, acumulando el riesgo en silencio.
Los uuids de su superficie de proteger cero confianza
No importa qué forma o forma tome un NHI, para trabajar como parte de una aplicación o sistema, debe autenticarse para acceder a datos y recursos y hacer su trabajo.
Más comúnmente, esto toma la forma de secretos, que parecen claves API, certificados o tokens. Todos estos son inherentemente únicos y pueden actuar como huellas digitales criptográficas en los sistemas distribuidos. Cuando se usan de esta manera, los secretos utilizados para la autenticación se convierten en artefactos rastreables vinculados directamente a los sistemas que los generaron. Esto permite un nivel de atribución y auditoría que es difícil de lograr con las cuentas de servicio tradicionales. Por ejemplo, un token de corta duración puede estar directamente vinculado a un trabajo específico de CI, confirmación de GIT o carga de trabajo, permitiendo que los equipos respondan no solo lo que está actuando, sino por qué, dónde y en quién en su nombre.
Este modelo de acceso como identificador puede aportar claridad a su inventario, ofreciendo una vista unificada de todas sus máquinas, cargas de trabajo, corredores de tareas e incluso sistemas de IA basados en agentes. Los secretos ofrecen un método consistente y verificable de la máquina para indexar NHIS, permitiendo que los equipos centralicen la visibilidad de lo que existe, quién lo posee y a qué puede acceder, independientemente de si se está ejecutando en Kubernetes, acciones de Github o una nube pública.
Críticamente, este modelo también admite la gestión del ciclo de vida y los principios de confianza de cero de manera más natural que los marcos de identidad heredados. Un secreto solo es válido cuando se puede usar, que es un estado comprobable, lo que significa que los secretos no utilizados o caducados pueden marcarse automáticamente para la limpieza. Esto puede detener la expansión de identidad y las cuentas fantasmas, que son endémicas en entornos de NHI pesados.
Las ramificaciones de seguridad de los secretos en los identificadores de NHI
Si vamos a hablar sobre los secretos como el identificador único para máquinas y cargas de trabajo, debemos abordar el hecho de que tienen una tendencia desagradable a filtrarse. Según nuestro estado de los secretos, la investigación de 2025, casi 23.8 millones de secretos se filtraron en repositorios públicos de GitHub en 2024, un aumento de 25% año tras año. Peor aún, un 35% completo de los repositorios privados que investigamos contenía secretos, 8 veces más Como encontramos en repositorios públicos.
Las violaciones en los últimos años, desde Uber hasta el Departamento del Tesoro de los Estados Unidos, han demostrado que cuando los secretos están dispersos por tuberías, basas de código, contenedores y configuraciones en la nube sin una gestión constante, se convierten en una invitación silenciosa a los atacantes. Estas credenciales filtradas o robadas ofrecen a los atacantes una ruta de compromiso de baja fricción.
Una clave API filtrada o un token NHI permite a cualquier persona que intente usarla establecer una sesión válida, sin mecanismo para verificar su legitimidad o el contexto de su uso. Si el secreto está vinculado a una cuenta o una cuenta de servicio de larga duración y demasiado permisionada, el atacante hereda instantáneamente toda esa confianza.
El problema se amplifica aún más cuando los secretos sobreviven a su propósito. Secretos huérfanos, credenciales olvidadas y nunca desmanteladas, trabajos de CI/CD abandonados, o proyectos únicos, persisten en silencio, a menudo con niveles peligrosos de acceso y visibilidad cero. Sin procesos de propiedad, vencimiento o revocación, se convierten en puntos de entrada ideales para los atacantes que buscan sigilo y persistencia.
Gitguardian puede inventar las que inventario todos sus secretos, no solo los filtrados
Los secretos solo pueden vivir en dos lugares posibles: donde pertenecen, almacenados de forma segura en una bóveda de gestión de secretos o filtrados en otro lugar. Hemos estado ayudando a las personas a encontrar los secretos filtrados donde se supone que no deben estar durante años, con nuestra oferta de detección de secretos centrados internamente y nuestra plataforma de monitoreo público.
Ahora, GitGuardian puede actuar como su plataforma de inventario NHI de fondo de medio ambiente, lo que le ayuda a obtener visibilidad de qué secretos hay en sus bóvedas, junto con metadatos en torno a cómo se usan. Gitguardian construye un inventario unificado y contextualizado de cada secreto, independientemente del origen o el formato. Ya sea inyectado a través de Kubernetes, incrustado en un libro de jugadas Ansible, o recuperado de una bóveda como Hashicorp, cada secreto se hace huellas digitales y monitoreada.
Esta conciencia entre modernidad permite a los equipos ver rápidamente
- ¿Qué NHIS tienen claves filtradas públicamente?
- Si alguna fuga interna ocurrió para esos mismos secretos.
- Cualquier secreto almacenado redundantemente en múltiples bóvedas
- Si el secreto es de larga data y necesita rotación
 |
| El tablero de inventario de gobernanza de Gitguardian NHI que muestra violaciones de políticas y puntajes de riesgo. |
Crucialmente, Gitguardian también detecta credenciales «zombies», secretos que persisten sin autorización ni supervisión. Los metadatos ricos, como la atribución del creador, la vida útil secreta, el alcance de los permisos y el contexto, potencian la gobernanza sobre estos actores no humanos, lo que permite la alineación y la responsabilidad del inventario en tiempo real.
Esta visibilidad no es solo operativa, es estratégica. Gitguardian permite la aplicación de políticas centralizadas en todas las fuentes secretas, transformando la detección de secretos reactivos en gobernanza de identidad proactiva. Al mapear secretos a NHIS y hacer cumplir las políticas del ciclo de vida como la expiración, la rotación y la revocación, Gitguardian cierra el bucle entre el descubrimiento, la bóveda y la aplicación de la ley
Más allá del inventario y hacia el gobierno de NHI
El surgimiento de las identidades no humanas ha remodelado el paisaje de identidad y, con él, la superficie de ataque. Las credenciales no son solo claves de acceso. Los secretos son el mecanismo que permite a un atacante asumir una identidad que ya tiene acceso persistente a sus datos y recursos. Sin visibilidad de dónde viven esas credenciales, cómo se usan y si todavía son válidas, las organizaciones se dejan vulnerables al compromiso silencioso.
 |
| Secrets Security de Gitguardian + Gobierno NHI = Seguridad de identidad no humana |
Tratar los secretos como los UUID de las cargas de trabajo modernas es el camino más claro hacia la gobernanza NHI escalable y multiplataforma. Pero ese enfoque solo funciona si puede ver la imagen completa: bóvedas, tuberías, infraestructura efímera y todo lo demás.
Gitguardian ofrece esa visibilidad. Estamos convirtiendo la credencial fragmentada en un inventario unificado y procesable. Al anclar la identidad de NHI a su secreto autenticador, y las capas en metadatos ricos y controles de ciclo de vida, Gitguardian permite a los equipos de seguridad detectar problemas temprano, identificar credenciales excesivamente permisionadas y huérfanas, y aplicar la revocación antes de una incumplimiento.
Estamos ayudando a las empresas modernas complejas a reducir la probabilidad de ataques exitosos basados en la identidad. Cuando las credenciales son monitoreadas, alcanzadas y manejadas en tiempo real, ya no son frutas de bajo ahuyente para los atacantes.
Nos encantaría darle una demostración completa de las capacidades de la plataforma de seguridad NHI Gitguardian y ayudarlo a obtener una visión incomparable de su seguridad NHIS y secretos. Y si prefiere explorar por su cuenta, ¡realice una visita guiada por Gitguardian con nuestra demostración interactiva!
