عناصر تحكم DevSecOps

يطبق DevSecOps أمان الابتكار من خلال دمج عمليات وأدوات الأمان في عملية تطوير DevOps.

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

تستعرض هذه الوثائق كل مرحلة من مراحل عملية DevOps للتكامل المستمر والتسليم المستمر (CI/CD) وعناصر التحكم في الأمان التي نوصي بتكاملها أولا.

التخطيط والتطوير

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

• نمذجة التهديد لعرض التطبيق من خلال عدسة مهاجم محتمل
• المكونات الإضافية لأمان IDE وربطات التثبيت المسبق لفحص التحليل الثابت الخفيف داخل بيئة تطوير متكاملة (IDE).
• مراجعات النظراء ومعايير الترميز الآمنة لتحديد معايير ترميز الأمان الفعالة وعمليات مراجعة النظراء وربطات التثبيت المسبق.

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

نماذج التهديدات

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

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

• كيف يمكن للمهاجمين إساءة استخدام تصميم التطبيق
• كيفية إصلاح الثغرات الأمنية
• ما مدى أهمية إصلاح المشكلات

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

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

نمذجة المخاطر: ابدأ بسيطا

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

سوف تساعدك أساليب الأسئلة البسيطة التالية على البدء:

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

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

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

مورد مفيد آخر هو دليل نمذجة المخاطر للمطورين.

المكونات الإضافية لأمان IDE وربطات التثبيت المسبق

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

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

هناك خيار آخر يجب مراعاته وهو استخدام إطار عمل ما قبل التثبيت إذا كان نظام التحكم بالإصدار يسمح به. يوفر إطار عمل ما قبل التثبيت برامج نصية ل Git hook تساعد في تحديد المشكلات قبل أن يرسل المطور التعليمات البرمجية لمراجعة التعليمات البرمجية. أحد الأمثلة على ذلك هو التثبيت المسبق الذي يمكنك إعداده في GitHub.

مراجعة النظراء ومعايير الترميز الآمنة

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

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

تنفيذ التعليمات البرمجية

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

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

إدارة التبعيات

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

تأكد من أن فريق التطوير الخاص بك يعرف المكونات التي يجب تضمينها في تطبيقاتهم. سيرغبون في تنزيل إصدارات آمنة ومحدثة من مصادر معروفة. وسيرغبون في الحصول على عملية للحفاظ على الإصدارات محدثة. يمكن لفريقك استخدام أدوات مثل مشروع OWASP Dependency-Check و WhiteSource وغيرها.

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

اختبار أمان التطبيق الثابت

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

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

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

البنية الأساسية لبرنامج ربط العمليات التجارية الآمنة

يأخذ DevOps الأتمتة إلى مستوى آخر لأن كل شيء في دورة حياة التطوير يمر عبر البنية الأساسية لبرنامج ربط العمليات التجارية. التكامل المستمر والتسليم المستمر (CI/CD) هما جزء رئيسي من دورات التطوير الحديثة. في CI/CD، يقوم فريقك بدمج التعليمات البرمجية للمطور في قاعدة تعليمات برمجية مركزية وفقا لجدول زمني منتظم وتشغيل البنيات القياسية وعمليات الاختبار تلقائيا.

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

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

الإنشاء والاختبار

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

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

اختبار أمان التطبيق الديناميكي

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

يتكون اختبار الاختراق من عدة نقاط عمل، واحدة منها هي اختبار أمان التطبيق الديناميكي (DAST). DAST هو اختبار أمان تطبيق ويب يعثر على مشكلات الأمان في التطبيق قيد التشغيل من خلال رؤية كيفية استجابة التطبيق للطلبات المصممة خصيصا. تعرف أدوات DAST أيضا باسم الماسحات الضوئية للثغرات الأمنية لتطبيق الويب. أحد الأمثلة على ذلك هو أداة مفتوحة المصدر، OWASP Zed Attack Proxy (ZAP) . يعثر على الثغرات الأمنية في تطبيق الويب قيد التشغيل. هناك طرق مختلفة لمسح OWASP ZAP: فحص أساسي سلبي أو فحص كامل، اعتمادا على التكوين.

عيب اختبار القلم هو أنه يستغرق وقتا. قد يستغرق اختبار القلم الشامل ما يصل إلى عدة أسابيع، ومع سرعة تطوير DevOps، قد يكون هذا الإطار الزمني غير مستدام. ولكن لا يزال من المفيد إضافة إصدار أخف من اختبار القلم أثناء عملية التطوير للكشف عن المشكلات التي فاتها SAST والخطوات الأخرى. يمكن أن تساعد أدوات DAST مثل OWASP ZAP.

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

التحقق من صحة تكوين السحابة ومسح البنية الأساسية

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

تتيح قدرات Azure للمؤسسات إنشاء معايير أمان من البيئات، مثل نهج Azure. يمكن للفرق استخدام نهج Azure لإنشاء مجموعات النهج. تمنع مجموعات النهج إنشاء أنواع معينة من أحمال العمل أو عناصر التكوين مثل عناوين IP العامة. تمكن حواجز الحماية هذه الفرق من التجربة داخل بيئة آمنة ومتحكم فيها، وموازنة الابتكار والحوكمة.

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

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

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

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

الانتقال إلى الإنتاج والتشغيل

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

فحص التكوين والبنية الأساسية

للرؤية في الاشتراكات السحابية وتكوين الموارد عبر اشتراكات متعددة، استخدم حل أمان مستأجر Azure من فريق AzSK.

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

اختبار الاختراق

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

يقدم العديد من المنتجات والشركاء خدمات اختبار الاختراق. توفر Microsoft إرشادات لاختبار الاختراق في Azure.

يغطي الاختبار عادة أنواع الاختبار التالية:

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

التحليل الذكي القابل للتنفيذ

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

حلقات الملاحظات

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

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