تحرير

جدار الحماية وبوابة التطبيقات للشبكات الظاهرية

Azure Application Gateway
Azure Firewall
Azure Front Door
Azure Virtual Network
Azure Web Application Firewall

لتأمين أحمال عمل تطبيق Azure، يجب عليك استخدام مقاييس الحماية، مثل المصادقة والتشفير، في التطبيقات نفسها. يمكنك أيضا إضافة طبقات أمان إلى الشبكات الظاهرية (VNets) التي تستضيف التطبيقات. تحمي طبقات الأمان هذه التدفقات الواردة للتطبيق من الاستخدام غير المقصود. كما أنها تحد من التدفقات الصادرة إلى الإنترنت على نقاط النهاية التي يتطلبها تطبيقك فقط. توضح هذه المقالة خدمات أمان Azure Virtual Network مثل Azure DDoS Protection وAzure Firewall وAzure Application Gateway، ومتى تستخدم كل خدمة، وخيارات تصميم الشبكة التي تجمع بين كليهما.

  • توفر Azure DDoS Protection، جنبا إلى جنب مع أفضل ممارسات تصميم التطبيق، ميزات محسنة لتخفيف DDoS لتوفير المزيد من الدفاع ضد هجمات DDoS. يجب تمكين Azure DDOS Protection على أي شبكة ظاهرية محيطة.
  • Azure Firewall هو جدار حماية مدار من الجيل التالي يوفر ترجمة عناوين الشبكة (NAT). يعمل Azure Firewall على تصفية حزمة البيانات على منافذ عناوين بروتوكول الإنترنت (IP) وبروتوكول التحكم في الإرسال وبروتوكول مخطط بيانات المستخدم (TCP/UDP)، أو على سمات بروتوكولات HTTP المستندة إلى التطبيق أو SQL. يطبق Azure Firewall أيضاً تحليل ذكي للمخاطر من Microsoft لتحديد عناوين IP الضارة. لمزيد من المعلومات، راجع ⁧وثائق ⁩Azure Firewall.
  • يتضمن Azure Firewall المتميز جميع وظائف Azure Firewall القياسي والميزات الأخرى، مثل فحص بروتوكول أمان طبقة النقل ونظام الكشف عن التسلل والحماية (IDPS).
  • Azure Application Gateway هو موازن تحميل نسبة استخدام شبكة الويب المدارة والوكيل العكسي الكامل لبروتوكولات HTTP الذي يمكنه إجراء تشفير طبقة مآخذ التوصيل الآمنة (SSL) وفك تشفيرها. تحتفظ بوابة التطبيق بعنوان IP للعميل الأصلي في عنوان HTTP X-Forwarded-For. يستخدم Application Gateway أيضاً جدار حماية تطبيقات الويب لفحص حركة مرور الويب والكشف عن الهجمات في طبقة HTTP. لمزيد من المعلومات، راجع وثائق Application Gateway.
  • يعد Azure Web Application Firewall (WAF) إضافة اختيارية إلى Azure Application Gateway. يوفر فحص طلبات HTTP، ويمنع الهجمات الضارة في طبقة الويب، مثل إدخال SQL أو البرمجة النصية عبر المواقع. لمزيد من المعلومات، راجع وثائق Web Application Firewall.

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

يستخدم Azure Firewall وAzure Application Gateway تقنيات مختلفة، ويدعمان تأمين التدفقات المختلفة:

تدفق التطبيق يمكن تصفيته بواسطة Azure Firewall يمكن تصفيته بواسطة WAF على Application Gateway
نسبة استخدام الشبكة لبروتوكولات HTTP من الموقع المحلي/الإنترنت إلى Azure (الواردة) ‏‏نعم‬ ‏‏نعم‬
نسبة استخدام الشبكة لبروتوكولات HTTP من Azure إلى الموقع المحلي/الإنترنت (الصادرة) ‏‏نعم‬ لا
نسبة استخدام الشبكة غير بروتوكولات HTTP، الواردة/الصادرة ‏‏نعم‬ لا

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

Diagram that demonstrates the virtual network security decision tree.

ستغطي هذه المقالة التصميمات الموصى بها على نطاق واسع من المخطط البياني التدفقي، وغيرها من التصاميم القابلة للتطبيق في سيناريوهات أقل شيوعاً:

  • Azure Firewall بمفرده، عندما لا توجد تطبيقات ويب في الشبكة الظاهرية. سيتحكم في كل من نسبة استخدام الشبكة الواردة إلى التطبيقات ونسبة استخدام الشبكة الصادرة.
  • Application Gateway بمفرده، عندما تكون تطبيقات الويب فقط في الشبكة الظاهرية، وتوفر مجموعات أمان الشبكة (NSG) تصفية إخراج كافية. يمكن أن تمنع الوظائف التي يوفرها Azure Firewall العديد من سيناريوهات الهجوم (مثل النقل غير المصرح للبيانات وIDPS وما إلى ذلك). لهذا السبب، لا يوصى عادة بسيناريو Application Gateway بمفرده وبالتالي غير موثق وغير موجود في مخطط البياني التدفقي أعلاه.
  • Azure Firewall وApplication Gateway بالتوازي، وهو أحد التصميمات الأكثر شيوعاً. استخدم هذه المجموعة عندما تريد أن يحمي Azure Application Gateway تطبيقات بروتوكولات HTTP من هجمات الويب، وAzure Firewall لحماية جميع أحمال العمل الأخرى وتصفية نسبة استخدام الشبكة الصادرة.
  • Application Gateway أمام Azure Firewall، عندما تريد أن يعمل Azure Firewall على فحص نسبة استخدام الشبكة وWAF لحماية نسبة استخدام الشبكة، ويحتاج التطبيق إلى معرفة عنوان IP المصدر للعميل. من خلال Azure Firewall المتميز وفحص TLS، يدعم هذا التصميم سيناريو SSL الشامل أيضاً.
  • Azure Firewall أمام Application Gateway، عندما تريد أن يعمل Azure Firewall على فحص نسبة استخدام الشبكة وتصفيتها قبل أن تصل إلى Application Gateway. نظراً لأن Azure Firewall لن يفك تشفير نسبة استخدام شبكة HTTPS، فإن الوظيفة التي يضيفها إلى Application Gateway محدودة. هذا السيناريو غير موثق في المخطط البياني التدفقي الوارد أعلاه.

في الجزء الأخير من هذه المقالة، يتم وصف اختلافات التصميمات الأساسية السابقة. تتضمن هذه الاختلافات ما يلي:

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

إشعار

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

Azure Firewall فقط

إذا لم تكن هناك أحمال عمل مستندة إلى الويب في الشبكة الظاهرية يمكنها الاستفادة من WAF، يمكنك استخدام Azure Firewall فقط. التصميم في هذه الحالة بسيط، ولكن مراجعة تدفق حزمة البيانات ستساعد على فهم التصاميم الأكثر تعقيداً. في هذا التصميم، يتم إرسال جميع حركة المرور الواردة إلى جدار حماية Azure عبر المسارات المعرفة من قبل المستخدم (UDRs) للاتصالات من أماكن العمل أو شبكات Azure الظاهرية الأخرى. يتم توجيهه إلى عنوان IP العام لجدار حماية Azure للاتصالات من الإنترنت العام، كما يظهر الرسم التخطيطي أدناه. يتم إرسال نسبة استخدام الشبكة الصادرة من الشبكات Azure الظاهرية إلى جدار الحماية عبر المسارات المحددة من قبل المستخدم، كما هو موضح في مربع الحوار أدناه.

يلخص الجدول التالي تدفقات نسبة استخدام الشبكة لهذا السيناريو:

سير العمل يمر عبر Application Gateway / WAF يمر عبر Azure Firewall
نسبة استخدام شبكة بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure ‏‫غير متوفر‬ نعم (راجع أدناه)
نسبة استخدام شبكة بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي ‏‫غير متوفر‬ ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure ‏‫غير متوفر‬ ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي ‏‫غير متوفر‬ ‏‏نعم‬

لن يفحص Azure Firewall نسبة استخدام شبكة بروتوكولات HTTP الواردة. ولكنه سيكون قادرا على تطبيق قواعد الطبقة 3 والطبقة 4 وقواعد التطبيق المستندة إلى FQDN. سيعمل Azure Firewall على فحص نسبة استخدام شبكة بروتوكولات HTTP الصادرة اعتماداً على طبقة Azure Firewall وما إذا كنت تقوم بتكوين فحص TLS:

  • سيقوم Azure Firewall Standard بفحص سمات الطبقة 3 والطبقة 4 فقط من الحزم في قواعد الشبكة، ورأس HTTP المضيف في قواعد التطبيق.
  • يضيف Azure Firewall Premium قدرات مثل فحص رؤوس HTTP الأخرى (مثل عامل المستخدم) وتمكين فحص TLS لتحليل حزم البيانات بصورة أعمق. لا يعادل Azure Firewall جدار حماية تطبيقات الويب. إذا كان لديك أحمال عمل ويب في الشبكة الظاهرية، فإنه يوصى بشدة باستخدام WAF.

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

  • تنشر خدمة Azure Firewall عدة مثيلات تحت الأغطية، هنا مع عنوان IP الأمامي 192.168.100.4 والعناوين الداخلية من النطاق 192.168.100.0/26. عادة ما تكون هذه المثيلات الفردية غير مرئية لمسؤول Azure. ولكن ملاحظة الفرق مفيدة في بعض الحالات، مثل عند استكشاف مشكلات الشبكة وإصلاحها.
  • إذا كانت نسبة استخدام الشبكة تأتي من شبكة ظاهرية خاصة محلية (VPN) أو بوابة Azure ExpressRoute بدلاً من الإنترنت، يبدأ العميل الاتصال بعنوان IP الخاص بالجهاز الظاهري. لا يبدأ الاتصال بعنوان IP لجدار الحماية، ولن يوفر جدار الحماية أي ترجمة عناوين شبكة للمصدر افتراضياً.

بناء الأنظمة

يوضح الرسم التخطيطي التالي تدفق نسبة استخدام الشبكة بافتراض أن عنوان IP للمثيل هو 192.168.100.7.

Diagram that shows Azure Firewall only.

‏‏سير العمل‬

  1. يبدأ العميل الاتصال بعنوان IP العام لجدار حماية Azure:
    • عنوان IP الخاص بالمصدر: ClientPIP
    • عنوان IP الخاص بالوجهة: AzFwPIP
  2. يتم توزيع الطلب إلى عنوان IP العام لجدار حماية Azure على مثيل خلفي لجدار الحماية، في هذه الحالة 192.168.100.7. تترجم قاعدة ترجمة عناوين الشبكة الخاصة بالوجهة (DNAT) الخاصة بـ Azure Firewall عنوان IP للوجهة إلى عنوان IP للتطبيق داخل الشبكة الظاهرية. يعد Azure Firewall أيضاً ترجمات عناوين الشبكة الخاصة بالمصدر (SNAT) حزمة البيانات إذا كان ذلك DNAT. لمزيد من المعلومات، راجع المشاكل المعروفة المتعلقة بخدمة Azure Firewall. يرى الجهاز الظاهري عناوين IP التالية في الحزمة الواردة:
    • عنوان IP الخاص بالمصدر: 192.168.100.7
    • عنوان IP الخاص بالوجهة: 192.168.1.4
  3. يجيب الجهاز الظاهري على طلب التطبيق، مع عكس عناوين IP الخاصة بالمصدر والوجهة. لا يتطلب التدفق الوارد مساراً محدداً من قبل المستخدم (UDR)، لأن عنوان IP الخاص بالمصدر هو عنوان IP الخاص بـ Azure Firewall. المسار المحدد من قبل المستخدم في الرسم التخطيطي لـ 0.0.0.0/0 للاتصالات الصادرة، للتأكد من أن حزم البيانات إلى الإنترنت العام تمر عبر Azure Firewall.
    • عنوان IP الخاص بالمصدر: 192.168.1.4
    • عنوان IP الخاص بالوجهة: 192.168.100.7
  4. وأخيرا، يتراجع Azure Firewall عن عمليات SNAT و DNAT، ويسلم الاستجابة للعميل:
    • عنوان IP الخاص بالمصدر: AzFwPIP
    • عنوان IP الخاص بالوجهة: ClientPIP

Application Gateway فقط

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

إشعار

لا يعد هذا تصميماً موصى به نظراً لاستخدام Azure Firewall للتحكم في التدفقات الصادرة (بدلاً من مجموعات أمان الشبكة فقط) سيمنع سيناريوهات هجوم معينة مثل نقل غير مصرّح للبيانات، حيث تتأكد من أن أحمال العمل الخاصة بك ترسل البيانات فقط إلى قائمة معتمدة من عناوين URL. علاوة على ذلك، تعمل مجموعات أمان الشبكة فقط على الطبقة 3 والطبقة 4 وليس لديها دعم FQDN.

الفرق الرئيسي عن التصميم السابق مع Azure Firewall فقط هو أن Application Gateway لا يعمل كجهاز توجيه مع ترجمة عناوين الشبكة. يعمل كوكيل تطبيق عكسي كامل. أي أن Application Gateway يوقف جلسة عمل الويب من العميل، وينشئ جلسة منفصلة مع أحد الخوادم الخلفية الخاصة بها. يجب إرسال اتصالات HTTP (S) الواردة من الإنترنت إلى عنوان IP العام لبوابة التطبيق، أو الاتصالات من Azure أو محليا إلى عنوان IP الخاص بالبوابة. سيتبع إرجاع نسبة استخدام الشبكة من أجهزة Azure الظاهرية توجيه الشبكة الظاهرية القياسية مرة أخرى إلى Application Gateway (راجع سير حزمة البيانات لمعرفة المزيد من التفاصيل). ستنتقل تدفقات الإنترنت الصادرة من أجهزة Azure الظاهرية مباشرة إلى الإنترنت.

يلخص الجدول التالي تدفقات نسبة استخدام الشبكة:

سير العمل يمر عبر Application Gateway / WAF يمر عبر Azure Firewall
نسبة استخدام شبكة بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure ‏‏نعم‬ غير متوفر
نسبة استخدام شبكة بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‫غير متاح
نسبة استخدام الشبكة غير بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure لا ‏‫غير متاح
نسبة استخدام الشبكة غير بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‫غير متاح

بناء الأنظمة

يوضح مثال سير حزمة البيانات التالية كيفية وصول العميل إلى التطبيق المضيف للجهاز الظاهري من الإنترنت العام.

Diagram that shows Application Gateway only.

‏‏سير العمل‬

  1. يبدأ العميل الاتصال بعنوان IP العام لبوابة تطبيق Azure:
    • عنوان IP الخاص بالمصدر: ClientPIP
    • عنوان IP الخاص بالوجهة: AppGwPIP
  2. يتم توزيع الطلب إلى IP العام لبوابة التطبيق على مثيل خلفي للبوابة، في هذه الحالة 192.168.200.7. يوقف مثيل Application Gateway الذي يتلقى الطلب الاتصال من العميل، وينشئ اتصالاً جديداً بإحدى الأطراف الخلفية. تظهر النهاية الخلفية مثيل Application Gateway كعنوان IP الخاص بالمصدر. يدرج Application Gateway عنوان X-Forwarded-For HTTP مع عنوان IP الأصلي الخاص بالعميل.
    • عنوان IP الخاص بالمصدر: 192.168.200.7 (عنوان IP الخاص لمثيل Application Gateway)
    • عنوان IP الخاص بالوجهة: 192.168.1.4
    • عنوان X-Forwarded-For:‏ ClientPIP
  3. يجيب الجهاز الظاهري على طلب التطبيق، مع عكس عناوين IP الخاصة بالمصدر والوجهة. يعرف الجهاز الظاهري بالفعل كيفية الوصول إلى Application Gateway، لذلك لا يحتاج إلى مسار محدد من قبل المستخدم.
    • عنوان IP الخاص بالمصدر: 192.168.1.4
    • عنوان IP الخاص بالوجهة: 192.168.200.7
  4. وأخيرا، يجيب مثيل Application Gateway على العميل:
    • عنوان IP الخاص بالمصدر: AppGwPIP
    • عنوان IP الخاص بالوجهة: ClientPIP

يضيف Azure Application Gateway بيانات التعريف إلى عناوين HTTP الخاصة بحزمة البيانات، مثل عنوان X-Forwarded-For الذي يحتوي على عنوان IP الخاص بالعميل الأصلي. تحتاج بعض خوادم التطبيقات إلى عنوان IP للعميل الخاص بالمصدر لخدمة محتوى محدد للموقع الجغرافي، أو للتسجيل. لمزيد من المعلومات، راجع عمليات كيفية عمل بوابة التطبيق.

  • عنوان 192.168.200.7 IP هو أحد المثيلات التي تنشرها خدمة Azure Application Gateway تحت الأغطية، هنا مع عنوان 192.168.200.4IP الداخلي الخاص للواجهة الأمامية . عادة ما تكون هذه المثيلات الفردية غير مرئية لمسؤول Azure. ولكن ملاحظة الفرق مفيدة في بعض الحالات، مثل عند استكشاف مشكلات الشبكة وإصلاحها.

  • يكون التدفق مشابهاً إذا كان العميل يأتي من شبكة محلية عبر VPN أو بوابة ExpressRoute. الفرق هو وصول العميل إلى عنوان IP الخاص لـ Application Gateway بدلاً من العنوان العام.

إشعار

راجع الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي للحصول على مزيد من المعلومات حول X-Forwarded-For والحفاظ على اسم المضيف بناء على طلب.

Firewall وApplication Gateway بالتوازي.

نظراً لبساطته ومرونته، غالباً ما يكون تشغيل Application Gateway وAzure Firewall بالتوازي هو أفضل سيناريو.

يمكنك تنفيذ هذا التصميم إذا كان هناك مزيج من أحمال العمل على الويب وغير المتعلقة بالويب في الشبكة الظاهرية. يحمي Azure WAF في Azure Application Gateway نسبة استخدام الشبكة الواردة إلى أحمال عمل الويب، ويفحص جدار حماية Azure نسبة استخدام الشبكة الواردة للتطبيقات الأخرى. سيغطي Azure Firewall التدفقات الصادرة من كلا نوعي أحمال العمل.

يجب إرسال اتصالات بروتوكولات HTTP الواردة من الإنترنت إلى عنوان IP العام الخاصة بـ Application Gateway أو اتصالات بروتوكولات HTTP من Azure أو محلياً إلى عنوان IP الخاص به. سيرسل توجيه الشبكة الظاهرية القياسية حزم البيانات من Application Gateway إلى أجهزة الوجهة الظاهرية، وكذلك من أجهزة الوجهة الظاهرية مرة أخرى إلى Application Gateway (راجع سير حزمة البيانات لمعرفة المزيد من التفاصيل). بالنسبة للاتصالات غير بروتوكولات HTTP الواردة، يجب أن تستهدف نسبة استخدام الشبكة عنوان IP العام الخاص بـ Azure Firewall (إذا كان قادماً من الإنترنت العام)، أو سيتم إرسالها من خلال Azure Firewall بواسطة المسارات المحددة من قبل المستخدم (إذا كانت قادمة من شبكات Azure الظاهرية الأخرى أو الشبكات المحلية). ستتم إعادة توجيه جميع التدفقات الصادرة من أجهزة Azure الظاهرية إلى Azure Firewall بواسطة المسارات المحددة من قبل المستخدم.

يلخص الجدول التالي تدفقات نسبة استخدام الشبكة لهذا السيناريو:

سير العمل يمر عبر Application Gateway / WAF يمر عبر Azure Firewall
نسبة استخدام شبكة بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure ‏‏نعم‬ لا
نسبة استخدام شبكة بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure لا ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‏نعم‬

يمنح هذا التصميم تصفية خروج أكثر دقة من مجموعات أمان الشبكة. على سبيل المثال، إذا كانت التطبيقات تحتاج إلى اتصال بحساب تخزين Azure معين، يمكنك استخدام عوامل تصفية تستند إلى اسم المجال المؤهل بالكامل (FQDN). باستخدام عوامل التصفية المستندة إلى FQDN، لا ترسل التطبيقات البيانات إلى حسابات التخزين المخادعة. تعذر منع هذا السيناريو فقط باستخدام مجموعات أمان الشبكة. غالباً ما يتم استخدام هذا التصميم حيث تتطلب نسبة استخدام الشبكة الصادرة تصفية تستند إلى FQDN. أحد الأمثلة على ذلك هو عند الحد من نسبة استخدام الشبكة الخروج من مجموعة خدمات Azure Kubernetes.

البُنى

يوضح الرسم التخطيطي التالي تدفق نسبة استخدام الشبكة لاتصالات HTTP(S) الواردة من عميل خارجي:

Diagram that shows Application Gateway and Azure Firewall in parallel, ingress flow,

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

Diagram that shows Application Gateway and Azure Firewall in parallel, egress flow.

خطوات تدفق حزمة البيانات لكل خدمة هي نفسها كما هو الحال في خيارات التصميم المستقلة السابقة.

Application Gateway قبل Firewall

يتم شرح هذا التصميم بمزيد من التفصيل في شبكة الثقة المعدومة لتطبيقات الويب مع جدار حماية Azure وبوابة التطبيق، سيركز هذا المستند على المقارنة مع خيارات التصميم الأخرى. في هذا المخطط، تمر حركة مرور الويب الواردة عبر كل من جدار حماية Azure و WAF. يوفر WAF الحماية في طبقة تطبيق الويب. يعمل Azure Firewall كنقطة تسجيل وتحكم مركزية، ويفحص نسبة استخدام الشبكة بين Application Gateway والخوادم الخلفية. Application Gateway وAzure Firewall لا يتواجدان بالتوازي، ولكن واحداً تلو الآخر.

باستخدام Azure Firewall Premium، يمكن أن يدعم هذا التصميم السيناريوهات الشاملة، حيث يطبق جدار حماية Azure فحص TLS لتنفيذ IDPS على نسبة استخدام الشبكة المشفرة بين بوابة التطبيق والواجهة الخلفية للويب.

هذا التصميم مناسب للتطبيقات التي تحتاج إلى معرفة عناوين IP الخاصة بمصدر العميل الواردة، على سبيل المثال لخدمة المحتوى الخاص بالموقع الجغرافي أو للتسجيل. يسجل Application Gateway أمام Azure Firewall عنوان IP الخاص بمصدر حزمة البيانات الواردة في عنوان X-forwarded-for، ليكون بإمكان خادم الويب رؤية عنوان IP الأصلي في هذا العنوان. لمزيد من المعلومات، راجع عمليات كيفية عمل بوابة التطبيق.

يجب إرسال اتصالات بروتوكولات HTTP الواردة من الإنترنت إلى عنوان IP العام لـ Application Gateway أو اتصالات بروتوكولات HTTP من Azure أو محلياً إلى عنوان IP الخاص. من المسارات المحددة من قبل المستخدم لـ Application Gateway ستتأكد من توجيه حزم البيانات من خلال Azure Firewall (راجع سير حزمة البيانات لمعرفة المزيد من التفاصيل). بالنسبة للاتصالات غير بروتوكولات HTTP الواردة، يجب أن تستهدف نسبة استخدام الشبكة عنوان IP العام الخاص بـ Azure Firewall (إذا كان قادماً من الإنترنت العام)، أو سيتم إرسالها من خلال Azure Firewall بواسطة المسارات المحددة من قبل المستخدم (إذا كانت قادمة من شبكات Azure الظاهرية الأخرى أو الشبكات المحلية). ستتم إعادة توجيه جميع التدفقات الصادرة من أجهزة Azure الظاهرية إلى Azure Firewall بواسطة المسارات المحددة من قبل المستخدم.

ملاحظة مهمة لهذا التصميم هي أن Azure Firewall Premium سيرى نسبة استخدام الشبكة باستخدام عنوان IP مصدر من الشبكة الفرعية لبوابة التطبيق. إذا تم تكوين هذه الشبكة الفرعية بعنوان IP خاص (في 10.0.0.0/8أو 192.168.0.0/16172.16.0.0/12 أو 100.64.0.0/10)، فإن Azure Firewall Premium سيتعامل مع نسبة استخدام الشبكة من بوابة التطبيق على أنها داخلية، ولن تطبق قواعد IDPS لحركة المرور الواردة. يمكنك العثور على مزيد من المعلومات حول توجيهات قاعدة IDPS لجدار حماية Azure وبادئات IP الخاصة ل IDPS في قواعد IDPS لجدار حماية Azure. وبالتالي، يوصى بتعديل بادئات IDPS الخاصة في نهج Azure Firewall بحيث لا تعتبر الشبكة الفرعية لبوابة التطبيق مصدرا داخليا، لتطبيق توقيعات IDPS الواردة والصادرة على حركة المرور.

يلخص الجدول التالي تدفقات نسبة استخدام الشبكة لهذا السيناريو:

سير العمل يمر عبر Application Gateway / WAF يمر عبر Azure Firewall
نسبة استخدام شبكة بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure ‏‏نعم‬ ‏‏نعم‬
نسبة استخدام شبكة بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure لا ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‏نعم‬

بالنسبة لنسبة استخدام الشبكة من المواقع المحلية أو الإنترنت إلى Azure، سيعمل Azure Firewall على فحص التدفقات التي سمح بها WAF بالفعل. اعتمادا على ما إذا كانت بوابة التطبيق تشفر نسبة استخدام الشبكة الخلفية (نسبة استخدام الشبكة من بوابة التطبيق إلى خوادم التطبيق)، سيكون لديك سيناريوهات محتملة مختلفة:

  1. يشفر Application Gateway نسبة استخدام الشبكة باتباع مبادئ الثقة المعدومة (تشفير TLS من طرف إلى طرف)، وسيتلقى Azure Firewall نسبة استخدام الشبكة المشفرة. ومع ذلك، سيتمكن Azure Firewall Standard من تطبيق قواعد الفحص، مثل تصفية الطبقة 3 والطبقة 4 في قواعد الشبكة، أو تصفية FQDN في قواعد التطبيق باستخدام عنوان TLS Server Name Indication (SNI). يوفر Azure Firewall Premium رؤية أعمق مع فحص TLS، مثل التصفية المستندة إلى عنوان URL.
  2. في حال إرسال Application Gateway نسبة استخدام شبكة غير مشفرة إلى خوادم التطبيقات، فسيظهر لـ Azure Firewall نسبة استخدام الشبكة الواردة في نص واضح. لا يلزم فحص TLS في Azure Firewall.
  3. إذا تم تمكين IDPS في Azure Firewall، فسيتحقق من أن عنوان مضيف HTTP يطابق عنوان IP الخاص بالوجهة. ولهذا الغرض، ستحتاج إلى تحليل الاسم لـ FQDN المحدد في عنوان المضيف. يمكن تحقيق تحليل الاسم هذا باستخدام المناطق الخاصة لـ Azure DNS وإعدادات DNS الافتراضية لـ Azure Firewall باستخدام Azure DNS. يمكن تحقيق ذلك أيضا مع خوادم DNS المخصصة التي تحتاج إلى تكوين في إعدادات Azure Firewall. (لمزيد من المعلومات، راجع الإعدادات DNS لـ Azure Firewall.) إذا لم يكن هناك وصول إداري إلى الشبكة الظاهرية حيث يتم نشر Azure Firewall، فإن الأسلوب الأخير هو الإمكانية الوحيدة. مثال واحد هو مع خدمات Azure Firewall المنشورة في مراكز Virtual WAN الآمنة.

بناء الأنظمة

بالنسبة إلى بقية التدفقات (نسبة استخدام الشبكة غير بروتوكولات HTTP الواردة وأي نسبة استخدام الشبكة الصادرة)، سيوفر Azure Firewall فحص IDPS وفحص TLS عند الاقتضاء. كما يوفر التصفية المستندة إلى FQDN في قواعد الشبكة استناداً إلى DNS.

Diagram that shows Application Gateway before Azure Firewall.

‏‏سير العمل‬

تتبع نسبة استخدام الشبكة من الإنترنت العام هذا التدفق:

  1. يبدأ العميل الاتصال بعنوان IP العام لبوابة تطبيق Azure:
    • عنوان IP الخاص بالمصدر: ClientPIP
    • عنوان IP الخاص بالوجهة: AppGwPIP
  2. يتم توزيع الطلب إلى IP العام لبوابة التطبيق على مثيل خلفي للبوابة، في هذه الحالة 192.168.200.7. يوقف مثيل Application Gateway الاتصال من العميل، وينشئ اتصالاً جديداً بإحدى الخلفيات. يقوم UDR إلى 192.168.1.0/24 في الشبكة الفرعية لبوابة التطبيق بإعادة توجيه الحزمة إلى جدار حماية Azure، مع الحفاظ على عنوان IP الوجهة إلى تطبيق الويب:
    • عنوان IP الخاص بالمصدر: 192.168.200.7 (عنوان IP خاص لمثيل Application Gateway)
    • عنوان IP الخاص بالوجهة: 192.168.1.4
    • عنوان X-Forwarded-For:‏ ClientPIP
  3. لا يقوم Azure Firewall بترجمة عناوين شبكة المصدر لنسبة استخدام الشبكة، لأن نسبة استخدام الشبكة ستنتقل إلى عنوان IP خاص. بل يعيد توجيه نسبة استخدام الشبكة إلى الجهاز الظاهري للتطبيق إذا كانت القواعد تسمح بذلك. لمزيد من المعلومات، راجع جدار حماية Azure مقابل الجهاز الظاهري للشبكة. ومع ذلك، إذا وصلت نسبة استخدام الشبكة إلى قاعدة تطبيق في جدار الحماية، فسيرى حمل العمل عنوان IP المصدر لمثيل جدار الحماية المحدد الذي عالج الحزمة، لأن جدار حماية Azure سيوكيل الاتصال:
    • عنوان IP المصدر إذا تم السماح بنسبة استخدام الشبكة بواسطة قاعدة شبكة Azure Firewall: 192.168.200.7 (عنوان IP الخاص لأحد مثيلات Application Gateway).
    • عنوان IP المصدر إذا تم السماح بنسبة استخدام الشبكة بواسطة قاعدة تطبيق Azure Firewall: 192.168.100.7 (عنوان IP الخاص لأحد مثيلات Azure Firewall).
    • عنوان IP الخاص بالوجهة: 192.168.1.4
    • عنوان X-Forwarded-For:‏ ClientPIP
  4. يجيب الجهاز الظاهري على الطلب، مع عكس عناوين IP الخاصة بالمصدر والوجهة. يلتقط المسار المحدد من قبل المستخدم إلى 192.168.200.0/24 حزمة البيانات المرسلة مرة أخرى إلى Application Gateway ويعيد توجيهها إلى Azure Firewall، مع الحفاظ على عنوان IP الخاص بالوجهة باتجاه Application Gateway.
    • عنوان IP الخاص بالمصدر: 192.168.1.4
    • عنوان IP الخاص بالوجهة: 192.168.200.7
  5. هنا مرة أخرى لا يقوم Azure Firewall بترجمة عناوين شبكة المصدر لنسبة استخدام الشبكة، لأنها ستنتقل إلى عنوان IP خاص، وتعيد توجيه نسبة استخدام الشبكة إلى Application Gateway.
    • عنوان IP الخاص بالمصدر: 192.168.1.4
    • عنوان IP الخاص بالوجهة: 192.168.200.7
  6. وأخيرا، يجيب مثيل Application Gateway على العميل:
    • عنوان IP الخاص بالمصدر: AppGwPIP
    • عنوان IP الخاص بالوجهة: ClientPIP

تمر التدفقات الصادرة من الأجهزة الظاهرية إلى الإنترنت العام عبر Azure Firewall، كما هو محدد من قبل المسار المحدد من قبل المستخدم إلى 0.0.0.0/0.

Application Gateway بعد firewall

يتيح هذا التصميم لـ Azure Firewall تصفية نسبة استخدام الشبكة الضارة وتجاهلها قبل أن تصل إلى Application Gateway. على سبيل المثال، يمكن تطبيق ميزات مثل التصفية المستندة إلى التحليل الذكي للمخاطر. ميزة أخرى هي أن التطبيق يحصل على نفس عنوان IP العام لكل من حركة المرور الواردة والصادرة، بغض النظر عن البروتوكول. ومع ذلك، فإن Azure Firewall يترجم عناوين الشبكة الخاصة بالمصدر لنسبة استخدام الشبكة الواردة، لذلك لن يكون للتطبيق قابلية وصول لعنوان IP الأصلي لطلبات HTTP. من منظور الإدارة، على سبيل المثال لأغراض استكشاف الأخطاء وإصلاحها، يمكنك الحصول على عنوان IP الفعلي للعميل لاتصال معين عن طريق ربطه بسجلات SNAT لجدار حماية Azure.

هناك ميزة محدودة في هذا السيناريو، لأن سيظهر لـ Azure Firewall نسبة استخدام الشبكة المشفرة فقط وهي تنتقل إلى Application Gateway. قد تكون هناك سيناريوهات يُفضل فيها هذا التصميم. إحدى الحالات هي إذا كان WAF آخر سابقاً في الشبكة (على سبيل المثال، مع Azure Front Door)، والذي يمكن أن يلتقط عنوان IP المصدر الأصلي في عنوان HTTP X-Forwarded-For. أو يفضل التصميم إذا كانت هناك حاجة إلى العديد من عناوين IP العامة.

يجب أن تستهدف تدفقات بروتوكولات HTTP الواردة من الإنترنت العام عنوان IP العام لـ Azure Firewall، وسيجري Azure Firewall ‏DNAT (وSNAT) لحزم البيانات إلى عنوان IP الخاص بـ Application Gateway. من شبكات Azure الظاهرية الأخرى أو الشبكات المحلية، يجب إرسال حركة مرور HTTP(S) إلى IP الخاص ببوابة التطبيق، وإعادة توجيهها من خلال جدار حماية Azure باستخدام UDRs. سيتأكد توجيه الشبكة الظاهرية القياسية من عودة نسبة استخدام الشبكة من أجهزة Azure الظاهرية إلى Application Gateway، ومن Application Gateway إلى Azure Firewall إذا تم استخدام قواعد DNAT. بالنسبة لنسبة استخدام الشبكة من مواقع الويب المحلية أو Azure UDRs في الشبكة الفرعية لبوابة التطبيق (راجع سير الحزمة لمزيد من التفاصيل). سيتم إرسال جميع نسب استخدام الشبكة الصادرة من أجهزة Azure الظاهرية إلى الإنترنت من خلال Azure Firewall بواسطة المسارات المحددة من قبل المستخدم.

يلخص الجدول التالي تدفقات نسبة استخدام الشبكة لهذا السيناريو:

سير العمل يمر عبر Application Gateway / WAF يمر عبر Azure Firewall
نسبة استخدام شبكة بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure ‏‏نعم‬ نعم (راجع أدناه)
نسبة استخدام شبكة بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من الإنترنت/نظام محلي إلى Azure لا ‏‏نعم‬
نسبة استخدام الشبكة غير بروتوكولات HTTP من Azure إلى الإنترنت/نظام محلي لا ‏‏نعم‬

بالنسبة إلى نسبة استخدام شبكة بروتوكولات HTTP الواردة، لن يفك Azure Firewall عادةً تشفير نسبة استخدام الشبكة. سيطبق بدلاً من بتطبيق نُهج IDPS التي لا تتطلب فحص TLS، مثل التصفية المستندة إلى عنوان IP أو استخدام عناوين HTTP.

بناء الأنظمة

لا يظهر للتطبيق عنوان IP الخاص بالمصدر الأصلي لنسبة استخدام شبكة الويب؛ ولا يترجم Azure Firewall عناوين الشبكة الخاصة بالمصدر لحزم البيانات كما أنها تأتي في الشبكة الظاهرية. لتجنب هذه المشكلة، استخدم Azure Front Door أمام جدار الحماية. يدخِل Azure Front Door عنوان IP الخاص بالعميل كعنوان HTTP قبل أن يدخل شبكة Azure الظاهرية.

Diagram that shows Application Gateway after Azure Firewall.

‏‏سير العمل‬

تتبع نسبة استخدام الشبكة من الإنترنت العام هذا التدفق:

  1. يبدأ العميل الاتصال بعنوان IP العام لجدار حماية Azure:
    • عنوان IP الخاص بالمصدر: ClientPIP
    • عنوان IP الخاص بالوجهة: AzFWPIP
  2. يتم توزيع الطلب إلى عنوان IP العام لجدار حماية Azure على مثيل خلفي لجدار الحماية، في هذه الحالة 192.168.100.7. يترجم Azure Firewall عناوين الشبكة الخاصة بالوجهة لمنفذ الويب، عادةً TCP 443، إلى عنوان IP الخاص لمثيل Application Gateway. يترجم Azure Firewall أيضاً عناوين الشبكة الخاصة بالمصدر عند إجراء ترجمة لعناوين الشبكة الخاصة بالوجهة. لمزيد من المعلومات، راجع المشكلات المعروفة في Azure Firewall:
    • عنوان IP المصدر: 192.168.100.7 (عنوان IP الخاص لمثيل Azure Firewall)
    • عنوان IP الخاص بالوجهة: 192.168.200.4
  3. تنشئ Application Gateway جلسة عمل جديدة بين المثيل الذي يعالج الاتصال وأحد الخوادم الخلفية. عنوان IP الأصلي للعميل غير موجود في الحزمة:
    • عنوان IP الخاص بالمصدر: 192.168.200.7 (عنوان IP الخاص لمثيل Application Gateway)
    • عنوان IP الخاص بالوجهة: 192.168.1.4
    • عنوان X-Forwarded-For:‏ 192.168.100.7
  4. يجيب الجهاز الظاهري على بوابة التطبيق، مع عكس عناوين IP المصدر والوجهة:
    • عنوان IP الخاص بالمصدر: 192.168.1.4
    • عنوان IP الخاص بالوجهة: 192.168.200.7
  5. يرد Application Gateway على عنوان IP الخاص بالمصدر SNAT لمثيل Azure Firewall. حتى إذا كان الاتصال قادما من مثيل Application Gateway معين مثل .7، فإن Azure Firewall يرى عنوان IP الداخلي لبوابة .4 التطبيق كعنوان IP المصدر:
    • عنوان IP الخاص بالمصدر: 192.168.200.4
    • عنوان IP الخاص بالوجهة: 192.168.100.7
  6. وأخيرا، يتراجع جدار حماية Azure عن SNAT و DNAT ويجيب على العميل:
    • عنوان IP الخاص بالمصدر: AzFwPIP
    • عنوان IP الخاص بالوجهة: ClientPIP

حتى إذا لم يكن لدى Application Gateway وحدات استماع تم تكوينها للتطبيقات، فإنها لا تزال بحاجة إلى عنوان IP عام حتى تتمكن Microsoft من إدارتها.

إشعار

المسار الافتراضي إلى 0.0.0.0/0 في الشبكة الفرعية لـ Application Gateway الذي يشير إلى Azure Firewall غير مدعوم، لأنه سيقطع نسبة استخدام شبكة وحدة التحكم المطلوبة للعملية الصحيحة لـ Azure Application Gateway.

العملاء المحليون

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

  • تقع بوابة VPN أو بوابة ExpressRoute أمام Azure Firewall أو Application Gateway.
  • يستخدم WAF عنوان IP الخاص لـ Application Gateway.
  • لا يدعم Azure Firewall‏ DNAT لعناوين IP الخاصة. لهذا السبب يجب عليك استخدام ترجمات UDR لإرسال نسبة استخدام الشبكة الواردة إلى Azure Firewall من بوابات VPN أو ExpressRoute.
  • تأكد من التحقق من المحاذير حول التوجيه الإجباري لأسفل لـ Azure Application Gatewayو Azure Firewall. حتى إذا لم يكن حمل العمل الخاص بك بحاجة إلى اتصال صادر بالإنترنت العام، فلا يمكنك إدخال مسار افتراضي مثل 0.0.0.0/0 لـ Application Gateway التي تشير إلى الشبكة المحلية، أو ستقاطع نسبة استخدام الشبكة. بالنسبة إلى Azure Application Gateway، يحتاج المسار الافتراضي إلى الإشارة إلى الإنترنت العام.

بناء الأنظمة

يوضح الرسم التخطيطي التالي تصميم Azure Application Gateway وAzure Firewall المتوازي. يأتي عملاء التطبيق من شبكة محلية متصلة بـ Azure عبر VPN أو ExpressRoute:

Diagram that shows a hybrid design with a VPN or an ExpressRoute gateway.

حتى إذا كان جميع العملاء موجودين محلياً أو في Azure، فإن Azure Application Gateway وAzure Firewall كلاهما بحاجة إلى عناوين IP عامة. تسمح عناوين IP العامة لشركة Microsoft بإدارة الخدمات.

تخطيط الشبكة المحورية

لا تزال التصاميم الواردة في هذه المقالة تنطبق في طوبولوجيا النظام المحوري. تتصل الموارد المشتركة في شبكة ظاهرية مركزية بالتطبيقات في شبكات ظاهرية منفصلة محورية من خلال نظيرات الشبكة الظاهرية.

بناء الأنظمة

Diagram that shows a hybrid design with VPN/ER Gateway and a hub-and-spoke topology.

الاعتبارات

تتضمن بعض الاعتبارات لهذه الطوبولوجيا ما يلي:

  • يتم نشر Azure Firewall في الشبكة الظاهرية المركزية. يوضح الرسم التخطيطي أعلاه ممارسة نشر بوابة التطبيق في المركز. غالباً ما تدير فرق التطبيقات مكونات مثل Azure Application Gateways أو بوابات APIM، على الرغم من ذلك. في هذه الحالة، يتم نشر هذه المكونات في الشبكات الظاهرية المحورية.
  • انتبه بشكل خاص إلى المسارات المحددة من قبل المستخدم في الشبكات المحورية: عندما يتلقى خادم التطبيق في محور نسبة استخدام الشبكة من مثيل Azure Firewall محدد، مثل العنوان 192.168.100.7 في الأمثلة السابقة، يجب إرسال نسبة استخدام الشبكة المعادة إلى نفس المثيل. في حال ضبط مسار محدد من قبل المستخدم في المحور الوثبة التالية لنسبة استخدام الشبكة الموجهة إلى المركز إلى عنوان IP لـ Azure Firewall (192.168.100.4 في الرسومات التخطيطية أعلاه)، فقد ينتهي الأمر بحزم بيانات الإرجاع على مثيل Azure Firewall مختلف، مما يتسبب في توجيه غير متماثل. تأكد من أنه إذا كان لديك مسارات محددة من قبل مستخدم في الشبكات الظاهرية المحورية لإرسال نسبة استخدام الشبكة إلى الخدمات المشتركة في المركز من خلال Azure Firewall، فإن هذه المسارات المحددة من قبل مستخدم لا تتضمن بادئة الشبكة الفرعية لـ Azure Firewall.
  • تنطبق التوصية السابقة بالتساوي على الشبكة الفرعية لـ Application Gateway وأي أجهزة ظاهرية للشبكة أخرى أو وكلاء عكسيين قد يتم توزيعهم في الشبكة الظاهرية المركزية.
  • لا يمكنك تعيين الوثبة التالية لـ Application Gateway أو الشبكات الفرعية لـ Azure Firewall من خلال مسارات ثابتة بنوع وثبة تالية من Virtual Network. نوع الوثبة التالية هذا صالح فقط في الشبكة الظاهرية المحلية وليس عبر نظيرات الشبكة الظاهرية. لمزيد من المعلومات عن المسارات المحددة من قبل المستخدم والتوجيه الإجباري لأسفل، راجع توجيه نسبة استخدام شبكة Azure الظاهرية.

التوجيه غير المتماثل

يوضح الرسم التخطيطي أدناه كيفية إرسال نسبة استخدام شبكة SNATted مرة أخرى إلى ALB لـ Azure Firewall. يؤدي هذا الإعداد إلى توجيه غير متماثل:

Diagram that shows an asymmetric routing in a hub-and-spoke topology.

لحل هذه المشكلة، حدد المسارات المحددة من قبل مستخدم في المحور بدون الشبكة الفرعية لـ Azure Firewall ولكن مع الشبكات الفرعية فقط حيث توجد الخدمات المشتركة. في المثال، يجب أن يحتوي المسار المحدد من قبل مستخدم الصحيح في المحور فقط على 192.168.1.0/24. لا ينبغي أن يحتوي على 192.168.0.0/16 بالكامل، كما هو محدد باللون الأحمر.

الدمج مع منتجات Azure الأخرى

يمكنك دمج Azure Firewall وAzure Application Gateway مع منتجات وخدمات Azure الأخرى.

بوابة APIM

دمج خدمات الوكيل العكسي مثل بوابة APIM في التصميمات السابقة لتوفير وظائف مثل تقييد واجهة برمجة التطبيقات أو وكيل المصادقة. لا يؤدي دمج بوابة APIM إلى تغيير التصميمات بشكل كبير. الفرق الرئيسي هو أنه بدلاً من الوكيل العكسي لـ Application Gateway الواحدة، هناك وكيلان عكسيان متسلسلان خلف بعضهما البعض.

لمزيد من المعلومات، راجع دليل التصميم لدمج إدارة واجهة برمجة التطبيقات وApplication Gateway في شبكة ظاهرية ونمط التطبيق بوابات واجهة برمجة التطبيقات لخدمات Micro.

Azure Kubernetes Service

بالنسبة لأحمال العمل التي تعمل على نظام مجموعة AKS، يمكنك نشر Azure Application Gateway بشكل مستقل عن نظام المجموعة. أو يمكنك دمجه مع نظام مجموعة AKS باستخدام وحدة تحكم دخول Azure Application Gateway. عند تكوين عناصر معينة على مستويات Kubernetes (مثل الخدمات والدخول)، تتكيف Application Gateway تلقائياً دون الحاجة إلى خطوات يدوية إضافية.

يلعب Azure Firewall دوراً مهماً في أمان نظام مجموعة AKS. يوفر الوظيفة المطلوبة لتصفية حركة الخروج من نظام مجموعة AKS استناداً إلى FQDN، وليس فقط عنوان IP. لمزيد من المعلومات، راجع التحكم في نسبة استخدام شبكة الخروج لنظم مجموعات العُقد في AKS.

عند دمج Application Gateway وAzure Firewall لحماية نظام مجموعة AKS، من الأفضل استخدام خيار التصميم المتوازي. تعالج Application Gateway مع WAF طلبات الاتصال الواردة إلى تطبيقات الويب في نظام المجموعة. يسمح Azure Firewall بالاتصالات الصادرة المسموح بها بشكل صريح فقط. راجع البنية الأساسية لنظام مجموعة خدمة Azure Kubernetes (AKS) للحصول على مثال لخيار التصميم المتوازي.

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

تتداخل وظيفة Azure Front Door جزئياً مع Azure Application Gateway. على سبيل المثال، توفر كلتا الخدمتين جدار حماية تطبيق الويب، وتفريغ SSL، والتوجيه المستند إلى عنوان URL. يتمثل أحد الاختلافات الرئيسية في أنه في حين أن Azure Application Gateway داخل شبكة ظاهرية، فإن Azure Front Door هي خدمة عالمية لا مركزية.

يمكنك أحياناً تبسيط تصميم الشبكة الظاهرية عن طريق استبدال Application Gateway بـ Azure Front Door اللامركزي. تظل معظم التصميمات الموضحة هنا صالحة، باستثناء خيار وضع Azure Firewall أمام Azure Front Door.

يعد استخدام Azure Firewall أمام Application Gateway في شبكتك الظاهرية حالة استخدام مثيرة للاهتمام. كما هو موضح سابقاً، X-Forwarded-For سيحتوي العنوان الذي تم إدخاله بواسطة Application Gateway على عنوان IP لمثيل جدار الحماية، وليس عنوان IP الخاص بالعميل. الحل البديل هو استخدام Azure Front Door أمام جدار الحماية لإدخال عنوان IP الخاص بالعميل كعنوان X-Forwarded-For قبل دخول نسبة استخدام الشبكة إلى الشبكة الظاهرية والضغط على Azure Firewall. الخيار الثاني هو تأمين الأصل الخاص بك باستخدام Private Link في Azure Front Door Premium.

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

الأجهزة الظاهرية للشبكة الأخرى

منتجات Microsoft ليست الخيار الوحيد لتنفيذ جدار حماية تطبيق الويب أو وظائف جدار الحماية من الجيل التالي في Azure. توفر مجموعة واسعة من شركاء Microsoft الأجهزة الظاهرية للشبكة (NVAs). تعتبر المفاهيم والتصميمات في الأساس نفسها كما هو الحال في هذه المقالة، ولكن هناك بعض الاعتبارات الهامة:

  • قد توفر الأجهزة الظاهرية للشبكة الشريكة لجدار الحماية من الجيل التالي مزيداً من التحكم والمرونة لتكوينات NAT غير المدعومة من Azure Firewall. ومن الأمثلة على ذلك DNAT من الموقع المحلي أو DNAT من الإنترنت دون SNAT.
  • تقلل الأجهزة الظاهرية للشبكة المدارة من Azure (مثل Application Gateway وAzure Firewall) من التعقيد، مقارنة ب الأجهزة الظاهرية للشبكة حيث يحتاج المستخدمون إلى التعامل مع قابلية التوسع والمرونة عبر العديد من الأجهزة.
  • عند استخدام الأجهزة الظاهرية للشبكة في Azure، استخدم الإعدادات النشطة نشطة والتحجيم التلقائي، لذلك هذه الأجهزة لا تعد ازدحاماً للتطبيقات التي تعمل في الشبكة الظاهرية.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

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

تعرف على المزيد حول تقنيات المكونات:

استكشاف البنى ذات الصلة: