الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به

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

ينطبق هذا التوجيه بشكل خاص على التطبيقات التي تتم استضافتها في عروض النظام الأساسي كخدمة (PaaS) مثل Azure App Service وAzure Spring Apps. توفر هذه المقالة إرشادات تنفيذ محددة لـ Azure Application GatewayوAzure Front DoorوAzure API Management، والتي تستخدم عادة خدمات الوكيل العكسي.

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

السياق

مضيف طلب HTTP

في كثير من الحالات، يحتاج خادم التطبيق أو بعض المكونات في مسار الطلب إلى اسم مجال الإنترنت الذي استخدمه المستعرض للوصول إليه. هذا هو مضيف الطلب. يمكن أن يكون عنوان IP، ولكنه عادة ما يكون اسماً مثل contoso.com (الذي يحله المتصفح بعد ذلك إلى عنوان IP باستخدام DNS). عادةً ما يتم تحديد قيمة المضيف من مكون المضيف لعنوان URI للطلب، والذي يرسله المستعرض إلى التطبيق كعنوانHost HTTP.

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

لماذا تستخدم أنظمة الويب الأساسية اسم المضيف

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

لتسهيل البدء، توفر هذه المنصات عادةً نطاقًا افتراضيًا تم تكوينه مسبقًا لتوجيه حركة المرور إلى مثيلك المنشور. بالنسبة لـ App Service، هذا المجال الافتراضي هو azurewebsites.net. يحصل كل تطبيق ويب تنشئه على نطاق فرعي خاص به، على سبيل المثال، contoso.azurewebsites.net. وبالمثل، المجال الافتراضي هو azuremicroservices.io ل Azure Spring Apps و azure-api.net API Management.

بالنسبة إلى عمليات نشر الإنتاج، لا تستخدم هذه المجالات الافتراضية. بدلاً من ذلك، يمكنك توفير مجالك الخاص للتوافق مع العلامة التجارية لمؤسستك أو تطبيقك. على سبيل المثال، contoso.com يمكن أن يحل خلف الكواليس لتطبيق الويب contoso.azurewebsites.net على خدمة التطبيقات، ولكن لا ينبغي أن يكون هذا النطاق مرئيًا للمستخدم النهائي الذي يزور الموقع. ومع ذلك، يجب تسجيل اسم المضيف contoso.com المخصص هذا مع خدمة PaaS، حتى تتمكن المنصة من تحديد الخادم الخلفي الذي يجب أن يستجيب للطلب.

لماذا تستخدم التطبيقات اسم المضيف

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

• إرجاع عنوان URL مطلق بدلاً من عنوان URL نسبي في استجابة HTTP الخاصة به (على الرغم من أن مواقع الويب تميل بشكل عام إلى تقديم ارتباطات نسبية عندما يكون ذلك ممكناً).
• إنشاء عنوان URL لاستخدامه خارج استجابة HTTP الخاصة به حيث لا يمكن استخدام عناوين URL النسبية، مثل إرسال ارتباط إلى موقع ويب إلى مستخدم عبر البريد الإلكتروني.
• إنشاء عنوان URL مطلق لإعادة التوجيه لخدمة خارجية. على سبيل المثال، إلى خدمة مصادقة مثل معرف Microsoft Entra للإشارة إلى مكان إرجاع المستخدم بعد المصادقة الناجحة.
• إصدار ملفات تعريف ارتباط HTTP التي تقتصر على مضيف معين، كما هو محدد في سمة ملف تعريفDomain الارتباط.

يمكنك تلبية جميع هذه المتطلبات عن طريق إضافة اسم المضيف المتوقع إلى تكوين التطبيق واستخدام تلك القيمة المعرفة بشكل ثابت بدلاً من اسم المضيف الوارد على الطلب. ومع ذلك، فإن هذا النهج يعقد تطوير التطبيقات ونشرها. أيضاً، يمكن أن يخدم تثبيت واحد للتطبيق مضيفين متعددين. على سبيل المثال، يمكن استخدام تطبيق ويب واحد لمستأجري التطبيقات المتعددين الذين لديهم جميعا أسماء مضيفين فريدة خاصة بهم (مثل tenant1.contoso.com و tenant2.contoso.com).

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

• في App Service، يمكنك فرض HTTPS لتطبيق الويب الخاص بك. يؤدي القيام بذلك إلى إعادة توجيه أي طلبات HTTP غير آمنة إلى HTTPS. في هذه الحالة، يتم استخدام اسم المضيف الوارد لإنشاء عنوان URL المطلق لعنوان إعادة توجيه Location HTTP.
• تستخدم Azure Spring Apps ميزة مماثلة لفرض HTTPS. كما يستخدم المضيف الوارد لإنشاء عنوان URL HTTPS.
• تحتوي App Service على إعداد ترابط ARR لتمكين جلسات العمل الملصقة، بحيث يتم دائما تقديم الطلبات من نفس مثيل المستعرض بواسطة نفس الخادم الخلفي. يتم تنفيذ ذلك بواسطة الأطراف الأمامية لخدمة التطبيقات، والتي تضيف ملف تعريف ارتباط إلى استجابة HTTP. يتم تعيين ملف تعريف الارتباط Domain إلى المضيف الوارد.
• توفر App Service إمكانات المصادقة والتخويل للسماح للمستخدمين بسهولة بتسجيل الدخول والوصول إلى البيانات في واجهات برمجة التطبيقات.
  • يتم استخدام اسم المضيف الوارد لإنشاء عنوان URL لإعادة التوجيه الذي يحتاج إليه موفر الهوية لإرجاع المستخدم بعد المصادقة الناجحة.
  • يؤدي تمكين هذه الميزة افتراضيًا أيضًا إلى تشغيل إعادة توجيه HTTP إلى HTTPS . مرة أخرى، يتم استخدام اسم المضيف الوارد لإنشاء موقع إعادة التوجيه.

لماذا قد تميل إلى تجاوز اسم المضيف

لنفترض أنك أنشأت تطبيق ويب في خدمة التطبيقات يحتوي على نطاق افتراضي قدره contoso.azurewebsites.net. (أو في خدمة أخرى مثل Azure Spring Apps.) لم تقم بتكوين مجال مخصص على App Service. لوضع وكيل عكسي مثل Application Gateway (أو أي خدمة مشابهة) أمام هذا التطبيق، يمكنك تعيين سجل DNS للحل contoso.com إلى عنوان IP لبوابة التطبيق. لذلك فإنه يتلقى الطلب contoso.com من المتصفح ويتم تكوينه لإعادة توجيه هذا الطلب إلى عنوان IP الذي contoso.azurewebsites.net يحل إلى: هذه هي الخدمة الخلفية النهائية للمضيف المطلوب. ومع ذلك، في هذه الحالة، لا تتعرف App Service على contoso.com المجال المخصص وترفض جميع الطلبات الواردة لاسم المضيف هذا. لا يمكنه تحديد مكان توجيه الطلب.

قد يبدو أن الطريقة السهلة لجعل هذا التكوين يعمل هو تجاوز أو إعادة كتابة Host عنوان طلب HTTP في بوابة التطبيق وتعيينه إلى قيمة contoso.azurewebsites.net. إذا قمت بذلك، فإن الطلب الصادر من بوابة التطبيق يجعل الأمر يبدو كما لو كان الطلب الأصلي مخصصاً contoso.azurewebsites.net بالفعل بدلاً من contoso.com:

في هذه المرحلة، تتعرف App Service على اسم المضيف، وهي تقبل الطلب دون الحاجة إلى تكوين اسم مجال مخصص. في الواقع، يجعل Application Gateway من السهل تجاوز عنوان المضيف مع مضيف تجمع النهاية الخلفية. يقوم Azure Front Door بذلك بشكل افتراضي.

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

المشاكل المحتملة

عناوين URL مطلقة غير صحيحة

إذا لم يتم الاحتفاظ باسم المضيف الأصلي ويستخدم خادم التطبيق اسم المضيف الوارد لإنشاء عناوين URL مطلقة، فقد يتم الكشف عن المجال الخلفي للمستخدم النهائي. يمكن إنشاء عناوين URL المطلقة هذه بواسطة التعليمات البرمجية للتطبيق أو، كما ذكر سابقا، بواسطة ميزات النظام الأساسي مثل دعم إعادة توجيه HTTP إلى HTTPS في App Service وAzure Spring Apps. يوضح هذا الرسم التخطيطي المشكلة:

1. يرسل المستعرض طلباً إلى contoso.com الوكيل العكسي.
2. يقوم الوكيل العكسي بإعادة كتابة اسم المضيف إلى contoso.azurewebsites.net في الطلب إلى تطبيق الويب الخلفي (أو إلى نطاق افتراضي مماثل لخدمة أخرى).
3. ينشئ التطبيق عنوان URL مطلق يستند إلى اسم المضيف الوارد contoso.azurewebsites.net، على سبيل المثال، https://contoso.azurewebsites.net/.
4. يتبع المستعرض عنوان URL هذا، والذي ينتقل مباشرة إلى الخدمة الخلفية بدلاً من الرجوع إلى الوكيل العكسي في contoso.com.

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

عناوين URL غير صحيحة لإعادة التوجيه

تحدث حالة شائعة وأكثر تحديداً للسيناريو السابق عند إنشاء عناوين URL لإعادة التوجيه المطلقة. عناوين URL هذه مطلوبة من قبل خدمات الهوية مثل معرف Microsoft Entra عند استخدام بروتوكولات الهوية المستندة إلى المستعرض مثل OpenID Connect أو Open Authorization (OAuth) 2.0 أو Security Assertion Markup Language (SAML) 2.0. يمكن إنشاء عناوين URL لإعادة التوجيه هذه بواسطة خادم التطبيق أو البرنامج الوسيط نفسه، أو، كما ذكر سابقا، بواسطة ميزات النظام الأساسي مثل مصادقة خدمة التطبيق وقدرات التخويل. يوضح هذا الرسم التخطيطي المشكلة:

1. يرسل المستعرض طلباً إلى contoso.com الوكيل العكسي.
2. يعيد الوكيل العكسي كتابة اسم المضيف في contoso.azurewebsites.net الطلب إلى تطبيق الويب الخلفي (أو إلى مجال افتراضي مشابه لخدمة أخرى).
3. ينشئ التطبيق عنوان URL مطلق يستند إلى اسم المضيف الوارد contoso.azurewebsites.net، على سبيل المثال، https://contoso.azurewebsites.net/.
4. ينتقل المتصفح إلى موفر الهوية لمصادقة المستخدم. يتضمن الطلب عنوان URL لإعادة التوجيه الذي تم إنشاؤه للإشارة إلى مكان إرجاع المستخدم بعد المصادقة الناجحة.
5. يتطلب موفرو الهوية عادة عناوين URL لإعادة التوجيه ليتم تسجيلها مقدماً، لذلك في هذه المرحلة يجب على موفر الهوية رفض الطلب لأن عنوان URL لإعادة التوجيه المقدم غير مسجل. (لم يكن من المفترض استخدامه.) إذا تم تسجيل عنوان URL لإعادة التوجيه لسبب ما، فإن موفر الهوية يعيد توجيه المتصفح إلى عنوان URL لإعادة التوجيه المحدد في طلب المصادقة. في هذه الحالة، يكون عنوان URL هو https://contoso.azurewebsites.net/.
6. يتبع المستعرض عنوان URL هذا، والذي ينتقل مباشرة إلى الخدمة الخلفية بدلاً من الرجوع إلى الوكيل العكسي.

ملفات تعريف الارتباط المقطوعة

يمكن أن يؤدي عدم تطابق اسم المضيف أيضاً إلى حدوث مشاكل عندما يصدر خادم التطبيق ملفات تعريف الارتباط ويستخدم اسم المضيف الوارد لإنشاء سمةDomain ملف تعريف الارتباط. تضمن سمة المجال استخدام ملف تعريف الارتباط لهذا المجال المحدد فقط. يمكن إنشاء ملفات تعريف الارتباط هذه بواسطة التعليمات البرمجية للتطبيق أو، كما ذكر سابقا، بواسطة ميزات النظام الأساسي مثل إعداد ترابط ARR لخدمة التطبيق. يوضح هذا الرسم التخطيطي المشكلة:

1. يرسل المستعرض طلباً إلى contoso.com الوكيل العكسي.
2. يقوم الوكيل العكسي بإعادة كتابة اسم المضيف ليكون contoso.azurewebsites.net في الطلب إلى تطبيق الويب الخلفي (أو إلى نطاق افتراضي مماثل لخدمة أخرى).
3. ينشئ التطبيق ملف تعريف ارتباط يستخدم مجالاً استناداً إلى اسم المضيف الوارد contoso.azurewebsites.net. يقوم المتصفح بتخزين ملف تعريف الارتباط لهذا النطاق المحدد بدلاً من contoso.com النطاق الذي يستخدمه المستخدم بالفعل.
4. لا يتضمن المستعرض ملف تعريف الارتباط على أي طلب لاحق لأن contoso.com مجال ملف تعريف الارتباط contoso.azurewebsites.net لا يتطابق مع مجال الطلب. لا يتلقى التطبيق ملف تعريف الارتباط الذي أصدره سابقاً. ونتيجة لذلك، قد يفقد المستخدم الحالة التي من المفترض أن تكون في ملف تعريف الارتباط، أو لا تعمل ميزات مثل ترابط ARR. لسوء الحظ، لا تنشئ أي من هذه المشاكل خطأ أو تكون مرئية مباشرة للمستخدم النهائي. وهذا يجعل من الصعب استكشاف الأخطاء وإصلاحها.

إرشادات التنفيذ لخدمات Azure الشائعة

لتجنب المشاكل المحتملة التي تمت مناقشتها هنا، نوصي بالاحتفاظ باسم المضيف الأصلي في الاستدعاء بين الوكيل العكسي وخادم التطبيق الخلفي:

تكوين الواجهة الخلفية

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

إذا كنت تستضيف تطبيق الويب الخاص بك في App Service، يمكنك إرفاق اسم مجال مخصص بتطبيق الويب وتجنب استخدام اسم المضيف الافتراضي azurewebsites.net نحو النهاية الخلفية. لا تحتاج إلى تغيير دقة DNS عند إرفاق مجال مخصص بتطبيق الويب: يمكنك التحقق من المجال باستخدام TXT سجل دون التأثير على السجلات العادية CNAME أو A السجلات. (ستظل هذه السجلات تحل إلى عنوان IP للوكيل العكسي.) إذا كنت تحتاج إلى TLS/SSL من طرف إلى طرف، يمكنك استيراد شهادة موجودة من Key Vault أو استخدام شهادة خدمة التطبيقات لمجالك المخصص. (لاحظ أن مجانا لا يمكن استخدام الشهادة المدارة ل App Service في هذه الحالة، لأنها تتطلب سجل DNS للمجال لحله مباشرة إلى App Service، وليس الوكيل العكسي.)

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

إذا كان لديك وكيل عكسي أمام APIM (والتي تعمل نفسها أيضاً كوكيل عكسي)، يمكنك تكوين مجال مخصص على مثيل APIM لتجنب استخدام azure-api.net اسم المضيف. يمكنك استيراد شهادة مدارة موجودة أو مجانية إذا كنت تحتاج إلى TLS/SSL من طرف إلى طرف. ومع ذلك، وكما لوحظ سابقًا، فإن واجهات برمجة التطبيقات أقل حساسية للمشكلات الناتجة عن عدم تطابق اسم المضيف، لذلك قد لا يكون هذا التكوين بنفس القدر من الأهمية.

إذا كنت تستضيف تطبيقاتك على أنظمة أساسية أخرى، مثل Kubernetes أو مباشرة على الأجهزة الظاهرية، فلا توجد وظائف مضمنة تعتمد على اسم المضيف الوارد. أنت مسؤول عن كيفية استخدام اسم المضيف في خادم التطبيق نفسه. لا تزال التوصية بالاحتفاظ باسم المضيف تنطبق عادة على أي مكونات في التطبيق الخاص بك تعتمد عليه، ما لم تجعل تطبيقك على وجه التحديد على دراية بالوكلاء العكسيين وتحترم forwarded العناوين أو X-Forwarded-Host، على سبيل المثال.

تكوين الوكيل العكسي

عند تعريف الأطراف الخلفية داخل الوكيل العكسي، لا يزال بإمكانك استخدام المجال الافتراضي للخدمة الخلفية، على سبيل المثال، https://contoso.azurewebsites.net/. يتم استخدام عنوان URL هذا من قبل الوكيل العكسي لحل عنوان IP الصحيح للخدمة الخلفية. إذا كنت تستخدم المجال الافتراضي للنظام الأساسي، يضمن دائما أن يكون عنوان IP صحيحاً. لا يمكنك عادةً استخدام المجال العام، مثل contoso.com، لأنه يجب أن يحل إلى عنوان IP للوكيل العكسي نفسه. (ما لم تستخدم تقنيات تحليل DNS أكثر تقدما، مثل DNS منقسم الأفق).

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

Application Gateway

إذا كنت تستخدم Application Gateway كوكيل عكسي، يمكنك التأكد من الاحتفاظ باسم المضيف الأصلي عن طريق تعطيل تجاوز باسم مضيف جديد في إعداد HTTP الخلفي. يؤدي القيام بذلك إلى تعطيل كل من اختيار اسم المضيف من العنوان الخلفيوالتجاوز باسم مجال معين. (يتجاوز كلا الإعدادين اسم المضيف.) في خصائص Azure Resource Manager لبوابة التطبيق، يتوافق هذا التكوين مع تعيين الخاصية hostName إلى null وإلى pickHostNameFromBackendAddressfalse.

نظرا لإرسال فحوصات السلامة خارج سياق طلب وارد، لا يمكنها تحديد اسم المضيف الصحيح ديناميكياً. بدلاً من ذلك، يجب عليك إنشاء فحص صحة مخصص، وتعطيل اختيار اسم المضيف من إعدادات HTTP الخلفية، وتحديد اسم المضيف بشكل صريح. بالنسبة لاسم المضيف هذا، يجب عليك أيضاً استخدام مجال مخصص مناسب، للتناسق. (ومع ذلك، يمكنك استخدام المجال الافتراضي للنظام الأساسي للاستضافة هنا، لأن تحقيقات السلامة تتجاهل ملفات تعريف الارتباط غير الصحيحة أو إعادة توجيه عناوين URL في الاستجابة.)

الواجهة الأمامية لـ Azure

إذا كنت تستخدم Azure Front Door، يمكنك تجنب تجاوز اسم المضيف عن طريق ترك عنوان المضيف الخلفي فارغاً في تعريف تجمع الخلفية. في تعريف Resource Manager للتجمع الخلفي، يتوافق هذا التكوين مع الإعداد backendHostHeader إلى null.

إذا كنت تستخدم Azure Front Door Standard أو Premium، يمكنك الاحتفاظ باسم المضيف عن طريق ترك عنوان المضيف الأصلي فارغاً في تعريف الأصل. في تعريف Resource Manager للأصل، يتوافق هذا التكوين مع الإعداد originHostHeader إلى null.

API Management

بشكل افتراضي، تتجاوز APIM اسم المضيف الذي يتم إرساله إلى النهاية الخلفية مع مكون المضيف من عنوان URL لخدمة الويب لواجهة برمجة التطبيقات (والذي يتوافق مع serviceUrl قيمة تعريف Resource Manager لواجهة برمجة التطبيقات).

يمكنك فرض إدارة واجهة برمجة التطبيقات على استخدام اسم المضيف للطلب الوارد بدلا من ذلك عن طريق إضافة inbound نهج تعيين عنوان HTTP، كما يلي:

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

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

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

• خدمة التطبيق
• Spring Apps
• بوابة التطبيق
• Azure Front Door
• إدارة API

الموارد ذات الصلة

• شبكة صفر ثقة لتطبيقات الويب مع Azure Firewall و Application Gateway
• حماية واجهات برمجة التطبيقات باستخدام Application Gateway وAPIM
• نشر المؤسسة باستخدام App Services Environment