翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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)」を参照してください。