"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

ÖzellikKlasik CARisk-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ı deneyimiSürekli MFA (yorgun)Sadece riskli durumlarda MFA
LisansMicrosoft Entra ID P1 (M365 BP / E3+)Microsoft Entra ID P2 (M365 E5 veya P2 add-on $9)
False positive yönetimiAzOrta (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ıç)

PolitikaKoşulAksiyon
CA-001Sign-in risk: MediumMFA zorunlu
CA-002Sign-in risk: HighErişimi BLOK
CA-003User risk: HighParola 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)

PolitikaKoşulAksiyon
CA-001Tüm sign-inMFA zorunlu (klasik)
CA-002Sign-in risk: Low+ + Trusted location dışıCompliant cihaz + MFA zorunlu
CA-003Sign-in risk: HighErişimi BLOK
CA-004User risk: Medium+Parola sıfırlama zorunlu

Şablon 3: Lokasyon-Sıkı (Türkiye/EU Dışı Kısıt)

PolitikaKoşulAksiyon
CA-001TR / EU named locationMFA only
CA-002TR/EU dışı + Sign-in risk: Low+Compliant cihaz + MFA zorunlu
CA-003TR/EU dışı + Sign-in risk: HighBLOK

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:

PolitikaKoşulAksiyon
CA-001-AdminPrivileged Roles + Tüm sign-inMFA + compliant cihaz
CA-002-AdminPrivileged Roles + Sign-in risk: Low+BLOK (admin için sıfır tolerans)
CA-003-AdminPrivileged 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

ÖzellikEntra 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 reportsSı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