مشاركة عبر

بروتوكول أمان طبقة النقل من طرف إلى طرف مع Azure Front Door

  • مقالة

هام

سيتم إيقاف دعم TLS 1.0 و1.1 في 1 مارس 2025.

أمان طبقة النقل (TLS)، المعروف سابقا باسم طبقة مآخذ التوصيل الآمنة (SSL)، هو تقنية الأمان القياسية لإنشاء ارتباط مشفر بين خادم ويب وعميل، مثل مستعرض ويب. يضمن هذا الارتباط أن تظل جميع البيانات التي تم تمريرها بين الخادم والعميل خاصة ومشفرة.

لتلبية متطلبات الأمان أو التوافق، يدعم Azure Front Door تشفير TLS الشامل. يؤدي إلغاء تحميل Front Door TLS/SSL إلى إنهاء اتصال TLS، وفك تشفير نسبة استخدام الشبكة في Azure Front Door، وإعادة تشفير حركة المرور قبل إعادة توجيهها إلى الأصل. عندما تستخدم الاتصالات بالأصل عنوان IP العام الخاص بالأصل، فمن الممارسات الأمنية الجيدة تكوين HTTPS كبروتوكول إعادة التوجيه على Azure Front Door. باستخدام HTTPS كبروتوكول إعادة التوجيه، يمكنك فرض تشفير TLS من طرف إلى طرف للمعالجة بأكملها للطلب من العميل إلى الأصل. يتم دعم إلغاء تحميل TLS/SSL أيضا إذا قمت بنشر أصل خاص باستخدام Azure Front Door Premium باستخدام ميزة Private Link .

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

تشفير TLS من طرف إلى طرف

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

يلغي Azure Front Door تحميل جلسات عمل بروتوكول أمان طبقة النقل عند الحافة وفك تشفير طلبات العميل. ثم يطبق قواعد التوجيه المكونة لتوجيه الطلبات إلى الأصل المناسب في مجموعة الأصل. ثم يبدأ Azure Front Door اتصال TLS جديد بالأصل ويعيد تشفير جميع البيانات باستخدام شهادة الأصل قبل إرسال الطلب إلى الأصل. يتم تشفير أي استجابة من الأصل من خلال نفس العملية مرة أخرى إلى المستخدم النهائي. يمكنك تكوين Azure Front Door لاستخدام HTTPS كبروتوكول إعادة التوجيه للتمكين من طرف إلى طرف.

إصدارات بروتوكول أمان طبقة النقل المدعومة

يدعم Azure Front Door حاليا أربعة إصدارات من بروتوكول TLS: إصدارات TLS 1.0 و1.1 و1.2 و1.3. تستخدم جميع ملفات تعريف Azure Front Door التي تم إنشاؤها بعد سبتمبر 2019 TLS 1.2 كحد أدنى افتراضي مع تمكين TLS 1.3، ولكن لا تزال TLS 1.0 وTLS 1.1 مدعومة للتوافق مع الإصدارات السابقة. سيتم إيقاف دعم TLS 1.0 و1.1 في 1 مارس 2025.

على الرغم من أن Azure Front Door يدعم TLS 1.2، الذي قدم مصادقة العميل/المصادقة المتبادلة في RFC 5246، حاليا، لا يدعم Azure Front Door مصادقة العميل/المصادقة المتبادلة (mTLS) حتى الآن.

يمكنك تكوين الحد الأدنى من إصدار بروتوكول أمان طبقة النقل في Azure Front Door في إعدادات HTTPS للمجال المخصص باستخدام مدخل Microsoft Azure أو واجهة برمجة تطبيقات Azure REST. حالياً، يمكنك الاختيار بين 1.0 و1.2. على هذا النحو، تحديد TLS 1.2 كالإصدار الأدنى الذي يتحكم في الحد الأدنى المقبول من إصدارات بروتوكول أمان طبقة النقل Azure Front Door الذي سيقبل من عميل. بالنسبة إلى الحد الأدنى من إصدار TLS 1.2، سيحاول التفاوض إنشاء TLS 1.3 ثم TLS 1.2، بينما ستتم محاولة الإصدار 1.0 من TLS الأدنى جميع الإصدارات الأربعة. عندما يبدأ Azure Front Door حركة مرور TLS إلى الأصل، سيحاول التفاوض على أفضل إصدار TLS يمكن أن يقبله الأصل بشكل موثوق ومتناسق. إصدارات TLS المدعومة لاتصالات الأصل هي TLS 1.0 وTLS 1.1 وTLS 1.2 وTLS 1.3. سيتم إيقاف دعم TLS 1.0 و1.1 في 1 مارس 2025.

إشعار

  • يطلب من العملاء الذين تم تمكين TLS 1.3 دعم أحد منحنيات EC المتوافقة مع Microsoft SDL، بما في ذلك Secp384r1 و Secp256r1 و Secp521، من أجل إجراء الطلبات بنجاح باستخدام Azure Front Door باستخدام TLS 1.3.
  • من المستحسن أن يستخدم العملاء أحد هذه المنحنيات كمنحنى مفضل لهم أثناء الطلبات لتجنب زيادة زمن انتقال تأكيد اتصال TLS، والذي قد ينتج عن رحلات ذهابا وأخرى متعددة للتفاوض على منحنى EC المدعوم.

الشهادات المعتمدة

عند إنشاء شهادة TLS/SSL الخاصة بك، عليك إنشاء سلسلة شهادات كاملة مع مرجع مصدق (CA) مسموح به مشمول في ⁧⁩قائمة المراجع المصدقة الموثوقة من Microsoft⁧⁩. إذا كنت تستخدم مرجعاً مصدقاً غير مسموح به، فسيتم رفض طلبك.

لا يُسمح بالشهادات من المراجع المصدقة الداخلية أو الشهادات الموقعة ذاتياً.

تثبيت بروتوكول حالة الشهادة عبر الإنترنت (OCSP)

تثبيت OCSP مدعم افتراضيًا من Azure Front Door ولا يحتاج إلى تكوين.

اتصال TLS الأصل (Azure Front Door إلى الأصل)

بالنسبة لاتصالات HTTPS، يتوقع Azure Front Door أن يقدم أصلك شهادة من مرجع مصدق صالح (CA) مع اسم موضوع يطابق اسم مضيف الأصل. على سبيل المثال، إذا تم تعيين اسم مضيف الأصل إلى myapp-centralus.contosonews.net والشهادة التي يقدمها الأصل أثناء تأكيد اتصال TLS لا تحتوي myapp-centralus.contosonews.net على أو *.contosonews.net في اسم الموضوع، فإن Azure Front Door يرفض الاتصال ويشاهد العميل خطأ.

إشعار

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

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

في Azure Front Door Standard وPremium، يمكنك تكوين أصل لتعطيل التحقق من اسم موضوع الشهادة.

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

إشعار

من وجهة نظر الأمان، لا توصي Microsoft بتعطيل التحقق من اسم موضوع الشهادة.

اتصال TLS للواجهة الأمامية (العميل إلى Azure Front Door)

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

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

توفر شهادة Azure Front Door المدارة شهادة TLS/SSL قياسية عبر DigiCert ويتم تخزينها في Key Vault الخاص ب Azure Front Door.

إذا اخترت استخدام الشهادة الخاصة بك، فيمكنك حينئذٍ إعداد شهادة من مرجع مصدق مدعوم ويمكن أن تكون شهادة بروتوكول أمان طبقة النقل قياسية، أو شهادة تحقق من الصحة ممتدة، أو حتى شهادة بدل. الشهادات الموقعة ذاتياً ليست مدعمة. تعرف على كيفية تمكين HTTPS لنطاق مخصص.

التشغيل التلقائي للشهادة

بالنسبة لخيار شهادات Azure Front Door المُدارة، يعمل Azure Front Door على إدارة الشهادات وتشغيلها تلقائياً خلال 90 يوماً من وقت انتهاء الصلاحية. بالنسبة للخيار القياسي/الممتاز لشهادات Azure Front Door المُدارة، يعمل Azure Front Door على إدارة الشهادات وتشغيلها تلقائياً خلال 45 يوماً من وقت انتهاء الصلاحية. إذا كنت تستخدم شهادة مُدارة من Azure Front Door ووجدت أن تاريخ انتهاء صلاحية الشهادة يحلّ بعد أقل من 60 يوماً، أو 30 يوماً لوحدة حفظ المخزون القياسية/الممتازة، فقدّم تذكرة دعم.

للحصول على شهادة بروتوكول أمان طبقة النقل/شهادة SSL المخصصة الخاصة بك:

  1. لكي تدار الشهادة تلقائيًا إلى أحدث إصدار عندما يتوفر إصدار أحدث من الشهادة في Key Vault، يُرجى تعيين الإصدار السري إلى "الأحدث". بالنسبة للشهادات المخصصة، يتم تدوير الشهادة تلقائيا في غضون 3-4 أيام مع إصدار أحدث من الشهادة، بغض النظر عن وقت انتهاء صلاحية الشهادة.

  2. إذا تم تحديد إصدار معين، لا يتم دعم الدوران التلقائي. سيتعين عليك إعادة تحديد الإصدار الجديد يدويًا لتدوير الشهادة. يستغرق نشر الإصدار الجديد من الشهادة/السر ما يصل إلى 24 ساعة.

    إشعار

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

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

تركيبات التشفير المدعومة

بالنسبة إلى TLS 1.2/1.3، يتم دعم مجموعات التشفير التالية:

  • TLS_AES_256_GCM_SHA384 (TLS 1.3 فقط)
  • TLS_AES_128_GCM_SHA256 (TLS 1.3 فقط)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

إشعار

بالنسبة إلى Windows 10 والإصدارات الأحدث، نوصي بتمكين إحدى مجموعات التشفير ECDHE_GCM أو كليهما للحصول على أمان أفضل. Windows 8.1 و8 و7 غير متوافق مع مجموعات التشفير ECDHE_GCM هذه. تم توفير مجموعات تشفير ECDHE_CBC وDHE للتوافق مع أنظمة التشغيل هذه.

عند استخدام المجالات المخصصة مع تمكين TLS 1.0 و1.1، يتم دعم مجموعات التشفير التالية:

  • TLS_AES_256_GCM_SHA384 (TLS 1.3 فقط)
  • TLS_AES_128_GCM_SHA256 (TLS 1.3 فقط)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

لا يدعم Azure Front Door تعطيل مجموعات تشفير معينة أو تكوينها لملف التعريف الخاص بك.

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