AWS セキュリティガバナンスの棚卸しと見直し方針を整理した話

この記事は KINTOテクノロジーズ Advent Calendar 2025 の 6 日目の記事です🎅🎄
 はじめにこんにちは。KINTO テクノロジーズ Cloud Security グループの渡邉です。
当社では AWS Organizations と Control Tower を利用したマルチアカウント運用を続けていますが、長年の積み重ねにより、一部の設計を見直す必要が出てきました。そこで、既存環境を前提にセキュリティガバナンス設計の再整理を進めることにしました。
本プロジェクトでは、いきなり全体を作り直すのではなく、影響の大きい領域から優先順位を付けて段階的に整理していく方針を取っています。そのうえで、安全性の判断を優先しつつ、新規 OU や AWS のマネージド機能の活用など、将来の運用改善につながる変更も一部取り入れています。
プロジェクトはまだ設計フェーズの段階であり、最終成果はこれからですが、本記事では現時点での意思決定の流れと背景を共有します。
※ 本記事は AWS Organizations / AWS Control Tower / Security Hub CSPM / SCP / OU 設計に一定の理解がある読者を対象としています。

※ プロジェクト前半である設計フェーズ時点の内容をベースにしており、今後の実装フェーズで変わる可能性があります。
 設計項目の棚卸しまずは既存環境のセキュリティガバナンス要素を整理し、影響度と改善効果の観点から、以下の 5 項目を優先的に棚卸ししました。
最初の 3 項目は影響範囲が広く、クラウドセキュリティ以外のチームにも関係する領域です。後半の 2 項目は、それらに付随して検討が必要となる領域です。
OU 設計

└ OU 構造がそのままガードレール設計に影響するため
予防的ガードレール

└ 望ましくない操作を事前にブロックする仕組みであり、既存アカウントに影響するため
発見的ガードレール

└ 望ましくない設定を早期に検出する仕組みであり、予防的ガードレールと相互補完の関係にあるため
設定自動化ツール

└ 新規アカウントの初期設定を自動化する社内ツール
アカウント発行フロー

└ 新規アカウント払い出しのプロセス
本記事では、それぞれの棚卸し過程で見えてきた課題と判断の背景を紹介します。
 AWS セキュリティガバナンス構成の整理この章では、当社の AWS セキュリティガバナンスがどのようなレイヤで構成されているかを整理します。
次の図は、
管理アカウントで適用される設定 ( AWS Organizations / AWS Control Tower / AWS CloudFormation )
それとは別に、設定自動化ツールによって管理アカウントおよびユーザアカウントに追加される設定
が、ユーザアカウント側で
3 段階の予防ガードレール ( 1 段目 : Control Tower 標準、2 段目 : 追加ガードレール、3 段目 : カスタムSCP )
2 系統の検出 ( Security Hub CSPM 系統、Control Tower 系統)
監視・予防対象リソースの事前適正化 (設定自動化ツールによる初期設定)
として作用する全体構造を示したものです。
図のとおり、当社環境では Control Tower の標準ガードレールに加えて、設定自動化ツールで補完した追加ガードレールやカスタム SCP により、3 段階の予防コントロールを構成しています。
また、Security Hub CSPM 系統と、Control Tower 系統という 2 系統の検出レイヤ、そして設定自動化ツールによるリソースの事前適正化も組み合わせることで、ガバナンス全体を構築しています。
これらは導入時期や目的が異なるため、OU や アカウント間で設定のばらつきが生じている部分もあります。
この図における主要な役割分担は、次の 5 つに整理できます。
Control Tower 標準ガードレール

└ AWS が提供する予防・検出のベースライン
追加ガードレール (設定自動化ツールで有効化)

└ 標準だけではカバーできない制約を追加するための予防・検出ガードレール
カスタムSCP (設定自動化ツールから設定)

└ 例外的な要件に対応するための当社独自の制限
Security Hub CSPM 系統 ( CSPM 側の検出レイヤ)

└ AWS Config と連携し、設定ミスやベストプラクティス違反を継続的に検出するサービス
Control Tower 系統 ( Control Tower 側の検出レイヤ)

└ AWS Config と連携し、Control Tower のガードレールに紐づく検出コントロールを実現
こうした多層構造は AWS ガバナンスでは珍しくない構成ですが、棚卸しを進めるうえでは、どのレイヤがどのコントロールを提供し、各設定が Control Tower / Security Hub CSPM / 設定自動化ツールのどこに属しているのかを明確に整理する必要があり、一定の複雑さを伴いました。
今回は、まず Control Tower の追加ガードレール、特に影響の大きい予防コントロールを最新の状態へ追従させることを優先しました。レイヤ間の重複や役割分担の最適化については、今後の改善テーマとして段階的に進めていく方針としています。
 OU 設計の棚卸しOU 設計は Control Tower の動作と密接に関係するため、設計変更時の影響範囲を見極めるのが特に難しい領域です。
特に影響が大きく、判断を難しくしたのは以下の 3 点です。
一部の動作がドキュメント化されておらず、事前に挙動を読み切れない場面がある点

└ 例えば、OU 名の変更後に必要となるランディングゾーンのリセット時に、何が行われるのかに関する詳細仕様が公開されていない点など
OU ごとの差異に加え、過去の実装や運用の積み重ねが影響しており、OU 内のアカウントを別 OU に移動する際に、どの設定がどう再適用されるかを個別確認する必要がある点
本番アカウントや Control Tower の履歴を含む状態を検証環境で正確に再現できないため、検証だけでは安全性を保証しきれない点

└ 例えば、本番アカウントにおいて、Control Tower の運用に必要なリソースが、過去の運用の中で何らかの理由により変更・削除されているケースなど
上記を踏まえ、今後作成されるアカウントの収容先として、次の 3 パターンを比較しました。
ここでの 3 パターンは次のようなイメージです。
既存 OU (現状維持) : いま使っている OU 構造やガードレールを変えずに、新規アカウントを収容していく。
既存 OU (新ガードレール適用) : いま使っている OU 群に新しいガードレールを適用し、新規アカウントを収容していくことで、既存アカウントも含めて一気に状態を揃える。
新規 OU 群 : 既存 OU 群は現状維持として、新しいガードレールを適用した OU 群を新たに作成し、その OU に新規アカウントを収容していく。


No
収容先
変更の影響
長期の健全性
導入容易性
コメント


1
既存 OU (現状維持)
◎ 既存への影響なし
× 負債が残る
◎ 現状維持で容易
一時的には安全だが長期負債が増える

2
既存 OU (新ガードレール適用)
× 既存全体へ影響大
◎ 健全性が高い
× 検証負荷が大きい
理想的だが影響が重く段階移行が必要

3
新規 OU 群
◎ 既存への影響なし
△ OU 分散リスク
◎ 導入・検証が容易
OU 分散を後続フェーズで解消する必要あり

今回は、既存環境への影響を避けつつも新たな仕組みの導入が容易な案 3 を採用しました。
ただし、これは恒久的な解ではなく、既存 OU をいきなり組み替えずに新しいガードレール構成と運用モデルを検証するための最初の一歩という位置付けです。
新規 OU 群で運用実績と検証結果を蓄積したうえで、Sandbox OU など影響の小さい既存アカウントから段階的に移設し、最終的には OU 構成とガードレールを可能な限り統一していくことを中長期の方針としています。
 予防的ガードレールの棚卸し予防的ガードレールは、望ましくない操作や構成を未然に防ぐための仕組みです。当社環境では、AWS Control Tower の標準ガードレールに加え、その不足分を補完するため、設定自動化ツールで追加のガードレール有効化・カスタム SCP を適用しています。


段
名称
主体
役割


1 段目
標準ガードレール
AWS Control Tower
AWS 標準の予防コントロール

2 段目
追加ガードレール
設定自動化ツール ( CDK )
標準ガードレールでカバーできない不足分の補完

3 段目
カスタムガードレール
設定自動化ツール ( CDK )
当社固有の要件に合わせた独自の SCP

新規アカウントを新設 OU に収容する方針としたため、新規 OU に設定するガードレール追加に伴う既存環境への影響はありません。そのため、初期導入後に追加された Control Tower の新しい予防コントロールを有効化すべきかどうかを検討しました。
しかしながら、AWS が提供する「重大度」だけでは、以下に挙げる 3 つの例のように、なぜその評価になっているのか、実運用でどのような影響が出るのかまでは見えませんでした。
重大度が高だが、導入判断がつかないものの例
(1) [CT.EC2.PV.4] Require that Amazon EBS direct APIs are not called
(2) [CT.S3.PV.2] Require all requests to Amazon S3 resources use authentication based on an Authorization header
重大度が中だが、導入しても良いと思われるものの例
(3) [CT.EC2.PV.11] Disallow public sharing of Amazon Machine Images ( AMIs )
そこで、Amazon Q Developer Pro ※ を用いて、各コントロールの SCP を、運用影響・推奨度・導入プロセスの観点で評価しました。上記 1～3 については、次のような気付きがありました。
EBS direct APIs を利用する AWS Backup パートナー製品などのバックアップに影響する可能性があるため注意が必要 ( CT.EC2.PV.4 )
Presigned URL が使えなくなる ( CT.S3.PV.2 )
導入は妥当であるが、SCP ではなく DECLARATIVE_POLICY なので挙動が異なる点に注意が必要 ( CT.EC2.PV.11 )
こうした整理を通じて、有効化が推奨され、影響が小さいものは、新規 OU で積極的に有効化する方針としました。
※ Amazon Q Developer Pro を利用した理由は、他の AI と比較すると応答速度は遅いものの、AWS の公式ドキュメントを都度参照したうえで回答していると推察でき、仕様変更の多い領域でも一定の安心感があったためです。
 発見的ガードレールの棚卸し当社環境では、セキュリティ基準の一元管理と自動更新性の観点から Security Hub CSPM をセキュリティ監査の主軸としています。
Control Tower の検出コントロールは、Control Tower が提供するガードレールや共通基盤の構成に関する観点を含むチェック群であり、当社では Security Hub CSPM を補完する仕組みとして位置付けています。
今回の見直しでは、運用開始後に追加された Control Tower の検出コントロールについて、「重大度：重大」または「ガイダンス：強く推奨」に該当するものを対象に、有効化の要否を確認しました。
その結果、例えば以下のようなコントロールは、Security Hub CSPM の基準にて既に監査可能であることを確認できたため、Control Tower 側では重複して有効化しない方針としました。
[CONFIG.KMS.DT.1] Checks if AWS Key Management Service ( AWS KMS ) keys are not scheduled for deletion in AWS KMS
[CONFIG.KMS.DT.2] Checks if the AWS KMS key policy allows public access
一方、以下のように、サービス固有の設定を扱う一部のコントロールについては、当社での実際の利用状況や将来の利用計画に応じて、必要性を個別に検討する方針としました。
[CONFIG.EMR.DT.1] Checks if an account with Amazon EMR has block public access settings enabled
 設定自動化ツールの棚卸し当社では、新規アカウントの初期設定を自動化するため、設定自動化ツール ( CDK ベース) を開発・運用しています。長年にわたり、このツールが新規アカウントの標準化や初期設定の抜け漏れ防止に大きく寄与してきました。
今回の棚卸しでは、現在のアカウント規模やチーム構成、AWS のマネージド機能の拡充状況を踏まえ、この仕組みをどこまでシンプルにできるかを整理しています。
一般的には自動化範囲を広げる事例も多いですが、当社では維持しやすさを優先し、必要な部分に絞る方向性としました。
設定自動化ツールで実施している内容は以下の通りです。
追加の予防的ガードレール適用
カスタム SCP の追加
Security Hub CSPM の重複・不要なアラーム抑制
Security Hub CSPM 準拠を目的としたサービス設定 (例：デフォルト暗号化やパブリックアクセスブロックの有効化など)
その他のセキュリティ設定の自動適用
現時点の方針としては、以下の 3 段構えで進める想定です。
AWS のマネージド機能に任せられる部分は、できる限り移行する
マネージド機能では置き換えられない部分は、宣言的 IaC ( CloudFormation、CloudFormation StackSets、Terraform など) での管理を優先する
IaC にも寄せられない例外的な処理は、最小限のコードとして残し、具体的な実装方式は後続フェーズで判断する
単にコードを減らすことが目的ではなく、組織として長期的に持ち続けるべき責務だけをコードに残すことを狙いとしています。
特に項目 4 については、Security Hub CSPM の中央設定 に移行することで、一部の設定を AWS のマネージド機能に寄せられる可能性があります。既存 OU ではコントロールの状態に個別差分が残っており、適用には棚卸しが必要ですが、新規 OU から段階的に活用する予定です。
また、5 の中で実施している S3 ブロックパブリックアクセス有効化の設定についても、先日公開された S3 ポリシー への移行により、同様に AWS のマネージド機能に寄せられる可能性があります。こちらも今後、導入可否についての調査を進めていく予定です。
なお、設定自動化ツールには CDK による条件分岐など独自の強みがあり、これが見直しにおける判断ポイントとなる可能性があります。引き続き、上記方針が適切かどうかを慎重に検証しながら進めていく予定です。
 アカウント発行フローの棚卸し当社では、これまで新規アカウント発行時にルートユーザの MFA を有効化する運用を行っていましたが、物理作業が伴うため、発行の都度一定の稼働が発生していました。
2024年末にメンバーアカウントのルートアクセス一元管理により、この運用自体を見直せる可能性があります。
今回の再設計と併せて、アカウント発行フローもできる限りシンプルかつ安全な形に整理することを検討しています。
 まとめ今回の棚卸しでは、長年の運用で積み上がった設定や仕組みを前提に、将来の拡張性と保守性の両面から、どこを変え、どこを維持すべきかを整理しました。
既存 Organizations を維持したまま理想的な構成へ作り替えることは簡単ではありません。OU 設計、ガードレール、初期設定の自動化ツールといった複数レイヤが相互に依存しているため、どれか一つを更新すると他のレイヤにも影響が波及するからです。
そのため今回は、すべてを全面刷新するのではなく、本番を止めずに少しずつ負債を減らしながら改善を進めるという方針で整理を進めました。特に Control Tower の挙動や一部のガードレールの影響範囲は、公開情報だけでは読み切れない部分もあるため、リスクを分割しながら段階的に検証する進め方が不可欠だと感じています。
今後は、AWS が提供するマネージド機能を積極的に活用しつつ、既存環境との整合を取りながら変更箇所を局所化し、段階的に改善を続けていく方針です。
本記事が、既存環境を前提にガバナンスを再設計する方々にとって、少しでも判断材料や視点のヒントになれば幸いです。

No	収容先	変更の影響	長期の健全性	導入容易性	コメント
1	既存 OU (現状維持)	◎ 既存への影響なし	× 負債が残る	◎ 現状維持で容易	一時的には安全だが長期負債が増える
2	既存 OU (新ガードレール適用)	× 既存全体へ影響大	◎ 健全性が高い	× 検証負荷が大きい	理想的だが影響が重く段階移行が必要
3	新規 OU 群	◎ 既存への影響なし	△ OU 分散リスク	◎ 導入・検証が容易	OU 分散を後続フェーズで解消する必要あり

段	名称	主体	役割
1 段目	標準ガードレール	AWS Control Tower	AWS 標準の予防コントロール
2 段目	追加ガードレール	設定自動化ツール ( CDK )	標準ガードレールでカバーできない不足分の補完
3 段目	カスタムガードレール	設定自動化ツール ( CDK )	当社固有の要件に合わせた独自の SCP