通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

保护云资产

本文提供了维护 Azure 云资产可靠性和安全性的最佳做法。 可靠性可确保云服务在最短的停机时间内保持正常运行。 安全性可保护资源的机密性、完整性和可用性。 可靠性和安全性对于成功的云作至关重要。

CAF 管理过程的示意图：就绪、管理、监控和保护（RAMP）。

管理可靠性

可靠性管理涉及使用冗余、复制和定义的恢复策略来最大程度地减少停机时间并保护业务。 表 1 提供了三个工作负荷优先级、可靠性要求（运行时间 SLO、最大停机时间、冗余、负载均衡、复制）和符合服务级别目标的示例方案（SLO）

表 1. 工作负荷优先级和可靠性要求的示例。

优先权 业务影响 最低运行时间 SLO 每月最大停机时间 体系结构冗余 负载均衡 数据复制和备份 示例方案
高（任务关键） 对公司声誉或收入的直接和严重影响。 99.99% 4.32 分钟 多区域和每个区域中多个可用性区域 主动-主动 跨区域同步数据复制和用于恢复的备份 任务关键型基线
中等 可衡量对公司声誉或收入的影响。 99.9% 43.20 分钟 多个区域 & 每个区域中的多个可用区域 主动-被动 跨区域异步数据复制和用于恢复的备份 可靠的网络应用模式
低 不会影响公司声誉、流程或利润。 99% 7.20 小时 单个区域 & 多个可用性区域 可用性区域冗余 跨可用性区域异步数据复制和用于恢复的备份 应用服务基线
虚拟机基线

确定可靠性责任

可靠性责任因部署模型而异。 使用下表确定基础结构（IaaS）、平台（PaaS）、软件（SaaS）和本地部署的管理责任。

责任 本地 IaaS （Azure） PaaS （Azure） SaaS
数据 ✔️ ✔️ ✔️ ✔️
代码和运行时 ✔️ ✔️ ✔️
云资源 ✔️ ✔️ ✔️
物理硬件 ✔️

有关详细信息，请参阅可靠性的共担责任。

定义可靠性要求

明确定义的可靠性要求对于运行时间目标、恢复和数据丢失容错至关重要。 按照以下步骤定义可靠性要求：

  1. 确定工作负荷的优先级。 根据业务关键性和财务投资级别为工作负荷分配高、中或低优先级。 定期查看优先级，以保持与业务目标保持一致。

  2. 将运行时间服务级别目标（SLO）分配给所有工作负荷。 SLO 会影响体系结构、数据管理策略、恢复过程和成本。 根据工作负荷优先级建立运行时间目标。 优先级较高的工作负荷需要更严格的运行时间目标。

  3. 标识服务级别指标 (SLI)。使用 SLI 针对 SLO 度量运行时间性能。 示例包括服务运行状况监视和错误率。

  4. 为所有工作负荷分配恢复时间目标（RTO）。 RTO 定义了工作负荷可接受的最大停机时间。 RTO 应该短于你的年度停机时间配额。 例如，运行时间 SLO 99.99% 要求年度故障时间应少于 52 分钟（每月 4.32 分钟）。 若要分配 RTO，请执行以下步骤：

    1. 估计每年的故障数。 对于具有操作历史记录的工作负荷，请使用 SLI。 对于新工作负载，请执行 故障模式分析 以获取准确的估计。

    2. 估算 RTO。 将每年允许的停机时间除以估计的故障数。 如果估计每年出现四次故障，则 RTO 必须 13 分钟或更少（52 分钟/4 次故障 = 13 分钟 RTO）。

    3. 测试恢复时间。跟踪在故障转移测试和实时故障期间恢复所需的平均时间。 从故障中恢复所需的时间必须小于你的 RTO。

  5. 为所有工作负荷定义恢复点目标（RPO）。 RPO 会影响复制和备份数据的频率。 确定业务可以容忍多少数据丢失。

  6. 定义工作负荷可靠性目标。 有关工作负荷可靠性目标的信息，请参阅 Well-Architected Framework 的 建议，以定义可靠性目标。

管理数据可靠性

数据可靠性涉及数据复制（副本）和备份（时间点副本），以保持可用性和一致性。 有关与数据可靠性目标一致的工作负荷优先级示例，请参阅 表 2。

表 2. 示例数据可靠性配置下的工作负荷优先级。

工作负荷优先级 运行时间 SLO 数据复制 数据备份 示例方案
高 99.99% 跨区域同步数据复制

跨可用性区域同步数据复制		 频率高、跨区域备份。 频率应支持 RTO 和 RPO。 任务关键型数据平台
中等 99.9% 跨区域同步数据复制

跨可用性区域同步数据复制		 跨区域备份。 频率应支持 RTO 和 RPO。 可靠 Web 应用模式中的数据库和存储解决方案
低 99% 跨可用性区域同步数据复制 跨区域备份。 频率应支持 RTO 和 RPO。 基线 Web 应用的数据弹性与区域冗余

必须将数据可靠性配置与工作负荷的 RTO 和 RPO 要求保持一致。 若要进行这种对齐，请执行以下步骤：

  1. 管理数据复制。 根据工作负荷的 RTO 和 RPO 要求同步或异步复制数据。

    数据分布 数据复制 负载均衡配置
    跨可用性区域 同步（近实时） 大多数 PaaS 服务以本机方式处理跨区域负载均衡
    跨区域（主动-主动） 同步 主动-主动负载均衡
    跨区域（主动-被动） 异步（定期） 主动-被动配置

    有关详细信息，请参阅复制：数据冗余。

  2. 管理数据备份。 备份用于灾难恢复（服务故障）、数据恢复（删除或损坏）和事件响应（安全性）。 备份必须支持每个工作负荷的 RTO 和 RPO 要求。 首选内置到 Azure 服务的备份解决方案，例如 Azure Cosmos DB 和 Azure SQL 数据库中的本机备份功能。 如果本机备份不可用（包括本地数据），请使用 Azure 备份。 有关详细信息，请参阅 备份 和 Azure 业务连续性中心。

  3. 设计工作负荷数据可靠性。 有关工作负荷数据可靠性设计，请参阅 Well-Architected 框架 数据分区指南 和 Azure 服务指南（从可靠性部分开始）。

管理代码和运行时可靠性

代码和运行时可靠性是工作负荷责任。 遵循 Well-Architected 框架 自我修复和自我保护指南。

管理云资源可靠性

管理云资源的可靠性通常需要体系结构冗余（重复服务实例）和有效的负载均衡策略。 有关与工作负荷优先级一致的体系结构冗余示例，请参阅 表 3。

表 3. 工作负荷优先级和体系结构冗余示例。

工作负荷优先级 体系结构冗余 负载均衡方法 Azure 负载均衡解决方案 示例方案
高 两个区域和可用性区域 主动-主动 Azure Front Door （HTTP）

Azure 流量管理器（非 HTTP）		 任务关键型基线应用程序平台
中等 两个区域和可用性区域 主动-被动 Azure Front Door （HTTP）

Azure 流量管理器（非 HTTP）		 可靠的网页应用模式架构指南
低 单个区域和可用性区域 跨可用性区域 Azure 应用程序网关

为虚拟机添加 Azure 负载均衡器		 应用服务基线
虚拟机基线

你的方法必须实现体系结构冗余，以满足工作负荷的可靠性要求。 按照以下步骤：

  1. 估计体系结构的运行时间。 对于每个工作负荷，计算复合 SLA。 仅包括可能导致工作负荷失败的服务（关键路径）。

    1. 列出工作负荷关键路径中的每个服务。 从官方文档中收集每个服务的微软正常运行时间服务级协议。

    2. 确定工作负荷是否包括独立的关键路径。 独立路径可能会失败，工作负荷仍然可用。

    3. 如果有一个关键路径，请使用单区域公式：N = S1 × S2 × S3 × ... × Sn。

    4. 如果你有两个或多个关键路径，请使用独立路径公式：N = S1 x 1 - [（1 - S2） × （1 - S3）]。

    5. 复杂的工作负荷通常合并这两种公式类型。 示例：N = S1 × S2 × S3 × （S4 x 1 - [（1 - S5） × （1 - S6）]。

    6. 对于多区域应用程序，请使用多区域公式的公式：M = 1 - （1 - N）^R

    7. 将计算的运行时间与运行时间 SLO 进行比较。 赤字需要更高级别 SLA 或其他冗余。 每次更改后重新计算。 在计算的正常运行时间超过 SLO 后停止。

    用例 公式 变量 例 解释
    单区域 N = S1 × S2 × S3 × ... × Sn N = 复合 SLA。
    S = Azure 服务的 SLA。
    n = 关键路径上的服务数。    		 N = 99.99% （app） × 99.95% （database） × 99.9% （缓存） 应用（99.99%）、数据库（99.95%）和缓存（99.9%）在单个关键路径中的简单工作负荷。
    独立路径 S1 × 1 - [(1 - S2) × (1 - S3)] S = Azure 服务的 SLA。 99.99% （app） × （1 - [（1 - 99.95% 数据库） × （1 - 99.9% 缓存）]） 在应用中，数据库（99.95%）或缓存（99.9%）可能会失败，而不会造成停机。
    多区域 M = 1 - （1 - N）^R M = 多区域 SLA。
    N = 单区域 SLA。
    R = 区域数。    		 如果 N = 99.95% 且 R = 2，则 M = 1 - （1 - 99.95%）^2 部署在两个区域中的工作负载。

  2. 调整服务层级。 在修改体系结构之前，请评估不同的 Azure 服务层级（SKU）是否符合可靠性要求。 某些 Azure 服务层级可能具有不同的正常运行时间服务级别协议（SLA），例如 Azure 托管磁盘。

  3. 添加体系结构冗余。 如果当前的运行时间估计低于 SLO，请增加冗余：

    1. 使用多个可用性区域。 将工作负荷配置为使用多个可用性区域。 可用性区域如何提高正常运行时间可能很难估计。 只有少数服务具有考虑可用性区域的正常运行时间服务级别协议。 在服务水平协议（SLA）包含可用性区域的情况下，请在正常运行时间估算中使用它们。 有关一些示例，请参阅下表。

      Azure 服务类型 具有可用性区域 SLA 的 Azure 服务
      计算平台 应用服务
      Azure Kubernetes 服务
      虚拟机
      数据存储 Azure 服务总线
      Azure 存储帐户
      适用于 Redis 的 Azure 缓存
      Azure 文件存储高级层级
      数据库 Azure Cosmos DB（Azure 宇宙数据库）
      Azure SQL 数据库
      Azure 数据库服务（用于 MySQL）
      适用于 PostgreSQL 的 Azure 数据库
      适用于 Apache Cassandra 的 Azure 托管实例
      负载均衡器 应用程序网关
      安全 Azure 防火墙

    2. 使用多个区域。 通常需要多个区域来满足运行时间 SLO。 使用全局负载均衡器（Azure Front Door 或流量管理器）进行流量分发。 多区域体系结构需要仔细的数据一致性管理。

  4. 管理体系结构冗余。 决定如何使用冗余：可以使用体系结构冗余作为日常作（活动）的一部分。 也可以在灾难恢复方案中使用体系结构冗余（被动）。 有关示例，请参阅表 3 。

    1. 跨可用区的负载均衡。 积极使用所有可用资源。 许多 Azure PaaS 服务自动管理跨可用性区域的负载均衡。 IaaS 工作负荷必须使用 内部负载均衡器 跨可用性区域进行负载均衡。

    2. 跨区域进行负载均衡。 确定是否应根据可靠性需求运行主动-主动或主动-被动的多区域工作负荷。

  5. 管理服务配置。 始终跨 Azure 资源的冗余实例应用配置，因此资源的行为方式相同。 使用 基础结构作为代码 来保持一致性。 有关详细信息，请参阅 重复资源配置。

  6. 设计工作负荷可靠性。 有关工作负荷可靠性设计，请参阅 Well-Architected 框架：

    工作负荷可靠性 指导
    可靠性支柱 高可用性多区域设计
    针对冗余设计
    使用可用性区域和地区
    服务指南 Azure 服务指南（从可靠性部分开始）

有关详细信息，请参阅冗余。

管理业务连续性

从故障中恢复需要明确的策略来快速还原服务，并最大程度地减少中断，以保持用户满意度。 按照以下步骤：

  1. 准备失败。 基于高、中、低优先级为工作负荷创建单独的恢复过程。 数据可靠性、代码和运行时可靠性，云资源可靠性 是准备故障的基础。 选择其他恢复工具来帮助进行业务连续性准备。 例如，将 Azure Site Recovery 用于本地和基于虚拟机的服务器工作负荷。

  2. 测试和记录恢复计划。 定期测试故障转移和故障恢复过程，以确认工作负荷满足恢复时间目标（RTO）和恢复点目标（RPO）。 清楚地记录恢复计划的每个步骤，以便在事件期间轻松参考。 验证恢复工具（如 Azure Site Recovery）是否一致地满足指定的 RTO。

  3. 检测故障。 采用主动策略来快速识别中断，即使此方法会增加误报。 通过最大程度地减少停机时间和维护用户信任来设置客户体验的优先级。

    1. 监视故障。 监视工作负荷，以在一分钟内检测中断。 使用 Azure 服务运行状况 和 Azure 资源运行状况，并使用 Azure Monitor 警报 来通知相关团队。 将这些警报与 Azure DevOps 或 IT 服务管理（ITSM）工具集成。

    2. 收集服务级别指示器（SLI）。 通过定义和收集充当 SLA 的指标来跟踪性能。 确保团队使用这些指标根据服务级别目标（SLO）来衡量工作负荷性能。

  4. 响应失败。 使恢复响应与工作负荷优先级保持一致。 实现故障转移过程，以立即将请求重新路由到冗余基础结构和数据副本。 系统稳定后，请解决根本原因、同步数据并执行故障回复过程。 有关详细信息，请参阅故障转移和故障回复。

  5. 分析失败。 确定问题的根本原因，然后解决问题。 记录任何课程并进行必要的更改。

  6. 管理工作负荷故障。 有关工作负荷灾难恢复，请参阅 Well-Architected Framework 灾难恢复指南 和 Azure 服务指南（从可靠性部分开始）。

Azure 可靠性工具

用例 解决方案
数据复制、备份和业务连续性 Azure 服务指南（从可靠性部分开始）

快速参考：
Azure Cosmos DB
Azure SQL 数据库
Azure Blob 存储
Azure 文件存储
数据备份 Azure 备份
业务连续性 （IaaS） Azure Site Recovery
多区域负载均衡器 Azure Front Door （HTTP）
Azure 流量管理器（非 HTTP）
多可用性区域负载均衡器 Azure 应用程序网关 （HTTP）
Azure 负载均衡器（非 HTTP）

管理安全性

使用迭代安全过程识别和缓解云环境中的威胁。 按照以下步骤：

管理安全操作

管理安全控制，以检测云资产的威胁。 按照以下步骤：

  1. 标准化安全工具。 使用标准化工具来检测威胁、修复漏洞、调查问题、保护数据、强化资源以及大规模强制实施合规性。 请参阅 Azure 安全工具。

  2. 环境基线。 记录云资产的正常状态。 监视安全 并记录网络流量模式和用户行为。 使用 Azure 安全基线 和 Azure 服务指南 为服务开发基线配置。 通过此基线可以更轻松地检测异常和潜在的安全漏洞。

  3. 应用安全控制。 实施访问控制、加密和多重身份验证等安全措施，加强环境并减少泄露的可能性。 有关详细信息，请参阅 管理安全。

  4. 分配安全责任。 指定跨云环境进行安全监视的责任。 定期监视和比较基线可以快速识别事件，例如未经授权的访问或异常数据传输。 定期更新和审核使安全基线能有效应对不断演变的威胁。

有关详细信息，请参阅 CAF Secure。

管理安全事件

采用流程和工具从安全事件（例如勒索软件、拒绝服务或威胁参与者入侵）中恢复。 按照以下步骤：

  1. 准备事件。 制定事件响应计划，明确定义调查、缓解和通信的角色。 定期测试计划的有效性。 评估和实现漏洞管理工具、威胁检测系统和基础结构监视解决方案。 通过基础结构强化和创建特定于工作负荷的恢复策略来减少攻击面。 请参阅 事件响应概述 和 事件响应手册。

  2. 检测事件。 使用安全信息和事件管理（SIEM）工具（如 Microsoft Sentinel）来集中安全数据。 使用 Microsoft Sentinel 的 安全业务流程、自动化和响应功能（SOAR） 自动执行例行安全任务。 将 威胁情报源 集成到 SIEM 中，以深入了解与云环境相关的对手策略。 使用 Microsoft Defender for Cloud 定期扫描 Azure 中的漏洞。 Microsoft Defender 将 与 Microsoft Sentinel 集成，以提供安全事件的统一视图。

  3. 响应事件。 检测事件后立即激活事件响应计划。 快速启动调查和缓解过程。 激活灾难恢复计划以还原受影响的系统，并清楚地向团队传达事件详细信息。

  4. 分析安全事件。 在发生每个事件后，根据从公共资源中吸取的教训和见解（如 MITRE ATT&CK 知识库）查看威胁情报并更新事件响应计划。 评估漏洞管理和检测工具的有效性，并根据事后分析优化策略。

有关详细信息，请参阅 管理事件响应（CAF Secure）。

Azure 安全工具

安全功能 Microsoft解决方案
标识和访问管理 Microsoft Entra ID
基于角色的访问控制 Azure 基于角色的访问控制
威胁检测 Microsoft Defender for Cloud
安全信息管理 Microsoft Sentinel
数据安全和治理 Microsoft Purview
云资源安全性 Azure 安全基线
云治理 Azure Policy
终端安全 Microsoft Defender for Endpoint
网络安全 Azure 网络观察程序
工业安全 Microsoft Defender for IoT
数据备份安全性 Azure 备份安全性

后续步骤

CAF 管理清单