この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Control Tower と Account Factory で以下の点を抑えるために手を動かしてみました。Account Factory 周りの操作はキャプチャを載せていますのでなんとなく操作雰囲気は伝わるのではないかと思います。
- Account Factory からの新規 AWS アカウント発行
- 有りもののガードレールを設定と検知テスト
- Organizaitions で管理していた既存 AWS アカウントを Control Tower へ登録
ちょうど良い Control Tower のワークショップがあったので内容を流用して個人的に確認したかった点を追加してやってみた記録です。
AWS CONTROL TOWER IMMERSION / ACTIVATION DAY
AWS Control Tower のワークショップは全11章ありボリューム満点です。
AWS Control Tower Immersion / Activation Day :: AWS Control Tower Workshop
個人的に検証したい内容を一部含んだ以下のコンテンツを流用していろいろやってみました。
- Core Labs - Deployment
- Core Labs - Account Factory
Account Factory
- Account Factory から新規アカウント発行
- 選択的ガードレールを有効化し検知テスト
準備
Control Tower で管理された OU としてLabsOU を新規作成しました。Control Tower へ登録されるのに5分ほどかかりました。
ガードレール・デフォルト VPC 設定
選択的のガードレールを設定します。「Amazon S3 バケットのバージョニングが有効になっているかどうかを検出する」のルールをLabsOUで有効化します。
OU を選択し有効化しました。
Account Factory から作成した AWS アカウントはデフォルト VPC を作成しないようにネットワーク設定します。
以下のリンクでも同じこと設定を入れていますのでご参考に。
アカウント新規作成
Account Factory からLab1アカウント新規作成します。Eメールアドレスは Control Tower 管理下のマネジメントアカウントと同じメールアドレスを使用し、IAM Identity Center の新規ユーザー作成する処理をスキップさせています。
30分ほど放置すれば新規アカウントが発行されます。
ガードレール検知テスト
次にガードレールのルールで検知できるかテストします。新規作成したLab1アカウントにサインインしバージョニングを無効にした S3 バケットを作成します。
マネジメントに戻り Control Tower のダッシュボードから確認します。5分位経つと検知されました。
詳細を確認するとアカウント名や、バケット名までわかります。
Lab1アカウントにサインインし直して S3 バケットを設定を変更しバージョニングを有効にしました。
マネジメントアカウントに戻り Control Tower のダッシュボードから確認します。5分位経つと検知していたアラートが解消されました。
Account Factory からの新規アカウント発行と、ガードレールの動作を確認できました。
Account Factory - Existing Accounts
- 既存アカウント単体を Control Tower へ登録
- OU 指定で既存アカウントを Control Tower へ登録
OU ・アカウント構成は以下です。SandboxOU内にSandbox、Snadbox2、Sandbox3アカウントがあります。
既存アカウントを単体で登録
学べたこと
- AWS アカウントのある OU が Control Tower に登録されていない場合、アカウントを Control Tower へ登録時に登録済みの OU 配下へ移動が必要になる
- Control Tower へ AWS アカウントを追加するには前提条件がありパスする必要がある
AWSControlTowerExecutionIAM ロールは通常存在していないはずなので作成することになる
準備
既存のSandobx3アカウントにログインするために AWSAdministoratrAccessを持った許可セットと管理者ユーザーからのアクセスを追加しました。
Sandbox3アカウトにサインインし、Control Tower で管理するために必要な IAM ロール（AWSControlTowerExecution）作成します。Organizaitions で管理していたアカウントだとこの IAM ロールがないためまず作成しないことには始まらないのですね。
- 信頼されたエンティティタイプは AWS アカウントでマネジメントアカウントの ID を指定
- ロール名は
AWSControlTowerExecution AdministratorAccessポリシーを付与- 参考ドキュメント
ポイントは IAM ロールを作成するときにマネジメントアカウントのアカウント ID 指定します。
Control Tower の管理に切り替えたいアカウント上に IAM ロールを作成しました。Config 無効化などその他前提条件もありますのでご確認ください。
アカウント登録
マネジメントアカウントにサインインします。Control Tower の組織から Control Tower 管理に切り替えたいアカウントを開き、アカウントの登録を行います。
確認画面ではAWSControlTowerExecution IAM ロールと必要な権限（AdministratorAccess）があるか？と聞かれました。また、Sandbox3アカウントのあるSandboxOUは Control Tower に登録された OU ではないため、Control Tower で登録された OU へ移動が必要となりました。
Account Factory から新規アカウント作成時する際に新規作成したLabOU は Control Tower に登録済みのため、組織単位の選択項目はLabOU を指定しました。
再度確認を求められました。アカウントの登録をクリックしてやっと処理が実行されます。
時間を確認していなかったのですが30分ほど放置していたら、Sandbox3アカウントは Control Tower に登録されていました。予定どおりLabOU へ移動されています。
既存アカウントを OU 単位で登録
OU アカウント構成は以下です。SandboxOU内にNested TestOU と、Snadbox2アカウントがあります。Nested OU内にSnadbox4アカウントがある構成にしました。Sandboxアカウントは削除したアカウントなので停止状態となっています。
ちなみにNestedOU を Control Tower に登録できるのか試したところ親の OU をまず Control Tower に登録する必要があるとメッセージが表示されました。というわけで、SandboxOU を Control Tower に登録をやってみます。
学べたこと
- AWS アカウントを Control Tower へ登録するにはまず OU が Control Tower に登録されている必要がある
- AWS アカウント削除済み（停止状態）のアカウントを含む OU を Control Tower に登録するエラーで登録失敗する
- OU 単位でネストされた親の OU を Control Tower へ登録すると子の OU までは登録されない
- 親の OU と親の OU 直下の AWS アカウントが Control Tower へ登録される
- Control Tower へ AWS アカウントを追加するには前提条件がありパスする必要がある
AWSControlTowerExecutionIAM ロールは通常存在していないはずなので作成することになる- OU 単位で複数アカウントを登録する場合は StackSets で IAM ロールを作成すると楽
- StackSets のデプロイはネストされた子の OU へもデプロイ可能
StackSets で IAM ロール作成
単体のアカウント登録と同様にAWSControlTowerExecutionIAM ロールが各アカウントに必要です。Snadbox2とSnadbox4アカウントにロール作成します。複数アカウントに IAM ロール作成を手動で行うのは大変なので StackSets で各アカウントに所定 IAM ロール作成の CloudFormation テンプレートを流し込みます。
template.yaml
AWSTemplateFormatVersion: 2010-09-09
Description: Configure the Execution Role for Control Tower
Parameters:
ManagementAccountId:
Description: "Control Tower management account ID"
Type: String
Resources:
AWSControlTowerExecutionRole:
Type: AWS::IAM::Role
Properties:
RoleName: "AWSControlTowerExecution"
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
AWS:
- !Ref ManagementAccountId
Action:
- "sts:AssumeRole"
Path: /
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AdministratorAccessテンプレートは以下のブログから拝借しました。手動登録に比べたらマシだからテンプレ書くかとググったらでてきたので感謝です。
マネジメントアカウントの StackSets より組織単位へのデプロイでSandboxOU の ID を指定し実行しました。
ネストされたNested TestOUにも IAM ロールが作成されました。これによりSandbox2とSandbox4アカウントの事前準備が整いました。ネストされた OU 構成でも一括で流し込めたんですね。
Control Tower へ登録
マネジメントアカウントの Control Tower 画面に戻り、SandboxOU を Control Tower に登録してみます。
SandboxOU を指定するとSandboxとSandobx2アカウントが対象と表示されました。
Control Tower へ登録を実行すると早々にエラーになりました。
事前チェックをダウンロードをクリックするとPrecheckErrors_OU_Sandbox_yyyy_mm_dd.csvというファイルがダウンロードされました。
削除済みのSandboxアカウントを Control Tower の登録へ巻き込んだの原因でした。日本語訳された CSV ファイルをダウンロードできるのは珍しい気がします。
Organizaitions 画面からSandboxの登録を解除しアカウントを整理しました。不要なアカウントは事前に整理しておく必要があったわけですね。
改めてSandboxOU を指定するとSandobx2アカウントのみが対象と表示されました。
時間を計測していませんでしたがしばらく放置すると Control Tower へ登録されていました。ネストされたOU（Nested Test）は登録されませんでした。親の OU を Control Tower へ登録した後に子の OU を順次登録していく流れなんですね。親の OU を登録すると子の OU すべて Control Tower へ登録されるとアカウント規模にもよりますが影響範囲が拡大するため安全な設計と言えるでしょう。
既存アカウントの Control Tower 登録をアカウント単体登録 OU 単位登録の2パターンを試しました。
おわりに
Account Factory からアカウント作成と、Organizaitions で管理していたアカウントを Control Tower へ登録を試してみたくてやってみました。ワークショップのコンテンツはかなり多いので時間あるときにまとめてやりたいところです。ちなみに本検証はブログにアウトプットする時間を含め4時間半かかりました。
2
