AWS Incident Response Demonstrated 受験レビュー
ひと目で分かる概要
AWS Skill Builder系のMicrocredentialのうち、Incident Response Demonstratedの性格を持つExam Labをコンソールで実施した(実習日2026年7月12日)。選択式ではなく、すでに侵害と設定不備が混在するアカウントが与えられ、調査、証拠保全、攻撃インフラの除去、再発防止をコンソールで行うハンズオンである。一言で印象をまとめると、「セキュリティ理論」よりもログで見つけ、証拠を保全してから除去しハードニングする順序をコンソールで最後までやり遂げられるかを見る。
シナリオの大きな絵は、外部からの侵害がWeb/アプリ層を経てデータ層まで及び、流出・公開アクセスの痕跡を残す形である。ここに監査ログとコンプライアンス設定の不備、過度に開放されたネットワーク・セキュリティグループ、持続アクセス(バックドア)の痕跡が絡み合っている。
形式はコンソールベースの自動採点Exam Labであり、範囲はストレージ、DB、監査ログ、構成記録、コンピュート/オートスケール、ログ分析、ネットワークACL、セキュリティグループ、IAM、Systems Managerである。体感難易度は中〜中上級で、ログの照会と「どのリソースに手をつけるか」の見極めが核心である。合格基準はチャレンジごとに保全・除去・ハードニングの状態を満たしているかであり、セキュリティサービスの名前は知っているがインシデント対応の順序をコンソールで一サイクル回したことがない人におすすめできる。
体感では複数の課題が、前半でデータ/監査、中盤でコンピュート・流出、後半でネットワーク・権限の順につながっていた。一つのチャレンジを適当に済ませると、後の検証で再びつまずくことになる。
この試験は何を見ているのか
試験が繰り返し問う質問はおおよそこうだ。消す前に証拠を残したか、攻撃者側だけを正確に区別して除去したか、再発を防ぐ設定を正しいリソースにかけたかである。一言で言えば「監査ログで侵害の痕跡を見つけ、証拠を残した上で、コンソールで正しいリソースを正しい値で直せるか」である。理論の暗記よりも調査の順序、コンソールの動線、そして自分の作業と攻撃の痕跡を区別する能力が合否を分ける。
実際に受けてみた感想
良かった点
実務のインシデント対応感覚が生きている。設定を一つ直すのではなく、保全、除去、ハードニングが一つのシナリオの中に入っている。検証が状態と成果物ベースなので、コンソールで「できたか」をすぐに確認できる。詰まると、ほとんどの場合ログ分析 → リソースIDの照合 → 正しい階層(バケット/インスタンス/SG/Role)の修正という順序で解決する。
苦労した点
ログ分析用のクエリ環境が平坦なテーブルではないことがあり、スキーマを先に確認しないと最初から詰まる。自分がラボで作業したIP・ロールと攻撃シミュレーションの痕跡が同じログに混在しているため、直近のイベントだけを見ると自分自身をブロックしてしまうことがある。似たようなリソースが複数(複数VPCのACL、ALB/Web/DBのセキュリティグループ、正常なASGインスタンス対不審な名前のインスタンス)あり、どれに手をつけるべきかを間違えると検証が失敗し続ける。一部の削除作業は関連設定(接続/Associationなど)を先に切る必要があるが、削除ボタンだけを押すと権限や依存関係のエラーだけが発生する。
総評
体感難易度は中〜中上級である。サービス自体の深さよりも「どのリソースに、どんな値で、どんな順序で」手をつけるかが核心だ。あらかじめ落とし穴のパターンだけ知っておいても体感難易度は大きく下がる。
課題タイプ別の経験談
以下は問題の全文ではなく、「こういうタイプが出た」というレベルでまとめたレビューである。
データ層の露出とフォレンジック保全タイプ
公開に近い形で開いたDB/ストレージと、流出したデータが攻撃者側のストレージにある構図が与えられる。証拠を安全な側に移した後、攻撃者側を整理し、DB側は公開アクセス・バックアップ・削除保護のような基本的なハードニングを適用する必要がある。難易度自体は低いが、どのバケットがフォレンジック用でどちらが攻撃者側かをSolution Resourcesとオブジェクト一覧で区別する必要がある。消す前にまずコピーする順序が重要だ。
監査ログとコンプライアンス統制タイプ
Trailの整合性、ログバケットの保護、構成記録(Config)がオフになっているか緩い状態が与えられる。ログの検証、暗号化、保存(ライフサイクル)、構成レコーダー、検知用のマネージドルールをオンにする課題だ。「だいたい似たような設定」が落とし穴になりやすい。例えば、ライフサイクルを片方のバージョンタイプにだけ設定したり、Configで新しいバケットを作ろうとしてラボの権限に阻まれたりするケースがある。Solutionにあらかじめ用意されたRoleやBucketを使うパターンが多い。
コンピュート侵害の識別・隔離・ハードニングタイプ
盗まれた認証情報で立ち上がったインスタンス、脆弱なメタデータ設定、ASGやローンチテンプレートが古いバージョンを使っている構図が与えられる。ログで異常な起動を見つけ、フォレンジックイメージとタグを残した後に除去し、メタデータを強制してホップ制限をかけ、ASGが新しいテンプレートを使うよう更新する必要がある。コンソールのイベントヒストリーだけでは不十分で、あらかじめ用意されたログ分析用のワークグループを使うべきタイプだった。Workgroupの設定編集画面とクエリエディタを混同すると時間がかかる。正常なオートスケールインスタンスと不審な名前のインスタンスを混ぜてTerminateしてはならず、検証は現在動いているインスタンスだけでなく証拠となるAMI側も併せて確認する。
データ流出とパブリックアクセス、ネットワーク遮断タイプ
顧客データバケットが開いており、外部に流出した痕跡がログに残る構図が与えられる。証拠を保全した後に攻撃者側のストレージを整理し、バケット/アカウント単位でパブリックアクセスを遮断し、ログで外部IPを特定してVPCネットワークACLにDENYルールをかける。最も迷いやすいタイプの一つで、たった今自分がコンソールで実行した作業のIPを攻撃者だと勘違いして入れてしまいやすい。攻撃シミュレーションのロールや流出関連のイベントの方に範囲を絞る必要がある。NACLルールをInboundだけに入れたり、別のVPCのACLに入れたり、DENYルール番号が広く許可するルールより後にあると検証を通過できない。アカウント単位のBlock Public Accessメニューの位置がコンソールのバージョンによって変わっていることもある。
3層ネットワークセグメンテーション(セキュリティグループ)タイプ
インターネット → ロードバランサー → Web → DBの流れが壊れており、0.0.0.0/0や広いTCP範囲が残っている構図が与えられる。層ごとにSourceをIPではなく前の層のセキュリティグループに絞り、SSHのような管理ポートはインバウンドから除去してSession Managerの方へ誘導する必要がある。今編集中のSGがALBなのかWebなのかDBなのかを見失うとすぐに失敗する。Webにインターネットの80/443ポートをそのまま残したり、WebのInbound SourceにDB SGを入れたりする混同がよくある。ロードバランサーのSecurityタブでALB用SGを先に確認する習慣が必要だ。
バックドアIAM/SSMとインスタンスロールの最小権限タイプ
不要なIAMユーザー、悪意あるSystems Managerドキュメント、過剰な権限が付いたEC2インスタンスロールが与えられる。ログで生成されたユーザーとドキュメントを見つけて除去した後、ロールにはSolutionに用意された最小権限ポリシーだけを残す必要がある。Userの削除は比較的簡単だ。DocumentはインスタンスのAssociationが残っていると削除がブロックされ、Automation実行ボタンからアクセスするとラボのIAMにない権限が出てきて迷うことになる。ポリシーのDetachはEC2画面ではなくIAM Roleで行い、最小権限ポリシーを先にAttachした後に広いポリシーを外す方が安全である。
時間がかかった区間
体感で最も時間がかかった区間はログスキーマの把握と攻撃者/本人の区別だった。NACL設定(正しいVPC、双方向、ルール順序)も非常に迷いやすい区間だった。SGの3層ごとのSource設定も手ごわく、SSMの接続解除後にDocumentを削除する作業も時間がかかった。Trailのライフサイクルと Configの既存リソース活用は中程度の難易度で、DBのハードニングとS3の証拠コピー、IAM Userの削除は相対的に楽だった。
戦略は明確だ。前半でログの照会と本人/攻撃者のフィルタリングを習慣化し、ネットワークとSGの区間にバッファを残しておくことである。
受験前に準備しておくと良いこと
この試験の基本対応ループは、監査ログを分析し(コンソールのEvent Historyだけでは不十分な場合がある)、証拠を保全(コピーまたはイメージ+タグ)した後、攻撃インフラだけを除去し、公開遮断・メタデータ・ACL/SG・最小権限・監査と構成の設定でハードニングを適用した上で、自動検証を再試行する順序で成り立つ。
コンソールで一サイクルを手で回してみることが大いに役立つ。AthenaやLogs Insightsのようなツールで CloudTrail系のイベントを照会すること、S3のコピーとバケットの空にする・削除、Block Public Access(バケット・アカウント単位)の設定、RDSのようなDBの公開アクセス・バックアップ・削除保護の設定、Trailの検証・暗号化・ライフサイクル設定とConfigレコーダー・ルールの設定、EC2のイメージ+タグ作業とLaunch Templateのメタデータ設定、ASGの更新、NACL DENYルール(どのVPCか、In/Out、ルール番号)、SGのSourceをセキュリティグループに絞る作業、IAM Userの削除とSSM Associationの削除、Roleポリシーの入れ替え作業を一度ずつやっておくとよい。
アカウントごとに名前とIDは異なるが、繰り返されるのは概念の種類だ。ログ分析では専用のWorkgroup/DBとネストされたJSON/配列スキーマがよく登場し、フォレンジックでは指定されたバケットへコピーし、AMIに事故タイプと元のインスタンスのタグを残すパターンが繰り返される。DBは非公開状態、バックアップの維持、削除保護が核心であり、Trail/Configは整合性検証、暗号化、保存、レコーダー、検知ルールが核心である。メタデータはトークン必須(IMDSv2)とhop limitが核心であり、SGはロードバランサーからインターネットへ、Webからロードバランサーへ、DBからWebへとつながる参照関係が核心である。NACLは単一IP(/32)へのDENYとALLOWより先のルール番号が核心であり、IAM/SSMはバックドアUserの除去、Associationを先に切ること、最小権限ポリシーが核心である。
自分の活動と攻撃者の活動を混同しないことも重要だ。直近の公開IPやAPI呼び出しの大部分はラボの利用者本人の活動であることが多いため、攻撃シミュレーションのロールや流出関連のAPI、不審なリソース名の方に範囲を絞る必要がある。
コンソールUIが複数の言語で表示されても、メニュー名よりInbound、State Manager/Associations、Account settings、Launch template Advancedのようなタブの位置を覚えておく方が効率的である。
よくあるミスまとめ
経験上よく出るミスは次の通りである。ログテーブルやスキーマを勝手に仮定してクエリを実行しすぐにエラーが出るケース、Event Historyだけを見て「ログがない」と断定するケース、ライフサイクル・暗号化・検証のうち一つの軸だけを合わせて提出するケース、Configやストレージでラボが阻止している生成作業を試みるケース、証拠(イメージ・タグ・コピー)なしに攻撃リソースから先に削除するケース、NACLに本人のIPを入れたり別のVPCのACLにDENYをかけたりするケース、NACLのOutboundを見落としたりDENYルールがALLOWルールより後の番号にあるケース、WebのSGのSourceに前の層(LB)ではない別のSGを指定するケース、広いTCPや0.0.0.0/0ルールが残っているのを見逃して提出するケース、SSM Documentだけを消そうとして接続のために失敗しAutomationでアクセスして権限エラーに遭うケースである。
こんな人におすすめ・非おすすめ
S3、RDS、SG、IAMをそれぞれは知っているがインシデント対応の順序では扱ったことがない人、CloudTrailとAthenaで「誰が何をしたか」を追跡する習慣を作りたい人、NACL・SG・IMDSv2・Configを短く手に馴染ませたい人におすすめする。逆にログSQLやCloudTrailイベントの構造がまだ馴染みのない人、VPC/SG/NACLをコンソールで区別したことがない人、「削除さえすればいい」と考え保全と正しい対象の選定を飛ばしてしまう人であれば、事前準備をもっとする方がよい。
合格後に残るもの
合格するとCompletion CertificateとCredlyバッジなどが発行され、マイクロクレデンシャル系は通常1年間有効である。詳細な更新周期はSkill Builderの案内に従えばよい。
資格の一行よりも実質的に残るのは、インシデント対応において、まず証拠を残し、攻撃者側だけを正確に消し、正しいリソースに最小権限とネットワーク境界を再び設定する感覚である。そのパターンをすでに使っているなら、この試験は短く検証してくれる装置であり、まだであれば準備過程自体が最も価値ある学びになる。
終わりに
AWS Incident Response Demonstratedは難しいセキュリティ理論試験というより実務型インシデント対応トラブルシューティング試験に近い。リソースはすでに壊れており、説明に状態がヒントとして書かれており、受験者はコンソールでそれを直す。
合格の核心は才能ではなく順序である。ログで侵害の痕跡を見つけ、証拠として残し、攻撃側だけを除去した後、公開遮断・メタデータ・ACL/SG・最小権限・監査設定で再び締める。
次に受験する方に一つだけ残すとすればこれである。ログではスキーマと「本人 vs 攻撃者」フィルターをまず見よ。ネットワークとセキュリティグループは、どのVPC、どの層のSGなのかを確認してから手をつけよ。バッジよりも「なぜ検証が通らないのか」「なぜ削除がブロックされるのか」「なぜ間違ったIPをブロックしたのか」を自分で答えられるようになる方が長く残る。その感覚を持って臨めば、このExam Labは十分に合格できる。