تحرير

شبكة صفر ثقة لتطبيقات الويب مع Azure Firewall و Application Gateway

Azure Application Gateway
Azure Firewall
Azure Virtual Network
Azure Virtual WAN
Azure Web Application Firewall

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

عادةً ما تقوم أنواع مختلفة من أجهزة الشبكة بفحص الجوانب المختلفة لحزم الشبكة:

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

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

رسم تخطيطي للبنية يوضح تدفق الحزمة في شبكة تطبيق ويب تستخدم Application Gateway أمام Azure Firewall Premium.

قم بتنزيل ملف Visio لهذه البنية.

تستخدم هذه البنية بروتوكول أمان طبقة النقل (TLS) لتشفير نسبة استخدام الشبكة في كل خطوة.

  • يرسل العميل حزماً إلى بوابة Application Gateway، وهو موازن تحميل. يتم تشغيله مع الإضافة الاختيارية جدار حماية تطبيق الويب Azure .

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

  • يقوم Azure Firewall Premium بإجراء فحوصات الأمان:

  • إذا اجتازت حزم البيانات الاختبارات، فإن Azure Firewall Premium يتخذ الخطوات التالية:

    • تشفير حزم البيانات
    • يستخدم خدمة نظام أسماء المجالات (DNS) لتحديد الجهاز الظاهري للتطبيق (VM)
    • إعادة توجيه حزم البيانات إلى التطبيق VM

تضمن محركات الفحص المختلفة في هذه البنية سلامة نسبة استخدام الشبكة:

  • يستخدم جدار حماية تطبيق الويب قواعد لمنع الهجمات على طبقة الويب. تتضمن أمثلة الهجمات إدخال كود SQL والبرمجة عبر المواقع. لمزيد من المعلومات بشأن القواعد ومجموعة القواعد الأساسية لمشروع أمان تطبيق الويب المفتوح (OWASP)، راجع مجموعات وقواعد CRS لجدار حماية تطبيق الويب.
  • يستخدم Azure Firewall Premium قواعد عامة للكشف عن التسلل والوقاية منه. تساعد هذه القواعد في تحديد الملفات الضارة والتهديدات الأخرى التي تستهدف تطبيقات الويب.

تدعم هذه البنية أنواعاً مختلفة من تصميمات الشبكة، والتي تناقشها هذه المقالة:

  • المركز التقليدي والشبكات الناطقة
  • الشبكات التي تستخدم Azure Virtual WAN كنظام أساسي
  • الشبكات التي تستخدم Azure Route Server لتبسيط التوجيه الديناميكي

Azure Firewall Premium وتحليل الاسم

عند التحقق من نسبة استخدام الشبكة الضارة، يتحقق Azure Firewall Premium من أن رأس HTTP Host يطابق عنوان IP للحزمة ومنفذ TCP. على سبيل المثال، افترض أن بوابة Application Gateway ترسل حزم الويب إلى عنوان IP 172.16.1.4 ومنفذ TCP 443. يجب أن يتم تحليل عنوان المضيف HTTP Host لعنوان IP هذا.

لا تحتوي عناوين المضيف HTTP عادةً على عناوين IP. بدلاً من ذلك، تحتوي العناوين على أسماء تطابق الشهادة الرقمية للخادم. في هذه الحالة، يستخدم Azure Firewall Premium DNS لتحليل اسم عنوان المضيف إلى عنوان IP. يحدد تصميم الشبكة أي حل DNS يعمل بشكل أفضل، كما هو موضح في الأقسام اللاحقة.

إشعار

لا يدعم بوابة Application Gateway أرقام المنافذ في عناوين المضيف HTTP Host. ونتيجة لذلك:

  • يفترض Azure Firewall Premium وجود منفذ HTTPS TCP افتراضي من 443.
  • الاتصال بين بوابة Application Gateway وخادم الويب يدعم فقط منفذ TCP 443، وليس المنافذ غير القياسية.

شهادات رقمية

يوضح الرسم التخطيطي التالي الأسماء الشائعة (CNs) والمراجع المصدقة (CAs) التي تستخدمها جلسات TLS والشهادات الخاصة بالبنية:

رسم تخطيطي للبنية يوضح الأسماء الشائعة وسلطات الشهادات التي تستخدمها شبكة تطبيق الويب عندما يكون موازن التحميل أمام جدار حماية.

اتصالات TLS

تحتوي هذه البنية على ثلاثة اتصالات TLS مميزة. الشهادات الرقمية تتحقق من صحة كل منها:

من العملاء إلى بوابة التطبيقات

في بوابة Application Gateway، تقوم بتوزيع الشهادة الرقمية التي يراها العملاء. عادةً ما يصدر المرجع المصدق المعروف مثل DigiCert أو Let's Encrypt مثل هذه الشهادة.

من بوابة التطبيق إلى Azure Firewall Premium

لفك تشفير حركة مرور TLS وفحصها، يقوم Azure Firewall Premium بإنشاء الشهادات ديناميكياً. يقدم Azure Firewall Premium نفسه أيضاً إلى بوابة Application Gateway باعتباره خادم الويب. يوقع المرجع المصدق الخاص الشهادات التي ينشئها Azure Firewall Premium. لمزيد من المعلومات، راجع شهادات Azure Firewall Premium . بوابة التطبيق تحتاج إلى التحقق من صحة هذه الشهادات. في إعدادات HTTP للتطبيق، يمكنك تكوين المرجع المصدق الجذر الذي يستخدمه Azure Firewall Premium.

من Azure Firewall Premium إلى خادم الويب

ينشئ Azure Firewall Premium جلسة TLS مع خادم الويب الوجهة. يتحقق Azure Firewall Premium من قيام مرجع مصدق معروف بتوقيع حزم بيانات TLS لخادم الويب.

أدوار المكون

تتعامل بوابة Application Gateway وAzure Firewall Premium مع الشهادات بشكل مختلف عن بعضها البعض لأن أدوارهما تختلف:

  • بوابة Application Gateway هو وكيل ويب عكسي . يحمي خوادم الويب من العملاء الضارين عن طريق اعتراض طلبات HTTP وHTTPS. أنت تعلن عن كل خادم محمي موجود في التجمع الخلفي لبوابة التطبيق بعنوان IP الخاص به أو اسم المجال المؤهل بالكامل. يجب أن يكون العملاء الشرعيون قادرين على الوصول إلى كل تطبيق. لذلك تقوم بتكوين بوابة Application Gateway بشهادة رقمية تم توقيعها بواسطة مرجع مصدق عام. استخدم مرجع مصدق يقبله أي عميل TLS.
  • Azure Firewall Premium هو وكيل ويب لإعادة التوجيه أو ببساطة وكيل ويب. إنه يحمي العملاء من خوادم الويب الضارة عن طريق اعتراض مكالمات TLS من العملاء المحميون. عندما يقوم عميل محمي بتقديم طلب HTTP، ينتحل وكيل التوجيه صفة خادم الويب الهدف عن طريق إنشاء شهادات رقمية وتقديمها إلى العميل. يستخدم Azure Firewall Premium مرجع مصدق خاص يوقع الشهادات التي تم إنشاؤها ديناميكياً. يمكنك تكوين العملاء المحميين للثقة في ذلك المرجع المصدق الخاص. في هذه البنية، يحمي Azure Firewall Premium الطلبات من بوابة Application Gateway إلى خادم الويب. تثق بوابة التطبيق في المرجع المصدق الخاص الذي يستخدمه Azure Firewall Premium.

التوجيه وإعادة توجيه حركة المرور

سيكون التوجيه مختلفا قليلا اعتمادا على طوبولوجيا تصميم الشبكة الخاصة بك، ستفصل الأقسام التالية تفاصيل أمثلة طبولوجيا Hub و Spoke و Virtual WAN و Route Server. ومع ذلك، هناك بعض الجوانب الشائعة في جميع الطوبولوجيا:

  • تتصرف Azure Application Gateway دائما كوكيل، كما أن Azure Firewall Premium يعمل أيضا عند تكوينه لفحص TLS: سيتم إنهاء جلسات TLS من العملاء بواسطة Application Gateway، وسيتم إنشاء جلسات TLS جديدة نحو Azure Firewall. سيتلقى Azure Firewall جلسات TLS المصدر من بوابة التطبيق وينهيها، وسينشئ جلسات TLS جديدة تجاه أحمال العمل. هذه الحقيقة لها آثار على تكوين IDPS من Azure Firewall Premium، تحتوي الأقسام أدناه على مزيد من التفاصيل حول هذا.
  • سيرى حمل العمل الاتصالات القادمة من عنوان IP للشبكة الفرعية لجدار حماية Azure. يتم الاحتفاظ بعنوان IP الخاص بالعميل الأصلي في X-Forwarded-For رأس HTTP الذي تم إدراجه بواسطة بوابة التطبيق.
  • عادة ما يتم إرسال حركة المرور من بوابة التطبيق إلى حمل العمل إلى جدار حماية Azure باستخدام آليات توجيه Azure، إما مع المسارات المعرفة من قبل المستخدم المكونة في الشبكة الفرعية لبوابة التطبيق أو مع المسارات التي تم حقنها بواسطة Azure Virtual WAN أو Azure Route Server. على الرغم من أن تحديد عنوان IP الخاص بجدار حماية Azure بشكل صريح في تجمع الواجهة الخلفية لبوابة التطبيق ممكن، إلا أنه من غير المستحسن تقنيا لأنه يأخذ بعض وظائف جدار حماية Azure مثل موازنة التحميل والثبات.

تدخل الأقسام التالية في التفاصيل لبعض المخططات الأكثر شيوعا المستخدمة مع Azure Firewall وApplication Gateway.

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

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

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

من خلال المركز التقليدي للمحور والتحدث، توفر المناطق الخاصة لنظام أسماء النطاقات طريقة سهلة لاستخدام DNS:

  • تكوين منطقة DNS الخاصة.
  • اربط المنطقة بالشبكة الظاهرية التي تحتوي على Azure Firewall Premium.
  • تأكد من وجود سجل A للقيمة التي يستخدمها بوابة Application Gateway لنسبة استخدام الشبكة وللفحوصات الصحية.

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

رسم تخطيطي للبنية يوضح تدفق الحزمة في مركز وشبكة محورية مع موازن تحميل وجدار حماية. يتصل العملاء من الإنترنت العام.

  1. يرسل العميل طلباً إلى خادم الويب.
  2. تعترض بوابة التطبيق حزم بيانات العميل وتفحصها. إذا اجتاز الفحص حزم البيانات، فإن بوابة Application Gateway سترسل الحزمة إلى الواجهة الخلفية VM. عندما تصل حزمة بيانات إلى Azure، يقوم المسار المحدد من قبل المستخدم (UDR) في الشبكة الفرعية لبوابة التطبيق بإعادة توجيه الحزم إلى Azure Firewall Premium.
  3. يقوم Azure Firewall Premium بإجراء فحوصات أمان على حزم البيانات. إذا اجتازوا الاختبارات، يقوم Azure Firewall Premium بإعادة توجيه حزم البيانات إلى التطبيق VM.
  4. يستجيب الجهاز الظاهري ويضبط عنوان IP الوجهة لبوابة التطبيق. يقوم UDR في شبكة VM الفرعية بإعادة توجيه حزم البيانات إلى Azure Firewall Premium.
  5. يقوم Azure Firewall Premium بإعادة توجيه حزم البيانات إلى بوابة Application Gateway.
  6. تجيب بوابة Application Gateway على العميل.

يمكن أن تصل نسبة استخدام الشبكة أيضاً من شبكة محلية بدلاً من الإنترنت العام. تتدفق نسبة استخدام الشبكة إما من خلال شبكة ظاهرية خاصة (VPN) من موقع إلى موقع أو عبر ExpressRoute. في هذا السيناريو، تصل نسبة استخدام الشبكة أولاً إلى بوابة الشبكة الظاهرية في المركز. باقي تدفق الشبكة هو نفس الحالة السابقة.

رسم تخطيطي للبنية يوضح تدفق الحزمة في مركز وشبكة محورية مع موازن تحميل وجدار حماية. يتصل العملاء من شبكة محلية.

  1. يتصل العميل المحلي ببوابة الشبكة الظاهرية.
  2. تقوم البوابة بإعادة توجيه حزم بيانات العميل إلى Application Gateway.
  3. تفحص Application Gateway حزم البيانات. إذا اجتازوا الفحص، فإن UDR في الشبكة الفرعية لبوابة Application Gateway يعيد توجيه حزم البيانات إلى Azure Firewall Premium.
  4. يقوم Azure Firewall Premium بإجراء فحوصات أمان على حزم البيانات. إذا اجتازوا الاختبارات، يقوم Azure Firewall Premium بإعادة توجيه حزم البيانات إلى التطبيق VM.
  5. يستجيب الجهاز الظاهري ويضبط عنوان IP الوجهة لبوابة التطبيق Application Gateway. يقوم UDR في شبكة VM الفرعية بإعادة توجيه حزم البيانات إلى Azure Firewall Premium.
  6. يقوم Azure Firewall Premium بإعادة توجيه حزم البيانات إلى بوابة Application Gateway.
  7. يرسل Application Gateway حزم البيانات إلى بوابة الشبكة الظاهرية.
  8. البوابة تجيب على العميل.

مخطط شبكة WAN الظاهرية

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

عند استخدام Virtual WAN كنظام أساسي للشبكات، ينتج عن ذلك اختلافان رئيسيان:

  • لا يمكنك ربط مناطق DNS الخاصة بمحور افتراضي لأن Microsoft تدير المراكز الظاهرية. بصفتك مالك الاشتراك، ليس لديك أذونات لربط مناطق DNS الخاصة. نتيجة لذلك، لا يمكنك إقران منطقة DNS الخاصة بالمركز الآمن الذي يحتوي على Azure Firewall Premium. لتنفيذ حل DNS لـ Azure Firewall Premium، استخدم خوادم DNS بدلاً من ذلك:

    • قم بتكوين Azure Firewall DNS Settings لاستخدام خوادم DNS المخصصة.
    • قم بتوزيع الخوادم في شبكة ظاهرية للخدمات المشتركة تقوم بتوصيلها بشبكة WAN الظاهرية.
    • ربط منطقة DNS الخاصة بالشبكة الظاهرية للخدمات المشتركة. يمكن لخوادم DNS بعد ذلك حل الأسماء التي تستخدمها بوابة Application Gateway في عناوينHTTP Host. لمزيد من المعلومات، راجع Azure Firewall DNS Settings.

  • يمكنك فقط استخدام Virtual WAN لبرمجة المسارات في محور إذا كانت البادئة أقصر (أقل تحديداً) من بادئة الشبكة الظاهرية. على سبيل المثال، في المخططات أعلاه، تحتوي VNet المتكلمة على البادئة 172.16.0.0/16: في هذه الحالة، لن تتمكن WAN الظاهرية من إدخال مسار يطابق بادئة VNet (172.16.0.0/16) أو أي من الشبكات الفرعية (172.16.0.0/24، 172.16.1.0/24). بمعنى آخر، لا يمكن لـ Virtual WAN جذب نسبة استخدام الشبكة بين شبكتين فرعيتين في نفس شبكة VNet. يصبح هذا القيد واضحا عندما تكون بوابة التطبيق وخادم الويب الوجهة في نفس الشبكة الظاهرية: لا يمكن ل Virtual WAN فرض حركة المرور بين Application Gateway وخادم الويب للانتقال عبر Azure Firewall Premium (سيكون الحل البديل هو تكوين المسارات المعرفة من قبل المستخدم يدويا في الشبكات الفرعية لبوابة التطبيق وخادم الويب).

يوضح الرسم البياني التالي تدفق حزمة البيانات في حال استخدام شبكة WAN الظاهرية. في هذه الحالة، يكون الوصول إلى بوابة Application Gateway من شبكة محلية. تقوم شبكة VPN من موقع إلى موقع أو ExpressRoute بتوصيل تلك الشبكة بـ Virtual WAN. الوصول من إنترنت مشابه.

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

  1. يتصل العميل المحلي بشبكة VPN.
  2. تقوم VPN بإعادة توجيه حزم بيانات العميل إلى بوابة Application Gateway.
  3. تفحص Application Gateway حزم البيانات. إذا اجتازوا الفحص، تقوم بوابة الشبكة الفرعية Application Gateway بإعادة توجيه حزم البيانات إلى Azure Firewall Premium.
  4. يطلب Azure Firewall Premium حل DNS من خادم DNS في الشبكة الظاهرية للخدمات المشتركة.
  5. يجيب خادم DNS على طلب الحل.
  6. يقوم Azure Firewall Premium بإجراء فحوصات أمان على حزم البيانات. إذا اجتازوا الاختبارات، يقوم Azure Firewall Premium بإعادة توجيه حزم البيانات إلى التطبيق VM.
  7. يستجيب الجهاز الظاهري ويضبط عنوان IP الوجهة لبوابة التطبيق Application Gateway. تعيد الشبكة الفرعية للتطبيق توجيه الحزم إلى Azure Firewall Premium.
  8. يقوم Azure Firewall Premium بإعادة توجيه حزم البيانات إلى بوابة Application Gateway.
  9. ترسل بوابة Application Gateway حزم البيانات إلى VPN.
  10. تجيب VPN على العميل.

باستخدام هذا التصميم، قد تحتاج إلى تعديل التوجيه الذي يعلن عنه المحور للشبكات الظاهرية المتكلمة. على وجه التحديد، لا تدعم بوابة Application Gateway v2 سوى مسار 0.0.0.0/0 يشير إلى الإنترنت. المسارات التي تحتوي على هذا العنوان والتي لا تشير إلى الإنترنت تقطع الاتصال الذي تطلبه Microsoft لإدارة Application Gateway. إذا كان الموزع الافتراضي يعلن عن مسار 0.0.0.0/0، فامنع هذا المسار من الانتشار إلى الشبكة الفرعية لـ Application Gateway باتباع إحدى الخطوات التالية:

  • قم بإنشاء جدول توجيه بمسار 0.0.0.0/0 ونوع القفزة التالية من Internet. قم بإقران هذا المسار بالشبكة الفرعية التي توزع فيها بوابة Application Gateway.
  • إذا قمت بتوزيع بوابة Application Gateway في محور مخصص، فقم بتعطيل انتشار المسار الافتراضي في إعدادات اتصال الشبكة الظاهرية.

مخطط خادم التوجيه

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

  • باستخدام خادم الطريق، يدير العملاء الشبكات الظاهرية المحورية. نتيجة لذلك، يمكنك ربط الشبكة الظاهرية للمحور بمنطقة DNS الخاصة.
  • يحتوي خادم المسار على نفس القيود التي تفرضها شبكة WAN الظاهرية فيما يتعلق ببادئات عنوان IP. يمكنك فقط إدخال المسارات في المحور إذا كانت البادئة أقصر (أقل تحديداً) من بادئة الشبكة الظاهرية. بسبب هذا القيد، يجب أن تكون بوابة التطبيق وخادم الويب الوجهة في شبكات ظاهرية مختلفة.

يوضح الرسم التخطيطي التالي تدفق الحزمة عندما يبسط Route Server التوجيه الديناميكي. لاحظ هذه النقاط:

  • يتطلب خادم الطريق حالياً الجهاز الذي يقوم بحقن المسارات لإرسالها عبر بروتوكول بوابة الحدود (BGP). نظراً لأن Azure Firewall Premium لا يدعم BGP، استخدم جهازاً ظاهرياً للشبكة (NVA) تابعاً لجهة خارجية بدلاً من ذلك.
  • تحدد وظيفة NVA في المركز ما إذا كان التنفيذ يحتاج إلى DNS.

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

  1. يتصل العميل المحلي ببوابة الشبكة الظاهرية.
  2. تقوم البوابة بإعادة توجيه حزم بيانات العميل إلى Application Gateway.
  3. تفحص Application Gateway حزم البيانات. إذا اجتازوا الاستقصاء، تقوم بوابة الشبكة الفرعية Application Gateway بإعادة توجيه حزم البيانات إلى جهاز الواجهة الخلفية. المسار في الشبكة الفرعية ApplicationGateway التي يتم حقنها بواسطة خادم المسار قد يعيد توجيه نسبة استخدام الشبكة إلى NVA.
  4. تقوم NVA بإجراء فحوصات أمنية على حزم البيانات. إذا اجتازوا الاختبارات، فإن NVA يعيد توجيه حزم البيانات إلى التطبيق VM.
  5. يستجيب الجهاز الظاهري ويضبط عنوان IP الوجهة لبوابة التطبيق Application Gateway. المسار الذي تم حقنه في الشبكة الفرعية لـ VM بواسطة خادم الطريق يعيد توجيه حزم البيانات إلى NVA.
  6. تقوم NVA بإعادة توجيه حزم البيانات إلى بوابة التطبيق.
  7. يرسل Application Gateway حزم البيانات إلى بوابة الشبكة الظاهرية.
  8. البوابة تجيب على العميل.

كما هو الحال مع Virtual WAN، قد تحتاج إلى تعديل التوجيه عند استخدام Route Server. إذا قمت بالإعلان عن المسار 0.0.0.0/0، فقد ينتشر إلى بوابة الشبكة الفرعية Application Gateway. لكن بوابة Application Gateway لا تدعم هذا الطريق. في هذه الحالة، قم بتكوين جدول توجيه لبوابة الشبكة الفرعية Application Gateway. قم بتضمين مسار لـ 0.0.0.0/0 ونوع الوثبة التالية من Internet في هذا الجدول.

IDPS وعناوين IP الخاصة

كما هو موضح في قواعد IDPS لجدار حماية Azure، سيقرر Azure Firewall Premium قواعد IDPS التي يجب تطبيقها اعتمادا على عناوين IP المصدر والوجهة للحزم. سيعامل Azure Firewall لكل عناوين IP خاصة افتراضية في نطاقات RFC 1918 (10.0.0.0/8192.168.0.0/16و172.16.0.0/12) ونطاق RFC 6598 (100.64.0.0/10) على أنها داخلية. وبالتالي، إذا تم نشر Application Gateway في شبكة فرعية في أحد هذه النطاقات (172.16.0.0/24 في الأمثلة أعلاه)، فسينظر Azure Firewall Premium في نسبة استخدام الشبكة بين بوابة التطبيق وعبء العمل لتكون داخلية، وسيتم استخدام تواقيع IDPS التي تم وضع علامة عليها ليتم تطبيقها على حركة المرور الداخلية أو على أي حركة مرور فقط. لن يتم تطبيق توقيعات IDPS التي تم وضع علامة عليها ليتم تطبيقها على حركة المرور الواردة أو الصادرة على حركة المرور بين بوابة التطبيق وعبء العمل.

أسهل طريقة لفرض تطبيق قواعد توقيع IDPS الواردة على حركة المرور بين بوابة التطبيق وحمل العمل هي عن طريق وضع بوابة التطبيق في شبكة فرعية مع بادئة خارج النطاقات الخاصة. لا تحتاج بالضرورة إلى استخدام عناوين IP العامة لهذه الشبكة الفرعية، ولكن بدلا من ذلك يمكنك تخصيص عناوين IP التي يتعامل معها Azure Firewall Premium على أنها داخلية ل IDPS. على سبيل المثال، إذا لم تستخدم 100.64.0.0/10 مؤسستك النطاق، يمكنك إزالة هذا النطاق من قائمة البادئات الداخلية ل IDPS (راجع نطاقات IPDS الخاصة ل Azure Firewall Premium للحصول على مزيد من التفاصيل حول كيفية القيام بذلك) ونشر Application Gateway في شبكة فرعية تم تكوينها باستخدام عنوان IP في 100.64.0.0/10.

المساهمون

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

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

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