Le identità non umane sono un motore di violazione: perché token e account di servizio continuano a essere esposti

/Tecnologia/ Di

Le identità non umane (chiavi API, token, account di servizio, identità dei carichi di lavoro) rappresentano oggi uno dei modi più semplici per accedere agli ambienti cloud moderni. Non perché gli aggressori siano diventati improvvisamente dei geni, ma perché le organizzazioni si basano sempre più sulla fiducia tra macchine, e questa fiducia è spesso troppo ampia, duratura e scarsamente monitorata.

Una nuova analisi evidenziata in un report evidenzia un modello familiare su larga scala: migliaia di immagini di container e repository espongono accidentalmente segreti che garantiscono silenziosamente l'accesso ai sistemi di produzione. Il problema non è solo che gli sviluppatori a volte commettono errori. Il problema è che gli strumenti e gli incentivi predefiniti lo rendono...facileper spedire segreti edifficileper dimostrare che non l'hai fatto.

Questa è una storia di "violazione invisibile". Molte compromissioni non iniziano con un exploit o un malware di forte impatto. Iniziano con un token che si autentica in modo pulito, quindi tutto sembra normale, finché non ci si rende conto che è stato utilizzato dal principale sbagliato.

Cosa sono le “identità non umane” (in parole povere)

Un'identità non umana (NHI) è una qualsiasi credenziale che consente al software di autenticarsi come attore attendibile:

  • chiavi di accesso al cloud e token di sessione
  • account di servizio e identità del carico di lavoro
  • Credenziali CI/CD utilizzate dalle pipeline di build
  • token per strumenti SaaS (GitHub, GitLab, Slack, piattaforme di monitoraggio)
  • Chiavi API per servizi di terze parti (fornitori di pagamento, fornitori di posta elettronica, API di modelli di intelligenza artificiale)

La differenza importante rispetto agli accessi umani è che gli NHI in genere:

  • funzionare continuamente
  • sono incorporati nel codice o nella configurazione
  • e spesso non usano MFA

Questo li rende attraenti.

Se un aggressore ottiene un token funzionante, non deve "introdursi". Deve solo autenticarsi.

Perché la situazione sta peggiorando

Tre tendenze stanno spingendo gli NHI da “rischi importanti” a “rischi dominanti”:

1) Le catene di fornitura del software sono più grandi che mai

Le app moderne sono assemblate da:

  • contenitori
  • dipendenze open source
  • infrastruttura come codice
  • decine di integrazioni SaaS

Ogni integrazione aggiunge un'ulteriore credenziale.

2) L'automazione è ovunque

Le organizzazioni vogliono:

  • distribuzioni più veloci
  • infrastruttura self-service
  • ambienti effimeri

L'automazione è positiva, ma è alimentata da identità dotate di privilegi.

3) Le credenziali durano più a lungo delle persone che le hanno create

Gli esseri umani cambiano ruolo e se ne vanno.

Ma un token in un repository o in un contenitore può:

  • persistono per mesi o anni
  • essere copiato nelle nuove build
  • e rimangono validi molto tempo dopo che qualcuno si ricorda che esiste

Quindi la superficie di attacco cresce silenziosamente.

Come i segreti trapelano nella vita reale (non è sempre "qualcuno ha commesso una chiave")

Lo stereotipo è uno sviluppatore che si impegnaAWS_SECRET_ACCESS_KEYsu GitHub.

Questo accade ancora. Ma molte perdite sono meno evidenti:

  • gettoni cotti in strati di contenitori
  • file di configurazione copiati nelle immagini durante la compilazione
  • registri di debug contenenti segreti
  • chiavi “temporanee” condivise in chat e successivamente incollate nel codice
  • Variabili CI stampate da pipeline non configurate correttamente

E le immagini dei contenitori sono particolarmente pericolose perché:

  • vengono specchiati
  • vengono memorizzati nella cache
  • vengono copiati tra i team

Anche se elimini la chiave dal repository, la chiave può rimanere nei vecchi livelli dell'immagine.

Perché i token trapelati sono più pericolosi di molti exploit

Gli exploit sono rumorosi e spesso attivano degli avvisi.

I token trapelati sono silenziosi. Spesso sembrano normali:

  • autenticazione riuscita
  • chiamate API corrette
  • endpoint legittimi

Ciò cambia il problema del difensore.

Invece di rilevare "un aggressore", è necessario rilevare:

  • un inaspettatoprincipaleutilizzando credenziali valide
  • da luoghi insoliti
  • in momenti insoliti
  • compiere azioni insolite

Ecco perché gli NHI rappresentano una lacuna nel rilevamento per molte organizzazioni.

Il problema dei privilegi: i token sono spesso troppo potenti

Molti segreti vengono creati come scorciatoie per "far funzionare le cose":

  • ampie autorizzazioni cloud
  • accesso API a livello di amministratore
  • chiavi di lunga durata

E una volta che il sistema funziona, la gente non vuole più toccarlo.

Ciò crea una pericolosa asimmetria:

  • un account umano potrebbe avere MFA e monitoraggio
  • l'identità della macchina potrebbe avere ampio accesso e poco controllo

Quando l'identità della macchina trapela, il raggio dell'esplosione può essere maggiore.

Come si presenta una buona strategia NHI (pratiche concrete)

Questo problema è risolvibile, ma solo se si considerano i fondi pensione nazionali come beni di prima classe.

1) Preferire credenziali di breve durata

Dove possibile:

  • utilizzare credenziali di sessione temporanee
  • ruotare frequentemente i token
  • evitare le chiavi "senza scadenza"

I token di breve durata riducono il guadagno derivante dalle perdite.

2) Sostituisci le chiavi statiche con l'identità del carico di lavoro dove puoi

Nelle moderne configurazioni cloud, spesso è possibile autenticare i carichi di lavoro tramite:

  • identità dell'istanza
  • Federazione OIDC
  • identità gestita

Ciò riduce la necessità di memorizzare chiavi statiche.

3) Separare rigorosamente gli ambienti

Un errore comune è l'utilizzo dello stesso token su:

  • sviluppatore
  • messa in scena
  • produzione

I token devono avere un ambito ambientale.

Se un'immagine di sviluppo viene divulgata, non dovrebbe sbloccare la produzione.

4) Inventario e proprietà

Ogni token significativo dovrebbe avere:

  • un proprietario
  • uno scopo
  • un modello di utilizzo previsto

Se un token non ha un proprietario, si tratta di un debito tecnico in attesa di trasformarsi in un incidente.

5) Monitorare il comportamento NHI come si monitora il comportamento umano

I buoni segnali includono:

  • viaggi impossibili / geografie insolite
  • sequenze di chiamate API insolite
  • picchi nell'accesso ai dati
  • nuovi permessi concessi
  • nuovi token creati

L'obiettivo non è la rilevazione perfetta, ma la rilevazione precoce.

6) Trattare CI/CD come una fabbrica di identità ad alto rischio

I sistemi CI contengono spesso:

  • chiavi di distribuzione
  • chiavi di firma
  • credenziali cloud

Bloccali:

  • minimo privilegio
  • corridori separati
  • mascheramento segreto e prevenzione delle perdite di log
  • rigorose approvazioni per le fasi di distribuzione della produzione

Dove solitamente falliscono i team (e come evitarlo)

"A volte ruotiamo le chiavi" non è un piano

Se la rotazione è manuale e dolorosa, non avverrà sotto pressione.

Rendere la rotazione una routine e automatizzarla.

Gli strumenti di sicurezza senza applicazione diventano “teatro di monitoraggio”

La scansione dei repository alla ricerca di segreti è utile, ma non sufficiente.

Ti serviranno anche:

  • revoca rapida
  • avvisi sull'utilizzo
  • e prevenzione nelle pipeline di costruzione

La trappola dello strato del contenitore

Se i segreti sono mai entrati nel contesto di compilazione di un contenitore, si presuppone che possano esistere in:

  • vecchie immagini
  • livelli memorizzati nella cache
  • Artefatti CI

La soluzione non è solo "eliminare la chiave del repository". È:

  • ruota il segreto
  • ricostruire e ripubblicare le immagini
  • invalidare le cache ove possibile

Cosa guardare dopo

Se vuoi verificare se le organizzazioni stanno migliorando i propri NHI, cerca:

  • adozione di identità di breve durata (identità OIDC/workload)
  • programmi di rotazione dei token diffusi
  • controlli più rigorosi dei confini CI/CD
  • rapporti di incidenti che riconoscono come causa primaria "credenziali valide utilizzate"

Prestate attenzione anche all'aspetto degli strumenti: gli strumenti migliori passeranno dal "rilevare stringhe esposte" al "ridurre il numero di segreti statici esistenti".

L'economia: perché gli aggressori amano la caccia ai token

Bilance per la caccia ai gettoni.

Un aggressore che ruba una credenziale di lavoro può spesso:

  • accedere a più sistemi (cloud + controllo sorgente + CI)
  • riutilizzare la stessa tecnica in molte organizzazioni
  • e vendere l'accesso nei marketplace se non vogliono gestirlo da soli

Per chi si occupa di difesa, questo significa che la minaccia non è semplicemente "un hacker che ci prende di mira". È "un'economia delle macchine che trae profitto da qualsiasi credenziale riutilizzabile".

Ecco perché la prevenzione è più importante della risposta. Se la chiave non è mai esistita in forma statica, non può essere raccolta in seguito.

Idee concrete per il rilevamento (su cosa allertare)

Se stai sviluppando rilevamenti per NHI, concentrati sui cambiamenti comportamentali piuttosto che su parole chiave magiche.

Esempi di segnale elevato:

  • Un account di servizio utilizzato da unnuovo paese/ASNnon è mai stato utilizzato prima.
  • Un token che normalmente chiama una sola API improvvisamente enumera risorse o scarica grandi volumi.
  • Un'identità CI che esegue azioni al di fuori della normale finestra di rilascio.
  • Segreti utilizzati dagli endpoint utente interattivi quando erano destinati solo ai carichi di lavoro del server.

Anche gli avvisi di anomalie di base possono individuare in anticipo il fenomeno del "furto silenzioso di credenziali".

Idee per l'indurimento del calcestruzzo (basso sforzo, alta leva)

Si tratta di cambiamenti pratici che la maggior parte dei team può apportare senza dover riprogettare radicalmente:

  • Ridurre l'ambito del token: dividere un token ampio in più token con ambito ristretto.
  • Ruotare secondo il programma: ruotare anche quando non c'è nulla di "sbagliato", quindi la rotazione diventa memoria muscolare.
  • Produzione di cancelli: richiedono l'approvazione esplicita per le identità di distribuzione in produzione.
  • Blocca i segreti in chiaro nelle build: La CI dovrebbe fallire le build quando compaiono evidenti schemi segreti.

Ogni spostamento riduce il raggio dell'esplosione, anche se si verifica comunque una perdita.

Una semplice politica interna che previene molto dolore

Se si desidera una politica che imponga un comportamento migliore, questa è:

  • Nessun segreto produttivo nei laptop degli sviluppatori o nei contesti di compilazione dei container.

Questa regola determina cambiamenti come:

  • identità del carico di lavoro per i servizi
  • credenziali di staging per lo sviluppo
  • e approvazioni esplicite per le fasi di distribuzione della produzione

All'inizio può essere fastidioso, ma blocca le vie di fuga più facili.

In conclusione

Le identità non umane sono la spina dorsale dell'automazione moderna e anche una delle principali cause di violazioni, perché spesso aggirano le protezioni che abbiamo creato per gli esseri umani.

Se vuoi una soglia pratica: una volta che puoi rispondere "dove vivono i nostri token di lunga durata, chi li possiede e quanto velocemente possiamo revocarli/ruotarli", sei passato da un pio desiderio a un vero e proprio programma di difesa.

La soluzione pratica non è uno scanner magico. È un programma: minimizza i segreti statici, riduci i privilegi, crea una routine di rotazione e monitora le identità delle macchine come si monitorano gli account utente.

Fonti

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...
t Italiano