みなさんこんにちは、杉金です。
Amazon GuardDutyのランタイムモニタリング機能が共有VPCに対応しました。
ランタイムモニタリング機能って何だっけ
OSレベルのイベントを監視して脅威を検出するGuardDutyの機能です。以前はAmazon EKSのみサポートされていましたが、昨年12月のre:Invent2023でAmazon ECSやEC2にも対応しました。
本記事の執筆時点でもEC2の方はまだプレビュー版のようです。（以下、GuardDutyのランタイムモニタリングの設定画面より）
共有VPCって何だっけ
複数のAWSアカウントでEC2やRDSなどのリソースを同一VPC上で実行するための機能です。いろいろと制約や条件があります。ポイントをかいつまむと以下です。
- 共有するリソースとして指定するのはVPCではなくサブネット
- 組織内のAWSアカウントでしか共有できない（組織外アカウントへのサブネット共有は不可）
- ひとつまたは複数のサブネットを共有できる
やってみる
EC2でのランタイムモニタリングを例に今回の機能を試してみます。以下、設定の概要図です。
登場人物として、AWS Organizations（組織）内に4つのAWSアカウントがいます。
- 管理アカウント（Organizationsにおける親玉アカウント）
- 監査アカウント（組織内のGuardDutyを管理）
- アカウントA（VPCを共有する側）
- アカウントB（VPCを共有される側）
設定1〜2までは本機能の前提条件ではありません。監査アカウントが組織全体のGuardDutyを統制している例として構成しました。
先ほど掲載した共有VPCのユーザーガイドでは、共有する側を所有者、共有される側を参加者と呼んでいます。今回はひとつのアカウントに対して共有していますが、複数アカウントへの共有も可能です。サブネットの共有はRAM（Resource Access Manager）で設定します。
前提条件、考慮事項
共有VPCを利用した環境でのラインタイムモニタリングについて、ユーザーガイドに前提条件と考慮事項について記載があります。設定する際は一読ください。
今回説明する環境ではAWS Organizationsを有効にしてAWSアカウントを作成し、上記概要図の設定2が完了した状態からスタートしています。以降の設定と動作確認まで解説していきます。
VPC（サブネット）の共有
まずアカウントAでサブネットの共有を行います。RAMの[リソースの共有]から[リソース共有を作成]を選びます。
リソース共有の名前を決め、共有するリソースとしてサブネットを選び、共有したいサブネットを選びます。
タグや権限などを設定していき、次は共有先を指定します。今回はアカウントBのアカウントIDを指定します。プリンシパルタイプを選択することで組織全体やOU単位でのリソース共有も可能です。
エンドポイントの作成
アカウントAでランタイムモニタリング用のVPCエンドポイントを作成します。サービス名はguardduty-dataです。
EC2インスタンスの起動とエージェント導入
アカウントBで操作します。VPCのサブネット一覧に共有されたサブネットが追加されていることが分かります。Nameタグは引き継がれず空欄になっており、サブネットの共有タブから共有リソースであることを確認できます。
共有されたサブネットを指定してEC2インスタンスを起動します（スクショは割愛）。今回はAmazon Linux2を選択しました。サポートされているOSやリソース制限については以下のリンクを参照ください。
プレビュー版であるEC2は手動でランタイムモニタリング用のエージェントを導入します。
Systems Managerのドキュメントからrun commandを通じて対象のEC2インスタンスを選びインストールを実行します。
ドキュメント名：AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin
動作確認
エージェントの導入まで終えると監査アカウントのGuardDuty→[ランタイムモニタリング]→[ランタイムカバレッジ]タブからインスタンスを認識していることが分かります。ここで表示されているAWSアカウントIDはマスクしていますが、アカウントB上で起動したEC2インスタンスであるため、アカウントBのものが表示されます。
何らかの原因で通信が確立されていない場合、Unhealthyとして表示されます。（下記の画像例はエンドポイントが存在しない場合のスクショ）
EC2からテスト用のドメインにクエリを投げて検知するか確認します。
監査アカウントおよびアカウントBのGuardDutyで検知していることを確認しました。
今回のケースではアカウントAのGuardDutyでは検知していませんでした。EC2の所有アカウントがアカウントBであったためと考えられますが、検出される脅威によってはアカウントAでも何かしら検知される可能性はありそうです。
料金について
GuardDutyと共有VPCの2つの面から利用料が決まります。詳細は料金に関するページをご確認ください。
GuardDutyの料金
共有VPCコスト：VPCリソースを管理する→所有者と参加者の請求と計測
補足情報
補足1：よくある質問集のページがあるよ
共有VPC環境でのランタイムモニタリングについて、専用のFAQページが用意されています。
今回はEC2を例に手動でエンドポイントの作成やエージェントの導入をしました。自動でエージェントを構成するEKSやECSの場合についての解説ページも用意されています。
補足2：共有するサブネットを増減させたいとき
共有するサブネットを増やしたい場合はRAMから設定変更する、もしくはVPCコンソールの[サブネット]から設定できます。
作成したRAMのリソース共有名が表示されるので選択します。これで共有するサブネットがひとつ増えます。
こんどは反対に共有を停止する場合、サブネットの[共有]タブから共有を停止できます。
AWS CLIから設定する場合は以下を参考にしてください。
補足3：エンドポイントの作成について
エンドポイントの作成について2つ補足情報があります。ひとつは、エンドポイントのセキュリティグループを割り当てるときにアカウントBが所有しているセキュリティグループを指定しようとすると以下のエラーとなり、エンドポイント作成に失敗します。解決策として自己所有（アカウントA）のセキュリティグループを選択します。
You are not authorized to perform CreateNetworkInterface operation. A subnet in this vpc is shared but the provided object is not owned by you
もうひとつは、アカウントBからはVPCエンドポイントを作成できません。以下のエラーになります。
This operation does not support shared VPCs.
これはVPCエンドポイントの制約によるものです。
You can't create, describe, modify, or delete VPC endpoints in subnets that are shared with you. However, you can use the VPC endpoints in subnets that are shared with you.
さいごに
共有VPCを利用したGuardDutyのランタイムモニタリングを試してみました。すでに共有VPCを使っている方やこれから共有VPCを使おうとしている方にとっては嬉しいアップデートではないでしょうか。ランタイムモニタリングをEC2で行う場合は、手動でエンドポイント作成やエージェントのインストールを行います。プレビュー版から正式リリースした際には自動で設定してくれることを期待したいですね。
0
