寄稿： AWS サービス利用時のセキュリティリスク評価手法と共同化の取り組み

本稿は、株式会社みずほフィナンシャルグループ／みずほリサーチ＆テクノロジーズ株式会社 服部 純一氏、畑山 洋平氏、浅香 樹氏、株式会社みずほフィナンシャルグループ 島浦 紳吾氏、翁 恒氏によって寄稿いただきました。

はじめに

企業のデジタル化が進み、クラウド活用の拡大を含め多くの業種で IT 予算、投資意欲が高まっています。 「企業 IT 動向調査報告書2024」によると、2023年度の IT 予算 DI 値(注1)は2011年度以降で最高値となっています。 IT 予算の重点領域として「セキュリティ強化」は「業務プロセスの効率化」に次いで高くなっていること、2022年度から割合を伸ばしていることからも企業のセキュリティに対する意識は高まっていると考えられます。 (注1) Diffusion Index ： IT 予算を「増加する」割合から「減少する」割合を差し引いた値

パブリッククラウドは、いまやビジネスに欠かせない IT インフラとなっています。アマゾン ウェブ サービス (AWS) は、俊敏性が高く、従量課金制で最先端のサービスを利用可能なため、アイデアをすぐにビジネスとして実現できイノベーションを加速できます。一方で、利便性が高いため、利用者は自身の管理領域の設定ミスなどによる情報漏洩などのリスクがあります。 そのため、責任共有モデルを正しく理解し、セキュリティ統制と対策を行う必要があります。

本ブログでは、AWS サービス利用時のセキュリティリスク評価とその対策として予防的統制と発見的統制の手法について紹介したいと思います。

AWS サービス利用時のセキュリティリスク評価の必要性と評価手法

パブリッククラウドは最先端のサービスを利用できる俊敏性が高い IT インフラです。一方で、設定や権限管理の不備に起因する事例も存在しています。 AWS を活用するうえで、責任共有モデルを前提としたセキュリティ・リスクマネジメントは不可欠となります。 <みずほ>では、 AWS サービスを安心・安全に活用するためのプロセスとして、(1) サービスを知る（ AWS ドキュメントや AWS Black Belt Online Seminar からサービスを把握する）、(2) リスクを知る（機密性・完全性・可用性それぞれの観点で整理する）、(3) 対策を練る（AWS Identity and Access Management (IAM) による権限管理や VPC エンドポイントでの通信経路の特定等）、(4) 対策を施す（予防的統制・発見的統制）を実施しています。

AWS サービス利用時のセキュリティリスク評価にあたり「利用シナリオと接続経路」、「セキュリティクライテリア」、「IAM アクション評価」を作成しています。 「利用シナリオと接続経路」は AWS サービスの使われ方を想定し、それぞれの利用者や関連するサービス、外部システムとの通信経路と通信方向を図示したものです。 「セキュリティクライテリア」は主要なリスクシナリオをベースにクラウド固有のリスクについて、AWS で実施可能な対策を整理したものです。機密性、完全性、可用性を観点として、セキュリティリスクに関する7評価観点19対策分類を定め、評価対象の AWS サービスで利用可能な予防的統制と発見的統制の情報を整理しています。 「IAM アクション評価」では、AWS サービスの IAM アクションを洗い出し、IAM アクションごとにセキュリティリスクを評価し、予防的統制と発見的統制を整理しています。

セキュリティリスク評価事例： AWS Lambda

AWS ユーザーの多くの方が利用する AWS Lambda を題材にセキュリティリスク評価の手法をご紹介したいと思います。

利用シナリオと接続経路

金融機関は個人情報や決済情報など、多くの機密データを扱っています。想定外のインターネット経由の接続経路（例：外部 AWS アカウントからの不正なリモートアクセス経路など）が存在すると、不正アクセスによる機密情報の漏洩などにより業務停止を引き起こし、結果として顧客への影響や事業運営全体に深刻なリスクをもたらす可能性があります。 本観点では、AWS サービスの通信経路を洗い出し、どのようなアクセスがあるかを明らかにすることで、リスクとなる箇所を明確にすることを目的としています。 ネットワーク構成やセキュリティ要件を考慮しながら、AWS サービスを利用する場面で具体的な指針を示しています。
AWS Lambda では、①Lambda 関数の管理と ②Lambda 関数の実行という2つの主要な観点に基づいて構成されています。

以下は、そのうちの ①Lambda 関数の管理の例です。

このように、通信元 / 通信先 / 通信の目的 / 通信経路 をもとに整理し可視化することで、アクセスルートに応じた権限や各種設定の具体的な考慮点を明らかにしています。

セキュリティクライテリア

本観点では、AWS サービスを運用する際に懸念されるセキュリティリスクを洗い出し、それに対する対策を整理することで、セキュリティ要件を満たしたシステム設計・運用に繋げることを目的としています。
以下の7評価観点・19対策分類で整理し、「予防的統制」と「発見的統制」の両側面から、具体的な設計・運用レベルでの対策を確認できるような構成としています。

以下は、そのうちの No.4 その他機能による保護の例です。

チェックリストのように評価観点とそれに対する予防的統制と発見的統制による対策を明らかにしています。

IAM アクション評価

本観点では、その時点における AWS サービスの IAM アクションを洗い出し、それぞれの具体的なリスクと統制内容を明らかにすることで、実装に繋げることを目的としています。
IAM アクションごとに、以下の観点で想定リスクを洗い出し、それに対するリスク低減方法を確認できるような構成としています。

[A] 権限が不正に利⽤され、データ持ち出しや破壊されるリスク
[B] データの保管場所や伝送経路が危殆化した際にデータの持ち出しや破壊されるリスク
[C] IP-NW 経由でのデータ持ち出しや破壊されるリスク
[D] クラウドサービスの機能が悪⽤され、データ持ち出しや破壊されるリスク
[E] 不正な操作やアクセスが検出ないしは記録されないリスク
[F] 障害時にデータが失われるリスク
[G] 障害時に業務継続性が失われるリスク
[H] 多額の請求が発生するリスク( Savings Plans の契約など)
[I] その他のリスク

以下の画像は、AWS Lambda の IAM アクション一部抜粋です。

例えばlambda:CreateEventSourceMappingとlambda:CreateFunctionであれば以下のようにリスクと対策をまとめています。

• lambda:CreateEventSourceMapping
  • 想定されるリスク [H]
    • 高頻度のイベント発生など大きくリソース使用量を増加させるようなイベントソースのマッピングが作成され、それを処理する Lambda 関数が実行された場合に、多額の請求が発生するリスクがある
  • リスク低減方法の例 [H]
    • アイデンティティベースとリソースベース、または SCP によるセキュリティ設定を適切に統制すると共に、CloudTrail などで変更を検知する
  • 参考
    • イベントソースの実行ロールを最小限の権限設定とするなど、イベントソース側の権限も適切に統制する
• lambda:CreateFunction
  • 想定されるリスク [D]
    • VPC アクセスを指定せずに Lambda 関数を作成した場合、インターネットへアウトバウンド通信する経路が Lambda 関数を経由して生成されるリスクがある
  • 想定されるリスク [G]
    • VPC アクセスを指定して Lambda 関数を作成した際に、複数の AZ で構成されるように複数のサブネットを指定しなかった場合、AZ (単一)障害時に、業務継続性が失われるリスクがある ※不適切あるいは悪意のあるコードを含む Lambda 関数が作成されるリスクがある。詳細は右記「参考」を参照
  • リスク低減方法の例 [D]
    • ドキュメントの例のように VPC に接続された関数の作成のみを許可する
    • AWS Config で Lambda 関数リソース、VPC リソースへの変更を検出、CloudTrail での関連API呼び出しを検知する
    • VPC 設定により Lambda 関数のアウトバウンド通信を制限し適切に監視・制御する
  • リスク低減方法の例 [G]
    • VPC Lambda とする場合、複数のAZで構成されるように複数のサブネットを指定する
    • サービスヘルスダッシュボードで、サービスの状態を確認する
    • アプリケーションとしてのログ、CloudWatch メトリクスをモニタリングする
  • 参考 不適切あるいは悪意のあるコードを含む Lambda 関数が作成され、その関数が実行された場合、以下のようなリスクが想定される
    • 関数ハンドラにて、AWS リソースを使って、ユーザー所有データを破壊あるいは AWS 内外の不適切な場所に送信し持ち出す [A][B][C]
    • Lambda 関数あるいは依存する Lambda レイヤー内のライブラリやコードにセキュリティ脆弱性を含むレイヤーバージョンが作成された場合、これを悪用されてデータの持ち出しや破壊されるリスクがある [D]
    • 大きくリソース使用量を増加させ、多額の請求を発生させる[H]
    • 関数ハンドラにて、外部サイトへの攻撃や犯罪行為などを行い、意図せず犯罪に巻き込まれ、法的責任を問われ、信用失墜や損害賠償請求などにより、ビジネスへの影響が生じる[I]

    <リスク低減方法の例> [共通]

    • アイデンティティベースとリソースベース、または SCP によるセキュリティ設定を適切に統制すると共に、CloudTrail などで変更を検知する
    • CI/CD パイプラインを導入するなど、第三者が介入できないコード作成、デプロイ自動化と承認のプロセスを確立し、アプリケーションの適切な開発・運用管理を行う
    • 関数作成の IAM ポリシーの条件として、特定の署名コード設定付き関数しか作成できないよう制限する（参考ドキュメント）
    • Inspector を利用して、ワークロードに作成・変更時(初回作成、更新、CVE 公開)があったときに自動的に再スキャンするよう設定する[D]

このように、IAM アクションごとにリスクの有無を整理することで、具体的な実装方法を明らかにしています。

セキュリティリスク評価による効果

セキュリティリスクの洗い出しやその対策を整理することで、各サービス利用時のリスク評価が可能になります。リスクとなる点は予防的統制による制限、発見的統制による検知の仕組みを導入します。一方で、相対的にリスクが低く評価される点については、権限移譲による利便性を高めることができ、より安心・安全にサービスを利用することが可能になります。

<みずほ>ではサービスごとのリスク評価に際して、本取り組みの内容をベースとし、セキュリティ基準を踏まえた評価を盛り込むことでサービスの評価として活用しています。また、実機検証や AWS サポートを活用し、セキュリティリスク評価と実装の精度を高める取り組みを取り入れています。 <みずほ>ではサービス評価のフェーズでは、アーキテクトだけでなくリスク管理部門といった2線部門(注2)とも連携を取りながら進めています。また、サービス評価完了後はシステムを所管するユーザー部門が設計・構築において参照したいといった要望挙がるなど、それぞれ異なる視点やニーズを持っています。本取り組みの成果物は、全員が共通理解を持つためのドキュメントとしても活用しています。 (注2)リスク管理・コンプライアンス所管部署：1線が行う自律的な統制活動を監視（モニタリング）・測定・評価するとともに、リスク管理・コンプライアンスの統制に係る基本方針等を策定・推進する責任を有する。

取り組み： AWS サービスリスク評価ワーキンググループについて

AWS サービス利用時のセキュリティリスク評価を行うワーキンググループとして、現在11社、9金融グループ共同で評価する取り組み（セキュリティリスク評価ワーキンググループ）を行っています。 これまでの活動実績として2020年7月の第1回目以降、継続的に開催しており、2025年2月末時点で88回のワーキンググループを開催し、45の AWS サービス・シリーズについてリスク評価を実施してきました。また、AWS サービス利用時のリスク評価以外に、参加企業間での事例共有をテーマとした情報交換会も定期的に実施しています。

ワーキンググループでは、セキュリティリスク評価対象サービスについて参加企業各社のユースケースを共有し、AWS で「利用シナリオと接続経路」と「セキュリティクライテリア」を作成した後、参加企業各社がレビューを行います。参加企業によるレビューにより成果物をブラッシュアップし、質疑応答によりサービス仕様の理解を深めています。 セキュリティリスク評価について取り組み始めた頃は、これら全てを<みずほ>自身で実施していたため、多大な工数・期間を要していました。それが本取り組みにより、セキュリティリスク評価におけるベース部分の体力削減ができると共に、網羅性の観点でも高めることでき、より効率的にサービス評価が可能となりました。

AWS サービスリスク評価ワーキンググループの活用

ワーキンググループは、金融機関各社が個別に行っていたAWSサービス利用時のリスク評価を共同で実施することで、作業負荷の軽減と評価の網羅性向上を図る取り組みです。 これからサービス利用時のセキュリティリスク評価を行う参加企業ではリファレンスとして、既にセキュリティリスク評価が済んでいる企業では、評価の観点や判断軸を客観的に捉えることが出来るとの声があります。

ワーキンググループでは事例共有の場を設けており、自動化ツールや標準化の仕組み、IAM 設定などの具体的ノウハウを共有する場を定期的に設けています。AWS CloudFormation や AWS Service Catalog 等の活用事例、クロスアカウント間でのデータ連携など、各社の実運用で培った知見が共有されることで、セキュリティ水準の向上にも繋がっています。

まとめ

AWS を含むパブリッククラウドは最先端のサービスを利用できる俊敏性が高い IT インフラです。一方で、設定ミスなどによる情報漏洩などのリスクも存在するため、責任共有モデルを正しく理解しセキュリティ統制と対策を行う必要があります。
金融機関でのセキュリティリスク評価共同化ワーキンググループのような手法は、多数の AWS サービス評価を効率的に進め、網羅性を高める有効な取り組みとして機能しています。

また、セキュリティリスク評価ワーキンググループの活動にご興味がありましたら、AWS 担当営業経由でご連絡ください。

免責文言

本稿は情報提供のみを目的として作成されたものであり、取引の勧誘を目的としたものではありません。本稿は、株式会社みずほフィナンシャルグループ／みずほリサーチ＆テクノロジーズ株式会社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を保証するものではありません。本稿のご利用に際しては、ご自身の判断にてなされますようお願い申し上げます。また、本稿に記載された内容は予告なしに変更されることもあります。

執筆者情報

参考情報

• AWS Lambda 開発者ガイド
• AWS Lambda APIリファレンス