جدران الحماية

بينما ركّز معظمُ هذا الكتاب على استعمالات التشفير (cryptography) لتوفير خصائصَ أمنيةٍ مثل المصادقة (authentication) والسرّية، فإنّ هناك مجموعةً كاملةً من المسائل الأمنية التي لا يمكن معالجتها بسهولة بالوسائل التشفيرية. فمثلًا، تنتشر الديدانُ والفيروساتُ وسائرُ البرمجياتِ الخبيثة (malware) باستغلال أخطاءٍ في أنظمة التشغيل وبرامج التطبيقات (وأحيانًا باستغلال سهولةِ تصديق الإنسان أيضًا)؛ ولا يمكن لأيّ مقدارٍ من التشفير أن ينفعك إذا كانت آلةُك تحمل ثغراتٍ (vulnerabilities) لم تُرقَّع. ولهذا تُستعمل غالبًا مقارباتٌ أخرى لمنع مختلف أشكال الحركة التي قد تكون ضارّة. وجدرانُ الحماية (firewalls) إحدى أكثر الطرق شيوعًا للقيام بذلك.

ولتقديم سياقٍ أيسر لهذا الفصل، من المفيد أن نفهم أنّ كتابة برمجياتٍ غيرِ معرَّضةٍ للاختراق تمثّل جزءًا مهمًّا من المشهد الأمني على نحوه الشامل. وهو موضوعٌ واسع، يبدأ بأسئلةٍ عن لغةِ البرمجة التي تستعملها (مثلًا: اللغاتُ الآمنةِ الذاكرةً مثل Rust أقلّ عرضةً من C مثلًا)، ويتضمّن أيضًا تنوّعًا من مشكلات أنظمة التشغيل (مثلًا: كيف يُطبَّق العزلُ بين العمليات بكفاءة). وهذه الموضوعاتُ خارج نطاق هذا الكتاب، الذي يتّخذ بدلًا من ذلك منظورًا مركزًا على الشبكة، ويسأل: «ماذا يمكننا أن نفعل في الشبكة إمّا للحدّ من فرص استغلال البرمجيات الخبيثة لبرمجياتٍ معرَّضة، أو للتخفيف من الأثر حين تنجح هذه الاستغلالات؟» وتُعدّ جدرانُ الحماية، والأعمّ منها أجهزةُ الأمن (security appliances)، جزءًا من الجواب. فهي أجهزةٌ توضع في مواضعَ استراتيجيةٍ في أنحاء الشبكة، تكتشف الحركةَ الخبيثةَ وتستجيب لها.

والخلاصةُ الكبرى الأخرى هي أنّ جدرانَ الحماية وسائرَ أجهزةِ الأمن تجلّي مبدأَ الدفاع متعدّد الطبقات (defense in depth) الذي قدّمناه في الفصل 2. فمن المثاليّ ألّا تكون كلُّ البرمجياتِ التي نشغّلها مصمَّمةً كأنّها لا تُخترق أبدًا، لكنّنا في الأوقات التي لا تكون فيها كذلك — مثلًا حين يُكتشف خطأٌ جديد — بحاجةٍ إلى خطّ دفاعٍ ثانٍ. وتضطلع أجهزةُ الشبكة بهذا الدور.

9.1 المبادئ الأساسية لجدران الحماية

المعنى التاريخي لجدار الحماية هو حاجزٌ يمنع انتشارَ النار من جزءٍ من مبنى إلى جزءٍ آخر. وتوجد جدرانُ حمايةٍ أيضًا في كثيرٍ من المركبات لفصل الركّاب عن حجرة المحرّك الصاخبة (وربما المعرَّضة للاشتعال). واستعمل سولتزر وشرويدر (Saltzer and Schroeder) المصطلحَ هذا عام 1975، ربما لأوّل مرّةٍ في سياق أمن الحواسيب، عند مناقشتهما مبدأَ أقلّ الامتياز (least privilege).

وجدارُ حمايةِ الشبكة نظامٌ يجلس عادةً بين منطقتين من الشبكة، كما هو مبيَّن في الشكل 33، فيحمي تدفّقَ الحركة من منطقةٍ إلى أخرى. ومن المواضع الشائعة نقطةٌ استراتيجيةٌ مثل نقطة الدخول/الخروج إلى شبكة مؤسسية أو مركز بيانات. وبالطبع، على خلاف جدار الحماية الماديّ الذي يحجب كلَّ ما في طريقه، فإنّ جدارَ حماية الشبكة هو في الحقيقة نوعٌ من مرشِّح الحزم (packet filter) يتّخذ قراراتٍ حول الحركة المسموح لها بالعبور بالضبط.

وتاريخيًّا، نُفِّذ جدارُ الحماية بوصفه «جهازًا» مخصَّصًا: نظامًا مُتخصَّصًا له مهمةٌ واحدة، وهي ترشيحُ الحزم. كما وفِّرت جدرانُ الحماية بوصفها مجموعةً من الميزات المتوفّرة على موجِّه (router)، ويمكن تنفيذُ «جدار حماية شخصي» على آلةِ مستخدمٍ نهائي. وأحدثُ من ذلك (في العقد الماضي تقريبًا)، ظهرت جدرانُ حمايةٍ موزّعة (distributed firewalls) سعيًا إلى تطبيق السياسات الأمنية على قدرٍ أكبر من الحركة. وسنعود إلى هذا الصنف من جدران الحماية في ما بعد من الفصل.

ويعتمد الأمنُ القائمُ على جدار الحماية على وجود الجدار في نوعٍ ما من نقاط الاختناق (choke-point). وينبغي ألّا تكون هناك طريقةٌ لتجاوز الجدار عبر بواباتٍ أخرى، أو مساراتٍ بديلة مثل اتصالاتٍ لاسلكيةٍ أو اتصالاتٍ هاتفيّة. ورغم أنّ مهمةَ جدار الحماية هي حجزُ الحركة المحتملةَ الضارّة («النار») وفق تعريفٍ ما للضرر، فإنّ قدرًا كبيرًا من الحركة يمرّ عبر جدار الحماية. ومن الإعدادات الشائعة لجدار الحماية أن يكون «مغلقًا افتراضيًّا» (default closed): فهو يحجب الحركة افتراضيًّا ما لم يُسمح صراحةً لها بالعبور. فمثلًا، قد يرشّح كلَّ الرسائل الواردة إلّا الموجَّهة إلى مجموعةٍ معيّنةٍ من عناوين IP وإلى أرقامِ منافذ TCP معيّنة. ونظرًا لتعقيد البيئات التي تُستعمل فيها جدرانُ الحماية، حيث قد يوجد آلافُ عناوين IP ومئاتُ التطبيقات قيد الاستعمال، فإنّ ضبطَ جدران الحماية يصير هو الآخر معقّدًا في الغالب.

الشكل 33. جدارُ حمايةٍ يرشّح الحزمَ المتدفّقةَ بين موقعٍ وبقيةِ الإنترنت.

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

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

بينما يوحي المثالُ أعلاه بشبكةٍ موثوقةٍ وأخرى غير موثوقة، فإنّ جدرانَ الحماية تُستعمل غالبًا لبناء مناطق ثقةٍ (zones of trust) متعدّدة، مثل تسلسلٍ هرميٍّ لمناطقَ تتصاعد ثقتُها. ومن الترتيبات الشائعة ثلاثُ مناطق ثقة: الشبكةُ الداخلية، والمنطقةَ المنزوعة السلاح (demilitarized zone, DMZ)، وبقيةَ الإنترنت. وتُستعمل المنطقةُ المنزوعة السلاح لاحتواء خدماتٍ مثل خوادم DNS والبريد الإلكتروني التي يلزم أن تكون في المتناول من الخارج. فكلٌّ من الشبكة الداخلية والعالم الخارجي يستطيع الوصولَ إلى المنطقة المنزوعة السلاح، لكنّ المضيفات في المنطقة المنزوعة السلاح لا تستطيع الوصولَ إلى الشبكة الداخلية؛ ولهذا فإنّ خصمًا ينجح في اختراق مضيفٍ في المنطقة المنزوعة السلاح المكشوفة يظلّ عاجزًا عن الوصول إلى الشبكة الداخلية. ويمكن استعادةُ المنطقة المنزوعة السلاح دوريًّا إلى حالةٍ نظيفة.

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

فمثلًا قد يُضبط جدارُ الحماية ليرشّح (لا يمرّر) كلَّ الحزم المطابقة للوصف التالي:

   (198.51.100.14, 1234, 192.0.2.11, 80, TCP)

يقول هذا النمطُ إنّه ينبغي التخلّصُ من كلّ حزم TCP القادمة من المنفذ 1234 على المضيف 198.51.100.14 والموجَّهة إلى المنفذ 80 على المضيف 192.0.2.11. (والمنفذ 80 هو منفذ TCP المعروف الخاصّ بـ HTTP.) وبالطبع، ليس عمليًّا غالبًا أن تذكر كلَّ مضيفِ مصدرٍ تريد ترشيحَ حزمه، ومن ثمّ يمكن أن تتضمّن الأنماطُ محارفَ بديلة (wildcards). فمثلًا،

   (*,  *, 192.0.2.11, 80, TCP)

يقال بترشيح كلّ الحزم الموجَّهة إلى المنفذ 80 على 192.0.2.11، بصرف النظر عن المضيف أو المنفذ الذي أرسل الحزمة. ولاحظ أنّ أنماطَ العناوين مثل هذه تتطلّب من جدار الحماية اتّخاذَ قراراتِ التمرير/الترشيح بناءً على أرقام منافذ الطبقة الرابعة، إلى جانب عناوين المضيفات في الطبقة الثالثة. ولهذا السبب تُسمّى جدرانُ حماية الشبكة أحيانًا مبدِّلاتِ الطبقة الرابعة (level 4 switches).

ولدى Linux ميزةُ جدار حمايةٍ تُسمّى ufw (uncomplicated firewall) يمكنها تطبيقُ قواعد جدار الحماية على مضيف. ويمكننا تنفيذُ السياسة الموصوفة أعلاه بالأمر التالي:

    $ sudo ufw deny to 192.0.2.11 port 80
    rule added
    $

ثمّ يمكننا التحقّق من أنّ قاعدتنا طُبِّقت على الوجه الصحيح:

    $ sudo ufw status
    Status: active

    To                         Action      From
    --                         ------      ----
    192.0.2.11 80              DENY        Anywhere

    $

في النقاش السابق، كان جدارُ الحماية يمرّر كلَّ شيءٍ إلّا ما يُطلب منه صراحةً ترشيحُ أنواعٍ معيّنةٍ من الحزم. ويمكن لجدار الحماية أيضًا أن يرشّح كلَّ شيءٍ ما لم يُطلب منه صراحةً تمريره، أو أن يستعمل مزيجًا من الاستراتيجيتين. فمثلًا، بدلًا من حجب الوصول إلى المنفذ 80 على المضيف 192.0.2.11، يمكن أن يُطلب من جدار الحماية حجبُ كلّ شيءٍ إلّا الوصولَ إلى المنفذ 25 (منفذ بريد SMTP) على خادمِ بريدٍ معيَّن، مثلَ

   (*,  *, 198.51.100.9, 25)

ويمكننا تحديدُ هذا السلوك باستخدام ufw:

    $ sudo ufw default deny incoming
    Default incoming policy changed to 'deny'
    (be sure to update your rules accordingly)
    $ sudo ufw allow to 198.51.100.9 port 25
    rule added
    $ sudo ufw status
    Status: active

    To                         Action      From
    --                         ------      ----
    198.51.100.9 25            ALLOW       Anywhere

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

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

وتفهم جدرانُ الحماية الحديثةُ وتقيم وترشّح بحسب بروتوكولاتَ تطبيقيّةٍ معيّنةٍ كثيرةٍ مثل HTTP أو FTP. فهي تستعمل معلوماتٍ خاصّةً بتلك البروتوكولات، مثل الروابط (URLs) في حالة HTTP، لاتخاذ قرارِ التخلّص من رسالةٍ ما أم لا. وحين قادرةٌ جدرانُ الحماية على فحص الحمولات (payloads) الموجودة داخل ترويسة TCP (مثلًا لتحليل طلب HTTP)، فيُشار إلى ذلك بأنّه الفحصُ العميق للحزم (deep packet inspection, DPI). وبالطبع، يكون هذا تحدّيًا إذا استُعمل التشفيرُ من الطرف إلى الطرف.

ومن أنواع جدران الحماية نوعٌ بعينه يستطيع تفسيرَ حركة التطبيقات، وهو جدارُ حماية تطبيقات الويب (Web Application Firewall). وكثيرًا ما توضع هذه الجدران مباشرةً أمام الخوادم التي تقدّم تطبيقات الويب (أو تُنفَّذ بوصفها وحدةً داخل الخادم). فهي تفحص حركةَ التطبيقات وتطبّق قواعدَ الترشيح لتكتشف وتصدّ هجماتٍ معيّنةٍ تستهدف ثغراتٍ معروفة، مثل حقن SQL. وحين يكون TLS مستعمَلًا (كما هو الحال دائمًا في الويب الحديث)، فإنّ جدران حماية تطبيقات الويب تنهي اتصالَ HTTPS بحيث يمكن فحصَ حمولة التطبيق. ومشروعُ ModSecurity مفتوحُ المصدر مثالٌ واسعُ الاستعمال لجدار حماية تطبيقات الويب.

9.2 نقاطُ القوة والضعف في جدران الحماية

في أفضل الأحوال، يحمي جدارُ الحماية الشبكةَ من الوصولِ غير المرغوبٍ من بقية الإنترنت؛ ولا يستطيع أن يوفّر اتصالًا آمنًا للاتصال المشروع بين داخل جدار الحماية وخارجه. وبالمقابل، فإنّ آليّاتِ الأمن القائمة على التشفير الموصوفة في هذا الفصل قادرةٌ على توفير اتصالٍ آمنٍ بين أيّ مشاركين في أيّ مكان. وإذ كان الأمر كذلك، فلماذا جدرانُ الحماية شائعةٌ إلى هذا الحد؟ أحدُ الأسباب أنّها يمكن نشرُها من طرفٍ واحدٍ (من قِبل مدير الشبكة مثلًا) باستعمال منتجاتٍ تجاريةٍ منفردة، في حين يتطلّب الأمنُ القائمُ على التشفير دعمًا عند طرفي الاتصال معًا. أمّا السببُ الأكثر جوهريًّا في هيمنة جدران الحماية فهو أنّها تحصر الأمنَ في مكانٍ مركزي، فتسحب الأمنَ فعليًّا من بقية الشبكة. فبإمكان مدير النظام إدارةُ جدار الحماية لتوفير الأمن، ممّا والتطبيقات الموجودة داخل الجدار من هموم الأمن — على الأقلّ بعضَ أنواع هموم الأمن. وكما أشرنا في مطلع الفصل، فإنّ التشفيرَ والمصادقةَ يوفّران حمايةً محدودةً ضدّ استغلال الأخطاء في أنظمة تشغيل المضيفات.

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

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

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

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

ومن المقاربات المستعملة لكشف البرمجيات الخبيثة البحثُ عن مقاطعَ من شيفرةِ برمجيةٍ خبيثةٍ معروفة، تُسمّى أحيانًا توقيعًا (signature). ولكلّ هذه المقاربة تحدّياتُها الخاصة، إذ يمكن للبرمجيات الخبيثة المصمَّمةِ بذكاء أن تعدّل تمثيلَها بصورٍ متنوّعة. كما أنّ إجراءَ هذا الفحص الدقيق للبيانات الداخلة إلى الشبكة قد يؤدّي إلى أثرٍ محتملٍ في أداء الشبكة.

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

9.3 جدران الحماية الموزّعة

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

ولأنّ جدارَ حمايةِ المحيط (perimeter firewall) لا يرشّح الحركةَ بين الآلات الواقعة على الجانب نفسه منه، فقد أتاح ذلك مجموعةً من الهجمات التي تستغلّ الحركةَ الجانبية (lateral movement). وتتمثّل الفكرةُ الأساسية في أنّ المهاجمَ يحصل على موطئِ قدمٍ في نظامٍ واحدٍ داخل الجدار، ثمّ يستعمله مطيّةً للانطلاق، حتى يبلغ في النهاية هدفَه النهائي. وقد لا يكون النظامُ الأولي الذي يخترقه المهاجم مهمًّا بدرجةٍ خاصة. فقد يحصل على الوصول مثلًا عبر هجوم تصيّدٍ أو باستغلال ثغرةٍ في نظام التشغيل. لكنّ جدارَ الحماية عديمُ الفائدة عند هذه النقطة، فيستطيع المهاجم أن يبدأ البحثَ عن طرقٍ للانتقال من نظامٍ إلى آخر داخل جدار الحماية، حتى يبلغ في النهاية آلةً تهمّه، مثلَ آلةٍ تحتفظ ببياناتٍ حسّاسة. وهذه الأنواعُ من هجمات الحركة الجانبية شديدةُ الانتشار وقد وُثِّقت جيّدًا، وكثيرًا ما تستمرّ شهورًا قبل أن تُكتشف.

يبدو الحلُّ البديهيّ لمشكلات الحركة الجانبية هو جدرانُ الحماية الداخلية. لكنّ مثل هذا الحلّ يطرح مجموعةً جديدةٍ من التحدّيات. فكّر في المثال في الشكل 34، حيث نُشر جدارُ حمايةٍ واحدٌ لترشيح تدفّقاتِ الحركة بين مجموعةٍ من الآلات الافتراضية في مركز بيانات.

لنفترض أنّ الحركةَ المرسلةَ من الآلة الافتراضية A إلى الآلة الافتراضية C تحتاج إلى المعالجة عند جدار الحماية. ولضمان ترشيحها، يجب أن تُوجَّه الحركةُ عبر مسارٍ يمرّ بجدار الحماية، لا بالضرورة عبر أقصر مسارٍ من A إلى C. وفي الحالة الأشدّ، وهي الحركةُ من الآلة الافتراضية A إلى الآلة الافتراضية B، تقع الآلتان الافتراضيتان على المضيف نفسه، فيجب أن تُرسَل الحركةُ من A إلى B خارج المضيف، وعبر الشبكة إلى جدار الحماية، ثمّ تعود إلى B. ومن البديهيّ أنّ هذا غيرُ فعّال، ويستهلك مواردَ داخل الشبكة وعند واجهة الشبكة بسبب الحركة التي انعطفت على شكل مشطِفٍ. فضلًا عن ذلك، يمكن أن يصبح جدارُ الحماية نفسه عنقَ زجاجة، إذ يجب أن تمرّ كلُّ الحركة التي تحتاج إلى ترشيحٍ إلى ذلك الجهاز المركزي.

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

الشكل 34. جدارُ حمايةٌ واحدٌ في مركز بياناتٍ مجهَّزٍ بالافتراضية.

أمّا حلُّ المشكلاتِ الكثيرة مع جدران الحماية الداخلية فقد ظهر بوصفه إحدى مزايا افتراضية الشبكة، وهي جدرانُ الحماية الموزّعة. ويوضّح الشكل 35 تنفيذًا لجدران حمايةٍ موزّعة. وفي هذه الحالة، يمكن أن تعالج الحركةُ المرسلةُ من الآلة الافتراضية A إلى الآلة الافتراضية C دالّةُ جدار حمايةٍ عند أحد المبدّلين الافتراضيين (أو كليهما) التي تعبرها، مع بقائها مُرسَلةً عبر أقصر مسارٍ في طبقة الشبكة السفلية (network underlay) بين المضيفين، دون انعطافٍ شعريٍّ إلى جدار حمايةٍ مركزي. فضلًا عن ذلك، لا تحتاج حركةُ الآلة الافتراضية A إلى الآلة الافتراضية B إلى مغادرة المضيف الذي تقيم عليه الآلتان إطلاقًا، إذ تمرّ فقط عبر المبدّل الافتراضي على ذلك المضيف لتحصل على المعالجةُ اللازمة من جدار الحماية.

ومن الآثارِ الجانبية المهمّة لتوزيع خدمةٍ بهذه الطريقة انعدامُ عنقِ الزجاجة المركزي. فكلّما أُضيف خادمٌ آخر إلى مضيفٍ لاستضافة عددٍ من الآلات الافتراضية، وُجد مبدّلٌ افتراضيٌّ جديدٌ له قدرةٌ على إجراء قدرٍ من المعالجة الموزّعة. وهذا يعني أنّ توسيعَ كمّيةِ الترشيح بجدران الحماية على هذا النحو يبقى بسيطًا نسبيًّا.

الشكل 35. يُنفَّذ جدارُ حمايةٍ موزَّعٌ بوصفه جزءًا من المبدّل الافتراضي في كلّ مضيفٍ في مركز البيانات.

وهناك تفصيلٌ مررنا عليه حتى الآن، وهو أنّ جدارَ الحماية الموزّع يحتاج إلى ضبطٍ ما. فضبطُ سياسات جدار الحماية في كلِّ مبدّلٍ افتراضيٍّ في أنحاء مركز البيانات لأمرٌ غيرُ عملي. ولهذا ظهرت جدرانُ الحماية الموزّعة بوصفها إحدى مزايا الشبكات المُعرَّفة ببرمجيات (software-defined networks). ويوفّر مُتحكّمُ SDN نقطةً مركزيةً للسيطرة الإدارية على سياسات جدار الحماية، بينما يتوزّع تنفيذُ قواعد الترشيح على المبدّلات الافتراضية. وهكذا، مثلًا، يمكن صياغةُ قاعدةٍ تحدّد كيفية ترشيح الحركة من الآلة الافتراضية A إلى الآلة الافتراضية B أمام مُتحكّم SDN، الذي يحسب بعدها كيفية إنشاء قواعد الترشيح منخفضة المستوى لدفعها إلى المبدّلات الافتراضية المناسبة. ويستطيع مُتحكّم SDN أيضًا أن يراعي أحداثًا مثل نقلِ آلةٍ افتراضيةٍ من موضعٍ إلى آخر، أو إضافةِ آلةٍ افتراضيةٍ جديدةٍ تتطلّب تركيبَ قواعدِ جدار حمايةٍ إضافية.

ويُشار غالبًا إلى النهج الموصوف أعلاه بأنّه التقسيمُ الدقيق (micro-segmentation). فعلى النقيض من مقاربات جدران الحماية التقليدية التي توفّر مقاطعَ شبكيةً كبيرةً فيها وصولٌ غيرُ مقيّدٍ بين جميع الأجهزة في المقطع، فإنّ التقسيمَ الدقيق ينشئ شبكاتٍ افتراضيةً صغيرةً ومحدَّدةَ بدقّةٍ تربط الأنظمةَ التي يلزمها الاتصالُ فقط كي تقدّم خدمةً أو وظيفةً بعينها.

وللمزيد من التفاصيل عن افتراضية الشبكة والخدمات الموزّعة، نوصي بكتابنا المكمِّل عن الشبكات المُعرَّفة ببرمجيات.

قراءات إضافية

L. Peterson وC. Cascone وB. O’Connor وT. Vachuska وB. Davie. الشبكات المُعرَّفة ببرمجيات: مقاربةُ نظام.

9.4 أمنُ الثقة الصفرية

وكما أشرنا أعلاه، فإنّ جدرانَ الحماية التقليدية تعاني ضعفًا جوهريًّا: فهي تحاول تقسيمَ الشبكة إلى مناطقَ «موثوقة» و«غير موثوقة». فإذا تمكّن المهاجمُ من إيجاد طريقةٍ للحصول على وصولٍ داخل المنطقة الموثوقة، ربما باختراق قطعةِ برمجياتٍ مشروعةٍ تعمل على الجانب الموثوق من الجدار، فإنّه يجد عندئذٍ مجموعةً كبيرةً من الآلات يستطيع أن يشنّ عليها هجماتٍ إضافيةً من دون اعتراض. ويتنافر هذا الحال مع بعض مبادئ الأمن التي عرضناها في الفصل 2، ولا سيّما مبدأ أقلّ الامتياز. فالآلةُ الموجودة على الجانب الموثوق من جدار حمايةٍ ما تملك غالبًا وصولًا إلى مواردَ أكثرُ بكثير — آلاتٍ وبياناتٍ أخرى — ممّا يلزم لأداء عملها. ومن أبرز المقاربات لتحسين هذا الحال ما يُعرف بـ«أمنِ الثقة الصفرية» (zero trust security).

لقد استُعمل مصطلحُ «الثقة الصفرية» (zero trust) لعقود، لكنّه بدأ في الانتشار الواسع نحو عام 2009 بمساعدة شركة التحاليل Forrester. وتتمثّل الفكرةُ المركزية خلف الثقة الصفرية في أنّ كلّ جهازٍ وكلّ مستخدمٍ ينبغي، افتراضيًّا، أن يكون غيرَ موثوق. فعلى كلّ مستخدمٍ وجهازٍ أن يصحّح هويّته كي يحصل على وصولٍ إلى مجموعةٍ دقيقةٍ من الخدمات. ولا توجد سياسةٌ عامّةٌ من نوع «اثق بهذا الجهاز لوصوله إلى كلّ شيء». وتقف الثقةُ الصفرية في مقابل نموذج «أمنِ المحيط» (perimeter security) القديم الذي يفترض وجودَ منطقةٍ موثوقةٍ داخل محيطٍ محميٍّ بجدران حماية ومنطقةٍ غيرِ موثوقةٍ خارج ذلك المحيط.

والثقةُ الصفرية مقبولةٌ بما يكفي لأنّ NIST قد ألّف مواصفةً (انظر قراءات إضافية أدناه) توفّر هذا التعريفِ المفيد:

«الثقةُ الصفرية… صارت المصطلحَ المستعملَ لوصف حلولٍ أمنيةٍ سيبرانيةٍ متنوّعةٍ نقلت الأمنَ بعيدًا عن الثقة الضمنية المبنيّة على موقع الشبكة، وركّزت بدلًا من ذلك على تقييم الثقة لكلِّ معاملةٍ على حدة.»

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

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

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

ويوفّر مثالُ VPN أعلاه مبرِّرًا لمقاربةٍ مختلفةٍ في التعامل مع المستخدمين والأجهزة الواقعة خارج أسوار المكتب التقليدي وخارج دفاعاتِ المحيط. ومن المقاربات المعروفةِ والشاملة لإعادة التفكير في نموذج دفاعِ المحيط و VPN نظامُ BeyondCorp من جوجل، الموصوفٌ في ورقةٍ علميةٍ عام 2014 في قسم قراءات إضافية أدناه. وهو مقاربةٌ تُستعمل لتنفيذ الثقة الصفرية في جوجل للموظفين الذين يصلون إلى مواردَ مؤسسية، وفي الوقت نفسه خدمةٌ يمكن للمؤسسات تنفيذُها بأنفسها.

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

ومن الجوانب المركزية في BeyondCorp أنّ «الأجهزة المُدارة» فقط هي التي تحصل على الوصول إلى الموارد المحمية. وجميعُ هذه الأجهزة المُدارة تُمنح شهاداتِها الخاصة كي تتمكّن من التصديق. وقبل الاتصال بأيّ خدمةٍ داخل المؤسسة، يتّصل الجهازُ بوكيلٍ (proxy) قادرٍ على إجراء التصديق. وبعد أن يُصادَق على الجهاز، على المستخدم أيضًا أن يصحّح هويّته باستعمال المصادقة ثنائية العامل (two-factor authentication)، وتُستهلَك صلاحياتُ وصولِ المستخدم من قاعدة بيانات. وهكذا، قد تكون للمهندسين، مثلًا، حقوقُ وصولٍ إلى الأنظمة الهندسية مثل مستودعات الشيفرة، لكنّ ليس إليهم الوصولُ إلى الأنظمة المالية أو أنظمة الموارد البشرية. ولا يُنشَأ الاتصالُ بين العميل والخادم إلّا بعد اجتياز كلّ هذه الفحوص — تصديقُ الجهاز، وتصديقُ المستخدم، وتفويضُ المستخدم. وقد تشمل فحوصُ الجهاز، إلى جانب التحقّق من شهادة الجهاز، التحقّقَ أيضًا من أنّ نظامَ تشغيله محدَّثٌ أو أنّه يحمل برمجياتَ حمايةٍ من الفيروسات مناسبةً مثبَّتة.

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

قراءات إضافية

S. Rose وO. Borchert وS. Mitchell وS. Connelly. بنيةُ الثقة الصفرية. NIST، 2020.

C. Cunningham. نظرةٌ إلى الوراء على الثقة الصفرية: لا تثق أبدًا، تحقّق دائمًا. Forrester، 2020.

R. Ward وB. Beyer. BeyondCorp: مقاربةٌ جديدةٌ لأمنِّ المؤسسات. ‏;login:‏، Usenix، 2014.

9.5 كشفُ التسلّل ومنعه

كما قدّمناه في مطلع هذا الفصل، فإنّ أجهزةَ الأمن (security appliances) تعميمٌ لجدران الحماية. وتُوضَع هذه الأجهزةُ في أنحاء الشبكة، تراقبُ الحركةَ غير المرغوبةَ وتستجيب لها. أمّا التحدّي الرئيسي الذي تواجهه هو كيفية التمييز بين الحركة الجيدة والسيّئة. ويتناول هذا القسم مثالَين: نظامَ كشف التسلّل (intrusion detection systems, IDS)، وأخاه نظامَ منع التسلّل (intrusion prevention systems, IPS).

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

ومن الأمثلة الجيدة على IPS نظامُ سنورت (Snort)، وهو مشروعٌ مفتوحُ المصدر نُشر لأوّل مرّة عام 1999، وبدأ حياته كنظام كشف تسلّل (IDS)، وصار اليوم مملوكًا لشركة Cisco. وفي صيغته الأصلية، كان سنورت يوفّر أداةً خفيفةً للترشيح والتقاط الحزم قائمةً على القواعد ومستندةً إلى مرشِّحات حزم بيركلي (Berkeley Packet Filters). والفكرةُ أنّ الهجمات، مثل الديدان، لها توقيعٌ يمكن التعرّفُ عليه — مثلًا تركيبةٌ معيّنةٌ من قيم الترويسات أو سلسلتُ بايتاتٍ فريدةٌ مُضمَّنةٌ في الحمولة — وأنّ نظام كشف التسلّل يمكن برمجتُه بقاعدةٍ تميّز حركةَ الهجوم وتُطلق تنبيهاتٍ حين يحدث ذلك. وكـ IPS، يتّخذ سنورت الآن خطوةً إضافيةً تتمثّل في حجزِ الهجوم.

قراءات إضافية

سنورت: نظامُ منع تسلّلٍ مفتوحُ المصدر (IPS).

مثل جدران الحماية، يحتاج نظاما IDS وIPS إلى رؤية كلِّ الحركة العابرة للشبكة إن كان لهما أن يكتشفا الهجمات، ولذلك فإنّ الوضعَ في مواضعَ استراتيجيةٍ مهمٌّ. ويؤدي ذلك إلى المخاوف ذاتها التي ناقشناها أعلاه بشأن الحركة شرق–غرب، ومن ثمّ فإنّ لهذه الأنظمة أيضًا نسخٌ موزّعة.

ولكي يكون نظامُ IDS/IPS الذي يستعمل توقيعاتِ الحزم فعّالًا، فلا بدّ من أن تكون مجموعةُ الهجمات المحتملة قد شوهدت في البيئة الحقيقيّة وحُلِّلت بحيث يمكن صياغةُ قواعدَ مناسبة. وتساعد مشاركةُ القواعد في مجتمعٍ من المستخدمين على تسريع هذه العمليّة، والنظمُ التجاريةُ من IDS/IPS تأتي عادةً مع اشتراكٍ في قواعد بياناتِ قواعدٍ تُحدَّث باستمرار. (وانظر موقع سنورت المذكور أعلاه بوصفه مثالًا لمجموعةِ قواعدٍ مجتمعية.)

ومن المقاربات الأخرى لاستعمال التوقيعات البحثُ عن شذوذٍ (anomalies) — أي أنماطٍ في سلوك الحركة تبدو مميّزةً عن «الطبيعي» ويمكن تصنيفُها هجماتٍ محتملة. ومن البديهيّ أنّ هذه المقاربة جذّابةٌ لأنّ الهجماتَ الجديدة يمكن اكتشافُها قبل أن تدخل قاعدةَ القواعد. أمّا الجزءُ الصعب فهو بلوغُ دقّةٍ عاليةٍ في الاكتشاف. ويعتمد كشفُ الشذوذ عادةً على خوارزمياتِ تعلّم الآلة لتصنيف الحركة على أنّها «طبيعية» أو «شاذّة». ولأنّ الكشفَ المعتمدَ على التوقيعات والكشفَ المعتمدَ على الشذوذ لكلٍّ منهما نقاطُ قوّةٍ وضعف، فإنّ من الشائع أن يُعثر على المقاربتين معًا في أنظمة IDS/IPS الحديثة.

ويؤكّد تكاثرُ أجهزة الأمن مجدّدًا مبدأَ الدفاع متعدّد الطبقات. فمثلًا، لو كان لدينا جدارُ حمايةٍ مثاليّ لما احتجنا إلى IDS أو IPS. لكنّ معرفةَ أنّ جدرانَ الحماية لن تحجب أبدًا جميع أشكال الحركة الخبيثة تقود إلى استنتاج أنّ وجود IDS/IPS يستحقّ بوصفه خطَّ دفاعٍ ثانٍ.