مبادئ تصميم الشبكات

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

ولكي نتّخذ مقاربةً منتظمةً للأمن، يفيد أن تكون لدينا رؤيةٌ واضحة لمتطلباتنا. فبمجرد أن نعرّف تلك المتطلبات، يمكننا أن ندرس المبادئ التي يمكن تطبيقها لمساعدتنا على تلبيةها.

2.1 متطلّبات الأمن

أوّل متطلّبٍ رئيسي يخطر ببال المرء عند التفكير في إرسال البيانات عبر شبكةٍ مشتركة هو على الأرجح السرّية (confidentiality). وكما أشرنا في الفصل 1، هناك طرقٌ كثيرة قد يتمكّن فيها الخصم (adversary) من الوصول إلى البيانات أثناء مرورها عبر الشبكة. والسرّية هي القدرة على منع قراءة البيانات من أيّ طرفٍ سوى المستقبِل المقصود. وهذا، على سبيل المثال، هو ما يلزم لمنع كشف بيانات بطاقتك الائتمانية حين تُدخلها في موقعٍ إلكتروني.

وقريبٌ جدًا من سرّية البيانات وُجود سرّية الحركة (traffic confidentiality). والفكرة هنا هي أنّنا لا نريد أن يتمكّن الخصم من تحديد إلى أين أو إلى من نرسل الحركة، أو بكمّية منها. وهذا يطرح تحدّياتٍ مختلفة عن سرّية البيانات؛ إذ لا حاجة إلى أن ترى أجهزة الشبكة بياناتنا، لكنّها يتعيّن عليها عمومًا أن تنظر في ترويسات الحزم (packet headers) التي تتضمّن معلومات الوجهة، لتحديد إلى أين تُرسَل الحركة.

أمّا المتطلّب الرئيسي الثاني فهو السلامة (integrity)، ويتعلّق بالثقة بأنّ المعلومات التي نتلقّاها جديرةٌ بالثقة، وأنّها، على سبيل المثال، لم يعدّلها خصمٌ ما أثناء مرورها. وضمان السلامة مسألةٌ متعدّد الأوجه، إذ يتضمّن أكثر من مجرّد خصوم «أثناء المرور».

فعلى سبيل المثال، نحتاج إلى القدرة على التحقّق من أنّ عنصر بياناتٍ ما قد أرسلته الجهة التي ادّعت إرسالَه. وهذا يعني أنّنا نحتاج إلى المصادقة (authentication) للمرسِل. وفي مثال التجارة الإلكترونية، هذا ما يتيح لنا أن نعرف أنّنا متّصلون، مثلًا، بموقع البائع الذي نرغب في رعايته، لا بأنّنا نسلّم بطاقتنا الائتمانية إلى منتحلٍ ما.

وتفترض المصادقة (authentication) أن يتوفّر لدينا مفهوم الهوية (identity). أي أنّنا نحتاج إلى نظامٍ تتمكّن عبره الكيانات المتّصلة، التي تُدعى عادةً الجهات (principals)، من التعرّف الآمن على بعضها بعضًا بأمان. وهذه المسألة أصعب في حلّها مما قد يبدو أوّل نظرة. فكيف نعرف أنّ موقعًا إلكترونيًا له معيّن من العنوان يمثّل فعلًا الشركة التي نرغب في التواصل معها؟ أو كيف يعرف نظامٌ مصرفيّ أنّ الشخص الذي يقف خلف طلب HTTPٍ معيّن هو فعلًا صاحب الحساب؟

كما تتطلّب السلامة أن تكون الرسائل طازجة (fresh) وفي وقتها (timely)، وهو ما تهدّده إمكانية التقاط البيانات ثمّ إعادة إرسالها في وقتٍ لاحق. وتُعرف هذه بـ هجوم إعادة الإرسال (replay attack)، حيث نرغب مثلًا في الحماية من مهاجمٍ يضيف عنصرًا إلى سلة تسوّق مرارًا وتكرارًا. ومن ثمّ فإنّ من المتطلّبات الشائعة توفير شكلٍ ما من الوقاية من إعادة الإرسال (replay prevention).

أمّا المتطلّب الرئيسي الأخير فهو التوافرية (availability)، وهي ببساطة القدرة على الوصول إلى جميع البيانات التي لنا حقّ الوصول إليها. وأعطال الأنظمة، سواء كانت حميدةً أو ناتجةً عن فاعلين خبيثين، تحدّ من التوافرية. ومن التهديدات الشائعة الأخرى للتوافرية هجمات حجب الخدمة (denial-of-service, DoS). وكانت دودة موريس (Morris Worm) مثالًا مبكّرًا لهجوم حجب خدمة غير مقصود: فمع انتشار الدودة إلى أجهزةٍ أكثر فأكثر، وإعادة إصابتها للأجهزة التي كانت فيها موجودة أصلًا، جعلت الموارد التي استهلكتها الدودة تلك الأجهزة غير قابلة للاستخدام. وتوفّر الشبكات وسيلةً يمكن بها تضخيم البيانات عبر التكرار، ما يسمح بإرسال أحجامٍ كبيرة من الحركة إلى هدف هجوم DoS؛ ولهذا أصبح من الضروري تطوير وسائل لتخفيف هذه الهجمات.

ونتيجةً لهذه المتطلّبات الرئيسية الثلاثة — السرّية والسلامة والتوافرية — تُفرض متطلّبات إضافية على الأنظمة الأساسية التي نبني فوقها، ما يعيدنا إلى فكرة «قاعدة الحوسبة الموثوقة» (Trusted Computing Base, TCB) التي عُرِّفت في الفصل 1. ولدينا عمومًا ثلاثة متطلّباتٍ مترابطة لهذه المنصّات، إلى جانب كونها ليست خبيثة (وهو ما يفترضه إدراجنا لها في TCB الخاص بنا). وقد رأينا الأوّل بالفعل: يتعيّن أن توفّر مفهومًا محليًّا (خاصًّا بكلّ مكوّن) لـ الهوية، ما يتيح لنا دعمَ عدة جهات (مستخدمين). أمّا الثاني فهو أنّها يتعيّن أن توفّر العزل (isolation)، فتحمي معلومات أحد المستخدمين من المستخدمين الآخرين على النظام. أمّا الثالث فهو أنّها يتعيّن أن تفرض التحكّم بالوصول (access control)، فحدّد المستخدمين الذين يمكنهم الوصول إلى أيّ بيانات، وما يُسمح لهم بتنفيذه من عمليات عليها. وتوفّر هذه الآليّات لنا الأساس الذي نحتاجه عندئذٍ لتلبية متطلّبات السرّية والسلامة والتوافرية ونحن نتّصل عبر الإنترنت.

2.2 متطلّبات النظام الأوسع

فهم متطلّبات النظام الآمن مهمّ، لكنّ الأمن ليس سوى متطلّبٍ واحدٍ من بين متطلّباتٍ كثيرةٍ تُفرض على أيّ نظام. ومن المهمّ أيضًا أن تكون الأنظمة موثوقة (reliable)، ومتاحة (available)، وقابلة للتوسّع (scalable)، وعالية الأداء (performant)، وسهلة الاستخدام (usable)، وقابلة للإدارة (manageable)، وقابلة للتطوّر (evolvable)، وقابلة للمراقبة (observable)، وهكذا.

وكثيرًا ما تكون متطلّبات النظام هذه غير قابلة للتمييز عن الأمن. فعلى سبيل المثال، نظامُ تجزئةٍ أُسقط بسبب اختراقٍ أمني لا يقلّ عن توافريّته نظامٌ أُسقط بسبب عطلٍ في الأجهزة أو خللٍ برمجيّ. وعلى نحوٍ مشابه، قد يكون نظامُ تسليم الفيديو مصمَّمًا ليتوسّع ليموجّه اندفاعًا مفاجئًا من المستخدمين (flash crowd)، فيكون في الوقت نفسه قادرًا على التوسّع لصدّ هجوم DoS. عمليًّا، قد يكون من الصعب تحديد السبب الجذري لعطلٍ ما (هل كان خبيثًا أم حميدًا) والمصدر الجذري لعبء العمل (هل كان خبيثًا أم مشروعًا). والفرق الرئيسي أنّه من الممكن عمومًا التهيئة لعبء العمل المشروع والأعطال الحميدة، إذ يمكن قياسها والتنبّؤ بها (وإن لم يكن ذلك دقيقًا دائمًا)، في حين إنّ الهجمات الخبيثة غالبًا ما تكون أقلّ قابليةً للتنبّؤ (مع أنّها ينبغي توقّعها).

وحيث تصبح المجموعة الأوسع من المتطلّبات جديرةً بالاهتمام هو عندما تتنازع مع بعضها فيصبح من الضروري إجراء مفاضلات. فعلى سبيل المثال، قد يضيف جعلُ نظامٍ ما آمنًا زمن استجابةٍ (latency) إلى كلّ معاملة. وعلى نحوٍ مشابه، يُحمّل إبقاءُ نظامٍ ما آمنًا عبئًا إضافيًّا على المستخدمين (فيصبح أقلّ قابليةً للاستخدام)، وفي المقابل فإنّ هؤلاء المستخدمين غالبًا ما يكونون الحلقةَ الأضعف في استراتيجية الأمن. ولا تحتاج هذه المفاضلات إلى فرض سيناريو «إمّا… أو…» — فمن الواضح أنّ التصميم للأمن وقابلية الاستخدام معًا أمرٌ مرغوب — لكنّ أيّ متطلّبٍ ليس مطلقًا، وإلّا لأمكننا تأمين أيّ نظام بمجرد منع الوصول إليه عن جميع المستخدمين.

ولأغراضنا، فالخلاصةُ الرئيسة أنّ الأمن فريدٌ من نوعه في أنّه ليس مجرّد متطلّبٍ لنظام (for a system)، بل يُنظر إليه غالبًا بوصفه نظامًا بذاته، لا بدّ وأن يكون قابلًا للاستخدام، وقابلًا للتوسّع، وقابلًا للإدارة، وقابلًا للتطوّر، قابلًا للمراقبة، متوفرًا، موثوقًا، وهكذا.

2.3 مبادئ الأنظمة الآمنة

نظرًا لطول أمد المحاولات التي بذلها الناس لبناء أنظمة حوسبةٍ آمنة، بما فيها الأنظمة المتّصلة بالشبكة، فقد كان هناك متّسعٌ من الوقت لتطوير بعض المبادئ التي ترفع احتمال بقاء النظام آمنًا. نعرض هنا بعضَ أشهر هذه المبادئ، وتتضمّن الفصول التالية أمثلة على كيفية تطبيقها عمليًا.

2.3.1 الدفاع متعدّد الطبقات

وكما أشرنا، فإنّ أحد التحديات المركزية في الأمن هو أنّنا لا نعرف أبدًا إن كان ما فعلناه كافٍ. فعلى قدر ما نحاول الدفاع في مواجهة كلّ أشكال الهجوم الممكنة، لا سبيل إلى اليقين بأنّنا قد فكّرنا في كلّ شيء. وهذا هو ما نعنيه بقولنا إنّ الأمن هدفٌ سلبيّ: فنحن نرمي إلى التأكّد من استحالة حدوث مجموعةٍ من الأمور، لكنّنا لا نستطيع مطلقًا أن نتيقّن تمامًا من أنّ جميع الثغرات (vulnerabilities) قد عُثِر عليها وخُفِّف أثرها. ويؤدّي هذا إلى فكرة الدفاع متعدّد الطبقات (defense in depth): طبقةً فوق طبقة من الدفاعات، بحيث إن اختُرقت إحداها تبقى طبقاتُ دفاعٍ أخرى متوفّرة. ولن يتمكّن المهاجم (attacker) من بلوغ هدفه (مثلًا سرقة بياناتنا) إلّا إذا اجتاز جميع طبقات الدفاع. والأمل هو أنّه بما يكفي من طبقات الدفاع، تصبح احتمالات اختراق المهاجم لها جميعًا ضئيلةً إلى حدّ العدم.

وكمثالٍ بسيط، قد تلجأ شركةٌ ما إلى شبكة VPN (virtual private network) لضمان أن يتمكّن المستخدمون المصرّح لهم وحدهم من الوصول إلى خوادم الشركة، وأن تكون حركتهم مشفّرة حين يفعلون ذلك عبر الإنترنت. لكنّ طبقة الدفاع هذه الواحدة معرّضةً لعدّة أشكالٍ من الهجوم، مثل وجود برمجيةٍ خبيثة (malware) على حاسوب المستخدم البعيد، أو اختراق بيانات اعتماد المستخدم البعيد. ولهذا تلزم طبقاتُ دفاعٍ إضافية، مثل جدران الحماية (firewalls) الداخلية بين أنظمة الشركة المختلفة؛ وأدوات لكشف البرمجيات الخبيثة على أنظمة المستخدمين البعيدة ومعالجتها والوقاية منها؛ والمصادقة متعدّدة العوامل (multi-factor authentication) للحماية من بيانات الاعتماد المخترَقة. وهذه ليست سوى قائمةٍ قصيرةٍ من إجراءات الدفاع المستخدَمة عادةً، وهي لا تُعدّ كافيةً بذاتها. لكنّ النقطة التي ينبغي ملاحظتها هنا هي استعمال طبقاتٍ دفاعٍ متداخلةٍ كثيرة، بهدف أن ترفع جميعها معًا العتبة بما يكفي لإفشال معظم الهجمات.

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

2.3.2 مبدأ أقلّ الامتياز

لمبدأ أقلّ الامتياز (least privilege) تاريخٌ طويل في علوم الحاسوب، فقد اقترحه سولتزر وشرويدر (Saltzer and Schroeder) عام 1975 (انظر «قراءات إضافية»). وينصّ المبدأ على:

«ينبغي لكلّ برنامج وكلّ مستخدمٍ للنظام أن يعمل بأقلّ مجموعةٍ من الامتيازات اللازمة لإنجاز المهمة.»

ومن الأمثلة الشائعة لهذا المبدأ في الممارسة العملية تجنّب تشغيل أيّ شيءٍ بصلاحية root على الأنظمة الشبيهة بيونكس (Unix) إلّا عند الضرورة القصوى.

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

ولافتًا، يذكر سولتزر وشرويدر صراحةً «جدران الحماية» (firewalls) في القسم المتعلّق بمبدأ أقلّ الامتياز في ورقتهما البحثية، مستخدمَين التشبيهَ الوارد من العالم الماديّ (جدارٌ لمنع انتشار النار) قبل أن يختُرع مفهوم جدران حماية الشبكة. وكما سنناقش لاحقًا، تبيّن أنّ الاستخدام الواسع لجدران حماية الشبكة خلال معظم تاريخها أخفق في اتباع مبدأ أقلّ الامتياز، إذ من الشائع أن يُعثر على «مناطق» (zones) واسعةٍ في الشبكة فيها تتمتّع كلّ الآلات بإمكانية الوصول إلى بعضها، رغم أنّ هذا الوصول ليس مطلوبًا في الواقع لكي تنجز الآلات مهامّها. وقد تطلّب معالجة هذا القصور بعض الابتكارات في تصميم جدران الحماية، ولم تصل إلّا في العقد الأخير تقريبًا.

2.3.3 التصميم المفتوح

مبدأ آخر دوّنه سولتزر وشرويدر هو مبدأ التصميم المفتوح (open design). وينصّ على أنّ الآليّات والخوارزميات المستخدَمة لتنفيذ الأمن ينبغي أن تكون مفتوحةً لا سرّية. والفكرة هي أنّه بدلًا من محاولة إبقاء شيءٍ ضخمٍ ومعقّدٍ مثل خوارزمية تشفير سرًّا، من الأفضل أن تُنشر تلك الخوارزمية وأن يقتصر السرّ على المفتاح (أو المفاتيح) وحدها. ولهذا المبدأ سببان:

• من الصعب إخفاء خوارزمية، خاصّةً إذا كانت مستعملةً على نطاقٍ واسع كما هو حال التشفير على الإنترنت؛
• جعلُ آليّات الأمن متينةً في مواجهة كلّ أشكال الهجوم مسألةٌ صعبة، كما ناقشنا. ولهذا من الأفضل أن تخضع هذه الآليّات لفحصٍ واسعٍ يكشف نقاط ضعفها، ثمّ تُصحَّح.

وتاريخُ أمن الحوسبة مليءٌ بقصصٍ تحذيريةٍ متعلّقة بهذا المبدأ. ففي الحالات التي اتُّبِع فيها المبدأ، كُشفت أخطاءٌ دقيقةٌ في تصميم البروتوكولات أو تنفيذها، وأُصدرت ترقيعاتٌ لمعالجتها. وHeartbleed، وهو خللٌ في التنفيذ المفتوح المصدر والواسع الاستخدام لـ SSL، مثالٌ مشهور. وكانت آثار الخلل خطيرة، إذ تأثّر بها ما يصل إلى نصف مليون خادم ويب، لكنّه كان أمرًا إيجابيًّا أنّ الخلل عُثِر عليه وأُبلِغ عنه وعُولج بسرعة.

وإن لم يُتَّبع هذا المبدأ، فإنّ تصميمًا يُظنّ سرًّا قد يكون في الواقع مخترَقًا (مثلًا بالهندسة العكسية)، أو قد تكون له عيوبٌ لم يُبلَّغ عنها لكنّها تُستغَلّ مع ذلك.

والصياغة الأخرى لهذا المبدأ هي «تقليل الأسرار» (minimize secrets). فعلى سبيل المثال، بدلًا من محاولة إبقاء خوارزميةٍ كاملةٍ سرًّا، لا نُبقي سرًّا إلّا المفتاح المستخدَم في فكّ التشفير بواسطة الخوارزمية. فاستبدالُ مفتاحٍ مخترَقٍ أسهلُ بكثير من استبدال خوارزميةٍ كاملة.

2.3.4 الإعدادات الافتراضية الآمنة عند الفشل

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

وتبيّن أنّ تصميم الإنترنت لا يتبع هذا النهج إطلاقًا. فنموذج تسليم مخطّطات البيانات (datagram delivery) في الإنترنت يسمح، بشكلٍ افتراضي، بإرسال الحزم من أيّ مكان إلى أيّ مكان. وبالقدر الذي يمكن تعريف إرسال حزمةٍ إلى نظامٍ ما بأنه الوصول إلى ذلك النظام، فإنّ السلوك الافتراضي للإنترنت لا يوفّر إعداداتٍ افتراضية آمنة عند الفشل. وتشمل تطبيقات العودة إلى سلوكٍ افتراضيٍ أكثر أمانًا أفكارًا قديمةً مثل جدران حماية الشبكة وشبكات VPN الخاصة الافتراضية، إلى جانب مقارباتٍ أحدث مثل التجزئة الدقيقة (microsegmentation) ومعماريات الثقة الصفرية. وسنناقش هذه التطوّرات في فصلٍ لاحق.

2.3.5 الآلية المشتركة الأقلّ انتشارًا

ينصّ هذا المبدأ على أنّ مقدار الآلية المشتركة بين أكثر من مستخدمٍ واحد ينبغي تقليله. وقد صاغه في الأصل جيرالد بوبك (Gerald Popek) عام 1974، حيث دافع في سياق تصميم أنظمة التشغيل عن تقليل عدد الآليّات الموضوعة في نواة (kernel) نظام التشغيل. وأي خللٍ (أو اختراقٌ أمني) في آليةٍ مشتركةٍ كهذه سيؤثّر في جميع المستخدمين، لذا من الأفضل توفيرها بطريقةٍ أخرى، مثل مكتبةٍ تعمل في نطاق عناوين المستخدم. عندئذٍ لا يؤثّر خللُ تلك الآلية سلبًا إلّا في ذلك المستخدم، لا في جميع المستخدمين.

والحجّة المضادّة هي أنّ أيّ آليّة تتطلّب وصولًا مُميَّزًا — مثلًا الوصول إلى جهاز إدخال/إخراج (I/O) أو تعديل بنية بياناتٍ مشتركة — يجب أن تُنفَّذ في طبقةٍ مشتركة (أي النواة)، لكنّ حتى في هذه الحالة ينبغي الحرص على تفكيك الآليّة بحيث تُقلَّص القطع الفرعية المشتركة قدر الإمكان. وقد ذهب أنظمةُ التشغيل المعتمِدة على شكل مكتبات (library OSes) التي صُمِّمت في تسعينيات القرن الماضي بهذا الحجّة إلى نتيجته المنطقية، واختصرت «النواة» إلى الحدّ الأدنى، مع تشغيل معظم الوظائف التي يُتوقّع عادةً من نظام تشغيلٍ في صورة مكتبةٍ موضوعة بجوار التطبيق.^[1]

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

قراءات إضافية

G. Popek. A Principle of Kernel Design. Security Kernel Panel at the AFIPS ‘74 National Computer Security Conference and Exposition. May 1974.

D. Engler, F. Kaashoek, and J. O’Toole Jr. Exokernel: an Operating System Architecture for Application-level Resource Management. SIGOPS Symposium on Operating System Principles. December 1995.

J. Saltzer, D. Reed, and D. Clark. End-to-End Arguments in System Design. ACM Transactions on Computer Systems. November 1984.

2.3.6 التصميم لأجل التكرار

نظرًا لما قلناه عن صعوبة اليقين بأنّ نظامًا ما آمن، فإنّ مبدأ تصميمٍ مفيدًا هو قبول حقيقة أنّنا سنحتاج إلى تكرار (iteration)، وأن نصمّم لأجله. ومن الأمثلة الجيّدة على ذلك اختيار خوارزمياتٍ تشفيرية بعينها لحماية السلامة أو للتشفير. وكثيرًا ما يُتبيّن أنّ هذه الخوارزميات غير قويةٍ بما يكفي بعد عددٍ من السنين، ربما بسبب ضعفٍ في الرياضيات التي تقوم عليها، أو قفزةٍ في الخوارزميات، أو مجرّد التزايد المستمر في القدرة الحوسبية الذي يحدث مع مرور الوقت. ولهذا ينبغي أن يُصمَّم أيّ بروتوكولٍ يُطوَّر ويعتمد على خوارزميةٍ كهذه بحيث يكون تغييرُ الخوارزمية سلوكًا متوقَّعًا. ونرى هذا في بروتوكولاتٍ مثل أمن طبقة النقل (Transport Layer Security, TLS) الذي يتضمّن مجموعةً من الإجراءات التي يتفاوض بها طرفان حول الخوارزميات التشفيرية التي ستُستخدم.

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

2.3.7 آثار التدقيق

يُعدّ جزءٌ من التعامل مع استحالة تغطية جميع التهديدات الأمنية الممكنة هو قبول حقيقة أنّنا نحتاج أحيانًا إلى تحليل ما الذي جرى بشكلٍ خاطئ. ويؤدّي هذا إلى فكرة أنّ الأمن يحتاج إلى أن يكون قابلًا للتدقيق (قابلًا للمراقبة). فعلى سبيل المثال، يكون إجراءُ تشريحٍ بعد الحداث (post-mortem) لاختراقٍ يتضمّن بيانات اعتماد دخولٍ مخترَقة أسهلَ إذا سُجِّلت كلّ محاولة دخول، إلى جانب معلوماتٍ مثل ما إذا كان الدخول قد تمّ عبر VPN، وما عنوان IP المستخدَم، وهكذا. وعلى نحوٍ مشابه، من الصعب جدًّا منع هجمات من الداخل، لكنّ السجلّات المناسبة قد تجعل اكتشافَ تلك الهجمات سريعًا أسهل، وقد تثّط ممّن قد يندفعون إلى تنفيذها.

وفي اتجاهٍ آخر، تأمّل تصميمَ البروتوكولات الآمنة. فمواصفة TLS (transport layer security) تصف عددًا كبيرًا من حالات الخطأ التي قد تُطلق تنبيهات، وتوصي بتسجيل كلّ تلك التنبيهات. وسيُساعد هذا التسجيلُ في فهم ما إذا كان البروتوكول قد تعرّض لهجومٍ تضمّن رسائلَ خاطئةً أو غير متوقّعة. ونظرًا لتعقيد التفاوضات الجارية في بروتوكولات الأمن (مثلًا لتثبيت الخوارزميات التشفيرية ومعاملاتها)، فمن الحكمة أن نفترض أنّ فيها أخطاءً دقيقة، وأنّ مجموعةً جيّدةً من أدوات التدقيق تمكّن من اكتشاف أيّ من تلك الأخطاء ثمّ معالجته.

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

2.4 أفضل الممارسات

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

وتبدأ هذه الممارسات بوضع مقاييس الأمن التي سيُحكَم بها على النتيجة النهائية، إلى جانب العمليات المستخدَمة لمراجعة التصاميم واختبار الالتزام. وعلى جانب التطوير، يُركَّز على استخدام معايير التشفير وأفضل البروتوكولات والمنصّات واللغات المتوفّرة. وليست مهمّةَ المهندس أن يعيد اختراع آليّات الأمن الموصوفة في هذا الكتاب، بل أن يعرف ما هي الآليّات المتوفّرة وكيف يستخدمها. وبمجرد نشر النظام ودخوله حيز التشغيل، ينتقل التركيز إلى مراقبة النظام استباقيًّا بحثًا عن سلوكٍ شاذّ، وعلى وضع خطة استجابة للحوادث للتعامل مع الهجمات المشتبه بها. فالجمع المستمرّ للبيانات عن نظامٍ قيد التشغيل أمرٌ شائع، واستخدام الذكاء الاصطناعي وتعلّم الآلة (AI/ML) لكشف الهجمات (والاستجابة لها المحتملة) أصبح شائعًا أكثر فأكثر.

وتفاصيل هذه الإجراءات خارج نطاق هذا الكتاب، باستثناء ما نذكره من أنّها تعتمد على أن يكون المهندسون والمشغّلون على اطّلاءٍ جيّد بالآليّات الأمنية المتوفّرة. وكأمثلةٍ لممارسات القطاع، نوصي بممارسات دورة حياة التطوير الأمني (Security Development Lifecycle, SDL) من مايكروسوفت.

قراءات إضافية

Microsoft Security Development Lifecycle (SDL).

2.5 الخلاصة

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

قراءات إضافية

J. Saltzer and M. Schroeder. The Protection of Information in Computer Systems. In Proceedings of the IEEE, 1975.

---

1. ورغم الالتزام الصارم بمبدأ أقلّ آليّة مشتركة (least common mechanism)، لم تُعتمد أنظمة التشغيل المكتبية (Library OSes) على نطاقٍ واسع في الممارسة، ممّا يدلّ على أنّ الأمن ليس سوى أحد متطلّباتٍ عديدةٍ تؤخذ في الحسبان. ↩︎