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

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

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

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

EC2 インスタンスを SSM マネージドにする

GuardDuty でランタイムイベントをモニタリングする Amazon EC2 インスタンスは、 AWS Systems Manager (SSM) マネージドである必要があります。これは、GuardDuty を使用してセキュリティエージェントを自動的に管理するか、手動で管理するかにかかわらず異なります。ただし、手動 を使用してエージェントを手動で管理する場合方法 2 - Linux パッケージマネージャーを使用する、EC2 インスタンスを SSM 管理する必要はありません。

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

Fedora ベースの EC2 インスタンスに関する注意

AWS Systems Manager は Fedora OS ディストリビューションをサポートしていません。Runtime Monitoring を有効にしたら、手動メソッド (方法 2 - Linux パッケージマネージャーを使用する) を使用して、セキュリティエージェントを Fedora ベースの EC2 インスタンスにインストールします。

サポートされているプラットフォームの詳細については、「 AWS Systems Manager ユーザーガイド」の「サポートされているパッケージプラットフォームとアーキテクチャ」を参照してください。

アーキテクチャ要件の検証

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

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

    OS ディストリビューション1 カーネルバージョン2 カーネルサポート CPU アーキテクチャ
    x64 (AMD64) Graviton (ARM64)

    AL2 と AL2023

    Ubuntu 20.04 および Ubuntu 22.04

    Debian 11 および Debian 12

    5.43、5.103、5.15、6.1、6.5、6.8

    eBPF、Tracepoints、Kprobe

    サポート

    サポート

    Ubuntu 24.04

    		 6.8

    RedHat 9.4

    5.14

    Fedora4 34.0

    5.11、5.17

    CentOS Stream 9

    5.14

    1. さまざまなオペレーティングシステムのサポート - GuardDuty は、前の表に記載されたオペレーティングシステムでの Runtime Monitoring の使用に対するサポートを検証しました。別のオペレーティングシステムを使用している場合でも、GuardDuty が記載されている OS ディストリビューションで提供することを検証したすべての期待されるセキュリティ値を取得できる可能性があります。

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

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

    4. Fedora は、自動エージェント設定でサポートされているプラットフォームではありません。を使用して GuardDuty セキュリティエージェントを Fedora にデプロイできます方法 2 - Linux パッケージマネージャーを使用する。

  • 追加要件 - 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 自動エージェント設定の対象となります。

    • 除外タグを機能させるには、インスタンス設定を更新して、インスタンスメタデータサービス (IMDS) でインスタンスアイデンティティドキュメントが使用可能になるようにします。このステップを実行する手順は、アカウントのRuntime Monitoring の有効化の一部として既に組み込まれています。

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 を設定し、セキュリティエージェントを (自動または手動で) 管理します。