セキュリティサービス部 佐竹です。
本ブログは、Amazon GuardDuty の Runtime Monitoring に関する設定において、EC2 インスタンスへの GuardDuty Security Agent（セキュリティエージェント）がどのような条件で自動インストールされるのか、その挙動を整理したので備忘として記述しています。
- はじめに
- 前提条件として SSM Agent のインストールが必須
- GuardDuty Security Agent on EC2 の自動インストール条件の整理
- 補足事項
- AWS 公式ドキュメント
- まとめ
はじめに
Amazon GuardDuty の Runtime Monitoring（ランタイムモニタリング）を有効化すると、EC2 インスタンス内部のプロセス挙動も検知/検出ができるようになります。しかし、これには GuardDuty Security Agent のインストールが必須となります。
そして、本エージェントのインストール方法は「自動」と「手動」があります。
基本的には「自動」としたいのですが、包含タグおよび除外タグ含めて色々と機能的な動作仕様があります。AWS アカウント全体の設定と、個別のタグ設定が組み合わさった時、「結局インストールされるのか？されないのか？」がわかりにくいと感じましたので、今回は条件を整理して一覧化しました。
AWS Security Hub CSPM の対応として
なお、以下のコントロールを Passed (成功) とするには、自動エージェント設定も有効にする必要があります。
- [GuardDuty.7] GuardDuty EKS ランタイムモニタリングを有効にする必要があります
- [GuardDuty.12] GuardDuty ECS ランタイムモニタリングを有効にする必要があります
- [GuardDuty.13] GuardDuty EC2 ランタイムモニタリングを有効にする必要があります
(引用) マルチアカウント環境では、委任 GuardDuty 管理者アカウントとすべてのメンバーアカウントに自動エージェント管理が有効になっている EKS Runtime Monitoring がない場合、コントロールは失敗します。
このため、本コントロールのクリアを目的として「自動」と設定する場面もあるでしょう。
前提条件として SSM Agent のインストールが必須
設定の組み合わせの話に入る前に、そもそもの前提を整理しておきます。
GuardDuty の「自動エージェント設定（Automated agent configuration）」は、実装としては AWS Systems Manager (SSM) を利用しています。Amazon Inspector のプラグインのような実装と基本的には同じということです。
このため、GuardDuty のアカウントの設定で「自動インストール」を有効化したとしても、対象の EC2 インスタンスが Systems Manager の管理下になければ、エージェントはインストールされません。
- EC2 に SSM Agent がインストールされていること
- EC2 に適切な IAM ロールがアタッチされていること
- EC2 がネットワーク経路として SSM エンドポイントへ到達可能であること
これらが満たされていないと、以下の表の条件に関わらず GuardDuty Security Agent の自動インストールは実行されません。
なお、現在は「SSM のデフォルトホスト管理設定」を利用すれば、EC2 インスタンスへの IAM ロールのアタッチは必須ではありません。
ただ「デフォルトホスト管理設定」には注意点もありますので、もし利用されたい場合は上記ブログも合わせてご覧ください。
GuardDuty Security Agent on EC2 の自動インストール条件の整理
本題の「設定とタグの組み合わせによる挙動」の一覧です。
GuardDuty のアカウント単位の設定と、EC2 インスタンス個別の GuardDutyManaged タグの組み合わせを表にまとめました。
| 自動エージェント設定 | GuardDutyManaged: | エージェントの自動インストール |
|---|---|---|
| 有効 | true | インストールされる |
| 有効 | タグ付与なし | インストールされる |
| 有効 | false | インストールされない (除外タグが優先され対象外となる) |
| 無効 | true | インストールされる (包含タグにより個別にインストールされる) |
| 無効 | タグ付与なし | インストールされない |
| 無効 | false | インストールされない |
1. アカウント単位の自動インストールを除外したい場合
アカウントの GuardDuty 自動エージェント設定で「有効 (Enabled)」としている場合、基本的には （組織の）アカウント内の全 EC2 インスタンス に GuardDuty Security Agent がインストールされます。
ただし、特定のインスタンス（例えば、サードパーティ製品のアプライアンスなど、セキュリティエージェントを入れたくないもの）がある場合は、EC2 側にタグ GuardDutyManaged: false を付与することで、除外（Exclusion） することが可能です。これが「除外タグ (exclusion tag) 」です。
なおタグは大文字小文字を区別するため、付与時に注意してください。念のため一覧表でも小文字にしています。
2. 特定のインスタンスにのみ自動インストールしたい場合
アカウント全体としては自動インストールを「無効」にしておきながら、特定の EC2 インスタンスだけにタグ GuardDutyManaged: true を付与することで、そのインスタンスだけピンポイントでインストールさせる ことが可能です。これが「包含タグ (inclusion tag)」です。
これは「全台に導入するとコストが心配だが、重要なサーバーだけは監視したい」といったスモールスタートのシナリオで有効です。
補足事項
ランタイムモニタリングの利用料金について
ここで念のための補足ですが、GuardDuty ランタイムモニタリングは「30日間の無料トライアル」が用意されているものの「有償の追加機能」です。以下の料金表の通り、「EC2 ランタイムモニタリング」は「vCPU あたり USD 2.00」から費用が発生する点に注意してください。
この費用は「最初の 500 個の vCPU /月 (監視対象のインスタンス)」の金額です。この費用の前提であれば、large サイズの EC2 インスタンスだと v コアが2つですので、1台で月額 $4.0 になる計算です。
除外タグは「アンインストール」ではない
少々運用上の補足です。除外タグは「アンインストール」ではない点に注意が必要でしょう。
GuardDutyManaged: false タグは、あくまで 「セキュリティエージェントのインストール処理を除外する」 ためのものです。
既にエージェントが自動インストールされてしまった後に、GuardDutyManaged: false タグを付与しても、既にインストールされたセキュリティエージェントは自動的にはアンインストールされません。
よって「セキュリティエージェントをインストールさせたくないインスタンス」がある場合は、以下のいずれかの対応が必要です。
- 構築時にタグを付与する:
Terraform や CloudFormation 等で EC2 を構築する時点で、タグにGuardDutyManaged: falseを含めておく。 - 手動でアンインストールする:
既にセキュリティエージェントがインストールされてしまった場合には、手動（SSM Run Command）でアンインストールを行う。
なお、SSM の Run Command では AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin が Uninstall でも利用可能です。
VPC Endpoint が自動的に構築されるという仕様について
GuardDuty ランタイムモニタリングを利用する場合、以下のドキュメントの通り自動的に VPC Endpoint が作成されます。
GuardDuty は、VPC 内に終了またはシャットダウンされたインスタンス状態にない Linux EC2 インスタンスが少なくとも 1 つある限り、共有 VPC を含むすべての VPC に VPC エンドポイントを作成します。
ですが「VPC エンドポイントの使用に追加コストはかかりません。」と注記に合わせて記載してある通り、ランタイムモニタリングが利用する VPC Endpoint に追加の費用は発生しません*1。
AWS 公式ドキュメント
本ブログは以下の公式ドキュメントを情報ソースとして整理、記述しました。
GuardDuty Runtime Monitoring
Amazon EC2 インスタンスでの Runtime Monitoring の仕組み
セキュリティエージェントの手動インストール
まとめ
本ブログでは、GuardDuty Runtime Monitoring を利用する際に重要となる、GuardDuty Security Agent の自動インストール条件について整理しました。
- 前提: EC2 が SSM 管理下（Managed Instance）であること
- 基本: アカウント設定「有効」なら全台にインストールされる
- 除外:
GuardDutyManaged: falseタグでインストール対象から除外が可能 - 個別: アカウント設定「無効」でも、
GuardDutyManaged: trueタグで個別インストールが可能
なお、GuardDuty の Runtime Monitoring は有償機能であるため、（セキュリティが重要であることに間違いはありませんが）コスト管理の観点では「いきなり全台に導入」とすると予想以上の高コストに繋がる可能性があります。
AWS Security Hub CSPM のスコア向上だけを目的に安易に全台有効化とはせず、本マトリクスを参考に、計画的または段階的に導入することをお勧めします。
では、またお会いしましょう。
*1:以前動作検証をしていたとき、VPC が消せなくてなんだろうと思っていたらこの VPC Endpoint がブロックしていた、という経験があります
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
