Identidades não humanas são uma fonte de vulnerabilidades: por que tokens e contas de serviço continuam sendo expostos?

/Tecnologia/ Por

Identidades não humanas — chaves de API, tokens, contas de serviço, identidades de cargas de trabalho — são agora uma das formas mais fáceis de acessar ambientes de nuvem modernos. Não porque os atacantes se tornaram gênios de repente, mas porque as organizações operam cada vez mais com base na confiança entre máquinas, e essa confiança costuma ser excessivamente ampla, de longa duração e mal monitorada.

Uma nova análise destacada em reportagens aponta para um padrão familiar em grande escala: milhares de imagens de contêineres e repositórios expondo acidentalmente segredos que silenciosamente concedem acesso a sistemas de produção. O problema não é apenas que os desenvolvedores às vezes cometem erros. O problema é que as ferramentas padrão e os incentivos tornam isso possível.fácilpara enviar segredos eduroPara provar que você não fez isso.

Esta é uma história de "invasão invisível". Muitas invasões não começam com uma exploração ou um ataque de malware de grande repercussão. Elas começam com um token que autentica sem problemas — então tudo parece normal — até que você perceba que a entidade errada o estava usando.

O que são “identidades não humanas” (em termos simples)

Uma identidade não humana (NHI, na sigla em inglês) é qualquer credencial que permite que um software se autentique como um agente confiável:

  • chaves de acesso à nuvem e tokens de sessão
  • contas de serviço e identidades de carga de trabalho
  • Credenciais de CI/CD usadas pelos pipelines de compilação
  • Tokens para ferramentas SaaS (GitHub, GitLab, Slack, plataformas de monitoramento)
  • Chaves de API para serviços de terceiros (provedores de pagamento, provedores de e-mail, APIs de modelos de IA)

A principal diferença em relação aos logins humanos é que os NHIs normalmente:

  • executar continuamente
  • estão incorporadas no código ou na configuração
  • e muitas vezes não usam MFA.

Isso os torna atraentes.

Se um atacante obtiver um token válido, ele não precisa "invadir" o sistema. Ele simplesmente se autentica.

Por que isso está piorando agora?

Três tendências estão impulsionando os Seguros Nacionais de Saúde (NHIs) de um risco “importante” para um “risco dominante”:

1) As cadeias de suprimentos de software são maiores do que nunca.

Os aplicativos modernos são montados a partir de:

  • contêineres
  • dependências de código aberto
  • infraestrutura como código
  • dezenas de integrações de SaaS

Cada integração adiciona uma nova credencial.

2) A automação está em toda parte

As organizações desejam:

  • implantações mais rápidas
  • infraestrutura de autoatendimento
  • ambientes efêmeros

A automação é boa, mas é alimentada por identidades que possuem privilégios.

3) As credenciais duram mais do que as pessoas que as criaram.

Os seres humanos mudam de papéis e vão embora.

Mas um token em um repositório ou contêiner pode:

  • persistir por meses ou anos
  • ser copiado para novas compilações
  • e permanecem válidas muito tempo depois de alguém se lembrar de sua existência.

Assim, a superfície de ataque cresce silenciosamente.

Como os segredos vazam na vida real (nem sempre é "alguém comprometeu uma chave")

O estereótipo é o de um desenvolvedor que se compromete com algo.AWS_SECRET_ACCESS_KEYpara o GitHub.

Isso ainda acontece. Mas muitos vazamentos são menos óbvios:

  • tokens incorporados em camadas de contêiner
  • Os arquivos de configuração são copiados para as imagens durante a compilação.
  • logs de depuração contendo segredos
  • Chaves “temporárias” compartilhadas no chat e posteriormente coladas no código.
  • Variáveis ​​de CI impressas por pipelines mal configurados

E as imagens de contêiner são particularmente perigosas porque:

  • eles são espelhados
  • eles ficam em cache
  • Eles são copiados entre as equipes.

Mesmo que você exclua a chave do repositório, ela pode permanecer em camadas de imagem antigas.

Por que tokens vazados são mais perigosos do que muitas explorações?

Explorações de vulnerabilidades são ruidosas. Elas frequentemente disparam alertas.

Os tokens vazados são silenciosos. Muitas vezes, eles se parecem com um uso normal:

  • autenticação bem-sucedida
  • chamadas de API corretas
  • pontos finais legítimos

Isso muda o problema do defensor.

Em vez de detectar “um atacante”, você precisa detectar:

  • um inesperadoprincipalusando credenciais válidas
  • de locais incomuns
  • em horários incomuns
  • realizando ações incomuns

É por isso que os NHIs representam uma lacuna de detecção para muitas organizações.

O problema do privilégio: os tokens muitas vezes são poderosos demais.

Muitos segredos são criados como atalhos para "fazer funcionar":

  • permissões amplas na nuvem
  • Acesso à API em nível de administrador
  • chaves de longa duração

E quando o sistema funciona, as pessoas não querem mais mexer nele.

Isso cria uma assimetria perigosa:

  • Uma conta humana pode ter autenticação multifator (MFA) e monitoramento.
  • A identidade da máquina pode ter amplo acesso e pouca fiscalização.

Quando a identidade da máquina vaza, o raio da explosão pode ser maior.

Como é uma boa estratégia de Seguro Nacional de Saúde (práticas concretas)

Isso tem solução, mas apenas se você tratar os NHIs como ativos de segurança de primeira classe.

1) Prefira credenciais de curta duração

Sempre que possível:

  • usar credenciais de sessão temporárias
  • Gire os tokens frequentemente.
  • Evite chaves que “nunca expiram”.

Tokens de curta duração reduzem o retorno dos vazamentos.

2) Substitua as chaves estáticas pela identidade da carga de trabalho sempre que possível.

Em configurações de nuvem modernas, você geralmente pode autenticar cargas de trabalho por meio de:

  • identidade da instância
  • Federação OIDC
  • identidade gerenciada

Isso reduz a necessidade de armazenar chaves estáticas.

3) Ambientes estritamente separados

Um erro comum é usar o mesmo token em vários locais:

  • desenvolvedor
  • encenação
  • produção

Os tokens devem ter escopo de ambiente.

Se uma imagem de desenvolvimento vazar, isso não deve desbloquear a versão de produção.

4) Inventário e propriedade

Todo token significativo deve ter:

  • um proprietário
  • um propósito
  • um padrão de uso esperado

Se um token não tem proprietário, ele representa uma dívida técnica prestes a se tornar um incidente.

5) Monitore o comportamento dos usuários do NHI da mesma forma que você monitora o comportamento humano.

Bons sinais incluem:

  • viagens impossíveis / geografias incomuns
  • sequências incomuns de chamadas de API
  • picos no acesso a dados
  • novas permissões concedidas
  • novos tokens criados

O objetivo não é a detecção perfeita, mas sim a detecção precoce.

6) Tratar CI/CD como uma fábrica de identidade de alto risco

Os sistemas de CI frequentemente contêm:

  • chaves de implantação
  • chaves de assinatura
  • credenciais de nuvem

Tranque-os:

  • privilégio mínimo
  • corredores separados
  • mascaramento secreto e prevenção de vazamentos de logs
  • Aprovações rigorosas para etapas de implantação em produção

Onde as equipes geralmente falham (e como evitar isso)

"Às vezes, trocamos as chaves" não é um plano.

Se a rotação for manual e dolorosa, ela não ocorrerá sob pressão.

Torne a rotação rotineira e automatizada.

Ferramentas de segurança sem aplicação se transformam em "teatro de monitoramento".

Analisar repositórios em busca de segredos é útil, mas não é suficiente.

Você também precisa de:

  • revogação rápida
  • alertas de uso
  • e prevenção em pipelines de construção

Armadilha da camada do contêiner

Se segredos alguma vez entraram no contexto de construção de um contêiner, presume-se que eles possam existir em:

  • imagens antigas
  • camadas em cache
  • Artefatos de CI

A solução não é apenas "excluir a chave do repositório". É:

  • gire o segredo
  • reconstruir e republicar imagens
  • invalidar caches sempre que possível

O que assistir a seguir

Se você deseja acompanhar se as organizações estão aprimorando seus indicadores de saúde, procure por:

  • Adoção de identidade de curta duração (OIDC/identidade de carga de trabalho)
  • programas generalizados de rotação de tokens
  • controles de limite CI/CD mais fortes
  • Relatórios de incidentes que reconhecem o uso de "credenciais válidas" como causa principal.

Fique de olho também nas ferramentas: as melhores ferramentas vão migrar de "detectar strings expostas" para "reduzir o número de segredos estáticos existentes".

A economia: por que os atacantes adoram a caça a tokens.

Escalas de caça de fichas.

Um invasor que rouba uma credencial funcional geralmente pode:

  • Acesso a múltiplos sistemas (nuvem + controle de versão + CI)
  • reutilizar a mesma técnica em diversas organizações
  • e vender acesso em marketplaces caso não queiram administrá-los por conta própria.

Para os defensores, isso significa que a ameaça não é apenas "um hacker nos visando". É "uma economia automatizada que lucra com qualquer credencial reutilizável".

Por isso, a prevenção é mais valiosa do que a resposta. Se a chave nunca existiu em formato estático, não poderá ser obtida posteriormente.

Ideias concretas para detecção (sobre o que gerar alertas)

Se você estiver criando detecções para NHIs (Informações de Saúde Nacionais), concentre-se em mudanças de comportamento em vez de palavras-chave mágicas.

Exemplos de sinal forte:

  • Uma conta de serviço usada a partir de umnovo país/ASNNunca foi usado antes.
  • Um token que normalmente só chama uma API, de repente, enumera recursos ou baixa grandes volumes.
  • Uma identidade de CI executando ações fora do período normal de lançamento.
  • Segredos utilizados em endpoints interativos de usuários quando estes eram destinados apenas a cargas de trabalho do servidor.

Até mesmo alertas básicos de anomalias podem detectar o padrão de "roubo silencioso de credenciais" logo no início.

Ideias para endurecimento de concreto (baixo esforço, alto resultado)

Estas são mudanças práticas que a maioria das equipes pode implementar sem uma reformulação completa:

  • Reduzir o escopo do token: dividir um token amplo em vários tokens de escopo restrito.
  • Rotacionar conforme o cronograma: girar mesmo quando nada está "errado", para que a rotação se torne um reflexo condicionado.
  • Produção de portãoExigir aprovação explícita para identidades de implantação em produção.
  • Bloquear segredos em texto simples nas compilaçõesA integração contínua (CI) deve interromper as compilações quando padrões secretos óbvios aparecerem.

Cada movimento reduz o raio da explosão, mesmo que ainda ocorra um vazamento.

Uma política interna simples que evita muitos problemas.

Se você quer uma política que incentive um comportamento melhor, é esta:

  • Não deve haver segredos que permitam a produção armazenados em laptops de desenvolvedores ou em contextos de construção de contêineres.

Essa regra impulsiona mudanças como:

  • identidade de carga de trabalho para serviços
  • credenciais de teste para desenvolvimento
  • e aprovações explícitas para etapas de implantação em produção

É irritante no início, mas elimina os caminhos de vazamento mais fáceis.

Resumindo

Identidades não humanas são a espinha dorsal da automação moderna — e também uma importante causa de violações de segurança, pois frequentemente contornam as proteções que criamos para os humanos.

Se você quer um limite prático: uma vez que você consiga responder “onde estão localizados nossos tokens de longa duração, quem os possui e com que rapidez podemos revogá-los/rotacioná-los”, você terá passado de uma mera ilusão para um programa de defesa real.

A solução prática não é um scanner mágico. É um programa: minimize segredos estáticos, reduza privilégios, torne a rotação rotineira e monitore as identidades das máquinas como você monitora as contas de usuário.

Fontes

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...
o Português