ثلاث خطوات لتأمين DevOps مفتوح المصدر

إنّ المفتاح الرئيسي لتأمين تطوير تطبيق ما هو "الإزاحة نحو اليسار" - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير.

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

يفحص معظمنا شيفرته بحثًا عن العيوب مستخدمًا «أدوات التحليل الثابتة» (static analysis tools)، لكن ماذا عن كل المواضيع التي لم نكتبها بأنفسنا؟ كيف يمكننا معرفة ما في داخلها بالفعل؟ وبمجرد معرفتنا لذلك، ما هي الإجراءات التي نتخذها إما لتنظيفها أو لإبقائها محدّثة؟ كيف يمكننا تجنب التعرض للاختراق لأننا ندع شيئا مفتوحًا يعمل في الخلفية باستخدامنا لتلك المكتبة القوية المزدحمة التي تفعل ذاك الشيء الجميل الذي لا يمكننا الاستغناء عنه؟

الطريقة القديمة

أُبرمج منذ 20 عامًا تقريبًا، وهي فترة طويلة وكافية لرؤية التطور بدءًا من النماذج التقليدية لتخطيط البرامج كالنماذج الشلالية أو الحلزونية إلى نماذج «البرمجة الفائقة» (Xtreme Programing)، والنماذج المرنة Agile و تطوير العمليات DevOps الآن.

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

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

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

إن الخبر الجيد هنا هو أنه الآن يوجد استراتيجيات حقيقية لإيضاح المشكلة وطرق حلها.

الطريقة الجديدة

عالم اليوم هو عالم الأتمتة و«التكرار المتواصل» (continuous iteration). نسمي هذه العملية بـ "DevOps" لأنها تمزج تطوير البرمجيات وتعريف وأتمتة البنية التحتية لإنشاء نماذج للنشر والعمليات التي تُمكّن ذاتيًا.

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

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

كما هو الحال في DevOps، التي تُمكّن المطورين من تعريف« بُنى» (architecture) معتمدة على البرمجيات وإصدارها ونشرها باستخدام الأتمتة، تمنح DevSecOps المطورين نفس الأدوات والتقنيات والعمليات للقيام بالشيء نفسه من أجل أمان البرنامج.

الخطوة 1: البدء في التصميم

إنّ الطريقة الأكبر التي تخرج بها التطبيقات مفتوحة المصدر عن مسارها بسرعة، تتمثل في عدم التفكير في بنيّة التطبيق قبل البدء بكتابة الشيفرة. هل ما زلت تستخدم نسخة "Struts" عمرها سنتين لتطبيقك الجديد فقط لمجرد أنّها مثبّتة على جهازك المحلي مسبقًا، متبقيةً من مشاريعك العشرة السابقة التي أنجزتها؟ تأكّد في كل مرّة تبدأ فيها مشروعًا جديدًا بأنّك تستخدم الإصدار الأحدث والأكثر موثوقية من إطار العمل الذي تعتمده. استخدم أدوات مجانيّة أو أدوات غير مكلفة مثل SourceClear لتحديد «فاتورة المواد» (Bill Of Materials- BOM) في تطبيقك وكن متأكدًا من أنها تفي بالمطلوب قبل بدء العمل. سيوفر عليك لك المتاعب لاحقًا.

الخطوة 2: أتمتة كل شيء

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

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

الخطوة 3: تطوير "مواطنين جيدين" وليس "بنى جيدة"

أخيرًا، لكي يتحقق DevSecOps بالفعل، علينا العمل على تغيير طريقة التفكير حول سياسة أمن المعلومات InfoSec وعمليات النشر المتعلقة بذلك.

كانت تبدو معظم نماذج النشر التي تتضمن الأمان في الماضي كالتالي:

تصميم -> كتابة شيفرة -> اختبار التكامل -> ضمان الجودة QA -> مراجعة InfoSec -> الإنتاج. ( QA: هي اختصار للكلمتين Quality Assurance)

ولكن عندما تكون دورات DevOps مُحتملة خلال ساعات أو حتى دقائق، فكيف يمكنك مراجعة InfoSec قبل مرحلة الإنتاج؟ الجواب: ليس أنت من يفعل ذلك.

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

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

اسأل نفسك الآن السؤال التالي، "هل تثق بهم؟"

لاحظ، إذا كنت تقدم المعلومات في وقت مبكر بما فيه الكفاية، فبإمكانك إزالة "مراجعة InfoSec" بالفعل عندما يحين وقت النشر.

ماذا؟ وهذا صحيح. يمكن ببساطة في هذه المرحلة أن تسأل عملية التحكم في التغيير الخاصة بك الأسئلة التالية:

"هل أُكمِلت مراجعات الأمان التلقائية لهذا التطبيق في كل مرحلة من المراحل؟"
"هل حلّ المطورون العيوب الحرجة كما هو متوقع على أسس ثابتة؟"
"هل كان آخر تقييم مكتمل يصل إلى مستوى توقعاتنا (سياستنا)؟" إذا كان بإمكانك الإجابة بنعم على هذه الأسئلة، فإن ما عليك فعله هو الوثوق في أن فريق التطوير يعمل بشكل نموذجي (مواطنين جيدين)، والحرص على إنتاج نوعية جيدة، والتصرف بطريقة مسؤولة. سيبدو نموذجنا الجديد مشابها لهذا:

تصميم مستنير -> مراجعة الشيفرة الآلية -> ضمان الجودة -> IT -> مواطن جيد؟ -> النشر.

ترجمة وبتصرف للمقال: 3 steps to secure, open source DevOps لصاحبه: Jet Anderson.