Ne žmonių tapatybės yra įsilaužimo variklis: kodėl žetonai ir paslaugų paskyros nuolat pažeidžiamos

/Technologijos/ Autorius

Ne žmonių tapatybės – API raktai, žetonai, paslaugų paskyros, darbo krūvio tapatybės – dabar yra vienas lengviausių būdų patekti į šiuolaikines debesijos aplinkas. Ne todėl, kad užpuolikai staiga tapo genijais, bet todėl, kad organizacijos vis dažniau remiasi mašinų tarpusavio pasitikėjimu, ir tas pasitikėjimas dažnai yra per platus, ilgalaikis ir prastai stebimas.

Naujoje ataskaitose pateiktoje analizėje atkreipiamas dėmesys į įprastą didelio masto modelį: tūkstančiai konteinerių atvaizdų ir saugyklų netyčia atskleidžia paslaptis, kurios tyliai suteikia prieigą prie gamybos sistemų. Problema ta, kad kūrėjai kartais klysta. Problema ta, kad numatytieji įrankiai ir paskatos neleidžia...lengvaperduoti paslaptis irsunkukad įrodytum, jog to nepadarei.

Tai „nematomo įsilaužimo“ istorija. Daugelis įsilaužimų neprasideda nuo spragų išnaudojimo ar garsaus kenkėjiškos programos atvejo. Jie prasideda nuo prieigos rakto, kuris autentifikuojasi švariai – todėl viskas atrodo normalu – kol nesuprantate, kad jį naudojo netinkamas administratorius.

Kas yra „nežmogiškos tapatybės“ (paprastai tariant)

Ne žmogaus tapatybė (NHI) yra bet koks kredencialas, leidžiantis programinei įrangai autentifikuotis kaip patikimam subjektui:

  • debesies prieigos raktai ir sesijos žetonai
  • paslaugų paskyros ir darbo krūvio tapatybės
  • CI/CD kredencialai, naudojami kūrimo srautuose
  • SaaS įrankių žetonai („GitHub“, „GitLab“, „Slack“, stebėjimo platformos)
  • Trečiųjų šalių paslaugų API raktai (mokėjimo paslaugų teikėjai, el. pašto paslaugų teikėjai, dirbtinio intelekto modelių API)

Svarbus skirtumas nuo žmonių prisijungimų yra tas, kad NHI paprastai:

  • veikti nuolat
  • yra įterpti į kodą arba konfigūraciją
  • ir dažnai nenaudoja MFA

Tai daro juos patrauklius.

Jei užpuolikas gauna veikiantį prieigos raktą, jam nereikia „įsilaužti“. Jis autentifikuojasi.

Kodėl dabar viskas blogėja

Trys tendencijos lemia, kad NHI statusas iš „svarbių“ tampa „dominuojančios rizikos“:

1) Programinės įrangos tiekimo grandinės yra didesnės nei bet kada anksčiau

Šiuolaikinės programos surenkamos iš:

  • konteineriai
  • atvirojo kodo priklausomybės
  • infrastruktūra kaip kodas
  • dešimtys SaaS integracijų

Kiekviena integracija prideda dar vieną akreditaciją.

2) Automatizavimas yra visur

Organizacijos nori:

  • greitesnis diegimas
  • savitarnos infrastruktūra
  • efemeriškos aplinkos

Automatizavimas yra geras dalykas, bet jį palaiko tapatybės, turinčios privilegijas.

3) Įgaliojimai galioja ilgiau nei juos sukūrę žmonės

Žmonės keičia vaidmenis ir išeina.

Tačiau saugykloje arba konteineryje esantis žetonas gali:

  • išlieka mėnesius ar metus
  • būti nukopijuoti į naujas versijas
  • ir galioja ilgai po to, kai kas nors prisimena, kad egzistuoja

Taigi atakos paviršius tyliai auga.

Kaip paslaptys nuteka realiame gyvenime (ne visada „kažkas pavogė raktą“)

Stereotipas yra kūrėjas, įsipareigojantisAWS_SECRET_ACCESS_KEYį „GitHub“.

Tai vis dar pasitaiko. Tačiau daug nutekėjimo yra mažiau akivaizdu:

  • žetonai, kepami į konteinerių sluoksnius
  • konfigūracijos failai, nukopijuoti į atvaizdus kūrimo metu
  • derinimo žurnalai su paslaptimis
  • „Laikini“ raktai, bendrinami pokalbyje ir vėliau įklijuojami į kodą
  • Neteisingai sukonfigūruotų vamzdynų spausdinami CI kintamieji

O konteinerių vaizdai yra ypač pavojingi, nes:

  • jie atsispindi
  • jie kaupiami talpykloje
  • jie kopijuojami tarp komandų

Net jei ištrinsite raktą iš saugyklos, jis gali likti senuose vaizdo sluoksniuose.

Kodėl nutekėję žetonai yra pavojingesni nei daugelis išnaudojimų

Išnaudojimai yra triukšmingi. Jie dažnai sukelia įspėjimus.

Nutekėję žetonai yra tylūs. Jie dažnai atrodo kaip įprastas naudojimas:

  • sėkmingas autentifikavimas
  • teisingi API iškvietimai
  • teisėti galiniai taškai

Tai pakeičia gynėjo problemą.

Užuot aptikę „užpuoliką“, turite aptikti:

  • netikėtasdirektoriusnaudojant galiojančius prisijungimo duomenis
  • iš neįprastų vietų
  • neįprastais laikais
  • atliekant neįprastus veiksmus

Štai kodėl daugeliui organizacijų NHI yra aptikimo spraga.

Privilegijų problema: žetonai dažnai yra per daug galingi

Daugybė paslapčių sukuriamos kaip „priversti viską veikti“ spartieji klavišai:

  • plačios debesies prieigos teisės
  • administratoriaus lygio API prieiga
  • ilgaamžiai raktai

O kai sistema veikia, žmonės nenori jos liesti.

Tai sukuria pavojingą asimetriją:

  • žmogaus paskyra gali turėti MFA ir stebėjimo funkciją
  • Mašinos tapatybė gali turėti plačią prieigą ir mažai kontrolės

Kai nuteka mašinos tapatybė, sprogimo spindulys gali būti didesnis.

Kaip atrodo gera NHI strategija (konkrečios praktikos)

Tai išsprendžiama, bet tik tuo atveju, jei NHI traktuosite kaip pirmos klasės saugumo turtą.

1) Pirmenybę teikite trumpalaikiams įgaliojimams

Kur įmanoma:

  • naudoti laikinus sesijos prisijungimo duomenis
  • dažnai keiskite žetonus
  • venkite raktų, kurių galiojimo laikas niekada nesibaigia

Trumpalaikiai žetonai sumažina nutekėjimo atlygį.

2) Pakeiskite statinius raktus darbo krūvio tapatybe, kur galite

Šiuolaikinėse debesijos sistemose darbo krūvius dažnai galima autentifikuoti per:

  • egzemplioriaus tapatybė
  • OIDC federacija
  • valdoma tapatybė

Tai sumažina poreikį saugoti statinius raktus.

3) Griežtai atskirkite aplinkas

Dažna klaida – to paties rakto naudojimas:

  • kūrėjas
  • inscenizacija
  • gamyba

Žetonai turėtų būti apriboti aplinkos.

Jei nuteka kūrėjo atvaizdas, jis neturėtų atrakinti gamybos proceso.

4) Atsargos ir nuosavybė

Kiekvienas prasmingas žetonas turėtų turėti:

  • savininkas
  • tikslas
  • numatomas naudojimo modelis

Jei žetonas neturi savininko, tai yra techninė skola, laukianti, kol taps incidentu.

5) Stebėkite NHI elgesį taip, kaip stebite žmonių elgesį

Geri signalai apima:

  • neįmanomos kelionės / neįprastos geografijos
  • neįprastos API iškvietimų sekos
  • duomenų prieigos šuoliai
  • suteikti nauji leidimai
  • sukurti nauji žetonai

Tikslas nėra tobulas aptikimas; tikslas – ankstyvas aptikimas.

6) CI/CD traktuokite kaip didelės rizikos tapatybės fabriką

CI sistemose dažnai yra:

  • diegimo raktai
  • pasirašymo raktai
  • debesies prisijungimo duomenys

Užrakinkite juos:

  • mažiausia privilegija
  • atskirti bėgikai
  • slaptas maskavimas ir rąstų nutekėjimo prevencija
  • griežti gamybinio diegimo etapų patvirtinimai

Kur komandos dažniausiai patiria nesėkmes (ir kaip to išvengti)

„Kartais keičiame raktus“ – ne planas

Jei sukimas atliekamas rankiniu būdu ir yra skausmingas, esant spaudimui, jis neįvyks.

Padarykite rotaciją įprastą ir automatizuotą.

Saugumo priemonės be vykdymo užtikrinimo tampa „stebėjimo teatru“

Saugyklų nuskaitymas ieškant paslapčių yra naudingas, bet to nepakanka.

Jums taip pat reikia:

  • greitas atšaukimas
  • įspėjimai apie naudojimą
  • ir prevencija statant vamzdynus

Konteinerio sluoksnio gaudyklė

Jei slapti kodai kada nors pateko į konteinerio kūrimo kontekstą, tarkime, kad jie gali egzistuoti:

  • seni vaizdai
  • talpykloje esantys sluoksniai
  • CI artefaktai

Pataisymas yra ne tik „ištrinti saugyklos raktą“. Tai yra:

  • pasukite paslaptį
  • atkurti ir iš naujo publikuoti vaizdus
  • anuliuoti talpyklas, jei įmanoma

Ką žiūrėti toliau

Jei norite stebėti, ar organizacijos gerina NHI, ieškokite:

  • trumpalaikės tapatybės (OIDC / darbo krūvio tapatybė) priėmimas
  • plačiai paplitusios žetonų rotacijos programos
  • griežtesnė CI/CD ribų kontrolė
  • incidentų ataskaitos, kuriose pagrindinė priežastis nurodoma „naudojami galiojantys įgaliojimai“

Taip pat atkreipkite dėmesį į įrankius: geriausi įrankiai pereis nuo „aptikti atviras eilutes“ prie „sumažinti iš viso egzistuojančių statinių paslapčių skaičių“.

Ekonomika: kodėl užpuolikai mėgsta žetonų medžioklę

Žetoninės medžioklės svarstyklės.

Užpuolikas, pavogęs vieną veikiantį prisijungimo dokumentą, dažnai gali:

  • prieiga prie kelių sistemų (debesų kompiuterija + šaltinio kontrolė + CI)
  • pakartotinai naudoti tą pačią techniką daugelyje organizacijų
  • ir parduoti prieigą prekyvietėse, jei jie nenori jos valdyti patys

Gynėjams tai reiškia, kad grėsmė yra ne tik „į mus taikosi įsilaužėlis“. Tai „mašinų ekonomika, kuri pelnosi iš bet kokių pakartotinai naudojamų įgaliojimų“.

Štai kodėl prevencija čia vertingesnė nei reagavimas. Jei rakto statine forma niekada nebuvo, jo vėliau nepavyks gauti.

Betono aptikimo idėjos (į ką atkreipti dėmesį)

Jei kuriate NHI aptikimo mechanizmus, sutelkite dėmesį į elgesio pokyčius, o ne į magiškus raktinius žodžius.

Aukšto signalo pavyzdžiai:

  • Paslaugos paskyra, naudojama išnauja šalis / ASNanksčiau niekada nenaudojo.
  • Žetonas, kuris paprastai kreipiasi tik į vieną API, staiga pradeda išvardinti išteklius arba atsisiunčia didelius kiekius duomenų.
  • CI tapatybė, atliekanti veiksmus ne įprasto išleidimo lango metu.
  • Interaktyvių vartotojų galinių taškų slaptieji kodai, naudojami tik serverio darbo krūviams.

Net ir pagrindiniai anomalijų įspėjimai gali anksti aptikti „tyliosios kredencialų vagystės“ modelį.

Betono kietėjimo idėjos (mažos pastangos, didelis svertas)

Tai yra praktiniai pakeitimai, kuriuos dauguma komandų gali atlikti be didelio pertvarkymo:

  • Sumažinti prieigos rakto apimtį: padalinti vieną platų žetoną į kelis siauros apimties žetonus.
  • Pasukti pagal grafikąsuktis net tada, kai nieko „negerai“, todėl sukimasis tampa raumenų atmintimi.
  • Vartų gamyba: reikalingas aiškus gamybinio diegimo tapatybių patvirtinimas.
  • Blokuoti paprasto teksto paslaptis versijoseCI turėtų nepavykti sukurti, kai atsiranda akivaizdūs slapti šablonai.

Kiekvienas judesys sumažina sprogimo spindulį, net jei vis tiek atsiranda nuotėkis.

Paprasta vidinė politika, kuri padeda išvengti daugybės problemų

Jei norite vienos politikos, kuri priverstų geresnį elgesį, tai būtų ši:

  • Kūrėjų nešiojamuosiuose kompiuteriuose ar konteinerių kūrimo kontekstuose nėra gamybai tinkamų paslapčių.

Ši taisyklė lemia tokius pokyčius:

  • paslaugų darbo krūvio tapatybė
  • kūrimo etapo įgaliojimai
  • ir aiškūs gamybinio diegimo etapų patvirtinimai

Iš pradžių tai erzina, bet taip užkertamas kelias lengviausiems nuotėkiams.

Esmė

Ne žmonių tapatybės yra šiuolaikinės automatizacijos pagrindas ir taip pat pagrindinė įsilaužimo varomoji jėga, nes jos dažnai apeina apsaugą, kurią sukūrėme žmonėms.

Jei norite praktiškos ribos: kai tik galite atsakyti į klausimą „kur gyvena mūsų ilgai gyvuojantys žetonai, kam jie priklauso ir kaip greitai galime juos atšaukti / pakeisti“, nuo svajonių perėjote prie realios gynybos programos.

Praktinis sprendimas nėra vienas stebuklingas skaitytuvas. Tai programa: sumažinkite statinius slaptus duomenis, sumažinkite teises, sukurkite rotacijos rutiną ir stebėkite mašinų tapatybes taip, kaip stebite vartotojų paskyras.

Šaltiniai

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...
i Lietuvių kalba