"Tüm kullanıcılarımıza MFA uyguluyoruz, bu yeterli değil mi?" Evet ve hayır. Klasik Conditional Access (CA) "her sign-in için MFA" gibi statik kurallar uygular — koruma sağlar ama operasyon yorucudur. Bir CFO ofisinden günde 5 kez MFA tıklamaktan bıkar. Risk-Based Conditional Access ise milyarlarca sign-in sinyalini analiz eden Microsoft Entra Identity Protection ile çalışır: sadece riskli sign-in'lere MFA, kalan zamanı sessiz geçer. Bu yazıda risk-based CA'nın ne olduğunu, hangi sinyalleri kullandığını, nasıl yapılandırılacağını ve üretime alma sırasında dikkat edilmesi gereken 7 ana pratiği ele alıyoruz.
Klasik CA vs Risk-Based CA — Temel Fark
| Özellik | Klasik CA | Risk-Based CA |
|---|
| Karar mantığı | Statik (her zaman aynı kural) | Adaptif (risk skoruna göre) |
| Örnek kural | "Her sign-in için MFA" | "Sign-in risk medium ise MFA, high ise BLOK" |
| Sinyal kaynağı | Yok (sadece kullanıcı/uygulama/lokasyon) | Microsoft Entra Identity Protection (milyarlarca sinyal) |
| Kullanıcı deneyimi | Sürekli MFA (yorgun) | Sadece riskli durumlarda MFA |
| Lisans | Microsoft Entra ID P1 (M365 BP / E3+) | Microsoft Entra ID P2 (M365 E5 veya P2 add-on $9) |
| False positive yönetimi | Az | Orta (ramp-up şart) |
Microsoft Entra Identity Protection — Hangi Sinyalleri Kullanıyor?
Microsoft Entra Identity Protection, sign-in başına 50+ sinyali analiz edip 0-100 arası risk skoru üretir. Sinyal kategorileri:
Sign-in Risk Sinyalleri (her sign-in için anında)
- Atypical travel: İstanbul'da sabah 09:00, 11:00'da California'dan sign-in. Imkansız.
- Anonymous IP address: Tor, anonim VPN, proxy üzerinden.
- Malware linked IP: Bilinen botnet/malware C&C IP'lerinden.
- Suspicious browser: Anormal user agent (örn. otomatik bot tarayıcı).
- Unfamiliar sign-in properties: Kullanıcının her zamanki davranışından sapma (lokasyon, cihaz, saat).
- Password spray: Şirket çapında benzer parolalarla brute force.
- Activity from anonymous IP: Aynı kullanıcı normalde anonim IP kullanmaz.
- Token issuer anomaly: Beklenmeyen authentication issuer.
User Risk Sinyalleri (kullanıcının zaman içindeki risk profili)
- Leaked credentials: Kullanıcının email + password kombinasyonu dark web'de tespit edildi (Have I Been Pwned veya Microsoft kendi tehdit istihbaratı).
- Threat intelligence: Microsoft güvenlik araştırma ekibinin manuel işaretlediği hesaplar.
- Multiple risky sign-ins: Kullanıcı son 14 gün içinde birden fazla riskli sign-in attı.
Risk Seviyeleri
- Low (<33): Hafif sapma, ortalama davranış
- Medium (33-66): Şüpheli, ek doğrulama önerilir
- High (>66): Yüksek olasılıkla saldırı, müdahale şart
Adaptif Politika Şablonları — 4 Yaygın Yapılanma
Şablon 1: Standart Adaptif (Önerilen Başlangıç)
| Politika | Koşul | Aksiyon |
|---|
| CA-001 | Sign-in risk: Medium | MFA zorunlu |
| CA-002 | Sign-in risk: High | Erişimi BLOK |
| CA-003 | User risk: High | Parola sıfırlama + MFA zorunlu |
Bu kombinasyon en dengeli: düşük operasyon yükü + yüksek koruma. Her 3 politika ayrı ayrı oluşturulmalı (tek politikada hem MFA hem BLOK olmaz).
Şablon 2: Yüksek Güvenlik (Finans, Sağlık)
| Politika | Koşul | Aksiyon |
|---|
| CA-001 | Tüm sign-in | MFA zorunlu (klasik) |
| CA-002 | Sign-in risk: Low+ + Trusted location dışı | Compliant cihaz + MFA zorunlu |
| CA-003 | Sign-in risk: High | Erişimi BLOK |
| CA-004 | User risk: Medium+ | Parola sıfırlama zorunlu |
Şablon 3: Lokasyon-Sıkı (Türkiye/EU Dışı Kısıt)
| Politika | Koşul | Aksiyon |
|---|
| CA-001 | TR / EU named location | MFA only |
| CA-002 | TR/EU dışı + Sign-in risk: Low+ | Compliant cihaz + MFA zorunlu |
| CA-003 | TR/EU dışı + Sign-in risk: High | BLOK |
KVKK Madde 9 (yurtdışı veri aktarım) gereksinimini destekler. Önce Named Locations tanımlanmalı (Microsoft Entra admin → Conditional Access → Named locations).
Şablon 4: PIM + Risk Kombo (Admin Hesapları)
Admin hesaplarını korumak için ekstra katman:
| Politika | Koşul | Aksiyon |
|---|
| CA-001-Admin | Privileged Roles + Tüm sign-in | MFA + compliant cihaz |
| CA-002-Admin | Privileged Roles + Sign-in risk: Low+ | BLOK (admin için sıfır tolerans) |
| CA-003-Admin | Privileged Roles + User risk: Low+ | Parola sıfırlama + MFA |
Yapılandırma — PowerShell Adım Adım
Aşağıda Şablon 1 (Standart Adaptif) için PowerShell ile yapılandırma. Manuel admin merkezde de yapılabilir ama PowerShell ile dokumantasyon + tekrarlanabilirlik avantajı vardır.
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","IdentityRiskyUser.Read.All","Application.Read.All"
# Break-glass hesabı (mutlaka tüm CA politikalarından hariç tutulmalı)
$breakGlass = Get-MgUser -Filter "userPrincipalName eq 'breakglass@sirket.onmicrosoft.com'"
if (-not $breakGlass) { Write-Error "Break-glass hesabı bulunamadı"; return }
# === Politika 1: Sign-in risk MEDIUM → MFA ===
$conditions1 = @{
Users = @{ IncludeUsers = @("All"); ExcludeUsers = @($breakGlass.Id) }
Applications = @{ IncludeApplications = @("All") }
SignInRiskLevels = @("medium")
ClientAppTypes = @("all")
}
$grant1 = @{ Operator = "OR"; BuiltInControls = @("mfa") }
New-MgIdentityConditionalAccessPolicy `
-DisplayName "CA001-Sign-in-Risk-MEDIUM-MFA" `
-State "enabledForReportingButNotEnforced" `
-Conditions $conditions1 `
-GrantControls $grant1
# === Politika 2: Sign-in risk HIGH → BLOK ===
$conditions2 = $conditions1.Clone()
$conditions2.SignInRiskLevels = @("high")
$grant2 = @{ Operator = "OR"; BuiltInControls = @("block") }
New-MgIdentityConditionalAccessPolicy `
-DisplayName "CA002-Sign-in-Risk-HIGH-BLOCK" `
-State "enabledForReportingButNotEnforced" `
-Conditions $conditions2 `
-GrantControls $grant2
# === Politika 3: User risk HIGH → Parola sıfırlama + MFA ===
$conditions3 = $conditions1.Clone()
$conditions3.Remove("SignInRiskLevels")
$conditions3.UserRiskLevels = @("high")
$grant3 = @{ Operator = "AND"; BuiltInControls = @("mfa","passwordChange") }
New-MgIdentityConditionalAccessPolicy `
-DisplayName "CA003-User-Risk-HIGH-PWD-MFA" `
-State "enabledForReportingButNotEnforced" `
-Conditions $conditions3 `
-GrantControls $grant3
Write-Host "3 politika oluşturuldu (report-only modda)" -ForegroundColor Green
Write-Host "→ Sign-in logs > Conditional Access tab'da 2-3 hafta izle, false-positive ayıkladıktan sonra 'enabled'a çevir" -ForegroundColor Cyan
Üretime Alma — 7 Kritik Pratik
1. Asla Doğrudan Enabled ile Başlama
Yeni CA politikalarını her zaman enabledForReportingButNotEnforced (report-only) modda başlat. 2-3 hafta izle, etkilenecek sign-in'leri analiz et, false-positive'leri tespit et. Sonra enabled'a çevir.
2. Break-Glass Hesabı Mutlaka
Tüm CA politikalarından hariç tutulan en az 1 break-glass (acil durum) hesabı yarat. Tipik isimlendirme: breakglass@sirket.onmicrosoft.com. Bu hesap:
- Tüm CA politikalarından hariç (
ExcludeUsers)
- MFA kayıtlı değil (kasıtlı — saldırı sırasında MFA cihaz erişilemez olabilir)
- Çok güçlü parola (50+ karakter, kasada saklı)
- Global Admin yetki
- Yıllık parola değişimi + sign-in audit raporlama
3. Named Locations Önce Tanımla
Lokasyon-bazlı CA için Named Locations'ları admin merkezde tanımla:
- Trusted IPs: Şirket public IP'leri (corporate firewall)
- TR-EU bölgeleri: Country/region listesi (Türkiye, AB üyesi 27 ülke)
- Yasaklı bölgeler: Yüksek riskli ülkeler (örn. herhangi bir sektör/ürün için yasaklı)
4. False-Positive İlk Hafta Yönetimi
Report-only modda en sık görülen false-positive'ler:
- VPN kullanıcısı: Sürekli "atypical travel" tetikler — VPN exit IP'sini Trusted IP'ye ekle
- Mobil veri: Operatör IP'si bazen anonymous IP listesine girer — kullanıcıya MFA OK
- Yurt dışı seyahat: Pazarlama personeli düzenli yurtdışı — onların user'larını ayrı bir politikada hariç tut veya whitelist
- Test/automation hesapları: Service principal kullan, kullanıcı hesabı kullanma
5. Risky User Manuel Review Süreci
Microsoft Entra Identity Protection "high risk" işaretlediği kullanıcılar için manuel review gerek:
# Riskli kullanıcı listesi
Get-MgRiskyUser -Top 50 | Select UserDisplayName, RiskLevel, RiskDetail, RiskLastUpdatedDateTime
# Riskli sign-in'ler (geçen 7 gün)
Get-MgRiskySignIn -Top 50 |
Select UserDisplayName, RiskLevel, IpAddress, Location, RiskEventTypes |
Where-Object { $_.RiskLevel -in @("medium","high") }
# False-positive olarak işaretle (manuel review sonrası)
Confirm-MgRiskyUserCompromised -RiskyUserIds @("user-id-here")
# veya temiz işaretle
Confirm-MgRiskyUserDismiss -RiskyUserIds @("user-id-here")
6. Aylık Audit + Raporlama
Her ay başında:
- CA Insights raporunu kontrol et (admin merkez → Conditional Access → Insights and reporting)
- Kaç sign-in MFA tetikledi, kaç sign-in BLOK oldu?
- False-positive oranı %5'in üzerine çıkmış mı?
- Hangi politika çoğu BLOK'u tetikliyor — review et
7. PIM Entegrasyonu (Admin Hesapları)
Admin hesaplarına ekstra katman: Privileged Identity Management (PIM). Her admin role'ünü "eligible" yapın, kullanım anında 4-8 saatlik aktivasyon talebi + MFA gereksinimi. Sürekli admin riski sıfırlanır.
Microsoft Entra ID P1 vs P2 Karşılaştırma
| Özellik | Entra ID P1 (M365 BP / E3+) | Entra ID P2 (M365 E5 / +$9) |
|---|
| Klasik Conditional Access | ✓ | ✓ |
| Sign-in risk Conditional Access | ✗ | ✓ |
| User risk Conditional Access | ✗ | ✓ |
| Risky users / sign-ins reports | Sınırlı | Tam (Identity Protection) |
| Privileged Identity Management (PIM) | ✗ | ✓ |
| Access Reviews | ✗ | ✓ |
| Entitlement Management | ✗ | ✓ |
Karar: Risk-based CA + PIM'i kullanmak istiyorsanız Microsoft Entra ID P2 zorunlu. M365 E5 ile dahil veya stand-alone $9/user/ay add-on. KOBİ için sadece admin hesaplarına P2 satın alıp diğer kullanıcıları P1'de tutmak (M365 BP) maliyet-etkili olabilir.
Sıradaki Adım: PowerShell Üreticisi ile Hızlı Başlangıç
PowerShell Komut Üretici — CA Risk-Based Template
PowerShell üreticimizdeki "CA Risk-Based" senaryosu ile risk modu (signInMedium / signInHigh / userRisk) ve lokasyon kuralı (trusted IP / TR-EU bölge) seçimleri ile politika kodu üretin. Tek tıkla kopyalanabilir.
PowerShell Üretici Aracını Aç →
Microsoft Yetkili Çözüm Ortağı (CSP) olarak Conditional Access ramp-up + PIM kurulumu + Identity Protection tuning hizmetlerini sunuyoruz. WhatsApp 0216 344 15 59.
Sıkça Sorulan Sorular
Risk-Based CA ile basic CA arasındaki fark nedir?
Basic CA kuralı (örn: tüm kullanıcılara MFA) statiktir — koşul her zaman aynıdır. Risk-based CA, Microsoft Entra Identity Protection'ın gerçek zamanlı sinyalleriyle (sızdırılmış parola, anormal sign-in, atypical travel, malware infected device, anonymous IP) çalışır: 'sign-in risk medium ise MFA, high ise blokla' gibi adaptif kararlar verir. Microsoft Entra ID P2 (Microsoft 365 E5 veya Entra ID P2 add-on) gerekir.
"Atypical travel" tetiklenmesi false-positive olabilir mi?
Evet. En yaygın false-positive: VPN kullanıcısı (exit IP başka bir ülkede). Çözüm: VPN exit IP'lerini Trusted IPs Named Location'a ekle. Yurt dışı seyahat eden personel için ayrı bir CA politikası + whitelist olabilir. Report-only modda 2-3 hafta izleyip false-positive'leri ayıklamak şart.
Break-glass hesabı niye MFA olmamalı?
Break-glass amacı acil durumda erişim. Eğer MFA kayıtlıysa ve MFA cihazı (telefon) ele geçirilmişse veya çalışmıyorsa hesaba erişemezsiniz. Trade-off: çok güçlü parola + fiziksel güvenlik (kasada saklı) + sign-in audit + olası sign-in için anında alarm yapılandırması. Microsoft 2 break-glass hesabı önerir.
Sign-in risk vs User risk farkı nedir?
Sign-in risk: O anki sign-in'in riski (anlık karar). Örnek: anormal lokasyon, anonymous IP, atypical travel. Aksiyon: MFA veya BLOK. User risk: Kullanıcının zaman içindeki risk profili (cumulative). Örnek: leaked credentials, multiple suspicious sign-ins. Aksiyon: parola sıfırlama + MFA. İki ayrı CA politikası gerekir.
Conditional Access raporu nereden görünür?
Microsoft Entra admin merkezi → Sign-in logs → Conditional Access tab. Her sign-in için hangi CA politikalarının değerlendirildiği, sonuç (success/failure/not applied/report-only), uygulanan kontrolleri görebilirsiniz. Workbooks sekmesinde hazır raporlar (Report-Only Insights, Sign-In failures vb.) var.
Conditional Access uygulayınca eski auth (POP, IMAP, SMTP basic) ne olur?
Modern CA legacy auth'u (basic auth) bloklar — bu kasıtlıdır. POP/IMAP/SMTP basic auth phishing açığıdır. Eğer eski uygulamalarınız (örn. eski tarayıcı, IoT cihazı) basic auth kullanıyorsa, bunları modern OAuth'a geçirin veya Service Principal + app password kullanın. Microsoft Exchange Online basic auth Eylül 2022'de tamamen kapatıldı.
Risk skorum yanlış olabilir mi?
Evet. Microsoft tüm sinyalleri 100% doğru analiz etmez (özellikle yeni hesaplar için baseline yokken). Bu yüzden: (1) report-only modda 2-3 hafta izle, (2) Confirm-MgRiskyUserDismiss ile false-positive'leri temizle (bu Microsoft'a feedback gider, model gelişir), (3) Confirm-MgRiskyUserCompromised ile gerçek tehditleri işaretle. Manuel review süreci kritik.
Kaynaklar