🛡️ AWS Security Hub 設定ポリシー完全図解

Configuration Policies ～ 組織全体のセキュリティ設定を一括管理 ～

📌 結論ファースト：30秒でわかる設定ポリシー

Security Hub設定ポリシーとは、
AWS Organizations内の複数アカウント・複数リージョンに対して
Security Hubの設定を一括で適用・管理できる機能です。
🏨 ホテルチェーンの本社が全店舗のセキュリティ基準を統一管理するイメージ！
🎯
一元管理
委任管理者が1つのリージョンから全アカウント・全リージョンのSecurity Hub設定を管理
📋
ポリシーベース
設定ポリシーを作成してOU/アカウントに関連付け。継承機能で効率的に適用
🔧
柔軟な制御
「中央管理」と「セルフ管理」を使い分け。組織の要件に合わせてカスタマイズ
✅
一貫性保証
新規アカウント追加時も自動でポリシー適用。設定の逸脱を防止

🏨 たとえ話：ホテルチェーンの本社セキュリティ管理

Security Hub設定ポリシーを「大手ホテルチェーンの本社によるセキュリティ管理」に例えてみましょう！
本社（委任管理者）が各ホテル（アカウント）のセキュリティルールを統一管理します。
🏢
ホテルチェーン本社（Delegated Administrator）
「全店舗のセキュリティ基準は本社が決めます！」
📋 セキュリティポリシー作成・配布
⬇️
🔄 AWS概念との対応関係
🏢
本社
Delegated Administrator
（委任管理者アカウント）
➡️
📋
セキュリティマニュアル
Configuration Policy
（設定ポリシー）
🏨
各ホテル店舗
Member Account
（メンバーアカウント）
➡️
🗺️
エリア（東日本/西日本）
Organizational Unit (OU)
（組織単位）
🏨
東京本店
中央管理
  • ✅ 本社のルール100%適用
  • ✅ 設定変更不可
  • ✅ 24時間監視カメラ必須
  • ✅ 金庫は指定メーカーのみ
🏨
大阪支店
中央管理
  • ✅ 本社のルール100%適用
  • ✅ 設定変更不可
  • ✅ 親OU（西日本）から継承
  • ✅ 自動で最新ルール適用
🏨
福岡フランチャイズ店
セルフ管理
  • ⚡ 独自ルール設定可能
  • ⚡ リージョンごとに設定
  • ⚡ 本社API使用不可
  • ⚡ 責任は各店舗
🏨
札幌支店（新規）
中央管理
  • ✅ 開店時に自動でルール適用
  • ✅ 親OUのポリシー継承
  • ✅ 手動設定不要
  • ✅ 即座にセキュリティ確保

🔧 設定ポリシーで制御できる内容

📋 Configuration Policyで指定できる設定項目
🔌
Security Hubの有効化/無効化
  • 対象アカウントでSecurity Hubを自動有効化
  • または無効化を強制
  • 新規アカウントにも自動適用
📏
セキュリティ基準の選択
  • AWS Foundational Security Best Practices
  • CIS AWS Foundations Benchmark
  • PCI DSS
  • NIST SP 800-53
  • その他利用可能な基準
🎚️
コントロールの有効化/無効化
  • 🟢 有効化リスト方式：
    指定したコントロールのみ有効化
  • 🔴 無効化リスト方式：
    指定したコントロールのみ無効化（他は全て有効）
⚙️
コントロールパラメータのカスタマイズ
  • 一部コントロールのパラメータ値を変更
  • 例：パスワードポリシーの最小文字数
  • 例：ログ保持期間の日数
  • 組織の要件に合わせて調整
⚠️ 注意：AWS Configの設定は別途必要
設定ポリシーにはAWS Config レコーダーの設定は含まれません。
Security Hubがコントロールの検出結果を生成するには、AWS Configを別途有効化し、必要なリソースの記録を設定する必要があります。

⚖️ 中央管理 vs セルフ管理

特徴 🏢 中央管理（Centrally Managed） 🏨 セルフ管理（Self-Managed）
設定の制御者 委任管理者のみ 各アカウントオーナー
設定ポリシーの適用 ✅ 適用される ❌ 適用されない
アカウント側での設定変更 ❌ 不可 ✅ 可能
設定範囲 ホームリージョン + リンクリージョン一括 リージョンごとに個別設定
ポリシーの継承 ✅ 親OUから継承 ⚡ セルフ管理を継承可能
推奨される用途 本番環境、コンプライアンス必須環境 開発/テスト環境、特殊要件のある環境
識別子 ポリシーのARN/UUID SELF_MANAGED_SECURITY_HUB

🏗️ 組織構造とポリシー継承の仕組み

📊 OU階層とポリシーの継承例
🌐 Organization Root
🔒 厳格ポリシー適用
🏭 Production OU
親から継承
💡 アカウントCには別のポリシーを直接適用
🔧 Development OU
柔軟ポリシー適用
💡 テストアカウントは独自設定が必要なためセルフ管理

📌 継承ルール：
1️⃣ 直接適用されたポリシーが最優先
2️⃣ 直接適用がなければ、親OUから継承
3️⃣ セルフ管理も親から継承可能（ポリシーは継承不可）

🚀 設定ポリシーの導入手順

📋 中央設定（Central Configuration）の有効化フロー
1
前提条件の確認
AWS Organizations有効化、AWS Config有効化、管理アカウントでSecurity Hub有効化
⬇️
2
委任管理者（Delegated Administrator）の指定
管理アカウントから委任管理者アカウントを指定。セキュリティ専用アカウントを推奨
⬇️
3
ホームリージョンとリンクリージョンの選択
ポリシー作成の拠点となるホームリージョンと、設定を適用するリンクリージョンを指定
⬇️
4
中央設定の有効化
ConfigurationTypeを「CENTRAL」に設定して中央設定モードを有効化
⬇️
5
設定ポリシーの作成
Security Hub有効化、基準選択、コントロール設定を含むポリシーを作成
⬇️
6
ポリシーの関連付け
作成したポリシーをOU、アカウント、またはルートに関連付け

💻 AWS CLI コマンド例

🔧 中央設定の有効化
# 中央設定（Central Configuration）を有効化 aws securityhub update-organization-configuration \ --region us-east-1 \ --no-auto-enable \ --organization-configuration '{"ConfigurationType": "CENTRAL"}'
📋 設定ポリシーの作成
# 本番環境向け厳格ポリシーの作成 aws securityhub create-configuration-policy \ --region us-east-1 \ --name "Production-Strict-Policy" \ --description "厳格なセキュリティ設定（本番環境用）" \ --configuration-policy '{ "SecurityHub": { "ServiceEnabled": true, "EnabledStandardIdentifiers": [ "arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0", "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0" ], "SecurityControlsConfiguration": { "DisabledSecurityControlIdentifiers": [ "CloudTrail.6", "CloudTrail.7" ] } } }'
🔗 ポリシーをOUに関連付け
# 本番OU全体にポリシーを適用 aws securityhub start-configuration-policy-association \ --region us-east-1 \ --configuration-policy-identifier "arn:aws:securityhub:us-east-1:123456789012:configuration-policy/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" \ --target '{"OrganizationalUnitId": "ou-abc1-23456789"}'
🔓 アカウントをセルフ管理に変更
# 特定のアカウントをセルフ管理に設定 aws securityhub start-configuration-policy-association \ --region us-east-1 \ --configuration-policy-identifier "SELF_MANAGED_SECURITY_HUB" \ --target '{"AccountId": "111122223333"}'

✨ ベストプラクティス

💡 設定ポリシー運用のコツ
🧪
テストファーストアプローチ
中央設定を有効化しても、既存アカウントは即座に影響を受けません（デフォルトでセルフ管理）。まずテストアカウントでポリシーを検証してから本番適用しましょう。
🎯
グローバルリソースコントロールの最適化
IAMなどグローバルリソースに関するコントロールは、Security Hubが自動的にホームリージョン以外で無効化します。重複評価を防ぎコスト削減できます。
📊
ポリシーの使い分け
環境ごとに異なるポリシーを作成：本番環境は全コントロール有効、開発環境は必須コントロールのみ、など柔軟に設計しましょう。
🔔
無効化リスト方式を推奨
新しいコントロールがリリースされた際に自動で有効化されるため、「無効化リスト方式」を使用することで常に最新のセキュリティカバレッジを維持できます。
📝
ポリシーの命名規則
ポリシー名に環境（prod/dev）、厳格度（strict/flexible）、対象（all/specific）を含めて管理しやすくしましょう。例：「Prod-Strict-AllStandards」
🔄
定期的な見直し
AWSは定期的に新しいコントロールを追加します。四半期ごとにポリシーを見直し、無効化しているコントロールが本当に不要か確認しましょう。

❓ よくある質問

🤔 設定ポリシーを使うには何が必要？
3つの前提条件があります：

1️⃣ AWS Organizationsが有効化されていること
2️⃣ AWS Configが必要なリージョンで有効化されていること
3️⃣ 管理アカウントでSecurity Hubが少なくとも1つのリージョンで有効化されていること

これらが揃ったら、委任管理者を指定して中央設定を有効化できます。
🤔 ローカル設定（Local Configuration）との違いは？
大きく3つの違いがあります：

項目 中央設定 ローカル設定
設定範囲 全リージョン一括 リージョンごと
ポリシー利用 ✅ 利用可能 ❌ 利用不可
新規アカウント 自動でポリシー適用 自動有効化のみ（限定的）

AWSは中央設定の使用を推奨しています。
🤔 ポリシーを関連付け解除したらどうなる？
設定は「そのまま残ります」。

例えば、CloudWatchコントロールを無効化するポリシーを適用していた場合、関連付けを解除しても CloudWatchコントロールは無効のままです。

元に戻すには：
• 新しいポリシーを関連付けてコントロールを有効化
• またはセルフ管理に変更して手動で有効化

⚠️ 関連付け解除≠設定リセット であることに注意してください。
🤔 オプトインリージョンでも使える？
はい、ただし事前に有効化が必要です。

2019年3月20日以降に導入されたリージョン（オプトインリージョン）は、デフォルトで無効化されています。

設定ポリシーを適用する前に：
1️⃣ Organizations管理アカウントでオプトインリージョンを有効化
2️⃣ その後、設定ポリシーが適用可能に

注意：ホームリージョンにはオプトインリージョンを指定できません。
🤔 委任管理者を変更・削除したらどうなる？
中央設定が自動的に停止します。

委任管理者が変更または削除されると：
• 中央設定は自動停止
• すべての設定ポリシーの関連付けが解除
• 設定ポリシー自体も削除

ただし、メンバーアカウントの設定は変更前の状態が維持されます。

💡 委任管理者の変更は慎重に行い、事前にポリシー設定をドキュメント化しておくことを推奨します。

📝 まとめ：設定ポリシーを使うべき理由

🎯
ガバナンスの統一
組織全体で一貫したセキュリティ基準を維持。「設定の逸脱」を防ぎ、コンプライアンスを確保
⚡
運用効率化
アカウント・リージョンごとの設定作業が不要に。新規アカウントも自動でセキュリティ確保
🔍
可視性の向上
どのアカウントにどのポリシーが適用されているか一目で把握。セキュリティ体制を見える化
🛡️
セキュリティ強化
委任管理者以外は設定変更不可。意図しない設定変更や無効化を防止

🏨 ホテルチェーンの本社が全店舗のセキュリティを統一管理するように、
設定ポリシーでAWS Organizations全体のセキュリティを一元管理しましょう！

Created by SSuzuki1063

AWS SAP Learning Resources