AWS Control Tower のランディングゾーンを「ネストされた OU 機能」で整理する

AWS Control Tower は AWS ベストプラクティスに従ったランディングゾーンと利用する AWS アカウントを、お客様に代わってセットアップ、管理する機能を提供します。AWS Control Tower は、複数の AWS サービス (AWS Organizations, AWS CloudFormation StackSets, Amazon S3, AWS IAM Identity Center, AWS Config, AWS CloudTrail) をオーケストレーションして 30 分以内にランディングゾーンを構築し、ベストプラクティスを実現するためのコントロール (旧ガードレール) を設定します。AWS Control Tower で「ネストされた組織単位 (OU) 」のサポートがリリースされたことで、効率的なワークロード管理を最適化することができる「AWS Organizations における組織単位のベストプラクティス」を実装できるようになりました。

「ネストされた OU 機能」により、ワークロード、チーム、または構築予定のシステムに基づいてグループ化した AWS アカウントに共通のセキュリティポリシーを適用できます。AWS のベストプラクティスに従い、かつ運用負荷を削減するために、新しい「ネストされた OU 機能」を使用して AWS Control Tower で Organizations を構築するためのガイダンスをこのブログでは提供します。

AWS アカウントを使用すると、リソースを自然に分離できます。さらに AWS アカウントを OU に配置し、コントロールを OU に適用することで、AWS アカウントをユニットまたはサブユニットにグループ化した上で、そのグループの単位である OU 毎にコントロールを適用できるようになります。「Organizing AWS Environments Using Multiple Accounts (マルチアカウント利用時の AWS 環境の組織化) ホワイトペーパー」には、OU の構成パターンがいくつか示されています。例えば、「関連するワークロード別」、「ポリシー要件別」、「ビジネスユニット別」などです。さらに、「ネストされた OU 機能」によりソフトウェア開発ライフサイクルの段階 (SDLC) を反映させ、運用前と本番用で AWS アカウントを分けることを推奨しています。AWS Control Tower の「ネストされた OU 機能」のサポートにより、これらのベストプラクティスとビジネスニーズに合わせてランディングゾーンを整理できるようになりました。

AWS Control Tower を使用する際に、AWS アカウントの数が数百に達する OU がある場合は、さらにネストされた OU を追加することをお勧めします。AWS Control Tower は、コントロールの有効化、AWS アカウントの一括登録、ドリフトの修正、ランディングゾーンの修復など、ほとんどのアクションが OU 単位で動作します。OU における AWS アカウントの数を制限することで、「影響を受ける AWS アカウントに関する運用リスク許容度」と、「OU と AWS アカウントを最新の状態に保つための運用負荷」のバランスを保つことができます。この機能の詳細については、以下のセクションで説明します。

拡大への備え

AWS Control Tower を使い始めたばかりの場合は、「Basic organization (基本的な組織)」または「Advanced organization (高度化した組織)」をお勧めします。AWS Control Tower は、ランディングゾーンを初めて設定したときに、基盤である「Security」OU と実験用の「Sandbox」OU でベースとなる構成を作成します。AWS Control Tower を既存の組織に拡張する場合は、ベストプラクティスに合わせて OU を登録した上で、そのランディングゾーンに AWS アカウントを移行してください。基本的な構成を設定することで、組織をどのように拡張していくかを検討できます。

AWS アカウントの構成

次に、OU 毎の AWS アカウント拡大計画を決定します。ワークロード、構築予定のシステム、またはテスト利用など、想定できる AWS アカウント作成の契機があるのではないでしょうか。それらの想定と対応するロードマップを参考にして、OU 毎に作成する AWS アカウントの数を予測してください。

ネストされた OU あたりの AWS アカウント数が数百から数千になると予測する場合は、パーティション OU を使用して「運用リスクと運用負荷のバランス」を取る必要があります。AWS Control Tower は、 OU に対して統制の設定をするアクションが行えます。このアクションを実行すると、OU に属するそれぞれの AWS アカウントにリソースが実装されます。OU に対して AWS アカウント数が多いほど、OU へのアクションを実行する時間が長くなります。

“Workload” や “Sandbox” の OU など、何百もの AWS アカウントが予想される OU は、さらに OU を分割することを推奨します。例えばサービス用システム、アプリケーション、および個々のチームのテスト用 AWS アカウントをホストしているような OU は、チームやアプリケーションの成長に合わせて時間の経過とともに拡張されます。OU 毎の AWS アカウント数上限を固定することで、アクションの所要時間を予測できるようになり、「運用リスクと運用負荷のバランス」を取ることができます。以下の図はこれを示しています。”Workload” OU には “Partition_1”, “Partition_2”, “Partition_3” の OU が含まれ、それぞれに最大 100 の AWS アカウントが含まれています。各パーティションの AWS アカウント数が上限に達したら、それ以降のワークロード用 AWS アカウントを紐づけるための新しいパーティション OU を作成します。ネストされた OU を追加することで、AWS Control Tower の変更を環境全体に均一に低レイテンシーで適用できます。

Organization へのセキュリティポリシーの適用

AWS Control Tower には、セキュリティポリシーの意図を表現するために、予防用と検出用のコントロールが用意されています。予防コントロールを有効にすると、AWS Organizations のサービスコントロールポリシー (SCP) を使用して違反作業が禁止されるため、コンプライアンスが保証されます。予防コントロールは OU 階層の下位に継承されます。つまりこのセキュリティポリシーはコントロールが有効になっている OU だけでなく、その配下の OU に属する AWS アカウントも対象です。一方で、ランディングゾーンの管理者は AWS Config Rules による検出コントロールを使用して、セキュリティポリシーの遵守状況を確認することができます。たとえば、「 S3 パブリックアクセスが有効になっているか」といった検出などです。予防コントロールとは異なり、検出コントロールは OU 階層の上位のコントロールを継承しません。

予防コントロールは可能な限り上位の OU で有効にする一方で、監視しなければいけない全ての OU で検出コントロールを有効にすることを考える必要があります。予防コントロールを可能な限り上位の OU に配置すると、対象となるネストされた OU のスコープが大きくなるので、SCP のメンテナンスを行いやすくなります。SCP の継承について詳しくは、AWS Organizations のドキュメントをご覧ください。対して検出コントロールは継承されません。監視するすべての OU で検出コントロールを有効にする必要があります。

結論

AWS Control Tower にて「ネストされた OU 機能」がサポートされたことで、AWS のベストプラクティスに従った OU の構成で AWS アカウントを整理できるようになりました。このブログでは「運用リスクと運用負荷のバランス」を取るために、AWS Control Tower のランディングゾーンでネストされた OU であるパーティション OU を追加する推奨事項についても説明しました。細かく SCP をメンテナンスするために、OU 階層の上位で予防コントロールを有効にすることが推奨されます。一方、検出コントロールは AWS アカウントが直接属する全ての OU で有効にする必要があります。このガイダンスは、セキュリティポリシー要件を順守することを維持したまま、ランディングゾーンを構成および拡大する際に役に立つはずです。

翻訳はプロフェッショナルサービス本部の須田が担当しました。原文はこちらです。

著者について：