İnsan dışı kimlikler bir güvenlik açığı motoru: Token'lar ve hizmet hesapları neden sürekli olarak ifşa ediliyor?

/Teknoloji/ İle

İnsan dışı kimlikler—API anahtarları, belirteçler, hizmet hesapları, iş yükü kimlikleri—artık modern bulut ortamlarına girmenin en kolay yollarından biri haline geldi. Bunun nedeni saldırganların birdenbire dahi olmaları değil, kuruluşların giderek artan bir şekilde makineden makineye güvene dayalı olarak çalışması ve bu güvenin genellikle çok geniş kapsamlı, uzun ömürlü ve yetersiz bir şekilde denetlenmesidir.

Haberlerde vurgulanan yeni bir analiz, devasa ölçekte tanıdık bir kalıba işaret ediyor: binlerce konteyner imajı ve depo, üretim sistemlerine sessizce erişim sağlayan gizli bilgileri yanlışlıkla açığa çıkarıyor. Sorun sadece geliştiricilerin bazen hata yapması değil. Sorun, varsayılan araçların ve teşviklerin bunu mümkün kılmasıdır.kolaysırları göndermek vezorYapmadığını kanıtlamak için.

Bu bir "görünmez ihlal" öyküsü. Birçok güvenlik açığı, bir güvenlik açığı veya yüksek sesli bir kötü amaçlı yazılım olayıyla başlamaz. Her şey normal görünene kadar sorunsuz bir şekilde kimlik doğrulaması yapan bir belirteçle başlar; ta ki yanlış bir kişinin onu kullandığını fark edene kadar.

“İnsan dışı kimlikler” (basit bir dille) nedir?

İnsan dışı kimlik (NHI), yazılımın güvenilir bir aktör olarak kimliğini doğrulamasına olanak tanıyan herhangi bir kimlik bilgisidir:

  • bulut erişim anahtarları ve oturum belirteçleri
  • hizmet hesapları ve iş yükü kimlikleri
  • Derleme işlem hatları tarafından kullanılan CI/CD kimlik bilgileri
  • SaaS araçları için belirteçler (GitHub, GitLab, Slack, izleme platformları)
  • Üçüncü taraf hizmetler için API anahtarları (ödeme sağlayıcıları, e-posta sağlayıcıları, yapay zeka modeli API'leri)

İnsan girişlerinden önemli farkı, NHI'ların tipik olarak şu özelliklere sahip olmasıdır:

  • sürekli çalıştır
  • kod veya yapılandırma dosyalarına gömülüdürler.
  • ve genellikle çok faktörlü kimlik doğrulamayı (MFA) kullanmıyorlar.

Bu da onları çekici kılıyor.

Eğer bir saldırgan çalışan bir token elde ederse, "izinsiz giriş" yapmasına gerek kalmaz. Sadece kimlik doğrulamasını yapar.

Bu durum neden şimdi daha da kötüleşiyor?

Üç eğilim, ulusal sağlık sigortalarını "önemli" riskten "baskın risk" seviyesine doğru itiyor:

1) Yazılım tedarik zincirleri her zamankinden daha büyük.

Modern uygulamalar şunlardan oluşur:

  • konteynerler
  • açık kaynak bağımlılıkları
  • altyapı-kod olarak
  • düzinelerce SaaS entegrasyonu

Her entegrasyon, bir başka kimlik bilgisi daha ekler.

2) Otomasyon her yerde

Kuruluşlar şunları istiyor:

  • daha hızlı dağıtımlar
  • öz hizmet altyapısı
  • geçici ortamlar

Otomasyon iyidir, ancak ayrıcalıklara sahip kimlikler tarafından desteklenir.

3) Kimlik belgeleri, onları oluşturan kişilerden daha uzun süre geçerlidir.

İnsanlar rollerini değiştirir ve ayrılırlar.

Ancak bir depoda veya konteynerde bulunan bir belirteç şunları yapabilir:

  • aylarca veya yıllarca devam edebilir
  • yeni yapılara kopyalanabilir
  • ve varlığını kimse hatırlamasa bile uzun süre geçerliliğini korur.

Dolayısıyla saldırı yüzeyi sessizce büyüyor.

Gerçek hayatta sırlar nasıl sızar (her zaman "birisi anahtarı çaldı" şeklinde olmaz)?

Stereotip, bir geliştiricinin şu hatayı yapmasıdır:AWS_SECRET_ACCESS_KEYGitHub'a.

Bu hâlâ oluyor. Ancak sızıntıların çoğu daha az belirgin:

  • konteyner katmanlarına yerleştirilmiş belirteçler
  • Yapılandırma dosyaları derleme sırasında imajlara kopyalanır.
  • gizli bilgiler içeren hata ayıklama günlükleri
  • Sohbette paylaşılan ve daha sonra koda yapıştırılan "geçici" anahtarlar
  • Yanlış yapılandırılmış işlem hatları tarafından yazdırılan CI değişkenleri

Ve konteyner görüntüleri özellikle tehlikelidir çünkü:

  • Aynaya yansıtılırlar.
  • Önbelleğe alınıyorlar
  • Bunlar takımlar arasında kopyalanır.

Anahtarı depodan silseniz bile, anahtar eski görüntü katmanlarında kalabilir.

Sızdırılan token'lar neden birçok güvenlik açığından daha tehlikelidir?

Saldırılar gürültülüdür. Genellikle uyarıları tetiklerler.

Sızdırılan token'lar sessizdir. Genellikle normal kullanım gibi görünürler:

  • başarılı kimlik doğrulama
  • doğru API çağrıları
  • meşru uç noktalar

Bu durum, savunmacının sorununu değiştiriyor.

“Bir saldırganı” tespit etmek yerine, şunları tespit etmelisiniz:

  • beklenmedik birmüdürgeçerli kimlik bilgilerini kullanarak
  • alışılmadık yerlerden
  • olağanüstü zamanlarda
  • alışılmadık eylemler yapmak

Bu nedenle, ulusal sağlık sigortaları birçok kuruluş için bir tespit açığı oluşturmaktadır.

Ayrıcalık sorunu: Token'lar genellikle çok güçlüdür.

Birçok sır, "çalışır hale getirme" kısayolları olarak yaratılır:

  • geniş bulut izinleri
  • yönetici düzeyinde API erişimi
  • uzun ömürlü anahtarlar

Sistem bir kere çalışmaya başlayınca, insanlar ona dokunmak istemiyorlar.

Bu durum tehlikeli bir asimetri yaratır:

  • İnsan tarafından kullanılan bir hesapta çok faktörlü kimlik doğrulama ve izleme özellikleri bulunabilir.
  • Makine kimliği geniş erişime sahip olabilir ve çok az denetime tabi tutulabilir.

Makinenin kimliği sızdığında, patlama yarıçapı daha büyük olabilir.

İyi bir Ulusal Sağlık Sigortası stratejisi nasıl olmalıdır (somut uygulamalar)?

Bu sorun çözülebilir, ancak yalnızca ulusal sağlık sigortalarını birinci sınıf güvenlik varlıkları olarak ele alırsanız.

1) Kısa süreli sertifikaları tercih edin

Mümkün olan yerlerde:

  • geçici oturum kimlik bilgilerini kullanın
  • jetonları sık sık döndürün
  • "Süresi asla dolmayan" anahtarlardan kaçının.

Kısa ömürlü tokenlar, sızıntıların getirisini azaltır.

2) Mümkün olan yerlerde statik anahtarları iş yükü kimliğiyle değiştirin.

Modern bulut ortamlarında, iş yüklerinin kimlik doğrulaması genellikle şu yollarla yapılabilir:

  • örnek kimliği
  • OIDC federasyonu
  • yönetilen kimlik

Bu, statik anahtarların saklanması ihtiyacını azaltır.

3) Ortamları kesinlikle birbirinden ayırın.

Sık yapılan bir hata, aynı belirtecin (token) farklı yerlerde kullanılmasıdır:

  • dev
  • sahneleme
  • üretme

Token'lar ortam kapsamına dahil edilmelidir.

Geliştirme ortamında kullanılan bir imaj sızarsa, üretim ortamının kilidini açmamalıdır.

4) Stok ve mülkiyet

Her anlamlı belirteç şu özelliklere sahip olmalıdır:

  • bir sahibi
  • bir amaç
  • beklenen bir kullanım modeli

Bir token'ın sahibi yoksa, bir olaya dönüşmeyi bekleyen teknik bir borçtur.

5) NHI davranışlarını tıpkı insan davranışlarını izlediğiniz gibi izleyin.

İyi sinyaller şunlardır:

  • imkansız seyahat / sıra dışı coğrafyalar
  • alışılmadık API çağrı dizileri
  • veri erişiminde ani artışlar
  • yeni izinler verildi
  • yeni tokenlar oluşturuldu

Amaç kusursuz tespit değil, erken tespittir.

6) CI/CD'yi yüksek riskli bir kimlik fabrikası olarak ele alın.

CI sistemleri sıklıkla şunları içerir:

  • dağıtım anahtarları
  • imzalama anahtarları
  • bulut kimlik bilgileri

Onları kilit altına alın:

  • en az ayrıcalıklı
  • ayrı koşucular
  • gizli maskeleme ve kayıt sızıntılarının önlenmesi
  • Üretim ortamına dağıtım adımları için sıkı onaylar

Takımların genellikle başarısız olduğu noktalar (ve bundan nasıl kaçınılır)

“Bazen anahtarları değiştiririz” bir plan değildir.

Dönme hareketi manuel ve acı vericiyse, baskı altında gerçekleşmeyecektir.

Rotaj işlemlerini rutin ve otomatik hale getirin.

Güvenlik araçları, yaptırım uygulanmadığı takdirde "gözetim tiyatrosuna" dönüşür.

Veri depolarını gizli bilgiler açısından taramak faydalıdır, ancak yeterli değildir.

Ayrıca şunlara da ihtiyacınız var:

  • hızlı iptal
  • kullanımla ilgili uyarılar
  • ve geliştirme süreçlerinde önleme

Konteyner katmanı tuzağı

Eğer gizli bilgiler bir konteyner oluşturma bağlamına girerse, bunların şu yerlerde bulunabileceğini varsayın:

  • eski görüntüler
  • önbelleğe alınmış katmanlar
  • CI yapıtları

Çözüm sadece "depo anahtarını silmek" değil. Çözüm şu:

  • sırrı döndürün
  • görüntüleri yeniden oluştur ve yeniden yayınla
  • Mümkün olan yerlerde önbellekleri geçersiz kılın.

Sırada ne izlenecek?

Kuruluşların Ulusal Sağlık Sigortaları (NHI) konusunda iyileşme gösterip göstermediğini takip etmek istiyorsanız şunlara bakın:

  • Kısa ömürlü kimliklerin (OIDC/iş yükü kimliği) benimsenmesi
  • yaygın token rotasyon programları
  • daha güçlü CI/CD sınır kontrolleri
  • Olay raporlarında birincil neden olarak "geçerli kimlik bilgilerinin kullanılması" belirtilmektedir.

Araçlar tarafına da dikkat edin: En iyi araçlar "açığa çıkmış dizeleri tespit etme" işlevinden "mevcut statik gizli bilgilerin sayısını azaltma" işlevine doğru kayacaktır.

Ekonomi: Saldırganlar neden token avlamayı seviyor?

Jeton avcılığı ölçekleri.

Geçerli bir kimlik bilgisini çalan bir saldırgan genellikle şunları yapabilir:

  • Birden fazla sisteme erişim (bulut + kaynak kontrolü + sürekli entegrasyon)
  • aynı tekniği birçok kuruluşta yeniden kullanın
  • ve eğer kendileri işletmek istemiyorlarsa, erişimi pazar yerlerinde satabilirler.

Savunmacılar için bu, tehdidin sadece "bizi hedef alan bir bilgisayar korsanı" olmadığı anlamına geliyor. Tehdit, "yeniden kullanılabilir kimlik bilgilerinden kar elde eden bir makine ekonomisi" anlamına geliyor.

Bu nedenle burada önlem almak, müdahale etmekten daha değerlidir. Anahtar statik biçimde hiç var olmadıysa, daha sonra elde edilemez.

Somut tespit fikirleri (hangi durumlarda uyarı verilmeli)

Ulusal Sağlık Enstitüleri (NHI) için tespit mekanizmaları geliştiriyorsanız, sihirli anahtar kelimeler yerine davranış değişikliklerine odaklanın.

Yüksek sinyalli örnekler:

  • Bir hizmet hesabı, bir kaynaktan kullanılıyor.yeni ülke/ASNDaha önce hiç kullanılmamıştı.
  • Normalde yalnızca tek bir API'yi çağıran bir token, aniden kaynakları listeliyor veya büyük miktarda veri indiriyor.
  • Normal yayın penceresinin dışında işlem gerçekleştiren bir CI kimliği.
  • Yalnızca sunucu iş yükleri için tasarlanmış olan etkileşimli kullanıcı uç noktalarından kullanılan gizli bilgiler.

En basit anormallik uyarıları bile "sessiz kimlik bilgisi hırsızlığı" modelini erken aşamada tespit edebilir.

Beton sertleştirme fikirleri (düşük çaba, yüksek etki)

Bunlar, çoğu ekibin büyük bir yeniden tasarım yapmadan uygulayabileceği pratik değişikliklerdir:

  • Token kapsamını azaltın: Geniş kapsamlı bir belirteci, daha dar kapsamlı birkaç belirtece bölmek.
  • Planlı bir şekilde dönüşümlü olarak çalışın.Hiçbir şey "yanlış" olmasa bile dönme hareketi gerçekleşir, böylece dönme hareketi kas hafızası haline gelir.
  • Kapı üretimiÜretim ortamına dağıtım kimlikleri için açık onay gereklidir.
  • Derlemelerde düz metin halindeki gizli bilgileri engelleyinCI, bariz gizli kalıplar ortaya çıktığında derlemeleri başarısız kılmalıdır.

Her hareket, sızıntı devam etse bile patlama yarıçapını küçültür.

Birçok sıkıntıyı önleyen basit bir iç politika.

Daha iyi davranışları zorunlu kılan tek bir politika istiyorsanız, o da budur:

  • Geliştirici dizüstü bilgisayarlarında veya konteyner derleme ortamlarında üretimde kullanılabilecek gizli bilgiler bulunmaz.

Bu kural şu ​​gibi değişikliklere yol açar:

  • hizmetler için iş yükü kimliği
  • geliştirme için hazırlık kimlik bilgileri
  • ve üretim aşamasına geçiş adımları için açık onaylar

İlk başta can sıkıcı olsa da, en kolay sızıntı yollarını ortadan kaldırıyor.

Özetle

İnsan dışı kimlikler, modern otomasyonun omurgasını oluşturuyor ve aynı zamanda, insanlar için oluşturduğumuz korumaları sıklıkla atlattıkları için, güvenlik ihlallerinin de önemli bir nedenidir.

Pratik bir eşik istiyorsanız: "Uzun ömürlü tokenlarımız nerede bulunuyor, kime ait ve ne kadar hızlı bir şekilde iptal edip/döndürebiliriz?" sorularına cevap verebildiğinizde, hayal kurmaktan gerçek bir savunma programına geçmiş olursunuz.

Pratik çözüm tek bir sihirli tarayıcı değil. Bir program gerekiyor: statik gizli bilgileri en aza indirin, ayrıcalıkları azaltın, rotasyonu rutin hale getirin ve makine kimliklerini tıpkı kullanıcı hesaplarını izlediğiniz gibi izleyin.

Kaynaklar

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...
Türkçe