الهويات المُدارة مقابل تسجيلات التطبيقات في Azure: الفروقات الرئيسية وأفضل الممارسات

By Mirko Peters · 2026-04-28

إذا كنت تبني أو تؤمّن أي شيء جادّ في Azure هذه الأيام، فإن فهم الهويات المُدارة وتسجيلات التطبيقات لم يعد خيارًا، بل أساسٌ لا غنى عنه…

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

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

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

فهم الهويات المُدارة وتسجيلات التطبيقات

لنبدأ بتوضيح ما تفعله الهويات المُدارة وتسجيلات التطبيقات فعليًا في Azure وEntra ID. كلاهما وسيلة تمكّن الكيانات غير البشرية، مثل التطبيقات والبرامج النصية وعمليات الأتمتة، من المصادقة والوصول إلى الموارد في السحابة من Microsoft. لكن طريقة عملهما والمتاعب اليومية التي يحلانها (أو التي قد يسببانها) مختلفة تمامًا.

الهويات المُدارة هي حل Azure للمصادقة بدون أسرار. فبدلًا من التعامل مع كلمات مرور التطبيقات والشهادات، يمكنك منح مورد في Azure (مثل جهاز افتراضي أو App Service أو Logic App) هوية خاصة به في Entra ID. تُدار هذه الهوية تلقائيًا من Azure: إذ تُنشأ عند إنشاء المورد، وتُحذف عند حذفه، والأهم من ذلك أنها لا تعرّضك لتداول الأسرار التقليدية بين الأطراف. تأتي الهويات المُدارة بنوعين: مُسندة إلى النظام (واحدة لكل مورد، ومعزولة بإحكام)، ومُسندة إلى المستخدم (قابلة لإعادة الاستخدام عبر عدة موارد).

تسجيلات التطبيقات هي النهج التقليدي. فتسجيل تطبيق في Entra ID ينشئ كائن تطبيق ويمنحك معرّف عميل (Client ID)، مع أسرار أو شهادات اختيارية للمصادقة. إذا احتاج تطبيقك إلى تسجيل الدخول إلى خدمات Microsoft، أو الوصول إلى Graph API، أو العمل خارج Azure (أو على أكثر من مورد واحد)، فمن المرجح أن تستخدم تسجيل تطبيق. لكن عليك في المقابل إدارة أسراره وأمانه ودورة حياته، وهذا له بعض المقايضات.

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

الفروقات الجوهرية: دورة الحياة والأمان والتكامل مع Azure

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

الهويات المُدارة هي أقرب ما تكون في السحابة إلى مفهوم "اضبطها ونسِها". أنشئ مورد Azure، واطلب هوية مُدارة، وقد انتهى الأمر. يُنشئ Azure الهوية لك، ويربطها بـ Entra ID، ويُبقي الجانب الخلفي متزامنًا. وعند حذف المورد، تختفي الهوية أيضًا. لا توجد أي إدارة للأسرار، ولا تدوير لكلمات المرور، ويشعر فريق الأمن براحة أكبر.

أما تسجيلات التطبيقات فتتطلب جهدًا أكبر بكثير. فأنت تنشئ تسجيل التطبيق يدويًا في Entra ID، وتتابع معرّف العميل الخاص به، وتولّد أسرارًا أو شهادات للمصادقة. ومع مرور الوقت تنتهي صلاحية هذه الأسرار (أو قد تتسرب)، وعليك أنت أن تراجع أي التطبيقات تستخدمها. تدوير الأسرار، ومتابعة بيانات الاعتماد المنتهية الصلاحية، وتنظيف تسجيلات التطبيقات المهجورة مهمة قائمة بذاتها، ولهذا يسأل فريق الأمن دائمًا عن أتمتة دورة الحياة.

من ناحية الأمان، يتضح الفرق بجلاء: تستخدم الهويات المُدارة (managed identities) مصادقة بلا أسرار مرتبطة بموارد Azure، بينما تعتمد تسجيلات التطبيقات على أسرار ثابتة أو شهادات. لذلك تُفضَّل الهويات المُدارة حيثما تشكّل الأسرار خطرًا، أو حيثما تكون الأتمتة هي الأولوية.

لهذه الفروق في دورة الحياة والأمان تبعات كبيرة على الأتمتة والامتثال والحفاظ على بيئات السحابة مُحكمة الضبط. وإذا أردتم معرفة كيف تؤثر نهج الحوكمة والضوابط في تشتت الهويات وانحراف الإعدادات الأمنية، فاطلعوا على هذا الدليل حول استراتيجية حوكمة Azure، فهو قراءة لا غنى عنها لكل من يتولى مسؤولية بيئات Azure الكبيرة والمتنامية.

كيانات الخدمة (Service Principals) وأدوار RBAC وأذونات Microsoft Graph

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

في حالة تسجيلات التطبيقات، عند إضافة تطبيق جديد، ينشئ Entra كيان خدمة مطابقًا له لكل مستأجر تُعيّنونه له. وهذه هي الهوية التي ستستخدمونها لمنح أدوار Azure RBAC، مثل Contributor أو Reader، ولمنح أذونات Graph API سواء كانت مفوّضة أو على مستوى التطبيق.

الهويات المُدارة تختلف قليلًا، لكنها مبنية على الأساس نفسه. فتفعيل هوية مُدارة لمورد Azure يأمر Entra بإنشاء كيان خدمة ذي غرض خاص يرتبط دورة حياته بالمورد نفسه. ثم تُسندون أدوار RBAC (مثل Key Vault Reader) مباشرة إلى هذه الهوية، ويحصل المورد على رمز الوصول خلف الكواليس، دون تغييرات في الشيفرة ودون أسرار متناثرة هنا وهناك.

منح الأذونات هو المحك الفعلي. يستخدم النموذجان RBAC من Azure للوصول على مستوى الموارد، لكن طريقة منح أذونات Graph تختلف. تتيح تسجيلات التطبيقات منح وصول Graph API عبر الموافقة الصريحة أو موافقة المسؤول؛ أما الهويات المُدارة فيمكن منحها أذونات على مستوى التطبيق في Graph دون تسجيل دخول تفاعلي، ما يجعلها مثالية للأتمتة التي تحتاج إلى جلب بيانات المستخدمين، أو تدقيق الأمان، أو تشغيل سير العمل.

إسناد الوصول ومراقبة الامتثال لهذه الهويات ليس، مع ذلك، أمرًا "نضبطه ثم ننساه". فإسناد أدوار RBAC بإحكام، والتدقيق المنتظم، والاستفادة من أدوات مثل Microsoft Defender for Cloud، تساعدكم على متابعة من يفعل ماذا، ورصد الإعدادات الخاطئة، وإبقاء الانحراف عند الحد الأدنى. هل تريدون التعمق في حوكمة الهويات؟ لا تفوّتوا هذا الدليل حول حوكمة المؤسسات في Azure، أو هذا الشرح حول مراقبة الامتثال في Microsoft Defender for Cloud للحصول على نصائح عملية حول الأمان المستمر.

اختيار النموذج المناسب: السيناريوهات والترحيل والحوكمة

كل هذه الخلفية مهمة، لكن ما تريد معظم الفرق معرفته فعلًا هو: متى تستخدمون الهويات المُدارة مقابل تسجيلات التطبيقات؟ وكيف ترحّلون هذه الهويات أو تحكمونها كي لا تسير الأمور في الاتجاه الخاطئ مع توسّعكم؟

تتألق الهويات المُدارة في أحمال العمل التي تعمل داخل Azure مباشرة، والتي تحتاج فقط إلى الوصول ضمن المستأجر نفسه، مثل أجهزة الافتراضية التي تشغّل النصوص البرمجية، أو تطبيقات App Service التي تتواصل مع Key Vault، أو Logic Apps التي تستعلم من Microsoft Graph. الأمان أفضل، والإعداد أسرع، وهناك إدارة أسرار أقل تشغلكم. لكن إذا كنتم تشغّلون حلول SaaS أو حلولًا متعددة المستأجرين، أو بيئات هجينة (مثل تطبيقات محلية تتصل بواجهات برمجة سحابية)، فتسجيلات التطبيقات تظل الخيار الأول بفضل مرونتها وتوافقها الأوسع.

ترحيل التطبيقات من تسجيلات التطبيقات إلى الهويات المُدارة موضوع ساخن. تبدأ العملية بتقييم الجاهزية: ما أحمال العمل التي يمكنها فعلًا الانتقال، وما التبعيات والقيود القائمة؟ بالنسبة للتطبيقات المبنية أصلًا على تسجيلات التطبيقات، ينبغي التدرّج في التطبيق، والاختبار الدقيق، وإعداد خطط بديلة لمنع توقف الخدمة أو مفاجآت المصادقة.

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

تجمع نهج الحوكمة القوية الاستراتيجية بأكملها معاً. فاستخدام Azure Policy وPrivileged Identity Management وعمليات الامتثال الدورية يضمن تطبيق مبدأ أقل الامتيازات، ورصد الانحراف عن الإعدادات المعتمدة، والتوافق مع نهج Zero Trust. وللوقوف على الواقع فيما يخص حسابات الخدمة مقارنةً بهويات أحمال العمل الحقيقية (ولماذا تقصر الأساليب التقليدية)، اطّلع على هذا التحليل حول مخاطر الهويات غير البشرية وMicrosoft Entra Workload Identities. وإن كنت تبحث عن أساسيات الحوكمة الشاملة، فإن مصدر استراتيجية حوكمة المؤسسات يزخر بأفضل الممارسات.