AWS Control Tower 導入のために取り組んだこと

こんにちは！

アンドパッド SREチームの宜野座です。

今回はアンドパッドにてAWS Control Towerを導入した経緯や導入のために取り組んだことをまとめてみました。

AWS Control Tower自体は2021年4月に東京リージョンで使えるようになったばかりの新しいサービスです。

aws.amazon.com

そのため東京リージョンで導入したという事例も多くなく、AWS Control Towerを有効化して実際どういう影響があるのか読めない部分が多くありました。

導入するために悩んだ部分などを可能な範囲でまとめておりますので、ご参考になれば幸いです。

※ AWS Control Tower の導入の取り組みを中心として行ったことも評価され、社内にてMVPを受賞することにも繋がりました。関わってくださった皆さまありがとうございます！

※ AWS Organizationsの有効化に関しては、本記事のスコープ外になります。 ※ 本記事内で紹介している手順、金額などは2022年11月時点での情報です。

AWS Control Towerとは？
アンドパッドでAWS Control Towerを導入した経緯
AWS Control Tower の導入のために調査したこと
他の検討事案とAWS Control Towerのメリット・デメリット
- 他の検討事案
- AWS Control Towerのメリット・デメリット
Q&A
まとめ
終わりに

AWS Control Towerとは？

AWS Control Tower は、マルチアカウントAWS 環境を統一したガバナンス体制でセットアップおよび管理するために利用できるサービスです。

AWSアカウントが複数あり、それぞれのアカウントの管理を整え、維持したいというケースには非常に有用なサービスかと思います。また、新規アカウントセットアップ時の作業にかかる手間を軽減できる機能も備えています。

AWS Control Towerの解説はわかりやすい記事がいくつかあるため、詳しくは以下の記事もご参照ください。

tech.nri-net.com

dev.classmethod.jp

アンドパッドでAWS Control Towerを導入した経緯

今回AWS Control Towerの導入を検討したのは、新たな役割のAWSアカウントが増えるタイミングでした。

アンドパッドではアカウントの数が必要以上に増えて、SREの対応が追いつかない事態に陥らないように少数のアカウントを運用しています。

しかし、今後も既存のアカウントとは別の利用目的でAWSアカウントが増える可能性はゼロではありません。

AWSアカウントを新たに作成する際には

アカウントの権限設計
禁止事項の検討
コストの管理
AWSにて最低限行いたい設定(CloudTrailやConfigの有効化、セキュリティ周りの設定(Guard Duty, SecurityHub, etc…))

など考慮しなければならないことがたくさんあります。

またそのAWSアカウントが適切に管理されていることを日々確認する必要がありますが、現在のアンドパッドではAWSアカウント管理を専門にしている部署はなくSREが中心として取り組んでいます。

今後もしアカウントが増えることになった場合、アカウントのセットアップ、セキュリティの整備、管理状況を確認、という作業をこれまで通り毎回行なっているとチームリソースが足りなくなり、他の重要なタスクの進捗などにも影響が出る可能性がありました。

そこでSREの課題を改善できるものとして、以下のような目的を持ってAWS Control Tower の導入の調査を開始しました。

目的

アカウントの新規開設を安全にスムーズにできるようにしたい
現行の運用よりも高レイヤーのルールを適用・管理できるようにして、低レイヤーのルールの管理負荷を下げたい
既にAWSによって組み込まれているガバナンスやベストプラクティスを簡単に把握・適用できるようにしたい
AWS環境に適用されたポリシーの概要およびアカウントのステータスを、統合的に確認できるようにしたい
AWSアカウントを安全に使用できるように全アカウントに共通のガードレールを整備していきたい
- 使用リージョンの制限、ロギングの有効化、ルートユーザーの使用制限など

→ 上記の達成によって、いまSREが割いている労力や時間を、より肝心な生産活動・価値提供に割けるようにしたい

AWS Control Tower の導入のために調査したこと

1. AWS Control Towerの有効化の影響

AWS Control Towerを有効化した際に起きる主要な影響は、以下のようなものになります。

AWS Organizations 組織単位 (OU) が 2 つ作成される
- Security OU とSandbox OU(任意)が新たに作成される
AWS Control Towerを有効化すると以下の２つのAWSアカウントがSecurity OUに新たに誕生する
- 監査アカウント
  - 全AWSアカウントからGuardDutyやSecurity Hubの集約できたり(集約は自前で設定が必要)、セキュリティの問題を検知した時の修復を行うために各AWSアカウントへの特権を有している
  - 将来的にはアカウントセキュリティを担当する人がこちらから一元的に複数アカウントの状態を確認できる
- ログアーカイブアカウント
  - 主に保全用で全AWSアカウントからCloudTrailやAWS Configなどのログが集約されてS3に保存される
20 個の必須の予防ガードレールを適用する。2 つの必須の検出ガードレールを適用して設定違反を検出する
- 必須の予防・検出ガードレールが新規作成される２つのアカウントに適応される
  - ConfigやCloudTrailの有効化や設定変更禁止など、既存の運用システムに影響を与えるものは含まれていない
  - 参照記事
AWS IAM Identity Center (AWS SSO)のグループが作成される
- 外部IDプロバイダー x AWS SSOの設定など既存の設定があれば維持される
- Control Towerのホームリージョンと AWS IAM Identity Center のリージョンと同じである必要がある
- 参照記事

その他の影響については以下リンクも合わせてご覧ください。

docs.aws.amazon.com

2. AWS Control Towerへの既存のOU・アカウントの登録方法

AWS Organizationsはすでに有効化済みだったため、どのように既存のOU・アカウントを登録できるのかを調査しました。

OUの登録

OUの登録に関しては、こちらに記載のあるようにAWS Control Towerを有効化した時点では勝手にOUの登録は行われませんでした。

登録作業はAWS公式ドキュメントが詳しいため、必要に応じてこちらのドキュメントの下の階層にある「既存のOUの登録」、「新しいOUの作成」をご参照ください。

docs.aws.amazon.com

アカウントの登録

すでにAWS Configの設定がアカウントに存在している場合は、AWS Control Towerへの登録が失敗します。

docs.aws.amazon.com

AWS Configを各アカウントで有効化済みの場合は、以下のリンクの対応が必要になります。ステップ1でAWSサポートへの依頼が必要になりますが、より安全にAWS Control Towerに既存のAWSアカウントを登録することができます。

docs.aws.amazon.com

3. AWS Control Tower 導入のための検討事項

既存のアカウントにどのように反映していくと良いのか、誰がAWS Control Towerの設定を変更できるのか、ガードレール設定変更の影響を事前に確認できるのかなどを検討しました。

既存のAWS OrganizationsにAWS Control Towerを適用していくための作業フロー例

本番環境への影響を抑えた上で導入するための作業フローの一例になります。各企業によって適切な導入の流れは変わると思いますので、参考までに記載しております。

1.AWS Organizationsのマネージメントアカウントにて、AWS Control Towerを有効化する

Security OU配下に、監査アカウントとログアーカイブアカウントが作成される

2.本番稼働中ではなく、開発にも影響の出ないアカウントをAWS Control Towerに登録する

必須ガードレールが本当に影響のないものかを再確認する
任意のガードレールに関しても導入して効果の高いと思われるものを適応していく
- 利用するリージョンの制限、ルートユーザーのアクセスキーの発行禁止、IAMユーザーのMFA有効化検知など

3.必須のガードレールおよび任意のガードレールの設定が問題ないことが確認できたタイミングで随時開発環境として利用しているアカウントを登録していく

4.開発環境として利用しているアカウントで問題起きないことを確認後、本番環境として利用しているアカウントに適応していく

Control Tower(ガードレール)の設定変更者

AWS Organizations のマネジメントアカウントに入れる人が元々絞られているため、最小限の人のみが設定変更をできる状態で管理する想定です。

もしマネジメントアカウントで、IAMユーザーの整理や権限管理が行われていない場合はそちらを整える作業も必要になるかと思います。

ガードレールの設定変更の影響

ガードレールをOUに適応すると配下のアカウントのリソースに影響を及ぼすため、事前に別の本番アカウントが含まれないOUで動作を確認する必要があります。

リージョン制限
S3の設定変更禁止
etc...

docs.aws.amazon.com

4. ログアーカイブおよび監査アカウントの検討事項

AWS Control Towerと共に作成されてしまう２つのアカウント（ログアーカイブ、監査）の利用用途、利用者、コストの試算を行いました。

ログアーカイブおよび監査アカウントの利用用途

ログアーカイブアカウント
- CloudTrailやConfigのログを確認したい時など、全アカウントのAWS関連のログを確認するために使う想定
監査アカウント
- SecurityHubとGuardDutyを一元管理する
- 各アカウントでセキュリティの問題を検知した時の修復に使う想定

ログアーカイブおよび監査アカウントの利用者

最小限の人だけがログインできるように運用する ※ ログインはSSOで行われる想定

ログアーカイブアカウント
- SRE + 最小ユーザー
監査アカウント
- SRE + 最小ユーザー

ログアーカイブおよび監査アカウントのコスト試算

ログアーカイブアカウント
- S3のログ料金: 0.023USD/GB
  - CloudTrail: 1ヶ月のデータ量(GB) x 0.023USD x 12ヶ月 (1年分の料金)
  - Config: 1年のデータ量(GB) x 0.023USD
- Athenaなどでログを調査する料金
- AWS Control Towerの機能で作成されるリソースへの料金
  - AWS Service Catalog, AWS CloudTrail, AWS Config, Amazon CloudWatch, Amazon SNS...
監査アカウント
- Lambdaなどで各アカウントへのセキュリティ修復を実施するとした分だけコストがかかる

5. AWS Control Tower をやめるには

もし導入した後にやめたい場合はやめれるのか、どういった影響があるのかを調査しました。

主に以下の作業が必要になりますが、AWS Control Towerを廃止することはできます。

1. AWS Control Towerの追加要素の無効化・削除
2. 子アカウントへの一時的なIAM作成
3. 子アカウントのService Catalog製品削除
4. AWS Control Tower廃止
5. AWS Control Tower IAM Role/Policy削除
6. CloudWatch Logsグループ削除
7. AWS SSOの削除
8. OrganizationsでのAWS Control Tower統合の無効化

引用元: https://dev.classmethod.jp/articles/decommission-control-tower/

AWS Control Towerを廃止すること自体はアカウントやログも保持された状態で行われるため、サービスに何か直接影響を与えることはないようです。

そんな中でも以下のようなリスクは考えられました。