AWS Security Hub
AWS 環境全体のセキュリティ態勢を一元的に可視化し、業界標準のセキュリティ基準に照らした自動評価と検出結果の集約を行うサービスである。
概要
AWS Security Hub は、GuardDuty、Inspector、Macie、Firewall Manager など複数のセキュリティサービスの検出結果を ASFF (AWS Security Finding Format) という統一フォーマットで集約し、ダッシュボード上で一元管理するサービスです。CIS AWS Foundations Benchmark、AWS Foundational Security Best Practices、PCI DSS などの業界標準に基づくセキュリティチェックを自動実行し、各リソースの準拠状況をスコアとして可視化します。AWS Organizations と統合すれば、数百のアカウントにまたがるセキュリティ態勢を管理者アカウントから一括で監視・管理できます。
ASFF が解決する検出結果の分断問題
AWS のセキュリティサービスはそれぞれ独自のフォーマットで検出結果を出力します。GuardDuty は脅威インテリジェンスに基づく検出、Inspector は脆弱性スキャン、Macie は機密データの検出と、目的も出力形式も異なります。Security Hub はこれらを ASFF (AWS Security Finding Format) という共通スキーマに正規化して取り込みます。ASFF は検出結果の重要度 (Severity)、影響を受けるリソース (Resources)、修復手順 (Remediation) などを統一的に記述するフォーマットで、サードパーティ製品の検出結果も同じ形式で統合できます。この正規化により、異なるソースの検出結果を横断的にフィルタリング・ソート・集計できるようになります。たとえば「重要度が CRITICAL かつ過去 24 時間以内に検出されたもの」を全サービス横断で抽出するといった運用が可能です。Azure の対応サービスである Microsoft Defender for Cloud も同様にセキュリティ態勢の一元管理を提供しますが、ASFF のようなオープンなフォーマット仕様を公開している点は Security Hub の特徴です。
セキュリティ基準の選定とスコア運用の実際
Security Hub には複数のセキュリティ基準 (Standards) が組み込まれており、有効化するだけで AWS Config ルールベースの自動チェックが走ります。AWS Foundational Security Best Practices (FSBP) は AWS が推奨するベースラインで、S3 バケットのパブリックアクセス設定、RDS の暗号化有無、IAM ルートアカウントの MFA 設定など、基本的なセキュリティ項目を網羅します。CIS AWS Foundations Benchmark はより厳格な基準で、CloudTrail のログファイル検証やパスワードポリシーの複雑性要件まで踏み込みます。実務では全基準を一度に有効化すると検出結果が大量に発生し、対応の優先順位が見えなくなります。まず FSBP を有効化してスコアを 90% 以上に引き上げ、その後 CIS を追加するのが現実的なアプローチです。スコアは PASSED / FAILED / NOT_AVAILABLE の比率で算出され、FAILED のコントロールを 1 つずつ潰していくことでスコアが改善します。クラウドセキュリティの関連書籍 (Amazon) では、こうしたセキュリティ基準の選定と運用プロセスが体系的に解説されています。
Organizations 連携と自動修復パイプライン
マルチアカウント環境では Security Hub の Organizations 統合が不可欠です。管理アカウントで Security Hub の委任管理者を指定すると、Organizations 配下の全アカウントで Security Hub が自動有効化され、検出結果が管理者アカウントに集約されます。新規アカウントが追加された場合も自動的に Security Hub が有効化されるため、設定漏れが発生しません。集約された検出結果に対して自動修復を実装するには、EventBridge と Lambda (または Systems Manager Automation) を組み合わせます。たとえば「S3 バケットのパブリックアクセスが検出されたら自動でブロック設定を有効化する」「セキュリティグループで 0.0.0.0/0 からの SSH が許可されていたら自動で削除する」といったルールを定義できます。ただし自動修復は意図しないサービス影響を引き起こすリスクがあるため、最初は通知のみにとどめ、十分な検証を経てから自動修復に切り替えるのが安全です。カスタムアクションを定義すれば、検出結果を手動で選択して修復ワークフローをトリガーする半自動の運用も可能です。