Kurumsal ağlarda kimlik bilgileri, yetki atamaları ve rol izinleri artık yalnızca erişim yönetimi konusu değil; saldırganların sistemler arasında ilerlemek için kullandığı ana güzergâhlardan biri haline geliyor. Son analizler, özellikle hibrit yapılarda unutulmuş oturumlar, önbelleğe alınmış kimlik bilgileri, fazla yetkili servis hesapları ve yapay zekâ ajanlarına tanımlanan geniş izinlerin, saldırı zincirini sessizce büyütebildiğini gösteriyor.
Bu tablo, bulut kimlik sağlayıcıları, Active Directory, IAM platformları, PAM çözümleri ve makine kimlikleriyle çalışan kurumları yakından ilgilendiriyor. Özellikle perakende uç noktaları, yazılım geliştirme ekipleri, SaaS sağlayıcıları, finans kuruluşları ve çoklu bulut kullanan şirketler için risk, tek bir çalınmış oturum açma bilgisinin üretim sistemlerine kadar uzanabilmesi.
Saldırı Zinciri Kimlik Üzerinden Nasıl Kuruluyor?
Güvenlik ekiplerinin sık gördüğü senaryolardan biri, gözden kaçmış bir grup üyeliği ya da eski bir SSO rolünün yıllarca aktif kalması. Saldırgan bir uç noktada düşük ayrıcalıklı erişim elde ettiğinde, bu tür izinler ona etki alanı içinde yatay hareket etme, bulut iş yüklerine sıçrama ve sonunda yönetici seviyesinde kaynaklara ulaşma imkânı verebiliyor.
Teknik açıdan bakıldığında zincir çoğu zaman şu adımlarla ilerliyor: ilk erişim bir kimlik avı kampanyası, çalınmış parola veya sızdırılmış oturum çereziyle geliyor; ardından saldırgan, AD grup üyelikleri, OAuth izinleri, servis hesabı anahtarları ya da API token’ları üzerinden ayrıcalık yükseltiyor; son aşamada ise bulut depolama, veritabanı, CI/CD boru hattı veya üretim sunucuları hedef alınıyor. Bu model, MITRE ATT&CK tarafında özellikle valid accounts, privilege escalation, lateral movement ve cloud account abuse teknikleriyle örtüşüyor.
Öne çıkan nokta şu: tek bir araç çoğu zaman bu zinciri baştan sona göremiyor. EDR uç noktadaki şüpheli davranışı işaretleyebilir, SIEM bazı oturum anomalilerini toplayabilir, IAM ise yalnızca kendi kapsamındaki izinleri gösterebilir. Ancak saldırganın bir uç noktadan Active Directory’ye, oradan da bulut ortamına nasıl geçtiğini birleştiren bütüncül görünürlük eksik kalabiliyor.
Kimlik Güvenliğinde Neden Boşluk Oluşuyor?
Kurumsal güvenlik programlarının önemli bir bölümü kimliği hâlâ çevresel bir kontrol gibi ele alıyor. MFA, koşullu erişim, parola politikaları ve oturum açma denetimleri elbette gerekli; ancak bunlar tek başına yeterli değil. Çünkü gerçek risk, saldırganın ilk kapıdan içeri girmesinden sonra başlıyor.
IGA platformları yaşam döngüsü yönetiminde, PAM çözümleri ayrıcalıklı erişimlerde, bulut güvenliği araçları ise bulut kaynaklarında güçlü olabilir. Fakat bu sistemlerin çoğu, kimlik maruziyetlerinin birbirine nasıl bağlandığını ve bir erişimin diğerine nasıl yol açtığını otomatik olarak modelleyemiyor. Sonuçta, görünürde zararsız duran bir rol ataması veya unutulmuş bir servis hesabı, pratikte kritik bir saldırı yolu oluşturabiliyor.
Bu durum özellikle hibrit yapılarda daha belirgin. Şirket içi Active Directory ile Azure AD/Entra ID, AWS IAM, Google Cloud IAM, SaaS uygulamaları ve üçüncü taraf entegrasyonlar arasında çok sayıda güven ilişkisi oluşuyor. Bir sistemdeki fazla yetki, başka bir sistemdeki kalıcı token ile birleştiğinde saldırı yüzeyi katlanıyor.
Yapay Zekâ Ajanları ve Makine Kimlikleri Riski Büyütüyor
Yeni nesil kurumsal iş akışlarında MCP sunucuları, otomasyon ajanları ve Pydantic AI gibi çerçevelerle çalışan yapay zekâ bileşenleri daha fazla rol üstleniyor. Bu sistemler veritabanlarına, dosya depolarına, ticket platformlarına veya iç API’lere erişmek için çoğu zaman geniş izinler alıyor. Sorun şu ki, bu izinler insan kullanıcılar kadar sık gözden geçirilmiyor.
Bir AI ajanı, bir MCP istemcisi üzerinden yüksek yetkili bir servis hesabına bağlandığında, o hesabın yetkilerini kendi kimliği gibi devralabiliyor. Eğer bu bileşenleri kullanan açık kaynak araçlarda bir zafiyet, yanlış yapılandırma ya da token sızıntısı varsa, saldırgan doğrudan kurumsal kaynaklara ulaşabiliyor. Bu nedenle makine kimlikleri, API anahtarları ve kısa ömürlü olmayan erişim jetonları artık klasik kullanıcı hesapları kadar kritik kabul edilmeli.
Benzer riskler konteyner ortamlarında da görülüyor. Yanlış yapılandırılmış Kubernetes servis hesapları, pod içinden erişilebilen metadata servisleri veya CI/CD sırlarının loglara düşmesi, saldırganın bulut kaynaklarına geçişini kolaylaştırabiliyor. Bazı vakalarda konteynerlerden elde edilen kimlik bilgileri, rastgele açılmış SSH portları ya da yönetim arayüzleri üzerinden kalıcı erişime dönüşebiliyor.
SOC ve Sistem Yöneticileri İçin Pratik Kontrol Listesi
Kimlik tabanlı saldırı yollarını azaltmak için güvenlik ekiplerinin yalnızca parola politikalarına değil, izin ilişkilerine de odaklanması gerekiyor. Aşağıdaki adımlar, özellikle SOC ve IAM ekipleri için hızlı kazanım sağlayabilir:
• Kullanılmayan AD grup üyeliklerini ve eski SSO rollerini düzenli olarak gözden geçirin.
• Servis hesapları için ayrı yaşam döngüsü, sahiplik ve rotasyon politikası uygulayın.
• MFA kapsamını yalnızca kullanıcı hesaplarıyla sınırlamayın; yönetim panelleri ve bulut konsollarını da dahil edin.
• SIEM üzerinde olağandışı oturum açma saatleri, yeni coğrafi konumlar ve sıra dışı token kullanımı için uyarılar kurun.
• EDR tarafında kimlik bilgisi dökümü, LSASS erişimi ve şüpheli PowerShell davranışlarını izleyin.
• Bulut ortamında aşırı yetkili IAM politikalarını ve kalıcı access key’leri tespit edin.
• Ağ segmentasyonu ile uç nokta, yönetim ağı ve üretim ortamı arasındaki geçişleri sınırlandırın.
• Olay müdahale planına kimlik ihlali senaryolarını, token iptali ve oturum sonlandırma adımlarını ekleyin.
Kurumsal Bir Senaryo: Tek Rol Atamasıyla Üretime Ulaşmak
Bir SaaS sağlayıcısını düşünelim. Geliştirme ekibi, bulut geçişi sırasında bir test rolünü geçici olarak açıyor. Proje tamamlandıktan sonra rol kapatılmıyor ve bir geliştirici hesabına bağlı kalıyor. Aylar sonra saldırgan bu hesabı ele geçiriyor. İlk aşamada yalnızca geliştirme ortamına erişebilen saldırgan, rol zinciri sayesinde üretim veritabanına, ardından da yönetici API’lerine ulaşabiliyor.
Bu tür senaryolarda sorun çoğu zaman tek bir açık değil; birbiriyle bağlantılı küçük izin hataları. Bu nedenle güvenlik ekipleri, yalnızca zafiyet taraması yapmak yerine kimlik ilişkilerini, rol devralmalarını ve erişim yollarını birlikte haritalamalı. Özellikle bulut güvenliği, e-posta güvenliği ve olay müdahale süreçlerinin aynı görünürlük katmanında birleşmesi, saldırıların erken aşamada yakalanmasını kolaylaştırır.
Ne Yapılmalı?
Kimlik merkezli savunma yaklaşımı, “içeri girdiyse zaten bitti” varsayımını tersine çevirmeli. Zero Trust mimarisi, en az ayrıcalık ilkesi, kısa ömürlü token kullanımı, düzenli erişim incelemeleri ve kimlik grafiği analitiği bu noktada temel araçlar arasında yer alıyor. Kurumlar, hangi hesabın hangi kaynağa neden eriştiğini yalnızca dokümantasyonda değil, canlı telemetri üzerinde de görebilmeli.
Özellikle hibrit yapılarda, kimlik maruziyetlerini tek tek değil zincir halinde değerlendiren platformlar öne çıkıyor. Çünkü saldırganlar da tam olarak bunu yapıyor: tek bir parola, tek bir rol, tek bir servis hesabı ve tek bir yanlış yapılandırmayı birleştirerek kritik varlıklara giden yolu açıyor.
Sonuç olarak kimlik, artık ağın kenarında duran bir kontrol noktası değil; kurumsal ortamın içinden geçen bir geçiş hattı. Güvenlik programları bu hattı görünür kılmadıkça, saldırganların en kolay kullandığı yol olmaya devam edecek.