Ikke-menneskelige identiteter er en sikkerhetsbruddsmotor: hvorfor tokens og tjenestekontoer stadig blir eksponert

/Teknologi/ Av

Ikke-menneskelige identiteter – API-nøkler, tokens, tjenestekontoer, arbeidsbelastningsidentiteter – er nå en av de enkleste veiene inn i moderne skymiljøer. Ikke fordi angripere plutselig ble genier, men fordi organisasjoner i økende grad opererer på maskin-til-maskin-tillit, og den tilliten er ofte for bred, langvarig og dårlig overvåket.

En ny analyse fremhevet i rapporter peker på et kjent mønster i stor skala: tusenvis av containerbilder og repositorier avslører ved et uhell hemmeligheter som i det stille gir tilgang til produksjonssystemer. Problemet er ikke bare at utviklere noen ganger gjør feil. Problemet er at standardverktøyene og insentivene gjør det mulig.lettå sende hemmeligheter oghardfor å bevise at du ikke gjorde det.

Dette er en historie om et «usynlig brudd». Mange kompromisser starter ikke med en utnyttelse eller en høylytt skadelig hendelse. De starter med et token som autentiserer rent – ​​slik at alt ser normalt ut – helt til du innser at feil prinsipal har brukt det.

Hva «ikke-menneskelige identiteter» er (i enkle orde)

En ikke-menneskelig identitet (NHI) er enhver legitimasjon som lar programvare autentisere seg som en klarert aktør:

  • skytilgangsnøkler og økttokener
  • tjenestekontoer og arbeidsbelastningsidentiteter
  • CI/CD-legitimasjon brukt av byggepipeliner
  • tokens for SaaS-verktøy (GitHub, GitLab, Slack, overvåkingsplattformer)
  • API-nøkler for tredjepartstjenester (betalingsleverandører, e-postleverandører, AI-modell-API-er)

Den viktige forskjellen fra menneskelige pålogginger er at NHI-er vanligvis:

  • kjøre kontinuerlig
  • er innebygd i kode eller konfigurasjon
  • og bruker ofte ikke MFA

Det gjør dem attraktive.

Hvis en angriper får tak i et fungerende token, trenger de ikke å «bryte seg inn». De autentiserer seg.

Hvorfor dette blir verre nå

Tre trender skyver NHI-er fra «viktige» til «dominerende risiko»:

1) Programvareforsyningskjeder er større enn noensinne

Moderne apper er satt sammen av:

  • beholdere
  • åpen kildekode-avhengigheter
  • infrastruktur-som-kode
  • dusinvis av SaaS-integrasjoner

Hver integrasjon legger til en ny legitimasjon.

2) Automatisering er overalt

Organisasjoner ønsker:

  • raskere utplasseringer
  • selvbetjeningsinfrastruktur
  • flyktige miljøer

Automatisering er bra – men det drives av identiteter som har privilegier.

3) Legitimasjoner varer lenger enn personene som opprettet dem

Mennesker bytter roller og drar.

Men et token i et repo eller en container kan:

  • vedvarer i måneder eller år
  • kopieres inn i nye bygg
  • og forblir gyldig lenge etter at noen husker at den eksisterer

Så angrepsflaten vokser stille.

Hvordan hemmeligheter lekker ut i det virkelige liv (det er ikke alltid «noen har begått en nøkkel»)

Stereotypen er en utvikler som forplikter segAWS_HEMMELIG_TILGANGSNØKKELtil GitHub.

Det skjer fortsatt. Men mye lekkasje er mindre åpenbar:

  • tokens bakt inn i beholderlag
  • konfigurasjonsfiler kopiert til bilder under bygging
  • feilsøkingslogger som inneholder hemmeligheter
  • «midlertidige» nøkler delt i chatten og senere limt inn i koden
  • CI-variabler skrevet ut av feilkonfigurerte pipelines

Og containerbilder er spesielt farlige fordi:

  • de blir speilvendte
  • de blir mellomlagret
  • de blir kopiert mellom lagene

Selv om du sletter nøkkelen fra depotet, kan nøkkelen forbli i gamle bildelag.

Hvorfor lekkede tokens er farligere enn mange utnyttelser

Utnyttelser er støyende. De utløser ofte varsler.

Lekkede tokens er stillegående. De ser ofte ut som om de er under normal bruk:

  • vellykket autentisering
  • riktige API-kall
  • legitime endepunkter

Det endrer forsvarerens problem.

I stedet for å oppdage «en angriper», må du oppdage:

  • en uventetrektorbruker gyldig legitimasjon
  • fra uvanlige steder
  • til uvanlige tider
  • utfører uvanlige handlinger

Dette er grunnen til at NHI-er er et deteksjonsgap for mange organisasjoner.

Privilegieproblemet: tokens er ofte for kraftige

Mange hemmeligheter lages som snarveier for å «få det til å fungere»:

  • brede skytillatelser
  • API-tilgang på administratornivå
  • langlivede nøkler

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

Dette skaper en farlig asymmetri:

  • en menneskelig konto kan ha MFA og overvåking
  • Maskinidentiteten kan ha bred tilgang og lite gransking

Når maskinidentiteten lekker, kan eksplosjonsradiusen være større.

Hvordan en god NHI-strategi ser ut (konkrete fremgangsmåter)

Dette er løsbart, men bare hvis du behandler NHI-er som førsteklasses sikkerhetsaktiva.

1) Foretrekk kortvarig legitimasjon

Der det er mulig:

  • bruk midlertidige øktlegitimasjoner
  • roter tokens ofte
  • unngå nøkler som aldri utløper

Kortlivede tokens reduserer utbetalingen av lekkasjer.

2) Erstatt statiske nøkler med arbeidsbelastningsidentitet der du kan

I moderne skyoppsett kan du ofte autentisere arbeidsbelastninger via:

  • instansidentitet
  • OIDC-føderasjonen
  • administrert identitet

Dette reduserer behovet for å lagre statiske nøkler.

3) Strengt separate miljøer

En vanlig feil er å bruke samme token på tvers av:

  • utvikler
  • iscenesettelse
  • produksjon

Tokener bør være miljøbestemte.

Hvis et utviklerbilde lekker, skal det ikke låse opp prod.

4) Lagerbeholdning og eierskap

Hvert meningsfullt token bør ha:

  • en eier
  • et formål
  • et forventet bruksmønster

Hvis en token ikke har noen eier, er det teknisk gjeld som venter på å bli en hendelse.

5) Overvåk NHI-atferd slik du overvåker menneskelig atferd

Gode ​​signaler inkluderer:

  • umulig reise / uvanlige geografier
  • uvanlige API-kallsekvenser
  • økning i datatilgang
  • nye tillatelser gitt
  • nye tokens opprettet

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

6) Behandle CI/CD som en identitetsfabrikk med høy risiko

CI-systemer har ofte:

  • distribusjonsnøkler
  • signeringsnøkler
  • skylegitimasjon

Lås dem inne:

  • minst privilegium
  • separate løpere
  • hemmelig maskering og forebygging av lekkasjer fra tømmerstokker
  • strenge godkjenninger for produksjonsdistribusjonstrinn

Hvor team vanligvis mislykkes (og hvordan man unngår det)

«Vi bytter nøkler noen ganger» er ikke en plan

Hvis rotasjonen er manuell og smertefull, vil den ikke skje under press.

Gjør rotasjonen rutinemessig og automatisert.

Sikkerhetsverktøy uten håndheving blir «overvåkingsteater»

Det er nyttig å skanne arkiver etter hemmeligheter, men det er ikke nok.

Du trenger også:

  • rask tilbakekalling
  • varsler om bruk
  • og forebygging i byggerørledninger

Beholderlagets felle

Hvis hemmeligheter noen gang har havnet i en containerbyggingskontekst, anta at de kan eksistere i:

  • gamle bilder
  • mellomlagrede lag
  • CI-artefakter

Løsningen er ikke bare å «slette repo-nøkkelen». Den er:

  • roter hemmeligheten
  • gjenoppbygge og publisere bilder på nytt
  • ugyldiggjør hurtigbuffer der det er mulig

Hva du skal se på neste gang

Hvis du vil spore om organisasjoner forbedrer seg på NHI-er, se etter:

  • adopsjon av kortvarig identitet (OIDC/arbeidsmengdeidentitet)
  • utbredte tokenrotasjonsprogrammer
  • sterkere CI/CD-grensekontroller
  • hendelsesrapporter som bekrefter at «gyldig legitimasjon brukt» er primær årsak

Se også på verktøysiden: de beste verktøyene vil skifte fra å «oppdage eksponerte strenger» til å «redusere antallet statiske hemmeligheter som finnes i det hele tatt».

Økonomien: hvorfor angripere elsker tokenjakt

Jaktvekter for tokener.

En angriper som stjeler én fungerende legitimasjon kan ofte:

  • tilgang til flere systemer (sky + kildekontroll + CI)
  • gjenbruke den samme teknikken på tvers av mange organisasjoner
  • og selge tilgang på markedsplasser hvis de ikke vil drifte den selv

For forsvarere betyr dette at trusselen ikke bare er «en hacker som sikter seg inn på oss». Det er «en maskinøkonomi som tjener på enhver gjenbrukbar legitimasjon».

Derfor er forebygging mer verdifullt her enn respons. Hvis nøkkelen aldri eksisterte i statisk form, kan den ikke høstes senere.

Ideer for konkret deteksjon (hva man skal varsle om)

Hvis du bygger deteksjoner for NHI-er, fokuser på atferdsendringer i stedet for magiske nøkkelord.

Eksempler på høye signaler:

  • En tjenestekonto brukt fra ennytt land/ASNden har aldri blitt brukt før.
  • Et token som vanligvis bare kaller ett API, lister plutselig opp ressurser eller laster ned store volumer.
  • En CI-identitet som utfører handlinger utenfor det normale utgivelsesvinduet.
  • Hemmeligheter brukt fra interaktive brukerendepunkter når de kun var ment for serverarbeidsbelastninger.

Selv grunnleggende anomalialvarsler kan fange opp mønsteret med «stille legitimasjonstyveri» tidlig.

Ideer for betongherding (lav innsats, høy utvekslingsevne)

Dette er praktiske endringer de fleste team kan gjøre uten en massiv omstrukturering:

  • Reduser tokenomfanget: del én bred token inn i flere tokens med snevert omfang.
  • Roter etter planenroter selv når ingenting er «galt», slik at rotasjon blir muskelminne.
  • Portproduksjonkrever eksplisitt godkjenning for identiteter for produksjonsdistribusjon.
  • Blokker hemmeligheter i klartekst i byggCI skal mislykkes når åpenbare hemmelige mønstre dukker opp.

Hver bevegelse krymper eksplosjonsradiusen selv om det fortsatt oppstår en lekkasje.

En enkel intern policy som forhindrer mye smerte

Hvis du ønsker én policy som fremtvinger bedre oppførsel, er det denne:

  • Ingen produksjonskompatible hemmeligheter i utviklerbærbare datamaskiner eller i containerbyggingskontekster.

Den regelen fører til endringer som:

  • arbeidsbelastningsidentitet for tjenester
  • Staging-legitimasjon for utvikling
  • og eksplisitte godkjenninger for trinn i produksjonsdistribusjonen

Det er irriterende i starten, men det kutter av de enkleste lekkasjeveiene.

Konklusjon

Ikke-menneskelige identiteter er ryggraden i moderne automatisering – og også en viktig årsak til brudd fordi de ofte omgår beskyttelsen vi har bygget for mennesker.

Hvis du ønsker en praktisk terskel: når du kan svare på «hvor bor våre langlivede tokens, hvem eier dem, og hvor raskt kan vi tilbakekalle/rotere dem», har du gått fra ønsketenkning til et reelt forsvarsprogram.

Den praktiske løsningen er ikke én magisk skanner. Det er et program: minimer statiske hemmeligheter, krymp privilegier, lag rotasjonsrutiner og overvåk maskinidentiteter slik du overvåker brukerkontoer.

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...
o Norsk bokmål