Identitățile non-umane sunt un motor al breșelor de securitate: de ce token-urile și conturile de servicii sunt în continuare expuse

/Tehnologie/ De

Identitățile non-umane — cheile API, token-urile, conturile de serviciu, identitățile sarcinilor de lucru — reprezintă acum una dintre cele mai ușoare căi de acces către mediile cloud moderne. Nu pentru că atacatorii au devenit brusc genii, ci pentru că organizațiile funcționează din ce în ce mai mult pe baza încrederii intermașină (machine-to-machine), iar această încredere este adesea prea extinsă, de lungă durată și slab monitorizată.

O nouă analiză evidențiată în raport indică un tipar familiar la scară largă: mii de imagini de containere și depozite expun accidental secrete care acordă în mod discret acces la sistemele de producție. Problema nu este doar că dezvoltatorii fac uneori greșeli. Problema este că instrumentele și stimulentele implicite fac ca...uşorsă expedieze secrete șigreuca să dovedești că nu ai făcut-o.

Aceasta este o poveste despre o „breșă invizibilă”. Multe compromisuri nu vor începe cu o exploatare sau un eveniment malware zgomotos. Vor începe cu un token care se autentifică în mod curat - astfel încât totul arată normal - până când îți dai seama că l-a folosit principalul greșit.

Ce sunt „identitățile non-umane” (în termeni simpli)

O identitate non-umană (NHI) este orice acreditare care permite unui software să se autentifice ca actor de încredere:

  • chei de acces la cloud și token-uri de sesiune
  • conturi de serviciu și identități de lucru
  • Acreditări CI/CD utilizate de conductele de compilare
  • token-uri pentru instrumente SaaS (GitHub, GitLab, Slack, platforme de monitorizare)
  • Chei API pentru servicii terțe (furnizori de plăți, furnizori de e-mail, API-uri pentru modele de inteligență artificială)

Diferența importantă față de autentificările umane este că NHI-urile de obicei:

  • rulează continuu
  • sunt încorporate în cod sau configurație
  • și adesea nu utilizează MFA

Asta le face atractive.

Dacă un atacator obține un token funcțional, nu trebuie să „intră prin efracție”. Se autentifică.

De ce se înrăutățește situația acum

Trei tendințe împing instituțiile naționale de sănătate (CNS) de la „importante” la „risc dominant”:

1) Lanțurile de aprovizionare cu software sunt mai mari ca niciodată

Aplicațiile moderne sunt asamblate din:

  • containere
  • dependențe open-source
  • infrastructură-ca-cod
  • zeci de integrări SaaS

Fiecare integrare adaugă o altă acreditare.

2) Automatizarea este peste tot

Organizațiile își doresc:

  • implementări mai rapide
  • infrastructură de autoservire
  • medii efemere

Automatizarea este bună, dar este susținută de identități care au privilegii.

3) Acreditările durează mai mult decât persoanele care le-au creat

Oamenii își schimbă rolurile și pleacă.

Însă un token dintr-un depozit sau container poate:

  • persistă luni sau ani
  • să fie copiate în versiuni noi
  • și rămân valabile mult timp după ce cineva își amintește că există

Deci suprafața de atac crește în tăcere.

Cum se scurg secretele în viața reală (nu este întotdeauna vorba despre „cineva a compromis o cheie”)

Stereotipul este un dezvoltator care se angajeazăAWS_SECRET_ACCESS_KEYcătre GitHub.

Asta se mai întâmplă. Dar multe scurgeri sunt mai puțin evidente:

  • jetoane integrate în straturi de containere
  • fișierele de configurare copiate în imagini în timpul construcției
  • jurnale de depanare care conțin secrete
  • chei „temporare” partajate în chat și ulterior lipite în cod
  • Variabile CI afișate de conducte configurate greșit

Și imaginile containerelor sunt deosebit de periculoase deoarece:

  • se oglindesc
  • acestea sunt stocate în cache
  • sunt copiați între echipe

Chiar dacă ștergeți cheia din depozit, aceasta poate rămâne în straturile vechi de imagine.

De ce token-urile scurse sunt mai periculoase decât multe exploatări

Exploit-urile sunt zgomotoase. Adesea declanșează alerte.

Jetoanele scurse sunt silențioase. Adesea arată ca o utilizare normală:

  • autentificare reușită
  • apeluri API corecte
  • puncte finale legitime

Asta schimbă problema fundașului.

În loc să detectezi „un atacator”, trebuie să detectezi:

  • un lucru neașteptatprincipalfolosind acreditări valide
  • din locații neobișnuite
  • în momente neobișnuite
  • făcând acțiuni neobișnuite

Acesta este motivul pentru care NHI-urile reprezintă o lacună în detectarea datelor pentru multe organizații.

Problema privilegiilor: token-urile sunt adesea prea puternice

Multe secrete sunt create ca scurtături pentru a „face lucrurile să funcționeze”:

  • permisiuni extinse în cloud
  • acces API la nivel de administrator
  • chei cu durată lungă de viață

Și odată ce sistemul funcționează, oamenii nu vor mai vrea să se atingă de el.

Aceasta creează o asimetrie periculoasă:

  • un cont uman ar putea avea MFA și monitorizare
  • identitatea mașinii ar putea avea acces larg și puțin control

Când identitatea mașinii se scurge, raza exploziei poate fi mai mare.

Cum arată o strategie NHI bună (practici concrete)

Această problemă este rezolvabilă, dar numai dacă tratați NHI-urile ca active de securitate de primă clasă.

1) Preferă acreditări de scurtă durată

Unde este posibil:

  • utilizați acreditări temporare de sesiune
  • rotiți jetoanele frecvent
  • evitați cheile „nu expiră niciodată”

Jetoanele cu durată scurtă de viață reduc beneficiile scurgerilor de informații.

2) Înlocuiți cheile statice cu identitatea sarcinii de lucru acolo unde este posibil

În configurațiile cloud moderne, puteți autentifica adesea sarcinile de lucru prin:

  • identitatea instanței
  • Federația OIDC
  • identitate gestionată

Acest lucru reduce nevoia de a stoca chei statice.

3) Separați strict mediile

O eroare frecventă este utilizarea aceluiași token în:

  • dezvoltator
  • punere în scenă
  • producție

Jetoanele ar trebui să fie în domeniul de aplicare al mediului.

Dacă o imagine de dezvoltator este scursă, nu ar trebui să deblocheze produsul.

4) Inventar și proprietate

Fiecare token semnificativ ar trebui să aibă:

  • un proprietar
  • un scop
  • un model de utilizare așteptat

Dacă un token nu are proprietar, este o datorie tehnică care așteaptă să devină un incident.

5) Monitorizați comportamentul NHI așa cum monitorizați comportamentul uman

Semnalele bune includ:

  • călătorii imposibile / geografii neobișnuite
  • Secvențe neobișnuite de apeluri API
  • creșteri bruște ale accesului la date
  • noi permisiuni acordate
  • token-uri noi create

Scopul nu este detectarea perfectă; ci detectarea timpurie.

6) Tratați CI/CD ca o fabrică de identități cu risc ridicat

Sistemele CI dețin frecvent:

  • chei de implementare
  • chei de semnare
  • acreditări în cloud

Închide-i:

  • cel mai mic privilegiu
  • alergători separați
  • mascare secretă și prevenirea scurgerilor de jurnal
  • aprobări stricte pentru etapele de implementare în producție

Unde echipele eșuează de obicei (și cum să eviți acest lucru)

„Rotim cheile uneori” nu este un plan

Dacă rotația este manuală și dureroasă, nu se va întâmpla sub presiune.

Faceți rotația o rutină și o automatizați.

Instrumentele de securitate fără aplicarea legii devin „teatru de monitorizare”

Scanarea depozitelor pentru secrete este utilă, dar nu este suficientă.

De asemenea, aveți nevoie de:

  • revocare rapidă
  • alerte privind utilizarea
  • și prevenție în conductele de construcție

Capcana stratului containerului

Dacă secretele au intrat vreodată într-un context de construire a containerului, presupunem că acestea ar putea exista în:

  • imagini vechi
  • straturi memorate în cache
  • Artefacte CI

Remedierea nu este doar „ștergerea cheii repo”. Este vorba despre:

  • rotește secretul
  • reconstruiește și republică imagini
  • invalidați cache-urile acolo unde este posibil

Ce să urmărești în continuare

Dacă doriți să urmăriți dacă organizațiile își îmbunătățesc INS-urile, căutați:

  • adoptarea unei identități pe termen scurt (identitate OIDC/workload)
  • programe extinse de rotație a tokenurilor
  • controale mai puternice ale limitelor CI/CD
  • rapoarte de incident care recunosc „utilizarea acreditărilor valide” ca cauză principală

De asemenea, fiți atenți la aspectul instrumentelor: cele mai bune instrumente se vor schimba de la „detectarea șirurilor expuse” la „reducerea numărului de secrete statice care există”.

Economia: de ce atacatorii iubesc vânătoarea de tokenuri

Cântare pentru vânătoarea de jetoane.

Un atacator care fură o acreditări funcționale poate adesea:

  • acces la mai multe sisteme (cloud + controlul sursei + CI)
  • reutilizarea aceleiași tehnici în mai multe organizații
  • și să vândă acces în piețe dacă nu doresc să îl administreze singuri

Pentru apărători, asta înseamnă că amenințarea nu este doar „un hacker care ne vizează”. Este „o economie automată care profită de orice acreditări reutilizabile”.

De aceea, prevenția este mai valoroasă aici decât răspunsul. Dacă cheia nu a existat niciodată în formă statică, nu poate fi colectată ulterior.

Idei pentru detectarea betonului (la ce să se alerteze)

Dacă construiți detectări pentru NHI-uri, concentrați-vă pe schimbările de comportament, mai degrabă decât pe cuvinte cheie magice.

Exemple de semnal înalt:

  • Un cont de serviciu utilizat dintr-unțară nouă/ASNnu a mai fost folosit niciodată înainte.
  • Un token care în mod normal apelează o singură API enumeră brusc resurse sau descarcă volume mari.
  • O identitate CI care efectuează acțiuni în afara ferestrei normale de lansare.
  • Secrete utilizate de la endpoint-urile interactive ale utilizatorilor atunci când erau destinate exclusiv sarcinilor de lucru ale serverului.

Chiar și alertele de anomalie de bază pot detecta din timp modelul de „furt discret de acreditări”.

Idei pentru întărirea betonului (efort redus, efect de levier ridicat)

Acestea sunt schimbări practice pe care majoritatea echipelor le pot face fără o reproiectare masivă:

  • Reduceți domeniul de aplicare al tokenului: împarte un token larg în mai multe token-uri cu domeniu de aplicare restrâns.
  • Rotiți conform programului: se rotește chiar și atunci când nimic nu este „în neregulă”, astfel încât rotația devine memorie musculară.
  • Producția de porți: necesită aprobare explicită pentru identitățile de implementare în producție.
  • Blocarea secretelor în text simplu în versiuniCI ar trebui să eșueze construcțiile atunci când apar tipare secrete evidente.

Fiecare mișcare micșorează raza exploziei chiar dacă apare în continuare o scurgere.

O politică internă simplă care previne multă durere

Dacă vrei o politică care să impună un comportament mai bun, aceasta este:

  • Nu există secrete capabile de producție în laptopurile dezvoltatorilor sau în contextele de construire a containerelor.

Această regulă determină schimbări precum:

  • identitatea sarcinii de lucru pentru servicii
  • acreditări de pregătire pentru dezvoltare
  • și aprobări explicite pentru etapele de implementare în producție

E enervant la început, dar taie cele mai ușoare căi de scurgere.

Concluzie

Identitățile non-umane sunt coloana vertebrală a automatizării moderne - și, de asemenea, un factor major de breșă de securitate, deoarece adesea ocolesc protecțiile pe care le-am construit pentru oameni.

Dacă vrei un prag practic: odată ce poți răspunde la întrebarea „unde se află token-urile noastre cu durată lungă de viață, cine le deține și cât de repede le putem revoca/rota”, ai trecut de la o gândire iluzorie la un program de apărare real.

Soluția practică nu este un scaner magic. Este un program: minimizează secretele statice, redu privilegiile, transformă rotația în rutină și monitorizează identitățile mașinilor așa cum monitorizezi conturile de utilizator.

Surse

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 Română