يمكن أن يكون إنشاء تطبيق متعدد المستأجرين معقدًا. يجمع هذا المقال كل منشوراتنا السابقة حول استراتيجيات متعددة المستأجرين والمنظمات. نأمل أن يساعدك في توفير الوقت والبدء بسهولة.
بناء تطبيق متعدد المستأجرين يمكن أن يكون تحديًا، حيث هناك العديد من الجوانب التي يجب النظر فيها. يجمع هذا المقال جميع مقالات المدونة السابقة لدينا لفهم ممارسات متعددة المستأجرين والمنظمات. للبداية السريعة وتوفير الوقت، فقط تحقق من هذا المقال، فهو يحتوي على كل ما تحتاجه!
يتم تحديد الإرشادات العامة في الخطوات التالية:
تعددية المستأجرين في البرمجيات هي نوع من تصميم البرمجيات حيث يعمل مثيل واحد من البرمجيات على خادم ويخدم العديد من المستأجرين. الأنظمة المصممة بهذه الطريقة تكون "مشتركة" (بدلاً من "مخصصة" أو "معزولة").
المستأجر هو مجموعة من المستخدمين الذين يشاركون في الوصول المشترك مع امتيازات معينة إلى مثيل البرنامج.
أحد العقول الرئيسية في تعددية المستأجرين هو مفهوم "المشتركة". وفقًا للتعريف الأوسع للتعددية، فإن كون التطبيق متعدد المستأجرين لا يعني أن كل مكون في الحل مشترك. بل يعني أن بعض مكونات الحل تُعاد استخدامها عبر العديد من المستأجرين. فهم هذا المصطلح بشكل واسع يساعدك في التعاطف مع احتياجات العملاء ومصادرها.
بمجرد فهم بنية متعددة المستأجرين، تكون الخطوة التالية هي تطبيق تطبيقك على السيناريوهات الواقعية، بالتركيز على الاحتياجات المحددة للمنتج والأعمال.
غالبًا ما تجد التطبيقات متعددة المستأجرين مكانًا لها في حلول الأعمال للأعمال (B2B) مثل أدوات الإنتاجية، وبرامج التعاون، وغيرها من المنتجات كخدمة (SaaS). في هذا السياق، يمثّل كل "مستأجر" عادةً عميلاً تجاريًا، قد يكون لديه العديد من المستخدمين (موظفيه). بالإضافة إلى ذلك، قد يكون لدى العميل التجاري العديد من المستأجرين لتمثيل مؤسسات أو أقسام أعمال منفصلة.
تمتد تطبيقات B2B إلى ما وراء منتجات SaaS وغالبًا ما تتضمن استخدام التطبيقات متعددة المستأجرين. في سياقات B2B، تعمل هذه التطبيقات كمنصة مشتركة لمختلف الفرق والعملاء التجاريين وشركات الشركاء للوصول إلى تطبيقاتك.
على سبيل المثال، فكر في شركة مشاركة سيارات توفر تطبيقات لكل من B2C وB2B. تخدم تطبيقات B2B العديد من العملاء التجاريين، ويمكن أن يساعد تطبيق بنية متعددة المستأجرين في إدارة موظفيهم ومواردهم. على سبيل المثال، إذا رغبت الشركة في الحفاظ على نظام هوية موحد للمستخدم، يمكنها تصميم هيكل مثل المثال التالي:
سارة لديها هوية شخصية وتجارية على حد سواء. تستخدم خدمة مشاركة السيارات كراكبة وتعمل أيضًا كسائقة في أوقات فراغها. في دورها المهني، تدير أيضًا عملها وتستخدم هذه الهوية التجارية لتكون شريكة مع الأعمال 1.
بالنسبة للشركات الكبيرة، تعددية المستأجرين هي الأساس لتلبية متطلباتهم بفعالية من حيث التوفر وإدارة الموارد وإدارة التكاليف وأمان البيانات. على المستوى الفني، يعتمد اعتماد نهج متعدد المستأجرين على تبسيط عمليات التطوير لديك، وتقليل التحديات التقنية، وتشجيع التوسع السلس.
عند فحص جذور منتجات SaaS، يشبه ذلك بناء يضم شققًا متنوعة. جميع المستأجرين يشاركون المرافق المشتركة مثل المياه والكهرباء والغاز، ومع ذلك يحتفظون بسيطرة مستقلة على إدارة مساحتهم ومواردهم. يبسط هذا النهج إدارة الممتلكات.
في بنية تعددية المستأجرين، يتم تقديم مصطلح "المستأجر" لإنشاء حدود تفصل بين الموارد والبيانات وتأمينها بين المستأجرين المختلفين ضمن مثيل مشترك. يضمن ذلك بقاء بيانات وعمليات كل مستأجر متميزة وآمنة، حتى إذا كانوا يستخدمون نفس الموارد الأساسية.
عند مناقشة التطبيقات متعددة المستأجرين، يكون من الضروري دائمًا تحقيق عزل المستأجر. يعني ذلك الحفاظ على البيانات والموارد المختلفة للمستأجرين منفصلة وآمنة داخل نظام مشترك (على سبيل المثال، بنية تحتية سحابية أو تطبيق متعدد المستأجرين). يمنع ذلك أي محاولات غير مصرح بها للوصول إلى موارد مستأجر آخر.
بينما قد تبدو التفسير مجردة، سنستخدم أمثلة وتفاصيل رئيسية لشرح عقلية العزل وممارساتها الأفضل.
ذلك لأن عزل المستأجر ليس بالضرورة بناءً على مستوى موارد البنية التحتية. في عالم التعددية والعزل، يرى البعض العزل كتقسيم صارم بين الموارد الفعلية للبنية التحتية. يؤدي ذلك عادةً إلى نموذج حيث يكون لكل مستأجر قواعد بيانات، وحسابات، أو سحابات خاصة منفصلة. في سيناريوهات الموارد المشتركة، مثل التطبيقات متعددة المستأجرين، يمكن أن يكون تحقيق العزل بناءً منطقيًا.
يركز عزل المستأجر بشكل حصري على استخدام "سياق المستأجر" لتحديد الوصول إلى الموارد. يقيم سياق المستأجر الحالي ويستخدم هذا السياق لتحديد الموارد المتاحة لذلك المستأجر.
استخدام المصادقة والتفويض للتحكم في الوصول إلى بيئات SaaS الخاصة بك مهم، ولكنه ليس كافياً للعزل الكامل. تكون هذه الآليات جزءًا واحدًا فقط من الأسهم الأمنية.
غالبًا ما يسأل الناس سؤالًا، هل يمكنني استخدام الحلول العامة للتفويض والتحكم في الوصول القائم على الأدوار لتحقيق عزل المستأجر؟
وإليك الشيء، يمكنك بناء تطبيق متعدد المستأجرين ولكنك لا تستطيع أن تقول إنك قد حققت واستخدمت استراتيجيات عزل المستأجر كممارسة أفضل. لا نوصي بها عمومًا لأن
لتوضيح الأمر، ضع في اعتبارك حالة قمت فيها بإعداد المصادقة والتفويض لنظام SaaS الخاص بك. عندما يقوم المستخدمون بتسجيل الدخول، يتلقون رمزًا يحتوي على معلومات حول دورهم، يحدد ما يمكنهم القيام به في التطبيق. يعزز هذا النهج الأمان ولكنه لا يضمن العزل.
الاعتماد فقط على المصادقة والتفويض لن يمنع مستخدمًا لديه الدور الصحيح من الوصول إلى موارد مستأجر آخر. لذلك نحتاج إلى دمج سياق "المستأجر"، مثل معرف المستأجر، لتقييد الوصول إلى الموارد.
هنا يأتي دور عزل المستأجر. يستخدم معرفات محددة للمستأجر لإنشاء حدود، مثل الجدران، الأبواب، والأقفال، لضمان فصل واضح بين المستأجرين.
ناقشنا عزل المستأجر، ولكن ماذا عن الهويات؟ كيف تقرر ما إذا كانت هوياتك يجب أن تكون "معزولة" أم لا؟
غالبًا ما يكون هناك لبس حول مفهوم "عزل الهوية". قد يشير إلى الحالات التي يكون فيها للمستخدم الواقعي هويتان في الفهم العام للناس.
في بعض الأحيان، تُشار إلى هذه السيناريوهات على أنها "هوية معزولة". لكن هذا المصطلح قد لا يساعد في اتخاذ قرار.
بدلاً من تحديد ما إذا كنت بحاجة إلى "عزل الهوية"، قم بالنظر في
يمكن أن يرشدك هذا الجواب في تصميم النظام الخاص بك. لإجابة موجزة بخصوص تطبيق متعدد المستأجرين،
في التطبيقات متعددة المستأجرين، تُشترك الهويات، على عكس الموارد والبيانات الخاصة بالمستأجر، بين العديد من المستأجرين. تخيل نفسك كمدير بناية؛ لن ترغب في الحفاظ على قائمتين من الأسماء لإدارة هويات مستأجريك.
عند السعي لتحقيق عزل المستأجر، قد تكون لاحظت التكرار المتكرر لمصطلح "المنظمة"، الذي يُعتبر غالبًا كممارسة أفضل لبناء التطبيقات متعددة المستأجرين.
باستخدام مفهوم "المنظمة"، يمكنك تحقيق عزل المستأجر في تطبيقك متعدد المستأجرين مع الحفاظ على نظام هوية موحد.
عند اختيار النموذج المناسب للتفويض، قم بالنظر في هذه الأسئلة:
RBAC (التحكم في الوصول القائم على الأدوار) هو طريقة لمنح أذونات المستخدم بناءً على أدوارهم، مما يمكن التحكم الفعال في الوصول إلى الموارد.
تعتبر هذه التقنية الشائعة جزءًا أساسيًا من ميزات التفويض في Logto. كمنصة متكاملة لإدارة الهويات، تقدم Logto حلولًا مخصصة لمستويات وكيانات مختلفة، مما يلبي احتياجات المطورين والشركات للبنى المعمارية المتنوعة للمنتجات.
لحماية موارد API العامة التي ليست محددة لأي منظمة ولا تحتاج إلى قيود سياقية، فإن ميزة API RBAC مثالية.
فقط قم بتسجيل API وتعيين أذونات لكل مورد. ثم التحكم في الوصول عبر العلاقة بين الأدوار والمستخدمين.
تكون موارد API، والأدوار، والأذونات هنا "مُدمقرطة" ضمن نظام هوية موحد. وهذا شائع إلى حد كبير في المنتجات من نوع B2C مع أقل مستوى من التسلسل الهرمي ولا تحتاج إلى مستوى عميق جدًا من العزل.
في بيئة B2B ومتعددة المستأجرين، يكون عزل المستأجر ضروريًا. لتحقيق ذلك، تُستخدم المنظمات كعنصر سياقي للعزل، مما يعني أن RBAC يكون فعالًا فقط عندما يكون المستخدم ينتمي إلى منظمة معينة.
يُركز التحكم في الوصول القائم على الأدوار للمنظمة على التحكم في الوصول على مستوى المنظمة بدلاً من مستوى API. يوفر ذلك مرونة كبيرة للإدارة الذاتية على مستوى المنظمة على المدى الطويل ولكنه لا يزال ضمن نظام هوية موحد.
ميزة رئيسية للتحكم في الوصول القائم على الأدوار للمنظمة هي أن الأدوار والأذونات تكون بشكل عام موحدة عبر جميع المنظمات بشكل افتراضي، مما يجعل "قالب المنظمة" في Logto ذو فائدة كبيرة في تحسين كفاءة التطوير. يتوافق ذلك مع فلسفة المشاركة لتطبيقات متعددة المستأجرين، حيث تعتبر سياسات الوصول والهويات مكونات بنية تحتية مشتركة عبر جميع المستأجرين (مستأجرين التطبيق)، وهي ممارسة شائعة في منتجات SaaS.
يوفر هذا المقال كل ما تحتاجه للبدء في تجهيز وتكوين التطبيقات متعددة المستأجرين. جرب Logto اليوم وابدأ في تطبيق أفضل الممارسات لتطوير التطبيقات متعددة المستأجرين مع المنظمات.