لماذا تفشل أتمتتك الليلية باستمرار: فخ الأذونات المفوّضة

By Mirko Peters · 2026-08-11

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

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

Titelbild: Why Your Nightly Automations Keep Breaking: The Delegated Permission Trap

في هذا المنشور، سنتعمق في سبب انتهاء ربط السكربتات والسير الخلفية بحسابات المستخدمين البشريين دائمًا بكارثة. سنستعرض كيف يغيّر الانتقال إلى نموذج حديث بلا واجهة تفاعلية موثوقية بنيتك التحتية بالكامل، وسنشرح بنية متكاملة للقيام بذلك بالشكل الصحيح. سواء كنتَ تكافح سكربتات PowerShell غير المستقرة، أو تدفقات Logic Apps المتقلبة، أو تدفقات Power Automate الهشة، فسيمنحك هذا الدليل المخطط اللازم لتكاملات متينة. للاستماع إلى نقاش صوتي معمّق حول هذا النمط المعماري بالذات، لا تفوّت حلقتنا ذات الصلة Build App-Only Microsoft Graph Integrations.

الخلاصة السريعة

السبب الجذري للأتمتات غير المستقرة: الأذونات المفوّضة المرتبطة بجلسات بشرية.
الحل: أذونات App-only (التطبيق) مع مبدأ الخدمة (service principal) ← بلا واجهة تفاعلية، وبأقل الصلاحيات الضرورية، وقابلة للتدقيق.
النتيجة: تذاكر مصادقة أقل، ونطاق أكثر أمانًا، وتشغيل ليلي مستقر، وسجلات تدقيق أوضح، وتوسّع أسهل.

لماذا تُسقطك الأذونات المفوّضة باستمرار

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

مرتبطة بـمستخدم: إعادة تعيين كلمات المرور، والمصادقة متعددة العوامل، وتغييرات الأدوار والتراخيص، وإجراءات إنهاء الخدمة.
تشجّع على إنشاء حسابات "خدمة" بصلاحيات مفرطة لإيقاف الأخطاء ← مخاطرة ومشكلات معقدة.
أعطال صامتة أثناء الليل، ورسالة "insufficient privileges"، ومهام خلفية هشة.

المسار الأذكى: التطبيقات فقط مع Microsoft Graph

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

التطبيق (مبدأ الخدمة) هو الهوية، فلا يوجد تسجيل دخول تفاعلي ولا جلسة تنتهي صلاحيتها.
أقل الصلاحيات: امنح فقط ما تحتاجه الأتمتة (لكل مورد أو نطاق).
قابلية التدقيق: تُنسب الإجراءات إلى التطبيق، مما يبسّط الامتثال وإعداد التقارير.

الإعداد خطوة بخطوة (بلا مفاجآت)

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

تسجيل التطبيق (Azure AD ← App registrations).
اختر أذونات "Application" (وليس Delegated) لنطاقات Graph التي تحتاجها فعلًا (مثل Sites.ReadWrite.All وMail.Send وChannelMessage.Send).
الموافقة الإدارية: يجب أن يمنح مسؤول عام أو مسؤول بصلاحيات مميزة الموافقة على مستوى المستأجر (تحقّق من Enterprise apps ← Permissions).
بيانات الاعتماد: يُفضَّل استخدام الشهادات بدلًا من الأسرار السرية للعميل؛ وإذا استخدمت الأسرار، فخزّنها في Azure Key Vault ودوّرها بانتظام.
كائنات المستأجر: تحقّق من معرّفات المواقع، ومعرّفات الفرق والقنوات، ونطاقات صناديق البريد المستهدفة، ووائم الأذونات مع المورد.
معالجة الأخطاء: اربط استجابات 403 و401 بالنطاقات المفقودة مقابل الموافقة المفقودة، وأضف إعادة المحاولة مع التراجع التدريجي (backoff)، وسجّل معرّفات الارتباط (correlation IDs).

وصفات الحد الأدنى من الأذونات (أمثلة)

لا تمنح وصولاً شاملاً أبداً عندما تكفي الأذونات المستهدفة. فصِّل نطاقات الوصول مباشرةً وفق متطلبات كل خدمة.

روبوت ملفات SharePoint: Sites.Selected (الخيار الأفضل) مع الموافقة لكل موقع، أو Sites.ReadWrite.All إذا لم يكن هناك بديل.
مُشعِر Teams: ChannelMessage.Send (على مستوى التطبيق) للنشر المستهدف.
تنبيهات البريد: Mail.Send (على مستوى التطبيق) على صندوق بريد مخصص.
مساعدو توفير المستخدمين: استخدم User.ReadWrite.All بنطاق ضيق فقط عند الضرورة، ويُفضَّل استخدام واجهات Graph الخاصة بدورة حياة المستخدم.

الربط بعد الاستيراد (التكامل مع Power Platform)

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

بعد استيراد الحل، اربط مراجع الاتصال بالاتصال الخاص بالتطبيق فقط.
استخدم PAC CLI/PowerShell لتعيين متغيرات البيئة الخاصة بمعرّفات المستأجر ومعرّفات المواقع ومعرّفات القنوات.

الوقت الفعلي والموثوقية

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

webhooks في Graph (SharePoint/Teams/Outlook): اشتراكات على مستوى التطبيق، والتحقق من نقطة النهاية، والتجديد قبل انتهاء الصلاحية.
نفّذ معالِجات عديمة التأثير عند التكرار (idempotent)، وDLQ/إعادة المحاولة، وضوابط تحديد المعدل (rate-limit).
تسجيل مركزي للأحداث (App Insights/Log Analytics) مع تنبيهات على معدل الفشل وارتفاعات 401/403.

قائمة التحقق من تعزيز الأمان

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

أقل قدر من الامتيازات ← يُفضَّل Sites.Selected مع المنح لكل موقع على النطاقات الشاملة للمستأجر.
هويات أمان منفصلة لكل مجال أتمتة، وتجنب تطبيق «الحلقة الواحدة» الذي يتحكم في كل شيء.
Key Vault لتخزين الأسرار، والهوية المُدارة حيثما أمكن.
استثناءات تطبيقات Conditional Access موثّقة، وتُراجَع كل ربع سنة.
مراجعات الوصول: أذونات التطبيقات ومالكوها.
مفتاح الإيقاف الطارئ: عطّل الكيان الخدمي بسرعة عند الحاجة.

خريطة استكشاف الأخطاء وإصلاحها (سريعة)

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

403 Insufficient privileges ← نطاق خاطئ أو الموافقة الإدارية مفقودة.
401 Unauthorized ← سر أو شهادة غير صالحة أو منتهية الصلاحية، أو عدم تطابق الجمهور المستهدف للرمز المميز.
404 Not found ← معرّف المورد أو عنوانه غير صحيح، أو أن التطبيق يفتقر إلى منح خاصة بالمورد (مثل Sites.Selected).
429/503 ← أضف التراجع التدريجي مع الجitter، والتزم بإرشادات تقييد الطلبات في Graph.

خطة الإطلاق (من sprint واحد إلى sprintين)

لا تحاول إعادة هيكلة كل عملية أتمتة في مؤسستك دفعة واحدة. اعتمد نهجاً منهجياً على مدى sprintين أو أكثر.

Sprint 1: سجّل التطبيق، وامنح أقل النطاقات الضرورية، واربط Key Vault، وحوّل مهمة واحدة غير مستقرة (رفع ملف إلى SharePoint، أو إشعار Teams).
Sprint 2: أضف webhooks، والتسجيل المركزي والتنبيهات، وقم بتدوير الأسرار، ووثّق دليل الدعم، ثم وسّع النطاق ليشمل سير عمل إضافية.

أنماط مضادة يجب تجنبها

تجنب هذه الاختصارات الشائعة التي تُدخل ثغرات أمنية جسيمة ومتاعب تشغيلية لاحقاً.

منح مسؤول عام صلاحية «مستخدم خدمة» لجعل الأمور تعمل.
نطاقات *.ReadWrite.All الشاملة «تحسباً» لأي طارئ.
تخزين الأسرار الخاصة بالعميل في الكود أو المتغيرات.
تخطي التحقق من الموافقة الإدارية، بحجة «يعمل على مستأجري».
تطبيق ضخم واحد يخدم كل شيء (نطاق تأثير أوسع من اللازم).

مخطط رمز للبدء السريع (مفهومي)

عند بناء منطق التكامل، صِغ كتل الكود وفق أنماط منح بيانات الاعتماد للعميل (client credentials) المعتادة مع مرونة مدمجة.

الرمز المميز: تدفق بيانات اعتماد العميل ← احصل على رمز تطبيق لـ https://graph.microsoft.com/.default.
الاستدعاء: ارفع الملف إلى محرك SharePoint عبر معرّفات الموقع/المحرك، وأرسل رسالة Teams عبر معرّف القناة.
إعادة المحاولة: عند 429/5xx مع تراجع أُسّي؛ سجّل request-id/client-request-id.

الأسئلة المتداولة

هل أحتاج إلى E5؟
لا. يعتمد التطبيق المعتمد على التطبيق فقط على تسجيلات تطبيقات Azure AD مع Graph، وتعتمد متطلبات الترخيص على الخدمات التي يتم الوصول إليها.

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

ماذا عن Power Automate؟
استخدم اتصالات app-only (موصل مخصص/HTTP مع Azure AD) واربطها عبر متغيرات البيئة في خط أنابيب ALM الخاص بك.

الخاتمة

إن تبني بنية app-only هو الخطوة الأكثر تأثيرًا التي يمكنك اتخاذها للتخلص من تنبيهات المصادقة في منتصف الليل وتثبيت أحمال العمل الآلية. فمن خلال التخلص من الاعتماد على المستخدمين البشريين، واعتماد مبدأ أقل الامتيازات، والاحتفاظ ببيانات الاعتماد بأمان في Azure Key Vault، تمهّد الطريق نحو حلول مؤسسية مرنة وآمنة وقابلة للتوسع بسهولة. وللتوسع أكثر في أنماط التطوير هذه والاستماع إلى تجارب هندسية عملية، تأكد من الاستماع إلى الحلقة المرافقة Build App-Only Microsoft Graph Integrations. حظًا موفقًا في البناء!