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

المدونة · Mirko Peters

الأذونات المفوّضة مقابل أذونات التطبيقات

By · · Updated

قارن بين الأذونات المفوّضة وأذونات التطبيقات في Microsoft Entra ID، واختر نموذج الوصول المناسب للواجهات البرمجية الآمنة، والأتمتة، وتطوير التطبيقات.

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

Cover: Stop OAuth Consent Attacks in Microsoft Entra ID

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

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

الخلفية والمقدمة: نماذج الأذونات في هوية Microsoft

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

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

أذونات التطبيقات مقابل الأذونات المفوّضة: المفاهيم الأساسية والسيناريوهات الواقعية

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

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

مع أذونات التطبيقات، يقوم التطبيق نفسه بالمصادقة بوصفه هويته الخاصة (مبدأ خدمة Service principal)، ويحصل على رمز (token) خاص به. وهذا هو النموذج الذي يدعم الأتمتة والمهام الخلفية، مثل تكامل النظم الذي يزامن البيانات بين SharePoint ونظام إدارة علاقات العملاء (CRM) لديكم ليلاً. لا يتطلب ذلك أي تفاعل من المستخدم؛ إذ يُنفّذ التطبيق المهام وفق جدوله الزمني ومستوى وصوله الخاص، وذلك بما يوافق عليه المسؤول.

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

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

داخل أذونات Microsoft Entra المفوّضة: تدفق المصادقة والقيود

تبدأ الأذونات المفوَّضة في Microsoft Entra ID بتدفق مصادقة كلاسيكي يقوده المستخدم. يبدأ التدفق عندما يسجّل المستخدم الدخول إلى تطبيقك باستخدام بيانات اعتماده في Microsoft. عند هذه النقطة، يطلب التطبيق أذونات محددة، أو نطاقات (Scopes)، ويُظهر للمستخدم (وأحياناً للمسؤول) بدقة نوع البيانات أو الإجراءات التي يريد الوصول إليها.

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

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

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

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

الإفراط في منح الأذونات لتطبيقات الوصول وأمان الرموز في Microsoft Entra ID

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

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

لا يقتصر الحديث على الإفراط في منح الأذونات. فالرموز وبيانات الاعتماد، بما في ذلك الأسرار السرية للعميل والشهادات، قد تتحول إلى كنز ثمين للمهاجمين إذا لم تُؤمَّن. ويكفي أن يتسرب سر عميل من تسجيل تطبيق يعمل بالتطبيق فقط حتى يتمكن المهاجم من انتحال هوية خدمتك. لذلك تُعدّ نظافة بيانات الاعتماد ضرورية: استخدم الهويات المُدارة كلما أمكن، ودوّر الأسرار السرية بانتظام، ولا تخزّن بيانات اعتماد العميل في الشيفرة البرمجية أو في ملفات غير محمية أبداً. أما في البيئات التي تعتمد على الوصول غير البشري، ففكّر في Microsoft Entra Workload Identities، التي تتيح وصولاً قابلاً للتدقيق دون أسرار، وتُنهي متاعب حسابات الخدمة القديمة. وللاطلاع على تحليل أعمق، راجع هذا المقال حول سبب كون هويات أحمال العمل ضرورية لنهج Zero Trust.

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

الضوابط وأفضل الممارسات لإدارة الأذونات المفوَّضة وأذونات التطبيقات

  • تطبيق ضوابط Entra المدمجة لإدارة الأذوناتاستفد من سير عمل الموافقة المدمجة في Microsoft Entra وعمليات موافقة المسؤول والنهج الدقيقة لتقييد المستخدمين أو المجموعات الذين يمكنهم منح الأذونات. استخدم نهج موافقة المسؤول لضمان أن التطبيقات المُدقَّقة فقط هي التي تحصل على النطاقات عالية المخاطر.
  • فرض مبدأ الحد الأدنى من الامتيازاتامنح التطبيقات الحد الأدنى من الأذونات اللازمة لوظيفتها فقط. راجع كل إذن يُطلب أثناء تسجيل التطبيق، وأزل أي إذن غير ضروري. يُعد الحد الأدنى من الامتيازات أقوى دفاع لديك ضد إساءة الاستخدام والتجاوز.
  • جدولة مراجعات الأذونات وعمليات التدقيق بانتظامأعدّ مراجعات وصول دورية، باستخدام لوحات الأذونات والموافقات في Entra، لتحديد الأذونات غير المستخدمة أو الخطرة وإلغائها. أتمتة هذه الفحوصات كلما أمكن ذلك لتحقيق حوكمة قابلة للتوسع، كما هو موضح في أدلة الحوكمة المتقدمة مثل استراتيجية Microsoft Purview هذه.
  • مراقبة تغييرات الأذونات والتنبيه إليهاأنشئ آليات مراقبة وتنبيه لرصد منح OAuth الجديدة، والارتفاعات المفاجئة في استخدام أذونات التطبيقات، أو عمليات الدمج الإدارية غير المتوقعة. يمنحك الإبلاغ الاستباقي وقتاً للاستجابة قبل أن تتفاقم المشكلات الأمنية.
  • تأمين تخزين الرموز المميزة وبيانات الاعتمادخزّن الأسرار الخاصة بالعملاء والرموز المميزة في مخازن آمنة مثل Azure Key Vault. دوّر بيانات الاعتماد بانتظام، وفضّل الشهادات على الأسرار المشتركة، وفضّل هويات أعباء العمل عند دمج الوصول غير البشري، لأنها توفر إدارة أفضل لدورة الحياة وقابلية تدقيق أعلى.
  • اعتماد الحوكمة المتقدمة وأتمتة السياساتاستخدم أدوات مثل Microsoft Purview وAzure Policy لفرض ضوابط على مستوى المستأجر، وتقسيم المخاطر باستخدام Data Loss Prevention، والتصميم من أجل الامتثال المستمر. للاطلاع على نظرة عملية حول استخدام النهج للحوكمة منذ التصميم، راجع استراتيجية الحوكمة المؤسسية في Azure.

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

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

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

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

Entities in this article

Microsoft Entra ID Microsoft Entra Governance Microsoft Automation Microsoft To Do Client secret Microsoft Entra Workload ID Microsoft Purview Zero Trust

Related articles

RSS