Entra ID Audit Logs and Sign-in Logs: What to Actually Monitor | لوجات الـ Audit والـ Sign-in في Entra ID: إيه اللي يستحق المتابعة فعلاً؟

لوجات الـ Audit والـ Sign-in في Entra ID: إيه اللي يستحق المتابعة فعلاً؟

دليل عملي لتحديد الـ signals المهمة في الزحمة، بعيد عن فكرة "شوف كل اللوجات" اللي مستحيل تنفذها.

---

المقدمة

أول مرة فتحت Sign-in Logs في tenant فيه عدد users كبير، حسيت إني بحاول أشرب من خرطوم حريق. آلاف الـ entries في اليوم، وكل entry فيها تفاصيل كتير: IP, device, location, conditional access result... والمشكلة إنك لو حاولت تراجع كل ده يدوي، مش هتلاقي وقت تعمل حاجة تانية في الشغل.

الحقيقة إن مش كل سطر في اللوجات ده له قيمة أمنية واحدة. فيه فرق كبير بين "حاجة حصلت" و"حاجة لازم تتراجع دلوقتي". في البوست ده هقولك بالتحديد إيه اللي أنا فعلاً براجعه بشكل دوري من الـ Audit Logs والـ Sign-in Logs، وإزاي تبني عليه queries بـ KQL تقدر تشغلها في Log Analytics أو Sentinel بدون ما تضيع وقتك.

💡 المتطلبات:

• Microsoft Entra ID P1 أو P2 للحصول على أفضل مدة retention وتصدير مستمر للوجات
• Global Reader أو Security Reader على الأقل لقراءة اللوجات من الـ portal
• Log Analytics workspace (لو هتعمل diagnostic settings وتشغل KQL)
• صلاحية AuditLog.Read.All لو هتستخدم Microsoft Graph API أو PowerShell

الفرق بين Audit Logs و Sign-in Logs

أول حاجة لازم تكون واضحة: الاتنين مش بديل لبعض، وكل واحد بيجاوب على سؤال مختلف.

الخاصية	Sign-in Logs	Audit Logs
السؤال اللي بتجاوب عليه	مين حاول يدخل، وامتى، ومن فين، ونجح ولا لأ	إيه اللي اتغير في الـ directory
أمثلة	Interactive sign-in, MFA challenge, Conditional Access result	Add member to role, Create application, Update policy
مصدره الأساسي	محاولات المصادقة	أي عملية تغيير قام بها user أو service

لو حصلت حادثة أمنية، هتحتاج الاتنين مع بعض: Sign-in Logs يقولك "دخل إزاي"، و Audit Logs يقولك "عمل إيه بعد ما دخل".

إيه اللي فعلاً تركز عليه في Sign-in Logs

1. محاولات فشل الـ Conditional Access بشكل متكرر

مش كل فشل هو attack، لكن نفس الـ user يفشل نفس الـ policy عشرات المرات في ساعة، ده signal يستحق النظر.

SigninLogs
| where ResultType == "53003" // blocked by Conditional Access
| summarize FailCount = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where FailCount > 10
| order by FailCount desc

2. Legacy authentication

لو عندك protocols زي IMAP أو POP3 أو SMTP AUTH لسه شغالة، ده أكبر باب للـ password spray attacks لأنها مش بتدعم MFA.

SigninLogs
| where ClientAppUsed in ("Other clients", "IMAP4", "POP3", "SMTP", "Authenticated SMTP")
| project TimeGenerated, UserPrincipalName, ClientAppUsed, IPAddress, Location, ResultType
| order by TimeGenerated desc

⚠️ لو عندك أي نتيجة من الـ query ده، متأخرش، legacy auth لازم يتقفل بـ Conditional Access policy أو Authentication Policies بأسرع وقت.

3. Risky sign-ins (لو معاك Entra ID Protection)

الـ risk detections زي "atypical travel" أو "anonymous IP" مهمة جداً، لكن لازم تتربط بـ automation عن طريق Risk-based Conditional Access policies، مش مجرد تراجعها يدوي.

4. Sign-ins من countries غير متوقعة

SigninLogs
| where ResultType == 0
| where Location !in ("EG", "AE", "SA") // عدّل حسب الدول المتوقعة عندك
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName

إيه اللي فعلاً تركز عليه في Audit Logs

1. تغييرات الـ privileged roles

أي إضافة لـ Global Administrator أو Privileged Role Administrator لازم تتابعها فورًا، خصوصًا لو حصلت بره ساعات العمل المعتادة أو بدون ما تعدي على PIM activation.

AuditLogs
| where OperationName == "Add member to role"
| extend RoleName = tostring(TargetResources[0].displayName)
| where RoleName has "Administrator"
| project TimeGenerated, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), RoleName, Result

2. App registrations وتغيير الـ permissions

أي app جديد اخد consent على Microsoft Graph بصلاحيات عالية (زي Directory.ReadWrite.All) لازم يبقى تحت المراقبة، لأنه ده أسلوب شائع في consent phishing.

AuditLogs
| where OperationName in ("Add app role assignment to service principal", "Consent to application")
| project TimeGenerated, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), TargetResources

3. تغييرات Conditional Access policies

لو حد عدل أو عطل policy مهمة، ده ممكن يكون نتيجة غلطة إدارية أو حاجة أخطر. تابعها زي أي تغيير حرج.

4. PIM activations غير المتوقعة

لو معاك PIM شغال، راجع الـ activations اللي حصلت بدون approval أو في وقت غريب من اليوم.

إزاي تسحب اللوجات دي بشكل programmatic

لو مش عايز تعتمد على الـ portal بس، تقدر تستخدم Microsoft Graph API أو PowerShell SDK.

Connect-MgGraph -Scopes "AuditLog.Read.All"

# سحب آخر التغييرات على الـ roles
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add member to role'" -Top 20

# سحب sign-ins فيها risk level متوسط أو عالي
Get-MgAuditLogSignIn -Filter "riskLevelDuringSignIn eq 'medium' or riskLevelDuringSignIn eq 'high'"

GET https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$filter=activityDateTime ge 2024-01-01T00:00:00Z

✅ لو عندك diagnostic settings متوجهة على Log Analytics workspace، أنت هتقدر تشغل نفس الاستعلامات دي بـ KQL بدل ما تستنى API calls كل مرة، وده أسرع في الـ dashboards والـ alerts.

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

المشكلة	الحل
اللوجات بتختفي بعد فترة قصيرة	مدة الاحتفاظ الافتراضية محدودة، خصوصًا بدون P1/P2. اعمل diagnostic settings على Log Analytics workspace للاحتفاظ لفترة أطول
مش لاقي Sign-in Logs في الـ portal	تأكد إن الحساب اللي بتستخدمه معاه Global Reader أو Security Reader على الأقل
عدد النتائج كبير جدًا ومش قادر تراجعها	استخدم summarize في KQL لتجميع النتائج حسب user أو IP بدل ما تراجع كل سطر لوحده
Graph API بيرجع 403 Forbidden	راجع الـ scopes اللي عملت لها consent، غالبًا ناقص AuditLog.Read.All أو Directory.Read.All

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

• اقفل legacy authentication protocols فورًا لو لسه شغالة، ده أكبر ثغرة موجودة في أغلب الـ tenants
• اربط risky sign-ins بـ Conditional Access policies تلقائيًا، مش تكتفي بمراجعتها manual
• راجع كل تعديل على Conditional Access policies بشكل دوري، حتى لو معمول من admin موثوق
• صدّر اللوجات لـ SIEM أو Log Analytics بدل الاعتماد على الاحتفاظ الافتراضي في الـ portal
• حدد baseline لعدد الـ sign-ins العادي لكل user، وده يسهّل عليك ملاحظة أي anomaly بسرعة

الخلاصة

مراقبة اللوجات في Entra ID مش موضوع "شغّل كل شيء وشوف اللي يحصل"، ده موضوع تحديد الأولويات: إيه الـ signals اللي فعلاً بتقولك إن فيه حاجة غلط، وإزاي تتحرك عليها بسرعة قبل ما تتحول لحادثة كبيرة.

1. افهم الفرق بين Sign-in Logs (المصادقة) و Audit Logs (التغييرات في الـ directory)
2. ركز على legacy auth, risky sign-ins, تغييرات الـ roles, و app consents كأولوية
3. استخدم KQL على Log Analytics بدل المراجعة اليدوية في الـ portal
4. صدّر اللوجات لفترة احتفاظ أطول من المدة الافتراضية

إنت بتراجع إيه بالتحديد في اللوجات دي في الشركة بتاعتك؟ شاركنا تجربتك في الكومنتات.