Tożsamości niebędące tożsamościami ludzkimi są motorem naruszeń: dlaczego tokeny i konta usługowe są stale ujawniane

/Technologia/ Przez

Tożsamości niebędące tożsamościami ludzkimi — klucze API, tokeny, konta usług, tożsamości obciążeń — stanowią obecnie jeden z najłatwiejszych sposobów dostępu do nowoczesnych środowisk chmurowych. Nie dlatego, że atakujący nagle stali się geniuszami, ale dlatego, że organizacje coraz częściej opierają się na zaufaniu między maszynami, a to zaufanie jest często zbyt szerokie, długotrwałe i słabo monitorowane.

Nowa analiza, o której mowa w raporcie, wskazuje na znany schemat na ogromną skalę: tysiące obrazów kontenerów i repozytoriów przypadkowo ujawniają sekrety, które po cichu zapewniają dostęp do systemów produkcyjnych. Problem nie polega tylko na tym, że programiści czasami popełniają błędy. Problem polega na tym, że domyślne narzędzia i zachęty sprawiają, że…łatwyaby przesyłać tajemnice itwardyaby udowodnić, że tego nie zrobiłeś.

To historia o „niewidzialnym naruszeniu”. Wiele naruszeń nie zaczyna się od exploita ani głośnego ataku złośliwego oprogramowania. Zaczynają się od tokena, który uwierzytelnia się bezbłędnie – więc wszystko wygląda normalnie – dopóki nie zorientujesz się, że używa go niewłaściwy podmiot.

Czym są „tożsamości nieludzkie” (w prostych słowach)

Tożsamość nieludzka (NHI) to dowolne poświadczenie umożliwiające oprogramowaniu uwierzytelnienie się jako zaufany podmiot:

  • klucze dostępu do chmury i tokeny sesji
  • konta usług i tożsamości obciążeń
  • Poświadczenia CI/CD używane przez potoki kompilacji
  • tokeny dla narzędzi SaaS (GitHub, GitLab, Slack, platformy monitorujące)
  • Klucze API dla usług stron trzecich (dostawców płatności, dostawców poczty e-mail, interfejsów API modeli AI)

Istotną różnicą w porównaniu z logowaniem ludzkim jest to, że NHI zazwyczaj:

  • działać nieprzerwanie
  • są osadzone w kodzie lub konfiguracji
  • i często nie używamy MFA

To właśnie czyni je atrakcyjnymi.

Jeśli atakujący uzyska działający token, nie musi się „włamywać”. Musi się uwierzytelnić.

Dlaczego teraz jest coraz gorzej

Trzy trendy powodują, że NHI przestają być instytucjami „istotnego” ryzyka i stają się instytucjami „dominującego ryzyka”:

1) Łańcuchy dostaw oprogramowania są większe niż kiedykolwiek

Nowoczesne aplikacje są tworzone z:

  • pojemniki
  • zależności typu open source
  • infrastruktura jako kod
  • dziesiątki integracji SaaS

Każda integracja dodaje kolejne dane uwierzytelniające.

2) Automatyzacja jest wszędzie

Organizacje chcą:

  • szybsze wdrażanie
  • infrastruktura samoobsługowa
  • środowiska efemeryczne

Automatyzacja jest dobra, ale opiera się na tożsamościach, które mają przywileje.

3) Poświadczenia są trwalsze niż osoby, które je stworzyły

Ludzie zamieniają się rolami i odchodzą.

Ale token w repozytorium lub kontenerze może:

  • utrzymywać się przez miesiące lub lata
  • zostać skopiowane do nowych kompilacji
  • i pozostają ważne długo po tym, jak ktokolwiek przypomni sobie o ich istnieniu

Więc powierzchnia ataku rośnie bezgłośnie.

Jak sekrety wyciekają w prawdziwym życiu (nie zawsze jest tak, że „ktoś ujawnił klucz”)

Stereotyp to deweloper, który popełniaAWS_SECRET_ACCESS_KEYdo GitHub.

To nadal się zdarza. Ale wiele wycieków jest mniej oczywistych:

  • tokeny wtopione w warstwy kontenerów
  • pliki konfiguracyjne kopiowane do obrazów podczas kompilacji
  • dzienniki debugowania zawierające sekrety
  • „tymczasowe” klucze udostępniane na czacie, a później wklejane do kodu
  • Zmienne CI drukowane przez nieprawidłowo skonfigurowane potoki

Obrazy kontenerów są szczególnie niebezpieczne, ponieważ:

  • są odbijane lustrzanie
  • są buforowane
  • są kopiowane między zespołami

Nawet jeśli usuniesz klucz z repozytorium, klucz może pozostać w starych warstwach obrazu.

Dlaczego wyciekłe tokeny są groźniejsze niż wiele exploitów

Exploity są głośne i często powodują alerty.

Wyciekłe tokeny są ukryte. Często wyglądają jak te używane normalnie:

  • pomyślne uwierzytelnienie
  • poprawne wywołania API
  • legalne punkty końcowe

To zmienia sytuację obrońcy.

Zamiast wykrywać „atakującego” należy wykryć:

  • nieoczekiwanegłównyużywając ważnych danych uwierzytelniających
  • z nietypowych lokalizacji
  • w nietypowych momentach
  • wykonywanie nietypowych czynności

Dlatego właśnie NHI stanowią lukę w wykrywaniu dla wielu organizacji.

Problem przywilejów: tokeny są często zbyt potężne

Wiele sekretów powstaje jako skróty pozwalające „zadziałać”:

  • szerokie uprawnienia w chmurze
  • dostęp do API na poziomie administratora
  • klucze o długiej żywotności

A gdy system już zadziała, ludzie nie będą chcieli się z nim mierzyć.

To stwarza niebezpieczną asymetrię:

  • konto ludzkie może mieć uwierzytelnianie wieloskładnikowe i monitorowanie
  • tożsamość maszyny może mieć szeroki dostęp i być poddawana niewielkiej kontroli

W przypadku wycieku danych o maszynie promień rażenia może być większy.

Jak wygląda dobra strategia NHI (konkretne praktyki)

Można to rozwiązać, ale tylko jeśli traktujemy NHI jako najwyższej klasy środki bezpieczeństwa.

1) Preferuj krótkotrwałe referencje

Jeśli to możliwe:

  • użyj tymczasowych danych uwierzytelniających sesję
  • często obracaj tokenami
  • unikaj kluczy „nigdy nie wygasających”

Krótkotrwałe tokeny zmniejszają zyski z wycieków.

2) Zastąp klucze statyczne tożsamością obciążenia, jeśli to możliwe

W nowoczesnych środowiskach chmurowych uwierzytelnianie obciążeń roboczych często można przeprowadzić za pośrednictwem:

  • tożsamość instancji
  • Federacja OIDC
  • zarządzana tożsamość

Zmniejsza to konieczność przechowywania kluczy statycznych.

3) Ściśle oddziel środowiska

Częstym błędem jest używanie tego samego tokena w:

  • deweloper
  • inscenizacja
  • produkcja

Tokeny powinny mieć zasięg środowiskowy.

Jeśli obraz deweloperski wycieknie, nie powinno to spowodować odblokowania wersji produkcyjnej.

4) Zapasy i własność

Każdy znaczący token powinien posiadać:

  • właściciel
  • cel
  • oczekiwany wzorzec użytkowania

Jeśli token nie ma właściciela, stanowi dług techniczny, który tylko czeka, aż stanie się incydentem.

5) Monitoruj zachowanie NHI tak, jak monitorujesz zachowanie człowieka

Dobre sygnały obejmują:

  • niemożliwa podróż / niezwykłe miejsca geograficzne
  • nietypowe sekwencje wywołań API
  • skoki w dostępie do danych
  • przyznano nowe uprawnienia
  • utworzono nowe tokeny

Celem nie jest idealne wykrywanie, lecz wczesne wykrywanie.

6) Traktuj CI/CD jako fabrykę tożsamości wysokiego ryzyka

Systemy CI często obejmują:

  • klucze wdrożeniowe
  • klucze do podpisywania
  • poświadczenia chmurowe

Zamknij je:

  • najmniejszy przywilej
  • oddzieleni biegacze
  • maskowanie poufne i zapobieganie wyciekom logów
  • surowe zatwierdzenia etapów wdrażania produkcji

Gdzie zespoły zazwyczaj zawodzą (i jak tego uniknąć)

„Czasami zmieniamy klucze” to nie jest plan

Jeśli rotacja jest wykonywana ręcznie i jest bolesna, nie uda się jej wykonać pod ciśnieniem.

Uczyń rotację rutynową i zautomatyzowaną.

Narzędzia bezpieczeństwa bez egzekwowania stają się „teatrem monitorowania”

Skanowanie repozytoriów w celu znalezienia sekretów jest przydatne, ale to nie wystarczy.

Potrzebujesz również:

  • szybkie odwołanie
  • alerty dotyczące użytkowania
  • i zapobieganie w budowie rurociągów

Pułapka warstwy kontenera

Jeśli sekrety kiedykolwiek weszły do ​​kontekstu kompilacji kontenera, należy założyć, że mogą istnieć w:

  • stare obrazy
  • buforowane warstwy
  • Artefakty CI

Rozwiązaniem nie jest tylko „usunięcie klucza repozytorium”. Jest to:

  • obróć sekret
  • odbudować i ponownie opublikować obrazy
  • unieważnij pamięć podręczną, jeśli to możliwe

Co obejrzeć dalej

Jeśli chcesz śledzić, czy organizacje osiągają lepsze wyniki w zakresie NHI, zwróć uwagę na:

  • przyjęcie tożsamości krótkotrwałej (OIDC/tożsamość obciążenia)
  • szeroko rozpowszechnione programy rotacji tokenów
  • silniejsze kontrole granic CI/CD
  • raporty o incydentach, w których jako główną przyczynę podano „użyto ważnych danych uwierzytelniających”

Warto też zwrócić uwagę na kwestię narzędzi: najlepsze narzędzia przejdą od „wykrywania odsłoniętych ciągów znaków” do „ograniczenia liczby istniejących statycznych sekretów”.

Ekonomia: dlaczego atakujący uwielbiają polować na tokeny

Wagi do polowań na żetony.

Osoba atakująca, która ukradnie jedno działające poświadczenie, może często:

  • dostęp do wielu systemów (chmura + kontrola źródła + CI)
  • ponowne wykorzystanie tej samej techniki w wielu organizacjach
  • i sprzedawać dostęp na rynkach, jeśli nie chcą sami nim zarządzać

Dla obrońców oznacza to, że zagrożeniem nie jest po prostu „haker atakujący nas”. To „gospodarka maszynowa, która czerpie zyski z wszelkich wielokrotnego użytku danych uwierzytelniających”.

Dlatego zapobieganie jest tu ważniejsze niż reagowanie. Jeśli klucz nigdy nie istniał w formie statycznej, nie da się go później zebrać.

Pomysły na wykrywanie betonu (na co zwracać uwagę)

Jeśli tworzysz mechanizmy wykrywania chorób niezakaźnych (NHI), skup się na zmianach zachowania, a nie na magicznych słowach kluczowych.

Przykłady wysokiego sygnału:

  • Konto usługi używane znowy kraj/ASNNigdy wcześniej nie był używany.
  • Token, który normalnie wywołuje tylko jedno API, nagle wylicza zasoby lub pobiera duże ilości.
  • Tożsamość CI wykonująca działania poza standardowym oknem wydania.
  • Sekrety używane w interaktywnych punktach końcowych użytkowników, gdy były przeznaczone wyłącznie do obciążeń serwerowych.

Nawet podstawowe alerty o anomaliach mogą wcześnie wykryć zjawisko „cichej kradzieży danych uwierzytelniających”.

Pomysły na utwardzanie betonu (niski wysiłek, duża dźwignia)

Oto praktyczne zmiany, które większość zespołów może wprowadzić bez konieczności przeprowadzania gruntownej przebudowy:

  • Zmniejsz zakres tokena:podzielić jeden szeroki token na kilka tokenów o wąskim zakresie.
  • Rotacja zgodnie z harmonogramem:obracaj nawet wtedy, gdy nic nie jest „nie tak”, dzięki czemu rotacja staje się pamięcią mięśniową.
  • Produkcja bram:wymagają wyraźnego zatwierdzenia dla tożsamości wdrożeniowych w środowisku produkcyjnym.
  • Blokuj sekrety tekstu jawnego w kompilacjach:CI powinno kończyć się niepowodzeniem kompilacji, gdy pojawią się oczywiste, tajne wzorce.

Każdy ruch zmniejsza promień wybuchu, nawet jeśli nadal nastąpi wyciek.

Prosta wewnętrzna polityka, która zapobiega wielu bólom

Jeśli szukasz polityki, która wymusza lepsze zachowania, to jest to ta:

  • Żadnych sekretów mogących mieć zastosowanie w produkcji na laptopach programistów lub w kontekstach budowania kontenerów.

Zasada ta powoduje zmiany takie jak:

  • tożsamość obciążenia pracą dla usług
  • poświadczenia dotyczące inscenizacji rozwoju
  • i wyraźne zatwierdzenia etapów wdrażania produkcji

Na początku może to być denerwujące, ale w efekcie odcina najłatwiejsze ścieżki przecieku.

Podsumowanie

Tożsamości niebędące ludźmi stanowią podstawę współczesnej automatyzacji, a także są głównym powodem naruszeń bezpieczeństwa, ponieważ często omijają zabezpieczenia, które stworzyliśmy dla ludzi.

Jeśli chcesz praktycznego progu: gdy będziesz w stanie odpowiedzieć na pytanie „gdzie znajdują się nasze długotrwałe tokeny, kto jest ich właścicielem i jak szybko możemy je unieważnić/obrócić”, przesunąłeś się od myślenia życzeniowego do rzeczywistego programu obronnego.

Praktycznym rozwiązaniem nie jest jeden magiczny skaner. To program: minimalizuje statyczne sekrety, zmniejsza uprawnienia, tworzy rutynową rotację i monitoruje tożsamości maszyn tak, jak monitoruje się konta użytkowników.

Źródła

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 Polski