[レポート] AWSセキュリティインシデント対応ワークショップ「The AWS Security Incident Response Challenge: Defend the Cake!」に参加しました！#AWSreInvent #SEC320

こんにちは！クラウド事業本部のおつまみです。

今回はre:Invent2025のセッション 「The AWS Security Incident Response Challenge: Defend the Cake! 」 に参加してきたので、内容をご紹介します！

セッションの概要

タイトル

The AWS Security Incident Response Challenge: Defend the Cake!

概要

Our precious Magic Unicorn Cake recipe is under threat from the notorious Grumpy Cats, and you're the AWS Security Engineer who must stop them. This high-stakes workshop mirrors the real security incidents you face daily—unauthorized access attempts, suspicious API activity, and data exfiltration threats—wrapped in a fun, immersive scenario. As you defend our digital delicacies from crafty cyber-cats, you'll implement the security controls that matter most: real-time threat detection, defensive configurations, comprehensive monitoring, and incident response procedures. Every technique you practice translates directly to real-world scenarios observed by the AWS Customer Incident Response Team. Join us to master rapid security response while saving our recipes from those crafty cats. This is hands-on and technical, so bring your laptop and prepare to defend against the Grumpy Cat invasion.

私たちの大切な魔法のユニコーンケーキのレシピが、悪名高いグランピーキャッツの脅威にさらされています。あなたはAWSセキュリティエンジニアとして、彼らを阻止しなければなりません。このハイリスクなワークショップでは、不正アクセスの試み、疑わしいAPIアクティビティ、データ窃盗の脅威など、日々直面する実際のセキュリティインシデントを、楽しく没入感のあるシナリオで再現します。私たちの大切なデジタルのお菓子を狡猾なサイバーキャッツから守るために、リアルタイムの脅威検出、防御設定、包括的なモニタリング、インシデント対応手順など、最も重要なセキュリティコントロールを実装します。実践するすべてのテクニックは、AWSカスタマーインシデント対応チームが観察した実際のシナリオに直接応用できます。このワークショップに参加して、迅速なセキュリティ対応を習得し、狡猾な猫たちから私たちのレシピを守りましょう。実践的で技術的な内容なので、ノートパソコンをご持参ください。グランピーキャッツの侵略から身を守る準備をしましょう。

スピーカー

• Ben Fletcher, AWS CIRT EMEA Operations Lead, AWS
• Geroen Joris, Security Specialist SA, Amazon Web Services

レベル

300

Session Type

Workshop

セッションの内容

ワークショップの形式

このセッションは、「Magic Unicorn Cake」のサイトを守る実践的なセキュリティインシデント対応ワークショップでした。

可愛いサイトですね。

前半はチームに分かれて、実際のAWSインシデント対応チーム（CIRT）が扱う典型的なセキュリティ脅威に対処します。
後半は講義形式でインシデント対応の重要性について学ぶものでした。

前半：ワークショップ

CISO議事録をもとに、ありとあらゆる箇所にあるセキュリティ脆弱性を修正するといったものでした。
議事録には以下の脆弱性内容があり、メンバーでS3、IAM、EC2と手分けして環境の是正を行なっていきます。

1. IAM/認証の脆弱性
2. S3バケットの脆弱性
3. 監視・アラートの脆弱性
4. EC2の脆弱性
5. Webアプリケーションの脆弱性

私は2の「S3バケットの脆弱性」を担当し、具体的には以下のようなことを実施しました。

• S3オブジェクトレベルのログ記録の設定（CloudTrail）
• オブジェクト整合性チェックの有効化（改ざん検知）
• S3 オブジェクトロックの変更
• S3 バケットポリシーの変更（多層防御）

「既存バケットのS3オブジェクトロック変更ってできるんだっけ？」と思ったのですが、2年前にできるようになっていました。
こういうのを思い出させてくれるのが良いところですね。

https://dev.classmethod.jp/articles/amazon-s3-enabling-object-lock-buckets/

40分ほど時間が過ぎると、IAMアクセスキーの認証情報が漏洩したり、S3バケットが公開されたりといった仕掛けがありマイナスになりましたが、

なんとか全体の上位には食い込むことができました。

後半：インシデント対応の重要性

スピーカーが強調していたのは、インシデント対応におけるチームワークの重要性です。

• 各メンバーが自分の強みを特定し、協力してペアを組む
• エゴを脇に置き、やるべき仕事に集中する
• 専門外のサービスについてはGoogle検索や同僚に聞くことも必要（AWSには250以上のサービスがある）
• ジュニアメンバーをインシデントコマンダーに配置する事例も紹介されました - データに基づいた決定を下すためで、これはNASAから取り入れられた手法とのことです

IAM認証情報の侵害（統計の66%）

AWSインシデント対応チームが扱うハッキングの66%が有効なIAM認証情報によるものということが伝えられました。
主に2つの経路があります。

1. コンソールログイン経由

• MFAは非常に効果的 - 9000件のケースで、MFA突破はわずか1件のみ（大規模インシデントでのMFA突破はIdentity Providerのソーシャルエンジニアリングによるもの）

2. アクセスキー経由

• アクセスキーは脅威アクターにとって「絶対的な金」
• MFAがほとんど付いておらず、過度に許可されている
• 本番環境からアクセスキーを取り除くべき
• ロールを使用したローテーション方式を推奨

ワークショップで発見された攻撃経路

1. GitHubへの認証情報コミット

• 開発者がアクセスキーを誤ってGitHubにコミット
• 数秒以内に脅威アクターが使用
• あるケースでは、インターンがプライベートGitHubリポジトリ（80個のアクセスキーを含む）を公開してしまった事例もある

2. EC2のSSRF脆弱性（IMDSv1）

• ユニコーンケースの画像アップロード機能に脆弱性
• **Server-Side Request Forgery（SSRF）**によりメタデータサービスバージョン1にアクセス
• EC2ロールの認証情報を盗むことができ、データプレーンからコントロールプレーンに移動可能
• IMDSv2にデフォルト設定すべき

3. Lambda関数のコードインジェクション

• マーケティングチームが設定した新しいキャンペーンに脆弱性
• ファイル名がPythonのsubprocessコールで処理されていた
• 任意のPythonスクリプトを注入可能で、過剰に特権を与えられたLambdaロールを悪用

ルートアカウント侵害の深刻さ

またインシデントの3分の1がルートアカウント侵害です。

• アカウント全体を閉鎖可能
• 組織がある場合、メンバーアカウントでルートを許可しない

データ保護とバックアップ

S3バケットの復旧について

• AWSはS3バケットを復旧できない
• コンプライアンス要件で削除が必要な場合もあるため
• 保護策：
  • オブジェクトロック（コストパフォーマンスが良い）
  • クロスアカウントレプリケーション
  • AWS Backup

ログの重要性

• CloudTrailログを有効にしていない限り、データ窃取の有無を判断できない
• S3アクセスログはオブジェクトレベルの追跡を提供
• 90日間の無料管理ログが利用可能

シフトレフト - 開発段階でのセキュリティ

デプロイ前にセキュリティバグをキャッチする方法：

• 静的アプリケーションセキュリティテスト（SAST）
• 動的アプリケーションセキュリティテスト（DAST）
• Amazon CodeGuruのようなAI支援型コード開発環境
• GitLeaksなどのツールでシークレットスキャン

Lambdaの脆弱性は、これらのツールを使っていれば開発段階で検出できました。

組織レベルの防御

Service Control Policies（SCP）

• 高価なEC2インスタンスのスピンアップを防止
• ゲノム研究や暗号マイニングなど特定のユースケースのみ必要な場合に制限

オフボーディングポリシー

• 退職者のアクセスキーが見つかるケースが非常に多い
• 適切なオンボーディング/オフボーディングポリシーが重要

まとめ

このワークショップを通じて学べる主なポイント：

1. IAM認証情報の保護が最重要 - ハッキングの66%がこれに起因
2. MFAの有効化 - 非常に効果的な防御手段
3. 本番環境からアクセスキーを排除 - ロールベースのアクセスに移行
4. IMDSv2への移行 - SSRF攻撃を防ぐ
5. ログとバックアップの重要性 - インシデント調査とデータ復旧のため
6. シフトレフトセキュリティ - 開発段階での脆弱性検出
7. 適切なオフボーディング - 退職者のアクセス権限を確実に削除

おわりに

今回のセッションで、実践的なAWSセキュリティインシデント対応の手法を学ぶことができました！

特に印象的だった点は、ハッキングの66%が有効なIAM認証情報によるもので、その3分の1がルートアカウント侵害だという統計です。
また、「クラウドだから大丈夫」という仮定は危険で、バックアップとログの設定は必須であることが強調されていました。

AWSカスタマーインシデント対応チーム（CIRT）の実際の経験に基づいた貴重な知見を得られるワークショップでした。

最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。

以上、おつまみ（＠AWS11077）でした！