AWS GuardDutyとSecurity Hubで脅威検知を設計する方法｜有効化から通知・対応フローの構築まで

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ AWS(Amazon Linux) ＞ AWS GuardDutyとSecurity Hubで脅威検知を設計する方法｜有効化から通知・対応フローの構築まで

「GuardDutyを有効化したはいいが、検出結果が大量に届いてどれを優先すればいいかわからない」「Security HubとGuardDutyの違いが説明できない」——AWSのセキュリティ運用を始めたエンジニアがつまずきやすいのが、この2つのサービスの使い分けです。

GuardDutyは「脅威を検知するエンジン」、Security Hubは「複数のセキュリティサービスの結果を集約して管理するコントロールセンター」です。この2つを組み合わせて初めて、「何が起きているか」を把握しながら「どう対応するか」を設計できる体制ができます。

この記事では、aws guardduty security hub の基本的な役割分担を整理した上で、有効化の手順、SNS・Lambdaを使った通知設定、検知から対応までのフロー設計、マルチアカウント環境での一元管理まで、セキュリティ運用の実務設計として必要な知識を一貫して解説します。

この記事のポイント

・GuardDutyは脅威検知エンジン、Security Hubはセキュリティ状態の一元集約管理
・GuardDutyはコンソール数クリックで有効化でき、S3・EKS・マルウェア保護も追加可能
・検出結果はEventBridge→SNS→Lambdaのパイプラインで自動通知・対応できる
・マルチアカウントはOrganizations委任管理者でGuardDutyとSecurity Hub両方を一元管理する

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

図解60P／登録10秒／解除も3秒／詳細はこちら

GuardDutyとSecurity Hubの役割分担を理解する

AWSのセキュリティ運用を設計する際に最初に明確にしておくべきことは、GuardDutyとSecurity Hubが「別々の層を担うサービスである」という点です。

Amazon GuardDutyは、AWSアカウント内のアクティビティを機械学習・脅威インテリジェンスで継続的に分析し、不審なふるまいを「Findings（検出結果）」として報告する脅威検知サービスです。分析対象は主に3つです。

・VPCフローログ：EC2インスタンスへの異常な通信パターン（ポートスキャン、マルウェアのC2通信等）を検出
・DNS クエリログ：マルウェアが悪意のあるドメインへ問い合わせる動きを検出
・AWS CloudTrailイベント：IAM認証情報の不審な使い回し、APIコールの異常パターンを検出

これらのデータソースをGuardDutyが自動で収集・分析します。エージェントのインストールや、S3へのログ転送設定などは不要です。

AWS Security Hubは、GuardDutyをはじめとする複数のAWSセキュリティサービス（Amazon Macie、AWS IAM Access Analyzer、AWS Config等）やサードパーティツールの検出結果を、ASFF（Amazon Security Finding Format）という統一フォーマットで集約・管理するSIEM的なサービスです。また、AWS Foundational Security Best PracticesやCIS AWS Foundations Benchmarkといったセキュリティ基準に対するコンプライアンス評価機能も持っています。

2つの立ち位置を整理すると次のようになります。

サービス	主な役割	入力データ	出力
Amazon GuardDuty	脅威検知エンジン	VPCフローログ・DNSクエリ・CloudTrail	脅威タイプ別Findings
AWS Security Hub	セキュリティ集約管理	GuardDuty・Macie・IAM Access Analyzer等	統合ダッシュボード・コンプライアンス評価

GuardDutyだけでも脅威検知は可能ですが、Security Hubと統合することで「どのリソースで・どのような脅威が・どのサービスによって検出されたか」を一元的に把握でき、対応の優先順位付けが格段に容易になります。

GuardDutyを有効化する手順

1. コンソールからの有効化

GuardDutyの有効化は、AWSマネジメントコンソールから数クリックで完了します。

・AWSコンソールにログインし、「Amazon GuardDuty」を検索して移動する
・「今すぐ始める」をクリックし、「GuardDutyを有効にする」を選択する
・有効化後、GuardDutyは自動でVPCフローログ・DNSクエリ・CloudTrailのデータを収集・分析し始める

有効化してから最初の30日間は無料トライアル期間です。実際の料金はその後、分析したデータ量（GB単位）に基づいて発生します。

重要：GuardDutyはリージョンごとに独立して有効化する必要があります。東京リージョン（ap-northeast-1）だけ有効化しても、バージニア北部（us-east-1）では無効のままです。攻撃者が意図的に別リージョンを使う手口を防ぐため、すべてのリージョンで有効化することを強く推奨します。

2. GuardDutyの検出タイプを理解する

GuardDutyが出力するFindingsは、脅威タイプ（Finding Type）で分類されます。主なカテゴリーを把握しておくと、アラートの意味を即座に判断できます。

# GuardDuty 主要 Finding Type（一部抜粋） Backdoor:EC2/C&CActivity.B # EC2がC2サーバーと通信している CryptoCurrency:EC2/BitcoinTool.B # 仮想通貨マイニングツールの使用を検出 Recon:EC2/PortProbeUnprotectedPort # ポートスキャンを検出 UnauthorizedAccess:IAMUser/MaliciousIPCaller # 悪意のあるIPからのAPIコール Stealth:IAMUser/CloudTrailLoggingDisabled # CloudTrailの無効化を検出

Findingsには重要度（Severity）が1.0～8.9のスコアで付与されます。High（7.0以上）は即時対応、Medium（4.0～6.9）は計画的対応、Low（1.0～3.9）は定期的なレビュー対象として優先度を分けるのが一般的です。

3. S3保護・EKS保護・Malware Protectionの追加

GuardDuty本体の有効化に加え、以下の拡張保護機能も用途に応じて有効化を検討してください。

・S3保護：S3バケットへの異常なアクセス（大量ダウンロード、未知のIPからのアクセス等）を検出。データ漏洩インシデントの検知に有効
・EKS保護：Kubernetesクラスターの監査ログを分析し、コンテナ環境内の脅威（権限昇格、APIサーバーへの不審なアクセス等）を検出
・Malware Protection（EC2）：GuardDutyがEC2インスタンスのマルウェア感染を検出した際に、EBSボリュームをスナップショット経由で自動的にスキャン

これらの拡張機能はGuardDutyの設定画面から個別に有効化でき、それぞれ独自の課金体系があります。本番環境での有効化前に、コスト試算を行うことをお勧めします。

Security Hubの有効化と統合設定

1. Security Hubを有効化する

Security HubもGuardDutyと同様、コンソールから有効化します。

・AWSコンソールで「AWS Security Hub」を開く
・「Security Hubに移動」→「Security Hubを有効にする」をクリック
・有効化時に「AWS Foundational Security Best Practices」や「CIS AWS Foundations Benchmark」などのセキュリティ基準を選択する（後から追加・変更も可能）

Security Hubも同様にリージョンごとの有効化が必要です。

2. GuardDutyとの統合設定

Security HubとGuardDutyの統合は、有効化後に自動的に設定されます。GuardDutyのFindingsが自動でSecurity Hubに転送され、統合ダッシュボードで確認できるようになります。

統合状況の確認は、Security Hubコンソールの「統合」メニューから行えます。「Amazon GuardDuty」が「有効」になっていることを確認してください。

3. セキュリティ基準とコンプライアンス評価

Security Hubのコンプライアンス評価機能は、AWSリソースの設定状態がベストプラクティスに準拠しているかを自動チェックします。

・AWS Foundational Security Best Practices：AWSが推奨するセキュリティ設定（MFAの有効化、S3のパブリックアクセス遮断、CloudTrailの有効化等）の自動評価。初めてSecurity Hubを使う場合の標準的な出発点
・CIS AWS Foundations Benchmark：CIS（Center for Internet Security）が定めたAWS環境のセキュリティ設定基準。コンプライアンス要件がある場合に有効

これらのチェックは「コントロール」単位で管理され、各コントロールのPASS/FAILが一覧表示されます。FAILになっているコントロールには修復ガイダンスも示されるため、セキュリティ改善の優先課題として活用できます。

AWSのセキュリティ設計・実務運用をより体系的に学びたい方は、AWSマスターセミナー上級編での実践ハンズオンもご確認ください。

検出結果をSNS・Lambdaで通知する

GuardDutyがFindingsを検出しても、担当者が気づかなければ対応が遅れます。EventBridge + SNS + Lambdaを組み合わせたパイプラインを構築し、重要度に応じた通知・自動対応を設計します。

1. EventBridgeルールの設定

GuardDutyのFindingsはEventBridgeにリアルタイムでイベントとして送信されます。EventBridgeルールでフィルタリングし、SNSトピックへ転送する設定を行います。


# EventBridgeルール（例：重要度HIGH以上のみ通知）
{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7.0] }]
  }
}

上記のイベントパターンをEventBridgeルールに設定すると、Severity 7.0以上（High）のFindingsのみがSNSトピックに送信されます。Medium・LowはSecurity Hubのダッシュボードで定期的にレビューする運用が実務では一般的です。

2. SNS通知の設定

EventBridgeのターゲットにSNSトピックを指定し、トピックのサブスクライバーとしてメールアドレスやSlack連携用エンドポイントを登録します。Highレベルの検出が発生したとき、担当者に即時メールやSlack通知が届く仕組みになります。

3. Lambdaによる自動対応

高優先度のFindingsに対しては、Lambdaを使って初動対応を自動化することができます。代表的なユースケースを示します。

・感染EC2の自動隔離：GuardDutyが特定のEC2インスタンスへのマルウェアC2通信を検出した場合、LambdaがそのインスタインスのセキュリティグループをすべてDenyの隔離用SGに差し替える
・不審なIAMキーの自動無効化：漏洩したIAMアクセスキーが不審な用途で使われていることをGuardDutyが検出した場合、LambdaがそのキーのステータスをInactiveに変更する


# Lambda（EC2隔離の例・Python疑似コード）
import boto3

def lambda_handler(event, context):
    detail = event['detail']
    finding_type = detail['type']
    instance_id = detail['resource']['instanceDetails']['instanceId']

    if 'Backdoor:EC2' in finding_type or 'CryptoCurrency:EC2' in finding_type:
        ec2 = boto3.client('ec2')
        # 隔離用セキュリティグループ（すべてのトラフィックを拒否）に差し替える
        ec2.modify_instance_attribute(
            InstanceId=instance_id,
            Groups=['sg-xxxxxxxx']  # 事前に用意した隔離用SG
        )
        print(f"Isolated instance: {instance_id}")

自動対応は誤検知（False Positive）時の影響が大きいため、最初はSNS通知のみで様子を見て、実運用に慣れた段階で自動化を段階的に導入することをお勧めします。

セキュリティ対応フローの設計（検知→調査→対応）

GuardDutyとSecurity Hubを有効化しても、「検出結果をどう処理するか」のフローが決まっていなければ機能しません。実務で使えるインシデント対応フローの設計指針を示します。

1. 検知→調査→封じ込め→修復→再発防止

セキュリティインシデント対応は、次の5フェーズで設計します。

・検知（Detection）：GuardDutyのFinding、Security Hubのコントロール違反を確認する
・調査（Investigation）：CloudTrailでそのFindingに関連するAPIコール履歴を調べ、「誰が・いつ・何をしたか」を特定する。dig コマンドで DNS を調べるような要領で、ドメイン名・IPアドレスの逆引き確認も有用です
・封じ込め（Containment）：影響を受けたリソース（EC2・IAMキー等）を隔離し、被害の拡大を防ぐ
・修復（Remediation）：根本原因を取り除く（脆弱なAMIの更新、過剰なIAM権限の削除等）
・再発防止（Post-incident）：インシデントの教訓をConfig Rulesやセキュリティ基準のコントロールに反映させ、同じ問題が再発しないように自動検出の仕組みを強化する

2. Findingsの優先度付けと誤検知対応

Security Hubのダッシュボードでは、GuardDutyをはじめとする複数ソースのFindingsを重要度順にソートして確認できます。運用上重要なルールを示します。

・High（7.0以上）：24時間以内に調査・初動対応を完了させる
・Medium（4.0～6.9）：72時間以内に調査開始。定期レビューの対象に加える
・Low（1.0～3.9）：週次レビューで傾向を確認。繰り返し発生するパターンはルール調整を検討する

GuardDutyは機械学習ベースのため、初期は誤検知（False Positive）が発生することがあります。「社内の特定のIPからのスキャンツール実行」など、業務上想定される動作がFindingとして検出された場合は、GuardDutyの「信頼済みIPリスト（Trusted IP List）」や「脅威リスト」を使って除外設定を行います。Security HubのFindingに対してはワークフローステータスを「サプレスト」に設定することで、ダッシュボードのノイズを減らせます。

3. 実サーバーでの確認例

GuardDutyとCloudTrailを連携させた実際のインシデント調査例を示します。GuardDutyがRecon（偵察活動）系のFindingを検出した場合、AWS CLIで詳細を確認します。


# GuardDuty Findingsの一覧取得（AWS CLI）
$ aws guardduty list-findings \
  --detector-id [detector-id] \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7,"Lte":8.9}}}'

# Findingの詳細取得
$ aws guardduty get-findings \
  --detector-id [detector-id] \
  --finding-ids [finding-id]

# 出力例（一部抜粋）
{
    "Findings": [
        {
            "Type": "Recon:EC2/PortProbeUnprotectedPort",
            "Severity": 2.0,
            "Description": "EC2 instance i-0abc123 is being probed on port 22.",
            "Resource": {
                "ResourceType": "Instance",
                "InstanceDetails": {
                    "InstanceId": "i-0abc123",
                    "NetworkInterfaces": [
                        { "PublicIp": "203.0.113.x" }
                    ]
                }
            }
        }
    ]
}

ポートスキャンの検出であれば、該当EC2インスタンスのLinux ポート確認の全コマンドでどのポートが実際に開放されているかを確認し、不要なポートのセキュリティグループルールを即座に見直すことが初動対応の基本です。

マルチアカウント環境での一元管理

本番環境・開発環境・ステージング環境を別々のAWSアカウントで管理しているケースでは、各アカウントでGuardDutyとSecurity Hubを個別に確認するのは現実的ではありません。AWS Organizationsと組み合わせることで、全アカウントを一元管理できます。

1. GuardDutyの組織管理（委任管理者アカウント）

AWS OrganizationsのマスターアカウントからGuardDutyの「委任管理者（Delegated Administrator）」として専用のセキュリティ監視アカウントを指定します。設定後は以下が可能になります。

・新しくOrganizationsに参加したアカウントに対してGuardDutyを自動有効化できる
・委任管理者アカウントのダッシュボードから、全メンバーアカウントのFindingsを集約して確認できる
・各アカウントのGuardDuty設定（信頼済みIPリスト等）を委任管理者から一元配布できる

# GuardDuty委任管理者の設定（Organizations管理アカウントで実行） $ aws guardduty enable-organization-admin-account \ --admin-account-id [security-account-id] # 新メンバーの自動有効化設定 $ aws guardduty update-organization-configuration \ --detector-id [detector-id] \ --auto-enable-organization-members ALL

2. Security Hubのクロスリージョン・クロスアカウント集約

Security Hubには「集約リージョン（Aggregation Region）」の設定があります。例えばap-northeast-1（東京）を集約リージョンとして指定すると、他のリージョンのFindingsが東京リージョンのSecurity Hubに集約されます。

Organizations連携では、GuardDutyと同様に委任管理者アカウントを設定することで、全組織アカウントのSecurity Hub Findingsとコンプライアンス状態を一元ダッシュボードで確認できます。

3. コスト管理と運用上の注意

マルチアカウント構成でGuardDutyとSecurity Hubを全アカウント・全リージョンで有効化すると、コストが想定外に膨らむことがあります。特にGuardDutyのデータイベント（S3、EKS）は処理データ量に比例するため、本番アカウントのみで有効化し、開発アカウントでは管理イベントのみに絞るといったコスト最適化が有効です。

Security HubのコントロールもFinding数に応じた課金があるため、評価不要な基準（CISとFSBPの両方を有効化した場合の重複チェック等）は整理してから本番稼働させることをお勧めします。

まとめ

aws guardduty security hub を活用した脅威検知設計の要点を整理します。

設計項目	推奨設定・ポイント
GuardDutyの有効化	全リージョンで有効化。S3保護・EKS保護も用途に応じて追加
Security Hubの統合	GuardDutyと統合し、AWS FBSPまたはCISベンチマークを有効化
通知パイプライン	EventBridge→SNS（高優先度）、Lambda自動対応は段階的に導入
対応フロー設計	検知→調査→封じ込め→修復→再発防止の5フェーズで標準化
優先度管理	High（24h以内）・Medium（72h以内）・Low（週次）で対応期限を定める
マルチアカウント	Organizations + 委任管理者アカウントで全体一元管理
コスト最適化	拡張機能・コンプライアンス基準は必要なものだけ有効化して監視

GuardDutyとSecurity Hubは有効化するだけで価値が出るサービスではありません。「どの検出結果を誰がどう処理するか」の対応フローと、EventBridgeによる通知・自動化の設計まで含めて初めて、実務で機能するセキュリティ運用体制になります。まずは東京リージョンだけGuardDutyとSecurity Hubを有効化し、Findingsの傾向を1週間観察することを最初のステップとして始めてみてください。

AWSのセキュリティ設計・マルチアカウントガバナンスをより体系的に学びたい方は、AWSマスターセミナー上級編での実践ハンズオンを検討してみてください。

GuardDutyを「使える」エンジニアは、Linuxの設計思想がわかっています

GuardDutyの設定自体はコンソールで数クリックですが、「どの検出結果をどう処理するか」「自動対応をどこまで入れるか」を現場で判断できますか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒）＞＞図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

次のページへ：AWS Well-Architected Frameworkで構成をレビューする方法｜6つの柱と改善の優先順位付け
前のページへ：AWS SQSとSNSで疎結合アーキテクチャを設計する方法｜キューイングとファンアウトの使い分け
この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る