Active Directory Güvenlik Serisi – Bölüm 7: Zero Trust Yaklaşımı
Active Directory (AD) güvenliğini güçlendirme serisinin bu bölümünde, Zero Trust yaklaşımının üç temel ilkesinden biri olan en az yetki (least privilege) kavramı ele alınıyor. “Açıkça doğrula, en az yetkiyi ver, ihlal varsayımıyla hareket et” prensipleri arasında, native Active Directory yetenekleriyle en uygulanabilir olanı en az yetki ilkesidir.
Aslında bu kavram, Windows domain’lerden çok daha önce de biliniyordu. Bazı organizasyonlar en başından itibaren yönetici yetkilerini minimumda tutmayı başarmış olsa da, ne yazık ki bunlar istisna olarak kaldı. Günümüzde yetki verme konusunda daha disiplinliyiz; ancak çoğu Active Directory ortamında, yıllar boyunca birikmiş ve artık gerekçesi kalmamış delegasyonlar hala duruyor. Bu makale, AD güvenlik değerlendirmelerinde yetkilerin nasıl azaltılması gerektiğini sistematik olarak ele alıyor.
Neden Ayrıcalıklı Hesaplara Bu Kadar Odaklanıyoruz?
Saldırı teknikleri zamanla değişebilir; kullanılan exploit’ler, zafiyetler ve ilk erişim yöntemleri farklılaşabilir. Ancak saldırganların değişmeyen tek hedefi vardır: kimlik bilgileri.
Saldırgan faydalı bir kimlik bilgisi ele geçirdiğinde, geri kalan tüm saldırı zinciri neredeyse otomatik olarak ilerler. Bu nedenle hedef;
- Ayrıcalıklı hesap sayısını azaltmak
- Bu hesapların nerelerde kullanılabileceğini sınırlamak (Tier modeli)
- Ayrıcalıklı işlemler için özel yönetim iş istasyonları (PAW) kullanmak
- Protokol ve kimlik doğrulama sertleştirmelerini uygulamak
olmalıdır. Bu yaklaşım, saldırganın oyun planını erken aşamada bozar.
Servis Hesapları: En Yaygın Aşırı Yetkilendirme Alanı
Aşırı yetkilendirilmiş servis hesapları, Active Directory ortamlarında en sık rastlanan güvenlik sorunlarından biridir. Özellikle geçmişte oluşturulmuş servis hesaplarının bir kısmı, hala Domain Admins gibi yüksek yetkili gruplarda yer alabiliyor. Bu durum çoğu zaman “kolaylık” veya uygulamanın gerçek gereksinimlerinin net bilinmemesinden kaynaklandı.
Bir uygulama canlıya alındıktan sonra servis hesabının yetkilerini küçültmek zor olsa da, bu adım mutlaka atılmalıdır. İyi haber şu ki; en az yetki ilkesinden taviz vermeyen kurumlar, yama yönetimi, zafiyet taraması ve Active Directory yedekleme gibi işlemleri Domain Admin yetkisi olmadan da başarıyla yapabiliyor.
Özellikle Service Principal Name (SPN) tanımlı servis hesapları öncelikli ele alınmalıdır. Bu hesaplar Kerberoasting saldırılarına açıktır. Yetkisi düşürülemeyen servis hesapları için AES desteği etkinleştirilmeli ve güçlü, rastgele parolalar kullanılmalıdır.
Uç Noktalarda Local Administrator Yetkisi
Eskiden local admin yetkileri daha çok kullanıcıların sistemi “bozmaması” için kısıtlanırdı. Bugün ise asıl motivasyon güvenliktir. Local admin olmayan bir kullanıcı, kötü amaçlı yazılım yüklemekte veya LSASS belleğinden kimlik bilgisi almakta ciddi şekilde zorlanır.
Her ne kadar bu konuda ilerleme kaydedilmiş olsa da, geliştiriciler ve sistem yöneticileri gibi bazı kullanıcılar için hâlâ istisnalar tanınabiliyor. Ancak bu istisnaların gerçekten gerekli mi yoksa sadece konfor amaçlı mı olduğu mutlaka sorgulanmalıdır.
Yanlış verilen local admin yetkilerinin etkisi genellikle sınırlı kalmaz. Bir geliştiricinin veya help desk kullanıcısının hesabı ele geçirildiğinde, bu durum üretim sistemlerine veya tüm uç noktalara yayılabilecek ciddi sonuçlar doğurabilir. Buradaki temel kavram blast radius yani etki alanıdır.
User Rights Assignment (URA) Ayarları
Domain Controller’lar üzerindeki User Rights Assignment ayarları, yıllar içinde genellikle şişer. Varsayılan Domain Controllers Policy incelendiğinde, artık var olmayan hesaplara veya gerekçesi açıklanamayan yetkilere sıkça rastlanır.
Microsoft’un Windows Server 2022 güvenlik temel ayarları (Security Baseline), Domain Controller’lar için bu konuda net bir referans sunar. Bu karşılaştırma yalnızca DC’lerle sınırlı kalmamalı; domain’e üye tüm sistemler için yapılmalıdır.
Group Policy Delegasyonları ve GPO Güvenliği
Saldırganlar ayrıcalıklı kimlik bilgilerini ele geçirdiklerinde, genellikle yerleşik araçları kullanır. Mevcut GPO’ların manipüle edilmesi buna iyi bir örnektir. Bu risk, GPO yönetim yetkilerinin farklı destek gruplarına dağıtılmasıyla daha da artar.
Özellikle Group Policy Creator Owners grubunun kullanımı ciddi risk taşır. Bu gruptaki kullanıcılar oluşturdukları GPO’lar üzerinde tam yetkiye sahip olur. Bu da saldırganlara zararlı payload dağıtmak için ideal bir zemin hazırlar. Bu nedenle bu grubun boş bırakılması ve merkezi GPO yönetim süreçlerinin benimsenmesi önerilir.
Organizational Unit (OU) Delegasyonları
OU bazlı delegasyonlar da zamanla kontrolsüz şekilde birikir. Parola sıfırlama, kullanıcı ve grup oluşturma, GPO linkleme veya dizin replikasyon yetkileri gibi izinler, yanlış ellere geçtiğinde saldırganlar için büyük avantaj sağlar.
Active Directory’nin kendi delegasyon sihirbazı, yetki vermeyi kolaylaştırsa da; verilen yetkileri analiz etmeyi veya geri almayı kolaylaştırmaz. Bu nedenle delegasyonların düzenli olarak gözden geçirilmesi ve gereksiz yetkilerin temizlenmesi kritik öneme sahiptir.
Ayrıcalıklı Grupların Yönetimi
En az yetki ilkesinin temel taşlarından biri, ayrıcalıklı grupların üyeliklerini minimize etmektir. Bu konu bazen kişisel algılansa da, mesele insanlara güvenmemek değil; cihazlara güvenmemektir.
Burada servis yönetimi ile veri yönetimi arasındaki farkın iyi anlaşılması gerekir. Domain controller yönetimi gibi işlemler yerleşik ayrıcalıklı gruplar gerektirirken; kullanıcı, grup ve GPO yönetimi gibi işlemler daha granular delegasyonlarla yapılabilir.
Domain Admins, Enterprise Admins, Schema Admins gibi gruplar başta olmak üzere Tier 0 kapsamındaki tüm gruplar için üyelikler azaltılmalı, izlenmeli ve gerekçelendirilmelidir. Ayrıca, DCSync gibi saldırılara zemin hazırlayabilecek eşdeğer yetkilere sahip diğer gruplar da aynı titizlikle ele alınmalıdır.
| Group Name | Recommendation |
| Account Operators | Account Operators group does not map well to how organizations operate. More appropriate delegations can be implemented to more granularly control the management of objects. As a result, the recommendation is to leave this group empty. |
| Administrators | Given Administrators grants full control to the Domain Controller’s OS, membership should be limited to accounts responsible for operational support of directory services. Due to nesting, there is no need for members of Domain Admins to also be direct members of Administrators. |
| Backup Operators | To minimize privilege, leave Backup Operators empty and create a special purpose service account that has the URAs of Backup up files and directory and Restore files and directories. |
| Domain Admins | Membership should be limited to resources responsible for operational support of domain controllers. |
| Enterprise Admin | In multi domain forests this group is nested in the Administrators group of every domain. When a centralized team is responsible for all domains, this group is often used to minimize the number of accounts an Active Directory administrator would need to possess. However, it is important to consider the blast radius if such an account was compromised. |
| Group Policy Creator Owners | As previously mentioned, this group allows members to create new GPOs for which they will have full control. Given that will result in decentralized management of GPOs, it is recommended to leave this group empty and pursue other solutions to minimize accounts that can manage group policies. |
| Print Operators | Domain Controllers should never host print queues or have the print spooler service enabled. In addition to having no members, print operators should have the URAs Load and unload devices drivers and Allow log on locally removed from the Default Domain Controller policy. |
| Remote Desktop Users | Remote desktop privileges should be limited to accounts used to perform service administration of Active Directory. Additionally, network connectivity to the RDP service (3389) on domain controllers should be restricted using firewall rules or IPsec. |
| Schema Admins | Schema modification is a very rare event. This group should remain empty and only populated when actively extending the schema. |
| Server Operators | Members of this group can perform junior admin tasks on domain controllers including start and stop service, manage network shares and manage backups. This group does not align with how Active Directory service administration is performed today. As a result it should remain empty and the URAs Allow logon locally, Back up files and directories, Change the system time, Force shutdown from a remote system, Restore files and directories and Shut down the system should be removed from it in the Default Domain Controllers policy. |
| Group Name | Recommendation |
| Incoming Forest Trust Builders Group | Members of the Incoming Forest Trust Builders group can create incoming, one-way trusts to this domain. By default, this group has no members. |
| Key Admins Group | This group is granted write access to msDS-KeyCredentialLink attribute of user and computer objects in a domain which is used to store public keys related to Passwordless authentication such as Windows Hello for Business. The group should be limited to accounts that administer WHFB keys and similar Passwordless key pair credentials |
| Enterprise Key Admins Group | This group is the same as Key Admins except the scope is the forest instead of just a domain. |
| Network Configuration Operators Group | This domain group grants the ability to manage TCP/IP and other network configuration settings on domain controllers. It could be used to enable a AiTM attack by manipulating name resolution and IP routing. |
| Read-only Domain Controllers Group | This group should only contain actual RODCs assuming you must have RODCs. Additionally, some third-party products are designed to be in the group in or order to emulate a RODC. The security risks introduced by such solutions should be fully evaluated. |
| Replicator Group | This is a legacy group that previously was used for Sysvol replication. By default, it has no members and should remain empty. |
| Storage Replica Administrators Group | This group can manage storage replicas on domain controllers. By default, this group has no members and should remain empty. |
| System Managed Accounts Group | This is a new group introduced with Server 2016. By default, the only member is the default account. This group should not have its membership manually modified. |
| Certificate Service DCOM Access Group | Members of this group can connect to certification authorities in the enterprise and by default is empty. Typically, only PKI administrators need to be added as members of this group. |
| Allowed RODC Password Replication Group | Members in this group can have their passwords replicated to all read-only domain controllers in the domain. Privileged accounts should not be members. |
| Cert Publishers Group | Members of this group are permitted to publish certificates to the directory. Membership should be limited to the accounts intended to be used for publishing certificates such as PKI administrators. Additionally, the computer accounts of the Enterprise CAs need to be in this group. |
| Cloneable Domain Controllers Group | Membership of this group should be limited to domain controllers you wish to clone. |
| Cryptographic Operators Group | Members are authorized to perform cryptographic operations. Membership should be limited to accounts that require this right for Certificate Services administration |
| Distributed COM Users Group | Members are allowed to launch, activate and use Distributed COM objects on domain controllers. |
| DnsUpdateProxy Group | This group is intended to be used by DHCP servers which are registering DNS records on behalf of DHCP clients. The group should only include those DHCP servers. |
| DnsAdmins Group | Group used to delegate management of DNS zones. This group was not introduced until Server 2003. Prior to then it was common to add an account to Domain Admins in order to manage DNS (e.g. Infrastructure team). Zones created before Windows 2003 need to have the ACLs updated to delegate access to this group. |
| Domain Controllers Group | This group has the extended right Replicating Directory Changes All. Members can replicate account passwords using that permission. Membership should be limited to domain controllers. |
| Enterprise Read-only Domain Controllers Group | This group has the extended right Replicating Directory Changes and should be limited to RODCs. Given RODCs are not without risks careful consideration should be given before deploying RODCs. |
Kerberos Delegation ve Yetki Sınırlandırması
Kerberos Delegation, bir servisin başka bir kullanıcı adına Kerberos ticket alabilmesini sağlar. Bu yapı doğru kurgulandığında Single Sign-On deneyimi sunar; ancak web sunucularının ele geçirilmesi durumunda ciddi risk oluşturur.
Bu nedenle unconstrained delegation yerine constrained delegation veya daha modern olan resource-based constrained delegation (RBCD) tercih edilmelidir. Ayrıca, Active Directory yönetimi için kullanılan ayrıcalıklı hesaplar genellikle delegation gerektirmediğinden, bu hesaplar için “delegation yapılamaz” olarak işaretlenmesi en az yetki yaklaşımını güçlendirir.
Exchange Yetkileri ve Active Directory
Exchange’in ilk sürümlerinde, Active Directory ile paylaşımlı yetki modeli kaçınılmazdı. Ancak zamanla Exchange ve AD yönetimi farklı ekiplerin sorumluluğuna geçti. Bu da split permissions yaklaşımını doğurdu.
On-prem Exchange kullanmaya devam eden kurumların, mümkünse AD split permissions modelini uygulaması önerilir. Exchange Online’a tamamen geçilmiş ortamlarda ise, yeni Exchange Management Tools sayesinde on-prem Exchange sunucularına artık ihtiyaç kalmamıştır. Bu durumda Exchange’e ait AD yetkilerinin temizlenmesi mümkündür.
Eğer bu yetkiler kaldırılamıyorsa, Exchange sunucuları ve Exchange yöneticileri Tier 0 olarak değerlendirilmelidir.
Credential Vaulting: Tek Başına Yeterli mi?
Credential vault çözümleri önemli bir güvenlik katmanı sunsa da, hesabın nerede ve nasıl kullanıldığı hala kritik önemdedir. Ayrıcalıklı bir hesabın, daha düşük güvenlik seviyesine sahip bir sunucuda kullanılması, tüm korumayı anlamsız hale getirebilir.
Buradan çıkarılacak ders nettir:
- Tier 0 hesaplar Tier 1 veya Tier 2 sistemlerde kullanılmamalıdır
- MFA, hash pass saldırılarını tek başına engellemez
- Protected Users gibi ek korumalar devreye alınmalıdır
User Account Control (UAC)
Microsoft baselines recommend the following UAC setting be implemented on domain controller.
| Setting name | Domain Controller Recommendation (Server 2022 baseline) | Default Setting |
| Admin Approval Mode for the Built-in Administrator account | Enabled | Not defined |
| Allow UIAccess applications to prompt for elevation without using the secure desktop | Disabled | |
| Behavior of the elevation prompt for administrators in Admin Approval Mode | Prompt for consent on the secure desktop | Prompt for consent for non-Windows binaries (default) |
| Behavior of the elevation prompt for standard users | Automatically deny elevation requests | Prompt for credentials |
| Detect application installations and prompt for elevation | Enabled | Enabled |
| Only elevate executables that are signed and validated | Disabled | |
| Only elevate UIAccess applications that are installed in secure locations | Enabled | Enabled |
| Run all administrators in Admin Approval Mode | Enabled | Enabled |
| Switch to the secure desktop when prompting for elevation | Enabled | |
| Virtualize File And Registry Write Failures To Per User Locations | Enabled | Enabled |
User Account Control, ayrıcalıklı işlemlerin otomatik olarak yüksek yetkiyle çalışmasını engelleyen bir savunma katmanıdır. Yönetici hesaplar, düşük yetkili token ile başlar ve yalnızca onayla yükselir.
Microsoft’un güncel güvenlik temel ayarları, Domain Controller’lar üzerinde UAC’nin sıkı şekilde yapılandırılmasını önermektedir. Bu ayarlar, kimlik bilgisi hijyeninin yerine geçmez; ancak saldırı yüzeyini daraltır.
Active Directory ortamlarında aşırı yetkileri azaltmak, tek seferlik bir proje değil; sürekli bir süreçtir. Bu süreçte:
- Ortamınızı derinlemesine tarayacak araçlardan faydalanın
- Tespit ettiğiniz sorunları ertelemeyin, izole ortamlarda test ederek düzeltin
- Yaptığınız tüm değişiklikleri mutlaka dokümante edin
- Ayrıcalıklı erişimleri proaktif olarak izleyin
- Microsoft’un yayınladığı güvenli ayrıcalıklı erişim rehberlerini düzenli olarak gözden geçirin
En az yetki ilkesi doğru uygulandığında, Active Directory yalnızca daha güvenli değil, aynı zamanda daha yönetilebilir hale gelir.
Eline sağlık.