AWS Control Towerでランディングゾーンを構築し、ガードレールでコンプライアンスを自動化できるようになりました。次のステップとして、AWS Security Hubを活用した組織全体のセキュリティ監視体制の構築が重要です。Security Hubは、複数のセキュリティサービスからの検出結果を集約し、業界標準に基づいた継続的なコンプライアンスチェックを自動化するサービスです。本記事では、Security HubとControl Towerの連携から実践的な運用方法まで体系的に解説します。
AWS Security Hubとは
AWS Security Hubは、AWSアカウント全体のセキュリティ状態を一元的に可視化し、セキュリティのベストプラクティスとの差分を自動的に検出するサービスです。複数のAWSセキュリティサービスやサードパーティツールからの検出結果を集約し、優先度付けされたセキュリティアラートとして提供します。
Security Hubの主要機能
Security Hubは、以下の3つの主要機能を提供します。
flowchart TB
subgraph "AWS Security Hub"
direction TB
F1[セキュリティ検出結果の集約<br/>複数サービスからの統合]
F2[セキュリティ標準による自動チェック<br/>継続的なコンプライアンス評価]
F3[自動化された対応<br/>EventBridgeとの連携]
end
subgraph "検出結果のソース"
GD[GuardDuty<br/>脅威検出]
INSP[Inspector<br/>脆弱性評価]
MM[Macie<br/>機密データ検出]
FW[Firewall Manager<br/>ファイアウォール管理]
IAM_AA[IAM Access Analyzer<br/>アクセス分析]
CFG[AWS Config<br/>設定監視]
THIRD[サードパーティ製品]
end
GD --> F1
INSP --> F1
MM --> F1
FW --> F1
IAM_AA --> F1
CFG --> F1
THIRD --> F1| 機能 | 説明 | 主なユースケース |
|---|---|---|
| 検出結果の集約 | 複数サービスからのセキュリティアラートを一元管理 | セキュリティ運用の効率化 |
| セキュリティ標準 | CIS、PCI DSS等の業界標準に基づく自動チェック | コンプライアンス対応 |
| 自動対応 | EventBridgeを通じた自動修復ワークフロー | インシデント対応の迅速化 |
Security Hubのアーキテクチャ
Security Hubは、AWS Security Finding Format(ASFF)という標準化されたフォーマットで検出結果を管理します。これにより、異なるソースからの検出結果を統一的に扱えます。
flowchart LR
subgraph "検出結果ソース"
SRC1[GuardDuty]
SRC2[Inspector]
SRC3[Config Rules]
SRC4[カスタム統合]
end
subgraph "Security Hub"
ASFF[ASFF変換]
AGGREGATE[検出結果集約]
STANDARDS[標準チェック]
INSIGHTS[インサイト]
end
subgraph "出力先"
CONSOLE[コンソール]
EB[EventBridge]
S3[S3エクスポート]
SIEM[SIEM連携]
end
SRC1 --> ASFF
SRC2 --> ASFF
SRC3 --> ASFF
SRC4 --> ASFF
ASFF --> AGGREGATE
AGGREGATE --> STANDARDS
AGGREGATE --> INSIGHTS
STANDARDS --> CONSOLE
INSIGHTS --> CONSOLE
AGGREGATE --> EB
AGGREGATE --> S3
AGGREGATE --> SIEMControl TowerとSecurity Hubの連携
AWS Control Towerは、ランディングゾーン内のすべてのアカウントでSecurity Hubを自動的に有効化し、集中管理を実現できます。これにより、組織全体のセキュリティ状態を一元的に監視できます。
Control TowerによるSecurity Hub設定
Control Towerでは、Security Hubをガードレールの一部として統合できます。監査アカウント(Audit Account)がSecurity Hubの委任管理者として機能し、全アカウントの検出結果を集約します。
flowchart TB
subgraph "管理アカウント"
MGMT[管理アカウント<br/>Organizations管理]
end
subgraph "Security OU"
AUDIT[監査アカウント<br/>Security Hub管理者]
LOG[ログアーカイブアカウント]
end
subgraph "Workloads OU"
PROD1[本番アカウント1]
PROD2[本番アカウント2]
DEV[開発アカウント]
end
MGMT -->|委任| AUDIT
AUDIT -->|検出結果集約| PROD1
AUDIT -->|検出結果集約| PROD2
AUDIT -->|検出結果集約| DEV
AUDIT -->|ログ送信| LOGSecurity Hubの有効化手順
Control Tower環境でSecurity Hubを組織全体に展開する手順を解説します。
手順1: 監査アカウントでSecurity Hubを有効化
監査アカウントにサインインし、Security Hubを有効化します。
|
|
手順2: 組織の委任管理者として登録
管理アカウントから監査アカウントを委任管理者として登録します。
|
|
手順3: メンバーアカウントの自動有効化設定
新規アカウントで自動的にSecurity Hubが有効化されるよう設定します。
|
|
Control Towerガードレールとの連携
Control Towerのガードレール(特に検出的ガードレール)とSecurity Hubは、AWS Configルールを共通基盤として連携します。
flowchart TB
subgraph "Control Tower"
GR[検出的ガードレール]
end
subgraph "AWS Config"
RULES[Config Rules]
end
subgraph "Security Hub"
STD[セキュリティ標準]
FINDINGS[検出結果]
end
GR -->|Config Rules実装| RULES
RULES -->|評価結果| GR
RULES -->|検出結果送信| FINDINGS
STD -->|追加チェック| RULES| 連携ポイント | 説明 |
|---|---|
| Config Rules共有 | Control TowerとSecurity Hubの両方でAWS Config Rulesを活用 |
| 検出結果の統合 | ガードレール違反がSecurity Hubの検出結果としても表示 |
| 一元管理 | 監査アカウントで両方の状態を確認可能 |
セキュリティ標準と自動チェック
Security Hubは、業界で認められたセキュリティフレームワークに基づいたセキュリティ標準を提供します。これらの標準を有効化することで、AWSリソースの設定を継続的に評価し、ベストプラクティスとの差分を自動検出できます。
利用可能なセキュリティ標準
Security Hubでは、以下のセキュリティ標準が利用可能です。
| 標準名 | 説明 | 主な対象 |
|---|---|---|
| AWS基礎セキュリティベストプラクティス | AWSが定義したセキュリティベストプラクティス | すべての組織 |
| CIS AWS Foundations Benchmark | Center for Internet Securityの推奨設定 | 一般的なセキュリティ要件 |
| PCI DSS | クレジットカード業界のデータセキュリティ標準 | カード情報を扱う組織 |
| NIST SP 800-53 | 米国政府のセキュリティ管理フレームワーク | 政府機関・規制業界 |
AWS基礎セキュリティベストプラクティス
AWS Foundational Security Best Practices(FSBP)は、AWSが定義したセキュリティベストプラクティスの集合です。200以上のコントロールが含まれ、最も包括的な標準です。
flowchart TB
subgraph "AWS基礎セキュリティベストプラクティス"
direction LR
subgraph "カテゴリ"
CAT1[アイデンティティと<br/>アクセス管理]
CAT2[ログ記録と<br/>モニタリング]
CAT3[ネットワーク<br/>セキュリティ]
CAT4[データ保護]
CAT5[脆弱性管理]
end
end
subgraph "対象サービス例"
IAM[IAM]
CT[CloudTrail]
VPC[VPC]
S3[S3]
EC2[EC2]
RDS[RDS]
LAMBDA[Lambda]
end
CAT1 --> IAM
CAT2 --> CT
CAT3 --> VPC
CAT4 --> S3
CAT5 --> EC2主要なコントロール例
| コントロールID | 内容 | 重要度 |
|---|---|---|
| IAM.1 | IAMポリシーが管理者アクセスを許可していないこと | HIGH |
| IAM.4 | IAMルートユーザーにアクセスキーが存在しないこと | CRITICAL |
| S3.1 | S3バケットでパブリックアクセスがブロックされていること | CRITICAL |
| EC2.19 | セキュリティグループが無制限のインバウンドを許可していないこと | HIGH |
| RDS.3 | RDSインスタンスで保管時の暗号化が有効であること | MEDIUM |
CIS AWS Foundations Benchmark
CIS(Center for Internet Security)が策定したAWS環境のセキュリティ推奨設定です。監査可能で実装しやすいコントロールが特徴です。
flowchart TB
subgraph "CIS AWS Foundations Benchmark v3.0"
subgraph "セクション1: IAM"
CIS1[1.1 ルートアカウントの<br/>ハードウェアMFA]
CIS2[1.4 アクセスキーの<br/>90日ローテーション]
CIS3[1.5 IAMパスワード<br/>ポリシーの要件]
end
subgraph "セクション2: ストレージ"
CIS4[2.1.1 S3バケットの<br/>パブリックアクセス禁止]
CIS5[2.1.2 S3バケットの<br/>暗号化有効化]
end
subgraph "セクション3: ログ記録"
CIS6[3.1 CloudTrailの<br/>全リージョン有効化]
CIS7[3.4 CloudTrailログの<br/>整合性検証]
end
subgraph "セクション4: モニタリング"
CIS8[4.1 不正APIコールの<br/>アラーム設定]
end
endPCI DSS
Payment Card Industry Data Security Standard(PCI DSS)は、クレジットカード情報を取り扱う組織向けのセキュリティ標準です。
| 要件番号 | 要件内容 | Security Hubでの対応 |
|---|---|---|
| 要件1 | ファイアウォールの設置・管理 | セキュリティグループ、NACLの設定チェック |
| 要件2 | ベンダーデフォルト値の変更 | デフォルトVPC、セキュリティグループのチェック |
| 要件3 | 保存データの保護 | 暗号化設定のチェック |
| 要件7 | アクセス制限 | IAM設定のチェック |
| 要件10 | アクセスの追跡・監視 | CloudTrail、CloudWatch設定のチェック |
セキュリティ標準の有効化
特定のセキュリティ標準を有効化するには、以下のコマンドを使用します。
|
|
検出結果の管理と優先順位付け
Security Hubに集約された検出結果を効率的に管理し、適切な優先順位で対応することがセキュリティ運用の鍵です。
検出結果の重要度レベル
Security Hubの検出結果は、以下の5段階の重要度で分類されます。
flowchart LR
subgraph "重要度レベル"
CRIT[CRITICAL<br/>90-100]
HIGH[HIGH<br/>70-89]
MED[MEDIUM<br/>40-69]
LOW[LOW<br/>1-39]
INFO[INFORMATIONAL<br/>0]
end
CRIT --> |即座に対応| A1[セキュリティ侵害の<br/>可能性が高い]
HIGH --> |24時間以内| A2[重大なセキュリティ<br/>リスク]
MED --> |1週間以内| A3[改善が必要な<br/>設定不備]
LOW --> |計画的に| A4[ベストプラクティスとの<br/>軽微な乖離]
INFO --> |参考情報| A5[情報提供のみ]| 重要度 | スコア範囲 | 対応目安 | 例 |
|---|---|---|---|
| CRITICAL | 90-100 | 即座に対応 | ルートアカウントのアクセスキー存在 |
| HIGH | 70-89 | 24時間以内 | セキュリティグループの0.0.0.0/0許可 |
| MEDIUM | 40-69 | 1週間以内 | S3バケットのバージョニング未設定 |
| LOW | 1-39 | 計画的に | タグ付けの不備 |
| INFORMATIONAL | 0 | 参考情報 | 正常な検出結果 |
検出結果のワークフロー状態
検出結果には、対応状況を示すワークフロー状態を設定できます。
stateDiagram-v2
[*] --> NEW: 検出
NEW --> NOTIFIED: 通知済み
NOTIFIED --> SUPPRESSED: 抑制
NOTIFIED --> RESOLVED: 解決済み
NEW --> SUPPRESSED: 誤検知/対象外
SUPPRESSED --> NEW: 抑制解除
RESOLVED --> [*]| ステータス | 説明 | ユースケース |
|---|---|---|
| NEW | 新規検出、未対応 | 初期状態 |
| NOTIFIED | 担当者に通知済み | 調査中 |
| SUPPRESSED | 抑制済み | 誤検知、許容リスク |
| RESOLVED | 解決済み | 修正完了 |
インサイトによる分析
Security Hubのインサイト機能を使用すると、検出結果をグループ化して傾向を分析できます。
|
|
組み込みインサイトの例
| インサイト名 | 分析内容 |
|---|---|
| AWS accounts with the most findings | アカウント別の検出結果数 |
| S3 buckets with public read access | パブリック読み取りアクセスのS3バケット |
| EC2 instances with public IP addresses | パブリックIPを持つEC2インスタンス |
| IAM users with suspicious activity | 疑わしいアクティビティのあるIAMユーザー |
自動対応ワークフローの構築
Security Hubの検出結果に対して、EventBridgeとLambdaを組み合わせた自動対応ワークフローを構築できます。
自動対応アーキテクチャ
flowchart LR
subgraph "検出"
SH[Security Hub]
end
subgraph "イベント処理"
EB[EventBridge]
RULE[ルール<br/>フィルタリング]
end
subgraph "自動対応"
LAMBDA[Lambda<br/>修復処理]
SNS[SNS<br/>通知]
SSM[Systems Manager<br/>Automation]
end
subgraph "対象リソース"
SG[セキュリティグループ]
S3[S3バケット]
IAM[IAMユーザー]
end
SH --> EB
EB --> RULE
RULE --> LAMBDA
RULE --> SNS
RULE --> SSM
LAMBDA --> SG
LAMBDA --> S3
SSM --> IAMEventBridgeルールの作成
Security Hubの検出結果をトリガーにするEventBridgeルールを作成します。
|
|
自動修復Lambda関数の例
セキュリティグループの無制限インバウンドルールを自動削除するLambda関数の例です。
|
|
通知ワークフローの設定
重要な検出結果を適切なチームに通知するワークフローを構築します。
flowchart TB
subgraph "Security Hub"
FINDING[検出結果]
end
subgraph "EventBridge"
RULE_CRIT[CRITICALルール]
RULE_HIGH[HIGHルール]
RULE_OTHER[その他ルール]
end
subgraph "通知先"
SNS_SEC[セキュリティチーム<br/>Slack/PagerDuty]
SNS_OPS[運用チーム<br/>メール/Slack]
SNS_DEV[開発チーム<br/>Slack]
end
FINDING --> RULE_CRIT
FINDING --> RULE_HIGH
FINDING --> RULE_OTHER
RULE_CRIT --> SNS_SEC
RULE_HIGH --> SNS_OPS
RULE_OTHER --> SNS_DEVOrganizations全体のセキュリティ可視化
マルチアカウント環境では、組織全体のセキュリティ状態を俯瞰的に把握することが重要です。Security Hubの委任管理者機能とダッシュボードを活用して、効果的な可視化を実現します。
セキュリティスコアの活用
Security Hubは、有効化されたセキュリティ標準に対するコンプライアンス率をセキュリティスコアとして表示します。
flowchart TB
subgraph "組織全体のセキュリティスコア"
OVERALL[全体スコア: 78%]
subgraph "標準別スコア"
FSBP[AWS基礎ベストプラクティス: 82%]
CIS[CIS Benchmark: 75%]
PCI[PCI DSS: 71%]
end
subgraph "アカウント別スコア"
PROD[本番アカウント: 85%]
DEV[開発アカウント: 72%]
SANDBOX[サンドボックス: 65%]
end
endダッシュボードによる可視化
Security Hubのコンソールダッシュボードでは、以下の情報を確認できます。
| ダッシュボード項目 | 表示内容 |
|---|---|
| セキュリティスコア | 各標準のコンプライアンス率 |
| 検出結果の概要 | 重要度別の検出結果数 |
| 最もコントロール違反の多いリソース | 問題のあるリソースの特定 |
| 傾向グラフ | 時系列での検出結果推移 |
クロスアカウントの検出結果集約
委任管理者アカウントでは、メンバーアカウントの検出結果を集約して表示できます。
|
|
CloudWatchダッシュボードとの統合
Security Hubのメトリクスを使用して、CloudWatchで詳細なダッシュボードを作成できます。
flowchart TB
subgraph "CloudWatch Dashboard"
subgraph "検出結果メトリクス"
M1[CRITICAL検出結果数の推移]
M2[アカウント別検出結果分布]
M3[標準別コンプライアンス率]
end
subgraph "運用メトリクス"
M4[平均解決時間MTTR]
M5[自動修復成功率]
M6[抑制された検出結果数]
end
end実践的な運用パターン
Security Hubを効果的に運用するためのベストプラクティスを解説します。
段階的な導入アプローチ
組織全体にSecurity Hubを導入する際は、段階的なアプローチを推奨します。
flowchart LR
subgraph "Phase 1: パイロット"
P1[監査アカウントで<br/>Security Hub有効化]
P2[基本標準の有効化<br/>FSBP]
P3[検出結果の<br/>ベースライン確認]
end
subgraph "Phase 2: 展開"
P4[本番アカウントへ<br/>展開]
P5[追加標準の有効化<br/>CIS/PCI DSS]
P6[通知ワークフロー<br/>構築]
end
subgraph "Phase 3: 最適化"
P7[全アカウントへ<br/>展開]
P8[自動修復の<br/>実装]
P9[継続的な<br/>改善]
end
P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7 --> P8 --> P9ノイズ削減のベストプラクティス
大規模環境では、検出結果のノイズを削減し、重要なアラートに集中することが重要です。
| 対策 | 実装方法 | 効果 |
|---|---|---|
| 不要なコントロールの無効化 | 組織で採用していないサービスのコントロールを無効化 | 誤検知の削減 |
| 抑制ルールの設定 | 許容されたリスクに対する自動抑制 | アラート疲れの防止 |
| カスタムインサイトの活用 | 重要な検出結果のみをフィルタリング | 優先度付けの効率化 |
| 自動対応の実装 | 定型的な問題の自動修復 | 運用負荷の軽減 |
コンプライアンスレポートの生成
監査対応のために、Security Hubの検出結果をレポートとして出力できます。
|
|
運用チェックリスト
日常的なSecurity Hub運用のチェックリストです。
| 頻度 | タスク | 担当 |
|---|---|---|
| 毎日 | CRITICAL/HIGH検出結果の確認 | セキュリティチーム |
| 週次 | セキュリティスコアの確認 | セキュリティチーム |
| 週次 | 新規検出結果のトリアージ | 開発チーム |
| 月次 | 抑制ルールの見直し | セキュリティチーム |
| 月次 | コンプライアンスレポートの生成 | コンプライアンス担当 |
| 四半期 | セキュリティ標準の有効化状況見直し | セキュリティリーダー |
まとめ
本記事では、AWS Security HubとControl Towerの連携による統合セキュリティ監視について解説しました。
学習したポイント
- Security Hubの役割: 複数のセキュリティサービスからの検出結果を集約し、一元的なセキュリティ管理を実現
- セキュリティ標準: AWS基礎ベストプラクティス、CIS、PCI DSSなどの業界標準に基づく継続的なコンプライアンスチェック
- Control Towerとの連携: 監査アカウントを委任管理者として組織全体の検出結果を集約
- 自動対応ワークフロー: EventBridgeとLambdaを組み合わせた検出結果への自動修復
- 組織全体の可視化: セキュリティスコアとダッシュボードによる俯瞰的な把握
Security Hubは、マルチアカウント環境のセキュリティ運用に欠かせないサービスです。Control Towerのガードレールと組み合わせることで、予防的・検出的コントロールの両面から組織のセキュリティを強化できます。
次回は、AWS Control Towerを活用したコンプライアンス対応の実践について、具体的な監査対応やログ集約の方法を解説します。