حاليًا ، كجزء من تنفيذ استراتيجية التطوير والتحول الرقمي الجديدة ، تعمل VTB بنشاط على تنفيذ DevOps ، حيث تقوم بدمج ممارسة تطوير البرامج الآمنة في العملية الهندسية ، وزيادة مستوى التشغيل الآلي ، وتحسين عمليات الإنتاج الروتينية. يمكن صياغة الغرض من هذه التغييرات في ثلاث نقاط رئيسية: السرعة والموثوقية والكفاءة. بطبيعة الحال ، عند إجراء مثل هذه التحولات العالمية ، يصبح من المهم عقد اجتماعات غير رسمية مفتوحة ، يمكنك من خلالها مشاركة تجربتك الخاصة ، ومناقشة مفترق الطرق المختلفة والفروق الدقيقة في تقديم ممارسات الإنتاج المختلفة. Mitapas هي تنسيق ممتاز لزيادة المشاركة الشاملة والوعي وتبادل الخبرات مع كل من الزملاء من البنك ومع الشركاء من الشركات الأخرى.
تحت القصاص - الأكثر إثارة للاهتمام من أول اجتماع VTB "DevSecOps: إجابات عملية على الأسئلة غير التافهة" ، الذي عقد في نوفمبر تشرين الثاني في موقع WeWork. حضر الاجتماع أكثر من 200 متخصص.
كيف بدأ كل شيء
كما تعلم ، VTB هو البنك الثاني في روسيا من حيث عدد العملاء والأصول والمؤشرات المالية. منذ عام 2018 ، بدأ البنك ، كجزء من استراتيجية التطوير ، في تغيير مساره التكنولوجي بفاعلية وقرر الانتقال التدريجي إلى التطوير الداخلي لأنظمة تكنولوجيا المعلومات. قبل ذلك ، تم توفير معظم الأنظمة والحلول من قبل البائعين. الآن أصبح من المهم تحسين الجودة والأمان وسرعة عمليات التسليم من خلال تشكيل فرق داخلية وبناء عملية تكنولوجيا المعلومات الخاصة بالإنتاج. يبدو أن كل شيء بسيط وواضح: هناك حالات ، هناك حلول - خذ و نفذ.
ولكن في الواقع ، كل شيء أكثر تعقيدًا. على هذا المسار ، كان على البنك مواجهة العديد من الصعوبات. تحدث إيغور شفاكوف ، رئيس قسم أتمتة عملية تطوير VTB ، عن هذا في تقريره.
التحدي الرئيسي هو تفرد VTB من حيث تكنولوجيا المعلومات. تاريخيا ، طور البنك من خلال الاستحواذ والتكامل مع اللاعبين الكبار ، كل منهم كان له بنية تكنولوجيا المعلومات الخاصة به ، الأجهزة ، العمليات التجارية ، إلخ. منذ عام 2018 ، أصبح VTB ، VTB24 وبنك موسكو واحد VTB مع تكنولوجيا المعلومات الفريدة الخاصة به المناظر الطبيعية ، غير متجانسة ، والبنية التحتية معزولة في مكان ما. بطبيعة الحال ، لتنفيذ التغييرات التحويلية ، في وقت واحد بناء الأعمال (مثل استراتيجية العمل) وتنفيذ DevOps (وخاصة DevSecOps) في مثل هذه الظروف هي قصة غير تافهة.
تتمثل الصعوبة الأولى التي نشأت في البداية في وجود عدد كبير من البائعين ، ونتيجة لذلك ، فإن الكفاءة الضيقة الخاصة بهم. نحن بحاجة إلى نقل المقاولين الخارجيين الذين عملوا خارج المحيط إلى البنية التحتية وعمليات البنك. الصعوبة الثانية هي أن العملاء من رجال الأعمال طالبوا بالتطوير النشط لأنظمة تكنولوجيا المعلومات لضمان تحقيق أداء أعمال عالي. لذلك ، كان علينا أن نعمل في ظل تزايد نشاط المعاملات للعملاء والاعتماد الكبير على الأنظمة.
في البداية ، خططنا لإجراء الانتقال إلى السكك الحديدية الداخلية تدريجيًا: تحديد الأنظمة وتحديد الأهداف ، ثم إعداد الفرق والبنية التحتية ، وفي المرحلة الأخيرة ، حدد الأدوات وقم بتكوين DevSecOps Pipeline. ولكن في الواقع ، كان علينا أن نفعل كل شيء دفعة واحدة ، وفي نفس الوقت حل المشاكل التي تنشأ.
تجربة النسخ المتماثل للنظام
نظرًا لأننا لم يكن لدينا البنية التحتية للتطوير الداخلي ، فقد تقرر إضفاء الطابع الافتراضي على كل شيء والتحول إلى بنية x86 لتقليل التكلفة والنفقات. كنتيجة لذلك ، تم إنشاء نظام أساسي للبنية التحتية على أساس حل Nutanix شديد التضمين الموجود بالفعل ، ونقلنا جميع أدوات التطوير إليه قدر الإمكان.
لكن الحديد هو الحديد ، والناس يعملون عليه. في هذا الصدد ، نشأ سؤال حول كيفية تشكيل الفرق. قررنا التركيز على العلاقات التالية: يجب أن يكون لدى اثنين من المطورين الداخليين تقني واحد ، وفريق من 10 مطورين يجب أن يكون لديهم مهندس DevOps واحد واختباران للأتمتة. هذا هو ما توصلنا إليه لتجربتنا الخاصة ، بالعمل مع أكثر من عشرين نظامًا. وكان هذا النهج فعال جدا.
السؤال المثير للاهتمام التالي هو كيفية نقل الأنظمة إلى الدائرة المصرفية.
كقاعدة عامة ، تستغرق دورة الترجمة القياسية لنظام واحد من 7 إلى 8 أشهر. وضعت على النحو التالي.
- خلال الشهرين الأولين ، هناك اختيار للموظفين. في الوقت نفسه ، يتم تحليل العلاقات التعاقدية مع المقاولين الخارجيين لإمكانية نقلهم للعمل في الدائرة المصرفية.
- بحلول الشهر الثالث ، يتم تشكيل الكفاءة الأساسية في النظام ويتم الانتهاء من فريق DevOps من حيث التطوير وإعداد خطوط الأنابيب والاختبار الآلي. في الوقت نفسه ، يتم تنظيم الوصول إلى أنظمة المعلومات للفرق الخارجية وتوفيره.
- الشهر الرابع - تدريب الفريق ونقل الرمز إلى مستودع البنك من البائع.
- خامساً - التطوير المشترك من قبل فرق البنك والمقاول الخارجي وصقل خط الأنابيب وإطلاق أول شحنات عليه.
- في الشهرين السادس والسابع ، تجري المراجعات التجريبية العملية بأكملها مباشرةً على البنية التحتية للبنك.
- النتيجة - للشهر السابع ، يعمل الفريق المشترك بالفعل ضمن نفس حلقة التطوير في البنك.
تبين التجربة أنه من خلال هذا النهج ، يمكن تنظيم فرق جيدة التنسيق وتنفيذ عدد كبير من المشاريع في سنة ونصف. بكلمات ، كل شيء على ما يرام ، ولكن في عملية الانتقال واجهنا مشاكل. واحد منهم هو حجم كبير من فرق من مزود خارجي. على سبيل المثال ، يتألف فريق أحد البائعين من أكثر من 200 مطور. الآن يعمل معظمهم ضمن دائرة مشتركة على البنية التحتية المصرفية. وكان هناك العديد من الفروق الدقيقة مماثلة.
في الوقت الحالي ، يوجد لدى البنك بالفعل أكثر من عشرين فريق تطوير (أكثر من 500 مطور بدوام كامل وخارجي) ، يستخدم كل منهم خط أنابيب خاص به من حيث CI. بالنسبة لمعظم هذه الأوامر ، يتم تنفيذ خطوة القرص المضغوط. هناك أيضًا العديد من الأنظمة التي تستخدم بالفعل التسليم التلقائي للتغييرات في الدوائر الصناعية.
مكنت الأساليب المنفذة من بناء خط أنابيب وتطوير النقل إلى القطاع الداخلي ، ليس فقط للأنظمة الجديدة ذات بنية الخدمة الدقيقة المرنة ، ولكن أيضًا لعدد كبير من الأنظمة المتجانسة المعقدة القائمة على حلول "محاصر" تم تكييفها مع متطلبات البنك.
منذ البداية ، لم نبحث عن طرق سهلة وأثبتنا أنه من خلال الكفاءات المناسبة للموظفين ، يمكنك تنفيذ ممارسات DevOps لأي نظام من أي تعقيد.
الآن تكتسب العملية زخماً ، ويتم إضافة أنظمة جديدة ، والمكدس التكنولوجي موحد ، ومراحل واحدة من خط الأنابيب ، وإعداد التقارير ، وقواعد العمل. أيضًا ، ينتقل النهج المتبع في تكرار الممارسات للفرق والكتل الأخرى في البنك إلى مستوى جديد من النضج ، ويجري تحسين العمليات ، وتحديد الأدوار والكفاءات اللازمة داخل الفرق ، وتحديد مسؤولية المشاركين. بشكل عام ، تم وضع عملية النسخ المتماثل على القضبان ويتم تحويلها من بدء التشغيل داخل أحد البنوك الكبيرة إلى حل مؤسسة ذات تكنولوجيا عالية. تمت تغطية هذا المسار في أكثر من عام ونصف بقليل من لحظة تثبيت الحديد في مركز البيانات إلى طرح التغييرات في الوضع التلقائي على الدائرة الصناعية أو ما قبل الصناعة.
المزالق
كجزء من الاستراتيجية الجديدة لـ VTB ، تم اعتبار الانتقال إلى ممارسات DevSecOps كأحد التدفقات الاستراتيجية على مستوى البنك. ألكساندر كالابوخوف ، رئيس مركز الممارسات الهندسية في قسم تطوير نظم إنتاج تكنولوجيا المعلومات وصيانة VTB ، تحدث عن هذا في تقريره.
تقرر تحويل الخدمات المتعلقة بالتطوير والاختبار والتشغيل إلى فرق متعددة الوظائف تعمل على نفس وظائف الأعمال. تشمل الفرق متخصصين في الهندسة المعمارية والتطوير ، وخبراء تقنية ، ومهندسين ، ومهندسي DevOps. في الخدمات المركزية ، يبقى فقط الذي لديه كفاءات فريدة أو يعيش في إيقاع فريد (24/7) - تطبيق وإدارة النظام ، وأمن المعلومات.
يقدم هذا الانتقال إلى فرق متعددة الوظائف متطلبات جديدة لعمليات إدارة الكود (المصدر ، الاختبار ، النشر ، إلخ) ، وإدارة الاختبار والتطوير. عندما كانت فجوات العملية مسموحًا بها في السابق ، أصبحت الآن عقبات حرجة ، ونحن نعمل على تحسين المشهد DevSecOps لدينا من حيث الأدوات وسد الفجوات في العملية.
يتحدث عن الأدوات. تتمثل إحدى المشكلات في أن البنوك تندرج تحت بعض المتطلبات التنظيمية المتعلقة بالسرية المصرفية وغيرها من القيود المماثلة. يجتاز أي نظام في البنك مرحلة اختبارات القبول للامتثال لمتطلبات أمن المعلومات ، بما في ذلك أدوات DevOps. لسوء الحظ ، لم يعمل معظم مهندسي DevOps أبدًا في مثل هذه البيئة المنظمة الصارمة ، وهم غالبًا ما يعرفون القليل عن تدقيق هذه الأدوات ، وكيف يجب أن يكون الوصول إلى الشبكة والوصول إلى البيانات محددين ، وماذا تفعل مع الأسرار المتبادلة بين أدوات DevOps وم. ع.
تتمثل المهمة الرئيسية لبناء حماية البيانات داخل البنك في ضمان عدم وصول أي شخص إلى جميع البيانات في وقت واحد. هذا هو السبب في أن المطورين لا يستطيعون أداء وظائف مسؤولي التطبيق والنظام. توجد قيود مماثلة لمهندسي DevSec. بطبيعة الحال ، لا يمكن لأي من هؤلاء المتخصصين أن يكون مسؤولًا عن أمن المعلومات. بمجرد تحديد جميع الأدوار ومحيط سلطتها ، يمكنك تضمين العملية القياسية لمنح حقوق أداة DevOps للعملية العامة لمنح الحقوق في أحد البنوك.
جانب مهم هو أمن الشبكة. يجب عليك الامتثال للقاعدة القائلة بأنه لا يمكن إجراء اتصال إلا من دوائر أكثر موثوقية إلى دوائر أقل ثقة. إذا تم تنفيذ العملية في الاتجاه المعاكس ، فمن الضروري توفير ثغرات الشبكة باستخدام وسائل خاصة. يجب أن يتم تأسيس اتصالات الشبكة بشكل آمن وأن تظل مشفرة فيما بينها. خلاف ذلك ، يمكن أن تدخل الفيروسات والبرامج الضارة الأخرى في السلسلة ، مما قد يؤدي إلى تسرب البيانات والحوادث في البيئات الصناعية.
تتأثر مشكلات الأمان بالطريقة التي يتم بها تنظيم البيانات ، نظرًا لوجود العديد من بيئات التطوير والاختبار ، هناك حاجة إلى الانضمام إلى دائرة البنك عبر VPN حتى يتسنى للمقاولين العمل من خلال أجهزة الكمبيوتر المحمولة الخاصة بهم. بالإضافة إلى ذلك ، هناك دوائر خاصة يُسمح فيها بالوصول إلى دائرة محدودة من الأشخاص ، ويجب ألا تتجاوز البيانات هذه الدوائر.
لذلك ، على الرغم من ثراء أدوات DevOps الحالية ، من الضروري توحيدها. مع النهج الصحيح ، يفرض أمن المعلومات في البنك قيودًا على عملية التطوير والتشغيل ، ولكنه لا يمنع إدخال تقنيات جديدة.
الأمن السيبراني قبل كل شيء
في سياق تحول الأعمال ووقت أقصر لإطلاق منتجات رقمية جديدة في السوق ، يتمثل التحدي الصناعي الرئيسي في ضمان أمن المعلومات في جميع مراحل عملية الإنتاج المستمرة. كان موضوع دمج ممارسات تطوير البرمجيات الآمنة في DevOps موضوع تقرير أعده يوري سيرجييف ، الشريك الإداري لشركة Swordfish Security وزعيم صناعة DevSecOps في روسيا.
يعد تنفيذ نموذج الأمن السيبراني في DevOps عملية معقدة إلى حد ما ، حيث تغطي طبقة ممارسات الأمان دورة هندسة الإنتاج بأكملها. يتم دعم ممارسات أمن المعلومات بأنفسهم من خلال مجموعة أدوات متكاملة مدمجة في جميع مراحل العملية.
تتضمن ممارسات IS اللازمة:
- التحكم في مكونات المصدر المفتوح عندما تقع في محيط التطوير (تحليل المصدر المفتوح ، OSA) ؛
- تحليل الشفرة الثابتة (اختبار أمان التطبيق الثابت ، SAST) ؛
- مراقبة تكوين مكونات البرنامج (تحليل تكوين البرامج ، SCA) ؛
- جميع أنواع التحليل الديناميكي (اختبار أمان التطبيق الديناميكي ، واختبار أمان التطبيقات التفاعلية / DAST ، واختبار أمان التطبيق السلوكي / IAST / BAST) ؛
- تحليل الرمز الثنائي والتحكم في تكوين الحاوية (Bytecode و Container Analysis، BCA) ؛
- تنفيذ WAF (جدار حماية تطبيق الويب).
في الوقت نفسه ، فإن أهم الجوانب عند توسيع نطاق عمليات DevOps وتحويلها إلى نموذج DevSecOps المشتق هي:
- استخدام المكتبات والأطر ومكونات البرامج الآمنة بشكل افتراضي أثناء عملية التطوير (Secure-by-Default) ؛
- تكامل ممارسات تكنولوجيا المعلومات في بداية خط أنابيب CI / CD (طريقة التحول إلى اليسار) ؛
- أتمتة جميع العمليات في مفهوم كل شيء ككود ؛
- تشكيل مجتمع من أبطال الأمن المسؤولين عن مهام أمن المعلومات في فرق الإنتاج وهم مرشدون لثقافة الأمن الهندسي ؛
- تطبيق نموذج نضج DevSecOps لتقييم العملية الحالية والتحسين المستمر ؛
- ضمان شفافية جميع الأنشطة الأمنية لجميع المشاركين في عملية الإنتاج الهندسي.
بشكل منفصل ، يجدر التأكيد على أهمية ممارسة DevSecOps-orchestration (تطبيق اختبار أمان التطبيق ، ASTO) ، والذي يوفر التكامل من طرف إلى آخر من مكدس أداة IS مع أدوات التطوير ، والإدارة الآلية لخط أنابيب الأمان (خطوط الأنابيب) ، وكذلك جمع وتوحيد وتحليل جميع البيانات بشكل مستمر عملية تطوير البرمجيات الآمنة. يمكن أن تؤدي ممارسة التنسيق إلى توفير الموارد بشكل كبير وتقليل وقت تنفيذ مبادرة DevSecOps بأكثر من 10 أضعاف في بيئات هندسية غير متجانسة معقدة.
إذا تحدثنا عن التحول ككل ، فيمكننا تمييز عوامل النجاح الرئيسية التالية:
- يعد إدخال أداة أو عنصر منفصل في عملية الأمن السيبراني ، بطبيعة الحال ، خطوة مهمة ، ولكن ليس بأي حال من الأحوال بمثابة رصاصة فضية لمعالجة قضايا الأمان الخاصة بالبرمجيات المطورة على نطاق صناعي. مفتاح النجاح هو التطبيق المتكامل لمجموعة كاملة من ممارسات أمن المعلومات.
- سيحمي تطبيق ممارسة الأوركسترا الفرق الهندسية وفريق أمن المعلومات من الفوضى التكنولوجية المتمثلة في تكامل الأدوات "عالية الركبة" والأتمتة "المرقعة" غير الخاضعة للرقابة.
- سيتيح لك جمع البيانات والتصور اللاحق للمقاييس إدارة العملية الشاملة ، وتحقيق الشفافية الكاملة ، وكذلك إنشاء الأساس اللازم لتطبيق ممارسات التعلم الآلي في المستقبل.