تاريخ عملي لجدار الحماية - الجزء الثاني: قيمة الإدارة

جودي برازيل، الرئيس التنفيذي لشركة FireMon لقد انتصرت Check Point وجدران الحماية ذات الفحص الحالتي في المعركة المبكرة ضد جدران الحماية الوكيلة (الجزء الأول: الأيام الأولى). من السهل الافتراض بأن الأمر كان متعلقًا بتقنية الفحص وحدها، لكن ذلك يغفل ابتكارًا أساسيًا في حل Check Point، وهو إدارة السياسات. إن تفوّق جدران الحماية ذات الفحص الحالتي على المنافسين من جدران الحماية الوكيلة في منتصف التسعينيات يعود، إلى حدّ كبير، إلى سهولة الإدارة. يركّز جزء كبير من هذه المقالة على Check Point. ويرجع ذلك أساسًا إلى الدور المهيمن الذي لعبته Check Point في سوق جدران الحماية في أواخر التسعينيات وأوائل الألفية الثانية. غير أنه يرجع على الأرجح أيضًا إلى احتكاكي بـ Check Point في تلك السنوات. وأرحّب بوجهة نظركم وأتطلع إلى تعليقاتكم. كان منتصف التسعينيات وقتًا تتطور فيه الشبكات بوتيرة سريعة. فعلى سبيل المثال، كانت الإيثرنت خيارًا متاحًا، لكنها لم تكن دائمًا بروتوكول الشبكة المحلية المستخدم (هل تذكرون token ring؟). ولم يكن الاتصال بالإنترنت أمرًا مفروغًا منه، بل كان موضعًا للنقاش. وكان الاتصال الهاتفي لا يزال شائعًا، وكانت AOL هي اللاعب المهيمن. والقول بأن جدران الحماية كانت تقنية سائدة يعني إساءة فهم كون الإنترنت نفسه سائدًا. ومن تبعات هذه الشبكة سريعة التغير قدر كبير من الجهل وقلة الخبرة. وفي هذا السياق، ينبغي عدم إغفال قابلية إدارة جدار الحماية باعتبارها محركًا رئيسيًا للسوق ساهم في تحديد الفائز النهائي فيه. اليوم، نتحدث في تطوير البرمجيات عن تجربة المستخدم وسهولة الاستخدام. ورغم أن هذه لم تكن المصطلحات الرائجة آنذاك، فإن السبب الذي يجعلنا نتحدث عنها اليوم كان له القدر نفسه من الأهمية حينها. فقد كان العملاء "يفضّلون" المنتج أكثر. ولذلك، ومع أن الأمان والأداء كانا مهمين، فإن سهولة استخدام واجهة جدار الحماية الرسومية من Check Point لا ينبغي التقليل من شأنها. وكما قال أحد مندوبي مبيعات Gauntlet في ذلك الوقت: "لم يكن يهم من هو العميل المحتمل؛ في كل حساب دخلته كان عليّ أن أواجه واجهة Check Point الرسومية - وعادةً ما كنت أخسر." أطلقت Check Point جدار الحماية الخاص بها مع إدارة مركزية وواجهة مستخدم مبتكرة للغاية. وشملت بعض القدرات الرئيسية ما يلي:

• محرر قواعد رسومي
• مستودع كائنات مركزي مشترك بين سياسات جدار الحماية
• تسجيل مركزي
• الإدارة متعددة النطاقات وOPSEC

محرر السياسات من Check Point

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

مستودع الكائنات المركزي من Check Point

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

التسجيل المركزي

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

الإدارة متعددة النطاقات وOPSEC

في أوائل الألفية الثانية، ضاعفت Check Point رهانها على قوة الإدارة بطرح الإدارة متعددة النطاقات عبر Provider-1 وواجهات برمجة التطبيقات للتكامل عبر OPSEC. وكان كلاهما رهانًا كبيرًا على قوة الإدارة لتمييز Check Point عن منافسيها في مجال جدران الحماية - وقد نجح ذلك. وكان Provider-1، كما يوحي اسمه، موجهًا إلى مجتمع مزوّدي الخدمة، وشركات الاتصالات ومزوّدي الخدمات المُدارة. ومع أن مزوّدي الخدمة كانوا من أوائل المتبنّين لهذه التقنية، سرعان ما وجدت المؤسسات أسبابًا لاستخدام المنتج أيضًا. وكانت القدرات الرئيسية، بما فيها التحكم في الأذونات، وتحسين أداء الإدارة وواجهة المستخدم عبر تجزئة السياسات وقواعد بيانات الكائنات الكبيرة، والقواعد العامة التي يمكن تطبيقها وفرضها على المستوى الشامل، كلها ميزات أساسية تطلبها المؤسسات الكبيرة. وكانت هذه في جزء كبير منها قيودًا في منصة الإدارة القياسية. ومع أن البعض قد يجادل بأنه كان على Check Point إصلاح منصة الإدارة بدلًا من مطالبة العملاء بدفع علاوة كبيرة مقابل Provider-1، فقد رأى العملاء الفوائد وكانوا على استعداد للدفع مقابل قدرات الإدارة المتقدمة هذه. أما OPSEC فكان برنامج شراكة ومجموعة من واجهات برمجة التطبيقات أصدرتها Check Point لتشجيع تكامل منتجات الأطراف الثالثة. وشملت النجاحات المبكرة منتجات إعداد التقارير التي استخدمت واجهة تصدير السجلات (LEA)، ومنتجات تصفية عناوين URL التي استخدمت بروتوكول تصفية عناوين URL (UFP)، ومنتجات الإدارة، مثل FireMon، التي استخدمت واجهة إدارة Check Point ‏(CPMI). وقد حقق البرنامج وعمليات التكامل نجاحًا هائلًا. واليوم، هناك أكثر من 100 شريك في OPSEC يقدمون قدرات تكامل مع المنصة. وتمنح هذه المنظومة من المنتجات الأمنية العملاء قيمة مضافة وثقة في استثماراتهم. واليوم، نعتبر تكاملات واجهات برمجة التطبيقات أمرًا بديهيًا، لكن في عام 2001 عند إطلاق OPSEC لم تكن شائعة إلى هذا الحد.

Cisco وسطر الأوامر لاعب مهيمن

لم تكن Check Point والواجهة الرسومية تهيمنان على السوق بالكامل. فبينما رسّخت Check Point مكانتها كشركة رائدة في سوق جدران الحماية بواجهة رسومية قوية وسهلة الاستخدام، ظلت Cisco وفيّة لجذورها بواجهة سطر الأوامر (CLI) في Pix. وكان Pix منافسًا مبكرًا في سوق جدران الحماية، يعود تاريخه إلى عام 1994 واستحوذت عليه Cisco في عام 1995. وقد جعلت ألفة مسؤولي الشبكات مع Cisco وسطر الأوامر من Pix الخيار المفضل عندما كان فريق الشبكة مسؤولًا عن الأمن. وأخذت Check Point تقلّص هذه الميزة تدريجيًا بفضل ميزاتها الأمنية وواجهتها الرسومية، مدعومةً بتحوّل بطيء في الهيكل التنظيمي للمؤسسات حيث أصبح الأمن مجموعة منفصلة عن فريق الشبكة. ومع حدوث هذا التحول، تراجع دور العلاقة القائمة بين Cisco وفريق الشبكة في اختيار مورّد جدار الحماية. لقد ساعدت قدرات الإدارة المحسّنة في ترسيخ موقع Check Point في السوق وعززت قيمة الإدارة بالنسبة لمنتجات الأمن. لكن، مثلما ساعد الأداء Check Point على التغلب على جدران الحماية الوكيلة في التسعينيات، فإن الأداء سيعود في السنوات التالية ليكون معيارًا أساسيًا في القرار، وهذه المرة ستكون Check Point مهددة. الجزء الثالث: الأداء يتصدر المشهد