أمان التطبيق أو كيفية تضمين الأمان في تطوير مخصص. تجربة شخصية في AGIMA

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

ما في المقال:

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

من هو المقال؟

قد تكون المقالة مفيدة لمديري المشاريع والمديرين التقنيين وقادة الفريق وكل شخص يرتبط بطريقة ما بتنظيم عمليات تطوير التطبيق.

تنويه:

هذه المقالة ليست حلا سحريا ، ولكنها مجرد رأي شخصي محض للمؤلف (أليكسي كلينوف ، رئيس أمن المعلومات في AGIMA).

كيف بدأ كل شيء

شاركت AGIMA منذ فترة طويلة في التطوير الشامل لإجراءات مراقبة الجودة وإدارة ضمان الجودة. تخضع جميع منتجاتنا لفحوصات داخلية عديدة:

• استخدام قوائم المراجعة بعد كل مرحلة / سباق لتطوير المنتج ؛
• نحن نغطي وظائف العمل المهمة من خلال شبكة من الاختبارات الذاتية ؛
• نحاول تغطية الكود باختبارات الوحدات قدر الإمكان ؛
• نستخدم محللات الكود التي تلبي المعايير (على سبيل المثال ، بالنسبة لـ PHP ، يكون PSR 0-4 ، إلخ) ؛
• نجري اختبارات الحمل دون فشل.

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

من قبل العملاء

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

من يد إلى يد عندما يقوم شخص آخر بتطوير مشروع

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

ما حصل في الطريق؟

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

من الواضح أن التحكم في سلامة المنتج يحسن من جودته. ولكن كيف سيؤثر تحليل الأمان على تكلفة وتوقيت المشاريع؟

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

الخطوات الأولى

رأينا في تحسين أمان التطبيق:



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

مكعب صغير

باختيار محلل للبدء ، استبعدنا المنتجات باهظة الثمن المدفوعة. توقفنا في SonarQube - وهو محلل يحتوي على إصدار تجريبي. هناك أيضًا نسخة سحابية ، لكن الإصدار المجاني يجعل المشروعات مفتوحة بالكامل ، وهو أمر غير مقبول في حالتنا.
لذلك ، للبدء - SonarQube Community Edition. يدعم 15 لغة ، بما في ذلك Java و JavaScript و C # و PHP و Python. يتم نشر الحل بسرعة كبيرة ولا يسبب أي مشاكل خاصة ، ويتم تسهيل ذلك عن طريق دليل مفصل.



نظام مناسب للتمييز في الحقوق: يمكنك إنشاء مصفوفة للوصول إلى كل مشروع.



يسمح لك SonarQube بمراقبة ديناميكيات المشروع وتخزين تاريخ التحليل. يمكننا نحن أنفسنا وضع حد للجودة لكل مشروع ، مما يسمح لنا بتحسين التحليل لمشاريع مختلفة.





اختبرنا المنتج في عدة مشاريع:

1. كان من الممكن التقاط العديد من نقاط الضعف غير الواضحة في المشاريع الحالية.
2. كان وقت التنفيذ الحد الأدنى.
3. لقد تأكدنا من أنه في إطار CI ، يتم إرجاع الرمز للمراجعة للإشارة إلى نقاط الضعف المحتملة.

قررنا أن هذا يكفي لمساعينا.

ما التالي؟

بالنسبة لأنفسنا ، حددنا ثلاثة أساليب تختلف اعتمادًا على المشروعات واحتياجات العملاء:

• الاندماج الكامل في عملية التطوير (CI / CD).
• التدقيق الأمني ​​عند نقاط التفتيش.
• التدقيق الأمني ​​أو لمرة واحدة.

الاندماج الكامل في عملية التنمية

قمنا بدمج الحل في GitLab. تستخدم GitLab CI / CD لأتمتة إطلاق الشيكات. هذا يتطلب البرنامج المساعد Sonar GitLab المساعد مجانا. يقوم النظام بإخطار مطوري الإلتزامات التي تفشل في التحقق ويضيف تعليقات تصف منطقة المشكلة (نوع الثغرة ، توصيات لإصلاحها ، وغيرها).
أحد المشروعات التي نفذت التكامل مع Bitbucket و Bamboo. في هذه الحالة ، كانت المكونات الإضافية المدفوعة Sonar for Bamboo و Sonar for Bitbucket Server مطلوبة. بعد إجراء الاختبار ، كان العميل مستعدًا لتغطية تكاليف إضافية ، حيث يتناسب الحل تمامًا مع المجموعة التكنولوجية.



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

نقطة تفتيش الأمن التدقيق

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

ما علاقة نقاط التحكم:

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

في المشاريع الرئيسية ، بدأنا في الجمع بين التحليل المتكامل وعمليات تدقيق الأمان عند نقاط التوقف. وبالتالي ، نحدد نقاط الضعف التي قد تمر مرور الكرام أثناء عملية التطوير.

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

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

التدقيق الأمني ​​أو لمرة واحدة

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

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

هذا هو نتيجة لمسح مشروع لم يخضع لمراجعة كاملة للأخطاء والأمان لعدة سنوات:



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



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

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

لم نتوقف عند هذا الحد:

• وأضاف تحليل لمعظم المشاريع.
• تم استكمال أدوات التحكم في الأمن بواسطة appScreener من Rostelecom-Solar.
• وأضاف التدقيق اليدوي واختبار القلم للمشاريع الرئيسية.
• تم تقديم مجموعات من المعايير ومستويات الأهمية للوظيفة المنفذة من حيث التأثير على أمان التطبيق.

إذن ماذا بعد؟

الجهود التي بذلت لتطبيق أمن المعلومات في عمليات التطوير المخصصة قد أفادتنا:

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

كلما تحركنا صوب تحسين أمن المعلومات ، كلما رأينا نقاطًا للنمو: أضف إلى إجراءاتنا ليس فقط اختبارات TOP-10 OWASP و CWE / SANS ، ولكن على سبيل المثال ، ربط تتبع نشرات الأمان أو تعليم CI الخاص بنا لاستخدام دليل الأمان الخاص الأطر لدينا.

لقد عقدنا بالفعل أول حدث IB لدينا ( Rostelecom-Solar Business Dinner - AGIMA ) ، وكتبنا هذا المقال ونخطط لمواصلة تقديم ممارسات جديدة إلى السوق لدينا ، كما فعلنا مع التصميم التكيفي في عصرنا (انظر Adaptoz أو قاموسنا التكيفي التصميم ، الذي تم إصداره في عام 2013) - بدأ معنا هذا الاتجاه ، وأصبح الآن هو المعيار الفعلي. نريد أن نفعل الشيء نفسه مع أمن المعلومات ، لأنه "عندما تعلم الآخرين ، تتعلم نفسك".