SCSインシデント対応
ある企業のセキュリティチームが、悪意あるサードパーティnpmパッケージが混入されたAWS Lambda関数（Node.js）によるサプライチェーン攻撃を検出しました。当該Lambda関数は個人情報データ（PII）を格納するS3バケットへの読み取り権限を持つIAMロールを使用しており、CloudWatch LogsにはAPIコールの記録が残っています。規制上の要件からフォレンジック調査に必要な証拠を保全しながら脅威を即座に封じ込める、最も適切な対応はどれですか？
ALambda関数のリザーブド同時実行数を0に設定して新規実行を停止し、IAMロールにS3アクセスを拒否するDenyポリシーを追加しながら、CloudWatch LogsとX-Rayトレースは証拠として保全する
✓ 正解
リザーブド同時実行数を0に設定して新規実行をスロットリングし、IAMロールへのDenyポリシー追加でS3アクセスを即時遮断する。CloudWatch LogsとX-Rayトレースを削除せず保全するため、フォレンジック証拠要件を満たした封じ込め手順として正しい。
BLambda関数のIAMロールをデタッチして空のロールに差し替え、安全なコードバージョンをZIPで再デプロイして機能を即座に復旧し、侵害されたコードバージョンを削除する
IAMロールのデタッチとコード再デプロイは侵害されたコードバージョンを削除してフォレンジック証拠を破壊するため、規制上の証拠保全要件に違反する。サービス復旧を優先するあまり調査に必要な証拠が失われるリスクがある。
C侵害されたLambda関数のCloudWatch Logsロググループを別アカウントにエクスポートしてから削除し、新しいARNで安全なLambda関数を再作成して環境を刷新する
CloudWatch Logsロググループのエクスポートは有効だが、その後の削除はフォレンジック証拠を破壊するリスクを伴う。新しいARNでの再作成は証拠保全を目的としておらず、根本的な封じ込め手順としても不適切。
DLambda関数が接続するVPCのセキュリティグループのアウトバウンドルールをすべて削除し、S3バケットポリシーでそのVPCエンドポイント経由のアクセスのみを許可する
VPCセキュリティグループのアウトバウンドルール削除はVPCに接続されたLambdaにのみ有効であり、VPC外のLambdaには効果がない。またIAMポリシーを通じたS3アクセスはセキュリティグループレベルでは遮断できないため封じ込めが不完全となる。
解説
Lambda関数のリザーブド同時実行数（Reserved Concurrency）を0に設定すると、以降の新規Invocationリクエストはすべてスロットリングエラーで即時拒否され、関数の実行が封じ込められます。
同時にIAMロールへのDenyポリシー追加により、AWSのポリシー評価においてDenyが最優先されるため、実行中のLambdaからのS3 APIコールも認可エラーとなりデータアクセスが遮断されます。
CloudWatch LogsおよびX-Rayトレースは関数停止後もAWS側に保持されるため、削除せずに保全することでフォレンジック証拠として活用できます。この二段階の封じ込め手順が証拠保全と脅威遮断を同時に実現します。
選択肢BのIAMロールデタッチと再デプロイは、侵害されたコードバージョンを削除してフォレンジック証拠を破壊するため、規制上の証拠保全要件に違反する。
選択肢CのCloudWatch Logsロググループの削除は、APIコール履歴などフォレンジック調査に不可欠な証拠を消失させる行為であり、証拠保全要件に反する。
選択肢DのVPCセキュリティグループのアウトバウンドルール変更は、VPCに接続されていないLambdaには無効であり、IAM権限を通じたS3 APIアクセスをネットワークレベルで直接遮断することができない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSCSを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →