يقوم البنك بالاستعانة بمصادر خارجية لمشاريعه للعديد من المقاولين. "الخارجيون" يكتبون التعليمات البرمجية، ثم ينقلون النتائج بشكل غير مناسب للغاية. على وجه التحديد، بدت العملية على النحو التالي: قاموا بتسليم مشروع اجتاز الاختبارات الوظيفية معهم، ثم تم اختباره داخل المحيط المصرفي من أجل التكامل والتحميل وما إلى ذلك. وكثيرا ما اكتشف أن الاختبارات كانت فاشلة. ثم عاد كل شيء إلى المطور الخارجي. كما يمكنك التخمين، كان هذا يعني فترات زمنية طويلة لإصلاح الأخطاء.
قرر البنك أنه من الممكن والضروري سحب خط الأنابيب بأكمله تحت جناحه، من الالتزامات إلى الإصدار. بحيث يكون كل شيء موحداً وتحت مراقبة الفرق المسؤولة عن المنتج في البنك. أي كما لو أن المقاول الخارجي كان يعمل ببساطة في مكان ما في الغرفة المجاورة للمكتب. على كومة الشركات. هذا هو المطورين العاديين.
من أين أتت سيك؟ لقد وضع أمن البنك متطلبات عالية على كيفية عمل المقاول الخارجي في قطاع الشبكة، وما هو الوصول الذي يتمتع به شخص ما، وكيف ومن يعمل مع الكود. كل ما في الأمر أن البكالوريا الدولية لم تكن تعلم بعد أنه عندما يعمل المقاولون في الخارج، يتم اتباع القليل من المعايير المصرفية. وبعد ذلك في غضون يومين، سيحتاج الجميع إلى البدء في مراقبتهم.
إن الكشف البسيط عن أن المقاول لديه حق الوصول الكامل إلى رمز المنتج قد قلب عالمه رأسًا على عقب.
في هذه اللحظة بدأت قصة DevSecOps التي أريد أن أخبركم عنها.
ما هي الاستنتاجات العملية التي استخلصها البنك من هذا الوضع؟
كان هناك الكثير من الجدل حول حقيقة أن كل شيء يتم بطريقة خاطئة. قال المطورون إن الأمن مشغول فقط بمحاولة التدخل في التطوير، وهم، مثل الحراس، يحاولون الحظر دون تفكير. وبدورهم، تردد المتخصصون في مجال الأمن بين الاختيار بين وجهتي النظر: "المطورون يخلقون نقاط الضعف في دائرتنا" و"المطورون لا يخلقون نقاط الضعف، بل هم أنفسهم". كان من الممكن أن يستمر النزاع لفترة طويلة لولا متطلبات السوق الجديدة وظهور نموذج DevSecOps. كان من الممكن توضيح أن هذه الأتمتة ذاتها للعمليات مع مراعاة متطلبات أمن المعلومات "خارج الصندوق" ستساعد الجميع على البقاء سعداء. بمعنى أن القواعد تُكتب فورًا ولا تتغير أثناء اللعبة (أمن المعلومات لن يمنع شيئًا غير متوقع)، ويبقي المطورون أمن المعلومات على اطلاع بكل ما يحدث (أمن المعلومات لا يواجه شيئًا فجأة) . كل فريق مسؤول أيضًا عن السلامة النهائية، وليس بعض الإخوة الأكبر سنًا.
- نظرًا لأن الموظفين الخارجيين لديهم بالفعل إمكانية الوصول إلى الكود وعدد من الأنظمة الداخلية، فمن المحتمل أن يكون من الممكن إزالة شرط "يجب أن يتم التطوير بالكامل على البنية التحتية للبنك" من المستندات.
- ومن ناحية أخرى، نحن بحاجة إلى تعزيز السيطرة على ما يحدث.
- كان الحل الوسط هو إنشاء فرق متعددة الوظائف، حيث يعمل الموظفون بشكل وثيق مع أشخاص خارجيين. في هذه الحالة، عليك التأكد من أن الفريق يعمل على الأدوات الموجودة على خوادم البنك. من البداية إلى النهاية.
أي أنه يمكن السماح للمقاولين بالدخول، لكن يجب منحهم شرائح منفصلة. حتى لا يجلبوا أي نوع من العدوى من الخارج إلى البنية التحتية للبنك وحتى لا يروا أكثر مما هو ضروري. حسنًا، حتى يتم تسجيل أفعالهم. DLP للحماية من التسربات، تم تضمين كل هذا.
من حيث المبدأ، تأتي جميع البنوك إلى هذا عاجلا أم آجلا. هنا سلكنا الطريق المطروق واتفقنا على متطلبات مثل هذه البيئات التي تعمل فيها "القوى الخارجية". ظهر الحد الأقصى لمجموعة أدوات التحكم في الوصول وأدوات التحقق من الثغرات الأمنية وتحليل مكافحة الفيروسات على الدوائر والتجمعات والاختبارات. وهذا ما يسمى DevSecOps.
وفجأة أصبح من الواضح أنه إذا لم يكن للأمن المصرفي قبل DevSecOps أي سيطرة على ما يحدث من جانب المطور، فإنه في النموذج الجديد يتم التحكم في الأمان بنفس الطريقة التي يتم بها التحكم في الأحداث العادية على البنية التحتية. الآن فقط توجد تنبيهات بشأن التجميعات والتحكم في المكتبات وما إلى ذلك.
كل ما تبقى هو نقل الفرق إلى النموذج الجديد. حسنًا، قم بإنشاء البنية التحتية. لكن هذه تفاهات، مثل رسم بومة. في الواقع، لقد ساعدنا في البنية التحتية، وفي ذلك الوقت كانت عمليات التطوير تتغير.
ما الذي تغير
قررنا تنفيذه بخطوات صغيرة، لأننا أدركنا أن العديد من العمليات سوف تنهار، وأن العديد من "الخارجيين" قد لا يتمكنون من تحمل ظروف العمل الجديدة تحت إشراف الجميع.
أولاً، أنشأنا فرقًا متعددة الوظائف وتعلمنا كيفية تنظيم المشاريع مع مراعاة المتطلبات الجديدة. بمعنى تنظيميا ناقشنا ما هي العمليات. وكانت النتيجة رسمًا تخطيطيًا لخط أنابيب التجميع مع جميع المسؤولين.
- CI: Git، Jenkins، Maven، Roslyn، Gradle، jUnit، Jira، MF Fortify، CA Harvest، GitlabCI.
- CD: Ansible، Puppet، TeamCity، Gitlab TFS، Liquidbase.
- اختبار: Sonarqube، SoapUI، jMeter، السيلينيوم: MF Fortify، مركز الأداء، MF UFT، Ataccama.
- العرض (الإبلاغ والتواصل): Grafana، Kibana، Jira، Confluence، RocketChat.
- عمليات (الصيانة والإدارة): Ansible، Zabbix، Prometheus، Elastic + Logstash، MF Service Manager، Jira، Confluence، MS Project.
المكدس المحدد:
- قاعدة المعرفة - التقاء الأطلسي؛
- تعقب المهام - أتلاسيان جيرا؛
- مستودع القطع الأثرية - "نيكزس" ؛
- نظام التكامل المستمر - "Gitlab CI"؛
- نظام التحليل المستمر - "SonarQube"؛
- نظام تحليل أمان التطبيقات - "Micro Focus Fortify"؛
- نظام الاتصالات - "GitLab Mattermost"؛
- نظام إدارة التكوين - "Ansible"؛
- نظام المراقبة - "ELK"، "TICK Stack" ("InfluxData").
بدأوا في إنشاء فريق جاهز لسحب المقاولين إلى الداخل. هناك إدراك أن هناك عدة أشياء مهمة:
- يجب أن يكون كل شيء موحدًا، على الأقل عند إرسال التعليمات البرمجية. لأنه كان هناك العديد من المقاولين بقدر ما كانت هناك العديد من عمليات التطوير المختلفة التي لها خصائصها الخاصة. كان من الضروري أن تناسب الجميع في واحد تقريبا، ولكن مع الخيارات.
- هناك العديد من المقاولين، والإنشاء اليدوي للبنية التحتية غير مناسب. يجب أن تبدأ أي مهمة جديدة بسرعة كبيرة - أي أنه يجب نشر المثيل على الفور تقريبًا حتى يكون لدى المطورين مجموعة من الحلول لإدارة تدفقاتهم.
لاتخاذ الخطوة الأولى، كان من الضروري فهم ما يجري القيام به. وكان علينا أن نحدد كيفية الوصول إلى هناك. لقد بدأنا بالمساعدة في رسم بنية الحل المستهدف في كل من البنية التحتية وأتمتة CI/CD. ثم بدأنا في تجميع هذا الناقل. كنا بحاجة إلى بنية تحتية واحدة، متماثلة للجميع، حيث سيتم تشغيل نفس الناقلات. لقد عرضنا خيارات مع الحسابات، فكر البنك، ثم قررنا ما سيتم بناؤه وبأي أموال.
التالي هو إنشاء الدائرة - تثبيت البرنامج والتكوين. تطوير البرامج النصية لنشر البنية التحتية وإدارتها. بعد ذلك يأتي الانتقال إلى دعم الناقل.
قررنا اختبار كل شيء على الطيار. ومن المثير للاهتمام أنه أثناء التجربة، ظهرت كومة معينة في البنك لأول مرة. ومن بين أمور أخرى، تم عرض بائع محلي لأحد الحلول لنطاق الإصدار التجريبي من أجل الإطلاق السريع. تعرف عليه الأمن أثناء قيادته، وترك انطباعا لا ينسى. عندما قررنا التبديل، لحسن الحظ، تم استبدال طبقة البنية التحتية بحل Nutanix، الذي كان موجودًا بالفعل في البنك من قبل. علاوة على ذلك، قبل ذلك كان مخصصًا لـ VDI، ولكننا قمنا بإعادة استخدامه لخدمات البنية التحتية. بكميات صغيرة لم تتناسب مع الاقتصاد، ولكن بكميات كبيرة أصبحت بيئة ممتازة للتطوير والاختبار.
بقية المكدس مألوفة للجميع إلى حد ما. تم استخدام أدوات الأتمتة في Ansible، وعمل متخصصو الأمن معهم بشكل وثيق. تم استخدام حزمة Atlassin من قبل البنك قبل المشروع. أدوات الأمان Fortinet - تم اقتراحها من قبل رجال الأمن أنفسهم. تم إنشاء إطار الاختبار من قبل البنك، دون طرح أي أسئلة. أثار نظام المستودع أسئلة، وكان علي أن أعتاد عليه.
تم منح المقاولين كومة جديدة. لقد منحونا الوقت لإعادة كتابته لـ GitlabCI، وترحيل Jira إلى القطاع المصرفي، وما إلى ذلك.
خطوة بخطوة
الخطوة 1. أولاً، استخدمنا حلاً من مورد محلي، حيث تم توصيل المنتج بقطاع شبكة DSO تم إنشاؤه حديثًا. تم اختيار المنصة بناءً على وقت التسليم ومرونة التوسع وإمكانية الأتمتة الكاملة. الاختبارات التي أجريت:
- إمكانية إدارة مرنة ومؤتمتة بالكامل للبنية التحتية لمنصة المحاكاة الافتراضية (الشبكة، النظام الفرعي للقرص، النظام الفرعي لموارد الحوسبة).
- أتمتة إدارة دورة حياة الجهاز الافتراضي (القوالب واللقطات والنسخ الاحتياطية).
بعد التثبيت والتكوين الأساسي للمنصة، تم استخدامها كنقطة وضع للأنظمة الفرعية للمرحلة الثانية (أدوات DSO، الخطوط العريضة لتطوير أنظمة البيع بالتجزئة). تم إنشاء المجموعات الضرورية من خطوط الأنابيب - إنشاء الأجهزة الافتراضية وحذفها وتعديلها ونسخها احتياطيًا. تم استخدام خطوط الأنابيب هذه كمرحلة أولى من عملية النشر.
والنتيجة هي أن المعدات المقدمة لا تلبي متطلبات البنك فيما يتعلق بالأداء وتحمل الأخطاء. قررت إدارة تكنولوجيا المعلومات التابعة للبنك إنشاء مجمع يعتمد على حزمة برامج Nutanix.
المرحلة 2. لقد أخذنا المكدس الذي تم تعريفه، وكتبنا التثبيت الآلي والبرامج النصية لما بعد التكوين لجميع الأنظمة الفرعية بحيث يتم نقل كل شيء من الإصدار التجريبي إلى الدائرة المستهدفة في أسرع وقت ممكن. تم نشر جميع الأنظمة في تكوين متسامح مع الأخطاء (حيث لا تقتصر هذه الإمكانية على سياسات ترخيص البائع) وتم توصيلها بالمقاييس والأنظمة الفرعية لجمع الأحداث. قام IB بتحليل الامتثال لمتطلباته وأعطى الضوء الأخضر.
المرحلة 3. ترحيل جميع الأنظمة الفرعية وإعداداتها إلى PAC الجديد. تمت إعادة كتابة البرامج النصية لأتمتة البنية التحتية، وتم الانتهاء من ترحيل أنظمة DSO الفرعية في وضع مؤتمت بالكامل. تمت إعادة صياغة ملامح تطوير الملكية الفكرية من خلال مسارات فرق التطوير.
الخطوة 4. أتمتة تثبيت برامج التطبيقات. تم تعيين هذه المهام من قبل قادة الفرق الجديدة.
الخطوة 5. استغلال.
الوصول عن بعد
طلبت فرق التطوير أقصى قدر من المرونة في العمل مع الدائرة، وتم طرح متطلبات الوصول عن بعد من أجهزة الكمبيوتر المحمولة الشخصية في بداية المشروع. كان لدى البنك بالفعل إمكانية الوصول عن بعد، لكنه لم يكن مناسبًا للمطورين. الحقيقة هي أن المخطط يستخدم اتصال المستخدم بـ VDI محمي. كان هذا مناسبًا لأولئك الذين يحتاجون فقط إلى البريد وحزمة المكتب في مكان عملهم. سيحتاج المطورون إلى عملاء كثيفين، وأداء عالٍ، مع الكثير من الموارد. وبالطبع، كان عليهم أن يكونوا ثابتين، لأن فقدان جلسة المستخدم لأولئك الذين يعملون مع VStudio (على سبيل المثال) أو SDK آخر أمر غير مقبول. أدى تنظيم عدد كبير من VDIs الثابتة السميكة لجميع فرق التطوير إلى زيادة تكلفة حل VDI الحالي بشكل كبير.
قررنا العمل على الوصول عن بعد مباشرة إلى موارد قطاع التطوير. تقوم Jira وWiki وGitlab وNexus ببناء واختبار المنصات والبنية التحتية الافتراضية. وطالب حراس الأمن بعدم السماح بالوصول إلا وفقًا لما يلي:
- استخدام التقنيات المتوفرة بالفعل في البنك.
- يجب ألا تستخدم البنية الأساسية وحدات تحكم المجال الموجودة التي تقوم بتخزين سجلات كائنات الحساب الإنتاجية.
- يجب أن يقتصر الوصول على تلك الموارد التي يطلبها فريق معين فقط (بحيث لا يتمكن فريق منتج واحد من الوصول إلى موارد فريق آخر).
- أقصى قدر من التحكم في RBAC في الأنظمة.
ونتيجة لذلك، تم إنشاء مجال منفصل لهذا الجزء. يضم هذا المجال جميع موارد قطاع التطوير، سواء بيانات اعتماد المستخدم أو البنية التحتية. تتم إدارة دورة حياة السجلات في هذا المجال باستخدام IdM الموجود في البنك.
تم تنظيم الوصول المباشر عن بعد على أساس المعدات الموجودة في البنك. تم تقسيم التحكم في الوصول إلى مجموعات إعلانية تتوافق معها قواعد السياقات (مجموعة منتجات واحدة = مجموعة واحدة من القواعد).
إدارة قوالب VM
تعد سرعة إنشاء حلقة التجميع والاختبار أحد مؤشرات الأداء الرئيسية التي يحددها رئيس وحدة التطوير، لأن سرعة إعداد البيئة تؤثر بشكل مباشر على وقت التنفيذ الإجمالي لخط الأنابيب. تم النظر في خيارين لإعداد صور VM الأساسية. الأول هو الحد الأدنى لأحجام الصور، وهو الإعداد الافتراضي لجميع منتجات النظام، والحد الأقصى من الامتثال لسياسات البنك فيما يتعلق بالإعدادات. والثانية هي الصورة الأساسية، التي تحتوي على برنامج POPPO عالي التحمل، والذي يمكن أن يؤثر وقت التثبيت بشكل كبير على سرعة تنفيذ خط الأنابيب.
تم أيضًا أخذ متطلبات البنية التحتية والأمن في الاعتبار أثناء التطوير - الحفاظ على تحديث الصور (التصحيحات، وما إلى ذلك)، والتكامل مع SIEM، وإعدادات الأمان وفقًا لمعايير البنك.
ونتيجة لذلك، تقرر استخدام الحد الأدنى من الصور لتقليل تكلفة تحديثها. يعد تحديث نظام التشغيل الأساسي أسهل بكثير من تصحيح كل صورة للإصدارات الجديدة من POPPO.
بناءً على النتائج، تم تشكيل قائمة بالحد الأدنى المطلوب لمجموعة أنظمة التشغيل، والتي يتم تحديثها من قبل فريق العمليات، وتكون البرامج النصية من المسار مسؤولة بالكامل عن تحديث البرنامج، وإذا لزم الأمر، قم بتغيير الإصدار من البرنامج المثبت - ما عليك سوى نقل العلامة المطلوبة إلى خط الأنابيب. نعم، يتطلب هذا أن يكون لدى فريق منتج devops سيناريوهات نشر أكثر تعقيدًا، ولكنه يقلل بشكل كبير من وقت التشغيل المطلوب لدعم الصور الأساسية، والتي قد تتطلب أكثر من مائة صورة VM أساسية للمحافظة عليها.
الوصول إلى الإنترنت
هناك حجر عثرة آخر في الأمن المصرفي وهو الوصول إلى موارد الإنترنت من بيئة التطوير. علاوة على ذلك، يمكن تقسيم هذا الوصول إلى فئتين:
- الوصول إلى البنية التحتية.
- وصول المطور.
تم تنظيم الوصول إلى البنية التحتية من خلال تفويض المستودعات الخارجية باستخدام Nexus. أي أنه لم يتم توفير الوصول المباشر من الأجهزة الافتراضية. هذا جعل من الممكن التوصل إلى حل وسط مع أمن المعلومات، والذي كان بشكل قاطع ضد توفير أي وصول إلى العالم الخارجي من قطاع التنمية.
يحتاج المطورون إلى الوصول إلى الإنترنت لأسباب واضحة (تدفق المكدس). وعلى الرغم من أن جميع الأوامر، كما هو مذكور أعلاه، لديها إمكانية الوصول عن بعد إلى الدائرة، إلا أنه ليس من المناسب دائمًا أن لا تتمكن من القيام بـ ctrl+v من مكان عمل المطور في البنك في IDE.
تم التوصل إلى اتفاق مع تنظيم الدولة الإسلامية ينص في البداية، في مرحلة الاختبار، على توفير الوصول من خلال وكيل مصرفي يعتمد على القائمة البيضاء. عند الانتهاء من المشروع، سيتم نقل الوصول إلى القائمة السوداء. تم إعداد جداول وصول ضخمة تشير إلى الموارد والمستودعات الرئيسية التي كان الوصول إليها مطلوبًا في بداية المشروع. استغرق تنسيق عمليات الوصول هذه قدرًا لا بأس به من الوقت، مما جعل من الممكن الإصرار على أسرع انتقال ممكن إلى القوائم السوداء.
النتائج
انتهى المشروع منذ أقل من عام بقليل. ومن الغريب أن جميع المقاولين تحولوا إلى المكدس الجديد في الوقت المحدد ولم يتبق أحد بسبب الأتمتة الجديدة. IB ليس في عجلة من أمره لمشاركة التعليقات الإيجابية، لكنه لا يشتكي أيضًا، ومن هنا يمكننا أن نستنتج أنهم يحبون ذلك. لقد هدأت الصراعات لأن أمن المعلومات أصبح يشعر بأنه تحت السيطرة مرة أخرى، لكنه لا يتعارض مع عمليات التطوير. تم منح الفرق المزيد من المسؤولية، وأصبح الموقف العام تجاه أمن المعلومات أفضل. لقد أدرك البنك أن الانتقال إلى DevSecOps كان أمرًا لا مفر منه تقريبًا، وقام بذلك، في رأيي، بالطريقة الأكثر لطفًا وصحيحة.
ألكسندر شوبين، مهندس النظام.
المصدر: www.habr.com