مشاركة عبر

النهج المعمارية للهوية في الحلول متعددة المستأجرين

  • مقالة

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

إشعار

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

المصادقة

المصادقة هي العملية التي يتم من خلالها إنشاء هوية المستخدم. عند إنشاء حل متعدد المستأجرين، هناك اعتبارات ونهج خاصة للعديد من جوانب عملية المصادقة.

الأمان المشترك

قد تحتاج إلى الاتحاد مع موفري الهوية الآخرين (IdPs). يمكن استخدام الاتحاد لتمكين السيناريوهات التالية:

  • تسجيل الدخول الاجتماعي، مثل تمكين المستخدمين من استخدام حساب Google أو Facebook أو GitHub أو حساب Microsoft الشخصي الخاص بهم.
  • الدلائل الخاصة بالمستأجر، مثل تمكين المستأجرين من توحيد تطبيقك مع موفري الهوية الخاصة بهم، لذلك لا يحتاجون إلى إدارة الحسابات في أماكن متعددة.

للحصول على معلومات عامة حول الاتحاد، راجع نمط الهوية الموحدة.

إذا اخترت دعم موفري الهوية الخاصة المستأجرين، فتأكد من توضيح الخدمات والبروتوكولات التي تحتاج إلى دعمها. على سبيل المثال، هل ستدعم بروتوكول OpenID Connect وبروتوكول لغة ترميز تأكيد الأمان (SAML)؟ أو، هل ستدعم فقط الاتحاد مع مثيلات Microsoft Entra؟

عند تنفيذ أي موفر هوية، ضع في اعتبارك أي مقياس وحدود قد تنطبق. على سبيل المثال، إذا كنت تستخدم Azure Active Directory (Azure AD) B2C كموفر هوية خاص بك، فقد تحتاج إلى نشر نهج مخصصة للاتحاد مع أنواع معينة من موفري هوية المستأجر. يحد Azure AD B2C من عدد النهج المخصصة التي يمكنك نشرها، مما قد يحد من عدد موفري الهوية الخاصة بالمستأجرين الذين يمكنك الاتحاد معهم.

يمكنك أيضا التفكير في توفير الاتحاد كميزة تنطبق فقط على العملاء في مستوى منتج أعلى.

تسجيل الدخول الأحادي

تمكن تجارب تسجيل الدخول الأحادي المستخدمين من التبديل بين التطبيقات بسلاسة، دون مطالبتك بإعادة المصادقة في كل نقطة.

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

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

تقييم مخاطر تسجيل الدخول

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

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

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

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

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

الانتحال

يتيح انتحال الهوية للمستخدم افتراض هوية مستخدم آخر، دون استخدام بيانات اعتماد هذا المستخدم.

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

إذا اخترت تنفيذ انتحال الهوية، ففكر في كيفية تدقيق استخدامه. تأكد من أن سجلاتك تتضمن كلا من المستخدم الفعلي الذي قام بتنفيذ الإجراء ومعرف المستخدم الذي انتتحل صفته.

تدعم بعض الأنظمة الأساسية للهوية انتحال الهوية، إما كميزة مضمنة أو باستخدام التعليمات البرمجية المخصصة. على سبيل المثال، في Azure AD B2C، يمكنك إضافة مطالبة مخصصة لمعرف المستخدم المنتحل، أو يمكنك استبدال مطالبة معرف الموضوع في الرموز المميزة التي يتم إصدارها.

التصريح

التخويل هو عملية تحديد ما يسمح للمستخدم بالقيام به.

يمكن تخزين بيانات التخويل في عدة أماكن، بما في ذلك في المواقع التالية:

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

في معظم الحلول متعددة المستأجرين، تتم إدارة تعيينات الأدوار والأذونات من قبل المستأجر أو العميل، وليس من قبلك كمورد للنظام متعدد المستأجرين.

لمزيد من المعلومات، راجع أدوار التطبيق.

إضافة هوية المستأجر ومعلومات الدور إلى الرموز المميزة

ضع في اعتبارك الجزء أو الأجزاء التي يجب أن ينفذها الحل الخاص بك طلبات التخويل، بما في ذلك تحديد ما إذا كان يسمح للمستخدم بالعمل مع بيانات من مستأجر معين.

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

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

التخويل المستند إلى التطبيق

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

استخدام معرف Microsoft Entra أو Azure AD B2C

توفر Microsoft معرف Microsoft Entra الهوية الخارجية لـ Microsoft Entra وAzure AD B2C، وهي أنظمة أساسية للهوية المدارة يمكنك استخدامها ضمن الحل متعدد المستأجرين الخاص بك.

العديد من الحلول متعددة المستأجرين هي برامج كخدمة (SaaS). يعتمد اختيارك لاستخدام معرف Microsoft Entra أو الهوية الخارجية لـ Microsoft Entra أو Azure AD B2C، جزئيا، على كيفية تعريف المستأجرين أو قاعدة العملاء.

  • إذا كان المستأجرون أو العملاء مؤسسات، فقد يستخدمون بالفعل معرف Microsoft Entra لخدمات مثل Office 365 أو Microsoft Teams أو لبيئات Azure الخاصة بهم. يمكنك إنشاء تطبيق متعدد المستأجرين في دليل Microsoft Entra الخاص بك، لجعل الحل الخاص بك متاحا لدلائل Microsoft Entra الأخرى. يمكنك حتى سرد الحل الخاص بك في Azure Marketplace وجعله متاحا بسهولة للمؤسسات التي تستخدم معرف Microsoft Entra.
  • إذا لم يستخدم المستأجرون أو العملاء معرف Microsoft Entra، أو إذا كانوا أفرادا بدلا من مؤسسات، ففكر في استخدام الهوية الخارجية لـ Microsoft Entra أو Azure AD B2C. يوفر كل من الهوية الخارجية لـ Microsoft Entra وAzure AD B2C مجموعة من الميزات للتحكم في كيفية تسجيل المستخدمين وتسجيل الدخول. على سبيل المثال، يمكنك تقييد الوصول إلى الحل الخاص بك فقط للمستخدمين الذين دعوتهم بالفعل، أو قد تسمح بالتسجيل في الخدمة الذاتية. استخدم النهج المخصصة في Azure AD B2C للتحكم الكامل في كيفية تفاعل المستخدمين مع النظام الأساسي للهوية. يمكنك استخدام العلامة التجارية المخصصة، ويمكنك توحيد Azure AD B2C مع مستأجر Microsoft Entra الخاص بك، لتمكين موظفيك من تسجيل الدخول. يتيح Azure AD B2C أيضا الاتحاد مع موفري الهوية الآخرين.
  • بعض الحلول متعددة المستأجرين مخصصة لكلا الموقفين المذكورين أعلاه. قد يكون لدى بعض المستأجرين مستأجري Microsoft Entra الخاصين بهم، وقد لا يكون لدى الآخرين. يمكنك أيضا استخدام Azure AD B2C لهذا السيناريو، واستخدام نهج مخصصة للسماح للمستخدم بتسجيل الدخول من دليل Microsoft Entra للمستأجر. ومع ذلك، إذا كنت تستخدم نهج مخصصة لإنشاء اتحاد بين المستأجرين، فتأكد من مراعاة الحدود المفروضة على عدد النهج المخصصة التي يمكن أن يستخدمها دليل Azure AD B2C واحد.

لمزيد من المعلومات، راجع اعتبارات استخدام Azure Active Directory B2C في بنية متعددة المستأجرين.

أنماط مضادة لتجنب

بناء أو تشغيل نظام الهوية الخاص بك

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

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

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

بدلا من بناء أو تشغيل نظام الهوية الخاص بك، من الممارسات الجيدة استخدام خدمة أو مكون جاهز. على سبيل المثال، ضع في اعتبارك استخدام معرف Microsoft Entra أو Azure AD B2C، وهما نظام أساسي للهوية المدارة. يتحمل موردو النظام الأساسي للهوية المدارة مسؤولية تشغيل البنية الأساسية لمنصاتهم، وعادة ما يدعمون معايير الهوية والمصادقة الحالية.

عدم مراعاة متطلبات المستأجرين

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

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

تكتل المستخدمين والمستأجرين

من المهم التفكير بوضوح في كيفية تعريف الحل الخاص بك للمستخدم والمستأجر. في كثير من الحالات، يمكن أن تكون العلاقة معقدة. على سبيل المثال، قد يحتوي المستأجر على عدة مستخدمين، وقد ينضم مستخدم واحد إلى عدة مستأجرين.

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

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

دور التكتل وتخويل المورد

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

فشل كتابة سجلات التدقيق

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

مساهمون آخرون:

الخطوات التالية

راجع الاعتبارات المعمارية للهوية في حل متعدد المستأجرين.