Control Towerの細かい仕様（OU単位のリージョン拒否コントロールがSecurity OUで適用出来ない件）

こんにちは、最近お腹周りが気になりだした今野です。

はじめに

みなさん、Control Towerは活用されてますでしょうか？

エンタープライズ企業のアカウント管理部門に所属されている方であればご活用されている方も多いでしょうし、一度は利用を検討したことはあるはずです。

本ブログでは、「OU単位のリージョン拒否コントロールがSecurity OUで適用出来ない」というControl Towerの仕様に焦点を当ててご紹介していきます。*1

前提知識の確認

Security OU

Security OUとは、Control Towerによって自動で作成されるOU（Organizational Unit：組織単位）のことです。*2 このOUの中には、デフォルトで「Log Archive アカウント」と「Audit アカウント」という2つのアカウントが作成されます。Control Tower管理環境において、以下のような役割を持つことが一般的です。

ログの一元管理による証跡保全の強化
中央集権的なセキュリティ監視

リージョン拒否コントロールについて

Control Towerの機能にて指定したリージョン以外のリージョンでの操作を禁止することが出来ます。

Organizations組織全体に適用するか、OUを指定して適用する方法の２パターンがあります。*3

表題の仕様について

表題の仕様については下記のようなお悩みケースの解決に向けた検討の際に考慮する必要があるかと考えております。同様の検討をされる方々のご参考になれば幸いです。

想定しているお悩みケース

想定している読者：エンタープライズ企業のアカウント管理部門
課題：Control Towerを導入したものの、AWS自体は導入前から利用していたため未だControl Tower管理対象に出来ていないアカウントが多い（今後段階的に管理対象のアカウントを増やしていきたい）

お悩みケースの解決に向けて

AWS利用部門に対しControl Towerを活用した統制の一環として、リージョン拒否の適用を検討しているとしましょう。

ただし、このようなケースではOrganizations組織全体にリージョン拒否コントロールを適用してしまうと、既存のワークロード（またはシステム）へ影響がある可能性があります。

そのため、影響調査等を実施し計画的に適用していく必要があると考えるでしょう。

個別アカウント群は個別に影響調査等をした上でWorkloads OUへの移行を検討といったステータスと想定される

OU単位のリージョン拒否コントロールがSecurity OUで適用出来ない件

前段のような検討を経て、OUを指定してリージョン拒否コントロールを適用することとしました。

この時、「OU単位のコントロールがSecurity OUで適用出来ない」ということを考慮しておく必要があります。

Security OUに対し、OU指定のリージョン拒否コントロール（TMULTISERVICEPV1）を適用するとエラーになる

なぜSecurity OUには適用不可なのか？

なぜSecurity OUには適用不可なのか？AWSサポートへ問い合わせたことがありました。回答としては下記の通りでした。

Security OU に含まれる監査アカウトおよびログアーカイブアカウントは、Control Tower が管理するリソースを用いて組織全体の管理を行うことを目的に利用されることを想定されている。また、これらのアカウントはワークロード（またはシステム）のリソースをデプロイおよび管理するために利用されることは想定していない。そのため、組織全体の管理に予期せぬ影響を及ぼす可能性のあるコントロールについては、Security OU には適用できないよう制限されている。 CT.MULTISERVICE.PV.1 についても、上記に該当したために適用が制限されたものとのこと。

代案としては、独自にSCPを作成しSecurity OU に適用する案が考えられます。適用による影響を検証した上でどうしても適用したい場合は検討してみるといいかもしれません。