كلما وصل طلب إلى التطبيق الخاص بك، تحتاج إلى تحديد المستأجر الذي تم إعداد الطلب له. عندما تكون لديك بنية أساسية خاصة بالمستأجر قد تتم استضافتها حتى في مناطق جغرافية مختلفة، تحتاج إلى مطابقة الطلب الوارد إلى مستأجر. بعد ذلك، يجب إعادة توجيه الطلب إلى البنية الأساسية الفعلية التي تستضيف موارد هذا المستأجر، كما هو موضح أدناه:
في هذه الصفحة، نقدم إرشادات لصانعي القرار التقنيين حول الأساليب التي يمكنك وضعها في الاعتبار لتعيين الطلبات إلى المستأجر المناسب والمقايضات المتضمنة في الأساليب.
إشعار
تناقش هذه الصفحة في الغالب التطبيقات المستندة إلى HTTP، مثل مواقع الويب وواجهات برمجة التطبيقات. ومع ذلك، تنطبق العديد من المبادئ الأساسية نفسها على التطبيقات متعددة المستأجرين التي تستخدم بروتوكولات اتصال أخرى.
نهج لتحديد المستأجرين
هناك طرق متعددة يمكنك من خلالها تحديد المستأجر لطلب وارد.
أسماء المجال
إذا كنت تستخدم أسماء المجالات أو المجالات الفرعية الخاصة بالمستأجر، فمن المحتمل أنه يمكن بسهولة تعيين الطلبات إلى المستأجرين باستخدام Host العنوان أو عنوان HTTP آخر يتضمن اسم المضيف الأصلي لكل طلب.
ومع ذلك، ضع في اعتبارك الأسئلة التالية:
- كيف سيعرف المستخدمون اسم المجال الذي يجب استخدامه للوصول إلى الخدمة؟
- هل لديك نقطة إدخال مركزية، مثل صفحة مقصودة أو صفحة تسجيل دخول، يستخدمها جميع المستأجرين؟ إذا قمت بذلك، فكيف سيحدد المستخدمون المستأجر الذي يحتاجون إلى الوصول إليه؟
- ما المعلومات الأخرى التي تستخدمها للتحقق من الوصول إلى المستأجر، مثل رموز التخويل المميزة؟ هل تتضمن الرموز المميزة للتخويل أسماء المجالات الخاصة بالمستأجر؟
خصائص طلب HTTP
إذا لم تستخدم أسماء المجالات الخاصة بالمستأجر، فقد لا تزال قادراً على استخدام جوانب طلب HTTP لتحديد المستأجر الذي يوجد طلب معين له. على سبيل المثال، ضع في اعتبارك طلب HTTP الذي يعرف اسم المستأجر على أنه tailwindtraders. قد يتم توصيل هذا باستخدام ما يلي:
- بنية مسار URL، مثل
https://app.contoso.com/tailwindtraders/. - سلسلة استعلام في عنوان URL، مثل
https://contoso.com/app?tenant=tailwindtraders. - عنوان طلب HTTP مخصص، مثل
X-Tenant-Id: tailwindtraders.
هام
رؤوس طلبات HTTP المخصصة غير مفيدة، حيث يتم إصدار طلبات HTTP GET من مستعرض ويب، أو حيث يتم التعامل مع الطلبات من قبل بعض أنواع وكيل الويب. يجب استخدام عناوين HTTP المخصصة لعمليات GET فقط عند إنشاء واجهة برمجة تطبيقات، أو إذا كنت تتحكم في العميل الذي يصدر الطلب ولا يوجد وكيل ويب مضمن في سلسلة معالجة الطلب.
عند استخدام هذا الأسلوب، يجب مراعاة الأسئلة التالية:
- هل سيعرف المستخدمون كيفية الوصول إلى الخدمة؟ على سبيل المثال، إذا كنت تستخدم سلسلة استعلام لتحديد المستأجرين، هل ستحتاج الصفحة المقصودة المركزية إلى توجيه المستخدمين إلى المستأجر الصحيح، عن طريق إضافة سلسلة الاستعلام؟
- هل لديك نقطة إدخال مركزية، مثل صفحة مقصودة أو صفحة تسجيل دخول، يستخدمها جميع المستأجرين؟ إذا قمت بذلك، فكيف سيحدد المستخدمون المستأجر الذي يحتاجون إلى الوصول إليه؟
- هل يوفر تطبيقك واجهات برمجة التطبيقات؟ على سبيل المثال، هل تطبيق الويب الخاص بك عبارة عن تطبيق من صفحة واحدة (SPA) أو تطبيق محمول مع واجهة برمجة تطبيقات خلفية؟ إذا كان الأمر كذلك، فقد تتمكن من استخدام بوابة واجهة برمجة التطبيقات أو وكيل عكسي لتنفيذ تعيين المستأجر.
مطالبات الرمز المميز
تستخدم العديد من التطبيقات بروتوكولات المصادقة والتخويل المستندة إلى المطالبات، مثل OAuth 2.0 أو SAML. توفر هذه البروتوكولات رموز التخويل المميزة للعميل. يحتوي الرمز المميز على مجموعة من المطالبات، وهي أجزاء من المعلومات حول تطبيق العميل أو المستخدم. يمكن استخدام المطالبات لتوصيل معلومات، مثل عنوان البريد الإلكتروني للمستخدم. يمكن لنظامك بعد ذلك تضمين عنوان البريد الإلكتروني للمستخدم، والبحث عن تعيين المستخدم إلى المستأجر، ثم إعادة توجيه الطلب إلى النشر المناسب. أو، قد تقوم بتضمين تعيين المستأجر في نظام الهوية الخاص بك، وإضافة مطالبة معرف المستأجر إلى الرمز المميز.
إذا كنت تستخدم المطالبات لتعيين الطلبات إلى المستأجرين، يجب مراعاة الأسئلة التالية:
- هل ستستخدم مطالبة لتحديد المستأجر؟ ما المطالبة التي ستستخدمها؟
- هل يمكن للمستخدم أن يكون عضواً في عدة مستأجرين؟ إذا كان هذا ممكناً، فكيف سيختار المستخدمون المستأجرين الذين يرغبون في العمل معهم؟
- هل هناك نظام مصادقة وتخويل مركزي لجميع المستأجرين؟ إذا لم يكن الأمر كما هو، فكيف ستضمن أن جميع سلطات الرمز المميز تصدر رموزاً مميزة ومطالبات متسقة؟
مفتاح API
تعرض العديد من التطبيقات واجهات برمجة التطبيقات. قد تكون هذه الواجهات للاستخدام الداخلي داخل مؤسستك، أو للاستخدام الخارجي من قبل الشركاء أو العملاء. الأسلوب الشائع للمصادقة لواجهات برمجة التطبيقات هو استخدام مفتاح واجهة برمجة التطبيقات. يتم توفير مفاتيح واجهة برمجة التطبيقات مع كل طلب، ويمكن استخدامها للبحث عن المستأجر.
يمكن إنشاء مفاتيح واجهة برمجة التطبيقات بعدة طرق. يتمثل النهج الشائع في إنشاء قيمة عشوائية مشفرة وتخزينها في جدول بحث، جنباً إلى جنب مع معرف المستأجر. عند تلقي طلب، يعثر النظام على مفتاح API في جدول البحث، ثم يطابقه بمعرف المستأجر. هناك نهج آخر يتمثل في إنشاء سلسلة ذات معنى مع معرف مستأجر مضمن داخله، ومن ثم يمكنك توقيع المفتاح رقمياً، باستخدام نهج، مثل التعليمة البرمجية لمصادقة الرسالة المستندة إلى التجزئة. عند معالجة كل طلب، يمكنك التحقق من التوقيع ثم استخراج معرف المستأجر.
إشعار
لا توفر مفاتيح واجهة برمجة التطبيقات مستوى عالياً من الأمان لأنها تحتاج إلى إنشائها وإدارتها يدوياً، ولأنها لا تحتوي على مطالبات. يتمثل النهج الأكثر حداثة وأماناً في استخدام آلية تخويل مستندة إلى المطالبات مع رموز مميزة قصيرة الأجل، مثل OAuth 2.0 أو OpenID Connect.
يؤخذ بعين الاعتبار الأسئلة التالية:
- كيف ستقوم بإنشاء مفاتيح واجهة برمجة التطبيقات وإصدارها؟
- كيف سيتلقى عملاء واجهة برمجة التطبيقات مفتاح API ويخزنونه بأمان؟
- هل تحتاج إلى انتهاء صلاحية مفاتيح واجهة برمجة التطبيقات بعد فترة زمنية؟ كيف ستقوم بتدوير مفاتيح واجهة برمجة التطبيقات الخاصة بعملائك، دون التسبب في وقت تعطل؟
- هل يوفر الاعتماد فقط على مفاتيح واجهة برمجة التطبيقات التي تم طرحها من قبل العميل مستوى مناسباً من الأمان لواجهات برمجة التطبيقات الخاصة بك؟
إشعار
مفاتيح واجهة برمجة التطبيقات ليست هي نفسها كلمات المرور. يجب إنشاء مفاتيح واجهة برمجة التطبيقات بواسطة النظام، ويجب أن تكون فريدة عبر جميع المستأجرين، بحيث يمكن تعيين كل مفتاح API بشكل فريد إلى مستأجر واحد. يمكن لبوابات واجهة برمجة التطبيقات، مثل Azure API Management، إنشاء مفاتيح واجهة برمجة التطبيقات وإدارتها، والتحقق من صحة المفاتيح على الطلبات الواردة، وتعيين مفاتيح لمشتركي API الفرديين.
شهادات العميل
يتم استخدام مصادقة شهادة العميل، التي تسمى أحيانًا TLS المتبادلة (mTLS)، بشكل شائع للاتصال من خدمة إلى خدمة. توفر شهادات العميل طريقة آمنة لمصادقة العملاء. وعلى غرار الرموز المميزة والمطالبات، توفر شهادات العميل سمات يمكن استخدامها لتحديد المستأجر. على سبيل المثال، قد يحتوي موضوع الشهادة على عنوان البريد الإلكتروني للمستخدم، والذي يمكن استخدامه للبحث عن المستأجر.
عند التخطيط لاستخدام شهادات العميل لتعيين المستأجر، ضع في اعتبارك ما يلي:
- كيف ستصدر شهادات العميل التي تثق بها خدمتك وتجددها بأمان؟ يمكن أن تكون شهادات العميل معقدة للعمل معها، لأنها تتطلب بنية أساسية خاصة لإدارة الشهادات وإصدارها.
- هل سيتم استخدام شهادات العميل فقط لطلبات تسجيل الدخول الأولية، أو إرفاقها بجميع الطلبات إلى خدمتك؟
- هل ستصبح عملية إصدار الشهادات وإدارتها غير قابلة لإدارة عندما يكون لديك عدد كبير من العملاء؟
- كيف ستنفذ التعيين بين شهادة العميل والمستأجر؟
وكلاء عكسيون
يمكن استخدام وكيل عكسي، يشار إليه أيضاً باسم وكيل التطبيق، لتوجيه طلبات HTTP. يقبل الوكيل العكسي طلباً من نقطة نهاية دخول، ويمكنه إعادة توجيه الطلب إلى واحدة من العديد من نقاط النهاية الخلفية. يعد الوكلاء العكسيون ذوو أهمية للتطبيقات متعددة المستأجرين، حيث يمكنهم إجراء التعيين بين جزء من معلومات الطلب، وإلغاء تحميل المهمة من البنية الأساسية للتطبيق لديك.
يمكن للعديد من الوكلاء العكسيين استخدام خصائص الطلب لاتخاذ قرار حول توجيه المستأجر. يمكنهم فحص اسم المجال الوجهة ومسار URL وسلسلة الاستعلام ورؤوس HTTP وحتى المطالبات داخل الرموز المميزة.
يتم استخدام الوكلاء العكسيين الشائعين التالين في Azure:
- الواجهة الأمامية لـ Azure هي موازن تحميل عمومي وجدار حماية لتطبيق الويب. يستخدم شبكة Microsoft Edge العالمية لإنشاء تطبيقات ويب سريعة وآمنة وقابلة للتطوير بدرجة كبيرة.
- Azure Application Gateway هو موازن تحميل نسبة استخدام شبكة الويب المدارة التي تقوم بتوزيعها في نفس المنطقة الفعلية كخدمة الواجهة الخلفية.
- تم تحسين Azure API Management لنسبة استخدام شبكة واجهة برمجة التطبيقات.
- تتضمن التقنيات التجارية مفتوحة المصدر (التي تستضيفها بنفسك) nginx وTraefik وHAProxy.
طلب التحقق
من المهم أن يتحقق تطبيقك من أن أي طلبات يتلقاها مصرح بها للمستأجر. على سبيل المثال، إذا كان التطبيق يستخدم اسم مجال مخصصًا لتعيين الطلبات إلى المستأجر، فلا يزال يتعين على التطبيق لديك التحقق من أن كل طلب يتلقاه التطبيق مصرح به لذلك المستأجر. على الرغم من أن الطلب يتضمن اسم مجال أو معرف مستأجر آخر، فإنه لا يعني أنه يجب عليك منح حق الوصول تلقائياً. عند استخدام OAuth 2.0، يمكنك إجراء التحقق من الصحة عن طريق فحص مطالبات الجمهور والنطاق.
إشعار
يعد هذا جزءاً من مبدأ افتراض الثقة المعدومة في تصميم الأمان في Microsoft Azure Well-Architected Framework.
عند تنفيذ التحقق من صحة الطلب، يجب مراعاة ما يلي:
- كيف ستخول جميع الطلبات إلى تطبيقك؟ تحتاج إلى تخويل الطلبات، بغض النظر عن النهج الذي تستخدمه لتعيينها إلى البنية الأساسية المادية.
- استخدم أطر عمل المصادقة والتخويل الموثوق بها والمستخدمة على نطاق واسع والمصانة جيدا والبرامج الوسيطة، بدلا من تنفيذ كل منطق التحقق بنفسك. على سبيل المثال، لا تقم بإنشاء منطق التحقق من صحة توقيع الرمز المميز أو مكتبات تشفير شهادات العميل. بدلاً من ذلك، استخدم ميزات النظام الأساسي للتطبيق (أو الحزم الموثوق بها المعروفة) التي تم التحقق من صحتها واختبارها.
الأداء
من المحتمل أن يعمل منطق تعيين المستأجر على كل طلب إلى التطبيق الخاص بك. ضع في اعتبارك مدى تحجيم عملية تعيين المستأجر، مع نمو الحل الخاص بك. على سبيل المثال، إذا قمت بالاستعلام عن جدول قاعدة بيانات كجزء من تعيين المستأجر، هل ستدعم قاعدة البيانات كمية كبيرة من التحميل؟ إذا كان تعيين المستأجر يتطلب فك تشفير رمز مميز، فهل ستصبح متطلبات الحساب عالية جدا بمرور الوقت؟ إذا كانت نسبة استخدام الشبكة متواضعة إلى حد ما، فمن غير المحتمل أن يؤثر ذلك على الأداء العام. عندما يكون لديك تطبيق واسع النطاق، على الرغم من ذلك، يمكن أن تصبح النفقات العامة المتضمنة في هذا التعيين كبيرة.
تقارب الجلسة
أحد النهج لتقليل النفقات العامة للأداء لمنطق تعيين المستأجر هو استخدام ترابط الجلسة. بدلاً من إجراء التعيين على كل طلب، ضع في اعتبارك حساب المعلومات فقط على الطلب الأول لكل جلسة عمل. ثم يوفر التطبيق الخاص بك ملف تعريف ارتباط جلسة عمل للعميل. يمرر العميل ملف تعريف ارتباط الجلسة مرة أخرى إلى الخدمة الخاصة بك مع جميع طلبات العميل اللاحقة داخل تلك الجلسة.
إشعار
يمكن للعديد من خدمات الشبكات والتطبيقات في Azure إصدار ملفات تعريف الارتباط للجلسة وتوجيه الطلبات في الأصل باستخدام ترابط الجلسة.
يؤخذ بعين الاعتبار الأسئلة التالية:
- هل يمكنك استخدام ترابط الجلسة لتقليل النفقات العامة لتعيين الطلبات إلى المستأجرين؟
- ما الخدمات التي تستخدمها لتوجيه الطلبات إلى عمليات التوزيع الفعلية لكل مستأجر؟ هل تدعم هذه الخدمات ترابط الجلسة المستندة إلى ملفات تعريف الارتباط؟
ترحيل المستأجر
غالباً ما يحتاج المستأجرون إلى نقلهم إلى بنية أساسية جديدة كجزء من دورة حياة المستأجر. عند نقل مستأجر إلى توزيع جديد، قد تتغير نقاط نهاية HTTP التي يصلون إليها. عند حدوث ذلك، ضع في اعتبارك أن عملية تعيين المستأجر تحتاج إلى تحديث. قد تحتاج إلى مراعاة ما يلي:
- إذا كان التطبيق لديك يستخدم أسماء المجالات لطلبات التعيين، فقد يتطلب أيضاً تغيير DNS في وقت الترحيل. قد يستغرق تغيير DNS وقتاً للنشر إلى العملاء، اعتماداً على وقت البقاء لإدخالات DNS في خدمة DNS.
- إذا غير الترحيل عناوين أي نقاط نهاية أثناء عملية الترحيل، ففكر في إعادة توجيه طلبات المستأجر مؤقتاً إلى صفحة صيانة يتم تحديثها تلقائياً.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- دانيال سكوت راينسفورد | الاستراتيجي التكنولوجي الشريك
مساهمون آخرون:
- جون داونز | مهندس العملاء الرئيسي، FastTrack ل Azure
- باولو سالفاتوري | مهندس العملاء الرئيسي، FastTrack for Azure
- Arsen Vladimirskiy | مهندس العملاء الرئيسي، FastTrack for Azure
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
تعرف على الاعتبارات عند العمل مع أسماء المجالات في تطبيق متعدد المستأجرين.