1．はじめに

SHIFTのナショナルセキュリティ事業部所属の松尾です。

本記事は、AWS Control Tower シリーズ vol.3となります。前回までの記事は以下をご参照ください。

本記事では、AWS Control Tower下のAWS Orgnaizationsでの組織単位（OU）（以下、「OU」）の設計について解説し、以下の方向けとなっています。

2．組織単位（OU）とは

AWS Control Towerシリーズ vol.1、2で既にOUは登場していました。OUの説明前にまず開発、本番アカウントなどAWSアカウントを分離することにより実現できることを押さえます。

では、次にAWS OrganaizationsのOUにより実現できることです。下図では、Sandbox OUについては3つのAWSアカウントが所属していることから、OUは、AWSアカウントをグルーピングする機能であることがわかります。AWS Control Towerにおいては、OUによるAWSアカウントのグルーピングとガードレールを組み合わせることによりOU単位でAWSアカウントを束ねて予防的・発見的統制をとることが可能となるわけです。

AWS Organaizationsはほかに一括請求機能があり、AWS Control Towerにおいては、Root OU下にあるすべてのAWSアカウントの請求はマスタアカウントで一括請求される仕組みになっています。

3．組織単位（OU）の設計

OUを設計する上では、各OUの役割を明確にし、各OUに所属するAWSアカウントをOUの役割どおりに機能させることがポイントになります。初期ランディングゾーン構築時のOUは必須OU（Root OU、Security OU）のほか、1つの任意OU（以下は「Sandbox OU」）で構成されます。この状態から組織の特性に合わせて任意OUを設計していくことになります。

まずOU設計をする上で、これさえすれば完璧であるといった型が無いことが前提であることを理解しておく必要があります。つまり、OU設計は組織要件をヒアリングし、最終的に要件にあった形に落とし込む必要があります。とはいえ、AWSがベストプラクティスとして提唱しているOU設計がありますので、これをベースにOU設計を1つ考えてみます。

最小構成（Workloads OU）

AWSで情報システムを運用する上では、開発・本番環境は最低限必要でしょう。一般的に本番環境と開発環境はセキュリティ上、分離することが通例であり、これに倣うと予防的ガードレールの設定など誤操作によるインシデントを防止するために、Prod OUとSLDC OUなどでOUを分離し、セキュリティ境界を設けます。以降はこの最小構成をベースに派生して複数のOUを順に追加していき、1つのOU設計（最終形）を考えてみます。

トレーニング用OU（Sandbox OU）の追加

AWSの初学者のためのトレーニング環境が必要な場合は、Sandbox OUを用意するとよいです。Sandbox OUのガードレールは、基本的に学習制限をかけないように設定しないようにするものとします。

ポリシー検証用OU（Policy Staging OU）の追加

Prod OUなど実運用に影響が出ないように事前にガードレールなどのポリシー設定を検証するために、Policy Staging OUを追加するとよいです。ガードレールやPolicy Staging OUの利用用途についてはvol.2をご参照ください。

利用停止アカウントの分離用OU（Suspended OU）の追加

標題のAWSアカウントの"利用停止"はAWSアカウントの削除（閉鎖）ではなく、運用上、利用せずに有効なAWSアカウントを指します。Suspended OUは、組織改編などOUの構成を見直しの際の一時的なAWSアカウントの避難場所であったり、閉鎖予定のAWSアカウントの待機場所として利用します。また、Suspended OUのガードレール設定については、当OUに所属するAWSアカウントではリソースを操作しないため、基本的に（特に予防的ガードレール一式）を有効化し、操作制限をかけます。

共通リソース管理用OU（Infrastructure OU）の追加

ネットワークなど組織全体で中央管理するためにInfrastructure OUを追加するとよいです。例えばAmazon VPCを当OUで一元的に管理することで、ネットワークCIDRブロックの重複防止につながるなど共通リソース管理の統制をとることが可能となります。

OU最終形（一例）

以上で考えてみたOU最終形となります。Workloads OUが情報システムの運用上、最小構成として必要なため、実質必須OUと見なせば、Workloads OUを主軸とし、これを補完するために他に必要な任意OUを用意することに整理がつきやすくなると思います。なおこの最終形はvol.1で冒頭に記載した、私がSHIFTに入社して初案件で導入した形そのものです。ご参考になれば幸いです。

4．OUの作成

vol.2でもPolicy Statging OUで手順を記載しましたが、上記最終形のOU設計で任意OUを作成してみます。今回は、Root OU＞Wolkloads OU直下にProd OUの作成手順を一例で示します。

AWS Control Towerの左ペイン「組織」から「リソースを作成 - 組織単位を作成」を押下します。

OU名を「Prod」とし、親OUにWorkloads OUを選択して、追加を押下します。

しばらくすると、Prod OUがWorkloads OU直下に作成されます。なおOUの作成時間ですが、OU 内のAWSアカウント数に応じて長くなります（全体のOU構成を維持しながら、OUの追加処理が行われるのと、追加処理中に連続してのOU追加は不可なので納得）。

他の任意OUも同様に作成後、AWS Control Towerの『組織』画面上のOU最終形は以下のとおりになります。「名前」列のフォルダアイコン部がOUとなります。

5．考察（OU設計で組織範囲はどこまで広げるべきか）

vol.1の考察で、AWSのマルチアカウント統制管理においては、中央で情報統制をとる組織（以下、便宜上「情報システム部」）が経営層などの上層部からAWSの統制管理を委任されているケースであれば実現性があることを述べました。組織内でAWSアカウントを利用する組織が限定的であれば、1つのAWS Control Towerを立ちあげてそこで一元的にAWSマルチアカウント統制を図るとよいでしょう。

しかしながら、ホールディングス会社など、いくつもの事業をもつ巨大組織において組織横断的にAWSアカウントを利用するのであれば、情報システム部の中でいくつかのグループに分けつつ、AWS Control Towerを複数立ち上げて運用負荷を分散する必要が出てくるかもしれません。

この場合、運用前に予め、AWS Control Tower毎の責任範囲を利用・運用規定で明確にしておく必要があります。そうもしなければ、AWS Control Tower運用中にトラブルが発生し、その責任が運用側にあったときに異なるAWS Control Towerのシステムオーナー間で責任の拠りどころが不明確となるからです。この場合、システムオーナー同士で責任の落としどころをつける必要があり、決着がなかなかつかないことになります。

私は規則類の作成支援を普段業務で関わっているのもあり、OU設計はこれといった型がない中で、AWSベストプラクティスをベースに顧客要件を具現化するプロセスが個人的に醍醐味です。

次回予告

次回（AWS Control Tower シリーズ vol.4）は、AWS OrganaizationsでのAWSアカウント移管で発生する、あるある課題について記載しようと思います。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO：UnsplashのChantha Pheuypraseuth