Amazon EC2 執行個體支援的先決條件 - Amazon GuardDuty
讓 EC2 執行個體 SSM 受管 （僅適用於自動化代理程式）驗證架構需求在多帳戶環境中驗證您的組織服務控制政策使用自動代理程式組態時CPU 和記憶體限制下一步驟

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon EC2 執行個體支援的先決條件

本節包含監控 Amazon EC2 執行個體執行時間行為的先決條件。符合這些先決條件後，請參閱 啟用 GuardDuty 執行期監控。

讓 EC2 執行個體 SSM 受管 （僅適用於自動代理程式組態）

GuardDuty 使用 AWS Systems Manager (SSM) 在您的執行個體上自動部署、安裝和管理安全代理程式。如果您打算手動安裝和管理 GuardDuty 代理程式，則不需要 SSM。

若要使用 Systems Manager 管理您的 Amazon EC2 執行個體，請參閱AWS Systems Manager 《 使用者指南》中的設定 Amazon EC2 執行個體的 Systems Manager。

驗證架構需求

作業系統分佈的架構可能會影響 GuardDuty 安全代理程式的行為。在使用 Amazon EC2 執行個體的執行期監控之前，您必須符合下列要求：

  • 核心支援包括 eBPF、 Tracepoints和 Kprobe。對於 CPU 架構，執行期監控支援 AMD64 (x64) 和 ARM64 (Graviton2 及更高版本）1。

    下表顯示已驗證為支援 Amazon EC2 執行個體的 GuardDuty 安全代理程式的作業系統分佈。

    作業系統分佈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
    Fedora 40

    6.8
    Fedora 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 資源的執行期監控不支援第一代 Graviton 執行個體，例如 A1 執行個體類型。

    2. 支援各種作業系統 - GuardDuty 已驗證對上表中所列作業系統分佈的執行期監控支援。雖然 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 最佳化 AMIs （日期為 2023 年 9 月 29 日或更新版本），或使用 Amazon ECS 代理程式版本 1.77.0。

檢視和更新RLIMIT_MEMLOCK值

當您的系統RLIMIT_MEMLOCK限制設定過低時，GuardDuty 安全代理程式可能無法如設計般執行。GuardDuty 建議硬限制和軟限制必須至少為 32 MB。如果您未更新限制，GuardDuty 將無法監控資源的執行期事件。當 RLIMIT_MEMLOCK 高於最低規定限制時，您可以選擇性地更新這些限制。

您可以在安裝 GuardDuty 安全代理程式之前或之後修改RLIMIT_MEMLOCK預設值。

檢視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. 透過提供至少 32MB 的硬性限制和軟性RLIMIT_MEMLOCK限制來更新預設值。更新應如下所示：DefaultLimitMEMLOCK=32M:32M。格式是 soft-limit:hard-limit。

  4. 執行 sudo reboot。

在多帳戶環境中驗證您的組織服務控制政策

如果您已設定服務控制政策 (SCP) 來管理組織中的許可，請驗證許可界限是否允許 guardduty:SendSecurityTelemetry動作。GuardDuty 需要支援不同資源類型的執行期監控。

如果您是成員帳戶，請與相關聯的委派管理員連線。如需有關管理組織 SCPs的資訊，請參閱服務控制政策 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%。

Memory limit (記憶體限制)

從與 Amazon EC2 執行個體相關聯的記憶體中，GuardDuty 安全代理程式可以使用的記憶體有限。

下表顯示記憶體限制。

Amazon EC2 執行個體的記憶體

GuardDuty 代理程式的最大記憶體

小於 8 GB

128 MB

少於 32 GB

256 MB

大於或等於 32 GB

1 GB

下一步驟

下一個步驟是設定執行期監控，以及管理安全代理程式 （自動或手動）。