これは 3-shake Advent Calendar 2022 10日目の記事です
仕事の中でAWSで複数のアカウントを管理したいという要件あり、その中でAWS Control Towerが使えないかなと調べたものをざっくりと書いていきます。
AWS Control Towerとは
AWS Control TowerとはLanding Zoneを実装するためのAWSのマネージドサービスです。そもそもLanding Zoneって何って話になりますね。
Landing Zoneとは
セキュリティとコンプライアンスのベストプラクティスに基づきアーキテクチャ設計とマルチアカウント環境を管理する仕組みを指します。
Landing Zoneは、下記機能から構成されます。
- アカウントの発行
- 必要な初期設定の済んだアカウントを作成
- 管理用権限の発行
- 対象アカウントを管理するための権限を作成
- AWS ログの集約
- 監査用ログをセキュアに一元保存
- ガードレールの設置
- 実施してはいけない操作の禁止
- 危険な設定の監視
Landing Zoneの実装方法
AWS Control Tower
AWSサービスとして提供される Landing Zoneです。容易に利用可能ですが、カスタマイズするには制限があります。(必須のガードレールを外せなかったり)
主にこれからAWSを利用する場合に利用できます。既存アカウントにも適用可能です。
独自実装の Landing Zone
自組織で独自実装するパターンです。自組織の方針に従って自由にカスタマイズできるのが強みです。ただし、自由にカスタマイズはできますが、自身でメンテナンスしないといけないので、コストはかかります。
主に既存アカウントに適用する場合に利用できます。自組織でアカウント発行の仕組みや管理の仕組みができあがってる場合などです。
そもそもなんでマルチアカウントにするのか
AWSをマルチアカウントにする観点として以下のものが考えられます。
- 環境の分離
- 開発、テスト、本番を分離することによるセキュリティおよび統制の確保
- 請求の分離
- 部門やシステム単位でのコスト明確化
- 権限の分離
- 部門間での権限分離およびアカウントへの権限移譲
- 複雑性の分離
- アカウントの目的を明確に絞ることで、構成がシンプルになる
AWS Organizationsだけでもできること
マルチアカウント管理するだけならOrganizationだけでもある程度はできます。むしろAWS Control TowerはOrganizationの機能を利用しています。
- 複数AWSアカウントの一元管理
- Organization Unit(OU)の作成
- 複数アカウントのグルーピング化
- AWSアカウントの発行
- Service Control Policyの作成、OUへの適用
- 複数アカウントの一括請求
AWS Control Towerだと何ができるのか
Control Towerで提供される機能として以下のものがあります。
- Landing Zoneの提供
- Account Factory
- AWSアカウントのプロビジョニングの自動化
- 設定可能なテンプレートを提供
- CloudTrailとConfigログの保存
- Log Archiveアカウント内のS3バケットに一元的に保存される
- ガードレールの提供
- 必須と任意の観点の2種類と予防的と発見的の2種類の組み合わせがありControl Towerにより管理下のアカウントに適用される
- 参考: ガードレールの仕組み
- 予防的ガードレール(Service Control Policy)
- 禁止されたアクションの実行が拒否される仕組み
- Control Tower管理下のアカウントは必須の予防的ガードレールで禁止されているアクションが不可能
- 禁止されたアクションの実行が拒否される仕組み
- 発見的ガードレール(Config)
- 特定のイベントが発生したときにCloudTrailに記録される仕組み
- ダッシュボード
- OUやアカウント、ガードレール違反などが一覧表示できる
AWS Control Towerではできないこと
AWS Control Towerでは提供されてない機能もあります。GuardDutyやSecurity Hubなどのセキュリティ機能を組織全体適用するにはOrganizationsの機能を利用する必要があります。
AWS Control Towerの注意点、制約事項
いろいろ資料を見てみてこの辺注意が必要かなという点を書いていきます。
注意点
- 既存アカウントの Control Tower への受入処理時にエラーになった場合、スタックセット内で自動実行される作業の一部手作業が必要になる
- 独自ガードレールの追加は可能だが、容易ではない。
- 必須ガードレールを外せない
- 各種セキュリティー機能は自動で有効化されないため、Control Towerの範囲外のセキュリティ機能は Control Tower の機能の外で管理が必要になる
- 範囲内の機能: Config, CloudTrail, SCP
- 範囲外の機能: GuardDuty, Security Hub, IAM Access Analyzer, Detective
- Control Tower 未対応リージョンを使用している場合、Control Tower適用リージョンと適用外リージョンが混在して管理が煩雑になる
- 大阪リージョン未対応なのでマルチリージョンを考えるときに注意
- Control Towerはマネージドサービスであるが追加機能によっては手動バージョンアップ が必要になるケースがある
- ログアーカイブアカウントで独自のログバケットを作成可能だが、非推奨
- リージョンの使用を制限する SCP の併用に注意が必要
- IaC との境界の検討が必要
- アカウント発行に関してはControl Tower(Account Factory)で手動で行い、その後のアカウント設定はTerraformで行うなど
- Account Factory for Terraformを利用することでAWSアカウント発行は可能
- どこまでTerraformで対応するかは別途検討が必要
制限とクォータ
- S３へのログの保存期間は、最大15年間保存可能(最近アップデートされた)
- Security OU の共有アカウントの E メールアドレスは変更可能だが、これらの変更を AWS Control Tower コンソールで確認するには、Landing Zone を更新する必要がある
- AWS Control Tower Landing zone の OU には、OU あたり5個のSCPの制限が適用される
- 300超のアカウントを持つ既存の OU は、AWS Control Tower に登録することはできない
- 300を超える場合はOUを分ける必要がある
- OUのネストは２段階まで、孫OUを持つことはできない
AWS Control Towerを使うべきなのか
マルチアカウントを展開していくのであれば、AWSのベストプラクティスに乗れるので、使用するのが無難です。
ただし、独自のLanding Zoneをすでに構築しており、Account Factoryの仕組みも独自で構築できているのであれば、移行コストを鑑みてそのままでも問題ないです。
必須の予防的ガードレールが許容できない、OUなどの制限にひっかるなどの運用上の制約がある場合は使えないので、組織のポリシーを見直すか、独自でLanding Zoneを作るかを考える必要があります。
発展
もっと調査したかったが、時間が足りなかったことや今後調べたいことです。
コンソールからAccount Factory実行するとService Catalogの設定項目がありますが、Service Catalog自体の理解不足でどう扱うのかが把握できてないのでこの辺調べたいです。
Account Factory for Terraform(AFT)を使うとアカウント発行そのものもIaC化できるので試したい。
- 参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニング
- 参考: ついにControl Towerのアカウント発行からカスタマイズまでIaC対応！Account Factory for Terraform (AFT)が新登場 #reinvent | DevelopersIO
Customization for Control Tower(CfCT)を使うとアカウント発行のイベントをトリガーにCloudFormationを実行できるので、これも実験したい。
- 参考: AWS Control Tower のカスタマイズ (CfCT) の概要 - AWS Control Tower
- 参考: Control Towerカスタマイズソリューション(CfCT)を使ってガードレールとCloudFormationを自動展開してみた | DevelopersIO
まとめ
Control Towerについて調べたことを書いていきました。
実運用自体はまだしてないので、これから触ってみて知見が溜まってきたらまたそれも共有できたらと思います。
