Herhangi bir güvenlik değerlendirmesinde basit bir soru sorun: "Bu veritabanına kimlerin erişimi var?"
Olacakları izleyin. Biri dizini açıp bir grup listeler. Bir başkası o grubun içinde üç iç içe grup olduğunu, birinin İK sisteminden senkronize edildiğini hatırlatır. Üçüncü kişi, SaaS uygulamasının kendi admin konsolundan dizini tamamen atlayarak doğrudan erişim verdiğini söyler. Connection string taşıyan servis hesabından ise kimse bahsetmez; çünkü var olduğunu kimse hatırlamıyordur.
Soru basit görünür. Oysa kurumsal BT'nin en zor sorularından biridir.
"Kimin neye erişimi var" neden bu kadar zor?
Gerçek bir kurumda erişim bir tablo değildir; bir grafiktir, üstelik ele avuca sığmayan bir grafik:
- İç içe gruplar üyeliği geçişli yapar: A grubundasınızdır, A B'nin içindedir, yetkiyi B verir. Üç adım sonra zinciri elle takip edebilen kalmaz.
- Roller ve entitlement'lar araya dolaylılık katar: rol yetkileri paketler, yetki kaynaklara eşlenir ve rol tanımları yıllar içinde sessizce başkalaşır.
- SaaS yetkileri dizininizin tamamen dışında yaşar. Her uygulamanın kendi yetki modeli, kendi paylaşım ayarları, kendi "admin" tanımı vardır.
- Servis hesapları ve insan-dışı kimlikler — hızla büyüyen AI ajanları dahil — hiçbir gözden geçirmeye girmeyen kalıcı erişimler taşır.
Her sistem kendi adına cevap verebilir. Sistemlerin tamamı üzerinden kimse cevap veremez. Saldırganların kullandığı yollar da tam olarak sistemler arası olanlardır: unutulmuş bir gruptaki atıl hesabın dört adım sonra bir üretim parolasına ulaşması gibi.
Aynı boşluğu denetimler de acı şekilde görünür kılar. Erişim sertifikasyonu dönemlerinde yöneticilere onaylamaları için gönderilen listeler, tam da bu soruya verilmiş yarım cevaplardır: atanmış yetkiler görünür, efektif erişim görünmez. Yönetici de göremediği şeyi gözden geçiremez — ve her şeyi olduğu gibi onaylar.
Gartner probleme bir isim verdi
Gartner, 2025'te bu boşluğu kapatmak için üretilen araçlara bir kategori tanımladı: Identity Visibility and Intelligence Platforms (IVIP). Erken benimseme aşamasında bir kategori olarak işaretlenen IVIP, ortamın tamamındaki kimlik verisini birleştirip cevaba dönüştüren platformları tarif ediyor. Kategori genç; ama tanımladığı yetenekler, kimlik görünürlüğü projelerinin alışveriş listesi haline hızla geldi.
Temel yetenekler
Birleşik kimlik grafiği. İşin temeli korelasyondur: dizinlerden, IdP'lerden, İK sistemlerinden, bulut platformlarından ve SaaS uygulamalarından kimlikleri, hesapları, grupları, rolleri ve entitlement'ları toplamak; sonra AD'deki "j.smith", IdP'deki "[email protected]" ve CRM'deki "John S." kayıtlarının aynı insan olduğunu çözmek. Korelasyon olmadan "kaç kimliğimiz var" sorusuna verilen her sayı hayal ürünüdür.
Yolun tamamıyla birlikte efektif erişim. Kategorinin baş sorgusu şudur: Kişiye ne atandığı değil, fiilen nereye ulaşabildiği — zincirin tamamı gösterilerek. John finans veritabanını değiştirebilir; çünkü A grubunda, A grubu B'nin içinde, B de db-writers rolünü taşıyor. Yol, cevabın kendisi kadar önemlidir; çünkü düzelttiğiniz şey yoldur.
Blast radius analizi. Aynı grafiğin tersinden dolaşılması: bir kaynaktan — ya da ele geçirilmiş bir hesaptan — başlayıp nereye ulaştığını sormak. Gece 2'de bir hesap ihlal edildiğinde olay ekibinin ilk sorusu "bu kimlik nelere dokunabilir?" olur ve bu sorunun tek iyi cevabı, zaten kurulu duran bir grafikten gelir.
Duruş (posture) bulguları. Grafiği riskli desenler için sürekli taramak: sahibi şirketten ayrılmış sahipsiz (orphan) hesaplar, aylardır oturum açmadığı halde ayrıcalıklı erişim taşıyan atıl ama yetkili kimlikler, aynı kişinin hem oluşturup hem onaylayabildiği görevler ayrılığı (SoD) çatışmaları ve kimsenin hesap vermediği sahipsiz ajanlar. Bu, kimlik güvenliği duruş yönetiminin (ISPM) analitik çekirdeğidir — sistem başına kontrol listeleri yerine grafiğin üzerinde çalışır.
Asıl ayrım: Bulduğunu düzeltebiliyor mu?
Kategorinin içindeki fay hattı burası. Görünürlük araçlarının çoğu salt-okunur birer katmandır: sistemlerinize okuma yetkisiyle bağlanır, grafiği kurar, bulgular üretir. Sonra bulgu bir talebe dönüşür, talep başka bir ekibe gider, o ekip değişikliği bambaşka bir araçta yapar — ve haftalar sonra biri grafiğin hâlâ aynı fikirde olup olmadığını kontrol eder.
Erişimin fiilen verildiği kontrol düzlemine — IdP ve IGA katmanına — sahip olan bir platform ise döngüyü doğrudan kapatabilir. Bulgu ve düzeltme aynı sistemde yaşar: atıl hesabın yetkisini kaldır, sahipsiz hesabı devre dışı bırak, SoD çatışmasını çöz — ideal olarak neyin değişeceğini önceden gösteren bir dry-run ve bir şey bozulursa geri alacak bir undo ile. Talep kuyruğunda biten görünürlük bir rapordur; düzeltilmiş bir bulguyla biten görünürlük bir kontroldür.
Doğal dille sorun
Not etmeye değer bir eğilim daha: arayüz doğal dile kayıyor. Grafik sorguları yazmak yerine soruyu soruyorsunuz — "Finans veritabanına kimler, hangi yollardan erişebiliyor?", "Hangi admin hesapları 90 gündür oturum açmadı?" — ve platform soruyu grafik dolaşımına çeviriyor. Bu göründüğünden daha önemli; çünkü bu cevapları uzmanın alet çantasından çıkarıp denetçilerin, yöneticilerin ve olay müdahale ekiplerinin eline veriyor.
Bu ayrımın pratik bir sonucu daha var: salt-okunur katman, izlediği sistemlerle er ya da geç senkron kaybeder ve grafiği gerçekliğin gerisinde kalır. Kontrol düzleminin içindeki görünürlük ise değişikliği dışarıdan öğrenmek zorunda değildir; değişiklik zaten kendi üzerinden geçer.
Monosign bu resmin neresinde?
Monosign'ın Identity Intelligence modülü, yanına iliştirilmiş değil, kontrol düzleminin içine inşa edilmiş bir IVIP'tir: birleşik grafik, efektif erişim yolları, blast radius analizi ve duruş bulguları, kimlikleri zaten yöneten platformun içinde çalışır — böylece düzeltme bir talep değil, dry-run'lı tek bir tıklamadır. Kategorinin derli toplu tanımı için sözlükteki IVIP maddesine de bakabilirsiniz.
"Kimin neye erişimi var?" bir araştırma projesi değil, bir sorgu olmalı. IVIP, onu sorguya dönüştürmenin kategorisi.
