مراجعة OAuth Consent في Entra: كيف تعرف الصلاحيات الممنوحة فعلًا بدل الاكتفاء بصورة API Permissions؟

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

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

خذ المسألة من المورد، مو من شاشة الموافقة

قبل قراءة الأذونات، حدد المورد الذي يفترض أن التطبيق يستخدمه. هل يتعامل مع واجهة دليل، أم ملفات، أم خدمة إدارة أجهزة، أم واجهة داخلية صممتها المؤسسة؟ اسم الإذن وحده ما يكفي؛ القيمة نفسها قد تظهر ضمن تعريف مورد مختلف وله سلوك تفويض مختلف.

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

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

أربع طبقات لازم تبقى منفصلة

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

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

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

الوصول المفوض يحتاج المستخدم والتطبيق

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

Delegated Permissions
Scopes

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

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

الوصول باسم التطبيق له هوية مستقلة

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

Application Permissions
App-only Access

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

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

اقرأ سجل المنح المفوض كعلاقة بين طرفين

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

oAuth2PermissionGrant
clientId
resourceId
scope

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

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

موافقة مستخدم واحد تختلف عن موافقة الجميع

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

Principal
AllPrincipals
principalId
consentType

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

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

تعيين دور تطبيق ليس دائمًا منحًا لتطبيق عميل

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

appRoleAssignment
principalType
appRoleId

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

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

سياسة الموافقة تمنع الجديد، لكنها ما تمسح القديم تلقائيًا

من الممكن تقييد موافقات المستخدمين الجديدة وفق إعداد المؤسسة. لكن نتيجة المراجعة لا تنتهي عند قراءة هذا الإعداد؛ راجع أيضًا المنح الموجودة قبل التقييد. تغيير سياسة المستقبل لا يعني أن كل الموافقات السابقة اختفت أو أن التطبيقات الموجودة توقف استخدامها.

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

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

ناشر موثق ما يساوي صلاحيات مناسبة

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

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

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

تمرين عملي يختبر قدرتك على تفسير البيانات

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

حدد أي صف يخص العميل المقصود، واربط معرف المورد بتعريفه، ثم افصل النطاقات واكتب لمن تنطبق الموافقة. بعدها قارن ذلك بقائمة الأذونات المطلوبة. المفاجأة التعليمية أن القائمتين قد لا تتطابقان، وأن اختلافهما ما يثبت ثغرة وحده قبل فهم تاريخ الطلب والمنح.

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

إذا راجعت رمزًا، احمِ القيمة وفسر السياق

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

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

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

من القائمة الطويلة إلى نتيجة قابلة للفحص

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

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

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

أخطاء تخليك تضخم الأثر أو تفوته

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

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

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

مصادر رسمية تكمل قراءة الحقول

تعريفات الحقول ونماذج الوصول موجودة هنا، أما خطة المقارنة والتمرين فهي أمثلة تعليمية مستقلة:

Permissions and consent overview
https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview

oAuth2PermissionGrant
https://learn.microsoft.com/en-us/graph/api/resources/oauth2permissiongrant?view=graph-rest-1.0

appRoleAssignment
https://learn.microsoft.com/en-us/graph/api/resources/approleassignment?view=graph-rest-1.0

User and admin consent
https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/user-admin-consent-overview

وقبل تقييم من يستطيع تغيير هوية العميل، ارجع لشرح الفرق بين تسجيل التطبيق ومثيله المحلي:
https://courses.cyberpts.com/community/151/akhtbar-ttbyqat-entra-alfrq-byn-app-registration-wservice-principal-wlysh-mlkyh-

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