إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
بروتوكول أمان طبقة النقل المعروف سابقًا باسم طبقة مآخذ التوصيل الآمنة هو تقنية الأمان القياسية لإنشاء ارتباط مشفر بين خادم الويب والمتصفح. يضمن هذا الارتباط أن تظل جميع البيانات التي يتم تمريرها بين خادم الويب والمتصفحات خاصة ومشفرة. تدعم Application Gateway كلاً من إنهاء TLS عند البوابة وكذلك تشفير TLS المتطور.
Important
بدءا من 31 أغسطس 2025، يجب على جميع العملاء والخوادم الخلفية التي تتفاعل مع Azure Application Gateway استخدام بروتوكول أمان طبقة النقل (TLS) 1.2 أو أعلى، حيث سيتم إيقاف دعم TLS 1.0 و1.1.
TLS termination
تدعم Application Gateway إنهاء TLS عند البوابة، وبعد ذلك تتدفق حركة المرور عادةً دون تشفير إلى الخوادم الخلفية. هناك عدد من المزايا لإنهاء TLS في Application Gateway:
- أداء محسن - أكبر أداء يتم تحقيقه عند إجراء فك تشفير TLS هو المصافحة الأولية. لتحسين الأداء، يقوم الخادم الذي يقوم بفك التشفير بتخزين معرّفات جلسة TLS مؤقتًا وإدارة بطاقات جلسة TLS. إذا تم ذلك في Application Gateway، يمكن لجميع الطلبات من نفس العميل استخدام القيم المُخزّنة مؤقتًا. إذا تم ذلك على خوادم الواجهة الخلفية، في كل مرة تنتقل فيها طلبات العميل إلى خادم مختلف، يجب على العميل إعادة المصادقة. يمكن أن يساعد استخدام تذاكر TLS في التخفيف من هذه المشكلة، ولكنها غير مدعومة من قبل جميع العملاء وقد يكون من الصعب تكوينها وإدارتها.
- الاستخدام الأفضل للخوادم الخلفية - تُعدّ معالجة SSL / TLS عملية مكثفة للغاية لوحدة المعالجة المركزية (CPU)، وتصبح أكثر كثافة مع زيادة أحجام المفاتيح. يُمكّنها عدم القيام بهذا العمل من خوادم الواجهة الخلفية من التركيز على الأمور أكثر كفاءة فيه، أي توصيل المحتوى.
- التوجيه الذكي - من خلال فك تشفير نسبة استخدام الشبكة ، يمكن لبوابة التطبيق الوصول إلى محتوى الطلب ، مثل الرؤوس وعنوان URI وما إلى ذلك ، ويمكنها استخدام هذه البيانات لتوجيه الطلبات.
- إدارة الشهادات - تحتاج الشهادات فقط إلى شراؤها وتثبيتها على بوابة التطبيق وليس جميع خوادم الواجهة الخلفية. هذا يوفر الوقت والمال.
لتكوين إنهاء TLS، يجب إضافة شهادة TLS/SSL إلى وحدة الاستماع. يسمح هذا لـ Application Gateway بفك تشفير نسبة استخدام الشبكة الواردة وتشفير نسبة استخدام الشبكة الخاصة بالاستجابة للعميل. يجب أن تكون الشهادة المقدمة لـ Application Gateway بتنسيق تبادل المعلومات الشخصية (PFX)، والذي يحتوي على كل من المفاتيح الخاصة والعامة. يتم سرد خوارزميات PFX المدعومة في وظيفة PFXImportCertStore.
Important
تتطلب الشهادة الموجودة على المستمع تحميل سلسلة الشهادات بالكامل (الشهادة الجذر من CA والوسطاء والشهادة الطرفية) لإنشاء سلسلة الثقة.
Note
لا توفر بوابة التطبيق أي إمكانية لإنشاء شهادة جديدة أو إرسال طلب شهادة إلى مرجع مصدق.
لكي يعمل اتصال 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.3، وإذا لم تكن متاحة، يعود إلى TLS 1.2.
تتصل بوابة التطبيق فقط بخوادم الواجهة الخلفية التي تحتوي إما على السماح بإدراج شهادتها مع Application Gateway أو التي تم توقيع شهاداتها من قبل المراجع المصدقة المعروفة ويتطابق CN للشهادة مع اسم المضيف في إعدادات الواجهة الخلفية HTTP. يتضمن ذلك خدمات Azure الموثوقة مثل Azure App Service / Web Apps وAPI Management.
إذا لم يتم توقيع شهادات الأعضاء في تجمع الواجهة الخلفية من قبل المراجع المصدقة المعروفة، فيجب تكوين كل مثيل في تجمع الواجهة الخلفية مع تمكين TLS من طرف إلى طرف بشهادة للسماح بالاتصال الآمن. تضمن إضافة الشهادة أن بوابة التطبيق تتصل فقط بمثيلات الواجهة الخلفية المعروفة. هذا يضمن وجود اتصال متطور.
Note
الشهادة المضافة إلى Backend HTTP Setting لمصادقة الخودام الخلفية يمكن أن تكون هي نفس الشهادة المضافة إلى المستمع لإنهاء TLS عند Application Gateway أو تختلف لتحسين الأمان.
في هذا المثال، يتم توجيه الطلبات التي تستخدم TLS1.2 إلى خوادم الواجهة الخلفية في Pool1 باستخدام TLS من النهاية إلى النهاية.
من طرف إلى طرف في TLS والسماح بإدراج الشهادات
تتصل بوابة التطبيق فقط بخوادم الواجهة الخلفية التي تحتوي إما على السماح بإدراج شهادتها مع Application Gateway أو التي تم توقيع شهاداتها من قبل المراجع المصدقة المعروفة ويتطابق CN للشهادة مع اسم المضيف في إعدادات الواجهة الخلفية HTTP. هناك بعض الاختلافات في عملية إعداد TLS من طرف إلى طرف فيما يتعلق بإصدار Application Gateway المستخدم. يشرح القسم التالي الإصدارات بشكل فردي.
TLS من طرف إلى طرف مع v1 SKU
لتمكين TLS من طرف إلى طرف مع خوادم الواجهة الخلفية و Application Gateway لتوجيه الطلبات إليها، يجب أن تنجح تحقيقات الصحة وتعيد استجابة صحية.
بالنسبة لتحقيقات صحة HTTPS، يستخدم Application Gateway v1 SKU مطابقة تامة لشهادة المصادقة (المفتاح العام لشهادة خادم الواجهة الخلفية وليس شهادة الجذر) ليتم تحميلها إلى إعدادات HTTP.
عندئذٍ يُسمح فقط بالاتصالات للخلفيات المعروفة والمسموح بها. تعتبر الخلفيات المتبقية غير صحية من قبل المسابير الصحية. الشهادات الموقعة ذاتيًا هي لأغراض الاختبار فقط ولا يوصى بها لأحمال عمل الإنتاج. يجب السماح بإدراج هذه الشهادات مع بوابة التطبيق كما هو موضح في الخطوات السابقة قبل أن يمكن استخدامها.
Note
المصادقة وإعداد شهادة الجذر الموثوق بها غير مطلوبين لخدمات 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 نهاية إلى نهاية.
Note
من أجل الوثوق بشهادة 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 للواجهة الأمامية (العميل إلى بوابة التطبيق)
| Scenario | v1 | v2 |
|---|---|---|
| إذا حدد العميل عنوان SNI وتم تمكين جميع أدوات الاستماع متعددة المواقع بعلامة "مطلوب SNI" | تُرجع الشهادة المناسبة وإذا كان الموقع غير موجود (وفقًا لـ server_name)، ثم تتم إعادة تعيين الاتصال. | تُرجع الشهادة المناسبة إذا كانت متوفرة، وإلا، تُرجع شهادة مستمع HTTPS الأول وفقًا للترتيب المحدد بواسطة قواعد توجيه الطلب المرتبطة بمستمعي HTTPS |
| إذا لم يحدد العميل عنوان SNI وإذا تم تمكين جميع عناوين المواقع المتعددة باستخدام "مطلوب SNI" | إعادة ضبط الاتصال | إرجاع شهادة مستمع HTTPS الأول وفقًا للترتيب المحدد بواسطة قواعد تحويل الطلب المرتبطة بمستمعي HTTPS |
| إذا لم يحدد العميل عنوان SNI وإذا كان هناك مستمع أساسي تم تكوينه باستخدام شهادة | إرجاع الشهادة المكونة في المستمع الأساسي إلى العميل (الشهادة الافتراضية أو الاحتياطية) | يعيد شهادة مستمع HTTPS ذات قاعدة التوجيه ذات الأولوية الأعلى. شهادة المستمع الأساسية لا تستخدم كخيار احتياطي. |
Important
سلوك شهادة وحدة تخزين VKU الافتراضية في V2: عندما يتصل العميل بدون رأس SNI (على سبيل المثال، باستخدام عنوان IP)، لا يعود Application Gateway V2 إلى شهادة المستمع الأساسية. بدلا من ذلك، يعيد دائما الشهادة من مستمع HTTPS الذي تكون قاعدة توجيه الطلب المرتبطة به ذات أعلى أولوية (أدنى رقم أولوية). يختلف هذا السلوك عن وحدة إصدار V1، التي تعيد شهادة المستمع الأساسية كخطة احتياطية.
Tip
التحكم في الشهادة الافتراضية باستخدام ثقب في SNI: لمنع بوابة التطبيق V2 من كشف شهادة موقع الإنتاج عندما يتصل العملاء عبر عنوان IP بدون SNI، يمكنك تكوين "ثغرة SNI":
- أنشئ مستمع HTTPS متعدد المواقع مع اسم مضيف وهمي لا يتطابق مع أي موقع حقيقي (على سبيل المثال،
sni-hole.invalid). - قم بتحميل شهادة موقعة ذاتيا لهذا المستمع.
- أنشئ قاعدة توجيه طلبات مرتبطة بهذا المستمع وخصص له أعلى أولوية (أدنى رقم أولوية) بين جميع قواعدك.
مع هذا التكوين، يحصل أي اتصال بدون رأس SNI مطابق على شهادة موقعة ذاتية الشهادة بدلا من شهادة موقع صالحة. هذا يمنع الاتصالات التي تعتمد فقط على IP من الحصول على معلومات عن مواقعك المستضافة.
اتصال TLS الخلفي (بوابة التطبيق إلى الخادم الخلفي)
نسبة استخدام الشبكة لمجموعة التحقيق
| Scenario | v1 | v2 |
|---|---|---|
| عند تكوين FQDN أو SNI | تعيين كـ FQDN من المُجمّع الخلفي. وفقا ل RFC 6066، لا يسمح بعناوين IPv4 و IPv6 الحرفية في اسم مضيف SNI. | يتم تعيين قيمة SNI استنادا إلى نوع التحقق من صحة TLS في إعدادات الواجهة الخلفية. 1. التحقق الكامل - تستخدم المجسات SNI بترتيب الأسبقية التالي: أ) اسم مضيف الفحص الصحي المخصص ب) اسم مضيف إعداد الواجهة الخلفية (حسب قيمة التجاوز أو انتقاء من خادم الواجهة الخلفية) 2. قابل للتكوين استخدام SNI محدد: تستخدم المجسات اسم المضيف الثابت هذا للتحقق من الصحة. تخطي SNI: لا يوجد التحقق من صحة اسم الموضوع. |
| عندما لا يتم تكوين FQDN أو SNI (يتوفر عنوان IP فقط) | لن يتم تعيين SNI (server_name). ملاحظه: في هذه الحالة، يجب أن يكون خادم الواجهة الخلفية قادرا على إرجاع شهادة افتراضية/احتياطية ويجب إدراج هذا في إعدادات HTTP ضمن شهادة المصادقة. إذا لم تكن هناك شهادة افتراضية / احتياطية تم تكوينها في الخادم الخلفي وكان من المتوقع وجود إشارة SNI، فقد يعيد الخادم تعيين الاتصال وسيؤدي إلى إخفاقات التحقيق |
إذا كان الفحص المخصص أو إعدادات الواجهة الخلفية تستخدم عنوان IP في حقل اسم المضيف، فلن يتم تعيين SNI، وفقا ل RFC 6066. يتضمن ذلك الحالات التي يستخدم فيها المسبار الافتراضي 127.0.0.1. |
لنقل البيانات المباشر
| Scenario | v1 | v2 |
|---|---|---|
| عند توفر FQDN أو SNI | يتم تعيين SNI باستخدام FQDN الخاص بخادم الواجهة الخلفية. | يتم تعيين قيمة SNI استنادا إلى نوع التحقق من صحة TLS في إعدادات الواجهة الخلفية. 1. التحقق الكامل - يتم تعيين SNI وفقا لترتيب الأسبقية التالي: أ) اسم المضيف لإعداد الخلفية (حسب القيمة المجاورة أو Pick from Backend Server) ب) رأس المضيف لطلب العميل الوارد 2. قابل للتكوين استخدام SNI محدد: يستخدم اسم المضيف الثابت هذا للتحقق من الصحة. تخطي SNI: لا يوجد التحقق من صحة اسم الموضوع. |
| عندما لا يتوفر FQDN أو SNI (يتوفر عنوان IP فقط) | لن يتم تعيين SNI وفقا ل RFC 6066 إذا لم يكن إدخال تجمع الواجهة الخلفية FQDN | لن يتم تعيين SNI وفقا لمعيار RFC 6066. |
الخطوات التالية
بعد التعرف على TLS المتطور، انتقل إلى تكوين TLS المتطور باستخدام Application Gateway مع PowerShell لإنشاء Application Gateway باستخدام TLS متطور.