構成タイムライン履歴の表示

追跡対象のリソースごとに、Configはconfiguration timelineを作成します。これは、そのリソースについて記録されたconfiguration itemを時系列に並べた履歴です。過去の任意の時点でリソースがどのように設定されていたかを正確に確認できるため、インフラストラクチャのタイムマシンのように機能します。

インシデント発生時、タイムラインは重要な問い、つまりwhat changed and whenに答えます。セキュリティグループが突然、どこからでもトラフィックを許可するようになった場合、タイムラインでそのルールが追加された時刻を確認できます。変更の瞬間を特定すると、調査対象の時間帯を絞り込め、他のイベントとの関連付けにも役立ちます。

タイムラインの各エントリには、タイムスタンプとbefore-and-after differencesを伴う設定変更が記録されています。ポート範囲が広げられた、暗号化が無効化されたなど、どの属性が変更されたかを正確に確認できます。この差分表示により、「何かが変わった」という曖昧な状況を、具体的で明確な調査結果に変えられます。

Configは状態がwhatになったかを示します。それを引き起こしたwhoを知るには、Configエントリのタイムスタンプを使ってCloudTrailを調べます。変更時刻とCloudTrailイベントを照合することで、原因となったプリンシパル、送信元IP、API呼び出しを特定できます。このConfigからCloudTrailへのピボットは、調査の基本テクニックです。

タイムラインにはrelationshipsの変更も記録されます。たとえば、ボリュームが別のインスタンスにアタッチされた場合や、サブネットのルートテーブルが変更された場合です。個々のリソース属性が変わっていないように見えても、攻撃者が接続関係を組み替えたことを明らかにするなど、こうした関係の変化がインシデントの本質を示すことがあります。

リソースごとのタイムラインに加えて、Configは記録対象となっているすべてのリソースの完全なconfiguration snapshotsを、スケジュールに従ってS3に配信できます。スナップショットはある時点の完全なインベントリであり、監査中の環境全体の状態を証明したり、日付ごとにポスチャを比較したりするのに役立ちます。

Configは、設定可能な期間（最長で数年間）にわたって設定履歴を保持し、基盤となるデータはS3 bucketにも保存されます。長期的なフォレンジックやコンプライアンスの要件に対応するには、記録そのものと同じくらい、bucketを保護して保持することが重要です。履歴は残ってこそ役に立つためです。

タイムラインは、リソースが意図した安全な状態から気付かないうちに離れていくconfiguration driftを調査するために使います。現在のCIと、以前の問題がないCIを比較すると、何がどのようにずれたかを正確に確認できます。昨日は準拠していたコントロールが今日失敗している場合に、非常に役立ちます。

コンソールでは、Configでリソースを開いてタイムラインを直接表示し、各時点に重ねて表示されたコンプライアンスステータスを確認できます。リソースがどのように変化したかだけでなく、各バージョンがルールに準拠していたかどうかも確認できるため、その時点の履歴上の状態とセキュリティポスチャを結び付けられます。

Configはdeleted resourcesについても履歴を保持し、削除を示す最後のCIを記録します。これは、攻撃者が痕跡を隠すためにリソースを作成してから削除するような調査で重要です。削除イベントとリソースの以前の状態は、どちらも記録に残るため確認できます。

configuration timelineは、フォレンジック調査の基盤です。リソースがいつ、何を変更されたかを示し、CloudTrailと組み合わせることで誰が変更したかも明らかにします。状態変更から、それを実行したAPI呼び出しへピボットする技術を身につけることは、試験で求められる調査そのものです。

Configの履歴を使う力をテストしましょう。

configuration timelineは、リソースのconfiguration itemsを時系列に並べた履歴であり、タイムスタンプ付きのbefore-and-after diffsと関係の変更を示します。whatがwhen変更されたかを特定でき、CloudTrailへピボットするとwhoが明らかになります。Configは削除されたリソースの履歴も保持し、snapshotsをサポートするため、ドリフトやインシデントの調査におけるフォレンジックの基盤となります。