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

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

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

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

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

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

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

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

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
    Ubuntu 24.04

    6.8
    Debian 11 および Debian 12

    5.44、5.104、5.15、6.1、6.5、6.8
    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 リソースのランタイムモニタリングは、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 値の表示と更新。

  • 追加要件 - 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. を前のステップからコピーしたプロセス ID pidに置き換え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制限の両方を 32MB 以上に指定して、デフォルト値を更新します。更新は次のようになります: 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 を設定し、セキュリティエージェントを (自動または手動で) 管理します。