【失敗談】適合パックの展開前にSCPを見直そう

はじめに

AWS Config の適合パックを更新した際に失敗し、その後の復旧もひと手間では済まない状態になりました。

直接の原因は、Config 適合パックが作成した CloudFormation スタックにサービスロールを付与してしまったことです。
実際には単純な操作ミスというより、いくつかの運用判断が重なって起きたものでした。

この記事では、発生したエラーの内容、対処方法、なぜ復旧が面倒になったのか、そして再発防止としてどんな制御を入れるべきかを整理します。

この記事で言いたいこと（結論）

言いたいことはシンプルです。 awsconfigconforms から始まるスタックは、SCP で更新や削除を制限しましょう！ということです。 後で更新するときに大変面倒なことになります。

発生した事象

Config 適合パックのStackSet更新時に、以下のエラーが発生しました。

ResourceLogicalId: xxxxxxx
ResourceType: AWS::Config::ConformancePack
ResourceStatusReason: Resource handler returned message: "Resource handler returned message: \"Calling service principals does not contain the owner of the SLCR (Service: AmazonConfig; Status Code: 400; Error Code: InsufficientPermissionsException)\""

権限不足のように見えますが、StackSet の実行ロールには AdministratorAccess が付与されているので、基本的にはそのようなことはないと認識していました。
失敗したスタックを実際に見に行くと、CloudFormation スタックにサービスロールが付与されていました。

失敗までの流れ

今回の事象は、次のような流れで発生しました。

1. Config 適合パックを CloudFormation StackSet を使い展開
2. StackSet 関連のスタックと awsconfigconforms で始まるスタックが作成
3. Security Hub CSPM の新規コントロールとして CloudFormation.4 が追加
4. 各アカウントで CloudFormation.4 の検知が発生
5. 是正対応として、担当者が awsconfigconforms- のスタックにサービスロールを付与
6. Config 適合パックの更新が失敗

何が問題だったのか

失敗の直接的な原因は awsconfigconforms から始まるスタックにサービスロールが付与されていたことでした。
このスタックによって作られるConfigルールは特別なサービスロールでのみ操作ができるものです。
ユーザー側でサービスロール設定してしまうと、たとえAdministratorAccessが付与されていても操作ができなくなります。

また、このような状況になった背景には、いくつかの要素がありました。

StackSet が展開するスタック以外にスタックが作られる

StackSet で適合パックを展開すると最小構成でも以下のようなスタックが作成されます。

• StackSet で始まるスタック（IAMロールや適合パックのスタック）
• awsconfigconforms で始まるスタック（適合パックに使われるルールや修復アクションのスタック）

awsconfigconforms のスタックは AWS Config によって内部的に作成されるスタックです。 この仕様が次の問題を生みます。

SCP でスタックの操作を制限していない

このうち StackSet 側は、操作を制限するように SCP で制御していました。
一方で awsconfigconforms 側は、SCP で制御していなかったため、各アカウントの担当者が操作できる状況でした。

そして次の点が各担当者に操作させるきっかけになりました。

Security Hub CSPM コントロール CloudFormation.4 が追加された

2026年の初頭に Security Hub CSPM のコントロールに CloudFormation.4 が追加されるアップデートが行われました。

CloudFormation.4 は「CloudFormation のスタックにはサービスロールを設定しましょう」というコントロールです。
基本的には推奨されるものなのですが、適合パックにおいてはその限りではありません。

本コントロールが追加されたことにより各アカウントで awsconfigconforms のスタックが検知され、担当者が是正対応としてサービスロールを付与することになりました。
我々もこのアップデートに気が付き各担当者に操作しないよう通達して SCP を修正したのですが、時すでに遅しでした。
素早く是正対応をしていた方が数名いたのです(もちろんこの方々は何も悪くないです。)
さらに、CloudFormation のサービスロールは一度設定すると後から外すことができません。（この仕様どうにかしていただけないでしょうか、、、）

対処方法

今回のような状態になってしまった場合、StackSet からの更新や削除は失敗してしまいます。
さらに、AWS Config から作成された Config ルールは自力では削除できないため、AWS サポートに依頼する必要があります。

今回のケースでは以下の順序で対応する必要があります。

1. StackSet から対象のアカウント・リージョンに対してスタックを保持したまま削除を実行する
2. 対象のアカウントにログインしてスタックを削除する
3. 削除に失敗するためもう一度強制的に削除を実行する（Config ルールのみ残る）
4. AWS サポートに対して残った Config ルールの削除を依頼する

再発防止策

もっとも有効な再発防止策は、StackSet 由来のスタックだけでなく、awsconfigconforms のスタックも SCP で保護することです。
例えば、以下のように CloudFormation の更新・削除を特定ロール以外に許可しない SCP を設定しておくと、意図しない変更を防ぎやすくなります。

※ Condition句にあるロールARNはご自身の環境で使用するものに置き換えてください。

{
    "Effect": "Deny",
    "Action": [
        "cloudformation:DeleteStack",
        "cloudformation:UpdateStack",
        "cloudformation:UpdateStackInstances"
    ],
    "Resource": [
        "arn:aws:cloudformation:::stack/StackSet-/",
        "arn:aws:cloudformation:::stack/awsconfigconforms-/"
    ],
    "Condition": {
        "ArnNotLike": {
            "aws:PrincipalArn": [
                "arn:aws:iam::*:role/stacksets-exec-xxxx"
            ]
        }
    }
}

終わりに

今回の件では、各アカウントの担当者がサービスロールを付与してしまいましたが、むしろそれ自体は正しい判断だと言えます。彼らは仕事を全うしたに過ぎません。
大切なことは、対象リソースに対して操作できない状態を先に作っておくことでした。
運用で防ぐより、権限制御で防ぐほうが確実です。

Config適合パックを展開する人々に届き、被害者が減ると嬉しいです。

この記事は私が書きました

渡邉 和貴

記事一覧

CCoEをやってます。森と山に出没します。 好きなAWSサービスは IAM と CloudFormation