Entra ID Protection: Kullanıcı ve Oturum Riski Politikaları

Doğru kullanıcı adı, doğru parola, beklenen ülke. Statik Conditional Access politikası bu oturum açmayı geçirir; saldırgana ait olup olmadığını bilemez. Microsoft Entra ID Protection her oturum açmaya ve her kullanıcıya bir risk düzeyi atayarak bu boşluğu kapatır. Bu rehberde kullanıcı riski ile oturum açma riski farkını, risk tespit türlerini, risk tabanlı Conditional Access tasarımını, kendi kendine düzeltmenin ön koşullarını ve güvenlik ekibinin riskli kullanıcı inceleme akışını anlatıyoruz.

Kullanıcı riski ve oturum açma riski farkı

Entra ID Protection iki ayrı risk kavramıyla çalışır. Sahada yanlış politika tasarımının en yaygın nedeni bu ikisini karıştırmaktır.

Özellik	Oturum açma riski	Kullanıcı riski
Soru	Bu oturum açma isteğini hesabın sahibi mi yapıyor?	Bu hesabın kimlik bilgileri ele geçirilmiş mi?
Kapsam	Tek bir oturum açma	Hesabın genel durumu, birikimli
Tipik kanıt	Anonim IP, alışılmadık oturum özellikleri, olağan dışı seyahat	Sızdırılmış kimlik bilgisi, tehdit istihbaratı eşleşmesi
Uygun düzeltme	MFA ile kimliği kanıtlamak	Güvenli parola değişikliği veya hesabın yeniden güvenceye alınması
Ne zaman sıfırlanır	Başarılı MFA ile o oturum için	Parola değişimi veya yöneticinin riski kapatmasıyla

Ayrım şuna dayanır: oturum açma riskini MFA ile düzeltmek mantıklıdır, çünkü saldırgan parolayı bilse bile ikinci faktörü geçemez. Kullanıcı riskinde durum farklı. Parola sızdıysa MFA istemek yetmez; parola değişmelidir. Yüksek kullanıcı riskli bir hesapta saldırganın kendi MFA yöntemini kaydetmiş olma ihtimali de ayrıca incelenir.

Risk tespit türleri ve kaynakları

Tespitler zamanlamaya göre ikiye ayrılır: oturum açma anında hesaplanan gerçek zamanlı tespitler ve sonradan analizle üretilen çevrimdışı tespitler. Çevrimdışı bir tespit, oturum açma tamamlandıktan sonra kullanıcı riskini yükseltebilir. Kullanıcı riski politikası bu yüzden bir sonraki oturum açmada devreye girer.

Tespit	Tür	Anlamı
Leaked credentials	Kullanıcı	Kullanıcının geçerli parolası sızıntı kaynaklarında bulundu
Microsoft Entra threat intelligence	Kullanıcı / oturum	Bilinen saldırı kalıplarıyla eşleşen etkinlik
Anonymous IP address	Oturum	Tor veya anonimleştirici VPN çıkışından giriş
Unfamiliar sign-in properties	Oturum	Kullanıcının geçmişine göre alışılmadık konum, cihaz, ASN
Atypical travel	Oturum	Coğrafi olarak kısa sürede imkânsız iki konum
Password spray	Oturum	Çok sayıda hesaba yaygın parolalarla deneme
Anomalous token / Token issuer anomaly	Oturum	Olağan dışı token özellikleri veya sahte token sağlayıcı izleri

Tespitlerin tam ve güncel listesi Microsoft’un Entra ID Protection dokümantasyonunda; liste zaman içinde değişir ve bazı tespitler yalnız belirli lisans düzeylerinde ayrıntılı görünür. Hibrit ortamlarda sızdırılmış kimlik bilgisi tespitinin çalışması için parola karması eşitlemesi (password hash sync) açık olmalıdır. Federasyon veya pass-through authentication kullanan ortamlarda da bu eşitleme ek olarak etkinleştirilebilir. Sahada sık rastladığımız durum: PTA kullanan kiracıda leaked credentials tespitinin “neden hiç tetiklenmediği” sorulur. Cevap genelde kapalı hash eşitlemesidir. Eşitleme yöntemi seçimi için Entra Connect Sync ve Cloud Sync karşılaştırmasına bakabilirsiniz.

Risk tabanlı Conditional Access politikaları

Risk politikaları Conditional Access içinde User risk ve Sign-in risk koşullarıyla kurulur. Microsoft’un önerisi, Identity Protection ekranındaki eski kullanıcı riski ve oturum açma riski politikaları yerine Conditional Access kullanmaktır. Ortamda eski politikalar varsa taşıyın; ikisini aynı anda yönetmeyin, çakışan iki politika sorun gidermeyi kâbusa çevirir. Genel tasarım çerçevesi için Conditional Access planlama rehberine bakın.

Başlangıç için iki politika yeterli:

Politika	Koşul	Erişim denetimi	Oturum
Oturum riski	Sign-in risk: High, Medium	Require MFA veya authentication strength	Sign-in frequency: Every time
Kullanıcı riski	User risk: High	Require MFA + Require password change	Sign-in frequency: Every time

Tasarım notları:

• Kapsam: Tüm kullanıcılar ve tüm bulut uygulamaları. Acil durum (break-glass) hesapları hariç tutulur; ama bu hesapların her oturum açması ayrıca alarm üretmelidir.
• Kullanıcı riskinde düzey seçimi: Yalnız High ile başlamak, yanlış pozitif oranını ve yardım masası yükünü görmenizi sağlar. Ölçümden sonra Medium eklenir.
• Parolasız kullanıcılar: Parolası olmayan veya yalnız FIDO2/Windows Hello for Business ile giren kullanıcıda “parola değiştir” düzeltmesi anlamsızdır. Microsoft’un bu senaryo için sunduğu risk düzeltme seçeneklerini güncel dokümantasyondan kontrol edin.
• Phishing’e dayanıklı yöntem: Oturum riski politikasında yalnız “Require MFA” yerine phishing’e dayanıklı bir authentication strength istemek, AiTM saldırısında saldırganın MFA’yı aracı sunucu üzerinden geçirmesini önler. Push onayı AiTM’i durdurmaz. Ayrıntılar için FIDO2 ve passkey geçiş planına bakın.
• Report-only ile başlayın: Politikaları bir–iki hafta yalnız rapor modunda çalıştırın, oturum açma günlüklerindeki “Report-only” sonuçlarını inceleyin, sonra açın.

Kendi kendine düzeltme ve lisans gereklilikleri

Risk tabanlı Conditional Access politikaları ve riskli kullanıcıların tam ayrıntılı raporları Microsoft Entra ID P2 lisansı gerektirir (Microsoft 365 E5 gibi paketlerde dahildir). P1 ve ücretsiz katmanda raporlama sınırlıdır, risk koşulu politikada kullanılamaz. Güncel lisans eşlemesini Microsoft’un lisans sayfasından doğrulayın.

Kendi kendine düzeltme, kullanıcı önceden hazırlanmışsa çalışır. Hazırlık yoksa politika, kullanıcıyı kapıda bırakır:

1. MFA kaydı: Risk anında MFA kaydı olmayan kullanıcı engellenir; o anda kayıt yapmasına izin vermek, saldırganın kendi yöntemini kaydetmesine yol açabilir. Kayıt kampanyası risk politikalarından önce bitmelidir.
2. SSPR ve parola geri yazma: Hibrit kullanıcının bulutta değiştirdiği parolanın şirket içi AD’ye yazılması için Entra Connect’te password writeback etkin olmalıdır. Writeback kapalıysa kullanıcı bulutta yeni, şirket içinde eski parolayla kalır; yardım masasına düşen ilk çağrı bu olur.
3. Şirket içi parola değişikliği: Password hash sync kullanan ortamlarda “şirket içi parola değişikliğinin kullanıcı riskini sıfırlamasına izin ver” ayarı, kullanıcının AD’de yaptığı değişikliğin riski kapatmasını sağlar.

Riskli kullanıcı inceleme akışı

Otomatik düzeltme her durumu kapatmaz. Kullanıcının kendi düzelttiği riskler dahil, yüksek riskli olayları bir analist görmelidir. Kontrol sırası:

1. Triyaj: Risky users raporunda kullanıcıyı açın; risk geçmişini, tetikleyen tespitleri ve ilişkili oturum açmaları inceleyin.
2. Bağlam: IP adresi, cihaz kimliği, uygulama, başarılı/başarısız MFA, aynı IP’den başka hesaplara girişler.
3. Kalıcılık kontrolü: Son günlerde eklenen MFA yöntemleri, yeni posta kutusu kuralları ve yönlendirmeler, uygulama onayları (OAuth consent), yeni kaydedilen cihazlar. Saldırgan önce kapıyı aralık bırakır.
4. Karar: Gerçek ele geçirme ise Confirm user compromised; kullanıcının oturumlarını iptal edin (Revoke sessions), parolayı sıfırlayın, şüpheli MFA yöntemlerini ve kuralları kaldırın. Yanlış pozitifse Confirm safe veya Dismiss user risk.
5. Kayıt: Kararın gerekçesi olay kaydına yazılır.

Toplu inceleme ve otomasyon için Microsoft Graph PowerShell kullanılabilir:

Connect-MgGraph -Scopes "IdentityRiskyUser.ReadWrite.All"

# Yüksek riskli ve hâlâ riskli durumdaki kullanıcılar
Get-MgRiskyUser -Filter "riskLevel eq 'high' and riskState eq 'atRisk'" |
  Select-Object UserPrincipalName, RiskLevel, RiskState, RiskLastUpdatedDateTime

# İnceleme sonrası: ele geçirildiğini onayla veya riski kapat
Confirm-MgRiskyUserCompromised -UserIds "<kullanici-object-id>"
Invoke-MgDismissRiskyUser -UserIds "<kullanici-object-id>"

Risk tespitlerini ve riskli kullanıcı olaylarını Microsoft Sentinel’e veya kullandığınız SIEM’e aktarmak, kimlik olaylarını uç nokta ve e-posta olaylarıyla ilişkilendirmeyi sağlar. Oturum açma ve denetim günlüklerinin portalda tutulma süresi sınırlıdır. Olay üç hafta sonra fark edildiğinde günlük çoktan gitmiş olabilir; uzun süreli inceleme için Log Analytics’e veya SIEM’e aktarımı baştan planlayın.

Yanlış pozitifler ve ayarlama

Risk motoru kullanıcının geçmiş davranışını öğrenir; yeni kiracılarda ve yeni kullanıcılarda ilk haftalarda daha fazla “alışılmadık özellik” tespiti görmek beklenen bir durumdur. Gürültüyü azaltmanın yolları:

• Adlandırılmış konumlar: Şirket çıkış IP’lerini trusted olarak işaretleyin; bu bilgi risk hesaplamasına girdi sağlar.
• Kurumsal VPN ve proxy: Tüm trafiği tek bir bulut proxy’sinden çıkaran mimarilerde konum tabanlı tespitler yanıltıcı olabilir; proxy çıkış IP’lerini tanımlayın.
• Geri bildirim: Analistin Confirm safe ve Confirm compromised kararları modeli besler. İncelenmeden bekleyen riskler hem gürültü üretir hem öğrenmeyi engeller. Kuyruk birikmesin.
• Hizmet hesapları: Etkileşimli oturum açmayan otomasyon hesapları için kullanıcı riski yerine iş yükü kimlikleri ve yönetilen kimlikler tercih edilmelidir.

Risk politikalarının mevcut Conditional Access ve MFA tasarımıyla birlikte değerlendirilmesi Microsoft 365 güvenliği çalışmalarının; risk tabanlı erişim kararlarının kurumun genel kimlik stratejisine bağlanması ise kimlik ve erişim yönetimi çalışmalarının kapsamındadır.

Sık sorulan sorular

Entra ID Protection için hangi lisans gerekir?

Risk koşullarını Conditional Access politikalarında kullanmak ve riskli kullanıcıların ayrıntılı raporlarını görmek için Microsoft Entra ID P2 gerekir. Ücretsiz ve P1 katmanlarında yalnız sınırlı raporlama vardır. Güncel eşlemeyi Microsoft’un lisans dokümantasyonundan doğrulayın.

Oturum açma riski politikasında hangi risk düzeylerini seçmeliyim?

Yaygın başlangıç noktası Medium ve High düzeylerinde MFA istemektir. Low düzeyini eklemek yanlış pozitifleri ve kullanıcı sürtünmesini belirgin biçimde artırabilir; önce report-only modunda etkisini ölçün.

Kullanıcı kendi riskini düzelttiyse yine de inceleme gerekir mi?

Yüksek riskli olaylarda evet. Kendi kendine düzeltme parolayı değiştirir ama saldırganın eklediği MFA yöntemlerini, posta kutusu kurallarını veya uygulama onaylarını temizlemez. Bu kalıcılık kontrollerini analist yapar.

Hibrit ortamda sızdırılmış parola tespiti çalışır mı?

Çalışması için Entra Connect veya Cloud Sync ile parola karması eşitlemesinin etkin olması gerekir. Federasyon veya pass-through authentication kullanılıyor ve parola karması eşitlemesi kapalıysa sızdırılmış kimlik bilgisi karşılaştırması yapılamaz; eşitleme bu yöntemlerle birlikte de açılabilir.