Bulut, SaaS ve otomasyon katmanı büyüdükçe kuruluşların kimlik envanteri de hızla dağılıyor. Yapılan son teknik incelemeler, bu dağınık yapı içinde merkezi IAM kayıtlarında görünmeyen yerel hesaplar, gömülü servis kimlik bilgileri ve eski oturum açma akışlarının hem denetimi hem de savunmayı zorlaştırdığını ortaya koyuyor.
Kimlik görünürlüğü, bir ortamda kimlerin bulunduğunu, hangi erişimlere sahip olduğunu ve bu erişimin çalışma anında nasıl kullanıldığını tek bir sürekli görünümde birleştiren yaklaşım olarak tarif ediliyor. Güvenlik ekipleri için asıl fark, politika niyeti ile gerçek yürütme arasındaki boşlukta ortaya çıkıyor: IAM sistemleri bir hesabın neye erişmesi gerektiğini söylerken, uygulamalar ve altyapı bu erişimin gerçekten kullanılıp kullanılmadığını gösteriyor.
İncelemelerde, saldırganların artık çoğu kez kötü amaçlı yazılımla değil, geçerli kimlik bilgileriyle içeri girdiği vurgulanıyor. Kimlik avı, token hırsızlığı ve oturum kaçırma yöntemleri IdP günlüklerinde sıradan bir kullanıcı hareketi gibi görünebiliyor. Cloud ortamlarında servis hesapları, API anahtarları ve iş yükü kimlik bilgileri çoğu zaman çalışan hesaplarını sayıca geçiyor; bu hesapların önemli bir bölümü de süre sonu olmadan yaşamaya devam ediyor.
Gizli hesaplar ve eksik kayıtlar güvenlik açığını büyütüyor
Raporlarda “identity dark matter” diye anılan görünmeyen yüzey, yerel uygulama hesaplarını, merkezi kimlik sağlayıcıya hiç bağlanmamış entegrasyonları ve kalıcı makine kimlik bilgilerini kapsıyor. Sorun yalnızca envanter eksikliği değil; bu hesapların ne işe yaradığının, kimin sahip olduğunun ve nerelerde kullanıldığının bilinmemesi de erişim zincirini bulanıklaştırıyor.
Kuruluşlar SaaS geçişini hızlandırdıkça, buluta göç ettikçe ve otomasyonu genişlettikçe bu boşluk daha görünür hale geliyor. Bir uygulama IAM programına hiç dahil edilmemişse raporlarda yer almıyor ve bu yokluk yanlışlıkla uyumluluk olarak okunabiliyor. Denetim platformları da çoğu zaman yalnızca bağlı oldukları uygulamaları raporluyor; bağımsız bir keşif yapmadıkları için görünmeyen kimlikleri yeniden üretmekten öteye geçemiyor.
Burada iki katman arasındaki fark kritik hale geliyor. Bir kullanıcının rolü, grubun içindeki başka bir grup ya da bulut hesapları arasındaki güven ilişkisi nedeniyle, görünürde düşük yetkili olsa bile fiilen yönetici erişimine sahip olabiliyor. Bu nedenle erişim ilişkilerinin haritalanması, nominal yetkiyle gerçek yetki arasındaki farkı açığa çıkarıyor.
Görünürlüğün yalnızca insan hesaplarına değil, otomasyon ve yapay zekâ iş yüklerine de uzandığı belirtiliyor. Otonom ajanlar farklı sistemlerde devredilmiş yetkilerle hareket ediyor ve insan incelemesinin yetişemeyeceği hızda işlem üretebiliyor. Kimlik güvenliği ekipleri için bu, çalışma anındaki davranışı görmeden yapılan her değerlendirmeyi eksik bırakıyor.
Bulut ve çoklu bulutta kimlik takibi neden zorlaşıyor
Bulut sağlayıcıları kimliği farklı dillerle tanımlıyor. AWS tarafında roller, kimlik ve kaynak tabanlı politikalar ile çapraz hesap rol devralma modeli öne çıkarken, Azure ve Entra ID’de dizin nesneleri, Azure RBAC atamaları ve yetkilendirilmiş uygulama izinleri devreye giriyor. Google Cloud’da hizmet hesapları ve organizasyon, klasör, proje hiyerarşisi üzerinden miras kalan IAM bağları belirleyici oluyor. SaaS uygulamaları ise çoğu zaman kendi yönetici kademelerini, özel rollerini ve yerel hesaplarını kullanıyor.
Bu farklı modeller normalize edilmediğinde güvenlik ekipleri her platformu ayrı ayrı inceliyor ve aradaki bağ dokusunu kaçırabiliyor. Federated trust ilişkileri, çapraz hesap devralma ve paylaşılan kimlik bilgileri, bir buluttaki hesabın başka bir ortam içinde hareket etmesini sağlıyor. İncelemede, bulut içi yanal hareketin çoğu kez ağ yollarından çok bu IAM güven ilişkileri üzerinden ilerlediği aktarılıyor.
Makine kimliklerinin bulut ortamlarında çoğu zaman çoğunluğu oluşturduğu da raporda yer alıyor. Pipeline’lar, Terraform çalıştırmaları ve orkestrasyon araçları tarafından oluşturulan bu kimlikler, insan kaynağı odaklı işe alım ve ayrılma süreçlerine bağlı olmadıkları için klasik yaşam döngüsü kontrollerinin dışında kalabiliyor. Bu nedenle kontrol düzlemi kimlikleri ayrı bir risk başlığı olarak öne çıkıyor.
Bir otomasyon kimliği ele geçirildiğinde saldırgan yalnızca bir hesabı kullanmıyor; altyapı ayarlarını değiştirebiliyor, yeni erişimler üretebiliyor ve kayıt mekanizmalarını kapatabiliyor. Bu yüzden rapor, her insan dışı kimlik için de isimlendirilmiş bir sahip, tanımlı amaç, son kullanma ya da rotasyon takvimi ve aktif izleme gerektiğini söylüyor.
Denetim, analiz ve platformlar aynı soruya farklı yerden bakıyor
Kimlik görünürlüğü ve istihbaratı, tek başına bir güvenlik katmanı olarak değil, mevcut IAM yatırımlarını doğrulanabilir hale getiren gözlem düzeyi olarak konumlanıyor. IGA sistemleri sertifikasyon kampanyalarının gerçekten erişimle örtüşüp örtüşmediğini görmek için bu veriye ihtiyaç duyuyor. PAM tarafı, kasaya alınmadan çalışan ayrıcalıklı hesapları keşfetmek istiyor. Güvenlik operasyonları ise soruşturma sırasında olay zaman çizelgesini farklı konsollar arasında birleştirmek yerine kimlik bağlamını tek yerden almak istiyor.
NIST SP 800-207 ile tanımlanan zero trust yaklaşımının da sürekli doğrulama olmadan çalışmadığı hatırlatılıyor. Erişim kararının kalitesi, oturum bağlamına, kimlik bilgisi türüne, geçmiş davranışa ve hedef sistemin hassasiyetine bağlı. Kimlik istihbaratı bu sinyali sağlıyor; aynı zamanda eski protokolleri hâlâ kabul eden uygulamaları ya da MFA olmadan duran yönetici hesaplarını da görünür kılıyor.
İncelemede adı geçen identity visibility and intelligence platformları arasında Orchid Security, Veza, SailPoint, Saviynt, Silverfort, Semperis ve CrowdStrike Falcon Identity Protection yer alıyor. Her biri farklı bir başlangıç noktasından ilerliyor: Orchid Security uygulama ve altyapıdan doğrudan kimlik, yetki ve kimlik doğrulama akışlarını çıkarıp denetime hazır kanıt üretiyor; Veza veri sistemleri, bulut platformları ve SaaS genelinde etkin yetkileri ilişki grafiğiyle haritalıyor; SailPoint yaşam döngüsü, sertifikasyon ve politika uygulamasına odaklanıyor; Saviynt IGA iş akışlarını CIEM analiziyle birleştiriyor; Silverfort eski ve yönetilmeyen sistemlerde çalışma anı kimlik doğrulamasını görünür kılıyor; Semperis Active Directory ve Entra ID üzerinde yapılandırma hijyeni, saldırı yolu analizi ve kurtarma başlıklarına yoğunlaşıyor; CrowdStrike Falcon Identity Protection ise kimlik tehdit tespiti ve müdahalesini uç nokta ile iş yükü telemetrisiyle bağlıyor.
Hangi mimari seçilirse seçilsin, temel yetenek tek bir otoritatif envanter oluşturmak olarak tarif ediliyor. Bu envanterin IdP’ler, bulut platformları, uygulamalar ve altyapı arasında kimlikleri uzlaştırması ve etkin erişimi ilişkilendirmesi gerekiyor. Sadece IAM yapılandırmasını okuyan bir sistem, IAM’in zaten taşıdığı kör noktaları tekrar üretmekten başka bir şey yapmıyor.
Analiz tarafında da envanter tek başına yeterli sayılmıyor. Davranışsal baz çizgisi olmadan, bir kimlik için normal kullanım ile anomali arasındaki fark ayırt edilemiyor. Bu yüzden davranışsal baz çizgisi, aynı kimlik bilgisiyle yürüyen olağan otomasyonu yetki suiistimalinden ayırmak için temel kriter olarak gösteriliyor.
Rapor, saldırı yolu analizini, yanlış yapılandırmanın yetki, erişilebilirlik ve çalışma zamanı bağlamında gerçekten sömürülebilir olup olmadığını ölçen bir kontrol olarak anlatıyor. Bulguların MITRE ATT&CK tarafında Valid Accounts (T1078) gibi kimlik odaklı tekniklere eşlenmesi de analistlerin tekil alarmlar yerine saldırgan davranışını okumasına yardımcı oluyor. Remediation routing ise bulguyu ortak bir kuyruğa atmak yerine kanıtıyla birlikte doğru ekibe yönlendiriyor.
Kimlik görünürlüğü programlarında önceliklendirme de ayrı bir aşama olarak ele alınıyor. Geniş yetkiyle üretim erişimi olan sahipsiz servis hesapları, MFA kullanmadan oturum açan yönetici hesapları, hiç döndürülmemiş kimlik bilgileri ve ayrılmış çalışanlara ait uyuyan hesaplar, ilk hedefler arasında sayılıyor. Bunlar hem net sahibi olan hem de doğrudan düzeltilip kapatılabilen bulgular olarak görülüyor.
Uygulama sırası için de bir yol haritası veriliyor. Önce kritik uygulamalar ve bulut hesapları kapsam içine alınıyor. Ardından doğrudan uygulama ve altyapı katmanından kimlik verisi çekiliyor. Sonra iç içe gruplar, güven ilişkileri ve miras kalan izinler çözülerek gerçek erişim haritalanıyor. Her hesap için bir insan sahibi ve inceleme ya da sonlandırma tarihi atanıyor. Son aşamada da normal kullanım davranışı baz alınıp yetki kullanımı ve kimlik doğrulama örüntülerindeki sapmalar izleniyor. Denetim dönemlerinde elektronik tabloları yeniden toplamak yerine canlı telemetri üzerinden kanıt üretimi yapıldığı da not düşülüyor.
Kuruluşların bu programı ne kadar hızlı kuracağı, ortam karmaşıklığına, uygulama sayısına ve uygulama sahiplerinin erişilebilirliğine göre değişiyor. İnceleme, kimlik görünürlüğünün bir noktada biten proje değil, görünmeyeni bulup etkin erişimi doğrulayan sürekli bir operasyon alanı olduğunu ortaya koyuyor.