كيفية بناء تدابير أمنية قوية لحماية خوادمك

مقدمة

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

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

مفاتيح SSH (Secure Shell)

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

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

تعزيز الأمان باستخدام مفاتيح SSH

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

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

تطبيق مفاتيح SSH

يجب أن يستخدم تسجيل الدخول إلى أي خادم Linux عن بعد مفاتيح SSH. يمكن توليدها على جهازك المحلي، مع نقل المفتاح العام إلى الخادم في غضون دقائق. من خلال هذا البرنامج التعليمي، ستحصل على فكرة أساسية حول كيفية استخدام SSH للاتصال بخادم عن بعد في Ubuntu. يمكنك أيضاً متابعة برنامجنا التعليمي المتعمق حول كيفية تهيئة خادم Linux الخاص بك لاستخدام المصادقة القائمة على مفتاح SSH.

بشكل عام، يعد عدم السماح للمستخدم الجذر (root) بتسجيل الدخول مباشرة عبر SSH ممارسة فضلى شائعة الاستخدام، في حين يتم تسجيل الدخول كمستخدم غير متميز واستخدام أداة مثل sudo لترقية الامتيازات حسب الحاجة. يُعرف هذا بمبدأ الامتياز الأقل: وهو طريقة للحد من أذونات الوصول. بمجرد التحقق من تسجيل الدخول كحساب غير متميز باستخدام SSH، يمكن تعطيل تسجيل دخول الجذر عن طريق تعيين التوجيه PermitRootLogin no في الملف /etc/ssh/sshd_config على الخادم الخاص بك. بعد ذلك، يمكن إعادة تشغيل الخادم باستخدام أمر عملية SSH وهو sudo systemctl restart sshd.

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

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

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

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

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

تعزيز الأمان باستخدام جدار الحماية

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

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

تنفيذ جدران الحماية

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

• بالنسبة لنظام CentOS، يمكنك اتباع دليلنا لـ إعداد جدار حماية باستخدام FirewallD على CentOS 7.
• دليلنا لـ Iptables يمكنه إرشادك خلال عرض وحذف قواعد جدار حماية Iptables.

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

شبكات السحابة الخاصة الافتراضية (VPC)

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

تعزيز الأمان باستخدام شبكات VPC

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

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

الاستفادة من التدقيق لتعزيز الأمن

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

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

• هل يجب أن تكون الخدمة المعينة قيد التشغيل بنشاط؟
• هل تعمل على واجهات الشبكة المثلى؟
• هل الخدمة هي الأنسب لواجهة شبكة عامة أم خاصة؟
• هل تم تكوين قواعد جدار الحماية بشكل صحيح للسماح بحركة المرور المشروعة إلى هذه الخدمة؟
• هل يتم حظر حركة المرور غير المشروعة باستخدام قواعد جدار الحماية الخاص بي؟
• هل هناك نظام تنبيه بشأن الثغرات الأمنية مُمكّن؟

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

إجراء عمليات تدقيق الخدمات

من أجل تدقيق الخدمات قيد التشغيل، استخدم الأمر ss لسرد جميع منافذ UDP و TCP المستخدمة بنشاط على الخادم. فيما يلي مثال على استخدام الأمر ss مع اسم برنامج PID، للتحقق من منافذ TCP و UDP التي تستمع:

سيتم إرجاع شيء مشابه لما يلي:

يجب أن ينصب تركيزك الأساسي على أعمدة Netid و Local Address:Port و Process:

• إذا كانت قيمة Local Address:Port هي 0.0.0.0 فهذا يعني أن الخدمة تقبل بنشاط جميع الاتصالات عبر جميع واجهات شبكة IPv4. وإذا كان العنوان هو [::] فإن جميع اتصالات IPv6 تقبل حركة المرور.
• في المثال أعلاه، يستمع كل من Nginx و SSH عبر جميع الواجهات العامة على كلا مكدسي الشبكات (IPv4 و IPv6).

باستخدام المثال أعلاه، يمكنك اختيار ما إذا كنت بحاجة إلى السماح لـ SSH و Nginx بالاستماع على الواجهتين، أو على إحداهما فقط. بشكل عام، قد ترغب في تعطيل أي خدمات غير مستخدمة لمنعها من العمل. على سبيل المثال، إذا كان موقعك يجب أن يكون متاحًا فقط من خلال IPv4، فسيكون من المفيد إيقاف تشغيل واجهات IPv6 للحد من التعرض.

مواكبة التحديثات غير المراقبة

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

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

كيفية تفعيل التحديثات غير المراقبة

أصبحت التحديثات غير المراقبة الآن ميزة اختيارية في معظم توزيعات الخوادم. على سبيل المثال، في Ubuntu، يمكن للإدارة تشغيل الأمر التالي:

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

فهارس الدلائل

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

زيادة الأمان من خلال تعطيل فهارس الدلائل

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

تعطيل فهارس الدلائل

في معظم الحالات، تكفي إضافة سطر واحد إضافي فقط إلى تكوين خادم الويب الخاص بك لتعطيل فهارس الدلائل.

• اتبع هذه الخطوات لتعطيل قوائم الدلائل هذه على Apache Wiki. تأكد من إدراج Options -Indexes في كتل تكوين Apache Directory.
• يتم تعطيل الفهارس افتراضيًا على Nginx، مما لا يتطلب أي إجراء إضافي في هذا الصدد.

النسخ الاحتياطي المتكرر

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

تعزيز الأمان من خلال النسخ الاحتياطي المتكرر

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

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

تنفيذ النسخ الاحتياطي المتكرر

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

إليك بعض النقاط الأخرى التي يجب مراعاتها عند التفكير في خطة التعافي من الكوارث:

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

لمعرفة المزيد حول حلول التعافي من الكوارث من CloudSigma، راجع منشور مدونتنا الذي يوضح بالتفصيل لماذا تعد خدمة التعافي من الكوارث كخدمة (Disaster-Recovery-as-a-Service) الرفيق المثالي للسحاب. وهنا يمكنك معرفة المزيد عن ميزات الأمان & استمرارية الأعمال من CloudSigma. لدينا أيضًا دليل مفصل حول كيفية إعداد وظيفة النسخ الاحتياطي من CloudSigma بسهولة.

الشبكات الخاصة والشبكات الافتراضية الخاصة (VPNs)

الشبكة الخاصة هي شبكة متاحة فقط للوصول والاستخدام من قبل مستخدمين أو خوادم معينين. والاتصال الآمن بين الأجهزة البعيدة الذي يتيح للاتصال بالعمل كما لو كان في شبكة خاصة هو VPN (شبكة افتراضية خاصة). وهي توفر لك القدرة على تأمين الاتصالات في شبكة خاصة وتوصيل الخوادم البعيدة.

كيف تعزز الشبكات الخاصة الأمان؟

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

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

ما مدى صعوبة تنفيذ VPN؟

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

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

تشفير SSL/TLS والبنية التحتية للمفاتيح العامة

يُشار إلى إنشاء الشهادات وإدارتها والتحقق من صحتها لتحديد هوية الأفراد وتشفير الاتصالات باسم البنية التحتية للمفاتيح العامة (PKI). يمكن للكيانات المختلفة مصادقة بعضها البعض باستخدام شهادات SSL أو TLS . بعد ذلك، يمكن استخدامها أيضًا لإنشاء اتصال مشفر.

كيف تعزز الشهادات الأمان

من أجل تشفير حركة المرور والتحقق من هويات الأعضاء على الخادم، من الضروري إنشاء سلطة شهادات (CA) والقدرة على رؤية جميع شهادات شبكتك. يمكن أن يساعد هذا في منع هجمات 'رجل في المنتصف' (man-in-the-middle)، والتي يقوم فيها مخترق بتقليد الخادم وإعادة توجيه حركة المرور بعيدًا.

يمكن ضبط تكوين كل خادم للوثوق بسلطة شهادات (CA) مركزية. ويمكن بعد ذلك الوثوق بأي توقيعات شهادات لاحقة بشكل ضمني. إذا كان تشفير SSL/TLS مدعومًا بواسطة البروتوكولات والتطبيقات التي يستخدمها خادمك، فيمكنك تأمين نظامك دون أعباء نفق VPN الإضافية. لمزيد من المعلومات، اتبع البرنامج التعليمي الخاص بنا حول كيفية أتمتة تجديدات شهادات LetsEncrypt SSL لـ Nginx.

صعوبة التنفيذ

يمكن أن يكون هناك الكثير من الجهد الأولي في تكوين سلطة الشهادات ثم إعداد الـ PKI المتبقي. أيضًا، عندما يلزم إنشاء شهادات جديدة أو إلغاؤها أو توقيعها، فسيتطلب ذلك جهدًا إداريًا إضافيًا.

نظرًا لأن معظم البنى التحتية تحتاج إلى النمو، فإن تنفيذ PKO كامل هو النهج الأكثر منطقية. وإلى أن تصل إلى نقطة تستحق فيها الـ PKI تكاليف الإدارة الإضافية، فإن استخدام VPN لتأمين مكونات النظام يمكن أن يكون بمثابة إجراء مؤقت كافٍ.

كشف اختراق النظام واستخدام تدقيق الملفات

تدقيق الملفات هو عملية تُستخدم لمقارنة ملفات نظامك وخصائصها في حالة جيدة وآمنة تمامًا بتلك الموجودة في نظامك حاليًا. هذه طريقة جيدة للعثور على تغييرات النظام غير المصرح بها وعزلها.

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

تعزيز الأمان عبر IDS/تدقيق الملفات

أبعد من مجرد التدقيق على مستوى الخدمة، فإن إجراء عمليات تدقيق على مستوى الملف أمر ضروري لضمان أمن نظامك. يمكن القيام بذلك إما عن طريق عملية IDS مؤتمتة أو بشكل دوري بواسطة مسؤول النظام.

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

مستوى صعوبة التنفيذ

يمكن أن يكون تنفيذ IDS وتدقيق الملفات عملية مكثفة للغاية. في البداية، يجب تكوين النظام لتحديد المسارات المراد استبعادها وتحديد التغييرات غير القياسية التي تم إجراؤها على النظام من أجل إنشاء قراءة مرجعية أساسية للنظام.

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

في حين أن هذا يزيد بالتأكيد من العبء الإداري لنظامك، إلا أنه أحد الطرق المضمونة الوحيدة لضمان عدم تعديل أي من الملفات دون علمك. بعض أشهر أنظمة كشف التسلل وتدقيق الملفات هي Aide و Tripwire.

البيئات المعزولة

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

قد يعني هذا أن مكونات تطبيق معينة سيتم استضافتها على خوادم مخصصة لها، أو أنه قد يتم تكوين خدماتك للعمل في بيئات chroot (أو الحاويات). يعتمد مدى عزل البيئة في الغالب على واقع بنيتك التحتية ومتطلبات تطبيقك.

تعزيز الأمان باستخدام البيئات المعزولة

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

صعوبة التنفيذ

تختلف درجة تعقيد عزل تطبيقاتك بناءً على أنواع الاحتواء التي قررت استخدامها. لا يعتبر Docker العزل ميزة أمنية. ومع ذلك، عندما يتم تقسيم مكوناتك بين حاويات مختلفة، يتم تحقيق العزل بسهولة أكبر بكثير. يمكنك اتباع هذا البرنامج التعليمي لتثبيت Docker على بنيتنا التحتية.

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

أفكار نهائية

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

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

حوسبة سعيدة!