GuardDuty各Protection機能について整理してみた

はじめに

GuardDutyはみなさん使われていることかと思います。
本記事ではGuardDuty基本機能ではなく、各Protection機能について調査する機会がありましたのでせっかくですので記事として残したいと思います。
セキュリティが向上するみたいだけど具体的になにができるのかといった事を説明します。
どれも少し調査すれば分かることですがひとつにまとめた記事があればより理解が進むと考え執筆しました。

そもそもGuardDutyとは

AWS CloudTrail 管理イベント、AWS CloudTrail イベントログ、(Amazon EC2 インスタンスからの) VPC フローログ、DNS ログ、などの 基礎データソース を分析して処理するセキュリティモニタリングサービスです。
また、Kubernetes 監査ログ、RDS ログインアクティビティ、S3 ログ、EBS ボリューム、ランタイムモニタリング、Lambda ネットワークアクティビティログなどの機能も処理します。

Amazon GuardDuty ユーザーガイドの説明がわかりやすいのでそのまま引用します。
引用：Amazon GuardDuty ユーザーガイド
（https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/what-is-guardduty.html）

本記事で説明する部分

上述されている内の後半部分についてが本記事の対象となります。
具体的には以下サービスのことについて記載をしております。

導入

まず認識していただきたいのは、いずれも発見的統制に役立つものとなります。
つまり事後的に脅威検出を行いどう対応していくのかを考える時の脅威検出部分に役立てることができます。

予防的統制として仕組みづくりを検討したい場合には、アクセス経路を最小限に絞る、不必要な権限を与えないなどといった基本的なセキュリティフレームワークに準拠しつつ、それでも足りないと判断する場合にはサードパーティ製のソフトウェア導入で検討していく必要があります。

GuardDuty Malware Protectionとは

Malware Protection は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスおよびコンテナワークロードにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリュームをスキャンすることで、マルウェアの潜在的な存在を検出することに役立ちます。

まずマルウェア対策における発見的統制として効果的なサービスとなります。
対象サービスは、EC2とECSとなりますがECSにおいてFagateは対象外となります。
そもそもマネージドサービスであるFargate実行環境はAWS責任範囲となりますのでユーザー側でどうこうできるものでもありません。
※データ部分に悪意のあるプログラムファイルがないかどうかはユーザー責任で管理検討する必要あります

またスキャン実行については二つのタイプから選択できます。

1. GuardDuty 実行型マルウェアスキャン
GuardDuty が Amazon EC2 インスタンスまたはコンテナワークロードにマルウェアの潜在的な存在を示す検出結果を生成するたびに、GuardDuty が影響を受けた可能性のあるリソースにアタッチされた Amazon EBS ボリュームにエージェントレスマルウェアスキャンを自動的に開始

2. オンデマンドのマルウェアスキャン
Amazon EC2 インスタンスまたはコンテナワークロードに関連付けされた Amazon リソースネーム (ARN) を指定することで、オンデマンドのマルウェアスキャンを開始

前者はまさにマルウェアっぽいふるまいを検知した時に、対象EBSボリュームをスキャンする動きとなります。
簡単に導入できるので利用する場合はほぼほぼこちらかと思います。
後者はオンデマンドスキャン継続的実行の仕組みがつくれれば予防的統制に役立つと思われます。

最後に次回スキャンタイミングまでのインターバルには気をつけましょう。

1. GuardDuty 実行型マルウェアスキャン
自動マルウェアスキャンが 24 時間に 1 回開始

2. オンデマンドのマルウェアスキャン
前回のスキャンの開始時刻から 1 時間後に、同じリソースにオンデマンドのマルウェアスキャンを開始できる

GuardDuty EKS Protectionとは

EKS Protection は、脅威検出の範囲を提供し、AWS 環境内の Amazon EKS クラスターを保護するのに役立ちます。
EKS Protection には、EKS 監査ログのモニタリングと EKS Runtime Monitoring が含まれます。

こちらもEKS 監査ログとEKS Runtime Monitoringから疑わしいアクティビティがあった場合に検知する機能です。
特にEKS Runtime Monitoringをソースとする場合にはGuardDuty セキュリティエージェントとも呼ばれる新しい EKS アドオン aws-guardduty-agent が必要となります。
これによりEKS クラスターのランタイム動作を分析することで、セキュリティ脅威を検出するのに役立ちます。

まとめると
監査ログは、ユーザー、Kubernetes API を使用するアプリケーション、コントロールプレーンからのアクティビティなど
Runtime Monitoringは、ファイルアクセス、プロセス実行、ネットワーク接続など、個々の EKS ワークロードランタイム
どの部分の動きについて脅威検出するのかの違いがありますので、要件と照らし合わせて利用しましょう。

GuardDuty S3 Protectionとは

S3 Protection は S3 バケット内のデータの潜在的なセキュリティリスクを特定するために、オブジェクトレベルの API オペレーションを Amazon GuardDuty がモニタリングする機能を有効にします。

CloudTrail 管理イベントとCloudTrail S3 データイベントをデータソースにして例えば、悪意のあるバケット公開設定や脅威のあるIPアドレスからオブジェクトへのアクセスがあった場合に検知することができます。

もちろん本機能の利用には、CloudTrail S3 データイベントを有効化する必要があります。
デフォルトでは有効となっておりませんのでご注意ください。

GuardDuty RDS Protectionとは

RDS Protection は、RDS ログインアクティビティを分析してプロファイリングし、Amazon Aurora データベース (Amazon Aurora MySQL 互換エディションおよび Aurora PostgreSQL 互換エディション) への潜在的なアクセス脅威がないかどうかを調べます。この機能により、潜在的に疑わしいログイン動作を特定できます。

潜在的に疑わしいログイン試行または異常なログイン試行があった場合に検知することができます。
またRDS Protection 機能を有効にすると、GuardDuty は直ちにアカウントにある Aurora データベースの RDS ログインアクティビティのモニタリングを開始します。
なのでこの機能の他に有効にしなければならないものはありませんので導入はとても簡単です。

注意点としては、通常の動作をベースラインにするための学習期間が必要となります。
最長で 2 週間程度、関連する異常ログインが検出されないことがあります。

GuardDuty Lambda Protectionとは

Lambda Protection は、AWS 環境内で AWS Lambda 関数が呼び出されたときに潜在的なセキュリティ脅威を特定するのに役立ちます。Lambda Protection を有効にすると、GuardDuty は Lambda ネットワークアクティビティログのモニタリングを開始します。これには VPC ネットワークを使用しないログも含め、アカウントのすべての LambdaVPC Flow Logs 関数から開始され、Lambda 関数が呼び出されたときに生成されます。GuardDuty が Lambda 関数に潜在的に悪意のあるコードが存在することを示す疑わしいネットワークトラフィックを特定した場合、GuardDuty は検出結果を生成します。

悪意のあるコードが存在することを示す疑わしいネットワークトラフィックを特定した場合に検知することができます。
またLambda Protection を有効にすると、GuardDuty は Lambda ネットワークアクティビティログのモニタリングを開始します。
なのでこの機能の他に有効にしなければならないものはありませんので導入はとても簡単です。

その他機能と同様ですが、悪意のあるコードそのものの脅威検出ができる訳でなく、ネットワークアクティビティという振る舞いに対して脅威検出をするものになります。

まとめ

以上でGuardDuty各Protection機能についての理解度があがりましたでしょうか。

私の場合、調査前はセキュリティ関連のサービスということで予防的な機能が働くものかと先入観をもっておりました。
しかし調査をする中で、侵害があった場合の検知ができるサービスであるということを理解しました。
これらのサービスをうまく使いつつ、ワークロード自体はAWS Well-Architected等を利用しセキュリティのベスプラを遵守する必要があるなと改めて認識しました。

以上、最後までご覧いただきありがとうございました。