TL

Cloud Service

AWS Security Hub

複数のセキュリティサービスの検出結果を集約し、基準で評価する統合ダッシュボード。組織全体の状態を一元把握する。

中級SCS-C02セキュリティ運用上の優秀性
最終更新: 2026-06-13公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.GuardDutyやInspectorなどの検出結果を共通フォーマットで集約する統合ハブ。
  • 2.CISやAWS基礎セキュリティなどの基準に照らして自動でスコア評価する。
  • 3.委任管理者とリージョン集約で組織全体を一元管理し、検出結果へ自動対応できる。

解決する課題

  • セキュリティ系サービスが増え、検出結果がサービスごとにバラバラ → 一箇所に集約して見たい
  • 「自社の設定は基準を満たしているか」を毎回手作業で確認するのは大変 → 基準で自動評価したい
  • アカウントもリージョンも多数あり、全体像が見えない → 組織横断で一元把握したい

主要概念と用語

  • 検出結果(Findings): セキュリティ上の気づき。各サービスが生成し、Security Hubが取り込む単位
  • ASFF: AWS Security Finding Format。検出結果を表す共通フォーマット。出どころの違うデータを同じ形に揃える
  • セキュリティ基準(Standards): 設定が望ましい状態かを判定する規格群。AWS基礎セキュリティ、CIS、PCI DSSなど
  • コントロール(Controls): 基準を構成する個々のチェック項目。合格・不合格・該当なしで評価される
  • セキュリティスコア: 合格したコントロールの割合を百分率で示す指標
  • インサイト(Insights): 検出結果を条件でまとめた集計ビュー。注目すべき集団を浮かび上がらせる
  • 委任管理者: 組織内でSecurity Hubを統括するアカウント。複数アカウントの結果を束ねる

仕様・制限・クォータ

  • リージョン単位のサービス。各リージョンで個別に有効化し、複数リージョンの結果は集約リージョンへまとめられる
  • 検出結果は一定期間(おおむね数か月程度)保持された後に削除される。長期保管したい場合は別途エクスポートする
  • 連携元の検出結果は自動取り込み。サードパーティ製品も対応していれば取り込める
  • 取り込みやチェック実行に応じた従量課金で、有効化しただけでは多くの場合無料枠の範囲に収まる

内部の仕組み

GuardDuty・Inspector・Macie・IAM Access Analyzerなどの連携元が検出結果を生成すると、Security Hubがそれを ASFF に正規化して取り込みます。出どころが違っても同じ項目(重要度・リソース・状態など)で扱えるため、横断検索やフィルタが効きます。

並行して、有効化した セキュリティ基準 のコントロールが定期的にチェックを実行し、合格・不合格を判定します。多くのチェックは内部的に AWS Config のルールを用いるため、Config を有効化しておくことが前提になります。判定結果は セキュリティスコア として集計されます。

検出結果はそのまま EventBridge に流れるため、しきい値超えで通知したり、自動修復のワークフローを起動したりできます。

Config が前提

多くのコントロールは AWS Config のルールで評価されます。Config が無効だと、関連コントロールが「データ不足」となりスコアが正しく出ません。基準を有効化する前に Config を有効化してください。

設計パターン / ベストプラクティス

  • 組織管理と委任管理者: AWS Organizations と連携し、専用の委任管理者アカウントで全体を統括する
  • 集約リージョンの設定: 複数リージョンの検出結果を1つの集約リージョンへまとめ、確認の手間を減らす
  • 自動有効化: 新規アカウントでも自動でSecurity Hubと基準が有効になるよう設定する
  • ノイズ抑制: 既知で対応不要な検出結果は抑制ルールで自動的に処理し、本当に見るべきものに集中する
  • 検出結果の集約先: GuardDutyなどを個別に開かず、Security Hubを単一の入口(シングルペインオブグラス)として運用する

運用・監視

  • **重要度(Critical/High/...)**で優先順位を付け、高重要度から対応する
  • 検出結果のワークフロー状態(新規・対応中・解決済みなど)を更新し、対応の進捗を追跡する
  • EventBridge 経由でSNS通知やLambda・Step Functionsによる自動修復をつなぐ
  • インサイトで「特定アカウントに集中する不合格」などの傾向を把握する
  • スコアの推移を定点観測し、悪化したら原因コントロールを特定する

コスト

従量課金で、主に セキュリティチェックの実行回数取り込んだ検出結果の件数 に対して課金されます。有効化直後は無料利用枠で試せることが多く、対象アカウント・リージョンを広げるほど費用が増えます。コントロールを絞る、不要なリージョンで有効化しないことで費用を抑えられます。最新の料金は公式の料金ページで確認してください。

セキュリティ

  • 検出結果には機微な情報が含まれうるため、閲覧・更新権限を 最小権限 で絞る
  • 委任管理者アカウントへのアクセスは特権扱いとし、MFAなどで保護する
  • 集約や自動修復に使うロールの権限を必要範囲に限定する
  • Security Hub自体は検出と評価が役割であり、修復はGuardDutyやConfigなど各サービスと組み合わせて実現する

Well-Architected の観点

  • セキュリティ: 検出結果の一元化と基準評価により、組織全体のセキュリティ状態を継続的に可視化する中核となる
  • 運用上の優秀性: スコアと検出結果をイベント駆動で自動処理に結びつけ、対応を仕組み化できる

試験で問われるポイント

頻出
  • Security Hubは 検出結果の集約と基準評価 が役割。検出そのものはGuardDutyやInspectorが行う
  • 検出結果の共通フォーマットは ASFF
  • 多くのコントロールは AWS Config に依存する
  • 組織横断管理は 委任管理者集約リージョン
  • 自動対応は EventBridge との連携で実現する

関連サービス・比較

観点Security HubGuardDuty
役割検出結果の集約と基準評価脅威の検出エンジン
主な入力各サービスの検出結果と設定状態ログとネットワークの挙動
出力統合ダッシュボードとスコア脅威の検出結果
関係GuardDutyの結果を取り込む側Security Hubへ結果を渡す側

ハンズオン / CLI例

# Security Hub を有効化(AWS基礎セキュリティ基準なども既定で有効化される)
aws securityhub enable-security-hub --enable-default-standards

# 高重要度かつ未対応の検出結果だけを抽出して確認
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}'

# 有効になっているセキュリティ基準を一覧
aws securityhub get-enabled-standards

AWS Service

AWS Security Hubを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

セキュリティ・ID

比較で見る軸

クラウド: AWS / カテゴリ: セキュリティ・ID / 難易度: intermediate

導入後に効く点

CISやAWS基礎セキュリティなどの基準に照らして自動でスコア評価する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
セキュリティ・ID
難易度
intermediate
関連資格
SCS-C02
設計柱
security / operational

判断チェックリスト

  • 自社の用途が「セキュリティ・ID / security」に近いか確認する。
  • 強みである「GuardDutyやInspectorなどの検出結果を共通フォーマットで集約する統合ハブ。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

セキュリティ・IDsecurityoperationalSCS-C02