هل يمكن للمستخدمين العاديين الموافقة على أذونات التطبيقات في Microsoft Entra ID؟

لا. تعمل أذونات التطبيقات دون وجود مستخدم مسجَّل الدخول، ويمتد نطاقها إلى المستأجر بأكمله. لذلك، لا يمكن منح أذونات التطبيقات إلا لمسؤول يملك حقوق المستأجر المناسبة.

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

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

الأذونات المفوَّضة مقابل أذونات التطبيقات في Microsoft Entra ID: ما يحتاج المسؤولون إلى معرفته

Q: ما الخطر الأمني الرئيسي لأذونات التطبيقات؟

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

Q: كيف يتفاعل Microsoft Graph مع رموز OAuth والأذونات؟

يعمل Microsoft Graph بوصفه بوابة واجهات البرمجة لـ Microsoft 365. يجب أن يحمل كل طلب يُرسل إلى Graph رمز وصول OAuth يتضمن نطاقات محددة تحدد إما الأذونات المفوَّضة أو أذونات التطبيقات.

By Mirko Peters · 2026-10-28

تعرّف على الفروق الجوهرية بين الأذونات المفوَّضة وأذونات التطبيقات في Microsoft Entra ID، بما في ذلك أفضل الممارسات الأمنية وقواعد الحد الأدنى من الصلاحيات.

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

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

النقاط الرئيسية

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

فهم أذونات OAuth في السحابة من Microsoft

عندما تربط أداة إنتاجية خارجية أو سكربت أتمتة داخلياً بمساحة عمل Microsoft 365 الخاصة بك، فأنت تُطلق سير عمل OAuth 2.0 في الخلفية. ومع ذلك، فإن الحصول على رمز الوصول ليس سوى نصف المعركة. فالحد الأمني الحقيقي يتحدد بما يُسمح لهذا الرمز بفعله فعلاً. وفي منظومة الهوية لدى Microsoft، التي يرتكز عليها Microsoft Entra ID (المعروف سابقاً باسم Azure Active Directory)، تنقسم الأذونات إلى نوعين مختلفين جوهرياً: الأذونات المفوَّضة وأذونات التطبيقات.

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

الأذونات المفوَّضة: العمل نيابةً عن المستخدم

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

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

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

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

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

تعمل أذونات التطبيقات وفق منطق مختلف تمامًا. فهي مصممة للعمليات الخلفية التي تعمل في الخلفية (daemons)، وسكربتات المزامنة الآلية، والخدمات الخلفية التي تعمل في الساعة الثالثة فجرًا حين لا يكون أي مستخدم مسجّل الدخول. فكّر في أداة تقارير آلية تجمع البيانات من كل صندوق بريد في المؤسسة.

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

لماذا تُعد موافقة المسؤول إلزامية

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

Microsoft Graph ودور نطاقات OAuth

سواء استخدم التطبيق أذونات مفوّضة أو أذونات تطبيقات، فإنه يوجّه طلباته في نهاية المطاف عبر بوابة واحدة وقوية: Microsoft Graph. فكل محادثة في Teams، وكل مستند في SharePoint، وكل ملف في OneDrive، وكل بريد في Outlook يمكن الوصول إليه من خلال Microsoft Graph، شريطة أن يقدّم التطبيق الطالب رمز وصول OAuth صالحًا.

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

تطبيق مبدأ أقل الصلاحيات في المستأجر

تعود أفضل ممارسات الأمان في Microsoft Entra ID دائمًا إلى قاعدة ذهبية واحدة: مبدأ أقل الصلاحيات. يجب منح كل تطبيق ومبدأ خدمة (Service Principal) وكل سكربت أتمتة الحد الأدنى المطلق من الوصول اللازم لإنجاز مهمته.

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

الخاتمة

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

لمزيد من التعمق في أساسيات آلية عمل هذه المصافحات، استمع إلى الحلقة الكاملة من البودكاست للحصول على شرح مبسّط لبروتوكول OAuth 2.0، ودورات حياة الرموز، والأطراف الأربعة في كل مصافحة.

الأسئلة المتداولة

هل يستطيع المستخدمون العاديون الموافقة على أذونات التطبيقات في Microsoft Entra ID؟

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

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

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

ما الخطر الأمني الرئيسي لأذونات التطبيقات؟

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

كيف يتفاعل Microsoft Graph مع رموز OAuth والأذونات؟

تعمل Microsoft Graph كبوابة واجهات برمجة التطبيقات لـ Microsoft 365. يجب أن يتضمن كل طلب يُرسل إلى Graph رمز وصول OAuth يحمل نطاقات محددة تحدد إما الأذونات المفوَّضة أو أذونات التطبيق.