Active Directory tier modeline geçişi planladığım gün, Microsoft dokümantasyonuna bakıp “üç ayda biter, sonra hayat normale döner” demiştim. Sekiz ay sürdü. Üç temel varsayımım çürüdü, her biri sahada bedel ödedi.
Bu yazı, T0/T1/T2 ayrımına geçen birinin —çoktan kitabını okumuş hâliyle— gerçekte ne ile karşılaştığını anlatıyor. Teknik adımları değil, planın çatlayan yerlerini paylaşacağım.
Hızlı tekrar: tier modeli neyi ayırıyor
Tier modeli (Microsoft Enhanced Security Admin Environment / ESAE’nin sadeleştirilmiş hâli) üç katman tanımlar:
- T0: Domain controller’lar, ADFS, PKI, ESAE forest’ı, T0 admin hesapları
- T1: Sunucular (uygulama, veritabanı, dosya, izleme), T1 admin hesapları
- T2: Workstation’lar, son kullanıcı hesapları
Kural çok basit görünür: bir tier’daki credential daha düşük tier’a inebilir, daha yüksek tier’a çıkamaz. T0 admin’i T2 makinesine RDP yapamaz; T2 kullanıcısı T1 sunucusunda yerel admin yetkisine sahip olmaz.
Mantıklı, temiz, çizilebilir. Sahaya geldiğinde üç şeyim yanlıştı.
Yanlış varsayım 1 — “Bu teknik bir geçiştir”
İlk hafta jump host kurdum, GPO’larla Domain Admins grubunu Deny logon locally + Deny logon as a batch job şeklinde T1/T2 makinelerine kısıttım. Restricted Admin RDP açtım. Protected Users grubuna T0 hesaplarını ekledim. Microsoft kitabını yumuşacık takip ediyordum.
İkinci hafta tıkanmalar başladı:
- Bir T1 admin’i workstation’ından doğrudan dosya sunucusuna bağlanamadığında bana yazdı: “Şimdi her seferinde jump host’a önce bağlanıp oradan mı gideceğim? Niye bu kadar zorlaştık?”
- Bir veritabanı admin’i, T0 PKI sunucusundaki sertifika sorununu kendi T1 hesabıyla “hızlıca düzeltmek” istedi. Politika izin vermedi. Aradı, sesi gergindi.
- Helpdesk ekibi, kendi kullanıcı oturumundan workstation desteği veriyordu. Tier ayrımı sonrası “T2 desteği” rolü olmadığı için bağlanamaz oldular.
Bu yüzden geçişin görünür adımları ile görünmeyen adımları ayrı çizelgelere düştü:
- Görünür: jump host, GPO, kısıtlamalar, jump host failover, Protected Users
- Görünmez: helpdesk rol matrisi yeniden yazımı, change request prosedürü, jump host’ta MFA, “T0 işi” tanımının yazılı hâle gelmesi, jump host sessiz timeout disiplini
Yazılı olmayan kısım, yazılı kısmın iki katı zaman aldı.
Yanlış varsayım 2 — “Hesap envanterimi biliyorum”
Geçiş başlamadan önce iki haftalık bir envanter çalışması yapmıştım. Privileged groups’a baktım, Domain Admins, Enterprise Admins, Schema Admins gibi açık T0 grupları temizdi. Service account’ları ayrı bir OU’da topladık, hangi servise ait olduklarını işaretledik. Plan teorik olarak kapalıydı.
Beşinci ayda Splunk dashboard’unda bir grafik düştü: bir BI raporlama aracının service account’ı, son 30 günde 17 farklı sunucuya RDP yapıyordu. Aracın dokümanı yoktu, hangi tier’a ait olduğu yazmıyordu, hatta hangi tier’a ait olması gerektiği de kimsenin masasında değildi.
Kazma kürek araştırma yaptım:
- Service account, beş yıl önce bir veri ambarı projesi için açılmış
- O zamanlar SQL Server’da local admin yetkisi gerektiriyormuş
- Sonradan birden fazla sunucuya “kolaylık olsun” diye yetki eklenmiş
- Originally sadece veri okuma yapması gerekirken 17 sunucuda interaktif login alıyordu
Bu kabus tek değildi. Üç ay içinde benzer dört “hayalet” hesap buldum: dokümanı yok, sahibi belirsiz, yetki düzeyi planda değil.
Sonra “linked account” sorunu çıktı. Bir T1 admin’in günlük kullanıcı hesabı ve T1 admin hesabı, AD’de “manager” alanı üzerinden birbirine bağlanmıştı. Phishing e-postası → günlük hesabı kompromize ederse → manager alanından T1 hesabı izlenebilir → token replay potansiyeli. Microsoft’un “günlük ve admin hesapları aynı kişi olabilir ama altyapısal olarak ayrı olmalı” tavsiyesini görmüştüm, fakat saha yapısında bu link’in nereden geldiğini farkına dahi varmamıştım.
Yanlış varsayım 3 — “Geçiş tamamlanır, bittikten sonra bakım kolaydır”
Sekizinci ayda büyük teknik adımları bitirdim. T0 izole, T1 düzenli, T2 disipline. Tüm jump host’lardan MFA aktif. Service account’lar dağıtılmış, yetkileri minimal. Project plan kapanmış görünüyordu.
İki hafta sonra yeni bir uygulama deployment’ında bir aksaklık: developer ekibi, yeni servisin Service Account’unu “Domain Admins” altında istedi. Bu kez prosedür yazılı olduğu için reddedildi. Ama developer’ların basıncı sürdü — yöneticilerine, sonra direktöre.
Tier modeli tek seferlik bir geçiş değil, sürekli bir disiplin. Yapısı oturdu diye bakım otomatize olmaz; tam tersi, yeni servis/sistem/proje her geldiğinde model tekrar test edilir. Eğer “ekstra adımı pas geçelim, bu sefer hızlı çıkalım” diyebileceğin bir yapı varsa, tier modeli zamanla aşınır.
Şu üç şeyi gözden kaçırmayacağıma yemin ettim:
- Quarterly tier audit: her çeyrek tier sınırlarının hâlâ uygulanıp uygulanmadığını doğrulayan bir BloodHound + custom PowerShell çalıştırması
- New service onboarding checklist: yeni bir kurumsal servis geldiğinde hangi tier’a ait, hangi service account ile koşacak, jump host gerektirir mi — dokümante
- Quarterly red team simülasyonu: T2 makinesinden başlayıp T0’a sıçramayı denediğimiz iç tatbikatlar. Sıçrayabiliyorsak tier’da bir delik var demektir.
Tier modelinin “küçük” ortamlarda da değerli olduğu yer
Belki kurumsal ölçek değilsin: 50 endpoint, 5 sunucu, küçük ofis. Tam Microsoft tier modeli aşırı gelebilir. Yine de iki minimal disiplin işe yarar:
- Ayrı admin hesap kullanımı: günlük kullanıcı hesabıyla server’a RDP yapma. Ayrı bir “admin” hesap aç, sadece o ile yönet. Bu tier modelinin %60’ı.
- Domain admin’inden uzak durma: yerel admin yeterse domain admin verme. Tek bir Domain Admin hesap, sadece DC üzerinde kullanılan. Workstation’a oturum açmaz. Bu da tier modelinin %30’u.
Bu iki adım küçük ortamlarda dahi compromise yarıçapını ciddi kısaltır. Tam tier modelini sonradan ekleyebilirsin.
Sonuç
Active Directory tier modeline geçiş, planda göründüğü kadar lineer değil. Kitap üç ay diyor, saha sekiz ay verdi. Üç temel varsayım üzerinden bedel ödedim:
- “Bu teknik bir geçiştir” → değil; davranışsal bir yeniden yazımdı
- “Hesap envanterimi biliyorum” → bilmiyordum; hayalet service account’lar dolaşıyordu
- “Geçiş tamamlanır, bakım kolaydır” → tamamlanmaz; sürekli disiplin gerektirir
Tier modeli, lateral movement riskini ciddi şekilde azaltır — fakat değer üretmesi için uzun süreli organizasyonel disiplin ister. Eğer bu disiplini sürdüremeyeceğiniz bir ortamdaysanız, model kâğıt üzerinde kalır; gerçek faydası alınmaz.
Hâlâ tier modeline geçmemiş bir ortamı yönetiyorsanız, üç ayda bitireceğinizi planlayın; sekiz aya hazırlanın. Tutkulu olun ama acele etmeyin.