AWS GuardDutyでセキュリティ対策！脅威検知のベストプラクティス

AWS GuardDutyは、CloudTrailの管理イベントやVPCフローログ、DNSログなどを継続的に分析し、機械学習や脅威インテリジェンスを用いて不正なアクティビティを検知する脅威検知サービスです。AWSの公式FAQでは、ワークロードのパフォーマンスや可用性に影響を与えない設計とされており、AWS環境のセキュリティリスクを可視化できます。本記事では、検知した脅威の重要度に応じた対応フローの構築や、Security Hubを用いた複数サービスの検出結果の一元管理など、実践的な運用方法を解説します。

この記事で分かること

AWS GuardDutyが検知できる脅威の種類と仕組み
重要度に応じた具体的な対応フローの構築手順
Security HubやInspectorなど他のAWSサービスとの連携方法
複数アカウント管理や無料枠の確認方法

AWSのセキュリティ対策におけるGuardDutyの役割

AWS環境におけるセキュリティ対策では、クラウド事業者であるAWSと利用者の双方が責任を分担するモデルが採用されています。その中で、Amazon GuardDutyは利用者側の責任範囲における脅威検知を自動化し、セキュリティレベルを向上させる重要な役割を担います。

責任共有モデルとユーザー側の対策

AWSを利用する際、セキュリティの基盤となるのが責任共有モデルです。AWSはデータセンターの物理的なセキュリティやインフラストラクチャの保護を担当しますが、その上で稼働するOS、ネットワーク設定、ファイアウォールの構成、そしてデータの保護は利用者の責任となります。

利用者側が実施すべき主なセキュリティ対策は、以下の通りです。

IAM（AWS Identity and Access Management）を用いた適切なアクセス権限の管理
VPC（Amazon Virtual Private Cloud）やセキュリティグループによるネットワークの保護
OSやアプリケーションのパッチ適用と脆弱性管理
システムログやアクセスログの継続的な監視と脅威検知

これらの対策のうち、ログの監視と脅威検知を手動で行うことは運用負荷が非常に高く、現実的ではありません。そこで、自動化された脅威検知サービスであるGuardDutyの活用が必要となります。

脅威検知の要となるGuardDutyの重要性

Amazon GuardDutyは、AWS環境内のデータソースやログを継続的にモニタリングし、悪意のある操作や不正な動作を検知するマネージド型の脅威検知サービスです。AWSの公式ドキュメントによると、悪意のあるIPアドレスやドメインのリスト、ファイルハッシュなどの脅威インテリジェンスフィードと、機械学習モデルを使って、疑わしいアクティビティを特定します。

GuardDutyが監視する主なデータソース

GuardDutyを有効にすると、次の3つの基本データソースが自動的に分析の対象になります。利用者が個別にログ収集の仕組みを構築したり、サーバーにソフトウェアをインストールしたりする必要はありません。

データソース	検知できる主な脅威の例
AWS CloudTrail 管理イベント	通常とは異なるAPI呼び出し、権限昇格の試み、無効な認証情報の連続使用
Amazon VPC フローログ	悪意のあるIPアドレスとの通信、ポートスキャン、EC2インスタンスからのデータ流出
DNS ログ（Route 53 Resolver）	既知のコマンド＆コントロール（C&C）サーバーへの通信、暗号資産マイニングに関連するドメインへのアクセス

公式ドキュメントによると、GuardDutyはこれらのデータを独立したデータストリームとして取得するため、VPCフローログやRoute 53 Resolverのクエリログを自分で作成・設定する必要はなく、既存のCloudTrailの設定にも影響しません。ただし、OpenDNSやGoogle DNSなどの別のDNSリゾルバーや、独自に構築したDNSリゾルバーを使っている場合、そのDNSのデータはGuardDutyで分析できません。

これらのログを統合的に分析することで、アカウントの侵害やリソースの不正利用を早期に発見し、被害を最小限に抑えることが可能になります。

保護プランで監視範囲を広げる

基本のデータソースに加えて、GuardDutyでは目的に応じた保護プランを追加できます。AWSの公式ドキュメントに掲載されている主な保護プランは、次のとおりです。

S3 Protection：Amazon S3バケットのデータ流出や破壊の試みなどを検知する
EKS Protection：Amazon EKSクラスターのKubernetes監査ログを分析する
Runtime Monitoring：Amazon EKS、EC2、ECS（Fargateを含む）のOSレベルのイベントを監視する。GuardDutyのセキュリティエージェントを使用する
Malware Protection：EC2のEBSボリュームやS3にアップロードされたオブジェクトなどのマルウェアを検出する
RDS Protection：AuroraやRDSデータベースへのログイン活動を分析する
Lambda Protection：Lambda関数のネットワークアクティビティを監視する
AI Protection：Amazon BedrockやSageMaker AIを使うAIワークロードへの脅威を検知する

また、複数のデータソースやリソースにまたがる多段階の攻撃を検出する「Extended Threat Detection」は、GuardDutyを有効にしたアカウントで自動的に有効になります。保護プランの追加や料金は、利用前にAWS公式ドキュメントと料金ページで確認してください。

AWS GuardDutyの効果的な運用方法

AWS GuardDutyは有効化するだけで脅威検知を開始しますが、検知した後の運用体制が整っていなければ、セキュリティインシデントの被害を最小限に抑えることはできません。ここでは、実際の運用において不可欠な対応フローの構築と、継続的なチューニング方法について解説します。

脅威の重要度に応じた対応フローの構築

GuardDutyが生成する検出結果（Finding）には、脅威の深刻度に応じて「緊急（Critical）」「高（High）」「中（Medium）」「低（Low）」の4段階の重要度が割り当てられます。数値は1.0〜10.0の範囲で、値が高いほどセキュリティリスクが大きいことを示します。限られたリソースで効率的にセキュリティ運用を行うためには、この重要度ごとにあらかじめ対応手順を定義しておくことが重要です。

重要度	数値スコア	状態と意味（AWS公式の定義）	対応アクションの例
緊急 (Critical)	9.0 - 10.0	攻撃シーケンスが進行中、または最近発生した可能性があり、IAM認証情報やS3バケットなどの複数のリソースが侵害されている、または侵害済みの可能性がある状態	最優先で即時通知（電話・緊急チャット）し、攻撃全体の流れと影響範囲を調査する。認証情報の無効化など、被害拡大を防ぐ措置を速やかに実施する
高 (High)	7.0 - 8.9	リソース（EC2インスタンスやIAM認証情報など）が侵害され、不正な目的で使用されている状態	即時通知（電話・緊急チャット）、対象のEC2インスタンスやIAM認証情報の自動隔離・無効化
中 (Medium)	4.0 - 6.9	通常の動作から逸脱した不審なアクティビティがある状態。使い方によっては、リソースの侵害を示している可能性がある	営業時間内の調査開始、SlackやMicrosoft Teamsへの通知、ログの分析
低 (Low)	1.0 - 3.9	不審なアクティビティの試みがあったが、環境は侵害されていない状態（失敗した侵入の試みなど）	即時対応はせず、週次や月次のセキュリティレポートで傾向を監視

検出結果の種類ごとに既定の重要度が決まっており、たとえば公式ドキュメントでは、Torネットワークへの接続（UnauthorizedAccess:EC2/TorClientなど）、暗号資産マイニング関連のDNSクエリ（CryptoCurrency:EC2/BitcoinTool.B!DNS）、C&Cサーバーとの通信（Backdoor:EC2/C&CActivity.B）の既定の重要度は「高」、EC2からのポートスキャン（Recon:EC2/Portscan）の既定の重要度は「中」とされています。なお、同じ種類の検出結果でも、状況によって重要度が異なる場合があります。各重要度の詳細な定義は、AWS公式ドキュメントのGuardDutyの検出結果の重要度で確認できます。

たとえば、重要度が「高」以上の検出結果が出た場合は、Amazon EventBridgeとAWS Lambdaを連携させ、対象のEC2インスタンスのセキュリティグループを自動的に変更してネットワークから隔離する仕組みを構築することが有効です。GuardDutyは、検出結果をAmazon EventBridgeに自動的に送信します。新しく生成された検出結果は、ほぼリアルタイムで通知されます。同じ種類の検出結果が繰り返し発生した場合は、既定では6時間ごとに1つのイベントにまとめられます。この間隔は、管理者アカウントから15分または1時間に変更できます。一方で「低」の場合は、即時対応ではなく定期的な確認にとどめるなど、メリハリをつけた運用が求められます。

定期的なセキュリティレビューの実施

脅威検知の精度を高く保ち、運用担当者の負担（アラート疲労）を軽減するためには、定期的なセキュリティレビューと設定のチューニングが欠かせません。特に、正常な通信を脅威として検知してしまう誤検知（フォールス・ポジティブ）への対応は継続的に行う必要があります。

信頼済みIPリスト（Trusted IP list）の更新：提携先や脆弱性診断ツールなど、信頼できる通信元のIPアドレスを登録し、不要なアラートを除外します。リストの対象は、パブリックにルーティング可能なIPアドレス（IPv4）宛ての通信に限られます。
脅威リスト（Threat list）の活用：自社で独自に把握している悪意のあるIPアドレスを登録し、検知を強化します。
抑制ルールの適用：特定の条件に合致する低リスクな検出結果を自動的にアーカイブし、重要なアラートを見落とさないように整理します。

公式ドキュメントによると、信頼済みリストは、1つのAWSアカウントにつき、リージョンごとに、IPアドレスのリストを1つまで登録できます。複数アカウントの環境では、リストを管理できるのはGuardDutyの管理者アカウントのみで、設定はメンバーアカウントにも自動的に適用されます。また、リストを有効化・無効化・削除した際の反映には、通常15分、場合によっては最大40分かかります。

抑制ルールに一致した検出結果は、生成された後で自動的に「アーカイブ」され、90日間GuardDutyに保存されます。注意点として、抑制された検出結果は、AWS Security Hub CSPMやAmazon EventBridgeなどには送信されません。抑制ルールは、本当に対応不要な検出結果に絞って設定してください。

これらのリストやルールは一度設定して終わりではありません。月に1回程度を目安に検出結果の傾向を分析し、リストの見直しやルールの追加を行う運用サイクルを確立することをおすすめします。リストの具体的な管理手順については、信頼されたIPリストと脅威リストの操作を参照してください。

他のAWSセキュリティサービスとの連携

AWS環境のセキュリティレベルを向上させるには、Amazon GuardDuty単体での運用だけでなく、他のAWSセキュリティサービスと連携させることが効果的です。各サービスが担う役割を理解し、組み合わせて利用することで、脅威の予防から検知、対応までのプロセスを包括的にカバーできます。

Amazon Inspectorによる脆弱性管理との違い

AWSのセキュリティ対策において、GuardDutyとAmazon Inspectorはどちらも重要な役割を果たしますが、その目的とアプローチは明確に異なります。GuardDutyが実際の攻撃や不審なアクティビティをほぼリアルタイムで検知する「発見的統制」のサービスであるのに対し、Inspectorはシステムに潜む弱点を事前に見つけ出す「予防的統制」のサービスです。

比較項目	Amazon GuardDuty	Amazon Inspector
主な目的	脅威検知（悪意のあるアクティビティの監視）	脆弱性管理（ソフトウェアの脆弱性やネットワーク露出の検出）
監視対象	VPCフローログ、CloudTrail管理イベント、DNSログなど	Amazon EC2インスタンス、コンテナイメージ、AWS Lambda関数など
アプローチ	ログの継続的な分析による事後検知	リソースのスキャンによる事前評価

例えば、EC2インスタンスに古いバージョンのソフトウェアがインストールされている場合、Amazon Inspectorはその脆弱性を検知してパッチ適用の必要性を提示します。一方、その脆弱性を突かれて外部から不正なアクセスを受けたり、マルウェアに感染して不審な通信が発生したりした場合は、Amazon GuardDutyがその異常な振る舞いを検知します。

このように、Inspectorで脆弱性を減らして攻撃の隙を減らし、それでも発生する脅威をGuardDutyで検知するという組み合わせが有効です。

AWS Security Hubでの一元的な可視化

複数のAWSアカウントやセキュリティサービスを運用している場合、アラートの確認や管理が煩雑になる課題があります。この課題を解決するのが、セキュリティ状態を統合的に管理できるAWS Security Hubとの連携です。AWSの公式ドキュメントでは、現在このサービスを「AWS Security Hub CSPM（Cloud Security Posture Management）」という名称で説明しています。

GuardDutyの検出結果をSecurity Hub CSPMに統合することで、以下のようなメリットが得られます。

GuardDuty、Inspector、Amazon Macieなど、複数のAWSサービスの検出結果を集約して確認できる
CIS AWS Foundations Benchmarkなどのセキュリティ基準に照らし合わせた環境の評価が可能になる

特に、マルチアカウント環境においては、GuardDutyの管理者アカウントに検出結果を集約して運用することが有効です。Security Hub CSPMと組み合わせることで、セキュリティ状況を一か所で確認でき、インシデント発生時の初動対応を進めやすくなります。なお、CISベンチマークの全項目に準拠したチェックを行うには、サポートされているすべてのリージョンでSecurity Hub CSPMを有効にする必要があります。

よくある質問（FAQ）

AWS GuardDutyの無料枠はどのように確認できますか

AWSの公式料金ページによると、GuardDutyには、サポートされているリージョンで、まだGuardDutyを利用したことがない新しいAWSアカウントを対象とした30日間の無料トライアルがあります。無料トライアルは、アカウントごと、リージョンごとに適用されます。また、追加で有効にした保護プランにも、それぞれ30日間のトライアルがあります（Malware Protection for S3、AWS Backup向けなど、トライアルの扱いが異なるものもあります）。

無料トライアルの残り日数は、GuardDutyのコンソールで確認できます。また、コンソールの使用状況ページでは、トライアル中もトライアル終了後も、データソースごとの月額費用の見積もりを確認できます。この見積もりを活用することで、導入後のコストを事前に把握できます。詳細な料金体系については、AWS GuardDutyの料金ページをご参照ください。

サードパーティのセキュリティツールと連携できますか

はい、連携可能です。GuardDutyが生成した検出結果は、Amazon EventBridgeに自動的に送信されます。EventBridgeのルールを設定することで、通知先や連携先のシステムに検出結果を渡せます。

AWSの公式パートナー一覧には、GuardDutyと連携するパートナーとして、次のようなサービスが掲載されています。

ツールカテゴリ	パートナー一覧に掲載されているサービス例	主な利用目的
SIEM・ログ分析	Splunk、Sumo Logic、Datadog	他のセキュリティログとの相関分析や長期保管
インシデント管理	PagerDuty	担当者への通知とインシデント対応の管理

Jira Service ManagementやSlack、Microsoft Teamsなど、上記以外のツールとの連携については、公式のパートナー一覧では確認できませんでした。連携の可否や設定方法は、各ツールの公式情報でご確認ください。

GuardDutyのアップデートは手動で行う必要がありますか

基本のデータソースを監視する場合、利用者側で手動のアップデートを行う必要はありません。GuardDutyはAWSが提供するマネージド型のサービスであり、脅威インテリジェンスは、AWSおよびProofpointやCrowdStrikeなどのサードパーティプロバイダーから提供されます。AWSの公式FAQによると、これらのフィードはあらかじめ統合されており、追加料金なしで更新されます。

ただし、Runtime Monitoringを使う場合は、EC2やEKSなどにGuardDutyのセキュリティエージェントが必要になります。エージェントの導入方法や管理方法は、公式ドキュメントで確認してください。

複数のAWSアカウントを管理するベストな方法はありますか

AWS Organizationsと統合し、委任された管理者アカウントを設定する方法が一般的です。この設定により、組織内のメンバーアカウントのGuardDutyを一元的に有効化し、管理することができます。

複数アカウントを管理する際の主なメリットは以下の通りです。

自動有効化の設定（新規アカウントのみ、または全メンバーアカウント）により、GuardDutyを有効にできる。保護プランの自動有効化は、プランごとに設定が必要
メンバーアカウントの検出結果を、1つの管理者アカウントに集約できる
信頼済みIPリスト、脅威リスト、抑制ルールを、管理者アカウントから一元管理できる
AWS Organizations経由で管理されているメンバーアカウントは、自分でGuardDutyを無効化・一時停止できない

パフォーマンスへの影響を心配する必要はありますか

AWSの公式FAQによると、GuardDutyは、利用者のリソースから完全に独立して動作し、ワークロードのパフォーマンスや可用性に影響を与えないように設計されています。基本のデータソースは、AWSのインフラストラクチャ側からGuardDutyに送られるため、EC2インスタンスにエージェントをインストールする必要はありません。

ただし、Runtime Monitoringでセキュリティエージェントを導入する場合は、そのエージェントによるリソースの使用が発生します。

分析の対象となる主なデータソースは以下の通りです。

AWS CloudTrailの管理イベント
Amazon VPCフローログ
DNSクエリログ（Route 53 Resolver）
保護プランを有効にした場合：S3のCloudTrailデータイベント（S3 Protection）、EKSの監査ログ（EKS Protection）、RDSのログイン活動（RDS Protection）、Lambdaのネットワークアクティビティ（Lambda Protection）、OSレベルのランタイムイベント（Runtime Monitoring）など

なお、S3 Protectionを使うために、CloudTrailのS3データイベントのログを自分で有効にする必要はありません。