تنظيف قواعد جدار الحماية: العثور على السياسات غير المستخدمة وتدقيقها

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

ما هو تنظيف قواعد جدار الحماية ولماذا يصبح أمراً لا مفر منه؟

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

لا تنمو مجموعة القواعد بسبب سوء الإدارة بل بسبب طبيعة العمل. يُطلق تطبيق جديد، ويُنقل خادم، ويُمنح مورّد وصولاً لأسبوعين، ويُكتب إذن «مؤقت» أثناء استكشاف عطل. ينتهي المشروع، ويُوقف الخادم، ويغادر المورّد؛ وتبقى القاعدة. وعند استبدال جهاز قديم تُنقل القواعد غالباً واحدة بواحدة لأن أحداً لا يعرف أيها ما زال ضرورياً. بعد بضع سنوات يواجه المسؤول قائمة سياسات من مئات الأسطر، ولا يستطيع حتى أخبر المهندسين الإجابة بثقة عن سؤال: «ما الذي يتعطل إذا حذفت هذه؟»

لهذا التراكم ثلاث تكاليف. الأولى أمنية: قواعد السماح الواسعة والمنسية مسارات للحركة الجانبية لمهاجم تمكّن من موطئ قدم في الشبكة. الثانية تشغيلية: كل تغيير يستلزم قراءة مئات القواعد، ويطول استكشاف الأعطال، وتزداد احتمالية أن تقع قاعدة جديدة أُضيفت في نهاية القائمة في ظل قاعدة واسعة فوقها. الثالثة امتثالية: عندما يسأل المدقق «لماذا توجد هذه القاعدة؟» ولا يجد جواباً، تُكتب ملاحظة بغضّ النظر عن حداثة البرنامج الثابت.

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

من أين يبدأ التدقيق؟ جرد القواعد والمبرر العملي

يبدأ تدقيق جدار الحماية بجرد كامل للقواعد: تُصدَّر السياسات لكل جهاز ونطاق افتراضي (VDOM)، وتُربط كل قاعدة بمالك وغرض وسجل تغيير. والقاعدة التي لا يُعثر على مبررها تُعلَّم مشبوهة حتى لو كانت تعمل تقنياً، وتدخل عملية إعادة اعتماد.

يبدأ الجرد بنسخة احتياطية من الإعدادات. النسخة المؤرَّخة المأخوذة في بداية التدقيق هي نقطة التراجع وأول وثيقة في ملف الأدلة معاً. ثم تُصدَّر قائمة السياسات إلى جدول يضم في كل صف على الأقل: معرّف السياسة واسمها، واجهات المصدر والوجهة، كائنات عناوين المصدر والوجهة، الخدمات، الإجراء، الجدولة، حالة NAT، ملفات الأمان المسندة، إعداد التسجيل، حقل التعليق، عدّاد الإصابات ووقت آخر استخدام. هذا الجدول هو سطح عمل التدقيق؛ وتُدوَّن فيه النتائج والقرارات والتواريخ في المكان نفسه.

الأصعب من الحقول التقنية هو السياق العملي. تُطرح على كل قاعدة ثلاثة أسئلة: من طلبها؟ أي عملية عمل تحتاجها؟ متى تصبح غير ضرورية؟ تُبحث الإجابات في حقل التعليق أو سجلات التغيير أو نظام التذاكر. في FortiGate يكفي حقلا اسم السياسة والتعليق لحمل رقم التذكرة والقسم المالك؛ وبعد التدقيق ينبغي اعتماد معيار تسمية يجعل هذين الحقلين إلزاميين. توصي وثيقة NIST SP 800-41 Rev. 1 لإرشادات جدران الحماية وسياساتها بمجموعة قواعد قائمة على مبدأ الرفض الافتراضي تُكتب فيها كل قاعدة بأضيق صيغة ممكنة وتُوثَّق؛ وجدول الجرد هو النظير الداخلي لهذا التوثيق.

للقواعد ذات المالك المعروف تُفتح جولة إعادة اعتماد: تُرسل قائمة القواعد إلى وحدة العمل مع مهلة للرد بـ«ما زالت مطلوبة» أو «يمكن إزالتها». والقواعد التي لا يصل رد بشأنها تصبح تلقائياً مرشحة للتعطيل. تمنع هذه الخطوة الفريق التقني من اتخاذ قرار الحذف منفرداً وتنقل المسؤولية إلى موضعها الصحيح، أي مالك العمل. وفي خبرتنا الميدانية هذه أطول خطوة في التدقيق الأول؛ وتقصر كثيراً في الدورات اللاحقة لأن الجرد يبقى محدَّثاً.

كيف تُكتشف السياسات غير المستخدمة؟ عدّاد الإصابات وبيانات آخر استخدام

سياسة جدار الحماية غير المستخدمة هي قاعدة لم تطابق أي حركة خلال نافذة مراقبة محددة. في FortiGate يعرض عمودا عدّاد الإصابات وآخر استخدام في جدول السياسات، وفي سطر الأوامر مخرجات diagnose firewall iprope show 100004 <policy-id>، وقت أول وآخر مطابقة؛ وتؤكد سجلات FortiAnalyzer هذه البيانات على المحور الزمني.

عدّاد الإصابات أقوى أدوات التدقيق، لكنه سهل التفسير الخاطئ. فبحسب الإصدار والإعداد قد تبدأ العدّادات من جديد بعد إعادة تشغيل أو تعديل قاعدة أو تصفير يدوي (diagnose firewall iprope clear 100004)، كما أن عدّاد السياسات المتحرك لسبعة أيام الموصوف في وثائق FortiOS 7.2 يغيّر الفترة التي تغطيها القيمة المعروضة. لذا لا تعني قيمة الصفر بحد ذاتها «لم تُستخدم قط». دوّن قبل البدء تاريخ بدء العدّادات، وتحقق من سلوكها لإصدارك في وثائق Fortinet. وتُحدَّد نافذة المراقبة وفق إيقاع العمل: تسعون يوماً حد أدنى معقول لحركة المكاتب الاعتيادية، أما القواعد التي تخدم عمليات نادرة مثل إقفال السنة أو التدقيق الدوري أو تمارين التعافي من الكوارث فتحتاج نافذة من ستة إلى اثني عشر شهراً.

المصدر الثاني للأدلة هو السجلات. في FortiAnalyzer يمكن تجميع سجلات الحركة حسب معرّف السياسة لإنتاج تقرير استخدام السياسات لكل فترة؛ وهذا التقرير مستقل عن عدّادات الجهاز ويُظهر التاريخ حتى لو صُفِّر العدّاد. تتناول مقالتنا عن تسجيل FortiGate ومراقبته والتكامل مع FortiAnalyzer بنية السجلات وتصميم التقارير. وحيث يتولى FortiAnalyzer الإدارة المركزية للسجلات أصلاً، تصبح المنصة نفسها مصدراً لأدلة التدقيق.

عند العثور على قاعدة غير مستخدمة يتبع المسار أربع خطوات. الأولى التصنيف: تُقيَّم قواعد السماح وقواعد الرفض الصريح كلٌّ على حدة؛ فقاعدة رفض صريح بلا إصابات غالباً تعبير متعمد عن السياسة ويمكن الإبقاء عليها. الثانية التعطيل: لا تُحذف القاعدة بل تُضبط حالتها على معطَّلة ويُكتب التاريخ ومرجع التدقيق في حقل التعليق. الثالثة الحجر: إذا لم يُبلَّغ عن أي تعطل خلال فترة مثل ثلاثين يوماً تصبح القاعدة جاهزة للحذف. الرابعة التسجيل: يُضاف التعريف الكامل للقاعدة المحذوفة إلى ملف الأدلة. وطوال ذلك ينبغي تفعيل تسجيل حركة المخالفات على سياسة الرفض الضمني (implicit deny)؛ فهو يُظهر فوراً أي حركة حقيقية حجبتها قاعدة أُزيلت ويبسّط قرار التراجع.

كيف تُكتشف القواعد المظلَّلة والمكررة والمتعارضة؟

القاعدة المظلَّلة لا تُنفَّذ أبداً لأن قاعدة أوسع فوقها تلتقط كل حركتها؛ والقاعدة المكررة تعيد الإجراء نفسه على الحركة نفسها؛ والقاعدة المتعارضة تطبّق إجراءً مختلفاً على حركة متداخلة جزئياً. الثلاث تُظهر عدّاد إصابات صفرياً أو منخفضاً، لكن الجذر خطأ في الترتيب، والحل إعادة التنظيم لا الحذف.

تُقيَّم سياسات جدار الحماية من الأعلى إلى الأسفل وتفوز أول مطابقة. هذه القاعدة البسيطة تنتج مفاجآت في القوائم الطويلة. مثال: إذا سمحت القاعدة الثانية عشرة بكل الخدمات من الشبكة المحلية إلى خادم تطبيقات في المنطقة المنزوعة السلاح (DMZ)، فإن قاعدة «HTTPS فقط» في الموضع الخامس والعشرين لن تعمل أبداً؛ يظن المسؤول أن سياسة ضيقة قائمة بينما يطبّق الجهاز الواسعة. والسيناريو الأخطر قاعدة رفض تحجب مشاركة الملفات من شبكة الضيوف إلى خادم لكنها لا تسري أبداً بسبب قاعدة سماح واسعة فوقها. عندها لا وجود عملياً للضابط الأمني المكتوب في وثيقة السياسة.

هناك ثلاث طرق للكشف. المؤسسات التي تشغّل FortiManager يمكنها استخدام فحص اتساق السياسات (Policy Consistency Check) الذي يعمل على حزمة السياسات ويبلّغ عن الكائنات المكررة والمظلَّلة والمتداخلة وغير المستخدمة (اليتيمة)؛ تحقق من نطاق هذه الميزة في وثائق إصدارك. ومنصات تحليل القواعد المستقلة تفحص أجهزة عدة مصنّعين في وحدة تحكم واحدة وتمنح كل قاعدة درجة خطر. أما مجموعات القواعد الصغيرة فيكفي فيها ترتيب جدول الجرد حسب تداخل عناوين المصدر والوجهة ليلتقط العين الخبيرة القواعد المظلَّلة يدوياً. يلخص الجدول أدناه أنواع الشذوذ التي تُصادف في التدقيق والإجراء الصحيح لكل منها.

عند العثور على قاعدة مظلَّلة يجب أن يكون السؤال الأول «أيهما الصحيحة؟» لا «هل أحذفها؟». ففي أغلب الأحيان تعبّر القاعدة الضيقة الواقعة في الظل عن النية الحقيقية، والواجب إزالتها هي القاعدة الواسعة فوقها. لهذا يُجرى تحليل الظل بالتوازي مع عمل تضييق any-any في القسم التالي.

قواعد any-any والقواعد الواسعة: تضييق السياسات الأعلى خطراً

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

تأتي قواعد any-any عادة من ثلاثة مصادر: أذونات واسعة فُتحت عند الإعداد الأول بعقلية «فليعمل أولاً»، وقواعد كُتبت أثناء استكشاف الأعطال ونُسيت، وسياسات تاريخية رُحِّلت من جهاز سابق. وما يجمعها ارتفاع عدّاد الإصابات؛ ولهذا لا تظهر أبداً في تحليل القواعد غير المستخدمة وتحتاج عملاً منفصلاً. فارتفاع العدّاد لا يثبت ضرورة القاعدة، بل يعني فقط أن حركة كثيرة تمر عبرها.

يُنفَّذ التضييق في ست خطوات. الأولى: تفعيل تسجيل جميع الجلسات على القاعدة الواسعة وتجميع البيانات طوال نافذة المراقبة. الثانية: استخراج ثلاثيات المصدر والوجهة والخدمة المستخدمة فعلاً من السجلات. الثالثة: كتابة هذه التدفقات كقواعد ضيقة فوق القاعدة الواسعة باستخدام مجموعات العناوين ومجموعات الخدمات. الرابعة: إسناد ملفات IPS ومكافحة الفيروسات وتصفية الويب والتحكم بالتطبيقات إلى القواعد المتجهة إلى الإنترنت؛ فهذه الملفات غالباً غائبة عن القاعدة الواسعة. الخامسة: مراقبة هبوط عدّاد إصابات القاعدة الواسعة نحو الصفر؛ فإن لم يهبط فهناك تدفق فائت. السادسة: عندما يبلغ العدّاد الصفر تُعطَّل القاعدة الواسعة وتُنتظر فترة الحجر ثم تُحذف.

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

إدارة التغيير وأدلة التدقيق: كيف يبقى التنظيف دائماً؟

يبقى التنظيف دائماً فقط عندما تُنشأ كل قاعدة جديدة بطلب معتمد ومالك وغرض وتاريخ انتهاء. تشترط إدارة التغيير نسخاً احتياطية للإعدادات قبل التغيير وبعده، وسجل اعتماد، وخطة تراجع؛ وتتكوّن أدلة التدقيق من الجرد المؤرَّخ، وتقرير عدّاد الإصابات، وقائمة القواعد المحذوفة، ومراسلات إعادة الاعتماد.

من الشائع أن تعود مجموعة قواعد نُظِّفت إلى حالتها القديمة خلال ستة أشهر، والسبب غياب عملية التغيير. الحد الأدنى للعملية: يدخل الطلب نظام التذاكر مع مبرر عملي مكتوب؛ يتحقق الفريق التقني من أن القاعدة الجديدة لا تظلّل القواعد القائمة ولا تكررها؛ يُحصل على الاعتماد؛ يُطبَّق التغيير في نافذة صيانة؛ تُحفظ نسخ الإعدادات قبل التغيير وبعده؛ تُتحقق النتيجة وتُغلق التذكرة. وللوصول المؤقت تُستخدم كائنات الجدولة في FortiGate؛ فالجدولة ذات تاريخ الانتهاء تجعل قاعدة المورّد تنقضي من تلقاء نفسها وتجفف فئة «القاعدة المؤقتة المنسية» من منبعها. والمؤسسات التي تشغّل FortiManager يمكنها عبر سجل مراجعات الإعدادات معرفة من غيّر ماذا ومتى، ومقارنة الفروق بين المراجعات.

يجيب ملف أدلة التدقيق عن سؤال المدقق أو العميل «هل تراجعون مجموعة قواعدكم؟» بالوثائق. ويضم: تاريخي بداية التدقيق ونهايته، النسخ الاحتياطية المؤرَّخة للإعدادات، جدول جرد القواعد، تقرير عدّاد الإصابات واستخدام السياسات، قائمة الشذوذ مع القرار المتخذ لكل منها، التعريفات الكاملة للقواعد المحذوفة والمضيَّقة، ردود إعادة الاعتماد من مالكي الأعمال، وتذاكر التغيير. وهذا الملف نفسه نقطة انطلاق التدقيق التالي.

تجعل أطر الامتثال هذه الدورة إلزامية. فالمتطلب 1.2.7 من PCI DSS v4.0 يشترط مراجعة إعدادات ضوابط أمن الشبكة مرة على الأقل كل ستة أشهر. وفي تركيا يُدرج دليل أمن البيانات الشخصية (التدابير التقنية والإدارية) الصادر عن هيئة حماية البيانات الشخصية (KVKK) جدران الحماية وإدارة صلاحيات الوصول ضمن التدابير التقنية؛ ونتناول الجانب المتعلق بجدار الحماية من هذه التدابير في قائمة تحقق التدابير التقنية لقانون KVKK. ولالتزامات الاحتفاظ بسجلات الحركة والأحداث راجع مقالتنا عن القانون رقم 5651 والإدارة المركزية للسجلات؛ وفي المجالين ننصح بالتحقق من التشريعات الحالية والأدلة الرسمية. وحيث لا يستطيع الفريق الداخلي تخصيص وقت لهذه الدورة، يدخل التدقيق الدوري للسياسات ضمن النطاق القياسي لـخدمة جدار الحماية المُدار.

قائمة تحقق تدقيق سياسات جدار الحماية

تُستخدم قائمة تحقق تدقيق سياسات جدار الحماية لإجراء التدقيق من بدايته إلى نهايته وتوثيق نتيجته بالأدلة. يجيب كل صف عن سؤال واحد بنعم أو لا ويسمّي الدليل الذي يدخل الملف؛ وتُكرَّر القائمة كل ستة أشهر على الأقل، وفصلياً في البيئات كثيرة التغييرات.

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

الأسئلة الشائعة

كم مرة يجب إجراء تنظيف قواعد جدار الحماية؟

يشترط المتطلب 1.2.7 من PCI DSS v4.0 مراجعة إعدادات ضوابط أمن الشبكة مرة واحدة على الأقل كل ستة أشهر. في البيئات كثيرة التغييرات تكون الدورة الفصلية أنسب، وبعد أي ترحيل كبير أو إعادة تصميم للشبكة ينبغي إجراء تدقيق خارج الجدول.

هل من الآمن حذف قاعدة عدّاد إصاباتها صفر فوراً؟

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

ما الفرق بين القاعدة المظلَّلة والقاعدة المكررة؟

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

كيف أرى السياسات غير المستخدمة على FortiGate؟

فعّل عمودي عدّاد الإصابات (hit count) وآخر استخدام (last used) في جدول السياسات ورشّح القيم الصفرية أو القديمة. في سطر الأوامر يعرض الأمر diagnose firewall iprope show 100004 وقت أول وآخر مطابقة لكل سياسة، ويؤكد تقرير FortiAnalyzer لاستخدام السياسات النتيجة من جهة السجلات.

هل تتوقف تطبيقات العمل إذا أزلنا قاعدة any-any؟

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

هل يُعدّ تدقيق سياسات جدار الحماية دليلاً لـ PCI DSS وحماية البيانات؟

الدليل هو المخرجات لا النشاط نفسه: جرد قواعد مؤرَّخ، تقرير عدّاد الإصابات، قائمة القواعد المحذوفة والمضيَّقة، ردود إعادة الاعتماد من المالكين، وتذاكر التغيير. يثبت هذا الملف المراجعة الدورية التي يشترطها PCI DSS وضبط الوصول الموثَّق الذي تتوقعه أدلة حماية البيانات.

هل من المنطقي إسناد تنظيف القواعد إلى فريق خارجي؟

نعم عندما يكون الفريق الداخلي مشغولاً بالتشغيل اليومي؛ فالتدقيق الدوري للسياسات جزء من نطاق معظم خدمات جدار الحماية المُدار. المهم أن تُتخذ قرارات الحذف مع مالكي الأعمال وأن يُسجَّل كل خطوة: الفريق الخارجي يحلل وينفذ، والمؤسسة تعتمد.

الخلاصة

لا يجعل تنظيف قواعد جدار الحماية الجهاز أقوى؛ بل يجعله يطبّق السياسة التي كتبتها فعلاً. فدورة تدقيق تبدأ بالجرد والمبرر العملي، وتستبعد القواعد غير المستخدمة بعدّادات الإصابات والسجلات، وتعيد تنظيم القواعد المظلَّلة وقواعد any-any، وتوثّق كل خطوة بالأدلة، تقلّص سطح الهجوم وتنتج في الوقت نفسه ملفاً يمكن الدفاع عنه أمام مراجعات PCI DSS ومتطلبات حماية البيانات. وسرّ الديمومة إجرائي لا تقني: لا تُنشأ قاعدة بلا طلب معتمد ومالك وغرض وتاريخ انتهاء.

لتخطيط أول تدقيق لمجموعة قواعدكم، أو مراجعة إعدادات FortiGate الحالية، أو إدراج التدقيق الدوري ضمن نطاق خدمة مُدارة، يمكنكم حجز جلسة استكشاف مجانية مع Sora Yazılım؛ نحدد معاً النطاق المناسب ونعدّ عرضاً.