Neľudské identity sú motorom narušenia: prečo sú tokeny a servisné účty neustále odhaľované

/Technológia/ Od

Neľudské identity – kľúče API, tokeny, servisné účty, identity pracovných záťaží – sú teraz jednou z najjednoduchších ciest do moderných cloudových prostredí. Nie preto, že by sa útočníci zrazu stali géniami, ale preto, že organizácie čoraz viac fungujú na dôvere medzi strojmi a táto dôvera je často príliš široká, dlhotrvajúca a zle monitorovaná.

Nová analýza zdôraznená v správe poukazuje na známy vzorec vo veľkom meradle: tisíce obrazov kontajnerov a repozitárov náhodne odhaľujú tajomstvá, ktoré nenápadne poskytujú prístup k produkčným systémom. Problém nie je len v tom, že vývojári niekedy robia chyby. Problém je v tom, že predvolené nástroje a stimuly to robia...ľahképosielať tajomstvá atvrdýaby si dokázal, že si to neurobil.

Toto je príbeh o „neviditeľnom narušení“. Mnohé kompromisy nezačnú zneužitím alebo hlučnou udalosťou škodlivého softvéru. Začnú tokenom, ktorý sa autentifikuje čisto – takže všetko vyzerá normálne – až kým si neuvedomíte, že ho používa nesprávny principál.

Čo sú to „neľudské identity“ (jednoducho povedané)

Neľudská identita (NHI) je akékoľvek poverenie, ktoré umožňuje softvéru overiť sa ako dôveryhodný aktér:

  • prístupové kľúče do cloudu a tokeny relácie
  • servisné účty a identity pracovných zaťažení
  • Prihlasovacie údaje CI/CD používané kanálmi zostavovania
  • tokeny pre SaaS nástroje (GitHub, GitLab, Slack, monitorovacie platformy)
  • Kľúče API pre služby tretích strán (poskytovatelia platieb, poskytovatelia e-mailov, API modelov AI)

Dôležitý rozdiel oproti ľudskému prihláseniu je, že NHI zvyčajne:

  • bežať nepretržite
  • sú vložené do kódu alebo konfigurácie
  • a často nepoužívajú MFA

To ich robí atraktívnymi.

Ak útočník získa funkčný token, nemusí sa „vlámať“. Autentifikuje sa.

Prečo sa to teraz zhoršuje

Tri trendy posúvajú NHI z pozície „dôležité“ na „dominantné riziko“:

1) Dodávateľské reťazce softvéru sú väčšie ako kedykoľvek predtým

Moderné aplikácie sú zostavené z:

  • kontajnery
  • závislosti od open-source
  • infraštruktúra ako kód
  • desiatky SaaS integrácií

Každá integrácia pridáva ďalšie poverenie.

2) Automatizácia je všade

Organizácie chcú:

  • rýchlejšie nasadenie
  • infraštruktúra samoobsluhy
  • prchavé prostredia

Automatizácia je dobrá – ale je poháňaná identitami, ktoré majú privilégiá.

3) Poverenia trvajú dlhšie ako ľudia, ktorí ich vytvorili

Ľudia menia úlohy a odchádzajú.

Token v repozitári alebo kontajneri však môže:

  • pretrvávajú mesiace alebo roky
  • skopírovať do nových zostavení
  • a zostávajú platné dlho potom, čo si niekto spomenie na ich existenciu

Takže útočná plocha rastie potichu.

Ako tajomstvá unikajú v reálnom živote (nie vždy ide o „niekto, kto zverejnil kľúč“)

Stereotyp je vývojár, ktorý sa zaväzujeAWS_SECRET_ACCESS_KEYna GitHub.

To sa stále stáva. Ale veľa únikov je menej zjavných:

  • tokeny zapečené do vrstiev kontajnerov
  • konfiguračné súbory skopírované do obrázkov počas zostavovania
  • ladiace protokoly obsahujúce tajné kódy
  • „dočasné“ kľúče zdieľané v chate a neskôr vložené do kódu
  • Premenné CI vytlačené nesprávne nakonfigurovanými kanálmi

A obrázky kontajnerov sú obzvlášť nebezpečné, pretože:

  • zrkadlia sa
  • ukladajú sa do vyrovnávacej pamäte
  • kopírujú sa medzi tímami

Aj keď kľúč z repozitára odstránite, môže zostať v starých vrstvách obrázka.

Prečo sú uniknuté tokeny nebezpečnejšie ako mnohé iné exploity

Zneužitie je hlučné. Často spúšťa upozornenia.

Uniknuté tokeny sú tiché. Často vyzerajú ako bežné používanie:

  • úspešné overenie
  • správne volania API
  • legitímne koncové body

To mení problém obrancu.

Namiesto odhaľovania „útočníka“ musíte odhaliť:

  • neočakávanériaditeľs použitím platných prihlasovacích údajov
  • z nezvyčajných miest
  • v nezvyčajných časoch
  • vykonávanie nezvyčajných akcií

Preto sú NHI pre mnohé organizácie detekčnou medzerou.

Problém s privilégiami: tokeny sú často príliš silné

Veľa tajomstiev je vytvorených ako skratky na „spustenie“:

  • široké cloudové povolenia
  • prístup k API na úrovni správcu
  • kľúče s dlhou životnosťou

A keď systém funguje, ľudia sa ho nechcú ani dotknúť.

To vytvára nebezpečnú asymetriu:

  • ľudský účet môže mať viacfaktorovú autentifikáciu a monitorovanie
  • identita stroja môže mať široký prístup a malú kontrolu

Keď unikne identita stroja, polomer výbuchu môže byť väčší.

Ako vyzerá dobrá stratégia NHI (konkrétne postupy)

Toto je riešiteľné, ale iba ak sa k NHI správate ako k prvotriednym bezpečnostným aktívam.

1) Uprednostňujte krátkodobé poverenia

Kde je to možné:

  • použiť dočasné prihlasovacie údaje k relácii
  • často striedajte žetóny
  • vyhnite sa kľúčom s „nekonečnou platnosťou“

Krátkodobé tokeny znižujú výnos z únikov.

2) Nahraďte statické kľúče identitou pracovnej záťaže, kde je to možné

V moderných cloudových nastaveniach môžete často overovať pracovné zaťaženia prostredníctvom:

  • identita inštancie
  • Federácia OIDC
  • spravovaná identita

To znižuje potrebu ukladať statické kľúče.

3) Prísne oddeľte prostredia

Bežnou chybou je použitie rovnakého tokenu naprieč:

  • vývojár
  • inscenácia
  • výroba

Tokeny by mali byť obmedzené na prostredie.

Ak unikne vývojársky obraz, nemal by odomknúť produkčnú verziu.

4) Zásoby a vlastníctvo

Každý zmysluplný token by mal mať:

  • majiteľ
  • účel
  • očakávaný vzorec používania

Ak token nemá vlastníka, ide o technický dlh, ktorý čaká na to, aby sa stal incidentom.

5) Monitorujte správanie NHI rovnako ako monitorujete ľudské správanie

Medzi dobré signály patria:

  • nemožné cestovanie / nezvyčajné zemepisné oblasti
  • nezvyčajné sekvencie volaní API
  • prudké nárasty v prístupe k údajom
  • nové udelené povolenia
  • vytvorené nové tokeny

Cieľom nie je dokonalá detekcia; ide o včasnú detekciu.

6) Zaobchádzajte s CI/CD ako s továrňou na identitu s vysokým rizikom

Systémy CI často obsahujú:

  • kľúče nasadenia
  • podpisové kľúče
  • cloudové poverenia

Zamknite ich:

  • najmenej privilégií
  • oddelené bežce
  • tajné maskovanie a prevencia únikov protokolov
  • prísne schvaľovanie krokov nasadenia v produkčnom prostredí

Kde tímy zvyčajne zlyhávajú (a ako sa tomu vyhnúť)

„Niekedy striedame kľúče“ nie je plán

Ak je rotácia manuálna a bolestivá, nestane sa tak pod tlakom.

Zabezpečte rutinnú a automatizovanú rotáciu.

Bezpečnostné nástroje bez presadzovania sa stávajú „monitorovacím divadlom“

Skenovanie repozitárov kvôli tajomstvám je užitočné, ale nestačí.

Tiež potrebujete:

  • rýchle zrušenie
  • upozornenia na používanie
  • a prevencia pri výstavbe potrubí

Pasca vrstvy kontajnera

Ak tajné údaje niekedy vstúpili do kontextu zostavenia kontajnera, predpokladajme, že môžu existovať v:

  • staré obrázky
  • vrstvy uložené v vyrovnávacej pamäti
  • Artefakty CI

Oprava nie je len „odstránenie kľúča repozitára“. Je to:

  • otočiť tajomstvo
  • obnoviť a znova publikovať obrázky
  • zneplatniť vyrovnávacie pamäte, kde je to možné

Čo si pozrieť ďalej

Ak chcete sledovať, či sa organizácie zlepšujú v oblasti NHI, hľadajte:

  • prijatie krátkodobej identity (OIDC/identita pracovnej záťaže)
  • rozsiahle programy rotácie tokenov
  • silnejšie kontroly hraníc CI/CD
  • správy o incidentoch, ktoré ako primárnu príčinu uvádzajú „použitie platných prihlasovacích údajov“

Sledujte aj stránku nástrojov: najlepšie nástroje sa posunú z „detekcie odhalených reťazcov“ na „zníženie počtu statických tajomstiev, ktoré vôbec existujú“.

Ekonomika: prečo útočníci milujú lov tokenov

Váhy na lov žetónov.

Útočník, ktorý ukradne jeden pracovný doklad, môže často:

  • prístup k viacerým systémom (cloud + správa zdrojového kódu + CI)
  • opätovne použiť tú istú techniku ​​v mnohých organizáciách
  • a predávať prístup na trhoviskách, ak ho nechcú prevádzkovať sami

Pre obrancov to znamená, že hrozbou nie je len „hacker, ktorý na nás útočí“. Je to „strojová ekonomika, ktorá profituje z akýchkoľvek opakovane použiteľných prihlasovacích údajov“.

Preto je v tomto prípade prevencia cennejšia ako reakcia. Ak kľúč nikdy neexistoval v statickej forme, nedá sa neskôr získať.

Nápady na detekciu betónu (na čo upozorniť)

Ak vytvárate detekcie pre NHI, zamerajte sa skôr na zmeny správania než na magické kľúčové slová.

Príklady vysokého signálu:

  • Servisný účet používaný znová krajina/ASNnikdy predtým sa to nepoužilo.
  • Token, ktorý bežne volá iba jedno API, zrazu vymenúva zdroje alebo sťahuje veľké objemy.
  • Identita CI vykonávajúca akcie mimo bežného okna vydania.
  • Tajomstvá používané z interaktívnych koncových bodov používateľov, keď boli určené iba pre serverové pracovné zaťaženia.

Dokonca aj základné upozornenia na anomálie dokážu včas odhaliť vzorec „tichej krádeže poverení“.

Nápady na kalenie betónu (nízka námaha, vysoký pákový efekt)

Toto sú praktické zmeny, ktoré väčšina tímov môže urobiť bez rozsiahlej prestavby:

  • Znížiť rozsah tokenov: rozdeliť jeden široký token na niekoľko úzko vymedzených tokenov.
  • Striedať podľa plánu: otáčať, aj keď nič nie je „zlé“, takže rotácia sa stáva svalovou pamäťou.
  • Výroba brán: vyžadujú explicitné schválenie pre identity nasadenia v produkčnom prostredí.
  • Blokovať tajné kódy v otvorenom texte v zostaveniach: CI by malo zlyhať pri zostavovaní, keď sa objavia zjavné tajné vzory.

Každý pohyb zmenšuje polomer výbuchu, aj keď stále dochádza k úniku.

Jednoduchá interná politika, ktorá predchádza mnohým problémom

Ak chcete jednu politiku, ktorá vynúti lepšie správanie, je to táto:

  • Žiadne tajné funkcie vhodné pre produkciu v prenosných počítačoch vývojárov alebo v kontextoch zostavovania kontajnerov.

Toto pravidlo vedie k zmenám, ako napríklad:

  • identita pracovnej záťaže pre služby
  • poverenia pre vývoj na základe pracovných podmienok
  • a explicitné schválenia krokov nasadenia v produkčnom prostredí

Spočiatku je to otravné, ale zabráni to najjednoduchším cestám úniku.

Zrátané a podčiarknuté

Identity iných subjektov sú chrbticou modernej automatizácie – a tiež hlavným faktorom narušenia bezpečnosti, pretože často obchádzajú ochrany, ktoré sme pre ľudí vytvorili.

Ak chcete praktický prah: akonáhle viete odpovedať na otázky „kde sa nachádzajú naše dlhodobé tokeny, kto ich vlastní a ako rýchlo ich môžeme zrušiť/rotovať“, prešli ste od zbožného priania k skutočnému obrannému programu.

Praktickým riešením nie je jeden magický skener. Je to program: minimalizujte statické tajomstvá, zmenšite privilégiá, nastavte rotáciu rutiny a monitorujte identity počítačov rovnako ako monitorujete používateľské účty.

Zdroje

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