ما هي التعددية المستأجرة (Multi-tenancy)؟
التعددية المستأجرة (Multi-tenancy) البرمجية هي بنية برمجية حيث تعمل نسخة واحدة من البرمجيات على خادم وتخدم عدة مستأجرين. الأنظمة المصممة بطريقة كهذه تعتبر “مشتركة” (بدلاً من “مخصصة” أو “معزولة”).
المستأجر هو مجموعة من المستخدمين الذين يشاركون الوصول العام مع امتيازات محددة إلى نسخة البرنامج.
يفضل استخدام بنية التعددية المستأجرة عندما يقدم مقدمو الخدمات خدمات موحدة لعدة عملاء. هذه الخدمات عادة ما تكون قليلة التخصيص، ويشارك جميع العملاء نفس نسخة التطبيق. عندما يتم تحديث التطبيق، فإنه يطبق على جميع العملاء في آن واحد.
على سبيل المثال، غالبًا ما تستخدم أنظمة CRM (إدارة علاقات العملاء) بنية التعددية المستأجرة لتقديم نفس الخدمة لجميع العملاء.
مبدأ أساسي في التعددية المستأجرة هو “المشاركة”. هذا لا يعني أن كل جزء من الحل مشترك؛ بل يعني أن بعض المكونات على الأقل يعاد استخدامها عبر عدة مستأجرين. فهم هذا المفهوم الأوسع يمكن أن يساعدك في تلبية احتياجات عملائك بشكل أفضل.
ما هي حالات استخدام المنتجات التعددية المستأجرة؟
تستخدم التطبيقات التعددية المستأجرة بشكل شائع في منتجات البرمجيات كخدمة (SaaS) مثل أدوات الإنتاجية وبرامج التعاون وما إلى ذلك. في هذا الترتيب، يمثل كل “مستأجر” عادةً عميل أعمال، مع عدة مستخدمين (عادة ما يكونون موظفين). في منتجات مختلفة، قد يشير إليه بمستأجر أو مساحة عمل أو مشروع، حسب السياق. قد يكون لدى شركة واحدة أيضًا عدة مستأجرين لتمثيل أقسام أو منظمات مختلفة.
في حالات أكثر تعقيدًا، مثل تطبيقات B2B خارج إطار SaaS، توفر التطبيقات التعددية المستأجرة منصة مشتركة لفرق مختلفة، عملاء الأعمال، وشركات الشركاء للوصول إلى خدماتك.
لماذا يجب اعتماد التعددية المستأجرة في منتج SaaS؟
التوسع باستخدام التعددية المستأجرة
بالنسبة لمؤسسات الأعمال، تعتبر التعددية المستأجرة المفتاح لتحقيق متطلباتهم بفعالية فيما يخص التوفر وإدارة الموارد وإدارة التكاليف وأمان البيانات. على المستوى التقني، يعتمد نهج تعددية المستأجر على تبسيط عمليات التطوير الخاصة بك، وتقليل التحديات التقنية، وتعزيز التوسع السلس.
إنشاء تجربة موحدة
عند فحص جذور منتجات SaaS، يكون الأمر مشابهًا لمبنى يضم شققًا مختلفة. كل المستأجرين يشاركون المرافق العامة مثل المياه والكهرباء والغاز، ومع ذلك يحافظون على التحكم المستقل في إدارة المساحة والموارد الخاصة بهم. هذا النهج يبسط إدارة الممتلكات.
ضمان الأمان من خلال عزل المستأجرين
في بنية التعددية المستأجرة، يتم إدخال مصطلح “المستأجر” لإنشاء حدود تفصل وتؤمن الموارد والبيانات للمستأجرين المختلفين ضمن نسخة مشتركة. هذا يضمن أن تظل بيانات وعمليات كل مستأجر متميزة وآمنة، حتى لو كانوا يستخدمون نفس الموارد الأساسية.
كيف تحقق عزل المستأجر في بنية التعددية المستأجرة؟
عند مناقشة التطبيقات التعددية المستأجرة، يكون من الضروري دائمًا تحقيق عزل المستأجر. وهذا يعني الحفاظ على بيانات وموارد المستأجرين المختلفين بشكل منفصل وآمن ضمن نظام مشترك (على سبيل المثال، بنية تحتية سحابية أو تطبيق تعددية مستأجرة). هذا يمنع أي محاولات غير مصرح بها للوصول إلى موارد مستأجر آخر.
في حين أن الشرح قد يبدو مجردًا، سنستخدم أمثلة وتفاصيل رئيسية لشرح فكرة العزل وأفضل ممارسة لتحقيق عزل المستأجر.
عزل المستأجر لا يتعارض مع عقلية “المشاركة” في التعددية المستأجرة
وذلك لأن عزل المستأجر ليس بالضرورة بناءً على مستوى موارد البنية التحتية. في عالم التعددية المستأجرة والعزل، يعتبر البعض العزل تقسيمًا صارمًا بين موارد البنية التحتية الفعلية. وعادة ما يؤدي ذلك إلى نموذج حيث يكون لكل مستأجر قواعد بيانات، أمثلة حوسبة، حسابات، أو سحابات خاصة منفصلة. في سيناريوهات الموارد المشتركة، مثل تطبيقات تعددية المستأجر، يمكن أن يكون العزل عبارة عن بناء منطقي.
في تصميم البنية، يمكن تحقيق درجات مختلفة من عزل الموارد بين المستأجرين:
بشكل عام، كلما زادت الموارد المشتركة بين المستأجرين، انخفضت تكلفة تكرار النظام وصيانته. وعلى النقيض من ذلك، كلما قلت الموارد المشتركة، ارتفعت التكلفة.
يركز عزل المستأجر بشكل حصري على استخدام سياق “المستأجر” لتقييد الوصول إلى الموارد. حيث يقيم سياق المستأجر الحالي ويستخدم ذلك السياق لتحديد الموارد التي يمكن الوصول إليها لذلك المستأجر.
المصادقة (Authentication) والتفويض (Authorization) ليست مساوية لـ “العزل”
استخدام المصادقة (Authentication) والتفويض (Authorization) للتحكم في الوصول بيئة SaaS الخاصة بك هو أمر مهم، ولكنه ليس كافيًا للعزل الكامل. هذه الآليات هي جزء فقط من معادلة الأمان.
غالبًا ما يسأل الناس سؤالًا، هل يمكنني استخدام حلول التخويل العامة ومراقبة الوصول بناءً على الدور لتحقيق عزل المستأجر؟
يمكنك بناء تطبيق تعددية مستأجر ولكن لا يمكنك القول أنك حققت واستخدمت استراتيجيات عزل المستأجر كأفضل ممارسة. لا نوصي بذلك عمومًا لأن عزل المستأجر منفصل عن المصادقة (Authentication) والتفويض (Authorization).
لتوضيح الأمر، فكر في حالة قمت فيها بإعداد المصادقة (Authentication) والتفويض (Authorization) لنظام SaaS الخاص بك. عندما يقوم المستخدمون بتسجيل الدخول، يحصلون على رمز يحتوي على معلومات حول دورهم، تملي ما يمكنهم القيام به في التطبيق. يعزز هذا النهج الأمان ولكنه لا يضمن العزل.
استخدام “المؤسسة” كسياق لتمثيل مستأجر منتج SaaS، لتحقيق عزل المستأجر
الاعتماد فقط على المصادقة (Authentication) والتفويض (Authorization) لن يمنع مستخدمًا لديه الدور الصحيح من الوصول إلى موارد مستأجر آخر. لذا نحتاج إلى تضمين سياق “المستأجر”، مثل معرّف المستأجر، لتقييد الوصول إلى الموارد.
هذا هو المكان الذي يأتي فيه عزل المستأجر. حيث يستخدم معرفات خاصة بالمستأجر لإنشاء حدود، تمامًا مثل الجدران والأبواب والمفاتيح، لضمان فصل واضح بين المستأجرين.
كيف تُدار الهوية في تطبيقات تعددية المستأجر؟
ناقشنا عزل المستأجر، لكن ماذا عن الهويات؟ كيف تقرر ما إذا كان ينبغي أن تكون هوياتك “معزولة” أم لا؟
غالبًا ما يكون هناك ارتباك حول مفهوم “عزل الهوية”. قد يشير إلى حالات يكون فيها لدى مستخدم حقيقي واحد هويتان في الفهم العام للناس.
- يمكن أن توجد كلتا الهويتين ضمن نظام هوية واحد. على سبيل المثال، قد يكون لدى سارة بريد إلكتروني شخصي مسجل إلى جانب بريد إلكتروني رسمي متصل من خلال تسجيل الدخول الأحادي (SSO).
- يحتفظ المستخدمون بهويتين متميزتين ضمن أنظمة هوية منفصلة، تمثل منتجات منفصلة تمامًا. هذه المنتجات غير مرتبطة تمامًا ببعضها البعض.
أحيانًا، تسمى هذه السيناريوهات “عزل الهوية”، لكن قد لا يساعد هذا المصطلح في اتخاذ القرار.
بدلاً من السؤال عما إذا كنت تحتاج إلى “عزل الهوية”، فكر في ما إذا كانت أجزاء من عملك أو منتجك تتطلب أنظمة هوية منفصلة. هذا سيوجه تصميم النظام الخاص بك. بالنسبة لتطبيقات تعددية المستأجر، في معظم الحالات، يتم مشاركة الهويات، بينما يتم الحفاظ على موارد كل مستأجر بشكل منفصل.
في تطبيقات تعددية المستأجر، يتم مشاركة الهويات عبر المستأجرين، على عكس الموارد والبيانات الخاصة بكل مستأجر. إنه مثل أن تكون مسؤولًا عن مبنى - لا ترغب في الاحتفاظ بقائمتين منفصلتين لأسماء المستأجرين.
عند السعي لتحقيق عزل المستأجر، يظهر مصطلح “المؤسسة” غالبًا، إذ إنه أفضل ممارسة لبناء تطبيقات متعددة المستأجر.
باستخدام “المؤسسة” في العديد من خدمات إدارة هوية العملاء (CIAM) أو خدمات Auth، يمكنك تحقيق عزل المستأجر في تطبيق تعددية المستأجر الخاص بك مع الحفاظ على نظام هوية موحد.
كيف تختار نماذج التفويض المناسبة لتحكم أفضل في الوصول؟
عند اختيار نموذج التفويض المناسب، احرص على النظر في هذه الأسئلة:
- هل تقوم بتطوير منتجات B2C، B2B، أو مزيج من الاثنين؟
- هل يحتوي التطبيق الخاص بك على بنية تعددية المستأجر؟
- هل هناك حاجة لمستوى معين من العزل في التطبيق الخاص بك، كما يحددها وحدة الأعمال؟
- ما الأذونات والأدوار التي تحتاج إلى تعريفها في سياق المؤسسة، وأيها ليست كذلك؟