• 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。您可以依照目前設定的方式使用這些基準 (您無法自訂)，也可以建立自己的自訂修補基準。自訂修補基準可讓您進一步控制為您的環境核准或拒絕哪些修補程式。此外，預先定義的基準會將 `Unspecified` 的合規層級指派給使用這些基準安裝的所有修補程式。針對要指派的合規值，您可以建立預先定義基準的複本，並指定要指派給修補程式的合規值。如需詳細資訊，請參閱[自訂基準](#patch-manager-baselines-custom)及[使用自訂修補基準](patch-manager-manage-patch-baselines.md)。
**注意**
無論您使用哪種方法或組態類型進行修補操作，此主題中的資訊都適用：
在 Quick Setup 中設定的修補程式政策
在 Quick Setup 中設定的主機管理選項
用來執行修補程式 `Scan` 或 `Install` 任務的維護時段
隨需 **Patch now** (立即修補) 操作
**Topics**
+ [預先定義的基準](#patch-manager-baselines-pre-defined)
+ [自訂基準](#patch-manager-baselines-custom)
## 預先定義的基準
下表說明 Patch Manager 提供的預先定義修補基準。
如需有關 Patch Manager 支援各作業系統的哪些版本的詳細資訊，請參閱 [Patch Manager 先決條件](patch-manager-prerequisites.md)。
****
| 名稱 | 支援的作業系統 | 詳細資訊 |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准所有被歸類為「Bugfix」的修補程式。在發行後 7 日，修補程式將自動核准。¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。在發行後七日，修補程式將自動核准。同時在修補程式發布七天之後，核准被歸類「Bugfix」的所有修補程式。 |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | 在更新可用 7 天之後核准所有更新，包括非安全性更新。 |
| AWS-DebianDefaultPatchBaseline | Debian Server | 立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。 |
| AWS-MacOSDefaultPatchBaseline | macOS | 核准所有被歸類為「安全」的作業系統修補程式。同時核准包含目前更新的所有套件。 |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | 核准所有被歸類為「安全性」以及嚴重性等級為「重要」或「中等」的作業系統修補程式。同時在修補程式發行 7 天之後，核准被歸類為 "Bugfix" 的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹ |
| `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 | 核准所有被歸類為「CriticalUpdates」或「SecurityUpdates」以及 MSRC 嚴重性為「關鍵」或「重要」的 Windows Server 作業系統修補程式。在發佈或更新 7 天後，修補程式將自動核准。² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | 核准所有被歸類為「CriticalUpdates」或「SecurityUpdates」以及 MSRC 嚴重性為「關鍵」或「重要」的 Windows Server 作業系統修補程式。在發佈或更新 7 天後，修補程式將自動核准。² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | 在修補程式發佈七天之後，核准所有被歸類為「CriticalUpdates」或「SecurityUpdates」以及 MSRC 嚴重性為「關鍵」或「重要」的 Windows Server 作業系統修補程式。對 Microsoft 發行的應用程式核准所有的修補程式。作業系統和應用程式的修補程式會在發佈或更新 7 天後自動核准。² |
¹ 對於 Amazon Linux 2，修補程式自動批准前的 7 天等待時間從 `updateinfo.xml` 中的 `Updated Date` 值開始計算，而不是從 `Release Date` 值計算。各種因素會影響 `Updated Date` 值。其他作業系統會以不同的方式處理發行和更新日期。如需詳細資訊來協助您避免因自動核准延遲而導致非預期結果，請參閱[套件發行日期和更新日期的計算方式](patch-manager-release-dates.md)。
² 對於 Windows Server，預設基準包括 7 天自動核准延遲。若要在發佈後 7 天內安裝修補程式，必須建立自訂基準。
## 自訂基準
使用下列資訊，協助您建立自訂修補基準，以符合您的修補目標。
**Topics**
+ [在自訂基準中使用自動核准](#baselines-auto-approvals)
+ [建立修補基準的其他資訊](#baseline-additional-info)
### 在自訂基準中使用自動核准
如果您建立自己的修補基準，您可以使用以下類別來選擇自動核准哪些修補程式。
+ **作業系統**：Windows Server 的支援版本、Amazon Linux、Ubuntu Server 等。
+ **產品名稱 **（適用於作業系統）：例如 RHEL 7.5、Amazon Linux 2023 2023.8.20250808、Windows Server2012、Windows Server2012 R2 等。
+ **產品名稱** (僅適用於在 Windows Server 由 Microsoft 發行的應用程式)：例如，Word 2016、BizTalk Server 等。
+ **分類**：例如，重要更新、安全性更新等。
+ **嚴重性**：例如關鍵、重要等。
對於您建立的每個核准規則，您可以選擇指定自動核准延遲，或指定修補程式核准截止日期。
**注意**
因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期，此作業系統不支援自動核准選項。
自動核准延遲是修補程式發行或最後更新之後，在自動核准修補程式進行修補之前的等待天數。例如，如果您使用 `CriticalUpdates` 分類來建立規則，並將自動核准延遲設定為 7 天，則 7 月 7 日發行的新的關鍵修補程式將在 7 月 14 日自動核准。
如果 Linux 儲存庫沒有提供套件發布日期資訊，Patch Manager 會將套件的建置時間用作 Amazon Linux 2、Amazon Linux 2023 和 Red Hat Enterprise Linux (RHEL) 的自動核准日期規格的日期。如果無法判斷套件的建置時間，Patch Manager 會使用 1970 年 1 月 1 日的預設日期。這會導致 Patch Manager 繞過修補基準中設定為核准 1970 年 1 月 1 日之後的任何日期的修補程式的任何自動核准日期規格。
當您指定自動核准截止日期時，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 會移除更新，而這些更新會由稍後的更新取代。因此，如果您在 Windows Server 修補基準中使用 `ApproveUntilDate` 參數，但 `ApproveUntilDate` 參數中選取的日期早於最新修補程式的日期，則修補操作執行時不會安裝新的修補程式。如需有關 Windows Server 修補規則的詳細資訊，請參閱 [如何選取安全性修補程式](patch-manager-selecting-patches.md) 中的 Windows Server 索引標籤。
這表示即使可能未安裝上個月的關鍵修補程式，受管節點在 Systems Manager 操作方面也符合規範。使用 `ApproveAfterDays` 參數時，可能會發生相同的情況。由於 Microsoft 取代了修補程式行為，可以設定數字 (通常大於 30 天)，這樣，若在 `ApproveAfterDays` 的天數之前發行 Microsoft 最新的可用修補程式，則永遠不會安裝 Windows Server 的修補程式。
+ 僅對於 Windows Server，未經修補基準核准的可用安全性更新修補程式可以具有 `Compliant` 或 `Non-Compliant` 的合規值，如自訂修補基準中所定義。
在建立或更新修補基準時，您可以選擇要指派給可用但未經核准的安全修補程式的狀態，因為這些修補程式不符合修補基準中指定的安裝條件。例如，如果您已指定在修補程式發布後、安裝前需要等待很長的時間，則可以略過您可能想要安裝的安全修補程式。如果在指定的等待期間發布了修補程式更新，安裝修補程式的等待期間會重新開始。如果等待期間過長，可以發布多個版本的修補程式，但絕不會安裝。
您可以使用主控台建立或更新修補基準，在**可用安全性更新合規狀態**欄位中指定此選項。使用 AWS CLI 執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)或 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)命令，您可以在 `available-security-updates-compliance-status` 參數中指定此選項。
+ 對於內部部署伺服器和虛擬機器 (VM)，Patch Manager 會嘗試使用您的自訂預設修補基準。如果不存在自訂預設修補基準，系統將使用為對應作業系統預先定義的修補基準。
+ 如果修補程式已在相同的修補基準中同時列為核准與拒絕，修補程式將遭到拒絕。
+ 一個受管節點只能有一個為其定義的修補基準。
+ 可新增至修補基準之核准與拒絕修補程式清單的套件名稱格式，取決於您要修補之作業系統的類型。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 如果您在 Quick Setup 中使用[修補程式政策組態](patch-manager-policies.md)，則您對自訂修補基準所做的更新會每小時與 Quick Setup 同步一次。
如果刪除修補程式政策中參照的自訂修補基準，則修補程式政策的 Quick Setup **Configuration details** (組態詳細資訊) 頁面上會顯示橫幅。此橫幅會通知您修補程式政策參照修補基準不再存在，而後續的修補操作將會失敗。在此情況下，請返回到 Quick Setup **Configurations** (組態) 頁面，選取 Patch Manager 組態，然後選擇 **Actions** (動作)、**Edit configuration** (編輯組態)。刪除的修補基準名稱會反白顯示，您必須為受影響的作業系統選取新的修補基準。
+ 您建立具有多個 `Classification` 和 `Severity` 值的核准規則時，系統會根據修補程式的可用屬性核准修補程式。具有 `Classification` 和 `Severity` 屬性的套件將符合兩個欄位的所選基準值。僅具有 `Classification` 屬性的套件只會與選取的基準 `Classification` 值進行比對。對於沒有 `Severity` 屬性的套件，會忽略相同規則中的嚴重性要求。
如需有關建立修補基準的詳細資訊，請參閱[使用自訂修補基準](patch-manager-manage-patch-baselines.md)與[教學課程：使用 修補伺服器環境 AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)。