どうも、ちゃだいん（@chazuke4649）です。
あれ、これControl TowerのSCPでブロックされてるやん
AWS Control Towerを運用している環境で、何か作業実施時にControl Towerが生成したSCPによってブロックされることがたまにあります。
ほとんどの場合、それは正しい挙動です。いわゆるControl Towerの機能であるガードレール/コントロールによる予防的統制であったり、あるいはControl Towerの仕組みを破壊しないようにするための防御であったりするSCPが正常に機能しているといえます。
ただし、稀に例外的にそれでも変更したいケースがあります。以下は１例です。
例)Auditアカウントにて、AWS Configコンプライアンス変更時のメール通知をフィルタしたい
Control Tower の標準的な機能として、Auditアカウントのルートメールアドレスに、AWS Configで管理されたリソースがルールに非準拠となった場合に通知することができます。
Compliance notifications by SNS in the audit account - AWS Control Tower
ただ、デフォルトのEventBridgeルールだと全てのAWS Configの変更通知をメールで行うため、例えばAWS Security Hubを有効化しAuditアカウントへ管理委譲すると、Security Hubによって作られた大量のAWS Configルールへの非準拠もメール通知されます。
本来AWS Security Hubの通知は別管理したいものですが、AWS Control Towerの仕様上は大量通知が届いてしまいます。
この考慮事項と対策に関してドキュメントに記載があります。
- AWS Control Tower の SNS トピックは、設計上、非常にノイズが多いです。たとえば、AWS Config は、AWS Config が新しいリソースを検出するたびに通知を送信します。
- SNS トピックから特定のタイプの通知を除外したい管理者は、AWS Lambda 関数を作成し、それを SNS トピックにサブスクライブできます。または、このサポート記事「AWS Config を使用して AWS リソースが非準拠の場合に通知を受けるにはどうすればよいですか?」で説明されているように、EventBridge ルールを設定して通知をフィルタリングすることもできます
では、このドキュメントに書かれている対策通り、「EventBridgeルールを変更してSecurity Hub関連は除外」をするとします。
具体的には、AuditアカウントのEventBridgeルール aws-controltower-ConfigComplianceChangeEventRule のイベントパターンが現状は以下となります。
{
"detail-type": ["Config Rules Compliance Change"],
"source": ["aws.config"]
}これを、Security Hub関連のみ除外します。
{
"detail-type": ["Config Rules Compliance Change"],
"source": ["aws.config"],
"detail": {
"configRuleName": [{
"anything-but": {
"prefix": "securityhub"
}
}]
}
}詳細は以下ブログがわかりやすいです。
[小ネタ]Config Rulesのイベント通知でコンテンツフィルタリングを使ってSecurity Hubのルールの通知を除外する | DevelopersIO
ただし、（ここでようやく本題に戻り）、この変更を実施しようとすると、以下Control Towerの必須のコントロール（SCP）がAuditアカウントに適用されているので、ブロックされてしまいます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GRCLOUDWATCHEVENTPOLICY",
"Effect": "Deny",
"Action": [
"events:PutRule",
"events:PutTargets",
"events:RemoveTargets",
"events:DisableRule",
"events:DeleteRule"
],
"Resource": [
"arn:aws:events:*:*:rule/aws-controltower-*"
],
"Condition": {
"ArnNotLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/AWSControlTowerExecution"
}
}
}
]
}そんな場合はどうしたものでしょうか？
ワークアラウンド1: AWSControlTowerExecutionへスイッチロールする
公式で推奨されている方法ではないので、実施は自己責任かつ最終手段としてご理解ください。ガイダンスににも原則的にはControl Towerが作成したリソースの変更はNGとなっています。
メンバーアカウント側の AWSControlTowerExecution IAMロールを利用する方法です。
これは、ブロックされるControl Towerが生成するSCPにて、以下記述のように例外登録されていれば、このロールを使用すればブロックされません。
"Condition": {
"ArnNotLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/AWSControlTowerExecution"
}
}マネジメントコンソールにて
流れとしては（コンソール操作で実施する場合の例）
- 組織管理アカウントへIdentity Centerポータルにて、Admin相当のユーザーでログインする
- ブラウザ拡張「AWS Extend Switch Roles」にて、プロファイル設定を追加する
- クロスアカウントのスイッチロールする（スイッチ先のメンバーアカウントとして実行可能になる）
- 作業を実施する
※2.に関しては以下ブログをどうぞ。
管理アカウントでAdmin権限でログイン後、以下のようなARNでプロファイルを追加します。
arn:aws:iam::111122223333:role/AWSControlTowerExecution(※111122223333は対象のメンバーアカウントのAWSアカウントIDに差し替える)
クロスアカウントのスイッチロールを実行します。
すると、対象メンバーアカウントの当該IAMロールとしてログインできます。
先述のケースでエラーになった作業が成功しました。
AWS CLIにて
詳細は割愛しますが、以下ブログにてCLIでのスイッチロール方法を紹介しています。
ワークアラウンド2: 一時的にSCPを外して作業実施し、元に戻す
再掲）公式で推奨されている方法ではないので、実施は自己責任かつ最終手段としてご理解ください。ガイダンスににも原則的にはControl Towerが作成したリソースの変更はNGとなっています。
対象メンバーアカウントの先述のSCPがアタッチされているOUから、手動で一時的にSCPをデタッチし、作業実施してから、再度OUにSCPを付け直す方法です。
管理アカウントにてAdmin権限があれば技術的には可能ではあり、試したところ実施できました。
ただし、SCPを戻した後にControl Towerコンソールを開くと以下の通り、改変イベントを検出したため「ランディングゾーンの修復」が必要な状態になってしまいます。
「修復」を実行すると、一度ランディングゾーンが正しい状態になっているか確認・是正する処理が走り、最終的に問題がなくなればOKとなります。（組織の規模によって、数十分程度時間がかかります）
とはいえ、極力回避したい行為ではあると思うので、個人的にはスイッチロールの方がベターと考えます。
現場からは以上です。
2
