Get best of the week

DevOps vs DevSecOps: كيف بدا في بنك واحد



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

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

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

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

في تلك اللحظة ، بدأت قصة DevSecOps ، والتي أريد أن أرويها.

أي بنك قدم استنتاجات عملية من هذا الموقف


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

  1. , , « ».
  2. , , .
  3. - , . , . .

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

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

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

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

ما كان يتغير


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

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

  • CI: Git ، Jenkins ، Maven ، Roslyn ، Gradle ، jUnit ، Jira ، MF Fortify ، CA Harvest ، GitlabCI.
  • القرص المضغوط: Ansible و Puppet و TeamCity و Gitlab TFS و Liquidbase.
  • اختبار: Sonarqube ، SoapUI ، jMeter ، Selenium: MF Fortify ، مركز الأداء ، MF UFT ، Atascama.
  • عرض (إعداد التقارير ، الاتصالات): Grafana ، Kibana ، Jira ، Confluence ، RocketChat.
  • العمليات : Ansible ، Zabbix ، Prometheus ، Elastic + Logstash ، مدير خدمة MF ، Jira ، Confluence ، MS Project.

تم تحديد تكديس:

  • قاعدة المعرفة - التقاء أتاسي ؛
  • تعقب المهام - Atlassian Jira ؛
  • مستودع التحف - "Nexus" ؛
  • نظام التكامل المستمر - "Gitlab CI" ؛
  • نظام التحليل المستمر - "SonarQube" ؛
  • نظام تحليل أمان التطبيق - "Micro Focus Fortify" ؛
  • نظام الاتصالات - "GitLab Mattermost" ؛
  • نظام إدارة التكوين - "Ansible" ؛
  • نظام المراقبة - "ELK" و "TICK Stack" ("InfluxData").

بدأوا في إنشاء فريق يكون جاهزًا لجذب المقاولين. لقد حان الإدراك أن هناك عدة أشياء مهمة:

  • . — . , .
  • , . — , .

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

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

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

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

أعطي المقاولون كومة جديدة. أعطوا الوقت لإعادة الكتابة تحت GitlabCI ، وترحيل Jira إلى قطاع البنوك وما إلى ذلك.

خطوة بخطوة


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

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

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

النتيجة - المعدات المقدمة لا تفي بمتطلبات البنك للأداء وتحمل الخطأ. قرر بنك DIT إنشاء مجمع يعتمد على PAC Nutanix.

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

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

المرحلة 4. أتمتة تثبيت برنامج التطبيق. تم تعيين هذه المهام من قبل قادة الفرق الجديدة.

المرحلة 5. العملية.

الوصول عن بعد


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

قررنا العمل على الوصول عن بعد مباشرة إلى موارد قطاع التنمية. Jira ، Wiki ، Gitlab ، Nexus ، منصات التجميع والاختبار ، البنية التحتية الافتراضية. وضع حراس الأمن متطلبات أنه لا يمكن تنظيم الوصول إلا وفقًا لما يلي:

  1. استخدام التقنيات المتاحة بالفعل في البنك.
  2. يجب ألا تستخدم البنية التحتية وحدات تحكم المجال الموجودة التي تخزن سجلات الحسابات / الكائنات المنتجة.
  3. يجب أن يقتصر الوصول فقط على تلك الموارد المطلوبة من قبل فريق معين (بحيث لا يتمكن فريق منتج واحد من الوصول إلى موارد فريق آخر).
  4. السيطرة القصوى على RBAC في النظم.

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

تم تنظيم الوصول عن بعد مباشرة على أساس المعدات المصرفية الموجودة. تم تقسيم التحكم في الوصول إلى مجموعات م ، والتي تتوافق مع القواعد في السياقات (مجموعة منتج واحد = مجموعة قاعدة واحدة).

إدارة قوالب VM


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

كما تم مراعاة متطلبات البنية التحتية والأمن أثناء التطوير - الحفاظ على الصور محدثة (التصحيحات ، وما إلى ذلك) ، والتكامل مع SIEM ، وإعدادات الأمان وفقًا للمعايير المعتمدة من قبل البنك.

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

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

الوصول إلى الإنترنت


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

  1. الوصول إلى البنية التحتية.
  2. الوصول إلى المطورين.

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

كان الوصول إلى الإنترنت للمطورين مطلوبًا لأسباب واضحة (تدفق مكدس). وعلى الرغم من أن جميع الفرق ، كما هو مذكور أعلاه ، كان لديها وصول عن بعد إلى الدائرة ، إلا أنه ليس مناسبًا دائمًا عندما لا تتمكن من تنفيذ ctrl + v من مكان عمل المطور في البنك في IDE.

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

النتائج


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

ألكسندر شوبين ، مهندس أنظمة.

More articles:


All Articles