Amazon GuardDutyは、AWS環境で発生するログやイベントを継続的に分析し、不審な操作や通信の兆候を検出する脅威検知サービスです。AWSアカウントの不正利用、通常とは異なるAPI操作、悪意ある可能性がある通信先とのやり取りなどに気づきやすくし、管理者やセキュリティ担当者が調査と対応に移れるよう支援します。
ポイントは、GuardDutyが「攻撃を自動で完全に防ぐサービス」ではなく、「危険な兆候を見つけて知らせるサービス」であることです。検出結果を確認する担当者、通知先、初動対応の流れまで決めておくと、単なるアラートで終わらず、実際の運用に組み込みやすくなります。
Amazon GuardDutyの基本概要
GuardDutyは、AWS環境内の操作ログ、ネットワーク通信、名前解決に関する情報などをもとに、セキュリティ上注意すべき動きを検出します。検出された内容は「Finding」と呼ばれ、対象リソース、検出理由、重要度などを確認できます。
脅威検知とは、すでに起きた被害だけを見るのではなく、被害につながる可能性がある兆候を早めに見つける考え方です。たとえば、普段使われない地域からのAPI操作、疑わしいIPアドレスとの通信、認証情報の悪用を疑わせる動きなどが調査のきっかけになります。
GuardDutyが見る主なデータ
GuardDutyを有効化すると、基本的なデータソースの分析が始まります。代表的なデータは次のとおりです。
| データソース | 何を見るか | 読み取り方の例 |
|---|---|---|
| AWS CloudTrailの管理イベント | AWS APIの呼び出しやアカウント操作 | 誰が、どこから、どの操作をしたかを手がかりにします。 |
| VPC Flow Logs | EC2インスタンスなどに関連するネットワーク通信 | 外部との不審な通信や、内部ネットワーク上の通常と異なる動きを見ます。 |
| Route 53 Resolver DNSクエリログ | 名前解決の問い合わせ | 悪意あるドメインやコマンドアンドコントロール通信の可能性を調べます。 |
GuardDutyは、これらの情報を脅威インテリジェンスや機械学習の仕組みと組み合わせて分析します。脅威インテリジェンスとは、悪意あるIPアドレス、ドメイン、攻撃手法に関する情報のことです。機械学習は、通常の利用傾向と異なる動きを見つけるために使われます。
GuardDutyでできること
不審な操作や通信を検出する
GuardDutyは、通常の利用パターンから外れたAPI操作、怪しい通信先、リスクの高いアクセスパターンなどを検出結果として示します。これにより、アカウント侵害や意図しない設定変更の可能性に早く気づき、調査の優先順位をつけやすくなります。
検出結果を調査の入口にする
GuardDutyのFindingには、対象リソース、検出タイプ、重要度、関連する通信や操作の情報が含まれます。担当者はこの情報を起点に、アクセスキーの無効化、権限の見直し、通信遮断、ログ確認などの対応を検討できます。
ただし、Findingは「調査すべき兆候」であり、すべてが確定した侵害を意味するわけではありません。誤検知や業務上正当な操作もあり得るため、実際の運用では確認手順と判断基準を用意しておくことが大切です。
通知と自動対応につなげる
GuardDutyの検出結果は、Amazon EventBridgeを使って通知や自動対応に連携できます。たとえば、Amazon SNSで担当者に通知し、必要に応じてAWS Lambdaで一次対応の処理を実行する構成が考えられます。
通知設計を深める場合は、Amazon CloudWatchの監視設計、Amazon SNSのPub/Sub設計、AWS Lambdaによるサーバーレス設計も合わせて確認すると理解しやすくなります。
Amazon GuardDutyの導入手順
GuardDutyはAWS Management Consoleから有効化できます。導入時は、単にスイッチを入れるだけでなく、監視対象、通知先、担当者、対応ルールを合わせて決めることが重要です。
- 監視するアカウントとリージョンを決める
GuardDutyはリージョン単位で有効化します。重要なワークロードがあるリージョンだけでなく、利用していないリージョンの扱いも確認しておくと安全です。複数アカウントを運用している場合は、組織単位での管理も検討します。 - GuardDutyを有効化する
AWS Management ConsoleでGuardDutyを開き、対象リージョンで有効化します。有効化後、基本的なデータソースの分析が開始されます。 - サンプルFindingで見え方を確認する
本番の検出を待つ前に、サンプルFindingを使って画面の見方、重要度、通知先、確認担当を確認しておくと、実際のアラート時に迷いにくくなります。 - 通知とエスカレーションを設計する
EventBridge、SNS、メール通知、チャット通知、チケット起票など、運用に合う連絡経路を決めます。重要度が高いFindingと低いFindingで通知先を分けると、見落としと通知疲れを減らせます。 - 調査と対応の手順を決める
誰がFindingを確認し、どの条件でアクセスキーの停止、権限見直し、通信遮断、ログ確認を行うのかを決めます。GuardDutyは検知の入口なので、対応手順まで用意して初めて効果が出ます。
GuardDutyの料金の考え方
GuardDutyは、利用量に応じて料金が変わるサービスです。監視するデータソース、保護機能、リージョン、アカウント数、処理されるログやイベントの量によって費用が変わります。
| 費用に影響する要素 | 確認するポイント |
|---|---|
| 有効化するリージョン | どのリージョンでGuardDutyを有効にするかを整理します。 |
| 対象アカウント数 | 複数アカウントでは、アカウントごとの利用量も確認します。 |
| 分析対象のデータ量 | CloudTrail管理イベント、VPC Flow Logs、DNSクエリなどの量が費用に関係します。 |
| 追加の保護機能 | S3、EKS、Runtime Monitoring、RDS、Lambdaなどの保護機能を使う場合は、それぞれの料金条件を確認します。 |
初めてGuardDutyを有効化するアカウントやリージョンでは、一定期間の無料トライアルを利用できる場合があります。導入前にAWS公式の料金ページとGuardDutyコンソールの利用量見積もりを確認し、通知運用や調査工数も含めて本番利用のコストを見積もると現実的です。
GuardDutyが役立つ利用シーン
- コンプライアンス対応が求められる環境
医療、金融、公共系など、監査性や継続的なセキュリティ監視が重視される環境では、AWS上の操作や通信を継続的に確認する仕組みが役立ちます。 - リモートワークや外部アクセスが多い環境
アクセス元や操作パターンが多様になるほど、通常と異なる動きに気づく仕組みが必要になります。GuardDutyは、AWS環境内で発生する不審な兆候を把握する補助線になります。 - ECサイトやオンラインサービス
サービス停止や不正アクセスの影響が大きいシステムでは、異常な通信やアカウント操作を早期に検出し、関係者へ通知する運用が重要です。 - 複数アカウントを運用する組織
アカウントが増えると、個別に状況を追うだけでは見落としが起きやすくなります。GuardDutyを組織的に管理すると、検出結果を集約して確認しやすくなります。
導入時に注意したいポイント
- 検知と防御を分けて考える
GuardDutyは脅威を検出するサービスであり、すべての攻撃を自動で止める仕組みではありません。検出後の対応手順を別に用意します。 - リージョンごとの有効化を確認する
GuardDutyはリージョン単位で扱います。使っていないリージョンでも、グローバルサービスに関連する不審な操作が問題になる場合があります。 - 通知の優先順位を決める
すべてのFindingを同じ扱いにすると、重要な通知を見落とす原因になります。重要度、対象リソース、業務影響に応じて確認順を決めます。 - 誤検知を前提に運用する
検出結果は調査の入口です。業務上正当な操作か、設定変更による一時的な挙動か、実際の侵害兆候かを確認できる体制が必要です。
より運用設計に踏み込む場合は、GuardDutyを運用で効く形にする設計も参考になります。
まとめ
Amazon GuardDutyは、AWS環境で脅威検知を始めるうえで有力な入口になるサービスです。CloudTrail管理イベント、VPC Flow Logs、Route 53 Resolver DNSクエリログなどを分析し、不審な操作や通信をFindingとして示すことで、調査と対応の起点を作れます。
導入時は、料金、通知、担当範囲、対応手順を合わせて設計することが大切です。まずは小さく有効化し、Findingの傾向と運用負荷を確認しながら、AWS環境全体のセキュリティ監視に組み込んでいくとよいでしょう。