如何選取安全性修補程式

Patch Manager ( AWS Systems Manager的功能) 的主要重點是在受管節點上安裝與作業系統安全相關的更新。在預設情況下，Patch Manager 不會安裝所有可用的修補程式，而是安裝以安全性為主的部分修補程式。

針對報告修補程式嚴重性層級的 Linux 作業系統類型，Patch Manager會針對更新通知或個別修補程式使用軟體發行者報告的嚴重性層級。 Patch Manager不會從第三方來源 (例如常見弱點評分系統 (CVSS) 或國家弱點資料庫 (NVD) 所發行的指標衍生嚴重性層級。

注意

在 Patch Manager 支援的所有 Linux 為基礎的系統上，您可以選擇為受管節點設定不同的來源儲存庫，通常用於安裝非安全性更新。如需相關資訊，請參閱 如何指定替代修補程式來源儲存庫 (Linux)。

請從以下標籤選擇，了解 Patch Manager 如何為您的作業系統選擇安全性修補程式。

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

預先設定的儲存庫在 Amazon Linux 1 和 Amazon Linux 2 上的處理方式與 Amazon 2022 和 Amazon Linux 2023 上的處理方式不同。

在 Amazon Linux 1 和 Amazon Linux 2 上，Systems Manager 修補程式基準服務會在受管節點上使用預先設定的儲存庫。節點上通常會有兩個預先設定的儲存庫 (repos)：

在 Amazon 1

• 儲存庫 ID：amzn-main/latest

  儲存庫名稱：amzn-main-Base

• 儲存庫 ID：amzn-updates/latest

  儲存庫名稱：amzn-updates-Base

在 Amazon 2

• 儲存庫 ID：amzn2-core/2/architecture

  儲存庫名稱：Amazon Linux 2 core repository

• 儲存庫 ID：amzn2extra-docker/2/architecture

  儲存庫名稱：Amazon Extras repo for docker

注意

architecture 可以是 64 或者是 64。

Amazon Linux 2023 (AL2023) 執行個體最初包含在 AL2 023 版和所選版本中可用的更新。AMI根據預設，您的 AL2 023 執行個體不會在啟動時自動接收其他重要和重要的安全性更新。取而代之的是，AL2023 中的透過版本化儲存庫功能進行確定性升級 (預設為開啟)，您可以根據符合特定需求的排程套用更新。如需詳細資訊，請參閱《Amazon Linux 2023 使用者指南》中的透過版本化儲存庫使用決定性升級一節。

在 Amazon Linux 2022 上，預先設定的儲存庫會繫結至套件更新的鎖定版本。當新的 Amazon Machine Images (AMIs) for Amazon Linux 2022 發布時，會鎖定至特定版本。針對修補程式更新，Patch Manager 會擷取修補程式更新儲存庫的最新鎖定版本，然後根據該鎖定版本的內容，更新受管節點上的套件。

在 AL2 023 上，預先設定的儲存庫如下：

• 儲存庫 ID：amazonlinux

  儲存庫名稱：Amazon Linux 2023 儲存庫

在 Amazon Linux 2022 (預覽版本) 上，預先設定的儲存庫會繫結至套件更新的鎖定版本。當新的 Amazon Machine Images (AMIs) for Amazon Linux 2022 發布時，會鎖定至特定版本。針對修補程式更新，Patch Manager 會擷取修補程式更新儲存庫的最新鎖定版本，然後根據該鎖定版本的內容，更新受管節點上的套件。

在 Amazon Linux 2022 上，預先設定的存儲庫如下：

• 儲存庫 ID：amazonlinux

  儲存庫名稱：Amazon Linux 2022 儲存庫

注意

所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。

Amazon Linux 1 和 Amazon Linux 2 受管節點使用 Yum 作為軟件包管理器。Amazon 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 codename 儲存庫進行篩選。這表示在每個版本上Debian Server，Patch Manager只會識別屬於該版本相關存放庫一部分的升級，如下所示：

• Debian Server 8︰debian-security jessie

• Debian Server9: debian-security stretch

• Debian Server十:debian-security buster

• Debian Serverdebian-security bullseye

• Debian Serverdebian-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

開啟 AlmaLinuxRed Hat Enterprise Linux、和 Rocky Linux Systems Manager 修補程式基準服務會在受管理的節點上使用預先設定的儲存庫 (存放庫)。節點上通常會有三個預先設定的儲存庫。

所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。

注意

如果您在建立修補基準頁面中選取包含非安全性更新核取方塊，則在 updateinfo.xml 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。

Red Hat Enterprise Linux7 個受管理節點使用 Yum 做為套件管理員。 AlmaLinux、Red Hat Enterprise Linux 8 和Rocky Linux受管節點用DNF作套件管理員。這兩個套件管理工具都使用更新通知的概念做為一個名為 updateinfo.xml 的檔案。更新通知僅只是修復特定問題的套件集合。個別套件不會被指派分類或嚴重性等級。出於此原因，Patch Manager 會為相關套件指派更新通知的屬性，並根據修補基準中指定的分類篩選條件安裝套件。

RHEL 7

注意

以下回購IDs與 RHUI 2 相關聯。RHUI3 於 2019 年 12 月推出，並為 Yum 資料庫引入了不同的命名方案IDs。根據AMI您建立受管節點的 RHEL -7，您可能需要更新指令。如需詳細資訊，請參閱 Red Hat 客戶入口網站上的AWS 已變更中的 RHEL 7 個儲存庫IDs。

• 儲存庫 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、RHEL八和Rocky Linux八

• 儲存庫 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 九、RHEL九和Rocky Linux九

• 儲存庫 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四分LTS之一 trusty-security

• Ubuntu Server四分LTS之一 xenial-security

• Ubuntu Serverbionic-securityLTS

• Ubuntu Server20.04LTS：focal-security

• Ubuntu Server20.10：STRgroovy-security

• Ubuntu Server22.04 LTS () jammy-security

• Ubuntu Server二月四日 lunar-security

Windows Server

在 Microsoft Windows 作業系統上，Patch Manager擷取 Microsoft 發佈至 Microsoft 更新並自動提供給 Windows 伺服器更新服務的可用更新清單 (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 Server2019 Windows Server 年和 2022 會移除由稍後更新取代的更新。因此，如果您在Windows Server修補程式基準中使用ApproveUntilDate參數，但在ApproveUntilDate參數中選取的日期早於最新修補程式的日期，則會發生下列情況：

• 已取代的修補程式會從節點中移除，因此無法使用. Patch Manager

• 最新的取代修補程式會出現在節點上，但尚未核准根據ApproveUntilDate參數的指定日期進行安裝。

這表示受管理節點在 Systems Manager 作業方面符合規範，即使上個月的重要修補程式可能未安裝。使用ApproveAfterDays參數時，可能會發生這種情況。由於 Microsoft ApproveAfterDays 已取代的修補程式行為，因此可以設定數字 (通常超過 30 天)，如果 Microsoft 提供的最新可用Windows Server修補程式在中的天數之前發行，則永遠不會安裝的修補程式。請注意，如果您已修改 Windows 全域原則物件 (GPO) 設定，以便在受管理的節點上提供取代的修補程式，則不適用此系統行為。

注意

在某些情況下，Microsoft 會針對未指定更新日期和時間的應用程式發佈修補程式。在這些情況下，預設會提供 01/01/1970 的更新日期和時間。