كيف يوقف Conditional Access و PIM الهجمات فعليًا؟
شرح عملي لسياسات Conditional Access و Privileged Identity Management، وكيف تغلق الثغرات التي تتركها سياسات كلمات المرور مفتوحة.
سياسات كلمات المرور توقف هجمات التخمين. لكنها لا تفعل شيئًا ضد token جلسة مسروقة، أو رسالة MFA مخادعة، أو حساب admin دائم بقي هناك مع صلاحيات Global Administrator لسنتين. Conditional Access و Privileged Identity Management (PIM) هما أداتا Azure AD / Entra ID اللتان تعالجان فعلًا تلك الثغرات، وتعملان بشكل أفضل معًا.
ما الذي يفعله Conditional Access تحت الغطاء
Conditional Access هو محرك if-this-then-that يتم تقييمه في وقت تسجيل الدخول. جانب "if" (الإشارات) يشمل عضوية المستخدم/المجموعة، حالة امتثال الجهاز، موقع الشبكة، مخاطر تسجيل الدخول (من Identity Protection)، التطبيق الذي يتم الوصول إليه، ونوع تطبيق العميل (متصفح مقابل بروتوكول قديم). جانب "then" (المراقبات) يشمل: طلب MFA، طلب جهاز متوافق، طلب تطبيق عميل معتمد، حظر الوصول كليًا، أو طلب قبول شروط الاستخدام.
سياسة مهمة في كل tenant تقريبًا: حظر المصادقة القديمة. بروتوكولات مثل POP و IMAP و SMTP الأقدم لا تدعم تحديات MFA الحديثة، لذا هي أول شيء تحاول أدوات الملء بالبيانات استخدامه. افحص سجلات تسجيل الدخول المصفاة حسب "Client App = Other clients" قبل الحظر — ستجد غالبًا قارئ legacy واحد قديم أو طابعة multifunction قديمة تصرح باستخدام basic auth.
سياسة ثانية تستحق الحصول عليها من اليوم الأول: طلب MFA لجميع المستخدمين، محدد النطاق باستثناء مجموعة break-glass فقط. لا تحدد نطاق MFA على "المسؤولين فقط." الحسابات المستخدمة القياسية المخترقة هي كيف يحصل المهاجمون على موطئ قدمهم الأول قبل أن يبدأ تصعيد الامتيازات حتى.
مخاطر تسجيل الدخول مقابل مخاطر المستخدم — إشارات مختلفة، استجابات مختلفة
Identity Protection (جزء من Entra ID P2) ينتج عن درجتي مخاطر منفصلتين وسهل الخلط بينهما:
- مخاطر تسجيل الدخول — محاولة المصادقة المحددة هذه تبدو غير عادية (السفر المستحيل، عنوان IP مجهول، خصائص تسجيل دخول غير مألوفة).
- مخاطر المستخدم — تم وضع علم على هذا الحساب لسبب مرتبط بالهوية نفسها (بيانات اعتماد مسربة وجدت في corpus بأرشيف خرق، نشاط compromission مؤكد).
سياسة Conditional Access التي تستجيب لمخاطر تسجيل الدخول يجب أن تطالب عادة بـ MFA — إذا كان المستخدم الحقيقي يمكنه إكمال التحدي، دعه يمر. سياسة تستجيب لمخاطر المستخدم يجب أن تفرض إعادة تعيين كلمة المرور، لأن MFA وحده لن يساعد إذا كان البيان الاعتماد نفسه مشتعل بالفعل.
لماذا الوصول الدائم للـ admin هو المشكلة الأكبر
حتى مع Conditional Access محكم الغلق، حساب يمتلك Global Administrator بشكل دائم هو هدف جالس في الأفق في الدليل. أي شخص يخترقه يرث سيطرة tenant كاملة بدون خطوة إضافية مطلوبة. PIM يزيل الجزء "الدائم".
مع PIM، أدوار admin يتم تعيينها كـ eligible وليس active. يجب على المستخدم تفعيل الدور بشكل صريح، الذي يؤدي إلى تبرير مطلوب، سير عمل الموافقة اختيارية، إعادة تأكيد MFA، ونافذة مرتبطة بالوقت — عادة 1 إلى 8 ساعات — بعدها يتم إلغاء تفعيل الدور تلقائيًا. لا أحد، بما في ذلك مالك الحساب، لديه Global Admin دائم ما لم يكونوا يستخدمونه بنشاط.
حد أدنى من تكوين PIM يكون قابلًا للاستخدام فعلًا
- كل دور فوق Helpdesk Administrator: eligible، وليس دائم.
- Global Administrator و Privileged Role Administrator: يتطلب الموافقة من admin ثانٍ، وليس التفعيل الذاتي فقط.
- تفعيل MFA مطلوب، بدون استثناءات.
- مدة تفعيل قصوى 4 ساعات تفرض على الناس إعادة التفعيل لجلسات عمل منفصلة حقيقية، الذي ينتج عنه أيضًا مسارات تدقيق أنظف.
- استعراضات الوصول كل 90 يومًا على جميع المهام eligible — الحسابات يتم إضافتها لمشروع واحد وليس تتم إزالتها بخلاف ذلك.
حيث تخطئ الفريق
الفشل الأكثر شيوعًا ليس تصميم السياسة، بل قائمة الاستثناء. سياسة Conditional Access مع مجموعة "استثن هؤلاء المستخدمين لأن التطبيق لا يدعم MFA" المتنامية بلا نهاية في النهاية تستثني نصف tenant. تابع الاستثناءات كعنصر في backlog مع مالك وتاريخ إزالة، وليس دلو دائم.
الفشل الثاني هو حسابات break-glass التي لم يتم اختبارها فعلًا. حسابان الطوارئ، مستثنيان من Conditional Access و PIM، مع كلمات مرور عشوائية طويلة محفوظة بدون اتصال والتنبيه على أي تسجيل دخول — وشخص ما يجب أن يحاول تسجيل الدخول إليهما كل ربع سنة لتأكيد أنهما لا يزالان يعملان.
Conditional Access و PIM ليسا تعليم نقطة لتدقيق compliance. إنهما الفرق بين بيان اعتماد مخادع يكون متاعب وبينها تكون compromise tenant كامل. إذا كنت تخطط لأدوات التحكم بالهوية كجزء من بناء Blue Team، فإن أقسام Cloud و Blue Team في Korra Studio تغطي جانب الكشف — ماذا تبدو أحداث مخاطر Identity Protection فعلًا في Sentinel وكيفية التنبيه على أنماط تفعيل PIM المستحيلة.
تمت كتابة هذا المقال بمساعدة الذكاء الاصطناعي، وراجعه ونشره Michal Pilch (CISSP)، Korra Studio.
هذه ملاحظة واحدة من قاعدة معارف Korra Studio — المنصة تجمع كل موضوع مع التوجيه الفردي.
ابدأ بالمجانarrow_forward