翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 を設定し、セキュリティエージェントを (自動または手動で) 管理します。