Active Directory Güvenlik Sıkılaştırması Rehberi

Active Directory güvenlik sıkılaştırması, saldırganın ele geçirdiği tek bir hesapla tüm domaine sıçramasını önleyen kademeli yetki, izole oturum ve sürekli izleme önlemlerinin bütünüdür. Amaç tek bir kapıyı kilitlemek değil; bir kapı kırılsa da saldırganın evin tümüne yayılamayacağı bir mimari kurmaktır.

Bir banka şubesini düşünün. Gişe memuru müşteriyle konuşur ama kasaya giremez; arka ofis günlük işlemleri yürütür ama şubenin ana kasa şifresini bilmez; kasa odasına ise sadece şube müdürü ve merkezden onaylı belirli kişiler girebilir. Her kademe bir öncekinden daha az kişiye, daha sıkı kontrolle açılır. Active Directory’de Tier 0, Tier 1 ve Tier 2 ayrımı tam olarak bu mantıkla çalışır ve bu rehber boyunca aynı şube benzetmesine geri döneceğiz.

Active Directory Rehberi ana hizmetinin “Active Directory Güvenliği” bölümünde Tier modeli, LAPS ve Fine-Grained Password Policy kavramları tanıtım seviyesinde ele alınmıştı. Bu makale aynı konuları sahada gerçekten uygulanabilir adımlara, somut PowerShell komutlarına ve sıkça yapılan hatalara indiriyor; ayrıca Active Directory Kullanıcı, Grup ve OU Yönetimi makalesinde değinilen servis hesabı yetki fazlalığı sorununa burada daha derinlemesine giriyoruz.

Tier Modelini Sahada Uygulamak: Hangi Hesap Nereye Oturum Açabilir?

Tier 0/1/2 Ayrımını GPO ile Zorunlu Kılmak

Tier modelini gerçek bir savunmaya çeviren şey yazılı kural değil, o kuralı teknik olarak imkansız kılan GPO ayarıdır. Şube müdürünün “kasa şifresini gişede kullanmayacağım” demesi yeterli değildir; gişe terminalinin zaten kasa şifresini kabul etmemesi gerekir. Active Directory’de bu karşılığı User Rights Assignment altındaki Deny log on locally ve Deny log on through Remote Desktop Services ayarları sağlar.

Pratikte şu şekilde kurarsınız: önce Tier 0 hesaplarının (Domain Admins, Enterprise Admins üyeleri) bulunduğu bir güvenlik grubu oluşturursunuz, ardından bu grubu Tier 1 ve Tier 2 OU’larına linklediğiniz bir GPO’da yukarıdaki iki “Deny” ayarına eklersiniz. Sonuç net: Domain Admin yetkili bir hesap artık bir sunucuda veya kullanıcı bilgisayarında fiziksel ya da RDP ile oturum açamaz; sadece Domain Controller’larda ve tanımlı Tier 0 yönetim makinelerinde çalışır.

Bu kurgunun sessiz ön koşulu, makinelerin gerçekten o Tier OU’larının içinde olmasıdır. Domain’e katılırken hedef OU belirtilmeyen bir sunucu varsayılan Computers konteynerine düşer ve konteynere GPO linklenemediği için buradaki Deny kuralları o makineye hiç ulaşmaz: model kağıt üzerinde kurulu, sahada boştadır. Nesnenin doğru OU’ya nasıl yerleştirileceğini bilgisayarı ve sunucuyu domain’e ekleme rehberinde ele alıyoruz.

Lab’da Tier 0 Grubu ve Deny Logon GPO’sunu Kurma: Adım Adım

Teoriyi tek bir somut örnekte uçtan uca görmek, parça parça okunan teoriden çok daha kalıcıdır. Gerçek lab domain’imizde (ad.sercebilisim.com) baştan sona ilerleyelim.

1. Tier 0 hesaplarını toplayan grup. Bu grup belirli bir lokasyona bağlı olmadığı için Active Directory Kullanıcı, Grup ve OU Yönetimi makalesinde tanımlanan Evrensel_Gruplar top-level OU’sunun altına açın. ADUC’ta bu OU’ya sağ tıklayıp New > Group’u seçin; grup adına USER_TIER0_YONETICILER yazın, Group scope’u Global, Group type’ı Security olarak ayarlayın.

Grubu oluşturduktan sonra Members sekmesinden günlük yönetimde kullandığınız gerçek Domain Admin hesaplarını ekleyin. Break-glass hesabını bu gruba bilerek eklemeyin; bu grup birazdan kuracağınız Deny Logon GPO’sunun hedefi olacak, break-glass hesabının ise tam tersine her yerden oturum açabilmesi gerekiyor.

2. GPO’yu oluşturma. GPMC’yi açın (gpmc.msc), sol panelde Group Policy Objects klasörüne sağ tıklayıp New’i seçin; isim olarak PC_TIER0_DENY_LOGON yazın. Bilerek hiçbir OU’ya henüz linklemeyin; önce ayarları yapıp sonra doğru yerlere bağlayacaksınız.

3. Deny Logon ayarlarını yapma. Yeni GPO’ya sağ tıklayıp Edit’i seçin; sırasıyla Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment yoluna gidin. “Deny log on locally“‘e çift tıklayıp Add User or Group ile USER_TIER0_YONETICILER’ı ekleyin; aynı işlemi “Deny log on through Remote Desktop Services” için de tekrarlayın.

4. GPO’yu doğru OU’lara linkleme. GPMC’de Sunucular OU’suna (Tier 1) sağ tıklayıp Link an Existing GPO’yu seçin, listeden PC_TIER0_DENY_LOGON’u bulup bağlayın. Aynı işlemi her lokasyonun Bilgisayarlar OU’su (Tier 2) için de tekrarlayın; örneğin Lokasyonlar/Genel_Mudurluk/Bilgisayarlar ve Lokasyonlar/Halkali/Bilgisayarlar.

5. Doğrulama. Bir Tier 0 hesabıyla, Sunucular veya bir lokasyonun Bilgisayarlar OU’sundaki bir makineye RDP ile bağlanmayı deneyin; “The sign-in method you’re trying to use isn’t allowed” benzeri bir hata almalısınız. İstemci tarafında gpresult /r çalıştırarak PC_TIER0_DENY_LOGON GPO’sunun gerçekten uygulandığını doğrulayın.

Jump Server ve PAW (Privileged Access Workstation) Mantığı

Kasa şifresi şube müdürünün cebinde her an taşınmaz; sadece kasa odasına girildiğinde kullanılır. Active Directory’de bu ilkenin karşılığı PAW (Privileged Access Workstation): Tier 0 kimlik bilgilerinin yalnızca üzerinde yazıldığı, internete çıkmayan, e-posta istemcisi ve ofis yazılımı barındırmayan ayrı bir yönetim makinesidir.

Yönetici günlük işini (e-posta, tarayıcı, ofis dosyaları) kendi normal bilgisayarında yapar; Domain Controller’a veya başka bir Tier 0 sistemine bağlanması gerektiğinde bir jump server üzerinden, sadece o jump server’dan gelen RDP bağlantılarına izin veren bir güvenlik duvarı kuralıyla geçer. Günlük kullanılan bilgisayar bir oltalama e-postasıyla ele geçirilse bile, üzerinde hiçbir zaman Tier 0 kimlik bilgisi yazılmadığı için saldırgan domaine sıçrayamaz.

Acil Durum (Break-Glass) Hesapları: Kendinizi Kilitleme Riskine Karşı Sigorta

Deny Logon GPO’sunun anlatılmayan tehlikesi, kuralı yazan yöneticinin kendisini de kilitleyebilmesidir. Şube müdürünün kartı bozulduğunda veya unutulduğunda merkez ofiste, mühürlü bir zarfta bekleyen yedek bir kasa anahtarı vardır; bu anahtar günlük işte hiç kullanılmaz, sadece gerçek bir tıkanmada açılır. Active Directory’de bu sigortanın adı break-glass (acil durum) hesabıdır.

Pratikte en az iki ayrı break-glass hesabı açılır ve Enterprise Admins ile Domain Admins’e üye yapılır; ikisinin de aynı anda devre dışı kalma ihtimali çok düşüktür. Bu hesaplar günlük yönetimde kullanılan Tier 0 hesaplarından kasıtlı olarak ayrı tutulur ve şu üç kuralla korunur:

• Deny Logon GPO’larından ve varsa Conditional Access/MFA zorunluluğundan istisna tutulur. Tam da bu hesaplara ihtiyaç duyulan anda, kendi koyduğunuz kısıtlama onları da kilitlerse sigortanın hiçbir değeri kalmaz.
• Parolası çok uzun ve rastgele üretilir, düzenli rotasyona bağlanmaz; fiziksel olarak güvenli bir yerde (kasada mühürlü zarf veya kurumsal bir parola kasasının ayrı, kısıtlı bir bölmesi) saklanır. Sık rotasyon burada güvenlik kazandırmaz, sadece parolanın unutulma riskini büyütür.
• Her oturum açışı anında alarm üretir. Bu hesap normal şartlarda hiç oturum açmamalıdır; bir oturum açma olayı görüldüğünde bu ya planlı bir test ya da gerçek bir acil durumdur, ikisi de anında doğrulanmalıdır.

Lab’da Break-Glass Hesabı Açma: ADUC Üzerinden Adım Adım

Bu hesabı PowerShell’le bir komutla da açabilirsiniz, ama ADUC (Active Directory Users and Computers) üzerinden adım adım gitmek, hangi alanın neden işaretlendiğini gözle de takip etmenizi sağlar. Hesabı, daha önce insan olmayan veya özel amaçlı hesapları topladığımız Servis_Kullanicilari OU’sunun altına açın; break-glass hesabı da günlük kullanılan bir kullanıcı değil, özel amaçlı bir hesaptır.

Çalıştır (Win+R) penceresinden dsa.msc ile ADUC’u açın, sol panelde Servis_Kullanicilari OU’sunu bulun. OU’ya sağ tıklayıp New > User’ı seçin; açılan sihirbazda First name ve Last name alanlarına sahada nötr bir ad (örneğin Backup / Service), User logon name alanına ise “admin” veya “breakglass” geçmeyen bir oturum açma adı (örneğin svc-bckup-ops) girin. Bu ad, hesabın gerçek amacını (Domain Admin break-glass hesabı olduğunu) değil, sıradan bir yedekleme servis hesabı görüntüsünü yansıtır.

Sihirbazın ikinci ekranında parolayı belirleyin. Burada iki kutucuk kritik: “User must change password at next logon” işaretini kaldırın (bu hesabın parolasını hiç kimse “ilk girişte değiştireceğim” diye unutmamalı) ve “Password never expires“‘ı işaretleyin; çünkü bu hesap için asıl risk parolanın sık değişmesi değil, acil bir anda kimsenin doğru parolayı hatırlamamasıdır. Parolanın kendisini uzun ve rastgele üretin, ekrana yazdığınız an fiziksel olarak güvenli bir yere not edin.

Hesabı oluşturduktan sonra Domain Admins grubuna üye yapın: Domain Admins grubunu açın, Members sekmesinde Add ile yeni hesabı ekleyin. Bu adımdan sonra break-glass hesabını, ilerleyen adımlarda kuracağınız Deny Logon GPO’sundan bilerek istisna tutacaksınız; aksi halde tam da gerektiği anda bu hesap da kilitli kalır.

LAPS ile Yerel Yönetici Parolasını Standart Dışına Çıkarmak

Her şubede aynı yedek anahtarın kullanılması, bir şubenin anahtarı çalındığında tüm şubelerin de açılabilmesi demektir. Sahada en sık görülen yapılandırma hatası tam olarak bu: tüm bilgisayarlarda aynı yerel Administrator parolasının kullanılmasıdır. Bir makine ele geçirildiğinde saldırgan aynı parolayla pass-the-hash tekniğiyle diğer tüm makinelere sıçrayabilir. Windows LAPS, her bilgisayar için ayrı ve rastgele bir parola üreterek bu riski ortadan kaldırır; kurulum ve yapılandırma adımları ayrı bir LAPS rehberinde ayrıntılı olarak ele alınacaktır.

Servis Hesapları İçin gMSA: Description Alanına Parola Yazmanın Alternatifi

Active Directory Kullanıcı, Grup ve OU Yönetimi makalesinde değinildiği gibi, servis hesabı parolasını AD’deki Description alanına not etmek sahada hâlâ sık görülen bir hata; bu alan varsayılan olarak Authenticated Users tarafından okunabilir. Asıl çözüm parolayı başka bir yere taşımak değil, parolayı insan eliyle hiç görmemek: gMSA (group Managed Service Account).

gMSA’nın 120 karakterlik parolasını hiçbir yönetici belirlemez ve göremez; Active Directory bu parolayı otomatik üretir, düzenli aralıklarla kendisi değiştirir, servisin çalıştığı sunucu da bu parolayı sormadan güvenli biçimde alır:

# gMSA oluştur ve hangi sunucuların kullanabileceğini belirt
New-ADServiceAccount -Name "GMSA_YEDEKLEME" -DNSHostName "yedekleme.ad.sercebilisim.com" -PrincipalsAllowedToRetrieveManagedPassword "YEDEKLEME-SUNUCU$"

# Hedef sunucuda gMSA'yı yükle
Install-ADServiceAccount -Identity "GMSA_YEDEKLEME"

# Sunucunun gMSA'yı gerçekten kullanabildiğini doğrula
Test-ADServiceAccount -Identity "GMSA_YEDEKLEME"

Fine-Grained Password Policy ile Hesap Bazlı Parola Kuralları

PSO (Password Settings Object) Nasıl Oluşturulur?

Bankanın tüm şubeleri aynı kasa şifre kuralını paylaşabilir, ama merkez kasanın şifre kuralı bir şube gişesinden çok daha sıkı olmalıdır. Default Domain Policy domaindeki her hesaba aynı parola kuralını dayatır; servis hesabı da CEO’nun hesabı da aynı kurala tabidir. Fine-Grained Password Policy (FGPP), ikinci bir domain kurmadan belirli bir gruba farklı ve genellikle daha sıkı bir kural tanımlamayı sağlar; bu kural bir PSO (Password Settings Object) nesnesiyle taşınır.

# Yöneticiler için daha sıkı bir PSO oluştur
New-ADFineGrainedPasswordPolicy -Name "PSO_Yoneticiler" `
    -Precedence 10 `
    -MinPasswordLength 16 `
    -PasswordHistoryCount 24 `
    -LockoutThreshold 3 `
    -ComplexityEnabled $true

# PSO'yu hedef güvenlik grubuna bağla
Add-ADFineGrainedPasswordPolicySubject -Identity "PSO_Yoneticiler" -Subjects "USER_GM_IT"

Precedence değeri, bir hesap birden fazla PSO’ya tabi olduğunda hangisinin kazanacağını belirler; düşük sayı her zaman önceliklidir. Bu sayede tek bir domainde “normal kullanıcı”, “yönetici” ve “servis hesabı” için üç farklı parola disiplini aynı anda yaşayabilir.

Hangi Gruplara Daha Sıkı Kural Uygulanmalı?

Her hesaba aynı sıkılıkta kural dayatmak pratik değildir; pratik olan, riskin yoğunlaştığı gruplara orantılı bir kural uygulamaktır. Sahada üç grup öncelik taşır: yönetici hesapları (uzun, sık değişen parola), servis hesapları (gMSA kullanılamıyorsa çok uzun ve nadiren değişen, çünkü insan eliyle giriliyor olması zaten risklidir) ve VPN ile dışarıdan erişen hesaplar (sıkı kilitleme eşiği, çünkü bunlar internetten doğrudan deneme saldırısına açıktır).

Active Directory Kullanıcı, Grup ve OU Yönetimi makalesinde önerilen Servis_Kullanicilari OU’su burada tam karşılığını bulur: o OU’daki hesapları temsil eden bir güvenlik grubu oluşturup PSO’yu doğrudan bu gruba bağlamak, gelecekte eklenecek her yeni servis hesabının otomatik olarak doğru kurala tabi olmasını sağlar.

Ayrıcalıklı Hesap ve Grup İzleme

AdminSDHolder ve SDProp: Yetki Sıçramasını Otomatik Sıfırlayan Mekanizma

Bankanın merkez denetimi, herhangi bir şubenin kasa erişim listesini habersizce değiştirip değiştirmediğini düzenli olarak kontrol eder ve yetkisiz bir ekleme bulursa onu sessizce siler. Active Directory’de bu denetimi SDProp süreci yapar: Domain Admins, Enterprise Admins gibi korunan gruplardaki hesapların ACL’i, PDC Emulator üzerinde varsayılan olarak her 60 dakikada bir AdminSDHolder nesnesindeki şablonla karşılaştırılır ve şablona uymayan her izin otomatik geri alınır.

Bu mekanizma çoğu yöneticiyi en az bir kez şaşırtır: bir Domain Admin hesabına doğrudan, özel bir izin eklenir, bir saat sonra o izin sebepsiz yere kaybolmuş gibi görünür. Sebepsiz değildir; SDProp görevini yapmıştır. Doğru çözüm bu hesaplara doğrudan izin eklemeye çalışmak değil, gerekiyorsa AdminSDHolder şablonunun kendisini, bilerek ve dikkatle düzenlemektir.

Kerberoasting ve AS-REP Roasting Belirtilerini Event Log’da Yakalamak

İki saldırı türü servis hesaplarını doğrudan hedef alır. Kerberoasting, SPN (Service Principal Name) tanımlı bir hesap için servis bileti (TGS) talep edip bu bileti çevrimdışı kırmaya çalışmaktır; saldırgan hiçbir kilitlenme tetiklemeden, sıradan bir kullanıcı yetkisiyle bu bileti isteyebilir. AS-REP Roasting ise “Do not require Kerberos preauthentication” ayarı açık bırakılmış hesapları hedefler; bu hesaplar için ön kimlik doğrulama adımı atlanabildiğinden bilet çok daha kolay elde edilir. İki saldırının da dayandığı bilet mantığını, SPN’in neden tek bir hesaba kayıtlı olması gerektiğini ve ön kimlik doğrulamanın akışta nereye oturduğunu Kerberos nedir rehberimizde paket düzeyinde ele alıyoruz.

Event Viewer’da takip edilecek iki imza var: Event ID 4769 (Kerberos servis bileti talebi) aynı hesap için kısa aralıklarla ve zayıf şifreleme türüyle (RC4, şifreleme türü 0x17) tekrarlanıyorsa Kerberoasting şüphesi taşır; Event ID 4768 (Kerberos kimlik doğrulama bileti) ön kimlik doğrulama olmadan (pre-authentication türü boş) geliyorsa AS-REP Roasting işaretidir. En etkili savunma tespitten önce gelir: servis hesaplarının parolasını gMSA ile insan eliyle asla belirlenmeyen, uzun ve rastgele bir değere taşımak, çalınan bileti kırılamaz hale getirir.

Dizin Katmanını Sıkılaştırmak: LDAP Signing ve Channel Binding

Sıkılaştırma tartışmaları genellikle hesaplar ve parolalar üzerinden yürür, ama dizinin kendisiyle konuşulan kanal da sıkılaştırılır. Varsayılan yapılandırmada bir Domain Controller, imzalanmamış ve şifrelenmemiş dizin bağlantılarını kabul etmeye devam eder; bu da araya giren birinin trafiği okumasına ya da değiştirmesine açık kapı bırakır.

İki ayar bu kapıyı kapatır. LDAP signing, istemci ile Domain Controller arasındaki dizin trafiğinin imzalanmasını zorunlu kılar; imza, mesajın yolda değiştirilmediğini garanti eder. Channel binding ise kimlik doğrulamayı üzerinde taşındığı TLS kanalına bağlar, böylece geçerli bir kimlik başka bir bağlantıya taşınarak kullanılamaz.

Bu ayarları zorunlu hale getirmeden önce ortamdaki eski istemcilerin ve dizine bağlanan üçüncü taraf uygulamaların taranması gerekir: imzasız bağlantı kuran bir uygulama, ayar zorunlu yapıldığı anda çalışmayı bırakır. Bu yüzden geçiş, önce denetim kaydı toplayıp sonra zorunluluğa geçme şeklinde iki aşamada yapılır.

Korumanın neden gerekli olduğunu somut görmek isterseniz, şifresiz bir dizin bağlantısında kullanıcı adı ve parolanın ağda nasıl açık metin olarak göründüğünü LDAP nedir rehberimizde paket düzeyinde yakalanmış gerçek trafikle gösteriyoruz.

Sahada En Sık Görülen Sıkılaştırma Hataları

Description Alanına Parola Yazmak

Bu hatanın gerçek boyutunu görmek için bir saldırgan olmaya gerek yok; sıradan, hiçbir özel yetkisi olmayan bir domain kullanıcısıyla tek satırlık bir PowerShell komutu yeterli:

Get-ADUser -Filter * -Properties Description | Where-Object { $_.Description -ne $null } | Select-Object Name, Description

Description alanı varsayılan olarak Authenticated Users tarafından okunabilir; yukarıdaki komut domaine kimliği doğrulanmış herhangi bir hesapla çalışır ve sonuçta “şifre”, “parola” veya doğrudan bir parola değeri içeren her açıklama satırı saniyeler içinde listelenir. Domain Admin yetkili bir servis hesabının parolası buraya yazılmışsa, bu tek komut domainin tamamının ele geçirilmesi için yeterli olabilir.

Servis Hesaplarına Gereksiz Domain Admin Yetkisi Vermek

“Çalışsın da kurtulayım” mantığı sahada en sık tekrarlanan kısayoldur: bir entegrasyon (Fortigate FSSO Collector Agent gibi tipik bir örnek) bağlanamadığında, doğru yetkiyi araştırmak yerine hesap doğrudan Domain Admin yapılır. Oysa FSSO Collector Agent’in gerçek ihtiyacı genellikle Event Log Readers ve Distributed COM Users üyeliğinden ibarettir; Domain Admin yetkisi sorunu “çözer” ama hesabı domainin en kritik tek noktası haline getirir.

Bunu bizzat yaşamadım ama bir arkadaşımın başına gelen bir olay konuyu fazlasıyla somutlaştırıyor: bir Linux sunucuda çalışan, gereğinden fazla yetkiyle tanımlanmış bir servis hesabı saldırganlar tarafından ele geçirilmişti. Saldırganlar bu hesabın erişimini uygulamanın kendi açığıyla birleştirip, belirli kullanıcı hesaplarına yetkisiz indirim kodları ve kuponlar üretecek şekilde kullandı. Sonuç doğrudan parasal kayba dönüştü. Hikaye Windows/AD dünyası dışında geçti ama ders aynı: servis hesabına “çalışsın da kurtulalım” diye gereğinden fazla yetki vermek, platform fark etmeksizin saldırgana aynı kapıyı açar.

Tam da Fortigate FSSO ve Azure AD servis hesaplarının parolasının Description alanına yazıldığı gerçek bir durumu, LAPS kurulumu ve tek nokta arızası riskini ortadan kaldıran yedek DC kurulumuyla birlikte Active Directory modernizasyon vaka çalışmasında anlatıyoruz.

SMBv1, NTLMv1 ve LLMNR’ı Kapatmamak

Üç eski protokol, sahada hâlâ “dokunmayalım, bir şey bozulur” korkusuyla açık bırakılıyor; oysa üçü de modern bir ortamda hem gereksiz hem tehlikeli. SMBv1’in neden bu kadar riskli olduğunu, kapatmadan önce hangi cihazların taranması gerektiğini ve sürümler arasındaki farkı SMB nedir rehberimizde ayrıntılı olarak ele alıyoruz.

Bu üçü de varsayılan olarak değil, uyumluluk için açık kalır; modern Windows sürümleriyle çalışan bir ortamda kapatılmaları işlevsel hiçbir kayba yol açmaz, sadece saldırı yüzeyini küçültür.

Sonuç: Sıkılaştırma Bir Proje Değil, Sürekli Bir Disiplindir

Active Directory sıkılaştırması tek seferlik bir kurulum adımı değil; her yeni servis hesabı, her yeni GPO ve her yeni entegrasyonla yeniden gözden geçirilmesi gereken sürekli bir disiplindir. Active Directory Rehberi ile genel mimariyi, Active Directory GPO Yönetimi ile politika dağıtımını, Active Directory Kullanıcı, Grup ve OU Yönetimi ile yetki devrini bu rehberle birlikte ele aldığınızda, kurumunuzun dijital omurgası hem yönetilebilir hem de saldırılara karşı dirençli hale gelir.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.