【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる

目次
①マルチアカウント管理の利点　
 ②ControlTowerの利点（＆実際かかったコストの画像）
③ひとまず構築しながらControlTowerを理解してみよう（手順付）
④SSOユーザー作成→サインインしてマルチアカウント管理を体感しよう
 ⑤セキュリティ（SecurityHub）の設定をしてみよう←本記事はここ
⑥セキュリティ（GuardDuty）の設定をしてみよう
 ⑦コントロールのざっくり解説＆設定をしてみよう

⑦までやればいったん一通り構築完了です。
ControlTowerだけの構築であれば③だけで完了です。

(+印付きはオプション現在執筆中です)
+ベストプラクティスとはいえ、構築後に実運用に沿って変えた設定集
 +全アカウントのコスト管理を行う
 +アカウント管理者を任命したらやること
 +SecurityHubをもっと詳しく

もし今回の記事が参考になったり、いいなと思ったら、よろしければストックやいいねしていただけると非常に嬉しいです🙌
あなたのいいねがとっても励みになり、記事を書くモチベになります。
コメントもぜひ、お待ちしております。

※本記事で使用するメールアドレスやアカウント名は一部マスキングしております。
あらかじめご了承ください。

本記事の流れ

本記事の大まかな流れは以下になります。
前回はControlTowerの構築が終わったので、続きをやっていきます。

①SandBoxOUにアカウント作成
②すでに作られてるSSOユーザー確認（管理者SSOユーザー）
③試しにログアーカイブアカウントへSSOでサインイン
④試しにセキュリティアカウントへSSOでサインイン

今回は統合の準備として、
・ControlTowerで試しにアカウント＆SSOサインインできるユーザーを払い出してみる
・各アカウントへSSOのサインインを体験する
これを①～④の流れで行っていきます。
前回ほど時間は使わず、やっていけばあっという間に終わると思います。

※記事の途中で「🔵おまけトグル」がありますが、こちらは手順としてスキップしても問題ないため、（スキップ可）の記載をしています。
本筋から逸れるおまけの検証/説明を行っているため、好奇心/興味がある人は見て頂けると幸いです。

①SandBoxにアカウント作成

前回はControlTowerの管理アカウントに、管理者IAMユーザーでサインインし「組織」を確認したところで終わりました。もう一回確認してみましょう。

ControlTowerの左タブの「組織」をクリックすると、現状のControlTowerのアカウント構成がわかります。フォルダマークがOU,立方体マークがアカウントになります。

登録というのがControlTowerへの登録（＝ControlTower管理下に置くこと）を指していることは前回お伝えしましたね。
ControlTowerの管理下に置かれていないアカウントを払い出すとどうなるのか、検証してみます。こちらは動作確認であり、構築とは関係ないのでスキップしても構いません。

🔵（スキップ可）検証のためにAWS Ornganizationsからアカウントを作ってみる

左上の検索窓から「organizations」を検索し、開いてみましょう。

見た目はControlTowerに似ており、画面中央の「組織」のところはContolTowerとそっくりです。
AWSによって、「既存のサービスを管理統制のためにカスタマイズした結果」、ControlTowerが出来たことが何となくつかめるのではないでしょうか。

アカウントIDはもちろん、各OUの組織IDなども先程のControlTowerと同じです。ControlTowerが内部的にはOrganizationsを使用しているからだと思います。

ただ、先程のControlTowerの画像とは違い、「ベースラインの状態」などの項目がありません。
当然かもですが、ControlTowerへの登録状態はControlTower側でしか確認できないんですね。
では、検証のためにOrganizationsからAWSアカウントを作成してみます。
***※実際にアカウントの追加はやらなくて結構です！ここで作成したアカウントは後で使いませんし、後々の構築の邪魔になる＆削除（閉鎖）は90日間かかってしまうので見ていただくだけにすることを推奨します。

右上の「AWSアカウントを追加」を押下します。

AWS アカウント名 : test-org
メアドテスト用Gmailのエイリアスを使用
一応上記みたいな形で行いました。検証なのでそれが分かる名前にしました。

エイリアスについても前回の記事でお伝えしましたが、設定方法を置いときます。
エイリアスの設定方法（Gmail）

IAMロール名は後々分かりづらくなるため、変えずに行きます。
ちなみにこのOrganizationsFullAccessについては本記事で後ほど説明します。

「AWSアカウントを作成」を押下すると、testアカウントの作成リクエストが送信されました。

いったんページを更新するとテスト用のアカウント(test-org)が出来ていました。
今回の方法だと、出来た直後はRootOU配下に所属しています。

ついでにOrganizationsの方でOUも作成し、まとめて挙動を見てみましょう。
RootOUにチェックを入れ、右上の「組織単位」から「新規作成」をクリックします。
※組織単位の方はアカウントと違い、すぐに削除できるため作っても心配ありません。また、ここで作成したものは後々使用しません。

名前はtestにします。組織単位の作成をクリック。

出来ました。現時点でリソースは空です。

では、ControlTowerの方で組織のタブを見てみます。
先程のテストアカウントはいますが、ベースラインの状態が「未登録」となっています。
また、試しに作成したOUも「有効になっていません」との表示になります。
これが 「ControlTowerの管理下にはおかれていない」 ということになります。
管理下に置かれていないため、コントロールが適用されていません。

詳細を見るため、testのOUをクリックしてみます。

比較のため、ControlTowerの管理下に既に置かれているSecurityOUを見てみます。

テスト用アカウントも見てみましょう。こちらも未登録のため、コントロールが適用されていません。

管理下に置く前に、この状態でコントロール(統一ポリシー)を適用しようとしても適用できません。
やり方は後述しますが、適当なコントロールを有効化しようとしても、先程のtestOUが表示すらされないことが分かります。

このように、Organizationsからアカウント/OUを払い出した場合、作っただけではControlTowerの管理下には置かれないことが分かります。

そのため、新規でアカウント/OUを払い出す際はなるべくOrganizationsを使用せず、ControlTower、もしくは別途説明するかもですがServiceCatalog/Cloudformation StackSetsなどから払い出すことをお勧めします。

もしOrgzanizationsからアカウントを誤って払い出してしまった場合は、素直にアカウントを消すか、どうしても消したくない場合はControlTowerへアカウントを「登録」することで管理下に置くことが可能です。
ただ、削除するときもまとめて一つのOU（＝SuspendOU）を作ってその配下に入れた後、削除することをおすすすめします。
ここらへんのアカウント周りはまた別の記事にて説明できればと思います。

では、本筋に戻って、今回は一緒にControlTowerから新たにアカウントを払い出してみましょう。

※私は今回Organizationsから作成したアカウント/OUはOrganizationsから該当のアカウントにチェックボックスを入れ削除（閉鎖）しました。ControlTowerの管理下に置かれていないものはControlTowerから削除できません。いったんControlTowerの管理下に置いてみたい（登録したい）場合はControlTowerの方で該当のアカウントにチェックボックスを入れ、「アクション」→「登録」してみてください。その際、RootOUには登録できないため、別のOU（SandBoxOU）に移動させてからアカウントを登録する必要があります。

さて、先程の検証をご覧になった方も、スキップされた方も、一緒にControlTowerから新たにアカウントを払い出してみましょう。
右上の「アカウントの作成」からアカウントを作成します。

🔵（スキップ可）Administrator AccessではないIAMユーザーでアカウントを作成する場合

ちなみにアカウント作成にも当然権限が必要ですが、今回は楽してAdministrrator AccessのIAMユーザーでやっているため問題ないです。

その権限でない場合は、以下記事を参考に権限付与を行いましょう。

ControlTowerでのアカウント作成は内部的にはServiceCatalogで行われているため、ServiceCatalogに対する権限を主に必要とします。

https://dev.classmethod.jp/articles/enroll-aws-account-by-account-factory/

※この画面のtest-orgというユーザーは先程の検証で作ったユーザーであり、今後不要のため心配ありません。無視して手順を進めてください。

作成画面で必要事項を入力します。アカウントのEメール/表示名は検証のために決めていたものを使用してください。特になければ適当に入力します。

「アクセス設定」で、SSOを使ってこのアカウントにサインインできるユーザーを作成します。
SSOのイメージは後で解説しますので、ひとまず作ります。

まずユーザーのEメールとユーザー名も入力します。
迷ったら上で入力したアカウントのEメール/表示名と同じでいいかもですが、
もしアカウントの所有者とSSOユーザーとして操作する人が別であれば、任意のものを記載してください。

ただアカウント作成時にとりあえずSSOユーザーを一人作る必要があるため作っている感じで、後からこのアカウントにサインインできる、複数のユーザーを追加/削除/編集なども可能です。
そこまで考えなくていいと思います（何かあればこのユーザー消して作り直せるので）

下へ行って、所属する組織単位はSandboxにします。ちなみにSecurityOUは実は特殊なOUのため、既存のアカウント以外でアカウントを所属させることが出来ません。細かい役割などは後ほど見ていきましょう。

ここのオプション系はいったん空欄でOKです。
細かく見ていくのは、運用を高度化するときに考えていきましょう。

※こういったアカウント払い出しはControlTower内の「AccoutFactory」という機能を用いているため、いつの間にか左タブで「AccountFactory」の機能に移り変わっています。
もっと細かく言うとAccountFactoryではServiceCatalog/CloudformationのStackSetsを使用しています。

ボタンを押下すると以下の画面に遷移し、アカウント作成のリクエストが送信されました。
ControlTower関係なくAWSアカウント作成時はデフォルトでVPCがつくられるため、そのVPCの情報が「ネットワーク構成」に載っています。

「組織」タブにうつると、先程作成したアカウントが表示されており、無事「登録済み」となっていることが確認できました。また、SandBoxのOU配下にいて、登録済みアカウントにこのアカウントがカウントされていれば問題ありません。

ここまででアカウント作成が完了しました。
※ちなみに、上記画像だとRootOUの登録済みアカウントが4/5となっています。
これは先程、おまけトグルにてAWS OrganizationsからCntの管理下に置いていないアカウントを払い出し、その後閉鎖（停止）したためです。このように停止したアカウントなどがある場合、登録済みアカウントのアイコンが変わります。

②すでに作られてるSSOユーザー確認（管理者SSOユーザー）

先程アカウント作成時にSSOユーザーも作成しましたので、その情報を見ていきましょう。
左上の検索欄からIAM Identity Centerを検索します

検索すると、ダッシュボードの画面が出るので左のタブから「ユーザー」をクリックします。

上の方が先程作成したユーザーになります（表示名・メアドで区別してください）。

もう一人下のユーザーがいます。
こちらはというと、ControlTower作成時（ランディングゾーン設定の60分間）に、管理アカウントに自動で作成されたSSOユーザーとなります。
表示名が「AWS Control Tower Admin」となっているのがそのSSOユーザーであり、すべてのアカウントにアクセスできるControlTower管理者ユーザーです。
ControlTowerでは、AccountFactoryからのアカウント作成時に、そのアカウントに管理者権限でアクセス可能なSSOユーザーが自動で作成されます（AuditやLogArchveのSSOユーザーは、管理者のSSOユーザーでサインイン可能なため自動では作られない）。

ただ、そのSSOユーザーを削除してしまうとそのアカウントにサインインできなくなるということは無く、新たにユーザーを作って権限を付与したり、既存のユーザーにアクセス権を付与することも可能ですので、ご安心ください。

一度SSOユーザーの詳細をクリックして確認してみます。こちらは管理者SSOユーザーです

プライマリ情報のメールアドレスが「未検証」となっているのがわかるでしょうか。SSOユーザーは、IAMなどと同じくメールの検証が必要ですのでこちらの検証を進めます。

作成したアカウントのEメール（もしくはIAM Identity CenterのEメール）宛てに以下の画像のようなメールが届いていると思います。

「Invitation to join AWS Identity Center」の件名そのままですが、こちらがSSOユーザーの検証のための招待メールとなります。Hello の後にユーザー名が来るため、このメールはControlTower作成時のSSOユーザー（AWS ControlTower Admin）あてのメールです。

こちらの「Accept invitation」をクリックするとメールの検証に遷移します。

🔵（スキップ可）ボタンクリック後「リクエストが完了できませんでした」の画面へ遷移した人向け

※ボタンの下にある文章の通り、メールには有効期限があり、7日間となっています。７日間を過ぎたのちボタンをクリックすると以下に遷移してしまい、検証できません。その場合は、再度Iam Identity Centerの該当のユーザーから「Eメール検証リンクを送信」を行い、メールを再送する必要があります。
まずIamIdentityCenterの「ユーザー」からEmail検証したいSSOユーザーをクリックします。
右上の通知の「Eメール検証リンクを送信」を押下します。

押下すると、このようなウィンドウが確認で出てくるので送信を押します。

押下すると「検証リンクが送信されました。」と通知されます。

検証リンクを送信すると、以下のメールが届きます。
最初に見た招待メールとは少し文面が違いますが、動作は同じなので「Verify Your email address」をクリックしましょう。

以下の画像が出て、Email検証が終わっていることが確認できました。

こちらの画面に遷移し、Eメールの検証が完了しました。

※なお、今回は管理用SSOユーザーの検証を行っていますが、メールの招待期限が切れていない場合や別のSSOユーザーの場合、検証の後にサインアップ画面（パスワードの設定ページ）に飛ぶことがあります。その場合は、SSOユーザーのパスワードの設定から行いましょう。

さて、SSOユーザーの説明に戻りまして、今度は管理者SSOユーザーの所属グループを見てみます。

所属しているグループは二つあり、①「AWS Account Factory」と②「AWSControlTowerAdmin」になります。
説明にもある通り、①、②にはそれぞれ権限が割り当てられているグループとなっており、①が「AccountFactoryにまつわる権限」、②が「管理者権限」となっています。

②はその名の通りControlTowerに対してのAdministrrator Accessが紐づけられていますが、実は①、説明の「ReadOnly～」に反してReadOnlyだけじゃない権限（書き込みや作成など）も入っています。

SSOの権限の仕組みはけっこう複雑で、ちゃんと説明すると細かくなってしまうため、今回は別記事にて解説いたします。
こちらはアカウント管理者の人には見てほしい内容です。

いったん今回はとりあえず管理者権限で各アカウントにサインインするよう進めちゃおうと思います（めんどいので……）

③試しにログアーカイブアカウントへSSOでサインイン

さて、それでは試しにLogArchiveアカウントへSSOでサインインしてみましょう

AWSのSSOサインインは、各ユーザーが「アクセスポータル」というポータルサイトにまずサインインし、そのポータルを経由して各アカウントに入ります。

（自作の図なので分かりづらかったらすみません……）

ジャンプアカウントとは違い、共用アカウントにサインインするわけではありません。
各ユーザーが共用のポータルを経由し、それぞれに割り当てられたアカウント、権限に行きます。

①各々のSSOユーザーでアクセスポータルにサインイン（個人のSSOユーザー）
②アクセスポータルから各々のアカウントに権限別でサインイン
という流れです。

図では分かりづらいと思うので、実際にサインインしてみましょう。

IAM Identity CenterのダッシュボードからAWS Access portal URLをクリックします。

（アクセスポータルURLは、ControlTowerからも「ランディングゾーン設定」→「設定」→「AWSアカウントアクセス設定」で確認可能です）

クリックしたらサインイン画面が出るので、今回は管理者のSSOユーザー名（SSOユーザーのEmailアドレス）、次の画面でパスワードを入力します。

※もしSSOユーザーのEmail検証が7日間を過ぎてしまった場合など、パスワードを設定していないことがあるので、パスワードに心当たりがなければ素直に「パスワードを忘れた場合」からパスワードをリセットしてください。

サインインに成功したら、MFAデバイスの登録を求められるので、ガイドに従って登録を行いましょう。

特にこだわりがなければ、認証アプリを選び「Google Authenticator」などを使用して登録を行います。登録に成功したら、再度サインイン＆2段階認証を行い、以下のAWS Access Portalの画面に遷移します。

スイッチロールとは違い、サインイン先のアカウントが一覧で表示され、それぞれサインイン時に使用できる権限が並んでいます。
例えば管理者アカウントの下には、先程確認したSSOのユーザーグループ①「AWS Account Factory」と②「AWSControlTowerAdmin」に紐づく権限が表示されています。①がAWS ServiceCatalogEndUserAccess、②がAdministratorAccessです。

※ちなみにこのポータルの画面から
アカウントCにStg-devの権限でサインイン
→サインアウトせずにこのポータル画面のの別アカウントをクリック
→アカウントBにProd-viewer-costの権限でサインイン＆Cからはサインアウト出来てる
ということも可能です。

同じくLogArchiveアカウント、AuditアカウントへAdministorator Accessでサインイン可能です。

※ちなみに、テスト用に作ったアカウントの方には「Administorator Access」ではなく制限された「AWS Organizations Full Access」の権限でアクセス可能です。

🔵スキップ可　AWSによってControlTower構築以外で作られた（自身で作った）アカウントへの権限

ControlTower構築によって作成されたアカウントには管理者権限でアクセス可能ですが、それ以外に新規に作ったアカウントに対しては、デフォルトでOrganizationsのみにアクセスするように、グループに許可が割り当てられています。おそらく事故防止（？）です。

今回はLogArchiveアカウントへサインインしてみましょう。Log Archiveの下のAdministorator Accessをクリックすると、コンソール画面に入れました。

右上のアカウントIDがLog ArchiveアカウントのID、ユーザー名が「サインインしたときの権限＋SSOユーザー名」であれば、サインイン成功です。

Log Archive内のリソース確認は本記事では割愛しますので、確認したい場合は以下@tonkatsu_oishiさんの記事を参考になさってください。

④試しに監査アカウントへSSOでサインイン

次にAuditアカウントへSSOでサインインしてみましょう。先程もお伝えしましたが、さっきのLogArchiveのSSOユーザーはサインアウトしなければ、並行でAuditユーザーにサインインすることが出来ます。
本来はよろしくないかもですが、手間なので今回はその方法を取らせてください。

別タブで開いていたAWS Access Portalの画面を再度開きます。

今回はAuditアカウントへサインインしてみましょう。Auditの下のAdministorator Accessをクリックすると、コンソール画面に入れました。

右上のアカウントIDがAuditアカウントのID、ユーザー名が「サインインしたときの権限＋SSOユーザー名」であれば、サインイン成功です。

こちらもアカウント内のリソースの細かい確認は省きますが、次回はAuditアカウント内で色々と操作しますので、なんとなくやっていけば把握できると思います！

おわりに

今回はSSOユーザーで各アカウントにサインインを行ってみました。
スイッチロールとは違い、各ユーザーの名前で権限を割り振れるため、より細かい権限設定が可能になります。あと個人的にはポータルURLのアカウントをクリックするだけで、スイッチバックとかせずにサインインできるのが嬉しいです。よろしいかどうかは置いといて……

次回はControlTowerのセキュリティ編（主にSecurityHub）です。セキュリティの設定、大丈夫？というチェックをControlTower内の組織全体に行き渡らせていきます。

ではまた～

←前回記事

次回記事→