Nicht-menschliche Identitäten als Einfallstor für Sicherheitslücken: Warum Tokens und Servicekonten immer wieder offengelegt werden

/Technologie/ Von

Nicht-menschliche Identitäten – API-Schlüssel, Token, Servicekonten, Workload-Identitäten – gehören heute zu den einfachsten Einfallstoren in moderne Cloud-Umgebungen. Nicht etwa, weil Angreifer plötzlich zu Genies geworden wären, sondern weil Unternehmen zunehmend auf maschinellem Vertrauen basieren, das oft zu weit gefasst, langfristig angelegt und unzureichend überwacht ist.

Eine neue Analyse, die in einem Bericht hervorgehoben wurde, deutet auf ein bekanntes Muster in großem Ausmaß hin: Tausende von Container-Images und Repositories geben versehentlich Geheimnisse preis, die unbemerkt Zugriff auf Produktionssysteme ermöglichen. Das Problem ist nicht nur, dass Entwickler manchmal Fehler machen. Das Problem ist, dass die Standardwerkzeuge und Anreize dies begünstigen.einfachSchiffsgeheimnisse undhartum zu beweisen, dass du es nicht getan hast.

Dies ist eine Geschichte über einen „unsichtbaren Sicherheitsverstoß“. Viele Sicherheitslücken beginnen nicht mit einer Sicherheitslücke oder einem auffälligen Malware-Vorfall. Sie beginnen mit einem Token, der sich problemlos authentifiziert – alles scheint also normal –, bis man feststellt, dass er von der falschen Person verwendet wurde.

Was sind „nicht-menschliche Identitäten“ (in einfachen Worten)?

Eine nicht-menschliche Identität (NHI) ist jede Berechtigungsbestätigung, die es einer Software ermöglicht, sich als vertrauenswürdiger Akteur zu authentifizieren:

  • Cloud-Zugriffsschlüssel und Sitzungstoken
  • Dienstkonten und Workload-Identitäten
  • CI/CD-Zugangsdaten, die von Build-Pipelines verwendet werden
  • Tokens für SaaS-Tools (GitHub, GitLab, Slack, Monitoring-Plattformen)
  • API-Schlüssel für Drittanbieterdienste (Zahlungsanbieter, E-Mail-Anbieter, KI-Modell-APIs)

Der wesentliche Unterschied zu menschlichen Logins besteht darin, dass NHIs typischerweise:

  • laufen kontinuierlich
  • sind im Code oder in der Konfiguration eingebettet
  • und nutzen häufig keine MFA.

Das macht sie attraktiv.

Wenn ein Angreifer ein funktionierendes Token erlangt, muss er nicht „einbrechen“. Er authentifiziert sich.

Warum wird das jetzt immer schlimmer?

Drei Trends führen dazu, dass nationale Krankenversicherungen von einem „wichtigen“ zu einem „dominanten Risiko“ werden:

1) Die Lieferketten für Software sind größer als je zuvor

Moderne Apps setzen sich aus Folgendem zusammen:

  • Container
  • Open-Source-Abhängigkeiten
  • Infrastruktur als Code
  • Dutzende von SaaS-Integrationen

Jede Integration erfordert eine weitere Anmeldeinformation.

2) Automatisierung ist allgegenwärtig

Organisationen wünschen sich:

  • schnellere Bereitstellungen
  • Selbstbedienungsinfrastruktur
  • ephemere Umgebungen

Automatisierung ist gut – aber sie basiert auf Identitäten mit entsprechenden Berechtigungen.

3) Zugangsdaten sind länger gültig als die Personen, die sie erstellt haben.

Menschen wechseln ihre Rollen und gehen.

Ein Token in einem Repository oder einem Container kann jedoch Folgendes:

  • über Monate oder Jahre anhalten
  • in neue Builds kopiert werden
  • und bleiben lange gültig, nachdem sich niemand mehr daran erinnert, dass es existiert

So wächst die Angriffsfläche unbemerkt.

Wie Geheimnisse im wirklichen Leben ans Licht kommen (es ist nicht immer so, dass „jemand einen Schlüssel verloren hat“)

Das Stereotyp ist ein Entwickler, der sich verschuldetAWS_SECRET_ACCESS_KEYzu GitHub.

Das kommt immer noch vor. Viele Leckagen sind jedoch weniger offensichtlich:

  • Tokens in Containerschichten eingebettet
  • Konfigurationsdateien werden während des Build-Prozesses in die Images kopiert.
  • Debug-Protokolle, die Geheimnisse enthalten
  • „Temporäre“ Schlüssel, die im Chat ausgetauscht und später in den Code eingefügt wurden
  • Von falsch konfigurierten Pipelines ausgegebene CI-Variablen

Und Container-Images sind besonders gefährlich, weil:

  • Sie werden gespiegelt
  • Sie werden zwischengespeichert
  • Sie werden zwischen den Teams kopiert.

Selbst wenn Sie den Schlüssel aus dem Repository löschen, kann der Schlüssel in alten Image-Layern erhalten bleiben.

Warum durchgesickerte Token gefährlicher sind als viele Exploits

Exploits sind auffällig. Sie lösen häufig Warnmeldungen aus.

Durchgesickerte Tokens sind unauffällig. Sie sehen oft wie normale Nutzung aus:

  • erfolgreiche Authentifizierung
  • korrekte API-Aufrufe
  • legitime Endpunkte

Das ändert das Problem des Verteidigers.

Statt einen „Angreifer“ zu erkennen, muss man Folgendes erkennen:

  • ein unerwartetesRektorVerwendung gültiger Anmeldeinformationen
  • von ungewöhnlichen Orten
  • zu ungewöhnlichen Zeiten
  • ungewöhnliche Handlungen

Aus diesem Grund stellen NHIs für viele Organisationen eine Erkennungslücke dar.

Das Privilegienproblem: Tokens sind oft zu mächtig

Viele Geheimnisse entstehen als „Abkürzungen, die zum Funktionieren bringen sollen“:

  • weitreichende Cloud-Berechtigungen
  • API-Zugriff auf Administratorebene
  • langlebige Schlüssel

Und wenn das System erst einmal funktioniert, will es niemand mehr anfassen.

Dadurch entsteht eine gefährliche Asymmetrie:

  • Ein menschliches Konto könnte über MFA und Überwachung verfügen.
  • Die Maschinenidentität könnte weitreichenden Zugriff und geringe Überprüfung haben.

Wenn die Identität der Maschine durchsickert, kann der Wirkungsbereich größer sein.

Wie eine gute NHI-Strategie aussieht (konkrete Praktiken)

Das Problem ist lösbar, aber nur, wenn man nationale Gesundheitseinrichtungen als erstklassige Sicherheitsanlagen behandelt.

1) Bevorzugen Sie kurzlebige Qualifikationen

Soweit möglich:

  • Temporäre Sitzungsanmeldeinformationen verwenden
  • Spielsteine ​​häufig drehen
  • Vermeiden Sie Schlüssel mit der Bezeichnung „Läuft nie ab“.

Kurzlebige Token verringern den Nutzen von Lecks.

2) Ersetzen Sie statische Schlüssel nach Möglichkeit durch Workload-Identitäten.

In modernen Cloud-Umgebungen können Workloads häufig über folgende Wege authentifiziert werden:

  • Instanzidentität
  • OIDC-Föderation
  • verwaltete Identität

Dadurch verringert sich der Bedarf, statische Schlüssel zu speichern.

3) Trennen Sie die Umgebungen strikt

Ein häufiger Fehler ist die Verwendung desselben Tokens für verschiedene Bereiche:

  • Entwickler
  • Inszenierung
  • Produktion

Tokens sollten umgebungsbezogen sein.

Wenn ein Entwickler-Image durchsickert, sollte dies die Produktionsversion nicht freischalten.

4) Inventar und Eigentum

Jedes sinnvolle Token sollte Folgendes aufweisen:

  • ein Eigentümer
  • ein Zweck
  • ein erwartetes Nutzungsmuster

Wenn ein Token keinen Besitzer hat, stellt er eine technische Schuld dar, die nur darauf wartet, zu einem Zwischenfall zu führen.

5) Überwachen Sie das Verhalten von NHIs genauso wie Sie das Verhalten von Menschen überwachen.

Gute Anzeichen sind unter anderem:

  • Unmögliche Reisen / ungewöhnliche Geografien
  • ungewöhnliche API-Aufrufsequenzen
  • Spitzen beim Datenzugriff
  • Neue Berechtigungen erteilt
  • neue Token erstellt

Ziel ist nicht die perfekte Erkennung, sondern die Früherkennung.

6) CI/CD als Hochrisiko-Identitätsfabrik behandeln

CI-Systeme enthalten häufig:

  • Bereitstellungsschlüssel
  • Signaturschlüssel
  • Cloud-Zugangsdaten

Sperrt sie ein:

  • geringstes Privileg
  • getrennte Läufer
  • Geheime Verschleierung und Verhinderung von Protokolllecks
  • strenge Genehmigungen für Produktionsbereitstellungsschritte

Wo Teams üblicherweise scheitern (und wie man das vermeiden kann)

„Wir tauschen die Schlüssel manchmal aus“ ist kein Plan.

Wenn die Rotation manuell und schmerzhaft ist, wird sie unter Druck nicht stattfinden.

Machen Sie die Rotation zur Routine und automatisieren Sie sie.

Sicherheitsinstrumente ohne Durchsetzung verkommen zu einem „Überwachungstheater“.

Das Durchsuchen von Datenspeichern nach Geheimnissen ist zwar nützlich, aber nicht ausreichend.

Sie benötigen außerdem:

  • schneller Widerruf
  • Nutzungshinweise
  • und Prävention in Baupipelines

Die Behälterschichtfalle

Falls Geheimnisse jemals in einen Container-Build-Kontext gelangen, gehen Sie davon aus, dass sie sich möglicherweise in Folgendem befinden:

  • alte Bilder
  • zwischengespeicherte Ebenen
  • CI-Artefakte

Die Lösung besteht nicht nur darin, den Repository-Schlüssel zu löschen. Sie lautet:

  • Drehe das Geheimnis
  • Bilder neu erstellen und erneut veröffentlichen
  • Caches nach Möglichkeit ungültig machen

Was Sie als Nächstes sehen sollten

Wenn Sie überprüfen möchten, ob Organisationen ihre nationalen Gesundheitsindikatoren verbessern, achten Sie auf Folgendes:

  • Einführung einer kurzlebigen Identität (OIDC/Workload-Identität)
  • weitverbreitete Token-Rotationsprogramme
  • stärkere CI/CD-Grenzkontrollen
  • Vorfallsberichte, die „gültige Anmeldeinformationen verwendet“ als Hauptursache angeben

Achten Sie auch auf die Tool-Seite: Die besten Tools werden sich von „Erkennen offengelegter Zeichenketten“ hin zu „Reduzieren der Anzahl statischer Geheimnisse, die überhaupt existieren“ verlagern.

Die Ökonomie: Warum Angreifer die Jagd nach Tokens lieben

Token-Jagd-Skalen.

Ein Angreifer, der einen funktionierenden Zugangspunkt stiehlt, kann oft:

  • Zugriff auf mehrere Systeme (Cloud + Quellcodeverwaltung + CI)
  • Dieselbe Technik in vielen Organisationen wiederverwenden
  • und sie können den Zugang auf Marktplätzen verkaufen, wenn sie ihn nicht selbst betreiben wollen.

Für die Verteidiger bedeutet dies, dass die Bedrohung nicht nur von „einem Hackerangriff auf uns“ ausgeht. Es geht vielmehr um „eine Maschinenökonomie, die von wiederverwendbaren Anmeldeinformationen profitiert“.

Deshalb ist Prävention hier wichtiger als Reaktion. Wenn der Schlüssel nie in statischer Form existierte, kann er später nicht gewonnen werden.

Konkrete Erkennungsideen (worauf soll man reagieren?)

Wenn Sie Erkennungsmechanismen für NHIs entwickeln, konzentrieren Sie sich auf Verhaltensänderungen anstatt auf magische Schlüsselwörter.

Beispiele für hohe Signale:

  • Ein Dienstkonto, das von einemneues Land/ASNEs wurde noch nie zuvor benutzt.
  • Ein Token, das normalerweise nur eine API aufruft, listet plötzlich Ressourcen auf oder lädt große Datenmengen herunter.
  • Eine CI-Identität, die Aktionen außerhalb des normalen Release-Fensters durchführt.
  • Geheimnisse, die von interaktiven Benutzerendpunkten verwendet wurden, obwohl sie nur für Server-Workloads vorgesehen waren.

Selbst einfache Anomaliewarnungen können das Muster des „stillen Zugangsdatendiebstahls“ frühzeitig erkennen.

Ideen zur Betonhärtung (geringer Aufwand, hohe Hebelwirkung)

Dies sind praktische Änderungen, die die meisten Teams ohne eine umfassende Neugestaltung vornehmen können:

  • Token-Bereich reduzieren: einen breit gefassten Token in mehrere eng gefasste Token aufteilen.
  • Rotation nach Zeitplan: sich auch dann drehen, wenn nichts „falsch“ ist, sodass die Rotation zum Muskelgedächtnis wird.
  • Torproduktion: Für die Bereitstellung von Identitäten in der Produktion ist eine explizite Genehmigung erforderlich.
  • Klartextgeheimnisse in Builds blockierenCI sollte Builds abbrechen, wenn offensichtliche geheime Muster auftreten.

Jeder Zug verringert den Explosionsradius, selbst wenn weiterhin ein Leck auftritt.

Eine einfache interne Richtlinie, die viel Leid verhindert

Wenn Sie eine Maßnahme wollen, die besseres Verhalten erzwingt, dann diese:

  • Keine produktionsfähigen Geheimnisse auf Entwickler-Laptops oder in Container-Build-Kontexten.

Diese Regel bewirkt Veränderungen wie:

  • Workload-Identität für Dienste
  • Staging-Zugangsdaten für die Entwicklung
  • und ausdrückliche Genehmigungen für Produktionsbereitstellungsschritte

Es ist anfangs ärgerlich, aber dadurch werden die einfachsten Leckagewege abgeschnitten.

Fazit

Nicht-menschliche Identitäten sind das Rückgrat der modernen Automatisierung – und gleichzeitig ein wichtiger Treiber für Sicherheitslücken, da sie oft die Schutzmechanismen umgehen, die wir für Menschen entwickelt haben.

Wenn Sie eine praktische Schwelle festlegen wollen: Sobald Sie die Fragen beantworten können „Wo werden unsere langlebigen Token gespeichert, wem gehören sie und wie schnell können wir sie widerrufen/rotieren?“, sind Sie vom Wunschdenken zu einem echten Verteidigungsprogramm übergegangen.

Die praktische Lösung ist kein einzelner Zauberscanner. Es ist ein Programm: Statische Geheimnisse minimieren, Berechtigungen einschränken, Rotationsroutinen einführen und Maschinenidentitäten wie Benutzerkonten überwachen.

Quellen

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 Deutsch