Niet-menselijke identiteiten vormen een bron van datalekken: waarom tokens en serviceaccounts steeds weer worden blootgesteld.

/Technologie/ Door

Niet-menselijke identiteiten – API-sleutels, tokens, serviceaccounts, workload-identiteiten – vormen tegenwoordig een van de gemakkelijkste manieren om toegang te krijgen tot moderne cloudomgevingen. Niet omdat aanvallers plotseling genieën zijn geworden, maar omdat organisaties steeds vaker vertrouwen hebben in de onderlinge relaties tussen machines, en dat vertrouwen is vaak te breed, langdurig en slecht gecontroleerd.

Een nieuwe analyse, die in diverse media aan bod komt, wijst op een bekend patroon op grote schaal: duizenden containerimages en repositories die per ongeluk geheimen prijsgeven die stilletjes toegang verlenen tot productiesystemen. Het probleem is niet alleen dat ontwikkelaars soms fouten maken. Het probleem is dat de standaardtools en -stimulansen dit mogelijk maken.eenvoudigom scheepsgeheimen te verschepen enmoeilijkom te bewijzen dat je dat niet hebt gedaan.

Dit is een verhaal over een "onzichtbare inbreuk". Veel inbreuken beginnen niet met een exploit of een opvallende malware-aanval. Ze beginnen met een token dat probleemloos authenticeert – dus alles lijkt normaal – totdat je beseft dat de verkeerde partij het gebruikt.

Wat zijn "niet-menselijke identiteiten" (in eenvoudige bewoordingen)?

Een niet-menselijke identiteit (NHI) is elke authenticatiegegevens waarmee software zich kan voordoen als een vertrouwde partij:

  • cloudtoegangssleutels en sessietokens
  • serviceaccounts en workload-identiteiten
  • CI/CD-referenties die door build-pipelines worden gebruikt
  • tokens voor SaaS-tools (GitHub, GitLab, Slack, monitoringplatforms)
  • API-sleutels voor diensten van derden (betaalproviders, e-mailproviders, API's voor AI-modellen)

Het belangrijkste verschil met menselijke aanmeldingen is dat NHI's doorgaans:

  • continu draaien
  • zijn ingebed in code of configuratie
  • en gebruiken vaak geen MFA

Dat maakt ze aantrekkelijk.

Als een aanvaller een werkend token bemachtigt, hoeft hij niet in te breken. Hij kan zich authenticeren.

Waarom dit nu erger wordt

Drie trends zorgen ervoor dat nationale ziektekostenverzekeringen van een "belangrijk" naar een "dominant risico" verschuiven:

1) Softwareleveringsketens zijn groter dan ooit.

Moderne apps worden samengesteld uit:

  • containers
  • open-source afhankelijkheden
  • infrastructuur als code
  • tientallen SaaS-integraties

Elke integratie voegt een extra authenticatiegegeven toe.

2) Automatisering is overal

Organisaties willen:

  • snellere implementaties
  • zelfbedieningsinfrastructuur
  • vluchtige omgevingen

Automatisering is goed, maar het werkt op basis van identiteiten met specifieke privileges.

3) Referenties blijven langer geldig dan de mensen die ze hebben opgesteld.

Mensen wisselen van rol en gaan weg.

Maar een token in een repository of container kan wel:

  • maanden of jaren aanhouden
  • worden gekopieerd naar nieuwe builds
  • en blijven geldig lang nadat niemand zich meer herinnert dat het bestond.

Het aanvalsoppervlak groeit dus ongemerkt.

Hoe geheimen in het echte leven uitlekken (het is niet altijd "iemand heeft een sleutel gestolen").

Het stereotype is een ontwikkelaar die zich vastlegtAWS_SECRET_ACCESS_KEYnaar GitHub.

Dat gebeurt nog steeds. Maar veel lekkages zijn minder duidelijk zichtbaar:

  • tokens ingebakken in containerlagen
  • configuratiebestanden worden tijdens het bouwproces naar de afbeeldingen gekopieerd
  • debuglogs met geheimen
  • "Tijdelijke" sleutels werden in de chat gedeeld en later in de code geplakt.
  • CI-variabelen afgedrukt door verkeerd geconfigureerde pipelines

Containerafbeeldingen zijn bijzonder gevaarlijk omdat:

  • ze worden gespiegeld
  • ze worden in de cache opgeslagen
  • Ze worden tussen teams gekopieerd.

Zelfs als je de sleutel uit de repository verwijdert, kan deze in oude imagelagen achterblijven.

Waarom gelekte tokens gevaarlijker zijn dan veel exploits

Exploits maken veel lawaai. Ze activeren vaak waarschuwingen.

Gelekte tokens blijven onopgemerkt. Ze lijken vaak op normaal gebruik:

  • succesvolle authenticatie
  • correcte API-aanroepen
  • legitieme eindpunten

Dat verandert het probleem van de verdediger.

In plaats van "een aanvaller" te detecteren, moet je het volgende detecteren:

  • een onverwachtevoornaamgeldige inloggegevens gebruiken
  • afkomstig van ongebruikelijke locaties
  • op ongebruikelijke tijden
  • ongebruikelijke acties uitvoeren

Dit is de reden waarom nationale gezondheidsinformatiesystemen (NHI's) voor veel organisaties een detectieprobleem vormen.

Het privilegeprobleem: tokens zijn vaak te machtig.

Veel geheimen worden bedacht als snelkoppelingen om dingen werkend te krijgen:

  • brede cloudrechten
  • API-toegang op beheerdersniveau
  • langlevende sleutels

En als het systeem eenmaal werkt, wil niemand er meer aan komen.

Dit creëert een gevaarlijke asymmetrie:

  • Een menselijk account kan MFA en monitoring hebben.
  • De machine-identiteit kan breed toegankelijk zijn en weinig gecontroleerd worden.

Als de identiteit van de machine uitlekt, kan de impact van de explosie groter zijn.

Hoe een goede NHI-strategie eruitziet (concrete praktijken)

Dit is oplosbaar, maar alleen als je nationale gezondheidsinstellingen als eersteklas zekerheidsactiva beschouwt.

1) Geef de voorkeur aan kortstondige certificaten

Waar mogelijk:

  • tijdelijke sessiegegevens gebruiken
  • Draai tokens regelmatig.
  • Vermijd sleutels die nooit verlopen.

Tokens met een korte levensduur verminderen de winst die lekken opleveren.

2) Vervang statische sleutels waar mogelijk door workload-identificatie.

In moderne cloudomgevingen kunt u workloads vaak authenticeren via:

  • instantie-identiteit
  • OIDC-federatie
  • beheerde identiteit

Dit vermindert de noodzaak om statische sleutels op te slaan.

3) Scheid de omgevingen strikt van elkaar.

Een veelvoorkomende fout is het gebruik van hetzelfde token op verschillende plaatsen:

  • dev
  • enscenering
  • productie

Tokens moeten een omgevingsbereik hebben.

Als een ontwikkelingsimage uitlekt, mag deze de productieomgeving niet ontgrendelen.

4) Inventaris en eigendom

Elk betekenisvol token moet het volgende bevatten:

  • een eigenaar
  • een doel
  • een verwacht gebruikspatroon

Als een token geen eigenaar heeft, is het een technische schuld die op het punt staat een incident te worden.

5) Monitor het gedrag van NHI zoals je het gedrag van mensen monitort.

Goede signalen zijn onder andere:

  • onmogelijke reizen / ongewone geografische gebieden
  • ongebruikelijke API-aanroepsequenties
  • pieken in de toegang tot gegevens
  • nieuwe vergunningen verleend
  • nieuwe tokens gecreëerd

Het doel is niet perfecte detectie, maar vroege detectie.

6) Beschouw CI/CD als een identiteitsfabriek met een hoog risico.

CI-systemen bevatten vaak:

  • implementatiesleutels
  • sleutels ondertekenen
  • cloud-referenties

Sluit ze op:

  • minst bevoorrecht
  • gescheiden hardlopers
  • Geheimhouding en preventie van loglekken
  • Strikte goedkeuringen voor implementatiestappen in productie

Waar teams meestal de mist in gaan (en hoe je dat kunt voorkomen)

"We wisselen soms van sleutels" is geen plan.

Als draaien handmatig en pijnlijk is, zal het onder druk niet lukken.

Maak rotatie routinematig en geautomatiseerd.

Beveiligingsinstrumenten zonder handhaving worden "schijnvertoning".

Het scannen van repositories op geheimen is nuttig, maar niet voldoende.

Je hebt ook het volgende nodig:

  • snelle intrekking
  • waarschuwingen over gebruik
  • en preventie bij de aanleg van pijpleidingen

De containerlaagval

Als er ooit geheimen in de context van een containerbuild terechtkomen, ga er dan vanuit dat ze zich mogelijk in de volgende gebieden bevinden:

  • oude afbeeldingen
  • in de cache opgeslagen lagen
  • CI-artefacten

De oplossing is niet alleen "verwijder de repositorysleutel". Het is:

  • draai het geheim
  • afbeeldingen opnieuw opbouwen en publiceren
  • Maak caches waar mogelijk ongeldig.

Wat je hierna kunt kijken

Als u wilt nagaan of organisaties vooruitgang boeken op het gebied van nationale gezondheidsrapportages (NHI's), let dan op het volgende:

  • adoptie van een kortstondige identiteit (OIDC/werkbelastingidentiteit)
  • wijdverspreide programma's voor tokenrotatie
  • strengere CI/CD-grenscontroles
  • Incidentrapporten waarin "geldige inloggegevens gebruikt" als primaire oorzaak wordt genoemd.

Let ook op de tooling: de beste tools zullen verschuiven van "het detecteren van blootgestelde tekenreeksen" naar "het verminderen van het aantal statische geheimen dat überhaupt bestaat".

De economie: waarom aanvallers zo dol zijn op token hunting

Schalen voor het jagen op tokens.

Een aanvaller die één werkende inloggegevens steelt, kan vaak het volgende doen:

  • toegang tot meerdere systemen (cloud + versiebeheer + CI)
  • Dezelfde techniek hergebruiken in meerdere organisaties.
  • en toegang verkopen via marktplaatsen als ze het niet zelf willen beheren.

Voor verdedigers betekent dit dat de dreiging niet alleen "een hacker is die ons aanvalt". Het is "een machine-economie die profiteert van elke herbruikbare inloggegeven".

Daarom is preventie hier waardevoller dan reactie. Als de sleutel nooit in statische vorm heeft bestaan, kan deze later ook niet meer worden achterhaald.

Ideeën voor concrete detectie (waarop te alarmeren)

Als je detectiemethoden ontwikkelt voor NHI's, focus dan op gedragsveranderingen in plaats van op magische trefwoorden.

Voorbeelden van hoge signaalsterktes:

  • Een serviceaccount dat wordt gebruikt vanuit eennieuw land/ASNHet is nog nooit eerder gebruikt.
  • Een token dat normaal gesproken slechts één API aanroept, somt plotseling alle resources op of downloadt grote hoeveelheden data.
  • Een CI-identiteit die acties uitvoert buiten het normale releasevenster.
  • Geheimen die afkomstig zijn van interactieve gebruikers-endpoints, terwijl deze eigenlijk alleen bedoeld waren voor servertoepassingen.

Zelfs eenvoudige waarschuwingen voor afwijkingen kunnen het patroon van "stille diefstal van inloggegevens" al vroeg opsporen.

Ideeën voor het verharden van beton (weinig moeite, veel effect)

Dit zijn praktische veranderingen die de meeste teams kunnen doorvoeren zonder een ingrijpende herontwerp:

  • Verklein het bereik van het token: splits één breed token op in meerdere tokens met een beperktere reikwijdte.
  • Wissel volgens schema: Draaien gebeurt zelfs als er niets "mis" is, waardoor draaien een automatisme wordt.
  • Poortproductie: expliciete goedkeuring is vereist voor identiteiten die in productie worden geïmplementeerd.
  • Blokkeer geheimen in platte tekst tijdens het bouwen.CI moet builds laten mislukken wanneer er duidelijke geheime patronen verschijnen.

Elke beweging verkleint de explosieradius, zelfs als er nog steeds een lek optreedt.

Een eenvoudig intern beleid dat veel ellende voorkomt.

Als je één beleid wilt dat beter gedrag afdwingt, dan is het dit:

  • Geen productiegeschikte geheimen op de laptops van ontwikkelaars of in de containeromgevingen.

Die regel leidt tot veranderingen zoals:

  • workload-identiteit voor services
  • stage-referenties voor ontwikkeling
  • en expliciete goedkeuringen voor de implementatiestappen in productie

Het is in eerste instantie vervelend, maar het sluit de gemakkelijkste lekroutes af.

Kortom

Niet-menselijke identiteiten vormen de ruggengraat van moderne automatisering, maar zijn tegelijkertijd ook een belangrijke oorzaak van datalekken, omdat ze vaak de beveiligingsmaatregelen omzeilen die we voor mensen hebben ingebouwd.

Als je een praktische drempel wilt: zodra je de vragen "waar bevinden onze langlopende tokens zich, wie is de eigenaar ervan en hoe snel kunnen we ze intrekken/vervangen" kunt beantwoorden, ben je van een wensdroom overgegaan naar een echt verdedigingsprogramma.

De praktische oplossing is niet één magische scanner. Het is een programma: minimaliseer statische geheimen, verklein privileges, maak rotatie een routine en monitor machine-identiteiten zoals je gebruikersaccounts monitort.

Bronnen

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 Nederlands