IBM Cloud とサテライト全体でハイブリッド・クラウド・バンキング・アプリケーションを安全かつ準拠したデプロイメントするためのベスト・プラクティス – IBM ブログ

金融サービスの顧客は、アプリケーションを最新化することをますます求めています。これには、コードの開発とメンテナンスの最新化（不足しているスキルを支援し、エンドユーザーが必要とする革新と新しいテクノロジーを可能にする）、アジャイル技術を使用した導入と運用の改善が含まれます。 DevSecOps.

モダナイゼーションの一環として、クライアントはアプリケーションの「目的に最適な」導入場所を柔軟に決定できることを望んでいます。これは、ハイブリッド クラウドがサポートする環境 (オンプレミス、プライベート クラウド、パブリック クラウド、またはエッジ) のいずれかに存在する可能性があります。 IBM Cloud Satellite® は、ハイブリッド・クラウド全体でアプリケーションを管理するための標準的で一貫したコントロール・プレーンを維持しながら、最新のクラウド・ネイティブ・アプリケーションをクライアントが必要とする場所で実行できるようにすることで、この要件を満たします。

さらに、これらの金融サービス アプリケーションの多くは、ワークロードのゼロトラスト保護を含む、厳格なレベルのセキュリティとコンプライアンスを必要とする、規制されたワークロードをサポートしています。 IBM Cloud for Financial Services は、ハイブリッド・クラウド全体でアプリケーションを安全に実装および/または最新化するために使用できる、エンドツーエンドのセキュリティーおよびコンプライアンスのフレームワークを提供することで、その要件を満たします。

このペーパーでは、バンキング アプリケーションを両方の環境に簡単に展開する方法を紹介します。 金融サービス向け IBM Cloud および 衛星、共通かつ一貫した方法で自動化された CI/CD/CC パイプラインを使用します。これには、構築および展開プロセス全体を通じて、深いレベルのセキュリティとコンプライアンスが必要です。

コンセプトと製品の紹介

IBM Cloud for Financial Services の目的は、金融サービス会社にセキュリティーとコンプライアンスを提供することです。これは、次のような業界標準を活用することで実現されます。 NIST 800-53 そして、Financial Services Cloud Council に参加している 100 社を超える金融サービス クライアントの専門知識を備えています。リファレンス アーキテクチャ、検証済みのクラウド サービス、ISV を使用して簡単に実装できる制御フレームワークに加え、ハイブリッド クラウド全体にわたる最高レベルの暗号化と継続的コンプライアンス (CC) を提供します。

IBM Cloud Satellite は、真のハイブリッド・クラウド・エクスペリエンスを提供します。サテライトを使用すると、セキュリティを損なうことなく、どこでもワークロードを実行できます。単一ウィンドウにより、すべてのリソースを 1 つのダッシュボードで簡単に確認できます。これらのさまざまな環境にアプリケーションをデプロイするために、当社はアプリケーションを構築し、安全かつ一貫した方法でサテライトの場所にデプロイし、DevOps のベスト プラクティスを使用して環境を監視する一連の堅牢な DevSecOps ツールチェーンを開発しました。

このプロジェクトでは、Kubernetes とマイクロサービスを使用するように最新化されたローン組成アプリケーションを使用しました。このサービスを提供するために、銀行アプリケーションは、 ビアン フレームワーク。

アプリケーションの概要

このプロジェクトで使用されるアプリケーションは、 BIAN コアレス 2.0イニシアチブ。顧客は、銀行が提供する安全で確実なオンライン チャネルを通じて個人向けローンを受け取ります。このアプリケーションは、IBM Cloud for Financial Services 上にデプロイされた BIAN アーキテクチャー上で相互運用するパートナー・アプリケーションのエコシステムを採用しています。 BIAN Coreless Initiative は、金融機関が BIAN アーキテクチャを通じて新しいサービスを迅速かつ効率的に市場に投入するのに役立つ最適なパートナーを選択できるようにします。各コンポーネントまたは BIAN サービス ドメインは、IBM Cloud 上の OCP クラスターにデプロイされるマイクロサービスを通じて実装されます。

BIAN サービス ドメインに基づくアプリケーション コンポーネント

• 製品ディレクトリ: 銀行の商品とサービスの包括的なディレクトリを管理します。

• 消費者ローン: 消費者ローン商品の履行を処理します。これには、ローン機能の初期設定と、スケジュールされたおよび臨時の商品処理タスクの完了が含まれます。

• 顧客オファープロセス/API: 新規または既存の顧客に対する製品オファーの処理を調整します。

• パーティルーティングプロファイル: ルーティング、サービス、製品/サービスの履行に関する意思決定を容易にするために、顧客との対話中に参照される顧客の重要な指標の小さなプロファイルを維持します。

導入プロセスの概要

アジャイル DevSecOps ワークフローを使用して、ハイブリッド クラウド全体への展開を完了しました。 DevSecOps ワークフローは、頻繁かつ信頼性の高いソフトウェア配信プロセスに焦点を当てています。この方法論は線形ではなく反復的であるため、DevOps チームは、セキュリティとコンプライアンスをチェックしながら、コードの作成、統合、テストの実行、リリースの提供、および変更のデプロイを共同でリアルタイムで行うことができます。

IBM Cloud for Financial Services のデプロイメントはセキュア・ランディング・ゾーン・クラスターで実現され、インフラストラクチャーのデプロイメントもコードとしてのポリシーを使用して自動化されています (テラフォーム）。アプリケーションはさまざまなコンポーネントで構成されています。各コンポーネントは独自のを使用してデプロイされました 継続的インテグレーション（CI）, 継続的デリバリー（CD） および 継続的コンプライアンス (CC) RedHat OpenShift Cluster 上のパイプライン。サテライト上でのデプロイメントを実現するために、CI/CC パイプラインが再利用され、新しい CD パイプラインが作成されました。

継続的インテグレーション

IBM Cloud デプロイメントの各コンポーネントには独自の CI パイプラインがありました。推奨される手順とアプローチのセットが CI ツールチェーンに含まれています。静的コード スキャナーは、アプリケーション リポジトリを検査して、アプリケーションのソース コードに保存されているシークレットや、アプリケーション コード内の依存関係として使用されている脆弱なパッケージを検査します。 Git コミットごとにコンテナー イメージが作成され、ビルド番号、タイムスタンプ、コミット ID に基づいてタグがイメージに割り当てられます。このタグ付けシステムにより、画像の追跡可能性が保証されます。イメージを作成する前に、Dockerfile がテストされます。作成されたイメージはプライベート イメージ レジストリに保存されます。ターゲット クラスター デプロイメントのアクセス権限は API トークンを使用して自動的に構成されますが、取り消すことができます。コンテナー イメージに対してセキュリティ脆弱性スキャンが実行されます。正常に完了すると、Docker 署名が適用されます。作成したイメージタグを追加すると、展開記録が即座に更新されます。クラスター内で明示的な名前空間を使用すると、各デプロイメントを分離することができます。 Git リポジトリの指定されたブランチにマージされるコードは、明示的に Kubernetes クラスターにデプロイするために、自動的に構築、検証、実装されます。

各 Docker イメージの詳細はインベントリ リポジトリに保存されます。これについては、このブログの「継続的デプロイメント」セクションで詳しく説明されています。さらに、パイプラインの実行ごとに証拠が収集されます。この証拠は、脆弱性スキャンや単体テストなど、ツールチェーンでどのようなタスクが実行されたかを説明します。この証拠は、必要に応じて監査できるように、Git リポジトリとクラウド オブジェクト ストレージ バケットに保存されます。

前述の IBM Cloud デプロイメントに使用されている現在の CI ツールチェーンをサテライト デプロイメントにも再利用しました。アプリケーションは変更されていないため、新しいデプロイメント用に CI パイプラインを再構築する必要はありませんでした。

継続的な展開

インベントリは、どのアーティファクトがどの環境/地域にデプロイされるかに関する真実の情報源として機能します。これは、環境を表す git ブランチを使用し、GitOps ベースのアプローチで環境を更新するプロモーション パイプラインを使用して実現されます。以前の展開では、インベントリは展開ファイルもホストしていました。これらは、各コンポーネントを説明する YAML Kubernetes リソース ファイルです。これらのデプロイメント ファイルは、各コンポーネントの最新バージョンの Docker イメージとともに、正しい名前空間記述子で更新されます。

しかし、いくつかの理由から、このアプローチは難しいことがわかりました。アプリケーションの観点から見ると、YAML 置換ツール (YQ など) を使用して非常に多くのイメージ タグ値と名前空間を変更する必要があるのは、大雑把で複雑でした。 Satellite 自体については、提供された各 YAML ファイルを「バージョン」としてカウントする直接アップロード戦略を使用しています。 1 つのコンポーネントやマイクロサービスだけではなく、アプリケーション全体に対応するバージョンを用意したいと考えています。

別のアプローチが必要だったので、代わりに Helm チャートを使用するようにデプロイメント プロセスを再設計しました。これにより、名前空間やイメージタグなどの重要な値をパラメータ化し、デプロイメント時にそれらを挿入できるようになりました。これらの変数を使用すると、特定の値の YAML ファイルの解析に伴う多くの困難が解消されます。 Helm チャートは個別に作成され、ビルドされた BIAN イメージと同じコンテナー レジストリに保存されました。私たちは現在、ヘルム チャートを検証するための特定の CI パイプラインの開発に取り組んでいます。これにより、チャートがリントされ、パッケージ化され、真実性を証明するために署名され (これは展開時に検証されます)、チャートが保存されます。現時点では、これらの手順を手動で実行してチャートを作成します。 Helm チャートと Satellite 構成を一緒に使用する場合、問題が 1 つあります。helm 機能を最も効果的に動作させるには、Kubernetes または OpenShift クラスターとの直接接続が必要ですが、Satellite ではもちろんそれが許可されません。したがって、この問題を解決するには、「helm テンプレート」を使用して正しくフォーマットされたグラフを出力し、結果の YAML ファイルを Satellite アップロード関数に渡します。次に、この関数は IBM Cloud Satellite CLI を利用して、アプリケーション YAML を含む構成バージョンを作成します。ここにはいくつかの欠点があります。Helm が提供するいくつかの便利な機能を使用できません。 ロールバック チャートを以前のバージョンに戻し、アプリケーションが正しく機能していることを確認するために実行できるテストを実行します。ただし、代わりに Satellite ロールバック メカニズムを使用し、そのバージョン管理をその基礎として使用できます。

継続的なコンプライアンス

CC パイプラインは、デプロイされたアーティファクトとリポジトリを継続的にスキャンするために重要です。ここでの価値は、アプリケーションの展開後に発見された可能性のある、新たに報告された脆弱性を見つけることにあります。などの組織による脆弱性の最新の定義 スナック と CVE プログラム これらの新しい問題を追跡するために使用されます。 CC ツールチェーンは、アプリケーションのソース コード内の秘密やアプリケーションの依存関係の脆弱性を検出するために提供されるアプリケーション リポジトリ上で、ユーザーが定義した間隔で静的コード スキャナーを実行します。

このパイプラインは、コンテナー イメージのセキュリティ脆弱性もスキャンします。スキャンまたは更新中に見つかったインシデントの問題には期限がマークされます。スキャンの詳細を要約した証拠が各実行の終了時に作成され、IBM Cloud Object Storage に保存されます。

DevOps の洞察 これは、アプリケーションの問題と全体的なセキュリティ体制を追跡するのに役立ちます。このツールには、継続的インテグレーション、デプロイメント、コンプライアンスの 3 つのシステムすべてにわたって実行された以前のツールチェーンのすべてのメトリクスが含まれています。スキャンまたはテストの結果はそのシステムにアップロードされ、 の経時変化の追跡では、セキュリティ体制がどのように進化しているかを観察できます。

クラウド環境で CC を導入することは、顧客データやアプリケーション データを保護したい金融サービスなどの規制の厳しい業界にとって重要です。以前は、このプロセスは難しく、手作業で行う必要があったため、組織は危険にさらされていました。しかし、 IBMクラウド・セキュリティーおよびコンプライアンス・センター、毎日の自動コンプライアンス チェックを開発ライフサイクルに追加して、このリスクを軽減できます。これらのチェックには、セキュリティとコンプライアンスを確保するための DevSecOps ツールチェーンのさまざまな評価が含まれます。

このプロジェクトおよび他の同様のプロジェクトでの経験に基づいて、チームが IBM Cloud for Financial Services および IBM Cloud Satellite 用のハイブリッド・クラウド・ソリューションを実装するのに役立つ一連のベスト・プラクティスを作成しました。

• 継続的インテグレーション
  • 異なるツールチェーン内の同様のアプリケーション用に共通のスクリプト ライブラリを維持します。これは、CI ツールチェーンが何を実行するかを決定する一連の命令です。たとえば、NodeJS アプリケーションのビルド プロセスは通常同じ構造に従います。そのため、ツールチェーンがアプリケーションをビルドするときに参照するスクリプト ライブラリを別のリポジトリに保持することは理にかなっています。これにより、CI への一貫したアプローチが可能になり、再利用が促進され、保守性が向上します。
  • あるいは、トリガーを使用して、CI ツールチェーンを同様のアプリケーションに再利用することもできます。これらの個別のトリガーを使用して、どのアプリケーションを構築するか、アプリケーションのコードの場所、およびその他のカスタマイズを指定できます。

• 継続的な展開
  • マルチコンポーネント アプリケーションの場合は、単一のインベントリを維持し、インベントリにリストされているすべてのコンポーネントを展開するための単一の展開ツールチェーンを維持します。これにより、多くの繰り返しが防止されます。 Kubernetes YAML デプロイメント ファイルはすべて同じデプロイメント メカニズムを備えているため、単一のツールチェーンを順番に反復処理することは、すべてが本質的に同じことを行う複数の CD ツールチェーンを維持するよりも論理的です。保守性が向上し、アプリケーションのデプロイに必要な作業が減りました。必要に応じて、トリガーを使用して個々のマイクロサービスをデプロイすることもできます。
  • 複雑な複数コンポーネントのアプリケーションには Helm チャートを使用します。 BIAN プロジェクトで Helm を使用すると、デプロイがはるかに簡単になりました。 Kubernetes ファイルは YAML で記述されており、デプロイメント時に複数の値をカスタマイズする必要がある場合、bash ベースのテキスト パーサーを使用するのは面倒です。 Helm は変数を使用することでこれを簡素化し、値の置換をより効果的にします。さらに、Helm は、アプリケーション全体のバージョン管理、チャートのバージョン管理、デプロイメント構成のレジストリ ストレージ、障害時のロールバック機能などの他の機能を提供します。ロールバックはサテライト固有のデプロイメントでは機能しませんが、これはサテライト構成のバージョニングによって対応されます。
• 継続的なコンプライアンス
  • インフラストラクチャの一部として CC ツールチェーンを設定し、コードとアーティファクトを継続的にスキャンして新たに公開された脆弱性を見つけることを強くお勧めします。通常、これらのスキャンは毎晩実行することも、アプリケーションやセキュリティの状況に合わせたスケジュールで実行することもできます。アプリケーションの問題と全体的なセキュリティ体制を追跡するには、DevOps Insights を使用することをお勧めします。
  • また、セキュリティ体制を自動化するために、セキュリティおよびコンプライアンス センター (SCC) を使用することをお勧めします。パイプラインによって生成された証拠の概要は SCC にアップロードでき、証拠の概要の各エントリは、脆弱性スキャン、単体テストなど、ツールチェーン内で完了したタスクに関連する「事実」として扱われます。 。その後、SCC は証拠に対して検証テストを実行し、ツールチェーンに関連するベスト プラクティスが遵守されていることを確認します。
• 棚卸
  • 前述したように、継続的デプロイメントでは、すべてのマイクロサービスの詳細が (Helm を使用していない場合は) Kubernetes デプロイメント ファイルとともに保存される単一のアプリケーション インベントリを維持することが望ましいです。これにより、デプロイメントの状態に関する信頼できる単一の情報源が可能になります。インベントリ内のブランチは環境を表すため、複数のインベントリ リポジトリにわたってこれらの環境を維持することは、すぐに面倒になる可能性があります。
• 証拠
  • 証拠リポジトリへのアプローチは、目録とは異なる方法で扱う必要があります。この場合、コンポーネントごとに 1 つの証拠リポジトリが望ましいです。これらを組み合わせると、保存された証拠が膨大になり、管理が困難になる可能性があります。証拠がコンポーネント固有のリポジ​​トリに保存されている場合、証拠の特定の部分を見つけるのがはるかに効率的になります。導入の場合、単一の導入ツールチェーンから供給されるため、単一の証拠ロッカーが受け入れられます。
  • デフォルトの git リポジトリ オプションを使用するだけでなく、証拠をクラウド オブジェクト ストレージ バケットに保存することを強くお勧めします。これは、COS バケットを不変に構成できるため、改ざんの可能性なしに証拠を安全に保存できるためです。これは監査証跡の場合に非常に重要です。        

まとめ

このブログでは、ハイブリッド クラウド全体に BIAN に基づくバンキング アプリケーションを実装した経験、つまり、DevSecOps パイプラインを使用して IBM Cloud とサテライト環境の両方にワークロードをデプロイした経験を紹介しました。私たちは、さまざまなアプローチの長所と短所、およびこのプロジェクトを経て導き出されたベスト プラクティスについて話し合いました。これにより、他のチームがより一貫性とスピードを持ってハイブリッド クラウドへの移行を達成できることを願っています。あなたの考えをお聞かせください。

IBM が今日提供できるものをご覧ください