Nelidské identity jsou motorem narušení: Proč jsou tokeny a servisní účty neustále odhalovány

/Technologie/ Od

Nelidské identity – klíče API, tokeny, servisní účty, identity úloh – jsou nyní jednou z nejjednodušších cest do moderních cloudových prostředí. Ne proto, že by se z útočníků náhle stali géniové, ale proto, že organizace stále častěji fungují na důvěře mezi stroji a tato důvěra je často příliš široká, dlouhodobá a špatně monitorovaná.

Nová analýza zdůrazněná ve zprávách poukazuje na známý vzorec ve velkém měřítku: tisíce kontejnerových obrazů a repozitářů nechtěně odhalují tajné informace, které tiše poskytují přístup k produkčním systémům. Problém není jen v tom, že vývojáři někdy dělají chyby. Problém je v tom, že výchozí nástroje a pobídky to znemožňují.snadnýposílat tajemství atvrdýabys dokázal, že jsi to neudělal.

Toto je příběh o „neviditelném narušení“. Mnoho kompromitací nezačne zneužitím nebo hlasitou událostí malwaru. Začnou tokenem, který se čistě autentizuje – takže vše vypadá normálně – dokud si neuvědomíte, že ho používá nesprávný principal.

Co jsou to „nelidské identity“ (jednoduše řečeno)

Nelidská identita (NHI) je jakýkoli doklad, který umožňuje softwaru ověřit se jako důvěryhodný aktér:

  • přístupové klíče ke cloudu a tokeny relací
  • servisní účty a identity úloh
  • Přihlašovací údaje CI/CD používané kanály sestavení
  • tokeny pro SaaS nástroje (GitHub, GitLab, Slack, monitorovací platformy)
  • Klíče API pro služby třetích stran (poskytovatelé plateb, poskytovatelé e-mailů, API modelů umělé inteligence)

Důležitý rozdíl oproti lidským přihlášením je, že NHI obvykle:

  • běžet nepřetržitě
  • jsou vloženy do kódu nebo konfigurace
  • a často nepoužívají MFA

To je dělá atraktivními.

Pokud útočník získá funkční token, nemusí se do něj „prolomit“. Provede autentizaci.

Proč se to teď zhoršuje

Tři trendy posouvají NHI z kategorie „důležitých“ na kategorii „dominantně rizikových“:

1) Dodavatelské řetězce softwaru jsou větší než kdy dříve

Moderní aplikace se sestavují z:

  • kontejnery
  • závislosti na open-source
  • infrastruktura jako kód
  • desítky SaaS integrací

Každá integrace přidává další pověření.

2) Automatizace je všude

Organizace chtějí:

  • rychlejší nasazení
  • infrastruktura samoobsluhy
  • prchavá prostředí

Automatizace je dobrá – ale je poháněna identitami, které mají oprávnění.

3) Pověření vydrží déle než lidé, kteří je vytvořili

Lidé si mění role a odcházejí.

Token v repozitáři nebo kontejneru však může:

  • přetrvávají měsíce nebo roky
  • zkopírovat do nových sestavení
  • a zůstávají platné dlouho poté, co si na jejich existenci někdo vzpomene

Takže útočná plocha roste tiše.

Jak tajemství unikají v reálném životě (ne vždycky je to „někdo sdělil klíč“)

Stereotyp je vývojář, který se zavazujeAWS_SECRET_ACCESS_KEYna GitHub.

To se stále stává. Ale mnoho úniků je méně zřejmých:

  • tokeny zapečené do vrstev kontejneru
  • konfigurační soubory zkopírované do imagí během sestavení
  • ladicí protokoly obsahující tajné kódy
  • „dočasné“ klíče sdílené v chatu a později vložené do kódu
  • Proměnné CI vytištěné nesprávně nakonfigurovanými kanály

A obrázky kontejnerů jsou obzvláště nebezpečné, protože:

  • zrcadlí se
  • ukládají se do mezipaměti
  • kopírují se mezi týmy

I když klíč z repozitáře smažete, může zůstat ve starých vrstvách obrazu.

Proč jsou uniklé tokeny nebezpečnější než mnoho dalších exploitů

Exploity jsou hlučné. Často spouštějí upozornění.

Uniklé tokeny jsou tiché. Často vypadají jako běžné použití:

  • úspěšné ověření
  • správná volání API
  • legitimní koncové body

To mění problém obránce.

Místo detekce „útočníka“ musíte detekovat:

  • neočekávanéhlavnís použitím platných přihlašovacích údajů
  • z neobvyklých míst
  • v neobvyklých časech
  • prováděním neobvyklých akcí

Proto jsou NHI pro mnoho organizací detekční mezerou.

Problém s privilegii: tokeny jsou často příliš silné

Mnoho tajných kódů je vytvořeno jako zkratky pro „zprovoznění“:

  • široká cloudová oprávnění
  • přístup k API na úrovni administrátora
  • klíče s dlouhou životností

A jakmile systém funguje, lidé se ho nechtějí ani dotknout.

To vytváří nebezpečnou asymetrii:

  • lidský účet může mít vícefaktorovou autentizaci (MFA) a monitorování
  • identita stroje může mít široký přístup a malou kontrolu

Pokud unikne identita stroje, může být poloměr výbuchu větší.

Jak vypadá dobrá strategie NHI (konkrétní postupy)

To je řešitelné, ale pouze pokud s NHI zacházíte jako s prvotřídními bezpečnostními aktivy.

1) Upřednostňujte krátkodobé pověření

Kde je to možné:

  • použít dočasné přihlašovací údaje k relaci
  • často střídejte žetony
  • vyhněte se klíčům s „nekonečnou platností“

Krátkodobé tokeny snižují výnos z úniků.

2) Nahraďte statické klíče identitou pracovní zátěže, kde je to možné.

V moderních cloudových nastaveních můžete úlohy často ověřovat pomocí:

  • identita instance
  • Federace OIDC
  • spravovaná identita

Díky tomu se snižuje potřeba ukládat statické klíče.

3) Přísně oddělte prostředí

Častou chybou je použití stejného tokenu napříč:

  • vývojář
  • inscenace
  • výroba

Tokeny by měly být omezeny na dané prostředí.

Pokud unikne vývojářský obraz, neměl by odemknout produkční verzi.

4) Zásoby a vlastnictví

Každý smysluplný token by měl mít:

  • majitel
  • účel
  • očekávaný vzorec užívání

Pokud token nemá vlastníka, jedná se o technický dluh, který čeká na to, aby se stal incidentem.

5) Sledujte chování NHI, stejně jako sledujete lidské chování

Mezi dobré signály patří:

  • nemožné cestování / neobvyklé zeměpisné oblasti
  • neobvyklé sekvence volání API
  • prudké nárůsty v přístupu k datům
  • udělena nová oprávnění
  • nové tokeny vytvořené

Cílem není dokonalá detekce, ale včasná detekce.

6) Zacházejte s CI/CD jako s vysoce rizikovou továrnou na identitu

Systémy CI často obsahují:

  • klíče nasazení
  • podpisové klíče
  • cloudové přihlašovací údaje

Zamkněte je:

  • nejmenší privilegium
  • oddělené běžce
  • tajné maskování a prevence úniků protokolů
  • přísné schvalování kroků nasazení v produkčním prostředí

Kde týmy obvykle selhávají (a jak se tomu vyhnout)

„Někdy střídáme klíče“ není plán

Pokud je rotace manuální a bolestivá, neprobíhá pod tlakem.

Zajistěte, aby rotace byla rutinní a automatizovaná.

Bezpečnostní nástroje bez vynucování se stávají „monitorovacím divadlem“

Prohledávání repozitářů kvůli tajným kódům je užitečné, ale nestačí.

Také potřebujete:

  • rychlé zrušení
  • upozornění na používání
  • a prevence při výstavbě potrubí

Depeše vrstvy kontejneru

Pokud tajné kódy někdy vstoupily do kontextu sestavení kontejneru, předpokládejme, že mohou existovat v:

  • staré obrázky
  • vrstvy uložené v mezipaměti
  • Artefakty CI

Oprava není jen „smazat klíč repozitáře“. Je to:

  • otočit tajemství
  • obnovit a znovu publikovat obrázky
  • zneplatnit mezipaměti, kde je to možné

Na co se dívat dál

Pokud chcete sledovat, zda se organizace zlepšují v oblasti NHI, hledejte:

  • přijetí krátkodobé identity (OIDC/identita pracovní zátěže)
  • rozšířené programy rotace tokenů
  • silnější kontroly hranic CI/CD
  • zprávy o incidentech, které jako primární příčinu uvádějí „použité platné přihlašovací údaje“

Sledujte také stránku nástrojů: nejlepší nástroje se posunou od „detekce odhalených řetězců“ k „snížení počtu statických tajných kódů, které vůbec existují“.

Ekonomika: proč útočníci milují lov tokenů

Váhy pro lov žetonů.

Útočník, který ukradne jeden funkční přihlašovací údaj, může často:

  • přístup k více systémům (cloud + správa zdrojů + CI)
  • znovu používat stejnou techniku ​​v mnoha organizacích
  • a prodávat přístup na tržištích, pokud je nechtějí provozovat sami

Pro obránce to znamená, že hrozbou není jen „hacker, který na nás cílí“. Je to „strojová ekonomika, která profituje z jakéhokoli opakovaně použitelného přihlašovacího údaje“.

Proto je zde prevence cennější než reakce. Pokud klíč nikdy neexistoval ve statické podobě, nelze jej později získat.

Nápady na detekci betonu (na co upozornit)

Pokud vytváříte detekční metody pro NHI, zaměřte se spíše na změny chování než na magická klíčová slova.

Příklady vysokého signálu:

  • Servisní účet používaný znová země/ASNnikdy předtím nepoužíváno.
  • Token, který normálně volá pouze jedno API, najednou vyjmenovává zdroje nebo stahuje velké objemy.
  • Identita CI provádějící akce mimo běžné okno vydání.
  • Tajné kódy používané z interaktivních uživatelských koncových bodů, když byly určeny pouze pro serverové úlohy.

I základní upozornění na anomálie dokáží včas odhalit vzorec „tiché krádeže přihlašovacích údajů“.

Nápady na kalení betonu (nízká námaha, vysoký pákový efekt)

Toto jsou praktické změny, které většina týmů může provést bez rozsáhlého přepracování:

  • Zmenšit rozsah tokenů: rozdělit jeden široký token na několik úzce vymezených tokenů.
  • Střídat podle plánu: otáčet, i když se nic „neděje“, takže se rotace stává svalovou pamětí.
  • Výroba bran: vyžadovat explicitní schválení pro identity nasazení v produkčním prostředí.
  • Blokovat tajné kódy prostého textu v sestaveníchCI by mělo selhat při sestavení, pokud se objeví zjevné tajné vzorce.

Každý pohyb zmenšuje poloměr výbuchu, i když k úniku stále dochází.

Jednoduchá interní politika, která předchází mnoha problémům

Pokud chcete jednu zásadu, která vynutí lepší chování, je to tato:

  • Žádné tajné kódy vhodné pro produkční prostředí ve vývojářských laptopech nebo v kontextech sestavení kontejnerů.

Toto pravidlo vede ke změnám, jako například:

  • identita úloh pro služby
  • pověření pro vývoj na stádiu vývoje
  • a explicitní schválení kroků nasazení v produkčním prostředí

Zpočátku je to otravné, ale zabrání to nejjednodušším cestám úniku.

Sečteno a podtrženo

Nelidské identity jsou páteří moderní automatizace – a také hlavním faktorem narušení bezpečnosti, protože často obcházejí ochrany, které jsme pro lidi vytvořili.

Pokud chcete praktický práh: jakmile si dokážete odpovědět na otázky „kde se nacházejí naše dlouhodobé tokeny, kdo je vlastní a jak rychle je můžeme zrušit/rotovat“, přesunuli jste se od zbožného přání ke skutečnému obrannému programu.

Praktickým řešením není jeden magický skener. Je to program: minimalizujte statické tajné údaje, zmenšete oprávnění, nastavte rotační rutinu a monitorujte identity počítačů, stejně jako monitorujete uživatelské úč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...
Čeština