AWS Control Tower とは
AWS Control Tower とは Landing Zone を実装するための AWS のマネージドサービスです。統制を取りつつマルチアカウントを管理する仕組みです。
Landing Zone とは
Landing Zone とはセキュリティとコンプライアンスのベストプラクティスに基づきアーキテクチャ設計と複数のアカウント環境を管理する仕組みを指します。
Landing Zone は、下記機能から構成されます。
- アカウントの発行・必要な初期設定の済んだアカウントを作成
- 管理用権限の発行・対象アカウントを管理するための権限を作成
- 共有サービスへのアクセス (ユーザー環境に合わせて個別に実装する)・AD やファイルサーバー等の共有サービスや運用拠点への接続経路の確保
- AWS ログの集約・監査用ログをセキュアに一元保存
- ガードレールの設置・実施してはいけない操作の禁止・危険な設定の監視
Landing Zone の実装方法
Langing Zone を実装する方法は以下の2つの方法が考えられます。
AWS Control Tower
AWS サービスとして提供される Landing Zone です。容易に利用可能ですが、カスタマイズするには制限があります。
主にこれから AWS を利用する場合に利用できます。既存アカウントにも適用可能です。
独自実装の Landing Zone
自組織で独自実装するパターンです。自組織の方針に従って自由にカスタマイズできるのが強みです。ただし、自由にカスタマイズがゆえにメンテナンスコストがかかります。
主に既存アカウントに適用する場合に利用できます。自組織でアカウント発行の仕組みや管理の仕組みができあがってる場合などに向いています。
そもそもなんでマルチアカウントにするのか
AWS をマルチアカウントにする観点として以下のものが考えられます。
- 環境の分離
- 開発、テスト、本番を分離することによるセキュリティおよび統制の確保
- 請求の分離
- 部門やシステム単位でのコスト明確化
- 権限の分離
- 部門間での権限分離およびアカウントへの権限移譲
- 複雑性の分離
- アカウントの目的を明確に絞ることで、構成がシンプルになる
AWS Organizations だけでもできること
マルチアカウント管理するだけなら AWS Organizations のみでも可能です。AWS Control Tower はAWS Organizations の機能を利用して、マルチアカウント管理機能を拡張しています。
AWS Organizations の機能は以下のとおりです。
- 複数 AWS アカウントの一元管理
- Organization Unit (OU)の作成
- 複数アカウントのグルーピング化
- AWS アカウントの発行
- Service Control Policy の作成、OU への適用
- 複数アカウントの一括請求
AWS Control Tower だと何ができるのか
AWS Control Tower の機能は以下のとおりです。
- Landing Zone の提供
- AWS Organizations を使用してマルチアカウントを作成
- ベストプラクティスに基づいたマルチアカウント構成
- デフォルトで Sandbox、Security の OU を作成
- AWS IAM アイデンティティセンターを利用した ID 管理を提供
- AWS Organizations を使用してマルチアカウントを作成
- Account Factory
- AWS アカウントのプロビジョニングの自動化
- 設定可能なテンプレートを提供
- CloudTrail と Config ログの保存
- Log Archive アカウント内の S3 バケットに一元的に保存される
- コントロールの提供
- AWS 環境全体に継続的なガバナンスを提供する高レベルのルール
- かつてはガードレールと呼ばれていたもの
- 予防と発見とプロアクティブの 3種類があり、この3種類のコントロールには、必須、強く推奨、選択的の 3 つのガイダンスカテゴリが適用される
参考: AWS Control Tower のコントロールについて – AWS Control Tower - 予防コントロール(Service Control Policy)
- 禁止されたアクションの実行が拒否される仕組み
- Control Tower 管理下のアカウントは必須の予防コントロールで禁止されているアクションが不可能
- 発見コントロール(AWS Config)
- ポリシー違反などリソース設定の非準拠を検出する仕組み
- プロアクティブ(CloudFormation フック)
- CloudFormation でプロビジョニングされる前にリソースをスキャンして、非準拠なリソースのプロビジョニングを拒否する仕組み
- ダッシュボード
- OU やアカウント、ガードレール違反などが一覧表示できる
AWS Control Tower ではできないこと
AWS Control Tower では提供されてない機能もあります。GuardDuty や Security Hub などのセキュリティ機能を組織全体適用するには Organizations の機能を利用する必要があります。
AWS Control Tower の注意点、制約事項
いろいろ資料を見てみてこの辺注意が必要かなという点を書いていきます。
注意点
- Conformance Packs (AWS Config 適合パック) を使ったガードレールの展開をする場合など、STS (AWS Security Token Service) を無効化している既存アカウントを取込もうとすると失敗するなど、既存アカウント受入時の制約がある
- 既存アカウントの Control Tower への受入処理時にエラーになった場合、スタックセット内で自動実行される作業の一部手作業が必要になる
- 必須コントロールを外せない
- セキュリティー機能 (GuardDuty, Security Hub, IAM Access Analyzer, Detective 等) は自動で有効化されないため、Control Tower 範囲外のセキュリティ機能は Control Tower の機能の外で管理が必要になる
- 範囲内の機能: Config, CloudTrail, SCP, Security Hub
- 範囲外の機能: GuardDuty, IAM Access Analyzer, Detective
- Control Tower 未対応リージョンを使用している場合、Control Tower 適用リージョンと適用外リージョンが混在して管理が煩雑になる
- 大阪リージョンには 2023年4月に対応
- AWS Control Tower がさらに 7 つのリージョンで利用可能に
- Control Tower はマネージドサービスであるが追加機能によっては手動バージョンアップ が必要になるケースがある
- CloudTrail のデータイベントとインサイトイベントの取得は無効でカスタマイズできない
- ログアーカイブアカウントで独自のログバケットを作成可能だが、推奨はされていない
- リージョンの使用を制限する SCP の併用に注意が必要
- SCP および AWS Security Token Service (STS) を介した AWS リージョンの使用の禁止をした場合AWS Control Tower が未定義の状態になる。AWS Control Tower のリージョンの拒否機能を使用する
- Terraform による IaC との境界の検討が必要
- アカウント発行に関してはControl Tower(Account Factory)で手動で行い、その後のアカウント設定はTerraformで行うなど
- Control Tower設定を全てTerraform化するのは困難
- Account Factory for Terraformを利用することでAWSアカウント発行は可能
- 参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニング
- どこまで Terraform で対応するかは別途検討が必要
制限とクォータ
- セキュリティ OU の共有アカウントの E メールアドレスは変更できますが、これらの変更を AWS Control Tower コンソールで確認するには、ランディングゾーンを更新する必要がある
- S3 へのログの保存期間は、最大15年間保存可能
- AWS Control Tower Landing zone の OU には、OU あたり 5 個の SCP の制限が適用される
- 300 を超えるアカウントを持つ既存の OU は、AWS Control Tower に登録または再登録することはできない
- 300を超える場合はOUを分ける必要がある
- OUのネストは 5段階まで
- 参考: AWS Control Tower の制限とクォータ – AWS Control Tower
AWS Control Towerを使うべきなのか
マルチアカウントを展開していくのであれば、AWSのベストプラクティスに乗れるので、使用するのが無難です。
ただし、独自の Landing Zone をすでに構築しており、Account Factory の仕組みも独自で構築できているのであれば、移行コストを鑑みてそのままでも問題ないです。
必須の予防コントロールが許容できない、OU などの制限にひっかかるなどの運用上の制約がある場合は使えないので、組織のポリシーを見直すか、独自で Landing Zone を作るかを考える必要があります。
まとめ
Control Tower について調べたことを書いていきました。
社内でも導入事例や運用事例がちらほら出始めてきたので、知見が溜まってきたらまたそれも共有できたらと思います。
参考文献
- AWS Control Tower とは – AWS Control Tower
- スタートアップにおけるマルチアカウントの考え方と AWS Control Tower のすゝめ | AWS Startup ブログ
- AWS マルチアカウント管理を実現するベストプラクティスとは ? – builders.flash☆ – 変化を求めるデベロッパーを応援するウェブマガジン | AWS
- AWS Control Tower Immersion / Activation Day :: AWS Control Tower ワークショップ
- AWS Control Tower を活用したランディングゾーンの構築
- AWS Control Towerで マルチアカウント管理しませんか
- AWS Control Tower で始める はじめての AWSアカウント管理
- 増加するシステムをマルチアカウントで 効率よく管理する
- マルチアカウント管理の基本