如何选择安全性补丁
Patch Manager（AWS Systems Manager 的一项功能）的主要设计意图在于在托管式节点上安装与安全性相关的操作系统更新。默认情况下，Patch Manager 并非安装所有可用的补丁，而只安装一小部分旨在提高安全性的补丁。
对于报告修补程序严重性级别的基于 Linux 的操作系统类型，Patch Manager 将软件发布商报告的严重性级别用于更新通知或单个修补程序。Patch Manager 不会从第三方来源（例如常见漏洞评分系统
注意
在 Patch Manager 支持的所有基于 Linux 的系统中，您可以选择为托管式节点配置的不同源存储库，以便通常用于安装非安全性更新。有关更多信息，请参阅 如何指定备用补丁源存储库 (Linux)。
请从以下选项卡中进行选择，了解 Patch Manager 如何为您的操作系统选择安全补丁。
- Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023
-
在 Amazon Linux 1 和 Amazon Linux 2 上处理预配置存储库的方式与 Amazon Linux 2022 和 Amazon Linux 2023 上不同。
在 Amazon Linux 1 和 Amazon Linux 2 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库。节点上通常有两个预配置存储库（存储库）：
在 Amazon Linux 1 上
-
存储库 ID：
amzn-main/latest存储库名称：
amzn-main-Base -
存储库 ID：
amzn-updates/latest存储库名称：
amzn-updates-Base
在 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 或 aarch64。Amazon Linux 2023（AL2023）实例最初包含 AL2023 版本和所选 AMI。默认情况下，AL2023 实例在启动时不会自动接收其他重大和重要的安全更新。相反，通过 AL2023 中默认开启的版本化存储库功能进行确定性升级，您可以根据满足您特定需求的计划应用更新。有关更多信息，请参阅《Amazon Linux 2023 User Guide》中的 Deterministic upgrades through versioned repositories。
在 Amazon Linux 2022 上，预配置的存储库与程序包更新的锁定版本相关。Amazon Linux 2022 的新 Amazon Machine Images（AMIs）在发布后会锁定到特定版本。对于补丁更新，Patch Manager 会检索补丁更新存储库的最新锁定版本，然后根据该锁定版本的内容更新托管式节点上的程序包。
在 AL2023 上，预配置的存储库如下所示：
-
存储库 ID：
amazonlinux存储库名称：Amazon Linux 2023 存储库
在 Amazon Linux 2022（预览版）上，预配置的存储库与程序包更新的锁定版本相关。Amazon Linux 2022 的新 Amazon Machine Images（AMIs）在发布后会锁定到特定版本。对于补丁更新，Patch Manager 会检索补丁更新存储库的最新锁定版本，然后根据该锁定版本的内容更新托管式节点上的程序包。
在 Amazon Linux 2022 上，预配置的存储库如下所示：
-
存储库 ID：
amazonlinux存储库名称：Amazon Linux 2022 存储库
注意
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
Amazon Linux 1 和 Amazon Linux 2 托管式节点使用 Yum 作为程序包管理器。Amazon Linux 2022 和 Amazon Linux 2023 使用 DNF 作为程序包管理器。
两个程序包管理器都将更新通知概念作为名为
updateinfo.xml的文件使用。更新通知只是修复特定问题的软件包的集合。Patch Manager 将更新通知中的所有软件包视为安全性软件包。单个软件包未分配分类或严重性级别。因此，Patch Manager 会向相关软件包分配更新通知属性。注意
如果在创建补丁基准页面中选中了包括非安全性更新复选框，则未分配到
updateinfo.xml文件中的软件包（或包含一个没有正确格式的分类、严重性和日期值的文件的软件包）可以包含在补丁的预筛选列表中。但是，为了应用补丁，补丁仍必须符合用户指定的补丁基准规则。 -
- CentOS and CentOS Stream
-
在 CentOS 和 CentOS Stream 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。以下列表提供了虚构 CentOS 8.2 的示例 Amazon Machine Image (AMI)：
-
存储库 ID：
example-centos-8.2-base存储库名称：
Example CentOS-8.2 - Base -
存储库 ID：
example-centos-8.2-extras存储库名称：
Example CentOS-8.2 - Extras -
存储库 ID：
example-centos-8.2-updates存储库名称：
Example CentOS-8.2 - Updates -
存储库 ID：
example-centos-8.x-examplerepo存储库名称：
Example CentOS-8.x – Example Repo Packages
注意
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
CentOS 6 和 7 托管式节点将 Yum 用作软件包管理器。CentOS 8 和 CentOS Stream 节点将 DNF 用作软件包管理器。两个程序包管理器都使用更新通知概念。更新通知只是修复特定问题的软件包的集合。
但是，CentOS 和 CentOS Stream 默认存储库不配置更新通知。这意味着，Patch Manager 不检测默认 CentOS 和 CentOS Stream 存储库上的软件包。要允许 Patch Manager 处理更新通知中未包含的软件包，您必须启用补丁基准规则中的
EnableNonSecurity标记。注意
支持 CentOS 和 CentOS Stream 更新通知。带有更新通知的存储库发布后即可供下载。
-
- Debian 服务器 and Raspberry Pi OS
-
在 Debian Server 和 Raspberry Pi OS（原 Raspbian）上，Systems Manager 补丁基准服务使用实例上的预配置存储库（存储库）。这些预配置存储库用于提取可用软件包升级的更新列表。在这一点上，Systems Manager 的作用类似于
sudo apt-get update命令。然后，在
debian-security存储库中筛选软件包。这就表示，在 Debian Server 的每个版本上，Patch Manager 仅识别属于该版本关联存储库一部分的升级，如下所示：codename-
Debian Server 8：
debian-security jessie -
Debian Server 9：
debian-security stretch -
Debian Server 10:
debian-security buster -
Debian Server 11:
debian-security bullseye -
Debian Server 12:
debian-security bookworm
注意
仅在 Debian Server 8 上：由于某些 Debian Server 8.* 托管式节点引用的软件包存储库 (
jessie-backports) 已被淘汰，Patch Manager 会执行其他步骤来确保修补操作成功。有关更多信息，请参阅 如何安装补丁。 -
- 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
。 -
存储库 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-securitytrusty适用于 Ubuntu Server 14。Patch Manager 只识别包含在这些储存库的升级：-
Ubuntu Server 14.04 LTS：
trusty-security -
Ubuntu Server 16.04 LTS：
xenial-security -
Ubuntu Server 18.04 LTS：
bionic-security -
Ubuntu Server 20.04 LTS：
focal-security -
Ubuntu Server 20.10 STR：
groovy-security -
Ubuntu Server 22.04 LTS：
jammy-security -
Ubuntu Server 23.04 (
lunar-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的更新日期和时间。 -
