الأذونات المفوّضة مقابل أذونات التطبيق: اختيار النموذج المناسب لتطبيقك

By Mirko Peters · 2026-08-11

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

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

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

لتوضيح هذا الموضوع المعقّد بمزيد من التفصيل، سجّلنا مؤخراً حلقة متعمّقة. تأكد من الاستماع إلى النقاش الصوتي الكامل عبر Microsoft Graph Permissions and Consent Models Explained. في منشور المدونة المرافق هذا، سنتوسع في هذه المفاهيم، ونبحث الفروق الجوهرية بين الأذونات المفوّضة وأذونات التطبيق، ونستعرض نماذج الموافقة، ونتناول أفضل الممارسات، ونقدّم إطاراً شاملاً يضمن بقاء تطبيقاتك آمنة ومتوافقة مع المتطلبات التنظيمية.

نظرة عامة على أذونات Microsoft Graph API

قبل الخوض في تفاصيل تدفقات التفويض المحددة، من المفيد أن تفهم ماهية أذونات Microsoft Graph API فعلياً. فجوهرياً، تعمل Microsoft Graph كبوابة موحّدة للوصول إلى البيانات الموجودة في خدمات Microsoft 365 المختلفة، ومنها Exchange Online وSharePoint وMicrosoft Teams وOneDrive وAzure Active Directory (Microsoft Entra ID). وبدلاً من إجبار المطورين على المصادقة أمام نقاط نهاية منفصلة متعددة، توفّر Microsoft Graph نقطة نهاية واحدة لواجهة REST. غير أنه، نظراً لأن هذه الواجهة تفتح الوصول إلى كل زاوية تقريباً من الأصول الرقمية للمؤسسة، فإن تأمينها يتطلب إطار أذونات متيناً ودقيقاً.

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

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

صُممت الأذونات المفوّضة (Delegated permissions) للتطبيقات الموجّهة للمستخدم أو التي تعمل على جهة العميل، مثل تطبيقات الويب ذات الصفحة الواحدة (single-page)، وتطبيقات الجوال، وأدوات سطح المكتب، حيث يكون المستخدم الذي سجّل الدخول حاضرًا وفاعلًا. في هذا النموذج، يعمل تطبيقك *نيابةً عن* المستخدم. ولا يستطيع التطبيق الوصول إلا إلى البيانات وتنفيذ الإجراءات التي يملك المستخدم نفسه صلاحية القيام بها. وعند تشغيل المستخدم للتطبيق، يُطلب منه تسجيل الدخول ومنح الموافقة صراحةً، فيُصدر النظام رمز وصول OAuth 2.0 يتضمن هويّة المستخدم والنطاقات (scopes) التي وافق عليها.

أما أذونات التطبيق، فتستخدمها الخدمات الخلفية، والبرامج الخفية (Daemons)، ومهام الويب، وكتب التشغيل الآلية التي تعمل بشكل مستقل عن أي سياق للمستخدم. وهنا يعمل التطبيق بهويته الخاصة، ويستخدم بيانات اعتماد العميل، مثل سرّ العميل (Client Secret) أو زوج مفاتيح الشهادة العامة/الخاصة، أو الهوية المُدارة، للحصول على رمز وصول خاص بالتطبيق من Azure AD. ولأنه لا يوجد مستخدم بشري يجلس أمام الجهاز للمصادقة، فإن هذه الأذونات تمتد إلى موارد على مستوى المستأجر بأكمله. ونتيجةً لذلك، تحمل مخاطر أمنية أعلى بكثير، وتتطلب دائماً موافقة صريحة من مسؤول المستأجر.

الفروق الرئيسية وحالات الاستخدام

إن فهم متى يُطبَّق كل نموذج أذونات يمنع الاختناقات المعمارية والثغرات الأمنية. فلنلقِ نظرة على مقارنة سريعة:

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

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

الأذونات المفوَّضة في Microsoft Graph

كيفية عمل الأذونات المفوَّضة

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

• الوصول المفوَّض يعني أن تطبيقك يتصرف مباشرةً باسم المستخدم.
• يجب أن يمتلك كل من تسجيل التطبيق والمستخدم الفردي الحقوق الأساسية المناسبة.
• تحدد النطاقات السقف الدقيق لما يمكن لتطبيقك القيام به نيابةً عن المستخدم.
• يربط رمز الوصول الناتج هوية التطبيق وسياق المستخدم معًا.

السيناريوهات الشائعة للأذونات المفوَّضة

تشغّل الأذونات المفوَّضة معظم تكاملات الإنتاجية اليومية. فعلى سبيل المثال، إذا احتاج تطبيق لتدوين الملاحظات للمؤسسات إلى مزامنة الملفات مع حساب OneDrive للمستخدم، فإنه يطلب النطاق Files.ReadWrite. وإذا لم يكن لدى المستخدم إذن للوصول إلى مستند معين، فستَرفض واجهة Graph API الطلب، حتى لو كان نطاق التطبيق يسمح به من الناحية التقنية. وبالمثل، تستفيد التطبيقات التي تستخدم Microsoft Graph SDK لإرسال إشعارات بريد إلكتروني آلية نيابةً عن المستخدم من نطاقات مفوَّضة مثل Mail.Send.

اعتبارات الأمان والموافقة

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

أذونات التطبيق في Microsoft Graph

كيفية عمل أذونات التطبيق

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

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

متى تستخدم أذونات التطبيق

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

الموافقة الإدارية وانعكاساتها الأمنية

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

إيجابيات وسلبيات أذونات Microsoft Graph API

الإيجابيات

• نموذج أذونات موحّد: إطار تفويض واحد ومتسق عبر جميع خدمات Microsoft 365 يبسّط الإدارة.
• نطاقات دقيقة: تتيح النطاقات المفوَّضة ونطاقات التطبيق الدقيقة بناء بنى تعتمد أقل الامتيازات بدقة.
• OAuth2/OpenID Connect قياسي: يعتمد على بروتوكولات أمان معيارية في الصناعة لتكامل هوية مباشر.
• تكامل RBAC: يرتبط بسلاسة بأدوار Azure AD ونُهج الوصول المشروط لتحقيق الامتثال المركزي.
• الموافقة التدريجية: يتيح للتطبيقات طلب أذونات إضافية مع مرور الوقت، بدلاً من المطالبة بكل شيء مسبقاً.

السلبيات

• التعقيد: قد يُربك التعامل مع تقاطع النطاقات المفوَّضة وأدوار التطبيقات ونماذج موافقة المسؤول المبتدئين.
• مخاطر الأذونات عالية الامتياز: قد يؤدي سوء ضبط الأذونات الواسعة (مثل Sites.FullControl.All) إلى كشف كميات هائلة من بيانات المؤسسة.
• اختناقات موافقة المسؤول: قد يؤدي اشتراط موافقة إدارية على الأذونات ذات التأثير الكبير إلى إبطاء دورات التطوير الرشيقة.
• تشتت التوثيق: غالباً ما يحتاج المطورون إلى الرجوع إلى مستودعات توثيق Microsoft متعددة لفهم السلوك الدقيق لواجهات البرمجة.

نماذج الموافقة وأفضل الممارسات

موافقة المستخدم مقابل موافقة المسؤول في Microsoft Graph

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

تأثير نُهج المستأجر على الأذونات

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

استراتيجيات لتدفق موافقة سلس

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

الأخطاء الشائعة المتعلقة بأذونات Microsoft Graph API

• الخلط بين الأذونات المفوَّضة وأذونات التطبيقات، وسوء فهم متطلبات سياق المستخدم.
• طلب أذونات مفرطة منذ البداية بدلاً من اعتماد مبدأ أقل الامتيازات.
• عدم مراعاة متطلبات موافقة المسؤول عند نشر الخدمات التي تعمل في الخلفية.
• افتراض أن تغييرات الأذونات في بوابة Azure تسري فوراً دون تحديث الرمز.
• تقديم رمز وصول مفوَّض في موضع يتطلب رمز بيانات اعتماد العميل (Client Credentials).
• تجاهل نُهج الوصول المشروط التي تحظر طلبات Graph API أثناء التشغيل.
• إغفال التحقق من مطالبات النطاقات (Scope Claims) داخل شيفرة التطبيق أثناء التشغيل.
• عدم تدقيق أذونات التطبيقات الممنوحة والمبادئ الخدمية (Service Principals) بمرور الوقت.

قائمة مراجعة أذونات Microsoft Graph API

استخدموا قائمة المراجعة العملية هذه لإرشاد فريقكم خلال تصميم أذونات Microsoft Graph API وتنفيذها وتدقيقها بأمان:

الخاتمة

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

لمزيد من الإرشادات المتخصصة والاستراتيجيات العملية والتعمق في تأمين بيئتكم السحابية، لا تفوّتوا الاستماع إلى الشرح الصوتي الكامل في الحلقة ذات الصلة: Microsoft Graph Permissions and Consent Models Explained. حافظوا على إحكام أذوناتكم، وتأمين بيانات اعتمادكم، وبرمجة سعيدة!