Product SiteDocumentation Site

فصل 14. الأمن

14.1. تحديد سياسة أمنية
14.2. الجدار الناري أو ترشيح الرزم
14.2.1. nftables Behavior
14.2.2. Moving from iptables to nftables
14.2.3. Syntax of nft
14.2.4. تثبيت القواعد عند كل إقلاع
14.3. الإشراف: المنع، والاكتشاف، والردع
14.3.1. مراقبة السجلات باستخدام logcheck
14.3.2. مراقبة النشاطات
14.3.3. Avoiding Intrusion
14.3.4. اكتشاف التغيُّرات
14.3.5. اكتشاف التطفل (IDS/NIDS)
14.4. مقدمة إلى AppArmor
14.4.1. المبادئ
14.4.2. تفعيل AppArmor وإدارة بروفايلاته
14.4.3. إنشاء بروفايل جديد
14.5. مقدمة إلى SELinux
14.5.1. المبادئ
14.5.2. إعداد SELinux
14.5.3. إدارة نظام SELinux
14.5.4. ملائمة القواعد
14.6. اعتبارات أمنية أخرى
14.6.1. المخاطر الملازمة لتطبيقات الوب
14.6.2. تَعرَّف على ما ينتظرك
14.6.3. اختيار البرمجيات بحكمة
14.6.4. إدارة الجهاز ككيان واحد
14.6.5. المستخدمين كفاعلين
14.6.6. الأمن الفيزيائي
14.6.7. المسؤولية القانونية
14.7. التعامل مع جهاز مُختَرَق
14.7.1. اكتشاف وملاحظة تطفل المخترقين
14.7.2. فصل المخدم عن الشبكة
14.7.3. الاحتفاظ بكل ما يمكن استخدامه كدليل
14.7.4. إعادة التثبيت
14.7.5. التحليل الجنائي
14.7.6. إعادة بناء سيناريو الهجوم
تختلف درجة أهمية النظام المعلوماتي حسب البيئة. في بعض الحالات، يكون النظام حيوياً لاستمرارية الشركة. ويجب حمايته إذن من مختلف المخاطر. تدعى عملية تقييم هذه المخاطر، وتعريف وتطبيق أساليب الحماية منها ”بالعملية الأمنية“.

14.1. تحديد سياسة أمنية

تغطي كلمة ”الأمن“ نفسها مجالاً واسعاً من المفاهيم، والأدوات والإجراءات، والتي لا يمكن تطبيق أي واحدة منها في جميع الحالات. تتطلب عملية اختيار واحدة منها فكرة دقيقة عن الأهداف المرجوة من حماية النظام. تبدأ عملية تأمين النظام بإجابة بعض الأسئلة. أما الاستعجال في تطبيق مجموعة عشوائية من الأدوات قد يؤدي إلى خطر التركيز على الناحية الأمنية غير المناسبة.
إذن أول الأشياء التي يجب تحديدها هو الهدف. من الأساليب الجيدة التي تساعد على تحديد هذا الهدف أسلوب يبدأ بطرح الأسئلة التالية:
  • ما الذي نحاول حمايته؟ تختلف السياسة الأمنية إذا كنا نريد حماية الحاسوب أو حماية البيانات. وإذا كنا نريد حماية البيانات، علينا أن نعرف أي بيانات هي المطلوب حمايتها.
  • ما الذي نريد أم نحتمي منه؟ هل هو تسريب البيانات السريّة؟ أم خسارة البيانات نتيجة الحوادث؟ أم خسارة أرباح نتيجة انقطاع الخدمة؟
  • وأيضاً، مَن الذي نحاول أن نحتمي منه؟ تختلف الإجراءات الأمنية كثيراً ما بين الحماية من خطأ فني بسيط يرتكبه أحد مستخدمي النظام المنتظمين وبين الحماية من مجموعة مهاجمين لهم أهداف محددة.
يستخدم المصطلح ”خطر risk“ عادة للإشارة إلى جميع هذه العوامل الثلاثة معاً: ما الذي نحميه، ما الذي يجب أن نمنع حدوثه، ومن الذي يحاول أن يجعل ذلك يحدث. يجب إجابة هذه الأسئلة للوصول إلى نموذج الخطر (risk model). واعتماداً على نموذج الخطر هذا، يمكن بناء سياسة أمنية، ويمكن تطبيق هذه السياسة بتدابير صارمة.
يجدر أيضاً أخذ القيود الإضافية بعين الاعتبار، إذ أنها تحدُّ مجال السياسات المتاحة. كم ننوي أن نبذل في سبيل حماية النظام؟ هذا السؤال يؤثر بشكل كبير على السياسة المتبعة. غالباً ما تُعرف إجابة هذا السؤال من النواحي المالية فقط، لكن هناك عناصر أخرى يجب أخذها بعين الاعتبار أيضاً، مثل درجة الإزعاج التي سوف تُفرَض على مستخدمي النظام أو مدى تراجع مستوى الأداء.
بعد نمذجة الخطر، يمكن البدء بالتفكير بتصميم سياسة أمنية فعلية.
في معظم الحالات، يمكن تقسيم النظام المعلوماتي إلى مجموعات فرعية مستقلة ومتماسكة. لكل نظام فرعي متطلباته وقيوده الخاصة، وبالتالي يجب تقييم المخاطر وتصميم سياسة أمنية لكل واحد منها بشكل منفصل. هناك مبدأ جيد لحفظه في ذاكرتك، هو أن حماية خندق قصير وحصين أسهل من حماية جبهة طويلة ملتفة. يجب تصميم بنية الشبكة وفق هذا المبدأ: يجب تركيز الخدمات الحساسة على عدد قليل من الأجهزة، ويجب أن يكون الوصول لهذه الأجهزة عبر أقل عدد ممكن من نقاط المرور؛ فحماية نقاط المرور هذه ستكون أسهل من حماية جميع الأجهزة الحساسة من الهجمات التي ترد من جميع أنحاء العالم الخارجي. تظهر هنا فائدة فلترة الشبكات (عبر الجدران النارية وغيرها). يمكن تطبيق هذه الفلترة باستخدام معدات خاصة، لكن لعل الحل الأبسط والأكثر مرونة استخدام جدار ناري برمجي مثل الجدار المدمج في النواة لينكس.