Entra Conditional Access Politikası Nasıl Yapılandırılır? (2026)

Özet (TL;DR): Microsoft Entra Conditional Access (Koşullu Erişim), Sıfır Güven (Zero Trust) mimarisinin politika motorudur ve doğru yapılandırıldığında MFA, cihaz uyumluluğu, oturum kontrolleri ve risk tabanlı koşulları tek bir merkezden uygular. Ancak yanlış yapılandırılan tek bir politika, bir tenant'ın kendi yöneticilerini kilitleyebilir. Bu rehber; lisans ve rol gereksinimlerinden başlayarak, 13 Mayıs 2026'da yürürlüğe giren "All resources" enforcement değişikliği, ilk politikayı report-only modda oluşturma, Microsoft'un önerdiği üç fazlı dağıtım planı (Hafta 1–4), What If aracıyla test, üretime alma ve Conditional Access Optimization Agent ile sürekli iyileştirmeyi adım adım anlatır. Yazı sonunda, en sık yapılan beş yapılandırma hatası ve bunlardan korunma reçeteleri yer alıyor.

Conditional Access Nedir ve Neden Politika Tabanlı?

Conditional Access, Microsoft Entra ID'nin if-then kuralları üzerinde çalışan politika motorudur: Eğer bir kullanıcı veya iş yükü kimliği belirli bir kaynağa, belirli bir cihazdan, belirli bir ağdan ve belirli bir risk seviyesinde erişiyorsa, o zaman şu kontrolü uygula — MFA iste, uyumlu cihaz şart koş, oturumu kısıtla veya tamamen engelle. Bu yapı, Microsoft'un Sıfır Güven (Zero Trust) stratejisinde kimliği ana kontrol düzlemi olarak konumlandırır: ağ sınırı yerine her erişim isteği bağlama göre değerlendirilir.

Klasik "VPN içindesin, güvendesin" yaklaşımının aksine Conditional Access, her oturum için sinyalleri (kullanıcı, cihaz, konum, uygulama, risk) gerçek zamanlı işler ve bir karar verir: izin ver, kontrol uygula veya reddet. Bu nedenle Conditional Access, kurumsal SaaS uygulamalarına erişimi yöneten operasyonel güvenlik kararının kendisidir; politika dosyasıdır, yönetmelik değildir.

Ön Gereksinimler: Lisans, Roller ve Acil Durum Hesapları

Conditional Access yapılandırmasına başlamadan önce dört zorunlu hazırlık vardır:

• Lisans: Microsoft Entra ID P1 minimum şarttır. Risk tabanlı politikalar (sign-in risk, user risk) için Microsoft Entra ID P2 gerekir. Microsoft 365 E3, P1 içerir; M365 E5 ise P2 dahildir. Microsoft Entra ID lisanslama detaylarını ayrı bir yazıda ele aldık.
• Yönetici rolleri: Politika oluşturmak için Conditional Access Administrator veya Security Administrator rolü, sadece okuma için Security Reader rolü yeterlidir. En az ayrıcalık ilkesini uygulamak için Privileged Identity Management (PIM) ile bu rolleri tam zamanlı değil, ihtiyaç anında aktive edin.
• Acil durum (break-glass) hesapları: Tenant'ta en az iki adet bulut tabanlı (cloud-only), MFA'sız, parolası uzun ve kasaya kilitli acil durum yönetici hesabı olmalıdır. Tüm Conditional Access politikalarınızdan bu hesapları hariç tutun. Politika kilitlenmesi olduğunda tenant'a girebilen tek yol bu hesaplardır.
• Test kullanıcısı ve grubu: Üretim trafiğine dokunmadan önce politikayı doğrulayacağınız ayrı bir test kullanıcısı ve test grubu oluşturun. Production rollout'tan önce her politika bu test grubunda 1 hafta report-only modda kalmalıdır.

Bu dört kalemi tamamlamadan politika oluşturmaya başlamak, tenant kilitlenmesi riskinin en sık nedenidir.

13 Mayıs 2026 Enforcement Değişikliği — Neden Şimdi Aksiyon Almalısınız?

Microsoft, 28 Ocak 2026'da resmi duyurusunda önemli bir Conditional Access davranış değişikliğini açıkladı: 13 Mayıs 2026 itibarıyla, "All resources" (eski adıyla "All cloud apps") hedefli politikalar, kaynak istisnaları (resource exclusions) bulunsa bile OIDC ve sınırlı dizin scope'ları için de zorla uygulanacak. Rollout Mart 2026'da başladı, Haziran 2026'da tamamlanıyor.

Daha önce, sadece openid, profile ve User.Read gibi düşük ayrıcalıklı scope'lar isteyen uygulamalar için bu politikalar atlanıyordu. Yeni davranışta, hangi scope istenirse istensin politika tetiklenir. Bu, MFA veya cihaz uyumluluk kontrolü gibi grant kontrollerinin tutarsız uygulandığı bir güvenlik açığını kapatır.

Çoğu kurumsal müşteri için ek aksiyon gerekmez — uygulamalar zaten ek scope'lar istiyor. Ancak Jamf Pro entegrasyonu, AVD profil yönetimi, özel geliştirilmiş düşük scope'lu uygulamalar veya MFA'sız iş yükü kimlikleri kullanan kurumlar için aşağıdaki kontrol listesi kritiktir:

1. Sign-in log'da Authentication context ve Resource ID filtreleri ile düşük scope'lu sign-in'leri tespit edin.
2. Bu uygulamalar Conditional Access challenge'larını (MFA prompt, compliance check) işleyebiliyor mu doğrulayın.
3. İşleyemiyorsa: ya uygulamayı güncelleyin ya politikayı kaynak bazında yeniden tasarlayın ya da uygulama için resmi policy filter'larını kullanın.

Ek olarak, Microsoft Entra ID Protection'daki legacy risk politikaları 1 Ekim 2026'da emekli oluyor. Hâlâ "User risk" veya "Sign-in risk" tabanlı politikaları Identity Protection bıçağında tutuyorsanız, bunları Conditional Access'e taşıyın — bu rehberde Faz 3'te bu adımı ele alıyoruz.

Adım 1: Politika Bileşenlerini Planlama

Her Conditional Access politikası iki ana parçadan oluşur: Atamalar (Assignments) ve Erişim Kontrolleri (Access Controls). Politikayı yazmadan önce her iki tarafta da net cevap verin:

Atamalar tarafı

• Kullanıcılar veya iş yükü kimlikleri: Hangi kullanıcılar, gruplar, dizin rolleri veya servis prensipleri politikaya dahil/hariç? Acil durum hesapları her zaman hariç.
• Hedef kaynaklar: Bir uygulama mı (örn. SharePoint Online), bir kullanıcı eylemi mi (örn. cihaz kayıt) yoksa bir authentication context mi (örn. yüksek değerli işlem)? Tek tek uygulama listelemek yerine filter for applications ile özelliğe göre süzmeyi tercih edin.
• Koşullar: Cihaz platformu (Windows, iOS, Android, macOS), ağ konumu (named locations), istemci uygulama tipi (browser, mobile, legacy), cihaz öznitelikleri ve kullanılabiliyorsa risk seviyesi (sign-in risk, user risk).

Erişim kontrolleri tarafı

• Grant (izin ver): MFA gerektir, cihaz uyumlu olsun, Entra hybrid joined olsun, onaylı istemci uygulaması, app protection policy uygulansın, parola değiştirilsin, kullanım koşulları kabul edilsin.
• Block (engelle): Erişimi tamamen reddet. Güçlü bir kontroldür; yanlış kullanılırsa kilitlenmeye yol açar. Production'a almadan mutlaka report-only ile etkisini ölçün.
• Session (oturum kontrolleri): App enforced restrictions, Conditional Access App control, sign-in frequency, persistent browser session, continuous access evaluation (CAE).

Adlandırma standardı

Politikalarınız büyüdükçe (tenant başına tavan: 240 politika), bir adlandırma standardı olmadan yönetilemez. Microsoft'un önerdiği şablon: CA[sıra no] - [kullanıcı]: [uygulama] - [kontrol]. Örnek: CA01 - All Users: All Resources - Block Legacy Auth. Acil durum politikaları için: EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] - Require Hybrid Join For VIP.

Adım 2: İlk Politikayı Report-Only Modda Oluşturma

Yeni hiçbir Conditional Access politikası doğrudan On moda alınmaz. Microsoft'un kendi önerisi açıktır: her politika önce Report-only modunda en az 1 hafta izlenmelidir. Adımlar:

1. Microsoft Entra admin center'a (entra.microsoft.com) Conditional Access Administrator rolüyle girin.
2. Sol menüden Protection > Conditional Access > Policies yolunu izleyin.
3. + New policy tıklayın. Adlandırma standardınıza uygun bir isim verin.
4. Assignments > Users: Sadece test grubunuzu ekleyin; Exclude sekmesine acil durum hesaplarınızı ve test ortamı dışındaki kritik servis hesaplarını ekleyin.
5. Target resources: Politika tipini seçin (Cloud apps, User actions veya Authentication context). "All resources" hedefliyorsanız Microsoft Graph dahil her şey kapsanır — block kontrolüyle bu kombinasyona dikkat.
6. Conditions: Cihaz platformu, konum, istemci uygulamaları ve risk seviyelerini girdi olarak ekleyin.
7. Access controls > Grant: Gereken kontrolü seçin (örn. "Require multifactor authentication").
8. Enable policy alanını Report-only olarak ayarlayın ve Create tıklayın.

Politika report-only iken kullanıcı erişimi engellenmez veya MFA tetiklenmez; ancak sign-in log'da "What would happen?" verisi toplanır. 1 hafta veri toplandıktan sonra Sign-in logs > bireysel bir oturum > Report-only sekmesi üzerinden politikanın tetiklenip tetiklenmediği görülebilir.

Adım 3: Microsoft'un Önerdiği Üç Fazlı Dağıtım (Hafta 1–4)

Microsoft Learn'deki Plan your Microsoft Entra Conditional Access deployment kılavuzu, sıfırdan başlayan kurumlar için üç fazlı bir takvim önerir:

Faz 1 — Temel (Hafta 1–2): Baseline güvenlik

• Block legacy authentication — POP, IMAP, SMTP AUTH, eski Exchange Web Services gibi modern auth desteklemeyen protokoller engellenir. Bu, en yüksek geri kazanımlı tek politikadır.
• Secure MFA registration — My Security Info kayıt sayfasına yalnızca güvenilen ağdan veya ek doğrulamayla erişilmesini şart koşar; saldırganın çalınmış parolayla telefon numarası eklemesini engeller.
• Privileged role'lere phishing-resistant MFA — Global Admin, Privileged Auth Admin, Authentication Admin gibi yüksek hak sahipleri için FIDO2 veya Windows Hello for Business gibi phishing-dirençli yöntem zorunlu kılınır.

Faz 2 — Çekirdek kimlik doğrulama (Hafta 2–3)

• Tüm kullanıcılar için MFA — "All users + All resources + Require MFA" yapısı; acil durum hesapları hariç.
• Misafir erişimine güçlü kimlik doğrulama — B2B guest hesapları için MFA + cihaz koşulu.
• Mobil için onaylı istemci uygulaması veya app protection policy — iOS ve Android'de Outlook, Teams gibi uygulamalar Microsoft Intune tarafından yönetilen App Protection Policy üzerinden kullanılır.
• Cihaz kayıt ve birleştirme için MFA — Bir cihazın tenant'a Entra joined veya Entra hybrid joined hâle gelmesi sırasında MFA istenir.

Faz 3 — İleri seviye koruma (Hafta 3–4)

• Yüksek riskli sign-in'leri kısıtla — Identity Protection'ın sign-in risk: high sinyali tetiklendiğinde MFA + parola değiştirme zorunlu kılınır. P2 lisansı gerekir.
• Yüksek riskli kullanıcıları kısıtla — user risk: high ile aynı yapıda; legacy Identity Protection politikalarının yerine geçer ve 1 Ekim 2026 retire'ı için zorunludur.
• Token koruması (token protection) — Sign-in token'larının cihaz bağlamından dışarı kopyalanmasını engeller; pass-the-token saldırılarına karşı koruma sağlar.
• Device code flow kısıtlama, authentication transfer engelleme — Hedefli phishing senaryolarında kullanılan tekniklere karşı baseline kontrol.
• Privileged Access Workstation (PAW) politikaları — Tenant'ta yüksek hak sahipleri için sadece sertifikalı, izole iş istasyonlarından erişim. Önemli infrastruktür yatırımı gerektirir.

Bu dört haftalık takvim, çoğu KOBİ ve mid-market için yeterlidir. Büyük kurumlar (15.000+ kullanıcı) için her fazı genişletmek mantıklıdır; ancak Faz 1 mutlaka ilk iki hafta içinde tamamlanmalı — legacy auth bloğu olmadan diğer politikaların hiçbiri etkin değildir.

Adım 4: What If Aracı ve Insights & Reporting ile Test

Politikayı production'a almadan önce iki test aracı kullanılır:

• What If tool: Conditional Access > What If sekmesinden, belirli bir kullanıcı + uygulama + cihaz + konum kombinasyonu için hangi politikalar tetiklenirdi simülasyonu çalıştırılır. Üretime atılan en sık hatadan biri, beklenmedik politika tetiklenmesidir; What If bu sürprizi önler.
• Insights and Reporting workbook: Sign-in log'larını Azure Monitor / Log Analytics workspace'e akıttığınızda, tüm report-only politikaların kümülatif etkisini bir Workbook'ta görürsünüz. Hangi kullanıcı kaç kez Conditional Access'e takıldı, hangi politika kaç oturumu engellerdi, hangi cihaz tipi en çok kontrol gördü — sayısal cevap.

Test aşamasında özellikle exclude listenizi doğrulamayı ihmal etmeyin: "X grubunu hariç tuttum" demek yetmez; başka bir politika aynı kullanıcıyı tekrar kapsama alabilir. Ortak yanlış: bir politikadan kullanıcıyı hariç tutmak, kullanıcının hiçbir politikadan etkilenmediğini garanti etmez.

Adım 5: Üretime Alma ve Geri Dönüş Stratejisi

Report-only modda 1 hafta + What If testleri tamamlandıktan ve etki sayıları beklenen aralıkta olduğunda, Enable policy toggle'ını On yapın. Bu noktada üç kontrol noktası kritiktir:

1. İletişim: Politikadan etkilenen kullanıcılara değişiklik mesajı gitsin. Yeni MFA prompt'u beklemediği için ilk gün help-desk yığılması en sık yaşanan operasyonel sorundur.
2. İlk 24 saat izleme: Sign-in log'da Failure ve Conditional Access: Failure filtreleriyle anlık takip yapılır. Anormal yığılma görülürse ilk eylem politikayı disable etmektir; delete değil.
3. Roll-back planı: Microsoft, geri dönüş için üç seçenek tanımlar:
   • Politikayı disable et — kullanıcı erişimi anında düzelir.
   • Belirli bir kullanıcı veya grubu exclude et — geçici çözüm; kullanıcı eklendikten sonra tekrar kontrol et.
   • Politika kalıcı olarak gereksizse delete et. Silinen politika ve named location'lar 30 gün soft-delete süresinde geri yüklenebilir; bu süre sonunda kayıp kalıcıdır.

Ekstra güvenlik için Conditional Access politikaları üzerinde değişiklik yapma eylemini protected actions olarak işaretleyin: politika düzenleme öncesinde admin'den taze MFA istenir, bu da yetki alan saldırganın politika değiştirmesini geciktirir.

Adım 6: Conditional Access Optimization Agent — AI Destekli Sürekli İyileştirme

Microsoft, 2026'da Conditional Access portföyüne Optimization Agent'ı ekledi. Microsoft Security Copilot ile entegre çalışan bu AI ajanı, tenant'ınızdaki politikaları sürekli analiz eder ve Sıfır Güven prensiplerine uyumlu öneriler üretir:

• Yeni eklenen uygulama veya kullanıcı grubunda kapsama dışı kalmış riskleri tespit eder.
• Birden fazla politika arasındaki çakışmaları (overlap) ve gereksiz yere genişletilmiş kapsamları işaretler.
• Önerileri tek tıkla uygulayabilir veya pilot grupta test edebilirsiniz.
• Tenant'ın Sıfır Güven postür raporunu, hangi politika hangi kontrol kategorisini karşılıyor seviyesinde görselleştirir.

Optimization Agent, Microsoft Security Copilot lisansına bağlıdır ve özellikle 50'nin üzerinde aktif politika işleten kurumlarda politika hijyenini elde tutar. Manuel denetimle yılda iki kez yapılan policy review, Optimization Agent ile sürekli ve bağlam-farkındalıklı hâle gelir.

Yaygın 5 Yapılandırma Hatası ve Sakınma Stratejileri

1. Acil durum hesaplarını exclude etmeyi unutmak: En sık ve en pahalı hata. Politikanın oluşturma sihirbazında Exclude sekmesini boş bırakırsanız ve aynı politika tüm yöneticileri kapsarsa, MFA yöntemi bozulduğunda tenant'a girilemez. Çözüm: Tenant'ın ilk gününden itibaren "BG-Admin01" ve "BG-Admin02" gibi iki break-glass hesabı oluşturun, parolalarını 64-karakter rastgele string olarak fiziksel kasaya kilitleyin, her politikadan exclude edin, ayda bir oturum açma testi yapın.
2. Block + All resources kombinasyonu: Block grant kontrolü tüm kaynaklara uygulanırsa Microsoft Graph dahil her şey engellenir; Graph'siz Entra portalı dahi açılmaz. Çözüm: Block politikalarını her zaman dar kapsamla yazın (örn. "Yüksek riskli sign-in'leri block" — All users + All resources kombinasyonu yapacaksanız sadece P2 user/sign-in risk koşullarıyla daraltın).
3. Report-only fazını atlamak: "Test grupta denedim, çalışıyor" diyerek doğrudan On'a almak. Test grup ile production trafik dağılımı asla aynı değildir. Çözüm: Her yeni politika minimum 7 gün report-only, ardından Insights workbook'ta etkisinin beklediğinizle uyumlu olduğunu doğrulayarak On'a alın.
4. Politika sayısını şişirmek: Her uygulamaya ayrı politika. 240 politika sınırına yaklaşır, JSON boyut limiti aşımıyla "policy too large" hatası alır, audit'te kimse ne için olduğunu hatırlamaz. Çözüm: Aynı kullanıcı/aynı kontrol gerektiren uygulamaları tek politikada toplayın, kullanıcı listelemek yerine grup veya rol kullanın, uygulamalar yerine filter for applications ile öznitelik bazlı süzme yapın.
5. Legacy Identity Protection risk politikalarını taşımayı unutmak: Identity Protection'daki "User risk policy" ve "Sign-in risk policy" 1 Ekim 2026'da kapanıyor. Taşımayan tenant'lar bu tarihte risk tabanlı korumayı kaybeder. Çözüm: 2026 üçüncü çeyreğine kadar Conditional Access içinde "User risk: high — require password change + MFA" ve "Sign-in risk: high — require MFA" politikalarını oluşturun, 30 gün report-only sonrası On'a alın, ardından Identity Protection'daki eski politikaları off yapın.

Sıkça Sorulan Sorular (SSS)

Conditional Access için hangi lisans yeterli?

Microsoft Entra ID P1 (M365 E3 ve Business Premium içerir) Conditional Access'in temel kullanımı için yeterlidir. Risk tabanlı politikalar (sign-in risk, user risk) ve token koruması için Microsoft Entra ID P2 (M365 E5 ve E5 Security içerir) gerekir. Microsoft Entra ID Free SKU'sunda Conditional Access bulunmaz; sadece security defaults vardır.

Security Defaults ile Conditional Access'i birlikte kullanabilir miyim?

Hayır. Security Defaults, lisanssız tenant'lar için baseline koruma sağlar; Conditional Access politikası oluşturduğunuzda Security Defaults otomatik devre dışı kalır. Bu nedenle ilk Conditional Access politikanızı oluşturmadan önce, Security Defaults'tan elde ettiğiniz korumayı (her kullanıcıya MFA, legacy auth bloğu, privileged role'lere ek MFA) kendi politikalarınızda tekrar inşa etmeniz gerekir.

13 Mayıs 2026 enforcement değişikliği için ne yapmam gerekiyor?

Çoğu kurumsal müşteri için ek aksiyon gerekmez — uygulamalar zaten openid + profile + User.Read dışında scope istiyor. Eğer Jamf Pro, AVD profil yönetimi, kendi geliştirdiğiniz düşük scope'lu uygulamalar veya MFA'sız iş yükü kimlikleri kullanıyorsanız sign-in log'da "resource exclusion" filtresiyle düşük scope'lu istekleri tespit edin ve uygulamaların Conditional Access challenge'larını işleyebildiğini doğrulayın. İşleyemiyorsa uygulama kodunu güncelleyin veya politika kapsamını yeniden tasarlayın.

Conditional Access politikası yanlış yapılandırıp tenant'tan kilitlendim, ne yaparım?

Acil durum (break-glass) hesaplarınızla giriş yapın. Bu hesaplar her Conditional Access politikasından exclude edilmiş olmalıdır; aksi takdirde Microsoft destek (Premier/Unified) çağrısı gerekir ve kurtarma birkaç saatten birkaç güne kadar sürebilir. Ön koşul olarak iki adet break-glass hesabını tenant'ın ilk gününde oluşturun, parolalarını fiziksel kasada saklayın ve her ay bir oturum açma testiyle çalıştığını doğrulayın.

Risk tabanlı politikalar için Identity Protection mu Conditional Access mı kullanmalıyım?

2026 itibarıyla Conditional Access. Microsoft Entra ID Protection'ın legacy risk politikaları (User risk policy, Sign-in risk policy) 1 Ekim 2026'da emekli oluyor. Yeni risk tabanlı politikalarınızı Conditional Access içinde "sign-in risk" ve "user risk" koşullarıyla oluşturun. Identity Protection sinyalleri üreten katman olmaya devam ediyor; Conditional Access ise bu sinyallere göre kontrol uygulayan katman olarak konumlanıyor.

Conditional Access Optimization Agent nedir, ek lisans gerekir mi?

Optimization Agent, Microsoft Security Copilot içinde çalışan bir AI ajanıdır; tenant'ınızdaki Conditional Access politikalarını sürekli analiz edip Sıfır Güven prensiplerine uyumlu öneriler sunar. Kullanım için Microsoft Security Copilot lisansı gerekir (kapasite tabanlı SCU faturalama). Özellikle 50+ aktif politikası olan tenant'larda manuel review yükünü ciddi şekilde azaltır.

Conditional Access Microsoft 365 dışındaki uygulamalar için de çalışır mı?

Evet. Conditional Access, Entra ID'ye federe edilmiş veya OIDC/SAML üzerinden entegre edilmiş tüm SaaS uygulamalarını kapsayabilir — Salesforce, ServiceNow, Workday, AWS Console, GCP, Slack ve binlerce gallery uygulaması dahil. Tenant'ınızda Entra Application Gallery üzerinden eklenmiş her uygulama, hedef kaynak olarak seçilebilir; "All resources" politikası bu uygulamaların tamamını otomatik olarak kapsar.

Sonuç: Politika Hijyeni, Sıfır Güven'in Kalbi

Conditional Access'i "yapılandırılmış" demek tek seferlik bir iş değil, yaşayan bir disiplindir. 2026'nın ortasındaki iki büyük değişiklik — 13 Mayıs enforcement güncellemesi ve 1 Ekim Identity Protection legacy retire — Conditional Access stratejinizi gözden geçirmek için iki resmi takvim noktası sunuyor. Bu rehberdeki üç fazlı dağıtım, report-only disiplini ve break-glass hesabı kuralı, tenant'ınızı hem güvenlik hem operasyonel sürdürülebilirlik açısından sağlam zemine oturtur.

Politika sayısı arttıkça gözle takip etmek mümkünsüzleşir; bu noktada Conditional Access Optimization Agent ile AI destekli sürekli iyileştirme, manuel denetimin yerine geçen ölçeklenebilir bir model sağlar. Kurumlar için pratik tavsiye: her çeyrek bir politika review oturumu, her yeni uygulama onboarding'inde "All resources" kapsama doğrulama, her yıl break-glass hesap testi. Bu üçü olduğunda, Conditional Access organizasyonel bir refleks hâline gelir.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Microsoft Entra Conditional Access yolculuğunda baseline politika tasarımından risk tabanlı yapıya geçişe, break-glass kasası operasyonundan Optimization Agent kurulumuna kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.