• AWS Systems Manager CloudWatch 控制面板在 2026 年 4 月 30 日之后将不再可用。客户可以像现在一样继续使用 Amazon CloudWatch 控制台来查看、创建和管理其 Amazon CloudWatch 控制面板。有关更多信息，请参阅 [Amazon CloudWatch 控制面板文档](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。
# AWS Systems Manager Patch Manager
Patch Manager是 AWS Systems Manager 中的一项工具，可使用安全相关更新及其他类型的更新自动执行修补托管式节点的过程。
**注意**
Systems Manager 为Quick Setup（AWS Systems Manager 中的一项工具）中的*补丁策略*提供支持。建议使用补丁策略来配置修补操作。使用单一补丁策略配置，您可以为贵组织中所有区域的所有账户定义修补、仅为所选的账户和区域定义修补，或为单个账户区域对定义修补。有关更多信息，请参阅 [Quick Setup 中的补丁策略配置](patch-manager-policies.md)。
您可以使用 Patch Manager 来应用操作系统和应用程序的补丁。（在 Windows Server 上，应用程序支持仅限于更新 Microsoft 发布的应用程序。） 您可以使用 Patch Manager 在 Windows 节点上安装 Service Pack，并在 Linux 节点上执行次要版本升级。可以按操作系统类型对 Amazon Elastic Compute Cloud（Amazon EC2）实例、边缘设备或本地服务器和虚拟机（VM）的实例集进行修补。这包括多个操作系统的支持版本，如 [Patch Manager 先决条件](patch-manager-prerequisites.md)中所列。您可以扫描实例以仅查看缺失补丁的报告，也可以扫描并自动安装所有缺失的补丁。要开始使用 Patch Manager，请打开 [Systems Manager 控制台](https://console.aws.amazon.com//systems-manager/patch-manager)。在导航窗格中，请选择 **Patch Manager**。
在 Patch Manager 中提供补丁之前，AWS 不会测试这些补丁。此外，Patch Manager 不支持升级操作系统的主要版本，例如，将 Windows Server 2016 升级到 Windows Server 2019，或将 Red Hat Enterprise Linux（RHEL）7.0 升级到 RHEL 8.0。
对于报告修补程序严重性级别的基于 Linux 的操作系统类型，Patch Manager 将软件发布者报告的严重性级别用于更新通知或单个修补程序。Patch Manager 不会从第三方来源（例如[常见漏洞评分系统](https://www.first.org/cvss/) (CVSS)），或者[国家漏洞数据库](https://nvd.nist.gov/vuln) (NVD) 发布的指标中获取严重性级别。
## 我的组织如何从 Patch Manager 获益？
Patch Manager 会使用安全相关更新及其他类型的更新自动执行修补托管式节点的过程。此功能有多个重要的好处：
+ **集中控制修补**：使用补丁策略，您可以为组织中所有区域的所有账户、特定账户和区域或者单个账户区域对设置定期修补操作。
+ **灵活的修补操作**：您可以选择通过扫描实例来仅查看缺失的补丁报告，也可以扫描并自动安装所有缺失的补丁。
+ **全面的合规性报告**：扫描操作完成后，您可以查看有关哪些托管式节点的补丁安装不合规以及缺失哪些补丁的详细信息。
+ **跨平台支持**：Patch Manager 支持多种操作系统，包括各种 Linux 发行版、macOS 和 Windows Server。
+ **自定义补丁基准**：您可以通过自定义补丁基准来指定批准安装的补丁，从而定义组织的补丁合规性要求。
+ **与其他 AWS 服务集成**：Patch Manager 可与 AWS Organizations、AWS Security Hub CSPM、AWS CloudTrail 和 AWS Config 集成，从而加强管理和安全性。
+ **确定性升级**：通过提供 Amazon Linux 2023 等操作系统的多版本存储库，支持确定性升级要求。
## 谁应该使用 Patch Manager？
Patch Manager 适合以下人员使用：
+ 需要在跨托管式节点实例集保持补丁合规性的 IT 管理员
+ 需要清晰了解整个基础设施环境中补丁合规状态的运营经理
+ 需要大规模实施自动化修补解决方案的云架构师
+ 需要将补丁安装功能集成到运营工作流的 DevOps 工程师
+ 部署了多账户/多区域环境并且需要集中式补丁管理的组织
+ 任何负责维护 AWS 托管式节点、边缘设备、本地服务器和虚拟机安全状况和运行状况的人员
## Patch Manager 的主要功能是什么？
Patch Manager 具有多个重要的功能：
+ **补丁策略**：通过与 AWS Organizations 集成，使用单个策略来配置跨多个 AWS 账户和区域的修补操作。
+ **自定义补丁基准**：定义在补丁发布后几天内自动批准补丁的规则，以及已批准和已拒绝的补丁列表。
+ **多种修补方法**：根据自己的具体需求选择补丁策略、维护时段或按需“立即修补”操作。
+ **合规性报告**：生成有关补丁合规状态的详细报告，并且可将报告以 CSV 格式发送到 Amazon S3 存储桶。
+ **跨平台支持**：可跨 Windows Server、多种 Linux 发行版和 macOS 修补操作系统和应用程序。
+ **灵活计划**：使用自定义 CRON 或 Rate 表达式设置不同的扫描和补丁安装计划。
+ **生命周期挂钩**：使用 Systems Manager 文档在修补操作之前和之后运行自定义脚本。
+ **侧重安全**：默认情况下，Patch Manager 侧重于安全相关更新，而不是安装所有可用补丁。
+ **速率控制**：为修补操作配置并发和错误阈值，从而尽可能减少对运营的影响。
## Patch Manager中的合规性是什么？
AWS、操作系统 (OS) 供应商或安全咨询公司等第三方未定义 Systems Manager 实例集中托管节点的*补丁合规性*构成要素的基准测试。
相反，您可以在*补丁基准*中定义补丁合规性对于您的组织或账户中的托管节点意味着什么。补丁基准是一种配置，它指定必须在托管节点上安装哪些补丁的规则。当托管节点的所有补丁都符合您在补丁基准中指定的批准标准时，该节点即符合补丁要求。
请注意，*符合*补丁基准并不意味着托管节点一定是*安全*的。“合规”意味着补丁基准定义的*可用*且*已批准*的补丁已安装在节点上。托管节点的整体安全性由Patch Manager范围之外的许多因素决定。有关更多信息，请参阅 [AWS Systems Manager 中的安全性](security.md)。
每个补丁基准都是针对特定受支持的操作系统 (OS) 类型的配置，例如 Red Hat Enterprise Linux (RHEL)、macOS 或 Windows Server。补丁基准可以为所有受支持的操作系统版本定义修补规则，或者也可以仅限于您指定的版本（例如 RHEL 7.8 和 RHEL 9.3）。
在补丁基准中，您可以指定批准安装特定类别和严重级别的所有补丁。例如，您可以包括归类为 `Security` 的所有补丁，但排除其他补丁（例如 `Bugfix` 或 `Enhancement`）。并且，您可以包括严重性为 `Critical` 的所有补丁，但排除其他补丁（例如 `Important` 和 `Moderate`）。
您还可以通过将补丁 ID 添加到要批准或拒绝的特定补丁列表中，在补丁基准中明确定义补丁，例如 Windows Server 的 `KB2736693` 或 Amazon Linux 2023 (AL2023) 的 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`。您可以选择指定补丁可用后等待修补的特定天数。对于 Linux 和 macOS，您可以选择指定合规性外部补丁列表（安装覆盖列表），而不是补丁基准规则定义的列表。
运行修补操作时，Patch Manager会将当前应用于托管节点的补丁与应根据补丁基准中设置的规则或安装覆盖列表应用的补丁进行比较。您可以选择让 Patch Manager 只显示缺失补丁的报告（`Scan` 操作），也可以选择让 Patch Manager 自动安装它发现的托管节点中缺失的所有补丁（`Scan and install` 操作）。
**注意**
补丁合规性数据代表最近一次成功修补操作的时间点快照。每个合规性报告都包含一个捕获时间，用于标识合规性状态的计算时间。在查看合规性数据时，请考虑捕获时间以确定操作是否按预期执行。
Patch Manager提供了可用于修补操作的预定义补丁基准；但是，这些预定义的配置仅作为示例提供，而不是推荐的最佳实践。我们建议您创建自己的自定义补丁基准，以便更好地控制您的实例集的补丁合规性构成要素。
有关补丁基准的更多信息，请参阅以下主题：
+ [预定义和自定义补丁基准](patch-manager-predefined-and-custom-patch-baselines.md)
+ [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)
+ [查看 AWS 预定义补丁基准](patch-manager-view-predefined-patch-baselines.md)
+ [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)
+ [使用补丁合规性报告](patch-manager-compliance-reports.md)
## 主要组件
在开始使用Patch Manager工具之前，您应该熟悉该工具的修补操作的一些主要组件和功能。
**补丁基准**
Patch Manager 使用*补丁基准*，该基准包含用于在补丁发布几天内自动批准补丁的规则以及一系列已批准和已拒绝的补丁。运行修补操作时，Patch Manager 会将当前应用于托管节点的补丁与应根据补丁基准中设置的规则应用的补丁进行比较。您可以选择让 Patch Manager 只显示缺失补丁的报告（`Scan` 操作），也可以选择让 Patch Manager 自动安装它发现的托管节点中缺失的所有补丁（`Scan and install` 操作）。
**修补操作方法**
Patch Manager 目前提供运行 `Scan` 和 `Scan and install` 操作的四种方法：
+ **（推荐）在 Quick Setup 中配置的补丁策略**：基于与 AWS Organizations 的集成，单个补丁策略可以定义整个组织的修补计划和补丁基准（包括多个 AWS 账户 和这些账户操作所在的 AWS 区域）。补丁策略也可以仅针对组织中的某些组织单位（OU）。您可以使用单个补丁策略按不同的计划进行扫描安装。有关更多信息，请参阅[使用 Quick Setup 补丁策略为组织中的实例配置修补](quick-setup-patch-manager.md)和[Quick Setup 中的补丁策略配置](patch-manager-policies.md)。
+ **在 Quick Setup 中配置的主机管理选项**：与 AWS Organizations 的集成还支持主机管理配置，从而可以对整个组织运行修补操作。但是，此选项仅限于使用当前默认补丁基准扫描缺失的补丁并在合规性报告中提供结果。此操作方法无法安装补丁。有关更多信息，请参阅 [使用 Quick Setup 设置 Amazon EC2 主机管理](quick-setup-host-management.md)。
+ **运行补丁 `Scan` 或 `Install` 任务的维护时段**：可以在 Systems Manager 的 Maintenance Windows 工具中设置维护时段，将其配置为按照您定义的计划运行不同类型的任务。Run Command 类型任务可用于运行 `Scan` 或 `Scan and install` 任务（用于您选择的一组托管节点）。每个维护时段任务只能针对单一 AWS 账户-AWS 区域 对中的托管节点。有关更多信息，请参阅 [教程：使用控制台创建修补的维护时段](maintenance-window-tutorial-patching.md)。
+ **Patch Manager 中的按需**立即修补**操作** – 使用**立即修补**选项，可以在需要尽快修补托管式节点时，绕过计划设置。使用 **Patch now**（立即修补），您可以指定是运行 `Scan` 还是 `Scan and install` 操作，以及要在哪些托管节点上运行该操作。您还可以选择在修补操作期间将 Systems Manager 文档（SSM 文档）作为生命周期挂钩运行。每个 **Patch now**（立即修补）操作只能针对单一 AWS 账户-AWS 区域 对中的托管节点。有关更多信息，请参阅 [按需修补托管式节点](patch-manager-patch-now-on-demand.md)。
**合规性报告**
`Scan` 操作完成后，可以使用 Systems Manager 控制台查看相关信息，了解哪些托管节点不满足补丁合规性以及每个节点缺少哪些补丁。也可以生成 .csv 格式的补丁合规性报告，发送到您选择的 Amazon Simple Storage Service（Amazon S3）存储桶。您可以生成一次性报告，也可以生成定期报告。对于单个托管式节点，报告包含节点所有补丁的详细信息。对于所有托管式节点的报告，仅提供缺少多少补丁的摘要。生成报告后，您可以使用 Amazon Quick 等工具导入和分析数据。有关更多信息，请参阅 [使用补丁合规性报告](patch-manager-compliance-reports.md)。
**注意**
通过使用补丁策略生成的合规性项的执行类型为 `PatchPolicy`。补丁策略操作中未生成的合规项的执行类型为 `Command`。
**集成**
Patch Manager 与以下其他 AWS 服务 服务集成在一起：
+ **AWS Identity and Access Management（IAM）**：使用 IAM 控制哪些用户、群组和角色有权访问 Patch Manager 操作。有关更多信息，请参阅 [AWS Systems Manager 如何与 IAM 协同工作](security_iam_service-with-iam.md) 和[配置 Systems Manager 所需的实例权限](setup-instance-permissions.md)。
+ **AWS CloudTrail**：使用 CloudTrail 记录由用户、角色或群组发起的修补操作事件历史记录以供审核。有关更多信息，请参阅 [使用 AWS CloudTrail 记录 AWS Systems Manager API 调用](monitoring-cloudtrail-logs.md)。
+ **AWS Security Hub CSPM**：可将来自 Patch Manager 的补丁合规性数据发送到 AWS Security Hub CSPM。Security Hub CSPM 能让您全面了解高优先级安全警报和合规性状态。它还监控您的实例集的修补状态。有关更多信息，请参阅 [将 Patch Manager 与 AWS Security Hub CSPM 集成](patch-manager-security-hub-integration.md)。
+ **AWS Config**：在 AWS Config 中设置录制以在 Patch Manager 控制面板中查看 Amazon EC2 实例管理数据。有关更多信息，请参阅 [查看补丁程序控制面板摘要](patch-manager-view-dashboard-summaries.md)。
**Topics**
+ [我的组织如何从 Patch Manager 获益？](#how-can-patch-manager-benefit-my-organization)
+ [谁应该使用 Patch Manager？](#who-should-use-patch-manager)
+ [Patch Manager 的主要功能是什么？](#what-are-the-main-features-of-patch-manager)
+ [Patch Manager中的合规性是什么？](#patch-manager-definition-of-compliance)
+ [主要组件](#primary-components)
+ [Quick Setup 中的补丁策略配置](patch-manager-policies.md)
+ [Patch Manager 先决条件](patch-manager-prerequisites.md)
+ [Patch Manager 操作是如何工作的](patch-manager-patching-operations.md)
+ [适用于修补托管式节点的 SSM 命令文档](patch-manager-ssm-documents.md)
+ [补丁基准](patch-manager-patch-baselines.md)
+ [在 Amazon Linux 2 托管式节点上使用 Kernel Live Patching](patch-manager-kernel-live-patching.md)
+ [使用控制台处理 Patch Manager 资源和合规性](patch-manager-console.md)
+ [使用 AWS CLI 处理 Patch Manager 资源使用](patch-manager-cli-commands.md)
+ [AWS Systems Manager Patch Manager 教程](patch-manager-tutorials.md)
+ [排除 Patch Manager 问题](patch-manager-troubleshooting.md)
# Quick Setup 中的补丁策略配置
AWS 建议使用*补丁策略*为组织和 AWS 账户配置补丁。补丁政策于 2022 年 12 月在Patch Manager中推出。
补丁策略是您使用Quick Setup（AWS Systems Manager 中的一项工具）设置的一项配置。与以前配置修补的方法相比，补丁策略可以对修补操作进行更广泛、更集中的控制。补丁策略可用于 [Patch Manager 支持的所有操作系统](patch-manager-prerequisites.md#pm-prereqs)，包括支持的 Linux、macOS和 Windows Server 版本。有关创建补丁策略的说明，请参阅 [使用 Quick Setup 补丁策略为组织中的实例配置修补](quick-setup-patch-manager.md)。
## 补丁策略的主要功能
与其使用其他方法修补您的节点，不如使用补丁策略来利用以下主要功能：
+ **单一设置**：若使用维护时段或 State Manager 关联设置修补操作，可能需要在 Systems Manager 控制台的不同部分执行多项任务。使用补丁策略，可以在单个向导中设置所有修补操作。
+ **多账户/多区域支持**：使用 Patch Manager 中的维护时段、State Manager关联或 **Patch now**（立即修补）功能，您只能针对一个 AWS 账户 与 AWS 区域 对中的托管节点。如果您使用多个账户和多个区域，则设置和维护任务可能需要大量时间，因为您必须在每个账户—区域对中执行设置任务。但是，如果您使用 AWS Organizations，则可以在您的所有 AWS 账户 的所有 AWS 区域 设置一个应用于所有托管节点的补丁策略。或者，您也可以选择把补丁策略只应用于您选择的账户和区域中的某些组织单位 (OU)。还可以选择把补丁策略应用于单个本地账户。
+ **组织层面的安装支持**：Quick Setup 中的现有主机管理配置选项支持对托管节点进行每日扫描，以确定是否满足补丁合规性。但是，要在预定时间完成此扫描，且只生成补丁合规信息。不执行补丁安装。使用补丁策略，您可以指定不同的扫描和安装计划。您还可使用自定义的 CRON 或 Rate 表达式来选择这些操作的频率和时间。例如，您可以每天扫描缺失的补丁，以便为您提供定期更新的合规信息。但是，为了避免不必要的停机，您的安装计划可能仅为每周一次。
+ **简化的补丁基准选择**：补丁策略仍包含补丁基准，补丁基准的配置方式不变。但是，在创建或更新补丁策略时，可以在单个列表中为每种操作系统（OS）类型选择要使用的 AWS 托管或自定义基准。无需在单独的任务中为每种操作系统类型指定默认基准。
**注意**
在运行基于补丁策略的修补操作时，他们使用的是 `AWS-RunPatchBaseline` SSM 文档。有关更多信息，请参阅 [用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
**相关信息**
[使用 Systems Manager Quick Setup 在整个 AWS 组织中集中部署修补操作](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/)（AWS 云运营和迁移博客）
## 与补丁策略的其他区别
相比以前配置修补的方法，使用补丁策略时需要注意一些其他差异：
+ **无需补丁组**：在以前的修补操作中，您可以将多个节点标记为属于一个补丁组，然后指定用于该补丁组的补丁基准。如果没有定义补丁组，Patch Manager 使用操作系统类型当前默认的补丁基准修补实例。使用补丁策略则不再需要设置和维护补丁组。
**注意**
对于在 2022 年 12 月 22 日发布补丁策略支持之前尚未使用补丁组的账户-区域对，控制台不支持补丁组功能。补丁组功能在此日期之前开始使用补丁组的账户区域对中仍然可用。
+ **已删除“配置修补”页面**：在补丁策略发布之前，您可以在 **Configure patching**（配置修补）页面上指定要修补哪些节点的默认值、修补计划和修补操作。此页面已从 Patch Manager 中删除。现在已在补丁策略中指定这些选项。
+ **不支持“立即修补”**：按需修补节点的能力仍然仅限于每次一个 AWS 账户 - AWS 区域 对。有关信息，请参阅[按需修补托管式节点](patch-manager-patch-now-on-demand.md)。
+ **补丁策略和合规信息**：在根据修补策略配置扫描托管节点是否合规时，系统将为您提供合规数据。您可以像使用其他合规性扫描方法一样查看并处理数据。尽管您可以为整个组织或多个组织单位设置补丁策略，但会单独报告每个 AWS 账户 - AWS 区域 对的合规信息。有关更多信息，请参阅 [使用补丁合规性报告](patch-manager-compliance-reports.md)。
+ **关联合规性状态和补丁策略** – Quick Setup 补丁策略下的托管式节点的修补状态与该节点的 State Manager 关联执行状态相匹配。如果关联执行状态为 `Compliant`，则还会将托管式节点的修补状态标记为 `Compliant`。如果关联执行状态为 `Non-Compliant`，则还会将托管式节点的修补状态标记为 `Non-Compliant`。
## 补丁策略支持的 AWS 区域
以下区域当前支持 Quick Setup 中的补丁策略配置：
+ 美国东部（俄亥俄州）(us-east-2)
+ 美国东部（弗吉尼亚州北部）(us-east-1)
+ 美国西部（北加利福尼亚）(us-west-1)
+ 美国西部（俄勒冈州）(us-west-2)
+ 亚太地区（孟买）(ap-south-1)
+ 亚太地区（首尔）(ap-northeast-2)
+ 亚太地区（新加坡）(ap-southeast-1)
+ 亚太地区（悉尼）(ap-southeast-2)
+ 亚太地区（东京）(ap-northeast-1)
+ 加拿大（中部）(ca-central-1)
+ 欧洲地区（法兰克福）(eu-central-1)
+ 欧洲地区（爱尔兰）(eu-west-1)
+ 欧洲地区（伦敦）(eu-west-2)
+ 欧洲地区（巴黎）（eu-west-3）
+ 欧洲地区（斯德哥尔摩）(eu-north-1)
+ 南美洲（圣保罗）（sa-east-1）
# Patch Manager 先决条件
使用Patch Manager（AWS Systems Manager 中的一项工具）之前，请确保自己已满足必要的先决条件。
**Topics**
+ [SSM Agent 版本](#agent-versions)
+ [Python 版本](#python-version)
+ [其他程序包要求](#additional-package-requirements)
+ [与补丁源的连接](#source-connectivity)
+ [S3 端点访问](#s3-endpoint-access)
+ [在本地安装补丁的权限](#local-installation-permissions)
+ [Patch Manager 支持的操作系统](#supported-os)
## SSM Agent 版本
SSM Agent 版本 2.0.834.0 或更高版本在要用 Patch Manager 管理的托管式节点上运行。
**注意**
如果有新工具添加至 Systems Manager 或者对现有工具进行了更新，则将发布 SSM Agent 的更新版本。无法使用代理的最新版本可能会阻止托管式节点使用 Systems Manager 的各项工具和功能。因此，我们建议您自动完成确保机器上的 SSM Agent 为最新的过程。有关更多信息，请参阅 [自动更新到 SSM Agent](ssm-agent-automatic-updates.md)。要获得有关 SSM Agent 更新的通知，请在 GitHub 上订阅 [SSM Agent 发布说明](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)页面。
## Python 版本
对于 macOS 以及大多数 Linux 操作系统（OS），Patch Manager 目前支持 Python 版本 2.6 - 3.12。AlmaLinux、Debian Server 和 Ubuntu Server 操作系统需要使用受支持版本的 Python 3（3.0 - 3.12）。
## 其他程序包要求
对于基于 DNF 的操作系统，可能需要使用 `zstd`、`xz` 和 `unzip` 实用程序来解压缩存储库信息和补丁文件。基于 DNF 的操作系统包括 Amazon Linux 2023、Red Hat Enterprise Linux 8 及更高版本、Oracle Linux 8 及更高版本、Rocky Linux、AlmaLinux 以及 CentOS 8 及更高版本。如果您看到类似于 `No such file or directory: b'zstd'`、`No such file or directory: b'unxz'` 的错误或由于缺失 `unzip` 而导致修补失败，则需要安装这些实用程序。`zstd`、`xz` 和 `unzip` 可以通过运行以下命令进行安装：
```
dnf install zstd xz unzip
```
## 与补丁源的连接
如果您的托管式节点没有直接连接到互联网，并且您正在通过某个 VPC 端点使用 Amazon Virtual Private Cloud（Amazon VPC），则必须确保这些节点能够访问源补丁存储库（存储库）。在 Linux 节点上，通常是从节点上配置的远程存储库下载补丁更新。因此，节点必须能够连接到远程存储库，才能执行修补。有关更多信息，请参阅 [如何选择安全性补丁](patch-manager-selecting-patches.md)。
在仅支持 IPv6 的环境中运行的节点上进行修补时，请确保该节点与补丁源有连接。您可以检查修补执行的 Run Command 输出，以检查有关无法访问的存储库的警告。对于基于 DNF 的操作系统，如果 `/etc/dnf/dnf.conf` 下的 `skip_if_unavailable` 选项设置为 `True`，则可以配置在修补期间跳过不可用的存储库。基于 DNF 的操作系统包括 Amazon Linux 2023、Red Hat Enterprise Linux 8 及更高版本、Oracle Linux 8 及更高版本、Rocky Linux、AlmaLinux 以及 CentOS 8 及更高版本。在 Amazon Linux 2023 上，`skip_if_unavailable` 选项默认设置为 `True`。
**CentOS Stream：启用 `EnableNonSecurity` 标志**
CentOS Stream 节点将 DNF 用作软件包管理器，其使用更新通知概念。更新通知只是修复特定问题的软件包的集合。
但是，CentOS Stream 默认存储库不配置更新通知。这意味着 Patch Manager 不检测默认 CentOS Stream 存储库上的软件包。要允许 Patch Manager 处理更新通知中未包含的软件包，您必须启用补丁基准规则中的 `EnableNonSecurity` 标记。
**Windows Server：确保连接到 Windows 更新目录或 Windows 服务器更新服务（WSUS）**
Windows Server 托管式节点必须能够连接到 Windows 更新目录或 Windows Server Update Service (WSUS)。确认您的节点通过互联网网关、NAT 网关或 NAT 实例已经连接到 [Microsoft 更新目录](https://www.catalog.update.microsoft.com/home.aspx)。如果您使用的是 WSUS，请确认该节点已连接到环境中的 WSUS 服务器。有关更多信息，请参阅 [问题：托管式节点无法访问 Windows 更新目录或 WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access)。
## S3 端点访问
无论托管式节点是在私有网络还是公有网络中运行，如果无法访问所需的 AWS 托管式 Amazon Simple Storage Service（Amazon S3）存储桶，则修补操作会失败。有关托管式节点必须能够访问的 S3 存储桶的信息，请参阅 [SSM Agent 与 AWS 托管 S3 存储桶进行通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 和 [使用适用于 Systems Manager 的 VPC 端点提高 EC2 实例的安全性](setup-create-vpc.md)。
## 在本地安装补丁的权限
在 Windows Server 和 Linux 操作系统上，Patch Manager分别假定使用管理员和根用户账户来安装补丁。
然而，在 macOS 上，对于 Brew 和 Brew Cask，Homebrew 不支持在根用户账户下运行其命令。因此，Patch Manager 以 Homebrew 目录的所有者或属于 Homebrew 目录的所有者组的有效用户身份查询并运行 Homebrew 命令。因此，为了安装补丁，`homebrew` 目录的所有者还需要 `/usr/local` 目录的递归所有者权限。
**提示**
以下命令可为指定的用户提供此权限：
```
sudo chown -R $USER:admin /usr/local
```
## Patch Manager 支持的操作系统
Patch Manager 工具可能不支持其他 Systems Manager 工具支持的所有相同的操作系统版本。（有关 Systems Manager 所支持的操作系统的完整列表，请参阅 [Systems Manager 支持的操作系统](operating-systems-and-machine-types.md#prereqs-operating-systems)。） 因此，请确保要使用 Patch Manager 的托管式节点在下表所列操作系统之一中运行。
**注意**
Patch Manager 依靠在托管式节点上配置的补丁存储库（例如 Windows 的 Windows 更新目录和 Windows Server Update Services）来检索要安装的可用补丁。因此，对于生命周期终止（EOL）操作系统版本，如果没有新的更新可用，则 Patch Manager 可能无法报告新的更新。这可能是因为 Linux 发行版维护者、Microsoft 或 Apple 没有发布任何新更新，或者因为托管式节点没有访问新更新的适当许可。
强烈建议避免使用生命周期 (EOL) 已终止的操作系统版本。包括 AWS 在内的操作系统供应商通常不为生命周期已终止的版本提供安全补丁或其他更新。继续使用生命周期终止的操作系统会大大增加无法应用升级（包括安全修复）以及其他操作问题的风险。AWS 不会在生命周期已终止的操作系统版本上测试 Systems Manager 功能。
Patch Manager 报告托管式节点上可用补丁的合规性状态。因此，如果实例运行的是 EOL 操作系统，但没有可用的更新，则 Patch Manager 可能会将该节点报告为“合规”，具体取决于为修补操作配置的补丁基准。
| 操作系统 | Details |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS 仅支持 Amazon EC2 实例。* 13.0–13.7（Ventura） 14*.x* (Sonoma) 15*.x* (Sequoia) macOS 操作系统更新 Patch Manager 不支持 macOS 操作系统（OS）更新或升级，例如从 13.1 到 13.2。要在 macOS 上执行操作系统版本更新，我们建议使用 Apple 的内置操作系统升级机制。有关更多信息，请参阅 Apple Developer 文档网站上的 [Device Management](https://developer.apple.com/documentation/devicemanagement)。 Homebrew 支持 Patch Manager 要求将开源软件包管理系统 Homebrew 安装在以下任一默认安装位置： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-prerequisites.html) 如果未安装 Homebrew，则使用 Patch Manager 执行的修补操作将无法正常运行。 区域支持 并非所有 AWS 区域 都支持 macOS。有关对适用于 macOS 的 Amazon EC2 支持的一般信息，请参阅《Amazon EC2 用户指南》**中的 [Amazon EC2 Mac 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)。 macOS 边缘设备 macOS 不支持适用于 AWS IoT Greengrass 核心设备的 SSM Agent。您不能使用 Patch Manager 修补 macOS 边缘设备。 |
| Windows | Windows Server 2012 至 Windows Server 2025，包括 R2 版本。 Windows 10 不支持适用于 AWS IoT Greengrass 核心设备的 SSM Agent。您不能使用 Patch Manager 修补 Windows 10 边缘设备。 Windows Server 2012 和 2012 R2 支持 Windows Server 2012 和 2012 R2 支持已于 2023 年 10 月 10 日结束。要将 Patch Manager 与这些版本一起使用，还建议使用 Microsoft 的扩展安全更新（ESU）。有关更多信息，请参阅 Microsoft 网站上的 [Windows Server 2012 和 2012 R2 即将终止支持](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support)。 |
# Patch Manager 操作是如何工作的
本节介绍一些技术细节，说明Patch Manager（AWS Systems Manager 中的一项工具）如何确定安装哪些补丁，以及如何在每个受支持的操作系统上安装这些补丁。对于 Linux 操作系统，其还提供有关在自定义补丁基准中为补丁指定源存储库（而非托管式节点上配置的默认源存储库）的信息。此节还提供了有关补丁基准规则在不同的 Linux 操作系统分发版上的工作原理的详细信息。
**注意**
无论您使用哪种配置方法或类型进行修补操作，以下主题中的信息都适用：
Quick Setup 中配置的补丁策略
Quick Setup 中配置的主机管理选项
运行补丁 `Scan` 或 `Install` 任务的维护时段
按需 **Patch now**（立即修补）操作
**Topics**
+ [如何计算软件包发布日期和更新日期](patch-manager-release-dates.md)
+ [如何选择安全性补丁](patch-manager-selecting-patches.md)
+ [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)
+ [如何安装补丁](patch-manager-installing-patches.md)
+ [补丁基准规则在基于 Linux 的系统上的工作原理](patch-manager-linux-rules.md)
+ [Linux 和 Windows Server 之间的补丁操作差异](patch-manager-windows-and-linux-differences.md)
# 如何计算软件包发布日期和更新日期
**重要**
本页面上的信息适用于 Amazon Elastic Compute Cloud（Amazon EC2）实例的 Amazon Linux 2 和 Amazon Linux 2023 操作系统（OS）。这些 OS 类型的软件包由 Amazon Web Services 创建和维护。其他操作系统的软件包和存储库的发布日期和更新日期的计算方式受其制造商管理方式的影响。对于除 Amazon Linux 2 和 Amazon Linux 2023 之外的操作系统，如 Red Hat Enterprise Linux，请参阅制造商的文档，以了解有关如何更新和维护其软件包的信息。
在您创建的[自定义补丁基准](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)设置中，对于大多数操作系统类型，您可以指定补丁在特定天数后自动批准安装。AWS 提供了几个预定义的补丁基准，其中包括 7 天的自动批准日期。
*自动批准延迟*是发布补丁后到自动批准补丁用于修补前等待的天数。例如，可以使用 `CriticalUpdates` 分类创建规则，并将其配置为自动批准延迟为 7 天。此时，发布日期或最后更新日期为 7 月 7 日的新关键补丁将在 7 月 14 日自动获得批准。
为了避免在 Amazon Linux 2 和 Amazon Linux 2023 上出现自动批准延迟的意外结果，了解其发布日期和更新日期的计算方式至关重要。
**注意**
如果 Amazon Linux 2 或 Amazon Linux 2023 存储库未提供软件包的发布日期信息，则Patch Manager会将软件包的构建时间用作自动批准日期规范的日期。如果无法确定软件包的构建时间，Patch Manager 会使用默认日期 1970 年 1 月 1 日。这将导致 Patch Manager 绕过补丁基准（配置为批准 1970 年 1 月 1 日之后任一日期发布的补丁）中的所有自动批准日期规范。
在大多数情况下，安装补丁之前的自动批准等待时间根据 `updateinfo.xml` 中的 `Updated Date` 值，而不是 `Release Date` 值计算。以下是有关这些日期计算的重要细节：
+ `Release Date` 是指*通知*发布的日期。但这并不意味着该软件包在相关存储库中可用。
+ `Update Date` 是指通知最后更新的日期。通知的更新可以指文本更新或描述更新这样的小更新。但这并不意味着该软件包在该日期发布，也不意味着在相关存储库中可用。
这意味着如果软件包的 `Update Date` 值为 7 月 7 日，可能直到（例如）7 月 13 日才能安装。假设在这种情况下，如果补丁基准指定的自动批准延迟为 7 天，则会在 7 月 14 日的 `Install` 操作中运行。因为 `Update Date` 值是运行日期前 7 天，所以软件包中的补丁和更新将在 7 月 14 日安装。即使自软件包可用于实际安装以来仅过了 1 天，安装仍会进行。
+ 包含操作系统或应用程序补丁的软件包在首次发布后可以更新多次。
+ 软件包可以发布到 AWS 托管存储库中，但如果以后发现它有问题，则可以回滚。
在某些补丁操作中，这些因素可能并不重要。例如，如果补丁基准配置为安装严重性的值为 `Low` 和 `Medium`，且分类为 `Recommended` 的补丁，则任何自动批准延迟都可能几乎不会对您的操作产生影响。
但是，如果关键或高严重性补丁的安装时间较为重要，您可能需要对补丁的安装时间进行更多的控制。执行此操作的建议方法是使用替代补丁源存储库，而不是默认存储库来执行托管节点上的补丁操作。
您可以在创建自定义补丁基准时指定备用补丁源存储库。在每个自定义补丁基准中，您可以为多达 20 个版本的受支持的 Linux 操作系统指定补丁源配置。有关更多信息，请参阅 [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。
# 如何选择安全性补丁
Patch Manager（AWS Systems Manager 中的一项工具）的主要设计意图在于在托管式节点上安装与安全性相关的操作系统更新。默认情况下，Patch Manager 并非安装所有可用的补丁，而只安装一小部分旨在提高安全性的补丁。
默认情况下，除非安装其他软件包更新需要替换，Patch Manager 不会将软件包存储库中标记为已过时软件包替换为任何具有不同名称的替换软件包。而对于更新软件包的命令，Patch Manager 仅会报告已安装但已过时的软件包并为其安装缺失的更新。这是因为替换已过时软件包通常需要卸载现有软件包并安装其替换软件包。替换已过时软件包可能会引入不在计划内的重大更改或额外功能。
这种行为与 YUM 和 DNF 的 `update-minimal` 命令一致，后者也侧重于安全更新而不是功能升级。有关更多信息，请参阅 [如何安装补丁](patch-manager-installing-patches.md)。
**注意**
当您在补丁基准规则中使用 `ApproveUntilDate` 参数或 `ApproveAfterDays` 参数时，Patch Manager会使用协调世界时 (UTC) 评估补丁发布日期。
例如，对于 `ApproveUntilDate`，如果您指定一个日期（例如 `2025-11-16`），则在 `2025-11-16T00:00:00Z` 到 `2025-11-16T23:59:59Z` 之间发布的补丁将获得批准。
请注意，托管节点上的本机软件包管理器显示的补丁发布日期可能因系统本地时区而异，但Patch Manager始终使用 UTC 时间进行审批计算。这确保了与官方安全公告网站上发布的补丁发布日期保持一致。
对于报告修补程序严重性级别的基于 Linux 的操作系统类型，Patch Manager 将软件发布商报告的严重性级别用于更新通知或单个修补程序。Patch Manager 不会从第三方来源（例如[常见漏洞评分系统](https://www.first.org/cvss/) (CVSS)），或者[国家漏洞数据库](https://nvd.nist.gov/vuln) (NVD) 发布的指标中获取严重性级别。
**注意**
在 Patch Manager 支持的所有基于 Linux 的系统中，您可以选择为托管式节点配置的不同源存储库，以便通常用于安装非安全性更新。有关信息，请参阅[如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。
请从以下选项卡中进行选择，了解 Patch Manager 如何为您的操作系统选择安全补丁。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
在 Amazon Linux 2 上处理预配置存储库的方式与在 Amazon Linux 2023 上不同。
在 Amazon Linux 2 上，Systems Manager 补丁基准服务使用托管节点上的预配置存储库。节点上通常有两个预配置存储库（存储库）：
**在 Amazon Linux 2 上**
+ **存储库 ID**：`amzn2-core/2/architecture`
**存储库名称**：`Amazon Linux 2 core repository`
+ **存储库 ID**：`amzn2extra-docker/2/architecture`
**存储库名称**：`Amazon Extras repo for docker`
**注意**
*架构*可以是 x86\$164 或（对于 Graviton 处理器）aarch64。
当您创建 Amazon Linux 2023（AL2023）实例时，它包含 AL2023 版本和您选择的特定 AMI 中可用的更新。AL2023 实例在启动时不会自动接收其他重大和重要的安全更新。相反，通过 AL2023 支持的默认开启的*版本化存储库功能进行确定性升级*，您可以根据满足您特定需求的计划应用更新。有关更多信息，请参阅《Amazon Linux 2023 User Guide》**中的 [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)。
在 AL2023 上，预配置的存储库如下所示：
+ **存储库 ID**：`amazonlinux`
**存储库名称**：Amazon Linux 2023 存储库
在 Amazon Linux 2023（预览版）上，预配置的存储库与程序包更新的*锁定版本*相关。AL2023 的新 Amazon Machine Images（AMIs）在发布后会锁定到特定版本。对于补丁更新，Patch Manager 会检索补丁更新存储库的最新锁定版本，然后根据该锁定版本的内容更新托管式节点上的程序包。
**软件包管理器**
Amazon Linux 2 托管节点使用 Yum 作为软件包管理器。Amazon Linux 2023 使用 DNF 作为软件包管理器。
两个程序包管理器都将*更新通知*概念作为名为 `updateinfo.xml` 的文件使用。更新通知只是修复特定问题的软件包的集合。Patch Manager 将更新通知中的所有软件包视为安全性软件包。单个软件包未分配分类或严重性级别。因此，Patch Manager 会向相关软件包分配更新通知属性。
**注意**
如果在**创建补丁基准**页面中选中了**包括非安全性更新**复选框，则未分配到 `updateinfo.xml` 文件中的软件包（或包含一个没有正确格式的分类、严重性和日期值的文件的软件包）可以包含在补丁的预筛选列表中。但是，为了应用补丁，补丁仍必须符合用户指定的补丁基准规则。
有关**包括非安全性更新**选项的更多信息，请参阅[如何安装补丁](patch-manager-installing-patches.md)和[补丁基准规则在基于 Linux 的系统上的工作原理](patch-manager-linux-rules.md)。
------
#### [ CentOS Stream ]
在 CentOS Stream 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。以下列表提供了虚构 CentOS 9.2 的示例 Amazon Machine Image (AMI)：
+ **存储库 ID**：`example-centos-9.2-base`
**存储库名称**：`Example CentOS-9.2 - Base`
+ **存储库 ID**：`example-centos-9.2-extras`
**存储库名称**：`Example CentOS-9.2 - Extras`
+ **存储库 ID**：`example-centos-9.2-updates`
**存储库名称**：`Example CentOS-9.2 - Updates`
+ **存储库 ID**：`example-centos-9.x-examplerepo`
**存储库名称**：`Example CentOS-9.x – Example Repo Packages`
**注意**
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
CentOS Stream 节点将 DNF 用作软件包管理器。软件包管理器使用更新通知概念。更新通知只是修复特定问题的软件包的集合。
但是，CentOS Stream 默认存储库不配置更新通知。这意味着 Patch Manager 不检测默认 CentOS Stream 存储库上的软件包。要允许 Patch Manager 处理更新通知中未包含的软件包，您必须启用补丁基准规则中的 `EnableNonSecurity` 标记。
**注意**
支持 CentOS Stream 更新通知。带有更新通知的存储库发布后即可供下载。
------
#### [ Debian 服务器 ]
在 Debian Server 上，Systems Manager 补丁基准服务使用实例上的预配置存储库（存储库）。这些预配置存储库用于提取可用软件包升级的更新列表。在这一点上，Systems Manager 的作用类似于 `sudo apt-get update` 命令。
然后，在 `debian-security codename` 存储库中筛选软件包。这就表示，在 Debian Server 的每个版本上，Patch Manager 仅识别属于该版本关联存储库一部分的升级，如下所示：
+ Debian Server 11：`debian-security bullseye`
+ Debian Server 12：`debian-security bookworm`
------
#### [ Oracle Linux ]
在 Oracle Linux 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。节点上通常有两个预配置存储库。
**Oracle Linux 7**：
+ **存储库 ID**：`ol7_UEKR5/x86_64`
**存储库名称**：`Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **存储库 ID**：`ol7_latest/x86_64`
**存储库名称**：`Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**：
+ **存储库 ID**：`ol8_baseos_latest`
**存储库名称**：`Oracle Linux 8 BaseOS Latest (x86_64)`
+ **存储库 ID**：`ol8_appstream`
**存储库名称**：`Oracle Linux 8 Application Stream (x86_64)`
+ **存储库 ID**：`ol8_UEKR6`
**存储库名称**：`Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**：
+ **存储库 ID**：`ol9_baseos_latest`
**存储库名称**：`Oracle Linux 9 BaseOS Latest (x86_64)`
+ **存储库 ID**：`ol9_appstream`
**存储库名称**：`Oracle Linux 9 Application Stream Packages(x86_64)`
+ **存储库 ID**：`ol9_UEKR7`
**存储库名称**：`Oracle Linux UEK Release 7 (x86_64)`
**注意**
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
Oracle Linux 托管式节点将 Yum 用作软件包管理器，并且 Yum 将更新通知表现为名为 `updateinfo.xml` 的文件。更新通知只是修复特定问题的软件包的集合。单个软件包未分配分类或严重性级别。出于这个原因, Patch Manager 会向相关软件包分配更新通知属性，并根据补丁基准中指定的分类筛选器安装软件包。
**注意**
如果在**创建补丁基准**页面中选中了**包括非安全性更新**复选框，则未分配到 `updateinfo.xml` 文件中的软件包（或包含一个没有正确格式的分类、严重性和日期值的文件的软件包）可以包含在补丁的预筛选列表中。但是，为了应用补丁，补丁仍必须符合用户指定的补丁基准规则。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。节点上通常有三个预配置存储库。
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
**注意**
如果在**创建补丁基准**页面中选中了**包括非安全性更新**复选框，则未分配到 `updateinfo.xml` 文件中的软件包（或包含一个没有正确格式的分类、严重性和日期值的文件的软件包）可以包含在补丁的预筛选列表中。但是，为了应用补丁，补丁仍必须符合用户指定的补丁基准规则。
Red Hat Enterprise Linux 7 托管式节点将 Yum 用作程序包管理器。AlmaLinux、Red Hat Enterprise Linux 8 和 Rocky Linux 托管式节点使用 DNF 作为程序包管理器。两个程序包管理器都将更新通知概念作为名为 `updateinfo.xml` 的文件使用。更新通知只是修复特定问题的软件包的集合。单个软件包未分配分类或严重性级别。出于这个原因, Patch Manager 会向相关软件包分配更新通知属性，并根据补丁基准中指定的分类筛选器安装软件包。
RHEL 7
以下存储库 ID 与 RHUI 2 相关联。RHUI 3 于 2019 年 12 月推出，并为 Yum 存储库 ID 引入了不同的命名方案。根据您从中创建托管式节点的 RHEL-7 AMI，您可能需要更新命令。有关更多信息，请参阅 *Red Hat 客户门户*上的 [Repository IDs for RHEL 7 in AWS Have Changed](https://access.redhat.com/articles/4599971)。
+ **存储库 ID**：`rhui-REGION-client-config-server-7/x86_64`
**存储库名称**：`Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **存储库 ID**：`rhui-REGION-rhel-server-releases/7Server/x86_64`
**存储库名称**：`Red Hat Enterprise Linux Server 7 (RPMs)`
+ **存储库 ID**：`rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**存储库名称**：`Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux、8、RHEL 8 和 Rocky Linux 8
+ **存储库 ID**：`rhel-8-appstream-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **存储库 ID**：`rhel-8-baseos-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **存储库 ID**：`rhui-client-config-server-8`
**存储库名称**：`Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9、RHEL 9 和 Rocky Linux 9
+ **存储库 ID**：`rhel-9-appstream-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **存储库 ID**：`rhel-9-baseos-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **存储库 ID**：`rhui-client-config-server-9`
**存储库名称**：`Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
在 SUSE Linux Enterprise Server (SLES) 托管式节点上，ZYPP 库从以下位置获取可用补丁的列表（软件包集合）：
+ 存储库的列表：`etc/zypp/repos.d/*`
+ 软件包信息：`/var/cache/zypp/raw/*`
SLES 托管式节点将 Zypper 用作软件包管理器，并且 Zypper 使用补丁的概念。补丁只是修复特定问题的程序包的集合。Patch Manager 处理补丁中所有引用为与安全性相关的软件包。因为没有为单个软件包提供分类或严重性，所以 Patch Manager 为软件包分配它们属于的补丁的属性。
------
#### [ Ubuntu Server ]
在 Ubuntu Server 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。这些预配置存储库用于提取可用软件包升级的更新列表。在这一点上，Systems Manager 的作用类似于 `sudo apt-get update` 命令。
然后，将从 `codename-security` 存储库筛选软件包，其中的代号对应唯一的发行版本，例如 `trusty` 适用于 Ubuntu Server 14。Patch Manager 只识别包含在这些储存库的升级：
+ Ubuntu Server 16.04 LTS：`xenial-security`
+ Ubuntu Server 18.04 LTS：`bionic-security`
+ Ubuntu Server 20.04 LTS：`focal-security`
+ Ubuntu Server 22.04 LTS：`jammy-security`
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
------
#### [ Windows Server ]
在 Microsoft Windows 操作系统上，Patch Manager 检索 Microsoft 通过其发布至 Microsoft 更新的以及 Windows Server Update Services (WSUS) 自动获取的可用更新的列表。
**注意**
Patch Manager 仅为支持 Patch Manager 的 Windows Server 操作系统版本提供可用补丁。例如，Patch Manager 不能用于修补 Windows RT。
Patch Manager 持续监控每个 AWS 区域 中的新更新。每个区域每天至少刷新一次可用更新的列表。在处理来自 Microsoft 的补丁信息时，Patch Manager 会删除已被其补丁列表中的后续更新取代的更新。因此，Patch Manager 只显示最新更新，以供您安装。例如，如果 `KB4012214` 取代了 `KB3135456`，则 `KB4012214` 会显示为 Patch Manager 的更新。
同样，Patch Manager 仅可安装在修补操作期间托管节点上可用的补丁。默认情况下，Windows Server 2019 和 Windows Server 2022 会移除由较新更新所取代的更新。因此，如果您在 Windows Server 补丁基准中使用 `ApproveUntilDate` 参数，但 `ApproveUntilDate` 参数中选择的日期*早于*最新补丁发布的日期，则会出现以下情况：
+ 取代的补丁已从节点中删除，因此无法使用 Patch Manager 进行安装。
+ 节点上存在最新的替换补丁，但尚未批准按照 `ApproveUntilDate` 参数的指定日期进行安装。
这意味着托管节点在 Systems Manager 操作方面是合规的，即使可能未安装上个月的关键补丁亦是如此。使用 `ApproveAfterDays` 参数时也可能出现同样的情况。由于 Microsoft 取代的补丁行为，可以设置一个数字（通常大于 30 天），这样，如果 Microsoft 的最新可用补丁是在经过 `ApproveAfterDays` 中的天数之前发布的，则绝不会安装 Windows Server 的补丁。请注意，如果您修改了 Windows 组策略对象（GPO）设置，以使取代的补丁在托管式节点上可用，则此系统行为不适用。
**注意**
在某些情况下，Microsoft 会为未指定更新日期和时间的应用程序发布补丁。在这些情况下，系统会默认提供 `01/01/1970` 的更新日期和时间。
------
# 如何指定备用补丁源存储库 (Linux)
当您使用托管式节点上配置的默认存储库执行修补操作时，Patch Manager（AWS Systems Manager 中的一项工具）会扫描或安装与安全性相关的补丁。这是 Patch Manager 的默认行为。有关 Patch Manager 如何选择和安装安全性补丁的完整信息，请参阅 [如何选择安全性补丁](patch-manager-selecting-patches.md)。
不过，在 Linux 系统中，您还可以使用 Patch Manager 安装与安全性无关的补丁，或安装与托管式节点上配置的默认源存储库不同的源存储库中的补丁。您可以在创建自定义补丁基准时指定备用补丁源存储库。在每个自定义补丁基准中，您可以为多达 20 个版本的受支持的 Linux 操作系统指定补丁源配置。
例如，假设您的 Ubuntu Server 实例集同时包括 Ubuntu Server 25.04 托管节点。在这种情况下，您可以在相同的自定义补丁基准中为每个版本指定备用存储库。对于每个版本，您提供名称，指定操作系统版本类型 (产品)，并提供存储库配置。您也可以指定适用于所有版本的受支持的操作系统的单个备用源存储库。
**注意**
运行为托管式节点指定备用补丁存储库的自定义补丁基准，不会使这些存储库成为操作系统中的新默认存储库。修补操作完成后，以前配置为节点操作系统的默认存储库的存储库仍为默认存储库。
有关使用此选项的示例场景的列表，请参阅本主题后面的[备用补丁源存储库的示例用法](#patch-manager-alternative-source-repository-examples)。
有关默认和自定义补丁基准的信息，请参阅 [预定义和自定义补丁基准](patch-manager-predefined-and-custom-patch-baselines.md)。
**示例：使用控制台**
要在 Systems Manager 控制台中指定备用补丁源存储库，请使用**创建补丁基准**上的**补丁来源**部分。有关使用 **Patch sources (补丁源)** 选项的信息，请参阅[创建适用于 Linux 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-linux.md)。
**示例：使用 AWS CLI**
有关将 `--sources` 选项与 AWS Command Line Interface (AWS CLI) 结合使用的示例，请参阅 [创建对不同操作系统版本使用自定义存储库的补丁基准](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources)。
**Topics**
+ [备用存储库的重要注意事项](#alt-source-repository-important)
+ [备用补丁源存储库的示例用法](#patch-manager-alternative-source-repository-examples)
## 备用存储库的重要注意事项
使用备用补丁存储库计划修补策略时，请注意以下几点：
**强制执行存储库更新验证（YUM 和 DNF）**
如果无法建立与存储库的连接，Linux 发行版上软件包管理器的默认配置可能会设置为跳过无法访问的软件包存储库。要强制执行存储库更新验证，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
**只指定用于修补的存储库**
指定备用存储库并不意味着指定*额外* 存储库。您可以选择指定除托管式节点上配置为默认存储库以外的存储库。但是，如果需要应用默认存储库更新，还必须在备用补丁源配置中指定默认存储库。
例如，在 Amazon Linux 2 托管式节点上，默认存储库为 `amzn2-core` 和 `amzn2extra-docker`。如果需要在修补操作中包括 Extra Packages for Enterprise Linux (EPEL) 存储库，您必须将所有三个存储库都指定为备用存储库。
**注意**
运行为托管式节点指定备用补丁存储库的自定义补丁基准，不会使这些存储库成为操作系统中的新默认存储库。修补操作完成后，以前配置为节点操作系统的默认存储库的存储库仍为默认存储库。
**基于 YUM 的分发版本的修补行为取决于 updateinfo.xml 清单**
为基于 YUM 的分发版本（如 Amazon Linux 2 或 Red Hat Enterprise Linux）指定备用补丁存储库时，修补行为取决于存储库是否包含一个采用正确格式的完整 `updateinfo.xml` 文件形式的更新清单。此文件指定各软件包的发行日期、分类和严重性。以下任一项都会影响修补行为：
+ 如果筛选**分类**和**严重性**，但并未在 `updateinfo.xml` 中指定它们，筛选器将不会包含此软件包。这也意味着没有 `updateinfo.xml` 文件的软件包不会包含在修补中。
+ 如果按 **ApprovalAfterDays** 筛选，但软件包的发行日期不是 Unix Epoch 格式（或未指定发行日期），筛选器将不会包含此软件包。
+ 如果您在**创建补丁基准**页面中选择了**包括非安全性更新**复选框，则存在例外。在这种情况下，没有 `updateinfo.xml` 文件（或包含此文件但 **Classification**（分类）、**Severity**（严重性）和 **Date**（日期）值格式不正确）的软件包*将*包含在补丁的预筛选列表中。（它们仍必须满足其他补丁基准规则要求才能安装。）
## 备用补丁源存储库的示例用法
**示例 1 – Ubuntu Server 的非安全性更新**
在使用 AWS 提供的预定义补丁基准 `AWS-UbuntuDefaultPatchBaseline` 的 Ubuntu Server 托管式节点机群上，您已经在使用 Patch Manager 安装安全性补丁。您可以创建基于此默认补丁基准的新补丁基准，但在批准规则中指定您也希望安装属于默认分配的与安全性无关的更新。当对节点运行此补丁基准时，将应用针对安全性和非安全性问题的补丁。您还可以选择在为基准指定的补丁异常中批准非安全性补丁。
**示例 2 – Ubuntu Server 的个人软件包存档 (PPA)**
Ubuntu Server 托管式节点正在运行通过 [Ubuntu 个人软件包归档 (PPA)](https://launchpad.net/ubuntu/+ppas) 分发的软件。在这种情况下，需创建补丁基准，用于指定已在托管式节点上配置为修补操作源存储库的 PPA 存储库。然后使用 Run Command 在节点上运行补丁基准文档。
**示例 3：受支持 Amazon Linux 版本上的企业内部应用程序**
您需要在 Amazon Linux 托管式节点上运行满足行业监管合规性要求所需的一些应用程序。您可以在节点上为这些应用程序配置存储库，使用 YUM 对这些应用程序进行初始安装，然后更新或创建新的补丁基准以包括此新企业存储库。此后，您可以使用 Run Command 运行 `AWS-RunPatchBaseline` 文档，并通过 `Scan` 选项查看企业软件包是否列在已安装软件包中以及在托管式节点上是否为最新。如果它不是最新的，可以使用 `Install` 选项再次运行该文档来更新应用程序。
# 如何安装补丁
Patch Manager 是 AWS Systems Manager 中的一个工具，使用操作系统内置的软件包管理器在托管式节点上安装更新。例如，在 Amazon Linux 2023 上的 Windows Server 和 `DNF` 上使用 Windows 更新 API。补丁管理器会考虑节点上现有的软件包管理器和存储库配置，包括存储库状态、映像 URL、GPG 验证等设置以及 `skip_if_unavailable` 等选项。
Patch Manager 不会安装新软件包来替换当前安装的已过时软件包。（例外情况：新软件包是正在安装的其他软件包更新的依赖项，或者新软件包与已过时软件包同名。） 相反，Patch Manager 会报告已安装的软件包并安装可用的更新。这种方法有助于防止在用一个软件包替换另一个软件包时，可能导致的系统功能意外更改。
如果需要卸载已过时软件包并安装替换软件包，则可能需要使用自定义脚本或软件包管理器命令，而不是使用标准的 Patch Manager 操作。
请从以下选项卡中进行选择，了解 Patch Manager 如何在操作系统上安装补丁。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
在 Amazon Linux 2 和 Amazon Linux 2023 托管节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. YUM 更新 API（Amazon Linux 2）或 DNF 更新 API（Amazon Linux 2023）用于已批准的补丁，如下所示：
+ 对于 AWS 提供的预定义默认补丁基准，仅应用 `updateinfo.xml` 中指定的补丁（仅安全性更新）。这是因为未选中**包括非安全性更新**复选框。预定义的基准等同于具有以下内容的自定义基准：
+ 未选中**包括非安全性更新**复选框
+ 严重性列表为 `[Critical, Important]`
+ 分类列表为 `[Security, Bugfix]`
对于 Amazon Linux 2，此工作流程的等效 yum 命令为：
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
对于 Amazon Linux 2023，此工作流程的等效 dnf 命令为：
```
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
```
如果选中了**包括非安全性更新**复选框，则 `updateinfo.xml` 中的补丁和未在 `updateinfo.xml` 中的补丁都会应用（安全更新和非安全性更新）。
对于 Amazon Linux 2，如果基准选中了**包括非安全性更新**，并且严重性列表为 `[Critical, Important]`，分类列表为 `[Security, Bugfix]`，则等效的 yum 命令为：
```
sudo yum update --security --sec-severity=Critical,Important --bugfix -y
```
对于 Amazon Linux 2023，等效的 dnf 命令为：
```
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**注意**
如果您在 Patch Manager 之外运行这些 `yum` 或 `dnf` 命令，则会使用不同的名称安装新软件包，来替换现已过时软件包。但是，这些软件包*无法*通过等效的 Patch Manager 操作安装。
**Amazon Linux 2023 的更多修补详细信息**
支持严重性级别“无”
Amazon Linux 2023 还支持补丁严重性级别 `None`，DNF 软件包管理器可识别该严重性级别。
支持严重性级别“中”
对于 Amazon Linux 2023，补丁严重性级别 `Medium` 相当于可能在某些外部存储库中定义的 `Moderate` 严重性。如果您在补丁基准中包含 `Medium` 严重性补丁，则外部补丁中的 `Moderate` 严重性补丁也会安装在实例上。
使用 API 操作 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) 查询合规性数据时，筛选严重性级别 `Medium` 会报告严重性级别为 `Medium` 和 `Moderate` 的补丁。
Amazon Linux 2023 的传递依赖项处理
对于 Amazon Linux 2023，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal --security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的**最新可用版本。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
**注意**
Linux 发行版上软件包管理器的默认配置可以设置为跳过无法访问但没有错误的软件包存储库。在这种情况下，相关的修补操作将在不安装存储库更新的情况下继续进行，并成功结束。要强制执行存储库更新，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ CentOS Stream ]
在 CentOS Stream 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 对已批准的补丁应用 CentOS Stream DNF 更新。
**注意**
对于 CentOS Stream，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal ‐‐security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的*最新可用版本*。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Debian 服务器 ]
在 Debian Server 实例上，补丁安装工作流程如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
**注意**
由于无法可靠地确定 Debian Server 更新程序包的发布日期，因此该操作系统不支持自动审批选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
**注意**
对于 Debian Server，补丁候选版本仅限于 `debian-security` 中包含的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 使用 APT 库升级软件包。
**注意**
Patch Manager 不支持使用 APT `Pin-Priority` 选项为软件包分配优先级。Patch Manager 汇总所有已启用存储库的可用更新，并选择匹配每个已安装软件包基准的最新更新。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ macOS ]
在 macOS 托管式节点上，补丁安装工作流如下：
1. `/Library/Receipts/InstallHistory.plist` 属性列表是软件的记录，已使用 `softwareupdate` 和 `installer` 软件包管理器安装和更新了这些软件。使用 `pkgutil` 命令行工具（适用于 `installer`）和 `softwareupdate` 软件包管理器，运行 CLI 命令来解析此列表。
对于 `installer`，对 CLI 命令的响应包括 `package name`、`version`、`volume`、`location` 和 `install-time` 详细信息，但只有 `package name` 和 `version` 被 Patch Manager 使用。
适用于 `softwareupdate`，对 CLI 命令的响应包括软件包名称 (`display name`)、`version` 和 `date`，但 Patch Manager 只使用软件包名称和版本。
对于 Brew 和 Brew 桶，自制软件不支持在根用户下运行的命令。因此, Patch Manager 以 Homebrew 目录的所有者或属于 Homebrew 目录的所有者组的有效用户身份查询并运行 Homebrew 命令。这些命令类似于 `softwareupdate` 和 `installer` 并通过 Python 子进程运行以收集软件包数据，并对输出进行解析以识别软件包名称和版本。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 在托管式节点上调用相应的软件包 CLI 以处理批准的补丁，如下所示：
**注意**
`installer` 缺乏检查和安装更新的功能。因此，对于 `installer`、Patch Manager 仅报告安装了哪些软件包。因此, `installer` 软件包从未作为 `Missing` 来报告。
+ 对于 AWS 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用安全性更新。
+ 对于*已*选中**包括非安全性更新**复选框的自定义补丁基准，安全性和非安全性更新都将应用。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Oracle Linux ]
在 Oracle Linux 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 在版本 7 托管式节点上，对已批准的补丁应用 YUM 更新 API，如下所示：
+ 对于 AWS 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用 `updateinfo.xml` 中指定的补丁（仅安全性更新）。
此工作流的等效 yum 命令为：
```
sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
```
+ 对于*已*选中**包括非安全性更新**复选框的自定义补丁基准，`updateinfo.xml` 中的补丁和未在 `updateinfo.xml` 中的补丁都将应用（安全性和非安全性更新）。
此工作流的等效 yum 命令为：
```
sudo yum update --security --bugfix -y
```
在版本 8 和 9 托管式节点上，对已批准的补丁应用 DNF 更新 API，如下所示：
+ 对于 AWS 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用 `updateinfo.xml` 中指定的补丁（仅安全性更新）。
此工作流的等效 yum 命令为：
```
sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
```
**注意**
对于 Oracle Linux，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal --security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的*最新可用版本*。
+ 对于*已*选中**包括非安全性更新**复选框的自定义补丁基准，`updateinfo.xml` 中的补丁和未在 `updateinfo.xml` 中的补丁都将应用（安全性和非安全性更新）。
此工作流的等效 yum 命令为：
```
sudo dnf upgrade --security --bugfix
```
**注意**
如果您在 Patch Manager 之外运行这些 `yum` 或 `dnf` 命令，则会使用不同的名称安装新软件包，来替换现已过时软件包。但是，这些软件包*无法*通过等效的 Patch Manager 操作安装。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
**注意**
Linux 发行版上软件包管理器的默认配置可以设置为跳过无法访问但没有错误的软件包存储库。在这种情况下，相关的修补操作将在不安装存储库更新的情况下继续进行，并成功结束。要强制执行存储库更新，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. YUM 更新 API（在 RHEL 7 上）或 DNF 更新 API（在 AlmaLinux 8 和 9、RHEL 8、9 和 10 以及 Rocky Linux 8 和 9 上）根据以下规则应用于已批准的补丁：
**场景 1：排除非安全性更新**
+ **适用对象**：AWS 提供的预定义默认补丁基准和自定义补丁基准。
+ **包括非安全性更新**复选框：*未*选中。
+ **应用的补丁**：仅当 `updateinfo.xml` 中指定的补丁（仅安全性更新）与补丁基准配置相匹配且位于所配置的存储库中时，*才会*应用这些补丁。
在某些情况下，在所配置的存储库中，`updateinfo.xml` 中指定的补丁可能不再可用。配置的存储库通常只有最新版本的补丁，这是先前所有更新的累积汇总，但是最新版本可能与补丁基准规则不匹配，因此在修补操作中会省略。
+ **命令**：对于 RHEL 7，此工作流的等效 Yum 命令为：
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
对于 AlmaLinux、RHEL 8 和 Rocky Linux，此工作流的等效 DNF 命令为：
```
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
```
**注意**
对于 AlmaLinux、RHEL 和 Rocky LinuxRocky Linux，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal --security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的*最新可用版本*。
**场景 2：包括非安全性更新**
+ **适用对象**：自定义补丁基准。
+ **包括非安全性更新**复选框：选中。
+ **应用的补丁**：`updateinfo.xml` 中的补丁*和*未在 `updateinfo.xml` 中的补丁（安全性和非安全性更新）都会应用。
+ **命令**：对于 RHEL 7，此工作流的等效 Yum 命令为：
```
sudo yum update --security --bugfix -y
```
对于 AlmaLinux 8 和 9、RHEL 8 和 9 以及 Rocky Linux 8 和 9，此工作流的等效 DNF 命令为：
```
sudo dnf update --security --bugfix -y
```
**注意**
如果您在 Patch Manager 之外运行这些 `yum` 或 `dnf` 命令，则会使用不同的名称安装新软件包，来替换现已过时软件包。但是，这些软件包*无法*通过等效的 Patch Manager 操作安装。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
**注意**
Linux 发行版上软件包管理器的默认配置可以设置为跳过无法访问但没有错误的软件包存储库。在这种情况下，相关的修补操作将在不安装存储库更新的情况下继续进行，并成功结束。要强制执行存储库更新，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ SLES ]
在 SUSE Linux Enterprise Server (SLES) 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 对已批准的补丁应用 Zypper 更新 API。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Ubuntu Server ]
在 Ubuntu Server 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
**注意**
由于无法可靠地确定 Ubuntu Server 的更新程序包的发布日期，因此此操作系统不支持自动批准选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
**注意**
对于 Ubuntu Server 的每个版本，补丁候选版本仅限于作为该版本关联存储库一部分的补丁，如下所示：
Ubuntu Server 16.04 LTS：`xenial-security`
Ubuntu Server 18.04 LTS：`bionic-security`
Ubuntu Server 20.04 LTS：`focal-security`
Ubuntu Server 22.04 LTS：`jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 使用 APT 库升级软件包。
**注意**
Patch Manager 不支持使用 APT `Pin-Priority` 选项为软件包分配优先级。Patch Manager 汇总所有已启用存储库的可用更新，并选择匹配每个已安装软件包基准的最新更新。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Windows Server ]
在 Windows Server 托管式节点上执行修补操作时，节点从 Systems Manager 请求相应补丁基准快照。此快照包含已批准部署的补丁基准中可用的所有更新的列表。系统会将更新列表发送到 Windows 更新 API，Windows 更新 API 确定哪些更新适用于托管式节点并根据需要安装更新。Windows 仅允许安装最新可用版本的 KB。当 KB 或 KB 的任何先前版本与应用的补丁基准匹配时，Patch Manager 会安装 KB 的最新版本。如果安装了任何更新，则系统会根据完成所有必要修补所需的次数重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。） 可在 Run Command 请求输出中找到修补操作摘要。其他日志可在托管式节点上的 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` 文件夹中找到。
因为使用 Windows Update API 下载和安装 KB，所以操作遵循 Windows Update 的所有组策略设置。使用 Patch Manager 时不需要任何组策略设置，但会应用已定义的所有设置，以便（例如）将托管式节点定向到 Windows Server Update Services (WSUS) 服务器。
**注意**
默认情况下，Windows 从 Microsoft 的 Windows Update 站点下载所有 KB，这是因为 Patch Manager 使用 Windows Update API 驱动 KB 的下载和安装。因此，托管式节点必须能够访问 Microsoft Windows 更新站点，否则修补将失败。或者，您也可以将 WSUS 服务器配置为 KB 存储库，然后使用组策略将托管式节点配置为将该 WSUS 服务器设为目标。
Patch Manager可能会在为 Windows Server 创建自定义补丁基准时引用 KB ID，例如基准配置中包含**已批准的补丁**列表或**已拒绝的补丁**列表时。只有在 Microsoft Windows Update 或 WSUS 服务器中分配了 KB ID 的更新才由Patch Manager安装。修补操作中不会包含缺少 KB ID 的更新。
有关创建自定义补丁基准的信息，请参阅以下主题：
[创建适用于 Windows Server 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-windows.md)
[创建补丁基准（CLI）](patch-manager-create-a-patch-baseline-for-windows.md)
[适用于 Windows 操作系统的软件包名称格式](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# 补丁基准规则在基于 Linux 的系统上的工作原理
对于 Linux 分发版，补丁基准中规则的工作方式因分发版类型的不同而有所差异。与 Windows Server 托管式节点上的补丁更新不同，将在每个节点上评估规则，以便考虑实例上配置的存储库。Patch Manager（AWS Systems Manager 中的一项工具）使用本机软件包管理器推动安装补丁基准批准的补丁。
对于报告修补程序严重性级别的基于 Linux 的操作系统类型，Patch Manager 将软件发布者报告的严重性级别用于更新通知或单个修补程序。Patch Manager 不会从第三方来源（例如[常见漏洞评分系统](https://www.first.org/cvss/) (CVSS)），或者[国家漏洞数据库](https://nvd.nist.gov/vuln) (NVD) 发布的指标中获取严重性级别。
**Topics**
+ [补丁基准规则在 Amazon Linux 2 和 Amazon Linux 2023 上的工作原理](#linux-rules-amazon-linux)
+ [补丁基准规则在 CentOS Stream 上的工作原理](#linux-rules-centos)
+ [补丁基准规则在 Debian Server 上的工作原理](#linux-rules-debian)
+ [补丁基准规则在 macOS 上的工作原理](#linux-rules-macos)
+ [补丁基准规则在 Oracle Linux 上的工作原理](#linux-rules-oracle)
+ [补丁基准规则在 AlmaLinux、RHEL 和 Rocky Linux 上的工作原理](#linux-rules-rhel)
+ [补丁基准规则在 SUSE Linux Enterprise Server 上的工作原理](#linux-rules-sles)
+ [补丁基准规则在 Ubuntu Server 上的工作原理](#linux-rules-ubuntu)
## 补丁基准规则在 Amazon Linux 2 和 Amazon Linux 2023 上的工作原理
**注意**
Amazon Linux 2023（AL2023）使用版本控制的存储库，这些存储库可以通过一个或多个系统设置锁定到特定版本。对于 AL2023 EC2 实例的所有修补操作，Patch Manager 使用最新的存储库版本，与系统配置无关。有关更多信息，请参阅《Amazon Linux 2023 User Guide》**中的 [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)。
在 Amazon Linux 2 和 Amazon Linux 2023 上，补丁选择过程如下：
1. 在托管节点上，YUM 库（Amazon Linux 2）或 DNF 库（Amazon Linux 2023）将访问每个已配置存储库的 `updateinfo.xml` 文件。
如果未找到 `updateinfo.xml` 文件，是否安装补丁将取决于**包括非安全性更新**和**自动批准**设置。例如，如果允许非安全更新，则会在自动批准时间到达时安装这些更新。
1. `updateinfo.xml` 中的每个更新通知都包含几个属性，它们表示通知中的软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 CentOS Stream 上的工作原理
CentOS Stream 默认存储库不包含 `updateinfo.xml` 文件。不过，您创建或使用的自定义存储库可能包含该文件。在本主题中，对 `updateinfo.xml` 的引用仅适用于这些自定义存储库。
在 CentOS Stream 上，补丁选择过程如下：
1. 在托管式节点上，DNF 库可访问每个已配置存储库的 `updateinfo.xml` 文件（如果该文件存在于自定义存储库中）。
如果未找到 `updateinfo.xml`（其中始终包含默认存储库），是否安装补丁将取决于**包括非安全性更新**和**自动批准**设置。例如，如果允许非安全更新，则会在自动批准时间到达时安装这些更新。
1. 如果存在 `updateinfo.xml`，该文件中的每个更新通知都包含几个属性，这些属性表示通知中软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 在所有情况下，托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 Debian Server 上的工作原理
在 Debian Server上，补丁基准服务提供对*优先级*和*部分*字段的筛选。这些字段通常存在于所有 Debian Server 软件包中。为确定补丁基准是否选择了某个补丁，Patch Manager 执行以下操作：
1. 在 Debian Server 系统上，运行等效于 `sudo apt-get update` 的程序刷新可用软件包列表。不配置存储库，从 `sources` 列表中配置的存储库提取数据。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 接下来将应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 和 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 列表。
**注意**
由于无法可靠地确定 Debian Server 更新程序包的发布日期，因此该操作系统不支持自动审批选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。在这种情况下，对于 Debian Server，补丁候选版本仅限于以下存储库中包含的补丁：
这些存储库的命名如下：
+ Debian Server 11：`debian-security bullseye`
+ Debian Server 12：`debian-security bookworm`
如果包含非安全更新，也会考虑来自其他存储库的补丁。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
要查看 *Priority* 和 *Section* 字段的内容，运行以下 `aptitude` 命令：
**注意**
您需要先在 Debian Server 系统上安装 Aptitude。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
在对此命令的响应中，按以下格式报告所有可升级软件包：
```
name, priority, section, archive, candidate version
```
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 macOS 上的工作原理
在 macOS 上，补丁选择过程如下：
1. 在托管式节点上，Patch Manager 访问 `InstallHistory.plist` 文件的已解析内容并标识软件包名称和版本。
有关解析过程的详细信息，请参阅 [如何安装补丁](patch-manager-installing-patches.md) 中的 **macOS** 选项卡。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 Oracle Linux 上的工作原理
在 Oracle Linux 上，补丁选择过程如下：
1. 在托管式节点上，YUM 库可访问每个已配置存储库的 `updateinfo.xml` 文件。
**注意**
如果存储库不是由 Oracle 管理的，则可能不存在 `updateinfo.xml` 文件。如果未找到 `updateinfo.xml`，是否安装补丁将取决于**包括非安全性更新**和**自动批准**设置。例如，如果允许非安全更新，则会在自动批准时间到达时安装这些更新。
1. `updateinfo.xml` 中的每个更新通知都包含几个属性，它们表示通知中的软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 AlmaLinux、RHEL 和 Rocky Linux 上的工作原理
在 AlmaLinux、Red Hat Enterprise Linux（RHEL）和 Rocky Linux 上，补丁选择过程如下：
1. 在托管式节点上，YUM 库 (RHEL 7) 或 DNF 库（AlmaLinux 8 和 9、RHEL 8、9 和 10 以及 Rocky Linux 8 和 9）访问每个已配置存储库的 `updateinfo.xml` 文件。
**注意**
如果存储库不是由 Red Hat 管理的，可能不存在 `updateinfo.xml` 文件。如果找不到 `updateinfo.xml`，则不会应用任何补丁。
1. `updateinfo.xml` 中的每个更新通知都包含几个属性，它们表示通知中的软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 SUSE Linux Enterprise Server 上的工作原理
在 SLES 上，每个补丁包括以下表示补丁中的软件包的属性的属性：
+ **类别**：对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中的 **Classification** 键属性的值。表示更新通知中包含的补丁的类型。
可以使用 AWS CLI 命令 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 或 API 操作 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** 来查看受支持值的列表。您也可以在 Systems Manager 控制台中**创建补丁基准**页面或**编辑补丁基准**页面中的**审批规则**区中查看列表。
+ **严重性**：对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中的**严重性**键属性的值。表示补丁的严重性。
可以使用 AWS CLI 命令 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 或 API 操作 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** 来查看受支持值的列表。您也可以在 Systems Manager 控制台中**创建补丁基准**页面或**编辑补丁基准**页面中的**审批规则**区中查看列表。
托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 **Product** 键属性的值。
对于每个补丁，补丁基准用作筛选器，只允许更新包含符合条件的软件包。如果应用补丁基准定义后有多个软件包适用，则使用最新版本。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
## 补丁基准规则在 Ubuntu Server 上的工作原理
在 Ubuntu Server上，补丁基准服务提供对*优先级*和*部分*字段的筛选。这些字段通常存在于所有 Ubuntu Server 软件包中。为确定补丁基准是否选择了某个补丁，Patch Manager 执行以下操作：
1. 在 Ubuntu Server 系统上，运行等效于 `sudo apt-get update` 的程序刷新可用软件包列表。不配置存储库，从 `sources` 列表中配置的存储库提取数据。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 接下来将应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 和 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 列表。
**注意**
由于无法可靠地确定 Ubuntu Server 的更新程序包的发布日期，因此此操作系统不支持自动批准选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。在这种情况下，对于 Ubuntu Server，补丁候选版本仅限于以下存储库中包含的补丁：
+ Ubuntu Server 16.04 LTS：`xenial-security`
+ Ubuntu Server 18.04 LTS：`bionic-security`
+ Ubuntu Server 20.04 LTS：`focal-security`
+ Ubuntu Server 22.04 LTS：`jammy-security`
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
如果包含非安全更新，也会考虑来自其他存储库的补丁。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
要查看 *Priority* 和 *Section* 字段的内容，运行以下 `aptitude` 命令：
**注意**
您需要先在 Ubuntu Server 16 系统上安装 Aptitude。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
在对此命令的响应中，按以下格式报告所有可升级软件包：
```
name, priority, section, archive, candidate version
```
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
# Linux 和 Windows Server 之间的补丁操作差异
本主题介绍Patch Manager（AWS Systems Manager 中的一项工具）中 Linux 和 Windows Server 修补之间的重要差异。
**注意**
要修补 Linux 托管式节点，节点必须运行 SSM Agent 2.0.834.0 版或更高版本。
如果有新工具添加至 Systems Manager 或者对现有工具进行了更新，则将发布 SSM Agent 的更新版本。无法使用代理的最新版本可能会阻止托管式节点使用 Systems Manager 的各项工具和功能。因此，我们建议您自动完成确保机器上的 SSM Agent 为最新的过程。有关更多信息，请参阅 [自动更新到 SSM Agent](ssm-agent-automatic-updates.md)。要获得有关 SSM Agent 更新的通知，请在 GitHub 上订阅 [SSM Agent 发布说明](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)页面。
## 区别 1：补丁评估
Patch Manager 在 Windows 托管式节点和 Linux 托管式节点上使用不同的进程，以评估应该存在的补丁。
**Linux**
对于 Linux 修补，Systems Manager 会评估补丁基准规则以及 *每个*托管式节点上已批准和已被拒绝的补丁列表。Systems Manager 必须在每个节点上评估修补，因为该服务从托管式节点上配置的存储库中检索已知补丁和更新列表。
**Windows**
对于 Windows 修补，Systems Manager *直接在服务中*评估补丁基准规则以及已批准和已拒绝的补丁列表。它可以执行此操作是因为 Windows 补丁从单个存储库 (Windows 更新) 拉取。
## 区别 2：`Not Applicable` 补丁
因为 Linux 操作系统有大量可用的软件包，所以 Systems Manager 不报告处于*不适用*状态的补丁的详细信息。例如，A `Not Applicable` 补丁是在实例未安装 Apache 时的 Apache 软件的补丁。Systems Manager 确实会在摘要中报告 `Not Applicable` 补丁的数量，但如果为某个托管式节点调用 [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API，则返回的数据中不包含状态为 `Not Applicable` 的补丁。这一行为不同于 Windows。
## 区别 3：SSM 文档支持
`AWS-ApplyPatchBaseline` Systems Manager 文档（SSM 文档）不支持 Linux 托管式节点。如需对 Linux、macOS 和 Windows Server 托管式节点应用补丁基准，则推荐的 SSM 文档是 `AWS-RunPatchBaseline`。有关更多信息，请参阅[适用于修补托管式节点的 SSM 命令文档](patch-manager-ssm-documents.md)和[用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
## 区别 4：应用程序补丁
Patch Manager 的主要目的是将补丁应用到操作系统。不过，您也可以使用 Patch Manager 将补丁应用到托管式节点上的某些应用程序。
**Linux**
在 Linux 操作系统上，Patch Manager 使用配置的存储库进行更新，不会区分操作系统补丁和应用程序补丁。您可以使用 Patch Manager 来定义从哪些存储库获取更新。有关更多信息，请参阅 [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。
**Windows**
在 Windows Server 托管式节点上，您可以为 Microsoft 发布的应用程序（如 Microsoft Word 2016 和 Microsoft Exchange Server 2016）应用已批准规则，以及*已批准*和*已被拒绝*补丁例外。有关更多信息，请参阅 [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)。
## 区别 5：自定义补丁基准中已拒绝的补丁列表选项
创建自定义补丁基准时，您可以为此**已拒绝的补丁**列表指定一个或多个补丁。对于 Linux 托管节点，如果它们是基准允许的其他补丁的依赖项，则也可以选择允许安装它们。
但是，Windows Server 不支持补丁依赖项的概念。您可以将补丁添加到 Windows Server 的自定义基准的**已拒绝的补丁**列表中，但结果取决于（1）被拒绝的补丁是否已安装在托管节点上，以及（2）您为**被拒绝的补丁操作**选择了哪个选项。
有关 Windows Server 上已拒绝的补丁选项的详细信息，请参阅下表。
| 安装状态 | 选项：“作为依赖项允许” | 选项：“语句块” |
| --- | --- | --- |
| 补丁已安装 | 报告状态：INSTALLED\$1OTHER | 报告状态：INSTALLED\$1REJECTED |
| 尚未安装补丁 | 补丁已跳过 | 补丁已跳过 |
Microsoft 发布的每个 Windows Server 补丁通常都包含成功安装所需的所有信息。但是，有时可能需要必备程序包，您必须手动安装该程序包。 Patch Manager 不报告有关这些先决条件的信息。有关相关信息，请参阅 Microsoft 网站上的 [Windows 更新问题排查](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)。
# 适用于修补托管式节点的 SSM 命令文档
本主题介绍了目前可用的九个 Systems Manager 文档（SSM 文档），有助于您保持为托管式节点提供最新的安全性相关更新补丁。
我们建议在修补操作中仅使用这些文档中的五个。结合使用这五个 SSM 文档，您即可获得使用 AWS Systems Manager 进行修补的全部选项。其中有四个文档是在四个早期 SSM 文档之后发布的，替换了这四个早期文档，对功能进行了扩展和整合。
**适用于修补的推荐 SSM 文档**
我们建议在修补操作中使用以下五个 SSM 文档。
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**适用于修补的旧版 SSM 文档**
以下四个旧版 SSM 文档在某些 AWS 区域中仍然可用，但不再更新或支持。无法保证这些文档在 IPv6 环境中有效，仅支持 IPv4。无法保证这些文档在所有情况下都有效，并且将来可能不再支持。我们建议您不要使用这些文档进行修补操作。
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
有关在仅支持 IPv6 的环境中设置修补操作的步骤，请参阅[教程：在仅支持 IPv6 的环境中修补服务器](patch-manager-server-patching-iPv6-tutorial.md)。
请参考以下各节，了解有关如何在修补操作中使用这些 SSM 文档的更多信息。
**Topics**
+ [用于修补托管式节点的推荐 SSM 文档](#patch-manager-ssm-documents-recommended)
+ [适用于修补托管式节点的旧 SSM 文档](#patch-manager-ssm-documents-legacy)
+ [适用于修补托管式节点的 SSM 文档的已知限制](#patch-manager-ssm-documents-known-limitations)
+ [用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [用于修补的 SSM 命令文档：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [用于修补的 SSM 命令文档：`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [在 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 中使用 InstallOverrideList 参数的示例场景](patch-manager-override-lists.md)
+ [使用基准覆盖参数](patch-manager-baselineoverride-parameter.md)
## 用于修补托管式节点的推荐 SSM 文档
建议在进行托管式节点的修补操作时使用以下五个 SSM 文档。
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
支持配置基本的 Windows 更新功能，并使用它们来自动安装更新 (或关闭自动更新)。在所有 AWS 区域 中可用。
此 SSM 文档可提示 Windows 更新下载并安装指定的更新，并根据需要重启托管式节点。将此文档与State Manager（AWS Systems Manager 中的一项工具）结合使用，确保 Windows Update 保持其配置。您也可以使用 Run Command（AWS Systems Manager 中的一项工具）手动运行该文档来更改 Windows Update 配置。
本文档中的可用参数支持指定要安装的更新类别 (或是否关闭自动更新)，还支持指定在星期几的什么时间运行修补操作。如果您不需要对 Windows 更新进行严格控制，也不需要收集合规性信息，则此 SSM 文档最为有用。
**替换早期 SSM 文档：**
+ *无*
### `AWS-InstallWindowsUpdates`
在 Windows Server 托管式节点上安装更新。在所有 AWS 区域 中可用。
如果您希望安装指定更新 (使用 `Include Kbs` 参数)，或希望安装特定类别或分类的补丁，但不需要补丁合规性信息，则此 SSM 文档可提供基本修补功能。
**替换早期 SSM 文档：**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
这三个早期文档执行不同的功能，但您可以使用较新的 SSM 文档 `AWS-InstallWindowsUpdates` 的不同参数设置得到同样的结果。这些参数设置在 [适用于修补托管式节点的旧 SSM 文档](#patch-manager-ssm-documents-legacy) 中进行了介绍。
### `AWS-RunPatchBaseline`
在托管式节点上安装补丁或扫描节点，以确定是否缺少任何符合条件的补丁。在所有 AWS 区域 中可用。
`AWS-RunPatchBaseline` 允许您使用指定为操作系统类型的“默认”补丁基准来控制补丁批准。报告补丁合规性信息，您可以使用 Systems Manager 合规性工具进行查看。您可使用这些工具深入了解托管式节点的补丁合规性状态，例如哪些节点缺少补丁以及缺少哪些补丁。当您使用 `AWS-RunPatchBaseline` 时，将使用 `PutInventory` API 命令记录补丁合规性信息。对于 Linux 操作系统，为来自托管式节点上配置的默认源存储库和来自在自定义补丁基准中指定的任何备用源存储库的补丁提供合规性信息。有关备用源存储库的更多信息，请参阅 [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。有关 Systems Manager 合规性工具的更多信息，请参阅 [AWS Systems Manager Compliance](systems-manager-compliance.md)。
**替换早期文档：**
+ `AWS-ApplyPatchBaseline`
旧文档 `AWS-ApplyPatchBaseline` 仅适用于 Windows Server 托管式节点，不提供应用程序修补支持。较新的 `AWS-RunPatchBaseline` 对 Windows 和 Linux 系统提供了同等支持。要使用 `AWS-RunPatchBaseline` 文档，需要版本 2.0.834.0 或 SSM Agent 的更高版本。
有关如何使用 `AWS-RunPatchBaseline` SSM 文档的更多信息，请参阅 [用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
### `AWS-RunPatchBaselineAssociation`
在实例上安装补丁，或扫描实例以确定是否缺少任何符合条件的补丁。在所有商业 AWS 区域 中提供。
`AWS-RunPatchBaselineAssociation` 与 `AWS-RunPatchBaseline` 的不同表现在几个重要方面：
+ `AWS-RunPatchBaselineAssociation` 主要用于使用Quick Setup（AWS Systems Manager 中的一项工具）创建的State Manager关联。具体来说，当使用 Quick Setup 主机管理配置类型时，如果选择**每天扫描实例以查找缺少的补丁**选项，系统将使用 `AWS-RunPatchBaselineAssociation` 进行操作。
但是，在大多数情况下，在设置您自己的修补操作时，应选择 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 或者 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)，而非 `AWS-RunPatchBaselineAssociation`。
有关更多信息，请参阅以下主题：
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [用于修补的 SSM 命令文档：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` 支持使用标签来标识在运行时使用哪个补丁基准来用于一组目标。
+ 对于使用 `AWS-RunPatchBaselineAssociation` 的修补操作，将按照特定的 State Manager 关联来编译补丁合规性数据。在运行 `AWS-RunPatchBaselineAssociation` 时收集的补丁合规性数据，使用 `PutComplianceItems` API 命令而不是 `PutInventory` 命令来记录。这样可以防止覆盖与此特定关联无关的合规性数据。
对于 Linux 操作系统，为来自实例上配置的默认源存储库和来自您在自定义补丁基准中指定的任何备用源存储库的补丁提供合规性信息。有关备用源存储库的更多信息，请参阅 [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。有关 Systems Manager 合规性工具的更多信息，请参阅 [AWS Systems Manager Compliance](systems-manager-compliance.md)。
**替换早期文档：**
+ **无**
有关如何使用 `AWS-RunPatchBaselineAssociation` SSM 文档的更多信息，请参阅 [用于修补的 SSM 命令文档：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)。
### `AWS-RunPatchBaselineWithHooks`
在托管式节点上安装补丁或扫描节点，以确定是否缺少任何符合条件的补丁，您可以使用可选钩子在修补周期内在三个点运行 SSM 文档。在所有商业 AWS 区域 中提供。在 macOS 上不受支持。
在其 `Install` 操作中，`AWS-RunPatchBaselineWithHooks` 不同于 `AWS-RunPatchBaseline`。
`AWS-RunPatchBaselineWithHooks` 支持托管式节点修补期间在指定点运行的生命周期钩子。由于补丁安装有时需要重启托管式节点，修补操作分为两个事件，共有三个支持自定义功能的钩子。第一个钩子先于 `Install with NoReboot` 操作。第二个钩子后于 `Install with NoReboot` 操作。节点重启后，即可使用第三个钩子。
**替换早期文档：**
+ **无**
有关如何使用 `AWS-RunPatchBaselineWithHooks` SSM 文档的更多信息，请参阅 [用于修补的 SSM 命令文档：`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)。
## 适用于修补托管式节点的旧 SSM 文档
以下四个 SSM 文档仍可在某些 AWS 区域 中使用。不过，这些版本已不再更新，将来可能不再受支持，因此不建议使用。请使用 [用于修补托管式节点的推荐 SSM 文档](#patch-manager-ssm-documents-recommended) 中介绍的文档。
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
仅支持 Windows Server 托管式节点，但不包括对在其替换文档 `AWS-RunPatchBaseline` 中找到的修补应用程序的支持。在 2017 年 8 月之后推出的 AWS 区域 中不提供。
**注意**
此 SSM 文档 `AWS-RunPatchBaseline` 的替换文档需要版本 2.0.834.0 或 SSM Agent 的更高版本。可以使用 `AWS-UpdateSSMAgent` 文档将托管式节点更新为代理的最新版本。
### `AWS-FindWindowsUpdates`
已被 `AWS-InstallWindowsUpdates` 取代，可执行所有相同的操作。在 2017 年 4 月之后推出的 AWS 区域 中不提供。
要得到与这个早期 SSM 文档相同的结果，请使用推荐的替换文档 `AWS-InstallWindowsUpdates` 的以下参数配置：
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
已被 `AWS-InstallWindowsUpdates` 取代，可执行所有相同的操作。在 2017 年 4 月之后推出的所有 AWS 区域 中均不提供。
要得到与这个早期 SSM 文档相同的结果，请使用推荐的替换文档 `AWS-InstallWindowsUpdates` 的以下参数配置：
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
已被 `AWS-InstallWindowsUpdates` 取代，可执行所有相同的操作。在 2017 年 4 月之后推出的所有 AWS 区域 中均不提供。
要得到与这个早期 SSM 文档相同的结果，请使用推荐的替换文档 `AWS-InstallWindowsUpdates` 的以下参数配置：
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *KB 文章的逗号分隔列表*
## 适用于修补托管式节点的 SSM 文档的已知限制
### 外部重启中断
如果在安装补丁期间，节点上的系统启动了重启（例如，将更新应用于固件或诸如 SecuReboot 之类的功能），则即使成功安装了补丁，修补文档的执行也可能会中断并标记为失败。出现这种情况是因为 SSM Agent 无法在外部重启后保持和恢复文档执行状态。
要在执行失败后验证补丁安装状态，请运行 `Scan` 修补操作，然后在补丁管理器中检查补丁合规性数据，进而评测当前的合规性状态。
# 用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`
AWS Systems Manager 支持 `AWS-RunPatchBaseline`，这是Patch Manager（AWS Systems Manager 中的一项工具）的 Systems Manager 文档（SSM 文档）。此 SSM 文档在托管式节点上为安全性相关更新和其他类型的更新执行修补操作。运行文档时，如果未指定补丁组，则使用为操作系统类型指定的“默认”的补丁基准。否则，它将使用与补丁组关联的补丁基准。有关补丁组的信息，请参阅 [补丁组](patch-manager-patch-groups.md)。
您可以使用文档 `AWS-RunPatchBaseline` 为操作系统和应用程序应用补丁。（在 Windows Server 上，应用程序支持仅限于更新 Microsoft 发布的应用程序。）
本文档支持 Linux、macOS和 Windows Server 托管式节点。此文档将为每个平台执行适当的操作。
**注意**
Patch Manager 还支持传统 SSM 文档 `AWS-ApplyPatchBaseline`。但是，此文档仅支持在 Windows 托管式节点上进行修补。建议改用 `AWS-RunPatchBaseline`，因为其同时支持在 Linux、macOS 和 Windows Server 托管式节点上进行修补。要使用 `AWS-RunPatchBaseline` 文档，需要版本 2.0.834.0 或 SSM Agent 的更高版本。
------
#### [ Windows Server ]
在 Windows Server 托管式节点上，`AWS-RunPatchBaseline` 文档下载并调用 PowerShell 模块，然后该模块下载适用于托管式节点的补丁基准快照。此补丁基准快照包含已批准的补丁列表，这些补丁通过查询 Windows 服务器更新服务 (WSUS) 服务器的补丁基准进行编译。将此列表传递给 Windows Update API，Windows Update API 根据需要控制已批准的补丁的下载和安装。
------
#### [ Linux ]
在 Linux 托管式节点上，`AWS-RunPatchBaseline` 文档调用 Python 模块，然后该模块下载适用于托管式节点的补丁基准快照。此补丁基准快照使用已定义规则及已批准和已阻止补丁列表驱动每个节点类型相应的软件包管理器：
+ Amazon Linux 2、Oracle Linux 和 RHEL 7 托管节点使用 YUM。对于 YUM 操作，Patch Manager 需要使用 `Python 2.6` 或受支持的更高版本（2.6 – 3.12）。Amazon Linux 2023 使用 DNF。对于 DNF 操作，Patch Manager 需要使用受支持版本的 `Python 2` 或 `Python 3`（2.6 – 3.12）。
+ RHEL 8 托管式节点使用 DNF。对于 DNF 操作，Patch Manager 需要使用受支持版本的 `Python 2` 或 `Python 3`（2.6 – 3.12）。（默认情况下，RHEL 8 上不安装其中任一版本。您必须手动安装其中一个版本。）
+ Debian Server 和 Ubuntu Server 实例使用 APT。对于 APT 操作，Patch Manager 需要使用受支持版本的 `Python 3`（3.0 – 3.12）。
------
#### [ macOS ]
在 macOS 托管式节点上，`AWS-RunPatchBaseline` 文档调用 Python 模块，然后该模块下载适用于托管式节点的补丁基准快照。接下来，Python 子进程在节点上调用 AWS Command Line Interface (AWS CLI），以检索指定软件包管理器的安装和更新信息，并为每个更新软件包驱动适当的软件包管理器。
------
每个快照都专用于一个 AWS 账户、补丁组、操作系统和快照 ID。快照通过预签名的 Amazon Simple Storage Service (Amazon S3) URL 传送，该 URL 在快照创建 24 小时后过期。但是，在 URL 过期后，如果要将相同的快照内容应用于其他托管式节点，您可以在创建快照后最久 3 天内生成新的预签名 Amazon S3 URL。为此，请使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 命令。
安装完所有已批准和适用的更新后，根据需要执行重启，然后在托管式节点上生成补丁合规性信息，并向 Patch Manager 报告。
**注意**
如果在 `AWS-RunPatchBaseline` 文档中将 `RebootOption` 参数设置为 `NoReboot`，在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。
有关查看补丁合规性数据的信息，请参阅 [关于补丁合规性](compliance-about.md#compliance-monitor-patch)。
## `AWS-RunPatchBaseline` 参数
`AWS-RunPatchBaseline` 支持六个参数。`Operation` 参数是必需的。`InstallOverrideList` 、 `BaselineOverride` 和 `RebootOption` 参数是可选的。从技术上讲，`Snapshot-ID` 是可选的，但我们建议在维护时段之外运行 `AWS-RunPatchBaseline` 时为其提供一个自定义值，而在维护时段操作中运行此文档时，让 Patch Manager 自动提供该值。
**Topics**
+ [参数名称: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [参数名称: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [参数名称: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [参数名称: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [参数名称: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [参数名称: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### 参数名称: `Operation`
**用法**：必需。
**选项**：`Scan` \$1 `Install`。
Scan
选择 `Scan` 选项时，`AWS-RunPatchBaseline` 确定托管式节点的补丁合规性状态并向 Patch Manager 报告此信息。`Scan` 不提示要安装的更新或要重启的托管式节点。相反，该操作会标识哪些地方缺少已批准并且适用于节点的更新。
安装
选择 `Install` 选项时，`AWS-RunPatchBaseline` 会尝试安装托管式节点中缺失并已批准的适用更新。在 `Install` 操作中生成的补丁合规性信息不会列出任何缺失的更新。但是，如果更新的安装因任何原因失败，它会报告处于失败状态的更新。一旦在托管式节点上安装了更新，就一定会重启节点，以确保正常安装和激活更新。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
如果在 Patch Manager 更新托管式节点*之前*安装了基准规则指定的补丁，则系统可能无法按预期重启。当补丁是由用户手动安装或由其他程序（例如 Ubuntu Server 上的 `unattended-upgrades` 程序包）自动安装时，可能会发生这种情况。
### 参数名称: `AssociationId`
**用法**：可选。
`AssociationId` 是State Manager（AWS Systems Manager 中的一项工具）中现有关联的 ID。Patch Manager 使用它来将合规性数据添加到指定的关联上。此关联与[在 Quick Setup 的补丁策略中设置](quick-setup-patch-manager.md)的修补操作有关。
**注意**
使用 `AWS-RunPatchBaseline` 时，如果在补丁策略基准覆盖的同时提供了一个 `AssociationId` 值，系统将以 `PatchPolicy` 操作来完成修补，`AWS:ComplianceItem` 中报告的 `ExecutionType` 值也是 `PatchPolicy`。如果未提供任何 `AssociationId` 值，系统将以 `Command` 操作来完成修补，提交的 `AWS:ComplianceItem` 中报告的 `ExecutionType` 值也是 `Command`。
如果您还没有要使用的关联，可以通过运行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 命令来创建关联。
### 参数名称: `Snapshot ID`
**用法**：可选。
`Snapshot ID` 是 Patch Manager 使用的唯一 ID (GUID)，用于确保在单一操作中修补的一组托管式节点均具有完全相同的一组已批准补丁。尽管它定义为可选参数，根据是否在维护时段中运行 `AWS-RunPatchBaseline`，我们还是提供了不同的最佳实践建议，如下表所述。
**`AWS-RunPatchBaseline` 最佳实践**
| Mode | 最佳实践 | Details |
| --- | --- | --- |
| 正在维护时段内运行 AWS-RunPatchBaseline | 不要提供快照 ID，Patch Manager 将为您提供。 | 如果使用维护时段运行 `AWS-RunPatchBaseline`，则不应提供自己生成的快照 ID。这种情况下，Systems Manager 基于维护时段执行 ID 提供 GUID 值。这可确保在维护时段中为 `AWS-RunPatchBaseline` 的所有调用使用正确的 ID。 如果在这种情况下您指定值，请注意，补丁基准的快照最多保留 3 天。之后，即使您在快照到期后指定相同的 ID，也将生成新的快照。 |
| 正在在维护时段以外运行 AWS-RunPatchBaseline | 为快照 ID¹ 生成和指定自定义 GUID 值。 | 如果您不使用维护时段运行 `AWS-RunPatchBaseline`，我们建议您为每个补丁基准生成并指定一个唯一的快照 ID，特别是于同一操作中在多个托管式节点上运行 `AWS-RunPatchBaseline` 文档时。如果在这种情况下不指定 ID，Systems Manager 会为向其发送命令的每个托管式节点生成不同的快照 ID。这可能会导致在托管式节点间指定不同的补丁集。 例如，假设您正在直接通过 Run Command（AWS Systems Manager 中的一项工具）运行 `AWS-RunPatchBaseline` 文档，并以一组 50 个的托管式节点为目标。指定自定义快照 ID 将生成单一基准快照，用于评估和修补所有节点，从而确保所有节点最终处于一致状态。 |
| ¹ 您可以使用任何能够生成 GUID 的工具为快照 ID 参数生成值。例如，在 PowerShell 中，可以使用 `New-Guid` cmdlet 生成格式为 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 的 GUID。 |
### 参数名称: `InstallOverrideList`
**用法**：可选。
使用 `InstallOverrideList`，可以指定一个到要安装的补丁列表的 https URL 或 Amazon S3 路径样式 URL。此补丁安装列表（以 YAML 格式维护）会覆盖当前的默认补丁基准指定的补丁。这样，您可以更精细地控制在托管式节点上安装哪些补丁。
**重要**
`InstallOverrideList` 文件名不能包含以下字符：反引号 (`)、单引号 (')、双引号 (") 和美元符号 (\$1)。
使用 `InstallOverrideList` 参数时的修补操作行为在 Linux 和 macOS 托管式节点以及 Windows Server 托管式节点之间有所不同。在 Linux 和 macOS 上，Patch Manager 尝试应用 `InstallOverrideList` 补丁列表中包含的补丁（存在于节点上启用的任何存储库中），无论补丁是否符合补丁基准规则。不过，在 Windows Server 节点上，只有当 `InstallOverrideList` 补丁列表中的补丁也符合补丁基准规则时，*才*会应用补丁列表中的补丁。
请注意，合规性根据补丁基准中指定的内容而不是您在补丁的 `InstallOverrideList` 列表中指定的内容反映补丁状态。也就是说，Scan 操作会忽略 `InstallOverrideList` 参数。这是为了确保合规性报告根据策略而不是针对特定修补操作批准的内容持续反映补丁状态。
**注意**
当您修补仅使用 IPv6 的节点时，请确保提供的 URL 可从该节点访问。如果将 SSM Agent 配置选项 `UseDualStackEndpoint` 设置为 `true`，则在提供 S3 URL 时将使用双堆栈 S3 客户端。有关将代理配置为使用双堆栈的更多信息，请参阅 [教程：在仅支持 IPv6 的环境中修补服务器](patch-manager-server-patching-iPv6-tutorial.md)。
有关如何使用 `InstallOverrideList` 参数按不同维护时段计划将不同类型的补丁应用到目标组，同时仍使用单个补丁基准的说明，请参阅 [在 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 中使用 InstallOverrideList 参数的示例场景](patch-manager-override-lists.md)。
**有效的 URL 格式**
**注意**
如果您的文件存储在公开可用的存储桶中，您可以指定 https URL 格式或 Amazon S3 路径样式的 URL。如果您的文件存储在私有存储桶中，则必须指定 Amazon S3 路径样式的 URL。
+ **https URL 格式**：
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 路径样式 URL**：
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**有效的 YAML 内容格式**
用于在列表中指定补丁的格式取决于托管式节点的操作系统。但是，一般格式如下所示：
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
尽管可以在 YAML 中提供额外字段，但是补丁操作会将其忽略。
此外，建议在 S3 存储桶中添加或更新列表之前验证 YAML 文件格式是否有效。有关 YAML 格式的更多信息，请参阅 [yaml.org](http://www.yaml.org)。对于验证工具选项，请在 Web 中搜索“yaml 格式验证程序”。
------
#### [ Linux ]
**id**
**id** 字段是必需的。它用来使用软件包名称和架构指定补丁。例如：`'dhclient.x86_64'`。您可以在 id 中使用通配符来指示多个软件包。例如：`'dhcp*'` 和 `'dhcp*1.*'`。
**标题**
**title** 字段是可选的，但它在 Linux 系统上提供额外的筛选功能。如果使用 **title**，它应包含以下格式之一的软件包版本信息：
YUM/SUSE Linux Enterprise Server (SLES)：
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
对于 Linux 补丁标题，您可以在任意位置使用一个或多个通配符来扩展匹配软件包的数量。例如：`'*32:9.8.2-0.*.rc1.57.amzn1'`。
例如：
+ 托管式节点上目前安装了 apt 软件包版本 1.2.25，但版本 1.2.27 现已可用。
+ 将 apt.amd64 版本 1.2.27 添加到补丁列表中。它依赖于 apt utils.amd64 版本 1.2.27，但在列表中指定了 apt-utils.amd64 版本 1.2.25。
在这种情况下，将阻止安装 apt 版本 1.2.27 并报告为“Failed-NonCompliant.”。
------
#### [ Windows Server ]
**id**
**id** 字段是必需的。它用来使用 Microsoft 知识库 ID（例如 KB2736693）和 Microsoft 安全公告 ID（例如 MS17-023）指定补丁。
您在 Windows 补丁列表中提供的任何其他字段都是可选的，仅供您自己参考。您可以使用其他字段，如 **title**、**classification**、**severity** 等来提供关于指定补丁的更详细信息。
------
#### [ macOS ]
**id**
**id** 字段是必需的。**id** 字段的值可以使用 `{package-name}.{package-version}` 格式或 \$1软件包名称\$1 格式。
------
**示例补丁列表**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### 参数名称: `RebootOption`
**用法**：可选。
**选项**：`RebootIfNeeded` \$1 `NoReboot`
**默认值**：`RebootIfNeeded`
**警告**
默认选项是 `RebootIfNeeded`。务必为应用场景选择正确的选项。例如，如果您的托管式节点必须立即重启才能完成配置过程，请选择 `RebootIfNeeded`。或者，如果您需要在计划的重启时间之前保持托管式节点可用，请选择 `NoReboot`。
**重要**
我们不建议使用 Patch Manager 在 Amazon EMR（原 Amazon Elastic MapReduce）中修补集群实例。特别是，不要为 `RebootOption` 参数选择 `RebootIfNeeded` 选项。（此选项在 SSM 命令文档中可用，用于修补 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks`。）
使用 Patch Manager 进行修补的底层命令使用 `yum` 和 `dnf` 命令。因此，由于软件包的安装方式，这些操作会导致不兼容。有关在 Amazon EMR 集群上更新软件的首选方法的信息，请参阅《Amazon EMR Management Guide》**中的 [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)。
RebootIfNeeded
选择 `RebootIfNeeded` 选项时，托管式节点将在以下任一情况下重启：
+ Patch Manager 已安装一个或多个补丁。
Patch Manager 不评估补丁是否*必需*重启。即使补丁不需要重启，系统也会重启。
+ Patch Manager 检测 `Install` 操作期间的一个或多个状态为 `INSTALLED_PENDING_REBOOT` 的补丁。
`INSTALLED_PENDING_REBOOT` 状态可能表示在上次运行 `Install` 操作时选择了选项 `NoReboot`，或者是自上次重新启动托管式节点以来在 Patch Manager 外部安装了补丁。
在这两种情况下重启托管式节点，可确保从内存中刷新更新的软件包，并在所有操作系统中保持修补和重启行为一致。
NoReboot
选择 `NoReboot` 选项时，即使托管式节点在 `Install` 操作期间安装了补丁，Patch Manager 也不会重启托管式节点。如果您知道托管式节点在应用补丁后不需要重启，或者应用程序或进程在节点上运行，但不应因修补操作重启而中断，则此选项有用。当您希望更多地控制托管式节点的重启时间（例如，使用维护时段来控制）时，该选项也很有用。
如果选择 `NoReboot` 选项并安装了补丁，则会为该补丁分配状态 `InstalledPendingReboot`。但托管式节点本身将被标记为 `Non-Compliant`。重启并运行 `Scan` 操作后，托管式节点状态将更新为 `Compliant`。
`NoReboot` 选项仅阻止操作系统级别的重启，服务级别的重启仍可作为修补过程的一部分进行。例如，当 Docker 更新时，即使启用了 `NoReboot`，Amazon Elastic Container Service 等依赖服务也可能会自动重启。要使关键服务不被中断，可考虑采取其他措施，例如暂时将实例从服务中删除或在维护时段内安排修补。
**补丁安装跟踪文件**：为跟踪补丁安装，特别是自上次系统重启以来安装的补丁，Systems Manager 会在托管式节点上维护一个文件。
**重要**
请勿删除或修改该跟踪文件。如果删除或损坏此文件，托管式节点的补丁合规性报告则不准确。如果发生这种情况，请重启节点并运行补丁扫描操作以还原此文件。
此跟踪文件存储在托管式节点上的以下位置：
+ Linux 操作系统：
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 操作系统:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### 参数名称: `BaselineOverride`
**用法**：可选。
您可以在运行时使用 `BaselineOverride` 参数来定义修补首选项。此基准覆盖在 S3 存储桶中以 JSON 对象的形式进行维护。它确保修补操作使用的所提供的基准与主机的操作系统相匹配，而不是应用默认补丁基准中的规则
**重要**
`BaselineOverride` 文件名不能包含以下字符：反引号 (`)、单引号 (')、双引号 (") 和美元符号 (\$1)。
有关如何使用 `BaselineOverride` 参数的更多信息，请参阅 [使用基准覆盖参数](patch-manager-baselineoverride-parameter.md)。
### 参数名称: `StepTimeoutSeconds`
**用法**：必需。
命令在被视为失败前将会运行的时间（以秒为单位），介于 1 至 36000 秒（10 小时）之间。
# 用于修补的 SSM 命令文档：`AWS-RunPatchBaselineAssociation`
就像 `AWS-RunPatchBaseline` 文档，`AWS-RunPatchBaselineAssociation` 对安全相关更新及其他更新类型执行修补操作。您也可以使用文档 `AWS-RunPatchBaselineAssociation` 为操作系统和应用程序应用补丁。（在 Windows Server 上，应用程序支持仅限于更新 Microsoft 发布的应用程序。）
此文档为 Linux、macOS 和 Windows Server 支持 Amazon Elastic Compute Cloud (Amazon EC2) 实例。它不支持[混合和多云](operating-systems-and-machine-types.md#supported-machine-types)环境中的非 EC2 节点。此文档将为每个平台执行相应的操作，在 Linux 上调用 Python 模块和 macOS 实例，以及在 Windows 实例上调用 PowerShell 模块。
但是，`AWS-RunPatchBaselineAssociation` 与 `AWS-RunPatchBaseline` 存在以下差异：
+ `AWS-RunPatchBaselineAssociation` 主要用于使用[Quick Setup](systems-manager-quick-setup.md)（AWS Systems Manager 中的一项工具）创建的State Manager关联。具体来说，当使用 Quick Setup 主机管理配置类型时，如果选择**每天扫描实例以查找缺少的补丁**选项，系统将使用 `AWS-RunPatchBaselineAssociation` 进行操作。
但是，在大多数情况下，在设置自己的修补操作时，应选择 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 或者 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)，而非 `AWS-RunPatchBaselineAssociation`。
+ 在使用 `AWS-RunPatchBaselineAssociation` 文档时，您可以在该文档的 `BaselineTags` 参数字段中指定标签键对。如果您 AWS 账户中的自定义补丁基准共享这些标签，则Patch Manager（AWS Systems Manager 中的一项工具）会在目标实例上运行时使用该标记的基准，而不是当前为操作系统类型指定的“默认”补丁基准。
**注意**
如果您选择在修补操作中使用 `AWS-RunPatchBaselineAssociation`，而不是使用 Quick Setup 设置的内容，并且您想要使用其可选的 `BaselineTags` 参数时，您必须为[实例配置文件](setup-instance-permissions.md)提供一些额外权限，以用于 Amazon Elastic Compute Cloud (Amazon EC2) 实例。有关更多信息，请参阅 [参数名称: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)。
以下两种格式都适用于 `BaselineTags` 参数：
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
标签键和值不能包含以下字符：反引号 (`)、单引号 (')、双引号 (") 和美元符号 (\$1)。
+ 在运行 `AWS-RunPatchBaselineAssociation` 时，其收集的补丁合规性数据将使用 `PutComplianceItems` API 命令而不是 `PutInventory` 命令 （该命令被 `AWS-RunPatchBaseline` 使用）来记录。这种差异意味着，所存储和报告的补丁合规性信息是依据特定*关联*的。在此关联之外生成的补丁合规性数据不会被覆盖。
+ 运行 `AWS-RunPatchBaselineAssociation` 后所报告的补丁合规性信息显示某个实例是否符合规定。它不包括补丁级别的详细信息，如以下 AWS Command Line Interface (AWS CLI) 命令的输出所显示的那样。命令筛选 `Association` 作为合规性类型：
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
系统将返回类似于以下内容的信息。
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
如果已将标签键对值指定为 `AWS-RunPatchBaselineAssociation` 文档的参数，则 Patch Manager 会搜索自定义补丁基准，该基准与操作系统类型匹配且已使用相同标签键对做了标记。此搜索不限于当前指定的默认补丁程序基准或分配给补丁组的基准。如果未找到具有指定标签的基准，下一步 Patch Manager 会查找补丁组（如果在运行 `AWS-RunPatchBaselineAssociation` 的命令中已经指定了）。如果没有匹配的补丁组，Patch Manager 将回退到操作系统账户的当前默认补丁基准。
如果找到多个具有 `AWS-RunPatchBaselineAssociation` 文档中的指定标签的补丁基准，则 Patch Manager 返回一条错误消息，指示只能使用该键值对标记一个补丁基准，以便继续执行操作。
**注意**
在 Linux 节点上，每种节点类型的相应软件包管理器被用来安装软件包：
Amazon Linux 2、Oracle Linux 和 RHEL 实例使用 YUM。对于 YUM 操作，Patch Manager 需要使用 `Python 2.6` 或受支持的更高版本（2.6 – 3.12）。Amazon Linux 2023 使用 DNF。对于 DNF 操作，Patch Manager 需要使用受支持版本的 `Python 2` 或 `Python 3`（2.6 - 3.12）
Debian Server 和 Ubuntu Server 实例使用 APT。对于 APT 操作，Patch Manager 需要使用受支持版本的 `Python 3`（3.0 – 3.12）。
在扫描完毕，或者所有已批准和适用的更新安装完毕后，根据需要执行重启，然后在实例上生成补丁合规性信息，并向 Patch Compliance 服务报告。
**注意**
如果在 `AWS-RunPatchBaselineAssociation` 文档中将 `RebootOption` 参数设置为 `NoReboot`，在 Patch Manager 运行后不会重启实例。有关更多信息，请参阅 [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)。
有关查看补丁合规性数据的信息，请参阅 [关于补丁合规性](compliance-about.md#compliance-monitor-patch)。
## `AWS-RunPatchBaselineAssociation` 参数
`AWS-RunPatchBaselineAssociation` 支持五个参数。`Operation` 和 `AssociationId` 参数是必需的。`InstallOverrideList`、 `RebootOption` 和 `BaselineTags` 参数可选。
**Topics**
+ [参数名称: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [参数名称: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [参数名称: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [参数名称: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### 参数名称: `Operation`
**用法**：必需。
**选项**：`Scan` \$1 `Install`。
Scan
选择 `Scan` 选项时，`AWS-RunPatchBaselineAssociation` 确定实例的补丁合规性状态，并向 Patch Manager 报告此信息。`Scan` 不提示要安装的更新或要重启的实例。相反，此操作会标识缺少哪些已批准并且适用于此实例的更新。
安装
选择 `Install` 选项时，`AWS-RunPatchBaselineAssociation` 尝试安装实例中缺失的已批准并且适用的更新。在 `Install` 操作中生成的补丁合规性信息不会列出任何缺失的更新。但是，如果更新的安装因任何原因失败，它会报告处于失败状态的更新。只要在实例上安装了更新，就一定会重启实例，以确保更新正常安装和激活。（例外：如果将 `AWS-RunPatchBaselineAssociation` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启实例。有关更多信息，请参阅 [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)。）
如果在 Patch Manager 更新实例*之前* 安装了基准规则指定的补丁，则系统可能无法按预期重启。当补丁是由用户手动安装或由其他程序（例如 Ubuntu Server 上的 `unattended-upgrades` 程序包）自动安装时，可能会发生这种情况。
### 参数名称: `BaselineTags`
**用法**：可选。
`BaselineTags` 是您选择并分配给单个自定义补丁基准的唯一标签键值对。可以为此参数指定一个或多个值。以下两种格式均为有效：
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
标签键和值不能包含以下字符：反引号 (`)、单引号 (')、双引号 (") 和美元符号 (\$1)。
`BaselineTags` 值是 Patch Manager 使用的值，用于确保在单一操作中修补的一组实例都具有完全相同的一组已批准补丁。当执行修补操作时，Patch Manager 检查操作系统类型的补丁基准是否使用为 `BaselineTags` 指定的相同键值对进行了标记。如果存在匹配项，则使用此自定义补丁基准。如果不匹配，则根据为修补操作指定的任何补丁组来标识补丁基准。如果没有，AWS 使用该操作系统的托管预定义补丁基准。
**其他权限要求**
如果您在修补操作中使用 `AWS-RunPatchBaselineAssociation`，而不是使用 Quick Setup 设置的内容，并且您想要使用可选的 `BaselineTags` 参数，则必须将以下权限添加到[实例配置文件](setup-instance-permissions.md)，以用于 Amazon Elastic Compute Cloud (Amazon EC2) 实例。
**注意**
Quick Setup 和 `AWS-RunPatchBaselineAssociation` 不支持本地服务器和虚拟机 (VM)。
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
将*补丁基准 ARN* 替换为使用要提供访问权限的补丁基准的 Amazon Resource Name (ARN)，格式为 `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`。
### 参数名称: `AssociationId`
**用法**：必需。
`AssociationId` 是State Manager（AWS Systems Manager 中的一项工具）中现有关联的 ID。Patch Manager 使用它来将合规性数据添加到指定的关联上。此关联与[在 Quick Setup 中创建的主机管理配置](quick-setup-host-management.md)中启用的补丁 `Scan` 操作有关。通过将修补结果作为关联合规性数据而不是库存合规性数据发送，您的实例的现有库存合规性信息不会在修补操作后被覆盖，同样，也不会覆盖其他关联 ID 的信息。如果您还没有要使用的关联，可以通过运行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 命令来创建关联。例如：
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### 参数名称: `InstallOverrideList`
**用法**：可选。
使用 `InstallOverrideList`，为要安装的补丁列表指定 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL。此补丁安装列表（以 YAML 格式维护）会覆盖当前的默认补丁基准指定的补丁。这样，您可以更精细地控制实例上安装的补丁。
**重要**
`InstallOverrideList` 文件名不能包含以下字符：反引号 (`)、单引号 (')、双引号 (") 和美元符号 (\$1)。
使用 `InstallOverrideList` 参数时的修补操作行为在 Linux 和 macOS 托管式节点以及 Windows Server 托管式节点之间有所不同。在 Linux 和 macOS 上，Patch Manager 尝试应用 `InstallOverrideList` 补丁列表中包含的补丁（存在于节点上启用的任何存储库中），无论补丁是否符合补丁基准规则。不过，在 Windows Server 节点上，只有当 `InstallOverrideList` 补丁列表中的补丁也符合补丁基准规则时，*才*会应用补丁列表中的补丁。
请注意，合规性根据补丁基准中指定的内容而不是您在补丁的 `InstallOverrideList` 列表中指定的内容反映补丁状态。也就是说，Scan 操作会忽略 `InstallOverrideList` 参数。这是为了确保合规性报告根据策略而不是针对特定修补操作批准的内容持续反映补丁状态。
**有效的 URL 格式**
**注意**
如果您的文件存储在公开可用的存储桶中，您可以指定 https URL 格式或 Amazon S3 路径样式的 URL。如果您的文件存储在私有存储桶中，则必须指定 Amazon S3 路径样式的 URL。
+ **https URL 格式示例**：
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 路径样式 URL 示例**：
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**有效的 YAML 内容格式**
用在列表中指定补丁的格式取决于实例的操作系统。但是，一般格式如下所示：
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
尽管可以在 YAML 中提供额外字段，但是补丁操作会将其忽略。
此外，建议在 S3 存储桶中添加或更新列表之前验证 YAML 文件格式是否有效。有关 YAML 格式的更多信息，请参阅 [yaml.org](http://www.yaml.org)。对于验证工具选项，请在 Web 中搜索“yaml 格式验证程序”。
+ Microsoft Windows
**id**
**id** 字段是必需的。它用来使用 Microsoft 知识库 ID（例如 KB2736693）和 Microsoft 安全公告 ID（例如 MS17-023）指定补丁。
您在 Windows 补丁列表中提供的任何其他字段都是可选的，仅供您自己参考。您可以使用其他字段，如 **title**、**classification**、**severity** 等来提供关于指定补丁的更详细信息。
+ Linux
**id**
**id** 字段是必需的。它用来使用软件包名称和架构指定补丁。例如：`'dhclient.x86_64'`。您可以在 id 中使用通配符来指示多个软件包。例如：`'dhcp*'` 和 `'dhcp*1.*'`。
**删除实例快照**
**title** 字段是可选的，但它在 Linux 系统上提供额外的筛选功能。如果使用 **title**，它应包含以下格式之一的软件包版本信息：
YUM/Red Hat Enterprise Linux (RHEL)：
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
对于 Linux 补丁标题，您可以在任意位置使用一个或多个通配符来扩展匹配软件包的数量。例如：`'*32:9.8.2-0.*.rc1.57.amzn1'`。
例如：
+ 实例上目前安装了 Apt 软件包版本 1.2.25，但版本 1.2.27 现已可用。
+ 将 apt.amd64 版本 1.2.27 添加到补丁列表中。它依赖于 apt utils.amd64 版本 1.2.27，但在列表中指定了 apt-utils.amd64 版本 1.2.25。
在这种情况下，将阻止安装 apt 版本 1.2.27 并报告为“Failed-NonCompliant.”。
**其他字段**
您在 Linux 补丁列表中提供的任何其他字段都是可选的，仅供您自己参考。您可以使用其他字段，如 **classification**、**severity** 等来提供关于指定补丁的更详细信息。
**示例补丁列表**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### 参数名称: `RebootOption`
**用法**：可选。
**选项**：`RebootIfNeeded` \$1 `NoReboot`
**默认值**：`RebootIfNeeded`
**警告**
默认选项是 `RebootIfNeeded`。务必为应用场景选择正确的选项。例如，如果您的实例必须立即重启才能完成配置过程，请选择 `RebootIfNeeded`。或者，如果您需要在计划的重启时间之前保持实例可用，请选择 `NoReboot`。
**重要**
`NoReboot` 选项仅阻止操作系统级别的重启，服务级别的重启仍可作为修补过程的一部分进行。例如，当 Docker 更新时，即使启用了 `NoReboot`，Amazon Elastic Container Service 等依赖服务也可能会自动重启。要使关键服务不被中断，可考虑采取其他措施，例如暂时将实例从服务中删除或在维护时段内安排修补。
**重要**
我们不建议使用 Patch Manager 在 Amazon EMR（原 Amazon Elastic MapReduce）中修补集群实例。特别是，不要为 `RebootOption` 参数选择 `RebootIfNeeded` 选项。（此选项在 SSM 命令文档中可用，用于修补 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks`。）
使用 Patch Manager 进行修补的底层命令使用 `yum` 和 `dnf` 命令。因此，由于软件包的安装方式，这些操作会导致不兼容。有关在 Amazon EMR 集群上更新软件的首选方法的信息，请参阅《Amazon EMR Management Guide》**中的 [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)。
RebootIfNeeded
如果您在选择 `RebootIfNeeded` 选项，则在以下任一情况下重启实例：
+ Patch Manager 已安装一个或多个补丁。
Patch Manager 不评估补丁是否*必需*重启。即使补丁不需要重启，系统也会重启。
+ Patch Manager 检测 `Install` 操作期间的一个或多个状态为 `INSTALLED_PENDING_REBOOT` 的补丁。
`INSTALLED_PENDING_REBOOT` 状态可能表示在上次运行 `Install` 操作时选择了选项 `NoReboot`，或者是自上次重新启动托管式节点以来在 Patch Manager 外部安装了补丁。
在这两种情况下重启实例，可确保从内存中刷新更新的软件包，并在所有操作系统中保持修补和重启行为的一致。
NoReboot
选择 `NoReboot` 选项后，即使实例在 `Install` 操作期间安装了补丁，Patch Manager 也不会重启实例。如果您知道您的实例在应用补丁后不需要重启，或者您的应用程序或进程在实例上运行，但不应因修补操作重启而中断，则此选项有用。当您希望更多地控制实例重启的时间（例如，使用维护时段）时，该选项也很有用。
**补丁安装跟踪文件**：为了跟踪补丁安装，特别是自上次重启系统以来安装的补丁，Systems Manager 会在托管实例上维护一个文件。
**重要**
请勿删除或修改该跟踪文件。如果删除或损坏此文件，实例的补丁合规性报告则不准确。如果发生这种情况，请重启实例并运行补丁扫描操作以还原文件。
此跟踪文件存储在托管实例上的以下位置：
+ Linux 操作系统：
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 操作系统:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# 用于修补的 SSM 命令文档：`AWS-RunPatchBaselineWithHooks`
AWS Systems Manager 支持 `AWS-RunPatchBaselineWithHooks`，这是Patch Manager（AWS Systems Manager 中的一项工具）的 Systems Manager 文档（SSM 文档）。此 SSM 文档在托管式节点上为安全性相关更新和其他类型的更新执行修补操作。
`AWS-RunPatchBaselineWithHooks` 与 `AWS-RunPatchBaseline` 存在以下差异：
+ **包装文档**– `AWS-RunPatchBaselineWithHooks` 是 `AWS-RunPatchBaseline` 的包装器并依赖 `AWS-RunPatchBaseline` 进行一些操作。
+ **`Install` 操作** – `AWS-RunPatchBaselineWithHooks` 支持托管式节点修补期间在指定点运行的生命周期钩子。由于补丁安装有时需要重启托管式节点，修补操作分为两个事件，共有三个支持自定义功能的钩子。第一个钩子先于 `Install with NoReboot` 操作。第二个钩子后于 `Install with NoReboot` 操作。托管式节点重启后，即可使用第三个钩子。
+ **不支持自定义补丁列表**– `AWS-RunPatchBaselineWithHooks` 不支持 `InstallOverrideList` 参数。
+ **SSM Agent 支持** – `AWS-RunPatchBaselineWithHooks` 要求 SSM Agent 3.0.502 或更高版本需安装在托管式节点上才能进行修补。
运行文档时，如果未指定补丁组，则使用当前指定为操作系统类型的 “默认” 补丁基准。否则，它将使用与补丁组关联的补丁基准。有关补丁组的更多信息，请参阅 [补丁组](patch-manager-patch-groups.md)。
您可以使用文档 `AWS-RunPatchBaselineWithHooks` 为操作系统和应用程序应用补丁。（在 Windows Server 上，应用程序支持仅限于更新 Microsoft 发布的应用程序。）
本文档支持 Linux 和 Windows Server 托管式节点。此文档将为每个平台执行适当的操作。
**注意**
`AWS-RunPatchBaselineWithHooks` 在 macOS 上不受支持。
------
#### [ Linux ]
在 Linux 托管式节点上，`AWS-RunPatchBaselineWithHooks` 文档调用 Python 模块，然后该模块下载适用于托管式节点的补丁基准快照。此补丁基准快照使用已定义规则及已批准和已阻止补丁列表驱动每个节点类型相应的软件包管理器：
+ Amazon Linux 2、Oracle Linux 和 RHEL 7 托管节点使用 YUM。对于 YUM 操作，Patch Manager 需要使用 `Python 2.6` 或受支持的更高版本（2.6 – 3.12）。Amazon Linux 2023 使用 DNF。对于 DNF 操作，Patch Manager 需要使用受支持版本的 `Python 2` 或 `Python 3`（2.6 – 3.12）。
+ RHEL 8 托管式节点使用 DNF。对于 DNF 操作，Patch Manager 需要使用受支持版本的 `Python 2` 或 `Python 3`（2.6 – 3.12）。（默认情况下，RHEL 8 上不安装其中任一版本。您必须手动安装其中一个版本。）
+ Debian Server 和 Ubuntu Server 实例使用 APT。对于 APT 操作，Patch Manager 需要使用受支持版本的 `Python 3`（3.0 – 3.12）。
------
#### [ Windows Server ]
在 Windows Server 托管式节点上，`AWS-RunPatchBaselineWithHooks` 文档下载并调用 PowerShell 模块，然后该模块下载适用于托管式节点的补丁基准快照。此补丁基准快照包含已批准的补丁列表，这些补丁通过查询 Windows 服务器更新服务 (WSUS) 服务器的补丁基准进行编译。将此列表传递给 Windows Update API，Windows Update API 控制相应的已批准补丁的下载和安装。
------
每个快照都特定于一个 AWS 账户、补丁组、操作系统和快照 ID。快照通过预签名的 Amazon Simple Storage Service (Amazon S3) URL 传送，该 URL 在快照创建 24 小时后过期。但是，在 URL 过期后，如果要将相同的快照内容应用于其他托管式节点，您可以在创建快照后最久三天内生成新的预签名 Amazon S3 URL。为此，请使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 命令。
安装完所有已批准和适用的更新后，根据需要执行重启，然后在托管式节点上生成补丁合规性信息，并向 Patch Manager 报告。
如果在 `AWS-RunPatchBaselineWithHooks` 文档中将 `RebootOption` 参数设置为 `NoReboot`，在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。
**重要**
尽管 `NoReboot` 选项可以阻止操作系统重启，但无法阻止某些软件包更新时可能发生的服务级别重启。例如，在更新 Docker 等软件包时，即使已指定 `NoReboot`，仍可能会自动重启依赖服务（例如容器编排服务）。
有关查看补丁合规性数据的信息，请参阅 [关于补丁合规性](compliance-about.md#compliance-monitor-patch)。
## `AWS-RunPatchBaselineWithHooks` 操作步骤
当 `AWS-RunPatchBaselineWithHooks` 运行时，将执行以下步骤：
1. **扫描** - `Scan` 操作使用 `AWS-RunPatchBaseline` 在托管式节点上运行，并生成和上传合规性报告。
1. **验证本地补丁状态** - 运行脚本以确定根据所选操作和步骤 1 的 `Scan` 结果将执行哪些步骤。
1. 如果选定的操作为 `Scan`，则操作将被标记为完成。操作结束。
1. 如果选定的 操作为 `Install`，则 Patch Manager 评估步骤1的 `Scan` 结果，以确定接下来要运行的内容：
1. 如果未检测到缺少的补丁，并且不需要暂挂重启，则操作直接进行到最后一步（步骤 8），其中包括您提供的钩子。跳过两者之间的任何步骤。
1. 如果未检测到缺少补丁，但需要挂起重新引导，并且选定的重启选项为 `NoReboot`，则操作直接进行到最后一步（步骤 8），其中包括您提供的钩子。跳过两者之间的任何步骤。
1. 否则，操作将继续下一步。
1. **预修补钩子操作** – 为第一个生命周期钩子提供的 SSM 文档 `PreInstallHookDocName` 在托管式节点上运行。
1. **使用 NoReboot 安装** – `Install` 操作，重启选项为 `NoReboot`，使用 `AWS-RunPatchBaseline` 在托管式节点上运行，生成并上传合规性报告。
1. **安装后钩子操作** – 为第二个生命周期钩子提供的 SSM 文档 `PostInstallHookDocName` 在托管式节点上运行。
1. **验证重启** – 运行脚本以确定托管式节点是否需要重启以及要运行哪些步骤：
1. 如果选定的重启选项为 `NoReboot`，则操作直接进行到最后一步（步骤 8），其中包括您提供的钩子。跳过两者之间的任何步骤。
1. 如果选定的重启选项为 `RebootIfNeeded`、Patch Manager 检查是否需要在步骤 4 中收集的库存中进行任何暂挂重启。这意味着在以下任一情况下，操作会继续执行步骤 7，并且托管式节点将重新启动：
1. Patch Manager 安装了一个或多个补丁。（Patch Manager 不会评估补丁是否需要重启系统。即使补丁不需要重启，系统也会重启。）
1. 在安装操作期间，Patch Manager 检测到一个或多个状态为 `INSTALLED_PENDING_REBOOT` 的补丁。`INSTALLED_PENDING_REBOOT` 状态可能表示上次运行安装操作时选择了选项 `NoReboot`，或者是自上次重新启动托管式节点以来在 Patch Manager 外部安装了补丁。
如果未找到符合标准的补丁，则托管式节点修补操作完成，操作直接进入最后一个步骤（步骤 8），该步骤包含您提供的挂钩。跳过两者之间的任何步骤。
1. **重启并报告** – 带有重启选项 `RebootIfNeeded` 的安装操作，使用 `AWS-RunPatchBaseline` 在托管式节点上运行，生成并上传合规性报告。
1. **重启后钩子操作** – 为第三个生命周期钩子提供的 SSM 文档 `OnExitHookDocName` 在托管式节点上运行。
对于 `Scan` 操作，如果步骤 1 失败，则运行文档的进程将停止，并将该步骤报告为失败，尽管后续步骤报告为成功。
对于 `Install` 操作，如果任一 `aws:runDocument` 步骤在操作期间失败，则这些步骤将被报告为失败，操作直接进行到最后一步（步骤 8），其中包括您提供的钩子。跳过两者之间的任何步骤。此步骤被报告为失败，最后一步报告其操作结果的状态，其间的所有步骤均报告为成功。
## `AWS-RunPatchBaselineWithHooks` 参数
`AWS-RunPatchBaselineWithHooks` 支持六个参数。
`Operation` 参数是必需的。
`RebootOption`、 `PreInstallHookDocName`、 `PostInstallHookDocName` 和 `OnExitHookDocName` 参数可选。
`Snapshot-ID` 在技术上是可选的，但是我们建议您在维护时段以外运行 `AWS-RunPatchBaselineWithHooks` 时为其提供自定义值。让 Patch Manager 在维护时段操作期间运行文档时自动提供值。
**Topics**
+ [参数名称: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [参数名称: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [参数名称: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [参数名称: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [参数名称: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### 参数名称: `Operation`
**用法**：必需。
**选项**：`Scan` \$1 `Install`。
Scan
选择 `Scan` 选项时，系统使用 `AWS-RunPatchBaseline` 文档确定托管式节点的补丁合规性状态并向 Patch Manager 报告此信息。`Scan` 不提示要安装的更新或要重启的托管式节点。相反，该操作会标识哪些地方缺少已批准并且适用于节点的更新。
安装
选择 `Install` 选项时，`AWS-RunPatchBaselineWithHooks` 会尝试安装托管式节点中缺失并已批准的适用更新。在 `Install` 操作中生成的补丁合规性信息不会列出任何缺失的更新。但是，如果更新的安装因任何原因失败，它会报告处于失败状态的更新。一旦在托管式节点上安装了更新，就一定会重启节点，以确保正常安装和激活更新。（例外：如果将 `AWS-RunPatchBaselineWithHooks` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)。）
如果在 Patch Manager 更新托管式节点*之前*安装了基准规则指定的补丁，则系统可能无法按预期重启。当补丁是由用户手动安装或由其他程序（例如 Ubuntu Server 上的 `unattended-upgrades` 程序包）自动安装时，可能会发生这种情况。
### 参数名称: `Snapshot ID`
**用法**：可选。
`Snapshot ID` 是 Patch Manager 使用的唯一 ID (GUID)，用于确保在单一操作中修补的一组托管式节点均具有完全相同的一组已批准补丁。尽管它定义为可选参数，根据是否在维护时段中运行 `AWS-RunPatchBaselineWithHooks`，我们还是提供了不同的最佳实践建议，如下表所述。
**`AWS-RunPatchBaselineWithHooks` 最佳实践**
| Mode | 最佳实践 | Details |
| --- | --- | --- |
| 正在维护时段内运行 AWS-RunPatchBaselineWithHooks | 不要提供快照 ID，Patch Manager 将为您提供。 | 如果使用维护时段运行 `AWS-RunPatchBaselineWithHooks`，则不应提供自己生成的快照 ID。这种情况下，Systems Manager 基于维护时段执行 ID 提供 GUID 值。这可确保在维护时段中为 `AWS-RunPatchBaselineWithHooks` 的所有调用使用正确的 ID。 如果在这种情况下您指定值，请注意，补丁基准的快照最多保留 3 天。之后，即使您在快照到期后指定相同的 ID，也将生成新的快照。 |
| 正在在维护时段以外运行 AWS-RunPatchBaselineWithHooks | 为快照 ID¹ 生成和指定自定义 GUID 值。 | 如果您不使用维护时段运行 `AWS-RunPatchBaselineWithHooks`，我们建议您为每个补丁基准生成并指定一个唯一的快照 ID，特别是于同一操作中在多个托管式节点上运行 `AWS-RunPatchBaselineWithHooks` 文档时。如果在这种情况下不指定 ID，Systems Manager 会为向其发送命令的每个托管式节点生成不同的快照 ID。这会导致在节点间指定不同的补丁集。 例如，假设您正在直接通过 Run Command（AWS Systems Manager 中的一项工具）运行 `AWS-RunPatchBaselineWithHooks` 文档，并以一组 50 个的托管式节点为目标。指定自定义快照 ID 将生成单一基准快照，用于评估和修补所有托管式节点，从而确保所有托管式节点最终处于一致状态。 |
| ¹ 您可以使用任何能够生成 GUID 的工具为快照 ID 参数生成值。例如，在 PowerShell 中，可以使用 `New-Guid` cmdlet 生成格式为 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 的 GUID。 |
### 参数名称: `RebootOption`
**用法**：可选。
**选项**：`RebootIfNeeded` \$1 `NoReboot`
**默认值**：`RebootIfNeeded`
**警告**
默认选项是 `RebootIfNeeded`。务必为应用场景选择正确的选项。例如，如果您的托管式节点必须立即重启才能完成配置过程，请选择 `RebootIfNeeded`。或者，如果您需要在计划的重启时间之前保持托管式节点可用，请选择 `NoReboot`。
**重要**
我们不建议使用 Patch Manager 在 Amazon EMR（原 Amazon Elastic MapReduce）中修补集群实例。特别是，不要为 `RebootOption` 参数选择 `RebootIfNeeded` 选项。（此选项在 SSM 命令文档中可用，用于修补 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks`。）
使用 Patch Manager 进行修补的底层命令使用 `yum` 和 `dnf` 命令。因此，由于软件包的安装方式，这些操作会导致不兼容。有关在 Amazon EMR 集群上更新软件的首选方法的信息，请参阅《Amazon EMR Management Guide》**中的 [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)。
RebootIfNeeded
选择 `RebootIfNeeded` 选项时，托管式节点将在以下任一情况下重启：
+ Patch Manager 已安装一个或多个补丁。
Patch Manager 不评估补丁是否*必需*重启。即使补丁不需要重启，系统也会重启。
+ Patch Manager 检测 `Install` 操作期间的一个或多个状态为 `INSTALLED_PENDING_REBOOT` 的补丁。
`INSTALLED_PENDING_REBOOT` 状态可能表示在上次运行 `Install` 操作时选择了选项 `NoReboot`，或者是自上次重新启动托管式节点以来在 Patch Manager 外部安装了补丁。
在这两种情况下重启托管式节点，可确保从内存中刷新更新的软件包，并在所有操作系统中保持修补和重启行为一致。
NoReboot
选择 `NoReboot` 选项时，即使托管式节点在 `Install` 操作期间安装了补丁，Patch Manager 也不会重启托管式节点。如果您知道托管式节点在应用补丁后不需要重启，或者应用程序或进程在节点上运行，但不应因修补操作重启而中断，则此选项有用。当您希望更多地控制托管式节点的重启时间（例如，使用维护时段来控制）时，该选项也很有用。
如果选择 `NoReboot` 选项并安装了补丁，则会为该补丁分配状态 `InstalledPendingReboot`。但托管式节点本身将被标记为 `Non-Compliant`。重启并运行 `Scan` 操作后，节点状态将更新为 `Compliant`。
**补丁安装跟踪文件**：为跟踪补丁安装，特别是自上次系统重启以来安装的补丁，Systems Manager 会在托管式节点上维护一个文件。
**重要**
请勿删除或修改该跟踪文件。如果删除或损坏此文件，托管式节点的补丁合规性报告则不准确。如果发生这种情况，请重启节点并运行补丁扫描操作以还原此文件。
此跟踪文件存储在托管式节点上的以下位置：
+ Linux 操作系统：
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 操作系统:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### 参数名称: `PreInstallHookDocName`
**用法**：可选。
**默认值**：`AWS-Noop`。
要提供的值 `PreInstallHookDocName` 参数是您选择的 SSM 文档的名称或 Amazon Resource Name (ARN)。您可以在中提供 AWS 托管文档的名称，或者您已创建或已与您共享的自定义 SSM 文档的名称或 ARN。（对于来自不同的 AWS 账户 的已与您共享的 SSM 文档，则必须指定完整的资源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。）
指定的 SSM 文档在 `Install` 操作之前运行并执行 SSM Agent 支持的任何操作，例如，在托管式节点上执行修补之前检查应用程序运行状况检查的 shell 脚本。（有关操作列表，请参阅 [命令文档插件参考](documents-command-ssm-plugin-reference.md)）。默认 SSM 文档名称为 `AWS-Noop`，不会对托管式节点执行任何操作。
有关创建自定义 SSM 文档的信息，请参阅 [创建 SSM 文档内容](documents-creating-content.md)。
### 参数名称: `PostInstallHookDocName`
**用法**：可选。
**默认值**：`AWS-Noop`。
要提供的值 `PostInstallHookDocName` 参数是您选择的 SSM 文档的名称或 Amazon Resource Name (ARN)。您可以在中提供 AWS 托管文档的名称，或者您已创建或已与您共享的自定义 SSM 文档的名称或 ARN。（对于来自不同 AWS 账户 的已与您共享的 SSM 文档，必须指定完整资源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。）
在 `Install with NoReboot` 操作之后运行您指定的 SSM 文档，并执行 SSM Agent 支持的任一操作，例如，用于在重启之前安装第三方更新的 shell 脚本。（有关操作列表，请参阅 [命令文档插件参考](documents-command-ssm-plugin-reference.md)）。默认 SSM 文档名称为 `AWS-Noop`，不会对托管式节点执行任何操作。
有关创建自定义 SSM 文档的信息，请参阅 [创建 SSM 文档内容](documents-creating-content.md)。
### 参数名称: `OnExitHookDocName`
**用法**：可选。
**默认值**：`AWS-Noop`。
要提供的值 `OnExitHookDocName` 参数是您选择的 SSM 文档的名称或 Amazon Resource Name (ARN)。您可以在中提供 AWS 托管文档的名称，或者您已创建或已与您共享的自定义 SSM 文档的名称或 ARN。（对于来自不同的 AWS 账户 的已与您共享的 SSM 文档，则必须指定完整的资源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。）
指定的 SSM 文档在托管式节点重启操作后运行并执行 SSM Agent 支持的任何操作，例如，在修补操作完成后验证节点运行状况的 shell 脚本。（有关操作列表，请参阅 [命令文档插件参考](documents-command-ssm-plugin-reference.md)）。默认 SSM 文档名称为 `AWS-Noop`，不会对托管式节点执行任何操作。
有关创建自定义 SSM 文档的信息，请参阅 [创建 SSM 文档内容](documents-creating-content.md)。
# 在 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 中使用 InstallOverrideList 参数的示例场景
当您要在Patch Manager（AWS Systems Manager 中的一项工具）中覆盖由当前默认补丁基准指定的补丁时，可以使用 `InstallOverrideList` 参数。本主题提供示例说明如何使用此参数来实现以下目标：
+ 将不同的补丁集应用于托管式节点目标组。
+ 以不同频率应用这些补丁集。
+ 对这两个操作使用相同的补丁基准。
假设您要在 Amazon Linux 2 托管式节点上安装两种不同类别的补丁。您希望使用维护时段按不同的计划安装这些补丁。您希望每周运行一个维护时段并安装所有 `Security` 补丁。您希望另一个维护时段每月运行一次，并安装所有可用的补丁或 `Security` 之外类别的补丁。
但是，一次只能将一个补丁基准定义为操作系统的默认值。此要求有助于避免一个补丁基准批准补丁而另一个补丁阻止补丁的情况，这种情况可能导致相互冲突的版本之间出现问题。
以下策略允许您使用 `InstallOverrideList` 参数按照不同的计划将不同类型的补丁应用到目标组，同时仍使用相同的补丁基准。
1. 在默认补丁基准中，确保仅指定 `Security` 更新。
1. 创建每周运行 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 的维护时段。不要指定覆盖列表。
1. 创建要每月应用的所有类型的补丁的覆盖列表，并将其存储在 Amazon Simple Storage Service (Amazon S3) 存储桶中。
1. 创建每月运行一次的第二个维护时段。但是，对于您为此维护时段注册的 Run Command 任务，请指定覆盖列表的位置。
结果：每周只安装在默认补丁基准中定义的 `Security` 补丁。每月都会安装所有可用的补丁或您定义的任何补丁子集。
**注意**
当您修补仅使用 IPv6 的节点时，请确保提供的 URL 可从该节点访问。如果将 SSM Agent 配置选项 `UseDualStackEndpoint` 设置为 `true`，则在提供 S3 URL 时将使用双堆栈 S3 客户端。有关将代理配置为使用双堆栈的更多信息，请参阅 [教程：在仅支持 IPv6 的环境中修补服务器](patch-manager-server-patching-iPv6-tutorial.md)。
有关更多信息和示例列表，请参阅 [参数名称: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)。
# 使用基准覆盖参数
您可以在运行时使用Patch Manager（AWS Systems Manager 中的一项工具）中的基准覆盖功能来定义修补首选项。通过指定包含一个带有补丁基准列表的 JSON 对象的 Amazon Simple Storage Service (Amazon S3) 存储桶来实施。该修补操作使用与主机操作系统匹配的 JSON 对象中提供的基准，而不是应用默认补丁基准中的规则。
**重要**
`BaselineOverride` 文件名不能包含以下字符：反引号 (`)、单引号 (')、双引号 (") 和美元符号 (\$1)。
除非补丁操作使用补丁策略，否则使用 `BaselineOverride` 参数不会覆盖参数中提供的基准的补丁合规性。输出结果记录在来自 Run Command（AWS Systems Manager 中的一项工具）的标准输出日志中。结果仅打印标记为 `NON_COMPLIANT` 的软件包。这意味着软件包被标记为 `Missing`、 `Failed`、 `InstalledRejected` 或者 `InstalledPendingReboot`。
但是，当补丁操作使用补丁策略时，系统会传递关联的 S3 存储桶中的覆盖参数，并更新托管式节点的合规性值。有关补丁策略的更多信息，请参阅 [Quick Setup 中的补丁策略配置](patch-manager-policies.md)。
**注意**
当您修补仅使用 IPv6 的节点时，请确保提供的 URL 可从该节点访问。如果将 SSM Agent 配置选项 `UseDualStackEndpoint` 设置为 `true`，则在提供 S3 URL 时将使用双堆栈 S3 客户端。有关将代理配置为使用双堆栈的更多信息，请参阅 [教程：在仅支持 IPv6 的环境中修补服务器](patch-manager-server-patching-iPv6-tutorial.md)。
## 使用快照 ID 的补丁基准覆盖，或者安装覆盖列表参数
在两种情况下，补丁基准覆盖具有值得注意的行为。
**同时使用基准覆盖和快照 ID**
快照 ID 可确保特定修补命令中的所有托管式节点都应用相同的内容。例如，如果您一次修补 1000 个节点，则补丁相同。
当同时使用快照 ID 和补丁基准覆盖时，快照 ID 优先于补丁基准覆盖。仍将使用基准覆盖规则，但只会对其进行评估一次。在前面的示例中，1000 个托管式节点中的补丁仍始终相同。如果在修补操作的中程，您将引用的 S3 存储桶中的 JSON 文件更改为不同的内容，应用的补丁仍将保持不变。这是因为提供了快照 ID。
**同时使用基准覆盖和安装覆盖列表**
您不能同时使用这两个参数。如果提供了两个参数，则修补文档将失败，并且不会在托管式节点上执行任何扫描或安装。
## 代码示例
以下 Python 代码示例说明了如何生成补丁基准覆盖。
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
这将产生类似下面的补丁基准覆盖。
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```
# 补丁基准
本节主题介绍当您在托管式节点上运行 `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) 以获取帮助解决问题。
# 在 Amazon Linux 2 托管式节点上使用 Kernel Live Patching
适用于 Amazon Linux 2 的 Kernel Live Patching 使您能够将安全漏洞和严重错误补丁应用于正在运行的 Linux 内核，而无需重启或中断正在运行的应用程序。这让您能够从改进的服务和应用程序可用性中受益，同时保持基础设施的安全和最新状态。在运行 Amazon Linux 2 的 Amazon EC2 实例、Kernel Live Patching 核心设备和[本地虚拟机](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html)上支持 AWS IoT Greengrass。
有关 Kernel Live Patching 的一般信息，请参阅 *Amazon Linux 2 User Guide* 中的 [Kernel Live Patching on AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html)。
在 Amazon Linux 2 托管式节点上启用 Kernel Live Patching 之后，您可使用Patch Manager（AWS Systems Manager 中的一项工具）将内核实时补丁应用到托管式节点。使用 Patch Manager 是使用节点上的现有 yum 工作流来应用更新的替代方法。
**开始前的准备工作**
要使用 Patch Manager 将内核实时补丁应用到 Amazon Linux 2 托管式节点上，请确保节点基于正确的架构和内核版本。要了解有关信息，请参阅《Amazon EC2 用户指南》**中的[支持的配置和先决条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)。
**Topics**
+ [使用 Patch Manager 的 Kernel Live Patching](#about-klp)
+ [使用 Patch Manager 的 Kernel Live Patching 的原理](#how-klp-works)
+ [使用 Run Command 来启用 Kernel Live Patching](enable-klp.md)
+ [使用 Run Command 应用内核实时补丁](install-klp.md)
+ [使用 Run Command 来关闭 Kernel Live Patching](disable-klp.md)
## 使用 Patch Manager 的 Kernel Live Patching
更新内核版本
应用内核实时补丁更新后，无需重启托管式节点。但是，AWS 为 Amazon Linux 2 内核版本提供内核实时补丁，最长可达其发布后三个月。在三个月期限之后，您必须更新到更高版本的内核才能继续接收内核实时补丁。我们建议使用维护时段至少每三个月一次安排重启节点，以提示内核版本更新。
卸载内核实时补丁
无法使用 Patch Manager 卸载内核实时补丁。相反，您可以关闭 Kernel Live Patching，从而删除所应用的内核实时补丁的 RPM 程序包。有关更多信息，请参阅 [使用 Run Command 来关闭 Kernel Live Patching](disable-klp.md)。
内核合规性
在某些情况下，从当前内核版本的实时补丁安装所有 CVE 补丁可能会使该内核进入与较新内核版本相同的合规性状态。发生这种情况时，较新版本报告为 `Installed`，而托管式节点报告为 `Compliant`。但是，对于较新的内核版本，不会报告安装时间。
一个内核实时补丁，多个 CVE
如果一个内核实时补丁解决多个 CVE，并且这些 CVE 具有各种分类和严重性值，则只针对该补丁报告 CVE 中的最高分类和严重性。
本节的其余部分介绍如何使用 Patch Manager 将内核实时补丁应用于满足这些要求的托管式节点。
## 使用 Patch Manager 的 Kernel Live Patching 的原理
AWS 为 Amazon Linux 2 发布了两种类型的内核实时补丁：安全更新和错误修复。要应用这些补丁类型，请使用仅针对下表列出的分类和严重性的补丁基准文档。
| 分类 | 严重性 |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
您可以创建仅针对这些补丁的自定义补丁基准，也可以使用预定义的 `AWS-AmazonLinux2DefaultPatchBaseline` 补丁基准。换句话说，您可以将 `AWS-AmazonLinux2DefaultPatchBaseline` 与启用 Kernel Live Patching 的 Amazon Linux 2 托管式节点一起使用，并且系统会应用内核实时更新。
**注意**
`AWS-AmazonLinux2DefaultPatchBaseline` 配置指定发布最后更新补丁后的 7 天等待期，然后才会自动安装补丁。如果您不想等待 7 天再自动批准内核实时补丁，则可以创建并使用自定义补丁基准。在补丁基准中，您可以不指定自动批准等待期，也可以指定较短或更长的等待期。有关更多信息，请参阅 [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)。
我们建议使用以下策略通过内核实时更新来修补托管式节点：
1. 在 Amazon Linux 2 托管式节点上启用 Kernel Live Patching。
1. 使用 Run Command（AWS Systems Manager 中的一项工具）在托管式节点上运行 `Scan` 操作，这些节点使用预定义 `AWS-AmazonLinux2DefaultPatchBaseline` 或自定义补丁基准，该基准也仅针对严重性分类为 `Critical` 和 `Important`，以及 `All` 的严重性为 `Bugfix` 的 `Security` 更新。
1. 使用 Compliance（AWS Systems Manager 中的一项工具）查看是否报告了任何被扫描托管式节点中存在不符合修补合规性的情况。如果是这样，请查看节点合规性详细信息，以确定托管式节点中是否缺少任何内核实时补丁。
1. 要安装缺少的内核实时补丁，请将 Run Command 与之前指定的相同补丁基准一起使用，但这次运行 `Install` 操作而不是 `Scan` 操作。
由于无需重启即可安装内核实时补丁，因此您可以为此操作选择 `NoReboot` 重启选项。
**注意**
如果托管式节点上安装的其他类型补丁需要，或者要更新到较新的内核，您仍然可以重启托管式节点。在这些情况下，请改为选择 `RebootIfNeeded` 重启选项。
1. 返回到合规性以验证安装了内核实时补丁。
# 使用 Run Command 来启用 Kernel Live Patching
要启用 Kernel Live Patching，您可以在托管式节点上运行 `yum` 命令，或使用 Run Command 以及您创建的自定义 Systems Manager 文档（SSM 文档）。
有关通过直接在托管式节点上运行 `yum` 命令来打开 Kernel Live Patching 的信息，请参阅《Amazon EC2 用户指南》**中的[启用 Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)。
**注意**
当您启用内核实时修补时，如果已在托管式节点上运行的内核为比 `kernel-4.14.165-131.185.amzn2.x86_64`（支持的最低版本）*更早*，进程将安装最新的可用内核版本并重启托管式节点。如果节点已运行 `kernel-4.14.165-131.185.amzn2.x86_64` 或更高版本，进程不会安装更新的版本，也不会重启节点。
**使用 Run Command 来启用 Kernel Live Patching (控制台)**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，选择 **Run Command**。
1. 选择 **Run command（运行命令）**。
1. 在**命令文档**列表中，选择自定义 SSM 文档 `AWS-ConfigureKernelLivePatching`。
1. 在 **Command parameters**（命令参数）部分中，指定是否希望作为此操作的一部分重启托管式节点。
1. 有关使用此页上的其余控件的信息，请参阅 [从控制台运行命令](running-commands-console.md)。
1. 选择**运行**。
**启用 Kernel Live Patching (AWS CLI)**
+ 在本地计算机上运行以下命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--parameters "EnableOrDisable=Enable" \
--targets "Key=instanceids,Values=instance-id"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--parameters "EnableOrDisable=Enable" ^
--targets "Key=instanceids,Values=instance-id"
```
------
将 *instance-id* 替换为要启用该功能的 Amazon Linux 2 托管式节点的 ID，例如 i-02573cafcfEXAMPLE。您可以使用以下任一格式，在多个托管式节点上启用该功能。
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
有关可以在命令中使用的其他选项的信息，请参阅《AWS CLI Command Reference》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)。
# 使用 Run Command 应用内核实时补丁
要应用内核实时补丁，您可以在托管式节点上运行 `yum` 命令，也可以使用 Run Command 和 SSM 文档 `AWS-RunPatchBaseline`。
有关通过在托管式节点上直接运行 `yum` 命令来应用内核实时补丁的信息，请参阅《Amazon EC2 用户指南》**中的[应用内核实时补丁](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply)。
**使用 Run Command 应用内核实时补丁（控制台）**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，选择 **Run Command**。
1. 选择 **Run command（运行命令）**。
1. 在**命令文档**列表中，请选择 SSM 文档 `AWS-RunPatchBaseline`。
1. 在 **Command parameters ( 命令参数)** 部分，执行以下操作之一：
+ 如果要检查是否有新的内核实时补丁，请对于 **Operation (操作)** 选择 `Scan`。对于 **Reboot Option**（重启选项），如果不希望托管式节点在此操作后重启，请选择 `NoReboot`。操作完成后，您可以在合规性中检查新的补丁和合规性状态。
+ 如果您已经检查了补丁合规性，并准备好应用可用的内核实时补丁，请对于 **Operation (操作)** 选择 `Install`。对于 **Reboot Option**（重启选项），如果不希望托管式节点在此操作后重启，请选择 `NoReboot`。
1. 有关使用此页上的其余控件的信息，请参阅 [从控制台运行命令](running-commands-console.md)。
1. 选择**运行**。
**使用 Run Command (AWS CLI) 应用内核实时补丁**
1. 要在合规性检查结果出来之前执行 `Scan` 操作，请从本地计算机运行以下命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
```
------
有关可以在命令中使用的其他选项的信息，请参阅《AWS CLI Command Reference》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)。
1. 要在合规性检查结果出来之后执行 `Install` 操作，请从本地计算机运行以下命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
```
------
在上述两个命令中，将 *instance-id* 替换为要应用内核实时补丁的 Amazon Linux 2 托管式节点的 ID，例如 i-02573cafcfEXAMPLE。您可以使用以下任一格式，在多个托管式节点上启用该功能。
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
有关可以在这些命令中使用的其他选项的信息，请参阅《AWS CLI Command Reference》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)。
# 使用 Run Command 来关闭 Kernel Live Patching
要关闭 Kernel Live Patching，您可以在托管式节点上运行 `yum` 命令，也可以使用 Run Command 以及自定义 SSM 文档 `AWS-ConfigureKernelLivePatching`。
**注意**
如果您不再需要使用内核实时修补，可以随时关闭它。在大多数情况下，不需要关闭该功能。
有关通过直接在托管式节点上运行 `yum` 命令来关闭 Kernel Live Patching 的信息，请参阅《Amazon EC2 用户指南》**中的[启用 Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable)。
**注意**
关闭 Kernel Live Patching 时，该进程会卸载 Kernel Live Patching 插件，然后重启托管式节点。
**使用 Run Command 来关闭 Kernel Live Patching (控制台)**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，选择 **Run Command**。
1. 选择 **Run command（运行命令）**。
1. 在**命令文档** 列表中，请选择 SSM 文档 `AWS-ConfigureKernelLivePatching`。
1. 在 **Command parameters (命令参数)** 部分中，为必需的参数指定值。
1. 有关使用此页上的其余控件的信息，请参阅 [从控制台运行命令](running-commands-console.md)。
1. 选择**运行**。
**关闭 Kernel Live Patching (AWS CLI)**
+ 运行类似于下面的命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--targets "Key=instanceIds,Values=instance-id" \
--parameters "EnableOrDisable=Disable"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--targets "Key=instanceIds,Values=instance-id" ^
--parameters "EnableOrDisable=Disable"
```
------
将 *instance-id* 替换为要关闭该功能的 Amazon Linux 2 托管式节点的 ID，例如 i-02573cafcfEXAMPLE。要在多个托管式节点上关闭该功能，您可以使用以下任一格式。
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
有关可以在命令中使用的其他选项的信息，请参阅《AWS CLI Command Reference》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)。
# 使用控制台处理 Patch Manager 资源和合规性
要使用Patch Manager（AWS Systems Manager 中的一项工具），请完成以下任务。此部分更详细地说明了这些任务。
1. 验证您使用的每个操作系统类型的 AWS 预定义的补丁基准是否符合您的需求。如果不符合，则为该托管式节点类型创建定义一组标准补丁的补丁基准，并将其设置为默认值。
1. 使用 Amazon Elastic Compute Cloud (Amazon EC2) 标签将托管节点整理到补丁组中（可选，但建议执行）。
1. 请执行以下操作之一：
+ （推荐）在Quick Setup（Systems Manager 中的一项工具）中配置补丁策略让您可以按计划为整个组织、部分组织单位或单个 AWS 账户安装缺失的补丁。有关更多信息，请参阅 [使用 Quick Setup 补丁策略为组织中的实例配置修补](quick-setup-patch-manager.md)。
+ 在 Run Command 任务类型中，创建使用 Systems Manager 文档（SSM 文档）`AWS-RunPatchBaseline` 的维护时段。有关更多信息，请参阅 [教程：使用控制台创建修补的维护时段](maintenance-window-tutorial-patching.md)。
+ 在 Run Command 操作中，手动运行 `AWS-RunPatchBaseline`。有关更多信息，请参阅 [从控制台运行命令](running-commands-console.md)。
+ 使用 **Patch now**（立即修补）功能按需手动修补节点。有关更多信息，请参阅 [按需修补托管式节点](patch-manager-patch-now-on-demand.md)。
1. 监视修补以验证合规性和调查故障。
**Topics**
+ [创建补丁策略](patch-manager-create-a-patch-policy.md)
+ [查看补丁程序控制面板摘要](patch-manager-view-dashboard-summaries.md)
+ [使用补丁合规性报告](patch-manager-compliance-reports.md)
+ [按需修补托管式节点](patch-manager-patch-now-on-demand.md)
+ [使用补丁基准](patch-manager-create-a-patch-baseline.md)
+ [查看可用的补丁](patch-manager-view-available-patches.md)
+ [创建和管理补丁组](patch-manager-tag-a-patch-group.md)
+ [将 Patch Manager 与 AWS Security Hub CSPM 集成](patch-manager-security-hub-integration.md)
# 创建补丁策略
补丁策略是您使用Quick Setup（AWS Systems Manager 中的一项工具）设置的一项配置。与其他配置修补的方法相比，补丁策略可以对补丁操作进行更广泛、更集中的控制。补丁策略定义了自动修补节点和应用程序时使用的计划和基准。
有关更多信息，请参阅以下主题：
+ [Quick Setup 中的补丁策略配置](patch-manager-policies.md)
+ [使用 Quick Setup 补丁策略为组织中的实例配置修补](quick-setup-patch-manager.md)
# 查看补丁程序控制面板摘要
Patch Manager中的**控制面板**选项卡在控制台中提供一个摘要视图，可用于在统一视图中监控修补操作。Patch Manager是 AWS Systems Manager 中的一项工具。在**控制面板**选项卡上，您可以查看以下内容：
+ 有多少托管式节点符合和不符合修补规则的快照。
+ 托管式节点补丁合规性结果的时间快照。
+ 对于每种最常见的不合规原因，有多少不合规的托管式节点链接计数。
+ 最近修补操作的链接列表。
+ 已设置的定期修补任务的链接列表。
**查看补丁控制面板摘要**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**控制面板**选项卡。
1. 滚动到包含要查看的摘要数据的部分：
+ **Amazon EC2 实例管理**
+ **合规性摘要**
+ **不合规问题计数**
+ **合规性报告**
+ **基于非补丁策略的操作**
+ **基于非补丁策略的重复任务**
# 使用补丁合规性报告
使用以下主题中的信息帮助您Patch Manager（AWS Systems Manager 中的一项工具）中生成和使用补丁合规性报告。
无论您使用哪种配置方法或类型进行修补操作，以下主题中的信息都适用：
+ Quick Setup 中配置的补丁策略
+ Quick Setup 中配置的主机管理选项
+ 运行补丁 `Scan` 或 `Install` 任务的维护时段
+ 按需 **Patch now**（立即修补）操作
**重要**
补丁合规性报告是仅在成功进行修补操作后生成的特定时间点快照。每个报告都包含一个捕获时间，用于标识合规性状态的计算时间。
如果您用多种操作来扫描实例的补丁合规性，请注意每次扫描都会覆盖先前扫描的补丁合规性数据。作为结果，您最终可能会导致补丁合规性数据中产生意外结果。有关更多信息，请参阅 [识别创建补丁合规性数据的执行](patch-manager-compliance-data-overwrites.md)。
要验证使用哪个补丁基准来生成最新的合规性信息，请导航到 Patch Manager 中的**合规性报告**选项卡，找到要了解的托管节点行，然后在**使用的基准 ID** 列中选择基准 ID。
**Topics**
+ [查看补丁合规性结果](patch-manager-view-compliance-results.md)
+ [生成 .csv 补丁合规性报告](patch-manager-store-compliance-results-in-s3.md)
+ [使用 Patch Manager 修复不合规的托管式节点](patch-manager-noncompliant-nodes.md)
+ [识别创建补丁合规性数据的执行](patch-manager-compliance-data-overwrites.md)
# 查看补丁合规性结果
使用这些过程可查看有关托管式节点的补丁合规性信息。
此过程适用于使用 `AWS-RunPatchBaseline` 文档的补丁操作。查看有关使用 `AWS-RunPatchBaselineAssociation` 文档进行补丁操作的补丁合规性信息的信息，请参阅 [标识不合规的托管式节点](patch-manager-find-noncompliant-nodes.md)。
**注意**
Quick Setup和 Explorer 的补丁扫描操作使用 `AWS-RunPatchBaselineAssociation` 文档。Quick Setup和 Explorer 都是 AWS Systems Manager 中的工具。
**确定针对特定 CVE 问题的补丁解决方案 (Linux)**
对于许多基于 Linux 的操作系统，补丁合规性结果表明哪些常见漏洞和暴露 (CVE) 公告问题是通过哪些补丁来解决的。此信息可帮助您确定需要安装丢失或失败的补丁的紧迫程度。
受支持的以下操作系统的类型版本中包含 CVE 详细信息：
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**注意**
默认情况下，CentOS Stream 不提供有关更新的 CVE 信息。但是，您可以使用 Fedora 发布的 Extra Packages for Enterprise Linux (EPEL) 存储库等第三方存储库来允许这种支持。想要了解有关信息，请参阅 Fedora 维基词条中的 [EPEL](https://fedoraproject.org/wiki/EPEL)。
目前，仅报告状态为 `Missing` 或 `Failed` 的补丁的 CVE ID 值。
您还可以根据情况和修补目标的需要，将 CVE ID 添加到补丁基准中已批准或已拒绝的补丁列表中。
有关使用已批准和已拒绝的补丁列表的信息，请参阅以下主题：
+ [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)
+ [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)
+ [补丁基准规则在基于 Linux 的系统上的工作原理](patch-manager-linux-rules.md)
+ [如何安装补丁](patch-manager-installing-patches.md)
**注意**
在某些情况下，Microsoft 会为未指定更新日期和时间的应用程序发布补丁。在这些情况下，系统会默认提供 `01/01/1970` 的更新日期和时间。
## 查看补丁合规性结果
使用以下过程在 AWS Systems Manager 控制台中查看合规性数据。
**注意**
有关生成下载到 Amazon Simple Storage Service (Amazon S3) 存储桶的补丁合规性报告的信息，请参阅 [生成 .csv 补丁合规性报告](patch-manager-store-compliance-results-in-s3.md)。
**查看补丁合规性结果**
1. 请执行以下操作之一。
**选项 1**（推荐）：从Patch Manager（AWS Systems Manager 中的一项工具）中导航：
+ 在导航窗格中，请选择 **Patch Manager**。
+ 选择 **Compliance reporting**（合规性报告）选项卡。
+ 在**节点修补详细信息**区域中，选择要查看其补丁合规性结果的托管式节点 ID。此处将不会显示处于 `stopped` 或 `terminated` 状态的节点。
+ 在**详细信息**区域的**属性**列表中，选择**补丁**。
**选项 2**：从 Compliance（AWS Systems Manager 中的一项工具）中导航：
+ 在导航窗格中，选择 **合规性**。
+ 适用于**合规性资源摘要**，请在列中为要查看的补丁资源类型选择一个数字，例如**不合规资源**。
+ 在下面的**资源**列表中，选择要查看其补丁合规性结果的托管式节点的 ID。
+ 在**详细信息**区域的**属性**列表中，选择**补丁**。
**选项 3**：从 Fleet Manager（AWS Systems Manager 中的一项工具）中导航：
+ 在导航窗格中，请选择 **Fleet Manager**。
+ 在**托管式实例**区域中，选择要查看其补丁合规性结果的托管式节点的 ID。
+ 在**详细信息**区域的**属性**列表中，选择**补丁**。
1. （可选）在搜索框 (![\[The Search icon\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/images/search-icon.png)）中，从可用筛选器中选择。
例如，对于 Red Hat Enterprise Linux (RHEL)，从以下选项中进行选择：
+ 名称
+ 分类
+ 州
+ 严重性
对于 Windows Server，从以下选项中进行选择：
+ KB
+ 分类
+ 州
+ 严重性
1. 为您选择的筛选器类型选择一个可用值。例如，如果您选择了**状态**，现在选择一个合规性状态，例如**已安装待定重启**、**已失败**或者**缺少**。
**注意**
目前，仅报告状态为 `Missing` 或 `Failed` 的补丁的 CVE ID 值。
1. 根据托管式节点的合规性状态，您可以选择采取哪些操作来补救任何不合规的节点。
例如，您可以选择立即修补不合规托管式节点。有关按需修补托管式节点的信息，请参阅 [按需修补托管式节点](patch-manager-patch-now-on-demand.md)。
有关补丁合规性数据的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
# 生成 .csv 补丁合规性报告
您可以使用 AWS Systems Manager 控制台来生成补丁合规性报告，这些报告将以 .csv 文件格式另存到您选择的 Amazon Simple Storage Service (Amazon S3) 存储桶。您可以生成单个按需报告或制定自动生成报告的计划。
可以在所选择的 AWS 账户 和 AWS 区域 中为单个托管式节点或所有托管式节点生成报告。对于单个节点，报告包含全面的详细信息，包括与不合规节点相关的补丁 ID。对于所有托管式节点的报告，仅提供摘要信息和不合规节点的补丁计数。
生成报告后，您可以使用 Amazon Quick 等工具导入和分析数据。Quick 是一项商业智能（BI）服务，可用于在交互式视觉环境中浏览和解读信息。有关更多信息，请参阅 [Amazon Quick 用户指南](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html)。
**注意**
创建自定义补丁基准时，您可以为此补丁基准批准的补丁指定合规性严重性级别，例如 `Critical` 或 `High`。如果任何已批准补丁的补丁状态报告为 `Missing`，则补丁基准报告的总体合规性严重性级别就是您指定的严重级别。
也可以指定一个在生成报告时发送通知的 Amazon Simple Notification Service (Amazon SNS) 主题。
**生成补丁合规性报告的服务角色**
首次生成报告时，Systems Manager 会创建名为 `AWS-SystemsManager-PatchSummaryExportRole` 的自动化担任角色，用于导出到 S3 的过程。
**注意**
如果您要将合规性数据导出到加密的 S3 存储桶，则必须更新其关联的 AWS KMS 密钥政策以为 `AWS-SystemsManager-PatchSummaryExportRole` 提供必要的权限。例如，将与此类似的权限添加到 S3 存储桶的 AWS KMS 策略中：
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
将 *role-arn* 替换为账户中创建的 Amazon 资源名称（ARN），格式为 `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`。
有关更多信息，请参阅《*AWS Key Management Service 开发人员指南*》中的[在 AWS KMS 中使用密钥策略](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)。
首次按计划生成报告时，Systems Manager 会创建另一个名为 `AWS-EventBridge-Start-SSMAutomationRole` 的另一个服务角色，以及服务角色 `AWS-SystemsManager-PatchSummaryExportRole`（如果尚未创建）以用于导出过程。`AWS-EventBridge-Start-SSMAutomationRole` 使 Amazon EventBridge 能够使用运行手册[AWS-导出补丁报告到 S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) 来启动自动化。
我们建议不要尝试修改这些策略和角色。这样做可能会导致补丁合规性报告生成失败。有关更多信息，请参阅 [解决补丁合规性报告生成中的问题](#patch-compliance-reports-troubleshooting)。
**Topics**
+ [生成的补丁合规性报告中有哪些内容？](#patch-compliance-reports-to-s3-examples)
+ [为单个托管式节点生成补丁合规性报告](#patch-compliance-reports-to-s3-one-instance)
+ [为所有托管式节点生成补丁合规性报告](#patch-compliance-reports-to-s3-all-instances)
+ [查看补丁合规性报告历史](#patch-compliance-reporting-history)
+ [查看补丁合规性报告计划](#patch-compliance-reporting-schedules)
+ [解决补丁合规性报告生成中的问题](#patch-compliance-reports-troubleshooting)
## 生成的补丁合规性报告中有哪些内容？
本主题提供有关生成并下载到指定 S3 存储桶的补丁合规性报告中包含的内容类型的信息。
### 单个托管式节点的报告格式
为单个托管式节点生成的报告提供摘要信息和详细信息。
[下载示例报告（单个节点）](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
单个托管式节点的摘要信息包括以下内容：
+ 索引
+ 实例 ID
+ 实例名称
+ 实例 IP
+ 平台名称
+ 平台版本
+ SSM Agent 版本
+ 补丁基准
+ 补丁组
+ 合规性状态
+ 合规性严重性
+ 不合规的重大严重性补丁计数
+ 不合规的高严重性补丁计数
+ 不合规的中等严重性补丁计数
+ 不合规的低严重性补丁计数
+ 不合规的信息严重性补丁计数
+ 不合规的未指定严重性补丁计数
单个托管式节点的详细信息包括以下内容：
+ 索引
+ 实例 ID
+ 实例名称
+ 补丁名称
+ KB ID/补丁 ID
+ 修补状态
+ 上次报告时间
+ 合规级别
+ 补丁严重性
+ 补丁分类
+ CVE ID
+ 补丁基准
+ 日志 URL
+ 实例 IP
+ 平台名称
+ 平台版本
+ SSM Agent 版本
**注意**
创建自定义补丁基准时，您可以为此补丁基准批准的补丁指定合规性严重性级别，例如 `Critical` 或 `High`。如果任何已批准补丁的补丁状态报告为 `Missing`，则补丁基准报告的总体合规性严重性级别就是您指定的严重级别。
### 所有托管式节点的报告格式
为所有托管式节点生成的报告仅提供摘要信息。
[下载示例报告（所有托管式节点）](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
所有托管式节点的摘要信息包括以下内容：
+ 索引
+ 实例 ID
+ 实例名称
+ 实例 IP
+ 平台名称
+ 平台版本
+ SSM Agent 版本
+ 补丁基准
+ 补丁组
+ 合规性状态
+ 合规性严重性
+ 不合规的重大严重性补丁计数
+ 不合规的高严重性补丁计数
+ 不合规的中等严重性补丁计数
+ 不合规的低严重性补丁计数
+ 不合规的信息严重性补丁计数
+ 不合规的未指定严重性补丁计数
## 为单个托管式节点生成补丁合规性报告
在 AWS 账户 中使用以下过程为单个托管式节点生成补丁摘要报告。单个托管式节点的报告提供有关每个不合规补丁的详细信息，包括补丁名称和 ID。
**为单个托管式节点生成补丁合规性报告**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择 **Compliance reporting**（合规性报告）选项卡。
1. 选择要为其生成报告的托管式节点所在行的按钮，然后选择 **View detail**（查看详细信息）。
1. 在 **Patch summary**（补丁摘要）部分中，选择 **Export to S3**（导出到 S3）。
1. 对于**报告名称**，输入名称以帮助您以后识别该报告。
1. 对于**报告频率**，选择下列选项之一：
+ **按需** — 创建一次性报告。跳至步骤 9。
+ **按计划** — 指定自动生成报告的定期计划。继续执行步骤 8。
1. 对于**计划类型**，请指定速率表达式（如每 3 天），或者提供 cron 表达式来设置报告频率。
有关 Cron 表达式的更多信息，请参阅 [参考：适用于 Systems Manager 的 Cron 和 Rate 表达式](reference-cron-and-rate-expressions.md)。
1. 对于于 **Bucket name**，选择要存储 .csv 报告文件的 S3 存储桶的名称。
**重要**
如果您处于 2019 年 3 月 20 日之后启动的 AWS 区域 中，则必须在该区域选择 S3 存储桶。默认情况下，在该日期之后启动的区域会被关闭。有关这些区域的详细信息和列表，请参阅《Amazon Web Services 一般参考》**中的 [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)。
1. （可选）要在报告生成时发送通知，请展开 **SNS topic**（SNS 主题）部分，然后从 **SNS topic Amazon Resource Name (ARN)** [SNS 主题的 Amazon Resource Name (ARN)] 中选择一个现存的 Amazon SNS 主题。
1. 选择**提交**。
有关查看生成报告的历史记录的信息，请参阅 [查看补丁合规性报告历史](#patch-compliance-reporting-history)。
有关查看已创建的报告计划详细信息的信息，请参阅 [查看补丁合规性报告计划](#patch-compliance-reporting-schedules)。
## 为所有托管式节点生成补丁合规性报告
在 AWS 账户 中使用以下过程为所有托管式节点生成补丁摘要报告。所有托管式节点的报告会指明哪些节点不合规以及不合规补丁的数量。它不提供补丁的名称或其他标识符。对于这些额外详细信息，您可以为单个托管式节点生成补丁合规性报告。有关更多信息，请参阅本主题前面的 [为单个托管式节点生成补丁合规性报告](#patch-compliance-reports-to-s3-one-instance)。
**为所有托管式节点生成补丁合规性报告**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择 **Compliance reporting**（合规性报告）选项卡。
1. 选择**导出到 S3**。（不要先选择节点 ID。）
1. 对于**报告名称**，输入名称以帮助您以后识别该报告。
1. 对于**报告频率**，选择下列选项之一：
+ **按需** — 创建一次性报告。跳至步骤 8。
+ **按计划** — 指定自动生成报告的定期计划。继续执行步骤 7。
1. 对于**计划类型**，请指定速率表达式（如每 3 天），或者提供 cron 表达式来设置报告频率。
有关 Cron 表达式的更多信息，请参阅 [参考：适用于 Systems Manager 的 Cron 和 Rate 表达式](reference-cron-and-rate-expressions.md)。
1. 对于于 **Bucket name**，选择要存储 .csv 报告文件的 S3 存储桶的名称。
**重要**
如果您处于 2019 年 3 月 20 日之后启动的 AWS 区域 中，则必须在该区域选择 S3 存储桶。默认情况下，在该日期之后启动的区域会被关闭。有关这些区域的详细信息和列表，请参阅《Amazon Web Services 一般参考》**中的 [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)。
1. （可选）要在报告生成时发送通知，请展开 **SNS topic**（SNS 主题）部分，然后从 **SNS topic Amazon Resource Name (ARN)** [SNS 主题的 Amazon Resource Name (ARN)] 中选择一个现存的 Amazon SNS 主题。
1. 选择**提交**。
有关查看生成报告的历史记录的信息，请参阅 [查看补丁合规性报告历史](#patch-compliance-reporting-history)。
有关查看已创建的报告计划详细信息的信息，请参阅 [查看补丁合规性报告计划](#patch-compliance-reporting-schedules)。
## 查看补丁合规性报告历史
使用本主题中的信息帮助您查看有关 AWS 账户 中生成的补丁合规性报告的详细信息。
**查看补丁合规性报告历史**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择 **Compliance reporting**（合规性报告）选项卡。
1. 选择**查看所有 S3 导出**，然后选择**导出历史记录**选项卡。
## 查看补丁合规性报告计划
使用本主题中的信息帮助您查看在 AWS 账户 中生成的补丁合规性报告历史的详细信息。
**查看补丁合规性报告历史**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择 **Compliance reporting**（合规性报告）选项卡。
1. 选择 **View all S3 exports**（查看所有 S3 导出），然后选择 **Report schedule rules**（报告计划规则）选项卡。
## 解决补丁合规性报告生成中的问题
利用以下信息，帮助排查Patch Manager（AWS Systems Manager 中的一项工具）中有关生成补丁合规性报告的问题。
**Topics**
+ [报告 `AWS-SystemsManager-PatchManagerExportRolePolicy` 策略已损坏的消息](#patch-compliance-reports-troubleshooting-1)
+ [在删除补丁合规性策略或角色后，未成功按照计划生成报告](#patch-compliance-reports-troubleshooting-2)
### 报告 `AWS-SystemsManager-PatchManagerExportRolePolicy` 策略已损坏的消息
**问题**：您收到类似于以下内容的错误消息，指示 `AWS-SystemsManager-PatchManagerExportRolePolicy` 已损坏：
```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any
role that uses it, then try again. Systems Manager recreates the roles and policies
you have deleted.
```
+ **解决方案**：在生成新的补丁合规性报告之前，使用 Patch Manager 控制台或 AWS CLI 删除受影响的角色和策略。
**使用控制台删除损坏的策略**
1. 访问：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)，打开 IAM 控制台
1. 请执行以下操作之一：
**按需报告** — 如果在生成一次性按需报告时出现问题，请在左侧导航栏中选择**策略**，搜索 `AWS-SystemsManager-PatchManagerExportRolePolicy`，然后删除该策略。下一步，选择**角色**，搜索 `AWS-SystemsManager-PatchSummaryExportRole`，然后删除该角色。
**计划报告**：如果在按计划生成报告时出现问题，请在左侧导航栏中选择**策略**，一次搜索一个 `AWS-EventBridge-Start-SSMAutomationRolePolicy` 和 `AWS-SystemsManager-PatchManagerExportRolePolicy`，然后删除每个策略。下一步，选择**角色**，一次搜索一个 `AWS-EventBridge-Start-SSMAutomationRole` 和 `AWS-SystemsManager-PatchSummaryExportRole`，然后删除每个角色。
**使用 AWS CLI 删除损坏的策略**
请将*占位符值*替换为账户 ID。
+ 如果在生成一次性按需报告时出现问题，请运行以下命令：
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
如果在按计划生成报告时出现问题，请运行以下命令：
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
```
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
完成任一过程后，按照以下步骤生成或计划新的补丁合规性报告。
### 在删除补丁合规性策略或角色后，未成功按照计划生成报告
**问题**：首次生成报告时，Systems Manager 会创建一个服务角色和一个策略，用于导出过程 (`AWS-SystemsManager-PatchSummaryExportRole` 和 `AWS-SystemsManager-PatchManagerExportRolePolicy`)。首次按计划生成报告时，Systems Manager 会创建另一个服务角色和策略 (`AWS-EventBridge-Start-SSMAutomationRole` 和 `AWS-EventBridge-Start-SSMAutomationRolePolicy`)。这些功能让 Amazon EventBridge 使用运行手册启动自动化 [AWS 导出补丁报告到 S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3)。
如果您删除这些策略或角色中的任何一个，则计划与指定的 S3 存储桶和 Amazon SNS 主题之间的连接可能会丢失。
+ **解决方案**：若要变通解决此问题，我们建议删除以前的计划，并创建一个新的计划来替换遇到问题的计划。
# 使用 Patch Manager 修复不合规的托管式节点
本节中的主题概述了如何标识不符合补丁合规性要求的托管式节点以及如何使节点合规。
**Topics**
+ [标识不合规的托管式节点](patch-manager-find-noncompliant-nodes.md)
+ [补丁合规性状态值](patch-manager-compliance-states.md)
+ [修补不合规的托管式节点](patch-manager-compliance-remediation.md)
# 标识不合规的托管式节点
当运行两个 AWS Systems Manager 文档（SSM 文档）中的其中一个文档时，会标识不合规的托管式节点。这些 SSM 文档引用了Patch Manager（AWS Systems Manager 中的一项工具）中每个托管式节点相应的补丁基准。然后，这些文档会评估托管式节点的补丁状态，并向您提供合规性结果。
有两个 SSM 文档用于标识或更新不合规的托管式节点：`AWS-RunPatchBaseline` 和 `AWS-RunPatchBaselineAssociation`。每个文档的使用流程不同，其合规性结果通过不同的渠道提供。下表概述了这些文档之间的差异。
**注意**
来自 Patch Manager 的补丁合规性数据可以发送到 AWS Security Hub CSPM。Security Hub CSPM 能让您全面了解高优先级安全警报和合规性状态。它还监控您的实例集的修补状态。有关更多信息，请参阅 [将 Patch Manager 与 AWS Security Hub CSPM 集成](patch-manager-security-hub-integration.md)。
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| 使用文档的过程 | **按需修补** – 您可以使用 **Patch now**（立即修补）选项按需扫描或修补托管式节点。有关信息，请参阅[按需修补托管式节点](patch-manager-patch-now-on-demand.md)。 **Systems Manager Quick Setup补丁策略**：您可以在Quick Setup（AWS Systems Manager 中的一项工具）中创建修补配置，可针对整个组织、部分组织单位或单个 AWS 账户按不同的计划扫描或安装缺失的补丁。有关信息，请参阅[使用 Quick Setup 补丁策略为组织中的实例配置修补](quick-setup-patch-manager.md)。 **运行命令**：在 Run Command（AWS Systems Manager 中的一项工具）的操作中，您可以手动运行 `AWS-RunPatchBaseline`。有关信息，请参阅[从控制台运行命令](running-commands-console.md)。 **维护时段** – 在 Run Command 任务类型中，您可以使用 SSM 文档 `AWS-RunPatchBaseline` 创建维护时段。有关信息，请参阅[教程：使用控制台创建修补的维护时段](maintenance-window-tutorial-patching.md)。 | **Systems Manager Quick Setup 主机管理**：您可以在 Quick Setup 中启用主机管理配置选项，每天扫描您的托管实例的补丁合规性。有关信息，请参阅[使用 Quick Setup 设置 Amazon EC2 主机管理](quick-setup-host-management.md)。 **Systems Manager [Explorer](Explorer.md)**：只要允许 Explorer（AWS Systems Manager 中的一项工具），该工具就会定期扫描托管式实例来了解补丁合规性，并会在 Explorer 控制面板中报告结果。 |
| 补丁扫描结果数据的格式 | 在 `AWS-RunPatchBaseline` 运行后，Patch Manager会将 `AWS:PatchSummary` 对象发送至 Inventory（AWS Systems Manager 中的一项工具）。此报告仅在成功完成修补操作后生成，并且包含用于标识合规性状态计算时间的捕获时间。 | 在 `AWS-RunPatchBaselineAssociation` 运行后，Patch Manager 发送 `AWS:ComplianceItem` 对象至 Systems Manager 库存。 |
| 在控制台中查看补丁合规性报告 | 您可以查看使用 [Systems Manager 配置合规性](systems-manager-compliance.md)中的 `AWS-RunPatchBaseline` 和 [使用托管式节点](fleet-manager-managed-nodes.md) 进程的补丁合规性信息。有关更多信息，请参阅 [查看补丁合规性结果](patch-manager-view-compliance-results.md)。 | 如果您使用 Quick Setup 扫描托管实例的补丁合规性，您可以在 [Systems Manager Fleet Manager](fleet-manager.md) 中查看合规性报告。在 Fleet Manager 控制台中，选择托管式节点的节点 ID。在**常规**菜单中，选择**配置合规性**。 如果您将Explorer 扫描托管实例的补丁合规性，您可以在 Explorer 和 [Systems Manager OpsCenter](OpsCenter.md) 中查看合规性报告。 |
| 查看补丁合规性结果的 AWS CLI 命令 | 对于使用 `AWS-RunPatchBaseline` 的进程，您可以使用以下 AWS CLI 命令查看有关托管式节点上的补丁的摘要信息。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | 对于使用 `AWS-RunPatchBaselineAssociation` 的进程，您可以使用以下 AWS CLI 命令查看有关实例补丁的摘要信息。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| 修补操作 | 对于使用 `AWS-RunPatchBaseline` 的进程，可以指定是否仅希望该操作运行 `Scan` 操作，或者 `Scan and install` 操作。 如果您的目标是标识而非修复不合规的托管式节点，则仅运行 `Scan` 操作。 | Quick Setup 和 Explorer 进程，使用 AWS-RunPatchBaselineAssociation，请仅运行 Scan 操作。 |
| 更多信息 | [用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [用于修补的 SSM 命令文档：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
有关您可能看到报告的各种补丁合规性状态的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)
有关修复不符合补丁合规性要求的托管式节点的信息，请参阅 [修补不合规的托管式节点](patch-manager-compliance-remediation.md)。
# 补丁合规性状态值
有关托管式节点补丁的信息包括每个单一补丁的状态报告。
**提示**
如果要将特定补丁合规性状态分配给托管式节点，可以使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface（AWS CLI）命令或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 操作。控制台中不支持分配合规性状态。
使用下表中的信息可帮助您确定托管式节点可能不符合补丁合规性要求的原因。
## Debian Server 和 Ubuntu Server 的补丁合规性值
对于 Debian Server 和 Ubuntu Server，将软件包分类到不同合规性状态的规则如下表所述。
**注意**
在评估 `INSTALLED`、`INSTALLED_OTHER` 和 `MISSING` 状态值时，请记住以下事项：如果在创建或更新补丁基准时未选中**包括非安全性更新**复选框，则补丁候选版本仅限于以下存储库中的补丁：
Ubuntu Server 16.04 LTS：`xenial-security`
Ubuntu Server 18.04 LTS：`bionic-security`
Ubuntu Server 20.04 LTS：`focal-security`
Ubuntu Server 22.04 LTS：`jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
`debian-security` (Debian Server)
如果选择了**包括非安全更新**复选框，也会考虑来自其他存储库的补丁。
| 修补状态 | 说明 | 合规性状态 |
| --- | --- | --- |
| **`INSTALLED`** | 补丁在补丁基准中列出，并已安装在托管式节点上。如果托管式节点上已运行 `AWS-RunPatchBaseline` 文档，则可能是由个人手动安装或由 Patch Manager 自动安装补丁。 | 合规 |
| **`INSTALLED_OTHER`** | 补丁不包括在基准中，或者未获基准批准，但已安装在托管式节点上。该补丁可能已手动安装，该软件包可能是另一个已批准补丁的必需依赖项，或者该补丁可能已包含在 InstallOverrideList 操作中。如果您没有指定 `Block` 作为**拒绝的修补**行动,`INSTALLED_OTHER` 补丁还包括已安装但拒绝的补丁。 | 合规 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` 可能表示以下任一情况： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-compliance-states.html) 无论是哪种情况，都不表示具有此状态的补丁*需要*重新启动，而是只表示自安装补丁以来该节点尚未重新启动。 | 不合规 |
| **`INSTALLED_REJECTED`** | 该补丁已安装在托管式节点上，但列在 **Rejected patches**（已被拒绝补丁）列表中。这通常意味着补丁是在添加到已拒绝的补丁列表之前安装的。 | 不合规 |
| **`MISSING`** | 基准中已批准补丁，但托管式节点上未安装该补丁。如果将 `AWS-RunPatchBaseline` 文档任务配置为扫描（而不是安装），系统将为扫描期间找到但未安装的补丁报告此状态。 | 不合规 |
| **`FAILED`** | 基准中已批准补丁，但无法安装补丁。要解决此问题，请查看命令输出中是否有可帮助您理解此问题的信息。 | 不合规 |
## 其他操作系统的补丁合规性值
对于除 Debian Server 和 Ubuntu Server 之外的所有操作系统，将软件包分类到不同合规性状态的规则如下表所述。
| 修补状态 | 说明 | 合规性值 |
| --- | --- | --- |
| **`INSTALLED`** | 补丁在补丁基准中列出，并已安装在托管式节点上。如果节点上已运行 `AWS-RunPatchBaseline` 文档，则可能是由个人手动安装或由 Patch Manager 自动安装补丁。 | 合规 |
| **`INSTALLED_OTHER`**¹ | 补丁不在基准中，但已安装在托管式节点上。有两个可能的原因： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-compliance-states.html) | 合规 |
| **`INSTALLED_REJECTED`** | 该补丁已安装在托管式节点上，但列在已被拒绝补丁列表中。这通常意味着补丁是在添加到已拒绝的补丁列表之前安装的。 | 不合规 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` 可能表示以下任一情况： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-compliance-states.html) 无论是哪种情况，都不表示具有此状态的补丁*需要*重新启动，而是只表示自安装补丁以来该节点尚未重新启动。 | 不合规 |
| **`MISSING`** | 基准中已批准补丁，但托管式节点上未安装该补丁。如果将 `AWS-RunPatchBaseline` 文档任务配置为扫描（而不是安装），系统将为扫描期间找到但未安装的补丁报告此状态。 | 不合规 |
| **`FAILED`** | 基准中已批准补丁，但无法安装补丁。要解决此问题，请查看命令输出中是否有可帮助您理解此问题的信息。 | 不合规 |
| **`NOT_APPLICABLE`**¹ | *此合规性状态仅针对 Windows Server 操作系统报告。* 基准中已批准补丁，但托管式节点上未安装使用该补丁的服务或功能。例如，如果基准中已批准 Web 服务器服务 [如 Internet Information Services (IIS)] 的补丁，但托管式节点上未安装该 Web 服务，则该补丁将显示 `NOT_APPLICABLE`。如果补丁已由后续更新取代，则也可以将补丁标记为 `NOT_APPLICABLE`。这意味着安装了更高版本的更新，并且不再需要 `NOT_APPLICABLE` 更新。 | 不适用 |
| AVAILABLE\$1SECURITY\$1UPDATES | *此合规性状态仅针对 Windows Server 操作系统报告。* 未经补丁基准批准的可用安全更新补丁可以具有合规性值 `Compliant` 或 `Non-Compliant`，如自定义补丁基准中所定义。 创建或更新补丁基准时，需选择要分配给可用但尚未批准的安全补丁（这些补丁由于不符合补丁基准中指定的安装标准而未获批准）的状态。例如，如果您指定在补丁发布后等待较长时间再进行安装，则会跳过某些您可能希望安装的安全补丁。如果在您指定的等待期内发布了该补丁的更新版本，则该补丁的安装等待期将重新开始。如果等待期过长，则可能会发布多个版本的补丁，但不会进行安装。 对于补丁摘要计数，当某个补丁报告为 `AvailableSecurityUpdate` 时，它将始终计入 `AvailableSecurityUpdateCount`。如果基准配置为将此类补丁报告为 `NonCompliant`，则它们也会计入 `SecurityNonCompliantCount`。如果基准配置为将此类补丁报告为 `Compliant`，则它们不会计入 `SecurityNonCompliantCount`。此类补丁始终以未指定严重性的形式报告，且永远不会计入 `CriticalNonCompliantCount`。 | “合规”或“不合规”，取决于为可用安全更新选择的选项。 通过控制台创建或更新补丁基准，需在**可用安全更新合规性状态**字段中指定此选项。通过 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` 参数中指定此选项。 |
¹ 对于状态为 `INSTALLED_OTHER` 和 `NOT_APPLICABLE` 的补丁，根据 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) 命令，Patch Manager 会从查询结果中省略一些数据，例如 `Classification` 和 `Severity` 的值。这样做有助于防止超出 Inventory（AWS Systems Manager 中的一项工具）中单个节点的数据限制。要查看所有补丁的详细信息，可以使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 命令。
# 修补不合规的托管式节点
许多 AWS Systems Manager 工具和流程均可用来检查托管式节点是否符合补丁合规性要求，您也可以使用这些工具和流程来使节点符合当前应用的补丁规则。要使托管式节点符合补丁合规性要求，Patch Manager（AWS Systems Manager 中的一项工具）必须运行 `Scan and install` 操作。（如果您的目标仅是标识而非修复不合规的托管式节点，请改为运行 `Scan` 操作。有关更多信息，请参阅 [标识不合规的托管式节点](patch-manager-find-noncompliant-nodes.md)。）
**使用 Systems Manager 安装补丁**
您可以从多个工具中选择以运行 `Scan and install` 操作：
+ （推荐）在Quick Setup（Systems Manager 中的一项工具）中配置补丁策略让您可以按计划为整个组织、部分组织单位或单个 AWS 账户安装缺失的补丁。有关更多信息，请参阅 [使用 Quick Setup 补丁策略为组织中的实例配置修补](quick-setup-patch-manager.md)。
+ 在 Run Command 任务类型中，创建使用 Systems Manager 文档（SSM 文档）`AWS-RunPatchBaseline` 的维护时段。有关信息，请参阅[教程：使用控制台创建修补的维护时段](maintenance-window-tutorial-patching.md)。
+ 在 Run Command 操作中，手动运行 `AWS-RunPatchBaseline`。有关信息，请参阅[从控制台运行命令](running-commands-console.md)。
+ 使用**修补**选项，按需安装补丁。有关信息，请参阅[按需修补托管式节点](patch-manager-patch-now-on-demand.md)。
# 识别创建补丁合规性数据的执行
补丁合规性数据代表最近一次成功修补操作的时间点快照。每个合规性报告都包含执行 ID 和捕获时间，可帮助您确定是哪个操作创建了合规性数据以及何时生成的。
如果您用多种操作来扫描实例的补丁合规性，则每次扫描都会覆盖先前扫描的补丁合规性数据。作为结果，您最终可能会导致补丁合规性数据中产生意外结果。
例如，假设您创建了一个补丁策略，该策略每天在当地时间凌晨 2 点扫描补丁合规性。该补丁策略使用的补丁基准是针对严重性标记为 `Critical`、`Important` 和 `Moderate` 的补丁。该补丁基准还指定了一些特定的已拒绝补丁。
同时，假设您已经设置了一个没有删除或停用的维护时段，每天在当地时间凌晨 4 点扫描同一组托管节点。该维护时段的任务使用其他补丁基准，该基准仅针对 `Critical` 严重性的补丁，且不排除任何特定补丁。
当维护时段执行第二次扫描时，第一次扫描的补丁合规性数据将被删除，并替换为第二次扫描的补丁合规性数据。
因此，我们强烈建议在修补操作中仅使用一种自动方法进行扫描和安装。如果您要设置补丁策略，应该删除或停用其他扫描补丁合规性的方法。有关更多信息，请参阅以下主题：
+ 要从维护时段删除修补操作任务：[使用控制台更新或注销维护时段任务](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ 删除 State Manager 关联：[删除关联](systems-manager-state-manager-delete-association.md)。
要在“主机管理”配置中停用每日补丁合规性扫描，请在 Quick Setup 中执行以下操作：
1. 在导航窗格中，请选择 **Quick Setup**。
1. 选择要更新的主机管理配置。
1. 选择 **Actions, Edit configuration**（操作、编辑配置）。
1. 清除 **Scan instances for missing patches daily**（每日扫描实例以查找缺失的补丁）复选框。
1. 选择**更新**。
**注意**
使用 **Patch now**（立即修补）选项扫描托管节点的合规性也会覆盖补丁合规性数据。
# 按需修补托管式节点
使用Patch Manager（AWS Systems Manager 中的一项工具）中的**立即修补**选项，您可以从 Systems Manager 控制台运行按需修补操作。这意味着您不必创建计划来更新托管式节点的合规性状态，或在不合规的节点上安装补丁。您也不需要在Patch Manager和 Maintenance Windows（AWS Systems Manager 中的一项工具）之间切换 Systems Manager 控制台来设置或修改计划的补丁时段。
当您必须尽快在托管式节点上应用零日更新或安装其他关键补丁时，**Patch now**（立即修补）特别有用。
**注意**
每次仅支持按需修补一个 AWS 账户 与 AWS 区域 对。这不能用于基于*补丁策略*的修补操作。我们建议使用补丁策略来确保所有托管节点满足合规性。有关使用补丁策略的更多信息，请参阅 [Quick Setup 中的补丁策略配置](patch-manager-policies.md)。
**Topics**
+ [“立即补丁”的工作原理](#patch-on-demand-how-it-works)
+ [运行“立即修补”](#run-patch-now)
## “立即补丁”的工作原理
要运行**立即修补**，您只需指定两个必需的设置：
+ 是仅扫描缺少的补丁，还是在托管式节点上扫描*并*安装补丁
+ 要在哪个托管式节点上运行该操作
当 **Patch now**（立即修补）操作运行时，其确定以与为其他修补操作选择的基准相同的方式使用哪个补丁基准。如果托管式节点与补丁组关联，则将使用为该组指定的补丁基准。如果托管式节点未与补丁组关联，则该操作使用的补丁基准为当前设置为托管式节点操作系统类型的默认补丁基准。这可以是预定义基准，也可以是您设置为默认基准的自定义基准。有关选择补丁基准的更多信息，请参阅 [补丁组](patch-manager-patch-groups.md)。
您可以为 **Patch now**（立即修补）指定的选项包括：选择修补后重启托管式节点的时间或是否重启托管式节点，指定 Amazon Simple Storage Service (Amazon S3) 存储桶来存储修补操作的日志数据，以及在修补期间将 Systems Manager 文档（SSM 文档）作为生命周期钩子运行。
### “立即修补”的并发和错误阈值
适用于**立即修补**操作，并发和错误阈值选项由 Patch Manager 来处理。您无需指定一次修补多少个托管式节点，也不需要指定操作失败之前允许的错误数。在按需进行修补时，Patch Manager 将应用下表中描述的并发和错误阈值设置。
**重要**
以下阈值仅适用于 `Scan and install` 操作。对于 `Scan` 操作，Patch Manager 会尝试同时扫描多达 1,000 个节点，并继续扫描，直到遇到多达 1,000 个错误。
**并发性：安装操作**
| **Patch now**（立即修补）操作中的托管式节点总数 | 一次扫描或修补的托管式节点数量 |
| --- | --- |
| 少于 25 | 1 |
| 25-100 | 5% |
| 101 到 1,000 | 8% |
| 1,000 以上 | 10% |
**错误阈值：安装操作**
| **Patch now**（立即修补）操作中的托管式节点总数 | 操作失败前允许的错误数 |
| --- | --- |
| 少于 25 | 1 |
| 25-100 | 5 |
| 101 到 1,000 | 10 |
| 1,000 以上 | 10 |
### 使用“立即修补”生命周期钩子
**立即修补**提供了在 `Install` 修补操作期间将 SSM 命令文档作为生命周期钩子运行的能力。您可以使用这些钩子执行诸如在修补之前关闭应用程序或在修补后或重启后对应用程序运行状况检查之类的任务。
有关使用生命周期钩子的更多信息，请参阅 [用于修补的 SSM 命令文档：`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)。
下表列出了适用于三个**立即修补**重启选项之一的可用生命周期钩子，以及每个钩子的示例用途。
**生命周期钩子和示例用途**
| 重启选项 | 钩子：安装前 | 钩子：安装后 | 钩子：退出时 | 钩子：计划重启后 |
| --- | --- | --- | --- | --- |
| 如果需要，重启 | 在开始修补之前运行 SSM 文档。 示例用途：在修补过程开始之前安全地关闭应用程序。 | 在修补操作结束时和托管式节点重启前运行 SSM 文档。 示例用途：在潜在重启之前运行诸如安装第三方应用程序等操作。 | 修补操作完成后运行 SSM 文档，重新启动实例。 示例用途：确保应用程序在修补后按预期运行。 | 不可用 |
| 不重启我的实例 | 同上。 | 在修补操作结束时运行 SSM 文档。 示例用途：确保应用程序在修补后按预期运行。 | *不可用* | *不可用* |
| 计划重启时间 | 同上。 | 与不重启我的实例相同。 | 不可用 | 在计划的重启完成后立即运行 SSM 文档。 示例用途：确保应用程序在重启后按预期运行。 |
## 运行“立即修补”
使用以下过程按需修补托管式节点。
**要运行“立即修补”**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**立即修补**。
1. 适用于**修补操作**，请选择以下选项之一：
+ **Scan**（扫描）：Patch Manager 查找托管式节点中缺少的补丁，但不进行安装。您可以在**合规性**控制面板中查看结果，或在你使用的其他工具中查看补丁合规性。
+ **Scan and install**（扫描并安装）：Patch Manager 查找并安装托管式节点中缺少的补丁。
1. 仅在上一个步骤中选择**扫描并安装**时，使用此步骤。对于 **重启选项**，请选择以下选项之一：
+ **Reboot if needed**（如需要，则重启）：安装后，Patch Manager 仅在需要完成补丁安装时才会重启托管式节点。
+ **Don't reboot my instances**（不重启我的实例）：安装后，Patch Manager 不会重启托管式节点。当您在 Patch Manager 之外选择或管理重启时，您可以手动重启节点。
+ **Schedule a reboot time**（计划重启时间）：为 Patch Manager 重启托管式节点，指定日期、时间和 UTC 时区。在您运行**立即修补**操作时，计划的重启将在 State Manager 中列为关联内容，名称为 `AWS-PatchRebootAssociation`。
**重要**
如果在主修补操作开始后取消该操作，则State Manager中的 `AWS-PatchRebootAssociation` 关联不会自动取消。为防止意外重启，如果不再希望发生计划重启，则必须手动从State Manager中删除 `AWS-PatchRebootAssociation`。否则可能导致系统意外重启，从而影响生产工作负载。您可以在 Systems Manager 控制台的**State Manager** > **关联**下找到此关联。
1. 对于 **要修补的实例**，请选择以下任一项：
+ **Patch all instances**（修补所有实例）：在当前 AWS 区域 中，Patch Manager 在 AWS 账户 中的所有托管式节点上运行指定操作。
+ **Patch only the target instances I specify**（仅修补我指定的目标实例）：您可以指定要在下一步中作为目标的托管式节点。
1. 仅在上一个步骤中选择**仅修补我指定的目标实例**时，使用此步骤。在 **Target selection**（目标选择）部分中，通过指定标签、手动选择节点或指定资源组，标识要在其上运行此操作的节点。
**注意**
如果未列出您希望看到的托管式节点，请参阅 [排除托管式节点可用性的问题](fleet-manager-troubleshooting-managed-nodes.md) 以获取故障排除技巧。
如果选择以资源组为目标，请注意，基于 AWS CloudFormation 堆栈的资源组仍然必须使用默认 `aws:cloudformation:stack-id` 标签来标记。如果已删除，Patch Manager 可能无法确定属于资源组的托管式节点。
1. （可选）对于**补丁日志存储**，如果要从此修补操作创建和保存日志，请选择用于存储日志的 S3 存储桶。
**注意**
授予将数据写入 S3 存储桶的能力的 S3 权限，是分配给实例的实例配置文件（适用于 EC2 实例）或 IAM 服务角色（混合激活的计算机）的权限，而不是执行此任务的 IAM 用户的权限。有关更多信息，请参阅[配置 Systems Manager 所需的实例权限](setup-instance-permissions.md)或[在混合和多云环境中创建 Systems Manager 所需的 IAM 服务角色](hybrid-multicloud-service-role.md)。此外，如果指定的 S3 存储桶位于不同的 AWS 账户 中，请确保与该托管式节点关联的实例配置文件或 IAM 服务角色具有写入该存储桶的所需权限。
1. （可选）如果要在修补操作的特定点期间将 SSM 文档作为生命周期钩子运行，请执行以下操作：
+ 选择**使用生命周期钩子**。
+ 对于每个可用钩子，选择要在操作的指定点运行的 SSM 文档：
+ 安装前
+ 安装后
+ 退出时
+ 计划重启后
**注意**
默认文档 `AWS-Noop`，不运行任何操作。
1. 选择**立即修补**。
打开 **Association execution targets (关联执行目标)**页面。[“立即修补”使用State Manager（AWS Systems Manager 中的一项工具）中的关联进行操作。] 在 **Operation summary**（操作摘要）区域中，您可以监控指定托管式节点上的扫描或修补状态。
# 使用补丁基准
Patch Manager（AWS Systems Manager 中的一项工具）中的补丁基准定义获批在托管式节点上安装的补丁。您可以逐个指定批准或拒绝的补丁。也可以创建自动批准规则，指定应自动批准的某些更新类型 (例如重要更新)。拒绝补丁列表将覆盖这些规则和批准列表。要使用一系列已批准的补丁来安装特定软件包，需要先删除所有自动批准规则。如果您将补丁明确标识为已拒绝，即使它匹配自动批准规则中的所有条件，也不会被批准或安装。此外，即使补丁获批用于某个托管式节点，只有该补丁适用于托管式节点上的软件时，才会安装该补丁。
**Topics**
+ [查看 AWS 预定义补丁基准](patch-manager-view-predefined-patch-baselines.md)
+ [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)
+ [将现有补丁基准设置为默认项](patch-manager-default-patch-baseline.md)
**更多信息**
+ [补丁基准](patch-manager-patch-baselines.md)
# 查看 AWS 预定义补丁基准
Patch Manager（AWS Systems Manager 中的一项工具）包含用于Patch Manager支持的每个操作系统的预定义补丁基准。您可以利用这些补丁基准（您不能对其进行自定义），也可创建自己的补丁基准。以下过程介绍了如何查看预定义的补丁基准，以查看它是否满足您的需求。要了解有关补丁基准的更多信息，请参阅 [预定义和自定义补丁基准](patch-manager-predefined-and-custom-patch-baselines.md)。
**查看 AWS 预定义补丁基准**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 在补丁基准列表中，请选择其中一个预定义补丁基准的基准 ID。
–或者–
如果您是在当前 AWS 区域 首次访问 Patch Manager，请选择**从概览开始**，然后选择**补丁基准**选项卡，然后选择预定义补丁基准之一的基准 ID。
**注意**
适用于 Windows Server，提供三个预定义的补丁基准。补丁基准 `AWS-DefaultPatchBaseline` 和 `AWS-WindowsPredefinedPatchBaseline-OS` 仅支持 Windows 操作系统本身的操作系统更新。除非您指定了其他补丁基准，`AWS-DefaultPatchBaseline` 用作 Windows Server 托管式节点的默认补丁基准。这两个补丁基准中的配置设置是相同的。两者中较新的,`AWS-WindowsPredefinedPatchBaseline-OS` 被创建来区分它和 Windows Server 的第三个预定义补丁基准。补丁基准 `AWS-WindowsPredefinedPatchBaseline-OS-Applications`，可用于将补丁应用到 Windows Server 操作系统和 Microsoft 发布的受支持的应用程序。
有关更多信息，请参阅 [将现有补丁基准设置为默认项](patch-manager-default-patch-baseline.md)。
1. 在**批准规则**部分中，查看补丁基准配置。
1. 如果托管式节点接受该配置，则可以直接跳至过程 [创建和管理补丁组](patch-manager-tag-a-patch-group.md)。
–或者–
要创建自己的默认补丁基准，请继续主题 [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)。
# 使用自定义补丁基准
Patch Manager（AWS Systems Manager 中的一项工具）包含用于Patch Manager支持的每个操作系统的预定义补丁基准。您可以利用这些补丁基准（您不能对其进行自定义），也可创建自己的补丁基准。
以下过程描述如何创建、更新和删除您自己的自定义补丁基准。要了解有关补丁基准的更多信息，请参阅 [预定义和自定义补丁基准](patch-manager-predefined-and-custom-patch-baselines.md)。
**Topics**
+ [创建适用于 Linux 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-linux.md)
+ [创建适用于 macOS 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-macos.md)
+ [创建适用于 Windows Server 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-windows.md)
+ [更新或删除自定义补丁基准](patch-manager-update-or-delete-a-patch-baseline.md)
# 创建适用于 Linux 的自定义补丁基准
在Patch Manager（AWS Systems Manager 中的一项工具）中，按照以下过程为 Linux 托管式节点创建自定义补丁基准。
有关为 macOS 托管式节点创建补丁基准的信息，请参阅 [创建适用于 macOS 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-macos.md)。有关为 Windows 托管式节点创建补丁基准的信息，请参阅 [创建适用于 Windows Server 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-windows.md)。
**为 Linux 托管式节点创建自定义补丁基准**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**补丁基准**选项卡，然后选择**创建补丁基准**。
–或者–
如果您是在当前 AWS 区域首次访问 Patch Manager，请选择**从概览开始**，然后选择**补丁基准**选项卡，然后选择**创建补丁基准**。
1. 在 **Name (名称)** 中，输入新补丁基准的名称，例如，`MyRHELPatchBaseline`。
1. （可选）对于 **Description (描述)**，输入此补丁基准的描述。
1. 对于 **Operating system (操作系统)**，请选择操作系统，例如 `Red Hat Enterprise Linux`。
1. 如果要在创建后即开始将此补丁基准用作所选操作系统的默认项，请选中 **Set this patch baseline as the default patch baseline for *operating system name* instances (将此补丁基准设置为 <操作系统名称> 实例的默认补丁基准)** 旁边的框。
**注意**
只有在 2022 年 12 月 22 日 [补丁策略](patch-manager-policies.md) 发布之前首次访问 Patch Manager时，此选项才可用。
有关将现有补丁基准设置为默认项的信息，请参阅 [将现有补丁基准设置为默认项](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating-systems (操作系统的批准规则)** 部分，使用字段创建一个或多个自动批准规则。
+ **产品**：批准规则适用的操作系统版本，例如 `RedhatEnterpriseLinux7.4`。默认选择为 `All`。
+ **Classification (分类)**：批准规则适用于的补丁的类型，例如 `Security` 或 `Enhancement`。默认选择为 `All`。
**提示**
您可以配置补丁基准来控制是否安装 Linux 的次要版本升级，如 RHEL 7.8。次要版本升级可由 Patch Manager 自动安装，前提是此更新在适当的存储库中可用。
对于 Linux 操作系统，次要版本升级的分类方式不一致。它们可以分类为错误修复或安全更新，或者不分类，即使在同一内核版本中也是如此。以下是控制补丁基准是否安装这些补丁的几个选项。
**选项 1**：确保在可用时安装次要版本升级的最广泛的批准规则是将 **Classification**（分类）指定为 `All` (\$1)，然后选择 **Include nonsecurity updates**（包括非安全更新）选项。
**选项 2**：为确保安装操作系统版本的补丁，您可以使用通配符 (\$1) 在基准的 **Patch exceptions (补丁例外)** 部分指定其内核格式。例如，RHEL 7.\$1 的内核格式为 `kernel-3.10.0-*.el7.x86_64`。
在补丁基准中的 **Approved patches**（已批准补丁）列表中输入 `kernel-3.10.0-*.el7.x86_64`，以确保所有补丁（包括次要版本升级）都应用到 RHEL 7.\$1 托管式节点。（如果您知道次要版本补丁的确切程序包名称，则可以输入此名称。）
**Option 3**（选项 3）：通过使用 `AWS-RunPatchBaseline` 文档中的 [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) 参数，您可以最大程度地控制应用于托管式节点的补丁（包括次要版本升级）。有关更多信息，请参阅 [用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
+ **Severity (严重性)**：规则适用于的补丁的严重性值，例如 `Critical`。默认选择为 `All`。
+ **Auto-approval**（自动批准）：选择要自动批准的补丁的方法。
**注意**
由于无法可靠地确定 Ubuntu Server 的更新程序包的发布日期，因此此操作系统不支持自动批准选项。
+ **在指定的天数后批准补丁**：Patch Manager 在发布或最后更新补丁之后等待的天数，然后自动批准补丁。可以输入零 (0) 到 360 的任何整数。对于大多数情况，我们建议等待期不超过 100 天。
+ **批准在特定日期之前发布的补丁**：补丁发布日期，Patch Manager 自动应用在该日期或之前发布或更新的所有补丁。例如，如果指定 2023 年 7 月 7 日，则不会自动安装在 2023 年 7 月 8 日或之后发布或最后更新的任何补丁。
+ （可选）**合规性报告**：要分配给基准批准的补丁的严重性级别，例如 `Critical` 或 `High`。
**注意**
如果您指定合规性报告级别以及任何已批准补丁的补丁状态报告为 `Missing`，则补丁基准报告的总体合规性严重性级别就是您指定的严重级别。
+ **Include non-security updates (包括非安全性更新)**：选中此复选框，除了可以安装与安全性相关的补丁外，还可以安装源存储库中提供的非安全性 Linux 操作系统补丁。
有关在自定义补丁基准中使用批准规则的更多信息，请参阅 [自定义基准](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)。
1. 如果要明确批准除满足批准规则的补丁外的任何补丁，请在 **Patch exceptions (补丁例外)** 部分执行以下操作：
+ 对于 **Approved patches (已批准的补丁)**，输入要批准的补丁的逗号分隔列表。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
+ （可选）对于 **Approved patches compliance level (已批准补丁合规性级别)**，为列表中的补丁分配合规性级别。
+ 如果您指定的任何已批准的补丁与安全性无关，请选中**包括非安全性更新**复选框，以便也在 Linux 操作系统上安装这些补丁。
1. 如果要明确拒绝除满足批准规则的补丁外的任何补丁，请在 **Patch exceptions (补丁例外)** 部分执行以下操作：
+ 对于 **Rejected patches (已拒绝的补丁)**，输入要拒绝的补丁的逗号分隔列表。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 对于**已拒绝的补丁操作**，请选择 Patch Manager 要对**已拒绝的补丁**列表中包含的补丁采取的操作。
+ **允许作为依赖项**：仅当**已拒绝的补丁**列表中的软件包是另一个软件包的依赖项时，才安装它。它被视为符合补丁基准，并且它的状态报告为 *InstalledOther*。这是未指定选项时的默认操作。
+ **阻止**：在任何情况下，Patch Manager 都不安装**已拒绝补丁**列表中的软件包以及包含相关补丁作为依赖项的软件包。如果在将软件包添加到**已拒绝补丁**列表之前已安装该软件包，或者之后会在 Patch Manager 外部安装该软件包，则将其视为不符合补丁基准并将状态报告为 *InstalledRejected*。
**注意**
Patch Manager 递归搜索补丁依赖项。
1. （可选）如果您要为不同版本的操作系统 (如 *AmazonLinux2016.03* 和 *AmazonLinux2017.09*) 指定备用补丁存储库，请为 **Patch sources (补丁来源)** 部分中的每个产品执行以下操作：
+ 在 **Name (名称)** 中，输入名称以帮助您标识源配置。
+ 在 **Product**（产品）中，请选择补丁源存储库适用于的操作系统的版本，例如 `RedhatEnterpriseLinux7.4`。
+ 在**配置**中，输入要以适当格式使用的存储库配置的值：
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**提示**
有关 yum 存储库配置可用的其他选项的信息，请参阅 [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html)。
------
#### [ Examples for Ubuntu Server and Debian 服务器 ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
必须在一行中指定 Ubuntu Server 存储库的存储库信息。有关更多示例和信息，请参阅 *Ubuntu 服务器手册*网站上的 [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) 以及 *Debian Wiki* 上的 [sources.list 格式](https://wiki.debian.org/SourcesList#sources.list_format)。
------
选择**添加其他来源**来为每个其他操作系统版本指定源存储库，最多 20 个。
有关备用源补丁存储库的更多信息，请参阅 [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。
1. （可选）对于**管理标签**，将一个或多个标签键名称/值对应用到补丁基准。
标签是您分配给资源的可选元数据。标签允许您按各种标准（如用途、所有者或环境）对资源进行分类。例如，您可能想要标记补丁基准来确定其指定的补丁的严重性级别、它适用的操作系统系列以及环境类型。在这种情况下，您可以指定类似于以下键名称/值对的标签：
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. 请选择**创建补丁基准**。
# 创建适用于 macOS 的自定义补丁基准
在Patch Manager（AWS Systems Manager 中的一项工具）中，按照以下过程为 macOS 托管式节点创建自定义补丁基准。
有关为 Windows Server 托管式节点创建补丁基准的信息，请参阅 [创建适用于 Windows Server 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-windows.md)。有关为 Linux 托管式节点创建补丁基准的信息，请参阅 [创建适用于 Linux 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-linux.md)。
**注意**
并非所有 AWS 区域 都支持 macOS。有关对适用于 macOS 的 Amazon EC2 支持的一般信息，请参阅《Amazon EC2 用户指南》**中的 [Amazon EC2 Mac 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)。
**为 macOS 托管式节点创建自定义补丁基准**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**补丁基准**选项卡，然后选择**创建补丁基准**。
–或者–
如果您是在当前 AWS 区域首次访问 Patch Manager，请选择**从概览开始**，然后选择**补丁基准**选项卡，然后选择**创建补丁基准**。
1. 在 **Name (名称)** 中，输入新补丁基准的名称，例如，`MymacOSPatchBaseline`。
1. （可选）对于 **Description (描述)**，输入此补丁基准的描述。
1. 对于 **Operating system**（操作系统），请选择 macOS。
1. 如果要在创建后即开始将此补丁基准用作 macOS 的默认项，请选中**将此补丁基准设置为 macOS 实例的默认补丁基准** 旁边的框。
**注意**
只有在 2022 年 12 月 22 日 [补丁策略](patch-manager-policies.md) 发布之前首次访问 Patch Manager时，此选项才可用。
有关将现有补丁基准设置为默认项的信息，请参阅 [将现有补丁基准设置为默认项](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating-systems (操作系统的批准规则)** 部分，使用字段创建一个或多个自动批准规则。
+ **产品**：批准规则适用的操作系统版本，例如 `BigSur11.3.1` 或 `Ventura13.7`。默认选择为 `All`。
+ **分类**：要在修补过程中应用软件包的软件包管理器。可从以下选项中进行选择：
+ 软件更新
+ 安装程序
+ 酿造
+ 酿造桶
默认选择为 `All`。
+ （可选）**合规性报告**：要分配给基准批准的补丁的严重性级别，例如 `Critical` 或 `High`。
**注意**
如果您指定合规性报告级别以及任何已批准补丁的补丁状态报告为 `Missing`，则补丁基准报告的总体合规性严重性级别就是您指定的严重级别。
有关在自定义补丁基准中使用批准规则的更多信息，请参阅 [自定义基准](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)。
1. 如果要明确批准除满足批准规则的补丁外的任何补丁，请在 **Patch exceptions (补丁例外)** 部分执行以下操作：
+ 对于 **Approved patches (已批准的补丁)**，输入要批准的补丁的逗号分隔列表。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
+ （可选）对于 **Approved patches compliance level (已批准补丁合规性级别)**，为列表中的补丁分配合规性级别。
1. 如果要明确拒绝除满足批准规则的补丁外的任何补丁，请在 **Patch exceptions (补丁例外)** 部分执行以下操作：
+ 对于 **Rejected patches (已拒绝的补丁)**，输入要拒绝的补丁的逗号分隔列表。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 对于**已拒绝的补丁操作**，请选择 Patch Manager 要对**已拒绝的补丁**列表中包含的补丁采取的操作。
+ **允许作为依赖项**：仅当**已拒绝的补丁**列表中的软件包是另一个软件包的依赖项时，才安装它。它被视为符合补丁基准，并且它的状态报告为 *InstalledOther*。这是未指定选项时的默认操作。
+ **阻止**：在任何情况下，Patch Manager 都不安装**已拒绝补丁**列表中的软件包以及包含相关补丁作为依赖项的软件包。如果在将软件包添加到**已拒绝补丁**列表之前已安装该软件包，或者之后会在 Patch Manager 外部安装该软件包，则将其视为不符合补丁基准并将状态报告为 *InstalledRejected*。
1. （可选）对于**管理标签**，将一个或多个标签键名称/值对应用到补丁基准。
标签是您分配给资源的可选元数据。标签允许您按各种标准（如用途、所有者或环境）对资源进行分类。例如，您可能想要标记补丁基准来确定其指定的补丁的严重性级别、它适用的软件包管理器以及环境类型。在这种情况下，您可以指定类似于以下键名称/值对的标签：
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. 请选择**创建补丁基准**。
# 创建适用于 Windows Server 的自定义补丁基准
在Patch Manager（AWS Systems Manager 中的一项工具）中，按照以下过程为 Windows 托管式节点创建自定义补丁基准。
有关为 Linux 托管式节点创建补丁基准的信息，请参阅 [创建适用于 Linux 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-linux.md)。有关为 macOS 托管式节点创建补丁基准的信息，请参阅 [创建适用于 macOS 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-macos.md)。
有关创建仅限于安装 Windows Service Pack 的补丁基准的示例，请参阅 [教程：使用控制台创建用于安装 Windows Service Pack 的补丁基准](patch-manager-windows-service-pack-patch-baseline-tutorial.md)。
**创建自定义补丁基准 (Windows)**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**补丁基准**选项卡，然后选择**创建补丁基准**。
–或者–
如果您是在当前 AWS 区域首次访问 Patch Manager，请选择**从概览开始**，然后选择**补丁基准**选项卡，然后选择**创建补丁基准**。
1. 在 **Name (名称)** 中，输入新补丁基准的名称，例如，`MyWindowsPatchBaseline`。
1. （可选）对于 **Description (描述)**，输入此补丁基准的描述。
1. 对于 **Operating system**（操作系统），请选择 `Windows`。
1. 对于**可用安全更新合规性状态**，需选择要分配给可用但尚未批准的安全补丁（这些补丁不符合补丁基准中指定的安装标准因此未获批准）的状态，即**不合规**或**合规**。
示例场景：如果您指定在补丁发布后等待较长时间再进行安装，则会跳过某些您可能希望安装的安全补丁。如果在您指定的等待期内发布了该补丁的更新版本，则该补丁的安装等待期将重新开始。如果等待期过长，则可能会发布多个版本的补丁，但不会进行安装。
1. 如果要在创建后即开始将此补丁基准用作 Windows 的默认项，请选择 **Set this patch baseline as the default patch baseline for Windows Server instances**（将此补丁基准设置为 Windows Server 实例的默认补丁基准）。
**注意**
只有在 2022 年 12 月 22 日 [补丁策略](patch-manager-policies.md) 发布之前首次访问 Patch Manager时，此选项才可用。
有关将现有补丁基准设置为默认项的信息，请参阅 [将现有补丁基准设置为默认项](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating systems (操作系统的批准规则)** 部分，使用字段创建一个或多个自动批准规则。
+ **产品**：批准规则适用的操作系统版本，例如 `WindowsServer2012`。默认选择为 `All`。
+ **Classification (分类)**：批准规则适用于的补丁的类型，例如 `CriticalUpdates`、`Drivers` 和 `Tools`。默认选择为 `All`。
**提示**
您可以在您的批准规则中包括 Windows 服务包安装，方法是包含 `ServicePacks` 或通过在您的**分类**列表中选择 `All`。有关示例，请参阅 [教程：使用控制台创建用于安装 Windows Service Pack 的补丁基准](patch-manager-windows-service-pack-patch-baseline-tutorial.md)。
+ **Severity (严重性)**：规则适用于的补丁的严重性值，例如 `Critical`。默认选择为 `All`。
+ **Auto-approval**（自动批准）：选择要自动批准的补丁的方法。
+ **在指定的天数后批准补丁**：Patch Manager 在发布或更新补丁之后等待的天数，然后自动批准补丁。可以输入零 (0) 到 360 的任何整数。对于大多数情况，我们建议等待期不超过 100 天。
+ **批准在特定日期之前发布的补丁**：补丁发布日期，Patch Manager 自动应用在该日期或之前发布或更新的所有补丁。例如，如果指定 2023 年 7 月 7 日，则不会自动安装在 2023 年 7 月 8 日或之后发布或最后更新的任何补丁。
+ （可选）**Compliance reporting（合规性报告）**：要分配给基准批准的补丁的严重性级别，例如 `High`。
**注意**
如果您指定合规性报告级别以及任何已批准补丁的补丁状态报告为 `Missing`，则补丁基准报告的总体合规性严重性级别就是您指定的严重级别。
1. （可选）在**应用程序的批准规则**部分，使用字段创建一个或多个自动批准规则。
**注意**
您可以将已批准和已拒绝的补丁列表指定为补丁例外，而不是指定批准规则。请参阅步骤 10 和 11。
+ **Product family (产品系列)**：您要为其指定规则的一般 Microsoft 产品系列，如 `Office` 或 `Exchange Server`。
+ **产品**：批准规则适用的应用程序版本，例如 `Office 2016` 或 `Active Directory Rights Management Services Client 2.0 2016`。默认选择为 `All`。
+ **Classification (分类)**：批准规则适用于的补丁的类型，例如 `CriticalUpdates`。默认选择为 `All`。
+ **Severity (严重性)**：规则适用于的补丁的严重性值，如 `Critical`。默认选择为 `All`。
+ **Auto-approval**（自动批准）：选择要自动批准的补丁的方法。
+ **在指定的天数后批准补丁**：Patch Manager 在发布或更新补丁之后等待的天数，然后自动批准补丁。可以输入零 (0) 到 360 的任何整数。对于大多数情况，我们建议等待期不超过 100 天。
+ **批准在特定日期之前发布的补丁**：补丁发布日期，Patch Manager 自动应用在该日期或之前发布或更新的所有补丁。例如，如果指定 2023 年 7 月 7 日，则不会自动安装在 2023 年 7 月 8 日或之后发布或最后更新的任何补丁。
+ （可选）**合规性报告**：要分配给基准批准的补丁的严重性级别，例如 `Critical` 或 `High`。
**注意**
如果您指定合规性报告级别以及任何已批准补丁的补丁状态报告为 `Missing`，则补丁基准报告的总体合规性严重性级别就是您指定的严重级别。
1. （可选）如果要明确批准任何补丁，而不是允许根据批准规则选择补丁，请在**修补例外**部分进行以下操作：
+ 对于 **Approved patches (已批准的补丁)**，输入要批准的补丁的逗号分隔列表。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
+ （可选）对于 **Approved patches compliance level (已批准补丁合规性级别)**，为列表中的补丁分配合规性级别。
1. 如果要明确拒绝除满足批准规则的补丁外的任何补丁，请在 **Patch exceptions (补丁例外)** 部分执行以下操作：
+ 对于 **Rejected patches (已拒绝的补丁)**，输入要拒绝的补丁的逗号分隔列表。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 对于**已拒绝的补丁操作**，请选择 Patch Manager 要对**已拒绝的补丁**列表中包含的补丁采取的操作。
+ **允许作为依赖项**：Windows Server 不支持软件包依赖项的概念。如果**已拒绝的补丁**列表中的软件包已安装在节点上，则其状态将报告为 `INSTALLED_OTHER`。任何尚未安装在节点上的软件包都将被跳过。
+ **阻止**：Patch Manager 在任何情况下都不会安装**已拒绝的补丁**列表中的软件包。如果在将软件包添加到**已拒绝补丁**列表之前已安装该软件包，或者之后会在 Patch Manager 外部安装该软件包，则将其视为不符合补丁基准并将状态报告为 `INSTALLED_REJECTED`。
有关已拒绝软件包操作的更多信息，请参阅[自定义补丁基准中的“已拒绝的补丁”列表选项](patch-manager-windows-and-linux-differences.md#rejected-patches-diff)。
1. （可选）对于**管理标签**，将一个或多个标签键名称/值对应用到补丁基准。
标签是您分配给资源的可选元数据。标签允许您按各种标准（如用途、所有者或环境）对资源进行分类。例如，您可能想要标记补丁基准来确定其指定的补丁的严重性级别、它适用的操作系统系列以及环境类型。在这种情况下，您可以指定类似于以下键名称/值对的标签：
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. 请选择**创建补丁基准**。
# 更新或删除自定义补丁基准
您可以更新或删除自己在Patch Manager（AWS Systems Manager 中的一项工具）中创建的自定义补丁基准。更新补丁基准时，可以更改它的名称或说明、批准规则，以及对已批准和已拒绝补丁的例外。另外还可以更新应用于补丁基准的标签。您不能更改为其创建补丁基准的操作系统类型，也不能对 AWS 提供的预定义补丁基准进行更改。
## 更新或删除补丁基准
请按照以下步骤更新或删除补丁基准。
**重要**
在 Quick Setup 中删除补丁策略配置可能使用的自定义补丁基准时要谨慎。
如果您在 Quick Setup 中使用[补丁策略配置](patch-manager-policies.md)，则系统会每小时与 Quick Setup 同步一次您对自定义补丁基准所做的更新。
如果删除了补丁策略中引用的自定义补丁基准，那么补丁策略的 Quick Setup **Configuration details**（配置详细信息）页面上会显示一个横幅。横幅将通知您，补丁策略引用的补丁基准已不存在，且后续的修补操作将失败。在这种情况下，返回 Quick Setup **Configurations**（配置）页面，选择 Patch Manager 配置，然后选择 **Actions**（操作），**Edit configuration**（编辑配置）。已删除的补丁基准名称将突出显示，您必须为受影响的操作系统选择新的补丁基准。
**更新或删除补丁基准**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 请选择要更新或删除的补丁基准，然后执行以下操作之一：
+ 要从您的 AWS 账户 中删除补丁基准，请选择**删除**。系统将提示您确认操作。
+ 要对补丁基准的名称或说明、批准规则或补丁例外进行更改，请选择 **Edit**（编辑）。在 **Edit patch baseline**（编辑补丁基准）页面中，更改所需的值和选项，然后选择 **Save changes**（保存更改）。
+ 要添加、更改或删除应用到补丁基准的标签，请选择 **Tags (标签)** 选项卡，然后选择 **Edit tags (编辑标签)**。在 **Edit patch baseline tags (编辑补丁基准标签)** 页面上，对补丁基准标签进行更新，然后选择 **Save changes (保存更改)**。
有关您可以进行的配置选择的信息，请参阅 [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)。
# 将现有补丁基准设置为默认项
**重要**
您在此处所作的任何默认补丁基准选择均不适用于基于补丁策略的修补操作。补丁策略将使用自身的补丁基准规范。有关补丁策略的更多信息，请参阅 [Quick Setup 中的补丁策略配置](patch-manager-policies.md)。
当您在Patch Manager（AWS Systems Manager 中的一项工具）中创建自定义补丁基准时，可在创建后便将此基准设置为关联的操作系统类型的默认项。有关信息，请参阅[使用自定义补丁基准](patch-manager-manage-patch-baselines.md)。
您还可以将现有补丁基准设置为某个操作系统类型的默认项。
**注意**
您执行的步骤取决于您首次访问 Patch Manager 是在 2022 年 12 月 22 日补丁策略发布之前还是之后。如果您在此日期之前使用过 Patch Manager，则可以使用控制台过程。否则，请使用 AWS CLI 过程。补丁策略发布前未使用 Patch Manager 的区域不会显示控制台过程中引用的**操作**菜单。
**将补丁基准设置为默认项**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**补丁基准**选项卡。
1. 在补丁基准列表中，选择当前未设置为操作系统类型的默认项的补丁基准的按钮。
**Default baseline (默认基准)** 列指示哪些基准当前被设置为默认项。
1. 在 **Actions (操作)** 菜单中，选择 **Set default patch baseline (设置默认补丁基准)**。
**重要**
如果您在 2022 年 12 月 22 日之前未在当前 AWS 账户 和区域中使用 Patch Manager，则**操作**菜单不可用。有关更多信息，请参阅本主题前面的**注释**。
1. 在确认对话框中，选择 **Set default (设置默认值)**。
**将补丁基准设置为默认项（AWS CLI）**
1. 运行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) 命令以查看可用补丁基准及其 ID 和 Amazon 资源名称（ARN）的列表。
```
aws ssm describe-patch-baselines
```
1. 运行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) 命令将基准设置为与其关联的操作系统的默认设置。将 *baseline-id-or-ARN* 替换为要使用的自定义补丁基准或预定义基准的 ID。
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
以下是将自定义基准设置为默认基准的示例。
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
以下是将 AWS 托管的预定义基准设置为默认基准的示例。
```
aws ssm register-default-patch-baseline \
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--baseline-id baseline-id-or-ARN
```
以下是将自定义基准设置为默认基准的示例。
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
以下是将 AWS 托管的预定义基准设置为默认基准的示例。
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# 查看可用的补丁
使用Patch Manager（AWS Systems Manager 中的一项工具），您可以查看指定操作系统以及特定操作系统版本（可选）的所有可用补丁。
**提示**
要生成可用补丁列表并将其保存到文件中，可以使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 命令并指定您的首选[输出](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html)。
**查看可用补丁**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**补丁**选项卡。
–或者–
如果您是在当前 AWS 区域首次访问 Patch Manager，请选择**从概览开始**，然后选择**补丁**选项卡。
**注意**
对于 Windows Server，**补丁**选项卡显示 Windows Server 更新服务（WSUS）提供的更新。
1. 对于**操作系统**，选择要查看其可用补丁的操作系统，例如 `Windows` 或者 `Amazon Linux`。
1. （可选）对于**产品**，选择操作系统版本，例如 `WindowsServer2019` 或者 `AmazonLinux2018.03`。
1. （可选）要添加或删除结果的信息列，请选择位于**补丁**列表右上方的配置按钮 (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/images/configure-button.png))。（默认情况下，**补丁**选项卡仅显示部分可用补丁元数据的列。）
有关可以添加到视图中的元数据类型的信息，请参阅 *AWS Systems Manager API 参考*中的[补丁](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html)。
# 创建和管理补丁组
如果您在操作中*未*使用补丁策略，则可以通过使用标签将托管式节点添加到补丁组来组织修补工作。
**注意**
补丁组不会用于基于*补丁策略*的修补操作。有关使用补丁策略的更多信息，请参阅 [Quick Setup 中的补丁策略配置](patch-manager-policies.md)。
对于在 2022 年 12 月 22 日发布补丁策略支持之前尚未使用补丁组的账户-区域对，控制台不支持补丁组功能。补丁组功能在此日期之前开始使用补丁组的账户区域对中仍然可用。
要在修补操作中使用标签，必须将标签键 `Patch Group` 或 `PatchGroup` 应用于托管式节点。您还必须指定要为补丁组提供的名称作为标签的值。您可以指定任何标签值，但标签键必须为 `Patch Group` 或 `PatchGroup`。
如果[在 EC2 实例元数据中允许使用标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，则必须使用 `PatchGroup`（不带空格）。
使用标签对托管式节点进行分组后，请将补丁组值添加到补丁基准。通过将补丁组注册到补丁基准，您可以确保在修补操作期间安装正确的补丁。有关补丁组的更多信息，请参阅 [补丁组](patch-manager-patch-groups.md)。
完成本主题中的任务，使用带节点和补丁基准的标签对托管式节点进行修补。只有在修补 Amazon EC2 实例时才需要执行任务 1。只有在[混合和多云](operating-systems-and-machine-types.md#supported-machine-types)环境中修补非 EC2 实例时才需要执行任务 2。所有托管式节点都必须执行任务 3。
**提示**
您还可以使用 AWS CLI 命令 `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` 或 Systems Manager API 操作 ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)`，向托管式节点添加标签。
**Topics**
+ [任务 1：请使用标签将 EC2 实例添加到补丁组](#sysman-patch-group-tagging-ec2)
+ [任务 2：使用标签将托管式节点添加到补丁组](#sysman-patch-group-tagging-managed)
+ [任务 3：将补丁组添加到补丁基准](#sysman-patch-group-patchbaseline)
## 任务 1：请使用标签将 EC2 实例添加到补丁组
您可以使用 Systems Manager 控制台或 Amazon EC2 控制台向 EC2 实例添加标签。只有在修补 Amazon EC2 实例时才需要执行此任务。
**重要**
如果在实例上启用 **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：将 EC2 实例添加到补丁组（Systems Manager 控制台）**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Fleet Manager**。
1. 在**托管式节点**列表中，选择您要配置以进行修补的托管式 EC2 实例的 ID。EC2 实例的节点 ID 以 `i-` 开头。
**注意**
使用 Amazon EC2 控制台和 AWS CLI 时，可以将 `Key = Patch Group` 或 `Key = PatchGroup` 标签应用于尚未配置为与 Systems Manager 结合使用的实例。
如果未列出您希望看到的托管式节点，请参阅 [排除托管式节点可用性的问题](fleet-manager-troubleshooting-managed-nodes.md) 以获取故障排除技巧。
1. 选择**标签**选项卡，然后选择**编辑**。
1. 在左列中，输入 **Patch Group** 或 **PatchGroup**。如果[在 EC2 实例元数据中允许使用标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，则必须使用 `PatchGroup`（不带空格）。
1. 在右列中，输入一个标签值作为此补丁组的名称。
1. 选择**保存**。
1. 重复此过程，向同一补丁组中添加其他 EC2 实例。
**选项 2：将 EC2 实例添加到补丁组（Amazon EC2 控制台）**
1. 打开 [ Amazon EC2 控制台](https://console.aws.amazon.com/ec2/)，然后在导航窗格中选择**实例**。
1. 从实例列表中选择您要配置用于修补的实例。
1. 在**操作**菜单中，依次选择**实例设置**、**管理标签**。
1. 选择**添加新标签**。
1. 对于 **Key**（键），输入 **Patch Group** 或 **PatchGroup**。如果[在 EC2 实例元数据中允许使用标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，则必须使用 `PatchGroup`（不带空格）。
1. 对于**值**，输入一个值作为此补丁组的名称。
1. 选择**保存**。
1. 重复此过程，向同一补丁组中添加其他实例。
## 任务 2：使用标签将托管式节点添加到补丁组
按照本主题中的步骤，向 AWS IoT Greengrass 核心设备和非 EC2 混合激活的托管式节点（mi-\$1）添加标签。只有在混合和多云环境中修补非 EC2 实例时才需要执行此任务。
**注意**
您不能使用 Amazon EC2 控制台为非 EC2 托管式节点添加标签。
**将非 EC2 托管式节点添加到补丁组（Systems Manager 控制台）**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Fleet Manager**。
1. 在**托管实例**列表中，选择您要为修补配置的托管节点的名称。
**注意**
如果未列出您希望看到的托管式节点，请参阅 [排除托管式节点可用性的问题](fleet-manager-troubleshooting-managed-nodes.md) 以获取故障排除技巧。
1. 选择**标签**选项卡，然后选择**编辑**。
1. 在左列中，输入 **Patch Group** 或 **PatchGroup**。如果[在 EC2 实例元数据中允许使用标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，则必须使用 `PatchGroup`（不带空格）。
1. 在右列中，输入一个标签值作为此补丁组的名称。
1. 选择**保存**。
1. 重复此过程，向同一补丁组添加其他托管式节点。
## 任务 3：将补丁组添加到补丁基准
要将特定的补丁基准与托管式节点关联，必须将补丁组值添加到补丁基准。通过将补丁组注册到补丁基准，您可以确保在修补操作期间安装正确的补丁。无论是修补 EC2 实例、非 EC2 托管式节点还是两者，都需要执行此任务。
有关补丁组的更多信息，请参阅 [补丁组](patch-manager-patch-groups.md)。
**注意**
您执行的步骤取决于您首次访问 Patch Manager 是在 2022 年 12 月 22 日[补丁策略](patch-manager-policies.md)发布之前还是之后。
**将补丁组添加到补丁基准（Systems Manager 控制台）**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 如果您是首次在当前 AWS 区域 中访问 Patch Manager，并且 Patch Manager 起始页打开，则请选择**从概览开始**。
1. 选择**补丁基准**选项卡，然后在**补丁基准**列表中，选择要为补丁组配置的补丁基准的名称。
如果您在补丁策略发布后才首次访问 Patch Manager，则必须选择已创建的自定义基准。
1. 如果**基准 ID** 详细信息页面包含**操作**菜单，请执行以下操作：
+ 选择 **Actions (操作)**，然后选择 **Modify patch groups (修改补丁组)**。
+ 在 [任务 2：使用标签将托管式节点添加到补丁组](#sysman-patch-group-tagging-managed) 中输入您添加到托管式节点的标签*值*，然后选择**添加**。
如果**基准 ID** 详细信息页面*不*包含**操作**菜单，则无法在控制台中配置补丁组。请改为执行以下操作之一：
+ （推荐）在Quick Setup（AWS Systems Manager 中的一项工具）中设置补丁策略，将补丁基准映射到一个或多个 EC2 实例。
有关更多信息，请参阅 [Using Quick Setup patch policies](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) 和 [Automate organization-wide patching using a Quick Setup patch policy](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)。
+ 使用 AWS Command Line Interface（AWS CLI）中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html) 命令配置补丁组。
# 将 Patch Manager 与 AWS Security Hub CSPM 集成
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 向您提供 AWS 中安全状态的全面视图。Security Hub CSPM 会跨 AWS 账户、AWS 服务 和受支持的第三方合作伙伴产品收集安全数据。利用 Security Hub CSPM，您可以根据安全行业标准和最佳实践检查您的环境。Security Hub CSPM 帮助您分析安全趋势并确定最高优先级的安全问题。
通过使用Patch Manager（AWS Systems Manager 中的一项工具）和 Security Hub CSPM 之间的集成，您可以将有关不合规节点的调查发现从Patch Manager发送至 Security Hub CSPM。调查发现是安全检查或与安全相关的检测的可观测记录。然后，Security Hub CSPM 可以在其对您的安全状况分析中包含这些补丁相关的调查发现。
无论您使用哪种配置方法或类型进行修补操作，以下主题中的信息都适用：
+ Quick Setup 中配置的补丁策略
+ Quick Setup 中配置的主机管理选项
+ 运行补丁 `Scan` 或 `Install` 任务的维护时段
+ 按需 **Patch now**（立即修补）操作
**Contents**
+ [Patch Manager 如何将调查发现发送到 Security Hub CSPM](#securityhub-integration-sending-findings)
+ [Patch Manager 发送的结果类型](#securityhub-integration-finding-types)
+ [发送调查发现的延迟](#securityhub-integration-finding-latency)
+ [Security Hub CSPM 不可用时重试](#securityhub-integration-retry-send)
+ [查看 Security Hub CSPM 中的 调查发现](#securityhub-integration-view-findings)
+ [来自 Patch Manager 的典型调查发现](#securityhub-integration-finding-example)
+ [打开并配置集成](#securityhub-integration-enable)
+ [如何停止发送调查发现](#securityhub-integration-disable)
## Patch Manager 如何将调查发现发送到 Security Hub CSPM
在 Security Hub CSPM 中，安全问题按调查发现进行跟踪。一些检查结果来自其他 AWS 服务或第三方合作伙伴检测到的问题。Security Hub CSPM 还有一套用于检测安全问题和生成调查发现的规则。
Patch Manager是 Systems Manager 的一项工具，能将结果发送到 Security Hub CSPM。在您通过运行 SSM 文档（`AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 或者 `AWS-RunPatchBaselineWithHooks`）来执行修补操作之后，修补信息将被发送至 Inventory 或 Compliance（都是 AWS Systems Manager 中的工具），或同时发给这两者。在库存、合规性或两者收到数据后，Patch Manager 会收到通知。然后,Patch Manager 评估数据的准确性、格式化和合规性。如果满足所有条件，Patch Manager将数据转发到 Security Hub CSPM。
Security Hub CSPM 提供了用于管理来自所有这些来源的调查发现的工具。您可以查看和筛选调查发现列表，并查看调查发现的详细信息。有关更多信息，请参阅 *AWS Security Hub 用户指南*中的[查看结果](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html)。您还可以跟踪调查发现的调查状态。有关更多信息，请参阅 *AWS Security Hub 用户指南*中[对结果采取行动](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html)。
Security Hub CSPM 中的所有调查发现都使用名为 AWS 安全调查发现格式（ASFF）的标准 JSON 格式。ASFF 包含有关问题根源、受影响资源以及调查发现当前状态的详细信息。有关更多信息，请参阅《AWS Security Hub 用户指南》**中的 [AWS 安全调查发现格式（ASFF）](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm)。
### Patch Manager 发送的结果类型
Patch Manager 使用 [AWS 安全调查发现格式（ASFF）](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html)将调查发现发送到 Security Hub CSPM。在 ASFF 中，`Types` 字段提供调查发现类型。来自 Patch Manager 的结果可能具有 `Types` 的以下值：
+ 软件和配置检查/补丁管理
Patch Manager 为每个不合规的托管式节点发送一个调查发现。调查发现与资源类型 [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance) 一起报告，以便调查发现可以与其他 Security Hub CSPM 集成相关联，这些集成会报告 `AwsEc2Instance` 资源类型。只有当操作发现托管式节点不合规时，Patch Manager 才会将调查发现转发给 Security Hub CSPM。调查发现中包括补丁摘要结果。
**注意**
向 Security Hub CSPM 报告不合规的节点之后。节点合规后Patch Manager不会向 Security Hub CSPM 发送更新。将所需的补丁应用到托管式节点后，您可以在 Security Hub CSPM 中手动解决调查发现的问题。
有关合规性定义的更多信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。有关 `PatchSummary` 的更多信息，请参阅 *AWS Security Hub API 参考*中的[补丁程序摘要](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)。
### 发送调查发现的延迟
当Patch Manager创建新调查发现时，通常会在几秒到 2 小时内将结果发送到 Security Hub CSPM。速度取决于处理 AWS 区域 时的流量。
### Security Hub CSPM 不可用时重试
如果存在服务中断，则运行 AWS Lambda 函数，以便在服务再次运行后将消息放回主队列。当消息进入主队列后，将自动重试。
如果 Security Hub CSPM 不可用，Patch Manager重试发送调查发现，直到收到这些调查发现。
### 查看 Security Hub CSPM 中的 调查发现
此程序介绍如何在 Security Hub CSPM 中查看有关实例集中不符合补丁合规性的托管式节点的调查发现。
**查看补丁合规性的 Security Hub CSPM 调查发现**
1. 登录到 AWS 管理控制台，然后通过以下网址打开 AWS Security Hub CSPM 控制台：[https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/)。
1. 在导航窗格中，选择 **调查发现**。
1. 选择**添加筛选条件**（![\[The Search icon\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/images/search-icon.png)）框。
1. 在菜单中的**筛选条件**下，选择**产品名称**。
1. 在打开的对话框中，在第一个字段中选择 **is**，然后在第二个字段中输入 **Systems Manager Patch Manager**。
1. 选择**应用**。
1. 添加您需要的任何其他筛选条件以帮助缩小搜索范围。
1. 在结果列表中，选择您想了解更多信息的调查发现的标题。
屏幕右侧将打开一个窗格，其中包含有关资源、发现的问题和建议补救措施的更多详细信息。
**重要**
目前，Security Hub CSPM 将所有托管式节点的资源类型报告为 `EC2 Instance`。这包括您已注册用于 Systems Manager 的本地服务器和虚拟机（VM）。
**严重性分类**
**Systems Manager Patch Manager** 的调查发现列表包括有关调查发现严重性的报告。**严重性**级别包括以下内容（从最低到最高）：
+ **性** – 未发现任何问题。
+ **低** – 问题不需要修复。
+ **中** – 必须解决问题，但不是紧急的。
+ **高** – 必须优先解决问题。
+ **严重** – 必须立即解决此问题，以避免它升级。
严重性由实例上最严重的不合规软件包确定。由于您可以拥有多个具有多个严重性级别的补丁基准，因此会在所有不合规软件包中报告最高的严重性。例如，假设您有两个不合规程序包，其中程序包 A 的严重性为“严重”，而程序包 B 的严重性为“低”。“严重”将报告为严重性。
请注意，严重性字段与 Patch Manager `Compliance` 字段直接相关。这是您设置分配给与规则匹配的各个补丁的字段。由于此 `Compliance` 字段已分配给各个补丁，因此不会反映在“补丁摘要”级别。
**相关内容**
+ 《AWS Security Hub User Guide》**中的 [Findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html)
+ *AWS 管理与治理博客*中的 [Multi-Account patch compliance with Patch Manager and Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/)
## 来自 Patch Manager 的典型调查发现
Patch Manager使用 [AWS 安全调查发现格式（ASFF）](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html)将调查发现发送到 Security Hub CSPM。
下面是来自 Patch Manager 的典型调查发现的示例。
```
{
"SchemaVersion": "2018-10-08",
"Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
"GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"AwsAccountId": "111122223333",
"Types": [
"Software & Configuration Checks/Patch Management/Compliance"
],
"CreatedAt": "2021-11-11T22:05:25Z",
"UpdatedAt": "2021-11-11T22:05:25Z",
"Severity": {
"Label": "INFORMATIONAL",
"Normalized": 0
},
"Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
"Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
"Remediation": {
"Recommendation": {
"Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
"Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
}
},
"SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
"ProductFields": {
"aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"aws/securityhub/ProductName": "Systems Manager Patch Manager",
"aws/securityhub/CompanyName": "AWS"
},
"Resources": [
{
"Type": "AwsEc2Instance",
"Id": "i-02573cafcfEXAMPLE",
"Partition": "aws",
"Region": "us-east-2"
}
],
"WorkflowState": "NEW",
"Workflow": {
"Status": "NEW"
},
"RecordState": "ACTIVE",
"PatchSummary": {
"Id": "pb-0c10e65780EXAMPLE",
"InstalledCount": 45,
"MissingCount": 2,
"FailedCount": 0,
"InstalledOtherCount": 396,
"InstalledRejectedCount": 0,
"InstalledPendingReboot": 0,
"OperationStartTime": "2021-11-11T22:05:06Z",
"OperationEndTime": "2021-11-11T22:05:25Z",
"RebootOption": "NoReboot",
"Operation": "SCAN"
}
}
```
## 打开并配置集成
要使用Patch Manager与 Security Hub CSPM 的集成，必须开启 Security Hub CSPM。有关如何开启 Security Hub CSPM 的信息，请参阅《AWS Security Hub 用户指南》**中的[设置 Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)。
以下程序介绍如何集成Patch Manager和 Security Hub CSPM（如果 Security Hub CSPM 已处于活动状态，但Patch Manager集成处于关闭状态）。只有在手动关闭集成时，才需要完成此过程。
**把Patch Manager添加到 Security Hub CSPM 集成**
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**设置**选项卡。
–或者–
如果您是在当前 AWS 区域首次访问 Patch Manager，请选择**从概览开始**，然后选择**设置**选项卡。
1. 在**导出到 Security Hub CSPM** 部分（在**补丁合规性调查发现未导出到 Security Hub** 的右侧），选择**启用**。
## 如何停止发送调查发现
要停止向 Security Hub CSPM 发送调查发现，您可以使用 Security Hub CSPM 控制台或 API。
有关更多信息，请参阅《AWS Security Hub 用户指南》**中的以下主题：
+ [禁用和启用来自集成的结果流（控制台）](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [禁用来自集成（Security Hub CSPM API，AWS CLI）的结果流](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# 使用 AWS CLI 处理 Patch Manager 资源使用
本节包含可用于为Patch Manager（AWS Systems Manager 中的一项工具）执行配置任务的 AWS Command Line Interface（AWS CLI）命令的示例。
有关通过 AWS CLI 使用自定义补丁基准对服务器环境进行修补的说明，请参阅[教程：使用 AWS CLI 修补服务器环境](patch-manager-patch-servers-using-the-aws-cli.md)。
有关使用 AWS CLI 完成 AWS Systems Manager 任务的更多信息，请参阅[AWS CLI 命令参考的 AWS Systems Manager 部分](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html)。
**Topics**
+ [AWS CLI 命令用于补丁基准](#patch-baseline-cli-commands)
+ [用于补丁组的 AWS CLI 命令](#patch-group-cli-commands)
+ [AWS CLI 命令用于查看补丁摘要和详细信息](#patch-details-cli-commands)
+ [用于扫描和修补托管式节点的 AWS CLI 命令](#patch-operations-cli-commands)
## AWS CLI 命令用于补丁基准
**Topics**
+ [创建补丁基准](#patch-manager-cli-commands-create-patch-baseline)
+ [创建对不同操作系统版本使用自定义存储库的补丁基准](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [更新补丁基准](#patch-manager-cli-commands-update-patch-baseline)
+ [重命名补丁基准](#patch-manager-cli-commands-rename-patch-baseline)
+ [删除补丁基准](#patch-manager-cli-commands-delete-patch-baseline)
+ [列出所有补丁基准](#patch-manager-cli-commands-describe-patch-baselines)
+ [列出所有 AWS 提供的补丁基准](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [列出我的补丁基准](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [显示补丁基准](#patch-manager-cli-commands-get-patch-baseline)
+ [获取默认补丁基准](#patch-manager-cli-commands-get-default-patch-baseline)
+ [将自定义补丁基准设置为默认基准](#patch-manager-cli-commands-register-default-patch-baseline)
+ [将 AWS 补丁基准重置为默认基准](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [标记补丁基准](#patch-manager-cli-commands-add-tags-to-resource)
+ [列出补丁基准的标签](#patch-manager-cli-commands-list-tags-for-resource)
+ [从补丁基准删除标签](#patch-manager-cli-commands-remove-tags-from-resource)
### 创建补丁基准
以下命令将创建一个补丁基准，该补丁基准将在 Windows Server 2012 R2 的关键和重要安全更新发布 5 天后批准所有这些更新。还为已批准和已拒绝的补丁列表指定了补丁。此外，补丁基准已标记来指示它适用于生产环境。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Windows-Server-2012R2" \
--tags "Key=Environment,Value=Production" \
--description "Windows Server 2012 R2, Important and Critical security updates" \
--approved-patches "KB2032276,MS10-048" \
--rejected-patches "KB2124261" \
--rejected-patches-action "ALLOW_AS_DEPENDENCY" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Windows-Server-2012R2" ^
--tags "Key=Environment,Value=Production" ^
--description "Windows Server 2012 R2, Important and Critical security updates" ^
--approved-patches "KB2032276,MS10-048" ^
--rejected-patches "KB2124261" ^
--rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 创建对不同操作系统版本使用自定义存储库的补丁基准
仅适用于 Linux 托管式节点。以下命令显示如何指定要用于特定版本的 Amazon Linux 操作系统的补丁存储库。此示例使用 Amazon Linux 2017.09 上默认启用的源存储库，但可以调整为您为托管式节点配置的不同源存储库。
**注意**
为了更好地说明这一更为复杂的命令，我们将 `--cli-input-json` 选项与存储在外部 JSON 文件中的其他选项结合使用。
1. 创建一个名称类似于 `my-patch-repository.json` 的 JSON 文件并将以下内容添加到其中。
```
{
"Description": "My patch repository for Amazon Linux 2",
"Name": "Amazon-Linux-2",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 7,
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": [
"Important",
"Critical"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"Security",
"Bugfix"
]
},
{
"Key": "PRODUCT",
"Values": [
"AmazonLinux2"
]
}
]
}
}
]
},
"Sources": [
{
"Name": "My-AL2",
"Products": [
"AmazonLinux2"
],
"Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
}
]
}
```
1. 在保存文件的目录中，键入以下命令。
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
系统将返回类似于以下内容的信息。
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 更新补丁基准
以下命令将两个带已拒绝状态的补丁和一个带已批准状态的补丁添加到现有补丁基准。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--rejected-patches "KB2032276" "MS10-048" \
--approved-patches "KB2124261"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--rejected-patches "KB2032276" "MS10-048" ^
--approved-patches "KB2124261"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001494.035,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 重命名补丁基准
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001795.287,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 删除补丁基准
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 列出所有补丁基准
```
aws ssm describe-patch-baselines
```
系统将返回类似于以下内容的信息。
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
以下是另一个命令，该命令将列出 AWS 区域 中的所有补丁基准。
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[All]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[All]"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### 列出所有 AWS 提供的补丁基准
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[AWS]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[AWS]"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### 列出我的补丁基准
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[Self]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[Self]"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### 显示补丁基准
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**注意**
对于自定义补丁基准，您可以指定补丁基准 ID 或完整的 Amazon Resource Name (ARN)。对于 AWS 提供的补丁基准，必须指定完整 ARN。例如 `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`。
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"PatchGroups":[
"Web Servers"
],
"RejectedPatches":[
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1480997823.81,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 获取默认补丁基准
```
aws ssm get-default-patch-baseline --region us-east-2
```
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 将自定义补丁基准设置为默认基准
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 将 AWS 补丁基准重置为默认基准
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 标记补丁基准
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tags "Key=Project,Value=Testing"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tags "Key=Project,Value=Testing"
```
------
### 列出补丁基准的标签
------
#### [ Linux & macOS ]
```
aws ssm list-tags-for-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm list-tags-for-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE"
```
------
### 从补丁基准删除标签
------
#### [ Linux & macOS ]
```
aws ssm remove-tags-from-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tag-keys "Project"
```
------
#### [ Windows Server ]
```
aws ssm remove-tags-from-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tag-keys "Project"
```
------
## 用于补丁组的 AWS CLI 命令
**Topics**
+ [创建补丁组](#patch-manager-cli-commands-create-patch-group)
+ [将补丁组“Web 服务器”注册到补丁基准](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [将补丁组“后端”注册到 AWS 提供的补丁基准](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [显示补丁组注册](#patch-manager-cli-commands-describe-patch-groups)
+ [从补丁基准取消注册补丁组](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### 创建补丁组
**注意**
补丁组不会用于基于*补丁策略*的修补操作。有关使用补丁策略的更多信息，请参阅 [Quick Setup 中的补丁策略配置](patch-manager-policies.md)。
为帮助您组织修补工作，我们建议您使用标签将托管式节点添加到补丁组。补丁组需要使用标签键 `Patch Group` 或 `PatchGroup`。如果[在 EC2 实例元数据中允许使用标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，则必须使用 `PatchGroup`（不带空格）。您可以指定任何标签值，但标签键必须为 `Patch Group` 或 `PatchGroup`。有关补丁组的更多信息，请参阅 [补丁组](patch-manager-patch-groups.md)。
使用标签对托管式节点进行分组后，请将补丁组值添加到补丁基准。通过将补丁组注册到补丁基准，您可以确保在修补操作期间安装正确的补丁。
#### 任务 1：请使用标签将 EC2 实例添加到补丁组
**注意**
使用 Amazon Elastic Compute Cloud (Amazon EC2) 控制台和 AWS CLI，则可以应用 `Key = Patch Group` 或 `Key = PatchGroup` 标签到尚未配置为与 Systems Manager 一起使用的实例。如果在应用 `Patch Group` 或 `Key = PatchGroup` 标签之后，未列出您希望在 Patch Manager 中看到的 EC2 实例，请参阅 [排除托管式节点可用性的问题](fleet-manager-troubleshooting-managed-nodes.md) 以获取故障排除技巧。
运行以下命令将 `PatchGroup` 标签添加到 EC2 实例。
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### 任务 2：使用标签将托管式节点添加到补丁组
运行以下命令以将 `PatchGroup` 标签添加到托管式节点。
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "ManagedInstance" \
--resource-id "mi-0123456789abcdefg" \
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "ManagedInstance" ^
--resource-id "mi-0123456789abcdefg" ^
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### 任务 3：将补丁组添加到补丁基准
运行以下命令将 `PatchGroup` 标签值关联到指定的补丁基准。
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Development"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Development"
```
------
系统将返回类似于以下内容的信息。
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 将补丁组“Web 服务器”注册到补丁基准
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Web Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Web Servers"
```
------
系统将返回类似于以下内容的信息。
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 将补丁组“后端”注册到 AWS 提供的补丁基准
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
--patch-group "Backend"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
--patch-group "Backend"
```
------
系统将返回类似于以下内容的信息。
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 显示补丁组注册
```
aws ssm describe-patch-groups --region us-east-2
```
系统将返回类似于以下内容的信息。
```
{
"PatchGroupPatchBaselineMappings":[
{
"PatchGroup":"Backend",
"BaselineIdentity":{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":false,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
},
{
"PatchGroup":"Web Servers",
"BaselineIdentity":{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":true,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
}
]
}
```
### 从补丁基准取消注册补丁组
------
#### [ Linux & macOS ]
```
aws ssm deregister-patch-baseline-for-patch-group \
--region us-east-2 \
--patch-group "Production" \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm deregister-patch-baseline-for-patch-group ^
--region us-east-2 ^
--patch-group "Production" ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
系统将返回类似于以下内容的信息。
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## AWS CLI 命令用于查看补丁摘要和详细信息
**Topics**
+ [获取补丁基准定义的所有补丁](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [获取 Amazonux2018.03 的所有分类为 `SECURITY` 、严重性为 `Critical` 的补丁](#patch-manager-cli-commands-describe-available-patches-linux)
+ [获取 Windows Server 2012 的所有补丁，其 MSRC 严重性为 `Critical`](#patch-manager-cli-commands-describe-available-patches)
+ [获取所有可用补丁](#patch-manager-cli-commands-describe-available-patches)
+ [获取每个托管式节点的补丁摘要状态](#patch-manager-cli-commands-describe-instance-patch-states)
+ [获取托管式节点的补丁合规性详细信息](#patch-manager-cli-commands-describe-instance-patches)
+ [查看修补合规性结果 (AWS CLI）](#viewing-patch-compliance-results-cli)
### 获取补丁基准定义的所有补丁
**注意**
此命令仅受 Windows Server 补丁基准的支持。
------
#### [ Linux & macOS ]
```
aws ssm describe-effective-patches-for-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm describe-effective-patches-for-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
系统将返回类似于以下内容的信息。
```
{
"NextToken":"--token string truncated--",
"EffectivePatches":[
{
"PatchStatus":{
"ApprovalDate":1384711200.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system
by installing this update from Microsoft. For a complete listing of the
issues that are included in this update, see the associated Microsoft
Knowledge Base article. After you install this update, you may have to
restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
"ReleaseDate":1384279200.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2876331",
"MsrcNumber":"MS13-089",
"Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
}
},
{
"PatchStatus":{
"ApprovalDate":1428858000.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"Windows Server 2012 R2 Update is a cumulative
set of security updates, critical updates and updates. You
must install Windows Server 2012 R2 Update to ensure that
your computer can continue to receive future Windows Updates,
including security updates. For a complete listing of the
issues that are included in this update, see the associated
Microsoft Knowledge Base article for more information. After
you install this item, you may have to restart your computer.",
"Classification":"SecurityUpdates",
"Title":"Windows Server 2012 R2 Update (KB2919355)",
"ReleaseDate":1428426000.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2919355",
"MsrcNumber":"MS14-018",
"Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
}
}
---output truncated---
```
### 获取 Amazonux2018.03 的所有分类为 `SECURITY` 、严重性为 `Critical` 的补丁
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
系统将返回类似于以下内容的信息。
```
{
"Patches": [
{
"AdvisoryIds": ["ALAS-2011-1"],
"BugzillaIds": [ "1234567" ],
"Classification": "SECURITY",
"CVEIds": [ "CVE-2011-3192"],
"Name": "zziplib",
"Epoch": "0",
"Version": "2.71",
"Release": "1.3.amzn1",
"Arch": "i686",
"Product": "AmazonLinux2018.03",
"ReleaseDate": 1590519815,
"Severity": "CRITICAL"
}
]
}
---output truncated---
```
### 获取 Windows Server 2012 的所有补丁，其 MSRC 严重性为 `Critical`
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
系统将返回类似于以下内容的信息。
```
{
"Patches":[
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 (KB2727528)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2727528",
"MsrcNumber":"MS12-072",
"Id":"1eb507be-2040-4eeb-803d-abc55700b715"
},
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Microsoft .NET Framework 3.5 on
Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2729462",
"MsrcNumber":"MS12-074",
"Id":"af873760-c97c-4088-ab7e-5219e120eab4"
}
---output truncated---
```
### 获取所有可用补丁
```
aws ssm describe-available-patches --region us-east-2
```
系统将返回类似于以下内容的信息。
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues
that are included in this update, see the associated Microsoft Knowledge Base
article. After you install this update, you may have to restart your system.",
"Id": "11adea10-0701-430e-954f-9471595ae246",
"KbNumber": "KB4074588",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518548400,
"Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based
Systems (KB4074588)",
"Vendor": "Microsoft"
},
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
"Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
"KbNumber": "KB4074590",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518544805,
"Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based
Systems (KB4074590)",
"Vendor": "Microsoft"
}
---output truncated---
```
### 获取每个托管式节点的补丁摘要状态
每个托管式节点的摘要可为您提供每个节点中具有以下状态的补丁数量：“NotApplicable”（不适用）、“Missing”（缺少）、“Failed”（失败）、“InstalledOther”（已安装其他）和“Installed”（已安装）。
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states \
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states ^
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
系统将返回类似于以下内容的信息。
```
{
"InstancePatchStates":[
{
"InstanceId": "i-08ee91c0b17045407",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
"InstalledCount": 50,
"InstalledOtherCount": 353,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 0,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 671,
"OperationStartTime": "2020-01-24T12:37:56-08:00",
"OperationEndTime": "2020-01-24T12:37:59-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
},
{
"InstanceId": "i-09a618aec652973a9",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
"InstalledCount": 36,
"InstalledOtherCount": 396,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 3,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 420,
"OperationStartTime": "2020-01-24T12:37:34-08:00",
"OperationEndTime": "2020-01-24T12:37:37-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
}
---output truncated---
```
### 获取托管式节点的补丁合规性详细信息
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
系统将返回类似于以下内容的信息。
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-libs.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:24-07:00"
},
{
"Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-utils.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:32-07:00"
},
{
"Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
"KBId": "dhclient.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:31-07:00"
},
---output truncated---
```
### 查看修补合规性结果 (AWS CLI）
**查看单个托管式节点的补丁合规性结果**
在 AWS Command Line Interface (AWS CLI) 中运行以下命令，查看单个托管式节点的补丁合规性结果。
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
以 `i-02573cafcfEXAMPLE` 或 `mi-0282f7c436EXAMPLE` 格式，将 *instance-id* 替换为要查看其结果的托管式节点的 ID。
系统将返回类似于以下内容的信息。
```
{
"InstancePatchStates": [
{
"InstanceId": "i-02573cafcfEXAMPLE",
"PatchGroup": "mypatchgroup",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
"CriticalNonCompliantCount": 2,
"SecurityNonCompliantCount": 2,
"OtherNonCompliantCount": 1,
"InstalledCount": 123,
"InstalledOtherCount": 334,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 1,
"FailedCount": 2,
"UnreportedNotApplicableCount": 11,
"NotApplicableCount": 2063,
"OperationStartTime": "2021-05-03T11:00:56-07:00",
"OperationEndTime": "2021-05-03T11:01:09-07:00",
"Operation": "Scan",
"LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
"RebootOption": "RebootIfNeeded"
}
]
}
```
**查看某个区域中所有 EC2 实例的补丁计数摘要**
`describe-instance-patch-states` 支持一次只检索一个托管实例的结果。但是，使用自定义脚本与 `describe-instance-patch-states` 命令，您可以生成更精细的报告。
例如，如果在本地计算机上安装 [jq 筛选工具](https://stedolan.github.io/jq/download/)，您可以运行以下命令来识别哪些 EC2 实例在特定 AWS 区域 中的状态为 `InstalledPendingReboot`。
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
*region* 表示 AWS Systems Manager 支持的 AWS 区域 的标识符，例如 `us-east-2` 对应美国东部（俄亥俄州）区域。有关支持的 *region* 值的列表，请参阅《Amazon Web Services 一般参考》**中的 [Systems Manager service endpoints](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) 的 **Region** 列。
例如：
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
系统将返回类似于以下内容的信息。
```
1 i-02573cafcfEXAMPLE
0 i-0471e04240EXAMPLE
3 i-07782c72faEXAMPLE
6 i-083b678d37EXAMPLE
0 i-03a530a2d4EXAMPLE
1 i-01f68df0d0EXAMPLE
0 i-0a39c0f214EXAMPLE
7 i-0903a5101eEXAMPLE
7 i-03823c2fedEXAMPLE
```
除了 `InstalledPendingRebootCount`，您可以搜索的计数类型列表包括以下内容：
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## 用于扫描和修补托管式节点的 AWS CLI 命令
运行以下命令来扫描补丁合规性或安装补丁后，可以使用 [AWS CLI 命令用于查看补丁摘要和详细信息](#patch-details-cli-commands) 部分里的命令来查看有关补丁状态和合规性的信息。
**Topics**
+ [扫描托管式节点以检查是否符合补丁合规性要求 (AWS CLI)](#patch-operations-scan)
+ [在托管式节点上安装补丁 (AWS CLI)](#patch-operations-install-cli)
### 扫描托管式节点以检查是否符合补丁合规性要求 (AWS CLI)
**扫描指定托管式节点以检查是否符合补丁合规性要求**
运行如下命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
系统将返回类似于以下内容的信息。
```
{
"Command": {
"CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974475.267,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621952275.267,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**按补丁组标签扫描托管式节点以检查是否符合补丁合规性要求**
运行如下命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
系统将返回类似于以下内容的信息。
```
{
"Command": {
"CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974983.128,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621952783.128,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
### 在托管式节点上安装补丁 (AWS CLI)
**在指定托管式节点上安装补丁**
运行如下命令。
**注意**
目标托管式节点按需重启以完成补丁安装。有关更多信息，请参阅 [用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
系统将返回类似于以下内容的信息。
```
{
"Command": {
"CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975301.791,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621953101.791,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**在指定补丁组中的托管式节点上安装补丁**
运行如下命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
-parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
系统将返回类似于以下内容的信息。
```
{
"Command": {
"CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975407.865,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621953207.865,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
# AWS Systems Manager Patch Manager 教程
本节中的教程演示如何针对各种修补场景使用Patch Manager（AWS Systems Manager 中的一项工具）。
**Topics**
+ [教程：在仅支持 IPv6 的环境中修补服务器](patch-manager-server-patching-iPv6-tutorial.md)
+ [教程：使用控制台创建用于安装 Windows Service Pack 的补丁基准](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [教程：使用控制台更新应用程序依赖项、修补托管式节点并执行特定于应用程序的运行状况检查](aws-runpatchbaselinewithhooks-tutorial.md)
+ [教程：使用 AWS CLI 修补服务器环境](patch-manager-patch-servers-using-the-aws-cli.md)
# 教程：在仅支持 IPv6 的环境中修补服务器
Patch Manager 支持对仅具有 IPv6 的环境中的节点进行修补。通过更新 SSM Agent 配置，可以将修补操作配置为仅调用 IPv6 服务端点。
**在仅支持 IPv6 的环境中修补服务器**
1. 确保托管式节点上安装了 SSM Agent 版本 3.3270.0 或更高版本。
1. 在托管节点上，导航到 SSM Agent 配置文件。您可以在以下目录中找到 `amazon-ssm-agent.json` 文件：
+ Linux：`/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
如果 `amazon-ssm-agent.json` 尚不存在，请将同一目录下的 `amazon-ssm-agent.json.template` 内容复制到 `amazon-ssm-agent.json`。
1. 更新以下条目以设置正确的区域并将 `UseDualStackEndpoint` 设置为 `true`：
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. 使用适用于您操作系统的命令重启 SSM Agent 服务：
+ Linux：`sudo systemctl restart amazon-ssm-agent`
+ 使用 Snap 的 Ubuntu Server：`sudo snap restart amazon-ssm-agent`
+ macOS：`sudo launchctl stop com.amazon.aws.ssm`，之后是 `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server：`Stop-Service AmazonSSMAgent`，之后是 `Start-Service AmazonSSMAgent`
有关每个操作系统的完整命令列表，请参阅 [正在检查 SSM Agent 状态并启动代理](ssm-agent-status-and-restart.md)。
1. 执行任何修补操作，以验证修补操作在仅支持 IPv6 的环境中是否成功。确保被修补的节点与补丁源有连接。您可以检查修补执行的 Run Command 输出，以检查有关无法访问的存储库的警告。在仅支持 IPv6 的环境中运行的节点上进行修补时，请确保该节点与补丁源有连接。您可以检查修补执行的 Run Command 输出，以检查有关无法访问的存储库的警告。对于基于 DNF 的操作系统，如果 `/etc/dnf/dnf.conf` 下的 `skip_if_unavailable` 选项设置为 `True`，则可以配置在修补期间跳过不可用的存储库。基于 DNF 的操作系统包括 Amazon Linux 2023、Red Hat Enterprise Linux 8 及更高版本、Oracle Linux 8 及更高版本、Rocky Linux、AlmaLinux 以及 CentOS 8 及更高版本。在 Amazon Linux 2023 上，`skip_if_unavailable` 选项默认设置为 `True`。
**注意**
使用“安装覆盖列表”或“基准覆盖”功能时，请确保提供的 URL 可从节点访问。如果将 SSM Agent 配置选项 `UseDualStackEndpoint` 设置为 `true`，则在提供 S3 URL 时将使用双堆栈 S3 客户端。
# 教程：使用控制台创建用于安装 Windows Service Pack 的补丁基准
创建自定义补丁基准时，可以指定安装所有、部分或仅安装一种支持的补丁。
在适用于 Windows 的补丁基准中，您可以选择 `ServicePacks` 作为唯一的 **Classification (分类)** 选项，以便将补丁更新仅限于 Service Pack。Patch Manager（AWS Systems Manager 中的一项工具）可以自动安装服务包，前提是此更新在 Windows Update 或 Windows Server Update Services（WSUS）中可用。
您可以配置补丁基准，以控制是安装所有 Windows 版本的 Service Pack，还是仅安装特定版本（如 Windows 7 或 Windows Server 2016）的 Service Pack。
使用以下过程创建自定义补丁基准，专门用于在 Windows 托管式节点上安装所有 Service Pack。
**创建用于安装 Windows Service Pack（控制台）的补丁基准**
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**补丁基准**选项卡，然后选择**创建补丁基准**。
1. 在 **Name (名称)** 中，输入新补丁基准的名称，例如，`MyWindowsServicePackPatchBaseline`。
1. （可选）对于 **Description (描述)**，输入此补丁基准的描述。
1. 对于 **Operating system**（操作系统），请选择 `Windows`。
1. 如果要在创建后即开始将此补丁基准用作 Windows 的默认项，请选择 **Set this patch baseline as the default patch baseline for Windows Server instances**（将此补丁基准设置为 Windows Server 实例的默认补丁基准）。
**注意**
只有在 2022 年 12 月 22 日 [补丁策略](patch-manager-policies.md) 发布之前首次访问 Patch Manager时，此选项才可用。
有关将现有补丁基准设置为默认项的信息，请参阅 [将现有补丁基准设置为默认项](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating systems (操作系统的批准规则)** 部分，使用字段创建一个或多个自动批准规则。
+ **产品**：批准规则适用的操作系统版本，例如 `WindowsServer2012`。您可以选择一个、多个或所有受支持的 Windows 版本。默认选择为 `All`。
+ **Classification (分类)**：选择 `ServicePacks`。
+ **Severity (严重性)**：规则适用于的补丁的严重性值。要确保规则包含所有 Service Pack，请选择 `All`。
+ **Auto-approval**（自动批准）：选择要自动批准的补丁的方法。
+ **在指定的天数后批准补丁**：Patch Manager 在发布或更新补丁之后等待的天数，然后自动批准补丁。可以输入零 (0) 到 360 的任何整数。对于大多数情况，我们建议等待期不超过 100 天。
+ **批准在特定日期之前发布的补丁**：补丁发布日期，Patch Manager 自动应用在该日期或之前发布或更新的所有补丁。例如，如果指定 2023 年 7 月 7 日，则不会自动安装在 2023 年 7 月 8 日或之后发布或最后更新的任何补丁。
+ （可选）**Compliance reporting (合规性报告)**：要分配给由基准批准的 Service Pack 的严重性级别，例如 `High`。
**注意**
如果您指定合规性报告级别以及任何已批准 Service Pack 的补丁状态报告为 `Missing`，则补丁基准报告的总体合规性严重性级别就是您指定的严重级别。
1. （可选）对于**管理标签**，将一个或多个标签键名称/值对应用到补丁基准。
标签是您分配给资源的可选元数据。标签允许您按各种标准（如用途、所有者或环境）对资源进行分类。对于专用于更新 Service Pack 的此补丁基准，您可以指定键值对，如下所示：
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. 请选择**创建补丁基准**。
# 教程：使用控制台更新应用程序依赖项、修补托管式节点并执行特定于应用程序的运行状况检查
在许多情况下，在使用最新软件更新修补托管式节点后必须将其重启。但是，在没有安全措施的情况下重启生产中的节点可能会导致若干问题，例如调用告警、记录不正确的指标数据以及中断数据同步。
本教程将演示为了避免上述类似问题，如何通过使用 AWS Systems Manager 文档（SSM 文档）`AWS-RunPatchBaselineWithHooks` 来实现复杂的多步骤修补操作，该操作可完成以下事项：
1. 防止新连接到应用程序
1. 安装操作系统更新
1. 更新应用程序的软件包依赖项
1. 重启系统
1. 执行特定于应用程序的运行状况检查
在此示例中，我们以这种方式设置了我们的基础设施：
+ 目标虚拟机在 Systems Manager 中注册为托管式节点。
+ `Iptables` 作本地防火墙。
+ 托管式节点上托管的应用程序正在端口 443 上运行。
+ 托管式节点上托管的应用程序是 `nodeJS` 应用程序。
+ 托管式节点上托管的应用程序由 pm2 进程管理器管理。
+ 应用程序已经具有指定的运行状况检查终端节点。
+ 应用程序的运行状况检查终结点不需要终端用户身份验证。终端节点允许进行运行状况检查，以满足组织在建立可用性方面的要求。（在您的环境中，可能只需确定正在运行 `nodeJS` 应用程序，并且能够侦听请求。在其他情况下，您可能还需要验证是否已建立到缓存层或数据库层的连接。）
本教程中的示例仅用于演示目的，并不意味着按原样实施到生产环境中。另请注意，Patch Manager（Systems Manager 中的一项工具）的生命周期挂钩功能和 `AWS-RunPatchBaselineWithHooks` 文档搭配使用，可以支持许多其他场景。下面是几个示例。
+ 在修补之前停止指标报告代理，并在托管式节点重启后重启该代理。
+ 在进行修补之前，将托管式节点与 CRM 或 PCS 集群分离，并在节点重启后重新连接。
+ 在应用操作系统 (OS) 更新之后、托管式节点重启之前，在 Windows Server 计算机上更新第三方软件（例如，Java、Tomcat、Adobe 应用程序等）。
**更新应用程序依赖项、修补托管式节点并执行特定于应用程序的运行状况检查**
1. 使用以下内容为预安装脚本创建 SSM 文档，并将其命名为 `NodeJSAppPrePatch`。将*您的应用程序*替换为应用程序的名称。
此脚本会立即阻止新的传入请求，并在开始修补操作之前为已经激活的请求提供 5 秒钟的完成时间。对于 `sleep` 选项，请指定一个比传入请求完成通常所需秒数大的秒数。
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
有关创建 SSM 文档的信息，请参阅 [创建 SSM 文档内容](documents-creating-content.md)。
1. 为安装后脚本创建包含以下内容的另一个 SSM 文档，以更新应用程序依赖项，并将其命名为 `NodeJSAppPostPatch`。将*/您的/应用程序/路径*替换为通向您的应用程序的路径。
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. 创建另一个包含以下内容的 SSM 文档，其中的 `onExit` 脚本使应用程序备份并执行运行状况检查。命名此 SSM 文档为 `NodeJSAppOnExitPatch`。将*您的应用程序*替换为您的应用程序的名称。
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. 在State Manager（AWS Systems Manager 中的一项工具）中创建关联，通过执行下列步骤发出操作：
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，选择 **State Manager**，然后选择**创建关联**。
1. 对于**名称**，请提供一个名称来帮助标识关联的用途。
1. 在**文档**列表中，选择 `AWS-RunPatchBaselineWithHooks`。
1. 对于**操作**，选择**安装**。
1. （可选）对于**快照 ID**，提供您生成的 GUID，以帮助加快操作速度并确保一致性。GUID 值可以像 `00000000-0000-0000-0000-111122223333` 一样简单。
1. 对于**安装前钩子文档名称**，输入 `NodeJSAppPrePatch`。
1. 对于**安装后钩子文档名称**，输入 `NodeJSAppPostPatch`。
1. 对于**针对 ExitHook 文档名称**，输入 `NodeJSAppOnExitPatch`。
1. 对于 **Targets**（目标），通过指定标签、手动选择节点、选择资源组或选择所有托管式节点来标识托管式节点。
1. 对于**指定时间表**，指定运行关联的频率。对于托管式节点修补，每周修补一次是常见的节奏。
1. 在 **Rate control**（速率控制）部分中，选择用于控制如何在多个托管式节点上运行关联的选项。确保一次只更新部分托管式节点。否则，您的所有或大部分队列都可以同时离线。有关使用速率控制的更多信息，请参阅 [了解 State Manager 关联中的目标和速率控制](systems-manager-state-manager-targets-and-rate-controls.md)。
1. （可选）对于 **Output options (输出选项)**，要将命令输出保存到文件，请选中 **Enable writing output to S3 (启用将输出写入 S3)** 方框。在方框中输入存储桶和前缀（文件夹）名称。
**注意**
授予将数据写入 S3 存储桶的能力的 S3 权限，是分配给托管式节点的实例配置文件的权限，而不是执行此任务的 IAM 用户的权限。有关更多信息，请参阅[配置 Systems Manager 所需的实例权限](setup-instance-permissions.md)或[为混合环境创建 IAM 服务角色](hybrid-multicloud-service-role.md)。此外，如果指定的 S3 存储桶位于不同的 AWS 账户 中，请确认与该托管式节点关联的实例配置文件或 IAM 服务角色具有写入该存储桶的所需权限。
1. 选择**创建关联**。
# 教程：使用 AWS CLI 修补服务器环境
以下过程介绍如何使用自定义补丁基准、补丁组和维护时段来修补服务器环境。
**开始前的准备工作**
+ 在托管式节点上安装或更新 SSM Agent。要修补 Linux 托管式节点，节点必须运行 SSM Agent 2.0.834.0 版或更高版本。有关更多信息，请参阅 [使用 Run Command 更新 SSM Agent](run-command-tutorial-update-software.md#rc-console-agentexample)。
+ 配置 Maintenance Windows（AWS Systems Manager 中的一项工具）的角色和权限。有关更多信息，请参阅 [设置 Maintenance Windows](setting-up-maintenance-windows.md)。
+ 安装并配置 AWS Command Line Interface（AWS CLI）（如果尚未执行该操作）。
有关信息，请参阅[安装或更新 AWS CLI 的最新版本](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。
**配置 Patch Manager 并修补托管式节点（命令行）**
1. 运行以下命令以创建名为 `Production-Baseline` 的适用于 Windows 的补丁基准。此补丁基准会在补丁发布或最后更新 7 天后批准用于生产环境。即，我们已标记补丁基准，以指示它适用于生产环境。
**注意**
`OperatingSystem` 参数和 `PatchFilters` 因补丁基准应用到的目标托管式节点的操作系统而异。有关详细信息，请参阅 [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) 和 [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
系统将返回类似于以下内容的信息。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 运行以下命令为两个补丁组注册“生产-基准”补丁基准。这些组命名为“数据库服务器”和“前端服务器”。
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
系统将返回类似于以下内容的信息。
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
系统将返回类似于以下内容的信息。
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 运行以下命令为生产服务器创建两个维护时段。第一个时段在每周二晚上 10 点运行。第二个时段在每周六晚上 10 点运行。此外，维护时段已标记来指示它适用于生产环境。
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
系统将返回类似于以下内容的信息。
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
系统将返回类似于以下内容的信息。
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. 运行以下命令，将 `Database` 和 `Front-End` 服务器补丁组注册到其各自的维护时段。
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
系统将返回类似于以下内容的信息。
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
系统将返回类似于以下内容的信息。
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. 运行以下命令注册一个补丁任务，该任务在 `Database` 和 `Front-End` 服务器各自的维护时段内安装缺少的更新。
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
系统将返回类似于以下内容的信息。
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
系统将返回类似于以下内容的信息。
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. 运行以下命令以获取补丁组的高级补丁合规性摘要。概括性补丁合规性摘要包括补丁处于相应状态的托管式节点的数量。
**注意**
在第一个维护时段内，在补丁任务运行之前，预计会在摘要中看到托管式节点数量为零。
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
系统将返回类似于以下内容的信息。
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. 运行以下命令以获取补丁组的每个托管式节点的补丁摘要状态。每个托管式节点摘要包括处于相应补丁状态的许多补丁（按补丁组的每个托管式节点划分）。
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
系统将返回类似于以下内容的信息。
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
有关可以用于 Patch Manager 配置任务的其他 AWS CLI 命令的示例，请参阅 [使用 AWS CLI 处理 Patch Manager 资源使用](patch-manager-cli-commands.md)。
# 排除 Patch Manager 问题
利用以下信息，帮助排查Patch Manager（AWS Systems Manager 中的一项工具）出现的问题。
**Topics**
+ [问题：`baseline_overrides.json` 出现“Invoke-PatchBaselineOperation : Access Denied”错误或“Unable to download file from S3”错误](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [问题：修补失败，没有明显的原因或错误消息](#race-condition-conflict)
+ [问题：意外的补丁合规结果](#patch-manager-troubleshooting-compliance)
+ [在 Linux 上运行 `AWS-RunPatchBaseline` 时出现的错误](#patch-manager-troubleshooting-linux)
+ [在 Windows Server 上运行 `AWS-RunPatchBaseline` 时出现错误](#patch-manager-troubleshooting-windows)
+ [在 macOS 上运行 `AWS-RunPatchBaseline` 时出现错误](#patch-manager-troubleshooting-macos)
+ [使用 AWS 支持 Automation 运行手册](#patch-manager-troubleshooting-using-support-runbooks)
+ [联系 AWS 支持](#patch-manager-troubleshooting-contact-support)
## 问题：`baseline_overrides.json` 出现“Invoke-PatchBaselineOperation : Access Denied”错误或“Unable to download file from S3”错误
**问题**：运行补丁策略指定的修补操作时，您会收到类似于以下示例的错误。
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**原因**：您在 Quick Setup 中创建了补丁策略，并且某些托管式节点已附加了实例配置文件（适用于 EC2 实例）或服务角色（适用于非 EC2 计算机）。
但是，如下图所示，您未选中**将所需的 IAM 策略添加到附加到实例的现有实例配置文件**复选框。
![\[\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
创建补丁策略时，还会创建一个 Amazon S3 存储桶来存储策略的配置 `baseline_overrides.json` 文件。如果您在创建策略时未选中**将所需的 IAM 策略添加到附加到实例的现有实例配置文件**复选框，则在 S3 存储桶中访问 `baseline_overrides.json` 所需的 IAM 策略和资源标签不会自动添加到现有 IAM 实例配置文件和服务角色中。
**解决方案 1**：删除现有的补丁策略配置，然后创建替代策略配置，确保选中**将所需的 IAM 策略添加到附加到实例的现有实例配置文件**复选框。此选择会将此 Quick Setup 配置创建的 IAM 策略应用于已附加实例配置文件或服务角色的节点。（默认情况下，Quick Setup 向还*没有*实例配置文件或服务角色的实例和节点添加所需策略。） 有关更多信息，请参阅 [Automate organization-wide patching using a Quick Setup patch policy](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)。
**解决方案 2**：手动将所需的权限和标签添加到与 Quick Setup 一起使用的每个 IAM 实例配置文件和 IAM 服务角色。有关说明，请参阅[补丁策略 S3 存储桶的权限](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions)。
## 问题：修补失败，没有明显的原因或错误消息
**问题**：修补操作失败，但未返回错误消息。
**可能的原因**：修补托管式节点时，即使已成功安装补丁，文档执行也可能会中断并标记为失败。如果系统在修补操作期间启动意外重启（例如，将更新应用于固件或诸如 SecuReboot 之类的功能），则可能会发生这种情况。SSM Agent 无法在外部重启后保持和恢复文档执行状态，从而导致执行被报告为失败。
**解决方案**：要在执行失败后验证补丁安装状态，请运行 `Scan` 修补操作，然后在补丁管理器中检查补丁合规性数据，进而评测当前的合规性状态。
如果确定外部重启不是导致这种情况失败的原因，我们建议联系 [AWS 支持](#patch-manager-troubleshooting-contact-support)。
## 问题：意外的补丁合规结果
**问题**：在 `Scan` 操作后查看生成的修补合规性详细信息时，结果中包含的信息不符合补丁基准中设置的规则。例如，您在补丁基准中添加到 **Rejected patches**（已拒绝补丁）列表中的异常被列为 `Missing`。或者，即使您的补丁基准仅指定 `Critical` 补丁，分类为 `Important` 的补丁也被列为缺失。
**原因**：Patch Manager 目前支持运行 `Scan` 操作的多种方法：
+ Quick Setup 中配置的补丁策略
+ Quick Setup 中配置的主机管理选项
+ 运行补丁 `Scan` 或 `Install` 任务的维护时段
+ 按需 **Patch now**（立即修补）操作
运行 `Scan` 操作时，它会覆盖最近扫描的合规性详细信息。如果您设置了多个方法来运行 `Scan` 操作，并且这些方法使用不同的补丁基准和不同的规则，那么它们会导致不同的补丁合规结果。
**解决方案**：为避免出现意外的补丁合规结果，我们建议一次仅使用一种方法来运行 Patch Manager `Scan` 操作。有关更多信息，请参阅 [识别创建补丁合规性数据的执行](patch-manager-compliance-data-overwrites.md)。
## 在 Linux 上运行 `AWS-RunPatchBaseline` 时出现的错误
**Topics**
+ [问题：“没有这样的文件或目录”错误](#patch-manager-troubleshooting-linux-1)
+ [问题：“另一个进程已获得 yum 锁定” 错误](#patch-manager-troubleshooting-linux-2)
+ [问题：“权限拒绝/未能运行命令” 错误](#patch-manager-troubleshooting-linux-3)
+ [问题：“Unable to download payload”错误](#patch-manager-troubleshooting-linux-4)
+ [问题：“不支持的软件包管理器和 python 版本组合” 错误](#patch-manager-troubleshooting-linux-5)
+ [问题：Patch Manager 没有应用指定来排除某些软件包的规则](#patch-manager-troubleshooting-linux-6)
+ [问题：修补失败同时 Patch Manager 报告 TLS 的服务器名称指示扩展不可用](#patch-manager-troubleshooting-linux-7)
+ [问题:Patch Manager 报告“没有更多的镜像要尝试”](#patch-manager-troubleshooting-linux-8)
+ [问题：修补失败并显示消息“Error code returned from curl is 23”](#patch-manager-troubleshooting-linux-9)
+ [问题：修补失败并显示消息“Error unpacking rpm package…”](#error-unpacking-rpm)
+ [问题：修补失败并显示消息“上传清单时出现服务端错误”](#inventory-upload-error)
+ [问题：修补失败并显示消息“Errors were encountered while downloading packages”](#errors-while-downloading)
+ [问题：修补失败并出现内存不足（OOM）错误](#patch-manager-troubleshooting-linux-oom)
+ [问题：修补失败并显示消息“The following signatures couldn't be verified because the public key is not available”](#public-key-unavailable)
+ [问题：修补失败并显示消息“NoMoreMirrorsRepoError”](#no-more-mirrors-repo-error)
+ [问题：修补失败并显示消息“Unable to download payload”](#payload-download-error)
+ [问题：修补失败并显示消息“install errors: dpkg: error: dpkg frontend is locked by another process”](#dpkg-frontend-locked)
+ [问题：Ubuntu Server 上的修补失败并出现“dpkg was interrupted”错误](#dpkg-interrupted)
+ [问题：程序包管理器实用工具无法解析包依赖项](#unresolved-dependency)
+ [问题：SLES 托管节点上的 Zypper 软件包锁定依赖项故障](#patch-manager-troubleshooting-linux-zypper-locks)
+ [问题：无法获取锁。另一个修补操作正在进行中。](#patch-manager-troubleshooting-linux-concurrent-lock)
### 问题：“没有这样的文件或目录”错误
**问题**：当您运行 `AWS-RunPatchBaseline` 时，修补失败，并出现以下错误之一。
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**原因 1**：要运行 `AWS-RunPatchBaseline` 的两个命令同时在同一托管式节点上运行。这将创建一个竞争条件，导致临时 `file patch-baseline-operations*` 未能正确创建或访问。
**原因 2**：`/var` 目录中的存储空间依然不足。
**解决方案 1**：确保维护时段没有具有相同的优先级并且在相同的目标 ID 上运行的两个或多个运行 `AWS-RunPatchBaseline` 的 Run Command 任务。如果是这种情况，请重新排序优先级。Run Command 是 AWS Systems Manager 中的一项工具。
**解决方案 2**：确保一次只有一个维护时段正在运行 Run Command 任务，该任务对相同的目标、在相同的时间表上使用 `AWS-RunPatchBaseline`。如果出现这种情况，请更改时间表。
**解决方案 3**：确保按照相同的计划只有一个State Manager关联正在运行 `AWS-RunPatchBaseline`，并针对相同的托管式节点。State Manager是 AWS Systems Manager 中的一项工具。
**解决方案 4**：在 `/var` 目录中为更新程序包释放足够的存储空间。
### 问题：“另一个进程已获得 yum 锁定” 错误
**问题**：当您运行 `AWS-RunPatchBaseline` 时，修补失败并显示以下错误。
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**原因**：`AWS-RunPatchBaseline` 文档已经开始在某个托管式节点上运行（在该节点中，该文档已在其他操作中运行），并且已获得软件包管理器 `yum` 进程。
**解决方案**：确保按计划运行 `AWS-RunPatchBaseline` 的 State Manager 关联、维护时段任务或其他配置不会在几乎同一时间针对相同的托管节点。
### 问题：“权限拒绝/未能运行命令” 错误
**问题**：当您运行 `AWS-RunPatchBaseline`，则修补失败并显示以下错误。
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**原因**：`/var/lib/amazon/` 可能会使用 `noexec` 权限。这是一个问题，因为 SSM Agent 把有效载荷脚本下载到 `/var/lib/amazon/ssm` 并从该位置运行它们。
**解决方案**：确保您已将独占分区配置为 `/var/log/amazon` 和 `/var/lib/amazon`，并且它们挂载了 `exec` 权限。
### 问题：“Unable to download payload”错误
**问题**：当您运行 `AWS-RunPatchBaseline` 时，修补失败并显示以下错误。
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**原因**：托管式节点没有访问指定的 Amazon Simple Storage Service (Amazon S3) 存储桶所需的权限。
**解决方案**：更新您的网络配置，以便可访问 S3 端点。有关更多详细信息，请参阅 [SSM Agent 与 AWS 托管 S3 存储桶进行通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 中 Patch Manager 对 S3 存储桶的所需访问。
### 问题：“不支持的软件包管理器和 python 版本组合” 错误
**问题**：当您运行 `AWS-RunPatchBaseline` 时，修补失败并显示以下错误。
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**原因**：Debian Server 或 Ubuntu Server 实例上未安装受支持版本的 python3。
**解决方案**：在服务器上安装受支持版本的 python3（3.0 - 3.12），Debian Server 和 Ubuntu Server 托管节点必须使用这些版本。
### 问题：Patch Manager 没有应用指定来排除某些软件包的规则
**问题**：您试图排除某些软件包，方法是在 `/etc/yum.conf` 文件中指定这些软件包，格式为 `exclude=package-name`，但在 Patch Manager `Install` 操作期间不排除它们。
**原因**：Patch Manager 不包含 `/etc/yum.conf` 文件中指定的排除项。
**解决方案**：要排除特定软件包，请创建自定义补丁基准并创建排除不想安装的软件包的规则。
### 问题：修补失败同时 Patch Manager 报告 TLS 的服务器名称指示扩展不可用
**问题**：修补操作发出以下消息。
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**原因**：此消息不表示错误存在。相反，这是一个警告，即随操作系统一起分发的较旧版本的 Python 不支持 TLS 服务器名称指示。在连接到支持 SNI 的 AWS API 时，Systems Manager 补丁有效载荷脚本发出此警告。
**解决方案**：若要在报告此消息时解决任何修补失败问题，请查看 `stdout` 和 `stderr` 文件的内容。如果您尚未配置补丁基准以将这些文件存储在 S3 存储桶或 Amazon CloudWatch Logs 中，则可以在 Linux 托管节点上的以下位置找到这些文件。
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### 问题:Patch Manager 报告“没有更多的镜像要尝试”
**问题**：修补操作发出以下消息。
```
[Errno 256] No more mirrors to try.
```
**原因**：在托管式节点上配置的存储库无法正常工作。可能的原因包括：
+ `yum` 缓存已损坏。
+ 由于网络相关问题，无法访问存储库 URL。
**解决方案**：Patch Manager 使用托管式节点的默认软件包管理器执行修补操作。双重检查存储库是否已配置并正常运行。
### 问题：修补失败并显示消息“Error code returned from curl is 23”
**问题**：使用 `AWS-RunPatchBaseline` 的修补操作失败，并出现类似以下内容的错误：
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**原因**：系统上使用的 curl 工具缺少写入文件系统所需的权限。如果程序包管理器的默认 curl 工具被其他版本（例如随 snap 安装的版本）所取代，则可能会发生这种情况。
**解决方案**：如果安装其他版本时卸载了程序包管理器提供的 curl 版本，请重新安装。
如果您需要安装多个 curl 版本，请确保与程序包管理器关联的版本位于 `PATH` 变量中列出的第一个目录中。您可以通过运行命令 `echo $PATH` 来查看系统上检查可执行文件的目录的当前顺序。
### 问题：修补失败并显示消息“Error unpacking rpm package…”
**问题**：修补操作失败，并出现类似以下内容的错误：
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**原因 1**：特定程序包存在于多个程序包安装程序（例如 `pip` 和 `yum` 或 `dnf`）中时，使用默认程序包管理器时可能会发生冲突。
一个常见的示例是 `urllib3` 程序包，可以在 `pip`、`yum` 和 `dnf` 中找到。
**原因 2**：`python-urllib3` 程序包已损坏。如果 `yum` 或 `dnf` 先前安装了 `rpm` 程序包之后，`pip` 安装或更新了程序包文件，则可能会发生这种情况。
**解决方案**：通过运行命令 `sudo pip uninstall urllib3` 从 pip 中删除 `python-urllib3` 程序包，仅将此程序包保留在默认程序包管理器（`yum` 或 `dnf`）中。
### 问题：修补失败并显示消息“上传清单时出现服务端错误”
**问题**：运行 `AWS-RunPatchBaseline` 文档时，收到以下错误消息：
```
Encounter service side error when uploading the inventory
```
**原因**：要运行 `AWS-RunPatchBaseline` 的两个命令同时在同一托管式节点上运行，这导致在修补操作期间初始化 boto3 客户端时产生了争用条件。
**解决方案**：确保按计划运行 `AWS-RunPatchBaseline` 的 State Manager 关联、维护时段任务或其他配置不会在几乎同一时间针对相同的托管节点。
### 问题：修补失败并显示消息“Errors were encountered while downloading packages”
**问题**：在修补期间，您会收到类似以下内容的错误：
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**原因**：托管式节点上的可用内存不足时，可能会发生此错误。
**解决方案**：配置交换内存，或将实例升级到其他类型以增加内存。然后开始新的修补操作。
### 问题：修补失败并出现内存不足（OOM）错误
**问题**：运行 `AWS-RunPatchBaseline` 时，由于托管式节点上内存不足，修补操作失败。您可能会看到诸如 `Cannot allocate memory`、`Killed`（来自 Linux OOM Killer）之类的错误，或者操作意外失败。在 RAM 小于 1 GB 的实例上出现此错误的可能性更高，但有大量可用更新时也可能会影响内存较大的实例。
**原因**：Patch Manager 在托管式节点上使用原生软件包管理器运行修补操作。修补操作期间所需的内存取决于多个因素，包括：
+ 托管式节点上安装的软件包和可用更新数量。
+ 正在使用的软件包管理器及其内存特性。
+ 执行修补操作时托管式节点上运行的其他进程。
对于安装了大量软件包或有大量可用更新的托管式节点，执行修补操作期间将需要更多内存。当可用内存不足时，修补进程将会失败退出并显示错误。操作系统也可能会终止修补进程。
**解决方法**：尝试以下一种或多种解决方法：
+ 在托管式节点上工作负载较低的时段安排修补操作，例如使用维护时段。
+ 将实例升级到具有更多内存的类型。
+ 在托管式节点上配置交换内存。请注意，在 EBS 吞吐量有限的实例上大量使用交换可能会导致性能下降。
+ 检查并减少修补操作期间在托管式节点上运行的进程数量。
### 问题：修补失败并显示消息“The following signatures couldn't be verified because the public key is not available”
**问题**：Ubuntu Server 上的修补失败，并出现类似以下内容的错误：
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**原因**：GNU 隐私保护（GPG）密钥已过期或丢失。
**解决方案**：刷新 GPG 密钥，或者重新添加密钥。
例如，借助之前显示的错误，我们发现 `467B942D3A79BD29` 密钥丢失，必须添加此密钥。为此，请运行以下命令之一：
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
或者，要刷新所有密钥，请运行以下命令：
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
如果之后再次出现此错误，我们建议将问题报告给维护存储库的组织。在修复可用之前，您可以编辑 `/etc/apt/sources.list` 文件以在修补过程中省略存储库。
为此，请打开 `sources.list` 文件进行编辑，找到存储库所在的行，然后在行首插入 `#` 字符将其注释掉。保存并关闭此文件。
### 问题：修补失败并显示消息“NoMoreMirrorsRepoError”
**问题**：您会收到类似以下内容的错误：
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**原因**：源存储库中存在错误。
**解决方案**：我们建议将问题报告给维护存储库的组织。在错误修复之前，您可以在操作系统级别禁用存储库。为此，请运行以下命令，将 *repo-name* 的值替换为存储库名称：
```
yum-config-manager --disable repo-name
```
以下为示例。
```
yum-config-manager --disable pgdg94
```
运行此命令后，再次执行修补操作。
### 问题：修补失败并显示消息“Unable to download payload”
**问题**：您会收到类似以下内容的错误：
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**原因**：托管式节点配置存在错误或不完整。
**解决方案**：确保托管式节点配置如下：
+ 安全组中的出站 TCP 443 规则。
+ NACL 中的出口 TCP 443 规则。
+ NACL 中的入口 TCP 1024-65535 规则。
+ 路由表中的 NAT/IGW 用于提供与 S3 端点的连接。如果实例无法访问互联网，请为其提供与 S3 端点的连接。为此，请在 VPC 中添加 S3 网关端点，并将其与托管式节点的路由表集成。
### 问题：修补失败并显示消息“install errors: dpkg: error: dpkg frontend is locked by another process”
**问题**：修补失败，并出现类似以下内容的错误：
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**原因**：程序包管理器已经在操作系统级别的托管式节点上运行另一个进程。如果其他进程需要很长时间才能完成，则 Patch Manager 修补操作可能会超时并失败。
**解决方案**：使用程序包管理器的其他进程完成后，执行新的修补操作。
### 问题：Ubuntu Server 上的修补失败并出现“dpkg was interrupted”错误
**问题**：在 Ubuntu Server 上，修补失败并出现类似以下内容的错误：
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**原因**：一个或多个程序包配置错误。
**解决方案**：执行以下步骤：
1. 通过依次运行以下命令来检查受影响的程序包，以及每个程序包存在的问题：
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. 通过运行以下命令更正有问题的程序包：
```
sudo dpkg --configure -a
```
1. 如果之前的命令未完全解决问题，可运行以下命令：
```
sudo apt --fix-broken install
```
### 问题：程序包管理器实用工具无法解析包依赖项
**问题**：托管式节点上的本机程序包管理器无法解析程序包依赖项，修补失败。以下错误消息示例指示使用 `yum` 作为程序包管理器的操作系统上的此类故障。
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**原因**：在 Linux 操作系统上，Patch Manager 使用计算机上的本机程序包管理器来执行修补操作。例如 `yum`、`dnf`、`apt` 和 `zypper`。应用程序会根据需要自动检测、安装、更新或删除从属程序包。但是，某些情况可能会导致程序包管理器无法完成依赖项操作，例如：
+ 操作系统上配置了多个相互冲突的存储库。
+ 由于网络相关问题，无法访问远程存储库 URL。
+ 存储库中发现了错误架构的包。
**解决方案**：由于各种原因，依赖项可能会导致修补失败。因此，我们建议您联系 AWS 支持 以帮助您进行故障排除。
### 问题：SLES 托管节点上的 Zypper 软件包锁定依赖项故障
**问题**：使用 `Install` 操作在 SUSE Linux Enterprise Server 实例上运行 `AWS-RunPatchBaseline` 时，修补程序失败，并出现与软件包锁定相关的依赖项检查错误。您可能会看到类似于以下内容的错误消息：
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
在此示例中，软件包 `mock-pkg-standalone` 已锁定，您可以通过运行 `sudo zypper locks` 并在输出中查找软件包名称来进行验证。
或者您可能会看到指示依赖项检查失败的日志条目：
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**注意**
该问题仅在 `Install` 操作期间出现。`Scan` 操作不应用软件包锁定，也不受现有软件包锁定的影响。”
**原因**：当 zypper 软件包锁定由于依赖项冲突而阻止安装或更新软件包时，就会发生这种错误。软件包锁定可能由若干原因所致：
+ **客户应用的锁定**：您或您的系统管理员使用 zypper 命令（例如 `zypper addlock`）手动锁定了软件包。
+ **Patch Manager 拒绝修补**：当您在补丁基准的“**拒绝的修补程序**”列表中指定软件包时，Patch Manager 会自动应用软件包锁定以阻止安装软件包。
+ **操作中断产生的残留锁**：在极少数情况下，如果修补操作在 Patch Manager 清理临时锁之前中断（例如系统重启），则在托管节点上可能会留存残留的软件包锁。
**解决方案**：要解决 zypper 软件包锁定的问题，请根据原因执行以下步骤：
**步骤 1：确定已锁定的软件包**
连接到 SLES 托管节点并运行以下命令，列出所有当前锁定的软件包：
```
sudo zypper locks
```
**步骤 2：确定锁的来源**
+ 如果锁定的软件包是您出于系统稳定性而故意锁定的，请考虑软件包是否需要保持锁定状态，或者是否可以临时解锁以进行修补。
+ 如果锁定的软件包与补丁基准的“**拒绝的修补程序**”列表中的条目相匹配，则表明这些软件包可能是因为修补操作中断而产生的残留锁。在正常操作中，Patch Manager 会临时应用这些锁定，并在操作完成后自动移除。您可以从拒绝列表中移除软件包，也可以修改补丁基准的规则。
+ 如果无法识别锁定的软件包，并且软件包不是故意锁定的，则可能是之前中断的修补操作产生的残留锁。
**第 3 步：根据需要移除锁定**
要移除特定的软件包锁定，请使用以下命令：
```
sudo zypper removelock package-name
```
要移除所有软件包锁定（谨慎使用），请运行：
```
sudo zypper cleanlocks
```
**步骤 4：更新补丁基准（如适用）**
如果锁定是由补丁基准中拒绝的修补程序造成的：
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Patch Manager**。
1. 选择**补丁基准**选项卡，然后选择自定义补丁基准。
1. 选择**操作**、**修改补丁基准**。
1. 在“**拒绝的修补程序**”部分，查看列出的软件包并移除应允许安装的任何软件包。
1. 选择**保存更改**。
**步骤 5：重试修补操作**
移除有问题的锁定并根据需要更新补丁基准之后，请再次运行 `AWS-RunPatchBaseline` 文档。
**注意**
Patch Manager 在 `Install` 操作期间对拒绝的修补程序应用锁定时，其设计旨在于修补操作完成后自动清理这些锁。如果在运行 `sudo zypper locks` 时看到了这些锁定，则表示之前的修补操作在清理完成之前已中断。但是，如果修补操作中断，则可能需要按照本流程中的说明进行手动清理。
**预防**：为避免未来出现 zypper 锁定冲突，请：
+ 仔细查看补丁基准中拒绝的修补程序，确保其中仅包含您真正想要排除的软件包。
+ 避免手动锁定可能需要作为安全更新依赖项的软件包。
+ 如果必须手动锁定软件包，请记录原因并定期检查锁定。
+ 确保修补操作成功完成，且未因系统重启或其他因素而中断。
+ 监控修补操作直至完成，避免因为系统重启或其他可能妨碍正确清理临时锁定的操作而中断。
### 问题：无法获取锁。另一个修补操作正在进行中。
**问题**：当您运行 `AWS-RunPatchBaseline` 时，修补失败，错误代码为 4，并显示以下错误消息。
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**原因**：当多个修补操作试图同时在同一受管节点上运行时，会发生此错误。锁定文件可防止并发修补操作，以避免冲突并确保系统稳定性。
**解决方案**：确保不要安排修补操作在同一托管节点上同时运行。请查看下面的配置以识别和解决调度冲突：
+ **补丁策略**：检查您的快速设置功能补丁策略配置，确保它们不会与其他修补计划重叠。
+ **维护时段**：检查维护时段关联，以确认多个时段不会在重叠时间对同一托管节点执行修补任务。
+ **手动立即修补操作**：避免在计划修补过程中启动手动**立即修补**操作。
## 在 Windows Server 上运行 `AWS-RunPatchBaseline` 时出现错误
**Topics**
+ [问题：产品系列/产品对不匹配](#patch-manager-troubleshooting-product-family-mismatch)
+ [问题: `AWS-RunPatchBaseline` 输出返回 `HRESULT`(Windows Server）](#patch-manager-troubleshooting-hresult)
+ [问题：托管式节点无法访问 Windows 更新目录或 WSUS](#patch-manager-troubleshooting-instance-access)
+ [问题：无法下载 PatchBaselineOperations （补丁基准操作） PowerShell 模块](#patch-manager-troubleshooting-module-not-downloadable)
+ [问题：缺少补丁](#patch-manager-troubleshooting-missing-patches)
+ [问题：无法获取锁。另一个修补操作正在进行中。](#patch-manager-troubleshooting-windows-concurrent-lock)
### 问题：产品系列/产品对不匹配
**问题**：在 Systems Manager 控制台中创建补丁基准时，您指定了产品系列和产品。例如，您可能选择：
+ **产品系列**：`Office`
**产品**：`Office 2016`
**原因**：如果您尝试使用不匹配的产品系列/产品对创建补丁基准，则会显示一条错误消息。以下是可能发生这种情况的原因：
+ 您选择了有效的产品系列/产品对，但随后删除了所选的产品系列。
+ 您从 **Obsolete or mismatched options (过时或不匹配的选项)** 子列表中选择的产品，而不是 **Available and matching options (可用和匹配选项)** 子列表。
产品**过时或不匹配的选项**子列表中的项目，可能是通过 SDK 或 AWS Command Line Interface (AWS CLI) `create-patch-baseline` 命令错误输入的。这可能意味着存在拼写错误或产品被分配到了错误的产品系列。如果为之前的补丁基准指定了某个产品，但该产品目前没有 Microsoft 提供的补丁，它也会包含在 **过时或不匹配的选项** 子列表中。
**解决方案**为避免控制台中出现此问题，请始终从**当前可用选项**子列表中选择选项。
您还可以使用 AWS CLI 中的 `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` 命令或 `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` API 命令查看具有可用补丁的产品。
### 问题: `AWS-RunPatchBaseline` 输出返回 `HRESULT`(Windows Server）
**问题**：您收到类似如下内容的错误：
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**原因**：此输出表示本机 Windows 更新 API 无法运行修补操作。
**解决方案**：检查以下 microsoft.com 主题中的 `HResult` 代码以确定解决错误的故障排除步骤：
+ [按组件划分的 Windows 更新错误代码](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Windows 更新常见错误和缓解措施](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### 问题：托管式节点无法访问 Windows 更新目录或 WSUS
**问题**：您收到类似如下内容的错误。
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**原因**：此错误可能与 Windows 更新组件，或缺乏连接到 Windows 更新目录或 Windows 服务器更新服务 (WSUS)有关。
**解决方案**：确认托管式节点已通过互联网网关、NAT 网关或 NAT 实例与 [Microsoft 更新目录](https://www.catalog.update.microsoft.com/home.aspx)连接。如果您使用的是 WSUS，请确认该托管式节点已连接到环境中的 WSUS 服务器。如果可以连接到预期目标，请查看 Microsoft 文档中 `HResult 0x80072EE2` 的其他潜在原因。这可能表明存在操作系统级问题。
### 问题：无法下载 PatchBaselineOperations （补丁基准操作） PowerShell 模块
**问题**：您收到类似如下内容的错误。
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**解决方案**：检查托管式节点与 Amazon Simple Storage Service (Amazon S3) 的连接和权限。托管式节点的 AWS Identity and Access Management (IAM) 角色必须使用 [SSM Agent 与 AWS 托管 S3 存储桶进行通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 中引用的最低权限。节点必须通过 Amazon S3 网关端点、NAT 网关或互联网网关与 Amazon S3 端点进行通信。有关 AWS Systems Manager SSM Agent（SSM Agent）的 VPC 端点要求的更多信息，请参阅 [使用适用于 Systems Manager 的 VPC 端点提高 EC2 实例的安全性](setup-create-vpc.md)。
### 问题：缺少补丁
**问题**：`AWS-RunPatchbaseline` 已成功完成，但缺少一些补丁。
以下是一些常见原因及其解决方案。
**原因 1**：基准无效。
**解决方案 1**：要检查这是否是原因，请使用以下过程。
1. 访问 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)，打开 AWS Systems Manager 控制台。
1. 在导航窗格中，请选择 **Run Command**。
1. 选择**命令历史记录**选项卡，然后选择要检查其基准的命令。
1. 选择缺少补丁的托管式节点。
1. 选择**步骤 1 - 输出**并查找 `BaselineId` 值。
1. 检查分配的[补丁基准配置](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)，即补丁基准的操作系统、产品名称、分类和严重性。
1. 转至[微软更新目录](https://www.catalog.update.microsoft.com/home.aspx)。
1. 搜索 Microsoft 知识库 (KB) 文章 ID（例如 KB3216916）。
1. 确认 **Product**（产品）下的值与托管式节点的值相匹配，然后选择相应的 **Title**（标题）。一个新**更新详细信息**窗口将打开。
1. 在**概述**选项卡中，**分类**和 **MSRC 严重性**必须与之前找到的补丁基准配置匹配。
**原因 2**：已替换补丁。
**解决方案 2**：要检查是否为真，请使用以下过程。
1. 转至[微软更新目录](https://www.catalog.update.microsoft.com/home.aspx)。
1. 搜索 Microsoft 知识库 (KB) 文章 ID（例如 KB3216916）。
1. 确认 **Product**（产品）下的值与托管式节点的值相匹配，然后选择相应的 **Title**（标题）。一个新**更新详细信息**窗口将打开。
1. 转至**程序包详细信息**选项卡。在**此更新已被以下更新所替换：**标头下面查找条目。
**原因 3**：相同的补丁可能具有不同的知识库编号，因为 WSUS 和窗口联机更新由 Microsoft 处理为独立的发布渠道。
**解决方案 3**：检查补丁的资格。如果软件包在 WSUS 下不可用，请安装[操作系统构建 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57)。如果该软件包适用于所有操作系统构建，请安装[操作系统构建 18362.1256 和 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9)。
### 问题：无法获取锁。另一个修补操作正在进行中。
**问题**：当您运行 `AWS-RunPatchBaseline` 时，修补失败，错误代码为 4，并显示以下错误消息。
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**原因**：当多个修补操作试图同时在同一受管节点上运行时，会发生此错误。锁定文件可防止并发修补操作，以避免冲突并确保系统稳定性。
**解决方案**：确保不要安排修补操作在同一托管节点上同时运行。请查看下面的配置以识别和解决调度冲突：
+ **补丁策略**：检查您的快速设置功能补丁策略配置，确保它们不会与其他修补计划重叠。
+ **维护时段**：检查维护时段关联，以确认多个时段不会在重叠时间对同一托管节点执行修补任务。
+ **手动立即修补操作**：避免在计划修补过程中启动手动**立即修补**操作。
## 在 macOS 上运行 `AWS-RunPatchBaseline` 时出现错误
**Topics**
+ [问题：无法获取锁。另一个修补操作正在进行中。](#patch-manager-troubleshooting-macos-concurrent-lock)
### 问题：无法获取锁。另一个修补操作正在进行中。
**问题**：当您运行 `AWS-RunPatchBaseline` 时，修补失败，错误代码为 4，并显示以下错误消息。
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**原因**：当多个修补操作试图同时在同一受管节点上运行时，会发生此错误。锁定文件可防止并发修补操作，以避免冲突并确保系统稳定性。
**解决方案**：确保不要安排修补操作在同一托管节点上同时运行。请查看下面的配置以识别和解决调度冲突：
+ **补丁策略**：检查您的快速设置功能补丁策略配置，确保它们不会与其他修补计划重叠。
+ **维护时段**：检查维护时段关联，以确认多个时段不会在重叠时间对同一托管节点执行修补任务。
+ **手动立即修补操作**：避免在计划修补过程中启动手动**立即修补**操作。
## 使用 AWS 支持 Automation 运行手册
AWS 支持 提供了两个 Automation 运行手册，可用于排查与修补相关的某些问题。
+ `AWSSupport-TroubleshootWindowsUpdate`：[https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) 运行手册用于识别可能导致 Amazon Elastic Compute Cloud（Amazon EC2）Windows Server 实例 Windows Server 更新失败的问题。
+ `AWSSupport-TroubleshootPatchManagerLinux`：[https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) 运行手册用于解决可能导致使用Patch Manager的基于 Linux 的托管式节点上出现补丁失败的常见问题。本运行手册的主要目标是确定补丁命令失败的根本原因并提出补救方案。
**注意**
运行 Automation 运行手册会产生费用。有关信息，请参阅 [AWS Systems Manager Automation 定价](https://aws.amazon.com/systems-manager/pricing/#Automation)。
## 联系 AWS 支持
如果您无法在本节或 [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager) 中的 Systems Manager 问题中找到故障排除解决方案，并且您有[开发人员、业务或企业 支持 计划](https://aws.amazon.com/premiumsupport/plans)，可在 [AWS 支持](https://aws.amazon.com/premiumsupport/) 创建一个技术支持用例。
在您联系 支持 之前，收集以下物品：
+ [SSM 代理日志](ssm-agent-logs.md)
+ Run Command 命令 ID、维护时段 ID 或自动化执行 ID
+ 对于 Windows Server 托管式节点，还要收集以下内容：
+ `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`，如 **Windows** 的选项卡 [如何安装补丁](patch-manager-installing-patches.md) 中所描述的那样
+ Windows 更新日志：对于 Windows Server 2012 R2 及更高版本，使用 `%windir%/WindowsUpdate.log`。对于 Windows Server 2016 及更新版本，首先运行 PowerShell 命令 [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)，然后再使用 `%windir%/WindowsUpdate.log`
+ 对于 Linux 托管式节点，还要收集以下内容：
+ 目录 `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux` 的内容