نحن نبني تطويرًا آمنًا في بائع تجزئة. تجربة مشروع واحد كبير

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







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



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



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



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

البوابات وتطبيقات الجوال

يبدو أن كل هذه التطبيقات مجتمعة في مجموعة منطقية واحدة ، لكنها في الواقع كانت في حالة فوضى رهيبة. كان هناك أكثر من 120 بوابة (!). الشركة كبيرة جدًا ، بها العديد من الإدارات التجارية والإدارية والفنية ، ومن وقت لآخر يقرر كل منهم أنه يحتاج إلى بوابته وتطبيق الهاتف المحمول الخاص به. تم إنشاء هذه البوابة والتطبيق ، واستخدامهما لبعض الوقت ، ثم تم التخلي عنها بأمان. نتيجة لذلك ، في المرحلة الأولية ، كان علينا إجراء جرد للعميل ، لأنه حتى مطوري هذه التطبيقات لم يكن لديهم قائمة واحدة من قواعد التعليمات البرمجية. على سبيل المثال ، لإدارة المستودعات في هذه المجموعة ، استخدم المطورون اثنين من GitLabs مع مسؤولين مختلفين. بالإضافة إلى ذلك ، بين البوابات وتطبيقات الهاتف المحمول ، تم تنفيذ جزء كبير من المشاريع باستخدام التطوير الخارجي.لذلك ، عندما يقترب وقت الإصدار ، غالبًا ما ينقل المقاولون رموز المصدر للإصدار الجديد إلى الشركة تقريبًا على محرك أقراص USB محمول. نتيجة لذلك ، كان لدى الشركة حديقة حيوان من التطبيقات المختلفة وفوضى كاملة في التعليمات البرمجية الخاصة بهم. كان علينا إعداد قائمة بجميع المشاريع ، والعثور على جميع المسؤولين عنها - الملاك الفنيون ، وقيادة الفريق ، ثم الاتفاق مع العميل الرئيسي - قسم أمن المعلومات ، أي منهم سنحلله.



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



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

التكامل حسب المخطط القياسي

تم استخدام GitLab من نسختين مختلفتين كنظام للتحكم في الإصدارات في مجموعة البوابات وتطبيقات الهاتف المحمول.





إعداد التكامل مع GitLab



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



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



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





إعداد تكامل Jira



في حالات نادرة ، نظر قادة الفريق إلى نتائج الزحف بأنفسهم وبدأوا المهام في Jira يدويًا.





إنشاء مهمة في Jira



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



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





نتائج التحليل ومهام إصلاح الثغرات الأمنية التي تم إنشاؤها في Jira



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

غير قياسي كمعيار

للوهلة الأولى ، هذه العملية غير المعقدة لها حدان خطيران. أولاً ، لتحليل تطبيقات Android (أي المكتوبة بلغة Java) ، نحتاج إلى تجميع. وثانيًا ، احتاج iOS إلى أجهزة macOS سيتم تثبيت وكيلنا عليها وستكون هناك بيئة تسمح لنا ببناء التطبيقات. تعاملنا مع تطبيقات Android بكل بساطة: لقد كتبنا أجزائنا في البرامج النصية المتاحة بالفعل للمطورين ، والتي تم إطلاقها أيضًا وفقًا للجدول الزمني. بدأت الأجزاء الخاصة بنا من البرامج النصية مسبقًا في بناء المشروع بأوسع تكوين ، والذي تم إرساله إلى Solar appScreener لتحليله. للتحقق من تطبيقات iOS ، قمنا بتثبيت وكيل MacOS الخاص بنا على جهاز Mac ، والذي قام بتجميع الرمز وأرسل أيضًا الرمز إلى المحلل للمسح عبر GitLab CI. علاوة على ذلك ، كما هو الحال مع أنواع البرامج الأخرى ،قام ضابط الأمن بمراجعة نتائج التحليل والتحقق منها ورفع مشكلات الإصلاح إلى جيرا.



أشرنا أيضًا إلى البوابات وتطبيقات الهاتف المحمول على أنها أي مشاريع مكتوبة بلغة Java - قمنا بجمعها وتحليلها بطريقة مماثلة.



في تلك المشاريع التي لم يكن فيها CI / CD ، والذي كان شرطًا أساسيًا لنا ، قلنا ببساطة: "أيها الرجال ، إذا كنت ترغب في تحليلها ، فجمعها يدويًا وقم بتحميلها في الماسح الضوئي بنفسك. إذا لم يكن لديك Java أو لغات شبيهة بلغات JVM - Scala و Kotlin وغيرها ، يمكنك ببساطة تحميل الكود إلى المستودع من الرابط ، وسيكون كل شيء على ما يرام. "

تعقيد المشروع

كما ترون مما سبق ، في حزمة التطبيقات هذه ، كانت المشكلة الرئيسية هي عدم وجود CI / CD في العديد من المشاريع. المطورين في كثير من الأحيان يبني باليد. بدأنا في دمج محللنا مع بوابات Sharepoint في C #. الآن تحولت C # أكثر أو أقل إلى أنظمة Linux ، على الرغم من أنها ليست كاملة تمامًا. وعندما كان المشروع على قدم وساق ، كانت هذه اللغة لا تزال تعمل على Windows ، وكان علينا تثبيت وكيل على Windows لـ GitLab. كان هذا تحديًا حقيقيًا حيث اعتاد المتخصصون لدينا على استخدام أوامر Linux. كانت هناك حاجة إلى حلول خاصة ، على سبيل المثال ، في بعض الحالات كان من الضروري تحديد المسار الكامل لملف exe ، في بعض الحالات - لا ، كان لابد من هروب شيء ما ، إلخ. وبعد تنفيذ التكامل مع Sharepoint قال فريق مشروع تطبيقات الهاتف المحمول في PHP:أنه ليس لديهم أيضًا عداء ويريدون استخدام C # -ovskiy. اضطررت إلى تكرار العمليات لهم.

ملخص

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

• الحل الذي ننفذه قديمًا بما يكفي ليكون مرنًا بما يكفي لبناء عمليات DevSecOps في بيئات نشر مختلفة جذريًا. تتحقق المرونة من خلال مجموعة كبيرة من عمليات الدمج المدمجة والمخصصة ، والتي بدونها ستزداد تكاليف العمالة للتنفيذ بشكل كبير أو تجعلها مستحيلة ؛
• . 3-4 ;
• DevSecOps DevOps , , . win-win - .

استدعاء: هذا هو الجزء الأول من سلسلة مقالات حول بناء عملية تطوير آمنة في بائع تجزئة كبير. في المنشور التالي ، سنكشف عن تفاصيل تنفيذ هذا المشروع في مجموعة التطبيقات لعائلة SAP.



هل كانت لديك تجربتك الخاصة في تنفيذ مشاريع مماثلة؟ سنكون سعداء إذا شاركت معنا حالاتك الخاصة بتطبيق ممارسات التطوير الآمن في التعليقات!



المؤلف: إيفان ستاروسيلسكي ، رئيس قسم أتمتة وتشغيل نظم المعلومات