Güncelleme (Ekim 2026): Bu rehber ilk olarak Exchange Server 2019 dönemindeki Client Access Rules (CAR) özelliğini uygulamalı olarak anlatmak için hazırlanmıştır. Exchange Server 2019, 14 Ekim 2025 itibarıyla destek dışıdır. Client Access Rules, Exchange Server Subscription Edition (SE) için Microsoft belgelerinde yer almaya devam eder; Exchange Online tarafında ise Eylül 2025 itibarıyla tamamen kullanımdan kaldırılmıştır. Aşağıdaki 2018 tarihli ekran görüntüleri tarihsel laboratuvar çalışmasına aittir.
Önemli güvenlik notu: Özellikle Remote PowerShell ve EAC erişimini engelleyen kuralları üretimde uygulamadan önce yönetim IP adreslerini, ara katman servisleri ve acil durum erişimini planlayın. Örnek IP aralıklarını kendi ortamınıza göre doğrulayın; mevcut yönetim oturumunuzu yanlış bir kuralla kesebilirsiniz.
Client Access Rules (CAR) nedir?
Exchange Server ortamında EAC ve Remote PowerShell erişim taleplerini; istemci IP adresi, protokol, kimlik doğrulama yöntemi ve kullanıcı özellikleri gibi koşullarla değerlendiren erişim denetim kurallarıdır. Mail flow/transport rule ile aynı şey değildir; yönetim erişimine ilişkin farklı bir güvenlik katmanıdır.
Exchange 2019, Exchange SE ve Exchange Online arasındaki fark
Exchange Server 2019: Özellik mevcuttur; ancak ürünün destek ömrü sona ermiştir. Exchange Server SE: Microsoft bu özellik için yönetim ve kullanım belgelerini yayımlamaktadır. Exchange Online: Client Access Rules kaldırılmıştır; eski komut örnekleri bulut ortamı için güncel bir çözüm olarak kullanılmamalıdır. Bulut erişim politikalarında Microsoft Entra Conditional Access gibi güncel mekanizmalar değerlendirilmelidir.
Kural mantığı: Conditions, Exceptions, Action ve Priority
Koşul ve istisnalar birlikte değerlendirildiğinde eşleşen ilk kural işlemi belirler. Daha küçük Priority sayısı daha yüksek öncelik anlamına gelir. Bu nedenle engelleme kurallarından önce gerekli yönetim erişimine izin veren kuralı tasarlamak kritik önemdedir.
Exchange Management Shell ile güvenli başlangıç kontrolleri
Bu sorgular ortamı değiştirmez. Öncelikle mevcut kuralları inceleyin. Yeni kural oluşturma veya var olanı değiştirme işlemlerini yetkili bakım penceresinde planlayın.
Özgün laboratuvar anlatımı ve ekran görüntüleri (2018)
Aşağıdaki bölüm, yayımlandığı dönemdeki uygulamalı senaryoyu ve tüm özgün ekran görüntülerini muhafaza eder. Komutların sözdizimi ve bazı tarihsel örnek IP açıklamaları güncel ortamlara doğrudan kopyalanmamalıdır.
Exchange Server 2019 duyurulması ile beraber bizlerde hızlı bir şekilde yeni özelliklerini sizler ile paylaşmaya başladık. Aslında geçen hafta yeni özelliklerinin nerede ise tamamına yakınını aşağıdaki makalede
sizler ile paylaştım
Ancak burada özellikle bazı teknolojiler için ayrı makaleler yazacağımı da belirtmiştim. Client Access Rule özelliği de bu teknolojilerden birisi.
Peki daha önce kullanmadığımız ve Exchange 2019 ile beraber gelen bu yeni özellik nedir?
Client Access Rule, temel olarak Exchange 2019 organizasyonunuzu yönetmek için kullandığınız Exchange admin center (EAC) ve remote PowerShell erişimlerini sınırlandırmak için kullanılır. Hub transport
kurallarına benzeyen bu kurallar sayesinde EAC ve remote PowerShell için IP temelli, kimlik doğrulama türüne ve kullanıcı özelliklerine bağlı olarak Exchange ‘e kimlerin bağlanacağına siz karar verebilirsiniz.
Peki bu ihtiyaç nereden doğdu? Aslında Exchange 2013 ile beraber web ve powershell temelli yönetim alışkanlıkları arttıkça bu uzak erişim protokolleri için özellikle şirket dışından veya şirket içerisinden
sıklıkla erişim talepleri arttı. Ancak şirket içerisinden olsun şirket dışında olsun bu tarz erişimler son derece büyük riskleri beraberinde getirmekteydi. Exchange sunucusuna RDP yapamayan kötü niyetli bir kişi şirket içerisinden veya dışından bu tarz uzak yönetim araçları sayesinde tüm mail sistemini ele geçire bilmekteydi. Tabiki banka, Telekom, gsm gibi büyük kurumlar Exchange Server
önünde konumlandırdıkları WAF veya benzeri güvelik cihazları ile aslında (bazen de IIS ile) bu tarz istekler için IP bazlı temel bir sınırlandırma getirerek koruma sağlayabiliyordu.
Ancak müşterilerden gelen yoğun istek üzerine bu tarz ek bir koruma veya önlem olmadan Exchange server’ ın kendi kendini koruması için tasarlanmış olan Client Access Rule ortaya çıkmıştır.
Peki örnek kurallara ve nasıl kural yazılacağına geçmeden önce Client Access Rule için temel bileşenler nelerdir onları görelim
Conditions- Koşullar
Kuralların en temel bileşeni olup Kimlik doğrulama tipi, IP adresi, kullanılan protokol, kapsam, kullanıcı ismi, kullanıcı filtresi gibi hangi koşulda kuralın çalışacağını tanımladığımız bölümdür.
Exceptions – Harici Durumlar
Tanımlanmış bir koşul için harici bırakılacak veya başka bir deyişle bu kuraldan etkilenmeyecek durumları tanımladığımız bölümdür.
Action – Aksiyon – Karar
En basit bölüm olup koşullara veya harici durumlara gelen bir isteği uyup uymamasına göre izin veya yasaklamaların yapılacağına karar verdiğimiz bölümdür.
Priority – Öncelik
Her kural dizesinde olduğu gibi burada da önceliklendirme söz konusu olup en düşük numaralı kural en baskın – öncelikli kuraldır.
Bu kısım önemli çünkü çakışma durumlarında kuralların nasıl çalışacağını iyi bilmemiz gerekiyor.
Örneğin birden çok kuralda aynı koşul sağlanır ise ilk kural uygulanır, diğer kurallar görmezden gelinir. Örneğin en yüksek öncelikli bir PS yasak kuralı olsun ve buna karşın siz bir de daha düşük öncelikli bir
remote powershell izin kuralını belirli bir ip ye veren bir kural yazmış olun, bu durumda ikinci yazdığınız kuralın hiçbir etkisi olmaz, yani ilgili ip den gelse bile istek ilk kuraldan dolayı bloklanır. Çözüm ise ilk kurala ek bir kural yazmaktansa ilk kurala ilgili ip için exception yani bir istisna eklemeniz doğru çözüm olacaktır.
Ya da başka bir senaryo düşünelim, bir kural içerisinde birden çok durum söz konusu olsun, yani EAC yasaklanacak ancak finans departmanındaki bir kullanıcı için. Böyle bir kuralın çalışması için gelen
isteğin kural içerisindeki “tüm” durumları sağlaması şarttır. Bir nevi OR değil AND olarak çalışır.
Bir kural içerisindeki bir durum için birden çok değer atanması durumunda OR yani hangisi uyuyor ise kural etkili olur. Örneğin ilgili kuralda bir ip için EAC veya Remote PowerShell demeniz halinde ikisinden biri
için action davranışı geçerli olacaktır.
Son olarak bir kural içerisinde bir den çok exception tanımlanmış ise yine firewall mantığındaki OR şeklinde çalışır, yani ip adres veya protocol olarak basic authentication seçmeniz halinde ikisinden hangisi
eşleşir ise action bu istek için uygulanmaz (exception olduğu için)
Yukarıdaki durumlar biraz gözünüzü korkutmuş olabilir ama emin olun kural yazmaya başlayınca son derece kolay olduğunu göreceksiniz. Hele ki Microsoft bize burada test için çok güzel bir komut seti hediye
etmişken;
Arşiv komut örneği (eski laboratuvar): komutu doğrudan çalıştırmadan önce kullanıcınızı, IP adresini, portu ve etkin kimlik doğrulama yöntemini doğrulayın.
Örnek komut aşağıdaki gibidir;
Arşiv komut örneği (eski laboratuvar): komutu doğrudan çalıştırmadan önce kullanıcınızı, IP adresini, portu ve etkin kimlik doğrulama yöntemini doğrulayın.
Aslında son derece basit bir mantık ile çalışıyor, pek çok firewall, smtp gateway veya benzeri cihazlardaki en temel kural mantığı ile durumu ve istisnaları seçiyorsunuz, bu durumun gerçekleşmesi durumunda ise ne
yapacağınızı seçiyorsunuz, hepsi bu!
Peki Client Access Rule yönetimini nasıl yapıyoruz?
Power Shell üzerinden yönetildiği için öncelikle mutlaka sunucu local erişiminizin olduğuna emin olun, çünkü olası bir hatalı kural tanımlamasından sonra uzak sunucu erişiminiz kesileceği için bu hatayı
düzeltme şansınız olmayacaktır.
Bu nedenle önerim sunucu üzerinde çalışmanız yönünde olacaktır. Ancak bu önerim core sürümleri için geçerli değildir, çünkü core sürümü bir Windows OS üzerine Exchange server kurmuş iseniz ki bunu tavsiye
ediyorum bu senaryo için ise ilk önerim aşağıdaki gibi en temel uzak erişim kuralını yazmanız olacaktır.
Unutmayın öncelik çok önemli ve bunun çakışma durumlarını da sizlerle paylaşıyor olacağım.
Peki gelelim kullanım senaryolarına.
Öncelikle mevcut durumda herhangi bir CAR var mı kontrol edelim;
Get-ClientAccessRule
Herhangi bir CAR olmadığını görüyoruz.
Eğer herhangi bir rule var ise detaylarını görmek için aşağıdaki gibi bir komut seti çalıştırabiliriz.
Peki ilk kuralımızı nasıl oluşturabiliriz;
Not: Exchange Server performans kaygılarından dolayı bu özelliği pek çok diğer özelliğinde olduğu gibi cache mantığı ile yönetir, bu nedenle ilk kuralı yazdıktan sonra aktif olarak gerçekleşmesi 24 saat alabilir.
Ek olarak bir kuraldaki değişiklik te en az 1 saat almaktadır. Bu nedenle kuralları yazdıktan hemen sonra etkisini göremezsiniz.
-ExceptUsernameMatchesAnyOfPatterns *hakan*
Not: Preview sürümünde çalıştırırsanız yukarıdaki ExceptUsername parametresi tanımsızdır.
Bu sefer Exchange Admin Center yasaklaması yapıyoruz, ancak yine harici durumlar söz konusu. Harici durumlara baktığımız zaman ip ve kullanıcı ismi için bir örnek görüyoruz. Ip adresi yine bir önceki örnekte
kullandığım gibi admin olan kullanıcının makinesi veya yönetim makinesi ip adresi, artı bu ip adresinin yanında ismi içerisinde hakan geçen kullanıcılar da bu kuraldan etkilenmeyecektir.
Peki istemci erişim kuralları için nasıl tanımlama yapacağımızı öğrendik. Şimdi sıra mevcut kurallar için nasıl değişiklik yapacağımızda.
Örnek ben biraz önce eklediğim kuralı pasif duruma çekiyorum.
Mevcut bir kuralı aktif iken pasif konumuna çekiyoruz.
Yukarıdaki gibi bir yazım mevcut değerleri değiştirmektedir, yani aktif olan kural pasif oldu, ancak bazen kural içerisinde değişiklik yaparken mevcut bazı değerleri değiştirmeden ekleme yapmak isteriz, böyle durumlar için aşağıdaki gibi bir yazım dili kullanmamız gereklidir.
@{Add=”<Value1>”,”<Value2>”…; Remove=”<Value1>”,”<Value2>”…}
Örnek yazım aşağıdaki gibidir;
Bu yazıma göre var olan Allow EAC kuralına exception olarak var olan ip yi silmeden ek olarak 172.17.17.27 nolu ip yi de eklemiş olduk.
Benzer şekilde kurallar için öncelikte değiştirme imkanına sahibiz.
Block PowerShell kuralı hatırlarsanız benim ilk oluşturduğum kuraldı, sonra ikinci bir kural oluşturmuştum, şimdi önceliği 1 olan “Block PowerShell” kuralını 2 yaptım, peki 2 olan kurala acaba ne oldu bir
bakalım.
Peki şimdi bir kural daha oluşturalım;
En sondaki kural yani 3 nolu kural 1 nolu kural olunca, 1 nolu kural 2, 2 nolu kural ise otomatik olarak 3 nolu kural oldu.
Yazdığımız bir kuralı değiştirmek değil de silmek istersek;
Veya test etmek istersek ki bunu paylaşmıştım;
Arşiv komut örneği (eski laboratuvar): komutu doğrudan çalıştırmadan önce kullanıcınızı, IP adresini, portu ve etkin kimlik doğrulama yöntemini doğrulayın.
Örnek bir yazım aşağıdaki gibidir
Arşiv komut örneği (eski laboratuvar): komutu doğrudan çalıştırmadan önce kullanıcınızı, IP adresini, portu ve etkin kimlik doğrulama yöntemini doğrulayın.
Sonuç aşağıdaki gibidir
Gördüğünüz gibi Restrict EAC Access kuralı nedeni ile “DenyAccess” sonucunun alıyoruz. Bu sorun çözmek için çok güzel bir komut setidir.
Bu kadar çok komut seti yazdıktan sonra insan ister istemez parametreleri merak ediyor, yani ben hangi durum tanımlamalarını yaparım derseniz kullanabileceğiniz parametreler aşağıdaki gibidir;
Evet umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.
Kaynak
https://docs.microsoft.com/en-us/exchange/clients/client-access-rules/client-access-rules?view=exchserver-2019
2019 yayınındaki alternatif ekran görüntüleri
2019 yılında yayımlanan aynı uygulamanın farklı WordPress medya dizinindeki ekran görüntüleri de arşiv bütünlüğü için aşağıda tutulmuştur. Aynı kavramları gösterdiklerinden, makalenin teknik içeriği ikinci kez tekrar edilmemiştir.
Güncel kullanım için kontrol listesi
• Yönetim bağlantılarının hangi public/private IP adreslerinden geldiğini saptayın; proxy, yük dengeleyici ve NAT etkisini dikkate alın.
• Önceliği yüksek bir yönetici erişim kuralı olmadan genel Remote PowerShell engellemesi uygulamayın.
• Kuralları Test-ClientAccessRule ile örnek kullanıcı ve istemci parametreleri üzerinden sınayın; gerçek bağlantı denemeleriyle ayrıca doğrulayın.
• İlk kuralın etkinleşmesi 24 saate, sonraki değişikliklerin yayılması bir saate kadar sürebilir.
• Exchange Online için Client Access Rules kullanmayın; Microsoft Entra Conditional Access ilkelerini değerlendirin.
Sonuç
Client Access Rules, Exchange Server yönetim yüzeylerini sınırlandırmak için yararlı olsa da tek başına yeterli bir güvenlik çözümü değildir. En az ayrıcalık, yönetim ağlarının ayrıştırılması, güncel yamalar ve erişim loglarının takibiyle birlikte ele alınmalıdır. Özellikle Exchange SE üzerinde değişiklik yapmadan önce ürünün güncel komut dokümantasyonunu kontrol edin.
