Security Hub CSPMの標準を再有効化しても削除済みリソースの Finding が残り続ける

Security Hub CSPMの標準を再有効化しても削除済みリソースの Finding が残り続ける

2026.03.18

はじめに

Security Hub CSPM の Finding 一覧を確認していたところ、すでに削除したリソースに対する失敗した Finding が残り続けていることに気づきました。

過去の Findings が適切に更新されずに、残ってしまうケースがあるようです。

実際に再現検証してみたのでまとめます。

先に結論

標準の無効化→リソース削除→再有効化という流れで、以下の問題が発生します。

  • 削除済みリソースに対する FAILED Finding が ACTIVE のまま残り続ける
  • 再有効化で Config Rule は再作成されるが、旧 Config Rule に紐づいた Finding は再評価されない
  • 24 時間経過するとコンソールのコントロール画面からは非表示になるが、API では取得できてしまう

security-hub-cspm-stale-findings-problem-flow.png

前提条件

項目 内容
リージョン ap-northeast-1(東京)
セキュリティ基準 AWS Foundational Security Best Practices(AFSBP)v1.0.0
検証対象コントロール EC2.18, EC2.19

検証の流れ

今回の検証は以下のステップで進めます。

  1. 検証用セキュリティグループを作成し、FAILED Finding が生成されるのを待つ
  2. AFSBP 標準を無効化する
  3. セキュリティグループを削除する
  4. AFSBP 標準を再有効化する
  5. 削除済みリソースの Finding が残っているか確認する

やってみる

検証用セキュリティグループの作成

まず、わざと FAILED になるセキュリティグループを作ります。SSH(ポート 22)を 0.0.0.0/0 で開放すれば EC2.18 / EC2.19 に引っかかります。

> aws ec2 create-security-group \
    --group-name "test-sg" \
    --description "Verification for CSPM finding persistence test" \
    --region ap-northeast-1
{
    "GroupId": "sg-093193fcb3867fc14",
    "SecurityGroupArn": "arn:aws:ec2:ap-northeast-1:123456789012:security-group/sg-093193fcb3867fc14"
}
> aws ec2 authorize-security-group-ingress \
  --group-id sg-093193fcb3867fc14 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0 \
  --region ap-northeast-1

Screenshot 2026-03-17 午前11.02.09.png

FAILED Finding の確認

数分待つと、Config Rule による評価が走り、Security Hub CSPM に FAILED Finding が生成されます。

Screenshot 2026-03-17 午前11.08.03_redacted.png

この Findings を検知した Config ルールはそれぞれ以下です。

  • EC2.18: securityhub-vpc-sg-open-only-to-authorized-ports-5770145b
  • EC2.19: securityhub-vpc-sg-restricted-common-ports-163491f2

ここまでの流れで通常の検知は確認できました。
security-hub-cspm-stale-findings-normal-flow.png

AFSBP 標準の無効化

ここからが検証の本番です。AFSBP 標準を無効化します。

Screenshot 2026-03-17 午前11.12.06.png

Config Rule 削除の確認

AFSBP 標準を無効化すると、Security Hub CSPM が管理していた Config Rule が削除されます。

Screenshot 2026-03-17 午前11.14.27.png

数分で全て削除されるので待ちます。

セキュリティグループの削除

Config Rule が存在しない状態で、検証用セキュリティグループを削除します。

Screenshot 2026-03-17 午前11.16.00.png

通常 AFSBP 標準が有効化されていれば、削除のタイミングで再評価が行われます。
しかし、評価する Config ルールが削除されているため、元のステータスのまま検出結果には残り続けます。

Screenshot 2026-03-17 午前11.08.03_redacted.png

AFSBP 標準の再有効化

セキュリティグループを削除した後に、AFSBP 標準を再有効化します。

Screenshot 2026-03-17 午前11.33.45.png

数分後に Config Rule も再作成されました。

Screenshot 2026-03-17 午前11.37.14.png

残存 Finding の確認

さて、ここが今回の検証で最も重要なポイントです。削除済みセキュリティグループの Finding は果たして残っているのか。

しばらく経っても Findings が更新されません。

削除済みのセキュリティグループに対する Finding が、ACTIVE / FAILED / NEW のまま残っています。 UpdatedAt も無効化前の値から変わっていません。EC2.19 も同様です。

念のため、セキュリティグループが本当に存在しないことを確認します。

> aws ec2 describe-security-groups --group-ids sg-093193fcb3867fc14 --region ap-northeast-1
An error occurred (InvalidGroup.NotFound) when calling the DescribeSecurityGroups operation:
The security group 'sg-093193fcb3867fc14' does not exist

リソースは確かに削除済みですが、Finding は残り続けています。

Findings に紐づいている Config ルールも確認してみると、削除されているためエラーとなりました。

>  aws configservice describe-config-rules \
    --config-rule-names securityhub-vpc-sg-open-only-to-authorized-ports-5770145b \
    --query 'ConfigRules[].{Name:ConfigRuleName,State:ConfigRuleState}'

aws: [ERROR]: An error occurred (NoSuchConfigRuleException) when calling the DescribeConfigRules operation: One or more ConfigRules provided in the request are invalid. Please check the configRule names.

>  aws configservice describe-config-rules \
    --config-rule-names securityhub-vpc-sg-restricted-common-ports-163491f2 \
    --query 'ConfigRules[].{Name:ConfigRuleName,State:ConfigRuleState}'

aws: [ERROR]: An error occurred (NoSuchConfigRuleException) when calling the DescribeConfigRules operation: One or more ConfigRules provided in the request are invalid. Please check the configRule names.

AFSBP 標準の再有効化により新しい名前で Config ルールが再作成されています。サフィックスが変わっているため、旧 Finding が参照している Config ルールとは別物です。

# EC2.18
- securityhub-vpc-sg-open-only-to-authorized-ports-5770145b
+ securityhub-vpc-sg-open-only-to-authorized-ports-911376e5

# EC2.19
- securityhub-vpc-sg-restricted-common-ports-163491f2
+ securityhub-vpc-sg-restricted-common-ports-ec0b145a

つまり、旧 Config ルールに紐づいた Finding は、新しい Config ルールでは再評価されないということです。

Screenshot 2026-03-17 午前11.51.51_redacted.png

ここまでの検証を整理すると、このような流れになります。
security-hub-cspm-stale-findings-problem-flow.png

なぜこうなるのか

この事象の根本原因は、Config Rule のライフサイクルと Finding の更新のギャップにあります。

  1. AFSBP 標準を無効化すると、Security Hub CSPM 管理の Config Rule が全て削除される
  2. Config Rule が存在しない間にリソースを削除しても、再評価が発生しない
  3. AFSBP 標準を再有効化すると Config Rule は再作成されるが、再評価の対象は現在存在するリソースのみ
  4. 削除済みリソースは評価対象外のため、古い Finding が ACTIVE / FAILED のまま取り残される

つまり、Security Hub CSPM は「Config Rule が削除された」ことと「リソースが削除された」ことを紐づけません。Finding を自動アーカイブする仕組みがないためです。

24 時間経つとコンソールから見えなくなる

ここでもう 1 つ注意すべき挙動があります。

Security Hub CSPM のコントロール画面には以下の記載があります。

Security Hub CSPM determines control status based on control findings in the last 24 hours.

コントロールのステータスは直近 24 時間の Finding に基づいて判定されます。つまり、残存した古い Finding は UpdatedAt が更新されないまま 24 時間が経過すると、コントロール画面やセキュリティスコアの計算対象から外れます

AFSBP 標準を再有効化してから 24 時間以内であれば、コントロール画面に FAILED として古い Finding が表示されます。しかし 24 時間を過ぎると表示されなくなります。セキュリティスコアにも反映されなくなるため、コンソール上は問題がないように見えます。

24 時間以内であれば、再有効化した後でも Config ルールが古い状態の Finding をコントロール画面から確認できました。

Screenshot 2026-03-18 午前8.15.56_redacted.png

これが 24 時間を超えると非表示になります。

Screenshot 2026-03-18 午前11.34.32_redacted.png

しかし、Finding レコード自体は ACTIVE / FAILED のまま残り続けていますGetFindings API や AWS CLI の get-findings で取得すると、これらの古い Finding はそのまま返ってきます。

> aws securityhub get-findings \
    --filters '{"ResourceId": [{"Value": "arn:aws:ec2:ap-northeast-1:123456789012:security-group/sg-093193fcb3867fc14", "Comparison": "EQUALS"}]}' \
    --query 'Findings[].{Id:Id,Status:Compliance.Status,UpdatedAt:UpdatedAt,Workflow:Workflow.Status}'

[
    {
        "Id": "arn:aws:securityhub:ap-northeast-1:123456789012:security-control/EC2.19/finding/64eb6249-1f7e-464b-b7e0-d41ebd5bf220",
        "Status": "FAILED",
        "UpdatedAt": "2026-03-17T02:03:42.992Z",
        "Workflow": "NEW"
    },
    {
        "Id": "arn:aws:securityhub:ap-northeast-1:123456789012:security-control/EC2.18/finding/32e70daa-d8e7-48ad-9559-6c305a28dd7a",
        "Status": "FAILED",
        "UpdatedAt": "2026-03-17T02:03:35.075Z",
        "Workflow": "NEW"
    }
]

これによってコントロール画面と、API で取得した Finding の状態に乖離が生じます。たとえば API 経由で FAILED Finding の数を監視しているケースでは、コンソール上は問題なしに見えるのに API 側では取得されてしまいます。

対処法

API 取得時のフィルタ追加

GetFindings API で Finding を取得している場合は、UpdatedAt フィルタを追加することで再評価されていない古い Finding を除外できます。
1 日以上更新がない Finding は除外するようにしましょう。

# 直近1日間に更新されたFindingのみ取得
"UpdatedAt": [{"DateRange": {"Value": 1, "Unit": "DAYS"}}],

手動での対処

コンソールまたは API から、対象の Finding のワークフローステータスを解決済み(RESOLVED)に変更しましょう。コントロール画面と検出結果画面のどちらから操作しても、同一の Finding レコードが更新されます。

Screenshot 2026-03-17 午前11.56.10_redacted.png

まとめ

AFSBP 標準の無効化中に削除したリソースの Finding は、再有効化後も残り続けます。 ステータスは ACTIVE / FAILED のままです。Config Rule が再作成されても、削除済みリソースは再評価されません。

さらに、24 時間が経過するとコンソールのコントロール画面やセキュリティスコアには反映されなくなりますが、Finding レコード自体は残り続けます。API 経由で Finding を取得しているケースでは、コンソールとの乖離に注意が必要です。

Finding を API やツールで取得している場合は、UpdatedAt フィルタを入れておくと古い Finding を除外できます。同じ事象で困っている方の参考になれば幸いです。

以上、鈴木純がお送りしました。

参考

この記事をシェアする

FacebookHatena blogX

関連記事