مشاركة عبر

المجالات في Azure Front Door

  • مقالة

يمثل المجال اسم مجال مخصص يستخدمه Azure Front Door لتلقي حركة مرور التطبيق الخاص بك. يدعم Azure Front Door إضافة ثلاثة أنواع من أسماء المجالات:

  • المجالات الفرعية هي النوع الأكثر شيوعا لاسم المجال المخصص. مثال على المجال الفرعي هو myapplication.contoso.com.
  • لا تحتوي مجالات Apex على مجال فرعي. مثال على مجال الذروة هو contoso.com. لمزيد من المعلومات حول استخدام مجالات الذروة مع Azure Front Door، راجع مجالات Apex.
  • تسمح مجالات أحرف البدل باستلام نسبة استخدام الشبكة لأي مجال فرعي. مثال على مجال حرف البدل هو *.contoso.com. لمزيد من المعلومات حول استخدام مجالات أحرف البدل مع Azure Front Door، راجع مجالات أحرف البدل.

تتم إضافة المجالات إلى ملف تعريف Azure Front Door. يمكنك استخدام مجال في مسارات متعددة داخل نقطة نهاية، إذا كنت تستخدم مسارات مختلفة في كل مسار.

لمعرفة كيفية إضافة مجال مخصص إلى ملف تعريف Azure Front Door، راجع تكوين مجال مخصص على Azure Front Door باستخدام مدخل Microsoft Azure.

تكوين DNS

عند إضافة مجال إلى ملف تعريف Azure Front Door، يمكنك تكوين سجلين في خادم DNS:

  • سجل DNS TXT، وهو مطلوب للتحقق من ملكية اسم المجال الخاص بك. لمزيد من المعلومات حول سجلات DNS TXT، راجع التحقق من صحة المجال.
  • سجل DNS CNAME، الذي يتحكم في تدفق حركة مرور الإنترنت إلى Azure Front Door.

تلميح

يمكنك إضافة اسم مجال إلى ملف تعريف Azure Front Door قبل إجراء أي تغييرات DNS. يمكن أن يكون هذا الأسلوب مفيدا إذا كنت بحاجة إلى تعيين تكوين Azure Front Door معا، أو إذا كان لديك فريق منفصل يغير سجلات DNS الخاصة بك.

يمكنك أيضا إضافة سجل DNS TXT للتحقق من صحة ملكية المجال قبل إضافة سجل CNAME للتحكم في تدفق حركة المرور. يمكن أن يكون هذا الأسلوب مفيدا لتجنب مواجهة وقت تعطل الترحيل إذا كان لديك تطبيق قيد الإنتاج بالفعل.

التحقق من صحة المجال

يجب التحقق من صحة جميع المجالات المضافة إلى Azure Front Door. يساعد التحقق من الصحة على حمايتك من التكوين الخاطئ العرضي، كما يساعد على حماية الأشخاص الآخرين من تزييف المجال. في بعض الحالات، يمكن التحقق مسبقا من المجالات بواسطة خدمة Azure أخرى. وإلا، تحتاج إلى اتباع عملية التحقق من صحة مجال Azure Front Door لإثبات ملكيتك لاسم المجال.

  • المجالات التي تم التحقق من صحتها مسبقا من Azure هي المجالات التي تم التحقق من صحتها بواسطة خدمة Azure أخرى مدعومة. إذا قمت بإلحاق مجال والتحقق من صحته إلى خدمة Azure أخرى، ثم قمت بتكوين Azure Front Door لاحقا، فقد تعمل مع مجال متحقق منه مسبقا. لا تحتاج إلى التحقق من صحة المجال من خلال Azure Front Door عند استخدام هذا النوع من المجال.

    إشعار

    لا يقبل Azure Front Door حاليا سوى المجالات التي تم التحقق من صحتها مسبقا والتي تم تكوينها باستخدام Azure Static Web Apps.

  • المجالات التي لم يتم التحقق من صحتها من Azure هي مجالات لم يتم التحقق من صحتها من قبل خدمة Azure المدعومة. يمكن استضافة نوع المجال هذا مع أي خدمة DNS، بما في ذلك Azure DNS، ويتطلب التحقق من صحة ملكية المجال بواسطة Azure Front Door.

التحقق من صحة سجل TXT

للتحقق من صحة مجال، تحتاج إلى إنشاء سجل DNS TXT. يجب أن يكون اسم سجل TXT من النموذج _dnsauth.{subdomain}. يوفر Azure Front Door قيمة فريدة لسجل TXT الخاص بك عند البدء في إضافة المجال إلى Azure Front Door.

على سبيل المثال، افترض أنك تريد استخدام المجال myapplication.contoso.com الفرعي المخصص مع Azure Front Door. أولا، يجب إضافة المجال إلى ملف تعريف Azure Front Door الخاص بك، وملاحظة قيمة سجل TXT التي تحتاج إلى استخدامها. بعد ذلك، يجب تكوين سجل DNS بالخصائص التالية:

الخاصية القيمة
اسم السجل _dnsauth.myapplication
قيمة السجل استخدام القيمة التي يوفرها Azure Front Door
مدة البقاء (TTL) ساعة

بعد التحقق من صحة مجالك بنجاح، يمكنك حذف سجل TXT بأمان من خادم DNS.

لمزيد من المعلومات حول إضافة سجل DNS TXT لمجال مخصص، راجع تكوين مجال مخصص على Azure Front Door باستخدام مدخل Microsoft Azure.

حالات التحقق من صحة المجال

يسرد الجدول التالي حالات التحقق من الصحة التي قد يعرضها المجال.

حالة التحقق من صحة المجال الوصف والإجراءات
Submitting يتم إنشاء المجال المخصص.

انتظر حتى يكون مورد المجال جاهزا.
معلق تم إنشاء قيمة سجل DNS TXT، وAzure Front Door جاهز لإضافة سجل DNS TXT.

أضف سجل DNS TXT إلى موفر DNS، وانتظر حتى يكتمل التحقق من الصحة. إذا ظلت الحالة معلق حتى بعد تحديث سجل TXT مع موفر DNS، فحدد إعادة كتابة لتحديث سجل TXT ثم أضف سجل TXT إلى موفر DNS مرة أخرى.
إعادة التحقق المعلقة الشهادة المدارة أقل من 45 يوما من انتهاء صلاحيتها.

إذا كان لديك سجل CNAME يشير بالفعل إلى نقطة نهاية Azure Front Door، فلا يلزم اتخاذ أي إجراء لتجديد الشهادة. إذا تم الإشارة إلى المجال المخصص إلى سجل CNAME آخر، فحدد حالة إعادة التحقق من الصحة المعلقة، ثم حدد إعادة إنشاء في صفحة التحقق من صحة المجال المخصص. وأخيراً، حدد إضافة إذا كنت تستخدم Azure DNS، أو أضف سجل TXT يدوياً باستخدام إدارة DNS لموفر DNS الخاص بك.
تحديث رمز التحقق من الصحة المميز ينتقل المجال إلى حالة تحديث رمز التحقق من الصحة المميز لفترة وجيزة بعد تحديد الزر إعادة كتابة. بمجرد إصدار قيمة سجل TXT جديدة، تتغير الحالة إلى معلق.
لا توجد أية إجراءات مطلوبة.
‏‫‏‫موافق عليها تم التحقق من صحة المجال بنجاح، ويمكن ل Azure Front Door قبول نسبة استخدام الشبكة التي تستخدم هذا المجال.

لا توجد أية إجراءات مطلوبة.
مرفوض رفض موفر/مرجع الشهادة إصدار الشهادة المدارة. على سبيل المثال، قد يكون اسم المجال غير صالح.

حدد الارتباط مرفوض ثم حدد إعادة كتابة في صفحة التحقق من صحة المجال المخصص، كما هو موضح في لقطات الشاشة أسفل هذا الجدول. ثم حدد إضافة لإضافة سجل TXT في موفر DNS.
المهلة لم تتم إضافة سجل TXT إلى موفر DNS في غضون سبعة أيام، أو تمت إضافة سجل DNS TXT غير صالح.

حدد ارتباط المهلة، ثم حدد إعادة كتابة في صفحة التحقق من صحة المجال المخصص. ثم حدد إضافة لإضافة سجل TXT جديد إلى موفر DNS. تأكد من استخدام القيمة المحدثة.
خطأ داخلي حدث خطأ غير معروف.

أعد محاولة التحقق من الصحة عن طريق تحديد الزر تحديث أو إعادة إنشاء . إذا كنت لا تزال تواجه مشكلات، فقم بإرسال طلب دعم إلى دعم Azure.

إشعار

  • TTL الافتراضي لسجلات TXT هو ساعة واحدة. عندما تحتاج إلى إعادة إنشاء سجل TXT لإعادة التحقق من الصحة، من فضلك انتبه إلى TTL لسجل TXT السابق. في حال لم تنتهي صلاحيتها، فسيفشل التحقق من الصحة حتى تنتهي صلاحية سجل TXT السابق.
  • في حال لم يعمل الزر Regenerate فاحذف المجال وأعد إنشاءه.
  • في حال لم تعكس حالة المجال كما هو متوقع، فحدد الزر Refresh.

HTTPS للمجالات المخصصة

باستخدام بروتوكول HTTPS على مجالك المخصص، فإنك تضمن تسليم بياناتك الحساسة بأمان باستخدام تشفير TLS/SSL عند إرسالها عبر الإنترنت. عندما يتصل عميل، مثل مستعرض ويب، بموقع ويب باستخدام HTTPS، يتحقق العميل من صحة شهادة أمان موقع الويب، ويضمن إصدارها من قبل مرجع مصدق شرعي. توفر هذه العملية الأمان وتحمي تطبيقات الويب خاصتك من الهجمات.

يدعم Azure Front Door استخدام HTTPS مع المجالات الخاصة بك، ويزيل إدارة شهادات أمان طبقة النقل (TLS) من خوادم الأصل. عند استخدام المجالات المخصصة، يمكنك إما استخدام شهادات TLS المدارة من Azure (مستحسن)، أو يمكنك شراء شهادات TLS الخاصة بك واستخدامها.

لمزيد من المعلومات حول كيفية عمل Azure Front Door مع TLS، راجع TLS من طرف إلى طرف باستخدام Azure Front Door.

شهادات TLS المدارة بواسطة Azure Front Door

يمكن ل Azure Front Door إدارة شهادات TLS تلقائيا للمجالات الفرعية ومجالات الذروة. عند استخدام الشهادات المدارة، لا تحتاج إلى إنشاء مفاتيح أو طلبات توقيع شهادة، ولا تحتاج إلى تحميل الشهادات أو تخزينها أو تثبيتها. بالإضافة إلى ذلك، يمكن ل Azure Front Door تدوير (تجديد) الشهادات المدارة تلقائيا دون أي تدخل بشري. تتجنب هذه العملية وقت التعطل الناجم عن فشل تجديد شهادات TLS في الوقت المناسب.

يمكن أن تستغرق عملية إنشاء شهادة TLS مدارة وإصدارها وتثبيتها من عدة دقائق إلى ساعة لإكمالها، وأحيانا قد تستغرق وقتا أطول.

إشعار

يتم تدوير الشهادات المدارة ل Azure Front Door (قياسي ومميز) تلقائيا إذا كان سجل CNAME للمجال يشير مباشرة إلى نقطة نهاية Front Door أو يشير بشكل غير مباشر إلى نقطة نهاية Traffic Manager. وإلا، تحتاج إلى إعادة التحقق من صحة ملكية المجال لتدوير الشهادات.

أنواع المجالات

يلخص الجدول التالي الميزات المتوفرة مع شهادات TLS المدارة عند استخدام أنواع مختلفة من المجالات:

الاعتبار فرعي مجال Apex مجال Wildcard
شهادات TLS المدارة متاحة ‏‏نعم‬ نعم لا
يتم تدوير شهادات TLS المدارة تلقائيا ‏‏نعم‬ انظر أدناه لا

عند استخدام شهادات TLS المدارة بواسطة Azure Front Door مع مجالات الذروة، قد يتطلب منك تدوير الشهادة التلقائي إعادة التحقق من ملكية المجال. لمزيد من المعلومات، راجع مجالات Apex في Azure Front Door.

إصدار الشهادة المدارة

يتم إصدار شهادات Azure Front Door من قبل المرجع المصدق الشريك لدينا، DigiCert. لبعض المجالات، يجب أن تسمح صراحة لـ DigiCert كمصدر شهادات بإنشاء سجل مجال CAA بالقيمة: 0 issue digicert.com.

يدير Azure الشهادات بشكل كامل نيابة عنك، لذلك يمكن تغيير أي جانب من جوانب الشهادة المدارة، بما في ذلك مصدر الجذر، في أي وقت. هذه التغييرات خارجة عن سيطرتك. تأكد من تجنب التبعيات الثابتة على أي جانب من جوانب الشهادة المدارة، مثل التحقق من بصمة إبهام الشهادة، أو التثبيت على الشهادة المدارة أو أي جزء من التسلسل الهرمي للشهادة. إذا كنت بحاجة إلى تثبيت الشهادات، فيجب عليك استخدام شهادة TLS مدارة من قبل العميل، كما هو موضح في القسم التالي.

شهادات TLS التي يديرها العميل

في بعض الأحيان، قد تحتاج إلى توفير شهادات TLS الخاصة بك. تتضمن السيناريوهات الشائعة لتوفير الشهادات الخاصة بك ما يلي:

  • تتطلب مؤسستك منك استخدام الشهادات الصادرة عن مرجع مصدق معين.
  • تريد أن يصدر Azure Key Vault شهادتك باستخدام مرجع شهادة شريك.
  • تحتاج إلى استخدام شهادة TLS التي يتعرف عليها تطبيق العميل.
  • تحتاج إلى استخدام نفس شهادة TLS على أنظمة متعددة.
  • يمكنك استخدام مجالات أحرف البدل. لا يوفر Azure Front Door شهادات مدارة لمجالات أحرف البدل.

إشعار

  • اعتبارا من سبتمبر 2023، يدعم Azure Front Door إحضار الشهادات الخاصة بك (BYOC) للتحقق من صحة ملكية المجال. يوافق Front Door على ملكية المجال إذا كان اسم الشهادة (CN) أو الاسم البديل للموضوع (SAN) للشهادة يطابق المجال المخصص. إذا حددت شهادة Azure المدارة، فإن التحقق من صحة المجال يستخدم سجل DNS TXT.
  • بالنسبة للمجالات المخصصة التي تم إنشاؤها قبل التحقق من الصحة المستند إلى BYOC، وحالة التحقق من صحة المجال غير معتمدة، تحتاج إلى تشغيل الموافقة التلقائية للتحقق من صحة ملكية المجال عن طريق تحديد حالة التحقق من الصحة والنقر على الزر إعادة التحقق في المدخل. إذا كنت تستخدم أداة سطر الأوامر، يمكنك تشغيل التحقق من صحة المجال عن طريق إرسال طلب PATCH فارغ إلى واجهة برمجة تطبيقات المجال.

متطلبات الشهادة

لاستخدام شهادتك مع Azure Front Door، يجب أن تفي بالمتطلبات التالية:

  • سلسلة الشهادات الكاملة: عند إنشاء شهادة TLS/SSL، يجب إنشاء سلسلة شهادات كاملة مع مرجع مصدق مسموح به (CA) يشكل جزءا من قائمة المرجع المصدق الموثوق به من Microsoft. إذا كنت تستخدم مرجعا مصدقا غير مسموح به، يتم رفض طلبك. يجب أن يكون المرجع المصدق الجذر مشمولاً في قائمة المراجع المصدقة الموثوقة من Microsoft. إذا تم تقديم شهادة دون سلسلة كاملة، فلن يتم ضمان عمل الطلبات التي تتضمن تلك الشهادة كما هو متوقع.
  • الاسم الشائع: يجب أن يتطابق الاسم الشائع (CN) للشهادة مع المجال الذي تم تكوينه في Azure Front Door.
  • الخوارزمية: لا يدعم Azure Front Door الشهادات مع خوارزميات تشفير المنحنى الناقص (EC).
  • نوع الملف (المحتوى): يجب تحميل شهادتك إلى مخزن المفاتيح الخاص بك من ملف PFX، والذي يستخدم application/x-pkcs12 نوع المحتوى.

استيراد شهادة إلى Azure Key Vault

يجب استيراد شهادات TLS المخصصة إلى Azure Key Vault قبل أن تتمكن من استخدامه مع Azure Front Door. لمعرفة كيفية استيراد شهادة إلى مخزن مفاتيح، راجع البرنامج التعليمي: استيراد شهادة في Azure Key Vault.

يجب أن يكون مخزن المفاتيح في نفس اشتراك Azure مثل ملف تعريف Azure Front Door.

تحذير

يدعم Azure Front Door فقط خزائن المفاتيح في نفس الاشتراك مثل ملف تعريف Front Door. سيؤدي اختيار مخزن مفاتيح ضمن اشتراك مختلف عن ملف تعريف Azure Front Door إلى فشل.

يجب تحميل الشهادات ككائن شهادة، وليس كبيانات سرية.

منح حق الوصول إلى Azure Front Door

يحتاج Azure Front Door إلى الوصول إلى مخزن المفاتيح لقراءة شهادتك. تحتاج إلى تكوين كل من جدار حماية شبكة المخزن الرئيسي والتحكم في الوصول إلى المخزن.

إذا تم تمكين قيود الوصول إلى الشبكة في المخزن الرئيسي، فيجب عليك تكوين مخزن المفاتيح للسماح لخدمات Microsoft الموثوقة بتجاوز جدار الحماية.

هناك طريقتان يمكنك من خلالهما تكوين التحكم في الوصول على مخزن المفاتيح الخاص بك:

  • يمكن ل Azure Front Door استخدام هوية مدارة للوصول إلى مخزن المفاتيح الخاص بك. يمكنك استخدام هذا الأسلوب عندما يستخدم مخزن المفاتيح مصادقة Microsoft Entra. لمزيد من المعلومات، راجع استخدام الهويات المدارة مع Azure Front Door Standard/Premium.
  • بدلا من ذلك، يمكنك منح حق الوصول الأساسي لخدمة Azure Front Door إلى مخزن المفاتيح الخاص بك. يمكنك استخدام هذا الأسلوب عند استخدام نهج الوصول إلى المخزن.

إضافة شهادتك المخصصة إلى Azure Front Door

بعد استيراد شهادتك إلى مخزن مفاتيح، أنشئ موردا سريا ل Azure Front Door، وهو مرجع إلى الشهادة التي أضفتها إلى مخزن المفاتيح الخاص بك.

ثم قم بتكوين مجالك لاستخدام سر Azure Front Door لشهادة TLS الخاصة به.

للحصول على إرشادات إرشادية لهذه الخطوات، راجع تكوين HTTPS على مجال Azure Front Door المخصص باستخدام مدخل Microsoft Azure.

التبديل بين أنواع الشهادات

يمكنك تغيير مجال بين استخدام شهادة مدارة بواسطة Azure Front Door وشهادة يديرها المستخدم.

  • قد يستغرق نشر الشهادة الجديدة ما يصل إلى ساعة عند التبديل بين أنواع الشهادات.
  • إذا كانت حالة المجال الخاصة بك معتمدة، فلن يؤدي تبديل نوع الشهادة بين شهادة مدارة من قبل المستخدم وشهادة مدارة إلى أي توقف.
  • عند التبديل إلى شهادة مدارة، يستمر Azure Front Door في استخدام الشهادة السابقة حتى تتم إعادة التحقق من ملكية المجال وتصبح حالة المجال معتمدة.
  • إذا قمت بالتبديل من BYOC إلى الشهادة المدارة، يلزم إعادة التحقق من المجال. إذا قمت بالتبديل من الشهادة المدارة إلى BYOC، فلن يطلب منك إعادة التحقق من المجال.

تجديد الشهادة

تجديد الشهادات المدارة بواسطة Azure Front Door

بالنسبة لمعظم المجالات المخصصة، يقوم Azure Front Door تلقائيا بتجديد (تدوير) الشهادات المدارة عندما تكون قريبة من انتهاء صلاحيتها، ولا تحتاج إلى القيام بأي شيء.

ومع ذلك، لن يقوم Azure Front Door تلقائيا بتدوير الشهادات في السيناريوهات التالية:

  • يشير سجل CNAME للمجال المخصص إلى سجل DNS غير مجال نقطة نهاية Azure Front Door.
  • يشير المجال المخصص إلى نقطة نهاية Azure Front Door من خلال سلسلة. على سبيل المثال، إذا كان سجل DNS يشير إلى Azure Traffic Manager، والذي بدوره يتحول إلى Azure Front Door، فإن سلسلة CNAME هي contoso.com CNAME في contoso.trafficmanager.net CNAME في contoso.z01.azurefd.net. لا يمكن ل Azure Front Door التحقق من السلسلة بأكملها.
  • يستخدم المجال المخصص سجل A. نوصي دائما باستخدام سجل CNAME للإشارة إلى Azure Front Door.
  • المجال المخصص هو مجال قمة ويستخدم تسوية CNAME.

إذا كان أحد السيناريوهات أعلاه ينطبق على المجال المخصص الخاص بك، ثم قبل 45 يوما من انتهاء صلاحية الشهادة المدارة ، تصبح حالة التحقق من صحة المجال Pending Revalidation. تشير حالة إعادة التحقق المعلقة إلى أنك بحاجة إلى إنشاء سجل DNS TXT جديد لإعادة التحقق من ملكية المجال.

إشعار

تنتهي صلاحية سجلات DNS TXT بعد سبعة أيام. إذا قمت مسبقا بإضافة سجل TXT للتحقق من صحة المجال إلى خادم DNS الخاص بك، فستحتاج إلى استبداله بسجل TXT جديد. تأكد من استخدام القيمة الجديدة، وإلا ستفشل عملية التحقق من صحة المجال.

إذا تعذر التحقق من صحة مجالك، تصبح حالة التحقق من صحة المجال مرفوضة. تشير هذه الحالة إلى أن المرجع المصدق قد رفض طلب إعادة إصدار شهادة مدارة.

لمزيد من المعلومات حول حالات التحقق من صحة المجال، راجع حالات التحقق من صحة المجال.

تجديد الشهادات المدارة من Azure للمجالات التي تم التحقق مسبقا من قبل خدمات Azure الأخرى

يتم تدوير الشهادات المدارة من Azure تلقائيا بواسطة خدمة Azure التي تتحقق من صحة المجال.

تجديد شهادات TLS التي يديرها العميل

عند تحديث الشهادة في مخزن المفاتيح الخاص بك، يمكن ل Azure Front Door الكشف عن الشهادة المحدثة واستخدامها تلقائيا. لكي تعمل هذه الوظيفة، قم بتعيين الإصدار السري إلى "الأحدث" عند تكوين شهادتك في Azure Front Door.

إذا حددت إصدارا معينا من الشهادة، يجب عليك إعادة تحديد الإصدار الجديد يدويا عند تحديث الشهادة.

يستغرق توزيع الإصدار الجديد من الشهادة أو السر تلقائيًا ما يصل إلى 72 ساعة.

إذا كنت تريد تغيير الإصدار السري من "الأحدث" إلى إصدار محدد أو العكس، فأضف شهادة جديدة.

نُهج أمان Azure

يمكنك استخدام جدار حماية تطبيق الويب (WAF) الخاص ب Azure Front Door لفحص الطلبات إلى تطبيقك بحثا عن التهديدات، وفرض متطلبات الأمان الأخرى.

لاستخدام WAF مع مجال مخصص، استخدم مورد نهج أمان Azure Front Door. يربط نهج الأمان مجالا بنهج WAF. يمكنك اختياريا إنشاء نهج أمان متعددة بحيث يمكنك استخدام نهج WAF مختلفة مع مجالات مختلفة.

الخطوات التالية