Beste praksis for hybrid skybankapplikasjoner sikker og kompatibel distribusjon på tvers av IBM Cloud og Satellite – IBM Blog

Financial Services-kunder søker i økende grad etter å modernisere applikasjonene sine. Dette inkluderer modernisering av kodeutvikling og vedlikehold (hjelper med knappe ferdigheter og tillater innovasjon og nye teknologier som kreves av sluttbrukere) samt forbedring av distribusjon og drift ved bruk av smidige teknikker og DevSecOps.

Som en del av moderniseringsreisen deres, ønsker klienter å ha fleksibilitet til å finne ut hva som er det beste "egnet for formålet"-distribusjonsstedet for applikasjonene deres. Dette kan være i alle miljøene som Hybrid Cloud støtter (i lokaler, på en privat sky, på en offentlig sky eller på kanten). IBM Cloud Satellite® oppfyller dette kravet ved å la moderne, skybaserte applikasjoner kjøre hvor som helst klienten krever, samtidig som det opprettholdes et standard og konsistent kontrollplan for administrasjon av applikasjoner på tvers av hybridskyen.

Dessuten støtter mange av disse finansielle tjenesteapplikasjonene regulerte arbeidsbelastninger, som krever strenge nivåer av sikkerhet og samsvar, inkludert Zero Trust-beskyttelse av arbeidsbelastningene. IBM Cloud for Financial Services oppfyller dette kravet ved å tilby et ende-til-ende sikkerhets- og samsvarsrammeverk som kan brukes til å implementere og/eller modernisere applikasjoner på en sikker måte på tvers av hybridskyen.

I denne artikkelen viser vi hvordan du enkelt kan distribuere en bankapplikasjon på begge IBM Cloud for Financial Services og Satellite, ved å bruke automatiserte CI/CD/CC-rørledninger på en felles og konsistent måte. Dette krever et dypt nivå av sikkerhet og samsvar gjennom hele bygge- og distribusjonsprosessen.

Introduksjon til konsepter og produkter

Formålet med IBM Cloud for Financial Services er å tilby sikkerhet og samsvar for finansielle tjenesteselskaper. Det gjør det ved å utnytte industristandarder som NIST 800-53 og ekspertisen til mer enn hundre finansielle tjenestekunder som er en del av Financial Services Cloud Council. Det gir et kontrollrammeverk som enkelt kan implementeres ved å bruke referansearkitekturer, validerte skytjenester og ISV-er, samt de høyeste nivåene av kryptering og kontinuerlig overholdelse (CC) på tvers av hybridskyen.

IBM Cloud Satellite gir en ekte hybrid skyopplevelse. Satellitt lar arbeidsbelastninger kjøres hvor som helst uten at det går på bekostning av sikkerheten. En enkelt glassrute gjør det enkelt å se alle ressursene i ett dashbord. For å distribuere applikasjoner på disse forskjellige miljøene, har vi utviklet et sett med robuste DevSecOps-verktøykjeder for å bygge applikasjoner, distribuere dem til en satellittposisjon på en sikker og konsistent måte og overvåke miljøet ved å bruke de beste DevOps-praksisene.

I dette prosjektet brukte vi en låneopprinnelsesapplikasjon som ble modernisert for å bruke Kubernetes og mikrotjenester. For å levere denne tjenesten bruker bankapplikasjonen et økosystem av partnerapplikasjoner som samvirker ved hjelp av BIAN rammeverk.

Søknadsoversikt

Applikasjonen som brukes i dette prosjektet er en låneopprinnelsesapplikasjon utviklet som en del av BIAN kjerneløs 2.0 initiativ. En kunde får et personlig lån gjennom en trygg og sikker nettkanal som tilbys av en bank. Applikasjonen bruker et økosystem av partnerapplikasjoner som fungerer sammen på BIAN-arkitekturen, som er distribuert på IBM Cloud for Financial Services. BIAN Coreless Initiative gir finansinstitusjoner mulighet til å velge de beste partnerne for å bidra til å bringe nye tjenester til markedet raskt og effektivt gjennom BIAN-arkitekturer. Hver komponent eller BIAN-tjenestedomene implementeres gjennom en mikrotjeneste, som er distribuert på en OCP-klynge på IBM Cloud.

Applikasjonskomponenter basert på BIAN Service Domains

• Produktkatalog: Opprettholder en omfattende katalog over bankens produkter og tjenester.

• Forbrukslån: Håndterer oppfyllelsen av et forbrukslånsprodukt. Dette inkluderer det første oppsettet av lånefasiliteten og fullføringen av planlagte og ad-hoc produktbehandlingsoppgaver.

• Kundetilbudsprosess/API: Orkestrerer behandlingen av et produkttilbud for en ny eller etablert kunde.

• Party Routing Profile: Opprettholder en liten profil med nøkkelindikatorer for en kunde som det refereres til under kundeinteraksjoner for å lette beslutninger om ruting, service og produkt-/tjenesteoppfyllelse.

Oversikt over distribusjonsprosessen

En smidig DevSecOps-arbeidsflyt ble brukt for å fullføre distribusjonene på tvers av hybridskyen. DevSecOps arbeidsflyter fokuserer på en hyppig og pålitelig programvareleveringsprosess. Metodikken er iterativ snarere enn lineær, noe som lar DevOps-teamene skrive kode, integrere den, kjøre tester, levere utgivelser og distribuere endringer i samarbeid og i sanntid, samtidig som sikkerhet og samsvar i sjakk.

IBM Cloud for Financial Services-distribusjonen ble oppnådd i en sikker landingssoneklynge, og infrastrukturdistribusjon er også automatisert ved å bruke policy som kode (terra). Applikasjonen består av ulike komponenter. Hver komponent ble distribuert med sin egen Kontinuerlig integrasjon (CI), Kontinuerlig levering (CD) og Kontinuerlig overholdelse (CC) pipeline på en RedHat OpenShift Cluster. For å oppnå utplasseringen på satellitt ble CI/CC-rørledningene gjenbrukt, og en ny CD-rørledning ble opprettet.

Kontinuerlig integrasjon

Hver komponent i IBM Cloud-distribusjonen hadde sin egen CI-pipeline. Et sett med anbefalte prosedyrer og tilnærminger er inkludert i CI-verktøykjeden. En statisk kodeskanner brukes til å inspisere applikasjonslageret for eventuelle hemmeligheter som er lagret i applikasjonens kildekode, samt eventuelle sårbare pakker som brukes som avhengigheter i applikasjonens kode. For hver Git-forpliktelse opprettes et beholderbilde, og en tagg tilordnes bildet basert på byggenummer, tidsstempel og forpliktelses-ID. Dette taggesystemet sikrer bildets sporbarhet. Før bildet lages, testes Dockerfilen. Det opprettede bildet lagres i et privat bilderegister. Tilgangsrettighetene for målklyngedistribusjonen konfigureres automatisk ved hjelp av API-tokens, som kan trekkes tilbake. En sikkerhetssårbarhetsskanning utføres på beholderbildet. En Docker-signatur påføres ved vellykket gjennomføring. Tillegget av den opprettede bildekoden oppdaterer distribusjonsposten umiddelbart. Bruken av et eksplisitt navneområde i en klynge tjener formålet med å isolere hver distribusjon. Enhver kode som er slått sammen til den spesifiserte grenen av Git-depotet, eksplisitt for distribusjon på Kubernetes-klyngen, blir automatisk konstruert, verifisert og implementert.

Detaljer om hvert docker-bilde lagres i et inventarlager, som er forklart i detalj i delen for kontinuerlig distribusjon av denne bloggen. I tillegg samles bevis gjennom hvert rørledningsløp. Dette beviset beskriver hvilke oppgaver som ble utført i verktøykjeden, for eksempel sårbarhetsskanninger og enhetstester. Dette beviset er lagret i et git-lager og en skyobjektlagringsbøtte, slik at det kan revideres om nødvendig.

Vi gjenbrukte de nåværende CI-verktøykjedene som ble brukt for IBM Cloud-distribusjonen som er angitt ovenfor for satellitt-distribusjonen. Fordi applikasjonen forble uendret, var det unødvendig å gjenoppbygge CI-rørledningene for den nye distribusjonen.

Kontinuerlig distribusjon

Inventaret fungerer som kilden til sannhet om hvilke artefakter som er utplassert i hvilket miljø/region; dette oppnås ved å bruke git-grener for å representere miljøer, med en promoteringspipeline som oppdaterer miljøer i en GitOps-basert tilnærming. I tidligere distribusjoner var inventaret også vert for distribusjonsfiler; dette er YAML Kubernetes-ressursfilene som beskriver hver komponent. Disse distribusjonsfilene vil bli oppdatert med de riktige navneområdebeskrivelsene, sammen med den nyeste versjonen av Docker-bildet for hver komponent.

Vi fant imidlertid denne tilnærmingen vanskelig av flere grunner. Fra applikasjonens perspektiv var det grovt og komplisert å måtte endre så mange bildekodeverdier og navneområder ved å bruke YAML-erstatningsverktøy (som YQ). For selve satellitten bruker vi den direkte opplastingsstrategien, der hver YAML-fil som leveres teller som en "versjon". Vi foretrekker å ha en versjon som samsvarer med hele applikasjonen, ikke bare én komponent eller mikrotjeneste.

En annen tilnærming var ønsket, så vi redesignet distribusjonsprosessen til å bruke et Helm-diagram i stedet. Dette tillot oss å parametrisere de viktige verdiene, for eksempel navneområder og bildekoder, og injisere dem ved utrulling. Å bruke disse variablene tar bort mye av vanskeligheten forbundet med å analysere YAML-filer for en gitt verdi. Rordiagrammet ble opprettet separat og lagret i samme beholderregister som de bygde BIAN-bildene. Vi jobber for tiden med å utvikle en spesifikk CI-pipeline for validering av rorkart; dette vil line diagrammet, pakke det, signere det for sannhet (dette vil bli bekreftet ved utrullingstidspunktet) og lagre diagrammet. Foreløpig gjøres disse trinnene manuelt for å utvikle diagrammet. Det er ett problem med å bruke rorkart og satellittkonfigurasjoner sammen: rorfunksjonalitet krever en direkte forbindelse med en Kubernetes- eller OpenShift-klynge for å fungere mest effektivt, og satellitt vil selvfølgelig ikke tillate det. Så, for å løse dette problemet, bruker vi "styrmalen" for å sende ut det riktig formaterte diagrammet og deretter sende den resulterende YAML-filen til satellittopplastingsfunksjonen. Denne funksjonen utnytter deretter IBM Cloud Satellite CLI for å lage en konfigurasjonsversjon som inneholder applikasjonen YAML. Det er noen ulemper her: vi kan ikke bruke noen nyttige funksjoner som Helm gir, for eksempel muligheten til rollback til en tidligere kartversjon og testene som kan gjøres for å sikre at applikasjonen fungerer som den skal. Vi kan imidlertid bruke Satellite rollback-mekanismen som en erstatning og bruke versjoneringen som grunnlag for dette.

Kontinuerlig etterlevelse

CC-rørledningen er viktig for kontinuerlig skanning av utplasserte artefakter og depoter. Verdien her er å finne nylig rapporterte sårbarheter som kan ha blitt oppdaget etter at applikasjonen har blitt distribuert. De siste definisjonene av sårbarheter fra organisasjoner som f.eks Snyk og CVE-program brukes til å spore disse nye problemene. CC-verktøykjeden kjører en statisk kodeskanner med brukerdefinerte intervaller på applikasjonslagrene som er gitt for å oppdage hemmeligheter i applikasjonens kildekode og sårbarheter i applikasjonsavhengigheter.

Rørledningen skanner også containerbilder for sikkerhetssårbarheter. Ethvert hendelsesproblem som oppdages under skanningen eller oppdateres, er merket med en forfallsdato. Bevis opprettes og lagres i IBM Cloud Object Storage på slutten av hver kjøring som oppsummerer detaljene i skanningen.

DevOps Insights er verdifull for å holde styr på problemer og den generelle sikkerhetsstillingen til applikasjonen din. Dette verktøyet inneholder alle beregningene fra tidligere verktøykjedekjøringer på tvers av alle tre systemene: kontinuerlig integrasjon, distribusjon og overholdelse. Ethvert skannings- eller testresultat lastes opp til det systemet, og over tid, kan du observere hvordan sikkerhetsstillingen din utvikler seg.

Å få CC i et skymiljø er viktig for sterkt regulerte bransjer som finansielle tjenester som ønsker å beskytte kunde- og applikasjonsdata. Tidligere var denne prosessen vanskelig og måtte gjøres for hånd, noe som setter organisasjoner i fare. Men med IBM Cloud Security and Compliance Center, kan du legge til daglige, automatiske samsvarskontroller til utviklingslivssyklusen din for å redusere denne risikoen. Disse kontrollene inkluderer ulike vurderinger av DevSecOps-verktøykjeder for å sikre sikkerhet og samsvar.

Basert på vår erfaring med dette prosjektet og andre lignende prosjekter, har vi laget et sett med beste praksis for å hjelpe team med å implementere hybride skyløsninger for IBM Cloud for Financial Services og IBM Cloud Satellite:

• Kontinuerlig integrasjon
  • Oppretthold et felles skriptbibliotek for lignende applikasjoner i forskjellige verktøykjeder. Dette er settet med instruksjoner som bestemmer hva CI-verktøykjeden din skal gjøre. For eksempel vil byggeprosessen for NodeJS-applikasjoner generelt følge samme struktur, så det er fornuftig å holde et skriptbibliotek i et eget depot, som verktøykjedene vil referere til når de bygger applikasjoner. Dette åpner for en konsistent tilnærming til CI, fremmer gjenbruk og øker vedlikeholdsevnen.
  • Alternativt kan CI-verktøykjeder gjenbrukes til lignende applikasjoner med bruk av triggere; disse separate triggerne kan brukes til å spesifisere hvilken applikasjon som skal bygges, hvor koden for applikasjonen er og andre tilpasninger.

• Kontinuerlig distribusjon
  • For flerkomponentapplikasjoner, vedlikehold en enkelt beholdning og dermed en enkelt distribusjonsverktøykjede for å distribuere alle komponentene som er oppført i beholdningen. Dette forhindrer mye gjentakelse. Kubernetes YAML-distribusjonsfiler har alle den samme distribusjonsmekanismen, så en enkeltstående verktøykjede som gjentar hver av dem er mer logisk enn å opprettholde flere CD-verktøykjeder, som alle i hovedsak gjør det samme. Vedlikeholdsevnen har økt, og det er mindre arbeid å gjøre for å distribuere applikasjonen. Utløsere kan fortsatt brukes til å distribuere individuelle mikrotjenester, hvis ønskelig.
  • Bruk Helm-diagrammer for komplekse flerkomponentapplikasjoner. Bruken av Helm i BIAN-prosjektet gjorde distribusjonen mye enklere. Kubernetes-filer er skrevet i YAML, og bruk av bash-baserte tekstparsere er tungvint hvis flere verdier må tilpasses ved distribusjon. Helm forenkler dette ved å bruke variabler, noe som gjør substitusjon av verdier mye mer effektivt. I tillegg tilbyr Helm andre funksjoner, for eksempel versjonering av hele applikasjonen, diagramversjon, registerlagring av distribusjonskonfigurasjon og tilbakerullingsmuligheter i tilfelle feil. Selv om tilbakerulling ikke vil fungere på satellittspesifikke distribusjoner, er dette ivaretatt av satellittkonfigurasjonsversjon.
• Kontinuerlig etterlevelse
  • Vi anbefaler på det sterkeste å sette opp CC-verktøykjeder som en del av infrastrukturen din for å kontinuerlig skanne kode og artefakter for sårbarheter som nylig er avslørt. Vanligvis kan disse skanningene kjøres nattlig eller etter hvilken tidsplan som passer din applikasjon og sikkerhetssituasjon. For å holde oversikt over problemer og den generelle sikkerhetsposisjonen til applikasjonen din, foreslår vi at du bruker DevOps Insights.
  • Vi anbefaler også bruk av Security and Compliance Center (SCC) for å automatisere sikkerhetsstillingen din. Bevissammendraget generert av rørledningene kan lastes opp til SCC, hvor hver oppføring i bevissammendraget behandles som et "fakta" knyttet til en oppgave utført i en verktøykjede, det være seg en sårbarhetsskanning, enhetstest eller andre ting. . SCC vil deretter kjøre valideringstester mot bevis for å fastslå at beste praksis knyttet til verktøykjeder blir fulgt.
• Varelager
  • Som tidligere nevnt, med kontinuerlig distribusjon, er det å foretrekke å opprettholde en enkelt applikasjonsbeholdning der alle mikrotjenestedetaljene dine vil bli lagret, sammen med (hvis du ikke bruker Helm) Kubernetes-distribusjonsfiler. Dette tillater én enkelt kilde til sannhet angående tilstanden til distribusjonene dine; Siden grener i inventaret ditt representerer miljøer, kan vedlikehold av disse miljøene på tvers av flere inventarlagre bli tungvint veldig raskt.
• bevis
  • Tilnærmingen til bevislager bør behandles annerledes enn inventaret. I dette tilfellet er ett bevislager per komponent å foretrekke; hvis du kombinerer dem, kan de lagrede bevisene bli overveldende og vanskelige å håndtere. Å finne spesifikke bevis er mye mer effektivt hvis bevisene er lagret i et depot spesifikt for en komponent. For distribusjon er et enkelt bevisskap akseptabelt, siden det er hentet fra en enkelt distribusjonsverktøykjede.
  • Vi anbefaler på det sterkeste å lagre bevis i en sky-objektlagringsbøtte i tillegg til å bruke standard git-repository-alternativet. Dette er fordi en COS-bøtte kan konfigureres til å være uforanderlig, noe som gjør at vi kan lagre bevisene på en sikker måte uten mulighet for tukling, noe som er veldig viktig i tilfelle av revisjonsspor.        

konklusjonen

I denne bloggen viste vi frem vår erfaring med å implementere en bankapplikasjon basert på BIAN på tvers av hybridskyen, det vil si å bruke DevSecOps-rørledninger for å distribuere arbeidsmengden både på IBM Cloud så vel som i et satellittmiljø. Vi diskuterte fordeler og ulemper med ulike tilnærminger og den beste praksisen vi utledet etter å ha gått gjennom dette prosjektet. Vi håper dette kan hjelpe andre team med å oppnå sin hybride skyreise med mer konsistens og hastighet. Gi oss beskjed om dine tanker.

Utforsk hva IBM har å tilby i dag