• AWS Systems Manager CloudWatch 控制面板在 2026 年 4 月 30 日之后将不再可用。客户可以像现在一样继续使用 Amazon CloudWatch 控制台来查看、创建和管理其 Amazon CloudWatch 控制面板。有关更多信息，请参阅 [Amazon CloudWatch 控制面板文档](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。 # 如何选择安全性补丁 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\_64 或（对于 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` 的更新日期和时间。 ------