如何安裝修補程式 - AWS Systems Manager

如何安裝修補程式

Patch Manager (AWS Systems Manager 的功能) 使用適當的內建機制,讓某種作業系統類型在受管節點上安裝更新。例如,在 Windows Server 上使用 Windows Update API,在 Amazon Linux 上使用 yum 套件管理員。

請從以下標籤選擇,了解 Patch Manager 如何在作業系統上安裝修補程式。

Amazon Linux and Amazon Linux 2

在 Amazon Linux 和 Amazon Linux 2 受管節點上,修補程式安裝工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單,系統會安裝列出的修補程式,並略過步驟 2-7。

  2. 套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  3. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除,將會套用隱含規則,以僅選擇安全儲存庫中包含升級的套件。對於每個套件,套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新,則也會考慮來自其他儲存庫的修補程式。

  4. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  5. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  6. 如果核准修補程式的多個版本,將會套用最新版本。

  7. YUM 更新 API 會套用至核准的修補程式,如下所示:

    • 若 AWS 提供的預先定義預設修補基準,以及 Approved patches include non-security updates (包含非安全性更新的已核准修補程式) 的自訂修補基準核取方塊未選取,則只會套用 updateinfo.xml 中指定的修補程式 (僅限安全性更新)。

      此工作流程的同等 yum 命令為:

      sudo yum update-minimal --sec-severity=critical,important --bugfix -y
    • 對於選取 Approved patches include non-security updates (已核准修補程式包含非安全性更新) 核取方塊的修補基準,位於 updateinfo.xml 中的修補程式和不位於 updateinfo.xml 中的修補程式皆會套用 (安全性和非安全性更新)。

      此工作流程的同等 yum 命令為:

      sudo yum update --security --bugfix
  8. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

CentOS

在 CentOS 受管節點上,修補程式安裝工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單,系統會安裝列出的修補程式,並略過步驟 2-7。

    套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  2. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除,將會套用隱含規則,以僅選擇安全儲存庫中包含升級的套件。對於每個套件,套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新,則也會考慮來自其他儲存庫的修補程式。

  3. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  4. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  5. 如果核准修補程式的多個版本,將會套用最新版本。

  6. YUM 更新 API (在 CentOS 6.x 和 7.x 版本上) 或 DNF 更新 (在 CentOS 8 上) 會套用至核准的修補程式。

  7. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

Debian Server and Raspberry Pi OS

在 Debian Server 和 Raspberry Pi OS (先前的 Raspbian) 執行個體上,修補程式安裝工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單,系統會安裝列出的修補程式,並略過步驟 2-7。

  2. 若有可用於 python3-apt (libapt 的 Python 程式庫界面) 的更新,它會升級到最新版本。(這個非安全性套件會升級,即使您未選取 Include nonsecurity updates (包含非安全性更新) 選項)。

    重要

    僅限於 Debian Server 8 上:由於某些 Debian Server 8.* 受管節點會參考已淘汰的套件庫 (jessie-backports),因此 Patch Manager 會執行下列額外的步驟以確保修補操作成功。

    1. 在您的受管節點上,對 jessie-backports 儲存庫的參考從來源位置清單 (/etc/apt/sources.list.d/jessie-backports) 會變更為註解。因此,不會嘗試從該位置下載修補程式,

    2. 並會匯入延展安全性更新簽署金鑰。此金鑰提供了 Debian Server 8.* 發行版本的更新和安裝操作所需的許可。

    3. 系統此時會執行 apt-get 操作以確保在修補程序開始之前已安裝最新版本的 python3-apt

    4. 安裝程序完成後,會還原對 jessie-backports 儲存庫的參考,並從 apt 來源金鑰環中移除簽署金鑰。這麼做是為了讓系統組態保持在修補操作之前的狀態。

    Patch Manager 下次更新系統時,會重複執行相同的程序。

  3. 套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  4. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    注意

    因為無法可靠地判斷 Debian Server 更新套件的發行日期,此作業系統不支援自動核准選項。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除,將會套用隱含規則,以僅選擇安全儲存庫中包含升級的套件。對於每個套件,套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新,則也會考慮來自其他儲存庫的修補程式。

    注意

    對於 Debian Server 和 Raspberry Pi OS 來說,修補程式候選版本僅限於 debian-security 中包含的修補程式。

  5. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  6. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  7. APT 程式庫用於升級套件。

  8. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

macOS

在 macOS 受管節點上,修補程式安裝工作流程如下:

  1. /Library/Receipts/InstallHistory.plist 屬性清單是使用 softwareupdateinstaller 套件管理工具的已安裝和已升級軟體記錄。使用 pkgutil 命令列工具 (用於 installer) 以及 softwareupdate 套件管理工具時,會執行 CLI 命令來剖析此清單。

    對於 installer,對 CLI 命令的回應包括 package nameversionvolumelocationinstall-time 詳細資訊,但 Patch Manager 僅使用 package nameversion

    對於 softwareupdate,對 CLI 命令的回應會包含套件名稱 (display name)、versiondate,但 Patch Manager 只會使用套件名稱和版本。

    對於 Brew 和 Brew Cask,Homebrew 不支援其在根使用者下執行的命令。因此,Patch Manager 以 Homebrew 目錄的擁有者或屬於 Homebrew 目錄之擁有者群組的有效使用者身分查詢和執行 Homebrew 命令。這些命令類似於 softwareupdateinstaller 並透過 Python 子程序執行命令,以收集套件資料,並解析輸出以識別套件名稱和版本。

  2. 套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  3. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

  4. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  5. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  6. 如果核准修補程式的多個版本,將會套用最新版本。

  7. 在受管節點上叫用適當的套件 CLI,以處理核准的修補程式,如下所示:

    注意

    installer 缺乏檢查和安裝更新的功能。因此,對於 installer,Patch Manager 只會報告已安裝的套件。因此,installer 套件永遠不會報告為 Missing

    • 若 AWS 提供的預先定義預設修補基準,以及 Approved patches include non-security updates (包含非安全性更新的已核准修補程式) 的自訂修補基準核取方塊選取,則只會套用安全性更新。

    • 對於選取 Approved patches include non-security updates (已核准修補程式包含非安全性更新) 核取方塊的修補基準,皆會套用安全性和非安全性更新。

  8. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

Oracle Linux

在 Oracle Linux 受管節點上,修補程式安裝工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單,系統會安裝列出的修補程式,並略過步驟 2-7。

  2. 套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  3. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除,將會套用隱含規則,以僅選擇安全儲存庫中包含升級的套件。對於每個套件,套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新,則也會考慮來自其他儲存庫的修補程式。

  4. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  5. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  6. 如果核准修補程式的多個版本,將會套用最新版本。

  7. 在版本 7 受管節點上,YUM 更新 API 會套用至核准的修補程式,如下所示:

    • 若 AWS 提供的預先定義預設修補基準,以及 Approved patches include non-security updates (包含非安全性更新的已核准修補程式) 的自訂修補基準核取方塊未選取,則只會套用 updateinfo.xml 中指定的修補程式 (僅限安全性更新)。

      此工作流程的同等 yum 命令為:

      sudo yum update-minimal --sec-severity=important,moderate --bugfix -y
    • 對於選取 Approved patches include non-security updates (已核准修補程式包含非安全性更新) 核取方塊的修補基準,位於 updateinfo.xml 中的修補程式和不位於 updateinfo.xml 中的修補程式皆會套用 (安全性和非安全性更新)。

      此工作流程的同等 yum 命令為:

      sudo yum update --security --bugfix -y

      在版本 8 受管節點上,Dnf 更新 API 會套用至核准的修補程式,如下所示:

      • 若 AWS 提供的預先定義預設修補基準,以及 Approved patches include non-security updates (包含非安全性更新的已核准修補程式) 的自訂修補基準核取方塊未選取,則只會套用 updateinfo.xml 中指定的修補程式 (僅限安全性更新)。

        此工作流程的同等 yum 命令為:

        sudo dnf upgrade-minimal --security --sec-severity Moderate --sec-severity Important
      • 對於選取 Approved patches include non-security updates (已核准修補程式包含非安全性更新) 核取方塊的修補基準,位於 updateinfo.xml 中的修補程式和不位於 updateinfo.xml 中的修補程式皆會套用 (安全性和非安全性更新)。

        此工作流程的同等 yum 命令為:

        sudo dnf upgrade --security --bugfix
  8. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

RHEL

在 Red Hat Enterprise Linux 受管節點上,修補程式安裝工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單,系統會安裝列出的修補程式,並略過步驟 2-7。

  2. 套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  3. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除,將會套用隱含規則,以僅選擇安全儲存庫中包含升級的套件。對於每個套件,套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新,則也會考慮來自其他儲存庫的修補程式。

  4. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  5. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  6. 如果核准修補程式的多個版本,將會套用最新版本。

  7. YUM 更新 API (在 RHEL 7 上) 或 DNF 更新 API (在 RHEL 8 上) 會套用至已核准的修補程式,如下所示:

    • 若 AWS 提供的預先定義預設修補基準,以及 Approved patches include non-security updates (包含非安全性更新的已核准修補程式) 的自訂修補基準核取方塊未選取,則只會套用 updateinfo.xml 中指定的修補程式 (僅限安全性更新)。

      對於 RHEL 7,此工作流程的同等 yum 命令為:

      sudo yum update-minimal --sec-severity=critical,important --bugfix -y

      對於 RHEL 8,此工作流程的對等 dnf 命令為:

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \ sudo dnf update-minimal --sec-severity=Important --bugfix -y
    • 對於選取 Approved patches include non-security updates (已核准修補程式包含非安全性更新) 核取方塊的修補基準,位於 updateinfo.xml 中的修補程式和不位於 updateinfo.xml 中的修補程式皆會套用 (安全性和非安全性更新)。

      對於 RHEL 7,此工作流程的同等 yum 命令為:

      sudo yum update --security --bugfix -y

      對於 RHEL 8,此工作流程的同等 yum 命令為:

      sudo dnf update --security --bugfix -y
  8. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

SLES

在 SUSE Linux Enterprise Server (SLES) 受管節點上,修補程式安裝工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單,系統會安裝列出的修補程式,並略過步驟 2-7。

  2. 套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  3. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除,將會套用隱含規則,以僅選擇安全儲存庫中包含升級的套件。對於每個套件,套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新,則也會考慮來自其他儲存庫的修補程式。

  4. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  5. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  6. 如果核准修補程式的多個版本,將會套用最新版本。

  7. Zypper 更新 API 將套用至核准的修補程式。

  8. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

Ubuntu Server

在 Ubuntu Server 受管節點上,修補程式安裝工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單,系統會安裝列出的修補程式,並略過步驟 2-7。

  2. 若有可用於 python3-apt (libapt 的 Python 程式庫界面) 的更新,它會升級到最新版本。(這個非安全性套件會升級,即使您未選取 Include nonsecurity updates (包含非安全性更新) 選項)。

  3. 套用修補基準中指定的 GlobalFilters,以便僅進一步處理合格的套件。

  4. 套用修補基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    注意

    因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期,此作業系統不支援自動核准選項。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除,將會套用隱含規則,以僅選擇安全儲存庫中包含升級的套件。對於每個套件,套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新,則也會考慮來自其他儲存庫的修補程式。

    然而,核准規則也受限於建立或最後更新修補基準時,是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    注意

    對於 Ubuntu Server,修補候選版本僅限於 trusty-security (Ubuntu Server 14.04 LTS)、xenial-security (Ubuntu Server 16.04 LTS)、bionic-security (Ubuntu Server 18.04 LTS)、focal-security (Ubuntu 伺服器 20.04 LTS) 或 groovy-gorilla (Ubuntu Server 20.10 STR) 中包含的修補程式。

  5. 套用修補基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准,仍將會核准用於更新。

  6. 套用修補基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除,而且將不會套用。

  7. APT 程式庫用於升級套件。

  8. 如有安裝任何更新,受管節點將會重新啟動。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)

Windows

在 Windows Server 受管節點上執行修補操作時,節點會從 Systems Manager 請求適當修補基準的快照。此快照包含已核准部署之修補基準中所有可用更新的清單。此更新清單會傳送至 Windows Update API,決定哪些更新適用於受管節點並視需要安裝這些更新。如有安裝任何更新,受管節點將會重新啟動,重新啟動的次數依據完成所有必要修補的需要而定。(例外:如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。) 在 Run Command 請求的輸出中,可以找到修補操作的摘要。在 %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs 資料夾的受管節點上,可以找到額外的日誌。

由於 Windows Update API 用於下載和安裝修補程式,因此會遵守適用於 Windows Update 的所有群組政策設定。使用 Patch Manager 無需任何群組政策設定,但您已定義的所有設定都將會套用,例如將受管節點導向至 Windows Server Update Services (WSUS) 伺服器。

注意

根據預設,Windows 會下載來自 Microsoft 的 Windows Update 網站的所有修補程式,因為 Patch Manager 使用 Windows Update API 來推動下載和安裝修補程式。因此,受管節點必須能夠連接至 Microsoft Windows Update 網站,否則修補將會失敗。或者,您可以設定 WSUS 伺服器做為修補程式儲存庫,並設定您的受管節點以 WSUS 伺服器為目標使用群組政策。