MFA’yı açtın, cihazları join ettin, kimlik doğrulama yöntemini seçtin. Ama "herkese her zaman MFA sor" kaba bir kalkandır; kullanıcıyı yorar, saldırganı tam olarak durduramaz. Asıl ihtiyaç şu: doğru kişiden, doğru koşulda, doğru kanıtı istemek. İşte bunu yapan katman Microsoft Entra Conditional Access (Koşullu Erişim).
Conditional Access özünde bir if-then motorudur: eğer bir kullanıcı şu uygulamaya, şu koşulda erişmek istiyorsa, o zaman şu kanıtı sağlasın (MFA, uyumlu cihaz, vb.) ya da erişimi engelle. Microsoft bunu "Zero Trust politika motoru" diye tanımlar — kimlik, cihaz, konum ve risk sinyallerini birleştirip anlık karar verir.
Bu yazıda önce bu motorun parçalarını, sonra her kurumun ilk kurması gereken temel politikaları tek tek ele alacağız. Ama en baştan bir uyarı: Conditional Access, yanlış kurulduğunda seni kendi tenant’ından kilitleyebilecek tek araçtır. O yüzden "nasıl kurulur" kadar "nasıl güvenle kurulur"u da işleyeceğiz.
Önce temel: nasıl çalışır?
Bir Conditional Access politikası iki yarıdan oluşur: kime/neye uygulanır (assignments) ve ne yaptırır (access controls).
Atamalar (if — sinyaller):
- Kullanıcı / grup / rol: Kimi hedefliyorsun; kimi hariç tutuyorsun.
- Hedef kaynak: Bulut uygulamaları, Azure yönetimi, belirli uygulamalar.
- Koşullar: Konum (IP/ülke), cihaz platformu (Windows/iOS/Android), istemci uygulaması (modern/legacy), oturum açma riski ve kullanıcı riski (ID Protection — P2).
Erişim denetimleri (then — kararlar):
- Engelle (block) — en katı karar.
- İzin ver, ama şu şartla: MFA iste, authentication strength iste (örn. kimlik avına dayanıklı), uyumlu cihaz iste, Entra hybrid joined cihaz iste, onaylı istemci uygulaması / uygulama koruma politikası iste, parola değişimi iste, kullanım şartları iste.
- Oturum denetimleri: Oturum süresi, uygulama içi kısıtlar (Defender for Cloud Apps ile).
Önemli teknik not: Conditional Access birinci faktör doğrulamasından sonra devreye girer; bir DoS/ön cephe savunması değildir, kimlik sonrası erişim kontrolüdür.
Lisans: Conditional Access Entra ID P1 gerektirir (Microsoft 365 Business Premium de kapsar). Risk tabanlı politikalar (oturum/kullanıcı riski) P2 / ID Protection ister. Lisansın yoksa granüler değil ama iyi bir taban olan Security Defaults’u kullan.
İlk kurulması gereken temel politikalar
Aşağıdakiler, çoğu kurumun güvenlik tabanını oluşturan "olmazsa olmaz" setidir. Hepsini önce report-only ile, break-glass hesaplarını hariç tutarak kur.
- Yöneticilere MFA zorunlu. Ayrıcalıklı rolleri hedefle; MFA — tercihen phishing-resistant authentication strength — iste. Saldırganın en değerli hedefi yönetici hesabıdır; ilk politika bu olmalı. Yöntem seçimi ve güçlü MFA için Entra MFA yapılandırması yazısına bak.
- Tüm kullanıcılara MFA zorunlu. Tüm kullanıcılar + tüm bulut uygulamaları için MFA iste. Zorunlu MFA dayatmasına uyumun da doğru yolu budur. Break-glass hesaplarını hariç tut.
- Legacy kimlik doğrulamayı engelle. Eski protokoller (IMAP/POP/SMTP AUTH gibi) MFA’yı atlatır; parola spreyi saldırılarının ana kapısıdır. Legacy istemcileri hedefleyip engelle. Bunu açmadan önce sign-in logs’ta hangi hesapların hâlâ legacy kullandığını gör.
- Azure yönetimine MFA zorunlu. Azure kaynak yönetimi (portal/CLI/PowerShell) için MFA iste. Faz 2 dayatmasıyla da örtüşür.
- Önemli uygulamalar için uyumlu veya hybrid-joined cihaz. Hassas uygulamalara yalnızca Intune uyumlu ya da Entra hybrid joined cihazlardan erişime izin ver. Cihaz kimliğini burada işe koşarsın.
- (P2) Risk tabanlı erişim. Yüksek oturum açma riski → MFA iste; yüksek kullanıcı riski → güvenli parola değişimi iste. ID Protection sinyalleriyle, saldırı anında otomatik tepki veren katman budur.
- Konum tabanlı kurallar. Named location’larla güvenilir ağları tanımla; iş yapmadığın ülkelerden erişimi engelle ya da ek MFA iste. Agresif coğrafi engellemeden önce gezgin/uzaktan kullanıcıları düşün.
İpucu: Sıfırdan yazmak yerine portaldaki politika şablonlarıyla başla; sonra kendi ortamına uyarla.
Güvenli kurulum disiplini (kendini kilitleme)
- Break-glass (acil erişim) hesaplarını her politikadan hariç tut. En az iki tane; güçlü yöntemle (passkey/CBA) korunur, kimlik bilgileri güvende saklanır ve düzenli test edilir. Bunları unutursan, kötü bir politika seni tamamen dışarıda bırakabilir.
- Önce report-only. Yeni politikayı "On" yapmadan report-only modda çalıştır; kimi, nasıl etkileyeceğini sign-in logs’ta gör.
- What If aracıyla simüle et. Belirli bir kullanıcı/uygulama/koşul için politikanın ne yapacağını canlıya dokunmadan test et.
- Pilot → kademeli → genel. Önce küçük bir grupta aç, sonra yay. Tüm tenant’a tek seferde "On" deme.
Ek olarak: politikalarını sade tut. Onlarca çakışan politika, sorun gidermesi imkânsız bir yumağa döner. Az sayıda, net amaçlı politika > çok sayıda üst üste binen politika.
Sahadan tuzaklar
- Break-glass istisnasını atlamak. Conditional Access ile kendini kilitlemenin bir numaralı yolu. Hesapları önce hazırla, sonra politika yaz.
- Legacy auth’u görmeden engellemek. Önce kim kullanıyor gör; doğrudan engellersen eski bir uygulama/çok işlevli yazıcı/servis hesabı bir anda düşebilir.
- Report-only’yi atlamak. "Eminim nasılsa" deyip "On" demek; en pahalı alışkanlık.
- Aşırı coğrafi engelleme. Gezgin yöneticiyi/VPN kullanıcısını kilitlersin. Blok yerine "bu konumdan ek MFA" çoğu zaman daha doğru.
- Politika enflasyonu. Her ihtiyaç için ayrı politika yazmak. Önce şablon/temel set, sonra gerektikçe ekle.
- Risk tabanlı politikayı lisanssız beklemek. Oturum/kullanıcı riski P2/ID Protection ister; P1’de bu kurallar çalışmaz.
Sonuç
Conditional Access, Entra güvenliğinin beynidir: MFA’yı, cihaz kimliğini ve risk sinyallerini "kime, nerede, hangi koşulda" sorusuna bağlar. Doğru başlangıç, sıfırdan karmaşık kurallar değil; birkaç temel politikadır — yöneticilere ve tüm kullanıcılara MFA, legacy auth engelleme, Azure yönetimine MFA, hassas uygulamalara uyumlu/hybrid-joined cihaz ve (P2 ile) risk tabanlı erişim. Hepsini break-glass istisnası, report-only ve What If disipliniyle kur; önce pilot, sonra genel. SCCM ile yönettiğin cihazları uyumluluk üzerinden bu kontrole katmak için SCCM’den Intune’a co-management yazısına bak.
