GuardDuty 脅威検知深化 Vol2 — ETD/S3マルウェア/Runtime

1. 脅威検知の本番課題とExtended Threat Detection全体像

1-1. 本記事のゴール

クラウド環境を狙う攻撃は、2024年以降、単一のイベントでは検知できない多段階の攻撃シーケンスへと急速に高度化しています。攻撃者はまず漏洩したIAMクレデンシャルでアカウントに侵入し、S3バケットの偵察・IAMロールの列挙・CloudTrailログの改ざん試行を経て、最終的に機密データを外部へ持ち出します。このような攻撃は複数ステップにわたるため、個別のfindingだけでは全体像を把握するのが困難でした。

多段攻撃の典型的なフェーズを整理すると、以下のようになります。

• 初期侵害（Initial Access）：漏洩したIAMアクセスキー、フィッシング、または誤設定されたS3バケット経由での侵入
• 内部探索（Discovery）：IAMロール・ポリシー・リソースの列挙、CloudTrailログの改ざん試行
• 横断移動（Lateral Movement）：別アカウントへのAssumeRole、コンテナからホストへのエスケープ
• データ持ち出し（Exfiltration）：S3バケットからの大量データ取得、不審な外部エンドポイントへの通信

これら個々のステップは、単発で観測すると正常な操作と区別しにくい場合があります。アナリストは手動で複数のfindingを突き合わせて攻撃の全体像を再構成する必要があり、対応までの時間が延びるという課題がありました。

本記事はAWSが2024年末にGAしたGuardDuty新機能を本番運用の観点から体系的に解説します。本記事で扱う内容は次の通りです。

• Extended Threat Detection（ETD）：複数Signalsを時系列・空間的に相関させ、多段階攻撃シーケンス全体を一つのfindingとして検知
• Malware Protection for S3：S3へのアップロードファイルを自動スキャンし、検知時の事後処理を自動化
• Runtime Monitoring：EKS・EC2・ECSのランタイム挙動をエージェントで可視化
• EventBridgeを起点とした自動対応：新機能の検知結果をLambda・Step Functionsへ連携する実装パターン

GuardDutyの基礎（有効化・findingの種類・マルチアカウント集約）については後述の棲み分けナビで紹介する既存記事が詳しく解説しています。本記事はその先の「新機能の本番活用」に特化しています。

1-2. 読者像

本記事が想定する読者像を明示します。以下のいずれかに当てはまる方を主な対象としています。

• GuardDutyの基礎はすでに運用中の方：FindingType・重要度スコア・マルチアカウント集約・Security Hub連携といった基礎的な概念は既知として進めます。
• 2024-2025年のGuardDuty新機能（ETD・Malware Protection for S3・Runtime Monitoring）を本番環境へ組み込もうとしているセキュリティエンジニアまたはSREの方。
• SOCチームのアナリストとして、Critical重要度のattack_sequence findingへの対応フローを整備したい方。
• コスト管理担当者として、保護プラン追加によるコスト影響を見積もり、最適化ポリシーを設計したい方。

GuardDutyが初めての方は、まず後述の棲み分けナビで紹介する基礎記事からお読みください。有効化・findingの種類・Security Hub統合といった基礎は本記事では扱いません。

1-3. 2024-2025年のクラウド脅威トレンドとGuardDuty新機能全体像

クラウドを狙う多段攻撃の急増

2024年以降、クラウド環境を標的とした攻撃の多くは、複数のステップを組み合わせた多段攻撃の形をとっています。攻撃者は単一の侵害アクションで済ませるのではなく、複数のフェーズを経ることで、各ステップ単体では正常な操作と区別しにくい行動を積み重ねます。

この攻撃手法が増加している背景には、クラウド環境のアクセス制御が複雑化していることがあります。IAMロール・ポリシー・サービスプリンシパル・リソースベースのポリシーが絡み合う環境では、適切に設定されていない権限や誤設定が攻撃者の足がかりになります。また、コンテナ・サーバーレス・マルチアカウントといったアーキテクチャは、横断移動の経路が多様化しているという側面もあります。

GuardDuty新機能の3本柱

AWSはこの課題に対し、以下の3機能をGAしました。

各機能の料金は有効化するリージョン・データ量・エージェント数によって異なります。最新の料金については公式料金ページを参照してください。

Extended Threat Detectionの概要

Extended Threat Detectionは、GuardDutyが生成するSignals（既存findingやIAMエンティティの異常行動など）を機械学習モデルで時系列・空間的に相関させます。複数のSignalsが攻撃シーケンスの一部と判断されると、attack_sequenceというfindingタイプが生成されます。

攻撃シーケンスfindingの重要度はCritical（9.0〜10.0）として報告されます。GuardDutyの重要度はLow（1.0〜3.9）・Medium（4.0〜6.9）・High（7.0〜8.9）・Critical（9.0〜10.0）の4段階で、Criticalは最上位に相当します。SOCのアラート対応フローでは、Criticalを最優先キューとして扱う設定が推奨されます。

ETDの重要な特徴は、追加コストが発生しない点です。ETDは既存の保護プラン（CloudTrailログ・VPCフローログ・DNSログ）に含まれるデータの範囲内で動作します。S3保護・EKS保護・Runtime Monitoringを追加有効化すると、これらのデータも相関対象に加わり、検知の網をさらに広げることができます。

ETDは24時間のローリングウィンドウで動作します。このウィンドウ内に発生したSignalsが相関対象となります。攻撃が24時間を超えて分散して行われる場合、シーケンスとして検知されない可能性がある点を理解しておくことが重要です。

1-4. 既存SOC運用との棲み分けナビ

GuardDuty関連記事の全体像と本記事の位置づけを整理します。どの記事から読み始めるべきかをここで確認してください。

既存の基礎機能（CloudTrailイベント監視・VPCフローログ解析・DNSクエリ監視）は、引き続きGuardDutyのコア機能として稼働しています。本記事が扱うExtended Threat Detectionはこれらの基礎機能を土台としてシーケンス相関します。基礎機能の無効化はできません。ETDを最大限活用するためには、S3保護・EKS保護・Runtime Monitoringといった追加保護プランを有効化することが推奨されます。これらの詳細は§2・§3・§4・§5で解説します。

1-5. 本記事の構成と読み方

本記事は次の流れで解説を進めます。初めて読む方は順を追って読み進めることで、全機能の全体像と本番運用パターンを体系的に習得できます。特定のトピックだけを知りたい方は、関連するセクションへ直接進んでください。

§2: Extended Threat Detectionの基礎

攻撃シーケンス検知の仕組み（Signals相関・24時間ローリングウィンドウ）と、デフォルト有効化の範囲・追加コストの考え方を解説します。ETDがどのようにattack_sequence findingを生成するかの理解に必要な基礎知識を扱います。

§3: 保護プラン連携による検知範囲の拡大

基礎データソース（CloudTrail・VPCフローログ・DNSログ）とS3保護・EKS保護プランの関係を整理します。保護プランを追加した際の検知範囲の拡大と、保護プラン選定の判断軸を解説します。

§4: Malware Protection for S3

S3オブジェクトアップロード時の自動スキャンフロー・スキャン結果タグ・EventBridgeを使った事後処理の自動化を解説します。具体的な設定手順と運用上の注意点を含みます。

§5: Runtime Monitoring

EKS・EC2・ECSそれぞれのエージェントデプロイ方式・前提条件・検知されるFindingTypeを詳説します。Systems Managerを使ったEC2向けデプロイの自動化パターンも扱います。

§6: 新検知タイプと運用・コスト管理

attack_sequenceのFindingType・日々の運用フロー・アラート疲労対策・自動対応フロー・コスト最適化を解説します。本番SOC運用に直結する実装パターンを中心に構成しています。

§7: 実戦統合パターン

EventBridgeを起点とした自動対応のエンドツーエンド実装・Security Hubとの集約・インシデント対応への接続といった実戦的な統合パターンを解説します。

§8: 詰まりポイント・アンチパターン・まとめ

本番運用で遭遇しやすい詰まりポイントと、回避すべきアンチパターンを整理します。既存GuardDuty記事へのクロスリンクも含みます。

GuardDuty新機能の全体像を把握した上で、実際にどの機能から有効化するかの判断は§3（保護プラン選定の判断軸）を参照してください。すでに特定の機能を有効化しており、運用フローの整備を急いでいる方は§6へ直接進むことを推奨します。

なお、本記事全体を通じて料金の単価は断定せず「公式料金ページ参照」として扱います。GuardDutyの料金はリージョン・データ量・保護プランの組み合わせによって変動するため、最新情報はAWS公式料金ページで確認してください。

2. Extended Threat Detectionの基礎

2-1. AI/ML多段攻撃シーケンス相関の仕組み

Amazon GuardDutyのExtended Threat Detection（以下、ETD）は、GuardDutyが収集する複数のデータソースにわたる個別のイベントを「シグナル（Signals）」として蓄積し、機械学習モデルを用いてこれらを相関させることで、単発の検知では見抜けない多段階攻撃を高精度に発見する機能です。

従来の検知アプローチでは、1件ごとのfindingを評価するため、各イベントは単独では無害に見える一連の操作の組み合わせによる攻撃（重要度の低いイベントが何件も重なって初めて侵害と判定できるケース）を見逃す傾向がありました。ETDはこの弱点を補い、攻撃者が意図的に「目立たない行動を積み重ねる」手口にも対応できる設計になっています。

ETDの内部では、GuardDutyが管理するAIモデルは以下のプロセスで多段攻撃を検知します。

1. 複数のデータソースから個別イベントをシグナルとして収集する
2. 24時間のローリングウィンドウ内で複数のシグナルを蓄積する
3. シグナル間の時系列的・論理的なつながりを分析し、既知の攻撃パターンと照合する
4. 攻撃シーケンスが成立すると判断した場合に、重要度CriticalのAttack Sequence findingを生成する

このプロセスは完全にマネージドで実行されます。ユーザー側でモデルの学習やチューニングを行う必要はなく、GuardDutyが有効化されている環境でETDも自動的に機能します。

ETDが検知の対象とするシグナルには、単独では重要度が中〜低程度のイベントも含まれます。たとえば「普段は使わないAPIを1回呼び出した」「特定リージョンへのアクセスが初めて発生した」といった事象は、単独では警告には至りません。しかしこれらが「IAM権限昇格の試みと思われるAPI呼出し」→「内部ネットワーク偵察」→「機密データへのアクセス」という流れで連続して発生した場合、ETDはこれを一連の攻撃シーケンスとして判定します。

この「弱いシグナルの積み重ね」を自動で評価できることが、ETDの最大の価値です。SOCアナリストが手動でイベントをつなぎ合わせる作業を大幅に削減し、攻撃の早期発見に貢献します。

2-2. Signalsの相関対象となるデータソース

ETDが参照するシグナルは、GuardDutyが取り込む以下のデータソースから収集されます。各データソースの有効化状況によって、ETDが参照できるシグナルの種類と量が変わります。

基礎データソース（GuardDuty有効化と同時に収集）

GuardDutyを有効化すると、追加設定なしで以下の3つのデータソースからシグナルが収集されます。

• AWS CloudTrail（管理イベント）: AWSサービスへのAPI呼出しの記録です。IAMロールの引き受け・セキュリティグループの変更・S3バケットポリシーの変更といった管理操作を収集します。ETDでは、権限昇格や防御回避に関連するAPI呼出しのシーケンスを検知する際の主要なシグナル源となります。

• VPC Flow Logs: VPC内外のネットワークフローの記録です。インスタンス間の異常な内部通信・既知の悪意あるIPアドレスへの通信・大量のポートスキャンなどを収集します。ETDでは、偵察や横展開の段階での異常ネットワーク行動を示すシグナルとして活用されます。

• DNS Logs: Route 53リゾルバー経由の名前解決記録です。悪意あるドメインへの通信・Domain Generation Algorithmによって生成されたドメインへのアクセスを収集します。ETDでは、感染後のC2通信やデータ持ち出しの兆候を検知するシグナルとして使われます。

保護プランによる拡張（別途有効化が必要）

以下の保護プランを有効化することで、ETDが参照できるシグナルの種類と粒度が大幅に拡張されます。

• S3保護: S3データイベント（GetObject・PutObject・DeleteObject等）を収集します。機密データへの異常アクセス・大量ダウンロード・パブリックアクセスに関連する操作のシーケンスを検知する際に不可欠です。特にAttackSequence:S3/プレフィックスを持つfindingの検知精度に直接影響します。

• EKS保護（EKSコントロールプレーンログ）: EKSクラスターのAPIサーバーへの操作記録を収集します。コンテナへの不正な権限付与・機密Secretsのアクセス・ノードへの横展開といったKubernetes環境特有の攻撃シーケンスを検知するために必要です。AttackSequence:EKS/CompromisedClusterの検知に必須の保護プランです。

• Runtime Monitoring（EKS/EC2/ECSのランタイムイベント）: GuardDutyセキュリティエージェントがインスタンスやコンテナのランタイム挙動（プロセス実行・ファイル操作・ネットワーク接続）をリアルタイムで収集します。シェルの逆接続・権限昇格ツールの実行・機密ファイルへのアクセスといったランタイムレベルの攻撃行動を検知します。

保護プランを有効化するほど、ETDが参照できるシグナルの粒度と範囲が広がり、より精度の高い相関分析が可能になります。特にEKS保護とRuntime Monitoringを組み合わせることで、コンテナ環境に対するAttackSequence:EKS/CompromisedClusterの検知精度が大きく向上します。

archived/suppressedのfindingは相関対象外

重要な注意点として、GuardDutyの抑制ルール（suppression rule）によってarchivedまたはsuppressedの状態になっているfindingは、ETDのシグナルとして利用されません。

既存の抑制ルールを広範囲に設定している環境では、正当な攻撃の痕跡はシグナルから除外され、ETDの相関分析は機能しなくなる可能性があります。抑制ルールの見直しは、ETDを本番導入する前の重要な準備作業です。この点は §8の詰まりポイントでも改めて取り上げます。

2-3. Attack Sequence findingsの種類と重要度

ETDによって生成されるAttack Sequence findingは、通常のGuardDuty findingとは異なる形式と体系を持っています。

finding名の読み方

Attack Sequence findingのfinding名は次の形式に従います。

AttackSequence:<リソースタイプ>/<シーケンス名>

AttackSequenceというプレフィックスが付くことで、通常の単発findingとは区別されます。<リソースタイプ>はどのAWSリソースが標的になったかを示し、<シーケンス名>は検知された攻撃シーケンスのパターンを表します。

主要なAttack Sequence finding一覧

以下は2025年時点でGAとなっている主要なAttack Sequence findingです。

これらのfindingはすべて重要度Criticalとして生成されます。GuardDutyの重要度スコアで言えばスコア9.0以上に相当し、即時対応が必要な最高優先度のアラートです。

通常のGuardDuty findingで重要度Criticalが付くケースはまれですが、Attack Sequence findingが生成された場合には必ずCriticalが付与されます。これにより、アラート疲れが発生しやすい環境においても、ETD由来のfindingはSeverity=CRITICALとして明確に際立ちます。

24時間ローリングウィンドウの考え方

ETDは24時間のローリングウィンドウでシグナルを蓄積します。この時間窓内に発生したシグナルを相関させ、攻撃シーケンスの成立を判定します。

ウィンドウが「ローリング」であることの意味は、固定の0時〜24時ではなく、常に「直近24時間」を見続けることです。攻撃者が深夜から翌朝にかけて段階的に操作を実施するような場合でも、シグナルが途切れることなく相関対象となります。

2-4. Threat Purposeの体系とID読み方

GuardDutyのfindingを理解する上で、Threat Purposeの分類体系を把握しておくと運用に役立ちます。ETDのコンテキストでは、複数のThreat Purposeにまたがる一連の行動が観測されることでAttack Sequence findingが生成されます。

Attack Sequence findingは、複数のThreat Purposeにまたがる一連の攻撃行動を背景として生成されるケースが多く、ETDはそのシーケンスを自動で可視化します。たとえばAttackSequence:EKS/CompromisedClusterであれば、InitialAccess（コンテナへの侵入）→Execution（コマンド実行）→PrivilegeEscalation（権限昇格）→LateralMovement（他Podへの横展開）というシーケンスが背景にある場合が典型的です。

2-5. 有効化と追加コストの考え方

自動有効化の範囲

ETDはGuardDutyを有効化した時点で自動的に機能します。別途「Extended Threat Detectionを有効にする」という専用の操作は不要です。GuardDutyのコンソールで「Extended Threat Detection」セクションを確認すると、動作中であることが表示されます。

追加コストはゼロ

ETD自体の利用に追加コストはかかりません。既存のGuardDuty基礎データソース（CloudTrail/VPC Flow Logs/DNS Logs）の処理料金がそのまま適用されます。保護プランを有効化している場合は、それぞれの保護プランの料金体系に従いますが、ETDによる「相関分析の実行」自体は課金対象外です。

ただし、検知精度を高めるために保護プランを追加有効化すると、その保護プランの料金が別途発生します。コストと検知精度のバランスを考慮した保護プランの選定は、§3で詳しく説明します。

マルチアカウント環境での有効化

AWS Organizationsを用いたマルチアカウント環境では、GuardDuty Administratorアカウントから一括してメンバーアカウントのETDも有効化できます。各メンバーアカウントごとに個別の操作は不要です。委任管理者アカウントを経由したOrganizations統合管理が推奨構成です。Organizationsポリシーで「新しく参加するメンバーアカウントにGuardDutyを自動有効化する」設定をすることで、メンバーアカウントの追加時にも自動でETDが有効化されます。

2-6. ETDを最大限に活用するための導入チェックリスト

ETDを本番環境で効果的に運用するために、以下のチェックリストを参考にしてください。

基本有効化チェック

• [ ] GuardDutyが全対象アカウント・全リージョンで有効化されていること
• [ ] GuardDutyのAdministratorアカウント（Organizations委任管理者）が設定されていること
• [ ] 全メンバーアカウントでGuardDutyが有効化されていること（Organizationsの自動有効化ポリシー活用）

保護プランチェック（ETDのシグナル源として重要）

• [ ] S3保護が有効化されていること（S3系AttackSequence findingに必須）
• [ ] EKS保護が有効化されていること（EKS系AttackSequence findingに必須）
• [ ] Runtime Monitoringが高リスクワークロードに有効化されていること

抑制ルールチェック（ETD導入前に必ず実施）

• [ ] 既存の抑制ルールを全件棚卸しし、広範な包括ルールが設定されていないことを確認
• [ ] ETDに必要なシグナルを除外する抑制ルールがないことを確認
• [ ] 必要な抑制ルールはリソースタグや特定のIAMエンティティを条件として絞り込んでいること

アラート対応チェック

• [ ] EventBridgeでSeverity=CRITICALのfindingを即時通知するルールが設定されていること
• [ ] SOCの対応フローにAttack Sequence finding専用のエスカレーションパスが定義されていること
• [ ] 自動対応（Lambda/Step Functions）を使用している場合はホワイトリストが実装されていること

3. 保護プラン連携による検知範囲の拡大

3-1. 基礎データソースと保護プランの関係

§2では各データソースとシグナル相関の仕組みを概説しました。本項ではその各データソースが「何を新たに可視化するか」と「どの保護プランで有効化されるか」を整理し、次項の具体的な検知パターンにつなげます。

基礎データソース3種の可視化対象

GuardDutyを有効化した時点から追加費用なしで収集される基礎データソースは、AWSコントロールプレーン全体を網羅します。

CloudTrail管理イベントはAWS APIへのすべての呼び出しを記録します。IAMロールの作成・S3バケットポリシーの変更・KMS鍵の削除・CloudTrail自体のログ削除といった操作が含まれます。ETDにとって最も汎用性が高いシグナル源であり、権限昇格・防御回避・認証情報の悪用といった攻撃キルチェーンの多くのフェーズをカバーします。

VPC Flow LogsはVPC内外のネットワークフローを記録します。インスタンス間の異常な通信・既知の悪意あるIPアドレスへの接続・大量のポートスキャンが検知対象です。ETDではこれを「攻撃者がC2と通信している」「横断移動でネットワークをスキャンしている」というシグナルとして活用します。

Route 53 DNS LogsはVPC内リゾルバー経由の名前解決を記録します。ドメイン生成アルゴリズム（DGA）が生成したドメインへのクエリや、GuardDutyの脅威インテリジェンスに含まれる悪意あるドメインへのアクセスを検知します。マルウェア感染後のC2通信チャネル特定において重要なシグナル源です。

保護プランが追加するデータレイヤーとETDへの寄与

基礎データソースはAWSコントロールプレーンを監視しますが、S3・EKS・ランタイムというデータプレーンの操作は基礎データソースだけでは捉えきれません。各保護プランはこのギャップを埋め、ETDが参照できるシグナルの種類を拡張します。

S3保護が追加するのはS3データプレーンイベントです。GetObject・PutObject・DeleteObject・CopyObjectといったS3 APIの実行記録が相関対象に加わります。基礎データソースのCloudTrail管理イベントで「PutBucketPolicyでバケットを公開設定にした」は捉えられますが、「その後に1,000件のGetObjectが外部IPから実行された」は捉えられません。S3保護を有効化することで、制御操作とデータ操作を結びつけた完全な攻撃シーケンスが成立します。

EKS保護が追加するのはEKS Audit Logです。KubernetesのAPIサーバーへのすべての操作が記録され、Podの作成・削除・Secretへのアクセス・RBACポリシーの変更・Namespaceを越えた操作などが相関対象に加わります。クラウドのIAM操作（CloudTrail）とKubernetesのコントロールプレーン操作（EKS Audit Log）を時系列で突き合わせることで、コンテナ環境からAWSアカウントへの横断攻撃が1件のAttack Sequence findingとして集約されます。

Runtime Monitoringが追加するのはEKS・EC2・ECSのランタイムイベントです。実際に実行されたプロセスのコマンドライン・開いたネットワーク接続・アクセスしたファイルパスがシステムコールレベルで記録されます。CloudTrailとEKS Audit Logが「APIレベルで何が起きたか」を記録するのに対し、Runtime Monitoringは「OSレベルで何が実行されたか」を記録します。この解像度の違いがETDのシグナル精度を大幅に向上させます。

保護プラン有効化でETDが検知可能になる攻撃シーケンスの対応

保護プランと検知可能な攻撃シーケンスfindingの関係を整理します。S3保護を有効化するとAttackSequence:S3/CompromisedAccountやAttackSequence:S3/CredentialHijackの検知に必要な複合シグナルが成立します。EKS保護を有効化するとAttackSequence:Kubernetes/CompromisedAccountの検知に必要なKubernetes APIシグナルが加わります。Runtime Monitoringを有効化すると上記の各攻撃シーケンスへの解像度がさらに高まり、ランタイムレベルの攻撃活動（ファイルレス攻撃・コンテナブレイクアウト）が個別findingとしても検知されます。これらのランタイムfindingは単独でもシグナルとなり、ETDの相関に寄与します。

弱いシグナルの蓄積から攻撃シーケンス判定まで

保護プランを複数組み合わせることで、弱いシグナルの蓄積効果は高まります。IAMユーザーによる初回リージョンからのAPIコール（CloudTrail・Low重要度）直後に、S3バケットのアクセス制御設定を変更し（CloudTrail管理イベント・Medium重要度）、外部IPアドレスから大量のGetObject実行（S3データイベント・High重要度）という3つのシグナルが24時間ウィンドウ内で発生した場合、ETDはこれらをAttackSequence:S3/CompromisedAccountとして集約します。S3保護がなければ、3番目のシグナルは取り込まれないため、Attack Sequence findingを生成できない可能性があります。

3-2. S3保護・EKS保護の有効化

S3保護による具体的な検知強化パターン

S3保護を有効化してETDの相関精度が向上する具体的なパターンを解説します。

(1) 認証情報侵害→大量ダウンロードシーケンス

攻撃者がIAMアクセスキーを入手した場合の典型的な流れです。偵察フェーズでは、攻撃者がListBuckets・ListObjects・GetBucketLocation・GetBucketPolicyを短時間に連続実行して機密データが含まれるバケットを特定します。これらのAPIコールはCloudTrail管理イベントとして記録されます。正規のユーザーも実行するため、単発では低〜中重要度のシグナルにとどまります。

データ持ち出しフェーズでは、対象バケットを特定した攻撃者が大量のGetObjectを実行します。通常の利用パターンを大幅に超える件数・大きさのオブジェクト取得が発生します。S3保護が有効でなければ、このS3データイベントはシグナルに含まれません。S3保護が有効化されている場合、ETDが偵察フェーズのCloudTrailシグナルとデータ持ち出しフェーズのS3データイベントシグナルを24時間ウィンドウ内で相関させ、AttackSequence:S3/CompromisedAccountを生成します。

(2) バケットパブリック公開→外部窃取シーケンス

内部者による意図的な情報漏洩またはIaCの誤設定が引き金になるパターンです。設定変更フェーズではPutBucketPolicy・PutBucketAcl・DeletePublicAccessBlockといったアクセス制御変更が実行されます（CloudTrail管理イベント）。外部アクセスフェーズでは、設定変更の後にこれまでアクセス実績のない外部IPアドレスからGetObjectが実行されます（S3データイベント）。S3保護によってこのデータプレーンアクセスがシグナルに加わり、設定変更と外部アクセスの時系列相関が成立します。S3 Block Public Accessが組織SCPで強制されている環境でも、バケット単位の変更が発生した場合はシグナルとなります。

(3) マルウェア配布バケットの利用検知

攻撃者がC2インフラとしてS3バケットを利用するパターンです。侵害したIAM認証情報でS3バケットにペイロードをアップロードし、感染したホストがそのS3バケットからペイロードをダウンロードします。S3保護によってPutObject（アップロード）とGetObject（ダウンロード）の両方がシグナルとなり、DNS Logs・VPC Flow Logsのシグナルと組み合わせた相関が可能になります。

EKS保護による具体的な検知強化パターン

(1) コンテナSecret漏洩→IAMクレデンシャル悪用シーケンス

EKS Audit Logが加わることで、Kubernetes APIレベルの操作とAWS APIレベルの操作を時系列で突き合わせた相関が可能になります。第1フェーズでは、アプリケーションコンテナの脆弱性を突いた攻撃者がKubernetes APIを通じてSecretを列挙します。list secrets・get secretsといった操作がEKS Audit Logに記録されます。通常のアプリケーションPodがNamespace外のSecretをlistするユースケースは限られており、このパターンがシグナルとして蓄積されます。

第2フェーズでは、取得したKubernetesのSecret（AWS認証情報が含まれていた場合）またはPodのIRSA（IAM Roles for Service Accounts）を利用して、CloudTrail側で異常なAWS APIコールが発生します。たとえば特定のPodに紐付くService Accountが通常はs3:GetObjectしか使わないのに、突然iam:CreateAccessKeyやsts:AssumeRoleを実行した場合、ETDはEKS Audit LogのSecret取得タイミングとCloudTrailの異常APIタイミングを突き合わせてシーケンスと判定します。

(2) 特権Pod作成→コンテナブレイクアウトシーケンス

攻撃者が十分な権限を持つKubernetesサービスアカウントを入手した場合、特権Pod（privileged: trueの設定を持つPod）やhostPathボリュームマウントを使ったPodを作成してホストのファイルシステムにアクセスします。EKS Audit Logにはcreate pods操作とそのPodのセキュリティコンテキスト情報が記録されます。GuardDutyはPod作成のAPI呼び出しに含まれるセキュリティコンテキストを評価し、特権コンテナ作成やホストの重要ディレクトリへのマウントをシグナルとして識別します。Runtime Monitoringを同時に有効化している場合、作成された特権Podのコンテナ内でのプロセス実行がランタイムシグナルとして加わり、シーケンスの精度が高まります。

Runtime Events相関による攻撃活動の解像度向上

Runtime MonitoringがETDに提供するプロセス・ネットワーク・ファイル操作のシグナルは、CloudTrailやEKS Audit Logでは捉えられない「実行の現場」を記録します。

プロセスシグナルの例として、コンテナやEC2インスタンスでアプリケーションコンテナ内での/bin/bash -c起動・Webサーバープロセスを親プロセスとするシェルの起動・wget・curl・nc（netcat）・chmod +xといった攻撃者が利用するコマンドの実行パターンが検知対象です。

ネットワークシグナルの例として、GuardDutyの脅威インテリジェンスに登録されたIPアドレス・Torエグジットノード・既知のC2インフラへの接続を記録します。特に通常のアプリケーションでは接続しないアウトバウンドのポートへの接続が検知対象です。

ファイル操作シグナルの例として、/etc/passwd・/etc/shadow・/etc/crontab・/root/.ssh/authorized_keys・コンテナイメージに存在しないパスへの書き込みを記録します。これらのシステムファイルへの変更は攻撃者の永続化フェーズの典型的な行動です。

CloudTrailとEKS Audit LogとRuntime Eventsを組み合わせることで、「コンテナで不審なシェルが起動し（Runtime Events）→EKSクラスター内のSecretを列挙し（EKS Audit Log）→IAM APIで権限昇格を図った（CloudTrail）」という多段攻撃シーケンスを1件のAttack Sequence findingとして集約できます。

3-3. 保護プラン選定の判断軸

ワークロード構成から始める保護プランマッピング

保護プランの有効化判断は「自組織で想定される攻撃シナリオ」と「自組織のワークロード構成」の両軸で考えます。全プランを一括有効化すれば最高の検知精度が得られますが、コストと運用の複雑さも比例して増加します。以下のステップで優先順位を決定します。

Step 1: S3の利用状況を確認（ほぼ全環境向け）

S3を機密データの保管・転送・共有に利用している場合、S3保護の有効化は最優先です。攻撃シナリオの多くがデータ持ち出しフェーズでS3を経由するため、S3保護なしでは最も重要な攻撃シーケンスの一部を検知できない状態になります。コストはS3データプレーンイベントのボリュームに依存するため、公式料金ページおよびAWS Cost Explorerで事前に試算してください。

Step 2: EKSクラスターの有無を確認

EKSクラスターを1つでも運用している場合、EKS保護の有効化を強く推奨します。EKS保護を有効化しない場合、ETDがKubernetesコントロールプレーンの操作を一切認識できないため、コンテナ環境を標的にした攻撃シーケンスが検知の死角になります。EKS Audit LogはEKSのコントロールプレーンログとしてCloudWatch Logsに出力するよう設定している環境が多く、GuardDutyへの取り込みによる運用負荷の増加はほぼありません。

Step 3: Runtime Monitoringの導入優先度を決定

Runtime Monitoringは最も高い検知解像度を提供しますが、エージェントのデプロイという運用コストが伴います。EKS向けRuntime MonitoringはEKS Add-onとして自動デプロイできるため運用負荷が最も低く、EKSクラスターを運用している場合はEKS保護と合わせて有効化を検討します。EC2向けRuntime MonitoringはSystems Manager経由のデプロイが必要です。インターネットからリクエストを受けるWebサーバー・踏み台インスタンス・認証情報を扱うバックエンドサーバーといった高リスクワークロードから段階的に展開します。全EC2インスタンスへの一括有効化は大規模環境ではコストが急増するため注意します。ECS Fargate向けRuntime MonitoringはFargateプラットフォームバージョン1.4以降でエージェントが自動注入されるため、追加デプロイ作業は不要です。

Step 4: Malware Protection for S3の適用範囲を決定

ユーザーからのファイルアップロードを受信するS3バケット（UGC保管・ドキュメント管理・ファイル共有サービス等）が存在する場合に有効化します。スキャン料金はアップロードのボリュームに依存するため、月次のPutObject件数を事前に確認してコストを試算します。内部システムのみが書き込むログバケット・バックアップバケット・AWSサービスが生成するアーティファクトバケットは、外部からの不審ファイル混入リスクが低く、スキャン対象から除外することでコストを最適化できます。

攻撃シナリオ別の推奨保護プランセット

代表的な攻撃シナリオと推奨する保護プランの組み合わせを示します。

認証情報漏洩→データ持ち出しシナリオへの対応セットは「S3保護 + Runtime Monitoring（EC2）」です。CloudTrail（偵察）+ S3データイベント（持ち出し）+ Runtime Events（侵害後のプロセス活動）の3層で攻撃キルチェーンを捕捉します。

コンテナ侵害→AWSアカウント横断シナリオへの対応セットは「EKS保護 + Runtime Monitoring（EKS）」です。EKS Audit Log（Kubernetes操作）+ Runtime Events（プロセス・ネットワーク）+ CloudTrail（AWS API悪用）の3層でコンテナからAWSへの横断を捕捉します。

S3バケット公開→データ窃取シナリオへの対応セットは「S3保護のみ」です。CloudTrail管理イベント（アクセス制御変更）+ S3データイベント（外部アクセス）の2層で構成でき、コンテナ基盤のない環境でも完結します。

マルウェア感染→リソース悪用シナリオへの対応セットは「Runtime Monitoring（全ワークロード対象）+ Malware Protection for S3」です。ランタイムレベルのマルウェア実行とS3経由の拡散経路を両方カバーします。

Organizations環境での一括有効化方針

マルチアカウント環境では、GuardDutyのDelegated Administratorアカウントから各保護プランを「組織全体で自動有効化」に設定することで、新規アカウント追加時にも保護が漏れません。ただし全プランを組織全体で自動有効化すると予想外のコスト増加につながる可能性があるため、Step 1（S3保護）→Step 2（EKS保護）→Step 3（Runtime Monitoring、高リスクワークロード対象）という順序で各段階のコストと検知効果を評価しながら適用範囲を段階的に広げることを推奨します。メンバーアカウントが手動で保護プランを無効化できる設定になっていないかを定期確認し、組織全体で一貫した保護プラン適用を維持することが重要です。

保護プラン有効化後の動作確認

保護プランを有効化した後は、GuardDutyが正しくシグナルを収集しているかを検証することが重要です。有効化直後に期待するfindingが発生しない場合、設定の不備やアクセス権限の問題が原因のことがあります。

GuardDutyコンソールのSettings → Protection plansでは、各プランのステータスと有効化範囲を確認できます。Organizationsを利用している場合は、メンバーアカウントへの展開状況もこのページで一覧確認します。ステータスが「設定中」のまま長時間経過する場合は、GuardDutyのサービスリンクロールに必要な権限が付与されているかを確認します。

S3保護の動作確認には、Usage statisticsページでS3DataEventsリソースタイプのデータ量が発生しているかを確認します。ゼロの場合はサービスリンクロールの設定や、CloudTrailのS3データイベント記録設定を見直します。S3保護は有効化から数分でデータ収集が開始されます。通常の業務時間帯であれば数十分以内にUsage statisticsのデータが反映されます。

EKS保護の動作確認では、EKS Audit Logの取り込み量をUsage statisticsで「EKSAuditLogs」として確認します。EKSクラスターとGuardDutyが同一リージョンに存在しない場合、EKS Audit LogはGuardDutyに取り込まれません。マルチリージョン構成ではリージョンごとにEKS保護を個別に有効化する必要があります。クラスターへのKubernetes APIアクセスが一切ない状態では取り込み量がゼロになる場合もあるため、テスト用のkubectlコマンドを実行して反応を確認します。

Runtime Monitoringの動作確認では、GuardDutyコンソールのRuntime Monitoring設定ページで各EKSクラスターのSecurity agent statusが「Healthy」であることを確認します。ECSタスクやEC2インスタンスについても同様にエージェントの状態を確認します。Unhealthyの場合はアドオンのバージョン互換性やノードIAMロールの権限不足を確認します。EC2向けはSSM Agentのバージョンも確認対象です。

既存セキュリティツールとの役割分担の明確化

GuardDutyの保護プランはAWS環境のデータソースを対象とした脅威検知に特化しています。WAFやEDRツールとの役割分担を整理することで、重複投資を避けながら防御の多層化を実現できます。

WAFはWebアプリケーション層のパターンマッチングによる攻撃ブロックを担い、GuardDutyは攻撃者が侵入した後の行動（認証情報の悪用・横断移動・データ持ち出し）を検知します。両者は補完関係にあります。GuardDuty findingをWAFのIPブロックリストに自動反映するEventBridge連携を組み合わせることで、検知から防御への自動化が実現します。

EDRツールはエンドポイントのファイル・プロセス・レジストリを詳細に監視しますが、AWSサービス（Lambda・RDS・S3等）のサーバーレスリソースはEDRの監視対象外です。GuardDutyのRuntime Monitoringはコンテナ・EC2のランタイムイベントを収集し、ETDとの相関によってサーバーレス環境とコンピュート環境を横断した攻撃シーケンスを検知します。社内EDRと機能が重複するように見えるRuntime Monitoringも、AWSのIAM操作やS3アクセスとのシグナル相関においてはGuardDuty固有の価値を提供します。

SIEM（Security Information and Event Management）との統合では、Security HubのASFF形式でGuardDuty findingをSIEMに取り込むことが最も一般的です。Attack Sequence findingsはSIEM上でCritical重要度のアラートとして表示され、既存のSIEMルールと組み合わせたコリレーションが可能です。GuardDutyのfindingはJSON形式でEventBridgeを経由してFirehose→S3→SIEMへ転送する構成もよく採用されます。既存のSIEM運用フローにGuardDutyを組み込む際は、ASFF形式のスキーマをSIEMのパーサーに登録することで、FindingType・影響リソース・重要度・地域情報を構造化データとして活用できます。

保護プランを段階的に追加するたびに、新しいfindingタイプがSIEMに流入します。SIEM側で事前にGuardDutyの全findingタイプを把握し、対応するアラートルールとエスカレーションフローを準備しておくことで、新機能有効化直後の混乱を防止できます。GuardDutyのドキュメントに公開されているfinding一覧は各リリースで更新されるため、定期的な確認が推奨されます。

Zero Trust Architectureを採用している組織では、GuardDutyの保護プランが提供するデータプレーン可視性はゼロトラストの監査証跡として活用できます。S3データプレーンイベント（S3保護）・Kubernetes APIアクセスログ（EKS保護）・プロセス実行記録（Runtime Monitoring）は、ゼロトラスト評価エンジンが必要なコンテキスト情報と重なります。GuardDuty findingをゼロトラストのポリシーエンジンにフィードバックし、リスクスコアの動的更新に活用する統合パターンも将来的な拡張として検討できます。

本節で解説した保護プランの連携・動作確認・ツール統合の観点は、§7の実戦統合パターンと密接に関連します。保護プランの選定（§3-3）が完了したら§7-1の段階的導入ロードマップに沿って実装を進め、各フェーズで本節の動作確認手順を適用することで、確実かつ段階的にGuardDutyの検知能力を拡充できます。

GuardDutyのfindingはAWS Security HubのASFF形式に準拠しており、クラウドセキュリティエコシステム全体との相互運用性が高い設計になっています。保護プランを追加するごとに新しいfindingタイプが利用可能になり、SOCの検知能力と対応範囲を段階的に拡張できます。各保護プランが提供するシグナルの質と量を理解した上で有効化の優先順位を決定することが、費用対効果の高いセキュリティ運用の基盤となります。次節以降では各保護プランの詳細な仕組みと設定手順を解説します。

保護プランの追加は後から行えますが、ETDが攻撃シーケンスを正確に判定するには各シグナルの蓄積期間が必要です。有効化のタイミングが遅れると、過去に遡及したシグナルの相関はできないため、早期有効化が推奨されます。

4. Malware Protection for S3

Malware Protection for S3 は、Amazon GuardDuty が提供する保護プランの一つで、S3 バケットへアップロードされたオブジェクトをリアルタイムでマルウェアスキャンします。2024年6月に一般提供（GA）となり、東京リージョンを含む全リージョンで利用できます。

アップロードファイルを起点とした侵害（マルウェア配布・ランサムウェア拡散・データ汚染）を防ぐために、アップロード後即座にスキャンし、結果に応じた自動対処へつなげる設計が重要です。

4-1. 対象バケットの設定とスキャン

有効化の手順

Malware Protection for S3 は、S3 バケット単位で有効化します。GuardDuty コンソールの「保護プラン」から「Malware Protection for S3」を選択し、スキャン対象とするバケットを指定します。AWS Organizations を使用している場合は、管理アカウントから委任管理者を設定することで、メンバーアカウントのバケットを一括管理できます。

有効化すると、GuardDuty は指定バケットに対してサービスリンクロールを付与し、S3 イベント通知を自動で設定します。利用者側で追加の手動設定をする必要はありません。

スキャン対象バケットの設定パターン

バケットの選択方式として、以下の2つのパターンがあります。

全バケット有効化:

アカウント内のすべての S3 バケットを対象にする設定です。新規バケット追加時も自動的にスキャン対象へ含まれます。ファイルのアップロードが多い環境では料金に注意が必要ですが、設定漏れのリスクをなくせます。

バケット単位の選択:

スキャンが必要なバケットだけを個別指定する設定です。外部ファイルを受け付けるバケット（アップロードポータル・CDN オリジン・データ連携先など）に絞って有効化することで、コストを最適化できます。

スキャンの仕組みとフロー

スキャンの一連の流れは以下のとおりです。

1. アップロード検知: S3 への PutObject・CompleteMultipartUpload イベントを GuardDuty が検知します。
2. スキャン実行: GuardDuty のスキャンエンジンがオブジェクトを取得し、既知のマルウェアシグネチャと機械学習モデルを組み合わせて検査します。
3. タグ付け: スキャン完了後、オブジェクトに GuardDutyMalwareScanStatus タグが自動付与されます。
4. イベント発行: 脅威が検出された場合、GuardDuty はセキュリティ検知として記録し、EventBridge へイベントを発行します。

スキャン制限事項

Malware Protection for S3 には以下のスキャン制限があります。

暗号化オブジェクトでスキャンが実行できなかった場合、GuardDutyMalwareScanStatus タグの値は ACCESS_DENIED または UNSUPPORTED となります。スキャン不可のオブジェクトは別途監視ルールで捕捉することをお勧めします。

除外設定（スキャン除外プレフィックス）

バケット全体を有効化した場合でも、特定のプレフィックス（フォルダパス相当）をスキャン対象から除外できます。例えば、信頼済みソースからのみ書き込まれるプレフィックスや、内部システムの一時ファイル格納先を除外することで、不要なスキャンコストを削減できます。

除外設定は、GuardDuty コンソールのバケット設定画面から追加できます。1 バケットあたり最大 5 プレフィックスまで除外可能です。

4-2. スキャン結果のタグとEventBridge連携

MalwareScanStatus タグの種類

スキャン完了後、オブジェクトに付与される GuardDutyMalwareScanStatus タグの値は 5 種類あります。

このタグを使用して、S3 バケットポリシーで NO_THREATS_FOUND タグのないオブジェクトへのダウンロードをブロックするアーキテクチャも実装できます。

タグを使ったアクセス制御（事前ゲート）

アップロード後のファイルをダウンロード前にスキャン完了を強制するパターンです。S3 バケットポリシーに以下の条件を追加することで、NO_THREATS_FOUND タグのないオブジェクトへのアクセスを拒否できます。

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::your-bucket/*",
  "Condition": {
 "StringNotEquals": {
"s3:ExistingObjectTag/GuardDutyMalwareScanStatus": "NO_THREATS_FOUND"
 }
  }
}

ただし、スキャン完了までの間（数秒〜数十秒）はアップロード直後のオブジェクトへのアクセスもブロックされます。非同期アップロードワークフロー（アップロード→処理→ダウンロード）にはこのパターンが有効ですが、同期的な即時ダウンロードの要件がある場合は適用に注意が必要です。

EventBridge 連携による自動対処

脅威が検出された場合（THREATS_FOUND）、GuardDuty は EventBridge へイベントを発行します。イベントソースは aws.guardduty、詳細タイプは GuardDuty Malware Protection Object Scanned です。

{
  "source": "aws.guardduty",
  "detail-type": "GuardDuty Malware Protection Object Scanned",
  "detail": {
 "scanStatus": "THREATS_FOUND",
 "s3ObjectDetails": {
"bucketName": "your-bucket",
"objectKey": "uploads/suspicious-file.exe"
 },
 "threats": []
  }
}

このイベントをトリガーに Lambda や Step Functions を起動し、以下の自動対処ワークフローを実装できます。

自動隔離パターン①：隔離バケットへの移動

最も一般的な対処パターンです。検出されたオブジェクトを隔離専用バケット（quarantine バケット）へコピーし、元のバケットから削除します。

import boto3

def lambda_handler(event, context):
 s3 = boto3.client('s3')
 detail = event['detail']
 bucket = detail['s3ObjectDetails']['bucketName']
 key = detail['s3ObjectDetails']['objectKey']
 quarantine_bucket = 'your-quarantine-bucket'

 s3.copy_object(
  Bucket=quarantine_bucket,
  CopySource={'Bucket': bucket, 'Key': key},
  Key=key
 )
 s3.delete_object(Bucket=bucket, Key=key)

隔離バケットを別の AWS アカウントに配置することで、本番環境からの完全な分離を実現できます。隔離バケットへのアクセスはセキュリティチームのみに限定し、マルウェア解析後に適切に廃棄する運用を設計してください。

自動隔離パターン②：タグによるアクセス制御

オブジェクトを移動せず、バケットポリシーによるアクセス制御のみで対処するパターンです。Lambda で Quarantined: true タグをオブジェクトに付与し、バケットポリシーでこのタグを持つオブジェクトへのアクセスを拒否します。オブジェクトを物理削除しないため、フォレンジック調査が必要な場合に有用です。

自動通知パターン：SNS または Slack 通知

セキュリティ担当者への即時通知を実装します。EventBridge ルールから SNS トピックを直接ターゲットに指定する方法と、Lambda 関数を経由して Slack の Incoming Webhook へ送信する方法があります。通知には検出されたバケット名・オブジェクトキー・脅威の種類を含め、担当者が即座に対処を開始できる情報を盛り込んでください。

Step Functions による多段自動処理

より複雑な対処ロジックが必要な場合は Step Functions を使用します。例えば、検出オブジェクトの種類判定 → 隔離 → 担当チームへの通知 → チケット登録という一連のワークフローを視覚的に定義・管理できます。Step Functions の状態管理により、Lambda のタイムアウト制限を超えるような長時間処理も安定して実行できます。

4-3. 料金と無料枠の考え方

料金体系

Malware Protection for S3 の料金は、スキャンしたオブジェクトの件数に基づく従量課金です。スキャン件数とオブジェクトサイズによって単価が異なります。正確な料金は AWS 公式料金ページを参照してください。スキャン件数はリージョンや時期によって変動するため、見積もり時は公式ページの最新値を使用することをお勧めします。

GuardDuty の既存の 30 日間無料トライアルには Malware Protection for S3 は含まれず、別途料金が発生します。ただし、GuardDuty 初回有効化後は一定期間の無料スキャン枠を利用できる場合があります。詳細は公式ドキュメントを確認してください。

コスト管理の主要施策

スキャン費用を適切に管理するための主要な施策を整理します。

スキャン対象バケットの絞り込み:

すべての S3 バケットを対象とするのではなく、外部からのファイル受付バケットや UGC（ユーザー生成コンテンツ）バケットなど、リスクの高いバケットに絞ってスキャンを有効化します。内部システムのみが書き込む信頼済みバケットは除外することでコストを削減できます。

除外プレフィックスの活用:

バケット全体を有効化している場合、ログファイル格納先・バックアップ先・内部処理の中間ファイル格納先などを除外プレフィックスとして設定します。

CloudWatch メトリクスによる監視:

GuardDuty は Malware Protection for S3 のスキャン件数を CloudWatch メトリクスとして提供しています。スキャン件数に対してアラームを設定することで、想定外のスキャン増加（大量アップロード攻撃・設定ミスなど）を早期検知できます。

S3 Storage Lens との連携:

S3 Storage Lens でバケットごとのオブジェクト件数・アップロード件数を可視化し、スキャン費用の見積もりに活用します。大量のオブジェクトが短時間にアップロードされるワークロードでは、事前に費用を試算しておくことが重要です。

運用設計のベストプラクティス

Malware Protection for S3 を本番環境で安定稼働させるための運用設計を紹介します。

KMS 権限の確認:

KMS 暗号化バケット（SSE-KMS）を使用している場合、GuardDuty サービスリンクロールへの kms:Decrypt 権限付与が必要です。権限が不足している場合、スキャン結果が ACCESS_DENIED となりセキュリティカバレッジに穴ができます。有効化後に ACCESS_DENIED の件数をモニタリングし、権限設定の漏れがないか確認してください。

タグポリシーの整備:

GuardDutyMalwareScanStatus タグをバケットのタグポリシーに追加し、許可されるタグ値を明示します。これにより、意図しないタグの上書きや削除を防止できます。

EICAR テストファイルによる動作確認:

EICAR テストファイル（標準的なマルウェアテスト用無害ファイル）をスキャン有効化バケットにアップロードすることで、THREATS_FOUND の検知・EventBridge 連携・自動隔離フローの動作確認を行えます。本番稼働前に必ずエンドツーエンドのテストを実施してください。

定期的なスキャンカバレッジの確認:

GuardDuty コンソールで、Malware Protection for S3 が有効化されているバケットの一覧と最終スキャン日時を定期確認します。新規バケット追加後にスキャンが適用されているかを確認するプロセスを運用手順に組み込むことを推奨します。

5. Runtime Monitoring

Runtime Monitoringは、コンテナやEC2インスタンス上のランタイムイベント（プロセス実行・ネットワーク接続・ファイルアクセス）をリアルタイムで監視し、脅威を検知する保護プランです。EKS・EC2・ECS Fargateの3つのワークロードに対応しており、いずれもGAとして提供されています。ランタイムシグナルはExtended Threat Detectionの相関データソースとしても活用されるため、保護プランの中でも特に重要な位置づけを持ちます。

5-1. 対応ワークロードと前提条件

EKS（Elastic Kubernetes Service）

EKSでのRuntime MonitoringはeBPF（Extended Berkeley Packet Filter）技術を用いたカーネルレベルのイベントを収集します。eBPFエージェントはKubernetesのDaemonSetとしてノードに展開され、ノード上の全コンテナのランタイム挙動を透過的に観測します。

有効化に際しては以下の前提条件を満たす必要があります。

• GuardDutyのEKS保護プランが有効になっていること
• EKSノードグループのIAMロールに必要な権限が付与されていること
• Kubernetes 1.20以降を推奨（eBPFのサポート状況はノードOSに依存）

Auto-enable Managed Agentを有効化すると、GuardDutyがDaemonSetとしてエージェントPodをEKSクラスターに自動展開します。新規作成されたEKSクラスターも自動的に保護対象に含まれ、エージェントのバージョン更新もGuardDutyが管理します。

eBPFはカーネルレベルでイベントをフックするため、コンテナプロセスがどのような方法で実行されていても観測できます。アプリケーションコードへの改修が不要で、運用上の大きなメリットとなります。

EC2（Elastic Compute Cloud）

EC2向けのRuntime MonitoringもGAとして提供されています。ただし、EC2ではEKSのようなAuto-enable Managed Agentは利用できないため、インスタンスへのエージェントデプロイは手動または自動化スクリプトを用いて行います。

代表的なデプロイ方式はAWS Systems Managerを活用する方法です。既存の運用フローにSystems Managerを組み込むことで、複数インスタンスへの一括デプロイが可能になります。新規インスタンスを自動的に保護対象に含めるには、EventBridgeとSystems Manager Automationを組み合わせた構成が有効です。

EC2での動作前提条件は以下のとおりです。

• Systems Manager AgentがEC2インスタンス上で稼働していること
• EC2インスタンスプロファイルに適切なIAMポリシーが付与されていること
• サポート対象のOS・カーネルバージョンを使用していること（Amazon Linux 2、Ubuntu 20.04/22.04、Red Hat Enterprise Linux等）

サポートOS・カーネルバージョンの最新一覧はAWS公式ドキュメントを参照してください。Windowsインスタンスは現時点で非対応です。

ECS Fargate

ECS Fargate向けのRuntime MonitoringもGAとして提供されています。Fargateタスクへのエージェント注入はGuardDutyが自動的に行います。タスク定義の変更は原則不要で、GuardDutyコンソールまたはAPIでRuntime Monitoringを有効化するだけでFargateタスクへの監視が始まります。

ECS Fargate向けの前提条件は以下のとおりです。

• Fargateプラットフォームバージョン1.4以降を使用していること
• ECSクラスターでRuntime Monitoringが有効になっていること
• 適切なIAMタスクロールが設定されていること

Fargate環境ではホストOSへの直接アクセスが不要なため、コンテナ内のプロセス・ネットワーク・ファイル操作の観測に特化した構成となっています。

なお、ECS on Managed EC2 インスタンスは Runtime Monitoring の対象外です。ECS のコンテナ挙動を監視できるのは Fargate と、EC2 起動タイプで EC2 向け Runtime Monitoring エージェントを展開したケースに限られます。Managed EC2 を利用している場合、ECS の攻撃シーケンス検知は有効化できない点に注意してください。

5-2. エージェント管理とランタイム検知

Auto-enable Managed Agentの仕組み（EKS向け）

GuardDutyコンソールの「Runtime Monitoring」設定画面で「Kubernetes agent management」を有効化すると、EKSクラスターにManaged AgentのDaemonSetが自動展開されます。

Managed Agentが担う主な役割は以下のとおりです。

• EKSノード上の全コンテナに対するランタイムイベントの収集
• eBPFを用いたカーネルイベントの透過的な観測（アプリケーションコード変更不要）
• GuardDutyへのイベントストリーミング
• エージェント自身のバージョン更新（GuardDutyが自動管理）

組織内で複数のEKSクラスターを運用している場合、GuardDutyのマルチアカウント管理（Organizations連携）と組み合わせることで、全クラスターへの一元的なRuntime Monitoring展開が可能です。

EC2へのエージェントデプロイ（Systems Manager経由）

EC2向けには自動エージェント管理機能がないため、以下の流れでデプロイを構成します。

1. GuardDutyコンソールでEC2向けRuntime Monitoringを有効化
2. AWS Systems Manager Run CommandでGuardDutyエージェントをインストール
3. 新規EC2インスタンスの自動対象化を要件に応じて構成

Systems Manager Run Commandを用いたインストールでは、GuardDutyが提供するインストールスクリプトを対象インスタンスに配布します。インスタンスタグやリソースグループを使ってデプロイ対象を柔軟に絞り込めます。

自動化の構成例として、EC2インスタンス起動イベントをEventBridgeで検知し、Systems Manager State Managerを使ってエージェントを自動インストールするパターンがあります。インストール手順の詳細はAWS公式ドキュメントを参照してください。

検知できるランタイム Findings

Runtime Monitoringが検知するFindingsは主に以下のカテゴリに分類されます。

暗号通貨マイニング系

CryptoCurrency:Runtime/BitcoinTool.B

ビットコインや暗号通貨のマイニングに関連するツールの実行が検知された場合に発生します。不正侵害後のリソース悪用の初期シグナルとして機能します。

ファイルレス攻撃・悪意ある実行

DefenseEvasion:Runtime/FilelessExecution
Execution:Runtime/MaliciousFile

ディスクへの書き込みなしにメモリ上でコードを実行するファイルレス攻撃や、既知の悪意あるファイルの実行を検知します。従来のウイルス対策ソフトでは見落としやすい攻撃手法を捉えるのに有効です。

コンテナブレイクアウト・権限昇格

PrivilegeEscalation:Runtime/CGroupsReleaseAgentFileModified

cgroupsのRelease Agentファイルを改ざんするコンテナブレイクアウト手法を検知します。コンテナから親ホストのファイルシステムへの不審なアクセスも同様に検知対象となります。コンテナのセキュリティバウンダリを超えようとする攻撃の早期発見に有効です。

C&C通信・不審なネットワーク接続

Backdoor:Runtime/C&CActivity

マルウェアやバックドアによるCommand & Control（C&C）サーバーへの通信や、通常とは異なるネットワーク接続パターンを検知します。GuardDutyが保持する脅威インテリジェンスフィードと照合することで、既知のC&Cインフラへのアクセスをリアルタイムに検知します。

これらのFindingsはいずれも単体では中〜低重要度として分類されることがあります。しかし、Extended Threat Detectionとの連携によって、多段攻撃シーケンスの相関データソースとして活用されます。

Extended Threat Detectionとの連携

Runtime MonitoringのイベントはExtended Threat Detectionにおける相関データソースとして機能します。ランタイムシグナル単体では検出できない多段階攻撃も、以下のデータソースと組み合わせることでCritical重要度の攻撃シーケンスとして検知されます。

• CloudTrail（APIコール）
• VPCフローログ（ネットワーク通信）
• DNSログ（名前解決）
• Runtime Monitoring（プロセス・ファイル・ネットワーク実行）

典型的な多段攻撃シーケンスの例として、以下の流れが挙げられます。

1. 初期侵害：CloudTrailで異常なAPIアクセス（CredentialAccess）を検知
2. ラテラルムーブメント：Runtimeシグナルで権限昇格の兆候を検知
3. 最終目的：暗号通貨マイニングや機密データへのアクセスを検知

この多段シグナルを24時間ローリングウィンドウで相関させ、Critical重要度の攻撃シーケンスFindingとして通知します。Runtime Monitoringを有効化することで、シーケンス検知の解像度が大幅に向上します。

5-3. 構成上の注意点

除外設定の活用

特定のコンテナやプロセスをRuntime Monitoringの対象外とする除外設定が利用できます。監視対象外とする典型的なユースケースとして、既知の安全なバッチ処理や負荷テストツールが頻繁に誤検知を引き起こす場合が挙げられます。

除外設定を使用する際は以下の点に注意してください。

• 除外対象は最小限の範囲に限定する（広すぎると検知の死角が増える）
• 除外設定の内容を定期的にレビューし、不要な除外を削除する
• 除外前にテスト環境での動作確認を行い、誤検知かどうかを正確に見極める
• セキュリティチームの承認なしに除外設定を変更しないよう運用ルールを整備する

料金の考え方

Runtime Monitoringの料金はエージェントの稼働時間に基づいて課金されます。EKS・EC2・ECS Fargateそれぞれで料金体系が異なるため、詳細はAWS公式料金ページを参照してください。リージョンや時期によって単価が変動する点に留意してください。

課金対象となる主な要素の概念は以下のとおりです。

• EKS：ノード数とエージェント稼働時間
• EC2：エージェントがインストールされたインスタンスの稼働時間
• ECS Fargate：タスクのvCPU数と稼働時間

コスト見積もりにはAWS Pricing Calculatorの活用を推奨します。

EKS特有の注意点

EKSでeBPFエージェントを使用する場合、以下の点に注意が必要です。

• eBPFに対応したカーネルバージョンが必要（Linux kernel 5.4以降を推奨）
• EKS最適化AMIを使用すれば対応済みのカーネルが利用可能
• EKS on AWS Graviton（Arm64アーキテクチャ）でもeBPFエージェントはサポートされています

DaemonSetとしてエージェントが稼働するため、ノードリソース（CPU・メモリ）を一定量消費します。リソース制約の厳しいノードでは、GuardDutyエージェントPodのリソースリクエスト・リミットを確認した上で展開してください。

EC2でのSystems Manager依存

EC2向けRuntime MonitoringはSystems Manager Agentの動作を前提としています。Systems Manager AgentがEC2インスタンス上で停止していたり、インスタンスプロファイルの権限が不足したりすると、GuardDutyエージェントのデプロイや更新が失敗します。

EC2インスタンスのSystems Manager接続状態は、定期的にSystems Managerのフリートマネージャーで確認することを推奨します。接続不可のインスタンスはRuntime Monitoringの保護対象外となるため、定期的な状態確認が運用上重要です。

ECS Fargateの制限事項

ECS FargateでのRuntime MonitoringはFargateプラットフォームバージョン1.4以降が必要です。古いプラットフォームバージョンを使用しているタスクはRuntime Monitoringの対象外となります。既存のFargateタスクをRuntime Monitoring対象に含めるには、タスク定義の更新やサービスの再デプロイが必要になる場合があります。

デプロイ計画を立てる際は、稼働中のFargateタスクのプラットフォームバージョンを事前に確認し、必要に応じてバージョンアップのスケジュールを含めた計画を立てることを推奨します。

6. 新検知タイプと運用・コスト管理

6-1. 攻撃シーケンスの検知タイプ

Extended Threat Detectionが生成する攻撃シーケンスfindingは、関係するAWSサービスによってタイプ名が異なります。各タイプの名称と検知対象を把握しておくと、アラート対応フローを設計する際に役立ちます。

EKSを起点とした攻撃シーケンス

EKS環境を対象とした攻撃シーケンスは、EKS保護プランが有効化されている状態でRuntime MonitoringやCloudTrailのシグナルと組み合わせて検知されます。

AttackSequence:Kubernetes/CompromisedAccount
AttackSequence:Kubernetes/CredentialAccess

CompromisedAccountはEKSクラスターに関連するアカウントが侵害されたと判断される一連のシグナルを相関させた結果として生成されます。具体的には、不審なAPIコール・権限昇格の試み・異常なコンテナ起動といったシグナルが24時間ウィンドウ内で複数検知された際に発生します。CredentialAccessはEKS環境でのシークレットや認証情報への不正アクセスを示すシーケンスです。

S3を起点とした攻撃シーケンス

S3保護プランが有効化された環境では、S3関連のAPIコールと他のシグナルを組み合わせた攻撃シーケンスが検知されます。

AttackSequence:S3/CompromisedAccount
AttackSequence:S3/CredentialHijack

CompromisedAccountは複数のS3操作（バケットポリシーの変更・大量ダウンロード・パブリック公開設定の変更など）と他のシグナルを相関させた結果です。CredentialHijackはS3アクセス権限の不正取得を示すシーケンスで、IAMポリシーの変更やアクセスキーの誤用を含む複合的なシグナルから検知されます。

EC2・IAMを起点とした攻撃シーケンス

EC2インスタンスやIAMエンティティに関連する攻撃シーケンスは、GuardDutyのコアデータソース（CloudTrail・VPCフローログ・DNSログ）から生成されます。

AttackSequence:EC2/CompromisedAccount

EC2インスタンスからの不審なネットワーク接続・インスタンスメタデータへの過剰アクセス・IAMロールの横断的利用といったシグナルが組み合わさった際に生成されます。Runtime MonitoringとExtended Threat Detectionが連携した環境では、EC2上のランタイムシグナルも相関対象に加わり、検知精度が向上します。

attack_sequenceの共通属性

すべての攻撃シーケンスfindingは以下の共通属性を持ちます。

6-2. 検知結果の優先度づけと運用

Critical重要度を最優先キューとして扱う設計

attack_sequence findingのCritical重要度は、通常のHigh（7.0以上）よりも高い優先度で扱います。SOC運用フローでは、以下のような優先度設計が推奨されます。

1. Critical（attack_sequence）：即時対応。担当者へのSMS・電話アラートを含む最優先エスカレーション
2. High（7.0〜）：4時間以内に初動調査を開始
3. Medium（4.0〜6.9）：24時間以内に調査
4. Low（1.0〜3.9）：週次レビューで一括対応

EventBridgeルールでSeverity別にフィルタリングし、Criticalのみを最優先キューへ送信する構成が効果的です。

日々の運用フロー

GuardDuty新機能の運用に際して、以下の日次・週次フローを基本として設計します。

日次確認事項

• attack_sequence findingの有無を確認（0件が正常、1件でも即時調査）
• Runtime MonitoringのFindingでCryptoCurrency系・PrivilegeEscalation系が新規発生していないか
• Malware Protection for S3でスキャン結果タグGuardDutyMalwareScanStatus: THREATS_FOUNDを持つオブジェクトがないか

週次確認事項

• 抑制ルールの内容をレビューし、過剰な抑制がないか確認
• 保護プランの有効化状況（新規アカウント・新規リージョンが対象外になっていないか）
• Runtime Monitoringエージェントの接続状態（EC2のSystems Manager接続確認）

アラート疲労対策

GuardDuty新機能を追加した場合、検知されるfindingの量は増加することがあります。アラート疲労を防ぐために、以下の対策を組み合わせて設計します。

重要度フィルタリング

EventBridgeルールでSeverity >= 7.0のfindingのみをSlack・PagerDuty・SNSへ通知する設定にします。Low・Medium findingはSecurity Hubに集約してダッシュボードで確認する運用に留め、都度のアラートは発生させません。

抑制ルールの適切な活用

繰り返し発生する既知の正常なfindingには抑制ルールを設定します。ただし、抑制ルールはattack_sequence findingへの適用は最小化することを推奨します。attack_sequenceは多段階攻撃全体を示す高精度の検知結果であるため、抑制による見落としのリスクが高くなります。

抑制ルールを適用する場合は、以下の条件を明確に定義してから設定します。

• 対象のFindingType（具体的なタイプ名で指定）
• 対象のリソース（IPアドレス・インスタンスID・バケット名など）
• 抑制の有効期限（定期レビューの契機）

Malware for S3のSCANNED_NO_THREATS_FOUND処理

Malware Protection for S3のスキャンでは、スキャン完了ごとにEventBridgeイベントが発生します。スキャン量が多い環境ではSCANNED_NO_THREATS_FOUNDイベントの量が多くなるため、EventBridgeルールでTHREATS_FOUNDのみを抽出してアラートを送信する設計が推奨されます。

6-3. 抑制ルールとattack_sequenceの関係

GuardDutyの抑制ルール（Suppression Rule）は、特定の条件を満たすfindingの現在の結果を自動的にSUPPRESSEDに変更する機能です。通常のfindingには有効な仕組みですが、attack_sequence findingに対する適用には慎重な設計が必要です。

抑制ルールが機能する仕組み

GuardDutyコンソールまたはAPIで設定した抑制ルールは、条件に合致する新規findingをSUPPRESSED状態にします。FindingType・ResourceType・IPアドレス・タグなどの条件を組み合わせて設定できます。

抑制ルールはfindingを削除しないため、SUPPRESSED状態のfindingは後から確認できます。ただし、デフォルトのビューでは非表示になるため、定期的にSUPPRESSEDフィルタを外してレビューする運用が重要です。

attack_sequenceへの適用時の注意点

attack_sequence findingは複数のシグナルを相関させた高精度の結果です。誤検知率が通常のfindingより低い傾向があるため、抑制ルールによってCritical findingが見えなくなることのリスクは高くなります。

attack_sequence findingを抑制する前に、以下を必ず確認してください。

• そのfindingが実際に誤検知であることを調査結果として記録する
• 抑制ルールの条件が広すぎないか（特定のインスタンスIDではなくIPアドレス範囲で指定するなど）
• セキュリティチームのレビューと承認を得る

正当な抑制ルールの用途

以下のようなケースでは、attack_sequence以外のfindingに対して抑制ルールが有効に機能します。

• ペネトレーションテストや負荷テストの期間中に発生する既知のfinding
• セキュリティスキャンツールの定期実行による既知のfinding
• 開発環境の特定インスタンスで繰り返し発生する誤検知

これらのケースでは、テスト終了後または開発環境の廃止後に抑制ルールを削除する運用ルールを事前に定めておくことを推奨します。

6-4. 自動対応フロー（EventBridge→Lambda/Step Functions）

GuardDuty新機能が生成するfindingを、EventBridgeを起点として自動対応につなげる実装パターンを解説します。

EventBridgeルールの設計

GuardDutyのfindingはすべてEventBridgeに自動的に送信されます。attack_sequence findingを最優先で処理するルールを以下の形式で設定します。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
 "severity": [{"numeric": [">=", 8.0]}],
 "type": [{"prefix": "AttackSequence:"}]
  }
}

このルールでSeverity 8.0以上かつAttackSequenceプレフィックスを持つfindingのみを対象とし、最優先のターゲット（Lambda・SNS・Step Functions）へ送信します。

Lambda関数による自動初動対応

attack_sequence findingを受信したLambda関数では、以下の初動対応を自動化することが有効です。

1. 影響を受けたリソースの特定：findingのdetailからアカウントID・リソースID・リージョンを抽出
2. コンテキスト情報の収集：Amazon Detectiveへの調査開始APIを呼び出し（Detective統合が有効な場合）
3. 担当者への緊急通知：SNS経由でSMS・メール・PagerDutyへ送信
4. Slackへのインシデントチケット作成：Severity・FindingType・影響リソースを含む形式で投稿

Lambda関数のコード例（通知送信部分）は以下の形式です。コードブロック内にサンプルを示します。

import boto3
import json

def handler(event, context):
 finding = event['detail']
 severity = finding['severity']
 finding_type = finding['type']
 resource_id = finding.get('resource', {}).get('instanceDetails', {}).get('instanceId', 'unknown')

 sns = boto3.client('sns')
 message = {
  'severity': severity,
  'finding_type': finding_type,
  'resource_id': resource_id,
  'account_id': finding['accountId'],
  'region': finding['region']
 }
 sns.publish(
  TopicArn='arn:aws:sns:ap-northeast-1:123456789012:security-critical',
  Subject=f'[CRITICAL] GuardDuty Attack Sequence Detected: {finding_type}',
  Message=json.dumps(message, ensure_ascii=False, indent=2)
 )
 return {'statusCode': 200}

Security Hub自動修復パターン

GuardDutyのfindingはSecurity Hubへ自動集約されます。Security Hub上でCustom Actionを設定することで、コンソール上の操作から自動修復フローを起動できます。

典型的な連携パターンは以下の通りです。

1. Security Hub上でGuardDuty findingを確認
2. SOCアナリストが「隔離」Custom Actionをクリック
3. Custom ActionのEventBridgeイベントをトリガーにLambdaが起動
4. LambdaがEC2セキュリティグループの変更・IAMアクセスキーの無効化などを実行

この連携により、アナリストの判断を介した半自動的な対応フローを構築できます。完全自動化と人間の確認を組み合わせた設計が、誤検知による影響を最小化しながら対応速度を向上させます。

6-5. GuardDuty新機能のコスト構造とコスト最適化

新機能別コスト構造

GuardDuty新機能の追加時に発生するコストの考え方を整理します。

Extended Threat Detection

ETD自体は追加コストなしで利用できます。ただし、ETDの相関精度を高めるために保護プランを追加有効化した場合、それらの保護プランのデータソース料金が発生します。ETDはその範囲のデータを活用して動作するため、「ETD有効化コスト」として分けて考えるのではなく、「保護プランのデータソース料金の一部」として捉えることが正確です。

Malware Protection for S3

スキャンされたオブジェクト件数に応じた従量課金となります。無料枠は初回有効化から一定期間設けられており、その後は件数に応じた料金が発生します。最新の料金体系については公式料金ページを参照してください。

スキャン対象バケットを絞り込むことで、コストを抑制できます。機密データを含まない一時的なバケットやログバケットはスキャン対象から除外する設定が有効です。

Runtime Monitoring

エージェントの稼働時間に基づく従量課金となります。EKS・EC2・ECS Fargateで料金体系が異なります。最新の単価はリージョンによって変動するため、AWS公式料金ページで確認してください。

コスト最適化の設計ポイント

不要な保護プランを無効化する

保護プランは必要なワークロードに絞って有効化します。全リージョン・全アカウントでデフォルト有効にすると、未使用のリソースに対しても料金が発生します。AWS Organizationsを使ったマルチアカウント環境では、組織レベルでのデフォルト有効化設定と個別アカウントの除外設定を組み合わせることで、適切なスコープ管理が可能です。

Malware for S3のスキャン除外バケット設定

以下のようなバケットはスキャン対象から除外することでコストを削減できます。

• CloudFrontアクセスログ・CloudTrailログが格納されるバケット（AWSが生成するログ）
• 機密データを含まないテンポラリバケット
• CIパイプラインの成果物バケット（既知のソースからのみ書き込まれる）

除外設定はGuardDutyコンソールの「Malware Protection for S3」設定から個別バケットを指定します。

Runtime Monitoringのデプロイ範囲の最適化

Runtime Monitoringを全EC2インスタンスに展開するのではなく、インターネットからのリクエストを受けるフロントエンド層や、機密データを処理するバックエンド層など、リスクの高いワークロードに絞って展開することでコストを抑制できます。開発・テスト環境では無効化し、本番環境のみに有効化する方針も有効です。

7. 実戦統合パターン

7-1. EventBridgeを起点とした自動対応

§6-4ではEventBridgeルールの設定例とLambda関数のコード例を解説しました。本項では「既存のSOC基盤にGuardDuty新機能を追加するときの設計方針」という観点で整理します。個別の実装パターン（コード・EventBridgeルール）は§6を参照してください。

既存SOC基盤への新機能統合の設計方針

既存のSOC（Security Operations Center）基盤がSecurity Hub経由でfindingを集約し、EventBridgeからSlackやPagerDutyに通知するアーキテクチャを採用している場合、GuardDuty新機能のfindingは自動的に同じパイプラインに乗ります。ただし、Attack Sequence findingsはCritical重要度で発行されるため、既存の通知ルールで重要度フィルタを設定していた場合は、Criticalが確実に通知対象に含まれているかを確認します。

新機能追加時の段階的な設計方針として以下の順序を推奨します。

第1ステップでは、既存の通知・エスカレーションフローを棚卸しします。現在GuardDutyのfindingがどのEventBridgeルール→Lambda→通知先の経路で処理されているかを文書化し、新機能findingが同じ経路に乗るかを確認します。

第2ステップでは、Attack Sequence findings専用のエスカレーションルールを追加します。Criticalは即時エスカレーション対象であり、既存のHigh重要度findingよりも優先して対応します。EventBridgeのルールパターンにdetail.typeのプレフィックスフィルタとしてAttackSequence:を追加し、Criticalのみを即時エスカレーション用Lambdaに転送します（§6-4のルール例を参照）。

第3ステップでは、保護プランを段階的に有効化し、各ステップで新しいfindingタイプの発生状況をモニタリングします。新機能有効化直後は誤検知（false positive）の増加が想定されるため、1〜2週間の試運転期間を設けて抑制ルールを調整します。

段階的導入ロードマップ

既存のSOC運用に3つの新機能を追加する場合、以下の段階的ロードマップが運用上の混乱を最小化しながら効果を最大化します。

Phase 1（1〜2週間）ではExtended Threat Detectionの確認と保護プランを整備します。ETDはGuardDutyを有効化している環境で自動的に有効になっており、追加の設定は原則として不要です。まず現在のGuardDutyコンソールでAttack Sequence findingが発生しているかを確認します。発生していた場合は既に新機能が機能しており、対応フローが整備されているかを評価します。この段階では保護プランの有効化状況も確認し、S3保護を優先的に有効化することでETDの相関精度を即座に向上させます。

Phase 2（2〜4週間）ではMalware Protection for S3を導入します。ユーザーからのファイルアップロードを受信するS3バケットを特定し、対象バケットでMalware Protection for S3を有効化します。試運転期間中は誤検知のパターンを観察し、必要に応じて特定のファイルタイプや送信元を除外する抑制設定を追加します。スキャン結果findingの通知が既存のEventBridgeフローに正しく組み込まれているかを確認して完了です。

Phase 3（4〜8週間）ではRuntime Monitoringを段階的に導入します。EKS Add-onとしてGuardDutyセキュリティエージェントを自動デプロイできるEKSが最も容易です。EC2はSystems Manager（SSM）経由のデプロイが必要であり、Auto Scaling起動テンプレートにSSMエージェントのインストールステップを追加することで新規インスタンスに自動デプロイできます。ECS FargateはプラットフォームバージョンをLATESTに設定してGuardDuty Runtime Monitoring統合を有効化するだけで動作します。

Attack Sequence findingsの優先対応フロー

Attack Sequence findingsはETDが複数のシグナルを相関させた結果として発行されるCritical findingであり、単発のHigh findingよりも侵害の可能性が高い状態を示します。そのため対応フローは既存のHigh finding対応とは別に設計することを推奨します。

推奨する対応フローは以下のとおりです。受信フェーズではAttack Sequence findingを受信したEventBridgeルールが即時対応Lambdaをトリガーします。初動対応フェーズでは影響を受けたIAMユーザー・ロールのアクセスキーを一時無効化し、侵害が疑われるEC2インスタンスを隔離するセキュリティグループを変更し、SOCチームへの緊急通知を送信します。エスカレーションフェーズでは即時対応後にSOCアナリストがAmazon Detectiveで攻撃シーケンスの詳細を調査し、被害範囲を確定します。

7-2. Security Hubとの集約連携

Security Hub集約でのAttack Sequence findings扱い

GuardDutyとSecurity Hubの統合を有効化している環境では、Extended Threat Detection・Malware Protection for S3・Runtime Monitoringの各findingが自動的にSecurity Hubに集約されます。Security HubはGuardDutyのfindingをAWS Security Finding Format（ASFF）に変換して取り込み、既存の他サービス（Inspector・Macie等）のfindingと統合して管理できます。

Attack Sequence findingsはCritical重要度でSecurity Hubに取り込まれ、Security Hubのコンソールでは「重要度: 重大」として表示されます。Security Hubの集約ビューでは、同一リソース（IAMユーザー・EC2インスタンス等）に対して発生した複数のfindingをグループ化して表示できるため、攻撃シーケンスに関連する個別findingとAttack Sequence findingを並べて確認できます。

Security Hubの自動対応（Security Hub Automations）を利用すると、findingの特定条件に応じてアクションを自動実行できます。Attack Sequence findingのWorkflow StatusをNEWからNOTIFIEDに自動更新し、SOCチームへの割り当てを自動化する設定が可能です。

Amazon Detective連携による脅威調査の深化

Amazon Detectiveはguarddutyのfindingを起点として、関連するリソース・ネットワーク・APIアクティビティを時系列で可視化するサービスです。ETDが生成したAttack Sequence findingのような複雑な脅威の調査において、Detectiveは特に強力なツールになります。

GuardDutyコンソールからAttack Sequence findingを開き「Detectiveで調査」をクリックすると、Detective調査セッションが起動します。調査セッションではfinding発生前後の24時間を中心に、関連するAWSエンティティ（IAMユーザー・EC2インスタンス・IPアドレス・S3バケット）の活動グラフが自動生成されます。

脅威ハンティングへの活用では、Attack Sequence findingが示す攻撃期間をDetective上で時系列に展開し、個々のシグナル（finding）が発生したタイミングと関連エンティティの変化を確認します。たとえば「CloudTrailでの異常なAPIコール（シグナル1）→S3バケット設定変更（シグナル2）→EC2インスタンスからの外部接続（シグナル3）」という攻撃シーケンスの各シグナル間に、他にどのような操作が発生していたかをDetectiveで掘り下げられます。

Detectiveのサマリページでは、調査対象エンティティの「ベースラインからの逸脱度」がグラフで表示されます。たとえば特定のIAMロールが通常は1日あたり10件のAPIコールを発行しているのに対し、攻撃日には1,000件発行していた場合、統計的な逸脱として視覚化されます。このベースライン比較は、GuardDutyのfindingだけでは判断が難しい「攻撃者の行動範囲」の把握に役立ちます。

積極的な脅威ハンティングでは、週次または月次でDetectiveを使ったハンティングを実施することを推奨します。GuardDutyのfindingが発生していなくても、DetectiveのSearch機能で過去30日間に新規接続元IPアドレスからアクセスしたIAMエンティティを列挙し、通常のビジネス拠点以外のIPアドレスからのアクセスが確認された場合はそのエンティティの活動グラフを展開してAPIコールのパターンを検証します。

マルチアカウント環境でのSecurity Hub集約設計

マルチアカウント環境では、Security HubのOrganizations統合を利用してメンバーアカウントのfindingを管理アカウントに集約します。GuardDutyのDelegated Administratorアカウントと、Security HubのAdministratorアカウントを同一アカウントに設定することで、管理の複雑さを軽減できます。集約されたfindingに対して、管理アカウントから一元的に自動対応ルールを設定できます。

Detectiveもマルチアカウント対応しており、Behavior Graphに複数のメンバーアカウントを登録することで、クロスアカウント攻撃シーケンス（あるアカウントで侵害した認証情報を別アカウントで悪用するパターン）を調査できます。GuardDutyの管理アカウントとDetectiveのBehavior Graph管理アカウントを統一することで、組織全体の脅威ランドスケープを1つのコンソールから調査できます。

7-3. インシデント対応への接続

インシデント管理プラットフォームとの連携設計

GuardDutyのfindingからインシデントチケットの自動生成までを連結することで、SOCアナリストの調査開始時間を短縮できます。典型的な連携パターンは以下のとおりです。

Attack Sequence findingがEventBridgeで受信されると、Lambdaがfindingの詳細（FindingType・重要度・影響リソース・AWSアカウントID・リージョン）を抽出してJiraまたはServiceNowのAPIを呼び出し、インシデントチケットを自動生成します。チケットにはDetective調査セッションへの直接リンクを含めることで、アナリストがチケットを開いた直後に調査を開始できます。

Detective調査URLの自動生成は、GuardDuty findingのidフィールドを利用してDetectiveのAPI（StartInvestigation）を呼び出す形で実装できます。LambdaからDetectiveの調査セッションを開始し、そのURLをインシデントチケットに自動付与する処理をEventBridgeパイプラインに組み込みます。

Runbookとの接続と対応記録

Attack Sequence findingへの対応手順は、SOCチームのRunbook（手順書）として事前に定義しておくことが重要です。Attack Sequence findingのFindingTypeごとの対応手順を整備し、インシデントチケットのテンプレートにRunbookへのリンクを含めます。これにより、初動対応者は手順で迷わず即座に対処を開始できます。

対応完了後はfindingをSecurity Hub上でアーカイブし、対応したDetective調査セッションのURLをインシデントチケットに記録して保管します。これらの記録は事後分析・再発防止策の策定・定期的なセキュリティレビューで活用します。

SOC運用の成熟度モデル

GuardDuty新機能の導入状況を3段階の成熟度で評価し、次のステップを明確にします。

Level 1（検知）の状態は、GuardDutyが有効化されS3保護・EKS保護を有効化した状態です。ETDが動作しており、Attack Sequence findingが発行されます。SOCチームは手動でfindingを確認・対応しています。

Level 2（自動化）の状態は、EventBridgeとLambdaによる自動初動対応（IAMキー無効化・インスタンス隔離）が実装済みの状態です。Malware Protection for S3の隔離自動化も完了し、Security Hubへの集約とSlack・PagerDuty通知が整備されています。

Level 3（統合）の状態は、Detective調査セッションが自動生成され、Attack Sequence finding発生時にSOCアナリストへ自動割り当てされる状態です。脅威ハンティングが週次または月次で実施され、Detectiveのベースライン情報を運用に活用しています。インシデント管理プラットフォームとの連携が完成し、findingからチケット作成・対応完了・事後レポートまでの流れが自動化されています。

Level 2からLevel 3への移行では、インシデント管理プラットフォーム（Jira・ServiceNow等）とGuardDuty・Detective・Security Hubの連携APIの実装が主要なステップです。このLevelに到達すると、SOCアナリストの調査開始時間が大幅に短縮され、MTTRの改善が数値として現れ始めます。

定期的な見直しサイクル

GuardDutyの設定は一度構築して終わりではなく、環境変化に合わせた定期的な見直しが重要です。月次では保護プランのカバレッジ確認・新しいAttack Sequence findingタイプの確認・阻止できなかった攻撃の事後分析を実施します。四半期では抑制ルールの棚卸し・Runtime Monitoringエージェントの接続状態確認・自動対応のホワイトリストを更新します。GuardDutyは継続的に新機能が追加されているサービスです。AWSのリリースノートや公式ブログを定期的に確認し、新しいAttack Sequence findingタイプや保護プランが追加された際には速やかに評価・導入を検討してください。

導入効果を定量評価するKPI設計

GuardDuty新機能の導入効果を組織内で可視化するため、定量的なKPIを設定することを推奨します。KPIは導入前のベースライン値を記録し、導入後の改善幅を追跡する形で設計します。

MTTD（Mean Time to Detect）は攻撃開始からGuardDutyがAttack Sequence findingを発行するまでの時間です。ETDの24時間ウィンドウという特性上、攻撃シーケンスの最初のシグナル発生タイムスタンプとAttack Sequence finding発行タイムスタンプの差分で算出します。試運転期間中に発生した実際のAttack Sequence findingでベースラインを計測し、保護プランの追加による改善幅を追跡します。

MTTR（Mean Time to Respond）はfinding発行からインシデント対応完了までの時間です。EventBridge→Lambda→インシデントチケット自動生成のパイプラインを導入することでMTTRを短縮できます。SOC成熟度Level 2達成後にMTTRを計測し、Level 3（Detective自動連携）導入による改善幅を定量評価します。自動化前後のMTTR比較は、経営層への投資対効果説明においても有効なデータになります。

誤検知率はAttack Sequence findingのうち実際の攻撃でなかった割合です。試運転期間中は誤検知と正検知を区別してSecurity Hub上でWorkflow Statusを記録します。抑制ルールの調整効果を数値で追跡し、3ヶ月ごとに誤検知率の改善状況をレビューします。誤検知率が高止まりする場合は、特定のユーザー・リソース・IPアドレスパターンを抑制対象として追加することを検討します。

Organizationsでの統合対応フローの設計

マルチアカウント組織では、クロスアカウントAttack Sequenceへの対応フローを事前に設計しておくことが重要です。GuardDutyのDelegated Administratorアカウントが複数のメンバーアカウントにまたがる攻撃シーケンスを一元的に検知し、各メンバーアカウントの担当者に自動的にインシデントチケットを割り当てる設計が効果的です。

Lambdaでfindingに含まれるAWSアカウントIDを判定し、アカウントIDと対応チームのマッピングテーブル（DynamoDBまたはSystems Manager Parameter Store）を参照してチケット割り当て先を決定します。マルチアカウント環境固有の実装として、Delegated Administratorアカウントから各メンバーアカウントのリソースを操作する場合はsts:AssumeRoleでクロスアカウントロールを引き受ける必要があります。Lambda実行ロールにOrganizationsの各メンバーアカウントへのAssumeRole権限を付与し、インシデント初動対応（IAMキー無効化・SG変更等）を管理アカウントから実行できる体制を構築します。

緊急隔離のためのSCP（Service Control Policy）自動適用も、マルチアカウント環境固有の対応フローです。Attack Sequence findingが発生したメンバーアカウントに対して、一時的に制限的なSCPを適用することで、攻撃者のさらなる悪用を防止できます。SCPの自動適用は影響範囲が大きいため、Criticalのうち特定のFindingTypeに限定する条件設定と、管理者承認のステップを含む設計が安全です。

GuardDuty新機能の継続的改善サイクル

GuardDuty新機能の運用は「有効化→モニタリング→調整→再評価」の継続的改善サイクルで成熟度を高めます。このサイクルは前述のSOC成熟度モデルのLevel間移行を推進するエンジンです。

有効化フェーズでは保護プランを§3-3のStep順に段階的に追加し、各段階でfindingタイプと件数の変化を記録します。モニタリングフェーズでは週次でAttack Sequence findingsの件数・重要度分布・影響リソース種別を集計し、脅威のトレンドを把握します。調整フェーズでは誤検知の多いfindingタイプに抑制ルールを追加し、対応フローの自動化範囲を拡大します。再評価フェーズでは四半期ごとにAWSのリリースノートを確認し、新しいfindingタイプや保護プランの機能強化を取り込みます。

このサイクルを維持することで、GuardDutyの検知精度と運用効率を継続的に向上させ、クラウドセキュリティ体制全体の成熟度を高めていきます。既存のSOC基盤に新機能を段階的に統合するアプローチにより、運用の混乱を最小化しながら検知能力を拡充できます。

SIEMおよびゼロトラストとの統合設計

GuardDuty新機能からのfindingをSIEMに統合する際は、Security HubのASFF形式が標準的なアプローチです。EventBridge→Kinesis Firehose→S3→SIEMという転送パイプラインを構築し、Attack Sequence findingsをCritical重要度のアラートとしてSIEMのダッシュボードに表示します。既存のSIEMにGuardDutyのパーサーが組み込まれている場合（Splunk・IBM QRadar・Microsoft Sentinelなど）はベンダー提供のコネクタを活用し、findingのASFFスキーマを構造化データとして取り込むことで検索・相関ルール作成が容易になります。

新しいfindingタイプが追加されるたびにSIEM側のパーサーやダッシュボードの更新が必要になります。GuardDutyのリリースノートを四半期ごとに確認し、新findingタイプのASFFフィールドマッピングとアラートルールを事前に準備しておくことで、新機能有効化直後から正確なアラートが発報される体制を維持できます。

Zero Trust Architectureを採用している組織では、GuardDutyの保護プランが提供するデータプレーン可視性はゼロトラストの継続評価に活用できます。S3データプレーンイベント・Kubernetes APIアクセスログ・プロセス実行記録はいずれも「誰が・何を・どのリソースに・いつ行ったか」というゼロトラストポリシー評価に必要なコンテキスト情報です。Attack Sequence findingをゼロトラストポリシーエンジンへフィードバックし、該当ユーザーのリスクスコアを動的に引き上げてアクセス制限を強化する統合パターンは、GuardDutyとIdP（ID Provider）を連携させた高度なゼロトラスト実装として検討できます。

GuardDutyのfindingはAWS Well-Architected FrameworkのSecurity Pillarにおける「検知」ドメインの中核ツールとして位置付けられています。Well-Architected Reviewを実施する際は、GuardDutyの有効化状況・保護プランのカバレッジ・findingへの対応状況をエビデンスとして提出することで、セキュリティリスク管理の成熟度を定量的に示せます。

テナントモデル別の統合設計考慮点

SaaSプロバイダーやマネージドサービスプロバイダー（MSP）がマルチテナント環境でGuardDutyを運用する場合、テナントごとのAWSアカウントをOrganizationsのメンバーとして管理することが前提になります。Delegated Administratorアカウントが全テナントのAttack Sequence findingを集約しますが、テナント間のfinding情報を隔離してそれぞれのテナント管理者にのみ開示する設計が必要です。

EventBridgeのfindingをLambdaで受信した後、findingに含まれるAWSアカウントIDを元にテナントIDを解決し、テナント専用のSNSトピックまたはEventBusにルーティングする設計が一般的です。テナントごとにSecurity HubのクロスリージョンアグリゲーターとDetectiveのBehavior Graphを設定することで、テナント単位の調査環境を提供できます。

コンプライアンス報告においては、PCI DSS・SOC 2・ISO 27001等の監査でGuardDutyのfinding対応履歴が証跡として求められることがあります。Security Hub上でfindingのWorkflow Statusを適切に管理し、対応完了・誤検知・抑制の各ステータスを記録することで、監査対応に必要なエビデンスを自動的に蓄積できます。findingの対応履歴はSecurity Hub→Firehose→S3へ長期保存し、コンプライアンス要件に定められた保存期間（多くの場合1年以上）を満たすアーカイブ設計を採用します。

本節で解説した統合パターン（EventBridge自動対応・Security Hub集約・Detective連携・インシデント管理連携）は独立して導入可能ですが、SOC成熟度モデルのLevelに沿って段階的に実装することで導入リスクを最小化できます。Level 1（検知体制の確立）から着手し、各Levelで得られた運用知見を次のLevelの設計にフィードバックするアプローチが、GuardDuty新機能を既存SOC基盤へ安全に統合するための実践的な方法論です。

§3で解説した保護プランの選定・有効化・検証ステップと、本節の統合パターンを組み合わせることで、GuardDuty拡張脅威検知の全体像が完成します。データソースの拡張（§3）→自動検知基盤の整備（§6）→SOC統合と成熟度向上（§7）という流れで段階的に実装を進めることを推奨します。GuardDutyの継続的な機能拡充と組み合わせることで、クラウドセキュリティの検知・対応能力を長期にわたって向上させ続けることができます。

セキュリティ運用の成熟度は一朝一夕には高まりません。まずLevel 1の検知体制を確立し、実際のfindingに対応する経験を通じてSOCチームの運用スキルを向上させながら、段階的に自動化と統合を進めることが持続可能な改善の鍵となります。

GuardDuty拡張脅威検知の導入はゴールではなく起点です。新機能有効化後に得られるfindingデータや対応履歴を継続的に分析し、自組織の脅威ランドスケープに合わせた検知精度の向上と対応フローの最適化を繰り返すことで、クラウドセキュリティ体制の真の成熟度が実現します。

AWSはGuardDutyに定期的に新しい検知タイプと保護プランを追加しています。本節で解説した統合パターンを基盤として構築しておくことで、新機能が追加された際に既存の自動対応パイプラインへの組み込みが容易になります。

8. 詰まりポイント・アンチパターン・まとめ

8-1. よくある詰まりポイントと解決策

本番環境でExtended Threat DetectionやMalware Protection for S3、Runtime Monitoringを運用する際に頻出する詰まりポイントを整理します。

詰まり1: Extended Threat Detectionが有効なのにAttack Sequence findingが出ない

ETDが有効化されていても、Attack Sequence findingが一切出ないというケースがあります。最も多い原因は、検知に必要な保護プランが有効化されていないことです。

たとえばAttackSequence:EKS/CompromisedClusterを検知するには、EKS保護とRuntime Monitoringの両方が有効化されている必要があります。S3関連の攻撃シーケンスを検知するにはS3保護が必須です。

また、データソースがそもそも十分なイベントを生成していない場合も考えられます。VPC Flow LogsがVPCレベルで有効化されていない・EKSコントロールプレーンログの出力が設定されていないといった前提条件の不備がないか確認します。

確認手順として、GuardDutyコンソールの「Protection plans」セクションで各保護プランのステータスを確認し、未有効のものがあれば順次有効化します。

詰まり2: 既存の抑制ルールが攻撃シーケンス検知を妨げる

GuardDutyでは、誤検知を減らす目的でsuppression rule（抑制ルール）を設定している環境が多く見られます。しかし、suppressedまたはarchivedになったfindingはETDのシグナルとして利用されないため、攻撃の痕跡はシグナルから脱落し、ETDの相関分析は機能しなくなる可能性があります。

特に問題になるのは、「あるAPIを呼び出すと必ずLowのfindingが出るので全て抑制する」という包括的な抑制ルールです。このルールが設定されているとその操作を含む攻撃シーケンスが組み立てられなくなります。

対策として、ETD導入前に既存の抑制ルールを棚卸しし、本当に必要なものだけに絞ることを推奨します。特に重要度LowやMediumのfindingに対する広範な抑制ルールは見直しの優先対象です。

詰まり3: Malware Protection for S3でスキャンが実行されない

Malware Protection for S3を有効化したにもかかわらず、S3バケットにファイルをアップロードしてもスキャンが実行されないというケースがあります。

最も多い原因は以下の2点です。

• 対象バケットの設定漏れ: Malware Protection for S3はデフォルトで全バケットを対象にするわけではなく、保護対象バケットを明示的に指定する必要があります。設定画面で対象バケットが正しく登録されているか確認します。

• スキャン除外設定の誤り: オブジェクトキーのプレフィックスやタグによる除外設定が広すぎて、スキャンしたいオブジェクトも除外されているケースがあります。除外設定を最小限に絞ることで解決します。

スキャンが実行された場合、オブジェクトにGuardDutyMalwareScanStatusタグが付与されます。タグが付いていない場合はスキャン自体が走っていないため、上記の設定を確認します。

詰まり4: Runtime Monitoringエージェントのデプロイが失敗する

Runtime Monitoringを有効化してGuardDutyセキュリティエージェントを展開しようとした際、デプロイが失敗するケースもあります。

• EC2のManaged Agentが非対応のOS: EC2向けManaged Agentは特定のLinuxディストリビューションとカーネルバージョンのみをサポートしています。Amazon Linux 2・Ubuntu・CentOSの古いバージョンや、カスタムカーネルを使っているインスタンスでは自動デプロイに失敗することがあります。

• ECS Fargate向けのサイドカー未設定: ECS Fargateではエージェントをサイドカーコンテナとして展開する必要があります。タスク定義を適切に更新しないとエージェントが動作しません。

対処としては、まず対応OS・カーネルバージョンのリストをAWSドキュメントで確認し、未対応の場合は手動エージェントのインストールを検討します。Managed Agent非対応環境では、インストールスクリプトを使った手動展開が必要です。

詰まり5: Runtime Monitoringの料金が予想より高い

Runtime Monitoringを全EC2インスタンスに一律有効化した結果、月額料金が想定を大幅に超えるというケースがあります。

Runtime MonitoringはEC2インスタンス1台ごとに料金が発生し、大規模なフリート（数百〜数千台規模）では顕著なコストになります。さらに、エージェントによるvCPU使用率やメモリ消費がインスタンスのコストにも影響を与えることがあります。

対策として、高リスクワークロードや機密データを扱うインスタンスから段階的に展開し、コストと検知効果を定期的に評価する運用が推奨されます。ポリシータグを活用してRuntime Monitoringの適用範囲を絞ることも有効です。

詰まり6: EventBridgeルールに設定したLambda自動対応が誤発火する

GuardDutyのfindingをEventBridgeで受けてLambdaで自動対応（IAMユーザーの無効化・インスタンスの停止など）を実装した場合に、正常なサービスアカウントの操作を攻撃と誤判定して自動対応が発火するインシデントも発生することがあります。

EventBridgeルールでseverity >= 7（HighまたはCritical）のfindingのみを対象にしている場合でも、Attack Sequence findingは必ずCriticalで生成されるため、ETD導入後にfindingの発生頻度が増えると誤発火のリスクが高まります。

対策として、以下のアプローチが有効です。

• Lambda内にホワイトリスト（信頼済みIAMエンティティ・IPアドレス）を実装し、ホワイトリストに合致する場合は自動対応をスキップする
• 自動対応のアクションを段階的に設計する（通知→隔離→無効化の順で確認ステップを設ける）
• テスト環境で誤発火パターンを十分に確認してから本番環境に展開する

詰まり7: GuardDuty無効化後に再有効化するとfindingがリセットされる

GuardDutyを無効化して再有効化すると、過去のfindingが失われます。ETDのシグナルも同様で、無効化前に蓄積されたシグナルは再有効化後に引き継がれません。

この仕様により、「GuardDutyを一時的に無効化してコストを削減し、必要な時だけ有効化する」という運用は、ETDの観点では攻撃シーケンスの検知精度を著しく低下させます。GuardDutyは常時有効化が原則です。

詰まり8: マルチアカウントで保護プランのステータスが不統一になる

AWS Organizationsを用いたマルチアカウント環境でGuardDutyを運用している場合、Administratorアカウントから一括有効化したつもりでも、一部のメンバーアカウントで特定の保護プランが有効化されていないことがあります。

Organization Adminアカウントから「Auto-enable」を有効化しても、有効化のタイミングによっては既存メンバーアカウントへの適用が遅延する場合もあります。また、メンバーアカウントが手動で保護プランを無効化できる設定になっていると、知らないうちに無効化されてしまうことがあります。

定期的にGuardDutyのOrganization設定画面から各メンバーアカウントの保護プランステータスを確認し、不整合がある場合は速やかに修正する運用が重要です。

ETD・Malware Protection for S3・Runtime Monitoringの詰まりポイント早見表

8-2. アンチパターンと正解

GuardDuty新機能の運用で陥りやすいアンチパターンと、その正しいアプローチを整理します。

アンチパターン1: 全findingをアラートとして通知する

❌ GuardDutyが生成するすべてのfindingをSlackやメールで通知するルールを設定する。

✅ 重要度Critical・Highのfindingのみをリアルタイム通知し、Medium以下はSecurity Hubに集約してバッチレビューする。

GuardDutyは大規模環境では1日数十件〜数百件のfindingを生成することがあります。すべてをアラートとして流すとアラート疲れが発生し、本当に重要なAttack Sequence finding（必ずCritical）が埋もれてしまいます。EventBridgeルールでseverityによるフィルタリングを行い、Critical・Highのみリアルタイム通知する設計が基本です。

アンチパターン2: Extended Threat Detection単体で多段攻撃を完全に検知できると考える

❌ GuardDutyを有効化するだけでETDが全ての多段攻撃を検知できると期待し、保護プランを有効化しない。

✅ S3保護・EKS保護・Runtime Monitoringといった各保護プランを有効化することで、ETDが参照できるシグナルを増やし、検知精度を高める。

ETDは「有効化したデータソースのシグナル」しか相関に使えません。S3保護を有効化していなければS3関連の攻撃シーケンスは検知できず、EKS保護がなければコンテナ環境への侵害シーケンスは検知できません。保護プランの有効化はETDの性能を引き出すための前提条件です。

アンチパターン3: Runtime Monitoringを全EC2インスタンスに一律適用する

❌ 一括設定でアカウント内の全EC2インスタンスにRuntime Monitoringを有効化する。

✅ 機密データを扱うインスタンス・外部公開サービスを実行するインスタンスなど高リスクワークロードから段階的に展開し、コストと効果を評価しながら適用範囲を広げる。

Runtime Monitoringはインスタンスごとに課金されるため、大規模環境で一括適用するとコストが急増します。また、エージェントによるCPU・メモリの消費がインスタンスのパフォーマンスに影響する場合があります。段階的な展開とコスト評価が不可欠です。

アンチパターン4: 既存の抑制ルールをETD導入後もそのまま使い続ける

❌ ETD導入前から設定していた抑制ルールを、ETD有効化後もレビューせずにそのまま使用する。

✅ ETD導入前に既存の抑制ルールを棚卸しし、攻撃シーケンス検知に必要なシグナルが意図せず除外されていないかを確認した上で、最小限の抑制ルールに絞り込む。

ETDはsuppressedになったfindingをシグナルとして利用しないため、包括的な抑制ルールが設定されているとETDの効果が大幅に減少します。「便宜的に設定した広範な抑制ルール」はETD導入の機会に見直すことを強く推奨します。

アンチパターン5: 自動対応を本番環境で即座に全面適用する

❌ EventBridgeとLambdaを使った自動対応（IAMユーザー無効化・インスタンス停止など）を、本番環境で即座に全面有効化する。

✅ まずテスト環境や非本番アカウントで十分に誤発火パターンを確認し、ホワイトリストの整備とアクションの段階設計（通知→隔離→無効化）を経てから本番展開する。

ETD導入後はAttack Sequence findingが新たに発生するようになります。自動対応の誤発火は本番サービスの停止につながるリスクがあります。段階的な展開と十分な検証が欠かせません。

8-3. まとめ

本記事では、Amazon GuardDutyの新機能であるExtended Threat Detection・Malware Protection for S3・Runtime Monitoringを中心に、本番運用の要点を解説しました。

本記事のポイント整理

• ETDによる多段攻撃検知: 単発findingでは見抜けない多段階攻撃を、24時間ローリングウィンドウでのシグナル相関によって自動検知します。検知精度は保護プランの有効化状況に依存するため、S3保護・EKS保護・Runtime Monitoringを適切に組み合わせることが重要です。

• Attack Sequence findingの体系: AttackSequence:EKS/CompromisedCluster（2025年6月GA）・AttackSequence:EC2/CompromisedInstanceGroup（2025年12月GA）・AttackSequence:ECS/CompromisedCluster（2025年12月GA）はいずれも重要度Criticalで生成されます。

• Malware Protection for S3: アップロードファイルのリアルタイムスキャンにより、不審ファイルの内部伝播を阻止します。GuardDutyMalwareScanStatusタグとEventBridgeを組み合わせた事後処理の自動化が本番運用の定石です。

• Runtime Monitoring: EKS・EC2・ECSのランタイム挙動をエージェントで収集し、プロセスレベルの攻撃行動を検知します。コストと適用範囲のバランスを考慮した段階的な展開が求められます。

• 運用設計の要点: 抑制ルールの定期見直し・EventBridge自動対応の段階設計・Security Hubとの集約連携を組み合わせることで、GuardDuty新機能を最大限に活用できます。

本番運用への次のステップ

ETDとMalware Protection for S3・Runtime Monitoringの基盤が整ったら、次のステップとしてSecurity Hubへの集約と統合ダッシュボードの構築を検討します。複数サービスのfindingを一元管理することで、SOCアナリストが多段攻撃の全体像を把握しやすくなります。

また、EventBridgeを起点としたインシデント対応の自動化（通知→隔離→修復）を段階的に整備することで、検知から対応までのMTTR（平均復旧時間）を短縮できます。GuardDutyの検知精度向上と自動対応の組み合わせが、クラウドセキュリティ運用の成熟度を高める核心です。

GuardDuty新機能の運用成熟度ロードマップ

本記事で取り上げたETD・Malware Protection for S3・Runtime Monitoringを段階的に整備し、クラウドセキュリティ運用の成熟度を高めるロードマップを示します。

各ステージを順番に整備することで、過負荷なく確実にセキュリティ運用のレベルを向上させることができます。まずはステージ1の基盤を固め、ステージ2でETDを本格活用する段階的なアプローチが推奨されます。

定期的な見直しのサイクル

GuardDutyの設定は一度構築して終わりではなく、環境変化に合わせた定期的な見直しが重要です。以下のサイクルを運用に組み込むことを推奨します。

• 月次: findingの発生傾向レビュー・アラート疲れの有無確認・新しいAttack Sequence findingタイプの確認
• 四半期: 抑制ルールの棚卸し・保護プランのカバレッジ確認・自動対応のホワイトリスト更新
• 年次: 全体的なセキュリティポスチャレビュー・AWSの新機能評価・料金最適化

このサイクルを継続的に回すことで、GuardDutyの検知精度と対応速度を常に最高水準に保つことができます。GuardDutyは継続的に新機能が追加されているサービスです。AWSのアップデート情報（What’s New・Security Blog）を定期的に確認し、新しいAttack Sequence findingタイプや保護プランが追加された際には速やかに評価・導入を検討します。

なお、GuardDutyの設定変更（保護プランの有効化・無効化・抑制ルールの変更など）は、CloudTrailで記録されます。GuardDuty設定変更のCloudTrailイベントをEventBridgeで監視することで、意図しない設定変更を即座に検知できる内部統制ループを構築することも有効です。

8-4. 注意事項

Amazon GuardDutyの機能・料金・対応サービスは継続的に更新されています。本記事の情報は執筆時点の仕様に基づいています。最新情報はAWS公式ドキュメントおよびリリースノートをご確認ください。特に保護プランごとの対応リージョン・対応OSバージョン・料金体系は変更される場合があります。本番環境への適用前には必ず最新の公式情報を確認した上で設計・実装してください。

また、GuardDuty findingはセキュリティチームのレビューなしに本番環境で直接的な対処（アクセスキーの無効化・インスタンスの停止など）を実行する場合は、十分な誤発火対策が施されていることを確認してください。適切な運用体制を整えた上で自動対応の範囲を段階的に拡大することが、安全なセキュリティ自動化の基本です。

8-5. 関連記事