Mitte-inimlikud identiteedid on rikkumiste mootor: miks märgid ja teenusekontod pidevalt lekivad

/Tehnoloogia/ Autor

Mitte-inimlikud identiteedid – API-võtmed, märgid, teenusekontod, töökoormuse identiteedid – on nüüdseks üks lihtsamaid viise tänapäevastesse pilvekeskkondadesse pääsemiseks. Mitte sellepärast, et ründajatest oleksid järsku geeniused saanud, vaid seetõttu, et organisatsioonid tuginevad üha enam masinatevahelisele usaldusele ning see usaldus on sageli liiga lai, pikaajaline ja halvasti jälgitav.

Aruannetes esile tõstetud uus analüüs osutab tuttavale mustrile laiaulatuslikus ulatuses: tuhanded konteineri kujutised ja repositooriumid paljastavad kogemata saladusi, mis annavad vaikselt juurdepääsu tootmissüsteemidele. Probleem ei seisne ainult selles, et arendajad teevad mõnikord vigu. Probleem on selles, et vaikimisi tööriistad ja stiimulid muudavad selle...lihtnesaladusi saatma jakõvatõestamaks, et sa seda ei teinud.

See on „nähtamatu rikkumise“ lugu. Paljud ohurünnakud ei alga ärakasutamise või valju pahavarajuhtumiga. Need algavad tokeniga, mis autentib puhtalt – nii et kõik näeb normaalne välja – kuni saate aru, et seda on kasutanud vale litsents.

Mis on (lihtsalt öeldes) „mitteinimlikud identiteedid”?

Mitte-inimese identiteet (NHI) on igasugune volitus, mis võimaldab tarkvaral autentida usaldusväärse osalejana:

  • pilvepääsuvõtmed ja seansi märgid
  • teenusekontod ja töökoormuse identiteedid
  • Ehitustorustike poolt kasutatavad CI/CD mandaadid
  • SaaS-tööriistade (GitHub, GitLab, Slack, jälgimisplatvormid) tokenid
  • Kolmandate osapoolte teenuste API-võtmed (makseteenuse pakkujad, e-posti pakkujad, tehisintellekti mudeli API-d)

Oluline erinevus inimeste sisselogimistest on see, et NHI-d tavaliselt:

  • pidevalt töötama
  • on koodi või konfiguratsiooni sisse põimitud
  • ja sageli ei kasuta MFA-d

See teeb nad atraktiivseks.

Kui ründaja saab toimiva tokeni, ei pea ta sisse murdma. Ta autentib.

Miks see nüüd hullemaks läheb

Kolm suundumust suruvad NHI-d „olulisest” „domineeriva riskini”:

1) Tarkvara tarneahelad on suuremad kui kunagi varem

Kaasaegsed rakendused on kokku pandud järgmistest osadest:

  • konteinerid
  • avatud lähtekoodiga sõltuvused
  • infrastruktuur koodina
  • kümneid SaaS-integratsioone

Iga integratsioon lisab uue volikirja.

2) Automatiseerimine on kõikjal

Organisatsioonid soovivad:

  • kiirem juurutamine
  • iseteeninduslik infrastruktuur
  • lühiajalised keskkonnad

Automatiseerimine on hea, aga seda toetavad identiteedid, millel on privileegid.

3) Volikirjad kestavad kauem kui inimesed, kes need lõid

Inimesed vahetavad rolle ja lahkuvad.

Kuid repositooriumis või konteineris olev token saab:

  • püsima kuude või aastate jooksul
  • kopeeritakse uutesse versioonidesse
  • ja jäävad kehtima kaua pärast seda, kui keegi mäletab selle olemasolu

Seega rünnakupind kasvab vaikselt.

Kuidas saladused päriselus lekivad (see ei ole alati "keegi võtme sisse murdnud")

Stereotüüp on arendaja, kes paneb toimeAWS_SECRET_ACCESS_KEYGitHubile.

Seda ikka juhtub. Aga suur osa lekketest on vähem ilmne:

  • konteineri kihtidesse küpsetatud žetoonid
  • konfiguratsioonifailid kopeeriti ehituse ajal piltidesse
  • saladusi sisaldavad silumislogid
  • Vestluses jagatud ja hiljem koodi kleebitud „ajutised” võtmed
  • Valesti konfigureeritud torujuhtmete poolt prinditud CI muutujad

Ja konteinerpildid on eriti ohtlikud, sest:

  • nad peegelduvad
  • need salvestatakse vahemällu
  • neid kopeeritakse meeskondade vahel

Isegi kui võtme hoidlast kustutate, võib see vanadesse pildikihtidesse jääda.

Miks lekkinud märgid on ohtlikumad kui paljud ärakasutamised

Turvaaukude ärakasutamised on lärmakad. Need käivitavad sageli alarme.

Lekkinud märgid on vaiksed. Need näevad sageli välja nagu tavaline kasutus:

  • edukas autentimine
  • korrektsed API-kõned
  • õigustatud lõpp-punktid

See muudab kaitsja probleemi.

„Ründaja” tuvastamise asemel peate tuvastama:

  • ootamatudirektorkehtivate volituste kasutamine
  • ebatavalistest kohtadest
  • ebatavalistel aegadel
  • ebatavaliste toimingute tegemine

Seepärast on NHI-d paljude organisatsioonide jaoks avastamislünk.

Privileegide probleem: märgid on sageli liiga võimsad

Paljud saladused luuakse otseteedena, mis aitavad asjal tööle hakata:

  • laialdased pilveõigused
  • administraatori tasemel API juurdepääs
  • pikaealised võtmed

Ja kui süsteem töötab, ei taha inimesed seda puutuda.

See loob ohtliku asümmeetria:

  • inimese kontol võib olla MFA ja jälgimine
  • masina identiteedil võib olla lai juurdepääs ja vähe kontrolli

Kui masina identiteet lekib, võib plahvatusraadius olla suurem.

Milline näeb välja hea NHI strateegia (konkreetsed tavad)

See on lahendatav, aga ainult siis, kui käsitlete riiklikke tervisekindlustusi esmaklassiliste turvavaradena.

1) Eelista lühiajalisi volitusi

Võimaluse korral:

  • kasutage ajutisi seansi volitusi
  • vahetage žetoone sageli
  • Väldi võtmeid, mis ei aegu kunagi

Lühiajalised märgid vähendavad lekete tasuvust.

2) Asendage staatilised võtmed töökoormuse identiteediga, kus see on võimalik

Kaasaegsetes pilvesüsteemides saab töökoormusi sageli autentida järgmiselt:

  • eksemplari identiteet
  • OIDC föderatsioon
  • hallatud identiteet

See vähendab vajadust staatiliste võtmete salvestamise järele.

3) Eraldage keskkonnad rangelt

Levinud tõrge on sama märgi kasutamine järgmistes valdkondades:

  • arendaja
  • lavastus
  • tootmine

Tokenid peaksid olema keskkonnapõhised.

Kui arendaja pildifail lekib, ei tohiks see tootmist avada.

4) Inventuur ja omandiõigus

Igal tähendusrikkal märgil peaks olema:

  • omanik
  • eesmärk
  • eeldatav kasutusmuster

Kui tokenil pole omanikku, on see tehniline võlg, mis ootab intsidendiks muutumist.

5) Jälgige NHI käitumist samamoodi nagu jälgite inimeste käitumist

Heade signaalide hulka kuuluvad:

  • võimatu reisimine / ebatavalised geograafiad
  • ebatavalised API-kõnede järjestused
  • andmetele juurdepääsu järsk tõus
  • uued õigused antud
  • uued žetoonid loodud

Eesmärk ei ole täiuslik avastamine; eesmärk on varajane avastamine.

6) Käsitlege CI/CD-d kõrge riskiga identiteeditehase rollis

CI-süsteemides on sageli:

  • juurutamisvõtmed
  • allkirjastamisvõtmed
  • pilvepõhised mandaadid

Lukusta need kinni:

  • vähim privileeg
  • eraldatud jooksjad
  • salajane maskeerimine ja logilekete ennetamine
  • ranged kinnitused tootmiskeskkonna juurutamise etappidele

Kus meeskonnad tavaliselt ebaõnnestuvad (ja kuidas seda vältida)

„Me vahetame vahel võtmeid” pole plaan

Kui pöörlemine on käsitsi teostatav ja valulik, siis surve all see ei toimu.

Muutke rotatsioon rutiinseks ja automatiseeritud.

Turvatööriistad ilma jõustamiseta muutuvad "jälgimisalaks"

Salajaste andmete otsimine hoidlatest on kasulik, aga sellest üksi ei piisa.

Teil on vaja ka:

  • kiire tühistamine
  • kasutamise kohta käivad hoiatused
  • ja ennetamine ehitustorustike puhul

Konteineri kihi lõks

Kui saladused on kunagi konteineri loomise konteksti sattunud, siis eeldage, et need võivad eksisteerida järgmistes kohtades:

  • vanad pildid
  • vahemällu salvestatud kihid
  • CI artefaktid

Parandus ei ole ainult "repo võtme kustutamine". See on:

  • pöörake saladust
  • piltide taastamine ja uuesti avaldamine
  • tühista vahemälud võimaluse korral

Mida järgmisena vaadata

Kui soovite jälgida, kas organisatsioonid parandavad riiklikke tervisekindlustusi (NHI), otsige järgmist:

  • lühiajalise identiteedi (OIDC/töökoormuse identiteet) kasutuselevõtt
  • laialt levinud žetoonide rotatsiooniprogrammid
  • tugevam CI/CD piirikontroll
  • intsidentide aruanded, mis peamise põhjusena märgivad, et kasutati kehtivaid volitusi

Jälgige ka tööriistade poolt: parimad tööriistad nihkuvad „paljastatud stringide tuvastamiselt“ „olemasolevate staatiliste saladuste arvu vähendamisele“.

Majandus: miks ründajad armastavad žetoonide jahtimist

Žetoonide jahikaalud.

Ründaja, kes varastab ühe toimiva volituse, saab sageli:

  • juurdepääs mitmele süsteemile (pilv + lähtekoodi kontroll + CI)
  • kasutada sama tehnikat paljudes organisatsioonides
  • ja müüa juurdepääsu turgudel, kui nad ei soovi seda ise hallata

Kaitsjate jaoks tähendab see, et oht pole lihtsalt „meid sihikule võtnud häkker“. See on „masinmajandus, mis teenib kasu igast korduvkasutatavast volitusest“.

Seepärast on ennetamine siinkohal väärtuslikum kui reageerimine. Kui võtit pole staatilisel kujul kunagi eksisteerinud, ei saa seda hiljem hankida.

Betooni tuvastamise ideed (millele tähelepanu pöörata)

Kui lood NHI-de tuvastusmehhanisme, keskendu pigem käitumuslikele muutustele kui maagilistele märksõnadele.

Kõrge signaali näited:

  • Teenusekonto, mida kasutatakse saidiltuus riik/ASNseda pole varem kunagi kasutatud.
  • Tavaliselt ainult ühte API-t kutsuv token hakkab ootamatult ressursse loetlema või suuri mahtusid alla laadima.
  • CI-identiteet, mis teeb toiminguid väljaspool tavapärast avaldamisaega.
  • Interaktiivsete kasutajate lõpp-punktide saladused, mida kasutati juhul, kui need olid mõeldud ainult serveri töökoormuste jaoks.

Isegi põhilised anomaaliateated suudavad varakult tuvastada „vaikse volituste varguse” mustri.

Betooni kõvenemise ideed (väike pingutus, suur kang)

Need on praktilised muudatused, mida enamik meeskondi saab teha ilma ulatusliku ümberkujundamiseta:

  • Vähenda tokeni ulatust: jaga üks lai märk mitmeks kitsa ulatusega märgiks.
  • Pööra graafiku järgi: pöörlemine isegi siis, kui miski pole "valesti", nii muutub pöörlemine lihasmäluks.
  • Väravate tootmine: tootmiskeskkonna juurutamise identiteetide jaoks on vaja selgesõnalist kinnitust.
  • Blokeeri lihtteksti saladused järkudesCI peaks ebaõnnestuma, kui ilmnevad ilmsed salajased mustrid.

Iga liigutus vähendab plahvatusraadiust isegi siis, kui leke ikkagi tekib.

Lihtne sisepoliitika, mis hoiab ära palju valu

Kui soovite ühte poliitikat, mis sunnib paremat käitumist, siis see on järgmine:

  • Arendaja sülearvutites või konteinerite loomise kontekstides puuduvad tootmiskõlblikud saladused.

See reegel soodustab selliseid muudatusi nagu:

  • teenuste töökoormuse identiteet
  • arenduse ettevalmistusvolitused
  • ja selgesõnalised kinnitused tootmiskeskkonna juurutamise etappidele

Alguses on see tüütu, aga see lõikab ära kõige lihtsamad lekketeed.

Lõpptulemus

Mitte-inimlikud identiteedid on tänapäevase automatiseerimise selgroog – ja ka peamine turvarikkumiste põhjustaja, kuna need mööduvad sageli inimeste jaoks loodud kaitsemeetmetest.

Kui soovite praktilist läve: kui saate vastata küsimusele „kus meie pikaealised märgid elavad, kellele need kuuluvad ja kui kiiresti saame neid tühistada/pöörata“, olete liikunud soovmõtlemisest reaalse kaitseprogrammini.

Praktiline lahendus pole üks maagiline skanner. See on programm: minimeerige staatilisi salasõnu, vähendage õigusi, tehke rotatsioonirutiiniks ja jälgige masinate identiteete samamoodi nagu jälgite kasutajakontosid.

Allikad

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 Eesti