AWS Security Hub CSPM 完全ガイド v2.0

初心者から実務者向けの包括的解説

AWS Security Hub CSPM（Cloud Security Posture Management） は、複数の AWS セキュリティサービス（GuardDuty・Inspector・Macie・IAM Access Analyzer）と外部ツール（Splunk・Palo Alto・CrowdStrike）の検出結果を集約し、ASFF（Amazon Security Findings Format）で標準化して、セキュリティ状況を一元管理するサービスです。PCI DSS・CIS AWS Foundations・AWS Foundational Security Best Practices・NIST 800-53 などのセキュリティ標準に対するコントロール自動チェック、セキュリティスコア（0-100%）の算出、Organizations マルチアカウント管理、EventBridge 統合による自動修復をサポートします。クラウドセキュリティポスチャー管理の最強の統合プラットフォームです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： Security Hub とは何か、CSPM とは何かを学びたい方
セキュリティエンジニア向け： Finding 統合・Automation Rule・Custom Insight の運用
コンプライアンス担当向け： PCI DSS・CIS・NIST コンプライアンス自動評価・監査レポート
CISO / セキュリティリーダー向け： 組織全体のセキュリティスコア・リスク可視化・KPI 管理
意思決思者向け： Wiz・Prisma Cloud・Lacework・Orca との比較・投資判断

2026 年の Security Hub CSPM エコシステム

Automation Rules の高度化： AI 駆動の自動分類・優先付け・自動修復
Security Lake 統合： 中央集約ログリポジトリとの連携
クロスリージョン集約の強化： マルチリージョン環境での統一ダッシュボード
サードパーティ統合の拡大： 100+ パートナー製品との ASFF ネイティブ統合
AI / 機械学習による異常検知： セキュリティ脅威の予測的検知
DevSecOps パイプライン統合： CI/CD 段階での自動コンプライアンス評価

定義

AWS 公式による定義：

“AWS Security Hub Cloud Security Posture Management provides you with a comprehensive view of your security state in AWS and helps you assess your AWS environment against security industry standards and best practices.”

Security Hub CSPM は AWS 全体のセキュリティポスチャー統合管理プラットフォーム です。

概要
Security Hub CSPM が解決する課題
主な特徴
アーキテクチャ
Finding 統合・ASFF
セキュリティ標準（Standards）
セキュリティコントロール（Controls）
セキュリティスコア
Insights（カスタム検索）
Automation Rules（自動対応）
Custom Actions（カスタムアクション）
Organizations 統合・委任管理者
クロスリージョン集約
EventBridge 連携
Security Lake 統合
他の類似ツールとの比較
クライアント・エコシステム
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例・活用シーン
導入ロードマップ
実装チェックリスト
まとめ
参考文献

概要

初心者向けメモ： Security Hub CSPM は「複数のセキュリティサービス（GuardDuty・Macie・Inspector など）の検出結果を一つのダッシュボードに集約して、セキュリティ状況を『見える化』するサービス」です。各サービスのコンソールを行き来する必要なく、Security Hub で全てを確認・対応できます。さらに、PCI DSS などの規制に対して「あなたの AWS はどこまで準拠しているか」を自動スコアリングしてくれます。

Security Hub CSPM は以下を実現します。

機能	説明
Finding 統合	GuardDuty・Macie・Inspector・IAM Access Analyzer の検出結果を ASFF で標準化
セキュリティ標準	PCI DSS・CIS・AWS Foundational Security Best Practices・NIST での自動コンプライアンスチェック
セキュリティスコア	0-100% の統合スコア（PASSED 率）でセキュリティ状況を可視化
Insights	Finding をカスタム検索・フィルタリングして優先順位付け
Automation Rule	Finding を条件ベースで自動更新・suppress・ルーティング
Custom Action	EventBridge トリガーで Lambda・SNS・Jira を自動実行
Organizations 統合	複数アカウント・複数リージョンを委任管理者で一元監視
クロスリージョン集約	複数リージョンのセキュリティ状況を単一ダッシュボードで表示
EventBridge 連携	検出結果を他の AWS サービスで自動処理・通知
コンプライアンスレポート	PCI DSS・NIST のコンプライアンスレポート自動生成

Security Hub CSPM が解決する課題

1. セキュリティ検出結果の分散・管理困難性

課題： GuardDuty は GuardDuty コンソール、Macie は Macie コンソール、Inspector は Inspector コンソール…各サービスのコンソールを行き来。全体的なセキュリティ状況の把握が困難。優先順位の判断も複雑。

Security Hub の解決：

全検出結果 → Security Hub に集約（ASFF 標準化）
→ 単一ダッシュボードで「Critical 検出件数 42 件」等を一目で確認
→ 重大度でソート・優先付け可能

2. コンプライアンス監査の手動工数

課題： PCI DSS・CIS 監査で「あなたは 150 のコントロール中、何個準拠しているか」を手動確認。膨大な工数・見落としリスク。

Security Hub の解決：

150 のコントロール → 自動スキャン・評価
→ セキュリティスコア「72/100」を算出
→ 不準拠コントロール 42 個をリスト
→ PCI DSS 監査に提出可能なレポート自動生成

3. マルチアカウント環境でのセキュリティ管理の複雑性

課題： 50 アカウント環境で各アカウントのセキュリティ状況を個別に確認。集約ビューなし。

Security Hub の解決：

委任管理者（Security Account）で一元管理
→ 全 50 アカウントのセキュリティスコアを一覧表示
→ アカウント別・重大度別に Finding を検索
→ 「prod アカウントの CRITICAL 件数：3 件」を即座に把握

4. セキュリティ対応の MTTR（Mean Time To Remediate）が長い

課題： Finding を見つけても、手動でログに調査・手動で修復。数日かかることも。

Security Hub の解決：

Finding 検出 → Automation Rule で自動ルーティング
→ EventBridge → Lambda で自動修復
→ SNS・Slack・Jira で自動通知
→ MTTR 数時間→数分に短縮

主な特徴

1. Finding 統合（ASFF 標準化）

検出ソース：
  ├── GuardDuty（脅威検出）
  ├── Macie（機密データ）
  ├── Inspector（脆弱性）
  ├── IAM Access Analyzer（外部アクセス）
  ├── AWS Firewall Manager（WAF・Network ACL）
  ├── AWS Config（構成変更）
  └── サードパーティ（Splunk・CrowdStrike等）
  
  ↓ ASFF 標準化

Security Hub
  ├── Finding 統合ビュー
  ├── 重大度でソート
  ├── タイプで分類
  └── オープン・クローズド状態管理

2. セキュリティ標準（Standards）

| 標準 | 対象 | コントロール数 |
|------|------|----------|
| AWS Foundational Security Best Practices（FSBP） | AWS 推奨設定 | 200+ |
| CIS AWS Foundations Benchmark | CIS による標準 | 150+ |
| PCI DSS v3.2.1 | クレジットカード業界 | 127 |
| NIST SP 800-53 | 米国政府標準 | 900+ |
| ISO 27001:2013 | 国際標準 | 233 |

各標準：複数のコントロール（チェック項目） で構成
  → Security Hub が自動スキャン・評価

3. セキュリティスコア

セキュリティスコア = PASSED コントロール率（%）

例：
  有効コントロール：150
  PASSED：108
  FAILED：42
  → スコア：72%
  
ダッシュボード表示：
  ┌─────────────────────┐
  │  セキュリティスコア  │
  │      72 / 100       │
  │                     │
  │  ━━━━━━━━━━━──────  │
  │  PASSED：108        │
  │  FAILED：42         │
  └─────────────────────┘

4. Automation Rules

条件ベースで Finding を自動処理：

Rule 1：低優先度は自動 suppress
  条件：
    - Type = "Software and Configuration Checks/AWS Security Best Practices"
    - Severity = "LOW"
  アクション：
    - Status = SUPPRESSED
    - Note = "Low priority, suppressed automatically"

Rule 2：Critical は即座に通知
  条件：
    - Severity = "CRITICAL"
  アクション：
    - SendNotification（SNS）
    - CreateTicket（Jira）
    - UpdateFindingStatus = NOTIFIED

Rule 3：S3 バケット検出は自動修復
  条件：
    - Type = "Policy:IAMUser/S3BlockPublicAccessDisabled"
  アクション：
    - UpdateFindingStatus = REMEDIATED
    - PublishToEventBridge（Lambda 実行）

アーキテクチャ

graph TB
    Sources["Security Sources"]
    GD["GuardDuty"]
    MC["Macie"]
    IN["Inspector"]
    AA["IAM Access Analyzer"]
    CFM["Config & Firewall Manager"]
    TP["Third-party Tools"]
    
    Sources --> GD
    Sources --> MC
    Sources --> IN
    Sources --> AA
    Sources --> CFM
    Sources --> TP
    
    GD -->|ASFF| Hub["Security Hub CSPM"]
    MC -->|ASFF| Hub
    IN -->|ASFF| Hub
    AA -->|ASFF| Hub
    CFM -->|ASFF| Hub
    TP -->|ASFF| Hub
    
    Hub -->|Findings Database| Agg["Aggregation<br/>Region"]
    Hub -->|Dashboard| Dashboard["Security Dashboard"]
    Hub -->|Standards| Standards["CSPM Standards<br/>Evaluation"]
    
    Dashboard --> Insights["Insights<br/>カスタム検索"]
    Standards --> Score["Security Score<br/>0-100%"]
    
    Hub -->|Automation Rules| Rules["Automation Rules<br/>自動対応"]
    Rules --> EB["EventBridge"]
    EB --> Lambda["Lambda"]
    EB --> SNS["SNS"]
    EB --> SH["Systems Manager"]
    
    Hub -->|Organizations| Orgs["Organizations<br/>Aggregation"]
    
    style Hub fill:#fff3e0
    style Dashboard fill:#f3e5f5
    style Score fill:#e8f5e9
    style Orgs fill:#fce4ec

Finding 統合・ASFF

ASFF（Amazon Security Findings Format）

{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:securityhub:us-east-1:123456789012:finding/guardduty/finding-id",
  "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/guardduty",
  "GeneratorId": "arn:aws:guardduty:us-east-1:123456789012:detector/abc123",
  "AwsAccountId": "123456789012",
  "Region": "us-east-1",
  "Types": [
    "TTPs/DefenseEvasion/AWS-GuardDuty"
  ],
  "CreatedAt": "2026-04-26T10:15:00.000Z",
  "UpdatedAt": "2026-04-26T10:15:00.000Z",
  "Severity": {
    "Label": "HIGH",
    "Normalized": 70
  },
  "Title": "Suspicious EC2 instance activity detected",
  "Description": "EC2 instance i-abc123 detected communicating with suspicious IP",
  "Resources": [
    {
      "Type": "AwsEc2Instance",
      "Id": "arn:aws:ec2:us-east-1:123456789012:instance/i-abc123",
      "Partition": "aws",
      "Region": "us-east-1"
    }
  ],
  "Compliance": {
    "Status": "FAILED",
    "RelatedRequirements": [
      "PCI-DSS.4.1"
    ]
  },
  "Workflow": {
    "Status": "NEW"
  }
}

セキュリティ標準（Standards）

AWS Foundational Security Best Practices（FSBP）

IAM Controls：
  - Ensure IAM policies do not allow full "*" administrative privileges
  - Require MFA enabled for IAM users
  - Require password policy with minimum 14 characters

Networking Controls：
  - Ensure VPC Flow Logs is enabled
  - Ensure default security group denies all inbound traffic
  - Ensure security group rules restrict traffic appropriately

Storage Controls：
  - Ensure S3 Block Public Access is enabled
  - Ensure S3 buckets have encryption enabled
  - Ensure S3 MFA Delete is enabled

Logging Controls：
  - Ensure CloudTrail is enabled
  - Ensure CloudTrail Log File Validation is enabled

200+ コントロール → Security Hub が自動評価

セキュリティコントロール（Controls）

Control の評価フロー

Control：「S3.8 - S3 buckets should have block public access enabled」
  ├── 評価対象：全 S3 バケット
  ├── チェック方法：AWS Config rule を自動実行
  ├── 評価結果：
  │   ├── PASSED：Block Public Access = true（450 個バケット）
  │   ├── FAILED：Block Public Access = false（12 個バケット）
  │   └── 重大度：HIGH
  │
  ├── Compliance Requirement：
  │   ├── PCI DSS 2.2.4
  │   ├── CIS 1.19
  │   └── NIST 800-53 AC-3
  │
  └── Remediation：
      ├── 推奨アクション：PutPublicAccessBlockConfiguration
      ├── AWS CLI：aws s3api put-public-access-block --bucket xxx
      └── 自動化：Automation Rule → Lambda 実行

セキュリティスコア

スコア計算ロジック

セキュリティスコア（0-100%） = PASSED コントロール / 有効コントロール × 100

例：
  標準：PCI DSS
  対象コントロール：127
  
  PASSED：95 個
  FAILED：32 個
  UNKNOWN：0 個
  
  スコア = 95 / 127 × 100 = 74.8%

ダッシュボード表示

┌──────────────────────────────────────────┐
│ Security Hub CSPM Dashboard              │
├──────────────────────────────────────────┤
│                                          │
│  Overall Security Score：74%             │
│  ━━━━━━━━━━━━━━━━━━━━━━━━━─────         │
│                                          │
│  Standards Compliance：                 │
│  ├─ AWS Foundational SBP：68%           │
│  ├─ CIS Foundations：72%                │
│  ├─ PCI DSS：74%                        │
│  └─ NIST 800-53：71%                    │
│                                          │
│  Finding Summary：                       │
│  ├─ CRITICAL：8                         │
│  ├─ HIGH：42                            │
│  ├─ MEDIUM：156                         │
│  └─ LOW：312                            │
│                                          │
└──────────────────────────────────────────┘

Insights（カスタム検索）

Insight の例

# Insight 1：Critical 検出が多いアカウント
Name: "High-Risk Accounts"
Filters:
  - Severity.Label = CRITICAL
  - RecordState = ACTIVE

# Insight 2：最近修復されていない Finding
Name: "Unresolved High-Severity Issues"
Filters:
  - Severity.Normalized >= 70
  - Workflow.Status = NEW
  - UpdatedAt >= 30 days ago

# Insight 3：特定の CIS コントロール違反
Name: "CIS 1.x IAM Violations"
Filters:
  - Compliance.RelatedRequirements = "CIS.1.*"
  - Compliance.Status = FAILED

結果：マトリックスで表示
  ├─ Account ID 別に違反数を表示
  ├─ Region 別に違反数を表示
  └─ Resource Type 別に違反数を表示

Automation Rules（自動対応）

Rule の実装例

# Rule 1：Config による構成漂流を自動 suppress
aws securityhub create-automation-rule \
  --name "suppress-config-configuration-drift" \
  --description "Suppress low-severity config drift findings" \
  --rule-order 10 \
  --rule-status ENABLED \
  --trigger-on FINDINGS_IMPORTED \
  --criteria '{
    "Type": [{
      "Value": "Software and Configuration Checks/AWS Config Configuration Item",
      "Comparison": "PREFIX"
    }],
    "Severity.Label": [{
      "Value": "LOW",
      "Comparison": "EQUALS"
    }]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdateAction": {
      "Workflow": {
        "Status": "SUPPRESSED"
      },
      "Note": {
        "Text": "Low-severity config drift, suppressed automatically",
        "UpdatedBy": "AutomationRule"
      }
    }
  }]'

# Rule 2：EC2 セキュリティグループ違反は自動修復
aws securityhub create-automation-rule \
  --name "auto-fix-sg-violations" \
  --description "Automatically remediate security group violations" \
  --rule-order 20 \
  --rule-status ENABLED \
  --trigger-on FINDINGS_IMPORTED \
  --criteria '{
    "Type": [{
      "Value": "TTPs/UnauthorizedAccess/EC2-UnauthorizedAccess",
      "Comparison": "PREFIX"
    }],
    "Severity.Label": [{
      "Value": "HIGH",
      "Comparison": "EQUALS"
    }]
  }' \
  --actions '[{
    "Type": "SEND_TO_EVENTBRIDGE"
  }]'

EventBridge ルール：
  → Lambda で security group を修復（0.0.0.0/0 削除等）
  → SNS で Slack に通知

Custom Actions（カスタムアクション）

Custom Action の例

# Custom Action 1：Jira チケット自動作成
aws securityhub create-custom-action-target \
  --name "Jira-Create-Ticket" \
  --description "Create Jira ticket for critical findings" \
  --custom-action-arn "arn:aws:securityhub:us-east-1:123456789012:custom-action/default/Jira-Create-Ticket"

EventBridge ルール：
  条件：Finding で Custom Action "Jira-Create-Ticket" をクリック
  → Lambda（Jira API 呼び出し）
  → Jira で自動チケット作成

Organizations 統合・委任管理者

マルチアカウント集約アーキテクチャ

Organization 管理アカウント
  ├── Security Hub 委任管理者を指定
  │   → セキュリティ専任アカウント（Security Account）
  │
  └── 全メンバーアカウント
      ├── Account A（dev）→ GuardDuty 有効化
      ├── Account B（stg）→ Macie 有効化
      ├── Account C（prod）→ Inspector 有効化
      └── Account D（log）→ CloudTrail 集約

委任管理者アカウント（Security Account）
  ├── Security Hub 有効化
  ├── 全メンバーアカウント の Finding を自動集約
  ├── 統一ダッシュボード
  │   ├── 全体セキュリティスコア
  │   ├── アカウント別 スコア
  │   ├── 重大度別 Finding 統計
  │   └── 標準別 コンプライアンス状況
  │
  ├── 一元的な対応
  │   ├── Automation Rule 設定
  │   ├── Custom Action 設定
  │   └── EventBridge 統合
  │
  └── コンプライアンスレポート
      ├── 月次：セキュリティスコア推移
      ├── 四半期：PCI DSS / NIST コンプライアンス
      └── 年次：セキュリティポスチャー監査

クロスリージョン集約

複数リージョン集約レジオン構成

アグリゲーション レジオン（us-east-1）
  ├── 自リージョン の Finding：すべて
  ├── リンクリージョン から集約
  │   ├── us-west-2：Finding 自動複製
  │   ├── eu-west-1：Finding 自動複製
  │   ├── ap-northeast-1：Finding 自動複製
  │   └── ap-southeast-1：Finding 自動複製
  │
  └── 統一ダッシュボール
      ├── 全リージョン の Finding 統計
      ├── リージョン別 セキュリティスコア
      ├── グローバル セキュリティ状況
      └── マルチリージョン コンプライアンスレポート

EventBridge 連携

Finding → 自動対応フロー

Security Hub Finding 生成
  ↓
EventBridge Event Route
  
Rule：「Critical S3 Finding」
  条件：
    {
      "source": ["aws.securityhub"],
      "detail-type": ["Security Hub Findings - Imported"],
      "detail": {
        "findings": {
          "Severity": {
            "Label": ["CRITICAL"]
          },
          "Types": [{
            "prefix": "Software and Configuration Checks/AWS Security Best Practices/S3"
          }]
        }
      }
    }
  
  アクション：
    ├─ Lambda：自動修復 S3 設定
    ├─ SNS：Slack 通知
    ├─ SQS：キュー登録（手動レビュー）
    └─ Systems Manager：Runbook 実行

Security Lake 統合

Security Lake との連携

Security Hub Finding
  ↓ ASFF 標準化
Security Lake（中央ログリポジトリ）
  ├── S3 に PARQUET 形式で格納
  ├── Athena で SQL クエリ可能
  └── QuickSight で可視化

Athena クエリ例：
  SELECT
    account_id,
    severity,
    COUNT(*) as finding_count
  FROM security_lake_findings
  WHERE severity IN ('HIGH', 'CRITICAL')
  GROUP BY account_id, severity
  ORDER BY finding_count DESC
  
結果：
  ├─ Account A：18 個 (CRITICAL), 45 個 (HIGH)
  ├─ Account B：3 個 (CRITICAL), 12 個 (HIGH)
  └─ Account C：0 個 (CRITICAL), 8 個 (HIGH)

他の類似ツールとの比較

サービス	特徴	統合範囲	コスト	推奨シーン
Security Hub CSPM	AWS native、統合集約、自動評価	AWS 15+ サービス	低~中	AWS multi-account
Wiz CSPM	マルチクラウド、高度な分析、AI 駆動	AWS/Azure/GCP	中~高	マルチクラウド
Prisma Cloud（Palo Alto）	エンタープライズ向け、IAM CSPM	AWS/Azure/GCP/K8s	高	大規模組織・IAM 重視
Lacework	ML 駆動異常検知、DevSecOps	AWS/Azure/GCP	中~高	DevSecOps・コンテナ環境
Orca Security	軽量・高速・リアルタイム	AWS/Azure/GCP	中	中規模組織・リアルタイム重視

AWS 環境での推奨：

AWS のみ → Security Hub CSPM （最高推奨）
AWS + Azure / GCP → Wiz または Prisma Cloud
エンタープライズ → Prisma Cloud + Security Hub CSPM（統合）
DevSecOps 重視 → Lacework + Security Hub CSPM

クライアント・エコシステム

AWS Management Console

Security Hub CSPM Dashboard
  ├── Overview（セキュリティスコア・Finding 統計）
  ├── Findings（検索・フィルタリング・対応）
  ├── Standards（コンプライアンス状況）
  ├── Insights（カスタム検索・マトリックス表示）
  ├── Automation Rules（自動対応設定）
  ├── Custom Actions（アクション管理）
  ├── Integrations（パートナー製品連携）
  └── Settings（標準・リージョン・委任管理者）

AWS CLI / SDKs

# Finding を取得
aws securityhub get-findings --filters '{
  "SeverityLabel": [{
    "Value": "CRITICAL",
    "Comparison": "EQUALS"
  }]
}'

# Insight を実行
aws securityhub get-insights --names "High-Risk-Accounts"

# Automation Rule を作成
aws securityhub create-automation-rule ...

IaC（Terraform / CloudFormation）

# Security Hub を有効化
resource "aws_securityhub_account" "example" {
  enable_default_standards = true
}

# セキュリティ標準を有効化
resource "aws_securityhub_standards_subscription" "pci_dss" {
  standards_arn = "arn:aws:securityhub:${var.aws_region}::standards/aws-foundational-security-best-practices/v/1.0.0"
}

# Automation Rule を作成
resource "aws_securityhub_automation_rule" "critical_findings" {
  rule_order = 10
  rule_status = "ENABLED"
  name = "suppress-low-severity"
  
  criteria {
    severity_label {
      value      = "LOW"
      comparison = "EQUALS"
    }
  }
  
  actions {
    finding_fields_update_action {
      workflow {
        status = "SUPPRESSED"
      }
    }
  }
}

ベストプラクティス

✅ 推奨パターン

Organization Instance での一元管理

委任管理者で全メンバーアカウント一元監視
→ セキュリティスコアの統一管理・トレンド追跡

すべてのセキュリティ標準を有効化

FSBP（最小限） + CIS + PCI DSS（if PCI）+ NIST（if 政府）
→ コンプライアンス要件の網羅的カバー

Automation Rule による優先付け・自動化

Critical → 即座に通知・自動修復
High → チケット自動作成
Medium / Low → 自動 suppress（手動レビュー対象外）

EventBridge + Lambda での自動修復

Policy Finding（設定ミス） → Lambda で自動修復
→ MTTR 大幅短縮

Security Lake での長期分析

Finding を Security Lake に格納
→ Athena で SQL クエリ・トレンド分析
→ QuickSight で可視化・経営報告

定期的なコンプライアンス監査

月次：Finding 統計・セキュリティスコア
四半期：PCI DSS / NIST コンプライアンスレポート
年次：セキュリティポスチャー監査

❌ アンチパターン

Security Hub 有効化だけで放置

❌ Finding が積み上がり、対応が後手に
✓ Automation Rule で自動対応

すべての Finding に対応（オーバーヘッド）

❌ Low Priority の Finding に時間浪費
✓ Automation Rule で重大度別に優先付け

Organizations 統合なし（各アカウント管理）

❌ 50 アカウント × 50 コンソール → 管理不可能
✓ 委任管理者で一元管理

EventBridge 自動化なし（手動対応）

❌ Finding を手動で確認・手動で修復
✓ Lambda で自動修復・SNS で通知

セキュリティレポートを作成しない

❌ セキュリティ状況が可視化されない
✓ 月次・四半期レポート自動生成

トラブルシューティング

問題	原因	解決方法
Finding が Security Hub に表示されない	GuardDuty・Macie が有効化されていない	各サービスをメンバーアカウントで有効化
セキュリティスコアが 0%	コントロール評価が実行されていない	標準を有効化・AWS Config ルール確認
Automation Rule が起動しない	Rule の条件が一致していない	Event pattern を検証・ログ確認
クロスリージョン集約が機能しない	他リージョンで Security Hub が有効化されていない	各リージョンで有効化・アグリゲーション設定
EventBridge が Finding を受け取らない	IAM 権限不足	EventBridge の IAM ロール確認

2025-2026 最新動向

1. AI / 機械学習による異常検知

検出結果の予測的分析が強化

CloudTrail ベースの異常なアクセスパターン自動検知
セキュリティスコアの自動予測・改善提案

2. DevSecOps パイプライン統合

CI/CD 段階でのセキュリティ自動評価

CodePipeline・CodeBuild との自動統合
Container Scan・SAST・DAST 結果の自動集約

3. Security Lake 本運用開始

中央ログリポジトリによる統一分析

Finding の長期保存・Athena による SQL クエリ
QuickSight での可視化・傾向分析

4. サードパーティ統合の拡大

100+ パートナー製品との ASFF ネイティブ統合

Splunk・Datadog・New Relic との統合深化

学習リソース

AWS 公式ドキュメント

Security Hub User Guide
- https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
Security Standards Reference
- https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference.html
Automation Rules
- https://docs.aws.amazon.com/securityhub/latest/userguide/automations.html

ベストプラクティス・ブログ

AWS Security Blog - Security Hub
AWS GitHub - Security Hub Best Practices
- https://aws.github.io/aws-security-services-best-practices/

実装例・活用シーン

（詳細は省略）

導入ロードマップ

Phase 1（0-1 ヶ月）

Security Hub 有効化
全セキュリティ標準を有効化
Organizations 委任管理者設定

Phase 2（1-3 ヶ月）

Automation Rule 作成
EventBridge・Lambda 統合
通知設定（SNS・Slack）

Phase 3（3-6 ヶ月）

Security Lake 統合
月次・四半期レポート自動生成
セキュリティスコア改善策実装

実装チェックリスト

[ ] Security Hub（Organization Instance）有効化
[ ] 全セキュリティ標準を有効化（FSBP・CIS・PCI・NIST）
[ ] Organizations 委任管理者設定完了
[ ] AWS Config が有効化・ルール実行中
[ ] GuardDuty・Macie・Inspector・IAM Access Analyzer 有効化
[ ] Automation Rule 3+ 個作成
[ ] EventBridge・Lambda 統合テスト完了
[ ] SNS・Slack 通知設定完了
[ ] 月次レポートテンプレート作成
[ ] セキュリティスコアダッシュボード確認

まとめ

Security Hub CSPM は AWS セキュリティの統合管理プラットフォーム です。

主要メリット

統合： 複数サービスの Finding を ASFF で統一管理
自動化： Automation Rule で優先付け・自動修復
コンプライアンス： PCI DSS・NIST 等を自動評価
マルチアカウント： Organizations で一元監視
可視化： セキュリティスコア・ダッシュボード

Security Hub CSPM 導入により、セキュリティ・コンプライアンス・運用効率を同時に最大化 できます。

参考文献

AWS 公式ドキュメント

ベストプラクティス

https://aws.github.io/aws-security-services-best-practices/guides/security-hub/
AWS Security Blog - Security Hub articles
AWS re:Invent sessions

最終更新：2026-04-26 バージョン：v2.0

目次

AWS Security Hub CSPM 完全ガイド v2.0

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の Security Hub CSPM エコシステム

定義

目次

概要

Security Hub CSPM が解決する課題

1. セキュリティ検出結果の分散・管理困難性

2. コンプライアンス監査の手動工数

3. マルチアカウント環境でのセキュリティ管理の複雑性

4. セキュリティ対応の MTTR（Mean Time To Remediate）が長い

主な特徴

1. Finding 統合（ASFF 標準化）

2. セキュリティ標準（Standards）

3. セキュリティスコア

4. Automation Rules

アーキテクチャ

Finding 統合・ASFF

ASFF（Amazon Security Findings Format）

セキュリティ標準（Standards）

AWS Foundational Security Best Practices（FSBP）

セキュリティコントロール（Controls）

Control の評価フロー

セキュリティスコア

スコア計算ロジック

ダッシュボード表示

Insights（カスタム検索）

Insight の例

Automation Rules（自動対応）

Rule の実装例

Custom Actions（カスタムアクション）

Custom Action の例

Organizations 統合・委任管理者

マルチアカウント集約アーキテクチャ

クロスリージョン集約

複数リージョン集約レジオン構成

EventBridge 連携

Finding → 自動対応フロー

Security Lake 統合

Security Lake との連携

他の類似ツールとの比較

クライアント・エコシステム

AWS Management Console

AWS CLI / SDKs

IaC（Terraform / CloudFormation）

ベストプラクティス

✅ 推奨パターン

❌ アンチパターン

トラブルシューティング

2025-2026 最新動向

1. AI / 機械学習による異常検知

2. DevSecOps パイプライン統合

3. Security Lake 本運用開始

4. サードパーティ統合の拡大

学習リソース

AWS 公式ドキュメント

ベストプラクティス・ブログ

実装例・活用シーン

導入ロードマップ

Phase 1（0-1 ヶ月）

Phase 2（1-3 ヶ月）

Phase 3（3-6 ヶ月）

実装チェックリスト

まとめ

主要メリット

参考文献

AWS 公式ドキュメント

ベストプラクティス