本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
如何選取安全性修補程式
的主要重點 Patch Manager是 的功能 AWS Systems Manager，它正在受管節點上安裝作業系統安全相關更新。根據預設，Patch Manager 不會安裝所有可用的修補程式，而是專注於安全性的小型修補程式集。
對於報告修補程式嚴重性層級的 Linux 作業系統類型，Patch Manager 使用軟體發佈者報告的嚴重性層級進行更新通知或個別修補程式。Patch Manager 不會從第三方來源衍生嚴重性等級，例如通用漏洞評分系統
注意
在 支援的所有 Linux 系統上 Patch Manager，您可以選擇為受管節點設定的不同來源儲存庫，通常用於安裝非安全更新。如需相關資訊，請參閱 如何指定替代修補程式來源儲存庫 (Linux)。
從下列索引標籤中選擇，以了解如何 Patch Manager 會為您的作業系統選取安全修補程式。
- Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023
-
Amazon Linux 1 和 Amazon Linux 2 上的預先設定儲存庫處理方式與 Amazon Linux 2022 和 Amazon Linux 2023 上的處理方式不同。
在 Amazon Linux 1 和 Amazon Linux 2 上，Systems Manager 修補程式基準服務會在受管節點上使用預先設定的儲存庫。節點上通常會有兩個預先設定的儲存庫 (repos)：
在 Amazon Linux 1 上
-
儲存庫 ID：
amzn-main/latest儲存庫名稱：
amzn-main-Base -
儲存庫 ID：
amzn-updates/latest儲存庫名稱：
amzn-updates-Base
在 Amazon Linux 2 上
-
儲存庫 ID：
amzn2-core/2/architecture儲存庫名稱：
Amazon Linux 2 core repository -
儲存庫 ID：
amzn2extra-docker/2/architecture儲存庫名稱：
Amazon Extras repo for docker
注意
architecture可以是 x86_64 或 aarch64。Amazon Linux 2023 （AL2023） 執行個體最初包含 AL2023 版本和所選 中的可用更新 AMI。 根據預設，您的 AL2023 執行個體不會在啟動時自動接收其他重要且重要的安全更新。相反地，在預設開啟的 AL2023 中，透過版本控制儲存庫功能進行決定性升級，您可以根據符合您特定需求的排程來套用更新。如需詳細資訊，請參閱《Amazon Linux 2023 使用者指南》中的透過版本化儲存庫使用決定性升級一節。
在 Amazon Linux 2022 上，預先設定的儲存庫會繫結至套件更新的鎖定版本。當新 時 Amazon Machine Images (AMIs） 已發行，它們會鎖定到特定版本。對於修補程式更新，Patch Manager 會擷取修補程式更新儲存庫的最新鎖定版本，然後根據該鎖定版本的內容更新受管節點上的套件。
在 AL2023 上，預先設定的儲存庫如下：
-
儲存庫 ID：
amazonlinux儲存庫名稱：Amazon Linux 2023 儲存庫
在 Amazon Linux 2022 (預覽版本) 上，預先設定的儲存庫會繫結至套件更新的鎖定版本。當新 時 Amazon Machine Images (AMIs） 已發行，它們會鎖定到特定版本。對於修補程式更新，Patch Manager 會擷取修補程式更新儲存庫的最新鎖定版本，然後根據該鎖定版本的內容更新受管節點上的套件。
在 Amazon Linux 2022 上，預先設定的存儲庫如下：
-
儲存庫 ID：
amazonlinux儲存庫名稱：Amazon Linux 2022 儲存庫
注意
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
Amazon Linux 1 和 Amazon Linux 2 受管節點使用 Yum 作為套件管理員。Amazon Linux 2022 和 Amazon Linux 2023 DNF用作套件管理員。
這兩個套件管理工具都使用更新通知的概念做為一個名為
updateinfo.xml的檔案。更新通知僅只是修復特定問題的套件集合。所有位於更新通知中的套件都被視為安全性 Patch Manager。 個別套件不會指派分類或嚴重性層級。因此 Patch Manager 會將更新通知的屬性指派給相關套件。注意
如果您在建立修補基準頁面中選取包含非安全性更新核取方塊，則在
updateinfo.xml檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。 -
- CentOS and CentOS Stream
-
在 CentOS 和 上 CentOS Stream，Systems Manager 修補程式基準服務會在受管節點上使用預先設定的儲存庫 （Repos）。下列清單提供虛構 CentOS 8.2 的範例 Amazon Machine Image (AMI):
-
儲存庫 ID：
example-centos-8.2-base儲存庫名稱：
Example CentOS-8.2 - Base -
儲存庫 ID：
example-centos-8.2-extras儲存庫名稱：
Example CentOS-8.2 - Extras -
儲存庫 ID：
example-centos-8.2-updates儲存庫名稱：
Example CentOS-8.2 - Updates -
儲存庫 ID：
example-centos-8.x-examplerepo儲存庫名稱：
Example CentOS-8.x – Example Repo Packages
注意
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
CentOS 6 和 7 受管節點使用 Yum 作為套件管理工具。CentOS 8 和 CentOS Stream 節點DNF用作套件管理員。這兩個套件管理工具都使用更新通知的概念。更新通知僅只是修復特定問題的套件集合。
不過，CentOS 和 CentOS Stream 預設位置未設定更新通知。這表示 Patch Manager 無法在預設 CentOS 和 上偵測套件 CentOS Stream 回收。若要允許 Patch Manager 若要處理更新通知中未包含的套件，您必須開啟修補程式基準規則中的
EnableNonSecurity旗標。注意
CentOS 和 CentOS Stream 支援更新通知。啟動後，可下載含有更新通知的儲存區。
-
- Debian Server and Raspberry Pi OS
-
開啟 Debian Server 以及 Raspberry Pi OS （先前為 Raspbian），Systems Manager 修補程式基準服務會在執行個體上使用預先設定的儲存庫 （Repos）。這些預先設定的儲存庫可用於提取更新的可用套件升級清單。因此，Systems Manager 執行相當於
sudo apt-get update命令。然後套件會從
debian-security儲存庫進行篩選。這表示在每個版本的 Debian Server, Patch Manager 僅識別屬於該版本關聯儲存庫一部分的升級，如下所示：codename-
Debian Server 8：
debian-security jessie -
Debian Server 9：
debian-security stretch -
Debian Server 10：
debian-security buster -
Debian Server 11：
debian-security bullseye -
Debian Server 12：
debian-security bookworm
注意
開啟 Debian Server 僅限 8：因為有些 Debian Server 8.* 受管節點是指過時的套件儲存庫 （
jessie-backports），Patch Manager 會執行其他步驟，以確保修補操作成功。如需詳細資訊，請參閱如何安裝修補程式。 -
- 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 作為套件管理員。 AlmaLinuxRed Hat Enterprise Linux 8，以及 Rocky Linux 受管節點使用 DNF作為套件管理員。這兩個套件管理工具都使用更新通知的概念做為一個名為
updateinfo.xml的檔案。更新通知僅只是修復特定問題的套件集合。個別套件不會被指派分類或嚴重性等級。因此 Patch Manager 會將更新通知的屬性指派給相關套件，並根據修補程式基準中指定的分類篩選條件安裝套件。- RHEL 7
-
注意
下列儲存庫與 2 RHUI IDs相關聯。RHUI 3 於 2019 年 12 月推出，並推出適用於百勝儲存庫 的不同命名方案IDs。根據 RHEL-7 AMI 您從 建立受管節點，您可能需要更新命令。如需詳細資訊，請參閱 IDs的儲存庫 RHELRed Hat 客戶入口網站 上的 AWS 7 已變更
。 -
儲存庫 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-securitytrusty的 Ubuntu Server 14.Patch Manager 僅識別屬於這些資源庫一部分的升級：-
Ubuntu Server 14.04LTS：
trusty-security -
Ubuntu Server 16.04 LTS：
xenial-security -
Ubuntu Server 18.04 LTS：
bionic-security -
Ubuntu Server 20.04 LTS：
focal-security -
Ubuntu Server 20.10 STR：
groovy-security -
Ubuntu Server 22.04 LTS（
jammy-security） -
Ubuntu Server 23.04 （
lunar-security）
-
- Windows Server
-
在 Microsoft Windows 作業系統上，Patch Manager 擷取 Microsoft 發佈至 Microsoft Update 且自動提供給 Windows Server Update Services （） 的可用更新清單WSUS。
注意
Patch Manager 只為 提供可用的修補程式 Windows Server 支援的作業系統版本 Patch Manager。 例如，Patch Manager 無法用來修補 Windows RT。
Patch Manager 會持續監控每個 中的新更新 AWS 區域。各個區域中可用的更新清單將至少每天重新整理一次。處理 Microsoft 的修補程式資訊時，Patch Manager 會從其修補程式清單 移除由稍後更新取代的更新。因此，只有最新的更新會顯示出來並提供安裝。例如，如果
KB4012214取代KB3135456，KB4012214則 中只會提供作為更新 Patch Manager.同樣地 Patch Manager 只能安裝在修補操作期間受管節點上可用的修補程式。根據預設，Windows Server 2019 年和 Windows Server 2022 會移除由稍後更新取代的更新。因此，如果您在 中使用
ApproveUntilDate參數 Windows Server 修補程式基準，但ApproveUntilDate參數中選取的日期早於最新修補程式的日期，則會發生下列情況：-
取代的修補程式已從節點移除，因此無法使用 進行安裝 Patch Manager.
-
節點上存在最新的替代修補程式，但尚未根據
ApproveUntilDate參數指定的日期核准安裝。
這表示受管節點在 Systems Manager 操作方面符合規範，即使上個月的重要修補程式可能未安裝。使用
ApproveAfterDays參數時，可能會發生相同的情況。由於 Microsoft 取代修補程式行為，因此可以設定數字 （通常大於 30 天），以便針對 的修補程式 Windows Server 如果 Microsoft 的最新可用修補程式在ApproveAfterDays的天數到期之前發行，則永遠不會安裝 。請注意，如果您已修改 Windows 群組政策物件 （GPO） 設定，讓受管節點上可用的取代修補程式，則此系統行為不適用。注意
在某些情況下，Microsoft 會針對未指定更新日期和時間的應用程式發行修補程式。在這些情況下，預設會提供
01/01/1970的更新日期和時間。 -
