１．はじめに
少し前にControl Towerでマルチアカウント環境を構築する機会がありました。非常に便利で使い勝手がよかったので、今回は構築方法を含てめこの記事の中で紹介していきたいと思います。
２．そもそもControl Towerとは
AWSのマルチアカウント環境を一括でまるっと提供してくれるサービスです。通常であれば非常に手間のかかる構築作業の大半をサービスがほぼ自動で対応してくれます。Control TowerはLanding Zoneという考え方に基づいているので、まずこちらについて簡単に解説します。
２－１．Landing Zone
Landing Zoneは、Well-Architected Framework などAWS のベストプラクティスに基づいて構成されたマルチアカウント環境をいい感じに展開するための仕組みの総称です。Landing Zone自体はあくまで考え方なので、これに準拠したマルチアカウント環境を構築する場合、基本的には仕組みを理解して自分でAWSの各種サービスを組み上げていく必要があります。
Landing Zoneについては以下のブログに詳しく書かれていますので、興味のある方はご覧ください。きれいに整理されているので、これからマルチアカウントを実装しようとしている人は読んでおいた方がよいかと思います。
ちなみにマルチアカウントそのものの考え方についてもこちらに詳細に書かれてます。（上の記事は第二回、こちらは第一回なので、こちらから先に読んだ方が分かりやすいかもしれません）
２－２．Landing Zone（実装）
先ほどLanding Zoneは考え方だと書きましたが、この概念をAWSが形にして一般公開したものをLanding Zone（実装）と言うそうです。名前が同じなので若干混乱してしまいそうですが。。
私も使用したことはないですがNode.jsやCloudFormationで実装されているようで、このスクリプトを各自のAWSアカウント上で実行することでLanding Zoneに則ったマルチアカウント環境を構築することができるとのことです。こちらは現在長期サポート中の扱いで機能追加はストップされているようなので、これからマルチアカウントを構築したいと考えている人は使わない方がよさそうです。もし興味のある方は以下AWSのページを参照ください。
２－３．Contorol Tower
上記Landing Zone（実装）の後継となるサービスです。どこかでそういう記述を見たわけではないですが、そんな雰囲気で恐らく合ってると思います。こちらはNode.jsスクリプトではなく純粋なAWSサービスとして提供されており、当然のごとくLanding Zoneに準拠しています。
対象のAWSアカウントでマウスをポチポチするだけで即利用できます。非常に便利なので今後のマルチアカウント管理のド本命と思いますが、利用できるリージョンに縛りがあるなど現時点ではまだ若干の癖があるため、この辺を受け入れられるかが採用のポイントかと思います。
制約や注意事項についてはこちらに纏めていますので、興味のある方はご覧ください。
２－４．Control Towerを構成するサービス
Control Towerは複数のAWSサービスを組み合わせて構成されています。使用しているサービスのうち、代表的なものを以下に記載します。
AWS Organizations
AWSでマルチアカウントを実現する際に必須となるサービスです。
親となるアカウントを管理アカウントとし、その配下にメンバーアカウントがぶら下がるようなイメージでマルチアカウント環境を構成できます。管理アカウントは絶大な権力を持ち、メンバーの追加／変更／削除だけでなく、SCP（サービスコントロールポリシー）を使用してメンバーアカウントに対して制限を掛けたりできます。いわゆるガードレールです。
また管理アカウント上に組織単位（OU）を作成することができ、作った組織の中にメンバーアカウントを入れて管理し、さらに組織に対してSCPを割り当てたりできます。
例えば、営業部・人事部など部署毎にOUを切ってメンバーアカウントを格納し、SCPにより各部単位に制限をかけたりできます。
AWS Config
AWSサービスの構成情報を記録できます。サービスに対する変更来歴を長期間保存し、いつどのような変更が行われたかを遡って確認することができます。例えば、誤ってS3がパブリック公開された際に、後からバケットポリシーの変更来歴を追いかけたりできます。
このサービスは全リージョン全アカウントで有効化することが推奨されているようです。
AWS Config Rule（適合パック）
AWS Configの派生サービスです。サービスに対して加えられた変更を自動的に検知し、予め定めておいたルールに違反した場合にアラートを上げたり、自動で修復（変更内容を取り消し）したりできます。
AWS Config Rule単体ではルール違反の検知しかできないため、以前は自動修復を実現するために色々なサービスと組み合わせる必要がありましたが、適合パックの登場によりAWS Configの１サービスだけでこういったことが対応ができるようになりました。
Cloud Trail
AWSに対するAPIコールのログを記録することができます。AWS Configと異なり、こちらのサービスではIAMなどのユーザによる操作（APIアクション）を記録、可視化することができます。
AWS Organizations環境下においては、管理アカウントから配下の全メンバーアカウントに対し、Cloud Trailを一括で有効化することも可能です。
AWS SSO
AWS上でシングルサインオン（SSO）を実現することができるサービスです。主に前述のOrganizationsと組み合わせて使うことが多いと思います。マルチアカウント環境下で、IAMユーザを使わずにAWSコンソールへログインしたり、複数アカウントの権限を一括でコントロールしたり、あるアカウントから別のアカウントへシームレスに切り替えたりと色々できるので非常に便利です。
Service Catalog
CloudFormationのテンプレートを製品として管理し、配布できるようになるサービスです。なんのこっちゃ分かりづらいと思いますが、とりあえずControl Towerの内部では、後述のAccount Factoryでこのサービスを使用しています。まあそんなものか、くらいの感覚で捉えておいてもらえればよいかと思います。
２－５．Control Towerが提供する機能
前述した通りControl Towerは様々なサービスの組み合わせで構成されているわけですが、これらを使って最終的に提供される具体的な機能のうち、代表的なものを以下に記載していきます。
ダッシュボード
Control Tower専用のダッシュボードが提供されます。これにより、中央管理者がControl Tower内のAWSアカウントの状況を継続的に監視することができます。配下のメンバーアカウントがガードレールに違反した場合には中央管理者へアラート（メール）が送信されるため、詳細をダッシュボードで確認し、各利用者に改善を促すといった運用ができるようになります。
ガードレール
ガードレールはAWSのガバナンスやセキュリティの実現における重要な考え方です。道路の脇にあるガードレールと同じで「事前にはみ出してはいけない範囲を決めておいてあげて、その中では何をしてもOK」というもので、OrganizationsのSCPやAWS Configルールなどで実現します。ガードレールの一例ですが、たとえば特定のAWSアカウントに対してインターネットへのアクセスを禁止＆それ以外は制約なく好きに使わせる、といったことが実現できます。
ガードレールには、大きく分けて発見的統制と予防的統制の２種類があります。
- 発見的統制：やってはいけないことのルールを定義し、これに違反した場合、アラートを上げたり変更内容を自動修復したりします。操作自体に制限を加えることはないので、各アカウントではルール違反の操作を実行すること自体は可能です。起きてしまった後にどう対応するか？といった考え方となります。AWS Config Rule（と適合パック）で実現します。
- 予防的統制：ルール違反の操作自体を禁止します。操作ができないのでより厳しいガードレールとなります。OranizationsのSCPで実現します。
現在Control Towerで提供されているガードレールの詳細については以下のリンクを参照ください。
- 必須のガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/mandatory-guardrails.html
- 強く推奨されるガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/strongly-recommended-guardrails.html
- 選択的ガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/elective-guardrails.html
監査ログの集約
後述のログアーカイブアカウントに、CloudTrailやAWS Configなど監査系のログが集約して保存されます。自分でログの転送設定などを行わなくても、Control Towerが全て自動で対応してくれるので非常に便利です。
Account Factory
Control Tower内に新規アカウントを追加するための機能です。これを使用することで、Landing Zoneに準拠した設定がAWSアカウントに対して自動的に適用されます。ワークロードで使用する運用アカウントの作成や配布は、基本的にこのAccount Factory機能から行うことになります。
３．構築手順
それではControl Towerの環境構築方法を記載していきます。
３－１．事前準備
Contorol Towerではメインとなるマスターアカウントの他に、ログアーカイブアカウントと監査アカウントの２つが必要になります。それぞれの役割は以下の通りです。
| アカウント種別 | 役割 |
|---|---|
| ログアーカイブアカウント | マルチアカウント環境内の全アカウントで生成された監査系のログ（AWS Config、CloudTrail）を集約して管理してくれます。 |
| 監査アカウント | マルチアカウント内の監査系サービス（AWS Configなど）を集中管理するアカウントです。Control Towerから発信されるアラートメール等はこのアカウントに対して送付されます。 |
このため、マスターアカウント以外の新規メールアドレスをを２つ取得しておいてください。
３－２．AWSコンソールでのセットアップ
まずはマスターアカウント上でAWSコンソールを開き、メニューからControl Towerを選択します。以下の画面が表示されるので「ランディングゾーンの設定」ボタンをクリックします。
続く画面でリージョンの設定を行います。ホームリージョンはメインで使用するリージョンです。基本は東京になるかと思います。また、ホームリージョン以外にControl Towerを適用するリージョンの選択も行えます。ここでは対応している全リージョンを指定しました。
続く画面でOUの設定を行います。「基礎となるOU」は、特に理由がなければデフォルトのまま「Security」でよいかと思います。「追加のOU」にはワークロードで使用するアカウントを追加していくことになるので、運用を考慮して任意の名前を指定してください。
続いてログアーカイブアカウント、監査アカウントの設定を行います。事前準備で取得したメールアドレスを指定しましょう。またKMS暗号化は任意項目なので、必要に応じチェックをONにしてください。
最後に確認画面が表示されます。画面最下部に同意文が記載されているので、内容を確認の上チェックを入れ、「ランディングゾーンの設定」ボタンをクリックします。
そうするとセットアップ画面が表示されます。推定残り時間は60分となっているので気長に待ちましょう。ちなみに私の場合は30分程度で完了しました。
３－３．各アカウントの設定（マスタアカウントなど）
セットアップ中にAWSからメールがいくつか飛んでくるので対応していきます。まずはマスターアカウント宛にアドレス検証のメールが来ます。「Verify your email address」ボタンに設定されているリンクを、マスターアカウントにログイン済みのブラウザで開きましょう。
ブラウザ上に以下の内容が表示されれば設定は完了です。
続いてマスターアカウント宛にAWS SSO（Single Sign-On）のメールが飛んできます。Control Towerでは自動でAWS SSOが有効になるので、このタイミングでアカウントの設定を行います。メール内の「Accept invitation」リンクに設定されているURLをブラウザで開きましょう。ちなみに、こちらはまだAWSコンソールにログインしていないブラウザを使用してください。
以下のサインアップ画面が開くので、SSOユーザのパスワードを設定します。
続いて監査アカウントとログアーカイブアカウントのアドレスに以下のメールが届きます。こちらはAWSアカウントが無事作成された旨のメールなので、特に何もする必要はありません。
最後に監査アカウントへSNSの案内が来ます。Control Towerでは、ガードレール違反等のセキュリティに関するアラートはこのSNS経由で配信されます。メール内の「Confirm subscription」をクリックすると以下の画面が表示され、SNSのサブスクリプションが有効になります。
AWSコンソールでControl Towerを見てみましょう。以下の画面が出れば設定は全て完了です。お疲れ様でした。
さいごに
今回はContorol Towerの環境構築方法を紹介しました。次回はAccount Factoryによるメンバーアカウントの追加方法などについても記載してみたいと思います。
この記事が誰かのお役に立てると幸いです。