A hibrid felhőbanki alkalmazások bevált gyakorlatai biztonságos és megfelelő telepítéshez az IBM Cloud és Satellite szolgáltatásban – IBM Blog

A pénzügyi szolgáltatások ügyfelei egyre inkább korszerűsítik alkalmazásaikat. Ez magában foglalja a kódfejlesztés és -karbantartás korszerűsítését (a szűkös készségekkel való segítés, valamint az innováció és a végfelhasználók által igényelt új technológiák lehetővé tétele), valamint a telepítés és a működés javítása, agilis technikák és DevSecOps.

Modernizációs útjuk részeként az ügyfelek rugalmasságot szeretnének biztosítani annak meghatározásában, hogy melyik a legmegfelelőbb telepítési hely alkalmazásaik számára. Ez előfordulhat a Hybrid Cloud által támogatott bármely környezetben (telephelyen, privát felhőn, nyilvános felhőn vagy a szélén). Az IBM Cloud Satellite® teljesíti ezt a követelményt azáltal, hogy lehetővé teszi, hogy a modern, felhőalapú alkalmazások bárhol futhassanak, ahol az ügyfél igényli, miközben fenntart egy szabványos és konzisztens vezérlősíkot az alkalmazások adminisztrációjához a hibrid felhőben.

Ezen túlmenően a pénzügyi szolgáltatási alkalmazások közül sok támogatja a szabályozott munkaterheléseket, amelyek szigorú biztonsági és megfelelőségi szinteket igényelnek, beleértve a munkaterhelések Zero Trust védelmét. Az IBM Cloud for Financial Services teljesíti ezt a követelményt azáltal, hogy végpontok közötti biztonsági és megfelelőségi keretrendszert biztosít, amely használható alkalmazások biztonságos megvalósítására és/vagy modernizálására a hibrid felhőben.

Ebben a cikkben bemutatjuk, hogyan lehet egyszerűen telepíteni egy banki alkalmazást mindkettőre IBM Cloud for Financial Services és a műhold, automatizált CI/CD/CC csővezetékek közös és következetes módon történő használatával. Ez magas szintű biztonságot és megfelelőséget igényel a teljes összeállítási és telepítési folyamat során.

Koncepciók és termékek bemutatása

Az IBM Cloud for Financial Services célja, hogy biztonságot és megfelelőséget biztosítson a pénzügyi szolgáltató vállalatok számára. Ezt olyan iparági szabványok kihasználásával teszi, mint pl NIST 800-53 és több mint száz pénzügyi szolgáltatási ügyfél szakértelme, akik a Financial Services Cloud Council részét képezik. Olyan vezérlési keretrendszert biztosít, amely könnyen megvalósítható referenciaarchitektúrák, Validated Cloud Services és ISV-k, valamint a legmagasabb szintű titkosítás és folyamatos megfelelés (CC) használatával a hibrid felhőben.

Az IBM Cloud Satellite valódi hibrid felhő élményt nyújt. A műhold lehetővé teszi a munkaterhelések bárhol futtatását a biztonság veszélyeztetése nélkül. Egyetlen üvegtábla lehetővé teszi, hogy az összes erőforrást egyetlen műszerfalon tekintse meg. Az alkalmazások ezekben a különböző környezetekben történő üzembe helyezéséhez robusztus DevSecOps eszközláncokat fejlesztettünk ki, amelyekkel alkalmazásokat hozhatunk létre, biztonságosan és következetesen telepíthetünk egy műholdhelyre, és figyelhetjük a környezetet a legjobb DevOps-módszerekkel.

Ebben a projektben egy hitelnyújtási alkalmazást használtunk, amelyet Kubernetes és mikroszolgáltatások használatára korszerűsítettünk. A szolgáltatás nyújtásához a banki alkalmazás partneralkalmazások ökoszisztémáját alkalmazza, amelyek együttműködnek a BIAN keretet.

Az alkalmazás áttekintése

A projektben használt alkalmazás egy hitelnyújtási alkalmazás, amelyet a projekt részeként fejlesztettek ki BIAN Coreless 2.0 kezdeményezés. Az ügyfél személyre szabott hitelhez jut a bank által kínált biztonságos online csatornán keresztül. Az alkalmazás a BIAN architektúrán együttműködő partneralkalmazások ökoszisztémáját alkalmazza, amely az IBM Cloud for Financial Services rendszeren van telepítve. A BIAN Coreless Initiative felhatalmazza a pénzintézeteket a legjobb partnerek kiválasztására, hogy segítsenek gyorsan és hatékonyan új szolgáltatásokat piacra vinni a BIAN architektúrákon keresztül. Minden egyes összetevő vagy BIAN szolgáltatási tartomány egy mikroszolgáltatáson keresztül valósul meg, amelyet az IBM Cloud OCP-fürtjére telepítenek.

BIAN szolgáltatási tartományokon alapuló alkalmazáskomponensek

• Termékkönyvtár: Átfogó jegyzéket vezet a bank termékeiről és szolgáltatásairól.

• Fogyasztói kölcsön: Fogyasztói hiteltermék teljesítését kezeli. Ez magában foglalja a hitelkeret kezdeti felállítását, valamint az ütemezett és ad hoc termékfeldolgozási feladatok elvégzését.

• Ügyfélajánlat folyamata/API: Egy új vagy letelepedett vásárló termékajánlatának feldolgozását szervezi.

• Party Routing Profile: Karbantartja a kulcsfontosságú mutatók kis profilját az ügyfelek számára, amelyekre hivatkoznak az ügyfelekkel folytatott interakciók során, hogy megkönnyítse az útválasztást, a szervizelést és a termék/szolgáltatás teljesítési döntéseit.

A telepítési folyamat áttekintése

Agilis DevSecOps munkafolyamatot használtak a hibrid felhőn keresztüli telepítések befejezéséhez. A DevSecOps munkafolyamatok a gyakori és megbízható szoftverszállítási folyamatra összpontosítanak. A módszertan inkább iteratív, mint lineáris, ami lehetővé teszi a DevOps-csapatok számára, hogy kódot írjanak, integráljanak, teszteket futtassák, kiadásokat szállítsanak ki és változtatásokat telepítsenek együttműködve és valós időben, a biztonság és a megfelelőség ellenőrzése mellett.

Az IBM Cloud for Financial Services üzembe helyezése egy biztonságos leszállózóna-fürtben valósult meg, és az infrastruktúra üzembe helyezése is automatizált, kódként kódolt házirend (terra forma). Az alkalmazás különböző összetevőkből áll. Mindegyik komponenst a sajátjával telepítették Folyamatos integráció (CI), Folyamatos kézbesítés (CD) és a Folyamatos megfelelőség (CC) csővezeték egy RedHat OpenShift Clusteren. A műholdon történő üzembe helyezés érdekében a CI/CC-folyamatokat újra felhasználták, és egy új CD-folyamatot hoztak létre.

Folyamatos integráció

Az IBM Cloud telepítés minden összetevője saját CI-folyamattal rendelkezett. Az ajánlott eljárások és megközelítések egy készletét tartalmazza a CI eszközlánc. Statikus kódolvasó segítségével ellenőrzik az alkalmazástárat az alkalmazás forráskódjában tárolt titkok, valamint az alkalmazás kódjában függőségként használt sebezhető csomagok tekintetében. Minden Git véglegesítéshez létrejön egy tárolókép, és egy címke hozzárendelődik a képhez a buildszám, az időbélyeg és a véglegesítési azonosító alapján. Ez a címkéző rendszer biztosítja a kép nyomon követhetőségét. A kép létrehozása előtt a Dockerfile tesztelésre kerül. A létrehozott kép egy privát képfájl-nyilvántartásba kerül mentésre. A célfürt-telepítéshez tartozó hozzáférési jogosultságok automatikusan konfigurálhatók API-tokenek segítségével, amelyek visszavonhatók. A biztonsági rés vizsgálata a tárolóképen történik. A sikeres befejezés után a rendszer Docker-aláírást alkalmaz. A létrehozott képcímke hozzáadása azonnal frissíti a telepítési rekordot. A fürtön belüli kifejezett névtér használata az egyes telepítések elkülönítését szolgálja. Minden olyan kód, amely a Git-tárhely meghatározott ágába van egyesítve, kifejezetten a Kubernetes-fürtön való üzembe helyezés céljából, automatikusan létrejön, ellenőrzi és implementálja.

Az egyes docker-képek részletei egy leltártárban vannak tárolva, amely részletes leírása ennek a blognak a Folyamatos telepítés szakaszában található. Ezen túlmenően minden csővezeték-futás során bizonyítékokat gyűjtenek. Ez a bizonyíték leírja, hogy milyen feladatokat hajtottak végre az eszközláncban, például sebezhetőségi vizsgálatokat és egységteszteket. Ezeket a bizonyítékokat egy git-tárolóban és egy felhőobjektum-tárolótárolóban tárolják, hogy szükség esetén auditálhatók legyenek.

Újra felhasználtuk az IBM Cloud telepítéshez használt jelenlegi CI-eszközláncokat, amelyeket a fentiekben említettünk a műholdas telepítéshez. Mivel az alkalmazás változatlan maradt, szükségtelen volt a CI-csővezetékek újjáépítése az új telepítéshez.

Folyamatos telepítés

A leltár az igazság forrásaként szolgál arra vonatkozóan, hogy milyen műtermékeket milyen környezetben/régióban helyeznek el; ezt a környezetek megjelenítésére szolgáló git-ágak használatával érik el, a GitOps-alapú megközelítésben egy promóciós folyamat segítségével frissítik a környezeteket. A korábbi telepítésekben a leltár telepítési fájlokat is tárolt; ezek a YAML Kubernetes erőforrásfájlok, amelyek leírják az egyes összetevőket. Ezeket a telepítési fájlokat a megfelelő névtér-leírókkal frissítjük, valamint az egyes összetevők Docker-lemezképének legújabb verzióját.

Ezt a megközelítést azonban néhány okból nehéznek találtuk. Az alkalmazások szemszögéből nézve, hogy oly sok képcímke-értéket és névteret kellett módosítani YAML-csereeszközök (például YQ) segítségével, durva és bonyolult volt. Magához a Satellite-hez a közvetlen feltöltési stratégiát használjuk, ahol minden YAML fájl „verziónak” számít. Szeretnénk, ha egy verzió megfelelne a teljes alkalmazásnak, nem csak egy összetevőnek vagy mikroszolgáltatásnak.

Más megközelítésre volt szükség, ezért átterveztük a telepítési folyamatot, hogy helyette Helm diagramot használjunk. Ez lehetővé tette számunkra, hogy paraméterezzük a fontos értékeket, például a névtereket és a képcímkéket, és beillesszük őket a telepítéskor. Ezeknek a változóknak a használata sok nehézséget kiküszöböl a YAML-fájlok adott értékhez történő elemzésével kapcsolatban. A vezetődiagram külön jött létre, és ugyanabban a konténer-nyilvántartásban tárolódott, mint a beépített BIAN lemezképek. Jelenleg egy speciális CI-folyamat kifejlesztésén dolgozunk a kormánydiagramok érvényesítésére; ez felborítja a diagramot, becsomagolja, aláírja a hitelesség érdekében (ezt a telepítéskor ellenőrizni fogják), és eltárolja a diagramot. Egyelőre ezeket a lépéseket manuálisan kell elvégezni a diagram elkészítéséhez. Egy probléma van a kormánydiagramok és a műholdkonfigurációk együttes használatával: a kormányfunkciókhoz közvetlen kapcsolatra van szükség egy Kubernetes vagy OpenShift fürttel a leghatékonyabb működéshez, és a műhold ezt természetesen nem teszi lehetővé. Tehát a probléma megoldásához a „helm template” segítségével kiadjuk a megfelelően formázott diagramot, majd átadjuk a kapott YAML fájlt a műholdas feltöltési funkciónak. Ez a funkció ezután kihasználja az IBM Cloud Satellite CLI-t a YAML alkalmazást tartalmazó konfigurációs verzió létrehozásához. Ennek van néhány hátránya: nem tudjuk használni a Helm által biztosított hasznos funkciókat, például a képességet rollback egy korábbi diagramverzióra, valamint az alkalmazás megfelelő működésének biztosítására elvégzendő tesztekre. Csereként azonban használhatjuk a Satellite visszagörgetési mechanizmust, és ennek a verziózását használhatjuk ennek alapjául.

Folyamatos megfelelőség

A CC folyamat fontos a telepített műtermékek és adattárak folyamatos vizsgálatához. Az érték itt az újonnan jelentett sebezhetőségek megtalálásában rejlik, amelyeket az alkalmazás telepítése után fedeztek fel. A sebezhetőségek legújabb definíciói olyan szervezetektől, mint pl Snyk és a CVE program ezeknek az új problémáknak a nyomon követésére szolgálnak. A CC eszközlánc statikus kódolvasót futtat a felhasználó által meghatározott időközönként az alkalmazás-lerakatokon, amelyek az alkalmazás forráskódjában található titkok és az alkalmazásfüggőségek sebezhetőségeinek észlelésére szolgálnak.

A folyamat a konténerképeket is átvizsgálja biztonsági réseket keresve. A vizsgálat során talált vagy frissített incidens problémákat esedékességi dátum jelzi. A bizonyítékok létrehozása és tárolása az IBM Cloud Object Storage-ban történik minden olyan futtatás végén, amely összefoglalja a vizsgálat részleteit.

DevOps Insights értékes a problémák és az alkalmazás általános biztonsági helyzetének nyomon követéséhez. Ez az eszköz tartalmazza a korábbi eszközlánc összes mérőszámát mindhárom rendszeren: folyamatos integráció, üzembe helyezés és megfelelőség. Minden szkennelés vagy teszt eredmény feltöltésre kerül a rendszerbe, és túlóra, megfigyelheti, hogyan fejlődik biztonsági testtartása.

A CC felhőkörnyezetben való beszerzése fontos a szigorúan szabályozott iparágak, például a pénzügyi szolgáltatások számára, amelyek meg akarják védeni az ügyfelek és az alkalmazások adatait. Korábban ez a folyamat nehéz volt, és kézzel kellett végrehajtani, ami veszélyezteti a szervezeteket. De azzal IBM Cloud Security and Compliance Center, napi, automatikus megfelelőségi ellenőrzéseket adhat hozzá fejlesztési életciklusához, hogy csökkentse ezt a kockázatot. Ezek az ellenőrzések magukban foglalják a DevSecOps eszközláncok különféle értékeléseit a biztonság és a megfelelőség biztosítása érdekében.

A projekttel és más hasonló projektekkel kapcsolatos tapasztalataink alapján bevált gyakorlatokat állítottunk össze, hogy segítsük a csapatokat hibrid felhőmegoldások megvalósításában az IBM Cloud for Financial Services és az IBM Cloud Satellite számára:

• Folyamatos integráció
  • Karbantartson közös szkriptkönyvtárat a különböző eszközláncokban lévő hasonló alkalmazásokhoz. Ez az utasításkészlet meghatározza, hogy a CI-eszközláncnak mit kell tennie. Például a NodeJS-alkalmazások összeállítási folyamata általában ugyanazt a struktúrát követi, ezért célszerű egy szkriptkönyvtárat külön tárolóban tartani, amelyre az eszközláncok hivatkozni fognak az alkalmazások felépítésekor. Ez lehetővé teszi a CI konzisztens megközelítését, elősegíti az újrahasználatot és javítja a karbantarthatóságot.
  • Alternatív megoldásként a CI-eszközláncok újra felhasználhatók hasonló alkalmazásokhoz triggerek használatával; ezek a külön triggerek használhatók annak meghatározására, hogy milyen alkalmazást kell készíteni, hol található az alkalmazás kódja és egyéb testreszabások.

• Folyamatos telepítés
  • Többkomponensű alkalmazások esetén egyetlen leltárt és így egyetlen telepítési eszközláncot tartson fenn a leltárban felsorolt ​​összes összetevő üzembe helyezéséhez. Ez megakadályozza a sok ismétlést. A Kubernetes YAML telepítési fájljainak mindegyike ugyanazzal a telepítési mechanizmussal rendelkezik, ezért logikusabb egy különálló eszközlánc, amely egymás után ismétlődik, mint több CD-eszközlánc fenntartása, amelyek lényegében ugyanazt végzik. A karbantarthatóság nőtt, és kevesebb a teendő az alkalmazás üzembe helyezéséhez. A triggerek továbbra is használhatók az egyes mikroszolgáltatások üzembe helyezésére, ha szükséges.
  • Használjon Helm diagramokat összetett többkomponensű alkalmazásokhoz. A Helm használata a BIAN projektben sokkal könnyebbé tette a telepítést. A Kubernetes-fájlok YAML-ben íródnak, és a bash-alapú szövegelemzők használata nehézkes, ha több értéket kell testreszabni a telepítés során. A Helm ezt leegyszerűsíti változók használatával, ami sokkal hatékonyabbá teszi az értékek helyettesítését. Ezen kívül a Helm egyéb szolgáltatásokat is kínál, például a teljes alkalmazás verziószámát, a diagramverziót, a telepítési konfigurációk nyilvántartási tárolását és a visszaállítási lehetőségeket hiba esetén. Bár a visszaállítás nem működik műhold-specifikus telepítéseknél, ezt a műholdkonfiguráció verziószámozása biztosítja.
• Folyamatos megfelelőség
  • Nyomatékosan javasoljuk, hogy az infrastruktúra részeként állítson be CC-eszközláncokat, amelyek segítségével folyamatosan ellenőrizheti a kódot és a műtermékeket az újonnan feltárt sebezhetőségek után. Ezeket a vizsgálatokat általában éjszaka vagy az alkalmazásának és a biztonsági helyzetnek megfelelő ütemezés szerint lehet futtatni. A problémák és az alkalmazás általános biztonsági helyzetének nyomon követéséhez javasoljuk a DevOps Insights használatát.
  • Azt is javasoljuk, hogy használja a Biztonsági és Megfelelőségi Központot (SCC) a biztonsági helyzet automatizálásához. A csővezetékek által generált bizonyíték-összefoglaló feltölthető az SCC-be, ahol a bizonyíték-összefoglaló minden bejegyzése egy eszközláncban elvégzett feladathoz kapcsolódó „tényként” kezelhető, legyen szó sebezhetőségi szkennelésről, egységtesztről vagy más hasonló dolgokról. . Az SCC ezután validációs teszteket futtat a bizonyítékok alapján annak megállapítására, hogy az eszközláncokkal kapcsolatos legjobb gyakorlatokat követik-e.
• Leltár
  • Ahogy korábban említettük, a folyamatos üzembe helyezés esetén előnyösebb egyetlen alkalmazásleltárt fenntartani, amelyben az összes mikroszolgáltatási adat tárolva lesz, valamint (ha nem Helm-et használ) Kubernetes telepítési fájlokat. Ez egyetlen igazságforrást tesz lehetővé a telepítések állapotával kapcsolatban; Mivel a készletben lévő ágak környezeteket képviselnek, ezeknek a környezeteknek a több készlettárban való karbantartása nagyon gyorsan nehézkessé válhat.
• Bizonyíték
  • A bizonyítéktárak megközelítését a leltártól eltérően kell kezelni. Ebben az esetben komponensenként egy bizonyítéktárat kell előnyben részesíteni; ha ezeket kombinálja, a tárolt bizonyítékok elsöprővé és nehezen kezelhetővé válhatnak. A konkrét bizonyítékok felkutatása sokkal hatékonyabb, ha a bizonyítékokat egy adott összetevőre jellemző adattárban tárolják. A telepítéshez egyetlen bizonyítéktároló elfogadható, mivel az egyetlen telepítési eszközláncból származik.
  • Határozottan javasoljuk, hogy a bizonyítékokat felhőobjektum-tárhelyben tárolja, valamint használja az alapértelmezett git-tárhely beállítást. Ennek az az oka, hogy egy COS-gyűjtődoboz változtathatatlanra konfigurálható, ami lehetővé teszi a bizonyítékok biztonságos tárolását a manipulálás lehetősége nélkül, ami nagyon fontos az ellenőrzési nyomvonalak esetében.        

Következtetés

Ebben a blogban bemutattuk a BIAN-alapú banki alkalmazás hibrid felhőn keresztüli megvalósításával kapcsolatos tapasztalatainkat, vagyis a DevSecOps folyamatok használatával a munkaterhelés IBM Cloud és Satellite környezetben történő telepítéséhez. Megvitattuk a különböző megközelítések előnyeit és hátrányait, valamint a projekt végrehajtása után levont bevált gyakorlatokat. Reméljük, hogy ez segíthet más csapatoknak abban, hogy nagyobb következetességgel és gyorsabban érjék el hibrid felhőútjukat. Ossza meg velünk gondolatait.

Fedezze fel, mit kínál ma az IBM