Icke-mänskliga identiteter är en intrångsmotor: varför tokens och servicekonton fortsätter att exponeras

/Teknologi/ Av

Icke-mänskliga identiteter – API-nycklar, tokens, tjänstkonton, arbetsbelastningsidentiteter – är nu ett av de enklaste sätten att komma in i moderna molnmiljöer. Inte för att angripare plötsligt blev genier, utan för att organisationer i allt högre grad använder maskin-tillit, och den tilliten är ofta överdriven, långvarig och dåligt övervakad.

En ny analys som framhävts i rapporter pekar på ett välbekant mönster i stor skala: tusentals containeravbildningar och arkiv exponerar av misstag hemligheter som i tysthet ger åtkomst till produktionssystem. Problemet är inte bara att utvecklare ibland gör misstag. Problemet är att standardverktygen och incitamenten gör det möjligt.lättatt skicka hemligheter ochhårdför att bevisa att du inte gjorde det.

Det här är en historia om "osynligt intrång". Många intrång börjar inte med ett utnyttjande eller en högljudd skadlig händelse. De börjar med en token som autentiseras korrekt – så att allt ser normalt ut – tills du inser att fel principal har använt den.

Vad "icke-mänskliga identiteter" är (enkelt uttryckt)

En icke-mänsklig identitet (NHI) är en autentiseringsuppgifter som låter programvara autentisera sig som en betrodd aktör:

  • molnåtkomstnycklar och sessionstokens
  • tjänstkonton och arbetsbelastningsidentiteter
  • CI/CD-autentiseringsuppgifter som används av byggpipelines
  • tokens för SaaS-verktyg (GitHub, GitLab, Slack, övervakningsplattformar)
  • API-nycklar för tredjepartstjänster (betalningsleverantörer, e-postleverantörer, AI-modell-API:er)

Den viktiga skillnaden från mänskliga inloggningar är att NHI:er vanligtvis:

  • kör kontinuerligt
  • är inbäddade i kod eller konfiguration
  • och använder ofta inte MFA

Det gör dem attraktiva.

Om en angripare får tag på en fungerande token behöver de inte "bryta sig in". De autentiserar sig.

Varför detta blir värre nu

Tre trender driver NHI:er från "viktiga" till "dominerande risk":

1) Leveranskedjorna för mjukvara är större än någonsin

Moderna appar är sammansatta från:

  • behållare
  • beroenden med öppen källkod
  • infrastruktur-som-kod
  • dussintals SaaS-integrationer

Varje integration lägger till ytterligare en autentiseringsuppgifter.

2) Automatisering finns överallt

Organisationer vill ha:

  • snabbare driftsättningar
  • självbetjäningsinfrastruktur
  • kortlivade miljöer

Automatisering är bra – men den drivs av identiteter som har privilegier.

3) Referenser varar längre än de personer som skapade dem

Människor byter roller och lämnar.

Men en token i ett repo eller en container kan:

  • kvarstår i månader eller år
  • kopieras till nya byggen
  • och förblir giltiga långt efter att någon kommer ihåg att de existerar

Så växer attackytan tyst.

Hur hemligheter läcker ut i verkliga livet (det är inte alltid "någon har begått en nyckel")

Stereotypen är en utvecklare som begårAWS_SECRET_ACCESS_KEYtill GitHub.

Det händer fortfarande. Men mycket läckage är mindre uppenbart:

  • tokens bakade i containerlager
  • konfigurationsfiler kopierade till avbildningar under byggandet
  • felsökningsloggar som innehåller hemligheter
  • "tillfälliga" nycklar som delas i chatten och senare klistras in i kod
  • CI-variabler som skrivs ut av felkonfigurerade pipelines

Och containerbilder är särskilt farliga eftersom:

  • de blir speglade
  • de blir cachade
  • de kopieras mellan lagen

Även om du tar bort nyckeln från repot kan nyckeln finnas kvar i gamla bildlager.

Varför läckta tokens är farligare än många exploateringar

Exploateringar är bullriga. De utlöser ofta varningar.

Läckta tokens är tysta. De ser ofta ut som normal användning:

  • lyckad autentisering
  • korrekta API-anrop
  • legitima slutpunkter

Det förändrar försvararens problem.

Istället för att upptäcka "en angripare" måste du upptäcka:

  • en oväntadrektormed giltiga inloggningsuppgifter
  • från ovanliga platser
  • vid ovanliga tidpunkter
  • utföra ovanliga handlingar

Det är därför NHI:er är en upptäcktslucka för många organisationer.

Privilegieproblemet: tokens är ofta för kraftfulla

Många hemligheter skapas som genvägar för att "få det att fungera":

  • breda molnbehörigheter
  • API-åtkomst på administratörsnivå
  • långlivade nycklar

Och när systemet väl fungerar vill folk inte röra det.

Detta skapar en farlig asymmetri:

  • ett mänskligt konto kan ha MFA och övervakning
  • Maskinidentiteten kan ha bred åtkomst och liten granskning

När maskinens identitet läcker ut kan explosionsradien vara större.

Hur en bra NHI-strategi ser ut (konkreta metoder)

Detta är lösbart, men bara om man behandlar NHI:er som förstklassiga säkerhetstillgångar.

1) Föredra kortlivade meriter

Där det är möjligt:

  • använd tillfälliga sessionsuppgifter
  • rotera tokens ofta
  • undvik nycklar som aldrig går ut

Kortlivade tokens minskar utdelningen av läckor.

2) Ersätt statiska nycklar med arbetsbelastningsidentitet där det är möjligt

I moderna molninställningar kan du ofta autentisera arbetsbelastningar via:

  • instansidentitet
  • OIDC-federationen
  • hanterad identitet

Detta minskar behovet av att lagra statiska nycklar.

3) Separera miljöer strikt

Ett vanligt fel är att använda samma token över:

  • utvecklare
  • iscensättning
  • produktion

Tokens bör vara miljöanpassade.

Om en utvecklaravbildning läcker, borde den inte låsa upp produkten.

4) Inventarier och ägande

Varje betydelsefull token bör ha:

  • en ägare
  • ett syfte
  • ett förväntat användningsmönster

Om en token inte har någon ägare är det en teknisk skuld som väntar på att bli en incident.

5) Övervaka NHI-beteende på samma sätt som du övervakar mänskligt beteende

Bra signaler inkluderar:

  • omöjliga resor / ovanliga geografiska områden
  • ovanliga API-anropssekvenser
  • toppar i dataåtkomst
  • nya tillstånd beviljade
  • nya tokens skapade

Målet är inte perfekt upptäckt; det är tidig upptäckt.

6) Behandla CI/CD som en högriskidentitetsfabrik

CI-system använder ofta:

  • distributionsnycklar
  • signeringsnycklar
  • molnuppgifter

Lås in dem:

  • minst privilegium
  • separerade löpare
  • hemlig maskering och förebyggande av stockläckor
  • strikta godkännanden för produktionsdistributionssteg

Var team oftast misslyckas (och hur man undviker det)

"Vi roterar nycklar ibland" är inte en plan

Om rotationen är manuell och smärtsam, kommer den inte att ske under tryck.

Gör rotationen rutinmässig och automatiserad.

Säkerhetsverktyg utan verkställighet blir "övervakningsteater"

Att skanna databaser efter hemligheter är användbart, men det räcker inte.

Du behöver också:

  • snabb återkallelse
  • aviseringar om användning
  • och förebyggande åtgärder i byggledningar

Fällan för behållarskiktet

Om hemligheter någonsin hamnade i en containerbyggkontext, anta att de kan finnas i:

  • gamla bilder
  • cachade lager
  • CI-artefakter

Lösningen är inte bara att "ta bort repo-nyckeln". Den är:

  • rotera hemligheten
  • återskapa och publicera bilder igen
  • ogiltigförklara cacher där det är möjligt

Vad man ska titta på härnäst

Om du vill följa om organisationer förbättrar sig gällande NHI:er, leta efter:

  • införande av kortlivad identitet (OIDC/arbetsbelastningsidentitet)
  • utbredda program för tokenrotation
  • starkare CI/CD-gränskontroller
  • incidentrapporter som bekräftar att "giltiga inloggningsuppgifter har använts" är primär orsak

Se även verktygssidan: de bästa verktygen kommer att växla från att "upptäcka exponerade strängar" till att "minska antalet statiska hemligheter som finns överhuvudtaget".

Ekonomin: varför angripare älskar tokenjakt

Jaktvågar för token.

En angripare som stjäl en fungerande autentiseringsuppgift kan ofta:

  • åtkomst till flera system (moln + källkontroll + CI)
  • återanvända samma teknik i många organisationer
  • och sälja åtkomst på marknadsplatser om de inte vill driva den själva

För försvarare innebär detta att hotet inte bara är ”en hackare som riktar in sig på oss”. Det är ”en maskinekonomi som tjänar på alla återanvändbara autentiseringsuppgifter”.

Därför är förebyggande åtgärder mer värdefulla här än åtgärder. Om nyckeln aldrig existerade i statisk form kan den inte samlas in senare.

Idéer för konkreta detekteringar (vad man ska varna för)

Om du bygger detektioner för NHI:er, fokusera på beteendeförändringar snarare än magiska nyckelord.

Exempel på höga signaler:

  • Ett servicekonto som används från ennytt land/ASNden har aldrig använts förut.
  • En token som normalt bara anropar ett API räknar plötsligt upp resurser eller laddar ner stora volymer.
  • En CI-identitet som utför åtgärder utanför det normala lanseringsfönstret.
  • Hemligheter som används från interaktiva användarslutpunkter när de endast var avsedda för serverarbetsbelastningar.

Även enkla avvikelser kan upptäcka mönstret för "tyst autentiseringsuppgifter" tidigt.

Idéer för betonghärdning (låg ansträngning, hög hävstångseffekt)

Det här är praktiska förändringar som de flesta team kan göra utan en omfattande omdesign:

  • Minska tokenomfattningendela upp en bred token i flera tokens med snävt omfattning.
  • Rotera enligt schemarotera även när inget är "fel", så rotation blir muskelminne.
  • Grindelproduktionkräver uttryckligt godkännande för identiteter för produktionsdistribution.
  • Blockera klartexthemligheter i byggenCI bör misslyckas med byggen när uppenbara hemliga mönster dyker upp.

Varje drag krymper explosionsradien även om en läcka fortfarande uppstår.

En enkel intern policy som förhindrar mycket smärta

Om du vill ha en policy som tvingar fram bättre beteende, så är det denna:

  • Inga produktionskompatibla hemligheter i utvecklarbärbara datorer eller i containerbyggkontexter.

Den regeln driver förändringar som:

  • arbetsbelastningsidentitet för tjänster
  • staging-inloggningsuppgifter för utveckling
  • och uttryckliga godkännanden för produktionsdistributionssteg

Det är irriterande i början, men det skär av de enklaste läckagevägarna.

Slutsats

Icke-mänskliga identiteter är ryggraden i modern automatisering – och också en viktig orsak till dataintrång eftersom de ofta kringgår de skydd vi har byggt för människor.

Om du vill ha en praktisk tröskel: när du väl kan svara på "var finns våra långlivade tokens, vem äger dem och hur snabbt kan vi återkalla/rotera dem", har du gått från önsketänkande till ett verkligt försvarsprogram.

Den praktiska lösningen är inte en enda magisk skanner. Det är ett program: minimera statiska hemligheter, krymp behörigheter, skapa rotationsrutiner och övervaka maskinidentiteter på samma sätt som du övervakar användarkonton.

Källor

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...
v Svenska