M365Con 2027 – مؤتمر مجاني عبر الإنترنت · 11–22 Jan 2027 · 120 sessions→ m365con.net

المدونة · Mirko Peters

تصيّد الموافقة في Microsoft 365

By · · Updated

تعرّف على كيفية تجاوز تصيّد الموافقة في Microsoft 365 لدفاعات المصادقة متعددة العوامل التقليدية، وكيفية إساءته لأذونات OAuth، وكيفية اكتشافه والوقاية منه.

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

Cover: Stop OAuth Consent Attacks in Microsoft Entra ID

يُعد تصيّد الموافقة من أسرع التهديدات نموًا في بيئات Microsoft 365 وAzure، إذ يفاجئ المؤسسات ويتجاوز حتى أقوى دفاعات المصادقة. وعلى خلاف التصيّد التقليدي الذي يسعى إلى سرقة كلمة المرور، يتسلل تصيّد الموافقة من “باب جانبي”، مستغلًا الآليات نفسها المصممة لتأمين تسجيل الدخول. تعتمد هذه التقنية على ثقة المستخدمين، وتستفيد من OAuth، وهو إطار التفويض نفسه الذي يدعم تسجيل الدخول الموحّد والتكاملات المشروعة للتطبيقات في السحابة.

يمكن للمهاجمين استخدام تصيّد الموافقة للحفاظ على وصول مستمر وخفي إلى بيانات الأعمال الحساسة، حتى في البيئات المحمية بالمصادقة متعددة العوامل (MFA). يتناول هذا الدليل بعمق كيفية تجاوز تصيّد الموافقة للأمن التقليدي وسببه، ويحلل هجمات واقعية، ويرشدكم إلى خطوات عملية لاكتشاف تهديدات الموافقة ومنعها واحتوائها. وسواء كنتم تديرون Microsoft 365 لفريق صغير أو تشرفون على أمن آلاف المستخدمين، فإن فهم طريقة عمل المهاجمين ضمن تدفقات موافقة OAuth أصبح مهارة أساسية.

فهم تصيّد الموافقة ولماذا تفشل المصادقة متعددة العوامل

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

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

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

ما هو تصيّد الموافقة، ولماذا يتجاوز المصادقة متعددة العوامل؟

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

والنقطة الحاسمة هنا أنك عندما توافق على شاشة الموافقة، يستلم التطبيق رموز وصول وتحديث من مزوّد الهوية، مثل Microsoft Entra ID (المعروف سابقًا باسم Azure AD). ويمكن استخدام هذه الرموز للوصول إلى بيانات Microsoft 365 الخاصة بك، مثل البريد والملفات والتقويم وغيرها، دون معرفة كلمة المرور ودون تفعيل المصادقة متعددة العوامل. لا يحتاج المهاجم إلى تجاوز دفاعات تسجيل الدخول، بل يكفيه استخدام الوصول الذي منحته طواعية، والذي تعدّه المنصة مشروعًا تمامًا.

الفرق بين تصيّد بيانات الاعتماد وتصيّد الموافقة دقيق لكنه جوهري. فتصيّد بيانات الاعتماد يسعى إلى التقاط اسم المستخدم وكلمة المرور (وهي عادةً ما تحميها المصادقة متعددة العوامل)، بينما يعمل تصيّد الموافقة ضمن تدفق تفويض OAuth 2.0 الرسمي. وحتى مع تطبيق المصادقة متعددة العوامل بالكامل، يتجاوزها المهاجم تمامًا عندما يُكمل المستخدم تدفق الموافقة من خلال جلسته الحالية. وبمجرد إصدار رموز OAuth هذه، يبقى موطئ قدم المهاجم قائمًا حتى لو غيّر الضحية كلمة المرور أو ألغى جلسته.

للاطلاع على تحليل أعمق، يمكنكم الاطلاع على هذه النظرة العامة على هجمات منح الموافقة عبر OAuth في Entra ID، التي تفصّل المخاطر الحقيقية واستراتيجيات الدفاع التي ينبغي للمؤسسات إعطاؤها الأولوية. الخلاصة: يجب على المؤسسات ألا تكتفي بأمان بيانات الاعتماد وMFA إذا أرادت وقف هذه الهجمات من مصدرها.

كيف يستغل تصيّد الموافقة عبر OAuth الثقة لاختراق البيانات

يقوم المهاجمون في حملات تصيّد الموافقة بإنشاء تطبيقات تابعة لجهات خارجية أو انتحال صفتها، ثم يطلبون من المستخدمين منحها أذونات واسعة، وغالبًا عبر تدفقات OAuth 2.0 تبدو مألوفة و"آمنة". يرى المستخدم نافذة موافقة قياسية تتضمن طلبات مثل "قراءة بريدك" أو "الوصول إلى ملفاتك". وإذا نقر المستخدم على "قبول"، يحصل التطبيق الخبيث على رموز OAuth حقيقية، ما يمنحه وصولًا مباشرًا إلى موارد Microsoft 365 أو Azure المحددة.

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

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

للاطلاع على تحليل لاختراق حقيقي ورؤية عملية لسلاسل هذه الهجمات، راجعوا هذا التحليل خطوة بخطوة لإساءة استخدام OAuth في Microsoft 365. وفي المحصلة، يمثل هذا النوع من الوصول المستمر تحديًا مرهقًا للمدافعين: إذ يبقى المهاجمون متخفّين دون اكتشاف، وقد يكون الطريق إلى الاستعادة الكاملة للبيانات ومعالجة التطبيقات طويلًا ومتعرجًا.

أساليب شائعة وهجمات تصيّد موافقة واقعية

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

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

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

أهم خمس تقنيات لهجمات تصيّد الموافقة التي يجب على فرق الأمن معرفتها

  1. انتحال صفة الناشر: ينشئ المهاجمون تطبيقات بأسماء تشبه أسماء موردين شرعيين، مثل "Microsoft Secure Suite" أو "HR Docs Cloud". يثق المستخدمون بالعلامات التجارية المألوفة، ما يزيد احتمال موافقتهم على الطلب. تحقّقوا دائمًا من تفاصيل الناشر وتأكدوا من المصدر.
  2. تضليل الأذونات: تُبرز التطبيقات الخبيثة غالبًا أذونات تبدو غير ضارة في شاشة الموافقة، بينما تتسلل خلفها نطاقات بصلاحيات عالية مثل "قراءة/كتابة جميع صناديق البريد" أو "وصول كامل إلى الملفات". وقد يغفل المستخدمون المدرَّبون على النظر إلى النص الغامق فقط عن المخاطر الفعلية التي يمنحونها الموافقة عليها.
  3. منح صلاحيات محدودة للتصعيد لاحقًا: يطلب بعض المهاجمين أذونات أساسية (مثل الوصول إلى ملفك الشخصي) لتجنب إثارة الشكوك. ثم يستخدمون رمز الوصول الأولي كموطئ قدم، ويحاولون لاحقًا منح موافقات أخطر عبر تصيد مرحلي أو تصعيد للامتيازات.
  4. الحركة الجانبية باستخدام رموز OAuth الدائمة: بمجرد الدخول، يستغل المهاجمون الرموز وأذونات التطبيقات للتحرك جانبيًا، والوصول إلى المجلدات المشتركة وأحداث التقويم، أو التصعيد داخل Microsoft 365. قد تمنح الرموز وصولًا "بالكاد كافيًا" للبدء، ثم يُوسَّع نطاقها أو يُجدَّد لاحقًا.
  5. تطبيقات الجهات الخارجية المخترقة: بدلًا من بناء تطبيقاتهم الخاصة، يخترق المهاجمون أحيانًا تطبيقات موردي البرمجيات المستقلين (ISV) الموثوقة، أو يعيدون توظيفها، وهي تطبيقات تملك بالفعل أذونات واسعة منحتها كثير من المستأجرين. وهذه الهجمات على سلسلة الإمداد يصعب كشفها بشكل خاص، ويمكن أن تنتشر بسرعة عبر المؤسسات.

للاطلاع على شرح تقني معمّق لآليات العمل الكامنة وكيفية تعزيز Entra ID ضد هذه الأنماط، يمكنك الاطلاع على هذا الشرح التفصيلي لإساءة استخدام موافقات OAuth. وهذه مجرد أمثلة قليلة على الطرق الإبداعية العديدة التي تعلّم بها المهاجمون تجاوز الدفاعات التقليدية والمصادقة متعددة العوامل.

كيف تعمل حملة ConsentFix خطوة بخطوة

  1. رسالة البريد الإلكتروني التصيدية الأولية: تبدأ الهجمة برسالة بريد إلكتروني مقنعة تحث المستخدم على "إصلاح مشكلة في النهج" أو "تأمين صندوق بريده". تتضمن الرسالة رابطًا مموهًا على أنه مورد رسمي من Microsoft.
  2. إعادة التوجيه إلى صفحة موافقة تطبيق خبيث: يؤدي النقر على الرابط إلى نافذة موافقة OAuth. تبدو الواجهة مألوفة وتحمل علامة تجارية وتبدو شرعية، لكن التطبيق الذي يقف خلفها يخضع لسيطرة المهاجمين، وغالبًا ما يحمل اسمًا مستنسخًا أو مضللًا.
  3. منح الموافقة وإصدار الرموز: يراجع المستخدم الأذونات المطلوبة، وغالبًا ما تُصاغ على أنها ضرورية لأغراض "الأمان" أو "الامتثال"، ثم ينقر على "قبول". يمنح ذلك المهاجم رموز الوصول ورموز التحديث الخاصة بحساب المستخدم.
  4. يحصل المهاجم على وصول دائم: باستخدام هذه الرموز، يصل المهاجمون إلى صناديق بريد Microsoft 365 والملفات والتقاويم وواجهات برمجة التطبيقات الأخرى التي تحتوي على بيانات حساسة. وتستمر الجلسة بعد تغيير كلمات المرور، وحتى بعد معظم إعادات تعيين المصادقة متعددة العوامل، إلى أن تُلغى الموافقة يدويًا.
  5. حصاد البيانات بصمت وتحقيق الربح منها: يستنزف المهاجم محتوى البريد الإلكتروني والمستندات الحساسة بهدوء، أو يبدأ حركة جانبية نحو الخدمات المتصلة. ولأن كل شيء يبدو "مصرّحًا به"، يصعب الكشف، إلا إذا كان فريقك يراقب نشاط التطبيقات غير المعتاد أو منح الموافقات الجديدة.

إذا كنت تريد معرفة الكيفية الدقيقة التي يربط بها المهاجمون هذه الخطوات معًا في Microsoft 365 باستخدام Entra ID، فاطلع على هذا الشرح التقني لهجمات موافقات OAuth.

لماذا تهم حملة ConsentFix أمان Microsoft 365 والسحابة

أظهرت حملة ConsentFix مدى السرعة والهدوء اللذين يمكن للمهاجمين بهما اختراق Microsoft 365 وGoogle Workspace وغيرها من بيئات SaaS السحابية، من خلال إساءة استخدام تدفقات OAuth المشروعة. وواجهت مؤسسات من قطاعات مختلفة وصولًا غير مصرّح به إلى البريد الإلكتروني، وتسريبات للملفات، واستمرارًا ممتدًا للحسابات، حتى بعد فرض إعادة تعيين كلمات المرور والمصادقة متعددة العوامل. وتُبرز هذه الهجمات أهمية الدفاع متعدد الطبقات: فوعي المستخدمين، ومراقبة الموافقات في الوقت الفعلي، وحوكمة التطبيقات الصارمة ليست "أمورًا مستحسنة"، بل ضرورية للوقاية من الاختراقات واسعة النطاق وفقدان البيانات في السحابة.

اكتشاف التطبيقات الخبيثة ومراقبة الموافقات غير الاعتيادية

رصد التهديدات القائمة على OAuth والاستجابة لها ليس دائمًا بالأمر السهل، فالهجوم يندمج تمامًا في حركة العمل الاعتيادية في مؤسستك. وبحلول الوقت الذي تلاحظ فيه الأثر، قد يكون التطبيق الخبيث قد كان يمتص البيانات الحساسة بصمت لأيام أو أسابيع. لهذا تكتسب استراتيجيات الكشف الاستباقي أهمية كبيرة. يحتاج فرق الأمان إلى أكثر من الضوابط الوقائية؛ فهم بحاجة إلى رؤية حقيقية لأنماط موافقات المستخدمين وسلوكيات التطبيقات، وإلى فهم ما يعنيه "الوضع الطبيعي" عبر المؤسسة بأكملها.

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

فكّر في هذا القسم باعتباره "كاميرات المراقبة" في بيئتك السحابية. فالمراقبة المستمرة والتسجيل الآلي والتنبيهات الذكية تمنحك فرصة حقيقية لتقليص مدة بقاء المهاجم داخل البيئة وتقليل الأضرار. وإذا كنت تسعى إلى أتمتة الامتثال أو تحتاج إلى ربط ذلك بإدارة المخاطر الأوسع، فإن التكامل مع أدوات مثل Microsoft Defender for Cloud يمكن أن يرفع جهودك إلى مستوى أعلى. للاطلاع على رؤى حول الحفاظ على امتثال بيئتك وأمانها من خلال الأتمتة، راجع هذا الدليل حول مراقبة الامتثال في Microsoft Defender for Cloud.

كيفية اكتشاف التطبيقات الخبيثة باستخدام الإشارات السلوكية وإشارات الموافقة

  1. مراقبة منح الموافقات غير المتوقعة: راقب موافقات OAuth الجديدة، خاصةً تلك التي تُعتمد خارج ساعات العمل المعتادة أو تصدر عن ناشرين غير معروفين. فالعدد الكبير من التطبيقات المصرّح بها حديثًا قد يكون مؤشرًا خطيرًا.
  2. تحليل أنماط استدعاء واجهات البرمجة المشبوهة: ابحث عن سلوك غير طبيعي، مثل الوصول المتكرر والسريع إلى الملفات، أو قراءة صناديق البريد بكميات كبيرة، أو الاستخدام غير المعتاد لواجهات برمجة تطبيقات المسؤول. فغالبًا ما "يفرط" المهاجمون في استخدام الأذونات مقارنةً بالتطبيقات العادية.
  3. راقب نشاط الرموز المميزة غير المعتاد: تتبّع عمليات إنشاء رموز التحديث المتكررة أو السريعة، والأنماط الغريبة في دورة حياة الرموز المميزة. فقد تسيء التطبيقات الخبيثة استخدام رموز التحديث للحفاظ على الوصول لفترة طويلة بعد الاختراق الأولي.
  4. استفد من سجلات Microsoft وDefender: استخدم منتجات أمان التطبيقات السحابية وسجلات Entra ID لحصر جميع التطبيقات المصرّح بها، وكشف التطبيقات الخطرة أو غير المعلنة (Shadow Apps) التي تجاوزت مسارات الموافقة الاعتيادية في تكنولوجيا المعلومات. وتوفر أدوات مثل Microsoft Defender for Cloud Apps الرؤية والتنبيهات بشأن السلوكيات المشبوهة للتطبيقات.
  5. اتخذ إجراءً بشأن نتائج تكنولوجيا المعلومات الموازية (Shadow IT): تنشأ كثير من الحوادث عن وصول تطبيقات غير معتمدة أو غير مُدارة. راجع مستأجرك بانتظام، وتابع اكتشافات التطبيقات الخطرة، ونظّف منح OAuth التي تتمتع بصلاحيات مفرطة. لمعرفة المزيد حول التعامل مع Shadow IT والتحكم في التطبيقات غير المصرّح بها، راجع هذا الدليل حول إدارة Shadow IT في Microsoft 365.

التحقيق في هجمات التصيد عبر الموافقات باستخدام Microsoft 365 Defender وEntra ID Protection

  1. الصيد الاستباقي للتهديدات: ابدأ بالبحث في سجلات Entra ID وتنبيهات Microsoft 365 Defender عن أحداث الموافقة الأخيرة، وإنشاء التطبيقات المشبوهة، أو أنماط تسجيل الدخول غير الطبيعية المرتبطة بتطبيقات OAuth.
  2. التحقيق المستهدف: تعمّق في سجل كل مستخدم وتطبيق، وتحقق من الأذونات التي مُنحت، ومتى، ومن قام بذلك. قارن هذا النشاط بخطوط الأساس الطبيعية وتوقيت سير العمل في المؤسسة.
  3. المعالجة: عند اكتشاف موافقة خبيثة، ألغِ فورًا رموز التطبيق ومنح الموافقة. يتيح Microsoft 365 Defender الإلغاء الجماعي، ويمكنه كذلك الإبلاغ عن جلسات خطرة إضافية. ويمنع ذلك المهاجمين من استخدام الرموز المستمرة للحفاظ على وصولهم.
  4. المراقبة المستمرة والأتمتة: أتمت التنبيهات الخاصة بالموافقات الجديدة عالية الخطورة، وطلبات موافقة المسؤول المتكررة، أو معرّفات الناشرين الخبيثة المعروفة. اضبط نهجًا آليًا للاستجابة بشكل أسرع وتقليص مدة بقاء المهاجم.
  5. دمج الامتثال وفرض النهج: استخدم Microsoft Defender for Cloud لمراقبة الامتثال بشكل مستمر إلى جانب الاستجابة للحوادث، واطّلع على مناهج حوكمة الهوية في Entra ID لضمان إمكانية فرض نهج الأمان على المدى الطويل. يضمن ذلك رصد الهجمات الفورية ومنع انحراف الإعدادات مستقبلًا أو تراكم الدَّين الهوياتي الذي قد يفتح مخاطر جديدة.

تأمين بيئتك باستخدام نهج الموافقة وقيود التطبيقات

إذا أردتَ وقف هجمات التصيّد بالموافقة (Consent Phishing) من جذورها، فعليك التوجّه مباشرةً إلى المصدر: النُّهج وإعدادات التهيئة التي تتحكم في طريقة طلب التطبيقات لموافقة المستخدمين واستلامها. ضبط هذه الضوابط يتطلب توازنًا دقيقًا؛ فالمطلوب تمكين المستخدمين من البقاء منتجين مع التكاملات الموثوقة، مع منع أي شخص من السماح، عن قصد أو عن غير قصد، بدخول “الذئب في ثوب الحمل”.

يقدّم هذا القسم خارطة طريق عملية لمسؤولي السحابة ولمديري أمن المعلومات (CISOs)، ويستعرض أبرز الأدوات التقنية المتاحة، بدءًا من تصميم نهج الموافقة والتحقق من الناشر، وصولًا إلى الإدارة الدقيقة لمدد صلاحية رموز OAuth. عند تطبيق هذه الاستراتيجيات بالشكل الصحيح، يمكن أن تقلّل المخاطر وتحدّ من الأضرار إذا تمكّن مهاجم من موطئ قدم في البيئة. والحوكمة المتسقة ضرورية، خاصةً مع تزايد عدد تكاملات SaaS وصعوبة تجاهل تقنية المعلومات الظلّية (Shadow IT).

الحوكمة لا تعني قول “لا” للابتكار، بل تعني التحكم في الوصول، وتحديد سير العمل الموثوق، وفرض الحدود التي تُبقي بيئتك سليمة مع نموّها. وإذا كنت تعمل على أطر أمنية أوسع، فإن الدروس الواردة هنا تنطبق بشكل جيد على ما هو أبعد من Microsoft 365، وتمتد إلى Power Platform وغيرها من منصات SaaS المؤسسية. لمزيد من الرؤى حول أفضل الممارسات، اطّلع على دليل حوكمة Power Platform وأمنها.

كيفية تهيئة نهج الموافقة وتقييد موافقة المستخدمين

  1. تقييد موافقة المستخدمين افتراضيًا: في Microsoft Entra ID، هيّئ الإعدادات على مستوى المستأجر بحيث لا يتمكن من الموافقة على التطبيقات عالية الخطورة إلا المسؤولون. وينبغي أن يرى المستخدمون النهائيون شاشات الموافقة للتطبيقات منخفضة الخطورة فقط، وهو ما يقلل الموافقات غير المقصودة.
  2. تفعيل سير عمل موافقة المسؤول: اشترط المراجعة والاعتماد الإداري لأي تطبيق يطلب أذونات واسعة أو حساسة. فهذا يمنع “التفويض العرضي” للتطبيقات المحفوفة بالمخاطر، ويُنشئ سجلًا رسميًا لأنشطة الموافقة.
  3. تحديد نطاق الأذونات بدقة: لا تستخدم أذونات “السماح بكل شيء” الشاملة. اقصر الموافقة على ما تتطلبه الاحتياجات التجارية فقط. فتعريفات النطاق المخصّصة تجعل من الصعب على المهاجمين التسلل بصلاحيات خطيرة.
  4. مراجعة منح الموافقات بانتظام: راجع التطبيقات التي تملك حاليًا إذنًا للوصول إلى المستأجر، خاصةً تلك التي منحها المستخدمون دون إشراف تقنية المعلومات. وألغِ الموافقات القديمة أو غير الضرورية لتقليل سطح الهجوم.
  5. الاستفادة من نهج الوصول المشروط: اقرن قيود الموافقة بنهج وصول مشروط قوي، يشمل الإنفاذ القائم على الموقع أو الجهاز أو المخاطر، لحظر اختطاف الجلسات أو الوصول من أجهزة غير مُدارة.

للحصول على نصائح تفصيلية وقابلة للتطبيق حول تعزيز Entra ID والحد من تدفقات الموافقة الخطرة، اطّلع على هذا الشرح الشامل.

فرض التحقق من الناشر وتقييد الوصول إلى تطبيقات الطرف الأول

  1. اشتراط التحقق من الناشر: اسمح فقط للتطبيقات الصادرة عن ناشرين موثَّقين بطلب موافقة المستخدم أو المسؤول في بيئتك. فهذا يضمن أن مطوّري التطبيقات قد تحققوا من هويتهم، ويضيف طبقة ثقة إضافية تحجب معظم هجمات الانتحال الصريح.
  2. حظر الناشرين غير الموثَّقين: في Entra ID والمنصات الأخرى، اضبط نهجًا أساسيًا يرفض تلقائيًا طلبات الموافقة للتطبيقات التي لا تستوفي معايير التحقق من الناشر. وراجع حالة الناشر بانتظام لجميع التطبيقات الحالية والجديدة.
  3. تقييد الموافقة على تطبيقات الطرف الأول الموثوقة: شدّد الإعدادات بحيث لا يمكن إلا لتطبيقات الطرف الأول (مثل تطبيقات Microsoft الرسمية) أو لتطبيقات الطرف الثالث المعتمدة تحديدًا أن تطلب موافقات جديدة. وهذا يقلل بشكل كبير خطر الحركة الجانبية من تطبيق مخترق إلى آخر.
  4. تدقيق جرد الناشرين والتطبيقات: اجعل حالة الناشر وجرد التطبيقات بندًا ثابتًا ضمن دورات المراجعة الأمنية المنتظمة لدى تقنية المعلومات، مع استخدام أدوات آلية لإبراز أي ناشرين جدد أو غير معتمدين.
  5. التطبيق على جميع المنصات المتصلة: وسّع نطاق التحقق من الناشر وقيود التطبيقات ليشمل Power Platform وتطبيقات Teams وتطبيقات SaaS المتصلة. تعرّف على المزيد حول تطبيق ذلك على نطاق أوسع في دليل حوكمة Power Platform هذا.

إدارة مدد صلاحية الرموز وتطبيق المراقبة المستمرة لأمان OAuth

تؤدي إعدادات عمر رمز OAuth المميز الأقصر إلى تقليص الفترة الزمنية التي يملكها المهاجم لاستغلال الرموز المسروقة أو الرموز التي تمت الموافقة عليها. اضبط نهج انتهاء صلاحية الرموز بحيث تنتهي صلاحية رموز الوصول بسرعة، ويُعاد تدوير رموز التحديث بشكل دوري. طبّق ربط الرموز المميزة (Token Binding) والإبطال القائم على المخاطر لقطع الجلسات المشبوهة أو التي أُسيء استخدامها. ادمج ذلك مع المراقبة المستمرة لاستخدام الرموز المميزة وأحداث الموافقة لرصد الأنماط غير المعتادة، مع الاستعانة بأدوات مثل Microsoft Defender for Office 365 ونهج الوصول المشروط في Entra، وذلك لضمان ألا تتحول الرموز المخترقة إلى تهديدات مستمرة وصامتة. للاطلاع على إعدادات عملية واستراتيجيات المراقبة المستمرة، راجع توصيات Microsoft الأمنية هذه.

تعزيز الحوكمة وبناء وعي المستخدمين لمواجهة التصيد عبر الموافقات

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

يتناول هذا القسم التفاصيل الدقيقة لبناء إطار حوكمة OAuth وتدقيق منح التطبيقات القائمة، والاستراتيجيات العملية للتدريب التي تساعد المستخدمين على التعرف على مطالبات الموافقة المشبوهة، وكيفية إعداد سير العمل الذي يضع عوائق فعلية أمام المهاجمين في طريقهم إلى بياناتك. الهدف هو ضمان ألا تتوقف دفاعاتك عند أبواب قسم تقنية المعلومات، بل أن تمتد إلى مختلف أرجاء المؤسسة.

بالنسبة للمؤسسات ذات منظومات التطبيقات المعقدة، تكون المخاطر أعلى بكثير، إذ قد تنتشر أخطاء أي حلقة في سلسلة التوريد إلى خارجها. الحوكمة الاستباقية والمستمرة والتوعية ضرورية للحفاظ على أمن البيانات الحساسة والالتزام بالامتثال، حتى مع نمو قاعدة المستخدمين وقائمة التطبيقات باستمرار. للاطلاع على إرشادات حوكمة متقدمة، تشمل DLP والتدقيق المتقدم في بيئات Microsoft، راجع دليل حوكمة Copilot المتعمق هذا والتفاصيل المتعلقة بتدقيق نشاط المستخدمين باستخدام Microsoft Purview Audit.

بناء إطار حوكمة OAuth وتدقيق المنح القائمة

  1. تحديد نهج الموافقة واستخدام التطبيقات: ضع قواعد واضحة تحدد المستخدمين والتطبيقات المسموح لهم بطلب الموافقة، مع توضيح أنواع الأذونات المسموح بها وحالات الاستخدام التجاري. انشر هذه الإرشادات بحيث يعرف الجميع في مؤسستك القواعد المعمول بها.
  2. الحفاظ على قائمة كاملة بالتطبيقات: سجّل جميع التطبيقات المرتبطة بـ OAuth في Entra ID، مع توثيق من منح كل موافقة، والناشر، والنطاقات المطلوبة، والمبرر التجاري. يمكن للاكتشاف الآلي باستخدام واجهات Entra البرمجية أو Microsoft Defender أن يسرّع هذه العملية ويكشف التطبيقات الخفية غير المعتمدة.
  3. إجراء عمليات تدقيق دورية للمنح: جدوِل مراجعات ربع سنوية أو نصف سنوية لرصد الأذونات القديمة أو المكررة أو الخطرة. تحقّق من حالة التحقق من ناشر كل تطبيق، وأزل المنح الخاصة بالتطبيقات التي لم تعد قيد الاستخدام أو التي أصبحت مشبوهة.
  4. مراقبة الانحرافات ومعالجتها: اضبط التنبيهات لمخالفات النهج، مثل منح المستخدمين أذونات واسعة لناشرين غير معتمدين، ونفّذ حملات معالجة فور اكتشاف أي ثغرات. تُبقي عمليات التدقيق المنتظمة دفاعاتك مرنة ومنظومة تطبيقاتك سليمة.
  5. دمج الحوكمة مع الامتثال وDLP: في البيئات عالية المخاطر أو الخاضعة للتنظيم، اربط حوكمة OAuth بسياسات DLP وتسجيل التدقيق في Microsoft Purview. راجع دليل حوكمة Purview هذا للاطلاع على طرق عملية لمراقبة نشاط المستخدمين وحدود الموصلات على نطاق واسع.

تعزيز التدريب على الوعي وسير عمل اعتماد التطبيقات

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

توصيات النظافة البرمجية من جانب المطوّر وأمن التطبيقات للشركات المطوّرة للبرمجيات المستقلة ومسؤولي أمن المعلومات

  • التحقق من الناشر: سجّل الناشرين وتحقّق من هويتهم لزيادة شفافية التطبيقات وثقة مشتري المؤسسات بها.
  • أذونات واضحة وبالحد الأدنى: اطلب الحد الأدنى من النطاقات اللازمة للوظيفة فقط، وتجنّب طلبات الأذونات المبالغ فيها التي تثير شكوك المستخدمين وتعرّض التطبيق للرفض.
  • تدفقات موافقة آمنة: صمّم صفحات الموافقة بتسمية صادقة للتطبيق، وأوصاف واضحة، وبيانات صريحة للغرض، لمنع الالتباس لدى المستخدمين والموافقة غير المقصودة.
  • تطبيق ممارسات التطوير الآمن: حدّث مكونات التطبيق بانتظام، ونفّذ خطوط اختبار أمني لمنع الثغرات في سلسلة التوريد.
  • توجيهات النهج لمسؤول أمن المعلومات: اشترط مراجعات أمنية داخلية للتطبيقات، واحتفظ بجرد حيّ للتطبيقات، وقنّن المواقف المؤسسية من مخاطر الناشرين الخارجيين قبل اعتماد أي تكامل جديد.

استمع أيضًا إلى هذه الحلقات

إذا كنت تستكشف تصيّد الموافقة في Microsoft 365، فإن هذه الحلقات تضيف سياقًا عمليًا حول التبني الآمن لـ Microsoft 365 وحماية البيانات والحوكمة وإدارة مخاطر الذكاء الاصطناعي.

تساعد هذه الحلقات على تحويل مفاهيم المقال إلى قرارات عملية في التصميم والنشر.

Entities in this article

Phishing Microsoft 365 Multifactor authentication (MFA) Microsoft Entra ID Fabric workspace Lateral movement Microsoft Publisher

Related articles

RSS