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

设计领域：安全性

  • 项目

此设计领域为 Azure、混合和多云环境的安全性创造基础。 稍后可以使用云采用框架的安全方法中概述的安全指南强化此基础。

设计领域回顾

涉及的角色或职能：此设计领域由云安全性，特别是该团队中的安全架构师主导。 评审网络和标识决策需要云平台和云卓越中心。 定义和实现此练习的技术要求可能需要集体角色。 更高级的安全防护措施可能还需要云治理的支持。

范围：本练习的目标是了解安全性要求，并跨云平台的所有工作负载一致地实现这些要求。 本练习的主要范围侧重于安全运营工具和访问控制。 此范围包括零信任和高级网络安全。

超出范围：本练习重点介绍云中新式安全运营中心的基础。 为了简化对话，本练习不会解决 CAF 安全方法中的一些规则。 将基于 Azure 登陆区域部署构建安全运营、资产保护和创新安全性。 但是，它们不在此设计领域讨论的范围内。

设计领域概述

安全性是每个环境中所有客户的核心考虑因素。 设计和实现 Azure 登陆区域时，应在整个过程中考虑安全性。

安全设计领域侧重于登陆区域决策的注意事项和建议。 此外，云采用框架中的安全方法也为整体安全过程和工具提供更深入的指导。

新（绿地）云环境：若要通过一小组订阅开始你的云之旅，请参阅创建初始 Azure 订阅。 此外，请考虑使用 Bicep 部署模板构建 Azure 登陆区域。 有关详细信息，请参阅 Azure 登陆区域 Bicep - 部署流。

现有（棕地）云环境：如果有兴趣将安全设计领域的原则应用到现有的 Azure 环境，请考虑使用以下 Microsoft Entra 标识和访问服务：

Azure 登陆区域 Bicep - 部署流存储库包含许多 Bicep 部署模板，可以加速绿地和棕地 Azure 登陆区域部署。 这些模板中已集成 Microsoft 经过验证的安全指南。

有关在棕地云环境中工作的详细信息，请参阅棕地环境注意事项。

Microsoft 云安全基准

Microsoft 云安全基准包含具有重要影响的安全建议，可用于帮助保护在 Azure 中使用的大多数服务。 可以将这些建议视为“常规”或“组织”建议，因为它们适用于大多数 Azure 服务。 然后针对每个 Azure 服务自定义 Microsoft 云安全基准建议。 此自定义指导包含在服务建议文章中。

Microsoft 云安全基准文档指定了安全控制和服务建议。

  • 安全控制：Microsoft 云安全基准建议按安全控制进行分类。 安全控制代表与供应商无关的高级安全需求，如网络安全和数据保护。 每个安全控制都有一组安全建议和帮助你实现这些建议的说明。
  • 服务建议：在可用情况下，针对 Azure 服务的基准建议将包括专门为该服务定制的 Microsoft 云安全基准建议。

Azure 证明

Azure 证明是一种工具，可帮助你确保运行其中的平台和二进制文件的安全性和完整性。 对于需要高度可缩放的计算资源和对远程证明功能不妥协信任的企业尤其有用。

安全性设计注意事项

组织必须了解其技术云资产中发生的情况。 Azure 平台服务的安全监视和审核日志记录功能是可缩放框架的关键组件。

安全运营设计注意事项

范围 上下文
安全警报 - 哪些团队需要安全警报通知？
- 是否存在警报需要路由到不同团队的服务组？
- 实时监视和警报的业务要求。
- 安全信息和事件管理与 Microsoft Defender for Cloud 和 Microsoft Sentinel 的集成。
安全日志 - 审核数据的数据保留期。 Microsoft Entra ID P1 或 P2 报表的保留期为 30 天。
- 长期存档日志，例如 Azure 活动日志、虚拟机 (VM) 日志和平台即服务 (PaaS) 日志。
安全控件 - 通过 Azure 来宾内 VM 策略进行的基线安全配置。
- 考虑安全控制如何与治理防护措施保持一致。
漏洞管理 - 对严重漏洞进行紧急修补。
- 对长时间脱机的 VM 进行修补。
- VM 的漏洞评估。
共担责任 - 团队职责的交接在哪里？ 监视或响应安全事件时，需要考虑这些责任。
- 考虑安全运营的安全方法中的指南。
加密和密钥 - 谁需要访问环境中的密钥？
- 谁负责管理密钥？
- 进一步探索加密和密钥。
证明 - 是否对 VM 使用受信任的启动，是否需要证明 VM（UEFI、OS、系统和驱动程序）的整个启动链的完整性？
- 是否要利用机密 VM 的机密磁盘加密？
- 工作负荷是否需要证明它们正在受信任的环境中运行？

安全运营设计建议

  • 使用 Microsoft Entra ID 报告功能生成访问控制审核报告。

  • 将 Azure 活动日志导出到 Azure Monitor 日志，以便长期保留数据。 如有必要，可导出到 Azure 存储，以便实现超过两年的长期存储。

  • 为所有订阅启用 Defender for Cloud 标准，并使用 Azure Policy 以确保合规性。

  • 通过 Azure Monitor 日志和 Microsoft Defender for Cloud 监视基础操作系统修补偏移。

  • 使用 Azure 策略通过 VM 扩展自动部署软件配置，并强制实施合规的基线 VM 配置。

  • 通过 Azure Policy 监视 VM 安全配置偏移。

  • 将默认资源配置连接到集中式 Azure Monitor Log Analytics 工作区。

  • 将基于 Azure 事件网格的解决方案用于日志导向型实时警报。

  • 使用Azure 证明进行证明：

    • VM 的整个启动链的完整性。 有关详细信息，请参阅 启动完整性监视概述。
    • 机密 VM 的机密磁盘加密密钥的安全发布。 有关详细信息，请参阅 机密 OS 磁盘加密。
    • 各种类型的工作负荷受信任执行环境。 有关详细信息，请参阅 用例。

访问控制设计注意事项

新式安全边界比传统数据中心中的边界更复杂。 数据中心的四面墙无法再保护你的资产。 将用户排除在受保护的网络外不再足以控制访问。 在云中，外围由两个部分组成：网络安全控制和零信任访问控制。

高级网络安全

范围 上下文
计划入站和出站 Internet 连接 描述进出公共 Internet 的入站和出站连接的推荐连接模型。
计划登陆区域网络分段 了解在登陆区域中提供高度安全的内部网络分段的重要建议。 这些建议可推动实现网络零信任。
定义网络加密要求 探索在本地与 Azure 之间以及跨 Azure 区域实现网络加密的关键建议。
计划流量检查 探索在 Azure 虚拟网络中镜像流量或分流的关键注意事项和建议方法。

零信任

对于使用标识零信任访问，应考虑：

  • 哪些团队或个人需要访问登陆区域中的服务？ 他们的角色是什么？
  • 谁授权访问请求？
  • 在激活特权角色时，谁应接收通知？
  • 谁应有权访问审核历史记录？

有关详细信息，请参阅 Microsoft Entra Privileged Identity Management。

实现零信任可以超越标识和访问管理。 组织是否需要跨多个支柱（例如基础结构、数据和网络）实施零信任做法。 有关详细信息，请参阅登陆区域中的合并零信任做法

访问控制设计建议

  • 在基础要求方面，请对每项所需服务执行联合检查。 如果要自带密钥，则可能并非所有考虑的服务都支持它。 实施相关缓解措施，确保不一致不会妨碍想要的结果。 选择适当的区域对和能最大程度减少延迟的灾难恢复区域。

  • 制定安全允许列表计划来评估安全配置、监视和警报等服务。 然后创建计划，以便将其与现有系统集成。

  • 确定 Azure 服务的事件响应计划，然后再将其投入生产。

  • 使安全要求与 Azure 平台路线图保持一致，以便与新发布的安全控制保持同步。

  • 在适当情况下，对访问 Azure 平台实施零信任方法。

Azure 登陆区域中加速器的安全性

安全性是 Azure 登陆区域中加速器的核心。 在实现过程中，会部署许多工具和控件，以帮助组织快速实现安全基线。

例如，包括以下内容：

工具：

  • Microsoft Defender for Cloud，标准层或免费层
  • Microsoft Sentinel
  • Azure DDoS 网络保护（可选）
  • Azure 防火墙
  • Web 应用程序防火墙 (WAF)
  • Privileged Identity Management (PIM)

联机和公司连接的登录区域的策略：

  • 强制对存储帐户进行安全访问（如 HTTPS）
  • 强制执行 Azure SQL 数据库审核
  • 强制执行 Azure SQL 数据库加密
  • 禁止 IP 转发
  • 阻止来自 Internet 的入站 RDP
  • 确保子网与 NSG 关联

后续步骤

了解如何在 Microsoft Entra ID 中保护混合部署和云部署的特权访问。

安全的特许访问权限