AWS Control TowerのSCPでDenyされるアクションを一時的に実行するワークアラウンド

どうも、ちゃだいん（@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"
        }
      }
    }
  ]
}

引用元）Disallow Changes to Amazon CloudWatch Set Up by AWS Control Tower (AWS Control Tower によって設定された Amazon CloudWatch への変更を不許可にする)|AWS Control Tower

そんな場合はどうしたものでしょうか？

ワークアラウンド1: AWSControlTowerExecutionへスイッチロールする

公式で推奨されている方法ではないので、実施は自己責任かつ最終手段としてご理解ください。ガイダンスににも原則的にはControl Towerが作成したリソースの変更はNGとなっています。

メンバーアカウント側の AWSControlTowerExecution IAMロールを利用する方法です。

これは、ブロックされるControl Towerが生成するSCPにて、以下記述のように例外登録されていれば、このロールを使用すればブロックされません。

      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/AWSControlTowerExecution"
        }
      }

マネジメントコンソールにて

流れとしては（コンソール操作で実施する場合の例）

1. 組織管理アカウントへIdentity Centerポータルにて、Admin相当のユーザーでログインする
2. ブラウザ拡張「AWS Extend Switch Roles」にて、プロファイル設定を追加する
3. クロスアカウントのスイッチロールする（スイッチ先のメンバーアカウントとして実行可能になる）
4. 作業を実施する

※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となります。（組織の規模によって、数十分程度時間がかかります）

とはいえ、極力回避したい行為ではあると思うので、個人的にはスイッチロールの方がベターと考えます。

現場からは以上です。