• AWS Systems Manager CloudWatch 控制面板在 2026 年 4 月 30 日之后将不再可用。客户可以像现在一样继续使用 Amazon CloudWatch 控制台来查看、创建和管理其 Amazon CloudWatch 控制面板。有关更多信息，请参阅 [Amazon CloudWatch 控制面板文档](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)
+ [Microsoft 在 Windows Server 上发布的补丁应用程序](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)。
****
| 名称 | 支持的操作系统 | Details |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | 批准分类为“Security”且严重性等级为“关键”或“重要”的所有操作系统补丁。还批准分类为“Bugfix”的所有补丁。补丁将在发布或更新后 7 天自动批准。¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | 批准分类为“Security”且严重性等级为“关键”或“重要”的所有操作系统补丁。还批准分类为“缺陷修正”的所有补丁。补丁将在发布后 7 天自动批准。¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | 批准分类为“Security”且严重性等级为“关键”或“重要”的所有操作系统补丁。补丁将在发布后七天自动批准。在发布 7 天后还批准分类为“缺陷修正”的所有补丁。 |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | 在所有更新可用 7 天后批准这些更新（包括非安全性更新）。 |
| AWS-DebianDefaultPatchBaseline | Debian Server | 立即批准优先级为“Required”、“Important”、“Standard”、“Optional”或“Extra”的与操作系统安全相关的所有补丁。由于存储库中未提供可靠的发布日期，因此批准之前无需等待。 |
| AWS-MacOSDefaultPatchBaseline | macOS | 批准分类为“Security”的所有操作系统补丁。同时批准具有当前更新的所有软件包。 |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | 批准分类为“Security”且严重性等级为“重要”或“中等”的所有操作系统补丁。在发布 7 天后还批准分类为“Bugfix”的所有补丁。补丁将在发布或更新后 7 天自动批准。¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | 批准分类为“Security”且严重性等级为“关键”或“重要”的所有操作系统补丁。还批准分类为“Bugfix”的所有补丁。补丁将在发布或更新后 7 天自动批准。¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | 批准分类为“Security”且严重性等级为“关键”或“重要”的所有操作系统补丁。还批准分类为“Bugfix”的所有补丁。补丁将在发布或更新后 7 天自动批准。¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | 批准分类为“Security”且严重性为“严重”或“重要”的所有操作系统补丁。补丁将在发布或更新后 7 天自动批准。¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | 立即批准优先级为“Required”、“Important”、“Standard”、“Optional”或“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 | 对于 Windows Server 操作系统，批准分类为“CriticalUpdates”或“SecurityUpdates”且 MSRC 严重性为“严重”或“重要”的所有补丁。对于 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 Server 2012、Windows Server 2012 R2 等。
+ **产品名称**（仅对于 Windows Server 上 Microsoft 发布的应用程序）：例如，Word 2016、BizTalk 服务器等。
+ **分类**：例如，关键更新、安全更新等。
+ **严重性**：例如，关键、重要等。
对于您创建的每个批准规则，您可以选择指定自动批准延迟或指定补丁批准截止日期。
**注意**
由于无法可靠地确定 Ubuntu Server 的更新程序包的发布日期，因此此操作系统不支持自动批准选项。
自动批准延迟是发布或最后更新补丁后到自动批准补丁用于修补前等待的天数。例如，如果您使用 `CriticalUpdates` 分类创建一条规则并将其自动批准延迟配置为 7 天，则将在 7 月 14 日自动批准 7 月 7 日发布的新关键补丁。
如果 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 天），这样，如果 Microsoft 的最新可用补丁是在经过 `ApproveAfterDays` 中的天数之前发布的，则绝不会安装 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` 来定义补丁组。为补丁基准注册补丁组时，为这两个键指定的任何相同*值*都将解释为属于同一补丁组。例如，假设您使用以下第一个键值对标记了五个节点，并使用第二个键值对标记了五个节点：
+ `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` 的每个目标数组最多可以包含五个键值对。
+ 建议您只选择其中一个标签键约定，`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) 和 [将补丁组添加到补丁基准](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 用户指南》**中的[标记您的 Amazon EC2 资源](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)。
## 工作方式
当系统运行将补丁基准应用于托管式节点的任务时，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_cn/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
在本示例中，我们有三组 Windows Server EC2 实例，其应用了以下标签：
****
| EC2 实例组 | 标签 |
| --- | --- |
| 组 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| 组 2 | `key=OS,value=Windows` |
| 组 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 控制台、SDK、 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)
# Microsoft 在 Windows Server 上发布的补丁应用程序
使用本主题中的信息可帮助您准备好使用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 发布的应用程序。
**支持在本地服务器、边缘设备、VM 和其他非 EC2 节点上修补由 Microsoft 发布的应用程序**
要在虚拟机（VM）和其他非 EC2 托管式节点上修补 Microsoft 发布的应用程序，必须打开高级实例套餐。使用高级实例套餐需支付费用。**但是，修补 Microsoft 在 Amazon Elastic Compute Cloud (Amazon EC2) 实例上发布的应用程序不收取额外费用。**有关更多信息，请参阅 [配置实例套餐](fleet-manager-configure-instance-tiers.md)。
**“其他微软产品”的 Windows 更新选项**
为了让 Patch Manager 能够在 Windows Server 托管式节点上修补 Microsoft 发布的应用程序，必须在托管式节点上启用 Windows 更新选项 **Give me updates for other Microsoft products when I update Windows**（更新 Windows 时向我提供其他 Microsoft 产品的更新）。
有关在单个托管式节点上允许此选项的信息，请参阅 Microsoft 支持网站上的[使用 Microsoft 更新更新 Office](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282)。
对于运行 Windows Server 2016 及更高版本的托管式节点机群，您可以使用组策略对象 (GPO) 打开设置。在组策略管理编辑器中，转到**计算机配置**、**管理模板**、**Windows 组件**、**Windows 更新**，然后选择**安装其他 Microsoft 产品的更新**。我们还建议使用其他参数配置 GPO，以防止在 Patch Manager 之外意外自动更新和重启。有关更多信息，请参阅 Microsoft 技术文档网站上的 [Configuring Automatic Updates in a Non-Active Directory Environment](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499)（在非 Active Directory 环境中配置自动更新）。
对于运行 Windows Server 2012 或 2012 R2 的托管式节点机群，您可以使用脚本打开该选项，如 Microsoft 文档博客网站上的[通过脚本在 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 中的一项工具），通过 Systems Manager 文档（SSM 文档）`AWS-RunPowerShellScript` 在托管式节点上运行脚本，所使用的命令类似于以下内容。
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**最低参数要求**
要在自定义补丁基准中包括 Microsoft 发布的应用程序，您必须至少指定要修补的产品。下面的 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) 以获取帮助解决问题。