Najboljše prakse za varno in skladno uvajanje hibridnih aplikacij za bančništvo v oblaku v IBM Cloud in Satellite - IBM Blog

Najboljše prakse za varno in skladno uvajanje hibridnih aplikacij za bančništvo v oblaku v IBM Cloud in Satellite – IBM Blog

Izvorno vozlišče: 2984448


Koncentrirana mlada Afroameričanka, ki dela z ekonomskim poročilom.

Stranke finančnih storitev vedno bolj želijo posodobiti svoje aplikacije. To vključuje posodobitev razvoja in vzdrževanja kode (pomoč pri redkih veščinah in omogočanje inovacij in novih tehnologij, ki jih potrebujejo končni uporabniki) ter izboljšanje uvajanja in delovanja z uporabo agilnih tehnik in DevSecOps.

Stranke želijo kot del svoje posodobitvene poti imeti prožnost pri določanju, katera lokacija za uvedbo njihovih aplikacij je najboljša »primerna za namen«. To je lahko v katerem koli okolju, ki ga podpira Hybrid Cloud (lokalno, v zasebnem oblaku, v javnem oblaku ali na robu). IBM Cloud Satellite® izpolnjuje to zahtevo tako, da omogoča, da se sodobne, v oblaku izvorne aplikacije izvajajo povsod, kjer odjemalec zahteva, hkrati pa ohranja standardno in dosledno nadzorno ravnino za upravljanje aplikacij v hibridnem oblaku.

Poleg tega mnoge od teh aplikacij za finančne storitve podpirajo regulirane delovne obremenitve, ki zahtevajo stroge ravni varnosti in skladnosti, vključno z zaščito delovnih obremenitev z ničelnim zaupanjem. IBM Cloud for Financial Services izpolnjuje to zahtevo z zagotavljanjem varnosti in skladnosti od konca do konca, ki ga je mogoče uporabiti za varno implementacijo in/ali posodobitev aplikacij v hibridnem oblaku.

V tem prispevku prikazujemo, kako preprosto uvesti bančno aplikacijo na obeh IBM Cloud za finančne storitve in Satelitske, z uporabo avtomatiziranih cevovodov CI/CD/CC na skupen in dosleden način. To zahteva visoko raven varnosti in skladnosti v celotnem procesu gradnje in uvajanja.

Uvod v koncepte in izdelke

Namen IBM Cloud for Financial Services je zagotavljanje varnosti in skladnosti za podjetja za finančne storitve. To počne z uporabo industrijskih standardov, kot je NIST 800-53 in strokovno znanje več kot sto strank finančnih storitev, ki so del Sveta za oblake finančnih storitev. Zagotavlja nadzorni okvir, ki ga je mogoče preprosto implementirati z uporabo referenčnih arhitektur, preverjenih storitev v oblaku in ISV-jev, kot tudi najvišje ravni šifriranja in stalne skladnosti (CC) v hibridnem oblaku.

IBM Cloud Satellite zagotavlja pravo izkušnjo hibridnega oblaka. Satellite omogoča izvajanje delovnih obremenitev kjer koli brez ogrožanja varnosti. Ena sama steklena plošča omogoča lažji ogled vseh virov na eni armaturni plošči. Za uvajanje aplikacij v ta različna okolja smo razvili nabor robustnih orodnih verig DevSecOps za izdelavo aplikacij, njihovo uvajanje na satelitsko lokacijo na varen in dosleden način ter spremljanje okolja z uporabo najboljših praks DevOps.

V tem projektu smo uporabili aplikacijo za izdajo posojila, ki je bila posodobljena za uporabo Kubernetesa in mikrostoritev. Za zagotavljanje te storitve bančna aplikacija uporablja ekosistem partnerskih aplikacij, ki medsebojno delujejo z uporabo BIAN okvir.

Pregled uporabe

Aplikacija, uporabljena v tem projektu, je aplikacija za odobritev posojila, razvita kot del BIAN brez jedra 2.0 pobuda. Stranka pridobi prilagojeno posojilo prek varnega spletnega kanala, ki ga ponuja banka. Aplikacija uporablja ekosistem partnerskih aplikacij, ki medsebojno delujejo na arhitekturi BIAN, ki je nameščena v IBM Cloud for Financial Services. Pobuda BIAN Coreless Initiative omogoča finančnim institucijam, da izberejo najboljše partnerje za hitro in učinkovito uvajanje novih storitev na trg prek arhitektur BIAN. Vsaka komponenta ali domena storitve BIAN je implementirana prek mikrostoritve, ki je nameščena v gruči OCP v IBM Cloud.

Komponente aplikacije, ki temeljijo na domenah storitev BIAN

  • Imenik izdelkov: vzdržuje obsežen imenik produktov in storitev banke.
  • Potrošniško posojilo: Ukvarja se z izpolnitvijo produkta potrošniškega posojila. To vključuje začetno postavitev posojila in dokončanje načrtovanih in ad hoc nalog obdelave izdelkov.
  • Proces ponudbe strank/API: Orkestrira obdelavo ponudbe izdelkov za novo ali uveljavljeno stranko.
  • Profil usmerjanja strank: vzdržuje majhen profil ključnih kazalnikov za stranko, na katerega se sklicuje med interakcijo s stranko, da olajša usmerjanje, servisiranje in odločitve o izpolnitvi izdelka/storitve.
Slika 1: Komponente aplikacije, ki temeljijo na domenah storitev BIAN

Pregled postopka uvajanja

Za dokončanje uvedb v hibridnem oblaku je bil uporabljen agilni potek dela DevSecOps. Delovni tokovi DevSecOps se osredotočajo na pogost in zanesljiv proces dostave programske opreme. Metodologija je iterativna in ne linearna, kar ekipam DevOps omogoča, da napišejo kodo, jo integrirajo, izvedejo teste, dostavijo izdaje in uvedejo spremembe skupaj in v realnem času, pri tem pa nadzorujejo varnost in skladnost.

Uvedba IBM Cloud for Financial Services je bila dosežena v gruči varnega pristajalnega območja, uvedba infrastrukture pa je prav tako avtomatizirana z uporabo pravilnika kot kode (terraform). Aplikacija je sestavljena iz različnih komponent. Vsaka komponenta je bila nameščena z lastno Neprekinjena integracija (CI), Neprekinjena dostava (CD) in Stalna skladnost (CC) cevovod v gruči RedHat OpenShift. Da bi dosegli uvedbo na Satellite, so bili ponovno uporabljeni cevovodi CI/CC in ustvarjen je bil nov cevovod CD.

Nenehno povezovanje

Vsaka komponenta uvedbe IBM Cloud je imela svoj cevovod CI. Niz priporočenih postopkov in pristopov je vključen v orodno verigo CI. Skener statične kode se uporablja za pregledovanje repozitorija aplikacije glede morebitnih skrivnosti, shranjenih v izvorni kodi aplikacije, kot tudi morebitnih ranljivih paketov, ki se uporabljajo kot odvisnosti znotraj kode aplikacije. Za vsako potrditev Git se ustvari slika vsebnika in sliki se dodeli oznaka na podlagi številke gradnje, časovnega žiga in ID-ja objave. Ta sistem označevanja zagotavlja sledljivost slike. Pred ustvarjanjem slike se datoteka Docker testira. Ustvarjena slika se shrani v zasebni register slik. Privilegiji dostopa za uvedbo ciljne gruče so samodejno konfigurirani z uporabo žetonov API, ki jih je mogoče preklicati. Na sliki vsebnika se izvede pregled varnostne ranljivosti. Po uspešnem zaključku se uporabi podpis Docker. Dodatek ustvarjene slikovne oznake takoj posodobi zapis o uvedbi. Uporaba eksplicitnega imenskega prostora znotraj gruče je namenjena izolaciji vsake razmestitve. Vsaka koda, ki je združena v določeno vejo repozitorija Git, izrecno za uvajanje v gručo Kubernetes, je samodejno izdelana, preverjena in implementirana.

Podrobnosti o vsaki sliki dockerja so shranjene v skladišču inventarja, ki je podrobno razloženo v razdelku o neprekinjenem uvajanju tega spletnega dnevnika. Poleg tega se med vsakim potekom cevovoda zbirajo dokazi. Ti dokazi opisujejo, katere naloge so bile izvedene v orodni verigi, kot so pregledi ranljivosti in testi enot. Ti dokazi so shranjeni v repozitoriju git in vedru za shranjevanje objektov v oblaku, tako da jih je mogoče po potrebi revidirati.

Ponovno smo uporabili trenutne orodne verige CI, ki se uporabljajo za zgoraj navedeno uvedbo IBM Cloud, za uvedbo Satellite. Ker je aplikacija ostala nespremenjena, ni bilo treba znova zgraditi cevovodov CI za novo uvedbo.

Neprekinjeno uvajanje

Popis služi kot vir resnice o tem, kateri artefakti so nameščeni v katerem okolju/regiji; to se doseže z uporabo vej git za predstavljanje okolij, s promocijskim cevovodom, ki posodablja okolja v pristopu, ki temelji na GitOps. V prejšnjih uvedbah je inventar gostil tudi datoteke uvedbe; to so datoteke virov YAML Kubernetes, ki opisujejo vsako komponento. Te datoteke za uvajanje bi bile posodobljene s pravilnimi deskriptorji imenskega prostora, skupaj z najnovejšo različico slike Docker za vsako komponento.

Vendar smo ugotovili, da je ta pristop težaven zaradi nekaj razlogov. Z vidika aplikacij je bilo spreminjanje toliko vrednosti slikovnih oznak in imenskih prostorov z orodji za zamenjavo YAML (kot je YQ) surovo in zapleteno. Za sam Satellite uporabljamo strategijo neposrednega nalaganja, pri čemer vsaka predložena datoteka YAML šteje kot »različica«. Raje bi imeli različico, ki ustreza celotni aplikaciji, ne le eni komponenti ali mikrostoritvi.

Zaželen je bil drugačen pristop, zato smo preoblikovali postopek uvajanja, da bi namesto tega uporabili grafikon Helm. To nam je omogočilo, da smo parametrirali pomembne vrednosti, kot so imenski prostori in slikovne oznake, in jih vnesli v času uvajanja. Uporaba teh spremenljivk odpravi veliko težav, povezanih z razčlenjevanjem datotek YAML za dano vrednost. Krmilna karta je bila ustvarjena ločeno in shranjena v istem registru vsebnikov kot zgrajene slike BIAN. Trenutno si prizadevamo razviti poseben CI cevovod za potrjevanje krmilnih kart; to bo grafikon prelilo, ga zapakiralo, podpisalo za verodostojnost (to bi bilo preverjeno ob času uvajanja) in shranilo grafikon. Zaenkrat se ti koraki izvajajo ročno za razvoj grafikona. Pri uporabi krmilnih grafikonov in konfiguracij Satellite skupaj obstaja ena težava: funkcija krmila zahteva neposredno povezavo z gručo Kubernetes ali OpenShift za najbolj učinkovito delovanje, Satellite pa tega seveda ne dovoli. Da bi rešili to težavo, uporabimo »helm template« za izpis pravilno oblikovanega grafikona in nato posredujemo nastalo datoteko YAML funkciji za nalaganje satelitov. Ta funkcija nato izkoristi IBM Cloud Satellite CLI za ustvarjanje konfiguracijske različice, ki vsebuje aplikacijo YAML. Tukaj je nekaj pomanjkljivosti: ne moremo uporabiti nekaterih uporabnih funkcij, ki jih ponuja Helm, kot je možnost, da rollback na prejšnjo različico grafikona in preizkuse, ki jih je mogoče izvesti, da zagotovite pravilno delovanje aplikacije. Lahko pa uporabimo mehanizem za povrnitev Satellite kot zamenjavo in uporabimo njegovo različico kot osnovo za to.

Slika 2: Cevovodi in komponente BIAN Coreless 2.0 pri prejšnji uvedbi v IBM Cloud FS
Slika 3: Cevovodi in komponente BIAN Coreless 2.0 na IBM Cloud Satellite 

Stalna skladnost

Cevovod CC je pomemben za neprekinjeno skeniranje razporejenih artefaktov in skladišč. Vrednost tukaj je v iskanju na novo prijavljenih ranljivosti, ki so bile morda odkrite po uvedbi aplikacije. Najnovejše definicije ranljivosti organizacij kot npr Snyk in Program CVE se uporabljajo za sledenje tem novim težavam. Veriga orodij CC zažene statični skener kode v uporabniško določenih intervalih v repozitorijih aplikacij, ki so na voljo za odkrivanje skrivnosti v izvorni kodi aplikacije in ranljivosti v odvisnostih aplikacij.

Cevovod tudi skenira slike vsebnikov za varnostne ranljivosti. Vsaka težava z incidentom, ki je najdena med skeniranjem ali posodobljena, je označena z rokom. Dokazi so ustvarjeni in shranjeni v IBM Cloud Object Storage na koncu vsakega zagona, ki povzema podrobnosti skeniranja.

DevOps Insights je dragocen za sledenje težavam in splošni varnosti vaše aplikacije. To orodje vsebuje vse meritve iz prejšnjih izvajanj verige orodij v vseh treh sistemih: neprekinjeno integracijo, uvajanje in skladnost. Vsi rezultati skeniranja ali testiranja se naložijo v ta sistem in čez čas, lahko opazujete, kako se razvija vaša varnostna drža.

Pridobitev CC v okolju oblaka je pomembna za visoko regulirane panoge, kot so finančne storitve, ki želijo zaščititi podatke strank in aplikacij. V preteklosti je bil ta proces težak in ga je bilo treba izvajati ročno, kar ogroža organizacije. Ampak z IBM Cloud Security and Compliance Center, lahko dodate dnevne samodejne preglede skladnosti v svoj življenjski cikel razvoja, da zmanjšate to tveganje. Ti pregledi vključujejo različne ocene orodnih verig DevSecOps za zagotavljanje varnosti in skladnosti.

Slika 4: Nadzorna plošča središča za varnost in skladnost

Na podlagi naših izkušenj s tem projektom in drugimi podobnimi projekti smo ustvarili niz najboljših praks za pomoč ekipam pri implementaciji hibridnih rešitev v oblaku za IBM Cloud for Financial Services in IBM Cloud Satellite:

  • Stalna integracija
    • Ohranite skupno knjižnico skriptov za podobne aplikacije v različnih verigah orodij. To je nabor navodil, ki določajo, kaj naj počne vaša orodna veriga CI. Na primer, postopek gradnje za aplikacije NodeJS bo na splošno sledil isti strukturi, zato je smiselno hraniti skriptno knjižnico v ločenem repozitoriju, na katerega se bodo orodne verige sklicevale pri gradnji aplikacij. To omogoča dosleden pristop k KI, spodbuja ponovno uporabo in povečuje vzdržljivost.
    • Druga možnost je, da se orodne verige CI lahko ponovno uporabijo za podobne aplikacije z uporabo sprožilcev; te ločene sprožilce je mogoče uporabiti za določitev, katera aplikacija naj bo izdelana, kje je koda za aplikacijo in druge prilagoditve.
  • Neprekinjeno uvajanje
    • Za večkomponentne aplikacije vzdržujte en inventar in s tem eno samo verigo orodij za uvajanje za uvajanje vseh komponent, navedenih v inventarju. To prepreči veliko ponavljanja. Datoteke za uvajanje Kubernetes YAML imajo vse enak mehanizem uvajanja, zato je ena sama veriga orodij, ki ponavlja vsako po vrsti, bolj logična kot vzdrževanje več verig orodij CD, ki v bistvu vse delajo isto stvar. Vzdrževanje se je povečalo, zato je manj dela za uvajanje aplikacije. Če želite, lahko še vedno uporabite sprožilce za uvajanje posameznih mikrostoritev.
    • Uporabite karte Helm za kompleksne večkomponentne aplikacije. Uporaba Helma v projektu BIAN je močno olajšala uvajanje. Datoteke Kubernetes so napisane v YAML in uporaba razčlenjevalnikov besedila, ki temeljijo na bash, je okorna, če je treba ob času uvajanja prilagoditi več vrednosti. Helm to poenostavi z uporabo spremenljivk, zaradi česar je zamenjava vrednosti veliko bolj učinkovita. Poleg tega Helm ponuja druge funkcije, kot so različica celotne aplikacije, različica grafikona, shranjevanje konfiguracije razmestitve v registru in zmožnosti povrnitve v prejšnje stanje v primeru okvare. Medtem ko povrnitev ne bo delovala pri razmestitvah, specifičnih za Satellite, je za to poskrbljeno z različicami konfiguracije Satellite.
  • Stalna skladnost
    • Močno priporočamo, da nastavite verige orodij CC kot del svoje infrastrukture za nenehno skeniranje kode in artefaktov za ranljivosti, ki so na novo izpostavljene. Običajno se ta skeniranja lahko izvajajo vsako noč ali po urniku, ki ustreza vaši aplikaciji in varnostni situaciji. Če želite spremljati težave in splošno varnostno stanje vaše aplikacije, predlagamo, da uporabite DevOps Insights.
    • Priporočamo tudi uporabo centra za varnost in skladnost (SCC) za avtomatizacijo vaše varnostne drže. Povzetek dokazov, ki ga ustvarijo cevovodi, je mogoče naložiti v SCC, kjer se vsak vnos v povzetek dokazov obravnava kot »dejstvo«, povezano z nalogo, dokončano v verigi orodij, pa naj bo to pregled ranljivosti, preizkus enote ali druge podobne stvari . SCC bo nato izvedel validacijske teste glede na dokaze, da ugotovi, ali se upoštevajo najboljše prakse v zvezi z orodnimi verigami.
  • popis
    • Kot je bilo že omenjeno, je pri neprekinjenem uvajanju bolje vzdrževati en inventar aplikacij, v katerem bodo shranjene vse vaše podrobnosti o mikrostoritvah, skupaj z (če ne uporabljate Helma) datotekami za uvajanje Kubernetes. To omogoča en sam vir resnice glede stanja vaših uvajanj; ker veje v vašem inventarju predstavljajo okolja, lahko vzdrževanje teh okolij v več repozitorijih inventarja zelo hitro postane okorno.
  • dokazi
    • Pristop k skladiščem dokazov je treba obravnavati drugače kot pristop k popisu. V tem primeru je zaželeno eno skladišče dokazov na komponento; če jih združite, lahko shranjeni dokazi postanejo ogromni in jih je težko upravljati. Iskanje določenih dokazov je veliko bolj učinkovito, če so dokazi shranjeni v skladišču, ki je specifično za komponento. Za uvajanje je sprejemljiva ena omarica za dokaze, saj izvira iz ene same verige orodij za uvajanje.
    • Močno priporočamo shranjevanje dokazov v vedro za shranjevanje objektov v oblaku in uporabo privzete možnosti repozitorija git. To je zato, ker je vedro COS mogoče konfigurirati tako, da je nespremenljivo, kar nam omogoča varno shranjevanje dokazov brez možnosti poseganja, kar je zelo pomembno v primeru revizijskih sledi.        

zaključek

V tem spletnem dnevniku smo predstavili naše izkušnje z implementacijo bančne aplikacije, ki temelji na BIAN, v hibridnem oblaku, to je z uporabo cevovodov DevSecOps za razporeditev delovne obremenitve tako v IBM Cloud kot tudi v Satellite okolje. Razpravljali smo o prednostih in slabostih različnih pristopov ter najboljših praksah, ki smo jih izpeljali po tem projektu. Upamo, da bo to lahko pomagalo drugim ekipam doseči njihovo hibridno potovanje v oblaku z več doslednosti in hitrostjo. Sporočite nam svoje misli.

Raziščite, kaj IBM ponuja danes


Več od Oblaka




Izboljšajte svoje aplikacije Kafka s shemami

4 min branja - Apache Kafka je znana odprtokodna trgovina dogodkov in platforma za obdelavo tokov in je zrasla v de facto standard za pretakanje podatkov. V tem članku razvijalec Michael Burgess ponuja vpogled v koncept shem in upravljanje shem kot način za dodajanje vrednosti vašim aplikacijam, ki temeljijo na dogodkih, v popolnoma upravljani storitvi Kafka, IBM Event Streams on IBM Cloud®. Kaj je shema? Shema opisuje strukturo podatkov. Na primer: preprost razred Java ...




SSD proti NVMe: Kakšna je razlika?

7 min branja - Nedavni tehnološki napredek pri shranjevanju podatkov je spodbudil podjetja in potrošnike, da se odmaknejo od tradicionalnih trdih diskov (HDD) k hitrejši tehnologiji pogonov SSD (SSD) z nižjo zakasnitvijo. V tem prispevku si bomo ogledali to novo tehnologijo, pa tudi najhitrejši in najbolj priljubljen protokol, ki je na voljo za povezavo z matično ploščo računalnika – ekspresni obstojni pomnilnik (NVMe). Medtem ko se izraza SSD in NVMe pogosto uporabljata za opis dveh različnih vrst pogonov, sta dejansko različna pomnilnika podatkov ...




Vodje podjetij poudarjajo potrebo po pristopu hibridnega oblaka, da bi sprostili moč generativne umetne inteligence

3 min branja - Leta 2023 so se organizacije soočile s pritiskom brez primere glede digitalne preobrazbe z vzponom generativne umetne inteligence ter zahtevami, kot so trajnost, delovna produktivnost in varnost. »Cloud Transformation Report«, nova globalna raziskava IBM-ovega inštituta za poslovno vrednost (IBV), je pokazala, da ima veliko vodilnih podjetij skupne temelje za digitalno preobrazbo – jasno strategijo hibridnega oblaka.¹ Ta podjetja navajajo več ključnih prednosti uporabe pristop hibridnega oblaka za spodbujanje poslovne transformacije, vključno z modernizacijo,…




Uvod v Wazi kot storitev

4 min branja - V današnjem hiperkonkurenčnem digitalnem okolju je hiter razvoj novih digitalnih storitev bistvenega pomena za ohranjanje prednosti. Vendar pa se številne organizacije soočajo s precejšnjimi izzivi, ko gre za integracijo njihovih osnovnih sistemov, vključno z aplikacijami Mainframe, s sodobnimi tehnologijami. Ta integracija je ključnega pomena za posodobitev osrednjih aplikacij podjetja na platformah hibridnega oblaka. Šokantno je, da osupljivih 33 % razvijalcev nima potrebnih veščin ali virov, kar ovira njihovo produktivnost pri zagotavljanju izdelkov in storitev. Poleg tega se 36 % razvijalcev spopada z ...

IBM-ove novice

Prejemajte naša glasila in posodobitve tem, ki prinašajo najnovejše miselno vodstvo in vpogled v nastajajoče trende.

Naročite zdaj

Več glasil

Časovni žig:

Več od IBM