翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# GuardDuty Runtime Monitoring
Runtime Monitoring は、オペレーティングシステムレベル、ネットワーク、ファイルイベントを監視および分析し、環境内の特定の AWS ワークロードで潜在的な脅威を検出するのに役立ちます。
**Runtime Monitoring でサポートされている AWS リソース** – GuardDuty は当初、Amazon Elastic Kubernetes Service (Amazon EKS) リソースのみをサポートするために Runtime Monitoring をリリースしていました。これで、Runtime Monitoring 機能を使用して、 AWS Fargate Amazon Elastic Container Service (Amazon ECS) および Amazon Elastic Compute Cloud (Amazon EC2) リソースの脅威検出を提供できるようになりました。
「 AWS Fargate」で実行されている Amazon EKS クラスターはサポートされていません。
このドキュメントおよび Runtime Monitoring に関連する他のセクションでは、GuardDuty は**リソースタイプ**という用語を使用して、Amazon EKS、Fargate Amazon ECS、Amazon EC2 リソースを指します。
Runtime Monitoring では、GuardDuty セキュリティエージェントを使用して、ファイルアクセス、プロセス実行、コマンドライン引数、ネットワーク接続などのランタイムアクティビティを可視化します。潜在的な脅威をモニタリングするリソースタイプごとに、その特定のリソースタイプのセキュリティエージェントを自動または手動で管理できます (Fargate (Amazon ECS のみ) を除く)。セキュリティエージェントの自動管理は、GuardDuty がユーザーに代わってセキュリティエージェントをインストールおよび更新することを許可することを意味します。一方、リソースのセキュリティエージェントを手動で管理する場合、必要に応じてセキュリティエージェントをインストールして更新する責任がユーザーにあります。
この拡張機能により、GuardDutyは、個々のワークロードやインスタンスで実行されているアプリケーションやデータを標的にする可能性のある潜在的な脅威を特定して対応するのに役立ちます。例えば、脅威は、脆弱なウェブアプリケーションを実行している 1 つのコンテナを危険にさらすことから始まる可能性があります。このウェブアプリケーションには、基盤となるコンテナとワークロードへのアクセス権限が存在する可能性があります。この場合、認証情報が正しく設定されていないと、アカウントとその中に保存されているデータへのアクセスを制御できない可能性があります。
個々のコンテナとワークロードのランタイムイベントを分析することで、GuardDuty はコンテナおよび関連する AWS 認証情報の侵害を初期段階で特定し、特権、疑わしい API リクエスト、環境内のデータへの悪意のあるアクセスをエスカレートしようとする試みを検出できます。
**Topics**
+ [仕組み](how-does-runtime-monitoring-work.md)
+ [Runtime Monitoring の 30 日間の無料トライアルの仕組み](runtime-monitoring-free-trial-works.md)
+ [Runtime Monitoring を有効にする前提条件](runtime-monitoring-prerequisites.md)
+ [GuardDuty Runtime Monitoring の有効化](runtime-monitoring-configuration.md)
+ [GuardDuty セキュリティエージェントの管理](runtime-monitoring-managing-agents.md)
+ [ランタイムカバレッジ統計の確認と問題のトラブルシューティング](runtime-monitoring-assessing-coverage.md)
+ [CPU とメモリモニタリングの設定](runtime-monitoring-setting-cpu-mem-monitoring.md)
+ [Runtime Monitoring で共有 VPC を使用する](runtime-monitoring-shared-vpc.md)
+ [GuardDuty 自動セキュリティエージェントでの Infrastructure as Code (IaC) の使用](using-iac-with-gdu-automated-agents-runtime-monitoring.md)
+ [GuardDuty が使用する収集されたランタイムイベントタイプ](runtime-monitoring-collected-events.md)
+ [Amazon ECR リポジトリホスティング GuardDuty エージェント](runtime-monitoring-ecr-repository-gdu-agent.md)
+ [同じ基盤となるホスト上の 2 つのセキュリティエージェント](two-security-agents-installed-on-ec2-node.md)
+ [GuardDuty での EKS Runtime Monitoring](eks-runtime-monitoring-guardduty.md)
+ [GuardDuty セキュリティエージェントのリリースバージョン](runtime-monitoring-agent-release-history.md)
+ [Runtime Monitoring でのリソースの無効化、アンインストール、クリーンアップ](runtime-monitoring-agent-resource-clean-up.md)
# 仕組み
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)が生成されます。検出の詳細にアクセスして、影響を受けたリソースの詳細を表示できます。
# Runtime Monitoring の 30 日間の無料トライアルの仕組み
30 日間の無料トライアル期間は、新しい GuardDuty アカウントと、Runtime Monitoring 機能が Amazon EC2 インスタンスおよび AWS Fargate (Amazon ECS のみ) に拡張される前に EKS Runtime Monitoring を既に有効にしている既存のアカウントでは異なります。
## GuardDuty のトライアル期間を使用している、または EKS Runtime Monitoring を一度も有効にしたことがない
以下のリストでは、GuardDuty の 30 日間の試用期間を使用している場合や、EKS Runtime Monitoring を有効にしたことがない場合に、30 日間の無料試用期間がどのように機能するかを説明しています。
+ GuardDuty を初めて有効にする場合、Runtime Monitoring と EKS Runtime Monitoring はデフォルトで有効になっていません。
アカウントまたは組織の Runtime Monitoring を有効にする場合は、脅威検出を監視したいリソースの GuardDuty セキュリティエージェントも必ず設定してください。例えば、Amazon EC2 インスタンスに Runtime Monitoring を使用する場合は、Runtime Monitoring を有効にした後、Amazon EC2 のセキュリティエージェントも設定する必要があります。これは、手動で行うか、GuardDuty を使用して自動的に行うかを選択できます。
+ Runtime Monitoring 保護プランは**アカウントレベル**で有効になっています。30 日間の無料トライアル期間の**リソースレベル**での仕組み。GuardDuty セキュリティエージェントが特定のリソースタイプにデプロイされた後、30 日間の無料トライアルは、GuardDuty がこのリソースタイプに関連付けられた**最初のランタイムイベント**を受信した時点で開始されます。例えば、GuardDuty エージェントをリソースレベル (Amazon EC2 インスタンス、Amazon ECS クラスター、Amazon EKS クラスターに対して) でデプロイしたとします。GuardDuty が Amazon EC2 インスタンスの最初のランタイムイベントを受信すると、Amazon EC2 に対してのみ 30 日間の無料トライアルが開始されます。
+ EKS Runtime Monitoring のみを有効にする場合 - GuardDuty を初めて有効にすると、EKS Runtime Monitoring はデフォルトで有効になっていません (Runtime Monitoring のリリース以降)。EKS Runtime Monitoring を有効にする必要があります。これを最適に使用するには、GuardDuty セキュリティエージェントを手動で管理するか、自動エージェント設定を有効にして GuardDuty がユーザーに代わってエージェントを管理するようにしてください。EKS Runtime Monitoring の 30 日間の無料トライアル期間は、GuardDuty が Amazon EKS リソースの最初のランタイムイベントを受信した時点で開始されます。
# Runtime Monitoring を開始する前に EKS Runtime Monitoring を有効にしました
このセクションは、 で EKS Runtime Monitoring が有効になっていて AWS アカウント、Runtime Monitoring に移行する場合にのみ使用します。
次のリストには、Runtime Monitoring を有効にするユースケースに適用されるシナリオが含まれています。
+ EKS Runtime Monitoring 保護プランが有効で、GuardDuty コンソールエクスペリエンスを使用してこの保護プランを使用する既存の GuardDuty アカウントの場合 — Runtime Monitoring の発表により、EKS Runtime Monitoring コンソールエクスペリエンスは Runtime Monitoring に統合されました。EKS Runtime Monitoring の既存の設定は変わりません。引き続き API/CLI サポートを使用して、EKS Runtime Monitoring に関連する操作を実行できます。
+ EKS Runtime Monitoring を Runtime Monitoring の一部として使用するには、アカウントまたは組織の Runtime Monitoring を設定する必要があります。Runtime Monitoring で同じ設定を維持するには、「[EKS Runtime Monitoring から Runtime Monitoring への移行](migrating-from-eksrunmon-to-runtime-monitoring.md)」を参照してください。ただし、Amazon EKS リソースの 30 日間の無料トライアルには影響しません。
+ Runtime Monitoring 保護プランは、リージョンごとのアカウントレベルで有効になります。GuardDuty セキュリティエージェントが指定されたリソースタイプ (Amazon EC2 インスタンスと Amazon ECS クラスター) のいずれかにデプロイされた後、30 日間の無料トライアルは、GuardDuty がリソースタイプに関連付けられた最初のランタイムイベントを受信した時点で開始されます。各リソースタイプには、30 日間の無料トライアルがあります。
例えば、Runtime Monitoring を有効にした後、GuardDuty エージェントを Amazon EC2 インスタンスにのみデプロイすることを選択すると、このリソースの 30 日間の無料トライアルは、GuardDuty が Amazon EC2 インスタンスの最初のランタイムイベントを受信したときにのみ開始されます。その後、Fargate (Amazon ECS のみ) の GuardDuty エージェントをデプロイすると、GuardDuty が Amazon ECS クラスターの最初のランタイムイベントを受信したときにのみ、このリソースの 30 日間の無料トライアルが開始されます。アカウントで EKS Runtime Monitoring が既に有効になっている場合、GuardDuty は Amazon EKS リソースの 30 日間の無料トライアルをリセットしません。
# Runtime Monitoring を有効にする前提条件
Runtime Monitoring を有効にして GuardDuty セキュリティエージェントを管理するには、脅威検出のためにモニタリングする各リソースタイプの前提条件を満たす必要があります。リソースタイプごとに前提条件が異なります。例えば、GuardDuty はリソースタイプに基づいて異なる OS ディストリビューションをサポートしています。
Amazon EC2 リソースのみをモニタリングする場合は、Amazon EC2 インスタンスの前提条件に従います。後で Amazon EKS リソースをモニタリングする場合は、Amazon EKS クラスターに固有の前提条件に従う必要があります。
以下のセクションには、リソースタイプに基づく前提条件が含まれています。
**Topics**
+ [Amazon EC2 インスタンスサポートの前提条件](prereq-runtime-monitoring-ec2-support.md)
+ [AWS Fargate (Amazon ECS のみ) サポートの前提条件](prereq-runtime-monitoring-ecs-support.md)
+ [Amazon EKS クラスターサポートの前提条件](prereq-runtime-monitoring-eks-support.md)
# Amazon EC2 インスタンスサポートの前提条件
このセクションでは、Amazon EC2 インスタンスのランタイム動作をモニタリングするための前提条件について説明します。これらの前提条件が満たされた後、「[GuardDuty Runtime Monitoring の有効化](runtime-monitoring-configuration.md)」を参照してください。
**Topics**
+ [EC2 インスタンスを SSM 管理にする (自動エージェント設定のみ)](#ssm-managed-prereq-ec2)
+ [アーキテクチャ要件を検証する](#validating-architecture-req-ec2)
+ [マルチアカウント環境での組織サービスコントロールポリシーの検証](#validate-organization-scp-ec2)
+ [自動エージェント設定を使用する場合](#runtime-ec2-prereq-automated-agent)
+ [GuardDuty エージェントにおける CPU とメモリの制限](#ec2-cpu-memory-limits-gdu-agent)
+ [次のステップ](#next-step-after-prereq-ec2)
## EC2 インスタンスを SSM 管理にする (自動エージェント設定のみ)
GuardDuty は AWS Systems Manager (SSM) を使用して、インスタンスにセキュリティエージェントを自動的にデプロイ、インストール、管理します。GuardDuty エージェントを手動でインストールして管理する場合は、SSM は必要ありません。
Amazon EC2 インスタンスを Systems Manager で管理するには、「*AWS Systems Manager ユーザーガイド*」の「[Amazon EC2 インスタンス用のシステムマネージャーのセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)」を参照してください。
## アーキテクチャ要件を検証する
OS ディストリビューションのアーキテクチャは、GuardDuty セキュリティエージェントの動作に影響を与える可能性があります。Amazon EC2 インスタンスに Runtime Monitoring を使用する前に、次の要件を満たす必要があります。
+ カーネルのサポートには、`eBPF`、`Tracepoints`、`Kprobe` が含まれます。CPU アーキテクチャの場合、Runtime Monitoring は AMD64 (`x64`) と ARM64 (Graviton2 以降) をサポートしています[1](#runtime-monitoring-ec2-graviton-2-support)。
次の表は、Amazon EC2 インスタンスの GuardDuty セキュリティエージェントをサポートすることが確認された、OS ディストリビューションを示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
1. Amazon EC2 リソースの Runtime Monitoring は、A1 インスタンスタイプなどの第 1 世代 Graviton インスタンスをサポートしていません。
1. さまざまなオペレーティングシステムのサポート - GuardDuty は、前の表に記載されたオペレーティングディストリビューションでの Runtime Monitoring のサポートを検証しました。GuardDuty セキュリティエージェントは、前の表に記載されていないオペレーティングシステムでも実行できますが、GuardDuty チームは予想されるセキュリティ値を保証できません。
1. カーネルバージョンについては、 `CONFIG_DEBUG_INFO_BTF`フラグを `y` (*true* を意味する) に設定する必要があります。これは、GuardDuty セキュリティエージェントが想定どおりに実行できるようにするために必要です。
1. カーネルバージョン 5.10 以前の場合、期待どおりに機能するために GuardDuty セキュリティエージェントは RAM (`RLIMIT_MEMLOCK`) のロックされたメモリを使用します。システムの `RLIMIT_MEMLOCK` 値が低すぎる場合、GuardDuty ではハード制限とソフト制限の両方を少なくとも 32 MB に設定することをお勧めします。デフォルトの `RLIMIT_MEMLOCK` 値の検証と変更については、「[`RLIMIT_MEMLOCK` 値のユーザーの表示と更新](#runtime-monitoring-ec2-modify-rlimit-memlock)」を参照してください。
1. Ubuntu 24.04 では、カーネルバージョン 6.13 および 6.14 は EC2 エージェントバージョン 1.9.2 以降のみをサポートしています。
+ 追加要件 - Amazon ECS/Amazon EC2 をお持ちの場合のみ
Amazon ECS/Amazon EC2 については、Amazon ECS に最適化された最新の AMI (2023 年 9 月 29 日以降) を使用するか、Amazon ECS エージェントバージョン v1.77.0 を使用することをお勧めします。
### `RLIMIT_MEMLOCK` 値のユーザーの表示と更新
システムの `RLIMIT_MEMLOCK` 制限が低すぎると、GuardDuty セキュリティエージェントが設計どおりに動作しない可能性があります。GuardDuty では、ハードリミットとソフトリミットの両方が 32 MB 以上であることを推奨しています。制限を更新しない場合、GuardDuty はリソースのランタイムイベントをモニタリングできません。`RLIMIT_MEMLOCK` が規定の最小制限を上回った場合、これらの制限を更新することはオプションになります。
デフォルトの `RLIMIT_MEMLOCK` 値は、GuardDuty セキュリティエージェントをインストールする前またはインストール後に変更できます。
**`RLIMIT_MEMLOCK` 値を表示するには**
1. `ps aux | grep guardduty` を実行します。これにより、プロセス ID (`pid`) が出力されます。
1. 前のコマンドの出力からプロセス ID (`pid`) をコピーします。
1. `pid` を前のステップでコピーしたプロセス ID に置き換えてから `grep "Max locked memory" /proc/pid/limits` を実行します。
これにより、GuardDuty セキュリティエージェントの実行時に使用される最大ロックメモリが表示されます。
**`RLIMIT_MEMLOCK` 値を更新するには**
1. `/etc/systemd/system.conf.d/NUMBER-limits.conf` ファイルが存在する場合は、このファイルから `DefaultLimitMEMLOCK` の行をコメントアウトします。このファイルは、優先度の高い デフォルト `RLIMIT_MEMLOCK` を設定し、`/etc/systemd/system.conf` ファイルの設定を上書きします。
1. `/etc/systemd/system.conf` ファイルを開き、`#DefaultLimitMEMLOCK=` がある行のコメントを解除します。
1. ハード制限とソフト `RLIMIT_MEMLOCK` 制限の両方を 32 MB 以上に指定して、デフォルト値を更新します。更新は次のようになります: `DefaultLimitMEMLOCK=32M:32M`。形式は `soft-limit:hard-limit` です。
1. `sudo reboot` を実行します。
## マルチアカウント環境での組織サービスコントロールポリシーの検証
組織内のアクセス許可を管理するようにサービスコントロールポリシー (SCP) を設定している場合は、アクセス許可の境界が `guardduty:SendSecurityTelemetry` アクションを許可していることを確認します。GuardDuty がさまざまなリソースタイプで Runtime Monitoring をサポートする必要があります。
メンバーアカウントの場合は、関連する委任管理者に接続します。組織の SCP の管理については、「[Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
## 自動エージェント設定を使用する場合
を使用するには[自動エージェント設定を使用する (推奨)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2)、 が次の前提条件を満たす AWS アカウント 必要があります。
+ 自動エージェント設定で包含タグを使用する場合、GuardDuty で新しいインスタンスの SSM 関連付けを作成するには、新しいインスタンスが SSM マネージドであり、[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) コンソールの **[Fleet Manager]** の下に表示されることを確認します。
+ 自動エージェント設定で除外タグを使用する場合:
+ アカウントの GuardDuty 自動エージェントを設定する前に、`GuardDutyManaged`:`false` タグを追加します。
Amazon EC2 インスタンスを起動する前に、必ず除外タグを追加してください。Amazon EC2 の自動エージェント設定を有効にすると、除外タグなしで起動する EC2 インスタンスは、GuardDuty 自動エージェント設定の対象となります。
+ インスタンスの **[メタデータ内でタグを許可する]** 設定を有効にします。この設定が必要なのは、GuardDuty がインスタンスメタデータサービス (IMDS) から除外タグを読み取って、インスタンスをエージェントインストールから除外するべきかどうかを判断しなければならないからです。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータ内のタグへのアクセスを有効にする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS)」を参照してください。
## GuardDuty エージェントにおける CPU とメモリの制限
**CPU 制限**
Amazon EC2 インスタンスに関連付けられている GuardDuty セキュリティエージェントの最大 CPU 制限は、合計 vCPU コアの 10% です。例えば、EC2 インスタンスに 4 つの vCPU コアがある場合、セキュリティエージェントは利用可能な合計 400% のうち最大 40% を使用できます。
**メモリ制限**
Amazon EC2 インスタンスに関連付けられているメモリから、GuardDuty セキュリティエージェントが使用できるメモリは限られています。
次の表は、メモリ制限を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
## 次のステップ
次のステップでは、Runtime Monitoring を設定し、セキュリティエージェントを (自動または手動で) 管理します。
# AWS Fargate (Amazon ECS のみ) サポートの前提条件
このセクションでは、Fargate-Amazon ECS リソースのランタイム動作をモニタリングするための前提条件について説明します。これらの前提条件が満たされた後、「[GuardDuty Runtime Monitoring の有効化](runtime-monitoring-configuration.md)」を参照してください。
**Topics**
+ [アーキテクチャ要件の検証](#validating-architecture-req-ecs)
+ [コンテナイメージアクセスの前提条件](#before-enable-runtime-monitoring-ecs)
+ [マルチアカウント環境での組織サービスコントロールポリシーの検証](#validate-organization-scp-ecs)
+ [ロールのアクセス許可とポリシーのアクセス許可の境界の検証](#guardduty-runtime-monitoring-ecs-permission-boundary)
+ [CPU とメモリの制限](#ecs-runtime-agent-cpu-memory-limits)
## アーキテクチャ要件の検証
使用するプラットフォームは、Amazon ECS クラスターからランタイムイベントを受信する際に GuardDuty セキュリティエージェントが GuardDuty をサポートする方法に影響を与える可能性があります。検証済みのプラットフォームのいずれかを使用していることを検証する必要があります。
**最初の検討事項:**
Amazon ECS クラスターの AWS Fargate プラットフォームは Linux である必要があります。対応するプラットフォームバージョンは少なくとも `1.4.0` または `LATEST` である必要があります。有効なプラットフォームバージョンの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Linux プラットフォームのバージョン](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-linux-fargate.html)」を参照してください。
Windows プラットフォームバージョンはまだサポートされていません。
### 検証済みプラットフォーム
OS ディストリビューションと CPU アーキテクチャは、GuardDuty セキュリティエージェントが提供するサポートに影響します。次の表は、GuardDuty セキュリティエージェントをデプロイし、Runtime Monitoring を設定するための検証済み設定を示しています。
| OS ディストリビューション**[1](#runtime-monitoring-ecs-os-support)** | カーネルサポート | CPU アーキテクチャ x64 (AMD64) | CPU アーキテクチャ Graviton (ARM64) |
| --- | --- | --- | --- |
| Linux | eBPF、Tracepoints、Kprobe | サポート対象 | サポート |
1 さまざまなオペレーティングシステムのサポート - GuardDuty は、前の表に記載されているオペレーティングシステムでの Runtime Monitoring のサポートを検証しました。GuardDuty セキュリティエージェントは、前の表に記載されていないオペレーティングシステムでも実行できますが、GuardDuty チームは予想されるセキュリティ値を保証できません。
## コンテナイメージアクセスの前提条件
以下の前提条件は、Amazon ECR リポジトリから GuardDuty サイドカーコンテナイメージにアクセスするのに役立ちます。
### アクセス許可の要件
タスク実行ロールには、GuardDuty セキュリティエージェントコンテナイメージをダウンロードするための特定の Amazon Elastic Container Registry (Amazon ECR) アクセス許可が必要です。
```
...
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
...
```
Amazon ECR アクセス許可をさらに制限するには、GuardDuty セキュリティエージェントをホストする Amazon ECR リポジトリ URI を追加します AWS Fargate (Amazon ECS のみ）。詳細については、「[Amazon ECR リポジトリホスティング GuardDuty エージェント](runtime-monitoring-ecr-repository-gdu-agent.md)」を参照してください。
[AmazonECSTaskExecutionRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) マネージドポリシーを使用するか、`TaskExecutionRole` ポリシーに上記のアクセス許可を追加できます。
### タスク定義の設定
Amazon ECS サービスを作成または更新する際には、タスク定義でサブネット情報を提供する必要があります。
「*Amazon Elastic Container Service API リファレンス*] の [[CreateService]](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) API と [[UpdateService]](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) API を実行するには、サブネット情報を渡す必要があります。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS のタスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」を参照してください。
### ネットワーク接続要件
Amazon ECR から GuardDuty コンテナイメージをダウンロードするには、ネットワーク接続を確保する必要があります。この要件は、Amazon ECR を使用してセキュリティエージェントをホストするため、GuardDuty に固有のものです。ネットワーク設定に応じて、以下のいずれかのオプションを実装する必要があります。
**オプション 1 - パブリックネットワークアクセスの使用 (利用可能な場合)**
Fargate タスクがアウトバウンドインターネットアクセスのあるサブネットで実行されている場合、追加のネットワーク設定は必要ありません。
**オプション 2 - Amazon VPC エンドポイントを使用する (プライベートサブネット用)**
Fargate タスクがインターネットアクセスできないプライベートサブネットで実行される場合は、GuardDuty セキュリティエージェントをホストする ECR リポジトリ URI がネットワークにアクセスできるようにするために、ECR の VPC エンドポイントを設定する必要があります。これらのエンドポイントがないと、プライベートサブネットのタスクは GuardDuty コンテナイメージをダウンロードできません。
VPC エンドポイントのセットアップ手順については、「*Amazon Elastic コンテナレジストリ ユーザーガイド*」の 「[Amazon ECR 用の VPC エンドポイントを作成する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)」を参照してください。
Fargate で GuardDuty コンテナをダウンロードできるようにする方法については、「*Amazon Elastic Container Registry ユーザーガイド*」の「[Using Amazon ECR images with Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html)」を参照してください。
### セキュリティグループの構成
GuardDuty コンテナイメージは Amazon ECR にあり、Amazon S3 アクセスが必要です。この要件は、Amazon ECR からのコンテナイメージのダウンロードに固有です。ネットワークアクセスが制限されたタスクでは、S3 へのアクセスを許可するようにセキュリティグループを設定する必要があります。
セキュリティグループに、[ポート 443 の S3 マネージドプレフィックスリスト (`pl-xxxxxxxx`)](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security) へのトラフィックを許可するアウトバウンドルールを追加します。アウトバウンドルールを追加するには、「*Amazon VPC ユーザーガイド*」の「[セキュリティグループの設定](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)」を参照してください。
AWSマネージドプレフィックスリストをコンソールで表示したり、 AWS Command Line Interface (AWS CLI) を使用して説明したりするには、*「Amazon VPC ユーザーガイド*」の[AWS「 マネージドプレフィックスリスト](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)」を参照してください。
## マルチアカウント環境での組織サービスコントロールポリシーの検証
このセクションでは、サービスコントロールポリシー (SCP) の設定を検証して、組織全体で Runtime Monitoring が期待どおりに動作することを確認する方法について説明します。
組織内のアクセス許可を管理するために 1 つ以上のサービスコントロールポリシーを設定している場合は、`guardduty:SendSecurityTelemetry` アクションを拒否しないことを検証する必要があります。SCP の仕組みについては、「*AWS Organizations ユーザーガイド*」の「[SCP の評価](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html)」を参照してください。
メンバーアカウントの場合は、関連する委任管理者に接続します。組織の SCP の管理については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
マルチアカウント環境で設定したすべての SCP に対して次の手順を実行します。
**SCP で `guardduty:SendSecurityTelemetry` が否定されていないことを検証するには**
1. [https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/) で Organizations コンソールを開きます。組織の管理アカウントで、IAM ロールとしてサインインするか、ルートユーザーとしてサインインする [(推奨されません)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) 必要があります。
1. 左のナビゲーションペインで [**ポリシー**] を選択します。次に、**[サポートされているポリシータイプ]** で、**[サービスコントロールポリシー]** を選択します。
1. **[サービスコントロールポリシー]** ページで、検証するポリシーの名前を選択します。
1. ポリシーの詳細ページで、このポリシーの**コンテンツ**を表示します。`guardduty:SendSecurityTelemetry` アクションを拒否しないことを確認してください。
次の SCP ポリシーは、 `guardduty:SendSecurityTelemetry` アクションを*拒否しない*例です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"guardduty:SendSecurityTelemetry"
],
"Resource": "*"
}
]
}
```
------
ポリシーがこのアクションを拒否する場合は、ポリシーを更新する必要があります。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシーの更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy)」を参照してください。
## ロールのアクセス許可とポリシーのアクセス許可の境界の検証
次のステップを使用して、ロールとそのポリシーに関連付けられたアクセス許可の境界が `guardduty:SendSecurityTelemetry` アクションを制限**しない**ことを確認します。
**ロールとそのポリシーのアクセス許可の境界を表示するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. 左のナビゲーションペインの **[アクセス管理]** で、**[ロール]** を選択します。
1. [**ロール**] ページで、作成したロール *`TaskExecutionRole`* を選択します。
1. 選択したロールのページで、**[アクセス許可]** タブで、このロールに関連付けられたポリシー名を展開します。次に、このポリシーが `guardduty:SendSecurityTelemetry` を制限していないことを確認します。
1. **アクセス許可の境界が設定されている場合**は、このセクションを展開します。次に、各ポリシーを展開して、`guardduty:SendSecurityTelemetry` アクションが制限されていないことを確認します。ポリシーは次の [Example SCP policy](#ecs-runtime-scp-not-deny-policy-example) のようになります。
必要に応じて、次のいずれかのアクションを実行します。
+ ポリシーを変更するには、**[編集]** を選択します。このポリシーの**[アクセス許可の変更]** ページで、**ポリシーエディタ**でポリシーを更新します。JSON スキーマが有効であることを確認してください。その後、**[Next]** を選択します。その後、変更を確認して保存することができます。
+ このアクセス許可の境界を変更して別の境界を選択するには、**[境界の変更]** を選択します。
+ このアクセス許可の境界を削除するには、**[境界の削除]** を選択します。
IAM ポリシーの管理の詳細については、「*IAM ユーザーガイド*」の「[AWS Identity and Access Managementでのポリシーとアクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)」を参照してください。
## CPU とメモリの制限
Fargate タスク定義では、CPU 値とメモリの値をタスクレベルで指定する必要があります。次の表は、タスクレベルの CPU 値とメモリの値の有効な組み合わせ、および、対応する GuardDuty コンテナの最大メモリ制限を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html)
Runtime Monitoring を有効にして、クラスターのカバレッジステータスが **[正常]** と評価されると、コンテナインサイトメトリクスを設定および表示できます。詳細については、[Amazon ECS クラスターでの監視設定](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent) を参照してください。
次のステップでは、Runtime Monitoring を設定し、セキュリティエージェントも設定します。
# Amazon EKS クラスターサポートの前提条件
このセクションでは、Amazon EKS リソースのランタイム動作をモニタリングするための前提条件について説明します。これらの前提条件は、GuardDuty エージェントが期待どおりに機能するために不可欠です。これらの前提条件が満たされたら、「[GuardDuty Runtime Monitoring の有効化](runtime-monitoring-configuration.md)」を参照してリソースのモニタリングを開始します。
## Amazon 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)」を参照してください。
## アーキテクチャ要件の検証
使用するプラットフォームは、EKS クラスターからランタイムイベントを受信する際に GuardDuty セキュリティエージェントが GuardDuty をサポートする方法に影響を与える可能性があります。検証済みのプラットフォームのいずれかを使用していることを検証する必要があります。GuardDuty エージェントを手動で管理している場合は、現在使用している GuardDuty エージェントのバージョンが、Kubernetes のバージョンでサポートされていることを確認します。
### 検証済みプラットフォーム
OS ディストリビューション、カーネルバージョン、CPU アーキテクチャは、GuardDuty セキュリティエージェントが提供するサポートに影響します。カーネルのサポートには、`eBPF`、`Tracepoints`、`Kprobe` が含まれます。CPU アーキテクチャの場合、Runtime Monitoring は AMD64 (`x64`) と ARM64 (Graviton2 以降) をサポートしています[1](#runtime-monitoring-eks-graviton-2-support)。
次の表は、GuardDuty セキュリティエージェントをデプロイし、EKS Runtime Monitoring を設定するための検証済み設定を示しています。
| OS ディストリビューション**[2](#runtime-monitoring-eks-os-support)** | カーネルバージョン**[3](#runtime-monitoring-eks-kernel-version-required-flag)** | サポートされている Kubernetes バージョン |
| --- | --- | --- |
| Bottlerocket | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23 - v1.35 |
| Ubuntu | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| Amazon Linux 2 | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| Amazon Linux 2023*[5](#runtime-eks-al2023-support-v1.6.0)* | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| RedHat 9.4 | 5.14[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| フェドラ 34 | 5.11～5.17 | v1.21 - v1.35 |
| フェドラ 40 | 6.8 | v1.28 - v1.35 |
| フェドラ 41 | 6.12 | v1.28 - v1.35 |
| CentOS Stream 9 | 5.14 | v1.21 - v1.35 |
1. Amazon EKS クラスターの Runtime Monitoring は、A1 インスタンスタイプなどの第 1 世代 Graviton インスタンスをサポートしていません。
1. さまざまなオペレーティングシステムのサポート - GuardDuty は、前の表に記載されたオペレーティングディストリビューションでの Runtime Monitoring のサポートを検証しました。GuardDuty セキュリティエージェントは、前の表に記載されていないオペレーティングシステムでも実行できますが、GuardDuty チームは予想されるセキュリティ値を保証できません。
1. カーネルバージョンについては、 `CONFIG_DEBUG_INFO_BTF`フラグを `y` (*true* を意味する) に設定する必要があります。これは、GuardDuty セキュリティエージェントが想定どおりに実行できるようにするために必要です。
1. 現在、カーネルバージョン `6.1` では、GuardDuty は[ドメインネームシステム (DNS) イベント](runtime-monitoring-collected-events.md#eks-runtime-dns-events)に関連する[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)を生成できません。
1. Runtime Monitoring は、GuardDuty セキュリティエージェント v1.6.0 以降のリリースで AL2023 をサポートします。詳細については、「[Amazon EKS リソースの GuardDuty セキュリティエージェントバージョン](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)」を参照してください。
#### GuardDuty セキュリティエージェントでサポートされている Kubernetes のバージョン
次の表は、GuardDuty セキュリティエージェントでサポートされている EKS クラスターの Kubernetes のバージョンを示しています。
| Amazon EKS アドオン GuardDuty セキュリティエージェントバージョン | Kubernetes バージョン |
| --- | --- |
| v1.12.1 (最新 - v1.12.1-eksbuild.2) | 1.28～1.35 |
| v1.11.0 (最新 - v1.11.0-eksbuild.4) | 1.28～1.34 |
| v1.10.0 (最新 - v1.10.0-eksbuild.2) | 1.21～1.33 |
| v1.9.0 (最新 - v1.9.0-eksbuild.2) v1.8.1 (最新 - v1.8.1-eksbuild.2) | 1.21～1.32 |
| v1.7.1 v1.7.0 v1.6.1 | 1.21～1.31 |
| v1.6.0 v1.5.0 v1.4.1 v1.4.0 v1.3.1 | 1.21～1.29 |
| v1.3.0 v1.2.0 | 1.21～1.28 |
| v1.1.0 | 1.21～1.26 |
| v1.0.0 | 1.21 - 1.25 |
一部の GuardDuty セキュリティエージェントバージョンでは、標準サポートが終了します。
エージェントリリースバージョンの詳細については、「[Amazon EKS リソースの GuardDuty セキュリティエージェントバージョン](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)」を参照してください。
### CPU とメモリの制限
次の表は、GuardDuty 向け Amazon EKS アドオンの CPU とメモリの制限を示しています (`aws-guardduty-agent`)。
| パラメータ | 最小限度 | 最大限度 |
| --- | --- | --- |
| CPU | 200m | 1000m |
| メモリ | 256 Mi | 1024 Mi |
Amazon EKS アドオンバージョン 1.5.0 以降を使用する場合、GuardDuty は CPU とメモリ値にアドオンスキーマを設定する機能を提供します。設定可能な範囲については、「[設定可能なパラメータと値](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values)」を参照してください。
EKS Runtime Monitoring を有効にして、EKS クラスターのカバレッジステータスを評価すると、コンテナインサイトメトリクスを設定および表示できます。詳細については、「[CPU とメモリモニタリングの設定](runtime-monitoring-setting-cpu-mem-monitoring.md)」を参照してください。
## 組織サービスコントロールポリシーの検証
組織内のアクセス許可を管理するようにサービスコントロールポリシー (SCP) を設定している場合は、アクセス許可の境界が `guardduty:SendSecurityTelemetry` を制限していないことを確認します。GuardDuty がさまざまなリソースタイプで Runtime Monitoring をサポートする必要があります。
メンバーアカウントの場合は、関連する委任管理者に接続します。組織の SCP の管理については、「[Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
# GuardDuty Runtime Monitoring の有効化
アカウントで Runtime Monitoring を有効にする前に、ランタイムイベントを監視したいリソースタイプがプラットフォームの要件を満たしていることを確認してください。詳細については、「[前提条件](runtime-monitoring-prerequisites.md)」を参照してください。
Runtime Monitoring の開始前に EKS Runtime Monitoring を使用していた場合は、API を使用して EKS Runtime Monitoring の既存の設定を確認して更新できます。既存の設定を EKS Runtime Monitoring から Runtime Monitoring に移行することもできます。詳細については、「[EKS Runtime Monitoring から Runtime Monitoring への移行](migrating-from-eksrunmon-to-runtime-monitoring.md)」を参照してください。
**注記**
現在、このドキュメントでは、アカウントと組織の Runtime Monitoring をコンソールでのみ有効にする手順を説明しています。「[API アクション](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Operations.html)」または「[GuardDuty のAWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/guardduty/index.html#cli-aws-guardduty)」を使用して、Runtime Monitoring を有効にすることもできます。
Runtime Monitoring は、以下のトピックの手順を使用して設定できます。
**Topics**
+ [マルチアカウント環境の Runtime Monitoring の有効化](enable-runtime-monitoring-multiple-acc-env.md)
+ [スタンドアロンアカウントの Runtime Monitoring の有効化](enable-runtime-monitoring-standalone-acc.md)
# マルチアカウント環境の Runtime Monitoring の有効化
マルチアカウント環境では、委任 GuardDuty 管理者アカウントのみが、メンバーアカウントの Runtime Monitoring を有効または無効にすることや、組織内のメンバーアカウントに属するリソースタイプの自動エージェント設定を管理できます。GuardDuty メンバーアカウントからは、この設定を変更できません。委任 GuardDuty 管理者アカウントは、 を使用してメンバーアカウントを管理します AWS Organizations。マルチアカウント環境の詳細については、「[複数のアカウントの管理](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html)」を参照してください。
## 委任 GuardDuty 管理者アカウントで有効にする
**委任 GuardDuty 管理者アカウントで Runtime Monitoring を有効にするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. **[設定]** タブの **[Runtime Monitoring 設定]** セクションで **[編集]** を選択します。
1.
**[すべてのアカウントについて有効にする] の使用**
委任 GuardDuty 管理者アカウントを含めて、組織に属するすべてのアカウントで Runtime Monitoring を有効にする場合は、**[すべてのアカウントについて有効にする]** を選択します。
1.
**[アカウントを手動で設定] の使用**
メンバーアカウントごとに個別に Runtime Monitoring を有効にする場合は、**[アカウントを手動で設定]** を選択します。
1. **[委任された管理者 (このアカウント)]** セクションで **[有効にする]** を選択します。
1. GuardDuty が 1 つ以上のリソースタイプ (Amazon EC2 インスタンス、Amazon ECS クラスターまたは Amazon EKS クラスター) からランタイムイベントを受信できるようにするには、以下のオプションを使用してこれらのリソースのセキュリティエージェントを管理します。
**GuardDuty セキュリティエージェントを削除するには**
+ [Amazon EC2 インスタンスの自動セキュリティエージェントの有効化](managing-gdu-agent-ec2-automated.md)
+ [Amazon EC2 リソースのセキュリティエージェントの手動管理](managing-gdu-agent-ec2-manually.md)
+ [Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)
+ [Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)
+ [Amazon EKS クラスターのセキュリティエージェントの手動管理](managing-gdu-agent-eks-manually.md)
## すべてのメンバーアカウントで有効にする
**組織内のすべてのメンバーアカウントの Runtime Monitoring を有効にするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
委任 GuardDuty 管理者アカウントを使用してサインインします。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. [Runtime Monitoring] ページで、**[設定]** タブの **[Runtime Monitoring 設定]** セクションの **[編集]** を選択します。
1. **[すべてのアカウントについて有効にする]** を選択します。
1. GuardDuty が 1 つ以上のリソースタイプ (Amazon EC2 インスタンス、Amazon ECS クラスターまたは Amazon EKS クラスター) からランタイムイベントを受信できるようにするには、以下のオプションを使用してこれらのリソースのセキュリティエージェントを管理します。
**GuardDuty セキュリティエージェントを削除するには**
+ [Amazon EC2 インスタンスの自動セキュリティエージェントの有効化](managing-gdu-agent-ec2-automated.md)
+ [Amazon EC2 リソースのセキュリティエージェントの手動管理](managing-gdu-agent-ec2-manually.md)
+ [Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)
+ [Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)
+ [Amazon EKS クラスターのセキュリティエージェントの手動管理](managing-gdu-agent-eks-manually.md)
## すべての既存のアクティブなメンバーアカウントで有効にする
**組織内の既存のメンバーアカウントの Runtime Monitoring を有効にするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
組織の委任 GuardDuty 管理者アカウントを使用してサインインします。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. **[Runtime Monitoring]** ページの **[設定]** タブで、Runtime Monitoring 設定の現在のステータスを表示できます。
1. [Runtime Monitoring] ペイン内の **[アクティブなメンバーアカウント]** セクションで、**[アクション]** を選択します。
1. **[アクション]** ドロップダウンメニューから、**[すべての既存のアクティブなメンバーアカウントについて有効にする]** を選択します。
1. **[確認]** を選択します。
1. GuardDuty が 1 つ以上のリソースタイプ (Amazon EC2 インスタンス、Amazon ECS クラスターまたは Amazon EKS クラスター) からランタイムイベントを受信できるようにするには、以下のオプションを使用してこれらのリソースのセキュリティエージェントを管理します。
**GuardDuty セキュリティエージェントを削除するには**
+ [Amazon EC2 インスタンスの自動セキュリティエージェントの有効化](managing-gdu-agent-ec2-automated.md)
+ [Amazon EC2 リソースのセキュリティエージェントの手動管理](managing-gdu-agent-ec2-manually.md)
+ [Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)
+ [Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)
+ [Amazon EKS クラスターのセキュリティエージェントの手動管理](managing-gdu-agent-eks-manually.md)
**注記**
メンバーアカウントの設定を更新するには、最大 24 時間かかる場合があります。
## 新しいメンバーアカウントでのみ Runtime Monitoring を自動的に有効にする
**組織内の新しいメンバーアカウントの Runtime Monitoring を有効にするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
組織の指定された委任 GuardDuty 管理者アカウントを使用してサインインします。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します
1. **[設定]** タブの **[Runtime Monitoring 設定]** セクションで **[編集]** を選択します。
1. **[アカウントを手動で設定]** を選択します。
1. **[新しいメンバーアカウントについて自動的に有効にする]** を選択します。
1. GuardDuty が 1 つ以上のリソースタイプ (Amazon EC2 インスタンス、Amazon ECS クラスターまたは Amazon EKS クラスター) からランタイムイベントを受信できるようにするには、以下のオプションを使用してこれらのリソースのセキュリティエージェントを管理します。
**GuardDuty セキュリティエージェントを削除するには**
+ [Amazon EC2 インスタンスの自動セキュリティエージェントの有効化](managing-gdu-agent-ec2-automated.md)
+ [Amazon EC2 リソースのセキュリティエージェントの手動管理](managing-gdu-agent-ec2-manually.md)
+ [Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)
+ [Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)
+ [Amazon EKS クラスターのセキュリティエージェントの手動管理](managing-gdu-agent-eks-manually.md)
## 選択したアクティブなメンバーアカウントでのみ有効にする
**個々のアクティブなメンバーアカウントの Runtime Monitoring を有効にするには**
1. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
委任 GuardDuty 管理者アカウントの認証情報を使用してサインインします。
1. ナビゲーションペインで、**[Accounts]** (アカウント) を選択します。
1. **[アカウント]** ページで、**[Runtime Monitoring]** および **[エージェントの自動管理]** の列の値を確認します。これらの値は、Runtime Monitoring と GuardDuty エージェント管理が、対応するアカウントで **[有効]** または **[無効]** のいずれであるのかを示します。
1. [アカウント] テーブルから、Runtime Monitoring を有効にするアカウントを選択します。一度に複数のアカウントを選択できます。
1. **[確認]** を選択します。
1. **[保護プランを編集]** を選択します。適切なアクションを選択します。
1. **[確認]** を選択します。
1. GuardDuty が 1 つ以上のリソースタイプ (Amazon EC2 インスタンス、Amazon ECS クラスターまたは Amazon EKS クラスター) からランタイムイベントを受信できるようにするには、以下のオプションを使用してこれらのリソースのセキュリティエージェントを管理します。
**GuardDuty セキュリティエージェントを削除するには**
+ [Amazon EC2 インスタンスの自動セキュリティエージェントの有効化](managing-gdu-agent-ec2-automated.md)
+ [Amazon EC2 リソースのセキュリティエージェントの手動管理](managing-gdu-agent-ec2-manually.md)
+ [Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)
+ [Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)
+ [Amazon EKS クラスターのセキュリティエージェントの手動管理](managing-gdu-agent-eks-manually.md)
# スタンドアロンアカウントの Runtime Monitoring の有効化
スタンドアロンアカウントは、特定の の で保護プランを有効または無効にする決定を所有 AWS アカウント します AWS リージョン。
アカウントが を通じて AWS Organizations、または招待方法によって GuardDuty 管理者アカウントに関連付けられている場合、このセクションはアカウントには適用されません。詳細については、「[マルチアカウント環境の Runtime Monitoring の有効化](enable-runtime-monitoring-multiple-acc-env.md)」を参照してください。
Runtime Monitoring を有効にした後、自動設定または手動デプロイを使用して GuardDuty セキュリティエージェントをインストールしてください。次の手順に記載されたすべてのステップを完了する一環として、セキュリティエージェントをインストールしてください。
**スタンドアロンアカウントで Runtime Monitoring を有効にするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. **[設定]** タブで **[有効にする]** を選択し、アカウントの EKS Runtime Monitoring を有効にします。
1. GuardDuty が 1 つ以上のリソースタイプ (Amazon EC2 インスタンス、Amazon ECS クラスターまたは Amazon EKS クラスター) からランタイムイベントを受信できるようにするには、以下のオプションを使用してこれらのリソースのセキュリティエージェントを管理します。
**GuardDuty セキュリティエージェントを削除するには**
+ [Amazon EC2 インスタンスの自動セキュリティエージェントの有効化](managing-gdu-agent-ec2-automated.md)
+ [Amazon EC2 リソースのセキュリティエージェントの手動管理](managing-gdu-agent-ec2-manually.md)
+ [Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)
+ [Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)
+ [Amazon EKS クラスターのセキュリティエージェントの手動管理](managing-gdu-agent-eks-manually.md)
# GuardDuty セキュリティエージェントの管理
監視したいリソースの GuardDuty セキュリティエージェントを管理できます。複数のリソースタイプを監視したい場合は、必ずそのリソースの GuardDuty エージェントを管理してください。
以下のトピックは、セキュリティエージェントを管理する次の手順に役立ちます。
**Topics**
+ [Amazon EC2 インスタンスの自動セキュリティエージェントの有効化](managing-gdu-agent-ec2-automated.md)
+ [Amazon EC2 リソースのセキュリティエージェントの手動管理](managing-gdu-agent-ec2-manually.md)
+ [Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)](managing-gdu-agent-ecs-automated.md)
+ [Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)
+ [Amazon EKS クラスターのセキュリティエージェントの手動管理](managing-gdu-agent-eks-manually.md)
+ [Amazon EKS の GuardDuty セキュリティエージェント (アドオン) パラメータを設定する](guardduty-configure-security-agent-eks-addon.md)
+ [VPC エンドポイント設定の検証](validate-vpc-endpoint-config-runtime-monitoring.md)
# Amazon EC2 インスタンスの自動セキュリティエージェントの有効化
このセクションでは、スタンドアロンアカウントまたはマルチアカウント環境で Amazon EC2 リソースの GuardDuty 自動エージェントを有効にするステップについて説明します。
続行する前に、必ずすべての「[Amazon EC2 インスタンスサポートの前提条件](prereq-runtime-monitoring-ec2-support.md)」に従ってください。
GuardDuty エージェントの手動管理から GuardDuty 自動エージェントの有効化に移行する場合は、GuardDuty 自動エージェントを有効にするステップを実行する前に、「[Amazon EC2 手動エージェントから自動エージェントへの移行](migrate-from-ec2-manual-to-automated-agent.md)」を参照してください。
# マルチアカウント環境で Amazon EC2 リソースの GuardDuty エージェントを有効にする
マルチアカウント環境では、委任 GuardDuty 管理者アカウントのみが、組織内のメンバーアカウントに属するリソースタイプの自動エージェント設定を有効または無効にできます。GuardDuty メンバーアカウントからは、この設定を変更できません。委任 GuardDuty 管理者アカウントは、 を使用してメンバーアカウントを管理します AWS Organizations。マルチアカウント環境の詳細については、「[複数のアカウントの管理](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html)」を参照してください。
## 委任 GuardDuty 管理者アカウントで有効にする
------
#### [ Configure for all instances ]
Runtime Monitoring で **[すべてのアカウントで有効にする]** を選択した場合、委任 GuardDuty 管理者アカウントで次のいずれかのオプションを選択します。
+ **オプション 1**
**[自動エージェント設定]** の **[EC2]** セクションで、**[すべてのアカウントで有効にする**] を選択します。
+ **オプション 2**
+ **[自動エージェント設定]** の **[EC2]** セクションで、**[アカウントを手動で設定する]** を選択します。
+ **[委任管理者 (このアカウント)]** で、**[有効にする]** を選択します。
+ **[保存]** を選択します。
Runtime Monitoring で **[アカウントを手動で設定する]** を選択した場合、次のステップを実行します。
+ **[自動エージェント設定]** の **[EC2]** セクションで、**[アカウントを手動で設定する]** を選択します。
+ **[委任管理者 (このアカウント)]** で、**[有効にする]** を選択します。
+ **[保存]** を選択します。
委任 GuardDuty 管理者アカウントの自動エージェント設定を有効にするためにどのオプションを選択したかに関係なく、GuardDuty が作成する SSM 関連付けがこのアカウントに属するすべての EC2 リソースにセキュリティエージェントをインストールおよび管理することを確認できます。
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. SSM 関連付け (`GuardDutyRuntimeMonitoring-do-not-delete`) の **[ターゲット]** タブを開きます。**[タグキー]** が **[InstanceIds]** として表示されることを確認します。
------
#### [ Using inclusion tag in selected instances ]
**選択した Amazon EC2 インスタンスに GuardDuty エージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出させたいインスタンスに `GuardDutyManaged`:`true` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
このタグを追加すると、GuardDuty は選択した EC2 インスタンスに対してセキュリティエージェントをインストールおよび管理できます。自動エージェント設定を明示的に有効にする必要は**ありません**。
1. GuardDuty が作成する SSM 関連付けが、包含タグでタグ付けされた EC2 リソースにのみセキュリティエージェントをインストールおよび管理することを確認できます。
[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. 作成される SSM 関連付け (`GuardDutyRuntimeMonitoring-do-not-delete`) の **[ターゲット]** タブを開きます。**[タグキー]** は **[tag:GuardDutyManaged]** として表示されます。
------
#### [ Using exclusion tag in selected instances ]
**注記**
Amazon EC2 インスタンスを起動する前に、必ず除外タグを追加してください。Amazon EC2 の自動エージェント設定を有効にすると、除外タグなしで起動する EC2 インスタンスは、GuardDuty 自動エージェント設定の対象となります。
**選択した Amazon EC2 インスタンスに GuardDuty エージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出**させたくない**インスタンスに `GuardDutyManaged`:`false` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
1.
**インスタンスメタデータで[除外タグを使用する](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2)には、次のステップを実行します。**
1. インスタンスの **[詳細]** タブで、**[インスタンスメタデータ内のタグを許可する]** のステータスを表示します。
現在 **[無効]** になっている場合は、次のステップを使用してステータスを **[有効]** に変更します。それ以外の場合は、この手順をスキップしてください。
1. **[アクション]** メニューで、**[インスタンス設定]** を選択します。
1. **[インスタンスメタデータ内のタグを許可する]** を選択します。
1. 除外タグを追加した後、**すべてのインスタンスの設定**タブに記載されているのと同じステップを実行します。
------
これでランタイム「[Amazon EC2 インスタンスのランタイムカバレッジとトラブルシューティング](gdu-assess-coverage-ec2.md)」を評価できるようになりました。
## すべてのメンバーアカウントの自動有効化
**注記**
メンバーアカウントの設定を更新するには、最大 24 時間かかる場合があります。
------
#### [ Configure for all instances ]
以下のステップは、Runtime Monitoring セクションで **[すべてのアカウントで有効にする]** を選択したことを前提としています。
1. **[Amazon EC2]** の **[自動エージェント設定]** セクションで、**[すべてのアカウントで有効にする]** を選択します。
1. GuardDuty が作成する SSM 関連付け (`GuardDutyRuntimeMonitoring-do-not-delete`) が、このアカウントに属するすべての EC2 リソースにセキュリティエージェントをインストールおよび管理することを確認できます。
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. SSM 関連付けの **[ターゲット]** タブを開きます。**[タグキー]** が **[InstanceIds]** として表示されることを確認します。
------
#### [ Using inclusion tag in selected instances ]
**選択した Amazon EC2 インスタンスに GuardDuty エージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出させたい EC2 インスタンスに `GuardDutyManaged`:`true` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
このタグを追加すると、GuardDuty は選択した EC2 インスタンスに対してセキュリティエージェントをインストールおよび管理できます。自動エージェント設定を明示的に有効にする必要は**ありません**。
1. GuardDuty が作成する SSM 関連付けが、アカウントに属するすべての EC2 リソースにセキュリティエージェントをインストールおよび管理することを確認できます。
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. SSM 関連付け (`GuardDutyRuntimeMonitoring-do-not-delete`) の **[ターゲット]** タブを開きます。**[タグキー]** が **[InstanceIds]** として表示されることを確認します。
------
#### [ Using exclusion tag in selected instances ]
**注記**
Amazon EC2 インスタンスを起動する前に、必ず除外タグを追加してください。Amazon EC2 の自動エージェント設定を有効にすると、除外タグなしで起動する EC2 インスタンスは、GuardDuty 自動エージェント設定の対象となります。
**選択した Amazon EC2 インスタンスに GuardDuty セキュリティエージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出**させたくない**インスタンスに `GuardDutyManaged`:`false` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
1.
**インスタンスメタデータで[除外タグを使用する](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2)には、次のステップを実行します。**
1. インスタンスの **[詳細]** タブで、**[インスタンスメタデータ内のタグを許可する]** のステータスを表示します。
現在 **[無効]** になっている場合は、次のステップを使用してステータスを **[有効]** に変更します。それ以外の場合は、この手順をスキップしてください。
1. **[アクション]** メニューで、**[インスタンス設定]** を選択します。
1. **[インスタンスメタデータ内のタグを許可する]** を選択します。
1. 除外タグを追加した後、**すべてのインスタンスの設定**タブに記載されているのと同じステップを実行します。
------
これでランタイム「[Amazon EC2 インスタンスのランタイムカバレッジとトラブルシューティング](gdu-assess-coverage-ec2.md)」を評価できるようになりました。
## 新しいメンバーアカウントでのみ自動的に有効にする
委任 GuardDuty 管理者アカウントは、Amazon EC2 リソースの自動エージェント設定を設定して、新しいメンバーアカウントが組織に加わるときに自動的に有効にできます。
------
#### [ Configure for all instances ]
次のステップでは、**[Runtime Monitoring]** セクションで、**[新しいメンバーアカウントで自動的に有効にする]** を選択した場合を前提としています。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. **[Runtime Monitoring]** ページで、**[編集]** を選択します。
1. **[新しいメンバーアカウントについて自動的に有効にする]** を選択します。このステップにより、新しいアカウントが組織に参加するたびに、そのアカウントに対して Amazon EC2 の自動エージェント設定が自動的に有効になります。この選択を変更できるのは、組織の委任 GuardDuty 管理者アカウントのみです。
1. **[保存]** を選択します。
新しいメンバーアカウントが組織に加わると、この設定が自動的に有効になります。GuardDuty がこの新しいメンバーアカウントに属する Amazon EC2 インスタンスのセキュリティエージェントを管理するには、「[EC2 インスタンスの場合](prereq-runtime-monitoring-ec2-support.md)」に記載されたすべての前提条件が満たされていることを確認してください。
SSM 関連付けが作成されると (`GuardDutyRuntimeMonitoring-do-not-delete`)、SSM 関連付けが新しいメンバーアカウントに属するすべての EC2 インスタンスにセキュリティエージェントをインストールおよび管理することを確認できます。
+ [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
+ SSM 関連付けの **[ターゲット]** タブを開きます。**[タグキー]** が **[InstanceIds]** として表示されることを確認します。
------
#### [ Using inclusion tag in selected instances ]
**アカウント内の選択したインスタンスに GuardDuty セキュリティエージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出させたいインスタンスに `GuardDutyManaged`:`true` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
このタグを追加すると、GuardDuty は選択したインスタンスに対してセキュリティエージェントをインストールおよび管理できます。自動エージェント設定を明示的に有効にする必要はありません。
1. GuardDuty が作成する SSM 関連付けが、包含タグでタグ付けされた EC2 リソースにのみセキュリティエージェントをインストールおよび管理することを確認できます。
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. 作成される SSM 関連付けの **[ターゲット]** タブを開きます。**[タグキー]** は **[tag:GuardDutyManaged]** として表示されます。
------
#### [ Using exclusion tag in selected instances ]
**注記**
Amazon EC2 インスタンスを起動する前に、必ず除外タグを追加してください。Amazon EC2 の自動エージェント設定を有効にすると、除外タグなしで起動する EC2 インスタンスは、GuardDuty 自動エージェント設定の対象となります。
**スタンドアロンアカウントの特定のインスタンスに GuardDuty セキュリティエージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出**させたくない**インスタンスに `GuardDutyManaged`:`false` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
1.
**インスタンスメタデータで[除外タグを使用する](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2)には、次のステップを実行します。**
1. インスタンスの **[詳細]** タブで、**[インスタンスメタデータ内のタグを許可する]** のステータスを表示します。
現在 **[無効]** になっている場合は、次のステップを使用してステータスを **[有効]** に変更します。それ以外の場合は、この手順をスキップしてください。
1. **[アクション]** メニューで、**[インスタンス設定]** を選択します。
1. **[インスタンスメタデータ内のタグを許可する]** を選択します。
1. 除外タグを追加した後、**すべてのインスタンスの設定**タブに記載されているのと同じステップを実行します。
------
これでランタイム「[Amazon EC2 インスタンスのランタイムカバレッジとトラブルシューティング](gdu-assess-coverage-ec2.md)」を評価できるようになりました。
## 選択したメンバーアカウントのみ
------
#### [ Configure for all instances ]
1. **[アカウント]** ページで、**[Runtime Monitoring 自動エージェント設定 (Amazon EC2)]** を有効にする 1 つ以上のアカウントを選択します。このステップで選択したアカウントで Runtime Monitoring が既に有効になっていることを確認してください。
1. **[保護プランの編集]** から、適切なオプションを選択して **[Runtime Monitoring 自動エージェント設定 (Amazon EC2)]** を有効にします。
1. **[確認]** を選択します。
------
#### [ Using inclusion tag in selected instances ]
**選択したインスタンスに GuardDuty セキュリティエージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出させたいインスタンスに `GuardDutyManaged`:`true` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
このタグを追加すると、GuardDuty がタグ付けされた Amazon EC2 インスタンスのセキュリティエージェントを管理できるようになります。自動エージェント設定 **[Runtime Monitoring - 自動エージェント設定 (EC2)]** を明示的に有効にする必要はありません。
------
#### [ Using exclusion tag in selected instances ]
**注記**
Amazon EC2 インスタンスを起動する前に、必ず除外タグを追加してください。Amazon EC2 の自動エージェント設定を有効にすると、除外タグなしで起動する EC2 インスタンスは、GuardDuty 自動エージェント設定の対象となります。
**選択したインスタンスに GuardDuty セキュリティエージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングまたは検出**させたくない** EC2 インスタンスに `GuardDutyManaged`:`false` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
1.
**インスタンスメタデータで[除外タグを使用する](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2)には、次のステップを実行します。**
1. インスタンスの **[詳細]** タブで、**[インスタンスメタデータ内のタグを許可する]** のステータスを表示します。
現在 **[無効]** になっている場合は、次のステップを使用してステータスを **[有効]** に変更します。それ以外の場合は、この手順をスキップしてください。
1. **[アクション]** メニューで、**[インスタンス設定]** を選択します。
1. **[インスタンスメタデータ内のタグを許可する]** を選択します。
1. 除外タグを追加した後、**すべてのインスタンスの設定**タブに記載されているのと同じステップを実行します。
------
これで、「[Amazon EC2 インスタンスのランタイムカバレッジとトラブルシューティング](gdu-assess-coverage-ec2.md)」を評価できるようになりました。
# スタンドアロンアカウントで Amazon EC2 リソースの GuardDuty 自動エージェントを有効にする
スタンドアロンアカウントは、特定の の で保護プランを有効または無効にする決定を所有 AWS アカウント します AWS リージョン。
アカウントが を通じて AWS Organizations、または招待方法によって GuardDuty 管理者アカウントに関連付けられている場合、このセクションはアカウントには適用されません。詳細については、「[マルチアカウント環境の Runtime Monitoring の有効化](enable-runtime-monitoring-multiple-acc-env.md)」を参照してください。
Runtime Monitoring を有効にした後、自動設定または手動デプロイを使用して GuardDuty セキュリティエージェントをインストールしてください。次の手順に記載されたすべてのステップを完了する一環として、セキュリティエージェントをインストールしてください。
すべての Amazon EC2 リソースをモニタリングするか、選択した Amazon EC2 リソースをモニタリングするかに応じて、任意の方法を選択し、次の表のステップに従います。
------
#### [ Configure for all instances ]
**スタンドアロンアカウント内のすべてのインスタンスで Runtime Monitoring を設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. **[設定]** タブで、**[編集]** を選択します。
1. **[EC2]** セクションで **[有効にする]** を選択します。
1. **[保存]** を選択します。
1. GuardDuty が作成する SSM 関連付けが、アカウントに属するすべての EC2 リソースにセキュリティエージェントをインストールおよび管理することを確認できます。
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. SSM 関連付け (`GuardDutyRuntimeMonitoring-do-not-delete`) の **[ターゲット]** タブを開きます。**[タグキー]** が **[InstanceIds]** として表示されることを確認します。
------
#### [ Using inclusion tag in selected instances ]
**選択した Amazon EC2 インスタンスに GuardDuty セキュリティエージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出させたいインスタンスに `GuardDutyManaged`:`true` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
1. GuardDuty が作成する SSM 関連付けが、包含タグでタグ付けされた EC2 リソースにのみセキュリティエージェントをインストールおよび管理することを確認できます。
[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. 作成される SSM 関連付け (`GuardDutyRuntimeMonitoring-do-not-delete`) の **[ターゲット]** タブを開きます。**[タグキー]** は **[tag:GuardDutyManaged]** として表示されます。
------
#### [ Using exclusion tag in selected instances ]
**注記**
Amazon EC2 インスタンスを起動する前に、必ず除外タグを追加してください。Amazon EC2 の自動エージェント設定を有効にすると、除外タグなしで起動する EC2 インスタンスは、GuardDuty 自動エージェント設定の対象となります。
**選択した Amazon EC2 インスタンスに GuardDuty セキュリティエージェントを設定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. GuardDuty に潜在的な脅威をモニタリングおよび検出**させたくない**インスタンスに `GuardDutyManaged`:`false` タグを追加します。このタグの追加については、[タグを個々のリソースに追加する方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
1.
**インスタンスメタデータで[除外タグを使用する](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2)には、次のステップを実行します。**
1. インスタンスの **[詳細]** タブで、**[インスタンスメタデータ内のタグを許可する]** のステータスを表示します。
現在 **[無効]** になっている場合は、次のステップを使用してステータスを **[有効]** に変更します。それ以外の場合は、この手順をスキップしてください。
1. タグを許可するインスタンスを選択します。
1. **[アクション]** メニューで、**[インスタンス設定]** を選択します。
1. **[インスタンスメタデータ内のタグを許可する]** を選択します。
1. **[インスタンスメタデータのタグへのアクセス]** で **[許可する]** を選択します。
1. **[保存]** を選択します。
1. 除外タグを追加した後、**すべてのインスタンスの設定**タブに記載されているのと同じステップを実行します。
------
これでランタイム「[Amazon EC2 インスタンスのランタイムカバレッジとトラブルシューティング](gdu-assess-coverage-ec2.md)」を評価できるようになりました。
# Amazon EC2 手動エージェントから自動エージェントへの移行
このセクションは、 AWS アカウント 以前にセキュリティエージェントを手動で管理していて、GuardDuty 自動エージェント設定を使用する場合に適用されます。これに該当しない場合は、アカウントのセキュリティエージェントの設定を続行します。
GuardDuty 自動エージェントを有効にすると、GuardDuty はユーザーに代わってセキュリティエージェントを管理します。GuardDuty が実行するステップについては、「[自動エージェント設定を使用する (推奨)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2)」を参照してください。
## リソースをクリーンアップする
**SSM 関連付けの削除**
+ Amazon EC2 のセキュリティエージェントを手動で管理するときに作成した SSM 関連付けを削除します。詳細については、「[関連付けを削除する](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html)」を参照してください。
+ これは、アカウントレベルまたはインスタンスレベルで (包含タグまたは除外タグを使用して) 自動エージェントを使用するかどうかにかかわらず、GuardDuty が SSM アクションの管理を引き継ぐことができるようにするために行われます。GuardDuty が実行できる SSM アクションの詳細については、「[GuardDuty のためのサービスにリンクされたロールの許可](slr-permissions.md)」を参照してください。
+ セキュリティエージェントを手動で管理するために以前作成された SSM 関連付けを削除すると、GuardDuty がセキュリティエージェントを自動的に管理するための SSM 関連付けを作成するときに、短時間の重複が発生する場合があります。この期間中、SSM スケジューリングに基づいて競合が発生する可能性があります。詳細については、[Amazon EC2 SSM のスケジューリング](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-scheduler.html)に関するページを参照してください。
**Amazon EC2 インスタンスの包含タグと除外タグを管理する**
+ **包含タグ** – GuardDuty 自動エージェント設定を有効にせず、Amazon EC2 インスタンスに包含タグ (`GuardDutyManaged`:`true`) をタグ付けすると、GuardDuty は、選択した EC2 インスタンスにセキュリティエージェントをインストールおよび管理する SSM 関連付けを作成します。これは、選択した EC2 インスタンスでのみセキュリティエージェントを管理するのに役立つ正常な動作です。詳細については、「[Amazon EC2 インスタンスでの Runtime Monitoring の仕組み](how-runtime-monitoring-works-ec2.md)」を参照してください。
GuardDuty がセキュリティエージェントをインストールおよび管理できないようにするには、これらの EC2 インスタンスから包含タグを削除します。詳細については、「*Amazon EC2 ユーザーガイド*」の[タグの追加と削除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)に関するページを参照してください。
+ **除外タグ** – アカウント内のすべての EC2 インスタンスで GuardDuty 自動エージェント設定を有効にする場合は、EC2 インスタンスに除外タグ (`GuardDutyManaged`:`false`) がタグ付けされていないことを確認してください。
# Amazon EC2 リソースのセキュリティエージェントの手動管理
このセクションでは、Amazon EC2 リソースのセキュリティエージェントを手動でインストールおよび更新するステップについて説明します。
Runtime Monitoring を有効にしたら、GuardDuty セキュリティエージェントを手動でインストールする必要があります。GuardDuty セキュリティエージェントを手動で管理するには、まず Amazon VPC エンドポイントを手動で作成する必要があります。その後、GuardDuty が Amazon EC2 インスタンスからランタイムイベントを受信し始めるように、セキュリティエージェントをインストールできます。GuardDuty がこのリソースの新しいエージェントバージョンをリリースすると、アカウントでエージェントバージョンを更新できます。
以下のトピックでは、Amazon EC2 リソースのセキュリティエージェントを継続的に管理するステップについて説明します。
**Topics**
+ [前提条件 - Amazon VPC エンドポイントの手動作成](creating-vpc-endpoint-ec2-agent-manually.md)
+ [セキュリティエージェントの手動インストール](installing-gdu-security-agent-ec2-manually.md)
+ [Amazon EC2 インスタンスの GuardDuty セキュリティエージェントの手動更新](gdu-update-security-agent-ec2.md)
# 前提条件 - Amazon VPC エンドポイントの手動作成
GuardDuty セキュリティエージェントをインストールする前に、Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを作成する必要があります。これにより、GuardDuty は Amazon EC2 インスタンスのランタイムイベントを受信できるようになります。
**注記**
VPC エンドポイントの使用に追加コストはかかりません。
**Amazon VPC エンドポイントを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) で Amazon VPC コンソールを開きます。
1. ナビゲーションペインの **[VPC プライベートクラウド]** で、**[エンドポイント]** を選択します。
1. **[エンドポイントの作成]** を選択します。
1. **[エンドポイントの作成]** ページの **[サービスカテゴリ]** で **[その他のエンドポイントサービス**] を選択します。
1. **[サービス名]** に **com.amazonaws.*us-east-1*.guardduty-data** と入力します。
必ず「*us-east-1*」をあなたの AWS リージョンに置き換えてください。これは、 AWS アカウント ID に属する Amazon EC2 インスタンスと同じリージョンである必要があります。
1. **[サービスの確認]** を選択します。
1. サービス名が正常に確認されたら、インスタンスが置かれている **[VPC]** を選択します。次のポリシーを追加して、Amazon VPC エンドポイントの使用を指定されたアカウントのみに制限します。このポリシー下で提供されている組織 `Condition` を使用して、次のポリシーを更新してエンドポイントへのアクセスを制限できます。組織内の特定のアカウント ID に Amazon VPC エンドポイントサポートを提供するには、「[Organization condition to restrict access to your endpoint](#gdu-runtime-ec2-organization-restrict-access-vpc-endpoint)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow",
"Principal": "*"
},
{
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111122223333"
}
},
"Action": "*",
"Resource": "*",
"Effect": "Deny",
"Principal": "*"
}
]
}
```
------
`aws:PrincipalAccount` アカウント ID は、VPC と VPC エンドポイントを含むアカウントと一致する必要があります。次のリストは、VPC エンドポイントを他の AWS アカウント IDs と共有する方法を示しています。
+ VPC エンドポイントにアクセスする複数のアカウントを指定するには、`"aws:PrincipalAccount: "111122223333"`を以下のブロックに置き換えます。
```
"aws:PrincipalAccount": [
"666666666666",
"555555555555"
]
```
AWS アカウント IDs は、VPC エンドポイントにアクセスする必要があるアカウントのアカウント IDs に置き換えてください。
+ 組織のすべてのメンバーが VPC エンドポイントにアクセスできるようにするには、`"aws:PrincipalAccount: "111122223333"` を以下のラインに置き換えます。
```
"aws:PrincipalOrgID": "o-abcdef0123"
```
組織「*o-abcdef0123*」は必ず自分の組織 ID に置き換えてください。
+ リソースへのアクセスを組織 ID で制限するには、`ResourceOrgID` をポリシーに追加します。詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid)」の「*`aws:ResourceOrgID`*」を参照してください。
```
"aws:ResourceOrgID": "o-abcdef0123"
```
1. **[追加設定]** で **[DNS 名を有効にする]** を選択します。
1. **[サブネット]** で、インスタンスが存在するサブネットを選択します。
1. **[セキュリティグループ]** で、VPC (または Amazon EC2 インスタンス) からのインバウンドポート 443 が有効になっているセキュリティグループを選択します。インバウンドポート 443 が有効になっているセキュリティグループがまだない場合は、「*Amazon VPC ユーザーガイド*」の「[VPC 用のセキュリティグループを作成するには](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html)」を参照してください。
VPC (またはインスタンス) へのインバウンド許可を制限する際に問題が発生した場合は、任意の IP アドレス `(0.0.0.0/0)` からのインバウンド 443 ポートをサポートできます。ただし、GuardDuty では、VPC の CIDR ブロックに一致する IP アドレスを使用することをお勧めします。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC CIDR ブロック](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-cidr-blocks.html)」を参照してください。
ステップに従った後、「[VPC エンドポイント設定の検証](validate-vpc-endpoint-config-runtime-monitoring.md)」を参照して、VPC エンドポイントが正しく設定されていることを確認します。
# セキュリティエージェントの手動インストール
GuardDuty には、Amazon EC2 インスタンスに GuardDuty セキュリティエージェントをインストールするための次の 2 つの方法が用意されています。続行する前に、「[前提条件 - Amazon VPC エンドポイントの手動作成](creating-vpc-endpoint-ec2-agent-manually.md)」のステップに従ってください。
Amazon EC2 リソースにセキュリティエージェントをインストールする優先アクセス方法を選択します。
+ [方法 1 - の使用 AWS Systems Manager](#install-gdu-by-using-sys-runtime-monitoring) – この方法では、Amazon EC2 インスタンス AWS Systems Manager を管理する必要があります。
+ [方法 2 - Linux パッケージマネージャーを使用する](#install-gdu-by-rpm-scripts-runtime-monitoring) – Amazon EC2 インスタンスが AWS Systems Manager 管理されているかどうかにかかわらず、この方法を使用できます。[OS ディストリビューション](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#validating-architecture-req-ec2)に応じて、RPM スクリプトまたは Debian スクリプトのいずれかをインストールする適切な方法を選択できます。*Fedora* プラットフォームを使用する場合は、この方法を使用してエージェントをインストールする必要があります。
## 方法 1 - の使用 AWS Systems Manager
この方法を使用するには、Amazon EC2 インスタンスが AWS Systems Manager 管理されていることを確認し、エージェントをインストールします。
### AWS Systems Manager マネージド Amazon EC2 インスタンス
Amazon EC2 インスタンスを AWS Systems Manager マネージドにするには、次のステップを実行します。
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS アプリケーションとリソースをend-to-endで管理し、安全なオペレーションを大規模に有効にするのに役立ちます。
で Amazon EC2 インスタンスを管理するには AWS Systems Manager、 *AWS Systems Manager ユーザーガイド*の[Amazon EC2 インスタンス用の Systems Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)」を参照してください。
+ 次の表に、新しい GuardDuty 管理 AWS Systems Manager ドキュメントを示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)
詳細については AWS Systems Manager、「 *AWS Systems Manager ユーザーガイド*」の[Amazon EC2 Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html)」を参照してください。
**Debian サーバーの場合**
が提供する AWS Debian サーバー用の Amazon マシンイメージ (AMIs) では、 AWS Systems Manager エージェント (SSM エージェント) をインストールする必要があります。Amazon EC2 Debian サーバーインスタンスを SSM マネージドにするには、SSM エージェントをインストールするための追加のステップを実行する必要があります。必要なステップについては、「*AWS Systems Manager ユーザーガイド*」の「[Debian サーバーインスタンスに SSM Agent を手動でインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html)」を参照してください。
**を使用して Amazon EC2 インスタンス用の GuardDuty エージェントをインストールするには AWS Systems Manager**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) で AWS Systems Manager コンソールを開きます。
1. ナビゲーションペインで、**[ドキュメント]** を選択します。
1. **[Amazon が所有]** で、`AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin` を選択します。
1. **[Run Command]** を選択します。
1. 次の Run Command パラメータを入力します。
+ アクション: **[インストール]** を選択します。
+ インストールのタイプ: **[インストール] または [アンインストール]** を選択します。
+ 名前: `AmazonGuardDuty-RuntimeMonitoringSsmPlugin`
+ バージョン:これが空のままの場合は、最新バージョンの GuardDuty セキュリティエージェントが取得されます。リリースバージョンの詳細については、「[Amazon EC2 インスタンス用の GuardDuty セキュリティエージェントバージョン](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history)」を参照してください。
1. 対象の Amazon EC2 インスタンス を選択します。複数の Amazon EC2 インスタンスを選択できます。詳細については、「*AWS Systems Manager ユーザーガイド*」の「[AWS Systems Manager コンソールからコマンドを実行する](https://docs.aws.amazon.com/systems-manager/latest/userguide/running-commands-console.html)」を参照してください
1. GuardDuty エージェントが正常にインストールされているかどうかを検証します。詳細については、「[GuardDuty セキュリティエージェントのインストールステータスの検証](#validate-ec2-gdu-agent-installation-healthy)」を参照してください。
## 方法 2 - Linux パッケージマネージャーを使用する
この方法では、RPM スクリプトまたは Debian スクリプトを実行して、GuardDuty セキュリティエージェントをインストールできます。オペレーティングシステムに応じて、任意の方法を選択できます。
+ RPM スクリプトを使用して、OS ディストリビューション AL2、AL2023、RedHat、CentOS,または Fedora にセキュリティエージェントをインストールします。
+ Debian スクリプトを使用して、OS ディストリビューション Ubuntu または Debian にセキュリティエージェントをインストールします。サポートされている Ubuntu および Debian OS ディストリビューションの詳細については、「[アーキテクチャ要件を検証する](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2)」を参照してください。
------
#### [ RPM installation ]
**重要**
GuardDuty セキュリティエージェントの RPM 署名をマシンにインストールする前に検証することをお勧めします。
1. GuardDuty セキュリティエージェントの RPM 署名の検証
1.
**テンプレートを準備する**
適切なパブリックキー、x86\$164 RPM の署名、arm64 RPM の署名、および Amazon S3 バケットでホストされている RPM スクリプトへの対応するアクセスリンクを使用してコマンドを準備します。RPM スクリプトにアクセスするには AWS リージョン、、 AWS アカウント ID、および GuardDuty エージェントバージョンの値を置き換えます。
+ **パブリックキー** :
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem
```
+ **GuardDuty セキュリティエージェントの RPM 署名** :
x86\$164 RPM の署名
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig
```
arm64 RPM の署名
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig
```
+ **Amazon S3 バケット内の RPM スクリプトへのアクセスリンク**:
x86\$164 RPM 用アクセスリンク
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm
```
arm64 RPM 用アクセスリンク
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.rpm
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)
1.
**テンプレートをダウンロードする**
次のコマンドで、適切なパブリックキー、x86\$164 RPM の署名、arm64 RPM の署名、Amazon S3 バケットでホストされている RPM スクリプトへの対応するアクセスリンクをダウンロードするには、アカウント ID を適切な AWS アカウント ID に、リージョンを現在のリージョンに置き換えてください。
```
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm ./amazon-guardduty-agent-1.9.2.x86_64.rpm
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig ./amazon-guardduty-agent-1.9.2.x86_64.sig
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem ./publickey.pem
```
1.
**パブリックキーをインポートする**
次のコマンドを使用して、パブリックキーをデータベースにインポートします。
```
gpg --import publickey.pem
```
gpg はインポートの成功を示しています。
```
gpg: key 093FF49D: public key "AwsGuardDuty" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
1.
**署名を検証する**
次のコマンドを使用して、署名を確認します。
```
gpg --verify amazon-guardduty-agent-1.9.2.x86_64.sig amazon-guardduty-agent-1.9.2.x86_64.rpm
```
検証に成功すると、次の結果のようなメッセージが表示されます。これで、RPM を使用して GuardDuty セキュリティエージェントをインストールできます。
出力例:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: Good signature from "AwsGuardDuty"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7478 91EF 5378 1334 4456 7603 06C9 06A7 093F F49D
```
検証に失敗した場合は、RPM の署名が改ざんされている可能性があることを意味します。パブリックキーをデータベースから削除して、検証プロセスを再試行する必要があります。
例:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: BAD signature from "AwsGuardDuty"
```
次のコマンドを使用して、データベースからパブリックキーを削除します。
```
gpg --delete-keys AwsGuardDuty
```
次に、検証プロセスを再試行します。
1. 「[Linux または macOS から SSH で接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html)」。
1. 次のコマンドを使用して GuardDuty セキュリティエージェントをインストールします。
```
sudo rpm -ivh amazon-guardduty-agent-1.9.2.x86_64.rpm
```
1. GuardDuty エージェントが正常にインストールされているかどうかを検証します。これらの手順の詳細については、「[GuardDuty セキュリティエージェントのインストールステータスの検証](#validate-ec2-gdu-agent-installation-healthy)」を参照してください。
------
#### [ Debian installation ]
**重要**
GuardDuty セキュリティエージェントの Debian 署名をマシンにインストールする前に検証することをお勧めします。
1. GuardDuty セキュリティエージェントの Debian 署名の検証
1.
**適切なパブリックキー、amd64 Debian パッケージの署名、arm64 Debian パッケージの署名、および Amazon S3 バケットでホストされている Debian スクリプトへの対応するアクセスリンク用のテンプレートを準備する**
次のテンプレートで、 AWS リージョン、 AWS アカウント ID、および GuardDuty エージェントバージョンの値を置き換えて、Debian パッケージスクリプトにアクセスします。
+ **パブリックキー** :
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem
```
+ **GuardDuty セキュリティエージェントの Debian 署名**:
amd64 の署名
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig
```
arm64 の署名
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig
```
+ **Amazon S3 バケット内の Debian スクリプトへのアクセスリンク**:
amd64 のアクセスリンク
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb
```
arm64 のアクセスリンク
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.deb
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)
1.
**適切なパブリックキー、amd64 の署名、arm64 の署名、および Amazon S3 バケットでホストされている Debian スクリプトへの対応するアクセスリンクをダウンロードしてください**
次のコマンドでは、アカウント ID を適切な AWS アカウント ID に置き換え、リージョンを現在のリージョンに置き換えます。
```
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb ./amazon-guardduty-agent-1.9.2.amd64.deb
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig ./amazon-guardduty-agent-1.9.2.amd64.sig
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem ./publickey.pem
```
1. プライベートキーをデータベースにインポートします。
```
gpg --import publickey.pem
```
gpg はインポートの成功を示しています。
```
gpg: key 093FF49D: public key "AwsGuardDuty" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
1. 署名を検証する
```
gpg --verify amazon-guardduty-agent-1.9.2.amd64.sig amazon-guardduty-agent-1.9.2.amd64.deb
```
検証が成功すると、次の結果のようなメッセージが表示されます。
出力例:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: Good signature from "AwsGuardDuty"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7478 91EF 5378 1334 4456 7603 06C9 06A7 093F F49D
```
これで、Debian を使用して GuardDuty セキュリティエージェントをインストールできます。
ただし、検証が失敗した場合は、Debian パッケージの署名が改ざんされている可能性があることを意味します。
例:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: BAD signature from "AwsGuardDuty"
```
次のコマンドを使用して、データベースからパブリックキーを削除します。
```
gpg --delete-keys AwsGuardDuty
```
次に、検証プロセスを再試行します。
1. 「[Linux または macOS から SSH で接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html)」。
1. 次のコマンドを使用して GuardDuty セキュリティエージェントをインストールします。
```
sudo dpkg -i amazon-guardduty-agent-1.9.2.amd64.deb
```
1. GuardDuty エージェントが正常にインストールされているかどうかを検証します。これらの手順の詳細については、「[GuardDuty セキュリティエージェントのインストールステータスの検証](#validate-ec2-gdu-agent-installation-healthy)」を参照してください。
------
## メモリ不足エラー
Amazon EC2 の GuardDuty セキュリティエージェントを手動でインストールまたは更新するときに `out-of-memory` エラーが発生した場合は、「[メモリ不足の問題のトラブルシューティング](troubleshooting-guardduty-runtime-monitoring.md#troubleshoot-ec2-cpu-out-of-memory-error)」を参照してください。
## GuardDuty セキュリティエージェントのインストールステータスの検証
GuardDuty セキュリティエージェントをインストールするステップを実行した後、次のステップを使用してエージェントのステータスを検証します。
**GuardDuty セキュリティエージェントが正常であるかを検証するには**
1. 「[Linux または macOS から SSH で接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html)」。
1. 次のコマンドを実行して、GuardDuty セキュリティエージェントのステータスを確認します。
```
sudo systemctl status amazon-guardduty-agent
```
セキュリティエージェントのインストールログを表示する場合は、`/var/log/amzn-guardduty-agent/` で確認できます。
ログを表示するには、`sudo journalctl -u amazon-guardduty-agent` を実行します。
# Amazon EC2 インスタンスの GuardDuty セキュリティエージェントの手動更新
GuardDuty は、セキュリティエージェントバージョンの更新をリリースします。セキュリティエージェントを手動で管理する場合、Amazon EC2 インスタンスのエージェントを更新する責任がユーザーにあります。新しいエージェントバージョンについては、Amazon EC2 インスタンスの「[GuardDuty セキュリティエージェントのリリースバージョン](runtime-monitoring-agent-release-history.md)」を参照してください。新しいエージェントバージョンリリースに関する通知を受け取るには、「[Amazon SNS GuardDuty のお知らせへのサブスクライブ](guardduty_sns.md)」を参照してください。
**Amazon EC2 インスタンスのセキュリティエージェントを手動で更新するには**
セキュリティエージェントを更新するプロセスは、セキュリティエージェントをインストールするプロセスと同じです。エージェントのインストールに使用した方法に応じて、Amazon EC2 インスタンスの「[セキュリティエージェントの手動インストール](installing-gdu-security-agent-ec2-manually.md)」のステップを実行できます。
[方法 1 を使用する場合 - を使用すると AWS Systems Manager](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#manage-ssm-ec2-instance-runtime-monitoring)、**Run コマンド**を使用してセキュリティエージェントを更新できます。更新するエージェントバージョンを使用します。
「[メソッド 2 - Linux パッケージマネージャーを使用する](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#heading:r2l:)」を使用する場合は、「[セキュリティエージェントの手動インストール](installing-gdu-security-agent-ec2-manually.md)」セクションに記載されたスクリプトを使用できます。スクリプトには、既に最新のエージェントリリースバージョンが含まれています。最近リリースされたエージェントバージョンについては、「[Amazon EC2 インスタンス用の GuardDuty セキュリティエージェントバージョン](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history)」を参照してください。
セキュリティエージェントを更新した後、ログを確認してインストールステータスを確認できます。詳細については、「[GuardDuty セキュリティエージェントのインストールステータスの検証](installing-gdu-security-agent-ec2-manually.md#validate-ec2-gdu-agent-installation-healthy)」を参照してください。
# Fargate の自動セキュリティエージェントの管理 (Amazon ECS のみ)
Runtime Monitoring は、GuardDuty を介してのみ Amazon ECS クラスター (AWS Fargate) のセキュリティエージェントの管理をサポートします。Amazon ECS クラスターでのセキュリティエージェントの手動管理はサポートされていません。
このセクションのステップに進む前に、必ず「[AWS Fargate (Amazon ECS のみ) サポートの前提条件](prereq-runtime-monitoring-ecs-support.md)」に従ってください。
「[Amazon ECS-Fargate リソースで GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-ecs-fargate.md#gdu-runtime-approaches-agent-deployment-ecs-clusters)」に応じて、リソースの GuardDuty 自動エージェントを有効にする任意の方法を選択します。
**Topics**
## マルチアカウント環境用の GuardDuty エージェントの設定
マルチアカウント環境では、委任 GuardDuty 管理者アカウントのみが、メンバーアカウントの自動エージェント設定を有効または無効にすることや、組織内のメンバーアカウントに属する Amazon ECS クラスターの自動エージェント設定を管理することができます。GuardDuty メンバーアカウントからは、この設定を変更できません。委任 GuardDuty 管理者アカウントは、 を使用してメンバーアカウントを管理します AWS Organizations。マルチアカウント環境の詳細については、「[GuardDuty での複数のアカウントの管理](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html)」を参照してください。
### 委任 GuardDuty 管理者アカウントの自動エージェント設定の有効化
------
#### [ Manage for all Amazon ECS clusters (account level) ]
Runtime Monitoring の **[すべてのアカウントについて有効にする]** を選択した場合、次のオプションがあります。
+ [自動エージェント設定] セクションで **[すべてのアカウントについて有効にする]** を選択します。GuardDuty は、起動されるすべての Amazon ECS タスクについてセキュリティエージェントをデプロイして管理します。
+ **[アカウントを手動で設定]** を選択します。
[Runtime Monitoring] セクションで **[アカウントを手動で設定]** を選択した場合、次の操作を行います。
1. [自動エージェント設定] セクションで **[アカウントを手動で設定する]** を選択します。
1. **[委任 GuardDuty 管理者 (このアカウント)]** セクションで **[有効にする]** を選択します。
**[保存]** を選択します。
GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. この Amazon ECS クラスターに、キーと値のペアを`GuardDutyManaged`-`false` というタグを追加します。
1. 信頼できるエンティティ以外は、タグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1.
**注記**
アカウントの自動エージェントの設定を有効にする前に、必ず Amazon ECS クラスターに除外タグを追加してください。追加しないと、GuardDuty サイドカーコンテナが起動される Amazon ECS タスクのすべてのコンテナに接続されます。
**[設定]** タブの **[自動エージェント設定]** で **[有効化]** を選択します。
除外されていない Amazon ECS クラスターの場合、GuardDuty がサイドカーコンテナ内のセキュリティエージェントのデプロイを管理します。
1. **[保存]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. すべてのタスクを含む Amazon ECS クラスターにタグを追加します。キーと値のペアは `GuardDutyManaged`–`true` である必要があります。
1. 信頼できるエンティティ以外は、これらのタグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**注記**
Amazon ECS クラスターに包含タグを使用する場合、自動エージェント設定によって GuardDuty エージェントを明示的に有効にする必要はありません。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
### すべてのメンバーアカウントの自動有効化
------
#### [ Manage for all Amazon ECS clusters (account level) ]
以下の手順は、[Runtime Monitoring] セクションで **[すべてのアカウントで有効化]** を選択したことを前提としています。
1. [自動エージェント設定] セクションで **[すべてのアカウントについて有効にする]** を選択します。GuardDuty は、起動されるすべての Amazon ECS タスクについてセキュリティエージェントをデプロイして管理します。
1. **[保存]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. この Amazon ECS クラスターに、キーと値のペアを`GuardDutyManaged`-`false` というタグを追加します。
1. 信頼できるエンティティ以外は、タグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1.
**注記**
アカウントの自動エージェントの設定を有効にする前に、必ず Amazon ECS クラスターに除外タグを追加してください。追加しないと、GuardDuty サイドカーコンテナが起動される Amazon ECS タスクのすべてのコンテナに接続されます。
**[設定]** タブで、**[編集]** を選択します。
1. **[自動エージェント設定]** セクションで **[すべてのアカウントについて有効にする]** を選択します。
除外されていない Amazon ECS クラスターの場合、GuardDuty がサイドカーコンテナ内のセキュリティエージェントのデプロイを管理します。
1. **[保存]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for selective (inclusion-only) Amazon ECS clusters (cluster level) ]
Runtime Monitoring をどのように有効にするかにかかわらず、以下の手順は組織内のすべてのメンバーアカウントで選択する Amazon ECS Fargate タスクを監視するのに役立ちます。
1. [自動エージェント設定] セクションの設定はどれも有効にしないでください。Runtime Monitoring の設定は、前の手順で選択したものと同じにします。
1. **[保存]** を選択します。
1. 信頼できるエンティティ以外は、これらのタグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**注記**
Amazon ECS クラスターにインクルージョンタグを使用する場合、**[GuardDuty エージェントの自動管理]** を明示的に有効にする必要はありません。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
### 既存のアクティブなメンバーアカウントでエージェントの自動設定を有効にする
------
#### [ Manage for all Amazon ECS clusters (account level) ]
1. [Runtime Monitoring] ページの **[設定]** タブで、自動エージェント 設定の現在のステータスを表示できます。
1. [自動エージェント設定] ペイン内の **[アクティブメンバーアカウント]** セクションで、**[アクション]** を選択します。
1. **[アクション]** から、**[すべての既存のアクティブなメンバーアカウントについて有効にする]** を選択します。
1. **[確認]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. この Amazon ECS クラスターに、キーと値のペアを`GuardDutyManaged`-`false` というタグを追加します。
1. 信頼できるエンティティ以外は、タグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1.
**注記**
アカウントの自動エージェントの設定を有効にする前に、必ず Amazon ECS クラスターに除外タグを追加してください。追加しないと、GuardDuty サイドカーコンテナが起動される Amazon ECS タスクのすべてのコンテナに接続されます。
[自動エージェント設定] セクションの **[設定]** タブから **[アクティブなメンバーアカウント]** で **[アクション]** を選択します。
1. **[アクション]** から、**[すべてのアクティブなメンバーアカウントについて有効にする]** を選択します。
除外されていない Amazon ECS クラスターの場合、GuardDuty がサイドカーコンテナ内のセキュリティエージェントのデプロイを管理します。
1. **[確認]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. すべてのタスクを含む Amazon ECS クラスターにタグを追加します。キーと値のペアは `GuardDutyManaged`–`true` である必要があります。
1. 信頼できるエンティティ以外は、これらのタグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**注記**
Amazon ECS クラスターに包含タグを使用する場合、**[自動エージェント設定]** を明示的に有効にする必要はありません。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
### 新規メンバー用の自動エージェント設定を自動有効化
------
#### [ Manage for all Amazon ECS clusters (account level) ]
1. [Runtime Monitoring] ページで、**[編集]** を選択して既存の設定を更新します。
1. [自動エージェント設定] セクションで **[すべてのアカウントについて有効にする]** を選択します。
1. **[保存]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. この Amazon ECS クラスターに、キーと値のペアを`GuardDutyManaged`-`false` というタグを追加します。
1. 信頼できるエンティティ以外は、タグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1.
**注記**
アカウントの自動エージェントの設定を有効にする前に、必ず Amazon ECS クラスターに除外タグを追加してください。追加しないと、GuardDuty サイドカーコンテナが起動される Amazon ECS タスクのすべてのコンテナに接続されます。
**[設定]** タブの **[自動エージェント設定]** セクションで、**[新しいメンバーアカウントについて自動的に有効にする]** を選択します。
除外されていない Amazon ECS クラスターの場合、GuardDuty がサイドカーコンテナ内のセキュリティエージェントのデプロイを管理します。
1. **[保存]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. すべてのタスクを含む Amazon ECS クラスターにタグを追加します。キーと値のペアは `GuardDutyManaged`–`true` である必要があります。
1. 信頼できるエンティティ以外は、これらのタグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**注記**
Amazon ECS クラスターに包含タグを使用する場合、**[自動エージェント設定]** を明示的に有効にする必要はありません。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
### アクティブなメンバーアカウントの自動エージェント設定を選択的に有効にする
------
#### [ Manage for all Amazon ECS (account level) ]
1. [アカウント] ページで、Runtime Monitoring 自動エージェント設定 (ECS-Fargate) を有効にするアカウントを選択します。複数のアカウントを選択できます。この手順で選択したアカウントで Runtime Monitoring が既に有効になっていることを確認してください。
1. **[保護プランの編集]** から、適切なオプションを選択して **[Runtime Monitoring 自動エージェントを設定 (ECS-Fargate)]** を有効にします。
1. **[確認]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. この Amazon ECS クラスターに、キーと値のペアを`GuardDutyManaged`-`false` というタグを追加します。
1. 信頼できるエンティティ以外は、タグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1.
**注記**
アカウントの GuardDuty エージェントの自動管理を有効にする前に、必ず Amazon ECS クラスターに除外タグを追加してください。追加しないと、GuardDuty サイドカーコンテナが起動される Amazon ECS タスク内のコンテナすべてにアタッチされます。
[アカウント] ページで、Runtime Monitoring 自動エージェント設定 (ECS-Fargate) を有効にするアカウントを選択します。複数のアカウントを選択できます。この手順で選択したアカウントで Runtime Monitoring が既に有効になっていることを確認してください。
除外されていない Amazon ECS クラスターの場合、GuardDuty がサイドカーコンテナ内のセキュリティエージェントのデプロイを管理します。
1. **[保護プランの編集]** から、適切なオプションを選択して **[Runtime Monitoring 自動エージェントを設定 (ECS-Fargate)]** を有効にします。
1. **[保存]** を選択します。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. 監視する Amazon ECS クラスターを含む選択したアカウントで、**[自動エージェント設定]** (または **[Runtime Monitoring 自動エージェント設定 (ECS-Fargate)**]) を有効にしていないことを確認してください。
1. すべてのタスクを含む Amazon ECS クラスターにタグを追加します。キーと値のペアは `GuardDutyManaged`–`true` である必要があります。
1. 信頼できるエンティティ以外は、これらのタグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**注記**
Amazon ECS クラスターに包含タグを使用する場合、**[自動エージェント設定]** を明示的に有効にする必要はありません。
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
------
## スタンドアロンアカウントの GuardDuty エージェント の設定
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. **[設定]** タブ:
1.
**すべての Amazon ECS クラスターの自動エージェント設定を管理するには (アカウントレベル)**
**[AWS Fargate (ECS のみ)]** の **[自動エージェント設定]** セクションで **[有効にする]** を選択します。新しい Fargate Amazon ECS タスクが起動すると、GuardDuty がセキュリティエージェントのデプロイを管理します。
1. **[保存]** を選択します。
1.
**Amazon ECS クラスターの一部を除外して自動エージェント設定を管理するには (クラスターレベル)**
1. すべてのタスクを除外する Amazon ECS クラスターにタグを追加します。キーと値のペアは `GuardDutyManaged`–`false` である必要があります。
1. 信頼できるエンティティ以外は、これらのタグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. **[設定]** タブの **[自動エージェント設定]** セクションで **[有効化]** を選択します。
**注記**
アカウントの GuardDuty エージェントの自動管理を有効にする前に、必ず Amazon ECS クラスターに除外タグを追加してください。追加しないと、セキュリティエージェントが対応する Amazon ECS クラスター内で開始されるすべてのタスクにデプロイされます。
除外されていない Amazon ECS クラスターの場合、GuardDuty がサイドカーコンテナ内のセキュリティエージェントのデプロイを管理します。
1. **[保存]** を選択します。
1.
**Amazon ECS クラスターの一部を含めて自動エージェント設定を管理するには (クラスターレベル)**
1. すべてのタスクを含む Amazon ECS クラスターにタグを追加します。キーと値のペアは `GuardDutyManaged`–`true` である必要があります。
1. 信頼できるエンティティ以外は、これらのタグを変更しないようにしてください。「*AWS Organizations ユーザーガイド*」の「[認められている原則による場合を除き、タグが変更されないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin)」に記載されているポリシーが、ここに適用できるように変更されました。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. GuardDuty でサービスの一部であるタスクをモニタリングする場合は、Runtime Monitoring を有効にした後に新しいサービスデプロイが必要です。Runtime Monitoring を有効にする前に特定の ECS サービスの最後のデプロイが開始された場合は、サービスを再起動するか、`forceNewDeployment` を使用してサービスを更新できます。
サービスを更新するステップについては、以下のリソースを参照してください。
+ 「*Amazon Elastic Container Service デベロッパーガイド*」の「[コンソールを使用した Amazon ECS サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html)」。
+ 「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」。
+ 「*AWS CLI コマンドリファレンス*」の「[update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html)」。
# Amazon EKS リソースのセキュリティエージェントの自動管理
Runtime Monitoring では、GuardDuty 自動設定と手動によるセキュリティエージェントの有効化をサポートしています。このセクションでは、Amazon EKS クラスターの自動エージェント設定を有効にするステップについて説明します。
続行する前に、「[Amazon EKS クラスターサポートの前提条件](prereq-runtime-monitoring-eks-support.md)」に従っていることを確認してください。
「[GuardDuty によるセキュリティエージェントの管理](how-runtime-monitoring-works-eks.md#eks-runtime-using-gdu-agent-management-auto)」の方法に関する任意のアプローチに応じて、以下のセクションのステップを適宜選択します。
## マルチアカウント環境の自動エージェントの設定
マルチアカウント環境では、委任 GuardDuty 管理者アカウントのみが、メンバーアカウントの自動エージェント設定を有効または無効にすることや、組織内のメンバーアカウントに属する EKS クラスターの自動エージェントを管理することができます。GuardDuty メンバーアカウントからは、この設定を変更できません。委任 GuardDuty 管理者アカウントは、 を使用してメンバーアカウントを管理します AWS Organizations。マルチアカウント環境の詳細については、「[複数のアカウントの管理](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html)」を参照してください。
### 委任 GuardDuty 管理者アカウントの自動エージェント設定
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | [Runtime Monitoring] セクションで **[すべてのアカウントについて有効にする]** を選択した場合、次のオプションがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [Runtime Monitoring] セクションで **[アカウントを手動で設定]** を選択した場合、次の操作を行います。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) **[保存]** を選択します。 |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | 次の手順から、該当するシナリオを 1 つ選択してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| 包含タグを使用した選択的な EKS クラスターのモニタリング | Runtime Monitoring をどのように有効にするかにかかわらず、以下のステップはアカウント内の選択的な EKS クラスターをモニタリングするために役立ちます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| GuardDuty セキュリティエージェントの手動管理 | Runtime Monitoring をどのように有効にするかにかかわらず、EKS クラスターのセキュリティエージェントを手動で管理できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
### すべてのメンバーアカウントの自動エージェントを自動で有効にする
**注記**
メンバーアカウントの設定を更新するには、最大 24 時間かかる場合があります。
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | このトピックは、すべてのメンバーアカウントの Runtime Monitoring を有効にするためのものです。そのため、以下のステップでは、[Runtime Monitoring] セクションで **[すべてのアカウントについて有効にする]** を選択していることを前提としています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | 次の手順から、該当するシナリオを 1 つ選択してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| 包含タグを使用した選択的な EKS クラスターのモニタリング | Runtime Monitoring をどのように有効にするかにかかわらず、以下のステップは組織内のすべてのメンバーアカウントの選択的な EKS クラスターをモニタリングするために役立ちます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| GuardDuty セキュリティエージェントの手動管理 | Runtime Monitoring をどのように有効にするかにかかわらず、EKS クラスターのセキュリティエージェントを手動で管理できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
### すべての既存のアクティブなメンバーアカウントの自動エージェントを有効にする
**注記**
メンバーアカウントの設定を更新するには、最大 24 時間かかる場合があります。
**組織内の既存のアクティブなメンバーアカウントの GuardDuty セキュリティエージェントを管理するには**
+ GuardDuty が組織内の既存のアクティブなメンバーアカウントに属する EKS クラスターからランタイムイベントを受信できるようにするには、これらの EKS クラスターの GuardDuty セキュリティエージェントを管理するための推奨アプローチを選択する必要があります。上記の各アプローチの詳細については、「[Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters)」を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)
### 新規メンバー用の自動エージェント設定を自動有効化
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | 次の手順から、該当するシナリオを 1 つ選択してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| 包含タグを使用した選択的な EKS クラスターのモニタリング | Runtime Monitoring をどのように有効にするかにかかわらず、以下のステップは組織内の新しいメンバーアカウントの選択的な EKS クラスターをモニタリングするために役立ちます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| GuardDuty セキュリティエージェントの手動管理 | Runtime Monitoring をどのように有効にするかにかかわらず、EKS クラスターのセキュリティエージェントを手動で管理できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
### アクティブなメンバーアカウントの自動エージェントを選択的に設定する
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | 次の手順から、該当するシナリオを 1 つ選択してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| 包含タグを使用した選択的な EKS クラスターのモニタリング | Runtime Monitoring をどのように有効にするかにかかわらず、以下のステップは選択したアカウントに属する選択的な EKS クラスターをモニタリングするために役立ちます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| GuardDuty セキュリティエージェントの手動管理 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
## スタンドアロンアカウント用の自動エージェントの設定
スタンドアロンアカウントは、特定の の で保護プランを有効または無効にする決定を所有 AWS アカウント します AWS リージョン。
アカウントが を通じて AWS Organizations、または招待方法によって GuardDuty 管理者アカウントに関連付けられている場合、このセクションはアカウントには適用されません。詳細については、「[マルチアカウント環境の Runtime Monitoring の有効化](enable-runtime-monitoring-multiple-acc-env.md)」を参照してください。
Runtime Monitoring を有効にした後、自動設定または手動デプロイを使用して GuardDuty セキュリティエージェントをインストールしてください。次の手順に記載されたすべてのステップを完了する一環として、セキュリティエージェントをインストールしてください。
すべての Amazon EKS リソースをモニタリングするか、選択した Amazon EKS リソースをモニタリングするかに応じて、任意の方法を選択し、次の表のステップに従います。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
1. ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
1. **[設定]**タブで**[有効にする]**を選択し、アカウントの自動エージェント設定を有効にします。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)
# Amazon EKS クラスターのセキュリティエージェントの手動管理
このセクションでは、Runtime Monitoring (または EKS Runtime Monitoring) を有効にした後に Amazon EKS アドオンエージェント (GuardDuty エージェント) を管理する方法について説明します。Runtime Monitoring を使用するには、Runtime Monitoring を有効にして Amazon EKS アドオン `aws-guardduty-agent` を設定する必要があります。GuardDuty が潜在的な脅威を検出し、「[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)」を生成するには、両方のステップを実行する必要があります。
エージェントを手動で管理するには、前提条件として VPC エンドポイントを作成する必要があります。これは、GuardDuty がランタイムイベントを受信するのに役立ちます。その後、GuardDuty が Amazon EKS リソースからランタイムイベントを受信し始めるように、セキュリティエージェントをインストールできます。GuardDuty がこのリソースの新しいエージェントバージョンをリリースすると、アカウントでエージェントバージョンを更新できます。
**Topics**
+ [前提条件 – Amazon VPC エンドポイントの作成](eksrunmon-prereq-deploy-security-agent.md)
+ [Amazon EKS リソースへの GuardDuty セキュリティエージェントの手動インストール](eksrunmon-deploy-security-agent.md)
+ [Amazon EKS リソースのセキュリティエージェントの手動更新](eksrunmon-update-security-agent.md)
# 前提条件 – Amazon VPC エンドポイントの作成
GuardDuty セキュリティエージェントをインストールする前に、Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを作成する必要があります。これにより、GuardDuty は Amazon EKS リソースのランタイムイベントを受信できるようになります。
**注記**
VPC エンドポイントの使用に追加コストはかかりません。
任意のアクセス方法を選択して、Amazon VPC エンドポイントを作成します。
------
#### [ Console ]
**VPC エンドポイントを作成するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインの **[仮想プライベートクラウド]** で、**[VPC]** を選択します。
1. **[エンドポイントの作成]** を選択します。
1. **[エンドポイントの作成]** ページの **[サービスカテゴリ]** で **[その他のエンドポイントサービス**] を選択します。
1. **[サービス名]** に **com.amazonaws.*us-east-1*.guardduty-data** と入力します。
必ず *us-east-1* を正しいリージョンに置き換えてください。これは、 AWS アカウント ID に属する EKS クラスターと同じリージョンである必要があります。
1. **[サービスの確認]** を選択します。
1. サービス名が正常に確認されたら、クラスターが置かれている **[VPC]** を選択します。次のポリシーを追加して、VPC エンドポイントの使用を指定されたアカウントのみに制限します。このポリシー下で提供されている組織 `Condition` を使用して、次のポリシーを更新してエンドポイントへのアクセスを制限できます。組織内の特定のアカウント ID に VPC エンドポイントサポートを提供するには、「[Organization condition to restrict access to your endpoint](#gdu-shared-vpc-endpoint-org)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow",
"Principal": "*"
},
{
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111122223333"
}
},
"Action": "*",
"Resource": "*",
"Effect": "Deny",
"Principal": "*"
}
]
}
```
------
`aws:PrincipalAccount` アカウント ID は、VPC と VPC エンドポイントを含むアカウントと一致する必要があります。次のリストは、VPC エンドポイントを他の AWS アカウント ID と共有する方法を示しています。
**エンドポイントへのアクセスを制限する組織の条件**
+ VPC エンドポイントにアクセスする複数のアカウントを指定するには、`"aws:PrincipalAccount": "111122223333"`を以下に置き換えます。
```
"aws:PrincipalAccount": [
"666666666666",
"555555555555"
]
```
+ 組織のすべてのメンバーが VPC エンドポイントにアクセスできるようにするには、`"aws:PrincipalAccount": "111122223333"` を以下に置き換えます。
```
"aws:PrincipalOrgID": "o-abcdef0123"
```
+ リソースへのアクセスを組織 ID に制限するには、`ResourceOrgID` をポリシーに追加します。
詳細については、「[ResourceOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid)」を参照してください。
```
"aws:ResourceOrgID": "o-abcdef0123"
```
1. **[追加設定]** で **[DNS 名を有効にする]** を選択します。
1. **[サブネット]** で、クラスターが存在するサブネットを選択します。
1. **[セキュリティグループ]** で、VPC (または EKS クラスター) からのインバウンドポート 443 が有効になっているセキュリティグループを選択します。インバウンドポート 443 が有効になっているセキュリティグループがまだない場合は、[セキュリティグループを作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group)します。
VPC (またはインスタンス) へのインバウンド許可を制限する際に問題が発生した場合は、任意の IP アドレス `(0.0.0.0/0)` からのインバウンド 443 ポートをサポートできます。ただし、GuardDuty では、VPC の CIDR ブロックに一致する IP アドレスを使用することをお勧めします。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC CIDR ブロック](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-cidr-blocks.html)」を参照してください。
------
#### [ API/CLI ]
**VPC エンドポイントを作成するには**
+ [CreateVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html) を呼び出します。
+ パラメータで以下の値を使用します。
+ **[サービス名]** に **com.amazonaws.*us-east-1*.guardduty-data** と入力します。
必ず *us-east-1* を正しいリージョンに置き換えてください。これは、 AWS アカウント ID に属する EKS クラスターと同じリージョンである必要があります。
+ [DNSOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DnsOptions.html) には、プライベート DNS オプションを `true` に設定して有効にします。
+ 詳細については AWS Command Line Interface、「[create-vpc-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-vpc-endpoint.html)」を参照してください。
------
ステップに従った後、「[VPC エンドポイント設定の検証](validate-vpc-endpoint-config-runtime-monitoring.md)」を参照して、VPC エンドポイントが正しく設定されていることを確認します。
# Amazon EKS リソースへの GuardDuty セキュリティエージェントの手動インストール
このセクションでは、特定の EKS クラスターに GuardDuty セキュリティエージェントを初めてデプロイする方法について説明します。このセクションに進む前に、アカウントの前提条件をセットアップし、Runtime Monitoring を有効にしていることを確認してください。Runtime Monitoring を有効にしないと、GuardDuty セキュリティエージェント (EKS アドオン) は動作しません。
任意のアクセス方法を選択して、GuardDuty セキュリティエージェントを初めてデプロイします。
------
#### [ Console ]
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. **[クラスター名]** を選択します。
1. **[アドオン]** タブを選択してください。
1. **[その他のアドオンを入手]** を選択します。
1. **[アドオンの選択]** ページで、**[Amazon GuardDuty EKS Runtime Monitoring]** を選択します。
1. GuardDuty では、最新およびデフォルトのエージェント**バージョン**を選択することをお勧めします。
1. **[選択したアドオン設定の設定]** ページで、デフォルトの設定を使用します。EKS アドオンの **[ステータス]** は、**[アクティベーションが必要]** の場合は、**[GuardDuty を有効化]** を選択します。このアクションにより、GuardDuty コンソールが開き、アカウントの Runtime Monitoring を設定できます。
1. アカウントに Runtime Monitoring を設定したら、Amazon EKS コンソールに戻ってください。EKS アドオンの **[ステータス]** は、**[インストール準備完了]** に変わっているはずです。
1.
**(オプション) EKS アドオン設定スキーマの提供**
アドオン **[バージョン]** で **[v1.5.0]** 以上を選択した場合、Runtime Monitoring は GuardDuty エージェントの特定のパラメータの設定をサポートします。パラメータ範囲の詳細については、「[EKS アドオンパラメータを設定する](guardduty-configure-security-agent-eks-addon.md)」を参照してください。
1. **[オプションの構成設定]** を展開して、設定可能なパラメータとその期待値と形式を表示します。
1. パラメータを設定します。値は、「[EKS アドオンパラメータを設定する](guardduty-configure-security-agent-eks-addon.md)」に記載されたされた範囲内である必要があります。
1. 詳細設定に基づいてアドオンを作成するには、**[変更の保存]** を選択します。
1. **[競合解決方法]** で選択したオプションが、パラメータの値をデフォルト値以外の値に更新する際の競合を解決するために使用されます。記載されたオプションの詳細については、「*Amazon EKS API リファレンス*」の「[resolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts)」を参照してください。
1. [**次へ**] を選択します。
1. **[確認と作成]** ページで、すべての詳細を確認し、**[作成]** を選択します。
1. クラスターの詳細に戻り、**[リソース]** タブを選択します。
1. **[aws-guardduty-agent]** というプレフィックスが付いた新しいポッドを表示できます。
------
#### [ API/CLI ]
Amazon EKS アドオンエージェント (`aws-guardduty-agent`) は、次のオプションのいずれかを使用して設定できます。
+ アカウントの [[CreateAddon]](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateAddon.html) を実行します。
+
**注記**
アドオン `version` で **[v1.5.0 以上]** を選択した場合、Runtime Monitoring は GuardDuty エージェントの特定のパラメータの設定をサポートします。詳細については、「[EKS アドオンパラメータを設定する](guardduty-configure-security-agent-eks-addon.md)」を参照してください。
リクエストパラメータに以下の値を使用します。
+ `addonName` に「`aws-guardduty-agent`」と入力します。
アドオンバージョン `v1.5.0`以降でサポートされている設定可能な値を使用する場合は、次の AWS CLI 例を使用できます。赤で強調表示されたプレースホルダー値と、設定済みの値に関連付けられた `Example.json` を必ず置き換えてください。
```
aws eks create-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json'
```
**Example.json**
```
{
"priorityClassName": "aws-guardduty-agent.priorityclass-high",
"dnsPolicy": "Default",
"resources": {
"requests": {
"cpu": "237m",
"memory": "512Mi"
},
"limits": {
"cpu": "2000m",
"memory": "2048Mi"
}
}
}
```
+ サポートされている `addonVersion` については、「[GuardDuty セキュリティエージェントでサポートされている Kubernetes のバージョン](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version)」を参照してください。
+ または、 を使用することもできます AWS CLI。詳細については、「[create-addon](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-addon.html)」を参照してください。
------
**VPC エンドポイントのプライベート DNS 名**
デフォルトでは、セキュリティエージェントは VPC エンドポイントのプライベート DNS 名を解決して接続します。FIPS 以外のエンドポイントの場合、プライベート DNS は以下の形式で表示されます。
FIPS 以外のエンドポイント – `guardduty-data.us-east-1.amazonaws.com`
us AWS リージョン*-east-1* の は、リージョンに応じて変わります。
# Amazon EKS リソースのセキュリティエージェントの手動更新
GuardDuty セキュリティエージェントを手動で管理する場合、アカウントのセキュリティエージェントを更新する責任がユーザーにあります。新しいエージェントバージョンに関する通知については、「[GuardDuty セキュリティエージェントのリリースバージョン](runtime-monitoring-agent-release-history.md)」の RSS フィードにサブスクライブできます。
セキュリティエージェントを最新バージョンに更新して、追加されたサポートと改善を活用できます。現在のエージェントバージョンが標準サポートを終了していて、引き続き Runtime Monitoring (または EKS Runtime Monitoring) を使用する場合は、利用可能な次のバージョンまたは現在のエージェントバージョンに更新する必要があります。
**前提条件**
セキュリティエージェントのバージョンを更新する前に、現在使用する予定のエージェントのバージョンが Kubernetes バージョンと互換性があることを確認してください。詳細については、「[GuardDuty セキュリティエージェントでサポートされている Kubernetes のバージョン](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version)」を参照してください。
------
#### [ Console ]
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. **[クラスター名]** を選択します。
1. **[クラスター情報]** で、**[アドオン]** タブを選択します。
1. **[アドオン]** タブで、**[GuardDuty Runtime Monitoring]** を選択します。
1. **[編集]** を選択してエージェントの詳細を更新します。
1. **[GuardDuty EKS Runtime Monitoring の設定]** ページで、詳細を更新します。
1.
**(オプション) オプションの設定の更新**
EKS アドオン **[バージョン]** が *1.5.0* 以降の場合は、アドオン設定スキーマを更新することもできます。
1. **[オプションの構成設定]** を展開して、設定スキーマを表示します。
1. 「[EKS アドオンパラメータを設定する](guardduty-configure-security-agent-eks-addon.md)」に記載された範囲に基づいてパラメータ値を更新します。
1. **[変更を保存]** を選択して更新を開始します。
1. **[競合解決方法]** で選択したオプションが、パラメータの値をデフォルト値以外の値に更新する際の競合を解決するために使用されます。記載されたオプションの詳細については、「*Amazon EKS API リファレンス*」の「[resolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts)」を参照してください。
------
#### [ API/CLI ]
Amazon EKS クラスターの GuardDuty セキュリティエージェントを更新するには、「[アドオンの更新](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html#updating-an-add-on)」を参照してください。
**注記**
アドオン `version` で **[1.5.0]** 以降を選択した場合、Runtime Monitoring は GuardDuty エージェントの特定のパラメータの設定をサポートします。パラメータ範囲の詳細については、「[EKS アドオンパラメータを設定する](guardduty-configure-security-agent-eks-addon.md)」を参照してください。
アドオンバージョン *1.5.0 以降*でサポートされている設定可能な値を使用する場合は、次の AWS CLI 例を使用できます。赤で強調表示されたプレースホルダー値と、設定済みの値に関連付けられた `Example.json` を必ず置き換えてください。
```
aws eks update-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json'
```
**Example.json**
```
{
"priorityClassName": "aws-guardduty-agent.priorityclass-high",
"dnsPolicy": "Default",
"resources": {
"requests": {
"cpu": "237m",
"memory": "512Mi"
},
"limits": {
"cpu": "2000m",
"memory": "2048Mi"
}
}
}
```
------
Amazon EKS アドオンバージョンが 1.5.0 以降で、アドオンスキーマを設定している場合は、クラスターに値が正しく表示されるかどうかを確認できます。詳細については、「[設定スキーマの更新の検証](guardduty-configure-security-agent-eks-addon.md#gdu-verify-eks-add-on-configuration-param)」を参照してください。
# Amazon EKS の GuardDuty セキュリティエージェント (アドオン) パラメータを設定する
Amazon EKS の GuardDuty セキュリティエージェントの特定のパラメータを設定できます。このサポートは、GuardDuty セキュリティエージェントバージョン 1.5.0 以降で利用できます。最新のアドオンバージョンについては、「[Amazon EKS リソースの GuardDuty セキュリティエージェントバージョン](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)」を参照してください。
**セキュリティエージェント設定スキーマを更新する理由**
GuardDuty セキュリティエージェントの設定スキーマは、Amazon EKS クラスター内のすべてのコンテナで同じです。デフォルト値が関連するワークロードおよびインスタンスサイズと一致しない場合は、CPU 設定、メモリ設定、`PriorityClass`、および `dnsPolicy` 設定の設定を検討してください。Amazon EKS クラスターの GuardDuty エージェントを管理する方法に関係なく、これらのパラメータの既存の設定を設定または更新できます。
## 設定されたパラメータを使用した自動エージェント設定動作
GuardDuty がユーザーに代わってセキュリティエージェント (EKS アドオン) を管理する場合、必要に応じてアドオンを更新します。GuardDuty は、設定可能なパラメータの値をデフォルト値に設定します。ただし、パラメータを目的の値に更新することはできます。これにより競合が発生する場合、[resolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) のデフォルトオプションは `None` です。
## 設定可能なパラメータと値
アドオンパラメータを設定するステップについては、以下を参照してください。
+ [Amazon EKS リソースへの GuardDuty セキュリティエージェントの手動インストール](eksrunmon-deploy-security-agent.md) または
+ [Amazon EKS リソースのセキュリティエージェントの手動更新](eksrunmon-update-security-agent.md)
次の表は、Amazon EKS アドオンを手動でデプロイしたり、既存のアドオン設定を更新したりするために使用できる範囲と値を示しています。
**CPU 設定**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
**[メモリの設定]**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
**`PriorityClass` 設定**
GuardDuty が Amazon EKS アドオンを作成する場合、割り当てられる `PriorityClass` は `aws-guardduty-agent.priorityclass` です。つまり、エージェントポッドの優先度に基づいてアクションは実行されません。このアドオンパラメータは、次のいずれかの `PriorityClass` オプションを選択して設定できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
**1** Kubernetes には、`system-cluster-critical` と `system-node-critical` の 2 つの `PriorityClass` オプションがあります。詳細については、「*Kubernetes ドキュメント*」の「[PriorityClass](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption)」を参照してください。
**`dnsPolicy` 設定**
Kubernetes がサポートする次の DNS ポリシーオプションのいずれかを選択します。設定が指定されていない場合は、`ClusterFirst` がデフォルト値として使用されます。
+ `ClusterFirst`
+ `ClusterFirstWithHostNet`
+ `Default`
これらのポリシーの詳細については、「*Kubernetes ドキュメント*」の「[Pod の DNS ポリシー](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy)」を参照してください。
## 設定スキーマの更新の検証
パラメータを設定した後、次のステップを実行して設定スキーマが更新されていることを確認します。
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[クラスター]** ページで、更新を検証する **[クラスター名]** を選択します。
1. **[リソース]** タブを選択してください。
1. **[リソースタイプ]** ペインの **[ワークロード]** で、**[DaemonSets]** を選択します。
1. **[aws-guardduty-agent]** を選択します。
1. **[aws-guardduty-agent]** ページで **[Raw ビュー]** を選択して、フォーマットされていない JSON レスポンスを表示します。設定可能なパラメータに、指定した値が表示されていることを確認します。
確認した後、GuardDuty コンソールに切り替えます。対応する を選択し、Amazon EKS クラスターのカバレッジステータス AWS リージョン を表示します。詳細については、「[Amazon EKS クラスターのランタイムカバレッジとトラブルシューティング](eks-runtime-monitoring-coverage.md)」を参照してください。
# VPC エンドポイント設定の検証
セキュリティエージェントを手動でインストールするか、GuardDuty 自動設定を使用してインストールした後、このドキュメントを使用して VPC エンドポイント設定を検証できます。リソースタイプの[ランタイムカバレッジの問題](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-assessing-coverage.html)をトラブルシューティングした後、これらのステップを使用することもできます。ステップが期待どおりに機能し、カバレッジステータスが **[正常]** として表示される可能性があることを確認できます。
次のステップを使用して、リソースタイプの VPC エンドポイント設定が VPC 所有者アカウントで正しく設定されていることを確認します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) で Amazon VPC コンソールを開きます。
1. ナビゲーションペインの **[仮想プライベートクラウド]** で、**[VPC]** を選択します。
1. **[VPC]** ページで、**VPC ID** に関連付けられた **IPv4 CIDR** を選択します。
1. ナビゲーションペインの **[仮想プライベートクラウド]** で、**[VPC]** を選択します。
1. **[エンドポイント]** テーブルで、**[com.amazonaws.*us-east-1*.guardduty-data]** のような **[サービス名]** を持つ行を選択します。リージョン (`us-east-1`) はエンドポイントによって異なる場合があります。
1. エンドポイントの詳細のパネルが表示されます。**[セキュリティグループ]** タブで、関連する **[グループ ID]** リンクを選択して詳細を確認します。
1. **[セキュリティグループ]** テーブルで、関連する **[セキュリティグループ ID]** を持つ行を選択して詳細を表示します。
1. **[インバウンドルール]** タブで、**[ポート範囲]** が **[443]**、**[ソース]** が **[IPv4 CIDR]** からコピーされた値であるイングレスポリシーがあることを確認します。インバウンドルールは、インスタンスに到達できる受信トラフィックを制御します。次の図は、GuardDuty セキュリティエージェントが使用する VPC に関連付けられているセキュリティグループのインバウンドルールを示しています。
インバウンドポート 443 が有効になっているセキュリティグループがまだない場合は、「*Amazon EC2 ユーザーガイド*」の[セキュリティグループの作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group)に関するページを参照します。
VPC (またはクラスター) へのインバウンド許可を制限する際に問題が発生した場合は、任意の IP アドレス (0.0.0.0/0) からのインバウンド 443 ポートをサポートします。
次のリストには、セキュリティエージェントをインストールまたは更新した後に知っておくべき項目が含まれています。
「**ランタイムカバレッジの評価**」
セキュリティエージェントをインストールまたは更新した後の次のステップは、リソースのランタイムカバレッジを評価することです。ランタイムカバレッジステータスが **[異常]** の場合、問題をトラブルシューティングする必要があります。詳細については、「[ランタイムカバレッジの問題とトラブルシューティング](runtime-monitoring-assessing-coverage.md)」を参照してください。
ランタイムカバレッジのステータスが **[正常]** と表示されている場合は、Runtime Monitoring がランタイムイベントを収集して受信できることを示します。これらのイベントのリストについては、「[収集されたランタイムイベントタイプ](runtime-monitoring-collected-events.md)」を参照してください。
**エンドポイントのプライベート DNS 名**
リソースに GuardDuty セキュリティエージェントをインストールすると、デフォルトで VPC エンドポイントのプライベート DNS 名を解決して接続します。FIPS 以外のエンドポイントの場合、プライベート DNS は以下の形式で表示されます。
`guardduty-data.us-east-1.amazonaws.com`
us AWS リージョン*-east-1* の は、リージョンに応じて変わります。
**ホストには 2 つのセキュリティエージェントがインストールされる場合があります**
Amazon EC2 インスタンスの GuardDuty セキュリティエージェントを使用する場合、Amazon EKS クラスター内の基盤となるホストにエージェントをインストールして使用することができます。その EKS クラスターにセキュリティエージェントを既にデプロイしている場合、同じホストで 2 つのセキュリティエージェントが同時に実行される可能性があります。このシナリオでの GuardDuty の仕組みについては、「[同じホスト上のセキュリティエージェント](two-security-agents-installed-on-ec2-node.md)」を参照してください。
# ランタイムカバレッジ統計の確認と問題のトラブルシューティング
Runtime Monitoring を有効にし、GuardDuty セキュリティエージェントがリソースにデプロイされると、GuardDuty は対応するリソースタイプのカバレッジ統計と、アカウントに属するリソースの個別のカバレッジステータスを提供します。カバレッジステータスは、Runtime Monitoring が有効になっていること、Amazon VPC エンドポイントが作成されていること、対応するリソースの GuardDuty セキュリティエージェントがデプロイされていることを確認することによって決定されます。**[正常]** カバレッジステータスは、リソースに関連するランタイムイベントが発生すると、GuardDuty が Amazon VPC エンドポイントを通じてそのランタイムイベントを受信し、動作を監視できることを示します。Runtime Monitoring の設定、Amazon VPC エンドポイントの作成または GuardDuty セキュリティエージェントのデプロイ時に問題が発生した場合、カバレッジステータスは **[異常]** と表示されます。カバレッジステータスが異常の場合、GuardDuty は対応するリソースのランタイム動作を受信または監視できず、Runtime Monitoring の結果を生成することもできません。
以下のトピックは、カバレッジ統計の確認、EventBridge 通知の設定、特定のリソースタイプのカバレッジ問題のトラブルシューティングに役立ちます。
**Topics**
+ [Amazon EC2 インスタンスのランタイムカバレッジとトラブルシューティング](gdu-assess-coverage-ec2.md)
+ [Amazon ECS クラスターのランタイムカバレッジとトラブルシューティング](gdu-assess-coverage-ecs.md)
+ [Amazon EKS クラスターのランタイムカバレッジとトラブルシューティング](eks-runtime-monitoring-coverage.md)
# Amazon EC2 インスタンスのランタイムカバレッジとトラブルシューティング
Amazon EC2 リソースの場合、ランタイムカバレッジはインスタンスレベルで評価されます。Amazon EC2 インスタンスは、 AWS 環境内のさまざまなタイプのアプリケーションやワークロードを実行できます。この機能は Amazon ECS によって管理されている Amazon EC2 インスタンスもサポートしており、Amazon EC2 インスタンスで Amazon ECS クラスターを実行している場合、インスタンスレベルでのカバレッジの問題は Amazon EC2 ランタイムカバレッジに表示されます。
**Topics**
+ [カバレッジ統計の確認](#review-coverage-statistics-ec2-runtime-monitoring)
+ [カバレッジステータス変更時の EventBridge 通知](#ec2-runtime-monitoring-coverage-status-change)
+ [Amazon EC2 ランタイムカバレッジの問題のトラブルシューティング](#ec2-runtime-monitoring-coverage-issues-troubleshoot)
## カバレッジ統計の確認
自分のアカウントまたはメンバーアカウントに関連付けられた Amazon EC2 インスタンスのカバレッジ統計は、選択した AWS リージョンのすべての EC2 インスタンスに対する正常な EC2 インスタンスの割合です。次の式はこれを次のように表します。
(正常なインスタンス/すべてのインスタンス)\$1100
Amazon ECS クラスターに GuardDuty セキュリティエージェントもデプロイしている場合、Amazon EC2 インスタンスで実行されている Amazon ECS クラスターに関連するインスタンスレベルのカバレッジの問題は、Amazon EC2 インスタンスのランタイムカバレッジ問題として表示されます。
いずれかのアクセス方法を選択して、アカウントのカバレッジ統計を確認してください。
------
#### [ Console ]
+ にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
+ ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
+ **[ランタイムカバレッジ]** タブを選択します。
+ **[EC2 インスタンスのランタイムカバレッジ]** タブでは、**[クラスターリスト]** テーブルにある各 Amazon EC2 インスタンスのカバレッジステータス別に集計されたカバレッジ統計を表示できます。
+ **[インスタンスリスト]** テーブルは次の列でフィルタリングできます。
+ **アカウント ID**
+ **[エージェント管理タイプ]**
+ **[エージェントバージョン]**
+ **[カバレッジステータス]**
+ **[インスタンス ID]**
+ **クラスター ARN**
+ EC2 インスタンスのいずれかの **[カバレッジステータス]** が **[異常]** の場合、**[問題]** 列には、**[異常]** ステータスである理由に関する追加情報が含まれています。
------
#### [ API/CLI ]
+ 独自の有効なディテクター ID、現在のリージョン、サービスエンドポイントを使用して [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html) API を実行します。この API を使用して、インスタンスリストをフィルタリングしたり、ソートしたりできます。
+ 以下の `CriterionKey` のオプションのいずれかを使用して例 `filter-criteria` を変更できます。
+ `ACCOUNT_ID`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `AGENT_VERSION`
+ `MANAGEMENT_TYPE`
+ `INSTANCE_ID`
+ `CLUSTER_ARN`
+ `filter-criteria` に **[EC2]** として `RESOURCE_TYPE` が含まれている場合、Runtime Monitoring は `AttributeName` としての **[ISSUE]** の使用をサポートしていません。これを使用すると、API レスポンスは `InvalidInputException` になります。
以下のオプションで `sort-criteria` の例 `AttributeName` を変更できます。
+ `ACCOUNT_ID`
+ `COVERAGE_STATUS`
+ `INSTANCE_ID`
+ `UPDATED_AT`
+ *max-results* (最大 50) を変更できます。
+ アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
```
aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "EKS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }' --max-results 5
```
+ [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html) API を実行すると、`statisticsType` に基づいてカバレッジ集計された統計情報を取得できます。
+ 例 `statisticsType` を次のオプションのいずれかに変更できます。
+ `COUNT_BY_COVERAGE_STATUS` - カバレッジステータス別に集計された EKS クラスターのカバレッジ統計を表します。
+ `COUNT_BY_RESOURCE_TYPE` – リスト内の AWS リソースのタイプに基づいて集計されたカバレッジ統計。
+ コマンドで例 `filter-criteria` を変更できます。`CriterionKey` に対して次のオプションを設定できます。
+ `ACCOUNT_ID`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `AGENT_VERSION`
+ `MANAGEMENT_TYPE`
+ `INSTANCE_ID`
+ `CLUSTER_ARN`
+ アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
```
aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
```
------
EC2 インスタンスのカバレッジステータスが **[異常]** である場合は、「[Amazon EC2 ランタイムカバレッジの問題のトラブルシューティング](#ec2-runtime-monitoring-coverage-issues-troubleshoot)」を参照してください。
## カバレッジステータス変更時の EventBridge 通知
Amazon EC2 インスタンスのカバレッジステータスが **[異常]** と表示される場合があります。カバレッジステータスの変化を検出するためにカバレッジステータスを定期的に監視し、ステータスが **[異常]** の場合はトラブルシューティングすることをお勧めします。または、Amazon EventBridge ルールを作成して、カバレッジステータスが **[異常]** から **[正常]** に変更された場合やそれ以外の変更があった場合に通知を受け取ることもできます。デフォルトでは、GuardDuty はこれをアカウントの [EventBridge バス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)に公開します。
### 通知スキーマの例
EventBridge のルールでは、あらかじめ定義されたサンプルイベントとイベントパターンを使用して、カバレッジステータスの通知を受け取ることができます。EventBridge ルールの作成の詳細については、「*Amazon EventBridge ユーザーガイド*」の「[ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule)」を参照してください。
さらに、次の通知スキーマの例を使用して、カスタムイベントパターンを作成します。アカウントの値を必ず置き換えてください。Amazon EC2 インスタンスのカバレッジステータスが `Healthy` から `Unhealthy` に変更されたときに通知を受け取るには、`detail-type` が *GuardDuty Runtime Protection Unhealthy* である必要があります。カバレッジステータスが `Unhealthy` から `Healthy` に変更されたときに通知を受け取るには、`detail-type` の値を *GuardDuty Runtime Protection Healthy* に置き換えます。
```
{
"version": "0",
"id": "event ID",
"detail-type": "GuardDuty Runtime Protection Unhealthy",
"source": "aws.guardduty",
"account": "AWS アカウント ID",
"time": "event timestamp (string)",
"region": "AWS リージョン",
"resources": [
],
"detail": {
"schemaVersion": "1.0",
"resourceAccountId": "string",
"currentStatus": "string",
"previousStatus": "string",
"resourceDetails": {
"resourceType": "EC2",
"ec2InstanceDetails": {
"instanceId":"",
"instanceType":"",
"clusterArn": "",
"agentDetails": {
"version":""
},
"managementType":""
}
},
"issue": "string",
"lastUpdatedAt": "timestamp"
}
}
```
## Amazon EC2 ランタイムカバレッジの問題のトラブルシューティング
Amazon EC2 インスタンスのカバレッジステータスが **[異常]** の場合、その理由を **[問題]** 列で確認できます。
EC2 インスタンスが EKS クラスターに関連付けられていて、EKS のセキュリティエージェントが手動または自動エージェント設定でインストールされている場合は、「[Amazon EKS クラスターのランタイムカバレッジとトラブルシューティング](eks-runtime-monitoring-coverage.md)」を参照してカバレッジの問題をトラブルシューティングします。
次の表に、問題のタイプと対応するトラブルシューティングステップを示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/gdu-assess-coverage-ec2.html)
# Amazon ECS クラスターのランタイムカバレッジとトラブルシューティング
Amazon ECS クラスターのランタイムカバレッジには、 AWS Fargate および Amazon ECS コンテナインスタンスで実行されるタスクが含まれます[1](#ecs-container-instance)。
Fargate で実行される Amazon ECS クラスターの場合、ランタイムカバレッジはタスクレベルで評価されます。ECS クラスターのランタイムカバレッジには、Fargate (ECS のみ) の Runtime Monitoring と自動エージェント設定を有効にした後に実行を開始した Fargate タスクが含まれます。デフォルトでは、Fargate タスクは変更できません。GuardDuty は、セキュリティエージェントをインストールして、既に実行されているタスクのコンテナをモニタリングすることはできません。このような Fargate タスクを含めるには、タスクを停止して再度開始する必要があります。関連付けられたサービスがサポートされていることを確認します。
Amazon ECS コンテナの詳細については、[キャパシティの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-capacity.html)に関するページを参照してください。
**Topics**
+ [カバレッジ統計の確認](#ecs-review-coverage-statistics-ecs-runtime-monitoring)
+ [カバレッジステータス変更時の EventBridge 通知](#ecs-runtime-monitoring-coverage-status-change)
+ [Amazon ECS-Fargate ランタイムカバレッジの問題のトラブルシューティング](#ecs-runtime-monitoring-coverage-issues-troubleshoot)
## カバレッジ統計の確認
自分のアカウントまたはメンバーアカウントに関連付けられた Amazon ECS リソースのカバレッジ統計は、選択した AWS リージョン内のすべての ECS クラスターに対する正常な ECS クラスターの割合です。これには、Fargate インスタンスと Amazon EC2 インスタンスの両方に関連付けられた Amazon ECS クラスターのカバレッジが含まれます。次の式はこれを次のように表します。
(正常なクラスター/すべてのクラスター)\$1100
### 考慮事項
+ ECS クラスターのカバレッジ統計には、その ECS クラスターに関連付けられた Fargate タスクまたは ECS コンテナインスタンスのカバレッジステータスが含まれます。Fargate タスクのカバレッジステータスには、実行中のタスク、または最近実行を終了したタスクが含まれます。
+ **[ECS クラスターのランタイムカバレッジ]** タブの **[対象のコンテナインスタンス]** フィールドは、Amazon ECS クラスターに関連付けられたコンテナインスタンスのカバレッジステータスを示します。
Amazon ECS クラスターに Fargate タスクのみが含まれている場合、カウントは **[0/0]** と表示されます。
+ Amazon ECS クラスターがセキュリティエージェントを持たない Amazon EC2 インスタンスに関連付けられている場合、Amazon ECS クラスターのカバレッジステータスも **[異常]** になります。
関連付けられた Amazon EC2 インスタンスのカバレッジの問題を特定してトラブルシューティングするには、Amazon EC2 インスタンスの「[Amazon EC2 ランタイムカバレッジの問題のトラブルシューティング](gdu-assess-coverage-ec2.md#ec2-runtime-monitoring-coverage-issues-troubleshoot)」を参照してください。
いずれかのアクセス方法を選択して、アカウントのカバレッジ統計を確認してください。
------
#### [ Console ]
+ にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
+ ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
+ **[ランタイムカバレッジ]** タブを選択します。
+ **[ECS クラスターのランタイムカバレッジ]** タブでは、**[クラスターリスト]** テーブルにある各 Amazon ECS クラスターのカバレッジステータス別に集計されたカバレッジ統計を表示できます。
+ **[クラスターリスト]** テーブルは次の列でフィルタリングできます。
+ **アカウント ID**
+ **[クラスター名]**
+ **[エージェント管理タイプ]**
+ **[カバレッジステータス]**
+ Amazon ECS クラスターのいずれかの **[カバレッジステータス]** が **[異常]** の場合、**[問題]** 列には、**[異常]** ステータスである理由に関する追加情報が含まれています。
Amazon ECS クラスターが Amazon EC2 インスタンスに関連付けられている場合は、**[EC2 インスタンスランタイムカバレッジ]** タブに移動し、**[クラスター名]** フィールドでフィルタリングして、関連する **[問題]** を表示します。
------
#### [ API/CLI ]
+ 独自の有効なディテクター ID、現在のリージョン、サービスエンドポイントを使用して [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html) API を実行します。この API を使用して、インスタンスリストをフィルタリングしたり、ソートしたりできます。
+ 以下の `CriterionKey` のオプションのいずれかを使用して例 `filter-criteria` を変更できます。
+ `ACCOUNT_ID`
+ `ECS_CLUSTER_NAME`
+ `COVERAGE_STATUS`
+ `MANAGEMENT_TYPE`
+ 以下のオプションで `sort-criteria` の例 `AttributeName` を変更できます。
+ `ACCOUNT_ID`
+ `COVERAGE_STATUS`
+ `ISSUE`
+ `ECS_CLUSTER_NAME`
+ `UPDATED_AT`
このフィールドは、関連する Amazon ECS クラスターで新しいタスクが作成されたとき、または対応するカバレッジステータスに変更があったときにのみ更新されます。
+ *max-results* (最大 50) を変更できます。
+ アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
```
aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "ECS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }' --max-results 5
```
+ [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html) API を実行すると、`statisticsType` に基づいてカバレッジ集計された統計情報を取得できます。
+ 例 `statisticsType` を次のオプションのいずれかに変更できます。
+ `COUNT_BY_COVERAGE_STATUS` - カバレッジステータス別に集計された ECS クラスターのカバレッジステータスを表します。
+ `COUNT_BY_RESOURCE_TYPE` – リスト内の AWS リソースのタイプに基づいて集計されたカバレッジ統計。
+ コマンドで例 `filter-criteria` を変更できます。`CriterionKey` に対して次のオプションを設定できます。
+ `ACCOUNT_ID`
+ `ECS_CLUSTER_NAME`
+ `COVERAGE_STATUS`
+ `MANAGEMENT_TYPE`
+ `INSTANCE_ID`
+ アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
```
aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
```
------
カバレッジ問題を解決する方法の詳細については、「[Amazon ECS-Fargate ランタイムカバレッジの問題のトラブルシューティング](#ecs-runtime-monitoring-coverage-issues-troubleshoot)」を参照してください。
## カバレッジステータス変更時の EventBridge 通知
Amazon ECS クラスターのカバレッジステータスは **[異常]** と表示される場合があります。カバレッジステータスの変化を検出するためにカバレッジステータスを定期的に監視し、ステータスが **[異常]** の場合はトラブルシューティングすることをお勧めします。または、Amazon EventBridge ルールを作成して、カバレッジステータスが **[異常]** から **[正常]** に変更された場合やそれ以外の変更があった場合に通知を受け取ることもできます。デフォルトでは、GuardDuty はこれをアカウントの [EventBridge バス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)に公開します。
### 通知スキーマの例
EventBridge のルールでは、あらかじめ定義されたサンプルイベントとイベントパターンを使用して、カバレッジステータスの通知を受け取ることができます。EventBridge ルールの作成の詳細については、「*Amazon EventBridge ユーザーガイド*」の「[ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule)」を参照してください。
さらに、次の通知スキーマの例を使用して、カスタムイベントパターンを作成します。アカウントの値を必ず置き換えてください。Amazon ECS クラスターのカバレッジステータスが `Healthy` から `Unhealthy` に変更されたときに通知を受け取るには、`detail-type` が *GuardDuty Runtime Protection Unhealthy* である必要があります。カバレッジステータスが `Unhealthy` から `Healthy` に変更されたときに通知を受け取るには、`detail-type` の値を *GuardDuty Runtime Protection Healthy* に置き換えます。
```
{
"version": "0",
"id": "event ID",
"detail-type": "GuardDuty Runtime Protection Unhealthy",
"source": "aws.guardduty",
"account": "AWS アカウント ID",
"time": "event timestamp (string)",
"region": "AWS リージョン",
"resources": [
],
"detail": {
"schemaVersion": "1.0",
"resourceAccountId": "string",
"currentStatus": "string",
"previousStatus": "string",
"resourceDetails": {
"resourceType": "ECS",
"ecsClusterDetails": {
"clusterName":"",
"fargateDetails":{
"issues":[],
"managementType":""
},
"containerInstanceDetails":{
"coveredContainerInstances":int,
"compatibleContainerInstances":int
}
}
},
"issue": "string",
"lastUpdatedAt": "timestamp"
}
}
```
## Amazon ECS-Fargate ランタイムカバレッジの問題のトラブルシューティング
Amazon ECS クラスターのカバレッジステータスが **[異常]** の場合、その理由を **[問題]** 列で確認できます。
次のテーブルは、Fargate (Amazon ECS のみ) の問題に推奨されるトラブルシューティング手順を示しています。Amazon EC2 インスタンスカバレッジの問題の詳細については、Amazon EC2 インスタンスの「[Amazon EC2 ランタイムカバレッジの問題のトラブルシューティング](gdu-assess-coverage-ec2.md#ec2-runtime-monitoring-coverage-issues-troubleshoot)」を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/gdu-assess-coverage-ecs.html)
# Amazon EKS クラスターのランタイムカバレッジとトラブルシューティング
Runtime Monitoring を有効にして EKS の GuardDuty セキュリティエージェント (アドオン) をインストールした後、EKS クラスターのカバレッジの評価を開始できます。
**Topics**
+ [カバレッジ統計の確認](#reviewing-coverage-statistics-eks-runtime-monitoring)
+ [カバレッジステータス変更時の EventBridge 通知](#eks-runtime-monitoring-coverage-status-change)
+ [Amazon EKS ランタイムカバレッジの問題のトラブルシューティング](#eks-runtime-monitoring-coverage-issues-troubleshoot)
## カバレッジ統計の確認
自分のアカウントまたはメンバーアカウントに関連付けられた EKS クラスターのカバレッジ統計は、選択した AWS リージョンのすべての EKS クラスターに対する正常な EKS クラスターの割合です。次の式はこれを次のように表します。
(正常なクラスター/すべてのクラスター)\$1100
いずれかのアクセス方法を選択して、アカウントのカバレッジ統計を確認してください。
------
#### [ Console ]
+ にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
+ ナビゲーションペインで、**[Runtime Monitoring]** を選択します。
+ **[EKS クラスターのランタイムカバレッジ]** タブを選択します。
+ **[EKS クラスターのランタイムカバレッジ]** タブでは、**[クラスターリスト]** テーブルにあるカバレッジステータス別に集計されたカバレッジ統計を表示できます。
+ **[クラスターリスト]** テーブルは次の列でフィルタリングできます。
+ **クラスター名**
+ **アカウント ID**
+ **[エージェント管理タイプ]**
+ **[カバレッジステータス]**
+ **[アドオンバージョン]**
+ EKS クラスターのいずれかの **[カバレッジステータス]** が **[異常]** の場合、**[問題]** 列には、**[異常]** ステータスである理由に関する追加情報が含まれている場合があります。
------
#### [ API/CLI ]
+ 独自の有効なディテクター ID、リージョン、およびサービスエンドポイントを使用して [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html) API を実行します。この API を使用して、クラスターリストをフィルタリングしたり、ソートしたりできます。
+ 以下の `CriterionKey` のオプションのいずれかを使用して例 `filter-criteria` を変更できます。
+ `ACCOUNT_ID`
+ `CLUSTER_NAME`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `ADDON_VERSION`
+ `MANAGEMENT_TYPE`
+ 以下のオプションで `sort-criteria` の例 `AttributeName` を変更できます。
+ `ACCOUNT_ID`
+ `CLUSTER_NAME`
+ `COVERAGE_STATUS`
+ `ISSUE`
+ `ADDON_VERSION`
+ `UPDATED_AT`
+ *max-results* (最大 50) を変更できます。
+ アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
```
aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "EKS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }' --max-results 5
```
+ [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html) API を実行すると、`statisticsType` に基づいてカバレッジ集計された統計情報を取得できます。
+ 例 `statisticsType` を次のオプションのいずれかに変更できます。
+ `COUNT_BY_COVERAGE_STATUS` - カバレッジステータス別に集計された EKS クラスターのカバレッジ統計を表します。
+ `COUNT_BY_RESOURCE_TYPE` – リスト内の AWS リソースのタイプに基づいて集計されたカバレッジ統計。
+ コマンドで例 `filter-criteria` を変更できます。`CriterionKey` に対して次のオプションを設定できます。
+ `ACCOUNT_ID`
+ `CLUSTER_NAME`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `ADDON_VERSION`
+ `MANAGEMENT_TYPE`
+ アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
```
aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
```
------
EKS クラスターのカバレッジステータスが **[異常]** である場合は、「[Amazon EKS ランタイムカバレッジの問題のトラブルシューティング](#eks-runtime-monitoring-coverage-issues-troubleshoot)」を参照してください。
## カバレッジステータス変更時の EventBridge 通知
アカウントの EKS クラスターのカバレッジステータスが **[異常]** と表示されることがあります。カバレッジステータスが **[異常]** になったことを検出するためにカバレッジステータスを定期的にモニタリングし、ステータスが **[異常]** の場合はトラブルシューティングすることをお勧めします。または、Amazon EventBridge ルールを作成して、カバレッジステータスが `Unhealthy` から `Healthy` に変更された場合やそれ以外の変更があった場合に通知を受け取ることもできます。デフォルトでは、GuardDuty はこれをアカウントの [EventBridge バス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)に公開します。
### 通知スキーマの例
EventBridge のルールでは、あらかじめ定義されたサンプルイベントとイベントパターンを使用して、カバレッジステータスの通知を受け取ることができます。EventBridge ルールの作成の詳細については、「*Amazon EventBridge ユーザーガイド*」の「[ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule)」を参照してください。
さらに、次の通知スキーマの例を使用して、カスタムイベントパターンを作成します。アカウントの値を必ず置き換えてください。Amazon EKS クラスターのカバレッジステータスが `Healthy` から `Unhealthy` に変更されたときに通知を受け取るには、`detail-type` が *GuardDuty Runtime Protection Unhealthy* である必要があります。カバレッジステータスが `Unhealthy` から `Healthy` に変更されたときに通知を受け取るには、`detail-type` の値を *GuardDuty Runtime Protection Healthy* に置き換えます。
```
{
"version": "0",
"id": "event ID",
"detail-type": "GuardDuty Runtime Protection Unhealthy",
"source": "aws.guardduty",
"account": "AWS アカウント ID",
"time": "event timestamp (string)",
"region": "AWS リージョン",
"resources": [
],
"detail": {
"schemaVersion": "1.0",
"resourceAccountId": "string",
"currentStatus": "string",
"previousStatus": "string",
"resourceDetails": {
"resourceType": "EKS",
"eksClusterDetails": {
"clusterName": "string",
"availableNodes": "string",
"desiredNodes": "string",
"addonVersion": "string"
}
},
"issue": "string",
"lastUpdatedAt": "timestamp"
}
}
```
## Amazon EKS ランタイムカバレッジの問題のトラブルシューティング
EKS クラスターのカバレッジステータスが `Unhealthy` の場合、GuardDuty コンソールの **[問題]** 列または [CoverageResource](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CoverageResource.html) データ型を使用して、対応するエラーを確認できます。
包含タグまたは除外タグを使用して EKS クラスターを選択的にモニタリングする場合、タグの同期に時間がかかることがあります。これにより、関連する EKS クラスターのカバレッジステータスに影響が及ぶ可能性があります。対応するタグ (包含または除外) を削除してから、もう一度追加してみることができます。詳細については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS リソースのタグ付け](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html)」を参照してください。
カバレッジ問題の構造は `Issue type:Extra information` です。通常、問題にはオプションの*追加情報*があり、特定のクライアント側の例外や問題に関する説明が含まれる場合があります。*追加情報*に基づき、EKS クラスターのカバレッジの問題をトラブルシューティングするための推奨ステップを以下の表に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-coverage.html)
**アドオン問題コードのあるアドオンの作成/更新エラーのトラブルシューティング手順**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-coverage.html)
# CPU とメモリモニタリングの設定
Runtime Monitoring を有効にして、クラスターのカバレッジステータスが **[正常]** と評価されると、インサイトメトリクスを設定および表示できます。
以下のトピックは、デプロイされたエージェントが GuardDuty エージェントの CPU とメモリの制限に対してどのように動作するかを評価するのに役立ちます。
## Amazon ECS クラスターでの監視設定
「*Amazon CloudWatch ユーザーガイド*」に記載されている以下の手順は、デプロイされたエージェントが GuardDuty エージェントの CPU とメモリの制限に対してどのように動作するかを評価するのに役立ちます。
1. 「[クラスターおよびサービスレベルの Amazon ECS でメトリクスの Container Insights の設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-cluster.html)」
1. 「[Amazon ECS Container Insights メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html)」
## Amazon EKS クラスターでの監視設定
GuardDuty セキュリティエージェントがデプロイされ、クラスターのカバレッジステータスが **[正常]** と評価されると、コンテナインサイトメトリクスを設定および表示できます。
**セキュリティエージェントのパフォーマンスを評価する**
1. 「*Amazon CloudWatch ユーザーガイド*」の「[Amazon EKS と Kubernetes での Container Insights のセットアップ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html)」
1. 「*Amazon CloudWatch ユーザーガイド*」の「[Amazon EKS および Kubernetes Container Insights のメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html)」
**セキュリティエージェント v1.5.0 以降でパフォーマンスを管理する**
セキュリティエージェント [v1.5.0 以降](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-agent-release-history.html#eks-runtime-monitoring-agent-release-history)では、関連する GuardDuty エージェントが割り当てられた制限に達していることがインサイトで示されると、特定のパラメータを設定できます。詳細については、「[EKS アドオンパラメータを設定する](guardduty-configure-security-agent-eks-addon.md)」を参照してください。
# Runtime Monitoring で共有 VPC を使用する
GuardDuty Runtime Monitoring は、 内の同じ組織 AWS アカウント に属する の共有 Amazon Virtual Private Cloud (Amazon VPC) の使用をサポートしています AWS Organizations。共有 VPC は、以下の 2 つの方法で使用できます。
+ **自動エージェント設定 (推奨)** – GuardDuty がセキュリティエージェントを自動的に管理する場合、Amazon VPC エンドポイントポリシーも設定されます。このポリシーは、組織の共有 VPC 設定に基づいています。
共有 VPC 所有者アカウントと、この VPC を共有するすべての参加アカウントで、自動エージェント設定を有効にする必要があります。
+ **手動マネージドエージェント** – 共有 VPC でセキュリティエージェントを手動で管理する場合は、対応するアカウントが共有 VPC にアクセスできるようにVPC エンドポイントポリシーを更新する必要があります。これを行うには、次の [仕組み](#how-shared-vpc-works-runtime-monitoring-auto) セクションで共有されているポリシーの例を使用します。
共有 VPC の参加アカウントを含む手動管理シナリオでは、カバレッジステータスが正確ではない可能性があります。リソースの up-to-date 保護とカバレッジステータスを確保するために、GuardDuty では、共有 VPC を使用するすべてのアカウントで自動エージェント設定を有効にすることをお勧めします。
**Topics**
+ [仕組み](#how-shared-vpc-works-runtime-monitoring-auto)
+ [共有 VPC を使用するための前提条件](#shared-vpc-prerequisite-runtime-monitoring)
## 仕組み
共有 Amazon VPC 所有者アカウントと同じ組織 AWS アカウント に属する は、同じ Amazon VPC エンドポイントを共有することもできます。同じ Amazon VPC エンドポイントポリシーを使用する各アカウントは、関連付けられた共有 Amazon VPC の**参加者 AWS アカウント**として呼び出されます。
次の例は、共有 VPC 所有者アカウントと参加者アカウントのデフォルトの VPC エンドポイントポリシーを示しています。`aws:PrincipalOrgID` は、共有 VPC リソースに関連付けられた組織 ID を表示します。このポリシーの使用は、所有者アカウントの組織に存在する参加者アカウントに限定されます。
**Example 共有 VPC エンドポイントポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Action": "*",
"Resource": "*",
"Effect": "Allow",
"Principal": "*"
},
{
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-abcdef0123"
}
},
"Action": "*",
"Resource": "*",
"Effect": "Deny",
"Principal": "*"
}
]
}
```
### GuardDuty 自動エージェント設定を使用する
共有 VPC の所有者アカウントがいずれかのリソース (Amazon EKS または AWS Fargate (Amazon ECS のみ)) の Runtime Monitoring および自動エージェント設定を有効にすると、すべての共有 VPCs は、共有 VPC 所有者アカウント内の共有 Amazon VPC エンドポイントおよび関連するセキュリティグループの自動インストールの対象となります。GuardDuty は、共有 Amazon VPC に関連付けられている組織 ID を取得します。
GuardDuty は、共有 VPC 所有者アカウントまたは参加アカウントのいずれかで必要な場合に Amazon VPC エンドポイントを作成します。Amazon VPC エンドポイントを必要とする例には、GuardDuty、Runtime Monitoring および EKS Runtime Monitoring の有効化、新しい Amazon ECS-Fargate タスクの起動などがあります。これらのアカウントが任意のリソースタイプの Runtime Monitoring と自動エージェント設定を有効にすると、GuardDuty は Amazon VPC エンドポイントを作成し、共有 VPC 所有者アカウントのものと同じ組織 ID でエンドポイントポリシーを設定します。GuardDuty は、GuardDuty が作成する Amazon VPC エンドポイントに `GuardDutyManaged` タグを追加し、その値を `true` に設定します。共有 Amazon VPC 所有者アカウントがいずれかのリソースの Runtime Monitoring または自動エージェント設定を有効にしていない場合、GuardDuty は Amazon VPC エンドポイントポリシーを設定しません。Runtime Monitoring の設定と、共有 VPC 所有者アカウントでのセキュリティエージェントの自動管理については、「[GuardDuty Runtime Monitoring の有効化](runtime-monitoring-configuration.md)」を参照してください。
### 手動マネージドエージェントを使用する
手動マネージドエージェントで共有 VPC を使用する場合は、共有 VPC を使用する必要があるアカウントをブロックする明示的な `Deny` エンドポイントポリシーがないことを確認します。これにより、セキュリティエージェントがテレメトリを GuardDuty に送信できなくなり、`Unhealthy` カバレッジステータスになります。エンドポイントポリシーの設定については、「[Example shared VPC endpoint policy](#guardduty-runtime-monitoring-shared-vpc-endpoint-policy-example)」を参照してください。
共有 VPC に対するアクセス許可がない場合など、ランタイムカバレッジが正確ではない場合があります。[ランタイムカバレッジ統計の確認と問題のトラブルシューティング](runtime-monitoring-assessing-coverage.md) のリソースタイプの手順に従って、リソースカバレッジを継続的にモニタリングできます。
コンピューティングリソースの継続的な Runtime Monitoring 保護を確実にするために、GuardDuty では、共有 VPC 所有者アカウントとリソースのすべての参加アカウントの自動エージェント設定を有効にすることをお勧めします。
## 共有 VPC を使用するための前提条件
初期設定の一環として、共有 VPC の所有者 AWS アカウント にする で次の手順を実行します。
1. **組織の作成** –「*AWS Organizations ユーザーガイド*」の「[Creating and managing an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org.html)」のステップに従って組織を作成します。
メンバーアカウントの追加または削除の詳細については、[「組織 AWS アカウント での の管理](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html)」を参照してください。
1. **共有 VPC リソースの作成** – 所有者アカウントから共有 VPC リソースを作成できます。詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC サブネットを他のアカウントと共有する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)」を参照してください。
### GuardDuty Runtime Monitoring に固有の前提条件
次のリストは、GuardDuty に固有の前提条件を示しています。
+ 共有 VPC の所有者アカウントと参加アカウントは、GuardDuty の異なる組織に所属することができます。ただし、 AWS Organizations内の同じ組織に属している必要があります。これは、GuardDuty が Amazon VPC エンドポイントと共有 VPC のセキュリティグループを作成する場合に必須です。共有 VPC の仕組みについては、「*Amazon VPC ユーザーガイド*」の「[VPC を他のアカウントと共有する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)」を参照してください。
+ 共有 VPC 所有者アカウントと参加者アカウントのリソースに対して、Runtime Monitoring または EKS Runtime Monitoring、および GuardDuty 自動エージェント設定を有効にします。詳細については、「[Runtime Monitoring の有効化](runtime-monitoring-configuration.md)」を参照してください。
これらの設定を既に完了している場合は、次のステップに進みます。
+ Amazon EKS または Amazon ECS (AWS Fargate のみ) タスクを使用する場合は、所有者アカウントに関連付けられた共有 VPC リソースを選択し、そのサブネットを選択してください。
# GuardDuty 自動セキュリティエージェントでの Infrastructure as Code (IaC) の使用
このセクションは、次のリストがユースケースに適用される場合にのみ使用します。
+ AWS リソースを管理するには、 AWS Cloud Development Kit (AWS CDK) や Terraform などの Infrastructure as Code (IaC) ツールを使用します。
+ Amazon EKS、Amazon EC2、または Amazon ECS-Fargate の 1 つ以上のリソースタイプに対して GuardDuty 自動エージェント設定を有効にする必要があります。
## IaC リソース依存関係グラフの概要
リソースタイプの GuardDuty 自動エージェント設定を有効にすると、GuardDuty は VPC エンドポイントと、この VPC エンドポイントに関連付けられたセキュリティグループを自動的に作成し、このリソースタイプのセキュリティエージェントをインストールします。デフォルトでは、GuardDuty は、Runtime Monitoring を無効にした後にのみ VPC エンドポイントと関連するセキュリティグループを削除します。詳細については、「[Runtime Monitoring でのリソースの無効化、アンインストール、クリーンアップ](runtime-monitoring-agent-resource-clean-up.md)」を参照してください。
IaC ツールを使用すると、リソースの依存関係グラフが維持されます。IaC ツールを使用してリソースを削除すると、リソースの依存関係グラフの一部として追跡できるリソースのみが削除されます。IaC ツールは、指定された設定外で作成されたリソースを認識できない場合があります。たとえば、IaC ツールを使用して VPC を作成し、 AWS コンソールまたは API オペレーションを使用してこの VPC にセキュリティグループを追加します。リソース依存関係グラフでは、作成する VPC リソースは、関連するセキュリティグループによって異なります。IaC ツールを使用してこの VPC リソースを削除すると、エラーが発生します。このエラーを回避するには、関連付けられたセキュリティグループを手動で削除するか、この追加されたリソースを含めるように IaC 設定を更新します。
## 一般的な問題 - IaC でのリソースの削除
GuardDuty 自動エージェント設定を使用する場合、IaC ツールを使用して作成したリソース (Amazon EKS、Amazon EC2、または Amazon ECS-Fargate) を削除できます。ただし、このリソースは、GuardDuty が作成した VPC エンドポイントに依存します。これにより、IaC ツールがリソース自体を削除するのを防ぎ、VPC エンドポイントを自動的に削除する Runtime Monitoring を無効にする必要があります。
例えば、GuardDuty がユーザーに代わって作成した VPC エンドポイントを削除しようとすると、次の例のようなエラーが発生します。
**Example**
**CDK を使用する場合のエラー例**
```
The following resource(s) failed to delete: [mycdkvpcapplicationpublicsubnet1Subnet1SubnetEXAMPLE1, mycdkvpcapplicationprivatesubnet1Subnet2SubnetEXAMPLE2].
Resource handler returned message: "The subnet 'subnet-APKAEIVFHP46CEXAMPLE' has dependencies and cannot be deleted. (Service: Ec2, Status Code: 400, Request ID: e071c3c5-7442-4489-838c-0dfc6EXAMPLE)" (RequestToken: 4381cff8-6240-208a-8357-5557b7EXAMPLE, HandlerErrorCode: InvalidRequest)
```
**Example**
**Terraform を使用する場合のエラー例**
```
module.vpc.aws_subnet.private[1]: Still destroying... [id=subnet-APKAEIVFHP46CEXAMPLE, 19m50s elapsed]
module.vpc.aws_subnet.private[1]: Still destroying... [id=subnet-APKAEIVFHP46CEXAMPLE, 20m0s elapsed]
Error: deleting EC2 Subnet (subnet-APKAEIBAERJR2EXAMPLE): DependencyViolation: The subnet 'subnet-APKAEIBAERJR2EXAMPLE' has dependencies and cannot be deleted.
status code: 400, request id: e071c3c5-7442-4489-838c-0dfc6EXAMPLE
```
### 解決策 - リソース削除の問題を防ぐ
このセクションでは、GuardDuty とは独立して VPC エンドポイントとセキュリティグループを管理するのに役立ちます。
IaC ツールを使用して設定されたリソースの完全な所有権を取得するには、記載されている順序で次のステップを実行します。
1. VPC を作成します。イングレスアクセス許可を許可するには、GuardDuty VPC エンドポイントをセキュリティグループにこの VPC に関連付けます。
1. リソースタイプの GuardDuty 自動エージェント設定を有効にする
上記のステップを完了すると、GuardDuty は独自の VPC エンドポイントを作成せず、IaC ツールを使用して作成したエンドポイントを再利用します。
ユーザー独自の VPC の作成については、「*Amazon VPC Transit Gateways*」で「[VPC のみを作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-only)」を参照してください。VPC エンドポイントの作成については、リソースタイプの次のセクションを参照してください。
+ Amazon EC2 については、「[前提条件 - Amazon VPC エンドポイントの手動作成](creating-vpc-endpoint-ec2-agent-manually.md)」を参照してください。
+ Amazon EKS については、「[前提条件 – Amazon VPC エンドポイントの作成](eksrunmon-prereq-deploy-security-agent.md)」を参照してください。
# GuardDuty が使用する収集されたランタイムイベントタイプ
GuardDuty セキュリティエージェントは、以下のイベントタイプを収集し、脅威の検出と分析のために GuardDuty バックエンドに送信します。GuardDuty では、これらのイベントにはアクセスできません。GuardDuty が潜在的な脅威を検出し、「[Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)」を生成した場合は、対応する検出結果の詳細を表示できます。
GuardDuty が Runtime Monitoring で収集したイベントタイプをどのように使用するかについては、「[サービス改善のためのデータ使用をオプトアウトする](guardduty-opting-out-using-data.md)」を参照してください。
## イベントを処理する
プロセスイベントは、Amazon EC2 インスタンスとコンテナワークロードで実行されているプロセスに関連する情報を表します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するプロセスイベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| プロセス名 | 監視されたプロセスの名前。 |
| プロセスパス | プロセスの実行可能ファイルの絶対パス。 |
| プロセス ID | オペレーティングシステムによってプロセスに割り当てられた ID。 |
| 名前空間 PID | ホストレベルの PID 名前空間以外のセカンダリ PID 名前空間内のプロセスのプロセス ID。コンテナ内のプロセスの場合、コンテナ内で確認されるプロセス ID です。 |
| プロセスユーザー ID | プロセスを実行したユーザーの固有 ID。 |
| プロセス UUID。 | GuardDuty によってプロセスに割り当てられた一意の ID。 |
| プロセス GID。 | プロセスグループのプロセス ID。 |
| プロセス EGID。 | プロセスグループの実効グループ ID。 |
| プロセス EUID。 | プロセスの実効ユーザー ID。 |
| プロセスユーザー名 | プロセスを実行したユーザー名。 |
| プロセス開始時間 | プロセスが作成された時間。このフィールドは、UTC 日付文字列形式 (`2023-03-22T19:37:20.168Z`)です。 |
| プロセスの実行可能ファイル SHA-256 | プロセスの実行可能ファイルの `SHA256` ハッシュ。 |
| プロセススクリプトパス | 実行されたスクリプトファイルのパス。 |
| プロセス環境変数 | プロセスで利用可能になった環境変数。`LD_PRELOAD` および `LD_LIBRARY_PATH` のみ収集可能です。 |
| プロセス現在の作業ディレクトリ (PWD) | プロセスの現在の作業ディレクトリ。 |
| 親プロセス | 親プロセスのプロセス詳細。親プロセスとは、監視対象のプロセスを作成したプロセスです。 |
| コマンドライン引数 現在、このフィールドはリソースタイプに対応する特定のエージェントバージョンに制限されています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/runtime-monitoring-collected-events.html) 詳細については、「[GuardDuty セキュリティエージェントのリリースバージョン](runtime-monitoring-agent-release-history.md)」を参照してください。 | プロセスの実行時に提供されるコマンドライン引数。このフィールドには機密の顧客データが含まれている可能性があります。 |
## コンテナイベント
コンテナイベントは、コンテナワークロードのアクティビティに関連する情報を表します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するコンテナワークロードイベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| コンテナ名 | コンテナの名前。 使用可能な場合、このフィールドには `io.kubenetes.container.name` ラベルの値が表示されます。 |
| コンテナ UID | コンテナランタイムによって割り当てられたコンテナの固有の ID。 |
| コンテナランタイム | コンテナの実行に使用されたコンテナランタイム (`docker` または `containerd` など)。 |
| コンテナイメージ ID | コンテナのイメージの ID。 |
| コンテナイメージ名 | コンテナイメージの名前。 |
## AWS Fargate (Amazon ECS のみ) タスクイベント
Fargate-Amazon ECS タスクイベントは、Fargate コンピューティングで実行されている Amazon ECS タスクに関連付けられたアクティビティを表します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する Amazon ECS-Fargate タスクイベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| タスク Amazon リソースネーム (ARN) | タスクの ARN。 |
| クラスター名 | Amazon ECS クラスターの名前。 |
| [Family Name] (姓) | タスク定義のファミリー名。`family` は、タスクを起動するために使用されるタスク定義の名前として使用されます。 |
| サービス名 | タスクがサービスの一部として起動された場合の Amazon ECS サービスの名前。 |
| 起動タイプ | タスクが実行されるインフラストラクチャ。`ECSCluster` のリソースタイプの Runtime Monitoring では、起動タイプは `EC2` または `FARGATE` のどちらかになります。 |
| CPU | タスク定義に示されている、タスクで使用される CPU ユニットの数。 |
## Kubernetes ポッドイベント
次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する Kubernetes ポッドイベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| ポッド ID | Kubernetes ポッドの ID。 |
| ポッド名 | Kubernetes ポッドの名前。 |
| ポッド名前空間 | Kubernetes ワークロードが属する Kubernetes 名前空間の名前。 |
| Kubernetes クラスター名 | Kubernetes クラスターの名前。 |
## ドメインネームシステム (DNS) イベント
ドメインネームシステム (DNS) イベントには、リソースタイプと対応するレスポンスによって行われた DNS クエリの詳細が含まれます。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する DNS イベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| ソケットタイプ | 通信セマンティクスを示すソケットのタイプ。例えば、`SOCK_RAW`。 |
| アドレスファミリー | アドレスに関連付けられた通信プロトコルを示します。例えば、アドレスファミリー `AF_INET` は IP v4 プロトコルに使用されます。 |
| 方向 ID | 接続方向の ID。 |
| プロトコル番号 | レイヤー 4 プロトコル番号。例えば UDP の場合は 17、TCP の場合は 6 です。 |
| DNS リモートエンドポイント IP | 接続のリモート IP。 |
| DNS リモートエンドポイントポート | 接続のポート番号。 |
| DNS ローカルエンドポイント IP | 接続のローカル IP。 |
| DNS ローカルエンドポイントポート | 接続のポート番号。 |
| DNS ペイロード | DNS クエリと応答を含む DNS パケットのペイロード。 |
## オープンイベント
オープンイベントは、ファイルアクセスと変更に関連付けられます。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するオープンイベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| Filepath | このイベントで開かれるファイルのパス。 |
| フラグ | 読み込み専用、書き込み専用、読み込み/書き込みなどのファイルアクセスモードについて説明します。 |
## ロードモジュールのイベント
次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するロードモジュールイベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| モジュール名 | カーネルにロードされたモジュールの名前。 |
## モプロテクトイベント
Mprotect イベントは、モニタリング対象のシステムで実行されているプロセスのメモリ保護設定の変更に関する情報を提供します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する Mprotect イベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| アドレス範囲 | アクセス保護が変更されたアドレス範囲。 |
| メモリ領域 | スタックやヒープなど、プロセスのアドレス空間のリージョンを指定します。 |
| フラグ | このイベントの動作をコントロールするオプションを示します。 |
## マウントイベント
マウントイベントは、モニタリング対象のリソースでのファイルシステムのマウントとアンマウントに関連する情報を提供します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するマウントイベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| マウントターゲット | マウントソースがマウントされているパス。 |
| マウントソース | マウントターゲットにマウントされているホスト上のパス。 |
| ファイルシステムタイプ | マウントされているファイルシステムのタイプを示します。 |
| フラグ | このイベントの動作をコントロールするオプションを示します。 |
## リンクイベント
リンクイベントは、モニタリング対象のリソース内のファイルシステムリンク管理アクティビティを可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するリンクイベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| リンクパス | ハードリンクが作成されるパス。 |
| ターゲットパス | ハードリンクが指すファイルのパス。 |
## Symlink イベント
Symlink イベントは、モニタリング対象のリソース内のファイルシステムのシンボリックリンク管理アクティビティを可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するシンボリックリンクイベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| リンクパス | Symlink リンクが作成されるパス。 |
| ターゲットパス | Symlink リンクが指すファイルのパス。 |
## Dup イベント
Dup イベントは、モニタリング対象のリソースで実行されているプロセスによるファイル記述子の重複を可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する dup イベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| 古いファイルディスクリプタ | 開いているファイルオブジェクトを表すファイル記述子。 |
| 新規ファイルディスクリプタ | 古いファイル記述子の複製である新しいファイル記述子。古いファイル記述子と新しいファイル記述子はどちらも同じ開いているファイルオブジェクトを示します。 |
| Dup リモートエンドポイント IP | 古いファイル記述子で表されるネットワークソケットのリモート IP アドレス。古いファイル記述子がネットワークソケットを示す場合にのみ適用されます。 |
| Dup リモートエンドポイントポート | 古いファイル記述子で表されるネットワークソケットのリモートポート。古いファイル記述子がネットワークソケットを示す場合にのみ適用されます。 |
| Dup ローカルエンドポイント IP | 古いファイルディスクリプタで表されるネットワークソケットのローカル IP アドレス。古いファイル記述子がネットワークソケットを示す場合にのみ適用されます。 |
| Dup ローカルエンドポイントポート | 古いファイル記述子で表されるネットワークソケットのローカルポート。古いファイル記述子がネットワークソケットを示す場合にのみ適用されます。 |
## メモリマッピングイベント
次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するメモリマップイベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| Filepath | メモリがマッピングされているファイルのパス。 |
## ソケットイベント
ソケットイベントは、モニタリング対象のリソースのアクティビティで使用されるネットワークソケット接続に関する情報を提供します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するソケットイベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| アドレスファミリー | アドレスに関連付けられた通信プロトコルを示します。例えば、アドレスファミリー `AF_INET` は IP バージョンの 4 プロトコルに使用されます。 |
| ソケットタイプ | 通信セマンティクスを示すソケットのタイプ。例えば、`SOCK_RAW`。 |
| プロトコル番号 | アドレスファミリー内の特定のプロトコルを指定します。通常、アドレスファミリーには単一のプロトコルがあります。例えば、アドレスファミリー `AF_INET` には IP プロトコルしかありません。 |
## イベントを接続
接続イベントは、モニタリング対象のリソース上のプロセスによって確立されたネットワーク接続を可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する接続イベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| アドレスファミリー | アドレスに関連付けられた通信プロトコルを示します。例えば、アドレスファミリー `AF_INET` は IP v4 プロトコルに使用されます。 |
| ソケットタイプ | 通信セマンティクスを示すソケットのタイプ。例えば、`SOCK_RAW`。 |
| プロトコル番号 | アドレスファミリー内の特定のプロトコルを指定します。通常、アドレスファミリーには単一のプロトコルがあります。例えば、アドレスファミリー `AF_INET` には IP プロトコルしかありません。 |
| Filepath | アドレスファミリーが `AF_UNIX` の場合のソケットファイルのパス。 |
| リモートエンドポイント IP | 接続のリモート IP。 |
| リモートエンドポイントポート | 接続のポート番号。 |
| ローカルエンドポイント IP | 接続のローカル IP。 |
| ローカルエンドポイントポート | 接続のポート番号。 |
## VM Readv イベントの処理
プロセス VM readv イベントは、プロセスによって独自の仮想メモリ領域で実行される読み取り操作を可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するプロセス VM readv イベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| フラグ | このイベントの動作をコントロールするオプションを示します。 |
| ターゲット PID | メモリを読み込んでいるプロセスのプロセス ID。 |
| ターゲットプロセスの UUID | ターゲットプロセスの一意の ID。 |
| ターゲットの実行可能ファイルのパス | ターゲットプロセスの実行可能ファイルの絶対パス。 |
## VM Writev イベントの処理
プロセス VM writev イベントは、プロセスによって独自の仮想メモリ領域で実行される書き込み操作を可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するプロセス VM writev イベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| フラグ | このイベントの動作をコントロールするオプションを示します。 |
| ターゲット PID | メモリが書き込まれているプロセスのプロセス ID。 |
| ターゲットプロセスの UUID | ターゲットプロセスの一意の ID。 |
| ターゲットの実行可能ファイルのパス | ターゲットプロセスの実行可能ファイルの絶対パス。 |
## プロセストレース (Ptrace) イベント
プロセストレース (Ptrace) システムコールは、あるプロセス (トレーサー) が別のプロセス (トレース) の実行を監視および制御できるようにするデバッグおよびトレースメカニズムです。これにより、トレーサーはターゲットプロセスのメモリ、レジスタ、実行フローを検査および変更できます。
Ptrace イベントは、モニタリング対象のリソースで実行されているプロセスによる ptrace システムコールの使用を可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する ptrace イベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| ターゲット PID | ターゲットプロセスのプロセス ID。 |
| ターゲットプロセスの UUID | ターゲットプロセスの一意の ID。 |
| ターゲットの実行可能ファイルのパス | ターゲットプロセスの実行可能ファイルの絶対パス。 |
| フラグ | このイベントの動作をコントロールするオプションを示します。 |
## バインドイベント
バインドイベントは、モニタリング対象のリソースで実行されているプロセスによるネットワークソケットのバインドを可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するバインドイベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| アドレスファミリー | アドレスに関連付けられた通信プロトコルを示します。例えば、アドレスファミリー `AF_INET` は IP v4 プロトコルに使用されます。 |
| ソケットタイプ | 通信セマンティクスを示すソケットのタイプ。例えば、`SOCK_RAW`。 |
| プロトコル番号 | レイヤー 4 プロトコル番号。例えば UDP の場合は 17、TCP の場合は 6 です。 |
| ローカルエンドポイント IP | 接続のローカル IP。 |
| ローカルエンドポイントポート | 接続のポート番号。 |
## リッスンイベント
リッスンイベントは、ネットワークソケットのリッスン状態を可視化し、ネットワークソケットが受信接続を受け入れる準備ができているかどうかを示します。モニタリング対象のリソースで実行されるプロセスは、ネットワークソケットをリッスン状態に設定します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集するリスンイベントのフィールド名と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| アドレスファミリー | アドレスに関連付けられた通信プロトコルを示します。例えば、アドレスファミリー `AF_INET` は IP v4 プロトコルに使用されます。 |
| ソケットタイプ | 通信セマンティクスを示すソケットのタイプ。例えば、`SOCK_RAW`。 |
| プロトコル番号 | レイヤー 4 プロトコル番号。例えば UDP の場合は 17、TCP の場合は 6 です。 |
| ローカルエンドポイント IP | 接続のローカル IP。 |
| ローカルエンドポイントポート | 接続のポート番号。 |
## 名前変更イベント
名前変更イベントは、モニタリング対象のリソースで実行されているプロセスによるファイルとディレクトリの名前変更に関する情報を提供します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する名前変更イベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| Filepath | 名前が変更されたファイルがあるパス。 |
| ターゲット | ファイルの新しいパス。 |
## ユーザー ID (UID) 設定イベント
ユーザー ID (UID) 設定イベントは、モニタリング対象のリソースで実行中のプロセスに関連付けられたユーザー ID (UID) に加えられた変更を可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する UID 設定イベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| 新しい EUID | プロセスの新しい実効ユーザー ID。 |
| 新しい UID | プロセスの新しいユーザー ID。 |
## Chmod イベント
Chmod イベントは、モニタリング対象のリソース上のファイルとディレクトリのアクセス許可 (モード) の変更を可視化します。次の表に、Runtime Monitoring が潜在的な脅威を検出するために収集する chmod イベントの名前と説明を示します。
| フィールド名 | 説明 |
| --- | --- |
| Filepath | このイベントを呼び出すファイルのパス。 |
| Filemode | 関連付けられたファイルの更新されたアクセス許可。 |
# Amazon ECR リポジトリホスティング GuardDuty エージェント
以下のセクションでは、Amazon EKS クラスターと Amazon ECS クラスターにデプロイされるセキュリティエージェントを GuardDuty がホストする Amazon Elastic Container Registry (Amazon ECR) リポジトリの一覧を示します。
[コンテナイメージアクセスの前提条件](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs) の前提条件では、特定の Amazon Elastic Container Registry (Amazon ECR) アクセス許可を持つタスク実行ロールを指定する必要があります。これらのアクセス許可をさらに制限するには、Fargate-Amazon ECS リソースの GuardDuty エージェントをホストする Amazon ECR リポジトリ URI を追加できます。
**Topics**
+ [EKS エージェントバージョン 1.12.1 ～ 1.8.1 の ECR リポジトリ (eks.build.2)](eks-runtime-agent-ecr-image-uri-v1-8-1-build-2.md)
+ [EKS エージェントバージョン 1.8.1 (`eks.build.1`) のリポジトリ](eks-runtime-agent-ecr-image-uri-v1-8-1-build-1.md)
+ [上の GuardDuty エージェント用の ECR リポジトリ AWS Fargate (Amazon ECS のみ)](ecs-runtime-agent-ecr-image-uri.md)
# EKS エージェントバージョン 1.12.1 ～ 1.8.1 の ECR リポジトリ (eks.build.2)
Runtime Monitoring for EKS で GuardDuty 自動設定を有効にすると、GuardDuty はこのエージェントバージョンを Amazon EKS クラスターにデプロイします。自動エージェントを有効にする方法については、「[Amazon EKS リソースのセキュリティエージェントの自動管理](managing-gdu-agent-eks-automatically.md)」を参照してください。
次の表は、Amazon EKS `1.8.0.eks.build.2`の GuardDuty セキュリティエージェントバージョン `1.12.1.eks.build.2`、`1.11.0.eks.build.2`、`1.10.0.eks.build.2`、`1.9.0.eks.build.2`、および がホストされている Amazon ECR リポジトリ URIs を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-agent-ecr-image-uri-v1-8-1-build-2.html)
# EKS エージェントバージョン 1.8.1 (`eks.build.1`) のリポジトリ
このセクションでは、Amazon EKS エージェントバージョン **1.8.1 (v1.8.1-eks-build.1)** の Amazon ECR リポジトリについて説明します。v1.8.1-eks-build.1 を使用している場合、GuardDuty は通常最新のエージェントバージョンであるデフォルトのエージェントバージョンへの切り替えを推奨します。そのためには、[Amazon EKS リソース用にリリースされたエージェントバージョン](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history) から最新のエージェントを特定し、[Amazon EKS リソースのセキュリティエージェントの手動更新](eksrunmon-update-security-agent.md) の手順を実行します。
次の表は、Amazon EKS の GuardDuty セキュリティエージェントバージョン `1.8.1-eks-build.1` がホストされている Amazon ECR リポジトリ URI を示しています。
| **AWS リージョン** | **Amazon ECR リポジトリ URI** |
| --- | --- |
| 米国西部 (オレゴン) | `039403964562.dkr.ecr.us-west-2.amazonaws.com` |
| 欧州 (パリ) | `113643092156.dkr.ecr.eu-west-3.amazonaws.com` |
| アジアパシフィック (ムンバイ) | `610108029387.dkr.ecr.ap-south-1.amazonaws.com` |
| アジアパシフィック (ハイデラバード) | `618745550137.dkr.ecr.ap-south-2.amazonaws.com` |
| カナダ (中部) | `001188825231.dkr.ecr.ca-central-1.amazonaws.com` |
| 中東 (アラブ首長国連邦) | `601769779514.dkr.ecr.me-central-1.amazonaws.com` |
| 欧州 (ロンドン) | `109118265657.dkr.ecr.eu-west-2.amazonaws.com` |
| 米国西部 (北カリフォルニア) | `373421517865.dkr.ecr.us-west-1.amazonaws.com` |
| 米国東部 (バージニア北部) | `031903291036.dkr.ecr.us-east-1.amazonaws.com` |
| 米国東部 (オハイオ) | `591382732059.dkr.ecr.us-east-2.amazonaws.com` |
| 欧州 (アイルランド) | `673884943994.dkr.ecr.eu-west-1.amazonaws.com` |
| 南米 (サンパウロ) | `941219317354.dkr.ecr.sa-east-1.amazonaws.com` |
| 欧州 (ストックホルム) | `366771026645.dkr.ecr.eu-north-1.amazonaws.com` |
| 欧州 (フランクフルト) | `409493279830.dkr.ecr.eu-central-1.amazonaws.com` |
| 欧州 (チューリッヒ) | `718440343717.dkr.ecr.eu-central-2.amazonaws.com` |
| アジアパシフィック (シンガポール) | `584580519942.dkr.ecr.ap-southeast-1.amazonaws.com` |
| アジアパシフィック (シドニー) | `011662287384.dkr.ecr.ap-southeast-2.amazonaws.com` |
| アジアパシフィック (ジャカルタ) | `617474730032.dkr.ecr.ap-southeast-3.amazonaws.com` |
| アジアパシフィック (東京) | `781592569369.dkr.ecr.ap-northeast-1.amazonaws.com` |
| アジアパシフィック (ソウル) | `732248494576.dkr.ecr.ap-northeast-2.amazonaws.com` |
| アジアパシフィック (大阪) | `810724417379.dkr.ecr.ap-northeast-3.amazonaws.com` |
| アジアパシフィック (香港) | `790429075973.dkr.ecr.ap-east-1.amazonaws.com` |
| 中東 (バーレーン) | `541829937850.dkr.ecr.me-south-1.amazonaws.com` |
| 欧州 (ミラノ) | `528450769569.dkr.ecr.eu-south-1.amazonaws.com` |
| 欧州 (スペイン) | `531047660167.dkr.ecr.eu-south-2.amazonaws.com` |
| アフリカ (ケープタウン) | `379032919888.dkr.ecr.af-south-1.amazonaws.com` |
| アジアパシフィック (メルボルン) | `750462861327.dkr.ecr.ap-southeast-4.amazonaws.com` |
| イスラエル (テルアビブ) | `292660727137.dkr.ecr.il-central-1.amazonaws.com` |
# 上の GuardDuty エージェント用の ECR リポジトリ AWS Fargate (Amazon ECS のみ)
Amazon ECS-Fargate の Runtime Monitoring を使用するための前提条件として、[コンテナイメージアクセスの前提条件](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs) が必要です。GuardDuty エージェントのサイドカーコンテナイメージは Amazon ECR に保存され、そのイメージレイヤーは Amazon S3 に保存されます。詳細については、「[Fargate での Runtime Monitoring の仕組み (Amazon ECS のみ)](how-runtime-monitoring-works-ecs-fargate.md)」を参照してください。
次の表は、それぞれ AWS Fargate (Amazon ECS のみ) の GuardDuty エージェントをホストする Amazon ECR リポジトリを示しています AWS リージョン。
| **AWS リージョン** | **Amazon ECR リポジトリ URI** |
| --- | --- |
| 米国西部 (オレゴン) | `733349766148.dkr.ecr.us-west-2.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (パリ) | `665651866788.dkr.ecr.eu-west-3.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (ムンバイ) | `251508486986.dkr.ecr.ap-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (ハイデラバード) | `950823858135.dkr.ecr.ap-south-2.amazonaws.com/aws-guardduty-agent-fargate` |
| カナダ (中部) | `354763396469.dkr.ecr.ca-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 中東 (アラブ首長国連邦) | `000014521398.dkr.ecr.me-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (ロンドン) | `892757235363.dkr.ecr.eu-west-2.amazonaws.com/aws-guardduty-agent-fargate` |
| 米国西部 (北カリフォルニア) | `684579721401.dkr.ecr.us-west-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 米国東部 (バージニア北部) | `593207742271.dkr.ecr.us-east-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 米国東部 (オハイオ) | `307168627858.dkr.ecr.us-east-2.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (アイルランド) | `694911143906.dkr.ecr.eu-west-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 南米 (サンパウロ) | `758426053663.dkr.ecr.sa-east-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (ストックホルム) | `591436053604.dkr.ecr.eu-north-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (フランクフルト) | `323658145986.dkr.ecr.eu-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (チューリッヒ) | `529164026651.dkr.ecr.eu-central-2.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (シンガポール) | `174946120834.dkr.ecr.ap-southeast-1.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (シドニー) | `005257825471.dkr.ecr.ap-southeast-2.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (ジャカルタ) | `510637619217.dkr.ecr.ap-southeast-3.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (東京) | `533107202818.dkr.ecr.ap-northeast-1.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (ソウル) | `914738172881.dkr.ecr.ap-northeast-2.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (大阪) | `273192626886.dkr.ecr.ap-northeast-3.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (香港) | `258348409381.dkr.ecr.ap-east-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 中東 (バーレーン) | `536382113932.dkr.ecr.me-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (ミラノ) | `266869475730.dkr.ecr.eu-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| 欧州 (スペイン) | `919611009337.dkr.ecr.eu-south-2.amazonaws.com/aws-guardduty-agent-fargate` |
| アフリカ (ケープタウン) | `197869348890.dkr.ecr.af-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (メルボルン) | `251357961535.dkr.ecr.ap-southeast-4.amazonaws.com/aws-guardduty-agent-fargate` |
| イスラエル (テルアビブ) | `870907303882.dkr.ecr.il-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (マレーシア) | `156041399949.dkr.ecr.ap-southeast-5.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (タイ) | `054037130133.dkr.ecr.ap-southeast-7.amazonaws.com/aws-guardduty-agent-fargate` |
| カナダ西部 (カルガリー) | `339712888787.dkr.ecr.ca-west-1.amazonaws.com/aws-guardduty-agent-fargate` |
| メキシコ (中部) | `311141559934.dkr.ecr.mx-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| アジアパシフィック (台北) | `259886477082.dkr.ecr.ap-east-2.amazonaws.com/aws-guardduty-agent-fargate` |
# 同じ基盤となるホスト上の 2 つのセキュリティエージェント
Amazon EC2 インスタンスは、複数のタイプのワークロードをサポートできます。Amazon EC2 インスタンスで自動セキュリティエージェントを設定すると、同じ EC2 インスタンスに EKS 経由で別のセキュリティエージェントがある可能性があります。
## 概要:
Runtime Monitoring を有効にしたシナリオを考えてみましょう。次に、GuardDuty を使用して Amazon EKS の自動エージェントを有効にします。また、Amazon EC2 の自動エージェントも有効にしました。同じ基盤となるホストに、Amazon EKS 用と Amazon EC2 用の 2 つのセキュリティエージェントがインストールされる場合があります。これにより、同じホスト内で 2 つのセキュリティエージェントが実行され、ランタイムイベントが収集および GuardDuty に送信され、重複する検出結果が生成される可能性があります。
## Impact
+ 同じホストで複数のセキュリティエージェントが実行されている場合、アカウントで CPU とメモリの処理ニーズが 2 倍になる可能性があります。各リソースタイプの CPU とメモリの制限については、そのリソースの「[前提条件](runtime-monitoring-prerequisites.md)」を参照してください。
+ GuardDuty は、同じ基盤となるホストからランタイムイベントを収集する 2 つのセキュリティエージェントが重複しても、アカウントがランタイムイベントの 1 つのストリームに対してのみ課金されるように Runtime Monitoring 機能を設計しました。
## GuardDuty が複数のエージェントを処理する方法
GuardDuty は、2 つのセキュリティエージェントが同じホストで実行されているかどうかを検出し、そのうちの 1 つだけをランタイムイベントをアクティブに収集するセキュリティエージェントに指定します。2 番目のエージェントは、アプリケーションのパフォーマンスへの影響を防ぐために、最小限のシステムリソースを消費します。
GuardDuty では、次のシナリオを考慮します。
+ EC2 インスタンスが Amazon EKS と Amazon EC2 セキュリティエージェントの両方のスコープに含まれる場合、EKS セキュリティエージェントが優先されます。これは、Amazon EC2 でセキュリティエージェント v1.1.0 以降を使用する場合にのみ適用されます。古いエージェントバージョンは優先順位付けの影響を受けないため、古いエージェントバージョンは引き続き実行され、ランタイムイベントを収集します。
+ Amazon EKS と Amazon EC2 の両方に GuardDuty マネージドセキュリティエージェントがあり、Amazon EC2 インスタンスも SSM マネージドである場合、両方のセキュリティエージェントがホストレベルでインストールされます。エージェントがインストールされると、GuardDuty はどちらのセキュリティエージェントが引き続き実行されるかを決定します。両方のセキュリティエージェントが実行されている場合、最終的にはそのうちの 1 つだけがランタイムイベントを収集します。
+ EC2 と EKS の両方に関連付けられたセキュリティエージェントが同時に実行されると、GuardDuty は重複期間にのみ重複する検出結果を生成する可能性があります。
これは、次の場合に発生する可能性があります。
+ EC2 と EKS の両方のセキュリティエージェントが GuardDuty を通じて (自動的に) 設定されている。または
+ Amazon EKS リソースに自動セキュリティエージェントがある。
+ EKS セキュリティエージェントが既に実行されている場合、EC2 セキュリティエージェントを同じ基盤となるホストに手動でデプロイし、すべての前提条件を満たすと、GuardDuty は 2 番目のセキュリティエージェントをインストールしない可能性があります。
# GuardDuty での EKS Runtime Monitoring
EKS Runtime Monitoring は、 AWS 環境内の Amazon Elastic Kubernetes Service (Amazon EKS) ノードとコンテナのランタイム脅威検出カバレッジを提供します。EKS Runtime Monitoring では、GuardDuty セキュリティエージェントを使用して、ファイルアクセス、プロセス実行、ネットワーク接続などの個々の EKS ワークロードをランタイムで可視化します。GuardDuty セキュリティエージェントは、GuardDuty が EKS クラスター内の危険にさらされている可能性のある特定のコンテナを識別するのに役立ちます。また、個々のコンテナから基盤となる EC2 ホスト、およびより広範な AWS 環境に権限をエスカレートしようとする試みを検出することもできます。
Runtime Monitoring が利用可能になったことで、GuardDuty は EKS Runtime Monitoring のコンソールエクスペリエンスを Runtime Monitoring に統合しました。GuardDuty は、ユーザーに代わって EKS Runtime Monitoring 設定を自動的に移行しません。これには、ユーザーによるアクションが必要です。EKS Runtime Monitoring のみを引き続き使用する場合は、 APIsまたは AWS CLI を使用して EKS Runtime Monitoring の既存の設定ステータスを確認および更新できます。ただし、GuardDuty では、「[EKS Runtime Monitoring から Runtime Monitoring への移行](migrating-from-eksrunmon-to-runtime-monitoring.md)」を行い、Amazon EKS クラスターをモニタリングするために Runtime Monitoring を使用することをお勧めします。
**Topics**
+ [マルチアカウント環境の EKS Runtime Monitoring の設定 (API)](eks-runtime-monitoring-configuration-multiple-accounts.md)
+ [スタンドアロンアカウントの EKS Runtime Monitoring の設定 (API)](eks-runtime-monitoring-configuration-standalone-acc.md)
+ [EKS Runtime Monitoring から Runtime Monitoring への移行](migrating-from-eksrunmon-to-runtime-monitoring.md)
# マルチアカウント環境の EKS Runtime Monitoring の設定 (API)
マルチアカウント環境では、委任 GuardDuty 管理者アカウントのみが、メンバーアカウントの EKS Runtime Monitoring を有効または無効にすることや、組織内のメンバーアカウントに属する EKS クラスターの GuardDuty エージェント管理を管理することができます。GuardDuty メンバーアカウントからは、この設定を変更できません。委任 GuardDuty 管理者アカウントは、 を使用してメンバーアカウントを管理します AWS Organizations。マルチアカウント環境の詳細については、「[複数のアカウントの管理](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html)」を参照してください。
## 委任 GuardDuty 管理者アカウントでの EKS Runtime Monitoring の設定
このセクションでは、EKS Runtime Monitoring を設定し、委任 GuardDuty 管理者アカウントに属する EKS クラスターの GuardDuty セキュリティエージェントを管理するステップを説明します。
「[Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters)」に基づいて、推奨アプローチを選択し、次の表に示すステップに従うことができます。
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | ユーザー独自のリージョンレベルのディテクター ID を使用し、`features` オブジェクト名を `EKS_RUNTIME_MONITORING` として、ステータスを `ENABLED` として渡して、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html) API を実行します。 `EKS_ADDON_MANAGEMENT` のステータスを `ENABLED` に設定します。 GuardDuty は、アカウント内のすべての Amazon EKS クラスターのセキュリティエージェントのデプロイと更新を管理します。 または、独自のリージョンディテクター ID を使用して AWS CLI コマンドを使用することもできます。アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。 次の例では、`EKS_RUNTIME_MONITORING` と `EKS_ADDON_MANAGEMENT` の両方を有効にします。 aws guardduty update-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| 選択的な EKS クラスターのモニタリング (包含タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| セキュリティエージェントの手動管理 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## すべてのメンバーアカウントのために EKS Runtime Monitoring を自動的に有効にする
このセクションでは、すべてのメンバーアカウントで EKS Runtime Monitoring を有効にし、セキュリティエージェントを管理するステップについて説明します。これには、委任 GuardDuty 管理者アカウント、既存のメンバーアカウント、および組織に参加する新しいアカウントが含まれます。
「[Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters)」に基づいて、推奨アプローチを選択し、次の表に示すステップに従うことができます。
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | メンバーアカウントの EKS Runtime Monitoring を選択的に有効にするには、自分の*ディテクター ID* を使用し、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API オペレーションを実行します。 `EKS_ADDON_MANAGEMENT` のステータスを `ENABLED` に設定します。 GuardDuty は、アカウント内のすべての Amazon EKS クラスターのセキュリティエージェントのデプロイと更新を管理します。 または、独自のリージョンディテクター ID を使用して AWS CLI コマンドを使用することもできます。アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。 次の例では、`EKS_RUNTIME_MONITORING` と `EKS_ADDON_MANAGEMENT` の両方を有効にします。 aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' スペースで区切られたアカウント ID のリストを渡すこともできます。 コードが正常に実行されると、`UnprocessedAccounts` の空のリストが返されます。アカウントのディテクター設定を変更する際に問題が発生した場合は、そのアカウント ID と問題の概要が表示されます。 |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| 選択的な EKS クラスターのモニタリング (包含タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| セキュリティエージェントの手動管理 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## すべての既存のアクティブなメンバーアカウントの EKS Runtime Monitoring の設定
このセクションでは、EKS Runtime Monitoring を有効にし、組織内の既存のアクティブなメンバーアカウントの GuardDuty セキュリティエージェントを管理するステップについて説明します。
「[Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters)」に基づいて、推奨アプローチを選択し、次の表に示すステップに従うことができます。
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | メンバーアカウントの EKS Runtime Monitoring を選択的に有効にするには、自分の*ディテクター ID* を使用し、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API オペレーションを実行します。 `EKS_ADDON_MANAGEMENT` のステータスを `ENABLED` に設定します。 GuardDuty は、アカウント内のすべての Amazon EKS クラスターのセキュリティエージェントのデプロイと更新を管理します。 または、独自のリージョンディテクター ID を使用して AWS CLI コマンドを使用することもできます。アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。 次の例では、`EKS_RUNTIME_MONITORING` と `EKS_ADDON_MANAGEMENT` の両方を有効にします。 aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' スペースで区切られたアカウント ID のリストを渡すこともできます。 コードが正常に実行されると、`UnprocessedAccounts` の空のリストが返されます。アカウントのディテクター設定を変更する際に問題が発生した場合は、そのアカウント ID と問題の概要が表示されます。 |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| 選択的な EKS クラスターのモニタリング (包含タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| セキュリティエージェントの手動管理 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## 新規メンバーの EKS Runtime Monitoring を自動有効化
委任 GuardDuty 管理者アカウントは、組織に参加する新しいアカウントの EKS Runtime Monitoring を自動的に有効にし、GuardDuty セキュリティエージェントを管理する方法のアプローチを選択することができます。
「[Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters)」に基づいて、推奨アプローチを選択し、次の表に示すステップに従うことができます。
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | 新しいアカウントの EKS Runtime Monitoring を選択的に有効にするには、自身の*ディテクター ID* を使用し、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html) API オペレーションを実行します。 `EKS_ADDON_MANAGEMENT` のステータスを `ENABLED` に設定します。 GuardDuty は、アカウント内のすべての Amazon EKS クラスターのセキュリティエージェントのデプロイと更新を管理します。 または、独自のリージョンディテクター ID を使用して AWS CLI コマンドを使用することもできます。アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。 次の例では、1 つのアカウントで `EKS_RUNTIME_MONITORING` と `EKS_ADDON_MANAGEMENT` の両方を有効にします。スペースで区切られたアカウント ID のリストを渡すこともできます。 アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。 aws guardduty update-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --autoEnable --features '[{"Name" : "EKS_RUNTIME_MONITORING", "AutoEnable": "NEW", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "AutoEnable": "NEW"}] }]' コードが正常に実行されると、`UnprocessedAccounts` の空のリストが返されます。アカウントのディテクター設定を変更する際に問題が発生した場合は、そのアカウント ID と問題の概要が表示されます。 |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| 選択的な EKS クラスターのモニタリング (包含タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| セキュリティエージェントの手動管理 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## 個々のアクティブなメンバーアカウントの EKS Runtime Monitoring の有効化
このセクションでは、個々のアクティブメンバーアカウントの EKS Runtime Monitoring を設定し、セキュリティエージェントを管理するステップについて説明します。
「[Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters)」に基づいて、推奨アプローチを選択し、次の表に示すステップに従うことができます。
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | メンバーアカウントの EKS Runtime Monitoring を選択的に有効にするには、自分の*ディテクター ID* を使用し、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API オペレーションを実行します。 `EKS_ADDON_MANAGEMENT` のステータスを `ENABLED` に設定します。 GuardDuty は、アカウント内のすべての Amazon EKS クラスターのセキュリティエージェントのデプロイと更新を管理します。 または、独自のリージョンディテクター ID を使用して AWS CLI コマンドを使用することもできます。アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。 次の例では、`EKS_RUNTIME_MONITORING` と `EKS_ADDON_MANAGEMENT` の両方を有効にします。 aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' スペースで区切られたアカウント ID のリストを渡すこともできます。 コードが正常に実行されると、`UnprocessedAccounts` の空のリストが返されます。アカウントのディテクター設定を変更する際に問題が発生した場合は、そのアカウント ID と問題の概要が表示されます。 |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| 選択的な EKS クラスターのモニタリング (包含タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| セキュリティエージェントの手動管理 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
# スタンドアロンアカウントの EKS Runtime Monitoring の設定 (API)
スタンドアロンアカウントは、特定の の で保護プランを有効または無効にする決定を所有 AWS アカウント します AWS リージョン。
アカウントが を通じて AWS Organizations、または招待方法によって GuardDuty 管理者アカウントに関連付けられている場合、このセクションはアカウントには適用されません。詳細については、「[マルチアカウント環境の EKS Runtime Monitoring の設定 (API)](eks-runtime-monitoring-configuration-multiple-accounts.md)」を参照してください。
Runtime Monitoring を有効にした後、自動設定または手動デプロイを使用して GuardDuty セキュリティエージェントをインストールしてください。次の手順に記載されたすべてのステップを完了する一環として、セキュリティエージェントをインストールしてください。
「[Amazon EKS クラスターの GuardDuty セキュリティエージェントを管理するためのアプローチ](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters)」に基づいて、推奨アプローチを選択し、次の表に示すステップに従うことができます。
| **GuardDuty セキュリティエージェントを管理するための推奨アプローチ** | **ステップ** |
| --- | --- |
| GuardDuty によるセキュリティエージェントの管理 (すべての EKS クラスターのモニタリング) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
| 一部を除外したすべての EKS クラスターのモニタリング (除外タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
| 選択的な EKS クラスターのモニタリング (包含タグの使用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
| セキュリティエージェントの手動管理 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
# EKS Runtime Monitoring から Runtime Monitoring への移行
GuardDuty Runtime Monitoring が開始されたことで、脅威検出の対象範囲が Amazon ECS コンテナと Amazon EC2 インスタンスにまで拡大されました。EKS Runtime Monitoring のエクスペリエンスは Runtime Monitoring に統合されました。Runtime Monitoring を有効にして、ランタイムの動作を監視したいリソースタイプ (Amazon EC2 インスタンス、Amazon ECS クラスター、Amazon EKS クラスター) ごとに個別の GuardDuty セキュリティエージェントを管理できます。
GuardDuty は、EKS Runtime Monitoring のコンソールエクスペリエンスを Runtime Monitoring に統合しました。GuardDuty は「[EKS Runtime Monitoring 設定ステータスの確認](checking-eks-runtime-monitoring-enable-status.md)」および「[EKS Runtime Monitoring から Runtime Monitoring への移行](#migrating-from-eksrunmon-to-runtime-monitoring)」を推奨します。
Runtime Monitoring への移行の一環として、「[EKS Runtime Monitoring を無効にする](disabling-eks-runtime-monitoring.md)」を必ず行ってください。これは重要です。後で Runtime Monitoring を無効にし、EKS Runtime Monitoring を無効にしない場合、EKS Runtime Monitoring の使用コストが引き続き発生するためです。
**EKS Runtime Monitoring から Runtime Monitoring に移行するには**
1. GuardDuty コンソールは、Runtime Monitoring の一部として EKS Runtime Monitoring をサポートしています。
組織やアカウントの [EKS Runtime Monitoring 設定ステータスの確認](checking-eks-runtime-monitoring-enable-status.md) ごとに Runtime Monitoring の使用を開始できます。
Runtime Monitoring を有効にする前に、EKS Runtime Monitoring を無効にしないでください。EKS Runtime Monitoring を無効にすると、Amazon EKS アドオン管理も無効になります。記載された順序で、次のステップを続行します。
1. すべての [Runtime Monitoring を有効にする前提条件](runtime-monitoring-prerequisites.md) を満たしていることを確認してください。
1. EKS Runtime Monitoring と同じ組織構成設定を Runtime Monitoring に対して複製することで、Runtime Monitoring を有効にします。詳細については、「[Runtime Monitoring の有効化](runtime-monitoring-configuration.md)」を参照してください。
+ スタンドアロンアカウントをお持ちの場合は、Runtime Monitoring を有効にする必要があります。
GuardDuty セキュリティエージェントが既にデプロイされている場合は、対応する設定が自動的に複製されるため、設定を再設定する必要はありません。
+ 自動有効化設定を行っている組織がある場合は、必ず同じ自動有効化設定を Runtime Monitoring に複製してください。
+ 既存のアクティブメンバーアカウントを個別に設定が構成されている組織がある場合は、これらのメンバーに対して必ず Runtime Monitoring を有効にし、GuardDuty セキュリティエージェントを個別に設定してください。
1. Runtime Monitoring と GuardDuty セキュリティエージェントの設定が正しいことを確認したら、 API または AWS CLI コマンドを使用して [EKS Runtime Monitoring を無効に](https://docs.aws.amazon.com/guardduty/latest/ug/disabling-eks-runtime-monitoring.html)します。
1. (オプション) GuardDuty セキュリティエージェントに関連付けられているリソースをクリーンアップする場合は、「[Runtime Monitoring でのリソースの無効化、アンインストール、クリーンアップ](runtime-monitoring-agent-resource-clean-up.md)」を参照してください。
Runtime Monitoring を有効にせずに EKS Runtime Monitoring を引き続き使用する場合は、「[GuardDuty での EKS Runtime Monitoring](eks-runtime-monitoring-guardduty.md)」を参照してください。ユースケースに基づいて、スタンドアロンアカウントまたは複数のメンバーアカウントに対して EKS Runtime Monitoring を設定するステップを選択します。
# EKS Runtime Monitoring 設定ステータスの確認
次の APIs または AWS CLI コマンドを使用して、EKS Runtime Monitoring の既存の設定ステータスを確認します。
**アカウント内の既存の EKS Runtime Monitoring 設定ステータスを確認するには**
+ [[GetDetector]](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetDetector.html) を実行して、自分のアカウントの設定ステータスを確認します。
+ または、 AWS CLIを使用して以下のコマンドを実行できます。
```
aws guardduty get-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --region us-east-1
```
AWS アカウント と現在のリージョンのディテクター ID を必ず置き換えてください。アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
**組織の既存の EKS Runtime Monitoring 設定ステータスを確認するには (委任 GuardDuty 管理者アカウントのみ)**
+ [[DescribeOrganizationConfiguration]](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DescribeOrganizationConfiguration.html) を実行して、組織の設定ステータスを確認します。
または、 AWS CLIを使用して以下のコマンドを実行できます。
```
aws guardduty describe-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --region us-east-1
```
ディテクター ID は必ず委任 GuardDuty 管理者アカウントのディテクター ID に、リージョンは現在のリージョンに置き換えてください。アカウントと現在のリージョンの `detectorId` を検索するには、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールの **[設定]** ページを参照するか、[https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API を実行します。
# Runtime Monitoring への移行後に EKS Runtime Monitoring を無効にする
アカウントまたは組織の既存の設定が Runtime Monitoring に複製されたことを確認したら、EKS Runtime Monitoring を無効にできます。
**EKS Runtime Monitoring を無効にするには**
+ **自分のアカウントで EKS Runtime Monitoring を無効にするには**
自身のリージョンの *detector-id* を使用して [UpdateDetector](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html) API を実行します。
または、次の AWS CLI コマンドを使用できます。*12abc34d567e8fa901bc2d34e56789f0* を自分のリージョン *detector-id* に置き換えます。
```
aws guardduty update-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "DISABLED"}]'
```
+ **組織内のメンバーアカウントの EKS Runtime Monitoring を無効にするには**
組織の委任 GuardDuty 管理者アカウントのリージョンの *detector-id* を使用して [UpdateMemberDetectors](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API を実行します。
または、次の AWS CLI コマンドを使用できます。*12abc34d567e8fa901bc2d34e56789f0* を組織の委任 GuardDuty 管理者アカウントのリージョン別 *detector-id* に、*111122223333* をこの機能を無効にするメンバーアカウントの AWS アカウント ID に置き換えます。
```
aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "DISABLED"}]'
```
+ **組織の EKS Runtime Monitoring 自動有効化設定を更新するには**
EKS Runtime Monitoring 自動有効化設定を組織内の新しい (`NEW`) メンバーアカウントまたはすべての (`ALL`) メンバーアカウントに設定した場合にのみ、次のステップを実行します。既に `NONE` として設定している場合は、このステップをスキップできます。
**注記**
EKS Runtime Monitoring の自動有効化設定を `NONE` に設定すると、既存のメンバーアカウントまたは新しいメンバーアカウントが組織に加わったときに EKS Runtime Monitoring が自動的に有効にならないことを意味します。
組織の委任 GuardDuty 管理者アカウントのリージョン *detector-id* を使用して [UpdateOrganizationConfiguration](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html) API を実行します。
または、次の AWS CLI コマンドを使用できます。*12abc34d567e8fa901bc2d34e56789f0* を、組織の委任 GuardDuty 管理者アカウントのリージョン *detector-id* に置き換えます。*EXISTING\$1VALUE* を、GuardDuty を自動有効化するための現在の設定に置き換えます。
```
aws guardduty update-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --auto-enable-organization-members EXISTING_VALUE --features '[{"Name" : "EKS_RUNTIME_MONITORING", "AutoEnable": "NONE"}]'
```
# GuardDuty セキュリティエージェントのリリースバージョン
GuardDuty は、更新されたエージェントバージョンを随時リリースします。GuardDuty がエージェントを自動的に管理する場合、GuardDuty はユーザーに代わってエージェントを更新するように設計されています。エージェントを手動で管理する場合、Amazon EC2 インスタンス、Amazon ECS クラスター、Amazon EKS クラスターなどのリソースタイプのエージェントバージョンを更新する責任がユーザーにあります。
以下のセクションでは、GuardDuty セキュリティエージェントのリリースバージョンと、サポートされているすべてのリソースタイプに関連するリリースノートについて説明します。
**トピック**
+ [Amazon EC2 インスタンス用の GuardDuty セキュリティエージェントバージョン](#ec2-gdu-agent-release-history)
+ [の GuardDuty セキュリティエージェントバージョン AWS Fargate (Amazon ECS のみ)](#ecs-gdu-agent-release-history)
+ [Amazon EKS リソースの GuardDuty セキュリティエージェントバージョン](#eks-runtime-monitoring-agent-release-history)
+ [その他のリソース - 次のステップ](#runtime-monitoring-related-agent-versions-next-steps)
## Amazon EC2 インスタンス用の GuardDuty セキュリティエージェントバージョン
次の表は、Amazon EC2 の GuardDuty セキュリティエージェントのリリースバージョン履歴を示しています。
| SSM ディストリビューターバージョン | [エージェントバージョン] | リリースノート | 利用可能日 |
| --- | --- | --- | --- |
| v1.9.2 | v1.9.2 | カーネル 6.15、6.16、6.17、6.18 のサポートが追加されました。 Alma Linux 9、Alma Linux 10、SUSE Linux Enterprise Server 16 のサポートが追加されました。Amazon EC2 リソースのすべての検証済み OS ディストリビューションのリストについては、「[アーキテクチャ要件を検証する](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2)」を参照してください。 | 2026 年 2 月 24 日 |
| v1.9.1 | v1.9.1 | 一般的なパフォーマンス調整とセキュリティ機能の更新。 | 2025 年 11 月 10 日 |
| v1.9.0 | v1.9.0 | 一般的なパフォーマンスの調整と強化。 | 2025 年 10 月 23 日 |
| v1.8.0 | v1.8.0 | 一般的なパフォーマンスの調整と強化。 | 2025 年 8 月 12 日 |
| v1.7.2 | v1.7.1 | RPM ベースの Linux ディストリビューション向けローカルエージェントインストール機能のサポート強化しました。 | 2025 年 7 月 23 日 |
| v1.7.1 | 1.7.1 | Fedora 40 と Fedora 41 のサポートが追加されました。Amazon EC2 リソースのすべての検証済み OS ディストリビューションのリストについては、「[アーキテクチャ要件を検証する](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2)」を参照してください。 一般的なパフォーマンスの調整と強化。 | 2025 年 6 月 3 日 |
| v1.7.0 | v1.7.0 | Oracle Linux バージョン 8.9 および 9.3、Rocky Linux バージョン 9.5 のサポートが追加されました。Amazon EC2 リソースのすべての検証済み OS ディストリビューションのリストについては、「[アーキテクチャ要件を検証する](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2)」を参照してください。 改善されたコンテナ ID の解決。 一般的なパフォーマンスの調整と強化。 | 2025 年 4 月 3 日 |
| v1.6.0 | v1.6.0 | 一般的なパフォーマンスの調整と強化。 | 2025 年 2 月 6 日 |
| v1.5.0 | v1.5.0 | CentOS Stream 9.0、RedHat 9.4、Fedora 34.0、および Ubuntu 24.04 のサポートが追加されました。 `.../MetadataDNSRebind` 検出結果の ARM インスタンスのサポート。 一般的なパフォーマンスの調整と強化。 | 2024 年 11 月 20 日 |
| v1.3.1 | v1.3.1 | カスタム DNS リゾルバーのサポート。 | 2024 年 9 月 12 日 |
| v1.3.0 | v1.3.0 | 一般的なパフォーマンスの調整と強化。 将来の「[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)」の追加セキュリティシグナルをキャプチャするためのサポートが含まれています。 | 2024 年 8 月 19 日 |
| v1.2.0 | v1.2.0 | OS ディストリビューション Ubuntu 20.04、Ubuntu 22.04、Debian 11、および Debian 12 をサポートします。 カーネル 6.5 と 6.8 をサポートします。 一般的なパフォーマンスの調整と強化。 | 2024 年 6 月 13 日 |
| v1.1.0 | v1.1.0 | Amazon EC2 インスタンスの Runtime Monitoring で GuardDuty 自動エージェント設定をサポートします。 EC2 インスタンスの Runtime Monitoring の一般提供の発表に伴ってリリースされた新しいセキュリティシグナルと検出結果をサポートします。 一般的なパフォーマンスの調整と強化。 | 2024 年 3 月 26 日 |
| v1.0.2 | v1.0.2 | 最新の Amazon ECS AMI をサポートします。 | 2024 年 2 月 2 日 |
| v1.0.1 | v1.0.1 | v1.0.2 より前にリリースされたエージェントバージョンは、2024 年 1 月 31 日以降に起動された Amazon ECS AMI と互換性がありません。 一般的なパフォーマンスの調整と強化。 | 2024 年 1 月 23 日 |
| v1.0.0 | v1.0.0 | RPM インストールの初期リリース。 v1.0.2 より前にリリースされたエージェントバージョンは、2024 年 1 月 31 日以降に起動された Amazon ECS AMI と互換性がありません。 | 2023 年 11 月 26 日 |
## の GuardDuty セキュリティエージェントバージョン AWS Fargate (Amazon ECS のみ)
次の表は、Fargate 用 GuardDuty セキュリティエージェントのリリースバージョン履歴を示しています (Amazon ECS のみ)。
| エージェントのバージョン | コンテナイメージ | リリースノート | 利用可能日 |
| --- | --- | --- | --- |
| v1.9.0 | **x86\$164 (AMD64)**: `sha256:fd9acaa2326f180f0ed0c5a25d8ff0a2d0498a6e900c34c68d4e973ea7fb26a8` **Graviton (ARM64)**: `sha256:0b04f8c28956684e752677bfd83dbc45afc8a43f7791fa44667b8078ba48a295` | 一般的なパフォーマンスの調整とセキュリティの強化。 | 2025 年 10 月 28 日 |
| v1.8.0 | **x86\$164 (AMD64)**: `sha256:4425417f39e38b24c1be428bacad1dad53e0645530dcf4422436353bfe358e3a` **Graviton (ARM64)**: `sha256:aff069418fd6825846f8f575c49906a67c8a446d12d9ed0d21ab95bd0d05497b` | 一般的なパフォーマンスの調整と強化。 | 2025 年 8 月 12 日 |
| v1.7.0 | **x86\$164 (AMD64)**: `sha256:bf9197abdf853607e5fa392b4f97ccdd6ca56dd179be3ce8849e552d96582ac8` **Graviton (ARM64)**: `sha256:56c8683c948bcd82c0dbcebf755204365ac7285994693c11717bd45f86e279c2` | 改善されたコンテナ ID の解決。 一般的なパフォーマンスの調整と強化。 | 2025 年 4 月 4 日 |
| v1.6.0 | **x86\$164 (AMD64)**: `sha256:c8dea71d372bc47b2f236f7a091b9a9b06bc8193c1cfe4c9346eb50f89258897` **Graviton (ARM64)**: `sha256:f4032a566b90537646c2a987bef42eca1b498078ccc58a848603f877971a8dbe` | 一般的なパフォーマンスの調整と強化。 | 2025 年 2 月 6 日 |
| v1.5.0 | **x86\$164 (AMD64)**: `sha256:5e6fdc41f9eb748219d0498cd6c1dba6a19d875daec50167a0ac80e5028eac54` **Graviton (ARM64)**: `sha256:d56801ff6864d6014740103b70b1c38431851358d182613bede20fe21090e734` | `.../MetadataDNSRebind` 検出結果の ARM タスクのサポート。 一般的なパフォーマンスの調整と強化。 | 2024 年 11 月 14 日 |
| v1.4.1 | **x86\$164 (AMD64)**: `sha256:ef36a11151ec2d3d7db22273bfb954750dee76f0ac7bec37a7ba7e74c3de1c78` **Graviton (ARM64)**: `sha256:a8844544a59d6b4cba98f8e528b513ac2d97432f208e3ad497cc16b331aa9faa` | コンテナイメージの強化。 一般的なパフォーマンスの調整と強化。 | 2024 年 10 月 24 日 |
| v1.3.1 | **x86\$164 (AMD64)**: `sha256:a6e2307d796e2875907bc4c1c69622c906f3192ddc42ef27b99e0a8f0979f3e0` **Graviton (ARM64)**: `sha256:ad1b6539d806edb504f17e6bcfb8b4026c5e822300afc31c0d23c6a08f9b99e9` | カスタム DNS リゾルバーのサポート。 | 2024 年 9 月 11 日 |
| v1.3.0 | **x86\$164 (AMD64)**: `sha256:f1ad3fb2dc55a1110c60eecf4453b9f9c02f29acb261df39814e7d29296bf831` **Graviton (ARM64)**: `sha256:ff81a755d46681e409f55a95beedae9ebbcf5336e1c0b1e6348af7c6518bdbb1` | 一般的なパフォーマンスの調整と強化。 将来の GuardDuty「[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)」の追加セキュリティシグナルをキャプチャするためのサポートが含まれています。 | 2024 年 8 月 9 日 |
| v1.2.0 | **x86\$164 (AMD64)**: `sha256:1dbad20ac2dc66d52d00bb28dde4281fe0d3c5f261b1649b247c2369d9e26b93` **Graviton (ARM64)**: `sha256:91930f8446f5f95b93b8ccb18773992affa401eb3f42da89d68077a56bafa6cd` | 一般的なパフォーマンスの調整と強化。 | 2024 年 5 月 31 日 |
| v1.1.0 | **x86\$164 (AMD64)**: `sha256:83ce3cf2ef85a349ed1797a8cf30a008ac5d8c9f673f2835823957e9dcf71657` **Graviton (ARM64)**: `sha256:0d4b61648d7bdeab8ab8d94684f805498927c7d437d318204dcccfe8c9383dc7` | 新しいセキュリティシグナルと検出結果をサポートします。 一般的なパフォーマンスの調整と強化。 | 2024 年 5 月 1 日 |
| v1.0.1 | **x86\$164 (AMD64)**: `sha256:9f8cd438fb66f62d09bfc641286439f7ed5177988a314a6021ef4ff880642e68` **Graviton (ARM64)**: `sha256:82c66bb615bd0d1e96db77b1f1fb51dc03220caa593b1962249571bf7147d1b7` | 一般的なパフォーマンスの調整と強化。 | 2024 年 1 月 26 日 |
| v1.0.0 | **x86\$164 (AMD64)**: `sha256:359b8b014e5076c625daa1056090e522631587a7afa3b2e055edda6bd1141017` **Graviton (ARM64)**: `sha256:b9438690fa8a86067180a11658bec0f4f838ae3fbd225d04b9306250648b3984` | ( AWS Fargate Amazon ECS のみ) の GuardDuty セキュリティエージェントの初回リリース。 | 2023 年 11 月 26 日 |
## Amazon EKS リソースの GuardDuty セキュリティエージェントバージョン
GuardDuty は、更新されたエージェントバージョンを随時リリースします。GuardDuty がエージェントを自動的に管理する場合、GuardDuty はユーザーに代わってエージェントの更新を管理するように設計されています。エージェントを手動で管理する場合、Amazon EKS クラスターのエージェントバージョンを更新する責任がユーザーにあります。
エージェントを特定のバージョンに更新する前に、GuardDuty のイメージレジストリをアドミッションコントローラーの `allowed-container-registries` に追加します。詳細については、「[Amazon ECR リポジトリホスティング GuardDuty エージェント](runtime-monitoring-ecr-repository-gdu-agent.md)」を参照してください。
次の表は、[Amazon EKS アドオン GuardDuty エージェント](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#add-ons-guard-duty)のリリースバージョン履歴を示しています。
| エージェントのバージョン | コンテナイメージ | リリースノート | 利用可能日 | 標準サポート終了日[1](#eks-security-agent-life-support-end) |
| --- | --- | --- | --- | --- |
| v1.12.1 | **x86\$164 (AMD64)**: `sha256:f29a597745e5acff48809bebac7d8091bbc38229453dd26710c549b817362491` **Graviton (ARM64)**: `sha256:089cebdc7e891177e107a099c9a4e362d9d74b5362cd374b448a16078040f6c6` | 一般的なパフォーマンス調整とセキュリティ機能の更新。 | 2025 年 11 月 17 日 | – |
| v1.11.0 | **x86\$164 (AMD64)**: `sha256:7c398fd50dee5fe493c361aa7fe191e094ddfa000c65b449a9ed6a5cd53610e7` **Graviton (ARM64)**: `sha256:98a547b47d4770f45e75eb9730c807d9265722ca2f391e0aa5cb19e487ab455f` | Fedora 40 および Fedora 41 OS ディストリビューションのサポートが追加されました。詳細については「[アーキテクチャ要件の検証](prereq-runtime-monitoring-eks-support.md#eksrunmon-supported-platform-concepts) (EKS の場合)」を参照してください。 一般的なパフォーマンスの調整とセキュリティの強化。 | 2025 年 8 月 29 日 | – |
| v1.10.0 | **x86\$164 (AMD64)**: `sha256:6dcbe5b055e1ef0af903071ede0b08f755ad5b7e9774a67df5399efdaa1f3d7d` **Graviton (ARM64)**: `sha256:f05368822689610a4bab543abf93d3e070b1b559e62a2e67d82dfa9837600f72` | 改善されたコンテナ ID の解決。 一般的なパフォーマンスの調整と強化。 | 2025 年 4 月 4 日 | – |
| v1.9.0 | **x86\$164 (AMD64)**: `sha256:51c5789ef6570f9bec879ac48a8f4769718cbc31e45430032569917e219af63f` **Graviton (ARM64)**: `sha256:9c2f74e7ea0827b7e422ae4c91fffc6c2bc41a1cdb96c7191d05259d337154e1` | 一般的なパフォーマンスの調整と強化。 | 2025 年 3 月 2 日 | – |
| v1.8.1 | **x86\$164 (AMD64)**: `sha256:f2ce8cf89dbe17e3388cecb35053544dadf21af7770545f8d4b50384076aff47` **Graviton (ARM64)**: `sha256:30f586e4b694e704bcafadfa9081ab0aeff3cfbcde39743a0f1e24f77d79627f` | CentOS Stream 9.0、RedHat 9.4、Fedora 34.0、および Ubuntu 24.04 のサポートが追加されました。 `.../MetadataDNSRebind` 検出結果の ARM インスタンスのサポート。 一般的なパフォーマンスの調整と強化。 | 2024 年 11 月 23 日 | – |
| v1.7.1 | **x86\$164 (AMD64)**: `sha256:b8b86b5d0872c8b67fecf64ec3d172666360545435a1752447d510951a7fd749` **Graviton (ARM64)**: `sha256:40ac4cfc354fd430ba7897ca1632e9a500ed13eeb0c315c5bcad38680e76b6e9` | 一般的なパフォーマンスの調整と強化。 将来の「[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)」の追加セキュリティシグナルをキャプチャするためのサポートが含まれています。 カスタム DNS リゾルバーのサポート。 | 2024 年 9 月 13 日 | – |
| v1.7.0 | **x86\$164 (AMD64)**: `sha256:f3a2a8806e6c2a7fd63a91cccf6f7dffcd7e68554a423d610cea8c7e8f2185ec` **Graviton (ARM64)**: `sha256:b1a6db35a072c0de3c695e5e909a03e6c4e1fdbe47ecfaeb2784435cf67ebe0a` | 一般的なパフォーマンスの調整と強化。 将来の「[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)」の追加セキュリティシグナルをキャプチャするためのサポートが含まれています。 | 2024 年 8 月 17 日 | – |
| v1.6.1 | **x86\$164 (AMD64)**: `sha256:30650708a6601f6d6b9046f54b30f5fd65af296b1e40b8c24426b9bdb07c3ab1` **Graviton (ARM64)**: `sha256:5f637c42ffb306b20f776d9d83e1e0b4be40ce245be44afcf43a8902b4d71019` | 一般的なパフォーマンスの調整と強化。 | 2024 年 5 月 14 日 | – |
| v1.6.0 | **x86\$164 (AMD64)**: `sha256:7dabcbee30d8b053676752fbc19e89f77272d9a6a53cc93731f5872180ef9010` **Graviton (ARM64)**: `sha256:9710f53afccdf4f22b265a1a6fc27f1469403af1f7d5d08c4869a7269cdd2650` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/runtime-monitoring-agent-release-history.html) | 2024 年 4 月 29 日 | – |
| v1.5.0 | **x86\$164 (AMD64)**: `sha256:e09a4e70af4058a212f172cc8eb3fc23ad9bed547ed609faa2bb82cf7cc5532d` **Graviton (ARM64)**: `sha256:afc9a3f8f17ae12499d76069efcf1b46271a5a4b2b3f6ba5de54637b8f55d5c6` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/runtime-monitoring-agent-release-history.html) | 2024 年 3 月 7 日 | – |
| v1.4.1 | **x86\$164 (AMD64)**: `sha256:66d491927763742660faa87cc2c39bb97b7873039157ae8b90bc999cb73d0b9c` **Graviton (ARM64)**: `sha256:537a330b2dd82357024fb6daeb8761034b7defd43b10dffe0792c9e6d0778b40` | 一般的なパフォーマンスの調整と強化。 | 2024 年 1 月 16 日 | – |
| v1.4.0 | **x86\$164 (AMD64)**: `sha256:848ce13d9430bad554ac23d4699551505326ada2a88e1a721fe9f86b56b52c0f` **Graviton (ARM64)**: `sha256:0c650aeafeeb5f2bcb8b989ac849bedc1fae1a4de1cf6306ffdd9c6aebe67f8e` | マニフェストマウントポイントによるより優れたデータ収集のサポート マニフェストでの AppArmor 設定 コマンドライン引数の収集 一般的なパフォーマンスの調整と強化 | 2023 年 12 月 21 日 | – |
| v1.3.1 | **x86\$164 (AMD64)**: `sha256:55578fcb7b73097ade5c8404390ef16cf76a7b568490abaae01ac75992b3ea29` **Graviton (ARM64)**: `sha256:e3ce8d66ac2121f8d476eb58f8bc50ab51336647615eb7cf514c21421cb818fd` | 重要なセキュリティパッチと更新。 | 2023 年 10 月 23 日 | – |
| v1.3.0 | **x86\$164 (AMD64)**: `sha256:6dace2337dfbb7609811be89fb4b23ae0b865f1027ad78fbe69530bfbd46c694` **Graviton (ARM64)**: `sha256:4928a7c6ef40e77c8ec95841323bb9a110db31f12c0ee7ab965e08b43efd01bb` | Ubuntu プラットフォームをサポートしています Kubernetes バージョン 1.28 をサポートしています 一般的なパフォーマンスの向上と安定性の向上。 | 2023 年 10 月 5 日 | – |
| v1.2.0 | **x86\$164 (AMD64)**: `sha256:d610413d662ec042057f05d6942496d7f2c08e9f5a077ea307ffdb5d3f11bcc3` **Graviton (ARM64)**: `sha256:174d7ab28b2f95e5309da80d95b88ad26f602dfe72c2b351a0ef9297a1412bfa` | AMD64 ベースのインスタンスに加えて、v1.2.0 では ARM64 ベースのインスタンスもサポートされるようになりました。Bottlerocket のサポートが追加、検証されました Kubernetes バージョン 1.27 をサポートしています 一般的なパフォーマンスの向上と安定性の向上。 | 2023 年 6 月 16 日 | – |
| v1.1.0 | `sha256:b19ba3a3c1a508d153263ae2fda891a7928b5ca9b3a5692db6c101829303281c` | [GuardDuty セキュリティエージェントでサポートされている Kubernetes のバージョン](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version) に加え、このエージェントリリースは Kubernetes バージョン 1.26 もサポートしています 一般的なパフォーマンスの向上と安定性の向上。 | 2023 年 5 月 2 日 | 2024 年 5 月 14 日 |
| v1.0.0 | `sha256:e38bdd2b1323e89113f1a31bd4bc8e5a8098525dd98e6981a28b9906b1e4411e` | Amazon EKS アドオンエージェントの初回リリース。 | 2023 年 3 月 30 日 | 2024 年 5 月 14 日 |
**1** 標準サポートの終了に近づいている現在のエージェントバージョンの更新については、「[Amazon EKS リソースのセキュリティエージェントの手動更新](eksrunmon-update-security-agent.md)」を参照してください。
## その他のリソース - 次のステップ
次のステップの詳細については、次のトピックを参照してください。
+ [Runtime Monitoring を有効にする前提条件](runtime-monitoring-prerequisites.md) - 新しいエージェントバージョンでは、前提条件セクションが更新される場合があります。リソースが最新の前提条件を満たしていることを確認します。
+ [GuardDuty セキュリティエージェントの管理](runtime-monitoring-managing-agents.md) - エージェントを手動で管理する場合、リソース上で実行されているエージェントバージョンの更新管理はお客様の責任となります。リソースタイプ (Amazon EKS または Amazon EC2-Amazon ECS)に基づいて、セキュリティ エージェントを更新する手順を実行してください。また、[VPC エンドポイント設定](https://docs.aws.amazon.com/guardduty/latest/ug/validate-vpc-endpoint-config-runtime-monitoring.html)も必ず検証してください。
+ [ランタイムカバレッジ統計の確認と問題のトラブルシューティング](runtime-monitoring-assessing-coverage.md) - セキュリティエージェントを更新した後、リソースの実行時カバレッジを評価できます。接続に関する問題が発生した場合は、関連するトラブルシューティング手順を参照してください。
# Runtime Monitoring でのリソースの無効化、アンインストール、クリーンアップ
このセクションは、Runtime Monitoring を無効にする AWS アカウント か、リソースタイプの GuardDuty 自動エージェント設定のみを無効にする場合、 に適用されます。
**GuardDuty 自動エージェント設定の無効化**
GuardDuty は、リソースにデプロイされているセキュリティエージェントを削除しません。ただし、GuardDuty はセキュリティエージェントに対する更新の管理を停止します。
GuardDuty は、引き続きリソースタイプからランタイムイベントを受信します。使用統計に影響が出ないように、リソースから GuardDuty セキュリティエージェントを必ず削除してください。
が共有 VPC エンドポイント AWS アカウント を使用するかどうかにかかわらず、GuardDuty は VPC エンドポイントを削除しません。必要に応じて、VPC エンドポイントを手動で削除する必要があります。
**Runtime Monitoring **および** EKS Runtime Monitoring** の無効化
このセクションは、次のシナリオに適用されます。
+ EKS Runtime Monitoring を個別に有効にしたことはないが、Runtime Monitoring を無効にした。
+ Runtime Monitoring と EKS Runtime Monitoring の両方を無効にしている。EKS Runtime Monitoring の設定ステータスが不明な場合は、「[EKS Runtime Monitoring 設定ステータスの確認](checking-eks-runtime-monitoring-enable-status.md)」を参照してください。
**EKS Runtime Monitoring を無効にせずに Runtime Monitoring を無効にする**
このシナリオでは、ある時点で EKS Runtime Monitoring を有効にし、後で EKS Runtime Monitoring を無効にすることなく Runtime Monitoring も有効にしました。
ここで Runtime Monitoring を無効にした場合、EKS Runtime Monitoring も無効にする必要があります。無効にしないと、EKS Runtime Monitoring の使用コストが引き続き発生します。
前述のシナリオが当てはまる場合、GuardDuty はアカウントで次のアクションを実行します。
+ GuardDuty は、`GuardDutyManaged`:`true` タグを持つ VPC エンドポイントを削除します。これは、GuardDuty が自動セキュリティエージェントを管理するために作成した VPC です。
+ GuardDuty は、`GuardDutyManaged`:`true` としてタグ付けされたセキュリティグループを削除します。
+ 少なくとも 1 つの参加者アカウントで使用されている共有 VPC の場合、GuardDuty は VPC エンドポイントも共有 VPC リソースに関連付けられたセキュリティグループも削除しません。
+ Amazon EKS リソースの場合、GuardDuty はセキュリティエージェントを削除します。これは、手動で管理するか、GuardDuty を使用して管理するかには関係ありません。
Amazon ECS リソースの場合、ECS タスクはイミュータブルであるため、GuardDuty はそのリソースからセキュリティエージェントをアンインストールできません。これは、セキュリティエージェントの管理方法 (手動管理または GuardDuty による自動管理) とは関係ありません。Runtime Monitoring を無効にすると、GuardDuty は新しい ECS タスクの実行開始時にサイドカーコンテナをアタッチしません。Fargate-ECS タスクの操作については、「[Fargate での Runtime Monitoring の仕組み (Amazon ECS のみ)](how-runtime-monitoring-works-ecs-fargate.md)」を参照してください。
Amazon EC2 リソースの場合、GuardDuty は、次の条件を満たす場合にのみ、すべての Systems Manager (SSM) マネージド Amazon EC2 インスタンスからセキュリティエージェントをアンインストールします。
+ リソースに `GuardDutyManaged`:`false` 除外タグが付けられて**いません**。
+ GuardDuty には、インスタンスメタデータ内のタグにアクセスするアクセス許可が必要です。この EC2 リソースでは、**[インスタンスメタデータのタグへのアクセス]** は **[許可]** に設定されます。
**セキュリティエージェントの管理を手動で停止する場合**
GuardDuty セキュリティエージェントのデプロイと管理にどのアプローチを使用するかに関係なく、リソース内のランタイムイベントのモニタリングを停止するには、GuardDuty セキュリティエージェントを削除する必要があります。アカウント内のリソースタイプからのランタイムイベントのモニタリングを停止する場合は、Amazon VPC エンドポイントを削除することもできます。
# Amazon EC2 リソースのセキュリティエージェントの手動アンインストール
このセクションでは、Amazon EC2 リソースから GuardDuty セキュリティエージェントをアンインストールする方法について説明します。セキュリティエージェントを手動で管理する場合、リソースからエージェントを削除する責任がユーザーにあります。GuardDuty は、管理するリソースに対してアクションを実行しません。
Amazon VPC エンドポイントを手動で作成した場合、アカウント内のすべてのモニタリング対象のリソースタイプでセキュリティエージェントをアンインストールした後、VPC エンドポイントを削除できます。これは別のステップです。詳細については、「[To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint)」を参照してください。
リソースにセキュリティエージェントをインストールした方法に応じて、次のいずれかの方法を選択してアンインストールします。
**Topics**
+ [方法 1 - Run Command を使用する](#remove-gdu-ec2-agent-run-command)
+ [方法 2 - Linux パッケージマネージャーを使用する](#remove-gdu-ec2-agent-rpm-script)
## 方法 1 - Run Command を使用する
「[方法 1 - の使用 AWS Systems Manager](installing-gdu-security-agent-ec2-manually.md#install-gdu-by-using-sys-runtime-monitoring)」を使用してセキュリティエージェントをインストールした場合、次のステップを実行してエージェントをアンインストールします。
**GuardDuty セキュリティエージェントをアンインストールするには**
1. GuardDuty セキュリティエージェントは、「*AWS Systems Manager ユーザーガイド*」の「[AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)」に記載されている手順に従ってアンインストールできます。パラメータの [Uninstall] アクションを使用して、GuardDuty セキュリティエージェントをアンインストールします。
**[ターゲット]** セクションで、セキュリティエージェントをアンインストールする Amazon EC2 インスタンスにのみ影響があることを確認してください。
次の GuardDuty ドキュメントとディストリビュータを使用してください。
+ ドキュメント名: `AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin`
+ ディストリビューター: `AmazonGuardDuty-RuntimeMonitoringSsmPlugin`
1. すべての詳細を入力した後、**[実行する]** を選択すると、対象の Amazon EC2 インスタンスにデプロイされたセキュリティエージェントが削除されます。
Amazon VPC エンドポイント設定を削除するには、Runtime Monitoring と Amazon EKS Runtime Monitoring の両方を無効にする必要があります。
1. このセキュリティエージェントに関連付けられている VPC エンドポイントも削除する場合は、「[To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint)」を参照してください。
## 方法 2 - Linux パッケージマネージャーを使用する
「[方法 2 - Linux パッケージマネージャーを使用する](installing-gdu-security-agent-ec2-manually.md#install-gdu-by-rpm-scripts-runtime-monitoring)」を使用してセキュリティエージェントをインストールした場合、次のステップを実行してエージェントをアンインストールします。
**GuardDuty セキュリティエージェントをアンインストールするには**
1. インスタンスに接続します。これを行うステップについては、「*Amazon EC2 ユーザーガイド*」の「[SSH クライアントを使用して Linux インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html)」を参照してください。
1.
**アンインストールするためのコマンド**
次のコマンドは、接続先の Amazon EC2 インスタンスから GuardDuty セキュリティエージェントをアンインストールします。
+ RPM の場合:
```
sudo rpm -e amazon-guardduty-agent
```
+ Debian の場合:
```
sudo dpkg --purge amazon-guardduty-agent
```
コマンドを実行した後、コマンドに関連付けられたログを確認することもできます。
1. このセキュリティエージェントに関連付けられている VPC エンドポイントも削除する場合は、「[To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint)」を参照してください。
# セキュリティエージェントのリソースのクリーンアップ
このセクションでは、セキュリティエージェントに関連付けられた AWS リソースをクリーンアップする方法について説明します。「[無効化、アンインストール、リソースクリーンアップ](runtime-monitoring-agent-resource-clean-up.md)」に記載されているように、GuardDuty はすべてのセキュリティエージェントリソースを削除または削除しません。次のセクションでは、セキュリティエージェントリソースを削除する方法について説明します。
**Amazon VPC エンドポイントを削除するには**
セキュリティエージェントを手動で管理する場合、Amazon VPC エンドポイントを手動で作成した可能性があります。アカウント内のすべてのモニタリング対象リソースのセキュリティエージェントをアンインストールした後、この VPC エンドポイントを削除できます。
次のリストは、共有 VPC を使用する場合と、共有 VPC を使用しない場合のシナリオを示しています。
+ 共有 VPC を使用しない場合 – アカウントのリソースをモニタリングする必要がなくなった場合は、Amazon VPC エンドポイントの削除を検討してください。
+ 共有 VPC を使用する場合 – 共有 VPC 所有者アカウントが、まだ使用されている共有 VPC リソースを削除すると、共有 VPC 所有者アカウントと参加アカウントのリソースの Runtime Monitoring (および該当する場合は EKS Runtime Monitoring) カバレッジステータスが異常になる可能性があります。カバレッジステータスについては、「[ランタイムカバレッジ統計の確認と問題のトラブルシューティング](runtime-monitoring-assessing-coverage.md)」を参照してください。
VPC エンドポイントを削除するには、「*AWS PrivateLink ガイド*」の「[インターフェースエンドポイントを削除する](https://docs.aws.amazon.com/vpc/latest/privatelink/delete-interface-endpoint.html)」を参照してください。
**セキュリティグループを削除するには**
+ 共有 VPC を使用しない場合 – アカウントのリソースタイプをモニタリングする必要がなくなった場合は、Amazon VPC に関連付けられたセキュリティグループの削除を検討してください。
+ 共有 VPC を使用する場合 – 共有 VPC 所有者アカウントがセキュリティグループを削除すると、共有 VPC に関連付けられたセキュリティグループを現在使用している参加者アカウント、共有 VPC 所有者アカウントおよび参加アカウントのリソースの Runtime Monitoring カバレッジステータスが異常になる可能性があります。詳細については、「[ランタイムカバレッジ統計の確認と問題のトラブルシューティング](runtime-monitoring-assessing-coverage.md)」を参照してください。
ステップの詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 セキュリティグループの削除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deleting-security-group.html)」を参照してください。
**EKS クラスターから GuardDuty セキュリティエージェントを削除するには**
モニタリングする必要がなくなった EKS クラスターからセキュリティエージェントを削除するには、「*Amazon EKS ユーザーガイド*」の「[クラスターからの Amazon EKS アドオンの削除](https://docs.aws.amazon.com/eks/latest/userguide/removing-an-add-on.html)」を参照してください。
EKS アドオンエージェントを削除しても、EKS クラスターから `amazon-guardduty` 名前空間は削除されません。`amazon-guardduty` 名前空間を削除するには、「[名前空間の削除](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)」を参照します。
**`amazon-guardduty` 名前空間を削除するには (EKS クラスター)**
自動エージェント設定を無効にしても、EKS クラスターから `amazon-guardduty` 名前空間は自動的に削除されません。`amazon-guardduty` 名前空間を削除するには、「[名前空間の削除](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)」を参照します。