AWS Security Hub CSPM の Finding が Aurora のバックアップ中に再作成された話

セキュリティサービス部佐竹です。
今回は、AWS Security Hub CSPM を運用する中で、特定のコントロールの検出結果 (Finding) が意図せず ARCHIVED (アーカイブ済み) となり、その後に同じ内容で再作成されてしまった事象に遭遇したため、その原因と仕様について解説します。

はじめに
- Security Hub CSPM での定期的な通知の抑制について
発生した事象: 意図しない Finding 再作成
原因は Aurora バックアップと Security Hub CSPM の評価仕様
- 調査の過程に関する補足
対策と今後の考慮事項
まとめ

はじめに

本ブログは AWS Security Hub CSPM の運用者を主な対象としており、AWS のセキュリティ運用に携わる中級レベル以上の方向けの内容となっています。

さて、AWS Security Hub CSPM （AWS re:Inforce 2025 において、AWS Security Hub から改名）は、AWS 環境全体のセキュリティ状況を一元的に可視化し、ベストプラクティスからの逸脱を自動で検出してくれる、CSPM (Cloud Security Posture Management) のサービスです。

我々もお客様の環境で AWS Security Hub CSPM のうち、特に「AWS Foundational Security Best Practices v1.0.0 標準」を有効化した後、検出された Findings をトリガーとした通知システムをサバソックにおいて「構築・運用」しています。

Security Hub CSPM での定期的な通知の抑制について

通常、一度検出された個々の Finding は、その結果が適切に修正されるまで ACTIVE な状態を維持し、そのステータスの変化は History として追跡されます。また、Security Hub CSPM は、以下の仕様を持っています。

Regardless of your chosen recording period, Security Hub CSPM checks every 18 hours to ensure no resource updates from AWS Config were missed.

選択した記録期間に関係なく、Security Hub CSPM は 18 時間ごとにチェックを行い、AWS Config からのリソース更新が見逃されていないことを確認します。

https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-schedule.html

このため、18時間に1度程度、定期的に通知が送られてきてしまいます。これを再通知しないためにはその Finding に対して「Suppress」するなどの対応を別途行う必要があります。

この定期的な通知がノイズとならないように、サバソック通知システムでは「ACTIVE なままの Finding の定期的な更新」は基本的に通知を抑制し、「新規 (NEW) の Finding」が作成された場合にアラートを発するよう設計しています。

しかし先日、この前提が崩れる事象が発生しました。どういう事象かというと AWS Security Hub CSPM (FSBP) における「ある Finding がアーカイブされ、その後に同じ内容の Finding が新規で作成された」ことで、本来は抑制されるべき通知がお客様へ送信されてしまったということがありました。

本ブログでは、この事象の調査経緯と、AWS サポートへの問い合わせによって明らかになったその原因、そして背景にある仕様について詳しく解説します。

発生した事象: 意図しない Finding 再作成

今回この事象が発生したのは、AWS のセキュリティ基準である「AWS Foundational Security Best Practices v1.0.0」に含まれる、以下のコントロールでした。

[RDS.45] Aurora MySQL DB clusters should have audit logging enabled (Aurora MySQL DB クラスターでは、監査ログ記録を有効にする必要があります)

このコントロールに以前より長らく違反（FAILED）していた、とある Aurora クラスターに対し、1つの Finding が ARCHIVED になり、その後に新しい Finding が作成されました。以下はその調査のために行ったことです。

新規作成された、NEW の Finding の履歴

まず、新規に作成された NEW Finding の履歴です。

こちらの履歴は、以下のようになっています。

October 1, 2025 04:44:21 (UTC+00:00)
- Finding Created
October 1, 2025 16:16:21 (UTC+00:00)
- ProductFields PreviousComplianceStatus added 'FAILED'

この後確認する古い Finding のステータスが NOT_AVAILABLE に更新されたのと全く同じタイムスタンプで、新しい Finding が作成されていました。そしてその後に、ステータスが FAILED として記録されています。

これにより、サバソック通知システムは「新規のセキュリティリスクが検出された」と判断し、通知を実行してしまいました。

ARCHIVED となった既存の Finding の履歴

次に、アーカイブされた古い Finding の履歴 (History) を確認しました。

履歴を見ると、以下のイベントが記録されていました。

September 30, 2025 16:14:03 (UTC+00:00)
- Compliance Status が FAILED から NOT_AVAILABLE に変更
October 1, 2025 04:44:21 (UTC+00:00)
- ProductFields PreviousComplianceStatus が FAILED から NOT_AVAILABLE に変更

この時、Compliance StatusReasons (準拠ステータスの理由) として CONFIG_RETURNS_NOT_APPLICABLE が追加されていたことが確認できました。これは「AWS Config が NOT_APPLICABLE (適用外) を返したため」ということを示しています。

画面右下には以下のメッセージが表示されています。

Compliance StatusReasons added
'[{"ReasonCode":"CONFIG_RETURNS_NOT_APPLICABLE","Description":"This finding has a compliance status of NOT AVAILABLE because AWS Config sent Security Hub a finding with a compliance state of Not Applicable. The potential reasons for a Not Applicable finding from Config are that (1) a resource has been moved out of scope of the Config rule; (2) the Config rule has been deleted; (3) the resource has been deleted; or (4) the logic of the Config rule itself includes scenarios where Not Applicable is returned. The specific reason why Not Applicable is returned is not available in the Config rule evaluation."}]'

(和訳) コンプライアンスステータスの理由が追加されました '[{"ReasonCode":"CONFIG_RETURNS_NOT_APPLICABLE","Description":"この結果のコンプライアンスステータスは「利用不可」です。これは、AWS Config が Security Hub にコンプライアンス状態が「該当なし」の結果を送信したためです。Config から「該当なし」の結果が返される理由として考えられるのは、(1) リソースが Config ルールの適用範囲外に移動された、(2) Config ルールが削除された、(3) リソースが削除された、(4) Config ルール自体のロジックに「該当なし」が返されるシナリオが含まれている、のいずれかです。「該当なし」が返される具体的な理由は、Config ルールの評価では確認できません。"}]'

今回、この4つの理由のうちどれかに該当したであろうことが推測できます。

この NOT_AVAILABLE へのステータス変更に伴い、RecordState が ACTIVE から ARCHIVED に変更され、この Finding はクローズされた扱いになっていました。

根本原因は何か？

ではなぜ、既存の Finding が更新され続けるのではなく、一度アーカイブされてから新規作成されるという挙動になったのでしょうか。

具体的には、先の4つの理由のうちどれに該当したのでしょうか？

原因は Aurora バックアップと Security Hub CSPM の評価仕様

結論からお伝えすると、この事象は不具合ではなく、Aurora DB クラスターのバックアップ処理と、Security Hub CSPM (と、その裏側で動作している AWS Config Rules) のコントロール評価のタイミングが重なったことによる仕様通りの動作でした。

本件に関して、調査後に、裏取りをするため AWS サポートにも質問を行っています。その回答で明らかになった、一連のシーケンスは以下の通りです。

Aurora のバックアップ処理が開始される
- バックアップ中、対象の DB クラスターのステータスは一時的に "Available" 以外 (例: "backing-up") に変わります。
Security Hub のコントロール評価が実行される
- コントロール [RDS.45] の評価は、裏側で動作している AWS Config ルール (aurora-mysql-cluster-audit-logging) によって行われます。
- この Config ルールは、ステータスが "Available" のクラスターのみを評価対象とする仕様になっています。
Config ルールが評価をスキップする
- バックアップ処理中のため、クラスターのステータスは "Available" ではありません。
- そのため、Config ルールはこのリソースを評価対象外と判断し、評価結果として "NOT_APPLICABLE" (適用外) を返します。
Security Hub が Finding をアーカイブする
- Security Hub は、関連する Config ルールから "NOT_APPLICABLE" という評価結果を受け取ると、「このリソースはもはや監視対象ではない」と判断し、既存の Finding を自動的に ARCHIVED に変更します。これは公式ドキュメントにも記載されている仕様です。
The associated AWS Config evaluation returned NOT_APPLICABLE for the compliance status of the specified resource.
https://docs.aws.amazon.com/securityhub/latest/userguide/controls-findings-create-update.html#securityhub-standards-results-updating
バックアップ完了後、次の評価で新しい Finding が作成される
- バックアップが完了し、クラスターのステータスが "Available" に戻ります。
- 次回の定期的なコントロール評価のタイミングで、Config ルールは再びこのクラスターを評価対象とします。
- 監査ログは依然として無効なため、評価結果は "NON_COMPLIANT" となり、コントロールのステータスは "FAILED" となります。
- ARCHIVED 済みの古い Finding は活用されず、Security Hub CSPM は新しい Finding を作成します。

この一連の流れにより、「アーカイブ」と「新規作成」が立て続けに発生し、結果的には別の Finding が生成されたことで、通知システムによる通知（メールの送信）が行われました。また、この動作は Security Hub CSPM と AWS Config ルールの仕様であり、回避策はないとのことです。

調査の過程に関する補足

AWSサポートへ問い合わせる前に、私は調査のため Aurora Cluster の AWS Config タイムラインを確認していました。

上図の通り、確かに特定のタイミングで一時的にリソースが非準拠 (NON_COMPLIANT) から準拠 (COMPLIANT) に変わった記録が残っていました。

しかし、これは実際には評価がスキップされ、非準拠のプロパティが Diff から消えたことで見かけ上 COMPLIANT になっていただけでした。この背後で起きていた根本的な事象である「バックアップ処理による Aurora のステータス変化」というトリガーまでは特定できませんでした。

対策と今後の考慮事項

繰り返しになりますが、この挙動は AWS の仕様であるため根本的な解決策は現状ありません。AWS サポートからも、以下のいずれかの対応を検討するよう案内がありました。

通知システム側で抑制ロジックを強化する
- 今回の事象を許容し、通知システム側で「特定の Finding が ARCHIVED になった直後に、同じリソース・同じコントロールで NEW の Finding が作成された場合は通知を抑制する」といった、より高度なロジックを組み込む。
コントロールを無効化する
- もしこのコントロールによる監視が不要であれば、Security Hub CSPM の設定から無効化する。

今回のケースでは、コントロール自体は有効にしておきたいため、対策としては「1」が現実的です。しかし、通知システムの改修にはコストがかかるため、まずは「Aurora のバックアップ時間帯に発生するこの事象は仕様である」と関係者間で合意し、運用でカバーすることを検討しています。

重要なのは、このような事象が [RDS.45] 以外のコントロールでも、リソースのステータスに依存する評価ロジックを持つものであれば同様に発生しうる、という点です。

特に Aurora や RDS は定期的なバックアップ等で一時的にステータスが Available 以外になることもよくあるため、Aurora/RDS に関わる運用において頭の片隅に入れておくべき仕様として、新たな知見が得られました。

なおこれは余談ですが、RDS で一時的にステータスが Available 以外になる場合にはその他の API 操作を受け付けないため、定期的な Snapshot の作成ジョブがそれにより稀に失敗してしまう、ということも発生します。これは何度か経験していたので言われて見れば今回の件もそれと同様の事態だったのですが、同原因であることにはなかなか気付けませんでした。

まとめ

今回のブログでは、Aurora のバックアップと AWS Security Hub CSPM の評価タイミングが重なることで、Finding が意図せず再作成される事象について、その原因と仕様を解説しました。

事象: Security Hub CSPM の [RDS.45] の Finding が突然 ARCHIVED になり、直後に同じ内容で Finding が NEW として再作成された。
原因: Aurora のバックアップ中、クラスターのステータスが Available 以外になる。そのタイミングで実行された Config ルールの評価が NOT_APPLICABLE となり、仕様に基づいて既存の Finding がアーカイブされたため。バックアップ完了後の再評価で、新たな Finding が作成された。
対策: AWS の仕様であるため、通知システム側で抑制ロジックを強化するか、運用上の「既知の事象」として受け入れる。

本ブログが、同様の事象に直面した方の助けになれば幸いです。

では、またお会いしましょう。