أول عشر خطوات لتأمين مؤسسة صغيرة

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

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

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

وسوف نناقش في هذا المقال ما يلي:

• لماذا الترتيب بالأثر، وما الذي يهدد مؤسسة صغيرة فعلاً (لا ما تخافه الأخبار).
• الخطوات العشر واحدة واحدة: الجرد، والمصادقة الثنائية، والنسخ الاحتياطي، والتحديث، وإغلاق المكشوف، وأقل صلاحية، والتوعية، وتقسيم الشبكة، والسجلات، وخطة الاستجابة.
• تجربة عملية: سكربت فحص على خادم Debian في المختبر، قبل الإصلاح وبعده.
• كيف تربط الخطوات بالأطر: ضوابط CIS والضوابط الأساسية NCA ECC.
• أخطاء شائعة، وخطة لأول ثلاثين يوماً.

لماذا الترتيب بالأثر لا بالثمن؟

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

ولاحظ في الصورة أن خطوات قليلة تتكرر في سد تهديدات كثيرة: المصادقة الثنائية تسد التصيد وسرقة الحساب، والنسخة الاحتياطية تسد الفدية والخطأ البشري والعطل، والتحديث يسد الثغرات والفدية معاً. وهذه الخطوات القليلة عالية المردود هي ما تبدأ به، لأنها تغطي أكثر ما قد يصيبك بأقل جهد ومال. وهذا بالضبط منطق ما يسمى مجموعة التطبيق الأولى Implementation Group 1 في ضوابط CIS، وهي الحد الأدنى من الحماية الأساسية للمؤسسات الصغيرة، والتي بنينا عليها هذه الخطوات. ولتفهم لماذا هذا الترتيب، انظر إلى الخطوات على محورين: كم تكلف، وكم أثرها. والصورة التالية تضعها على هذين المحورين:

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

الخطوة 1: اعرف ما تملك (الجرد)

لا تستطيع أن تحمي ما لا تعرف أنه موجود، ولذلك فأول خطوة هي جرد الأصول Asset Inventory، وهي أول ضابط في CIS وأول مكونات الدفاع في الضوابط الأساسية. والجرد في شركة صغيرة لا يحتاج أداة، وإنما جدولاً فيه: كل جهاز (حاسب الموظفين، الخوادم، الراوتر)، وكل خدمة (المتجر، البريد، التخزين السحابي، حسابات التواصل)، وكل مجموعة بيانات مهمة (قاعدة العملاء، الملفات المالية)، ولكل سطر مالكه، والبيانات التي عليه، ومدى أهميته. والفائدة مزدوجة: تعرف ما تحميه، وتكتشف غالباً أشياء نسيتها، كخادم تجريبي قديم ما زال يعمل ومكشوف، أو حساب موظف غادر الشركة قبل سنة. وهذا الجرد هو الأساس الذي تبنى عليه كل خطوة بعده، فالتحديث يحتاج أن تعرف ما تشغله، وإغلاق المكشوف يحتاج أن تعرف ما هو مكشوف.

ولا تنس نوعاً من الأصول يغفل عنه الجميع: الأصول التي لا تملكها لكنها تحمل بياناتك، أي مزودو الخدمات. فبريدك على خدمة سحابية، ومتجرك قد يعتمد على مزود استضافة، وبياناتك قد تمر عبر شركاء. وكل مزود باب محتمل، ولذلك اجعل في جردك عموداً لمزودي الخدمات: من يملك وصولاً إلى بياناتك، وما الذي يصل إليه، وماذا يحدث لو اخترق هو. وهذا ما يسميه الإطار إدارة مزودي الخدمة Service Provider Management، وهو ضابط مستقل في CIS، ومهم في المؤسسات الصغيرة تحديداً لأنها تعتمد على مزودين أكثر من اعتمادها على بنية تحتية خاصة. والجرد ليس عملاً يفعل مرة ويترك: راجعه كل ربع سنة وعند كل تغيير كبير، لأن الأصول تتغير، والخادم الذي أضفته الشهر الماضي لا يعرف عنه جرد كتب قبل سنة.

الخطوة 2: فعل المصادقة الثنائية MFA

إن لم تفعل إلا شيئاً واحداً، فليكن هو هذا. فالمصادقة الثنائية تجعل كلمة المرور المسروقة وحدها غير كافية للدخول، وهي أرخص ضابط يوقف أكثر الهجمات شيوعاً: التصيد وسرقة الحساب. وقد رأينا في مقال أشهر الهجمات حادثة Snowflake التي أصابت 165 جهة، وكان السبب الأول فيها أن الحسابات لم تكن عليها مصادقة ثنائية. فعلها اليوم على البريد أولاً (لأنه مفتاح استعادة كل شيء آخر)، ثم على الحسابات الإدارية، ثم على كل ما يدعمها. وفضل التطبيقات ومفاتيح المرور Passkeys على رموز الرسائل القصيرة SMS التي يمكن اعتراضها، وهو ما شرحناه في مقالات مرحلة كلمات المرور. والسبب أن رمز الرسالة القصيرة يمكن سرقته بطريقتين: اعتراض الرسالة، أو هجوم تبديل الشريحة الذي ينقل رقمك إلى شريحة يملكها المهاجم، بينما مفتاح المرور مربوط بجهازك والنطاق الحقيقي فلا ينفع على موقع مزيف. ومع ذلك، لا تجعل البحث عن أفضل نوع ذريعة للتأجيل: رمز الرسالة القصيرة خير من لا شيء بكثير، فابدأ بأي نوع متاح اليوم، ثم ارتق إلى الأقوى تدريجياً. ولا يكلفك هذا شيئاً تقريباً، فأغلب الخدمات تدعمه مجاناً، والعائق الوحيد هو أن تقرر وتطبق.

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

الخطوة 3: انسخ احتياطياً، واختبر الاستعادة

النسخة الاحتياطية هي ما يحول الفدية والخطأ البشري والعطل من كارثة إلى توقف مؤقت. لكن ليست كل نسخة تنفع: النسخة التي يصل إليها الخادم المصاب يحذفها المهاجم أو يشفرها أول ما يدخل، ولذلك يجب أن تكون نسخة معزولة Offline وغير قابلة للتعديل Immutable. والقاعدة المعروفة هي 3-2-1: ثلاث نسخ، على وسيطين مختلفين، واحدة منها خارج الموقع، كما تبين الصورة التالية:

وأهم ما في هذه القاعدة النسخة المعزولة: نسخة لا يصل إليها الخادم الحي ولا الحساب الذي يديره، فإذا أصيب الخادم وانتشرت الفدية، لا تجدها لتحذفها. والأهم من أخذ النسخة أن تختبر الاستعادة منها: النسخة التي لم تجرب استعادتها ليست نسخة، وإنما وعد لم يختبر، وكثير من الجهات اكتشفت أن نسخها لا تستعيد في اليوم الذي احتاجتها فيه. وقبل أن تبني النسخ، اسأل سؤالين يحددان شكلها: كم بيانات تقبل أن تخسر؟ وكم وقتاً تقبل أن تتوقف؟ الأول يسمى هدف نقطة الاستعادة RPO، ويحدد كل كم تأخذ نسخة: إن كنت تقبل خسارة يوم عمل فنسخة يومية تكفي، وإن كان كل ساعة مهمة فتحتاج نسخاً أكثر تواتراً. والثاني يسمى هدف زمن الاستعادة RTO، ويحدد كيف تخزن النسخ وتختبرها: إن كنت تحتاج العودة خلال ساعة فلا يكفي أن تكون النسخة على قرص بعيد يستغرق نقله يوماً. والإجابة عن السؤالين تختلف بين متجر يبيع كل دقيقة وأرشيف يراجع شهرياً، ولذلك لا توجد نسخة احتياطية واحدة تناسب الجميع، وإنما تبنيها على ما تقبل خسارته فعلاً. وقد شرحنا كيف تبني نسخاً بقاعدة 3-2-1 وتختبر الاستعادة في مقال مستقل:

دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.

الخطوة 4: حدث كل شيء

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

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

الخطوة 5: أغلق ما لا تحتاجه

كل خدمة تعمل، وكل منفذ مفتوح، وكل حساب نشط، باب محتمل. وتقليل هذه الأبواب يسمى تقليص سطح الهجوم Attack Surface Reduction: أغلق المنافذ التي لا تحتاجها، وأوقف الخدمات التي لا تستخدمها، واحذف الحسابات القديمة، وأزل البرامج التي لم تعد تعمل بها. والسؤال الذي تسأله عن كل شيء: هل أحتاج هذا مكشوفاً للإنترنت فعلاً؟ فقاعدة البيانات مثلاً يجب ألا تكون مكشوفة للإنترنت أبداً، وإنما يصل إليها التطبيق فقط من الداخل. وهذه الخطوة تطبق الضابط الرابع في CIS، الإعداد الآمن Secure Configuration، وسوف نراها عملياً في المختبر حين نكتشف خدمة مكشوفة ونقيدها.

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

الخطوة 6: حساب لكل شخص، وأقل صلاحية

الحسابات المشتركة عدو الأمن: حين يستخدم خمسة موظفين حساب admin واحد، لا تعرف من فعل ماذا، ولا تستطيع أن تغلق وصول من غادر دون أن تقطع البقية. فأعط كل شخص حسابه، وطبق مبدأ أقل صلاحية Least Privilege: لكل حساب الصلاحيات التي يحتاجها لعمله فقط، لا أكثر. فموظف خدمة العملاء لا يحتاج صلاحية حذف قاعدة البيانات، والمحاسب لا يحتاج صلاحية إدارة الخادم. وراجع الصلاحيات دورياً، واحذف ما لم يعد مستخدماً، وأغلق حسابات المغادرين فوراً. وهذا الضابط (إدارة الحسابات والوصول) هو الخامس والسادس في CIS، وإدارة الهوية والوصول بعمق موضوع مقال IAM وPAM، وإدارة كلمات المرور المشتركة في خزنة بدل ملف Excel موضوع مقال إدارة كلمات المرور.

وأخطر أنواع الصلاحيات هي الصلاحيات المميزة Privileged Access: حسابات المدير التي تملك كل شيء، وصلاحية root على الخوادم. فهذه إذا سرقت أعطت سيطرة كاملة، ولذلك تعامل معها بحذر خاص: قلل عدد من يملكها، ولا تستخدمها للعمل اليومي بل للمهام الإدارية فقط، وسجل استخدامها. ومن الأخطاء الشائعة أن يعمل الموظف طوال اليوم بحساب يملك صلاحية المدير «حتى لا يضطر لطلبها كل مرة»، فإذا أصيب جهازه أصيب كل شيء معه. والصحيح أن يعمل بحساب عادي، ويرفع صلاحيته للمهمة التي تحتاجها فقط ثم يعود. وأهم عادة عملية: اجعل إغلاق حساب من يغادر الشركة جزءاً من إجراء المغادرة نفسه، لا شيئاً يؤجل، فالحسابات المنسية لمن غادروا من أكثر أبواب الاختراق التي تجدها في أي تدقيق.

الخطوة 7: درب موظفيك

رأينا أن ثلاثاً من أشهر أربع هجمات تستهدف الإنسان لا الآلة، فالعنصر البشري Human Element هو أوسع سطح هجوم عندك وأرخص دفاع عنه. لكن المحاضرة السنوية الواحدة لا تغير السلوك، والفعال برنامج توعية مستمر: رسائل قصيرة دورية، وتدريب على التعرف على التصيد، وزر إبلاغ سهل، وثقافة لا تلوم من يبلغ عن خطئه. والقياس هنا نسبة من يبلغ عن الرسالة المشبوهة، لا نسبة من ينقر فقط. ولا يحتاج هذا ميزانية كبيرة، فمحتوى التوعية متوفر بتراخيص مفتوحة، وقد شرحنا كيف تبني برنامجاً متكاملاً بأدوات مفتوحة المصدر في مقال برنامج التوعية، وكيف تختبر وعي فريقك بمحاكاة تصيد مصرح بها في مقال GoPhish.

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

الخطوة 8: قسم شبكتك

في شبكة مسطحة يصل كل جهاز إلى كل جهاز، فكاميرا مخترقة تصل إلى قاعدة بياناتك، وجهاز ضيف مصاب يصل إلى خوادمك. وتقسيم الشبكة Network Segmentation يمنع ذلك بفصل الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به: شبكة للضيوف منفصلة، وشبكة لأجهزة إنترنت الأشياء، وشبكة للخوادم، وشبكة لأجهزة الموظفين. فإذا أصيب جهاز في منطقة لم يصل الضرر إلى البقية، وهذا ما يقطع الحركة الجانبية Lateral Movement التي تستخدمها الفدية للتمدد. وفي شركة صغيرة يكفي للبداية فصل شبكة الضيوف وأجهزة إنترنت الأشياء عن شبكة العمل، وهو ما يدعمه أغلب أجهزة الراوتر. وتقسيم الشبكة بالتفصيل موضوع مقال تقسيم الشبكة.

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

الخطوة 9: فعل السجلات وراقبها

كل ما سبق يقلل احتمال الاختراق، لكن لا يلغيه، ولذلك تحتاج أن تعرف أن شيئاً حدث. وهذا ما تفعله السجلات Logs: تسجل من دخل ومتى، وما طلب، وما فشل. وفعل السجلات على الخوادم والتطبيقات والبريد، واجمعها في مكان مركزي لا يستطيع المهاجم حذفه، وراجعها، ولو مرة في اليوم في البداية. ولاحظ أن أخطر ما في حادثة Equifax التي ذكرناها سابقاً أن جهاز المراقبة كان متوقفاً 19 شهراً، فبقي المهاجمون 76 يوماً دون أن يلاحظهم أحد. والسجل الذي لا يقرؤه أحد لا يختلف كثيراً عن غيابه، ولذلك المهم ليس جمع السجلات فقط، بل أن ينظر فيها إنسان. وسوف نرى في المختبر كيف تقرأ سجل خادم وتلخصه بأدوات بسيطة، وبناء مراقبة أعمق موضوع مراحل لاحقة في المسار.

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

الخطوة 10: اكتب خطة استجابة

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

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

ما الذي لا تحتاجه بعد؟

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

تجربة عملية: افحص خادمك وأصلحه

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

سكربت الفحص

احفظ الملف التالي باسم audit.sh:

#!/bin/sh
# Read-only posture check for a small-org server, mapped to the first security steps.
pass=0; warn=0
ok(){ echo "  [ OK ]  $1"; pass=$((pass+1)); }
bad(){ echo "  [WARN]  $1"; warn=$((warn+1)); }

echo "== Step 1-2: what is exposed (services listening on all interfaces) =="
EXP=$(ss -ltnH 2>/dev/null | awk '$4 ~ /0\.0\.0\.0|\[::\]|\*/ {print $4}')
if [ -z "$EXP" ]; then ok "no service is reachable from outside the host"
else echo "$EXP" | sed 's/^/    exposed: /'; bad "$(echo "$EXP" | wc -l) service(s) reachable from any network"; fi

echo "== Step 3: patch management (pending updates) =="
UPG=$(apt-get -s upgrade 2>/dev/null | grep -c '^Inst')
[ "$UPG" -eq 0 ] && ok "no pending package updates" || bad "$UPG packages need updating"

echo "== Step 4-5: accounts (login-capable, empty passwords) =="
LOGINS=$(grep -E ':/bin/(ba)?sh$' /etc/passwd | cut -d: -f1 | tr '\n' ' ')
echo "    accounts with a login shell: ${LOGINS:-none}"
EMPTY=$(awk -F: '($2==""){print $1}' /etc/shadow 2>/dev/null | tr '\n' ' ')
[ -z "$EMPTY" ] && ok "no accounts with an empty password" || bad "empty password: $EMPTY"

echo "== Step 6: least privilege (only root is uid 0) =="
ROOT0=$(awk -F: '($3==0){print $1}' /etc/passwd | tr '\n' ' ')
[ "$ROOT0" = "root " ] && ok "only root has uid 0" || bad "extra uid-0 accounts: $ROOT0"

echo "== Step 7-config: world-writable files under /etc =="
WW=$(find /etc -xdev -type f -perm -0002 2>/dev/null | wc -l)
[ "$WW" -eq 0 ] && ok "no world-writable files under /etc" || bad "$WW world-writable file(s) under /etc"

echo
echo "== scorecard: $pass OK / $warn to fix =="

ولماذا نبني سكربتاً بدل أن نفحص يدوياً؟ لثلاثة أسباب تطبق روح الخطوات نفسها: الأول أن الفحص اليدوي ينسى، فالسكربت يفحص الأشياء كلها في كل مرة دون أن يسهو. والثاني أنه قابل للتكرار، فتشغله كل أسبوع فتعرف هل تغير شيء، وهذا هو جوهر المراقبة. والثالث أنه يترك ناتجاً مكتوباً تحتفظ به دليلاً على حالتك عبر الزمن، وهو ما يطلبه أي مدقق. وقد بنيناه بأبسط الأدوات (shell وawk وgrep) لا بأداة متخصصة، لأن الهدف أن تفهم ما يقيسه لا أن تثق بصندوق أسود. وفي السكربت أعلاه لاحظ أن كل فحص يقابل خطوة من الخطوات: المنافذ المكشوفة (الخطوتان 1 و5)، والتحديثات (الخطوة 4)، والحسابات وكلمات المرور الفارغة (الخطوتان 4 و5)، وصلاحيات root (الخطوة 6)، والملفات التي يكتبها الجميع (الإعداد الآمن). وكلها قراءة من ملفات النظام وأوامر Linux الأساسية التي شرحناها في مقال ما تحتاجه قبل الأمن.

قبل: خادم ضعيف

نبني خادماً فيه عيوب شائعة عمداً: حساب إضافي بصلاحية root، وحساب بكلمة مرور فارغة، وملف إعداد يكتبه الجميع، وخدمة مكشوفة على كل الشبكات:

docker run -d --name lab-srv debian:13-slim sleep 900
docker exec lab-srv sh -c '
  apt-get update -qq; apt-get install -y -qq iproute2 python3 procps
  useradd -o -u 0 -m backupadmin                 # حساب ثان بصلاحية root
  useradd -m -s /bin/bash shared; passwd -d shared  # حساب بكلمة مرور فارغة
  chmod 0666 /etc/motd                           # ملف يكتبه الجميع
  nohup python3 -m http.server 8080 &'           # خدمة مكشوفة على 0.0.0.0

ثم ننسخ السكربت إليه ونشغله:

docker cp audit.sh lab-srv:/audit.sh
docker exec lab-srv sh /audit.sh

والمخرج سوف يكون كما يلي:

== Step 1-2: what is exposed (services listening on all interfaces) ==
    exposed: 0.0.0.0:8080
  [WARN]  1 service(s) reachable from any network
== Step 3: patch management (pending updates) ==
  [ OK ]  no pending package updates
== Step 4-5: accounts (login-capable, empty passwords) ==
    accounts with a login shell: root backupadmin shared
  [WARN]  empty password: shared
== Step 6: least privilege (only root is uid 0) ==
  [WARN]  extra uid-0 accounts: root backupadmin
== Step 7-config: world-writable files under /etc ==
  [WARN]  1 world-writable file(s) under /etc

== scorecard: 1 OK / 4 to fix ==

أربع علامات تحذير، وكل واحدة منها باب دخول حقيقي: الخدمة المكشوفة يصل إليها أي أحد، والحساب بكلمة مرور فارغة يدخله أي أحد، والحساب الثاني بصلاحية root يعطي سيطرة كاملة، والملف الذي يكتبه الجميع قد يعدله مهاجم ليرفع صلاحياته. وأي واحدة منها قد تكفي وحدها لاختراق المؤسسة.

بعد: نطبق الإصلاحات

الآن نطبق الخطوات بأوامر بسيطة: نوقف الخدمة المكشوفة ونعيد تشغيلها مقيدة بالعنوان المحلي فقط، ونحذف الحساب الزائد بصلاحية root، ونقفل الحساب ذا كلمة المرور الفارغة ونزيل الشل عنه، ونصحح صلاحيات الملف:

docker exec lab-srv sh -c '
  pkill -9 -f "http.server"; sleep 1
  nohup python3 -m http.server 8080 --bind 127.0.0.1 &   # مقيدة بالعنوان المحلي
  userdel -f backupadmin                                 # حذف الحساب الزائد
  passwd -l shared; usermod -s /usr/sbin/nologin shared  # قفل الحساب وإزالة شله
  chmod 0644 /etc/motd'                                  # تصحيح الصلاحيات
docker exec lab-srv sh /audit.sh

== Step 1-2: what is exposed (services listening on all interfaces) ==
  [ OK ]  no service is reachable from outside the host
== Step 3: patch management (pending updates) ==
  [ OK ]  no pending package updates
== Step 4-5: accounts (login-capable, empty passwords) ==
    accounts with a login shell: root
  [ OK ]  no accounts with an empty password
== Step 6: least privilege (only root is uid 0) ==
  [ OK ]  only root has uid 0
== Step 7-config: world-writable files under /etc ==
  [ OK ]  no world-writable files under /etc

== scorecard: 5 OK / 0 to fix ==

والصورة التالية تجمع المقارنة:

في المقارنة أعلاه لاحظ التالي:

• الإصلاحات كلها أوامر بسيطة لا تكلف مالاً: لا أداة اشتريناها، ولا ميزانية صرفناها، وإنما قرار وتطبيق. وهذا جوهر رسالة المقال: أغلب أمن المؤسسة الصغيرة قرار لا شراء.
• تقييد الخدمة بالعنوان المحلي 127.0.0.1 يطبق الخطوة الخامسة: ما لا يحتاج أن يكون مكشوفاً للإنترنت لا يكون مكشوفاً.
• حذف الحساب الزائد بصلاحية root وقفل الحساب الفارغ يطبقان الخطوة السادسة: حساب لكل شخص بأقل صلاحية، لا حسابات زائدة أو مفتوحة.
• السكربت نفسه يصلح أن يكون أداة دورية: شغله على خوادمك كل أسبوع لتعرف هل ظهر شيء جديد مكشوف، وهذا يطبق الخطوة التاسعة (المراقبة) بأبسط صورة.

وبعد التجربة ننظف المختبر:

docker rm -f lab-srv

وتأمل في هذه التجربة درساً أكبر من السكربت نفسه: كل حادثة أمنية كبيرة قرأت عنها بدأت بواحدة من هذه العلامات الأربع، خدمة مكشوفة أو كلمة مرور ضعيفة أو حساب زائد الصلاحية أو إعداد خاطئ. فالاختراقات المعقدة التي تملأ الأخبار غالباً ما تبدأ من خطأ بسيط كهذه، ثم يبني المهاجم عليه. وهذا يعني أن إغلاق هذه الأبواب البسيطة، وهو ما فعلناه في دقائق، يقطع الطريق على أغلب ما قد يصيبك قبل أن يبدأ. ولاحظ أيضاً أن الأمن ليس حالة تصل إليها مرة وتنتهي: شغلنا الفحص، وأصلحنا، لكن غداً قد يفتح موظف منفذاً، أو يضاف حساب، أو يظهر تحديث معلق، ولذلك يعاد الفحص دورياً. الأمن عملية مستمرة Process لا منتج Product تشتريه مرة، وهذه هي الفكرة التي تميز من يبقى آمناً عمن يؤمن نفسه مرة ثم ينسى.

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

ربط الخطوات بالأطر: CIS وNCA ECC

هذه الخطوات العشر ليست اجتهاداً، وإنما ملخص عملي لأطر معروفة. فضوابط CIS الثمانية عشر ترتبها في مجموعات تطبيق، ومجموعتها الأولى IG1 هي بالضبط الحد الأدنى للمؤسسات الصغيرة، وتغطي الجرد (الضابطان 1 و2) وحماية البيانات (3) والإعداد الآمن (4) وإدارة الحسابات والوصول (5 و6) وإدارة الثغرات (7) والسجلات (8) وحماية البريد (9) ومكافحة البرمجيات الخبيثة (10) والنسخ الاحتياطي (11) والتوعية (14). والجدول التالي يربط خطواتنا بها وبالضوابط الأساسية السعودية، ليطمئنك أنك حين تطبق خطة بسيطة مفهومة لا تبتعد عن المعايير، بل تبني أساسها:

ولاحظ أنك حين تطبق الخطوات العشر تكون قد غطيت جزءاً كبيراً من الحد الأدنى في الإطارين معاً، دون أن تبدأ بقراءة مئات الضوابط. وحين تحتاج الامتثال الكامل للضوابط الأساسية، تكون قد بنيت الأساس، وشرح قراءة الضوابط كاملة في مقال الضوابط الأساسية NCA ECC.

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

أخطاء شائعة Common Mistakes

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

خطة لأول ثلاثين يوماً

• الأسبوع الأول: اكتب الجرد (الخطوة 1)، وفعل المصادقة الثنائية على البريد والحسابات الإدارية (الخطوة 2).
• الأسبوع الثاني: أنشئ نسخة احتياطية معزولة واختبر استعادة ملف منها (الخطوة 3)، وفعل التحديثات التلقائية (الخطوة 4).
• الأسبوع الثالث: شغل سكربت الفحص على خوادمك، وأغلق ما هو مكشوف، واحذف الحسابات القديمة (الخطوتان 5 و6).
• الأسبوع الرابع: أرسل أول رسالة توعية (الخطوة 7)، وافصل شبكة الضيوف (الخطوة 8)، وفعل السجلات (الخطوة 9)، واكتب خطة استجابة في صفحة (الخطوة 10).

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

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

الخلاصة

وصلنا لنهاية الموضوع، وقد رأينا أن تأمين مؤسسة صغيرة لا يحتاج ميزانية كبيرة، وإنما ترتيباً وانضباطاً. وأهم ما يجب أن تتذكره:

• ابدأ بالأعلى أثراً لا بالأغلى ثمناً: المصادقة الثنائية والنسخة الاحتياطية والتحديث تغطي أكثر ما قد يصيبك.
• لا تحمي ما لا تعرف أنه موجود، فالجرد أول خطوة لكل ما بعده.
• النسخة الاحتياطية تنفع إذا كانت معزولة ومختبرة، وإلا فهي وعد لم يختبر.
• أغلب أمن المؤسسة الصغيرة قرار لا شراء: رأينا بطاقة قياس تنتقل من أربع مخاطر إلى صفر بأوامر بسيطة.
• الخطوات العشر تغطي الحد الأدنى في ضوابط CIS والضوابط الأساسية NCA ECC معاً.
• فعل السجلات واكتب خطة استجابة، فالمنع وحده لا يكفي، وتحتاج أن تعرف وأن تتعافى.
• الأمن عملية مستمرة لا منتج تشتريه مرة: راجع خطواتك العشر كل ربع سنة، فما يفعل مرة ويترك يتآكل.

تدريب عملي Practice

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتشغيل سكربت الفحص على حاوية debian:13-slim قبل الإصلاحات وبعدها (من 1 سليم و4 للإصلاح إلى 5 سليم و0 للإصلاح) ثم إزالتها.