こんにちは、アイレットの日下です。AWSの脅威検知を支える Amazon GuardDuty は非常に多機能ですが、その真価はログを眺めることではなく「仕様のクセを理解して運用に組み込むこと」にあります。実際にコンソールを叩き、最新の保護プランまで触れて分かった、地に足の着いた運用ポイントを解説します。

1. GuardDutyは「脆弱性」ではなく「挙動」を裁く

よく「Amazon Inspector と何が違うの？」という質問を受けますが、その役割は決定的に異なります。

  • Inspector（予防）： 自分に「隙（脆弱性）」がないか調べる、いわば「戸締まり点検」。
  • GuardDuty（検知）： 今まさに「泥棒（脅威）」が入っていないか、不審な動きを調べる「監視カメラ」です。

 

ログを「集約」せず「直接」解析する

GuardDutyの最大の特徴は、VPC Flow LogsやCloudTrailなどのログをS3から読み込んでいるのではなく、コントロールプレーンから直接ストリームとして吸い上げている点にあります。そのため、インフラ側の負荷はゼロ。既存のワークロードに一切の影響を与えずに導入できることが最大の魅力です。

2. 検知ロジックの正体：シグネチャ & 振る舞い

GuardDutyの判定は、静的な「点」と動的な「線」の両面から行われます。

  • シグネチャベース： AWS独自の脅威インテリジェンスを活用。世界中で収集された最新のブラックリスト（悪意あるIPやドメイン）と数分おきに照合し、既知の攻撃を瞬時に見抜きます。
  • 振る舞い（アノマリ）ベース： 機械学習モデルが約14日間かけて、その環境固有の「平常時（Baseline）」を学習します。例えば「普段は1GBしか転送しないロールが突然500GBダウンロードした」といった、シグネチャが存在しない未知の攻撃を、統計的な乖離によって炙り出します。

ただし、有効化したばかりのアカウントやリソースは、最長2週間の学習期間が終わるまでこのアノマリ検知が有効に機能しません（この期間はシグネチャ検知のみが頼りとなります）。この仕様の存在は、初期運用の設計において必ず頭に入れておくべき裏仕様です。

3. 「通知タイミング」の落とし穴

運用設計において、EventBridgeへの送信タイミングの仕様理解は非常に重要です。

  • 新規（New）： 初めて検知された脅威は、ほぼリアルタイムで通知されます。
  • 更新（Subsequent）： 同一の活動が継続している場合、デフォルトでは6時間ごとに集約して通知されます。

※ 自動防御のトリガーは必ず「初回通知」で 「2回目の通知を待ってから対処」では、最長6時間の空白が生まれてしまい、攻撃者がその間に目的を達成する可能性があります。なので新規通知を受けた際に、セキュリティグループ（SG）の遮断や IAM アクセスキーの無効化を即座にオートメーションで実行するのが、GuardDuty運用をする上で肝になるポイントです。

添付の画像について

  • デフォルト設定の確認： 「検出結果のエクスポートオプション」セクションを見ると、『EventBridge と S3 を 6 時間ごとに更新 (デフォルト)』 と明記されているのがわかります。
  • 「更新」通知の性質： これは、一度検知された攻撃が継続している場合、その続報が届くまでに最大 6 時間のタイムラグが発生することを意味します。
  • 運用の要諦： 「編集」ボタンから頻度を短縮することも可能ですが、それでも最短 15 分です。だからこそ、前述の通り 『新規通知（New）』というリアルタイムなトリガー を逃さず、即座に自動防御（SG遮断など）へ繋げる設計が不可欠です。

4. 進化する「保護プラン」：エージェントレスの限界を超える

現在のGuardDutyは、単なるログ解析を超えた個別プランの組み合わせで真価を発揮します。

① Malware Protection for EC2：本体を汚さないスキャン

不審な挙動（マイニング通信など）を検知すると、裏側でターゲットのEBSスナップショットを作成し、マルウェアスキャンを自動実行します。

  • 非侵襲な設計： 本体にエージェントを導入せず、複製したスナップショット側を調べるため、稼働中のワークロードへの負荷は一切ありません。
  • コストの暴走防止： 攻撃を受け続けてもスキャン料金が爆発しないよう、自動スキャンは同一インスタンスに対し24時間に1回までに制限されています。
  • 証拠保全： 「マルウェアが見つかった場合のみスナップショットを保持する」という設定が可能。事後調査に必要なエビデンスを最小限のコストで残せます。

※GuardDutyコンソールの「EC2のマルウェア保護」設定画面です。自動スキャン設定や、検知時のスナップショット保持オプションが確認できます。

② Runtime Monitoring：OS内部まで見通す

これまでのログ解析では追えなかった、OS内の「どのプロセスが起動したか」というプロセスレベルの動きを捕捉します。

  • エージェント管理の自動化： セキュリティエージェントのデプロイはAWS側での自動管理が可能。VPCエンドポイント経由でイベントを配信する構成をとります。
  • 二重課金の回避： エージェント側でネットワーク情報を取得するため、この機能を有効にしたインスタンスでは、VPC Flow Logs側の解析課金が免除されるという合理的で良心的な仕様になっています。

添付の画像について

  • カバレッジの可視化： 画面上部では、EKSやECS（Fargate含む）、EC2といった各ワークロードごとの監視導入率がひと目で確認できます。 「有効にしたつもり」で漏れているリソースをなくすための、運用に欠かせないダッシュボードです。
  • インスタンスごとのステータス詳細： 下段の「インスタンスリスト」では、特定のEC2に対してエージェントが正常（Healthy）に動作しているか、自動管理されているかを確認できます。
  • 異常の早期発見： このリストで「Unhealthy」と表示されているものは、エージェントの未導入や通信不備などの問題があることを示しています。

5. まとめ：自動化して初めて「価値」が出る

GuardDutyそのものには、攻撃を止める力はありません。

  1. 検知（GuardDuty）
  2. 判断（トリアージ・重要度の確認）
  3. 封じ込め（EventBridge + Lambdaによる自動遮断）

このフローを回して初めて、24時間365日の監視が完成します。まずは有効化から始めて、ワークロードに合わせて必要な保護プランを積み上げていきましょう。