Necilvēciskas identitātes ir datu noplūdi veicinošs faktors: kāpēc žetoni un pakalpojumu konti tiek pastāvīgi atklāti

Necilvēciskas identitātes — API atslēgas, žetoni, pakalpojumu konti, darba slodzes identitātes — tagad ir viens no vienkāršākajiem veidiem, kā iekļūt modernās mākoņvidēs. Ne tāpēc, ka uzbrucēji pēkšņi kļuva par ģēnijiem, bet gan tāpēc, ka organizācijas arvien vairāk darbojas, balstoties uz mašīnu un mašīnu savstarpēju uzticēšanos, un šī uzticēšanās bieži vien ir pārāk plaša, ilgstoša un slikti uzraudzīta.

Jaunā ziņojumā izceltā analīze norāda uz pazīstamu modeli milzīgā mērogā: tūkstošiem konteineru attēlu un repozitoriju nejauši atklāj noslēpumus, kas klusi piešķir piekļuvi ražošanas sistēmām. Problēma nav tikai tā, ka izstrādātāji dažreiz pieļauj kļūdas. Problēma ir tā, ka noklusējuma rīki un stimuli to apgrūtina.vieglilai nosūtītu noslēpumus ungrūtilai pierādītu, ka to nedarīji.

Šis ir stāsts par "neredzamu pārkāpumu". Daudzi apdraudējumi nesākas ar ielaušanos vai skaļu ļaunprogrammatūras notikumu. Tie sākas ar žetonu, kas autentificējas tīri — lai viss izskatītos normāli —, līdz brīdim, kad saprotat, ka to ir izmantojis nepareizais vadītājs.

Kas ir “necilvēciskas identitātes” (vienkārši izsakoties)?

Necilvēka identitāte (NHI) ir jebkura akreditācija, kas ļauj programmatūrai autentificēties kā uzticamai personai:

mākoņa piekļuves atslēgas un sesijas žetoni
pakalpojumu konti un darba slodzes identitātes
CI/CD akreditācijas dati, ko izmanto būvēšanas cauruļvadi
SaaS rīku (GitHub, GitLab, Slack, uzraudzības platformu) žetoni
API atslēgas trešo pušu pakalpojumiem (maksājumu pakalpojumu sniedzējiem, e-pasta pakalpojumu sniedzējiem, mākslīgā intelekta modeļu API)

Svarīga atšķirība no cilvēku pieteikšanās ir tā, ka NHI parasti:

darboties nepārtraukti
ir iegulti kodā vai konfigurācijā
un bieži neizmanto MFA

Tas padara tos pievilcīgus.

Ja uzbrucējs iegūst darbojošos žetonu, viņam nav "jāielaužas". Viņš veic autentifikāciju.

Kāpēc tagad kļūst arvien sliktāk

Trīs tendences veicina NHI statusa maiņu no “svarīga” uz “dominējošo risku”:

1) Programmatūras piegādes ķēdes ir lielākas nekā jebkad agrāk

Mūsdienu lietotnes tiek veidotas no:

konteineri
atvērtā pirmkoda atkarības
infrastruktūra kā kods
desmitiem SaaS integrāciju

Katra integrācija pievieno vēl vienu akreditācijas dokumentu.

2) Automatizācija ir visur

Organizācijas vēlas:

ātrāka izvietošana
pašapkalpošanās infrastruktūra
īslaicīgas vides

Automatizācija ir laba, taču to nodrošina identitātes ar privilēģijām.

3) Pilnvaras ir derīgas ilgāk nekā cilvēki, kas tās izveidoja

Cilvēki maina lomas un aiziet.

Bet marķieris repozitorijā vai konteinerā var:

saglabājas mēnešiem vai gadiem ilgi
tikt kopēts jaunās versijās
un paliek spēkā ilgi pēc tam, kad kāds atceras, ka tā pastāv

Tātad uzbrukuma virsma klusībā aug.

Kā noslēpumi noplūst reālajā dzīvē (ne vienmēr ir tā, ka "kāds ir uzlauzis atslēgu")

Stereotips ir izstrādātājs, kas apņemasAWS_SECRET_ACCESS_KEYuz GitHub.

Tas joprojām notiek. Taču daudzas noplūdes ir mazāk acīmredzamas:

žetoni, kas cepti konteineru slāņos
konfigurācijas faili kopēti attēlos būvēšanas laikā
atkļūdošanas žurnāli, kas satur noslēpumus
“Pagaidu” atslēgas, kas koplietotas tērzēšanā un vēlāk ielīmētas kodā
Nepareizi konfigurētu cauruļvadu izdrukāti CI mainīgie

Un konteineru attēli ir īpaši bīstami, jo:

tie tiek atspoguļoti
tie tiek kešatmiņā saglabāti
tie tiek kopēti starp komandām

Pat ja izdzēšat atslēgu no repozitorija, tā var palikt vecajos attēlu slāņos.

Kāpēc nopludinātie žetoni ir bīstamāki nekā daudzi citi uzbrukumi

Ekspluatācijas ir trokšņainas. Tās bieži vien izraisa brīdinājumus.

Nopludinātie žetoni ir klusi. Tie bieži izskatās pēc parastas lietošanas:

veiksmīga autentifikācija
pareizi API izsaukumi
likumīgi galapunkti

Tas maina aizsarga problēmu.

Tā vietā, lai atklātu "uzbrucēju", jums ir jāatklāj:

negaidītsdirektorsizmantojot derīgus akreditācijas datus
no neparastām vietām
neparastos laikos
veicot neparastas darbības

Tāpēc daudzām organizācijām NHI ir atklāšanas plaisa.

Privilēģiju problēma: žetoni bieži vien ir pārāk spēcīgi

Daudzi noslēpumi tiek izveidoti kā īsceļi “likt to darboties”:

plašas mākoņa atļaujas
administratora līmeņa API piekļuve
ilgmūžīgas atslēgas

Un, kad sistēma darbojas, cilvēki nevēlas tai pieskarties.

Tas rada bīstamu asimetriju:

cilvēka kontam var būt MFA un uzraudzība
mašīnas identitātei varētu būt plaša piekļuve un maza kontrole

Kad tiek atklāta mašīnas identitāte, sprādziena rādiuss var būt lielāks.

Kā izskatās laba NHI stratēģija (konkrētas prakses)

Tas ir atrisināms, bet tikai tad, ja NHI tiek uzskatīti par pirmklasīgiem drošības aktīviem.

1) Dodiet priekšroku īslaicīgai kvalifikācijai

Ja iespējams:

izmantot pagaidu sesijas akreditācijas datus
bieži rotēt žetonus
izvairieties no atslēgām, kuru derīguma termiņš nekad nebeidzas

Īslaicīgi žetoni samazina noplūžu atdevi.

2) Aizvietojiet statiskās atslēgas ar darba slodzes identitāti, kur tas ir iespējams

Mūsdienu mākoņpakalpojumos darba slodzes bieži var autentificēt, izmantojot:

instances identitāte
OIDC federācija
pārvaldīta identitāte

Tas samazina nepieciešamību uzglabāt statiskās atslēgas.

3) Stingri nodalīt vides

Bieži sastopama kļūme ir viena un tā paša marķiera izmantošana:

izstrādātājs
iestudējums
ražošana

Tokeniem jābūt vides tvērumā.

Ja izstrādātāja attēls noplūst, tam nevajadzētu atbloķēt produktu.

4) Inventārs un īpašumtiesības

Katram jēgpilnam tokenam jābūt:

īpašnieks
mērķis
paredzamais lietošanas modelis

Ja tokenam nav īpašnieka, tas ir tehnisks parāds, kas gaida, lai kļūtu par incidentu.

5) Uzraugiet NHI uzvedību tāpat kā jūs uzraugāt cilvēku uzvedību

Labi signāli ietver:

neiespējami ceļojumi / neparastas ģeogrāfiskās vietas
neparastas API izsaukumu secības
datu piekļuves pieaugums
piešķirtas jaunas atļaujas
izveidoti jauni žetoni

Mērķis nav perfekta atklāšana; tā ir agrīna atklāšana.

6) Izturēties pret CI/CD kā pret augsta riska identitātes fabriku

CI sistēmās bieži ir:

izvietošanas atslēgas
parakstīšanas atslēgas
mākoņa akreditācijas dati

Bloķējiet tos:

vismazākās privilēģijas
atdalīti skrējēji
slepena maskēšana un žurnālu noplūžu novēršana
stingri apstiprinājumi ražošanas ieviešanas soļiem

Kur komandas parasti cieš neveiksmes (un kā no tā izvairīties)

“Mēs dažreiz mainām atslēgas” nav plāns

Ja rotācija ir manuāla un sāpīga, tā nenotiks zem spiediena.

Padariet rotāciju rutīnu un automatizētu.

Drošības rīki bez uzraudzības kļūst par “monitoringa teātri”

Repozitoriju skenēšana, meklējot noslēpumus, ir noderīga, taču ar to nepietiek.

Jums arī nepieciešams:

ātra atsaukšana
brīdinājumi par lietošanu
un profilakse būvniecības cauruļvados

Konteinera slāņa slazds

Ja noslēpumi kādreiz ir nonākuši konteinera veidošanas kontekstā, pieņemsim, ka tie var atrasties:

veci attēli
kešatmiņā saglabātie slāņi
CI artefakti

Risinājums nav tikai "repozitorija atslēgas dzēšana". Tas ir:

pagriezt noslēpumu
atjaunot un atkārtoti publicēt attēlus
padarīt kešatmiņas nederīgas, ja iespējams

Ko skatīties tālāk

Ja vēlaties izsekot, vai organizācijas uzlabo NHI, meklējiet:

īslaicīgas identitātes (OIDC/darba slodzes identitātes) pieņemšana
plaši izplatītas žetonu rotācijas programmas
stingrāka CI/CD robežu kontrole
incidentu ziņojumi, kuros kā galvenais iemesls ir norādīts, ka “izmantoti derīgi akreditācijas dati”

Pievērsiet uzmanību arī rīku pusei: labākie rīki mainīsies no "atklātu virkņu noteikšanas" uz "vispār pastāvošo statisko noslēpumu skaita samazināšanu".

Ekonomika: kāpēc uzbrucējiem patīk žetonu medības

Žetonu medību svari.

Uzbrucējs, kurš nozog vienu derīgu akreditācijas informāciju, bieži vien var:

piekļūt vairākām sistēmām (mākonis + avota kontrole + CI)
atkārtoti izmantot vienu un to pašu metodi daudzās organizācijās
un pārdot piekļuvi tirdzniecības vietās, ja viņi paši nevēlas to pārvaldīt

Aizstāvjiem tas nozīmē, ka drauds nav tikai "hakeris, kas uzbrūk mums". Tā ir "mašīnekonomika, kas gūst peļņu no jebkuras atkārtoti izmantojamas akreditācijas".

Tāpēc profilakse šeit ir vērtīgāka nekā reaģēšana. Ja atslēga nekad nav pastāvējusi statiskā formā, to vēlāk nevar iegūt.

Betona noteikšanas idejas (par ko brīdināt)

Ja veidojat NHI noteikšanas mehānismus, koncentrējieties uz uzvedības izmaiņām, nevis maģiskiem atslēgvārdiem.

Augsta signāla piemēri:

Pakalpojuma konts, ko izmanto nojauna valsts/ASNtas nekad iepriekš nebija lietots.
Tokens, kas parasti izsauc tikai vienu API, pēkšņi uzskaita resursus vai lejupielādē lielus apjomus.
CI identitāte, kas veic darbības ārpus parastā izlaišanas loga.
Noslēpumi, kas izmantoti no interaktīviem lietotāju galapunktiem, ja tie bija paredzēti tikai serveru darba slodzēm.

Pat pamata anomāliju brīdinājumi var laikus pamanīt “klusas akreditācijas datu zādzības” modeli.

Betona sacietēšanas idejas (maza piepūle, liela ietekme)

Šīs ir praktiskas izmaiņas, ko lielākā daļa komandu var veikt bez apjomīgas pārprojektēšanas:

Samazināt marķiera darbības jomu: sadalīt vienu plašu marķieri vairākos šauri ierobežotos marķieros.
Rotēt pēc grafika: rotēt pat tad, ja nekas nav “nepareizi”, tāpēc rotācija kļūst par muskuļu atmiņu.
Vārtu ražošana: nepieciešama skaidra apstiprināšana ražošanas izvietošanas identitātēm.
Bloķēt vienkārša teksta noslēpumus versijāsCI vajadzētu neizdoties veidot, ja parādās acīmredzami slepeni modeļi.

Katra kustība samazina sprādziena rādiusu, pat ja noplūde joprojām rodas.

Vienkārša iekšējā politika, kas novērš daudz sāpju

Ja vēlaties vienu politiku, kas piespiež labāku uzvedību, tā ir šāda:

Izstrādātāju klēpjdatoros vai konteineru veidošanas kontekstos nav ražošanai piemērotu noslēpumu.

Šis noteikums veicina šādas izmaiņas:

pakalpojumu darba slodzes identitāte
izstrādes stadijā esošās akreditācijas dati
un skaidri apstiprinājumi ražošanas ieviešanas soļiem

Sākumā tas ir kaitinoši, bet tas nogriež vieglākos noplūdes ceļus.

Apakšējā līnija

Necilvēciskas identitātes ir mūsdienu automatizācijas mugurkauls un arī būtisks pārkāpumu virzītājspēks, jo tās bieži vien apiet aizsardzību, ko esam izveidojuši cilvēkiem.

Ja vēlaties praktisku slieksni: tiklīdz varat atbildēt uz jautājumu “kur atrodas mūsu ilgmūžīgie žetoni, kam tie pieder un cik ātri mēs tos varam atsaukt/pagriezt”, jūs esat pārgājuši no sapņu domāšanas uz reālu aizsardzības programmu.

Praktiskais risinājums nav viens burvju skeneris. Tā ir programma: samaziniet statiskos noslēpumus, samaziniet privilēģijas, izveidojiet rotācijas rutīnu un uzraugiet datoru identitātes tāpat kā lietotāju kontus.

Avoti

https://www.bleepingcomputer.com/news/security/the-double-edged-sword-of-non-human-identities/

Document Title
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed	Necilvēciskas identitātes ir datu noplūdi veicinošs faktors: kāpēc žetoni un pakalpojumu konti tiek pastāvīgi atklāti

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.	Nopludinātas API atslēgas un pakalpojumu kontu žetoni ir kluss, bet augošs datu noplūžu veicinātājs mākoņvidē. Lūk, kā notiek noplūdes, kāpēc tās ir bīstamas un kā pastiprināt un atklāt ļaunprātīgu izmantošanu.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin	Skatīt visus administratora ierakstus
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs	Amaranth-Dragon, kas izmanto WinRAR trūkumu, parāda, cik ātri spiegošanas dalībnieki izmanto publiskas kļūdas kā ieročus
Google teases Pixel 10A: what we know ahead of the February 18 reveal	Google ieskicē Pixel 10A: ko mēs zinām pirms 18. februāra atklāšanas
Page Content
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed	Necilvēciskas identitātes ir datu noplūdi veicinošs faktors: kāpēc žetoni un pakalpojumu konti tiek pastāvīgi atklāti
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.	Necilvēciskas identitātes — API atslēgas, žetoni, pakalpojumu konti, darba slodzes identitātes — tagad ir viens no vienkāršākajiem veidiem, kā iekļūt modernās mākoņvidēs. Ne tāpēc, ka uzbrucēji pēkšņi kļuva par ģēnijiem, bet gan tāpēc, ka organizācijas arvien vairāk darbojas, balstoties uz mašīnu un mašīnu savstarpēju uzticēšanos, un šī uzticēšanās bieži vien ir pārāk plaša, ilgstoša un slikti uzraudzīta.
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	Jaunā ziņojumā izceltā analīze norāda uz pazīstamu modeli milzīgā mērogā: tūkstošiem konteineru attēlu un repozitoriju nejauši atklāj noslēpumus, kas klusi piešķir piekļuvi ražošanas sistēmām. Problēma nav tikai tā, ka izstrādātāji dažreiz pieļauj kļūdas. Problēma ir tā, ka noklusējuma rīki un stimuli to apgrūtina.
easy
to ship secrets and
hard
to prove you didn’t.	lai pierādītu, ka to nedarīji.
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.	Šis ir stāsts par "neredzamu pārkāpumu". Daudzi apdraudējumi nesākas ar ielaušanos vai skaļu ļaunprogrammatūras notikumu. Tie sākas ar žetonu, kas autentificējas tīri — lai viss izskatītos normāli —, līdz brīdim, kad saprotat, ka to ir izmantojis nepareizais vadītājs.
What “non-human identities” are (in plain terms)	Kas ir “necilvēciskas identitātes” (vienkārši izsakoties)?
A non-human identity (NHI) is any credential that lets software authenticate as a trusted actor:	Necilvēka identitāte (NHI) ir jebkura akreditācija, kas ļauj programmatūrai autentificēties kā uzticamai personai:
cloud access keys and session tokens	mākoņa piekļuves atslēgas un sesijas žetoni
service accounts and workload identities	pakalpojumu konti un darba slodzes identitātes
CI/CD credentials used by build pipelines	CI/CD akreditācijas dati, ko izmanto būvēšanas cauruļvadi
tokens for SaaS tools (GitHub, GitLab, Slack, monitoring platforms)	SaaS rīku (GitHub, GitLab, Slack, uzraudzības platformu) žetoni
API keys for third-party services (payment providers, email providers, AI model APIs)	API atslēgas trešo pušu pakalpojumiem (maksājumu pakalpojumu sniedzējiem, e-pasta pakalpojumu sniedzējiem, mākslīgā intelekta modeļu API)
The important difference from human logins is that NHIs typically:	Svarīga atšķirība no cilvēku pieteikšanās ir tā, ka NHI parasti:
run continuously
are embedded in code or config	ir iegulti kodā vai konfigurācijā
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.	Ja uzbrucējs iegūst darbojošos žetonu, viņam nav "jāielaužas". Viņš veic autentifikāciju.
Why this is getting worse now	Kāpēc tagad kļūst arvien sliktāk
Three trends are pushing NHIs from “important” to “dominant risk”:	Trīs tendences veicina NHI statusa maiņu no “svarīga” uz “dominējošo risku”:
1) Software supply chains are bigger than ever	1) Programmatūras piegādes ķēdes ir lielākas nekā jebkad agrāk
Modern apps are assembled from:	Mūsdienu lietotnes tiek veidotas no:
containers
open-source dependencies
infrastructure-as-code
dozens of SaaS integrations
Every integration adds another credential.	Katra integrācija pievieno vēl vienu akreditācijas dokumentu.
2) Automation is everywhere
Organizations want:
faster deploys
self-service infrastructure	pašapkalpošanās infrastruktūra
ephemeral environments
Automation is good—but it is powered by identities that have privileges.	Automatizācija ir laba, taču to nodrošina identitātes ar privilēģijām.
3) Credentials last longer than the people who created them	3) Pilnvaras ir derīgas ilgāk nekā cilvēki, kas tās izveidoja
Humans change roles and leave.	Cilvēki maina lomas un aiziet.
But a token in a repo or a container can:	Bet marķieris repozitorijā vai konteinerā var:
persist for months or years	saglabājas mēnešiem vai gadiem ilgi
be copied into new builds
and remain valid long after anyone remembers it exists	un paliek spēkā ilgi pēc tam, kad kāds atceras, ka tā pastāv
So the attack surface grows silently.	Tātad uzbrukuma virsma klusībā aug.
How secrets leak in real life (it’s not always “someone committed a key”)	Kā noslēpumi noplūst reālajā dzīvē (ne vienmēr ir tā, ka "kāds ir uzlauzis atslēgu")
The stereotype is a developer committing	Stereotips ir izstrādātājs, kas apņemas
AWS_SECRET_ACCESS_KEY
to GitHub.
That still happens. But a lot of leakage is less obvious:	Tas joprojām notiek. Taču daudzas noplūdes ir mazāk acīmredzamas:
tokens baked into container layers	žetoni, kas cepti konteineru slāņos
config files copied into images during build	konfigurācijas faili kopēti attēlos būvēšanas laikā
debug logs containing secrets	atkļūdošanas žurnāli, kas satur noslēpumus
“temporary” keys shared in chat and later pasted into code	“Pagaidu” atslēgas, kas koplietotas tērzēšanā un vēlāk ielīmētas kodā
CI variables printed by misconfigured pipelines	Nepareizi konfigurētu cauruļvadu izdrukāti CI mainīgie
And container images are particularly dangerous because:	Un konteineru attēli ir īpaši bīstami, jo:
they get mirrored
they get cached	tie tiek kešatmiņā saglabāti
they get copied between teams	tie tiek kopēti starp komandām
Even if you delete the key from the repo, the key can remain in old image layers.	Pat ja izdzēšat atslēgu no repozitorija, tā var palikt vecajos attēlu slāņos.
Why leaked tokens are more dangerous than many exploits	Kāpēc nopludinātie žetoni ir bīstamāki nekā daudzi citi uzbrukumi
Exploits are noisy. They often trigger alerts.	Ekspluatācijas ir trokšņainas. Tās bieži vien izraisa brīdinājumus.
Leaked tokens are quiet. They often look like normal usage:	Nopludinātie žetoni ir klusi. Tie bieži izskatās pēc parastas lietošanas:
successful authentication
correct API calls
legitimate endpoints
That changes the defender’s problem.
Instead of detecting “an attacker,” you have to detect:	Tā vietā, lai atklātu "uzbrucēju", jums ir jāatklāj:
an unexpected
principal
using valid credentials	izmantojot derīgus akreditācijas datus
from unusual locations
at unusual times
doing unusual actions
This is why NHIs are a detection gap for many organizations.	Tāpēc daudzām organizācijām NHI ir atklāšanas plaisa.
The privilege problem: tokens are often too powerful	Privilēģiju problēma: žetoni bieži vien ir pārāk spēcīgi
A lot of secrets are created as “get it working” shortcuts:	Daudzi noslēpumi tiek izveidoti kā īsceļi “likt to darboties”:
broad cloud permissions
admin-level API access	administratora līmeņa API piekļuve
long-lived keys
And once the system works, people don’t want to touch it.	Un, kad sistēma darbojas, cilvēki nevēlas tai pieskarties.
This creates a dangerous asymmetry:
a human account might have MFA and monitoring	cilvēka kontam var būt MFA un uzraudzība
the machine identity might have broad access and little scrutiny	mašīnas identitātei varētu būt plaša piekļuve un maza kontrole
When the machine identity leaks, the blast radius can be bigger.	Kad tiek atklāta mašīnas identitāte, sprādziena rādiuss var būt lielāks.
What a good NHI strategy looks like (concrete practices)	Kā izskatās laba NHI stratēģija (konkrētas prakses)
This is solvable, but only if you treat NHIs as first-class security assets.	Tas ir atrisināms, bet tikai tad, ja NHI tiek uzskatīti par pirmklasīgiem drošības aktīviem.
1) Prefer short-lived credentials	1) Dodiet priekšroku īslaicīgai kvalifikācijai
Where possible:
use temporary session credentials	izmantot pagaidu sesijas akreditācijas datus
rotate tokens frequently
avoid “never expires” keys	izvairieties no atslēgām, kuru derīguma termiņš nekad nebeidzas
Short-lived tokens reduce the payoff of leaks.	Īslaicīgi žetoni samazina noplūžu atdevi.
2) Replace static keys with workload identity where you can	2) Aizvietojiet statiskās atslēgas ar darba slodzes identitāti, kur tas ir iespējams
In modern cloud setups, you can often authenticate workloads via:	Mūsdienu mākoņpakalpojumos darba slodzes bieži var autentificēt, izmantojot:
instance identity
OIDC federation
managed identity
This reduces the need to store static keys.	Tas samazina nepieciešamību uzglabāt statiskās atslēgas.
3) Separate environments strictly
A common failure is using the same token across:	Bieži sastopama kļūme ir viena un tā paša marķiera izmantošana:
dev
staging
production
Tokens should be environment-scoped.	Tokeniem jābūt vides tvērumā.
If a dev image leaks, it shouldn’t unlock prod.	Ja izstrādātāja attēls noplūst, tam nevajadzētu atbloķēt produktu.
4) Inventory and ownership	4) Inventārs un īpašumtiesības
Every meaningful token should have:	Katram jēgpilnam tokenam jābūt:
an owner
a purpose
an expected usage pattern	paredzamais lietošanas modelis
If a token has no owner, it is technical debt waiting to become an incident.	Ja tokenam nav īpašnieka, tas ir tehnisks parāds, kas gaida, lai kļūtu par incidentu.
5) Monitor NHI behavior like you monitor human behavior	5) Uzraugiet NHI uzvedību tāpat kā jūs uzraugāt cilvēku uzvedību
Good signals include:
impossible travel / unusual geographies	neiespējami ceļojumi / neparastas ģeogrāfiskās vietas
unusual API call sequences	neparastas API izsaukumu secības
spikes in data access
new permissions granted
new tokens created
The goal is not perfect detection; it’s early detection.	Mērķis nav perfekta atklāšana; tā ir agrīna atklāšana.
6) Treat CI/CD as a high-risk identity factory	6) Izturēties pret CI/CD kā pret augsta riska identitātes fabriku
CI systems frequently hold:
deployment keys
signing keys
cloud credentials
Lock them down:
least privilege
separated runners
secret masking and prevention of log leaks	slepena maskēšana un žurnālu noplūžu novēršana
strict approvals for production deploy steps	stingri apstiprinājumi ražošanas ieviešanas soļiem
Where teams usually fail (and how to avoid it)	Kur komandas parasti cieš neveiksmes (un kā no tā izvairīties)
“We rotate keys sometimes” isn’t a plan	“Mēs dažreiz mainām atslēgas” nav plāns
If rotation is manual and painful, it won’t happen under pressure.	Ja rotācija ir manuāla un sāpīga, tā nenotiks zem spiediena.
Make rotation routine and automated.	Padariet rotāciju rutīnu un automatizētu.
Security tools without enforcement become “monitoring theater”	Drošības rīki bez uzraudzības kļūst par “monitoringa teātri”
Scanning repositories for secrets is useful, but it’s not enough.	Repozitoriju skenēšana, meklējot noslēpumus, ir noderīga, taču ar to nepietiek.
You also need:
rapid revocation
alerts on usage
and prevention in build pipelines	un profilakse būvniecības cauruļvados
The container layer trap
If secrets ever entered a container build context, assume they may exist in:	Ja noslēpumi kādreiz ir nonākuši konteinera veidošanas kontekstā, pieņemsim, ka tie var atrasties:
old images
cached layers	kešatmiņā saglabātie slāņi
CI artifacts
The fix is not only “delete the repo key.” It’s:	Risinājums nav tikai "repozitorija atslēgas dzēšana". Tas ir:
rotate the secret
rebuild and republish images	atjaunot un atkārtoti publicēt attēlus
invalidate caches where possible	padarīt kešatmiņas nederīgas, ja iespējams
What to watch next
If you want to track whether organizations are improving on NHIs, look for:	Ja vēlaties izsekot, vai organizācijas uzlabo NHI, meklējiet:
adoption of short-lived identity (OIDC/workload identity)	īslaicīgas identitātes (OIDC/darba slodzes identitātes) pieņemšana
widespread token rotation programs	plaši izplatītas žetonu rotācijas programmas
stronger CI/CD boundary controls	stingrāka CI/CD robežu kontrole
incident reports that acknowledge “valid credentials used” as a primary cause	incidentu ziņojumi, kuros kā galvenais iemesls ir norādīts, ka “izmantoti derīgi akreditācijas dati”
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.”	Pievērsiet uzmanību arī rīku pusei: labākie rīki mainīsies no "atklātu virkņu noteikšanas" uz "vispār pastāvošo statisko noslēpumu skaita samazināšanu".
The economics: why attackers love token hunting	Ekonomika: kāpēc uzbrucējiem patīk žetonu medības
Token hunting scales.
An attacker who steals one working credential can often:	Uzbrucējs, kurš nozog vienu derīgu akreditācijas informāciju, bieži vien var:
access multiple systems (cloud + source control + CI)	piekļūt vairākām sistēmām (mākonis + avota kontrole + CI)
reuse the same technique across many organizations	atkārtoti izmantot vienu un to pašu metodi daudzās organizācijās
and sell access in marketplaces if they don’t want to operate it themselves	un pārdot piekļuvi tirdzniecības vietās, ja viņi paši nevēlas to pārvaldīt
For defenders, this means the threat isn’t just “a hacker targeting us.” It’s “a machine economy that profits from any reusable credential.”	Aizstāvjiem tas nozīmē, ka drauds nav tikai "hakeris, kas uzbrūk mums". Tā ir "mašīnekonomika, kas gūst peļņu no jebkuras atkārtoti izmantojamas akreditācijas".
That’s why prevention is more valuable here than response. If the key never existed in static form, it can’t be harvested later.	Tāpēc profilakse šeit ir vērtīgāka nekā reaģēšana. Ja atslēga nekad nav pastāvējusi statiskā formā, to vēlāk nevar iegūt.
Concrete detection ideas (what to alert on)	Betona noteikšanas idejas (par ko brīdināt)
If you’re building detections for NHIs, focus on behavior changes rather than magic keywords.	Ja veidojat NHI noteikšanas mehānismus, koncentrējieties uz uzvedības izmaiņām, nevis maģiskiem atslēgvārdiem.
High-signal examples:
A service account used from a	Pakalpojuma konts, ko izmanto no
new country/ASN
it never used before.	tas nekad iepriekš nebija lietots.
A token that normally only calls one API suddenly enumerates resources or downloads large volumes.	Tokens, kas parasti izsauc tikai vienu API, pēkšņi uzskaita resursus vai lejupielādē lielus apjomus.
A CI identity performing actions outside the normal release window.	CI identitāte, kas veic darbības ārpus parastā izlaišanas loga.
Secrets used from interactive user endpoints when they were intended only for server workloads.	Noslēpumi, kas izmantoti no interaktīviem lietotāju galapunktiem, ja tie bija paredzēti tikai serveru darba slodzēm.
Even basic anomaly alerts can catch the “quiet credential theft” pattern early.	Pat pamata anomāliju brīdinājumi var laikus pamanīt “klusas akreditācijas datu zādzības” modeli.
Concrete hardening ideas (low effort, high leverage)	Betona sacietēšanas idejas (maza piepūle, liela ietekme)
These are practical changes most teams can make without a massive redesign:	Šīs ir praktiskas izmaiņas, ko lielākā daļa komandu var veikt bez apjomīgas pārprojektēšanas:
Reduce token scope	Samazināt marķiera darbības jomu
: split one broad token into several narrowly scoped tokens.	: sadalīt vienu plašu marķieri vairākos šauri ierobežotos marķieros.
Rotate on schedule
: rotate even when nothing is “wrong,” so rotation becomes muscle memory.	: rotēt pat tad, ja nekas nav “nepareizi”, tāpēc rotācija kļūst par muskuļu atmiņu.
Gate production
: require explicit approval for production deploy identities.	: nepieciešama skaidra apstiprināšana ražošanas izvietošanas identitātēm.
Block plaintext secrets in builds	Bloķēt vienkārša teksta noslēpumus versijās
: CI should fail builds when obvious secret patterns appear.	CI vajadzētu neizdoties veidot, ja parādās acīmredzami slepeni modeļi.
Each move shrinks blast radius even if a leak still occurs.	Katra kustība samazina sprādziena rādiusu, pat ja noplūde joprojām rodas.
A simple internal policy that prevents a lot of pain	Vienkārša iekšējā politika, kas novērš daudz sāpju
If you want one policy that forces better behavior, it’s this:	Ja vēlaties vienu politiku, kas piespiež labāku uzvedību, tā ir šāda:
No production-capable secrets in developer laptops or in container build contexts.	Izstrādātāju klēpjdatoros vai konteineru veidošanas kontekstos nav ražošanai piemērotu noslēpumu.
That rule drives changes like:	Šis noteikums veicina šādas izmaiņas:
workload identity for services	pakalpojumu darba slodzes identitāte
staging credentials for development	izstrādes stadijā esošās akreditācijas dati
and explicit approvals for production deployment steps	un skaidri apstiprinājumi ražošanas ieviešanas soļiem
It’s annoying at first, but it cuts off the easiest leak paths.	Sākumā tas ir kaitinoši, bet tas nogriež vieglākos noplūdes ceļus.
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.	Necilvēciskas identitātes ir mūsdienu automatizācijas mugurkauls un arī būtisks pārkāpumu virzītājspēks, jo tās bieži vien apiet aizsardzību, ko esam izveidojuši cilvēkiem.
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.	Ja vēlaties praktisku slieksni: tiklīdz varat atbildēt uz jautājumu “kur atrodas mūsu ilgmūžīgie žetoni, kam tie pieder un cik ātri mēs tos varam atsaukt/pagriezt”, jūs esat pārgājuši no sapņu domāšanas uz reālu aizsardzības programmu.
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.	Praktiskais risinājums nav viens burvju skeneris. Tā ir programma: samaziniet statiskos noslēpumus, samaziniet privilēģijas, izveidojiet rotācijas rutīnu un uzraugiet datoru identitātes tāpat kā lietotāju kontus.
Sources
https://www.bleepingcomputer.com/news/security/the-double-edged-sword-of-non-human-identities/	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	Skatīt visus administratora ierakstus
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs	Amaranth-Dragon, kas izmanto WinRAR trūkumu, parāda, cik ātri spiegošanas dalībnieki izmanto publiskas kļūdas kā ieročus
Google teases Pixel 10A: what we know ahead of the February 18 reveal	Google ieskicē Pixel 10A: ko mēs zinām pirms 18. februāra atklāšanas
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.	Nopludinātas API atslēgas un pakalpojumu kontu žetoni ir kluss, bet augošs datu noplūžu veicinātājs mākoņvidē. Lūk, kā notiek noplūdes, kāpēc tās ir bīstamas un kā pastiprināt un atklāt ļaunprātīgu izmantošanu.

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/

←

→

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	Lapa nav atrasta — 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	Lapa nav atrasta — Florin.blog
Skip to content
Home
Blog
Garden Decor
Indoor
Main Menu
This page doesn't seem to exist.	Šķiet, ka šī lapa neeksistē.
It looks like the link pointing here was faulty. Maybe try searching?	Izskatās, ka saite, kas norāda uz šejieni, bija kļūdaina. Varbūt pamēģiniet meklēt?
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.	Kā Amazon partneris mēs saņemam komisijas maksu no kvalificētiem pirkumiem — bez papildu izmaksām jums.
Florin.blog
Florin.blog » Feed
RSD
Search...

Document Title

Page not found - Florin.blog

Image Alt

Florin.blog

Title Attribute

Florin.blog » Feed

RSD

Placeholder Attribute

Search...

Page Content

Page not found - Florin.blog

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:

Quick Links

Outdoors

About

Contact

Explore

Bestsellers

Hot deals

Best of The Year

Featured

Gift Cards

Help

Disclaimer

: As an Amazon Associate, we earn from qualifying purchases — at no extra cost to you.

Florin.blog

Florin.blog » Feed

RSD

Search...