الأسئلة المتداولة حول جدار حماية Azure

شائع

ما هو Azure Firewall؟

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

ما القدرات التي يدعمها Azure Firewall؟

للحصول على قائمة مفصلة بميزات Azure Firewall، راجع ميزات Azure Firewall.

ما هو نموذج النشر النموذجي لجدار حماية Azure Firewall؟

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

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

كيف يمكنني نشر Azure Firewall؟

يمكن نشر Azure Firewall باستخدام مدخل Microsoft Azure أو PowerShell أو REST API أو القوالب. للحصول على إرشادات خطوة بخطوة، راجع البرنامج التعليمي: نشر وتكوين جدار حماية Azure باستخدام مدخل Microsoft Azure.

ما هي بعض المفاهيم الرئيسية لجدار حماية Azure؟

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

هناك ثلاثة أنواع من مجموعات القواعد:

• قواعد التطبيق: تكوين أسماء المجالات المؤهلة بالكامل (FQDNs) التي يمكن الوصول إليها من شبكة ظاهرية.
• قواعد الشبكة: تكوين القواعد باستخدام عناوين المصدر والبروتوكولات ومنافذ الوجهة وعناوين الوجهة.
• قواعد NAT: تكوين قواعد DNAT للسماح باتصالات الإنترنت أو الإنترانت الواردة (معاينة).

لمزيد من المعلومات، راجع تكوين قواعد جدار حماية Azure.

ما هي خدمات التسجيل والتحليلات التي يدعمها Azure Firewall؟

يتكامل جدار حماية Azure مع Azure Monitor لعرض السجلات وتحليلها. يمكن إرسال السجلات إلى Log Analytics أو Azure Storage أو مراكز الأحداث وتحليلها باستخدام أدوات مثل Log Analytics أو Excel أو Power BI. لمزيد من المعلومات، راجع البرنامج التعليمي: مراقبة سجلات جدار حماية Azure Firewall.

كيف يختلف جدار حماية Azure عن NVAs في السوق؟

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

ما هو الفرق بين Application Gateway WAF وجدار الحماية Azure Firewall؟

يوفر Application Gateway WAF حماية واردة مركزية لتطبيقات الويب ضد الاستغلالات والثغرات الأمنية الشائعة. يوفر جدار حماية Azure Firewall حماية واردة للبروتوكولات غير HTTP/S (على سبيل المثال، RDP وSSH و FTP) وحماية صادرة على مستوى الشبكة لكافة المنافذ والبروتوكولات والحماية على مستوى التطبيق لـ HTTP/S الصادرة.

ما هو الفرق بين مجموعات أمان الشبكة (NSGs) وجدار حماية Azure Firewall؟

يكمل جدار حماية Azure NSGs لتوفير أمان أفضل للشبكة "الدفاعية المتعمقة". تقدم مجموعات أمان الشبكة تصفية حركة مرور طبقة الشبكة الموزعة للحد من نسبة استخدام الشبكة داخل الشبكات الظاهرية في كل اشتراك. يوفر Azure Firewall شبكة مركزية وكاملة الحالة وحماية على مستوى التطبيق عبر الاشتراكات والشبكات الظاهرية.

هل مجموعات أمان الشبكة (NSGs) معتمدة على AzureFirewallSubnet؟

Azure Firewall هي خدمة مدارة مع طبقات حماية متعددة، بما في ذلك حماية النظام الأساسي باستخدام مجموعات أمان الشبكة على مستوى NIC (غير قابلة للعرض). NSGs على مستوى الشبكة الفرعية غير مطلوبة على AzureFirewallSubnet ويتم تعطيلها لمنع انقطاع الخدمة.

ما هي القيمة المضافة لجدار حماية Azure مع نقاط النهاية الخاصة؟

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

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

ما القيمة المضافة لجدار حماية Azure مع نقاط نهاية خدمة الشبكة الظاهرية؟

تعد نقاط نهاية خدمة الشبكة الظاهرية بديلا ل Private Link للتحكم في وصول الشبكة إلى خدمات Azure PaaS. حتى إذا كان العميل لا يزال يستخدم عناوين IP العامة للوصول إلى خدمة PaaS، يتم جعل الشبكة الفرعية المصدر مرئية بحيث يمكن لخدمة PaaS الوجهة تنفيذ قواعد التصفية وتقييد الوصول على أساس كل شبكة فرعية. يمكنك العثور على مقارنة مفصلة بين الآليتين في مقارنة نقاط النهاية الخاصة ونقاط نهاية الخدمة.

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

ما هو تسعير جدار حماية Azure Firewall؟

للحصول على تفاصيل التسعير، راجع تسعير جدار حماية Azure.

ما هي حدود الخدمة المعروفة لجدار حماية Azure؟

للحصول على حدود الخدمة، راجع اشتراك Azure وحدود الخدمة والحصص النسبية والقيود.

أين يقوم جدار حماية Azure Firewall بتخزين بيانات العملاء؟

لا ينقل Azure Firewall بيانات العملاء أو يخزنها خارج المنطقة التي يتم نشرها فيها.

هل Azure Firewall في المراكز الظاهرية الآمنة (vWAN) مدعوم في قطر؟

لا، جدار حماية Azure في المراكز الظاهرية الآمنة (vWAN) غير مدعوم حاليا في قطر.

القدرات والميزات المدعومة

هل يدعم جدار حماية Azure Firewall تصفية حركة المرور الواردة؟

نعم، يدعم جدار حماية Azure تصفية نسبة استخدام الشبكة الواردة والصادرة. عادة ما تستخدم التصفية الواردة للبروتوكولات غير HTTP مثل RDP وSSH وFTP. بالنسبة لحركة مرور HTTP وHTTPS الواردة، ضع في اعتبارك استخدام جدار حماية تطبيق ويب مثل Azure Web Application Firewall (WAF) أو إلغاء تحميل TLS وميزات فحص الحزمة العميقة ل Azure Firewall Premium.

هل يدعم Azure Firewall Basic الاتصال النفقي القسري؟

نعم، يدعم Azure Firewall Basic الاتصال النفقي القسري.

لماذا يبدو أن اختبار اتصال TCP أو أداة مشابهة للاتصال ب FQDN هدف حتى عندما لا تسمح أي قاعدة بنسبة استخدام الشبكة؟

لا يتصل اختبار اتصال TCP فعليا ب FQDN الهدف. يحظر جدار حماية Azure الاتصالات بأي عنوان IP هدف أو FQDN ما لم تسمح به قاعدة بشكل صريح.

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

هل يدعم جدار حماية Azure تناظر BGP؟

لا، لا يدعم جدار حماية Azure في الأصل تناظر BGP. ومع ذلك، تستخدم ميزة مسارات Autolearn SNAT بشكل غير مباشر BGP من خلال Azure Route Server.

الإدارة والتكوين

كيف يمكنني إيقاف جدار حماية Azure Firewall وبدء تشغيله؟

يمكنك استخدام Azure PowerShell لإزالة تخصيص جدار حماية Azure وتخصيصه. تختلف العملية اعتمادا على التكوين.

لجدار حماية بدون Management NIC:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

لجدار حماية باستخدام Management NIC:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

لجدار حماية في مركز ظاهري آمن:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

إشعار

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

كيف يمكنني تكوين مناطق التوفر بعد التوزيع؟

يوصى بتكوين مناطق التوفر أثناء النشر الأولي. ومع ذلك، يمكنك إعادة تكوينها بعد التوزيع إذا:

• يتم نشر جدار الحماية في شبكة ظاهرية (غير مدعوم في المراكز الظاهرية الآمنة).
• تدعم المنطقة مناطق التوفر.
• يتم تكوين جميع عناوين IP العامة المرفقة بنفس المناطق.

لإعادة تكوين مناطق التوفر:

1. إلغاء تخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. تحديث تكوين المنطقة وتخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

هل هناك أي قيود على مجموعة موارد جدار حماية Azure؟

نعم:

• يجب أن يكون جدار حماية Azure والشبكة الظاهرية في نفس مجموعة الموارد.
• يمكن أن يكون عنوان IP العام في مجموعة موارد مختلفة.
• يجب أن تكون جميع الموارد (جدار حماية Azure، والشبكة الظاهرية، وعنوان IP العام) في نفس الاشتراك.

ماذا تعني حالة التوفير **Failed** ؟

تشير حالة التوفير الفاشلة إلى فشل تحديث التكوين على مثيل خلفي واحد أو أكثر. يظل جدار حماية Azure قيد التشغيل، ولكن قد يكون التكوين غير متناسق. أعد محاولة التحديث حتى تتغير حالة التوفير إلى Succeeded.

كيف يعالج جدار حماية Azure Firewall الصيانة المخطط لها والأعطال غير المخطط لها؟

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

هل هناك حد للأحرف المخصصة لاسم جدار حماية؟

نعم، تقتصر أسماء جدار الحماية على 50 حرفا.

لماذا يحتاج جدار حماية Azure Firewall إلى حجم الشبكة الفرعية /26؟

تضمن الشبكة الفرعية /26 عناوين IP كافية للتحجيم حيث يقوم جدار حماية Azure بتوفير مثيلات إضافية للجهاز الظاهري.

هل يحتاج حجم الشبكة الفرعية لجدار الحماية إلى تغيير كحجم الخدمة؟

لا، الشبكة الفرعية /26 كافية لجميع سيناريوهات التحجيم.

كيف يمكنني زيادة معدل نقل جدار الحماية؟

يتوسع جدار حماية Azure تلقائيا استنادا إلى استخدام وحدة المعالجة المركزية ومعدل النقل وعدد الاتصالات. تتراوح سعة معدل النقل من 2.5 إلى 3 جيجابت في الثانية في البداية إلى 30 جيجابت في الثانية (SKU قياسي) أو 100 جيجابت في الثانية (Premium SKU).

هل هناك حدود لعدد عناوين IP المعتمدة من قبل مجموعات IP؟

نعم. للحصول على التفاصيل، راجع حدود الاشتراك والخدمة في Azure والحصص النسبية والقيود.

هل يمكنني نقل مجموعة IP إلى مجموعة موارد أخرى؟

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

ما هي مهلة خمول TCP لجدار حماية Azure Firewall؟

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

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

هل يمكنني نشر جدار حماية Azure Firewall بدون عنوان IP عام؟

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

هل هناك طريقة لنسخ Azure Firewall والنهج احتياطيا تلقائيا؟

نعم. لمزيد من المعلومات، راجع النسخ الاحتياطي لجدار حماية Azure ونهج جدار حماية Azure باستخدام Logic Apps.

الاتصال والتوجيه

كيف يمكنني إعداد جدار حماية Azure Firewall باستخدام نقاط نهاية الخدمة؟

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

هل يمكن لجدار حماية Azure في شبكة ظاهرية مركزية إعادة توجيه حركة مرور الشبكة وتصفيتها بين شبكات ظاهرية متعددة محورية؟

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

هل يمكن لجدار حماية Azure إعادة توجيه حركة مرور الشبكة وتصفيتها بين الشبكات الفرعية في نفس الشبكة الظاهرية أو الشبكات الظاهرية المقترنة؟

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

هل يقوم جدار حماية Azure Firewall بترجمة عنوان شبكة المصدر الخارجي SNAT بين الشبكات الخاصة؟

لا يقوم جدار حماية Azure ب SNAT عندما يكون عنوان IP الوجهة هو نطاق IP خاص لكل IANA RFC 1918 أو IANA RFC 6598 للشبكات الخاصة. إذا كانت مؤسستك تستخدم نطاق عنوان IP عام للشبكات الخاصة، فإن جدار حماية Azure Firewall يقوم بترجمة عنوان شبكة المصدر SNAT لحركة المرور لأحد عناوين IP الخاصة بجدار الحماية في AzureFirewallSubnet. يمكنك تكوين جدار حماية Azure Firewall على عدم ترجمة عنوان شبكة المصدر SNAT لنطاق عنوان IP العام الخاص بك. لمزيد من المعلومات، راجع نطاقات عناوين IP الخاصة بـ Azure Firewall SNAT.

بالإضافة إلى ذلك، حركة المرور التي تتم معالجتها بواسطة قواعد التطبيق هي دائمًا SNAT-ed. إذا كنت تريد مشاهدة عنوان IP المصدر الأصلي في سجلات حركة مرور FQDN يمكنك استخدام قواعد شبكة الاتصال مع FQDN الوجهة.

هل التوجيه/التسلسل القسري لجهاز ظاهري للشبكة مدعوم؟

يتم دعم التوجيه القسري عند إنشاء جدار حماية جديد. لا يمكنك تكوين جدار حماية موجود للتوجيه القسري. لمزيد من المعلومات، راجع توجيه Azure Firewall المفروض.

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

إذا تطلب التكوين الخاص بك توجيهًا قسريًّا إلى شبكة محلية ويمكنك تحديد بادئات IP الهدف لوجهات إنترنت الخاصة بك، يمكنك تكوين هذه النطاقات مع شبكة الاتصال المحلية كالقفزة التالية عبر توجيه محدد من قبل مستخدم على AzureFirewallSubnet. أو يمكنك استخدام BGP لتعريف هذه التوجيهات.

كيف تعمل أحرف البدل في عناوين URL المستهدفة وتستهدف FQDNs في قواعد التطبيق؟

• URL - تعمل العلامات النجمية عند وضعها على الجانب أقصى اليمين أو أقصى اليسار. إذا كانت على اليسار، فلا يمكنها أن تكون جزءًا من FQDN.
• FQDN - تعمل العلامات النجمية عند وضعها على الجانب أقصى اليسار.
• GENERAL - تعني العلامات النجمية على الجانب الأيسر الأكثر حرفيا أي شيء إلى التطابقات اليسرى، ما يعني مطابقة مجالات فرعية متعددة و/أو تباينات اسم المجال غير المرغوب فيها - راجع الأمثلة التالية.

أمثلة:

نوع	‏‏قاعدة	مدعوم؟	أمثلة إيجابية
TargetURL	www.contoso.com	‏‏نعم‬	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	‏‏نعم‬	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	‏‏نعم‬	example.anycontoso.com sub1.example.contoso.com contoso.com تحذير: يسمح هذا الاستخدام لحرف البدل أيضا بتباينات غير المرغوب فيها/الخطرة مثل th3re4lcontoso.com - الاستخدام بحذر.
TargetURL	www.contoso.com/test	‏‏نعم‬	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	‏‏نعم‬	www.contoso.com/test/anything ملاحظة: www.contoso.com/testلا يتطابق (الشرطة المائلة الأخيرة)
TargetURL	www.contoso.*/test/*	لا
TargetURL	www.contoso.com/test?example=1	لا
TargetURL	www.contoso.*	لا
TargetURL	www.*contoso.com	لا
TargetURL	www.contoso.com:8080	لا
TargetURL	*.contoso.*	لا
TargetFQDN	www.contoso.com	‏‏نعم‬	www.contoso.com
TargetFQDN	*.contoso.com	‏‏نعم‬	any.contoso.com ملاحظة: إذا كنت تريد السماح على وجه التحديد contoso.com ، فيجب تضمين contoso.com في القاعدة. وإلا، يتم إسقاط الاتصال بشكل افتراضي لأن الطلب لا يتطابق مع أي قاعدة.
TargetFQDN	*contoso.com	‏‏نعم‬	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	لا
TargetFQDN	*.contoso.*	لا

هل يسمح جدار حماية Azure Firewall بالوصول إلى Active Directory بشكل افتراضي؟

‏‏لا. جدار حماية Azure Firewall يمنع الوصول إلى Active Directory بشكل افتراضي. للسماح بالوصول، قم بتكوين علامة خدمة AzureActiveDirectory. لمزيد من المعلومات، راجع علامات خدمة Azure Firewall.

هل يمكنني استبعاد FQDN أو عنوان IP من التصفية المستندة على التحليل الذكي للمخاطر من Azure Firewall؟

نعم، يمكنك استخدام Azure PowerShell للقيام بذلك:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

لماذا يمكن لـ TCP ping والأدوات المشابهة الاتصال بنجاح بـ FQDN للهدف حتى عندما لا توجد قاعدة في جدار حماية Azure Firewall يسمح بحركة المرور هذه؟

اختبار اتصال TCP لا يؤدي بالفعل إلى الاتصال بـ FQDN الهدف. لا يسمح Azure Firewall بالاتصال بأي عنوان IP/FQDN هدف ما لم تكن هناك قاعدة صريحة تسمح بذلك.

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

هل هناك حدود لعدد عناوين IP المعتمدة من قبل مجموعات IP؟

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

هل يمكنني نقل مجموعة IP إلى مجموعة موارد أخرى؟

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

ما هي مهلة خمول TCP لجدار حماية Azure Firewall؟

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

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

هل يمكنني نشر جدار حماية Azure Firewall بدون عنوان IP عام؟

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

أين يقوم جدار حماية Azure Firewall بتخزين بيانات العملاء؟

لا يقوم Azure Firewall بنقل بيانات العملاء أو تخزينها خارج المنطقة التي يتم نشرها فيها.

هل هناك طريقة لنسخ Azure Firewall والنهج احتياطيا تلقائيا؟

نعم. لمزيد من المعلومات، راجع النسخ الاحتياطي لجدار حماية Azure ونهج جدار حماية Azure باستخدام Logic Apps.

هل Azure Firewall في المراكز الظاهرية الآمنة (vWAN) مدعوم في قطر؟

لا، جدار حماية Azure حاليا في المراكز الظاهرية الآمنة (vWAN) غير مدعوم في قطر.

كم عدد الاتصالات المتوازية التي يمكن أن يدعمها Azure Firewall؟

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

الحد الإجمالي لكل جدار حماية هو حد اتصال الجهاز الظاهري (250 ألف) × عدد الأجهزة الظاهرية في تجمع الواجهة الخلفية لجدار الحماية. يبدأ جدار حماية Azure بجهازين ظاهريين ويتوسع استنادا إلى استخدام وحدة المعالجة المركزية ومعدل النقل.

ما هو سلوك إعادة استخدام منفذ SNAT TCP/UDP في Azure Firewall؟

يستخدم Azure Firewall حاليا منافذ مصدر TCP/UDP لحركة مرور SNAT الصادرة، مع عدم وجود وقت انتظار الخام. عند إغلاق اتصال TCP/UDP، ينظر إلى منفذ TCP المستخدم على الفور على أنه متاح للاتصالات القادمة.

كحل بديل لبنى معينة، يمكنك النشر والتحجيم باستخدام بوابة NAT باستخدام جدار حماية Azure لتوفير مجموعة أوسع من منافذ SNAT للتغير والتوافر.

ما هي سلوكيات NAT في Azure Firewall؟

تعتمد سلوكيات NAT المحددة على تكوين جدار الحماية ونوع NAT الذي تم تكوينه. على سبيل المثال، يحتوي جدار الحماية على قواعد DNAT لنسبة استخدام الشبكة الواردة وقواعد الشبكة وقواعد التطبيق لحركة المرور الصادرة من خلال جدار الحماية.

لمزيد من المعلومات، راجع سلوكيات NAT لجدار حماية Azure.

المهلات والتحجيم

كيف يعمل استنزاف الاتصال؟

لأي عملية صيانة المخطط لها، يقوم منطق استنزاف الاتصال بتحديث العقد الخلفية بأمان. جدار حماية Azure Firewall ينتظر 90 ثانية للاتصالات الموجودة لإغلاق. في أول 45 ثانية، لا تقبل عقدة الواجهة الخلفية اتصالات جديدة، وفي الوقت المتبقي تستجيب مع RST جميع الحزم الواردة. إذا لزم الأمر، يمكن للعملاء تلقائيًّا إعادة تأسيس الاتصال إلى عقدة خلفية أخرى.

كيف يتعامل جدار حماية Azure مع إيقاف تشغيل مثيل الجهاز الظاهري أثناء مقياس مجموعة مقياس الجهاز الظاهري في (تقليص الحجم) أو ترقيات برامج الأسطول؟

قد يحدث إيقاف تشغيل مثيل Azure Firewall VM أثناء مقياس مجموعة مقياس الجهاز الظاهري في (تقليص) أو أثناء ترقية برنامج الأسطول. في هذه الحالات، يتم تحميل الاتصالات الواردة الجديدة متوازنة إلى مثيلات جدار الحماية المتبقية ولا تتم إعادة توجيهها إلى مثيل جدار الحماية لأسفل. بعد 45 ثانية، يبدأ جدار الحماية في رفض الاتصالات الموجودة عن طريق إرسال حزم TCP RST. بعد 45 ثانية أخرى يتم إيقاف تشغيل جدار الحماية VM. لمزيد من المعلومات، راجع إعادة تعيين TCP لموازن التحميل ومهلة الخمول.

كم من الوقت يستغرق جدار حماية Azure Firewall لتوسيع نطاقه؟

يتوسع جدار حماية Azure تدريجيا عندما يكون متوسط معدل النقل أو استهلاك وحدة المعالجة المركزية عند 60٪، أو يكون عدد استخدام الاتصالات 80٪. على سبيل المثال، يبدأ في التوسع عندما يصل إلى 60٪ من الحد الأقصى لمعدل النقل الخاص به. تختلف أرقام معدل النقل القصوى استنادا إلى Azure Firewall SKU والميزات الممكنة. لمزيد من المعلومات، راجع أداء Azure Firewall.

يستغرق التوسع من خمس إلى سبع دقائق. عند اختبار الأداء، تأكد من الاختبار لمدة 10 إلى 15 دقيقة على الأقل، وابدأ اتصالات جديدة للاستفادة من عقد جدار حماية Azure التي تم إنشاؤها حديثا.

كيف يعالج جدار حماية Azure Firewall مهلات الخمول؟

عندما يحتوي الاتصال على مهلة الخمول (أربع دقائق من عدم النشاط)، يقوم جدار حماية Azure بإنهاء الاتصال بأمان عن طريق إرسال حزمة TCP RST.

الصيانة التي يتحكم فيها العميل

ما نوع الصيانة التي يدعمها العملاء؟

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

هل يمكنني الحصول على إعلام متقدم بحدث الصيانة؟

لا تتوفر إعلامات متقدمة لصيانة جدار حماية Azure.

هل يمكنني تكوين نافذة صيانة أقصر من خمس ساعات؟

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

هل يمكنني تكوين نافذة صيانة غير الجدول الزمني اليومي؟

لا، يتم حاليا تكوين نوافذ الصيانة للتكتم يوميا.

هل هناك حالات لا يمكنني فيها التحكم في تحديثات معينة؟

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

هل يجب أن تكون موارد تكوين الصيانة في نفس المنطقة مثل Azure Firewall؟

نعم.

هل يمكننا إنشاء أكثر من تكوين صيانة واحد لجدار حماية Azure واحد؟

‏‏لا. حاليا، يمكن إقران تكوين صيانة واحد فقط بجدار حماية Azure.

ما هي وحدات SKU لجدار حماية Azure التي يمكنني تكوينها لاستخدام الصيانة التي يتحكم فيها العميل؟

تدعم جميع وحدات SKU لجدار حماية Azure - الأساسية والقياسية والمتميزة الصيانة التي يتحكم فيها العميل.

كم من الوقت يستغرق نهج تكوين الصيانة لتصبح فعالة بعد تعيينها إلى جدار حماية Azure؟

قد يستغرق جدار حماية Azure ما يصل إلى 24 ساعة لمتابعة جدول الصيانة بعد إقران نهج الصيانة.

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

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

كيف يمكنني معرفة المزيد حول الصيانة التي يتحكم فيها العميل على جدار حماية Azure؟

لمزيد من المعلومات، راجع تكوين الصيانة التي يتحكم فيها العميل.

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

للحصول على قائمة مفصلة بميزات Azure Firewall، راجع ميزات Azure Firewall.

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

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

يمكن نشر Azure Firewall باستخدام مدخل Microsoft Azure أو PowerShell أو REST API أو القوالب. للحصول على إرشادات خطوة بخطوة، راجع البرنامج التعليمي: نشر وتكوين جدار حماية Azure باستخدام مدخل Microsoft Azure.

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

هناك ثلاثة أنواع من مجموعات القواعد:

• قواعد التطبيق: تكوين أسماء المجالات المؤهلة بالكامل (FQDNs) التي يمكن الوصول إليها من شبكة ظاهرية.
• قواعد الشبكة: تكوين القواعد باستخدام عناوين المصدر والبروتوكولات ومنافذ الوجهة وعناوين الوجهة.
• قواعد NAT: تكوين قواعد DNAT للسماح باتصالات الإنترنت أو الإنترانت الواردة (معاينة).

لمزيد من المعلومات، راجع تكوين قواعد جدار حماية Azure.

يتكامل جدار حماية Azure مع Azure Monitor لعرض السجلات وتحليلها. يمكن إرسال السجلات إلى Log Analytics أو Azure Storage أو مراكز الأحداث وتحليلها باستخدام أدوات مثل Log Analytics أو Excel أو Power BI. لمزيد من المعلومات، راجع البرنامج التعليمي: مراقبة سجلات جدار حماية Azure Firewall.

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

يوفر Application Gateway WAF حماية واردة مركزية لتطبيقات الويب ضد الاستغلالات والثغرات الأمنية الشائعة. يوفر جدار حماية Azure Firewall حماية واردة للبروتوكولات غير HTTP/S (على سبيل المثال، RDP وSSH و FTP) وحماية صادرة على مستوى الشبكة لكافة المنافذ والبروتوكولات والحماية على مستوى التطبيق لـ HTTP/S الصادرة.

يكمل جدار حماية Azure NSGs لتوفير أمان أفضل للشبكة "الدفاعية المتعمقة". تقدم مجموعات أمان الشبكة تصفية حركة مرور طبقة الشبكة الموزعة للحد من نسبة استخدام الشبكة داخل الشبكات الظاهرية في كل اشتراك. يوفر Azure Firewall شبكة مركزية وكاملة الحالة وحماية على مستوى التطبيق عبر الاشتراكات والشبكات الظاهرية.

Azure Firewall هي خدمة مدارة مع طبقات حماية متعددة، بما في ذلك حماية النظام الأساسي باستخدام مجموعات أمان الشبكة على مستوى NIC (غير قابلة للعرض). NSGs على مستوى الشبكة الفرعية غير مطلوبة على AzureFirewallSubnet ويتم تعطيلها لمنع انقطاع الخدمة.

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

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

تعد نقاط نهاية خدمة الشبكة الظاهرية بديلا ل Private Link للتحكم في وصول الشبكة إلى خدمات Azure PaaS. حتى إذا كان العميل لا يزال يستخدم عناوين IP العامة للوصول إلى خدمة PaaS، يتم جعل الشبكة الفرعية المصدر مرئية بحيث يمكن لخدمة PaaS الوجهة تنفيذ قواعد التصفية وتقييد الوصول على أساس كل شبكة فرعية. يمكنك العثور على مقارنة مفصلة بين الآليتين في مقارنة نقاط النهاية الخاصة ونقاط نهاية الخدمة.

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

للحصول على تفاصيل التسعير، راجع تسعير جدار حماية Azure.

للحصول على حدود الخدمة، راجع اشتراك Azure وحدود الخدمة والحصص النسبية والقيود.

لا ينقل Azure Firewall بيانات العملاء أو يخزنها خارج المنطقة التي يتم نشرها فيها.

لا، جدار حماية Azure في المراكز الظاهرية الآمنة (vWAN) غير مدعوم حاليا في قطر.

نعم، يدعم جدار حماية Azure تصفية نسبة استخدام الشبكة الواردة والصادرة. عادة ما تستخدم التصفية الواردة للبروتوكولات غير HTTP مثل RDP وSSH وFTP. بالنسبة لحركة مرور HTTP وHTTPS الواردة، ضع في اعتبارك استخدام جدار حماية تطبيق ويب مثل Azure Web Application Firewall (WAF) أو إلغاء تحميل TLS وميزات فحص الحزمة العميقة ل Azure Firewall Premium.

نعم، يدعم Azure Firewall Basic الاتصال النفقي القسري.

لا يتصل اختبار اتصال TCP فعليا ب FQDN الهدف. يحظر جدار حماية Azure الاتصالات بأي عنوان IP هدف أو FQDN ما لم تسمح به قاعدة بشكل صريح.

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

لا، لا يدعم جدار حماية Azure في الأصل تناظر BGP. ومع ذلك، تستخدم ميزة مسارات Autolearn SNAT بشكل غير مباشر BGP من خلال Azure Route Server.

يمكنك استخدام Azure PowerShell لإزالة تخصيص جدار حماية Azure وتخصيصه. تختلف العملية اعتمادا على التكوين.

لجدار حماية بدون Management NIC:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

لجدار حماية باستخدام Management NIC:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

لجدار حماية في مركز ظاهري آمن:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

إشعار

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

يوصى بتكوين مناطق التوفر أثناء النشر الأولي. ومع ذلك، يمكنك إعادة تكوينها بعد التوزيع إذا:

• يتم نشر جدار الحماية في شبكة ظاهرية (غير مدعوم في المراكز الظاهرية الآمنة).
• تدعم المنطقة مناطق التوفر.
• يتم تكوين جميع عناوين IP العامة المرفقة بنفس المناطق.

لإعادة تكوين مناطق التوفر:

1. إلغاء تخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. تحديث تكوين المنطقة وتخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

نعم:

• يجب أن يكون جدار حماية Azure والشبكة الظاهرية في نفس مجموعة الموارد.
• يمكن أن يكون عنوان IP العام في مجموعة موارد مختلفة.
• يجب أن تكون جميع الموارد (جدار حماية Azure، والشبكة الظاهرية، وعنوان IP العام) في نفس الاشتراك.

تشير حالة التوفير الفاشلة إلى فشل تحديث التكوين على مثيل خلفي واحد أو أكثر. يظل جدار حماية Azure قيد التشغيل، ولكن قد يكون التكوين غير متناسق. أعد محاولة التحديث حتى تتغير حالة التوفير إلى Succeeded.

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

نعم، تقتصر أسماء جدار الحماية على 50 حرفا.

تضمن الشبكة الفرعية /26 عناوين IP كافية للتحجيم حيث يقوم جدار حماية Azure بتوفير مثيلات إضافية للجهاز الظاهري.

لا، الشبكة الفرعية /26 كافية لجميع سيناريوهات التحجيم.

يتوسع جدار حماية Azure تلقائيا استنادا إلى استخدام وحدة المعالجة المركزية ومعدل النقل وعدد الاتصالات. تتراوح سعة معدل النقل من 2.5 إلى 3 جيجابت في الثانية في البداية إلى 30 جيجابت في الثانية (SKU قياسي) أو 100 جيجابت في الثانية (Premium SKU).

نعم. للحصول على التفاصيل، راجع حدود الاشتراك والخدمة في Azure والحصص النسبية والقيود.

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

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

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

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

نعم. لمزيد من المعلومات، راجع النسخ الاحتياطي لجدار حماية Azure ونهج جدار حماية Azure باستخدام Logic Apps.

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

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

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

لا يقوم جدار حماية Azure ب SNAT عندما يكون عنوان IP الوجهة هو نطاق IP خاص لكل IANA RFC 1918 أو IANA RFC 6598 للشبكات الخاصة. إذا كانت مؤسستك تستخدم نطاق عنوان IP عام للشبكات الخاصة، فإن جدار حماية Azure Firewall يقوم بترجمة عنوان شبكة المصدر SNAT لحركة المرور لأحد عناوين IP الخاصة بجدار الحماية في AzureFirewallSubnet. يمكنك تكوين جدار حماية Azure Firewall على عدم ترجمة عنوان شبكة المصدر SNAT لنطاق عنوان IP العام الخاص بك. لمزيد من المعلومات، راجع نطاقات عناوين IP الخاصة بـ Azure Firewall SNAT.

بالإضافة إلى ذلك، حركة المرور التي تتم معالجتها بواسطة قواعد التطبيق هي دائمًا SNAT-ed. إذا كنت تريد مشاهدة عنوان IP المصدر الأصلي في سجلات حركة مرور FQDN يمكنك استخدام قواعد شبكة الاتصال مع FQDN الوجهة.

يتم دعم التوجيه القسري عند إنشاء جدار حماية جديد. لا يمكنك تكوين جدار حماية موجود للتوجيه القسري. لمزيد من المعلومات، راجع توجيه Azure Firewall المفروض.

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

إذا تطلب التكوين الخاص بك توجيهًا قسريًّا إلى شبكة محلية ويمكنك تحديد بادئات IP الهدف لوجهات إنترنت الخاصة بك، يمكنك تكوين هذه النطاقات مع شبكة الاتصال المحلية كالقفزة التالية عبر توجيه محدد من قبل مستخدم على AzureFirewallSubnet. أو يمكنك استخدام BGP لتعريف هذه التوجيهات.

• URL - تعمل العلامات النجمية عند وضعها على الجانب أقصى اليمين أو أقصى اليسار. إذا كانت على اليسار، فلا يمكنها أن تكون جزءًا من FQDN.
• FQDN - تعمل العلامات النجمية عند وضعها على الجانب أقصى اليسار.
• GENERAL - تعني العلامات النجمية على الجانب الأيسر الأكثر حرفيا أي شيء إلى التطابقات اليسرى، ما يعني مطابقة مجالات فرعية متعددة و/أو تباينات اسم المجال غير المرغوب فيها - راجع الأمثلة التالية.

أمثلة:

نوع	‏‏قاعدة	مدعوم؟	أمثلة إيجابية
TargetURL	www.contoso.com	‏‏نعم‬	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	‏‏نعم‬	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	‏‏نعم‬	example.anycontoso.com sub1.example.contoso.com contoso.com تحذير: يسمح هذا الاستخدام لحرف البدل أيضا بتباينات غير المرغوب فيها/الخطرة مثل th3re4lcontoso.com - الاستخدام بحذر.
TargetURL	www.contoso.com/test	‏‏نعم‬	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	‏‏نعم‬	www.contoso.com/test/anything ملاحظة: www.contoso.com/testلا يتطابق (الشرطة المائلة الأخيرة)
TargetURL	www.contoso.*/test/*	لا
TargetURL	www.contoso.com/test?example=1	لا
TargetURL	www.contoso.*	لا
TargetURL	www.*contoso.com	لا
TargetURL	www.contoso.com:8080	لا
TargetURL	*.contoso.*	لا
TargetFQDN	www.contoso.com	‏‏نعم‬	www.contoso.com
TargetFQDN	*.contoso.com	‏‏نعم‬	any.contoso.com ملاحظة: إذا كنت تريد السماح على وجه التحديد contoso.com ، فيجب تضمين contoso.com في القاعدة. وإلا، يتم إسقاط الاتصال بشكل افتراضي لأن الطلب لا يتطابق مع أي قاعدة.
TargetFQDN	*contoso.com	‏‏نعم‬	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	لا
TargetFQDN	*.contoso.*	لا

‏‏لا. جدار حماية Azure Firewall يمنع الوصول إلى Active Directory بشكل افتراضي. للسماح بالوصول، قم بتكوين علامة خدمة AzureActiveDirectory. لمزيد من المعلومات، راجع علامات خدمة Azure Firewall.

نعم، يمكنك استخدام Azure PowerShell للقيام بذلك:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

اختبار اتصال TCP لا يؤدي بالفعل إلى الاتصال بـ FQDN الهدف. لا يسمح Azure Firewall بالاتصال بأي عنوان IP/FQDN هدف ما لم تكن هناك قاعدة صريحة تسمح بذلك.

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

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

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

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

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

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

لا يقوم Azure Firewall بنقل بيانات العملاء أو تخزينها خارج المنطقة التي يتم نشرها فيها.

نعم. لمزيد من المعلومات، راجع النسخ الاحتياطي لجدار حماية Azure ونهج جدار حماية Azure باستخدام Logic Apps.

لا، جدار حماية Azure حاليا في المراكز الظاهرية الآمنة (vWAN) غير مدعوم في قطر.

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

الحد الإجمالي لكل جدار حماية هو حد اتصال الجهاز الظاهري (250 ألف) × عدد الأجهزة الظاهرية في تجمع الواجهة الخلفية لجدار الحماية. يبدأ جدار حماية Azure بجهازين ظاهريين ويتوسع استنادا إلى استخدام وحدة المعالجة المركزية ومعدل النقل.

يستخدم Azure Firewall حاليا منافذ مصدر TCP/UDP لحركة مرور SNAT الصادرة، مع عدم وجود وقت انتظار الخام. عند إغلاق اتصال TCP/UDP، ينظر إلى منفذ TCP المستخدم على الفور على أنه متاح للاتصالات القادمة.

كحل بديل لبنى معينة، يمكنك النشر والتحجيم باستخدام بوابة NAT باستخدام جدار حماية Azure لتوفير مجموعة أوسع من منافذ SNAT للتغير والتوافر.

تعتمد سلوكيات NAT المحددة على تكوين جدار الحماية ونوع NAT الذي تم تكوينه. على سبيل المثال، يحتوي جدار الحماية على قواعد DNAT لنسبة استخدام الشبكة الواردة وقواعد الشبكة وقواعد التطبيق لحركة المرور الصادرة من خلال جدار الحماية.

لمزيد من المعلومات، راجع سلوكيات NAT لجدار حماية Azure.

لأي عملية صيانة المخطط لها، يقوم منطق استنزاف الاتصال بتحديث العقد الخلفية بأمان. جدار حماية Azure Firewall ينتظر 90 ثانية للاتصالات الموجودة لإغلاق. في أول 45 ثانية، لا تقبل عقدة الواجهة الخلفية اتصالات جديدة، وفي الوقت المتبقي تستجيب مع RST جميع الحزم الواردة. إذا لزم الأمر، يمكن للعملاء تلقائيًّا إعادة تأسيس الاتصال إلى عقدة خلفية أخرى.

قد يحدث إيقاف تشغيل مثيل Azure Firewall VM أثناء مقياس مجموعة مقياس الجهاز الظاهري في (تقليص) أو أثناء ترقية برنامج الأسطول. في هذه الحالات، يتم تحميل الاتصالات الواردة الجديدة متوازنة إلى مثيلات جدار الحماية المتبقية ولا تتم إعادة توجيهها إلى مثيل جدار الحماية لأسفل. بعد 45 ثانية، يبدأ جدار الحماية في رفض الاتصالات الموجودة عن طريق إرسال حزم TCP RST. بعد 45 ثانية أخرى يتم إيقاف تشغيل جدار الحماية VM. لمزيد من المعلومات، راجع إعادة تعيين TCP لموازن التحميل ومهلة الخمول.

يتوسع جدار حماية Azure تدريجيا عندما يكون متوسط معدل النقل أو استهلاك وحدة المعالجة المركزية عند 60٪، أو يكون عدد استخدام الاتصالات 80٪. على سبيل المثال، يبدأ في التوسع عندما يصل إلى 60٪ من الحد الأقصى لمعدل النقل الخاص به. تختلف أرقام معدل النقل القصوى استنادا إلى Azure Firewall SKU والميزات الممكنة. لمزيد من المعلومات، راجع أداء Azure Firewall.

يستغرق التوسع من خمس إلى سبع دقائق. عند اختبار الأداء، تأكد من الاختبار لمدة 10 إلى 15 دقيقة على الأقل، وابدأ اتصالات جديدة للاستفادة من عقد جدار حماية Azure التي تم إنشاؤها حديثا.

عندما يحتوي الاتصال على مهلة الخمول (أربع دقائق من عدم النشاط)، يقوم جدار حماية Azure بإنهاء الاتصال بأمان عن طريق إرسال حزمة TCP RST.

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

لا تتوفر إعلامات متقدمة لصيانة جدار حماية Azure.

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

لا، يتم حاليا تكوين نوافذ الصيانة للتكتم يوميا.

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

نعم.

‏‏لا. حاليا، يمكن إقران تكوين صيانة واحد فقط بجدار حماية Azure.

تدعم جميع وحدات SKU لجدار حماية Azure - الأساسية والقياسية والمتميزة الصيانة التي يتحكم فيها العميل.

قد يستغرق جدار حماية Azure ما يصل إلى 24 ساعة لمتابعة جدول الصيانة بعد إقران نهج الصيانة.

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

لمزيد من المعلومات، راجع تكوين الصيانة التي يتحكم فيها العميل.