قصص مخيفة تُروى في الشبكة

مع اقتراب عيد الهالوين، إليكم قصة رعب واقعية عن سياسات الجدران النارية. (لتكتمل الصورة، تخيّلوها بصوت مخيف أجشّ يحمل تحذيراً… أو بصوت Morgan Freeman إن كنتم تفضّلون ذلك.)

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

السيناريو:
كانت الشركة قد تبنّت حديثاً فلسفة "Zero Trust" واستثمرت وقتاً كبيراً للاقتراب من هذا الهدف. وعلى مدار العام الماضي ركّزت على تنظيف سياسات الجدران النارية لديها من خلال كتابة قواعد محدّدة وفق حاجة العمل – لا أكثر – أي عناوين IP والشبكات التي تحتاج إلى الوصول فقط. وكانت تحرز تقدماً حين اكتشف أحد مهندسيها أمراً مروّعاً: قاعدة "Any – Any – Any – Accept" مرعبة مدفونة في منتصف السياسة.

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

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

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

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

—

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

1) تنبيهات الامتثال وإعداد التقارير:
كنا سننبّه الفريق فوراً إذا دخلت الخدمة قاعدة مفرطة التساهل كهذه. ويمكنكم ببساطة "ضبط المؤشر" على مستوى التساهل الذي تقبلونه في القواعد، مثل "القواعد التي تسمح بالوصول إلى أكثر من 60,000 وجهة" أو "القواعد التي تتجاوز مصادرها شبكة /16".

2) تنبيهات التغيير:
كانت هذه القاعدة ستظهر في العرض الموحّد لدينا – أياً كان مزوّد الجدار الناري – وسيتضح بجلاء أنها أُضيفت. أي أنه لم يكن ممكناً "تمريرها خلسة". ويتلقى بعض المهندسين والمديرين تقارير تغيير السياسة عبر البريد الإلكتروني تلقائياً في كل مرة يُجرى فيها تغيير – أو حتى لقطة لكل ما تغيّر خلال 30 يوماً.

3) وبوجود أداة الأتمتة لدينا، FireMon Policy Planner، كانت القاعدة الخطرة ستُوقف في مسارها – قبل أن تُنشر أصلاً. فباستخدام "تحليل ما قبل التغيير" كانت القاعدة ستُحدَّد ويُشار إليها قبل نشرها في بيئة الإنتاج وقبل أن تسمح بمرور حزمة واحدة عبرها. ولهذا السبب يحب مختصو الامتثال أننا لا نكتفي بالتوصية بإنشاء قواعد بناءً على الحاجة، بل نشغّل خوارزميات الامتثال لدينا – أشبه ببيئة معزولة – قبل أن نتمكن من نشر القواعد تلقائياً. بعض العملاء يقتنون Policy Planner من أجل هذه الميزة فقط – ويستخدمون واجهات برمجة التطبيقات لدينا للوصول إليها.

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

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

6) احتفظت بالأفضل للنهاية. إذا كانت لديكم قاعدة مفرطة التساهل – كأن يكون من سبقكم قد اتّبع "أسلوباً أكثر انفتاحاً ومرونة في إنشاء القواعد" يختلف عن أسلوبكم – فلدينا طريقة سهلة لتنظيف هذه القواعد. فباستخدام تحليل تدفق حركة البيانات، تفحص أداتنا كل عنوان IP يمر عبر القاعدة، مفكّكة قاعدة any/any/any إلى تدفقات محدّدة. ويمكنكم تصدير هذه التدفقات وإنشاء قواعد محدّدة استناداً إليها.