Amazon EC2 インスタンスサポートの前提条件 - Amazon GuardDuty
EC2 インスタンスを SSM 管理にする (自動エージェントのみ)アーキテクチャ要件を検証するマルチアカウント環境での組織サービスコントロールポリシーの検証自動エージェント設定を使用する場合CPU とメモリの制限次のステップ

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon EC2 インスタンスサポートの前提条件

このセクションでは、Amazon EC2 インスタンスのランタイム動作をモニタリングするための前提条件について説明します。これらの前提条件が満たされた後、「GuardDuty Runtime Monitoring の有効化」を参照してください。

EC2 インスタンスを SSM 管理にする (自動エージェント設定のみ)

GuardDuty は AWS Systems Manager (SSM) を使用して、インスタンスにセキュリティエージェントを自動的にデプロイ、インストール、管理します。GuardDuty エージェントを手動でインストールして管理する場合は、SSM は必要ありません。

Amazon EC2 インスタンスを Systems Manager で管理するには、「AWS Systems Manager ユーザーガイド」の「Amazon EC2 インスタンス用のシステムマネージャーのセットアップ」を参照してください。

アーキテクチャ要件を検証する

OS ディストリビューションのアーキテクチャは、GuardDuty セキュリティエージェントの動作に影響を与える可能性があります。Amazon EC2 インスタンスに Runtime Monitoring を使用する前に、次の要件を満たす必要があります。

  • カーネルのサポートには、eBPF、Tracepoints、Kprobe が含まれます。CPU アーキテクチャの場合、Runtime Monitoring は AMD64 (x64) と ARM64 (Graviton2 以降) をサポートしています1。

    次の表は、Amazon EC2 インスタンスの GuardDuty セキュリティエージェントをサポートすることが確認された、OS ディストリビューションを示しています。

    OS ディストリビューション2 カーネルバージョン3
    Amazon Linux 2

    5.44、5.104、5.15
    Amazon Linux 2023

    5.44、 5.104、 5.15、 6.1、 6.5、 6.8、 6.12
    Ubuntu 20.04 および Ubuntu 22.04

    5.44、 5.104、 5.15、 6.1、 6.5、 6.8
    Debian 11 および Debian 12

    5.44、 5.104、 5.15、 6.1、 6.5、 6.8
    Ubuntu 24.04

    6.8

    6.135、6.145
    RedHat 9.4

    5.14
    Fedora 34.0

    5.11、5.17
    フェドラ 40

    6.8
    フェドラ 41

    6.12
    CentOS Stream 9

    5.14
    Oracle Linux 8.9

    5.15
    Oracle Linux 9.3

    5.15
    Rocky Linux 9.5

    5.14

    1. Amazon EC2 リソースの Runtime Monitoring は、A1 インスタンスタイプなどの第 1 世代 Graviton インスタンスをサポートしていません。

    2. さまざまなオペレーティングシステムのサポート - GuardDuty は、前の表に記載されたオペレーティングディストリビューションでの Runtime Monitoring のサポートを検証しました。GuardDuty セキュリティエージェントは、前の表に記載されていないオペレーティングシステムでも実行できますが、GuardDuty チームは予想されるセキュリティ値を保証できません。

    3. カーネルバージョンについては、 CONFIG_DEBUG_INFO_BTFフラグを y (true を意味する) に設定する必要があります。これは、GuardDuty セキュリティエージェントが想定どおりに実行できるようにするために必要です。

    4. カーネルバージョン 5.10 以前の場合、期待どおりに機能するために GuardDuty セキュリティエージェントは RAM (RLIMIT_MEMLOCK) のロックされたメモリを使用します。システムの RLIMIT_MEMLOCK 値が低すぎる場合、GuardDuty ではハード制限とソフト制限の両方を少なくとも 32 MB に設定することをお勧めします。デフォルトの RLIMIT_MEMLOCK 値の検証と変更については、「RLIMIT_MEMLOCK 値のユーザーの表示と更新」を参照してください。

    5. Ubuntu 24.04 では、カーネルバージョン 6.13 および 6.14 は EC2 エージェントバージョン 1.9.1 以降のみをサポートしています。

  • 追加要件 - 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) が出力されます。

  2. 前のコマンドの出力からプロセス ID (pid) をコピーします。

  3. 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 ファイルの設定を上書きします。

  2. /etc/systemd/system.conf ファイルを開き、#DefaultLimitMEMLOCK= がある行のコメントを解除します。

  3. ハード制限とソフト RLIMIT_MEMLOCK 制限の両方を 32 MB 以上に指定して、デフォルト値を更新します。更新は次のようになります: DefaultLimitMEMLOCK=32M:32M。形式は soft-limit:hard-limit です。

  4. sudo reboot を実行します。

マルチアカウント環境での組織サービスコントロールポリシーの検証

組織内のアクセス許可を管理するようにサービスコントロールポリシー (SCP) を設定している場合は、アクセス許可の境界が guardduty:SendSecurityTelemetry アクションを許可していることを確認します。GuardDuty がさまざまなリソースタイプで Runtime Monitoring をサポートする必要があります。

メンバーアカウントの場合は、関連する委任管理者に接続します。組織の SCP の管理については、「Service control policies (SCPs)」を参照してください。

自動エージェント設定を使用する場合

を使用するには自動エージェント設定を使用する (推奨)、 が以下の前提条件を満たす AWS アカウント 必要があります。

  • 自動エージェント設定で包含タグを使用する場合、GuardDuty で新しいインスタンスの SSM 関連付けを作成するには、新しいインスタンスが SSM マネージドであり、https://console.aws.amazon.com/systems-manager/ コンソールの [Fleet Manager] の下に表示されることを確認します。

  • 自動エージェント設定で除外タグを使用する場合:

    • アカウントの GuardDuty 自動エージェントを設定する前に、GuardDutyManaged:false タグを追加します。

      Amazon EC2 インスタンスを起動する前に、必ず除外タグを追加してください。Amazon EC2 の自動エージェント設定を有効にすると、除外タグなしで起動する EC2 インスタンスは、GuardDuty 自動エージェント設定の対象となります。

    • インスタンスの [メタデータ内でタグを許可する] 設定を有効にします。この設定が必要なのは、GuardDuty がインスタンスメタデータサービス (IMDS) から除外タグを読み取って、インスタンスをエージェントインストールから除外するべきかどうかを判断しなければならないからです。詳細については、「Amazon EC2 ユーザーガイド」の「インスタンスメタデータ内のタグへのアクセスを有効にする」を参照してください。

GuardDuty エージェントにおける CPU とメモリの制限

CPU 制限

Amazon EC2 インスタンスに関連付けられている GuardDuty セキュリティエージェントの最大 CPU 制限は、合計 vCPU コアの 10% です。例えば、EC2 インスタンスに 4 つの vCPU コアがある場合、セキュリティエージェントは利用可能な合計 400% のうち最大 40% を使用できます。

メモリ制限

Amazon EC2 インスタンスに関連付けられているメモリから、GuardDuty セキュリティエージェントが使用できるメモリは限られています。

次の表は、メモリ制限を示しています。

Amazon EC2 インスタンスのメモリ

GuardDuty エージェントの最大メモリ

8 GB 未満

128 MB

32 GB 未満

256 MB

32 GB 以上

1 GB

次のステップ

次のステップでは、Runtime Monitoring を設定し、セキュリティエージェントを (自動または手動で) 管理します。