"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 iş ortağı 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
MFA ve Koşullu Erişimi sizin için kuralım
Kuralları önce raporlama modunda deneyip kimseyi kilitlemeden devreye alıyoruz. Hangi lisansın gerektiğini kullanıcı sayınıza göre hesaplıyoruz.
Hesap güvenliğinizi birlikte gözden geçirelim