金融機関が機密性の高いデータのためにAWS のサービスを承認する方法

本投稿はワールドワイドで金融業界を担当しているプリンシパルソリューションアーキテクトの Ilya Epshteyn による寄稿を翻訳したものです。

グローバル展開されている金融事業グループの中でプリンシパルソリューションアーキテクトとして、私が最もよく聞かれる質問の1つは、特定の AWS サービスが 金融サービスで利用可能かどうかです。金融サービスのような規制された業界では、クラウドへの移行は単純なリフト＆シフト作業ではありません。代わりに、金融機関は、一般的にホワイトリストと呼ばれる秩序だったサービスごとの評価プロセスを使用して、クラウドサービスが規制上の義務にどのように対応できるかを実証しています。このプロセスが明確に定義されていない場合、クラウドにデータを移行する作業が遅れる可能性があります。

この記事では、最も機密性の高いデータに対するクラウドサービスのホワイトリスト化を簡素化するため、金融機関が焦点を当てるべき 5つの重要な考慮事項 で構成されるフレームワークについてご説明します。また、⾦融サービス組織がこの作業をする上で役⽴つ重要な AWS 機能についても概説します。

5 つの重要な考慮事項は、以下の通りです：

コンプライアンスの達成
データ保護
コンピューティング環境の隔離
API による監査の自動化
運用上のアクセスとセキュリティ

私がこれまで関わってきたビジネスリーダーやテクノロジーリーダーの多くにとって、俊敏性と素早い変革がクラウド化の最大の推進要因です。金融サービス機関はクラウドに移行することで、パーソナライズされたデジタルエクスペリエンスの開発、データサイロの打破、新商品の開発、既存商品の利益率の向上、グローバルなリスクとコンプライアンス要件への積極的な対応を行いやすくしています。幅広い AWS サービスを使用する AWS のお客様は、クラウド導入の段階を進むにつれて俊敏性を高めることができるようになります。幅広いサービスを使用することで、組織は差別化につながらない面倒な部分を AWS に任せて、コアビジネスと顧客に集中することができます。

私の目標は、金融サービス機関が（本番環境とミッションクリティカルなワークロードの両方で）自社の極めて機密性の高いデータをクラウドに移行することに対し、ガイドを提供することです。以下の考慮事項は、金融サービス組織がクラウドサービスへの準備状況を判断し、クラウドで成功を収めるのに役立つでしょう。

1. コンプライアンスの達成

ホワイトリストのプロセスを使用する金融機関にとっての最初のステップは、クラウドサービスプロバイダー (CSP) のサービスの基盤となるコンポーネントが、基準となるコンプライアンスのベースラインを満たせるようにすることです。これについて確信を持つための重要な前提条件は、 AWS 責任共有モデルを理解することです。責任共有とは、AWS 上でアプリケーションが安全に機能するためには、CSP としてのAWSおよびお客様との両者でのアクションが必要であることを意味します。AWS のお客様は、クラウド内のセキュリティに責任があります。お客様は、コンテンツ、アプリケーション、システム、ネットワークのセキュリティを制御および管理します。 AWS は、クラウドのセキュリティを管理し、サービスと機能の適切な運用の提供および維持し、AWS のインフラストラクチャとサービスの保護、運用上の優秀性の維持、関連する法的および規制要件を満たします。

責任共有モデルのAWS 側への信頼を確信するために、お客様は、独立した第三者監査人が作成したAWS System and Organization Controls 2(SOC 2)Type II レポートを定期的に確認することができます。AWS SOC 2 レポートには、AWS のコンプライアンスレポートにオンデマンドでアクセスするためのセルフサービスポータルである AWS Artifactを通じて、AWS機密保持契約 (NDA) に基づいてお客様が取得できる機密情報が含まれています。AWS マネジメントコンソールで AWS Artifact にサインインするか、 AWS Artifact の開始方法をご覧ください。

重要なポイント : 現在、116 の AWS サービスが SOC コンプライアンスの対象範囲にあり、組織がホワイトリスト登録プロセスを簡素化するのに役立ちます。対象範囲内のサービスの詳細については、コンプライアンスプログラムによる対象範囲内のAWSサービスを参照してください。

2. データ保護

金融機関は、包括的な情報漏洩防止戦略によって機密情報を保護しています。AWS データサービスを使用しているお客様は、暗号化を採用して、情報漏洩、機密情報の改ざん、不正アクセスのリスクを軽減できます。AWS Key Management Service(AWS KMS) を使用すると、お客様は暗号鍵のライフサイクルを管理し、アプリケーションや AWS サービスによる暗号鍵の使用方法を制御できます。AWS KMS の FIPS 140-2 検証済みハードウェアセキュリティモジュール (HSM) で暗号化キーを生成および維持できるようにすることは、ベストプラクティスであり、最もコスト効率の高い選択です。

鍵の生成と保管の柔軟性をさらに高めたいと思っている AWS のお客様であれば、AWS KMS では、独自のキーマテリアルを AWS KMS にインポートしてオンプレミスの HSM にコピーを保持するか、お客様の管理下にある専用の AWS CloudHSM インスタンスにて鍵を生成して保存することができます。これらの鍵の生成と保管のどちらのオプションに対しても、AWS のお客様は、任意のアプリケーションまたは AWS サービスが鍵を使用するためのすべてのアクセス権限を制御できます。さらに、鍵の使用またはそのポリシーの変更はすべて、監査の目的で AWS CloudTrail に記録されます。このレベルの鍵管理に関するコントロールおよび監査は、データプライバシー保護の仕組みとして暗号化を使用するよう定めた規制要件に対応するために組織が使用できるツールの 1 つです。

すべての AWS サービスは暗号化機能を提供し、金融機関が使用するほとんどの AWS サービスは AWS KMS と統合されており、組織がサービス内のデータを保護するために使用する暗号鍵を組織の側で制御できるようにします。AWS では、他の CSP の 2 倍もの多くのサービスにおいて、お客様側が制御できる鍵管理機能を提供しています。

また、金融機関は転送中のデータを暗号化して、意図した受信者だけがデータにアクセスできます。転送時の暗号化は、AWS サービスエンドポイントへの API 呼び出し、AWS サービスコンポーネント間で転送中のデータの暗号化、およびアプリケーション内での転送時の暗号化など、いくつかの分野で考慮する必要があります。最初の 2 つの考慮事項は責任共有モデルにおけるAWSの責任範囲に含まれますが、後者はお客様の責任範囲となります。

すべての AWS サービスでは、すべての API コールに使用できる Transport Layer Security(TLS)1.2 の暗号化エンドポイントを提供しています。一部の AWS サービスでは、限定された AWS リージョンになりますが、 FIPS 140-2 エンドポイントも提供しています。これらの FIPS 140-2 エンドポイントは、連邦情報処理標準 (FIPS)140-2 標準で検証された暗号化ライブラリを使用します。米国政府に代わってワークロードを運用する金融機関の場合、FIPS 140-2 エンドポイントを使用することで、必要となるコンプライアンス要件を満たすことができます。

お客様の責任範囲下にあるアプリケーション内の転送時の暗号化の設定を簡素化するために、お客様は AWS Certificate Manager(ACM) サービスを使用できます。ACMを利用すると、AWSにホストされた重要なアプリケーションエンドポイントにTLSを使用する際に、x.509 証明書のプロビジョニング、管理、デプロイを簡単に行うことができます。これらの統合により、 Amazon CloudFront、Elastic Load Balancing、Amazon API Gateway、AWS CloudFormation、AWS Elastic Beanstalkの証明書とプライベート鍵の自動デプロイ、自動ローテーションが提供されます。ACM は、アプリケーションの信頼モデル要件に応じて、パブリックに信頼された証明書とプライベート証明書の両方のオプションを提供します。組織は、既存のパブリックキーインフラストラクチャ (PKI) への投資を活用して、既存のパブリックまたはプライベート証明書を ACM にインポートすることもできます。

重要なポイント : AWS KMS では、暗号鍵のライフサイクルを管理し、50 以上のサービスで暗号鍵を使用する方法を制御できます。詳細については、 AWS KMS と統合された AWS サービスを参照してください。AWS ACM は、オンプレミス環境での自己管理する場合と比較して、PKI のデプロイと管理を簡素化します。

3. コンピューティング環境の分離

金融機関では、機密性の高いデータを含むワークロードのコンピューティングリソースの分離とネットワークトラフィック制御についての厳格な要件があります。CSP としての AWS の主なコンピテンシーの 1 つは、顧客のワークロードを保護し、それぞれを分離できることです。 Amazon Virtual Private Cloud (Amazon VPC) を使用すると、お客様は AWS 環境を制御し、他のお客様の環境から分離することができます。Amazon VPC では、Amazon Elastic Compute Cloud (Amazon EC2) ネットワーク内に論理的に独立したネットワークの区画を作成して、コンピューティングリソースとストレージリソースを格納できます。お客様は、IP アドレス、サブネット、ネットワークアクセスコントロールリスト、セキュリティグループ、オペレーティングシステムのファイアウォール、ルートテーブル、仮想プライベートネットワーク (VPN)、インターネットゲートウェイなどのプライベート環境を制御します。

Amazon VPC は、お客様のリソースを論理的に堅牢に分離する機能を提供します。例えば、ネットワーク上のすべてのパケットフローは、それが転送または配信される前に、正しい送信元と送信先であるかを個別に検証し、承認を行います。転送元および受取先のお客様両方によって明確に承認されることなく、情報が複数のテナント間で受け渡しされることは不可能です。あるパケットがそれに一致するルールがないまま送信先にルーティングされる場合、そのパケットはドロップされます。また、AWS は、カスタムハードウェアコンポーネントを搭載した専用ハイパーバイザーであるAWS Nitro System を開発しました。このハイパーバイザーは、インスタンスごとに中央処理ユニット (CPU) リソースを割り当て、たとえ本番環境のオペレータからであっても、お客様のデータのセキュリティを保護するように設計されています。

AWS Lambda などのマルチテナントコンピューティングサービスの分離モデルの詳細については、AWS Lambdaのセキュリティ概要ホワイトペーパーを参照してください。Lambda がお客様に代わって関数を実行する場合、Lambdaはコードの実行に必要なプロビジョニングとリソースの両方を管理します。Lambda 関数が呼び出されると、データプレーンはその関数に実行環境を割り当てるか、その関数に既にセットアップされている既存の実行環境を選択し、その環境で関数コードを実行します。各関数は、関数の存続期間中に使用される 1 つ以上の専用実行環境で実行され、その後破棄されます。実行環境は、ハードウェア仮想化された軽量マイクロ仮想マシン (microVM) で実行されます。microVM は 1 つの AWS アカウント専用ですが、同じアカウント内の関数全体で実行環境によって再利用できます。実行環境が関数間で共有されることはありません。また、microVM が AWS アカウント間で共有されることもありません。AWS はハイパーバイザーセキュリティの分野で革新を続けており、リソースを分離することで、金融サービスのお客様は AWS クラウド内で最も機密性の高いワークロードでも安心して実行できます。

ほとんどの金融機関では、トラフィックは可能な限りプライベートに維持され、（インターネットを経由するワークロードなど）特に必要で無い限りAWS ネットワークから離れないようにする必要があります。トラフィックをプライベートに保つため、お客様は Amazon VPC を使用して、組織のニーズに合わせてクラウドの隔離されたプライベート部分を構築できます。VPC を使用すると、お客様はアプリケーションの層に基づいてセグメント化された独自の仮想ネットワーク環境を定義できます。

VPC の外側で実行される AWS リージョン固有のサービスに接続するために、VPC エンドポイントを使用すると、VPC 内のリソースと対応している AWS サービス間のプライベート接続が可能になります。エンドポイントは、高可用性、冗長性があり、スケーラブルなマネージド型仮想デバイスです。エンドポイントは、プライベート IP アドレスを使用することで、お客様の VPC と AWS のサービス間のプライベート接続を可能にします。VPC エンドポイントを使用すると、VPC のプライベートサブネットで実行されている Amazon EC2 インスタンスは、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要とせずに、リージョン固有のリソースにプライベートアクセスできます。さらに、お客様がエンドポイントを作成するときに、エンドポイントの使用を制御するポリシーをアタッチすることで、AWS アカウント内の特定の Amazon Simple Storage Service (Amazon S3) バケットなど、特定の AWS リソースにのみアクセスできるように制限できます。同様に、リソースベースのポリシーを使用することで、お客様は VPC エンドポイントからのアクセスのみを許可するようにリソースへのアクセスを制限できます。例えば、バケットポリシーを使用することで、お客様は特定の Amazon S3 バケットへのアクセスをエンドポイントを通じてのみ許可するよう制限できます。これにより、トラフィックはプライベートに保たれ、パブリックアドレス空間を通過することなく、エンドポイントのみを通過することを確実にできます。

重要なポイント : お客様がトラフィックをプライベートに保つために、45 を超える AWS サービスが VPC エンドポイントをサポートしています。

4. API による監査の自動化

ユーザーアクティビティやリソースの設定変更を可視化することは、IT ガバナンス、セキュリティ、コンプライアンスにおける重要なコンポーネントです。オンプレミスのログ管理ソリューションでは、エージェントのインストール、設定ファイルとログサーバーのセットアップ、およびデータを保存するためのデータストアの構築と保守が必要です。この複雑さにより、可視性が低下し、モニタリングスタックが断片化され、問題のトラブルシューティングと問題解決に時間がかかります。CloudTrail は、AWS API の呼び出しとリソースの変更をクラウドに記録するためのシンプルで一元化されたソリューションを提供し、この負担を軽減します。

CloudTrail は、お客様の AWS アカウントのアクティビティ履歴を提供し、社内ポリシーや規制基準のコンプライアンス要件への適合を支援します。CloudTrail は、誰がどのアクションを実行したか、どのようなリソースが実行されたか、どのようなリソースが処理されたか、イベントの発生日時、およびその他の詳細を識別し、お客様が AWS アカウントのアクティビティを分析して対応するのに役立ちます。CloudTrail 管理イベントは、AWS アカウントのリソースで実行される管理（コントロールプレーン）オペレーションについての洞察を提供します。例えば、お客様は Amazon EC2 インスタンスの作成、削除、変更などの管理アクションを記録できます。イベントごとに、AWS アカウント、IAM ユーザーロール、アクションを開始したユーザーの IP アドレス、アクションの時間、影響を受けるリソースなどの詳細情報を受け取ります。

CloudTrail データイベントは、リソース自体またはその内部で実行されるリソース（データプレーン）オペレーションについての洞察を提供します。データイベントは、多くの場合、膨大な量のアクティビティであり、Amazon S3 オブジェクトレベル API や AWS Lambda 関数呼び出し API などのオペレーションが含まれます。例えば、お客様は Amazon S3 オブジェクトに対する API アクションを記録することで、AWS アカウント、IAM ユーザーロール、発信者の IP アドレス、API 呼び出しの時間などの詳細情報を受け取ることができます。また、Lambda 関数のアクティビティを記録することで、Invoke API 呼び出しを行った IAM ユーザーまたはサービス、呼び出しが行われた時間、実行された関数など、Lambda 関数の実行に関する詳細を受け取ることもできます。

継続的に行われるコンプライアンスと監査を簡素化するために、AWS では AWS リソースの設定の評価、監査、評価に役立つ AWS Config という独自のサービスを提供しています。AWS Config では、AWS リソースの設定を継続的にモニタリングおよび記録を行っており、お客様は内部ガイドラインに照らして記録された設定の評価を自動化できます。AWS Config を使用すると、お客様は AWS リソース間の設定や関係の変更を確認し、詳細なリソース設定履歴を掘り下げることができます。

重要なポイント : 160 を超える AWS のサービスが CloudTrail と統合されています。これにより、AWS アカウント内のアクティビティ履歴を提供することで、お客様は社内ポリシーや規制基準に準拠できるようになります。特定の AWS サービスで CloudTrail を使用する方法の詳細については、CloudTrail ユーザーガイドの CloudTrail の AWS サービストピックを参照してください。特定の環境で AWS Config を有効にする方法の詳細については、AWS Config の開始方法を参照してください。

5. 運用上のアクセスとセキュリティ

金融機関との話し合いの中で、お客様のデータへのアクセスについて明確に理解することが求められていることを AWS にお伝えいただくことがよくあります。これには、不正なアクセスが発生しないように、どのようなコントロールが実施されているかを把握することが含まれます。AWS では、承認された個人のみがお客様のコンテンツが存在する本番環境にアクセスできるように、予防的および発見的対策を用いた多層的なコントロールを実装しています。アクセスとセキュリティコントロールの詳細については、AWS Artifact から AWS SOC 2 レポートを参照してください。

AWS セキュリティの基本的な設計原則の 1 つは、リスクを最小限に抑えるために人間をデータから遠ざけることです。その結果、AWS は AWS Nitro System と呼ばれるまったく新しい仮想化プラットフォームを作成しました。この非常に革新的なシステムは、パフォーマンスとセキュリティの両方を劇的に向上させる、新しいハードウェアとソフトウェアを組み合わせたものです。AWS Nitro System では、お客様のワークロードが実行されるメインシステムボードから専用のハードウェアとソフトウェアに仮想化とセキュリティ機能がオフロードされるため、攻撃対象領域を最小限に抑えてセキュリティを強化できます。さらに、AWS Nitro System のロックダウンセキュリティモデルでは、Amazon の従業員によるものを含むすべての管理アクセスを禁止しているため、人為的なエラーや改ざんの可能性を排除できます。

重要なポイント : AWS Artifact で利用可能な第三者監査人レポート（SOC 2 Type II を含む）を確認し、 AWS Nitro Systemの詳細を確認してください。

まとめ

AWS は、金融サービス機関がクラウドに移行するためのホワイトリスト登録プロセスを簡素化し、迅速化することを支援します。組織が幅広く AWS サービスを活用することで俊敏性を最大化し、AWS サービスに組み込まれている既存のセキュリティおよびコンプライアンス対策を活用してホワイトリスト作業を完了することができれば、金融サービス組織がコアビジネスと顧客に集中できるようになります。

組織がホワイトリストのプロセスを完了し、どのクラウドサービスをアーキテクチャの⼀部として使⽤できるか決定できれば、AWS Well-Architected フレームワークを活用することにより、安全で、耐障害性があり、パフォーマンスが⾼く、コスト効率に優れたアーキテクチャを AWSに構築し運⽤することができます。

また、AWS には、金融サービスの専門家からなる専任チームがあり、複雑な規制状況を理解するためのご支援や、お客様が移行プロセスのどの段階であっても、クラウドへの移行に役立つリソースもご用意しています。詳細につきましては、 AWS 金融サービスのページをご参照頂くか、 AWS 金融サービスのお問い合わせフォームにご記入ください。

その他のリソース

AWS セキュリティドキュメント
セキュリティドキュメントリポジトリは、セキュリティとコンプライアンスの目標を達成するために AWS サービスを設定する方法を示しています。クラウドセキュリティは AWS の最優先事項です。AWS のお客様は、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターおよびネットワークアーキテクチャをご活用頂くことができます。
AWS コンプライアンスセンター
AWS コンプライアンスセンターは、お客様が運用している地域でのクラウド使用に関して、国固有の要件と特別な考慮事項を提供するインタラクティブなツールです。AWS コンプライアンスセンターには、特定の国のクラウド導入を支援する AWS リソースへのクイックリンクがあり、これらの管轄区域に適用されるコンプライアンスプログラムの詳細が掲載されています。AWS コンプライアンスセンターは多くの国を対象とし、テクノロジーの使用に関する規制要件を更新するにつれて追加される国は増え続けています。
AWS Well-Architected フレームワークと AWS Well-Architected Tool
AWS Well-Architected フレームワークは、AWS でシステムを構築する際にお客様が行なった決定について、長所と短所を理解するのに役立ちます。AWS Well-Architected Tool は、ワークロードの状態を確認し、最新の AWS アーキテクチャのベストプラクティスと比較するのに役立ちます。AWS Well-Architected フレームワークとセキュリティの詳細については、セキュリティの柱 -AWS Well-Architected Framework ホワイトペーパーを参照してください。

翻訳はソリューションアーキテクトの澤野佳伸が担当しました。原文はこちらです。

Amazon Web Services ブログ