はじめに

 

この記事は AWS Summit Japan 2022  5月25日(水) のセッション「 AWS-15：金融機関に求められる クラウドセキュリティの AWS 環境での実装 」に参加した時のレポートになります！

セッション概要

タイトル

金融機関に求められる クラウドセキュリティの AWS 環境での実装(AWS-15)

金融機関のお客様から、ビジネスのアジリティとセキュリティをどのように両立していくか、という課題をご相談いただく機会がここ数年増えてきています。このセッションでは、マルチアカウント管理などAWS環境で金融機関に求められるセキュリティレベルとアジリティを両立するための仕組み作りの事例や実装例をご紹介します。

スピーカー

AWS 技術統括本部 金融ソリューション本部シニアソリューションアーキテクト
能仁 信亮 氏

セッション内容

【 目的 】

• 金融機関で求められる「セキュリティレベル」を「自動化などのメカニズム」によって実現する方法の「勘所」を理解いただく

【 前提 】

• 具体的な実装方法は本セッション内の関連セッション、参考資料等ご参照ください

【 金融機関のクラウド活用における古典的な状況 】

• セキュリティ
  社会インフラを担う金融機関として、高いセキュリティ水準が求められている
• アジリティ
  ビジネス環境が急激に変化するなか、アジリティをもって新たなビジネスの起ち上げや変革が必要

高いセキュリティレベルを求めると利便性を犠牲にしなければならないのは、致し方ないところですね。
例を挙げるとデータセンターの「マントラップ」ですが、扉が2重 かつ 片方閉じないと開かない のは利便性があるとはいえません。そのような話と解釈しています。

【 AWS利用の拡大と新たな課題 】

• 金融機関のクラウド活用が急激に進んだ
• 多数のAWS環境をアジリティを確保しながら統制を取っていく「メカニズム」が求められている

AWSの上に金融系のシステムがあるのは昔からすると信じられないことだと思います。
オンプレミスで自社管理していた時と比べて、システムは「見えない」、「仮想的な閉鎖環境」に置かれているので統制も難易度が上がっているかもしれないですね。

【 統制メカニズムの方向性 】

またこのセッションテーマに関わる内容として、AWS では統制メカニズムを「ゲートキーパー」と「ガードレール」に例えて話すことが多い。

• ゲートキーパー
  • 事前承認制でガチガチな統制を取る。
    管理業務がボトルネックになりイノベーションが阻害されてしまう。
• ガードレール
  • 道路のガードレールのように事故が起きない仕組みを提供する。
    守られた環境で可能な限り自由に使わせつつ、利用者を守るためのガードレールを整備する。

【 アジェンダ 】

セキュリティとアジリティを両立するために特に重要な以下３つのポイント

• AWSアカウントの構成・統制のためのメカニズム
  安全なAWS環境をプロジェクトや部門に払い出す仕組み
• AWS環境に発見的統制を実装するためのメカニズム
  発見的統制をうまく活用してアジリティとセキュリティのバランスを取る方法について
• 安全に権限を委譲するためのメカニズム
  広範囲の権限をプロジェクトや部門へどのように委譲するのか

【 AWSアカウントの構成・統制のためのメカニズム 】

大きく分けたAWSアカウント利用方式のパターン

• シングルアカウントアーキテクチャ
  • 1つのアカウントの中で複数システムを構築する。
  • VPCやIAMによってシステム・環境の分離を行う。
    ( 金融業界では分離が厳密に求められるためアカウントは分けることが多い )
• マルチアカウントアーキテクチャ
  • 独立した小さなAWアカウントを利用したアーキテクチャ
  • AWSアカウントによってリソースや権限を明確に分離できる

金融業界では基本的にシングルアカウントアーキテクチャが少ないようです。
マルチアカウントアーキテクチャにすることで、各環境の詳細なコスト確認やアカウントの権限委譲も行えるのでマルチアカウントアーキテクチャが採用されるのも納得です。

【 どのように多数のAWSアカウントを統制するか 】

古典的には、各プロジェクトや開発環境を含め複数のAWSアカウントを払い出す。
その際、以下のような課題に対応する場合は「セキュアで事前設定済みのAWSアカウントを払い出す仕組み」が必要となる。

• 多数のAWSアカウントに対して、一定のセキュリティ水準をどのように保つか
• ログ等必要な情報をどのように一元管理するか
• アカウント払い出しに時間がかかる

【 Landing Zone の実装 】

AWSでは、「セキュアで事前設定済みのAWSアカウントを払い出す仕組み」を 「Landing Zone」と呼んでいる。

• Landing Zone とは
  • セキュアで事前設定済みのAWSアカウントを提供する仕組みの総称
  • ツールを活用してスケーラブルかつ高い柔軟性を提供
  • ビジネスのアジリティとイノベーションを実現

実装には２つの実装がある。
今回は 実装 1 についてみていく。

• 実装 1: AWS Control Tower
  • AWSサービスとして提供される Landing Zone
  • 最小限のマルチアカウント管理を迅速に開始できる
  • 特に新規にAWSを使い始める場合に有効
• 実装 2: 独自実装の Landing Zone
  • マルチアカウント戦略に基づき独自に実装する Landing Zone
  • 自社の方針に従って自由にカスタマイズ可能
  • 既に管理の仕組みがあって Control Tower の適合が難しい場合に有効

【 AWS Control Tower 】

マルチアカウント AWS環境をセットアップおよび管理するためのサービス
先ほど取り上げたマルチアカウントの課題をカバーしている。

• ログ取得の強制とアーカイブ集約
• アイデンティティ & アクセス管理
• セキュリティモニタリングの集約
• リスクあるアクションを予防/発見するガードレール
• 管理のためのダッシュボード
• 新規作成アカウントに対するベースライン統制の展開

AWS Control Tower のサービス概要ページはこちらになります。
AWS Control Tower

【事例から見た課題と解決策】

• 課題
  • セキュリティ対応が現場任せとなっており、グループ全体として組織的に取り組めていなかった。
• 解決策
  • AWS Control Tower を活用して、各アカウントのセキュリティ水準を一定レベル以上に集中管理
  • 予防的/発見的統制により、セキュリティインシデントの発生リスク低減
  • インシデント発生時の早期発見・回復を図る

セキュリティは組織全体の取り組みとして決まったルールを設けなければ意味をなさないので、全体に反映させることも重要ですね。

【 独自の統制を追加する 】

組織特有のセキュリティ要件や開発標準をどのように Landing Zone に組み込んでいくか

例)
アカウントを払い出す際に組織として標準的な構成を事前設定として払い出しを行いたい

• 解決策の例
  • 再利用可能な クラウド・ブループリントを提供
    • ユースケースごとにブループリント開発 ( ウェブアプリ、データレイク)
    • セキュリティ、コンプライアンス、レジリエンシーを事前定義
    • CCoE が開発者に向けて提供するプロダクトとして位置づけ
• 利用可能なサンプルテンプレート
  • Baseline Environment on AWS ( BLEA )

BLEA の紹介についてはこちらになります。
AWS環境にセキュアなベースラインを提供するテンプレート「Baseline Environment on AWS」のご紹介

【 AWSアカウントの構成・統制のためのメカニズム まとめ 】

• マルチアカウントアーキテクチャはベストプラクティス
• AWS Control Tower の活用
• 独自の統制の追加 ( Baseline Environment on AWS の活用など )

【 関連情報 】

• AWS Summit Japan での関連セッション
  • セキュアでスケーラブルな AWS アカウント統制プラクティス最新動向(AWS-19)
  • テンプレートによる AWS環境のガバナンス〜 Baseline Environment on AWS 徹底解説 〜(AWS-22)
• 過去のセッション
  • AWS re:Invent 2020: JPMC: Migrations at scale through cloud blueprints and automation
    動画 | 資料
• その他のリソース
  • Baseline Environment on AWS   Blog｜Github
  • ホワイトペーパー: Organizing Your AWS  Environment Using Multiple Accounts  資料

【 AWS環境に発見的統制を実装するためのメカニズム 】

【 発見的統制に関する古典的な状況と課題 】

金融機関では、セキュリティオペレーションセンター( SOC )含め、発見的統制を行う組織や仕組みを保持しており、他業界と比較しても古くから取り組みされている。

これまでの知見や仕組みを活かし、オンプレミス環境の統制からクラウドの特性を生かした発見的統制のメカニズムを考える必要がある。

金融なのでSOCもそうですが、インシデントレスポンスに対する取り組みは他の業界より積極的かもしれないですね。

【 インテリジェントな脅威検出 Amazon GuardDuty 】

• 脅威検出
• 人的コストを削減
• 既知と未知の振る舞い検知

検知例)
EC2インスタンス専用に作成された一時クレデンシャルが、AWSの外部や別アカウントで使用された際、Amazon GuardDutyが検知

Amazon GuardDuty のサービスページはこちらになります。
Amazon GuardDuty

【 AWS Security Hub セキュリティ基準】

チェックリストを基に準拠状況を手動で確認せず、 AWS Security Hub により自動で準拠状況を随時確認

対応しているコンプライアンス

• AWS Foundational Security Best Practices v1.0.0
• CIS AWS Foundations Benchmark v1.2.0
• PCI DSS v3.2.1

自動確認の内に PCI DSS が含まれているのは、金融業界にとっていいメリットですね。

【 自動修復 】

リスクが相対的に高いセキュリティイベントに対して、対応の自動化を行う
例)
クレデンシャル漏洩の可能性高いセキュリティイベントが検知された場合、クレデンシャルを無効化

自動修復自体は調査までに留め、その後の対応は人に任せるのも良いと思います。
ウイルスに感染したインスタンスがあるとして、自動で削除してしまうとデジタルフォレンジックができなくなってしまうためです。

【 AWS環境に発見的統制を実装するためのメカニズム まとめ 】

• クラウドの特性を活かした発見的統制を考える
• Amazon GuardDuty や AWS Security Hub など AWS環境の特性が考慮されている発見的統制の仕組みを利用することも有効
• APIを利用して環境操作が可能なAWS環境では、検知されたイベントに対し自動修復が可能

【 関連情報 】

• AWS Summit Japan での関連セッション
  • 運用視点で考える AWS のセキュリティ体制強化(AWS-24)
• 過去のセッション
  • AWS re:Invent 2021: Citi: Scaling security guardrail development via AWS CDK
    動画 | 資料
• その他のリソース
  • ワークショップ AWS環境における脅威検知と対応
    資料

【 安全に権限を委譲するためのメカニズム 】

【 権限委譲を行う上での考慮点 】

• アジリティの観点では、Landing Zone や 発見的統制で、一定のセキュリティレベルを保ち、チームなどに可能な限り権限を委譲することが望ましい
• ただし、金融機関では規制・内部統制の面から、無条件の権限委譲は難しいケースがある
• その制約の中で、権限委譲するための仕組み・工夫を取り上げる

【 必要な権限を一時的に払い出すメカニズム 】

• 必要な操作に対し、申請を基に一時的な権限の払い出しが考えられる
• 権限払い出しの仕組みを自動化し、かつ監査に必要な情報を収集することで、ガバナンスが効いた権限委譲を行う

リファレンス実装:
AWS環境への一時的な昇格アクセスの管理

この実装で可能なこと

• 承認を基にした一時的な権限払い出しを自動化
• セッションポリシーを利用し、セッションごとに最小権限を付与
• 申請内容に紐づけてCloudTrailログから監査するため、セッション名にユーザIDと払い出しIDを付与

これだけの規模のアクセス制御を使うシーンは限られると思いますが、承認後の一時的な権限払い出しを実現しつつ、IDを照らし合わせて監査までできるのは優れている点だと思います。

【 多様なAWSサービスの利用 】

200を超えるAWSサービスに対して、構築するシステムの特性によってセキュリティ上の考慮点を事前に確認することが望ましい場合があり、AWSサービスに対する考慮点の確認を効率的に進める仕組みが必要となる

【 セキュリティリスク評価共同化 WG 】

金融機関各社が個別に実施していたリスク洗い出し・統制機能の整理と確認を 10社の金融機関とAWSが共同で実施。

セキュリティリスクに対する対策・サービス利用時の留意事項等まとめたWGの成果物があることで、30% の工数削減の見込みが立てられた

【 安全に権限を委譲するためのメカニズム まとめ 】

• 必要な権限を一時的に払い出すメカニズムの実装
• 多様なAWSサービスを活用する上で、サービスリスク評価の共同化する仕組み

【 関連情報 】

• AWS Summit Japan での関連セッション
  • イノベーションを加速するセキュリティ〜 AWS Identity Services でビジネスの成功の礎をつくる 〜(AWS-23)
• 過去のセッション
  • AWS re:Invent 2020: How Goldman Sachs administers temporary elevated AWS access   動画｜資料

•   その他のリソース
  • AWS 環境への⼀時的な昇格アクセスの管理   Blog｜Github

【 セッションのまとめ 】

• アジリティとセキュリティの両⽴のためには、セキュリティのベスト
  プラクティスをメカニズムとして実装することが有効
•  メカニズムを実装するために AWSサービス、リファレンス実装、事
  例などを活⽤する
  • マルチアカウントの統制: AWS Control Towerなどを利⽤したLanding Zoneの構築
  • 発⾒的統制: Amazon GuardDuty、AWS Security Hub、⾃動修復などクラウドの特性を活かした発⾒的統制と対応
  • 権限委譲: 権限払い出しや監査、セキュリティ評価を⾏うための仕組み

全体的にはマルチアカウントアーキテクチャを採用しつつ、統制や安全な権限委譲のため AWS Control Tower 等があり、さらに BLEA や リファレンスアーキテクチャを活用するといった内容でしたね。
タイトル通りAWS上のセキュリティ実装を詳しく知ることができました。

まとめ

金融についてはブラックボックスなイメージがありますが、承認をして一時的に払い出すアーキテクチャ等勉強になりました。

まずは実験することから始めてみると、より体系的に理解が深まると思います。
力をつけてより複雑なソリューションにチャレンジしていきたいですね。