あるソフトウェア企業が、サーバーレスアーキテクチャを採用しており、本番環境の決済処理にAWS Lambdaを使用しています。Amazon GuardDutyが「CredentialAccess:Lambda/AnomalousBehavior」を検出し、特定のLambda関数の実行ロールが通常とは異なるリージョンでAWS APIを呼び出していることが判明しました。この実行ロールには広範なIAM権限が付与されており、攻撃者がコード内の脆弱性を悪用している可能性があります。セキュリティチームが証拠を保全しながら侵害を封じ込めるために最初に実施すべき対応として、最も適切なものはどれですか？
予約済み同時実行数（Reserved Concurrency）を0に設定することで、Lambda関数のそれ以降の実行を防止しながら、関数自体は削除せずにコード・環境変数・設定情報を証拠として保全できます。さらに実行ロールにExplicit Denyポリシーを付与することで、既存および将来の不正なIAM認証情報の使用を無効化します。CloudTrailとCloudWatch LogsをS3に保全することで、フォレンジック調査に必要な証拠チェーン（Chain of Custody）を確立します。これがインシデント対応の封じ込め（Containment）フェーズの正しい手順です。 選択肢Aの「Lambda関数の削除」は、攻撃者の侵入経路特定に必要なコード・環境変数・設定情報を破壊するため、フォレンジック調査の観点から不適切です。 選択肢Cの「脆弱なコードの修正とデプロイ」は根絶（Eradication）フェーズの作業であり、封じ込めが完了する前に実施すると証拠が上書きされるリスクがあります。 選択肢Dの「EventBridgeとSNSによる通知」はインシデント検知として有用ですが、Lambdaトリガーの無効化だけでは既存の不正IAMセッションを停止できず、封じ込めとして不十分です。