Amazon SCS-C02: インシデント対応とフォレンジック — 学習ガイド

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Security Specialty SCS-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

侵害されたEC2インスタンスの隔離

EC2インスタンスの侵害が疑われる場合の最初の運用目標は、証拠を破壊しない封じ込めです。AWSにおける封じ込めは、インスタンスのネットワーク露出、ライフサイクルとの関連付け、そして対応担当者からのアクセス性に関わる階層的なアクティビティです。

標準的な隔離手順は、インスタンスのセキュリティグループを厳格化することから始まります。理想的には各インスタンスが専用のセキュリティグループを持つため、イングレスおよびエグレスルールを、フォレンジックチーム（または専用の診断用セキュリティグループ）のみがアクセスできる最小限のセットに置き換えることができます。インスタンスがApplication Load Balancerの背後やターゲットグループ内にある場合は、まず登録を解除します。Auto Scalingグループのメンバーである場合は、--should-decrement-desired-capacityフラグを付けてデタッチします。これにより、ASGが即座に代替インスタンスを起動したり、さらに悪いことに、調査の途中で「異常な」インスタンスを終了させたりするのを防ぎます。

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

終了保護の有効化は不可欠です。なぜなら、善意のオペレーター、自動化スクリプト、またはASGのスケールインイベントによって、まさに保全しようとしているボリュームが破壊されてしまう可能性があるからです。終了保護はASGからのデタッチの代替にはなりません。インスタンスをグループのスコープから除外しない限り、ASGはスケールイン中に保護されたインスタンスを終了させることができます。

即時の出力通信遮断が必要な場合（例えば、インスタンスが既知の悪意のあるIPにビーコン通信している場合）のサブネットレベルの封じ込めとして、サブネットのネットワークACLに、明示的なすべて拒否のアウトバウンドルールを最も若い番号のルールとして追加できます。これはステートレスであり、すべてのフローに即座に効果を発揮します。これは、新しいフローにのみ影響するセキュリティグループの変更とは異なります。診断用SGを介したフォレンジックアクセス経路が確保されたら、NACLの拒否ルールを削除して、レスポンダーのサブネットがSGの許可リストを通じてターゲットに到達できるようにします。

揮発性および不揮発性の証拠の保全

揮発性の証拠（プロセスリスト、開いているネットワークソケット、ロードされたカーネルモジュール、メモリコンテンツ、tmpfsのコンテンツなど）は、インスタンスが停止した瞬間に破壊されます。不揮発性の証拠はEBS上に存在し、停止/起動後も残りますが、ボリュームがデタッチされたり、スナップショットなしでインスタンスが終了されたりすると失われる可能性があります。手順のルール：まずインスタンスが実行中の間に揮発性アーティファクトを収集し、その後EBSをスナップショットします。

揮発性データの収集は、人間がインタラクティブシェルで入力するのではなく、スクリプト化し、SSM Run Command経由で実行されるべきです。Run Commandは、呼び出し、パラメータ、実行プリンシパル、および出力をCloudWatch LogsやS3に記録し、それ自体が管理の連鎖の記録の一部となります。

実践的な問題：ユースケースシナリオ

シナリオ： Meridian Financialは、顧客向けのウェブアプリケーションを単一のAWSアカウント内の複数のVPCで実行しています。これには、Application Load Balancerの背後にあるAuto Scalingグループ、EBSベースのEC2インスタンス、一元化されたCloudTrailとCloudWatchのロギング、GuardDuty、そしてKMSで暗号化されたS3ベースのログアーカイブを使用しています。セキュリティオペレーションチームは、リモート管理にAWS Systems Managerを使用し、バックアップとスナップショットは指定されたリカバリアカウントに保存しています。

課題： 1つの本番EC2インスタンスに、不審なアウトバウンドトラフィックと予期しないプロセスアクティビティという侵害の兆候が見られます。チームは、監査証跡を破壊することなく、インスタンスを隔離し、フォレンジック分析のために揮発性のメモリと不揮発性のディスクの両方の証拠を保全しなければなりません。

推奨アプローチ：

Auto ScalingおよびELBのAPIを使用して、インスタンスをターゲットグループからデタッチし、Auto Scalingプロセスを中断します。その後、制限的なセキュリティグループ（すべてのインバウンド/アウトバウンドを拒否）を適用し、インスタンスのネットワークACLルールを更新してネットワークアクセスを隔離します。その際、AWS Systems Manager Session Manager経由の管理は維持します。
AWS Systems Manager Run Commandを使用して、ゲスト内メモリキャプチャ（例：LiME）を実行し、RAMダンプをアタッチされた暗号化EBSボリューム、またはSSE-KMSで暗号化され保持のためにS3オブジェクトロックが有効化されたS3バケットに直接書き込みます。
EC2 CreateSnapshot（またはCreateImage）を使用して、アタッチされているすべてのボリュームのポイントインタイムEBSスナップショットを取得し、それらのスナップショットを別のAWSアカウントまたは別のリージョンにコピーして、管理の連鎖を維持し、改ざんを防ぎます。
インスタンスのENIに対してVPC Traffic Mirroringを有効化または取得し、専用のモニタリングEC2にパケットキャプチャを収集します。同時に、VPCフローログ、ELBアクセスログ、CloudTrail、CloudWatch Logs、およびGuardDutyの検出結果をセキュアなS3アーカイブへエクスポートします。
収集したすべてのアーティファクトにAWS Security Hubまたはチケットシステムでタグを付けてインベントリ化し、S3オブジェクトが暗号化されオブジェクトロックが設定されていることを確認し、IAMアクセスを少人数のフォレンジックチームに制限します。その間、CloudTrailを通じてすべてのアクセスを記録します。

論理的根拠： イメージを取得する前にネットワークアクセスを隔離することで、さらなる汚染を防ぎます。また、SSMを使用することで新たなネットワーク経路を開くことを回避します。最初に揮発性メモリをキャプチャし、不変のEBSスナップショットとセキュアなS3アーカイブを作成することで、AWSのインシデント対応のベストプラクティスに沿って、証拠の完全性と管理の連鎖を維持します。

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

揮発性データのキャプチャ直後に、アタッチされているすべてのEBSボリュームのスナップショットを作成します。インシデント識別子でスナップショットにタグを付け、それらがケースに明確に関連付けられるようにします。

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

インスタンス自体にも同じインシデントチケット、調査担当者の名前、そしてQuarantine（隔離）などのステータスラベルでタグを付けます。一貫したメタデータタギングは、管理の連鎖のためのAWSネイティブなメカニズムです。これはクエリ可能であり、IAMの条件キーを介して不変にでき、リソースに関するすべてのCloudTrailイベントに表示されます。

Session ManagerとRun Commandによるライブレスポンス

見過ごしがちですが試験で非常に重要なポイントです。**既存のSSHセッションは、セキュリティグループのルールを削除しても維持されます。**セキュリティグループはステートフルであり、接続確立時にルールを評価します。そのため、一度確立されたTCPセッションは、それを許可したイングレスルールが削除された後でも通信が継続します。もし対応者が、自身のSSHセッションをアクセス手段として頼りながら、SGルールを削除してインスタンスを隔離した場合、そのセッションは機能し続けます。しかし、セッションが切断された時点で、対応者はロックアウトされ、踏み台やキーベースでの再アクセスは不可能になります。

正しいパターンは、フォレンジックチームにSSM Session Manager経由でのアクセスを許可することです。これには、インバウンドポートを開ける必要がありません。Session Managerは、SSM AgentからSSM、EC2 Messages、およびSSM Messagesエンドポイントへのアウトバウンド接続を介して機能します（理想的には、隔離されたインスタンスがインターネットルートを必要としないように、VPCインターフェイスエンドポイントを経由させます）。ssm:UpdateInstanceInformationとmessages APIを許可するインスタンスプロファイルをアタッチし、対応者には隔離されたインスタンスにタグでスコープを限定したssm:StartSessionを許可します。

Session ManagerのセッションはSSMコントロールプレーンによって仲介されるため、セキュリティグループのイングレスを厳格化したり完全に空にしたりしても影響を受けません。また、すべてのキーストロークをS3やCloudWatch Logsに記録でき、ブラックボックスではなく監査可能なインタラクティブセッションとなります。

暗号化されたスナップショットのクロスアカウントリカバリ

成熟した環境では、フォレンジック用のスナップショットを、侵害されたワークロードアカウントから隔離された専用のフォレンジックアカウントに転送します。アカウント間でスナップショットを共有するには、2つのことが必要です。まず、スナップショットをターゲットアカウントと共有し（modify-snapshot-attribute --create-volume-permission）、次に、スナップショットがカスタマーマネージドKMSキーで暗号化されている場合は、KMSキーポリシーでフォレンジックアカウントのプリンシパルにkms:Decrypt、kms:CreateGrant、kms:DescribeKeyを許可する必要があります。AWSマネージドのaws/ebsキーで暗号化されたスナップショットは、クロスアカウントで共有できません。まずコピー操作によってCMKで再暗号化する必要があります。フォレンジックアカウント側で、共有されたスナップショットをコピーし、フォレンジックアカウント内のCMKで再暗号化します。これにより、その後のボリューム作成がソースアカウントに依存しなくなります。

プレイブックの設計とオーバーヘッドの最小化

封じ込め手順を、EventBridge経由でGuardDutyやSecurity Hubの検出結果によってトリガーされるSSM AutomationドキュメントまたはStep Functionsワークフローとしてコード化します。単一のオートメーションで次のことを実行すべきです。(1) Run Commandで揮発性データを取得、(2) インシデントタグを付けてボリュームをスナップショット、(3) 終了保護を有効化、(4) ASGからデタッチし、ELBターゲットから登録解除、(5) SGを隔離用SGに置き換え、(6) インスタンスにチケットIDをタグ付けする。インスタンスを実行し続けることで、ライブな証拠が保全され、Session Managerによるインタラクティブな調査が可能になります。電源オフは、自動封じ込めの一部ではなく、意図的な後のステップとすべきです。なぜなら、シャットダウンは揮発性の証拠を消去し、マルウェアに埋め込まれたクリーンアップロジックをトリガーする可能性があるからです。

心に留めておくべき落とし穴は次の通りです。既存のSSHセッションを信頼したままSGルールを削除すると、対応者は状況を把握できなくなり、隔離が完了したと誤信してしまいます。スナップショットを取得する前にインプレースでの修復を行うと、侵入がどのように発生したかを解明するためのアーティファクトが破壊されます。そして、インスタンスをASGやターゲットグループに残したままにすると、自動的な終了や、さらに悪いことに、インシデントの範囲を隠蔽するサイレントな置き換えを招く可能性があります。

即時封じ込め

ワークロードが侵害された疑いがある場合、最初の判断は、その場で隔離するか、サービスから切り離すかです。サービスから切り離すこと、つまり停止や終了は、RAMの内容、実行中のプロセス、開いているソケット、メモリ上にのみ存在するマルウェアなどの揮発性の証拠を破壊します。その場での封じ込めが、ほとんどの場合、正しい初動です。そして、制御が有効になる前に攻撃者が追加のデータを外部に送信したり、横展開（ラテラルムーブメント）したりできないよう、十分に迅速に行う必要があります。

2つのAWSネイティブのコントロールは異なるレイヤーで動作し、その違いは重要です。セキュリティグループはステートフルで、Elastic Network Interface (ENI) にアタッチされます。一方、ネットワークACL (NACL) はステートレスで、サブネットにアタッチされます。インスタンスのセキュリティグループを、ロックダウンされた「隔離用」SGに置き換えるのは、外科的なアプローチです。これにより、同じサブネット内の他のワークロードに影響を与えることなく1つのENIを隔離し、インスタンスの実行状態を維持できます。しかし、セキュリティグループの変更は、ENIに到達する新しいフローにしか影響しません。侵害されたインスタンスがすでに長期間続くアウトバウンド接続を保持している場合、既存の状態が持続する可能性があります。NACLの拒否ルールはサブネット境界で即座に有効になり、外科的な精度よりも速度が重要な場合に、トラフィックをさらに迅速に遮断できます。例えば、同じサブネット内の複数のインスタンスが関与している場合や、攻撃者のアクティブなセッションを即座に切断する必要がある場合などです。また、ポリシーによってインスタンスを直接変更することができない場合にも、NACLは役立ちます。

標準的な隔離用SGは、インバウンドトラフィックを一切許可せず、アウトバウンドトラフィックはcom.amazonaws.<region>.ssm、com.amazonaws.<region>.ssmmessages、com.amazonaws.<region>.ec2messagesのVPCインターフェイスエンドポイントへの通信のみを許可します。これにより、C2チャネル、データ漏洩、横展開をブロックしつつ、Systems Manager Session Managerへのアクセスを維持できます。

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

証拠保全の順序

フォレンジックの価値は揮発性の高いものから低いものへと低下していくため、操作の順序は固定されており、交渉の余地はありません。

最初に終了保護を有効にする。 DisableApiTermination=true を設定することで、Auto Scalingイベント、オペレーターのミス、またはスケジュールされたアクションによって、調査中にインスタンスが破棄されるのを防ぎます。また、ASGのヘルスチェックによってインスタンスが置き換えられないように、インスタンスをAuto Scalingグループからデタッチします。
Auto Scalingからデタッチまたは保護する。 EnterStandby を使用するか、インスタンスをデタッチして、ASGがインスタンスを異常と判断して終了させないようにします。
アタッチされているすべてのEBSボリュームのスナップショットを作成する。 CreateSnapshot（または複数ボリュームのアトミックなキャプチャのための CreateSnapshots）は、不変で暗号化されたフォレンジックアーティファクトを生成します。スナップショットには、インシデントID、ソースインスタンスID、タイムスタンプ、および分析担当者をタグ付けします。アカウントが侵害された場合でもスナップショットが残るように、セキュリティチームが所有する専用のフォレンジックアカウントにスナップショットをコピーします。
メモリをキャプチャする。 SSM RunCommand ドキュメントを使用してメモリ取得ツール（LinuxではLiME、AVML、WindowsではWinPMEM）を呼び出し、コンプライアンスモードのObject Lockが設定されたS3フォレンジックバケットにイメージをストリーミングします。メモリは インスタンスがまだ実行中 の間にキャプチャする必要があります。停止したインスタンスには取得するRAMがありません。
メタデータを収集する。 インスタンスID、AMI、IAMインスタンスプロファイル、VPC/サブネット、ENI ID、タグ、実行中のプロセスリスト、netstat の出力、およびIMDSのコンテンツを記録します。インスタンスに Status=Quarantined および IncidentId=<id> というタグを付け、下流の自動化や人間のオペレーターがその状態を認識できるようにします。
その後でのみインスタンスを停止する。オフラインでのディスク分析が調査で必要な場合にのみ、インスタンスを停止します。停止するとメモリが消去されるため、これは常に最後のステップです。

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

自動化されたIRワークフロー

GuardDutyの検出結果は、数時間ではなく数秒以内に封じ込めをトリガーすべきです。標準的なパイプラインは EventBridge → Lambda → SSM Automation であり、通知にはSNSを使用します。

EventBridgeルールは、source: aws.guardduty、詳細タイプ GuardDuty Finding に一致させ、UnauthorizedAccess:EC2/*、Backdoor:EC2/*、Trojan:EC2/*、CryptoCurrency:EC2/* などのEC2関連の検出タイプにフィルタリングするパターンを使用します。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

ターゲットのLambdaは detail.resource.instanceDetails.instanceId からインスタンスIDを抽出し、SSM Automationドキュメントを呼び出すか（または直接SDKを呼び出して）、終了保護を有効にし、ModifyNetworkInterfaceAttribute を介してENIのセキュリティグループを隔離用SGに置き換え、アタッチされているすべてのボリュームのスナップショットを作成し、インスタンスにタグを付け、SOCチャネルにSNSメッセージを公開します。生のSDK呼び出しではなくSSM Automationを使用することで、Automationの実行履歴にステップバイステップの監査証跡が残ります。

データ漏洩とC2分析のためのロギング

テレメトリのない封じ込めは当て推量にすぎません。VPC Flow Logsは、VPCまたはサブネットレベルで有効にし、トラフィックタイプを ALL（ACCEPTとREJECTの両方）に設定する必要があります。REJECTレコードは、スキャン、ブロックされたデータ漏洩の試み、および既知の不正なIPに到達しようとするC2ビーコンを明らかにします。ACCEPTレコードは、どのフローが成功したかを示します。フローログは、リアルタイムクエリのためにCloudWatch Logsに、Object Lockを使用した長期保存のためにS3にルーティングします。フォレンジックS3バケットとKMSに対するデータイベントを含むCloudTrailは、証拠取り扱いのための監査チェーンを提供します。これをDNSクエリロギング（Route 53 Resolver）と組み合わせることで、フローログだけでは見逃してしまうDGAやDNSトンネリングを捕捉します。

Session Managerによる制御されたフォレンジックアクセス

Session Managerは、SSHキー、踏み台ホスト、またはポート22/3389を開く必要性をなくします。これこそが、隔離用SGがすべての従来のアクセスをブロックできる理由です。SSE-KMSを使用したS3バケットとCloudWatch Logsへのセッションロギングを有効にします。セッション設定で EnforceEncryption=true を強制し、TLSとログ暗号化なしでセッションが実行されないようにします。ssm:StartSession に対するIAMポリシーは、tag:Status=Quarantined を持つインスタンスにスコープを限定し、インシデント対応ロールにのみ付与されるべきです。

よくある落とし穴とその失敗理由

最初に停止または終了させてしまう。 停止するとメモリが解放され、アクティブな接続が切断され、揮発性のアーティファクトをキャプチャする能力が失われます。終了させると、DeleteOnTermination=falseでない限りルートボリュームも解放され、その場合でもランタイムの状態は失われます。電源状態を変更する前には、必ずその場で封じ込めてください。
NACLの方が高速な場合にセキュリティグループのみに依存する。 SGの変更はピンポイントな対応ですが、アタッチされているENIにしか影響せず、新しいフローのみを制御します。サブネット内の複数のインスタンスが関与している場合や、攻撃者の既存のアウトバウンドセッションを即座に切断する必要がある場合、サブネットレベルのNACL拒否ルールの方が迅速に遮断できます。なぜなら、NACLはステートレスであり、以前の状態に関係なくすべてのパケットをブロックするからです。
スナップショット取得前に修復する。 EBSスナップショットを作成する前にインスタンスの再イメージ化、パッチ適用、または置換を行うと、マルウェアのバイナリ、永続化の仕組み、ログ、タイムスタンプといったディスク上の証拠が破壊されます。スナップショットは安価で不変です。あらゆる修復アクションの前に取得し、侵害された本番アカウントから削除されないように、専用のフォレンジック用アカウントにコピーしてください。

実践的な問題：ユースケースシナリオ

シナリオ： Meridian Financialは、本番ワークロードを専用アカウントで運用するマルチアカウントAWS環境を運営しています。この環境には、顧客データをホストするEC2およびEKSサービス、アーカイブ用のS3バケット、CloudTrail、GuardDuty、Security Hub、Configが有効化されたセキュリティアカウントでの集中ログ記録、デプロイ用のCI/CDパイプラインが含まれます。運用チームは、パッチ適用とメンテナンスにSystems Managerを、パブリックエンドポイントにRoute 53/ALBを使用しています。

課題： GuardDutyの検出結果と予期せぬアウトバウンドトラフィックの急増から、EC2インスタンスが侵害され、データ窃取と不審なIAM APIコールを行っている可能性が示唆されました。フォレンジック証拠を保全し、監査可能な調査担当者アクセスを維持しつつ、即時の封じ込めが求められます。

推奨アプローチ：

GuardDutyの検出結果をトリガーとしてEventBridge経由で即時封じ込めを開始します。これによりStep Functionsワークフローが呼び出され、Lambda/SSM Automationを使用して、隔離用セキュリティグループのアタッチ、パブリックIPの削除またはENIのデタッチ、およびIAM経由で関連するIAM認証情報の失効/ローテーションを行います。
SSM Automationドキュメントを実行して、揮発性および永続性の証拠を保全します。インスタンスのEBSスナップショットとAMIを作成し、スナップショットを専用のフォレンジック用AWSアカウントにコピーし、エクスポートされたアーティファクトをS3オブジェクトロック（コンプライアンスモード）とKMS暗号化が設定されたS3バケットに保存します。
データ窃取とC2分析のためのログをキャプチャします。CloudTrailの管理イベントとデータイベント（S3、Lambda）が有効になっていることを確認し、VPC Flow Logs、ALB/NGINXアクセスログ、Route 53クエリログを中央のセキュリティアカウントに転送し、タイムラインの相関分析のために検出結果をAmazon Detectiveで調査します。
EventBridge -> Step Functions -> Lambdaを使用してオーケストレーションと通知を自動化します。これにより、封じ込め、証拠のコピー、インシデントオーナーへのSNS通知、および既存のITSMシステムでのチケット作成を連携させます。
制御されたフォレンジックアクセスを提供します。ライブ調査セッションにはAWS Systems Manager Session Managerの使用を必須とし、セッションログをCloudWatch Logsとフォレンジック用S3バケットに記録します。アクセスは、MFAと一時的な認証情報を持つ、指定されたフォレンジック用IAMロールにのみ許可します。

論理的根拠： このアプローチは、脅威を迅速に隔離し、分析のために不変のアーティファクトと集中管理されたログを保全し、再現可能な対応ステップを自動化して封じ込めまでの時間を短縮し、AWSのベストプラクティスに従ってSession Manager経由で監査可能かつ最小権限のフォレンジックアクセスを強制します。

← コンテナとサーバーレスセキュリティ · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

試験に合格する →

Amazonを閲覧 →

Amazon SCS-C02: インシデント対応とフォレンジック — 学習ガイド

侵害されたEC2インスタンスの隔離

揮発性および不揮発性の証拠の保全

実践的な問題：ユースケースシナリオ

Session ManagerとRun Commandによるライブレスポンス

暗号化されたスナップショットのクロスアカウントリカバリ

プレイブックの設計とオーバーヘッドの最小化

即時封じ込め

証拠保全の順序

自動化されたIRワークフロー

データ漏洩とC2分析のためのロギング

Session Managerによる制御されたフォレンジックアクセス

よくある落とし穴とその失敗理由

実践的な問題：ユースケースシナリオ

Pass the whole exam — not just this question

Related guides

1つのサブスクリプション。すべての試験。