بهترین شیوه ها برای برنامه های بانکداری ابری ترکیبی استقرار ایمن و سازگار در سراسر IBM Cloud و Satellite - IBM Blog

مشتریان خدمات مالی به طور فزاینده ای به دنبال مدرن سازی برنامه های خود هستند. این شامل نوسازی توسعه و نگهداری کد (کمک به مهارت‌های کمیاب و اجازه دادن به نوآوری و فناوری‌های جدید مورد نیاز کاربران نهایی) و همچنین بهبود استقرار و عملیات، استفاده از تکنیک‌های چابک و DevSecOps.

به عنوان بخشی از سفر مدرن‌سازی، مشتریان می‌خواهند برای تعیین بهترین مکان استقرار «مناسب برای هدف» برای برنامه‌هایشان انعطاف‌پذیری داشته باشند. این ممکن است در هر یک از محیط‌هایی باشد که Hybrid Cloud پشتیبانی می‌کند (در محل، در یک ابر خصوصی، یک ابر عمومی یا در لبه). IBM Cloud Satellite® این نیاز را برآورده می‌کند و به برنامه‌های مدرن و بومی ابری اجازه می‌دهد تا در هر جایی که مشتری نیاز دارد اجرا شوند و در عین حال یک صفحه کنترل استاندارد و ثابت برای مدیریت برنامه‌ها در سراسر ابر ترکیبی را حفظ کنند.

علاوه بر این، بسیاری از این برنامه‌های خدمات مالی از بارهای کاری تنظیم‌شده پشتیبانی می‌کنند، که نیازمند سطوح سختی از امنیت و انطباق هستند، از جمله حفاظت Zero Trust از بارهای کاری. IBM Cloud for Financial Services با ارائه یک چارچوب امنیتی و انطباق سرتاسری که می‌تواند برای پیاده‌سازی و/یا مدرن‌سازی برنامه‌های کاربردی به‌طور ایمن در سراسر ابر ترکیبی استفاده شود، این الزام را برآورده می‌کند.

در این مقاله، نحوه استقرار آسان یک برنامه بانکی در هر دو را نشان می دهیم IBM Cloud برای خدمات مالی و ماهواره ای، با استفاده از خطوط لوله خودکار CI/CD/CC به روشی مشترک و سازگار. این نیاز به سطح عمیقی از امنیت و انطباق در کل فرآیند ساخت و استقرار دارد.

مقدمه ای بر مفاهیم و محصولات

هدف IBM Cloud for Financial Services ارائه امنیت و انطباق برای شرکت های خدمات مالی است. این کار را با استفاده از استانداردهای صنعتی مانند 800-53 NIST و تخصص بیش از صد مشتری خدمات مالی که بخشی از شورای ابری خدمات مالی هستند. این یک چارچوب کنترلی را ارائه می دهد که می تواند به راحتی با استفاده از معماری های مرجع، خدمات ابر معتبر و ISV ها و همچنین بالاترین سطوح رمزگذاری و انطباق مداوم (CC) در سراسر ابر ترکیبی پیاده سازی شود.

IBM Cloud Satellite یک تجربه ابری ترکیبی واقعی را ارائه می دهد. ماهواره اجازه می دهد تا بارهای کاری در هر مکانی بدون به خطر انداختن امنیت اجرا شود. یک صفحه شیشه ای به راحتی می توانید همه منابع را در یک داشبورد مشاهده کنید. برای استقرار برنامه‌ها در این محیط‌های مختلف، مجموعه‌ای از زنجیره‌های ابزار قوی DevSecOps را برای ساخت برنامه‌ها، استقرار آنها در یک مکان ماهواره‌ای به شیوه‌ای ایمن و سازگار و نظارت بر محیط با استفاده از بهترین شیوه‌های DevOps ایجاد کرده‌ایم.

در این پروژه، ما از یک برنامه وام منشاء استفاده کردیم که برای استفاده از Kubernetes و میکروسرویس ها مدرن شده بود. برای ارائه این خدمات، برنامه بانکی از اکوسیستمی از برنامه های شریک استفاده می کند که با استفاده از BIAN چارچوب

بررسی اجمالی برنامه

برنامه کاربردی مورد استفاده در این پروژه یک برنامه اعطای وام است که به عنوان بخشی از برنامه توسعه یافته است BIAN Coreless ابتکار 2.0 مشتری از طریق یک کانال آنلاین امن و مطمئن که توسط بانک ارائه می شود، وام شخصی دریافت می کند. این برنامه از اکوسیستمی از برنامه‌های شریک استفاده می‌کند که بر روی معماری BIAN کار می‌کنند، که در IBM Cloud برای خدمات مالی مستقر شده است. BIAN Coreless Initiative به موسسات مالی قدرت می دهد تا بهترین شرکا را برای کمک به ارائه سریع و کارآمد خدمات جدید به بازار از طریق معماری BIAN انتخاب کنند. هر مؤلفه یا دامنه خدمات BIAN از طریق یک میکروسرویس پیاده سازی می شود که بر روی یک خوشه OCP در IBM Cloud مستقر شده است.

اجزای برنامه بر اساس دامنه های سرویس BIAN

• فهرست محصولات: فهرست جامعی از محصولات و خدمات بانک را نگهداری می کند.

• وام مصرفی: انجام یک محصول وام مصرفی را انجام می دهد. این شامل راه اندازی اولیه تسهیلات وام و تکمیل وظایف پردازش محصول برنامه ریزی شده و موقت است.

• فرآیند/API پیشنهاد مشتری: پردازش یک پیشنهاد محصول را برای یک مشتری جدید یا مستقر هماهنگ می کند.

• نمایه مسیریابی مهمانی: نمایه کوچکی از شاخص‌های کلیدی را برای مشتری حفظ می‌کند که در طول تعامل با مشتری برای تسهیل مسیریابی، سرویس‌دهی و تصمیم‌های انجام محصول/خدمت ارجاع داده می‌شود.

نمای کلی فرآیند استقرار

یک گردش کار چابک DevSecOps برای تکمیل استقرار در سراسر ابر هیبریدی استفاده شد. گردش کار DevSecOps بر یک فرآیند تحویل نرم افزار مکرر و قابل اعتماد متمرکز است. این روش به جای خطی، تکراری است، که به تیم‌های DevOps اجازه می‌دهد کد بنویسند، آن را ادغام کنند، آزمایش‌ها را اجرا کنند، نسخه‌ها را ارائه کنند و تغییرات را به صورت مشترک و در زمان واقعی اجرا کنند و در عین حال امنیت و انطباق را کنترل کنند.

استقرار IBM Cloud for Financial Services در یک خوشه منطقه فرود امن به دست آمد، و استقرار زیرساخت نیز با استفاده از خط مشی به عنوان کد خودکار می شود (terraform). برنامه از اجزای مختلفی تشکیل شده است. هر جزء با استفاده از خود مستقر شد ادغام پیوسته (CI), تحویل مستمر (CD) و انطباق مداوم (CC) خط لوله در یک خوشه OpenShift RedHat. برای دستیابی به استقرار در ماهواره، خطوط لوله CI/CC مجددا مورد استفاده قرار گرفت و خط لوله CD جدیدی ایجاد شد.

ادغام مداوم

هر جزء از استقرار IBM Cloud خط لوله CI خاص خود را داشت. مجموعه ای از رویه ها و رویکردهای توصیه شده در زنجیره ابزار CI گنجانده شده است. یک اسکنر کد ایستا برای بررسی مخزن برنامه برای هر گونه اسرار ذخیره شده در کد منبع برنامه و همچنین بسته های آسیب پذیری که به عنوان وابستگی در کد برنامه استفاده می شود، استفاده می شود. برای هر commit Git، یک تصویر کانتینری ایجاد می‌شود و یک برچسب بر اساس شماره ساخت، برچسب زمانی و شناسه commit به تصویر اختصاص می‌یابد. این سیستم برچسب گذاری قابلیت ردیابی تصویر را تضمین می کند. قبل از ایجاد تصویر، 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 برای اسکن مداوم مصنوعات و مخازن مستقر شده مهم است. ارزش اینجا در یافتن آسیب‌پذیری‌های گزارش‌شده جدید است که ممکن است پس از استقرار برنامه کشف شده باشند. آخرین تعاریف آسیب پذیری از سازمان هایی مانند اسنیک و برنامه CVE برای ردیابی این مسائل جدید استفاده می شود. زنجیره ابزار CC یک اسکنر کد ایستا را در فواصل زمانی تعریف شده توسط کاربر بر روی مخازن برنامه اجرا می کند که برای شناسایی اسرار در کد منبع برنامه و آسیب پذیری ها در وابستگی های برنامه ارائه شده است.

این خط لوله همچنین تصاویر کانتینر را برای آسیب‌پذیری‌های امنیتی اسکن می‌کند. هر مشکل حادثه ای که در حین اسکن پیدا شود یا به روز شود، با سررسید مشخص می شود. شواهد در پایان هر اجرا در IBM Cloud Object Storage ایجاد و ذخیره می‌شود که جزئیات اسکن را خلاصه می‌کند.

DevOps Insights برای پیگیری مسائل و وضعیت امنیتی کلی برنامه شما ارزشمند است. این ابزار شامل تمام معیارهای زنجیره ابزار قبلی در هر سه سیستم است: یکپارچه سازی مداوم، استقرار و انطباق. هر نتیجه اسکن یا آزمایشی در آن سیستم آپلود می شود و اضافه کاری، می توانید مشاهده کنید که وضعیت امنیتی شما چگونه در حال تکامل است.

دریافت CC در یک محیط ابری برای صنایع بسیار تحت نظارت مانند خدمات مالی که می‌خواهند از داده‌های مشتری و برنامه محافظت کنند، مهم است. در گذشته این فرآیند سخت بود و باید با دست انجام می شد که سازمان ها را در معرض خطر قرار می داد. اما با IBM Cloud Security and Compliance Center، می توانید بررسی های انطباق روزانه و خودکار را به چرخه عمر توسعه خود اضافه کنید تا به کاهش این خطر کمک کنید. این بررسی ها شامل ارزیابی های مختلفی از زنجیره ابزار DevSecOps برای اطمینان از امنیت و انطباق است.

بر اساس تجربه خود با این پروژه و سایر پروژه‌های مشابه، مجموعه‌ای از بهترین روش‌ها را برای کمک به تیم‌ها برای پیاده‌سازی راه‌حل‌های ابری ترکیبی برای IBM Cloud برای خدمات مالی و IBM Cloud Satellite ایجاد کردیم:

• ادغام مداوم
  • یک کتابخانه اسکریپت مشترک برای برنامه های کاربردی مشابه در زنجیره های ابزار مختلف حفظ کنید. این مجموعه دستورالعمل هایی است که تعیین می کند زنجیره ابزار CI شما باید چه کاری انجام دهد. به عنوان مثال، فرآیند ساخت برنامه‌های NodeJS معمولاً از ساختار مشابهی پیروی می‌کند، بنابراین منطقی است که یک کتابخانه اسکریپت در یک مخزن جداگانه نگهداری شود، که زنجیره‌های ابزار هنگام ساخت برنامه‌ها به آن اشاره خواهند کرد. این اجازه می دهد تا برای یک رویکرد سازگار به CI، ترویج استفاده مجدد و افزایش قابلیت نگهداری.
  • از طرف دیگر، زنجیره‌های ابزار CI را می‌توان برای کاربردهای مشابه با استفاده از محرک‌ها مورد استفاده مجدد قرار داد. این محرک‌های جداگانه می‌توانند برای تعیین برنامه‌ای که قرار است ساخته شود، کد برنامه در کجا قرار دارد و سایر سفارشی‌سازی‌ها استفاده شوند.

• استقرار مداوم
  • برای برنامه های چند جزئی، یک موجودی واحد و بنابراین، یک زنجیره ابزار استقرار واحد را برای استقرار همه اجزای فهرست شده در موجودی نگهداری کنید. این کار از تکرار زیاد جلوگیری می کند. فایل‌های استقرار YAML Kubernetes همگی مکانیزم استقرار یکسانی دارند، بنابراین یک زنجیره ابزار منفرد که روی هر کدام به نوبه خود تکرار می‌شود، منطقی‌تر از نگهداری زنجیره‌های ابزار CD متعدد است، که همه آنها اساساً کار مشابهی را انجام می‌دهند. قابلیت نگهداری افزایش یافته است و کار کمتری برای استقرار برنامه وجود دارد. در صورت تمایل همچنان می توان از تریگرها برای استقرار میکروسرویس های فردی استفاده کرد.
  • از نمودارهای Helm برای برنامه های پیچیده چند جزئی استفاده کنید. استفاده از Helm در پروژه BIAN استقرار را بسیار آسان تر کرد. فایل‌های Kubernetes در YAML نوشته شده‌اند، و استفاده از تجزیه‌کننده‌های متنی مبتنی بر bash در صورتی که نیاز به سفارشی‌سازی چندین مقدار در زمان استقرار داشته باشد، دشوار است. Helm این کار را با استفاده از متغیرها ساده می کند، که جایگزینی مقادیر را بسیار موثرتر می کند. علاوه بر این، Helm ویژگی‌های دیگری مانند نسخه‌سازی کل برنامه، نسخه‌سازی نمودار، ذخیره‌سازی رجیستری پیکربندی استقرار و قابلیت‌های بازگشت به عقب در صورت خرابی را ارائه می‌دهد. در حالی که بازگشت مجدد روی استقرارهای خاص ماهواره کار نمی کند، این امر توسط نسخه پیکربندی ماهواره ای انجام می شود.
• انطباق مداوم
  • ما قویاً توصیه می‌کنیم زنجیره‌های ابزار CC را به عنوان بخشی از زیرساخت خود راه‌اندازی کنید تا به طور مداوم کدها و مصنوعات را برای آسیب‌پذیری‌هایی که به تازگی در معرض دید قرار گرفته‌اند اسکن کنید. به طور معمول، این اسکن‌ها می‌توانند شبانه یا بر اساس هر برنامه‌ای که مناسب برنامه و وضعیت امنیتی شما باشد اجرا شوند. برای پیگیری مشکلات و وضعیت امنیتی کلی برنامه خود، پیشنهاد می کنیم از DevOps Insights استفاده کنید.
  • ما همچنین استفاده از مرکز امنیت و انطباق (SCC) را برای خودکار کردن وضعیت امنیتی خود توصیه می کنیم. خلاصه شواهد تولید شده توسط خطوط لوله را می توان در SCC بارگذاری کرد، جایی که هر ورودی در خلاصه شواهد به عنوان یک "واقعیت" مربوط به یک کار تکمیل شده در یک زنجیره ابزار تلقی می شود، خواه اسکن آسیب پذیری، تست واحد یا موارد دیگر مشابه باشد. . سپس SCC آزمایش‌های اعتبارسنجی را در برابر شواهد اجرا می‌کند تا تعیین کند که بهترین شیوه‌های مرتبط با زنجیره‌های ابزار دنبال می‌شوند.
• فهرست
  • همانطور که قبلاً ذکر شد، با استقرار مداوم، ترجیح داده می‌شود یک فهرست برنامه واحد که در آن تمام جزئیات میکروسرویس شما به همراه فایل‌های استقرار Kubernetes (اگر از Helm استفاده نمی‌کنید) ذخیره شود. این اجازه می دهد برای یک منبع حقیقت واحد در مورد وضعیت استقرار شما. از آنجایی که شاخه‌های موجودی شما محیط‌ها را نشان می‌دهند، نگهداری این محیط‌ها در چندین مخزن موجودی می‌تواند خیلی سریع دست و پا گیر شود.
• مدرک
  • رویکرد به مخازن شواهد باید متفاوت از موجودی باشد. در این مورد، یک مخزن شواهد برای هر جزء ارجح است. اگر آنها را با هم ترکیب کنید، شواهد ذخیره شده می تواند بسیار زیاد و مدیریت آن دشوار باشد. اگر شواهد در مخزن مخصوص یک جزء ذخیره شوند، مکان یابی شواهد خاص بسیار کارآمدتر است. برای استقرار، یک قفل شواهد واحد قابل قبول است، زیرا از یک زنجیره ابزار استقرار منفرد تهیه می شود.
  • ما قویاً توصیه می‌کنیم که شواهد را در یک سطل ذخیره‌سازی آبجکت ابری و همچنین استفاده از گزینه پیش‌فرض git repository ذخیره کنید. این به این دلیل است که یک سطل COS را می توان به گونه ای پیکربندی کرد که تغییر ناپذیر باشد، که به ما امکان می دهد شواهد را بدون امکان دستکاری، که در مورد مسیرهای حسابرسی بسیار مهم است، به طور ایمن ذخیره کنیم.        

نتیجه

در این وبلاگ، ما تجربه خود را در اجرای یک برنامه بانکی مبتنی بر BIAN در سراسر ابر ترکیبی، یعنی استفاده از خطوط لوله DevSecOps برای استقرار حجم کار هم در IBM Cloud و هم در یک محیط ماهواره‌ای به نمایش گذاشتیم. ما در مورد جوانب مثبت و منفی رویکردهای مختلف و بهترین شیوه هایی که پس از انجام این پروژه به دست آوردیم، بحث کردیم. ما امیدواریم که این بتواند به سایر تیم‌ها کمک کند تا سفر ابری هیبریدی خود را با ثبات و سرعت بیشتر انجام دهند. افکار خود را با ما درمیان بگذار.

آنچه را که IBM امروز ارائه می دهد را بررسی کنید