預先定義和自訂修補程式基準 - AWS Systems Manager
預先定義的基準自訂基準

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

預先定義和自訂修補程式基準

Patch Manager是 的功能 AWS Systems Manager，為 支援的每個作業系統提供預先定義的修補程式基準 Patch Manager。 您可以使用目前設定的這些基準 （您無法自訂），也可以建立自己的自訂修補基準。自訂修補基準可讓您進一步控制為您的環境核准或拒絕哪些修補程式。此外，預先定義的基準會將 Unspecified 的合規層級指派給使用這些基準安裝的所有修補程式。針對要指派的合規值，您可以建立預先定義基準的複本，並指定要指派給修補程式的合規值。如需詳細資訊，請參閱 自訂基準 和 使用自訂修補基準。

注意

無論您使用哪種方法或組態類型進行修補操作，此主題中的資訊都適用：

  • 在 中設定的修補程式政策 Quick Setup

  • 在 中設定的主機管理選項 Quick Setup

  • 用來執行修補程式 Scan 或 Install 任務的維護時段

  • 隨需 Patch now (立即修補) 操作

預先定義的基準

下表說明隨 提供的預先定義修補程式基準 Patch Manager.

如需每個作業系統哪些版本的相關資訊 Patch Manager 支援，請參閱 Patch Manager 先決條件。

名稱 支援的作業系統 詳細資訊

AWS-AlmaLinuxDefaultPatchBaseline

AlmaLinux

核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹

AWS-AmazonLinuxDefaultPatchBaseline

Amazon Linux 1

核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時自動核准所有被歸類為「Bugfix」的修補程式。在發行或更新 7 天後，修補程式將自動核准。¹
AWS-AmazonLinux2DefaultPatchBaseline Amazon Linux 2 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准所有被歸類為「Bugfix」的修補程式。在發行後 7 日，修補程式將自動核准。¹
AWS-AmazonLinux2022DefaultPatchBaseline Amazon Linux 2022

核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。在發佈後七日，修補程式將自動核准。同時在修補程式發布七天之後，核准被歸類「Bugfix」的所有修補程式。
AWS-AmazonLinux2023DefaultPatchBaseline Amazon Linux 2023

核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。在發佈後七日，修補程式將自動核准。同時在修補程式發布七天之後，核准被歸類「Bugfix」的所有修補程式。
AWS-CentOSDefaultPatchBaseline CentOS 和 CentOS Stream 在更新可用 7 天之後核准所有更新，包括非安全性更新。
AWS-DebianDefaultPatchBaseline Debian Server 立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。
AWS-MacOSDefaultPatchBaseline macOS 核准所有被歸類為「安全」的作業系統修補程式。同時核准包含目前更新的所有套件。
AWS-OracleLinuxDefaultPatchBaseline Oracle Linux 核准所有被歸類為「安全性」以及嚴重性等級為「重要」或「中等」的作業系統修補程式。同時在修補程式發行 7 天之後，核准被歸類為 "Bugfix" 的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹
AWS-DefaultRaspbianPatchBaseline Raspberry Pi OS 立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。

AWS-RedHatDefaultPatchBaseline

Red Hat Enterprise Linux (RHEL)

核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹

AWS-RockyLinuxDefaultPatchBaseline

Rocky Linux

核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹
AWS-SuseDefaultPatchBaseline SUSE Linux Enterprise Server (SLES) 核准所有在被歸類為「安全性」以及嚴重性為「關鍵」或「重要」的作業系統修補程式。在發行或更新 7 天後，修補程式將自動核准。¹

AWS-UbuntuDefaultPatchBaseline

Ubuntu Server

立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。
AWS-DefaultPatchBaseline

Windows Server

核准全部 Windows Server 作業系統修補程式被分類為「CriticalUpdates」或「SecurityUpdates」，且其MSRC嚴重性為「重大」或「重要」。在發佈或更新 7 天後，修補程式將自動核准。²
AWS-WindowsPredefinedPatchBaseline-OS

Windows Server

核准全部 Windows Server 作業系統修補程式被分類為「CriticalUpdates」或「SecurityUpdates」，且其MSRC嚴重性為「重大」或「重要」。在發佈或更新 7 天後，修補程式將自動核准。²
AWS-WindowsPredefinedPatchBaseline-OS-Applications Windows Server 對於 Windows Server 作業系統， 會核准所有分類為 "CriticalUpdates" 或 "SecurityUpdates" 且MSRC嚴重性為 "Critical" 或 "Important" 的修補程式。對 Microsoft 發行的應用程式核准所有的修補程式。作業系統和應用程式的修補程式會在發佈或更新 7 天後自動核准。²

1 對於 Amazon Linux 1 和 Amazon Linux 2，修補程式自動核准之前的 7 天等待是從 中的Updated Date值計算updateinfo.xml，而不是Release Date值。各種因素會影響 Updated Date 值。其他作業系統會以不同的方式處理發行和更新日期。如需詳細資訊來協助您避免因自動核准延遲而導致非預期結果，請參閱套件發行日期和更新日期的計算方式。

2 對於 Windows Server，預設基準包含 7 天的自動核准延遲。若要在發佈後 7 天內安裝修補程式，必須建立自訂基準。

自訂基準

使用下列資訊協助您建立自訂修補基準，以達到修補目標。

在自訂基準中使用自動核准

如果您建立自己的修補基準，您可以使用以下類別來選擇自動核准哪些修補程式。

  • 作業系統：Windows Server、Amazon Linux、Ubuntu Server等。

  • 產品名稱 （適用於作業系統）：例如，RHEL 6.5、Amazon Linux 2014.09、Windows Server 2012 年，Windows Server 2012 R2 等。

  • 產品名稱 （適用於 Microsoft 在 上發行的應用程式 Windows Server 僅限）：例如 Word 2016、 BizTalk 伺服器等。

  • 分類 ：例如重大更新、安全更新等。

  • 嚴重性 ：例如 Critical、Messor 等。

對於您建立的每個核准規則，您可以選擇指定自動核准延遲，或指定修補程式核准截止日期。

注意

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

自動核准延遲是修補程式發行或最後更新之後，在自動核准修補程式進行修補之前的等待天數。例如，如果您使用 CriticalUpdates 分類來建立規則，並將自動核准延遲設定為 7 天，則 7 月 7 日發行的新的關鍵修補程式將在 7 月 14 日自動核准。

如果 Linux 儲存庫未提供套件的發行日期資訊，Systems Manager 會使用套件的建置時間作為 Amazon Linux 1、Amazon Linux 2、RHEL、 和 CentOS 。如果系統無法找到套件的建置時間，Systems Manager 會將自動核准延遲值視為 0。

當您指定自動核准截止日期時，Patch Manager 會自動套用在該日期當天或之前發行或上次更新的所有修補程式。例如，如果您指定 2023 年 7 月 7 日作為截止日期，則不會自動安裝在 2023 年 7 月 8 日或之後發行或最後更新的修補程式。

當您建立自訂修補基準時，您可以指定此修補基準所核准之修補程式的合規嚴重性等級，例如 Critical 或 High。如果任何核准之修補程式的修補程式狀態回報為 Missing，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。

建立修補程式基準的其他資訊

建立修補基準時，請謹記下列事項：

  • Patch Manager 為每個支援的作業系統提供一個預先定義的修補程式基準。除非您建立自己的修補基準，並將其指定為相應作業系統類型的預設基準，否則這些預先定義的修補基準會用於每種作業系統類型的預設修補基準。

    注意

    用於 Windows Server，提供了三個預先定義的修補程式基準。修補程式基準AWS-DefaultPatchBaseline和 僅AWS-WindowsPredefinedPatchBaseline-OS支援 Windows 作業系統本身的作業系統更新。 AWS-DefaultPatchBaseline 會用作 的預設修補程式基準 Windows Server 受管節點，除非您指定不同的修補程式基準。這兩個修補基準中的組態設定是相同的。兩者的較新版本 AWS-WindowsPredefinedPatchBaseline-OS已建立，以將其與 的第三個預先定義修補程式基準區分開 Windows Server。 該修補程式基準 AWS-WindowsPredefinedPatchBaseline-OS-Applications可用來將修補程式套用至 Windows Server 作業系統和 Microsoft 發行的支援應用程式。

  • 根據預設，Windows Server 2019 年和 Windows Server 2022 會移除由稍後更新取代的更新。因此，如果您在 中使用 ApproveUntilDate 參數 Windows Server 修補程式基準，但ApproveUntilDate參數中選取的日期早於最新修補程式的日期，則修補操作執行時不會安裝新的修補程式。如需關於 Windows Server 修補規則，請參閱 Windows Server 標籤如何選取安全性修補程式。

    這表示受管節點在 Systems Manager 操作方面符合規範，即使上個月的重要修補程式可能未安裝。使用 ApproveAfterDays 參數時，可能會發生相同的情況。由於 Microsoft 取代修補程式行為，因此可以設定數字 （通常大於 30 天），以便針對 的修補程式 Windows Server 如果 Microsoft 的最新可用修補程式在 ApproveAfterDays 的天數到期之前發行，則永遠不會安裝 。

  • 對於內部部署伺服器和虛擬機器 （VMs），Patch Manager 會嘗試使用您的自訂預設修補程式基準。如果不存在自訂預設修補基準，系統將使用為對應作業系統預先定義的修補基準。

  • 如果修補程式已在相同的修補基準中同時列為核准與拒絕，修補程式將遭到拒絕。

  • 一個受管節點只能有一個為其定義的修補基準。

  • 可新增至修補基準之核准與拒絕修補程式清單的套件名稱格式，取決於您要修補之作業系統的類型。

    如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 已核准和拒絕修補程式清單的套件名稱格式。

  • 如果您在 中使用修補程式政策組態 Quick Setup，您對自訂修補程式基準所做的更新會與 同步 Quick Setup 每小時一次。

    如果刪除修補程式政策中參考的自訂修補程式基準，則 上會顯示橫幅 Quick Setup 修補政策的組態詳細資訊頁面。此橫幅會通知您修補程式政策參照修補基準不再存在，而後續的修補操作將會失敗。在這種情況下，請返回 。Quick Setup 組態頁面，選取 Patch Manager 組態 ，然後選擇動作 、編輯組態 。刪除的修補基準名稱會反白顯示，您必須為受影響的作業系統選取新的修補基準。

如需有關建立修補基準的詳細資訊，請參閱使用自訂修補基準與教學課程：使用 修補伺服器環境 AWS CLI。