翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 仕組み Runtime Monitoring を使用するには、Runtime Monitoring を有効にしてから GuardDuty セキュリティエージェントを管理する必要があります。以下のリストでこの 2 つの手順を説明しています。 1. アカウントの「**Runtime Monitoring を有効化**」して、GuardDuty が Amazon EC2 インスタンス、Amazon ECS クラスター、Amazon EKS ワークロードから受信するランタイムイベントを受け入れることができるようにします。 1. ランタイムのアクティビティを監視したい個々のリソースの「**GuardDuty エージェントを管理**」します。リソースタイプに基づいて、以下を選択できます。 + 自動エージェント設定を使用すると、GuardDuty がエージェントのデプロイを管理し、Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを自動的に作成します。 + エージェントを手動でインストールします。前提条件として VPC エンドポイントを作成する必要があります。 セキュリティエージェントは VPC エンドポイントを使用して GuardDuty にイベントを配信し、データが AWS ネットワーク内に留まるようにします。このアプローチはセキュリティを強化し、GuardDuty がリソース (Amazon EKS、Amazon EC2、 AWS Fargateおよび Amazon ECS) 全体のランタイム動作をモニタリングおよび分析できるようにします。GuardDuty は、各リソースタイプのセキュリティエージェントを認証する[インスタンス ID ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#ec2-instance-identity-roles)を使用して、関連するランタイムイベントを VPC エンドポイントに送信します。 **注記** GuardDuty では、ランタイムイベントにはアクセスできません。 EKS Runtime Monitoring または Runtime Monitoring for EC2 インスタンスで (手動または GuardDuty を介して) セキュリティエージェントを管理し、GuardDuty が現在 Amazon EC2 インスタンスにデプロイされ、このインスタンス[収集されたランタイムイベントタイプ](runtime-monitoring-collected-events.md)から を受け取る場合、GuardDuty はこの Amazon EC2 インスタンスからの VPC フローログの分析 AWS アカウント に対して に課金しません。これにより、GuardDuty はアカウントでの二重課金を回避できます。 以下のトピックでは、Runtime Monitoring の有効化と GuardDuty セキュリティエージェントの管理がリソースタイプごとにどのように異なるかを説明します。 **Topics** + [Amazon EKS クラスターでの Runtime Monitoring の仕組み](how-runtime-monitoring-works-eks.md) + [Amazon EC2 インスタンスでの Runtime Monitoring の仕組み](how-runtime-monitoring-works-ec2.md) + [Fargate での Runtime Monitoring の仕組み (Amazon ECS のみ)](how-runtime-monitoring-works-ecs-fargate.md) + [Runtime Monitoring を有効にした後](runtime-monitoring-after-configuration.md) # Amazon EKS クラスターでの Runtime Monitoring の仕組み Runtime Monitoring は、GuardDuty セキュリティエージェントとも呼ばれる「[EKS アドオン `aws-guardduty-agent`](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#workloads-add-ons-available-eks)」を使用します。GuardDuty が EKS クラスターにデプロイされると、GuardDuty セキュリティエージェントはこれらの EKS クラスターのランタイムイベントを受信できます。 **注意事項** Runtime Monitoring は、Amazon EC2 インスタンスと Amazon EKS Auto Mode で実行されている Amazon EKS クラスターを**サポートします**。 Runtime Monitoring は、Amazon EKS Hybrid Nodes を使用する Amazon EKS クラスター、および AWS Fargateで実行されているクラスターを**サポートしていません**。 これらの Amazon EKS の詳細については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS とは](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)」を参照してください。 この機能は、Amazon EKS クラスターのランタイムイベントをアカウントレベルまたはクラスターレベルで監視できます。GuardDuty セキュリティエージェントを管理できるのは、監視して脅威を検出したい Amazon EKS クラスターに対してのみです。GuardDuty セキュリティエージェントは、手動で管理することも、自動エージェント設定を使用してユーザーに代わって GuardDuty に管理させることもできます。 自動エージェント設定アプローチを使用して、GuardDuty がユーザーに代わってセキュリティエージェントのデプロイを管理できるようにすると、自動的に **Amazon Virtual Private Cloud (Amazon VPC) エンドポイントが作成**されます。セキュリティエージェントは、この Amazon VPC エンドポイントを使用してランタイムイベントを GuardDuty に配信します。 VPC エンドポイントと共に、GuardDuty は新しいセキュリティグループも作成します。インバウンド (Ingress) ルールは、セキュリティグループに関連付けられたリソースに到達することが許可されたトラフィックを制御します。GuardDuty は、リソースの VPC CIDR 範囲に一致するインバウンドルールを追加し、CIDR 範囲が変更されたときにそれに適応します。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC CIDR range](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)」を参照してください。 **注意事項** VPC エンドポイントの使用に追加コストはかかりません。 自動エージェントによる一元化された VPC の使用 – リソースタイプに GuardDuty 自動エージェント設定を使用する場合、GuardDuty はすべての VPC に対してユーザーに代わって VPC エンドポイントを作成します。これには、一元化された VPC とスポーク VPC が含まれます。GuardDuty は、一元化された VPC のみの VPC エンドポイントの作成をサポートしていません。一元化された VPC の仕組みの詳細については、ホワイトペーパーの[「インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) - スケーラブルで安全なマルチ VPC ネットワークインフラストラクチャの構築」を参照してください。 *AWS AWS * ## Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ 2023 年 9 月 13 日より前は、セキュリティエージェントをアカウントレベルで管理するように GuardDuty を設定できました。つまり、デフォルトでは GuardDuty が、 AWS アカウントに属するすべての EKS クラスター上のセキュリティエージェントを管理していました。現在は、GuardDuty でセキュリティエージェントを管理する EKS クラスターについて、きめ細かな選択機能が提供されています。 「[GuardDuty セキュリティエージェントの手動管理](#eks-runtime-using-gdu-agent-manually)」を選択した場合も、モニタリングする EKS クラスターを選択できます。ただし、エージェントを手動で管理するには、 の Amazon VPC エンドポイントを作成することが前提条件 AWS アカウント です。 **注記** GuardDuty セキュリティエージェントの管理に使用するアプローチに関係なく、EKS Runtime Monitoring は常にアカウントレベルで有効になります。 **Topics** + [GuardDuty によるセキュリティエージェントの管理](#eks-runtime-using-gdu-agent-management-auto) + [GuardDuty セキュリティエージェントの手動管理](#eks-runtime-using-gdu-agent-manually) ### GuardDuty によるセキュリティエージェントの管理 GuardDuty は、ユーザーに代わってセキュリティエージェントをデプロイおよび管理します。次のいずれかのアプローチを使用して、アカウント内の EKS クラスターをいつでもモニタリングできます。 **Topics** + [すべての EKS クラスターをモニタリングする](#gdu-security-agent-all-eks-custers) + [選択的な EKS クラスターを除外する](#eks-runtime-using-exclusion-tags) + [選択的な EKS クラスターを含める](#eks-runtime-using-inclusion-tags) #### すべての EKS クラスターをモニタリングする アカウント内のすべての EKS クラスターのセキュリティエージェントを GuardDuty でデプロイおよび管理する場合は、このアプローチを使用します。デフォルトでは、GuardDuty はアカウント内で作成される可能性のある新しい EKS クラスターにもセキュリティエージェントをデプロイします。 **このアプローチを使用した場合の影響** + GuardDuty が Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを作成します。GuardDuty セキュリティエージェントは、このエンドポイントを通じてランタイムイベントを GuardDuty に配信します。GuardDuty を使用してセキュリティエージェントを管理する場合、Amazon VPC エンドポイントの作成に追加コストはかかりません。 + ワーカーノードにアクティブな `guardduty-data` VPC エンドポイントへの有効なネットワークパスが必要です。GuardDuty が EKS クラスターにセキュリティエージェントをデプロイします。Amazon Elastic Kubernetes Service (Amazon EKS) が、EKS クラスター内のノードでのセキュリティエージェントのデプロイを調整します。 + GuardDuty は IP の可用性に基づいてサブネットを選択し、VPC エンドポイントを作成します。高度なネットワークトポロジを使用する場合は、接続が可能であることを検証する必要があります。 #### 選択的な EKS クラスターを除外する GuardDuty でアカウント内のすべての EKS クラスターのセキュリティエージェントを管理し、選択的な EKS クラスターを除外する場合は、このアプローチを使用します。この方法では、ランタイムイベントを受信しない EKS クラスターにタグを付けることができる、タグベース[1](#eks-runtime-inclusion-exclusion-tags)のアプローチを使用します。事前定義されたタグには、キーと値のペアとして `GuardDutyManaged`-`false` が必要です。 **このアプローチを使用した場合の影響** このアプローチでは、モニタリングから除外する EKS クラスターにタグを追加してから、GuardDuty エージェントの自動管理を有効にする必要があります。 そのため、「[GuardDuty によるセキュリティエージェントの管理](#eks-runtime-using-gdu-agent-management-auto)」の場合の影響がこのアプローチにも適用されます。GuardDuty エージェントの自動管理を有効にする前にタグを追加すると、GuardDuty はモニタリングから除外された EKS クラスターのセキュリティエージェントのデプロイと管理を行いません。 **考慮事項** + GuardDuty エージェントの自動管理を有効にする前に、選択する EKS クラスターのタグのキーと値のペアを `GuardDutyManaged`:`false` として追加する必要があります。追加しない場合、タグを使用するまで GuardDuty セキュリティエージェントがすべての EKS クラスターにデプロイされます。 + 信頼できる ID 以外により、タグが変更されないようにする必要があります。 **重要** サービスコントロールポリシーまたは IAM ポリシーを使用して、EKS クラスターの `GuardDutyManaged` タグの値を変更する権限を管理します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」または「*IAM ユーザーガイド*」の「[AWS のリソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)」を参照してください。 + モニタリングする必要のない、潜在的な新しい EKS クラスターについては、その EKS クラスターの作成時に必ず `GuardDutyManaged`-`false` のキーと値のペアを追加してください。 + このアプローチには、「[すべての EKS クラスターをモニタリングする](#gdu-security-agent-all-eks-custers)」で指定されているものと同じ考慮事項があります。 #### 選択的な EKS クラスターを含める アカウント内の選択的な EKS クラスターに対してのみ、GuardDuty でセキュリティエージェントのデプロイと更新の管理を行う場合は、このアプローチを使用します。この方法では、ランタイムイベントを受信する EKS クラスターにタグを付けることができる、タグベース[1](#eks-runtime-inclusion-exclusion-tags)のアプローチを使用します。 **このアプローチを使用した場合の影響** + 包含タグを使用することで、GuardDuty は、キーバリューのペアとして `GuardDutyManaged`-`true` でタグ付けされた選択する EKS クラスターに対してのみ、セキュリティエージェントを自動的にデプロイおよび管理します。 + このアプローチを使用した場合も、「[すべての EKS クラスターをモニタリングする](#gdu-security-agent-all-eks-custers)」で指定されているものと同じ影響があります。 **考慮事項** + `GuardDutyManaged` タグの値が `true` に設定されていないと、包含タグが期待どおりに機能せず、EKS クラスターのモニタリングに影響する可能性があります。 + 選択的な EKS クラスターを確実にモニタリングするには、信頼できる ID 以外によりタグが変更されないようにする必要があります。 **重要** サービスコントロールポリシーまたは IAM ポリシーを使用して、EKS クラスターの `GuardDutyManaged` タグの値を変更する権限を管理します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」または「*IAM ユーザーガイド*」の「[AWS のリソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)」を参照してください。 + モニタリングする必要のない、潜在的な新しい EKS クラスターについては、その EKS クラスターの作成時に必ず `GuardDutyManaged`-`false` のキーと値のペアを追加してください。 + このアプローチには、「[すべての EKS クラスターをモニタリングする](#gdu-security-agent-all-eks-custers)」で指定されているものと同じ考慮事項があります。 1 選択的な EKS クラスターのタグ付けの詳細については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS リソースのタグ付け](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html)」を参照してください。 ### GuardDuty セキュリティエージェントの手動管理 すべての EKS クラスターで GuardDuty セキュリティエージェントを手動でデプロイおよび管理する場合は、このアプローチを使用します。アカウントで EKS Runtime Monitoring が有効になっていることを確認してください。EKS Runtime Monitoring を有効にしないと、GuardDuty セキュリティエージェントが期待どおりに動作しないことがあります。 **このアプローチを使用した場合の影響** EKS クラスター内の GuardDuty セキュリティエージェントのデプロイを、すべてのアカウントおよびこの機能が利用可能な AWS リージョン 場所で調整する必要があります。また、GuardDuty がエージェントバージョンをリリースしたときに、エージェントバージョンを更新する必要があります。EKS のエージェントバージョンの詳細については、「[Amazon EKS リソースの GuardDuty セキュリティエージェントバージョン](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)」を参照してください。 **考慮事項** 新しいクラスターやワークロードが継続的にデプロイされるにつれて、カバレッジのギャップをモニタリングして対処しながら、安全なデータフローをサポートする必要があります。 # Amazon EC2 インスタンスでの Runtime Monitoring の仕組み Amazon EC2 インスタンスは、 AWS 環境内のさまざまなタイプのアプリケーションやワークロードを実行できます。Runtime Monitoring を有効にして GuardDuty セキュリティエージェントを管理すると、GuardDuty は既存の Amazon EC2 インスタンスと潜在的な新しい Amazon EC2 インスタンスの脅威を検出するのに役立ちます。この機能は、Amazon ECS によって管理される Amazon EC2 インスタンスもサポートしています。詳細については、[「Guardduty でのマネージドインスタンスのサポート](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_managed-instances.html)」を参照してください。 **注記** Runtime Monitoring は、[Amazon ECS マネージドインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html)で実行されているアプリケーションをサポートしていません。 Runtime Monitoring を有効にすると、GuardDuty は Amazon EC2 インスタンス内の現在実行中のプロセスや新しいプロセスからのランタイムイベントを利用できるようになります。GuardDuty では、EC2 インスタンスから GuardDuty にランタイムイベントを送信するセキュリティエージェントが必要です。 Amazon EC2 インスタンスの場合、GuardDuty セキュリティエージェントはインスタンスレベルで動作します。アカウント内のすべての Amazon EC2 インスタンスまたは選択的な Amazon EC2 インスタンスをモニタリングするかどうかを決定できます。選択的なインスタンスを管理する場合は、これらのインスタンスにのみセキュリティエージェントが必要です。 GuardDuty は、Amazon ECS クラスター内の Amazon EC2 インスタンスで実行されている新しいタスクや既存のタスクからのランタイムイベントを消費することもできます。 GuardDuty セキュリティエージェントをインストールするために、Runtime Monitoring には次の 2 つのオプションがあります。 + 「[自動エージェント設定を使用する (推奨)](#use-automated-agent-config-ec2)」または + [セキュリティエージェントの手動管理](#ec2-security-agent-option2-manual) ## GuardDuty による自動エージェント設定を使用する (推奨) GuardDuty がユーザーに代わって Amazon EC2 インスタンスにセキュリティエージェントをインストールできるようにする自動エージェント設定を使用します。GuardDuty は、セキュリティエージェントの更新も管理します。 デフォルトでは、GuardDuty はアカウント内のすべてのインスタンスにセキュリティエージェントをインストールします。GuardDuty で選択した EC2 インスタンスのみのセキュリティエージェントをインストールおよび管理する場合は、必要に応じて EC2 インスタンスに包含タグまたは除外タグを追加します。 アカウントに属するすべての Amazon EC2 インスタンスのランタイムイベントをモニタリングしたくない場合があります。限られた数のインスタンスのランタイムイベントをモニタリングする場合は、選択したインスタンスに包含タグを `GuardDutyManaged`:`true` として追加します。Amazon EC2 の自動エージェント設定が利用可能になったことから、EC2 インスタンスに包含タグ (`GuardDutyManaged`:`true`) がある場合、GuardDuty は自動エージェント設定を明示的に有効にしない場合でも、タグを優先し、選択したインスタンスのセキュリティエージェントを管理します。 一方、ランタイムイベントをモニタリングしたくない EC2 インスタンスが限られている場合は、選択したインスタンスに除外タグ (`GuardDutyManaged`:`false`) を追加します。GuardDuty は除外タグを優先し、それらの EC2 リソースに対してセキュリティエージェントのインストール**または**管理を**行いません**。 ### Impact AWS アカウント または組織で自動エージェント設定を使用する場合、GuardDuty がユーザーに代わって次の手順を実行することを許可します。 + GuardDuty は、SSM マネージドであり、[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) コンソールの **[Fleet Manager]** の下に表示されるすべての Amazon EC2 インスタンスに対して 1 つの SSM 関連付けを作成します。 + 自動エージェント設定が無効になっている包含タグの使用 – Runtime Monitoring を有効にした後、自動エージェント設定を有効にせず、Amazon EC2 インスタンスに包含タグを追加すると、GuardDuty がユーザーに代わってセキュリティエージェントを管理することを許可することになります。次に、SSM 関連付けは、包含タグ (`GuardDutyManaged`:`true`) を持つ各インスタンスにセキュリティエージェントをインストールします。 + 自動エージェント設定を有効にした場合 - SSM 関連付けによって、アカウントに属するすべての EC2 インスタンスにセキュリティエージェントがインストールされます。 + 自動エージェント設定での除外タグの使用 – 自動エージェント設定を有効にする前に、Amazon EC2 インスタンスに除外タグを追加すると、この選択したインスタンスのセキュリティエージェントのインストールおよび管理を防止することを GuardDuty に対して許可することになります。 次に、自動エージェント設定を有効にすると、SSM 関連付けは、除外タグが付けられたインスタンスを除くすべての EC2 インスタンスにセキュリティエージェントをインストールおよび管理します。 + GuardDuty は、VPC 内に終了またはシャットダウンされたインスタンス状態にない Linux EC2 インスタンスが少なくとも 1 つある限り、共有 VPC を含むすべての VPC に VPC エンドポイントを作成します。これには、一元化された VPC とスポーク VPC が含まれます。GuardDuty は、一元化された VPC のみの VPC エンドポイントの作成をサポートしていません。一元化された VPC の仕組みの詳細については、ホワイトペーパーの[「インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) - スケーラブルで安全なマルチ VPC ネットワークインフラストラクチャの構築」を参照してください。 *AWS AWS * さまざまなインスタンス状態の詳細については、「*Amazon EC2 ユーザーガイド*」の[インスタンスのライフサイクル](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html)に関するページを参照してください。 GuardDuty は[Runtime Monitoring で共有 VPC を使用する](runtime-monitoring-shared-vpc.md)もサポートしています。組織および のすべての前提条件が考慮されると AWS アカウント、GuardDuty は共有 VPC を使用してランタイムイベントを受信します。 **注記** VPC エンドポイントの使用に追加コストはかかりません。 + VPC エンドポイントと共に、GuardDuty は新しいセキュリティグループも作成します。インバウンド (Ingress) ルールは、セキュリティグループに関連付けられたリソースに到達することが許可されたトラフィックを制御します。GuardDuty は、リソースの VPC CIDR 範囲に一致するインバウンドルールを追加し、CIDR 範囲が変更されたときにそれに適応します。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC CIDR range](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)」を参照してください。 ## セキュリティエージェントの手動管理 Amazon EC2 のセキュリティエージェントを手動で管理する方法は 2 つあります。 + で GuardDuty マネージドドキュメント AWS Systems Manager を使用して、既に SSM マネージドされている Amazon EC2 インスタンスにセキュリティエージェントをインストールします。 新しい Amazon EC2 インスタンスを起動するときは、必ず SSM が有効になっていることを確認してください。 + Amazon EC2 インスタンスが SSM マネージドであるかどうかに関係なく、RPM パッケージマネージャー (RPM) スクリプトを使用して、Amazon EC2 インスタンスにセキュリティエージェントをインストールします。 ## 次のステップ Amazon EC2 インスタンスをモニタリングするための Runtime Monitoring 設定を開始するには、「[Amazon EC2 インスタンスサポートの前提条件](prereq-runtime-monitoring-ec2-support.md)」を参照してください。 # Fargate での Runtime Monitoring の仕組み (Amazon ECS のみ) Runtime Monitoring を有効にすると、GuardDuty はタスクからのランタイムイベントを使用する準備が整います。これらのタスクは Amazon ECS クラスター内で実行され、 AWS Fargate インスタンスで実行されます。GuardDuty がこれらのランタイムイベントを受信するには、フルマネージド型の専用セキュリティエージェントを使用する必要があります。 **注記** Runtime Monitoring は、[Amazon ECS マネージドインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html)で実行されているアプリケーションをサポートしていません。 AWS アカウントまたは組織の自動エージェント設定を使用して、GuardDuty がユーザーに代わって GuardDuty セキュリティエージェントを管理できるようにします。GuardDuty は、Amazon ECS クラスターで起動される新しい Fargate タスクへのセキュリティエージェントのデプロイを開始します。次のリストは、GuardDuty セキュリティエージェントを有効にする場合の動作を示しています。「**GuardDuty セキュリティエージェントを有効にした場合の影響**」 **GuardDuty は仮想プライベートクラウド (VPC) エンドポイントとセキュリティグループを作成します** + GuardDuty セキュリティエージェントをデプロイすると、GuardDuty は VPC エンドポイントを作成します。このエンドポイントを通じて、セキュリティエージェントがランタイムイベントを GuardDuty に配信します。 VPC エンドポイントと共に、GuardDuty は新しいセキュリティグループも作成します。インバウンド (Ingress) ルールは、セキュリティグループに関連付けられたリソースに到達することが許可されたトラフィックを制御します。GuardDuty は、リソースの VPC CIDR 範囲に一致するインバウンドルールを追加し、CIDR 範囲が変更されたときにそれに適応します。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC CIDR range](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)」を参照してください。 + 自動エージェントによる一元化された VPC の使用 – リソースタイプに GuardDuty 自動エージェント設定を使用する場合、GuardDuty はすべての VPC に対してユーザーに代わって VPC エンドポイントを作成します。これには、一元化された VPC とスポーク VPC が含まれます。GuardDuty は、一元化された VPC のみの VPC エンドポイントの作成をサポートしていません。一元化された VPC の仕組みの詳細については、ホワイトペーパーの[「インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) - スケーラブルで安全なマルチ VPC ネットワークインフラストラクチャの構築」を参照してください。 *AWS AWS * + VPC エンドポイントの使用に追加コストはかかりません。 「**GuardDuty はサイドカーコンテナを追加します**」 新しい Fargate タスクまたはサービスが実行を開始すると、GuardDuty コンテナ (サイドカー) が Amazon ECS Fargate タスク内の各コンテナに接続されます。GuardDuty セキュリティエージェントは、接続されている GuardDuty コンテナ内で実行されます。これにより、GuardDuty は、これらのタスク内で実行されている各コンテナのランタイムイベントを収集できます。 GuardDuty サイドカーコンテナイメージは Amazon Elastic Container Registry (Amazon ECR) に保存され、そのイメージレイヤーは Amazon S3 に保存されます。タスクが開始されたら、ECR からこのイメージをプルする必要があります。ネットワーク設定によっては、ECR と S3 の両方へのアクセスできるようにするために特定の設定が必要になる場合があります。例えば、アクセスが制限されたセキュリティグループを使用している場合は、S3 マネージドプレフィックスリストへのアクセスを許可する必要があります。方法の詳細については、「[コンテナイメージアクセスの前提条件](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs)」を参照してください。 Fargate タスクを開始したときに、GuardDuty コンテナ (サイドカー) が正常な状態で起動できない場合でも、Runtime Monitoring はタスクの実行を妨げないように設計されています。 デフォルトでは、Fargate タスクは変更できません。タスクがすでに実行中である場合、GuardDuty はサイドカーをデプロイしません。既に実行中のタスク内のコンテナをモニタリングしたい場合は、タスクを停止して再開できます。 ## Amazon ECS-Fargate リソースで GuardDuty セキュリティエージェントを管理するためのアプローチ Runtime Monitoring では、アカウント内のすべての Amazon ECS クラスター (アカウントレベル) または選択的クラスター (クラスターレベル) のいずれかで潜在的なセキュリティ脅威を検出できます。実行する Amazon ECS Fargate タスクごとに自動エージェント設定を有効にすると、GuardDuty はそのタスク内のコンテナワークロードごとにサイドカーコンテナを追加します。GuardDuty セキュリティエージェントがこのサイドカーコンテナにデプロイされます。これが、GuardDuty が Amazon ECS タスク内のコンテナの実行時の動作を可視化する方法です。 Runtime Monitoring は、GuardDuty を介してのみ Amazon ECS クラスター (AWS Fargate) のセキュリティエージェントの管理をサポートします。Amazon ECS クラスターでのセキュリティエージェントの手動管理はサポートされていません。 アカウントを設定する前に、Amazon ECS タスクに属するすべてのコンテナのランタイム動作をモニタリングするか、特定のリソースを含めるか除外するかを評価します。次のアプローチを参考にしてください。 **すべての Amazon ECS クラスターをモニタリングする** このアプローチは、潜在的なセキュリティ脅威をアカウントレベルで検出するのに役立ちます。このアプローチは、アカウントに属するすべての Amazon ECS クラスターに対する潜在的なセキュリティ脅威を GuardDuty に検出させる場合に使用します。 **特定の Amazon ECS クラスターを除外する** このアプローチは、GuardDuty が AWS 環境内のほとんどの Amazon ECS クラスターで潜在的なセキュリティ脅威を検出し、一部のクラスターを除外する場合に使用します。このアプローチは、Amazon ECS タスク内のコンテナの実行時の動作をクラスターレベルで監視するのに役立ちます。例えば、アカウントに属する Amazon ECS クラスターの数は 1000 個です。ただし、監視したい Amazon ECS クラスターは 930 個だけです。 この方法では、監視したくない Amazon ECS クラスターに定義済みの GuardDuty タグを追加する必要があります。詳細については、「[Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)」を参照してください。 **特定の Amazon ECS クラスターを含める** このアプローチは、一部の Amazon ECS クラスターに対する潜在的なセキュリティ脅威を GuardDuty に検出させる場合に使用します。このアプローチは、Amazon ECS タスク内のコンテナの実行時の動作をクラスターレベルで監視するのに役立ちます。例えば、アカウントに属する Amazon ECS クラスターの数は 1000 個です。ただし、監視したいクラスターは 230 個だけです。 この方法では、監視したい Amazon ECS クラスターに定義済みの GuardDuty タグを追加する必要があります。詳細については、「[Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)」を参照してください。 # Runtime Monitoring を有効にした後 Runtime Monitoring を有効にし、スタンドアロンアカウントまたは複数のメンバーアカウントに GuardDuty セキュリティエージェントをインストールした後、次のステップを実行して保護プラン設定が期待どおりに機能することを確認し、GuardDuty セキュリティエージェントが使用するメモリと CPU の量をモニタリングできます。 「**ランタイムカバレッジの評価**」 GuardDuty では、セキュリティエージェントをデプロイしたリソースのカバレッジステータスを継続的に評価することをお勧めします。**カバレッジステータスは「**正常**」または「異常**」の場合があります。「**正常**」のカバレッジステータスは、オペレーティングシステムレベルのアクティビティがあるときに、GuardDuty が対応するリソースからランタイムイベントを受信していることを示します。 リソースのカバレッジステータスが「**正常**」になると、GuardDuty はランタイムイベントを受信し、脅威を検出するために分析できます。GuardDuty が、コンテナワークロードとインスタンスで実行されているタスクまたはアプリケーションで潜在的なセキュリティ脅威を検出すると、GuardDuty は[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)を生成します。 カバレッジステータスが **[異常]** から **[正常]** に変わったときなどに通知を受け取るように Amazon EventBridge (EventBridge) を設定することもできます。詳細については、「[ランタイムカバレッジ統計の確認と問題のトラブルシューティング](runtime-monitoring-assessing-coverage.md)」を参照してください。 **GuardDuty セキュリティエージェントの CPU とメモリのモニタリングを設定する** カバレッジステータスが **[正常]** と表示されていることを評価した後、リソースタイプのセキュリティエージェントのパフォーマンスを評価できます。セキュリティエージェントリリース v1.5 以降の Amazon EKS クラスターの場合、GuardDuty は (アドオン) セキュリティエージェントのパラメータの設定をサポートしています。詳細については、「[CPU とメモリモニタリングの設定](runtime-monitoring-setting-cpu-mem-monitoring.md)」を参照してください。 「**GuardDuty による潜在的な脅威の検出**」 GuardDuty はリソースのランタイムイベントの受信を開始すると、それらのイベントの分析を開始します。GuardDuty が Amazon EC2 インスタンス、Amazon ECS クラスターまたは Amazon EKS クラスターのいずれかで潜在的なセキュリティ脅威を検出すると、1 つ以上の[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)が生成されます。検出の詳細にアクセスして、影響を受けたリソースの詳細を表示できます。