Ikke-menneskelige identiteter er en brudmotor: hvorfor tokens og servicekonti bliver ved med at blive eksponeret

/Teknologi/ Af

Ikke-menneskelige identiteter – API-nøgler, tokens, servicekonti, arbejdsbelastningsidentiteter – er nu en af ​​de nemmeste veje ind i moderne cloud-miljøer. Ikke fordi angribere pludselig blev genier, men fordi organisationer i stigende grad kører på maskine-til-maskine-tillid, og den tillid er ofte for bred, langvarig og dårligt overvåget.

En ny analyse, der er fremhævet i rapporter, peger på et velkendt mønster i stor skala: tusindvis af containerbilleder og -lagre afslører ved et uheld hemmeligheder, der i al hemmelighed giver adgang til produktionssystemer. Problemet er ikke kun, at udviklere nogle gange begår fejl. Problemet er, at standardværktøjerne og incitamenterne gør det muligt.letat sende hemmeligheder oghårdfor at bevise at du ikke gjorde det.

Dette er en historie om et "usynligt brud". Mange kompromitteringer starter ikke med en udnyttelse eller en højlydt malwarehændelse. De starter med et token, der autentificerer rent – ​​så alt ser normalt ud – indtil du indser, at den forkerte principal har brugt det.

Hvad "ikke-menneskelige identiteter" er (enklet sagt)

En ikke-menneskelig identitet (NHI) er enhver legitimationsoplysninger, der tillader software at godkende sig som en betroet aktør:

  • Cloud-adgangsnøgler og sessionstokens
  • servicekonti og arbejdsbelastningsidentiteter
  • CI/CD-legitimationsoplysninger brugt af build-pipelines
  • tokens til SaaS-værktøjer (GitHub, GitLab, Slack, overvågningsplatforme)
  • API-nøgler til tredjepartstjenester (betalingsudbydere, e-mailudbydere, AI-model-API'er)

Den vigtige forskel fra menneskelige logins er, at NHI'er typisk:

  • køre kontinuerligt
  • er indlejret i kode eller konfiguration
  • og bruger ofte ikke MFA

Det gør dem attraktive.

Hvis en angriber får fat i en fungerende token, behøver de ikke at "bryde ind". De autentificerer sig.

Hvorfor det bliver værre nu

Tre tendenser skubber NHI'er fra "vigtige" til "dominerende risiko":

1) Softwareforsyningskæder er større end nogensinde

Moderne apps er samlet fra:

  • containere
  • open source-afhængigheder
  • infrastruktur-som-kode
  • snesevis af SaaS-integrationer

Hver integration tilføjer endnu en legitimationsoplysninger.

2) Automatisering er overalt

Organisationer ønsker:

  • hurtigere implementeringer
  • selvbetjeningsinfrastruktur
  • flygtige miljøer

Automatisering er godt – men det drives af identiteter, der har privilegier.

3) Legitimationer holder længere end de personer, der skabte dem

Mennesker skifter roller og forlader stedet.

Men et token i et repo eller en container kan:

  • vedvarer i måneder eller år
  • kopieres til nye builds
  • og forbliver gyldig længe efter at nogen husker dens eksistens

Så vokser angrebsfladen lydløst.

Hvordan hemmeligheder lækker ud i det virkelige liv (det er ikke altid "nogen har begået en nøgle")

Stereotypen er en udvikler, der forpligter sigAWS_HEMMELLIG_ADGANGSNØGLEtil GitHub.

Det sker stadig. Men meget lækage er mindre tydelig:

  • tokens bagt ind i containerlag
  • konfigurationsfiler kopieret til billeder under opbygning
  • fejlfindingslogfiler, der indeholder hemmeligheder
  • "Midlertidige" nøgler delt i chatten og senere indsat i koden
  • CI-variabler udskrevet af forkert konfigurerede pipelines

Og containerbilleder er særligt farlige fordi:

  • de bliver spejlet
  • de bliver cachelagret
  • de bliver kopieret mellem holdene

Selv hvis du sletter nøglen fra lageret, kan nøglen forblive i gamle billedlag.

Hvorfor lækkede tokens er farligere end mange exploits

Exploits er støjende. De udløser ofte alarmer.

Lækkede tokens er stille. De ser ofte ud til at være under normal brug:

  • vellykket godkendelse
  • korrekte API-kald
  • legitime slutpunkter

Det ændrer forsvarsspillerens problem.

I stedet for at opdage "en angriber" skal du opdage:

  • en uventetrektorved hjælp af gyldige legitimationsoplysninger
  • fra usædvanlige steder
  • på usædvanlige tidspunkter
  • udfører usædvanlige handlinger

Derfor er NHI'er et hul i opdagelsen for mange organisationer.

Privilegieproblemet: tokens er ofte for kraftfulde

Mange hemmeligheder skabes som genveje til at "få det til at virke":

  • brede cloud-tilladelser
  • API-adgang på administratorniveau
  • langlivede nøgler

Og når systemet først fungerer, vil folk ikke røre ved det.

Dette skaber en farlig asymmetri:

  • en menneskelig konto kan have MFA og overvågning
  • Maskinidentiteten kan have bred adgang og begrænset kontrol

Når maskinens identitet lækker, kan eksplosionsradiusen være større.

Sådan ser en god NHI-strategi ud (konkrete fremgangsmåder)

Dette kan løses, men kun hvis man behandler NHI'er som førsteklasses sikkerhedsaktiver.

1) Foretrækker kortvarige legitimationsoplysninger

Hvor det er muligt:

  • brug midlertidige sessionsoplysninger
  • roter tokens ofte
  • Undgå nøgler, der aldrig udløber

Kortlivede tokens reducerer udbetalingen af ​​lækager.

2) Erstat statiske nøgler med arbejdsbelastningsidentitet, hvor det er muligt

I moderne cloud-opsætninger kan du ofte godkende arbejdsbelastninger via:

  • instansidentitet
  • OIDC-føderationen
  • administreret identitet

Dette reducerer behovet for at gemme statiske nøgler.

3) Strengt adskilte miljøer

En almindelig fejl er at bruge den samme token på tværs af:

  • udvikler
  • iscenesættelse
  • produktion

Tokens skal være miljøbestemte.

Hvis et udviklerbillede lækker, burde det ikke låse prod op.

4) Lagerbeholdning og ejerskab

Ethvert meningsfuldt token bør have:

  • en ejer
  • et formål
  • et forventet brugsmønster

Hvis en token ikke har nogen ejer, er det teknisk gæld, der venter på at blive en hændelse.

5) Overvåg NHI-adfærd, ligesom du overvåger menneskelig adfærd

Gode ​​signaler inkluderer:

  • umulig rejse / usædvanlige geografier
  • usædvanlige API-kaldssekvenser
  • stigninger i dataadgang
  • nye tilladelser givet
  • nye tokens oprettet

Målet er ikke perfekt detektion; det er tidlig detektion.

6) Behandl CI/CD som en identitetsfabrik med høj risiko

CI-systemer indeholder ofte:

  • implementeringsnøgler
  • signeringsnøgler
  • cloud-legitimationsoplysninger

Lås dem inde:

  • mindst privilegium
  • adskilte løbere
  • hemmelig maskering og forebyggelse af loglækager
  • strenge godkendelser for produktionsimplementeringstrin

Hvor teams ofte fejler (og hvordan man undgår det)

"Vi skifter nøgler nogle gange" er ikke en plan

Hvis rotationen er manuel og smertefuld, vil den ikke ske under pres.

Gør rotation rutinemæssig og automatiseret.

Sikkerhedsværktøjer uden håndhævelse bliver til "overvågningsteater"

Det er nyttigt at scanne arkiver for hemmeligheder, men det er ikke nok.

Du skal også bruge:

  • hurtig tilbagekaldelse
  • advarsler om brug
  • og forebyggelse i byggerørledninger

Containerlagets fælde

Hvis hemmeligheder nogensinde er kommet ind i en container-byggekontekst, antag at de muligvis findes i:

  • gamle billeder
  • cachelagrede lag
  • CI-artefakter

Løsningen er ikke kun at "slette repo-nøglen". Det er:

  • roter hemmeligheden
  • genopbygge og genudgive billeder
  • ugyldiggør caches hvor det er muligt

Hvad skal man se næste gang

Hvis du vil spore, om organisationer forbedrer sig med hensyn til NHI'er, skal du kigge efter:

  • indførelse af kortlivet identitet (OIDC/arbejdsbelastningsidentitet)
  • udbredte tokenrotationsprogrammer
  • stærkere CI/CD-grænsekontrol
  • hændelsesrapporter, der anerkender "gyldige legitimationsoplysninger brugt" som primær årsag

Hold også øje med værktøjssiden: de bedste værktøjer vil skifte fra "detektere eksponerede strenge" til "reducere antallet af statiske hemmeligheder, der overhovedet findes".

Økonomien: hvorfor angribere elsker token-jagt

Token-jagtvægte.

En angriber, der stjæler én fungerende legitimationsoplysninger, kan ofte:

  • adgang til flere systemer (cloud + kildekontrol + CI)
  • genbruge den samme teknik på tværs af mange organisationer
  • og sælge adgang på markedspladser, hvis de ikke selv ønsker at drive det

For forsvarere betyder det, at truslen ikke bare er "en hacker, der går efter os". Det er "en maskinøkonomi, der profiterer fra enhver genbrugelig legitimationsoplysninger".

Derfor er forebyggelse mere værdifuldt her end respons. Hvis nøglen aldrig har eksisteret i statisk form, kan den ikke høstes senere.

Idéer til konkret detektion (hvad man skal advare om)

Hvis du opbygger detektioner til NHI'er, så fokuser på adfærdsændringer i stedet for magiske nøgleord.

Eksempler på høje signaler:

  • En servicekonto brugt fra ennyt land/ASNden har aldrig været brugt før.
  • Et token, der normalt kun kalder én API, opregner pludselig ressourcer eller downloader store mængder.
  • En CI-identitet, der udfører handlinger uden for det normale udgivelsesvindue.
  • Hemmeligheder brugt fra interaktive brugerslutpunkter, når de kun var beregnet til serverarbejdsbelastninger.

Selv simple anomali-advarsler kan opdage mønsteret med "stille tyveri af legitimationsoplysninger" tidligt.

Idéer til betonhærdning (lav indsats, høj gearing)

Dette er praktiske ændringer, som de fleste teams kan foretage uden en massiv omstrukturering:

  • Reducer token-omfangetopdel en bred token i flere tokens med snævert omfang.
  • Roter efter planenRoter selv når intet er "forkert", så rotation bliver til muskelhukommelse.
  • Produktion af portekræver eksplicit godkendelse af produktionsimplementeringsidentiteter.
  • Bloker klarteksthemmeligheder i buildsCI bør fejle i builds, når åbenlyse hemmelige mønstre opstår.

Hver bevægelse krymper eksplosionsradius, selvom der stadig opstår en lækage.

En simpel intern politik, der forhindrer en masse smerte

Hvis du ønsker én politik, der fremtvinger bedre adfærd, er det denne:

  • Ingen produktionskompatible hemmeligheder i udviklerbærbare computere eller i containerbyggekontekster.

Den regel fører til ændringer som:

  • arbejdsbelastningsidentitet for tjenester
  • Staging-legitimationsoplysninger for udvikling
  • og eksplicitte godkendelser af produktionsimplementeringstrin

Det er irriterende i starten, men det afskærer de nemmeste lækageveje.

Konklusion

Ikke-menneskelige identiteter er rygraden i moderne automatisering – og også en væsentlig årsag til brud på datasikkerheden, fordi de ofte omgår de beskyttelser, vi har bygget til mennesker.

Hvis du ønsker en praktisk tærskel: Når du kan svare på "hvor befinder vores langlivede tokens sig, hvem ejer dem, og hvor hurtigt kan vi tilbagekalde/rotere dem", er du gået fra ønsketænkning til et rigtigt forsvarsprogram.

Den praktiske løsning er ikke én magisk scanner. Det er et program: minimer statiske hemmeligheder, krymp privilegier, lav rotationsrutiner og overvåg maskinidentiteter, ligesom du overvåger brugerkonti.

Kilder

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...
a Dansk