Active Directory Tier Modeli: Yönetici Hesaplarını Katmanlamak

Domain Admin parolası nadiren etki alanı denetleyicisinden çalınır. Çoğunlukla o hesapla oturum açılmış sıradan bir iş istasyonundan ya da bir uygulama sunucusunun belleğinden çıkar. Active Directory tier modeli, yönetici kimlik bilgilerinin bu düşük güvenlikli sistemlere hiç düşmemesi için kurulan bir erişim mimarisidir. Aşağıda Tier 0/1/2 sınırının nasıl çizildiğini, hesap yapısını, GPO ile oturum kısıtlamalarını, PAW’ı ve ortamı kırmadan uygulama sırasını anlatıyoruz.

Kimlik bilgisi hırsızlığı ve tier modelinin mantığı

Windows’ta etkileşimli oturum, RDP bağlantısı, “Farklı çalıştır” ile süreç başlatma ve zamanlanmış görevde parola saklama gibi işlemler, kimlik bilgisinin türetilmiş biçimlerini (NT hash, Kerberos biletleri) hedef sistemin belleğinde bırakır. O sistemde yerel yönetici yetkisi alan saldırgan bunları okur, pass-the-hash veya pass-the-ticket ile başka sistemlere geçer. Yardım masasının Domain Admin hesabıyla bir kullanıcı bilgisayarına RDP yapması, o makinedeki sıradan bir zararlıyı etki alanının tamamına taşıyabilir. Tek RDP yeter.

Tier modeli iki kurala dayanır:

• Kontrol kuralı: Bir varlığı kontrol eden her şey o varlıkla aynı tier’dadır. Etki alanı denetleyicisinin yedeğini alan sunucu da Tier 0’dır.
• Oturum kuralı: Üst tier hesabı alt tier sistemde oturum açmaz. Tier 0 hesabı bir iş istasyonunda kimlik bilgisi bırakmaz; alt tier hesabı da üst tier sistemi yönetemez.

Model bir ürün değildir; kurumsal siber güvenliğin temelindeki bir çalışma disiplinidir. GPO, kimlik doğrulama politikaları ve ayrı hesaplar gibi teknik kontroller, bu disiplinin dışına çıkmayı zorlaştırmak için vardır.

Tier 0, 1 ve 2 varlıklarını belirlemek

Sahada en sık gördüğümüz hata, Tier 0’ı yalnız DC’lerden ibaret saymaktır. Kontrol kuralını dürüstçe uyguladığınızda liste uzar:

Tier	Varlık örnekleri	Neden bu tier
Tier 0	DC’ler, AD CS, AD FS, Entra Connect sunucusu	Kimliğin kendisini üretir veya senkronize eder
Tier 0	DC’leri barındıran hipervizör, DC yedeğini alan yedekleme sistemi	DC diskine ve belleğine erişebilir
Tier 0	DC’lere ajan dağıtan yönetim araçları, PAM kasası	DC üzerinde kod çalıştırabilir
Tier 1	Uygulama, veritabanı, dosya ve e-posta sunucuları	İş verisini barındırır
Tier 2	İş istasyonları, dizüstüler, yazıcılar, kullanıcı destek araçları	Kullanıcı kullanımına açık, internete maruz

Pratik test şu soru: “Bu sistemin yöneticisi bir DC’de kod çalıştırabilir mi, DC’nin diskini okuyabilir mi?” Cevap evetse sistem ya Tier 0’dır ya da DC ile ilişkisi kesilmelidir. Örneğin tüm sunucuları taşıyan tek bir hipervizör kümesi DC’leri de barındırıyorsa, iki yol vardır: küme Tier 0 sayılır ve yönetimi daraltılır, ya da DC’ler ayrı bir yönetim düzlemine taşınır. Ortası yok. Yedekleme sistemleri için benzer kararlar yedek altyapısında kimlik izolasyonu yazısında ele alınıyor.

Yönetici hesap yapısı ve isimlendirme

Her yönetici, ihtiyaç duyduğu her tier için ayrı bir hesap kullanır; e-posta ve internet işini ayrıcalıksız standart hesabıyla yapar. İsimlendirme, hesabın tier’ını hem insana hem betiğe ilk bakışta göstermelidir.

Hesap	Örnek ad	Kullanım yeri
Standart kullanıcı	ayilmaz	E-posta, internet, iş uygulamaları
Tier 2 yönetici	t2-ayilmaz	İş istasyonu desteği
Tier 1 yönetici	t1-ayilmaz	Sunucu yönetimi
Tier 0 yönetici	t0-ayilmaz	AD ve Tier 0 sistemleri, yalnız PAW’dan

Hesaplar tier’a göre ayrı OU’larda tutulur, her tier’ın kendi yönetici grubu olur. Tier 0 hesaplarının posta kutusu olmaz, Entra ID’ye senkronize edilmez ve Protected Users grubuna eklenir. Protected Users üyeleri için NTLM, Kerberos ön kimlik doğrulamasında DES/RC4 ve delegasyon kullanılamaz; TGT ömrü dört saatle sınırlanır, kimlik bilgisi önbelleğe alınmaz. Bu kısıtlamalar eski uygulamaları kırabilir; önce birkaç hesapla deneyin, sonra yayın.

İlk adım mevcut durumu görmek: ayrıcalıklı grupların iç içe üyeliklerini çözerek listeleyin. Bu listenin uzunluğu çoğu ortamda ilk sürprizdir.

Import-Module ActiveDirectory
$gruplar = 'Domain Admins','Enterprise Admins','Schema Admins',
           'Administrators','Account Operators','Backup Operators',
           'Server Operators','Print Operators'
$sonuc = foreach ($g in $gruplar) {
    Get-ADGroupMember -Identity $g -Recursive |
        Where-Object objectClass -eq 'user' |
        Get-ADUser -Properties LastLogonDate, PasswordLastSet, Enabled |
        Select-Object @{n='Grup';e={$g}}, SamAccountName, Enabled,
                      LastLogonDate, PasswordLastSet
}
$sonuc | Sort-Object Grup, SamAccountName | Format-Table -AutoSize

Backup Operators, Server Operators ve Account Operators gibi yerleşik gruplar DC üzerinde dolaylı Tier 0 yetkisi verir. Hedef, bu grupların boş olmasıdır.

Oturum kısıtlamalarını GPO ile zorlamak

Oturum kuralı, User Rights Assignment ayarlarıyla teknik olarak zorlanır. Ayarlar Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment altındadır ve tier OU’larına bağlanan ayrı GPO’larla uygulanır.

Hedef sistemler	Reddedilecek gruplar	Ayarlar
Tier 2 iş istasyonları	Tier 0 ve Tier 1 yöneticileri	Tüm deny hakları
Tier 1 sunucular	Tier 0 yöneticileri	Tüm deny hakları
Tier 1 sunucular	Tier 2 yöneticileri	Yönetim yetkisi verilmez; deny tercihe bağlı
Tier 0 sistemleri	Tier 1 ve Tier 2 yöneticileri	Etkileşimli ve RDP deny

“Tüm deny hakları” şu beş ayardır: Deny log on locally, Deny log on through Remote Desktop Services, Deny access to this computer from the network, Deny log on as a batch job ve Deny log on as a service. Ağ erişimi reddini DC’lere uygularken dikkatli olun: kullanıcıların Group Policy ve kimlik doğrulama için DC’ye ağ üzerinden erişmesi gerekir; DC GPO’suna yalnız gerçekten dışarıda kalması gereken yönetici gruplarını yazın.

Daha sıkı kontrol için Windows Server 2012 R2 etki alanı işlevsellik düzeyinden itibaren kullanılabilen Authentication Policies ve Authentication Policy Silos var: Tier 0 hesaplarının Kerberos TGT’si yalnız belirli Tier 0 bilgisayarlarından alınabilir. Kimlik bilgisinin başka makinede kullanılması DC tarafında engellenir ve bunu aşmak GPO’yu aşmaktan zordur; karşılığında Kerberos armoring (FAST) desteği ve dikkatli test ister.

Tier 1 sunuculara RDP ile bağlanırken kimlik bilgisinin hedefte kalmaması için Remote Credential Guard veya Restricted Admin modunu değerlendirin. Yerel yönetici hesaplarının her makinede farklı parolaya sahip olması da yatay hareketi kesen tamamlayıcı bir kontroldür; adımlar Windows LAPS geçişi yazısında.

Ayrıcalıklı erişim iş istasyonu (PAW)

Tier 0 hesabının parolasının girildiği cihaz da Tier 0’dır. Kendi günlük dizüstüsünden Tier 0 hesabıyla RDP yapan yönetici, kurduğunuz bütün GPO’ları tek hamlede boşa çıkarır. PAW, yalnız yönetim işi için kullanılan sıkılaştırılmış bir cihazdır:

• E-posta istemcisi, genel internet tarayıcısı ve ofis uygulamaları yoktur; internet erişimi yönetim portallarıyla sınırlıdır.
• Yalnız Tier 0 yöneticileri oturum açabilir; standart kullanıcı hesapları reddedilir.
• Credential Guard, Secure Boot, BitLocker ve uygulama kontrolü (WDAC/AppLocker) etkindir.
• Cihaz Tier 0 OU’sunda yönetilir; Tier 2 yönetim araçları bu cihaza ajan kuramaz.

Her yöneticiye ayrı fiziksel cihaz verilemiyorsa, Tier 0 erişimi için merkezî ve sıkılaştırılmış atlama sunucuları kullanılabilir. Ama atlama sunucusuna bağlanılan cihaz hâlâ sorudur. Atlama sunucusu yalnız ek bir sıçrama noktasıdır; kaynak cihazın riskini ortadan kaldırmaz.

Enterprise access model ile ilişkisi

Microsoft, klasik tier modelini ve ESAE (“red forest”) önerisini daha geniş bir çerçeve olan enterprise access model ile güncelledi. Bu model hibrit ve bulut ortamlarını da kapsar; control plane, management plane ve data/workload plane kavramlarını kullanır. Şirket içi AD için Tier 0 kabaca control plane’e karşılık gelir; Entra ID’deki Global Administrator ve Privileged Role Administrator gibi roller de aynı düzlemdedir.

Sahadaki karşılığı şudur: şirket içi Tier 0 ile bulut kimlik yönetimi ayrı düşünülemez. Entra Connect sunucusunu ele geçiren saldırgan hem buluttaki hem şirket içindeki kimliğe etki edebilir. Bu sunucu Tier 0’dır. Bulut tarafındaki ayrıcalıklı rollerin tam zamanında yetkilendirilmesi Entra ID PIM rehberinde anlatılıyor. Genel bir başlangıç noktası arıyorsanız Active Directory güvenlik kontrolleri yazısı, tier modelinin yanında uygulanacak temel kontrolleri listeler.

Uygulama sırası ve sahada sık görülen hatalar

Sıra önemlidir. Kırılma riski en düşük adımdan başlayın:

1. Envanter: Ayrıcalıklı grup üyeleri, hizmet hesapları ve Tier 0 adayı sistemler listelenir; her sistemi kimin yönettiği yazılır.
2. Tier 0 sınırını çizmek: DC’leri kontrol eden tüm sistemler belirlenir; gerekiyorsa yedekleme, hipervizör ve yönetim araçlarının DC ile ilişkisi kesilir.
3. Hesap ayrıştırma: Tier 0 hesapları açılır, Domain Admins üyeliği bu hesaplara taşınır; kişisel hesaplardan ayrıcalık kaldırılır.
4. PAW veya atlama sunucusu: Tier 0 erişimi tek bir kontrollü yola indirilir.
5. Deny GPO’ları: Önce Tier 2’de Tier 0 hesapları reddedilir (en düşük kırılma riski), ardından Tier 1 sunucularda.
6. İzleme: Tier 0 hesaplarının Tier 0 dışı sistemlerdeki 4624 oturum olayları SIEM’de alarm üretir.

Sık görülen hatalar:

• Hizmet hesaplarını Domain Admins grubunda bırakmak; bu hesaplar Tier 1 sunucularda çalıştığı için modeli doğrudan deler.
• Yedekleme ve izleme sistemlerini Tier 1 sayıp DC’lere tam erişimle bırakmak.
• Tier 1 yöneticisini tüm sunucularda yerel Administrators grubuna eklemek; Tier 1 içinde de iş yüküne göre ayrım gerekir.
• Deny GPO’ları bittikten sonra istisna için yeni yetkili gruplar açmak ve bunları izlememek. İstisna, zamanla kuralın kendisi olur.

Modelin gerçekte nerede delindiğini görmek için yapılandırmaların birleşerek oluşturduğu ayrıcalık yollarına bakmak gerekir; yöntem AD saldırı yolu analizi yazısında. Ayrıcalıklı erişim tasarımı için ayrıcalıklı erişim yönetimi, mevcut yapının değerlendirilmesi için Active Directory güvenlik denetimi sayfalarına bakabilirsiniz.

Sık sorulan sorular

Küçük bir ortamda da tier modeli gerekli mi?

Kimlik bilgisi hırsızlığı ortamın büyüklüğüne bakmaz. Tam bir PAW altyapısı kurulamasa bile ayrı Tier 0 hesapları, Domain Admin hesaplarının iş istasyonlarında oturum açmasını engelleyen GPO ve ayrıcalıklı grupların temizlenmesi düşük maliyetle uygulanır ve riskin büyük kısmını kapatır.

Tier 0 hesapları neden Entra ID’ye senkronize edilmemeli?

Senkronize edilen bir Tier 0 hesabı bulut tarafında da saldırı yüzeyi olur; bulutta ele geçirilen bir kimlik veya parola sıfırlama akışı şirket içi Tier 0’a giden bir yol açabilir. Şirket içi ve bulut yönetici hesaplarını ayrı tutmak, iki ortam arasındaki ayrıcalık geçişini keser.

Deny log on GPO’ları uygulamaları kırar mı?

Doğru gruplara uygulandığında kırmaz. Ancak ayrıcalıklı gruplara üye hizmet hesapları varsa bu hesapların çalıştırdığı hizmetler başlamayabilir. Önce hizmet hesaplarının grup üyeliklerini temizleyin, GPO’yu pilot OU’da test edin, sonra kademeli yaygınlaştırın.

Enterprise access model tier modelinin yerini mi aldı?

Enterprise access model, tier modelini hibrit ve bulut ortamlarını kapsayacak şekilde genişletir. Şirket içi Active Directory için tier ayrımı ve oturum kısıtlamaları geçerliliğini korur; yeni model bu ayrımı control plane, management plane ve data/workload plane kavramlarıyla bulut kimliklerine ve uygulama erişimine taşır.