Praktik terbaik untuk aplikasi perbankan cloud hibrid yang aman dan sesuai dengan penerapan di IBM Cloud dan Satelit – Blog IBM

Klien Jasa Keuangan semakin berupaya memodernisasi aplikasi mereka. Hal ini mencakup modernisasi pengembangan dan pemeliharaan kode (membantu keterampilan yang langka dan memungkinkan inovasi dan teknologi baru yang dibutuhkan oleh pengguna akhir) serta peningkatan penerapan dan operasi, menggunakan teknik tangkas dan DevSecOps.

Sebagai bagian dari perjalanan modernisasi mereka, klien ingin memiliki fleksibilitas untuk menentukan lokasi penerapan yang “sesuai dengan tujuan” terbaik untuk aplikasi mereka. Hal ini dapat terjadi di lingkungan mana pun yang didukung oleh Hybrid Cloud (on-premise, private cloud, public cloud, atau edge). IBM Cloud Satellite® memenuhi persyaratan ini dengan memungkinkan aplikasi-aplikasi cloud-native yang modern untuk dijalankan di mana pun yang dibutuhkan klien dengan tetap mempertahankan bidang kendali yang standar dan konsisten untuk administrasi aplikasi di seluruh cloud hibrid.

Selain itu, banyak dari aplikasi layanan keuangan ini mendukung beban kerja yang diatur, yang memerlukan tingkat keamanan dan kepatuhan yang ketat, termasuk perlindungan beban kerja Zero Trust. IBM Cloud for Financial Services memenuhi persyaratan tersebut dengan menyediakan kerangka kerja keamanan dan kepatuhan menyeluruh yang dapat digunakan untuk mengimplementasikan dan/atau memodernisasi aplikasi secara aman di seluruh cloud hibrid.

Dalam tulisan ini, kami menunjukkan cara mudah menerapkan aplikasi perbankan pada keduanya IBM Cloud untuk Layanan Keuangan dan satelit, menggunakan pipeline CI/CD/CC otomatis dengan cara yang umum dan konsisten. Hal ini memerlukan tingkat keamanan dan kepatuhan yang mendalam di seluruh proses pembangunan dan penerapan.

Pengenalan konsep dan produk

Tujuan IBM Cloud for Financial Services adalah untuk memberikan keamanan dan kepatuhan bagi perusahaan jasa keuangan. Hal ini dilakukan dengan memanfaatkan standar industri seperti NIST 800-53 dan keahlian lebih dari seratus klien jasa keuangan yang merupakan bagian dari Financial Services Cloud Council. Ini memberikan kerangka kontrol yang dapat dengan mudah diimplementasikan dengan menggunakan Arsitektur Referensi, Layanan Cloud Tervalidasi, dan ISV, serta enkripsi tingkat tertinggi dan kepatuhan berkelanjutan (CC) di seluruh cloud hybrid.

IBM Cloud Satellite memberikan pengalaman cloud hybrid yang sesungguhnya. Satelit memungkinkan beban kerja dijalankan di mana saja tanpa mengorbankan keamanan. Satu panel kaca memberikan kemudahan melihat semua sumber daya dalam satu dasbor. Untuk menyebarkan aplikasi ke berbagai lingkungan ini, kami telah mengembangkan serangkaian rantai alat DevSecOps yang kuat untuk membangun aplikasi, menyebarkannya ke lokasi Satelit dengan cara yang aman dan konsisten, serta memantau lingkungan menggunakan praktik DevOps terbaik.

Dalam proyek ini, kami menggunakan aplikasi pinjaman origination yang dimodernisasi untuk menggunakan Kubernetes dan layanan mikro. Untuk memberikan layanan ini, aplikasi bank menggunakan ekosistem aplikasi mitra yang saling beroperasi menggunakan BIAN kerangka.

Ikhtisar aplikasi

Aplikasi yang digunakan dalam proyek ini adalah aplikasi originasi pinjaman yang dikembangkan sebagai bagian dari BIAN Tanpa Biji inisiatif 2.0. Pelanggan memperoleh pinjaman yang dipersonalisasi melalui saluran online aman dan terjamin yang ditawarkan oleh bank. Aplikasi ini menggunakan ekosistem aplikasi mitra yang saling beroperasi pada arsitektur BIAN, yang diterapkan pada IBM Cloud for Financial Services. BIAN Coreless Initiative memberdayakan lembaga keuangan untuk memilih mitra terbaik guna membantu menghadirkan layanan baru ke pasar dengan cepat dan efisien melalui arsitektur BIAN. Setiap komponen atau Domain Layanan BIAN diimplementasikan melalui layanan mikro, yang disebarkan pada klaster OCP di IBM Cloud.

Komponen Aplikasi berdasarkan Domain Layanan BIAN

• Direktori Produk: Menyimpan direktori lengkap produk dan layanan bank.

• Pinjaman Konsumen: Menangani pemenuhan produk pinjaman konsumen. Hal ini mencakup pengaturan awal fasilitas pinjaman dan penyelesaian tugas pemrosesan produk terjadwal dan ad-hoc.

• Proses Penawaran Pelanggan/API: Mengatur pemrosesan penawaran produk untuk pelanggan baru atau lama.

• Profil Perutean Partai: Mempertahankan profil kecil dari indikator-indikator utama bagi pelanggan yang direferensikan selama interaksi pelanggan untuk memfasilitasi keputusan perutean, layanan, dan pemenuhan produk/layanan.

Ikhtisar proses penerapan

Alur kerja DevSecOps yang tangkas digunakan untuk menyelesaikan penerapan di seluruh cloud hybrid. Alur kerja DevSecOps berfokus pada proses pengiriman perangkat lunak yang sering dan andal. Metodologinya bersifat iteratif, bukan linier, yang memungkinkan tim DevOps menulis kode, mengintegrasikannya, menjalankan pengujian, meluncurkan rilis, dan menerapkan perubahan secara kolaboratif dan real-time sambil tetap menjaga keamanan dan kepatuhan.

Penerapan IBM Cloud for Financial Services dicapai dalam klaster zona pendaratan yang aman, dan penerapan infrastruktur juga diotomatisasi menggunakan kebijakan sebagai kode (terraform). Aplikasi ini terdiri dari berbagai komponen. Setiap komponen dikerahkan menggunakan komponennya sendiri Integrasi berkelanjutan (CI), Pengiriman Berkelanjutan (CD) dan Kepatuhan Berkelanjutan (CC) pipa pada RedHat OpenShift Cluster. Untuk mencapai penerapan di Satelit, pipeline CI/CC digunakan kembali, dan pipeline CD baru dibuat.

Integrasi berkelanjutan

Setiap komponen penerapan IBM Cloud memiliki saluran CI-nya sendiri. Serangkaian prosedur dan pendekatan yang direkomendasikan disertakan dalam rangkaian alat CI. Pemindai kode statis digunakan untuk memeriksa repositori aplikasi untuk mencari rahasia apa pun yang disimpan dalam kode sumber aplikasi, serta paket rentan apa pun yang digunakan sebagai dependensi dalam kode aplikasi. Untuk setiap penerapan Git, gambar kontainer dibuat, dan tag ditetapkan ke gambar berdasarkan nomor build, stempel waktu, dan ID penerapan. Sistem penandaan ini memastikan ketertelusuran gambar. Sebelum membuat image, Dockerfile diuji. Gambar yang dibuat disimpan dalam registri gambar pribadi. Hak istimewa akses untuk penerapan kluster target secara otomatis dikonfigurasi menggunakan token API, yang dapat dicabut. Pemindaian kerentanan keamanan dilakukan pada gambar kontainer. Tanda tangan Docker diterapkan setelah berhasil diselesaikan. Penambahan tag gambar yang dibuat secara instan memperbarui catatan penerapan. Penggunaan namespace eksplisit dalam cluster bertujuan untuk mengisolasi setiap penerapan. Setiap kode yang digabungkan ke dalam cabang tertentu dari repositori Git, secara khusus untuk diterapkan pada cluster Kubernetes, secara otomatis dibuat, diverifikasi, dan diimplementasikan.

Detail setiap image buruh pelabuhan disimpan dalam gudang inventaris, yang dijelaskan secara detail di bagian Penerapan Berkelanjutan di blog ini. Selain itu, bukti dikumpulkan di setiap proses pipa. Bukti ini menjelaskan tugas apa saja yang dilakukan di toolchain, seperti pemindaian kerentanan dan pengujian unit. Bukti ini disimpan dalam repositori git dan keranjang penyimpanan objek cloud, sehingga dapat diaudit jika diperlukan.

Kami menggunakan kembali rantai alat CI yang digunakan untuk penerapan IBM Cloud yang disebutkan di atas untuk penerapan Satelit. Karena aplikasinya tetap tidak berubah, maka tidak perlu membangun kembali pipeline CI untuk penerapan baru.

Penerapan Berkelanjutan

Inventarisasi tersebut berfungsi sebagai sumber kebenaran mengenai artefak apa yang ditempatkan di lingkungan/wilayah apa; hal ini dicapai dengan menggunakan cabang git untuk mewakili lingkungan, dengan saluran promosi yang memperbarui lingkungan dalam pendekatan berbasis GitOps. Pada penerapan sebelumnya, inventaris juga menghosting file penerapan; ini adalah file sumber daya YAML Kubernetes yang menjelaskan setiap komponen. File penerapan ini akan diperbarui dengan deskriptor namespace yang benar, bersama dengan versi terbaru image Docker untuk setiap komponen.

Namun, kami menganggap pendekatan ini sulit karena beberapa alasan. Dari sudut pandang aplikasi, mengubah begitu banyak nilai tag gambar dan namespace menggunakan alat pengganti YAML (seperti YQ) adalah hal yang kasar dan rumit. Untuk Satelit sendiri, kami menggunakan strategi unggahan langsung, dengan setiap file YAML yang disediakan dihitung sebagai “versi”. Kami lebih suka jika versinya sesuai dengan keseluruhan aplikasi, bukan hanya satu komponen atau layanan mikro.

Pendekatan yang berbeda diinginkan, jadi kami merancang ulang proses penerapan untuk menggunakan diagram Helm. Hal ini memungkinkan kami untuk membuat parameterisasi nilai-nilai penting, seperti namespace dan tag gambar, dan memasukkannya pada waktu penerapan. Menggunakan variabel-variabel ini menghilangkan banyak kesulitan yang terkait dengan penguraian file YAML untuk nilai tertentu. Bagan helm dibuat secara terpisah dan disimpan dalam registri kontainer yang sama dengan gambar BIAN yang dibuat. Kami saat ini sedang berupaya mengembangkan jalur CI khusus untuk memvalidasi diagram kemudi; ini akan mengikat bagan, mengemasnya, menandatanganinya untuk kebenaran (ini akan diverifikasi pada waktu penerapan) dan menyimpan bagan. Untuk saat ini, langkah-langkah tersebut dilakukan secara manual untuk mengembangkan grafik. Ada satu masalah dalam penggunaan diagram helm dan konfigurasi Satelit secara bersamaan: fungsionalitas helm memerlukan koneksi langsung dengan cluster Kubernetes atau OpenShift agar dapat beroperasi secara efektif, dan Satelit, tentu saja, tidak mengizinkan hal tersebut. Jadi, untuk mengatasi masalah ini, kami menggunakan “template helm” untuk menampilkan grafik yang diformat dengan benar dan kemudian meneruskan file YAML yang dihasilkan ke fungsi unggahan Satelit. Fungsi ini kemudian memanfaatkan IBM Cloud Satellite CLI untuk membuat versi konfigurasi yang berisi aplikasi YAML. Ada beberapa kelemahan di sini: kami tidak dapat menggunakan beberapa fungsi berguna yang disediakan Helm, seperti kemampuannya rollback ke versi grafik sebelumnya dan pengujian yang dapat dilakukan untuk memastikan aplikasi berfungsi dengan benar. Namun, kita dapat menggunakan mekanisme rollback Satelit sebagai pengganti dan menggunakan versinya sebagai dasar untuk hal ini.

Kepatuhan Berkelanjutan

Pipeline CC penting untuk pemindaian berkelanjutan terhadap artefak dan repositori yang diterapkan. Nilainya di sini adalah menemukan kerentanan yang baru dilaporkan yang mungkin ditemukan setelah aplikasi diterapkan. Definisi terbaru tentang kerentanan dari organisasi seperti Snyk dan Program CVE digunakan untuk melacak isu-isu baru ini. Toolchain CC menjalankan pemindai kode statis pada interval yang ditentukan pengguna pada repositori aplikasi yang disediakan untuk mendeteksi rahasia dalam kode sumber aplikasi dan kerentanan dalam dependensi aplikasi.

Pipeline juga memindai gambar kontainer untuk mencari kerentanan keamanan. Setiap masalah insiden yang ditemukan selama pemindaian atau pembaruan ditandai dengan tanggal jatuh tempo. Bukti dibuat dan disimpan di IBM Cloud Object Storage pada akhir setiap proses yang merangkum rincian pemindaian.

Wawasan DevOps sangat berharga untuk melacak masalah dan keseluruhan postur keamanan aplikasi Anda. Alat ini berisi semua metrik dari rangkaian alat sebelumnya yang dijalankan di ketiga sistem: integrasi berkelanjutan, penerapan, dan kepatuhan. Hasil pemindaian atau tes apa pun diunggah ke sistem itu, dan dari waktu ke waktu, Anda dapat mengamati bagaimana postur keamanan Anda berkembang.

Mendapatkan CC di lingkungan cloud sangat penting bagi industri yang memiliki regulasi ketat seperti layanan keuangan yang ingin melindungi data pelanggan dan aplikasi. Di masa lalu, proses ini sulit dan harus dilakukan dengan tangan, sehingga membahayakan organisasi. Tetapi dengan Pusat Keamanan dan Kepatuhan Cloud IBM, Anda dapat menambahkan pemeriksaan kepatuhan otomatis harian ke siklus hidup pengembangan Anda untuk membantu mengurangi risiko ini. Pemeriksaan ini mencakup berbagai penilaian terhadap toolchain DevSecOps untuk memastikan keamanan dan kepatuhan.

Berdasarkan pengalaman kami dengan proyek ini dan proyek serupa lainnya, kami menciptakan serangkaian praktik terbaik untuk membantu tim menerapkan solusi cloud hibrid untuk IBM Cloud for Financial Services dan IBM Cloud Satellite:

• Integrasi berkelanjutan
  • Pertahankan pustaka skrip umum untuk aplikasi serupa di rantai alat yang berbeda. Ini adalah serangkaian instruksi yang menentukan apa yang harus dilakukan oleh rantai alat CI Anda. Misalnya, proses pembuatan aplikasi NodeJS umumnya akan mengikuti struktur yang sama, jadi masuk akal untuk menyimpan pustaka skrip di repositori terpisah, yang akan dirujuk oleh rantai alat saat membuat aplikasi. Hal ini memungkinkan pendekatan CI yang konsisten, mendorong penggunaan kembali, dan meningkatkan kemudahan perawatan.
  • Alternatifnya, rantai alat CI dapat digunakan kembali untuk aplikasi serupa dengan menggunakan pemicu; pemicu terpisah ini dapat digunakan untuk menentukan aplikasi apa yang akan dibangun, di mana kode untuk aplikasi tersebut berada dan penyesuaian lainnya.

• Penerapan Berkelanjutan
  • Untuk aplikasi multi-komponen, pertahankan satu inventaris dan, dengan demikian, satu rantai alat penerapan untuk menerapkan semua komponen yang tercantum dalam inventaris. Hal ini mencegah banyak pengulangan. Semua file penerapan YAML Kubernetes memiliki mekanisme penerapan yang sama, sehingga satu rantai alat yang melakukan iterasi pada masing-masing rantai alat secara bergantian akan lebih logis dibandingkan mempertahankan beberapa rantai alat CD, yang semuanya pada dasarnya melakukan hal yang sama. Kemampuan pemeliharaan telah meningkat, dan lebih sedikit pekerjaan yang harus dilakukan untuk menerapkan aplikasi. Pemicu masih dapat digunakan untuk menerapkan layanan mikro individual, jika diinginkan.
  • Gunakan diagram Helm untuk aplikasi multi-komponen yang kompleks. Penggunaan Helm dalam proyek BIAN membuat penerapan lebih mudah. File Kubernetes ditulis dalam YAML, dan menggunakan parser teks berbasis bash akan merepotkan jika beberapa nilai perlu disesuaikan pada waktu penerapan. Helm menyederhanakannya dengan menggunakan variabel, yang membuat substitusi nilai menjadi lebih efektif. Selain itu, Helm menawarkan fitur lain, seperti pembuatan versi seluruh aplikasi, pembuatan versi bagan, penyimpanan registri konfigurasi penerapan, dan kemampuan rollback jika terjadi kegagalan. Meskipun rollback tidak akan berfungsi pada penerapan khusus Satelit, hal ini dapat dilakukan dengan pembuatan versi konfigurasi Satelit.
• Kepatuhan Berkelanjutan
  • Kami sangat menyarankan untuk menyiapkan rantai alat CC sebagai bagian dari infrastruktur Anda untuk terus memindai kode dan artefak untuk mencari kerentanan yang baru terungkap. Biasanya, pemindaian ini dapat dijalankan setiap malam atau pada jadwal apa pun yang sesuai dengan aplikasi dan situasi keamanan Anda. Untuk melacak masalah dan keseluruhan kondisi keamanan aplikasi Anda, kami menyarankan Anda menggunakan DevOps Insights.
  • Kami juga merekomendasikan penggunaan Pusat Keamanan dan Kepatuhan (SCC) untuk mengotomatiskan postur keamanan Anda. Ringkasan bukti yang dihasilkan oleh pipeline dapat diunggah ke SCC, di mana setiap entri dalam ringkasan bukti diperlakukan sebagai “fakta” ​​terkait dengan tugas yang diselesaikan dalam rantai alat, baik itu pemindaian kerentanan, pengujian unit, atau hal-hal lain yang serupa. . SCC kemudian akan menjalankan uji validasi terhadap bukti untuk menentukan bahwa praktik terbaik terkait rantai alat telah diikuti.
• Inventaris
  • Seperti disebutkan sebelumnya, dengan penerapan berkelanjutan, sebaiknya simpan satu inventaris aplikasi yang akan menyimpan semua detail layanan mikro Anda, bersama dengan (jika tidak menggunakan Helm) file penerapan Kubernetes. Hal ini memungkinkan adanya satu sumber kebenaran mengenai status penerapan Anda; karena cabang di inventaris Anda mewakili lingkungan, mempertahankan lingkungan ini di beberapa repositori inventaris dapat menjadi rumit dengan sangat cepat.
• Bukti
  • Pendekatan terhadap penyimpanan bukti harus diperlakukan berbeda dengan inventarisasi. Dalam hal ini, satu tempat penyimpanan bukti per komponen lebih disukai; jika Anda menggabungkannya, bukti yang disimpan bisa menjadi sangat banyak dan sulit dikelola. Menemukan bukti tertentu jauh lebih efisien jika bukti tersebut disimpan dalam repositori khusus untuk suatu komponen. Untuk penerapan, satu loker bukti dapat diterima, karena bersumber dari satu rantai alat penerapan.
  • Kami sangat menyarankan untuk menyimpan bukti di keranjang penyimpanan objek cloud serta menggunakan opsi repositori git default. Hal ini karena bucket COS dapat dikonfigurasi agar tidak dapat diubah, yang memungkinkan kami menyimpan bukti dengan aman tanpa kemungkinan gangguan, yang sangat penting dalam kasus jejak audit.        

Kesimpulan

Di blog ini, kami memamerkan pengalaman kami mengimplementasikan aplikasi perbankan berdasarkan BIAN di seluruh cloud hybrid, yaitu menggunakan pipeline DevSecOps untuk menyebarkan beban kerja baik di IBM Cloud maupun di lingkungan Satelit. Kami mendiskusikan pro dan kontra dari berbagai pendekatan dan praktik terbaik yang kami peroleh setelah melalui proyek ini. Kami berharap hal ini dapat membantu tim lain mencapai perjalanan cloud hybrid mereka dengan lebih konsisten dan cepat. Beri tahu kami pendapat Anda.

Jelajahi apa yang ditawarkan IBM saat ini