كيفية معرفة التطبيقات التي لديها إمكانية الوصول إلى Microsoft 365 الخاص بك
يمكنك رؤية كل تطبيق لديه إمكانية وصول إلى مستأجر Microsoft 365 الخاص بك من مركز إدارة Microsoft Entra، ضمن Identity → Applications → Enterprise applications → All applications. عند اختيار تطبيق وفتح علامة التبويب Permissions الخاصة به، تظهر لك بدقة البيانات التي يمكنه الوصول إليها عبر Microsoft Graph، مقسّمة إلى أذونات وافق عليها مسؤولو مؤسستك وأذونات وافق عليها مستخدمون أفراد لأنفسهم.
يغطي هذا الدليل هذا المسار بالكامل، والفرق بين موافقة المسؤول وموافقة المستخدم الذي يُربك الكثيرين، وما لا يمكن أن تكشفه لك مراجعة تطبيق واحد في كل مرة.
أين أجد قائمة التطبيقات التي لديها إمكانية وصول في Entra؟
- سجّل الدخول إلى entra.microsoft.com بحساب يحمل على الأقل دور Cloud Application Administrator أو Application Administrator.
- اذهب إلى Identity → Applications → Enterprise applications → All applications.
- اختر التطبيق الذي تريد مراجعته، ثم افتح Permissions.
يسرد هذا كل تطبيق أُضيف إلى مستأجرك عبر موافقة المستخدم أو موافقة المسؤول — بما في ذلك مساعدو الذكاء الاصطناعي، وروبوتات الاجتماعات، وإضافات الإنتاجية التي تتصل عبر منصة الهوية الخاصة بمايكروسوفت، إلى جانب تطبيقات الأعمال الأساسية. تشمل القائمة كلاً من تطبيقات مايكروسوفت الأصلية وتسجيلات الجهات الخارجية، لذا يستحق الأمر تجاوز الأسماء المألوفة لرؤية ما تراكم بهدوء من أذونات أخرى بمرور الوقت.
ما الفرق بين موافقة المسؤول وموافقة المستخدم؟
تنقسم علامة التبويب Permissions إلى قسمين:
- موافقة المسؤول (Admin consent) — أذونات يمنحها مسؤول لكامل المؤسسة. وتنطبق على كل مستخدم يشمله المنح، وليس فقط على الشخص الذي صادف أن نقر على الموافقة.
- موافقة المستخدم (User consent) — أذونات وافق عليها فرد لنفسه، شخصًا واحدًا في كل مرة، من دون تدخّل مسؤول (عندما تسمح إعدادات الموافقة في مستأجرك بذلك).
عند اختيار أي إذن مدرج، تُفتح لوحة Permission Details تصف بالضبط ما يسمح به هذا الإذن.
كيف ألغي إمكانية وصول تطبيق ما؟
بالنسبة لمنح admin consent: افتح الإذن في القائمة، واختر عنصر التحكم … المجاور له، ثم اختر Revoke permission — يعمل هذا مباشرة من داخل البوابة.
أما بالنسبة لمنح user consent، فلا توجد في البوابة زر إلغاء. يتطلب سحبه استدعاء واجهة برمجة تطبيقات Microsoft Graph (DELETE /oAuth2PermissionGrants/{id} للأذونات المفوَّضة، أو الاستدعاء المكافئ appRoleAssignments للأذونات الخاصة بالتطبيق) أو أمر PowerShell المطابق، يُنفَّذه شخص يحمل دور Cloud Application Administrator. كما أن إلغاء المنح لا يمنع المستخدم نفسه من الموافقة مجددًا في المرة التالية التي يطلب فيها التطبيق ذلك — إيقاف ذلك يتطلب تغيير سياسة الموافقة الخاصة بالمستأجر بشكل منفصل، تحت Enterprise apps → Consent and permissions → User consent settings.
ماذا يحدث عندما يصطدم المستخدم بإذن لا يمكنه منحه لنفسه؟
إذا قيّد المستأجر موافقة المستخدم، فإن الشخص الذي يحاول تسجيل الدخول إلى تطبيق يطلب إذنًا يتجاوز هذا الحد يصطدم بحائط بدلاً من الحصول على منح. يمكن لمسؤول عام (Global Administrator) تفعيل admin consent workflow من Enterprise apps → Consent and permissions → Admin consent settings، مما يتيح لذلك الشخص إرسال طلب بدلاً من ذلك: يُرسَل عبر البريد الإلكتروني إلى أي مستخدمين أو مجموعات أو أدوار محدَّدة كمراجعين، والذين يمكنهم الموافقة عليه أو حظره أو رفضه من علامة التبويب My Pending الخاصة بهم. لا يستطيع الموافقة على طلب يخص أذونات تطبيق Microsoft Graph إلا مسؤول عام — فتسمية شخص كمراجع لا تمنحه هذه الصلاحية بحد ذاتها. كما تنتهي صلاحية كل طلب بعد عدد أيام قابل للتهيئة، بحيث لا يبقى طلب لم تتم مراجعته مفتوحًا إلى أجل غير مسمى.
ماذا لو كانت مؤسستي تمتد عبر عدة مستأجرين لـMicrosoft 365 أو دليل شريك؟
المراجعة داخل مستأجر واحد تُظهر ذلك المستأجر فقط. إذا كانت مؤسستك تعمل عبر أكثر من دليل واحد لـMicrosoft 365 — شركة أم وشركة تابعة مستحوذ عليها، على سبيل المثال، أو مستأجر خاص بشريك — فإن كل واحد منها يحتاج إلى هذه الخطوات نفسها بشكل منفصل، مع تسجيل الدخول بالدور الصحيح في كل منها. الأدوات المصممة لمستأجر واحد ثابت تنهار بمجرد إضافة دليل ثانٍ إلى الصورة، لذا فإن أي أداة يُراد لها تغطية أكثر من مستأجر واحد يجب أن تدعم الموافقة من دليل أي مؤسسة بشكل مستقل، وليس فقط الدليل الذي أُعدّت عليه في البداية.
ما الذي لا يمكن أن تكشفه لك مراجعة تطبيق واحد في كل مرة، وكيف يجيب 8200.dev عن ذلك؟
المرور عبر Enterprise applications تطبيقًا تلو الآخر يُخبرك بما *يُسمح* لكل تطبيق بالوصول إليه. لكنه لا يُرتّب التطبيقات حسب مقدار المخاطرة التي تمثّلها فعليًا، ولا يُشير إلى المنح التي أصبحت قديمة، ولا يبقى ثابتًا بينما تعمل على مراجعة القائمة — فقد تصل موافقة جديدة بينما لا تزال تراجع الأخيرة. يقرأ موصل Microsoft 365 من 8200.dev بيانات Sites وFiles وDirectory وApplication registrations وUsers وسياسات أمان المستأجر وتقارير تسجيل MFA وسجلات التدقيق وتعيينات الأدوار ومنح الأذونات المفوَّضة — كل ذلك عبر نطاقات Graph للقراءة فقط — ويحوّلها إلى مخزون واحد مُحدَّث باستمرار ومصنَّف حسب المخاطر، بدلاً من قائمة تعيد فتحها يدويًا. تُشغّل نفس إمكانية الوصول للقراءة فقط أيضًا تدقيقًا شاملاً لإعدادات المستأجر جنبًا إلى جنب مع مخزون التطبيقات: حالة Security Defaults وسياسة Conditional Access، وسياسة موافقة التطبيقات، وإعدادات التعاون الخارجي، بحيث يظهر تطبيق مفرط الصلاحيات وسياسة مستأجر أُرخيت وسمحت بدخوله معًا بدلاً من ظهورهما في مراجعتين منفصلتين. يتصل بالطريقة نفسها بأي دليل عمل أو دليل مدرسي خاص بأي مؤسسة، بحيث لا تحتاج مجموعة تمتد عبر أكثر من مستأجر واحد إلى إعداد منفصل لكل واحد منها. كل نطاق هنا للقراءة فقط: لا شيء يغيّر إذنًا أو سياسة ما لم تختر المؤسسة بشكل منفصل أتمتة إجراء محدد.
راجع قائمة الموصلات الكاملة لمعرفة كيف يتناسب هذا مع Google Workspace وSlack وGitHub.
أدلة ذات صلة
- كيفية معرفة أدوات الذكاء الاصطناعي التي تملك وصولاً إلى Google Workspace الخاص بك
المسار الدقيق في لوحة تحكم Google Admin لعرض أدوات الذكاء الاصطناعي التي تملك وصول OAuth إلى Google Workspace، وما تكشفه، وما لا يمكنها إخبارك به.
- إدارة وضعية أمان SaaS: ما هي وماذا يجب أن تفحص
ماذا تفحص إدارة وضعية أمان SaaS (SSPM) فعليًا، وكيف تُراجعها يدويًا تطبيقًا تلو الآخر، ولماذا يجب أن يكون الفحص مستمرًا لا تدقيقًا لمرة واحدة.
- كيفية تدقيق تطبيقات OAuth الخارجية عبر Slack وGitHub وMicrosoft 365
شاشات الإدارة الدقيقة لمراجعة تطبيقات OAuth المصرَّح لها في Slack وGitHub وMicrosoft 365، وما يمكن أن تُظهره كل منصة وما لا يمكنها إظهاره.