この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、大前です。
Control Tower に激アツなアップデートがありましたので紹介させていただきます。
どんなアップデートか
アップデートとしては単純で、Control Tower 利用時に OU を入れ子構造にする事が出来る 様になりました。 「OU を入れ子構造にする」とは、以下の様に OU の中にさらに OU を作成することができる、という意味合いです。
Root
∟ hogehogeOU
∟ fugafugaOU
∟ barbarOU今までは Control Tower で入れ子構造の OU が使えなかった制限があったため、Root 直下のフラットな OU 構成しか使う事が出来ませんでした。今回のアップデートにより、Control Tower を利用しても、Organizations のみを利用している場合と同様に柔軟な OU 設計が出来る様になる点が嬉しいポイントです。
また、Control Tower でネスト OU を利用する際の制限はドキュメントに記載されています。ネストできる OU の階層の最大数が 5 だったりする事から、基本的には Organizations に従った制限になっている様に見えます。
・OUは、ルートの下で最大5階層までネストすることができます。
・対象となるOUの下に入れ子になったOUは、個別に登録または再登録する必要がある。
・対象となるOUが階層のレベル2以下にある場合、つまりトップレベルのOUではない場合、上位のOUで有効になっている予防的ガードレールが、このOUとその下のすべてのOUに自動的に適用される。
・OU登録の失敗は、階層ツリーを伝搬しません。ネストしたOUの状態の詳細は、親のOUの詳細ページで確認できます。
・OU登録の失敗は、階層ツリーの下に伝播しません。
・AWS Control Towerは、新規または既存のアカウントのVPC設定を変更しません。
（DeepL 翻訳）
アップデートとしては OU を入れ子に出来る様になったというシンプルな内容ですが、ガードレールなど、Control Tower 独自の機能への影響や制限などを実際に触ってみながら確認してみたいと思います。
最初にまとめ
- Control Tower 側から OU を追加するときに親 OU が選択できる様に
- Organizations 側で作成した OU を登録する事も可能だが、子 OU もまとめて登録してくれるわけではない
- ガードレールは種類によって子 OU への継承の有無が異なる
- 予防的ガードレールは継承
- 検知的ガードレールは継承しないため、子 OU 側で個別に有効化が必要
やってみた
Control Tower で子 OU を作ってみる
まずはシンプルにアップデートを実感するべく、Control Tower を使って子 OU を作ってみます。
Control Tower > 組織単位 から「OU の追加」を選択すると、親 OU という項目が追加されている事がわかります。
まずは Root 直下の OU を作りたいので、親 OU には "Root" を指定し、「ParentsOU」という OU を作成しました。
続いて、作成した ParentsOU を親 OU として「ChildOU」を作成
さらに、ChildOU を親 OU として「GrandchildOU」を作成しました。
OU の階層としては以下のイメージになります。
Root
∟ ParentsOU
∟ ChildOU
∟ GrandchildOUControl Tower のコンソールは下記の様な表示になります。親組織単位 列で親 OU が確認できる事がわかります。
SecurityOU（旧CoreOU）配下には子 OU は作成できない
ドキュメントにも記載がありますが、Control Tower が作成する SecurityOU（旧CoreOU）配下には子 OU を作成することはできませんので注意しましょう。
Considerations for nested OU registration - AWS Control Tower
コア OU（Security OU）の下に OU を登録することはできません。 （DeepL 翻訳）
コンソールだと、親 OU の候補としてそもそも SecurityOU は除かれている事も確認できます。
Organizations で作成された OU を Control Tower で取り込んでみる
Control Tower は Organizations を前提として利用するサービスですので、Organizations 側で作成した OU を Control Tower 配下に登録したい時もあるかと思いますのでこちらもやってみます。
Organizations 側の操作になるので説明は省きますが、事前準備として、Organizations 側で入れ子の OU を用意しました。OU 名の先頭に ”Org” がついているものが用意した OU です。
Root
∟ OrgParentsOU
∟ OrgChildOU
∟ OrgGrandchildOUControl Tower のコンソール側で確認すると、Organizations で用意した OU は全て状態が "未登録" である事がわかります。
それでは、この Organizations 側で作成した入れ子 OU を Control Tower に登録してみます。
Control Tower の画面で一番上の親である "OrgParentsOU" を選択し、「OU を登録」をクリックします。
OU の登録画面に進みますが、以下の注釈が追加されている事が確認できます。
登録する組織単位 OrgParentsOU と関連付けられているアカウントを選択しました。この OU の下にあるネストされた OU は、個別に登録する必要があります。上位の OU で有効になっている Detective ガードレールは、この OU によって継承されません。これらは個別に有効にする必要があります。
この注釈内のポイントを整理すると、以下の通りとなります。
- ネストされた OU を取り込む場合、子 OU は個別に Control Tower に登録する必要がある
- 親 OU で Detective （検出）ガードレールが有効化されていても、子 OU には継承されないため個別に有効化が必要
ガードレールについてはタイプが「予防」か「検出」かで挙動が異なり、注意すべき点としては 「検出」のガードレールは継承されない 点です。
これはドキュメントにも記載があります。
Nested OUs in AWS Control Tower - AWS Control Tower
登録済みのOUでガードレールを有効にした場合、予防的ガードレールと検知的ガードレールでは動作が異なります。
予防的ガードレール
予防的ガードレールは、ネストされた OU に適用されます。
必須の予防的ガードレールは、OU およびそのネストされた OU の下にあるすべてのアカウントに適用されます。
予防的ガードレールは、対象となるOUの下に入れ子になっているすべてのアカウントやOUに影響を与えますが、それらのアカウントやOUが登録されていない場合もあります。
検出型ガードレール
ネストした OU は、ディテクティブ ガードレールを自動的に継承しません。
ディテクティブ ガードレールは、ランディング ゾーンのオペレーティング リージョンに登録されているアカウントにのみ展開されます。
ちなみ、ガードレール一覧画面では「継承元」やその状態が確認できる様になっていました。
上記の仕様を頭に入れつつ、「OU の登録」を続けます。
OU の登録が完了し、再度 Control Tower のコンソールを確認すると指定した親 OU（OrgParentsOU）のみ "登録済み" となり、その子 OU である "OrgChildOU"、"OrgGrandchildOU" については "未登録" のままである事が確認できます。
これは、上記に記載した仕様である 「ネストされた OU を取り込む場合、子 OU は個別に Control Tower に登録する必要がある」 の通りである事がわかります。階層構造の OU を現状利用していて、それを Control Tower に持ってきたい場合、現状は各 OU（アカウントを含む）をそれぞれ Control Tower に登録する必要がありそうです。
おわりに
Control Tower で入れ子構造の OU が利用できる様になりました。
入れ子 OU ができない仕様は Control Tower を利用する際の大きな制約として今まで存在していましたが、これが解消されたということで Control Tower をより活用しやすくなったのではないでしょうか。
ただ、本文中に記載した通り、現状は既存の入れ子構造をまるっと Control Tower に登録する事はできず、一つ一つ持ってくる作業が必要になりそうです。また、ガードレールも検知的ガードレールは継承されない点にご注意ください。
以上、AWS 事業本部の大前でした。
3
