本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 补丁管理概述
<a name="overview"></a>

如果您参与应用程序或基础架构的运营，您就会明白操作系统 (OS) 修补解决方案的重要性，该解决方案要足够灵活且可扩展，可以满足应用程序团队的不同需求。在典型的组织中，一些应用程序团队使用的架构涉及不可变实例，而另一些应用程序团队则在可变实例上部署应用程序。

不可变实例修补涉及将补丁应用于用于配置不可变 EC2 应用程序实例的 Amazon 机器映像 (AMI)。可变实例补丁涉及在计划维护窗口内，对正在运行的实例进行就地补丁部署。

本规范性指南介绍了如何使用 AWS Systems Manager 补丁管理器根据应用程序团队在服务器上通过标签定义的维护窗口和补丁组，自动修补跨多个 AWS 账户和 AWS 地区的可变实例。

该指南描述了一种自动修补解决方案，该解决方案使用补丁管理器和维护窗口 AWS Lambda 来自动配置修补和调度。Amazon Quick 提供了必要的报告和控制面板功能，用于报告补丁合规性。

此外，本指南还介绍了混合云环境的参考架构。在混合云环境中运行应用程序的用户会寻找机会来整合、简化、标准化和优化其本地基础架构中的 AWS 补丁管理操作。该指南解释了如何扩展可变实例的自动修补解决方案以支持混合云场景。

本指南介绍了：
+ 补丁管理的关键用户案例
+ 修补过程
+ 单一账户和单一 AWS 区域中可变实例的补丁管理；架构注意事项和限制
+ 多账户、多区域环境中可变实例的补丁管理；架构注意事项和限制
+ 混合云环境中本地实例的补丁管理；架构注意事项和限制
+ 主要利益相关者、角色和责任

**注意**  
本指南描述了自动化解决方案（称为*自动修补解决方案*）的架构，您可以实施该架构来支持可变实例的补丁管理要求。它不提供构建解决方案的代码。

## 术语和概念
<a name="terms"></a>


****  

| 租期 | 定义 | 
| --- | --- | 
| **不可变实例** | 不可变实例是指在运行时不会发生任何更改的 EC2 服务器实例。如果需要更改，则使用更新的服务器映像创建新实例，重新部署该实例，然后销毁现有的服务器映像。 | 
| **补丁基准** | 补丁基准特定于操作系统类型，它定义了允许在实例上安装的补丁列表。有关更多信息，请参阅 Systems Manager 文档中的[关于预定义和自定义补丁基准](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-baselines.html)。 | 
| **补丁组** | 补丁组表示应用程序环境中作为特定补丁基准目标的服务器。补丁组根据正确的实例集，帮助确保您将合适的补丁部署到正确的实例集。它们还可帮助避免过早地部署补丁（在对补丁进行充分测试之前）。修补程序组由**补丁组**标签表示。有关更多信息，请参阅 Systems Manager 文档中的[关于补丁组](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-patchgroups.html)。 | 
| **维护窗口** | 借助维护窗口，您可以制定计划，规定对实例执行具有潜在破坏性的操作，比如修补操作系统、更新驱动程序或安装软件或补丁。每个维护窗口都有一个计划、一段最长持续时间、一组注册的目标实例和一组注册任务。维护窗口由**“维护窗口”**标签表示。有关更多信息，请参阅 Systems Manager 文档中的[关于使用维护窗口修补计划](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-scheduletasks.html)。 | 

## 关键用户案例
<a name="user-stories"></a>

典型的操作系统修补过程涉及三项任务：

1. 扫描 EC2 实例和本地服务器以获取适用的操作系统补丁。

1. 在适当的时间对实例进行分组和修补。

1. 报告整个服务器环境的修补合规性。

下表列出了用于补丁管理的关键用户案例。


****  

| 场景 | 用户角色 | 说明 | 
| --- | --- | --- | 
| **修补机制** | 应用程序开发/支持团队 | 作为负责操作系统补丁的应用程序团队成员，我需要一种机制来修补我的长期运行或可变实例，这样才能缓解任何操作系统安全漏洞，并确保这些实例符合安全团队定义的修补基准。 | 
| **修补解决方案** | 云服务所有者 | 作为负责向应用程序团队提供云服务的云服务所有者，我需要构建一个支持多个 AWS 账户和 AWS 区域以及本地服务器的操作系统补丁解决方案，这样应用程序团队就可以缓解任何操作系统安全漏洞，同时保持与安全团队定义的补丁基准的合规性。 | 
| **修补合规性报告** | 安全运营经理 | 作为一名负责确保补丁合规性的安全运营经理，我需要详细的补丁合规性报告和云环境中的信息，这样我才能识别不符合补丁基准的服务器，并提醒团队实施所需的缓解措施。 | 
| **角色和职责的定义** | 云服务所有者 | 作为云服务所有者，我需要建立一个定义明确的角色和职责矩阵，解释谁在管理我构建的混合云补丁解决方案时做了什么，这样修补操作的义务就会公布并得到满足。 |