【小ネタ】 Control Tower の管理対象リージョンに us-east-1 がないとアカウントカラーを設定できない
はじめに
こんにちは、クラウド事業本部 コンサルティング部のいたくらです。
皆さんは、マネジメントコンソール上のアカウントの色を変えようとしたのにエラーで拒否されたことはありますか？私はあります。
アカウントカラーは AWS マネジメントコンソールのヘッダーの色を変更できる機能で、本番環境と開発環境を視覚的に区別するのにとても便利です。
しかし、Control Tower のリージョン拒否コントロールが有効な環境では、この設定がブロックされてしまうケースがあります。
この記事では、その原因と検証結果をご紹介します。
先に結論
- アカウントカラーの設定に使われる
uxcサービスのエンドポイントはus-east-1にある - Control Tower のランディングゾーンレベルのリージョン拒否コントロール（
GRREGIONDENY）のNotActionリストにuxc:*が含まれていないため、許可リージョン以外からのアクセスとして拒否される - OU レベルのリージョン拒否コントロール（
CT.MULTISERVICE.PV.1）でuxc:*を除外しても、GRREGIONDENYの Deny が優先されるため解決しない - 管理対象リージョンに
us-east-1を追加すれば解決する
前提となる環境
今回の事象は、以下の Control Tower 環境で発生しました。
- ランディングゾーンバージョン：4.0
- ホームリージョン：ap-northeast-1（東京）
- 管理対象リージョン：ap-northeast-1（東京）のみ
- リージョン拒否コントロール：有効
- 自動アカウント登録：有効
何が起きたか
Control Tower に登録されたアカウントでアカウントカラーを変更しようとしたところ、以下のエラーが表示されました。
a service control policy explicitly denies the action という記載から、IAM ポリシーではなく、SCP によって拒否されていることがわかります。
原因
該当アカウントが所属する OU には、Control Tower のランディングゾーンレベルのリージョン拒否コントロール（GRREGIONDENY）が適用されていました。
この SCP は、許可されたリージョン以外へのアクセスを拒否するものですが、グローバルサービスなど一部のサービスは NotAction に記載することで除外されています。
{
"Sid": "GRREGIONDENY",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-1"
]
},
...
},
"Resource": "*",
"Effect": "Deny",
"NotAction": [
"iam:*",
"sts:*",
"s3:GetBucketLocation",
"route53:*",
...
]
}
しかし、アカウントカラーの設定に使われる uxc:* はこの NotAction リストに含まれていません。
アカウントカラーのリソース ARN を見ると arn:aws:uxc:us-east-1:... となっており、エンドポイントは us-east-1 にあります。
許可リージョンが ap-northeast-1 のみの環境では、us-east-1 へのリクエストはリージョン拒否コントロールによってブロックされます。
CT.MULTISERVICE.PV.1 で回避できるか検証してみた
ランディングゾーンレベルの GRREGIONDENY はユーザー側で直接編集できません（編集するとドリフトが発生します）。
そこで、OU レベルで適用できるリージョン拒否コントロール「[CT.MULTISERVICE.PV.1] Deny access to AWS based on the requested AWS Region for an organizational unit」を使って回避できるか検証してみました。
設定内容
以下の設定で CT.MULTISERVICE.PV.1 を対象 OU に適用しました。
| パラメータ | 値 |
|---|---|
| この OU を許可する AWS リージョン | ap-northeast-1 |
| この OU を許可するサービスアクション | uxc:* |
| 除外されるプリンシパル | なし |
AllowedRegions に us-east-1 を追加する方法もありますが、それだと us-east-1 の全サービスへのアクセスが許可されてしまい、リージョン制限をかけている意味が薄れます。そのため、ExemptedActions で uxc:* のみを除外する方法で試しています。
結果
CT.MULTISERVICE.PV.1 を有効化した後もアカウントカラーの変更はできませんでした。エラー内容も変わらずです。
原因の分析
適用後の SCP を確認すると、同一 SCP 内に2つの Statement が存在していました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GRREGIONDENY",
"Effect": "Deny",
"NotAction": [
// uxc:* が含まれていない → uxc:* は Deny される
"iam:*",
"sts:*",
...
],
...
},
{
"Sid": "CTMULTISERVICEPV1",
"Effect": "Deny",
"NotAction": [
"uxc:*", // uxc:* が含まれている → この Statement では Deny されない
"iam:*",
"sts:*",
...
],
...
}
]
}
SCP の評価ロジックでは、いずれかの Statement で明示的に Deny されていれば、それが最終結果になります。
CTMULTISERVICEPV1 が uxc:* を Deny しないだけでは、GRREGIONDENY の Deny を打ち消すことはできません。
そのため、CT.MULTISERVICE.PV.1 を追加しても効果がないという結果になりました。
対処方法について
管理対象リージョンに us-east-1 を追加する
ランディングゾーンの管理対象リージョンに us-east-1 を追加すれば、GRREGIONDENY の許可リージョンに us-east-1 が含まれるようになり、アカウントカラーを設定できるようになります。
管理対象リージョンに us-east-1 を追加した状態のランディングゾーン設定画面
アカウントカラー変更前（黄色）
アカウントカラー変更後（紫）
us-east-1 は CloudFront 用の WAF や ACM のデプロイ先でもあり、管理対象リージョンに含めている環境は多いと思います。ただし、管理対象リージョンを追加すると Config や CloudTrail の記録対象も増えるため、コストへの影響は考慮が必要です。
ランディングゾーンのリージョン拒否コントロールを無効化する
ランディングゾーンレベルのリージョン拒否コントロール（GRREGIONDENY）を無効化し、代わりに CT.MULTISERVICE.PV.1 のみで各 OU のリージョン制御を行う方法が考えられます。
GRREGIONDENY がなくなれば Deny の競合が解消されるため、CT.MULTISERVICE.PV.1 の ExemptedActions で uxc:* を除外すればアカウントカラーを設定できるようになるはずです。
ただし、既存のすべての OU に対して CT.MULTISERVICE.PV.1 を個別に設定し直す必要があり、影響範囲が大きいため、あまり現実的な方法ではないと思っています。
さいごに
Control Tower のリージョン拒否コントロールが有効な環境で、アカウントカラーが設定できない事象と検証結果をご紹介しました。
アカウントカラーのような比較的新しい機能は、リージョン拒否コントロールのグローバルサービス除外リストに含まれていないことがあります。
コンソール上の設定で突然アクセス拒否されたときは、SCP の影響を疑ってみてください。
なお、根本的には GRREGIONDENY の NotAction リストに uxc:* が含まれていないことが原因なので、この件については AWS にフィードバックしてもいいんじゃないかなと思ってます。
この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部コンサルティング部のいたくら（@itkr2305）でした！
