افهم مخاطر السياسات. اطرح أسئلتك حول السياسات بلغة طبيعية. اطلب عرضًا توضيحيًا ←
Published:
يجب ألا يتحول الوصول المؤقت إلى سياسة firewall دائمة
تعرّفوا على سبب استمرار الوصول المؤقت عبر firewall بعد انتهاء الغرض منه، وكيف تسهم الملكية والمبرر وتواريخ انتهاء الصلاحية والمراجعات في ضبط القواعد المحددة زمنياً.
by FireMon
كثيرًا ما يتحوّل الوصول المؤقت إلى وصول دائم.
تُنشأ القاعدة من أجل مشروع أو مورّد أو عملية ترحيل أو طلب عاجل. في تلك اللحظة يعرف الجميع سبب وجودها. وبعد أشهر، يصبح العثور على هذا السياق أصعب بكثير.
من طلبها؟ ومن اعتمدها؟ وأي حاجة عمل كانت تخدمها؟ وهل لا يزال هذا الوصول مطلوبًا؟
ومن دون هذه المعلومات، قد يصعب تقييم قاعدة جدار حماية سليمة تقنيًا.
لهذا السبب تتطلب الإدارة الفعّالة للسياسات أكثر من معرفة ما تسمح به القاعدة. فالفرق بحاجة أيضًا إلى معرفة سبب وجود القاعدة ومن المسؤول عنها.
إضافة السياق ما دام القرار حديثًا
في الفيديو أعلاه، يوضّح Rob Rodriguez، المدير الأول لهندسة الميدان العالمية في FireMon، كيف يمكن للفرق توثيق سياق العمل الكامن خلف قاعدة جدار الحماية مباشرةً داخل Security Manager.
ويمكن أن يشمل هذا السياق معلومات مثل:
- مبرر العمل
- وحدة الأعمال
- مالك القاعدة
- مقدّم الطلب والجهة المعتمِدة
- معلومات ضبط التغيير
- تاريخ المراجعة التالية
- تاريخ انتهاء الصلاحية
يحمل المثال الذي يعرضه Rob التسمية "Temp Access"، وهو ما يسلّط الضوء على مشكلة شائعة في إدارة السياسات.
قد يكون الوصول المؤقت ضروريًا. لكن الخطر يبدأ عندما لا توجد آلية واضحة لتحديد موعد انتهائه.
يوفّر تاريخ انتهاء الصلاحية أو المراجعة المجدولة نقطة تحقّق. فبدلًا من الاعتماد على تذكّر أحدهم للطلب الأصلي بعد أشهر، تحمل السياسة نفسها المعلومات اللازمة لإعادة النظر في القرار.
تسهيل تقييم القواعد لاحقًا
يكشف التكوين التقني ما تفعله قاعدة جدار الحماية.
أما التوثيق فيكشف سبب وجودها.
ويزداد هذا التمييز أهمية مع اتساع البيئات وتغيّر الفرق.
فالمهندس الذي يراجع قاعدة بعد ستة أشهر من إنشائها قد لا يكون طرفًا في الطلب الأصلي. وقد يكون مالك التطبيق انتقل إلى دور آخر، وقد يكون المشروع انتهى، وقد تكون العلاقة مع المورّد لم تعد قائمة.
ومن دون معرفة المالك ومبرر العمل، يضطر الفريق إلى إعادة بناء تاريخ القاعدة قبل أن يتمكن من تحديد ما إذا كان الوصول لا يزال مناسبًا.
ويؤدي توثيق هذه المعلومات منذ البداية إلى تسهيل المراجعات المستقبلية إلى حد كبير.
فبدلًا من السؤال: "هل يعرف أحد الغرض من هذه القاعدة؟"، ينطلق المختصون من غرض موثّق ومالك محدد وجدول زمني للمراجعة.
تحديد تاريخ انتهاء للوصول المؤقت
تستحق القواعد المؤقتة اهتمامًا خاصًا لأن الغرض الأصلي منها يرتبط غالبًا بحدث أو فترة محددة.
قد يكون ذلك نافذة صيانة أو عملية ترحيل أو فترة اختبار أو تعاملًا مع طرف ثالث أو متطلب عمل قصير الأجل.
وإذا أُنشئت القاعدة دون تاريخ انتهاء أو عملية مراجعة، فقد يبقى الوصول قائمًا لفترة طويلة بعد زوال الحاجة الأصلية.
العملية الأفضل هي تلك التي تربط القاعدة التقنية بدورة حياتها من منظور العمل.
فعندما يكون للوصول مالك ومبرر وتاريخ مراجعة، يمتلك الفريق أساسًا واضحًا لتحديد ما إذا كان ينبغي الإبقاء عليه.
ولا يعني ذلك حذف كل قاعدة مؤقتة تلقائيًا عند حلول التاريخ المحدد، بل إيجاد نقطة مراجعة مقصودة بدلًا من ترك الوصول مستمرًا إلى أجل غير مسمى بشكل افتراضي.
تحويل قواعد جدار الحماية إلى قرارات خاضعة للحوكمة
تصبح إدارة سياسة جدار الحماية أسهل عندما تُعامَل القواعد كقرارات عمل لا كمجرد كائنات تكوين.
تساعد FireMon الفرق على ربط السياسة التقنية بمعلومات الملكية والمبرر والمراجعة اللازمة لإدارة هذا الوصول بمرور الوقت.
والنتيجة سجل أوضح لسبب وجود الوصول، وطريقة أكثر عملية لتحديد ما إذا كانت الحاجة إليه لا تزال قائمة.
فالسؤال لا يقتصر على ما إذا كانت القاعدة تعمل اليوم، بل ما إذا كانت المؤسسة ستظل تفهم هذا الوصول وتمتلكه وتحتاج إليه غدًا.
أدخِلوا سياق العمل إلى إدارة سياسات جدار الحماية. تعرّفوا على كيفية مساعدة FireMon Security Manager للفرق على فهم السياسة الأمنية وتوثيقها وحوكمتها عبر البيئات المعقدة.
الأسئلة الشائعة
يتحوّل الوصول المؤقت عبر جدار الحماية إلى وصول دائم عندما تُنشأ القاعدة دون مالك أو مبرر عمل أو تاريخ انتهاء أو تاريخ مراجعة. فعند إنشاء القاعدة يعرف الجميع سبب وجودها، لكن بعد أشهر قد يكون مقدّم الطلب قد انتقل إلى مكان آخر وقد يكون المشروع انتهى. وإذا لم يستطع أحد تأكيد ما إذا كان الوصول لا يزال مطلوبًا، تبقى القاعدة قائمة بشكل افتراضي.
عندما يستمر الوصول المؤقت، قد تكون قاعدة جدار الحماية سليمة تقنيًا ومع ذلك يصعب تقييمها. إذ ترى الفرق ما تسمح به القاعدة دون معرفة سبب وجودها أو المسؤول عنها، فيبقى الوصول قائمًا بعد زوال الحاجة الأصلية بوقت طويل. ويضطر المراجعون عندئذ إلى إعادة بناء تاريخ القاعدة قبل أن يتمكنوا من تحديد ما إذا كان الوصول لا يزال مناسبًا.
عادةً ما يخدم الوصول المؤقت عبر جدار الحماية حدثًا أو فترة محددة. ومن الأمثلة الشائعة: مشروع، أو نافذة صيانة، أو عملية ترحيل، أو فترة اختبار، أو تعامل مع طرف ثالث أو مورّد، أو طلب عاجل، أو متطلب عمل قصير الأجل. وبما أن الحاجة مرتبطة بذلك الحدث، فينبغي ربط دورة حياة القاعدة به أيضًا عبر تاريخ مراجعة أو تاريخ انتهاء.
وثّقوا مبرر العمل، ووحدة الأعمال، ومالك القاعدة، ومقدّم الطلب والجهة المعتمِدة، ومعلومات ضبط التغيير، وتاريخ المراجعة التالية، وتاريخ انتهاء الصلاحية. وتسجيل هذه التفاصيل ما دام القرار حديثًا يعني أن أي مراجِع مستقبلي سينطلق من غرض موثّق ومالك محدد بدلًا من إعادة بناء التاريخ. ويتيح FireMon Security Manager للفرق تسجيل سياق العمل هذا مباشرةً على قاعدة جدار الحماية.
يوفّر تاريخ الانتهاء أو المراجعة المجدولة نقطة تحقّق لا تعتمد على تذكّر أحدهم للطلب الأصلي. وعند حلول الموعد، يمنح مالك القاعدة ومبررها الفريقَ أساسًا واضحًا لتقرير ما إذا كان ينبغي إبقاء الوصول أو تعديله أو إزالته. ومن دون نقطة التحقّق هذه، يميل الوصول المؤقت إلى الاستمرار إلى أجل غير مسمى بشكل افتراضي.
ليس بالضرورة. توصي FireMon بالتعامل مع تاريخ الانتهاء كنقطة مراجعة مقصودة لا كمحفّز للحذف التلقائي. فقد تكون بعض صلاحيات الوصول لا تزال مطلوبة فعليًا، وإزالتها دون تحقق قد تعطّل العمل. والهدف هو ضمان اتخاذ قرار صريح بشأن كل قاعدة مؤقتة بدلًا من استمرارها لمجرد أن أحدًا لم ينظر فيها.
ابدأوا بأربعة أسئلة: من طلب هذه القاعدة؟ ومن اعتمدها؟ وأي حاجة عمل كانت تخدمها؟ وهل لا تزال تلك الحاجة قائمة؟ ثم تحققوا مما إذا كان المالك أو التطبيق أو المشروع أو العلاقة مع المورّد قد تغيّر. وإذا كانت القاعدة توثّق مبررها ومالكها وتاريخ مراجعتها، يمكن للفريق الإجابة بسرعة بدلًا من السؤال عمّا إذا كان أحد يعرف الغرض منها.
ابحثوا عن حل يربط سياق العمل بكل قاعدة، بما في ذلك المبرر ووحدة الأعمال والمالك ومقدّم الطلب والجهة المعتمِدة ومعلومات ضبط التغيير وتواريخ المراجعة وتواريخ الانتهاء. وينبغي أن يساعد الفرق على التعامل مع القواعد كقرارات عمل خاضعة للحوكمة ولها دورة حياة، لا كمجرد كائنات تكوين. ويدعم FireMon Security Manager توثيق هذا السياق على قواعد جدار الحماية بحيث يمكن للفرق إعادة النظر في الوصول المؤقت استنادًا إلى سجل واضح.