# Vaka İncelemesi: Active Directory’de Kontrolden Çıkan Hesap Yaşam Döngüsü - Bağlantı: https://musti.org/vaka-incelemeleri/vaka-incelemesi-ad-hesap-yasam-dongusu-denetimi/ - Yayımlanma: 2026-09-23T23:51:04+03:00 - Yazar: mmutlu _📌 Bu vaka incelemesi, alanımda sıkça karşılaşılan bir sorun örgüsüne dayanan ** temsili bir anlatımdır** — belirli bir şirketi, kişiyi veya tarihi olayı tanımlamaz. Gerçek mesleki deneyimlerimden ilham alan, öğretici amaçlı bileşik (composite) bir örnektir._ ## Durum Yıllık bir güvenlik denetiminde, dışarıdan gelen denetçi ekibi Active Directory’de** ayrılmış personele ait ama hâlâ aktif olan 200’den fazla kullanıcı hesabı** tespit etti. Bunların bir kısmı aylar, bazıları ise yıllar önce şirketten ayrılmış kişilere aitti. Daha endişe verici olanı: bu hesaplardan birkaçının hâlâ VPN erişimi ve dosya sunucusu yetkileri aktifti. ## İlk Teşhis: Neden Bu Kadar Büyüdü? Kök nedene indiğimde, sorunun tek bir hatadan değil, **süreç eksikliğinden** kaynaklandığını gördüm: İK’dan ayrılış bildirimleri e-posta ile geliyordu, BT ekibi bunları manuel olarak işliyordu, ve yoğun dönemlerde bu bildirimler gözden kaçabiliyordu. Bazı durumlarda İK bildirimi hiç göndermemişti. Sistemsel bir kontrol noktası yoktu — her şey insan hafızasına ve disiplinine bağlıydı. ## Yaklaşım Önce mevcut hasarı ölçülebilir hale getirdim: [90 günden fazla giriş yapmamış hesapları tespit eden bir PowerShell scripti](https://musti.org/powershell/powershell-ad-inaktif-hesaplar-sureli-parolalar/) ile tam bir envanter çıkardım. Bu, “kaç hesap risk altında” sorusunu net bir sayıya( 247 hesap) dönüştürdü — yönetime sunulacak somut bir veri elde etmiş oldum. Ardından iki aşamalı bir çözüm kurguladım: * **Acil müdahale:** Tespit edilen 247 hesaptan, İK kayıtlarıyla çapraz kontrol edilerek gerçekten ayrılmış olduğu doğrulananlar (203 hesap) derhal devre dışı bırakıldı ve 30 gün sonra arşivlendi. * **Kalıcı çözüm:** İK sistemi ile AD arasında otomatik bir senkronizasyon köprüsü kurdum — bir çalışanın İK sisteminde “ayrıldı” olarak işaretlenmesinin, 24 saat içinde AD hesabını otomatik devre dışı bırakan bir sürece dönüşmesini sağladım. ## Neden Otomasyon, Neden Sadece Politika Değil? İlk içgüdüm “yeni bir süreç dokümanı yazalım, ekip buna uysun” olabilirdi. Ama denetimde ortaya çıkan asıl gerçek şuydu: **var olan süreç zaten yazılıydı, uygulanmıyordu**. İnsan hafızasına bağlı kontrol noktaları, yoğunluk arttığında ilk kırılan halka oluyor. Bu yüzden çözümü bir “hatırlatma” değil, bir “otomatik tetikleyici” olarak kurguladım — insan müdahalesi gerektirmeyen bir güvenlik ağı. ## Sonuç Devreye alınan otomasyon sonrasında yetim hesap sayısı üç ay içinde sıfıra indi ve o günden beri bu şekilde kaldı. Daha da önemlisi, bir sonraki denetimde bu madde“ kapatıldı” olarak işaretlendi — ve denetim raporunda AD hesap yönetimi artık bir risk maddesi olarak yer almıyor. ## Çıkarım Bu vaka bana şunu net şekilde gösterdi: kimlik yönetiminde **tekrarlayan, insan hafızasına bağlı süreçler er ya da geç kırılır**. Kalıcı çözüm, daha fazla disiplin değil, daha az insan müdahalesi gerektiren bir sistem kurmaktır. _İlgili yazı: [Microsoft Entra ID ile bulut kimlik yönetimi](https://musti.org/microsoft-entra-id/microsoft-entra-id-nedir-bulut-kimlik-yonetimi/)_