Las identidades no humanas son un motor de vulnerabilidades: por qué los tokens y las cuentas de servicio siguen estando expuestos

/Tecnología/ Por

Las identidades no humanas (claves API, tokens, cuentas de servicio, identidades de carga de trabajo) son ahora una de las formas más sencillas de acceder a los entornos de nube modernos. No porque los atacantes se hayan vuelto expertos de repente, sino porque las organizaciones se basan cada vez más en la confianza entre máquinas, y esa confianza suele ser excesiva, duradera y poco supervisada.

Un nuevo análisis destacado en un informe señala un patrón familiar a gran escala: miles de imágenes de contenedores y repositorios que exponen accidentalmente secretos que otorgan acceso sigilosamente a los sistemas de producción. El problema no es solo que los desarrolladores a veces cometan errores. El problema es que las herramientas y los incentivos predeterminados lo hacen...fácilpara enviar secretos yduroPara demostrar que no lo hiciste.

Esta es una historia de "filtración invisible". Muchas vulneraciones no comienzan con un exploit ni un evento de malware de alto impacto. Comienzan con un token que se autentica correctamente (para que todo parezca normal) hasta que te das cuenta de que lo ha estado usando el principal equivocado.

Qué son las “identidades no humanas” (en términos sencillos)

Una identidad no humana (NHI) es cualquier credencial que permite que el software se autentique como un actor confiable:

  • claves de acceso a la nube y tokens de sesión
  • cuentas de servicio e identidades de carga de trabajo
  • Credenciales de CI/CD utilizadas por los canales de compilación
  • tokens para herramientas SaaS (GitHub, GitLab, Slack, plataformas de monitorización)
  • Claves API para servicios de terceros (proveedores de pago, proveedores de correo electrónico, API de modelos de IA)

La diferencia importante con los inicios de sesión humanos es que los NHI normalmente:

  • correr continuamente
  • están incrustados en el código o configuración
  • y a menudo no utilizan MFA

Eso los hace atractivos.

Si un atacante obtiene un token funcional, no necesita “entrar ilegalmente”. Se autentica.

¿Por qué esto está empeorando ahora?

Tres tendencias están llevando a los SNS de “importantes” a “riesgo dominante”:

1) Las cadenas de suministro de software son más grandes que nunca

Las aplicaciones modernas se componen de:

  • contenedores
  • dependencias de código abierto
  • infraestructura como código
  • Docenas de integraciones SaaS

Cada integración agrega otra credencial.

2) La automatización está en todas partes

Las organizaciones quieren:

  • despliegues más rápidos
  • infraestructura de autoservicio
  • entornos efímeros

La automatización es buena, pero está impulsada por identidades que tienen privilegios.

3) Las credenciales duran más que las personas que las crearon

Los humanos cambian de roles y se van.

Pero un token en un repositorio o un contenedor puede:

  • persistir durante meses o años
  • ser copiado en nuevas compilaciones
  • y seguirá siendo válido mucho después de que alguien recuerde que existe.

Así que la superficie de ataque crece silenciosamente.

Cómo se filtran secretos en la vida real (no siempre es "alguien ha cometido un error")

El estereotipo es el de un desarrollador que se comprometeCLAVE DE ACCESO SECRETA DE AWSa GitHub.

Eso todavía ocurre. Pero muchas fugas son menos evidentes:

  • tokens horneados en capas de contenedores
  • archivos de configuración copiados en imágenes durante la compilación
  • registros de depuración que contienen secretos
  • Claves “temporales” compartidas en el chat y luego pegadas en el código
  • Variables CI impresas por canalizaciones mal configuradas

Y las imágenes de contenedores son particularmente peligrosas porque:

  • se reflejan
  • se almacenan en caché
  • Se copian entre equipos

Incluso si elimina la clave del repositorio, esta puede permanecer en las capas de imágenes antiguas.

Por qué los tokens filtrados son más peligrosos que muchos exploits

Los exploits son ruidosos y suelen generar alertas.

Las filtraciones de tokens son silenciosas. Suelen parecer de uso normal:

  • autenticación exitosa
  • llamadas API correctas
  • puntos finales legítimos

Eso cambia el problema del defensor.

En lugar de detectar “un atacante”, hay que detectar:

  • Un inesperadoprincipalutilizando credenciales válidas
  • desde lugares inusuales
  • en momentos inusuales
  • realizando acciones inusuales

Es por esto que los NHIs representan una brecha de detección para muchas organizaciones.

El problema del privilegio: los tokens suelen ser demasiado poderosos

Muchos secretos se crean como atajos para "hacer que funcione":

  • amplios permisos en la nube
  • acceso a la API de nivel de administrador
  • llaves de larga duración

Y una vez que el sistema funciona, la gente no quiere tocarlo.

Esto crea una asimetría peligrosa:

  • Una cuenta humana podría tener MFA y monitoreo
  • La identidad de la máquina podría tener amplio acceso y poco escrutinio.

Cuando se filtra la identidad de la máquina, el radio de explosión puede ser mayor.

Cómo es una buena estrategia de NHI (prácticas concretas)

Esto tiene solución, pero sólo si tratamos los NHI como activos de seguridad de primera clase.

1) Prefiera credenciales de corta duración

Cuando sea posible:

  • utilizar credenciales de sesión temporales
  • rotar tokens con frecuencia
  • Evite las claves que “nunca caducan”

Los tokens de corta duración reducen la rentabilidad de las filtraciones.

2) Reemplace las claves estáticas con la identidad de la carga de trabajo donde sea posible.

En las configuraciones de nube modernas, a menudo es posible autenticar cargas de trabajo mediante:

  • identidad de instancia
  • Federación OIDC
  • identidad administrada

Esto reduce la necesidad de almacenar claves estáticas.

3) Entornos estrictamente separados

Un error común es utilizar el mismo token en:

  • desarrollador
  • puesta en escena
  • producción

Los tokens deben tener alcance ambiental.

Si se filtra una imagen de desarrollo, no debería desbloquear la producción.

4) Inventario y propiedad

Cada token significativo debe tener:

  • un propietario
  • un propósito
  • un patrón de uso esperado

Si un token no tiene dueño, es una deuda técnica a punto de convertirse en un incidente.

5) Monitorear el comportamiento del NHI como se monitorea el comportamiento humano

Las buenas señales incluyen:

  • viajes imposibles / geografías inusuales
  • secuencias de llamadas API inusuales
  • picos en el acceso a los datos
  • nuevos permisos concedidos
  • nuevos tokens creados

El objetivo no es la detección perfecta sino la detección temprana.

6) Tratar la CI/CD como una fábrica de identidad de alto riesgo

Los sistemas CI frecuentemente contienen:

  • claves de implementación
  • claves de firma
  • credenciales en la nube

Bloquearlos:

  • mínimo privilegio
  • corredores separados
  • Enmascaramiento secreto y prevención de fugas de registros
  • Aprobaciones estrictas para los pasos de implementación de producción

Dónde suelen fallar los equipos (y cómo evitarlo)

“Rotamos las llaves a veces” no es un plan

Si la rotación es manual y dolorosa, no se realizará bajo presión.

Hacer que la rotación sea rutinaria y automatizada.

Las herramientas de seguridad sin control se convierten en un “teatro de vigilancia”

Escanear repositorios en busca de secretos es útil, pero no es suficiente.

También necesitarás:

  • revocación rápida
  • alertas de uso
  • y prevención en la construcción de tuberías

La trampa de la capa contenedora

Si alguna vez los secretos ingresaron a un contexto de compilación de contenedor, suponga que pueden existir en:

  • imágenes antiguas
  • capas en caché
  • Artefactos de CI

La solución no es solo "eliminar la clave del repositorio". Es:

  • girar el secreto
  • reconstruir y republicar imágenes
  • invalidar cachés cuando sea posible

¿Qué ver a continuación?

Si desea realizar un seguimiento de si las organizaciones están mejorando los NHI, busque:

  • Adopción de una identidad de corta duración (OIDC/identidad de carga de trabajo)
  • programas generalizados de rotación de tokens
  • controles de límites CI/CD más fuertes
  • informes de incidentes que reconocen el uso de credenciales válidas como causa principal

También hay que tener en cuenta el aspecto de las herramientas: las mejores herramientas pasarán de “detectar cadenas expuestas” a “reducir la cantidad de secretos estáticos que existen”.

La economía: por qué a los atacantes les encanta la caza de tokens

Balanzas de caza de fichas.

Un atacante que roba una credencial funcional a menudo puede:

  • acceder a múltiples sistemas (nube + control de código fuente + CI)
  • reutilizar la misma técnica en muchas organizaciones
  • y vender el acceso en mercados si no quieren operarlo ellos mismos

Para los defensores, esto significa que la amenaza no es solo "un hacker que nos ataca". Es "una economía de máquinas que se beneficia de cualquier credencial reutilizable".

Por eso, la prevención es más valiosa que la respuesta. Si la clave nunca existió de forma estática, no se podrá extraer posteriormente.

Ideas concretas para la detección (sobre qué hay que estar alerta)

Si está creando detecciones para NHI, concéntrese en los cambios de comportamiento en lugar de en palabras clave mágicas.

Ejemplos de señal alta:

  • Una cuenta de servicio utilizada desde unnuevo país/ASNNunca se usó antes.
  • Un token que normalmente solo llama a una API de repente enumera recursos o descarga grandes volúmenes.
  • Una identidad de CI que realiza acciones fuera de la ventana de lanzamiento normal.
  • Secretos utilizados desde puntos finales de usuario interactivos cuando estaban destinados únicamente a cargas de trabajo del servidor.

Incluso las alertas de anomalías básicas pueden detectar de forma temprana el patrón de “robo silencioso de credenciales”.

Ideas para el endurecimiento del hormigón (bajo esfuerzo, alto apalancamiento)

Estos son cambios prácticos que la mayoría de los equipos pueden realizar sin un rediseño masivo:

  • Reducir el alcance del token:dividir un token amplio en varios tokens de alcance limitado.
  • Girar según horario:girar incluso cuando no hay nada “malo”, de modo que la rotación se convierte en memoria muscular.
  • Producción de compuertas:requiere aprobación explícita para identidades de implementación de producción.
  • Bloquear secretos de texto simple en compilaciones:CI debería fallar en las compilaciones cuando aparecen patrones secretos obvios.

Cada movimiento reduce el radio de la explosión incluso si todavía ocurre una fuga.

Una política interna sencilla que evita muchos dolores

Si quieres una política que fuerce un mejor comportamiento, es ésta:

  • No hay secretos aptos para producción en las computadoras portátiles de los desarrolladores ni en contextos de creación de contenedores.

Esa regla impulsa cambios como:

  • identidad de carga de trabajo para servicios
  • credenciales de puesta en escena para el desarrollo
  • y aprobaciones explícitas para los pasos de implementación de producción

Al principio es molesto, pero corta las vías de fuga más fáciles.

En resumen

Las identidades no humanas son la columna vertebral de la automatización moderna y también un importante factor de vulneración de datos porque a menudo eluden las protecciones que hemos creado para los humanos.

Si desea un umbral práctico: una vez que pueda responder "dónde viven nuestros tokens de larga duración, quién los posee y con qué rapidez podemos revocarlos o rotarlos", habrá pasado de ser una ilusión a un verdadero programa de defensa.

La solución práctica no es un escáner mágico. Es un programa: minimiza los secretos estáticos, reduce los privilegios, haz que la rotación sea rutinaria y monitorea las identidades de las máquinas como monitoreas las cuentas de usuario.

Fuentes

Document Title
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed
Leaked API keys and service-account tokens are a quiet but growing breach driver in cloud environments. Here’s how they leak, why they’re dangerous, and how to harden and detect abuse.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs
Google teases Pixel 10A: what we know ahead of the February 18 reveal
Page Content
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed
Nature
Climate
/
Technology
/ By
Admin
Non-human identities—API keys, tokens, service accounts, workload identities—are now one of the easiest ways into modern cloud environments. Not because attackers suddenly became geniuses, but because organizations increasingly run on machine-to-machine trust, and that trust is often overbroad, long-lived, and poorly monitored.
A new analysis highlighted in reporting points to a familiar pattern at huge scale: thousands of container images and repositories accidentally exposing secrets that quietly grant access to production systems. The problem isn’t just that developers sometimes make mistakes. The problem is that the default tooling and incentives make it
easy
to ship secrets and
hard
to prove you didn’t.
This is an “invisible breach” story. Many compromises won’t start with an exploit or a loud malware event. They’ll start with a token that authenticates cleanly—so everything looks normal—until you realize the wrong principal has been using it.
What “non-human identities” are (in plain terms)
A non-human identity (NHI) is any credential that lets software authenticate as a trusted actor:
cloud access keys and session tokens
service accounts and workload identities
CI/CD credentials used by build pipelines
tokens for SaaS tools (GitHub, GitLab, Slack, monitoring platforms)
API keys for third-party services (payment providers, email providers, AI model APIs)
The important difference from human logins is that NHIs typically:
run continuously
are embedded in code or config
and often don’t use MFA
That makes them attractive.
If an attacker obtains a working token, they don’t have to “break in.” They authenticate.
Why this is getting worse now
Three trends are pushing NHIs from “important” to “dominant risk”:
1) Software supply chains are bigger than ever
Modern apps are assembled from:
containers
open-source dependencies
infrastructure-as-code
dozens of SaaS integrations
Every integration adds another credential.
2) Automation is everywhere
Organizations want:
faster deploys
self-service infrastructure
ephemeral environments
Automation is good—but it is powered by identities that have privileges.
3) Credentials last longer than the people who created them
Humans change roles and leave.
But a token in a repo or a container can:
persist for months or years
be copied into new builds
and remain valid long after anyone remembers it exists
So the attack surface grows silently.
How secrets leak in real life (it’s not always “someone committed a key”)
The stereotype is a developer committing
AWS_SECRET_ACCESS_KEY
to GitHub.
That still happens. But a lot of leakage is less obvious:
tokens baked into container layers
config files copied into images during build
debug logs containing secrets
“temporary” keys shared in chat and later pasted into code
CI variables printed by misconfigured pipelines
And container images are particularly dangerous because:
they get mirrored
they get cached
they get copied between teams
Even if you delete the key from the repo, the key can remain in old image layers.
Why leaked tokens are more dangerous than many exploits
Exploits are noisy. They often trigger alerts.
Leaked tokens are quiet. They often look like normal usage:
successful authentication
correct API calls
legitimate endpoints
That changes the defender’s problem.
Instead of detecting “an attacker,” you have to detect:
an unexpected
principal
using valid credentials
from unusual locations
at unusual times
doing unusual actions
This is why NHIs are a detection gap for many organizations.
The privilege problem: tokens are often too powerful
A lot of secrets are created as “get it working” shortcuts:
broad cloud permissions
admin-level API access
long-lived keys
And once the system works, people don’t want to touch it.
This creates a dangerous asymmetry:
a human account might have MFA and monitoring
the machine identity might have broad access and little scrutiny
When the machine identity leaks, the blast radius can be bigger.
What a good NHI strategy looks like (concrete practices)
This is solvable, but only if you treat NHIs as first-class security assets.
1) Prefer short-lived credentials
Where possible:
use temporary session credentials
rotate tokens frequently
avoid “never expires” keys
Short-lived tokens reduce the payoff of leaks.
2) Replace static keys with workload identity where you can
In modern cloud setups, you can often authenticate workloads via:
instance identity
OIDC federation
managed identity
This reduces the need to store static keys.
3) Separate environments strictly
A common failure is using the same token across:
dev
staging
production
Tokens should be environment-scoped.
If a dev image leaks, it shouldn’t unlock prod.
4) Inventory and ownership
Every meaningful token should have:
an owner
a purpose
an expected usage pattern
If a token has no owner, it is technical debt waiting to become an incident.
5) Monitor NHI behavior like you monitor human behavior
Good signals include:
impossible travel / unusual geographies
unusual API call sequences
spikes in data access
new permissions granted
new tokens created
The goal is not perfect detection; it’s early detection.
6) Treat CI/CD as a high-risk identity factory
CI systems frequently hold:
deployment keys
signing keys
cloud credentials
Lock them down:
least privilege
separated runners
secret masking and prevention of log leaks
strict approvals for production deploy steps
Where teams usually fail (and how to avoid it)
“We rotate keys sometimes” isn’t a plan
If rotation is manual and painful, it won’t happen under pressure.
Make rotation routine and automated.
Security tools without enforcement become “monitoring theater”
Scanning repositories for secrets is useful, but it’s not enough.
You also need:
rapid revocation
alerts on usage
and prevention in build pipelines
The container layer trap
If secrets ever entered a container build context, assume they may exist in:
old images
cached layers
CI artifacts
The fix is not only “delete the repo key.” It’s:
rotate the secret
rebuild and republish images
invalidate caches where possible
What to watch next
If you want to track whether organizations are improving on NHIs, look for:
adoption of short-lived identity (OIDC/workload identity)
widespread token rotation programs
stronger CI/CD boundary controls
incident reports that acknowledge “valid credentials used” as a primary cause
Also watch the tooling side: the best tools will shift from “detect exposed strings” to “reduce the number of static secrets that exist at all.”
The economics: why attackers love token hunting
Token hunting scales.
An attacker who steals one working credential can often:
access multiple systems (cloud + source control + CI)
reuse the same technique across many organizations
and sell access in marketplaces if they don’t want to operate it themselves
For defenders, this means the threat isn’t just “a hacker targeting us.” It’s “a machine economy that profits from any reusable credential.”
That’s why prevention is more valuable here than response. If the key never existed in static form, it can’t be harvested later.
Concrete detection ideas (what to alert on)
If you’re building detections for NHIs, focus on behavior changes rather than magic keywords.
High-signal examples:
A service account used from a
new country/ASN
it never used before.
A token that normally only calls one API suddenly enumerates resources or downloads large volumes.
A CI identity performing actions outside the normal release window.
Secrets used from interactive user endpoints when they were intended only for server workloads.
Even basic anomaly alerts can catch the “quiet credential theft” pattern early.
Concrete hardening ideas (low effort, high leverage)
These are practical changes most teams can make without a massive redesign:
Reduce token scope
: split one broad token into several narrowly scoped tokens.
Rotate on schedule
: rotate even when nothing is “wrong,” so rotation becomes muscle memory.
Gate production
: require explicit approval for production deploy identities.
Block plaintext secrets in builds
: CI should fail builds when obvious secret patterns appear.
Each move shrinks blast radius even if a leak still occurs.
A simple internal policy that prevents a lot of pain
If you want one policy that forces better behavior, it’s this:
No production-capable secrets in developer laptops or in container build contexts.
That rule drives changes like:
workload identity for services
staging credentials for development
and explicit approvals for production deployment steps
It’s annoying at first, but it cuts off the easiest leak paths.
Bottom line
Non-human identities are the backbone of modern automation—and also a major breach driver because they often bypass the protections we’ve built for humans.
If you want a practical threshold: once you can answer “where do our long-lived tokens live, who owns them, and how quickly can we revoke/rotate them,” you’ve moved from wishful thinking to a real defense program.
The practical fix is not one magic scanner. It’s a program: minimize static secrets, shrink privileges, make rotation routine, and monitor machine identities like you monitor user accounts.
Sources
https://www.bleepingcomputer.com/news/security/the-double-edged-sword-of-non-human-identities/
←
Previous Post
Next Post
→
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs
Google teases Pixel 10A: what we know ahead of the February 18 reveal
Leaked API keys and service-account tokens are a quiet but growing breach driver in cloud environments. Here’s how they leak, why they’re dangerous, and how to harden and detect abuse.
Document Title
Page not found - Florin.blog
Image Alt
Florin.blog
Title Attribute
Florin.blog » Feed
RSD
Skip to content
Placeholder Attribute
Search...
Page Content
Page not found - Florin.blog
Skip to content
Home
Blog
Garden Decor
Indoor
Main Menu
This page doesn't seem to exist.
It looks like the link pointing here was faulty. Maybe try searching?
Search for:
Search
Quick Links
Outdoors
About
Contact
Explore
Bestsellers
Hot deals
Best of The Year
Featured
Gift Cards
Help
Privacy Policy
Disclaimer
: As an Amazon Associate, we earn from qualifying purchases — at no extra cost to you.
Florin.blog
Florin.blog » Feed
RSD
Search...
s Español