これだけはやっておいた方がよさそう？awsにおけるランサムウェア対策

https://classmethod.connpass.com/event/379617/
#cm_sapporo_study

Transcript

1. これだけはやっておいた方がよさそう？ aws におけるランサムウェア対策 ドキュメントをベースにいろいろ調べてみた 2026 年2 月10 日( 火) クラメソさっぽろIT 勉強会 ( 仮) #12
2. 自己紹介 セキュリティ最近勉強中です 三浦 一樹 クラウドアーキテクト
3. 新千歳の床で寝ました 新千歳の床で寝ました こないだ こないだ
4. はじめに ランサムウェアの脅威とAWS の対応 体系的なことを知らなかったので 調べてみたというお話
5. フレームワークについて調べてみた NIST CSF とそれに対するAWS の対応 3 / 21 一般的なお話 AWS のお話 The NIST Cybersecurity Framework (CSF) 2.0 https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf https://d0.awsstatic.com/whitepapers/compliance/NIST_Cybersecurity_Framework_CSF_Jan_2025.pdf whitepaper 米国国立標準技術研究所 National Institute of Standards and Technology
6. Aligning to the NIST CSF 2.0 in the AWS Cloud AWS Security Blog — 2025 年1 月28 日公開 ｜ ホワイトペーパー更新版 NIST CSF 2.0 の主要変更点 Govern 新設 6 つ目のコア機能として「統治」を追加。サイバ ーセキュリティを全社リスク管理に統合 対象範囲の拡大 重要インフラに限らず、あらゆる規模・業種の組 織に適用可能に サプライチェーン サプライチェーン全体のリスク管理ガイダンスを 強化 プライバシー データの機密性・完全性・可用性に関するプライ バシーリスク管理を拡充 ホワイトペーパーのポイント AWS サービスをCSF 2.0 の6 コア機能にマッピング 共有責任モデルに基づく顧客/AWS の役割分担を明確化 Healthcare ・金融・サプライチェーン等のユースケース紹介 Well-Architected / Cloud Adoption Framework との併用ガイド 143 以上の準拠規格（FedRAMP, ISO, PCI DSS 等）との整合 CSF 2.0 の 6 コア機能 Govern 統治 NEW Identify 特定 Protect 防御 Detect 検知 Respond 対応 Recover 復旧 › › › › › CSF 2.0 × AWS — Govern の追加により「ガバナンス → 実装 → 運用」の一貫した体制構築が可能に
7. Govern （統治）— CSF 2.0 新設 NIST CSF 2.0 — サイバーセキュリティをERM （全社リスク管理）に統合 6 / 21 カテゴリ ID 概要 組織のコンテキスト GV.OC ミッション・法規制・ステークホルダー期待の把握 リスク管理戦略 GV.RM リスク許容度・優先順位の設定と伝達 役割・責任・権限 GV.RR 説明責任とパフォーマンス評価の確立 ポリシー GV.PO 組織のサイバーセキュリティポリシーの策定・施行 監督 GV.OV リスク管理活動の成果に基づく戦略改善 サプライチェーンリスク管理 GV.SC サプライチェーン全体のリスク把握と管理 AWS での実装 AWS Organizations + SCP でガードレール / Control Tower でランディングゾーン自動構築 / Security Hub で態勢管理 / IAM Identity Center で権限の一元管理 / Audit Manager で監査自動化
8. npm サプライチェーン攻撃への AWS の対応と教訓 AWS Security Blog — 2025 年12 月15 日公開 ｜ 日本語版 2026 年1 月14 日 2025 年8 月 Nx パッケージ侵害 生成AI ツール経由で悪意ある telemetry.js を配 布。GitHub 設定ファイルの窃取を試行 30 分 で指揮体制確立 2025 年9 月 Shai-Hulud ワーム npm/GitHub/ クラウド認証情報を窃取し自己増殖。 Chalk, Debug 等180+ パッケージを標的 7 分 で対応プロセス開始 2025 年10-11 月 tea.xyz トークンファーミング 暗号資産Tea トークンの不正取得。オープンソー スレジストリ史上最大規模の攻撃 150,000+ 悪意あるパッケージ検出 › › 攻撃の共通パターン • OSS の信頼関係を悪用した大規模展開 • npm / GitHub / クラウド認証情報の窃取 • postinstall スクリプトによる自動実行・拡散 AWS の推奨対策 Inspector + GuardDuty で継続的監視・脆弱性スキャン OSS 依存関係の完全なインベントリ管理（SBOM ） OpenSSF 等コミュニティとの脅威インテリジェンス共有 教訓: 各インシデントの対応から検出能力を継続的に改善 → Shai-Hulud では公開後 7 分 で対応開始、150,000+ パッケージを 30 分以内 にOpenSSF 登録
9. Identify （特定） NIST CSF 2.0 — 守るべき資産を把握し、リスクを可視化 7 / 21 対策 AWS サービス 概要 リソースインベントリ管理 AWS Config 全リソースの構成記録・変更追跡 ソフトウェア管理 Systems Manager Inventory EC2 上のソフトウェア一覧取得 データ分類 Amazon Macie S3 内の機密データ自動検出 リソースタグ付け タグポリシー 技術・ビジネス・セキュリティ・コンプライアンスの4 軸 タグ付けによりデータオーナーを明確化 → インシデント時の連絡先特定に直結
10. Protect （防御）— バックアップ編 NIST CSF 2.0 — 最重要: バックアップと復旧体制の構築 8 / 21 対策 AWS サービス/ 機能 概要 集中バックアップ管理 AWS Backup 複数サービスのバックアップを一元管理 改ざん防止 AWS Backup Vault Lock WORM 設定でバックアップの削除・変更を防止 オブジェクト保護 S3 Object Lock + Versioning オブジェクトの上書き・改ざん防止 論理的分離 クロスアカウント バックアップ バックアップ専用アカウントへコピー 時点指定復旧 ポイントインタイム リカバリ ランサムウェア発生前の状態に復元
11. Protect （防御）— IAM ・暗号化・NW 編 NIST CSF 2.0 — 長期IAM アクセスキーの廃止が最重要 9 / 21 対策領域 具体策 AWS サービス IAM 長期アクセスキー廃止 → IAM ロールへ IAM / IAM Identity Center IAM 最小権限の原則 IAM Access Analyzer 暗号化 保存時・転送時の暗号化 KMS / ACM パッチ管理 自動パッチ適用 SSM Patch Manager ネットワーク セグメント化と分離 VPC / SG / NACLs 多くのランサムウェアイベントは長期IAM アクセスキーの漏洩が起点。IAM Identity Center で SSO + 短期認証情報に 一元化することが最も効果的
12. Detect （検知） NIST CSF 2.0 — 脅威の早期発見と継続的モニタリング 10 / 21 対策 AWS サービス 概要 脅威検知 Amazon GuardDuty 悪意のあるアクティビティを継続的に監視 マルウェアスキャン GuardDuty Malware Protection EBS ボリュームの自動スキャン セキュリティ態勢管理 AWS Security Hub CIS/PCI DSS 等のベンチマーク評価 ログ管理 CloudTrail / VPC Flow Logs API 操作・ネットワークフローの記録 GuardDuty は Organizations 統合で全アカウントを一括有効化可能 Security Hub で複数のセキュリティサービスの所見を単一ビューに集約
13. Respond （対応） NIST CSF — インシデント対応の自動化 10 / 20 GuardDuty 脅威検知 → EventBridge ルール起動 → Lambda 自動隔離 → EBS スナップショット → Slack 通知 対応フロー詳細 ① GuardDuty が不正アクティビティを検知 ② EventBridge 経由で Lambda 関数を自動起動 ③ 対象EC2 のセキュリティグループを隔離用に変更 ④ フォレンジック用にEBS スナップショットを取得 ⑤ 担当者へ Slack など で即座に通知
14. Recover （復旧） NIST CSF 2.0 — イミュータブルな復旧とIaC による再構築 12 / 21 イミュータブル リカバリ 改ざん不可能なバックアップコピー から確実に復元 IaC による 環境再構築 CloudFormation / CDK で「既知の正常 な状態」をコードとして保持。感染 環境を破棄して再デプロイ 復旧訓練 Game Day 定期的な復旧テストの実施で RTO/RPO を検証。バックアップを取 るだけでなくリストア訓練を
15. 一体どこから手をつけたら、 、 なんかとっても大変そう 11 / 20 やることいっぱい！ どこからやったらいいの！！
16. 一体どこから手をつけたら、 、 なんかとっても大変そう 11 / 20 そんなあなたに AWS セキュリティ成熟度モデル
17. AWS セキュリティ成熟度モデル v2 4 フェーズ × 10 カテゴリ 2024 年11 月にversion 2 が公開 13 / 20 https://maturitymodel.security.aws.dev/ja/model/
18. AWS セキュリティ成熟度モデル v2 4 フェーズ × 10 カテゴリ — Phase 1 & 2 （基盤確立） 13 / 21 Phase 1 クイックウィン 即時 Phase 2 基礎 1 〜3 ヶ月 Phase 3 効率化 3 〜6 ヶ月 Phase 4 最適化 6 ヶ月〜 Phase 1: クイックウィン GuardDuty 有効化（脅威検知） Security Hub 有効化（ポスチャ管理） MFA / ルートの保護 CloudTrail （API 監査） S3 パブリックアクセスブロック Macie （機密データ検出） Phase 2: 基礎 一時的な認証情報 / IAM Identity Center SCP ガードレール AWS Backup 構成 KMS 暗号化 ネットワークセグメント化 インシデント対応プレイブック Phase 2 （基礎）まで完了すれば、最低限のセキュリティベースラインは確保できる
19. 成熟度モデル Phase 3-4 効率化・最適化 — 高度化と自動化 14 / 21 Phase 1 クイックウィン 即時 Phase 2 基礎 1 〜3 ヶ月 Phase 3 効率化 3 〜6 ヶ月 Phase 4 最適化 6 ヶ月〜 Phase 3: 効率化 IaC （Infrastructure as Code ）活用 タグ付け戦略の体系化 SIEM / Security Lake プレイブックの自動化 インシデント机上演習 アウトバウンド通信制御 ディザスタリカバリプラン策定 Phase 4: 最適化 ゼロトラストアクセス 一時的な昇格アクセス管理 脅威インテリジェンスの活用 SOAR / チケット管理 高度なセキュリティ自動化 DR の自動化 カオスエンジニアリング 成熟度モデルの良いところは「全部やらなきゃ」というプレッシャーから解放されること
20. 【実践】GuardDuty & Security Hub 設定 Organizations 統合での一括有効化 15 / 21 ① GuardDuty の有効化（Organizations 統合） # 管理アカウントで委任管理者を設定 aws guardduty enable-organization-admin-account \ --admin-account-id 123456789012 # 全メンバーの自動有効化 + Malware Protection aws guardduty update-organization-configuration \ --auto-enable-organization-members ALL \ --features '[{"Name":"EBS_MALWARE_PROTECTION","AutoEnable":"ALL"}]' ② Security Hub の有効化（Organizations 統合） # 委任管理者の設定 aws securityhub enable-organization-admin-account \ --admin-account-id 123456789012 # 自動有効化 + CIS Benchmark の適用 aws securityhub update-organization-configuration \ --auto-enable --auto-enable-standards
21. 【実践】Vault Lock & Object Lock 設定 イミュータブルストレージの構成 16 / 21 ③ AWS Backup Vault Lock # バックアップボルトの作成 + Vault Lock 適用 aws backup create-backup-vault \ --backup-vault-name ransomware-protection-vault aws backup put-backup-vault-lock-configuration \ --backup-vault-name ransomware-protection-vault \ --min-retention-days 30 --max-retention-days 365 --changeable-for-days 3 ④ S3 Object Lock # Object Lock 有効のバケット作成（作成時のみ設定可能） aws s3api create-bucket --bucket my-immutable-backup \ --object-lock-enabled-for-bucket --region ap-northeast-1 # Compliance モード: 90 日間保持 aws s3api put-object-lock-configuration --bucket my-immutable-backup \ --object-lock-configuration '{"ObjectLockEnabled":"Enabled", ...}' Governance: 特定IAM 権限で解除可能 Compliance: 誰も解除不可（root 含む）
22. 【実践】 RCP で SSE-C をブロックし S3 ランサムウェアを防御 Resource Control Policy （組織レベル）で攻撃者の暗号化を組織全体で一括拒否 SSE-C ランサムウェアの仕組み ❶ IAM キー漏洩で環境に侵入 ❷ 攻撃者が自前の暗号化鍵（SSE-C ）でS3 オブジェ クトを再暗号化 ❸ 復号鍵と引き換えに身代金を要求 なぜ SSE-C ブロックが有効か SSE-C の正規ユースケースはほぼ皆無 → 組織全体で一括 Deny しても業務影響なし → 攻撃者の暗号化操作自体を阻止できる RCP Policy: SSE-C を Deny （Organizations で適用） 1 { 2 "Version": "2012-10-17", 3 "Statement": [{ 4 "Sid": "RestrictSSECObjectUploads", 5 "Effect": "Deny", 6 "Principal": "*", 7 "Action": "s3:PutObject", 8 "Resource": "*", 9 "Condition": { 10 "Null": { 11 "s3:x-amz-server-side- 12 encryption-customer-algorithm": "false" 13 }}} 14 }] 15 } 併用すべき対策 GuardDuty AttackSequence:S3/Compromised Data （重大度 9.0 ）を検知・通知 バックアップ バージョニング + Object Lock + クロスアカウント Backup IAM 根本対策 長期アクセスキー廃止 + IAM Role への移行 RCP 上記に示した SSE-C Deny を 組織全体に適用 ← NEW 出典: DevelopersIO — S3 に対するランサムウェアの流行に伴い GuardDuty による脅威検出を活用するようアナウンス（2025.02.26 ） https://dev.classmethod.jp/articles/s3-ransomware-detection-with-guardduty-alerts/
23. マルチアカウント環境の基盤設計 AWS Blueprint 推奨基盤 — SCP + RCP による多層防御ガードレール サービス 役割 ランサムウェア対策での意義 AWS Organizations マルチアカウント管理 SCP + RCP によるガードレール Resource Control Policy (RCP) リソースの権限境界 SSE-C Deny 等を組織全体に適用 ← NEW re:Invent 2024 で発表 AWS Control Tower ガバナンスの自動化 ベースラインの自動適用・ドリフト検知 IAM Identity Center 一元的なアクセス管理 長期アクセスキー不要に AWS CloudTrail API 操作のログ記録 フォレンジック・監査証跡 AWS Config リソース構成の記録 構成ドリフトの検知 SCP と RCP の使い分け SCP （Service Control Policy ） 対象: プリンシパル（IAM ユーザー・ロール）の権限上限 { "Effect": "Deny", "Action": ["backup:DeleteBackupVault", "backup:DeleteRecoveryPoint"], "Resource": "*" } // Backup 削除をブロック RCP （Resource Control Policy ） NEW 対象: リソース（S3, KMS, STS, SQS 等）の権限境界 { "Effect": "Deny", "Action": "s3:PutObject", "Resource": "*", "Condition": {"Null": { "s3:..encryption-customer-algorithm":"false"}}} // SSE-C によるPutObject を組織全体で拒否 SCP = 「誰が何をできるか」を制限 × RCP = 「リソースに誰がアクセスできるか」を制限 → 組み合わせてデータ境界を確立
24. NIST CSF 2.0 × AWS セキュリティ成熟度モデル 対応関係 Whitepaper 「Aligning to the NIST CSF 2.0 in the AWS Cloud 」の6 機能を成熟度4 フェーズにマッピング CSF 2.0 機能 Phase 1: Quick Wins 即時 Phase 2: Foundational 1 〜3 ヶ月 Phase 3: Efficient 3 〜6 ヶ月 Phase 4: Optimized 6 ヶ月〜 Govern ( 統治) Security Hub 有効化 CloudTrail 有効化 Organizations + SCP Control Tower 導入 RCP 導入・IaC 化 Audit Manager Security Lake 継続的コンプライアンス Identify ( 特定) Config 有効化 リソースインベントリ タグ戦略策定 Macie （機密データ検出） SBOM 管理 リスクアセスメント体系化 脅威インテリジェンス 継続的リスク評価 Protect ( 防御) MFA ・ルート保護 S3 パブリックブロック IAM Identity Center KMS 暗号化・Backup NW セグメント化 WAF / Shield ゼロトラスト 特権アクセス管理 Detect ( 検知) GuardDuty 有効化 基本アラート設定 Inspector 脆弱性スキャン SecurityHub スコア監視 SIEM 統合 カスタム検知ルール ML ベース異常検知 脅威ハンティング Respond ( 対応) セキュリティ連絡先設定 基本通知フロー IR プレイブック策定 EventBridge 自動通知 プレイブック自動化 机上演習の実施 SOAR 統合 フォレンジック自動化 Recover ( 復旧) バックアップ基本設定 S3 バージョニング Backup Vault Lock Object Lock (WORM) DR プラン策定 クロスリージョン複製 DR 自動化 カオスエンジニアリング CSF 2.0 の6 機能 がフェーズ横断で段階的に成熟 → Govern （統治）が全フェーズを貫くガバナンス軸として機能 出典: AWS 「Aligning to the NIST CSF 2.0 in the AWS Cloud 」(2025.01) + AWS Security Maturity Model v2
25. まとめ とりあえずなんもわからん状態からは脱出できそう？ NIST SCF 2.0 と成熟度モデルを参考に 進めていけば、だいぶセキュアな環境作れそう！
26. 助言いただいたのでセキュリティの柱も見てみた W-A Framework もみてみた appendix
27. Well-Architected Framework — セキュリティの柱 7 つのベストプラクティス領域 × 7 つの設計原則で構成（Security Pillar Whitepaper, Nov 2024 ） 1 / 9 Security Foundations SEC 1 アカウント戦略 / ガードレール運 用 Identity & Access Mgmt SEC 2-4 最小権限 / ID 一元管理 Detection SEC 5 セキュリティイベント検知・調査 Infrastructure Protection SEC 6-7 ネットワーク保護 / コンピュー ト保護 Data Protection SEC 8-10 データ分類 / 暗号化・アクセス 制御 Incident Response SEC 11-12 IR 計画・演習 / 検出〜復旧の自 動化 Application Security SEC 13 セキュアな設計 / 脆弱性管理 7 つの設計原則（次スライドで詳解 →） 1. 強力なID 基盤の実装 2. トレーサビリティの確保 3. 全レイヤーにセキュリティ適用 4. セキュリティのベストプラクティスを自動化 5. 転送中・保管中のデータ保護 6. データから人を遠ざける 7. セキュリティイベントへの備え ワークロード視点 のセキュリティ設計指針 — 次の7 スライドで各設計原則を詳解
28. 1 強力なID 基盤の実装 Implement a Strong Identity Foundation 2 / 9 最小権限の原則を実装し、適切な認可でAWS リソースへの各操作に対して職務分離を強制する。ID 管理を一元化し、長期的な静的認証情報への依存をなくす。 IAM Identity Center で一元管理 AWS Organizations と統合し、全アカウントのアクセスを集中管理。SAML/OIDC によ る IdP 連携で SSO を実現 最小権限ポリシー 必要最小限のアクション・リソースのみ許可。IAM Access Analyzer で未使用権限を定 期的に棚卸し 長期認証情報の排除 IAM ユーザーのアクセスキーを廃止し、IAM ロール + 一時的認証情報（STS ）に移行 権限の境界（Permissions Boundary ） 開発者に委任する IAM 権限の上限を SCP / Permissions Boundary で制御 主要 AWS サービス: IAM Identity Center | IAM Access Analyzer | STS | AWS Organizations (SCP/RCP) WA: Identity and Access Management (SEC 2-4) 設計原則 1/7 AWS Well-Architected Framework — Security Pillar
29. 2 トレーサビリティの確保 Maintain Traceability 3 / 9 環境内のアクションと変更をリアルタイムでモニタリング、アラート、監査する。ログとメトリクス収集をシステムと統合し、自動的に調査・対応を行う。 CloudTrail の全リージョン有効化 管理イベント + データイベントを記録。S3 + CloudWatch Logs への配信でリアルタイ ム分析を実現 VPC Flow Logs / DNS Logs ネットワークレベルの通信ログで不正なデータ流出や C2 通信を検知 一元ログ集約（Log Archive アカウント） 全アカウントのログを専用アカウントに集約。改ざん防止のため S3 Object Lock を適 用 Security Lake による統合分析 OCSF 形式でログを正規化・統合。Athena / QuickSight で横断分析を実現 主要 AWS サービス: CloudTrail | VPC Flow Logs | Security Lake | CloudWatch Logs WA: Detection (SEC 5) 設計原則 2/7 AWS Well-Architected Framework — Security Pillar
30. 3 全レイヤーにセキュリティ適用 Apply Security at All Layers 4 / 9 多層防御（Defense in Depth ）アプローチで複数のセキュリティコントロールを適用する。ネットワークエッジ、VPC 、ロードバランサー、インスタンス、OS 、 アプリケーション、コードの全レイヤーに適用。 ネットワークエッジ保護 CloudFront + WAF + Shield でDDoS ・SQLi ・XSS を防御。AWS Network Firewall でVPC 間通 信を制御 VPC セグメンテーション パブリック / プライベートサブネットの分離。セキュリティグループ + NACL の多層 制御 コンピュート保護 EC2 Instance Metadata Service v2 (IMDSv2) の強制。Systems Manager によるパッチ管理 アプリケーションレイヤー Inspector による脆弱性スキャン。CodeGuru / SAST ツールによるコードレベルの脆弱 性検出 主要 AWS サービス: WAF | Shield | Network Firewall | Security Groups | Inspector WA: Infrastructure Protection (SEC 6-7) 設計原則 3/7 AWS Well-Architected Framework — Security Pillar
31. 4 セキュリティのベストプラクティスを自動化 Automate Security Best Practices 5 / 9 自動化されたソフトウェアベースのセキュリティメカニズムにより、安全にスケールする能力を向上させる。バージョン管理されたテンプレートでコードとし て定義・管理されるコントロールを含むセキュアアーキテクチャを作成。 Infrastructure as Code (IaC) CloudFormation / CDK でセキュリティ構成をコード化。変更をGit で管理し、レビュ ー・承認フローを確立 Security Hub 自動修復 CIS / AWS FSBP ベンチマーク違反を検出し、EventBridge → Lambda / SSM で自動修復 Config Rules + 自動修正 AWS Config ルールで構成逸脱を検出し、SSM Automation による自動修正を実行 GuardDuty → EventBridge → 自動隔離 脅威検出時にEC2 の隔離SG 適用やIAM ポリシー無効化を自動実行するパイプライン 主要 AWS サービス: Security Hub | Config | EventBridge | CloudFormation / CDK | Lambda WA: Security Foundations (SEC 1) 設計原則 4/7 AWS Well-Architected Framework — Security Pillar
32. 5 転送中・保管中のデータ保護 Protect Data in Transit and at Rest 6 / 9 データを感度レベルに分類し、暗号化、トークン化、アクセス制御などのメカニズムを適切に使用する。 保管時の暗号化 KMS （CMK ）による S3 / EBS / RDS の暗号化を必須化。SCP で暗号化なしの操作を Deny 転送時の暗号化 ACM による TLS 証明書管理。ALB / CloudFront で TLS 1.2+ を強制。VPC 内通信も暗号化 データ分類と Macie Amazon Macie で S3 内の個人情報・機密データを自動検出・分類。リスクに応じた保 護レベルを適用 キー管理のベストプラクティス KMS キーポリシーで使用者を限定。自動ローテーション有効化。削除保護期間を設 定 主要 AWS サービス: KMS | ACM | Macie | S3 (SSE-S3/SSE-KMS) | CloudHSM WA: Data Protection (SEC 8-10) 設計原則 5/7 AWS Well-Architected Framework — Security Pillar
33. 6 データから人を遠ざける Keep People Away from Data 7 / 9 データへの直接アクセスや手動処理の必要性を軽減・排除するメカニズムとツールを使用する。これにより機密データの取り扱い時のミスや改ざん、ヒューマ ンエラーのリスクを低減する。 本番環境への直接アクセス排除 SSM Session Manager 経由のアクセスに限定。SSH キーを排除し、CloudTrail でセッシ ョンを記録 CI/CD パイプラインによるデプロイ 手動デプロイを禁止し、CodePipeline / CodeBuild による自動デプロイに統一。承認ゲ ートを設置 ダッシュボード / クエリベースの分析 Athena / QuickSight でデータをクエリ。生データの直接ダウンロードを IAM で制限 一時的な特権昇格 常時の管理者権限を排除。IAM ロールの一時引き受け + 承認フローで必要時のみアク セスを許可 主要 AWS サービス: SSM Session Manager | CodePipeline | Athena | CloudTrail | IAM Roles WA: Data Protection (SEC 8-10) + IAM (SEC 2-4) 設計原則 6/7 AWS Well-Architected Framework — Security Pillar
34. 7 セキュリティイベントへの備え Prepare for Security Events 8 / 9 組織要件に沿ったインシデント管理・調査のポリシーとプロセスを整備してインシデントに備える。インシデント対応シミュレーションを実施し、自動化ツー ルを活用して検出・調査・復旧の速度を向上させる。 IR プレイブック策定 ランサムウェア、不正アクセス、データ漏洩など脅威別のプレイブックを事前に策 定・文書化 Game Day / 机上演習 定期的なインシデント対応演習で対応力を検証。AWS Incident Manager でランブック を管理・実行 フォレンジック環境の事前準備 専用の Security アカウントに隔離 VPC を準備。EBS スナップショットのクロスアカウ ントコピーで証拠保全 自動検出・対応パイプライン GuardDuty → EventBridge → Step Functions で検出から初動対応までを自動化。SOAR 連 携 主要 AWS サービス: Incident Manager | GuardDuty | Detective | Step Functions | EventBridge WA: Incident Response (SEC 11-12) 設計原則 7/7 AWS Well-Architected Framework — Security Pillar
35. 3 つのフレームワーク対応マッピング NIST CSF 2.0 × AWS セキュリティ成熟度モデル × Well-Architected セキュリティの柱 9 / 9 CSF 2.0 WA Security Pillar Phase 1 Quick Wins Phase 2 Foundational Phase 3 Efficient Phase 4 Optimized Govern ( 統治) Security Foundations CloudTrail Security Hub Organizations SCP + RCP Control Tower Audit Manager Security Lake 継続的ガバナンス Identify ( 特定) Security Found. + Application Sec. Config 有効化 リソース棚卸 タグ戦略 Macie SBOM 管理 リスク評価体系化 脅威インテリジェンス 継続的評価 Protect ( 防御) IAM + Infra Prot. + Data Protection MFA ・ルート保護 S3 パブリック Block IAM IdC / KMS Backup / NW 分離 WAF / Shield IaC 自動化 ゼロトラスト 特権アクセス管理 Detect ( 検知) Detection GuardDuty 基本アラート Inspector SecHub スコア監視 SIEM 統合 カスタムルール ML 異常検知 脅威ハンティング Respond ( 対応) Incident Response 連絡先設定 通知フロー IR プレイブック EventBridge 自動化演習 机上訓練 SOAR フォレンジック自動化 Recover ( 復旧) Incident Resp. + Reliability Pillar Backup 基本設定 バージョニング Vault Lock Object Lock DR プラン クロスリージョン DR 自動化 カオスエンジニアリング NIST CSF 2.0 リスク管理フレームワーク — （何を守るか） WA Security Pillar ワークロード設計指針 — （どう作るか） 成熟度モデル v2 実装優先順位 — （いつ実装するか） CSF 2.0 （何を）× WA （どう設計）× 成熟度モデル（いつ実装）→ 3 軸で網羅的なセキュリティ戦略を構築