コラム

自己紹介

こんにちは、BTCクラウドCoEの宮國です。
業務では主にサーバレスに関連するAWSサービスを扱いつつ、BTCが持つクラウドアカウントの管理・統制を行い、より良いクラウドサービスの利用環境づくりを行っています。

このコラムでも上記に関連する記事を（まったり）更新していこうと思います。

マルチアカウントの統制とAWS Control Towerの可能性

組織に紐づくAWSアカウントをどのように管理するか。という課題はどの組織にとっても悩ましい問題だと思います。

多数のAWSアカウントが様々な用途で使用されている上に、利用者の習熟度が様々なので、アカウント管理やセキュリティ監査が難しくなります。

今回試してみるAWS Control Towerは、そういったマルチアカウント管理の悩みを解消し得るサービスです。

AWS Control Towerによって、マルチアカウント環境を手軽に構築設定できます。Landing Zone Solutionと同等の機能を持ちつつ、取っつきやすいのが特徴です。

このAWS Control Towerは2019年6月に一般公開されたばかりで、東京リージョンにもリリースされていないため、まだまだ情報が少ないです。

習うより慣れよ。という事でやってみたいと思います。

AWS Control Tower ハンズオン

前提

・Organizationsを有効化していないアカウントを使用しています。まっさらではなく、EC2のインスタンスやS3のバケットが残存する私用のアカウントでした。よって、アカウント作成や IAM 管理者の作成等、公式ガイドのステップ1まで完了しています。

AWS Control Towerの使用開始

・執筆時点（2019/9/26）でAWS Control Towerを利用できるリージョンは米国東部 (オハイオ)、欧州 (アイルランド)、米国東部 (バージニア北部)、米国西部 (オレゴン) の4リージョンです。今回は米国東部 (バージニア北部)を使用します。

ランディングのセットアップ

マネジメントコンソールからAWS Control Towerを選択し、ランディングゾーンの設定を選択します。

Landing Zone はアカウント群をCloud FormationやAWS SSO等で作成できるマルチアカウント作成向けのソリューションです。

AWS Control Towerではこれをサービスとしてコンソールから利用できるのが強みです。

• ログアーカイブアカウント
• 監査アカウント

用のEメールアドレスを指定します。

AWS Control Tower では、3 つの共有アカウント (マスターアカウント、ログアーカイブアカウント、監査アカウント) が作成されます。

各アカウントの役割はAWS Control Towerの仕組みを参照ください。

サービスのアクセス権限で「私は、AWS～」に✓をいれてランディングゾーンの設定を選択します。

完了するまで1時間かかるとの事…。

しかし、すぐにエラーになってしまいました。

序盤で躓くとは…。

3 つの共有アカウント (マスターアカウント、ログアーカイブアカウント、監査アカウント) が作成されるはずなのに、アカウントが2つしか作成されていません。

「詳細はこちら」から公式のトラブルシューティングに移動しますが、現時点での情報量は少ないです。いずれも当てはまりませんでした。

Organizationsを見た所、監査用のアカウントのみ作成されていました。

ログアーカイブアカウントの作成に失敗しているようですね。

一旦再試行することにします。

再び新しいEメールアドレスを入力するよう求められています。

ログアーカイブアカウント、監査アカウントに入力したEメールアドレスは確実にどのAWSアカウントにも紐づいていなかったので困ってしまいました。

ダメ元で1度目と同じアドレスを入れてランディングゾーンの設定を選択してみました。

すると、今度はプログレスバーが順調に進んでいます。

アカウントが3つになった上に各種ガードレールが作成（後述）されています。

CloudTrailを眺めましたが原因の特定には至りませんでした。一旦先に進みます。

まず、マスターアカウントにメールが届きます。

クリックする事でOrganizationsが有効化されます。

また、もう一通AWS SSOの招待メールが届きます。

招待を受け、パスワードを設定してユーザーの更新を押下します。

SSOのログイン画面に遷移します。先ほど作成したマスターアカウント、監査アカウント、ログアーカイブアカウント全てにログイン出来ます。

ここで、AWSAdministratorAccess権限を利用してMasterアカウントのマネージメントコンソールに入ってみます。

AWS Control Tower を使用する場合、AWS SSO は 米国東部（バージニア北部） ディレクトリに作成されるそうです。別リージョンでAWS Control Towerを開始した際は注意が必要です。

ディレクトリを選択した際、ユーザとしてAWS Control Tower Adminユーザ（マスターアカウントのメールアドレスと紐づく）が登録されている事を確認します。

次に、監査アカウントに設定したメールを見てみます。

「AWSアカウントの準備ができました」「アマゾンウェブサービスへようこそ」といったアカウント開始時のいつものメールに加えて　SNSのサブスクリプション承認メールが届いています。

メールは4通（eu-west-1,us-east-1,us-east-2,us-west-2 リージョン分）届いていました。現時点でAWS Control Towerを利用できるリージョンですね。

4通分承認します。

ログアーカイブアカウントではアカウント開始時のいつものメールのみ届きました。

さて、そうこうしている間にランディングゾーンの作成が完了しました。

かかった時間はやはり1時間程度でした。これから対応リージョンが増えると更に時間がかかるのでしょうか？

AWS Control Towerのコンソールからアカウントを選択しアカウントの情報を見てみましょう。

ざっくりとした各アカウントの主な役割は以下です。

• アカウント名：Master   組織単位： Root
• 請求アカウント
• ガードレール管理
• Account Factory作成※
• アカウント名：Audit   組織単位： Core
• 監査情報通知（SNS）
• アカウント名：Log archive   組織単位： Core
• ログ集約

※ 他のSSO ユーザーもAWSAccountFactory グループに所属させれば作成可能なようです。　→Account Factory

マルチアカウントのベストプラクティスを満たすような、課金管理、セキュリティ管理を支援するためのアカウントがすぐに作成できました。

新しいアカウントの作成

それでは、公式ユーザーガイドのAccount Factoryを参考に個別のアプリケーションアカウントを作成してみます。

新しいアカウントのプロビジョニングを選択し、AWS Service Catalogのページに遷移します。

AWS Control TowerではAWS Service Catalog を介してAccount Factoryを使用することで、新しいアカウントを作成するようです。

ドロップダウンメニューから製品の起動を選択します。

名前と製品バージョンを入力して次へ進みます。

パラメータを入力して次へを選択します。

メールアドレスやSSOユーザ名、OU、新しく作成するAWSアカウント名を入力していきます。

この時以下の点について注意が必要です。

• [SSOUserEmail] は新しい E メールアドレスか既存の AWS SSO ユーザーに関連付けられた E メールアドレスのいずれかです。どちらを選択しても、このユーザーにはプロビジョニングするアカウントへの管理者アクセスが許可されます。
• [AccountEmail] は、AWS アカウントにまだ関連付けられていない E メールアドレスであることが必要です。[SSOUserEmail] で新しい E メールアドレスを使用する場合は、ここでもそのアドレスを使用できます。

今回は新しいEメールアドレスを入力しました。

TagOptions、通知については何も入力せずそのまま次へを選択します。ユーザガイドによると、入力してしまうとアカウントのプロビジョニングに失敗する可能性があるそうです。

確認画面まで進んだら起動を選択します。リソースプランを変更するとアカウントのプロビジョニングに失敗するそうです。

必要な箇所以外何もいじらないのが鉄則のようです。

アカウントのプロビジョニングが開始されました。

しばらくすると、アプリケーションアカウントとして設定したメールアドレスにSSOの招待メールが届きます。先ほどと同じ要領でパスワードの設定をすると、今度はアプリケーションアカウントのみにサインインができます。AWSAdministratorAccessが自動付与されています。

マスターアカウントに戻り、Organizationsを見てみます。

Custom OUに新しいアカウントが登録されています。

AWS Service Catalogに戻ると、アカウントのプロビジョニングに成功していました。作成開始から20~25分程です。

このようにAccount Factory を介して新しいアプリケーションアカウントを作成することが出来ました。作成されたアカウントは、親 OU のガードレールを継承するので、マルチアカウントにおける監視やログ収集を手軽に実現できます。

ガードレールの概要

ガードレールはAWS 環境全体に継続的なガバナンスを提供するためのルールです。実際にガードレールを見てみます。

AWS Control Towerからガードレールを選択します。

気になった項目について意味を調べてみました。

• ガイダンス
• 必須：デフォルトで有効
• 強く推奨：マルチアカウント環境のベストプラクティスに基づき強く推奨されるがデフォルトでは無効
• 選択的：AWS エンタープライズ環境で一般的に制限されているアクションだがデフォルトでは無効

• 動作
• 予防：SCPで定義されており、ポリシー違反を予防する。
• 検出：Configルールで定義されており、ポリシー違反を検出する。

各ガードレール項目のガイダンス／動作を参照にしつつ、アカウントの利用方針と相談しながら設定していく感じですね。

各ガードレールの詳細はガードレールリファレンスが一番参考になりそうです。

ガードレールの有効化

それでは新しく作成したアプリケーションアカウントを対象として、ガードレールを有効化してみます。

「S3バケットへのパブリック読み取りアクセスを不許可にする」を選択します。

当項目のガイダンスは「強く推奨」で動作は「検出」になってます。

「組織単位が有効」から「OUでガードレールを有効にする」を選択します。

今回は、Customを対象としてガードレールを有効にします。

有効になりました。

次は、ガードレールに違反してみて挙動を確かめます。

アプリケーションアカウントにサインインし、S3でバケットを作成し、パブリックアクセス権限を付与します。リージョンは米国東部（バージニア北部）にしています。

この時、「予防」ではなく「検出」なので、パブリックアクセス権限の付与自体はできますね。

パブリック公開後数分程して、AWS Control TowerのS3のガードレールを参照すると…

非準拠と表示されました！

もちろんダッシュボードでも非準拠であることを確認できます。

そして、監査用に設定したEメールアドレスに対しても、SNS通知が届きました。

まとめ

このようにAWS Control Towerを使う事で、マルチアカウント環境の作成、管理、統制が手軽に実現できそうです。

・対象リージョンが4つのみであること

・新規に作成したOrganizationsでないとサービスを利用出来ないこと

の2つが解消されればマルチアカウント作成のスタンダードになっていく気がします。

実際S3で同じように東京リージョンにバケットを作成し、パブリックアクセス権限を付与してみましたが、もちろん検知してくれませんでした。

東京リージョンで使えない＆既存のOrganizationsでは使用できないとなると、まだまだ手を出しづらいですね。

アップデートを待ちたい所です。それでは！