AWSマルチアカウント統制環境の構築（AWS Control Tower シリーズ vol.1）
1．はじめに
SHIFTのナショナルセキュリティ事業部所属の松尾です。
AWS Control Towerは、私がSHIFTに入社して初案件で利用した思い入れのあるサービスです。そのようなこともあり、AWS Control Towerをシリーズ化し、（ときには他のネタを入れつつ）ブログを連載していこうと思いました。
業務では主に組織やITガバナンス統制に関わり、監査対応や規則類（ポリシー）の作成支援をしています。その経験をAWS Control Towerに絡め、マルチアカウント統制において一般的に悩みそうなことへの対処案をシリーズ化していく予定でいます。
本記事は、以下の方向けとなっています。
（１）個々に管理している複数のAWSアカウントに対して、マルチアカウントの統制管理に変更したいけど何から始めたらよいかわからない方
（２）AWSをはじめて使うけれども、はじめからマルチアカウント統制環境を用意したほうがよいのか？と悩まれている方
AWSシングルアカウント管理での課題点
上記（１）の個々のアカウント管理（以下、「シングルアカウント管理」）からマルチアカウント管理へ切り替える動機としては、例えばシングルアカウント管理において以下のような課題があり、解決したいというものがあると思います。
これらの課題は、AWS Control Towerを利用することによって、まとめて解決することができます。
【課題例】
各AWSアカウントのIAMユーザを一元的に管理したい。
各AWSアカウントのAWSリソースが統制上準拠して利用・管理されているか一元的に把握したい。
各AWSアカウントのマネジメントコンソールやAWS API操作ログを一元的に集約したい。...ほか
2．AWS Control Tower概要
AWS Control Towerを一言で説明すると、AWSマルチアカウント統制環境を構築・管理するためのマネージドサービスになります。
マルチアカウント管理で活躍する主なAWSサービスは以下のとおりです。
AWS Organaizations
複数のAWSアカウントの一元管理することができます。
SCP（Service Control Policy）をOU（組織単位）に適用し、その配下のAWSアカウントに対してAWSリソースへの操作を制御します。なお、SCPはAWS Control Towerでは、AWSリソースの設定が反映される前に操作を制限する機能であることから、『予防的ガードレール』と呼ばれます。
マスタアカウントで各AWSアカウントの請求情報を一元的に閲覧することができます。
AWS CloudFormation
IaC（Infrastructure As Code）の機能であり、テンプレートをもとにAWSクラウド基盤の構築を自動化することができます。
AWS Control Towerでは、マスタアカウントのStackSetsを共通内容として統制下のAWSアカウントに展開します。
AWS Service Catalog
AWS CloudFormationと連携して、セルフサービスでリソースを展開するための仕組みとポータルを構築することができます。
AWS Control Towerでは、別名「Account Factory」と呼ばれ、AWS Control Towerのランディングゾーンに配置する、任意のAWSアカウントの登録管理で利用されます。
AWS IAM Identity Center
AWS Organaizations、Directory Serviceと連携し、AWS IAM Identity Centerで管理されるユーザー（※）を作成し、AWSアカウントのマネジメントコンソールにログインすることができます。
（※）ここでのユーザーは別機能のIAMで管理されるIAMユーザーとは別で、「IAM Identity Centerワークフォースユーザー」と呼ばれます。
AWS CloudTrail
マネジメントコンソールやAWS APIの操作ログを取得し、Amazon S3へログファイルを保存します。
AWS Control Towerでは、ログ管理専用のAWSアカウント（Log Archive）が所有するS3バケットに対して、AWS Control Towerのランディングゾーン上の全AWSアカウントの操作ログファイルを集約し、一元管理することができます。
AWS Config
AWSリソースの構成管理を自動管理し、「誰が」「いつ」「何をしたか」自動的かつ継続的に記録することができます。
Config Rulesを利用すると、AWSクラウド基盤で準拠すべきルールを設定でき、ルールの準拠状況を継続的にチェックすることができます。
Config Rulesには、AWS管理のマネージドルールとカスタマイズ型のユーザルールがありますが、AWS Control Towerでは、マネージドルールを利用します。なお、Config RulesはAWS Control Towerでは、AWSリソースの設定反映後にルール準拠の違反を検知する機能であることから、『発見的ガードレール』と呼ばれます。
3．AWS Control Towerの初期ランディングゾーン構築
ランディングゾーンはAWS Control TowerのGA前からある用語であることからもAWS Control Towerが無くても構築可能ですが、AWS利用者側でAWS CloudFormationのIaCなどを設計する必要があるため、大変です。AWS Control Towerを利用することにより、ランディングゾーンをマネージドで容易に構築可能となります。
ランディングゾーンは、スケーラブルで安全な、適切に設計されたマルチアカウント AWS 環境です。これは、組織がセキュリティおよびインフラストラクチャ環境に自信を持ってワークロードとアプリケーションを迅速に起動してデプロイできる出発点です。ランディングゾーン構築には、組織の成長と将来のビジネス目標に応じて、アカウント構造、ネットワーク、セキュリティ、アクセス管理に関する技術的およびビジネス上の意思決定を行う必要があります。
AWS Control Towerで初期ランディングゾーンの構築について、画面遷移をまとめた記事はなかなかないと思いますので、以下にまとめてみます。
初期ランディングゾーン構築時は、マスタアカウント、監査アカウント、ログ管理アカウントの3つのAWSアカウントが必要となります。 事前に3つメールアドレスを用意し、うち1つのマスタアカウントはAWSアカウント登録済の状態にしておきます。このマスタアカウントのマネジメントコンソール経由でAWS Control Towerから初期ランディングゾーンを構築していきます。
初期ランディングゾーン構築手順
以下の手順にあるマネジメントコンソールのキャプチャは、2024年10月27日時点のものとなります。
マスタアカウントにおいて、マネジメントコンソール上でメインのリージョン（AWS Control Towerのホームリージョン）に切り替えた後、AWS Control Towerのメニューを開き、『ランディングゾーンの設定」を押下します。
ホームリージョンを指定します（以下は、「東京リージョン」を指定）。
ホームリージョン以外に、追加の必要なリージョンがあれば指定します。
ホームリージョンに対して、リージョン拒否設定をします（以下は、拒否設定を無効化）。画像の注意書きがあるように、リージョン間での必要なリソース操作が利用不可とならないように注意する必要があります。詳細は以下のブログが参考になると思います。
組織単位（OU）の設定です。Audit（監査アカウント）とLog Archive（ログ管理アカウント）が所属するOU名を決めます。ここでは、デフォルトの「Security OU」のままとします。なお必須OUは、Security OUのほかRoot OUがありますが、今ログインしているマスタアカウント自体であり、設定項目はありません。
初期ランディングゾーン構築時は、任意OUを1つ作成する必要があり、ここではデフォルトの「Sandbox OU」としています。ここで設定したOUは構築後、変更可能です。OU設定後、「次へ」を押下します。
予め用意した2つのメールアドレス（AWSアカウント未登録）を使用して、ログ管理アカウントと監査アカウントの設定をします。管理アカウント枠のメールアドレスは、今ログインしているマスタアカウント自体のものが自動入力されています。
IAM Identity Centerを用いた、AWSアカウントへのアクセス管理方法を選択します。この設定は初期ランディングゾーン構築後に変更可能です。
AWS Control Tower下にあるすべてのAWSアカウントに対して、マネジメントコンソールとAWS API操作ログをログ管理アカウントのS3バケットに集約するため、ここでは「有効」としています。また、当S3バケットでのライフサイクルポリシー（ログ保管期間）を設定します。
AWS Control Towerの管理下にあるアカウントに対してKMSで一括して暗号化します。予めKMS側で暗号鍵を作成しておく必要があり、鍵作成にあたっては以下の記事が参考になります。追加が必要なキーポリシーについては記事内を引用させて頂き、Statement枠に対して以下を追加します。KMS暗号化設定後、「次へ」を押下します。
{
"Sid": "Allow CloudTrail and AWS Config to encrypt/decrypt logs",
"Effect": "Allow",
"Principal": {
"Service": [
"cloudtrail.amazonaws.com",
"config.amazonaws.com"
]
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
今までの設定内容が表示されますので、意図した内容が設定されていることを確認後、同意枠にチェックを入れて「ランディングゾーンの設定」を押下します。
初期ランディングゾーンが構築開始されますので、完了するまで気長に待ちましょう。今回は、残り時間の60分以内には終わりました。
初期ランディングゾーン構築後の様子
初期ランディングゾーン構築後に各AWSアカウントの様子をピックアップして以下に掲載します。
マスタアカウント
まずは、マスタアカウントの様子になります。
ログ管理アカウント（Log Archive）
ログ管理アカウントの様子になります。S3バケットにAWS Control Tower専用のS3バケットが作成されています。
監査アカウント（Audit）
初期ランディングゾーン構築後、監査アカウントのメールアドレスにSNSトピックのサブスクリプションに対する承認要求のメールが届きますので、Confirmしましょう。発見的ガードレール（AWS Config）にかかったときの通知先で利用されます。
監査アカウントの様子になります。AWS ConfigルールとSNSトピックそれぞれにAWS Control Tower専用のリソースが作成されています。
【補足事項】
ログ管理アカウント（Log Archive）と監査アカウント（Audit）のルートユーザーですが、両ユーザーとも初期ランディングゾーン構築経由で作成し、パスワードが未設定のままでマネジメントコンソールへログイン不可であり、初回ログインの際はパスワードリセットをするほかないと思います（ほかに方法があるのだろうか... ）。 ルートユーザーはMFA設定後、利用せずに凍結してしまいましょう。
4．考察（マルチアカウント統制環境はシングルアカウント管理を兼ねる？）
最後に、AWS Control Towerでマルチアカウント統制環境を構築すれば、当環境とは別にシングルアカウント管理をしなくてもよいことになるのか？という問いが出てくるかと思います。
結論から述べますと、AWSのマルチアカウント統制環境内でシングルアカウントライクに管理することが可能です。つまり、AWS Organaizationsにてガードレールを適用しないOU（下図では、「Sandbox OU」）を作成し、ここに本来シングルアカウントで管理したいAWSアカウントを登録します。 これにより、他のOUによるガードレール設定を継承せずに、個々のシングルアカウント内でSCP、Config Rulesなどの設定を完結することができます。
一般的に企業では、中央で情報統制をとる組織（以下、便宜上「情報システム部」）があると思います。もし情報システム部が経営層などの上層部からAWSの統制管理を委任されているようであれば、マルチアカウント統制管理がやりやすいでしょう。一方で、AWSの管理を中央管理ではなく個々の組織で実施する方針であったり、企業として一部のAWSアカウント管理においては個別組織の責任でスピーディーな運用としたい理由などから中央管理から外したい場合は、シングルアカウント管理が望ましいです。
執筆者プロフィール：松尾光敏
過去にアプリケーション開発・基盤構築を経て、いまはコンサルとしてメインクライアントの官公庁案件のほか、社内AWS CCoEに関わっています。最近は週末に、コンサルをするための体力づくりと歳による体力低下を補うために趣味のサイクリングをまたするようになりました。
■保有資格
・AWS認定全冠（2023/2024 Japan AWS All Certifications Engineers）
・Azure Solutions Architect Expert
・Google Cloud Professional Cloud Architect
・CISSP
・CISA
・PMP
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
SHIFTのサービスについて（サービスサイト）
SHIFTの導入事例
お役立ち資料はこちら
SHIFTの採用情報はこちら