Share via

نظرة عامة على إنهاء TLS وبروتوكول أمان طبقة النقل (TLS) المتطورة مع Application Gateway

  • مقالة

بروتوكول أمان طبقة النقل المعروف سابقًا باسم طبقة مآخذ التوصيل الآمنة هو تقنية الأمان القياسية لإنشاء ارتباط مشفر بين خادم الويب والمتصفح. يضمن هذا الارتباط أن تظل جميع البيانات التي يتم تمريرها بين خادم الويب والمتصفحات خاصة ومشفرة. تدعم Application Gateway كلاً من إنهاء TLS عند البوابة وكذلك تشفير TLS المتطور.

إنهاء TLS

تدعم Application Gateway إنهاء TLS عند البوابة، وبعد ذلك تتدفق حركة المرور عادةً دون تشفير إلى الخوادم الخلفية. هناك عدد من المزايا لإنهاء TLS في Application Gateway:

  • أداء مُحسَّن - أكبر نتيجة تأثرت بالأداء عند القيام بفك تشفير TLS هي تأكيد الاتصال الأولي. لتحسين الأداء، يقوم الخادم الذي يقوم بفك التشفير بتخزين معرّفات جلسة TLS مؤقتًا وإدارة بطاقات جلسة TLS. إذا تم ذلك في Application Gateway، يمكن لجميع الطلبات من نفس العميل استخدام القيم المُخزّنة مؤقتًا. إذا تم ذلك على خوادم الواجهة الخلفية، في كل مرة تنتقل فيها طلبات العميل إلى خادم مختلف، يجب على العميل إعادة المصادقة. يمكن أن يساعد استخدام تذاكر TLS في التخفيف من هذه المشكلة، ولكنها غير مدعومة من قبل جميع العملاء وقد يكون من الصعب تكوينها وإدارتها.
  • الاستخدام الأفضل للخوادم الخلفية - تُعدّ معالجة SSL / TLS عملية مكثفة للغاية لوحدة المعالجة المركزية (CPU)، وتصبح أكثر كثافة مع زيادة أحجام المفاتيح. يُمكّنها عدم القيام بهذا العمل من خوادم الواجهة الخلفية من التركيز على الأمور أكثر كفاءة فيه، أي توصيل المحتوى.
  • التوجيه الذكي - من خلال فك تشفير نسبة استخدام الشبكة، تمتلك Application Gateway وصولاً إلى محتوى الطلب، مثل العناوين و URI وما إلى ذلك، ويمكنها استخدام هذه البيانات لتوجيه الطلبات.
  • إدارة الشهادات - لا يلزم شراء الشهادات وتثبيتها إلا على Application Gateway وليس على جميع الخوادم الخلفية. هذا يوفر الوقت والمال.

لتكوين إنهاء TLS، يجب إضافة شهادة TLS/SSL إلى وحدة الاستماع. يسمح هذا لـ Application Gateway بفك تشفير نسبة استخدام الشبكة الواردة وتشفير نسبة استخدام الشبكة الخاصة بالاستجابة للعميل. يجب أن تكون الشهادة المقدمة لـ Application Gateway بتنسيق تبادل المعلومات الشخصية (PFX)، والذي يحتوي على كل من المفاتيح الخاصة والعامة. يتم سرد خوارزميات PFX المدعومة في دالة PFXImportCertStore.

هام

تتطلب الشهادة الموجودة على المستمع تحميل سلسلة الشهادات بالكامل (الشهادة الجذر من CA والوسطاء والشهادة الطرفية) لإنشاء سلسلة الثقة.

إشعار

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

لكي يعمل اتصال TLS، تحتاج إلى التأكد من أن شهادة TLS / SSL تفي بالشروط التالية:

  • أن التاريخ والوقت الحاليين يقعان ضمن النطاق الزمني "صالح من" و "صالح حتى" في الشهادة.
  • أن "الاسم العام" (CN) للشهادة يطابق عنوان المضيف في الطلب. على سبيل المثال، إذا كان العميل يقدم طلبًا إلى https://www.contoso.com/، فيجب أن يكون CN هو www.contoso.com.

إذا كانت لديك أخطاء في الاسم الشائع لشهادة الواجهة الخلفية (CN)، فراجع دليل استكشاف الأخطاء وإصلاحها.

الشهادات المدعومة لإنهاء TLS

تدعم Application Gateway الأنواع التالية من الشهادات:

  • شهادة CA (الهيئة المصدقة): شهادة CA هي شهادة رقمية صادرة عن هيئة مصدقة (CA)
  • شهادة EV (التحقق من الصحة الممتد): شهادة EV هي شهادة تتوافق مع إرشادات شهادة معايير الصناعة. سيؤدي هذا إلى تحويل شريط محدد موقع المتصفح إلى اللون الأخضر ونشر اسم الشركة أيضًا.
  • شهادة Wildcard: تدعم هذه الشهادة أي عدد من المجالات الفرعية بناءً على *.site.com، حيث سيحل نطاقك الفرعي محل *. ومع ذلك، فإنه لا يدعم site.com، لذلك في حالة وصول المستخدمين إلى موقعك على الويب دون كتابة "www" الرائد، فلن تغطي شهادة حرف البدل ذلك.
  • الشهادات الموقعة ذاتيا: لا تثق مستعرضات العميل بهذه الشهادات وستحذر المستخدم من أن شهادة الخدمة الظاهرية ليست جزءا من سلسلة ثقة. تُعدّ الشهادات الموقعة ذاتيًا جيدة للاختبار أو البيئات التي يتحكم فيها المسؤولون في العملاء ويمكنهم تجاوز تنبيهات أمان المتصفح بأمان. يجب ألا تُستخدم أحمال العمل في الإنتاج الشهادات الموقعة ذاتيًا.

لمزيد من المعلومات، راجع تكوين إنهاء TLS باستخدام Application Gateway.

حجم الشهادة

تحقق من قسم حدود Application Gateway لمعرفة الحد الأقصى لحجم شهادة TLS / SSL المدعومة.

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

قد لا ترغب في الاتصال غير المشفر بالخوادم الخلفية. قد تكون لديك متطلبات أمان أو متطلبات امتثال أو قد يقبل التطبيق اتصالاً آمنًا فقط. تحتوي Azure Application Gateway على تشفير TLS متطور لدعم هذه المتطلبات.

يُمكّنك TLS المتطور من تشفير البيانات الحساسة ونقلها بأمان إلى الخادم الخلفي أثناء استخدام ميزات موازنة تحميل Layer-7 الخاصة بـ Application Gateway. تتضمن هذه الميزات تقارب الجلسة المستند إلى ملفات تعريف الارتباط، والتوجيه المستند إلى عنوان URL، ودعم التوجيه استنادًا إلى المواقع، والقدرة على إعادة كتابة أو تضمين عناوين X-Forwarded- *، وما إلى ذلك.

عند تكوينها باستخدام وضع اتصال TLS المتطور، تنهي Application Gateway جلسات TLS في البوابة وتفك تشفير نسبة استخدام الشبكة للمستخدم. ثم يقوم بتطبيق القواعد التي تم تكوينها لتحديد مثيل مُجمّع خلفي مناسب لتوجيه نسبة استخدام الشبكة إليه. تبدأ Application Gateway بعد ذلك اتصال TLS جديدًا بالخادم الخلفي وتعيد تشفير البيانات باستخدام شهادة المفتاح العام للخادم الخلفي قبل إرسال الطلب إلى الواجهة الخلفية. تمر أي استجابة من خادم الويب بنفس العملية إلى المستخدم النهائي. يتم تمكين TLS المتطور عن طريق تعيين إعداد البروتوكول في Backend HTTP Setting على HTTPS، والذي يتم تطبيقه بعد ذلك على المُجمّع الخلفي.

في بوابات Application Gateway v1 SKU، يطبق نهج TLS إصدار TLS فقط على حركة مرور الواجهة الأمامية والشفرات المعرفة على كل من أهداف الواجهة الأمامية والخلفية. في بوابات Application Gateway v2 SKU، ينطبق نهج TLS فقط على حركة مرور الواجهة الأمامية، وسيتم دائما التفاوض على اتصالات TLS الخلفية عبر TLS 1.0 إلى إصدارات TLS 1.2.

تتصل بوابة التطبيق فقط بخوادم الواجهة الخلفية التي تحتوي إما على السماح بإدراج شهادتها مع Application Gateway أو التي تم توقيع شهاداتها من قبل المراجع المصدقة المعروفة ويتطابق CN للشهادة مع اسم المضيف في إعدادات الواجهة الخلفية HTTP. يتضمن ذلك خدمات Azure الموثوقة مثل Azure App Service / Web Apps وAPI Management.

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

إشعار

الشهادة المضافة إلى Backend HTTP Setting لمصادقة الخودام الخلفية يمكن أن تكون هي نفس الشهادة المضافة إلى المستمع لإنهاء TLS عند Application Gateway أو تختلف لتحسين الأمان.

end to end TLS scenario

في هذا المثال، يتم توجيه الطلبات التي تستخدم TLS1.2 إلى خوادم الواجهة الخلفية في Pool1 باستخدام TLS من النهاية إلى النهاية.

من طرف إلى طرف في TLS والسماح بإدراج الشهادات

تتصل بوابة التطبيق فقط بخوادم الواجهة الخلفية التي تحتوي إما على السماح بإدراج شهادتها مع Application Gateway أو التي تم توقيع شهاداتها من قبل المراجع المصدقة المعروفة ويتطابق CN للشهادة مع اسم المضيف في إعدادات الواجهة الخلفية HTTP. هناك بعض الاختلافات في عملية إعداد TLS من طرف إلى طرف فيما يتعلق بإصدار Application Gateway المستخدم. يشرح القسم التالي الإصدارات بشكل فردي.

TLS من طرف إلى طرف مع v1 SKU

لتمكين TLS من طرف إلى طرف مع خوادم الواجهة الخلفية و Application Gateway لتوجيه الطلبات إليها، يجب أن تنجح تحقيقات الصحة وتعيد استجابة صحية.

بالنسبة لتحقيقات صحة HTTPS، يستخدم Application Gateway v1 SKU مطابقة تامة لشهادة المصادقة (المفتاح العام لشهادة خادم الواجهة الخلفية وليس شهادة الجذر) ليتم تحميلها إلى إعدادات HTTP.

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

إشعار

المصادقة وإعداد شهادة الجذر الموثوق بها غير مطلوبين لخدمات Azure الموثوق بها مثل Azure App Service. تعتبر موثوقة بشكل افتراضي.

TLS من طرف إلى طرف مع v2 SKU

تم إهمال شهادات المصادقة واستبدالها بشهادات الجذر الموثوقة في Application Gateway v2 SKU. تعمل بشكل مشابه لشهادات المصادقة مع بعض الاختلافات الرئيسية:

  • لا تتطلب الشهادات الموقعة من قبل سلطات المرجع المصدق المعروفة التي يطابق CN اسم المضيف في إعدادات الواجهة الخلفية HTTP أي خطوة إضافية حتى تعمل TLS من طرف إلى طرف.

    على سبيل المثال، إذا تم إصدار شهادات الواجهة الخلفية بواسطة مرجع مصدق معروف جيدًا وتحتوي على CN لـ contoso.com، كما تم تعيين حقل مضيف إعداد http الخلفي على contoso.com، فلن تكون هناك حاجة إلى خطوات إضافية. يمكنك تعيين بروتوكول إعداد http الخلفي على HTTPS وسيتم تمكين TLS لكل من مسبار الصحة ومسار البيانات. إذا كنت تستخدم Azure App Service أو خدمات Azure الأخرى على الويب كخلفية لك، فستكون هذه موثوقة ضمنيًا أيضًا ولا توجد خطوات أخرى مطلوبة من أجل TLS نهاية إلى نهاية.

إشعار

من أجل الوثوق بشهادة TLS / SSL، يجب أن تكون هذه الشهادة الخاصة بخادم الواجهة الخلفية صادرة عن مرجع مصدق معروف جيدًا. إذا لم يتم إصدار الشهادة من قِبل هيئة مصدقة موثوق بها، فستتحقق application gateway بعد ذلك لمعرفة ما إذا كانت شهادة الهيئة المصدقة المُصدر قد صدرت عن هيئة مصدقة موثوقة، وما إلى ذلك حتى يتم العثور على هيئة مصدق موثوق به (وعند هذه النقطة يتم العثور على هيئة مصدقة موثوقة، سيتم إنشاء اتصال آمن) أو لا يمكن العثور على هيئة مصدقة موثوقة (عند هذه النقطة ستحدد بوابة التطبيق أن الواجهة الخلفية غير صحية). لذلك، من المستحسن أن تحتوي شهادة الخادم الخلفي على كل من المراجع المصدقة الجذر والمتوسطة.

  • إذا كانت شهادة الخادم الخلفي موقعة ذاتيًا، أو موقعة من قِبل CA / وسطاء غير معروفين، فعندئذٍ لتمكين TLS من طرف إلى طرف في Application Gateway v2، يجب تحميل شهادة جذر موثوقة. ستتواصل Application Gateway فقط مع الخلفيات الخلفية التي تطابق شهادة جذر شهادة الخادم الخاصة بها إحدى قائمة الشهادات الجذرية الموثوقة في إعداد http الخلفي المرتبط بالمُجمّع.

  • بالإضافة إلى مطابقة الشهادة الجذر، يتحقق Application Gateway v2 أيضًا من صحة ما إذا كان إعداد المضيف المحدد في إعداد http الخلفي يطابق الاسم الشائع (CN) المقدم بواسطة شهادة TLS / SSL لخادم الواجهة الخلفية. عند محاولة إنشاء اتصال TLS بالواجهة الخلفية، تقوم Application Gateway v2 بتعيين امتداد مؤشر اسم الخادم (SNI) للمضيف المحدد في إعداد http الخلفي.

  • إذا تم اختيار اختيار اسم مضيف من هدف الواجهة الخلفية بدلاً من حقل المضيف في إعداد http الخلفي، فسيتم تعيين عنوان SNI دائمًا على المُجمع الخلفي FQDN ويجب أن يتطابق اسم CN على الخادم الخلفي TLS / SSL مع FQDN. لا يتم دعم أعضاء المُجمّع الخلفي مع عناوين IP في هذا السيناريو.

  • شهادة الجذر هي شهادة جذر مشفرة base64 من شهادات الخادم الخلفي.

الاختلافات SNI في v1 وv2 SKU

كما ذكرنا سابقًا، تقوم Application Gateway بإنهاء نسبة استخدام TLS من العميل في Application Gateway Listener (دعنا نسميها اتصال الواجهة الأمامية)، وتقوم بفك تشفير نسبة استخدام الشبكة، وتطبيق القواعد اللازمة لتحديد الخادم الخلفي الذي يجب إعادة توجيه الطلب إليه، وإنشاء جلسة TLS جديدة مع الخادم الخلفي (دعنا نسميها اتصال الواجهة الخلفية).

توضح الجداول التالية الاختلافات في SNI بين v1 و v2 SKU من حيث اتصالات الواجهة الأمامية والخلفية.

اتصال TLS للواجهة الأمامية (العميل إلى بوابة التطبيق)

السيناريو v1 v2
إذا حدد العميل عنوان SNI وتم تمكين جميع أدوات الاستماع متعددة المواقع بعلامة "مطلوب SNI" تُرجع الشهادة المناسبة وإذا كان الموقع غير موجود (وفقًا لـ server_name)، ثم تتم إعادة تعيين الاتصال. تُرجع الشهادة المناسبة إذا كانت متوفرة، وإلا، تُرجع شهادة مستمع HTTPS الأول وفقًا للترتيب المحدد بواسطة قواعد توجيه الطلب المرتبطة بمستمعي HTTPS
إذا لم يحدد العميل عنوان SNI وإذا تم تمكين جميع عناوين المواقع المتعددة باستخدام "مطلوب SNI" إعادة ضبط الاتصال إرجاع شهادة مستمع HTTPS الأول وفقًا للترتيب المحدد بواسطة قواعد تحويل الطلب المرتبطة بمستمعي HTTPS
إذا لم يحدد العميل عنوان SNI وإذا كان هناك مستمع أساسي تم تكوينه باستخدام شهادة إرجاع الشهادة المكونة في المستمع الأساسي إلى العميل (الشهادة الافتراضية أو الاحتياطية) إرجاع الشهادة المكونة في المستمع الأساسي

تلميح

يمكن تكوين علامة SNI باستخدام PowerShell أو باستخدام قالب ARM. لمزيد من المعلومات، راجع RequireServerNameIndication و Quickstart: حركة مرور الويب المباشرة باستخدام بوابة تطبيق Azure - قالب ARM.

اتصال TLS الخلفي (بوابة التطبيق إلى الخادم الخلفي)

نسبة استخدام الشبكة لمجموعة التحقيق

السيناريو v1 v2
عنوان SNI (server_name) أثناء تأكيد اتصال TLS كـ FQDN تعيين كـ FQDN من المُجمّع الخلفي. وفقا ل RFC 6066، لا يسمح بعناوين IPv4 وIPv6 الحرفية في اسم مضيف SNI.
ملاحظة: يجب على FQDN في المُجمّع الخلفي أن يحل DNS على عنوان IP للخادم الخلفي (عام أو خاص)		 يتم تعيين عنوان SNI (server_name) على أنه اسم المضيف من مجموعة التحقيق المخصصة المرفقة بإعدادات HTTP (إذا تم تكوينها)، وإلا من اسم المضيف المذكور في إعدادات HTTP، وإلا من FQDN المذكور في المُجمّع الخلفي. ترتيب الأسبقية هو تجمع خلفية لإعدادات > HTTP للتحقيق المخصص>.
ملاحظة: إذا كانت أسماء المضيف التي تم تكوينها في إعدادات HTTP والتحقيق المخصص مختلفة، فوفقًا للأولوية، سيتم تعيين SNI كاسم مضيف من التحقيق المخصص.
إذا كان عنوان المُجمّع الخلفي هو عنوان IP (الإصدار 1) أو إذا تم تكوين اسم مضيف مجموعة التحقيق المخصصة كعنوان IP (الإصدار 2) لن يتم تعيين SNI (server_name).
ملاحظة: في هذه الحالة، يجب أن يكون الخادم الخلفي قادرا على إرجاع شهادة افتراضية/احتياطية ويجب أن يكون هذا مدرجا في إعدادات HTTP ضمن شهادة المصادقة. إذا لم تكن هناك شهادة افتراضية / احتياطية تم تكوينها في الخادم الخلفي وكان من المتوقع وجود إشارة SNI، فقد يعيد الخادم تعيين الاتصال وسيؤدي إلى إخفاقات التحقيق		 وفقًا لترتيب الأسبقية المذكور سابقًا، إذا كان لديهم عنوان IP كاسم مضيف، فلن يتم تعيين SNI وفقًا لـ RFC 6066 .
ملاحظة: لن يتم تعيين SNI أيضًا في تحقيقات v2 إذا لم يتم تكوين مجموعة تحقيق مخصصة ولم يتم تعيين اسم مضيف على إعدادات HTTP أو المُجمّع الخلفي

إشعار

إذا لم يتم تكوين مسبار مخصص، فإن Application Gateway ترسل مسبارا افتراضيا بهذا التنسيق - <protocol>://127.0.0.1:<port>/. على سبيل المثال، بالنسبة إلى فحص HTTPS الافتراضي، سيتم إرساله ك https://127.0.0.1:443/. لاحظ أنه، يتم استخدام 127.0.0.1 المذكور هنا فقط كعنوان مضيف HTTP، وفقا ل RFC 6066، لن يتم استخدامه كعنوان SNI. لمزيد من المعلومات حول أخطاء التحقق من الصحة، راجع دليل استكشاف الأخطاء وإصلاحها للسلامة في الخلفية .

لنقل البيانات المباشر

السيناريو v1 v2
عنوان SNI (server_name) أثناء تأكيد اتصال TLS كـ FQDN تعيين كـ FQDN من المُجمّع الخلفي. وفقا ل RFC 6066، لا يسمح بعناوين IPv4 وIPv6 الحرفية في اسم مضيف SNI.
ملاحظة: يجب على FQDN في المُجمّع الخلفي أن يحل DNS على عنوان IP للخادم الخلفي (عام أو خاص)		 يتم تعيين عنوان SNI (server_name) على أنه اسم المضيف من إعدادات HTTP، وإلا، إذا تم اختيار الخيار PickHostnameFromBackendAddress أو إذا لم يذكر اسم مضيف، فسيتم تعيينه على أنه FQDN في تكوين تجمع الخلفية
إذا كان عنوان تجمع الواجهة الخلفية هو عنوان IP أو لم يتم تعيين اسم المضيف في إعدادات HTTP لن يتم تعيين SNI وفقا ل RFC 6066 إذا لم يكن إدخال تجمع الخلفية FQDN سيتم تعيين SNI كاسم مضيف من إدخال FQDN من العميل ويجب أن يتطابق اسم CN لشهادة الواجهة الخلفية مع اسم المضيف هذا.
لا يتم توفير اسم المضيف في HTTP الإعدادات، ولكن يتم تحديد FQDN كهدف لعضو تجمع الخلفية سيتم تعيين SNI كاسم مضيف من إدخال FQDN من العميل ويجب أن يتطابق اسم CN لشهادة الواجهة الخلفية مع اسم المضيف هذا. سيتم تعيين SNI كاسم مضيف من إدخال FQDN من العميل ويجب أن يتطابق اسم CN لشهادة الواجهة الخلفية مع اسم المضيف هذا.

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

بعد التعرف على TLS المتطور، انتقل إلى تكوين TLS المتطور باستخدام Application Gateway مع PowerShell لإنشاء Application Gateway باستخدام TLS متطور.