يمكن أن يكون بناء تطبيق متعدد المستأجرين تحديًا، مع العديد من الجوانب التي يجب النظر فيها. يجمع هذا المقال جميع منشورات المدونة السابقة حول فهم ممارسات متعددة المستأجرين والمنظمات. لبدء سريع ولتوفير الوقت، قُم بمراجعة هذا المقال، فهو يحتوي على كل ما تحتاجه! يتم توضيح الإرشادات العامة في الخطوات التالية: 1. فهم بنية متعددة المستأجرين 2. رسم حالات الاستخدام لتطبيقك المتعدد المستأجرين 3. تحقيق عزل المستأجرين 4. تحديد كيفية إدارة الهويات 5. اختيار نماذج التفويض المناسبة ## فهم بنية متعددة المستأجرين تعدد المستخدمين في البرمجيات هو نوع من [البنية البرمجية](https://en.wikipedia.org/wiki/Software_architecture) حيث تعمل [نسخة]() واحدة من [البرمجيات](https://en.wikipedia.org/wiki/Computer_software) على خادم وتخدم عدة مستأجرين. الأنظمة المصممة على هذا النحو تكون "مشتركة" (بدلاً من "مخصصة" أو "معزولة"). المستأجر هو مجموعة من المستخدمين الذين يشاركون وصولًا مشتركًا مع امتيازات محددة إلى نسخة البرمجيات. multi-tenant

إحدى المفاهيم الرئيسية في تعدد المستخدمين هو فكرة "المشاركة". في التعريف الأوسع لتعدد المستخدمين، لا يعني أن التطبيق متعدد المستخدمين أن **كل** مكون في الحل يتم مشاركته. بدلاً من ذلك، يعني أن يتم إعادة استخدام **بعض** مكونات الحل عبر مستأجرين متعددين. فهم هذا المصطلح بشكل واسع يمكن أن يساعدك بشكل أفضل على التعاطف مع احتياجات عملائك ومن أين يأتون. بمجرد فهم بنية متعددة المستخدمين، الخطوة التالية هي تطبيق تطبيقك على سيناريوهات العالم الواقعي، مع التركيز على احتياجات المنتج والأعمال الخاصة. ## رسم حالات الاستخدام لتطبيقك المتعدد المستأجرين ### SaaS غالبًا ما تجد التطبيقات متعددة المستأجرين مكانها في حلول المنظمات للعمل مع التطبيقات الأخرى مثل أدوات الإنتاجية، برامج التعاون، وغيرها من المنتجات كخدمة (SaaS). في هذا السياق، يمثل كل "مستأجر" عادةً عميلًا تجاريًا، قد يكون لديه عدة مستخدمين (موظفيه). وبالإضافة إلى ذلك، قد يكون لدى العميل التجاري مستأجرين متعددين لتمثيل منظمات مختلفة أو أقسام أعمال. ![SaaS](https://uploads.strapi.logto.io/1/saas_product_d63c736650.webp) ### حالات الاستخدام العامة B2B تذهب تطبيقات الاعمال إلى أبعد من SaaS وغالبًا ما تشارك في استخدام التطبيقات متعددة المستأجرين. في سياقات B2B، تقوم هذه التطبيقات بدور منصة مشتركة لأنواع عديدة من الفرق، العملاء التجاريين، وشركات الشركاء للوصول إلى تطبيقاتك. على سبيل المثال، فكر في شركة لمشاركة الركوب التي تقدم تطبيقات B2C وB2B على حد سواء. تخدم تطبيقات B2B العديد من العملاء التجاريين، وتوظيف بنية متعددة المستأجرين يمكن أن يساعد في إدارة موظفيها ومواردها. لتوضيح ذلك، إذا كانت الشركة ترغب في الحفاظ على نظام هوية المستخدم الموحد، يمكنها تصميم هيكل مثل المثال التالي: سارة لديها هوية شخصية وأخرى تجارية. تستخدم خدمة مشاركة الركوب كراكبة وتعمل أيضًا كسائقة في أوقات فراغها. في دورها المهني، تدير أعمالها وتستخدم هذه الهوية التجارية لتكون شريكة مع الأعمال 1.

### لماذا يجب عليك توظيف تعدد المستخدمين في منتج SaaS الخاص بك #### التوسع باستخدام تعدد المستخدمين بالنسبة للأعمال التجارية الكبيرة، تعدد المستخدمين هو المفتاح لتحقيق متطلباتهم المتعلقة بالتوافر، إدارة الموارد، إدارة التكاليف، وأمان البيانات بشكل فعال. على المستوى التقني، تبنى اسلوب متعدد المستخدمين يساعدك على تبسيط عمليات التطوير، تقليل التحديات التقنية، وتعزيز التوسع السلس. #### إنشاء تجربة موحدة عند فحص أصول منتجات SaaS، فإنها تشبه المبنى الذي يحتوي على شقق مختلفة. كل المستأجرين يشاركون المرافق العامة مثل الماء، الكهرباء، والغاز، لكنهم يحتفظون بالسيطرة المستقلة على إدارة مساحتهم ومواردهم. هذا النهج يبسط إدارة الممتلكات. #### ضمان الأمان من خلال عزل المستأجرين في بنية متعددة المستخدمين، يتم تقديم مصطلح "المستأجر" لإنشاء حدود تفصل وتحمي الموارد والبيانات لمستأجرين مختلفين ضمن نسخة مشتركة. يضمن ذلك أن تظل البيانات والعمليات الخاصة بكل مستأجر مميزة وآمنة، حتى إذا كانوا يستخدمون نفس الموارد الأساسية. ## تحقيق عزل المستأجرين عند مناقشة التطبيقات متعددة المستأجرين، من الضروري دائمًا تحقيق **عزل المستأجرين**. يعني ذلك الحفاظ على البيانات والموارد لمستأجرين مختلفين منفصلة وآمنة ضمن نظام مشترك (على سبيل المثال، بنية تحتية سحابية أو تطبيق متعدد المستأجرين). يمنع ذلك أي محاولات غير مصرح بها للوصول إلى موارد مستأجر آخر. بينما قد تبدو الشرح مجردة، سنستخدم أمثلة وتفاصيل رئيسية لشرح عقلية العزل وأفضل الممارسات لتحقيق عزل المستأجرين. ### العزل لا يتعارض مع عقلية "المشاركة" لتعدد المستخدمين ذلك لأن عزل المستأجرين ليس بالضرورة عبارة عن إنشاء موارد مستوى البنية التحتية. في عالم تعدد المستخدمين والعزل، البعض يرون العزل كتقسيم صارم بين موارد البنية التحتية الفعلية. يؤدي هذا عادةً إلى نموذج يكون لكل مستأجر قواعد بيانات منفصلة، أو مثيلات حسابات، أو سحاب خاص. في سيناريوهات الموارد المشتركة، مثل التطبيقات متعددة المستخدمين، يمكن أن يكون طريقة الوصول إلى العزل بناء على مفهوم منطقي. يركز العزل على استخدام سياق “المستأجر” لتقييد الوصول إلى الموارد. يأخذ بعين الاعتبار سياق المستأجر الحالي ويستخدم هذا السياق لتحديد الموارد المتاحة لهذا المستأجر. ### المصادقة والتفويض ليست مساوية للعزل استخدام المصادقة والتفويض للتحكم في الوصول إلى بيئات SaaS الخاصة بك أمر مهم، لكنه ليس كافٍ للعزل الكامل. هذه الآليات ليست سوى جزء من اللغز الأمني. غالبًا ما يسأل الناس سؤالًا، هل يمكنني استخدام حلول التفويض العامة والتحكم بالوصول المستند إلى الأدوار لتحقيق عزل المستأجرين؟ هنا الأمر، يمكنك بناء تطبيق متعدد المستأجرين ولكن لا يمكنك القول أنك حققت واستخدمت استراتيجيات عزل المستأجرين كأفضل ممارسة. بشكل عام، نحن لا نوصي بذلك لأن العزل منفصل عن المصادقة والتفويض. للتوضيح، فكر في موقف حيث قمت بإعداد المصادقة والتفويض لنظام SaaS الخاص بك. عندما يسجل المستخدمون الدخول، يتلقون رمزًا يحتوي على معلومات حول دورهم، مما يحدد ما يمكنهم فعله في التطبيق. يعزز هذا الأمان ولكنه لا يضمن العزل. ### استخدام "المنظمة" لتمثيل مستأجر منتج SaaS، لتحقيق عزل المستأجرين الاعتماد فقط على المصادقة والتفويض لن يمنع مستخدمًا لديه الدور المناسب من الوصول إلى موارد مستأجر آخر. لذا نحتاج إلى تضمين سياق “المستأجر”، مثل معرف المستأجر، لتقييد الوصول إلى الموارد. هنا يأتي دور عزل المستأجرين. يستخدم معرفات المستأجرين لإنشاء حدود، على غرار الجدران، الأبواب، والأقفال، مما يضمن فصلًا واضحًا بين المستأجرين. ## الهويات في تطبيقات متعددة المستأجرين لقد ناقشنا عزل المستأجرين، لكن ماذا عن الهويات؟ كيف تقرر إذا كانت الهويات الخاصة بك يجب أن تكون “معزولة” أم لا؟ غالبًا ما يكون هناك لبس حول مفهوم "عزل الهوية". قد يُشير إلى مواقف حيث يكون لشخص معين هويتان في فهم الناس العام. 1. يمكن أن توجد كلتا الهويتين ضمن نظام هوية واحد. على سبيل المثال، قد يكون لدى سارة بريد إلكتروني شخصي مسجل جنبًا إلى جنب مع بريد إلكتروني للشركة متصل من خلال تسجيل الدخول الأحادي (SSO). 2. يحتفظ المستخدمون بهويتين منفصلتين ضمن نظامي هوية منفصلين، وتمثلان منتجات منفصلة تمامًا. هذه المنتجات لا تتعلق بأي شكل ببعضها البعض. في أوقات، تُشير هذه السيناريوهات إلى "عزل الهوية". ومع ذلك، قد لا يساعد هذا التصنيف في اتخاذ القرار. بدلاً من تحديد إذا كنت بحاجة إلى "عزل الهوية"، فكر في ما إذا كنت أو جزء من عملك أو منتجك تحتاج إلى الحفاظ على أنظمة هوية منفصلة يمكن أن يوجهك هذا في تصميم نظامك. لإجابة مختصرة بشأن تطبيق متعدد المستأجرين، في معظم الحالات، في التطبيقات متعددة المستأجرين، تتم مشاركة الهويات بينما يتم عزل موارد كل مستأجر. في التطبيقات متعددة المستأجرين، تكون الهوية مشتركة بين عدة مستأجرين بخلاف الموارد والبيانات المحددة للمستأجرين. يمكنك تخيل نفسك كمدير للمبنى؛ لن ترغب في الحفاظ على ورقتي أسماء منفصلتين لإدارة هويات مستأجريك. عند السعي لتحقيق عزل المستأجرين، قد تلاحظ التركيز المتكرر على مصطلح "المنظمة"، والتي غالبًا ما تعتبر كأفضل ممارسة لبناء تطبيقات متعددة المستأجرين. من خلال استخدام مفهوم "المنظمة"، يمكنك تحقيق عزل المستأجرين في تطبيقك متعدد المستأجرين مع الحفاظ على نظام هوية موحد. ## اختيار نماذج التفويض لتحسين التحكم في الوصول ### اختيار وتصميم نموذج التفويض المناسب عند اختيار نموذج التفويض الصحيح، ضع في اعتبارك هذه الأسئلة: 1. هل تقوم بتطوير منتج B2C، B2B، أو مزيج من كليهما؟ 2. هل يحتوي تطبيقك على بنية متعددة المستأجرين؟ 3. هل هناك حاجة إلى مستوى معين من العزل في تطبيقك، كما تحدده الوحدة التجارية؟ 4. ما الصلاحيات والأدوار التي تحتاج إلى تحديدها في سياق المنظمة، وأيها غير ذلك؟ ### فهم نماذج التفويض المختلفة في Logto #### التحكم في الوصول المستند إلى الأدوار RBAC (التحكم في الوصول المستند إلى الأدوار) هو طريقة لمنح أذونات المستخدم بناءً على أدوارهم، مما يتيح إدارة فعالة لوسائل الوصول إلى الموارد. يعد هذا الأسلوب الشائع في صميم التحكم في الوصول وهو جزء أساسي من ميزات التفويض في Logto. كمنصة إدارة الهوية الشاملة، يقدم Logto حلولًا مخصصة لطبقات متنوعة وكيانات، يخدم المطورين والشركات لهندسة متنوعة للمنتجات. #### التحكم في الوصول المستند إلى الأدوار API لحماية موارد API العامة التي لا تخص أي منظمة ولا تحتاج إلى قيود سياقية، فإن ميزة **_API RBAC_** مناسبة تمامًا. سجل فقط واجهة برمجية وخصص أذونات لكل مورد. ثم، تحكم في الوصول من خلال العلاقة بين الأدوار والمستخدمين. هنا، موارد API، الأدوار، والأذونات "تتشارك" في نظام هوية موحد. هذا شائع جدًا في منتج B2C ذو الهرمية الأقل ولا يحتاج إلى مستوى عميق جدًا من العزل. #### التحكم في الوصول المستند إلى الأدوار بالمنظمة في بيئة الأعمال التجارية متعددة المستأجرين، ضروري تحقيق عزل المستأجرين. لتحقيق ذلك، تُستخدم منظمات كالوسيط للعزل، مما يعني أن RBAC يكون فعالًا فقط عندما يكون المستخدم جزءًا من منظمة محددة. يركز RBAC للمنظمة على التحكم بالوصول على مستوى المنظمة بدلاً من مستوى API. يوفر هذا مرونة كبيرة للإدارة الذاتية على مستوى المنظمة على المدى الطويل ولكن لا يزال ضمن نظام هوية موحد. ميزة رئيسية في RBAC للمنظمة هي أن الأدوار والأذونات عمومًا نفسها عبر جميع المنظمات افتراضيًا، مما يجعل قالب Logto "لمنظمة" ذو مغزى للغاية لتحسين كفاءة التطوير. يتماشى هذا مع فلسفة المشاركة لتطبيقات متعددة المستأجرين، حيث تكون سياسات التحكم في الوصول والهويات هي مكونات البنية الأساسية المشتركة بين جميع المستأجرين (مستأجرين التطبيق)، وهو ممارسة شائعة في منتجات SaaS. ## الخاتمة يقدم هذا المقال كل ما تحتاجه للبدء في إعداد وتكوين تطبيقات متعددة المستأجرين. جرب Logto اليوم وابدأ في تطبيق أفضل الممارسات لتطوير التطبيقات متعددة المستأجرين باستخدام المنظمات. جرب Logto Cloud مجانًا