Amazon GuardDuty実践設計入門｜Organizations統合・保護機能の有効化判断・抑制フィルター設計で脅威検知を本番運用する実践ガイド

クラウドに移行してGuardDutyを有効にした。しかし数日後には「どのアラートを優先すべきかわからない」「同じ検知が毎日繰り返し出てくる」「マルチアカウントでそれぞれのコンソールを確認するのが手間だ」——そういう声が現場から上がる。これはGuardDutyの「有効化後の運用設計」が抜けている典型的なパターンだ。

GuardDutyはスイッチひとつで動き始めるが、本番で使い物になる状態にするには設計が必要だ。どの保護機能を有効にするか、どのFindingsを抑制してノイズを減らすか、誰にどう通知するか。この設計が抜けたまま稼働させると、アラート疲れ（Alert Fatigue）を招いて有名無実化する。

この記事では、GuardDutyをオンプレのセキュリティ監視と比較しながら、Organizations統合によるマルチアカウント集約設計、保護機能の種類と有効化判断、抑制フィルター設計、EventBridge連携による自動通知フローまでを実践的に解説する。

GuardDutyとは何か — オンプレのIDS/SIEMとの違い

オンプレ環境でのセキュリティ監視といえば、ネットワーク境界にIDSを置き、SIEMにログを集めてルールを書くアーキテクチャが一般的だった。GuardDutyはこれと根本的に異なる。

GuardDutyはAWSが提供するマネージド型の脅威検知サービスで、次の3つのデータソースを内部で自動的に分析してFindingsを生成する。

・AWS CloudTrailログ: APIコールの異常を検知（例: 権限昇格の試み、ルートアカウントの使用）
・VPC Flow Logs: ネットワーク通信の異常を検知（例: 既知の悪意あるIPとの通信）
・DNSログ: ドメイン解決パターンの異常を検知（例: C2サーバーとの通信疑い）

オンプレのIDSとの最大の違いは、ログ収集インフラを自前で持たなくていい点だ。VPC Flow LogsはCloudWatchへの転送設定すら不要で、GuardDutyが内部で直接分析する。既知の脅威情報（Threat Intelligence）はAWSがマネージドで更新するため、シグネチャの管理コストもない。

一方で「自分でルールが書けない」という不満もある。これは後述の抑制フィルターとカスタムThreat Intelligenceで対処できる。

GuardDutyはVPC Flow Logsを分析するが、VPC Flow Logs自体をCloudWatch Logsに転送しなくてもGuardDutyは動作する。この点を知らずに「VPC Flow Logsを有効化していないから動かない」と勘違いするケースは一般的に多い（GuardDutyは独自の経路でFlowログデータにアクセスする）。

保護機能の種類と有効化判断

GuardDutyには基本機能に加え、対象リソースに応じた複数の保護オプションがある。有効化するかどうかは環境と目的によって判断が必要だ。

1. VPC・DNS・CloudTrail（基本機能・常時有効）

GuardDuty本体を有効化すると、VPC Flow Logs・DNSログ・CloudTrailイベントの分析が自動的に始まる。これは無効にできない（GuardDuty全体を停止することになる）。

基本機能で検知できるFindingsの例（想定例）：
・UnauthorizedAccess:EC2/SSHBruteForce: インターネットからEC2へのSSHブルートフォース試行を検知
・Recon:IAMUser/UserPermissions: IAMユーザーが大量のAPIを呼び出してリソース一覧を取得しようとしている
・CryptoCurrency:EC2/BitcoinTool.B: EC2が仮想通貨マイニングプールに通信していることを検知

2. S3保護（ほぼ全環境で推奨）

S3保護を有効にすると、CloudTrail S3データイベントを分析してバケットレベルの脅威を検知できる。追加コストが発生するが、データ漏洩の主要経路であるS3を監視できる価値は高い。

検知できるFindingsの例（想定例）：
・Policy:S3/BucketBlockPublicAccessDisabled: S3バケットのパブリックアクセスブロックが無効化された
・Discovery:S3/MaliciousIPCaller: 既知の悪意あるIPからのS3 APIコール
・Exfiltration:S3/ObjectRead.Unusual: 通常とは異なるパターンでのS3オブジェクト読み取り

3. EKS保護（EKSを使う環境では必須）

EKS保護はKubernetesの監査ログを分析し、コンテナクラスターへの不審なアクセスを検知する。2種類の保護機能がある。

・EKS Audit Log Monitoring: 過剰な権限を持つServiceAccount、匿名ユーザーのAPIアクセスなどを検知。EKSクラスターにエージェントは不要
・EKS Runtime Monitoring: コンテナ内のプロセス実行・ファイル操作・ネットワーク接続を監視。EC2ノードにDaemonSetエージェントが必要

EKS Runtime MonitoringはEKS Audit Log Monitoringより細かい検知が可能だが、ノードへのエージェント展開と追加コストが発生する。まずAudit Log Monitoringから始め、セキュリティ要件の高い環境でRuntime Monitoringを追加するアプローチが現実的だ。

4. マルウェアスキャン（EC2・ECSのEBSボリューム）

EC2やECSのEBSボリュームをスナップショット経由でスキャンし、マルウェアを検知する。2つのスキャン方式がある。

・ガード起動スキャン（GuardDuty-Initiated Malware Scan）: GuardDuty本体の基本検知が怪しいEC2/ECSを検知したとき、自動的にEBSスキャンを実行する
・オンデマンドスキャン: 任意のタイミングで特定のリソースをスキャンできる（手動実行）

料金はスキャン対象のGiB数に応じた従量課金（2026年10月時点）。大量のEBSボリュームを持つ環境ではコスト試算を先に行うこと。

5. Lambda保護

Lambda関数の実行中のネットワーク通信を分析し、Lambda内部から悪意あるIPや悪意あるドメインへの通信を検知する。サーバーレスアーキテクチャを多用する環境では有効化の価値がある。料金はLambda関数の呼び出し数・実行時間に基づく。

6. RDS保護

Amazon RDS Aurora（MySQL・PostgreSQL互換）のログイン認証イベントを分析し、ブルートフォース攻撃や異常なログイン試行を検知する。

Organizations統合によるマルチアカウント集約設計

複数のAWSアカウントでGuardDutyを使う場合、Organizations統合が必須だ。統合しないと、各アカウントのコンソールをログインし直してFindingsを確認する手間が生じ、横断的な分析もできない。

委任管理者アカウントの選択

GuardDutyのOrganizations統合では「委任管理者アカウント」を1つ指定する。この設計のポイントはOrganizations管理アカウント（ルートアカウント）を委任管理者にしないことだ。

管理アカウントはOrganizations自体の操作（アカウント追加・OU変更・SCP管理）を行うため、セキュリティサービスの管理と権限が混在してしまう。専用のセキュリティ集約アカウントを別に用意して委任管理者に指定するのがベストプラクティスだ。

# GuardDutyの委任管理者を登録する（AWS CLI）
# Organizations管理アカウントで実行する

aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 123456789012
# 123456789012 はセキュリティ集約アカウントのID

自動有効化の設定

委任管理者アカウントで「自動有効化」を設定すると、Organizationsに新しくアカウントが追加された時にGuardDutyが自動で有効になる。

# 自動有効化の設定（AWS CLI）
# 委任管理者アカウントで実行する

aws guardduty update-organization-configuration \
  --detector-id  \
  --auto-enable-organization-members NEW_ACCOUNTS
# NEW_ACCOUNTS: 新規アカウントのみ
# ALL: 既存アカウントも含めて全て有効化

マルチアカウントでのFindingsの確認

委任管理者アカウントのGuardDutyコンソールで、全メンバーアカウントのFindingsを一元確認できる。「アカウント」フィールドでどのアカウントで発生したFindingかを識別できる。

各メンバーアカウントでは設定変更が制限されており、委任管理者が許可しない限りメンバーは保護機能の無効化や抑制フィルターの変更ができない。セキュリティチームによる中央管理という観点では正しい設計だが、各環境の担当者に事前に説明しておかないと混乱を招く。

抑制フィルター（Suppression Rules）の設計

GuardDutyの本番運用で最も重要なのがノイズを減らすための抑制フィルター設計だ。同じアラートが何百件も出続けると、エンジニアの注意力が分散して本物の脅威を見落とすリスクが上がる。

抑制フィルターは「条件に合致するFindingsを自動でアーカイブ状態にする」仕組みだ。アーカイブされたFindingsはコンソールの「Archived」タブに移動し、アクティブな一覧には表示されなくなる（ただし記録は残る）。

よくある抑制フィルターのパターン

一般的によく見られるケース（想定例）として、以下のパターンが運用現場で頻出する。

・CI/CDツールのIPからのAPI呼び出し: GitHub ActionsのIPレンジからの操作がRecon系のFindingsとして誤検知されるケース
・踏み台サーバーからのSSH通信: 社内VPNや踏み台のEIPからのSSH接続がUnauthorizedAccess:EC2/SSHBruteForceとして出るケース
・定期的なセキュリティスキャン: セキュリティチームが実行する内製スキャンツールが毎日同じFindingを生成するケース

# 抑制フィルターの作成例（AWS CLI）
# タグ "Role=CI-Server" のEC2からの
# UnauthorizedAccess:EC2/SSHBruteForce を抑制する

aws guardduty create-filter \
  --detector-id  \
  --name "suppress-ci-server-ssh-bruteforce" \
  --action ARCHIVE \
  --finding-criteria '{
    "Criterion": {
      "type": {
        "Equals": ["UnauthorizedAccess:EC2/SSHBruteForce"]
      },
      "resource.instanceDetails.tags.value": {
        "Equals": ["CI-Server"]
      }
    }
  }'

抑制フィルターを設計する際の注意点

・過剰な抑制は禁物: 「アラートを減らしたい」という動機で広すぎる条件を設定すると、本物の脅威を見逃す。フィルターは狭く・具体的な条件で設計する
・定期的なレビュー: 一度作ったフィルターが陳腐化していないか、四半期ごとにレビューする運用を設ける
・IAM・ルートアカウント関連は原則抑制しない: Policy:IAMUser/RootCredentialUsageやUnauthorizedAccess:IAMUser/InstanceCredentialExfiltrationは高重要度のFindingsであり、抑制の例外として扱うべきだ
・抑制とアーカイブの使い分け: 1回だけ手動でアーカイブするのは「今回は無視」の意味。抑制フィルターは「将来も同条件は常に無視」の意味だ。使い分けを意識する

EventBridge連携による自動通知・対応フロー

GuardDutyのFindingsはAmazon EventBridgeにイベントとして自動送信される。これを使えば、Findingsの重要度（Severity）に応じた自動通知・自動対応が構築できる。

重要度によるFindingsの分類

GuardDutyのFindingsは重要度スコア（1.0～10.0）で分類される。

・High（7.0以上）: 即時対応が必要。即座に通知し、担当者がトリアージする
・Medium（4.0～6.9）: 数時間以内に確認が必要。ダイジェスト通知で十分な場合が多い
・Low（1.0～3.9）: 優先度低。週次サマリーで確認するか、多くは抑制フィルターの候補となる

EventBridgeルールの設定例

# EventBridgeルール（JSON形式）
# Severity 7.0以上のGuardDuty FindingsをSNSに送信する

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

# このルールのターゲットにSNS TopicやLambdaを指定する
# SNS Topicを経由してSlack/PagerDutyに転送するのが典型的な構成

自動対応（Auto-Remediation）の設計方針

Findingsをトリガーにした自動対応は魅力的だが、誤検知による誤動作リスクも考慮が必要だ。段階的なアプローチを推奨する。

・即時自動化の対象（リスクが低い）: Findingsへのタグ付け、チケット起票、Slackへの通知送信
・承認フロー付きの半自動化（リスク中）: Security Hubへのエスカレーション、担当者へのSlack通知＋承認ボタン経由での対応
・慎重に設計する対象（リスクが高い）: EC2の自動隔離（セキュリティグループ変更）、IAMユーザーの自動無効化

AWS Security Hubと組み合わせると、GuardDutyのFindingsをSecurity Hubに集約し、JIRAやServiceNowへのチケット連携をSecurity Hub側で一元管理できる。

GuardDutyの料金体系と見積もり方法

GuardDutyの料金は機能ごとに独立した課金体系を持つ（2026年10月時点）。

料金見積もりの実務的なアプローチ

GuardDutyには30日間の無料トライアル期間がある。トライアル中にコンソールの「Usage」画面で「トライアル期間終了後の月額コスト予測」が表示されるため、この数字を確認してから本番有効化の意思決定をすることを推奨する。

マルチアカウント環境では各メンバーアカウントのトライアル期間が独立している。全アカウントで順次トライアルを実施してコストを積み上げる、という手順が現実的だ。

よくあるつまずきと対処法

つまずき1: Finding数が多すぎて運用が回らない
有効化直後の1～2週間は「抑制フィルターを構築する期間」と割り切ることが大切だ。最初から全Findingsへの対応を求めず、まず重要度Highのみを優先対応対象にする。Medium・LowはGuardDutyのUsage画面で傾向を観察しながら抑制フィルターを追加していく。

つまずき2: GuardDutyを停止・再有効化したらFindingsが消えた
GuardDutyを停止すると、そのアカウントのFindingsは90日後に削除される（停止直後は残る）。再有効化後も過去のFindingsは復元されない。コスト削減目的での一時停止は、過去の検知記録を失うリスクがある。GuardDutyは原則として停止しない運用を推奨する。

つまずき3: Organizations統合後にメンバーアカウントで設定変更できない
これは仕様通りの動作だ。委任管理者から「ユーザーが変更できる設定」を明示的に許可しない限り、メンバーアカウントの担当者はGuardDutyの設定を変更できない。セキュリティチームによる中央管理という観点では正しい設計だが、各環境担当者に事前に説明しておかないと混乱を招く。

つまずき4: 特定のFindingが毎日繰り返し出続ける
同じFindingタイプが同じリソースで繰り返し発生する場合、GuardDutyは一定期間まとめてカウントする。繰り返すFindingは根本原因の解消（セキュリティグループの修正・IAMポリシーの見直し等）か、正常な動作と確認できたなら抑制フィルターの設定が必要だ。どちらにせよ放置は避ける。

本記事のまとめ

GuardDutyは「有効にするだけ」では本番運用の体をなさない。設計の要点を整理する。

・保護機能の選択: S3保護はほぼ全環境で推奨。EKS・Lambda・RDS保護は使用するサービスに応じて判断。マルウェアスキャンは機密データを扱うEC2/ECS環境で検討する
・Organizations統合: 専用のセキュリティ集約アカウントを委任管理者にし、全アカウントのFindingsを一元管理する
・抑制フィルター: 既知の正常な通信・CI/CDツールのノイズを具体的な条件で抑制し、アラート疲れを防ぐ。IAM/ルートアカウント関連は抑制しない
・EventBridge連携: 重要度に応じた通知フローを設計し、High（7.0以上）のみ即時対応。自動対応は段階的に導入する
・料金: 30日間のトライアルでコスト予測を確認してから全面有効化を判断する

GuardDutyを本番運用に乗せると、AWS Security HubによるFindings集約管理やAWS Detectiveによる詳細調査との組み合わせが自然に求められる。GuardDutyを入り口として、クラウドセキュリティ監視の仕組みを段階的に整えていくことを推奨する。

GuardDutyのFindingsを起点にしたAWS Detectiveによる詳細調査フローについてはAWS Detective入門｜GuardDutyアラートを深掘り調査してセキュリティインシデント対応を効率化する実践ガイドを参照いただきたい。

また、GuardDutyを含むFindingsをSecurity Hubで一元管理する方法についてはAWS Security Hub入門 セキュリティ運用を一元管理する実践ガイドも合わせて参照いただきたい。