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 --> SIEM

Control 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 -->|ログ送信| LOG

Security Hubの有効化手順

Control Tower環境でSecurity Hubを組織全体に展開する手順を解説します。

手順1: 監査アカウントでSecurity Hubを有効化

監査アカウントにサインインし、Security Hubを有効化します。

1
2
3
4
# AWS CLIでSecurity Hubを有効化
aws securityhub enable-security-hub \
    --enable-default-standards \
    --control-finding-generator SECURITY_CONTROL

手順2: 組織の委任管理者として登録

管理アカウントから監査アカウントを委任管理者として登録します。

1
2
3
# 管理アカウントで実行
aws securityhub enable-organization-admin-account \
    --admin-account-id 123456789012

手順3: メンバーアカウントの自動有効化設定

新規アカウントで自動的にSecurity Hubが有効化されるよう設定します。

1
2
3
4
# 委任管理者アカウントで実行
aws securityhub update-organization-configuration \
    --auto-enable \
    --auto-enable-standards DEFAULT

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
    end

PCI DSS

Payment Card Industry Data Security Standard(PCI DSS)は、クレジットカード情報を取り扱う組織向けのセキュリティ標準です。

要件番号 要件内容 Security Hubでの対応
要件1 ファイアウォールの設置・管理 セキュリティグループ、NACLの設定チェック
要件2 ベンダーデフォルト値の変更 デフォルトVPC、セキュリティグループのチェック
要件3 保存データの保護 暗号化設定のチェック
要件7 アクセス制限 IAM設定のチェック
要件10 アクセスの追跡・監視 CloudTrail、CloudWatch設定のチェック

セキュリティ標準の有効化

特定のセキュリティ標準を有効化するには、以下のコマンドを使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# AWS基礎セキュリティベストプラクティスの有効化
aws securityhub batch-enable-standards \
    --standards-subscription-requests \
    StandardsArn=arn:aws:securityhub:ap-northeast-1::standards/aws-foundational-security-best-practices/v/1.0.0

# CIS AWS Foundations Benchmark v3.0の有効化
aws securityhub batch-enable-standards \
    --standards-subscription-requests \
    StandardsArn=arn:aws:securityhub:ap-northeast-1::standards/cis-aws-foundations-benchmark/v/3.0.0

# 特定のコントロールを無効化(誤検知や対象外の場合)
aws securityhub update-standards-control \
    --standards-control-arn "arn:aws:securityhub:ap-northeast-1:123456789012:control/aws-foundational-security-best-practices/v/1.0.0/IAM.6" \
    --control-status DISABLED \
    --disabled-reason "別のID管理ソリューションを使用"

検出結果の管理と優先順位付け

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のインサイト機能を使用すると、検出結果をグループ化して傾向を分析できます。

1
2
3
4
5
# カスタムインサイトの作成例:リソースタイプ別の検出結果数
aws securityhub create-insight \
    --name "リソースタイプ別CRITICAL検出結果" \
    --filters '{"SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}]}' \
    --group-by-attribute "ResourceType"

組み込みインサイトの例

インサイト名 分析内容
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 --> IAM

EventBridgeルールの作成

Security Hubの検出結果をトリガーにするEventBridgeルールを作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {
        "Label": ["CRITICAL", "HIGH"]
      },
      "Workflow": {
        "Status": ["NEW"]
      },
      "RecordState": ["ACTIVE"]
    }
  }
}

自動修復Lambda関数の例

セキュリティグループの無制限インバウンドルールを自動削除するLambda関数の例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
import boto3
import json

def lambda_handler(event, context):
    """
    Security Hubの検出結果を受け取り、
    セキュリティグループの0.0.0.0/0ルールを削除する
    """
    ec2 = boto3.client('ec2')
    securityhub = boto3.client('securityhub')
    
    for finding in event['detail']['findings']:
        # 対象のコントロールIDを確認
        if 'EC2.19' not in finding.get('GeneratorId', ''):
            continue
        
        # リソース情報を取得
        for resource in finding.get('Resources', []):
            if resource['Type'] != 'AwsEc2SecurityGroup':
                continue
            
            sg_id = resource['Id'].split('/')[-1]
            
            try:
                # セキュリティグループのルールを取得
                response = ec2.describe_security_groups(
                    GroupIds=[sg_id]
                )
                
                for sg in response['SecurityGroups']:
                    for rule in sg.get('IpPermissions', []):
                        for ip_range in rule.get('IpRanges', []):
                            if ip_range.get('CidrIp') == '0.0.0.0/0':
                                # 無制限ルールを削除
                                ec2.revoke_security_group_ingress(
                                    GroupId=sg_id,
                                    IpPermissions=[rule]
                                )
                                print(f"Removed 0.0.0.0/0 rule from {sg_id}")
                
                # 検出結果のステータスを更新
                securityhub.batch_update_findings(
                    FindingIdentifiers=[{
                        'Id': finding['Id'],
                        'ProductArn': finding['ProductArn']
                    }],
                    Workflow={'Status': 'RESOLVED'},
                    Note={
                        'Text': 'Auto-remediated by Lambda function',
                        'UpdatedBy': 'SecurityHubAutoRemediation'
                    }
                )
                
            except Exception as e:
                print(f"Error processing {sg_id}: {str(e)}")
                raise
    
    return {
        'statusCode': 200,
        'body': json.dumps('Processing complete')
    }

通知ワークフローの設定

重要な検出結果を適切なチームに通知するワークフローを構築します。

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_DEV

Organizations全体のセキュリティ可視化

マルチアカウント環境では、組織全体のセキュリティ状態を俯瞰的に把握することが重要です。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のコンソールダッシュボードでは、以下の情報を確認できます。

ダッシュボード項目 表示内容
セキュリティスコア 各標準のコンプライアンス率
検出結果の概要 重要度別の検出結果数
最もコントロール違反の多いリソース 問題のあるリソースの特定
傾向グラフ 時系列での検出結果推移

クロスアカウントの検出結果集約

委任管理者アカウントでは、メンバーアカウントの検出結果を集約して表示できます。

1
2
3
4
5
# メンバーアカウントの検出結果を取得
aws securityhub get-findings \
    --filters '{"AwsAccountId": [{"Value": "111111111111", "Comparison": "EQUALS"}]}' \
    --sort-criteria '{"Field": "SeverityNormalized", "SortOrder": "desc"}' \
    --max-items 20

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の検出結果をレポートとして出力できます。

1
2
3
4
5
# 検出結果をS3にエクスポート
aws securityhub get-findings \
    --filters '{"RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]}' \
    --query 'Findings[*].{Id:Id,Title:Title,Severity:Severity.Label,Resource:Resources[0].Id,Status:Workflow.Status}' \
    --output json > security_findings_report.json

運用チェックリスト

日常的なSecurity Hub運用のチェックリストです。

頻度 タスク 担当
毎日 CRITICAL/HIGH検出結果の確認 セキュリティチーム
週次 セキュリティスコアの確認 セキュリティチーム
週次 新規検出結果のトリアージ 開発チーム
月次 抑制ルールの見直し セキュリティチーム
月次 コンプライアンスレポートの生成 コンプライアンス担当
四半期 セキュリティ標準の有効化状況見直し セキュリティリーダー

まとめ

本記事では、AWS Security HubとControl Towerの連携による統合セキュリティ監視について解説しました。

学習したポイント

  1. Security Hubの役割: 複数のセキュリティサービスからの検出結果を集約し、一元的なセキュリティ管理を実現
  2. セキュリティ標準: AWS基礎ベストプラクティス、CIS、PCI DSSなどの業界標準に基づく継続的なコンプライアンスチェック
  3. Control Towerとの連携: 監査アカウントを委任管理者として組織全体の検出結果を集約
  4. 自動対応ワークフロー: EventBridgeとLambdaを組み合わせた検出結果への自動修復
  5. 組織全体の可視化: セキュリティスコアとダッシュボードによる俯瞰的な把握

Security Hubは、マルチアカウント環境のセキュリティ運用に欠かせないサービスです。Control Towerのガードレールと組み合わせることで、予防的・検出的コントロールの両面から組織のセキュリティを強化できます。

次回は、AWS Control Towerを活用したコンプライアンス対応の実践について、具体的な監査対応やログ集約の方法を解説します。

参考リンク