AWS Security Hub CSPM のLastObservedAtとUpdatedAt、ProcessedAtの違いをまとめてみた

はじめに

AWS Security Hub CSPM のコントロール検出結果を Amazon EventBridge 経由で通知する運用は、以下の記事などで実装できます。

https://dev.classmethod.jp/articles/amazon-eventbridge-microsoft-teams/

通知内容は、記事に記載されている実装の場合、以下のような形式になります。

通知を導入後、アラート通知日時と、通知内容の「最終検知日時（LastObservedAt）」にズレがあることを確認しました。

なお、通知内容の「初回検知日時」は FirstObservedAt です。

例えば、次のような検出結果でズレが発生しました。

• EventBridge通知が発生したのは：2025年10月9日
• LastObservedAt（最終検知日時）：2025年10月5日

{
  "FirstObservedAt": "2025-10-01T00:00:00.000Z",
  "LastObservedAt": "2025-10-05T00:00:00.000Z",
  "UpdatedAt": "2025-10-09T00:00:00.000Z",
  "ProcessedAt": "2025-10-09T00:00:00.000Z",
  "Compliance": {
    "Status": "FAILED"
  }
}

4日間のズレが発生しており、運用上どの時刻を信頼すべきか判断に迷う状況でした。

また、UpdatedAtとProcessedAtはほぼ同時に更新されていますが、これらとLastObservedAtの関係も明確ではありませんでした。

本記事では、このズレが発生する理由と、LastObservedAt、UpdatedAt、ProcessedAtの3つのプロパティの正確な違いについて、ドキュメント調査と実際の検証結果をもとにまとめます。

各プロパティの公式ドキュメントでの説明

まず、公式ドキュメントでの各プロパティの説明を確認します。

LastObservedAt

コントロールの結果を生成および更新するでは、以下のように説明されています。

LastObservedAt – Security Hub CSPM が最後に指定されたコントロールとリソースのセキュリティチェックを実行したとき。

また、LastObservedAtの定義では、以下のように記載されています。

このタイムスタンプは、イベントまたは脆弱性が最後に観測された、または最後に観測された日時を指定します。したがって、これはこの結果記録が最後に更新された日時または最近更新された日時が反映される UpdatedAt タイムスタンプとは異なる可能性があります。

UpdatedAt

UpdatedAtの定義では、以下のように説明されています。

検出結果プロバイダーが最後に結果レコードを更新した日時を示します。このタイムスタンプは、検出結果レコードが最後または最も最近に更新された時刻を反映しています。したがって、イベントまたは脆弱性が最後または最も最近に検出された日時を反映する LastObservedAt タイムスタンプとは異なる可能性があります。

ProcessedAt

ProcessedAtの定義では、以下のように説明されています。

Security Hub CSPM が検出結果を受け取り、処理を開始した日時を示します。これは、検出結果プロバイダーとセキュリティ問題CreatedAtおよび検出結果とのやり取りに関連する必須のタイムスタンプUpdatedAtである および とは異なります。ProcessedAt タイムスタンプは、Security Hub CSPM が検出結果の処理を開始するタイミングを示します。

ドキュメントから読み取れる内容と疑問点

ドキュメントから以下のことが読み取れます。

• LastObservedAt：セキュリティチェックを実行した時刻
• UpdatedAt：検出結果レコードを更新した時刻
• ProcessedAt：Security Hubが検出結果の処理を開始した時刻

しかし、以下の疑問が残ります。

1. セキュリティチェックは毎日実行されているはずなのに、なぜ LastObservedAt は4日前のままなのか？
2. UpdatedAt と ProcessedAt は毎日更新されているのに、LastObservedAt だけ更新されない理由は？
3. UpdatedAt と ProcessedAt はどういう関係なのか？常にほぼ同時に更新されるのか？
4. 「セキュリティチェックを実行した」とは具体的にどういう状態を指すのか？

これらの疑問を解消するため、さらに調査しました。

コントロールタイプは2種類存在する

Security Hub CSPM のコントロールは、背後で AWS Config ルールを使用して評価を行います。

AWS Config ルールのコンポーネントのドキュメントに、評価のトリガータイプについて以下のように記載されています。

アカウントにルールを追加すると、 はリソースをルールの条件 AWS Config と比較します。この最初の評価の後、 AWS Config は引き続き、評価がトリガーされるたびに評価を実行します。評価のトリガーは、ルールの一部として定義されます。以下のタイプを含めることができます。

また、セキュリティチェックの実行スケジュールのドキュメントに、以下のように記載されています。

最初のチェックの後、各コントロールのスケジュールは、定期的に実行されるか、変更によってトリガーされます。

本記事では、AWS Config の「設定変更」トリガータイプに対応するコントロールをトリガー型コントロール、「定期的」トリガータイプに対応するコントロールを定期型コントロールと呼びます。

つまり、Security Hub CSPM には以下の2つのタイプがあります。

1. トリガー型コントロール：リソースの変更があった際にセキュリティチェックが実行される（例：Lambda.1）
2. 定期型コントロール：定期的にセキュリティチェックが実行される

コントロールタイプの確認方法

各コントロールのタイプは、AWS Lambda の Security Hub コントロールなどのドキュメントで確認できます。

例えば、Lambda.1の場合、トリガー型コントロールです。

[Lambda.1] Lambda 関数ポリシーでは、パブリックアクセスを禁止する必要があります
スケジュールタイプ: 変更がトリガーされた場合

トリガー型コントロールの動作

動作検証

今回問題が発生したLambda.1はトリガー型コントロールでした。

実際に環境で確認したところ、CloudTrail のイベント履歴から、評価が最後にトリガーされた時刻は 2025-10-05T00:00:00Z であり、これは検出結果の LastObservedAt の時刻とほぼ一致していました。

つまり、LastObservedAtは実際にリソース変更によってセキュリティチェックが実行された時刻を示しており、リソース変更がなければ更新されないことが確認できました。

18時間ごとの再確認

それでは、なぜUpdatedAtとProcessedAtは毎日更新されているのでしょうか？

変更によってトリガーされるセキュリティチェックのドキュメントに、以下のように記載されています。

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

トリガー型コントロールでは、リソース変更時にセキュリティチェックが実行されますが、それとは別に18時間ごとの再確認が行われます。

実際の検証から、以下のことが確認できました。

• トリガー型コントロールでも18時間ごとに再確認が行われる
• 再確認時に UpdatedAt と ProcessedAt が更新される
• 再確認では実際にリソース変更がなくても検出結果の更新処理が行われる
• UpdatedAt と ProcessedAt は更新されるが、LastObservedAt（実際のリソース観測時刻）は更新されない
• UpdatedAt が更新された後、Security Hub がその検出結果を受け取って処理を開始するため、ProcessedAt は UpdatedAt とほぼ同時に更新される

重要な点として、この18時間ごとの再確認はトリガー型コントロールにのみ適用されます。
定期型コントロールには適用されず、定期型コントロールは独自の12〜24時間の実行スケジュールに従います。

定期型コントロールの動作

実行頻度

定期的なセキュリティチェックのドキュメントに、以下のように記載されています。

定期的なセキュリティチェックは、最後の実行から 12 時間または 24 時間以内に自動的に実行されます。Security Hub CSPM は周期性を決定し、変更することはできません。

つまり、定期型コントロールは12〜24時間ごとに自動的に実行され、実行周期は Security Hub CSPM が決定します。

タイムスタンプの更新

定期型コントロールでは、定期チェックが実行されるたびにLastObservedAt、UpdatedAt、ProcessedAtのすべてが更新されます。

そのため、トリガー型コントロールのようにLastObservedAtとUpdatedAtの間でズレが発生することはなく、すべてのタイムスタンプがほぼ同じ時刻になります。

まとめ

Security Hub CSPMのコントロールには、トリガー型と定期型の2つのタイプがあり、それぞれでLastObservedAt、UpdatedAt、ProcessedAtの更新タイミングが異なります。

1. トリガー型コントロールの場合（例：Lambda.1）

実行タイミング

• リソース状態の変更時
• 18時間ごとの再確認（AWS Config からの更新漏れを確認）

タイムスタンプの更新条件

リソース変更がない期間の動作

• LastObservedAt：更新されない（最後のリソース変更時のまま）
• UpdatedAt：18時間ごとに更新される
• ProcessedAt：18時間ごとに更新される（UpdatedAtとほぼ同時）

2. 定期型コントロールの場合

実行タイミング

• 最後の実行から12時間以内または24時間以内に自動実行（Security Hub CSPM が周期を決定、変更不可）

タイムスタンプの更新条件

定期チェック実行時の動作

• LastObservedAt：12〜24時間ごとに更新される
• UpdatedAt：12〜24時間ごとに更新される
• ProcessedAt：12〜24時間ごとに更新される

EventBridge 通知で使用するタイムスタンプ

EventBridge 経由の通知メッセージでは、通常以下のような構成になります。

• 初回検知日時：FirstObservedAt
• 最終検知日時：LastObservedAt または UpdatedAt

ここでは、「最終検知日時」として LastObservedAt を表示すべきかどうかを検討します。

なお、ProcessedAt は UpdatedAt とほぼ同時（数秒～数十秒差）に更新されるため、通知メッセージの表示内容としては UpdatedAt と実質的に同じです。

LastObservedAt を使用するケース

トリガー型コントロールで実際の問題発生時刻を把握したい場合

以下の用途に適しています。

• 「いつリソースが変更されて問題が発生したのか」を知りたい
• セキュリティインシデントの調査で、実際の変更タイミングを特定したい

注意点

• 定期型コントロールの場合、LastObservedAt は定期チェック実行時に更新されるため、実際の問題発生時刻とは異なります。定期型コントロールでは、LastObservedAt と UpdatedAt がほぼ同じ時刻になるため、どちらを使用しても差はありません。
• EventBridge 通知時刻とメッセージ内の時刻を一致させたい場合は、UpdatedAt または EventBridge イベント自体に含まれる time フィールド（イベント発生時刻）を使用することもできます。

タイムスタンプを最小限にするケース

シンプルさを優先する場合

複数のタイムスタンプを併記すると、運用担当者が混乱する可能性があります。運用チームのリテラシーや通知の目的に応じて、シンプルに1つのタイムスタンプ（初回検知日時：FirstObservedAt）のみを表示する方が適切な場合もあります。

さいごに

AWS Security Hub CSPM の LastObservedAt、UpdatedAt、ProcessedAt の3つのタイムスタンプは、コントロールのタイプ（トリガー型 or 定期型）によって更新タイミングが異なります。

特にトリガー型コントロールでは、18時間ごとの再確認によって UpdatedAt と ProcessedAt のみが更新されるため、リソース変更がない期間に LastObservedAt との間でズレが発生します。

EventBridge 通知を設計する際は、これらのタイムスタンプの違いを理解した上で、運用目的に応じて適切なタイムスタンプを選択してください。

公式ドキュメントでは、コントロールタイプによる動作の違いが明確に記載されていないため、本記事が皆様の運用設計の参考になれば幸いです。