كيفية تدقيق تطبيقات OAuth الخارجية عبر Slack وGitHub وMicrosoft 365

لتدقيق تطبيقات OAuth الخارجية، تحقق من قائمة التصريحات الخاصة بكل منصة على حدة: صفحة التطبيقات المثبَّتة في Slack، وسياسة تطبيقات OAuth الخاصة بمؤسستك في GitHub، وقائمة تطبيقات المؤسسة في Microsoft Entra. تُظهر كل منها جزءًا مختلفًا من نفس المشكلة الأساسية — أي التطبيقات التي يمكنها التصرف في بياناتك — ولا تُظهر أي منها البيانات الخاصة بالمنصتين الأخريين.

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

أين أرى تطبيقات OAuth المصرَّح لها في Slack؟

انتقل إلى Settings & administration → Manage apps، وهو ما يفتح Slack Marketplace مقتصرًا على مساحة عملك، ثم اختر Installed Apps أعلى الشريط الجانبي. هذا الخيار متاح في كل خطط Slack، ويسرد كل تطبيق مثبَّت مع النطاقات (scopes) التي تمت الموافقة عليها له.

في Enterprise Grid، يضيف قسم Integrations في لوحة تحكم المسؤول عرضًا على مستوى المؤسسة بالكامل يشمل كل مساحات العمل دفعة واحدة. ويعتمد هذا العرض عبر مساحات العمل على النطاق admin.apps:read، وهو مقتصر على Enterprise Grid، وحتى فيه، لا يُظهر سوى ما إذا كانت التطبيقات معتمدة أو مقيَّدة أو معلَّقة؛ ولا يكشف قائمة النطاقات الكاملة لكل تطبيق ضمن الاستدعاء نفسه. أما على مساحة عمل واحدة، فتظل صفحة Installed Apps هي المرجع الموثوق لمعرفة ما يمكن للتطبيق فعله فعليًا.

أين أرى تطبيقات OAuth المصرَّح لها في GitHub؟

انتقل إلى Settings → Third-party Access → OAuth app policy الخاصة بمؤسستك. المؤسسات الجديدة تُفعِّل افتراضيًا قيود الوصول لتطبيقات OAuth، لذا فإن هذه الصفحة هي أيضًا المكان الذي يطلب فيه الأعضاء الوصول إلى تطبيق جديد، والمكان الذي يوافق فيه المالك على الطلب أو يرفضه. لإلغاء تصريح تطبيق سبق اعتماده، اعثر عليه في القائمة نفسها واختر Deny access.

تُراجَع تطبيقات GitHub Apps (وهي آلية منفصلة عن تطبيقات OAuth الكلاسيكية، وتُستخدم في معظم عمليات التكامل الحديثة) في مكان مختلف: Settings → Integrations → GitHub Apps (أو Installed GitHub Apps) الخاصة بالمؤسسة، وتسرد ما هو مثبَّت وأي المستودعات التي يمكن لكل تطبيق الوصول إليها.

اعتبارًا من عام 2026، يمكن للمؤسسة أيضًا وضع ضوابط متدرجة تحدد من يُسمح له أصلًا بـ*طلب* تطبيق جديد، من خلال Settings → Third-party Access: يمكن السماح لكل من الأعضاء والمتعاونين الخارجيين بطلب التطبيقات (الإعداد الافتراضي المعتمد منذ زمن طويل)، أو حظر المتعاونين الخارجيين مع بقاء الأعضاء قادرين على الطلب، أو منع كلتا الفئتين من طلب أي تطبيق على الإطلاق — مما يضيّق نطاق التدقيق قبل أن يصل أي طلب إلى قائمة انتظار المالك أصلًا. كما يمكن إيقاف قيد الوصول الخاص بتطبيقات OAuth على مستوى المؤسسة بالكامل، وهو ما يُلغي خطوة الموافقة لكل عضو — وهو إعداد يستحق التأكد من أنه لا يزال مفعّلًا قبل الوثوق بأن قائمة سياسة تطبيقات OAuth تمثل سجلًا كاملًا لما تم التصريح به.

أين أرى تطبيقات OAuth المصرَّح لها في Microsoft 365؟

سجّل الدخول إلى مركز إدارة Microsoft Entra وانتقل إلى Identity → Applications → Enterprise applications → All applications. اختر تطبيقًا، ثم Permissions. يُظهر تبويب Admin consent الأذونات الممنوحة على مستوى المستأجر بأكمله — ويمكن إلغاؤها مباشرة من هناك. أما تبويب User consent فيُظهر ما وافق عليه المستخدمون كلٌّ لنفسه — ولا توفر البوابة زر إلغاء له؛ فاستعادته تتطلب استدعاء واجهة برمجة Microsoft Graph أو تشغيل أمر PowerShell من قبل شخص يحمل دور Cloud Application Administrator. وإذا كان المستأجر يحظر موافقة المستخدم كليًا، يمكن لمسؤول عام (Global Administrator) تفعيل سير عمل لموافقة المسؤول بدلًا من ذلك، بحيث يتحول الطلب المحظور إلى طلب قابل للمراجعة بدلًا من أن يصل إلى طريق مسدود — راجع دليل الوصول إلى Microsoft 365 لمعرفة كيفية عمل قائمة انتظار المراجعة تلك بالتفصيل.

لماذا يصعب مواكبة التدقيق الخاص بكل منصة على حدة؟

ثلاث وحدات تحكم، وثلاثة تنسيقات، وثلاثة أدوار إدارية مختلفة يلزم امتلاكها لمجرد فتحها. فالعرض البرمجي على مستوى المؤسسة في Slack يتطلب Enterprise Grid؛ والتصريحات على مستوى المستخدم في Microsoft تحتاج إلى PowerShell أو Graph، لا إلى نقرة في البوابة؛ وGitHub يفصل بين تطبيقات OAuth الكلاسيكية وتطبيقات GitHub Apps كقائمتين مختلفتين يجب أن يعرف المسؤول ضرورة مراجعتهما كلٍّ على حدة. كما يقسّم Slack عرض التطبيقات المثبَّتة الخاص به إلى تبويبات Approved وRestricted وRequests، بحيث تتطلب المراجعة الكاملة فحص ثلاثة مرشِّحات فوق المنصات الثلاث. ولا تُرتِّب أي من المنصات الثلاث التطبيقات حسب درجة الخطورة، ولا تخبرك أي منها إن كان المورّد نفسه متصلًا أيضًا بالمنصتين الأخريين بمجموعة أذونات أوسع هناك.

ما الذي لا يمكن لقائمة كل منصة على حدة إخبارك به، وكيف يجيب 8200.dev عن ذلك

تخبرك كل وحدة تحكم بما هو مصرَّح به على تلك المنصة الواحدة فقط. ولا تخبرك أي منها بالصورة المجمَّعة — كأن يكون تطبيق تدوين ملاحظات بالذكاء الاصطناعي نفسه متصلًا بقنوات Slack، ومستودع GitHub، وصندوق بريد Microsoft 365، لكل منها نطاق صلاحيات مُمنوح بشكل منفصل. تقرأ ميزة Agent Guard من 8200.dev المنصات الثلاث جميعها بنطاقات صلاحيات محدودة للقراءة فقط ومبنية على مبدأ الحد الأدنى من الامتيازات — نطاقات Slack مثل channels:read وgroups:read وfiles:read وusers:read وما يتصل بها من نطاقات قراءة إضافةً إلى تدقيق لإعدادات مساحة العمل؛ ونطاقات GitHub مثل read:org، وصلاحية وصول للقراءة فقط للمستودعات، وread:user، وجرد التثبيتات، ورؤية للقراءة فقط لفوترة Copilot، وread:audit_log؛ ونطاقات Microsoft 365 مثل Sites.Read.All وFiles.Read.All وDirectory.Read.All وApplication.Read.All وUser.Read.All وPolicy.Read.All وReports.Read.All وAuditLog.Read.All وRoleManagement.Read.Directory وDelegatedPermissionGrant.Read.All — وتضع كل نتيجة من هذه المنصات الثلاث في مخزون واحد مُصنَّف حسب درجة الخطورة. يعمل موصل Microsoft 365 مع دليل العمل أو المؤسسة التعليمية الخاص بأي مؤسسة، وليس مع مستأجر واحد ثابت، لذا فهو يتصل بالطريقة نفسها سواء كانت مؤسستك الوحيدة في الصورة أو واحدة من عدة مؤسسات.

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

راجع صفحات موصلات Slack وGitHub وMicrosoft 365 للاطلاع على قائمة النطاقات الكاملة وما يفحصه كل منها.