عزل المستأجر في تطبيق متعدد المستأجرين
عزل المستأجر هو مفهوم أساسي في التطبيقات المتعددة المستأجرين. في هذه المقالة، سنناقش ما هو وكيف يمكن تحقيقه.
Product & Design
مرحبًا بالجميع! في هذا الفصل، سنبني على مناقشاتنا السابقة حول مواضيع تعدد المستأجرين. إذا لم تكن قد قرأت المقالات السابقة بعد، نوصي بقراءتها أولاً!
عند مناقشة التطبيقات المتعددة المستأجرين، من المهم التفكير في عزل المستأجرين. يعني هذا إبقاء بيانات وموارد المستأجرين المختلفين منفصلة وآمنة داخل نظام مشترك (على سبيل المثال، بنية تحتية سحابية أو تطبيق متعدد المستأجرين).
الهدف من عزل المستأجرين هو التأكد من أن بيانات وعمليات كل مستأجر تبقى منفصلة وآمنة عن بعضها البعض، حتى عندما يستخدمون نفس الموارد الأساسية.
في سيناريو البرمجيات كخدمة (SaaS)، يتضمن عزل المستأجرين إنشاء هياكل داخل إطار العمل السحابي تنظم بدقة الوصول إلى الموارد. وهذا يمنع أي محاولات غير مصرح بها للوصول إلى موارد مستأجر آخر.
بينما قد يبدو الشرح مجردًا، سنستخدم أمثلة وتفاصيل رئيسية لشرح عقلية العزل بشكل أكبر.
عزل المستأ جرين لا يتعارض مع عقلية "المشاركة" في تعدد المستأجرين
ذلك لأن عزل المستأجرين ليس بالضرورة بنيانًا على مستوى الموارد التحتية. في عالم تعدد المستأجرين والعزل، البعض يرى العزل كقسمة صارمة بين الموارد التحتية الفعلية. عادة ما يؤدي هذا إلى نموذج حيث يكون لكل مستأجر قواعد بيانات وحالات حسابات أو غيوم خاصة منفصلة. في حالات الموارد المشتركة، مثل التطبيقات المتعددة المستأجرين، يمكن تحقيق العزل كهيكل منطقي.
يركز عزل المستأجرين بشكل حصري على استخدام سياق "المستأجر" لتقييد الوصول إلى الموارد. يقوم بتقييم سياق المستأجر الحالي ويستخدم ذلك السياق لتحديد الموارد المتاحة لذلك المستأجر. ويطبق هذا العزل على جميع المستخدمين داخل ذلك المستأجر. يجب تقييد أي محاولة للوصول إلى موارد مستأجر لتلك الموارد التي تنتمي إلى ذلك المستأجر فقط.
العزل يأتي بمستويات مختلفة
عندما نفهم أن العزل ليس مرتبطاً بشكل صارم بمستويات موارد البنية التحتية وليس انفصالًا واضحًا بين البنية التحتية المادية، يؤدي ذلك إلى الاستنتاج التالي:
بدلاً من اعتبار العزل كـ "نعم" أو "لا" بسيط، فكر فيه كطيف. يمكنك إعداد أجزاء من نظامك لتكون أكثر أو أقل عزلاً بناءً على ما تحتاجه.
يوضح الرسم البياني أدناه هذا الطيف من العزل.
المصادقة والتفويض ليسوا متساويين مع "العزل"
استخدام المصادقة والتفويض للتحكم في الوصول إلى بيئات SaaS الخاصة بك مهم، لكنه ليس كافيًا للعزل الكامل. هذه الآليات هي جزء واحد فقط من لغز الأمان.
غالبًا ما يسأل الناس سؤالًا: هل يمكنني استخدام حلول التفويض العامة والتحكم في الوصول المستند إلى الدور لتحقيق عزل المستأجر؟ يمكنك بناء تطبيق متعدد المستأجرين ولكن لا يمكنك القول أنك حققت وأطبقت استراتيجيات عزل المستأجرين كأفضل ممارسة. لا نوصي بذلك عمومًا لأنه
للتوضي ح، فكر في وضع حيث قمت بإعداد المصادقة والتفويض لنظام SaaS الخاص بك. عندما يقوم المستخدمون بتسجيل الدخول، يتلقون رمزًا يحتوى على معلومات حول دورهم، يحدد ما يمكنهم القيام به في التطبيق. تعزز هذه الطريقة الأمان لكنها لا تضمن العزل.
الآن، هنا الجزء الحساس: بدون دمج سياق "المستأجر"، مثل هوية المستأجر، لتقييد الوصول إلى الموارد، الاعتماد فقط على المصادقة والتفويض لن يمنع مستخدمًا ذا الدور الصحيح من الوصول إلى موارد مستأجر آخر.
هذا هو المكان الحيث يأتي عزل المستأجرين ليلعب دوره. يستخدم معرفات محددة للمستأجرين لإنشاء حدود، مثل الجدران والأبواب والأقفال، لضمان فصل واضح بين المستأجرين.
الهوية في التطبيقات متعددة المستأجرين
ناقشنا عزل المستأجرين، ولكن ماذا عن الهويات؟ كيف تقرر إذا كانت هوياتك يجب أن تكون "معزولة" أم لا؟
هناك دائمًا ارتباك حول مفهوم "عزلة الهوية." قد يشير إلى مواقف حيث يكون للمستخدم الواقعي هويتين في الفهم العام للناس.
- يمكن أن توجد كلا الهوية داخل نظام هوية واحد. على سبيل المثال، قد يكون لدى سارة بريد إلكتروني شخصي مسجل إلى جانب بريد إلكتروني للمؤسسة م تصل من خلال تسجيل الدخول الواحد (SSO).
- يحتفظ المستخدمون بهويتين متميزتين داخل أنظمة هوية منفصلة، تمثل منتجات منفصلة تمامًا وغير مرتبطة ببعضها البعض.
في بعض الأحيان، يُشار إلى هذه السيناريوهات بـ "عزلة الهوية." ومع ذلك، قد لا يساعد هذا التصنيف في اتخاذ القرار.
بدلاً من تحديد ما إذا كنت تحتاج إلى "عزلة الهوية," فكر فيما إذا كنت أنت أو قطاع من عملك أو منتجك بحاجة إلى الحفاظ على أنظمة هوية منفصلة. يمكن أن يوجهك هذا الجواب في تصميم نظام إدارة الهوية والوصول (IAM) الخاص بك. للحصول على إجابة موجزة فيما يتعلق بتطبيق متعدد المستأجرين,
في معظم الحالات، في التطبيقات متعددة المستأجرين، تُشارك الهويات بينما يتم عزل موارد كل مستأجر.
في التطبيقات متعددة المستأجرين، تُشارك الهوية، على عكس الموارد والبيانات الخاصة بالمستأجر، بين مستأجرين عدة. تخيل نفسك كمشرف البناء؛ لن ترغب في الحفاظ على ورقتين مختلفتين للأسماء لإدارة هويات مستأجريك.
عند السعي إلى عزل المستأجرين، قد تكون لاحظت التركيز المتكرر على مصطلح "المنظمة," والذي يعتبر غالبًا كأفضل ممارسة لبناء تطبيقات متعددة المستأجرين.
من خلال استخدام مفهوم "المنظمة," يمكنك تحقيق عزل المستأجرين في تطبيقك متعدد المستأجرين مع الحفاظ على نظام هوية موحد. يتيح ذلك وجود عدة "منظمات" بشكل مستقل، ولكن تشارك الموارد العامة داخل التطبيق. مثل الساكنين الذين يعيشون في مبنى، تستخدم كل منظمة التطبيق بدون قلق تجاه جيرانها، حيث توفر "المنظمة" الفصل اللازم في شكل جدران وممرات وأبواب وأقفال. يشاركون البنية التحتية للمبنى بشكل عام، ونظام التصميم الداخلي، ومختلف المكونات الملموسة أو غير الملموسة.
Logto يقدم ميزة "المنظمة" في نوفمبر
Logto في دورة تطوير نشطة لميزة "المنظمة", تستهدف إطلاقها في نوفمبر 2023. تم تصميم هذه الميزة خصيصًا لتلبية متطلبات عزل المستأجر اللازمة لبناء منتج SaaS، بما يتماشى مع المعايير وأفضل الممارسات الصناعية.
في الفصل القادم، سنتعمق أكثر في ميزة "المنظمة" وكيف يسهل Logto تطبيق أفضل الممارسات لبناء تطبيق متعدد المستأجرين.