إتقان فجوة الموافقة في Microsoft Graph: ما تغفله الدروس التعليمية

By Mirko Peters · 2026-08-11

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

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

مرحبًا بكم في الدليل المصاحب للبودكاست! إذا سبق لك إعداد مهمة خلفية، ومنح الموافقة الإدارية، ثم أملت خيرًا، فأنت بالتأكيد لست وحدك. يسير كثير من المطورين والمسؤولين عبر الدروس القياسية، ويهيئون خدماتهم الخلفية، ويفترضون أنه بمجرد أن يعمل الكود تكون مهمة الأمان قد انتهت. غير أن هناك فجوة كبيرة بين تشغيل التكامل في بيئة اختبار والحفاظ على أمانه وموثوقيته وقابليته للتدقيق في بيئة الإنتاج. في هذه المقالة نتوسع في المخاطر الخفية للوصول بصلاحيات التطبيق فقط، حيث تُطبَّق الأذونات على مستوى المستأجر دون سياق مستخدم، وفي سبب قدرة الموافقة لمرة واحدة على التأثير في وضعك الأمني على المدى الطويل، وفي كيفية أن تتسبب تغييرات النهج في تعطيل المهام الخلفية غير المراقبة دون أن تلاحظ. وللتعمق أكثر في هذا الموضوع، لا تفوت الاستماع إلى حلقة البودكاست ذات الصلة: Microsoft Graph App-Only Consent Explained.

لمن هذا الدليل

• مسؤولو Azure AD / Entra ID ومهندسو الأمان
• مالكو منصة M365 ومسؤولو SharePoint وExchange وTeams
• المطورون الذين يبنون خدمات تعمل دون تدخل بشري، مثل Azure Functions وLogic Apps أو التكاملات
• فرق الامتثال والتدقيق والحوكمة

فجوة الموافقة (ما تتجاهله الدروس التعليمية)

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

أقل الصلاحيات أولًا (اختيار الأذونات)

• فضّل نطاقات موارد ضيقة على *.ReadWrite.All كلما أمكن ذلك.
• أمثلة تستحق التدقيق:
  • الدليل: فضّل User.Read.All (الملف الشخصي الأساسي) قبل Directory.Read.All.
  • SharePoint: جرّب أنماط الوصول المقتصرة على المواقع أو كتالوجات التطبيقات قبل Sites.ReadWrite.All.
  • البريد والتقاويم: استخدم Mail.Read / Calendars.Read ما لم تكن الكتابة ضرورية فعلًا.
• لا تُجرِ "تهيئة للمستقبل" بتوسيع النطاقات أكثر من اللازم. أضف النطاقات فقط عندما تتطلبها ميزة بعينها.

تسجيل التطبيق بالطريقة الصحيحة (خطوة بخطوة)

1. سجّل التطبيق في Entra ID ← دوّن معرّف التطبيق (العميل) ومعرّف المستأجر.
2. المصادقة: اختر طريقة بيانات اعتماد العميل:
   • الشهادة (موصى بها) تُخزَّن وتُدوَّر عبر Key Vault، أو
   • الكلمة السرية للعميل (عمر قصير + نهج تدوير)، أو
   • الهوية المُدارة (الأفضل في أحمال العمل المستضافة على Azure).
3. أذونات واجهة برمجة التطبيقات ← علامة التبويب Application ← أضف أدنى نطاقات Graph ممكنة فقط.
4. امنح الموافقة الإدارية بقصد ووعي (وثّق من ومَن ولماذا ومتى).
5. تطبيقات المؤسسة: أحكم إعداد التعيين مطلوب والمالكين وتسجيل تسجيل الدخول والتدقيق.

الموافقة الإدارية والنهج والضوابط

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

الرموز المميزة في الواقع (كيف يفشل المصادقة فعليًا)

• الأعطال الشائعة: انتهاء صلاحية الأسرار أو الشهادات، والمورد الخاطئ (نطاق .default)، والدور المفقود، وعدم تطابق المستأجر.
• تقوية تدفق الرموز:
  • استخدم بيانات اعتماد بشهادات أو الهوية المُدارة بدلًا من الأسرار طويلة الأمد.
  • دوّر الأسرار والشهادات قبل انتهائها بوقت كافٍ (تذكيرات Key Vault + أتمتة).
  • أعد المحاولة مع التراجع التدريجي وأظهر قياسات الأخطاء 401/403 مع معرّفات الترابط.
  • خزّن الرموز مؤقتًا لكل تشغيل، لكن لا تُعِد استخدامها أبدًا عبر المستأجرين أو بعد تجاوز أعمارها الآمنة.

المراقبة والتدقيق (اجعله جاهزًا للتدقيق)

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

أنماط الأذونات الأدنى (المصفوفة الأساسية)

• جرد المستخدمين والتقارير ← User.Read.All
• تحليلات استخدام Teams ← Reports.Read.All
• تصدير صندوق البريد للقراءة فقط ← Mail.Read
• مزامنة التقويم (قراءة) ← Calendars.Read
• قراءة SharePoint (نطاق واسع) ← Sites.Read.All (تجنّب ReadWrite إلا عند الضرورة القصوى)
• مزامنة الملفات الشخصية مع الموارد البشرية ← User.Read.All (+ نطاقات كتابة محددة فقط إذا كانت مطلوبة فعلاً)

قاعدة عامة: إذا انتهى النطاق بـ .ReadWrite.All، فتوقّف وأعد التقييم. وإن كان لا بد منه، فاعزل التطبيق ووثّق المبرر وأضف مراقبة إضافية.

الأخطاء الشائعة والحلول السريعة

• invalid_client / invalid_grant ← انتهاء صلاحية الكلمة السرية أو الشهادة؛ قم بتدويرها في Key Vault ثم أعد النشر.
• insufficient privileges to complete the operation ← نقص في أذونات التطبيق، أو عدم منح موافقة المسؤول في هذا المستأجر.
• خطأ 403 على SharePoint مع تطبيق يعمل بالتطبيق فقط ← النطاق أوسع من اللازم، أو أن الوصول على مستوى الموقع غير متوافق؛ تحقق من أذونات الموقع ونهج كتالوج التطبيقات.
• أخطاء 401 متقطعة ← تغيير في الوصول المشروط أو في نهج الموافقة؛ راجع سجلات تسجيل الدخول والتدقيق لمبدأ الخدمة.

ضوابط الأمان والامتثال

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

الأسئلة المتداولة السريعة

• هل تورث أذونات التطبيق فقط قوائم التحكم بالوصول (ACL) الخاصة بالمستخدم؟ لا، فالتطبيق بالصلاحيات فقط يعمل بشكل مستقل عن سياق المستخدم.
• هل يمكن للمستخدم العادي منح نطاقات التطبيق فقط؟ لا، إذ تُشترط موافقة المسؤول.
• هل تنتهي الرموز تلقائياً عند سحب الوصول؟ تنتهي صلاحية الرموز بسرعة، لكن الأذونات الممنوحة تبقى سارية حتى يتم سحبها.
• ما أفضل خيار للمصادقة؟ الهوية المُدارة (في Azure) أو الشهادات مع Key Vault، وتجنّب الكلمات السرية طويلة الأمد.

خطة العمل (سبرنت تعزيز الأمان لمدة 90 دقيقة)

1. الجرد: تطبيقات المؤسسة وأذونات تطبيقات Graph.
2. ضع علامة على تطبيقات *.ReadWrite.All وDirectory.* لمراجعتها.
3. دوّر أي كلمة سرية تنتهي خلال أقل من 30 يوماً، وانتقل إلى الشهادة أو الهوية المُدارة حيثما أمكن.
4. فعّل التنبيهات لتغييرات الموافقة وانتهاء صلاحية Key Vault.
5. اكتب ورقة من صفحة واحدة لكل تطبيق: الغرض، والبيانات المتأثرة، والنطاقات، والمالك، وتاريخ التدوير.
6. جدوِل مراجعة فصلية مع فريق SecOps ومالكي التطبيقات.

الخاتمة

تأمين تكاملات Microsoft Graph ليس مهمة إعداد تُنجز مرة واحدة. فبفهم الآثار الحقيقية لفجوة الموافقة، واعتماد أنماط الأذونات الأدنى، والابتعاد عن الكلمات السرية الهشة للعملاء، وإرساء روتين مراقبة صارم، يمكنك رفع مستوى وضعية أمان المستأجر بشكل كبير. لا تترك مهامك الخلفية عرضة للإخفاقات الصامتة أو لتوسّع الوصول دون رقابة. خصص وقتاً اليوم لتنفيذ سبرنت التعزيز لمدة 90 دقيقة ومراجعة تطبيقات مؤسستك. وللاطلاع على شرح شامل لهذه المفاهيم ونقاش أعمق حول إتقان الوصول بالتطبيق فقط، لا تفُتْك الحلقة البودكاست المرتبطة: Microsoft Graph App-Only Consent Explained.