はじめに
Security Hub CSPM を複数アカウントで管理する方法には、「中央設定（推奨）」と「ローカル設定」の 2 種類があります。
公式ドキュメントと AWS のベストプラクティス資料をもとに、違いと推奨構成を理解のために図にまとめてみました。
Security Hub CSPM は、旧「AWS Security Hub」の現在の名前です。AWS の設定がセキュリティのお作法に沿っているかを継続的にチェックします。
GuardDuty などの検出結果をまとめる新しい Security Hub とは別のサービスです。
中央設定では、設定する場所が「委任管理者 × ホームリージョン」の 1 か所にまとまります。
用語
| 用語 | ひとことで |
|---|---|
| 管理アカウント | AWS Organizations の親アカウント（旧称: マスターアカウント） |
| OU（組織単位） | アカウントを入れるフォルダ。「本番 OU」「開発 OU」のように分ける |
| 委任管理者 | Security Hub CSPM の管理を任されたメンバーアカウント。中央設定では管理アカウントはなれない |
| ホームリージョン | 委任管理者が設定するリージョン。検出結果の集約先も兼ねる |
| リンクされたリージョン | ホームリージョンから一括で設定されるリージョン |
| セキュリティ標準 / コントロール | チェック項目のセット（FSBP、CIS など）/ その中の個々のチェック項目 |
| 設定ポリシー | 有効にする標準・コントロールをまとめた設定のひな形 |
ローカル設定と中央設定の違い
Organizations と連携しただけの状態はローカル設定で、委任管理者が自動化できるのは「新規アカウント × 1 リージョン」の有効化だけです（ローカル設定）。
| 観点 | ローカル設定（既定） | 中央設定（推奨） |
|---|---|---|
| 対象アカウント | 新規のみ | 既存 + 新規 |
| 対象リージョン | 委任管理者を指定したリージョンのみ | ホーム + リンクされたリージョン |
| 標準・コントロール | 既定の FSBP と CIS v1.2.0 のみ。それ以外は各自で設定 | ポリシーで有効化・無効化・パラメータまで指定 |
| 勝手な設定変更 | 起こりうる | 一元管理型のアカウントではできない |
ドキュメントでは「複数リージョンで運用している」「チームごとに設定を変えたい」「新規アカウントにも決まった設定を入れたい」「親 OU の設定を子に引き継ぎたい」のどれかに当てはまれば中央設定を推奨しています。マルチアカウントなら、ほぼ中央設定になるということかと思います。
中央設定の仕組み
アカウントや OU ごとに、一元管理型（委任管理者がポリシーで決め、メンバーは変更できない）かセルフマネージド型（持ち主がリージョンごとに自分で設定）を選びます（中央設定）。
ポリシーは OU の親子関係に沿って継承され、直接つけた設定が継承より優先されます。 組織に入ったばかりのアカウントは Root の設定を継承するので、Root にポリシーをつけておけば漏れがありません。
設定ポリシーの作り方
設定ポリシーは、用意されている「推奨ポリシー」をそのまま使うか、「カスタムポリシー」を自分で作るかの 2 通りです。
- 推奨ポリシー: コンソールで選ぶだけで、組織全体で CSPM と FSBP のチェックがすべてオンになる。まずはここから始めるのが手軽
- カスタムポリシー: 本番と開発でチェック内容を変えたいときなどに作る（最大 20 個。1 つのアカウント / OU に紐づくのは 1 つだけ）
中央設定を始める流れ
① の委任管理者の指定は、ホームリージョンにしたいリージョンで行います（開始手順）。
なお、始める前に、AWS Config を全アカウント × 使うリージョンで有効にしておく必要があることに留意してください。
ベストプラクティス
AWS Security Reference Architecture の推奨構成です。
検出結果はホームリージョンに自動で集まるので、保管用の EventBridge ルールはホームに 1 本で済みます。
| やること | 理由 |
|---|---|
| 委任管理者は Security Tooling アカウントにする | セキュリティ専用アカウントに管理を寄せる |
| GuardDuty / Inspector / Macie / 新しい Security Hub と委任管理者をそろえる | 1 つのアカウントで横断して見られる |
| 使っているリージョンはすべてリンクする | リンクしないとポリシーも検出結果も届かない。CloudFront 系は us-east-1 でしか評価されない |
| 管理アカウント用のポリシーを分ける | ルートユーザー系の IAM.6 など、管理アカウントだけ無効にしたくないものがある（AWS Security Blog） |
| Config のグローバルリソース記録はホームだけ | IAM などのグローバル系コントロールは原則ホームだけで評価されるので、費用を抑えられる |
| ポリシーは IaC で管理する | CloudFormation の AWS::SecurityHub::ConfigurationPolicy が使える |
注意点
- 委任管理者を Organizations 側で変更・削除すると中央設定が止まる: ポリシーの関連付けも消える
- マルチクラウドの標準（CIS Azure など）はポリシーに入れられない: 各アカウントで設定する
- CLI / API での関連付けは 1 リクエスト 1 対象: コンソールならまとめて関連付けできる
まとめ
- マルチアカウントでは、全アカウント × 全リージョンをポリシーで管理できる中央設定が推奨です
- Root に基本のポリシー、OU ごとに差分、例外だけセルフマネージド型、という組み立てがわかりやすそうです