أفضل الممارسات للتطبيقات المصرفية السحابية المختلطة النشر الآمن والمتوافق عبر IBM Cloud and Satellite - IBM Blog

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

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

علاوة على ذلك، تدعم العديد من تطبيقات الخدمات المالية هذه أعباء العمل المنظمة، والتي تتطلب مستويات صارمة من الأمان والامتثال، بما في ذلك حماية الثقة المعدومة لأعباء العمل. يحقق IBM Cloud for Financial Services هذا المطلب من خلال توفير إطار عمل شامل للأمان والامتثال يمكن استخدامه لتنفيذ و/أو تحديث التطبيقات بشكل آمن عبر السحابة المختلطة.

في هذه الورقة، نعرض كيفية نشر تطبيق مصرفي بسهولة على كليهما IBM Cloud للخدمات المالية و الأقمار الصناعية، باستخدام خطوط أنابيب CI/CD/CC الآلية بطريقة مشتركة ومتسقة. وهذا يتطلب مستوى عميقًا من الأمان والامتثال خلال عملية الإنشاء والنشر بأكملها.

مقدمة للمفاهيم والمنتجات

الغرض من IBM Cloud for Financial Services هو توفير الأمان والامتثال لشركات الخدمات المالية. وهي تفعل ذلك من خلال الاستفادة من معايير الصناعة مثل نيست 800-53 وخبرة أكثر من مائة من عملاء الخدمات المالية الذين يشكلون جزءًا من مجلس الخدمات السحابية المالية. فهو يوفر إطار تحكم يمكن تنفيذه بسهولة باستخدام البنى المرجعية والخدمات السحابية التي تم التحقق منها ومقدمي البرامج المستقلين، بالإضافة إلى أعلى مستويات التشفير والامتثال المستمر (CC) عبر السحابة المختلطة.

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

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

نظرة عامة على التطبيق

التطبيق المستخدم في هذا المشروع هو تطبيق إنشاء قرض تم تطويره كجزء من بيان كورليس مبادرة 2.0. يحصل العميل على قرض شخصي من خلال قناة إلكترونية آمنة ومأمونة يقدمها البنك. يستخدم التطبيق نظامًا بيئيًا للتطبيقات الشريكة التي تعمل بشكل متبادل على بنية BIAN، والتي يتم نشرها على IBM Cloud for Financial Services. تعمل مبادرة BIAN Coreless على تمكين المؤسسات المالية من اختيار أفضل الشركاء للمساعدة في تقديم خدمات جديدة إلى السوق بسرعة وكفاءة من خلال بنيات BIAN. يتم تنفيذ كل مكون أو مجال خدمة BIAN من خلال خدمة صغيرة، والتي يتم نشرها على مجموعة OCP على IBM Cloud.

مكونات التطبيق على أساس مجالات خدمة BIAN

• دليل المنتج: يحتفظ بدليل شامل لمنتجات وخدمات البنك.

• القروض الاستهلاكية: يتعامل مع استيفاء منتج قرض المستهلك. يتضمن ذلك الإعداد الأولي لتسهيل القرض وإكمال مهام معالجة المنتج المجدولة والمخصصة.

• عملية عرض العملاء/واجهة برمجة التطبيقات (API).: ينسق معالجة عرض المنتج لعميل جديد أو مؤسس.

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

نظرة عامة على عملية النشر

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

تم تحقيق نشر IBM Cloud for Financial Services في مجموعة منطقة الهبوط الآمنة، كما يتم نشر البنية التحتية آليا باستخدام السياسة كرمز (terraform). ويتكون التطبيق من مكونات مختلفة. تم نشر كل مكون باستخدام مكونه الخاص التكامل المستمر (CI), التسليم المستمر (CD) و الامتثال المستمر (CC) خط الأنابيب على مجموعة RedHat OpenShift. لتحقيق النشر على القمر الصناعي، تم إعادة استخدام خطوط أنابيب CI/CC، وتم إنشاء خط أنابيب CD جديد.

التكامل المستمر

يحتوي كل مكون من مكونات نشر IBM Cloud على قناة CI الخاصة به. يتم تضمين مجموعة من الإجراءات والأساليب الموصى بها في سلسلة أدوات CI. يتم استخدام ماسح ضوئي للكود الثابت لفحص مستودع التطبيق بحثًا عن أي أسرار مخزنة في الكود المصدري للتطبيق، بالإضافة إلى أي حزم ضعيفة تستخدم كتبعيات داخل كود التطبيق. لكل التزام Git، يتم إنشاء صورة حاوية، ويتم تعيين علامة للصورة بناءً على رقم الإصدار والطابع الزمني ومعرف الالتزام. يضمن نظام العلامات هذا إمكانية تتبع الصورة. قبل إنشاء الصورة، يتم اختبار ملف Dockerfile. يتم حفظ الصورة التي تم إنشاؤها في سجل صور خاص. يتم تكوين امتيازات الوصول لنشر المجموعة المستهدفة تلقائيًا باستخدام الرموز المميزة لواجهة برمجة التطبيقات (API)، والتي يمكن إبطالها. يتم إجراء فحص الثغرات الأمنية على صورة الحاوية. يتم تطبيق توقيع Docker عند الانتهاء بنجاح. تؤدي إضافة علامة الصورة التي تم إنشاؤها إلى تحديث سجل النشر على الفور. إن استخدام مساحة اسم واضحة داخل المجموعة يخدم غرض عزل كل عملية نشر. يتم إنشاء أي تعليمات برمجية يتم دمجها في الفرع المحدد لمستودع Git، خصيصًا للنشر على مجموعة Kubernetes، والتحقق منها وتنفيذها تلقائيًا.

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

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

الانتشار المستمر

يعد المخزون بمثابة مصدر الحقيقة فيما يتعلق بالقطع الأثرية التي تم نشرها وفي أي بيئة/منطقة؛ يتم تحقيق ذلك باستخدام فروع git لتمثيل البيئات، مع خط أنابيب ترويجي لتحديث البيئات بأسلوب يعتمد على GitOps. في عمليات النشر السابقة، كان المخزون أيضًا يستضيف ملفات النشر؛ هذه هي ملفات موارد YAML Kubernetes التي تصف كل مكون. سيتم تحديث ملفات النشر هذه باستخدام واصفات مساحة الاسم الصحيحة، بالإضافة إلى الإصدار الأحدث من صورة Docker لكل مكون.

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

كنا نرغب في اتباع نهج مختلف، لذلك قمنا بإعادة تصميم عملية النشر لاستخدام مخطط Helm بدلاً من ذلك. وقد أتاح لنا ذلك تحديد معلمات القيم المهمة، مثل مساحات الأسماء وعلامات الصور، وإدخالها في وقت النشر. يؤدي استخدام هذه المتغيرات إلى التخلص من الكثير من الصعوبات المرتبطة بتحليل ملفات YAML لقيمة معينة. تم إنشاء مخطط الدفة بشكل منفصل وتخزينه في نفس سجل الحاوية مثل صور BIAN المضمنة. نحن نعمل حاليًا على تطوير خط أنابيب CI محدد للتحقق من صحة مخططات الدفة؛ سيؤدي ذلك إلى فحص المخطط وتعبئته وتوقيعه للتأكد من صحته (سيتم التحقق من ذلك في وقت النشر) وتخزين المخطط. في الوقت الحالي، يتم تنفيذ هذه الخطوات يدويًا لتطوير المخطط. توجد مشكلة واحدة في استخدام مخططات الدفة وتكوينات القمر الصناعي معًا: تتطلب وظيفة الدفة اتصالاً مباشرًا بمجموعة Kubernetes أو OpenShift لتعمل بشكل أكثر فعالية، ولن يسمح القمر الصناعي بذلك بالطبع. لذا، لحل هذه المشكلة، نستخدم "قالب الدفة" لإخراج المخطط المنسق بشكل صحيح ثم تمرير ملف YAML الناتج إلى وظيفة تحميل القمر الصناعي. تعمل هذه الوظيفة بعد ذلك على الاستفادة من IBM Cloud Satellite CLI لتكوين نسخة تكوين تحتوي على تطبيق YAML. هناك بعض العيوب هنا: لا يمكننا استخدام بعض الوظائف المفيدة التي يوفرها Helm، مثل القدرة على ذلك العودة إلى إصدار مخطط سابق والاختبارات التي يمكن إجراؤها للتأكد من أن التطبيق يعمل بشكل صحيح. ومع ذلك، يمكننا استخدام آلية التراجع عن القمر الصناعي كبديل واستخدام إصدارها كأساس لذلك.

الامتثال المستمر

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

يقوم خط الأنابيب أيضًا بفحص صور الحاوية بحثًا عن الثغرات الأمنية. يتم وضع علامة على أي مشكلة حادثة يتم العثور عليها أثناء الفحص أو التحديث بتاريخ استحقاق. يتم إنشاء الأدلة وتخزينها في IBM Cloud Object Storage في نهاية كل عملية تشغيل والتي تلخص تفاصيل الفحص.

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

يعد الحصول على CC في بيئة سحابية أمرًا مهمًا بالنسبة للصناعات شديدة التنظيم مثل الخدمات المالية التي ترغب في حماية بيانات العملاء والتطبيقات. في الماضي، كانت هذه العملية صعبة وكان يجب إجراؤها يدويًا، مما يعرض المؤسسات للخطر. ولكن مع مركز IBM Cloud Security and Compliance، يمكنك إضافة عمليات فحص امتثال تلقائية يومية إلى دورة حياة التطوير الخاصة بك للمساعدة في تقليل هذه المخاطر. تتضمن هذه الاختبارات تقييمات مختلفة لسلاسل أدوات DevSecOps لضمان الأمان والامتثال.

استنادا إلى خبرتنا في هذا المشروع والمشاريع المماثلة الأخرى، قمنا بإنشاء مجموعة من أفضل الممارسات لمساعدة الفرق على تنفيذ حلول السحابة المختلطة لـ IBM Cloud for Financial Services وIBM Cloud Satellite:

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

• الانتشار المستمر
  • بالنسبة للتطبيقات متعددة المكونات، احتفظ بمخزون واحد، وبالتالي، بسلسلة أدوات نشر واحدة لنشر كافة المكونات المدرجة في المخزون. وهذا يمنع الكثير من التكرار. تحتوي جميع ملفات نشر Kubernetes YAML على نفس آلية النشر، لذا فإن تكرار سلسلة الأدوات الفردية فوق كل منها بدوره أكثر منطقية من الحفاظ على سلاسل أدوات متعددة للأقراص المضغوطة، وكلها تفعل نفس الشيء بشكل أساسي. لقد زادت قابلية الصيانة، وأصبح هناك عمل أقل للقيام به لنشر التطبيق. لا يزال من الممكن استخدام المشغلات لنشر الخدمات الصغيرة الفردية، إذا رغبت في ذلك.
  • استخدم مخططات Helm للتطبيقات المعقدة متعددة المكونات. إن استخدام Helm في مشروع BIAN جعل النشر أسهل بكثير. تتم كتابة ملفات Kubernetes بلغة YAML، ويعد استخدام موزعي النصوص المستندة إلى bash أمرًا مرهقًا إذا كانت هناك حاجة إلى تخصيص قيم متعددة في وقت النشر. يقوم Helm بتبسيط ذلك باستخدام المتغيرات، مما يجعل استبدال القيم أكثر فعالية. بالإضافة إلى ذلك، يقدم Helm ميزات أخرى، مثل إصدار التطبيق بالكامل، وإصدار المخطط، وتخزين التسجيل لتكوين النشر وإمكانيات التراجع في حالة الفشل. على الرغم من أن التراجع لن يعمل في عمليات النشر الخاصة بالقمر الصناعي، إلا أنه يتم تلبية ذلك من خلال إصدار تكوين القمر الصناعي.
• الامتثال المستمر
  • نوصي بشدة بإعداد سلاسل أدوات CC كجزء من البنية التحتية الخاصة بك لفحص التعليمات البرمجية والعناصر بشكل مستمر بحثًا عن الثغرات الأمنية التي تم كشفها حديثًا. عادةً، يمكن إجراء عمليات الفحص هذه ليلاً أو وفقًا لأي جدول زمني يناسب تطبيقك وحالتك الأمنية. لتتبع المشكلات والوضع الأمني ​​العام لتطبيقك، نقترح عليك استخدام DevOps Insights.
  • نوصي أيضًا باستخدام مركز الأمان والامتثال (SCC) لأتمتة الوضع الأمني ​​لديك. يمكن تحميل ملخص الأدلة الناتج عن التدفقات إلى SCC، حيث يتم التعامل مع كل إدخال في ملخص الأدلة على أنه "حقيقة" تتعلق بمهمة مكتملة في سلسلة أدوات، سواء كان ذلك فحصًا للثغرات الأمنية أو اختبار الوحدة أو أشياء أخرى مماثلة . ستقوم SCC بعد ذلك بإجراء اختبارات التحقق من الصحة مقابل الأدلة لتحديد ما إذا كان يتم اتباع أفضل الممارسات المتعلقة بسلاسل الأدوات.
• المعرض
  • كما ذكرنا سابقًا، مع النشر المستمر، من الأفضل الاحتفاظ بمخزون تطبيق واحد حيث سيتم تخزين جميع تفاصيل الخدمة الصغيرة الخاصة بك، بالإضافة إلى ملفات نشر Kubernetes (إذا لم تكن تستخدم Helm). وهذا يسمح بمصدر واحد للحقيقة فيما يتعلق بحالة عمليات النشر الخاصة بك؛ نظرًا لأن الفروع الموجودة في مخزونك تمثل بيئات، فإن الحفاظ على هذه البيئات عبر مستودعات مخزون متعددة يمكن أن يصبح مرهقًا بسرعة كبيرة.
• دليل
  • ينبغي التعامل مع النهج المتبع في مستودعات الأدلة بشكل مختلف عن المخزون. في هذه الحالة، يفضل مستودع أدلة واحد لكل مكون؛ إذا قمت بدمجها، يمكن أن تصبح الأدلة المخزنة ساحقة ويصعب إدارتها. يعد تحديد موقع أجزاء معينة من الأدلة أكثر كفاءة إذا تم تخزين الأدلة في مستودع خاص بمكون ما. بالنسبة للنشر، تعتبر خزانة أدلة واحدة مقبولة، حيث يتم الحصول عليها من سلسلة أدوات نشر واحدة.
  • نوصي بشدة بتخزين الأدلة في حاوية تخزين الكائنات السحابية بالإضافة إلى استخدام خيار مستودع git الافتراضي. وذلك لأنه يمكن تكوين مجموعة COS لتكون غير قابلة للتغيير، مما يسمح لنا بتخزين الأدلة بشكل آمن دون احتمال التلاعب، وهو أمر مهم جدًا في حالة مسارات التدقيق.        

وفي الختام

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

اكتشف ما تقدمه IBM اليوم