Zenn
🧱

AWSでマルチアカウントするならControl Towerなのか？

2022/07/18に公開
AWS
Control Tower
tech

はじめに

とあるお客様先の環境で、数十システムをAWSアカウント１つで運用してまして、複数アカウントに分ける事になりました。
「マルチアカウントするならControl Towerでしょ」って気がしませんか？
でも検証・調査した結果、不採用としました。

ざっくりまとめ

  • Control Towerがカバーする範囲が不明確
  • たぶん一番とっつきにくいであろうAWS SSO設定をやってくれない
  • 分かり辛い部分が増えるのを上回るメリットを感じない

筆者（私）について

マルチアカウント環境を自分で作るのは初めてで、「Control Tower使ってなかった時はこうだったのにー」という話はできないのでご了承ください。

役割

普段は特定システムのAWS環境の設計構築がメインですが、今の案件ではシステムをまたいだ全体的な改善対応をしてまして、技術的な方針決め・共通部分の実装が主な役割です。
アカウント分離もそうですし、最近やってることだとCI/CDまわりの説明資料やサンプルを作ったりしてます。
今までの仕事の集大成みたいなところがあってなかなか楽しいです。

Control Towerはどんなサービスか

調べると色々書いてあると思いますが、主にAWS OrganizationsとAWS Single Sign-On(AWS SSO)を対象としたラッパーツールと一旦考えておくと良いと思います。
ここではOrganizationsとAWS SSOの説明は省きます。以下などを参照してください。

ざっくり言うと、Organizationsは複数アカウントをまとめて管理するサービス、AWS SSOは複数アカウントに１つのユーザでログインできるようにするサービスです。
そして、Control Towerという全く別のサービスがあるわけではなく、CloudFormationと連携してそれらを設定しています。

知ってる人はElastic Beanstalkを想像してください。あれも実体はELBとEC2の組み合わせです。

ワークショップ

私は以下のワークショップで初期設定を試してから、気になるところを調べていきました。
https://controltower.aws-management.tools/ja/immersionday/

もしControl Towerを検討していて、この記事を見つけた方はワークショップの上２つくらいをやってから読むと良いかもしれません。

Control Towerがやってくれること

※以降の説明に合わせてざっくり分類しています

  • Organizationsの範囲
    • OUの設定、共通アカウントの設定
    • AWSアカウントの発行
  • AWS SSOの範囲
    • SSOの設定
  • その他
    • ガードレールの設定
    • CloudTrailの集約設定
    • VPC作成とフローログの設定
    • AWS Configの有効化

こう書くと良さげにも見えますが（私もそう思ってましたし）これから課題を書いていきます。

主な課題

カバー範囲が不明確

Control Towerが関係するサービス、機能についてどこまでやってくれるのか不明確という事です。
以下のパターンに分けられます

  1. Control Towerで設定・管理するもの
  2. Control Towerで初期設定だけされるもの
  3. Control Towerで設定されないもの

最初に「3. Control Towerで設定されないもの」の例を上げると、各アカウントを利用するユーザ、デフォルト以外の権限・グループがそうです。
Control Towerの設定を行うと、SSOの設定もなされます。
でも、これはあくまでデフォルトの権限・グループをいくつか作ってくれるくらいです。
デフォルトにないものはSSOの設定から作らないといけませんし、ユーザー作成と権限の紐づけもSSOでやらないといけないです。（後述）

じゃぁControl Towerが作ったデフォルトの権限ってどういう扱いなのというと「2. Control Towerで初期設定だけされるもの」です。
つまりちょっと権限修正したいなとなったら直接変更する事になります。
VPCもここに入ると思います。

「1. Control Towerで設定・管理するもの」はどういうものがあるかと言うと、例えばOU構成がそうです。
CloudTrail関連の設定も1だそうです。
これらをControl Tower以外から変更してしまうと、Control Towerでエラーが起きます。（ドリフト）

AWSさん的には、基本的に必須のガードレール（ガードレールについては後述）に入っているものは1、そうでないものは2か3と考えればよいとの事でした。
だた、全部そうかは分からないです。ドキュメントには書いてないですし、サポートに問い合わせても分からないです。[1]

SSOの設定が大して楽にならない

マルチアカウント化での必須要素[2]な上、複雑と感じるのがこの部分です。

IAMユーザで1つのAWSアカウントだけだと、こんな感じの設定ですよね？

Group 権限
A Group Admin
B Group ReadOnly

AWS SSOでは「AWSアカウント×ユーザ/グループ×権限」の組み合わせで各アカウントへの権限を設定していきます。

Account ID Group 権限
1111 A Group Admin, ReadOnly
〃 B Group ReadOnly
2222 A Group Admin, ReadOnly

例えばこのように設定すると、A Groupは1111にも2222にもAdminで入れるし、ReadOnlyに切り替える事もできます。
B Groupは1111にReadOnlyで入る事しかできません。
設定する項目が増えるので慣れないとなかなか分かり辛いと思います。

これについてControl Towerは部分的にしか対応できません。
グループや権限の種類が増えれば飛躍的に複雑化しますし、単純にアカウントが増えれば追加しなければなりません。
で、この組み合わせを自分で設定管理しないといけない訳ですね[3]。

デフォルトのグループ・権限をいくつか作ってくれる機能はありますが、SSOでやりたい事は各アカウントの権限制御なのでそこだけ作られてもなぁって感じです。

Organizationsの設定は簡単

SSOの設定が楽にならないとするとOrganizationsはどうなの？と思うかもしれませんが、そもそもOrganizationsの設定は簡単です。

これがOrganizationsの画面です。（ID等を隠してます）
ディレクトリっぽいのがOU（グループ分けする機能。組織単位とも呼ぶ）。立方体のアイコンがAWSアカウントです。
ディレクトリでグループ分けした中にアカウントを作成してくだけです。

Organizations画面

誤解を恐れず言えば、触った事あるAWSサービスの中で最も簡単なサービスかもしれません。

ここまでのまとめ

マルチアカウントする上での必須機能で言えば、Control Tower使っても大して変わらない上に分かり辛い部分が増えるという事です。
これ以降はもう少し細かい話になります。

その他の課題

ガードレールの使い勝手がイマイチ

ガードレールとは複数アカウント全体で守る標準のセキュリティポリシーを設定できる機能です。[4]
ガードレールには必須のものと選択式のものがあります。
そして、選択はできるもののアカウント全体でのON/OFFしかできません[5]。
つまり１つでも例外的なリソースがあると、アカウント全体でOFFにするか、エラーだけどこれは無視みたいな運用でカバーをやる事になります。

似たような機能に、Security Hubの「セキュリティ標準」という機能があるのですが、Security Hubには抑制機能があるのでそちらを使った方が良いと思います。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards.html
https://dev.classmethod.jp/articles/security-hub-use-workflow-status-suppressed/

ガードレールにもメリットはありまして、「セキュリティ標準」は検出型のルールしか設定できません。
そもそも操作をさせない予防型のルールはOrganizationsのSCPで設定する必要があり[6]、これはガードレールの守備範囲です。

他にも微妙なところがある

  • AWS Configの自動設定が微妙

  • CloudTrailの集約設定がされるものの、CloudTrailの標準機能で代替できるし、そっちの方がシンプル →修正されました

    • Control Towerだと各アカウント毎に設定されるが、CloudTrailの標準機能だと設定自体も１箇所に集約される。
    • 例えばCloudTrail Insightsを後から使いたいとなった場合、全アカウントの設定を書き換える事になるのかな？

  • アカウント構成がAWSおすすめ構成と若干異なる

    • Audit accountとSecurity Tooling accountの違い。役割も若干違いそうな気がする
    • 必ずしも一致する必要はないと思うのだけど、どこにも触れられてないのでモヤっとする

  • VPCの作成機能がイマイチ[9]

    • フローログがLogアカウントに集約されない（CloudWatch Logsへの出力）
    • サブネット名（Nameタグ）が分かり辛い[10]
    • サブネット構成のカスタマイズがあまりできない。

役立ちそうなパターン

AWSあまり分からない/時間裂けないんだけど、アカウントは分けたい！って時でしょうか？あとセキュリティもある程度は気を付けたいんだって時？
にしても一番ややこしいと感じる権限設定は自分でなんとかするしかないのが微妙なんですよね。

いま対応してる案件だと、AWS担当者がある程度居るのもあり、分かり辛くなるデメリットが上回ると判断しました。

感想

私としては使う意味があまり見いだせなかったのですが、これが良かったのかも分かりません。
Control Tower環境と非Control Tower環境を両方運用してみた感想とかあったら読んでみたいですね。ある程度規模が大きくなるとうまくいく気がしないんだけど・・・

結局どうしたのか

  • アカウント管理：Organizations自体を操作する
  • ユーザ管理：AWS SSO自体を操作する。権限の紐付けはTerraformで頑張る
  • ガードレール：Security Hubの「セキュリティ標準」。リージョン拒否のSCP（必要に応じて増やす）
  • ログ集約
    • CloudTrail：標準機能
    • VPC Flow Log：各システムアカウント側で設定してもらう。Security Hubでチェックする
  • AWS Config：Terraformで頑張る。（SSM Quick Setupもなくはないと思う）
  • VPC：各システムで普通に作る

※Terraformを使ってるのは元々使われているからです。

Appendix

マルチアカウント構成の参考資料

脚注

  1. 具体的に「○○の設定を変更してもControl Towerに影響ないですか？」という質問には答えられるが、「どれを触って良くてどれを触っちゃだめなのか知りたい」と言っても答えられないそうです。都度確認するしかないです。 ↩︎

  2. Role作ってSwitch Roleしても良いですが、あまりやらないと思うので。 ↩︎

  3. 煩雑なので、Terraformで設定する事にしました。 ↩︎

  4. ガードレールはセキュリティの考え方であり、Control Towerの機能だけを指すものではなないですが、ここでは便宜上Control Towerの機能として話しています。 ↩︎

  5. 正確に言うとOU単位かアカウント単位ですが、最小単位はアカウントです。 ↩︎

  6. ドキュメントを参考にリージョン拒否は設定しておいて、後はSecurity Hubで運用しつつ必要に応じて追加すると良いんじゃないかと思います。 ↩︎

  7. リソース種別によっては料金が高額になるようです。 ↩︎

  8. それともランディングゾーンのカスタマイズしたらいけるのかな？訳ワカメになりそうな気がするけど… ↩︎

  9. VPC作成はとって付けたような感じがしてしまいます。各アカウントのNW範囲の管理とかやってくれれば良いんですけどね。使う意味を感じないので、Control Tower採用するにしても無効化（できる）した方が分かり易いかもです。 ↩︎

  10. 例えば「aws-controltower-PrivateSubnet2A」とか付くんですけど、AZ-Aの2つめのPrivateサブネットではなく、2つめのAZのA系のPrivateサブネットです ↩︎

Discussion