目次
BeeXの榊原です。本記事はBeeX Advent Calendar 2024、21日目の記事です。以前弊社エンジニアがこちらでAWS Control Tower(以下Control Tower)の設定手順を詳細に書かれていました。しかし画面や内容が一部古い部分があったため、アップデートの意味も込めて今回改めてアウトプットしています。※ご本人の許可もいただいています。
想定読者
・とりあえず試しにControl Towerを触ってみたい方
・AWSの試験対策でマルチアカウントの問題に苦しんでいる方
・Control Towerで作成されるリソースを具体的に知りたい
基本説明
自分の言葉で書こうと思いましたが、2024年12月現在、Control Towerだけでなんと3つのBlackbeltがリリースされていました。どの内容も非常にわかりやすいため、基本的内容の説明はこれらの資料にお任せします。各項目ごとに何が書かれているかコメントを記載しますので、不安な内容があればチェックしてみてください。
・AWS Control Tower 基礎編
・マルチアカウントのメリットは何か
・OrganizationsやControl Towerとは何か
・基本用語の説明(OU、管理アカウント、SCP等)
・Control Towerで何が実現できるのか
・AWS Control Tower 手順編 AWS Control Tower の有効化
・管理アカウントでランディングゾーン設定時に何が起こるか
・ランディングゾーンの設定手順(メールアドレスは複数用意されている前提)
・OUへのメンバーアカウント登録方法
・AWS Control Tower 機能紹介編
・Control Tower有効時に各アカウントで作成されるAWSリソース
・Control Towerの機能
Control Towerの設定
マルチアカウント用のアドレスを複数準備
Gmailアドレスを1つ用意してください。既にお持ちの方はそちらをつかっていただいて問題ないです。1つ用意できれば後はそこから複数のアドレスが作成できるため、アカウントも複数作成可能です。Gmailの画面を開き、左上の歯車マークからすべての設定を表示をクリックします。
「アカウントとインポート」を選択し、名前のセクションから「他のメールアドレスを追加」を選択します。
画面が切り替わります。名前は自由な値で良いですが、アドレスと一致させると良いでしょう。メールアドレスは例えば現在利用しているアドレスが「hogehoge@gmail.com」の場合「hogehoge+20241211Sample@gmail.com」といった形で「+」を記載した後に自由な@の前まで入力してアドレスの複数利用が可能です。一度作成したアカウントは削除すると同じアドレスは使えなくなるので、タイムスタンプをつけることをお勧めします。二項目の入力が終わったら、
以上の手順を参考に、ルートアカウント用、ログアーカイブアカウント用、監査アカウント用の計3つのアドレスを作成してください。
アカウント作成とセットアップ
ルートアカウントの準備をしましょう。手順はAWS公式のものをご参照ください。
アカウント作成が完了したら、さっそくログインしましょう。以降の流れは上で紹介したAWS Control Tower 手順編 AWS Control Tower の有効化を踏襲しています。Control Towerのサービス画面から「ランディングゾーンの設定」を選択します。
画面が切り替わります。下記の設定を確認したら「次へ」を選択します。
・ホームリージョン:国内の利用であれば東京リージョンでよいでしょう。
・ガバナンスのための追加リージョン選択:us-east-1を追加しました。(後から編集可)
・リージョン拒否設定:有効にすると、上で選択したリージョン以外でサービス利用が拒否されます。(リージョン拒否コントロール)
画面が切り替わります。下記の設定を確認したら「次へ」を選択します。どちらもデフォルトの値で設定していますが、後から変更可能です。
・基礎となるOU:ログアーカイブアカウントと、監査アカウントが所属するOU名を入力します。デフォルト値はSecurityです。
・追加のOU:後からこのOrganizationsに追加されるアカウントを入れるOU名を入力します。デフォルト値はSandboxです。
画面が切り替わります。下記の設定を確認したら「次へ」を選択します。ここで先ほど用意したメールアドレスを使います。管理アカウントは既に入力済みです。
・ログアーカイブアカウント:ログアーカイブ用アカウントに紐づけるメールアドレスとアカウント名を入力します。
・アカウントの監査:監査用アカウントに紐づけるメールアドレスとアカウント名を入力します。
ちなみにセッティングのタイミングで初めて知ったのですが、上記2つのアカウント作成時に個人情報やクレジットカードの入力は不要です。サクッと検証するには便利ですね。
画面が切り替わります。下記の設定を確認したら「次へ」を選択します。
・AWS アカウントアクセス設定:IAM Identity Centerを使ってアクセスするか否かを設定します。
・AWS CloudTrailの設定:組織の証跡を有効にするか否かを設定します。有効にすると組織証跡が有効にされ、ログアーカイブ用アカウントのS3(バケット名はaws-controltower-logs-[ログアーカイブ用アカウントID]-[ホームリージョンID])にアカウント毎のプレフィックスで、ログが保管されます。
・Amazon S3のログ設定:ログアーカイブ用アカウントに作成される2つのS3(ログとアクセスログ用)のライフサイクルを設定します。ライフサイクルルール名は「RetentionRule」です。
・KMS暗号化:CloudTrailとConfigのログを管理アカウントのKMSキーで暗号化するか否か設定します。利用する際は考慮すべきポイントがいくつかあるので、公式ドキュメントをご参照ください。
・AWS Backup:2024年11月に追加された項目ですが、ランディングゾーンの設定時点では有効化できません。ランディングゾーンのセットアップ完了後、「ランディングゾーンの設定」から有効化できます。
最後に設定確認画面が出るので、Control Towerがリソース作成することを許可(チェック)して、「ランディングゾーンの設定」を選択します。
画面が切り替わり、ランディングゾーンの設定が始まります。
ここで注意ポイントです。設定が始まったら、まもなくログアーカイブアカウント用、監査アカウント用のメールアドレスに下のようなメールが届きます。届いたメールの「Getting Started Resources」を押下します。
この操作を忘れてしまうと、下のようなエラーが発生します。
これについてはAWS公式ドキュメントに記載があります。
Common causes of landing zone launch failure:
•Lack of response to a confirmation email message.
•AWS CloudFormation StackSet failure.
(『Troubleshooting』より引用)
失敗しても再試行して、上記操作を行えばランディングゾーンの設定が完了します。自分の場合は設定開始からおよそ30分で完了しました。
この時点で作成されているAWSリソースは以下の通りです。実際に作成されたリソースを次の項目で確認してみましょう。
(引用元:AWS Control Tower 機能紹介編)
管理アカウントのリソース確認
直前の画像のリソースを1つ1つ確認します。
ControlTower
説明不要ですね。以下、各項目について深堀します。
・ダッシュボード
全体の設定を確認可能です。
・コントロール(ガードレール)
ガードレールの設計・思想を実現する機能です。道の両脇のガードレールは、車が車線からでて深刻な事故を防ぐことを目的としています。AWSのケースではリスクのある操作を防ぐことを目的として本機能が備わっています。コントロールの種類は大きく3つに分かれます。
コントロールの種類 | 内容 |
---|---|
予防コントロール | 特定の操作を禁止(実行不可)。 SCPで実装。 |
検出コントロール | 特定の動作を検出の上、対処。 Config Rulesで実装。 |
プロアクティブコントロール | リソースがルールに準拠しているか監視。 CloudFormation Hooksで実装。 2022年に追加。 |
コントロールはOU単位で有効で、コントロールごとにガイダンスという項目があります。ガイダンスは「必須」、「強く推奨」、「選択的」が存在しています。「必須」のコントロールはセットアップ時必ず適用され、解除不可です。下の画像はAWS Control Tower 基礎編からの引用です。
参考までにコントロールの初期設定状態をまとめてみました。表がかなり見づらいですがご容赦ください。合計24項目あります。一番最後の「[AWS-GR_REGION_DENY] リクエストされた AWS リージョンに基づいて AWS へのアクセスを拒否する」を除いて全てガイダンス「必須」の項目です。
コントロール名 | Root | Sandbox | Security |
---|---|---|---|
[AWS-GR_LOG_GROUP_POLICY] | 〇 | 〇 | 〇 |
[AWS-GR_CLOUDWATCH_EVENTS_CHANGE_PROHIBITED] AWS Control Tower によって設定された Amazon CloudWatch の変更を許可しない | 〇 | 〇 | 〇 |
[AWS-GR_AUDIT_BUCKET_PUBLIC_READ_PROHIBITED] ログアーカイブのパブリック読み取りアクセス設定を検出する | 〇 | 〇 | |
[AWS-GR_AUDIT_BUCKET_PUBLIC_WRITE_PROHIBITED] ログアーカイブのパブリック書き込みアクセス設定を検出する | 〇 | 〇 | |
[AWS-GR_AUDIT_BUCKET_DELETION_PROHIBITED] ログアーカイブの削除を許可しない | 〇 | 〇 | |
[AWS-GR_CT_AUDIT_BUCKET_ENCRYPTION_CHANGES_PROHIBITED] ログアーカイブで AWS Control Tower が作成した S3 バケットの暗号化設定の変更を許可しない | 〇 | 〇 | |
[AWS-GR_CT_AUDIT_BUCKET_LIFECYCLE_CONFIGURATION_CHANGES_PROHIBITED] ログアーカイブで AWS Control Tower が作成した Amazon S3 バケットのライフサイクル設定の変更を許可しない | 〇 | 〇 | |
[AWS-GR_CT_AUDIT_BUCKET_LOGGING_CONFIGURATION_CHANGES_PROHIBITED] ログアーカイブで AWS Control Tower が作成した Amazon S3 バケットのログ記録設定の変更を許可しない | 〇 | 〇 | |
[AWS-GR_CT_AUDIT_BUCKET_POLICY_CHANGES_PROHIBITED] ログアーカイブで AWS Control Tower が作成した Amazon S3 バケットのバケットポリシーの変更を許可しない | 〇 | 〇 | |
[AWS-GR_SNS_CHANGE_PROHIBITED] AWS Control Tower によって設定された Amazon SNS への変更を不許可にします | 〇 | 〇 | 〇 |
[AWS-GR_SNS_SUBSCRIPTION_CHANGE_PROHIBITED] AWS Control Tower によって設定された Amazon SNS のサブスクリプションへの変更を不許可にします | 〇 | 〇 | 〇 |
[AWS-GR_DETECT_CLOUDTRAIL_ENABLED_ON_SHARED_ACCOUNTS] セキュリティ組織単位の共有アカウントで AWS CloudTrail または CloudTrail Lake が有効になっているかどうかを検出します。 | 〇 | 〇 | 〇 |
[AWS-GR_CLOUDTRAIL_CHANGE_PROHIBITED] CloudTrail への設定変更を不許可にします | 〇 | 〇 | |
[AWS-GR_CLOUDTRAIL_CLOUDWATCH_LOGS_ENABLED] CloudTrail イベントと CloudWatch logs を統合する | 〇 | 〇 | 〇 |
[AWS-GR_CLOUDTRAIL_ENABLED] 利用可能なすべてのリージョンで CloudTrail を有効にする | 〇 | 〇 | 〇 |
[AWS-GR_CLOUDTRAIL_VALIDATION_ENABLED] CloudTrail ログファイルの整合性検証を有効にする | 〇 | 〇 | 〇 |
[AWS-GR_CONFIG_AGGREGATION_AUTHORIZATION_POLICY] AWS Control Tower によって作成された AWS Config アグリゲーション認可の削除を許可しない | 〇 | 〇 | 〇 |
[AWS-GR_CONFIG_AGGREGATION_CHANGE_PROHIBITED] AWS Control Tower で AWS Config リソースに付けたタグの変更を許可しない | 〇 | 〇 | 〇 |
[AWS-GR_CONFIG_CHANGE_PROHIBITED] AWS Config への設定変更を不許可にします | 〇 | 〇 | 〇 |
[AWS-GR_CONFIG_ENABLED] 利用可能なすべてのリージョンで AWS Config を有効にする | 〇 | 〇 | 〇 |
[AWS-GR_CONFIG_RULE_CHANGE_PROHIBITED] AWS Control Tower によって設定された AWS Config ルールへの変更を不許可にします | 〇 | 〇 | 〇 |
[AWS-GR_IAM_ROLE_CHANGE_PROHIBITED] AWS Control Tower と AWS CloudFormation によって設定された AWS IAM ロールの変更を許可しない | 〇 | 〇 | 〇 |
[AWS-GR_LAMBDA_CHANGE_PROHIBITED] AWS Control Tower によって設定された AWS Lambda 関数の変更を許可しない | 〇 | 〇 | 〇 |
[AWS-GR_REGION_DENY] リクエストされた AWS リージョンに基づいて AWS へのアクセスを拒否する | 〇 | 〇 |
・ランディングゾーン設定
Control Towerをセットアップした際の設定内容が確認できます。ランディングゾーンリージョンを増やしたり、セットアップ時にできなかったBackupの有効化もここから可能です。
Organizations
これも説明不要ですね。同様に項目について深堀します。
・組織(OU)
Control Towerを用いたら下の通り作成されます。
・サービス
Organizationsで管理されているすべてのアカウントに対して有効化するサービスを選択します。初期設定段階の有効化状況は下記の通りでした。
サービス名 | 初期設定 |
---|---|
Amazon Detective | |
Amazon DevOps Guru | |
Amazon GuardDuty | |
Amazon Inspector | |
Amazon Macie | |
Amazon Q | |
Amazon Security Lake | |
Amazon VPC IP Address Manager | |
Artifact | |
AWS Account Management | |
AWS Application Migration Service | |
AWS Audit Manager | |
AWS Backup | |
AWS Control Tower | 〇 |
AWS IAM Identity Center | 〇 |
AWS Marketplace - License Management | |
AWS Marketplace Private Marketplace | |
AWS Network Manager | |
AWS Resource Explorer | |
AWS Trusted Advisor | |
CloudFormation StackSets | |
CloudTrail | 〇 |
Config | 〇 |
Directory Service | |
Firewall Manager | |
IAM Access Analyzer | |
License Manager | |
RAM | |
S3 Storage Lens | |
Security Hub | |
Service Catalog | |
Service Quotas | |
Systems Manager | |
Tag policies | |
VPC Reachability Analyzer |
ここで有効化が推奨されているものはSecurity HubとGuardDutyです。AWSの公式資料や社内事例をみてもほぼマストと言い切ってよいレベルです。下の画像はAWSの公式資料からの引用です。
・ポリシー
SCPや最近追加されたRCP以外にも様々なポリシーがあったことを初めて知りましたが、ここでは各ポリシーの説明は省略します。初期段階ではSCPしか有効になっていません。
ポリシータイプ | 初期設定 |
---|---|
AI サービスのオプトアウトポリシー | |
バックアップポリシー | |
チャットボットポリシー | |
EC2 の宣言型ポリシー | |
リソースコントロールポリシー | |
サービスコントロールポリシー | 〇 |
タグポリシー |
Service Catalog
個人的に書籍『AWSの基本・仕組み・重要用語が全部わかる教科書』の文章がわかりやすかったので、そちらから引用します。
AWS Service Catalogは、CloudFormationと連携して、セルフサービスでリソースをプロビジョニングするための仕組みとポータルを構築するサービスです。
Control Towerにアカウントファクトリーというアカウント作成機能がありますが、ここでService Catalogが利用されます。
Config
AWSサービスの設定状況を記録してくれるものです。管理アカウントには各リージョン・アカウントのConfigの内容を集約して一元化してくれるConfigアグリゲータが設定されていますが、コンソールからは内容が確認できませんでした。調べてみたところ、AWS re:Postが参考になりました。以下引用です。
If you try to see it in the Config service console, you wont be able to as AWS config is not enabled in the management account. You can use the cli to view it:
$ aws configservice describe-configuration-aggregators
管理アカウントでAWS Configが有効化されていないことに起因していました。試しに管理アカウントで入力したところ、アグリゲータ自体は確かに設定されていることを確認しました。
$ aws configservice describe-configuration-aggregators --region ap-northeast-1
{
"ConfigurationAggregators": [
{
"ConfigurationAggregatorName": "aws-controltower-ConfigAggregatorForOrganizations",
"ConfigurationAggregatorArn": "arn:aws:config:ap-northeast-1:<管理アカウントID>:config-aggregator/config-aggregator-19mxmqgz",
"OrganizationAggregationSource": {
"RoleArn": "arn:aws:iam::<管理アカウントID>:role/service-role/AWSControlTowerConfigAggregatorRoleForOrganizations",
"AllAwsRegions": true
},
"CreationTime": "2024-12-07T06:42:13.878000+00:00",
"LastUpdatedTime": "2024-12-07T06:42:14.497000+00:00"
}
]
}
CloudWatch
各アカウントからCloudTrailのログを集めるためのロググループ「aws-controltower/CloudTrailLogs」が作成されています。アカウント部分をマスクしていますが、ルートアカウント用、ログアーカイブアカウント用、監査アカウント用のCloudTrailの内容が出力されます。
CloudTrail
組織への証跡が適用された証跡「aws-controltower-BaselineCloudTrail」が作成されます。SNS通知のトピックは監視アカウントのものを利用しています。
IAM
IAMダッシュボードの状況は以下の通りでした。
それぞれ作成されているリソースは下記の通りでした。
・IAMロール
Identity Center用のロールが5つ、各サービスで利用するためのロールが9つ作成されています。
・IAMポリシー
・IDプロバイダ
Identity Centerを有効にしたことで作成されます。
CloudFormation
ConfigアグリゲータとCloudTrailの証跡を集めるためのリソース作成用のスタックが作成されていました。
IAMダッシュボードの状況は以下の通りでした。
IAM Identity Center
・グループ
合計8つ作成されます。
・許可セット
こちらは6つ作成されています。
ログ用/監査用アカウントのリソース確認
ここも1つ1つ確認しようかと思いましたが、量が長くなってしまったため、弊社エンジニアが既にブログ化しているものをご参照ください。ログ用アカウントはこちら。監査用アカウントはこちら。
最後に
今回はControl Towerの有効化から、作成されたリソースの確認まで行いました。ここからさらにSCPを編集したり、Security Hub等セキュリティサービスを有効化してみると、さらに理解が深まるでしょう。ここまでお読みいただきありがとうございました。