2025-08-11

شرح أذونات Microsoft Graph ونماذج الموافقة

تفشل معظم التطبيقات المعتمدة على Microsoft Graph عند الإطلاق لا بسبب الشيفرة البرمجية، بل بسبب الموافقة. تسمح بيئات التطوير باختبارات واسعة، بينما تفرض بيئات الإنتاج سياسات صارمة تمنع النطاقات عالية المخاطر. والحل هو فهم نموذجي Graph: المفوَّض (Delegated) الذي يعمل في سياق المستخدم، والتطبيق (Application) الذي يعمل بصلاحيات التطبيق فقط على مستوى المؤسسة، ثم طلب الحد الأدنى من النطاقات الضرورية التي تتوافق مع طريقة عمل التطبيق فعلياً. أبقِ بيانات المستخدم ضمن النموذج المفوَّض قدر الإمكان، واحتفظ بنموذج التطبيق للمهام غير المراقبة أو العابرة للمستأجرين، وخطط للحصول على موافقة المسؤول. ارسم سياسات موافقة المستأجر مبكراً، ونفّذ الأذونات بمراحل (من التجربة التجريبية إلى التوسع)، ووثّق سبب الحاجة إلى كل نطاق. استخدم بدائل الحد الأدنى من الصلاحيات، مثل Calendars.Read بدلاً من Calendars.ReadWrite، وTeam.ReadBasic.All بدلاً من دليل كامل. أحِط ذلك بإطار حوكمة يشمل سير عمل للموافقة المسبقة، ومراجعات ربع سنوية، ووسوماً، وسجلات تدقيق. والنتيجة: عدد أقل من نوافذ "مطلوب موافقة المسؤول"، وإنجاز أسرع لاعتمادات الأمان، وإطلاق أكثر استقراراً.

Apple Podcasts · Spotify · YouTube

Microsoft Graph Permissions and Consent Models Explained (English)