【AWS設計ガイドライン】Amazon GuardDuty マルチアカウント構成・Extended Threat Detection 導入設計のベストプラクティス

📅 作成日: 2023/08/11, 更新日: 2026/11/01 ⏱️ 読了目安約15分 (7,297文字)

AWS Organizations 環境で Amazon GuardDuty を全アカウントへ統合導入する際の設計ガイドライン。委任管理者アカウント設計、S3/EKS/Runtime Monitoring 保護プランの取捨選択、EventBridge 通知フィルタリングまで体系的に解説します。

改訂履歴
マルチアカウント環境で GuardDuty を「全部盛り」にして痛感した失敗
1. Amazon GuardDuty の基本仕様と Extended Threat Detection
1. ① CloudTrail や VPC Flow Logs の事前有効化は不要
2. ② Extended Threat Detection（拡張脅威検出）による「点から線へ」の相関分析
2. IDS / IPS（AWS Network Firewall・WAF）との役割分担
3. オプション保護プラン（7機能）の料金体系と有効化判断基準
4. 現場でハマりやすい3つの設計トラップと回避策
5. アラート疲れを防ぐ EventBridge 通知フィルタと役割分担
1. ① 基盤チーム（CCoE）とシステム担当チームの役割分担
2. ② EventBridge による High / Critical および AttackSequence 抽出ルール
まとめ

改訂履歴

日付

更新内容

2026/10/28

・Extended Threat Detection（AI/ML 攻撃シーケンス相関検知：AttackSequence:*）の設計・運用ポイントを追加
・AWS Organizations マルチアカウント委任管理者（Auto-Enable）と Malware Protection for S3 個別展開の全体構成図を刷新
・S3 Protection のログ集約バケット課金抑制、Runtime Monitoring の VPC エンドポイント設計、抑制ルール（Suppression Rules）の現場知見を追加

2025/01/22

・「GuardDuty Malware Protection for S3」「GuardDuty Runtime Monitoring」を追加
・リンク切れの更新

マルチアカウント環境で GuardDuty を「全部盛り」にして痛感した失敗

僕が CCoE（Cloud Center of Excellence）として数十アカウント規模の AWS Organizations 環境でセキュリティ統制を標準化した際、最初にやってしまった失敗があります。それは、委任管理者アカウントから「念のためすべての保護プランを全アカウント一括で ON にしておこう」と設定し、翌月の請求書を見て青ざめたことです。

原因は、全アカウントの CloudTrail ログや ALB アクセスログを集約していた「ログアーカイブ専用アカウント（Log Archive）」や、高頻度でオブジェクトを読み書きするバッチ処理用 S3 バケットに対してまで S3 Protection（S3 データイベント監視）を無差別に有効化してしまったことでした。月間数億〜数十億件の PutObject / GetObject イベントがそのまま課金対象になり、本来守るべき機密バケット以外のノイズコストが大きく膨らんでしまったのです。

さらに運用を始めると、単発の偵察アラート（ Recon:IAMUser/... や Discovery:S3/... ）が毎日何十件も Slack に流れ込み、開発チームから「どれが本当に危険で、どれが無視していいスキャンなのか判断できない」と悲鳴が上がりました。

こうした手戻りを経てたどり着いた結論は、「基本データソース＋Extended Threat Detection（攻撃シーケンス相関分析）を全アカウントの土台にしつつ、オプション保護プランはワークロード特性と自動有効化（Auto-Enable）の仕様制約を見極めて選択適用する」という設計アプローチです。

▲ AWS Organizations マルチアカウント環境における Amazon GuardDuty 委任管理・保護プラン・通知ルーティング構成図

1. Amazon GuardDuty の基本仕様と Extended Threat Detection

Amazon GuardDuty は、AWS アカウント内のコントロールプレーンおよびデータプレーンの挙動を継続的に分析し、不正アクセスやマルウェア、認証情報の侵害を検出するマネージド型の脅威検知（IDS）サービスです。

① CloudTrail や VPC Flow Logs の事前有効化は不要

現場の設計レビューで今でもよく誤解されるポイントですが、GuardDuty を動かすために各アカウントで CloudTrail 証跡や VPC Flow Logs を手動で有効化・S3 保存しておく必要はありません。GuardDuty は AWS 内部の独立したデータストリームから以下の 3 つの基礎データソースを直接引き込んで分析します。

AWS CloudTrail 管理イベント（IAM 操作、セキュリティグループ変更、EC2 起動など）
Amazon VPC フローログ（ネットワーク通信の送信元・宛先・ポート・バイト数）
Route 53 DNS クエリログ（C2 サーバーや暗号資産マイニングプール等の不審ドメイン名前解決）

② Extended Threat Detection（拡張脅威検出）による「点から線へ」の相関分析

従来の GuardDuty 運用で最大の課題だった「単発アラートの洪水（アラート疲れ）」を解決する中核機能が、AI/ML を用いた Extended Threat Detection です。

たとえば、「IAM ロールが不審な IP から呼び出された（Low）」「直後に S3 バケット一覧が列挙された（Low）」「機密バケットから大量のオブジェクトがダウンロードされた（High）」という複数の事象が別々に発生したとします。Extended Threat Detection はこれらの時系列シグナルを自動的に紐づけ、1 つの重大（ Critical ）な攻撃シーケンス（ AttackSequence:* ）として統合通知します。

攻撃シーケンス検出タイプ	検出されるマルチステージ攻撃のシナリオ	相関分析に使われる主なシグナル源
AttackSequence:IAM/CompromisedCredentials	漏洩した IAM 認証情報の悪用から、偵察・権限昇格・リソース操作へ至る一連の侵害	CloudTrail 管理イベント、異常 API 呼び出し
AttackSequence:S3/CompromisedData	不審なアクセス元や侵害された IAM 主体による S3 機密データの大量窃取・破壊（ランサムウェア挙動）	CloudTrail 管理イベント、S3 Protection
AttackSequence:EKS/CompromisedCluster	Kubernetes API の悪用、特権コンテナの起動、コンテナ内での不正プロセス実行・C2 通信の連鎖	EKS Audit Logs、Runtime Monitoring
AttackSequence:ECS/CompromisedCluster	ECS タスク（Fargate / EC2）内でのリバースシェル実行やマルウェア展開、横展開の試行	Runtime Monitoring、VPC Flow Logs
AttackSequence:EC2/CompromisedInstanceGroup	Web 脆弱性等を突いた EC2 侵害から、暗号資産マイニングや外部への踏み台通信へ至る連鎖	Runtime Monitoring、VPC Flow Logs、DNS、Malware

Extended Threat Detection は追加料金なしでデフォルト有効化されますが、S3 Protection や Runtime Monitoring を有効にしているほど相関分析の材料が増え、検出精度が高まります。

2. IDS / IPS（AWS Network Firewall・WAF）との役割分担

「すでに AWS Network Firewall やサードパーティ製 IPS、AWS WAF を入れている場合、GuardDuty は不要ではないか？」という質問もよく受けます。

結論から言うと、Network Firewall や WAF は「ネットワーク境界・HTTP レイヤーでの通信遮断（IPS）」を担うのに対し、GuardDuty は「IAM 認証情報の不正利用や AWS API 操作、DNS クエリ、OS カーネルレベルのランタイム挙動を含めたアカウント全体の脅威検知（IDS）」を担うため、守備範囲が異なります。

脅威カテゴリ	監視・検知対象	Amazon GuardDuty (IDS)	AWS Network Firewall (IPS)
認証・API 侵害	漏洩した IAM クレデンシャルによる不正 API 操作・権限昇格	○ (CloudTrail 機械学習分析)	- (通信経路外のため検知不可)
データ持ち出し	正規ポート・HTTPS 経由での S3 バケット大量取得・削除	○ (S3 Protection / AttackSequence)	- (AWS 内部 API のため遮断不可)
マルウェア・ランタイム	EC2 / ECS / EKS コンテナ内での不審プロセス実行・ファイル改ざん	○ (Runtime Monitoring / Malware)	△ (外部 C2 通信発生時のみ検知)
名前解決	暗号資産マイニング・C2 ドメインへの DNS クエリ	○ (Route 53 内部ストリーム)	○ (Route 53 Resolver DNS Firewall 併用時)
境界ネットワーク通信	既知の悪성 IP・ボットネット・Tor ノードとのパケット通信	○ (検知・通知のみ)	○ (Suricata ルールで即時遮断可能)
ブルートフォース	SSH / RDP やデータベースへの総当たり攻撃	○	-

IPS は不正通信を即座に遮断できる反面、誤検知（False Positive）を起こすと本番トラフィックを止めてしまうリスクがあります。AWS 環境では、まず全アカウントに GuardDuty を敷いて API・ネットワーク・DNS の異常を網羅的に拾い、外部公開境界にだけ WAF や Network Firewall を組み合わせるのが現実的です。

3. オプション保護プラン（7機能）の料金体系と有効化判断基準

GuardDuty のオプション保護プランは、何でも一括で有効化すると予算を圧迫します。東京リージョン（ ap-northeast-1 ）の料金水準と、AWS Organizations の委任管理者から一括自動有効化（Auto-Enable）できるかどうかを整理した上で、対象アカウント・リソースを絞り込みます。

No	保護プラン名	監視内容	東京リージョン料金目安	Organizations 一括 Auto-Enable	推奨される有効化スコープ
01	S3 Protection	S3 データイベント（GetObject / PutObject 等）の異常 API 監視	`$1.04` / 100万イベント（最初の5億件/月）	対応	本番・機密データ保有アカウント（ログ集約専用アカウントは除外検討）
02	Malware Protection for S3	S3 に新規配置されたオブジェクトのマルウェアスキャン	`$0.60` / GB ＋ `$0.24` /1000件	非対応（バケット単位設定）	外部ユーザーがファイルをアップロードする受付用バケットのみ
03	Malware Protection for EC2	GuardDuty が不審挙動を検知した際、EBS スナップショットからマルウェア検査	`$0.05` / GB（スキャン実行時のみ）	対応	EC2 / コンテナホストを稼働させる全ワークロードアカウント
04	RDS Protection	Amazon Aurora / RDS のログイン試行を分析し不審アクセスを検知	`$1.33` / プロビジョニング済み vCPU・月	対応	機密データを格納する本番 Aurora / RDS 稼働アカウント
05	EKS Audit Logs Monitoring	Amazon EKS コントロールプレーンの監査ログから不審な kubectl 操作等を検知	`$2.48` / 100万監査ログイベント	対応	EKS クラスターを稼働させるアカウント
06	Lambda Protection	Lambda 関数が実行時に発生させる VPC ネットワーク通信ログを分析	`$1.18` / GB（最初の500GB/月）	対応	本番・ステージングのサーバーレス稼働アカウント
07	Runtime Monitoring	EKS / ECS (Fargate含む) / EC2 内の OS レベル（プロセス起動・ファイル・通信）監視	`$1.50` 〜 `$2.00` / vCPU・月（最初の500 vCPU）	対応（エージェント自動管理可）	外部公開アプリやコンテナを動かす重要本番アカウント

4. 現場でハマりやすい3つの設計トラップと回避策

① Malware Protection for S3 は「検疫（隔離）フロー」とセットで組む

表の通り、Malware Protection for S3 は Organizations の委任管理者設定から全アカウント一括で ON にすることはできません。なぜなら、検査対象の S3 バケット名と、スキャンを実行するための専用 IAM ロール（ PassRole 権限を含む）をバケット単位で紐づける必要があるためです。

また、GuardDuty がマルウェアを検出しても、デフォルトではオブジェクトに GuardDutyMalwareScanStatus: THREATS_FOUND というタグを付けるだけで、ファイルを自動削除したりダウンロードを止めたりはしてくれません。そのため、現場では以下のシーケンスで「スキャン完了かつ脅威なし（ NO_THREATS_FOUND ）と判定されるまで後続アプリからの読み取りを拒否する」検疫設計を組みます。

        sequenceDiagram
    autonumber
    actor User as 外部ユーザー
    participant S3 as アップロード受付用 S3
    participant GD as GuardDuty Malware Protection
    participant EB as Amazon EventBridge
    participant Quarantine as 隔離用 S3 / 通知 Lambda

    User->>S3: ファイルアップロード (s3:PutObject)
    Note over S3: バケットポリシーによりタグ未付与時は GetObject を拒否
    S3->>GD: S3 イベント通知 (非同期スキャン起動)
    GD->>S3: オブジェクト読み取り & マルウェア検査
    alt 脅威なし (NO_THREATS_FOUND)
        GD->>S3: タグ付与 (GuardDutyMalwareScanStatus = NO_THREATS_FOUND)
        Note over S3: アプリケーションからの GetObject が解禁される
    else マルウェア検出 (THREATS_FOUND)
        GD->>S3: タグ付与 (GuardDutyMalwareScanStatus = THREATS_FOUND)
        GD->>EB: Object Scan Result イベント発火
        EB->>Quarantine: 隔離バケットへ移動 & CSIRT へ即時通知
    end
       

② Runtime Monitoring の VPC エンドポイント（ `guardduty-data` ）自動作成と IaC 競合

Runtime Monitoring で「AWS によるセキュリティエージェントの自動管理（Automated Agent Management）」を有効化すると、GuardDuty サービス側が対象アカウントの VPC 内に com.amazonaws.ap-northeast-1.guardduty-data というインターフェース VPC エンドポイントと専用セキュリティグループを自動プロビジョニングします。

僕が現場で実際に踏んだハマりどころは以下の 2 点です。

Terraform / CloudFormation との状態ドリフト :
VPC 内のサブネットやエンドポイントを Terraform で厳格に管理していると、GuardDuty が裏で自動作成した VPC エンドポイントや ENI が原因で、サブネット削除時や SG 変更時に DependencyViolation エラーが発生することがあります。
極小サブネットでの IP アドレス枯渇 :
/28 （利用可能 IP 11 個）などの小さなプライベートサブネットを切っている環境で Runtime Monitoring を有効化すると、各 AZ のサブネットにエンドポイント用 ENI が作られて IP を消費します。

EKS や ECS Fargate で Runtime Monitoring を導入する際は、事前にプライベートサブネットの空き IP 数を確認し、エンドポイント作成用の SCP 制限（ ec2:CreateVpcEndpoint の拒否ルールなど）に GuardDuty サービスプリンシパルの除外条件が入っているかを確認してください。

③ Organizations 委任管理者での Auto-Enable 設定コマンド例

管理アカウントではなく「セキュリティ監査アカウント（Audit / Security Tooling）」を委任管理者に指定し、既存メンバーおよび今後作成される新規アカウントに対して保護プランを自動有効化する AWS CLI の実装パターンです。

# 1. Organizations 管理アカウント側で、セキュリティ監査アカウントを委任管理者に登録
aws organizations enable-aws-service-access   --service-principal guardduty.amazonaws.com
aws organizations register-delegated-administrator   --account-id 111122223333   --service-principal guardduty.amazonaws.com

# 2. セキュリティ監査アカウント（委任管理者）側で、組織全体の自動有効化を構成
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

aws guardduty update-organization-configuration   --detector-id "${DETECTOR_ID}"   --auto-enable-organization-members ALL   --features '[
    {"Name": "S3_DATA_EVENTS", "AutoEnable": "ALL"},
    {"Name": "EBS_MALWARE_PROTECTION", "AutoEnable": "ALL"},
    {"Name": "RDS_LOGIN_EVENTS", "AutoEnable": "ALL"},
    {"Name": "LAMBDA_NETWORK_LOGS", "AutoEnable": "ALL"},
    {"Name": "EKS_AUDIT_LOGS", "AutoEnable": "ALL"},
    {"Name": "RUNTIME_MONITORING", "AutoEnable": "NONE"}
  ]'

上記のように、コスト影響や VPC エンドポイント作成を伴う RUNTIME_MONITORING は組織一括では NONE （手動または特定本番アカウントのみ個別に有効化）とし、基本保護プランを ALL にするのが安全です。

5. アラート疲れを防ぐ EventBridge 通知フィルタと役割分担

GuardDuty の検出結果（Finding）はそのまま全件をチャットに流すと、数週間で誰も見なくなります。運用設計では「誰が何を担当するか」と「どの重要度から人間を起こすか」を明確に定義します。

① 基盤チーム（CCoE）とシステム担当チームの役割分担

運用フェーズ	タスク内容	担当チーム	設計のポイント
1. 初期構築・ガバナンス	委任管理者設定、SCP による無効化防止、通知基盤構築	基盤チーム (CCoE)	StackSets / Terraform で全リージョン展開
2. 一次トリアージ・調査	Critical / High 検出時の攻撃経路確認・影響範囲特定	システム担当＋ CSIRT	Extended Threat Detection のシーケンス図を活用
3. 抑制ルール (チューニング)	社内脆弱性スキャナーや既知バッチ通信の自動アーカイブ	システム担当申請 → 基盤承認	Suppression Rules を IaC でコード管理し履歴を残す
4. 新規保護プラン評価	30日間無料トライアルでのコスト試算と有効化判断	基盤チーム (CCoE)	コンソールの Usage 画面で見積もり額を事前確認

② EventBridge による High / Critical および AttackSequence 抽出ルール

Medium 未満（Severity 1.0〜3.9 の Low）は Security Hub への記録のみにとどめ、リアルタイムの Slack / PagerDuty 通知は Severity 4.0 以上（Medium / High / Critical） に絞ります。特に AttackSequence:* は Severity 9.0+（Critical）で発火するため、最優先チャネルへルーティングします。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 4.0] }]
  }
}

まとめ

マルチアカウント環境への Amazon GuardDuty 導入において、押さえておくべき設計判断は以下の 3 点に集約されます。

基本検知＋Extended Threat Detection を全アカウント・全リージョンで必須化する :
追加コストなしで AI 相関分析（ AttackSequence:* ）が機能し、IAM・S3・コンテナをまたぐ侵害シナリオを 1 つの重大インシデントとして把握できます。
S3 Protection と Malware Protection for S3 の対象バケットを見極める :
ログ集約バケットでの S3 データイベント課金膨張を避け、マルウェア検査は外部アップロード受付バケットに限定して EventBridge 検疫フローとセットで構築します。
Runtime Monitoring は VPC エンドポイントと IP 消費を考慮して段階導入する :
組織全体でいきなり Auto-Enable にせず、本番の重要コンテナ・EC2 ワークロードから段階的に適用します。

とはいえ、Extended Threat Detection がどこまで巧妙な内部不正や未知の攻撃パターンを過不足なく束ねてくれるのか、また今後追加されるランタイム検知ルールでどの程度のノイズチューニング（抑制ルール追加）が必要になるかは、僕自身も実運用の中で引き続き見極めていきたいと考えています。まずは 30 日間の無料トライアルと Usage 画面のコスト見積もりを活用し、自組織のトラフィック量に合った保護プランの組み合わせを探ってみてください。