• 2026 年 4 月 30 日之後將不再提供 AWS Systems Manager CloudWatch Dashboard。客戶可以繼續使用 Amazon CloudWatch 主控台來檢視、建立和管理其 Amazon CloudWatch 儀表板，就像現在一樣。如需詳細資訊，請參閱 [Amazon CloudWatch Dashboard 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 如何選取安全性修補程式 中Patch Manager工具 的主要重點 AWS Systems Manager是在受管節點上安裝作業系統安全相關更新。在預設情況下，Patch Manager 不會安裝所有可用的修補程式，而是安裝以安全性為主的部分修補程式。 依預設，Patch Manager 不會使用任何不同名稱的替換套件取代在套件儲存庫中標示為過時的套件，除非另一個套件更新的安裝需要此替換套件。相反地，對於更新套件的命令，Patch Manager 只會報告和安裝已安裝但過時之套件的遺失更新。這是因為取代過時的套件通常需要解除安裝現有的套件並安裝其替換套件。取代過時的套件可能會帶來重大變更或您不想要的其他功能。 此行為與 YUM 和 DNF 的 `update-minimal` 命令一致，其著重於安全性更新，而不是功能升級。如需詳細資訊，請參閱[如何安裝修補程式](patch-manager-installing-patches.md)。 **注意** 當您在修補程式基準規則中使用 `ApproveUntilDate` 參數或 `ApproveAfterDays` 參數時， 會使用國際標準時間 (UTC) Patch Manager評估修補程式發行日期。 例如，對於 `ApproveUntilDate`，如果您指定日期，例如 `2025-11-16`，`2025-11-16T23:59:59Z`則會核准 `2025-11-16T00:00:00Z`和 之間發行的修補程式。 請注意，受管節點上原生套件管理員顯示的修補程式發行日期可能會根據您系統的本機時區顯示不同的時間，但Patch Manager一律使用 UTC 日期時間進行核准計算。這可確保與官方安全諮詢網站上發佈的修補程式發行日期一致。 對於報告修補程式嚴重性級別的 Linux 作業系統類型，Patch Manager 使用軟體發佈者為更新通知或個別修補程式報告的嚴重性級別。Patch Manager 不會從第三方來源推導出嚴重性級別，例如[通用漏洞評分系統](https://www.first.org/cvss/) (CVSS)，或者[美國國家漏洞資料庫](https://nvd.nist.gov/vuln) (NVD) 發佈的指標。 **注意** 在 Patch Manager 支援的所有 Linux 為基礎的系統上，您可以選擇為受管節點設定不同的來源儲存庫，通常用於安裝非安全性更新。如需相關資訊，請參閱[如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)。 請從以下標籤選擇，了解 Patch Manager 如何為您的作業系統選擇安全性修補程式。 ------ #### [ Amazon Linux 2 and Amazon Linux 2023 ] 預先設定的儲存庫在 Amazon Linux 2 上的處理方式與在 Amazon Linux 2023 上不同。 在 Amazon Linux 2 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫。節點上通常會有兩個預先設定的儲存庫 (repos)： **在 Amazon Linux 2 上** + **儲存庫 ID**：`amzn2-core/2/{{architecture}}` **儲存庫名稱**：`Amazon Linux 2 core repository` + **儲存庫 ID**：`amzn2extra-docker/2/{{architecture}}` **儲存庫名稱**：`Amazon Extras repo for docker` **注意** {{架構}}可以是 x86\_64 或 aarch64 (適用於 Graviton 處理器)。 如果您建立 Amazon Linux 2023 (AL2023) 執行個體，它包含 AL2023 版本中可用的更新，以及您選取的特定 AMI。AL2023 執行個體不會在啟動時自動接收其他關鍵和重要的安全性更新。而藉由 AL2023 支援的*透過版本化儲存庫進行確定性升級*功能 (預設為開啟)，您可以根據滿足特定需求的排程套用更新。如需詳細資訊，請參閱《Amazon Linux 2023 使用者指南》**中的[透過版本化儲存庫使用決定性升級](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)一節。 在 AL2023 上，預先設定的儲存庫如下： + **儲存庫 ID**：`amazonlinux` **儲存庫名稱**：Amazon Linux 2023 儲存庫 在 Amazon Linux 2023 （預覽版本） 上，預先設定的儲存庫會繫結至套件更新的*鎖定版本*。所發布的適用於 AL2023 的新 Amazon Machine Images (AMIs) 會鎖定至特定版本。針對修補程式更新，Patch Manager 會擷取修補程式更新儲存庫的最新鎖定版本，然後根據該鎖定版本的內容，更新受管節點上的套件。 **套件管理工具** Amazon Linux 2 受管節點使用 Yum 作為套件管理工具。Amazon Linux 2023 使用 DNF 作為套件管理工具。 這兩個套件管理工具都使用*更新通知*的概念做為一個名為 `updateinfo.xml` 的檔案。更新通知僅只是修復特定問題的套件集合。更新通知中的所有套件皆被 Patch Manager 視為是安全的。個別套件不會被指派分類或嚴重性等級。因此，Patch Manager 會指派更新通知的屬性給相關的套件。 **注意** 如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `updateinfo.xml` 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。 如需有關**包含非安全性更新**選項的詳細資訊，請參閱[如何安裝修補程式](patch-manager-installing-patches.md)和[修補基準規則在 Linux 系統上的運作方式](patch-manager-linux-rules.md)。 ------ #### [ CentOS Stream ] 在 CentOS Stream 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。下列清單提供虛構 CentOS 9.2 Amazon Machine Image(AMI) 的範例： + **儲存庫 ID**：`example-centos-9.2-base` **儲存庫名稱**：`Example CentOS-9.2 - Base` + **儲存庫 ID**：`example-centos-9.2-extras` **儲存庫名稱**：`Example CentOS-9.2 - Extras` + **儲存庫 ID**：`example-centos-9.2-updates` **儲存庫名稱**：`Example CentOS-9.2 - Updates` + **儲存庫 ID**：`example-centos-9.x-examplerepo` **儲存庫名稱**：`Example CentOS-9.x – Example Repo Packages` **注意** 所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。 CentOS Stream 節點使用 DNF 作為套件管理工具。套件管理工具使用更新通知的概念。更新通知僅只是修復特定問題的套件集合。 不過，CentOS Stream 預設儲存庫並未設定更新通知。這表示 Patch Manager 不會偵測預設 CentOS Stream 儲存庫上的套件。若要啟用 Patch Manager 來處理不包含在更新通知中的套件，您必須在修補基準規則中啟用 `EnableNonSecurity` 旗標。 **注意** 支援 CentOS Stream 更新通知。啟動後，可下載含有更新通知的儲存區。 ------ #### [ Debian Server ] 在 Debian Server 上，Systems Manager 修補基準服務會使用執行個體上預先設定的儲存庫 (repos)。這些預先設定的儲存庫可用於提取更新的可用套件升級清單。因此，Systems Manager 執行相當於 `sudo apt-get update` 命令。 然後套件會從 `debian-security {{codename}}` 儲存庫進行篩選。這表示，在每個 Debian Server 版本上，Patch Manager 只會識別屬於該版本關聯儲存庫的升級，如下所示： + Debian Server 11： `debian-security bullseye` + Debian Server 12： `debian-security bookworm` ------ #### [ Oracle Linux ] 在 Oracle Linux 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。節點上通常會有兩個預先設定的儲存庫。 **Oracle Linux 7**︰ + **儲存庫 ID**：`ol7_UEKR5/x86_64` **儲存庫名稱**：`Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)` + **儲存庫 ID**：`ol7_latest/x86_64` **儲存庫名稱**：`Oracle Linux 7Server Latest (x86_64)` **Oracle Linux 8**︰ + **儲存庫 ID**：`ol8_baseos_latest` **儲存庫名稱**：`Oracle Linux 8 BaseOS Latest (x86_64)` + **儲存庫 ID**：`ol8_appstream` **儲存庫名稱**：`Oracle Linux 8 Application Stream (x86_64)` + **儲存庫 ID**：`ol8_UEKR6` **儲存庫名稱**：`Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)` **Oracle Linux 9**： + **儲存庫 ID**：`ol9_baseos_latest` **儲存庫名稱**：`Oracle Linux 9 BaseOS Latest (x86_64)` + **儲存庫 ID**：`ol9_appstream` **儲存庫名稱**：`Oracle Linux 9 Application Stream Packages(x86_64)` + **儲存庫 ID**：`ol9_UEKR7` **儲存庫名稱**：`Oracle Linux UEK Release 7 (x86_64)` **注意** 所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。 Oracle Linux 受管節點使用 Yum 做為套件管理工具，且 Yum 使用更新通知的概念，以做為名為 `updateinfo.xml` 的檔案。更新通知僅只是修復特定問題的套件集合。個別套件不會被指派分類或嚴重性等級。出於此原因，Patch Manager 會為相關套件指派更新通知的屬性，並根據修補基準中指定的分類篩選條件安裝套件。 **注意** 如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `updateinfo.xml` 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。 ------ #### [ AlmaLinux, RHEL, and Rocky Linux ] 在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。節點上通常會有三個預先設定的儲存庫。 所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。 **注意** 如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `updateinfo.xml` 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。 Red Hat Enterprise Linux 7 受管節點使用 Yum 作為套件管理工具。AlmaLinux、Red Hat Enterprise Linux 8 和 Rocky Linux 受管節點使用 DNF 作為套件管理工具。這兩個套件管理工具都使用更新通知的概念做為一個名為 `updateinfo.xml` 的檔案。更新通知僅只是修復特定問題的套件集合。個別套件不會被指派分類或嚴重性等級。出於此原因，Patch Manager 會為相關套件指派更新通知的屬性，並根據修補基準中指定的分類篩選條件安裝套件。 **注意** 在 AlmaLinux 和 Rocky Linux 上，一旦發行相同套件名稱的較新版本，儲存庫可能無法保留較舊版本的套件。如果更新通知參考儲存庫中不再可用的版本， 會使用針對不再可用的版本發佈的建議中繼資料來Patch Manager評估較新版本的安裝。這可確保當儲存庫中不再有無法使用的版本時，套用待定修補程式。 這可能會導致Patch Manager安裝較新版本的套件，即使其相關聯的建議是在設定的 `ApproveUntilDate`或 之後發行`ApproveAfterDays`。 RHEL 7 下列儲存庫 ID 與 RHUI 2 相關聯。RHUI 3 於 2019 年 12 月推出，並為 Yum 儲存庫 ID 引入了不同的命名方式。根據您建立受管節點的 RHEL-7 AMI，您可能需要更新命令。如需詳細資訊，請參閱 Red Hat [RHEL 客戶入口網站上 AWS 變更的 中 7 的儲存庫 IDs](https://access.redhat.com/articles/4599971)。 ** + **儲存庫 ID**：`rhui-REGION-client-config-server-7/x86_64` **儲存庫名稱**：`Red Hat Update Infrastructure 2.0 Client Configuration Server 7` + **儲存庫 ID**：`rhui-REGION-rhel-server-releases/7Server/x86_64` **儲存庫名稱**：`Red Hat Enterprise Linux Server 7 (RPMs)` + **儲存庫 ID**：`rhui-REGION-rhel-server-rh-common/7Server/x86_64` **儲存庫名稱**：`Red Hat Enterprise Linux Server 7 RH Common (RPMs)` AlmaLinux 8、RHEL 8 和 Rocky Linux 8 + **儲存庫 ID**：`rhel-8-appstream-rhui-rpms` **儲存庫名稱**：`Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)` + **儲存庫 ID**：`rhel-8-baseos-rhui-rpms` **儲存庫名稱**：`Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)` + **儲存庫 ID**：`rhui-client-config-server-8` **儲存庫名稱**：`Red Hat Update Infrastructure 3 Client Configuration Server 8` AlmaLinux 9、RHEL 9 和 Rocky Linux 9 + **儲存庫 ID**：`rhel-9-appstream-rhui-rpms` **儲存庫名稱**：`Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)` + **儲存庫 ID**：`rhel-9-baseos-rhui-rpms` **儲存庫名稱**：`Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)` + **儲存庫 ID**：`rhui-client-config-server-9` **儲存庫名稱**：`Red Hat Enterprise Linux 9 Client Configuration` ------ #### [ SLES ] 在 SUSE Linux Enterprise Server (SLES) 受管節點上，ZYPP 程式庫從下列位置取得可用修補程式的集合 (套件的集合)： + 儲存庫的清單：`etc/zypp/repos.d/*` + 套件資訊：`/var/cache/zypp/raw/*` SLES 受管節點使用 Zypper 作為套件管理工具，Zypper 使用修補程式的概念。修補程式只是修復特定問題的套件集合。Patch Manager 處理安全性相關修補程式中參考的所有套件。由於個別套件並未指定分類或嚴重性，因此 Patch Manager 會將修補程式所屬的屬性指派給套件。 ------ #### [ Ubuntu Server ] 在 Ubuntu Server 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。這些預先設定的儲存庫可用於提取更新的可用套件升級清單。因此，Systems Manager 執行相當於 `sudo apt-get update` 命令。 然後套件會從 `{{codename}}-security` 儲存庫中進行篩選，其中的代號名稱為發行版本專屬，例如 Ubuntu Server 14 的 `trusty`。Patch Manager 僅識別屬於這些儲存庫之一部分的升級： + Ubuntu Server 16.04 LTS︰`xenial-security` + Ubuntu Server 18.04 LTS︰`bionic-security` + Ubuntu Server 20.04 LTS︰`focal-security` + Ubuntu Server 22.04 LTS (`jammy-security`) + Ubuntu Server 24.04 LTS (`noble-security`) + Ubuntu Server 25.04 (`plucky-security`) ------ #### [ Windows Server ] 在 Microsoft Windows 作業系統上，Patch Manager 會擷取 Microsoft 透過更新服務發佈的可用更新清單，並自動對 Windows Server Update Services (WSUS) 可用。 **注意** Patch Manager 僅為 Patch Manager 支援的 Windows Server 作業系統版本提供可用的修補程式。例如，Patch Manager 無法用於修補 Windows RT。 Patch Manager 持續監控每個 AWS 區域中的新更新。各個區域中可用的更新清單將至少每天重新整理一次。Microsoft 的修補程式資訊經處理後，Patch Manager 會從其修補程式清單中刪除已被更新版本取代的更新。因此，只有最新的更新會顯示出來並提供安裝。例如，如果 `KB4012214` 取代了 `KB3135456`，Patch Manager 中只會有 `KB4012214` 可供更新。 同樣地，Patch Manager 只能在修補操作期間安裝受管節點上提供的修補程式。依預設，Windows Server 2019 和 Windows Server 2022 會移除更新，而這些更新會由稍後的更新取代。因此，如果您在 Windows Server 修補基準中使用 `ApproveUntilDate` 參數，但 `ApproveUntilDate` 參數中選取的日期*早於*最新修補程式的日期，則會發生下列情況： + 取代的修補程式會從節點中移除，因此無法使用 Patch Manager 進行安裝。 + 節點上存在最新的替代修補程式，但尚未根據 `ApproveUntilDate` 參數指定的日期核准安裝。 這表示即使可能未安裝上個月的關鍵修補程式，受管節點在 Systems Manager 操作方面也符合規範。使用 `ApproveAfterDays` 參數時，可能會發生相同的情況。由於 Microsoft 取代了修補程式行為，可以設定數字 (通常大於 30 天)，這樣，若在 `ApproveAfterDays` 的天數之前發行 Microsoft 最新的可用修補程式，則永遠不會安裝 Windows Server 的修補程式。請注意，如果您已修改 Windows 群組政策物件 (GPO) 設定，以在受管節點上提供取代的修補程式，則此系統行為不適用。 **注意** 在某些情況下，Microsoft 會針對未指定更新日期和時間的應用程式發行修補程式。在這些情況下，預設會提供 `01/01/1970` 的更新日期和時間。 ------