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

# Amazon EC2 執行個體支援的先決條件
<a name="prereq-runtime-monitoring-ec2-support"></a>

本節包含監控 Amazon EC2 執行個體執行時間行為的先決條件。符合這些先決條件後，請參閱 [啟用 GuardDuty 執行期監控](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 受管 （僅適用於自動代理程式組態）
<a name="ssm-managed-prereq-ec2"></a>

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

若要使用 Systems Manager 管理您的 Amazon EC2 執行個體，請參閱*AWS Systems Manager 《 使用者指南*》中的[設定 Amazon EC2 執行個體的 Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)。

## 驗證架構需求
<a name="validating-architecture-req-ec2"></a>

作業系統分佈的架構可能會影響 GuardDuty 安全代理程式的行為。在使用 Amazon EC2 執行個體的執行期監控之前，您必須符合下列要求：
+ 核心支援包括 `eBPF`、 `Tracepoints`和 `Kprobe`。對於 CPU 架構，執行期監控支援 AMD64 (`x64`) 和 ARM64 (Graviton2 及更高版本）[1](#runtime-monitoring-ec2-graviton-2-support)。

  下表顯示已驗證為支援 Amazon EC2 執行個體的 GuardDuty 安全代理程式的作業系統分佈。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

  1. <a name="runtime-monitoring-ec2-graviton-2-support"></a>Amazon EC2 資源的執行期監控不支援第一代 Graviton 執行個體，例如 A1 執行個體類型。

  1. <a name="runtime-monitoring-ec2-os-support"></a>支援各種作業系統 - GuardDuty 已驗證對上表中所列作業系統分佈的執行期監控支援。雖然 GuardDuty 安全代理程式可能會在上表中未列出的作業系統上執行，但 GuardDuty 團隊無法保證預期的安全值。

  1. <a name="runtime-monitoring-ec2-kernel-version-required-flag"></a>對於任何核心版本，您必須將 `CONFIG_DEBUG_INFO_BTF`旗標設定為 `y`（表示 *true*)。這是必要的，以便 GuardDuty 安全代理程式可以如預期般執行。

  1. <a name="runtime-monitoring-ec2-kernel-5-10"></a>對於核心版本 5.10 及更早版本，GuardDuty 安全代理程式會使用 RAM (`RLIMIT_MEMLOCK`) 中的鎖定記憶體來如預期般運作。如果您的系統`RLIMIT_MEMLOCK`值設定太低，GuardDuty 建議將硬性限制和軟性限制設定為至少 32 MB。如需驗證和修改`RLIMIT_MEMLOCK`預設值的詳細資訊，請參閱 [檢視和更新`RLIMIT_MEMLOCK`值](#runtime-monitoring-ec2-modify-rlimit-memlock)。

  1. <a name="runtime-monitoring-ec2-ubuntu-noble-agent-version"></a>對於 Ubuntu 24.04，核心版本 6.13 和 6.14 僅支援 EC2 代理程式版本 1.9.2 及更高版本。
+ 其他要求 - 僅當您有 Amazon ECS/Amazon EC2 時

  對於 Amazon ECS/Amazon EC2，我們建議您使用最新的 Amazon ECS 最佳化 AMIs (2023 年 9 月 29 日或更新版本），或使用 Amazon ECS 代理程式版本 1.77.0。

### 檢視和更新`RLIMIT_MEMLOCK`值
<a name="runtime-monitoring-ec2-modify-rlimit-memlock"></a>

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

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

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

1. 執行 `sudo reboot`。

## 在多帳戶環境中驗證您的組織服務控制政策
<a name="validate-organization-scp-ec2"></a>

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

如果您是成員帳戶，請與相關聯的委派管理員連線。如需有關管理組織 SCPs 的資訊，請參閱[服務控制政策 SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。

## 使用自動代理程式組態時
<a name="runtime-ec2-prereq-automated-agent"></a>

若要 [使用自動代理程式組態 （建議）](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 和記憶體限制
<a name="ec2-cpu-memory-limits-gdu-agent"></a>

**CPU 限制**  
與 Amazon EC2 執行個體相關聯的 GuardDuty 安全代理程式的最大 CPU 限制為 vCPU 核心總數的 10%。例如，如果您的 EC2 執行個體有 4 個 vCPU 核心，則安全代理程式最多可以使用可用總數 400% 的 40%。

**Memory limit (記憶體限制)**  
從與 Amazon EC2 執行個體相關聯的記憶體中，GuardDuty 安全代理程式可以使用的記憶體有限。  
下表顯示記憶體限制。      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

## 下一步驟
<a name="next-step-after-prereq-ec2"></a>

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