Nečloveške identitete so gonilna sila vdorov: zakaj so žetoni in računi storitev vedno znova izpostavljeni

/Tehnologija/ Avtor

Nečloveške identitete – ključi API-jev, žetoni, računi storitev, identitete delovnih obremenitev – so zdaj eden najlažjih načinov za vstop v sodobna oblačna okolja. Ne zato, ker bi napadalci nenadoma postali geniji, ampak zato, ker organizacije vse bolj delujejo na zaupanju med stroji, to zaupanje pa je pogosto preširoko, dolgotrajno in slabo nadzorovano.

Nova analiza, izpostavljena v poročilih, kaže na znan vzorec v velikem obsegu: na tisoče slik vsebnikov in repozitorijev po nesreči razkrije skrivnosti, ki neopazno omogočajo dostop do produkcijskih sistemov. Težava ni le v tem, da razvijalci včasih delajo napake. Težava je v tem, da privzeta orodja in spodbude to otežujejo.enostavnopošiljati skrivnosti intrdoda dokažeš, da nisi.

To je zgodba o »nevidni kršitvi«. Številne vdorne škode se ne začnejo z izkoriščanjem ali glasnim dogodkom zlonamerne programske opreme. Začnejo se z žetonom, ki se nemoteno overi – tako da je vse videti normalno – dokler ne ugotovite, da ga uporablja napačen principal.

Kaj so »nečloveške identitete« (preprosto povedano)

Nečloveška identiteta (NHI) je katera koli poverilnica, ki programski opremi omogoča overjanje kot zaupanja vrednega akterja:

  • ključi za dostop do oblaka in žetoni seje
  • računi storitev in identitete delovnih obremenitev
  • Poverilnice CI/CD, ki jih uporabljajo cevovodi gradnje
  • žetoni za orodja SaaS (GitHub, GitLab, Slack, platforme za spremljanje)
  • Ključi API-jev za storitve tretjih oseb (ponudniki plačilnih storitev, ponudniki e-pošte, API-ji modelov umetne inteligence)

Pomembna razlika od človeških prijav je, da NHI običajno:

  • teči neprekinjeno
  • so vdelani v kodo ali konfiguracijo
  • in pogosto ne uporabljajo MFA

To jih dela privlačne.

Če napadalec pridobi delujoč žeton, mu ni treba "vdreti". Omogoča avtentikacijo.

Zakaj se to zdaj slabša

Trije trendi spodbujajo razvoj NHI iz kategorije »pomembnih« v kategorijo »prevladujoče tveganje«:

1) Dobavne verige programske opreme so večje kot kdaj koli prej

Sodobne aplikacije so sestavljene iz:

  • posode
  • odvisnosti od odprte kode
  • infrastruktura-kot-koda
  • na desetine SaaS integracij

Vsaka integracija doda še eno poverilnico.

2) Avtomatizacija je povsod

Organizacije želijo:

  • hitrejše uvajanje
  • infrastruktura samopostrežbe
  • minljiva okolja

Avtomatizacija je dobra – vendar jo poganjajo identitete s privilegiji.

3) Poverilnice trajajo dlje kot ljudje, ki so jih ustvarili

Ljudje zamenjajo vloge in odidejo.

Žeton v repozitoriju ali vsebniku pa lahko:

  • vztrajajo mesece ali leta
  • kopirati v nove gradnje
  • in ostanejo veljavni še dolgo potem, ko se kdorkoli spomni njihovega obstoja

Torej površina napada raste tiho.

Kako skrivnosti uhajajo v resničnem življenju (ni vedno "nekdo je posredoval ključ")

Stereotip je razvijalec, ki se zavezujeAWS_SECRET_ACCESS_KEYna GitHub.

To se še vedno dogaja. Vendar je veliko puščanja manj očitno:

  • žetoni, vpeti v plasti vsebnika
  • konfiguracijske datoteke, kopirane v slike med gradnjo
  • dnevniki odpravljanja napak, ki vsebujejo skrivnosti
  • »začasni« ključi, deljeni v klepetu in kasneje prilepljeni v kodo
  • Spremenljivke CI, ki jih natisnejo napačno konfigurirani cevovodi

In slike vsebnikov so še posebej nevarne, ker:

  • zrcalijo se
  • shranijo se v predpomnilnik
  • kopirajo se med ekipami

Tudi če ključ izbrišete iz repozitorija, lahko ostane v starih slojih slike.

Zakaj so razkriti žetoni bolj nevarni kot številne zlorabe

Izkoriščanje je hrupno. Pogosto sproži opozorila.

Razkriti žetoni so tihi. Pogosto so videti kot običajna uporaba:

  • uspešno preverjanje pristnosti
  • pravilni klici API-ja
  • legitimne končne točke

To spremeni problem branilca.

Namesto odkrivanja "napadalca" morate odkriti:

  • nepričakovanoravnateljz uporabo veljavnih poverilnic
  • z nenavadnih lokacij
  • ob nenavadnih časih
  • izvaja nenavadna dejanja

Zato so NHI za številne organizacije vrzel v odkrivanju.

Problem privilegijev: žetoni so pogosto premočni

Veliko skrivnosti je ustvarjenih kot bližnjice za »zagon«:

  • široka dovoljenja za oblak
  • dostop do API-ja na administratorski ravni
  • dolgoživi ključi

In ko sistem enkrat deluje, se ga ljudje nočejo več dotikati.

To ustvarja nevarno asimetrijo:

  • Človeški račun ima lahko večfaktorsko preverjanje in spremljanje
  • identiteta stroja ima lahko širok dostop in malo nadzora

Ko identiteta stroja uide, je lahko polmer eksplozije večji.

Kako izgleda dobra strategija NHI (konkretne prakse)

To je rešljivo, vendar le, če z NHI ravnate kot s prvovrstnimi varnostnimi sredstvi.

1) Prednost imajo kratkotrajne poverilnice

Kjer je mogoče:

  • uporabite začasne poverilnice seje
  • pogosto menjajte žetone
  • Izogibajte se ključem »never expires«

Kratkotrajni žetoni zmanjšujejo izplačilo puščanja informacij.

2) Kjer je mogoče, zamenjajte statične ključe z identiteto delovne obremenitve

V sodobnih nastavitvah v oblaku lahko delovne obremenitve pogosto overite prek:

  • identiteta primerka
  • Zveza OIDC
  • upravljana identiteta

To zmanjša potrebo po shranjevanju statičnih ključev.

3) Strogo ločite okolja

Pogosta napaka je uporaba istega žetona v:

  • razvijalec
  • uprizoritev
  • proizvodnja

Žetoni morajo biti omejeni na okolje.

Če razvojna slika pušča, ne bi smela odkleniti produkcijske različice.

4) Zaloge in lastništvo

Vsak smiseln žeton mora imeti:

  • lastnik
  • namen
  • pričakovan vzorec uporabe

Če žeton nima lastnika, gre za tehnični dolg, ki čaka, da postane incident.

5) Spremljajte vedenje NHI, tako kot spremljate vedenje ljudi

Dobri signali vključujejo:

  • nemogoča potovanja / nenavadne geografske lokacije
  • nenavadna zaporedja klicev API-ja
  • porast dostopa do podatkov
  • nova dovoljenja odobrena
  • ustvarjeni novi žetoni

Cilj ni popolno odkrivanje, temveč zgodnje odkrivanje.

6) Obravnavajte CI/CD kot tovarno identitet z visokim tveganjem

Sistemi CI pogosto vsebujejo:

  • ključi za uvajanje
  • podpisni ključi
  • poverilnice v oblaku

Zaklenite jih:

  • najmanj privilegijev
  • ločeni tekači
  • skrivno maskiranje in preprečevanje puščanja dnevnikov
  • stroge odobritve za korake uvajanja v produkcijo

Kje ekipe običajno odpovejo (in kako se temu izogniti)

"Včasih menjamo ključe" ni načrt

Če je rotacija ročna in boleča, se ne bo zgodila pod pritiskom.

Naj bo rotacija rutinska in avtomatizirana.

Varnostna orodja brez izvrševanja postanejo »gledališče nadzora«

Skeniranje repozitorijev za skrivnosti je koristno, vendar ni dovolj.

Potrebujete tudi:

  • hitra razveljavitev
  • opozorila o uporabi
  • in preprečevanje pri gradnji cevovodov

Past plasti kontejnerja

Če so skrivnosti kdaj vstopile v kontekst gradnje vsebnika, predpostavimo, da morda obstajajo v:

  • stare slike
  • predpomnjene plasti
  • Artefakti CI

Rešitev ni samo "izbris ključa repozitorija". Gre za:

  • zavrti skrivnost
  • obnovi in ​​ponovno objavi slike
  • razveljavi predpomnilnike, kjer je to mogoče

Kaj si ogledati naprej

Če želite spremljati, ali organizacije izboljšujejo svoje NHI, poiščite:

  • sprejetje kratkotrajne identitete (OIDC/identiteta delovne obremenitve)
  • razširjeni programi rotacije žetonov
  • močnejši nadzor meja CI/CD
  • poročila o incidentih, ki kot glavni vzrok navajajo »uporabo veljavnih poverilnic«

Bodite pozorni tudi na orodjarstvo: najboljša orodja se bodo preusmerila od »zaznavanja izpostavljenih nizov« k »zmanjševanju števila statičnih skrivnosti, ki sploh obstajajo«.

Ekonomija: zakaj napadalci obožujejo lov na žetone

Tehtnice za lov na žetone.

Napadalec, ki ukrade eno delujočo poverilnico, lahko pogosto:

  • dostop do več sistemov (oblak + nadzor vira + neposredna integracijska rešitev)
  • ponovno uporabite isto tehniko v številnih organizacijah
  • in prodajajo dostop na tržnicah, če ga ne želijo upravljati sami

Za zagovornike to pomeni, da grožnja ni le »heker, ki cilja na nas«. Gre za »strojno gospodarstvo, ki ima koristi od vsake poverilnice za večkratno uporabo«.

Zato je preprečevanje tukaj bolj dragoceno kot odzivanje. Če ključ nikoli ni obstajal v statični obliki, ga kasneje ni mogoče pridobiti.

Ideje za odkrivanje betona (na kaj opozoriti)

Če gradite zaznave za NHI, se osredotočite na spremembe vedenja in ne na čarobne ključne besede.

Primeri visokega signala:

  • Storitveni račun, ki se uporablja iznova država/ASNnikoli prej ni bil uporabljen.
  • Žeton, ki običajno kliče samo en API, nenadoma našteje vire ali prenese velike količine.
  • Identiteta CI, ki izvaja dejanja zunaj običajnega okna izdaje.
  • Skrivnosti, uporabljene iz interaktivnih uporabniških končnih točk, ko so bile namenjene le delovnim obremenitvam strežnika.

Že osnovna opozorila o anomalijah lahko zgodaj zaznajo vzorec »tihe kraje poverilnic«.

Ideje za utrjevanje betona (malo truda, veliko vzvoda)

To so praktične spremembe, ki jih lahko večina ekip izvede brez obsežne prenove:

  • Zmanjšajte obseg žetonov: razdeli en širok žeton na več žetonov z ozkim obsegom.
  • Rotirajte po urniku: vrtite se, tudi ko ni nič "narobe", zato rotacija postane mišični spomin.
  • Proizvodnja vrat: zahteva izrecno odobritev za identitete uvajanja v produkciji.
  • Blokiraj skrivne besedilne kode v graditvah: CI bi moral spodleteti pri gradnji, ko se pojavijo očitni skriti vzorci.

Vsak premik zmanjša polmer eksplozije, tudi če še vedno pride do puščanja.

Preprosta notranja politika, ki preprečuje veliko težav

Če želite eno politiko, ki sili k boljšemu vedenju, je to ta:

  • V prenosnikih razvijalcev ali v kontekstih gradnje vsebnikov ni skrivnosti, ki bi omogočale produkcijo.

To pravilo povzroča spremembe, kot so:

  • identiteta delovne obremenitve za storitve
  • poverilnice za pripravo na razvoj
  • in izrecne odobritve za korake uvajanja v produkcijo

Na začetku je nadležno, vendar prekine najlažje poti puščanja.

Bistvo

Nečloveške identitete so hrbtenica sodobne avtomatizacije – in tudi pomemben dejavnik kršitev, saj pogosto zaobidejo zaščite, ki smo jih zgradili za ljudi.

Če želite praktičen prag: ko lahko odgovorite na vprašanja »kje živijo naši dolgoživi žetoni, kdo je njihov lastnik in kako hitro jih lahko prekličemo/zamenjamo«, ste prešli iz pobožnih želja v resničen obrambni program.

Praktična rešitev ni en sam čarobni skener. Gre za program: zmanjšajte statične skrivnosti, skrčite privilegije, vzpostavite rutino rotacije in spremljajte identitete računalnikov, tako kot spremljate uporabniške račune.

Viri

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...
l Slovenščina