Entra ID Protection Risk Policies: Sign-in Risk vs User Risk Explained | Sign-in Risk ولا User Risk؟ إزاي تفهم Entra ID Protection صح

Sign-in Risk ولا User Risk؟ إزاي تفهم Entra ID Protection صح

دليل عملي للفرق بين النوعين، وإزاي تبني عليهم Conditional Access policies تحمي بيها الشركة بدون ما تضرب المستخدمين بـ friction زيادة.

---

المقدمة

كنت شغال على incident فيه user واحد جالوا Risk Detections كتير في نفس اليوم، وأول حاجة اتسألت فيها في الاجتماع كانت "طب ده Sign-in Risk ولا User Risk؟". ولو أنت جديد على Entra ID Protection، ممكن تفتكر إن الاتنين نفس الحاجة، بس الحقيقة إن كل واحد منهم بيحل مشكلة مختلفة تماماً. لو خلطت بينهم في تصميم الـ Conditional Access policies، ممكن تعمل experience تعبان للمستخدمين، أو الأسوأ، تسيب gap أمني حقيقي.

في البوست ده هنفكك الفرق بينهم بشكل عملي، هنشوف إزاي تبني policy لكل واحد، وهنشوف كمان إزاي تراقب النتيجة بـ Microsoft Graph وKQL في Defender XDR.

💡 المتطلبات:

• ترخيص Microsoft Entra ID P2 (جزء من Entra ID Governance أو E5)
• صلاحية Security Administrator أو Conditional Access Administrator على الـ tenant
• Microsoft Graph PowerShell SDK متثبت (Install-Module Microsoft.Graph)
• وصول لـ Microsoft Defender XDR portal لو هتستخدم Advanced Hunting

الفرق الأساسي بين Sign-in Risk وUser Risk

الفكرة الأساسية إن كل واحد منهم بيقيس نوع مختلف من الخطر:

المقارنة	Sign-in Risk	User Risk
بيقيس إيه	احتمالية إن الـ session الحالية نفسها مش المستخدم الحقيقي	احتمالية إن الـ identity نفسها (الحساب) اتعمل له compromise
وقت الحساب	Real-time أثناء عملية Sign-in	Aggregated من تاريخ المستخدم على مدار وقت
أمثلة على الـ Detections	Anonymous IP address, Atypical travel, Unfamiliar sign-in properties, Malware linked IP	Leaked credentials, Password spray, Suspicious risky sign-ins اتجمعت على المستخدم
Remediation النمطي	MFA challenge للسماح بالـ session	Password change (Self-remediation) أو Block من Admin
Grant control في CA policy	Require multifactor authentication	Require password change

⚠️ نقطة مهمة: Microsoft بتوجه العملاء بشكل مستمر لبناء الـ risk policies من خلال Conditional Access مباشرة (باستخدام conditions اسمها Sign-in risk و User risk)، بدل الصفحات القديمة اللي كانت موجودة تحت Identity Protection مباشرة (Legacy User risk policy / Sign-in risk policy). لو لسه عندك policies قديمة على الشكل القديم، الوقت مناسب تنقلها لـ Conditional Access عشان تستفيد من كل الـ conditions التانية زي Device, Location, App.

بناء Sign-in Risk Policy عن طريق Conditional Access

الخطوة الأولى: تحديد الشرط في الـ CA Policy

هنعمل policy تطلب MFA لما الـ Sign-in Risk يكون Medium أو High. أسهل طريقة تعمل ده من الـ Portal، بس لو عايز تعملها بـ Microsoft Graph مباشرة (مفيدة للـ automation أو الـ Infrastructure as Code):

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    displayName = "SamirOnCloud - Require MFA on Medium and High Sign-in Risk"
    state       = "enabledForReportingButNotEnforced"
    conditions  = @{
        users = @{
            includeUsers = @("All")
        }
        applications = @{
            includeApplications = @("All")
        }
        signInRiskLevels = @("medium", "high")
    }
    grantControls = @{
        operator        = "OR"
        builtInControls = @("mfa")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

✅ لاحظ إني بدأت الـ state بـ enabledForReportingButNotEnforced، ده بيخليك تشوف الـ report-only mode الأول قبل ما تفعل الـ policy رسمياً، وده بيوفر عليك مشاكل كتير مع المستخدمين.

الخطوة الثانية: راجع النتيجة في Report-only mode

روح على Entra admin center > Protection > Conditional Access > Insights and reporting وشوف كام sign-in كان هيتأثر بالـ policy لو كانت On. لو النتيجة منطقية، حول الـ state لـ enabled.

بناء User Risk Policy

هنا الفلسفة مختلفة: أنت مش بتحاول تمنع session معينة، أنت بتحاول تحمي الـ identity نفسها من إن حد يستخدمها بعد ما اتسرقت. عادةً الـ grant control هنا بيكون Require password change:

$params = @{
    displayName = "SamirOnCloud - Require Password Change on High User Risk"
    state       = "enabled"
    conditions  = @{
        users = @{
            includeUsers = @("All")
            excludeRoles = @("62e90394-69f5-4237-9190-012177145e10") # Global Administrator
        }
        applications = @{
            includeApplications = @("All")
        }
        userRiskLevels = @("high")
    }
    grantControls = @{
        operator        = "AND"
        builtInControls = @("mfa", "passwordChange")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

⚠️ استبعاد الـ Global Administrators من هذا النوع من الـ policies حاجة مهمة جداً، عشان لو حصل false positive على حساب Admin، مش عايز تتفاجئ إنه مقفول برا الـ tenant في وقت حرج. استخدم PIM بدل ما يكون الـ account دايماً Global Admin أساساً، ده بيقلل الـ exposure من البداية.

مراقبة النتيجة بـ Microsoft Graph وKQL

جلب المستخدمين الخطرين حالياً

Get-MgRiskyUser -Filter "riskLevel eq 'high'" | Select-Object UserPrincipalName, RiskLevel, RiskState, RiskLastUpdatedDateTime

جلب تفاصيل الـ Risk Detections

Get-MgIdentityProtectionRiskDetection -Filter "riskState eq 'atRisk'" |
    Select-Object UserDisplayName, RiskEventType, RiskLevel, DetectedDateTime

تحليل الـ Sign-in Risk في Defender XDR Advanced Hunting

لو الـ tenant متوصل بـ Defender XDR، تقدر تستخدم جدول AADSignInEventsBeta عشان تربط بين الـ Risk Level والـ sign-in events الفعلية:

AADSignInEventsBeta
| where Timestamp > ago(7d)
| where RiskLevelDuringSignIn in ("medium", "high")
| summarize Count = count() by AccountUpn, RiskLevelDuringSignIn, RiskState
| order by Count desc

الـ query ده مفيد جداً لو عايز تعمل triage سريع قبل ما تفعل policy جديدة، أو لو عايز تعرف حجم التأثير المتوقع.

مشاكل شائعة وحلولها

المشكلة	الحل
المستخدم فضل Blocked بعد Password Change ومش قادر يدخل	تأكد إن الـ Risk State اتغيرت لـ Remediated في Get-MgRiskyUser، ولو لسه atRisk، محتاج تعمل Dismiss يدوي من Admin بعد التحقق
Sign-in Risk Policy بتحظر Service Accounts أو Break-glass accounts	استخدم Exclude group مخصص للـ break-glass accounts وراقبهم بشكل منفصل، مش بالـ risk policy العادية
الـ Policy شغالة بس مفيش أي detections بتظهر	تحقق إن الـ P2 license متفعلة فعلياً على المستخدمين المستهدفين، بدونها الـ Identity Protection مش بيولد أي risk detections
فيه فرق بين اللي شايفه في Portal واللي شايفه في Graph API	شوف الـ API version، بعض خصائص riskyUsers متاحة بس في beta endpoint، جرب /beta/riskyUsers لو الـ v1.0 ناقص بيانات

نصائح الأمان 🔐

• ابدأ دايماً بـ Report-only mode لأي policy جديدة قبل التفعيل الكامل، بالذات على User Risk اللي بتأثر على كل جلسات المستخدم
• استبعد break-glass accounts من كل risk policies، وحماهم بطريقة تانية زي FIDO2 keys مع monitoring منفصل
• ربط الـ Risk Policies بـ PIM لتقليل نطاق التأثير، خصوصاً لحسابات الـ Admins
• راجع Risky Users list بشكل أسبوعي، مش بس اعتماداً على الـ automatic remediation
• لو عندك Legacy Identity Protection risk policies، خططلها للانتقال لـ Conditional Access في أقرب فرصة قبل الـ deprecation

الخلاصة

الفرق بين Sign-in Risk وUser Risk مش تفصيلة نظرية، ده بيأثر مباشرة على شكل الـ Conditional Access policies اللي هتبنيها وعلى تجربة المستخدم النهائية. Sign-in Risk بيحمي الـ session، وUser Risk بيحمي الـ identity نفسها على المدى الطويل.

1. حدد بوضوح إيه اللي عايز تحميه: الجلسة الحالية أو الحساب نفسه
2. ابني الـ policies من خلال Conditional Access مباشرة مش من الصفحات القديمة
3. ابدأ بـ Report-only mode وراجع التأثير قبل التفعيل
4. راقب النتيجة باستمرار بـ Graph API أو KQL في Defender XDR

إنت جربت الفرق بين النوعين في بيئتك؟ شاركنا تجربتك أو أي gotcha واجهته في التعليقات.