【札幌開催】 AWS re:Inforce 2025 振り返り勉強会にて「5分でわかる！GuardDuty 拡張脅威検出 EKS 編」というタイトルで登壇します！

こんにちは！クラウド事業本部コンサルティング部のたかくに（@takakuni_）です。

2025年07月01日に【札幌開催】AWS re:Inforce 2025 振り返り勉強会を行います。

https://classmethod.connpass.com/event/357714/

私は「5分でわかる！GuardDuty 拡張脅威検出 EKS 編」というタイトルで、登壇します！

（当日は 3 本話す想定なので、今日はそのうちの 1 つをご紹介します）

EKS の拡張脅威検出について

今回リリースされた EKS の拡張脅威検出機能は、EKS クラスター内で悪意のあるアクティビティが検出された際に、攻撃者が行った一連のアクションを連ねて脅威として表示する機能です。

ドキュメントによると、悪意のあるアクティビティは以下のようなケースを想定しています。

1. Amazon EKS クラスター内のコンテナアプリケーションを悪用しようとしている
2. 侵害されたコンテナを使用して、特権を持つサービスアカウントのトークン取得を試みる
3. 昇格された権限を利用して、ポッド ID を通じて機密の Kubernetes シークレットまたは AWS リソースにアクセス

https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-extended-threat-detection.html#extended-threat-detection-eks-clusters

連なって脅威を確認できる

拡張脅威検出は、攻撃者が行なった一連のアクティビティを横串で確認できる点です。時系列順に脅威を特定できるため、非常に便利な機能です。

以下のように、最新順や侵害されたリソースをまとめて確認できます。

データソース

続いて評価するデータソースです。EKS の拡張脅威検出機能は非常に多くのデータソースの相関関係を確認しながら検出を行います。

• EKS audit log events
• AWS CloudTrail data events for S3
• AWS CloudTrail management events
• VPC Flow Logs
• Route53 Resolver DNS query logs
• Amazon EKS malware detection for Amazon EC2
• Runtime Monitoring for Amazon EKS

https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-attack-sequence-finding-types.html#attack-sequence-eks-compromised-cluster

前提条件の中で EKS Protection または Runtime Monitoring（EKS アドオンを使用）のいずれか少なくとも 1 つの機能を有効にする必要があります。

GuardDuty correlated multiple security signals across EKS audit logs, runtime behavior of processes, and AWS API activity to detect sophisticated attack patterns. To benefit from Extended Threat Detection for EKS, you must enable at least one of these features – EKS Protection or Runtime Monitoring (with EKS add-on). EKS Protection monitors control plane activities through audit logs, while Runtime Monitoring observes behaviors within containers.

最大限の効果を活かしたい場合は、両方有効化が推奨されています。私個人としても、利用するのであれば、両方有効化しておくことをオススメします。

https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-extended-threat-detection.html#extended-threat-detection-eks-clusters

ログ周りについて

よくお問い合わせいただくので、あらためて振り返りますが、GuardDuty を利用するために EKS audit log や VPC Flowlog を有効にしていただく必要はありません。裏で GuardDuty が独自で収集しています。これもまた GuardDuty の Good ポイントだと私は思います。

いいえ。GuardDuty は、CloudTrail、VPC Flow Logs、DNS クエリログ、および Amazon EKS から独立したデータストリームを直接取得します。Amazon S3 バケットポリシーを管理したり、ログを収集して保存する方法を変更したりする必要はありません。GuardDuty のアクセス許可は、サービスにリンクされたロールとして管理されます。GuardDuty はいつでも無効にでき、その場合、すべての GuardDuty アクセス許可が削除されます。これにより、複雑な設定を回避できるため、サービスを有効にすることがより容易になります。また、サービスにリンクされたロールにより、AWS Identity and Access Management (IAM) アクセス許可の設定ミスや Amazon S3 バケットのポリシー変更がサービス運用に影響を与える可能性もなくなります。最後に、サービスにリンクしたロールにより、ほぼリアルタイムで大量のデータを消費する時に GuardDuty が非常に効率的に活用されるため、アカウントやワークロードのパフォーマンス、および可用性にほとんど影響を与えません。

https://aws.amazon.com/jp/guardduty/faqs/

まとめ

「【札幌開催】AWS re:Inforce 2025 振り返り勉強会にて 5分でわかる！GuardDuty 拡張脅威検出 EKS 編というタイトルで、登壇します！」でした。

まだまだ受付も行なっていますので、ぜひお越しいただけますと幸いです。

https://classmethod.connpass.com/event/357714/

クラウド事業本部コンサルティング部のたかくに（@takakuni_）でした！