Best practices voor veilige en conforme implementatie van hybride cloud-bankingapplicaties in IBM Cloud en Satellite – IBM Blog

Klanten uit de financiële dienstverlening willen steeds vaker hun applicaties moderniseren. Dit omvat modernisering van de ontwikkeling en het onderhoud van code (helpen met schaarse vaardigheden en het mogelijk maken van innovatie en nieuwe technologieën die eindgebruikers nodig hebben), evenals verbetering van de implementatie en operaties, met behulp van flexibele technieken en DevSecOps.

Als onderdeel van hun moderniseringstraject willen klanten de flexibiliteit hebben om te bepalen wat de beste ‘fit for purpose’ implementatielocatie voor hun applicaties is. Dit kan in elke omgeving zijn die Hybrid Cloud ondersteunt (on-premises, in een private cloud, in een publieke cloud of aan de edge). IBM Cloud Satellite® voldoet aan deze eis door moderne, cloud-native applicaties overal te laten draaien waar de klant dat nodig heeft, terwijl een standaard en consistent controlevlak behouden blijft voor het beheer van applicaties in de hybride cloud.

Bovendien ondersteunen veel van deze toepassingen voor financiële diensten gereguleerde werklasten, die strikte niveaus van beveiliging en compliance vereisen, inclusief Zero Trust-bescherming van de werklasten. IBM Cloud for Financial Services voldoet aan deze eis door een end-to-end beveiligings- en compliance-framework te bieden dat kan worden gebruikt om applicaties veilig in de hybride cloud te implementeren en/of te moderniseren.

In dit artikel laten we zien hoe u eenvoudig een bankapplicatie op beide kunt implementeren IBM Cloud voor financiële diensten en Satelliet, waarbij op een gemeenschappelijke en consistente manier gebruik wordt gemaakt van geautomatiseerde CI/CD/CC-pijplijnen. Dit vereist een hoog niveau van beveiliging en compliance gedurende het gehele bouw- en implementatieproces.

Introductie van concepten en producten

Het doel van IBM Cloud for Financial Services is het bieden van beveiliging en compliance voor financiële dienstverleners. Dit gebeurt door gebruik te maken van industriestandaarden zoals NIST 800-53 en de expertise van ruim honderd financiële dienstverleners die deel uitmaken van de Financial Services Cloud Council. Het biedt een controleframework dat eenvoudig kan worden geïmplementeerd door gebruik te maken van referentiearchitecturen, gevalideerde cloudservices en ISV's, evenals de hoogste niveaus van versleuteling en continue compliance (CC) in de hybride cloud.

IBM Cloud Satellite biedt een echte hybride cloudervaring. Dankzij Satellite kunnen workloads overal worden uitgevoerd zonder dat dit ten koste gaat van de veiligheid. Eén enkel glasvenster biedt het gemak om alle bronnen in één dashboard te zien. Om applicaties in deze uiteenlopende omgevingen te implementeren, hebben we een reeks robuuste DevSecOps-toolchains ontwikkeld om applicaties te bouwen, deze op een veilige en consistente manier op een satellietlocatie te implementeren en de omgeving te monitoren met behulp van de beste DevOps-praktijken.

In dit project hebben we een applicatie voor het genereren van leningen gebruikt die is gemoderniseerd om Kubernetes en microservices te gebruiken. Om deze dienst te leveren, maakt de bankapplicatie gebruik van een ecosysteem van partnerapplicaties die samenwerken met behulp van de BIAN kader.

Toepassingsoverzicht

De applicatie die in dit project wordt gebruikt, is een leningaanvraag die is ontwikkeld als onderdeel van de BIAN Kernloos 2.0 initiatief. Een klant krijgt een gepersonaliseerde lening via een veilig online kanaal aangeboden door een bank. De applicatie maakt gebruik van een ecosysteem van partnerapplicaties die samenwerken op de BIAN-architectuur, die wordt ingezet op de IBM Cloud for Financial Services. BIAN Coreless Initiative stelt financiële instellingen in staat de beste partners te selecteren om nieuwe diensten snel en efficiënt op de markt te brengen via BIAN-architecturen. Elke component of BIAN Service Domain wordt geïmplementeerd via een microservice, die wordt geïmplementeerd op een OCP-cluster op IBM Cloud.

Applicatiecomponenten gebaseerd op BIAN Servicedomeinen

• Productgids: Onderhoudt een uitgebreid overzicht van de producten en diensten van de bank.

• Consumentenlening: Verzorgt de uitvoering van een consumentenleningproduct. Dit omvat de initiële opzet van de leningsfaciliteit en de voltooiing van geplande en ad-hoc productverwerkingstaken.

• Klantaanbiedingsproces/API: Organiseert de verwerking van een productaanbod voor een nieuwe of gevestigde klant.

• Profiel voor partijroutering: Onderhoudt een klein profiel van sleutelindicatoren voor een klant waarnaar wordt verwezen tijdens klantinteracties om routerings-, service- en product-/dienstvervullingsbeslissingen te vergemakkelijken.

Overzicht van het implementatieproces

Er werd gebruik gemaakt van een flexibele DevSecOps-workflow om de implementaties in de hybride cloud te voltooien. DevSecOps-workflows zijn gericht op een frequent en betrouwbaar softwareleveringsproces. De methodologie is iteratief in plaats van lineair, waardoor DevOps-teams code kunnen schrijven, integreren, testen kunnen uitvoeren, releases kunnen leveren en veranderingen gezamenlijk en in realtime kunnen implementeren, terwijl de beveiliging en compliance onder controle blijven.

De implementatie van IBM Cloud for Financial Services vond plaats in een beveiligd landingszonecluster, en de implementatie van de infrastructuur is ook geautomatiseerd met behulp van beleid als code (terraform). De applicatie bestaat uit verschillende componenten. Elke component werd ingezet met behulp van zijn eigen component Continue integratie (CI), Continue levering (CD) en Continue naleving (CC) pijplijn op een RedHat OpenShift Cluster. Om de implementatie op Satellite te realiseren, werden de CI/CC-pijpleidingen hergebruikt en werd een nieuwe CD-pijplijn aangelegd.

Continue integratie

Elk onderdeel van de IBM Cloud-implementatie had zijn eigen CI-pijplijn. Een reeks aanbevolen procedures en benaderingen is opgenomen in de CI-toolchain. Er wordt een statische codescanner gebruikt om de applicatierepository te inspecteren op eventuele geheimen die zijn opgeslagen in de broncode van de applicatie, evenals op kwetsbare pakketten die worden gebruikt als afhankelijkheden binnen de code van de applicatie. Voor elke Git-commit wordt er een containerimage gemaakt en wordt er een tag aan de image toegewezen op basis van het buildnummer, de tijdstempel en de commit-ID. Dit taggingsysteem garandeert de traceerbaarheid van de afbeelding. Voordat de image wordt gemaakt, wordt het Dockerbestand getest. De gemaakte image wordt opgeslagen in een privéimageregister. De toegangsrechten voor de doelclusterimplementatie worden automatisch geconfigureerd met behulp van API-tokens, die kunnen worden ingetrokken. Er wordt een beveiligingskwetsbaarheidsscan uitgevoerd op de containerimage. Na succesvolle voltooiing wordt een Docker-handtekening toegepast. Door de toevoeging van de gemaakte afbeeldingstag wordt het implementatierecord onmiddellijk bijgewerkt. Het gebruik van een expliciete naamruimte binnen een cluster heeft tot doel elke implementatie te isoleren. Elke code die wordt samengevoegd in de opgegeven tak van de Git-repository, uitdrukkelijk voor implementatie op het Kubernetes-cluster, wordt automatisch geconstrueerd, geverifieerd en geïmplementeerd.

Details van elke docker-image worden opgeslagen in een inventarisrepository, die in detail wordt uitgelegd in de sectie Continue implementatie van deze blog. Bovendien wordt er tijdens elke pijplijnrun bewijsmateriaal verzameld. Dit bewijsmateriaal beschrijft welke taken in de toolchain zijn uitgevoerd, zoals kwetsbaarheidsscans en unit-tests. Dit bewijsmateriaal wordt opgeslagen in een git-repository en een cloud-objectopslagbucket, zodat het indien nodig kan worden gecontroleerd.

We hebben de huidige CI-toolchains die hierboven zijn gebruikt voor de IBM Cloud-implementatie hergebruikt voor de Satellite-implementatie. Omdat de applicatie ongewijzigd bleef, was het niet nodig om de CI-pijplijnen opnieuw op te bouwen voor de nieuwe implementatie.

Voortdurende inzet

De inventaris dient als de bron van waarheid over welke artefacten in welke omgeving/regio worden ingezet; dit wordt bereikt door git branches te gebruiken om omgevingen te vertegenwoordigen, met een promotiepijplijn die omgevingen bijwerkt in een op GitOps gebaseerde aanpak. Bij eerdere implementaties hostte de inventaris ook implementatiebestanden; dit zijn de YAML Kubernetes-bronbestanden die elk onderdeel beschrijven. Deze implementatiebestanden zouden worden bijgewerkt met de juiste naamruimtedescriptors, samen met de nieuwste versie van de Docker-image voor elk onderdeel.

We vonden deze aanpak echter om een ​​aantal redenen moeilijk. Vanuit het perspectief van de applicatie was het grof en ingewikkeld om zoveel afbeeldingstagwaarden en naamruimten te moeten wijzigen met behulp van YAML-vervangingstools (zoals YQ). Voor Satellite zelf gebruiken we de directe uploadstrategie, waarbij elk geleverd YAML-bestand telt als een “versie”. Wij geven er de voorkeur aan dat een versie overeenkomt met de gehele applicatie, en niet slechts met één onderdeel of microservice.

Er was een andere aanpak gewenst, dus hebben we het implementatieproces opnieuw ontworpen om in plaats daarvan een Helm-diagram te gebruiken. Hierdoor konden we de belangrijke waarden, zoals naamruimten en afbeeldingstags, parametriseren en deze tijdens de implementatie invoegen. Het gebruik van deze variabelen neemt een groot deel van de problemen weg die gepaard gaan met het parseren van YAML-bestanden voor een bepaalde waarde. Het roerdiagram is afzonderlijk gemaakt en opgeslagen in hetzelfde containerregister als de gebouwde BIAN-images. We werken momenteel aan de ontwikkeling van een specifieke CI-pijplijn voor het valideren van roerkaarten; hierdoor wordt de kaart gevild, verpakt, ondertekend voor waarheidsgetrouwheid (dit wordt tijdens de implementatietijd geverifieerd) en wordt de kaart opgeslagen. Voorlopig worden deze stappen handmatig uitgevoerd om het diagram te ontwikkelen. Er is één probleem met het samen gebruiken van roerkaarten en satellietconfiguraties: de roerfunctionaliteit vereist een directe verbinding met een Kubernetes- of OpenShift-cluster om zo effectief mogelijk te kunnen werken, en Satellite staat dat uiteraard niet toe. Om dit probleem op te lossen, gebruiken we dus de “helm-sjabloon” om de correct opgemaakte grafiek uit te voeren en vervolgens het resulterende YAML-bestand door te geven aan de functie Satellietupload. Deze functie maakt vervolgens gebruik van de IBM Cloud Satellite CLI om een ​​configuratieversie te maken die de applicatie YAML bevat. Er zijn hier enkele nadelen: we kunnen bepaalde nuttige functionaliteiten die Helm biedt, zoals de mogelijkheid om dat te doen, niet gebruiken rollback naar een eerdere kaartversie en de tests die kunnen worden uitgevoerd om ervoor te zorgen dat de applicatie correct functioneert. We kunnen echter het Satellite rollback-mechanisme gebruiken als vervanging en het versiebeheer ervan als basis hiervoor gebruiken.

Continue naleving

De CC-pijplijn is belangrijk voor het continu scannen van geïmplementeerde artefacten en opslagplaatsen. De waarde hier ligt in het vinden van nieuw gerapporteerde kwetsbaarheden die mogelijk zijn ontdekt nadat de applicatie is geïmplementeerd. De nieuwste definities van kwetsbaarheden van organisaties zoals Snyk en CVE-programma worden gebruikt om deze nieuwe problemen op te sporen. De CC-toolchain voert met door de gebruiker gedefinieerde intervallen een statische codescanner uit op de applicatieopslagplaatsen die beschikbaar zijn om geheimen in de broncode van de applicatie en kwetsbaarheden in applicatie-afhankelijkheden te detecteren.

De pijplijn scant ook containerimages op beveiligingsproblemen. Elk incidentprobleem dat tijdens de scan wordt gevonden of wordt bijgewerkt, wordt gemarkeerd met een vervaldatum. Aan het einde van elke run wordt bewijsmateriaal aangemaakt en opgeslagen in IBM Cloud Object Storage, waarin de details van de scan worden samengevat.

DevOps-inzichten is waardevol om problemen en de algehele beveiligingsstatus van uw applicatie bij te houden. Deze tool bevat alle statistieken van eerdere toolchain-runs op alle drie de systemen: continue integratie, implementatie en compliance. Elk scan- of testresultaat wordt naar dat systeem geüpload, en na verloop van tijd, kunt u zien hoe uw beveiligingspositie evolueert.

Het verkrijgen van CC in een cloudomgeving is van groot belang voor sterk gereguleerde sectoren zoals de financiële dienstverlening, die klant- en applicatiegegevens willen beschermen. In het verleden was dit proces lastig en moest het met de hand worden gedaan, wat organisaties in gevaar bracht. Maar met IBM Cloud Beveiligings- en Compliancecentrum, kunt u dagelijkse, automatische nalevingscontroles toevoegen aan uw ontwikkelingslevenscyclus om dit risico te helpen verminderen. Deze controles omvatten verschillende beoordelingen van DevSecOps-toolchains om de veiligheid en compliance te garanderen.

Op basis van onze ervaring met dit project en andere soortgelijke projecten hebben we een reeks best practices ontwikkeld om teams te helpen hybride cloudoplossingen voor IBM Cloud for Financial Services en IBM Cloud Satellite te implementeren:

• Continue integratie
  • Onderhoud een gemeenschappelijke scriptbibliotheek voor vergelijkbare toepassingen in verschillende toolchains. Dit is de set instructies die bepaalt wat uw CI-toolchain moet doen. Het bouwproces voor NodeJS-applicaties zal bijvoorbeeld over het algemeen dezelfde structuur volgen, dus het is zinvol om een ​​scriptbibliotheek in een aparte repository te bewaren, waarnaar de toolchains zullen verwijzen bij het bouwen van applicaties. Dit maakt een consistente aanpak van CI mogelijk, bevordert hergebruik en vergroot de onderhoudbaarheid.
  • Als alternatief kunnen CI-toolchases worden hergebruikt voor soortgelijke toepassingen met behulp van triggers; deze afzonderlijke triggers kunnen worden gebruikt om te specificeren welke applicatie moet worden gebouwd, waar de code voor de applicatie zich bevindt en andere aanpassingen.

• Voortdurende inzet
  • Voor toepassingen die uit meerdere componenten bestaan, dient u één inventaris bij te houden en dus één implementatietoolketen om alle componenten te implementeren die in de inventaris worden vermeld. Dit voorkomt veel herhaling. Kubernetes YAML-implementatiebestanden hebben allemaal hetzelfde implementatiemechanisme, dus een enkele toolchain die deze op zijn beurt herhaalt, is logischer dan het onderhouden van meerdere CD-toolchains, die in wezen allemaal hetzelfde doen. De onderhoudbaarheid is toegenomen en er is minder werk te doen om de applicatie te implementeren. Triggers kunnen desgewenst nog steeds worden gebruikt om individuele microservices te implementeren.
  • Gebruik Helm-diagrammen voor complexe toepassingen met meerdere componenten. Het gebruik van Helm in het BIAN-project maakte de implementatie veel eenvoudiger. Kubernetes-bestanden worden geschreven in YAML en het gebruik van op bash gebaseerde tekstparsers is omslachtig als tijdens de implementatie meerdere waarden moeten worden aangepast. Helm vereenvoudigt dit door variabelen te gebruiken, waardoor vervanging van waarden veel effectiever wordt. Daarnaast biedt Helm andere functies, zoals versiebeheer voor de hele applicatie, kaartversiebeheer, registeropslag van implementatieconfiguratie en terugdraaimogelijkheden in het geval van een storing. Hoewel het terugdraaien niet werkt bij satellietspecifieke implementaties, wordt hieraan tegemoet gekomen door versiebeheer van de satellietconfiguratie.
• Continue naleving
  • We raden u ten zeerste aan CC-toolchains in te stellen als onderdeel van uw infrastructuur, zodat u voortdurend code en artefacten kunt scannen op kwetsbaarheden die onlangs zijn blootgelegd. Normaal gesproken kunnen deze scans elke nacht worden uitgevoerd of volgens een schema dat past bij uw toepassing en beveiligingssituatie. Om problemen en de algehele beveiligingsstatus van uw applicatie bij te houden, raden we u aan DevOps Insights te gebruiken.
  • We raden ook het gebruik van het Security and Compliance Center (SCC) aan om uw beveiligingshouding te automatiseren. De door de pijpleidingen gegenereerde bewijssamenvatting kan worden geüpload naar de SCC, waar elke vermelding in de bewijssamenvatting wordt behandeld als een “feit” met betrekking tot een taak die in een toolchain is voltooid, of het nu gaat om een ​​kwetsbaarheidsscan, unit-test of iets dergelijks. . De SCC zal vervolgens validatietests uitvoeren op basis van het bewijsmateriaal om vast te stellen dat de beste praktijken met betrekking tot toolchains worden gevolgd.
• Inventaris
  • Zoals eerder vermeld, verdient het bij continue implementatie de voorkeur om één applicatie-inventaris bij te houden waarin al uw microservicegegevens worden opgeslagen, samen met (als u Helm niet gebruikt) Kubernetes-implementatiebestanden. Dit zorgt voor één enkele bron van waarheid over de status van uw implementaties; aangezien vertakkingen in uw inventaris omgevingen vertegenwoordigen, kan het onderhouden van deze omgevingen over meerdere inventarisopslagplaatsen zeer snel omslachtig worden.
• bewijsmateriaal
  • De aanpak van bewijsopslagplaatsen moet anders worden behandeld dan de inventarisatie. In dit geval verdient één bewijsopslag per component de voorkeur; als je ze combineert, kan het opgeslagen bewijsmateriaal overweldigend en moeilijk te beheren worden. Het lokaliseren van specifieke bewijsstukken is veel efficiënter als het bewijsmateriaal wordt opgeslagen in een opslagplaats die specifiek is voor een component. Voor implementatie is één bewijskluis acceptabel, omdat deze afkomstig is van één implementatietoolketen.
  • We raden ten zeerste aan om bewijsmateriaal op te slaan in een objectopslagbucket in de cloud en om de standaard Git-repositoryoptie te gebruiken. Dit komt omdat een COS-bucket zo kan worden geconfigureerd dat deze onveranderlijk is, waardoor we het bewijsmateriaal veilig kunnen opslaan zonder de mogelijkheid van manipulatie, wat erg belangrijk is in het geval van audittrails.        

Conclusie

In deze blog hebben we onze ervaring getoond met het implementeren van een bankapplicatie op basis van BIAN in de hybride cloud, dat wil zeggen met behulp van DevSecOps-pijplijnen om de werklast zowel op IBM Cloud als in een satellietomgeving te implementeren. We bespraken de voor- en nadelen van verschillende benaderingen en de best practices die we hieruit hebben afgeleid na het doorlopen van dit project. We hopen dat dit andere teams kan helpen hun hybride cloudreis met meer consistentie en snelheid te realiseren. Laat ons uw mening weten.

Ontdek wat IBM vandaag de dag te bieden heeft