Control Towerのコントロール、何から設定する？
はじめに
皆様こんにちは、あかいけです。
突然ですが、Control Towerのコントロール、多すぎないですか…？
2026年10月30日時点のコントロールカタログを見ると、次のとおり合わせて1,613個のコントロールがあります。
- 予防的コントロール：69個
- 発見的コントロール：1,309個
- プロアクティブコントロール：235個
こんなの、初めて見た人はどれから手をつければいいかわからず、路頭に迷ってしまいますよね…？？？
というわけで今回は、Control Towerのコントロールを何から設定すればよいのか、考え方と優先度を整理してみます。
前提条件
本ブログでは以下の前提でお話しします。
- Control Towerのランディングゾーンが有効化済み
- ランディングゾーンのバージョンが4.0
コントロールの全体像
Control Towerにおけるコントロールは、AWS環境に対するガバナンスのルールを、AWSが管理する形で提供してくれる仕組みです。
たとえば次のようなルールが、あらかじめ用意されています。
- rootユーザーでの操作を禁止する（SCP）
- S3バケットへのパブリックな読み取りアクセスを検知する（AWS Configルール）
これらのコントロールの多くはAWSのベストプラクティスに基づいており、CISやNISTといったコンプライアンスフレームワークとの対応付けも用意されています。
そのため、ガバナンスのルールを一から設計しなくても、必要なコントロールを選んで有効化するだけで、ある程度ベストプラクティスに沿った環境を作れるわけですね。
そしてコントロールを有効化すると、動作に応じて次の場所にリソースが作られます。
- 予防的コントロール：AWS OrganizationsのポリシーとしてOUにアタッチされる
- 発見的コントロール / プロアクティブコントロール：OU配下の登録済みアカウントにデプロイされる
コントロールの分類
コントロールは、大まかに次の3つの軸で分類できます。
この軸を整理しておくことで、コンソールの一覧画面に並んでいる大量のコントロールが何をしてくれるのかが分かるようになります。
動作による分類
1つ目の軸は、そのコントロールが何をするのかを表す動作(Behavior)です。
| 動作 | 実装方法 | 評価するタイミング |
|---|---|---|
| 予防的(Preventive) | SCP、RCP、宣言型ポリシー | API呼び出しの時点でブロックする |
| 発見的(Detective) | AWS Configルール | リソースが作られたあとに検知する |
| プロアクティブ(Proactive) | CloudFormation Hooks | プロビジョニングの前に判定する |
各動作のコントロールが評価を行うタイミングを、リソースが作られるまでの流れに沿って並べると次のようになります。
注意したいのは、プロアクティブコントロールはCloudFormation Hooksで動くため、CloudFormationを経由しない操作は基本的に評価されない点です。そのため上記の図の通り、マネジメントコンソールやTerraformからの操作はHooksを通りません。
ガイダンスによる分類
2つ目の軸は、AWSによる推奨度を表すガイダンス(Guidance)です。
動作とは独立した分類であり、「予防的かつ選択的」といった組み合わせになります。
| ガイダンス | 位置付け |
|---|---|
| 必須(Mandatory) | Control Towerが作成したリソースを保護するためのもの。無効化できない |
| 強く推奨(Strongly recommended) | マルチアカウント環境のベストプラクティスに基づくもの |
| 選択的(Elective) | 企業環境で制限されることが多い操作を追跡、制限するもの |
なお必須コントロールは、ランディングゾーン3.3以前は一律に適用されていましたが、4.0からは有効化した機能に応じて適用されるように変わりました。
- AWS ConfigやCloudTrailのサービス統合を有効化すると、それらのリソースを保護する必須コントロールが適用される
- OUを登録する（ベースラインを適用する）と、そのOUに必須コントロールが適用される
オーナーによる分類
3つ目の軸は、そのコントロールを誰が管理しているかを表すオーナー(Control owner)です。
オーナーによって、デプロイされるリソースの実体をどのサービスが管理するのかが変わります。
| オーナー | 識別子の例 | 内容 |
|---|---|---|
| AWS Control Tower | AWS-GR_REGION_DENY、CT.CLOUDFORMATION.PR.1 |
Control Tower自身が提供するコントロール |
| AWS Security Hub | SH.で始まるもの |
Service-Managed Standard: AWS Control Towerとして提供される発見的コントロール。AWS基礎セキュリティのベストプラクティス(FSBP)のサブセット |
| AWS Config | CONFIG.で始まるもの |
統合Configコントロール。Configマネージドルールが500以上登録されている |
このうち、Security HubとAWS Configがオーナーのコントロールには、次のような特徴があります。
- Security Hubがオーナーのコントロール（
SH.）- Control Towerから有効化すると、Security Hub側に「Service-Managed Standard: AWS Control Tower」という標準が作成され、そこに追加される
- Security Hubのコンソールから直接無効化するとControl Tower側がドリフト状態になるため、有効化と無効化はControl Towerから行う
- AWS Configがオーナーのコントロール（
CONFIG.、統合Configコントロール）- Configのマネージドルールを、コントロールカタログから検索して有効化できる
- Security Hubの標準に含まれないチェックを足したいときの選択肢になる
コントロールとOUの関係
ここまでで、コントロールそのものの分類を整理しました。
次は、コントロールを適用する単位であるOUについて、継承の仕組みとOU構成の考え方を整理します。
コントロールの適用単位について
前提として、コントロールはOU単位で有効化します。
SCPやRCPを自分でアタッチする場合はアカウントを直接指定できますが、コントロールはアカウント単位で個別に有効化できません。
つまりOU構成がそのままガバナンスの適用単位になります。
なのでコントロールを検討する前に、まずOU構成を決めておく必要があります。
OU構成そのものについては、AWSが公開しているベストプラクティスが参考になります。
ネストしたOUへの継承
OU構成を考えるうえで必ず押さえておきたいのが、ネストしたOUへの継承の有無がコントロールの動作ごとに異なる点です。
| 動作 | ネストしたOUへの継承 |
|---|---|
| 予防的 | 継承される。上位OUで有効化すると、配下のOUとアカウントすべてに適用される。 |
| 発見的 | 継承されない。OUごとに個別に有効化する必要がある。デプロイ先は登録済みアカウントのみ。 |
| プロアクティブ | 継承されない。OUごとに個別に有効化する必要がある。デプロイ先は登録済みアカウントのみ。 |
たとえばWorkloadsOUで予防的コントロールと発見的コントロールを有効化すると、配下のProdOUへの適用は次のようになります。
（この違いを知らないとWorkloadsOUだけで発見的コントロールを有効化にして配下のWorkloads/ProdOUには適用されない…みたいな事故が起きます）
なおこの継承は、SCPの上限対策にも使えます。
Control Towerのランディングゾーン配下のOUには、1つのOUあたり10個までというSCPの上限があります。
下位OUそれぞれで予防的コントロールを有効化するのではなく、上位OUでまとめて有効化すれば、その分の枠を節約できます。
OU構成の考え方
以上を踏まえると、OU構成とコントロールのかけ方は次のように整理できます。
実際の組織ではこれ以外にもOUがあると思いますが、統制のかけ方はどのOUも似たり寄ったりです。そのため、基本となる次のOUの考え方が決まれば、ほかのOUのかけ方も自ずと決まっていくでしょう。
- Root
- 組織全体に適用したいコントロールを有効化する
- Workloads OU
- ワークロード全体に共通で適用したいコントロールを有効化する。ただし配下のOUに継承されるのは予防的コントロールだけなので、発見的コントロールとプロアクティブコントロールは配下のOUでも個別に有効化する
- Dev／Stg／Prod OU（Workloads配下）
- 環境ごとに強度を変えたいコントロールを、それぞれのOUで個別に有効化する
- Sandbox OU
- 検証用途なので、自由度高め
- PolicyStaging OU
- 新しいコントロールを本番に出す前に試すため、普段は利用しない
コントロールを設定する優先順位
さて、冒頭でも触れた通りコントロールはとにかく数が多いので、優先度の高いものから何を使うか決めていきましょう。
なお必須コントロールはそもそも強制的に有効になっているため、検討対象から外してOKです。
| 順番 | 対象 | おすすめの初期設定 |
|---|---|---|
| 1 | 予防的コントロール | リージョンの制限など、実行を禁止したい操作に絞って有効化する。それ以外の「強く推奨」「選択的」は運用開始後に検討する |
| 2 | 発見的コントロール | Security Hub CSPMでFSBPを全アカウントに有効化し、足りないチェックだけをコントロールカタログから追加する |
| 3 | プロアクティブコントロール | CloudFormationやCDKでのデプロイが中心で、デプロイ前に設定を厳格にチェックしたい場合に有効化する |
| 4 | コントロールでカバーできない領域 | SCP、RCP、宣言型ポリシー、カスタムConfig Rulesで補う |
こうして並べてみると、初期構築の段階でコントロールの一覧から自分で選ぶものは、実はそれほど多くありません。
1. 予防的コントロール
予防的コントロールは、違反につながる操作をAPI呼び出しの時点で止められる、最も強い統制です。
ただしその分、想定より広い範囲に影響しやすく、次のような点に注意が必要です。
- 本来必要なAPIまで拒否されると、リソースのデプロイやアプリケーションの実行が失敗する
- 1つのOUあたり10個までのSCPの枠を消費する
そのため、明確に禁止したい操作や具体的な要件がなければ、初期構築ではリージョンの制限のように最低限必要なものだけを有効化しましょう。
それ以外の「強く推奨」や「選択的」の予防的コントロールは運用開始後に個別に検討し、リソース作成後に検知できれば十分なものは次の発見的コントロールに任せましょう。
以下はリージョン制限ができる主なコントロールです。
| コントロール | 適用範囲 |
|---|---|
AWS-GR_REGION_DENY |
ランディングゾーン全体 |
CT.MULTISERVICE.PV.1 |
OU単位。AllowedRegionsやExemptedPrincipalArnsで、許可するリージョンと例外のプリンシパルを指定できる |
なおすでに使っているリージョンを塞ぐとそのリージョンのリソースを操作できなくなるため、有効化する前に利用中のリージョンを確認しておきましょう。
2. 発見的コントロール
Control Towerの発見的コントロールとSecurity Hub CSPMのFSBPは、どちらもConfigルールを使ってチェックします。
そのため両方を無計画に有効化すると、同じ内容のチェックがControl Tower側とSecurity Hub CSPM側でそれぞれ実行され、Control Tower側のConfigルールの評価料金とSecurity Hub CSPMのチェック料金が二重にかかります。
そこで、次のように役割を分けておきます。
基本はSecurity Hub CSPMでFSBPを全アカウントに有効化し、これをベースラインにします。
Control Towerの発見的コントロールは、FSBPで足りないチェックがあるときにだけ追加すれば十分です。
またControl Towerの発見的コントロールを追加するときは、パラメータを指定できない点に注意しましょう。
本来パラメータで条件を調整するConfigルールもパラメータなしでデプロイされるため、判定が想定より厳しくなる場合があります。
3. プロアクティブコントロール
プロアクティブコントロールはCloudFormation Hooksで動くため、使うかどうかはデプロイ方法で決まります。
| デプロイ方法 | 判断 |
|---|---|
| CloudFormationやCDKが中心 | デプロイ前にブロックできるので、有効な選択肢になる |
| Terraformが中心 | CloudFormationを経由しないため、ほとんど機能しない |
ただし、CloudFormationやCDKだけでデプロイしている環境でも、コンソールからの手動操作までは止められず、結局は予防的コントロールが必要になります。
そのため優先度は低めで、デプロイ前に設定を厳格にチェックしたい場合など、必要なときに使えば十分だと思います。
4. コントロールでカバーできない領域
「このAWSサービスは組織として使わせない」のような固有の制限は、ドンピシャなコントロールが用意されていないことがほとんどです。
そのためそれらは、コントロール外で以下のような機能を使って実装する必要があります。
| 手段 | 設定場所 | 向いている要件 |
|---|---|---|
| SCP | AWS Organizations | 特定サービスのAPIを組織全体で拒否したい |
| RCP | AWS Organizations | 組織内のリソースに対するアクセス許可の上限を決めたい |
| 宣言型ポリシー | AWS Organizations | APIの拒否ではなくサービス側の設定そのものを強制したい |
| Config Rules | AWS Config | 既存のルールにない独自の設定チェックを行いたい |
Control Towerのコントロールも、中身はSCPやConfigルールといった各サービスの機能です。
違いは、Control Towerがコントロールとしてラッピングしたものを使うか、元のサービスの機能をそのまま使うかだけです。
元のサービスの機能をそのまま使うときは、次の2点を意識しておくとよいです。
- SCPやRCPは、要件ごとに分けずに1つのポリシーへStatementを足していくと、アタッチ数の上限（SCPは10個、RCPは
RCPFullAWSAccessを含めて5個）を圧迫しない。ただし1つのポリシーにもサイズ上限（SCPは10,240文字、RCPは5,120文字）があるので、まとめすぎにも注意する - 宣言型ポリシーは、AWSサービスの設定そのものを強制する仕組み。IMDSv2の強制やAMI・EBSスナップショットのパブリック共有の禁止など、SCPやRCPでは制御しづらい設定は宣言型ポリシーで制御する
さいごに
以上、Control Towerのコントロールを何から設定するか、優先順位を整理してみました。
一見するとコントロールの数は膨大ですが、本ブログで整理した分類や優先順位を意識すれば、コントロールの選定はグッと楽になるはずです。
次回は、個人的に設定をおすすめしたいアチアチなコントロールについて語っていきたいと思います。
これからControl Towerを触る方の参考になれば幸いです。
