KIM JAEWON

【ASW22-01】クラウドコンピューティングにおけるSTAMP/CASTを用いた分析事例の紹介

Transcript

1. Capital Oneの個人情報流出事件について 金子研究室 4年 KIM JAEWON クラウドコンピューティングにおける STAMP/CASTを用いた分析事例の紹介 2024/12/05 第６回AI/IoTシステム安全性シンポジウム 【ASW22-01】
2. 何が起こったのか？ 2 ー発生時期：2019 年 3 月 22 日と 23 日 ー発見時期：2019 年 7 月 19 日 ー被害範囲：米国の約一億人、カナダの約６００万人の個人データ流出 ー流出された情報： ・クレジットカード顧客の社会保険番号 ・顧客ステータスデータ（例：信用スコア、信用限度額、残高、支払い 履歴、連絡先情報） ・住所、勤務先、職業などの個人情報 ・2016年、2017年、2018年の合計23日間の取引データの断片
3. 顧客情報の流出が可能になった連鎖的侵入経路 3 １。 攻撃者はServer-Side Request Forgery (SSRF)の脆弱性を利用して、 EC2インスタンスメタデータ(IMDSv1)にアクセスしした。 ２。 IMDSv1は認証なしでアクセス可能だったため、攻撃者は容易にIAMロー ルの一時的な認証情報が取得できた。 ３。 IMDSv1から取得した一時的な認証情報を使用して、S3バケット内の 機密データにアクセスした。 ４。取得した認証情報には、S3バケット内のデータを復号化するために必要 な暗号化キーへのアクセス権限が含まれており、復号化できた。
4. SSRF攻撃とは 4 ＊出典：https://cybersecurity-jp.com/column/33568
5. Copyright 2010, Soka University, All Rights Reserved. 5
6. この事件に関して仮説と検証 6 •クラウドサービスにおける技術的脆弱性（EC2やS3バケットなど）により、事 故が起こった場合 →クラウド事業者に責任がある。 •ユーザ権限設定ミス（鍵管理ミス）により、事故が起こった場合 →クラウド利用者に責任がある。 仮説 仮説検証 •CAST分析を通してクラウド事業者と利用者の責任モデルを確認し、脆弱 性をどう解決できるか提案する。
7. CAST1,2）事故情報の把握（基本情報の収集） Copyright, Soka University, All Rights Reserved. 7
8. CAST1,2）事故情報の把握（基本情報の収集） Copyright 2010, Soka University, All Rights Reserved. 8 ・アクシデント A1：EC2インスタンスのメタデータにアクセスする ・ハザード H1：IMDSv1が使用されており、IMDSv2のようなアクセス制限がなかった。 H2：Webアプリケーションの脆弱性が残り、攻撃者が公開サーバーから不正なリク エストを実行可能だった。 ・安全規約 SC1：クラウド事業者と利用者は、IMDSv1ではなく、トークンベース認証を要求 するIMDSv2を使用するよう徹底するべきである SC2: 異常なアクセスパターンや権限昇格の試みを検出できるよう、不正侵入検 知ツールやWAFを活用する。 SC3: 開発やテスト段階でSSRF脆弱性を検出し、適切に対応する。
9. CAST1,2）事故情報の把握（基本情報の収集） Copyright 2010, Soka University, All Rights Reserved. 9 ・アクシデント A2: 一時的なIAM認証情報を取得する ・ハザード H4:EC2インスタンスに割り当てられたIAMロールが、S3や暗号化キーへの過剰な アクセス権を持っていた。 ・安全規約 SC2: 異常なアクセスパターンや権限昇格の試みを検出できるよう、不正侵入検 知ツールやWAFを活用する。
10. CAST1,2）事故情報の把握（基本情報の収集） Copyright 2010, Soka University, All Rights Reserved. 10 ・アクシデント A3:取得した認証情報を用いてS3バケットに保存された機密デー タを復号し、不正に取得する ・ハザード H6:一時的な認証情報には復号に必要なキーが含まれていた。 ・安全規約 SC6: 復号に必要なキーは別管理とし、一時的な認証情報だけで直接アクセスで きないようにする。
11. CAST1,2）事故情報の把握（基本情報の収集） Copyright 2010, Soka University, All Rights Reserved. 11 ・アクシデント A4:長期間に渡って不正アクセスや異常な活動が行なっていた ・ハザード H7: 不正アクセスや異常な活動をリアルタイムで検知できない ・安全規約 SC2: 異常なアクセスパターンや権限昇格の試みを検出できるよう、不正侵入検 知ツールやWAFを活用する。
12. CAST4） 事故情報の把握（基本情報の収集） Copyright, Soka University, All Rights Reserved. 12
13. CAST4） 事故情報の把握（基本情報の収集） 13 ・何が起きたのか 不正アクセスによるデータ漏洩:攻撃者はEC2インスタンスメタデータ (IMDSv1)に アクセスした。 ・原因究明のため明らかにしたいこと Q 0-1.なぜ、不正侵入検知されずに攻撃者はWAFを通過できたのか？ -WAFの設定にどのような不備があったのか？ -WAFの設定は定期的に見直されていたのか？ Q 0-2.なぜ、攻撃者はEC2インスタンスにアクセスできたのか？ -公開サーバーの設定に問題があったのか？ -不適切なアクセス権限が与えられていたのか？
14. CAST4） 事故情報の把握（基本情報の収集） 14 ・何が起きたのか 不正アクセスによるデータ漏洩:IAMロールの誤設定により、攻撃者がS3にアクセス し、データを漏洩した ・原因究明のため明らかにしたいこと Q 0-3.なぜ、攻撃者はS3にアクセスできたのか？ -IAMロールの設定にどのような問題があったのか？ -S3のアクセス制御ポリシーに問題があったのか？
15. CAST4） 事故情報の把握（基本情報の収集） 15 ・何が起きたのか 不適切なIAMポリシー設定:過剰な権限が与えられており、攻撃者がデータにアク セスできた。 ・原因究明のため明らかにしたいこと Q 1-1.なぜ、IAMポリシーに過剰な権限が設定されていたのか？ -IAMポリシーの設定手順に問題があったのか？ -定期的なレビューや監査が行われていたのか？ Q 1-2.なぜ、最小権限の原則が適用されなかったのか？ -IAMポリシーの設定に対するベストプラクティスが遵守されていなかったのか？ -クラウド利用者に対しての教育やトレーニングに問題があったのか？
16. CAST4） 事故情報の把握（基本情報の収集） 16 ・何が起きたのか ログ管理の不備:不正アクセスや異常な活動をリアルタイムで検知できなかった。 ・原因究明のため明らかにしたいこと Q 2-1.なぜ、不正アクセスや異常な活動をリアルタイムで検知できなかったのか？ -ログ管理システムに問題があったのか？ -ログの収集や分析が適切に行われていたのか？ -異常検知アルゴリズムやルールに問題があったのか？ Q 2-2.なぜ、ログの監視やアラートが機能していなかったのか？ -ログ監視システムの設定や運用に問題があったのか？ -クラウド利用者側の運用管理チームの対応手順やプロセスに問題があったのか？
17. CAST5）具体的な事象（物理モデルの分析） Copyright, Soka University, All Rights Reserved. 17 ・クラウド事業内部者 ・不正侵入検知 ・クラウド事業者側の運用管理チーム ・ EC2のIMDS ・S3バケット ・クラウド利用者側の取締役会 ・WAF ・IAM ・公開サーバ ・クラウド利用者側の運用管理チーム
18. コンポーネント：クラウド事業内部者 Copyright 2010, Soka University, All Rights Reserved. 18 ーインシデント発生対象 ・内部者による不正アクセスや機密情報の持ち出し。 ・内部の管理者権限を持つ従業員が不正行為を行う可能性。 ー安全上の責務（責任） ・従業員のアクセス権限を最小限に制限する。 ・内部者の行動を監視するログ監査システムを導入する。 ・退職時にすぐに権限を剥奪する。 ー非安全なコントロールアクション ・不要な管理者権限を維持したままにする。 ・内部者の行動を記録・監査しない。
19. コンポーネント：EC2のIMDS（Instance Metadata Service） Copyright 2010, Soka University, All Rights Reserved. 19 ーインシデント発生対象 ・IMDSv1を使用していたため、SSRF攻撃でメタデータが不正に取得される。 ・IMDSに保存された一時的な認証情報が漏洩。 ー安全上の責務（責任） ・IMDSv2を使用し、トークン認証を有効化する。 ・EC2インスタンスのIAMロールの権限を最小限に設定する。 ・セキュリティグループを設定して、外部アクセスを制限する。 ー非安全なコントロールアクション ・IMDSv1を使い続ける。 ・IAMロールに過剰な権限を付与する。
20. コンポーネント：Web Application Firewall (WAF) Copyright 2010, Soka University, All Rights Reserved. 20 ーインシデント発生対象 ・WAF設定のミスで不正リクエストが通過。 ・重要なトラフィックパターンを見逃し、攻撃の早期検知に失敗。 ー安全上の責務（責任） ・適切なルールとポリシーを設定し、不正リクエストをブロック。 ・定期的にWAF設定を更新し、新しい攻撃パターンに対応する。 ・WAFログを監視して異常な動きを検出する。 ー非安全なコントロールアクション ・WAF設定を定期的に見直さない。 ・トラフィックモニタリングを怠る。
21. コンポーネント：公開サーバー Copyright 2010, Soka University, All Rights Reserved. 21 ーインシデント発生対象 ・SSRF攻撃により、公開サーバーが内部ネットワークやクラウドサービス（例： AWS EC2 Metadataサービス）に不正アクセスを送信。 ・不正なリクエストを介して、機密情報（例：認証トークンやAPIキー）が漏洩 ー安全上の責務（責任） ・Webアプリケーションでリクエスト検証を実施してSSRFを防ぐ。 ・公開サーバーに最小限の権限を付与する。 ー非安全なコントロールアクション ・公開サーバーに過剰なアクセス権限を付与。 ・リクエスト検証を怠る。
22. コンポーネント：不正侵入検知（IDS） Copyright 2010, Soka University, All Rights Reserved. 22 ーインシデント発生対象 ・不正侵入検知システム (IDS) が攻撃の兆候を見逃す。 ・侵入後の異常な振る舞いを検出できない。 ー安全上の責務（責任） ・IDSを適切に構成し、異常なパターンをリアルタイムで検知する。 ・IDSログを定期的に確認し、アラートを分析する。 ・IDSのルールセットを最新の状態に保つ。 ー非安全なコントロールアクション ・IDSログの確認を怠る。 ・古いルールセットを使い続ける。
23. コンポーネント：S3バケット Copyright 2010, Soka University, All Rights Reserved. 23 ーインシデント発生対象 ・EC2インスタンスのIAMロールの一時的な認証情報が取得され、不正にS3バケットにアクセスされる。 ・IAMロールに付与された過剰な権限により、機密データの読み取りや暗号化キーへのアクセスが可能になる。 ・S3バケットの適切なアクセス制御ポリシーが設定されておらず、機密情報が漏洩する。 ー安全上の責務（責任） ・EC2インスタンスでIMDSv2（Instance Metadata Service Version 2）を使用し、認証なしでのメタデータアクセスを防止 する。 ・IAMロールのポリシーを最小権限に設定し、必要最小限のリソースへのアクセス権限のみを付与する。 ・S3バケットポリシーを構成して、特定のIPアドレスやVPC内のリクエストのみを許可する。 ・機密データを暗号化し、暗号化キーの管理をAWS Key Management Service (KMS)を使用して行う。 ・S3アクセスログを監視して不正アクセスを早期に検知する。 ・バケット内のデータへのパブリックアクセスを禁止し、必要な場合には一時的なURL（Presigned URL）の利用に限定する。 ー非安全なコントロールアクション ・IMDSv1を使用したまま放置し、認証なしでのメタデータアクセスを許可していた。 ・IAMロールにS3全体への過剰な権限を付与した。 ・S3バケットポリシーやアクセス制御リスト（ACL）の設定ミスにより、意図しないユーザーがアクセス可能だった。 ・S3バケットアクセスログを有効化せず、不審なアクセスを検知できなかった。
24. コンポーネント：IAM（Identity and Access Management） Copyright 2010, Soka University, All Rights Reserved. 24 ーインシデント発生対象 ・IAMポリシーのミスで過剰な権限が付与される。 ・不正に取得されたIAMロールの認証情報で機密データにアクセスされる。 ー安全上の責務（責任） ・最小権限の原則を適用したIAMポリシーを設計する。 ・IAMポリシーとアカウントの使用状況を定期的に監査する。 ・Multi-Factor Authentication (MFA) を有効化する。 ー非安全なコントロールアクション ・IAMロールに広範囲の権限を付与。 ・MFAを適用せず、認証情報漏洩に無防備。
25. コンポーネント：クラウド利用者側の運用管理チーム Copyright 2010, Soka University, All Rights Reserved. 25 ーインシデント発生対象 ・セキュリティ設定や権限の管理不足。 ・侵入検知やログ監査を怠る。 ー安全上の責務（責任） ・セキュリティベストプラクティスを順守する。 ・定期的なセキュリティ監査を実施し、設定ミスを修正する。 ・侵入検知や脆弱性管理を継続的に行う。 ー非安全なコントロールアクション ・セキュリティ設定を確認・更新しない。 ・侵入検知やログ監査のプロセスを実施しない。
26. コンポーネント：クラウド事業者側の運用管理チーム Copyright 2010, Soka University, All Rights Reserved. 26 ーインシデント発生対象 ・基盤の設定ミスにより、利用者側のデータが脆弱になる。 ・アップデートやセキュリティパッチ適用の遅延。 ー安全上の責務（責任） ・基盤のセキュリティ強化と定期的なアップデートの実施。 ・顧客に対するセキュリティ通知を迅速に行う。 ・システムの監視とインシデント対応を迅速に行う。 ー非安全なコントロールアクション ・セキュリティ更新を遅延させる。 ・顧客に不十分な情報提供。
27. コンポーネント：クラウド利用者側の取締役会 Copyright 2010, Soka University, All Rights Reserved. 27 ーインシデント発生対象 ・セキュリティ投資の不足により、脆弱性が生じる。 ・セキュリティインシデント対応のガバナンスが不足。 ー安全上の責務（責任） ・セキュリティ対策に十分な資金を配分する。 ・セキュリティポリシーの実施を確認・監督する。 ・インシデント対応計画を承認し、継続的に見直す。 ー非安全なコントロールアクション ・セキュリティ予算を削減する。 ・ガバナンス体制を構築しない。
28. CAST３） コントロールストラクチャ図 Copyright, Soka University, All Rights Reserved. 28
29. Copyright 2010, Soka University, All Rights Reserved. 29
30. CAST６）抽象的事象（論理モデルの分析） Copyright, Soka University, All Rights Reserved. 30
31. システム（外部）インシデント発生対象：内部サーバーへの侵入 Copyright 2010, Soka University, All Rights Reserved. 31 ー安全上の責務（責任） ・WAFや不正侵入検知が不正なアクセスを検知しブロックする。 ・公開サーバーに最小限の権限を付与する。 ・クラウド利用者側の運用管理チームとファイアウォールが適切に設定されていることを確認する。 ・定期的なセキュリティレビューと監視を実施する。 ー非安全なコントロールアクション ・WAFや不正侵入検知が特定の攻撃（SSRF）を検知できなかった。 ・公開サーバーに過剰なアクセス権限を付与されていた。 ・クラウド利用者側の運用管理チーム設定が不適切だった。 ・外部からの異常なアクセスを監視ログが適切に警告できなかった。
32. Copyright 2010, Soka University, All Rights Reserved. 32 システム（内部）インシデント発生対象：データの漏洩
33. システム（内部）インシデント発生対象：データの漏洩 Copyright 2010, Soka University, All Rights Reserved. 33 ー安全上の責務（責任） ・EC2インスタンスでIMDSv2（Instance Metadata Service Version 2）を使用し、認証なしでのメタデータアク セスを防止する。 ・IAMロールのポリシーを最小権限に設定し、必要最小限のリソースへのアクセス権限のみを付与する。 ・S3バケットポリシーを構成して、特定のIPアドレスやVPC内のリクエストのみを許可する。 ・機密データを暗号化し、暗号化キーの管理をAWS Key Management Service (KMS)を使用して行う。 ・CloudTrailを有効化し、S3アクセスログを監視して不正アクセスを早期に検知する。 ・バケット内のデータへのパブ リックアクセスを禁止し、必要な場合には一時的なURL（Presigned URL）の利用に限定する。 ー非安全なコントロールアクション ・IMDSv1を使用したまま放置し、認証なしでのメタデータアクセスを許可していた。 ・IAMロールにS3全体への過剰な権限を付与した。 ・S3バケットポリシーやアクセス制御リスト（ACL）の設定ミスにより、意図しないユーザーがアクセス可能だった。 ・機密データを暗号化せずに保存し、また暗号化キーへのアクセス制御を適切に行わなかった。 ・S3バケットアクセスログを有効化せず、不審なアクセスを検知できなかった。
34. Copyright 2010, Soka University, All Rights Reserved. 34 クラウド利用者と事業者側の運用管理チーム
35. クラウド利用者と事業者側の運用管理チーム Copyright 2010, Soka University, All Rights Reserved. 35 ーインシデント発生対象：セキュリティ監視と対応の不足 ー安全上の責務（責任） ・セキュリティインシデント対応プロセスを確立し、迅速に対応する。 ・定期的なセキュリティレビューと脆弱性評価を実施する。 ・インシデント発生時のログの保存と分析を行う。 ー非安全なコントロールアクション ・セキュリティインシデント対応プロセスが迅速に機能しなかった。 ・セキュリティレビューと脆弱性評価が定期的に実施されていなかった。 ・ログの保存と分析が不十分で、異常なアクセスが見逃された。
36. Copyright 2010, Soka University, All Rights Reserved. 36 組織（セキュリティガバナンス）
37. 組織（セキュリティガバナンス） Copyright 2010, Soka University, All Rights Reserved. 37 ーインシデント発生対象：セキュリティポリシーの不備と従業員の意識不足 ー安全上の責務（責任） ・セキュリティポリシーとガイドラインを策定し、全従業員に周知徹底する。 ・定期的なセキュリティトレーニングと教育を実施する。 ・組織全体でセキュリティ意識を高めるための施策を講じる。 ー非安全なコントロールアクション ・セキュリティポリシーが策定されていなかった、または不十分だった。 ・セキュリティトレーニングが定期的に実施されていなかった。 ・セキュリティ意識向上のための施策が実施されていなかった。
38. CAST７、８）システム全体の整合（制御構造の欠陥 特定） Copyright, Soka University, All Rights Reserved. 38 ・設計段階からの欠陥 ・運営段階からの欠陥① ・運営段階からの欠陥②
39. 設計段階からの欠陥 Copyright 2010, Soka University, All Rights Reserved. 39 ー欠陥：セキュリティ対策が後手に回り、システムの設計時に脆弱性が組み込ま れてしまった。具体的には不正侵入検知の設定ミスや不適切な管理により、不 正行為が見逃され、対応が遅れた。例えば、ファイアウォールなどのアクセス制御の 設定が不十分で、外部からの攻撃を防げなかった。 ー直接的な要因 ・設計段階でのセキュリティ考慮の不足:不正侵入検知システム設計時にセキュ リティ要件が不十分だった。 ・脆弱性の放置:不正侵入検知システムの脆弱性が適切に修正されていなかった。
40. 直接的な要因から影響すると思う要因 Copyright 2010, Soka University, All Rights Reserved. 40 ・内部ネットワークにおける影響: システム設計の脆弱性が外部からの侵入を容易にし、 攻撃者がシステム内にアクセスする手助けとなった。 ・安全なマネジメントシステムの設計における影響: マネジメントシステムの設計が脆弱 であったため、全体的なセキュリティ管理が不十分であった。具体にはセキュリティポリシー や手順が適切に設計されていなかったため、全体のセキュリティが弱体化した。 ・安全な情報システム: システム設計の段階で、過剰な権限付与を防ぐ仕組みが導入 されていなかった。 ・情報セキュリティ監査体制: 侵入後の異常なアクティビティを検知できず、侵入が長期 間見過ごされた。 ・不正監視機能:監視システムの機能や設定に関する定期的な見直しが行われておら ず、脆弱な部分が放置された。
41. 運営段階からの欠陥① Copyright 2010, Soka University, All Rights Reserved. 41 ー欠陥：定期的な監査や評価が不十分で、システム全体のセキュリティ脆弱 性が放置されて迅速な対応が難しかった。 ー直接的な要因 ・教育の不備: セキュリティに関する教育やトレーニングが不足していた。 ・セキュリティポリシーの不統一: 各部門で異なるセキュリティポリシーや手順が適 用されていた。 ・技術的な変化への対応不足: 新しい技術や脅威に対して迅速に対応できな かった。 ・プロセスの変化への適応不足: システムやプロセスの変更に対する適切な評価 や対応が行われなかった。
42. ー直接的な要因から影響すると思う要因 Copyright 2010, Soka University, All Rights Reserved. 42 ・情報交換と相互連携における影響: 部門間での情報共有や連携が不足していたため、セキュリ ティの統一管理ができなかった。具体には脆弱性情報やセキュリティインシデントが部門間で共有さ れず、全体のセキュリティが脆弱になった。 ・安全な文化における影響: 部門ごとのセキュリティ意識が低く、セキュリティポリシーが徹底されてい なかった。具体例にはセキュリティに対する意識が不足し、ポリシーの遵守が緩かった。 安全な情報システムにおける影響:技術的な変化に対応できず、古いシステムの脆弱性が放置さ れ、セキュリティリスクが増加した。具体には古いシステムやソフトウェアの脆弱性が対応されず、攻撃 の対象となった。 安全なマネジメントシステムの設計における影響: プロセスやポリシーの変化に対応できなかったため、 セキュリティ管理が劣化した。具体には変化に応じたリスク評価や管理が行われず、システムのセキュ リティが低下した。 ・経時的な変化とダイナミクスにおける影響: リスク評価の不足により、システムやプロセスの変化に 適切に対応できなかった。具体例にはシステムの変化に伴うリスクが評価されず、セキュリティ対策が 遅れた。
43. 運営段階からの欠陥② Copyright 2010, Soka University, All Rights Reserved. 43 ー欠陥：クラウド事業者と利用者との間にセキュリティに対する意識や実践が 異なり、全体のセキュリティポリシーが徹底されなかった。具体的にはシステム内 のユーザー権限が適切に管理されておらず、内部からの不正アクセスのリスクが高 まった。 ー直接的な要因 ・システム運用の不備: 運用時にリスクを適切に評価し、対策を講じていなかった。 ・権限管理の不備: 権限付与が適切に管理されておらず、不要な権限が付与さ れていた。 ・部門間の連携不足: 部門間でのセキュリティ情報や課題の共有が不十分だった。 ・役割ベースのアクセス制御（RBAC）の欠如: ユーザーの役割や業務に応じ たアクセス制御が適切に設定されていなかった。
44. ー直接的な要因から影響すると思う要因 Copyright 2010, Soka University, All Rights Reserved. 44 ・内部ネットワークにおける影響: 不適切な権限設定が侵入者に対して広範な アクセスを許可し、内部システムへの侵入を容易にした。 具体的には過剰な権限 を持ったユーザーがシステム内の機密情報にアクセスできるようになっていた。 ・マネジメント体制における影響: 部門ごとにアクセス権限の管理が不統一であり、 適切な権限管理が行われていなかった。具体的には各部門の独自の管理が権 限の一貫性を欠き、セキュリティリスクが増加していた。具体的にはセキュリティポリ シーやアクセス権限の管理が適切に行われていないことが、過剰権限の原因となっ た。
45. CAST９）結果 Copyright, Soka University, All Rights Reserved. 45 ・分析から見える弱点（不正侵入に関して、情報共有とコミュニケーションの不備） ・新たな改善案
46. １．現在のシステムでは、IMDSv1を使用したまま放置し、認証なしでのメタデー タアクセスを許可していた。 ２．WAFや不正侵入検知が特定の攻撃（SSRF）を検知できなかった。 ３．公開サーバーに過剰なアクセス権限を付与されていた。 ４．クラウド利用者側の運用管理チーム設定が不適切だった。 ５．外部からの異常なアクセスを監視ログが適切に警告できなかった。 Copyright 2010, Soka University, All Rights Reserved. 46 CAST分析から見える弱点（不正侵入に関して）
47. 1.IMDSv2への移行 IMDSv2では認証付きのトークンベースアクセスが必要となり、IMDSv1の脆弱 性を回避できる。 2-1.WAFルールの強化: • AWS WAFや他のWeb Application Firewallを使用して、SSRF攻撃を含む 悪意あるリクエストパターンをブロックする。 2-2.侵入検知システム（IDS）の改善: • Amazon GuardDutyのようなサービスを活用して、異常なリクエストや動作を 検知する。 • 組織内のIDSを定期的に更新し、最新のSSRF検知アルゴリズムを適用する。 Copyright 2010, Soka University, All Rights Reserved. 47 新たな改善案（アクセス権限の強化）
48. 3-1.最小権限の原則を適用: • IAMロールやポリシーをレビューし、各サーバーに最小限のアクセス権限を与える。 • S3バケットポリシーを確認し、特定のリソースや操作（読み取り、書き込みな ど）のみを許可する。 3-2.パブリックアクセスの禁止: • EC2インスタンスに必要以上のパブリックIPを割り当てない。 • S3バケットに対するパブリックアクセスを無効化（「Block Public Access」を有 効化）する。 Copyright 2010, Soka University, All Rights Reserved. 48 新たな改善案（アクセス権限の強化）
49. 4-1.教育とトレーニング: • クラウドセキュリティのベストプラクティスを定期的にトレーニングする。 • IAMロールにおけるポリシー設定の重要性を認識させる。 4-2. セキュリティの責任共有モデルの理解強化: • クラウド事業者（AWSなど）と利用者の責任を明確に分け、責任分担に基づ く設定を行う。 Copyright 2010, Soka University, All Rights Reserved. 49 新たな改善案（アクセス権限の強化）
50. 情報共有の不足と部門間の連携不備 １．コミュニケーションの欠如: 各部門間でセキュリティに関する重要な情報が共 有されなかった。 ２．連携不足: 部門間での連携が不十分であり、統一したセキュリティ対策が取 られていなかった。 Copyright 2010, Soka University, All Rights Reserved. 50 CAST分析から見える弱点（情報共有とコミュニケーションの不備）
51. 1.定期的なセキュリティブリーフィングの実施 • 事業者側の運用管理チームは最新のセキュリティ情報やリスクを共有し、全体としての対応 能力を向上させることを目指して、 月次または四半期ごとにセキュリティブリーフィングを実施し、 最新の脅威や対策について情報を共有する。 ２.セキュリティポリシーの統一化: • 全社的に統一されたセキュリティポリシーを策定し、各部門が同じ基準でセキュリティを管理す ることを目指して、各部門が同じセキュリティポリシーに基づいて運用するように、ガイドラインを 整備し、適用を徹底する。 ３.クロスファンクショナルチームの設立: • システム全体としてのセキュリティを強化することを目指して、横断的なセキュリティチームを設 立し、定期的に集まり、リスク管理や対策を検討する。 Copyright 2010, Soka University, All Rights Reserved. 51 新たな改善案（情報共有とコミュニケーションの強化）
52. 関連文献 Copyright, Soka University, All Rights Reserved. 52 ・A Systematic Analysis of the Capital One Data Breach: Critical Lessons Learned（2022、 Shaharyar Khan, Ilya Kabanov,Yunke Hua, Stuart Madnick） ・Information on the Capital One cyber incident（ https://www.capitalone.com/digital/facts2019/） ・2019 Capital One Cyber Incident （https://support.capitalone.ca/cyber/facts2019） ・クラウドサービス利用のための情報セキュリティマネジメントガイドライン（ 2013年版、 経済産業省）