Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
跳到主要内容

使用 AWS Systems Manager 和标签修补托管节点

简介​

在整个节点基础设施中维护安全性和性能需要一个强大的补丁管理策略。本指南解决方案将引导您使用 AWS Systems Manager 实施自动化的、基于标签的补丁管理系统。通过遵循本指南解决方案，您将建立一个可扩展且高效的补丁流程，减少手动干预的同时提高安全合规性。此方法可以在 AWS Organizations 中用于集中化方法，也可以为单个账户实施。

利用这样的标签调度方法可以允许应用程序所有者管理其节点何时接收更新。可以使用 AWS CLI 查询已批准的计划（这些计划将有相应的补丁策略），从而提供一种自助式更改节点计划的方法。

理解解决方案​

在开始将某些部分实施到补丁管理解决方案之前，了解此解决方案的工作原理很重要。该方法将 AWS Systems Manager 的补丁管理功能与标准化的标签策略相结合。这种集成允许您在保持对更新计划精细控制的同时，自动化托管节点的补丁计划。

每个托管节点将被分配一个预定义标签，在本例中为 maintenance:patching。此标签的值将包含类似于 cron 表达式的条目，指示节点将被评估和应用更新的计划。

将为每个授权的托管节点应接收更新的计划创建补丁策略。

可以创建自定义补丁基线并关联到补丁策略，从而对应用的更新进行额外控制，或者可以使用默认补丁基线。

一旦建立并分配了补丁策略和标签，托管节点将按照补丁策略和补丁基线中的规范应用补丁策略。

基于角色的职责​

云运维团队​

云运维团队在通过全面的补丁管理监督维护云基础设施的安全性和稳定性方面发挥着关键作用。他们的职责涵盖几个关键领域，确保补丁计划的有效性。

持续监控补丁部署成功率对于维护系统健康至关重要。团队利用 AWS Systems Manager 跟踪和分析补丁结果，生成每周报告以识别模式和潜在关注领域。（参见使用补丁合规报告）这种主动监控能够及早发现系统性问题，并确保补丁在整个环境中成功应用。

团队负责维护驱动补丁流程的自动化基础设施。这包括定期优化 AWS Systems Manager 补丁基线、优化部署计划和维护自动化工作流。这些自动化流程必须持续评估和调整，以适应不断变化的业务需求，同时维护安全标准。

当补丁失败发生时，云运维团队作为主要响应者。他们必须在 24 小时内调查问题，协调必要的修复工作，并在需要时与应用团队合作。对事件及其解决方案的详尽记录有助于为未来参考建立知识库，并推动补丁流程的持续改进。

定期合规监督是另一项关键职责。团队每周进行补丁标签合规审查，确保所有节点遵守既定标准。这包括验证正确的标签实施，并通过 AWS Config 规则管理任何必要的修复。他们维护合规状态的详细记录，并管理对标准流程的任何已批准的例外。

通过这些活动，云运维团队确保了一个强大可靠的补丁计划，在维护系统安全的同时最大限度地减少业务影响。他们作为补丁问题的升级点以及与利益相关者的持续沟通有助于维护对补丁流程的透明度和信任。

安全团队​

安全团队作为托管节点补丁计划的治理权威，确保维护安全标准并通过全面的监督和战略方向满足合规要求。

补丁合规监控构成安全团队职责的基石。通过定期分析合规报告，他们评估组织的安全态势，并识别需要注意的潜在漏洞。此监督包括审查补丁部署 metrics、分析安全公告影响，以及确保关键补丁在规定时间内应用。

团队根据新出现的威胁和行业最佳实践维护和发展安全要求。当发现新漏洞或合规标准发生变化时，他们评估影响并相应更新补丁要求。这包括定义可接受的补丁部署窗口、建立最低合规阈值以及确定哪些安全补丁必须优先处理。

补丁基线治理属于其职权范围，安全团队作为补丁基线修改的批准权威。他们根据安全标准和合规要求评估拟议的变更，确保任何调整在适应运营需求的同时维持适当的安全态势。这包括审查操作系统和应用程序补丁规范。

团队定期进行合规验证，以确认补丁流程符合监管要求和内部安全策略。他们维护合规状态文档，管理审计响应，并在发现差距时提供修复指导。他们的评估有助于确保组织维护其安全认证并满足合规义务。

通过这些活动，安全团队建立和维护指导补丁计划的安全框架，确保安全始终是首要关注点，同时实现运营效率。

应用团队​

应用团队在确保成功的补丁管理的同时维护应用程序可用性和性能方面发挥着至关重要的作用。他们对应用程序行为和业务需求的深入了解使他们成为补丁流程中不可或缺的参与者。

协调补丁计划需要仔细考虑业务运营。应用团队必须主动与云运维合作，确定合适的计划以最大限度地减少业务影响。他们需要评估高峰使用期、关键业务事件和依赖关系，以确定何时可以安全地进行补丁。

补丁后验证是一项关键职责，应用团队必须系统地验证其应用程序的功能。在每个补丁周期之后，他们应执行既定的测试程序以确认所有关键业务功能按预期运行。这包括监控应用程序性能 metrics、验证核心功能，以及确认与依赖系统的集成保持完整。

当问题出现时，应用团队必须遵循既定的升级程序以确保正确的事件跟踪和解决。这包括提供所观察到问题的详细文档，包括具体症状、问题时间以及与最近补丁的潜在关联。及时准确的报告有助于云运维和安全团队有效响应与补丁相关的事件。

资源标签准确性完全属于应用团队的职责。他们必须维护所有资源上的当前和准确标签，特别是与补丁计划相关的标签。这些标签驱动自动化补丁流程，其准确性对于确保系统按照适当的计划和要求进行补丁至关重要。

通过这些职责，应用团队充当技术运营和业务需求之间的重要桥梁，确保补丁活动在维护系统安全的同时保持应用程序可用性和性能。

构建基础​

基于标签的补丁实施先决条件​

AWS Systems Manager 配置​

在实施基于标签的补丁之前，必须在账户或组织级别正确配置 AWS Systems Manager。在组织环境中，确保通过 AWS Organizations 在所有相关账户中启用 Systems Manager。配置适当的 IAM 角色和策略以允许 Systems Manager 管理资源，包括所需的服务关联角色和实例配置文件。如果需要跨多个区域或账户的集中可见性，请建立资源数据同步。

SSM Agent 管理​

所有托管节点必须运行正确配置的 SSM Agent。虽然许多 AWS AMI 默认包含该 agent，但请验证它存在并已更新到最新版本。对于非 AWS 托管节点，在实例预配期间实施安装和配置 agent 的流程。建立自动化流程以维护 agent 更新，在适当的情况下利用 Systems Manager 的 agent 自动更新功能。

网络连接要求​

Systems Manager 需要一致的网络连接才能有效管理节点。确保托管节点可以通过互联网或 VPC endpoint 访问 Systems Manager endpoint。对于私有子网中的节点，为 Systems Manager（ssm、ssmmessages 和 ec2messages）配置必要的 VPC endpoint。验证安全组和网络 ACL 允许所需的流量。如果使用代理，请使用适当的代理设置配置 SSM Agent。

补丁标签策略​

制定并记录与组织需求一致的全面标签策略。定义：

  • 用于标识补丁组的标签键值对（例如 maintenance:patching）
  • 通过 AWS Config 规则的标签执行机制
  • 标签治理和所有权职责
  • 标签更新和修改的程序

记录完整的标签模式，包括不同环境或应用程序类型所需的任何变体。建立验证标签合规性和修复不正确标签资源的流程。

备注

还需要与补丁源或仓库的网络连接。请参阅与补丁源的连接了解更多信息。

实施补丁流程​

保持托管节点的最新和安全状态是维护 AWS、本地和多云基础设施的重要组成部分。通过 AWS Systems Manager，您可以自动化跨托管节点队列的许多安全和其他类型的软件更新（补丁）。然而，管理补丁计划和节奏仍然可能很复杂，特别是随着基础设施的扩展。本指南解决方案是一种可以用于协助灵活管理补丁计划的方法示例。

步骤 1：建立标签策略​

首先实施 maintenance:patching 标签约定。此标签将定义何时应将补丁应用到每个节点。标签值使用类似 cron 的表达式来指定计划。组织通常选择非高峰（非生产）时间来应用更新。在这种情况下，可以选择特定的时间和月份中的日期作为每个节点需要对齐的标准。

例如：

Key: maintenance:patching
Value: 2SATX4    # Runs at 2 AM every 4th Saturday
备注

值中的 'X' 用于替换 '#' 符号，因为 '#' 不在标签值允许的字符范围内

值的其他常见模式包括：

  • 0SUN 表示每周日午夜维护
  • 4TUEX2 表示每月第二个周二凌晨 4 点维护
  • 22MONX3 表示每月第三个周一晚上 10 点维护

以下图表演示了来自各种来源的托管节点上的标签如何与补丁策略对齐。

演示托管节点上的标签如何与补丁策略对齐的示例图

此解决方案的一个实施提供了从周五晚上 10 点开始的实施时间。随后的时间选项在周五晚上 10 点之后每四小时创建一次，直到周日晚上 10 点。这允许每周有 13 个更新应用选项，可以根据需要分布在环境中，包括在不同计划上更新开发、测试和生产等环境的能力。

步骤 2：部署标签策略​

一旦您决定了标签策略，您需要确保现有节点接收新的必需标签，并制定要求所有新节点使用该标签的标准。

合规执行​

实施 AWS Config 规则以在整个环境中维护标签治理。配置规则以验证所有托管节点上是否存在必需的补丁标签，并验证标签值是否符合批准的标准。这种自动化监督确保基础设施中标签的一致性，并有助于快速识别不合规资源。

自动修复​

使用 AWS Systems Manager Automation 建立自动修复流程以处理不合规资源。您的修复工作流应根据资源特征添加缺少的标签和适当的默认值。设计您的修复既能自动处理标准情况，又能手动处理需要人工审查的例外。

审计和审查流程​

部署 AWS Config 规则以自动监控托管节点的 maintenance:patching 标签，确保标签存在和有效的补丁计划值（例如 2SATX4、4TUEX2）。每周审查 Config 合规报告以识别不合规资源并验证自动修复是否正常运行。在集中位置创建和维护已批准例外的文档。

治理模型​

建立标签管理的明确所有权和职责，云运维在 AWS Systems Manager Parameter Store 中维护已批准的补丁计划，以便在整个组织中保持一致的参考。定义请求更改标签标准和补丁计划的流程，确保更新反映在 Parameter Store 和相关 Config 规则中。创建有文档记录的变更审批工作流，在云运维更新集中参数之前需要安全团队验证。维护运维、安全和应用团队之间的反馈循环，以确保标签策略和维护窗口继续满足组织需求，使用 Parameter Store 作为已批准值的真实来源。

步骤 3：配置 Systems Manager​

有了标签策略后，您的云运维团队可以配置 Systems Manager 来执行补丁策略：

补丁基线指导​

在创建自定义补丁基线之前，评估 AWS 的预定义基线是否满足您的补丁要求。审查您操作系统的默认 AWS 托管基线，这些基线通常包括关键更新和安全补丁的已批准补丁。如果您的组织有特定的合规要求、补丁排除、延迟补丁批准，或需要管理特定的应用程序依赖关系，您可能需要自定义基线。然而，如果您只需要定期应用关键和安全更新，AWS 托管基线通常提供足够的覆盖范围，同时需要较少的维护开销。记录您的补丁要求并将其与预定义基线配置进行比较，以做出明智的决定。

补丁策略配置指导​

对于 Parameter Store 中定义的每个已批准补丁计划，在 AWS Systems Manager 中创建相应的补丁策略。命名您的策略以清楚反映其 CRON 计划，确保与补丁计划轻松关联（例如 Patch-2SATX4）。配置策略进行扫描和安装操作，利用自定义扫描计划选项指定与补丁计划对齐的预批准 CRON 表达式。

在定义策略范围时，选择指定的补丁基线并使用自定义目标选项配置目标。指定此策略应适用的适当组织单位 (OU) 和 AWS 区域。最关键的是，使用 maintenance:patching 标签设置目标节点，输入与此补丁计划对应的特定标签值（例如 2SATX4）。这确保只有明确标记为此补丁计划的节点才会包含在补丁操作中。

此配置方法维护了标签策略、补丁计划和补丁策略执行之间的一致性，同时提供了对哪些节点将在每个计划期间进行补丁的清晰可见性。

自动化工作流指导（可选）​

通过在 AWS Systems Manager 中实施补充自动化工作流来增强您的补丁策略。设计补丁前验证检查以验证系统就绪状态，例如确认可用磁盘空间、运行进程验证和备份关键配置。创建补丁后测试自动化以验证系统功能，包括服务状态检查、应用程序健康监控和基本连接测试。配置 SNS 主题和通知路径以向相关团队告警补丁执行状态、测试失败或验证问题。这些自动化工作流通过在整个补丁周期中提供一致的验证和清晰的通信渠道来加强您的补丁流程。

实施路线图​

按照以下步骤推出您的补丁策略：

阶段 1：规划和设计（第 1-2 周）​

这个基础阶段帮助客户清楚了解其当前环境并设定可实现的目标。详细的文档和角色定义确保了跨团队的问责制和顺畅运营。通过预先建立标准化的标签和自动化工作流，组织可以实现一致高效的补丁管理，同时最大限度地减少人为错误。此阶段创建了在降低运营开销的同时维护合规性和安全标准的框架。

  • 评估和记录当前环境的补丁管理状态
  • 定义可衡量的成功标准，包括合规目标和报告要求
  • 建立标签标准，包括要存储在 Parameter Store 中的已批准补丁计划值
  • 设计补丁前验证和补丁后测试的自动化工作流（可选）
  • 记录云运维、安全和应用团队的角色和职责

阶段 2：测试和验证（第 3-4 周）​

在受控环境中进行测试允许客户在影响生产系统之前发现和解决潜在问题，显著降低业务风险。验证过程确保自动化工作流按预期运行，并且报告提供了对补丁状态和合规性的必要可见性。此阶段帮助组织改进程序并建立对补丁管理策略的信心，同时维护系统稳定性和安全性。跨不同配置的彻底测试确保解决方案在整个基础设施中可靠工作。

  • 在测试环境中部署用于标签合规监控的 AWS Config 规则
  • 实施带有相关自动化工作流的补丁策略
  • 验证标签执行和自动修复流程
  • 验证报告机制和 dashboard 的有效性
  • 跨不同实例类型和操作系统进行彻底测试
  • 根据测试结果审查和调整程序

阶段 3：生产实施（第 5-6 周）​

分阶段推出方法在确保跨生产环境成功实施的同时最大限度地减少业务中断。定期监控和记录问题有助于创建用于未来参考和持续改进补丁管理流程的知识库。利益相关者审查和最终文档确保解决方案满足业务要求并可以长期有效维护。此阶段建立了一个可持续的自动化补丁管理系统，在维护安全和合规标准的同时减少手动工作。

  • 从非关键应用层开始执行分阶段推出
  • 监控 Config 合规报告和修复成功率
  • 记录遇到的问题和解决方案
  • 根据生产经验调整自动化工作流和程序
  • 与利益相关者进行补丁执行结果审查
  • 最终确定运营文档和交接程序

每个阶段包括与利益相关者的定期检查点，以确保与业务要求和安全标准保持一致。

监控和维护​

持续运营流程​

每周补丁合规审查​

每周审查 AWS Config 合规报告、Amazon Athena 报告或 Amazon QuickSight 以识别不合规节点和修复效果。云运维团队验证补丁策略执行结果并处理任何失败的补丁尝试。生成并向利益相关者分发合规状态报告，突出趋势和需要注意的潜在问题。

每月标签准确性审计​

每月验证 maintenance:patching 标签是否与 Parameter Store 中的已批准值对齐。审查 Config 规则报告以了解未经授权的标签修改，并验证自动修复是否正常运行。记录和调查任何重复不合规的模式，如果发现系统性问题则更新程序。

季度补丁基线评估​

安全团队每季度审查和更新补丁基线，确保它们符合当前的安全要求和供应商建议。验证已批准的补丁满足合规标准，并评估任何排除的补丁的风险。更新基线文档并向利益相关者传达变更。

半年度流程审查​

每年两次对整个补丁计划进行全面审查。评估自动化工作流的有效性、补丁计划的时机和整体合规率。收集所有利益相关者的反馈并实施流程改进。更新文档和培训材料以反映计划的任何变更。

每个审查过程包括对发现和采取行动的正式文档记录，结果与适当的利益相关者共享。

故障排除和支持​

组织应制定和维护其环境中常见补丁问题的全面故障排除文档。为支持团队创建详细的运行手册，至少涵盖以下场景：

  • 补丁安装失败：记录常见失败模式、所需的日志收集程序以及补丁持续失败时的升级路径。
  • 错过补丁计划窗口：提供识别错过计划根本原因的指导以及适当重新安排补丁的程序。
  • 缺少重启验证：包括验证重启要求的步骤、处理卡住重启状态的程序，以及必要时强制重启场景的指导。
  • 标签合规失败：记录调查不合规资源的程序、纠正标签问题的步骤以及验证修复成功的方法。
  • Systems Manager 连接问题：详细说明 agent 连接问题的故障排除步骤，包括网络验证和 IAM 权限验证。

将这些文档维护在支持团队可访问的集中位置，并建立定期审查周期，以使故障排除程序与环境变化和新发现的问题保持同步。

其他资源​

维护以下链接：

  • AWS Systems Manager 文档
  • 内部故障排除指南
  • 支持团队联系信息
  • 相关 AWS 服务文档

记住随着 AWS 服务的发展和组织需求的变化定期审查和更新本指南。使用此流程的团队的定期反馈将有助于随着时间的推移改进您的补丁策略。

这种标准化的补丁管理方法将有助于确保您的托管节点队列保持安全和最新，同时最大限度地减少运营开销和潜在的人为错误。