こんにちは、大和総研CCoEの粟ケ窪です。
大和総研ではクラウドを通じてお客様に価値を提供すべく、2021年度よりパブリッククラウドの推進組織（CCoE: Cloud Center of Excellence）を設置し、クラウド活用を推進しています。
本記事では、AWSにおけるマルチアカウント管理を効率化するために有効なAWS Control Tower（以下、Control Tower）のセットアップと、有効に活用するためのベストプラクティスを紹介したいと思います。
はじめに
AWSではマルチアカウント構成を取ることがベストプラクティスとされています。AWSのアカウントは、AWSにおけるリソースコンテナです。マルチアカウント構成によってアカウントを分割することで、影響範囲を最小限に抑えることができます。
そんなマルチアカウント構成を実現するうえで、AWSが提供している便利なサービスに、Control Tower があります。
Control Tower とは、AWSが提唱する Landing Zone を早期に実装するためのサービスです。その内部では、AWS Organizations、AWS Service Catalog、AWS IAM Identity Center などが利用されています。
Control Tower はLanding Zone を早期に実装できる便利なサービスですが、一方で多数のサービスが自動でデプロイされることから全体像が見えにくく、さらに個々のサービスに関する高い知識が求められるなど、運用上の課題を抱えている方も多いのではないでしょうか。そこで本記事では、Control Tower のセットアップを順に解説しながら、利用にあたって有益なベストプラクティスをお伝えします。
Control Tower のセットアップ手順と注意点
本章では、Control Tower のセットアップ手順と注意点を紹介します。
Control Tower は大きく以下の手順でセットアップを行います。
ステップ1：事前確認
Control Tower を展開する際は、以下の前提条件を確認して操作を行う必要があります。特に、既存環境でControl Tower を展開する際には一層注意が必要です。
確認事項1：リソース作成を制限するSCPをアタッチしていないこと
Control Tower は多数のサービスを展開するため、SCP（サービスコントロールポリシー）が原因で失敗することがあります。Control Tower を展開するRootにはFull AWS Accessポリシーのみアタッチしておくことが推奨されています。
確認事項2：操作するIAMユーザ/ロールに十分な権限があること
Control Tower を展開するエンティティはAdministrator Access権限を有している必要があります。なお、ルートユーザである必要はありません。
確認事項3：共有アカウントのメールアドレスを保有していること
新規にControl Tower を展開する際にはルート以外の2つの共有アカウント用として2つのメールアドレスが必要です。このアドレスは共同受信箱として機能し、監査アカウントとログアーカイブアカウントに利用します。 なお、Control Tower を展開する際は新規アカウントを利用することが推奨されていますが、もしも既存のアカウントを共有アカウントとして利用する場合には新規のメールアドレスは不要です。
ステップ2：リージョンの選択
ホームリージョンの選択
Control Tower を展開するためのホームリージョンを選択します。なお、展開後の変更はできません。ホームリージョンは以下のような観点で選択します。- リソースを展開するリージョンと同じリージョン
- 既存の IAM Identity Center と同じリージョン
- 最も使用頻度の高いリージョン
- 管理対象リージョンの選択
Control Tower によるガバナンスを有効にするリージョンを選択します。選択したリージョンに対して Control Tower が展開されるため、コスト最適化の観点から実際にAWSリソースを展開するリージョンのみを Control Tower の管理対象とすることをおすすめします。
- リージョン拒否設定
管理対象外リージョンのAWSサービスへのアクセスを拒否することができます。セキュリティ侵害は普段利用していないリージョンが狙われやすい傾向にあるため、特段の理由がない限り有効化することをお勧めします。
ステップ3：組織単位(OU)の設定
AWSアカウントを論理的にグループ化したものをAWS Organizational Unit（以下、OU）と呼びます。Control Towerでは基礎となるOUと、追加のOUをそれぞれ設定します。それぞれデフォルト名は以下のとおりです。どちらのOU名も後から変更することが可能です。
- 基礎となるOU：Security
- 追加のOU：Sandbox
なお、基礎となるOUには監査アカウントとログアーカイブアカウントのみが配置されます。そのため、追加のOUは事実上必須となります。
ステップ4：共有アカウントの設定
ログアーカイブアカウントと監査アカウントの設定を行います。新規にログアーカイブアカウントと監査アカウントを作成する場合は、メールアドレスとアカウント名を指定し、既存のアカウントを利用する場合はアカウントIDを指定します。
ステップ5：その他の設定
- AWS IAM Identity Center の設定
Control Tower で AWS IAM Identity Center（以下、IAM Identity Center） を利用するか否かを選択します。「利用する」を選択した場合はControl Tower の管理に必要な許可セットが展開されます。厳密なパスワードポリシーが定められているなど IAM Identity Center の利用が制限されるケースもありますが、IAM Identity Centerを利用することで、ユーザ、グループ、ロール（権限）を一元的に管理できる利点がありますので、基本的には利用したほうがよいでしょう。
図8：Control Towerアカウントアクセス設定画面
- AWS CloudTrail の設定
Control Tower で AWS CloudTrail の設定と管理を行う場合は有効にします。サードパーティのロギングツールで管理を行いたいなどの要件がある場合は有効にする必要はありません。 なお、後から設定の変更が可能です。
- ログ保持期間の設定
AWS CloudTrail および AWS Config のログの保持期間を設定します。組織のポリシーおよび実際に展開されるワークロードに準じて適切な保持期間を設定します。
- 暗号化の設定
ログを管理アカウントのKMSで暗号化するか否かを選択します。KMSで暗号化する際は、事前にKMSキーを作成しておくか既存のキーを選択することができます。なお、AWS公式のユーザガイドにもあるように、キーポリシーには AWS Config と AWS CloudTrail への必要最小限のアクセス許可を持たせることが推奨されています。
以上の手順で Control Tower を展開することができます。ただし、 Control Tower の利用にあたってはいくつか留意すべき点があります。次項から実際の利用時のコツをお伝えします。
Control Tower を利用するコツ
前頁ではControl Tower のセットアップ手順と注意点を紹介しました。本章では、Control Towerを有効に活用するために、ベストプラクティスを考慮した設計方法をお伝えします。
適切なOU設計を行う
Control Tower は AWS Organizations を基軸としたサービスです。OUの設計が適切でないと後の管理負荷が増大するため、初期段階で十分に考慮しておく必要があります。
OUにはSCPをアタッチして制限をかけることができますが、ルートユーザの操作までも制限してしまう強力なポリシーであるため、なるべくシンプルに保つことが推奨されています。AWS利用が成熟していない初期段階では、特に階層を深くしすぎないという点に留意するとよいでしょう。推奨されるOUの例はAmazon Web Servicesブログ「AWS Organizations における組織単位のベストプラクティス」で公開されています。
主なOUとその用途については以下の通りです。
Infrastructure
ネットワークやITサービスなどの共有インフラストラクチャサービス用に使用する。必要なサービスの種類ごとにアカウントを作成する。Security
セキュリティサービスに使用される。ログアーカイブ、セキュリティ読み取り専用アクセス、セキュリティツールなどのアカウントを作成する。Sandbox
個々のデベロッパーがAWSのサービスを試すために使用できるAWSアカウントを保持する。これらのアカウントを内部ネットワークから確実にデタッチできるようにし、コスト制限を設定する。Workloads
外部向けのアプリケーションサービスをホストするAWSアカウントを保持する。本番ワークロードを分離して厳密に制御するには、SDLCおよびProd環境OUをこの配下に構成する。
IAM Identity Center の管理を他アカウントに委任する
Control Tower というよりは AWS Organizations におけるベストプラクティスですが、委任管理者を設定可能なものは設定し、管理アカウントの利用用途を減らすことが推奨されています。そのなかでも IAM Identity Center は設定変更の頻度が特に多いため委任管理者を設定することをおすすめします。
委任管理者を設定することで以下のように委任管理アカウントに IAM Identity Center の管理を任せることができるようになります。
許可セットの編集権限を個別のアカウントに委任する
IAM Identity Centerを利用する際に課題として、ポリシーが許可セットという形で集中管理されるため、中央のID管理者の負荷が増大したりコミュニケーションのオーバーヘッドが発生したりしてしまうという事態が起こりやすくなります。このような場合の有効な手段に、タグを活用して許可セットの操作権限を与えるというものがあります。 たとえば以下のポリシーをプリンシパルにアタッチすると、 Team:Infrastructure というタグのついた許可セットを作成し、自身のアカウントに割り当てることができるようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sso:CreatePermissionSet",
"sso:DescribePermissionSet",
"sso:UpdatePermissionSet",
"sso:DeletePermissionSet",
"sso:DescribePermissionSetProvisioningStatus",
"sso:DescribeAccountAssignmentCreationStatus",
"sso:DescribeAccountAssignmentDeletionStatus",
"sso:TagResource"
],
"Resource": [
"arn:aws:sso:::instance/ssoins-<sso-ins-id>"
]
},
{
"Effect": "Allow",
"Action": [
"sso:DescribePermissionSet",
"sso:UpdatePermissionSet",
"sso:DeletePermissionSet"
],
"Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Team": "Infrastructure"
}
}
},
{
"Effect": "Allow",
"Action": [
"sso:CreatePermissionSet"
],
"Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/",
"Condition": {
"StringEquals": {
"aws:RequestTag/Team": "Infrastructure"
}
}
},
{
"Effect": "Allow",
"Action": "sso:TagResource",
"Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Team": "Infrastructure",
"aws:RequestTag/Team": "Infrastructure"
}
}
},
{
"Effect": "Allow",
"Action": [
"sso:CreateAccountAssignment",
"sso:DeleteAccountAssignment",
"sso:ProvisionPermissionSet"
],
"Resource": [
"arn:aws:sso:::instance/ssoins-<sso-ins-id>",
"arn:aws:sso:::account/aaaaaaaaaaaa(自身のアカウントID)",
"arn:aws:sso:::account/bbbbbbbbbbbb(自身のアカウントIDその2)"
]
},
{
"Sid": "InlinePolicy",
"Effect": "Allow",
"Action": [
"sso:GetInlinePolicyForPermissionSet",
"sso:PutInlinePolicyToPermissionSet",
"sso:DeleteInlinePolicyFromPermissionSet"
],
"Resource": [
"arn:aws:sso:::instance/ssoins-<sso-ins-id>"
]
},
{
"Sid": "InlinePolicyABAC",
"Effect": "Allow",
"Action": [
"sso:GetInlinePolicyForPermissionSet",
"sso:PutInlinePolicyToPermissionSet",
"sso:DeleteInlinePolicyFromPermissionSet"
],
"Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Team": "Infrastructure"
}
}
}
]
}
なお、IAM Identity Center 全体に権限を与えてしまうと他チームの許可セットや管理者の許可セットも変更できてしまうため、タグなどを利用してスコープを絞って権限を委譲するようにしましょう。
まとめ
本記事では、Control Tower のセットアップ手順と注意点、またControl Towerを有効に活用するためのベストプラクティスを考慮した設計方法を紹介しました。Control Tower は小規模な環境からグローバル規模の環境まで、強力なガバナンスのもとに運用することが可能な便利なサービスです。マルチアカウントの管理に悩まれている方はControl Towerの利用をぜひご検討ください。
関連記事
大和総研の豊富な知識と粘り強い取り組みで実現した ミッションクリティカルなEC決済システムのクラウド移行 | 大和総研
プロジェクト事例：AWSとプライベートクラウドのハイブリッド構成で実現したCRMシステムの全面更改 | 大和総研
