من حارس البوابة إلى المراقب: ربط أمان ما قبل المصادقة وما بعدها

By Mirko Peters · 2026-08-11

مرحبًا بعودتكم إلى البودكاست والتعمق التقني المرافق له! إن كنتم قد شعرتم يومًا بأن استراتيجية أمان الهوية لديكم تحتوي على نقطة عمياء مباشرةً بعد أن يقوم المستخدم…

Automatically translated with AI from the original post. Read the English original

أهلاً بعودتكم إلى البودكاست وإلى التعمق التقني المصاحب له! إذا شعرتم يوماً أن استراتيجية أمان الهوية لديكم تتضمن نقطة عمياء بعد أن ينجح المستخدم في تسجيل الدخول مباشرةً، فأنتم لستم وحدكم بالتأكيد. لسنوات، اعتمدت المؤسسات بشكل كبير على ضوابط ما قبل المصادقة لإبقاء المهاجمين خارجاً، معاملةً الباب الأمامي على أنه خط الدفاع الأخير. لكن ماذا يحدث عندما يتجاوز المهاجم هذا الباب برمز مميز صالح أو بمجموعة بيانات اعتماد مسروقة؟ كانت هذه المعضلة بالذات محور حلقتنا الأخيرة، Conditional Access with Defender for Identity Signals. في هذا المنشور، سنتوسع في تلك المفاهيم ونشرح كيف يمكنكم دمج حارس البوابة قبل المصادقة مع المراقب بعدها لبناء بنية هوية مرنة حقاً.

الفكرة الأساسية (الملخص السريع)

لفهم حماية الهوية الحديثة فهماً حقيقياً، يجب أن تنظروا إلى أدواتكم بوصفها أدواراً متخصصة تعمل معاً في الوقت الفعلي:

• الوصول المشروط (CA) هو الحارس عند المدخل. يتميز بقدرته الكبيرة على اتخاذ قرارات ما قبل المصادقة استناداً إلى هوية من يحاول الدخول، ومكان اتصاله، ووضع جهازه.
• Defender for Identity (DfI) هو نظام المراقبة بالكاميرات مضافاً إليه أمن الطوابق لديكم. يتميز برصد سلوك ما بعد المصادقة، والحركة الجانبية، والحالات الشاذة الداخلية.
• لا تتحقق المرونة الحقيقية إلا عندما يرفع المخاطر بعد المصادقة من مستوى الاحتكاك قبل المصادقة تلقائياً وديناميكياً، وذلك هنا، أثناء الجلسة.

النموذج الذهني

لنحسّن النموذج الذهني لكيفية تفاعل هذه المكونات داخل منظومتكم:

• حارس البوابة (CA): يقيّم من يسجل الدخول، وأين يوجد، ووضع الجهاز، والمخاطر وقت تسجيل الدخول، ويفرض ضوابط الجلسة الفورية.
• المراقب (DfI + M365 Defender): يتتبع الحركة الجانبية، وأنماط الوصول غير الطبيعية إلى الموارد، وKerberoasting، وإساءة استخدام NTLM، وتصعيدات الامتيازات غير المتوقعة.
• حلقة التغذية الراجعة: يُبلغ المراقب عن السلوك المشبوه، وهذا بدوره يرفع درجة مخاطر المستخدم أو مخاطر الجلسة. وهذا يدفع حارس البوابة إلى تشديد الضوابط فوراً عبر طلب MFA إضافي، أو حظر الوصول كلياً، أو تقييد الجلسة النشطة.

خارطة الطريق للتكامل (ما يجب تفعيله، وبالترتيب)

يتطلب جعل هذه الأنظمة تتواصل فيما بينها طرحاً منظماً. إليكم الخارطة التي ينبغي اتباعها:

1. الوصول المشروط المدرك للمخاطر (خط الأساس)
   • Entra ID Protection: فعّلوا تقييم مخاطر المستخدم ومخاطر تسجيل الدخول.
   • أنشئوا سياسات الوصول المشروط:
     • حظر عند مخاطر المستخدم = عالية (أو اطلبوا تغيير كلمة المرور إذا كانت عمليات مكتب المساعدة لديكم تدعم ذلك).
     • اطلبوا MFA عند مخاطر تسجيل الدخول ≥ متوسطة.
     • اطلبوا جهازاً متوافقاً للتطبيقات ذات الحساسية المتوسطة إلى العالية؛ واستخدموا مرشحات الأجهزة للأجهزة غير المُدارة لتوجيهها مباشرةً إلى ضوابط الجلسة المقيّدة.
2. دعوا المراقب يتحدث إلى حارس البوابة
   • تأكدوا من أن DfI يبث التنبيهات فعلياً إلى Microsoft 365 Defender وSentinel (إذا كنتم تستخدمونه لـ SIEM/SOAR).
   • أتمتوا إجراءات "Confirm compromised" على المستخدمين عند تنبيهات DfI عالية الخطورة. يؤدي ذلك إلى ضبط مخاطر المستخدم = عالية في Entra ID Protection، فتتفاعل سياسات الوصول المشروط لديكم فوراً.
   • مسار الأتمتة: حادثة M365 Defender ← Logic App أو Power Automate ← Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) ← تسجيل الخروج القسري (اختياري).
   • فعّلوا Continuous Access Evaluation (CAE) على جميع التطبيقات المدعومة (Exchange وSharePoint وGraph) حتى تنهي تغييرات السياسات الرموز المميزة النشطة فعلياً.
3. التحكم بالجلسة لاحتواء المخاطر
   • بالنسبة للجلسات غير المُدارة أو الخطرة، انشروا Defender for Cloud Apps (وكيل الجلسة) مباشرةً من الوصول المشروط:
     • الوصول المشروط ← Use Conditional Access App Control (راقبوا أولاً، ثم احظروا تسرب البيانات مثل التنزيلات، والنسخ واللصق، والطباعة، والمزامنة).
   • قم بإقران هذا مع مخاطر الجهاز في MDE → الامتثال في Intune ← الوصول المشروط "Require compliant device" لجميع التطبيقات الحساسة.
4. ضوابط حماية الهوية المميزة
   • يجب أن يفرض PIM الوصول Just-in-Time، ويشترط المصادقة متعددة العوامل + جهاز متوافق + عدم وجود حالة مخاطر للمستخدم قبل السماح برفع الصلاحيات.
   • طبّق نهج الوصول المشروط لـ حظر الأدوار المميزة إذا كانت مخاطر المستخدم ≥ منخفضة (نعم، حتى عند المخاطر المنخفضة) لفرض الفرز الفوري قبل تولي أي دور إداري.

"إذا كان هذا، فافعل ذاك": ربط إشارات DfI بإجراءات الوصول المشروط

إن ربط إشارات الكشف المحددة من Defender for Identity بالوصول المشروط المؤتمت وإجراءات الاستجابة يسد الفجوة بين المراقبة السلبية والدفاع الفعّال:

ابدأ بتشغيل هذه القواعد في وضع التدقيق/المراقبة لمدة أسبوع إلى أسبوعين، ثم انتقل بالاستجابات إلى وضع الفرض لكل فئة تنبيه مع زيادة ثقتك.

نماذج السياسات (عملية ومختصرة)

لتطبيق هذه الاستراتيجيات في بيئة الإنتاج، إليك أربع سياسات أساسية يجب تكوينها:

1. الحظر عندما تكون مخاطر المستخدم = مرتفعة
   • التعيين: جميع المستخدمين (باستثناء حسابات الطوارئ)، وجميع التطبيقات السحابية
   • الشروط: مخاطر المستخدم = مرتفعة
   • المنح: حظر الوصول
2. رفع مستوى التحقق عند مخاطر تسجيل الدخول
   • التعيين: جميع المستخدمين، والتطبيقات عالية القيمة (بوابات الإدارة، وExchange، وSharePoint، ومركز إدارة Entra)
   • الشروط: مخاطر تسجيل الدخول ≥ متوسطة
   • المنح: اشتراط المصادقة متعددة العوامل + اشتراط جهاز متوافق (أو جهاز مُدار)
3. احتواء الجلسة لغير المُدار
   • التعيين: جميع المستخدمين، وSharePoint/OneDrive/Teams
   • حالة الجهاز: Hybrid/Compliant = تجاوز؛ غير مُدار = فرض
   • الجلسة: استخدام Conditional Access App Control (حظر التنزيلات)
4. حماية رفع الصلاحيات
   • التعيين: أدوار الدليل = الأدوار الإدارية المميزة
   • الشروط: مخاطر المستخدم ≥ منخفضة أو مخاطر تسجيل الدخول ≥ متوسطة
   • المنح: اشتراط المصادقة متعددة العوامل + اشتراط جهاز متوافق؛ حظر إذا كانت المخاطر ≥ مرتفعة

كتيبات الأتمتة (جاهزة للربط)

الأتمتة هي السر الذي يقلل متوسط الوقت اللازم للاحتواء (MTTC). إليك كتيبان يمكنك بناؤهما اليوم:

الكتيب A: تنبيه DfI عالي الخطورة ← احتواء الهوية

• المشغّل: حادثة M365 Defender موسومة بـ IdentityThreatHigh
• الإجراءات:
  1. Graph API – تأكيد اختراق المستخدم (يضبط مخاطر المستخدم على مرتفعة)
  2. Entra ID – إبطال رموز التحديث فوراً
  3. Intune/MDE – عزل الجهاز (إذا كان مرتبطاً بجهاز أساسي واحد)
  4. ServiceNow/JSM – إنشاء تذكرة حادثة تتضمن الخط الزمني والأدلة التي تم جمعها
  5. إشعار فريق SOC ومالك المستخدم عبر بطاقة تكيفية في Teams مع زر تراجع بنقرة واحدة في حال الإنذارات الكاذبة

الكتيب B: اندفاع وصول مشبوه إلى SharePoint

• المشغّل: تنبيه Defender "تنزيل ملف غير معتاد"
• الإجراءات:
  1. وسم المستخدم بـ UnderInvestigation عبر سمات الامتداد في AAD
  2. نقل المستخدم إلى نهج وصول مشروط يوجهه إلى App Control (حظر التنزيل والطباعة)
  3. تفعيل حجز eDiscovery على مواقع SharePoint المتأثرة (اختياري، حسب متطلبات الامتثال)
  4. إنهاء الاحتواء تلقائياً بعد 72 ساعة ما لم يقم فريق SOC بتمديده يدوياً

البحث الاستباقي والاستعلامات المفيدة

يساعدك البحث الاستباقي على اكتشاف الثغرات قبل أن يستغلها المهاجمون. استخدم هذه الاستعلامات في Advanced Hunting لـ M365 Defender:

ارتفاع في وصول مستخدم إلى مواقع SharePoint مقارنةً بخط الأساس لآخر 30 يوماً:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

ارتفاعات في مخاطر تسجيل الدخول مرتبطة ارتباطاً وثيقاً بتنبيهات DfI لاحقة:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

مقاييس تثبت فعالية النهج

عند تقديم التقارير إلى الإدارة العليا، تحتاج إلى مقاييس تُظهر خفضاً ملموساً للمخاطر. تتبّع مؤشرات الأداء الرئيسية التالية:

• متوسط الوقت حتى الاحتواء (MTTC) لحوادث الهوية (الفترة من إنشاء التنبيه حتى تطبيق نهج الوصول المشروط) ↓
• مدة بقاء المهاجم (الفترة من أول إجراء مشبوه حتى المعالجة الكاملة) ↓
• الجلسات عالية المخاطر التي تم حظرها (أحداث أطلقها النهج) ↑ مع انخفاض معدل الإيجابيات الكاذبة ↓
• عمر تراكم المستخدمين ذوي المخاطر (الحالات المفتوحة الأقدم من 24 ساعة) ↓
• زمن إلغاء الرموز المميزة (مقاساً بالثواني) ↓
• إخفاقات الرفع المتميز بسبب المخاطر (يتم رصدها مبكراً قبل وقوع الضرر) ↑ ثم تعود إلى الاستقرار مع مرور الوقت
• Secure Score عبر الهوية والأجهزة والتطبيقات ↑ دون ارتفاع مقابل في تذاكر مكتب المساعدة

استراتيجية النشر على مراحل: 30/60/90

تجنّب محاولة تغيير كل شيء دفعة واحدة. اعتمد الجدول الزمني المرحلي التالي:

الأيام 0–30 (الأسس)

• فعّل إعدادات مخاطر المستخدم وتسجيل الدخول في Entra، ونشر سياسات الوصول المشروط الأساسية في وضع التدقيق، ثم الانتقال إلى وضع الفرض.
• ضمّ Defender for Identity إلى M365 Defender، وتحقّق من التنبيهات وتعيينات الكيانات الأساسية.
• فعّل تقييم الوصول المستمر (CAE) للتطبيقات المدعومة، ودمج مخاطر أجهزة MDE مع امتثال Intune.

الأيام 31–60 (التغذية الراجعة والاحتواء)

• أنشئ دليلي التشغيل A وB في Logic Apps، واختبرهما بشكل موسّع في حالة التشغيل التجريبي.
• طبّق تجربة تجريبية لـ التحكم في التطبيقات للجلسات غير المُدارة مع فريقين إلى ثلاثة فرق أعمال متعاونة.
• طبّق نهج حماية الرفع المتميز في PIM.

الأيام 61–90 (الفرض والقياس)

• انقل أدلة التشغيل الآلية لديك إلى وضع الفرض الكامل للتنبيهات عالية الموثوقية.
• أنشئ مصنف أمان الهوية (في Sentinel أو Power BI) لتتبّع المقاييس المذكورة أعلاه.
• نفّذ تمرين فريق بنفسجي ربع سنوي للتحقق من MTTC وسرعة إلغاء الرموز المميزة وتبديل سياسات الوصول المشروط في سيناريو اختبار حي.

المزالق الشائعة (والإعدادات الافتراضية الأكثر أماناً)

احذر من هذه الأخطاء الشائعة أثناء التنفيذ:

• المزلق: الاعتماد فقط على مخاطر تسجيل الدخول في الوصول المشروط ← الحل: استجب أيضاً لـ مخاطر المستخدم وتنبيهات DfI التي تظهر بعد المصادقة.
• المزلق: عدم تهيئة CAE، مما يسمح للرموز القديمة بإبقاء الجلسات المخترقة نشطة ← الحل: فعّل CAE وادمج إلغاء الرموز المميزة مباشرةً في أدلة التشغيل الآلية.
• المزلق: حظر تنزيل الملفات على نطاق واسع في المؤسسة، مما يثير استياء المستخدمين ← الحل: طبّق التحكم في التطبيقات بشكل انتقائي، فقط عندما تكون الجلسات غير مُدارة أو عالية المخاطر.
• المزلق: سيل من التنبيهات والإيجابيات الكاذبة الناتجة عن سير عمل آلي عدواني لمعالجة الاختراقات ← الحل: اجعل الأتمتة مشروطة بـ التحقق من إشارات متعددة (مثل تنبيه DfI عالي الخطورة + حجم تنزيل غير معتاد + وصول خارج ساعات العمل).
• المزلق: قفل حسابات الطوارئ (break-glass) عن طريق الخطأ بسبب نهج المخاطر الآلية ← الحل: استثنِ حسابين من حسابات الطوارئ المراقبة بعناية، وقم بتدوير بيانات اعتمادهما كل ربع سنة.

قطع نصية جاهزة للنسخ واللصق

لمساعدتك على إيصال هذه التغييرات إلى مؤسستك، استخدم المقتطفات الجاهزة التالية:

ملخص من سطر واحد للتنفيذيين (CAB):

لقد ربطنا بنجاح سلوك المستخدم بعد تسجيل الدخول بقرارات التحكم في الوصول. إذا بدأ أحد الحسابات بالتصرف بشكل غير معتاد، نضيف إجراءً أمنياً إضافياً أو نحظر الوصول أثناء الجلسة. وهذا يقلّص مدة بقاء المهاجم بشكل كبير دون إبطاء العمل اليومي المعتاد.

ملاحظة التغيير للمسؤولين:

• قد تطلب سياسات الوصول المشروط الجديدة المصادقة متعددة العوامل المعززة أو تحظر الوصول عند رصد مخاطر غير طبيعية. يمكن الآن إلغاء رموز المصادقة النشطة أثناء الجلسة استناداً إلى بيانات القياس عن بُعد. تظل حسابات الطوارئ (break-glass) مستثناة صراحةً. يُرجى مراقبة مصنف Identity Resilience لتحليل التأثير.

بطاقة إشعار Teams مناسبة للمالكين (آلية):

• “لاحظنا نشاطاً غير معتاد على الملفات صادراً من حسابك. لقد طبّقنا حمايات مؤقتة (مثل تعطيل التنزيلات على الأجهزة غير المُدارة). إذا كنت أنت من قام بذلك، فما عليك سوى النقر على إقرار؛ وإذا لم تكن أنت، فيُرجى النقر على إبلاغ فوراً.”