【AWS re:Inforce 2025】GuardDuty と Step Functions で作るマルウェア自動隔離 (COM222)

マネージドサービス部佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。

はじめに
COM222 Serverless threat response for Amazon S3 malware detection 解説
関連情報
まとめ

はじめに

reinforce.awsevents.com

2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。

参加したセッションのまとめを「1日のまとめ」に書いていこうとしたらあまりにも文章量が増えすぎてしまったので小分けにしています。

本ブログは「【AWS re:Inforce 2025】現地参加レポート 1日目 6月16日(月) 佐竹版」より COM222 Serverless threat response for Amazon S3 malware detection の解説です。

私の感想やコメントは解説の邪魔になると感じたので「脚注」として記載しています。

COM222 Serverless threat response for Amazon S3 malware detection 解説

翻訳すると「Amazon S3 マルウェア検知のためのサーバーレス脅威対応」となります。

概要

このセッションでは Amazon S3 にアップロードされるファイルに対するマルウェアの脅威に対し、サーバーレスアーキテクチャで自動的に検知・隔離する実践的なワークフローが紹介されました*1。

Amazon GuardDuty Malware Protection をトリガーに、AWS Step Functions と AWS Lambda を連携させることで、悪意のあるオブジェクトが検知された際に、人手を介さずリアルタイムで隔離（Quarantine）までを実行することを目指します。これにより、データ保護を強化し、迅速な脅威対応を実現するスケーラブルなソリューションの構築方法が解説されました。

なぜ今、S3 のマルウェア対策が重要なのか？（課題）

セッションの冒頭では、多くのアプリケーションがユーザーからのファイルアップロード機能を持っており、日常的に大量のデータが Amazon S3 バケットにアップロードされている現状があることがまず示されました。

本スライドで構成図でも示されている通り、画像、ドキュメント、ログファイルなど、様々なデータが S3 バケットに集約されます。

しかし、「What if just one of those files... is malicious? (もし、そのファイルのうちの1つでも悪意のあるものだったら？)」という問いかけの通り、ここには重大なリスクが潜んでいます。

もちろん、Amazon S3 自体は「Secure by default (デフォルトで安全)」なサービスです。本スライドで示されているように、現在では以下の設定が標準となっています。

Automatically enabling S3 Block Public Access (S3 パブリックアクセスブロックの自動有効化)
Disabling S3 access control lists for all new S3 buckets (新規バケットでのS3 ACLの無効化)
Encryption new objects by default (SSE-S3) (デフォルトでのオブジェクト暗号化)

これらの設定により、意図しない情報漏洩のリスクは大幅に低減されています*2。

しかし、これらはあくまでバケットレベルの保護であり、アップロードされたオブジェクト自体の「中身の安全性」までを保証するものではありません。脅威を「即座に検知」し、自動で対応する仕組みが不可欠になります。

解決策としての自動修復アーキテクチャ

この課題に対する解決策として、サーバーレスサービスを組み合わせた自動修復アーキテクチャが提示されました。

その核となるのが「Amazon GuardDuty Malware Protection for S3」です。これを有効にすることで、S3 バケットに新しいオブジェクトがアップロードされると、GuardDuty が自動的にマルウェアスキャンを実行してくれるようになります。

スキャンの結果、オブジェクトには以下のいずれかのタグが付与されます*3。

NO_THREATS_FOUND – スキャンされたオブジェクトに脅威は見つかりませんでした。
THREATS_FOUND – スキャン中に潜在的な脅威が検出されました。
UNSUPPORTED – このオブジェクトのサイズが原因で GuardDuty はスキャンできません。
ACCESS_DENIED – GuardDuty はオブジェクトにアクセスできません。許可を確認してください。
FAILED – GuardDuty はオブジェクトをスキャンできませんでした。

このタグ付けをトリガーとして、後続の自動化ワークフローを起動します。

Step Functions で実装する自動化フロー

セッションで紹介されたアーキテクチャの全体像は以下のスライドの通りです。

このアーキテクチャの処理の流れをステップごとにまとめます。

イベント通知とワークフロー起動: S3 へのオブジェクト作成イベントを EventBridge が受け取り、Step Functions のワークフローを開始します。
タグの確認 (Check Object Tag): Step Functions の最初のステップで、GuardDuty によって付与されたタグを確認する Lambda 関数が実行されます。
処理の分岐 (Evaluate Tag): Step Functions の Choice ステートが、タグ情報に基づき処理を分岐させます。
- 脅威あり (THREATS_FOUND) の場合: Quarantine if threats found という別の Lambda 関数を呼び出します。この関数は、マルウェアと判定されたオブジェクトを隔離用の S3 バケットに移動させ、元のオブジェクトを削除します。
- その他の場合: NO_THREATS_FOUND や UNSUPPORTED などのタグに応じて、Do nothing/Custom Logic のパスに進み、ログ記録や通知など、ビジネス要件に合わせたカスタムロジックを実装します。

この仕組みの最大の利点は、AWS Step Functions を利用することで、一連の処理の流れが可視化され、管理やデバッグが非常に容易になる点です。

Step Functions のビジュアルワークフローは、複雑な処理を直感的に理解できるだけでなく、エラーハンドリングやリトライ処理も簡単に組み込めるため、堅牢なシステムを構築する上で非常に強力なツールです。

隔離後のアクションと拡張性

マルウェアは隔離して終わりではありません。インシデントとして記録し、関係者に通知し、分析に繋げるプロセスも重要です。

スライドでは「What happens after object quarantine? (オブジェクト隔離の後に何が起きるか？)」として、以下の例が示されました。

Send an alert via Amazon SNS (Amazon SNS でアラートを送信): セキュリティ担当者や関連チームにリアルタイムで通知します。
Write detailed data to Amazon DynamoDB (Amazon DynamoDB に詳細データを書き込む): いつ、どのファイルが、どのような脅威として検知されたか、といった詳細情報を永続的なデータストアに記録し、監査や分析に利用します。
Use AWS Systems Manager Incident Manager (AWS Systems Manager Incident Manager を使用): インシデントとして正式に起票し、対応計画の実行や根本原因分析といった、より構造化されたインシデント対応プロセスを開始します。

このように、Step Functions を介在させることで、様々なAWSサービスと連携して、自社のセキュリティ要件に合わせた対応フローを構築することが容易になります。

まとめ

本セッションでは、Amazon S3 バケットを特にパブリックに利用する上で避けては通れないマルウェア対策について、実践的な話題となっていました。

先の「関連情報」でもご紹介したのですが、このような Amazon GuardDuty Malware Protection をトリガーにした対応フローの自動化は「re:Post」に投稿された記事の通り、具体的な例として既に紹介されているものではあります。

単に「検知」するだけでなく、その後の「対応」までをサーバーレスで完全に自動化するという考え方は、3本目のブログでも触れた DevSecOps の思想そのものとなっています。特に、顧客からファイルをアップロードしてもらうようなシステムを構築している場合、このような仕組みを導入することは、サービスの信頼性を担保する上で極めて重要だと感じました。

また、アーキテクチャの中心に Step Functions を据えることで、複雑になりがちなインシデント対応フローを可視化し、管理しやすくしている点、「それを机上の空論ではなく実装して運用しているという事実」も参考になります。