AWS SOC GuardDuty Security Hub Detective 統合運用 完全ガイド Vol2

1. なぜSOC統合運用か — セキュリティVol1(基礎)からの架橋 + SOC実践深化結節点

AWS クラウドのセキュリティ運用は、2022〜2024年にかけて急速に複雑化しました。GuardDuty が拡張機能を追加し、Security Hub が Standards の評価範囲を広げ、Detective が Behavior Graph を強化したことで、個々のサービスを単独で運用する時代から、三位一体で統合運用する時代へと移行しています。

本章では、なぜ GuardDuty・Security Hub・Detective の3サービスを統合運用する必要があるか、Vol1（基礎）との違い、そして本記事で習得できる5つの到達ゴールを解説します。

1-1. なぜSOC統合運用が必要か — 三位一体の設計思想

AWS 環境でのセキュリティ脅威対応が複雑化した根本的な理由は、「検知・集約・調査の3フェーズが個別のサービスに分散している」点にあります。GuardDuty が脅威を検知しても、その Finding がどのコンプライアンス要件に影響するかを把握するには Security Hub の Standards 評価が必要です。さらに、Finding の背後にある攻撃者の行動パターンや被害範囲を特定するには Detective の Behavior Graph が不可欠です。

SOC（Security Operations Center）運用において、これら3サービスを個別に扱うと以下の問題が発生します。

GuardDuty → Security Hub → Detective の流れは「脅威を検知（GuardDuty）→ Finding を集約・評価（Security Hub）→ 詳細を調査（Detective）」という一連の対応フローを構成します。この統合運用フローを確立することが、本記事が目指す SOC統合運用の中心的な設計思想です。

セキュリティ担当者が日々直面する現実的な課題として、GuardDuty の Finding が1日数十件に上るケースがあります。全件対応は現実的でなく、その中から本当に対処すべき脅威を選び出す仕組みが不可欠です。3サービスの統合運用は、このトリアージプロセスを体系化し、限られたリソースで最大のセキュリティ効果を得るための基盤となります。

AWS セキュリティの設計原則として、「検知だけではセキュリティは完結しない」 という考え方があります。GuardDuty が Finding を生成しても、それが Security Hub で正しく集約・評価されなければ対応漏れが発生します。また、Security Hub がスコアを算出しても、Detective で根本原因を調査しなければ同一攻撃者による再侵害を防ぐことができません。三位一体の統合運用は、この3フェーズを切れ目なく接続する設計です。

三位一体の動作フロー — 具体的な攻撃検知シナリオ

実際のセキュリティ対応シナリオを通じて、GuardDuty・Security Hub・Detective がどのように連携するかを確認します。

シナリオ: 外部攻撃者がフィッシングによって IAM アクセスキーを窃取し、S3 バケットからデータを持ち出そうとしているケースを想定します。

[Phase 1] GuardDuty が脅威を検知
├── 通常とは異なる地域（例: 東南アジア）からの API 呼び出しを検知
├── Finding 生成: CredentialAccess:IAMUser/AnomalousBehavior (Severity: High)
└── Finding 生成: Exfiltration:S3/MaliciousIPCaller (Severity: High)

[Phase 2] Security Hub が評価・集約
├── GuardDuty Finding を ASFF 形式で自動受信
├── FSBP コントロール "S3.1: Public access block" の評価と照合
├── Custom Insight "High Severity Findings by IAM User" で集計
├── EventBridge → SNS 通知で担当者にアラート送信
└── Security Score に影響（High Finding が Security Score を低下させる）

[Phase 3] Detective で根本原因を調査
├── Finding に紐づく IAM ユーザーのエンティティを Behavior Graph で確認
├── 過去30日間の正常な API 呼び出しパターンと今回の異常行動を比較
├── 同一 IP アドレスから他のリソースへのアクセス試行がないか確認
├── アクセスキーの発行日時・最終使用時刻・利用されたリージョンを時系列確認
└── 対応判定: アクセスキーの無効化 + S3 バケットポリシーの審査

この一連のフローが 15〜30 分以内に完結するのが、SOC統合運用の目標とする対応速度です。個別サービスを個別に調べると、同じ調査に数時間かかる場合があります。三位一体の統合運用によって、脅威の検知から対応判断までの時間（MTTD / MTTR）を大幅に短縮できます。

1-2. Vol1(基礎) → Vol2(SOC統合) への進化 — 3本柱の深化

セキュリティシリーズ Vol1「セキュリティ運用入門 — 脅威検出 / コンプライアンス / ログ集約」では、AWS セキュリティの3本柱として「脅威検出 / コンプライアンス / ログ集約」を解説しました。Vol2 では、この3本柱をより高度な SOC統合運用の設計へと発展させます。

Vol1 の時点では「有効化して監視する」フェーズでしたが、Vol2 では「Finding を正確に評価し、優先順位をつけ、根拠を持って対応判断する」フェーズへの移行を扱います。

特に重要な変化は、受動的な通知待ちから能動的な脅威追跡への転換です。Security Hub の Custom Insights で傾向を可視化し、Detective で攻撃パターンを分析することで、次の脅威が発生する前にリスクを低減する運用サイクルが確立されます。

Vol1（基礎フェーズ）  Vol2（SOC統合フェーズ）
─────────────────────────────── ──────────────────────────────────────────
GuardDuty 有効化 GuardDuty 全6 Protection + Finding type 分類
 ↓ ↓
Security Hub 基本設定Security Hub Standards 3種 + Security Score + Custom Insights
 ↓ ↓
CloudTrail ログ保管  Detective Behavior Graph + Triage workflow + Cross-service correlation
 ↓ ↓
個別アラート対応  Multi-Account Aggregator + 詰まり7選対処 + 演習5問で定着

Vol1 の基礎知識を持つ読者にとって、Vol2 の内容は「GuardDuty の Finding 件数が多すぎてどれを対処すべきか分からない」「Security Hub のスコアをどう解釈すればいいか」「Detective をどこから使い始めるか」という実務的な疑問への直接的な回答となります。

Multi-Account 環境での統合については、マルチアカウント運用 Vol1「Organizations × Control Tower × Landing Zone」が前提知識として有効です。Organizations の委任管理モデルを理解していると、§5 で解説する GuardDuty / Security Hub の delegated admin 設定がスムーズに理解できます。

Vol1→Vol2 移行で変わること — セキュリティ運用の成熟度指標

SOC 統合運用への移行は、セキュリティ運用の成熟度（Security Operations Maturity）の向上を意味します。以下の4段階で自組織の現在地を確認してください。

多くの組織は Level 2（Vol1 段階）で運用が止まっています。GuardDuty の Finding が増え続け、Security Hub のスコアが低いまま改善方法が分からず、Detective は有効化したものの使い方が不明という状態です。Vol2 では、Level 2 から Level 4 への移行を段階的に解説します。

1-3. 本記事の到達ゴール5点

本記事を読み終えた時点で、以下の5つの能力を習得することを目標とします。

(a) GuardDuty 全6 Protection の本番運用

GuardDuty の基本 Threat Detection に加え、Malware Protection / RDS Protection / EKS Protection / Lambda Protection / S3 Protection の5拡張機能について、それぞれの対象リソース・Finding type・コスト特性を理解し、プロダクション環境で適切に選択・設定できる状態を目指します。Protection ごとの課金モデルの違いを把握し、コスト試算した上で段階的に有効化するアプローチを習得します。

(b) Security Hub Standards の設計と運用

AWS Foundational Security Best Practices（FSBP）・CIS Benchmarks・PCI DSS の3 Standards について、組織の業界要件・監査要件に基づく選定軸を理解します。Security Score の読み方と改善優先順位の付け方、Custom Insights による Alert Fatigue 対策を実装できる状態を目指します。ASFF（Amazon Security Finding Format）による Finding の統一集約と、EventBridge を使った自動対応アクションの設計方法も習得します。

(c) Detective Behavior Graph の活用

Detective の Behavior Graph を使って、GuardDuty Finding の背後にある エンティティ関係（IAM ユーザー / ロール / EC2 / IP アドレス）の時系列推移を調査し、正常なベースライン行動と異常行動を区別できる Triage workflow を設計できる状態を目指します。Cross-service correlation（複数 AWS サービスにまたがる攻撃パターンの相関分析）の実践手法を習得します。

(d) Multi-Account Aggregator の Terraform 実装

Organizations 委任管理モデルを用いた GuardDuty / Security Hub の delegated admin 設定、Cross-Region 集約、メンバーアカウント一括有効化を Terraform で実装できる状態を目指します。§5 で提供する Terraform 完全例をそのまま本番環境に適用できる水準の理解を目指します。Organizations Trust Relationship の設定ミスや、Cross-Region Aggregator の構成漏れを回避する方法を習得します。

(e) 詰まりポイント7選の体系的な回避

Alert Fatigue / False Positive 誤判定 / Auto-Remediation の設計誤り / Cross-Account 集約の設定ミス / Cross-Region Aggregator の構成漏れ / GuardDuty コスト超過 / Detective 未活用の7つの典型的な詰まりポイントを、図解と Terraform + AWS CLI の実例を使って回避できる状態を目指します。§7 の演習5問（Terraform + AWS CLI + EventBridge 3形式）で理解を実践レベルに定着させます。

これら5つのゴールは、Vol1 読了済みの SRE・セキュリティ担当が「GuardDuty/Security Hub を有効化したが、実際の運用で詰まっている」という現実的な課題に直接対応しています。Vol1 の基礎知識を前提に、本番 SOC 運用に必要な実装・設計・トリアージの全フェーズをカバーする構成になっています。

2. GuardDuty 詳細 — Threat Detection / Malware Protection / RDS / EKS / Lambda / S3 / Finding types

2-1. GuardDuty 全体像 — 基本 Threat Detection + 5 Protection 拡張機能

Amazon GuardDuty は、AWS アカウントおよびワークロードに対する 継続的な脅威検出サービスです。VPC Flow Logs・CloudTrail Logs・DNS Logs の3種類のデータソースを基本とし、機械学習・脅威インテリジェンス・異常検出アルゴリズムを組み合わせて悪意のある活動や不正アクセスを検出します。

GuardDuty は2022〜2024年にかけて、基本の Threat Detection に加えて5つの Protection 拡張機能（アドオン）を追加しました。これにより、単なる「ネットワーク・API異常検出」から「マルウェア検出 / データベース異常 / コンテナ脅威 / サーバーレス監視 / オブジェクトストレージ保護」まで、AWS ワークロード全体を網羅する脅威検出プラットフォームへと進化しています。

GuardDuty のデータソース（基本）:

GuardDuty 6 Protection 全体構成:

Amazon GuardDuty
├── 基本 Threat Detection（デフォルト有効・追加料金なし）
│├── VPC Flow Logs 解析
│├── CloudTrail 管理イベント解析
│└── DNS ログ解析
│
├── Malware Protection（EC2 / ECS on EC2 のマルウェアスキャン）
├── RDS Protection（RDS Aurora 異常ログインの検出）
├── EKS Protection（EKS Audit Log + Runtime 解析）
├── Lambda Protection（Lambda Network Activity 解析）
└── S3 Protection（S3 データイベント解析）

2-2. 6 Protection 詳細 — 通常検知 / Malware / RDS / EKS / Lambda / S3

基本 Threat Detection（Standard）

対象リソース: EC2 / IAM / S3（データイベントなし）/ Route 53

Finding type の例:
– UnauthorizedAccess:EC2/SSHBruteForce — SSH ブルートフォース攻撃の検出
– Backdoor:EC2/C&CActivity.B — 既知のC&Cサーバーへの通信
– CredentialAccess:IAMUser/AnomalousBehavior — IAM ユーザーの異常なAPI呼び出しパターン
– CryptoCurrency:EC2/BitcoinTool.B — 暗号通貨マイニングツールの検出
– Recon:IAMUser/MaliciousIPCaller — 既知の悪意あるIPからの偵察

Malware Protection

対象リソース: EC2 インスタンス・ECS タスク（EC2 起動タイプ）

Malware Protection は、EBS ボリュームのスナップショットを取得し、GuardDuty マネージドの環境でスキャンすることでマルウェアを検出します。本番インスタンスへの影響なしにスキャンが実施される点が特徴です。

Finding type の例:
– Execution:EC2/MaliciousFile — EC2 上でマルウェアが実行または検出
– Execution:ECS/MaliciousFile — ECS タスク上のマルウェア検出

コスト特性: スキャン対象 EBS ボリューム容量（GB）× スキャン実行回数に比例。Finding 発生時のみスキャンが起動するため、通常時のコストは基本 Threat Detection のみです。

RDS Protection

対象リソース: Amazon Aurora（MySQL / PostgreSQL 互換）

RDS Protection は Aurora Database Activity Streams を解析し、不審なログイン試行や異常なデータベース操作を検出します。

Finding type の例:
– CredentialAccess:RDS/AnomalousBehavior.SuccessfulBruteForce — ブルートフォース成功（Aurora ログイン）
– CredentialAccess:RDS/MaliciousIPCaller.SuccessfulLogin — 既知の悪意あるIPからのログイン成功

コスト特性: Aurora の Database Activity Streams 有効化が前提（別途 Kinesis Data Streams コスト）。大規模 Aurora クラスターでは Activity Streams のデータ量に注意が必要です。

EKS Protection

対象リソース: Amazon EKS クラスター（Kubernetes Audit Log + Runtime）

EKS Protection は2段構成です。EKS Audit Log Monitoring（Kubernetes API サーバーの監査ログ）と EKS Runtime Monitoring（ノード上のランタイム挙動）の両方を解析します。

Finding type の例:
– Discovery:Kubernetes/SuccessfulAnonymousAccess — 匿名認証でのKubernetes API アクセス成功
– PrivilegeEscalation:Kubernetes/PrivilegedContainer — 特権コンテナの起動
– Execution:Kubernetes/ExecInKubeSystemPod — kube-system Pod への exec 操作
– Impact:Runtime/CryptoMinerExecuted — ランタイム上での暗号通貨マイナー実行

EKS Protection と EKS 本番運用の詳細については §2-4 でクロスリンクとともに解説します。

コスト特性: Kubernetes Audit Log の解析はログ量に比例。大規模クラスターでは Audit Log Policy でノイズの少ないイベントのみを有効化することでコスト最適化が可能です。

Lambda Protection

対象リソース: AWS Lambda 関数

Lambda Protection は、Lambda 関数が実行中に行うネットワーク通信（Lambda Network Activity Monitoring）を解析します。Lambda のコードが意図せず外部の悪意あるエンドポイントに通信している場合を検出します。

Finding type の例:
– CryptoCurrency:Lambda/BitcoinTool.B — Lambda 関数から暗号通貨マイニングプールへの通信
– Backdoor:Lambda/C&CActivity.B — Lambda 関数から既知のC&Cサーバーへの通信

コスト特性: Lambda 呼び出し数（invocation）に比例した解析コスト。高頻度で呼び出される Lambda 関数の Protection 有効化前にコスト見積もりを実施することを推奨します。

S3 Protection

対象リソース: Amazon S3 バケット（データイベント）

S3 Protection は CloudTrail S3 データイベント（GetObject / PutObject / DeleteObject 等）を解析し、S3 バケットに対する不審なアクセスパターンを検出します。

Finding type の例:
– Exfiltration:S3/MaliciousIPCaller — 既知の悪意あるIPからのデータ取得
– Discovery:S3/MaliciousIPCaller — バケット一覧の偵察
– UnauthorizedAccess:S3/MaliciousIPCaller.Custom — カスタム脅威リストに登録されたIPからのアクセス

コスト特性: S3 データイベント量（GET / PUT 等のリクエスト数）に比例。大量の S3 アクセスが発生するワークロードでは、前月の CloudTrail S3 データイベント数からコストを事前試算します。

2-3. Finding type 分類 — Severity × Category マトリクス

GuardDuty の Finding は Severity（重大度） と Category（カテゴリ） の2軸で分類されます。

Severity（重大度）

High / Critical Finding が発生した場合は Security Hub の Automated Response（EventBridge 連携）で即時通知・自動隔離アクションを設定することを推奨します。Low / Medium の大量発生は Alert Fatigue の典型的な原因であり、Security Hub の Suppression Rule で抑制対象とすることが有効です。

Category（カテゴリ）と代表的な Finding type

Stealth カテゴリに注意: Stealth:IAMUser/CloudTrailLoggingDisabled（CloudTrail ログ無効化）や Stealth:IAMUser/PasswordPolicyChange（パスワードポリシー変更）は、攻撃者が証跡を消そうとしている兆候です。Severity が Medium であっても、Detective での詳細調査を必ず実施することを推奨します。

Policy カテゴリの見落とし注意: Policy:IAMUser/RootCredentialUsage（ルートアカウントの使用）は Severity が低くても、ルートアカウントの使用自体が設計上の問題を示します。Security Hub FSBP の “Root account used” コントロールと合わせて、即時調査対象としてください。

2-4. EKS Vol1-3 との連携 — EKS Protection 実践

EKS Protection は、EKS クラスター上のコンテナワークロードに対する脅威を検出します。本番 EKS 運用との組み合わせについては以下の各巻を参照してください。

• EKS本番運用 Vol1「クラスター設計 / IRSA / ALB Ingress」: IRSA（IAM Roles for Service Accounts）の正しい設定が EKS Protection の False Positive 削減に直結します。IRSA が適切に設定されていれば、GuardDuty が検出する UnauthorizedAccess:Kubernetes/AnomalousBehavior の多くは正当な自動スケーリング・CI/CD パイプラインの操作として識別できます。

• EKS本番運用 Vol2「Observability / Fluent Bit / Container Insights」: Container Insights で収集したメトリクスと GuardDuty EKS Finding を組み合わせることで、CPU スパイク + GuardDuty CryptoCurrency Finding の相関検知が可能になります。

• EKS本番運用 Vol3「GitOps / ArgoCD」: ArgoCD による継続的デプロイと EKS Protection を組み合わせる場合、ArgoCD のサービスアカウントが行う API 操作を Finding の除外対象（Suppression Rule）として設定することで、CI/CD パイプラインに起因する False Positive を大幅に削減できます。

EKS Runtime Monitoring の有効化には GuardDuty Security Agent（DaemonSet）のクラスターへのデプロイが必要です。マネージドデプロイ（自動インストール）を使うと、GuardDuty が DaemonSet を管理するため、手動管理の手間が不要になります。

2-5. AI Vol1+Vol2 との連携 — Bedrock API 異常検知

Amazon Bedrock を活用する AI ワークロードにおいて、GuardDuty は Bedrock API 呼び出しの異常パターンを検出します。

AI シリーズ Vol1「Bedrock Agents 本番運用」およびVol2「Bedrock Knowledge Bases × RAG」で構築した Bedrock ワークロードに GuardDuty を組み合わせると、以下のシナリオが検出可能になります。

• Bedrock API を呼び出す IAM ロールが、通常とは異なるリージョンから API 呼び出しを実行している場合: CredentialAccess:IAMUser/AnomalousBehavior
• Bedrock を呼び出す Lambda 関数が、外部の不審なエンドポイントに通信している場合: Backdoor:Lambda/C&CActivity.B（Lambda Protection 有効化が必要）
• Bedrock 用の S3 バケット（RAG のナレッジベースソース）への不審なアクセス: Exfiltration:S3/MaliciousIPCaller（S3 Protection 有効化が必要）

AI ワークロードでの Bedrock IAM ロール設計については AI シリーズ Vol1 の IAM セクションを参照し、GuardDuty との組み合わせで継続的な監視体制を構築することを推奨します。

2-6. Protection 別コスト比較表

GuardDuty の料金は Protection 機能ごとに独立した課金モデルを持ちます。本番導入前に以下の比較表を使ってコスト試算を行ってください。

コスト最適化の原則: 全 Protection をいきなり全有効化するのではなく、ワークロードの特性に合わせて段階的に有効化することを推奨します。まず基本 Threat Detection と S3 Protection を有効化し、EKS / Lambda / RDS Protection は対象サービスの規模に応じてコスト試算後に追加する手順が現実的です。

AWS 公式の GuardDuty Price Estimator（マネジメントコンソール → GuardDuty → Setting → Usage）を使うと、現在のデータソース量に基づいた月額試算が確認できます。

3. Security Hub 統合 (山場1) — Findings aggregation / Standards (FSBP/CIS/PCI) / Security Score / Custom Insights

flowchart LR
  A[GuardDuty/Inspector/Macie] -->|Findings| B[Security Hub]
  B --> C{Standards評価}
  C -->|FSBP Pass| D[Security Score +]
  C -->|FSBP Fail| E[Security Score -]
  B --> F[Custom Insights]
  B --> G[EventBridge]

3-1. Security Hub とは — Finding 集約ハブ + Standards 評価エンジン

AWS Security Hub は、GuardDuty・Inspector・Macie・Config などの複数セキュリティサービスが生成する Finding（セキュリティ検出結果）を単一コンソールに集約し、業界標準 Standards に照らしてコンプライアンス評価と Security Score を自動算出する マネージドサービスです。

セキュリティシリーズ Vol1「セキュリティ運用入門 — 脅威検出 / コンプライアンス / ログ集約」でカバーした「コンプライアンス評価」の基礎を、Security Hub は継続的自動評価として実装します。GuardDuty が Threat Detection（脅威検知）に特化するのに対し、Security Hub は “検出された Finding がどのような意味を持つか” を Standards スコアリングと Custom Insights によって構造化します。

Security Hub が解決する主な課題:

Finding の送受信には Amazon Security Finding Format（ASFF） という統一スキーマが用いられます。ASFF により、サービスを問わず同一フォーマットで Finding を扱えるため、Custom Insights での横断集計やカスタムアクション（EventBridge 連携）の適用が容易になります。

3-2. Standards 3種 詳細 — FSBP / CIS Benchmarks / PCI DSS

Security Hub は Standards（業界標準） を使ってリソース設定のコンプライアンス適合度を自動評価します。主要 Standards は3種類です。

AWS Foundational Security Best Practices (FSBP)

対象: AWS 全サービス向けのセキュリティベースライン
Controls 数: 400+ Controls（2024年時点、継続的に追加）
対象サービス例: IAM / EC2 / S3 / RDS / Lambda / ECS / EKS / CloudTrail / Config / GuardDuty 等
業界適合: 業種を問わない汎用ベースライン
評価頻度: 準リアルタイム（Config ルール連携）

FSBP は AWS が定義した「AWS を安全に使うための最低限の実践集」です。GuardDuty の有効化・S3 バケットのパブリックアクセスブロック・MFA 有効化など、業種を問わず適用すべき Controls が網羅されています。Security Hub を有効化するとデフォルトで FSBP が自動有効化されます。

aws securityhub get-enabled-standards \
  --query 'StandardsSubscriptions[*].{Arn:StandardsArn,Status:StandardsStatus}'

CIS AWS Foundations Benchmark

対象: CIS（Center for Internet Security）策定の AWS 設定ベースライン
Controls 数: v1.4 = 58 Controls / v3.0 = 100+ Controls
対象領域: IAM / ログ管理 / ネットワーク / モニタリング
業界適合: 全業種（特に外部監査・セキュリティ認証取得を目指す組織）
評価頻度: 定期的（CloudTrail ログ分析を含む）

CIS Benchmarks は独立機関が策定しており、外部監査における参照標準として広く認められています。FSBP と重複する Controls も多い一方、パスワードポリシー・ルートアカウント MFA・アクセスキーのローテーション期限など IAM・ログ管理に特化した Controls が充実しています。

PCI DSS (Payment Card Industry Data Security Standard)

対象: カード会員データを扱う環境
Controls 数: v3.2.1 = 50+ Controls
対象領域: アクセス制御 / 暗号化 / ネットワーク分離 / ログ監視 / 脆弱性管理
業界適合: EC サイト / 金融 / 決済代行（必須）
評価頻度: 定期的

PCI DSS の Requirements 1〜12 に対応する AWS Controls を自動評価し、準拠状況を継続的にモニタリングします。QSA（Qualified Security Assessor）による監査を受ける組織では、Security Hub の PCI DSS Standards レポートを証跡として活用できます。

Standards 3種 比較サマリー

3-3. Standards 選定フローチャート

業界要件・コンプライアンス目標・監査要件の3軸で有効化する Standards を決定します。

組織の業界要件を確認する
│
├─【決済/金融】カード会員データを扱う EC サイト・金融機関
│└─ PCI DSS + FSBP の両立 (PCI DSS は必須 / FSBP は全体ベースライン)
│
├─【外部監査あり】セキュリティ認証取得・定期監査を受ける組織
│└─ CIS Benchmarks + FSBP の組み合わせ
│ ├─ CIS v3.0 (最新・より広範なカバレッジ)
│ └─ CIS v1.4 (既存監査基準が v1.4 を参照している場合はこちら)
│
└─【特定業界要件なし】SaaS / 社内システム / スタートアップ
 └─ FSBP のみで開始 → 監査要件が発生した時点で CIS を追加

Standards は Config ルールとして実装されるため、有効化する Standards 数が増えると AWS Config の評価数が増加しコストが上昇します。FSBP のみで月次数千円〜（評価対象リソース数に依存）、全 Standards 有効化で 2〜3 倍程度のコスト増を見込んで予算計画を立てます。

3-4. Findings Aggregation — 多様なソースからの統合受信

Security Hub は以下の統合ソースから Finding を受信します。

自動統合サービス（Security Hub 有効化後に自動で統合）:

カスタム統合（ASFF 形式で任意のシステムから送信可能）:

import boto3

client = boto3.client('securityhub', region_name='ap-northeast-1')

response = client.batch_import_findings(
 Findings=[{
  'SchemaVersion': '2018-10-08',
  'Id': 'custom-scan-2026-001',
  'ProductArn': 'arn:aws:securityhub:ap-northeast-1:123456789012:product/123456789012/default',
  'GeneratorId': 'in-house-security-scanner',
  'AwsAccountId': '123456789012',
  'Types': ['Software and Configuration Checks/AWS Security Best Practices'],
  'CreatedAt': '2026-05-12T00:00:00Z',
  'UpdatedAt': '2026-05-12T00:00:00Z',
  'Severity': {'Label': 'HIGH'},
  'Title': '社内スキャン: 未暗号化 S3 バケット検出',
  'Description': '暗号化設定のない S3 バケットが検出されました。',
  'Resources': [{'Type': 'AwsS3Bucket', 'Id': 'arn:aws:s3:::example-unencrypted-bucket'}]
 }]
)

既知の False Positive（開発環境の設定違反 / 許容済みの設定）には Suppression Rule を設定し、ワークフローステータスを SUPPRESSED に自動設定することで、アナリストが本物の脅威に集中できる環境を確保します。

aws securityhub create-automation-rule \
  --rule-name "suppress-dev-low-findings" \
  --rule-order 100 \
  --actions '[{"Type":"FINDING_FIELDS_UPDATE","FindingFieldsUpdate":{"Workflow":{"Status":"SUPPRESSED"}}}]' \
  --criteria '{"ResourceTags":[{"Key":"Environment","Value":"dev","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"LOW","Comparison":"EQUALS"}]}'

3-5. Security Score — 計算ロジックと実務的解釈

Security Score（0〜100点） は、有効な Standards Controls の通過率を Severity 重み付きで算出します。

重み付きスコア = Σ(PASSED Controls × Severity重み) / Σ(全有効Controls × Severity重み) × 100

Severity 別の重み:

Score の実務目安:

Security Score は Standards 単位（FSBP / CIS / PCI DSS）で個別に算出されます。全体スコアが高くても特定 Standards のスコアが低い場合、その Standards に関連する Controls を集中改善する戦略が有効です。

3-6. Custom Insights — 業界要件に応じた独自集計

Custom Insights は Finding を任意の条件でフィルタリング・集計するダッシュボードクエリです。Alert Fatigue を防ぎながら重要な Finding を可視化するために活用します。

実装例: 過去7日間の CRITICAL Finding を製品別に集計

{
  "Name": "Critical-Findings-Last-7d-by-Product",
  "Filters": {
 "CreatedAt": [{"DateRange": {"Value": 7, "Unit": "DAYS"}}],
 "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}],
 "WorkflowStatus": [{"Value": "SUPPRESSED", "Comparison": "NOT_EQUALS"}]
  },
  "GroupByAttribute": "ProductName"
}

実務で有用な Custom Insights パターン:

aws securityhub create-insight \
  --name "Critical-Findings-Last-7d-by-Product" \
  --filters '{"CreatedAt":[{"DateRange":{"Value":7,"Unit":"DAYS"}}],"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --group-by-attribute "ProductName"

3-7. セキュリティ Vol1 との地続き設計

本記事（Vol2）の Security Hub 活用は、セキュリティシリーズ Vol1「セキュリティ運用入門 — 脅威検出 / コンプライアンス / ログ集約」で扱った コンプライアンス評価の概念 を実装レベルに深化させたものです。

Vol1 では「脅威検出 / コンプライアンス / ログ集約」という3本柱を概説しました。Vol2（本記事）では Standards Controls による継続的コンプライアンス評価の自動化と Security Score の実務活用まで踏み込みます。Vol1 を読了済みの方は、Standards Controls の評価結果を Vol1 で学んだ CloudTrail ログ集約と組み合わせることで、Finding の根拠トレースまで一貫した SOC 運用フローを確立できます。

3-8. Observability Vol1 との連携

Observability実践 Vol1「Application Signals × SLO × X-Ray」で構築した CloudWatch ダッシュボードに、Security Hub の Finding 状況を統合できます。

Security Hub の Finding 発生を EventBridge ルールで検知し、CloudWatch にカスタムメトリクスとして送信することで、アプリケーション可観測性とセキュリティ状態を統合したダッシュボードを実現します。EventBridge → Lambda (put_metric_data) → CloudWatch Dashboard という連携により、アプリケーション障害とセキュリティ検出の相関（例: SLO エラー率急上昇時に GuardDuty CryptoCurrency Finding も同時発生）を視覚的に把握でき、根本原因分析の精度が向上します。

4. Detective Investigation (山場2) — Behavior Graph / Finding context / Triage workflow / Cross-service correlation

sequenceDiagram
  GuardDuty->>SecurityHub: Finding送信
  SecurityHub->>Detective: Investigate
  Detective->>Detective: Behavior Graph構築
  Detective->>Analyst: Context提供(Entity/Timeline)
  Analyst->>SecurityHub: 対応ステータス更新

4-1. Amazon Detective とは — Finding 起点の深掘り調査サービス

Amazon Detective は、GuardDuty や Security Hub が検出した Finding の「なぜ・誰が・どこから」を深掘り調査するための Machine Learning ベースのセキュリティ調査サービスです。GuardDuty が「脅威を検出する」サービスであるのに対し、Detective は「検出された脅威を調査する」サービスとして補完的な役割を担います。

Detective が解決する課題:

Detective が自動収集・分析するデータソース:
– VPC Flow Logs: ネットワーク通信の送受信レコード
– CloudTrail: AWS API 呼び出しの全履歴
– GuardDuty Findings: 脅威検出結果（Detective の入力として活用）
– EKS 監査ログ: Kubernetes API サーバーへのアクセス履歴（EKS Protection と連携）

Detective は有効化後 2〜4 週間で機械学習モデルが各 Entity のベースラインを構築します。ベースライン構築前は Behavior Graph が不完全なため、有効化直後の調査精度は低くなります。本番 SOC 運用への組み込みは有効化から1ヶ月後を目安に設定するのが実務上の推奨です。

4-2. Behavior Graph 構造 — Entity 間の Relationship 可視化

Behavior Graph（ビヘイビアグラフ） は Detective の中核概念で、AWS リソース（Entity）間の関係性と行動パターンを時系列でグラフ構造として可視化します。

Detective が扱う Entity 種別:

Behavior Graph の分析イメージ（実際の Detective コンソールでは視覚グラフで表示）:

[IAM Role: web-app-role]
 │ CloudTrail: 通常の API 呼び出し履歴
 │ 通常: ap-northeast-1 / 9:00-18:00 / GetObject・PutObject のみ
 │
 ├─ 2026-05-12 03:15 UTC【異常検出】us-east-1 から ListBuckets + GetObject（全バケット）
 │└─ GuardDuty Finding: UnauthorizedAccess:IAMUser/TorIPCaller
 │
 └─ 接続元 IP: 198.51.100.1（Tor 出口ノード / Anonymous Proxy）
  └─ VPC Flow Logs: 当該 IP からの inbound 接続なし → コンソールアクセスと判定

Behavior Graph により「GuardDuty の Finding が示す異常が通常の行動範囲からどれだけ逸脱しているか」を過去90日間のベースラインと照らして定量評価できます。

機械学習モデルの活用: Detective は収集したログを機械学習モデルで分析し、各 Entity の「通常の行動プロファイル（ベースライン）」を自動構築します。Finding 発生時に現在の行動とベースラインを比較することで、「このアクセスは本当に異常か（True Positive）」「通常の範囲内か（False Positive）」を定量的に判断できます。

4-3. Finding Context — 「誰がいつどこから」の補完

GuardDuty Finding 単体では、以下の情報に限界があります。

Finding context の実践例として、GuardDuty Finding「CredentialAccess:IAMUser/AnomalousBehavior」を調査するシナリオを考えます。

Step 1: GuardDuty Finding の受信

Finding タイプ: CredentialAccess:IAMUser/AnomalousBehavior
Severity: HIGH
Principal: arn:aws:iam::123456789012:user/deploy-user
Action: GetSecretValue (Secrets Manager)
Region: ap-northeast-1
Time: 2026-05-12T14:32:00Z

Step 2: Detective で Behavior Graph を確認

deploy-user の行動プロファイル（過去90日間）:
  通常: CodeBuild サービスロール経由でのみ呼び出し
  GetSecretValue = 0回（過去90日間で初回）
  今回: コンソールログインから直接 GetSecretValue を実行
  接続元 IP: 203.0.113.50（過去未登場の IP アドレス）
  前後の API: DescribeSecrets → GetSecretValue → AssumeRole（別ロール）

このコンテキストが示すのは「deploy-user のクレデンシャルが第三者に窃取され、シークレット値の取得と権限昇格が試みられた可能性が高い」という判断根拠です。Finding 単体の情報だけでは False Positive と判断してしまいかねない状況でも、Behavior Graph のコンテキストが True Positive の確信度を高めます。

4-4. Triage Workflow — Finding 受信から対応判定まで

Triage（トリアージ） は、Finding を重要度・緊急度に基づいて評価し、「対応する / 抑制する / エスカレーションする」を判断するプロセスです。Detective を活用した推奨 Triage Workflow は以下の5ステップです。

Step 1: Finding 受信（Security Hub / GuardDuty）
└─ Severity ≥ HIGH → Triage 対象として抽出
│
Step 2: 初期評価（所要時間目安: 5分）
└─ Finding タイプ・対象リソース・発生時刻を確認
└─ 既知の False Positive パターンか？ → YES → SUPPRESSED に設定してクローズ
│ NO（判断不能）
Step 3: Behavior Graph 確認（所要時間目安: 10〜15分）
└─ Detective で対象 Entity のプロファイルを確認
└─ 通常の行動範囲か？ → YES → False Positive → SUPPRESSED
│ NO（行動ベースラインから逸脱）
Step 4: Cross-service Correlation（所要時間目安: 10〜15分）
└─ VPC Flow Logs で不審なネットワーク通信を確認
└─ CloudTrail で前後の API 呼び出し連鎖を確認
└─ 複数の Evidence が相関 → True Positive と判断
│
Step 5: 対応判定（所要時間目安: 5分）
└─ True Positive → 担当チームへ通知 / ワークフロー IN_PROGRESS に更新
└─ 証拠を Security Hub Finding のメモとして記録
└─ 対応完了後 RESOLVED に設定

Triage Workflow の自動化（EventBridge 連携）:

# HIGH 以上の Finding を EventBridge 経由で Slack 通知するルール
aws events put-rule \
  --name "high-severity-finding-alert" \
  --event-pattern '{
 "source": ["aws.securityhub"],
 "detail-type": ["Security Hub Findings - Imported"],
 "detail": {
"findings": {
  "Severity": {"Label": ["HIGH", "CRITICAL"]},
  "Workflow": {"Status": ["NEW"]}
}
 }
  }'

Triage 時間の短縮効果: Detective を活用しない従来の Triage では、アナリストが CloudTrail コンソール・VPC Flow Logs・GuardDuty コンソールを個別に切り替えながら手動で調査する必要がありました。Detective の Behavior Graph を中心に据えた Triage Workflow では、同等の調査を Detective コンソール上でほぼ完結させられるため、平均 Triage 時間を従来比 50〜70% 短縮できるケースが報告されています。

4-5. Cross-service Correlation — VPC Flow Logs / CloudTrail / GuardDuty の統合分析

Cross-service correlation（クロスサービス相関分析） は、単一のログソースでは見えない攻撃パターンを複数データソースの突き合わせによって可視化する手法です。Detective はこの相関分析を自動化します。

実践的な相関分析シナリオ:

シナリオ: EC2 インスタンスからのデータ持ち出し調査

GuardDuty Finding:
  タイプ: Exfiltration:S3/AnomalousBehavior
  対象: EC2 instance i-0abcdef1234567890
  内容: 異常な数の S3 GetObject リクエスト

Detective での Cross-service Correlation:
  ┌─ VPC Flow Logs 分析 ────────────────────────────────────┐
  │ 14:00-14:30: i-0abcdef → 198.51.100.5:443（外部 IP） │
  │ 転送量: 2.3 GB（通常の月次転送量を30分で超過） │
  │ 方向: OUTBOUND のみ（外部への送信）  │
  └───────────────────────────────────────────────────────────┘
  ┌─ CloudTrail 分析 ──────────────────────────────────────┐
  │ 13:55: SSH キーペアのダウンロード（通常外のアクション）  │
  │ 13:58: S3 ListBuckets（全バケット列挙）│
  │ 14:00-14:30: S3 GetObject × 1,240 件（大量） │
  │ 14:31: DeleteTrail 試行 → AccessDenied（失敗）  │
  └───────────────────────────────────────────────────────────┘

Cross-service 相関から導き出されたタイムライン:
  13:55 認証情報取得 → 13:58 偵察（バケット列挙）→
  14:00 データ持ち出し開始 → 14:31 証跡削除試行（失敗）
  ⇒ 段階的な攻撃フロー（MITRE ATT&CK: Discovery → Exfiltration → Defense Evasion）

Detective の Behavior Graph ビューでは、この時系列を視覚的に把握できるため、アナリストが複数のコンソールを切り替えながらログを手動で突き合わせる作業を大幅に削減できます。

EKS Protection との連携: GuardDuty EKS Protection が検出した Finding（Kubernetes API への不審なアクセスなど）も Detective の Behavior Graph に統合されます。コンテナ環境での異常アクセスを EC2 ネットワーク通信や IAM API 呼び出しと突き合わせた調査が可能です。詳細は EKS本番運用 Vol1〜3 を参照してください。

4-6. IAM Vol1-4 との連携 — Detective による IAM Identity 調査

Detective は IAM Principal（IAM User / IAM Role）を起点とした調査に特に強みを発揮します。これは IAM シリーズ（Vol1〜4）で学んだ IAM 設計の実務応用です。

IAM Vol1「IAM ポリシー設計入門」で学んだ最小権限原則に基づいた IAM 設計が実装されていると、Detective の Behavior Graph で「この IAM Role が通常呼ぶはずのない API を呼び出した」という異常を精密に検出できます。権限が絞られているほど、ベースラインからの逸脱が明確になるためです。

IAM Vol2「マルチアカウント IAM 設計」および IAM Vol4「STS クロスアカウント」で扱った Cross-Account の AssumeRole は、Detective での調査において特に重要なトレースポイントです。クレデンシャルが窃取された後に AssumeRole で他アカウントに侵入するラテラルムーブメント（横展開）を Detective の Behavior Graph で可視化できます。

[アカウント A: 侵害された IAM Role]
 │
 └─ AssumeRole → [アカウント B の IAM Role]
 │
 ├─ S3 GetObject（機密データへのアクセス）
 └─ EC2 DescribeInstances（偵察）

IAM Vol3「IAM 権限棚卸し自動化」で構築した IAM Access Analyzer の検出結果は、Security Hub 経由で Detective に連携されます。外部アクセス可能なリソースの発見（IAM Access Analyzer Finding）から、実際の不正アクセス試行（GuardDuty Finding）まで、一連の調査を Detective の Behavior Graph で繋げられます。

5. Multi-Account Aggregator 設計 — Organizations / delegated admin / Cross-Region / Terraform完全例

5-1. なぜ Multi-Account Aggregator が必要か — 単一アカウント運用の限界

大規模な AWS 環境では Organizations 配下に数十〜数百のアカウントが存在する。GuardDuty や Security Hub を各アカウントで個別に有効化した場合、セキュリティチームはアカウントごとにコンソールへログインして Findings を確認しなければならない。この「サイロ化された脅威検出」は運用上の重大な死角を生む。

単一アカウント運用の限界:

Multi-Account Aggregator が解決すること:

Organizations 全体の GuardDuty/Security Hub Findings を単一の集約先（セキュリティアカウント）に統合し、セキュリティチームが「全アカウント・全リージョン横断」で Findings を可視化・対応判定できる状態を実現する。GuardDuty の脅威検出と Security Hub の Standards 評価を一元管理することで、アラート対応の優先度付けも格段に効率化される。

5-2. Organizations + delegated admin 設計

管理アカウントは最小権限で — セキュリティアカウントへの管理委任

Organizations の管理アカウントは組織全体を制御する強大な権限を持つため、GuardDuty/Security Hub の日常運用拠点として直接使用することは推奨されない。delegated admin（管理委任） を活用し、専用のセキュリティアカウントに運用を委任するのが本番設計の鉄則だ。

推奨アカウント構成:

Organizations Root (管理アカウント)
├── Security OU
│└── セキュリティアカウント  ← delegated admin 先
│ ├── GuardDuty: 全アカウント Findings 集約・管理
│ ├── Security Hub: 全アカウント Findings + Standards 評価
│ └── Detective: Behavior Graph 調査拠点
├── Workload OU
│├── 本番アカウント (Prod) ← メンバーアカウント (自動参加)
│├── ステージング (Staging)  ← メンバーアカウント (自動参加)
│└── 開発アカウント (Dev) ← メンバーアカウント (自動参加)
└── Sandbox OU
 └── 検証アカウント  ← 除外設定も可

delegated admin 委任の流れ:

1. 管理アカウントで Organizations のサービス統合を有効化 (aws organizations enable-aws-service-access)
2. 管理アカウントからセキュリティアカウントを delegated admin に指定（GuardDuty/Security Hub それぞれ）
3. セキュリティアカウントで Organization 設定を構成（auto_enable = true で新規アカウント自動参加）
4. 管理アカウントでの GuardDuty/Security Hub 直接操作を SCP で制限し最小権限を維持

マルチアカウント基盤との連携

Multi-Account Aggregator を最大限活用するには、Organizations 基盤が正しく整備されていることが前提となる。Control Tower による Landing Zone 構築、SCP によるガードレール、Account Factory による新規アカウントの自動プロビジョニングが揃って初めて、Aggregator の自動展開が機能する。

Organizations 基盤の設計については、マルチアカウント運用入門 — Organizations × Control Tower × Landing Zone を参照。本 Vol2 のセキュリティ Aggregator と組み合わせることで、「Organizations基盤 × SOC統合」の完全な構成を実現できる。

5-3. Cross-Region Aggregation — リージョン別 Finding を1箇所に集約

GuardDuty と Security Hub はリージョンサービスであるため、東京リージョン（ap-northeast-1）で有効化しても、バージニア（us-east-1）やオレゴン（us-west-2）の Findings は別リージョンで管理される。グローバル展開環境では、各リージョンの Findings を個別確認する必要が生じる。

Security Hub Finding Aggregator を活用すると、指定したホームリージョンに全リージョンの Findings を自動集約できる。

5-4. Terraform 完全例 — delegated admin + Cross-Region Aggregation

Multi-Account Aggregator の中核となる3リソース（aws_securityhub_organization_admin_account / aws_guardduty_organization_admin_account / aws_securityhub_finding_aggregator）を Terraform で構成する。管理アカウントとセキュリティアカウントを別 Provider で定義し、それぞれのスコープで適切なリソースをデプロイする点が設計の核心だ。

providers.tf:

terraform {
  required_version = ">= 1.5.0"
  required_providers {
 aws = {
source  = "hashicorp/aws"
version = "~> 5.0"
 }
  }
}

# 管理アカウント用 Provider — delegated admin 委任を実施
provider "aws" {
  alias  = "management"
  region = "ap-northeast-1"
  assume_role {
 role_arn = "arn:aws:iam::${var.management_account_id}:role/OrganizationRole"
  }
}

# セキュリティアカウント用 Provider — Aggregator / Organization 設定を実施
provider "aws" {
  alias  = "security"
  region = "ap-northeast-1"
  assume_role {
 role_arn = "arn:aws:iam::${var.security_account_id}:role/SecurityAdminRole"
  }
}

main.tf:

# -----------------------------------------------------------------------
# Security Hub delegated admin 委任 (管理アカウントで実施)
# -----------------------------------------------------------------------
resource "aws_securityhub_organization_admin_account" "security" {
  provider= aws.management
  admin_account_id = var.security_account_id

  depends_on = [aws_organizations_organization.main]
}

# -----------------------------------------------------------------------
# GuardDuty delegated admin 委任 (管理アカウントで実施)
# -----------------------------------------------------------------------
resource "aws_guardduty_organization_admin_account" "security" {
  provider= aws.management
  admin_account_id = var.security_account_id

  depends_on = [aws_organizations_organization.main]
}

# -----------------------------------------------------------------------
# Security Hub Organization 設定 (セキュリティアカウントで実施)
# -----------------------------------------------------------------------
resource "aws_securityhub_organization_configuration" "main" {
  provider  = aws.security
  auto_enable  = true
  auto_enable_standards = "DEFAULT"

  depends_on = [aws_securityhub_organization_admin_account.security]
}

# -----------------------------------------------------------------------
# Security Hub Finding Aggregator — Cross-Region 集約 (セキュリティアカウントで実施)
# -----------------------------------------------------------------------
resource "aws_securityhub_finding_aggregator" "all_regions" {
  provider  = aws.security
  linking_mode = "ALL_REGIONS"
  # ALL_REGIONS: 現在 + 将来追加される全リージョンを自動集約対象にする
  # SPECIFIED_REGIONS: 特定リージョンのみ集約する場合は regions パラメータでリスト指定

  depends_on = [aws_securityhub_organization_configuration.main]
}

# -----------------------------------------------------------------------
# GuardDuty 検出器 (セキュリティアカウントで実施)
# -----------------------------------------------------------------------
resource "aws_guardduty_detector" "security" {
  provider = aws.security
  enable= true

  datasources {
 s3_logs { enable = true }
 kubernetes {
audit_logs { enable = true }
 }
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes { enable = true }
}
 }
  }
}

# -----------------------------------------------------------------------
# GuardDuty Organization 設定 — メンバーアカウントへの自動展開
# -----------------------------------------------------------------------
resource "aws_guardduty_organization_configuration" "main" {
  provider = aws.security
  auto_enable = "ALL"
  detector_id = aws_guardduty_detector.security.id

  datasources {
 s3_logs { auto_enable = true }
 kubernetes {
audit_logs { enable = true }
 }
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes { auto_enable = true }
}
 }
  }

  depends_on = [aws_guardduty_organization_admin_account.security]
}

variables.tf:

variable "management_account_id" {
  description = "AWS Organizations 管理アカウントの ID"
  type  = string
}

variable "security_account_id" {
  description = "delegated admin に指定するセキュリティアカウントの ID"
  type  = string
}

5-5. まとめ — Multi-Account Aggregator で組織全体の脅威を一元把握

delegated admin と Cross-Region Aggregation を組み合わせた Multi-Account Aggregator を展開することで、GuardDuty/Security Hub の Findings を組織全体で一元管理できる状態を実現できる。セキュリティアカウントを単一の可視化・対応判定拠点として確立することが、本番 SOC 運用の出発点となる。

前述のとおり、本構成は Organizations 基盤（Control Tower / Landing Zone / SCP）が整備されていることを前提とする。マルチアカウント運用入門 — Organizations × Control Tower × Landing Zone の Control Tower Account Factory と組み合わせることで、新規アカウント追加時の GuardDuty/Security Hub 自動展開を完全に自動化できる。

6. 詰まりポイント7選 図解

6-1. Alert Fatigue — Critical Finding が埋もれる Severity 設計ミス

原因:

GuardDuty の Finding が1日数十〜数百件発生する環境で、Severity 区分 (LOW/MEDIUM/HIGH/CRITICAL) を考慮せずに「全 Finding → EventBridge → Slack」と直結すると、対応が必要な CRITICAL Finding がノイズに埋もれる。セキュリティチームは通知疲れに陥り、重要アラートを見逃すリスクが高まる。

対処:

Security Hub の Custom Insights と EventBridge の Severity フィルタを組み合わせて、本番対応が必要な Finding のみを通知チャンネルに転送する。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
 "findings": {
"Severity": {
  "Label": ["HIGH", "CRITICAL"]
},
"RecordState": ["ACTIVE"]
 }
  }
}

Custom Insights 設定例: Security Hub コンソール → Insights → Create custom insight で filter を Severity.Label = ["HIGH", "CRITICAL"] AND RecordState = "ACTIVE" と設定し、SOC ダッシュボード冒頭に固定表示する。LOW/MEDIUM Finding は週次バッチレビューに回し、24時間 on-call 対応から除外する運用設計が現実解だ。

6-2. False Positive — 既知の運用 Traffic が Finding 化される

原因:

GuardDuty は通常のペネトレーションテストやセキュリティスキャナーの通信、あるいは設計上許可した IP からのアクセスを「Unauthorized Access」または「Recon」として検知することがある。False Positive を放置すると、Custom Insights の件数が歪んで本物の脅威検出精度が下がる。

対処:

GuardDuty の Suppression Rule と Security Hub の Suppression を使い分け、既知の正常通信を抑制する。

• GuardDuty Suppression Rule: Finding Type (Recon:EC2/PortProbeUnprotectedPort) + 送信元 IP リストを条件にして、特定の脆弱性スキャナー IP からの偵察 Finding を抑制
• Security Hub Suppression: SUPPRESSED WorkflowStatus を使い、False Positive 確認済みの Finding を集計から除外
• Custom Insights で SUPPRESSED Finding の件数推移を定期モニタリングし、過剰な抑制が起きていないことを確認

# GuardDuty Suppression Rule 作成 (AWS CLI)
aws guardduty create-filter \
  --detector-id <DETECTOR_ID> \
  --name "suppress-pentest-scanner" \
  --action ARCHIVE \
  --finding-criteria '{
 "Criterion": {
"type": {
  "Equals": ["Recon:EC2/PortProbeUnprotectedPort"]
},
"service.action.networkConnectionAction.remoteIpDetails.ipAddressV4": {
  "Equals": ["192.0.2.10", "198.51.100.20"]
}
 }
  }'

6-3. Auto-Remediation 暴走 — 自動対応で正常 Traffic が遮断される

原因:

「GuardDuty Finding → EventBridge → Lambda → Security Group 自動変更」という Auto-Remediation パイプラインを False Positive の検証なしに全 Finding に適用すると、正常なサービスのネットワーク通信を遮断してしまう。特に Staging/Prod 環境で全 Finding を自動対応すると、大規模障害につながるリスクがある。

対処:

Auto-Remediation は段階的に展開し、最初は Dry-run mode で動作確認してから本番適用する。

# Auto-Remediation Lambda (Dry-run フラグ付き)
resource "aws_lambda_function" "auto_remediation" {
  function_name = "guardduty-auto-remediation"
  handler = "index.handler"
  runtime = "python3.12"
  role = aws_iam_role.remediation_role.arn
  filename= data.archive_file.lambda_zip.output_path

  environment {
 variables = {
DRY_RUN= "true"  # false に変更してから本番稼働
NOTIFY_SNS_ARN  = aws_sns_topic.security_alert.arn
SEVERITY_THRESHOLD = "HIGH"  # CRITICAL のみ or HIGH以上 を設定
 }
  }
}

段階的展開プラン:

1. Phase 1 (Dry-run): Lambda が「この Finding に対しこの対応を実行する予定」とログ出力のみ。実際の API コールなし。
2. Phase 2 (Dev 環境のみ): Dev アカウントの GuardDuty Finding にのみ自動対応を有効化。2週間の動作検証。
3. Phase 3 (Severity CRITICAL のみ): 本番環境では Severity CRITICAL に限定し AUTO 対応を有効化。HIGH は通知のみ。
4. Phase 4 (HIGH 追加): Phase 3 の False Positive 件数がゼロ継続後、HIGH Severity に拡大。

6-4. Cross-Account 漏れ — 一部アカウントが Aggregator に未統合

原因:

Organizations の Aggregator 設定時に auto_enable = true を設定しても、設定前に作成されたアカウントや、OU 構造変更で一時的に除外されたアカウントが Aggregator に参加していないケースがある。特に大規模組織ではサンドボックス OU のアカウントが見落とされやすい。

対処:

Organizations コンソール → Security Hub → Member accounts で全アカウントの Status が Enabled または Auto-enabled になっていることを定期確認する。

# Organization 配下の Security Hub メンバーアカウント一覧確認 (未統合アカウント検出)
aws securityhub list-members \
  --only-associated \
  --query 'Members[?MemberStatus!=`Enabled`].{AccountId:AccountId,Status:MemberStatus}' \
  --output table

# GuardDuty メンバーアカウント確認 (未参加アカウント検出)
aws guardduty list-members \
  --detector-id <DELEGATED_ADMIN_DETECTOR_ID> \
  --query 'Members[?RelationshipStatus!=`Enabled`].{AccountId:AccountId,Status:RelationshipStatus}' \
  --output table

さらに、Organizations Conformance Pack を活用してアカウント参加状況を Config Rules で継続監視することで、未統合アカウントを自動検知できる体制を整える。

6-5. Cross-Region 漏れ — リージョン別運用で集約抜け

原因:

Security Hub Finding Aggregator を設定しても、linking_mode = "SPECIFIED_REGIONS" で特定リージョンのみを指定した場合、後から有効化した新リージョン (例: ap-southeast-1) の Findings が自動集約対象に含まれない。グローバル展開後に新リージョンを追加するたびに手動でリージョンを追加する必要が生じる。

対処:

Finding Aggregator は linking_mode = "ALL_REGIONS" を推奨。将来追加されるリージョンも自動でカバーされる。

# 推奨: ALL_REGIONS モード (将来追加リージョンも自動集約)
resource "aws_securityhub_finding_aggregator" "main" {
  provider  = aws.security
  linking_mode = "ALL_REGIONS"
  # regions パラメータは不要 (ALL_REGIONS 時は指定不可)
}

# 非推奨: SPECIFIED_REGIONS (リージョン追加のたびに手動変更が必要)
# resource "aws_securityhub_finding_aggregator" "main" {
#linking_mode = "SPECIFIED_REGIONS"
#specified_regions = ["ap-northeast-1", "us-east-1"]
## → 新リージョン追加時の更新漏れが頻発
# }

GuardDuty についても同様で、セキュリティアカウントの GuardDuty Organization Configuration で新リージョン有効化時に自動参加されることを確認する。aws guardduty list-detectors を新リージョン指定で実行し、検出器が存在することを定期確認する習慣をつける。

6-6. Cost 爆発 — Malware Protection・S3 Protection の全対象適用

原因:

GuardDuty の Malware Protection を全 EC2 インスタンスに適用し、S3 Protection を全バケットに適用すると、スキャン費用がデータ量に比例して急増する。特に大容量データを扱う S3 バケット (ログアーカイブ/データレイク) への S3 Protection 適用は月額コストが急騰する要因になる。

コスト試算例 (概算):

対処:

Protection の適用対象を絞り込み、コスト効果の高い対象のみに限定する。

# GuardDuty: Malware Protection と S3 Protection を選択的に有効化
resource "aws_guardduty_detector" "security" {
  enable = true

  datasources {
 # S3 Protection: 高リスクバケット (公開受付/ユーザーアップロード) のみ有効
 s3_logs {
enable = true  # バケットレベルの絞り込みは GuardDuty Malware Protection Plan で行う
 }

 # Malware Protection: スキャン対象 EC2 を Tag でフィルタリング
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes {
 enable = true  # EC2 Tags で "MalwareScan=enabled" タグの付いた対象のみスキャン
  }
}
 }
  }
}

コスト最適化の参照先として、コスト最適化入門 — Cost Explorer × Budgets × Compute Optimizer の Cost Anomaly Detection と GuardDuty コストの連携設計も有効だ。GuardDuty のサービス行を Cost Explorer で週次モニタリングし、想定外のコスト増加を早期検知する体制を整えておく。

6-7. Detective 未活用 — Finding 受信のみで Behavior Graph 未確認

原因:

Security Hub に GuardDuty Findings が集約されているにもかかわらず、Detective の Behavior Graph まで掘り下げる習慣がないと、「誰がいつどこから何をしたか」という調査が不完全なままになる。Detective は GuardDuty Finding を「入り口」として Behavior Graph を活用してこそ真価を発揮するが、コンソールを開かない運用が常態化しているチームが多い。

対処:

セキュリティチームの対応フローに Behavior Graph 確認を必須ステップとして組み込む。

Detective 活用 Triage Workflow:

1. Security Hub で HIGH/CRITICAL Finding を検知
2. Finding の「Actions」→「Investigate in Detective」を選択
3. Detective Behavior Graph で Finding に紐づく Entity (IAM Principal / EC2 / VPC) を展開
- 過去30日間のベースライン API コール頻度と比較
- 通常と異なる AWS リージョンからのアクセスを確認
4. Cross-service correlation パネルで関連 Finding を横断確認
- 同一 IP から複数アカウントへのアクセス試行がないか
- GuardDuty Finding と CloudTrail の API エラー急増が時系列で一致するか
5. True Positive → エスカレーション対応 / False Positive → Suppression Rule 追加
6. 判定根拠を Security Hub Finding の Note フィールドに記録

復旧・対応連携の参照先:
– 復旧運用編 Vol1 (Backup/DR) — データ侵害 Finding 検知後のバックアップ確認フロー
– 復旧運用編 Vol2 (Chaos Engineering/FIS) — 脅威検知後のレジリエンス検証
– 復旧運用編 Vol3 (対応自動化) — Threat Detection 後の自動対応フロー設計
– 復旧運用編 Vol4 (マルチリージョン) — クロスリージョン脅威への対応

7. アンチパターン→正解パターン変換演習 (Terraform + AWS CLI + EventBridge 3形式)

演習1: GuardDuty Terraform — datasources ブロック欠落

アンチパターン:

# 問題: datasources ブロックが省略されている
resource "aws_guardduty_detector" "main" {
  enable = true
  # datasources を省略 → Malware Protection/EKS Protection/S3 Protection が無効のまま
}

問題点: datasources ブロックを省略すると GuardDuty の基本 Threat Detection (VPC Flow Logs/CloudTrail/DNS) のみが有効化され、Malware Protection・EKS Protection・S3 Protection がすべて無効のままになる。GuardDuty が「動いているつもり」で Protection の穴ができる典型的なミスだ。

正解パターン:

resource "aws_guardduty_detector" "main" {
  enable  = true
  finding_publishing_frequency = "SIX_HOURS"  # 本番では FIFTEEN_MINUTES も検討

  datasources {
 # S3 Protection: S3 API コール異常検知 (データ流出検知に必須)
 s3_logs {
enable = true
 }

 # EKS Protection: EKS Audit Log 解析
 kubernetes {
audit_logs {
  enable = true
}
 }

 # Malware Protection: EC2 EBS スキャン
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes {
 enable = true
  }
}
 }
  }
}

解説: finding_publishing_frequency は FIFTEEN_MINUTES / ONE_HOUR / SIX_HOURS から選択。セキュリティ要件が高い本番環境では FIFTEEN_MINUTES を指定し、Active Findings の検知から通知までのタイムラグを最小化する。

演習2: Security Hub Findings 全件 Slack 通知 → Severity HIGH+ のみ通知に変更

アンチパターン:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"]
}

問題点: この EventBridge Rule は Security Hub の全 Findings (Severity LOW〜CRITICAL) をすべてターゲットに転送する。Slack への全件通知は1日数百件のノイズを生み出し、対応チームの Alert Fatigue の最大要因となる。

正解パターン:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
 "findings": {
"Severity": {
  "Label": ["HIGH", "CRITICAL"]
},
"RecordState": ["ACTIVE"],
"WorkflowState": ["NEW"]
 }
  }
}

# EventBridge Rule を AWS CLI で更新
aws events put-rule \
  --name "securityhub-high-critical-only" \
  --event-pattern '{
 "source": ["aws.securityhub"],
 "detail-type": ["Security Hub Findings - Imported"],
 "detail": {
"findings": {
  "Severity": {"Label": ["HIGH", "CRITICAL"]},
  "RecordState": ["ACTIVE"],
  "WorkflowState": ["NEW"]
}
 }
  }' \
  --state ENABLED

解説: WorkflowState = "NEW" を追加することで、一度対応した (NOTIFIED / RESOLVED) Finding が再通知されるのを防ぐ。Slack 通知は NEW HIGH/CRITICAL Finding のみとし、MEDIUM/LOW は Security Hub コンソールの Custom Insights ダッシュボードで週次レビューする運用に切り替える。

演習3: Auto-Remediation 暴走 → 段階的 Auto-Remediation + Dry-run mode

アンチパターン:

# 問題: Severity フィルタなしで全 Finding に Auto-Remediation を即時適用
resource "aws_cloudwatch_event_rule" "auto_remediation_all" {
  name = "auto-remediation-all-findings"
  event_pattern = jsonencode({
 source= ["aws.guardduty"]
 detail-type = ["GuardDuty Finding"]
 # Severity フィルタなし → LOW Finding でも自動対応が走る
  })
}

問題点: Severity フィルタなしで全 Finding に Auto-Remediation を適用すると、LOW Severity の偵察 Finding (Recon:EC2/PortProbe 等) に対しても Security Group 変更や EC2 停止が実行される。False Positive 1件で本番サービスが停止するリスクがある。

正解パターン:

# Step1: Dry-run モード付き Lambda (実際の対応は行わずログのみ)
resource "aws_lambda_function" "auto_remediation" {
  function_name = "guardduty-auto-remediation"
  handler = "index.handler"
  runtime = "python3.12"
  role = aws_iam_role.remediation_role.arn
  filename= data.archive_file.lambda_zip.output_path

  environment {
 variables = {
DRY_RUN= "true"  # 本番稼働前に false へ変更
SEVERITY_THRESHOLD = "CRITICAL"  # まず CRITICAL のみで開始
TARGET_ACCOUNT_ID  = var.target_account_id
 }
  }
}

# Step2: CRITICAL Finding のみ対象 (HIGH は通知のみ)
resource "aws_cloudwatch_event_rule" "auto_remediation_critical" {
  name = "auto-remediation-critical-only"
  event_pattern = jsonencode({
 source= ["aws.guardduty"]
 detail-type = ["GuardDuty Finding"]
 detail = {
severity = [{ numeric = [">=", 9.0] }]  # CRITICAL (9.0+) のみ
 }
  })
}

解説: Auto-Remediation の安全な導入手順:
1. DRY_RUN = "true" で2週間稼働させ、CloudWatch Logs で「想定外の対象」がないか確認
2. Severity CRITICAL のみ (severity >= 9.0) で本番適用を開始
3. False Positive ゼロが2週間継続したら HIGH (>= 7.0) に拡大

演習4: Detective Behavior Graph 未活用 → Triage Workflow への組み込み

アンチパターン:

セキュリティチームの対応フローが次のような状態になっている:

1. Security Hub で HIGH Finding を検知
2. Finding の詳細画面で IP アドレスと Finding Type を確認
3. 手動で CloudTrail を検索してアクティビティを確認
4. 「問題なさそう」と判断して Finding を RESOLVED にする

問題点: CloudTrail の手動検索は「特定の API コール」しか検索できず、Entity (IAM Principal / EC2) の「過去の行動パターンとの乖離」を検出できない。Detective の Behavior Graph を使わないと、緩やかな権限昇格や長期的な異常通信パターンを見落とす。

正解パターン — Detective を組み込んだ Triage Workflow:

1. Security Hub で HIGH/CRITICAL Finding を検知
2. Finding の「Actions」→「Investigate in Detective」を選択
3. Detective Behavior Graph で Finding に紐づく IAM Principal を展開
- 過去30日間のベースライン API コール頻度と比較
- 通常と異なる AWS リージョンからのアクセスを確認
- 関連する EC2 / VPC / S3 のアクティビティを時系列で追跡
4. Cross-service correlation パネルで関連 Finding を横断確認
- 同一 IP から複数アカウントへのアクセス試行がないか
- GuardDuty Finding と CloudTrail の API エラー急増が時系列で一致するか
5. 判定:
- True Positive → エスカレーション対応フローへ
- False Positive → Suppression Rule を追加して Behavior Graph の根拠を記録
6. 判定根拠を Security Hub Finding の Note フィールドに記録

解説: Detective は追加料金なしで GuardDuty/Security Hub と統合される (Behavior Graph 分析料金は別途発生)。「Investigate in Detective」ボタンはコンソールから1クリックでアクセスでき、Learning period (約2週間) 後から Behavior Graph の正常ベースラインが確立されるため、新規 AWS 環境では Detective を早めに有効化しておくことが重要だ。

演習5: Cross-Account Aggregator 設定漏れ → delegated admin + Finding Aggregator 完全例

アンチパターン:

# 問題: 各アカウントで個別に Security Hub を有効化 (Organization 統合なし)
resource "aws_securityhub_account" "member_a" {
  provider = aws.account_a
  # Organization 統合なし → セキュリティアカウントに Findings が集約されない
}

resource "aws_securityhub_account" "member_b" {
  provider = aws.account_b
  # 同様に孤立した設定
}

問題点: 各アカウントで個別に aws_securityhub_account を有効化するだけでは Organization 統合が機能しない。セキュリティアカウントに Findings が集約されないため、Cross-Account 可視性がゼロのままとなる。

正解パターン — delegated admin + Finding Aggregator:

# -----------------------------------------------------------------------
# Security Hub delegated admin の委任 (管理アカウントで実施)
# -----------------------------------------------------------------------
resource "aws_securityhub_organization_admin_account" "security" {
  provider= aws.management
  admin_account_id = var.security_account_id

  depends_on = [aws_organizations_organization.main]
}

# -----------------------------------------------------------------------
# Organization 設定: 新規アカウントへの自動展開 (セキュリティアカウントで実施)
# -----------------------------------------------------------------------
resource "aws_securityhub_organization_configuration" "main" {
  provider  = aws.security
  auto_enable  = true
  auto_enable_standards = "DEFAULT"  # FSBP を全アカウントに自動適用

  depends_on = [aws_securityhub_organization_admin_account.security]
}

# -----------------------------------------------------------------------
# Finding Aggregator: 全リージョン集約 (セキュリティアカウントで実施)
# -----------------------------------------------------------------------
resource "aws_securityhub_finding_aggregator" "all_regions" {
  provider  = aws.security
  linking_mode = "ALL_REGIONS"

  depends_on = [aws_securityhub_organization_configuration.main]
}

解説: depends_on の連鎖が重要で、admin_account 委任 → organization_configuration → finding_aggregator の順序で apply しなければリソース作成が失敗する。Terraform の depends_on で明示的に依存関係を記述することが必須だ。

8. まとめ + Vol3予告 + 落とし穴10選 + 全9軸クロスリンク + セキュリティ Vol1↔Vol2双方向リンク

8-1. 本記事で学んだこと

本記事「AWS SOC統合運用 完全ガイド — GuardDuty × Security Hub × Detective」では、セキュリティ運用入門 Vol1 で学んだセキュリティ運用の基礎を土台に、以下の5つの到達ゴールを達成した。

Vol1 (基礎) から本 Vol2 (SOC統合深化) へ進んだことで、GuardDuty/Security Hub/Detective の三位一体による「検知 → 集約 → 調査」パイプラインを本番構築できる状態を手に入れた。

8-2. 落とし穴10選

本記事全体を通じて繰り返し登場した重要な落とし穴を10選にまとめる。

上記10の落とし穴はすべて「設定した後に気づく」パターンだ。本 Vol2 の各セクションで解説した対処法を組み合わせることで、これらを事前に防ぐ SOC 設計が可能になる。

8-3. セキュリティシリーズ Vol3 予告

次巻 Vol3 では、Vol1 (基礎) × Vol2 (SOC統合) の上に データ保護 + コンプライアンス自動化 レイヤーを追加する予定だ。

Vol3 予定トピック:
– Macie — S3 機密データ検出 (PII/金融情報) + 自動分類
– Inspector — EC2/Lambda/Container イメージの脆弱性スキャン
– Audit Manager — フレームワーク (PCI/HIPAA/NIST) ベースの自動エビデンス収集
– Config Aggregator — 複数アカウント・複数リージョンの Config Rules 一元管理

本 Vol2 の Multi-Account Aggregator と組み合わせることで、「GuardDuty/Security Hub/Detective (検知・集約・調査)」+ 「Macie/Inspector/Audit Manager (データ保護・脆弱性・コンプライアンス)」の SOC 全レイヤーカバー を実現できる。Vol3 は近日公開予定だ。

8-3b. セキュリティシリーズ 学習ロードマップ

本シリーズを活用した推奨学習順序を示す。

Vol1: セキュリティ運用入門 (基礎3本柱)
  ↓ GuardDuty / Security Hub / CloudTrail の基礎を習得
Vol2: SOC統合運用 (本記事)
  ↓ GuardDuty 6 Protection / Security Hub Standards / Detective Behavior Graph
  ↓ Multi-Account Aggregator / 詰まり7選 / 演習5問
Vol3 (近日公開): データ保護 + コンプライアンス自動化
  ↓ Macie / Inspector / Audit Manager / Config Aggregator
完成形: "検知 → 集約 → 調査 → データ保護 → コンプライアンス" の SOC 全レイヤーカバー

Vol1 未読の方へ: セキュリティ運用入門 — 3本柱 (脅威検出/コンプライアンス/ログ集約) から始めることを推奨する。GuardDuty/CloudTrail/Security Hub の基礎を Vol1 で押さえることで、本 Vol2 の内容がより深く理解できる。

8-4. 全9軸クロスリンク再掲 + セキュリティ Vol1↔Vol2 双方向リンク