Best Practices für die sichere und konforme Bereitstellung hybrider Cloud-Banking-Anwendungen in IBM Cloud und Satellite – IBM Blog

Kunden aus dem Finanzdienstleistungssektor streben zunehmend danach, ihre Anwendungen zu modernisieren. Dazu gehört die Modernisierung der Codeentwicklung und -wartung (Unterstützung bei knappen Fähigkeiten und Ermöglichung von Innovationen und neuen Technologien, die von Endbenutzern benötigt werden) sowie die Verbesserung von Bereitstellung und Betrieb unter Verwendung agiler Techniken und DevSecOps.

Im Rahmen ihrer Modernisierungsreise möchten Kunden flexibel bestimmen können, welcher Einsatzort für ihre Anwendungen am besten geeignet ist. Dies kann in jeder der Umgebungen geschehen, die Hybrid Cloud unterstützt (vor Ort, in einer privaten Cloud, in einer öffentlichen Cloud oder am Edge). IBM Cloud Satellite® erfüllt diese Anforderung, indem es die Ausführung moderner, cloudnativer Anwendungen überall dort ermöglicht, wo der Kunde es benötigt, und gleichzeitig eine standardisierte und konsistente Steuerungsebene für die Verwaltung von Anwendungen in der gesamten Hybrid Cloud beibehält.

Darüber hinaus unterstützen viele dieser Finanzdienstleistungsanwendungen regulierte Workloads, die ein strenges Maß an Sicherheit und Compliance erfordern, einschließlich Zero Trust-Schutz der Workloads. IBM Cloud for Financial Services erfüllt diese Anforderung, indem es ein durchgängiges Sicherheits- und Compliance-Framework bereitstellt, mit dem Anwendungen sicher in der Hybrid Cloud implementiert und/oder modernisiert werden können.

In diesem Dokument zeigen wir, wie Sie problemlos eine Bankanwendung auf beiden Plattformen bereitstellen können IBM Cloud für Finanzdienstleistungen machen Satellite, unter Verwendung automatisierter CI/CD/CC-Pipelines auf gemeinsame und konsistente Weise. Dies erfordert ein hohes Maß an Sicherheit und Compliance während des gesamten Erstellungs- und Bereitstellungsprozesses.

Einführung in Konzepte und Produkte

Der Zweck von IBM Cloud for Financial Services besteht darin, Finanzdienstleistungsunternehmen Sicherheit und Compliance zu bieten. Dies geschieht durch die Nutzung von Industriestandards wie NIST800-53 und das Fachwissen von mehr als hundert Finanzdienstleistungskunden, die dem Financial Services Cloud Council angehören. Es bietet ein Kontroll-Framework, das einfach implementiert werden kann, indem Referenzarchitekturen, validierte Cloud-Dienste und ISVs sowie höchste Verschlüsselungsstufen und kontinuierliche Compliance (CC) in der gesamten Hybrid Cloud verwendet werden.

IBM Cloud Satellite bietet ein echtes Hybrid-Cloud-Erlebnis. Mit Satellite können Workloads überall ausgeführt werden, ohne dass die Sicherheit beeinträchtigt wird. Eine einzige Glasscheibe ermöglicht die einfache Anzeige aller Ressourcen in einem Dashboard. Um Anwendungen in diesen unterschiedlichen Umgebungen bereitzustellen, haben wir eine Reihe robuster DevSecOps-Toolchains entwickelt, um Anwendungen zu erstellen, sie sicher und konsistent an einem Satellitenstandort bereitzustellen und die Umgebung mithilfe der besten DevOps-Praktiken zu überwachen.

In diesem Projekt verwendeten wir eine Kreditvergabeanwendung, die für die Verwendung von Kubernetes und Microservices modernisiert wurde. Um diesen Service bereitzustellen, nutzt die Bankanwendung ein Ökosystem von Partneranwendungen, die über die zusammenarbeiten BIAN Rahmen.

Anwendungsübersicht

Bei der in diesem Projekt verwendeten Anwendung handelt es sich um eine Kreditvergabeanwendung, die im Rahmen des Projekts entwickelt wurde BIAN Kernlos 2.0-Initiative. Ein Kunde erhält einen personalisierten Kredit über einen sicheren Online-Kanal, der von einer Bank angeboten wird. Die Anwendung nutzt ein Ökosystem von Partneranwendungen, die auf der BIAN-Architektur zusammenarbeiten, die in der IBM Cloud for Financial Services bereitgestellt wird. Die BIAN Coreless Initiative ermöglicht es Finanzinstituten, die besten Partner auszuwählen, um mithilfe von BIAN-Architekturen neue Dienste schnell und effizient auf den Markt zu bringen. Jede Komponente oder BIAN-Servicedomäne wird über einen Microservice implementiert, der auf einem OCP-Cluster in IBM Cloud bereitgestellt wird.

Anwendungskomponenten basierend auf BIAN Service Domains

• Produktverzeichnis: Führt ein umfassendes Verzeichnis der Produkte und Dienstleistungen der Bank.

• Verbraucherkredit: Verwaltet die Erfüllung eines Verbraucherkreditprodukts. Dies umfasst die Ersteinrichtung der Kreditfazilität und die Durchführung geplanter und Ad-hoc-Produktverarbeitungsaufgaben.

• Kundenangebotsprozess/API: Orchestriert die Bearbeitung eines Produktangebots für einen neuen oder bestehenden Kunden.

• Party-Routing-Profil: Verwaltet ein kleines Profil von Schlüsselindikatoren für einen Kunden, das bei Kundeninteraktionen herangezogen wird, um Routing-, Service- und Produkt-/Dienstleistungserfüllungsentscheidungen zu erleichtern.

Übersicht über den Bereitstellungsprozess

Ein agiler DevSecOps-Workflow wurde verwendet, um die Bereitstellungen in der gesamten Hybrid Cloud abzuschließen. DevSecOps-Workflows konzentrieren sich auf einen regelmäßigen und zuverlässigen Softwarebereitstellungsprozess. Die Methodik ist iterativ und nicht linear, was es DevOps-Teams ermöglicht, Code zu schreiben, ihn zu integrieren, Tests auszuführen, Releases bereitzustellen und Änderungen gemeinsam und in Echtzeit bereitzustellen und dabei Sicherheit und Compliance unter Kontrolle zu halten.

Die Bereitstellung von IBM Cloud for Financial Services wurde in einem sicheren Landing-Zone-Cluster erreicht, und die Infrastrukturbereitstellung wird ebenfalls mithilfe von Richtlinien als Code automatisiert (Terraform). Die Anwendung besteht aus verschiedenen Komponenten. Jede Komponente wurde mit ihrer eigenen bereitgestellt Kontinuierliche Integration (CI), Kontinuierliche Lieferung (CD) machen Kontinuierliche Compliance (CC) Pipeline auf einem RedHat OpenShift-Cluster. Um die Bereitstellung auf Satellite zu erreichen, wurden die CI/CC-Pipelines wiederverwendet und eine neue CD-Pipeline erstellt.

Kontinuierliche Integration

Jede Komponente der IBM Cloud-Bereitstellung verfügte über eine eigene CI-Pipeline. Die CI-Toolchain enthält eine Reihe empfohlener Verfahren und Ansätze. Ein statischer Codescanner wird verwendet, um das Anwendungs-Repository auf alle im Quellcode der Anwendung gespeicherten Geheimnisse sowie auf alle anfälligen Pakete zu untersuchen, die als Abhängigkeiten im Code der Anwendung verwendet werden. Für jeden Git-Commit wird ein Container-Image erstellt und dem Image basierend auf der Build-Nummer, dem Zeitstempel und der Commit-ID ein Tag zugewiesen. Dieses Tagging-System gewährleistet die Rückverfolgbarkeit des Bildes. Vor der Erstellung des Images wird das Dockerfile getestet. Das erstellte Image wird in einer privaten Image-Registrierung gespeichert. Die Zugriffsrechte für die Zielclusterbereitstellung werden automatisch mithilfe von API-Tokens konfiguriert, die widerrufen werden können. Für das Container-Image wird ein Scan auf Sicherheitslücken durchgeführt. Nach erfolgreichem Abschluss wird eine Docker-Signatur angewendet. Durch das Hinzufügen des erstellten Image-Tags wird der Bereitstellungsdatensatz sofort aktualisiert. Die Verwendung eines expliziten Namespace innerhalb eines Clusters dient dem Zweck, jede Bereitstellung zu isolieren. Jeder Code, der ausdrücklich für die Bereitstellung im Kubernetes-Cluster in den angegebenen Zweig des Git-Repositorys eingefügt wird, wird automatisch erstellt, überprüft und implementiert.

Details zu jedem Docker-Image werden in einem Inventar-Repository gespeichert, was im Abschnitt „Kontinuierliche Bereitstellung“ dieses Blogs ausführlich erläutert wird. Darüber hinaus werden während jedes Pipelinelaufs Beweise gesammelt. Dieser Nachweis beschreibt, welche Aufgaben in der Toolchain ausgeführt wurden, beispielsweise Schwachstellenscans und Unit-Tests. Diese Beweise werden in einem Git-Repository und einem Cloud-Objektspeicher-Bucket gespeichert, sodass sie bei Bedarf überprüft werden können.

Wir haben die aktuellen CI-Toolchains, die für die oben genannte IBM Cloud-Bereitstellung verwendet wurden, für die Satellite-Bereitstellung wiederverwendet. Da die Anwendung unverändert blieb, war es nicht erforderlich, die CI-Pipelines für die neue Bereitstellung neu zu erstellen.

Continuous Deployment

Das Inventar dient als Quelle der Wahrheit darüber, welche Artefakte in welcher Umgebung/Region eingesetzt werden; Dies wird mithilfe von Git-Zweigen zur Darstellung von Umgebungen erreicht, wobei eine Promotion-Pipeline Umgebungen in einem GitOps-basierten Ansatz aktualisiert. In früheren Bereitstellungen wurden im Inventar auch Bereitstellungsdateien gehostet. Dies sind die YAML-Kubernetes-Ressourcendateien, die jede Komponente beschreiben. Diese Bereitstellungsdateien würden mit den richtigen Namespace-Deskriptoren sowie der neuesten Version des Docker-Images für jede Komponente aktualisiert.

Allerdings fanden wir diesen Ansatz aus mehreren Gründen schwierig. Aus Sicht der Anwendungen war es grob und kompliziert, so viele Bild-Tag-Werte und Namespaces mithilfe von YAML-Ersetzungstools (wie YQ) ändern zu müssen. Für Satellite selbst verwenden wir die direkte Upload-Strategie, wobei jede bereitgestellte YAML-Datei als „Version“ zählt. Wir möchten, dass eine Version der gesamten Anwendung entspricht und nicht nur einer Komponente oder einem Mikrodienst.

Da ein anderer Ansatz gewünscht wurde, haben wir den Bereitstellungsprozess neu strukturiert und stattdessen ein Helm-Diagramm verwendet. Dies ermöglichte es uns, wichtige Werte wie Namespaces und Image-Tags zu parametrisieren und sie zum Zeitpunkt der Bereitstellung einzufügen. Durch die Verwendung dieser Variablen entfällt ein Großteil der Schwierigkeiten, die mit dem Parsen von YAML-Dateien für einen bestimmten Wert verbunden sind. Das Helmdiagramm wurde separat erstellt und in derselben Containerregistrierung wie die erstellten BIAN-Images gespeichert. Wir arbeiten derzeit an der Entwicklung einer speziellen CI-Pipeline zur Validierung von Ruderkarten; Dadurch wird das Diagramm liniert, verpackt, auf Richtigkeit signiert (dies wird zum Zeitpunkt der Bereitstellung überprüft) und das Diagramm gespeichert. Derzeit werden diese Schritte manuell ausgeführt, um das Diagramm zu entwickeln. Es gibt ein Problem bei der gemeinsamen Verwendung von Helm-Charts und Satellite-Konfigurationen: Für die Helm-Funktionalität ist eine direkte Verbindung mit einem Kubernetes- oder OpenShift-Cluster erforderlich, um am effektivsten zu funktionieren, und Satellite lässt dies natürlich nicht zu. Um dieses Problem zu lösen, verwenden wir die „Helm-Vorlage“, um das korrekt formatierte Diagramm auszugeben und übergeben dann die resultierende YAML-Datei an die Satellite-Upload-Funktion. Diese Funktion nutzt dann die IBM Cloud Satellite-CLI, um eine Konfigurationsversion zu erstellen, die die Anwendungs-YAML enthält. Hier gibt es einige Nachteile: Wir können einige nützliche Funktionen, die Helm bietet, wie z. B. die Möglichkeit, nicht nutzen Rollback auf eine frühere Diagrammversion und die Tests, die durchgeführt werden können, um sicherzustellen, dass die Anwendung ordnungsgemäß funktioniert. Wir können jedoch den Satellite-Rollback-Mechanismus als Ersatz nutzen und dessen Versionierung als Grundlage dafür nutzen.

Kontinuierliche Compliance

Die CC-Pipeline ist wichtig für das kontinuierliche Scannen bereitgestellter Artefakte und Repositorys. Der Wert liegt hier darin, neu gemeldete Schwachstellen zu finden, die möglicherweise erst nach der Bereitstellung der Anwendung entdeckt wurden. Die neuesten Definitionen von Schwachstellen von Organisationen wie Snyk und für CVE-Programm werden verwendet, um diese neuen Probleme zu verfolgen. Die CC-Toolchain führt in benutzerdefinierten Intervallen einen statischen Code-Scanner in den bereitgestellten Anwendungs-Repositorys aus, um Geheimnisse im Quellcode der Anwendung und Schwachstellen in Anwendungsabhängigkeiten zu erkennen.

Die Pipeline scannt auch Container-Images auf Sicherheitslücken. Jedes Vorfallproblem, das während des Scans gefunden oder aktualisiert wird, wird mit einem Fälligkeitsdatum gekennzeichnet. Am Ende jedes Laufs werden Beweise erstellt und in IBM Cloud Object Storage gespeichert, die die Details des Scans zusammenfassen.

DevOps-Einblicke ist wertvoll, um Probleme und den allgemeinen Sicherheitsstatus Ihrer Anwendung im Auge zu behalten. Dieses Tool enthält alle Metriken früherer Toolchain-Läufe über alle drei Systeme hinweg: kontinuierliche Integration, Bereitstellung und Compliance. Jedes Scan- oder Testergebnis wird in dieses System hochgeladen und Zeitkönnen Sie beobachten, wie sich Ihre Sicherheitslage entwickelt.

CC in einer Cloud-Umgebung einzusetzen ist für stark regulierte Branchen wie Finanzdienstleistungen, die Kunden- und Anwendungsdaten schützen möchten, von Bedeutung. In der Vergangenheit war dieser Prozess schwierig und musste manuell durchgeführt werden, was ein Risiko für Unternehmen darstellt. Aber mit IBM Cloud Security and Compliance Centerkönnen Sie Ihrem Entwicklungslebenszyklus tägliche, automatische Compliance-Prüfungen hinzufügen, um dieses Risiko zu reduzieren. Diese Prüfungen umfassen verschiedene Bewertungen der DevSecOps-Toolchains, um Sicherheit und Compliance zu gewährleisten.

Basierend auf unserer Erfahrung mit diesem Projekt und anderen ähnlichen Projekten haben wir eine Reihe von Best Practices erstellt, um Teams bei der Implementierung hybrider Cloud-Lösungen für IBM Cloud for Financial Services und IBM Cloud Satellite zu unterstützen:

• Kontinuierliche Integration
  • Pflegen Sie eine gemeinsame Skriptbibliothek für ähnliche Anwendungen in verschiedenen Toolchains. Dies sind die Anweisungen, die bestimmen, was Ihre CI-Toolchain tun soll. Beispielsweise folgt der Erstellungsprozess für NodeJS-Anwendungen im Allgemeinen derselben Struktur. Daher ist es sinnvoll, eine Skriptbibliothek in einem separaten Repository aufzubewahren, auf das die Toolchains beim Erstellen von Anwendungen verweisen. Dies ermöglicht einen konsistenten CI-Ansatz, fördert die Wiederverwendung und erhöht die Wartbarkeit.
  • Alternativ können CI-Toolchains mithilfe von Triggern für ähnliche Anwendungen wiederverwendet werden. Diese separaten Trigger können verwendet werden, um anzugeben, welche Anwendung erstellt werden soll, wo sich der Code für die Anwendung befindet und um andere Anpassungen vorzunehmen.

• Continuous Deployment
  • Pflegen Sie für Mehrkomponentenanwendungen ein einziges Inventar und damit eine einzige Bereitstellungs-Toolchain, um alle im Inventar aufgeführten Komponenten bereitzustellen. Dies verhindert viele Wiederholungen. Kubernetes YAML-Bereitstellungsdateien verfügen alle über denselben Bereitstellungsmechanismus. Daher ist es logischer, eine einzelne Toolchain nacheinander zu durchlaufen, als mehrere CD-Toolchains zu verwalten, die im Wesentlichen alle das Gleiche tun. Die Wartbarkeit hat sich verbessert und die Bereitstellung der Anwendung erfordert weniger Arbeit. Bei Bedarf können Trigger weiterhin zur Bereitstellung einzelner Microservices verwendet werden.
  • Verwenden Sie Helm-Diagramme für komplexe Mehrkomponentenanwendungen. Die Verwendung von Helm im BIAN-Projekt hat die Bereitstellung erheblich vereinfacht. Kubernetes-Dateien werden in YAML geschrieben und die Verwendung von Bash-basierten Textparsern ist umständlich, wenn zum Zeitpunkt der Bereitstellung mehrere Werte angepasst werden müssen. Helm vereinfacht dies durch die Verwendung von Variablen, wodurch die Ersetzung von Werten wesentlich effektiver wird. Darüber hinaus bietet Helm weitere Funktionen wie Versionierung der gesamten Anwendung, Diagrammversionierung, Registrierungsspeicherung der Bereitstellungskonfiguration und Rollback-Funktionen im Fehlerfall. Während ein Rollback bei Satellite-spezifischen Bereitstellungen nicht funktioniert, wird dies durch die Versionierung der Satellite-Konfiguration berücksichtigt.
• Kontinuierliche Compliance
  • Wir empfehlen dringend, CC-Toolchains als Teil Ihrer Infrastruktur einzurichten, um Code und Artefakte kontinuierlich auf neu aufgedeckte Schwachstellen zu scannen. In der Regel können diese Scans jede Nacht oder nach einem Zeitplan ausgeführt werden, der Ihrer Anwendung und Sicherheitssituation entspricht. Um den Überblick über Probleme und den allgemeinen Sicherheitsstatus Ihrer Anwendung zu behalten, empfehlen wir Ihnen die Verwendung von DevOps Insights.
  • Wir empfehlen außerdem die Verwendung des Security and Compliance Center (SCC), um Ihren Sicherheitsstatus zu automatisieren. Die von den Pipelines generierte Beweiszusammenfassung kann in das SCC hochgeladen werden, wo jeder Eintrag in der Beweiszusammenfassung als „Tatsache“ behandelt wird, die sich auf eine in einer Toolchain erledigte Aufgabe bezieht, sei es ein Schwachstellenscan, ein Komponententest oder ähnliches . Das SCC führt dann Validierungstests anhand der Beweise durch, um festzustellen, ob Best Practices im Zusammenhang mit Toolchains befolgt werden.
• Maschinen
  • Wie bereits erwähnt, ist es bei der kontinuierlichen Bereitstellung vorzuziehen, ein einziges Anwendungsinventar zu verwalten, in dem alle Ihre Microservice-Details zusammen mit den Kubernetes-Bereitstellungsdateien (falls Sie Helm nicht verwenden) gespeichert werden. Dies ermöglicht eine zentrale Informationsquelle über den Status Ihrer Bereitstellungen. Da Zweige in Ihrem Inventar Umgebungen darstellen, kann die Verwaltung dieser Umgebungen über mehrere Inventar-Repositorys hinweg sehr schnell mühsam werden.
• Beweis
  • Die Herangehensweise an Beweismittelspeicher sollte anders behandelt werden als die Bestandsaufnahme. In diesem Fall ist ein Evidence-Repository pro Komponente vorzuziehen; Wenn Sie sie kombinieren, können die gespeicherten Beweise überwältigend und schwierig zu verwalten sein. Das Auffinden bestimmter Beweisstücke ist viel effizienter, wenn die Beweise in einem komponentenspezifischen Repository gespeichert werden. Für die Bereitstellung ist ein einzelner Beweisschließer akzeptabel, da er aus einer einzigen Bereitstellungs-Toolchain stammt.
  • Wir empfehlen dringend, Beweise in einem Cloud-Objektspeicher-Bucket zu speichern und die standardmäßige Git-Repository-Option zu verwenden. Dies liegt daran, dass ein COS-Bucket unveränderlich konfiguriert werden kann, was es uns ermöglicht, die Beweise sicher zu speichern, ohne dass die Möglichkeit einer Manipulation besteht, was im Fall von Audit-Trails sehr wichtig ist.        

Zusammenfassung

In diesem Blog haben wir unsere Erfahrungen bei der Implementierung einer auf BIAN basierenden Bankanwendung in der gesamten Hybrid Cloud vorgestellt, d. h. mithilfe von DevSecOps-Pipelines, um die Arbeitslast sowohl in der IBM Cloud als auch in einer Satellite-Umgebung bereitzustellen. Wir diskutierten die Vor- und Nachteile verschiedener Ansätze und die Best Practices, die wir nach der Durchführung dieses Projekts abgeleitet hatten. Wir hoffen, dass dies anderen Teams dabei helfen kann, ihre Hybrid-Cloud-Reise konsistenter und schneller zu gestalten. Teilen Sie uns Ihre Gedanken mit.

Entdecken Sie, was IBM heute zu bieten hat