System-Assigned مقابل User-Assigned: الهويات المُدارة في Azure، أيّهما تختار؟

By Mirko Peters · 2026-10-26

قارن بين الهويات المُدارة في Azure من نوع system-assigned وuser-assigned. تعرّف على النوع الذي ينبغي اختياره لتقليل العبء الإداري والتوسّع بأمان.

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

يُعدّ الاختيار بين الهويات system-assigned وuser-assigned في Azure من أهم القرارات المعمارية المتعلقة بأمن السحابة والعبء الإداري. فبينما ترتبط الهويات system-assigned مباشرةً بدورة حياة مورد Azure واحد، تعمل الهويات user-assigned ككيانات مستقلة يمكن مشاركتها بين موارد متعددة، ما يقلّل بشكل كبير من تعيينات الأدوار المكررة ويمنع الوصول إلى حدود الرموز في البيئات المؤتمتة.

النقاط الرئيسية

• تُنشأ الهويات system-assigned وتُدار وتُحذف تلقائياً مع مورد Azure الأصلي.
• توجد الهويات user-assigned بشكل مستقل كموارد Azure قائمة بذاتها، ما يجعلها قابلة للمشاركة بين عدة أجهزة افتراضية وتطبيقات ودوال.
• توصي Microsoft باستخدام الهويات user-assigned في معظم سيناريوهات الموارد المتعددة لتقليل أعمال التتبّع وتعيينات الأدوار المعقدة.
• قد يؤدي استخدام الهويات system-assigned في البيئات سريعة التوسّع أو في بيئات الاختبار قصيرة العمر إلى تراكم الهويات وتجاوز حدود معدل Azure.
• يمكن لمورد Azure واحد أن يستضيف هوية system-assigned للتسجيل المعزول، وهوية user-assigned واحدة أو أكثر لأحمال العمل المشتركة.

فهم الفروقات الجوهرية

عندما تبدأ بتصميم تطبيقات سحابية آمنة دون مفاتيح سرية مضمّنة في الكود أو سلاسل اتصال ثابتة، يجب أن تحدد كيف ستتحقق أحمال عملك من هويتها لدى Microsoft Entra ID. تقدم Azure نوعين مختلفين من الهويات المُدارة: system-assigned وuser-assigned. إن فهم طريقة عملهما من الداخل سيوفّر على فريق الهندسة ساعات لا تُحصى من استكشاف الأخطاء وصيانة الإدارة.

كيف تعمل الهويات system-assigned

تُفعَّل الهوية المُدارة system-assigned مباشرةً داخل مورد Azure محدد، مثل Azure Virtual Machine أو App Service أو Function App. يمكن تصوّرها كهوية تولد مع المورد وتنتهي بانتهائه. عند تفعيل هوية system-assigned على جهاز افتراضي، تُنشئ Azure هوية في Microsoft Entra ID تحمل الاسم نفسه تماماً لذلك المورد.

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

كيف تعمل الهويات user-assigned

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

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

إدارة الأعباء الإدارية وتعيين الأدوار

تتضح الفروق العملية بين نوعي الهوية هذين بوضوح مؤلم عند النظر إلى إدارة التحكم في الوصول المستند إلى الأدوار (RBAC) في البيئات الكبيرة. فكلما منحتم هوية حق الوصول إلى حساب تخزين أو خزنة مفاتيح أو قاعدة بيانات، يجب عليكم إنشاء تعيين دور في Azure.

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

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

المزالق المعمارية وحالات الحافة

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

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

على العكس، تتألق الهويات المُعيّنة من النظام في سيناريوهين محددين:

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

تذكّروا أنكم لستم مُلزَمين بالاختيار الثنائي المطلق. فيمكن لمورد Azure واحد أن يحمل هوية مُعيّنة من النظام للعمليات الخاصة الحساسة، وهوية مُعيّنة من المستخدم أو أكثر لتدفقات العمل المؤسسية المشتركة.

الخاتمة

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

للتعمّق في كيفية إصدار الرموز المميزة، وكيفية تكامل Azure Key Vault دون كلمات مرور، والمزالق الأمنية الشائعة التي ينبغي تجنّبها، تأكّدوا من الاستماع إلى الحلقة الكاملة من البودكاست للحصول على رؤى الخبراء واستراتيجيات عملية.

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

هل يمكن لمورد Azure واحد أن يستخدم الهويتين المُدارتين المُعيّنة من النظام والمُعيّنة من المستخدم معًا؟

نعم. يمكن لمورد Azure مثل Virtual Machine أو App Service أن يملك هوية واحدة مُعيّنة من النظام وهوية واحدة أو أكثر مُعيّنة من المستخدم مفعّلة في الوقت نفسه، مما يتيح الجمع بين استراتيجيات المصادقة المخصصة والمشتركة.

ماذا يحدث للهوية المُعيّنة من المستخدم عند حذف مورد Azure المرتبط بها؟

على عكس الهويات المُعيّنة من النظام، التي تُحذف تلقائيًا عند إزالة المورد الأصلي، تبقى الهويات المُعيّنة من المستخدم قائمة ككائنات مستقلة في Azure إلى أن يحذفها المسؤول صراحةً.

لماذا توصي Microsoft باستخدام الهويات المُعيّنة من المستخدم في معظم سيناريوهات الموارد المتعددة؟

توصي Microsoft بالهويات المُعيّنة من المستخدم أساسًا لتقليل العبء الإداري وانتشار تعيينات الأدوار. فمشاركة هوية واحدة عبر عدة موارد حوسبة تقلل بشكل كبير عدد تعيينات RBAC التي تحتاجون إلى إنشائها وصيانتها.

هل تُكلّف الهويات المُدارة شيئًا مقابل التشغيل في Azure؟

لا، فالهويات المُدارة المعيّنة للنظام والهويات المُدارة المعيّنة للمستخدم كلاهما ميزتان مجانيتان ضمن Microsoft Entra ID للموارد في Azure، لكن قد تُطبَّق التكاليف المعتادة على خدمات الحوسبة أو التخزين الأساسية التي تصل إليها.