Her CISO bu hikayeyi en az bir kez yaşadı: bir çalışan altı hafta önce ayrıldı, HR sisteminde "ayrılan" olarak işaretlendi, AD hesabı kapatıldı. Sonra denetim için bir liste çıkarıyorsunuz — aynı kişi, ayrıldığı tarihten sonra Salesforce'a iki kez giriş yapmış, Notion'da bir sayfayı güncellemiş, GitHub'a hâlâ erişebiliyor. Çıkış prosedürünüz işlemedi. Sebep tek değil: SaaS dünyasında işten çıkış süreci başlı başına parçalı bir problem.
Bu yazıda offboarding'in neden kurumların görmediği bir güvenlik açığına dönüştüğünü, "lastLogon" alanının sandığınız kadar dürüst olmadığını ve çıkış prosedürünün hangi noktalarda gerçek anlamda kapatılması gerektiğini anlatıyoruz.
Problemin gerçek büyüklüğü
Ortalama bir kurumsal çalışan bugün 40-90 SaaS uygulamasına dokunuyor — kurumsal SSO ile bağlı olanlar, Google/Microsoft hesabıyla bağlı olanlar, doğrudan e-posta ile kayıtlı olanlar dahil. Çıkış sırasında BT yalnızca SSO katmanını kapatabiliyorsa:
- SSO ile yönetilen 15-20 uygulama kapanır.
- SSO'ya bağlanmamış ama kurumsal e-posta ile kayıtlı uygulamalar (15-30 adet) açık kalır.
- Kişisel kredi kartıyla alınmış ama kurumsal iş için kullanılan gölge SaaS (10-20 adet) BT'nin radarına dahi düşmez.
Sonuç: çıkış prosedürünüz kâğıt üstünde tamamlandı; gerçekte erişimin %50'sinden fazlası açık kalıyor.
lastLogon yanıltıcı bir tekil kaynaktır
Active Directory ile çalışan BT ekiplerinin en sık başvurduğu alan lastLogon: "bu kullanıcı en son ne zaman giriş yaptı?" sorusunun cevabı. Ne yazık ki bu alan tek bir domain controller üzerinde yazılır ve diğer DC'lere otomatik olarak replike edilmez. Microsoft'un AD dokümantasyonunda açıkça yazıyor; ama sahada BT ekipleri bunu sıklıkla atlıyor.
Pratik sonuç: 3 DC'li bir kurumda bir kullanıcı için lastLogon değeri DC-Istanbul'da "47 gün önce", DC-Frankfurt'ta "2 gün önce", DC-London'da "14 gün önce" görünebilir. Tek bir DC sorgularsanız yanlış cevabı alırsınız. Çıkış sürecinde "bu hesabı kapatabiliriz, 47 gündür kullanılmıyor" kararı verirseniz, gerçekte 2 gün önce aktif olan bir hesabı yanlış değerlendirirsiniz.
JML 5 kategori: 'aktif' ve 'pasif' yeterli değil
Geleneksel "Joiner/Mover/Leaver" yaklaşımı kimliği iki duruma indiriyor: aktif ya da pasif. Oysa pratikte beş kategori var ve her birinin kendi aksiyon listesi olmalı:
- Joiner (işe yeni alınan) — henüz hiçbir SaaS erişimi yok; tahsis edilmesi gereken hesap listesi var.
- Mover (transfer) — pozisyon değişti. Eski erişim hâlâ açık olabilir; rolü değişmiş ama yetkileri yeni göreve taşınmamış olabilir. Çoğu kurum bu kategoriyi takip etmiyor.
- Idle (atıl) — kullanmayı bıraktı ama hâlâ kurumda. Lisans atıl duruyor, hesap ise güvenlik açığı olarak bekliyor.
- Leaver — orphaned (ayrılan ama açık) — ayrıldı ama bazı SaaS'larda hesabı hâlâ aktif. Kritik kategori.
- Leaver — closed (kapatılmış) — ayrıldı ve tüm SaaS'larda erişimi kapatıldı. Hedef durum.
Bu beş kategoriyi raporlayan bir sistemde "ayrılan ama hâlâ aktif" (orphaned) listesi her ay denetlenebilir. İki kategoriye indiren bir sistemde bu sınıf görünmez.
Çıkış prosedürünüzü nasıl gerçek hale getirirsiniz
1. Kullanıcı-merkezli envanter
Her SaaS'ı ayrı ayrı saymak yerine, her kullanıcının tüm SaaS izini tek bir profilde toplayın. CenseCloud bunu DISTINCT username üzerinden yapar — uç-nokta ajanı + tarayıcı eklentisi + IdP sinyallerinin korelasyonuyla.
2. Çoklu-DC lastLogon MAX
Her DC'ye ayrı sorgu, en yeni zaman damgası. Replikasyon gecikmesinin sizi yanıltmasına izin vermeyin.
3. SSO-eliminated takibi
SSO kapatıldı ama uygulamaya doğrudan e-posta/şifre ile giriliyor mu? Bu vakaları ayrı bir kategori olarak raporlamak gerekir; SSO kapatması güvenlik garantisi değildir.
4. Aylık orphan denetimi
Ayda bir, "ayrılan ama hâlâ aktif" listesini çıkarın. Sıfıra inmediği sürece offboarding süreciniz tamamlanmış sayılmaz.
Sonuç: 'kapattım' diyebilmek için önce görmek lazım
IT'nin AD üzerinden hesap kapatma yetkisi var; ama SaaS dünyasında AD bir kaynak, otorite değil. SaaS çıkışı için kimlik envanteri uç-noktadan ve tarayıcıdan da beslenmeli. Aksi halde "kapattım" cümlesi yalnızca bir kâğıt parçası olur.
CenseCloud bu envanteri çoklu-DC AD okuması + uç-nokta ajanı + tarayıcı eklentisi üzerinden kurar. Kimlik ve erişim çözümü veya CenseRisk modülü detaylar için.