• 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)。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 修補基準 本節中的主題提供當您在受管節點上執行 `Scan` 或 `Install` 操作時，修補基準在 Patch Manager (AWS Systems Manager 中的工具) 中之運作方式的相關資訊。 **Topics** + [預先定義和自訂的修補基準](patch-manager-predefined-and-custom-patch-baselines.md) + [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md) + [修補程式群組](patch-manager-patch-groups.md) + [在 Windows Server 上由 Microsoft 發行的修補應用程式](patch-manager-patching-windows-applications.md) # 預先定義和自訂的修補基準 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)。 # 已核准與遭拒的修補程式清單的套件名稱格式 可新增至核准與拒絕修補程式清單的套件名稱格式，取決於您要修補之作業系統的類型。 ## 適用於 Linux 作業系統的套件名稱格式 您可為修補基準中的核准與拒絕修補程式指定的格式，依據 Linux 類型而有不同。具體來說，支援的格式取決於 Linux 作業系統類型所使用的套件管理工具。 **Topics** + [Amazon Linux 2、Amazon Linux 2023、Oracle Linux 和 Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard) + [Debian Server 和 Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu) + [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles) ### Amazon Linux 2、Amazon Linux 2023、Oracle Linux 和 Red Hat Enterprise Linux (RHEL) **套件管理工具**：YUM，Amazon Linux 2023 和 RHEL 8 除外，它使用 DNF 作為套件管理工具。 **核准的修補程式**：對於核准的修補程式，您可以指定以下任何項目： + Bugzilla ID，格式為 `1234567` (系統將僅有數字的字串處理為 Bugzilla ID。) + CVE ID，格式為 `CVE-2018-1234567` + 諮詢 ID，格式範例為 `RHSA-2017:0864` 及 `ALAS-2018-123` + 使用一個或多個可用於套件命名的元件建構的套件名稱。為了說明，對於名為 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` 的套件，元件如下所示： + `name`: `dbus` + `architecture`: `x86_64` + `epoch`: `1` + `version`: `1.12.28` + `release`: `1.amzn2023.0.1` 支援具有下列結構的套件名稱： + `name` + `name.arch` + `name-version` + `name-version-release` + `name-version-release.arch` + `version` + `version-release` + `epoch:version-release` + `name-epoch:version-release` + `name-epoch:version-release.arch` + `epoch:name-version-release.arch` + `name.arch:epoch:version-release` 一些範例： + `dbus.x86_64` + `dbus-1.12.28` + `dbus-1.12.28-1.amzn2023.0.1` + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` + 我們也支援使用上述格式之單一萬用字元的套件名稱元件，例如下列所示： + `dbus*` + `dbus-1.12.2*` + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64` **拒絕的修補程式**：對於拒絕的修補程式，您可以指定以下任何項目： + 使用一個或多個可用於套件命名的元件建構的套件名稱。為了說明，對於名為 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` 的套件，元件如下所示： + `name`: `dbus` + `architecture`; `x86_64` + `epoch`: `1` + `version`: `1.12.28` + `release`: `1.amzn2023.0.1` 支援具有下列結構的套件名稱： + `name` + `name.arch` + `name-version` + `name-version-release` + `name-version-release.arch` + `version` + `version-release` + `epoch:version-release` + `name-epoch:version-release` + `name-epoch:version-release.arch` + `epoch:name-version-release.arch` + `name.arch:epoch:version-release` 一些範例： + `dbus.x86_64` + `dbus-1.12.28` + `dbus-1.12.28-1.amzn2023.0.1` + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` + 我們也支援使用上述格式之單一萬用字元的套件名稱元件，例如下列所示： + `dbus*` + `dbus-1.12.2*` + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64` ### Debian Server 和 Ubuntu Server **套件管理工具**：APT **核准的修補程式**與**拒絕修補程式**：對於核准與拒絕的修補程式，請指定以下項目： + 套件名稱，格式為 `ExamplePkg33` **注意** 對於 Debian Server 清單和 Ubuntu Server 清單，請勿包含諸如架構或版本之類的元素。例如，您指定套件名稱 `ExamplePkg33` 將下列所有項目包含在修補程式清單中： `ExamplePkg33.x86.1` `ExamplePkg33.x86.2` `ExamplePkg33.x64.1` `ExamplePkg33.3.2.5-364.noarch` ### SUSE Linux Enterprise Server (SLES) **套件管理工具**：Zypper **核准的修補程式** 與 **拒絕修補程式**：對於核准與拒絕的修補程式清單，可指定以下任何項目： + 完整套件名稱，格式範例： + `SUSE-SLE-Example-Package-15-2023-123` + `example-pkg-2023.15.4-46.17.1.x86_64.rpm` + 套件名稱含一個萬用字元，例如： + `SUSE-SLE-Example-Package-15-2023-*` + `example-pkg-2023.15.4-46.17.1.*.rpm` ## macOS 的套件名稱格式 **支援的套件管理工具**：softwareupdate、installer、Brew、Brew Cask **核准的修補程式** 與 **拒絕修補程式**：對於核准與拒絕的修補程式清單，您可以使用以下格式指定完整套件名稱： + `XProtectPlistConfigData` + `MRTConfigData` macOS 的已核准和已拒絕修補程式清單不支援萬用字元。 ## 適用於 Windows 作業系統的套件名稱格式 對於 Windows 作業系統，請使用修補程式的 Microsoft 知識庫 ID 和 Microsoft 資訊安全佈告欄 ID，例如： ``` KB2032276,KB2124261,MS10-048 ``` # 修補程式群組 **注意** 修補程式群組不會用於基於*修補程式政策*的修補操作。如需有關使用修補程式政策的資訊，請參閱 [Quick Setup中的修補程式政策組態](patch-manager-policies.md)。 對於在 2022 年 12 月 22 日發布修補程式政策支援之前尚未使用修補程式群組的帳戶區域對，主控台中不支援修補程式群組功能。對於在此日期之前開始使用修補程式群組的帳戶區域對，修補程式群組功能仍然可用。 您可以使用*修補程式群組*，將受管節點與 Patch Manager (AWS Systems Manager 中的工具) 中的特定修補基準關聯。修補程式群組會協助您根據相關的修補基準規則，確保您部署適當的修補程式至正確的節點。修補程式群組也能協助您避免在充分測試之前即部署修補程式。例如，您可以為不同的環境建立修補程式群組 (例如，開發、測試和生產) 並將每個修補程式群組註冊到適當的修補基準。 在您執行 `AWS-RunPatchBaseline` 或其他 SSM 命令文件進行修補時，可以使用其 ID 或標籤來鎖定受管節點。然後，SSM Agent 和 Patch Manager 會根據您新增至受管節點的修補程式群組值來評估要使用的修補基準。 ## 使用標籤定義修補程式群組 您可以使用套用至[混合多雲端](operating-systems-and-machine-types.md#supported-machine-types)環境中的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體和非 EC2 節點的標籤來建立修補程式群組。請注意下列有關使用修補程式群組標籤的詳細資訊： + 必須使用套用至受管節點的標籤鍵 `Patch Group` 或 `PatchGroup` 來定義修補程式群組。為修補基準註冊修補程式群組時，為這兩個鍵指定的任何相同*值*都會解譯為相同群組的一部分。例如，假設您已使用下列鍵值對中的第 1 個來標記 5 個節點，並使用當中的第 2 個來標記 5 個節點： + `key=PatchGroup,value=DEV` + `key=Patch Group,value=DEV` 建立基準的 Patch Manager 命令會根據值 `DEV`，將這 10 個受管節點合併為單一群組。為修補程式群組建立修補基準的命令的 AWS CLI 等效命令如下： ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id pb-0c10e65780EXAMPLE \ --patch-group DEV ``` 將不同鍵的值合併為單一目標，是用於建立新修補程式群組的此 Patch Manager 命令的唯一功能，且不受其他 API 動作支援。例如，如果您使用具有相同值的 `PatchGroup` 和 `Patch Group` 鍵執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 動作，則您是鎖定了兩組完全不同的節點： ``` aws ssm send-command \ --document-name AWS-RunPatchBaseline \ --targets "Key=tag:PatchGroup,Values=DEV" ``` ``` aws ssm send-command \ --document-name AWS-RunPatchBaseline \ --targets "Key=tag:Patch Group,Values=DEV" ``` + 以標籤為基礎的目標鎖定存在限制。`SendCommand` 的每個目標陣列最多可包含 5 個鍵值對。 + 建議您僅選擇其中 1 個標籤鍵慣例，可以是 `PatchGroup` (不含空格) 或 `Patch Group` (含空格)。不過，如果您在執行個體上[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用 `PatchGroup`。 + 該金鑰區分大小寫。您可以指定任何*值*來協助您識別並鎖定該群組中的資源，例如 "web servers" 或 "US-EAST-PROD"，但鍵必須是 `Patch Group` 或 `PatchGroup`。 在您建立修補程式群組並標記受管節點之後，您可以使用修補基準註冊修補程式群組。使用修補基準註冊修補程式群組，可確保修補程式群組中的節點使用相關修補基準中定義的規則。 有關如何建立修補程式群組，以及將修補程式群組與修補基準建立關聯的詳細資訊，請參閱 [建立和管理修補程式群組](patch-manager-tag-a-patch-group.md) 和 [Add a patch group to a patch baseline](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline)(新增修補程式群組至修補基準)。 若要檢視使用 AWS Command Line Interface (AWS CLI) 建立修補基準與修補程式群組的範例，請參閱 [教學課程：使用 修補伺服器環境 AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)。如需有關 Amazon EC2 標籤的詳細資訊，請參閱《Amazon EC2 使用者指南》[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)中的 *Tag your Amazon EC2 resources*。 ## 運作方式 當系統執行將修補基準套用於受管節點的任務時，SSM Agent 會驗證是否為該節點定義了修補程式群組值。如果節點已指派給修補程式群組，則 Patch Manager 會驗證該群組註冊了哪一個修補基準。如果找到了該群組的修補基準，則 Patch Manager 會通知 SSM Agent 使用關聯的修補基準。如果節點未針對修補程式群組進行設定，則 Patch Manager 會自動通知 SSM Agent 已使用目前設定的預設修補基準。 **重要** 受管節點只能存在於一個修補程式群組中。 一個修補程式群組只能為每個作業系統類型註冊一個修補基準。 如果在執行個體上啟用 **Allow tags in instance metadata** (允許執行個體中繼資料中的標籤) 選項，則您不得將 `Patch Group` 標籤 (有空格) 套用至 Amazon EC2 執行個體。允許執行個體中繼資料中的標籤可防止標籤鍵名稱含空格。如果您[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用標籤索引鍵 `PatchGroup` (不留空格)。 **圖 1：修補操作處理流程一般範例** 下圖顯示 Systems Manager 將 Run Command 任務傳送到您的伺服器機群，以使用 Patch Manager 進行修補時執行程序的一般範例。這些程序會確定要在修補操作中使用的修補基準。(當維護時段設定為使用 Patch Manager 向修補程式傳送命令時，將使用類似的程序。) 完整程序見圖例下方的說明。 ![\[Patch Manager 工作流程，用於確定在執行修補操作時要使用的修補基準。\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/images/patch-groups-how-it-works.png) 在此範例中，我們有三個 Windows Server EC2 執行個體群組已套用以下標籤： **** | EC2 執行個體群組 | Tags (標籤) | | --- | --- | | Group 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` | | Group 2 | `key=OS,value=Windows` | | Group 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` | 在這個範例中，我們也有這兩個 Windows Server 修補基準： **** | 修補基準 ID | 預設 | 關聯的修補程式群組 | | --- | --- | --- | | `pb-0123456789abcdef0` | 是 | `Default` | | `pb-9876543210abcdef0` | 否 | `DEV` | 使用 Run Command (AWS Systems Manager 中的工具) 和 Patch Manager 掃描或安裝修補程式的一般程序如下所示： 1. **傳送命令至修補程式**：透過 Systems Manager 主控台、軟體開發套件、AWS Command Line Interface (AWS CLI)，或 AWS Tools for Windows PowerShell 以使用文件 `AWS-RunPatchBaseline` 傳送 Run Command 任務。該圖顯示了透過定位標籤 `key=OS,value=Windows` 來修補受管執行個體的 Run Command 任務。 1. **修補基準判定**：SSM Agent 會驗證套用於 EC2 執行個體的修補程式群組標籤，並查詢 Patch Manager 以取得對應的修補基準。 + **符合與修補基準關聯的修補程式群組值：** 1. 安裝在群組 1 中的 EC2 執行個體上的 SSM Agent 會接收步驟 1 中發出的命令以開始修補操作。SSM Agent 會驗證 EC2 執行個體是否已套用修補程式群組標籤值 `DEV`，並向 Patch Manager 查詢關聯的修補基準。 1. Patch Manager 會確認修補基準 `pb-9876543210abcdef0` 已關聯修補程式群組 `DEV`，並通知 SSM Agent。 1. SSM Agent 會根據在 `pb-9876543210abcdef0` 中設定的核准規則和例外狀況從 Patch Manager 擷取修補基準快照，然後繼續執行下一步驟。 + **無新增至執行個體的修補程式群組標籤：** 1. 安裝在群組 2 中 EC2 執行個體上的 SSM Agent 會接收步驟 1 中發出的命令，以開始修補操作。SSM Agent 會驗證 EC2 執行個體未套用的 `Patch Group` 或 `PatchGroup` 標籤，因此，SSM Agent 會查詢 Patch Manager 以取得預設 Windows 修補基準。 1. Patch Manager 會確認預設的 Windows Server 修補基準是 `pb-0123456789abcdef0` 並通知 SSM Agent。 1. SSM Agent 會根據在預設修補程式基線 `pb-0123456789abcdef0` 中設定的核准規則和例外狀況，從 Patch Manager 擷取修補程式基線快照，然後繼續執行下一步驟。 + **沒有符合與修補基準關聯的修補程式群組值：** 1. 安裝在群組 3 中的 EC2 執行個體上的 SSM Agent 會接收步驟 1 中發出的命令以開始修補操作。SSM Agent 會驗證 EC2 執行個體是否已套用修補程式群組標籤值 `QA`，並向 Patch Manager 查詢關聯的修補基準。 1. Patch Manager 未找到與修補程式群組 `QA` 相關聯的修補基準。 1. Patch Manager 會通知 SSM Agent 以使用預設的 Windows 修補基準 `pb-0123456789abcdef0`。 1. SSM Agent 會根據在預設修補基準 `pb-0123456789abcdef0` 中設定的核准規則和例外狀況，從 Patch Manager 擷取修補基準快照，然後繼續執行下一步驟。 1. **修補程式掃描或安裝**：在決定欲使用的適當修補基準後，SSM Agent 會根據步驟 1 中指定的作業值開始掃描或安裝修補程式。掃描或安裝的修補程式，是由 Patch Manager 提供的修補基準快照中所定義的核准規則和修補程式的例外狀況所判斷。 **詳細資訊** + [修補程式合規狀態值](patch-manager-compliance-states.md) # 在 Windows Server 上由 Microsoft 發行的修補應用程式 使用本主題中的資訊來協助您準備使用 Patch Manager ( AWS Systems Manager中的工具) 修補 Windows Server 上的應用程式。 **Microsoft 應用程式修補** 對 Windows Server 受管節點上應用程式的修補支援僅限於 Microsoft 發行的應用程式。 **注意** 在某些情況下，Microsoft 會針對未指定更新日期和時間的應用程式發行修補程式。在這些情況下，預設會提供 `01/01/1970` 的更新日期和時間。 **修補由 Microsoft 發行之應用程式的修補基準** 對於 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 電腦上更新 Microsoft 發行的應用程式。 **對於 Microsoft 在內部部署伺服器、邊緣裝置、VM 和其他非 EC2 節點上發行之應用程式的修補支援** 若要修補 Microsoft 在虛擬機器 (VM) 和其他非 EC2 受管節點上發行的應用程式，您必須開啟 advanced-instances 方案。使用 advanced-instance 方案會產生費用。**但是，修補由 Microsoft 在 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上發行的應用程式無須另外付費。**如需詳細資訊，請參閱[設定執行個體方案](fleet-manager-configure-instance-tiers.md)。 **「其他 Microsoft 產品」的 Windows 更新選項** 為了讓 Patch Manager 能夠在您的 Windows Server 受管節點上修補 Microsoft 發行的應用程式，必須在受管節點上啟用 Windows 更新選項 **Give me updates for other Microsoft products when I update Windows** (當我更新 Windows 時，為我提供其他 Microsoft 產品的更新)。 如需在單一受管節點上允許此選項的相關資訊，請參閱[使用 Microsoft Update 更新 Office](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) (位於 Microsoft Support 網站)。 針對執行 Windows Server 2016 及更新版本的受管節點機群，您可以使用群組政策物件 (GPO) 來開啟設定。在群組政策管理編輯器中，移至 **Computer Configuration** (電腦組態)、**Administrative Templates** (管理範本)、**Windows Components** (Windows 元件)、**Windows Updates** (Windows 更新)，然後選擇 **Install updates for other Microsoft products** (為其他 Microsoft 產品安裝更新)。我們還建議您使用其他參數來設定 GPO，以防止 Patch Manager 之外的計劃外自動更新和重新開機。如需詳細資訊，請參閱 Microsoft 技術文件網站上的[在非作用中目錄環境設定自動更新](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499)。 針對執行 Windows Server 2012 或 2012 R2 的受管節點機群，您可以使用指令碼來開啟選項，如 Microsoft Docs 部落格網站上的[透過指令碼啟用和停用 Windows 7 的 Microsoft 更新](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script)所述。例如，您可以執行下列操作： 1. 將部落格文章中的指令碼儲存在檔案中。 1. 將檔案上傳至 Amazon Simple Storage Service (Amazon S3) 儲存貯體或其他可存取的位置。 1. 使用 中的Run Command工具 AWS Systems Manager，透過類似以下的`AWS-RunPowerShellScript`命令，使用 Systems Manager 文件 (SSM 文件） 在受管節點上執行指令碼。 ``` Invoke-WebRequest ` -Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" ` -Outfile "C:\script.vbs" cscript c:\script.vbs ``` **最低參數要求** 若要在自定修補基準中包含 Microsoft 發行的應用程式，您至少必須指定要修補的產品。following AWS Command Line Interface (AWS CLI) 命令示範修補產品的最低需求，例如 Microsoft Office 2016。 ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "My-Windows-App-Baseline" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ #### [ Windows Server ] ``` aws ssm create-patch-baseline ^ --name "My-Windows-App-Baseline" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ 如果您指定了 Microsoft 應用程式產品系列，則您指定的每個產品都必須是所選產品系列的受支援成員。例如，若要修補產品「Active Directory Rights Management Services Client 2.0」，您必須指定其產品系列為「Active Directory」而非「Office」或「SQL Server」。下列 AWS CLI 命令示範產品系列和產品的配對。 ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "My-Windows-App-Baseline" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ #### [ Windows Server ] ``` aws ssm create-patch-baseline ^ --name "My-Windows-App-Baseline" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ **注意** 如果您收到有關不相符產品與家庭配對的錯誤訊息，請參閱 [問題：產品系列/產品配對不相符](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch)，以取得解決問題的協助。