Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
本文提供了一组用于保护Azure中的数据、应用程序和其他资产的作最佳做法。
最佳做法基于意见的共识,它们适用于当前的Azure平台功能和功能集。 意见和技术随时间而变化。 Microsoft 会定期更新本文以反映这些变化。
本文与Microsoft的 零信任 安全模型保持一致,该模型假定存在违规,并且需要持续验证。 有关强制实施Azure Policy的规范性安全控制,请参阅 Microsoft Cloud Security Benchmark v2 - 事件响应和 MCSB v2 - 状况和漏洞管理。
定义并部署强大的操作安全做法
Azure运营安全性是指用户可用来保护他们在Azure中的数据、应用程序和其他资产的服务、控制措施和功能。 Azure作安全性建立在一个框架之上,该框架结合了通过Microsoft特有的功能获得的知识,包括安全开发生命周期(SDL)、Microsoft安全响应中心计划和对网络安全威胁状况的深入认识。
对用户强制执行多重身份验证
要求所有用户进行两步验证。 这一要求包括管理人员以及在账户被盗时可能产生重大影响的组织成员,如财务官员。
你有多种方式要求两步验证。 最佳选项取决于你的目标、正在运行的 Microsoft Entra 版本和你的许可计划。 请参阅如何要求对用户进行双重验证了解最佳选项。 有关许可和定价的更多信息,请参阅 Microsoft Entra ID 和 Microsoft Entra 多因素认证文档。
以下选项和优势可以帮助您实现两步验证:
选项1:为所有用户和登录方式启用多重身份验证。Microsoft Entra 安全默认优势:此选项允许您通过严格的策略快速为环境中所有用户强制多重身份验证:
- 质疑管理帐户和管理登录认证机制
- 要求所有用户通过 Microsoft Authenticator 完成多重身份验证质询
- 限制旧身份验证协议。
你可以在所有许可层级使用这种方法,但不能与现有的条件访问政策结合使用。 欲了解更多信息,请参见 Microsoft Entra 安全默认设置。
选项 2:通过更改用户状态启用多重身份验证。 优点:选项2是传统的两步验证方法。 该方法适用于云端的 Microsoft Entra 多因素认证和 Azure 多因素认证服务器。 此方法要求用户在每次登录和替代条件访问策略时执行双重验证。
要确定在哪里启用多因素认证,请参见 Microsoft Entra 多因素认证哪个版本适合我的组织?
Option 3:使用条件访问策略启用多重身份验证。 优势:该选项使用 条件访问,在特定条件下要求进行两步验证。 特定条件可以是用户从不同位置、不受信任的设备或你认为存在风险的应用程序登录。 定义要求双重验证的特定条件可以避免不断提示用户这种令人不快的用户体验。
选项3是为用户启用两步验证的最灵活方式。 启用条件Access策略仅适用于云中的Microsoft Entra 多重身份验证,是Microsoft Entra ID的高级功能。 有关此方法的详细信息,请参阅部署基于云的Microsoft Entra多重身份验证。
注释
选项 2:通过更改用户状态启用多重身份验证,替代条件访问策略。 由于选项 3 和 4 使用条件访问策略,因此不能对它们使用选项 2。
没有增加额外身份保护层(如两步验证)的组织更容易遭受凭证盗窃攻击。 凭据窃取攻击可能导致数据泄漏。
管理和监视用户密码
下表列出了与管理用户密码相关的一些最佳做法:
- 确保云端的密码保护水平达到适当。 请遵循 Microsoft 密码指南中的指导,该指南适用于 Microsoft 身份平台的用户(Microsoft Entra ID、Active Directory 和 Microsoft 帐户)。
接收来自 Microsoft 的事件通知
确保您的安全运营团队收到来自Microsoft的Azure事件通知。 事件通知帮助安全团队了解您的 Azure 资源已被攻破,从而能够快速响应并修复潜在的安全风险。
在 Azure 注册门户中,可以确保管理员联系信息包括详细信息,以便通知安全操作团队。 联系人详细信息为电子邮件地址和电话号码。
将 Azure 订阅整理到管理组中
如果您的组织有多个订阅,您可能需要一种方法来有效管理这些订阅的访问、策略和合规性。 Azure管理组提供一个高于订阅的组织范围级别。 可将订阅组织到名为“管理组”的容器中,并将治理条件应用到管理组。 管理组中的所有订阅都将自动继承应用于管理组的条件。
可以在目录中构建管理组和订阅的灵活结构。 为每个目录指定了一个称为根管理组的顶级管理组。 此根管理组被纳入层次结构内,以便所有管理组和订阅统一归于此组。 根管理组允许在目录级别应用全局策略和Azure角色分配。
下面是管理组使用方面的一些最佳做法:
确保新订阅在添加时应用治理元素,如策略和权限。 使用根管理组分配适用于所有 Azure 资产的全企业安全元素。 策略和权限是元素的示例。
将管理组的顶层与你的细分策略对齐,为每个细分区块内的控制和政策一致性提供一个点。 在根管理组下为每个段创建一个管理组。 请勿在根下创建任何其他管理组。
限制管理组的深度,以避免混淆,从而影响运营和安全。 将层次结构限制为三层,包括根节点。
请谨慎选择要通过根管理组应用到整个企业的项目。 确保根管理组元素明确需要应用于每个资源,并且影响低。
合适的候选项包括:
具有明确业务影响的监管要求,如与数据主权相关的限制。
那些对运营几乎没有负面影响的需求,比如带有审计效果的策略,或者经过仔细审查的Azure RBAC权限分配。
在应用根管理组的所有企业范围变更(策略、Azure RBAC模型等)前,务必仔细规划和测试。 根管理组的变更可能影响Azure上的所有资源。 尽管它们提供了一种强大的方法来确保整个企业中的一致性,但错误或不正确的使用可能会对生产操作产生负面影响。 请在测试实验室或生产试点中测试对根管理组的所有更改。
通过部署堆栈和模板规范简化环境创建
使用 Azure 部署堆栈,将可重复的 Azure 资源集合部署和管理为一个整体。 部署栈支持 Bicep 和 Azure 资源管理器 模板、生命周期管理以及拒绝设置,帮助保护被管理资源免受不必要的更改。 使用 Azure 资源管理器 模板规范来存储、版本化并在组织内共享批准的模板。
监视存储服务的行为是否发生意外变化
在云环境中托管的分布式应用中,诊断和排查问题可能比传统环境更复杂。 你可以在PaaS或IaaS基础设施中部署应用,无论是本地部署、移动设备上,还是在这些环境的某种组合中。 应用程序的网络流量可能会遍历公共网络和专用网络,应用程序可能使用多种storage技术。
持续监控应用使用的存储服务,以防任何意外的行为变化,比如响应时间变慢。 若要收集更详细的数据和深度分析问题,请使用日志记录。 你从监控和日志中获得的诊断信息,有助于你确定应用遇到问题的根本原因。 然后你可以排查问题并确定合适的修复步骤。
Azure 存储分析执行日志记录并为Azure storage帐户提供指标数据。 利用这些数据追踪请求,分析使用趋势,并诊断存储账户的问题。
防范、检测和应对威胁
Microsoft Defender for Cloud 通过增强对 Azure 资源安全的可视性和控制,帮助您预防、检测和响应威胁。 Defender for Cloud 为您的 Azure 订阅提供集成的安全监控和策略管理,帮助检测可能被忽视的威胁,并配合多种安全解决方案。
Defender for Cloud 包含基础云安全态势管理(CSPM)功能,并免费访问 Microsoft Defender XDR。 若要扩展保护范围,请为要保护的工作负载启用 Defender for Cloud 的付费计划,例如 Defender CSPM、容器 Defender、应用服务 Defender、资源管理器 Defender、API Defender 和 AI 服务 Defender。 这些计划帮助您发现并修复安全漏洞,应用访问和应用控制以阻止恶意活动,利用分析和情报检测威胁,并在遭受攻击时迅速响应。
你可以在前30天免费试用Defender for Cloud,直到某些套餐达到使用限额,以先到者为准。 试用期或使用限额结束后,费用会根据您在环境中启用的套餐开始计算。 更多信息请参见“连接您的Azure订阅”和“什么是Microsoft Defender for Cloud?”。
使用 Defender for Cloud 获取自己的数据中心、Azure和其他云中所有资源的安全状态的中心视图。 一眼就可验证适当的安全控件是否配置到位且配置正确,还可快速确认任何需要注意的资源。
几乎所有的企业组织都有一个安全信息和事件管理 (SIEM) 系统,它可以整合来自不同信号收集设备的日志信息,因此可以识别新出现的威胁。 随后,数据分析系统会分析这些日志,帮助从所有日志收集和分析解决方案中不可避免的噪声中辨别出“有趣”的部分。
Microsoft Sentinel 是可缩放的云原生安全信息与事件管理 (SIEM) 和安全业务流程自动响应 (SOAR) 解决方案。 Microsoft Sentinel通过警报检测、威胁可视化、主动搜寻和自动化威胁响应,提供智能安全分析和威胁情报。
下面是一些用于预防、检测和响应威胁的最佳做法:
通过使用基于云的SIEM,提升您的SIEM解决方案的速度和可扩展性。 调查 Microsoft Sentinel 的功能和能力,并将其与你当前本地使用的设备进行比较。 如果符合组织的 SIEM 要求,请考虑采用 Microsoft Sentinel。
找出最严重的安全漏洞,以便优先进行调查。 查看您的 Azure 安全评分,了解 Microsoft Defender for Cloud 内置的 Azure 政策和举措所产生的推荐。 这些建议有助于解决顶级风险,例如安全更新、终结点保护、加密、安全配置、WAF 缺失、VM 连接到 Internet 等方面的风险。
安全评分基于互联网安全中心(CIS)的控制措施,帮助您将组织的Azure安全性与外部来源进行基准对比。 外部验证可帮助验证并扩充团队的安全策略。
监控机器、网络、存储和数据服务及应用的安全态势,以发现并优先处理潜在的安全问题。 按照 Defender for Cloud 中的安全建议,从最高优先级的项目开始。
将 Defender for Cloud 警报集成到您的安全信息与事件管理(SIEM)解决方案中。 大多数使用 SIEM 的组织都将其作为需要分析师进行响应的安全警报的集中处理中心。 Defender for Cloud 生成的已处理事件发布到Azure活动日志,这是通过 Azure Monitor 提供的日志之一。 Azure Monitor 提供了一个合并管道,用于将任何监视数据路由到 SIEM 工具。 有关说明,请参阅将警报流式传输到 SIEM、SOAR 或 IT 服务管理解决方案。
将Azure日志与你的SIEM集成。 使用Azure Monitor来收集和导出数据。 此做法对于启用安全事件调查至关重要,而在线日志保留期是有限的。 如果使用 Microsoft Sentinel,请参阅 连接数据源。
基于端到端场景的网络监控
组织通过结合虚拟网络、ExpressRoute、应用网关和负载均衡器等网络资源,在Azure中构建端到端网络。 你可以监控这些网络资源。
Azure 网络观察程序是区域服务。 使用其诊断和可视化工具来监视和诊断在、到及来自Azure的网络场景级别的情况。
以下是网络监视和可用工具的最佳做法。
通过数据包捕获实现远程网络监控自动化。 使用网络观察程序监控和诊断网络问题,无需登录虚拟机即可。 通过设置警报来触发数据包捕获,获取数据包级别的实时性能信息。 当你发现问题时,可以详细调查以获得更好的诊断。
通过使用流量日志深入了解你的网络流量。 通过使用 网络安全组流量日志,深入理解您的网络流量模式。 流日志中的信息可帮助收集合规性数据、审核和监控您的网络安全状况。
诊断VPN连接问题。 使用网络观察程序来诊断常见的VPN 网关和连接问题。 你可以找出问题所在,并利用详细日志进一步调查。
缓解和防护 DDoS 攻击
分布式拒绝服务(DDoS)是一种尝试耗尽应用程序资源的攻击。 目标是影响应用程序的可用性及其处理合法请求的能力。 这些攻击变得越来越复杂,规模和影响更大。 攻击者可能针对任何通过互联网公开可访问的终端。
设计和构建 DDoS 复原能力需要规划和设计各种故障模式。 下面是在 Azure 上构建 DDoS 复原服务的最佳做法。
- 确保优先考虑从设计和实施到部署和操作的整个应用程序生命周期的安全性。 应用程序可能存在漏洞,导致相对较少的请求消耗大量资源,导致服务中断。 为了帮助保护运行在 Azure 上的服务,你应当对应用架构有充分理解,并关注软件质量的五大支柱。 你应该了解典型的流量、应用程序与其他应用程序之间的连接模型,以及暴露于公共互联网的服务端点。
确保应用程序具有足够的弹性来处理针对应用程序本身的拒绝服务,这一点最为重要。 安全和隐私内置于 Azure 平台中,从
- 将应用程序设计为水平缩放以满足放大负载的需求,特别是在发生 DDoS 攻击时。 如果应用程序依赖于服务的单个实例,则会造成单一故障点。 预配多个实例可使系统更具弹性且更具可缩放性。 对于 Azure 应用服务,请选择提供多个实例的应用服务计划。
对于 Azure 云服务,请将每个角色配置为使用多个实例。
对于 Azure 虚拟机,请确保 VM 体系结构包含多个 VM,并且每个 VM 都包含在 可用性集中。 使用虚拟机规模集实现自动扩展功能。
- 应用程序中的分层安全防御可以减少攻击成功的可能性。 使用 Azure 平台的内置功能为应用程序实现安全设计。 攻击风险随着应用面积(表面积)的增加而增加。 你可以通过使用允许列表关闭暴露的IP地址空间和负载均衡器不需要的监听端口来减少表面积(Azure 负载均衡器和Azure 应用程序网关)。
网络安全组是减少攻击面的另一种方法。 可以使用 服务标记 和 应用程序安全组 来最大程度地减少创建安全规则和配置网络安全的复杂性,作为应用程序结构的自然扩展。
应尽可能在 virtual network 中部署Azure服务。 这种做法允许服务资源通过专用 IP 地址进行通信。 默认情况下,Azure来自virtual network的服务流量使用公共 IP 地址作为源 IP 地址。
使用服务终结点切换服务流量,以便在从虚拟网络访问 Azure 服务时使用虚拟网络专用地址作为源 IP 地址。
攻击者可以针对本地资源以及Azure中的资源。 如果要将本地环境连接到 Azure,请尽量减少本地资源暴露在公共互联网中的机会。
Azure有两个DDoS 服务套餐,用于防止网络攻击:
- DDoS基础设施保护默认集成到Azure中,无需额外费用。 全球部署的Azure网络规模和容量通过始终在线的流量监控和实时缓解措施,防御常见的网络层攻击。 基础设施保护无需用户配置或应用更改,帮助保护所有 Azure 服务,包括像 Azure DNS 这样的 PaaS 服务。
- DDoS 网络保护提供先进的 DDoS 防护能力,可抵御网络攻击。 它会自动调整,以保护特定的Azure资源。 你可以在虚拟网络创建时或创建后启用保护,且无需更改应用程序或资源。
启用Azure Policy
Azure Policy是用于创建、分配和管理策略Azure中的服务。 这些策略将在整个资源中强制实施规则和效果,使这些资源符合公司标准和服务级别协议。 Azure Policy通过评估资源是否符合分配的策略来满足此需求。
启用Azure Policy以监视和强制实施组织的书面策略。 这种方法通过集中管理混合云工作负载的安全策略,确保符合公司或监管的安全要求。 了解如何创建和管理策略以强制实施合规性。 有关策略元素的概述,请参阅 Azure Policy 定义结构。
- 使用 Azure Policy 在您的环境中强制执行 Microsoft Cloud Security Benchmark v2(预览版)建议。 Microsoft Cloud Security Benchmark v2(预览版)提供了全面的安全最佳实践,并扩展了 Azure Policy 覆盖范围(420+ 基于策略的测量)。 将Microsoft云安全基准 v2(预览版)策略分配给订阅和管理组,以便持续审核并强制实施安全配置。 基准测试包括 AI 安全性、机密计算和增强的威胁检测的新控制措施。 使用 Defender for Cloud 法规合规性仪表板 跟踪合规性并识别需要修正的安全差距。
下面是采用Azure Policy后要遵循的一些安全最佳做法:
在审计模式下启动策略部署。 策略支持多种效果类型。 可以在 Azure Policy 定义结构中阅读它们。 业务运营可能会受到 拒绝 效果和 修正 效果的负面影响,因此从 审核 效果开始,以限制策略的负面影响风险。 随后,进而选择拒止或修正。 在推进到拒绝或修正之前,请测试并评估审核结果的效果。
有关详细信息,请参阅创建和管理策略以强制实施符合性。
Azure Policy是组织的书面策略的技术表示形式。 将所有Azure Policy定义映射到组织策略,以减少混淆并提高一致性。 在组织文档中或 Azure Policy 定义中,通过在策略定义或倡议定义描述中添加对组织策略的引用来进行文档映射。
后续步骤
有关在 Azure 环境中响应安全事件的指南,请参阅 事件响应概述 。 请参阅 Azure 安全最佳做法和模式,了解在使用 Azure 设计、部署和管理云解决方案时要使用的更多安全最佳做法。
以下资源可用于提供有关Azure安全性和相关Microsoft服务的更常规信息:
- Azure 安全团队博客——获取有关 Azure 安全最新动态的最新信息。
- Microsoft 安全响应中心 - 用于报告 Microsoft 安全漏洞,包括 Azure 的问题。 你也可以通过电子邮件向 secure@microsoft.com 报告漏洞。
- 查看 Microsoft 云安全基准 v2 - 事件响应和 MCSB v2 - 态势和漏洞管理控制,以获取包含 Azure 策略映射的综合运营安全指南。
- 了解Microsoft安全未来计划(SFI),即Microsoft内部安全最佳实践。
- 浏览 零信任 原则,了解如何实现零信任安全体系结构。