本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 了解 AMS Accerate 中的补丁管理
**重要**
加速补丁报告定期部署 AWS Glue 基于资源的策略。请注意，AMS 对修补系统的更新会覆盖现有的基于 AWS Glue 资源的策略。
**重要**
您可以为托管节点指定备用补丁存储库。在 AMS 实施您请求的补丁配置时，您负责选择和验证所选存储库的安全性。您还必须接受使用这些存储库所带来的任何风险，例如供应链风险。
以下是确保补丁管理流程安全性的最佳实践：
仅使用可信、经过验证的存储库来源
如果可能，默认为标准操作系统供应商存储库
定期审核自定义存储库配置
您可以使用 AMS Accelerate 修补系统，即补丁附加组件，使用安全相关更新和其他类型的更新来修补您的实例。加速补丁插件是一项为 AMS 实例提供基于标签的修补的功能。它利用 AWS Systems Manager (SSM) 功能，因此您可以使用基准和您配置的窗口标记实例并修补这些实例。AMS Accelerate 补丁插件是一个入门选项，如果您在加入 Accelerate 账户时未获得，请联系您的云服务交付经理 (CSDM) 获取。
AMS Accelerate 补丁管理使用 Systems Manager 补丁基准功能来控制应用于实例的补丁的定义。补丁基准包含预先批准的补丁列表；例如，所有安全补丁。实例的合规性是根据与其关联的补丁基准来衡量的。默认情况下，AMS Accelerate 会安装所有可用的补丁以使实例保持最新状态。
**注意**
AMS Accelerate 仅应用操作系统 (OS) 补丁。例如，对于 Windows，仅应用 Windows 更新，不应用微软更新。
有关报告的信息，请参阅[AMS 主机管理报告](ams-host-man.md)。
AMS Accelerate 提供了一系列运营服务，可帮助您实现卓越运营 AWS。要快速了解 AMS 如何利用我们的一些关键运营功能（包括全天候服务台、主动监控、安全、补丁、日志记录和备份）来帮助您的团队实现整体卓越运营，请参阅 [AMS](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/AWS-managed-services-for-operational-excellence-ra.pdf) 参考架构图。 AWS 云
**Topics**
+ [修补建议](#acc-patching-recos)
+ [在 AMS 中创建补丁维护窗口](acc-p-maint-window.md)
+ [带挂钩的补丁](acc-p-hooks.md)
+ [AMS 加速补丁基准](acc-patch-baseline.md)
+ [创建 IAM 角色以按需修补 AMS Accelerate](acc-p-user-access.md)
+ [了解 AMS Accelerate 中的补丁通知和补丁故障](acc-patch-mon-remediate.md)
## 修补建议
如果您参与应用程序或基础架构的运营，您就会明白操作系统 (OS) 修补解决方案的重要性，该解决方案要足够灵活且可扩展，可以满足应用程序团队的不同需求。在典型的组织中，一些应用程序团队使用的架构涉及不可变实例，而另一些应用程序团队则在可变实例上部署应用程序。
有关修补 AWS 规范指南的更多信息，请参阅使用[自动修补混合云中的可变实例](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)。 AWS Systems Manager
**注意**
加速补丁插件是一项为 AMS 实例提供基于标签的修补的功能。它利用 AWS Systems Manager (SSM) 功能，因此您可以使用基准和您配置的窗口标记实例并修补这些实例。AMS Accelerate 补丁插件是一个入门选项，如果您在加入 Accelerate 账户时未获得，请联系您的云服务交付经理 (CSDM) 获取。
### 补丁责任建议
永久性实例的修补过程应涉及以下团队和操作：
+ **应用程序 (DevOps) 团队**根据应用程序环境、操作系统类型或其他标准为其服务器定义补丁组。它们还定义了每个补丁组特定的维护窗口。此信息应存储在附加到实例的标签上。推荐的标签名称为 “补丁组” 和 “维护窗口”。在每个补丁周期中，应用程序团队都要为修补做准备，在修补后测试应用程序，并在修补期间对应用程序和操作系统的任何问题进行故障排除。
+ **安全运营团队为应用团队**使用的各种操作系统类型定义补丁基准，并通过 Systems Manager Patch Manager 提供补丁程序。
+ **自动修补解决方案**定期运行，并根据用户定义的补丁组和维护时段部署补丁基准中定义的补丁。
+ **治理和合规团队**定义补丁指南以及例外流程和机制。
有关更多信息，请参阅为[可变 EC2 实例设计修补解决方案](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/design-standard.html)。
### 应用团队指南
+ 查看并熟悉如何创建和管理维护窗口；要了解更多信息，请参阅[AWS Systems Manager 维护](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)窗口和[创建 SSM 维护窗口进行修补](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-patching.html#acc-p-maint-window)。了解维护窗口的总体结构和用法有助于您了解如果不是创建维护窗口的人，则需要提供哪些信息。
+ 对于高可用性 (HA) 设置，计划为每个可用区和每个环境设置一个维护窗口 (Dev/Test/Prod)。这将确保修补期间的持续可用性。
+ 建议的维护时段持续时间为 4 小时，中断时间为 1 小时，外加每 50 个实例增加 1 小时
+ 在开发和测试版本之间留出足够的时间进行修补，这样你就可以在生产修补之前识别出任何潜在的问题。
+ 通过 SSM 自动化自动执行常见的修补前和修补后任务，并将其作为维护窗口任务运行。请注意，对于修补后的任务，您必须确保分配足够的时间，因为一旦达到截止时间，任务就不会启动。
+ 熟悉补丁基准及其功能，尤其是补丁严重性类型的自动批准延迟，这可用于确保日后只有在生产中应用的补丁 Dev/Test 才能在生产中应用。有关详细信息，请参阅[关于补丁基准](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html)。
### 安全运营团队指南
+ 查看并熟悉补丁基准。补丁批准以自动方式处理，并且具有不同的规则选项。[有关更多信息，请参阅关于补丁基准](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html)。
+ Dev/Test/Prod与应用团队讨论有关修补的需求，并制定多个基准来满足这些需求。
### 治理和合规团队指南
+ 修补应该是一个 “选择退出” 功能。应存在默认维护时段和自动标记，以确保没有任何未修补的内容。AMS Resource Tagger 可以帮助解决这个问题；请与您的云架构师 (CA) 或云服务交付经理 (CSDM) 讨论此选项，以获取实施指导。
+ 申请补丁豁免时应要求提供证明豁免理由的文件。首席信息安全官 (CISO) 或其他审批官应批准或拒绝申请。
+ 应通过 Patch Manager 控制台、Security Hub 或漏洞扫描程序定期检查补丁合规性。
### 高可用性 Windows 应用程序的设计示例
![\[Patch Tuesday schedule showing development, test, and production environments with baseline approval timelines.\]](http://docs.aws.amazon.com/zh_cn/managedservices/latest/accelerate-guide/images/acc-maint-window.png)
**概述：**
+ 每个可用区一个维护窗口。
+ 每个环境都有一组维护窗口。
+ 每个环境一个补丁基准：
+ 开发人员：0 天后批准所有严重性和分类。
+ 测试：在 0 天后批准关键安全更新补丁，7 天后批准所有其他严重性和分类。
+ Prod：在 0 天后批准关键安全更新补丁，14 天后批准所有其他严重性和分类。
**CloudFormation 脚本：**
这些脚本的设置是为了使用上述基准批准设置为两个可用区 Windows HA EC2 应用程序构建维护窗口、基准和修补任务。
+ [Windows Dev CFN 堆栈示例：ha-patching-dev-stack.json](samples/HA-Patching-Dev-Stack.zip)
+ [Windows 测试 CFN 堆栈示例：ha-patching-test-stack.json](samples/HA-Patching-Test-Stack.zip)
+ [Windows Prod CFN 堆栈示例：ha-patching-prod-stack.json](samples/HA-Patching-Prod-Stack.zip)
### 补丁建议 FAQs
问：如何处理 “0” 天漏洞的计划外修补？
答：SSM 支持 “**立即修补**” 功能，该功能使用实例操作系统的当前默认基准。AMS 会部署一组默认的补丁基准，该基准会在 0 天后批准所有补丁。但是，使用 “**立即修补**” 功能时，不会拍摄修补前的快照，因为此命令运行 AW RunPatchBaseline S-SSM 文档。我们建议您在修补之前进行手动备份。
问：AMS 是否支持修补自动伸缩组 () ASGs 中的实例？
答：不是。 目前，Accelerate 客户不支持 ASG 修补。
问：维护时段是否有任何限制需要记住？
答：是的，您应该注意一些限制。
+ 每个账户的维护时段：50
+ 每个维护时段的任务数：20
+ 每个维护时段的最大并发自动化数量：20
+ 并发维护时段的最大数量：5
有关默认 SSM 限制的完整列表，请参阅[AWS Systems Manager 终端节点和配额](https://docs.aws.amazon.com/general/latest/gr/ssm.html)。