AWS Control Towerのセットアップ手順と導入時にぶつかる課題
2024年3月25日（月）11時34分 マイナビニュース
●
今回は、AWS Control Towerのセットアップ手順と導入時によく課題となる点について説明します。AWS Control Towerは複数のAWSアカウントをガバナンスを維持する目的で利用されるサービスです。これまで紹介してきたAWS Security HubやAWS IAM Identity Centerなどの複数のAWSサービスを組み合わせてAWSの考えるベストプラクティスに則ったランディングゾーンを構成できます。
昨今、さまざまな企業でAWS Control Towerの導入事例が発表されており、ガバナンスを効かせたAWS環境の提供を考えているケースでは利用を検討されることが多いサービスだと思います。
非常に多くのサービスを組み合わせて実現していることから、検討する事項も多くなりがちです。まずはセットアップ手順から紹介していきます。
想定する構成
Control Towerは委任管理者をサポートしておらず、管理アカウントでしか操作ができません。そのため、これまでに紹介してきたようなセキュリティアカウントなどのメンバーアカウントでの設定ができません。これ以降はすべて管理アカウントでの操作となります。
管理アカウントの設定
（1）管理アカウントにログインし、Control Towerのメニューを表示し、「ランディングゾーンの設定」ボタンをクリックします。
もし、以下のようにセットアップする準備ができていないというメッセージが表示された場合は別途対処が必要です。
公式ドキュメントに事前チェックに関する要件が記載されているので、要件を満たしているかを確認ください。上の画面が出てしまう理由としては、AWS CloudTrailおよびAWS ConfigのOrganizations連携の設定されており、信頼されたアクセスが有効化されていることがよくあります。Organizationsのサービスの一覧から、CloudTrailおよびConfigが以下のように「アクセス有効」となっていると、前提条件を満たしていません。
各サービスのリンクを選択の上、無効化処理を行います。もし、委任管理者の設定を行っている場合は、委任管理者の削除が必要です。CloudTrailはマネジメントコンソールから委任管理者を削除できますが、ConfigはAWS CLIでの操作が必要となるので、注意してください。
※本稿執筆時点で、Configの委任管理者の削除手順について公式ドキュメントが整備されていないため、上記のトラブルシュート内で紹介されている「aws organizations deregister-delegated-administrator -account-id 委任管理者のAWSアカウントID -service-principal config.amazonaws.com」コマンドの実行によって委任管理者の削除を行ってください。
最終的に、以下のように「アクセス無効」状態となっていることを確認します。
（2）事前チェックを通過すると次の画像が表示されます。
Control Towerのホームリージョンを選択します。加えて、Control Towerによって管理したいリージョンを選択します。ここで選択されたリージョンにはControl Towerによって、ガバナンス維持のために必要なAWSリソースの作成が行われます。
（3）特定のリージョン以外の利用を禁止するリージョン拒否を設定したい場合は、ここで有効を選択します。もし特定のOU配下のAWSアカウントのみを対象にリージョン拒否したい場合は、この機能は利用せずに、OUに適用されるリージョン拒否コントロールを利用することをおすすめします。本手順ではこの機能を利用しないこととし、「次へ」ボタンをクリックします。
（4）続いて、OUの設定を行います。ここでは2つのOUの名前の入力が必要です。基礎となるOUはデフォルトでSecurityという名前が入っており、追加のOUはデフォルトでSandboxという名前が入っています。 基礎となるOUは、ログを集約保管するログアーカイブアカウントやConfigのアグリゲーターが設定される監査アカウントを配置するためのOUです。追加のOUは、AWSアカウント払い出し時の一時的な作業を行う際に配置するOUです。特に変更する必要がないところであるためデフォルト値とし、「次へ」ボタンをクリックします。
（5）次に、自動で作成されるログアーカイブアカウントと監査アカウントのルートアカウントとなるメールアドレスの入力を行います。Organizationsの既存のAWSアカウントを選択することも可能ですが、セットアップの阻害要因となりやすいため、新規アカウントを選択することをおすすめします。入力が完了したら、「次へ」ボタンをクリックします。
（6）さらに、AWSアカウントにログインする方法を選択します。IAM Identity Centerを利用することが多いとは思いますが、すでに別の方法でAWSアカウントへのシングルサインオンを実現している場合は、IAM Identity Centerを利用しないことも可能となっています。
（7）CloudTrailおよびConfig記録のS3バケットでのログ保管期間およびそのS3バケットにアクセスされたことを記録するアクセスログの保管期間について入力します。今回は最低限の1年としておきます。
保管するログをCMKを使って暗号化することも可能です。CMKの要件については公式ドキュメントにまとまっています。要件を満たすCMKを選択し、「次へ」ボタンをクリックします。
ちなみに本稿執筆時点では、前回に紹介したaws:SourceOrgIDを利用したキーポリシーとなっていないため、より厳密に制御する場合は以下のキーポリシーとしていただければと思います。
{
"Sid": "Allow Config to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:{リージョン}:{CMKを作成するAWSアカウントID}:key/{CMKのID}",
"Condition": {
"StringEquals": {
"aws:SourceOrgID": "{「o-」から始まるOrganizationID}"
}
}
},
{
"Sid": "Allow CloudTrail to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:{リージョン}:{CMKを作成するAWSアカウントID}:key/{CMKのID}",
"Condition": {
"StringEquals": {
"aws:SourceOrgID": "{「o-」から始まるOrganizationID}",
"aws:SourceArn": "arn:aws:cloudtrail:{リージョン}:{管理アカウントのAWSアカウントID}:trail/aws-controltower-BaselineCloudTrail"
},
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:{管理アカウントのAWSアカウントID}:trail/*"
}
}
}
（8）入力内容を確認の上、「ランディングゾーンの設定」ボタンをクリックします。
（9）ランディングゾーンの設定時に以下のようなエラーが表示される場合があります。その場合は公式ドキュメントのトラブルシューティングを参照し、Configレコーダーやデリバリーチャンネルの削除を実施してください。
どのリージョンが阻害要因になっているかは管理アカウントのCloudFormation Stacksetsで確認が可能ですので、必要に応じて参照ください。
（10）ランディングゾーンの設定に成功すると、次のような画面が表示されます。完了まで1時間程度がかかるかと思います。
●
Control Towerの操作
続いて、Control Towerの操作をいくつか紹介します。まずは、Control Tower管理下のAWSアカウントにログインするユーザーの追加操作を説明します。AWSアカウント設定でIAM Identity Centerを選択している前提とします。
（1）Control Towerの「ユーザーとアクセス」メニューをクリックし、「IAM Identity Centerで表示」ボタンをクリックします。
（2）Control Towerにより、こちらのドキュメントに記載のグループおよび権限セットがIAM Identity Centerに作成されています。AWSアカウントにログインするユーザーを追加する最も簡単な方法は作成されているグループにユーザーを追加することです。しかし、このグループに割り当てられている権限はAdministratorAccess、PowerUserAccess、ReadOnlyAccessといったものがメインで、かなり大雑把に強い権限が与えられています。そのため、実際の運用では業務上必要な権限を検討したうえで、新たに許可セットを作ることになるでしょう。こちらを参考に、新たな許可セットの作成を行ってください。
（3）その後、ユーザーへの許可セットの割り当てまたはグループへの許可セットの割り当てを実施してください。これにより、Control Tower管理下のAWSアカウントへIAM Identity Center経由でアクセスが可能になります。
次に、ランディングゾーンの更新手順を紹介します。ランディングゾーンは定期的に新しいバージョンが提供されるため、最新版のバージョンを適用したい場合は、ランディングゾーンの更新作業を行う必要があります。基本的にAWSのベストプラクティスに基づき、ランディングゾーンはアップデートされるため、原則最新版としておくことが推奨されています。具体的な変更点はリリースノートに記載されますので、アップデート前にご確認いただくとよいでしょう。
（1）手順自体はシンプルで、こちらの手順に従い、ランディングゾーンの更新を行うだけです。初期セットアップ時と同じ程度の時間を要しますので、ご注意ください。
※本稿執筆時点で、最新のランディングゾーンに更新済みのため、更新ボタンがアクティブになりませんが、新しいランディングゾーンが存在する場合は、更新ボタンがアクティブになります。
最後に、新たにControl Tower管理下にAWSアカウントを加えたい場合の手順を紹介します。今回は、以下の画像のようにUsers OUが存在し、その配下にあるAWSアカウントを追加する場合の手順について説明します。
（1）Users OUをの横のチェックボックスを選択した状態で、「組織単位」-「組織単位を登録」をクリックします。
（2）内容を確認し、「OUを登録」ボタンをクリックします。
既存のAWSアカウントを登録する際には、こちらの前提条件を満たしている必要があるので、条件を満たすかを事前に確認ください。
課題となりやすいポイント
実運用時によくある課題となりやすいポイントについて説明します。
（1）Control Towerは委任管理者をサポートしていないため、管理アカウントにログインして操作が必要となりますが、Control Towerの管理者向けに用意されているAWSControlTowerAdminsは、AdministratorAccessが付与されており、あまりにも強い権限となっています。これまでに何度も触れていますが、管理アカウントには請求データが集約されているなどセンシティブな情報が多く含まれるため、このような強い権限で運用するのはおすすめしません。
そのため、デフォルトで用意している許可セットは管理アカウントから削除し、権限を限定した許可セットで運用することを検討ください。しかし、デフォルトで用意している許可セットは削除しても、ランディングゾーンの更新を行うと、復活してしまうという仕様があります。よって、ランディングゾーンの更新は限定したメンバーで実施し、復活した許可セットは再度削除するという運用を検討ください。
（2）Control TowerではAccount FactoryというAWSアカウントの新規払い出し機能が用意されておりますが、AWSアカウントのリセラーによっては、本機能を提供されていない場合があります。本機能を利用したい場合は、事前にリセラーにご確認いただくことをおすすめします。
（3）AWSを初めて利用される方がいきなりControl Towerを導入されるということはなく、ある程度AWSを利用されている方が、セキュリティ上の懸念などを理由にControl Towerを導入されるケースがほとんどかと思います。そうしたケースでは、Control Tower用に新たにOrganizationsを払い出して、そちらでControl Tower環境を用意することなっているでしょう。
その際に課題となるのが、「もともとのOrganizationsにあるAWSアカウントをどうするか？」ということです。Control Tower管理下に置くためには、Configレコーダーやデリバリーチャンネルの削除などいくつかの前提条件を満たす必要があります。また、必須のガードレールが強制的に適用されます。影響はなさそうだとは頭ではわかっていても、本番稼働しているシステムが動いているAWSアカウントでのこうした変更は精神的なハードルとなってしまい、すべてのAWSアカウントをControl Tower管理下に置けないことも実案件では多いです。
こうした際は、無理してすべてのAWSアカウントをControl Tower管理下とはせずに、Control TowerがないOrganizationsではSecurity HubやGuardDutyなどを組み合わせてセキュリティレベルを高めるという対応をとってもよいでしょう。 すでにControl Towerよりも自社の要件に基づくセキュリティガードレールを適用済みの環境があるのであれば、無理にControl Towerを利用することもありません。ダブルスタンダードとなり、違和感はあるかもしれませんが、どちらのOrganizationsに所属させるかというルールがきちんと整備されていれば十分でないかと私は考えています。
まとめ
今回は、Control TowerのセットアップステップやControl Towerの利用時に課題となりやすいポイントについても紹介しました。本記事がControl Towerの管理にお役に立てば幸いです。
奥村康晃 おくむらやすあき NTTデータ入社以来、クラウドサービスのAPIを連携させることで効率的な管理を可能とするクラウド管理プラットフォームの開発に従事。現在では、クラウド導入の技術コンサルや組織での技術戦略立案にも携わる。 2023 Japan AWS Ambassadors受賞 この著者の記事一覧はこちら
今回は、AWS Control Towerのセットアップ手順と導入時によく課題となる点について説明します。AWS Control Towerは複数のAWSアカウントをガバナンスを維持する目的で利用されるサービスです。これまで紹介してきたAWS Security HubやAWS IAM Identity Centerなどの複数のAWSサービスを組み合わせてAWSの考えるベストプラクティスに則ったランディングゾーンを構成できます。
昨今、さまざまな企業でAWS Control Towerの導入事例が発表されており、ガバナンスを効かせたAWS環境の提供を考えているケースでは利用を検討されることが多いサービスだと思います。
非常に多くのサービスを組み合わせて実現していることから、検討する事項も多くなりがちです。まずはセットアップ手順から紹介していきます。
想定する構成
Control Towerは委任管理者をサポートしておらず、管理アカウントでしか操作ができません。そのため、これまでに紹介してきたようなセキュリティアカウントなどのメンバーアカウントでの設定ができません。これ以降はすべて管理アカウントでの操作となります。
管理アカウントの設定
（1）管理アカウントにログインし、Control Towerのメニューを表示し、「ランディングゾーンの設定」ボタンをクリックします。
もし、以下のようにセットアップする準備ができていないというメッセージが表示された場合は別途対処が必要です。
公式ドキュメントに事前チェックに関する要件が記載されているので、要件を満たしているかを確認ください。上の画面が出てしまう理由としては、AWS CloudTrailおよびAWS ConfigのOrganizations連携の設定されており、信頼されたアクセスが有効化されていることがよくあります。Organizationsのサービスの一覧から、CloudTrailおよびConfigが以下のように「アクセス有効」となっていると、前提条件を満たしていません。
各サービスのリンクを選択の上、無効化処理を行います。もし、委任管理者の設定を行っている場合は、委任管理者の削除が必要です。CloudTrailはマネジメントコンソールから委任管理者を削除できますが、ConfigはAWS CLIでの操作が必要となるので、注意してください。
※本稿執筆時点で、Configの委任管理者の削除手順について公式ドキュメントが整備されていないため、上記のトラブルシュート内で紹介されている「aws organizations deregister-delegated-administrator -account-id 委任管理者のAWSアカウントID -service-principal config.amazonaws.com」コマンドの実行によって委任管理者の削除を行ってください。
最終的に、以下のように「アクセス無効」状態となっていることを確認します。
（2）事前チェックを通過すると次の画像が表示されます。
Control Towerのホームリージョンを選択します。加えて、Control Towerによって管理したいリージョンを選択します。ここで選択されたリージョンにはControl Towerによって、ガバナンス維持のために必要なAWSリソースの作成が行われます。
（3）特定のリージョン以外の利用を禁止するリージョン拒否を設定したい場合は、ここで有効を選択します。もし特定のOU配下のAWSアカウントのみを対象にリージョン拒否したい場合は、この機能は利用せずに、OUに適用されるリージョン拒否コントロールを利用することをおすすめします。本手順ではこの機能を利用しないこととし、「次へ」ボタンをクリックします。
（4）続いて、OUの設定を行います。ここでは2つのOUの名前の入力が必要です。基礎となるOUはデフォルトでSecurityという名前が入っており、追加のOUはデフォルトでSandboxという名前が入っています。 基礎となるOUは、ログを集約保管するログアーカイブアカウントやConfigのアグリゲーターが設定される監査アカウントを配置するためのOUです。追加のOUは、AWSアカウント払い出し時の一時的な作業を行う際に配置するOUです。特に変更する必要がないところであるためデフォルト値とし、「次へ」ボタンをクリックします。
（5）次に、自動で作成されるログアーカイブアカウントと監査アカウントのルートアカウントとなるメールアドレスの入力を行います。Organizationsの既存のAWSアカウントを選択することも可能ですが、セットアップの阻害要因となりやすいため、新規アカウントを選択することをおすすめします。入力が完了したら、「次へ」ボタンをクリックします。
（6）さらに、AWSアカウントにログインする方法を選択します。IAM Identity Centerを利用することが多いとは思いますが、すでに別の方法でAWSアカウントへのシングルサインオンを実現している場合は、IAM Identity Centerを利用しないことも可能となっています。
（7）CloudTrailおよびConfig記録のS3バケットでのログ保管期間およびそのS3バケットにアクセスされたことを記録するアクセスログの保管期間について入力します。今回は最低限の1年としておきます。
保管するログをCMKを使って暗号化することも可能です。CMKの要件については公式ドキュメントにまとまっています。要件を満たすCMKを選択し、「次へ」ボタンをクリックします。
ちなみに本稿執筆時点では、前回に紹介したaws:SourceOrgIDを利用したキーポリシーとなっていないため、より厳密に制御する場合は以下のキーポリシーとしていただければと思います。
{
"Sid": "Allow Config to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:{リージョン}:{CMKを作成するAWSアカウントID}:key/{CMKのID}",
"Condition": {
"StringEquals": {
"aws:SourceOrgID": "{「o-」から始まるOrganizationID}"
}
}
},
{
"Sid": "Allow CloudTrail to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:{リージョン}:{CMKを作成するAWSアカウントID}:key/{CMKのID}",
"Condition": {
"StringEquals": {
"aws:SourceOrgID": "{「o-」から始まるOrganizationID}",
"aws:SourceArn": "arn:aws:cloudtrail:{リージョン}:{管理アカウントのAWSアカウントID}:trail/aws-controltower-BaselineCloudTrail"
},
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:{管理アカウントのAWSアカウントID}:trail/*"
}
}
}
（8）入力内容を確認の上、「ランディングゾーンの設定」ボタンをクリックします。
（9）ランディングゾーンの設定時に以下のようなエラーが表示される場合があります。その場合は公式ドキュメントのトラブルシューティングを参照し、Configレコーダーやデリバリーチャンネルの削除を実施してください。
どのリージョンが阻害要因になっているかは管理アカウントのCloudFormation Stacksetsで確認が可能ですので、必要に応じて参照ください。
（10）ランディングゾーンの設定に成功すると、次のような画面が表示されます。完了まで1時間程度がかかるかと思います。
●
Control Towerの操作
続いて、Control Towerの操作をいくつか紹介します。まずは、Control Tower管理下のAWSアカウントにログインするユーザーの追加操作を説明します。AWSアカウント設定でIAM Identity Centerを選択している前提とします。
（1）Control Towerの「ユーザーとアクセス」メニューをクリックし、「IAM Identity Centerで表示」ボタンをクリックします。
（2）Control Towerにより、こちらのドキュメントに記載のグループおよび権限セットがIAM Identity Centerに作成されています。AWSアカウントにログインするユーザーを追加する最も簡単な方法は作成されているグループにユーザーを追加することです。しかし、このグループに割り当てられている権限はAdministratorAccess、PowerUserAccess、ReadOnlyAccessといったものがメインで、かなり大雑把に強い権限が与えられています。そのため、実際の運用では業務上必要な権限を検討したうえで、新たに許可セットを作ることになるでしょう。こちらを参考に、新たな許可セットの作成を行ってください。
（3）その後、ユーザーへの許可セットの割り当てまたはグループへの許可セットの割り当てを実施してください。これにより、Control Tower管理下のAWSアカウントへIAM Identity Center経由でアクセスが可能になります。
次に、ランディングゾーンの更新手順を紹介します。ランディングゾーンは定期的に新しいバージョンが提供されるため、最新版のバージョンを適用したい場合は、ランディングゾーンの更新作業を行う必要があります。基本的にAWSのベストプラクティスに基づき、ランディングゾーンはアップデートされるため、原則最新版としておくことが推奨されています。具体的な変更点はリリースノートに記載されますので、アップデート前にご確認いただくとよいでしょう。
（1）手順自体はシンプルで、こちらの手順に従い、ランディングゾーンの更新を行うだけです。初期セットアップ時と同じ程度の時間を要しますので、ご注意ください。
※本稿執筆時点で、最新のランディングゾーンに更新済みのため、更新ボタンがアクティブになりませんが、新しいランディングゾーンが存在する場合は、更新ボタンがアクティブになります。
最後に、新たにControl Tower管理下にAWSアカウントを加えたい場合の手順を紹介します。今回は、以下の画像のようにUsers OUが存在し、その配下にあるAWSアカウントを追加する場合の手順について説明します。
（1）Users OUをの横のチェックボックスを選択した状態で、「組織単位」-「組織単位を登録」をクリックします。
（2）内容を確認し、「OUを登録」ボタンをクリックします。
既存のAWSアカウントを登録する際には、こちらの前提条件を満たしている必要があるので、条件を満たすかを事前に確認ください。
課題となりやすいポイント
実運用時によくある課題となりやすいポイントについて説明します。
（1）Control Towerは委任管理者をサポートしていないため、管理アカウントにログインして操作が必要となりますが、Control Towerの管理者向けに用意されているAWSControlTowerAdminsは、AdministratorAccessが付与されており、あまりにも強い権限となっています。これまでに何度も触れていますが、管理アカウントには請求データが集約されているなどセンシティブな情報が多く含まれるため、このような強い権限で運用するのはおすすめしません。
そのため、デフォルトで用意している許可セットは管理アカウントから削除し、権限を限定した許可セットで運用することを検討ください。しかし、デフォルトで用意している許可セットは削除しても、ランディングゾーンの更新を行うと、復活してしまうという仕様があります。よって、ランディングゾーンの更新は限定したメンバーで実施し、復活した許可セットは再度削除するという運用を検討ください。
（2）Control TowerではAccount FactoryというAWSアカウントの新規払い出し機能が用意されておりますが、AWSアカウントのリセラーによっては、本機能を提供されていない場合があります。本機能を利用したい場合は、事前にリセラーにご確認いただくことをおすすめします。
（3）AWSを初めて利用される方がいきなりControl Towerを導入されるということはなく、ある程度AWSを利用されている方が、セキュリティ上の懸念などを理由にControl Towerを導入されるケースがほとんどかと思います。そうしたケースでは、Control Tower用に新たにOrganizationsを払い出して、そちらでControl Tower環境を用意することなっているでしょう。
その際に課題となるのが、「もともとのOrganizationsにあるAWSアカウントをどうするか？」ということです。Control Tower管理下に置くためには、Configレコーダーやデリバリーチャンネルの削除などいくつかの前提条件を満たす必要があります。また、必須のガードレールが強制的に適用されます。影響はなさそうだとは頭ではわかっていても、本番稼働しているシステムが動いているAWSアカウントでのこうした変更は精神的なハードルとなってしまい、すべてのAWSアカウントをControl Tower管理下に置けないことも実案件では多いです。
こうした際は、無理してすべてのAWSアカウントをControl Tower管理下とはせずに、Control TowerがないOrganizationsではSecurity HubやGuardDutyなどを組み合わせてセキュリティレベルを高めるという対応をとってもよいでしょう。 すでにControl Towerよりも自社の要件に基づくセキュリティガードレールを適用済みの環境があるのであれば、無理にControl Towerを利用することもありません。ダブルスタンダードとなり、違和感はあるかもしれませんが、どちらのOrganizationsに所属させるかというルールがきちんと整備されていれば十分でないかと私は考えています。
まとめ
今回は、Control TowerのセットアップステップやControl Towerの利用時に課題となりやすいポイントについても紹介しました。本記事がControl Towerの管理にお役に立てば幸いです。
奥村康晃 おくむらやすあき NTTデータ入社以来、クラウドサービスのAPIを連携させることで効率的な管理を可能とするクラウド管理プラットフォームの開発に従事。現在では、クラウド導入の技術コンサルや組織での技術戦略立案にも携わる。 2023 Japan AWS Ambassadors受賞 この著者の記事一覧はこちら
関連記事（外部サイト）
