Microsoft 365 Conditional Access Politikası 2026: Kurulum + 6 Politika Örneği + What If Analizi

Conditional Access (Koşullu Erişim), Microsoft 365 / Entra ID güvenliğinin kalbidir. "Bu kullanıcı, bu uygulamadan, bu cihazla, bu lokasyondan girerken MFA isteyelim mi? Engelleyelim mi?" sorusuna otomatik cevap verir. Bu rehberde sıfırdan kurulum (Azure AD P1 lisansı şart), 6 yaygın politika örneği, "What If" tool ile etki analizi, "break glass" admin koruması ve yaygın sorunların çözümü detaylı. Yanlış yapılandırılmış CA = tenant'tan herkesi kilitleyebilir — bu rehberi Report-only modda test ederek uygulayın.

Conditional Access Nedir, Neden Kritik?

Conditional Access (CA), Microsoft Entra ID'nin "signal-based access control" motorudur. Klasik bir parola tabanlı erişimden farklı olarak şu sinyalleri eş zamanlı değerlendirir:

• Kim — kullanıcı kimliği, grup üyeliği, rol (ör. global admin)
• Ne — hangi uygulama (Microsoft 365, üçüncü taraf SaaS, custom app)
• Nereden — IP / lokasyon (named locations, trusted IPs, ülke filtresi)
• Hangi cihaz — Azure AD joined, Hybrid joined, Intune compliant, BYOD
• Hangi platform — Windows, macOS, iOS, Android, Linux
• Risk seviyesi — user risk (Identity Protection) + sign-in risk (suspicious activity)

Sonra Access Control uygular: izin ver / engelle / MFA iste / compliant cihaz şart / session kontrolü (token süresi, app-enforced kısıtlamalar).

Neden tek "MFA aç" değil de CA? Klasik MFA kullanıcı bazlıdır — açtığınız anda her erişim için MFA prompt çıkar (rahatsızlık, productivity düşer). CA "şart olduğunda iste" stratejisi: ofis IP'sinden + compliant cihazdan + low-risk session = MFA isteme. Aynı kullanıcı kafede + bilinmeyen cihazdan + high-risk session = MFA + parola değiştirme zorla.

Lisans Gereksinimi — Azure AD P1 Şart

Lisans	CA Yeteneği
Microsoft 365 Business Basic / Standard / Apps	CA yok (sadece "Security defaults" — tüm kullanıcılara MFA, granular yok)
Microsoft 365 Business Premium	Azure AD P1 dahil — Tam CA
Microsoft 365 E3 / Office 365 E3	Azure AD P1 dahil — Tam CA
Microsoft 365 E5 / EMS E5	Azure AD P2 dahil — CA + Identity Protection (risk-based CA)
Standalone Azure AD P1	$6/user/ay, sadece CA gerekiyorsa

Yaygın yanılgı: Business Standard kullanıcılarda "Security defaults" var, CA yok. Daha granular kontrol için Business Premium upgrade gerekir. Sadece P1 satın alma ($6/user/ay) bazı yerlerde mantıklı, ama M365 Business Premium ($22) Defender for Business + Intune dahil = toplam değer daha yüksek.

Politika Yapısı — Assignments + Access Controls

Her CA politikası 2 ana bölümden oluşur:

1. Assignments (Kim, Nereye, Hangi Şartlarda)

• Users / groups: kim kapsanacak veya istisna olacak. "All users" başlangıçta kaçınılması gereken bir scope — önce küçük grup ile test.
• Target resources: hangi uygulamalar. "All cloud apps" en güvenli ama agresif; başlangıçta Office 365 + Microsoft 365 admin portalı ile sınırla.
• Network: IP lokasyon filtresi — "Named locations" ile ofis/şube IP'lerini "Trusted" işaretle.
• Conditions: sign-in risk, user risk, device platforms, client apps (browser/mobile/legacy), filter for devices.

2. Access Controls (Ne Yapılacak)

• Grant: "Block access" veya "Grant access" + şartlar (require MFA / require compliant device / require password change / require approved client app / require app protection policy).
• Session: "Use app-enforced restrictions" (Exchange/SharePoint için web/mobile kısıt), "Use Conditional Access App Control" (Defender for Cloud Apps üzerinden session monitoring), "Sign-in frequency" (her X saat tekrar auth), "Persistent browser session" (browser kapanınca oturum bitsin mi).

İlk Politika — "Require MFA for All Users" (Production'a Almadan Test)

Başlangıç için altın standart politika. Adım adım Entra admin center üzerinden:

1. "Break glass" admin hesabı oluştur ÖNCE. CA politikalarından MUAF tutulacak, en az 2 tane. Sadece felaket senaryosunda kullan. Detay: aşağıdaki bölüm.
2. Entra admin center → Protection → Conditional Access → Policies → "New policy"
3. Name: Require MFA for All Users
4. Users or workload identities: "Include" → "All users". "Exclude" → "Break glass" admin hesabı + emergency service accounts.
5. Target resources: "Include" → "All cloud apps" (veya başlangıçta sadece "Office 365").
6. Grant: "Grant access" → "Require multi-factor authentication" işaretle → Select.
7. Enable policy: "Report-only" seç (PRODUCTION'A ALMA HENÜZ).
8. Politikayı kaydet → Sign-in logs → "Conditional Access" tab → bu politikanın "Would have required MFA" sonuçlarını incele (3-7 gün veri topla).
9. Beklenmedik blok yoksa (özellikle service accounts, on-prem hesaplar) → politikayı "On" yap.

UYARI: "All users" + "All cloud apps" + Block veya MFA → service accounts + on-prem sync hesapları + 3rd-party app integration'ları kırabilir. Mutlaka önce Report-only modda 1 hafta tut ve "Conditional Access Insights and Reporting" workbook'unu incele.

6 Yaygın CA Politikası Örneği

1. Block Legacy Authentication

Amaç: POP3, IMAP, SMTP-Basic, eski Outlook (2013 ve önce) gibi MFA desteklemeyen kimlik doğrulama protokollerini engelle.

Alan	Değer
Users	All users (break-glass exclude)
Apps	All cloud apps
Conditions → Client apps	Exchange ActiveSync clients + Other clients (legacy auth)
Grant	Block access

Etki: SMTP gönderim yapan eski uygulamalar (printer relay, line-of-business app) kırılabilir — önce envanter çıkar, ihtiyaç olanlar için exception grubu oluştur.

2. Require Compliant Device for Sensitive Apps

Amaç: SharePoint admin, Exchange admin, Azure portal gibi yönetimsel uygulamalara sadece Intune'da uyumlu cihazlardan erişim.

Alan	Değer
Users	Directory roles: Global Admin, SharePoint Admin, Exchange Admin
Apps	Office 365 SharePoint, Microsoft Azure Management, Office 365 Exchange Online
Grant	Require MFA + Require device to be marked as compliant

İlgili hata: AADSTS530003 (Device is not enrolled) — kullanıcı cihazını Intune'a kaydetmeli.

3. Trusted Locations — Ofisten MFA İstenmesin

Amaç: Şirket merkez/şube IP'lerinden gelen oturumlarda MFA prompt'u skip et (productivity).

1. Entra → Protection → Conditional Access → Named locations → "New location"
2. Name: Office HQ. IP ranges: ofisin static dış IP'leri (örn. 78.135.10.0/24). "Mark as trusted location" işaretle.
3. Mevcut "Require MFA" politikasını düzenle → Conditions → Locations → Include "Any location", Exclude "All trusted locations".

Dikkat: Trusted location'dan MFA olmadan giriş = saldırgan o IP'yi ele geçirirse MFA bypass eder. Trust kararı stratejik olmalı, "tüm Türkiye trusted" değil.

4. Block Sign-in from Unsupported Countries

Amaç: Şirket faaliyet göstermediği ülkelerden gelen oturumları engelle (örn. Türkiye + iş seyahatleri dışı tüm dünya).

Alan	Değer
Conditions → Locations	Include "Selected locations" → "Allowed countries" (TR, DE, UK, US, vb.) → bunları DIŞINDA Block
Grant	Block access

İpucu: Seyahatte çalışanlar için 24 saatlik bypass için Entra → "Temporary Access Pass" özelliği kullanılabilir.

5. Risk-Based CA (Azure AD P2 — E5 Şart)

Amaç: High-risk sign-in (Identity Protection algılaması) durumunda otomatik MFA + parola değiştirme zorla.

Alan	Değer
Conditions → Sign-in risk	High, Medium
Conditions → User risk	High
Grant	Require MFA + Require password change

Bu politika, kompromize edilmiş hesapları otomatik karantinaya alır. Eski "user clicked, password leaked, attacker logged in" senaryosu artık 5 dakikada blok + parola reset ile durur.

6. Privileged Role Protection

Amaç: Global Admin, Privileged Role Admin gibi hesaplara her oturumda hem MFA hem session lifetime kısaltma.

Alan	Değer
Users → Directory roles	Global Admin, Privileged Role Admin, Privileged Authentication Admin, Security Admin
Grant	Require MFA
Session	Sign-in frequency: 4 hours

Admin oturumu 4 saatte bir tekrar auth gerekir → çalınmış token'ın etki süresi kısalır.

"What If" Tool — Etki Analizi Şart

Yeni politika oluşturmadan önce mutlaka "What If" tool ile simulate et:

1. Entra → Protection → Conditional Access → Policies → "What If"
2. User: politikadan etkilenecek bir kullanıcıyı seç (örn. CEO)
3. Cloud apps: Office 365
4. IP address: ofis IP veya seyahat IP'si test et
5. Device platform: Windows / iOS / Android dene
6. "What If" butonu → hangi politikalar uygulanacak + sonuç ne olacak görünür

Özellikle birden fazla politika varsa "what if" hangi politikaların kümülatif olarak çalışacağını gösterir — beklenmedik blok'ları önler.

"Break Glass" Admin Hesabı — Mutlaka Şart

CA politikaları yanlış uygulanırsa global admin dahil herkes tenant'tan kilitlenir. Felaket geri dönüşü için en az 2 "break glass" hesabı:

• UPN örneği: break-glass-01@firma.onmicrosoft.com, break-glass-02@firma.onmicrosoft.com (default tenant domain — federation/sync etkilenmesin)
• Global Administrator rolü atanmış
• Çok uzun rastgele parola (40+ karakter), kasada / 2 ayrı yönetici elinde fiziksel kağıtta
• Tüm CA politikalarından EXCLUDED (her politika için tek tek exclude eklemeyi unutma)
• MFA istisna: başka bir telefondan / dedicated authenticator (kayıp olmasın)
• Sign-in monitoring: bu hesabın oturum açtığı an Slack/Teams alarm bildirimi
• 90 günde bir test — gerçekten giriş yapılabildiğinden emin ol

Tek admin tenant felaketi: 1 kişi global admin + MFA telefonu da kayıp → tenant'a giriş yok → Microsoft Support 5-30 günlük "tenant recovery" süreci başlatır, sırasında üretim durur. Break-glass hesap bu felaketi 5 dakikaya indirir.

Sorun Çözüm — CA Hataları

"AADSTS53003 — Access has been blocked by Conditional Access policies"

1. Sign-in logs'a git → kullanıcıyı filtrele → failed entry → "Conditional Access" tab → hangi politikanın bloklandığını gör
2. Politikayı "What If" tool ile test et → beklenen davranış mı kontrol et
3. İstisna gerekiyorsa: politika → Exclusions → kullanıcı/grup ekle
4. Geçici çözüm: politikayı "Report-only" moda al → sebep analiz et → düzelt → tekrar "On"

Detaylı kod açıklaması için AADSTS53003 lookup tool.

"AADSTS530003 — Device is not enrolled"

Cihaz Intune'a uyumlu olarak kayıt değil. Çözüm: kullanıcı cihazını "Settings → Accounts → Access work or school → Connect" ile join etmeli. Veya politikada cihaz uyumluluğunu BYOD için kaldır.

"AADSTS50158 — External security challenge not satisfied"

Conditional Access "compliant device" istiyor ama cihaz Intune'da kayıtlı değil veya compliance kontrolü fail oluyor.

PowerShell ile CA Politika Yönetimi

UI yerine PowerShell ile politika oluşturma (versiyonlanabilir, IaC dostu):

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Policy.Read.All"

$policy = @{
    displayName = "Require MFA for All Users (PowerShell)"
    state = "enabledForReportingButNotEnforced"  # Önce Report-only
    conditions = @{
        users = @{
            includeUsers = @("All")
            excludeUsers = @("break-glass-01-user-guid","break-glass-02-user-guid")
        }
        applications = @{
            includeApplications = @("All")
        }
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("mfa")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $policy

# Politikayı production'a al
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "policy-guid" -State "enabled"

# Tüm politikaları listele
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State, CreatedDateTime

Hazır komut için: PowerShell üretici aracı → Conditional Access (Basic).

Conditional Access Best Practices

• Her zaman Report-only ile başla. 7-14 gün veri topla, sonra "On" yap.
• "All users + All apps + Block" politikası KOY ASLA (test ortamı hariç) — break-glass'i de exclude etsen başka admin'ler bloklanır.
• Politika sayısı 10-20 ile sınırlı tut. 30+ politika kümülatif etkileşim debug edilemez hale gelir.
• Naming convention: Geo - TR Only - All Users gibi açıklayıcı isimler.
• Conditional Access Insights workbook'unu haftalık incele (Azure Monitor Logs).
• Change management: politika değişikliği = ticket + onay + rollback planı. PowerShell + Git ile policy-as-code önerilir.
• Microsoft 365 Apps trafiği: yenileme token süresi 90 gün → sürekli MFA istemez. Sign-in frequency kısa ayarlamak güvenliği değil rahatsızlığı artırır.
• Service accounts için ayrı politika: "Workload identities" CA özelliği (Azure AD P2 ile) — managed identity / service principal için.

"Tek başıma yapamam" — Yönetilen Destek

Conditional Access politikası tasarımı + roll-out + monitoring 1 kişilik IT için risklidir — tek hata tüm tenant'ı kilitler. Aşağıdaki durumlarda profesyonel destek şart:

• İlk kez tenant geneli CA roll-out (200+ kullanıcı)
• Hybrid Exchange + on-prem Active Directory + Azure AD Connect ortamı
• 3rd party SaaS uygulamalarının CA entegrasyonu (Salesforce, ServiceNow, SAP)
• BYOD + corporate hibrit cihaz stratejisi
• Regüle sektör (sağlık, finans, kamu) compliance audit hazırlığı
• "What If" + Insights workbook analizi + politika sayısı 15+

Sık Sorulan Sorular

Microsoft 365 Business Basic'te Conditional Access var mı?

Hayır. Business Basic/Standard/Apps planlarında sadece "Security defaults" var — tüm kullanıcılara MFA, granular yok. Conditional Access için Microsoft 365 Business Premium veya E3+ şart (Azure AD P1 dahil). Sadece P1 satın alma da mümkün ($6/user/ay) ama Premium paketi (Defender + Intune dahil) daha mantıklı.

"Security defaults" vs "Conditional Access" — hangisini seçmeli?

Security defaults: ücretsiz, tek tıkla açılır, tüm kullanıcılara MFA + Block Legacy Auth. KOBİ için minimum güvenlik tabanı. Conditional Access: Azure AD P1 lisans, granular kontrol — kullanıcıya/lokasyona/cihaza göre değişen kural. Sadece biri açık olabilir (ikisi birden değil). KOBİ <50 kullanıcı → Security defaults yeterli, 50+ ise CA önerilir.

CA politikası sayısı limiti var mı?

Tenant başına 195 politika sınırı var ama pratikte 10-20 üzerinde yönetilemez. Politika sayısı arttıkça kümülatif etkileşim debug zorlaşır. Naming convention + workbook monitoring + change log şart.

"Block Legacy Auth" politikası SMTP printer'ları kıracak mı?

Evet, eğer printer'lar Basic Auth ile smtp.office365.com'a bağlanıyorsa kırılır. Çözüm: (1) printer'ları SMTP relay servisine geçirin (örn. SendGrid/Mailgun); (2) printer'lar için ayrı uygulama parolası + service account (Modern Auth desteklemeyen) — bu service account'u CA exclude grubuna al; (3) Direct Send protokolü ile gönderim (kimlik doğrulama gereksiz, sadece kendi domain'ine yollarken çalışır).

CA politikası yanlış uygulandı, tenant'a giriş yok — ne yapayım?

Break-glass hesabı varsa hemen kullan → politika düzelt veya kaldır. Yoksa Microsoft Support tenant recovery case'i aç — 5-30 gün sürer + production durur. Bu yüzden break-glass hesabı OPTIONAL DEĞİL, ŞART. Yönetilen destek paketinizdeyseniz partner GDAP üzerinden tenant'ınıza erişip 30 dakikada çözer — destek paketleri.