Hibrit bulut bankacılığı uygulamalarının IBM Cloud ve Satellite genelinde güvenli ve uyumlu devreye alınmasına yönelik en iyi uygulamalar - IBM Blogu

Finansal Hizmetler müşterileri giderek daha fazla uygulamalarını modernleştirme arayışındadır. Bu, kod geliştirme ve bakımın modernizasyonunu (kıt becerilere yardımcı olmak ve son kullanıcıların ihtiyaç duyduğu inovasyona ve yeni teknolojilere izin vermek) yanı sıra çevik teknikler ve çözümler kullanarak dağıtım ve operasyonların iyileştirilmesini içerir. DevSecOps.

Müşteriler, modernizasyon yolculuğunun bir parçası olarak, uygulamaları için "amaca en uygun" dağıtım konumunun ne olduğunu belirleme esnekliğine sahip olmak istiyor. Bu, Hibrit Bulut'un desteklediği ortamlardan herhangi birinde (şirket içinde, özel bulutta, genel bulutta veya uçta) olabilir. IBM Cloud Satellite®, modern, bulutta yerel uygulamaların müşterinin ihtiyaç duyduğu her yerde çalıştırılmasına izin verirken, hibrit buluttaki uygulamaların yönetimi için standart ve tutarlı bir kontrol düzlemini koruyarak bu gereksinimi karşılar.

Üstelik bu finansal hizmet uygulamalarının birçoğu, iş yüklerinin Sıfır Güven koruması da dahil olmak üzere sıkı düzeyde güvenlik ve uyumluluk gerektiren düzenlenmiş iş yüklerini destekler. IBM Cloud for Financial Services, uygulamaları hibrit bulutta güvenli bir şekilde uygulamak ve/veya modernleştirmek için kullanılabilecek uçtan uca bir güvenlik ve uyumluluk çerçevesi sağlayarak bu gereksinimi karşılar.

Bu yazıda, bir bankacılık uygulamasının her iki platformda da kolayca nasıl dağıtılacağını gösteriyoruz. Finansal Hizmetler için IBM Cloud ve Uydu, otomatik CI/CD/CC işlem hatlarını ortak ve tutarlı bir şekilde kullanmak. Bu, tüm oluşturma ve dağıtım süreci boyunca derin düzeyde güvenlik ve uyumluluk gerektirir.

Kavramlara ve ürünlere giriş

IBM Cloud for Financial Services'in amacı, finansal hizmet şirketlerine güvenlik ve uyumluluk sağlamaktır. Bunu, aşağıdaki gibi endüstri standartlarından yararlanarak yapar: 800-53 ve Finansal Hizmetler Bulut Konseyi'nin parçası olan yüzden fazla finansal hizmet müşterisinin uzmanlığı. Referans Mimarileri, Doğrulanmış Bulut Hizmetleri ve ISV'lerin yanı sıra hibrit bulut genelinde en yüksek düzeyde şifreleme ve sürekli uyumluluk (CC) kullanılarak kolayca uygulanabilecek bir kontrol çerçevesi sağlar.

IBM Cloud Satellite, gerçek bir hibrit bulut deneyimi sağlar. Satellite, iş yüklerinin güvenlikten ödün vermeden her yerde çalıştırılmasına olanak tanır. Tek bir cam panel, tüm kaynakları tek bir kontrol panelinde görme kolaylığı sağlar. Uygulamaları bu değişken ortamlara dağıtmak için, uygulamalar oluşturmak, bunları güvenli ve tutarlı bir şekilde bir Uydu konumuna dağıtmak ve en iyi DevOps uygulamalarını kullanarak ortamı izlemek için bir dizi güçlü DevSecOps araç zinciri geliştirdik.

Bu projemizde Kubernetes ve mikro servisleri kullanacak şekilde modernize edilmiş bir kredi kullandırım uygulaması kullandık. Bu hizmeti sunmak için banka uygulaması, aşağıdakileri kullanarak birlikte çalışan ortak uygulamalardan oluşan bir ekosistem kullanır: BİAN çerçeve.

Uygulamaya genel bakış

Bu projede kullanılan uygulama, Proje kapsamında geliştirilen bir kredi kullandırım uygulamasıdır. BIAN Çekirdeksiz 2.0 girişimi. Müşteri, bir bankanın sunduğu güvenli ve emniyetli bir çevrimiçi kanal aracılığıyla kişiselleştirilmiş bir kredi alır. Uygulama, IBM Cloud for Financial Services üzerinde devreye alınan BIAN mimarisi üzerinde birlikte çalışan bir iş ortağı uygulamaları ekosistemini kullanır. BIAN Çekirdeksiz Girişimi, finans kurumlarına, BIAN mimarileri aracılığıyla yeni hizmetlerin pazara hızlı ve verimli bir şekilde sunulmasına yardımcı olacak en iyi ortakları seçme yetkisi veriyor. Her bileşen veya BIAN Hizmet Etki Alanı, IBM Cloud üzerindeki bir OCP kümesinde devreye alınan bir mikro hizmet aracılığıyla uygulanır.

BIAN Hizmet Alanlarını Temel Alan Uygulama Bileşenleri

• Ürün Rehberi: Bankanın ürün ve hizmetlerinin kapsamlı bir dizinini tutar.

• Tüketici kredisi: Bir ihtiyaç kredisi ürününün yerine getirilmesini yönetir. Bu, kredi tesisinin ilk kurulumunu ve planlanmış ve geçici ürün işleme görevlerinin tamamlanmasını içerir.

• Müşteri Teklif Süreci/API: Yeni veya yerleşik bir müşteri için bir ürün teklifinin işlenmesini düzenler.

• Parti Yönlendirme Profili: Yönlendirme, servis ve ürün/hizmet yerine getirme kararlarını kolaylaştırmak için müşteri etkileşimleri sırasında başvurulan müşteri için temel göstergelerin küçük bir profilini korur.

Dağıtım sürecine genel bakış

Hibrit buluttaki dağıtımları tamamlamak için çevik bir DevSecOps iş akışı kullanıldı. DevSecOps iş akışları, sık ve güvenilir bir yazılım teslim sürecine odaklanır. Metodoloji doğrusal olmaktan çok yinelemelidir; bu, DevOps ekiplerinin kod yazmasına, entegre etmesine, testler yürütmesine, sürümler sunmasına ve değişiklikleri işbirliği içinde ve gerçek zamanlı olarak dağıtmasına olanak tanırken güvenliği ve uyumluluğu kontrol altında tutmasına olanak tanır.

IBM Cloud for Financial Services devreye alımı, güvenli bir giriş bölgesi kümesinde gerçekleştirildi ve altyapı devreye alımı aynı zamanda kod olarak politika kullanılarak otomatikleştirildi (terraform). Uygulama çeşitli bileşenlerden oluşmaktadır. Her bileşen kendi kullanılarak konuşlandırıldı Sürekli entegrasyon (CI), Sürekli Teslimat (CD) ve Sürekli Uyumluluk (CC) RedHat OpenShift Kümesi üzerindeki işlem hattı. Uydu üzerinde dağıtımı gerçekleştirmek için CI/CC işlem hatları yeniden kullanıldı ve yeni bir CD işlem hattı oluşturuldu.

Sürekli entegrasyon

IBM Cloud devreye alımının her bileşeninin kendi CI ardışık düzeni vardı. CI araç zincirinde bir dizi önerilen prosedür ve yaklaşım yer almaktadır. Statik bir kod tarayıcı, uygulama kaynak kodunda saklanan sırların yanı sıra uygulama kodunda bağımlılık olarak kullanılan savunmasız paketler açısından uygulama deposunu incelemek için kullanılır. Her Git taahhüdü için bir kapsayıcı görüntüsü oluşturulur ve derleme numarası, zaman damgası ve taahhüt kimliğine göre görüntüye bir etiket atanır. Bu etiketleme sistemi görüntünün izlenebilirliğini sağlar. İmajı oluşturmadan önce Dockerfile test edilir. Oluşturulan görüntü özel bir görüntü kayıt defterine kaydedilir. Hedef küme dağıtımına ilişkin erişim ayrıcalıkları, iptal edilebilen API belirteçleri kullanılarak otomatik olarak yapılandırılır. Container görüntüsü üzerinde güvenlik açığı taraması gerçekleştirilir. Başarılı bir şekilde tamamlandığında Docker imzası uygulanır. Oluşturulan görüntü etiketinin eklenmesi, dağıtım kaydını anında günceller. Bir küme içinde açık bir ad alanının kullanılması, her dağıtımın yalıtılması amacına hizmet eder. Özellikle Kubernetes kümesinde dağıtım için Git deposunun belirtilen dalıyla birleştirilen herhangi bir kod, otomatik olarak oluşturulur, doğrulanır ve uygulanır.

Her docker görüntüsünün ayrıntıları, bu blogun Sürekli Dağıtım bölümünde ayrıntılı olarak açıklanan bir envanter deposunda saklanır. Ayrıca her boru hattı çalışması sırasında kanıtlar toplanır. Bu kanıt, güvenlik açığı taramaları ve birim testleri gibi araç zincirinde hangi görevlerin gerçekleştirildiğini açıklar. Bu kanıt, gerektiğinde denetlenebilmesi için git deposunda ve bulut nesne depolama grubunda saklanır.

Yukarıda belirtilen IBM Cloud devreye alımı için kullanılan mevcut CI araç zincirlerini Uydu devreye alımı için yeniden kullandık. Uygulama değişmeden kaldığı için yeni dağıtım için CI ardışık düzenlerini yeniden oluşturmak gereksizdi.

Sürekli Dağıtım

Envanter, hangi eserlerin hangi ortamda/bölgede konuşlandırıldığına ilişkin gerçeğin kaynağı olarak hizmet eder; bu, GitOps tabanlı bir yaklaşımla ortamları güncelleyen bir tanıtım hattıyla ortamları temsil etmek için git dalları kullanılarak gerçekleştirilir. Önceki dağıtımlarda envanter aynı zamanda dağıtım dosyalarını da barındırıyordu; bunlar her bileşeni açıklayan YAML Kubernetes kaynak dosyalarıdır. Bu dağıtım dosyaları, her bileşen için Docker görüntüsünün en yeni sürümüyle birlikte doğru ad alanı tanımlayıcılarıyla güncellenecektir.

Ancak birkaç nedenden dolayı bu yaklaşımı zor bulduk. Uygulamalar açısından bakıldığında, YAML değiştirme araçlarını (YQ gibi) kullanarak bu kadar çok resim etiketi değerini ve ad alanını değiştirmek zorunda kalmak kaba ve karmaşıktı. Satellite'ın kendisi için, sağlanan her YAML dosyasının bir "sürüm" olarak sayıldığı doğrudan yükleme stratejisini kullanıyoruz. Yalnızca bir bileşene veya mikro hizmete değil, uygulamanın tamamına karşılık gelen bir sürüme sahip olmayı tercih ederiz.

Farklı bir yaklaşım isteniyordu, bu nedenle dağıtım sürecini bunun yerine Helm grafiği kullanacak şekilde yeniden tasarladık. Bu, ad alanları ve resim etiketleri gibi önemli değerleri parametrelememize ve bunları dağıtım sırasında eklememize olanak sağladı. Bu değişkenlerin kullanılması, belirli bir değer için YAML dosyalarının ayrıştırılmasıyla ilgili birçok zorluğu ortadan kaldırır. Dümen grafiği ayrı olarak oluşturuldu ve oluşturulan BIAN görüntüleriyle aynı kapsayıcı kayıt defterinde saklandı. Şu anda dümen çizelgelerini doğrulamak için özel bir CI hattı geliştirmek için çalışıyoruz; bu, grafiği lintleyecek, paketleyecek, doğruluk açısından imzalayacak (bu, dağıtım zamanında doğrulanacaktır) ve grafiği saklayacaktır. Şimdilik bu adımlar grafiği geliştirmek için manuel olarak yapılıyor. Dümen grafiklerini ve Uydu yapılandırmalarını birlikte kullanmanın bir sorunu vardır: Dümen işlevselliğinin en etkili şekilde çalışabilmesi için bir Kubernetes veya OpenShift kümesiyle doğrudan bağlantı kurulması gerekir ve Uydu elbette buna izin vermez. Dolayısıyla, bu sorunu çözmek için, doğru biçimlendirilmiş grafiğin çıktısını almak üzere "dümen şablonunu" kullanıyoruz ve ardından ortaya çıkan YAML dosyasını Uydu yükleme işlevine aktarıyoruz. Bu işlev daha sonra YAML uygulamasını içeren bir yapılandırma sürümü oluşturmak için IBM Cloud Satellite CLI'den yararlanır. Burada bazı dezavantajlar var: Helm'in sağladığı bazı yararlı işlevleri kullanamıyoruz. geri alma önceki bir grafik sürümüne ve uygulamanın doğru çalıştığından emin olmak için yapılabilecek testler. Ancak bunun yerine Uydu geri alma mekanizmasını kullanabilir ve onun sürümlendirmesini bunun için temel olarak kullanabiliriz.

Sürekli Uyumluluk

CC boru hattı, konuşlandırılan yapıların ve depoların sürekli taranması için önemlidir. Buradaki değer, uygulama dağıtıldıktan sonra keşfedilmiş olabilecek yeni bildirilen güvenlik açıklarını bulmaktır. Aşağıdaki kuruluşlardan gelen en son güvenlik açıkları tanımları: Snyk ve Özgeçmiş Programı bu yeni sorunları takip etmek için kullanılır. CC araç zinciri, uygulama kaynak kodundaki sırları ve uygulama bağımlılıklarındaki güvenlik açıklarını tespit etmek için sağlanan uygulama havuzlarında kullanıcı tanımlı aralıklarla statik bir kod tarayıcı çalıştırır.

İşlem hattı ayrıca konteyner görüntülerini güvenlik açıklarına karşı tarar. Tarama sırasında bulunan veya güncellenen herhangi bir olay sorunu, son tarihle işaretlenir. Taramanın ayrıntılarını özetleyen kanıtlar, her çalıştırmanın sonunda IBM Cloud Object Storage'da oluşturulur ve saklanır.

DevOps İçgörüleri Sorunları ve uygulamanızın genel güvenlik durumunu takip etmek değerlidir. Bu araç, her üç sistemdeki önceki araç zinciri çalıştırmalarından elde edilen tüm ölçümleri içerir: sürekli entegrasyon, dağıtım ve uyumluluk. Herhangi bir tarama veya test sonucu bu sisteme yüklenir ve birbirine çok benzemeye başladı., güvenlik duruşunuzun nasıl geliştiğini gözlemleyebilirsiniz.

CC'nin bulut ortamında kullanılması, müşteri ve uygulama verilerini korumak isteyen finansal hizmetler gibi sıkı düzenlemeye tabi sektörler için önemlidir. Geçmişte bu süreç zordu ve elle yapılması gerekiyordu, bu da kuruluşları riske atıyordu. Fakat IBM Bulut Güvenliği ve Uyumluluk Merkezi, bu riski azaltmaya yardımcı olmak için geliştirme yaşam döngünüze günlük, otomatik uyumluluk kontrolleri ekleyebilirsiniz. Bu kontroller, güvenliği ve uyumluluğu sağlamak için DevSecOps araç zincirlerinin çeşitli değerlendirmelerini içerir.

Bu proje ve diğer benzer projelerdeki deneyimimize dayanarak, ekiplerin IBM Cloud for Financial Services ve IBM Cloud Satellite için hibrit bulut çözümlerini uygulamalarına yardımcı olacak bir dizi en iyi uygulama oluşturduk:

• Sürekli Entegrasyon
  • Farklı araç zincirlerindeki benzer uygulamalar için ortak bir komut dosyası kitaplığı bulundurun. Bu, CI araç zincirinizin ne yapması gerektiğini belirleyen talimatlar dizisidir. Örneğin, NodeJS uygulamalarının derleme süreci genellikle aynı yapıyı izleyecektir; bu nedenle, uygulama oluştururken araç zincirlerinin başvuracağı bir komut dosyası kitaplığını ayrı bir depoda tutmak mantıklıdır. Bu, CI'ya tutarlı bir yaklaşım sağlar, yeniden kullanımı teşvik eder ve sürdürülebilirliği artırır.
  • Alternatif olarak CI araç zincirleri, tetikleyicilerin kullanımıyla benzer uygulamalar için yeniden kullanılabilir; bu ayrı tetikleyiciler hangi uygulamanın oluşturulacağını, uygulama kodunun nerede olduğunu ve diğer özelleştirmeleri belirtmek için kullanılabilir.

• Sürekli Dağıtım
  • Çok bileşenli uygulamalar için, tek bir envanter ve dolayısıyla envanterde listelenen tüm bileşenleri dağıtmak için tek bir dağıtım araç zinciri bulundurun. Bu çok fazla tekrarı önler. Kubernetes YAML dağıtım dosyalarının tümü aynı dağıtım mekanizmasına sahiptir; bu nedenle, her biri üzerinde sırayla yinelenen tek bir araç zinciri, hepsi aslında aynı şeyi yapan birden fazla CD araç zincirini sürdürmekten daha mantıklıdır. Bakım kolaylığı arttı ve uygulamayı dağıtmak için yapılması gereken iş azaldı. İstenirse, tetikleyiciler yine de bireysel mikro hizmetleri dağıtmak için kullanılabilir.
  • Karmaşık çok bileşenli uygulamalar için Helm grafiklerini kullanın. BIAN projesinde Helm'in kullanılması, dağıtımı çok daha kolay hale getirdi. Kubernetes dosyaları YAML'de yazılır ve dağıtım sırasında birden fazla değerin özelleştirilmesi gerekiyorsa bash tabanlı metin ayrıştırıcıların kullanılması zahmetlidir. Helm, değerlerin değiştirilmesini çok daha etkili hale getiren değişkenleri kullanarak bunu basitleştirir. Buna ek olarak Helm, tüm uygulamanın sürüm oluşturma, grafik sürüm oluşturma, dağıtım yapılandırmasının kayıt defterinde saklanması ve arıza durumunda geri alma yetenekleri gibi başka özellikler de sunar. Geri alma işlemi Uyduya özgü dağıtımlarda çalışmazken, bu durum Uydu yapılandırması sürümlendirmesi tarafından karşılanmaktadır.
• Sürekli Uyumluluk
  • Yeni ortaya çıkan güvenlik açıklarına karşı kodu ve yapıtları sürekli olarak taramak için altyapınızın bir parçası olarak CC araç zincirleri kurmanızı önemle tavsiye ederiz. Genellikle bu taramalar her gece veya uygulamanıza ve güvenlik durumunuza uygun olan herhangi bir programda çalıştırılabilir. Sorunları ve uygulamanızın genel güvenlik durumunu takip etmek için DevOps Insights'ı kullanmanızı öneririz.
  • Güvenlik duruşunuzu otomatikleştirmek için Güvenlik ve Uyumluluk Merkezi'nin (SCC) kullanılmasını da öneririz. İşlem hatları tarafından oluşturulan kanıt özeti, kanıt özetindeki her girişin, bir güvenlik açığı taraması, birim testi veya benzeri şeyler gibi bir araç zincirinde tamamlanan bir görevle ilgili bir "gerçek" olarak değerlendirildiği SCC'ye yüklenebilir. . SCC daha sonra takım zincirleriyle ilgili en iyi uygulamaların takip edildiğini belirlemek için kanıtlara göre doğrulama testleri gerçekleştirecek.
• Envanter
  • Daha önce de belirtildiği gibi, sürekli dağıtımda, tüm mikro hizmet ayrıntılarınızın (Helm kullanılmıyorsa) Kubernetes dağıtım dosyalarıyla birlikte depolanacağı tek bir uygulama envanterinin tutulması tercih edilir. Bu, dağıtımlarınızın durumuyla ilgili tek bir gerçek kaynağına olanak tanır; Envanterinizdeki şubeler ortamları temsil ettiğinden, bu ortamların birden fazla envanter deposunda sürdürülmesi çok hızlı bir şekilde zahmetli hale gelebilir.
• Kanıt
  • Kanıt depolarına yönelik yaklaşım envanterden farklı ele alınmalıdır. Bu durumda, bileşen başına bir kanıt deposu tercih edilir; bunları birleştirirseniz, saklanan kanıtlar bunaltıcı hale gelebilir ve yönetilmesi zor olabilir. Kanıt belirli bir bileşene özel bir havuzda saklanırsa, belirli kanıt parçalarının yerini tespit etmek çok daha verimli olur. Dağıtım için, tek bir dağıtım araç zincirinden kaynaklandığı için tek bir kanıt dolabı kabul edilebilir.
  • Kanıtların bir bulut nesne depolama grubunda saklanmasını ve varsayılan git deposu seçeneğinin kullanılmasını önemle tavsiye ederiz. Bunun nedeni, bir COS kümesinin değişmez olacak şekilde yapılandırılabilmesidir; bu da, denetim izleri durumunda çok önemli olan, kurcalama olasılığı olmadan kanıtları güvenli bir şekilde saklamamıza olanak tanır.        

Sonuç

Bu blogda, hibrit bulutta BIAN'a dayalı bir bankacılık uygulamasını hayata geçirme, yani iş yükünü hem IBM Cloud hem de Uydu ortamında devreye almak için DevSecOps ardışık düzenlerini kullanma deneyimimizi sergiledik. Farklı yaklaşımların artılarını ve eksilerini ve bu projeyi inceledikten sonra elde ettiğimiz en iyi uygulamaları tartıştık. Bunun, diğer ekiplerin hibrit bulut yolculuklarını daha tutarlı ve hızlı bir şekilde gerçekleştirmelerine yardımcı olabileceğini umuyoruz. Düşüncelerinizi bize bildirin.

IBM'in bugün neler sunabileceğini keşfedin