Azure 操作安全性最佳做法

本文提供了用于保护 Azure 中的数据、应用程序和其他资产的一系列操作最佳做法。

最佳做法以观点的共识以及 Azure 平台功能和特性集为基础。 观点和技术将随着时间改变，本文会定期更新以反映这些更改。

定义并部署强大的操作安全做法

Azure 操作安全性是指用户可用于在 Azure 中保护其数据、应用程序和其他资产的服务、控件和功能。 Azure 运营安全基于一个框架构建，该框架结合了通过Microsoft特有的功能获得的知识，包括安全开发生命周期（SDL），Microsoft安全响应中心计划，以及对网络安全威胁格局的深入认识。

对用户强制执行多重身份验证

建议对所有用户要求进行双重验证。 这包括组织中的管理员和其他人员，如果他们的帐户泄露，可能会产生重大影响（例如，财务官员）。

要求双重验证有多种选项。 最佳选项取决于你的目标、正在运行的 Microsoft Entra 版本和你的许可计划。 请参阅 “如何要求用户进行双重验证 ”，以确定最适合你的选项。 有关许可证和定价的详细信息，请参阅 Microsoft Entra ID 和 Microsoft Entra 多重身份验证 定价页。

以下是启用双重验证的选项和优势：

选项 1：使用 Microsoft Entra 安全默认值为所有用户和登录方法启用 MFA。优势：借助此选项，可以轻松、快速地为环境中的所有用户强制执行 MFA，同时采用严格的策略来执行以下操作：

• 质询管理帐户和管理登录机制
• 要求通过 Microsoft Authenticator 对所有用户进行 MFA 质询
• 限制旧身份验证协议。

此方法可用于所有许可层，但不能与现有的条件访问策略混合使用。 可以在 Microsoft Entra Security Defaults 中找到详细信息

选项 2： 通过更改用户状态启用多重身份验证。
优点：这是要求双重验证的传统方法。 它适用于 云中的 Microsoft Entra 多重身份验证和 Azure 多重身份验证服务器。 使用此方法要求用户在每次登录时都执行双重验证，并且会替代条件访问策略。

若要确定需要启用多重身份验证的位置，请参阅哪个版本的 Microsoft Entra 多重身份验证适合我的组织？

选项 3： 使用条件访问策略启用多重身份验证。 权益：此选项允许使用 条件访问在特定条件下提示进行双重验证。 特定条件可以是用户从不同位置、不受信任的设备或你认为存在风险的应用程序登录。 定义要求双重验证的特定条件可以避免不断提示用户这种令人不快的用户体验。

这是为用户启用双重验证最灵活的方式。 “启用条件访问”策略只适用于云中的 Microsoft Entra 多重身份验证，这是 Microsoft Entra ID 的一项高级功能。 可以在 Deploy cloud-based Microsoft Entra 多重身份验证中找到有关此方法的详细信息。

选项 4：启用多重身份验证，并通过评估基于风险的条件访问策略实施条件访问策略。
权益：使用此选项可以：

• 检测影响组织标识的潜在漏洞。
• 配置自动响应与组织标识相关的可疑操作。
• 调查可疑事件，并采取适当的措施进行解决。

此方法使用“Microsoft Entra ID 标识保护”风险评估来确定是否需要基于所有云应用程序的用户和登录风险进行双重验证。 此方法需要 Microsoft Entra ID P2 许可。 可以在 Microsoft Entra ID Protection 中找到有关此方法的详细信息。

未添加额外标识保护层（如双重验证）的组织将更容易受到凭据窃取攻击。 凭据窃取攻击可能导致数据泄漏。

管理和监视用户密码

下表列出了与管理用户密码相关的一些最佳做法：

最佳做法：确保云中具有适当的密码保护级别。
详细信息：遵循 Microsoft密码指南中的指南，该指南的范围限定为Microsoft标识平台的用户（Microsoft Entra ID、Active Directory 和 Microsoft 帐户）。

最佳做法：监视与用户帐户相关的可疑操作。
详细信息：使用 Microsoft Entra 安全报告监视 有风险 的用户和 有风险的登录 。

最佳做法：自动检测和修正高风险密码。
详细信息： Microsoft Entra ID 保护是Microsoft Entra ID P2 版本的一项功能，可用于：

• 检测影响组织标识的潜在漏洞
• 配置自动响应，可检测与组织标识相关的可以操作
• 调查可疑事件，并采取适当的措施进行解决

接收来自 Microsoft 的事件通知

确保你的安全运营团队接收来自 Microsoft 的 Azure 事件通知。 事件通知让你的安全团队知道你已经破坏了某个 Azure 资源，目的是让他们可以快速响应并修正潜在的安全风险。

在 Azure 注册门户中，你可以确保管理员联系信息包含用来进行安全操作通知的详细信息。 联系人详细信息为电子邮件地址和电话号码。

将 Azure 订阅组织到管理组中

如果你的组织有多个订阅，则可能需要一种方法来高效地管理这些订阅的访问权限、策略和符合性。 Azure 管理组提供的范围级别高于订阅。 可将订阅组织到名为“管理组”的容器中，并将治理条件应用到管理组。 管理组中的所有订阅都将自动继承应用于管理组的条件。

可以在目录中构建管理组和订阅的灵活结构。 为每个目录指定了一个称为根管理组的顶级管理组。 此根管理组内置在层次结构中，包含其所有下级管理组和订阅。 该根管理组允许在目录级别应用全局策略和 Azure 角色分配。

下面是管理组使用方面的一些最佳做法：

最佳做法：确保在添加新订阅时应用政策和权限等治理元素。
详细信息：使用根管理组分配适用于所有 Azure 资产的企业范围安全元素。 策略和权限是元素的示例。

最佳做法：将管理组的顶级级别与分段策略保持一致，以提供一个控制点，并在每个段内实现策略一致性。
详细信息：为根管理组下的每个段创建单个管理组。 请勿在根下创建任何其他管理组。

最佳做法：限制管理组深度以避免阻碍作和安全性的混淆。
详细信息：将层次结构限制为三个级别，包括根。

最佳做法：请仔细选择要应用于具有根管理组的整个企业的项目。
详细信息：确保根管理组元素在每个资源中明确需要应用，并且它们的影响较低。

典型的候选项包括：

• 具有明确业务影响的法规要求（例如，与数据主权相关的限制）
• 对操作几乎没有潜在负面影响的要求，例如，其审核效果或 Azure RBAC 权限分配已经过仔细审查的策略

最佳做法：在应用根管理组之前仔细规划和测试所有企业范围的更改（策略、Azure RBAC 模型等）。
详细信息：根管理组中的更改可能会影响 Azure 上的每个资源。 尽管它们提供了一种强大的方法来确保整个企业中的一致性，但错误或不正确的使用可能会对生产操作产生负面影响。 请在测试实验室或生产试点中测试对根管理组的所有更改。

利用蓝图简化环境创建

Azure 蓝图 服务使云架构师和中心信息技术组能够定义一组可重复的 Azure 资源，这些资源可实现并遵守组织的标准、模式和要求。 使用 Azure 蓝图，开发团队可以快速生成新的环境并将其放在新的环境中，并提供一套内置组件，并确保他们在组织符合性中创建这些环境。

监视存储服务的意外行为更改

诊断和排查在云环境中托管的分布式应用程序中的问题可能会比在传统环境中更复杂。 应用程序可以部署在 PaaS 或 IaaS 基础结构、本地、移动设备，或这些环境的某种组合中。 应用程序的网络流量可能会遍历公用和专用网络，你的应用程序可能使用多种存储技术。

应持续监视应用程序使用的存储服务是否存在任何意外行为更改（如响应时间变长）。 若要收集更详细的数据和深度分析问题，请使用日志记录。 从监视和日志记录获取的诊断信息将有助于确定应用程序所遇到问题的根本原因。 然后，可以排查该问题，并确定修正问题的相应步骤。

Azure 存储分析 执行日志记录并为 Azure 存储帐户提供指标数据。 建议使用此数据跟踪请求、分析使用情况趋势以及诊断存储帐户的问题。

防范、检测和应对威胁

Microsoft Defender for Cloud 通过提高对 Azure 资源安全性的可见性（和控制）来帮助防止、检测和响应威胁。 它提供对 Azure 订阅的集成安全监视和策略管理，帮助检测可能被忽略的威胁，且适用于各种安全解决方案。

Defender for Cloud 的免费层为 Azure 中的资源以及 Azure 外已启用 Arc 的资源提供有限的安全性。 增强的安全性功能扩展了这些功能，以包括威胁和漏洞管理，以及法规符合性报告。 使用 Defender for Cloud 计划，可以查找和修复安全漏洞、应用访问和应用程序控制来阻止恶意活动、使用分析和情报检测威胁，以及在受到攻击时迅速做出响应。 可以在前 30 天内免费试用 Defender for Cloud 标准层。 建议在 Defender for Cloud 中的 Azure 订阅上启用增强的安全功能。

使用 Defender for Cloud 获取自己的数据中心、Azure 和其他云中所有资源的安全状态的集中视图。 一眼就可验证适当的安全控件是否配置到位且配置正确，还可快速确认任何需要注意的资源。

Defender for Cloud 还与 Microsoft Defender for Endpoint 集成，后者提供全面的终结点检测和响应（EDR）功能。 通过 Microsoft Defender for Endpoint 集成，可以发现异常并检测漏洞。 还可以检测和响应 Defender for Cloud 所监视的服务器终结点上出现的高级攻击。

几乎所有的企业组织都有一个安全信息和事件管理 (SIEM) 系统，它可以整合来自不同信号收集设备的日志信息，因此可以识别新出现的威胁。 然后，数据分析系统会对日志进行分析，以便从所有日志收集和分析解决方案的不可避免的干扰内容中找出“需关注”的内容。

Microsoft Sentinel 是一种可缩放的、云原生的安全信息和事件管理（SIEM）和安全业务流程自动响应（SOAR）解决方案。 Microsoft Sentinel 通过警报检测、威胁可见性、主动搜寻和自动威胁响应提供智能安全分析和威胁情报。

下面是一些用于预防、检测和响应威胁的最佳做法：

最佳做法：使用基于云的 SIEM 提高 SIEM 解决方案的速度和可伸缩性。
详细信息：调查 Microsoft Sentinel 的特性和功能，并将其与当前在本地使用的功能进行比较。 如果符合组织的 SIEM 要求，请考虑采用 Microsoft Sentinel。

最佳做法：查找最严重的安全漏洞，以便确定调查的优先级。
详细信息：查看 Azure 安全功能分数 ，查看内置于 Microsoft Defender for Cloud 中的 Azure 策略和计划的建议。 这些建议有助于解决顶级风险，例如安全更新、终结点保护、加密、安全配置、WAF 缺失、VM 连接到 Internet 等方面的风险。

安全评分基于 Internet 安全中心 (CIS) 控件，允许你根据外部源对组织的 Azure 安全性进行基准测试。 外部验证可帮助验证并扩充团队的安全策略。

最佳做法：监视计算机、网络、存储和数据服务以及应用程序的安全状况，以发现和确定潜在安全问题的优先级。
详细信息：请遵循 Defender for Cloud 中的 安全建议 （从优先级最高的项开始）。

最佳做法：将 Defender for Cloud 警报集成到安全信息与事件 (SIEM) 解决方案。
详细信息：具有 SIEM 的大多数组织都将其用作需要分析师响应的安全警报的中心清算所。 Defender for Cloud 生成的事件经过处理后，将被发布到 Azure 活动日志，这是 Azure Monitor 提供的日志类型之一。 Azure Monitor 提供了一个综合管道，可将任何监视数据路由到 SIEM 工具。 有关说明，请参阅 SIEM、SOAR 或 IT 服务管理解决方案的流警报 。 如果使用 Microsoft Sentinel，请参阅 Connect Microsoft Defender for Cloud。

最佳做法：将 Azure 日志与 SIEM 集成。
详细信息：使用 Azure Monitor 收集和导出数据。 此做法对于启用安全事件调查至关重要，而在线日志保留期是有限的。 如果使用 Microsoft Sentinel，请参阅 连接数据源。

最佳做法：通过将终结点检测和响应（EDR）功能集成到攻击调查中，加快调查和搜寻过程并减少误报。
详细信息：通过 Defender for Cloud 安全策略启用 Microsoft Defender for Endpoint 集成。 请考虑使用 Microsoft Sentinel 进行威胁搜寻和事件响应。

监视基于端到端方案的网络监视

客户在 Azure 中通过合并虚拟网络、ExpressRoute、应用程序网关和负载均衡器等网络资源来构建端到端网络。 监视适用于每个网络资源。

Azure 网络观察程序 是一项区域服务。 其诊断和可视化工具可用于在网络方案级别监视和诊断 Azure 内部以及传入和传出 Azure 的流量的状态。

以下是网络监视和可用工具的最佳做法。

最佳做法：使用数据包捕获自动执行远程网络监视。
详细信息：使用网络观察程序监视和诊断网络问题，而无需登录到 VM。 通过设置警报并获取对数据包级别的实时性能信息的访问权限来触发 数据包捕获 。 如果遇到问题，可进行详细调查，获得更精确的诊断。

最佳做法：使用流日志深入了解网络流量。
详细信息：使用 网络安全组流日志更深入地了解网络流量模式。 流日志中的信息可帮助收集符合性数据、审核和监视网络安全配置文件。

最佳做法：诊断 VPN 连接问题。
详细信息：使用网络观察程序 诊断最常见的 VPN 网关和连接问题。 不仅可以确定问题，还可以使用详细日志进一步调查。

使用经验证的 DevOps 工具确保安全部署

使用以下 DevOps 最佳做法来确保企业和团队多产且高效。

最佳做法：自动生成和部署服务。
详细信息： 基础结构即代码 是一组技术和做法，可帮助 IT 专业人员减轻模块化基础结构的日常生成和管理负担。 使得 IT 专业人员生成和维护新式服务器环境的方式就像是软件开发人员生成和维护应用程序代码的方式。

可以使用 Azure 资源管理器 通过声明性模板预配应用程序。 在单个模板中，可以部署多个服务及其依赖项。 在应用程序生命周期的每个阶段，可使用相同模板重复部署应用程序。

最佳做法：自动生成并部署到 Azure Web 应用或云服务。
详细信息：可以将 Azure DevOps Projects 配置为 自动生成并部署到 Azure Web 应用或云服务。 Azure DevOps 在每次代码签入后对 Azure 执行一次生成，然后自动部署二进制文件。 包生成过程与 Visual Studio 中的 Package 命令等效，而发布步骤与 Visual Studio 中的 Publish 命令等效。

最佳做法：自动执行发布管理。
详细信息： Azure Pipelines 是一种解决方案，用于自动执行多阶段部署和管理发布过程。 创建托管的持续部署管道，快速、轻松地频繁发布。 通过 Azure Pipelines，可以使发布过程自动化，还可以拥有预定义的批准工作流。 根据需要进行本地部署和部署到云、扩展和自定义。

最佳做法：在推出应用或将更新部署到生产环境之前，先检查该应用的性能。
详细信息：运行基于云的 负载测试 以：

• 在应用中查找性能问题。
• 提高部署质量。
• 请确保应用始终可用。
• 确保应用可以处理下一次启动或市场营销活动的流量。

Apache JMeter 是一款免费的常用开源工具，具有强大的社区支持。

最佳做法：监视应用程序性能。
详细信息： Azure Application Insights 是面向多个平台上的 Web 开发人员的可扩展应用程序性能管理（APM）服务。 使用 Application Insights 来监视实时 Web 应用程序。 它会自动检测性能异常。 其中包含分析工具来帮助诊断问题，了解用户在应用中实际执行了哪些操作。 Application Insights 有助于持续提高性能与可用性。

缓解和防范 DDoS

分布式拒绝服务 (DDoS) 是企图耗尽应用程序资源的一种攻击。 其目的是影响应用程序的可用性和处理合法请求的能力。 这些攻击正变得越来越复杂，且规模和影响程度越来越高。 它们可能会将任何可通过 Internet 公开访问的终结点作为目标。

设计和构建 DDoS 复原能力需要规划和设计各种故障模式。 下面是用于在 Azure 上构建 DDoS 可复原服务的最佳做法。

最佳做法：确保优先考虑从设计和实施到部署和操作的整个应用程序生命周期的安全性。 应用程序可能包含 bug，使相对较少的请求使用过多的资源，从而导致服务中断。
详细信息：为了帮助保护Microsoft Azure 上运行的服务，你应该对应用程序体系结构有很好的了解，并专注于 软件质量的五大支柱。 应该清楚典型的流量大小、应用程序与其他应用程序之间的连接模型，以及向公共 Internet 公开的服务终结点。

至关重要的一点是，确保应用程序具有足够的弹性，可应对针对应用程序本身的拒绝服务攻击。 安全和隐私内置于 Azure 平台中，从 安全开发生命周期（SDL）开始。 SDL 可以解决每个开发阶段的安全性，并确保 Azure 不断更新，以变得越来越安全。

最佳做法：设计应用程序以 横向缩放 以满足放大负载的需求，特别是在发生 DDoS 攻击时。 如果应用程序依赖于服务的单个实例，则会造成单一故障点。 预配多个实例能够提高复原能力和可伸缩性。
详细信息：对于 Azure 应用服务，请选择提供多个实例 的应用服务计划 。

对于 Azure 云服务，请将每个角色配置为使用 多个实例。

对于 Azure 虚拟机，请确保 VM 体系结构包含多个 VM，并且每个 VM 都包含在 可用性集中。 建议使用虚拟机规模集来实现自动缩放功能。

最佳做法：应用程序中的分层安全防御可以减少攻击成功的可能性。 使用 Azure 平台的内置功能对其应用程序实施安全设计。
详细信息：攻击风险会随着应用程序的规模（外围应用）的增大而增大。 可以使用审批列表关闭负载均衡器（Azure 负载均衡器和 Azure 应用程序网关）上不需要的公开 IP 地址空间和侦听端口，从而减少外围应用。

网络安全组 是减少攻击面的另一种方法。 可以使用 服务标记 和 应用程序安全组 来最大程度地减少创建安全规则和配置网络安全的复杂性，作为应用程序结构的自然扩展。

应尽可能在 虚拟网络 中部署 Azure 服务。 这种做法可让服务资源通过专用 IP 地址通信。 来自虚拟网络的 Azure 服务流量默认使用公共 IP 地址作为源 IP 地址。

使用 服务终结点 时，服务流量将切换为使用虚拟网络专用地址作为其源 IP 地址，以通过虚拟网络访问 Azure 服务。

我们经常看到，客户本地资源会连同其在 Azure 中资源的一起受到攻击。 如果将本地环境连接到 Azure，尽量不要在公共 Internet 上公开本地资源。

Azure 有两个 DDoS 服务方案，提供防御网络攻击的保护：

• 基本防护默认已集成到 Azure 中，不收取额外的费用。 全球部署的 Azure 网络的规模和容量通过始终开启的监视和实时缓解措施，来防御公用网络层攻击。 基本防护无需用户配置或应用程序更改，并帮助保护所有 Azure 服务，包括 Azure DNS 等 PaaS 服务。
• 标准防护提供针对网络攻击的高级 DDoS 缓解功能。 这些功能自动经过优化，可保护特定的 Azure 资源。 在创建虚拟网络期间，可以轻松启用保护。 也可以在创建之后启用它，而不需要对应用程序或资源做出任何更改。

启用 Azure Policy

Azure Policy 是 Azure 中的一项服务，用于创建、分配和管理策略。 这些策略将在整个资源中强制实施规则和效果，使这些资源符合公司标准和服务级别协议。 Azure Policy 通过评估资源是否符合指定策略来满足此需求。

启用 Azure Policy 来进行监视并强制实施组织的书面策略。 这样就可以集中管理混合云工作负荷中的安全策略，确保符合公司或法规安全要求。 了解如何 创建和管理策略以强制实施合规性。 有关策略元素的概述，请参阅 Azure Policy 定义结构 。

下面是在采用 Azure Policy 后要遵循的一些安全性最佳做法：

最佳做法：策略支持多种效果。 可以在 Azure Policy 定义结构中了解它们。 业务运营可能会受到 拒绝 效果和 修正 效果的负面影响，因此从 审核 效果开始，以限制策略的负面影响风险。
详细信息： 在审核模式下启动策略部署 ，然后在以后进行 拒绝 或 修正。 在移动到 拒绝 或 修正之前，测试和查看审核效果的结果。

有关详细信息，请参阅 创建和管理策略以强制实施合规性。

最佳做法：确定负责监视策略冲突的角色，并确保快速采取正确的修正作。
详细信息：通过 Azure 门户 或 命令行让分配的角色监视符合性。

最佳做法：Azure Policy 是组织的书面策略的技术表示形式。 将所有 Azure 策略定义映射到组织策略，以减少混乱并增强一致性。
详细信息：通过在 策略定义 或 计划定义 说明中添加对组织策略的引用，在组织的文档中或 Azure Policy 定义本身中进行文档映射。

监视 Microsoft Entra 风险报告

大多数安全违规出现在当攻击者通过窃取用户的标识来获取环境的访问权限时。 发现标识是否遭到入侵并不容易。 Microsoft Entra ID 使用自适应机器学习算法和试探法来检测与用户帐户相关的可疑操作。 每个检测到的可疑作都存储在称为 风险检测的记录中。 风险检测记录在 Microsoft Entra 安全报告中。 有关详细信息，请阅读 风险安全报告 和 有风险的登录安全报告。

后续步骤

请参阅 Azure 安全最佳做法和模式 ，了解在使用 Azure 设计、部署和管理云解决方案时要使用的更多安全最佳做法。

以下资源提供了有关 Azure 安全性及相关 Microsoft 服务的更多常规信息：

• Azure 安全团队博客 - 有关 Azure 安全的最新信息
• Microsoft安全响应中心 - Microsoft安全漏洞（包括 Azure 问题）可以报告或通过电子邮件向 secure@microsoft.com