Cloud Service
AWS Security Hub
複数のセキュリティサービスの検出結果を集約し、基準で評価する統合ダッシュボード。組織全体の状態を一元把握する。
- 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 に流れるため、しきい値超えで通知したり、自動修復のワークフローを起動したりできます。
多くのコントロールは 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 Hub | GuardDuty |
|---|---|---|
| 役割 | 検出結果の集約と基準評価 | 脅威の検出エンジン |
| 主な入力 | 各サービスの検出結果と設定状態 | ログとネットワークの挙動 |
| 出力 | 統合ダッシュボードとスコア | 脅威の検出結果 |
| 関係 | 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。