تعزيز Zero Trust باستخدام Continuous Access Evaluation (CAE)

By Mirko Peters · 2026-08-11

مرحباً بكم من جديد في البودكاست، وفي تعمّقنا المتواصل في بنية أمن الهوية. إذا سبق لكم أن طبّقتم نهج Conditional Access جديداً ومحكماً في Microsoft Entra ID، ثم رأيتم مستخدماً مخترقاً أو جهازاً خارج النهج يواصل عمله كأن شيئاً لم يحدث لثماني ساعات أخرى، فأنتم لستم وحدكم. يواجه مسؤولو الهوية هذا الواقع المحبط كل يوم. الحقيقة الخفية وراء طريقة تعامل Microsoft 365 مع المصادقة هي أن حدود أمانكم لا تكون

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

مرحباً بكم من جديد في البودكاست، وفي تعمّقنا المتواصل في بنية أمن الهوية. إذا سبق لكم أن طبّقتم نهج Conditional Access جديداً ومحكماً في Microsoft Entra ID، ثم رأيتم مستخدماً مخترقاً أو جهازاً خارج النهج يواصل عمله كأن شيئاً لم يحدث لثماني ساعات أخرى، فأنتم لستم وحدكم. يواجه مسؤولو الهوية هذا الواقع المحبط كل يوم. الحقيقة الخفية وراء طريقة تعامل Microsoft 365 مع المصادقة هي أن حدود أمانكم لا تكون أقوى من رموزكم. النهج لا تفرض نفسها بنفسها؛ بل الرموز هي التي تفرضها.

في منشور المدونة هذا، سنتوسع في حديثنا الأخير في البودكاست، ونشرح كيف يغيّر Continuous Access Evaluation (CAE) قواعد اللعبة. فبالانتقال من الرموز الثابتة إلى الإلغاء الفوري المدفوع بالأحداث، يمكنكم تقليص نافذة التعرض للخطر في مؤسستكم بشكل كبير. وللاطلاع على الآليات الأساسية لانتقال هذه الرموز في الخلفية، تأكدوا من الاستماع إلى الحلقة المرافقة، Modern Authentication and Token Lifecycle in Microsoft 365.

الفكرة الرئيسية (الخلاصة)

• النهج لا تفرض نفسها بنفسها—بل الرموز هي التي تفرضها. يتم تقييم Conditional Access عند إصدار الرمز أو تجديده. وتحتفظ الرموز الموجودة بثقة الأمس حتى تفرض إعادة التقييم.
• MSAL يستبدل رموز الوصول بصمت باستخدام رموز التجديد، بينما يمكن لـ CAE إبطال هذه الرموز أثناء استخدامها عندما يتغير الخطر أو السياق.
• لكي تصبح التغييرات "سارية فورًا"، يجب عليك استهداف دورة حياة الرموز المميزة (تكرار تسجيل الدخول، وإبطال رموز التحديث، وCAE، وعناصر التحكم في الجلسة).

نموذج ذهني بلغة مبسّطة

لفهم سبب كون Continuous Access Evaluation بهذا التحوّل، يجب أولاً أن ننظر إلى العناصر المشاركة في المصادقة الحديثة. تخيّلوا بنية المصادقة لديكم كنادٍ حصري:

• رمز الوصول (AT): بطاقة ضيف قصيرة الأمد (تدوم عادةً نحو ساعة) تمنحكم الدخول إلى غرف محددة.
• رمز التجديد (RT): سوار يدوم لفترة أطول (أياماً أو أسابيع) يتيح لكم طلب بطاقات ضيوف جديدة من مكتب الاستقبال دون المرور بفحص الأمن في كل مرة.
• MSAL: المنفّذ الداخلي الذي يستبدل رمز التجديد الخاص بكم برمز وصول جديد بصمت تام خلف الكواليس.
• Conditional Access (CA): محرك النهج الحارس الذي يتحقق من بيانات الاعتماد والسياق بدقة لحظة إصدار AT/RT (وخلال أحداث CAE).
• CAE (Continuous Access Evaluation): ترقية بروتوكول حديثة تتيح لـ Azure AD سحب الوصول بشكل فعّال أثناء الجلسة إذا ارتفع الخطر، أو أصبح الجهاز غير متوافق، أو تغيّر موقع المستخدم بشكل غير سليم، أو تم تعطيل حساب المستخدم.

لماذا لم يسر نهجك الجديد اليوم

من أكثر تذاكر الدعم الفني شيوعاً بعد أي تحديث لنهج الأمان: "لقد حظرت الدول المحددة للتو، لكن المستخدم X ما زال يحمّل ملفات من شبكة غير مُدارة!" لماذا يحدث هذا؟ الجواب يكمن في التخزين المؤقت للرموز.

• يحمل المستخدمون بالفعل رموز AT صالحة؛ ولا تتم إعادة التقييم قبل أن ينتهي الرمز بشكل طبيعي.
• تظل رموز RT التي صدرت قبل تغييركم تعمل بسلاسة حتى:
  • يتم تقديم رمز RT مرة أخرى أثناء تجديد صامت عادي، أو
  • تقومون بإلغاء الجلسات ورموز التجديد بشكل فعّال، أو
  • يُطلق CAE إعادة تحقق قسرية.
• تقوم تطبيقات الأجهزة المحمولة وأجهزة سطح المكتب (مثل Microsoft Teams وOutlook وOneDrive) بـ التخزين المؤقت والتجديد الصامت للرموز بقوة، مما يطيل دون قصد عمر نافذة "النهج القديم".

أدوات التحكم (بحسب ترتيب الأولوية)

1. فعّلوا CAE لموفري الموارد المدعومين (Exchange Online وSharePoint Online وMicrosoft Graph وTeams).
   • التأثير: يمكن لتغييرات النهج والمخاطر أن تُبطل الرموز أثناء الجلسة فوراً.
2. اضبطوا تكرار تسجيل الدخول (يتم ضبطه عبر عناصر التحكم في الجلسة في Conditional Access لكل تطبيق).
   • أمثلة: من 8 إلى 12 ساعة لتطبيقات الإنتاجية القياسية، ومن ساعة إلى 4 ساعات للبوابات الإدارية عالية الحساسية.
3. فرض إعادة المصادقة عند تغيّر السياق.
   • شروط الوصول المشروط المطلوب فرضها: مخاطر تسجيل الدخول ≥ متوسطة، أو مخاطر المستخدم ≥ عالية، أو الامتثال المطلوب للجهاز، أو الانضمام الهجين/AADJ فقط.
4. استخدم Conditional Access App Control (وكيل جلسات Microsoft Defender for Cloud Apps) للجلسات غير المُدارة أو عالية المخاطر.
   • فرض نهج صارمة مثل منع التنزيل والطباعة والمزامنة لتقليل نطاق التأثير أثناء إيقاف الرموز القديمة تدريجيًا.
5. إبطال الرموز عند الطلب أثناء عمليات النشر النشطة أو حوادث الأمان.
   • النهج المستهدف: إبطال رموز التحديث للمستخدمين أو المجموعات المتأثرة تحديدًا.
   • النهج الواسع: فرض تسجيل الخروج وإبطال الرموز عبر المستأجر بأكمله لتعديل وضع الطوارئ.
6. إعدادات جلسة المصادقة الحديثة.
   • فضّل دائمًا عناصر التحكم Session في الوصول المشروط على نهج عمر الرموز القديمة، التي أُلغي معظمها لأعباء العمل الحديثة.

نهج جاهزة للاستخدام (بسيطة لكنها فعّالة)

1. الحظر عند مخاطر المستخدم = عالية

• التعيين: جميع المستخدمين (باستثناء حسابي طوارئ) + جميع التطبيقات السحابية
• الشروط: مخاطر المستخدم = عالية
• المنح: حظر
• الجلسة: تمكين CAE (إعداد المستأجر)

1. المصادقة التصاعدية عند مخاطر تسجيل الدخول

• التعيين: جميع المستخدمين؛ التطبيقات: Exchange وSharePoint والبوابات الإدارية
• الشروط: مخاطر تسجيل الدخول ≥ متوسطة
• المنح: طلب MFA؛ طلب جهاز متوافق (خاصةً للبوابات الإدارية)

1. تكرار تسجيل دخول قصير للمسؤولين

• التعيين: أدوار الدليل = المميزة
• الجلسة: تكرار تسجيل الدخول = من 1 إلى 4 ساعات، جلسة المتصفح المستمرة = أبدًا

1. احتواء الأجهزة غير المُدارة

• التعيين: جميع المستخدمين؛ التطبيقات: SharePoint وOneDrive وTeams
• مرشّح الأجهزة: غير مُدارة
• الجلسة: استخدام Conditional Access App Control (حظر التنزيل والطباعة)

أدلة التشغيل

دليل الإجراءات A — "اجعل قاعدة الوصول المشروط الجديدة سارية الآن"

• النطاق: مجموعة باسم "Sensitive-Apps-Users"
• الخطوات:
  1. اضبط تكرار تسجيل الدخول للتطبيقات المستهدفة وعدّله حسب الحاجة.
  2. إبطال رموز التحديث لمجموعة الأمان المستهدفة.
  3. أرسل إلى المستخدمين رسالة توضح سبب ظهور مطالبات إضافية لهم اليوم.
  4. راقب SignInLogs بحثًا عن تحديات الوصول المشروط الجديدة، وتابع حجم تذاكر مكتب المساعدة.

دليل الإجراءات B — "احتواء ارتفاع المخاطر أو الاختراق"

• المحفّز: تنبيه هوية عالي الخطورة (مثل مستخدم عالي المخاطر، أو سفر مستحيل، أو حركة جانبية تكشفها Defender for Identity)
• الإجراءات (أتمتها عبر Azure Logic Apps):
  1. تأكيد اختراق المستخدم (يضبط مخاطر المستخدم = عالية).
  2. إبطال رموز التحديث + إبطال جلسات تسجيل الدخول.
  3. نقل المستخدم إلى نهج App Control لمدة 72 ساعة.
  4. طلب إعادة تعيين كلمة المرور وفحص سلامة الجهاز.
  5. إبلاغ فريق SOC ومدير المستخدم عبر بطاقة Teams التكيفية.

أوامر ونقاط نهاية المسؤول (نسخ ولصق)

• Microsoft Graph (موصى به):
  • إبطال الجلسات (للمستخدم): POST /users/{id}/revokeSignInSessions
  • إبطال جميع رموز التحديث (للمستخدم): POST /users/{id}/invalidateAllRefreshTokens
  • تأكيد اختراق مستخدم عالي المخاطر: POST /identityProtection/riskyUsers/{id}/confirmCompromised
  • تجاهل إنذار كاذب: POST /identityProtection/riskyUsers/{id}/dismiss
• PowerShell (Entra / AzureAD)
  • (قديم): Revoke-AzureADUserAllRefreshToken -ObjectId <UserId>
  • MSGraph PowerShell: Invoke-MgGraphRequest -Method POST -Uri "/users/$id/revokeSignInSessions"

نصيحة: استخدم دائمًا Microsoft Graph لضمان توافق أتمتتك مع المستقبل. أنشئ كتب تشغيل تقبل قائمة UPN وتكرر هذه الاستدعاءات مع منطق تأخير متدرج مدمج.

الاستقصاء والمراقبة (KQL)

من واصل استخدام الرموز القديمة بعد تغيير الوصول المشروط؟

ارتفاعات مفاجئة في تبديل رموز التحديث الصامتة (احتمال إساءة استخدام رموز التحديث عبر النصوص البرمجية)

مقاييس ذات أهمية

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

خطة التنفيذ على مدى 30/60/90 يومًا

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

• فعّل CAE ووثّق التطبيقات المدعومة لديك.
• طبّق نهجي الوصول المشروط حظر مخاطر المستخدم ورفع مستوى التحقق عند مخاطر تسجيل الدخول.
• اضبط تكرار تسجيل الدخول على 8–12 ساعة لتطبيقات الإنتاجية، و1–4 ساعات لأدوات المسؤول.
• جرّب App Control تجريبيًا على الأجهزة الطرفية غير المُدارة.

الأيام 31–60 – انضباط الرموز

• أنشئ دليل تشغيل Graph لإبطال رموز التحديث بالجملة حسب مجموعة الأمان.
• اربط Playbook B مباشرةً بتنبيهات Microsoft Defender (مستخدم عالي الخطورة ← إلغاء تلقائي للرموز واحتواء).
• قلّص الجلسات المستمرة وألغِ سياسات عمر الرموز القديمة.

الأيام 61–90 – ضبط Zero Trust

• وسّع تغطية CAE وتحقق من أن المطالبات أثناء الجلسة تعمل بسلاسة كما هو مقصود.
• أضف ضوابط PIM (حظر الترقية إذا كانت مخاطر المستخدم أو تسجيل الدخول ≥ منخفضة/متوسطة).
• أنشئ مصنف Identity Session Health باستخدام المقاييس الموضحة أعلاه.
• نفّذ تمرين فريق بنفسجي للتحقق من سرعة الإلغاء وآليات فرض الوصول المشروط.

أخطاء شائعة (وإعدادات افتراضية أكثر أمانًا)

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

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

ربطنا النهج مباشرةً بـدورة حياة الرموز. مع Continuous Access Evaluation والإلغاء المستهدف، تسري تغييرات المخاطر أو النهج فورًا، فتتقلص فترات التعرض دون أن تتوقف أعمال اليوم.