Rahatsız Edici Gerçek: Güvenilen Etki Alanları Arasında Güvenlik Sınırı Yoktur
Active Directory (AD) ortamlarını yönetirken en tehlikeli yanlış anlamalardan biri, etki alanları veya ormanlar arasında güven ilişkileri kurduğunuzda gerçek bir güvenlik sınırı olduğu yanılgısıdır. Bu yaygın mit, birçok kuruluşu yanlış bir güvenlik hissi içinde bırakıyor ve potansiyel olarak ciddi güvenlik ihlallerine zemin hazırlıyor.
Acı gerçek: Başka bir AD’ye güvendiğinizde, onların güvenlik sorunları doğrudan sizin sorunlarınız haline gelir.
Güvenlik İhlalleri Nasıl Yayılır?
Güven ilişkisi yönü ne olursa olsun (tek yönlü veya iki yönlü), tek bir güvenlik ihlali ortamlar arasında kolayca kademeli olarak yayılabilir. Saldırganlar şu yollarla güven ilişkilerini kötüye kullanabilir:
- Kimlik Bilgilerini Ele Geçirme: Güvenilen bir etki alanında ayrıcalıklı kimlik bilgilerini ele geçiren saldırgan, bu bilgileri kullanarak güvenen etki alanına kolayca sıçrayabilir.
- SID Geçişi: Doğru şekilde filtrelenmezse, Güvenlik Tanımlayıcıları (SID) güven ilişkisi üzerinden geçebilir, böylece saldırganlar bir etki alanındaki ayrıcalıkları diğerine aktarabilir.
- Kerberos Zafiyetleri: Zayıf Kerberos yapılandırması, saldırganların biletleri çalmasına veya sahte biletler oluşturmasına olanak tanıyabilir, böylece tüm güven yapısı boyunca erişim elde edebilirler.
- Şifreleme Zayıflıkları: Güvenler genellikle zayıf şifreleme protokollerini kullanır, bu da çeşitli saldırılara karşı savunmasız bırakır.
Gerçek Dünya ile Güvenliği Dengelemek
İdeal olarak, etki alanları arasında güven ilişkileri kurulmamalıdır. Ancak gerçek dünyada, iş ihtiyaçları genellikle güvenlik tavsiyelerini geçersiz kılar. Şirket birleşmeleri, devralmaları, ortak girişimler veya dağıtık BT ortamları, kaçınılmaz olarak AD güvenlerinin kurulmasını gerektirebilir.
Bu kaçınılmaz olduğunda, güveni mümkün olan en güvenli şekilde yapılandırmak hayati önem taşır.
Güvenler İçin Güvenlik En İyi Uygulamaları
Eğer AD güvenleri kullanmanız gerekiyorsa, bu güvenlik önlemlerini uygulayın:
1. Doğru Güven Türünü Seçin
Tüm güven türleri eşit yaratılmamıştır. Maruz kalma alanını en aza indirmek için:
- Orman Güvenleri: Yalnızca farklı ormanlar arasında paylaşım gerekiyorsa kullanın. Bu, en azından farklı şema ve yapılandırma yöneticilerine sahip iki ayrı AD ortamı sağlar.
- Harici Güvenler: Ormana özgü erişimi sınırlamak için tercih edin. Dış güvenler genellikle daha güvenlidir çünkü iki ormanın şemaları ayrı kalır.
- Kapsam Belirleme: Güveni mümkün olduğunca kısıtlayın – etki alanı genelinde değil, seçici veya orman genelinde güvenler kullanmayı düşünün.
2. Seçmeli Kimlik Doğrulamayı Etkinleştirin
Seçmeli kimlik doğrulama, güven ilişkisi genelinde kimlerin nerede kimlik doğrulaması yapabileceğini sınırlamanıza olanak tanır:
# Seçmeli kimlik doğrulamayı etkinleştirme
netdom trust TrustedDomain /d:TrustingDomain /SelectiveAuth:Yes
Bunu yaptıktan sonra, yalnızca özel olarak izin verilen kullanıcılar ve gruplar kaynaklara erişebilir. Bu, varsayılan “herkes erişebilir” modelini “kimse açıkça izin verilmediği sürece erişemez” modeline dönüştürür.
3. Kerberos AES Şifrelemesini Zorlayın
Eski RC4 şifreleme ve NTLM gibi daha zayıf kimlik doğrulama protokollerine güvenmek yerine, güven ilişkilerinde AES şifrelemesini zorlayın:
# AES şifrelemesini zorlama
Set-ADDomainTrust -Identity "TargetDomainName" -TrustDirection Bidirectional -TrustType External -AdvancedOptions:256
RC4’e geri dönüşü önlemek için, AD yapılandırmanızda daha zayıf şifreleme yöntemlerini devre dışı bırakmayı da düşünün.
4. SID Filtrelemeyi Denetleyin ve Etkinleştirin
SID filtreleme, güven sınırları boyunca SID geçişini önlemede kritik bir rol oynar. Ne yazık ki, bu genellikle geçiş süreçleri sırasında devre dışı bırakılır ve asla yeniden etkinleştirilmez:
# SID filtreleme durumunu kontrol etme
netdom trust TrustedDomain /d:TrustingDomain /quarantine:status
# SID filtrelemeyi etkinleştirme
netdom trust TrustedDomain /d:TrustingDomain /quarantine:yes
5. Güvenleri Düzenli Olarak Denetleyin
Mevcut güven ilişkilerinizi tanımak ve düzenli olarak denetlemek gerekmektedir. PowerShell, bu görevi basitleştirmenize yardımcı olabilir:
# Tüm güvenleri listeleme
Get-ADTrust -Filter *
# Alternatif komut
nltest /domain_trusts
# Güven özelliklerini görüntüleme
netdom trust YourDomain /domain:TrustedDomain /verify
Daha kapsamlı inceleme için, şeffaf bir PowerShell aracı olan ADProbe veya benzer güvenlik değerlendirme araçlarını düşünebilirsiniz.
Alt Etki Alanı Miti: Başka Bir Tehlikeli Yanlış Anlama
Güvenlerle ilgili bir diğer yaygın yanlış anlama da alt etki alanlarının bir güvenlik sınırı oluşturduğudur. Bu kesinlikle doğru değildir.
Alt etki alanına erişimi olan herhangi biri, yeterli ayrıcalıklarla, üst etki alanına ve nihayetinde tüm ormana sıçrayabilir. Örneğin, alt alan.ornek.com’daki yerel bir Yönetici, Enterprise Admin haklarını elde edebilir ve ornek.com’a – hatta tüm ormanınıza – tam erişim kazanabilir.
Etki alanlarını yönetimsel ayrım için kullanmak istiyorsanız, bunun yerine şunları düşünün:
- Organizasyon Birimleri (OU’lar): Yönetimsel delegasyon için çok daha iyi bir mekanizma sağlarlar
- Detaylı İzinler: Belirli OU’lar veya kaynaklara ayrıntılı izinler atayın
- Ayrı Ormanlar: Gerçek yönetim veya güvenlik ayrımı için ayrı ormanlar kullanın (her zaman güvensiz)
Sonuç: Sınırlarını Bilen Güvenlik
Active Directory güvenleri bazen gereklidir, ancak bunların ek güvenlik risklerini de beraberinde getirdiğini anlamak çok önemlidir. Etki alanları arasında geçirimsiz duvarlar olmadığını kabul ettiğinizde, güven ilişkilerinizi çok daha bilinçli ve güvenli bir şekilde yapılandırabilirsiniz.
En iyi yaklaşım:
- Mümkünse, AD güvenlerinden kaçının
- Kaçınılamıyorsa, mümkün olan en kısıtlayıcı yapılandırmayı uygulayın
- Güven ilişkilerini düzenli olarak gözden geçirin ve denetleyin
- Güven sınırları boyunca tüm etkinlikleri izleyin
- Güven ilişkileri üzerinden asla ayrıcalıklı hesaplara izin vermeyin
Güvenilen etki alanlarının güvenliğinin sizin güvenliğiniz kadar iyi olduğunu unutmayın. İş ortaklarınızın, satın alımlarınızın veya alt şirketlerinizin güvenlik standartları için gerçekten kefil olabilir misiniz?
Bu blog yazısı, yalnızca bilgilendirme amaçlıdır. Kuruluşunuzun Active Directory ortamında değişiklik yapmadan önce her zaman kapsamlı risk değerlendirmesi yapmanızı ve test etmenizi öneririz.
