AWS Control Tower の Security OU にメンバーアカウントを配置してみた

こんにちは、クラウド事業本部コンサルティング部のいたくらです。

はじめに

AWS Control Tower の Security OU は、統合アカウント（Audit / Log Archive アカウント）を配置するための OU です。
では、Security OU にメンバーアカウントを配置するとどうなるのでしょうか？ 実際に検証してみました。
なお、本記事の検証はランディングゾーン（LZ）バージョン 4.0、以下のランディングゾーン設定で実施しています。

三行まとめ

• Security OU にメンバーアカウントを移動してもベースラインは適用されない
• 一方、コントロールは Security OU から継承される
• Security OU は統合アカウント（Audit / Log Archive アカウント）専用として使用することが推奨されそう

前提知識：Security OU とは

Security OU は、AWS Control Tower の統合アカウントを配置するための OU です。

LZ 4.0 では、統合アカウント（integration accounts）が配置される OU が「Security OU」として機能します。

The OU with the service integration accounts will be the designated Security OU.
引用：Key changes - AWS Control Tower

前提知識：Security OU のコントロールとベースライン

コントロールの制限は LZ 4.0 で撤廃

LZ 3.3 以下では、Security OU に対して特定のコントロールを有効にできない制限がありましたが、LZ 4.0 ではこの制限が撤廃されました。

For customers on LZ v4.0: There is no longer a Security OU managed by AWS Control Tower so restrictions below do not apply.
引用：Exception to controls for the Security OU - AWS Control Tower

ベースラインの制限は LZ 4.0 でも継続

一方、ベースラインについては LZ 4.0 でも制限が継続しています。

The AWS Control Tower Baseline and the AWS Config Baseline are not applicable to the Security OU and integration accounts.

引用：Key changes - AWS Control Tower

ベースラインの詳細については、以下のブログをご参照ください。
https://dev.classmethod.jp/articles/202601-control-tower-baseline-status-invest/

検証してみた

ということで、Security OU にメンバーアカウントを配置するとどうなるか検証してみました。

検証結果

Security OU 配下にメンバーアカウントを移動すると、以下の状態になりました。
（※ Aggregator = Audit アカウントです）

• メンバーアカウント（itkr3_mem01）の「Control status = Controls enabled」と表示される
• しかし「AWS Control Tower baseline status = 有効になっていません」と表示される

Security OU を登録しようとしても登録できない

Security OU の詳細画面を確認すると、通常の OU にはある「アクション」ボタンが存在しません。

そのため、メンバーアカウントを CT に登録するために Security OU を Control Tower に登録（再登録）する操作ができません。

メンバーアカウントを直接登録しようとしても Security OU を選択できない

メンバーアカウントを直接 Control Tower に登録しようとしても、組織単位の選択肢に Security OU が表示されません。

Security OU は Control Tower に登録されている OU ですが、メンバーアカウントの登録先としては選択できない仕様のようです。

CLI でベースラインの適用状態を確認

list-enabled-baselines コマンドで、Security OU と Security OU 配下に移動したメンバーアカウントのベースライン適用状態を確認しました。

// Security OU
~ $ aws controltower list-enabled-baselines \
>     --filter targetIdentifiers=arn:aws:organizations::<管理アカウントID>:ou/<組織ID>/<Security OU ID> \
>     --region ap-northeast-1
{
    "enabledBaselines": []
}
~ $

// Security OU 配下に移動したメンバーアカウント
~ $ aws controltower list-enabled-baselines \
>     --filter targetIdentifiers=arn:aws:organizations::<管理アカウントID>:account/<組織ID>/<メンバーアカウントID> \
>     --region ap-northeast-1
{
    "enabledBaselines": []
}
~ $

結果は空でした。つまり、

• Security OU には AWSControlTowerBaseline が適用されていない
• 通常のメンバーアカウントは OU からベースラインを継承するが、継承元がない
• 統合アカウント用のベースラインも適用されない（統合アカウントではないため）
• 結果：ベースラインが何も適用されていない状態

となっています。

ベースラインによって展開されるリソース

ベースラインが適用されると、管理アカウントの CloudFormation StackSets を通じて各アカウントにリソースが展開されます。

以下は統合アカウント（Audit アカウント）に展開された CloudFormation スタックの例です。

StackSet-AWSControlTowerBP-* というプレフィックスのスタックが展開されており、以下のようなリソースが作成されます。

• AWS Config レコーダー、配信チャンネル
• EventBridge Rule、SNS Topic
• Config 用 S3 バケット
• AWSControlTowerExecution ロール など

ですが、Security OU 配下のメンバーアカウントにはベースラインが適用されないため、これらのスタックも展開されません。

コントロールは継承されている

メンバーアカウントで有効になっているコントロールを確認します。

• 「Control status = Controls enabled」
• 「コントロールが有効」には 10 個の予防コントロールが表示
• 各コントロールは「継承済み」と表示されている

つまり、ベースラインとコントロールは独立した概念であることが分かります。

検証結果のまとめ

ということで、結果は以下の通りとなりました。

Security OU 配下のメンバーアカウントは、Control Tower のベースラインによるリソースセットアップが行われないので、Control Tower のガバナンスが効いた状態になりません。
ということで、Security OU は統合アカウント専用の OU として使用することが推奨されそうです。

まとめ

Security OU にメンバーアカウントを配置した場合の挙動を検証しました。

結論として、Security OU は統合アカウント専用の OU として使用することを推奨します。

この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部コンサルティング部のいたくら（@itkr2305）でした！

参考ドキュメント

• Key changes - AWS Control Tower
• Exception to controls for the Security OU - AWS Control Tower