Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
本文提供了一组用于保护Azure中的数据、应用程序和其他资产的作最佳做法。
最佳做法基于意见的共识,它们适用于当前的Azure平台功能和功能集。 观点和技术将随着时间改变,本文会定期更新以反映这些更改。
本文与Microsoft的 Zero Trust 安全模型保持一致,该模型假定存在违规,并且需要持续验证。 有关强制实施Azure Policy的规范性安全控制,请参阅 Microsoft Cloud Security Benchmark v2 - 事件响应和 MCSB v2 - 状况和漏洞管理。
定义并部署强大的操作安全做法
Azure运营安全性是指用户可用来保护他们在Azure中的数据、应用程序和其他资产的服务、控制措施和功能。 Azure作安全性建立在一个框架之上,该框架结合了通过Microsoft特有的功能获得的知识,包括安全开发生命周期(SDL)、Microsoft安全响应中心计划和对网络安全威胁状况的深入认识。
对用户强制执行多重身份验证
建议对所有用户要求进行双重验证。 这包括组织中的管理员和其他人员,如果他们的帐户泄露,可能会产生重大影响(例如,财务官员)。
要求双重验证有多种选项。 最佳选项取决于你的目标、正在运行的 Microsoft Entra 版本和你的许可计划。 请参阅如何要求对用户进行双重验证了解最佳选项。 有关许可证和定价的详细信息,请参阅 Microsoft Entra ID 和 Microsoft Entra Multifactor Authentication 定价页。
以下是启用双重验证的选项和优势:
选项 1:使用 Microsoft Entra 安全默认值为所有用户和登录方法启用 MFA。优势:借助此选项,可以轻松、快速地为环境中的所有用户强制执行 MFA,同时采用严格的策略来执行以下操作:
- 质疑管理帐户和管理登录认证机制
- 要求所有用户使用 Microsoft Authenticator 进行 MFA 认证挑战
- 限制旧身份验证协议。
此方法适用于所有许可层,但无法与现有条件Access策略混合使用。 若要了解详细信息,可参阅 Microsoft Entra 安全默认值
选项 2:通过更改用户状态启用多重身份验证。
优势:这是要求进行双重验证的传统方法。 它适用于云中的 Microsoft Entra 多重身份验证和 Azure 多重身份验证服务器。 使用此方法要求用户在每次登录时执行双重验证,并覆盖条件访问策略。
若要确定需要启用多重身份验证的位置,请参阅 哪些版本的 Microsoft Entra 多重身份验证适合我的组织?
Option 3:使用条件访问策略启用多重身份验证。 Benefit:此选项允许使用 Conditional Access在特定条件下提示进行双重验证。 特定条件可以是用户从不同位置、不受信任的设备或你认为存在风险的应用程序登录。 定义要求双重验证的特定条件可以避免不断提示用户这种令人不快的用户体验。
这是为用户启用双重验证最灵活的方式。 启用条件Access策略仅适用于云中的Microsoft Entra 多重身份验证,是Microsoft Entra ID的高级功能。 有关此方法的详细信息,请参阅部署基于云的 Microsoft Entra 多重身份验证。
注释
选项 2:通过更改用户状态启用多重身份验证,替代条件访问策略。 由于选项 3 使用条件访问策略,因此不能使用选项 2。
未添加额外标识保护层(如双重验证)的组织将更容易受到凭据窃取攻击。 凭据窃取攻击可能导致数据泄漏。
管理和监视用户密码
下表列出了与管理用户密码相关的一些最佳做法:
- 确保你在云端具有适当的密码保护级别:请参考《Microsoft 密码指南》中的建议,该指南的适用范围限定于 Microsoft 身份平台(Microsoft Entra ID、Active Directory 和 Microsoft 账户)的用户。
- 检测影响组织标识的潜在漏洞
- 配置自动响应处理与组织身份相关的被检测到的可疑操作。
- 调查可疑事件,并采取适当的措施进行解决
接收来自 Microsoft 的事件通知
请确保安全运营团队从Microsoft收到Azure事件通知。 事件通知使安全团队知道你已泄露了Azure资源,以便他们可以快速响应和修正潜在的安全风险。
在 Azure 注册门户中,可以确保管理员联系信息包括详细信息,以便通知安全操作团队。 联系人详细信息为电子邮件地址和电话号码。
将 Azure 订阅整理到管理组中
如果您的组织有多个订阅,您可能需要一种方法来有效管理这些订阅的访问、策略和合规性。 Azure管理组提供一个高于订阅的组织范围级别。 可将订阅组织到名为“管理组”的容器中,并将治理条件应用到管理组。 管理组中的所有订阅都将自动继承应用于管理组的条件。
可以在目录中构建管理组和订阅的灵活结构。 为每个目录指定了一个称为根管理组的顶级管理组。 此根管理组被纳入层次结构内,以便所有管理组和订阅统一归于此组。 根管理组允许在目录级别应用全局策略和Azure角色分配。
下面是管理组使用方面的一些最佳做法:
确保新订阅在添加策略和权限时应用治理元素。:使用根管理组分配应用于所有Azure资产的企业范围安全元素。 策略和权限是元素的示例。
使管理组的顶层与分段策略保持一致,以提供每个段内的控制和策略一致性点。:在根管理组下为每个段创建单个管理组。 请勿在根下创建任何其他管理组。
限制管理组深度以避免阻碍作和安全性的混淆。:将层次结构限制为三个级别,包括根级别。
仔细选择哪些项应用于具有根管理组的整个企业。:确保根管理组元素在每个资源中都明确需要应用,并且影响不大。
合适的候选项包括:
具有明确业务影响的法规要求(例如,与数据主权相关的限制)
对运营产生近乎零负面影响的要求,例如具有审计效果的策略或已仔细审查的 Azure 的 RBAC 权限分配。
在应用根管理组(策略、Azure RBAC 模型等)之前,认真规划和测试根管理组上的所有企业范围更改。:根管理组中的更改可能会影响Azure上的每个资源。 尽管它们提供了一种强大的方法来确保整个企业中的一致性,但错误或不正确的使用可能会对生产操作产生负面影响。 请在测试实验室或生产试点中测试对根管理组的所有更改。
利用蓝图简化环境创建
Azure Blueprints 服务使云架构师和中心信息技术组能够定义一组可重复的Azure资源,这些资源实现并遵循组织的标准、模式和要求。 Azure Blueprints使开发团队能够使用一组内置组件快速构建和建立新环境,并确信他们在组织合规性中创建这些环境。
监视存储服务的行为是否发生意外变化
诊断和排查在云环境中托管的分布式应用程序中的问题可能会比在传统环境中更复杂。 应用程序可以部署在 PaaS 或 IaaS 基础结构、本地、移动设备,或这些环境的某种组合中。 应用程序的网络流量可能会遍历公共网络和专用网络,应用程序可能使用多种storage技术。
应持续监控应用程序使用的存储服务,以应对行为的任何意外变化(例如响应时间变慢)。 若要收集更详细的数据和深度分析问题,请使用日志记录。 从监视和日志记录获取的诊断信息将有助于确定应用程序所遇到问题的根本原因。 然后,可以排查该问题,并确定修正问题的相应步骤。
Azure Storage Analytics执行日志记录并为Azure storage帐户提供指标数据。 建议使用此数据来跟踪请求、分析使用趋势,以及诊断storage帐户的问题。
防范、检测和应对威胁
Microsoft Defender for Cloud通过提高对Azure资源安全性的可见性,帮助防止、检测和响应威胁。 它跨Azure订阅提供集成的安全监视和策略管理,有助于检测可能忽略的威胁,并处理各种安全解决方案。
Defender for Cloud 的免费层为Azure中的资源以及Azure外部已启用 Arc 的资源提供有限的安全性。 增强型安全功能扩展了这些功能,包括威胁和漏洞管理以及法规合规性报告。 Defender for Cloud Plans 可帮助你查找和修复安全漏洞、应用access和应用程序控制来阻止恶意活动、使用分析和智能检测威胁,并在受到攻击时快速响应。 可以在前 30 天内免费试用 Defender for Cloud 标准层。 建议您在 Defender for Cloud 的 Azure 订阅中启用增强的安全功能。
使用 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 等方面的风险。
安全功能分数基于 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,请参阅 连接数据源。
基于端到端场景的网络监控
客户通过将网络资源(如 virtual network、ExpressRoute、Application Gateway 和负载均衡器)组合在Azure中构建端到端网络。 可以对每个网络资源进行监视。
Azure Network Watcher是区域服务。 使用其诊断和可视化工具来监视和诊断在、到及来自Azure的网络场景级别的情况。
以下是网络监视和可用工具的最佳做法。
自动化远程网络监控,利用数据包捕获:使用 Network Watcher 监控和诊断网络问题,而无需登录到您的虚拟机。 通过设置警报来触发数据包捕获,获取数据包级别的实时性能信息。 如果遇到问题,可进行详细调查,获得更精确的诊断。
使用流日志深入了解网络流量。:使用 网络安全组流日志更深入地了解网络流量模式。 流日志中的信息可帮助收集合规性数据、审核和监控您的网络安全状况。
诊断 VPN 连接问题。:使用 Network Watcher 诊断您最常见的 VPN 网关和连接问题。 不仅可以确定问题,还可以使用详细日志进一步调查。
缓解和防护 DDoS 攻击
分布式拒绝服务(DDoS)是一种尝试耗尽应用程序资源的攻击。 目标是影响应用程序的可用性及其处理合法请求的能力。 这些攻击变得越来越复杂,规模和影响更大。 它们可以针对可通过 Internet 公开访问的任何终结点。
设计和构建 DDoS 复原能力需要规划和设计各种故障模式。 下面是在 Azure 上构建 DDoS 复原服务的最佳做法。
- 确保优先考虑从设计和实施到部署和操作的整个应用程序生命周期的安全性。 应用程序可能存在可以让相对较少数量的请求消耗大量资源的缺陷,从而导致服务中断。为了帮助保护在Microsoft Azure上运行的服务,你应该对应用程序体系结构有很好的了解,并专注于软件质量的五个支柱。 你应该了解典型的流量、应用程序与其他应用程序之间的连接模型,以及暴露于公共互联网的服务端点。
确保应用程序具有足够的弹性来处理针对应用程序本身的拒绝服务,这一点最为重要。 安全和隐私内置于 Azure 平台中,从
- 将应用程序设计为水平缩放以满足放大负载的需求,特别是在发生 DDoS 攻击时。 如果应用程序依赖于服务的单个实例,则会造成单一故障点。 预配多个实例可使系统更具弹性且更具可缩放性。:对于 Azure App Service,请选择提供多个实例的 App Service 计划。
对于 Azure Cloud Services,请将每个角色配置为使用多个实例。
对于 Azure Virtual Machines,请确保 VM 体系结构包含多个 VM,并且每个 VM 都包含在 可用性集中。 建议使用Virtual Machine Scale Sets自动缩放功能。
- 应用程序中的分层安全防御可以减少攻击成功的可能性。 使用 Azure 平台的内置功能为应用程序实现安全设计。攻击的风险会随应用程序的表面积大小增加。 通过使用批准列表来减少攻击面,以关闭负载均衡器(Azure Load Balancer 和 Azure Application Gateway)上不需要的暴露IP地址空间和侦听端口。
网络安全组是减少攻击面的另一种方法。 可以使用 服务标记 和 应用程序安全组 来最大程度地减少创建安全规则和配置网络安全的复杂性,作为应用程序结构的自然扩展。
应尽可能在 virtual network 中部署Azure服务。 这种做法允许服务资源通过专用 IP 地址进行通信。 默认情况下,Azure来自virtual network的服务流量使用公共 IP 地址作为源 IP 地址。
使用服务终结点切换服务流量,以便在从虚拟网络访问 Azure 服务时使用虚拟网络专用地址作为源 IP 地址。
我们经常看到客户的本地资源受到攻击,以及其Azure中的资源。 如果要将本地环境连接到 Azure,请尽量减少本地资源暴露在公共互联网中的机会。
Azure有两个DDoS 服务套餐,用于防止网络攻击:
- 默认情况下,基本保护已集成到Azure,无需额外付费。 全球部署Azure网络的规模和容量通过始终启用的流量监视和实时缓解来防御常见的网络层攻击。 基本不需要用户配置或应用程序更改,并且有助于保护所有Azure服务,包括 paaS 服务(如 Azure DNS)。
- 标准保护针对网络攻击提供高级 DDoS 缓解功能。 它会自动调整,以保护特定的Azure资源。 在创建虚拟网络期间启用保护非常简单。 也可以在创建之后启用它,而不需要对应用程序或资源做出任何更改。
启用Azure Policy
Azure Policy是用于创建、分配和管理策略Azure中的服务。 这些策略将在整个资源中强制实施规则和效果,使这些资源符合公司标准和服务级别协议。 Azure Policy通过评估资源是否符合分配的策略来满足此需求。
启用Azure Policy以监视和强制实施组织的书面策略。 这样就可以集中管理混合云工作负荷中的安全策略,确保符合公司或法规安全要求。 了解如何创建和管理策略以强制实施合规性。 有关策略元素的概述,请参阅 Azure Policy 定义结构。
- 使用Azure Policy在整个环境中强制实施Microsoft云安全基准 v2(预览版)建议。:Microsoft云安全基准 v2(预览版)提供了全面的安全最佳做法,包括扩展的Azure Policy覆盖范围(420 多个基于策略的度量)。 将Microsoft云安全基准 v2(预览版)策略分配给订阅和管理组,以便持续审核并强制实施安全配置。 基准测试包括 AI 安全性、机密计算和增强的威胁检测的新控制措施。 使用 Defender for Cloud 法规合规性仪表板 跟踪合规性并识别需要修正的安全差距。
下面是采用Azure Policy后要遵循的一些安全最佳做法:
策略支持多种效果类型。 可以在 Azure Policy 定义结构中阅读它们。 业务运营可能会受到 拒绝 效果和 修正 效果的负面影响,因此请从 审核 效果开始,以限制策略的负面影响风险。: 在审核模式下启动策略部署 ,然后在以后 拒绝 或 修正进度。 在推进到拒绝或修正之前,请测试并评估审核结果的效果。
有关详细信息,请参阅创建和管理策略以强制实施符合性。
确定负责监视策略冲突的角色,并确保快速采取正确的修正作。:让分配的角色通过 Azure portal 或通过 命令行监视合规性。
Azure Policy是组织的书面策略的技术表示形式。 将所有Azure Policy定义映射到组织策略,以减少混淆并提高一致性。通过在策略定义或措施定义的说明中添加对组织政策的引用,记录组织文档或 Azure Policy 定义中的映射。
后续步骤
请参阅 Azure 安全最佳做法和模式,了解在使用 Azure 设计、部署和管理云解决方案时要使用的更多安全最佳做法。 了解 Microsoft 安全未来计划(SFI),Microsoft的内部安全框架基于Zero Trust原则,并与 NIST CSF 2.0 保持一致。 以下资源可用于提供有关Azure安全性和相关Microsoft服务的更常规信息:
- Azure安全团队博客 - 有关Azure安全的最新信息
- Microsoft安全响应中心 - Microsoft安全漏洞(包括Azure问题)可以报告或通过电子邮件向 secure@microsoft.com
- 查看 Microsoft 云安全基准 v2 - 事件响应和 MCSB v2 - 态势和漏洞管理控制,以获取包含 Azure 策略映射的综合运营安全指南。
- 深入了解 Microsoft 安全未来计划 (SFI),这是 Microsoft 的内部安全最佳实践,我们也向客户推荐使用。
- 浏览 Zero Trust 原则,了解如何实现Zero Trust安全体系结构。