アカウントを作った直後の設定（MFA と CloudTrail）は済ませた。次に GuardDuty、Inspector、Config、Security Hub のどれを入れるか、と考えて手が止まる。どれも「セキュリティの検出結果」を出し、画面も似ていて、全部入れるべきなのか、順番があるのかが分からない。この記事は、4つを「何を見張るか」で分け、入れる順と組織での置き方を決められるようにします。
この記事の結論
- GuardDuty は脅威（不審な振る舞い）、Inspector は脆弱性、Config は設定の記録と準拠評価を見ます。見張る対象が違うので、互いの代わりにはなりません。
- Security Hub は検出する側ではなく集める側です。GuardDuty や Inspector などの検出結果を1か所に集め、基準に照らしたチェックも出します。
- Security Hub の多くのコントロールは Config の記録が前提になります。Security Hub を入れるなら Config も必要です。
- 入れる順は「設定の土台（Config）→ 脅威（GuardDuty）→ 脆弱性（Inspector）→ 集約（Security Hub）」を基本に、扱う資源で調整します。
- 複数アカウントでは、セキュリティ専用アカウントを委任管理者にして、組織全体へ自動で有効化します。
似た検出結果が出る4つのサービスは、何が違うのか
4つが混ざって見えるのは、どれも最後は「要対応の指摘」という形で現れるからです。しかし指摘が生まれる理由は別々です。
- 誰かが不審な操作をした、あるいは資源が不審な通信をしている → 振る舞いの問題
- 動かしているソフトウェアに既知の欠陥がある → 脆弱性の問題
- 資源の設定が、決めた規則から外れている → 設定の問題
- それらを担当者が1か所で見たい → 集約の問題
つまり、「どのサービスを入れるか」は「自分は何を見張りたいのか」に言い換えられます。サービス名から入ると混乱し、見張る対象から入ると整理できます。この記事では、この4つの切り口を全体で使います。
なお、責任共有モデルの上では、クラウド内の設定・OS・アプリケーション・データは利用者の責任です（台帳 shared-responsibility の言い方では、クラウド「の」セキュリティは AWS、クラウド「内の」セキュリティは利用者）。ここで扱う4つは、その利用者側の責任を果たすための目になるサービスです。Well-Architected フレームワークのセキュリティの柱で言えば、検知を整える領域にあたります。
見張る対象で分ける｜振る舞い・脆弱性・設定・集約
まず4つを1枚で並べます。
見張る対象で分ける
4つは振る舞い・脆弱性・設定を見て、Security Hub が集める
-
振る舞い
GuardDuty — 不審な操作や通信の脅威を検出
CloudTrail・フローログ・DNS ログが基礎
-
脆弱性
Inspector — EC2・ECR・Lambda の脆弱性を継続スキャン
検出結果は Security Hub へも送れる
-
設定
Config — 構成を記録し、ルールで準拠を評価
Security Hub のチェックの前提になる
-
集約
Security Hub — 結果を1か所に集め、基準でチェック
自分では脅威も脆弱性も検出しない
| サービス | 見張る対象 | 何を材料にするか | 出てくるもの |
|---|---|---|---|
| Amazon GuardDuty | 不審な振る舞い（脅威） | CloudTrail の管理イベント、VPC フローログ、DNS ログが基礎。保護プランで S3・EKS・RDS・Runtime Monitoring などを追加 | 脅威の検出結果 |
| Amazon Inspector | ソフトウェアの脆弱性とネットワークの露出 | EC2、ECR のコンテナイメージ、Lambda を継続スキャン | 脆弱性の検出結果 |
| AWS Config | 資源の設定 | 構成の記録と履歴、ルールによる準拠評価 | 構成の履歴、準拠・非準拠の評価 |
| AWS Security Hub | 検出結果の集約と基準への準拠 | 他サービスの検出結果、基準（FSBP・CIS・PCI DSS・NIST など）に基づくチェック | 1か所にまとまった結果 |
GuardDuty は「振る舞い」を見る
Amazon GuardDuty は、ログを自分で集めて検知ルールを書かなくても、アカウント内の脅威を継続的に検出するサービスです。基礎のデータ源は CloudTrail の管理イベント、VPC フローログ、DNS ログで、エージェントの導入は要りません。S3 や EKS、RDS、Runtime Monitoring などは保護プランとして足していきます。見るのは「誰が何をしたか」「どこと通信したか」であり、ソフトウェアの欠陥の有無や設定の良し悪しではありません。
Inspector は「脆弱性」を見る
Amazon Inspector は、EC2、ECR のコンテナイメージ、Lambda 関数を継続的にスキャンし、ソフトウェアの脆弱性とネットワークの露出を検出します。新しい脆弱性が公開されたあとも、対象を継続して評価する点が、一度きりの診断との違いです。検出結果は Security Hub にも送れます。
Config は「設定」を見る
AWS Config は、資源の構成を記録して履歴として残し、ルールで準拠かどうかを評価します。ルールをまとめた適合パック、非準拠を直す修復、複数アカウントを横断して見るアグリゲーターもあります。GuardDuty や Inspector が「いま起きていること・今ある欠陥」を拾うのに対し、Config は「設定がいつ、どう変わったか」を答えられます。たとえば SSH を全開放したセキュリティグループがあるかどうかは、Config のルールで継続的に評価できます。
練習問題との対応
試験でも、この分担がそのまま問われます。脅威の継続検出は GuardDuty、EC2・ECR・Lambda の脆弱性は Inspector、構成の記録と準拠評価は Config、検出結果の集約は Security Hub、という対応です。実務でこの4つを選ぶときも、同じ対応で足ります。
CHECK 1ここまでの確認
見慣れない場所からの API 呼び出しや、不審な宛先への通信の兆候を継続的に拾いたいとき、中心になるのはどれか?
答えと解説
答え: 2. Amazon GuardDuty
振る舞い（脅威）を見るのが GuardDuty の役割です。Inspector は脆弱性、Config は設定を見ます。「見張る対象で分ける」の表を読み直してください。
CHECK 2ここまでの確認
EC2 やコンテナイメージに含まれるソフトウェアの既知の脆弱性を、継続的に見つけ出したいときに使うのは?
答えと解説
答え: 1. Amazon Inspector
脆弱性のスキャンが Inspector の役割です。Security Hub は結果を集める側で、自分では脆弱性を検出しません。
Security Hub とは何か｜検出する側ではなく集める側という位置づけ
AWS Security Hub（現在の公式の名称は Security Hub CSPM として説明されています）は、検出結果の集約と、基準に基づくチェックを行うサービスです。ここで大事なのは、脅威や脆弱性を自分で見つけるわけではないことです。GuardDuty、Inspector などの結果を受け取り、1か所の画面に並べるのが主な仕事です。
役割は2つあります。
- 集約: 他サービスの検出結果を、共通の形式でまとめて見られるようにする
- 基準チェック: FSBP（AWS の基礎的なセキュリティのベストプラクティス）、CIS、PCI DSS、NIST などの基準に照らして、資源の設定を評価する
2つ目のチェックは、多くのコントロールで Config の有効化と記録が前提です。Security Hub は設定の記録を Config から得て評価するため、Config を有効にしていなければ、チェックが機能しません。この依存を知らないまま Security Hub だけを入れると、「入れたのに何も出ない」「評価されない資源がある」という状態になります。
ここで、Security Hub を「4つの親玉」と誤解しないでください。親玉に見えるのは、画面の上で結果が1枚に集まるからです。構成としては、検出側（GuardDuty・Inspector・Config）が下にあり、Security Hub はその結果を読む上の層です。
料金や無料トライアルの数値は、この記事では書きません。公式の料金ページで、使う時点の値を確認してください。
CHECK 3ここまでの確認
Security Hub の位置づけとして正しい説明はどれか?
答えと解説
答え: 2. 各サービスの検出結果を集め、基準に照らしたチェックも出すサービス
Security Hub は集める側です。検出そのものは GuardDuty や Inspector などが行います。「Security Hub とは何か」の章を読み直してください。
どの順で有効にするか｜資源の種類と段階で決める判断軸
4つを一斉に有効にしても構いませんが、段階を踏むと、各段で「何が見えるようになったか」を確かめながら進められます。基本の順は次のとおりです。
TURN IT ON有効にする順の門
設定の記録から始めて、最後に集約の門を開ける
有効にする順（各段で何が分かるようになるか）
- 1Config 設定が分かる設定の記録と準拠評価
- 2GuardDuty 脅威が分かる不審な振る舞いの検出
- 3Inspector 脆弱性が分かるEC2・ECR・Lambda のスキャン
- 4Security Hub 1か所で見える結果の集約と基準チェック
基本の順とその理由
- Config（設定の土台）: 設定の記録は、有効にした時点から先のものしか残りません。あとから過去を取り戻せないので、早く入れる価値があります。また Security Hub のコントロールの前提にもなります。
- GuardDuty（脅威）: ログの基礎データ源を自分で整えなくても、検出を始められます。資源の種類に関係なく、アカウント全体に効くので、早い段階で入れやすい選択です。
- Inspector（脆弱性）: 検査する資源（EC2・ECR・Lambda）があって初めて意味が出ます。
- Security Hub（集約）: 集める元ができたあとに入れると、最初から意味のある一覧になります。
扱う資源で調整する
基本の順は、資源の使い方で入れ替えます。
| 扱っている資源 | 優先して考えること |
|---|---|
| EC2 を多く運用している | Inspector の優先度が上がる。OS やパッケージの脆弱性を継続的に見たい |
| コンテナ（ECR・EKS）が中心 | Inspector の ECR スキャンと、GuardDuty の EKS 向けの保護プランを組み合わせる |
| Lambda や S3 が中心 | GuardDuty の S3 向けの保護プランと、Inspector の Lambda スキャンを検討する |
| 規制や社内基準への準拠が要る | Config と Security Hub を早めに入れ、基準チェックを見られる状態にする |
どの場合も、GuardDuty と Inspector は片方がもう片方の代わりになりません。資源の使い方で「先に入れる方」を決めるだけで、最終的には両方が要ると考えるのが安全です。
複数アカウントで有効にする設計｜委任管理者と自動有効化
アカウントが1つなら、ここまでの話で足ります。組織でアカウントが増えると、「各アカウントで有効にし忘れる」「結果が散らばる」という問題が出ます。対応は、Organizations と組み合わせた運用です。
委任管理者に集める
メンバーの検出結果を、セキュリティ専用アカウントで見る
-
管理アカウント
請求と組織の管理だけ
-
委任管理者を指定
セキュリティ専用アカウント
-
自動有効化
新しいアカウントも対象
-
結果が集まる
組織全体を1か所で確認
管理アカウントでは運用しない
Organizations の管理アカウントは、請求と組織の管理に絞って使います。そこで検知サービスの設定や結果の確認まで行うと、強い権限を持つアカウントの利用が増え、事故の影響が大きくなります。そこで、セキュリティ専用のアカウントを、各サービスの委任管理者にします。GuardDuty や Security Hub などは委任管理者を指定でき、委任管理者のアカウントから組織のメンバーアカウントを管理できます。
自動有効化で漏れをなくす
委任管理者を決めたら、新しく作られるアカウントにも自動で有効化する設定を入れます。これがないと、アカウントを増やすたびに有効化の作業が必要になり、有効化を忘れたアカウントが検知の穴になります。
設計の要点
- 委任管理者は、サービスごとに登録する（GuardDuty、Security Hub、Inspector など）。同じセキュリティ専用アカウントにまとめると、確認する場所が1つになる
- Config は、複数アカウントとリージョンを横断して見るアグリゲーターを使うと、準拠状況をセキュリティ用アカウントから参照できる
- Security Hub は、クロスリージョンの集約を設定すれば、ホームリージョンで結果を1か所に寄せられる
- 検知サービスを無効にできる権限は、通常のメンバーアカウントの管理者には渡さない
「どのアカウントを何に使うか」の全体像は、マルチアカウント設計の記事で扱います。
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウント設計｜アカウントを「境界」として使い、Organizations と SCP で組織のガードレールを引く
CHECK 4ここまでの確認
組織で運用するとき、検知サービスの設定や結果の確認はどこで行うのがよいか?
答えと解説
答え: 2. セキュリティ専用アカウントを委任管理者にして行う
管理アカウントは請求と組織の管理に絞り、セキュリティ専用アカウントを委任管理者にします。「複数アカウントで有効にする設計」の章を読み直してください。
検出結果が増えたあとの扱い｜EventBridge で自動対応する範囲を決める
有効にしたあとに待っているのは、検出結果の山です。GuardDuty、Inspector、Config、Security Hub は、検出結果を EventBridge に流せます。ここで人が見る範囲と、自動で処理する範囲を決めます。
- 人が見る: 判断が要るもの。たとえば業務に影響するかどうかの確認が要る検出結果
- 自動で処理する: 手順が決まっていて、誤って動いても戻せるもの。たとえば GuardDuty の検出結果を EventBridge で受けて、Lambda で隔離用のセキュリティグループに付け替える処理や、Config ルールの非準拠を Systems Manager Automation で自動修復する処理
自動化は、はじめから広げません。止めてよい資源、戻せる操作に限って始め、動きを見てから範囲を広げます。逆に、本番の資源を判断なしに止める処理を全検出結果に付けると、誤検知のたびに業務が止まります。
Security Hub のカスタムアクションを使えば、アナリストが確認して選んだ検出結果だけを、EventBridge 経由で処理に回す形も作れます。「全部自動」と「全部手動」の間に、段階を置くのが設計の勘所です。
まとめ
4つのサービスは、振る舞い（GuardDuty）、脆弱性（Inspector）、設定（Config）、集約（Security Hub）という見張る対象で分けると、役割が重ならずに整理できます。Security Hub は集める側で、Config の記録が前提になります。入れる順は Config → GuardDuty → Inspector → Security Hub を基本に、扱う資源で調整し、組織ではセキュリティ専用アカウントを委任管理者にして自動有効化します。そのうえで、検出結果が増えたら、自動で処理する範囲を段階的に決めます。
Cloudory 執筆者（AWS 認定 全冠）
この記事は生成 AI の下書きを、公式ドキュメントと照らして確認したものです。製品の機能名や基準の一覧は改定されるため、設定の前に各サービスの公式ドキュメントで最新の内容を確かめてください。
参照ソース
- Amazon GuardDuty とは — GuardDuty が脅威検出であること、基礎のデータ源（CloudTrail 管理イベント・VPC フローログ・DNS ログ）と保護プランの根拠
- Amazon Inspector とは — EC2・ECR・Lambda の継続スキャンと、脆弱性・ネットワークの露出の検出、Security Hub への送信の根拠
- AWS Config とは — 構成の記録と履歴、ルールによる準拠評価、適合パック、修復、アグリゲーターの根拠
- AWS Security Hub とは — 検出結果の集約、基準（FSBP・CIS・PCI DSS・NIST）に基づくチェック、Config の有効化が必要なコントロールの根拠
- AWS 責任共有モデル — クラウド「の」セキュリティと「内の」セキュリティの分担（台帳
shared-responsibility） - AWS Well-Architected フレームワーク — セキュリティの柱との対応（台帳
well-architected）
