في العديد من تطبيقات الويب متعددة المستأجرين، يمكن استخدام اسم المجال كطريقة لتحديد المستأجر، وللمساعدة في توجيه الطلبات إلى البنية الأساسية الصحيحة، وتوفير تجربة ذات علامة تجارية لعملائك. هناك نهجان شائعان هما استخدام المجالات الفرعية وأسماء المجالات المخصصة. في هذه الصفحة، نقدم إرشادات لصانعي القرار التقنيين حول النهج التي يمكنك النظر فيها ومفاضلاتهم.
المجالات الفرعية
قد يحصل كل مستأجر على مجال فرعي فريد ضمن اسم مجال مشترك شائع، باستخدام تنسيق مثل tenant.provider.com.
دعونا ننظر في مثال حل متعدد المستأجرين الذي أنشأته Contoso. يشتري العملاء منتج Contoso للمساعدة في إدارة إنشاء الفاتورة. قد يتم تعيين المجال الفرعي الخاص بهم لجميع مستأجري Contoso، تحت contoso.com اسم المجال. أو، إذا كانت Contoso تستخدم عمليات التوزيع الإقليمية، فقد تقوم بتعيين مجالات فرعية us.contoso.com ضمن المجالين و eu.contoso.com . في هذه المقالة، نشير إلى هذه المجالات على أنها مجالات جذع. يحصل كل عميل على مجال فرعي خاص به ضمن مجالك الجذعي. على سبيل المثال، قد يتم تعيين tailwind.contoso.com لـTailwind Toys، وقد يتم تعيين adventureworks.contoso.com لـAdventure Works.
ملاحظة
تستخدم العديد من خدمات Azure هذا النهج. على سبيل المثال، عند إنشاء حساب تخزين Azure، يتم تعيين مجموعة من المجالات الفرعية لاستخدامها، مثل <your account name>.blob.core.windows.net.
إدارة مساحة اسم المجال
عند إنشاء مجالات فرعية تحت اسم المجال الخاص بك، يجب أن تكون على دراية بأنه يمكن أن يكون لديك عملاء متعددون بأسماء مماثلة. نظرا لأنهم يشتركون في مجال جذع واحد، فإن أول عميل يحصل على مجال معين سيحصل على اسمه المفضل. بعد ذلك، يجب على العملاء اللاحقين استخدام أسماء المجالات الفرعية البديلة، لأن أسماء المجالات الكاملة يجب أن تكون فريدة عالميا.
بدل DNS
ضع في اعتبارك استخدام إدخالات DNS لأحرف البدل لتبسيط إدارة المجالات الفرعية. بدلًا من إنشاء إدخالات DNS لـtailwind.contoso.com، وadventureworks.contoso.com، وما إلى ذلك، يمكنك بدلًا من ذلك إنشاء إدخال حرف بدل لـ*.contoso.com وكافة المجالات الفرعية وتوجيهها إلى عنوان IP واحد (سجل) أو اسم متعارف عليه (سجل CNAME).
ملاحظة
تأكد من أن خدمات مستوى الويب تدعم DNS لأحرف البدل، إذا كنت تخطط للاعتماد على هذه الميزة. تدعم العديد من خدمات Azure، بما في ذلك Azure Front Door وAzure App Service، إدخالات DNS لأحرف البدل.
المجالات الفرعية ذات المجالات الجذعية متعددة الأقسام
تنتشر العديد من الحلول متعددة المستأجرين عبر عمليات نشر فعلية متعددة. هذا نهج شائع عندما تحتاج إلى الامتثال لمتطلبات موقع البيانات، أو عندما تريد توفير أداء أفضل عن طريق توزيع الموارد الأقرب جغرافيا إلى المستخدمين.
حتى داخل منطقة واحدة، قد تحتاج أيضا إلى نشر المستأجرين عبر عمليات التوزيع المستقلة، لدعم استراتيجية التحجيم الخاصة بك. إذا كنت تخطط لاستخدام المجالات الفرعية لكل مستأجر، فقد تفكر في بنية نطاق فرعي متعدد الأقسام.
فيما يلي مثال: تنشر شركة Contoso تطبيقًا متعدد المستأجرين لعملائها الأربعة. تقع Adventure Works وTailwind Traders في الولايات المتحدة، ويتم تخزين بياناتها على مثيل أمريكي مشترك لمنصة Contoso. توجد شركة Fabrikam والمستوردون العالميون في أوروبا، ويتم تخزين بياناتهم على مثيل أوروبي.
إذا اختارت شركة Contoso استخدام مجال جذع واحد، contoso.com لجميع عملائها، فإليك الشكل الذي قد يبدو عليه هذا:
قد تبدو إدخالات DNS (المطلوبة لدعم هذا التكوين) كما يلي:
| فرعي | CNAME to |
|---|---|
adventureworks.contoso.com |
us.contoso.com |
tailwind.contoso.com |
us.contoso.com |
fabrikam.contoso.com |
eu.contoso.com |
worldwideimporters.contoso.com |
eu.contoso.com |
يتطلب كل عميل جديد تم إعداده مجالًا فرعيًا جديدًا، ويزداد عدد المجالات الفرعية مع كل عميل.
بدلًا من ذلك، يمكن لـ Contoso استخدام مجالات جذع خاصة بالنشر أو المنطقة، مثل هذا:
بعد ذلك، باستخدام DNS لأحرف البدل، قد تبدو إدخالات DNS لهذا النشر كما يلي:
| فرعي | CNAME to |
|---|---|
*.us.contoso.com |
us.contoso.com |
*.eu.contoso.com |
eu.contoso.com |
لا تحتاج Contoso إلى إنشاء سجلات المجال الفرعي لكل عميل. بدلا من ذلك، لديهم سجل DNS واحد لأحرف البدل لنشر كل جغرافية، وأي عملاء جدد تتم إضافتهم أسفل هذا stem يرثون سجل CNAME تلقائيا.
هناك فوائد وعيوب لكل نهج. عند استخدام مجال جذع واحد، يتطلب كل مستأجر قمت بإلحاقه إنشاء سجل DNS جديد، ما يقدم المزيد من النفقات التشغيلية. ومع ذلك، لديك المزيد من المرونة لنقل المستأجرين بين عمليات التوزيع، لأنه يمكنك تغيير سجل CNAME لتوجيه نسبة استخدام الشبكة الخاصة بهم إلى توزيع آخر. لن يؤثر هذا التغيير على أي مستأجرين آخرين. عند استخدام مجالات جذع متعددة، هناك نفقات إدارية أقل. يمكنك أيضا إعادة استخدام أسماء العملاء عبر مجالات جذع إقليمية متعددة، لأن كل مجال جذع يمثل مساحة الاسم الخاصة به بشكل فعال.
أسماء المجالات المخصصة
قد ترغب في تمكين عملائك من إحضار أسماء المجالات الخاصة بهم. يرى بعض العملاء أن هذا جانب مهم من علاماتهم التجارية. قد تكون أسماء المجالات المخصصة مطلوبة أيضا لتلبية متطلبات أمان العملاء، خاصة إذا كانوا بحاجة إلى توفير شهادات TLS الخاصة بهم. في حين أنه قد يبدو من التافهة تمكين العملاء من إحضار أسماء المجالات الخاصة بهم، هناك بعض التعقيدات المخفية لهذا النهج، ويتطلب الأمر مراعاة مدروسة.
تحليل الاسم
في نهاية المطاف، يجب حل كل اسم مجال إلى عنوان IP. كما رأيت، يمكن أن يعتمد الأسلوب الذي يحدث به تحليل الاسم على ما إذا كنت تنشر مثيلا واحدا أو مثيلات متعددة من الحل الخاص بك.
دعونا نعود إلى مثالنا. طلب أحد عملاء Contoso، Fabrikam، استخدام invoices.fabrikam.com، كاسم مجال مخصص للوصول إلى خدمة Contoso. نظرا لأن Contoso لديها عمليات نشر متعددة للنظام الأساسي الخاص بها، فإنها تقرر استخدام المجالات الفرعية وسجلات CNAME لتحقيق متطلبات التوجيه الخاصة بها. كون Contoso وFabrikam سجلات DNS التالية:
| الاسم | نوع السجل | القيمة | تم التكوين بواسطة |
|---|---|---|---|
invoices.fabrikam.com |
CNAME | fabrikam.eu.contoso.com |
Fabrikam |
*.eu.contoso.com |
CNAME | eu.contoso.com |
"Contoso" |
eu.contoso.com |
A | (عنوان IP الخاص بـContoso) | "Contoso" |
من منظور تحليل الاسم، تحل سلسلة السجلات هذه الطلبات invoices.fabrikam.com بدقة إلى عنوان IP للتوزيع الأوروبي لشركة Contoso.
دقة رأس المضيف
تحليل الاسم هو نصف المشكلة فقط. يجب أن تكون جميع مكونات الويب داخل النشر الأوروبي لشركة Contoso على دراية بكيفية التعامل مع الطلبات التي تصل مع اسم مجال Fabrikam في عنوان الطلب الخاص بها Host . اعتمادا على تقنيات الويب المحددة التي تستخدمها Contoso، قد يتطلب ذلك مزيدا من التكوين لاسم مجال كل مستأجر، ما يضيف حملا تشغيليا إضافيا إلى إلحاق المستأجرين.
يمكنك أيضًا التفكير في إعادة كتابة رؤوس المضيف، بحيث يرى خادم الويب قيمة رأس متناسقة بغض النظر عن عنوان الطلب Host الوارد. على سبيل المثال، يتيح لك Azure Front Door إعادة كتابة Host الرؤوس، بحيث يتلقى خادم التطبيق عنوان Host واحدًا بغض النظر عن الطلب. ينشر Azure Front Door عنوان المضيف الأصلي في X-Forwarded-Host العنوان، بحيث يمكن للتطبيق فحصه ثم البحث عن المستأجر. ومع ذلك، يمكن أن تتسبب إعادة كتابة رأس في Host حدوث مشاكل أخرى. لمزيد من المعلومات، راجع الاحتفاظ باسم المضيف.
التحقق من صحة المجال
من المهم التحقق من صحة ملكية المجالات المخصصة قبل إلحاقها. وإلا، فإنك تخاطر بإيقاف اسم مجال عن طريق الخطأ أو بشكل ضار.
دعونا نفكر في عملية إعداد Contoso لـ Adventure Works، الذين طلبوا استخدام invoices.adventureworks.com كاسم مجال مخصص. لسوء الحظ، قام شخص ما بكتابة خطأ إملائي عندما حاول إلحاق اسم المجال المخصص، وفوت اسم المجال المخصص. لذلك، قاموا بإعداده على أنه invoices.adventurework.com. لا تتدفق نسبة استخدام الشبكة بشكل صحيح ل Adventure Works فحسب، ولكن عندما تحاول شركة أخرى تسمى Adventure Work إضافة مجالها المخصص إلى النظام الأساسي لشركة Contoso، يتم إخبارهم بأن اسم المجال قيد الاستخدام بالفعل.
عند العمل مع المجالات المخصصة، خاصة داخل الخدمة الذاتية أو العملية التلقائية، من الشائع طلب خطوة التحقق من المجال. قد يتطلب ذلك إعداد سجلات CNAME قبل إضافة المجال. بدلًا من ذلك، قد تقوم Contoso بإنشاء سلسلة عشوائية واطلب من Adventure Works إضافة سجل DNS TXT بقيمة السلسلة. من شأن ذلك أن يمنع إضافة اسم المجال، حتى يتم إكمال التحقق.
Dangling DNS وهجمات الاستيلاء على المجال الفرعي
عند العمل مع أسماء المجالات المخصصة، من المحتمل أن تكون عرضة لفئة من الهجوم تسمى DNS المتدلية أو استيلاء المجال الفرعي. يحدث هذا الهجوم عندما يقوم العملاء بفصل اسم المجال المخصص الخاص بهم عن خدمتك، لكنهم لا يحذفون السجل من خادم DNS الخاص بهم. ثم يشير إدخال DNS هذا إلى مورد غير موجود وهو عرضة للاستيلاء.
دعونا نفكر في كيفية تغيير علاقة Fabrikam مع Contoso:
- قررت شركة Fabrikam عدم العمل مع شركة Contoso، وبالتالي فقد أنهوا علاقتهم التجارية.
- قامت شركة Contoso بإيقاف تشغيل مستأجر Fabrikam، وطلبوا لـ
fabrikam.contoso.comعدم العمل بعد الآن. ومع ذلك، نسيت Fabrikam حذف سجل CNAME لـinvoices.fabrikam.com. - يقوم ممثل ضار بإنشاء حساب Contoso جديد ويعطيه الاسم
fabrikam. - يقوم المهاجم بإلحاق اسم المجال المخصص
invoices.fabrikam.comبالمستأجر الجديد. نظرًا لأن Contoso تقوم بالتحقق من صحة المجال المستند إلى CNAME، فإنها تتحقق من خادم DNS الخاص بـFabrikam. يرون أن خادم DNS يرجع سجل CNAME لـinvoices.fabrikam.com، والذي يشير إلىfabrikam.contoso.com. تعتبر Contoso التحقق من صحة المجال المخصص ناجحًا. - إذا حاول أي من موظفي Fabrikam الوصول إلى الموقع، فستظهر الطلبات للعمل. إذا قام المهاجم بإعداد مستأجر Contoso الخاص به باستخدام العلامة التجارية لشركة Fabrikam، فقد ينخدع الموظفون بالوصول إلى الموقع وتوفير البيانات الحساسة، والتي يمكن للمهاجم الوصول إليها.
الاستراتيجيات الشائعة للحماية من هجمات DNS المتدلية هي:
- اطلب حذف سجل CNAME قبل إزالة اسم المجال من حساب المستأجر.
- حظر إعادة استخدام معرفات المستأجر، كما تتطلب من المستأجر إنشاء سجل TXT باسم يطابق اسم المجال وقيمة تم إنشاؤها عشوائيا، والتي تتغير لكل محاولة إلحاق.
شهادات TLS/SSL
أمان طبقة النقل (TLS) هو مكون أساسي عند العمل مع التطبيقات الحديثة. يوفر الثقة والأمان لتطبيقات الويب الخاصة بك. ملكية شهادات TLS وإدارتها أمر يحتاج إلى دراسة متأنية للتطبيقات متعددة المستأجرين.
عادة ما يكون مالك اسم المجال مسؤولًا عن إصدار شهاداته وتجديدها. على سبيل المثال، شركة Contoso مسؤولة عن إصدار وتجديد شهادات TLS لـus.contoso.com، بالإضافة إلى شهادة حرف بدل لـ*.contoso.com. وبالمثل، ستكون Fabrikam مسؤولة بشكل عام عن إدارة أي سجلات للمجال fabrikam.com، بما في ذلك invoices.fabrikam.com. يمكن استخدام نوع سجل DNS ل CAA (تخويل المرجع المصدق) من قبل مالك المجال. تضمن سجلات CAA أن المراجع المحددة فقط يمكنها إنشاء شهادات للمجال.
إذا كنت تخطط للسماح للعملاء بإحضار مجالاتهم الخاصة، ففكر فيما إذا كنت تخطط لإصدار الشهادة نيابة عن العميل، أو ما إذا كان يجب على العملاء إحضار شهاداتهم الخاصة. ولكل خيار فوائد وعيوب.
- إذا قمت بإصدار شهادة لعميل، يمكنك التعامل مع تجديد الشهادة، لذلك لا يتعين على العميل تذكر إبقائها محدثة. ومع ذلك، إذا كان لدى العملاء سجلات CAA على أسماء المجالات الخاصة بهم، فقد يحتاجون إلى تفويضك بإصدار شهادات نيابة عنهم.
- إذا كنت تتوقع أنه يجب على العملاء إصدار الشهادات الخاصة بهم وتزويدك بها، فأنت مسؤول عن تلقي المفاتيح الخاصة وإدارتها بطريقة آمنة، وقد تضطر إلى تذكير عملائك بتجديد الشهادة قبل انتهاء صلاحيتها، لتجنب انقطاع الخدمة.
تدعم العديد من خدمات Azure الإدارة التلقائية للشهادات للمجالات المخصصة. على سبيل المثال، يوفر Azure Front Door وApp Service شهادات للمجالات المخصصة، ويتعاملان تلقائيًا مع عملية التجديد. يؤدي ذلك إلى إزالة عبء إدارة الشهادات من فريق العمليات. ومع ذلك، لا تزال بحاجة إلى النظر في مسألة الملكية والسلطة، مثل ما إذا كانت سجلات CAA سارية المفعول ومكونة بشكل صحيح. تحتاج أيضًا إلى التأكد من تكوين مجالات عملائك للسماح بالشهادات التي يديرها النظام الأساسي.
المساهمون
هذه المقالة تحتفظ بها Microsoft. تمت كتابتها في الأصل من قِبل المساهمين التاليين.
الكاتب الرئيسي:
- جون داونز | مهندس العميل الرئيسي، FastTrack ل Azure
مساهمون آخرون:
- دانيال سكوت راينسفورد | الاستراتيجي التكنولوجي الشريك
- Arsen Vladimirskiy | مهندس العملاء الرئيسي، FastTrack لـAzure
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
تلميح
تستخدم العديد من الخدمات Azure Front Door لإدارة أسماء المجالات. للحصول على معلومات حول كيفية استخدام Azure Front Door في حل متعدد المستأجرين، راجع استخدام Azure Front Door في حل متعدد المستأجرين.
ارجع إلى نظرة عامة على الاعتبارات المعمارية. أو راجع Microsoft Azure Well-Architected Framework.