غالبًا ما نركز اهتمامنا على معرفة كيفية بناء التطبيق ونشره في البيئة السحابية، وقد نغفل دون قصد الإجراءات الأمنية الأساسية التي ينبغي علينا توفيرها على الخادم السحابي قبل نشر التطبيقات عليه وإتاحتها للعامة. سنشارك في هذا المقال بعض التوصيات التي يمكننا تنفيذها على الخادم لحمايته من الهجمات الإلكترونية وجعله بيئة آمنة للنشر. بالطبع لن تغني هذه التوصيات العامة عن التدابير المصممة خصيصًا للتطبيق والتي يمكن تنفيذها بعد النشر، لكنها تُعَدّ انطلاقة جيدة يمكن البناء عليها.
استخدام مفاتيح SSH
SSH هي اختصار لعبارة Secure Shell، وهو بروتوكول آمن ومُشفر للاتصال بالخوادم وإدارتها، وهو شائع الاستخدام فأي شخص يتعامل مع الخوادم سيقضي معظم وقته متصلًا بالخادم عبر جلسة اتصال طرفية terminal تستخدم برتوكول SSH، أما مفاتيح SSH أو SSH Keys فهي بديل آمن لعمليات تسجيل الدخول المستندة إلى كلمة مرور أي تلك التي تعتمد الاستيثاق بكلمة المرور، لأن هذه المفاتيح تستخدم التشفير لتأمين تسجيل الدخول إلى الخادم، وتُعَدُّ إجراءً ضروريًا يوصى به لجميع مستخدمي SSH.
لإجراء الاستيثاق authentication من خلال مفاتيح SSH نحتاج لتوليد مفتاحين، مفتاح عام public key مكن مشاركته مع الطرف الآخر، ومفتاح خاص private key سري يحتفظ به المستخدم ولا يشاركه مع أحد، تُسمى هذه الآلية التشفير غير المتماثل asymmetric encryption وقد تصادفنا في حالات استخدام أخرى.
بعد توليد مفتاح SSH العام ينبغي لنا وضعه على الخادم ضمن المسار المخصص له وهو عادةً المجلد ~/.ssh/authorized_keys، وبعدها يمكننا الاتصال بالخادم باستخدام مفاتيح SSH، ومعرفة المزيد عن الاستيثاق باستخدام كلمة المرور والاستيثاق باستخدام المفاتيح ننصح بمشاهدة الفيديو التالي:
كيف تعزز مفاتيح SSH أمان الاتصال مع الخادم
إن جميع أنواع الاستيثاق في SSH مُشفرة بالكامل حتى تلك المعتمدة على كلمات المرور فقط، لكن بالرغم من التشفير لن يُعدّ الاستيثاق باستخدام كلمة المرور آمنًا بما فيه كفاية، فالمخترق سيحاول تخمين كلمة المرور مرارًا وتكرارًا باستخدام برمجيات متخصصة وقد ينجح في كسرها والوصول إلى الخادم وخاصةً إذا كان للخادم عنوان IP عام، وعلى الرغم من إمكانية تقليل عدد المحاولات المتاحة أمام المخترق بضبط إعدادات الخادم ليمنع تلقائيًا الاتصالات الواردة من أي عنوان IP يجري عددًا معينًا من محاولات الاتصال الفاشلة، إلّا أن ذلك يبقى غير آمن تمامًا فترك الخادم عرضة لهجمات القوة الغاشمة brute force attacks يُعدّ خطرًا أمنيًا لا يستهان به.
وهنا تبرز أهمية الاستيثاق باستخدام مفاتيح SSH فهو يسمح بتعطيل الاستيثاق المستند إلى كلمة المرور ويلغي المخاطر المرتبطة به، وحتى إذا عينا كلمة مرور لمفتاح SSH الخاص بنا فإنها تُعدّ هدفًا صعب المنال في هجوم القوة الغاشمة بسبب عدد المحارف الكبير إذ يمكننا إنشاء تقطيع أو تجزئة hash بطول يصل إلى 128 محرف لمفتاح SSH ذو كلمة مرور بطول 12 محرف فقط،
ورغم أن التشفير يُستخدم لحماية كلمات المرور، إلا أن بعض خوارزميات التشفير ليست آمنة بالكامل. فبعضها يمكن اختراقه باستخدام تقنيات الهندسة العكسية، وذلك من خلال تحليل تجزئات كلمات المرور password hashes على أجهزة قوية لفترات طويلة حتى الوصول إلى كلمة مرور مطابقة. في المقابل، توجد خوارزميات أكثر أمانًا حتى الآن، مثل خوارزمية RSA الافتراضية التي تعتمدها تطبيقات SSH الحديثة.
تنفيذ الاستيثاق بمفاتيح SSH على الخادم
يوصى باستخدام مفاتيح SSH للاتصال عن بعد بأي خادم لينكس، ويمكنك تنفيذ ذلك بخطوتين: توليد زوج من مفاتيح SSH على الحاسوب المحلي باستخدام الأمر ssh وفق الخطوات الواردة في مقال العمل مع خواديم SSH: العملاء والمفاتيح، ثم نقل المفتاح العام public key إلى الخادم البعيد.
أما في أجزاء النظام التي تحتاج لاستخدام كلمة مرور أو التي تكون عرضةً لهجمات القوة الغاشمة brute force attacks فيمكن تنفيذ حلول مخصصة لذلك مثل استخدام Fail2ban للحد من محاولات تخمين كلمة المرور، ولمطالعة المزيد ننصح بمطالعة مقال كيفية حماية SSH باستخدام Fail2Ban على Ubuntu.
من ناحية أخرى يُعدّ عدم السماح لمستخدم الجذر root بتسجيل الدخول مباشرةً عبر SSH واحدًا من أفضل الممارسات الأمنية الموصى بها، وذلك طبقًا لمبدأ إعطاء الامتيازات الأقل فبدلاً من المستخدم root نسجل الدخول بمستخدم عادي لا يملك امتيازات عالية، ثم نرفع امتيازاته حسب الحاجة بواسطة أداة مثل sudo، ويمكن تطبيق ذلك كما يلي: بعد التأكد من الاتصال بالخادم وإنشاء حساب لا يتمتع بامتيازات عالية لكنه قادر على العمل مع SSH، يمكن تعطيل عمليات تسجيل الدخول بواسطة مستخدم الجذر عبر تعديل قيمة السطر الخاص بذلك ضمن الملف /etc/ssh/sshd_config على الخادم ليصبح PermitRootLogin no ثم نعيد تشغيل SSH باستخدام أمر مثل Sudo systemctl Restart sshd ليأخذ التعديل مفعوله.
الجدران النارية Firewalls
الجدار الناري Firewall هو تطبيق برمجي أو عتاد يتحكم بإتاحة الخدمات على الشبكة، وبأنواع حركة مرور البيانات المسموح لها بالدخول والخروج من وإلى خادم معين أو مجموعة خوادم معينة، وعند ضبطه بشكل صحيح، يعمل الجدار الناري على حماية النظام بفعالية، حيث يمنع أي اتصال وارد من خارج الشبكة ما لم يكن مصرحًا به، ولا يسمح إلا بالوصول إلى الخدمات المخصصة لذلك فقط.
تُصَنَّف الخدمات الموجودة على أي خادم تقليدي إلى الفئات التالية:
- خدمات عامة Public متاحة لأي شخص عبر الإنترنت مثل خوادم الويب
- خدمات خاصة Private محصورة بالاتصالات من مواقع محددة أو حسابات مصرح لها بالوصول مثل لوحات تحكم قواعد البيانات
- خدمات داخلية Internal غير متاحة للعامة وتقبل الاتصالات المحلية فقط، مثل قواعد البيانات المحلية
تتحكم الجدران النارية بالوصول إلى التطبيقات تبعًا للفئات المذكورة أعلاه، فتساعد على إتاحة الخدمات العامة للجميع عبر الإنترنت، وعلى تقييد الوصول إلى الخدمات الخاصة بناءً على معايير مختلفة مثل أنواع الاتصالات أو غيرها، بالإضافة إلى عزل الخدمات الداخلية تمامًا عن الإنترنت، وإغلاق المنافذ غير المستخدمة التي عادة ما تغلق في معظم إعدادات الحماية.
كيف يحمي الجدار الناري التطبيقات
لا غنى عن استخدام الجدار الناري لحماية الأنظمة البرمجية، حتى وإن كانت التطبيقات نفسها مزوّدة بميزات أمنية أو تقيّد الوصول إلى واجهات معينة فقط. فالجدار الناري يشكّل طبقة حماية أساسية تعمل على تصفية الاتصالات الواردة والصادرة، وتمنع حركة المرور غير المصرح بها من الوصول إلى التطبيق أساسًا، قبل معالجتها من قبل النظام أو الخوادم المعنية.
ويتحكم الجدار الناري المُعَدّ بطريقة سليمة بإمكانية الوصول إلى مكونات النظام الخاص بنا حسب طبيعة العمل، فلا يتيح الوصول لكل الخدمات والاتصالات على الخادم، بل يسمح بالوصول إلى خدمات معينة ويمنع الوصول إلى سواها، وذلك عبر فتح المنافذ ports الخاصة بها وإغلاق بقية المنافذ، مثلًا يمكن فتح المنفذ 22 لبروتوكول الاتصال SSH، والمنفذين 80 و 443 لخدمات الويب HTTP/HTTPS التي تعمل من المتصفح وغيرها، عمومًا كلما اختصرنا عدد المنافذ أو الخدمات المفتوحة كلما قللنا من الثغرات الأمنية التي يمكن أن يستغلها المخترق ومن احتمالية تعرضنا للهجمات الإلكترونية.
تشغيل الجدار الناري على الخادم
يوفر نظام لينكس أنواع متعددة من جدران الحماية تختلف عن بعضها في درجة التعقيد وطبيعة الحماية التي تؤمنها، وكل ما علينا هو فهمها وضبط إعداداتها بحسب خدماتنا ثم التعديل عليها مع أي تغيير تجريه على هذه الخدمات، ومن أشهر الخيارات المتاحة الجدار الناري غير المُعقَّد Uncomplicated Firewall -أو UFW اختصارًا- حيث يتوفر هذا النوع افتراضيًا على بعض توزيعات لينكس مثل أوبنتو، ويمكن إعداده بالرجوع إلى مقال كيف تضبط جدارًا ناريًا في أوبنتو باستخدام UFW ومقال أساسيات UFW: قواعد وأوامر شائعة للجدار الناري.
تحتفظ العديد من الجدران النارية البرمجية مثل UFW و firewalld بقواعدها rules ضمن ملف خاص يدعى iptables، ويمكن مطالعة المزيد عن هذا الموضوع بقراءة مقال كيفية إعداد جدار ناري باستخدام IPTables على Ubuntu 14.04، ومقال أساسيات IPTables - قواعد وأوامر شائعة للجدار الناري، إذ يساعد فهم iptables على التعامل مع حالات التعارض التي قد تنشأ من تسجيل بعض البرمجيات مثل Docker قواعدها الأمنية الخاصة بالتحكم بمنافذ الخادم ضمن الملف iptables إلى جوانب قواعد UFW المُسجلَّة فيه أيضًا.
ملاحظة:توفر العديد من شركات الاستضافة خدمة جدار ناري خارجي يمكن تفعيله أمام الخادم السحابي لحمايته، بدلًا من الاعتماد فقط على الجدار الناري الموجود داخل نظام التشغيل، وهذا النوع من الجدران النارية يُدار من خلال لوحة التحكم الخاصة بمزود الخدمة، وتختلف أدوات التحكم فيه وطريقة إعداده من مزود لآخر.
أهم ما يجب الانتباه إليه هو أن تكون الإعدادات الافتراضية للجدار الناري قائمة على مبدأ الحظر، أي أن يتم منع أي حركة مرور مجهولة أو غير مصرح بها بشكل تلقائي، فهذا الإجراء يحمي الخدمات الجديدة من الظهور على الإنترنت عن طريق الخطأ أو من أن تكون متاحة لأطراف غير مخولين. وعندما نقرر إطلاق خدمة جديدة، سيكون علينا حينها إعداد قواعد واضحة ومحددة في الجدار الناري تسمح بالوصول إليها وهذا يدفعنا بشكل طبيعي إلى التفكير المسبق في طريقة تشغيل الخدمة، وكيفية الوصول إليها، والتأكد من جميع الجوانب الأمنية قبل طرحها.
شبكات السحابة الافتراضية الخاصة VPC Networks
شبكات السحابة الافتراضية الخاصة Virtual Private Cloud -أو VPC اختصارًا- ههي شبكات مخصصة لربط موارد البنية التحتية في السحابة، وتوفر اتصالًا آمنًا ومعزولًا عن الإنترنت العام.
كيف تعزز شبكات VPC أمان نظامنا
عند حجز استضافة سحابية، يقوم بعض مزودي الخدمة بتخصيص واجهتين للشبكة تلقائيًا: واحدة عامة public network interface للتواصل مع الإنترنت، وأخرى خاصة private network interface للتواصل داخل الشبكة السحابية فقط. يمكننا تعطيل الواجهة العامة لبعض الخوادم والسماح لها بالتواصل فقط عبر الواجهة الخاصة. بذلك نحمي البيانات المتبادلة بين هذه الخوادم لأن الحركة لا تمر عبر الإنترنت العام، مما يقلل من خطر تعرضها للاختراق أو الكشف
يساعدنا الاستخدام المدروس لعدد بوابات الإنترنت أو بوابات الدخول ingress gateways التي تعد نقاط الاتصال الوحيدة بين موارد شبكتنا السحابية الخاصة VPC والإنترنت العام على مراقبة حركة المرور العامة التي تتصل مع الموارد والتحكم بها بأفضل طريقة ممكنة، وتتوافق بعض أنظمة تنسيق الحاويات الحديثة مثل Kubernetes جيدًا مع مفهوم بوابات الدخول فلها إعداداتها الخاصة في هذا المجال، إذ تنشئ العديد من واجهات الشبكة الخاصة افتراضيًا، ويعود القرار لنا بما نريد إتاحته أو الكشف عنه منها.
تطبيق شبكات VPC
يتيح العديد من مزودي الخدمات السحابية المتخصصين بخدمات البنية التحتية إمكانية إنشاء مواردنا الخاصة وإضافتها إلى شبكة VPC حسب ما نريد لكن بالطبع على أنظمتهم الأساسية وداخل مراكز بياناتهم، أما بناء شبكتك الخاصة من VPC يدويًا من دون أي مزود خدمة فهو أمرٌ صعب وبتطلب إعدادات ومزايا متقدمة على الخادم ومعرفة عميقة بالشبكات، لذا يمكن استخدام أحد بدائل VPC الموجودة في المتناول وهو إعداد اتصال VPN بين الخوادم كما سنشرح في فقرتنا التالية.
شبكات VPN والشبكات الخاصة
الشبكة الافتراضية الخاصة virtual private network -أو VPN اختصارًا- هي وسيلة لإنشاء اتصالات آمنة بين الحواسيب البعيدة تكافئ الاتصالات ضمن شبكة محلية خاصة local private network، يساعدك ذلك على إعداد خدماتك كما لو أنها في شبكة خاصة وأيضًا على الاتصال مع خوادمنا البعيدة بطريقة آمنة.
كيف تحسِّن شبكات VPN أمان النظام
يُعَدُّ استخدام VPN طريقةً فعالة لبناء شبكة خاصة لا يراها إلَّا خوادمنا، وتتمتع الاتصالات ضمنها بالأمان والخصوصية التامة، يمكن تمرير حركة مرور بعض التطبيقات عبر الواجهة الافتراضية التي توفرها برمجيات VPN، وستكون عندها الخدمات الوحيدة المتاحة عبر الشبكة العامة هي تلك التي يُفترض بالعملاء أن يستخدموها عبر الإنترنت العام.
تنفيذ شبكات VPN عمليًا
يعتمد إعداد الشبكة الخاصة private network على التخطيط وضبط الإعدادات المناسبة لمشروعنا على التطبيقات والواجهات الشبكية والجدران النارية التي نستخدمها، وذلك في بداية العمل عند نشر الخوادم لأول مرة، بالمقابل يتطلب إعداد شبكات VPN ونشرها تثبيت أدوات إضافية على بنيتنا الحالية وبناء مسارات شبكة network routes إضافية، كما ينبغي أن يمتلك كل خادم في شبكة VPN الخاصة بنا البيانات والإعدادات التي تمَكِّنُه من تأسيس اتصال VPN مع مكونات الشبكة، وبعد إتمام كافة الإعدادات وتشغيل VPN بنجاح يمكن ضبط إعدادات تطبيقاتنا لتمرر كافة بياناتها عبر نفق VPN tunnel. ولمزيد من المعلومات ننصح بمطالعة المقالات الموجودة في قسم VPN.
هناك العديد من الأدوات مفتوحة المصدر التي تساعدنا على بناء شبكات VPN مثل وايرجارد Wireguard وغيرها، وتتبع شبكات VPN عمومًا المبدأ نفسه الذي ناقشناه في فقرة VPC والخاص بتقييد الوصول إلى الخوادم السحابية بعدد محدود من المداخل ingress وذلك عبر تنفيذها سلسلة من واجهات الشبكة الخاصة خلف عدد قليل من نقاط الدخول entry points، ويمكننا تنفيذ التقنيتين معًا أي VPN ضمن بنية تحتية أساسها VPC من بناء شبكات VPN أكثر تخصيصًا.
تدقيق الخدمات ومراجعتها
يُعدّ تحليل الأنظمة المستخدمة وفهم ثغراتها واحتمالات الهجمات التي قد تتعرض لها من أهم تدابير الحماية التي تساعدك على تأمين الخودام وبقية مكونات النظام بأفضل طريقة ممكنة.
ويُعدّ تدقيق الخدمات Service auditing ومراجعتها من أبرز أساليب هذا التحليل، فهو يوفر معلومات عن الخدمات العاملة على نظام معين، وأرقام المنافذ التي تستخدمها، والبروتوكولات التي تتخاطب بها وما إلى ذلك، وتساعدنا هذه المعلومات في ضبط إعدادات الخدمات الموجهة للعامة، وإعدادات الجدران النارية، وأيضًا في المراقبة، والإنذار بحدوث أي طارئ.
كيف يساهم تدقيق الخدمات ومراجعتها بتعزيز أمان الأنظمة؟
تمثل كل خدمة داخلية أو عامة تعمل على نظام حاسوبي ثغرة أمنية محتملة ونقطة ضعف يمكن أن يستغلها المهاجمون، وبالتالي كلما ازداد عدد الخدمات الموجودة على خادمنا كلما ازدادت احتمالات اختراقه وما يتبعها من تأثيراتٍ سلبية على برمجياتنا.
عند توفر فكرة أساسية عن الخدمات الشبكية العاملة على جهازنا يمكن البدء بتحليلها، وطرح الأسئلة التالية عن كل خدمة نود تدقيقها:
- هل من الضروري تشغيل هذه الخدمة
- هل تعمل هذه الخدمة على واجهات الشبكة الصحيحة أم على واجهات لا ينبغي لها العمل عليها
- هل ينبغي ربط هذه الخدمة بواجهة شبكة عامة أم خاصة
- هل قواعد الجدار الناري مضبوطة بطريقة صحيحة فتمرر حركة البيانات المسموحة فقط إلى هذه الخدمة وتمنع غير المسموحة
- هل النظام مجهز بآلية تنبيه تعلمنا بالتحذيرات الأمنية المرتبطة بنقاط ضعف كل خدمة من هذه الخدمات
ننصح بإجراء هذا النوع من تدقيق الخدمات عند بناء أي خادم جديد، وتكرراه دوريًا كل بضعة أشهر مثلًا ليساعدنا على اكتشاف أي تغيير طرأ على الخدمات بقصد أو بغير قصد لنتخذ الإجراءات المناسبة حياله.
تنفيذ تدقيق الخدمات ومراجعتها
نستخدم الأمر ss لتدقيق خدمات الشبكة العاملة على نظامنا، إذ يعرض هذا الأمر كافة منافذ TCP و UDP المستخدمة على الخادم. لنلقِ نظرة على المثال التالي المتضمن استخدام هذا الأمر مع الخيارات الخاصة بإظهار اسم البرنامج، ورقم العملية PID، والعناوين الشبكية المستخدمة للاستماع أو لتلقي اتصالات TCP و UDP:
$ sudo ss -plunt
وهذه دلالة كل واحد من الخيارات p و l و u و n و t المستخدمة أعلاه:
- الخيار
pمسؤول عن إظهار رقم العملية PID المقابل لكل مِقبس socket - يعرض الخيار
lالمقابس الفعالة التي تستمع listening حاليًّا للاتصالات - يعمل
uعلى تضمين مقابس UDP في المعلومات المعروضة عن الخدمات بالإضافة إلى مقابس TCP - يعرض
nبيانات رقمية عن حركة مرور البيانات - يعمل
tعلى تضمين مقابس TCP في المعلومات المعروضة عن الخدمات بالإضافة إلى مقابس UDP
وستحصل بعد تنفيذ الأمر على خرج يشبه التالي:
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=69226,fd=6),("nginx",pid=69225,fd=6))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=812,fd=4))
tcp LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=69226,fd=7),("nginx",pid=69225,fd=7))
الأعمدة الرئيسية في الخرج السابق هي: Netid و Local Address:Port و Process وهي الأجدر بالاهتمام، فإذا كانت قيمة العمود Local Address:Port هي 0.0.0.0 فإن الخدمة ستستقبل الاتصالات الواردة إليها على جميع واجهات الشبكة IPv4، وإذا كانت قيمته [::] فستتلقى الخدمة الاتصالات على جميع واجهات الشبكة من نوع IPv6، إذا طبقنا ذلك على المثال أعلاه سنجد أن كل من SSH و Nginx يستقبلان الاتصالات على جميع الواجهات العامة وبكلا النوعين IPv4 و IPv6.
إذًا يمكن الآن أن نقرر فيما إذا كنا نرغب بإبقاء SSH و NGINX تستقبلان الاتصالات على كلا الواجهتين أم تغيير ذلك إلى واجهة واحدة، وبالمثل لبقية الخدمات. هذه هي الفائدة الرئيسية من تدقيق الخدمات بالإضافة إلى قدرتنا على كشف الخدمات التي تعمل على واجهات غير مستخدمة وضرورة تعطيلها.
التحديثات التلقائية غير المراقبة
يُعد التحديث المنتظم للخوادم وتطبيق الإصلاحات الأمنية بشكل دوري أمرًا أساسيًا للحفاظ على مستوى جيد من الأمان، حيث إن الخوادم غير المُحدَّثة أو الإصدارات القديمة من البرامج قد تحتوي على ثغرات أمنية معروفة للمهاجمين، مما يسهل عليهم استغلالها لاختراق الأنظمة. من خلال تفعيل التحديثات التلقائية أو التحديثات غير المراقبة Unattended Updates التي لا تتطلب تدخلاً بشريًا، يمكن ضمان تحديث معظم حزم النظام بشكل تلقائي وفوري، مما يساهم في معالجة الثغرات الأمنية وحماية النظام من مخاطرها.
كيف تُحسّن التحديثات التلقائية أمان النظام
تُحسن التحديثات التلقائية أمان النظام من خلال تقليل الفترات التي يكون فيها الخادم عرضة للاختراق بسبب الثغرات الأمنية المعروفة. فبفضل التحديثات التلقائية، يجري تثبيت الإصلاحات الأمنية التي تصدرها الشركات المطورة بشكل فوري، مما يحد من التأخير الذي قد يحدث عند تعطيل التحديثات. فحتى لو كان التأخير بسيطًا، فإنه يزيد من الفترة التي يكون فيها النظام عرضة للاستغلال. فمع التحديثات اليومية غير المُراقَبة، نضمن عدم تفويت أي تحديث أو إصلاح وتثبيته فور صدوره، مما يحسن أمان الخادم ويحميه من المخاطر الأمنية.
تنفيذ التحديثات غير التلقائية على الخادم
ننصح بقراءة مقال التحديث التلقائي لخادم أوبنتو فهو يعرفكم بأفضل استراتيجيات التحديثات التلقائية على نظام أوبنتو، سواء تحديثات الحزم أو نواة النظام kernel.
البنية التحتية للمفتاح العام والتشفير بواسطة SSL أو TLS
إن البنية التحتية للمفتاح العام Public key infrastructure -أو PKI اختصارًا- هي نظام مخصص لإنشاء وإدارة الشهادات certificates والتحقق من صحتها بهدف تحديد هويات الأفراد وتشفير الاتصالات بينهم. تُستخدم شهادات SSL أو TLS في البداية لإجراء الاستيثاق authentication بين مكونات النظام، ثم تُستخدم بعد ذلك لإنشاء اتصالات مشفرة بين هذه المكونات لضمان الأمان وحماية البيانات المتبادلة.
دور PKI في تحسين أمان الأنظمة
يساعد إنشاء سُلطَة تصديق الشهادات Certificate Authority -أو AC اختصارًا- في تحسين أمان النظام عن طريق السماح لكل خادم بالتحقق من هويات الخوادم الأخرى وتشفير البيانات المتبادلة معها. هذا يمنع هجمات الرجل في المنتصف man-in-the-middle حيث يحاول المهاجم انتحال شخصية خادم آخر لاعتراض البيانات. يُضبَط كل خادم ليثق في سُلطَة التصديق المركزية، وبالتالي يثق في الشهادات التي تصدرها هذه السُلطَة، مما يزيد الأمان ويحمي البيانات.
إعداد بنية تحتية للمفتاح العام PKI
في الواقع يتطلب إعداد سلطة لتصديق الشهادات وبناء البنية التحتية للمفتاح العام PKI جهدًا كبيرًا، كما أن إدارة الشهادات مثل إصدارها أو إبطالها قد تضيف عبئًا إداريًا إضافيًا، هذا الجهد لن يكون مفيدًا جدًا للمستخدم العادي، ولا يستحق كل هذه التكاليف، إلا إذا كان النظام كبيرًا ويزداد تعقيده مع الوقت، مما يجعل من الضروري وجود بنية خاصة لتأمينه. أما بالنسبة لمعظم المستخدمين، فإن استخدام الشبكات الخاصة الافتراضية VPN لتأمين الاتصال بين أجزاء النظام يُعد خيارًا مناسبًا ويوفر حماية كافية، إلى أن يكبر النظام ويصبح بحاجة فعلية لبنية مفاتيح عامة متقدمة.
الخلاصة
نستخلص من هذا المقال فكرتين: الأولى هي أن التدابير الأمنية الأساسية التي عرضناها وغيرها ينبغي أن تكون لبنة أساسية في أي نظام نبنيه مهما كان حجمه وتعقيده، ومن الضروي أن نفكر بها ونجهزها في بداية المشروع قبل نشر التطبيقات وتقديم الخدمات لإعداد بيئة آمنة قدر الإمكان. والثانية هي أنه لا يوجد أمان دائم في أي نظام تقني فإجراءات الحماية هي عمليات مستمرة ومتكررة وتخضع دائماً للمراجعة، وخاصةً بعد أي تغيير يطرأ على بنية النظام، لذا علينا أن نسأل أنفسنا دومًا عن التأثير الأمني الذي قد يقع عند إجراء أي تغيير مهما كان بسيطًا، ونسأل نفس السؤال قبل إطلاق أي خدمة أو ميزة جديدة.
ترجمة -وبتصرف- لمقال Recommended Security Measures to Protect Your Servers لصاحبيه Justin Ellingwood و Alex Garnett.
تعليقات
إرسال تعليق