Bedste praksis for hybrid cloud banking-applikationer sikker og kompatibel implementering på tværs af IBM Cloud og Satellite – IBM Blog

Financial Services-kunder søger i stigende grad at modernisere deres applikationer. Dette omfatter modernisering af kodeudvikling og -vedligeholdelse (hjælper med knappe færdigheder og muliggør innovation og nye teknologier, der kræves af slutbrugere) samt forbedring af implementering og drift ved brug af agile teknikker og DevSecOps.

Som en del af deres moderniseringsrejse ønsker kunder at have fleksibilitet til at bestemme, hvad der er den bedste "egnet til formålet"-implementeringsplacering til deres applikationer. Dette kan være i ethvert af de miljøer, som Hybrid Cloud understøtter (i lokaler, på en privat sky, på en offentlig sky eller på kanten). IBM Cloud Satellite® opfylder dette krav ved at tillade moderne, cloud-native applikationer at køre hvor som helst, klienten har brug for, samtidig med at der opretholdes et standard og ensartet kontrolplan til administration af applikationer på tværs af hybridskyen.

Desuden understøtter mange af disse finansielle tjenester-applikationer regulerede arbejdsbelastninger, som kræver strenge niveauer af sikkerhed og overholdelse, herunder Zero Trust-beskyttelse af arbejdsbelastningerne. IBM Cloud for Financial Services opfylder dette krav ved at levere en end-to-end-sikkerheds- og overholdelsesramme, der kan bruges til at implementere og/eller modernisere applikationer sikkert på tværs af hybridskyen.

I dette papir viser vi, hvordan du nemt kan implementere en bankapplikation på begge IBM Cloud for Financial Services , Satellit, ved at bruge automatiserede CI/CD/CC-pipelines på en fælles og ensartet måde. Dette kræver et dybt niveau af sikkerhed og compliance gennem hele bygge- og implementeringsprocessen.

Introduktion til koncepter og produkter

Formålet med IBM Cloud for Financial Services er at levere sikkerhed og compliance for finansielle servicevirksomheder. Det gør det ved at udnytte industristandarder som NIST 800-53 og ekspertisen fra mere end hundrede finansielle servicekunder, som er en del af Financial Services Cloud Council. Det giver en kontrolramme, der let kan implementeres ved at bruge referencearkitekturer, validerede cloudtjenester og ISV'er, samt de højeste niveauer af kryptering og kontinuerlig overholdelse (CC) på tværs af hybridskyen.

IBM Cloud Satellite giver en ægte hybrid cloud-oplevelse. Satellit gør det muligt at køre arbejdsbelastninger hvor som helst uden at gå på kompromis med sikkerheden. En enkelt glasrude gør det nemt at se alle ressourcer i ét dashboard. For at implementere applikationer på disse forskellige miljøer har vi udviklet et sæt robuste DevSecOps-værktøjskæder til at bygge applikationer, implementere dem til en satellitplacering på en sikker og ensartet måde og overvåge miljøet ved hjælp af den bedste DevOps-praksis.

I dette projekt brugte vi en låneoprettelsesapplikation, der blev moderniseret til at bruge Kubernetes og mikrotjenester. For at levere denne service anvender bankapplikationen et økosystem af partnerapplikationer, der fungerer sammen ved hjælp af BIAN rammer.

Applikationsoversigt

Den applikation, der bruges i dette projekt, er en låneoprettelsesapplikation udviklet som en del af BIAN Coreless 2.0 initiativ. En kunde opnår et personligt lån gennem en sikker online kanal, som tilbydes af en bank. Applikationen anvender et økosystem af partnerapplikationer, der fungerer sammen på BIAN-arkitekturen, som er implementeret på IBM Cloud for Financial Services. BIAN Coreless Initiative giver finansielle institutioner mulighed for at vælge de bedste partnere for at hjælpe med at bringe nye tjenester på markedet hurtigt og effektivt gennem BIAN-arkitekturer. Hver komponent eller BIAN-tjenestedomæne implementeres gennem en mikrotjeneste, som er implementeret på en OCP-klynge på IBM Cloud.

Applikationskomponenter baseret på BIAN Service Domains

• Produktkatalog: Vedligeholder en omfattende oversigt over bankens produkter og tjenester.

• Forbrugslån: Håndterer opfyldelsen af ​​et forbrugslånsprodukt. Dette inkluderer den indledende opsætning af lånefaciliteten og færdiggørelsen af ​​planlagte og ad hoc produktbehandlingsopgaver.

• Kundetilbudsproces/API: Orkestrerer behandlingen af ​​et produkttilbud til en ny eller etableret kunde.

• Party Routing-profil: Vedligeholder en lille profil af nøgleindikatorer for en kunde, der refereres til under kundeinteraktioner for at lette beslutninger om routing, servicering og opfyldelse af produkter/tjenester.

Oversigt over implementeringsprocessen

En agil DevSecOps-workflow blev brugt til at fuldføre implementeringerne på tværs af hybridskyen. DevSecOps arbejdsgange fokuserer på en hyppig og pålidelig softwareleveringsproces. Metoden er iterativ snarere end lineær, hvilket gør det muligt for DevOps-teams at skrive kode, integrere den, køre test, levere udgivelser og implementere ændringer i samarbejde og i realtid, mens sikkerhed og compliance holdes i skak.

IBM Cloud for Financial Services-implementeringen blev opnået i en sikker landingszone-klynge, og infrastrukturimplementeringen er også automatiseret ved hjælp af politik som kode (terra form). Ansøgningen består af forskellige komponenter. Hver komponent blev implementeret ved hjælp af sin egen Kontinuerlig integration (CI), Kontinuerlig levering (CD) , Kontinuerlig overholdelse (CC) pipeline på en RedHat OpenShift Cluster. For at opnå udrulningen på satellit blev CI/CC-pipelines genbrugt, og en ny CD-pipeline blev oprettet.

Kontinuerlig integration

Hver komponent i IBM Cloud-implementeringen havde sin egen CI-pipeline. Et sæt anbefalede procedurer og tilgange er inkluderet i CI-værktøjskæden. En statisk kodescanner bruges til at inspicere applikationsarkivet for eventuelle hemmeligheder, der er gemt i applikationens kildekode, såvel som eventuelle sårbare pakker, der bruges som afhængigheder i applikationens kode. For hver Git-commit oprettes et containerbillede, og et tag tildeles billedet baseret på buildnummer, tidsstempel og commit-id. Dette tagging system sikrer billedets sporbarhed. Inden billedet oprettes, testes Dockerfilen. Det oprettede billede gemmes i en privat billedregistrering. Adgangsrettighederne for målklynge-implementeringen konfigureres automatisk ved hjælp af API-tokens, som kan tilbagekaldes. En sikkerhedssårbarhedsscanning udføres på containerbilledet. En Docker-signatur påføres ved vellykket gennemførelse. Tilføjelsen af ​​det oprettede billedtag opdaterer implementeringsposten øjeblikkeligt. Brugen af ​​et eksplicit navneområde i en klynge tjener det formål at isolere hver implementering. Enhver kode, der er flettet ind i den specificerede gren af ​​Git-lageret, udtrykkeligt til udrulning på Kubernetes-klyngen, konstrueres, verificeres og implementeres automatisk.

Detaljer om hvert docker-billede er gemt i et lageropbevaring, som er forklaret i detaljer i afsnittet Kontinuerlig Deployering af denne blog. Derudover indsamles beviser gennem hver rørledningskørsel. Denne dokumentation beskriver, hvilke opgaver der blev udført i værktøjskæden, såsom sårbarhedsscanninger og enhedstests. Dette bevis er gemt i et git-lager og en sky-objekt-opbevaringsbøtte, så det kan revideres, hvis det er nødvendigt.

Vi genbrugte de nuværende CI-værktøjskæder, der blev brugt til IBM Cloud-implementeringen, der er angivet ovenfor, til satellit-implementeringen. Da applikationen forblev uændret, var det unødvendigt at genopbygge CI-pipelines til den nye implementering.

Kontinuerlig implementering

Opgørelsen tjener som kilden til sandhed om, hvilke artefakter der er udplaceret i hvilket miljø/region; dette opnås ved at bruge git-grene til at repræsentere miljøer, med en promoveringspipeline, der opdaterer miljøer i en GitOps-baseret tilgang. I tidligere implementeringer var inventaret også vært for implementeringsfiler; disse er YAML Kubernetes-ressourcefilerne, der beskriver hver komponent. Disse installationsfiler vil blive opdateret med de korrekte navneområdebeskrivelser sammen med den nyeste version af Docker-billedet for hver komponent.

Men vi fandt denne tilgang vanskelig af et par grunde. Fra applikationernes perspektiv var det groft og kompliceret at skulle ændre så mange billedtagværdier og navneområder ved hjælp af YAML-erstatningsværktøjer (såsom YQ). For selve Satelliten bruger vi den direkte upload-strategi, hvor hver YAML-fil, der leveres, tæller som en "version". Vi foretrækker, at en version svarer til hele applikationen, ikke kun én komponent eller mikrotjeneste.

En anden tilgang var ønsket, så vi ombyggede implementeringsprocessen til at bruge et Helm-diagram i stedet. Dette gjorde det muligt for os at parametrisere de vigtige værdier, såsom navnerum og billedmærker, og injicere dem på implementeringstidspunktet. Brug af disse variabler fjerner meget af vanskeligheden forbundet med at parse YAML-filer for en given værdi. Rordiagrammet blev oprettet separat og gemt i det samme containerregister som de indbyggede BIAN-billeder. Vi arbejder i øjeblikket på at udvikle en specifik CI-pipeline til validering af rordiagrammer; dette vil fnug kortet, pakke det, underskrive det for rigtighed (dette vil blive bekræftet ved implementeringstidspunktet) og gemme kortet. Indtil videre udføres disse trin manuelt for at udvikle diagrammet. Der er et problem med at bruge rordiagrammer og satellitkonfigurationer sammen: rorfunktionalitet kræver en direkte forbindelse med en Kubernetes- eller OpenShift-klynge for at fungere mest effektivt, og det vil Satellit selvfølgelig ikke tillade. Så for at løse dette problem bruger vi "hjelmskabelonen" til at udlæse det korrekt formaterede diagram og derefter sende den resulterende YAML-fil til satellit-uploadfunktionen. Denne funktion udnytter derefter IBM Cloud Satellite CLI til at skabe en konfigurationsversion, der indeholder applikationen YAML. Der er nogle ulemper her: vi kan ikke bruge nogle nyttige funktioner, som Helm giver, såsom evnen til at rollback til en tidligere diagramversion og de test, der kan udføres for at sikre, at applikationen fungerer korrekt. Vi kan dog bruge Satellite rollback-mekanismen som en erstatning og bruge dens versionering som grundlag for dette.

Kontinuerlig overholdelse

CC-pipelinen er vigtig for kontinuerlig scanning af installerede artefakter og depoter. Værdien her er at finde nyligt rapporterede sårbarheder, der kan være blevet opdaget, efter at applikationen er blevet implementeret. De seneste definitioner af sårbarheder fra organisationer som f.eks SNYK og CVE-program bruges til at spore disse nye problemer. CC-værktøjskæden kører en statisk kodescanner med brugerdefinerede intervaller på applikationslagrene, der er tilvejebragt for at opdage hemmeligheder i applikationens kildekode og sårbarheder i applikationsafhængigheder.

Pipelinen scanner også containerbilleder for sikkerhedssårbarheder. Ethvert hændelsesproblem, der findes under scanningen eller opdateres, er markeret med en forfaldsdato. Beviser oprettes og gemmes i IBM Cloud Object Storage i slutningen af ​​hver kørsel, der opsummerer detaljerne i scanningen.

DevOps Insights er værdifuld for at holde styr på problemer og den overordnede sikkerhedsposition for din ansøgning. Dette værktøj indeholder alle metrics fra tidligere værktøjskæder på tværs af alle tre systemer: kontinuerlig integration, implementering og compliance. Ethvert scannings- eller testresultat uploades til det system, og over tid, kan du observere, hvordan din sikkerhedsstilling udvikler sig.

At få CC i et cloudmiljø er vigtigt for stærkt regulerede industrier som finansielle tjenester, der ønsker at beskytte kunde- og applikationsdata. Tidligere var denne proces hård og skulle udføres i hånden, hvilket sætter organisationer i fare. Men med IBM Cloud Security and Compliance Center, kan du tilføje daglige, automatiske overholdelsestjek til din udviklingslivscyklus for at hjælpe med at reducere denne risiko. Disse kontroller omfatter forskellige vurderinger af DevSecOps værktøjskæder for at sikre sikkerhed og overholdelse.

Baseret på vores erfaring med dette projekt og andre lignende projekter, skabte vi et sæt bedste praksisser for at hjælpe teams med at implementere hybride cloud-løsninger til IBM Cloud for Financial Services og IBM Cloud Satellite:

• Kontinuerlig integration
  • Vedligehold et fælles scriptbibliotek til lignende applikationer i forskellige værktøjskæder. Dette er det sæt instruktioner, der bestemmer, hvad din CI-værktøjskæde skal gøre. For eksempel vil byggeprocessen for NodeJS-applikationer generelt følge den samme struktur, så det giver mening at opbevare et script-bibliotek i et separat lager, som værktøjskæderne vil referere til, når de bygger applikationer. Dette giver mulighed for en konsekvent tilgang til CI, fremmer genbrug og øger vedligeholdelsesevnen.
  • Alternativt kan CI-værktøjskæder genbruges til lignende applikationer med brug af triggere; disse separate triggere kan bruges til at specificere hvilken applikation der skal bygges, hvor koden til applikationen er og andre tilpasninger.

• Kontinuerlig implementering
  • For multikomponentapplikationer skal du vedligeholde en enkelt beholdning og dermed en enkelt implementeringsværktøjskæde for at implementere alle komponenter, der er angivet i beholdningen. Dette forhindrer mange gentagelser. Kubernetes YAML-implementeringsfiler har alle den samme implementeringsmekanisme, så en enkelt værktøjskæde, der gentages over hver efter tur, er mere logisk end at vedligeholde flere cd-værktøjskæder, som alle i det væsentlige gør det samme. Vedligeholdelsen er øget, og der er mindre arbejde at gøre for at implementere applikationen. Triggere kan stadig bruges til at implementere individuelle mikrotjenester, hvis det ønskes.
  • Brug Helm-diagrammer til komplekse multi-komponent applikationer. Brugen af ​​Helm i BIAN-projektet gjorde implementeringen meget lettere. Kubernetes-filer er skrevet i YAML, og det er besværligt at bruge bash-baserede tekstparsere, hvis flere værdier skal tilpasses på implementeringstidspunktet. Helm forenkler dette ved at bruge variabler, hvilket gør substitution af værdier meget mere effektiv. Derudover tilbyder Helm andre funktioner, såsom versionering af hele applikationen, diagramversionering, registreringsdatabasen for implementeringskonfiguration og rollback-funktioner i tilfælde af fejl. Selvom tilbagerulning ikke virker på satellitspecifikke implementeringer, er dette imødekommet af satellitkonfigurationsversionering.
• Kontinuerlig overholdelse
  • Vi anbefaler kraftigt, at du opsætter CC-værktøjskæder som en del af din infrastruktur for løbende at scanne kode og artefakter for sårbarheder, der er blevet blotlagt for nylig. Typisk kan disse scanninger køres om natten eller på den tidsplan, der passer til din applikation og sikkerhedssituation. For at holde styr på problemer og den overordnede sikkerhedsposition for din applikation, foreslår vi, at du bruger DevOps Insights.
  • Vi anbefaler også brugen af ​​Security and Compliance Center (SCC) til at automatisere din sikkerhedsposition. Evidensresuméet, der genereres af pipelines, kan uploades til SCC, hvor hver indtastning i bevisresuméet behandles som en "kendsgerning" relateret til en opgave udført i en værktøjskæde, det være sig en sårbarhedsscanning, enhedstest eller andet lignende. . SCC vil derefter køre valideringstests mod beviserne for at fastslå, at bedste praksis relateret til værktøjskæder bliver fulgt.
• Inventory
  • Som tidligere nævnt, med kontinuerlig udrulning, er det at foretrække at opretholde en enkelt applikationsopgørelse, hvor alle dine mikroservicedetaljer vil blive gemt sammen med (hvis du ikke bruger Helm) Kubernetes-implementeringsfiler. Dette giver mulighed for en enkelt kilde til sandhed vedrørende tilstanden af ​​dine implementeringer; da grene i dit lager repræsenterer miljøer, kan det blive besværligt meget hurtigt at vedligeholde disse miljøer på tværs af flere lagerbeholdninger.
• Beviser
  • Tilgangen til bevisopbevaring bør behandles anderledes end opgørelsen. I dette tilfælde er ét bevislager pr. komponent at foretrække; hvis du kombinerer dem, kan de lagrede beviser blive overvældende og svære at håndtere. Lokalisering af specifikke beviser er meget mere effektivt, hvis beviserne er gemt i et depot specifikt for en komponent. Til implementering er et enkelt bevisskab acceptabelt, da det er hentet fra en enkelt implementeringsværktøjskæde.
  • Vi anbefaler på det kraftigste at gemme beviser i en sky-objekt-opbevaringsspand samt at bruge standardindstillingen for git-lager. Dette skyldes, at en COS-spand kan konfigureres til at være uforanderlig, hvilket giver os mulighed for sikkert at opbevare beviserne uden mulighed for manipulation, hvilket er meget vigtigt i tilfælde af revisionsspor.        

Konklusion

I denne blog viste vi vores erfaring med at implementere en bankapplikation baseret på BIAN på tværs af hybridskyen, det vil sige at bruge DevSecOps-pipelines til at implementere arbejdsbyrden både på IBM Cloud såvel som i et satellitmiljø. Vi diskuterede fordele og ulemper ved forskellige tilgange og den bedste praksis, vi udledte efter at have gennemgået dette projekt. Vi håber, at dette kan hjælpe andre teams med at opnå deres hybrid cloud-rejse med mere konsistens og hastighed. Fortæl os dine tanker.

Udforsk, hvad IBM har at tilbyde i dag