【ガイドライン】会社組織/システムへ Amazon GuardDuty を導入する際の検討事項

作成日: 2023/08/11, 更新日: 2025/01/22

Amazon GuardDuty は、AWSアカウントのアクティビティを監視し脅威検出するサービスです。
本記事では、Amazon GuardDuty の概要の説明と会社組織/システムへ導入を検討するにあたって確認すべきポイントを記載いたしました。

改訂履歴
Amazon GuardDuty とは？
導入検討
1. ① IDS/IPS 製品を利用しているか？
ガイドライン策定
1. ① 有効化する保護機能の検討
2. ② 役割分担整理

改訂履歴

日付	更新内容
2025/01/22	・「GuardDuty Malware Protection for S3」「GuardDuty Runtime Monitoring」を追加・リンク切れの更新

Amazon GuardDuty とは？

Amazon GuardDuty （以下略: GD）は、AWS アカウント内のアクティビティを監視し、不正なアクションや不審なアクティビティを検出するマネージド型の脅威検知サービスです。
GD は、AWS CloudTrail ログ、Amazon VPC フローログ、DNS ログを AWS が内部的に収集して分析し、不正なアクティビティを検出します。
- よく勘違いされていますが、GD を利用するためには、CloudTrail と VPC フローログを有効にする必要はありません。

GD では基本的なデータソースに加えて、以下の 7 つの脅威検出機能がオプションで利用可能です。
- GuardDuty EKS Protection
- GuardDuty Lambda Protection
- GuardDuty Malware Protection for EC2
- GuardDuty Malware Protection for S3
- GuardDuty RDS Protection
- GuardDuty S3 Protection
- GuardDuty Runtime Monitoring

30 日間の無料トライアルが可能なため、まずは無料トライアルを利用しどのぐらいの料金がかかるかを確認することをおすすめします。

導入検討

① IDS/IPS 製品を利用しているか？

GD は IDS/IPS のうち、IDS（Intrusion Detection System）に分類されます。
既存の環境で IDS/IPS 製品を利用している場合は、GD との併用は検討する必要があります。
- IDS は異常な通信を見つけた場合に通知のみを行いますが、IPS は異常な通信を見つけた場合に通知のみならず、通信を遮断することも可能です。
- IPS は IDS と比べ迅速な対応が実現できる反面、業務影響が大きい仕組みでもあります。
  - 設定が不正な場合など誤検知を行うと、即時システムの停止にもつながり得るためです。

GD では機械学習を利用しているため、ブルートフォース攻撃や不審な API 通知も検知することができます。
以下の表は GD と Network Firewall のマネージドルールで検知/遮断される攻撃や通信の種類を整理しました。
- 参考:
  - 検出結果タイプ - Amazon GuardDuty
  - Using AWS managed rule groups in AWS Network Firewall - AWS Network Firewall

カテゴリ	項目	GuardDuty	Network Firewall
攻撃	マルウェア	○	○
〃	DoS/DDoS	○	○
〃	ゼロデイ(脆弱性)	○	○
〃	フィッシング	○	○
〃	ブルートフォース	○	-
通信	ボットネット	○	○
〃	匿名通信(Tor)	○	-
〃	不審な通信元/通信先	○	○
〃	不審なAPI通信	○	-
〃	その他不審な通信	○	○
設定	Kubernetesの設定不備	○	-

既存で利用している IDS/IPS 製品や Network Firewall を利用するのであれば、GD は利用しない選択肢もあります。

ガイドライン策定

① 有効化する保護機能の検討

GD では、以下の 7 つの脅威検出機能がオプションで利用可能です。会社としてどの脅威検出機能を有効化するかを検討します。

No	項目	概要	料金(東京リージョン)
01	S3 Protection	CloudTrail の管理イベントとデータイベントの両方をモニタリングして、 Amazon S3 バケットのAPIオペレーションを分析します。	100 万イベントあたり 1.04 USD (最初の 5 億イベント/月)
02	RDS Protection	Amazon Aurora データベースのログインアクティビティを分析します。	vCPU あたり 1.33 USD
03	Malware Protection for EC2	脅威のあるアクティビティが検知された場合、 Amazon EC2 インスタンスまたはコンテナワークロードにアタッチされたEBSをスキャンします。	1 GB あたり 0.05 USD
04	Malware Protection for S3	S3 バケットにアップロードされたファイルをスキャンして、マルウェアを検出します。	1 GB あたり 0.60 USD
05	EKS Protection	EKS の監査ログとランタイムをモニタリングし、アプリケーションやコントロールプレーンのアクティビティ、イベントを分析します。	監査ログ: 2.48USD/100 万件のイベント (最初の 1 億イベント/月) EKS ランタイムモニタリング: vCPU あたり 2.00USD (最初の 500 個の vCPU /月)
06	Lambda Protection	Lambda ネットワークアクティビティログを分析します。	1 GB あたり 1.18 USD (最初の 500 GB/月)
07	Runtime Monitoring	Lambda、EC2、Fargate などのリソースのランタイムアクティビティを監視します。	vCPU あたり 1.50 USD (最初の 500 個の vCPU /月)

参考

脅威検出機能の有効化を検討するにあたり、GD の検出内容を対策/検知する方法が他の設計でされていないか確認することが重要です。

以下は S3 Protection における検出結果タイプと対策/検知方法の有無をリストアップしたものです。
- GuardDuty の S3 の検出結果タイプ - Amazon GuardDuty

他の AWS サービスの機能を利用して対策/検知することが基本的に可能だと考えます。

GuardDuty のS3 の検出結果タイプ	デフォルトの重要度	対策/検知方法の有無
Discovery:S3/AnomalousBehavior	低	有(*1)
Discovery:S3/MaliciousIPCaller	高	有(*1)
Discovery:S3/MaliciousIPCaller.Custom	高	有(*1)
Discovery:S3/TorIPCaller	中	有(*1)
Exfiltration:S3/AnomalousBehavior	高	有(*1)
Exfiltration:S3/MaliciousIPCaller	高	有(*1)
Impact:S3/AnomalousBehavior.Delete	高	有(1,4)
Impact:S3/AnomalousBehavior.Permission	高	有(1,2,*3)
Impact:S3/AnomalousBehavior.Write	中	有(*1)
Impact:S3/MaliciousIPCaller	高	有(*1)
PenTest:S3/KaliLinux	中	有(*1)
PenTest:S3/ParrotLinux	中	有(*1)
PenTest:S3/PentooLinux	中	有(*1)
Policy:S3/AccountBlockPublicAccessDisabled	低	有(*2)
Policy:S3/BucketAnonymousAccessGranted	高	有(2,3)
Policy:S3/BucketBlockPublicAccessDisabled	低	有(*2)
Policy:S3/BucketPublicAccessGranted	高	有(*2)
Stealth:S3/ServerAccessLoggingDisabled	低	有(*2)
UnauthorizedAccess:S3/MaliciousIPCaller.Custom	高	有(*1)
UnauthorizedAccess:S3/TorIPCaller	高	有(*1)

*1: IAM 認証情報の削除, アクセス元 GIP の制限, MFA デバイス認証
*2: Security Hub、Config
*3: Access Analyzer
*4: SCP による操作禁止

② 役割分担整理

GD の運用中に発生する主なタスクは以下の 4 つになります。

ディテクターの初期セットアップ
検出結果の確認/対応
検出結果のフィルタリング（チューニング）
機能アップデートの取り込み

基本的にセキュリティ系のAWSサービスを有効化するのは基盤チームの役割となりますので、「1. ディテクターの初期セットアップ」や「4. 機能アップデートの取り込み」は基盤チームが担当することを想定します。
「2. 検出結果の確認/対応」や「3. 検出結果のフィルタリング（チューニング）」は、システムの設計を把握している人でないと対応が難しいため、システム担当側で対応することが多いかと思います。
GD 以外の AWS サービスの権限をどこまで委譲しているかによって役割分担を判断しましょう。