こんにちは、近藤（りょう）です！
AWS Security Hub CSPM をローカル設定から中央設定へ切り替えた際、中央管理下にあるメンバーアカウントで利用している各リージョンにおいて、Config.1 のステータスが FAILED になるという事象が発生しました。
調査の結果、中央設定の 「ホームリージョン／リンクされたリージョン」の構成 、Config.1 の「includeConfigServiceLinkedRoleCheck」パラメータ や AWS Config の「includeGlobalResourceTypes」パラメータの組み合わせが FAILED の発生要因となっていることが分かりました。
本記事では、今回の事象の背景と対処方法について検証結果を交えてご紹介します。
前提
Config.1 について
AWS Security Hub CSPM が提供するセキュリティチェックの 1 つで、「AWS Config が有効になっており、正しいロールと設定でリソース記録が行われているか」を評価するコントロールです。
- AWS Config が現在のリージョンで有効か
- 必要な AWS リソースが記録されているか
- サービスにリンクされたロール（
AWSServiceRoleForConfig）を使用しているか
なお、AWSServiceRoleForConfig をチェックしない場合は、Config.1 のパラメータを includeConfigServiceLinkedRoleCheck = false に設定を行います。
以下の公式ドキュメントをご参照下さい。
AWS Config の includeGlobalResourceTypes について
AWS の一部のサービスリソース（IAM、CloudFront、Route53 など）はグローバルリソース として扱われ、特定のリージョンに紐づかず、アカウント全体で 1 つのインスタンスとして存在します。
includeGlobalResourceTypes = true を設定した場合、AWS Config はこれらの グローバルリソースの設定変更（変更履歴）を記録し、変更の追跡も可能となります。
以下の公式ドキュメントをご参照下さい。
ローカル設定 と 中央設定 について
以下の公式ドキュメントをご参照下さい。
■ ローカル設定について docs.aws.amazon.com
■ 中央設定について docs.aws.amazon.com
ローカル設定時の構成
今回の事象は、以下の構成で運用をしている Security Hub CSPM を中央設定へ変更した際に確認ができました。
- 管理アカウントから 委任管理者アカウントへ Security Hub CSPM を委任済み
- Security Hub CSPM は ローカル設定で運用中
- ホームリージョン：ap-northeast-1
- クロスリージョン集約：us-east-1
- ローカル設定時点での Config.1 ステータス：PASSED
- ap-northeast-1 AWS Config のパラメータ：
includeGlobalResourceTypes= true - us-east-1 AWS Config のパラメータ：
includeGlobalResourceTypes= false - Config.1 のパラメータ：
includeConfigServiceLinkedRoleCheck = false*1
こちらがローカル設定時の構成となります。
Config.1 のコントロールの評価について
ホームリージョン（集約リージョン）、リンクされたリージョン、そのどちらでもない場合のどのパターンに該当するかによって挙動が変わります。
評価のポイントは AWS Identity and Access Management (IAM) グローバルリソースがそのリージョンで記録されるかのチェックとなり、パターンごとに評価方法が異なります。
■ 現在のリージョンが「ホームリージョン（集約リージョン）」の場合
IAM グローバルリソースが記録されている場合にのみ PASSED
■ 現在のリージョンが「リンクされたリージョン」の場合
IAM グローバルリソースの記録有無は評価しない
■ 現在のリージョンが「アグリゲータにない」場合、または「クロスリージョン集約がアカウントで設定されていない」場合
IAM グローバルリソースが記録されている場合にのみ PASSED
ローカル設定から中央設定への切り替え検証
Security Hub CSPM は、ローカル設定から中央設定へ比較的簡単に切り替えることができます。詳しい手順は、以下の公式ドキュメントおよび弊社ブログが参考になりますのでご参照いただければと思います。
検証の流れ
中央設定では、管理対象とする OU または AWS アカウントを指定し、Security Hub CSPM のポリシーを適用していきます。
今回は Config.1 の動作検証を行うため、ホームリージョンを ap-northeast-1 として、以下の 3 パターンで評価結果を比較しました。
- ① コントロールパラメータ なし＋リンクされたリージョン なし
- ②
includeConfigServiceLinkedRoleCheck = falseに設定 - ③ リンクされたリージョンに us-east-1 を追加
① コントロールパラメータ なし＋リンクされたリージョン なし
■ ① 検証構成と Config.1 のステータス概要
まず、Config.1 のコントロールを有効化したうえで、コントロールパラメータのカスタマイズなし、リンクされたリージョン設定なし の状態でステータスのコントロールを確認します。
■ コントロールパラメータのカスタマイズ なしの状態
■ リンクされたリージョン なしの状態
設定変更後、ローカル設定で使用していた Config.1 のパラメータ includeConfigServiceLinkedRoleCheck が false から true に強制的に変更されていました。
さらに、当環境では AWS Config にカスタムロールを使用しており、AWSServiceRoleForConfig を利用していないため、コントロールが失敗しているようです。
② includeConfigServiceLinkedRoleCheck = false に設定
■ ② 検証構成と Config.1 のステータスの概要
①の結果を受けて、Config.1 のパラメータ includeConfigServiceLinkedRoleCheck が ture に変更されていたので false に変更するために中央設定からポリシーの変更を行います。
■ Config.1 のパラメータ includeConfigServiceLinkedRoleCheck を false に変更
設定変更後、includeConfigServiceLinkedRoleCheck が false に反映されていることが確認でき、コントロールも成功となり正常に改善されました。
補足ですが、中央設定の管理下にあるため、メンバーアカウント側から直接コントロールパラメータを変更しようとするとエラーとなります。
③ リンクされたリージョンに us-east-1 を追加
■ ③ 検証構成と Config.1 のステータスの概要
今回は検証の都合上、初期状態では us-east-1 をリンクリージョンに含めていなかったため、 us-east-1 をリンクされたリージョンとして追加します。
us-east-1 がリンクされたリージョンに追加された後、us-east-1 の Config.1 のコントロールも成功しています。
まとめ
今回の検証により、Security Hub CSPM をローカル設定から中央設定へ切り替えた際の Config.1 の FAILED は、複数の設定が組み合わさることで発生し、改善方法もパターンごとに異なることが分かりました。
中央設定に移行することで設定管理が統一され、メンバーアカウント側での操作制限や、StackSets 運用からの解放によって運用負荷は大きく軽減されますのでまだローカル設定で運用している場合は、この機会に中央設定への移行をぜひ検討してみてください。
良い Security Hub ライフを!!
*1:当環境は AWS Config に カスタムロールを使用しており、AWSServiceRoleForConfig ではなく、必要な最小権限のみを付与しています。チェックによる誤検知を避ける目的で設定していました。
近藤 諒都
（記事一覧）カスタマーサクセス部CS5課
夜行性ではありません。朝活派です。
趣味：お酒、旅行、バスケ、掃除、家庭用パン作り（ピザも）など
2025 Japan AWS All Certifications Engineers
