自動オンボーディング: USAA のセキュリティ チームがユーザーを GCP にオンボーディングする方法

※この投稿は米国時間 2021 年 10 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

1922 年以来、テクノロジーとイノベーションは、USAA が軍人とその家族にサービスを提供するうえで不可欠な役割を果たしてきました。会員数が 1,300 万人を超え、それに伴い会員のニーズに応えるためのサービスも進化しています。その結果、銀行業や保険業のアプリケーション チーム全体で、未来のサービスを発展させるために Google Cloud を利用するようになりました。

USAA では、ビジネスにおけるパートナーは、セキュリティ チームに絶対的な信頼を寄せ、アプリケーション チームの Google Cloud へのオンボーディングを受け、迅速に生産性を高めています。この投稿では、USAA のセキュリティ チームがこのような要件を満たすために使用している自動化されたプロセスについて詳しくご紹介します。具体的には、以下の原則を重視しています。

• セキュリティのベスト プラクティスを確実に基盤に組み込む - 時間的制約のある認証情報や、セキュリティ ツールとのインテグレーションであっても、最初からセキュリティを組み込むことで技術的負担を軽減し、GCP 組織全体の可視性を確保します。

• Terraform を導入してアプリケーション チームの障害を減らす - Terraform を導入することで、アプリケーション開発者は本来の業務に集中でき、全体的なエクスペリエンスが向上します。また、チームは既存の予防的ガードレールを活用して、USAA のセキュリティ対策の向上に貢献しています。

• セキュリティ チームのための再現性のあるオンボーディング プロセスを確立する – 需要が増加しても、セキュリティ チームのメンバーは、確立された標準的な手順を再利用することができ、承認済みのベースライン セキュリティ制御とガードレールを迅速に追加できます。このプロセスを確立することで、少数のチームメンバーに知識が集中することも防ぎます。

はじめに - 組織の構造化

このガイドでは、GCP 上に組織を作成し、スーパー ユーザー アカウントを保護するためのベスト プラクティスを確認していることを前提としています。

セキュリティ チームが備えるツールの中で最も強力なものは、GCP リソースを階層的に構造化する能力です。これにより、権限を任意の階層で定義し、子リソースに継承させることができます。既存の組織構造をクラウドにリフト＆シフトするのは簡単かもしれませんが、多くの場合この最初のステップでは、組織が現在および将来的にリソースを保護、デプロイ、使用する方法とその影響を考慮した慎重な設計をすることでメリットが得られます。

セキュリティ パイプライン – アクセス制御のフレームワーク

クラウドへの移行の初期段階で、セキュリティ チームは、すべての CI / CD リソースをフェデレーション ID グループの IAM アクセスとともに所有することを決断しました。この決断をすることで、セキュリティ チームはプログラムによって IAM アクセスの付与が可能になります。そして、アプリケーション チームのサービス アカウントとリモート Terraform 状態のバケットは、それらを使用するアプリケーション チームの権限外にあるセキュリティ所有のプロジェクトに存在できるようになります。これは、セキュリティにも大きく影響し、各チームのアプリケーションのベースラインや境界線を構築するためには欠かせないものです。

このアプローチの利点の一つは、リモート Terraform 状態のバケットとオブジェクト ライフサイクル ポリシーの一元管理です。これは、アプリケーション シークレットやその他の機密情報が状態ファイルに保存されるリスクがあるために実装された制御です。また、このソリューションによって、すべての CI / CD パイプラインのサービス アカウントを一元化します。サービス アカウントの Google Cloud API アクセスは、元のプロジェクトで API を有効または無効にすることで制御されるため、すべてのパイプライン サービス アカウントの API アクセスは、このセキュリティ所有のプロジェクトから一元管理されます。例えば、IaC-app プロジェクトで Google Cloud Billing API が無効だとします。この場合、どのアプリケーション サービス アカウントも、エンジニアリング フォルダの下に作成された Billing API プロジェクトを有効にできません。また、この方法によりセキュリティ チームは、削除、未承認のサービス アカウント キーの生成、または権限を付与されたサービスア カウントに関するその他の改ざんを防げます。

セキュリティの CI / CD パイプラインは、シンプルなツールセットを使ってビルドされています。

• 最小限の権限セットを持つセキュリティ パイプラインのサービス アカウント。

• 各アプリケーション チームのベースラインを定義する Terraform モジュール。

• 各アプリケーション チームのベースライン デプロイを管理するためのTerraform リモート状態バケット。

さらに、社内のマルチテナント フットプリントを管理するために、オンボーディング プロセスを拡大し、管理対象の Firestore データベースにアプリケーション固有のメタデータを入力しました。このデータは、ビルバックまたは、この記事の「イベントベースの登録」のセクションで紹介するプロジェクトのオートラベラーのような他のサービスで利用できます。

アプリケーションのベースライン設定 – 権限の境界線の作成

アプリケーション固有のメタデータにより、アプリケーションのベースライン モジュールを使用して、チームが GCP アプリケーションのワークスペースとして使用するアプリケーション チームフォルダをビルドできます。さらに、このモジュールを使用して、CI / CD パイプラインのサービス アカウントと Google Cloud Storage バケットを作成し、セキュリティ所有のプロジェクト（下図の IaC-app）にリモート Terraform 状態のファイルを保持します。最も重要なのは、パイプラインのサービス アカウントとフェデレーション ID グループの基本的なアクセス制御に取り組むことです。このような IAM バインディングは、アプリケーション チームフォルダに設定されます。

このモジュールは一連の基本的な権限を提供するという点では優れていますが、アプリケーション チームが求める十分なレベルのアジリティを提供できないことがすぐにわかりました。Google プロジェクトを作成した ID は、制限なくオーナーとして追加されるため、当初、プロジェクトの作成はセキュリティ チームが手動で行っていました。この問題を解決するために、イベントベースの「オーナー権限の降格」サービスを実装することで、開発者が独自のプロジェクトを作成して管理できるようにしました。このサービスでは、組織のログシンクを使用してプロジェクトの作成イベントをキャプチャし、Cloud Functions の関数をトリガーすることで、開発者をプロジェクトのオーナーから外すことができます。これにより、許可リスト登録済みのロールから最初に設定された権限の境界が、アプリケーション チームによって変更できなくなります。

このワークフローにはいくつかのメリットがあります。アプリケーション　チームはわずか数分でビルドできるようになり、すぐに使用できる制限付き権限セットがチームに提供されます。サンドボックス化された環境ではコンソールへのアクセスを制限していますが、この初期のベースラインにより Terraform に関連する摩擦が軽減されています。チームは、状態ファイルの管理、バージョニング、ファイルレベルの暗号化などを気にする必要がなくなりました。

認証 – アプリケーション チームのためのビルド済みワークフロー

認証には、どのような種類の認証情報を使用するのか、このようなシークレットはどこにどのように保存されるのか、そしてどのように CI / CD パイプラインに組み込むのかなど、難しい問題がつきまといます。  この問題を解決できないと、アプリケーション チームは独自の戦略を立てざるを得なくなり、開発に集中できなくなるだけでなく、セキュリティに関する懸念の原因となる可能性があります。USAA のセキュリティ チームは、Google Cloud にデプロイするすべての CI / CD パイプラインで使用されるビルド済みのワークフローによって、この問題の緩和に取り組んできました。

GCP への認証に関する集中型の管理を導入するために、確実な VPC Service Controls で保護された Cloud Functions の関数を作成しました。この Cloud Functions の関数の唯一の目的は、CI / CD パイプラインに使用する有効時間が短い認証情報を生成することです。前のセクションで説明したアプリケーションのベースライン モジュールを実行する際に、環境ごとに「呼び出し元」サービス アカウントといくつかの「処理中」サービス アカウントをアプリケーション チーム用に作成します。サービス アカウント キーは「呼び出し元」のサービス アカウント用に生成され、オンプレミスで安全に保管され、CI / CD パイプラインで取得できます。Cloud Functions は、「呼び出し元」が誰であるか、どのような環境にデプロイされているかを判断し、リクエスト済みの「処理中」サービス アカウントに関する一時的な認証情報を提供します。Terraform はこれらの有効時間が短い認証情報を問題なく使用できますが、他のツールで使用できない場合がありますのでご注意ください。同様の戦略を実践する前に、お使いのデプロイツールやテストツールのドキュメントをご覧ください。

このプロセスは、ほとんどすべての GCP デプロイメントで適切に機能することがわかっています。アプリケーション チームに対して、シークレットは適切に管理され、保護されています。また、有効期間の短いトークンの使用や、VPC Service Controls で上り（内向き）の制限をすることで、ベスト プラクティスに従っています。さらに、私たちのチームはパイプライン内のリモート状態バケットの使用を抽象化し、開発者に関する変更を正しい Terraform 状態ファイルとバケットにマッピングするという当て推量での作業を排除しています。これにより、同じチームの開発者がコードの改善や、機能ブランチを作成する際に、チームメイトの作業を邪魔することがなくなります。上記のベースライン設定と同様に、これは組織全体で選択するデプロイ メカニズムとして Terraform の導入支援に役立つことがわかりました。

イベントベースの登録

アプリケーション チームのための基礎を築いた今、次の課題は、セキュリティ チームが Google Cloud 環境全体の可視性を確保することです。これには、ロギング、モニタリング、アラート、脆弱性管理などが含まれます。これらの要件を満たすために、ネイティブ GCP サービス、外部ベンダー、カスタムの自動化を組み合わせて使用しています。

すべての自動化は、アプリケーション チームがプロジェクトを作成する際に始まります。組織レベルで集約されたログシンクを使用し、「projectCreate」イベントをフィルタリングします。このイベントは Pub/Sub トピックにエクスポートされ、Cloud Functions の関数がトリガーされます。目的に応じて、Cloud Functions ではベンダーの SaaS プラットフォームや USAA のデータセンターで不足しているツールに API 呼び出しを行う場合があります。また、ベースライン設定のプロセスで提供されたアプリケーション固有の Firestore メタデータで、すべてのプロジェクトを確実にラベル付けするオートラベラーなどのカスタムツールも活用しています。

アプリケーション チームが機能を強化するに従い、「Day 2」のサポートを維持することは最重要課題です。イベントベースのプロセスにより、セキュリティ チームは手動のエラーが発生しやすいプロセスから解放され、メンバーはより優先度の高い作業に集中できます。その結果、USAA のセキュリティ チームは、追加されるアプリケーションのオンボーディングに合わせてスケーリングできます。

まとめ

このような基本のセキュリティ レイヤをビルドしていく中で、開発者の利便性やアジリティとセキュリティ要件とのバランスを保つことに重点を置き、チームの数が増えても、ロータッチなクラウド インフラストラクチャという精神を貫いています。この記事が、Google Cloud Platform の機能の活用を検討されているお客様にとって、より安全な基盤レイヤの開拓に役立つことを願っています。

- USAA Tyler Warren

- USAA James DeLuna