2024 yılında kurumsal bulut ihlallerinin %68’i ne oltalama saldırısından ne de zayıf paroladan kaynaklandı — cevap çok daha sessiz ve çok daha tehlikeli: kimsenin izlemediği servis hesapları, unutulan API anahtarları ve sahipsiz kalan OAuth yetkilendirmeleri. Yani teknik tabirle Non-Human Identities (NHI), Türkçesiyle insan-dışı kimlikler. Eğer kurumunuzda çalışan başına 40-50 adet otomatik kimlik bilgisi döngüde olduğunu düşünürsek — ve bunların büyük çoğunluğu aktif olarak izlenmiyorsa — saldırı yüzeyinizin ne kadar büyük olduğunu bir düşünün. ⚠️ Bu yazıda NHI’nin ne anlama geldiğini, kurumunuzu nasıl etkilediğini ve Wazuh ekosistemiyle bu riski nasıl görünür kılabileceğinizi ele alacağım.
👻 NHI Nedir ve Neden “Hayalet” Diyoruz?
Non-Human Identity (NHI), bir sisteme veya API’ye erişim sağlayan ancak arkasında gerçek bir insan oturmayan her türlü kimlik bilgisidir. Buna servis hesapları, CI/CD pipeline token’ları, bulut fonksiyon erişim anahtarları, AI ajan bağlantıları ve OAuth grant’ları dahildir. Bir proje başladığında bu kimlikler oluşturulur, projeye özel izinler verilir — ancak proje bittiğinde, ekip değiştiğinde ya da ilgili mühendis ayrıldığında bu kimlikler genellikle silinmez. Sistemde aktif kalmaya, hatta zaman zaman geniş yetkilerle var olmaya devam ederler.
“Hayalet” metaforu tam da buradan geliyor: görünmez, ölü ama hâlâ erişim hakkına sahip. Bir saldırgan bu kimliği ele geçirdiğinde — örneğin sızdırılmış bir GitHub reposunda gömülü bir API anahtarı üzerinden — kimse alarm vermez çünkü kimse o kimliği izlemiyordur. Bu, tespit süresi (MTTD) açısından felaket demektir.
📊 Saldırı Yüzeyi: Rakamların Anlattığı Hikaye
Şu basit hesabı yapın: 500 kişilik bir kurumda çalışan başına ortalama 45 NHI varsa, sistemde 22.500 adet insan-dışı kimlik bilgisi dolaşıyor demektir. Bunların kaçı aktif olarak kullanılıyor? Kaçının son erişim tarihi 6 aydan eski? Kaçı aşırı geniş yetkiye (örn. tam bulut yönetici yetkisi) sahip?
Türkiye’deki kurumsal yapıya baktığımda özellikle şu senaryoları sık görüyorum:
- Eski çalışanların bıraktığı servis hesapları: Kişi ayrıldı, insan kimliği devre dışı bırakıldı ama oluşturduğu API token’ı hâlâ aktif.
- Dış kaynaklı (outsource) ekiplerin OAuth grant’ları: Proje bitti, firma değişti ama erişim yetkisi revoke edilmedi.
- Test/geliştirme ortamı kimlik bilgileri üretimde: “Geçici” diye oluşturulan token production’a taşındı ve orada kaldı.
- AI ajan bağlantıları: LLM tabanlı araçlara verilen API erişimleri, kapsam ve süre sınırı olmadan açık bırakıldı.
MITRE ATT&CK çerçevesinde bu senaryo T1078 – Valid Accounts (özellikle T1078.004 – Cloud Accounts alt tekniği) ile doğrudan eşleşiyor. Saldırgan geçerli, meşru görünen bir kimlik kullandığı için davranışsal anomali tespit etmek son derece güçleşiyor.
🛡️ Wazuh ile NHI Görünürlüğü: Pratik Yaklaşım
Wazuh, NHI’ye özel bir modül sunmuyor — ama doğru kural seti ve log entegrasyonuyla bu boşluğu büyük ölçüde kapatabilirsiniz. Biz kurumda özellikle şu üç katmana odaklanıyoruz: bulut audit log’ları, servis hesabı oturum açma anomalileri ve API token kullanım deseni.
Aşağıdaki Wazuh özel kuralı, AWS CloudTrail üzerinden gelen ve son 90 günde hiç kullanılmamış bir IAM servis hesabının ani erişim denemesini yakalar. “Dormant account activation” olarak sınıflandırılan bu durum, NHI güvenliğinin en kritik sinyallerinden biridir:
amazon-aws
AssumeRole|GetSessionToken|ConsoleLogin
IAMUser|AssumedRole|ServiceAccount
NHI Alert: Dormant IAM identity activated - possible orphaned credential abuse (T1078.004)
no_full_log
nhi_dormant_activation,mitre_t1078
T1078.004
100500
NHI Alert: Service account API call outside business hours - investigate immediately
nhi_offtime_access,mitre_t1078
T1078.004
100500
aws.userIdentity.arn
NHI Critical: High-volume API calls from single service identity - credential abuse suspected (T1078)
nhi_api_abuse,mitre_t1078
T1078
Bu kuralları /var/ossec/etc/rules/nhi_detection.xml dosyasına ekleyip ossec-control restart ile yükleyebilirsiniz. AWS CloudTrail loglarınızı Wazuh’a S3 üzerinden veya doğrudan agent aracılığıyla besliyorsanız bu kurallar anında devreye girecektir. Benzer mantığı Azure AD servis prensipleri ve GCP servis hesapları için de adapte edebilirsiniz — sadece eventName ve userIdentity.type alanlarını ilgili log şemasına göre düzenleyin.
⚠️ Özellikle Dikkat: AI Ajan Kimlikleri Yeni Bir Risk Katmanı
2025-2026 dönemiyle birlikte NHI sorununa yeni bir boyut eklendi: AI ajan bağlantıları. LangChain, AutoGPT veya kurumsal LLM entegrasyonları için oluşturulan API token’ları ve OAuth grant’ları, klasik servis hesaplarından çok daha belirsiz bir kapsama sahip. Bu bağlantılar çoğunlukla aşırı geniş izinlerle oluşturuluyor çünkü “AI ajanın neye ihtiyaç duyacağı tam bilinmiyor.” Bu tam anlamıyla en az ayrıcalık prensibinin (Principle of Least Privilege) terk edilmesi demek.
Bir AI ajanına verilen geniş kapsamlı bir API token’ı, hem prompt injection saldırısı yoluyla kötüye kullanılabilir hem de token sızdığında saldırgana neredeyse sınırsız hareket alanı tanır. Bu senaryo MITRE ATLAS çerçevesinde AML.T0043 – Craft Adversarial Data ile de örtüşüyor. AI güvenliği ile kimlik güvenliği artık ayrı disiplinler değil.
🔧 Ne Yapmalısınız? 5 Aksiyon Maddesi
- Envanter çıkarın, acil: Tüm bulut ortamınızdaki servis hesaplarını, API token’larını ve OAuth grant’larını listeleyin. AWS IAM Access Advisor, Azure AD Workload Identities veya GCP IAM Recommender bu konuda iyi başlangıç noktaları. Son 90 günde hiç kullanılmamış kimlikler hemen inceleme listesine girmeli.
- Sona erme tarihi (expiry) zorunlu hale getirin: Hiçbir servis hesabı veya API token’ı süresiz olmamalı. CI/CD token’ları için maksimum 30-90 gün, AI ajan bağlantıları için proje süresine kilitli kısa ömürlü token politikası benimseyin.
- Wazuh ile davranışsal anomali tespiti kurun: Yukarıdaki kural setini uygulayın. Özellikle “mesai saati dışı servis hesabı erişimi” ve “beklenmedik API çağrısı hacmi” alarm eşiklerini SIEM seviyesinde izleyin.
- En az ayrıcalık prensibini NHI’ye uygulayın: Bir servis hesabı sadece ihtiyaç duyduğu kaynağa, sadece ihtiyaç duyduğu süre boyunca erişebilmeli. “Full admin” servis hesabı neredeyse hiçbir zaman meşru değildir.
- Offboarding süreçlerine NHI adımı ekleyin: Çalışan ayrılığı veya proje kapanışı prosedürüne “bu kişi/proje tarafından oluşturulan tüm NHI’leri tespit et ve revoke et” adımını ekleyin. Bu kâğıt üzerinde basit görünse de büyük kurumların %70’inde yapılmıyor.
- AI ajan token’larını ayrı kategoride yönetin: LLM entegrasyonları için oluşturulan API anahtarlarını klasik servis hesaplarından ayrı bir politikayla yönetin. Kapsam, süre ve izin düzeyi açısından en kısıtlayıcı yaklaşımı benimseyin; ajan “daha fazlasına ihtiyaç duyarsa” bu bir güvenlik tasarım sorunudur, token kapsamını genişletmek değil mimariye müdahale etmek gerekir.
NHI güvenliği, kurumsal güvenlik ekiplerinin uzun süredir ihmal ettiği ama saldırganların çok iyi bildiği bir alan. Phishing simülasyonlarına, endpoint korumaya ve firewall kurallarına harcanan onca enerji; kimsenin izlemediği 22.500 token karşısında yeterli olmuyor. Wazuh gibi açık kaynaklı araçlarla bu görünürlüğü kazanmak mümkün — ama önce envanteri çıkarmak, sonra izlemek, en son silmek gerekiyor. Sıralama önemli. 🛡️
Orijinal kaynak: https://thehackernews.com/2026/04/webinar-find-and-eliminate-orphaned-non.html
Bir Cevap Yazın