Download as pdf or txt
Download as pdf or txt
You are on page 1of 304

Contents

基础知识文档
概述
Azure 安全性简介
云中责任分担
在 Azure 中保护工作负荷
安全技术功能
内置安全控件
Azure 平台和基础结构
基础结构安全性
物理安全性
可用性
组件和边界
网络体系结构
生产网络
SQL 数据库
操作
监视
完整性
数据保护
平台完整性和安全性
固件安全性
安全启动
度量启动和主机证明
Cerberus 项目
静态加密
虚拟机监控程序安全性
Azure 云中的隔离
身份管理
安全概述
最佳做法
安全清单
选择无密码
网络安全
安全概述
最佳做法
DDoS 防护最佳做法
DDoS 防护安全基线
无关联的 DNS 和子域接管
安全混合网络体系结构
IaaS 安全
Microsoft 反恶意软件
Microsoft Antimalware 代码示例
虚拟机安全性概述
最佳做法 - IaaS 工作负荷
Azure 市场映像
数据安全性、加密和存储
数据安全与加密
双重加密
TLS 证书更改
磁盘加密
最佳做法
静态数据加密
数据加密模型
适用于虚拟机的 Azure 磁盘加密
数据库安全
概述
最佳做法
安全清单
存储安全指南
客户密码箱
客户密码箱安全基线
应用程序
PaaS
适用于 PaaS 的 Azure 应用服务
适用于 PaaS 的 Azure 存储
适用于 PaaS 的 DB 最佳做法
Azure Service Fabric 安全
监视、审核和操作
威胁防护
Azure 日志记录和审核
安全管理和监视
增强远程管理
运营安全
概述
最佳做法
安全清单
资源
Azure 安全服务
安全性白皮书
最佳做法
网络安全咨询
记录安全事件支持票证
渗透测试
Azure 域
Azure 安全性简介
2021/2/9 • • Edit Online

概述
我们知道,安全是云中的首要任务,及时找到有关 Azure 安全性的准确信息极其重要。 将 Azure 用于应用程序和
服务的最合理原因之一是可以利用其各种安全工具和功能。 这些工具和功能可帮助在安全的 Azure 平台上创建
安全的解决方案。 Microsoft Azure 提供具备保密性、完整性和可用性的客户数据,同时还能实现透明的问责制。

本文全面介绍了 Azure 提供的安全机制。

Azure 平台
Azure 是一个公有云服务平台,支持极为广泛的操作系统、编程语言、框架、工具、数据库和设备选择。 它可运行
与 Docker 集成的 Linux 容器;使用 JavaScript、Python、.NET、PHP、Java 和 Node.js 生成应用;生成适用于 iOS 、
Android 和 Windows 设备的后端。
Azure 公有云服务支持数百万开发人员和 IT 专业人士已经有所依赖并信任的相同技术。 构建 IT 资产或将其迁移
到公有云服务提供商处时,需要借助该组织的能力来保护应用程序和数据,并使用该组织提供的服务和控制机制
来管理基于云的资产的安全性。

Azure 的基础结构(从设备到应用程序)经过设计,可同时托管数百万的客户,并为企业提供可靠的基础,使之能
够满足其安全要求。

此外,Azure 还提供广泛的可配置安全选项以及对这些选项进行控制的功能,方便用户自定义安全措施来满足组
织部署的独特要求。 本文档可帮助用户了解 Azure 安全功能如何帮助满足这些要求。

NOTE
本文档重点介绍面向客户的控件,客户可以使用这些控件自定义和提高应用程序和服务的安全性。

有关 Microsoft 如何保护 Azure 平台本身的信息,请参阅 Azure 基础结构安全性。

Azure 安全功能汇总
用于保 护 Azure 平台的功能
以下功能可以用于确保以安全的方式管理 Azure 平台。 提供了相应链接,方便用户进一步了解 Microsoft 如何从
四个方面解决客户信任问题:安全平台、隐私和控制、合规性和透明度。

安全开发周期,内部审核 随时进行数据管理 信任中心 Microsoft 如何保护 Azure


服务中的客户数据

强制性安全培训、背景检查 控制数据位置 通用控制中心 Microsoft 如何管理 Azure


服务中的数据位置

渗透测试,入侵检 根据条件提供数据访问 云服务审慎调查清单 Microsoft 中的哪些人员可


测,DDoS,审核和日志记录 以根据哪些条款访问数据

艺术数据中心、物理安全、安 响应执法部门 服务、位置和行业的符合性 Microsoft 如何保护 Azure


全网络的状态 服务中的客户数据
安全事件响应,共担责任 严格的隐私标准 查看 Azure 服务和透明度中
心的认证

用于保 护 数据和 应 用程序的功能


根据云服务模型,负责管理应用程序或服务的安全的人员需承担各种不同的责任。 Azure 平台中提供的功能可帮
助用户通过内置功能以及可部署到 Azure 订阅中的合作伙伴解决方案来履行这些职责。

内置功能划分为六个功能区:操作、应用程序、存储、网络、计算和标识。 摘要信息对 Azure 平台在这六个区域内


提供的特性和功能进行了详细介绍。

操作
本部分提供了关于安全操作中主要特性的其他信息以及有关这些功能的摘要信息。

“安全和 审 核 ”仪 表板
安全和审核解决方案借助内置搜索查询找到需要关注的重要问题,从而提供有关组织的 IT 安全态势的全面观
点。 “安全和审核”仪表板是主屏幕,提供 Azure Monitor 日志中与安全性相关的所有内容。 它提供计算机安全状
态的高级洞见。 还允许查看过去 24 小时、7 天或任何自定义时间范围的所有事件。

此外,检测到特定事件时,可以将安全性和符合性配置为自动执行特定操作。

Azure Resource Manager


可以使用 Azure Resource Manager 将解决方案中的资源作为一个组进行处理。 可以通过一个协调的操作为解决
方案部署、更新或删除所有资源。 可以使用 Azure 资源管理器模板来完成部署,该模板适用于测试、过渡和生产
等不同环境。 Resource Manager 提供安全、审核和标记功能,以帮助你在部署后管理资源。

基于 Azure 资源管理器模板的部署因其标准的安全控制设置,有助于提高 Azure 中部署的解决方案的安全性,并


且还可以集成到基于标准化模板的部署中。 这样可以降低手动部署期间可能发生的安全配置错误风险。

Application Insights
Application Insights 是面向 Web 开发人员的可扩展应用程序性能管理 (APM) 服务。 用户可以使用 Application
Insights 监视实时 Web 应用程序并自动检测性能异常。 Application Insights 内含强大的分析工具,有助于诊断
问题并了解用户在应用中实际执行的操作。 它在应用程序运行时全程进行监视,包括测试期间以及发布或部署
之后。

Application Insights 可创建图表和表格来显示多种信息,例如,一天中的哪些时间用户最多、应用的响应能力如


何,以及应用依赖的任何外部服务是否顺利地为其提供服务。

如果出现崩溃、故障或性能问题,可以搜索详细的遥测数据来诊断原因。 此外,如果应用的可用性和性能有任何
变化,该服务还会向用户发送电子邮件。 Application Insight 就是这样因其有助于实现保密性、完整性和可用性
安全三元素的可用性而成为有价值的安全工具。

Azure Monitor
Azure Monitor 对来自 Azure 基础结构(活动日志)和每个单独的 Azure 资源(诊断日志)的数据提供可视化效果、
查询、路由、警报、自动缩放和自动化功能。 可以使用 Azure Monitor 对 Azure 日志中生成的与安全相关的事件
发出警报。

Azure Monitor 日志
Azure Monitor 日志 - 为本地基础结构和第三方基于云的基础结构(例如 AWS ),以及 Azure 资源提供 IT 管理解
决方案。 可以将来自 Azure Monitor 的数据直接路由到 Azure Monitor 日志,因此可以在一个位置查看整个环境
的指标和日志。

在取证和其他安全分析中,Azure Monitor 日志是非常有用的工具,因为使用该工具能通过灵活的查询方法快速


搜索大量与安全相关的条目。 此外,本地防火墙和代理日志可以导出到 Azure 中,并可以使用 Azure Monitor 日
志进行分析。

Azure 顾问
Azure 顾问是一种个性化的云顾问,可帮助优化 Azure 部署。 它分析资源配置和使用情况遥测数据。 然后,它推
荐解决方案,帮助提高资源的性能、安全性和高可用性,同时寻找机会减少总体 Azure 支出。 Azure 顾问提供安
全建议,可显著提高在 Azure 中部署的解决方案的总体安全状况。 这些建议来自于 Azure 安全中心执行的安全
分析。

Azure 安全中心
安全中心有助于预防、检测和响应威胁,同时提高对 Azure 资源安全的可见性和可控性。 它提供 Azure 订阅之间
的集成安全监视和策略管理,帮助检测可能被忽略的威胁,且适用于广泛的安全解决方案生态系统。

此外,安全中心通过提供单个仪表板实现可立即执行的警报和建议,从而帮助进行安全操作。 通常,只需在安全
中心控制台中单击一下就可修复问题。

应用程序
本部分提供了关于应用程序安全中主要特性的其他信息以及有关这些功能的摘要信息。

Web 应 用程序漏洞 扫 描
开始对应用服务应用进行漏洞测试最简单的一种方法是使用与 Tinfoil Security 的集成对应用执行一键式漏洞扫
描。 可以查看易于理解的报告中的测试结果,并了解如何按照分步说明修复每个安全漏洞。

渗透 测试
如果想要执行自己的渗透测试,或者想要使用其他扫描程序套件或提供程序,则必须按照 Azure 渗透测试审批流
程 来进行并获得事先批准才能执行所需的渗透测试。

Web 应 用程序防火 墙
Azure 应用程序网关中的 Web 应用程序防火墙 (WAF) 可帮助保护 Web 应用程序,使其免受常见基于 Web 的攻
击威胁,例如 SQL 注入、跨站点脚本攻击和会话劫持。 同时预先配置保护,免受 Open Web Application Security
Project (OWASP) 标识为前 10 种常见漏洞的威胁攻击。
Azure 应 用服 务 中的身份 验证 和授 权
应用服务身份验证/授权是一项功能,方便应用程序登录用户,避免在应用后端更改代码。 该功能可以方便地保
护应用程序和处理每个用户的数据。

分 层 安全体系 结 构
由于应用服务环境提供部署到 Azure 虚拟网络的隔离运行时环境,因此开发人员能够创建分层安全体系结构,针
对每个应用层提供不同级别的网络访问权限。 常见的需求之一是要隐藏对 API 后端的常规 Internet 访问,而只允
许由上游 Web 应用调用 API。 可以在包含应用服务环境的 Azure 虚拟网络子网上使用网络安全组 (NSG),限制
对 API 应用程序的公共访问。

Web 服 务 器 诊 断和 应 用程序 诊 断
应用服务 Web 应用为 Web 服务器和 Web 应用程序中的日志记录信息提供诊断功能。 这些诊断功能按逻辑分为
Web 服务器诊断和应用程序诊断。 Web 服务器包括诊断和排查站点和应用程序这两大改进方面。
第一个新特点是有关应用程序池、工作进程、站点、应用程序域和运行请求的实时状态信息。 第二个新特点是在
整个请求和响应过程中跟踪请求的详细跟踪事件。

要启用这些跟踪事件的收集,可以将 IIS 7 配置为根据运行时间或错误响应代码自动捕获任何特定请求的完整跟


踪日志(采用 XML 格式)。

Web 服 务 器 诊 断
可以启用或禁用以下种类的日志:

详细错误日志记录 - 指示故障的 HTTP 状态代码(状态代码 400 或更大数字)的详细错误消息。 其中可能


包含有助于确定服务器返回错误代码的原因的信息。

失败请求跟踪 - 有关失败请求的详细信息,包括对用于处理请求的 IIS 组件和每个组件所用的时间的跟


踪。 在尝试提高站点性能或隔离导致要返回特定 HTTP 错误的内容时,此信息很有用。

Web 服务器日志记录 - 使用 W3C 扩展日志文件格式的 HTTP 事务信息。 这在确定整体站点度量值(如处


理的请求数量或来自特定 IP 地址的请求数)时非常有用。

应 用程序 诊 断

应用程序诊断可以捕获由 Web 应用程序生成的信息。 ASP.NET 应用程序可使用 System.Diagnostics.Trace 类将信


息记录到应用程序诊断日志。 在应用程序诊断中,有两种主要类型的事件,即与应用程序性能相关的事件以及与
应用程序故障和错误相关的事件。 故障和错误可以进一步分为连接性、安全性和故障问题。 故障问题通常与应
用程序代码问题相关。

在应用程序诊断中,可以查看按以下方式分组的事件:

全部(显示所有事件)
应用程序错误(显示异常事件)
性能(显示性能事件)

存储
本部分提供了关于 Azure 存储安全中主要特性的其他信息以及有关这些功能的摘要信息。

Azure 基于角色的 访问 控制 (Azure RBAC )


可以使用 Azure RBAC) (azure 基于角色的访问控制来保护存储帐户。 对于想要实施数据访问安全策略的组织而
言,必须根据需知原则和最低权限安全原则限制访问权限。 这些访问权限是通过将相应的 Azure 角色分配给特
定范围内的组和应用程序来授予的。 可以使用Azure 内置角色(例如存储帐户参与者)将权限分配给用户。 可以
通过 Azure RBAC 控制使用 azure 资源管理器 模型对存储帐户的存储密钥的访问权限。

共享 访问签 名
共享访问签名 (SAS) 用于对存储帐户中的资源进行委托访问。 使用 SAS ,意味着可以授权客户端在指定时间段
内,以一组指定权限有限访问存储帐户中的对象。 可以授予这些有限的权限,而不必共享帐户访问密钥。

传输 中加密
传输中加密是通过网络传输数据时用于保护数据的机制。 在 Azure 存储中,可以使用以下加密方式来保护数据:

传输级别加密,例如从 Azure 存储传入或传出数据时使用的 HTTPS 。

线路加密,例如 Azure 文件共享的 SMB 3.0 加密。

客户端加密,在将数据传输到存储之前加密数据,以及从存储传出数据后解密数据。

静 态 加密
对许多组织而言,静态数据加密是实现数据隐私性、符合性和数据所有权的必要措施。 有三项 Azure 存储安全功
能可提供“静态”数据加密:

存储服务加密可以请求存储服务在将数据写入 Azure 存储时自动加密数据。

客户端加密 也提供静态加密功能。

Azure 磁盘加密 允许加密 IaaS 虚拟机使用的 OS 磁盘和数据磁盘。


存 储 分析
Azure 存储分析执行日志记录并为存储帐户提供指标数据。 可以使用此数据为存储帐户跟踪请求、分析使用趋势
和诊断问题。 存储分析记录成功和失败的存储服务请求的详细信息。 可以使用该信息监视各个请求和诊断存储
服务问题。 将最大程度地记录请求。 将记录以下类型的经过身份验证的请求:
成功的请求。

失败的请求,包括超时、限制、网络、授权和其他错误。

使用共享访问签名 (SAS) 的请求,包括失败和成功的请求。

分析数据的请求。

使用CORS 启用基于 浏览 器的客 户 端


跨源资源共享 (CORS) 是一种允许域授予彼此资源访问权限的机制。 用户代理发送额外的标头,以确保允许从特
定域中加载的 JavaScript 代码访问位于另一个域的资源。 然后,后一个域使用额外标头进行回复,允许或拒绝原
始域访问其资源。

Azure 存储服务现支持 CORS ,因此,为服务设置 CORS 规则后,便会对从另一个域对服务发出的经过正确验证


的请求进行评估,以根据指定的规则确定是否允许该请求。

网络
本部分提供了关于 Azure 网络安全中主要特性的其他信息以及有关这些功能的摘要信息。

网 络层 控制
网络访问控制是限制特定设备或子网之间的连接的行为,代表了网络安全的核心。 网络访问控制的目标是确保
只有有权限的用户和设备才能访问虚拟机和服务。

网 络 安全 组

网络安全组 (NSG) 是基本的静态数据包筛选防火墙,使用户能够基于 5 元组控制访问权限。 NSG 不提供应用程


序层检查或经过身份验证的访问控制。 它们可用于控制在 Azure 虚拟网络中的子网之间移动的流量以及控制
Azure 虚拟网络和 Internet 之间的流量。
路由控制和 强 制隧道

控制 Azure 虚拟网络上的路由行为是关键的网络安全和访问控制功能。 例如,如果要确保与 Azure 虚拟网络之


间的所有流量都通过该虚拟安全设备,则必须能够控制和自定义路由行为。 可以通过在 Azure 中配置用户定义
的路由实现此操作。

用户定义的路由允许用户为进出单个虚拟机或子网的流量自定义入站和出站路径,以确保最安全的路由。 强制
隧道 是一种机制,可用于确保不允许服务发起与 Internet 上设备的连接。

这不同于能够接受传入连接然后对其作出响应。 前端 Web 服务器需要响应来自 Internet 主机的请求,因此允许


源自 Internet 的流量传入到这些 Web 服务器,而且这些 Web 服务器可以作出响应。

强制隧道通常用于强制到 Internet 的外部流量通过本地安全代理和防火墙。

虚 拟 网 络 安全 设备

虽然网络安全组、用户定义的路由和强制隧道在 OSI 模型的网络层和传输层为用户提供了一定程度的安全性,但


有时可能想要启用堆栈的更高级别安全性。 可以使用 Azure 合作伙伴安全设备解决方案访问这些增强的网络安
全功能。 通过访问 Azure 市场并搜索“安全”和“网络安全”,可以找到最新的 Azure 合作伙伴网络安全解决方案。

Azure 虚 拟 网 络
Azure 虚拟网络 (VNet) 是你自己的网络在云中的表示形式。 它是对专用于订阅的 Azure 网络结构进行的逻辑隔
离。 可以完全控制该网络中的 IP 地址块、DNS 设置、安全策略和路由表。 可以将 VNet 细分成各个子网,并在
Azure 虚拟网络上放置 Azure IaaS 虚拟机 (VM) 和/或云服务(PaaS 角色实例)。
此外,还可以使用 Azure 中提供的连接选项 之一将虚拟网络连接到本地网络。 实际上,可以将网络扩展到
Azure,对 IP 地址块进行完全的控制,并享受企业级 Azure 带来的好处。
Azure 网络支持各种安全远程访问方案。 其中包括:
将单独的工作站连接到 Azure 虚拟网络
通过 VPN 将本地网络连接到 Azure 虚拟网络

通过专用 WAN 链接将本地网络连接到 Azure 虚拟网络

相互连接 Azure 虚拟网络

VPN 网关
若要在 Azure 虚拟网络与本地站点之间发送网络流量,必须为 Azure 虚拟网络创建 VPN 网关。 VPN 网关是一种
虚拟网络网关,可以通过公共连接发送加密流量。 也可以使用 VPN 网关在基于 Azure 网络结构的 Azure 虚拟网
络之间发送流量。

Express Route
Microsoft Azure ExpressRoute 是专用 WAN 链接,可让用户通过连接服务提供商所提供的专用连接,将本地网络
扩展到 Microsoft 云。

使用 ExpressRoute 可与 Microsoft Azure、Microsoft 365 和 CRM Online 等 Microsoft 云服务建立连接。 可以从


任意位置之间的 (IP VPN) 网络、点到点以太网或在共置设施上通过连接服务提供商的虚拟交叉连接来建立这种
连接。

ExpressRoute 连接不会通过公共 Internet,因此可以认为它比基于 VPN 的解决方案更安全。 与通过 Internet 的


典型连接相比,ExpressRoute 连接提供更高的可靠性、更快的速度、更低的延迟和更高的安全性。

应 用程序网关
Microsoft Azure 应用程序网关以服务形式提供应用程序传送控制器 (ADC),借此为应用程序提供第 7 层各种负
载均衡功能。
它使用户能够通过将 CPU 密集型 TLS 终止卸载到应用程序网关(也称为“TLS 卸载”或“TLS 桥接”)来优化 Web 场
生产率。 它还提供第 7 层其他路由功能,包括传入流量的轮循机制分配、基于 Cookie 的会话相关性、基于 URL
路径的路由,以及在单个应用程序网关后面托管多个网站的能力。 Azure 应用程序网关是第 7 层负载均衡器。

它在不同服务器之间提供故障转移和性能路由 HTTP 请求,而不管它们是在云中还是本地。

应用程序提供许多应用程序传送控制器 (ADC) 功能,包括 HTTP 负载均衡、基于 cookie 的会话相关性、TLS 卸


载、自定义运行状况探测、多站点支持,以及许多其他功能。

Web 应 用程序防火 墙
Web 应用程序防火墙是 Azure 应用程序网关的一项功能,它为使用应用程序网关实现标准应用程序传递控制
(ADC) 功能的 Web 应用程序提供保护。 Web 应用程序防火墙的此功能可以保护 Web 应用程序免受 OWASP 十
大常见 Web 漏洞中的大部分漏洞的威胁。

SQL 注入保护
常见 Web 攻击保护,例如命令注入、HTTP 请求走私、HTTP 响应拆分和远程文件包含攻击

防止 HTTP 协议违反行为
防止 HTTP 协议异常行为,例如缺少主机用户代理和接受标头

防止自动程序、爬网程序和扫描程序

检测常见应用程序错误配置(即 Apache、IIS 等)

集中式 Web 应用程序防火墙可以防止 Web 攻击,简化安全管理,并可针对入侵威胁为应用程序提供更好的保


障。 相较保护每个单独的 Web 应用程序,WAF 解决方案还可通过在中央位置修补已知漏洞,更快地响应安全威
胁。 现有应用程序网关可以轻松地转换为带 Web 应用程序防火墙的应用程序网关。

流量管理器
使用 Microsoft Azure 流量管理器,可以控制用户流量在不同数据中心内的服务终结点上的分布。 流量管理器支
持的服务终结点包括 Azure VM、Web 应用和云服务。 也可将流量管理器用于外部的非 Azure 终结点。 流量管理
器根据流量路由方法和终结点的运行状况,使用域名系统 (DNS) 将客户端请求定向到最合适的终结点。

流量管理器提供多种流量路由方法来满足不同的应用程序需求、终结点运行状况监视和自动故障转移。 流量管
理器能够灵活应对故障,包括整个 Azure 区域的故障。

Azure 负载 均衡器
Azure 负载均衡器可提高应用程序的可用性和网络性能。 它是第 4 层(TCP、UDP)类型的负载均衡器,可在负载
均衡集中定义的运行状况良好的服务实例之间分配传入流量。 可以将 Azure 负载均衡器配置为:

对传入到虚拟机的 Internet 流量进行负载均衡。 此配置称为公共负载均衡。

对虚拟网络中虚拟机之间的流量、云服务中虚拟机之间的流量或本地计算机和跨界虚拟网络中虚拟机之
间的流量进行负载均衡。 此配置称为 负载均衡。

将外部流量转发到特定的虚拟机

内部 DNS
可以在管理门户或网络配置文件中管理 VNet 中使用的 DNS 服务器列表。 客户最多可以为每个 VNet 添加 12 个
DNS 服务器。 指定 DNS 服务器时,请务必按照客户环境的正确顺序列出客户的 DNS 服务器。 DNS 服务器列表
不采用循环机制。 将按指定服务器的顺序使用这些服务器。 如果可访问列表上的第一个 DNS 服务器,则无论该
DNS 服务器是否运行正常,客户端都将使用该服务器。 要更改客户的虚拟网络的 DNS 服务器顺序,请从列表中
删除 DNS 服务器,并按客户希望的顺序重新添加这些服务器。 DNS 支持“CIA”安全三因素的可用性方面。

Azure DNS
域名系统或 DNS 负责将网站或服务名称转换(或解析)为它的 IP 地址。 Azure DNS 是 DNS 域的托管服务,它使
用 Microsoft Azure 基础结构提供名称解析。 通过在 Azure 中托管域,可以使用与其他 Azure 服务相同的凭据、
API、工具和计费来管理 DNS 记录。 DNS 支持“CIA”安全三因素的可用性方面。
Azure Monitor 日志 NSG
可以为 NSG 启用以下诊断日志类别:

事件:包含根据 MAC 地址向 VM 和实例角色应用的 NSG 规则条目。 每隔 60 秒收集一次这些规则的状


态。

规则计数器:包含应用每个 NSG 规则以拒绝或允许流量的次数的条目。

安全中心
Azure 安全中心不断分析 Azure 资源的安全状态,以实现网络安全最佳做法。 在安全中心识别出潜在的安全漏洞
时,它会创建一些“建议”,指导完成配置所需控件以强化和保护资源的过程。

计算
本部分提供了关于此区域中主要特性的其他信息以及有关这些功能的摘要信息。

反 恶 意 软 件和防病毒 软 件
借助 Azure IaaS ,可以使用来自 Microsoft、Symantec、Trend Micro、McAfee 和 Kaspersky 等安全性供应商的反
恶意软件,以保护虚拟机免受恶意文件、广告软件和其他威胁的侵害。 适用于 Azure 云服务和虚拟机的
Microsoft 反恶意软件是一种保护功能,可帮助识别并删除病毒、间谍软件和其他恶意软件。 当已知恶意软件或
不需要的软件试图在 Azure 系统上安装自身或运行时,Microsoft 反恶意软件将提供可配置的警报。 此外可以使
用 Azure 安全中心部署 Microsoft 反恶意软件

硬件安全模 块
加密和身份验证无法提高安全性,除非密钥本身也受到保护。 通过将关键密码和密钥存储在 Azure Key Vault
中,可以简化此类密码和密钥的管理和保护。 Key Vault 可将用户密钥存储在已通过 FIPS 140-2 Level 2 标准认证
的硬件安全模块 (HSM) 中。 用于备份或 透明数据加密 的 SQL Server 加密密钥可以存储在密钥保管库中,此外
还可存储应用程序中的任意密钥或机密。 对这些受保护项的权限和访问权限通过 Azure Active Directory进行管
理。

虚拟机备份
Azure 备份是一种解决方案,无需资本投资便可保护应用程序数据,最大限度降低运营成本。 应用程序错误可能
损坏数据,人为错误可能将 bug 引入应用程序,从而导致安全问题。 使用 Azure 备份可以保护运行 Windows 和
Linux 的虚拟机。
Azure Site Recovery
组织的业务连续性/灾难恢复 (BCDR) 策略的其中一个重要部分是,找出在发生计划内和计划外的中断时让企业
工作负荷和应用保持启动并运行的方法。 Azure Site Recovery 可帮助协调工作负荷和应用的复制、故障转移及
恢复,因此能够在主要位置发生故障时通过辅助位置来提供工作负荷和应用。

SQL VM TDE
SQL Server 加密功能包括透明数据加密 (TDE)和列级加密 (CLE)。 这种加密形式要求客户管理和存储用于加密的
加密密钥。

Azure Key Vault (AKV) 服务专用于在一个高度可用的安全位置改进这些密钥的安全性和管理。 SQL Server 连接


器使 SQL Server 能够使用 Azure Key Vault 中的这些密钥。

如果在本地计算机上运行 SQL Server ,请按照此处步骤通过本地 SQL Server 实例访问 Azure Key Vault。 但对于
Azure VM 中的 SQL Server,可以使用 Azure Key Vault 集成功能节省时间。 通过使用几个 Azure PowerShell
cmdlet 来启用此功能,可以自动为 SQL VM 进行必要的配置以便访问密钥保管库。
VM 磁 盘 加密
Azure 磁盘加密是用于加密 Windows 和 Linux IaaS 虚拟机磁盘的新功能。 它应用 Windows 的行业标准
BitLocker 功能和 Linux 的 DM-Crypt 功能,为 OS 和数据磁盘提供卷加密。 该解决方案与 Azure Key Vault 集成,
帮助用户控制和管理 Key Vault 订阅中的磁盘加密密钥和机密。 此解决方案还可确保虚拟机磁盘上的所有数据在
Azure 存储中静态加密。
虚拟网络
虚拟机需要网络连接。 为了满足该要求,Azure 需要虚拟机连接到 Azure 虚拟网络。 Azure 虚拟网络是构建在物
理 Azure 网络结构基础之上的逻辑构造。 每个逻辑 Azure 虚拟网络都独立于所有其他 Azure 虚拟网络。 这种隔
离有助于确保其他 Microsoft Azure 客户无法访问部署中的网络流量。

修 补 程序更新
修补程序更新可以减少必须在企业中部署的软件更新数目并提高监视符合性的能力,从而提供查找及修复潜在
问题的基础并简化软件更新管理过程。

安全策略管理和 报 告
安全中心有助于预防、检测和响应威胁,同时提高对 Azure 资源安全的可见性和可控性。 它提供对 Azure 订阅的
集成安全监视和策略管理,帮助检测可能被忽略的威胁,且适用于广泛的安全解决方案生态系统。

标识和访问管理
保护系统、应用程序和以基于标识的访问控制开始的数据。 Microsoft 企业产品和服务内置的标识和访问管理功
能有助于保护组织和个人信息免受未经授权的访问,同时向合法用户提供随时随地访问权限。

安全 标识
Microsoft 在其产品和服务中使用多种安全实践和技术来管理标识和访问权限。
多重身份验证要求用户在本地和云中使用多种方法进行访问。 它提供强大的身份验证和一系列简单的验
证选项,同时满足用户对简单登录过程的需求。

Microsoft Authenticator 提供了一种用户友好型多重身份验证体验,它可与 Microsoft Azure Active


Directory 和 Microsoft 帐户兼容,并支持可穿戴设备和基于指纹的批准。
强制实施密码策略通过强制执行长度和复杂性要求、强制定期轮换和身份验证尝试失败后的帐户锁定来
提高传统密码的安全性。

基于令牌的身份验证启用通过 Azure Active Directory 进行身份验证。

Azure 基于角色的访问控制 (Azure RBAC) 能够根据用户分配的角色来授予访问权限,从而轻松为用户仅


提供执行作业所需的访问量。 你可以根据组织的业务模型自定义 Azure RBAC 并降低风险。

集成标识管理(混合标识)能够保持对用户在内部数据中心和云平台中的访问控制,并为所有资源的身份
验证和授权创建单个用户标识。

保 护应 用和数据
Azure Active Directory 是综合性的标识和访问管理云解决方案,可帮助确保安全访问站点和云中的应用程序数
据,并简化对用户和组的管理。 它结合了核心目录服务、高级 Identity Governance、安全性以及应用程序访问管
理,使开发人员可以轻松在其应用中构建基于策略的标识管理。 若要增强 Azure Active Directory,可以使用
Azure Active Directory 基本版、Premium P1 版和 Premium P2 版添加付费功能。

A Z URE A C T IVE
DIREC TO RY JO IN –
/ P1 P2 W IN DO W S 10

目录对象, 用户/组管 基于组的访问管理/预 自助组和应用管理/自 标识保护, Privileged 将设备加入到 Azure


理 (添加/更新/删除) / 配, 云用户的自助服 助应用程序添加件/动 Identity AD,桌面
基于用户的预配、设 务密码重置, 公司品 态组, 自助密码重置/ Management SSO,Microsoft
备注册、 单一 Sign- 牌 (登录页/访问面板 更改/解锁,具有本地 Passport 用于 Azure
On (SSO) 、 云用户的 自定义) , 应用程序 写回、 多重身份验证 AD,管理员 BitLocker
自助密码更改、 连接 代理, SLA 99.9% (云和本地 (MFA 恢复, MDM 自动注
(同步引擎,可将本地 server) # B3 , MIM 册,Self-Service
目录扩展到 Azure CAL + Mim server, BitLocker 恢复,通过
Active Directory) 、 Cloud App Azure AD Join 附加到
安全/使用情况报告 Discovery, 连接运行 Windows 10 设备的
状况, 组帐户的自动 其他本地管理员
密码滚动更新

Cloud App Discovery 是 Azure Active Directory 的一项高级功能,能够识别组织中的人员所使用的云应用


程序。

Azure Active Directory 标识保护是一种安全服务,它使用 Azure Active Directory 异常检测功能对风险检


测和可能影响组织标识的潜在漏洞提供综合视图。

Azure Active Directory 域服务让用户可以将 Active VM 加入一个域,且无需部署域控制器。 用户可使用他


们的企业 Active Directory 凭证登录这些 VM,且可以无缝访问资源。

Azure Active Directory B2C 是一个高度可用的全局性标识管理服务,该服务适用于面向用户且可通过伸


缩来处理数以亿计标识的应用程序,并可跨移动平台和 Web 平台集成。 客户可以通过使用现有社交媒体
帐户的自定义体验登录所有应用,也可以创建新的独立凭据。

Azure Active Directory B2B 协作是一种安全的合作伙伴集成解决方案,可让合作伙伴使用其自行管理的


标识有选择性地访问企业应用程序和数据,为跨公司合作关系提供支持。

Azure Active Directory Join 可以将云功能扩展到 Windows 10 设备进行集中管理。 它使用户可以通过


Azure Active Directory 连接到企业或组织云,并简化对应用和资源的访问。
Azure Active Directory 应用程序代理为本地托管的 Web 应用程序提供 SSO 和安全远程访问。

后续步骤
了解云中责任分担。

了解 Azure 安全中心如何有助于预防、检测和应对威胁,同时提高了 Azure 资源安全性的可见性和可控


性。
云中责任分担
2021/2/9 • • Edit Online

当你考虑和评估公有云服务时,必须了解共担责任模型、由云服务提供商处理的安全任务以及由你处理的任务。
工作负荷责任因各种因素而异,具体取决于工作负荷是托管在软件即服务 (SaaS) 上、平台即服务 (PaaS) 上、基
础结构即服务 (IaaS) 上还是托管在本地数据中心

责任划分
在本地数据中心,你拥有整个堆栈。 当你迁移到云时,某些责任将转移到 Microsoft。 下图说明了你和 Microsoft
之间的责任区域,具体取决于你的堆栈的部署类型。

对于所有云部署类型,拥有数据和标识。 需要负责保护由你控制的数据和标识、本地资源及云组件的安全(保护
的项目因服务类型而异)。

无论部署类型如何,你始终要承担以下责任:

数据
终结点
帐户
访问管理

云的安全优势
云在解决长期存在的信息安全难题方面具有显著优势。 在本地环境中,组织的可用资源可能有限,无法尽责在安
全措施上投资,使得攻击者能够利用所有层中的漏洞。

下图显示了一种传统方法,其中的许多安全责任由于资源有限而无法履行。 在启用云的方法中,你可以将日常安
全责任转移到云服务提供商,并重新分配资源。
在启用云的方法中,你还可以利用基于云的安全功能来提高效率,并使用云智能来缩短威胁检测和响应时间。 通
过将责任转移到云提供商,组织可以扩大安全覆盖范围,为其他优先业务重新调配安全资源与预算。

后续步骤
若要详细了解你和 Microsoft 在 SaaS 、PaaS 和 IaaS 部署中的责任划分,请参阅云计算的共担责任。
Azure 安全技术功能
2021/2/9 • • Edit Online

本文介绍了 Azure 中的安全服务,这些服务可帮助保护云中的数据、资源和应用程序,并满足业务的安全需求。

Azure 平台
Microsoft Azure 是托管于 Microsoft 公有云数据中心的云平台,由基础结构和应用程序服务组成,并且集成了数
据服务、高级分析以及开发人员工具和服务。 客户可将 Azure 用于许多不同的容量和方案,从基本计算、网络和
存储,到移动和 Web 应用服务,再到物联网等完整云方案,并且可将 Azure 与开源技术配合使用,作为混合云进
行部署或托管在客户的数据中心内。 Azure 以构建基块的形式提供云技术,帮助公司节省成本、快速创新和主动
管理系统。 构建 IT 资产或将其迁移到云提供商处时,需要借助该组织的能力来保护应用程序和数据,并使用该
组织提供的服务和控件来管理基于云的资产的安全性。

Microsoft Azure 是唯一一个提供安全一致的应用程序平台和服务架构的云计算提供商,让团队可以使用各种云


技能组合应对各种级别的项目复杂性;它集成了数据服务和分析,可以跨 Microsoft 和非 Microsoft 平台、开放框
架和工具,从现有数据中挖掘信息;它允许用户选择是将云与本地集成,还是在本地数据中心部署 Azure 云服
务。 作为 Microsoft 受信任云的一部分,客户可依赖 Azure 行业领先的安全性、可靠性、合规性、隐私以及庞大的
人员、合作伙伴和流程网络,为云中的组织提供支持。

借助 Microsoft Azure,可以:

通过云加快创新。

深入了解业务决策和应用。

随时生成,随地部署。

保护业务。

利用安全技术功能来履行责任
Microsoft Azure 提供的服务可帮助你满足安全、隐私和合规性需求。 下图有助于阐释各种不同的 Azure 服务,这
些服务可用于按照行业标准来构建安全合规的应用程序基础结构。
管理和控制标识与用户访问
可使用 Azure 管理用户标识和凭据以及控制访问,帮助保护企业信息和个人信息。

Azure Active Directory


Microsoft 标识和访问管理解决方案支持更多的验证级别(如多重身份验证和条件访问策略),可帮助 IT 部门保护
对企业数据中心和云中的应用程序和资源的访问。 通过高级安全报告、审核和警报来监视可疑活动,有助于减少
潜在的安全问题。 Azure Active Directory Premium 可为数千种云应用提供单一登录,并提供对你在本地运行的
Web 应用的访问。
Azure Active Directory (Azure AD) 在安全方面的益处包括以下能力:
为混合企业中的每个用户创建和管理单一标识,从而使用户、组和设备保持同步。

提供对应用程序(包括数千个预先集成的 SaaS 应用)的单一登录访问。

通过对本地应用程序和云应用程序实施基于规则的多重身份验证,启用应用程序访问安全措施。

通过 Azure AD 应用程序代理预配对本地 Web 应用程序的安全远程访问。

Azure Active Directory 门户作为 Azure 门户的一部分提供。 在此仪表板中,你可以大致了解你的组织的状态,并


轻松管理目录、用户或应用程序访问。

以下是核心的 Azure 标识管理功能:

单一登录

多重身份验证

安全监控、警报和基于机器学习的报告

消费者标识和访问管理

设备注册

Privileged identity management


标识保护
单 一登 录

单一登录 (SSO) 是指只需使用单个用户帐户登录一次,就能访问开展业务所需的全部应用程序和资源。 登录之


后,用户可以访问所需的全部应用程序,而无需再次进行身份验证(例如键入密码)。

许多组织依赖于软件即服务 (SaaS) 应用程序(如 Microsoft 365 、Box 和 Salesforce)来提高最终用户生产力。 从


历史上看,IT 人员需要在每个 SaaS 应用程序中单独创建和更新用户帐户,而用户需要记住每个 SaaS 应用程序
的密码。

Azure AD 将本地 Active Directory 扩展到云中,使用户能够使用其主组织帐户不仅登录到已加入域的设备和公司


资源,而且还支持其工作所需的所有 Web 和 SaaS 应用程序。

优势是不仅用户无需管理多组用户名和密码,而且还可根据组织组以及其身为员工的状态,自动预配或取消预配
应用程序的访问权限。 Azure AD 引入了安全和访问管理控件,支持跨 SaaS 应用程序集中管理用户的访问权限。

多重身份 验证

Azure AD 多重身份验证 (MFA) 是需要使用多种验证方法的身份验证方法,为用户登录和事务又增加了一层至关


重要的安全保障。 MFA 可帮助保护对数据和应用程序的访问,同时满足用户对简单登录过程的需求。 它通过各
种验证选项(例如电话、短信、移动应用通知或验证码和第三方 OAuth 令牌)来提供强身份验证。

安全 监 控、 警 报 和基于机器学 习 的 报 告

安全监控、警报和基于机器学习的报告(它们识别不一致的访问模式)可以帮助保护业务。 可以使用 Azure Active


Directory 的访问和使用情况报告来监控你所在组织的目录的完整性和安全性。 使用此信息,目录管理员可以更
好地确定哪里可能存在安全风险,以便制定相应的计划来降低风险。

在 Azure 门户或 Azure Active Directory 门户中,报告按以下方式分类:

异常报告 - 包含我们发现存在异常的登录事件。 我们的目标是让用户知道这类活动并使用户能够就事件


是否可疑做出决定。

集成应用程序报告-提供有关如何在组织中使用云应用程序的信息。 Azure Active Directory 提供与数千个


云应用程序的集成。

错误报告 - 指示在为外部应用程序预配帐户时可能发生的错误。

用户特定的报告-显示特定用户的设备和登录活动数据。

活动日志 - 包含过去 24 小时、过去 7 天或过去 30 天内的所有已审核事件的记录,以及组活动更改记录、


密码重置和注册活动记录。

消 费 者 标识 和 访问 管理

Azure Active Directory B2C 是一个高度可用的全局性标识管理服务,该服务适用于面向用户且可通过缩放来处


理数以亿计标识的应用程序。 它可以跨移动平台和 Web 平台进行集成。 用户只需使用现有社交帐户或创建新凭
据,即可通过可自定义的体验登录到所有应用程序。

过去,想要在自己的应用程序中注册用户并使用户登录的应用程序开发人员会编写自己的代码。 他们使用本地
数据库或系统存储用户名和密码。 Azure Active Directory B2C 通过基于标准的安全平台和大量的可扩展策略,
向组织提供一种更好的方式将用户标识管理集成到应用程序中。

使用 Azure Active Directory B2C 时,用户可通过使用他们现有的社交帐户(Facebook、Google、Amazon、


LinkedIn)或创建新的凭据(电子邮件地址和密码,或者用户名和密码)在应用程序中注册。
设备 注册

Azure AD 设备注册 是基于设备的 条件性访问 方案的基础。 在注册设备时,Azure AD 设备注册会为设备提供一


个标识,此标识用于在用户登录时对设备进行身份验证。 然后,可以使用经过身份验证的设备和设备的属性,对
云中和本地托管的应用程序实施条件性访问策略。

当与 Intune 之类的移动设备管理 (MDM) 解决方案结合使用时,Azure Active Directory 中的设备属性会使用关于


设备的更多信息进行更新。 这允许你创建条件性访问规则,以根据你的安全性和符合性标准强制从设备进行访
问。
Privileged identity management
利用 Azure Active Directory (AD) Privileged Identity Management,可以管理、控制和监视特权标识以及对 Azure
AD 中和 Microsoft 365 或 Microsoft Intune 等其他 Microsoft Online Services 中资源的访问。
用户有时候需要在 Azure 或 Microsoft 365 资源或者其他 SaaS 应用中执行特权操作。 这通常意味着,组织必须
授予他们永久的 Azure AD 访问特权。 这会给云中托管的资源不断增大安全风险,因为组织无法充分监视这些用
户正在使用管理特权执行哪些操作。 此外,如果有访问特权的用户帐户被泄露,这个缺口可能会影响其总体云安
全性。 Azure AD 特权标识管理可帮助解决这一风险。

利用 Azure AD Privileged Identity Management,可以:

查看哪些用户是 Azure AD 管理员

按需启用对 Microsoft 365 和 Intune 等 Microsoft Online Services 的“实时”管理访问权限

获取有关管理员访问历史记录以及管理员分配更改的报告

获取有关访问特权角色的警报

标识 保 护

Azure AD Identity Protection 是一种安全服务,可提供对风险检测和潜在漏洞(影响组织标识)的合并视图。 标识


保护使用现有 Azure Active Directory 的异常检测功能 (可通过 Azure AD 的异常活动报告) ,并引入了新的风险
检测类型,这些类型可以实时检测异常。

保护资源访问
Azure 中的访问控制首先体现在计费方面。 Azure 帐户的所有者(可通过访问 Azure 帐户中心进行访问)是帐户管
理员 (AA)。 订阅是计费容器,但它们也可充当安全边界:每个订阅都有一个服务管理员 (SA),此管理员可以使用
Azure 门户在该订阅中添加、删除和修改 Azure 资源。 新订阅的默认 SA 是 AA,但 AA 可以在 Azure 帐户中心更
改 SA。

订阅也与目录相关联。 目录定义一组用户。 这些用户可以是创建该目录的公司或学校的用户,也可以是外部用


户(即 Microsoft 帐户)。 订阅可由这些已被指定为服务管理员 (SA) 或共同管理员 (CA) 的目录用户的子集来访
问;唯一的例外是,为了保持向后兼容,可以将 Microsoft 帐户(以前称为 Windows Live ID)指定为 SA 或 CA,而
这些帐户不必存在于目录中。

面向安全的公司应侧重于向员工提供他们所需的确切权限。 权限过多,可能会向攻击者公开帐户。 权限太少,员


工无法有效完成工作。 Azure 基于角色的访问控制 (Azure RBAC) 通过为 Azure 提供精细的访问权限管理来帮助
解决此问题。
使用 Azure RBAC,可以在团队中实现职责分离,仅向用户授予他们执行作业所需的访问权限。 而不是向每个人
提供对 Azure 订阅或资源的无限权限,可以仅允许某些操作。 例如,使用 Azure RBAC 允许一个员工管理订阅中
的虚拟机,而另一个员工可以管理同一订阅中的 SQL 数据库。

数据安全与加密
在云中保护数据的关键问题之一是考虑数据可能将发生的状态,以及哪些控件适用于该状态。 根据 Azure 数据
安全与加密最佳实践,将针对以下数据状态提供建议。

静态:包括物理媒体(磁盘或光盘)上以静态方式存在的所有信息存储对象、容器和类型。
传输中:数据在组件、位置或程序之间发送时,例如通过网络、通过服务总线(从本地到云,反之亦然,包括诸
如 ExpressRoute 的混合连接),或在输入/输出过程中,会被视为动态数据。

静 态 加密
Azure 数据静态加密中详细讨论了静态加密。
传输 中加密
保护传输中的数据应该是数据保护策略中不可或缺的部分。 由于数据将从许多位置来回移动,一般建议始终使
用 SSL/TLS 协议来交换不同位置的数据。 在某些情况下,建议使用虚拟专用网络 (VPN) 隔离本地与云基础结构
之间的整个通信通道。
对于在本地基础结构与 Azure 之间移动的数据,应该考虑适当的防护措施,例如 HTTPS 或 VPN。

对于需要从位于本地的多个工作站安全访问 Azure 的组织而言,请使用 Azure 站点到站点 VPN。

对于需要从位于本地的一个工作站安全访问 Azure 的组织而言,请使用点到站点 VPN。

可以通过专用高速 WAN 链路(例如 ExpressRoute)移动较大的数据集。 如果选择使用 ExpressRoute,则还可以使


用 SSL/TLS 或其他协议,在应用程序级别加密数据,以提供额外的保护。

如果通过 Azure 门户与 Azure 存储交互,则所有事务都将通过 HTTPS 发生。 也可以使用基于 HTTPS 的存储
REST API 来与 Azure 存储和 Azure SQL 数据库交互。
无法保护传输中数据的组织更容易遭受中间人攻击、窃听和会话劫持。 这些攻击可能是获取机密数据访问权限
的第一步。

有关 Azure VPN 选项的详细信息,请阅读规划和设计 VPN 网关一文。

实 施文件 级 数据加密
Azure RMS 使用加密、标识和授权策略帮助保护文件与电子邮件。 Azure RMS 可跨多个设备工作 — 手机、平板
电脑和台式电脑保护组织内部和外部的数据。 因为 Azure RMS 添加了数据所属的保护级别,所以即使数据离开
组织边界,此功能仍然可行。

使用 Azure RMS 保护文件时,意味着使用行业标准加密并配合 FIPS 140-2 的完全支持。 使用 Azure RMS 进行


数据保护时,即使文件被复制到不受 IT 控制的存储(例如云存储服务),也可保证该文件持续受到保护。 同样的
情况将出现在通过电子邮件共享的文件,文件以电子邮件的附件形式受到保护,并提供如何打开受保护附件的说
明。 规划 Azure RMS 采用时,建议执行以下操作:

安装 RMS 共享应用。 此应用通过安装 Office 外挂程序来与 Office 应用程序集成,使用户可以轻松地直接


保护文件。

配置应用程序和服务以支持 Azure RMS

创建可反映业务要求的自定义模板。 例如:最高机密数据的模板应在所有最高机密相关的电子邮件中应
用。

数据分类和文件保护能力不佳的组织可能更容易遭到数据泄漏。 没有适当的文件保护,组织将无法获取业务见
解、监控滥用,以及防止文件被恶意访问。

NOTE
有关 Azure RMS 的详细信息,请阅读 Getting Started with Azure Rights Management(Azure Rights Management 入门)一
文。

保护应用程序
Azure 负责保护运行应用程序的基础结构和平台,而你负责保护应用程序本身。 换而言之,需要以安全方式开
发、部署和管理应用程序代码和内容。 无此安全性,应用程序代码或内容仍然容易受到威胁。

Web 应 用程序防火 墙
Web 应用程序防火墙 (WAF) 是应用程序网关的功能,可以对 Web 应用程序进行集中保护,避免其受到常见的攻
击和漏洞危害。

Web 应用程序防火墙基于 OWASP 核心规则集 3.0 或 2.2.9 中的规则。 Web 应用程序已逐渐成为利用常见已知


漏洞的恶意攻击的目标。 这些攻击中最常见的攻击包括 SQL 注入攻击、跨站点脚本攻击等。 防止应用程序代码
遭受此类攻击颇具挑战性,并且可能需要对应用程序拓扑的多个层进行严格的维护、修补和监视。 集中式 Web
应用程序防火墙有助于大幅简化安全管理,为抵卸威胁或入侵的应用程序管理员提供更好的保障。 相较保护每
个单独的 Web 应用程序,WAF 解决方案还可通过在中央位置修补已知漏洞,更快地响应安全威胁。 可将现有应
用程序网关轻松转换为支持 Web 应用程序防火墙的应用程序网关。

Web 应用程序防火墙防范的某些常见 Web 安全漏洞包括:


SQL 注入保护
跨站点脚本保护

常见 Web 攻击保护,例如命令注入、HTTP 请求走私、HTTP 响应拆分和远程文件包含攻击

防止 HTTP 协议违反行为

防止 HTTP 协议异常行为,例如缺少主机用户代理和接受标头

防止自动程序、爬网程序和扫描程序

检测常见应用程序错误配置(即 Apache、IIS 等)

NOTE
有关规则及其保护措施的更详细的列表,请参阅下面的核心规则集:

Azure 还提供多种易用的功能,帮助保护应用的入站和出站流量。 此外,Azure 还提供外部来源的功能来扫描


Web 应用程序的漏洞,帮助客户保护其应用程序代码。
为应用设置 Azure Active Directory 身份验证

启用传输层安全性 (TLS/SSL) - HTTPS 保护应用流量安全

强制所有传入流量通过 HTTPS 连接

启用严格传输安全性 (HSTS)

按客户端 IP 地址限制应用访问

按客户端行为(请求频率和并发)限制应用访问

使用 Tinfoil 安全性扫描对 Web 应用代码进行扫描以确定是否存在漏洞

配置 TLS 相互身份验证来要求将客户端证书连接到 Web 应用

配置从应用中使用的客户端证书以安全连接到外部资源

删除标准服务器标头以避免工具对应用进行指纹识别

使用点到站点 VPN 安全连接应用与专用网络资源

使用混合连接安全连接应用与专用网络资源

Azure 应用服务所使用的反恶意软件解决方案与 Azure 云服务和虚拟机使用的相同。 若要了解此方面的详细信


息,请参阅反恶意软件文档。

保护网络
Microsoft Azure 包括可靠的网络基础结构以支持应用程序和服务连接要求。 Azure 中的资源之间、本地资源与
Azure 托管的资源之间以及 Internet 与 Azure 之间都可能存在网络连接。
利用 Azure 网络基础结构,可以安全地将 Azure 资源通过虚拟网络 (VNet) 相互连接。 VNet 是自己的网络在云中
的表示形式。 VNet 是对专用于订阅的 Azure 云网络进行的逻辑隔离。 可将 VNet 连接到本地网络。
如果需要基本的网络级别访问控制(基于 IP 地址和 TCP 或 UDP 协议),则可以使用网络安全组。 网络安全组
(NSG) 是基本的静态数据包筛选防火墙,使用户能够基于 5 元组控制访问权限。
Azure 网络支持在 Azure 虚拟网络上为网络流量自定义路由行为的功能。 可以通过在 Azure 中配置用户定义路
由实现此操作。

强制隧道 是一种机制,可用于确保不允许服务发起与 Internet 上设备的连接。

Azure 支持通过 ExpressRoute 使用专用 WAN 链路连接本地网络和 Azure 虚拟网络。 Azure 和站点之间的链接使
用专用连接,不需要通过公共 Internet。 如果 Azure 应用程序在多个数据中心运行,则可以使用 Azure 流量管理
器智能地跨应用程序实例路由来自用户的请求。 如果可以通过 Internet 访问未在 Azure 中运行的服务,还可以
将流量路由到这些服务。

虚拟机安全
借助 Azure 虚拟机,可以采用灵活的方式部署各种计算解决方案。 通过对 Microsoft Windows、Linux、Microsoft
SQL Server、Oracle、IBM、SAP 和 Azure BizTalk 服务的支持,可以在几乎所有操作系统上部署任何工作负荷和任
何语言。

借助 Azure,可以使用来自 Microsoft、Symantec、Trend Micro 和 Kaspersky 等安全性供应商的反恶意软件,保护


虚拟机免受恶意文件、广告软件和其他威胁的侵害。

适用于 Azure 云服务和虚拟机的 Microsoft 反恶意软件是一种实时保护功能,可帮助识别并移除病毒、间谍软件


和其他恶意软件。 当已知恶意软件或不需要的软件试图在 Azure 系统上安装自身或运行时,Microsoft 反恶意软
件将提供可配置的警报。

Azure 备份是一种可缩放的解决方案,无需资本投资便可保护应用程序数据,从而最大限度降低运营成本。 应用
程序错误可能会损坏数据,人为错误可能会将 bug 引入应用程序。 使用 Azure 备份可以保护运行 Windows 和
Linux 的虚拟机。
Azure Site Recovery 可帮助协调工作负荷和应用的复制、故障转移及恢复,因此能够在主要位置发生故障时通过
辅助位置来提供工作负荷和应用。

确保符合性:云服务审慎调查清单
Microsoft 制定了云服务审慎调查清单,帮助组织在考虑迁移到云时执行审慎调查。 它为所有规模、所有类型的
组织(私有企业和公共部门组织,包括所有级别的政府部门和非盈利组织)提供了一种结构,用于确定他们自己的
性能、服务、数据管理以及监管目标和要求。 这样,他们就可以对不同云服务提供商的服务/产品进行比较,最终
构成云服务协议的基础。
该清单提供一个框架,该框架与新的云服务协议国际标准 ISO/IEC 19086 逐条保持一致。 此标准为组织提供一
系列统一的考虑事项,帮助他们就云采用做出决策,并为云服务产品的比较确立一个共同的基础。

该清单促使云迁移得到全面审核,并为云服务提供商的选择提供结构化指导以及一致且可重复的方法。

云采用不再只是技术决策。 由于清单要求涉及组织的方方面面,因此它们可以让内部所有关键决策者(CIO、
CISO 以及法律、风险管理、采购和合规性专业人员)聚集在一起。 这样可以通过合理的推论提高决策过程和基本
决策的效率,从而降低出现影响云采用的意外障碍的可能性。

此外,该清单:

在云采用流程开始时公开决策者的关键议题。

支持就法律法规以及组织自身的隐私、个人身份信息 (PII) 和数据安全目标展开深入的业务讨论。

帮助组织识别任何可能影响云项目的问题。

针对各提供商提供一系列一致的问题,以及相同的术语、定义、指标和可交付结果,从而简化不同云服务
提供商产品/服务的比较过程。

Azure 基础结构和应用程序安全性验证
Azure 操作安全性 是指可供用户在 Microsoft Azure 中保护其数据、应用程序和其他资产的服务、控件和功能。

Azure 操作安全性建立在一个框架上,该框架融合了通过 Microsoft 独有的各种功能获得的知识,包括 Microsoft


安全开发生命周期 (SDL)、Microsoft 安全响应中心计划以及对网络安全威胁形态的深刻认识。

Microsoft Azure 监视 器
Azure Monitor 是适用于混合云的 IT 管理解决方案。 Azure Monitor 日志可单独使用,也可用于扩展现有 System
Center 部署,为你基于云来管理基础结构提供了最大的灵活性和控制度。
使用 Azure Monitor ,可以在任何云中(包括本地、Azure、AWS 、Windows Server 、Linux、VMware 和 OpenStack)
管理任何实例,且成本低于其他竞争性的解决方案。 Azure Monitor 专为云优先的环境而构建,为管理企业提供
了一种新方法,能最快且最经济高效地应对新的业务挑战并适应新的工作负载、应用程序和云环境。

Azure Monitor 日志
Azure Monitor 日志通过将受管理资源的数据收集到中心存储库来提供监视服务。 这些数据可能包括事件、性能
数据或通过 API 提供的自定义数据。 收集后,可以分析、导出数据或针对它们发出警报。

使用这种方法可以整合来自各种来源的数据,因此可将 Azure 服务中的数据合并到现有的本地环境。 此外,它还


能将数据收集与针对该数据执行的操作明确区分开来,以便能够针对所有类型的数据执行所有操作。

Azure 安全中心
Azure 安全中心有助于预防、检测和响应威胁,同时增加 Azure 资源的可见性和安全可控性。 它提供 Azure 订阅
之间的集成安全监视和策略管理,帮助检测可能被忽略的威胁,且适用于广泛的安全解决方案生态系统。

安全中心将分析 Azure 资源的安全状态,以识别潜在的安全漏洞。 会有一列建议对所需控件的整个配置过程提


供指导。

示例包括:

设置反恶意软件可帮助识别和删除恶意软件

配置网络安全组和规则来控制发送到 VM 的流量

设置 web 应用程序防火墙,帮助抵御针对 web 应用程序的攻击

部署缺少的系统更新

解决与推荐基线不匹配的操作系统配置

安全中心自动从 Azure 资源、网络和合作伙伴解决方案(例如恶意软件程序和防火墙)收集、分析和整合数据。 检


测到威胁时会创建安全警报。 示例中包括的检测项:

与已知的恶意 IP 地址通信的不符合安全性的 VM

使用 Windows 错误报告检测到的高级恶意软件

对 VM 的暴力破解攻击

来自集成的反恶意软件程序和防火墙的安全警报

Azure Monitor
Azure Monitor 提供一系列指针,指向特定资源类型的相关信息。 它对来自 Azure 基础结构(活动日志)和每个单
独 Azure 资源(诊断日志)的数据提供可视化、查询、路由、警报、自动缩放和自动化功能。
云应用程序很复杂,包含很多移动部件。 监视可以为用户提供数据,确保应用程序始终处于健康运行状态。 监视
还有助于避免潜在问题,或者解决过去的问题。

此外,还
可以利用监视数据深入了解应用程序的情况。 了解这些情况有助于改进应用程序的性能或可维护性,或者实现
本来需要手动干预的操作的自动化。

审核网络安全性对于检测网络漏洞以及确保符合 IT 安全和监管治理模型至关重要。 使用安全组视图,可以检索


配置的网络安全组和安全规则,以及有效的安全规则。 应用规则列表后,可以确定打开的端口并评估网络漏洞。

网 络观 察程序
网络观察程序是一个区域性服务,可用于在网络级别监视和诊断 Azure 内部以及传入和传出 Azure 的流量的状
态。 借助网络观察程序随附的网络诊断和可视化工具,可以了解、诊断和洞察 Azure 中的网络。 此服务包括数据
包捕获、下一跃点、IP 流验证、安全组视图和 NSG 流日志。 与单独网络资源的监视不同,方案级监视提供网络资
源的端到端视图。

存 储 分析
存储分析可存储一些指标,这些指标包括有关存储服务请求的聚合事务统计信息和容量数据。 在 API 操作级别
以及存储服务级别报告事务,并在存储服务级别报告容量。 度量值数据可用于分析存储服务使用情况,诊断对存
储服务所发出请求的问题以及提高使用服务的应用程序的性能。

Application Insights
Application Insights 是多个平台上面向 Web 开发人员的可扩展应用程序性能管理 (APM) 服务。 使用它可以监视
实时 Web 应用程序。 它会自动检测性能异常。 Application Insights 内含强大的分析工具,有助于诊断问题并了
解用户在应用中执行的操作。 Application Insights 有助于持续提高性能与可用性。 它适用于本地或云中托管的
各种平台(包括 .NET、Node.js 和 Java EE)中的应用。 它与 devOps 流程集成,并具有与各种开发工具的连接点。

监视:

请 求率、响 应时间 和失 败 率 - 了解最受欢迎的页面、时段以及用户的位置。 查看哪些页面效果最好。 当


有较多请求时,如果响应时间长且失败率高,则可能存在资源问题。

依 赖项 速率、响 应时间 和失 败 率 - 了解外部服务是否正拖慢速度。

异常 - 分析聚合的统计信息,或选择特定实例并钻取堆栈跟踪和相关请求。 报告服务器和浏览器异常。

页 面 查 看次数和 负载 性能 - 由用户的浏览器报告。
来自网 页 的 AJAX 调 用 :速率、响应时间和失败率。
用 户 和会 话计 数。

Windows 或 Linux 服务器计算机中的 性能 计 数器 ,例如 CPU、内存和网络使用情况。


Docker 或 Azure 中的 主机 诊 断 。
应用中的 诊 断跟踪日志 - 可以将跟踪事件与请求相关联。

在客户端或服务器代码中自行编写的 自定 义 事件和指 标 ,用于跟踪业务事件(例如销售的商品或赢得的


游戏)。

应用程序的体系结构通常由许多组件构成 – 其中可能包括虚拟机、存储帐户、虚拟网络、Web 应用、数据库、数


据库服务器和第三方服务。 这些组件不会以独立的实体出现,而是以单个实体的相关部件和依赖部件出现。 如
果希望以组的方式部署、管理和监视这些这些组件, 可以使用 Azure Resource Manager 将解决方案中的资源作
为一个组进行处理。

可以通过一个协调的操作为解决方案部署、更新或删除所有资源。 可以使用一个模板来完成部署,该模板适用于
不同的环境,例如测试、过渡和生产。 Resource Manager 提供安全、审核和标记功能,以帮助你在部署后管理资
源。

使用 Resource Manager 的 优势

资源管理器提供多种优势:

可以以组的形式部署、管理和监视解决方案的所有资源,而不是单独处理这些资源。

可以在整个开发生命周期内重复部署解决方案,并确保以一致的状态部署资源。

可以通过声明性模板而非脚本来管理基础结构。

可以定义各资源之间的依赖关系,使其按正确的顺序进行部署。

可以将访问控制应用到资源组中的所有服务,因为 Azure 基于角色的访问控制 (Azure RBAC) 已在本机集


成到管理平台。

可以将标记应用到资源,以逻辑方式组织订阅中的所有资源。

可以通过查看一组共享相同标记的资源的成本来理清组织的帐单。

NOTE
Resource Manager 提供了一种新方法来部署和管理解决方案。 如果使用早期的部署模型并想了解这些更改,请参阅了解
Resource Manager 部署和经典部署。

后续步骤
Azure 安全基准计划包括一系列安全建议,可用于帮助保护在 Azure 中使用的服务。
Azure 服务的 “内置安全控制 ”文章索引
2021/2/9 • • Edit Online

本索引提供指向“内置安全控制”文章的链接。 安全控制是促使 Azure 服务能够防范、检测和响应安全漏洞的一种


服务质量或功能。

内置安全控制文章适用于以下服务:

Azure 应用服务
Azure Resource Manager
Azure 服务总线中继
Azure Spring Cloud
Azure 基础结构安全性
2021/2/9 • • Edit Online

Microsoft Azure 在由 Microsoft 管理和运营的数据中心运行。 这些地理位置分散的数据中心符合有关安全性和


可靠性的关键行业标准,例如 ISO/IEC 27001:2013 和 NIST SP 800-53 。 它们由 Microsoft 运营人员进行管理和
监控。 这些运营人员在提供全球最大的全天候持续运行的联机服务方面拥有多年经验。

保护 Azure 基础结构
本系列文章提供了有关 Microsoft 如何保护 Azure 基础结构的信息。 文章讨论了:

物理安全性
可用性
组件和边界
网络体系结构
生产网络
SQL 数据库
操作
监视
完整性
数据保护

后续步骤
了解云中责任分担。

了解 Azure 安全中心如何有助于预防、检测和应对威胁,同时提高了 Azure 资源安全性的可见性和可控


性。
Azure 设施、场地和物理安全性
2021/2/9 • • Edit Online

本文介绍 Microsoft 采取哪些措施来保护 Azure 基础结构的安全。

数据中心基础结构
Azure 由全球分布式数据中心基础结构组成,该基础结构支持数千个联机服务,并跨越全球 100 多个高度安全的
设施。

该基础结构旨在使应用程序更靠近全球用户、预留数据的驻留位置,并为客户提供全面的符合性与复原选项。
Azure 在全球设立了 58 个区域,并已在 140 个国家/地区推出。
区域是指通过大规模弹性网络互连的一系列数据中心。 该网络包括区域内的或在区域间传播的所有 Azure 流量
的内容分发、负载均衡、冗余和默认情况下的数据链路层加密。 Azure 包含的全球区域比任何其他云提供商所包
含的都多,因此允许你灵活地选择部署应用程序所需的位置。

Azure 区域组织为地域形式。 Azure 地域保证数据驻留、主权、符合性和恢复能力的要求在地域边界内得到遵


从。

地域允许具有特定数据驻留和符合性要求的客户保持他们的数据和应用程序相邻近。 通过与专用的高容量网络
基础设施相连,地域具有容错能力,可承受整个区域的故障。

可用性区域是 Azure 区域中的物理上独立的位置。 每个可用性区域都由一个或多个数据中心组成,这些数据中


心都配置了独立电源、冷却和网络。 可用性区域允许运行任务关键型应用程序,同时具有高可用性和低延迟复
制。

下图显示了 Azure 全球基础结构如何将同一数据驻留边界内的区域和可用性区域配对,以实现高可用性、灾难恢


复和备份。
地理分布式数据中心使得 Microsoft 非常靠近客户,以降低网络延迟并实现异地冗余的备份和故障转移。

物理安全性
Microsoft 设计、构建和运营数据中心的方式能够严格控制对存储数据的区域的物理访问。 Microsoft 理解保护数
据的重要性,并承诺帮助保护包含客户数据的数据中心。 Microsoft 专门设立了一个完整的部门来设计、构建和
运营支持 Azure 的物理设施。 此团队在维持一流物理安全性方面投入了大量的人力物力。

Microsoft 采用分层方法实现物理安全性,以减少未经授权的用户获取数据和数据中心资源的物理访问权限的风
险。 Microsoft 管理的数据中心具有广泛的保护层:在设施周边、建筑物周边、建筑物内部和数据中心楼层上实施
访问权限审批。 物理安全层包括:

访问权 限 请 求和 审 批。 必须在抵达数据中心之前请求访问权限。 必须提供来访的有效业务理由,例如,


出于法规或审核目的。 Microsoft 员工根据“访问必要性”审批所有请求。 “访问必要性”依据有助于将在数
据中心完成某个任务所需的人数减到最少。 在 Microsoft 授予权限后,个人只能根据批准的业务理由访问
数据中心的所需离散区域。 权限的有效期限制为特定的一段时间,此后过期。

设 施周 边 。 抵达数据中心时,必须经过完善定义的访问点。 通常,由钢筋混凝土制成的高墙会围住周边
的每一次土地。 数据中心的周围有摄像头,安全团队全时间监控视频。

建筑物入口。 数据中心的入口由专业的保安人员值守,他们经受过严格的培训和背景检查。 这些保安人


员还会例行巡视数据中心,同时也会全时间监控数据中心内部的摄像头视频。

建筑物内部。 进入建筑物后,必须使用生物识别特征通过双重身份验证,然后才能继续在数据中心内部
走动。 如果你的身份通过验证,只能进入已获批访问的数据中心区域。 只能在该区域中逗留批准的一段
时间。

数据中心楼 层 。 你只能进入获批进入的楼层。 必须通过全身金属探测扫描。 为了减少在我们不知情的情


况下,未经授权的数据进入或离开数据中心的风险,只有获批准的设备可以进入数据中心楼层。 此外,视
频摄像头会监控每个服务器机架的正面和背面。 当你离开数据中心楼层时,同样需要通过全身金属探测
扫描。 若要离开数据中心,必须通过其他安全扫描。

Microsoft 要求访问者必须在离开 Microsoft 设施时交回徽章。

物理安全性评审
我们定期对设施执行物理安全性评审,确保数据中心正常满足 Azure 的安全要求。 数据中心托管提供商人员不
会提供 Azure 服务管理。 这些人员无法登录 Azure 系统,且没有 Azure 机房和机舱的物理访问权限。

数据承载设备
Microsoft 使用最佳做法过程和符合 NIST 800-88 的数据擦除解决方案。 对于无法擦除的硬盘驱动器,我们会使
用销毁过程来销毁该驱动器,并避免恢复信息。 销毁过程可能包括解体、切碎、粉碎或焚烧。 我们根据资产类型
确定处置方式。 我们会保留销毁记录。

设备处置
在系统使用寿命结束时,Microsoft 操作人员会遵循严格的数据处理过程和硬件处置过程,确保不会将包含数据
的硬件提供给不受信任的一方使用。 对于支持安全擦除方法的硬盘驱动器,我们会使用此方法。 对于无法擦除
的硬盘驱动器,我们会使用销毁过程来销毁该驱动器,并避免恢复信息。 销毁过程可能包括解体、切碎、粉碎或
焚烧。 我们根据资产类型确定处置方式。 我们会保留销毁记录。 所有 Azure 服务使用已批准的介质存储和处置
管理服务。

合规性
Azure 基础结构的设计和管理符合广泛的国际和行业特定标准,例如 ISO 27001、HIPAA、FedRAMP、SOC 1 和
SOC 2。 此外还符合国家/地区特定的标准,包括澳大利亚的 IRAP、英国的 G-Cloud 和新加坡的 MTCS 。 严苛的
第三方审核(例如英国标准协会进行的审核)可验证 Azure 是否遵循严格的安全控制标准。

有关 Azure 遵守的合规标准的完整列表,请参阅合规性产品。

后续步骤
若要详细了解 Microsoft 如何帮助保护 Azure 基础结构,请参阅:

Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure 生产网络
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构监视
Azure 基础结构完整性
Azure 客户数据保护
Azure 基础结构可⽤性
2021/2/9 • • Edit Online

本文介绍 Microsoft 如何保护 Azure 基础结构并提供客户数据的最大可用性。 Azure 基于通过虚拟化技术实现的


全面冗余提供可靠的可用性。

临时停电和自然灾害
Microsoft 云基础结构和运营团队设计、生成、运营云基础结构并提高其安全性。 该团队确保 Azure 基础结构提
供高可用性和可靠性、高效率、智能可伸缩性。 该团队提供更安全、更专用且更受信任的云。

不间断电源和大量电池可确保在发生短期电力中断时仍然持续供电。 应急发电机为长时间的停电和计划内维护
提供备用电源。 如果发生自然灾难,数据中心可以使用现场燃料储备。

高速且可靠的光纤网络将数据中心与其他主要中心和 Internet 用户连接起来。 计算节点将工作负荷托管在离用


户较近的位置,以减少延迟、提供异地冗余并提高整体服务复原能力。 一组工程师全天候工作,以确保服务持续
可用。

Microsoft 通过高级监视和事件响应、服务支持以及备份故障转移功能确保高可用性。 地理位置分散的 Microsoft


运营中心每周 7 天、每天 24 小时运营。 Azure 网络是世界上最大的网络之一。 光纤和内容分发网络连接数据中
心和边缘节点,以确保高性能和可靠性。

灾难恢复
Azure 使数据在两个位置保持持久性。 可以选择备份站点的位置。 在这两个位置,Azure 始终维护数据的三个正
常副本。

数据库可用性
Azure 确保可通过具有持续数据库可用性的 Internet 网关从 Internet 访问数据库。 监视服务以 5 分钟的时间间
隔评估活动数据库的运行状况和状态。

存储可用性
Azure 通过高度可缩放且持久的存储服务提供存储,该服务提供连接终结点。 这意味着应用程序可以直接访问存
储服务。 存储服务在保持事务完整性的同时有效地处理传入存储请求。

后续步骤
若要详细了解 Microsoft 如何帮助保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure 生产网络
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构监视
Azure 基础结构完整性
Azure 客户数据保护
Azure 信息系统的组件和边界
2021/2/9 • • Edit Online

本文提供有关 Azure 体系结构和管理的一般说明。 Azure 系统环境由以下网络组成:

Microsoft Azure 生产网络(Azure 网络)


Microsoft 企业网络 (corpnet)
独立的 IT 团队负责操作和维护这些网络。

Azure 体系结构
Azure 是一个云计算平台和基础结构,用于通过数据中心的网络构建、部署和管理应用程序与服务。 Microsoft 管
理这些数据中心。 基于指定的资源数量,Azure 会根据资源需求创建虚拟机 (VM)。 这些 VM 在 Azure 虚拟机监
控程序中运行,该程序只能在云中使用,而不会提供给公众访问。

在每个 Azure 物理服务器节点上,有一个虚拟机监控程序直接通过硬件运行。 虚拟机监控程序将节点划分为数


量可变的来宾 VM。 每个节点还提供一个根 VM,用于运行主机操作系统。 每个 VM 上已启用 Windows 防火墙。
通过配置服务定义文件来定义可寻址的端口。 只有这些端口是开放的,且可在内部或外部寻址的端口。 发往磁
盘和网络的所有流量以及对其的访问均由虚拟机监控程序和根操作系统进行调解。

在主机层,Azure VM 运行最新 Windows Server 的定制强化版本。 Azure 使用的 Windows Server 版本只包含托
管 VM 所需的组件。 这可以提高性能,并减小受攻击面。 机器边界由虚拟机监控程序实施,不依赖于操作系统安
全性。

通 过结 构控制器 进 行 Azure 管理
在 Azure 中,物理服务器(刀片服务器/节点)上运行的 VM 分组为大约由 1000 个 VM 构成的群集。 这些 VM 由
一个横向扩展的冗余平台软件组件(称为结构控制器 (FC))单独管理。

每个 FC 管理其群集中运行的应用程序的生命周期,预配并监视受其控制的硬件的运行状况。 它会运行自主操
作,例如,在确定服务器出现故障时,它会在正常的服务器上重建 VM 实例。 FC 还会执行应用程序管理操作,例
如部署、更新和横向扩展应用程序。

数据中心划分为群集。 群集在 FC 级别隔离故障,并防止特定种类的错误影响到发生这些错误的群集以外的服务


器。 为特定 Azure 群集提供服务的 FC 分组到 FC 群集。

硬件 库 存
FC 在启动配置过程中准备 Azure 硬件和网络设备的库存。 进入 Azure 生产环境的任何新硬件和网络组件必须遵
循启动配置过程。 FC 负责管理 datacenter.xml 配置文件中列出的整个库存。

FC 托管的操作系 统 映像
操作系统团队以虚拟硬盘的形式提供映像,这些映像将部署到 Azure 生产环境中的所有主机和来宾 VM。 该团队
通过自动化的脱机生成过程构建这些基本映像。 基本映像是操作系统的一个版本,其中的内核和其他核心组件
已经过修改和优化,可支持 Azure 环境。

有三种类型的结构托管操作系统映像:

主机:在主机 VM 上运行的定制操作系统。
本机:在租户(例如 Azure 存储)上运行的本机操作系统。 此操作系统不包含任何虚拟机监控程序。
来宾:在来宾 VM 上运行的来宾操作系统。

主机和本机 FC 托管的操作系统只能在云中使用,不可供公众访问。
主机和本机操作系 统

主机和本机操作系统是强化的操作系统映像,它们托管结构代理,并在计算节点(作为节点上的第一个 VM 运行)
和存储节点上运行。 使用主机和本机操作系统的优化基本映像的好处在于,可以减少 API 或未使用的组件公开
的外围应用。 这些 API 或组件可能存在较高的安全风险,并增大操作系统的覆盖范围。 覆盖范围减小的操作系
统只包括 Azure 所需的组件。

来 宾 操作系 统

来宾操作系统 VM 上运行的 Azure 内部组件无法运行远程桌面协议。 对基线配置设置所做的任何更改都必须经


历更改和发布管理过程。

Azure 数据中心
Microsoft 云基础结构和运营 (MCIO) 团队管理所有 Microsoft 联机服务的物理基础结构和数据中心设施。 MCIO
主要负责管理数据中心内的物理和环境控制,以及管理和支持外围网络设备(例如边缘路由器和数据中心路由
器)。 MCIO 还负责在数据中心内的机架上设置最基本的服务器硬件。 客户无法直接与 Azure 交互。

服务管理和服务团队
Azure 服务的支持由称作“服务团队”的多个工程小组来管理。 每个服务团队负责某个方面的 Azure 支持工作。 每
个服务团队必须指派一名全天候工作的工程师,以调查和解决服务中的故障。 默认情况下,服务团队无法对
Azure 中运行的硬件进行实物接触。
服务团队负责:

应用程序平台
Azure Active Directory
Azure 计算
Azure Net
云工程服务
ISSD:安全性
多重身份验证
SQL 数据库
存储

用户类型
Microsoft 的员工(或合同工)被视为内部用户。 其他所有用户被视为外部用户。 所有 Azure 内部用户都有一种根
据敏感级别分类的员工状态,该状态定义了相应用户对客户数据的访问权限(有访问权限或无访问权限)。 下表
描述了用户对 Azure 的特权(身份验证后的授权权限):
Azure 数据中心工程 内部 无权访问客户数据 管理现场的物理安全 对环境的持久性访问
师 性。 数据中心进出人 权限。
员的巡查,监控所有
入口点。 针对在数据
中心内部提供日常服
务(餐饮、清洁)或 IT
工作的某些非特许人
员,执行数据中心进
出人员护送服务。 针
对网络硬件展开例行
监控和维护。 使用各
种工具执行事件管理
和中断修复工作。 针
对数据中心内的物理
硬件展开例行监控和
维护。 根据业主的要
求访问环境。 能够执
行取证调查、记录事
件报告,并提出强制
性的安全培训和政策
要求。 对关键安全工
具(例如扫描仪和日
志收集)拥有操作所
有权和维护权。

Azure 事件会审(快速 内部 有权访问客户数据 管理 MCIO、支持与 环境的适时访问权


响应工程师) 工程团队之间的沟 限,对非客户系统的
通。 会审平台事件、 持久性访问权限有
部署问题和服务请 限。
求。

Azure 部署工程师 内部 有权访问客户数据 部署/升级平台组件、 环境的适时访问权


软件和有计划的配置 限,对非客户系统的
更改,以支持 Azure。 持久性访问权限有
限。

Azure 客户中断支持 内部 有权访问客户数据 调试和诊断单个计算 环境的适时访问权


(租户) 租户与 Azure 帐户出 限,对非客户系统的
现的平台中断和故 持久性访问权限有
障。 分析故障。 为平 限。
台或客户推进关键修
复措施,在整个支持
团队中推进技术改
进。

Azure 现场工程师(监 内部 有权访问客户数据 使用诊断工具诊断和 环境的适时访问权


控工程师)和事件 缓解平台运行状况。 限,对非客户系统的
推进批量发布的驱动 持久性访问权限有
程序的修复措施、修 限。
复中断时造成的问
题,并为中断复原措
施提供协助。

Azure 客户 外部 空值 空值 空值

Azure 使用唯一标识符对组织用户和客户(或代表组织用户执行操作的流程)进行身份验证。 这适用于 Azure 环


境中包括的所有资产和设备。

Azure 内部身份 验证
Azure 内部组件之间的通信受 TLS 加密的保护。 在大多数情况下,X.509 证书已自签名。 包含可从 Azure 网络外
部访问的连接的证书以及 FC 的证书例外。 FC 具有 Microsoft 证书颁发机构 (CA) 颁发的证书,该 CA 以受信任的
根 CA 为后盾。 因此,可以轻松滚动更新 FC 公钥。 此外,Microsoft 开发人员工具使用 FC 公钥。 当开发人员提
交新的应用程序映像时,会使用 FC 公钥加密这些映像,以保护任何嵌入的机密。

Azure 硬件 设备 身份 验证
FC 维护一组凭据(密钥和/或密码),用于在其控制的各种硬件设备上对自身进行身份验证。 Microsoft 使用某个
系统来防止访问这些凭据。 具体而言,在传输、保存和使用这些凭据时,可防止 Azure 开发人员、管理员和备份
服务和人员访问敏感的机密信息或私人信息。

Microsoft 使用基于 FC 的主标识公钥的加密。 在设置 FC 和重新配置 FC 时将采用这种加密技术来传输用于访问


网络硬件设备的凭据。 当 FC 需要凭据时,FC 会检索并解密凭据。

网 络设备
Azure 网络团队将配置网络服务帐户,使 Azure 客户端能够在网络设备(路由器、交换机和负载均衡器)中进行身
份验证。

安全服务管理
Azure 运营人员必须使用安全管理员工作站 (SAW)。 客户可以使用特权访问工作站实现类似的控制。 借助
SAW,管理人员可以使用与用户的标准用户帐户不同的、单独分配的管理帐户。 SAW 通过为这些敏感帐户提供
可信的工作站,建立此帐户分离做法。

后续步骤
若要详细了解 Microsoft 如何帮助保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 网络体系结构
Azure 生产网络
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构监视
Azure 基础结构完整性
Azure 客户数据保护
Azure ⽹络体系结构
2021/2/9 • • Edit Online

Azure 网络体系结构提供从 Internet 到 Azure 数据中心的连接。 在 Azure 上部署 (IaaS 、PaaS 和 SaaS) 的任何工
作负荷都利用了 Azure 数据中心网络。

网络拓扑
Azure 数据中心的网络体系结构由以下组件组成:
边缘网络
广域网络
区域网关网络
数据中心网络

网络组件
网络组件的简短说明。

边缘网络

Microsoft 网络和其他网络之间的分界点 (例如,Internet、企业网络)


向 Azure 提供 Internet 和 ExpressRoute 对等互连
广域网络

全球范围内的 Microsoft 智能主干网络


提供Azure 区域之间的连接
区域网关
Azure 区域中所有数据中心的聚合点
在 Azure 区域内的数据中心之间提供大规模连接 (例如,每个数据中心有几百个 terabits)
数据中心网络

提供数据中心内服务器之间的连接,具有较低的超额订阅带宽

上述网络组件旨在提供最大的可用性,以支持始终可用的、始终可用的云业务。 从物理方面一直到控制协议,将
冗余设计并内置到网络中。

数据中心网络复原
让我们使用数据中心网络展示复原设计原则。

数据中心网络是 Clos 网络的修改版本,可为云规模流量提供较高的 bi 版本。 网络是使用大量商用设备构造的,


以降低单个硬件故障造成的影响。 这些设备在不同的物理位置上战略定位在不同的物理位置,从而降低了环境
事件的影响。 在控制平面上,所有网络设备都作为 OSI 模型第3 层路由模式运行,从而消除了流量循环的历史问
题。 不同层之间的所有路径都处于活动状态,以便使用 Equal-Cost 多路径 (ECMP) 路由来提供高冗余和带宽。

下图演示了数据中心网络由不同的网络设备层构造。 该图中的条形表示提供冗余和高带宽连接的网络设备组。

后续步骤
若要详细了解 Microsoft 如何帮助保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 生产网络
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构监视
Azure 基础结构完整性
Azure 客户数据保护
Azure ⽣产⽹络
2021/2/9 • • Edit Online

Azure 生产网络的用户包括访问其自己的 Azure 应用程序的外部客户以及管理生产网络的 Azure 内部支持人员。


本文介绍了用于与 Azure 生产网络建立连接的安全接入方法和保护机制。

Internet 路由和容错
全局冗余的内部和外部 Azure 域名服务 (DNS) 基础结构与多个主要和辅助 DNS 服务器群集相结合,可提供容错
功能。 与此同时,其他 Azure 网络安全控件(如 NetScaler )可预防分布式拒绝服务 (DDoS) 攻击并保护 Azure
DNS 服务的完整性。
Azure DNS 服务器位于多个数据中心设施。 Azure DNS 实现整合了辅助和主要 DNS 服务器的层次结构,可公开
解析 Azure 客户域名。 域名通常解析成 CloudApp.net 地址,其中包装了客户服务的虚拟 IP (VIP) 地址。 Azure 的
独特之处在于,与租户转换的内部专用 IP (DIP) 地址对应的 VIP 由负责该 VIP 的 Microsoft 负载均衡器执行。

Azure 托管在分布于美国境内各处的 Azure 数据中心,且基于一流路由平台构建,可实施可靠、可缩放体系结构


标准。 其中包含如下重要功能:

基于多协议标签交换 (MPLS) 的流量工程,在发生服务中断时,可提供高效的链路利用率和妥善的服务降级。


以“需求加一”(N+1) 冗余体系结构或更佳的方式实施网络。
从外部看,数据中心由专用的高带宽网络线路提供服务,这些线路以冗余方式将资产连接到全球 1,200 多个
Internet 服务提供商的多个对等互连点。 连接后可提供超过 2,000 GB/秒 (GBps) 的边缘容量。
由于 Microsoft 在数据中心之间拥有自身的网络线路,因此,这些属性有助于 Azure 产品/服务实现 99.9% 以上
的网络可用性,而无需与传统的第三方 Internet 服务提供商合作。

连接到生产网络和关联的防火墙
Azure 网络 Internet 流量流策略将流量定向到美国境内最靠近的区域数据中心内的 Azure 生产网络。 由于 Azure
生产数据中心拥有一致的网络体系结构和硬件,下面的流量流说明同样适用于所有数据中心。

将 Azure 的 Internet 流量路由到最近的数据中心后,将与接入的路由器建立连接。 这些接入路由器用于隔离


Azure 节点与客户实例化 VM 之间的流量。 位于接入位置和边缘位置的网络基础结构设备是应用入口和出口筛
选器的边界点。 这些路由器已通过分层的访问口控制列表 (ACL) 进行配置,在必要时可以筛选不需要的网络流
量并应用流量速率限制。 ACL 允许的流量将路由到负载均衡器。 分配路由器只允许 Microsoft 批准的 IP 地址,
可提供反欺骗功能,并建立使用 ACL 的 TCP 连接。

外部负载均衡设备位于接入路由器后方,执行从 Internet 可路由 IP 到 Azure 内部 IP 的网络地址转换 (NAT)。 设


备还将数据包路由到有效的生产内部 IP 和端口,并且它们充当保护机制,限制内部生产网络地址空间的公开。

默认情况下,Microsoft 针对传输到客户 Web 浏览器的所有流量(包括登录和由此产生的所有流量)强制实施安


全超文本传输协议 (HTTPS)。 使用 TLS v1.2 能够为传送的流量建立安全隧道。 接入路由器和核心路由器上的
ACL 确保流量的源符合预期。
与传统的安全体系结构相比,此体系结构的重要区别在于没有专用的硬件防火墙、专用的入侵检测或预防设备,
或者在与 Azure 生产环境建立连接之前通常需要的其他安全设备。 客户通常预期 Azure 网络中存在这些硬件防
火墙设备;但是,Azure 中并未采用任何此类设备。 这些安全功能内置在运行 Azure 环境的软件中,提供包括防
火墙功能在内的可靠多层安全机制,这几乎是 Azure 独有的特色。 此外,如上图所示,关键安全设备的边界范围
和关联衍生功能更易于管理和清点,因为它们由运行 Azure 的软件管理。

核心安全性和防火墙功能
Azure 在各个级别实现可靠的软件安全性和防火墙功能来强制执行传统环境中通常需要的安全功能,以保护核心
安全授权边界。

Azure 安全功能
Azure 在生产网络内实现基于主机的软件防火墙。 核心 Azure 环境中包含多种核心安全性和防火墙功能。 这些
安全功能反映了 Azure 环境中的深层防御策略。 Azure 中的客户数据受以下防火墙的保护:

虚 拟 机 监 控程序防火 墙 (数据包 筛选 器) :在虚拟机监控程序中实现此防火墙并由结构控制器 (FC) 代理配置。


此防火墙可保护在 VM 内运行的租户免受未经授权的访问。 默认情况下,创建 VM 时,将阻止所有流量,然后 FC
代理在筛选器中添加规则和例外,以允许获得授权的流量。

此处对两类规则进行了编程:

计 算机配置或基 础结 构 规则 :默认情况下,将阻止所有通信。 但也存在例外情况,可允许 VM 发送和接收动


态主机配置协议 (DHCP) 通信和 DNS 信息,并将流量发送到“公共”Internet 并出站到 FC 群集与 OS 激活服务
器内的其他 VM。 由于 VM 允许的传出目标列表不包括 Azure 路由器子网和其他 Microsoft 属性,因此这些规
则将充当它们的一道防御层。
角色配置文件 规则 :根据租户的服务模型定义入站 ACL 。 例如,如果某个租户在某个特定 VM 的端口 80 上
有一个 Web 前端,则会向所有 IP 地址开放端口 80 。 如果 VM 上正在运行某个辅助角色,则只向同一租户中
的 VM 开放该辅助角色。

本机主机防火 墙 :Azure Service Fabric 和 Azure 存储在本机 OS 上运行,其中没有虚拟机监控程序,因此会使用


上述两组规则配置 Windows 防火墙。

主机防火 墙 :主机防火墙保护运行虚拟机监控程序的主机分区。 可以通过编程方式对规则进行设置,只允许 FC


和跳转盒在特定端口上与主机分区通信。 其他例外包括允许 DHCP 响应和 DNS 回复。 Azure 使用计算机配置文
件,其中包括主机分区的防火墙规则模板。 还有一种主机防火墙例外情况,可允许 VM 通过特定协议/端口与主
机组件、网络服务器和元数据服务器进行通信。

来 宾 防火 墙 :来宾 OS 的 Windows 防火墙部分,可由客户在客户 VM 和存储中配置。

内置于 Azure 功能中的其他安全功能包括:

基础结构组件,可为其分配来自 DIP 的 IP 地址。 Internet 上的攻击者无法将流量发往这些地址,因其无法


访问 Microsoft。 Internet 网关路由器筛选仅发往内部地址的数据包,因此这些数据包不会进入生产网络。
只有负载均衡器才是接受定向到 VIP 的流量的组件。

在任何给定的场景下,所有内部节点上实现的防火墙在安全体系结构方面都存在三个主要注意事项:

防火墙位于负载均衡器后方,接受来自任何位置的数据包。 这些数据包可在外部公开,对应于传统外
围防火墙中打开的端口。
防火墙仅接受来自一组有限地址的数据包。 此考虑是针对 DDoS 攻击的防御性深入战略的一部分。 此
类连接以加密方式进行身份验证。
仅可从选定的内部节点访问防火墙。 防火墙仅接受源 IP 地址枚举列表中的数据包,所有这些都是
Azure 网络中的 DIP。 例如,企业网络中出现的攻击可能会将请求定向到这些地址,但将阻止攻击,除
非数据包的源地址是 Azure 网络内枚举列表中的某个地址。
外围的接入路由器会阻止发往 Azure 网络中某个地址的出站数据包,因为它使用配置的静态路
由。

后续步骤
若要详细了解 Microsoft 如何保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构监视
Azure 基础结构完整性
Azure 客户数据保护
Azure SQL 数据库安全功能
2021/2/9 • • Edit Online

Azure SQL 数据库在 Azure 中提供关系型数据库服务。 为了保护客户数据并提供关系型数据库服务预期具备的


强大安全功能,SQL 数据库具有自身的安全功能集。 这些功能立足于从 Azure 继承的控制能力。

安全功能
TDS 协议 用法
Azure SQL 数据库仅支持表格格式数据流 (TDS) 协议,该协议要求只能通过默认端口 TCP/1433 访问数据库。
Azure SQL 数据 库 防火 墙
为了帮助保护客户数据,Azure SQL 数据库包括防火墙功能,该功能默认情况下会阻止对 SQL 数据库的所有访
问,如下所示。

网关防火墙可以限制地址,使客户能够进行精细控制,以指定可接受的 IP 地址范围。 防火墙基于每个请求的来


源 IP 地址授予访问权限。

客户可以使用管理门户,或者使用 Microsoft Azure SQL 数据库管理 REST API 以编程方式实现防火墙配置。 默认


情况下,Azure SQL 数据库网关防火墙阻止所有客户 TDS 对 Azure SQL 数据库的访问权限。 客户使用访问控制
列表 (ACL) 配置访问权限,允许通过源和目标 Internet 地址、协议和端口号建立 Azure SQL 数据库建立连接。

DoSGuard
名为 DoSGuard 的 SQL 数据库网关服务可以减少拒绝服务 (DoS) 攻击。 DoSGuard 能够主动跟踪 IP 地址发起的
失败登录。 如果特定的 IP 地址在一段时间内多次登录失败,则会阻止该 IP 地址在预定义的时间段内访问服务中
的任何资源。

此外,Azure SQL 数据库网关还会:

执行安全通道功能协商,以便在连接到数据库服务器时实现 TDS FIPS 140-2 验证的加密连接。


在接受来自客户端的连接时执行有状态 TDS 数据包检查。 网关会验证连接信息,并根据连接字符串中指定的
数据库名称,将 TDS 数据包传递给相应的物理服务器。

Azure SQL 数据库产品/服务网络安全性的首要原则是,只出于让服务正常运行的目的允许所需的连接和通信。


默认会阻止其他所有端口、协议和连接。 按源和目标网络、协议与端口号,使用虚拟局域网 (VLAN) 和 ACL 限制
网络通信。

已批准用于实现基于网络的 ACL 的机制包括路由器和负载均衡器上的 ACL 。 这些机制由客户配置的 Azure 网


络、来宾 VM 防火墙和 Azure SQL 数据库网关防火墙规则管理。

数据分离和客户隔离
Azure 生产网络的构建方式确保可公开访问的系统组件与内部资源相分离。 为面向公众的 Azure 门户提供访问
权限的 Web 服务器,与客户应用程序实例和客户数据所在的底层 Azure 虚拟基础之间存在物理和逻辑边界。

所有可公开访问的信息在 Azure 生产网络中进行管理。 生产网络受双重身份验证和边界保护机制的控制,使用


上一部分中所述的防火墙和安全功能集,并使用后续部分所述的数据隔离功能。

未 经 授 权 的系 统 和
FC 隔离
由于结构控制器 (FC) 是 Azure 结构的中心业务流程协调程序,因此已采取重要的控制措施来缓解它面临的威
胁,尤其是来自客户应用程序中可能受到攻击的 FA 的威胁。 FC 无法识别其设备信息(例如 MAC 地址)未预先在
FC 中加载的任何硬件。 FC 上的 DHCP 服务器包含它们想要启动的节点的已配置 MAC 地址列表。 即使未经授权
的系统已连接,它们也不会合并到结构库存中,因此,不会连接到结构库存中的任何系统,也无权与这些系统通
信。 这降低了未经授权的系统与 FC 通信并获取 VLAN 和 Azure 的访问权限的风险。

VLAN 隔离
Azure 生产网络在逻辑上分离成三个主要 VLAN:
主 VLAN:互连不受信任的客户节点。
FC VLAN:包含受信任的 FC 及支持的系统。
设备 VLAN:包含受信任的网络和其他基础结构设备。

数据包 筛选
在节点的根 OS 和来宾 OS 上实施的 IPFilter 与软件防火墙强制实施连接限制,并阻止 VM 之间未经授权的流
量。

虚 拟 机 监 控程序、根 OS 和来 宾 VM
根 OS 与来宾 VM 之间的隔离以及不同来宾 VM 之间的隔离,由虚拟机监控程序和根 OS 管理。

防火 墙 上的 规则类 型
规则定义为:

{Src IP,Src 端口,目标 IP,目标端口,目标协议,传入/传出,有状态/无状态,有状态流超时}。


仅当受任一规则的允许时,才允许传入或传出同步空闲字符 (SYN) 数据包。 对于 TCP,Azure 使用无状态规则,
其中的原则是,只允许所有非 SYN 数据包传入或传出 VM。 安全性的前提是,如果任何主机堆栈以前未发现
SYN 数据包,则灵活忽略非 SYN 数据包。 TCP 协议本身是有状态的,与无状态的基于 SYN 的规则相结合,实现
有状态实施方案的整体行为。

对于用户数据报协议 (UDP),Azure 使用有状态规则。 每当 UDP 数据包与规则匹配时,就会朝另一个方向创建反


向流。 此流具有内置的超时。

客户需负责在 Azure 提供的功能的基础上设置自己的防火墙。 此处,客户可以针对入站和出站流量定义规则。

生 产 配置管理
标准的安全配置由相应的运营团队在 Azure 和 Azure SQL 数据库中维护。 通过中心跟踪系统阐述和跟踪对生产
系统做出的所有配置更改。 通过中心跟踪系统跟踪软件和硬件更改。 使用 ACL 管理服务跟踪与 ACL 相关的网络
更改。

对 Azure 做出的所有配置在过渡环境中进行开发和测试,然后部署在生产环境中。 软件内部版本在测试过程中


进行评审。 安全和隐私检查作为入口清单条件的一部分进行评审。 相应的部署团队根据计划的时间间隔部署更
改。 在将发行版部署到生产环境之前,相应的部署团队人员会对其进行评审和签收。

将会监视更改是否成功。 发生故障时,会将更改回滚到其以前的状态,或者在得到指定人员的批准的情况下,部
署修补程序来解决故障。 使用 Source Depot、Git、TFS 、Master Data Services (MDS)、Runners、Azure 安全监
视、FC 和 WinFabric 平台在 Azure 虚拟环境中集中管理、应用和验证配置设置。

同样,将对硬件和网络更改运行已建立的验证步骤来评估它们是否符合生成要求。 通过相关小组的协调变更咨
询委员会 (CAB) 在整个堆栈上评审和授权发行版。

后续步骤
若要详细了解 Microsoft 如何保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure 生产网络
Azure 生产运营和管理
Azure 基础结构监视
Azure 基础结构完整性
Azure 客户数据保护
管理和操作 Azure ⽣产⽹络
2021/2/9 • • Edit Online

本文介绍 Microsoft 如何管理和操作 Azure 生产网络来保护 Azure 数据中心。

监视、日志记录和报告
Azure 生产网络的管理和操作需要在 Azure 运营团队与 Azure SQL 数据库之间做出协调。 团队在环境中使用了
多个系统和应用程序性能监视工具。 他们使用适当的工具来监视网络设备、服务器、服务和应用程序进程。

为确保安全执行 Azure 环境中运行的服务,运营团队实施多种级别的监视、日志记录和报告,包括以下操作:

首先,Microsoft Monitoring Agent (MMA) 从多个位置(包括结构控制器 (FC) 和根操作系统 (OS))收集监


视和诊断日志信息,并将其写入日志文件中。 该代理最终会将一部分摘要信息推送到预配置的 Azure 存
储帐户中。 此外,独立监视和诊断服务会读取各种监视和诊断日志数据并汇总信息。 监视和诊断服务将
信息写入集成日志。 Azure 使用定制的 Azure 安全监视,这是 Azure 监视系统的一个扩展。 ASM 中的组
件可以从平台中的各个位置观察、分析和报告安全相关的事件。

Azure SQL 数据库 Windows Fabric 平台为 Azure SQL 数据库提供管理、部署、开发和操作监督服务。 该


平台提供分布式多步骤部署服务、运行状况监视、自动修复和服务版本符合性。 它提供以下服务:

服务建模功能和高保真开发环境(数据中心群集的成本高昂且能力不足)。
一键式部署和升级工作流,用于执行服务启动和维护。
运行状况报告和自动化修复工作流,可实现自我修复。
跨分布式系统节点的实时监视、警报和调试工具。
集中收集操作数据和指标,以提供分散式的根本原因分析和服务见解。
用于部署、变更管理和监视的操作工具。
Azure SQL 数据库 Windows Fabric 平台和监视器脚本持续实时运行并监视。
如果出现任何异常,将会激活事件响应过程,Azure 事件会审团需遵循此过程。 相应的 Azure 支持人员会收到响
应事件的通知。 在集中式票证系统中阐述和管理问题跟踪与解决方法。 根据保密协议 (NDA) 和客户请求提供系
统正常运行时间指标。

通过企业网络和多重身份验证访问生产环境
企业网络用户群包括 Azure 支持人员。 企业网络支持内部企业职能,并提供 Azure 客户支持人员所用的内部应
用程序的访问权限。 企业网络在物理上和逻辑上与 Azure 生产网络分离。 Azure 人员使用 Azure 工作站和笔记
本电脑访问企业网络。 所有用户必须有一个 Azure Active Directory (Azure AD) 帐户(包括用户名和密码)才能访
问企业网络资源。 企业网络访问使用 Azure AD 帐户,该帐户发布给所有 Microsoft 人员、承包商和供应商,并由
Microsoft 信息技术管理。 唯一的用户标识符根据用户在 Microsoft 的雇佣关系状态来区分用户。
通过 Active Directory 联合身份验证服务 (AD FS) 进行身份验证来控制对内部 Azure 应用程序的访问。 AD FS 是
由 Microsoft 信息技术托管的服务,它通过应用安全令牌和用户声明来提供企业网络用户的身份验证。 AD FS 使
内部 Azure 应用程序能够针对 Microsoft 公司 Active Directory 域对用户进行身份验证。 若要从公司网络环境访
问生产网络,用户必须使用多重身份验证进行身份验证。

后续步骤
若要详细了解 Microsoft 如何保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure 生产网络
Azure SQL 数据库安全功能
Azure 基础结构监视
Azure 基础结构完整性
Azure 客户数据保护
Azure 基础结构监视
2021/2/9 • • Edit Online

配置和更改管理
Azure 每年都会检查和更新硬件、软件和网络设备的配置设置和基线配置。 在从开发和/或测试环境进入生产环
境之前,需开发、测试和批准更改。

Azure 安全性和符合性团队以及服务团队会对基于 Azure 的服务所需的基线配置进行评审。 服务团队评审是在


部署其产品服务前进行的测试的一部分。

漏洞管理
安全更新管理可帮助保护系统免受已知漏洞的侵害。 Azure 使用集成的部署系统来管理 Microsoft 软件的安全更
新的分发和安装。 Azure 还可以利用 Microsoft 安全响应中心 (MSRC) 的资源。 MSRC 一年中每天每时识别、监
视、响应和解决安全事件以及云漏洞。

漏洞扫描
对服务器操作系统、数据库和网络设备进行漏洞扫描。 至少按季度进行漏洞扫描。 Azure 与独立评估师约定,对
Azure 边界进行渗透测试。 还会定期进行红队练习,根据结果来改善安全性。

保护监视
Azure 安全性定义了主动监视的要求。 服务团队配置符合这些要求的主动监视工具。 主动监视工具包括
Microsoft Monitoring Agent (MMA) 和 System Center Operations Manager。 这些工具配置为在需要立即采取措
施的情况下向 Azure 安全管理人员提供实时警报。

事件管理
Microsoft 实施安全事件管理过程,以在发生事件时加速对事件的协调响应。
如果 Microsoft 发现对存储在其设备或设施上的客户数据未经授权的访问,或者发现未经授权访问这些设备或设
施导致客户数据丢失、泄露或更改,Microsoft 将采取以下措施:

立即通知客户相关安全事件。
立即调查安全事件,并向客户提供有关安全事件的详细信息。
执行合理的提示性步骤,以减轻影响并将安全事件导致的所有损害降至最低。

已建立一个事件管理框架,其中定义了角色并分配了职责。 Azure 安全事件管理团队负责管理安全事件,包括升


级,并确保在必要时专家团队的参与。 Azure 操作管理员负责监督安全和隐私事件的调查及解决。

后续步骤
若要详细了解 Microsoft 如何保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure 生产网络
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构完整性
Azure 客户数据保护
Azure 基础结构完整性
2021/2/9 • • Edit Online

软件安装
安装在 Azure 环境中的软件堆栈中的所有组件都是按照 Microsoft 的安全开发生命周期 (SDL) 流程自定义生成
的。 所有软件组件(包括操作系统 (OS) 映像和 SQL 数据库)都在变更管理和发布管理过程中进行部署。 在所有
节点上运行的 OS 是 Windows Server 2008 或 Windows Server 2012 的自定义版本。 结构控制器 (FC) 根据其为
OS 设定的角色来选择确切的版本。 此外,主机 OS 不允许安装任何未经授权的软件组件。
某些 Azure 组件作为 Azure 客户部署在来宾 OS 上运行的来宾 VM 上。

生成时的病毒扫描
Azure 软件组件(包括 OS )生成必须使用终结点保护防病毒工具进行病毒扫描。 每次病毒扫描都会在关联的生成
目录中创建一个日志,详细说明扫描的内容和扫描结果。 病毒扫描是 Azure 中每个组件的生成源代码的一部分。
如果未对代码进行干净且成功的病毒扫描,就不会将其移至生产环境中。 一旦发现任何问题,就会将生成冻结,
并提交给 Microsoft Security 的安全团队,以确定在生成的哪一处混入了“未授权”代码。

封闭和锁定的环境
默认情况下,Azure 基础结构节点和来宾 VM 上不会创建用户帐户。 此外,默认的 Windows 管理员帐户也处于
禁用状态。 Azure Live Support 的管理员经过适当的身份验证后,可以登录这些计算机并管理 Azure 生产网络以
进行紧急维修。

Azure SQL 数据库身份验证


与 SQL Server 的任何实现一样,必须严格控制用户帐户管理。 Azure SQL 数据库仅支持 SQL Server 身份验证。
若要补充客户的数据安全模型,还应使用具有强密码并配置有特定权限的用户帐户。

Microsoft 企业网络与 Azure 群集之间的 ACL 和防火墙


服务平台与 Microsoft 企业网络之间的访问控制列表 (ACL) 和防火墙可防止未经授权的内部人员访问 SQL 数据
库实例。 此外,只有来自 Microsoft 企业网络的 IP 地址范围的用户才能访问 Windows Fabric 平台管理终结点。

SQL 数据库群集节点之间的 ACL 和防火墙


作为额外保护以及深入防御策略的一部分,已在 SQL 数据库群集中的节点之间实施 ACL 和防火墙。 Windows
Fabric 平台群集内的所有通信以及所有正在运行的代码都是可信的。

自定义监视代理
SQL 数据库使用称为监视器的自定义监视代理 (MA) 来监视 SQL 数据库群集的运行状况。

Web 协议
角色 实 例 监视 和重启
Azure 确保部署的所有正在运行的角色(面向 Internet 的 Web 角色或后端处理辅助角色)都受到持续的运行状况
监视,以确保这些角色有效且高效地提供已预配它们的服务。 如果某个角色由于托管应用程序中的严重故障或
角色实例本身的基础配置问题而变得不正常,FC 将检测角色实例中的问题并启动纠正状态。
计算连接
Azure 确保可通过基于 Web 的标准协议来访问部署的应用程序或服务。 面向 Internet 的 Web 角色的虚拟实例
具有外部 Internet 连接,并且可供 Web 用户直接访问。 为了保护辅助角色代表可公开访问的 Web 角色虚拟实
例执行的操作的敏感性和完整性,后端处理辅助角色的虚拟实例具有外部 Internet 连接,但不能由外部 Web 用
户直接访问。

后续步骤
若要详细了解 Microsoft 如何保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure 生产网络
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构监视
Azure 客户数据保护
Azure 客户数据保护
2021/2/9 • • Edit Online

默认情况下,拒绝 Microsoft 运营和支持人员访问客户数据。 当授予对与支持案例相关的数据的访问权限时,只


会使用基于我们的符合性和隐私策略审核并审查的策略,使用实时 (JIT) 模型来授予它。 访问控制要求由以下
Azure 安全策略制定:
默认情况下无权访问客户数据。
客户虚拟机 (VM) 上没有用户帐户或管理员帐户。
授予完成任务所需的最低特权;审核并记录访问权限请求。

Microsoft 为 Azure 支持人员分配独特的企业 Active Directory 帐户。 Azure 依赖于 Microsoft 信息技术 (MSIT) 管
理的 Microsoft Corporate Active Directory 来控制对关键信息系统的访问。 要求执行多重身份验证,只从安全的
控制台授予访问权限。

所有访问尝试受到监视,可以通过一组基本报告来显示。

数据保护
Azure 按默认或者以客户选项的形式为客户提供可靠的数据安全性。
数据隔离 :Azure 是一项多租户服务,这意味着,多个客户的部署和 VM 存储在同一物理硬件上。 Azure 使用逻
辑隔离将每个客户的数据互相分离开来。 分离提供多租户服务的缩放和经济优势,同时严格防止客户访问其他
人的数据。

静 态 数据保 护 :客户负责确保按标准加密 Azure 中存储的数据。 Azure 提供各种加密功能,便于客户选择满足自


己需求的最佳解决方案。 Azure Key Vault 可帮助客户轻松保持对密钥的控制,以便云应用程序和服务用于加密
数据。 客户可以使用 Azure 磁盘加密来加密 VM。 Azure 存储服务加密可以加密客户存储帐户中的所有数据。

传输 中数据保 护 : Microsoft 提供了许多选项,这些选项可供客户在 Azure 网络内部和外部通过 Internet 向最终


用户提供数据传输的安全。 其中包括通过虚拟专用网络进行通信 (利用 IPsec/IKE 加密) 、传输层安全性 (TLS) 1.2
或更高版本 (通过 Azure 组件(例如应用程序网关或 Azure 前门) ),直接在 Azure 虚拟机上的协议 (例如
Windows IPsec 或 SMB) 等。
此外,"默认情况下使用 MACsec 加密" (在数据链路层上使用 IEEE standard) 为 Azure 数据中心之间的所有 Azure
流量启用此功能,以确保客户数据的机密性和完整性。

数据冗余 :出现网络攻击或者数据中心遭到物理损坏时,Microsoft 可帮助确保数据受到保护。 客户可以选择:

出于合规或延迟方面的考虑使用国内/区域内存储。
出于安全或灾难恢复目的使用国外/区域外存储。

数据可在选定的地理区域中进行复制以实现冗余,但不会传输到此区域以外。 客户可以使用多个选项来复制数
据,包括指定副本数量,以及复制数据中心的数量和位置。

创建存储帐户时,请选择以下复制选项之一:

本地冗余存 储 (LRS) : 本地冗余存储保留数据的三个副本。 LRS 会在单个区域的单个设施内复制三次。 LRS


可以保护数据免受普通的硬件故障损害,但无法保护数据免受单个设施故障的损害。
区域冗余存 储 (ZRS) :区域冗余存储保留数据的三个副本。 ZRS 在两到三个个设施之间复制三次,其持久性
比 LRS 更高。 复制在单个区域中或者在两个区域之间进行。 ZRS 帮助在单个区域内确保数据持久保存。
异地冗余存 储 (GRS) :创建存储帐户时,默认会为该存储帐户启用异地冗余存储。 GRS 维护数据的六个副
本。 使用 GRS 时,数据将在主要区域中复制三次。 数据还会在离主要区域数百英里的次要区域中复制三次,
从而提供最高级别的持久性。 当主要区域发生故障时,Azure 存储会故障转移到次要区域。 GRS 帮助在两个
不同的区域中确保数据持久保存。

数据 销 毁 :当客户删除数据或离开 Azure 时,Microsoft 会在重复使用之前遵循严格的规则覆盖存储资源,并对


已退役的硬件执行物理销毁。 在客户提出请求和合同终止时,Microsoft 会执行完全数据删除。

客户数据所有权
Microsoft 不会检查、审批或监视客户在 Azure 中部署的应用程序。 此外,Microsoft 不知道客户选择在 Azure 中
存储哪种类型的数据。 Microsoft 不会基于客户在 Azure 中输入的信息声索数据所有权。

记录管理
针对后端数据,Azure 已制定内部记录保留要求。 客户负责确定其自己的记录保留要求。 对于存储在 Azure 中的
记录,客户需负责提取其数据,并根据自己指定的保留期在 Azure 的外部保留内容。

Azure 可让客户从产品中导出数据和审核报告。 导出内容保存在本地,并根据客户定义的保留期保留信息。

电子发现
Azure 客户在使用 Azure 服务时需负责遵守电子发现要求。 如果 Azure 客户必须保留其客户数据,可在本地导出
并保存数据。 此外,客户可以请求从 Azure 客户支持部门导出其数据。 除了允许客户导出其数据以外,Azure 还
会在内部展开广泛的日志记录和监视。

后续步骤
若要详细了解 Microsoft 如何保护 Azure 基础结构,请参阅:

Azure 设施、场地和物理安全性
Azure 基础结构可用性
Azure 信息系统的组件和边界
Azure 网络体系结构
Azure 生产网络
Azure SQL 数据库安全功能
Azure 生产运营和管理
Azure 基础结构监视
Azure 基础结构完整性
平台完整性和安全性概述
2021/2/9 • • Edit Online

Azure 汽油包含数百万服务器 (主机) ,每日增加了上千个。 数千台主机还会通过重新启动、操作系统刷新或修复


日常维护。 在主机可以加入汽油并开始接受客户工作负荷之前,Microsoft 会验证该主机是否处于安全可信状
态。 此验证可确保在供应链或维护工作流期间启动序列组件上未发生恶意或无意的更改。

保护 Azure 硬件和固件
此系列文章介绍了 Microsoft 如何通过其生命周期中的各个阶段(从制造到日落)来确保主机的完整性和安全性。
文章讨论了:

固件安全性
UEFI 安全启动
标准启动和主机证明
项目 Cerberus
静态加密
虚拟机监控程序安全性

后续步骤
了解 Microsoft 如何积极地在云硬件生态系统中合作来驱动持续 固件安全改进。

了解云中责任分担。
固件安全性
2021/2/9 • • Edit Online

本文介绍 Microsoft 如何保护云硬件生态系统和提供链。

保护云硬件生态系统
Microsoft 积极在云硬件生态系统中的合作伙伴,通过以下方式驱动持续安全改进:
与 Azure 硬件和固件伙伴 (,如组件制造商和系统集成商) ,以满足 Azure 硬件和固件安全要求。

让合作伙伴可以在以下方面使用 Microsoft 定义的要求对其产品安全状况进行持续评估和改进:

固件安全启动
固件安全恢复
固件安全更新
固件加密
锁定的硬件
精细调试遥测
TPM 2.0 硬件的系统支持,用于启用标准启动
通过开发规范 (OCP) 安全项目,参与和贡献 开放式计算项目 。 规范提升了一致性和清晰度,以确保生态
系统中的安全设计和体系结构。

NOTE
我们对 OCP 安全项目的贡献示例是 硬件安全启动 规范。

保护硬件和固件供应链
还需要适用于 Azure 的云硬件供应商和供应商,以遵守供应链安全流程和 Microsoft 开发的要求。 需要硬件和固
件开发和部署过程才能遵循 Microsoft 安全开发生命周期 (SDL) 过程,例如:

威胁建模
安全设计评审
固件审查和渗透测试
保护生成和测试环境
安全漏洞管理和事件响应

后续步骤
若要详细了解如何驱动平台的完整性和安全性,请参阅:

安全启动
标准启动和主机证明
项目 Cerberus
静态加密
虚拟机监控程序安全性
安全启动
2021/2/9 • • Edit Online

安全启动是 统一可扩展固件接口 (UEFI) 的一项功能,需要在加载之前验证所有低级固件和软件组件。 在启动过


程中,UEFI 安全启动检查每个启动软件的签名,其中包括 UEFI 固件驱动程序 (也称为选项 Rom) 、可扩展固件接
口 (EFI) 应用程序以及操作系统驱动程序和二进制文件。 如果签名 (OEM) 的原始设备制造商有效或信任,则计算
机将启动,并且固件会向操作系统提供控制权。

组件和过程
安全引导依赖于以下关键组件:

平台键 (PK) -在平台所有者 (Microsoft) 和固件之间建立信任。 Public 一半是 PKpub,而 private 一半是
PKpriv。
密钥注册密钥数据库 (KEK) -在 OS 和平台固件之间建立信任。 Public 一半是 KEKpub,而 private 一半是
KEKpriv。
签名数据库 (db) -保存受信任签署者 (公钥和证书的摘要,这些摘要和证书) 授权与平台固件交互的固件和软
件模块。
已吊销的签名数据库 (.dbx) –持有已被识别为恶意、易受攻击、已泄露或不受信任的代码模块的摘要。 如果哈
希位于签名数据库和吊销的签名数据库中,则已吊销的签名数据库采用引用单元。

下图和进程说明了如何更新这些组件:

OEM 在生产时 (NV RAM) 在计算机的非易失性 RAM 上存储安全启动摘要。


1. 签名数据库 (db) 由 UEFI 应用程序、操作系统加载器 ((如 Microsoft 操作系统加载程序或启动管理器) )和受
信任的 UEFI 驱动程序的签名者或映像哈希填充。
2. 已吊销的签名数据库 (.dbx) 会用不再受信任的模块的摘要填充。
3. (KEK) 数据库的密钥注册密钥使用可用于更新签名数据库和吊销的签名数据库的签名密钥进行填充。 可以通
过使用正确的密钥签名的更新或通过使用固件菜单的实际授权用户进行更新来编辑数据库。
4. 添加 db、.dbx 和 KEK 数据库并完成最终固件验证和测试后,OEM 会锁定固件以进行编辑,并 (PK) 生成平台
密钥。 PK 可用于对 KEK 的更新进行签名,或关闭安全启动。

在启动过程中的每个阶段,将计算固件、启动程序、操作系统、内核驱动程序和其他启动链项目的摘要,并将其与
可接受的值进行比较。 不允许加载不受信任的固件和软件。 因此,可能会阻止低级恶意软件注入或预启动恶意
软件攻击。
在 Azure 汽油上安全启动
如今,载入并部署到用于托管客户工作负荷的 Azure 计算的每台计算机都是在启用了安全启动的工厂楼层中进
行的。 在硬件 ring 和集成管道中的每个阶段都有目标工具和过程,以确保不会因意外或恶意目的而恢复安全启
动。

验证 db 和 .dbx 摘要是否正确可确保:

加载项存在于其中一个 db 条目中
引导程序的签名有效
主机通过受信任的软件启动

验证 KEKpub 和 PKpub 的签名后,可以确认只有可信方有权修改被视为受信任的软件的定义。 最后,通过确保安


全启动处于活动状态,我们可以验证是否强制执行这些定义。

后续步骤
若要详细了解如何驱动平台的完整性和安全性,请参阅:

固件安全性
标准启动和主机证明
项目 Cerberus
静态加密
虚拟机监控程序安全性
标准启动和主机证明
2021/2/9 • • Edit Online

本文介绍 Microsoft 如何通过测量的启动和主机证明来确保主机的完整性和安全性。

标准引导
受信任的平台模块 (TPM) 是使用受信任的第三方提供的固件的防篡改加密安全审核组件。 启动配置日志包含其
平台配置注册中记录的哈希链接度量值 () 主机上一次启动序列时,将在该主机上注册。 下图显示了此录制过程。
以增量方式将以前的哈希度量值添加到下一个度量值的哈希,并在联合上运行哈希算法来完成哈希链。

当主机使用其启动配置日志 (TCGLog) 验证其配置状态时,将完成证明。 伪造启动日志是非常困难的,因为 TPM


不公开读取和扩展操作以外的 PCR 值。 而且,主机证明服务提供的凭据会密封到特定的 PCR 值。 使用哈希链使
其无法进行计算,以便在带外欺骗或解封凭据。

主机证明服务
主机证明服务是一种预防措施,在允许主机计算机与客户数据或工作负荷交互之前,检查主机是否可信。 主机证
明服务检查的方法是,通过验证符合性声明的主机的符合性声明 (可验证的主机的符合性证明) 安全状态) 的证明
策略 (定义。 TPM 提供的 信任根 提供此系统的完整性。

主机证明服务在专用锁定环境中的每个 Azure 群集中都存在。 锁定的环境包括参与主机启动协议的其他守卫服


务。 (PKI) 的公钥基础结构充当用于验证证明请求的 provenance 的中介,并作为标识颁发者 (在成功的主机证明)
时获得。 颁发给证明主机的后期证明凭据会密封为其标识。 只有发出请求的主机才能解封凭据并利用它们来获
取增量权限。 这可以防止中间人攻击和哄骗攻击。

如果 Azure 主机在工厂中由于安全配置错误或已被篡改,则其 TCGLog 包含在下一次证明时由主机证明服务标


记的折衷指标,这会导致证明失败。 证明失败会阻止 Azure 汽油信任有问题的主机。 此防护有效地阻止与主机
之间的所有通信,并触发事件工作流。 进行调查,并进行详细的事后分析来确定根本原因和任何可能的折衷迹
象。 仅在分析完成后,主机经过修正,并有机会加入 Azure 汽油并接管客户工作负荷。
下面是主机证明服务的高级体系结构:

证明度量
下面是今天捕获的许多度量值的示例。

安全启 动 和安全启 动 密 钥
通过验证签名数据库和吊销的签名数据库摘要是否正确,主机证明服务可确保客户端代理认为合适的软件是受
信任的。 通过验证公钥注册密钥数据库和公共平台密钥的签名,主机证明服务会确认只有可信方有权修改被视
为受信任的软件的定义。 最后,通过确保安全启动处于活动状态,主机证明服务会强制验证这些定义。

调试 控件
调试器是面向开发人员的强大工具。 但是,如果提供给不受信任的参与方,自由的内存和其他调试命令的访问可
能会降低数据保护和系统的完整性。 在生产计算机上启动时,主机证明服务可确保禁用任何类型的调试。

代 码 完整性
UEFI 安全启动 可以确保只有受信任的低级别软件可以在启动顺序中运行。 不过,相同的检查还必须在启动后环
境中应用到使用内核模式访问的驱动程序和其他可执行文件。 为此, (CI) 策略的代码完整性用于通过指定有效
和无效的签名来定义哪些驱动程序、二进制文件和其他可执行文件被视为受信任。 强制实施这些策略。 策略违
规会生成警报到安全事件响应团队进行调查。

后续步骤
若要详细了解如何驱动平台的完整性和安全性,请参阅:

固件安全性
安全启动
Cerberus 项目
静态加密
虚拟机监控程序安全性
项⽬ Cerberus
2021/2/9 • • Edit Online

Cerberus 是具有无法克隆的标识的 NIST 800-193 兼容硬件信任。 Cerberus 旨在进一步提高 Azure 基础结构的


安全状况,因为它提供了针对固件完整性的强大信任锚。

启用信任锚
每个 Cerberus 芯片都具有唯一的加密标识,该标识是使用) 的 Microsoft 证书颁发机构 (的签名证书链建立的。
从 Cerberus 获取的度量值可用于验证组件的完整性,如:

主机
基板管理控制器 (BMC)
所有外围设备,包括网络接口卡和 系统芯片 (SoC)

此信任锁定点可帮助保护平台固件:

平台上运行的已泄露固件二进制文件
利用操作系统、应用程序或虚拟机监控程序中的 bug 的恶意软件和黑客
某些类型的供应链攻击 (制造、组装、中转)
具有管理权限或访问硬件的恶意预览体验人员

Cerberus 证明
Cerberus 使用平台固件清单 (PFM) 为服务器组件的固件完整性进行身份验证。 PFM 定义授权固件版本的列表,
并向 Azure 主机证明服务提供平台度量。 主机证明服务验证度量,并做出决定,只允许受信任的主机加入 Azure
汽油并托管客户工作负荷。

与主机证明服务一起使用时,Cerberus 的功能增强并提升了高安全性的 Azure 生产基础结构。

NOTE
若要了解详细信息,请参阅 GitHub 上的 项目 Cerberus 信息。

后续步骤
若要详细了解如何驱动平台的完整性和安全性,请参阅:

固件安全性
安全启动
标准启动和主机证明
静态加密
虚拟机监控程序安全性
Azure 静态数据加密
2021/2/9 • • Edit Online

Microsoft Azure 提供了许多工具,可以使用它们根据你公司的安全性和合规性需求来保护数据。 本白皮书重点


介绍:

如何在 Microsoft Azure 上对数据进行静态保护


讨论参与数据保护实现的各个组件
查看不同密钥管理保护方法的优点和缺点。

静态加密是常见的安全要求。 在 Azure 中,组织可以加密静态数据,而不会造成自定义密钥管理解决方案的风险


或成本。 组织可以选择让 Azure 来全权管理静态加密。 另外,组织还可以通过各种选择来严格管理加密或加密
密钥。

什么是静态加密?
加密是用于保护数据机密性的数据的安全编码。 Azure 中的静态加密设计使用对称加密根据简单的概念模型来
快速加密和解密大量数据:

将使用对称加密密钥在将数据写入到存储时对数据进行加密。
当数据在内存中就绪可供使用时,将会使用同一加密密钥来解密该数据。
可以将数据分区,并可对每个分区使用不同的密钥。
必须将密钥存储在实施了基于标识的访问控制和审核策略的安全位置。 数据加密密钥通常由 Azure Key Vault
中的密钥加密密钥进行加密,以进一步限制访问。

在实践中,密钥管理和控制方案以及规模和可用性保证都需要其他构造。 下面描述的是 Microsoft Azure 静态加


密概念和组件。

静态加密的目的
静态加密为已存储的数据(静止的)提供数据保护。 对静态数据进行的攻击包括:试图获得存储数据的硬件的物理
访问机会,然后盗用其中包含的数据。 发生此类攻击可能是由于服务器的硬盘驱动器在维护过程中处理不当,导
致攻击者有机会拆除硬盘驱动器。 攻击者随后会将该硬盘驱动器置于受其控制的计算机中,尝试访问相关数据。

静态加密旨在防止攻击者访问未加密的数据,其方法是确保这些数据在磁盘上时是加密的。 如果攻击者获取了
包含加密数据的硬盘驱动器但未获取加密密钥,则攻击者必须破解加密才能读取数据。 这种攻击比访问硬盘驱
动器上的未加密数据要复杂得多,且消耗的资源也多得多。 因此,强烈建议使用静态加密。对于许多组织来说,
这是需要完成的高优先级事项。

当组织需要进行数据治理并确保符合性时,可能也需要使用静态加密。 行业和政府法规(例如 HIPAA、PCI 和


FedRAMP)就数据保护和加密要求制定了具体的保障措施。 要符合这其中的许多法规,静态加密是一种必需的强
制措施。 有关 Microsoft 的 FIPS 140-2 验证方法的详细信息,请参阅美国联邦信息处理标准 (FIPS) 出版物 140-
2。
除了满足合规要求以外,静态加密还能提供深层防御保护。 Microsoft Azure 为服务、应用程序和数据提供合规的
平台。 此外,它还提供综合性的设施和物理安全性、数据访问控制和审核。 但是,必须提供额外的“重叠性”安全
措施,以免出现其他某个安全措施失效的情况,而静态加密正好提供这样一道安全措施。

Microsoft 致力于提供跨云服务的静态加密选项,可让客户控制加密密钥和密钥使用日志。 另外,Microsoft 正在


努力实现默认加密所有客户静态数据。
Azure 静态加密组件
如前所述,静态加密的目标是使用机密加密密钥来加密持久保存在磁盘上的数据。 若要实现该目标,必须为加密
密钥提供安全的密钥创建、存储、访问控制和管理措施。 可以使用下图中介绍的术语来描述 Azure 服务静态加密
实现,虽然细节可能有所不同。

Azure Key Vault


对于静态加密模型来说,最重要的是加密密钥的存储位置以及对这些密钥的访问控制。 密钥需要严格的保护,但
同时又要能够由指定的用户进行管理,并可供特定的服务使用。 对于 Azure 服务,建议使用 Azure Key Vault 作
为密钥存储解决方案,它可以跨服务提供通常的管理体验。 密钥在密钥保管库中存储和管理,对密钥保管库的访
问权限可以提供给用户或服务。 Azure Key Vault 支持客户创建密钥,也支持将导入的客户密钥用于客户管理的
加密密钥方案。

Azure Active Directory


可以为 Azure Active Directory 帐户提供存储在 Azure Key Vault 中的密钥的使用权限,以便通过管理或访问这些
密钥来完成静态加密的加密和解密操作。

密 钥层 次 结 构
在实施静态加密时,使用多个加密密钥。 将加密密钥存储在 Azure Key Vault 中可确保安全的密钥访问并可集中
管理密钥。 但是,就批量加密和解密来说,通过服务在本地访问加密密钥比每项数据操作都要与 Key Vault 交互
更为高效,可以提高加密强度和性能。 限制单个加密密钥的使用降低了密钥被盗用的风险,也降低了必须更换密
钥时的重新加密成本。 Azure 静态加密模块使用一个密钥层次结构来解决所有这些需求,该密钥层次结构由以下
类型的密钥构成:

(DEK) 的数据加密密 钥 –用于对分区或数据块进行加密的对称 AES256 密钥。 单个资源可能有多个分区和多


个数据加密密钥。 使用不同的密钥加密每个数据块可以增加加密分析攻击的难度。 资源提供程序或应用程序
实例需要 DEK 访问权限才能加密和解密特定的块。 将 DEK 替换为新密钥时,仅其关联的块中的数据需要使
用新密钥重新加密。
密 钥 加密密 钥(KEK) –用于对数据加密密钥进行加密的加密密钥。 使用从不离开 Key Vault 的密钥加密密钥
可以加密和控制数据加密密钥本身。 具有 KEK 访问权限的实体可能不同于需要 DEK 的实体。 实体可能会代
理对 DEK 的访问以将每个 DEK 的访问限制到特定分区。 由于解密 DEK 需要 KEK,因此 KEK 实际上构成了一
个单点机制:删除 KEK 即可删除 DEK。

使用密钥加密密钥加密的数据加密密钥将单独进行存储,只有能够访问密钥加密密钥的实体才能解密这些数据
加密密钥。 支持各种不同的密钥存储模型。 有关详细信息,请参阅数据加密模型。

Microsoft 云服务中的静态加密
Microsoft 云服务用于下述所有三个云模型:IaaS 、PaaS 、SaaS 。 下面是在每个模型上使用该服务的示例:
软件服务,也称软件即服务(简称 SaaS ),它包含云提供的应用程序,例如 Microsoft 365 。
平台服务,方便客户在其应用程序中利用云,将云用于存储、分析和服务总线功能等。
基础结构服务,也称基础结构即服务 (IaaS),方便客户部署托管在云中的操作系统和应用程序,并尽可能利用
其他云服务。

适合SaaS 客 户 的静 态 加密
软件即服务 (SaaS) 客户通常会在每个服务中启用或提供静态加密。 Microsoft 365 为客户提供多个选项来验证
或启用静态加密。 若要了解 Microsoft 365 服务,请参阅 Microsoft 365 中的加密。

适合PaaS 客 户 的静 态 加密
平台即服务 (PaaS) 客户的数据通常驻留在存储服务(例如 Blob 存储)中,但也可以缓存或存储在应用程序执行环
境(例如虚拟机)中。 若要查看适用的静态加密选项,请检查下表中是否存在所用的存储和应用程序平台。

适合 IaaS 客 户 的静 态 加密
基础结构即服务 (IaaS) 客户可以使用各种服务和应用程序。 IaaS 服务可以在其 Azure 托管的虚拟机和 VHD 中通
过 Azure 磁盘加密来启用静态加密。

加密的存 储

与 PaaS 一样,IaaS 解决方案可以利用其他存储静态加密数据的 Azure 服务。 在此类情况下,可以启用每个所用


Azure 服务提供的静态加密支持。 下表枚举了主要的存储、服务和应用程序平台以及所支持的静态加密模型。
加密的 计 算

所有托管磁盘、快照和映像都通过服务管理的密钥使用存储服务加密进行加密。 更完整的静态加密解决方案可
确保数据从不以未加密形式持久保存。 在虚拟机上处理数据时,可以将数据持久保存到 Windows 页面文件或
Linux 交换文件、故障转储或应用程序日志。 为了确保对该数据进行静态加密,IaaS 应用程序可以在 Azure IaaS
虚拟机(Windows 或 Linux)和虚拟磁盘上使用 Azure 磁盘加密。

自定 义 静 态 加密

建议让 IaaS 应用程序尽可能利用 Azure 磁盘加密以及任何所用 Azure 服务提供的静态加密选项。 在某些情况下


(例如加密要求异乎寻常,或者存储不是基于 Azure 的),IaaS 应用程序开发人员可能需要自行实施静态加密。
IaaS 解决方案开发人员可以利用某些 Azure 组件,改进与 Azure 管理的集成并更好地满足客户期望。 具体说来,
开发人员应该使用 Azure Key Vault 服务为其客户提供安全的密钥存储,以及提供与大多数 Azure 平台服务一致
的密钥管理选项。 另外,自定义解决方案应通过 Azure 托管服务标识来允许服务帐户访问加密密钥。 有关 Azure
Key Vault 和托管服务标识的开发人员信息,请参阅各自的 SDK。

Azure 资源提供程序加密模型支持
每个 Microsoft Azure 服务都支持一个或多个静态加密模型。 但是,对于某些服务来说,其中的一个或多个加密
模型可能并不适用。 对于支持客户管理的密钥方案的服务,它们可能只支持 Azure Key Vault 支持用于密钥加密
密钥的密钥类型的一个子集。 另外,服务可能会按不同的计划发布对这些方案和密钥类型的支持。 此部分介绍
的静态加密支持在撰写本文时仍适用于每个主要的 Azure 数据存储服务。

Azure 磁 盘 加密
任何使用 Azure 基础结构即服务 (IaaS) 功能的客户都可以通过 Azure 磁盘加密为其 IaaS VM 和磁盘实施静态加
密。 有关 Azure 磁盘加密的详细信息,请参阅 Azure 磁盘加密文档。

Azure 存 储
所有 Azure 存储服务(Blob 存储、队列存储、表存储和 Azure 文件存储)均支持静态服务器端加密,其中某些服务
额外支持客户管理的密钥和客户端加密。

服务器端:默认情况下,所有 Azure 存储服务都使用服务托管的密钥来启用服务器端加密(对应用程序而言是


透明的)。 有关详细信息,请参阅静态数据的 Azure 存储服务加密。 Azure Blob 存储和 Azure 文件也支持
Azure Key Vault 中客户托管的 RSA 2048 位密钥。 有关详细信息,请参阅 Azure Key Vault 中使用客户托管密
钥的存储服务加密。
客户端:Azure Blob、表和队列支持客户端加密。 使用客户端加密时,客户会加密数据并将数据作为加密的
blob 上传。 密钥管理由客户执行。 有关详细信息,请参阅 Microsoft Azure 存储的客户端加密和 Azure Key
Vault。
Azure SQL 数据 库
Azure SQL 数据库目前支持将静态加密用于 Microsoft 托管的服务器端和客户端加密方案。
对服务器加密的支持目前通过名为“透明数据加密”的 SQL 功能来提供。 在 Azure SQL 数据库客户启用 TDE 后,
系统会自动为其创建和管理密钥。 可以在数据库和服务器级别启用静态加密。 从 2017 年 6 月开始,会在新创建
的数据库上默认启用透明数据加密 (TDE)。 Azure SQL 数据库支持 Azure Key Vault 中客户管理的 RSA 2048 位密
钥。 有关详细信息,请参阅使用 Azure SQL 数据库和数据仓库的“创建自己的密钥”支持进行透明数据加密。

可以通过 Always Encrypted 功能启用对 Azure SQL 数据库数据的客户端加密。 Always Encrypted 使用由客户端
创建和存储的密钥。 客户可以将主密钥存储在 Windows 证书存储、Azure Key Vault 或本地硬件安全模块中。 使
用 SQL Server Management Studio 时,SQL 用户可以选择想要使用什么密钥来加密哪个列。

结论
保护存储在 Azure 服务中的客户数据对于 Microsoft 来说至关重要。 所有 Azure 托管服务都会始终提供静态加
密选项。 Azure 服务支持服务管理的密钥、客户管理的密钥或客户端加密。 Azure 服务正在大范围地增强静态加
密的可用性,计划在将来数月中推出新功能的预览版和公开发行版。

后续步骤
若要详细了解服务管理的密钥和客户管理的密钥,请参阅数据加密模型。
了解 Azure 如何使用双重加密来缓解加密数据所带来的威胁。
了解 Microsoft 如何确保主机遍历硬件和固件构建、集成、操作化和维修管道的 完整性和安全性 。
Azure 汽油上的虚拟机监控程序安全性
2021/2/9 • • Edit Online

Azure 虚拟机监控程序系统基于 Windows Hyper-v。 虚拟机监控程序系统使计算机管理员可以指定具有不同地


址空间的来宾分区。 使用单独的地址空间,可以加载在计算机的根分区中执行的操作系统和应用程序并行运行
(主机) 。 主机操作系统 (也称为特权根分区) 可以直接访问系统 (存储控制器、网络 adaptions) 上的所有物理设备
和外围设备。 通过向每个来宾分区公开 "虚拟设备",主机操作系统允许来宾分区共享这些物理设备的使用。 因
此,在来宾分区中执行的操作系统有权访问在根分区中执行的虚拟化服务提供的虚拟化外围设备。

Azure 虚拟机监控程序的构建目的是考虑以下安全目标:

隔离 安全策略不要求在 Vm 之间传输信息。 此约束要求 Virtual


Machine Manager (VMM) 和硬件中的功能,以便隔离内存、
设备、网络和托管资源(如持久化数据)。

VMM 完整性 为了实现整体系统完整性,将建立和维护各个虚拟机监控程


序组件的完整性。

平台完整性 虚拟机监控程序的完整性取决于它所依赖的硬件和软件的完
整性。 尽管虚拟机监控程序无法直接控制平台的完整性,但
Azure 依赖于硬件和固件机制(如 Cerberus 芯片)来保护和检
测底层平台完整性。 如果平台完整性受到危害,则会阻止
VMM 和来宾运行。

受限访问 只有通过安全连接进行连接的授权管理员才能执行管理功
能。 最小特权原则由 Azure 基于角色的访问控制 (Azure
RBAC) 机制强制实施。

审核 Azure 允许审核功能捕获和保护有关系统上发生的情况的数
据,以便以后可以对其进行检查。

Microsoft 对 Azure 虚拟机监控程序和虚拟化子系统进行强化的方法可分为以下三个类别。

虚拟机监控程序强制实施的强定义安全边界
Azure 虚拟机监控程序强制执行以下两个安全边界:
虚拟化的 "来宾" 分区和特权分区 ( "主机" )
多个来宾
本身和主机
本身和所有来宾

为虚拟机监控程序安全边界保证机密性、完整性和可用性。 边界防御各种攻击,包括侧通道信息泄露、拒绝服务
和特权提升。

虚拟机监控程序安全边界还为网络流量、虚拟设备、存储、计算资源和所有其他 VM 资源提供租户之间的分段。

深层防御攻击缓解
在极少数情况下,安全边界有一个漏洞,Azure 虚拟机监控程序包括多个缓解层,包括:
隔离承载跨虚拟机组件的基于主机的进程
基于虚拟化的安全 (VBS) ,确保用户和内核模式组件在安全世界中的完整性
多个攻击级别。 缓解措施包括地址空间布局随机化 (ASLR) ,数据执行保护 (DEP) ,任意代码防护,控制流完
整性和数据损坏防护
在编译器级别自动初始化堆栈变量
自动初始化 Hyper-v 所进行的内核堆分配的内核 Api

这些缓解旨在使利用跨 VM 漏洞的攻击成为不可行的。

强大的安全保障过程
与虚拟机监控程序相关的攻击面包括软件网络、虚拟设备和所有跨虚拟机表面。 攻击面通过自动生成集成进行
跟踪,这会触发定期的安全检查。

所有 VM 攻击面都是威胁建模、代码审查、模糊,并由我们的红色团队测试安全边界违规。 Microsoft 有一个 bug


奖励计划 ,该程序针对 Microsoft Hyper-V 的合格产品版本中的相关漏洞支付奖励。

NOTE
了解有关 Hyper-v 中的 强大安全保障流程 的详细信息。

后续步骤
若要详细了解如何驱动平台的完整性和安全性,请参阅:

固件安全性
安全启动
标准启动和主机证明
Cerberus 项目
静态加密
Azure 公有云中的隔离
2021/2/9 • • Edit Online

可以通过 Azure 在共享的物理基础结构上运行应用程序和虚拟机 (VM)。 在云环境中运行应用程序的一个主要经


济动机是可由多个客户分摊共享资源的成本。 这种多租户的做法在不同客户间多路复用资源,提高了效率并降
低了成本。 遗憾的是,这种做法也带来了风险,会导致通过共享物理服务器和其他基础结构资源来运行敏感应用
程序和 VM,而这些 VM 可能属于任意或潜在恶意用户。

本文概述了 Azure 以何种方式同时针对恶意和非恶意用户提供隔离,并向架构师提供了多种隔离选项,指导他们


构建云解决方案。

租户级别隔离
云计算的一个主要优势是同时跨多位客户使用共享的通用基础结构的概念,可带来规模效益。 这种概念称为多
租户。 Microsoft 始终致力于确保 Microsoft Cloud Azure 的多租户体系结构支持安全、保密性、隐私、完整性和
可用性标准。

在启用云的工作区中,可以将“租户”定义为拥有并管理该云服务的特定实例的客户端或组织。 使用 Microsoft
Azure 提供的标识平台,租户只是组织在注册 Microsoft 云服务时接收并拥有的 Azure Active Directory (Azure
AD) 专用实例。
每个 Azure AD 目录都是独特的,独立于其他 Azure AD 目录。 就像公司办公大楼是组织特有的安全资产一样,根
据设计,Azure AD 目录也是仅供组织使用的安全资产。 Azure AD 体系结构隔离了客户数据和身份信息,避免混
合存放。 这意味着,一个 Azure AD 目录的用户和管理员不可能意外或恶意性地访问另一目录中的数据。

Azure 租 户
Azure 租户(Azure 订阅)是指 Azure Active Directory 中的“客户/账单”关系和唯一的租户。 Microsoft Azure 中的
租户级隔离使用 Azure Active Directory 和 Azure 提供的 基于角色的访问控制 实现。 每个 Azure 订阅都会与一
个 Azure Active Directory (AD) 目录关联。

该目录中的用户、组和应用程序可以管理 Azure 订阅中的资源。 可以使用 Azure 门户、Azure 命令行工具及


Azure 管理 API 来分配这些访问权限。 从逻辑上讲,Azure AD 租户是使用安全边界隔离的,这样,任何客户都不
能访问或入侵联合租户,而无论其行为是恶意的还是偶然的。 在“裸机”服务器上运行的 Azure AD 是在分隔的网
络段中隔离的,主机级别数据包筛选和 Windows 防火墙在该网络段中阻止不需要的连接和流量。

访问 Azure AD 中的数据需要通过安全令牌服务 (STS) 进行用户身份验证。 授权系统使用有关用户存在性、已


启用状态和角色的信息,确定此用户在此会话中对目标租户的访问请求是否已获授权。
租户是离散的容器,它们之间没有任何关系。

除非租户管理员通过联合身份验证或预配来自其他租户的用户帐户授予访问权限,否则不允许跨租户访
问。

限制了对危及 Azure AD 服务的服务器的物理访问,以及对 Azure 后端系统的直接访问。

Azure AD 用户无权访问物理资产或位置,因此,他们不可能跳过以下所述的逻辑 Azure RBAC 策略检查。


为了满足诊断和维护需求,需要使用采用实时特权提升系统的操作模型。 Azure AD Privileged Identity
Management (PIM) 引入了有资格管理员的概念。有资格管理员应是不时(但不是每天)需要特权访问的用户。 该
角色处于非活动状态,直到用户需要访问权限,然后他们完成激活过程,并在预定的时间内成为活动管理员。

Azure Active Directory 在其自己受保护的容器中托管每个租户,使用的策略和权限针对各租户单独拥有和管理


的容器,并保存在该容器内。

从门户一直到永久性存储,租户容器的概念深入贯彻于目录服务的每一层。

即使多个 Azure Active Directory 租户的元数据存储在同一个物理磁盘中,除目录服务定义的容器外,各容器之


间仍没有任何关系,而目录服务是由租户管理员指定的。

Azure 基于角色的 访问 控制 (Azure RBAC )


Azure 基于角色的访问控制 (Azure RBAC) 提供针对 Azure 的精细访问权限管理,有助于共享 Azure 订阅中提供
的各种组件。 借助 Azure RBAC,可分隔组织内的职责,并根据用户进行作业的需求授予访问权限。 可以仅允许
某些操作,而不是向每个人提供对 Azure 订阅或资源不受限制的权限。

Azure RBAC 有三种适用于所有资源类型的基本角色:


所有者 对所有资源具有完全访问权限,包括将访问权限委派给其他用户的权限。

参与者 可以创建和管理所有类型的 Azure 资源,但不能将访问权限授予其他用户。

读 者 可以查看现有的 Azure 资源。

可以通过 Azure 中的其他 Azure 角色对特定的 Azure 资源进行管理。 例如,虚拟机参与者角色允许用户创建和


管理虚拟机。 但不会向用户授予对虚拟机连接的 Azure 虚拟网络或子网的访问权限。

Azure 内置角色 列出了 azure 中可用的角色。 它指定每个内置角色向用户授予的操作和范围。 若要定义自己的


角色以便进一步控制,请参阅如何生成 Azure RBAC 中的自定义角色。

Azure Active Directory 的其他部分功能包括:


使用 Azure AD 即可对 SaaS 应用程序启用 SSO,不管这些应用程序在何处托管。 某些应用程序会与
Azure AD 联合起来进行身份验证,其他应用程序则使用密码 SSO。 联合应用程序还可以支持用户预配
和密码存储。

对 Azure 存储中的数据进行访问可以通过身份验证来控制。 每个存储帐户都有一个主密钥(存储帐户密


钥,简称 SAK)和一个辅助密钥(共享访问签名,简称 SAS )。

Azure AD 通过联合身份验证(使用 Active Directory 联合身份验证服务)、同步以及本地目录复制方式提供


标识即服务。

Azure AD 多重身份验证 是多因素身份验证服务,它要求用户使用移动应用、电话呼叫或短信验证登录。


它可以与 Azure AD 配合使用,帮助通过 Azure 多重身份验证服务器来保护本地资源;它还用于使用 SDK
的自定义应用程序和目录。

Azure AD 域服务可让用户将 Azure 虚拟机加入一个 Active Directory 域,且无需部署域控制器。 用户可以


使用其公司的 Active Directory 凭据登录到这些虚拟机中,并使用组策略管理已加入域的虚拟机,以便在
所有 Azure 虚拟机上强制实施安全基准措施。

Azure Active Directory B2C 提供高度可用的全局性标识管理服务,该服务适用于面向用户且可通过缩放


来处理数以亿计的标识的应用程序。 它可以跨移动平台和 Web 平台进行集成。 使用者只需使用现有社交
帐户或创建凭据,即可通过可自定义的体验登录到所有应用程序。

与 Microsoft 管理 员 和数据 删 除隔离


Microsoft 采取强硬措施保护数据免受不适当的访问或未经授权的用户使用。 这些操作过程和控制由联机服务条
款提供支持,该条款提供有关管理数据访问权限的合同承诺。

Microsoft 工程师没有访问云端数据的默认权限。 而是在必要时在管理监督下获取访问权限。 将谨慎控制并


记录该访问权限,并在不再需要时撤回。
Microsoft 可能雇佣其他公司代表其提供有限的服务。 分包商访问客户数据可能只是为了提供服务,这些服务
是 Microsoft 雇佣他们来提供的,并且 Microsoft 禁止他们将这些数据用于其他用途。 此外,受合同限制,他
们必须维护客户信息的机密性。

对于经过审核认证(如 ISO/IEC 27001 )的企业服务,Microsoft 和认证审核公司会定期进行验证,仅出于合法的商


业目的对这些服务访问的资产执行样本审计。 用户始终都可随时访问自己的客户数据,而不论出于什么原因。

如果用户删除了任何数据,Microsoft Azure 也将删除该数据,包括所有缓存或备份副本。 对于范围内服务,该删


除操作会在保留期结束后 90 天内进行。 (联机服务条款的数据处理条款部分对范围内服务进行了定义。)

如果用于存储的磁盘驱动器发生硬件故障,在 Microsoft 将其送回给制造商进行更换或修复前,将安全擦除或销


毁该磁盘驱动器上的数据。 驱动器上的数据会被覆盖,以确保无法通过任何方式恢复数据。

计算隔离
Microsoft Azure 提供各种基于云的计算服务,包括大量计算实例和服务,它们可根据应用程序或企业的需求自
动扩展和缩减。 这些计算实例和服务提供多个级别的隔离来保护数据,且不会降低客户所需配置的灵活性。

独立虚 拟 机大小
Azure 计算提供独立于特定硬件类型并专用于单个客户的虚拟机大小。 独立大小在特定的硬件生成上有效并运
行,当硬件生成失效时,将弃用。

独立的虚拟机大小最适合于由于满足符合性和法规要求等原因而需要与其他客户的工作负载高度隔离的工作负
载。 使用独立大小可保证你的虚拟机将是在特定服务器实例上唯一运行的虚拟机。

另外,由于独立大小的 VM 很大,客户可以选择使用 对嵌套虚拟机的 Azure 支持来细分这些 VM 的资源。

当前的独立虚拟机产品/服务包括:

Standard_E64is_v3
Standard_E64i_v3
Standard_E80ids_v4
Standard_E80is_v4
Standard_M128ms
Standard_GS5
Standard_G5
Standard_F72s_v2

NOTE
独立的 VM 大小具有有限的硬件寿命。 详情请参阅下文

弃用独立的 VM 大小
由于独立的 VM 大小是硬件绑定的大小,Azure 将在正式弃用这些大小之前 12 个月提供提醒。 Azure 还将为我
们的下一个硬件版本提供已更新的独立大小,客户可以考虑将其工作负载转移到该版本上。

Standard_DS15_v21 2020 年 5 月 15 日

Standard_D15_v21 2020 年 5 月 15 日

1 有关 Standard_DS15_v2 和 Standard_D15_v2 隔离停用计划的详细信息,请参阅常见问题解答

常见问题解答
问 :是要停用大小 还 是只停用 “隔离 ”功能?
答 :如果虚拟机大小没有“i”下标,则只有“隔离”功能将失效。 如果不需要隔离,则不需要执行任何操作,VM 将继
续按预期工作。 例如 Standard_DS15_v2 、Standard_D15_v2 、Standard_M128ms 等。如果虚拟机大小包括“i”下
标,那么该大小将被停用。

问 :当我的虚 拟 机落脚于非隔离的硬件上 时 ,是否会出 现 停机?


答 :如果不需要隔离,就不需要采取任何行动,也不会有停机时间。

问 :迁移到非独立的虚 拟 机是否有成本增量?
答 :否

问 :其他独立大小将于何 时 停用?
答 :我们将提前 12 个月进行提醒,以防官方弃用孤立的大小。

问 :我是依 赖 于白 银 或黄金耐久性 层级 的 Azure Service Fabric 客 户 。 此更改是否会影响我?


答 :否。 Service Fabric 的耐久性层级提供的保证即使在此更改发生后也将继续履行。 如果你出于其他原因而需
要物理硬件隔离,可能仍需采取上述措施之一。

问: D15_v2 或 DS15_v2 隔离停用的里程碑有哪些?


A:

2019 年 11 月 18 日 (PAYG,1年 RI 的 DS15i_v2 可用性)

5月14日2020 第一天购买 D/DS15i_v2 1 年 RI

2020 年 5 月 15 日 删除了 D/DS15_v2 隔离保障

5月15日2021 (所有客户(在) 2019 年11月18日之前购买了第3年 DS15_v2


的第3年 DS15i_v2

2022年11月17日 当在2019年11月18日之前购买 DS15_v2 了3年版的第3年 RI


的客户 (,在完成了3年的 RIs 后,停用了 D/DS15i_v2)

后续步骤
客户还可以选择利用对嵌套虚拟机的 Azure 支持,对这些独立的虚拟机资源进一步细分。

专 用主机
除了前面部分所述的独立主机以外,Azure 还提供了专用主机。 Azure 中的专用主机是一项服务,它提供能够承
载一个或多个虚拟机的物理服务器,专用于单个 Azure 订阅。 专用主机在物理服务器级别提供硬件隔离。 不会
在你的主机上放置任何其他 VM。 专用主机部署在相同的数据中心,与其他非隔离主机共享相同的网络和底层存
储基础结构。 有关详细信息,请参阅 Azure 专用主机的详细概述。

根 VM 和来 宾 VM 之 间 的 Hyper-V 和根 OS 隔离
Azure 的计算平台以计算机虚拟化为基础,这意味着所有客户代码都在 Hyper-V 虚拟机中执行。 在每个 Azure 节
点(或网络终结点)上,都有一个虚拟机监控程序在硬件上直接运行,并将节点分为数目不定的来宾虚拟机 (VM)。

每个节点还有一个特殊的根 VM,用于运行主机 OS 。 关键边界由虚拟机监控程序和根 OS 管理,用于将根 VM 与


来宾 VM 隔离,以及将各来宾 VM 彼此隔离。 虚拟机监控程序/根 OS 配对充分利用 Microsoft 在操作系统安全性
方面的数十年经验以及来自 Hyper-V 的最新信息,实现了各来宾 VM 之间的强大隔离。

Azure 平台使用虚拟化的环境。 用户实例作为无法访问物理主机服务器的独立虚拟机运行。


Azure 的虚拟机监控程序相当于微内核,可将所有硬件访问请求从来宾虚拟机传递到主机,以便使用名为 VMBus
的共享内存界面进行处理。 这样可以防止用户获取对系统的原始读取/写入/执行访问权限,减轻共享系统资源的
风险。

高级VM 布局算法和 侧 信道攻 击 防 护


任何跨 VM 攻击都包括两个步骤:在同一主机上放置一个攻击者控制的 VM 作为牺牲品 VM 之一,并破坏隔离边
界以窃取敏感的牺牲品信息,或者故意或因贪婪影响其性能。 Microsoft Azure 通过使用高级 VM 布局算法同时
针对这两个步骤提供保护,并防止所有已知侧信道攻击,包括干扰性邻居 VM。

Azure 结 构控制器
Azure 结构控制器负责将基础结构资源分配到租户工作负荷,并管理从主机到虚拟机的单向通信。 Azure 结构控
制器的 VM 布局算法高度复杂,并且作为物理主机级别几乎不可能预测。
Azure 虚拟机监控程序会在虚拟机之间强制实施内存和流程的隔离,并通过安全方式将网络流量路由到来宾 OS
租户。 这样可以避免 VM 级别的侧信道攻击。

在 Azure 中,根 VM 是特殊的:它运行称为根 OS 的强化操作系统,并托管了结构代理 (FA) 。 而 FA 又用于管理客


户 VM 上来宾操作系统内的来宾代理 (GA)。 FA 还可管理存储节点。

Azure 虚拟机监控程序、根 OS/FA 和客户 VM/GA 的集合包含一个计算节点。 FA 由结构控制器 (FC) 托管,位于


计算节点和存储节点外部(计算和存储群集由单独的 FC 托管)。 如果客户在运行应用程序的同时更新其配置文
件,FC 将与 FA 进行通信,然后 FA 将联系 GA,通知应用程序配置已更改。 出现硬件故障时,FC 会自动查找可用
硬件并在该处重启 VM。

结构控制器到代理的通信是单向的。 代理实施受 SSL 保护的服务,仅响应来自控制器的请求。 它不能发起与控


制器或其他特权内部节点的连接。 FC 将处理所有响应,就像是它们不受信任一样。
扩展了根 VM 与来宾 VM,以及来宾 VM 之间的隔离。 计算节点也独立于存储阶段,可增强保护。

虚拟机监控程序和主机 OS 提供了网络数据包筛选器,可帮助确保不受信任的虚拟机无法产生欺骗性流量或接
收并非发送给它们的流量,也无法将流量定向到受保护的基础结构终结点,或发送/接收不适当的广播流量。

结 构控制器代理 为 隔离 VM 而配置的其他 规则
默认情况下,在创建虚拟机时,会阻止所有流量,结构控制器代理会配置数据包筛选器,添加规则和例外以允许
经授权的流量。

进行编程的规则有两类:

计 算机配置或基 础结 构 规则 : 默认情况下,将阻止所有通信。 在例外情况下,可以允许虚拟机发送和接收


DHCP 和 DNS 流量。 虚拟机还可以将流量发送到“公共”Internet 以及同一 Azure 虚拟网络和 OS 激活服务器
内的其他虚拟机。 虚拟机的传出目标允许列表不包括 Azure 路由器子网、Azure 管理以及其他 Microsoft 属
性。
角色配置文件: 根据租户的服务模型定义入站访问控制列表 (ACL)。

VLAN 隔离
每个群集中有三个 VLAN:
主 VLAN – 互连不受信任的客户节点
FC VLAN – 包含受信任的 FC 及支持的系统
设备 VLAN – 包含受信任的网络和其他基础结构设备

允许从 FC VLAN 到主 VLAN 的通信,但不能启动从主 VLAN 到 FC VLAN 的通信。 还会阻止从主 VLAN 到设备
VLAN 的通信。 这可确保即使运行客户代码的节点遭到破坏, FC 或设备 VLAN 上的节点也不会受到攻击。

存储隔离
计 算和存 储 之 间 的 逻辑 隔离
作为其基本设计的一部分,Microsoft Azure 将基于 VM 的计算与存储分隔开。 这种分隔可实现计算和存储的自
主扩展,使提供多租户和隔离变得更简单。

因此,Azure 存储在单独的硬件上运行,且没有与 Azure 计算建立网络连接,从逻辑上讲时例外。 这意味着,创建


虚拟磁盘后,不会针对整体容量分配磁盘空间。 而是会创建一个表格,用于将虚拟磁盘上的地址映射到物理磁盘
上的区域中,且该表最初为空。 客 户 首次在虚 拟 磁 盘 上写入数据 时 ,将分配物理磁 盘 上的空 间 ,且指向它的
指 针 将位于表中。

使用存 储访问 控制的隔离


Azure 存 储 中的 访问 控制 具有简单的访问控制模型。 每个 Azure 订阅都可以创建一个或多个存储帐户。 每个
存储帐户都具有一个密钥,用于控制对该存储帐户中所有数据的访问权限。
可以通过 SAS (共享访问签名)令牌来控制 对 Azure 存 储 数据(包括表)的 访问权 限 ,该令牌可授予限定的访问
权限。 SAS 是根据查询模板 (URL) 创建的,且使用 SAK(存储帐户密钥)进行签名。 可以将该签名 URL 提供给另
一个进程(即委托进程),后者随后可以填充查询的详细信息并发出存储服务请求。 使用 SAS ,可以向客户端授予
基于时间的访问权限,无需泄露存储帐户的密钥。

使用 SAS ,意味着可以授权客户端在指定时间段内,以一组指定权限有限访问存储帐户中的对象。 可以授予这些


有限的权限,而不必共享帐户访问密钥。

IP 级别 存 储 隔离
可以为受信任客户端建立防火墙,定义 IP 地址范围。 使用 IP 地址范围,只有 IP 地址在定义范围内的客户端才可
以连接到 Azure 存储。

可通过网络机制防止未经授权的用户访问 IP 存储数据,该机制用于分配到 IP 存储的专用流量或专用流量隧道。

Encryption
Azure 提供了以下加密类型来保护数据:
传输中加密
静态加密

传输 中加密

传输中加密是通过网络传输数据时用于保护数据的机制。 在 Azure 存储中,可以使用以下加密方式来保护数据:

传输级别加密,例如从 Azure 存储传入或传出数据时使用的 HTTPS 。


线路加密,例如 Azure 文件共享的 SMB 3.0 加密。
客户端加密,在将数据传输到存储之前加密数据,以及从存储传出数据后解密数据。

静 态 加密

对许多组织而言, 静态数据加密 是实现数据隐私性、合规性和数据所有权的必要措施。 有三项 Azure 功能可提


供“静态”数据加密:

存储服务加密可以请求存储服务在将数据写入 Azure 存储时自动加密数据。


客户端加密 也提供静态加密功能。
Azure 磁盘加密 允许加密 IaaS 虚拟机使用的 OS 磁盘和数据磁盘。
Azure 磁 盘 加密
适用于虚拟机 (VM) 的 Azure 磁盘加密通过使用 Azure Key Vault 中控制的密钥和策略加密 VM 磁盘(包括引导磁
盘和数据磁盘),帮助解决企业的安全和符合性要求。

适用于 Windows 的磁盘加密解决方案基于 Microsoft BitLocker 驱动器加密,Linux 解决方案基于 dm dm-crypt。

在 Microsoft Azure 中启用 IaaS VM 时,该解决方案支持以下 IaaS VM 方案:

与 Azure Key Vault 集成


标准层 VM:A、D、DS 、G 和 GS 等系列 IaaS VM
在 Windows 和 Linux IaaS VM 上启用加密
在 Windows IaaS VM 的 OS 和数据驱动器上禁用加密
在 Linux IaaS VM 的数据驱动器上禁用加密
在运行 Windows 客户端 OS 的 IaaS VM 上启用加密
在包含安装路径的卷上启用加密
在使用 mdadm 配置了磁盘条带化的 Linux Vm 上启用加密 (RAID) 使用mdadm
使用 LVM(逻辑卷管理器)对 Linux VM 上的数据磁盘启用加密
在使用存储空间配置的 Windows VM 上启用加密
支持所有 Azure 公共区域

该解决方案不支持版本中的以下方案、功能和技术:

基本层 IaaS VM
在 Linux IaaS VM 的 OS 驱动器上禁用加密
使用经典 VM 创建方法创建的 IaaS VM
与本地密钥管理服务集成
Azure 文件(文件共享系统)、网络文件系统 (NFS)、动态卷,以及配置了基于软件的 RAID 系统的 Windows
VM

SQL 数据库隔离
SQL 数据库是 Microsoft 云中的关系型数据库服务,它基于行业领先的 Microsoft SQL Server 引擎,能够处理任
务关键型工作负荷。 SQL 数据库在联网时基于地理位置/区域提供帐户级别的可预测数据隔离,几乎不用人工管
理。

SQL 数据 库应 用程序模型
Microsoft SQL 数据库是一项基于云的关系数据库服务,是根据 SQL Server 技术构建的。 它提供由 Microsoft 在
云端托管的多租户数据库服务,该服务高度可用并且可缩放。

从应用程序的角度来看,SQL 数据库提供了以下层次结构:每个级别都包含以下一对多的级别。
帐户和订阅是用于将计费和管理关联的 Microsoft Azure 平台。

逻辑 SQL 服务器和数据库是特定于 SQL 数据库的概念,通过使用 SQL 数据库以及提供的 OData 和 TSQL 接口


或者通过 Azure 门户进行管理。

SQL 数据库中的服务器不是物理实例或 VM 实例,而是数据库、共享管理和安全策略的集合,它们存储在所谓


的“逻辑主”数据库中。

逻辑主数据库包括:

用于连接到服务器的 SQL 登录名


防火墙规则

同一服务器中数据库的计费和使用情况相关信息不保证位于群集中的同一物理实例中,应用程序在连接时必须
提供目标数据库名称。

从客户的角度看,服务器是在某个地理区域中创建的,但实际上,服务器是在该区域内的一个群集中创建的。

通 过 网 络 拓扑 实现 的隔离
创建服务器并注册其 DNS 名称后,该 DNS 名称指向该服务器所在的特定数据中心内所谓的“网关 VIP”地址。

在 VIP(虚拟 IP 地址)后面,有一个无状态网关服务的集合。 通常,多个数据源(主数据库、用户数据库等)之间需


要协调时,将涉及到网关。 网关服务可实现以下功能:

TDS 连 接代理。 这包括查找后端群集中的用户数据库,实现登录序列,并将 TDS 数据包转发到后端并返回。


数据 库 管理。 这包括采用工作流集合来执行数据库的创建/更改/删除操作。 可通过探查 TDS 数据包或显式
OData API 调用数据库操作。
创建/更改/删除登录/用户操作
通过 OData API 进行的服务器管理操作
网关后面的层称为“后端”。 这是以高度可用的方式存储所有数据的位置。 每段数据都被认为属于某个“分
区”或“故障转移单元”,并且有至少三个副本。 副本由 SQL Server 引擎存储和复制,并由通常称为“结构”的故障
转移系统进行管理。

通常,作为安全预防措施,后端系统不会与其他系统进行出站通信。 这会保留到前端(网关)层中的系统。 作为深


层防御机制,网关层计算机对后端计算机具有有限的特权,可最大限度减少攻击。

按 计 算机功能和 访问权 限的隔离


SQL 数据库由针对不同计算机功能运行的服务组成。 按照流量在后端只进不出的一般原则,SQL 数据库分为“后
端”云数据库和“前端”(网关/管理)环境。前端环境可与其他服务外部进行通信,而在后端只有有限的权限(足以调
用进行调用所需的入口点)。

网络隔离
Azure 部署具有多层网络隔离。 下图显示了 Azure 提供给客户的各种网络隔离层。 这些层同时属于 Azure 平台
本身的本机功能和客户定义的功能。 对于来自 Internet 的入站流量,Azure DDoS 提供针对 Azure 的大规模攻击
的隔离。 下一层隔离是客户定义的公共 IP 地址(终结点),可以根据这些终结点确定哪些流量可以通过云服务进
入虚拟网络。 本机 Azure 虚拟网络隔离可确保与其他所有网络完全隔离,而且流量只能流经用户配置的路径和
方法。 这些路径和方法就是下一个安全层,在该层中,可以使用 NSG、UDR 和网络虚拟设备来创建隔离边界,以
保护受保护网络中的应用程序部署。
流量隔离 :虚拟网络是 Azure 平台上的流量隔离边界。 一个虚拟网络中的虚拟机 (VM) 无法与不同虚拟网络中的
VM 直接通信,即使这两个虚拟网络是由同一个客户所创建。 隔离是一个非常关键的属性,可确保客户 VM 与通
信在虚拟网络中保持私密性。

子网基于 IP 范围在虚拟网络中提供额外的隔离层。 使用虚拟网络中的 IP 地址,可以将虚拟网络划分成多个子


网,以方便进行组织和提高安全性。 部署到 VNet 的子网(不管是相同的子网还是不同的子网)中的 VM 和 PaaS
角色实例可以互相通信,不需任何额外的配置。 还可以配置网络安全组 (NSG),以便根据 NSG 的访问控制列表
(ACL) 中配置的规则允许或拒绝到某个 VM 实例的网络流量。 NSG 可以与子网或该子网中的各个 VM 实例相关
联。 当 NSG 与子网关联时,ACL 规则将应用于该子网中的所有 VM 实例。

后续步骤
了解 Windows Azure 虚拟网络中的计算机的网络隔离选项。 它包括经典的前端和后端方案,其中特定后
端网络或子网中的计算机可能只允许某些客户端或其他计算机根据 IP 地址允许列表连接到特定终结点。

了解 Azure 中的虚拟机隔离。 Azure 计算提供独立于特定硬件类型并专用于单个客户的虚拟机大小。


Azure 标识管理安全概述
2021/2/9 • • Edit Online

标识管理是对安全主体进行身份验证和授权的过程。 它还包括控制有关这些主体(标识)的信息。 安全主体(标


识)可能包括服务、应用程序、用户和组等等。Microsoft 标识和访问管理解决方案可帮助 IT 部门保护对企业数据
中心和云中的应用程序和资源的访问。 此类保护支持附加的验证级别,比如多重身份验证和条件访问策略。 通
过高级安全报告、审核和警报来监视可疑活动,以便减少潜在的安全问题。 Azure Active Directory Premium 向
数千个云软件即服务 (SaaS) 应用提供单一登录 (SSO),并且可以用来访问在本地运行的 Web 应用。

利用 Azure Active Directory (Azure AD) 的安全优势,可以实现以下目的:

为混合企业中的每个用户创建和管理单一标识,从而保持用户、组和设备同步。
提供对应用程序(包括数千个预先集成的 SaaS 应用)的 SSO 访问。
通过对本地应用程序和云应用程序实施基于规则的多重身份验证,启用应用程序访问安全措施。
通过 Azure AD 应用程序代理预配对本地 Web 应用程序的安全远程访问。

本文旨在概述可帮助进行标识管理的核心 Azure 安全功能。 此外还提供了文章链接,更详细说明每项功能。

本文重点介绍以下核心 Azure 标识管理功能︰

单一登录
反向代理
多重身份验证
Azure 基于角色的访问控制 (Azure RBAC)
安全监控、警报和基于机器学习的报告
消费者标识和访问管理
设备注册
Privileged identity management
标识保护
混合标识管理/Azure AD Connect
Azure AD 访问评审

单一登录
SSO 是指只需使用单个用户帐户登录一次,就能访问开展业务所需的全部应用程序和资源。 登录之后,用户可以
访问全部所需的应用程序,而无需再次进行身份验证(例如键入密码)。

许多组织依赖 SaaS 应用程序(例如 Microsoft 365 、Box 和 Salesforce)来提高用户工作效率。 从历史上看,IT 人


员需要在每个 SaaS 应用程序中单独创建和更新用户帐户,而用户需要记住每个 SaaS 应用程序的密码。

Azure AD 将本地 Active Directory 环境扩展到云,让用户不仅能够使用主要组织帐户登录到已加入域的设备和公


司资源,而且能够登录到完成作业所需的全部 Web 和 SaaS 应用程序。

优势是不仅用户无需管理多组用户名和密码,而且你还可根据其组织组和员工状态,自动预配或取消预配应用程
序的访问权限。 Azure AD 引入了安全和访问管理控制,因此可以跨 SaaS 应用程序集中管理用户的访问权限。

了解详细信息:

SSO 概述
有关身份验证基础的视频
应用程序管理的快速入门系列
反向代理
使用 Azure AD 应用程序代理可以在专用网络内部发布本地应用程序(例如 SharePoint 站点、Outlook Web 应
用和基于 IIS 的应用),并网络之外的用户提供安全访问。 应用程序代理为许多类型的本地 Web 应用程序和
Azure AD 支持的数以千计的 SaaS 应用程序提供远程访问和 SSO。 员工可以从家中他们自己的设备登录到应
用,并通过此基于云的代理进行身份验证。

了解详细信息:

启用 Azure AD 应用程序代理
使用 Azure AD 应用程序代理发布应用程序
使用应用程序代理进行单一登录
使用条件性访问

多重身份验证
Azure AD 多重身份验证是需要使用多种验证方法的身份验证方法,为用户登录和事务又增加了一层至关重要的
安全保障。 多重身份验证可帮助保护对数据和应用程序的访问,同时可以满足用户对简单登录过程的需求。 它
通过各种验证选项(例如电话、短信、移动应用通知或验证码以及第三方 OAuth 令牌)来提供强身份验证。

了解详细信息:

多重身份验证
什么是 Azure AD 多重身份验证?
Azure AD 多重身份验证的工作原理

Azure RBAC
Azure RBAC 是在 Azure 资源管理器基础上构建的授权系统,针对 Azure 中的资源提供精细的访问权限管理。 可
以通过 Azure RBAC 精确控制用户具有的访问权限级别。 例如,可以限制一位用户仅管理虚拟网络,限制另一位
用户管理资源组中的所有资源。 Azure 包含多个可用的内置角色。 下面列出了四个基本的内置角色。 前三个角
色适用于所有资源类型。

所有者 - 拥有对所有资源的完全访问权限,包括将访问权限委派给其他用户的权限。
参与者 - 可以创建和管理所有类型的 Azure 资源,但无法将访问权限授予其他用户。
读取者 - 可以查看现有的 Azure 资源。
用户访问管理员 - 可以管理用户对 Azure 资源的访问。

了解详细信息:

什么是 Azure 基于角色的访问控制 (Azure RBAC)?


Azure 内置角色

安全监控、警报和基于机器学习的报告
安全监控、警报和基于机器学习的报告(用于标识不一致的访问模式)可以帮助保护业务。 可以使用 Azure AD 的
访问和使用情况报告来监控组织目录的完整性和安全性。 使用此信息,目录管理员可以更好地确定哪里可能存
在安全风险,以便制定相应的计划来降低这些风险。

在 Azure 门户中,报告分为以下类别:

异常 报 告 :包含我们发现存在异常的登录事件。 我们的目标是让你知道这类活动,并让你能够确定事件是否
可疑。
集成式 应 用程序 报 告 :就组织如何使用云应用程序提供见解。 Azure AD 提供与数千个云应用程序的集成。
错误报 告 :指示在为外部应用程序预配帐户时可能发生的错误。
用 户 特定的 报 告 :显示特定用户的设备登录活动数据。
活 动 日志 :包含过去 24 小时、过去 7 天或过去 30 天内的所有已审核事件的记录,以及组活动更改记录、密
码重置和注册活动记录。

了解详细信息:

查看访问和使用情况报告
Azure Active Directory 报告入门
Azure Active Directory 报告指南

消费者标识和访问管理
Azure AD B2C 是一项高度可用的全局性标识管理服务,适用于面向用户且可通过缩放来处理数亿标识的应用程
序。 它可以跨移动平台和 Web 平台进行集成。 使用者只需使用现有社交帐户或创建新凭据,即可通过可自定义
的体验登录到所有应用程序。

过去,想要在自己的应用程序中注册客户并使其登录的应用程序开发人员会编写自己的代码。 他们使用本地数
据库或系统存储用户名和密码。 Azure AD B2C 通过基于标准的安全平台和大量的可扩展策略,向组织提供一种
更好的方式将用户标识管理集成到应用程序中。

使用 Azure AD B2C 时,用户可通过使用他们现有的社交帐户(Facebook、Google、Amazon、LinkedIn)或创建新


的凭据(电子邮件地址和密码,或者用户名和密码)来注册应用程序。

了解详细信息:

什么是 Azure Active Directory B2C?


Azure Active Directory B2C 预览版:在应用程序中注册用户和让用户登录
Azure Active Directory B2C 预览版:应用程序的类型

设备注册
Azure AD 设备注册是基于设备的 条件性访问 方案的基础。 在注册设备时,Azure AD 设备注册会为设备提供一
个标识,用于在用户登录时对设备进行身份验证。 然后,可以使用经过身份验证的设备和设备的属性,对云中和
本地托管的应用程序实施条件性访问策略。

当与 Intune 之类的移动设备管理解决方案结合使用时,Azure AD 中的设备属性将使用关于设备的更多信息进行


更新。 然后,你可以创建条件性访问规则,以根据你的安全性和符合性标准强制从设备进行访问。

了解详细信息:

Azure AD 设备注册入门
将已加入 Windows 域的设备自动注册到 Azure AD
对已加入域的 Windows 设备在 Azure AD 中的自动注册进行设置

Privileged identity management


利用 Azure AD Privileged Identity Management,你可以管理、控制和监视特权标识以及对 Azure AD 和其他
Microsoft Online Services(如 Microsoft 365 和 Microsoft Intune)中的资源的访问。
用户有时候需要在 Azure 或 Microsoft 365 资源或者其他 SaaS 应用中执行特权操作。 这种需要通常意味着,组
织必须授予用户永久的 Azure AD 访问特权。 此类访问会给云中托管的资源不断增大安全风险,因为组织无法充
分监视这些用户正在使用管理员特权执行哪些操作。 此外,如果有访问特权的用户帐户被泄露,此安全漏洞可能
会影响组织的总体云安全性。 Azure AD Privileged Identity Management 可帮助解决这一风险。

使用 Azure AD Privileged Identity Management 可执行以下操作:

查看哪些用户是 Azure AD 管理员。


按需启用对 Microsoft 365 和 Intune 等 Microsoft 服务的实时 (JIT) 管理访问权限。
获取有关管理员访问历史记录以及管理员分配更改的报告。
获取有关访问特权角色的警报。

了解详细信息:

什么是 Azure AD Privileged Identity Management?


在 PIM 中分配 Azure AD 目录角色

标识保护
Azure AD 标识保护是一种安全服务,它提供一个综合视图,你可以在其中查看影响组织标识的风险检测和潜在
漏洞。 “标识保护”使用现有的 Azure AD 异常检测功能,该功能可通过 Azure AD 异常活动报告得到。 “标识保
护”还引入了新的可以实时检测异常的风险检测类型。

了解详细信息:

Azure AD 标识保护
第 9 频道:Azure AD 和标识展示:“标识保护”预览

混合标识管理/Azure AD Connect
Microsoft 的标识解决方案跨越本地和基于云的功能,创建单一用户标识对所有资源进行身份验证和授权,而不
考虑其位置。 我们称此为混合标识。 Azure AD Connect 专用于满足和完成混合标识目标的 Microsoft 工具。 这
样,便可为集成到 Azure AD 的 Microsoft 365 、Azure 和 SaaS 应用程序的用户提供一个通用标识。 它提供以下
功能:

同步
AD FS 和联合集成
直通身份验证
运行状况监视

了解详细信息:

混合标识白皮书
Azure Active Directory
Azure AD 团队博客

Azure AD 访问评审
Azure Active Directory (Azure AD) 访问评审可以使组织有效地管理组成员身份、对企业应用程序的访问权限,以
及特权角色分配。

了解详细信息:

Azure AD 访问评审
使用 Azure AD 访问评审管理用户访问权限
Azure 标识管理和访问控制安全最佳实践
2021/2/9 • • Edit Online

本文介绍一系列 Azure 标识管理和访问控制安全最佳实践。 这些最佳做法衍生自我们的 Azure AD 经验和客户


经验。

对于每项最佳做法,本文将说明:

最佳实践是什么
为何要启用该最佳实践
如果无法启用该最佳实践,可能的结果是什么
最佳实践的可能替代方案
如何学习启用最佳实践

这篇 Azure 标识管理和访问控制安全最佳实践以共识以及 Azure 平台功能和特性集(因为在编写本文时已存在)


为基础。

撰写本文的目的是,以引导你了解我们的一些核心功能和服务的“保护标识基础结构的 5 个步骤”清单为指导,提
供在部署后实现更可靠的安全状况的总体路线图。

看法和技术将随着时间改变,本文会定期更新以反映这些更改。

本文中介绍的 Azure 标识管理和访问控制安全最佳实践包括:

将标识视为主要安全边界
集中化标识管理
管理已连接的租户
启用单一登录
启用条件访问
计划例程安全改进
启用密码管理
对用户强制执行多重身份验证
使用基于角色的访问控制
降低特权帐户的泄露风险
控制资源所在的位置
使用 Azure AD 进行存储身份验证

将标识视为主要安全边界
许多人认为标识是主要安全边界。 这与以网络安全为重点的传统做法不同。 网络边界出现越来越多的漏洞,在
BYOD 设备和云应用程序激增之前相比,边界防御不再那样有效。
Azure Active Directory (Azure AD) 是用于标识和访问管理的 Azure 解决方案。 Azure AD 是 Microsoft 提供的多
租户、基于云的目录和标识管理服务。 它将核心目录服务、应用程序访问管理和标识保护融入一个解决方案中。

以下部分列出了使用 Azure AD 实现标识和访问安全性的最佳做法。

最佳做法 :围绕用户和服务标识进行安全控制和检测。 详细 信息 :使用 Azure AD 并置控制和标识。

集中化标识管理
在混合标识方案中,我们建议集成本地目录和云目录。 通过集成,IT 团队可以在一个位置集中管理帐户,而不管
帐户是在哪里创建的。 集成还通过提供用于访问云和本地资源的通用标识,从而帮助用户提高工作效率。

最佳做法 :建立一个 Azure AD 实例。 一致性和一个权威源不仅会提高简明性,还会减少人为错误和配置复杂性


带来的安全风险。 详细 信息 :指定一个 Azure AD 目录作为企业帐户和组织帐户的权威源。

最佳做法 :将本地目录与 Azure AD 进行集成。


详细 信息 :使用 Azure AD Connect 将本地目录与云目录同步。

NOTE
存在影响 Azure AD Connect 性能的因素。 确保 Azure AD Connect 有足够的容量来防止性能不佳的系统影响安全性和工作
效率。 大型或复杂的组织(预配超过 100,000 个对象的组织)应遵循建议来优化其 Azure AD Connect 实现。

最佳做法 :不要将现有 Active Directory 实例中拥有高权限的帐户同步到 Azure AD。 详细 信息 :不要更改用于筛


选掉这些帐户的默认 Azure AD Connect 配置。 这种配置降低了对手从云转向本地资产的风险(这可能引发重大
事件)。

最佳做法 :启用密码哈希同步。
详细 信息 :密码哈希同步是用于将用户密码哈希从本地 Active Directory 实例同步到基于云的 Azure AD 实例的
功能。 此同步有助于防止重放先前攻击中泄露的凭据。

即使决定使用 Active Directory 联合身份验证服务 (AD FS) 或其他标识提供者进行联合身份验证,也可以选择性


地设置密码哈希同步作为备用机制,以应对本地服务器发生故障或临时不可用的情况。 借助此同步,用户可以使
用与登录本地 Active Directory 实例相同的密码来登录服务。 如果用户对其他未连接到 Azure AD 的服务使用过
相同的电子邮件地址和密码,此同步还可便于标识保护将同步的密码哈希与已知被盗用的密码进行比较,从而检
测被盗用的凭据。

有关详细信息,请参阅使用 Azure AD Connect 同步实现密码哈希同步。

最佳做法 :对于新的应用开发,使用 Azure AD 进行身份验证。 详细 信息 :使用正确的功能来支持身份验证:

面向员工的 Azure AD
面向来宾用户和外部合作伙伴的 Azure AD B2B
用于控制客户在使用应用时如何注册、登录和管理配置文件的 Azure AD B2C

未将其本地标识与云标识集成的组织在管理帐户方面可能开销更大。 这种开销增加了出错和安全漏洞的可能
性。

NOTE
你需要选择关键帐户将驻留在哪些目录中,以及所使用的管理工作站是由新的云服务托管,还是由现有进程托管。 使用现有
的管理和标识预配流程可以降低一些风险,但也可能会造成攻击者入侵本地帐户并转向云的风险。 不妨对不同的角色(例
如,IT 管理员与业务部门管理员)使用不同的策略。 您有两种选择: 第一种选择是,创建不与本地 Active Directory 实例同步
的 Azure AD 帐户。 将管理工作站加入到 Azure AD,这样可以使用 Microsoft Intune 进行管理和修补。 第二种选择是,通过
同步到本地 Active Directory 实例来使用现有的管理员帐户。 使用 Active Directory 域中的现有工作站来实现管理和安全
性。

管理已连接的租户
你的安全组织需要能够查看订阅来评估风险,并确定是否遵循了组织的策略和任何法规要求。 你应确保安全组
织能够查看所有(通过 Azure ExpressRoute 或站点到站点 VPN)连接到生产环境和网络的订阅。 Azure AD 中的
全局管理员 可以将其访问权限提升到 " 用户访问管理员 " 角色,并查看连接到你的环境的所有订阅和管理组。

请参阅提升访问权限以管理所有 Azure 订阅和管理组,以确保你和你的安全组可以查看所有连接到环境的订阅


或管理组。 你应该在评估风险后撤消此提升的访问权限。
启用单一登录
在移动优先、云优先的世界中,你希望能够从任意位置实现对设备、应用和服务的单一登录 (SSO),以便你的用
户随时随地都能高效工作。 如果要管理多个标识解决方案,则不仅会给 IT 人员造成管理问题,而且用户还必须
记住多个密码。

通过对所有应用和资源使用相同的标识解决方案,可以实现 SSO。 并且不论资源是位于本地还是云中,用户均可


以使用相同凭据集登录和访问所需资源。

最佳做法 :启用 SSO。


详细 信息 :Azure AD 将本地 Active Directory 扩展到云。 用户可以将他们的主要工作或学校帐户用于他们加入域
的设备、公司资源以及完成工作所需的所有 Web 和 SaaS 应用程序。 用户无需记住多组用户名和密码,系统会根
据组织的组成员身份和员工身份的状态,自动预配(或取消设置)应用程序访问权限。 可以针对库应用或者通过
Azure AD 应用程序代理自行开发和发布的本地应用控制访问权限。
用户可使用 SSO 基于 Azure AD 中的工作或学校帐户访问 SaaS 应用程序。 这不仅适用于 Microsoft SaaS 应用,
还适用于其他应用,例如 Google Apps 和 Salesforce。 应用程序可配置为使用 Azure AD 作为基于 SAML 的标
识提供者。 作为安全控制机制,Azure AD 不会发出允许用户登录应用程序的令牌,除非用户已通过 Azure AD 获
取了访问权限。 可以直接或者通过用户所属的组授予访问权限。

如果组织没有通过创建通用标识来为用户和应用程序实现 SSO,那么用户拥有多个密码的情况就更容易出现。
这种情况增加了用户重复使用同一密码或使用弱密码的可能性。

启用条件访问
用户可能会从任意位置使用各种设备和应用访问组织的资源。 作为一名 IT 管理员,你需要确保这些设备符合安
全性和符合性标准。 仅关注谁可以访问资源不再能满足需求。

为了平衡安全性与工作效率,在做出访问控制决策之前,需要考虑如何访问资源。 使用 Azure AD 条件访问,可


以满足这一需求。 使用条件访问,可以根据访问云应用的条件做出自动访问控制决策。

最佳做法 :管理和控制对公司资源的访问。
详细 信息 :根据 SaaS 应用和 Azure AD 连接的应用的组、位置和应用敏感度,配置通用 Azure AD 条件访问策
略。

最佳做法 :阻止旧身份验证协议。 详细 信息 :攻击者每天都在利用旧协议中的弱点,尤其是密码喷射攻击。 配置


条件访问来阻止旧协议。

计划例程安全改进
安全性一直在不断发展,在云和标识管理框架中构建一种定期显示安全性发展并发现保护环境的新方法是很重
要的。

标识安全分数是 Microsoft 发布的一组建议的安全控制,旨在为你提供一个数字分数,以便客观地度量你的安全


状况,并帮助计划未来的安全改进。 你还可以查看你的分数与其他行业分数的比较,以及你自己的分数在一段时
间内的趋势。

最佳做法 :根据你所在行业的最佳做法来计划例程安全评审和改进。 详细 信息 :使用标识安全分数功能对你在一


段时间内的改进进行排名。

启用密码管理
如果有多个租户或者你想要允许用户重置自己的密码,则必须使用适当的安全策略来防止滥用。

最佳做法 :为用户设置自助式密码重置 (SSPR)。


详细 信息 :使用 Azure AD 自助式密码重置功能。

最佳做法 :监视是否在使用 SSPR 及其使用情况。


详细 信息 :通过使用 Azure AD 密码重置注册活动报表监视正在注册的用户。 Azure AD 提供的报表功能可帮助
使用预生成的报表来回答问题。 如果有相应的授权,还可以创建自定义查询。

最佳做法 :将基于云的密码策略扩展到本地基础结构。 详细 信息 :通过对本地密码更改执行与对基于云的密码更


改执行的相同检查,增强组织中的密码策略。 为本地 Windows Server Active Directory 代理安装 Azure AD 密码
保护,以将禁止的密码列表扩展到现有基础结构。 更改、设置或重置本地密码的用户或管理员必须与仅限云的用
户遵循相同的密码策略。

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

要求双重验证有多种选项。 最佳选项取决于你的目标、正在运行的 Azure AD 版本以及许可计划。 请参阅如何要


求对用户进行双重验证了解最佳选项。 有关许可和定价的详细信息,请参阅 Azure AD 和 Azure AD 多重身份验
证定价页。

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

选项 1 :使用 Azure AD 安全默认值为所有用户和登录方法启用 MFA 优势:借助此选项,可以轻松、快速地为环境


中的所有用户强制执行 MFA,同时采用严格的策略来执行以下操作:

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

此方法可用于所有许可层,但不能与现有的条件访问策略混合使用。 你可以在 Azure AD 安全默认值中找到更多


信息

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

若要确定需要启用多因素身份验证的位置,请参阅 哪个版本的 AZURE AD MFA 适用于组织?。

选项 3 :使用条件访问策略启用多重身份验证。 优势 :借助此选项,可以使用 条件访问在特定条件下提示进行双


重验证。 特定条件可以是用户从不同位置、不受信任的设备或你认为存在风险的应用程序登录。 定义要求双重
验证的特定条件可以避免不断提示用户这种令人不快的用户体验。

这是为用户启用双重验证最灵活的方式。 启用条件性访问策略仅适用于云中 Azure AD 多重身份验证,并且是


Azure AD 的高级功能。 可以在 部署基于云的 Azure AD 多重身份验证中找到有关此方法的详细信息。
选项 4 :通过评估基于风险的条件访问策略,使用条件访问策略启用多重身份验证。
优势 :此选项使你能够:

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

此方法使用“Azure AD 标识保护”风险评估来确定是否需要基于所有云应用程序的用户和登录风险进行双重验
证。 此方法需要 Azure Active Directory P2 授权。 有关此方法的详细信息,请参阅 Azure Active Directory 标识保
护。

NOTE
选项2,通过更改用户状态启用多重身份验证会替代条件访问策略。 由于选项3和4使用条件性访问策略,因此不能将选项2
与它们一起使用。
未添加额外标识保护层(如双重验证)的组织将更容易受到凭据窃取攻击。 凭据窃取攻击可能导致数据泄漏。

使用基于角色的访问控制
对于任何使用云的组织而言,云资源的访问管理至关重要。 Azure 基于角色的访问控制 (Azure RBAC) 可帮助你
管理谁有权访问 Azure 资源、他们可以对这些资源执行哪些操作以及他们有权访问哪些区域。

在 Azure 中指定负责特定功能的组或单个角色有助于避免混乱,从而避免可能会导致安全风险的人为错误和自
动化错误。 对于想要实施数据访问安全策略的组织而言,必须根据需要知道和最低权限安全策略限制访问权限。

你的安全团队需要能够查看 Azure 资源,以便评估和修正风险。 如果安全团队具有运营职责,则需要额外的权限


来完成他们的作业。

可以使用 Azure RBAC 向特定范围的用户、组和应用程序分配权限。 角色分配的范围可以是订阅、资源组或单个


资源。

最佳做法 :在团队中分离职责,只向用户授予执行作业所需的访问权限。 只允许在特定范围内执行特定操作,而


不要在 Azure 订阅或资源中向每个人都授予无限制权限。 详细 信息 :使用 Azure 中的 Azure 内置角色向用户分
配权限。

NOTE
特定的权限会造成不必要的复杂性和混乱,进而积累为很难在不担心造成破坏的情况下进行修复的“旧”配置。 避免特定于
资源的权限。 而是将管理组用于企业范围内的权限,并将资源组用于订阅中的权限。 避免用户特定的权限。 而是向 Azure
AD 中的组分配权限。

最佳做法 :向具有 Azure 职责的安全团队授予对 Azure 资源的访问权限,以便他们可以评估和修正风险。 详细


信息 :向安全团队授予 Azure RBAC 安全读取者角色。 可以使用根管理组或段管理组,具体视职责范围而定:

根管理组:用于负责所有企业资源的团队
段管理组:用于范围有限的团队(通常是由于法规或其他组织边界所致)

最佳做法 :向具有直接运营职责的安全团队授予适当的权限。 详细 信息 :查看 Azure 内置角色以进行合适的角色


分配。 如果内置角色不能满足组织的具体需求,则可以创建 Azure 自定义角色。 与内置角色一样,可以在订阅、
资源组和资源范围内向用户、组和服务主体分配自定义角色。

最佳做法 :向需要的安全角色授予 Azure 安全中心访问权限。 使用安全中心,安全团队可以快速发现和修正风


险。 详细 信息 :将具有这些需求的安全团队添加到 Azure RBAC 安全管理员角色,以便他们可以查看安全策略、
查看安全状态、编辑安全策略、查看警报和建议,以及关闭警报和建议。 你可以使用根管理组或段管理组来执行
此操作,具体取决于职责范围。

不通过使用 Azure RBAC 等功能实施数据访问控制的组织可能会向其用户提供比所需权限更多的特权。 允许用


户访问他们不应该有权访问的数据类型(例如,对业务有重大影响的数据)可能会导致数据泄露。

降低特权帐户的泄露风险
保护特权访问是保护业务资产的首要步骤。 减少拥有访问权限的人员以保护信息或资源安全,这样可以减小恶
意用户获得访问权限,或者已授权用户无意中影响敏感资源的可能性。

特权帐户是指掌控和管理 IT 系统的帐户。 网络攻击者会攻击这些帐户来获取组织数据和系统的访问权限。 为了


保护特权访问,应隔离此类帐户和系统,使其免受恶意用户的威胁。

建议制定并遵循一个路线图,防止特权访问受到网络攻击者的攻击。 若要详细了解如何在 Azure AD、Microsoft


Azure、Microsoft 365 和其他云服务中管理或报告的安全身份和访问,请参阅 Azure AD 中的保护混合和云部署
的特权访问。

以下内容总结了确保 Azure AD 中混合部署和云部署的特权访问安全性中介绍的最佳做法:


最佳做法 :管理、控制和监视对特权帐户的访问。
详细 信息 :启用 Azure AD Privileged Identity Management。 启用 Privileged Identity Management 以后,会收到
有关特权访问角色更改的通知电子邮件。 向目录中的高特权角色添加更多用户时,这些通知相当于早期警告。

最佳做法 :确保所有关键管理员帐户都是托管的 Azure AD 帐户。 详细 信息 :从关键管理员角色中删除所有使用


者帐户(例如,hotmail.com 、live.com 和 outlook.com 等 Microsoft 帐户)。

最佳做法 :确保所有关键管理员角色都有一个单独的帐户来执行管理任务,以免发生网络钓鱼和其他入侵管理权
限的攻击。 详细 信息 :创建一个单独的管理员帐户,向其分配执行管理任务所需的权限。 阻止使用这些管理帐户
进行 Microsoft 365 电子邮件或任意 web 浏览等日常生产力工具。

最佳做法 :对特许权限高的角色中的帐户进行标识和分类。
详细 信息 :启用 Azure AD Privileged Identity Management 后,请查看角色为全局管理员、特权角色管理员和其
他高特权角色的用户。 请删除在这些角色中不再需要的任何帐户,并对剩余的分配给管理员角色的帐户分类:

单独分配给管理用户,可用于非管理性目的(例如,个人电子邮件)
单独分配给管理用户,按规定只能用于管理目的
跨多个用户共享
适用于紧急访问情况
适用于自动化脚本
适用于外部用户

最佳做法 :实行“实时”(JIT) 访问可进一步降低特权的曝光时间,并提高对特权帐户使用情况的可见性。


详细 信息 :利用 Azure AD Privileged Identity Management,可以:

限制用户只接受他们的权限 JIT。
分配时限更短的角色,确信权限会自动撤消。

最佳做法 :定义至少两个紧急访问帐户。
详细 信息 :可以使用紧急访问帐户来帮助组织限制现有 Azure Active Directory 环境中的特权访问。 这些帐户拥
有极高的特权,不要将其分配给特定的个人。 紧急访问帐户只能用于不能使用正常管理帐户的情况。 组织必须
将紧急账户的使用限制在必要时间范围内。

评估已经获得或有资格获得全局管理员角色的帐户。 如果使用 *.onmicrosoft.com 域(用于紧急访问)看不到任


何仅限云的帐户,请创建此类帐户。 有关详细信息,请参阅在 Azure AD 中管理紧急访问管理帐户。

最佳做法 :准备“破窗”流程,以备紧急情况时使用。 详细 信息 :按照 确保 Azure AD 中混合部署和云部署的特权


访问安全性中的步骤操作。

最佳做法 :要求所有关键管理员帐户都是无密码的(首选),或要求进行多重身份验证。 详细 信息 :使用


Microsoft Authenticator 应用登录任何 Azure AD 帐户,而不需要使用密码。 与 Windows Hello for Business 一
样,Microsoft Authenticator 使用基于密钥的身份验证来启用与设备绑定的用户凭据,并使用生物识别身份验证
或 PIN。

对于永久分配给一个或多个 Azure AD 管理员角色的单个用户,要求在登录时进行 Azure AD 多重身份验证:全局


管理员、特权角色管理员、Exchange Online 管理员和 SharePoint Online 管理员。 为管理员帐户启用多重身份验
证,并确保管理员帐户用户已注册。

最佳做法 :对于关键管理员帐户,需要有不允许执行生产任务(例如,浏览和电子邮件)的管理工作站。 这会保护


你的管理员帐户免受使用浏览和电子邮件的攻击途径的侵害,并大大降低发生重大事件的风险。 详细 信息 :使用
管理工作站。 选择工作站安全级别:

高度安全的效率提升设备为浏览和其他效率提升任务提供高级安全性。
特权访问工作站 (PAW) 为敏感任务提供免受 Internet 攻击和威胁攻击途径侵害的专用操作系统。

最佳做法 :在员工离开组织时,取消设置管理员帐户。 详细 信息 :准备一个流程,在员工离开组织时禁用或删除


管理员帐户。
最佳做法 :使用最新的攻击技术定期测试管理员帐户。 详细 信息 :使用 Microsoft 365 攻击模拟器或第三方产品/
服务在你的组织中运行现实的攻击方案。 这样有助于在真正攻击发生之前发现易受攻击的用户。

最佳做法 :采取措施来缓解最常用的攻击技术的冲击。
详细 信息 :确定管理角色中那些需要切换到工作或学校帐户的 Microsoft 帐户

对于全局管理员帐户,请确保使用单独的用户帐户和邮件转发功能

确保最近更改过管理帐户的密码

启用密码哈希同步

要求对所有特权角色用户和公开的用户进行多重身份验证

获取 Microsoft 365 安全分数(如果使用 Microsoft 365 )

查看 Microsoft 365 安全指导 (如果使用 Microsoft 365)

配置 Microsoft 365 活动监视(如果使用 Microsoft 365 )

确定事件/紧急情况响应计划所有者

保护本地特权管理帐户

如果不保护特权访问,你可能会拥有过多高特权角色用户,并且更易受到攻击。 恶意操作者(包括网络攻击者)通
常会以管理员帐户和特权访问的其他元素为目标,通过凭据窃取获得敏感数据和系统的访问权限。

控制创建资源的位置
非常重要的一点是,既要允许云操作员执行任务,同时又要防止他们违反管理组织资源所需的惯例。 想要控制创
建资源的位置的组织应该对这些位置进行硬编码。

可以使用 Azure 资源管理器创建安全策略,其中的定义描述了会明确遭到拒绝的操作或资源。 可以在所需范围


(例如订阅、资源组或是单个资源)分配这些策略定义。

NOTE
安全策略与 Azure RBAC 不同。 它们实际上使用 Azure RBAC 来授权用户创建这些资源。

无法控制资源创建方式的组织更容易因用户创建的资源超过所需数目,而产生滥用服务的情况。 强化资源创建
过程是保护多租户方案的重要步骤。

主动监视可疑活动
主动身份监视系统可以快速检测可疑行为并触发警报以进行进一步调查。 下表列出了两个可帮助组织监视其标
识的 Azure AD 功能:

最佳做法 :采用一种方法来确定:

未受跟踪的登录尝试。
针对特定帐户的暴力攻击。
从多个位置的登录尝试。
从受感染的设备登录。
可疑 IP 地址。

详细 信息 :使用 Azure AD Premium 异常报告。 制定相应的流程和过程,使 IT 管理员每天或按需(通常在事件响


应方案中)运行这些报告。

最佳做法 :安装一个主动监视系统,用于通知风险,并且可以根据业务需求调整风险等级(高、中或低)。
详细 信息 :使用 Azure AD 标识保护,它会在自己的仪表板上标记当前风险并通过电子邮件发送每日摘要通知。
要帮助保护组织的标识,可以配置基于风险的策略,该策略可在达到指定风险级别时自动响应检测到的问题。

不主动监视其标识系统的组织将面临用户凭据泄露的风险。 如果不知道有人通过这些凭据实施可疑活动,组织
就无法缓解这种类型的威胁。

使用 Azure AD 进行存储身份验证
Azure 存储支持使用 Azure AD 对 Blob 存储和队列存储进行身份验证和授权。 借助 Azure AD 身份验证,可以使
用基于 Azure 角色的访问控制向用户、组和应用(一直到各个 Blob 容器或队列的范围)授予特定权限。

建议使用 Azure AD 验证对存储的访问。

后续步骤
有关通过 Azure 设计、部署和管理云解决方案时可以使用的更多安全最佳做法,请参阅 Azure 安全最佳做法和模
式。
保护标识基础结构的五个步骤
2021/2/9 • • Edit Online

阅读本文档意味着你认识到了安全的重要性。 你可能已在履行保护组织的责任。 如果需要说服其他人注重安全


性,请建议他们阅读最新的 Microsoft 安全情报。

本文档说明了如何使用包含五个步骤的查检表来防范组织受到网络攻击,帮助用户更安全地使用 Azure Active


Directory 功能。
此查检表有助于快速部署关键的建议措施,立即为组织提供保护。具体措施包括:

增强凭据。
缩小受攻击面。
自动化威胁响应。
利用云智能。
启用最终用户自助服务。

阅读此清单时,请确保记录哪些功能和步骤已完成。

NOTE
本文档中的许多建议仅适用于配置为使用 Azure Active Directory 作为标识提供者的应用程序。 在应用中配置单一登录可
确保将凭据策略、威胁检测、审核和日志记录的优势及其他功能添加到这些应用程序。 Azure AD 的应用程序管理 是所有这
些建议所基于的基础。

本文档中的建议符合标识安全评分(Azure AD 租户的标识安全配置的自动评估)。 组织可以使用 Azure AD 门户


中的“标识安全分数”页查找当前安全配置的差距,以确保遵循当前的 Microsoft 安全最佳做法。 实施“安全评
分”页中的每条建议可以提高评分和跟踪进度,并有助于将实施方案与其他类似规模的组织或行业进行比较。

NOTE
此处所述的许多功能都需要 Azure AD Premium 订阅,而有些功能则是免费的。 有关详细信息,请查看 Azure Active
Directory 定价和 Azure AD 部署清单。

开始之前:使用 MFA 保护特权帐户


在开始实施此查检表之前,请确保在阅读此查检表时不会受到攻击。 首先需要保护自己的特权帐户。

获得特权帐户控制权的攻击者可以执行巨大的破坏,因此先行保护这些帐户至关重要。 使用Azure AD 安全性默


认值或条件性访问,为组织中的所有管理员启用和要求AZURE AD 多重身份验证 (MFA) 。 如果尚未实施 MFA,请
立即实施! 因为 MFA 非常重要。

准备好了吗? 让我们开始阅读查检表。

步骤 1 - 增强凭据
大多数企业安全漏洞的起源在于某个帐户受到某种手段的攻击。这些手段多种多样,例如密码喷洒 (password
spray)、破解重放或网络钓鱼。 请观看以下视频(45 分钟)来详细了解这些攻击:

确保 组织 使用 强 身份 验证
考虑到密码被猜中、钓鱼、被恶意软件盗用或重复使用的频率,使用某种形式的强凭据备份密码非常重要-详细了
解 Azure AD 多重身份验证。

若要轻松启用基本级别的身份安全,可以将“一键式启用”与 Azure AD 安全默认值结合使用。 安全默认值为租户


中的所有用户强制实施 Azure AD MFA,并阻止来自租户范围内的传统协议的登录。

开始禁止使用 经 常受到攻 击 的密 码 ,摒弃 传统 的复 杂 性 规则 和 过 期 规则 。


许多组织使用传统的复杂性规则(要求使用特殊字符、数字和大小写)和密码过期规则。 Microsoft 的研究表明,
这些策略会导致用户选择更容易猜出的密码。

Azure AD 的动态禁止密码功能使用当前的攻击者行为来防止用户设置容易猜出的密码。 在云中创建用户时,始


终会启用此功能。混合型组织在部署适用于 Windows Server Active Directory 的 Azure AD 密码保护时,也可以
使用此功能。 Azure AD 密码保护会阻止用户选择这些常用密码,经扩展后可以阻止包含指定的自定义关键字的
密码。 例如,可以阻止用户选择包含你公司的产品名称或当地球队的密码。

Microsoft 建议根据 NIST 指导采用以下新式密码策略:


1. 要求密码至少包含 8 个字符。 密码并非越长越好,因为这会导致用户选择容易预测的密码、将密码保存在文
件中,或者写下密码。
2. 禁用过期规则,因为这种规则会促使用户选择容易猜出的密码,例如“Spring2019!”
3. 禁用字符组合要求,并防止用户选择经常受到攻击的密码,因为这些规则会导致用户在密码中选择容易预测
的替代字符。

如果直接在 Azure AD 中创建标识,可以使用 PowerShell 防止用户的密码过期。 混合型组织应该使用域组策略


设置或 Windows PowerShell 实施这些策略。

防止凭据泄漏,并 针对 服 务 中断添加复原功能
如果组织使用实施直通身份验证或联合身份验证的混合标识解决方案,应该启用密码哈希同步,原因包括以下两
点:

Azure AD 管理系统中的凭据已泄漏的用户报告会警告用户名和密码对已在“黑暗网络”中透露。 日后遭到攻击


的第三方站点上出现的网络钓鱼、恶意软件和密码重用,导致大量的密码泄漏。 Microsoft 发现其中许多泄露
的凭据,并在此报表中通知你,如果它们与你组织中的凭据匹配–但仅当你 启用了密码哈希同步 或具有仅限
云的标识时才适用!
如果发生本地中断 (例如,在勒索软件攻击) ,可以 使用密码哈希同步切换到使用云身份验证。利用此备份身
份验证方法,你可以继续访问配置为 Azure Active Directory 身份验证的应用,包括 Microsoft 365 。 在这种情
况下,解决本地服务中断之前,IT 人员无需采用个人电子邮件帐户来共享数据。

详细了解密码哈希同步的工作原理。
NOTE
如果启用密码哈希同步并且使用 Azure AD 域服务,则 Kerberos (AES 256) 哈希和可选的 NTLM(RC4,不加盐)哈希也将加
密并同步到 Azure AD。

实施 AD FS Extranet 智能 锁 定
将应用程序配置为直接向 Azure AD 进行身份验证的组织可以受益于 Azure AD 智能锁定。 如果在 Windows
Server 2012R2 中使用 AD FS ,请实现 AD FS Extranet 锁定保护。 如果在 Windows Server 2016 中使用 AD FS ,
请实现 Extranet 智能锁定。 AD FS 智能 Extranet 锁定可以防范针对 AD FS 的暴力攻击,同时可以防止用户在
Active Directory 中遭到锁定。
利用本 质 安全的、易于使用的凭据
使用 Windows Hello 可在电脑和移动设备上将密码取代为强式双重身份验证。 这种身份验证包括一种与设备安
全绑定的新型用户凭据,并使用生物识别技术或 PIN。

步骤 2 - 缩小受攻击面
密码攻击无处不在,尽量缩小组织中的受攻击面至关重要。 弃用不够安全的旧式协议、限制访问入口点、针对资
源的管理访问实行更严格的控制有助于缩小受攻击面。

阻止 传统 身份 验证
使用自身的传统方法在 Azure AD 中进行身份验证和访问公司数据的应用给组织带来了另一种风险。 使用传统
身份验证的应用示例包括 POP3 、IMAP4 或 SMTP 客户端。 传统身份验证应用会代表用户执行身份验证,并阻止
Azure AD 执行高级安全评估。 替代的新式身份验证可降低安全风险,因为它支持多重身份验证和条件访问。 我
们建议采取以下三项措施:

1. 如果使用 AD FS ,则阻止传统身份验证。
2. 将 SharePoint Online 和 Exchange Online 设置为使用新式身份验证。
3. 如果有 Azure AD Premium ,请使用条件访问策略阻止旧身份验证,否则请使用 Azure AD 安全默认值。

阻止无效的身份 验证 入口点
使用假设违规思路会减少用户凭据泄露造成的影响。 对于环境中的每个应用,请考虑有效的方案:要为哪些组、
哪些网络、哪些设备和其他元素授权 – 然后阻止余下的部分。 使用 Azure AD 条件访问,可以控制已获授权的用
户根据定义的特定条件访问其应用和资源的方式。

限制用 户许 可操作
请务必了解各种 Azure AD 应用程序许可体验、权限和许可的类型以及它们对组织安全状况的影响。 默认情况
下,Azure AD 中的所有用户都可以对利用 Microsoft 标识平台访问组织数据的应用程序进行授权。 尽管允许用
户自行许可确实可让用户轻松获取与 Microsoft 365 、Azure 和其他服务集成的有用应用程序,但如果未小心使用
或未受监视,这可能会带来风险。

Microsoft 建议限制用户同意,以帮助减少您的 surface 区域并降低这种风险。 你还可以使用 应用许可策略 (预


览) 将最终用户许可限制为仅限已验证的发布者和你选择的权限。 如果对最终用户的同意受到限制,则仍将接受
以前的许可授权,但所有未来的同意操作都必须由管理员执行。 对于受限制的情况,用户可以通过集成的 管理
员同意请求工作流 或通过你自己的支持过程来请求管理员许可。 在限制最终用户同意之前,请使用我们的 建议
在组织中规划此更改。 对于希望允许所有用户访问的应用程序,请考虑代表所有用户授予许可,确保尚未单独许
可的用户能够访问该应用。 如果不希望这些应用程序对所有场景中的所有用户都可用,请使用应用程序分配和
条件访问来限制用户对特定应用的访问。

确保用户可以请求管理员批准新应用程序,以减少用户摩擦、最大程度降低支持量并防止用户使用非 Azure AD
凭据注册应用程序。 管控许可操作后,管理员应定期审核应用和许可权限。

实施 Azure AD Privileged Identity Management


“假设违规”的另一个影响是,需要尽量减少受到攻击的帐户以特权角色运行的可能性。
Azure AD Privileged Identity Management (PIM) 有助于尽量减少帐户特权,因为它可以帮助:
识别和管理已分配到管理角色的用户。
了解应删除的未使用或过多的特权角色。
建立规则来确保特权角色受到多重身份验证的保护。
建立规则来确保授予特权角色的时间长短刚好足够用于完成特权任务。

启用 Azure AD PIM,然后查看分配有管理角色的用户,并删除这些角色中不必要的帐户。 对于剩余的特权用户,


请将其角色分配从“永久”更改为“符合条件”。 最后,建立适当的策略,确保当这些用户需要访问这些特权角色
时,能够使用所需的变更控制安全地进行访问。

在部署特权帐户的过程中,请遵循至少创建两个紧急帐户的最佳做法,确保自己被锁定时仍能访问 Azure AD。

步骤 3 - 自动化威胁响应
Azure Active Directory 中的许多功能可以自动截获攻击,以消除检测与响应之间的延迟。 如果能够减少罪犯渗
入你的环境所能利用的时间,则就可以降低成本和风险。 下面是可以采取的具体措施。

使用 “Azure AD 标识 保 护 ”实 施用 户风险 安全策略


用户风险指示用户身份泄露的可能性,它是根据与用户身份关联的用户风险检测计算的。 用户风险策略是一种
条件访问策略,评估特定用户或组的风险级别。 根据“低”、“中”、“高”风险级别,可以配置一个策略来阻止访问,
或者要求使用多重身份验证进行安全密码更改。 Microsoft 建议要求高风险用户进行安全密码更改。

使用 “Azure AD 标识 保 护 ”实 施登 录风险 策略
登录风险是指除帐户所有者以外的其他某人尝试使用标识登录的可能性。 登录风险策略是一种条件访问策略,
评估特定用户或组的风险级别。 根据风险级别(高/中/低),可以配置一个策略来阻止访问,或强制实施多重身份
验证。 请确保针对“中”或更高风险的登录强制实施多重身份验证。
步骤 4 - 利用云智能
审核和记录与安全相关的事件以及相关警报是有效保护策略的至关重要组成部分。 安全日志和报告提供可疑活
动的电子记录,并帮助检测可能指示试图或已成功的外部网络渗透以及内部攻击的模式。 可以使用审核来监控
用户活动、记录法规遵从性以及进行取证分析等。 警报提供安全事件的通知。

监视 Azure AD
Microsoft Azure 服务和功能提供可配置的安全审核和日志记录选项,帮助识别安全策略和机制的缺口,并解决
这些缺口,以防违规。 可以使用 Azure 日志记录和审核,以及 Azure Active Directory 门户中的审核活动报告。

监视 混合 环 境中的 Azure AD Connect Health


使用 Azure AD Connect Health 监视 AD FS 能够更好地洞察潜在问题以及 AD FS 基础结构受到的攻击。 Azure
AD Connect Health 提供附带详细信息的警报、解决方法步骤、相关文档的链接、与身份验证流量相关的多个指
标的使用情况分析、性能监视和报告。
监视 “Azure AD 标识 保 护 ”事件
Azure AD 标识保护是一个通知、监视和报告工具,可用于检测影响组织标识的潜在漏洞。 它可以检测风险检测,
例如,泄漏的凭据、不可能的轨迹、来自受感染设备的登录、匿名的 IP 地址、与可疑活动关联的 IP 地址,以及未
知的位置。 启用通知警报可以接收有风险用户的电子邮件,和/或每周摘要电子邮件。

Azure AD 标识保护提供两份应该每日监视的重要报告:
1. 风险登录报告显示应该调查的用户登录活动,合法所有者不可以执行这种登录。
2. 风险用户报告显示可能已泄密的用户帐户,例如,检测到已泄漏的凭据,或者用户从不同的位置登录,导致不
可能的行程事件。
审 核 应 用和 许 可的 权 限
用户可能在诱骗之下导航到已被入侵的网站或应用,使攻击者获取用户个人资料信息和数据(例如电子邮件)的
访问权限。 恶意行动者可以使用获得的许可权限来加密用户的邮箱内容,并勒索邮箱数据的赎金。 管理员应查
看并审核用户授予的权限,或者在默认情况下禁用用户授予许可的能力。

除了审核用户授予的权限之外,还可以在高级环境中查找有风险或不需要的 OAuth 应用程序。

步骤 5 - 启用最终用户自助服务
我们希望在安全性与工作效率之间尽量实现平衡。 在达成目标的同时兼顾长期安全基准的制定,可以消除组织
中存在的冲突,让用户获得所需的能力,并让他们保持警惕。

实 施自助密 码 重置
IT 管理员可以通过 Azure AD 的自助密码重置 (SSPR),让用户方便重置或解锁其密码或帐户,而无需支持人员或
管理员的干预。 系统提供详细的报告,用于跟踪用户何时重置密码,同时还提供通知,提醒用户存在误用或滥用
情况。

实现 自助服 务组 和 应 用程序 访问
Azure AD 使非管理员能够使用安全组、Microsoft 365 组、应用程序角色和访问包目录管理对资源的访问。 自助
服务组管理使组所有者能够管理自己的组,而无需分配管理角色。 用户还可以创建和管理 Microsoft 365 组,而
无需依靠管理员来处理其请求,且未使用的组会自动过期。 Azure AD 权利管理进一步启用委派和可见性,具有全
面的访问请求工作流和自动过期。 可以委托非管理员为其拥有的组、Teams、应用程序和 SharePoint Online 网站
配置自己的访问包,并为需要批准访问权限的人员配置自定义策略,包括将员工的经理和业务合作伙伴发起人配
置为审批者。

实施 Azure AD 访问评审
使用 Azure AD 访问评审可以管理访问包和组成员身份、企业应用程序的访问权限和特权角色分配,以确保维持
以下安全标准。 用户本身、资源所有者和其他审阅者的定期监督确保了用户在不再需要访问权限的情况下不会长
时间保留访问权限。

总结
保护安全标识基础结构涉及到很多方面,但此五步骤查检表可帮助你快速实现一个更可靠的安全标识基础结构:

增强凭据。
缩小受攻击面。
自动化威胁响应。
利用云智能。
通过自助措施提高可预测性,更全面地保护最终用户安全。

非常感谢你严肃看待标识安全性,希望本文档在帮助你提高组织的安全性上提供了有用的思路。

后续步骤
如果在规划和部署这些建议方面需要帮助,请参阅 Azure AD 项目部署计划。

如果你确信所有这些步骤都已完成,请使用 Microsoft 的标识安全分数,它可让你随时了解最新的最佳做法和安


全威胁。
Azure Active Directory 的⽆密码 authentication 选

2021/2/9 • • Edit Online

多重身份验证 (MFA) 等功能是保护组织的一种好方法,但用户通常会在必须记住其密码的情况下使用额外的安


全层。 无密码身份验证方法更为方便,因为密码会被删除并替换为你拥有的内容,以及你或你知道的内容。

A UT H EN T IC AT IO N

无密码 Windows 10 设备、电话号码或安全密 生物识别或 PIN


当涉及身份验证时,每个组织都有不同的需求。 Microsoft 提供了以下三个无密码身份验证选项,这些选项与


Azure Active Directory (Azure AD) :
Windows Hello 企业版
Microsoft Authenticator 应用
FIDO2 安全密钥

Windows Hello 企业版


Windows Hello 企业版非常适合拥有自己的指定 Windows PC 的信息工作者。 生物识别和 PIN 凭据直接绑定到
用户的 PC,这会阻止除所有者之外的任何人访问。 利用公钥基础结构 (PKI) 集成和内置支持单一登录 (SSO)
,Windows Hello 企业版提供了一种方便的方法,可用于无缝访问本地和云中的公司资源。
以下步骤演示了如何使用 Azure AD 的登录过程:
1. 用户使用生物识别或 PIN 手势登录 Windows。 手势会解除对 Windows Hello 企业版私钥的锁定,并发送到云
身份验证安全支持提供程序(称为 云 AP 提供程序)。
2. 云 AP 提供程序请求 nonce (随机任意数字,只需从 Azure AD) 一次即可。
3. Azure AD 返回有效时间为5分钟的 nonce。
4. 云 AP 提供程序使用用户的私钥对 nonce 进行签名,并将签名的 nonce 返回到 Azure AD。
5. Azure AD 使用用户安全注册的公钥对 nonce 签名进行签名。 验证签名后,Azure AD 验证返回的签名 nonce。
验证 nonce 后,Azure AD 将使用加密到设备传输密钥的会话密钥 (PRT) 创建主刷新令牌,并将其返回给云 AP
提供商。
6. 云 AP 提供程序接收带会话密钥的加密 PRT。 使用设备的专用传输密钥,云 AP 提供程序会解密会话密钥,并
使用设备的受信任的平台模块 (TPM) 来保护会话密钥。
7. 云 AP 提供程序向 Windows 返回成功的身份验证响应。 然后,用户可以访问 Windows 以及云和本地应用程
序,而无需再次 (SSO) 进行身份验证。

Windows Hello 企业版 规划指南 可用于帮助您决定 Windows Hello 企业版部署的类型以及需要考虑的选项。

Microsoft Authenticator 应用
你还可以允许员工的电话成为无密码的身份验证方法。 除密码外,你可能已使用 Microsoft Authenticator 应用作
为便利的多重身份验证选项。 你还可以使用验证器应用作为无密码选项。

验证器应用会将任何 iOS 或 Android 手机变成强、无密码凭据。 用户可以通过以下方式登录到任何平台或浏览


器:向其手机发送通知,将屏幕上显示的数字与电话上的一个数字匹配,然后使用其生物识别 (触摸或面部) 或
PIN 以确认。 有关安装的详细信息,请参阅 下载并安装 Microsoft Authenticator 应用 。
无密码 Microsoft Authenticator 应用登录到 Azure AD 目前处于预览阶段。 使用 Microsoft Authenticator 应用进
行辅助身份验证 Azure AD 多重身份验证、自助服务密码重置 (SSPR) 或 OATH 软件令牌为 GA。 有关预览版的详
细信息,请参阅 Microsoft Azure 预览版补充使用条款。

使用验证器应用的无密码 authentication 遵循与 Windows Hello 企业版相同的基本模式。 这会稍微复杂一些,因


为需要识别用户,以便 Azure AD 可以找到正在使用的 Microsoft Authenticator 应用程序版本:
1. 用户输入用户名。
2. Azure AD 检测到用户具有强凭据并启动强凭据流。
3. 通过 iOS 设备上的 Apple Push Notification 服务 (APNS) ,或通过 Android 设备上的 Firebase Cloud 消息传递
(FCM) 将通知发送到应用。
4. 用户收到推送通知并打开应用。
5. 该应用程序调用 Azure AD,并收到一项存在证据和 nonce。
6. 用户通过输入生物识别或 PIN 锁定私钥来完成质询。
7. Nonce 用私钥签名并发送回 Azure AD。
8. Azure AD 执行公钥/私钥验证并返回令牌。
若要开始无密码登录,请完成以下操作方法:

启用使用验证器应用的无密码签名

FIDO2 安全密钥
FIDO (快速标识联机) 联盟有助于提高开放式身份验证标准并减少使用密码作为身份验证形式。 FIDO2 是采用了
Web 身份验证 (WebAuthn) 标准的最新标准。
FIDO2 安全密钥是基于 unphishable 标准的无密码身份验证方法,可采用任何形式。 快速标识在线 (FIDO) 是用
于无密码 authentication 的开放标准。 FIDO 允许用户和组织利用标准登录到其资源,而无需使用外部安全密钥
或设备内置的平台密钥。

用户可以进行注册,然后在登录界面选择 FIDO2 安全密钥作为主要的身份验证方式。 这些 FIDO2 安全密钥通常


是 USB 设备,但也可以使用蓝牙或 NFC。 使用处理身份验证的硬件设备,由于不使用可能被公开或猜到的密码,
帐户的安全性会提高。

FIDO2 安全密钥可用于登录到其 Azure AD 或混合 Azure AD 加入 Windows 10 设备,并可在其云和本地资源上


进行单一登录。 用户还可以登录到受支持的浏览器。 对于安全敏感的企业而言,FIDO2 安全密钥是一个不错的
选择,或者不愿意或无法使用其电话作为第二个因素的方案或员工。

通过 FIDO2 安全密钥登录到 Azure AD 当前为预览版。 有关预览版的详细信息,请参阅 Microsoft Azure 预览版


补充使用条款。

当用户使用 FIDO2 安全密钥登录时,将使用以下过程:

1. 用户将 FIDO2 安全密钥插入到计算机中。


2. Windows 检测 FIDO2 安全密钥。
3. Windows 发送身份验证请求。
4. Azure AD 发回 nonce。
5. 用户完成其笔势以解锁存储在 FIDO2 安全密钥的 secure enclave 中的私钥。
6. FIDO2 安全密钥用私钥对 nonce 进行签名。
7. 向 Azure AD 发送带签名 nonce (PRT) 令牌请求的主刷新令牌。
8. Azure AD 使用 FIDO2 公钥验证签名 nonce。
9. Azure AD 返回 PRT 以启用对本地资源的访问。
尽管有很多密钥 FIDO2 通过 FIDO 联盟进行了认证,Microsoft 还是需要由供应商实现的 FIDO2 客户端到身份验
证器协议的一些可选扩展 (CTAP) 规范,以确保最高的安全性和最佳体验。

安全密钥 必 须 实现 FIDO2 CTAP 协议中的以下功能和扩展,才能与 Microsoft 兼容:

# / ?

1 居民密钥 此功能使安全密钥可移植,其中的凭据
存储在安全密钥上。

2 客户端 pin 利用此功能,你可以使用另一个因素来


保护凭据,并将其应用于没有用户界面
的安全密钥。

3 hmac 密钥 此扩展可确保你可以在设备处于脱机状
态或处于飞行模式时登录到你的设备。

4 每个 RP 多个帐户 此功能可确保你可以在多个服务(如
Microsoft 帐户和 Azure Active
Directory)上使用相同的安全密钥。

FIDO2 安全密 钥 提供程序


以下提供商提供了 FIDO2 安全密钥,它们具有已知兼容无密码体验的不同形式因素。 建议你通过联系供应商以
及 FIDO 联盟来评估这些密钥的安全属性。

Yubico https://www.yubico.com/support/contact/

Feitian https://ftsafe.us/pages/microsoft

HID https://www.hidglobal.com/contact-us

Ensurity https://www.ensurity.com/contact

TrustKey 解决方案 https://www.trustkeysolutions.com/security-keys/

AuthenTrend https://authentrend.com/about-us/#pg-35-3

Gemalto 身份 (Thales 组) https://safenet.gemalto.com/multi-factor-


authentication/authenticators/passwordless-authentication/

OneSpan Inc。 https://www.onespan.com/products/fido

IDmelon 技术 Inc。 https://www.idmelon.com/#idmelon


Hypersecu https://www.hypersecu.com/hyperfido

VinCSS https://passwordless.vincss.net

KONA I https://konai.com/business/security/fido

Excelsecu https://www.excelsecu.com/productdetail/esecufido2secu.ht
ml

瑞士 Token2 https://www.token2.swiss/shop/product/token2-t2f2-alu-
fido2-u2f-and-totp-security-key

NOTE
如果你购买并计划使用基于 NFC 的安全密钥,则需要为安全密钥提供支持的 NFC 读卡器。 NFC 读卡器不是 Azure 要求或
限制。 有关支持的 NFC 读卡器的列表,请与供应商联系以获取基于 NFC 的安全密钥。

如果你是供应商,并且想要在此支持的设备列表上获取设备,请联系 Fido2Request@Microsoft.com 。

若要开始 FIDO2 安全密钥,请完成以下操作方法:

启用使用 FIDO2 安全密钥的无密码签名

使用预览版的情况如何?
Azure AD 无密码登录功能当前以预览版提供。 请注意以下事项:
管理员可以为其租户启用无密码 authentication 方法
对于每个方法,管理员可面向所有用户或选择其租户中的用户/组
最终用户可以在其帐户门户中注册和管理这些无密码 authentication 方法
最终用户可以用这些无密码身份验证方法登录
Microsoft Authenticator 应用:在使用 Azure AD 身份验证的情况下,包括跨所有浏览器、在 Windows
10 全新版 (OOBE) 安装程序中,以及在任何操作系统上集成的移动应用。
安全密钥:在受支持的浏览器(如 Microsoft Edge)中使用针对 Windows 10 和 web 的锁定屏幕 (旧边缘
和新边缘) 。

选择无密码方法
这三个无密码选项之间的选择取决于公司的安全、平台和应用要求。

下面是在选择 Microsoft 无密码技术时要考虑的一些因素:

M IC RO SO F T
W IN DO W S H EL LO A UT H EN T IC ATO R F IDO 2

Windows 10 版本 1809 或 Microsoft Authenticator 应 Windows 10 版本1903或更


更高版本 用 高版本
Azure Active Directory 电话 (运行 Android 6.0 或更 Azure Active Directory
高版本的 iOS 和 Android 设
备。 )

Platform 软件 硬件
M IC RO SO F T
W IN DO W S H EL LO A UT H EN T IC ATO R F IDO 2

带有内置受信任的平台模块 电话上的 PIN 和生物识别识 FIDO2 兼容 Microsoft 的安


(TPM) 的 PC 别 全设备
PIN 和生物识别识别

使用 PIN 或生物识别识别登 使用带有指纹扫描、面部或 使用 FIDO2 security 设备登


录 (使用 Windows 设备的面 iris 识别或 PIN 的移动电话 录 (生物识别、PIN 和 NFC)
部) 、iris 或指纹。 登录。 用户可以基于组织控制和使
Windows Hello 身份验证已 用户从他们的 PC 或手机登 用设备(如 USB 安全密钥和
绑定到设备;用户需要设备和 录到工作帐户或个人帐户。 启用了 NFC 的智能卡、密钥
登录组件(如 PIN 或生物识 或可穿戴设备)的设备,基于
别因素)来访问公司资源。 PIN、生物识别来访问设备。

Windows 设备的无密码体 使用移动电话的无密码的任 使用生物识别、PIN 和 NFC


验。 意位置解决方案。 的辅助角色的无密码体验。
适用于专用于设备和应用程 适用于从任何设备访问 web 适用于共享 Pc,移动电话不
序的单一登录功能的工作 上的工作或个人应用程序。 是可行的选项 (例如,用于咨
PC。 询台人员、公共展台或医院
团队)

使用下表选择支持和用户的方法。

安全访问设备以执行管理任 分配的 Windows 10 设备 Windows Hello 企业版和/或


务 FIDO2 安全密钥

非 Windows 设备上的管理 移动或非 windows 设备 无密码 Microsoft


任务 Authenticator 应用登录

工作效率 分配的 Windows 10 设备 Windows Hello 企业版和/或


FIDO2 安全密钥

工作效率 移动或非 windows 设备 无密码 Microsoft


Authenticator 应用登录

工厂、植物、零售或数据输入 共享 Windows 10 设备 FIDO2 安全密钥


中的网亭

后续步骤
若要开始 Azure AD 中的无密码,请完成以下操作方法之一:

启用 FIDO2 安全密钥无密码登录
使用验证器应用启用基于手机的无密码登录

外部 链 接
FIDO 联盟
FIDO2 CTAP 规范
Azure ⽹络安全概述
2021/2/9 • • Edit Online

网络安全可以定义为通过对网络流量应用控制来保护资源遭受未经授权的访问或攻击的过程。 目标是确保仅允
许合法流量。 Azure 包括可靠的网络基础结构以支持应用程序和服务连接需求。 Azure 中的资源之间、本地资源
与 Azure 托管的资源之间,以及 Internet 与 Azure 之间都可能存在网络连接。

本文介绍 Azure 在网络安全方面提供的某些选项。 具体内容:

Azure 网络
网络访问控制
Azure 防火墙
安全远程访问和跨界连接
可用性
名称解析
外围网络 (DMZ) 体系结构
Azure DDoS 防护
Azure Front Door
流量管理器
监视和威胁检测

Azure 网络
Azure 要求将虚拟机连接到 Azure 虚拟网络。 虚拟网络是一个构建于物理 Azure 网络结构之上的逻辑构造。 每
个虚拟网络与其他所有虚拟网络相互隔离。 这可帮助确保其他 Azure 客户无法访问部署中的流量。

了解详细信息:

虚拟网络概述

网络访问控制
网络访问控制是限制虚拟网络内特定设备或子网之间的连接的行为。 网络访问控制的目的是将对虚拟机和服务
的访问权限限制为仅授予已批准的用户和设备。 访问控制基于虚拟机或服务之间的允许或拒绝连接的决策。

Azure 支持多种类型的网络访问控制,例如:
网络层控制
路由控制和强制隧道
虚拟网络安全设备

网 络层 控制
任何安全部署都需要某种程度的网络访问控制。 网络访问控制的目的是将虚拟机通信限制为必要的系统。 将阻
止其他通信尝试。

NOTE
要了解存储防火墙,请参阅 Azure 存储安全概述一文

网 络 安全 规则 (NSG)
如果需要基本的网络级别访问控制(基于 IP 地址和 TCP 或 UDP 协议),可使用网络安全组 (NSG)。 NSG 是基本
的静态数据包筛选防火墙,你可使用它来基于 5 元组控制访问。 NSG 包含的功能可以简化管理,并减少配置错
误的可能性:

扩 充式安全 规则 简化了 NSG 规则定义,并允许创建复杂规则,而无需创建多个简单规则来实现相同的结


果。
服 务标记 是 Microsoft 创建的标签,表示一组 IP 地址。 这些标记会动态更新,以包含符合在标签中定义包含
项的条件的 IP 范围。 例如,如果你要创建一个应用到东部区域的所有 Azure 存储的规则,可以使用
Storage.EastUS
应 用程序安全 组 可用于将资源部署到应用程序组,并通过创建使用这些应用程序组的规则来控制对这些资
源的访问。 例如,如果 Web 服务器已部署到“Webservers”应用程序组,则你可以创建一个规则,以便将允许
来自 Internet 的 443 流量的 NSG 应用到“Webservers”应用程序组中的所有系统。

NSG 不提供应用程序层检查或经过身份验证的访问控制。
了解详细信息:

网络安全组

ASC 实时 VM 访问
Azure 安全中心可以管理 VM 上的 NSG,并将对 VM 的访问权限锁定到具有相应 Azure 基于角色的访问控制
Azure RBAC 权限的用户请求访问为止。 如果成功为该用户授权,则 ASC 会对 NSG 进行修改,以允许在指定的
时间访问选定的端口。 该时间过后,NSG 将还原到其以前的受保护状态。

了解详细信息:

Azure 安全中心实时访问
服 务终结 点

服务终结点是对流量实施控制的另一种方式。 可以限制为只能在 VNet 中通过直接连接来与支持的服务通信。


从 VNet 发往指定 Azure 服务的流量保留在 Microsoft Azure 主干网络中。

了解详细信息:

服务终结点

路由控制和 强 制隧道
能够控制虚拟网络上的路由行为至关重要。 如果路由配置不正确,虚拟机上托管的应用程序和服务可能会连接
到未授权的设备,其中包括潜在攻击者所拥有或操作的系统。

Azure 网络支持在虚拟网络上为流量自定义路由行为。 由此可更改 Azure 虚拟网络中的默认路由表条目。 通过


控制路由行为,可帮助你确保特定设备或设备组中的所有流量通过特定位置进入或离开虚拟网络。

例如,虚拟网络上可能有虚拟网络安全设备。 想要确保与虚拟网络之间的所有流量都通过该虚拟安全设备。 可
以通过在 Azure 中配置用户定义的路由 (UDR) 实现此操作。

强制隧道是一种机制,可用于确保不允许服务启动与 Internet 上设备的连接。 请注意,这与接受并响应传入连接


不同。 前端 Web 服务器需要响应来自 Internet 主机的请求,因此允许源自 Internet 的流量传入到这些 Web 服务
器,并允许 Web 服务器作出响应。

不想要允许的是前端 Web 服务器发起出站请求。 此类请求可能带来安全风险,因为这些连接可用于下载恶意软


件。 即使想要这些前端服务器启动对 Internet 的出站请求,你可能想要强制它们通过本地 Web 代理服务器。 由
此可利用 URL 筛选和日志记录。

可以使用强制隧道来避免此问题。 启用强制隧道后,会强制与 Internet 的所有连接通过本地网关。 可以利用


UDR 配置强制隧道。
了解详细信息:
什么是用户定义的路由和 IP 转发

虚 拟 网 络 安全 设备
当 NSG、UDR 和强制隧道在 OSI 模型的网络层和传输层提供安全级别时,你可能也想要启用级别高于网络的安
全性。

例如,安全要求可能包括:

必须经过身份验证和授权才允许访问应用程序
入侵检测和入侵响应
高级别协议的应用程序层检查
URL 筛选
网络级别防病毒和反恶意软件
防 Bot 保护
应用程序访问控制
其他 DDoS 防护(除了 Azure 结构自身提供的 DDoS 防护以外)

可以使用 Azure 合作伙伴解决方案来访问这些增强的网络安全功能。 通过访问 Azure 市场并搜索“安全”和“网络


安全”,可以找到最新的 Azure 合作伙伴网络安全解决方案。

Azure 防火墙
Azure 防火墙是托管的基于云的网络安全服务,可保护 Azure 虚拟网络资源。 它是一个服务形式的完全有状态防
火墙,具有内置的高可用性和不受限制的云可伸缩性。 包括的一些功能为:

高可用性
云可伸缩性
应用程序 FQDN 筛选规则
网络流量筛选规则

了解详细信息:

Azure 防火墙概述

安全远程访问和跨界连接
安装、配置和管理 Azure 资源需要远程完成。 此外,你可能想要部署在本地和 Azure 公有云中具有组件的混合 IT
解决方案。 这些方案需要安全远程访问权限。

Azure 网络支持以下安全远程访问方案:
将单独的工作站连接到虚拟网络
通过 VPN 将本地网络连接到虚拟网络
通过专用的 WAN 链接将本地网络连接到虚拟网络
将虚拟网络相互连接

将 单 独的工作站 连 接到虚 拟 网 络
你可能想要让各个开发者或操作人员在 Azure 中管理虚拟机和服务。 例如,假设需要访问虚拟网络上的虚拟机。
但你的安全策略不允许 RDP 或 SSH 远程访问单独的虚拟机。 在这种情况下,可以使用点到站点 VPN 连接。

点到站点 VPN 连接允许你在用户和虚拟网络之间设置专用的安全连接。 建立 VPN 连接后,用户可通过 VPN 链


接将 RDP 或 SSH 连接到虚拟网络上的任何虚拟机。 (假设用户可以进行身份验证并获得授权。)点到站点 VPN
支持以下项:

安全套接字隧道协议 (SSTP),这是一种基于 SSL 的专属协议。 由于大多数防火墙都会打开 TLS/SSL 所用


的 TCP 端口 443 ,因此 SSL VPN 解决方案可以穿透防火墙。 只有 Windows 设备支持 SSTP。 Azure 支持
所有采用 SSTP 的 Windows 版本(Windows 7 和更高版本)。

IKEv2 VPN,这是一种基于标准的 IPsec VPN 解决方案。 IKEv2 VPN 可用于从 Mac 设备进行连接(OSX
10.11 和更高版本)。
OpenVPN
了解详细信息:

使用 PowerShell 配置与虚拟网络的点到站点连接

通过 VPN 将本地网 络连 接到虚 拟 网 络


你可能想要将整个企业网络或其中的某些部分连接到虚拟网络。 这是常见的混合 IT 方案,通过该方案组织可
以将其本地数据中心扩展到 Azure。 在许多情况下,组织在 Azure 和本地中各托管部分服务。 例如,当解决方案
包括 Azure 中的前端 Web 服务器和本地后端数据库时,他们可能会执行此操作。 这些类型的“跨界”连接还使得
位于 Azure 的资源的管理更加安全,并且能够启用方案,如将 Active Directory 域控制器扩展到 Azure 中。

实现此目的的方法之一是使用 站点到站点 VPN。 站点到站点 VPN 和点到站点 VPN 的区别在于后者将单个设备


连接到虚拟网络。 站点到站点 VPN 将整个网络(如本地网络)连接到虚拟网络。 连接到 Azure 虚拟网络的站点到
站点 VPN 使用高度安全的 IPsec 隧道模式 VPN 协议。

了解详细信息:

使用 Azure 门户创建具有站点到站点 VPN 连接的资源管理器 VNet


关于 VPN 网关

通 过专 用的
WAN 链 接将本地网 络连 接到虚 拟 网 络
点到站点和站点到站点 VPN 连接可以有效地启用跨界连接。 但是,某些组织认为它们存在以下缺点:

VPN 连接通过 Internet 移动数据。 这会导致这些连接存在通过公用网络移动数据所涉及的潜在安全问题。 此


外,不能保证 Internet 连接的可靠性和可用性。
到虚拟网络的 VPN 连接可能没有用于某些应用程序和目的带宽,因为它们达到的最高极限约为 200 Mbps。

需要最高安全性和可用性级别进行其跨界连接的组织通常使用专用 WAN 链路连接到远程网站。 凭借 Azure,可


使用专用的 WAN 链接将本地网络连接到虚拟网络。 Azure ExpressRoute、Express Route Direct 和 Express Route
Global Reach 实现了此功能。
了解详细信息:

ExpressRoute 技术概述
ExpressRoute 直接
Express Route Global Reach
将虚 拟 网 络 相互 连 接
可以将多个虚拟网络用于部署。 这样做的原因可能有很多。 你可能想要简化管理或提高安全性。 无论将资源放
在不同的虚拟网络上的动机是什么,可能有时你都会想要将一个网络上的资源与另一个网络相连接。

一个选择是通过 Internet 以“环回”方式将一个虚拟网络上的服务连接到另一个虚拟网络上的服务。 该连接将在


一个虚拟网络上开始,通过 Internet,再回到目标虚拟网络。 此选项会导致连接存在任何基于 Internet 的通信所
固有的安全问题。

创建两个虚拟网络之间相互连接的站点到站点 VPN 可能是最佳选择。 此方法与上述的跨界站点到站点 VPN 连


接使用相同的 IPSec 隧道模式协议。

此方法的优点是通过 Azure 网络结构建立 VPN 连接,而不是通过 Internet 进行连接。 与通过 Internet 连接的站
点到站点 VPN 相比,这提供了额外的安全层。

了解详细信息:
使用 Azure Resource Manager 和 PowerShell 配置 VNet 到 VNet 连接

连接到虚拟网络的另一种方式是使用 VNET 对等互连。 使用此功能可以连接两个 Azure 网络,使两者之间的通


信通过 Microsoft 主干基础结构进行,而永远无需通过 Internet。 VNET 对等互连可以连接到同一区域中的两个
VNET,或者两个跨 Azure 区域的 VNET。 可以使用 NSG 来限制不同子网或系统之间的连接。

可用性
可用性是任何安全程序的重要组件。 如果用户和系统无法通过网络访问需要访问的内容,则可以认为服务已遭
入侵。 Azure 的网络技术支持以下高可用性机制:

基于 HTTP 的负载均衡
网络级别负载均衡
全局负载均衡

负载均衡是一种机制,旨在将连接平均分布到多个设备。 负载均衡的目标如下:

提高可用性。 在跨多个设备对连接进行负载均衡时,一个或多个设备可能变得不可用,但不影响服务。 在剩
余的联机设备上运行的服务可继续提供服务中的内容。
提高性能。 在跨多个设备对连接进行负载均衡时,单个设备不必负责所有处理。 提供内容的处理和内存需求
分散在多个设备之间。

基于HTTP 的 负载 均衡
运行基于 Web 的服务的组织通常希望在这些 Web 服务前面具有基于 HTTP 的负载均衡器。 这可帮助确保足够
级别的性能和高可用性。 基于网络的传统负载均衡器依赖于网络和传输层协议。 另一方面,基于 HTTP 的负载均
衡器根据 HTTP 协议的特性做出决策。

Azure 应用程序网关为基于 Web 的服务提供了基于 HTTP 的负载均衡。 应用程序网关支持:


基于 Cookie 的会话关联。 此功能可确保建立到负载均衡器后面的某个服务器的连接在客户端和服务器之间
保持不变。 此操作确保了事务的稳定性。
TLS 卸载。 当客户端与负载均衡器连接时,会话使用 HTTPS (TLS) 协议进行加密。 但是,为了提高性能,可以
使用 HTTP(未加密)协议在负载均衡器和该负载均衡器后面的 Web 服务器之间进行连接。 这称为“TLS 卸
载”,因为负载均衡器后面的 Web 服务器不会遇到涉及加密的处理器开销。 因此 Web 服务器可更快地为请求
提供服务。
基于 URL 的内容路由。 此功能可使负载均衡器决定在哪里转接基于目标 URL 的连接。 它提供的弹性大于基
于 IP 地址做出负载均衡决策的解决方案。

了解详细信息:

应用程序网关概述

网 络级别负载 均衡
与基于 HTTP 的负载均衡相比,网络级别负载均衡基于 IP 地址和端口(TCP 或 UDP)号做出决策。 使用 Azure 负
载均衡器,可以在 Azure 中获得网络级别负载均衡的优点。 负载均衡器的一些主要特征包括:

基于 IP 地址和端口号的网络级别负载均衡。
支持任何应用层协议。
对 Azure 虚拟机和云服务角色实例进行负载均衡。
可用于面向 Internet(外部负载均衡)和面向非 Internet(内部负载均衡)的应用程序和虚拟机。
终结点监视,可用于确定负载均衡器后面的任何服务是否已变得不可用。

了解详细信息:

多个虚拟机或服务之间的面向 Internet 的负载均衡器


内部负载均衡器概述
全局 负载 均衡
某些组织可能想要最高级别的可用性。 实现此目标的方法之一是将应用程序托管到全球分布的数据中心。 在分
布于世界各地的数据中心托管应用程序时,即使整个地缘政治区域变得不可用,应用程序也可以启动并运行。

此负载平衡策略也可暂停性能优势。 可直接向距离提出请求的设备最近的数据中心请求服务。

在 Azure 中,使用 Azure 流量管理器可以获得全局负载均衡的优点。

了解详细信息:

什么是流量管理器?

名称解析
名称解析是对 Azure 中托管的所有服务而言至关重要的功能。 从安全角度看,入侵名称解析功能可能会导致攻
击者将你站点的请求重定向到攻击者的站点。 安全名称解析是所有云托管服务的要求。

需要解决两种类型的名称解析:

内部名称解析。 虚拟网络和/或本地网络上的服务使用此名称解析。 用于内部名称解析的名称无法通过


Internet 访问。 为了获取最高安全性,外部用户不能访问内部名称解析方案,这一点非常重要。
外部名称解析。 本地网络和虚拟网络之外的人员和设备使用此名称解析。 这些是对 Internet 可见且用于将连
接定向到基于云的服务的名称。

对于内部名称解析,可以使用两个选项:

虚拟网络 DNS 服务器。 创建新的虚拟网络时,会为你创建 DNS 服务器。 此 DNS 服务器可以解析位于该虚拟


网络上的计算机的名称。 此 DNS 服务器是不可配置的,而且由 Azure 结构管理器进行管理,从而帮助对名称
解析解决方案进行安全保护。
自带 DNS 服务器。 可选择将自己选择的 DNS 服务器放置在虚拟网络上。 此 DNS 服务器可以是 Active
Directory 集成的 DNS 服务器或由 Azure 合作伙伴提供的专用 DNS 服务器解决方案,两者均可从 Azure 市场
中获得。

了解详细信息:

虚拟网络概述
管理虚拟网络使用的 DNS 服务器

对于外部名称解析,有两个选项:

在本地托管自己的外部 DNS 服务器。


通过服务提供程序托管自己的外部 DNS 服务器。

许多大型组织在本地托管自己的 DNS 服务器。 可以这样做的原因是它们具有相应的网络专业技术,并且在全球


运营。

在大多数情况下,最好在服务提供商那里托管 DNS 名称解析服务。 这些服务提供商具有网络专业技术并在全球


运营,可确保名称解析服务具有极高的可用性。 可用性是 DNS 服务所必需的,因为如果名称解析服务失败,则
任何人都将无法访问面向 Internet 的服务。

Azure 以 Azure DNS 的形式提供一个高可用性且高性能的外部 DNS 解决方案。 此外部名称解析解决方案利用全


球 Azure DNS 基础结构。 由此可使用与其他 Azure 服务相同的凭据、API、工具和计费在 Azure 中托管域。 由于
属于 Azure 的一部分,它还会继承平台内置的强大安全控制。

了解详细信息:

Azure DNS 概述
使用 Azure DNS 专用区域可为 Azure 资源配置专用的 DNS 名称而不是自动分配的名称,且无需添加自定义
DNS 解析。
外围网络体系结构
许多大型组织使用外围网络对其网络进行分段,并在 Internet 及其服务之间创建缓冲区域。 网络的外围部分被
视为一个低安全区域,而且不会将重要的资产放在该网络段中。 通常会看到在外围网络段上具有网络接口的网
络安全设备。 将另一个网络接口连接到具有接受来自 Internet 的入站连接的虚拟机和服务的网络。

可通过多种不同的方式设计外围网络。 部署外围网络的决策以及决定使用哪种类型的外围网络取决于你的网络
安全需求。

了解详细信息:

Microsoft 云服务和网络安全

Azure DDoS 防护
分布式拒绝服务 (DDoS) 攻击是将应用程序移动到云的客户所面临的一些最大的可用性和安全性问题。 DDoS 攻
击尝试耗尽应用程序的资源,使应用程序对于合法用户不可用。 DDoS 攻击可能会将任何可通过 Internet 公开访
问的终结点作为目标。 Microsoft 提供“基本”DDoS 防护作为 Azure 平台的一部分。 此防护功能是免费的,包含针
对常见网络级攻击的不间断监视和实时缓解。 除了“基本”DDoS 防护随附的保护以外,还可以启用“标准”选项。
DDoS 保护标准功能包括:
本机平台集成: 本机集成到 Azure 中。 包括通过 Azure 门户进行配置。 DDoS 保护标准了解你的资源和资源
配置。
统 包保 护 : 一旦启用 DDoS 保护标准,简化后的配置会立即保护虚拟网络上的所有资源。 要求没有干预或用
户定义。 一旦检测到攻击,标准 DDoS 保护会立即自动减轻攻击。
始 终 可用的流量 监 控: 应用程序流量模式将全天候受到监控,以寻找 DDoS 攻击的迹象。 将在超出保护策略
范围时执行缓解措施。
攻 击缓 解 报 表 攻击缓解报表使用聚合的网络流数据提供有关针对你的资源的攻击的详细信息。
攻 击缓 解流日志 通过攻击缓解流日志,可在活动 DDoS 攻击期间近乎实时地查看丢弃的流量、转发的流量和
其他攻击数据。
自适 应优 化: 智能流量分析了解应用程序在一段时间内的流量,并选择和更新最适合服务的配置文件。 当流
量随时间变化时,配置文件将进行调整。 第 3 层到第 7 层保护:与 Web 应用程序防火墙配合使用时,提供完
整的堆栈 DDoS 保护。
广泛的 缓 解 规 模: 可以使用全球容量缓解超过 60 种不同攻击类型,从而防止最大的已知 DDoS 攻击。
攻 击 指 标 : 可以通过 Azure Monitor 访问每个攻击的汇总指标。
攻 击 警 报 : 可以使用内置攻击指标在攻击开始和停止时以及攻击持续期间配置警报。 警报集成到操作软件,
如 Microsoft Azure 监视日志、Splunk、Azure 存储、电子邮件和 Azure 门户。
成本保 证 : 记录的 DDoS 攻击的数据传输和应用程序横向扩展服务信用度。
DDoS 快速响 应 DDoS 防护标准版客户可以在攻击正在进行时联系“快速响应”团队。 DRR 可以帮助进行攻
击调查,在攻击发生期间定制缓解措施以及进行攻击后分析。

了解详细信息:

DDOS 防护概述

Azure Front Door


使用 Azure Front Door 服务,你可以定义、管理和监视 Web 流量的全局路由。 它可以优化流量的路由以实现最
佳性能和高可用性。 Azure Front Door 允许编写自定义 Web 应用程序防火墙 (WAF) 规则进行访问控制,以基于
客户端 IP 地址、国家/地区代码和 http 参数来防范 HTTP/HTTPS 工作负荷遭到恶意利用。 此外,前门还允许您创
建速率限制规则来分担恶意 bot 流量,包括 TLS 卸载和每个 HTTP/HTTPS 请求、应用层处理。

Front Door 平台本身由 Azure DDoS 防护基本版提供保护。 若要进一步提供保护,可在 VNET 中启用 Azure
DDoS 防护标准版,并通过自动优化和缓解措施来防范资源遭到网络层 (TCP/UDP) 攻击。 Front Door 是第 7 层
反向代理,它仅允许 Web 流量通过后端服务器,默认会阻止其他类型的流量。

了解详细信息:

若要了解有关 Azure Front Door 的完整功能的详细信息,可以查看 Azure Front Door 概述

Azure 流量管理器
Azure 流量管理器是一种基于 DNS 的流量负载均衡器,可以在全球 Azure 区域内以最佳方式向服务分发流量,
同时提供高可用性和响应性。 流量管理器根据流量路由方法和终结点的运行状况,使用 DNS 将客户端请求定向
到最合适的服务终结点。 终结点可以是托管在 Azure 内部或外部的任何面向 Internet 的服务。 流量管理器对终
结点进行监视,并且不会将流量定向到不可用的任何终结点。

了解详细信息:

Azure 流量管理器概述

监视和威胁检测
Azure 提供相关功能来帮助在此关键领域中进行早期检测、监视,并收集和查看流量。
Azure 网 络观 察程序
Azure 网络观察程序 可帮助进行排除故障,并提供一套全新的工具来协助识别安全问题。
安全组视图有助于审核以及符合虚拟机的安全要求。 使用此功能执行编程审核,将组织定义的基线策略与每台
VM 的有效规则进行比较。 这有助于识别任何配置偏移。
通过数据包捕获可以捕获流向和流出虚拟机的网络流量。 可收集网络统计信息并对应用程序问题进行故障排
除,这对调查网络入侵非常有用。 此功能还可与 Azure Functions 一起使用,使其根据特定 Azure 警报启动网络
捕获。

若要深入了解网络观察程序以及如何开始测试实验室中的一些功能,请参阅 Azure 网络观察程序监视概述。

NOTE
有关此服务可用性和状态方面的最新通知,请参阅 Azure 更新页。

Azure 安全中心
Azure 安全中心帮助你预防、检测和响应威胁,同时提高 Azure 资源的可见性并控制其安全性。 它提供对 Azure
订阅的集成安全监视和策略管理,帮助检测可能被忽略的威胁,且适用于大量的安全解决方案。

安全中心通过以下方式来帮助优化和监视网络安全:

提供网络安全建议。
监视网络安全配置的状态。
在终结点和网络级别发出基于网络的威胁警报。

了解详细信息:

Azure 安全中心简介
虚拟网络 TAP
通过 Azure 虚拟网络 TAP(终端接入点),可让你持续将虚拟机网络流量流式传输到网络数据包收集器或分析工
具。 收集器或分析工具是由网络虚拟设备合作伙伴提供的。 你可以使用相同的虚拟网络 TAP 资源来聚合来自相
同或不同订阅的多个网络接口的流量。

了解详细信息:
虚拟网络 TAP

日志 记录
网络级别的日志记录是任何网络安全方案的重要功能。 在 Azure 中,可以记录针对 NSG 获得的信息,以获取网
络级别的日志记录信息。 使用 NSG 日志记录可从以下来源获取信息:

活动日志。 使用这些日志查看提交到 Azure 订阅的所有操作。 默认情况下,这些日志已启用并可在 Azure 门


户中使用。 这些日志以前称为审核或操作日志。
事件日志。 这些日志提供有关应用了哪些 NSG 规则的信息。
计数器日志。 通过这些日志,可知道所应用每个 NSG 规则拒绝或允许流量的次数。

还可以使用功能强大的数据可视化工具 Microsoft Power BI 来查看和分析这些日志。 了解详细信息:

网络安全组 (NSG) 的 Azure Monitor 日志


Azure ⽹络安全最佳做法
2021/2/9 • • Edit Online

本文介绍一系列 Azure 最佳做法以增强网络安全。 这些最佳实践衍生自我们的 Azure 网络经验和客户的经验。

对于每项最佳实践,本文将说明:

最佳实践是什么
为何要启用该最佳实践
如果无法启用该最佳实践,可能的结果是什么
最佳实践的可能替代方案
如何学习启用最佳实践

这些最佳做法以共识以及 Azure 平台功能和特性集(因为在编写本文时已存在)为基础。 看法和技术将随着时间


改变,本文会定期更新以反映这些更改。

使用强网络控制
你可以将 Azure虚拟机 (VM) 和设备放在 Azure虚拟网络上,从而将它们连接到其他网络设备。 也就是说,可以将
虚拟网络接口卡连接到虚拟网络,允许启用了网络的设备之间进行基于 TCP/IP 的通信。 连接到 Azure 虚拟网络
的虚拟机能够连接到相同虚拟网络、不同虚拟网络、Internet 或自己的本地网络上的设备。

规划网络和网络安全性时,建议集中执行以下操作:

管理核心网络功能,如 ExpressRoute、虚拟网络和子网预配以及 IP 寻址。


治理网络安全元素,如 ExpressRoute、虚拟网络和子网预配以及 IP 寻址等网络虚拟设备功能。

如果使用一组通用的管理工具来监视网络和网络的安全性,则可清楚地了解这两者。 一种简单、统一的安全策略
可减少错误,因为这会改善人员理解和自动化可靠性。

以逻辑方式分段子网
Azure 虚拟网络类似于本地网络上的 LAN。 Azure 虚拟网络背后的思路是创建基于单个专用 IP 地址空间的网
络,以将所有Azure 虚拟机置于其上。 可用的专用 IP 地址空间位于类别 A (10.0.0.0/8)、类别 B (172.16.0.0/12) 和
类别 C (192.168.0.0/16) 范围内。

以逻辑方式对子网进行分段的最佳做法包括:

最佳做法 :不要分配具有广泛范围的允许规则(例如,允许 0.0.0.0 到 255.255.255.255 )。


详细 信息 :确保故障排除过程不会建议或禁止设置这些类型的规则。 这些允许规则会导致错误的安全感,经常被
红队发现并利用。

最佳做法 :将较大的地址空间分段成子网。
详细 信息 :使用基于 CIDR 的子网原理来创建子网。

最佳做法 :在子网之间创建网络访问控制。 子网之间的路由会自动发生,不需要手动配置路由表。 默认情况下,


在 Azure 虚拟网络上创建的子网之间没有任何网络访问控制。
详细 信息 :使用 网络安全组防止未经请求的流量进入 Azure 子网。 网络安全组是简单的有状态数据包检查设
备,使用 5 元组方法(源 IP、源端口、目标 IP、目标端口和第 4 层协议)来创建网络流量的允许/拒绝规则。 可以允
许或拒绝流往或来自单个 IP 地址、多个 IP 地址或整个子网的流量。

将网络安全组用于子网之间的网络访问控制时,可将属于同一安全区域或角色的资源置于其本身的子网中。
最佳做法 :避免小型虚拟网络和子网,以确保简易性和灵活性。
详细 信息 :大多数组织会添加比最初计划更多的资源,重新分配地址是劳动密集型工作。 使用小型子网会增加有
限的安全值,将网络安全组映射到每个子网会增加开销。 广泛定义子网,以确保具有增长灵活性。

最佳做法 :通过定义 应用程序安全组来简化网络安全组规则管理。


详细 信息 :为你认为将来可能会更改或是在许多网络安全组间使用的 IP 地址列表定义一个应用程序安全组。 务
必清楚地命名应用程序安全组,以便其他人可以理解其内容和用途。

采用零信任方法
基于外围的网络在工作时假设网络中的所有系统都可以受信任。 但当前的员工会通过各种设备和应用,从任何
位置访问其组织的资源,这使得外围安全控制不适用。 仅关注可以访问资源的用户的访问控制策略是不够的。
为了掌握安全与效率之间的平衡,安全管理员还需要考虑访问资源的方式。

网络需要从传统防御进行演化,因为网络可能容易受到侵害:攻击者可能会破坏受信任边界内的单个终结点,然
后在整个网络中快速扩展立足点。 零信任网络消除了基于外围中的网络位置的信任概念。 相反,零信任体系结
构使用设备和用户信任声明来获取组织数据和资源的访问权限。 对于新计划,采用在访问时验证信任的零信任
方法。

最佳做法包括:

最佳做法 :基于设备、标识、保证、网络位置等提供对资源的条件访问。
详细 信息 :Azure AD 条件访问使你可以根据所需条件实现自动访问控制决策,从而应用正确的访问控制。 有关
详细信息,请参阅使用条件访问管理对 Azure 管理的访问。

最佳做法 :仅在工作流审批之后才启用端口访问。
详细 信息 :可以使用 Azure Security Center 中的 实时 VM 访问来锁定发往 Azure VM 的入站流量,降低遭受攻击
的可能性,同时在需要时还允许轻松连接到 VM。

最佳做法 :授予执行特权任务的临时权限,防止恶意用户或未授权用户在权限过期后获得访问权限。 只有在用户


需要的情况下,才会授予访问权限。
详细 信息 :使用 Azure AD Privileged Identity Management 或第三方解决方案中的实时访问来授予执行特权任务
的权限。

零信任是网络安全的下一步发展。 网络攻击的状态促使组织采用“假定违规”思维方式,但这种方法不应受到限
制。 零信任网络可保护公司数据和资源,同时确保组织可以使用相关技术来构建新式工作区,这些技术使员工能
够以任何方式随时随地提高工作效率。

控制路由行为
将虚拟机置于 Azure 虚拟网络时,即使其他 VM 位于不同的子网,VM 也可以连接到同一虚拟网络上的任何其他
VM。 这是可能的,原因是默认启用的系统路由集合允许这种类型的通信。 这些默认路由可让相同虚拟网络上的
VM 彼此发起连接,以及与 Internet 连接(仅适用于 Internet 的出站通信)。
尽管默认系统路由适用于许多部署方案,但有时也需要针对部署自定义路由配置。 可以配置下一个跃点地址,用
于访问特定目标。

建议你在为虚拟网络部署安全设备时配置用户定义的路由。 我们将在后面的标题为保护关键的 Azure 服务资


源,只允许在客户自己的虚拟网络中对其进行访问的部分中讨论此问题。

NOTE
不需要用户定义的路由,默认的系统路通常有效。

使用虚拟网络设备
网络安全组和用户定义的路由可以在网络和 OSI 模型的传输层上提供一定的网络安全措施。 但在某些情况下,
建议在高级别堆栈中启用安全性。 在此类情况下,建议部署 Azure 合作伙伴所提供的虚拟网络安全设备。

Azure 网络安全设备可提供比网络级控制所提供的更高的安全性。 虚拟网络安全设备的网络安全功能包括:


防火墙
入侵检测/入侵防护
漏洞管理
应用程序控制
基于网络的异常检测
Web 筛选
防病毒
僵尸网络防护

要查找可用的 Azure 虚拟网络安全设备,请转到 Azure 市场并搜索“安全”和“网络安全”。

为安全区部署外围网络
外围网格(也称为 DMZ)是物理或逻辑网络区段,可在资产与 Internet 之间提供额外的安全层。 外围网络边缘的
专用网络访问控制设备只允许所需流量流入虚拟网络。

外围网络非常有用,因为可以将网络访问控制管理、监视、日志记录和报告的重点放在位于 Azure 虚拟网络边缘


的设备上。 在外围网络中通常将启用分布式拒绝服务 (DDoS) 预防、入侵检测/入侵防护系统 (IDS/IPS)、防火墙规
则和策略、Web 筛选、网络反恶意软件等。 网络安全设备位于 Internet 与 Azure 虚拟网络之间,在两个网络上均
有接口。

尽管这是外围网络的基本设计,但有许多不同的设计,例如背靠背式、三闸式、多闸式。

基于前面提到的零信任概念,建议考虑将外围网络用于所有高安全性部署,以增强 Azure 资源的网络安全和访问


控制级别。 可以使用 Azure 或第三方解决方案在资产与 Internet 之间提供额外的安全层:

Azure 本机控制。 Azure 防火墙和应用程序网关中的 Web 应用程序防火墙通过完全有状态防火墙即服务、内


置高可用性、无限制的云可伸缩性、FQDN 筛选、对 OWASP 核心规则集的支持以及简单的设置和配置,来提
供基本安全性。
第三方产品/服务。 在 Azure 市场中搜索下一代防火墙 (NGFW) 和其他第三方产品/服务,它们可提供熟悉的
安全工具和显著增强的网络安全级别。 配置可能会更加复杂,但第三方产品/服务可能会允许你使用现有功能
和技能组。

避免向具有专用 WAN 链接的 Internet 公开


许多组织选择了混合 IT 路由。 使用混合 IT 时,有些企业的信息资产是在 Azure 中,而有些企业则维持在本地。
在许多情况下,服务的某些组件在 Azure 中运行,而其他组件则维持在本地。

在混合 IT 方案中,通常有某种类型的跨界连接。 跨界连接可让公司将其本地网络连接到 Azure 虚拟网络。 可用


的跨界连接解决方案有两种:

站点到站点 VPN。 它是一种值得信赖、可靠且成熟的技术,但连接是通过 Internet 进行的。 带宽限制在 1.25


Gbps 左右。 在某些情况下,站点到站点 VPN 是一个理想选择。
Azure ExpressRoute。 建议使用 ExpressRoute 进行跨界连接。 使用 ExpressRoute 可通过连接服务提供商所提
供的专用连接,将本地网络扩展到 Microsoft 云。 借助 ExpressRoute,你可以与 Microsoft 云服务(如 Azure、
Microsoft 365 和 Dynamics 365)建立连接。 ExpressRoute 是你本地位置与 Microsoft Exchange 托管提供商
之间专用的 WAN 链接。 因为这是电信运营商连接,所以数据不会通过 Internet 传输,也不会暴露在 Internet
通信的潜在风险中。

ExpressRoute 连接的位置可能会影响防火墙容量、可伸缩性、可靠性和网络流量可见性。 需要确定在现有(本地)


网络中终止 ExpressRoute 的位置。 可以:

如果需要查看流量、需要继续执行隔离数据中心的现有做法或者只是将 extranet 资源放在 Azure 上,请在防


火墙之外终止(外围网络范例)。
在防火墙之内终止(网络扩展范例)。 这是默认建议。 在所有其他情况下,建议将 Azure 视为第 n 个数据中
心。

优化运行时间和性能
如果服务已关闭,便无法访问信息。 如果性能太差而无法使用数据,则可以将此数据视为无法访问。 从安全角度
来看,需要尽可能确保服务有最佳的运行时间和性能。

用于增强可用性和性能的常用且有效的方法是负载均衡。 负载均衡是将网络流量分布于服务中各服务器的方
法。 例如,如果服务中有前端 Web 服务器,可以使用负载均衡将流量分布于多台前端 Web 服务器。

这种流量分布将提高可用性,因为如果其中一台 Web 服务器不可用,负载均衡器停止将流量发送到该服务器,


并将它重定向到仍在运行的服务器。 负载均衡还对性能有帮助,因为处理请求的处理器、网络和内存开销将分布
于所有负载均衡的服务器之间。

建议尽可能为服务采用适当的负载均衡。 以下是 Azure 虚拟网络级别和全球级别的方案,以及每个级别的负载


均衡选项。

情形 :你有如下应用程序:

要求来自同一用户/客户端会话的请求访问相同后端虚拟机。 此类示例如购物车应用和 Web 邮件服务器。


仅接受安全连接,因此与服务器进行未加密的通信是不可接受的选项。
要求将长时间运行的同一 TCP 连接上多个 HTTP 请求路由到或负载均衡到不同的后端服务器。

负载 均衡 选项 :使用 Azure 应用程序网关,一个 HTTP Web 流量负载均衡器。 应用程序网关支持网关上的端到


端 TLS 加密和 TLS 终止。 然后,Web 服务器可以免受加密和解密开销以及未加密流向后端服务器的流量的负
担。

情形 :需要在位于 Azure 虚拟网络中的服务器之间对来自 Internet 的传入连接进行负载均衡。 也就是说当:

具有接受来自 Internet 的传入请求的无状态应用程序时。


不需要粘性会话或 TLS 卸载时。 粘性会话是与应用程序负载均衡一起使用的方法,用于实现服务器关联。

负载 均衡 选项 :使用 Azure 门户 创建外部负载均衡器,该均衡器将多个 VM 之间的传入请求进行分散,以提供


更高级别的可用性。

情形 :需要从不在 Internet 上的 VM 对连接进行负载均衡。 大多数情况下,接受的用于进行负载均衡的连接由


Azure 虚拟网络上的设备发起,例如 SQL Server 实例或内部 Web 服务器。
负载 均衡 选项 :使用 Azure 门户 创建内部负载均衡器,该均衡器将多个 VM 之间的传入请求进行分散,以提供
更高级别的可用性。

情形 :你需要全球负载均衡,因为:

拥有广泛分布在多个地区的云解决方案,并且需要可能的最高级别的正常运行时间(可用性)。
需要可能的最高级别的正常运行时间,以确保即使整个数据中心不可用,服务仍然可用。

负载 均衡 选项 :使用 Azure 流量管理器。 流量管理器可以根据用户的位置,对服务的连接进行负载均衡。

例如,如果用户从欧盟对服务发出请求,此连接会被定向到位于欧盟数据中心的服务。 这一部分的流量管理器全
局负载均衡有助于改善性能,因为连接到最近的数据中心比连接到远处的数据中心还要快。

禁用对虚拟机的 RDP/SSH 访问
使用远程桌面协议 (RDP) 和安全外壳 (SSH) 协议可以访问 Azure 虚拟机。 这些协议支持远程管理 VM,并且是数
据中心计算中的标准协议。

在 Internet 上使用这些协议的潜在安全问题是,攻击者可以使用暴力破解技术来访问 Azure 虚拟机。 攻击者获


取访问权限后,就可以使用 VM 作为破坏虚拟网络上其他计算机的启动点,甚至攻击 Azure 之外的网络设备。

我们建议禁用从 Internet 对 Azure 虚拟机的直接 RDP 和 SSH 访问。 禁用从 Internet 的直接 RDP 和 SSH 访问之
后,有其他选项可用于访问这些 VM 以便进行远程管理。

情形 :可让单个用户通过 Internet 连接到 Azure 虚拟网络。


选项 :点到站点 VPN 是远程访问 VPN 客户端/服务器连接的另一种说法。 建立点到站点连接之后,用户能够使
用 RDP 或 SSH 连接到位于用户通过点到站点 VPN 连接的 Azure 虚拟网络上的任何 VM。 此处假设用户有权访
问这些 VM。

点到站点 VPN 比直接 RDP 或 SSH 连接更安全,因为用户必须事先通过两次身份验证才将连接到 VM。 首先,用


户需要进行身份验证(并获得授权)以建立点到站点 VPN 连接。 其次,用户需要进行身份验证(并获得授权)以建
立 RDP 或 SSH 会话。

情形 :使本地网络上的用户能够连接到 Azure 虚拟网络上的 VM。


选项 :站点到站点 VPN 通过 Internet 将整个网络连接到另一个网络。 可以使用站点到站点 VPN 将本地网络连接
到 Azure 虚拟网络。 本地网络上的用户通过站点到站点 VPN 使用 RDP 或 SSH 协议进行连接。 不必允许通过
Internet 进行的直接 RDP 或 SSH 访问。
情形 :使用专用的 WAN 链接提供类似于站点到站点 VPN 的功能。
选项 :使用 ExpressRoute。 它提供类似于站点到站点 VPN 的功能。 它们的主要区别包括:

专用的 WAN 链接不会遍历 Internet。


专用的 WAN 链接通常更稳定且性能更佳。

保护关键的 Azure 服务资源,只允许在客户自己的虚拟网络中对其进行


访问
使用 Azure 专用链接访问 Azure PaaS 服务 (例如,Azure 存储和 SQL 数据库) 通过虚拟网络中的专用终结点。 专
用终结点允许你将关键 Azure 服务资源仅保护到虚拟网络。 从虚拟网络发往 Azure 服务的流量始终保留在
Microsoft Azure 主干网络中。 不再需要使用 Azure PaaS 服务将虚拟网络公开到公共 internet。
Azure Private Link 具有以下优势:
提高 azure 服 务资 源的安全性 :借助 Azure 专用链接,可以使用专用终结点将 Azure 服务资源保护到虚拟
网络。 将服务资源保护到虚拟网络中的专用终结点可通过完全删除资源的公共 internet 访问权限,并仅允许
来自虚拟网络中专用终结点的流量,从而提高了安全性。
在 azure 平台上私下 访问 azure 服 务资 源 :使用专用终结点将虚拟网络连接到 azure 中的服务。 不需要公
共 IP 地址。 专用链接平台将通过 Azure 主干网络处理使用者与服务之间的连接。
从本地和 对 等互 连 网 络访问 :通过 ExpressRoute 专用对等互连、VPN 隧道和使用专用终结点的对等互连虚
拟网络,从本地在 Azure 中运行的访问服务。 无需配置 ExpressRoute Microsoft 对等互连或遍历 Internet 即
可访问服务。 专用链接可让客户安全地将工作负荷迁移到 Azure。
防范数据泄露 :专用终结点映射到 PaaS 资源的某个实例,而不是映射到整个服务。 使用者只能连接到特定的
资源。 对服务中任何其他资源的访问将遭到阻止。 此机制可以防范数据泄露风险。
全球覆盖 :以私密方式连接到在其他区域中运行的服务。 使用者的虚拟网络可以在区域 A 中,它可以连接到
区域 B 中的服务。
易于 设 置和管理 :你不再需要在虚拟网络中保留的公共 IP 地址来通过 IP 防火墙保护 Azure 资源。 设置专用
终结点不需要 NAT 或网关设备。 专用终结点通过简单的工作流进行配置。 在服务端,你还可以轻松地管理
Azure 服务资源上的连接请求。 Azure 专用链接适用于属于不同 Azure Active Directory 租户的使用者和服
务。

若要了解有关专用终结点的详细信息以及可供使用的 Azure 服务和区域的详细信息,请参阅 Azure Private Link。


后续步骤
有关通过 Azure 设计、部署和管理云解决方案时可以使用的更多安全最佳做法,请参阅 Azure 安全最佳做法和模
式。
基本最佳做法
2021/2/9 • • Edit Online

以下部分提供了有关在 Azure 中构建弹性应对 DDoS 的服务的规范性指导。

安全设计
确保优先考虑从设计和实施到部署和操作的整个应用程序生命周期的安全性。 应用程序可能包含 bug,使相对
较少的请求使用过多的资源,导致服务中断。

为帮助保护 Microsoft Azure 上运行的服务,应该对应用程序体系结构有充分的了解,并重点关注软件质量的五


大要素。 应该清楚典型的流量大小、应用程序与其他应用程序之间的连接模型,以及向公共 Internet 公开的服务
终结点。

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

可伸缩性设计
可伸缩性是指系统处理增加的负载的能力。 采用可横向缩放的应用程序设计,以满足放大负载的需求,尤其是防
范 DDoS 攻击。 如果应用程序依赖于服务的单个实例,则会造成单一故障点。 预配多个实例能够提高复原能力
和可伸缩性。

对于 Azure 应用服务,请选择提供多个实例的应用服务计划。 对于 Azure 云服务,请将每个角色配置为使用多个


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

深层防御
深层防御的理念是通过多样化的防御策略来掌控风险。 应用程序中的分层安全防御可以减少攻击成功的可能
性。 我们建议使用 Azure 平台的内置功能对其应用程序实施安全设计。

例如,攻击风险会随着应用程序的规模(外围应用)的增大而增大。 你可以通过使用审批列表来关闭公开的 IP 地
址空间,并将负载平衡器上不需要的侦听端口关闭 (Azure 负载平衡器 和 Azure 应用程序网关) ,从而减少外围
应用。 网络安全组 (NSG) 是缩小受攻击面的另一种方法。 可以使用服务标记和应用程序安全组来最大程度地简
化安全规则的创建,并将网络安全性配置为应用程序结构的自然扩展。

应尽可能地在虚拟网络中部署 Azure 服务。 这种做法可让服务资源通过专用 IP 地址通信。 来自虚拟网络的


Azure 服务流量默认使用公共 IP 地址作为源 IP 地址。 使用服务终结点时,服务流量会在通过虚拟网络访问
Azure 服务时改用虚拟网络专用地址作为源 IP 地址。
我们经常看到,客户本地资源会连同其在 Azure 中资源的一起受到攻击。 如果将本地环境连接到 Azure,我们建
议尽量不要在公共 Internet 上公开本地资源。 可以通过在 Azure 中部署已知的公共实体,来利用 Azure 的规模
和高级 DDoS 防护功能。 由于这些可公开访问的实体通常会成为 DDoS 攻击的目标,将它们放在 Azure 中可以
降低对本地资源的影响。

后续步骤
了解如何 创建 DDoS 保护计划。
Azure DDoS 保护标准的 azure 安全基线
2021/2/9 • • Edit Online

此安全基线将 Azure 安全性基准 中的指南应用于 Azure DDoS 保护标准。 Azure 安全基准提供有关如何在 Azure
上保护云解决方案的建议。 内容由 Azure 安全基准定义的 安全控制 和适用于 DDoS 保护的相关指南进行分组。
排除了不适用于 DDoS 保护的 控件 。 若要查看 DDoS 保护如何完全映射到 Azure 安全基准,请参阅 完整的
Ddos 保护安全基线映射文件。

日志记录和监视
有关详细信息,请参阅安全控制:日志记录和监视。

2.2:配置中心安全日志管理
指南 :启用 Azure 活动日志诊断设置,并将日志发送到 Log Aalytics 工作区、Azure 事件中心或 Azure 存储帐户进
行存档。 活动日志可让你深入了解在控制平面级别对 Azure DDoS 保护计划执行的操作。 使用 Azure 活动日志
数据,可以确定任何写入操作的 "内容、人员和时间",) (在 Azure DDoS 保护实例的控制平面级别执行任何写入
操作。

如何启用 Azure 活动日志的诊断设置

Azure 安全中心 监视 :是
责 任 :客户

2.3: 为 Azure 资 源启用 审 核日志 记录


指南 :你可以选择任何可用的 DDoS 保护指标以在攻击期间使用 Azure Monitor 警报配置来向你发出警报。 当满
足条件时,指定的地址会收到警报电子邮件。

启用 Azure 活动日志诊断设置,并将日志发送到 Log Analytics 工作区、Azure 事件中心或 Azure 存储帐户以进行


存档。 活动日志可让你深入了解在 Azure Cache for Redis 实例在控制平面级别上执行的操作。 使用 Azure 活动
日志数据,可以确定任何写入操作的 "内容、人员和时间",) (在 Azure DDoS 保护实例的控制平面级别执行任何
写入操作。

查看和配置 DDoS 诊断日志记录

如何启用 Azure 活动日志的诊断设置

Azure 安全中心 监视 :是
责 任 :客户

2.5:配置安全日志存 储 保留期
指南 :在 Azure Monitor 中,根据组织的符合性规定,设置与 Azure DDoS 保护计划关联的 Log Analytics 工作区
的日志保持期。

如何设置日志保留参数

Azure 安全中心 监视 :不适用


责 任 :客户

2.6: 监视 和 查 看日志
指 导 :启用 Azure 活动日志诊断设置,并将日志发送到 Log Analytics 工作区。 在 Log Analytics 中执行查询,以搜
索术语,确定趋势,分析模式,并根据可能已为恢复服务保管库收集的活动日志数据提供许多其他见解。
有关如何访问针对 DDoS 保护标准服务的遥测、日志和攻击分析的信息

如何启用 Azure 活动日志的诊断设置

如何收集和分析 Azure Monitor 的 Log Analytics 工作区中的 Azure 活动日志

Azure 安全中心 监视 :是
责 任 :客户

2.7: 针对 异常活 动 启用警 报


指南 :配置警报和攻击分析。 Azure DDoS 防护识别并缓解 DDoS 攻击,无需任何用户干预。

将 Log Analytics 工作区载入 Azure Sentinel,因为它提供了一个安全业务流程自动响应 (之忠诚度) 解决方案。


这样便可以创建 playbook(自动化解决方案)并将其用于修正安全问题。 此外,还可以使用 Azure Monitor 在
Log Analytics 工作区中创建自定义日志警报。
如何为 DDoS 指标配置警报

如何加入 Azure Sentinel

使用 Azure Monitor 创建、查看和管理日志警报

Azure 安全中心 监视 :不适用


责 任 :客户

标识和访问控制
有关详细信息,请参阅安全控制:标识和访问控制。

3.1: 维护 管理 帐户 的清 单
指南 :若要使用 DDoS 防护计划,你的帐户必须分配到网络参与者角色或分配了相应操作的自定义角色。

此外,Azure Active Directory (AD) 具有内置角色,必须显式分配并可查询。 使用 Azure AD PowerShell 模块执行


即席查询,以发现属于管理组成员的帐户。

了解 Azure DDoS 防护中的权限

如何使用 PowerShell 获取 Azure AD 中的目录角色

如何使用 PowerShell 获取 Azure AD 中目录角色的成员

Azure 安全中心 监视 :是
责 任 :客户

3.2:在适用的情况下更改默 认 密 码
指 导 :Azure AD 没有默认密码。 其他需要密码的 Azure 资源会强制创建具有复杂性要求和最小密码长度的密
码,该长度因服务而异。 你对可能使用默认密码的第三方应用程序和市场服务负责。

Azure 安全中心 监视 :不适用


责 任 :客户

3.3:使用 专 用管理 帐户
指南 :围绕专用管理帐户的使用创建标准操作程序。 使用 Azure 安全中心标识和访问管理来监视管理帐户的数
量。

此外,为了帮助你跟踪专用管理帐户,你可以使用 Azure 安全中心或内置的 Azure 策略提供的建议,例如:

应该为你的订阅分配了多个所有者
应从订阅中删除拥有所有者权限的已弃用帐户

应从订阅中删除拥有所有者权限的外部帐户

如何使用 Azure 安全中心监视标识和访问(预览)

如何使用 Azure Policy

Azure 安全中心 监视 :是
责 任 :客户

3.4:使用 Azure Active Directory 单 一登 录 (SSO )


指南 :使用 Azure 应用注册 (服务主体) 检索可用于通过 API 调用与 DDoS 保护计划进行交互的令牌。

如何调用 Azure REST API

如何将客户端应用程序(服务主体)注册到 Azure AD

Azure DDoS 保护 API 信息


Azure 安全中心 监视 :不适用
责 任 :客户

3.5: 对 所有基于 Azure Active Directory 的 访问 使用多重身份 验证


指 导 :启用 Azure Active Directory 多重身份验证,并遵循 Azure 安全中心标识和访问管理的建议。

如何在 Azure 中启用 MFA

如何在 Azure 安全中心监视标识和访问

Azure 安全中心 监视 :是
责 任 :客户

3.6: 对 所有管理任 务 使用 专 用 计 算机(特 权访问 工作站)


指南 :在启用了 Azure AD 多重身份验证的情况下,使用安全的 Azure 托管工作站 (MFA) 登录并配置 Azure 客户
密码箱请求。

部署安全的 Azure 托管工作站

规划基于云的 Azure AD 多重身份验证部署

Azure 安全中心 监视 :不适用


责 任 :客户

3.7: 记录 来自管理 帐户 的可疑活 动 并 对 其 发 出警 报


指 导 :当环境中出现可疑或不安全的活动时,可使用 Azure Active Directory (Azure AD) Privileged Identity
Management (PIM) 生成日志和警报。
此外,还可使用 Azure AD 风险检测来查看有关风险用户行为的警报和报告。

如何部署 Privileged Identity Management

了解 Azure AD 风险检测

Azure 安全中心 监视 :是
责 任 :客户

3.8: 仅 从批准的位置管理 Azure 资 源


指南 :使用 Azure AD 命名位置,以仅允许从 IP 地址范围或国家/地区的特定逻辑分组访问 Azure 门户。

如何配置 Azure AD 命名位置

Azure 安全中心 监视 :不适用


责 任 :客户

3.9:使用 Azure Active Directory


指南 :使用 Azure Active Directory (Azure AD) 作为中心身份验证和授权系统(如果适用)。 Azure AD 通过对静态
数据和传输中数据使用强加密来保护数据。 Azure AD 还会对用户凭据进行加盐、哈希处理和安全存储操作。

如何创建和配置 Azure AD 实例

Azure 安全中心 监视 :不适用


责 任 :客户

3.10:定期 审查 和 协调 用 户访问
指 导 :Azure Active Directory (Azure AD) 提供了日志来帮助你发现过时的帐户。 此外,还可以使用 Azure AD 访
问评审来有效地管理组成员身份、访问企业应用程序和角色分配。 应定期查看用户访问权限,以确保只有正确的
用户才能继续访问。

了解 Azure AD 报告

如何使用 Azure AD 访问评审

Azure 安全中心 监视 :是
责 任 :客户

3.11: 监视尝试访问 已停用凭据的行 为


指南 :使用 Azure Active Directory (Azure AD) 作为中心身份验证和授权系统(如果适用)。 Azure AD 通过对静态
数据和传输中数据使用强加密来保护数据。 Azure AD 还会对用户凭据进行加盐、哈希处理和安全存储操作。

你可以访问 Azure AD 登录活动、审核和风险事件日志源,以便与 Azure Sentinel 或第三方 SIEM 集成。

可以通过为 Azure AD 用户帐户创建诊断设置,并将审核日志和登录日志发送到 Log Analytics 工作区,来简化此


过程。 可以在 Log Analytics 中配置所需的日志警报。

如何将 Azure 活动日志集成到 Azure Monitor

如何加入 Azure Sentinel

Azure 安全中心 监视 :不适用


责 任 :客户

3.12: 针对帐户 登 录 行 为 偏差 发 出警 报
指南 :对于控件平面上的帐户登录行为偏差 (例如 Azure 门户) ,请使用 Azure AD Identity Protection 和风险检测
功能来配置对检测到的与用户标识相关的可疑操作的自动响应。 还可将数据引入 Azure Sentinel 以做进一步调
查。

如何查看 Azure AD 风险登录

如何配置和启用标识保护风险策略

如何加入 Azure Sentinel

Azure 安全中心 监视 :目前不可用


责 任 :客户
数据保护
有关详细信息,请参阅安全控制:数据保护。

4.1: 维护 敏感信息的清 单
指 导 :使用标记可以帮助跟踪存储或处理敏感信息的 Azure 资源。

如何创建和使用标记

Azure 安全中心 监视 :不适用


责 任 :客户

4.6:使用 Azure RBAC 控制 对资 源的 访问


指南 :若要使用 Azure DDoS 保护计划,你的帐户必须分配到网络参与者角色或分配有特定操作的自定义角色。

在 azure DDoS 保护中管理 azure RBAC) 的 Azure 基于角色的访问控制 (

Azure 安全中心 监视 :不适用


责 任 :客户

4.9: 记录对 关 键 Azure 资 源的更改并 对 此 类 更改 发 出警 报


指南 :将 Azure Monitor 与 Azure 活动日志结合使用,以创建有关 Azure DDoS 保护计划以及其他关键或相关资
源发生更改的警报。

如何针对 Azure 活动日志事件创建警报

Azure 安全中心 监视 :是
责 任 :客户

库存和资产管理
有关详细信息,请参阅安全控制:清单和资产管理。

6.1:使用自 动 化 资产发现 解决方案


指南 :使用 Azure 资源关系图查询/发现订阅中的所有资源 (如计算、存储、网络、端口和协议等 ) 。 确保租户中具
有适当的(读取)权限,并枚举所有 Azure 订阅以及订阅中的资源。

尽管可以通过 Resource Graph 发现经典 Azure 资源,但我们强烈建议你今后还是创建并使用 Azure 资源管理器


资源。

如何使用 Azure Resource Graph 创建查询

如何查看 Azure 订阅

Azure 安全中心 监视 :不适用


责 任 :客户

6.2: 维护资产 元数据


指 导 :将标记应用到 Azure资源,以便有条理地根据分类组织元数据。

如何创建和使用标记

Azure 安全中心 监视 :不适用


责 任 :客户

6.3: 删 除未 经 授 权 的 Azure 资 源
指南 :在适用的情况下,请使用标记、管理组和单独的订阅来组织和跟踪 Azure 资产。 定期核对清单,确保及时
地从订阅中删除未经授权的资源。

此外,使用 Azure Policy 对可使用以下内置策略定义在客户订阅中创建的资源类型施加限制:

不允许的资源类型

允许的资源类型

如何创建其他 Azure 订阅

如何创建管理组

如何创建和使用标记

Azure 安全中心 监视 :不适用


责 任 :客户

6.4:定 义 并 维护 已批准的 Azure 资 源的清 单


指 导 :根据组织需求,创建已获批 Azure 资源以及已获批用于计算资源的软件的清单。

Azure 安全中心 监视 :不适用


责 任 :客户

6.5: 监视 未批准的 Azure 资 源


指 导 :使用 Azure Policy 对可以在订阅中创建的资源类型施加限制。

使用 Azure Resource Graph 查询和发现订阅中的资源。 确保环境中的所有 Azure 资源均已获得批准。

如何配置和管理 Azure Policy

如何使用 Azure Resource Graph 创建查询

Azure 安全中心 监视 :不适用


责 任 :客户

6.9: 仅 使用已批准的 Azure 服 务


指 导 :在 Azure Policy 中使用以下内置策略定义,对可以在客户订阅中创建的资源类型施加限制:

不允许的资源类型

允许的资源类型

如何配置和管理 Azure Policy

如何使用 Azure Policy 拒绝特定的资源类型

Azure 安全中心 监视 :不适用


责 任 :客户

6.11:限制用 户 与 Azure 资 源管理器 进 行交互的能力


指南 :配置 Azure 条件访问,使其通过为“Microsoft Azure 管理”应用配置“阻止访问”,来限制用户与 Azure 资源
管理器进行交互的能力。

如何配置条件访问以阻止访问 Azure 资源管理器

Azure 安全中心 监视 :不适用


责 任 :客户
安全配置
有关详细信息,请参阅安全控制:安全配置。

7.1: 为 所有 Azure 资 源建立安全配置


指南 :定义和实现 Azure DDoS 保护与 azure 策略的标准安全配置。 在“Microsoft.Network”命名空间中使用
Azure Policy 别名创建自定义策略,以审核或强制实施恢复服务保管库的配置。
如何查看可用的 Azure Policy 别名

如何配置和管理 Azure Policy

Azure 安全中心 监视 :不适用


责 任 :客户

7.3: 维护 安全的 Azure 资 源配置


指南 :使用 Azure Policy“[拒绝]”和“[不存在则部署]”对不同的 Azure 资源强制实施安全设置。

如何配置和管理 Azure Policy

了解 Azure Policy 效果

Azure 安全中心 监视 :不适用


责 任 :客户

7.5:安全存 储 Azure 资 源的配置


指 导 :如果使用自定义的 Azure Policy 定义,请使用 Azure DevOps 或 Azure Repos 安全地存储和管理代码。

如何在 Azure DevOps 中存储代码

Azure Repos 文档
Azure 安全中心 监视 :不适用
责 任 :客户

7.7:部署 Azure 资 源的配置管理工具


指 导 :在“Microsoft.Network”命名空间中使用内置的 Azure Policy 定义和 Azure Policy 别名创建自定义策略,以
审核、强制实施系统配置并为其发出警报。 另外,开发一个用于管理策略例外的流程和管道。

如何配置和管理 Azure Policy

Azure 安全中心 监视 :不适用


责 任 :客户

7.9: 为 Azure 资 源 实 施自 动 配置 监视
指 导 :在“Microsoft.Network”命名空间中使用内置的 Azure Policy 定义和 Azure Policy 别名创建自定义策略,以
审核、强制实施系统配置并为其发出警报。 使用 Azure Policy“[审核]”、“[拒绝]”和“[不存在则部署]”自动强制实施
Azure 资源的配置。
如何配置和管理 Azure Policy

Azure 安全中心 监视 :不适用


责 任 :客户

7.13:消除意外的凭据透露
指南 :实施凭据扫描程序来识别代码中的凭据。 凭据扫描程序还会建议将发现的凭据转移到更安全的位置,例如
Azure Key Vault。
如何设置凭据扫描程序

Azure 安全中心 监视 :不适用


责 任 :客户

恶意软件防护
有关详细信息,请参阅安全控制:恶意软件防护。

8.2: 预 先 扫 描要上 传 到非 计 算 Azure 资 源的文件


指南 :在支持 azure 服务的基础主机上启用了 Microsoft 反恶意软件 (例如,Azure DDoS 保护) ,但它不会在客户
内容上运行。

你需要负责预先扫描要上传到非计算 Azure 资源的任何内容。 Microsoft 无法访问客户数据,因此无法代表你对


客户内容执行反恶意软件扫描。

Azure 安全中心 监视 :不适用


责 任 :客户

事件响应
有关详细信息,请参阅安全控制:事件响应。

10.1: 创 建事件响 应 指 导
指南 :为组织制定事件响应指南。 确保在书面的事件响应计划中定义人员职责,以及事件处理/管理从检测到事
件后审查的各个阶段。

关于建立自己的安全事件响应流程的指南

Microsoft 安全响应中心分析 SSIRP 事件


利用 NIST 的“计算机安全事件处理指南”,帮助制定自己的事件响应计划

Azure 安全中心 监视 :不适用


责 任 :客户

10.2: 创 建事件 评 分和 优 先 级设 定 过 程
指 导 :安全中心为每条警报分配严重性,以帮助你优先处理应该最先调查的警报。 严重性取决于安全中心在发出
警报时所依据的检测结果和分析结果的置信度,以及导致发出警报的活动的恶意企图的置信度。

此外,请明确标记订阅(例如 生产、非生产)并创建命名系统来对 Azure 资源进行明确标识和分类,特别是处理敏


感数据的资源。 你的责任是根据发生事件的 Azure 资源和环境的关键性确定修正警报的优先级。

Azure 安全中心中的安全警报
使用标记整理 Azure 资源

Azure 安全中心 监视 :是
责 任 :客户

10.3: 测试 安全响 应过 程
指 导 :定期执行演练来测试系统的事件响应功能,以帮助保护 Azure 资源。 识别弱点和差距,并根据需要修改计
划。

通过为应用程序生成流量来模拟 DDoS 攻击,来测试你的服务将如何响应攻击。 不要等待实际攻击发生。


Microsoft 与 Ixia (一家 Keysight 公司)合作,提供 (BreakingPoint Cloud) 的自助服务流量生成器,使 Azure DDoS
保护客户能够针对其 Azure 公共终结点模拟 DDoS 测试流量。

Microsoft Azure DDoS 保护验证


NIST 发布 - IT 计划和功能的测试、训练和演练计划指南
Azure 安全中心 监视 :不适用
责 任 :客户

10.4:提供安全事件 联 系人 详细 信息,并 针对 安全事件配置警 报 通知


指 导 :如果 Microsoft 安全响应中心 (MSRC) 发现数据被某方非法访问或未经授权访问,Microsoft 会使用安全事
件联系信息联系用户。 事后审查事件,确保问题得到解决。

如何设置 Azure 安全中心安全联系人

Azure 安全中心 监视 :是
责 任 :客户

10.5:将安全警 报 整合到事件响 应 系 统 中
指南 :使用连续导出功能导出 Azure 安全中心警报和建议,以帮助确定 Azure 资源的风险。 使用连续导出可以手
动导出或者持续导出警报和建议。 可以使用 Azure 安全中心数据连接器将警报流式传输到 Azure Sentinel。

选择任何可用的 DDoS 保护指标以在攻击期间使用 Azure Monitor 警报配置来向你发出警报。 满足条件时,指定


的地址会收到警报电子邮件

配置针对 DDoS 防护指标的警报

如何配置连续导出

如何将警报流式传输到 Azure Sentinel

Azure 安全中心 监视 :不适用


责 任 :客户

10.6:自 动 响 应 安全警 报
指 导 :使用 Azure 安全中心内的工作流自动化功能,通过“逻辑应用”针对安全警报和建议自动触发响应,以保护
Azure 资源。
如何配置工作流自动化和逻辑应用

Azure 安全中心 监视 :不适用


责 任 :客户

渗透测试和红队练习
有关详细信息,请参阅安全控制:渗透测试和红队演练。

11.1:定期 对 Azure 资 源 执 行渗透 测试 ,确保修正所有 发现 的关 键 安全 问题


指南 :按照 Microsoft 渗透测试规则参与,确保你的渗透测试不违反 Microsoft 政策。 使用 Microsoft 红队演练策
略和执行,以及针对 Microsoft 托管云基础结构、服务和应用程序执行的现场渗透测试。

参与的渗透测试规则

Microsoft 云红色组合
Azure 安全中心 监视 :不适用
责 任 :共享

后续步骤
请参阅 Azure 安全基准
详细了解 Azure 安全基线
阻⽌⽆关联的 DNS 项并避免⼦域接管
2021/2/9 • • Edit Online

本文介绍了子域接管造成的常见安全威胁,以及可采取的缓解措施。

什么是子域接管?
子域接管是定期创建和删除大量资源的组织会遇到的一种常见严重威胁。 当你有 DNS 记录指向已取消预配的
Azure 资源时,可能会发生子域接管。 这类 DNS 记录也称为“无关联的 DNS”项。 CNAME 记录特别容易受到此威
胁的攻击。 子域接管使恶意操作者能够将专用于某组织的域的流量重定向到一个执行恶意活动的站点。

出现子域接管的常见情况:

1. 创 建:

a. 你使用完全限定的域名 (FQDN) app-contogreat-dev-001.azurewebsites.net 预配 Azure 资源。

b. 你使用将流量路由到你的 Azure 资源的子域 greatapp.contoso.com 在 DNS 区域中分配 CNAME 记


录。

2. 取消 预 配:

a. 不再需要 Azure 资源时将其取消预配或删除。

此时,应从 DNS 区域删除 CNAME 记录 greatapp.contoso.com 。 如果未删除 CNAME 记录,则该记


录将播发为活动域,但不会将流量路由到活动的 Azure 资源。 这就是“无关联的”DNS 记录的定义。

b. 无关联的子域 greatapp.contoso.com 目前易受攻击,可通过将其分配到其他 Azure 订阅的资源来


接管它。

3. 接管:

a. 威胁操纵者使用常用方法和工具来发现无关联的子域。

b. 威胁操纵者使用之前由你控制的资源的 FQDN 来预配 Azure 资源。 在本示例中为


app-contogreat-dev-001.azurewebsites.net 。

c. 发送到子域 greatapp.contoso.com 的流量现在路由到由恶意操作者控制其中内容的资源。


子域接管造成的风险
当 DNS 记录指向不可用的资源时,记录本身应已从 DNS 区域中删除。 如果尚未删除,它会成为“无关联的
DNS”记录,并且有可能发生子域接管。
无关联的 DNS 项使威胁操纵者能够控制关联的 DNS 名称,进而托管恶意网站或服务。 组织子域中的恶意页面
和服务可能导致以下结果:

失去 对 子域内容的控制 - 造成负面影响,显示出你的组织没法保护自身的内容,还会造成品牌受损和信
任丧失。

从无防 备 的 访 客那里 获 取 Cookie - Web 应用通常会将会话 Cookie 公开到子域 (*.contoso.com),这导


致任何子域均可对其进行访问。 威胁操纵者可能会使用子域接管来生成看似可信的页面,诱使毫无戒心
的用户访问该页面,然后获取用户的 Cookie(甚至是安全 Cookie)。 常见的误解是,使用 SSL 证书可保护
网站和用户的 Cookie 免遭接管。 然后,威胁操纵者可能会使用劫持的子域来申请和接收有效的 SSL 证
书。 有效的 SSL 证书使他们能够访问安全 Cookie,而且可进一步使恶意网站看起来更合法。

网 络钓鱼 活 动 - 看似可信的子域可能会被用于网络钓鱼活动。 对于恶意网站和 MX 记录来说确实如此,


威胁操纵者会利用这些内容来接收发往已知安全品牌的合法子域的电子邮件。

其他 风险 - 恶意网站可能会被用于升级为其他经典攻击,例如 XSS 、CSRF 和 CORS 绕过等。

标识无关联的 DNS 项
若要标识组织内部可能无关联的 DNS 项,请使用 Microsoft 的 GitHub 托管的 PowerShell 工具“Get-
DanglingDnsRecords”。
此工具可帮助 Azure 客户列出 CNAME 与客户订阅或租户上创建的现有 Azure 资源相关联的所有域。

如果 CNAME 属于其他 DNS 服务并指向 Azure 资源,请在该工具的输入文件中提供 CNAME。

该工具支持下表中列出的 Azure 资源。 该工具会提取所有租户的 CNAME 或将其作为输入。


F Q DN P RO P ERT Y

Azure Front Door microsoft.network/frontdoo properties.cName abc.azurefd.net


rs

Azure Blob 存储 microsoft.storage/storageac properties.primaryEndpoint abc.


counts s.blob blob.core.windows.net

Azure CDN microsoft.cdn/profiles/endp properties.hostName abc.azureedge.net


oints

公共 IP 地址 microsoft.network/publicipa properties.dnsSettings.fqdn abc.EastUs.cloudapp.azure.com


ddresses

Azure 流量管理器 microsoft.network/trafficma properties.dnsConfig.fqdn abc.trafficmanager.net


nagerprofiles

Azure 容器实例 microsoft.containerinstance/ properties.ipAddress.fqdn abc.EastUs.azurecontainer.io


containergroups

Azure API 管理 microsoft.apimanagement/s properties.hostnameConfig abc.azure-api.net


ervice urations.hostName

Azure 应用服务 microsoft.web/sites properties.defaultHostName abc.azurewebsites.net

Azure 应用服务 - 槽 microsoft.web/sites/slots properties.defaultHostName abc-


def.azurewebsites.net

先决条件
以具有下列权限的用户身份运行查询:

至少可对 Azure 订阅进行读取者级别访问


可对 Azure Resource Graph 进行读取访问

如果你是贵组织租户的全局管理员,请按照提升访问权限以管理所有 Azure 订阅和管理组中的指导,将帐户提升


为可访问贵组织的所有订阅。

TIP
如果使用大型 Azure 环境,应考虑 Azure Resource Graph 的带宽限制和分页限制。

详细了解如何使用大型 Azure 资源数据集。

该工具使用订阅批处理来避免这些限制。

运行脚本
详细了解 PowerShell 脚本 Get-DanglingDnsRecords.ps1 ,然后从 GitHub 下载:
https://aka.ms/DanglingDNSDomains。

修正无关联的 DNS 项
查看 DNS 区域,并标识无关联的或已遭接管的 CNAME 记录。 如果发现子域无关联或已遭接管,请删除易受攻
击的子域,并按以下步骤操作来缓解风险:

1. 在 DNS 区域中,删除所有指向不再预配的资源的 FQDN 的 CNAME 记录。


2. 为确保流量路由到你控制的资源,请使用无关联子域的 CNAME 记录中指定的 FQDN 来预配其他资源。

3. 查看应用程序代码中对特定子域的引用,并更新所有错误或过期的子域引用。

4. 调查是否发生了任何泄露,并按照组织的事件响应程序采取措施。 以下是调查此问题的提示和最佳做法。

如果应用程序逻辑是将 OAuth 凭据等机密发送到无关联的子域,或将隐私敏感信息发送到无关联的子


域,则该数据可能已公开到第三方。

5. 了解取消预配资源时未从 DNS 区域中删除 CNAME 记录的原因,并采取措施以确保后续取消预配 Azure


资源时正确更新 DNS 记录。

防止无关联的 DNS 项
确保贵组织已落实过程来防止出现无关联的 DNS 项,安全计划的关键部分是防止由这些项产生的子域接管。

一些 Azure 服务提供了相关功能来帮助创建预防措施,下面是详细介绍。 必须根据贵组织的最佳做法或标准操


作程序来建立防止此问题的其他方法。

为应 用服 务 启用 Azure Defender
Azure 安全中心的集成云工作负荷保护平台 (CWPP) ,Azure Defender 提供一系列计划来保护 Azure、混合和多
云资源和工作负荷。

适用于 应 用服 务计 划的 Azure Defender 包含无关联的 DNS 检测。 启用此计划后,如果你解除应用服务网站


的授权,但不从 DNS 注册机构删除其自定义域,你会收到安全警报。

无论你的域是使用 Azure DNS 还是外部域注册机构来管理,并且适用于 Windows 和 Linux 上的应用服


务,Azure Defender 的无关联 DNS 保护功能可用。

若要深入了解 azure defender 计划,请参阅 Azure Defender 应用服务简介。

使用 Azure DNS 别 名 记录
Azure DNS 的别名记录通过将 DNS 记录的生命周期与 Azure 资源相结合来防止出现无关联引用。 例如,假设某
个 DNS 记录限定为别名记录,以指向公共 IP 地址或流量管理器配置文件。 如果删除这些基础资源,DNS 别名记
录会变成空的记录集。 它不再引用已删除的资源。 务必注意,别名记录可保护的内容有限。 目前,列表限制如
下:

Azure Front Door


流量管理器配置文件
Azure 内容分发网络 (CDN) 终结点
公共 IP

尽管目前服务产品有限,但建议尽可能使用别名记录来防止子域接管。

详细了解 Azure DNS 别名记录的功能。

使用 Azure 应 用服 务 的自定 义 域 验证
为 Azure 应用服务创建 DNS 项时,请使用域验证 ID 创建 asuid.{subdomain} TXT 记录。 存在此类 TXT 记录时,
其他 Azure 订阅均无法验证自定义域,即无法接管自定义域。

这些记录不会阻止使用 CNAME 项中的名称创建 Azure 应用服务。 如果无法证明域名的所有权,则威胁操纵者


无法接收流量或控制内容。

详细了解如何将现有的自定义 DNS 名称映射到 Azure 应用服务。

建立并自 动执 行 缓 解威 胁 的流程
通常是由开发人员和操作团队来运行清理进程,以避免无关联的 DNS 威胁。 以下做法有助于确保贵组织免遭这
种威胁。
创 建 预 防 过 程:

训练应用程序开发人员在每次删除资源时都重新路由地址。

将“删除 DNS 项”放入停用服务时需进行的检查的列表中。

在具有自定义 DNS 项的所有资源中放入删除锁定。 删除锁定可指示取消预配资源前必须删除映


射。 只有在与内部训练计划结合时,此类措施才能发挥作用。

创 建 发现过 程:

定期查看 DNS 记录,确保所有子域都映射到以下 Azure 资源:

存在-在 DNS 区域中查询指向 Azure 子域的资源,例如 *. azurewebsites.net 或 *.


cloudapp.azure.com (参阅 azure 域) 的参考列表 。
You own - 确认拥有 DNS 子域面向的所有资源。
维护包含 Azure 完全限定的域名 (FQDN) 终结点和应用程序所有者的服务目录。 若要生成服务目
录,请运行以下 Azure Resource Graph 查询脚本。 此脚本阐述你有权访问的资源的 FQDN 终结点
信息,并将其以 CSV 文件形式输出。 如果你可访问租户的所有订阅,则脚本将考虑所有这些订阅,
如以下示例脚本所示。 若要将结果限制为一组特定的订阅,请如下所示编辑脚本。

创 建修正 过 程:

找到无关联的 DNS 项后,团队需要调查是否发生了任何泄露。


调查停用资源时未重新路由地址的原因。
如果不再使用 DNS 记录,请将其删除,或将其指向贵组织所拥有的正确 Azure 资源 (FQDN)。

后续步骤
若要详细了解可用于防止子域接管的相关服务和 Azure 功能,请参阅以下页面。

启用用于应用服务的 Azure Defender -在检测到无关联 DNS 条目时接收警报

防止与 Azure DNS 无关联的 DNS 记录

在 Azure 应用服务中添加自定义域时使用域验证 ID

快速入门:使用 Azure PowerShell 运行首个 Resource Graph 查询


适⽤于 Azure 云服务和虚拟机的 Microsoft 反恶意
软件
2021/2/9 • • Edit Online

适用于 Azure 的 Microsoft 反恶意软件是一种免费实时保护,可帮助识别并删除病毒、间谍软件和其他恶意软


件。 当已知恶意软件或不需要的软件试图在 Azure 系统上安装自己或运行时,该服务会生成警报。

该解决方案是在 Microsoft Security Essentials [MSE]、Microsoft Forefront Endpoint Protection、Microsoft


System Center Endpoint Protection、Microsoft Intune 和 Microsoft Defender 使用的同一个反恶意软件平台的基
础上构建的。 适用于 Azure 的 Microsoft 反恶意软件是一个针对应用程序和租户环境所提供的单一代理解决方
案,可在在后台运行而无需人工干预。 可以根据应用程序工作负荷的需求,选择默认的基本安全性或高级的自定
义配置(包括反恶意软件监视)来部署保护。

为应用程序部署并启用适用于 Azure 的 Microsoft 反恶意软件后,便可以使用以下几项核心功能:

实时 保 护 - 监视云服务和虚拟机上的活动,以检测和阻止恶意软件的执行。
计 划的 扫 描 - 定期扫描以检测恶意软件(包括主动运行的程序)。
恶 意 软 件消除 - 自动针对检测到的恶意软件采取措施,例如删除或隔离恶意文件以及清除恶意注册表项。
签 名更新 - 自动安装最新的保护签名(病毒定义)以确保按预定的频率保持最新保护状态。
反 恶 意 软 件引擎更新 - 自动更新 Microsoft 反恶意软件引擎。
反 恶 意 软 件平台更新 – 自动更新 Microsoft 反恶意软件平台。
主 动 保 护 - 将检测到的威胁和可疑资源的遥测元数据报告给 Microsoft Azure,以确保针对不断演变的威胁局
势做出快速响应,并通过 Microsoft Active Protection System (MAPS) 启用实时同步签名传递。
示例 报 告 - 将示例提供并报告给 Microsoftt 反恶意软件服务,以帮助改善服务并实现故障排除。
排除 项 - 允许应用程序和服务管理员配置文件、进程和驱动器的排除项。
恶 意 软 件事件收集 -在操作系统事件日志中记录反恶意软件服务的运行状况、可疑活动及采取的补救措施,
并将这些数据收集到客户的 Azure 存储帐户。

NOTE
此外可以使用 Azure 安全中心部署 Microsoft 反恶意软件。 有关详细信息,请参阅在 Azure 安全中心中安装 Endpoint
Protection。

体系结构
适用于 Azure 的 Microsoft 反恶意软件包含 Microsoft 反恶意软件客户端和服务、反恶意软件经典部署模型、反
恶意软件 PowerShell cmdlet 和 Azure 诊断扩展。 Windows Server 2008 R2 、Windows Server 2012 和
Windows Server 2012 R2 操作系统系列支持 Microsoft 反恶意软件。 Windows Server 2008 操作系统不支持此
解决方案,Linux 中也不支持此解决方案。

默认情况下,Microsoft 反恶意软件客户端和服务以禁用状态安装在云服务平台中所有受支持的 Azure 来宾操作


系统系列上。 默认情况下,Microsoft 反恶意软件客户端和服务未安装在虚拟机平台中,而是通过 Azure 门户和
Visual Studio 虚拟机配置中的“安全扩展”作为一个可选功能来提供。
在 Windows 上使用 Azure 应用服务时,托管 Web 应用的基础服务在 Web 应用上启用了 Microsoft
Antimalware。 它用于保护 Azure 应用服务基础结构,不会对客户内容运行。
NOTE
Microsoft Defender 是 Windows Server 2016 中启用的内置反恶意软件。 一些 Windows Server 2016 SKU 上也默认启用了
Microsoft Defender 界面,请参阅此处了解详细信息。 Azure VM 反恶意软件扩展仍可添加到带 Microsoft Defender 的
Windows Server 2016 Azure VM,但在此情况下,该扩展会应用 Microsoft Defender 要使用的任何可选配置策略,而且不会
部署任何其他反恶意软件服务。 可在此处阅读有关此更新的详细信息。

Microsoft 反 恶 意 软 件工作流
Azure 服务管理员可以使用以下选项,针对虚拟机和云服务通过默认或自定义配置来启用 Azure 的反恶意软件:
虚拟机 – 在Azure 门户中的“安全 扩 展 ”下
虚拟机 – 在服务器资源管理器中使用 Visual Studio 虚拟机配置
虚拟机和云服务 – 使用反恶意软件经典部署模型
虚拟机和云服务 – 使用反恶意软件 PowerShell cmdlet

Azure 门户或 PowerShell cmdlet 将反恶意软件扩展包文件推送到 Azure 系统中的预定固定位置。 Azure 来宾代


理(或结构代理)启动反恶意软件扩展,并将提供的反恶意软件配置设置应用为输入。 此步骤以默认或自定义配
置设置来启用反恶意软件服务。 若未提供任何自定义配置,则以默认配置设置来启用反恶意软件服务。 有关详
细信息,请参阅适用于 Azure 的 Microsoft Antimalware - 代码示例中的“反恶意软件配置”部分。

运行后,Microsoft 反恶意软件客户端将从 Internet 下载最新的保护引擎和签名定义,并将其加载到 Azure 系统


上。 Microsoft 反恶意软件服务会将服务相关的事件写入“Microsoft 反恶意软件”事件源下的系统 OS 事件日志
中。 事件包括反恶意软件客户端运行状况、保护和补救状态、新的和旧的配置设置、引擎更新和签名定义及其他
信息。

可以为云服务或虚拟机启用反恶意软件监视,以便将生成的反恶意软件事件日志事件写入 Azure 存储帐户。 反


恶意软件服务使用 Azure 诊断扩展将 Azure 系统中的反恶意软件事件收集到客户 Azure 存储帐户中的表内。

本文档的“反恶意软件部署方案”部分介绍了上述方案支持的部署工作流,包括配置步骤和选项。
NOTE
不过,可以使用 Powershell/API 和 Azure 资源管理器模板来部署带有 Microsoft 反恶意软件扩展的虚拟机扩展集。 若要在已
运行的虚拟机上安装扩展,可以使用示例 python 脚本 vmssextn.py。 此脚本获取扩展集的现有扩展配置,并向 VM 扩展集
的现有扩展列表中添加扩展。

默 认 和自定 义 的反 恶 意 软 件配置
如果未提供自定义配置设置,会应用默认的配置设置以启用适用于 Azure 云服务或虚拟机的反恶意软件。 默认
配置设置已预先经过优化,可在 Azure 环境中运行。 或者,可以根据 Azure 应用程序或服务部署的需要自定义这
些默认配置设置,并将其应用到其他部署方案。

下表汇总了反恶意软件服务可用的配置设置。 标有“默认”的列下面标记了默认配置设置。
反恶意软件部署方案
本部分介绍启用和配置反恶意软件的方案,包括监视 Azure 云服务和虚拟机。

虚 拟 机 - 启用和配置反 恶 意 软 件
使用 Azure 门户创 建 VM 时进 行部署
若要在预配虚拟机时使用 Azure 门户启用和配置 Azure 虚拟机的 Microsoft 反恶意软件,请执行以下步骤:

1. 通过 https://portal.azure.com 登录到 Azure 门户。


2. 若要创建新的虚拟机,请导航到“虚拟机”,选择“添加”,然后选择“Windows Server”。
3. 选择要使用的 Windows Server 版本。
4. 选择“创建”。 创建虚拟机

5. 提供“名称”、“用户名”和“密码”,然后创建新资源组或选择现有的资源组。
6. 选择“确定”。
7. 选择 VM 大小。
8. 在下一部分,根据需要做出相应的选择,然后选择“扩展”部分。
9. 选择“添加扩展”
10. 在“新建资源”下,选择“Microsoft 反恶意软件”。
11. 选择“创建”
12. 在“安装扩展”部分,可以配置文件、位置和进程排除项,及其他扫描选项。 选择“确定”。
13. 选择“确定”。
14. 返回“设置”部分,选择“确定”。
15. 在“创建”屏幕中选择“确定”。

请参阅此 Azure 资源管理器模板 ,部署适用于 Windows 的反恶意软件 VM 扩展。

使用 Visual Studio 虚 拟 机配置 进 行部署


若要使用 Visual Studio 启用和配置 Microsoft 反恶意软件服务,请执行以下操作:

1. 在 Visual Studio 中连接到 Microsoft Azure。

2. 在“服务器资源管理器”的“虚拟机”节点中选择自己的虚拟机。
3. 右键单击“配置”查看虚拟机配置页

4. 从“已安装的扩展”下的下拉列表中选择“Microsoft 反恶意软件”扩展,并单击“添加”以使用默认反恶意软件
配置进行配置。

5. 若要自定义默认反恶意软件配置,请在“已安装的扩展”列表中选择(突出显示)“反恶意软件”扩展,并单
击“配置”。

6. 将“公共配置”文本框中的默认反恶意软件配置替换为受支持的 JSON 格式的自定义配置,然后单击“确


定”。

7. 单击“更新”按钮,将配置更新推送到虚拟机。

NOTE
反恶意软件的 Visual Studio 虚拟机配置仅支持 JSON 格式配置。 适用于 Azure 的 Microsoft Antimalware - 代码示例中包含
了反恶意软件 JSON 配置设置模板,其中显示了支持的反恶意软件配置设置。

使用 PowerShell cmdlet 进 行部署


Azure 应用程序或服务可以使用 PowerShell cmdlet 来启用和配置适用于 Azure 虚拟机的 Microsoft 反恶意软
件。

若要使用反恶意软件 PowerShell cmdlet 来启用和配置 Microsoft 反恶意软件,请执行以下操作:


1. 设置 PowerShell 环境 - 请参考 https://github.com/Azure/azure-powershell 处的文档
2. 使用 Set-AzureVMMicrosoftAntimalwareExtension cmdlet 来启用和配置适用于虚拟机的 Microsoft
Antimalware。

NOTE
反恶意软件的 Azure 虚拟机配置仅支持 JSON 格式配置。 适用于 Azure 的 Microsoft Antimalware - 代码示例中包含了反恶
意软件 JSON 配置设置模板,其中显示了支持的反恶意软件配置设置。

使用 PowerShell cmdlet 来启用和配置反 恶 意 软 件


Azure 应用程序或服务可以使用 PowerShell cmdlet 来启用和配置适用于 Azure 云服务的 Microsoft 反恶意软
件。 请注意,Microsoft 反恶意软件以禁用状态安装在云服务平台中,需要 Azure 应用程序执行某个操作来启用
它。

若要使用 PowerShell cmdlet 来启用和配置 Microsoft 反恶意软件,请执行以下操作:

1. 设置 PowerShell 环境 - 请参考 https://github.com/Azure/azure-powershell 处的文档


2. 使用 Set-AzureServiceExtension cmdlet 来启用和配置适用于云服务的 Microsoft Antimalware。

适用于 Azure 的 Microsoft Antimalware - 代码示例中包含了反恶意软件 XML 配置设置模板,其中显示了支持的


反恶意软件配置设置。

云服 务 和虚 拟 机 - 使用
PowerShell cmdlet 进 行配置
Azure 应用程序或服务可以使用 PowerShell cmdlet 来检索适用于云服务和虚拟机的 Microsoft 反恶意软件配
置。

若要使用 PowerShell cmdlet 来检索 Microsoft 反恶意软件配置,请执行以下操作:

1. 设置 PowerShell 环境 - 请参考 https://github.com/Azure/azure-powershell 处的文档


2. 对 于虚 拟 机 :使用 Get-AzureVMMicrosoftAntimalwareExtension cmdlet 来获取反恶意软件配置。
3. 对 于云服 务 :使用 Get-AzureServiceExtension cmdlet 来获取反恶意软件配置。

使用 PowerShell cmdlet 删 除 Microsoft 反 恶 意 软 件配置


Azure 应用程序或服务可从相关的 Azure 反恶意软件以及与云服务或虚拟机关联的诊断服务扩展中,删除反恶意
软件配置和任何关联的反恶意软件监视。

若要使用 PowerShell cmdlet 删除 Microsoft 反恶意软件,请执行以下操作:

1. 设置 PowerShell 环境 - 请参考 https://github.com/Azure/azure-powershell 处的文档


2. 对 于虚 拟 机 :使用 Remove-AzureVMMicrosoftAntimalwareExtension cmdlet。
3. 对 于云服 务 : 使用 Remove-AzureServiceExtension cmdlet。

若要使用 Azure 预览门户来 启用 适用于虚拟机的反恶意软件事件收集,请执行以下操作:

1. 在“虚拟机”边栏选项卡中单击“监视”透镜的任何部位
2. 在“度量值”边栏选项卡中单击“诊断”命令
3. 为“状 态 ”选择“打开”,并选中 Windows 事件系统日志的对应选项
4. . 可以取消选中列表中的所有其他选项,或者根据应用程序服务的需要将它们保持启用状态。
5. 将在 Azure 存储帐户中捕获“错误”、“警告”、“信息”等反恶意软件事件类别。
反恶意软件事件将从 Windows 事件系统日志收集到 Azure 存储帐户中。 可以通过选择相应的存储帐户,为虚拟
机配置存储帐户以收集反恶意软件事件。
使用PowerShell cmdlet 为 Azure 资 源管理器 VM 启用和配置反 恶 意 软 件
可以使用 PowerShell cmdlet 为 Azure 资源管理器 VM 启用和配置 Microsoft Antimalware。

若要使用反恶意软件 PowerShell cmdlet 来启用和配置 Microsoft 反恶意软件,请执行以下操作:

1. 使用 GitHub 上的此文档设置 PowerShell 环境。


2. 使用 Set-AzureRmVMExtension cmdlet 为 VM 启用和配置 Microsoft Antimalware。

可以使用以下代码示例:

在 ARM VM 上部署 Microsoft Antimalware


将 Microsoft Antimalware 添加到 Azure Service Fabric 群集

后续步骤
请参阅代码示例,以便为 Azure 资源管理器 (ARM) 虚拟机启用和配置 Microsoft Antimalware。
为 Azure 资源管理器 Vm 启⽤和配置 Microsoft 反
恶意软件
2021/2/9 • • Edit Online

可以为 Azure 资源管理器 Vm 启用和配置 Microsoft 反恶意软件。 本文提供使用 PowerShell cmdlet 的代码示
例。

在 Azure 上部署 Microsoft 反恶意软件资源管理器 Vm

NOTE
在执行此代码示例之前,必须取消注释变量并提供相应的值。
# Script to add Microsoft Antimalware extension to Azure Resource Manager VMs
# Specify your subscription ID
$subscriptionId= " SUBSCRIPTION ID HERE "
# specify location, resource group, and VM for the extension
$location = " LOCATION HERE " # eg., “Southeast Asia” or “Central US”
$resourceGroupName = " RESOURCE GROUP NAME HERE "
$vmName = " VM NAME HERE "

# Enable Antimalware with default policies


$settingString = ‘{"AntimalwareEnabled": true}’;
# Enable Antimalware with custom policies
# $settingString = ‘{
# "AntimalwareEnabled": true,
# "RealtimeProtectionEnabled": true,
# "ScheduledScanSettings": {
# "isEnabled": true,
# "day": 0,
# "time": 120,
# "scanType": "Quick"
# },
# "Exclusions": {
# "Extensions": ".ext1,.ext2",
# "Paths":"",
# "Processes":"sampl1e1.exe, sample2.exe"
# },
# "SignatureUpdates": {
# "FileSharesSources": “”,
# "FallbackOrder”: “”,
# "ScheduleDay": 0,
# "UpdateInterval": 0,
# },
# "CloudProtection": true
#
# }’;
# Login to your Azure Resource Manager Account and select the Subscription to use
Login-AzureRmAccount

Select-AzureRmSubscription -SubscriptionId $subscriptionId


# retrieve the most recent version number of the extension
$allVersions= (Get-AzureRmVMExtensionImage -Location $location -PublisherName “Microsoft.Azure.Security” -
Type “IaaSAntimalware”).Version
$versionString = $allVersions[($allVersions.count)-1].Split(“.”)[0] + “.” +
$allVersions[($allVersions.count)-1].Split(“.”)[1]
# set the extension using prepared values
# ****—-Use this script till cmdlets address the -SettingsString format issue we observed ****—-
Set-AzureRmVMExtension -ResourceGroupName $resourceGroupName -Location $location -VMName $vmName -Name
"IaaSAntimalware" -Publisher “Microsoft.Azure.Security” -ExtensionType “IaaSAntimalware” -TypeHandlerVersion
$versionString -SettingString $settingString

向 Azure Service Fabric 群集添加 Microsoft 反恶意软件


Azure Service Fabric 使用 Azure 虚拟机规模集创建 Service Fabric 群集。 目前,未使用反恶意软件扩展启用用于
创建 Service Fabric 群集的虚拟机规模集模板。 因此,需要在规模集上单独启用反恶意软件。 在规模集上启用此
设置时,虚拟机规模集下创建的所有节点都将继承并自动获取扩展。

下面的代码示例演示了如何使用 Update-azurermvmss PS cmdlet 来启用 IaaS 反恶意软件扩展。

NOTE
在执行此代码示例之前,必须取消注释变量并提供相应的值。
# Script to add Microsoft Antimalware extension to VM Scale Set(VMSS) and Service Fabric Cluster(in turn it
used VMSS)
# Login to your Azure Resource Manager Account and select the Subscription to use
Login-AzureRmAccount
# Specify your subscription ID
$subscriptionId="SUBSCRIPTION ID HERE"
Select-AzureRmSubscription -SubscriptionId $subscriptionId
# Specify location, resource group, and VM Scaleset for the extension
$location = "LOCATION HERE" # eg., “West US or Southeast Asia” or “Central US”
$resourceGroupName = "RESOURCE GROUP NAME HERE"
$vmScaleSetName = "YOUR VM SCALE SET NAME"

# Configuration.JSON configuration file can be customized as per MSDN documentation:


https://msdn.microsoft.com/en-us/library/dn771716.aspx
$settingString = ‘{"AntimalwareEnabled": true}’;
# Enable Antimalware with custom policies
# $settingString = ‘{
# "AntimalwareEnabled": true,
# "RealtimeProtectionEnabled": true,
# "ScheduledScanSettings": {
# "isEnabled": true,
# "day": 0,
# "time": 120,
# "scanType": "Quick"
# },
# "Exclusions": {
# "Extensions": ".ext1,.ext2",
# "Paths":"",
# "Processes":"sampl1e1.exe, sample2.exe"
# } ,
# "SignatureUpdates": {
# "FileSharesSources": “”,
# "FallbackOrder”: “”,
# "ScheduleDay": 0,
# "UpdateInterval": 0,
# },
# "CloudProtection": true

# }’;

# retrieve the most recent version number of the extension


$allVersions= (Get-AzureRmVMExtensionImage -Location $location -PublisherName “Microsoft.Azure.Security” -
Type “IaaSAntimalware”).Version
$versionString = $allVersions[($allVersions.count)-1].Split(“.”)[0] + “.” +
$allVersions[($allVersions.count)-1].Split(“.”)[1]
$VMSS = Get-AzureRmVmss -ResourceGroupName $resourceGroupName -VMScaleSetName $vmScaleSetName
Add-AzureRmVmssExtension -VirtualMachineScaleSet $VMSS -Name “IaaSAntimalware” -Publisher
“Microsoft.Azure.Security” -Type “IaaSAntimalware” -TypeHandlerVersion $versionString
Update-AzureRmVmss -ResourceGroupName $resourceGroupName -Name $vmScaleSetName -VirtualMachineScaleSet $VMSS

后续步骤
详细了解适用于 Azure 的 Microsoft 反恶意软件 。
Azure 虚拟机安全概述
2021/2/9 • • Edit Online

本文概述了可用于虚拟机的核心 Azure 安全功能。

可使用 Azure 虚拟机灵活地部署各种计算解决方案。 该服务支持 Microsoft Windows、Linux、Microsoft SQL


Server、Oracle、IBM、SAP 和 Azure BizTalk Services。 因此,几乎可在任何操作系统上部署任何工作负载和任何
语言。

Azure 虚拟机让你能够灵活地进行虚拟化,而无需购买和维护运行虚拟机的物理硬件。 可生成并部署应用程序,


并保证数据在高度安全的数据中心受到保护且是安全的。

使用 Azure 可以构建安全增强且符合法规的解决方案:

保护虚拟机不受病毒和恶意软件的侵害。
加密敏感数据。
保护网络流量的安全。
识别和检测威胁。
满足符合性要求。

反恶意软件
通过 Azure,可使用安全供应商(例如 Microsoft、Symantec、Trend Micro 和 Kaspersky)提供的反恶意软件。 此软
件可帮助保护虚拟机免受恶意文件、广告程序和其他威胁的侵害。

适用于 Azure 云服务和虚拟机的 Microsoft 反恶意软件是一种实时保护功能,可帮助识别并移除病毒、间谍软件


和其他恶意软件。 适用于 Azure 的 Microsoft 反恶意软件提供可配置警报,能在已知恶意软件或不需要的软件试
图自行安装或在 Azure 系统上运行时进行警报通知。

适用于 Azure 的 Microsoft 反恶意软件是针对应用程序和租户环境的单一代理解决方案。 它旨在后台运行,且无


需人工干预。 可以根据应用程序工作负荷的需求,选择默认的基本安全性或高级的自定义配置(包括反恶意软件
监视)来部署保护。

详细了解 Microsoft Antimalware for Azure 和可用的核心功能。

了解有关反恶意软件的详细信息以保护虚拟机:

在 Azure 虚拟机上部署反恶意软件解决方案
如何在 Windows VM 上安装和配置服务型 Trend Micro Deep Security
如何在 Windows VM 上安装和配置 Symantec Endpoint Protection
Azure 市场中的安全解决方案
若要实现更强大的保护,请考虑使用 Windows Defender 高级威胁防护。 使用 Windows Defender ATP,可以实
现:

攻击面减小
下一代保护
终结点保护和响应
自动调查和补救
安全评分
高级追寻
管理和 API
Microsoft 威胁防护
了解详细信息:

WDATP 入门
WDATP 功能概述

硬件安全模块
提高密钥安全性可增强加密和身份验证保护。 通过将关键密码和密钥存储在 Azure 密钥保管库中,可以简化此
类密码和密钥的管理和保护。

密钥保管库提供将你的密钥存储在已通过 FIPS 140-2 Level 2 标准认证的硬件安全性模块 (HSM) 中的选项。 用


于备份或 透明数据加密 的 SQL Server 加密密钥可以存储在密钥保管库中,此外还可存储应用程序中的任意密
钥或机密。 对这些受保护项的权限和访问权限通过 Azure Active Directory进行管理。

了解详细信息:

什么是 Azure 密钥保管库?


Azure 密钥保管库博客

虚拟机磁盘加密
Azure 磁盘加密是用于加密 Windows 和 Linux 虚拟机磁盘的新功能。 Azure 磁盘加密利用 Windows 的行业标准
BitLocker 功能和 Linux 的 dm-crypt 功能,为 OS 和数据磁盘提供卷加密。
该解决方案与 Azure Key Vault 集成,帮助用户控制和管理 Key Vault 订阅中的磁盘加密密钥和机密。 它可确保虚
拟机磁盘上的所有数据在 Azure 存储中静态加密。

了解详细信息:

适用于 IaaS VM 的 Azure 磁盘加密


快速入门:Encrypt a Windows IaaS VM with Azure PowerShell(快速入门:使用 Azure PowerShell 加密
Windows IaaS VM)

虚拟机备份
Azure 备份是一种可缩放的解决方案,无需资本投资便可帮助保护应用程序数据,从而最大限度降低运营成本。
应用程序错误可能会损坏数据,人为错误可能会将 bug 引入应用程序。 使用 Azure 备份可以保护运行 Windows
和 Linux 的虚拟机。

了解详细信息:

什么是 Azure 备份?


Azure 备份服务 - 常见问题解答

Azure Site Recovery


组织的 BCDR 策略的其中一个重要部分是,找出在发生计划的和非计划的中断时让企业工作负荷和应用保持运
行的方法。 Azure Site Recovery 可帮助协调工作负荷和应用的复制、故障转移及恢复,因此能够在主要位置发生
故障时通过辅助位置来提供工作负荷和应用。

Site Recovery:
简化 BCDR 策略 :通过 Site Recovery 可从一个位置轻松处理多个业务工作负荷和应用的复制、故障转移及
恢复。 Site Recovery 会协调复制和故障转移,但不会拦截应用程序数据或拥有任何相关信息。
提供灵活的复制 :借助 Site Recovery,可以复制 Hyper-V 虚拟机、VMware 虚拟机和 Windows/Linux 物理服
务器上运行的工作负荷。
支持故障 转 移和恢复 :Site Recovery 提供测试故障转移,既能支持灾难恢复练习,又不会影响生产环境。 还
可针对预期会出现的中断运行计划内故障转移,确保不丢失任何数据;或者针对意外灾难运行计划外故障转
移,尽量减少数据丢失(具体取决于复制频率)。 故障转移之后,可故障回复到主站点。 Site Recovery 提供包
含脚本和 Azure 自动化工作簿的恢复计划,以供你自定义多层应用程序的故障转移和恢复。
消除 辅 助数据中心 :可复制到辅助本地站点,或复制到 Azure。 使用 Azure 作为灾难恢复的目标可以消除维
护辅助站点所带来的成本和复杂性。 复制的数据存储在 Azure 存储中。
与现有 BCDR 技 术 集成 :Site Recovery 能够与其他应用程序的 BCDR 功能结合使用。 例如,可使用 Site
Recovery 来帮助保护公司工作负荷的 SQL Server 后端。 这包括对 SQL Server AlwaysOn 的本机支持以管理
可用性组的故障转移。

了解详细信息:

什么是 Azure Site Recovery?


Azure Site Recovery 的工作原理是什么?
哪些工作负荷受 Azure Site Recovery 保护?

虚拟网络
虚拟机需要网络连接。 若要支持该需求,Azure 要求将虚拟机连接到 Azure 虚拟网络。

Azure 虚拟网络是一个构建于物理 Azure 网络结构之上的逻辑构造。 每个逻辑 Azure 虚拟网络都独立于所有其


他 Azure 虚拟网络。 这种隔离有助于确保其他 Microsoft Azure 客户无法访问部署中的网络流量。

了解详细信息:

Azure 网络安全概述
虚拟网络概述
Networking features and partnerships for Enterprise scenarios(网络功能和用于企业方案的合作关系)

安全策略管理和报告
Azure 安全中心可帮助防范、检测和应对威胁。 通过安全中心可提高对 Azure 资源安全性的可见性和控制力度。
它为 Azure 订阅提供集成的安全监控和策略管理。 它有助于检测可能会被忽视的威胁,适用于各种安全解决方
案生态系统。

安全中心通过以下方式帮助优化和监视虚拟机的安全:

为虚拟机提供安全建议。 示例建议包括:应用系统更新、配置 ACL 终结点、启用反恶意软件、启用网络安全组


和应用磁盘加密。
监视虚拟机的状态。

了解详细信息:

Azure 安全中心简介
Azure 安全中心常见问题解答
Azure 安全中心规划和操作

合规性
Azure 虚拟机已针对 FISMA、FedRAMP、HIPAA、PCI DSS Level 1 和其他关键合规性计划进行了认证。 此认证使
自己的 Azure 应用程序更容易满足合规性要求,并使企业更容易应对各种国内和国际法规要求。

了解详细信息:

Microsoft Trust Center:Compliance(Microsoft 信任中心:合规性)


Trusted Cloud:Microsoft Azure Security, Privacy, and Compliance(可信云:Microsoft Azure 安全性、隐私和合
规性)

机密计算
虽然机密计算在技术方面不是虚拟机安全性的一部分,但是虚拟机安全性的主题属于“计算”安全性的更高级别的
主题。 机密计算属于“计算”安全性类别。

当数据“采用明文”(这是进行高效处理所必需的)时,机密计算可确保数据在可信执行环境
https://en.wikipedia.org/wiki/Trusted_execution_environment (TEE - 也称为飞地)中受到保护,下图显示了一个
这样的示例。

TEE 可以确保无法从外部查看数据或执行操作,即使通过调试程序也不可以。 它们甚至可以确保只有经过授权的


代码才能访问数据。 如果代码被更改或篡改,则会拒绝操作并禁用环境。 TEE 会在代码在它中执行的整个过程中
实施这些保护。

了解详细信息:

Azure 机密计算介绍
Azure 机密计算

后续步骤
了解 VM 和操作系统的安全最佳做法。
Azure 中 IaaS ⼯作负荷的安全性最佳实践
2021/2/9 • • Edit Online

本文介绍了 VM 和操作系统的安全最佳做法。

最佳做法以观点的共识以及 Azure 平台功能和特性集为基础。 由于观点和技术会随时改变,本文会进行更新以


反映这些变化。

在大多数基础结构即服务 (IaaS) 方案中,Azure 虚拟机 (VM) 是使用云计算的组织的主要工作负荷。 这种事实


在混合方案中十分明显,组织希望在混合方案中慢慢将工作负载迁移到云。 在这种方案中,应遵循 IaaS 常规安
全注意事项,并向所有 VM 应用安全最佳做法。

通过身份验证和访问控制保护 VM
保护 VM 安全的第一步是确保只有授权用户才能设置新 VM 以及访问 VM。

NOTE
若要改进 Azure 上 Linux VM 的安全性,可以与 Azure AD 身份验证集成。 使用适用于 Linux VM 的 Azure AD 身份验证时,
可以通过集中进行控制和强制实施策略来允许或拒绝对 VM 的访问。

最佳做法 :控制 VM 访问。


详细 信息 :使用 Azure 策略建立组织中的资源约定和创建自定义策略。 将这些策略应用于资源,如资源组。 属于
该资源组的 VM 将继承该组的策略。

如果你的组织有多个订阅,则可能需要一种方法来高效地管理这些订阅的访问权限、策略和符合性。 Azure 管理
组提供订阅上的作用域级别。 可将订阅组织到管理组(容器)中,并将管理条件应用到该组。 管理组中的所有订
阅都将自动继承应用于该组的条件。 不管使用什么类型的订阅,管理组都能提供大规模的企业级管理。

最佳做法 :减少 VM 的安装和部署的可变性。


详细 信息 :使用 Azure 资源管理器模板增强部署选项,使其更易理解并清点环境中的 VM。

最佳做法 :保护特权访问。
详细 信息 :使用 最低特权方法和内置 Azure 角色使用户能够访问和设置 VM:

虚拟机参与者:可以管理 VM,但无法管理虚拟机连接的虚拟网络或存储帐户。
经典虚拟机参与者:可管理使用经典部署模型创建的 VM,但无法管理这些 VM 连接到的虚拟网络或存储帐
户。
安全管理员:仅在安全中心内:可以查看安全策略、查看安全状态、编辑安全策略、查看警报和建议、关闭警报
和建议。
开发测试实验室用户:可以查看所有内容,以及连接、启动、重新启动和关闭 VM。

订阅管理员和共同管理员可更改此设置,使其成为订阅中所有 VM 的管理员。 请确保你信任所有订阅管理员和


共同管理员,以登录你的任何计算机。

NOTE
建议将具有相同生命周期的 VM 合并到同一个资源组中。 使用资源组可以部署和监视资源,并统计资源的计费成本。

控制 VM 访问和设置的组织可改善其整体 VM 安全性。
使用多个 VM 提高可用性
如果 VM 运行需要具有高可用性的关键应用程序,我们强烈建议使用多个 VM。 为了获得更好的可用性,请使用
可用性集 或可用性 区域。

可用性集是一种逻辑分组功能,在 Azure 中使用它可以确保将 VM 资源部署在 Azure 数据中心后,这些资源相互


隔离。 Azure 确保可用性集中部署的 VM 能够跨多个物理服务器、计算机架、存储单元和网络交换机运行。 如果
出现硬件或 Azure 软件故障,只有一部分 VM 会受到影响,整体应用程序仍可供客户使用。 如果想要构建可靠的
云解决方案,可用性集是一项关键功能。

防范恶意软件
应安装反恶意软件保护,以帮助识别和删除病毒、间谍软件和其他恶意软件。 可安装 Microsoft 反恶意软件或
Microsoft 合作伙伴的终结点保护解决方案(Trend Micro、Broadcom、McAfee、Windows Defender 和 System
Center Endpoint Protection)。
Microsoft 反恶意软件包括实时保护、计划扫描、恶意软件修正、签名更新、引擎更新、示例报告和排除事件收集
等功能。 对于与生产环境分开托管的环境,可以使用反恶意软件扩展来帮助保护 VM 和云服务。

可将 Microsoft 反恶意软件和合作伙伴解决方案与 Azure 安全中心集成,以方便部署和内置检测(警报和事件)。

最佳做法 :安装反恶意软件解决方案,以防范恶意软件。
详细 信息 :安装 Microsoft 合作伙伴解决方案或 Microsoft 反恶意软件

最佳做法 :将反恶意软件解决方案与安全中心集成,以监视保护状态。
详细 信息 :使用安全中心管理终结点保护问题

管理 VM 更新
与所有本地 VM 一样,Azure VM 应由用户管理。 Azure 不会向他们推送 Windows 更新。 你需要管理 VM 更新。

最佳做法:使 VM 保持最新。
详细信息:使用 Azure 自动化中的更新管理解决方案,为部署在 Azure、本地环境或其他云提供程序中的
Windows 和 Linux 计算机管理操作系统更新。 可以快速评估所有代理计算机上可用更新的状态,并管理为服务
器安装所需更新的过程。

由更新管理托管的计算机使用以下配置执行评估和更新部署:

用于 Windows 或 Linux 的 Microsoft 监视代理 (MMA)


用于 Linux 的 PowerShell 所需状态配置 (DSC)
自动化混合 Runbook 辅助角色
适用于 Windows 计算机的 Microsoft 更新或 Windows Server 更新服务 (WSUS)

若使用 Windows 更新,请启用 Windows 自动更新设置。

最佳做法 :在部署时,确保构建的映像包含最新一轮的 Windows 更新。


详细 信息 :每个部署的第一步应是检查和安装所有 Windows 更新。 在部署自己或库中提供的映像时,采用此措
施就特别重要。 虽然默认情况下会自动更新 Azure 市场中的映像,但公开发布后可能会有延迟(最多几周)。

最佳做法 :定期重新部署 VM 以强制刷新操作系统版本。


详细 信息 :使用 Azure 资源管理器模板定义 VM,以便轻松地重新部署。 使用模板可在需要时提供已修补且安全
的 VM。

最佳做法 :快速对 VM 应用安全更新。


详细 信息 :启用 Azure 安全中心(免费层或标准层)以 识别缺少的安全更新并应用这些安全更新。

最佳做法 :安装最新的安全更新。
详细 信息 :客户移到 Azure 的部分首批工作负荷为实验室和面向外部的系统。 如果 Azure VM 托管需要访问
Internet 的应用程序或服务,则需要警惕修补。 修补不仅仅包括操作系统。 合作伙伴应用程序上未修补的漏洞还
可能导致一些问题,而如果实施良好的修补程序管理,就可以避免这些问题。

最佳做法 :部署并测试一个备份解决方案。
详细 信息 :需要按照处理任何其他操作的相同方法处理备份。 这适合于属于扩展到云的生产环境的系统。

测试和开发系统必须遵循备份策略,这些策略可以根据用户的本地环境体验,提供与用户习惯的功能类似的存储
功能。 如果可能,迁移到 Azure 的生产工作负荷应与现有的备份解决方案集成。 或者,可以使用 Azure 备份来帮
助解决备份要求。

未实施软件更新策略的组织面临更多利用已修复的已知漏洞的威胁。 为了遵守行业法规,公司还必须证明他们
在不断作出相应努力并使用正确的安全控制机制来帮助确保云中工作负载的安全性。

传统数据中心与 Azure IaaS 之间的软件更新最佳做法存在许多相似之处。 建议评估当前的软件更新策略,将位


于 Azure 中的 VM 包含在内。

管理 VM 安全状况
网络威胁不断加剧。 保护 VM 需要监视功能,以便快速检测威胁、防止有人未经授权访问资源、触发警报并减少
误报。

若要监视 Windows 和 Linux VM 的安全状况,可以使用 Azure 安全中心。 可以利用安全中心的以下功能来保护


VM:
应用包含建议的配置规则的 OS 安全设置。
识别并下载可能缺少的系统安全更新和关键更新。
部署终结点反恶意软件防护建议措施。
验证磁盘加密。
评估并修正漏洞。
检测威胁。

安全中心可主动监视威胁,并通过“安全警报”公开潜在的威胁。 关联的威胁将合并到名为“安全事件”的单个视图
中。

安全中心将数据存储在 Azure Monitor 日志中。 Azure Monitor 日志提供查询语言和分析引擎,让你能够深入了


解应用程序和资源的操作。 数据也是从 Azure Monitor 、管理解决方案以及安装在虚拟机(云中或本地)上的代理
收集的数据。 可以通过此共享功能全面了解自己的环境。

没有为 VM 实施强大安全措施的组织将意识不到未经授权的用户可能试图绕过安全控制机制。

监视 VM 性能
如果 VM 进程消耗的资源多过实际所需的量,可能会造成资源滥用的问题。 VM 性能问题可能会导致服务中断,
从而违反可用性安全原则。 这对于托管 IIS 或其他 Web 服务器的 VM 尤其重要,因为 CPU 或内存占用较高可能
意味着遭到拒绝服务 (DoS) 攻击。 不仅要在出现问题时被动监视 VM 的访问,而且还要在正常运行期间针对基
准性能进行主动监视。

我们还建议使用 Azure Monitor 来洞察资源的运行状况。 Azure Monitor 功能:

资源诊断日志文件:监视 VM 资源并识别可能会损害性能与可用性的潜在问题。
Azure 诊断扩展:在 Windows VM 上提供监视和诊断功能。 在 Azure 资源管理器模板中包含该扩展即可启用
这些功能。

不监视 VM 性能的组织无法确定性能模式的某些变化是正常还是异常。 若 VM 消耗的资源超过平常,可能意味


着存在来自外部资源的攻击,或者此 VM 中有不安全的进程正在运行。
加密虚拟硬盘文件
建议加密虚拟硬盘 (VHD),以帮助保护存储中的静态启动卷和数据卷以及加密密钥和机密。

Azure 磁盘加密用于加密 Windows 和 Linux IaaS 虚拟机磁盘。 Azure 磁盘加密使用 Windows 行业标准的
BitLocker 功能和 Linux 的 DM-CRYPT 功能为 OS 和数据磁盘提供卷加密。 该解决方案与 Azure Key Vault 集成,
帮助用户管理 Key Vault 订阅中的磁盘加密密钥和机密。 此解决方案还可确保虚拟机磁盘上的所有数据在 Azure
存储中静态加密。

下面是使用 Azure 磁盘加密的最佳做法:

最佳做法 :在 VM 上启用加密。
详细 信息 :Azure 磁盘加密将生成加密密钥并将其写入密钥保管库。 在 Key Vault 中管理加密密钥需要 Azure AD
身份验证。 为此,请创建 Azure AD 应用程序。 对于身份验证,可以使用基于客户端机密的身份验证或基于客户
端证书的 Azure AD 身份验证。

最佳做法:使用密钥加密密钥 (KEK) 来为加密密钥提供附加的安全层。 将 KEK 添加到密钥保管库。


详细 信息 :使用 AzKeyVaultKey cmdlet 在 key vault 中创建密钥加密密钥。 还可从本地硬件安全模块 (HSM) 导入
KEK 以进行密钥管理。 有关详细信息,请参阅 Key Vault 文档。 指定密钥加密密钥后,Azure 磁盘加密会使用该密
钥包装加密机密,然后将机密写入 Key Vault。 在本地密钥管理 HSM 中保留此密钥的托管副本,提供额外的保
护,防止意外删除密钥。

最佳做法 :在加密磁盘之前创建 快照和/或备份。 如果加密期间发生意外故障,备份可提供恢复选项。


详细 信息 :加密之前,需要备份包含托管磁盘的 VM。 备份之后,可以通过指定“-skipVmBackup”参数,使用“Set-
AzVMDiskEncryptionExtension cmdlet”来加密托管磁盘。 有关如何备份和还原已加密 VM 的详细信息,请参阅
Azure 备份一文。
最佳做法 :为确保加密机密不会跨过区域边界,Azure 磁盘加密需要将密钥保管库和 VM 共置在同一区域。
详细 信息 :在要加密的 VM 所在的同一区域中创建并使用密钥保管库。

Azure 磁盘加密可解决以下业务需求:
使用行业标准的加密技术轻松保护 IaaS VM,满足组织的安全性与合规性要求。
IaaS VM 会根据客户控制的密钥和策略启动,客户可以在 Key Vault 中审核密钥和策略的使用方式。

限制直接 Internet 连接
监视和限制 VM 直接 Internet 连接。 攻击者会不断地扫描公共云 IP 范围,寻找开放管理端口,并尝试 "轻松" 的
攻击,如常见密码和已知的修补漏洞。 下表列出了有助于防范这些攻击的最佳做法:

最佳做法 :防止无意中暴露网络路由和安全性。
详细 信息 :使用 Azure RBAC 确保只有中心网络组具有网络资源的权限。

最佳做法 :标识并修正允许从 "任何" 源 IP 地址进行访问的公开 vm 。


详细 信息 :使用 Azure 安全中心。 如果你的任何网络安全组有一个或多个允许从 "任何" 源 IP 地址进行访问的入
站规则,安全中心将建议你通过面向 internet 的终结点限制访问。 安全中心将建议编辑这些入站规则,以对实际
需要访问的源 IP 地址限制访问。

最佳做法 :限制管理端口(RDP、SSH)。
详细 信息 :实时 (JIT) VM 访问可以用来锁定发往 Azure VM 的入站流量,降低遭受攻击的可能性,同时在需要时
还允许轻松连接到 VM。 当 JIT 时,安全中心会通过创建网络安全组规则来锁定发往 Azure VM 的入站流量。 你
需要选择要锁定 VM 上的哪些端口的入站流量。 这些端口将受 JIT 解决方案控制。

后续步骤
有关通过 Azure 设计、部署和管理云解决方案时可以使用的更多安全最佳做法,请参阅 Azure 安全最佳做法和模
式。
以下资源提供了有关 Azure 安全性及相关 Microsoft 服务的更多常规信息:

Azure 安全团队博客 - 随时掌握 Azure 安全性的最新信息


Microsoft 安全响应中心 - 可在其中报告 Microsoft 安全漏洞(包括 Azure 问题)或将其通过电子邮件发送到
secure@microsoft.com
适⽤于 Azure 市场映像的安全建议
2021/2/9 • • Edit Online

映像必须满足这些安全配置建议。 这些建议不仅有助于为 Azure 市场中的合作伙伴解决方案映像保持高级别的


安全性。

提交之前,始终在映像上运行安全漏洞检测。 如果你在自己发布的映像中检测到安全漏洞,则必须及时通知你的
客户,并将其更正。

打开基于源的映像

安全 安装适用于 Linux 分发版的所有最新安全修补程序。

安全 遵循行业准则,保护特定 Linux 分发版的 VM 映像。

安全 限制攻击面,仅保留必要的 Windows Server 角色、功能、服务


和网络端口来保持最小的占用空间。

安全 扫描源代码和生成的 VM 映像中的恶意软件。

安全 VHD 映像只包含没有默认密码允许交互式登录的必要锁定帐
户;无后门。

安全 禁用防火墙规则,除非应用程序依赖于它们,如防火墙设备。

安全 删除 VHD 映像中的所有敏感信息,例如测试 SSH 密钥、已知


主机文件、日志文件和不必要的证书。

安全 避免使用 LVM。

安全 包含所需库的最新版本:
- OpenSSL v1.0 或更高版本
- Python 2.5 或更高版本(强烈建议使用 Python 2.6+)
- Python pyasn1 包(如果尚未安装)
- d.OpenSSL v 1.0 或更高版本

安全 清除 Bash/Shell 历史记录项。

网络 默认情况下包括 SSH 服务器。 将 SSH 保持连接到 sshd


config,并提供以下选项: ClientAliveInterval 180。

网络 从映像中删除任何自定义网络配置。 删除 resolv.conf:
rm /etc/resolv.conf 。
部署 安装最新的 Azure Linux 代理。
-使用 RPM 或 Deb 包安装。
- 也可使用手动安装进程,但建议首选安装包。
- 如果要从 GitHub 存储库手动安装代理,首先请将
waagent 文件复制到 /usr/sbin 中并(以 root 身份)运行:
# chmod 755 /usr/sbin/waagent
# /usr/sbin/waagent -install
代理配置文件放置在 /etc/waagent.conf 中。

部署 确保 Azure 支持人员可以在需要时为合作伙伴提供串行控制
台输出,并为从云存储装载的操作系统磁盘提供足够的超时
时间。 将以下参数添加到映像内核引导行:
console=ttyS0 earlyprintk=ttyS0 rootdelay=300 。

部署 OS 磁盘上无需交换分区。 可通过 Linux 代理在本地资源磁盘


上请求创建交换。

部署 为 OS 磁盘创建一个根分区。

部署 仅支持 64 位 操作系统。

基于 Windows Server 的映像

安全 使用安全 OS 的基础映像。 用于任何基于 Windows Server 的


映像源的 VHD 必须来自 Microsoft Azure 所提供的 Windows
Server OS 映像。

安全 安装所有最新的安全更新。

安全 应用程序不应依赖于受限用户名,如管理员、root 或 admin。

安全 为 OS 硬盘驱动器和数据硬盘启用 BitLocker 驱动器加密。

安全 限制攻击面,仅保留必要的 Windows Server 角色、功能、服务


和网络端口来保持最小的占用空间。

安全 扫描源代码和生成的 VM 映像中的恶意软件。

安全 将 Windows Server 映像安全更新设置为自动更新。

安全 VHD 映像只包含没有默认密码允许交互式登录的必要锁定帐
户;无后门。

安全 禁用防火墙规则,除非应用程序依赖于它们,如防火墙设备。

安全 删除 VHD 映像中的所有敏感信息,包括主机文件、日志文件
和不必要的证书。

部署 仅支持 64 位 操作系统。

即使你的组织没有 Azure marketplace 中的映像,也可以考虑根据这些建议检查 Windows 和 Linux 映像配置。


Azure 加密概述
2021/2/9 • • Edit Online

本文概述了如何在 Microsoft Azure 中使用加密。 其中涵盖了加密的主要领域,包括 Azure Key Vault 的静态加


密、动态加密以及密钥管理。 每个部分包括更详细信息的链接。

静态数据加密
静态数据包括以任何数字格式驻留在物理介质上的永久性存储中的信息。 该介质可包括磁性介质或光学介质上
的文件、归档数据和数据备份。 Microsoft Azure 提供各种数据存储解决方案,以满足不同需求,包括文件、磁
盘、blob 和表存储。 Microsoft 还提供加密以保护 Azure SQL 数据库、Azure Cosmos DB 和 Azure Data Lake。

静态数据加密可用于服务型软件 (SaaS)、平台即服务 (PaaS) 和基础结构即服务 (IaaS) 云模型中的服务。 本文总


结并提供资源,以帮助使用 Azure 加密选项。

有关如何在 Azure 中加密静态数据的更详细的讨论,请参阅 Azure 静态数据加密。

Azure 加密模型
Azure 支持各种加密模型,包括使用服务托管密钥、Key Vault 中客户托管密钥或客户所控硬件上客户托管密钥的
服务器端加密。 通过客户端加密,可在本地或另一个安全位置管理并存储密钥。

客 户 端加密
客户端加密在 Azure 之外执行。 其中包括:

由客户数据中心中运行的应用程序或服务应用程序加密的数据。
当 Azure 接收到数据时,数据已加密。

使用客户端加密时,云服务提供商无法访问加密密钥,因此无法解密该数据。 你完全控制了密钥。

服 务 器端加密
三个服务器端加密模型提供不同的密钥管理特性,可根据要求进行选择:

服 务 托管密 钥 :可带来低开销的控制和便利。

客 户 管理的密 钥 :可用于控制密钥,包括支持“创建自己的密钥”(BYOK) 或生成新密钥。

客 户 所控硬件上的服 务 托管密 钥 :可用于管理不受 Microsoft 控制的专有存储库中的密钥。 此特性称为


自留密钥 (HYOK)。 但是,配置相当复杂,并且大多数 Azure 服务都不支持此模式。

Azure 磁 盘 加密
可使用 Azure 磁盘加密保护 Windows 和 Linux 虚拟机,它采用 Windows BitLocker 技术和 Linux DM-Crypt通过
全卷加密来保护操作系统磁盘和数据磁盘。

Azure Key Vault 订阅中的加密密钥和机密会得到保护。 使用 Azure 备份服务,可备份和还原使用密钥加密密钥


(KEK) 配置的加密虚拟机 (VM)。
Azure 存 储 服 务 加密
Azure Blob 存储和 Azure 文件共享中的静态数据都可以在服务器端和客户端方案中进行加密。
Azure 存储服务加密 (SSE) 可在数据存储前自动加密数据,并在检索数据时自动解密数据。 此过程对用户是完全
透明的。 存储服务加密使用 256 位高级加密标准 (AES) 加密,这是可用的最强分组加密中的一种。 AES 采用透
明方式处理加密、解密和密钥管理。
Azure blob 的客 户 端加密
可通过各种方式执行 Azure blob 的客户端加密。

可使用适用于 .NET NuGet 包的 Azure 存储客户端库在客户端应用程序内加密数据,然后再将其上传到 Azure 存


储。

若要详细了解和下载适用于.NET NuGet 包的 Azure 存储客户端库,请参阅 Windows Azure 存储 8.3.0 。

在 Key Vault 中使用客户端加密时,将使用 Azure 存储客户端 SDK 生成的一次性对称内容加密密钥 (CEK) 加密数


据。 CEK 在使用密钥加密密钥 (KEK) 加密后,可以是对称密钥,也可以是非对称密钥对。 可在本地进行管理或将
其存储在 Key Vault 中。 然后,将加密数据上传到 Azure 存储。

若要详细了解 Key Vault 的客户端加密和学习使用操作说明,请参阅教程:在 Azure 存储中使用 Key Vault 加密和


解密 Blob。

最后,还可使用适用于 Java 的 Azure 存储客户端库执行客户端加密,之后再将数据上传到 Azure 存储,并在将数


据下载到客户端时解密数据。 此库还支持与 Key Vault 集成,以便管理存储帐户密钥。

使用 Azure SQL 数据 库 加密静 态 数据


Azure SQL 数据库是 Azure 中通用的关系数据库服务,支持关系数据、JSON、空间和 XML 等结构。 SQL 数据库
通过透明数据加密 (TDE) 功能支持服务器端加密,通过 Always Encrypted 功能支持客户端加密。

透明数据加密

TDE 可通过数据库加密密钥 (DEK) 实时加密 SQL Server、Azure SQL 数据库和 Azure Synapse Analytics 数据文
件,该加密密钥存储在数据库启动记录中,可在恢复期间使用。

TDE 使用 AES 和三重数据加密标准 (3DES) 加密算法保护数据和日志文件。 数据库文件加密在页面级执行。 加密


数据库中的页面在写入磁盘之前被加密,在读入内存后被解密。 默认情况下,新创建的 Azure SQL 数据库启用
TDE。
Always Encrypted 功能
借助 Azure SQL 中的 Always Encrypted 功能,可在客户端应用程序中加密数据,之后再将其存储在 Azure SQL
数据库中。 还可将本地数据库管理工作委派给第三方,并将数据拥有者和可查看数据的人员,以及管理数据但无
权访问数据的人员分开。

单 元 级 加密或列 级 加密

借助 Azure SQL 数据库,可使用 Transact-SQL 对数据列应用对称加密。 这种方法被称为单元级加密或列级加密


(CLE),因为可使用这种方法通过不同加密密钥来加密特定列,甚至是特定数据单元。 这样可以提供比 TDE 更加
精细的加密功能,能够加密页面中的数据。

CLE 具有内置函数,可通过函数使用对称或非对称密钥、证书的公钥或 3DES 的密码来加密数据。


Cosmos DB 数据 库 加密
Azure Cosmos DB 由 Microsoft 提供,是全球分布式多模型数据库。 存储在非易失性存储(固态硬盘)中的
Cosmos DB 中的用户数据默认加密。 无法将其打开或关闭。 静态加密是使用许多安全技术实现的,其中包括安
全的密钥存储系统、加密的网络以及加密 API。 加密密钥由 Microsoft 管理,并根据 Microsoft 的内部指南进行轮
换。

Data Lake 中的静 态 加密


Azure Data Lake 是在正式定义需求或架构之前,在单个位置收集的每种类型数据的企业级存储库。 Data Lake
Store 支持“默认启用”透明加密静态数据,可以在创建帐户期间设置。 默认情况下,Azure Data Lake Store 替你管
理密钥,但你可以选择自己管理密钥。

有三种类型的密钥用于加密和解密数据:主加密密钥 (MEK)、数据加密密钥 (DEK) 和块加密密钥 (BEK)。 MEK 用


于加密存储在永久性介质上的 DEK,BEK 派生自 DEK 和数据块。 如果管理自己的密钥,可以轮换 MEK。

传输中的数据加密
Azure 提供了许多机制,用于在迁移数据时保持数据的私密性。
Azure 中的数据 链 路 层 加密
每当 Azure 客户流量在数据中心之间(在不受 Microsoft 或代表 Microsoft 的某方控制的物理边界之外)移动时,
都会在底层网络硬件上点对点应用使用 IEEE 802.1AE MAC 安全标准(也称 MACsec)的数据链路层加密方法。 数
据包会在发送之前在设备上进行加密和解密,以防止物理上的“中间人”攻击或窥探/窃听攻击。 由于此技术在网
络硬件本身上集成,因此它会在网络硬件上提供线路速率加密,而不会增加可度量的链路延迟。 对于在区域内或
区域之间传输的所有 Azure 流量,会默认启用此 MACsec 加密,客户无需执行任何操作。

Azure 中的 TLS 加密
Microsoft 让客户能够使用传输层安全性 (TLS) 协议来保护在云服务和客户之间传输的数据。 Microsoft 的数据中
心与连接到 Azure 服务的客户端系统协商建立 TLS 连接。 TLS 提供严格的身份验证,消息隐私性和完整性强(允
许检测消息篡改、拦截和伪造),具有良好的互操作性,算法灵活,易于部署和使用。

完美正向保密 (PFS) 通过唯一密钥保护客户的客户端系统与 Microsoft 云服务间的连接。 连接还使用基于 RSA


的 2,048 位加密密钥长度。 此组合使得别人难以拦截和访问传输中的数据。

Azure 存 储 事 务
当通过 Azure 门户与 Azure 存储交互时,所有事务都通过 HTTPS 发生。 也可根据 HTTPS 使用存储 REST API 与
Azure 存储交互。 在调用 REST API 来访问存储帐户中的对象时,可通过启用存储帐户所需的安全传输来强制使
用 HTTPS 。

使用共享访问签名 (SAS) 除了能委派对 Azure 存储对象的访问权限,还能包含一个选项,指定在使用共享访问签


名时只能使用 HTTPS 协议。 通过此方法,可确保只能使用正确的协议发送有 SAS 令牌的链接。

用于访问 Azure 文件共享的 SMB 3.0 支持加密,并且可以在 Windows Server 2012 R2 、Windows 8 、Windows
8.1 和 Windows 10 中使用。 它允许跨区域访问,甚至在桌面上访问。
在将数据发送到 Azure 存储实例前,客户端加密会对数据加密,所以在通过网络传输时数据是加密的。

Azure 虚 拟 网 络 上的 SMB 加密
在运行 Windows Server 2012 或更高版本的 VM 中使用 SMB 3.0 后,可对在 Azure 虚拟网络上传输数据进行加
密,以此确保数据安全传输。 加密数据有助于防止数据遭到篡改和窃听攻击。 管理员可以为整个服务器启用
SMB 加密,也可以启用特定的共享。
默认情况下,为共享或服务器启用 SMB 加密后,只允许 SMB 3.0 客户端访问加密共享。

VM 中的传输中加密
根据连接的性质,可通过多种方式对在运行 Windows 的 VM 间传输的数据进行加密。

RDP 会 话
可以使用 Windows 客户端计算机或者安装了 RDP 客户端的 Mac 上的远程桌面协议 (RDP) 连接并登录 VM。 在
RDP 会话中通过网络传输的数据可以受到 TLS 的保护。
还可使用远程桌面连接到 Azure 中的 Linux VM。

使用 SSH 安全 访问 Linux VM
若要进行远程管理,可以使用安全外壳 (SSH) 连接到在 Azure 中运行的 Linux VM。 SSH 是一种加密的连接协
议,利用该协议可以通过未受保护的连接进行安全登录。 它是适用于 Azure 中托管的 Linux VM 的默认连接协
议。 使用 SSH 密钥进行身份验证,无需使用密码即可登录。 SSH 使用公钥/私钥对(非对称加密)进行身份验证。

Azure VPN 加密
连接到 Azure 时可以使用虚拟专用网络,它可以创建安全通道以保护通过网络发送的数据的隐私。

Azure VPN 网关
可使用 Azure VPN 网关跨公共连接在虚拟网络和本地位置间发送加密流量,或在虚拟网络间发送流量。

站点到站点 VPN 使用 IPsec 进行传输加密。 Azure VPN网关使用一组默认提议。 可将 Azure VPN 网关配置为使


用具有特定加密算法和关键优势的自定义 IPsec/IKE 策略,而不是 Azure 默认策略集。

点到站点 VPN
点到站点 VPN 允许单个客户端计算机访问 Azure 虚拟网络。 安全套接字隧道协议 (SSTP) 可用于创建 VPN 隧
道。 它可遍历防火墙(隧道显示为 HTTPS 连接)。 你可使用自己的内部公钥基础结构 (PKI) 根证书颁发机构 (CA)
实现点到站点的连接。

可以使用具有证书身份验证或 PowerShell 的 Azure 门户,将点到站点 VPN 连接配置到虚拟网络。

若要详细了解点到站点 VPN 连接与 Azure 虚拟网络,请参阅:

使用证书身份验证将点到站点连接配置到虚拟网络:Azure 门户

使用证书身份验证将点到站点连接配置到虚拟网络:PowerShell

站点到站点 VPN
可使用站点到站点 VPN 网关连接,通过 IPsec/IKE(IKEv1 或 IKEv2 )VPN 隧道将本地网络连接到 Azure 虚拟网络。
此类型的连接需要一个分配有面向外部的公共 IP 地址的本地 VPN 设备。

可以使用 Azure门户、PowerShell 或 Azure CLI 将站点到站点 VPN 连接配置到虚拟网络。

有关详细信息,请参阅:

在 Azure 门户中创建站点到站点连接

在 PowerShell 门户中创建站点到站点连接

使用 CLI 创建具有站点到站点 VPN 连接的虚拟网络

Data Lake 中的传输中加密


此外,还会始终在 Data Lake Store 中对传输数据(也称移动数据)加密。 除在将数据存储到永久性介质前进行加
密外,还始终会在数据传输过程中使用 HTTPS 保护数据。 HTTPS 是 Data Lake Store REST 接口唯一支持的协议。

若要详细了解 Data Lake 中的传输中数据加密,请参阅 Data Lake Store 中的数据加密。

使用 Key Vault 的密钥管理


如果没有适当地保护和管理密钥,加密会变得毫无用处。 Key Vault 是 Microsoft 推荐的解决方案,用于管理和控
制云服务使用的对加密密钥的访问。 访问密钥的权限可以通过 Azure Active Directory 帐户分配给服务或用户。

Key Vault 可帮助组织减少对配置、修补以及维护硬件安全模块 (HSM) 和密钥管理软件的需求。 使用 Key Vault


时,一切由你控制。 Microsoft 永远看不到你的密钥,应用程序无法直接访问密钥。 也可以在 HSM 中导入或生成
密钥。

后续步骤
Azure 安全概述
Azure 网络安全概述
Azure 数据库安全性概述
Azure 虚拟机安全概述
静态数据加密
数据安全与加密最佳做法
双重加密
2021/2/9 • • Edit Online

双加密是指启用了两个或更多独立加密层,以防止任何一层加密的损害。 使用两个加密层可减少对数据加密所
带来的威胁。 例如:

数据加密中的配置错误
加密算法中的实现错误
泄露单个加密密钥

Azure 为静态数据和传输中的数据提供双精度加密。

静态数据
Microsoft 针对静态数据启用两层加密的方法是:
使用客 户 托管密 钥 的磁 盘 加密 。 提供自己的密钥用于磁盘加密。 你可以将自己的密钥带到 Key Vault (BYOK
–创建自己的密钥) ,或在 Azure Key Vault 中生成新的密钥来加密所需的资源。
使用平台托管密 钥 的基 础结 构加密 。 默认情况下,使用平台托管的加密密钥自动对磁盘进行静态加密。

传输中的数据
对于传输中的数据启用两层加密的方法是:

传输 加密使用 传输层 安全性 (TLS) 1.2 ,用于在云服 务 和你之 间传输 数据 时 保 护 数据 。 即使流量目标是


同一区域中的另一个域控制器,离开数据中心的所有流量仍会在传输过程中加密。 TLS 1.2 是使用的默认安全
协议。 TLS 提供严格的身份验证,消息隐私性和完整性强(允许检测消息篡改、拦截和伪造),具有良好的互操
作性,算法灵活,易于部署和使用。
基 础结 构 层 提供的其他加密 层 。 使用 IEEE 802.1 AE MAC 安全标准的数据链路层加密方法 (也称为 MACsec)
在基础网络硬件之间通过点到点应用。 每当 Azure 客户流量在数据中心之间移动时(不是由 Microsoft (或代
表 Microsoft) 控制),包在发送之前将在设备上加密和解密,从而阻止物理 "中间人" 或侦听/wiretapping 攻
击。 由于此技术在网络硬件本身上集成,因此它会在网络硬件上提供线路速率加密,而不会增加可度量的链
路延迟。 默认情况下,此 MACsec 加密对于某个区域内或各区域之间的所有 Azure 流量都处于启用状态,并
且在要启用的客户部件上无需执行任何操作。

后续步骤
了解如何 在 Azure 中使用加密。
Azure TLS 证书更改
2021/2/9 • • Edit Online

Microsoft 在将 Azure 服务更新为使用来自一组不同的根证书颁发机构 (CA) 的 TLS 证书。 正在进行此更改,因为


当前 CA 证书不符合某个 CA/浏览器论坛基线要求,将于2021 年2 月15 日吊销。

此更改将在何时进行?
从 2020 年 8 月 13 日起,现有 Azure 终结点已开始分阶段转换。 所有新创建的 Azure TLS/SSL 终结点都包含链
接到新根 CA 的已更新证书。

特定于服务的详细信息:

Azure Active Directory (Azure AD) 服务在 2020 年 7 月 7 日开始此过渡。


Azure IoT 中心和 DPS 将继续使用 Baltimore CyberTrust 根 CA,但其中间 CA 将会更改。 单击此处了解详细信
息。
Azure 存储将继续使用 Baltimore CyberTrust 根 CA,但其中间 CA 将会更改。 单击此处了解详细信息。
Azure Cache for Redis 将继续使用 Baltimore CyberTrust 根 CA,但其中间 CA 将会更改。 单击此处了解详细
信息。
Azure 实例元数据服务将继续使用 Baltimore CyberTrust 根 CA,但其中间 CA 将会更改。 单击此处了解详细
信息。

IMPORTANT
进行此更改之后,客户可能需要更新其应用程序,以防止在尝试连接到 Azure 服务时出现连接故障。

有什么变化?
如今,Azure 服务使用的大多数 TLS 证书都链接到以下根 CA:

CA ( SH A 1)

Baltimore CyberTrust 根 d4de20d05e66fc53fe1a50882c78db2852cae474

Azure 服务使用的 TLS 证书都链接到以下根 CA 之一:

CA ( SH A 1)

DigiCert 全局根 G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

DigiCert 全局根 CA a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436

Baltimore CyberTrust 根 d4de20d05e66fc53fe1a50882c78db2852cae474

D-TRUST 根类 3 CA 2 2009 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0

Microsoft RSA 根证书颁发机构 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74

Microsoft ECC 根证书颁发机构 2017 999a64c37ff47d9fab95f14769891460eec4c3c5


何时可以停用旧的中间指纹?
在 2021 年 2 月 15 日 之前,不会撤销当前 CA 证书。 在该日期后,可以从代码中删除旧指纹。

如果此日期发生更改,则会收到新的吊销日期通知。

此更改将对我产生影响吗?
我们预计 大多数 Azure 客 户 不会 受到影响。 但是,如果应用程序显式指定可接受 CA 的列表,则可能会受到影
响。 这种做法称为证书固定。

下面是检测应用程序是否受影响的一些方式:

在源代码中搜索在此处找到的任何 Microsoft IT TLS CAs 的指纹、公用名和其他证书属性。 如果存在匹


配,则应用程序会受到影响。 若要解决此问题,请更新源代码,包括新的 CA。 最佳做法是确保在简短通知
时可添加或编辑 CA。 行业法规要求在 7 天内替换 CA 证书,因此依赖于固定的客户需要迅速做出反应。

如果你的应用程序与 Azure API 或其他 Azure 务集成,并且你不确定它是否使用证书固定,请向应用程序


供应商核实。

与 Azure 服务进行通信的不同操作系统和语言运行时可能需要额外步骤,才能正确利用这些新的根来构
建证书链:

Linux:许多发行版要求将 CA 添加到 /etc/ssl/certs。 有关特定说明,请查看发行版的相应文档。


Java :确保 Java 密钥存储包含上面列出的 CA。
在断开连接的环境中运行的 Windows:在断开连接的环境中运行的系统需要将新根添加到受信任的根
证书颁发机构存储,并将中间证书添加到中间证书颁发机构存储。
Android:查看适用于你设备和 Android 版本的文档。
其他硬件设备(尤其是 IoT):联系设备制造商。
如果环境中的防火墙规则设置为仅允许对特定证书吊销列表 (CRL) 下载和/或在线证书状态协议 (OCSP)
验证位置进行出站呼叫。 需要允许以下 CRL 和 OCSP URL :

http://crl3.digicert.com
http://crl4.digicert.com
http://ocsp.digicert.com
http://www.d-trust.net
http://root-c3-ca2-2009.ocsp.d-trust.net
http://crl.microsoft.com
http://oneocsp.microsoft.com
http://ocsp.msocsp.com
http://www.microsoft.com/pkiops

后续步骤
如果有其他问题,请通过支持联系我们。
Azure 数据安全与加密最佳做法
2021/2/9 • • Edit Online

本文介绍了针对数据安全和加密的最佳做法。

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


反映这些更改。

保护数据
为了帮助保护云中的数据,需要考虑数据可能出现的状态以及可用于该状态的控件。 Azure 数据安全与加密的最
佳做法与以下数据状态相关:

静态:包括物理媒体(磁盘或光盘)上以静态方式存在的所有信息存储对象、容器和类型。
传输中:在各组件、位置或程序间传输数据时,数据处于“传输中”状态。 例如通过网络、通过服务总线(从本地
到云,反之亦然,包括诸如 ExpressRoute 的混合连接)进行传输,或在输入/输出过程。

选择密钥管理解决方案
保护密钥对保护云中的数据至关重要。

Azure Key Vault 可帮助保护云应用程序和服务使用的加密密钥和机密。 密钥保管库简化了密钥管理过程,可让


你控制用于访问和加密数据的密钥。 开发人员可以在几分钟内创建用于开发和测试的密钥,然后将其迁移到生
产密钥。 安全管理员可以根据需要授予(和吊销)密钥权限。

可以使用 Key Vault 创建多个安全容器(称为保管库)。 这些保管库受 HSM 支持。 保管库可以集中存储应用程序


机密,降低安全信息意外丢失的可能性。 Key vault 还控制并记录外界对其所存储内容的访问。 Azure Key Vault
负责处理传输层安全性 (TLS) 证书的请求和续订事宜。 它为可靠的证书生命周期管理解决方案提供相关功能。

Azure Key Vault 旨在支持应用程序密钥和机密。 Key Vault 不应用于存储用户密码。


以下是使用 Key Vaul 的安全最佳做法。

最佳做法 :向特定范围内的用户、组和应用程序授予访问权限。
详细 信息 :使用 Azure RBAC 预定义角色。 例如,要向用户授予管理密钥保管库的访问权限,需要将预定义的角
色密钥保管库参与者分配给位于特定范围内的此用户。 在此情况下,该范围可以是订阅、资源组,或只是特定的
密钥保管库。 如果预定义角色不符合需求,可以定义自己的角色。

最佳做法 :控制用户有权访问的内容。
详细 信息 :可通过以下两个独立接口来控制对密钥保管库的访问:管理平面和数据平面。 管理平面访问控制与数
据平面访问控制相互独立。

使用 Azure RBAC 控制用户有权访问的内容。 例如,如果想要授予应用程序使用密钥保管库中的密钥的访问权


限,只需使用密钥保管库访问策略授予数据平面访问权限,而无需授予此应用程序的管理平面访问权限。 相反,
如果希望用户能够读取保管库属性和标记,但不让其具有任何访问密钥、机密或证书的权限,则可以使用 Azure
RBAC 向此用户授予“读取”访问权限,而无需授予数据平面访问权限。
最佳做法 :将证书存储在 Key Vault 中。 证书的价值很高。 如果落入他人之手,应用程序或数据的安全性可能会
受到损害。
详细 信息 :Azure 资源管理器可以在部署 VM 时,将存储在 Azure Key Vault 中的证书安全地部署到 Azure VM。
通过为密钥保管库设置适当的访问策略,还可以控制有权访问证书的人员。 另一个好处是,可以在 Azure Key
Vault 中的一个位置管理所有证书。 有关详细信息,请参阅将证书从客户托管的 Key Vault 部署到 VM。
最佳做法 :确保可以恢复删除的 Key Vault 或 Key Vault 对象。
详细 信息 :删除 Key Vault 或 Key Vault 对象可以是无意或恶意的。 启用 Key Vault 的软删除和清除保护功能,尤
其是对用于加密静态数据的密钥。 删除这些密钥相当于丢失数据,因此可以在需要时恢复已删除的保管库和保
管库对象。 定期练习 Key Vault 恢复操作。

NOTE
如果用户具有密钥保管库管理平面的参与者权限 (Azure RBAC),则该用户可以通过设置密钥保管库访问策略来授予自己对
数据平面的访问权限。 建议严格控制具有密钥保管库“参与者”权限的人员,以确保只有获得授权的人员可以访问和管理密
钥保管库、密钥、机密和证书。

使用安全工作站进行管理

NOTE
订阅管理员或所有者应使用安全访问工作站或特权访问工作站。

因为绝大多数的攻击以最终用户为目标,所以终结点将成为主要攻击点之一。 入侵终结点的攻击者可以使用用
户的凭据来访问组织的数据。 大多数终结点攻击都利用了用户是其本地工作站的管理员这一事实。

最佳做法 :使用安全管理工作站来保护敏感帐户、任务和数据。
详细 信息 :使用 特权访问工作站来减小工作站的受攻击面。 这些安全管理工作站可帮助减轻其中一些攻击,以
确保数据更为安全。

最佳做法 :确保终结点受保护。
详细 信息 :在用于使用数据的所有设备上强制实施安全策略(无论数据位于云中还是本地)。

保护静止的数据
静态数据加密是实现数据隐私性、符合性和数据主权的必要措施。

最佳做法 :使用磁盘加密来帮助保护数据。
详细 信息 :使用 Azure 磁盘加密。 它使 IT 管理员能够加密 Windows 和 Linux IaaS VM 磁盘。 磁盘加密利用符合
行业标准的 Windows BitLocker 功能和 Linux dm-crypt 功能为 OS 和数据磁盘提供卷加密。

Azure 存储和 Azure SQL 数据库默认对静态数据进行加密,并且许多服务都将加密作为选项提供。 可以使用


Azure Key Vault 来持续控制用于访问和加密数据的密钥。 有关详细信息,请参阅 Azure 资源提供程序加密模型
支持。

最佳做法 :使用加密来帮助降低与未经授权访问数据相关的风险。
详细 信息 :在将敏感数据写入驱动器之前先将驱动器加密。

未实施数据加密的组织面临的数据保密性问题风险更大。 例如,未经授权的用户或恶意用户可能会窃取已入侵
帐户中的数据,或者未经授权访问以明文格式编码的数据。 公司还必须证明,为了遵守行业法规,他们在不断作
出相应努力并使用正确的安全控件来增强其数据安全性。

保护传输中的数据
保护传输中的数据应该是数据保护策略中不可或缺的部分。 由于数据在许多位置间来回移动,因此,通常建议始
终使用 SSL/TLS 协议在不同位置间交换数据。 在某些情况下,可以使用 VPN 隔离本地与云基础结构之间的整个
信道。

对于在本地基础结构与 Azure 之间移动的数据,请考虑适当的防护措施,例如 HTTPS 或 VPN。 通过公共 Internet


在 Azure 虚拟网络和本地位置之间发送加密流量时,请使用 Azure VPN 网关。

以下是特定于使用 Azure VPN 网关、SSL/TLS 和 HTTPS 的最佳做法。


最佳做法 :从位于本地的多个工作站安全访问 Azure 虚拟网络。
详细 信息 :使用 站点到站点 VPN。

最佳做法 :从位于本地的单个工作站安全访问 Azure 虚拟网络。


详细 信息 :使用 点到站点 VPN。

最佳做法 :通过专用高速 WAN 链路移动大型数据集。


详细 信息 :使用 ExpressRoute。 如果选择使用 ExpressRoute,则还可以使用 SSL/TLS 或其他协议在应用程序级别
加密数据,以提供额外的保护。

最佳做法 :通过 Azure 门户与 Azure 存储交互。


详细 信息 :所有事务都通过 HTTPS 进行。 也可通过 HTTPS 使用存储 REST API 与 Azure 存储进行交互。

无法保护传输中数据的组织更容易遭受中间人攻击、窃听和会话劫持。 这些攻击可能是获取机密数据访问权限
的第一步。

保护电子邮件、文档和敏感数据
你希望控制并帮助保护在公司外部共享的电子邮件、文档和敏感数据。 Azure 信息保护是基于云的解决方案,可
帮助组织对其文档和电子邮件进行分类、标记和保护。 这可以由定义了规则和条件的管理员自动执行、由用户手
动执行,或者以组合方式执行,在组合方式中,用户可获得建议。

分类始终是可标识的,而无论数据的存储位置或数据的共享人员。 标签包括视觉标记,如页眉、页脚或水印。 元
数据以明文形式添加到文件和电子邮件标题中。 明文形式确保其他服务(如防止数据丢失的解决方案)可以识别
分类并采取相应的操作。

保护技术使用 Azure Rights Management (Azure RMS)。 此技术与其他 Microsoft 云服务和应用程序(如


Microsoft 365 和 Azure Active Directory)相集成。 此保护技术使用加密、标识和授权策略。 通过 Azure RMS 应
用的保护与文档和电子邮件保留在一起,不受位置影响,也无论是在组织、网络、文件服务器和应用程序内部还
是外部。

此信息保护解决方案可用于控制数据,即使是与他人共享的数据,也可控制。 还可以将 Azure RMS 用于自己的


业务线应用程序和软件供应商提供的信息保护解决方案,而无论这些应用程序和解决方案是在本地还是在云中。

建议:

为组织部署 Azure 信息保护。


应用可反映业务需求的标签。 例如:将名为“高度机密”的标签应用于包含绝密数据的所有文档和电子邮件,以
对这些数据进行分类和保护。 然后,只有授权的用户才能访问此数据,并具有指定的任何限制。
配置 Azure RMS 的使用情况日志记录,以便监视组织使用保护服务的方式。

数据分类和文件保护能力不佳的组织可能更容易遭到数据泄漏或数据滥用。 使用适当的文件保护,可以分析数
据流,以深入了解业务、检测风险行为并采取纠正措施、跟踪对文档的访问等等。

后续步骤
有关通过 Azure 设计、部署和管理云解决方案时可以使用的更多安全最佳做法,请参阅 Azure 安全最佳做法和模
式。

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

Azure 安全团队博客 - 随时掌握 Azure 安全性的最新信息


Microsoft 安全响应中心 - 可在其中报告 Microsoft 安全漏洞(包括 Azure 问题)或将其通过电子邮件发送到
secure@microsoft.com
Azure 静态数据加密
2021/2/9 • • Edit Online

Microsoft Azure 提供了许多工具,可以使用它们根据你公司的安全性和合规性需求来保护数据。 本白皮书重点


介绍:

如何在 Microsoft Azure 上对数据进行静态保护


讨论参与数据保护实现的各个组件
查看不同密钥管理保护方法的优点和缺点。

静态加密是常见的安全要求。 在 Azure 中,组织可以加密静态数据,而不会造成自定义密钥管理解决方案的风险


或成本。 组织可以选择让 Azure 来全权管理静态加密。 另外,组织还可以通过各种选择来严格管理加密或加密
密钥。

什么是静态加密?
加密是用于保护数据机密性的数据的安全编码。 Azure 中的静态加密设计使用对称加密根据简单的概念模型来
快速加密和解密大量数据:

将使用对称加密密钥在将数据写入到存储时对数据进行加密。
当数据在内存中就绪可供使用时,将会使用同一加密密钥来解密该数据。
可以将数据分区,并可对每个分区使用不同的密钥。
必须将密钥存储在实施了基于标识的访问控制和审核策略的安全位置。 数据加密密钥通常由 Azure Key Vault
中的密钥加密密钥进行加密,以进一步限制访问。

在实践中,密钥管理和控制方案以及规模和可用性保证都需要其他构造。 下面描述的是 Microsoft Azure 静态加


密概念和组件。

静态加密的目的
静态加密为已存储的数据(静止的)提供数据保护。 对静态数据进行的攻击包括:试图获得存储数据的硬件的物理
访问机会,然后盗用其中包含的数据。 发生此类攻击可能是由于服务器的硬盘驱动器在维护过程中处理不当,导
致攻击者有机会拆除硬盘驱动器。 攻击者随后会将该硬盘驱动器置于受其控制的计算机中,尝试访问相关数据。

静态加密旨在防止攻击者访问未加密的数据,其方法是确保这些数据在磁盘上时是加密的。 如果攻击者获取了
包含加密数据的硬盘驱动器但未获取加密密钥,则攻击者必须破解加密才能读取数据。 这种攻击比访问硬盘驱
动器上的未加密数据要复杂得多,且消耗的资源也多得多。 因此,强烈建议使用静态加密。对于许多组织来说,
这是需要完成的高优先级事项。

当组织需要进行数据治理并确保符合性时,可能也需要使用静态加密。 行业和政府法规(例如 HIPAA、PCI 和


FedRAMP)就数据保护和加密要求制定了具体的保障措施。 要符合这其中的许多法规,静态加密是一种必需的强
制措施。 有关 Microsoft 的 FIPS 140-2 验证方法的详细信息,请参阅美国联邦信息处理标准 (FIPS) 出版物 140-
2。
除了满足合规要求以外,静态加密还能提供深层防御保护。 Microsoft Azure 为服务、应用程序和数据提供合规的
平台。 此外,它还提供综合性的设施和物理安全性、数据访问控制和审核。 但是,必须提供额外的“重叠性”安全
措施,以免出现其他某个安全措施失效的情况,而静态加密正好提供这样一道安全措施。

Microsoft 致力于提供跨云服务的静态加密选项,可让客户控制加密密钥和密钥使用日志。 另外,Microsoft 正在


努力实现默认加密所有客户静态数据。
Azure 静态加密组件
如前所述,静态加密的目标是使用机密加密密钥来加密持久保存在磁盘上的数据。 若要实现该目标,必须为加密
密钥提供安全的密钥创建、存储、访问控制和管理措施。 可以使用下图中介绍的术语来描述 Azure 服务静态加密
实现,虽然细节可能有所不同。

Azure Key Vault


对于静态加密模型来说,最重要的是加密密钥的存储位置以及对这些密钥的访问控制。 密钥需要严格的保护,但
同时又要能够由指定的用户进行管理,并可供特定的服务使用。 对于 Azure 服务,建议使用 Azure Key Vault 作
为密钥存储解决方案,它可以跨服务提供通常的管理体验。 密钥在密钥保管库中存储和管理,对密钥保管库的访
问权限可以提供给用户或服务。 Azure Key Vault 支持客户创建密钥,也支持将导入的客户密钥用于客户管理的
加密密钥方案。

Azure Active Directory


可以为 Azure Active Directory 帐户提供存储在 Azure Key Vault 中的密钥的使用权限,以便通过管理或访问这些
密钥来完成静态加密的加密和解密操作。

密 钥层 次 结 构
在实施静态加密时,使用多个加密密钥。 将加密密钥存储在 Azure Key Vault 中可确保安全的密钥访问并可集中
管理密钥。 但是,就批量加密和解密来说,通过服务在本地访问加密密钥比每项数据操作都要与 Key Vault 交互
更为高效,可以提高加密强度和性能。 限制单个加密密钥的使用降低了密钥被盗用的风险,也降低了必须更换密
钥时的重新加密成本。 Azure 静态加密模块使用一个密钥层次结构来解决所有这些需求,该密钥层次结构由以下
类型的密钥构成:

(DEK) 的数据加密密 钥 –用于对分区或数据块进行加密的对称 AES256 密钥。 单个资源可能有多个分区和多


个数据加密密钥。 使用不同的密钥加密每个数据块可以增加加密分析攻击的难度。 资源提供程序或应用程序
实例需要 DEK 访问权限才能加密和解密特定的块。 将 DEK 替换为新密钥时,仅其关联的块中的数据需要使
用新密钥重新加密。
密 钥 加密密 钥(KEK) –用于对数据加密密钥进行加密的加密密钥。 使用从不离开 Key Vault 的密钥加密密钥
可以加密和控制数据加密密钥本身。 具有 KEK 访问权限的实体可能不同于需要 DEK 的实体。 实体可能会代
理对 DEK 的访问以将每个 DEK 的访问限制到特定分区。 由于解密 DEK 需要 KEK,因此 KEK 实际上构成了一
个单点机制:删除 KEK 即可删除 DEK。

使用密钥加密密钥加密的数据加密密钥将单独进行存储,只有能够访问密钥加密密钥的实体才能解密这些数据
加密密钥。 支持各种不同的密钥存储模型。 有关详细信息,请参阅数据加密模型。

Microsoft 云服务中的静态加密
Microsoft 云服务用于下述所有三个云模型:IaaS 、PaaS 、SaaS 。 下面是在每个模型上使用该服务的示例:
软件服务,也称软件即服务(简称 SaaS ),它包含云提供的应用程序,例如 Microsoft 365 。
平台服务,方便客户在其应用程序中利用云,将云用于存储、分析和服务总线功能等。
基础结构服务,也称基础结构即服务 (IaaS),方便客户部署托管在云中的操作系统和应用程序,并尽可能利用
其他云服务。

适合SaaS 客 户 的静 态 加密
软件即服务 (SaaS) 客户通常会在每个服务中启用或提供静态加密。 Microsoft 365 为客户提供多个选项来验证
或启用静态加密。 若要了解 Microsoft 365 服务,请参阅 Microsoft 365 中的加密。

适合PaaS 客 户 的静 态 加密
平台即服务 (PaaS) 客户的数据通常驻留在存储服务(例如 Blob 存储)中,但也可以缓存或存储在应用程序执行环
境(例如虚拟机)中。 若要查看适用的静态加密选项,请检查下表中是否存在所用的存储和应用程序平台。

适合 IaaS 客 户 的静 态 加密
基础结构即服务 (IaaS) 客户可以使用各种服务和应用程序。 IaaS 服务可以在其 Azure 托管的虚拟机和 VHD 中通
过 Azure 磁盘加密来启用静态加密。

加密的存 储

与 PaaS 一样,IaaS 解决方案可以利用其他存储静态加密数据的 Azure 服务。 在此类情况下,可以启用每个所用


Azure 服务提供的静态加密支持。 下表枚举了主要的存储、服务和应用程序平台以及所支持的静态加密模型。
加密的 计 算

所有托管磁盘、快照和映像都通过服务管理的密钥使用存储服务加密进行加密。 更完整的静态加密解决方案可
确保数据从不以未加密形式持久保存。 在虚拟机上处理数据时,可以将数据持久保存到 Windows 页面文件或
Linux 交换文件、故障转储或应用程序日志。 为了确保对该数据进行静态加密,IaaS 应用程序可以在 Azure IaaS
虚拟机(Windows 或 Linux)和虚拟磁盘上使用 Azure 磁盘加密。

自定 义 静 态 加密

建议让 IaaS 应用程序尽可能利用 Azure 磁盘加密以及任何所用 Azure 服务提供的静态加密选项。 在某些情况下


(例如加密要求异乎寻常,或者存储不是基于 Azure 的),IaaS 应用程序开发人员可能需要自行实施静态加密。
IaaS 解决方案开发人员可以利用某些 Azure 组件,改进与 Azure 管理的集成并更好地满足客户期望。 具体说来,
开发人员应该使用 Azure Key Vault 服务为其客户提供安全的密钥存储,以及提供与大多数 Azure 平台服务一致
的密钥管理选项。 另外,自定义解决方案应通过 Azure 托管服务标识来允许服务帐户访问加密密钥。 有关 Azure
Key Vault 和托管服务标识的开发人员信息,请参阅各自的 SDK。

Azure 资源提供程序加密模型支持
每个 Microsoft Azure 服务都支持一个或多个静态加密模型。 但是,对于某些服务来说,其中的一个或多个加密
模型可能并不适用。 对于支持客户管理的密钥方案的服务,它们可能只支持 Azure Key Vault 支持用于密钥加密
密钥的密钥类型的一个子集。 另外,服务可能会按不同的计划发布对这些方案和密钥类型的支持。 此部分介绍
的静态加密支持在撰写本文时仍适用于每个主要的 Azure 数据存储服务。

Azure 磁 盘 加密
任何使用 Azure 基础结构即服务 (IaaS) 功能的客户都可以通过 Azure 磁盘加密为其 IaaS VM 和磁盘实施静态加
密。 有关 Azure 磁盘加密的详细信息,请参阅 Azure 磁盘加密文档。

Azure 存 储
所有 Azure 存储服务(Blob 存储、队列存储、表存储和 Azure 文件存储)均支持静态服务器端加密,其中某些服务
额外支持客户管理的密钥和客户端加密。

服务器端:默认情况下,所有 Azure 存储服务都使用服务托管的密钥来启用服务器端加密(对应用程序而言是


透明的)。 有关详细信息,请参阅静态数据的 Azure 存储服务加密。 Azure Blob 存储和 Azure 文件也支持
Azure Key Vault 中客户托管的 RSA 2048 位密钥。 有关详细信息,请参阅 Azure Key Vault 中使用客户托管密
钥的存储服务加密。
客户端:Azure Blob、表和队列支持客户端加密。 使用客户端加密时,客户会加密数据并将数据作为加密的
blob 上传。 密钥管理由客户执行。 有关详细信息,请参阅 Microsoft Azure 存储的客户端加密和 Azure Key
Vault。
Azure SQL 数据 库
Azure SQL 数据库目前支持将静态加密用于 Microsoft 托管的服务器端和客户端加密方案。
对服务器加密的支持目前通过名为“透明数据加密”的 SQL 功能来提供。 在 Azure SQL 数据库客户启用 TDE 后,
系统会自动为其创建和管理密钥。 可以在数据库和服务器级别启用静态加密。 从 2017 年 6 月开始,会在新创建
的数据库上默认启用透明数据加密 (TDE)。 Azure SQL 数据库支持 Azure Key Vault 中客户管理的 RSA 2048 位密
钥。 有关详细信息,请参阅使用 Azure SQL 数据库和数据仓库的“创建自己的密钥”支持进行透明数据加密。

可以通过 Always Encrypted 功能启用对 Azure SQL 数据库数据的客户端加密。 Always Encrypted 使用由客户端
创建和存储的密钥。 客户可以将主密钥存储在 Windows 证书存储、Azure Key Vault 或本地硬件安全模块中。 使
用 SQL Server Management Studio 时,SQL 用户可以选择想要使用什么密钥来加密哪个列。

结论
保护存储在 Azure 服务中的客户数据对于 Microsoft 来说至关重要。 所有 Azure 托管服务都会始终提供静态加
密选项。 Azure 服务支持服务管理的密钥、客户管理的密钥或客户端加密。 Azure 服务正在大范围地增强静态加
密的可用性,计划在将来数月中推出新功能的预览版和公开发行版。

后续步骤
若要详细了解服务管理的密钥和客户管理的密钥,请参阅数据加密模型。
了解 Azure 如何使用双重加密来缓解加密数据所带来的威胁。
了解 Microsoft 如何确保主机遍历硬件和固件构建、集成、操作化和维修管道的 完整性和安全性 。
数据加密模型
2021/2/9 • • Edit Online

了解各种加密模型及其优缺点很重要,有助于了解 Azure 中的各个资源提供程序是如何实施静态加密的。 这些


定义在 Azure 的所有资源提供程序中是共享的,目的是确保共同的语言和分类。

服务器端加密有三种方案:

使用服务托管密钥进行服务器端加密

Azure 资源提供程序执行加密和解密操作
Microsoft 管理密钥
完整云功能
使用 Azure Key Vault 中客户托管密钥的服务器端加密

Azure 资源提供程序执行加密和解密操作
客户通过 Azure Key Vault 控制密钥
完整云功能
使用客户所控制硬件上的客户托管密钥的服务器端加密

Azure 资源提供程序执行加密和解密操作
客户控制其所控制的硬件上的密钥
完整云功能

服务器端加密模型是指由 Azure 服务执行的加密。 在该模型中,资源提供程序执行加密和解密操作。 例


如,Azure 存储可能会以纯文本操作方式接收数据,并且会在内部进行加密和解密。 资源提供程序可能使用由
Microsoft 或客户管理的加密密钥,具体取决于提供的配置。

每个服务器端静态加密模型都暗含密钥管理的独特特征。 其中包括:加密密钥的创建和存储位置和方式,以及访
问模型和密钥轮换过程。

对于客户端加密,请注意以下事项:

Azure 服务无法看到已解密的数据
客户在本地(或其他安全存储中)管理和存储密钥。 Azure 服务无法使用密钥
精简云功能

Azure 中支持的加密模型分为两大类:“客户端加密”和“服务器端加密”,如前所述。 Azure 服务始终建议使用独立


于所用静态加密模型的安全传输(例如 TLS 或 HTTPS )。 因此,传输过程中的加密应由传输协议来处理,不应成为
决定要使用的静态加密模型的主要因素。
客户端加密模型
客户端加密模型是指由服务或调用应用程序在资源提供程序或 Azure 外部执行的加密。 加密可以由 Azure 中的
服务应用程序执行,也可以由在客户数据中心运行的应用程序执行。 不管哪种情况,在采用此加密模型
时,Azure 资源提供程序都会收到加密的数据 blob,但却无法以任何方式解密数据,也无法访问加密密钥。 在此
模型中,密钥管理由调用服务/应用程序执行,对 Azure 服务来说是不透明的。

使用服务托管密钥的服务器端加密
对许多客户来说,基本要求就是确保数据在静态时能够获得加密。 使用服务托管密钥的服务器端加密实现该模
型的方式是:让客户标出适用于加密的特定资源(存储帐户、SQL DB 等),将所有密钥管理事项(例如密钥的颁
发、轮换和备份)留给 Microsoft。 大多数支持静态加密的 Azure 服务通常支持这种将加密密钥管理任务留给
Azure 的模型。 Azure 资源提供程序创建密钥,将其置于安全的存储中,然后根据需要对其进行检索。 这意味着,
服务具有密钥的完全访问权限,且服务可以全权控制凭据生命周期管理。

因此,使用服务托管密钥的服务器端加密可以快速满足进行静态加密并降低客户开销的需求。 在可用的情况下,
客户通常会打开适用于目标订阅和资源提供程序的 Azure 门户,选中一个表明其希望数据加密的复选框。 在某
些资源管理器中,使用服务托管密钥的服务器端加密默认处于启用状态。

使用 Microsoft 托管密钥的服务器端加密意味着服务对存储具有完全访问权限,并且可以管理密钥。 某些客户可


能希望对密钥进行管理,因为他们觉得自己可以获得更高的安全性,但在评估此模型时,应该考虑与自定义密钥
存储解决方案相关联的成本和风险。 在许多情况下,组织可能觉得本地解决方案的资源约束或风险会大于对静
态加密密钥进行云管理的风险。 但是,此模型可能满足不了某些组织的需求,这些组织需要控制加密密钥的创建
或生命周期,或者需要安排某个人来管理服务,安排另一个人来管理该服务的加密密钥(也就是说,这是一种将
密钥管理与总体管理分开的服务管理模型)。

密 钥访问权 限
使用服务托管密钥的服务器端加密在使用时,密钥的创建、存储和服务访问均由服务管理。 通常情况下,基础
Azure 资源提供程序会将数据加密密钥存储在靠近数据且能快速使用和访问的存储中,而将密钥加密密钥存储在
安全的内部存储中。

优点

安装简单
Microsoft 管理密钥轮换、备份和冗余
客户没有与实施相关联的成本,也没有自定义密钥管理方案的风险。

缺点

客户无法控制加密密钥(密钥规范、生命周期、吊销等)
此服务的管理模型无法将密钥管理与总体管理分开

使用 Azure Key Vault 中客户托管密钥的服务器端加密


对于需要加密静态数据并控制加密密钥的情况,客户可以选择使用 Key Vault 中客户托管密钥的服务器端加密。
某些服务可能仅将根密钥加密密钥存储在 Azure Key Vault 中,而将加密的数据加密密钥存储在更靠近数据的内
部位置。 在这种情况下,客户可以将自己的密钥带到 Key Vault 中(BYOK – 自带密钥),或者生成新的密钥,以便
加密所需资源。 资源提供程序在执行加密和解密操作时,会将所配置的密钥加密密钥用作所有加密操作的根密
钥。

密钥加密密钥丢失意味着数据丢失。 因此,不应删除密钥。 每次创建或轮换时都应备份密钥。 应在存储着密钥


加密密钥的任何保管库上启用软删除。 不应删除密钥,而应将“启用”设置为 false 或设置到期日期。

密 钥访问权 限
将客户托管密钥置于 Azure Key Vault 中的服务器端加密模型涉及到的操作是,服务会根据需要访问用于加密和
解密的密钥。 可以通过访问控制策略来允许服务访问静态加密密钥。 此策略授予服务标识接收密钥所需的访问
权限。 可以为代表关联的订阅运行的 Azure 服务配置一个该订阅中的标识。 该服务可以执行 Azure Active
Directory 身份验证,然后会收到一个身份验证令牌,将服务本身标识为代表该订阅的服务。 然后,该服务可以将
该令牌出示给 Key Vault,以便获取有权访问的密钥。

对于使用加密密钥的操作,可以为服务标识授予以下任何操作的访问权限:decrypt、encrypt、unwrapKey、
wrapKey、verify、sign、get、list、update、create、import、delete、backup、restore。
若要获取用于加密或解密静态数据的密钥,服务标识(将由资源管理器服务实例在运行时充当)必须使用
UnwrapKey 来获取解密用的密钥,并在创建新密钥时使用 WrapKey 将密钥插入密钥保管库中。

NOTE
有关 Key Vault 授权的更多详细信息,请参阅 Azure Key Vault 文档中的“保护密钥保管库”页。

优点

完全控制使用的密钥–加密密钥在客户的 Key Vault 下由客户控制。


能够通过加密将多个服务转换成一个主服务
此服务的管理模型可以将密钥管理与总体管理分开
可以跨区域定义服务和密钥位置

缺点

客户全权负责密钥访问管理
客户全权负责密钥生命周期管理
额外的安装和配置开销

使用客户所控制硬件中的客户管理的密钥进行服务器端加密
某些 Azure 服务启用了“托管自己的密钥 (HYOK)”密钥管理模型。 当需要对静止的数据进行加密并在不受
Microsoft 控制的专有存储库中管理密钥时,此管理模式非常有用。 在此模型中,服务必须从外部站点检索密钥。
性能和可用性担保会受影响,并且配置更复杂。 另外,由于服务可以在加密和解密操作过程中访问 DEK,此模型
的总体安全保证类似于密钥在 Azure Key Vault 中由客户托管的情况。 因此,此模型不适合大多数组织,除非该组
织有特定的密钥管理要求。 由于这些限制,大多数 Azure 服务不支持使用客户所控硬件中服务器管理的密钥进
行服务器端加密。

密 钥访问权 限
使用客户所控硬件中服务管理的密钥进行服务器端加密时,密钥保留在客户配置的系统上。 支持此模型的 Azure
服务提供了一种建立安全连接的方法,用于连接到客户提供的密钥存储。

优点

全权控制所用的根密钥 – 加密密钥由客户提供的存储托管
能够通过加密将多个服务转换成一个主服务
此服务的管理模型可以将密钥管理与总体管理分开
可以跨区域定义服务和密钥位置

缺点

全权负责密钥的存储、安全、性能和可用性
全权负责密钥访问管理
全权负责密钥生命周期管理
极高的安装、配置和持续维护成本
增强了对客户数据中心和 Azure 数据中心之间网络可用性的依赖。

支持服务
支持每个加密模型的 Azure 服务:

AI

Azure 认知搜索 是 是 -

Azure 认知服务 是 是 -

Azure 机器学习 是 是 -

Azure 机器学习工作室(经 是 预览,RSA 2048 位 -


典)
内容审查器 是 是 -

人脸 是 是 -

语言理解 是 是 -

个性化体验创建服务 是 是 -

QnA Maker 是 是 -

语音服务 是 是 -

文本翻译 是 是 -

Power BI 是 是,RSA 4096 位 -

Azure 流分析 是 是** -

事件中心 是 是 -

函数 是 是 -

Azure Analysis Services 是 - -

Azure 数据目录 是 - -

Azure HDInsight 是 全部 -

Azure Monitor Application 是 是 -


Insights

Azure Monitor Log 是 是 -


Analytics

Azure 数据资源管理器 是 是 -

Azure 数据工厂 是 是 -

Azure Data Lake Store 是 是,RSA 2048 位 -

Azure Kubernetes 服务 是 是 -

容器实例 是 是 -

容器注册表 是 是 -
虚拟机 是 是 -

虚拟机规模集 是 是 -

SAP HANA 是 是 -

应用服务 是 是** -

自动化 是 是** -

Azure Functions 是 是** -

Azure 门户 是 是** -

逻辑应用 是 是 -

Azure 托管应用程序 是 是** -

服务总线 是 是 -

站点恢复 是 是 -

虚拟机上的 SQL Server 是 是 是

Azure SQL 数据库 是 是,RSA 3072 位 是

Azure SQL Database for 是 - -


MariaDB

Azure SQL Database for 是 是 -


MySQL

Azure SQL Database for 是 是 -


PostgreSQL

Azure Synapse Analytics 是 是,RSA 3072 位 -

SQL Server Stretch 是 是,RSA 3072 位 是


Database

表存储 是 是 是

Azure Cosmos DB 是 是 -

Azure Databricks 是 是 -

Azure 数据库迁移服务 是 暂无* -


DevOps

Azure DevOps Services 是 - 是

Azure Repos 是 - 是

Azure Active Directory 是 - -

Azure Active Directory 域服 是 是 -


服务总线 是 是 是

事件网格 是 - -

API 管理 是 - -

IoT 服务

IoT 中心 是 是 是

IoT 中心设备预配 是 是 -

Azure Site Recovery 是 - -

Azure Migrate 是 是 -

媒体服务 是 是 是

适用于 IoT 的 Azure 安全中 是 是 -


Azure Sentinel 是 是 -

Blob 存储 是 是 是

高级 Blob 存储 是 是 是
磁盘存储 是 是 -

超级磁盘存储 是 是 -

托管磁盘存储 是 是 -

文件存储 是 是 -

文件高级存储 是 是 -

文件同步 是 是 -

队列存储 是 是 是

Avere vFXT 是 - -

用于 Redis 的 Azure 缓存 是 暂无* -

Azure NetApp 文件 是 是 -

存档存储 是 是 -

StorSimple 是 是 是

Azure 备份 是 是 是

Data Box 是 - 是

Data Box Edge 是 是 -

* 此服务不会持久保存数据。 将使用 Microsoft 密钥来加密暂时性缓存(如果有)。


** 此服务支持将数据存储在你自己的 Key Vault、存储帐户或其他已支持使用客户管理的密钥进行服务器端加密
的数据持久保存服务中。

后续步骤
了解如何在 Azure 中使用加密。
了解 Azure 如何使用双重加密来缓解加密数据所带来的威胁。
适⽤于虚拟机和虚拟机规模集的 Azure 磁盘加密
2021/2/9 • • Edit Online

Azure 磁盘加密可同时适用于 Linux 和 Windows 虚拟机以及虚拟机规模集。

Linux 虚拟机
以下文章提供了有关加密 Linux 虚拟机的指南。

Azure 磁 盘 加密的当前版本
Linux 虚拟机的 Azure 磁盘加密概述
Linux VM 上的 Azure 磁盘加密方案
使用 Azure CLI 创建和加密 Linux VM
使用 Azure Powershell 创建和加密 Linux VM
使用 Azure 门户创建和加密 Linux VM
适用于 Linux 的 Azure 磁盘加密扩展架构
创建和配置用于 Azure 磁盘加密的密钥保管库
Azure 磁盘加密示例脚本
Azure 磁盘加密疑难解答
Azure 磁盘加密常见问题解答
使用 Azure AD 执 行 Azure 磁 盘 加密(以前版本)
使用 Azure AD 对 Linux 虚拟机执行 Azure 磁盘加密概述
了解在 Linux VM 上使用 Azure AD 执行 Azure 磁盘加密的方案
使用 Azure AD 创建和配置用于 Azure 磁盘加密的密钥保管库(以前版本)

Windows 虚拟机
以下文章提供了有关加密 Windows 虚拟机的指南。

Azure 磁 盘 加密的当前版本
Windows 虚拟机的 Azure 磁盘加密概述
Windows VM 上的 Azure 磁盘加密方案
使用 Azure CLI 创建和加密 Windows VM
使用 Azure PowerShell 创建和加密 Windows VM
使用 Azure 门户创建和加密 Windows VM
适用于 Windows 的 Azure 磁盘加密扩展架构
创建和配置用于 Azure 磁盘加密的密钥保管库
Azure 磁盘加密示例脚本
Azure 磁盘加密疑难解答
Azure 磁盘加密常见问题解答
使用 Azure AD 执 行 Azure 磁 盘 加密(以前版本)
使用 Azure AD 对 Windows 虚拟机执行 Azure 磁盘加密概述
了解在 Windows VM 上使用 Azure AD 执行 Azure 磁盘加密的方案
使用 Azure AD 创建和配置用于 Azure 磁盘加密的密钥保管库(以前版本)
虚拟机规模集
以下文章提供了有关加密虚拟机规模集的指南。

适用于虚拟机规模集的 Azure 磁盘加密概述


使用 Azure CLI 加密虚拟机规模集
使用 Azure Powershell 加密虚拟机规模集。
使用 Azure 资源管理器加密虚拟机规模集
为 Azure 磁盘加密创建和配置密钥保管库
将 Azure 磁盘加密与虚拟机规模集扩展排序配合使用

后续步骤
Azure 加密概述
静态数据加密
数据安全与加密最佳做法
Azure SQL 数据库和 Azure SQL 托管实例安全功能
概述
2021/2/9 • • Edit Online

适用于: Azure SQL 数据库 Azure SQL 托管实例 Azure Synapse Analytics
本文概述使用 AZURE Sql 数据库、 azure Sql 托管实例和 azure Synapse Analytics保护应用程序数据层的基础知
识。 所述的安全策略遵循如下图所示的分层深度防御方法,并从外向内移动:

网络安全性
Microsoft Azure SQL 数据库、SQL 托管实例和 Azure Synapse Analytics 为云和企业应用程序提供关系数据库服
务。 为了帮助保护客户数据,防火墙会阻止对服务器的网络访问,直到根据 IP 地址或 Azure 虚拟网络流量源显
式授予访问权限。

IP 防火 墙规则
IP 防火墙规则基于每个请求的起始 IP 地址授予对数据库的访问权限。 有关详细信息,请参阅 Azure SQL 数据库
和 Azure Synapse Analytics 防火墙规则概述。

虚 拟 网 络 防火 墙规则
虚拟网络服务终结点将虚拟网络连接扩展到 Azure 主干网,并使 Azure SQL 数据库能够识别作为流量来源的虚
拟网络子网。 若要允许流量到达 Azure SQL 数据库,请使用 SQL 服务标记,以允许出站流量通过网络安全组。

虚拟网络规则使 Azure SQL 数据库仅接受从虚拟网络中的所选子网发送的通信。

NOTE
使用防火墙规则控制访问权限不应用于“SQL 托管实例”。 有关所需网络配置的详细信息,请参阅连接到托管实例

访问管理
IMPORTANT
管理 Azure 中的数据库和服务器由门户用户帐户的角色分配控制。 有关本文的详细信息,请参阅 Azure 门户中的 Azure 基
于角色的访问控制。

身份 验证
身份验证是证明用户所声明身份的过程。 Azure SQL 数据库和 SQL 托管实例支持两种类型的身份验证:

SQL 身份 验证 :

SQL 身份验证是指使用用户名和密码连接到 Azure SQL 数据库或 Azure SQL 托管实例时对用户进行的身


份验证。 在创建服务器时,需要指定含用户名和密码的“服务器管理员”登录名。 借助这些凭据,“服务器管
理员”可以使用数据库所有者的身份向服务器或实例上的任何数据库进行身份验证。 之后,服务器管理员
可以创建额外的 SQL 登录和用户,以允许用户使用用户名和密码进行连接。

Azure Active Director y 身份 验证 :

Azure Active Directory 身份验证是使用 Azure Active Directory (Azure AD) 中的标识连接到 Azure SQL 数
据库、Azure SQL 托管实例和 Azure Synapse Analytics 的一种机制。 使用 Azure AD 身份验证,管理员可
在一个中心位置集中管理数据库用户以及其他 Azure 服务的标识和权限。 这包括最小化密码存储并启用
集中式密码轮换策略。

必须创建一个名为“Active Directory 管理员”的服务器管理员,以便在 SQL 数据库中使用 Azure AD 身份验


证。 有关详细信息,请参阅使用 Azure Active Directory 身份验证连接到 SQL 数据库。 Azure AD 身份验证
同时支持托管帐户和联合帐户。 联合帐户支持与 Azure AD 联合的客户域的 Windows 用户和组。

其他可用的 Azure AD 身份验证选项包括适用于 SQL Server Management Studio 的 Active Directory 通用


身份验证连接,其中包括多重身份验证和条件访问。

IMPORTANT
管理 Azure 中的数据库和服务器由门户用户帐户的角色分配控制。 有关本文的详细信息,请参阅 Azure 中基于角色的访问
控制 Azure 门户。 使用防火墙规则控制访问权限不应用于“SQL 托管实例”。 有关所需网络配置的详细信息,请参阅以下有
关连接到托管实例的文章。

授权
授权是指在 Azure SQL 数据库的数据库或 Azure SQL 托管实例中分配给用户的权限,并决定用户可以执行的操
作。 权限控制通过将用户帐户添加到数据库角色并向这些角色分配数据库级权限来实现,也可以通过授予用户
特定的对象级权限来实现。 有关详细信息,请参阅登录和用户

最佳做法是根据需要创建自定义角色。 将用户添加到具有完成其作业功能所需的最低权限的角色中。 请勿直接


将权限分配给用户。 服务器管理员帐户是内置的 db_owner 角色的成员,该角色具有广泛权限,只应将其授予部
分具有管理职责的用户。 对于应用程序,请使用 EXECUTE AS 来指定被调用模块的执行上下文,或者使用权限受
限的应用程序角色。 此做法可确保连接到数据库的应用程序具有应用程序所需的最低权限。 按这些最佳做法操
作也有助于职责分离。

行 级别 安全性
行级别安全性使客户可以基于执行查询的用户的特性(例如,组成员身份或执行上下文)来控制对数据库表进行
的访问。 行级别安全性也可用于实现基于自定义标签的安全概念。 有关详细信息,请参阅行级别安全性。
威胁防护
SQL 数据库和 SQL 托管实例通过提供审核和威胁检测功能来保护客户数据。
Azure Monitor 日志和事件中心中的 SQL 审 核
SQL 数据库和 SQL 托管实例审核可跟踪数据库活动,通过将数据库事件记录到客户所有的 Azure 存储帐户中的
审核日志,帮助用户保持符合安全标准。 用户可以通过审核监视正在进行的数据库活动,以及分析和调查历史活
动,以标识潜在威胁或可疑的滥用行为和安全违规。 有关详细信息,请参阅 SQL 数据库审核入门。

高级威胁防护
高级威胁防护通过对你的日志进行分析来检测异常行为和对数据库的潜在恶意访问或利用。 针对可疑活动(例如
SQL注入、潜在的数据渗透和暴力攻击)或访问模式中的异常情况创建警报,以捕获特权提升和违规的凭据使用。
可以从 Azure 安全中心查看警报,其中提供了可疑活动的详细信息,并给出了进一步调查建议以及缓解威胁的措
施。 可以为每台服务器启用高级威胁防护,但需要额外付费。 有关详细信息,请参阅 SQL 数据库高级威胁防护
入门。

信息保护和加密
传输层 安全性( 传输 中加密)
SQL Database、SQL 托管实例和 Azure Synapse Analytics 通过使用 传输层安全性 (TLS) 对运动中的数据进行加
密来保护客户数据。

SQL Database、SQL 托管实例和 Azure Synapse Analytics 始终对所有连接强制执行加密 (SSL/TLS) 。 这样可以确


保在客户端与服务器之间传输的所有数据经过加密,而不管连接字符串中的 Encr ypt 或
TrustSer verCer tificate 设置如何。
作为最佳做法,建议在应用程序使用的连接字符串中指定加密的连接,而“不要”信任服务器证书。 这会强制应用
程序验证服务器证书,从而防止应用程序容易受到中间人类型的攻击。
例如,在使用 ADO.NET 驱动程序时,这是通过 Encr ypt=True 和 TrustSer verCer tificate=False 实现的。 如果
是从 Azure 门户中获取连接字符串,则它将具有正确的设置。

IMPORTANT
请注意,某些非 Microsoft 驱动程序默认可能不使用 TLS,或者依赖于旧版 TLS (<1.2) 来正常运行。 在这种情况下,服务器
仍允许连接到数据库。 但是,我们建议评估允许此类驱动程序和应用程序连接到 SQL 数据库所带来的安全风险,尤其是存
储敏感数据时。

有关 TLS 和连接的更多信息,请参阅 TLS 注意事项。

透明数据加密(静 态 加密)
透明数据加密 (适用于 Sql 数据库的 TDE) 、sql 托管实例和 Azure Synapse Analytics 增加了一层安全保护,以帮
助保护静态数据,防止未经授权或脱机访问原始文件或备份。 常见方案包括数据中心被盗或对硬件或媒体(如磁
盘驱动器和备份磁带)的不安全处置。TDE 使用 AES 加密算法加密整个数据库,无需应用程序开发人员对现有应
用程序进行任何更改。

在 Azure 中,所有新创建的数据库都默认处于加密状态,且数据库加密密钥通过一个内置的服务器证书保护。 证
书维护和轮换由服务管理,无需用户输入。 喜欢控制加密密钥的客户可以管理 Azure Key Vault 中的密钥。

使用Azure Key Vault 的密 钥 管理


创建自己的密钥 (BYOK) 支持透明数据加密 (TDE),允许客户使用 Azure Key Vault(Azure 基于云的外部密钥管理
系统)来获得密钥管理和轮换的所有权。 如果撤销了数据库对密钥保管库的访问权限,则无法解密数据库和将其
读入内存。 Azure Key Vault 提供集中密钥管理平台,利用严格监控的硬件安全模块 (HSM),并可在密钥与数据管
理之间实现职责分离,以帮助满足安全合规性要求。

Always Encrypted(使用中加密)

Always Encrypted 功能旨在保护特定数据库列中存储的敏感数据不被访问(如信用卡号或、国民身份证号或视需


要而定的数据)。 这包括数据库管理员或其他特权用户,他们被授权访问数据库以执行管理任务,但不需要访问
加密列中的特定数据。 数据始终处于加密状态,这意味着加密数据只在有权访问加密密钥的客户端应用程序需
要处理数据时才解密。 加密密钥从不暴露给 SQL 数据库或 SQL 托管实例,而且可以存储在 Windows 证书存
储或 Azure Key Vault 中。

动态 数据屏蔽
动态数据屏蔽通过对非特权用户屏蔽敏感数据来限制敏感数据的公开。 动态数据掩码可自动发现 Azure SQL 数
据库和 SQL 托管实例中潜在的敏感数据,提供可行的建议来掩码这些字段,对应用程序层造成的影响可忽略不
计。 它的工作原理是在针对指定的数据库字段运行查询后返回的结果集中隐藏敏感数据,同时保持数据库中的
数据不变。 有关详细信息,请参阅 SQL 数据库和 SQL 托管实例动态数据掩码入门。

安全管理
漏洞 评 估
漏洞评估是一项易于配置的服务,可以发现、跟踪和帮助修正潜在的数据库漏洞,旨在主动提高整体数据库安全
性。 漏洞评估 (VA) 是 Azure Defender for SQL 产品/服务(高级 SQL 安全功能的统一包)的一部分。 可通过中心
Azure Defender for SQL 门户访问和管理漏洞评估。
数据 发现 和分 类
数据发现和分类(当前为预览版)提供了内置于 Azure SQL 数据库和 SQL 托管实例的高级功能,可用于发现、分
类、标记和保护数据库中的敏感数据。 发现最敏感的数据(业务/财务、医疗保健、个人数据等)并进行分类,可在
组织的信息保护方面发挥关键作用。 它可以充当基础结构,用于:

各种安全方案,如监视(审核)并在敏感数据存在异常访问时发出警报。
控制对包含高度敏感数据的数据库的访问并增强其安全性。
帮助满足数据隐私标准和法规符合性要求。

有关详细信息,请参阅数据发现和分类入门。

合规性
除了上述有助于应用程序符合各项安全要求的特性和功能以外,Azure SQL 数据库还定期参与审核,并已通过许
多法规标准的认证。 有关详细信息,请参阅 Microsoft Azure 信任中心 ,你可以在其中找到最新的 SQL 数据库符
合性认证列表。

后续步骤
有关如何使用 SQL 数据库和 SQL 托管实例中的登录名、用户帐户、数据库角色和权限,请参阅管理登录名和
用户帐户。
有关数据库审核的讨论,请参阅审核。
有关威胁检测的讨论,请参阅威胁检测。
⽤于解决 Azure SQL 数据库和 Azure SQL 托管实
例常⻅安全要求的 playbook
2021/2/9 • • Edit Online

适用于: Azure SQL 数据库 Azure SQL 托管实例


本文提供了有关如何解决常见安全要求的最佳做法。 并非所有要求都适用于所有环境,你应该向数据库和安全
团队咨询要实现哪些功能。

解决常见的安全要求
本文档提供有关如何解决使用 Azure SQL 数据库和 Azure SQL 托管实例的新应用程序或现有应用程序的常见安
全要求的指导。 本文档的内容已从较高层面按照安全考虑因素进行组织。 若要解决特定的威胁,请参阅常见安
全威胁和潜在缓解措施部分。 提供的某些建议在将应用程序从本地迁移到 Azure 时适用,不过,本文档不会重点
说明迁移方案。

本指南涉及的 Azure SQL 数据 库 部署 产 品 /服 务


Azure SQL 数据库:服务器中的单一数据库和弹性池
Azure SQL 托管实例
本指南不涉及的部署 产 品 / 服 务
Azure Synapse Analytics
Azure SQL VM (IaaS)
SQL Server
目 标 受众
本指南的目标读者是在保护 Azure SQL 数据库时遇到问题的客户。 对本最佳做法文章感兴趣的角色包括但不限
于:

安全架构师
安全经理
合规性主管
隐私主管
安全工程师

使用本指南
本文档旨在用作现有 Azure SQL 数据库安全性文档的配套资源。

除非另有说明,否则我们建议遵循每个部分中列出的所有最佳做法,以实现相关的目标或要求。 为了帮助客户满
足特定的安全合规标准或最佳做法,在适用的情况下,“要求或目标”部分下面会列出重要的法规控制措施。 本文
参考了以下安全标准和法规:

FedRAMP:AC-04、AC-06
SOC:CM-3、SDL-3
ISO/IEC 27001:访问控制、加密
Microsoft 操作安全保障 (OSA) 做法:做法 #1-6 和 #9
NIST 专刊 800-53 安全控制:AC-5、AC-6
PCI DSS :6.3.2、6.4.2
我们计划持续更新本文列出的建议和最佳做法。 使用本文底部的 " 反 馈 " 链接提供对此文档的输入或任何更
正。

身份验证
身份验证是证明用户所声明身份的过程。 Azure SQL 数据库和 SQL 托管实例支持两种类型的身份验证:

SQL 身份验证
Azure Active Directory 身份验证

NOTE
并非所有工具和第三方应用程序都支持 Azure Active Directory 身份验证。

标识 的集中管理
集中式标识管理提供以下优势:

管理组帐户并控制用户权限,而无需跨服务器、数据库和托管实例重复登录。
简化且灵活的权限管理。
应用程序的大规模管理。

如何 实现 :

使用 Azure Active Directory (Azure AD) 身份验证实现集中式标识管理。

最佳做法 :

创建 Azure AD 租户,创建用户来表示人类用户,并创建服务主体来表示应用、服务和自动化工具。 服务
主体相当于 Windows 和 Linux 中的服务帐户。

通过组分配向 Azure AD 主体分配资源访问权限:创建 Azure AD 组,向组授予访问权限,并将各个成员添


加到组中。 在数据库中,创建包含的数据库用户用于映射 Azure AD 组。 若要在数据库中分配权限,请将
与 Azure AD 组关联的用户置于具有适当权限的数据库角色中。

请参阅文章通过 SQL 配置和管理 Azure Active Directory 身份验证以及通过 SQL 使用 Azure AD 进行


身份验证。

NOTE
在 SQL 托管实例中,还可以创建映射到 master 数据库中的 Azure AD 主体的登录名。 请参阅 CREATE LOGIN
(Transact-SQL)。

使用 Azure AD 组可以简化权限管理,组所有者和资源所有者都可以在组中添加/删除成员。

为每个服务器或托管实例创建单独的 Azure AD 管理员组。

请参阅为服务器预配 Azure Active Directory 管理员一文。


使用 Azure AD 审核活动报告监视 Azure AD 组成员身份的更改。

对于托管实例,需要执行一个单独的步骤来创建 Azure AD 管理员。

请参阅为托管实例预配 Azure Active Directory 管理员一文。


NOTE
Azure AD 身份验证记录在 Azure SQL 审核日志中,而不是记录在 Azure AD 登录日志中。
Azure 中授予的 azure RBAC 权限不适用于 Azure SQL 数据库或 SQL 托管实例权限。 必须使用现有的 SQL 权限手动创
建/映射此类权限。
在客户端上,Azure AD 身份验证需要访问 Internet,或通过用户定义的路由 (UDR) 访问虚拟网络。
Azure AD 访问令牌缓存在客户端,其生存期取决于令牌配置。 请参阅Azure Active Directory 中可配置的令牌生存期一

有关解决 Azure AD 身份验证问题的指南,请参阅以下博客: Azure AD 故障排除。

Azure AD 多重身份 验证
内容来源:OSA 做法 #2 ,ISO 访问控制 (AC)

Azure AD 多重身份验证通过要求多种形式的身份验证提供额外的安全性。
如何 实现 :

使用条件访问在 Azure AD 中启用多重身份验证,并使用交互式身份验证。

或者,为整个 Azure AD 或 AD 域启用多重身份验证。

最佳做法 :

Azure AD (需要高级订阅) 中激活条件性访问。


请参阅文章 Azure AD 中的条件性访问。
创建 Azure AD 组,并使用 Azure AD 条件访问为选定的组启用多重身份验证策略。

请参阅规划条件访问部署一文。
可为整个 Azure AD 或者与 Azure AD 联合的整个 Active Directory 启用多重身份验证。

对以交互方式请求密码的 Azure SQL 数据库和 Azure SQL 托管实例使用 Azure AD 交互式身份验证模式,


然后启用多重身份验证:

在 SSMS 中使用通用身份验证。 请参阅在 Azure SQL 数据库、SQL 托管实例和 Azure Synapse


Analytics 中使用多重 Azure AD 身份验证(SSMS 对多重身份验证的支持)一文。
使用 SQL Server Data Tools (SSDT) 中支持的交互式身份验证。 请参阅 SQL Server Data Tools (SSDT)
中的 Azure Active Directory 支持。
使用其他支持多重身份验证的 SQL 工具。
SSMS 向导对导出/提取/部署数据库操作的支持
sqlpackage.exe:选项“/ua”
sqlcmd 实用工具:选项 -G(交互式)
bcp 实用工具:选项 -G(交互式)
实现你的应用程序,以使用支持多重身份验证的交互式身份验证连接到 Azure SQL 数据库或 Azure SQL
托管实例。

请参阅 通过 Azure AD 多重身份验证连接到 AZURE SQL 数据库一文。

NOTE
此身份验证模式需要使用基于用户的标识。 如果使用的受信任标识模型会绕过个体 Azure AD 用户身份验证(例如,
使用 Azure 资源的托管标识),则不会应用多重身份验证。

尽量减少 对 用 户 使用基于密 码 的身份 验证


内容来源:OSA 做法 #4 ,ISO 访问控制 (AC)

基于密码的身份验证方法是较弱的身份验证形式。 凭据可能会透露或者被错误地丢弃。

如何 实现 :

使用 Azure AD 集成身份验证,此方法可消除密码的使用。

最佳做法 :

使用 Windows 凭据进行单一登录身份验证。 将本地 AD 域与 Azure AD 相联合,并使用 Windows 集成身份


验证(适用于 Azure AD 中已加入域的计算机)。
请参阅 SSMS 对 Azure AD 集成身份验证的支持一文。

尽量减少 对应 用程序使用基于密 码 的身份 验证

内容来源:OSA 做法 #4 ,ISO 访问控制 (AC)

如何 实现 :

启用 Azure 托管标识。 还可以使用集成式或基于证书的身份验证。

最佳做法 :

使用 Azure 资源的托管标识。

系统分配的托管标识
用户分配的托管标识
从具有托管标识的 Azure 应用服务使用 Azure SQL 数据库(无需更改代码)
对应用程序使用基于证书的身份验证。

请参阅此代码示例。
对集成的联合域和已加入域的计算机使用 Azure AD 身份验证(参阅上一部分)。

请参阅集成身份验证的示例应用程序。

保 护 密 码 和机密
如果不可避免地需要使用密码,请确保密码受到保护。

如何 实现 :

使用 Azure Key Vault 存储密码和机密。 在适用的情况下,请对 Azure AD 用户使用 Azure SQL 数据库的多重
身份验证。

最佳做法 :

如果无法避免密码或机密的使用,请在 Azure Key Vault 中存储用户密码和应用程序机密,并通过 Key


Vault 访问策略管理访问权限。
各种应用开发框架还可能提供框架特定的机制来保护应用中的机密。 例如:ASP.NET Core 应用。

对 旧式 应 用程序使用 SQL 身份 验证
SQL 身份验证是指使用用户名和密码连接到 Azure SQL 数据库或 SQL 托管实例时对用户进行身份验证。 需要在
每个服务器或托管实例中创建一个登录名,并在每个数据库中创建一个用户。

如何 实现 :

使用 SQL 身份验证。

最佳做法 :
以服务器或实例管理员的身份创建登录名和用户。 除非将包含的数据库用户与密码配合使用,否则所有密码
将存储在 master 数据库中。
请参阅控制和授予对 SQL 数据库、SQL 托管实例和 Azure Synapse Analytics 的数据库访问权限一文。

访问管理
访问管理(也称为授权)是控制和管理已授权用户对 Azure SQL 数据库或 SQL 托管实例的访问权限与特权的过
程。

实 施最低特 权 原 则

内容来源:FedRamp 控制措施 AC-06 ,NIST:AC-6 ,OSA 做法 #3

最低特权原则指出,用户拥有的特权不应超过他们完成任务所需的特权。 有关详细信息,请参阅 Just Enough


Administration 一文。
如何 实现 :

仅分配完成所需任务而需要的权限:

在 SQL 数据库中:

使用粒度权限和用户定义的数据库角色(或托管实例中的服务器角色):
1. 创建所需的角色
CREATE ROLE
CREATE SERVER ROLE
2. 创建所需的用户
CREATE USER
3. 将用户作为成员添加到角色
ALTER ROLE
ALTER SERVER ROLE
4. 然后将权限分配给角色。
GRANT
确保不要将用户分配到不必要的角色。
在 Azure 资源管理器中:

使用内置角色(如果可用)或 Azure 自定义角色,并分配所需的权限。


Azure 内置角色
Azure 自定义角色
最佳做法 :

以下最佳做法是可选的,但可以改善安全策略的易管理性和支持性:

如果可能,请从尽可能低的权限集开始,并在有实际需要(和理由)时逐个添加权限 - 而不要采用相反的方
法:逐步去除权限。

避免将权限分配给单个用户。 改为以一致的方式使用角色(数据库角色或服务器角色)。 角色能够为报告


权限和排查权限问题提供很大的帮助。 (Azure RBAC 仅支持通过角色分配权限。)

创建和使用具有所需确切权限的自定义角色。 实践中使用的典型角色:

安全部署
管理员
开发人员
支持人员
审核员
自动化过程
最终用户
只有当角色的权限与用户所需的权限完全匹配时,才使用内置角色。 可将用户分配到多个角色。

请记住,数据库引擎中的权限可以在以下范围内应用(范围越小,授予的权限的影响越小):

Azure 中的服务器(master 数据库中的特殊角色)


数据库
架构
最佳做法是使用架构在数据库中授予权限。 (另请参阅:架构设计:有关架构设计的建议和安全
注意事项)
对象(表、视图、过程等)

NOTE
不建议在对象级别应用权限,因为此级别会给整个实现带来不必要的复杂性。 如果决定使用对象级权限,应明确阐
述这些权限。 这同样适用于列级权限,出于相同的原因,我们更不建议应用此类权限 另请注意,默认情况下,表级
DENY 不会覆盖列级授权。 这需要激活通用标准合规性服务器配置。

使用漏洞评估 (VA) 执行定期检查,以测试权限是否过多。

实现职责 分离

内容来源:FedRamp:AC-04 ,NIST:AC-5 ,ISO:6.1.2 、PCI 6.4.2 ,SOC:CM-3 、SDL-3

“职责分离”描述将敏感任务拆分为要分配给不同用户的多个任务的要求。 职责分离有助于防止数据违规。
如何 实现 :

识别所需的职责分离级别。 示例:

在开发/测试环境与生产环境之间
安全相关的任务、数据库管理员 (DBA) 管理级别任务与开发人员任务。
示例:审核员为角色级安全性 (RLS) 创建安全策略,并使用 DDL 权限实现 SQL 数据库对象。
识别有权访问系统的用户(和自动化过程)的综合层次结构。

根据所需的用户组创建角色,并将权限分配给角色。

对于通过 Azure 门户或 PowerShell 自动化完成的管理级任务,请使用 Azure 角色。 查找符合要求的内


置角色,或者使用可用权限创建 Azure 自定义角色
在托管实例中为服务器范围的任务(创建新的登录名和数据库)创建服务器角色。
为数据库级任务创建数据库角色。
对于某些敏感任务,考虑创建由证书签名的特殊存储过程,以代表用户执行这些任务。 数字签名存储过程
的一个重要优点是,如果更改了该过程,则会立即删除授予该过程的旧版本的权限。

示例:教程:使用证书为存储过程签名
使用 Azure Key Vault 中客户管理的密钥实现透明数据加密 (TDE),以便在数据所有者与安全所有者之间实
现职责分离。

请参阅通过 Azure 门户配置客户管理的密钥用于 Azure 存储加密一文。


为了确保 DBA 无法看到高度敏感的数据但仍可执行 DBA 任务,可将 Always Encrypted 与角色分离配合
使用。
请参阅文章 Always Encrypted 密钥管理概述、使用角色分离的密钥预配和使用角色分离的列主密钥轮
换。
如果使用 Always Encrypted 不可行(最起码在不付出极大成本和工作量的情况下做不到这一点,但如果付
出,甚至可能会导致系统几乎不可用),可以通过补偿性的控制措施来采取折衷办法,例如:

在过程中进行人工干预。
审核线索 – 有关审核的详细信息,请参阅审核关键安全事件。

最佳做法 :

确保将不同的帐户用于开发/测试环境和生产环境。 不同的帐户有助于满足测试和生产系统分离的原则。

避免将权限分配给单个用户。 改为以一致的方式使用角色(数据库角色或服务器角色)。 使用角色能够为


报告权限和排查权限问题提供很大的帮助。

当权限与所需权限完全匹配时使用内置角色 – 如果多个内置角色的所有权限的联合导致 100% 匹配,则


还可以同时分配多个角色。

当内置角色授予的权限过多或不足时,创建并使用用户定义的角色。

还可以通过 T-SQL 的 SQL 代理作业步骤或适用于 Azure 角色的 Azure PIM 暂时执行角色分配(也称为动


态职责分离 (DSD))。

确保 DBA 无权访问加密密钥或密钥存储,而有权访问密钥的安全管理员无权访问数据库。 (EKM) 使用可


扩展的密钥管理可以使此分离更容易实现。 Azure Key Vault 可用于实现 EKM。

始终确保针对安全相关的操作提供审核线索。

可以检索 Azure 内置角色的定义以查看所用的权限,并通过 PowerShell 根据这些信息的摘录和累积创建


自定义角色。

由于 db_owner 数据库角色的任何成员都可以更改透明数据加密 (TDE) 等安全设置或更改 SLO,因此,应


谨慎地授予此成员身份。 但是,许多任务要求使用 db_owner 特权。 例如,更改数据库选项等任何数据库
设置的任务。 在任何解决方案中,审核都发挥着关键的作用。

无法限制 db_owner 的权限,因此应阻止管理帐户查看用户数据。 如果数据库中包含高度敏感的数据,可


以使用 Always Encrypted 来安全阻止 db_owners 或任何其他 DBA 查看这些数据。

NOTE
对安全相关的任务或故障排除任务实现职责分离 (SoD) 会有难度。 其他方面(例如开发和最终用户角色)更易于分离。 当其
他解决方案不可行时,大多数合规性相关的控制措施允许使用替代的控制功能,例如审核。

对于想要深入了解 SoD 的读者,建议阅读以下资源:

对于 Azure SQL 数据库和 SQL 托管实例:

控制和授予数据库访问权限
应用程序开发人员的引擎职责分离
职责分离
对存储过程签名
对于 Azure 资源管理:

Azure 内置角色
Azure 自定义角色
使用 Azure AD Privileged Identity Management 提升访问权限

执 行定期代 码评审
内容来源:PCI:6.3.2 ,SOC:SDL-3

职责分离不局限于数据库中的数据,它还包括应用程序代码。 恶意代码可能会绕过安全控制。 在将自定义代码


部署到生产环境之前,必须评审要部署的内容,这一点至关重要。

如何 实现 :

使用支持源代码管理的数据库工具,例如 Azure Data Studio。

实现分离的代码部署过程。

在提交到主分支之前,必须由某个人员(代码本身的作者除外)检查代码是否存在提升特权的风险,以及是
否存在恶意的数据修改,以防止出现欺诈和恶意访问。 可以使用源代码管理机制实现此目的。

最佳做法 :

标准化:实现每次更新代码时都要遵循的标准过程会很有帮助。

漏洞评估中的规则可以检查是否存在过多的权限、是否使用了旧加密算法,以及数据库架构中是否存在其
他安全问题。

可以在 QA 或测试环境中使用高级威胁防护来执行更多的检查,此技术将扫描容易受到 SQL 注入攻击的


代码。

要注意的方面的示例:

从自动化 SQL 代码更新部署内部创建用户或更改安全设置。


某个存储过程根据提供的参数以不一致的方式更新单元格中的货币值。
确保执行评审的人员是除原始代码作者以外的个人,且熟悉代码评审和安全编码。

确保知道所有代码更改来源。 代码可能位于 T-SQL 脚本中。 它可能是要以视图、函数、触发器和存储过程


形式执行或部署的临时命令。 它可能是 SQL 代理作业定义(步骤)的一部分。 它还可能从 SSIS 包、Azure
数据工厂和其他服务的内部执行。

数据保护
数据保护是通过加密或模糊处理来防止重要信息遭到透露的一组功能。

NOTE
Microsoft 的 Azure SQL 数据库和 SQL 托管实例已通过 FIPS 140-2 级别 1 合规认证。 认证过程中已确认它严格使用 FIPS
140-2 级别 1 可接受的算法,以及这些算法的、经 FIPS 140-2 级别 1 验证的实例,包括符合所需密钥长度、密钥管理、密钥
生成和密钥存储的要求。 此项认证意味着,我们的客户在处理数据或者交付系统或应用程序的过程中,可以满足使用 FIPS
140-2 级别 1 验证实例的需求或要求。 我们定义了上述语句中使用的术语 "FIPS 140-2 Level 1 相容" 和 "FIPS 140-2 Level
1 相容性",以演示其对美国和加拿大政府使用不同术语 "FIPS 140-2 Level 1 验证" 的预期适用性。

加密 传输 中的数据

内容来源:OSA 做法 #6 ,ISO 控制系列:Cryptography

当数据在客户端与服务器之间移动时为其提供保护。 请参阅网络安全性。

静 态 数据加密

内容来源:OSA 做法 #6 ,ISO 控制系列:Cryptography

静态加密是指对数据库、日志和备份文件中保存的数据进行加密保护。
如何 实现 :

对于 2017 年后在 Azure SQL 数据库和 SQL 托管实例中创建的任何数据库,默认将启用通过服务托管的密钥


进行透明数据库加密 (TDE)。
在托管实例中,如果数据库是使用本地服务器从还原操作创建的,则会遵循原始数据库的 TDE 设置。 如果未
为原始数据库启用 TDE,则我们建议手动为托管实例启用 TDE。

最佳做法 :

不要将需要静态加密的数据存储在 master 数据库中。 无法使用 TDE 加密 master 数据库。

如果需要提高透明度并精细控制 TDE 保护,请使用 Azure Key Vault 中客户管理的密钥。 Azure Key Vault
允许随时撤销权限,使数据库不可访问。 可以集中管理 TDE 保护器及其他密钥,或使用 Azure Key Vault
按自己的计划轮换 TDE 保护器。

如果使用 Azure Key Vault 中客户管理的密钥,请参阅文章有关使用 Azure Key Vault 配置 TDE 的指导原
则和如何使用 Azure Key Vault 配置异地灾难恢复。

防止未 经 授 权 的高特 权 用 户查 看使用中的敏感数据


使用中的数据是指在执行 SQL 查询期间存储在数据库系统内存中的数据。 如果数据库存储敏感数据,则组织可
能需要确保防止高特权用户查看数据库中的敏感数据。 高特权用户(例如组织中的 Microsoft 操作员或 DBA)应
该能够管理数据库,但不能通过查询数据库来查看并潜在地透露 SQL 进程内存中的敏感数据。

需要确定哪些数据是敏感的,以及敏感数据是否必须在内存中加密并且不可供管理员以明文形式访问,用于确定
这些事项的策略特定于你的组织以及你需要遵守的合规性规定。 请参阅相关要求:识别并标记敏感数据。

如何 实现 :

使用 Always Encrypted 来确保不会以纯文本形式公开 Azure SQL 数据库或 SQL 托管实例中的敏感数据,即


使是内存中/使用中的数据。 Always Encrypted 可以防止数据库管理员 (DBA) 和云管理员(或者可以仿冒未经
授权的高特权用户的恶意行动者)查看数据,并使你能够以更高的力度控制谁可以访问数据。

最佳做法 :

Always Encrypted 不能取代静态数据加密 (TDE) 或传输中数据加密 (SSL/TLS)。 为了尽量减轻对性能和功


能的影响,请不要将 Always Encrypted 用于非敏感数据。 建议将 Always Encrypted 与 TDE 和传输层安全
性 (TLS) 结合使用,以全面保护静态数据、传输中的数据和使用中的数据。

在生产数据库中部署 Always Encrypted 之前,请先评估对所识别出的敏感数据列进行加密会带来的影


响。 通常情况下,Always Encrypted 会降低对加密列的查询功能,并具有其他限制,如 Always Encrypted -
功能详细信息中所列。 因此,你可能需要在客户端重构你的应用程序来重新实现查询不支持的功能,或
者/并且重构你的数据库架构,包括存储过程、函数、视图和触发器的定义。 如果现有应用程序未遵守
Always Encrypted 的限制,则可能无法使用加密列。 虽然支持 Always Encrypted 的 Microsoft 工具、产品
和服务的生态系统在不断增长,但它们中还是有许多不能使用加密列。 加密列还可能会影响查询性能,具
体取决于工作负荷的特征。

如果使用 Always Encrypted 来防止恶意 DBA 查看数据,请通过角色分离来管理 Always Encrypted 密钥。


安全管理员可以使用角色分离来创建物理密钥。 DBA 在数据库中创建用于描述物理密钥的列主密钥和列
加密密钥元数据对象。 在此过程中,安全管理员不需要访问数据库,且 DBA 不需要访问纯文本形式的物
理密钥。

有关详细信息,请参阅使用角色分离管理密钥一文。
将列主密钥存储在 Azure Key Vault 中,以方便管理。 避免使用会使密钥管理变得困难的 Windows 证书存
储(以及一般的分布式密钥存储解决方案,而不是集中式密钥管理解决方案)。

仔细考虑使用多个密钥(列主密钥或列加密密钥)的利弊。 保留少量的密钥以减小密钥管理成本。 在稳定


态的环境中(而不是在密钥轮换的中途),为每个数据库准备一个列主密钥和一个列加密密钥通常已足够。
如果有不同的用户组,而每个组使用不同的密钥并访问不同的数据,则可能需要更多的密钥。
根据合规要求轮换列主密钥。 如果还需要轮换列加密密钥,请考虑使用在线加密来尽量减少应用程序停
机时间。

请参阅性能和可用性注意事项一文。
如果需要支持数据计算(相等性),请使用确定性加密。 否则请使用随机加密。 避免将确定性加密用于低
熵数据集或采用众所周知分布形式的数据集。

如果你担心第三方在合法的情况下访问你的数据,请确保能够以纯文本形式访问密钥和数据的所有应用
程序和工具在 Microsoft Azure 云的外部运行。 如果第三方无权访问密钥,则除非绕过加密,否则他们无
法解密数据。

Always Encrypted 无法轻松支持授予对密钥(和受保护数据)的临时访问权限。 例如,如果需要与 DBA 共


享密钥,使 DBA 能够对敏感数据和加密的数据执行一些清理操作。 可靠撤销 DBA 的数据访问权限的唯一
方法是,同时轮换用于保护数据的列加密密钥和列主密钥,而这是一项开销较高的操作。

若要访问已加密列中的纯文本值,用户需要有权访问用于保护列的列主密钥 (CMK)(在保存 CMK 的密钥


存储中进行配置)。 用户还需要拥有“查看任何列主密钥定义”和“查看任何列加密密钥定义”数据库权限。

通 过 加密控制 应 用程序用 户对 敏感数据的 访问


可以使用加密来确保只有有权访问加密密钥的特定应用程序用户才能查看或更新数据。

如何 实现 :

使用单元级加密 (CLE)。 有关详细信息,请参阅加密数据列一文。


使用 Always Encrypted,但要注意其限制。 下面列出了限制。

最佳 实 践

使用 CLE 时:

通过 SQL 权限和角色控制对密钥的访问。

使用 AES (推荐 AES 256) 进行数据加密。 由于存在已知漏洞,RC4 、DES 和 TripleDES 等算法已遭弃用,请


不要使用它们。

使用非对称密钥/证书(而不是密码)来保护对称密钥,以避免使用 3DES 。

通过导出/导入(bacpac 文件)使用单元级加密迁移数据库时请小心。

有关在迁移数据时如何防止丢失密钥以及其他最佳做法指导,请参阅有关在 Azure SQL 数据库中使用


单元级加密的建议。

请记住,Always Encrypted 主要用于防止 Azure SQL 数据库的高特权用户(云操作员、DBA)查看使用中的敏感数


据 - 请参阅防止防止未经授权的高特权用户查看使用中的敏感数据。 使用 Always Encrypted 防止应用程序用户
查看数据时,请注意以下难点:

默认情况下,支持 Always Encrypted 的所有 Microsoft 客户端驱动程序都会维护列加密密钥的全局缓存(每个


应用程序一个缓存)。 在客户端驱动程序通过联系保存列主密钥的密钥存储获取纯文本列加密密钥后,将会
缓存纯文本列加密密钥。 这使得将数据与多用户应用程序的用户相隔离变得困难。 如果应用程序在与密钥存
储交互(例如 Azure Key Vault)时模拟最终用户,则在用户的查询使用列加密密钥填充缓存之后,需要同一个
密钥但由其他用户触发的后续查询将使用缓存的密钥。 驱动程序不会调用密钥存储,也不会检查第二个用户
是否有权访问列加密密钥。 因此,即使用户无权访问密钥,也可以查看加密的数据。 若要在多用户应用程序
中实现用户隔离,可以禁用列加密密钥缓存。 禁用缓存会导致性能开销增大,因为驱动程序需要联系密钥存
储来完成每个数据加密或解密操作。

在保留数据格式的同 时 防止 应 用程序用 户 在未 经 授 权 的情况下 查 看数据


防止未经授权的用户查看数据的另一种方法是对数据进行模糊处理或掩码,同时保留数据类型和格式,以确保用
户应用程序可以继续处理和显示数据。
如何 实现 :

使用动态数据掩码来模糊处理表列。

NOTE
Always Encrypted 不能与动态数据掩码配合工作。 无法加密和掩码同一个列,这意味着,需确定是要优先保护使用中的数
据,还是通过动态数据掩码来对应用用户掩码数据。

最佳做法 :

NOTE
动态数据掩码不可用于防止高特权用户查看数据。 掩码策略不适用于拥有管理访问权限的用户,例如 db_owner。

不要允许应用用户运行临时查询(因为他们也许可以克服动态数据掩码)。

有关详细信息,请参阅使用推理或暴力破解技术绕过掩码一文。
使用适当的访问控制策略(通过 SQL 权限、角色、RLS )来限制用户在掩码列中进行更新的权限。 对列进行
掩码不会阻止对该列进行更新。 如果查询掩码列时收到掩码数据的用户拥有写入权限,则他们可以更新
这些数据。

动态数据掩码不会保留掩码值的统计属性。 这可能会影响查询结果(例如,包含筛选谓词的查询或者对掩
码数据的联接)。

网络安全性
网络安全性是指用于保护传输到 Azure SQL 数据库的数据的访问控制和最佳做法。

配置客 户 端以安全 连 接到 SQL 数据 库 /SQL 托管 实 例


有关如何防范存在已知漏洞(例如,使用早期 TLS 协议和密码套件)的客户端计算机和应用程序连接到 Azure
SQL 数据库和 SQL 托管实例的最佳做法。
如何 实现 :

确保连接到 Azure SQL 数据库和 SQL 托管实例的客户端计算机使用传输层安全性 (TLS)。

最佳做法 :

配置所有应用和工具以连接到启用了加密的 SQL 数据库

Encrypt = On,TrustServerCertificate = Off(或者在非 Microsoft 驱动程序中配置相应的设置)。


如果应用使用的驱动程序不支持 TLS 或者支持早期版本的 TLS ,请尽可能地更换驱动程序。 如果无法做到
这一点,请认真评估安全风险。

减少通过 SSL 2.0 、SSL 3.0 、TLS 1.0 和 TLS 1.1 中的漏洞发起的攻击途径:根据传输层安全性 (TLS) 注册表
设置,在连接到 Azure SQL 数据库的客户端计算机上禁用相关的途径。

检查客户端上的密码套件:TLS/SSL (Schannel SSP) 中的密码套件。 具体而言,根据配置 TLS 密码套件顺


序禁用 3DES 。

对于 Azure SQL 数据库和 SQL 托管实例,将对“代理”和“重定向”连接类型强制加密。 对于 Azure SQL 托


管实例,请使用“代理”连接类型(默认设置),因为这可以强制在服务器端加密。 “重定向”连接类型目前不
支持加密强制,仅在专用 IP 连接上可用。

有关详细信息,请参阅 Azure SQL 数据库连接体系结构 - 连接策略。


尽量减少受攻 击 面
尽量减少恶意用户可以攻击的特征数。 对 Azure SQL 数据库实现网络访问控制。

内容来源:OSA 做法 #5

如何 实现 :

在 SQL 数据库中:

在服务器级别将“允许访问 Azure 服务”设置为“关闭”


使用 VNet 服务终结点和 VNet 防火墙规则。
使用专用链接(预览)。

在 SQL 托管实例中:

遵循网络要求中的指导原则。

最佳做法 :

通过连接到专用终结点(例如,使用专用数据路径)来限制对 Azure SQL 数据库和 SQL 托管实例的访问:

可将托管实例隔离在虚拟网络内,防止外部访问。 位于同一区域的相同或对等虚拟网络中的应用程序
和工具可以直接访问它。 位于不同区域的应用程序和工具可使用虚拟网络到虚拟网络连接,或使用
ExpressRoute 线路对等互连来建立连接。 客户应使用网络安全组 (NSG) 来仅限通过端口 1433 访问需
要访问托管实例的资源。
对于 SQL 数据库,请使用 专用链接 功能,该功能为虚拟网络中的服务器提供专用专用 IP。 还可使
用配置了虚拟网络防火墙规则的虚拟网络服务终结点来限制对服务器的访问。
移动用户应使用点到站点 VPN 连接,通过数据路径进行连接。
连接到本地网络的用户应使用站点到站点 VPN 连接或 ExpressRoute,通过数据路径进行连接。
可以通过连接到公共终结点(例如,使用公共数据路径)来访问 Azure SQL 数据库和 SQL 托管实例。 应考
虑以下最佳做法:

对于 SQL 数据库中的服务器,请使用 IP 防火墙规则,仅限访问已授权的 IP 地址。


对于 SQL 托管实例,请使用网络安全组 (NSG),仅限通过端口 3342 访问所需的资源。 有关详细信息,
请参阅在公共终结点中安全使用托管实例。

NOTE
SQL 托管实例公共终结点默认未启用,必须显式启用它。 如果公司政策禁止使用公共终结点,请首先使用 Azure Policy 来防
止启用公共终结点。

设置 Azure 网络组件:
按照 Azure 网络安全最佳做法进行操作。
根据 Azure 虚拟网络常见问题解答 (FAQ) 和计划中所述的最佳做法规划虚拟网络配置。
将虚拟网络划分为多个子网,并将类似角色的资源(例如,前端与后端资源)分配到同一子网。
使用网络安全组 (NSG) 来控制 Azure 虚拟网络边界范围内子网之间的流量。
为订阅启用 Azure 网络观察程序,以监视入站和出站网络流量。

配置 Power BI 以安全 连 接到 SQL 数据 库 /SQL 托管 实 例


最佳做法 :

对于 Power BI Desktop,请尽可能地使用专用数据路径。

根据传输层安全性 (TLS) 注册表设置在客户端计算机上设置注册表项,确保 Power BI Desktop 使用


TLS1.2 进行连接。
通过 Power BI 行级安全性 (RLS) 限制特定用户的数据访问权限。

对于 Power BI 服务,请使用本地数据网关,同时请记住限制和注意事项。

配置 应 用服 务 以安全 连 接到 SQL 数据 库 /SQL 托管 实 例


最佳做法 :

对于简单的 Web 应用,通过公共终结点进行连接需要将“允许 Azure 服务”设置为“打开”。

将应用与 Azure 虚拟网络集成,以通过专用数据路径连接到托管实例。 (可选)还可以部署采用应用服务


环境 (ASE) 的 Web 应用。

对于连接到 SQL 数据库中的数据库的、采用 ASE 的 Web 应用或者与虚拟网络集成的 Web 应用,可以使


用 虚拟网络服务终结点和虚拟网络防火墙规则来限制从特定虚拟网络和子网的访问。 然后,将“允许
Azure 服务”设置为“关闭”。 还可以通过专用数据路径将 ASE 连接到 SQL 托管实例中的托管实例。
确保 Web 应用按照使用 Azure 应用服务保护平台即服务 (PaaS) Web 和移动应用程序的最佳做法一文进
行了配置。

安装 Web 应用程序防火墙 (WAF),以防止 Web 应用遭到常见的恶意利用和出现漏洞。

配置 Azure 虚 拟 机以安全 连 接到 SQL 数据 库 /SQL 托管 实 例


最佳做法 :

在 Azure 虚拟机的 NSG 中结合使用“允许”和“拒绝”规则,以控制可从 VM 访问哪些区域。

确保 VM 根据 Azure 中 IaaS 工作负载的安全性最佳做法一文进行了配置。

确保所有 VM 与特定的虚拟网络和子网相关联。

根据关于强制隧道中的指导,评估是否需要默认路由 0.0.0.0/Internet。

如果需要(例如在前端子网中),请保留默认路由。
如果不需要(例如在中间层或后端子网中),请启用强制隧道,使流量不会通过 Internet 抵达本地(即跨
界)。
如果使用对等互连或者连接到本地,请实现可选默认路由。

如果需要将虚拟网络中的所有流量发送到网络虚拟设备进行数据包检查,请实现用户定义的路由。

使用虚拟网络服务终结点通过 Azure 主干网络安全访问 Azure 存储等 PaaS 服务。

防范分布式拒 绝 服 务 (DDoS ) 攻 击
分布式拒绝服务 (DDoS) 攻击由恶意用户尝试向 Azure SQL 数据库发送大量网络流量,目的是使 Azure 基础结构
成为惊人,并导致其拒绝有效登录和工作负荷。

中提到的: OSA 实践 #9

如何 实现 :

在 Azure 平台中,会自动启用 DDoS 保护。 它包括 always on 流量监视和对公共终结点上网络级别攻击的实时缓


解。

使用 Azure DDoS 防护 来监视与虚拟网络中部署的资源关联的公共 IP 地址。

使用 AZURE SQL 数据库的高级威胁防护 来检测对数据库的拒绝服务 (DoS) 攻击。

最佳做法 :

遵循 最小化攻击面 中所述的做法有助于最大程度地减少 DDoS 攻击威胁。

高级威胁防护 强 力 强 制 SQL 凭据 警报有助于检测暴力破解攻击。 在某些情况下,警报甚至可以区分渗


透测试工作负荷。

对于托管连接到 SQL 数据库的应用程序的 Azure VM:

遵循建议,在 Azure 安全中心中通过面向 Internet 的终结点限制访问。


使用虚拟机规模集在 Azure Vm 上运行应用程序的多个实例。
禁用来自 Internet 的 RDP 和 SSH,以防止强力攻击。

监视、日志记录和审核
本部分所述的功能可帮助你检测异常活动,这些活动指示非同寻常或者潜在有害的访问或恶意利用数据库的企
图。 本部分还将提供有关配置数据库审核来跟踪和捕获数据库事件的最佳做法。

防范数据 库 遭到攻 击
高级威胁防护可在发生异常活动时提供安全警报,让我们检测潜在威胁并做出响应。

如何 实现 :

使用适用于 SQL 的高级威胁防护来检测非同寻常或者潜在有害的访问或恶意利用数据库的企图,包括:


SQL 注入攻击。
凭据盗窃/泄露。
特权滥用。
数据透露。

最佳做法 :

为特定服务器或托管实例配置 Azure Defender for SQL 。 还可以通过切换到 Azure 安全中心标准层,为订


阅中的所有服务器和托管实例配置 Azure Defender for SQL 。

若要获得完整的调查体验,建议启用 SQL 数据库审核。 使用审核可以跟踪数据库事件,并将这些事件写


入到 Azure 存储帐户或 Azure Log Analytics 工作区中的审核日志。

审 核关 键 安全事件
跟踪数据库事件有助于了解数据库活动。 可以洞察可能指示业务关注点或可疑安全违规的差异与异常。 此措施
还有助于遵守法规标准。

如何 实现 :

启用 SQL 数据库审核或托管实例审核以跟踪数据库事件,并将这些事件写入到 Azure 存储帐户、Log


Analytics 工作区(预览版)或事件中心(预览版)中的审核日志。
可将审核日志写入 Azure 存储帐户、写入 Log Analytics 工作区(供 Azure Monitor 日志使用),或写入事件
中心(供事件中心使用)。 可以将这些选项随意组合起来进行配置,审核日志会写入到每一个之中。

最佳做法 :

在服务器上配置 SQL 数据库审核或配置托管实例审核以审核事件后,该服务器上所有现有的和新建的数据库


都会被审核。
审核策略默认包括对数据库执行的所有操作(查询、存储过程,以及成功和失败的登录),这可能会导致生成大
量的审核日志。 建议客户使用 PowerShell 对不同类型的操作和操作组配置审核。 此项配置有助于控制审核
的操作数量,并将事件丢失的风险降到最低。 自定义审核配置可让客户仅捕获所需的审核数据。
可以在 Azure 门户中直接使用审核日志,或者从配置的存储位置使用。
NOTE
启用在 Log Analytics 中进行审核会根据引入速率产生成本。 请注意,使用此选项会产生相关的成本;或者,可以考虑将审核
日志存储在 Azure 存储帐户中。

其他 资 源 :

SQL 数据库审核
SQL Server 审核
保 护审 核日志
限制对存储帐户的访问,以支持职责分离,并将 DBA 与审核员区分开来。

如何 实现 :

将审核日志保存到 Azure 存储时,请确保按照最低安全原则来限制对存储帐户的访问。 控制谁有权访问存储


帐户。
有关详细信息,请参阅授权访问 Azure 存储。

最佳做法 :

控制对审核目标的访问是将 DBA 与审核员相区分时使用的重要概念。

审核对敏感数据的访问时,请考虑使用数据加密来保护数据,以免向审核员透露信息。 有关详细信息,请
参阅防止未经授权的高特权用户查看使用中的敏感数据部分。

安全管理
本部分介绍有关管理数据库安全态势的各个方面和最佳做法。 其中提供了有关确保根据安全标准配置数据库、
发现漏洞,以及分类和跟踪对数据库中潜在敏感数据的访问的最佳做法。

确保根据安全最佳做法配置数据 库
通过发现并修正潜在数据库漏洞来主动改善数据库的安全性。

如何 实现 :

启用 SQL 漏洞评估 (VA) 来扫描数据库的安全问题,并使其定期对数据库自动运行。

最佳做法 :

对数据库运行首次 VA,在补救不符合安全最佳做法的失败检查后反复运行 VA。 设置可接受配置的基线,


直到扫描结果全部正常,或所有检查均已通过。

将定期的重复扫描配置为每周运行一次,并配置相关人员来接收摘要电子邮件。

完成每周扫描后查看 VA 摘要。 对于发现的任何漏洞,评估与前一次扫描结果的偏差,并确定是否应解决


本次检查发现的问题。 查看配置发生更改是否有合理的原因。

解决检查发现的问题并更新相关的基线。 为解决措施创建票证项,并在解决问题之前跟踪这些项。

其他 资 源 :

SQL 漏洞评估
SQL 漏洞评估服务有助于识别数据库漏洞
识别 并 标记 敏感数据
发现可能包含敏感数据的列。 什么数据是敏感数据在很大程度上取决于客户、合规性规定等,并且需要由负责该
数据的用户进行评估。 将列分类以使用基于敏感性的高级审核和保护方案。
如何 实现 :

使用 SQL 数据发现和分类来发现、分类、标记和保护数据库中的敏感数据。
在 SQL 数据发现和分类仪表板中查看自动发现创建的分类建议。 接受相关的分类,以使用分类标签来
持久标记敏感数据。
对于未被自动机制发现的任何其他敏感数据字段,请手动添加分类。
有关详细信息,请参与 SQL 数据发现和分类。

最佳做法 :

定期监视分类仪表板,准确评估数据库的分类状态。 可以导出或打印有关数据库分类状态的报告,以使在
合规与审核措施中共享。

持续监视 SQL 漏洞评估中建议的敏感数据的状态。 跟踪敏感数据发现规则,识别建议列中的任何分类偏


差。

使用根据你的组织的特定需求定制的方式使用分类。 在 Azure 安全中心的 SQL 信息保护 策略中,自定义


信息保护策略 (敏感度标签、信息类型、发现逻辑) 。

跟踪 对 敏感数据的 访问
在审核日志中监视谁访问了敏感数据,并捕获对敏感数据运行的查询。

如何 实现 :

结合使用 SQL 审核和数据分类。


在 SQL 数据库审核日志中,可以专门跟踪对敏感数据的访问。 还可以查看访问的数据及其敏感性标签
等信息。 有关详细信息,请参阅数据发现和分类和审核对敏感数据的访问。

最佳做法 :

参阅有关审核和数据分类的最佳做法部分:
审核关键安全事件
识别并标记敏感数据

可 视 化安全性与合 规 性状 态
使用统一的基础结构安全管理系统来增强数据中心(包括 SQL 数据库中的数据库)的安全态势。 查看有关数据库
安全性与合规性状态的建议列表。

如何 实现 :

在 Azure 安全中心监视 SQL 相关的安全建议与正在进行的威胁。

常见安全威胁和潜在缓解措施
本部分帮助你找到用于防范特定攻击途径的安全措施。 遵循上述一条或多条安全指导原则预期可以实现大部分
缓解措施。

安全威 胁 :数据透露
Data 透露是指在未经授权的情况下,从计算机或服务器复制、传输或检索数据。 查看维基百科中的数据透露定
义。

通过公共终结点连接到服务器会带来数据透露的风险,因为这需要客户向公共 IP 打开其防火墙。

场景 1 :Azure VM 上的某个应用程序连接到 Azure SQL 数据库中的某个数据库。 恶意行动者获取 VM 的访问权


限并入侵到其中。 在此场景中,数据透露表示使用恶意 VM 的外部实体连接到数据库,复制个人数据,并将这些
数据存储在 Blob 存储中或者不同订阅内的不同 SQL 数据库中。

场景 2 :恶意 DBA。 这种场景通常出现在受管制行业的安全敏感型客户那里。 在此场景中,高特权用户可将


Azure SQL 数据库中的数据复制到不受数据所有者控制的其他订阅。
潜在 缓 解措施 :

Azure SQL 数据库和 SQL 托管实例目前提供以下技术来缓解数据透露威胁:


在 Azure VM 的 NSG 中结合使用“允许”和“拒绝”规则,以控制可从 VM 访问哪些区域。
如果在 SQL 数据库中使用服务器,请设置以下选项:
将“允许 Azure 服务”设置为“关闭”。
设置 VNet 防火墙规则,仅允许来自包含你的 Azure VM 的子网的流量。
使用 专用链接
对于 SQL 托管实例,使用专用 IP 访问默认可以解决恶意 VM 的首要数据透露隐患。 在子网中启用子网委托
功能,以在 SQL 托管实例子网中自动设置最严格的策略。
恶意 DBA 隐患主要出现在 SQL 托管实例上,因为 SQL 托管实例的受攻击面较大,而网络要求对客户是可见
的。 此问题的最佳缓解措施是首先应用本安全指南中的所有做法,以防止出现恶意 DBA 的情景(不仅可以解
决数据透露)。 Always Encrypted 是保护敏感数据的一种方法,它可以加密敏感数据,并使 DBA 无法访问密
钥。

业务连续性和可用性的安全性方面
大多数安全标准在操作连续性方面解决数据可用性问题,实现此效果的方式是实施冗余和故障转移功能来避免
单一故障点。 对于灾难恢复方案,常见的做法是保留数据和日志文件的备份。以下部分概述了 Azure 中内置的功
能。 此外,提供了可根据具体需求进行配置的其他选项:

Azure 提供内置的高可用性:SQL 数据库和 SQL 托管实例的高可用性


“业务关键”层包括故障转移组、完整和差异日志备份,以及默认已启用的时间点还原备份:
自动备份
使用自动数据库备份恢复数据库 - 时间点还原
可以配置其他业务连续性功能,如跨不同 Azure 地域的区域冗余配置和自动故障转移组:

高级 & 业务关键服务层的高可用性区域冗余配置
常规用途服务层的高可用性区域冗余配置
业务连续性概述

后续步骤
参阅 Azure SQL 数据库安全功能概述
Azure 数据库安全性清单
2021/2/9 • • Edit Online

为了帮助提高安全性,Azure 数据库包括大量可用于限制和控制访问的内置安全控件。

其中包括:

防火墙,可用于创建防火墙规则,以便根据IP 地址限制连接,
可从 Azure 门户访问的服务器级防火墙
可从 SSMS 访问的数据库级防火墙规则
使用安全连接字符串保护数据库连接
使用访问管理
数据加密
SQL 数据库审核
SQL 数据库威胁检测

简介
云计算需使用许多应用程序用户、数据库管理员和程序员不熟悉的新安全范例。 由于这个原因,一些组织对于是
否要出于安全风险因素实现云基础结构以进行数据管理犹豫不决。 但是,通过更好地了解 Microsoft Azure 和
Microsoft Azure SQL 数据库中内置的安全功能,可极大减缓这方面的担忧。

清单
查看此清单之前,建议阅读 Azure 数据库安全性最佳做法一文。 了解最佳做法后,便能够充分利用此清单。 然
后,可使用此清单确保解决重要的 Azure 数据库安全性问题。

传输层安全性,用于数据移动到网络时的数据加密。
动态加密/传输中加密 数据库要求来自于客户端的通信是基于 TDS(表格格
式数据流)协议、通过 TLS(传输层安全性)实现的安全
通信。

透明数据加密,适用于非活动数据以任何数字形式和
静态加密 物理方式存储时的情况。

身份验证(Azure Active Directory 身份验证),AD 身份


数据库访问 验证使用 Azure Active Directory 管理的标识。
授权,授予用户必需的最低权限。
行级别安全性(使用安全策略,同时基于用户的标识、
应用程序访问 角色或执行上下文来限制行级别访问)。
动态数据掩码(使用“权限和策略”,通过对非特权用户
模糊化敏感数据来限制此类数据的泄露)

审核跟踪数据库事件,并将事件写入 Azure 存储帐


跟踪和检测 户中的审核日志/活动日志。
使用 Azure Monitor 活动日志跟踪 Azure 数据库运行
状况。
威胁检测会检测异常的数据库活动,指出数据库有潜
在的安全威胁。

数据监视,使用 Azure 安全中心作为 SQL 和其他


Azure 安全中心 Azure 服务的集中式安全监视解决方案。

结论
Azure 数据库是一个可靠的数据库平台,提供满足众多组织要求与合规要求的整套安全功能。 通过控制对数据的
物理访问,结合透明数据加密、单元格级加密或行级别安全性使用各种文件级、列级或行级数据安全选项,可轻
松保护数据。 此外,Always Encrypted 支持针对加密的数据执行操作,简化应用程序更新的过程。 反过来,访问
SQL 数据库活动的审核日志可以提供所需的信息来帮助自己了解何时以何种方法访问了数据。

后续步骤
只需几个简单的步骤,即可大大提升数据库抵御恶意用户或未经授权的访问的能力。 本教程介绍以下内容:

为服务器和/或数据库设置防火墙规则。
通过加密保护数据。
启用 SQL 数据库审核。
适⽤于 Blob 存储的安全建议
2021/2/9 • • Edit Online

本文包含适用于 Blob 存储的安全建议。 实施执行建议将有助于你履行我们的共享职责模型中描述的安全职责。


若要深入了解 Microsoft 如何满足服务提供商的责任,请阅读 云计算的共享责任。

包含在本文中的某些建议可能受 Azure 安全中心的自动监视。 在保护你在 Azure 中的资源方面,Azure 安全中心


是第一道防线。 有关 Azure 安全中心的信息,请参阅 什么是 Azure 安全中心?

Azure 安全中心会定期分析 Azure 资源的安全状态,以识别潜在的安全漏洞。 然后向你提供有关如何解决这些安


全漏洞的建议。 有关 Azure 安全中心建议的详细信息,请参阅 Azure 安全中心的安全性建议。

数据保护

使用 Azure 资源管理器部署模型 使用 Azure 资源管理器部署模型创建新 -


的存储帐户,以用于重要的安全增强功
能,包括高级的 Azure 基于角色的访问
控制 (Azure RBAC) 和审核、基于资源管
理器的部署和治理、托管标识访问权
限、用于存储机密的 Azure Key Vault 访
问权限、用于访问 Azure 存储数据和资
源的基于 Azure AD 的身份验证和授
权。 如果可能,请迁移使用经典部署模
型的现有存储帐户以使用 Azure 资源管
理器。 有关 Azure 资源管理器的详细信
息,请参阅 Azure 资源管理器概述。

为所有存储帐户启用 Azure Defender Azure Defender for Azure 存储提供额 是


外的安全智能层,用于检测访问或利用
存储帐户的异常和潜在有害尝试。 如果
活动发生异常,则会在 Azure 安全中心
触发安全警报,并通过电子邮件发送给
订阅管理员,并详细介绍可疑活动以及
如何调查和修正威胁的建议。 有关详细
信息,请参阅 为 Azure 存储配置 Azure
Defender。

为 Blob 启用软删除 Blob 的软删除使你能够在 blob 数据被 -


删除后恢复它们。 有关 blob 的软删除
的详细信息,请参阅 Azure 存储 blob
的软删除。

为容器启用软删除 容器的软删除使你能够在容器被删除后 -
恢复容器。 有关容器软删除的详细信
息,请参阅 (预览版) 的容器软删除 。

锁定存储帐户以防止意外删除帐户 可以锁定 Azure 资源管理器资源(例如


订阅、资源组或存储帐户),以防止组织
中的其他用户意外删除或修改它。 锁定
存储帐户不会阻止删除该帐户中的数
据。 它仅阻止删除帐户本身。 有关详细
信息,请参阅锁定资源以防止意外更
改。
在不可变 Blob 中存储业务关键数据 配置法定保留和基于时间的保留策略, -
以 WORM(一次写入,多次读取)状态
存储 Blob 数据。 在保留时间间隔期间
内,可以读取即时存储的 Blob,但不能
对其进行修改或删除。 有关详细信息,
请参阅使用不可变的存储来存储业务关
键型 Blob 数据。

需要安全传输 (HTTPS) 到存储帐户 如果需要对存储帐户进行安全传输,则 -


必须通过 HTTPS 进行对存储帐户的所
有请求。 拒绝通过 HTTP 发出的任何请
求。 Microsoft 建议你始终需要对所有
存储帐户进行安全传输。 有关详细信
息,请参阅 要求安全传输以确保安全连
接。

将共享访问签名 (SAS) 令牌限制为仅用 当客户端使用 SAS 令牌访问 Blob 数据 -


于 HTTPS 连接 时要求使用 HTTPS 有助于最大程度地
降低被窃听的风险。 有关详细信息,请
参阅使用共享访问签名 (SAS) 授予对
Azure 存储资源的有限访问权限。

标识和访问管理

使用 Azure Active Directory (Azure 与用于授权对 Blob 存储的请求的共享 -


AD) 授权对 Blob 数据的访问 密钥相比,Azure AD 提供了卓越的安全
性和易用性。 有关详细信息,请参阅使
用 Azure Active Directory 授予对
Azure Blob 和队列的访问权限。

通过 Azure RBAC 向 Azure AD 安全主 将角色分配给用户、组或应用程序时, -


体分配权限时,请记住“最低权限”原则 只向该安全主体授予执行任务所需的权
限。 限制对资源的访问有助于防止意外
和恶意滥用数据。

使用用户委托 SAS 授予客户端对 Blob 用户委托 SAS 使用 Azure Active -


数据的有限访问权限 Directory (Azure AD) 凭据以及为 SAS
指定的权限进行保护。 用户委托 SAS
在其作用域和功能方面类似于服务
SAS,但相对于服务 SAS 具有安全优
势。 有关详细信息,请参阅使用共享访
问签名 (SAS) 授予对 Azure 存储资源的
有限访问权限。

使用 Azure Key Vault 保护帐户访问密 Microsoft 建议使用 Azure AD 对 Azure -


钥 存储的请求进行授权。 但是,如果必须
使用共享密钥授权,请使用 Azure Key
Vault 保护帐户密钥。 可以在运行时从
密钥保管库检索密钥,而不是将其与应
用程序一起保存。 有关 Azure Key Vault
的详细信息,请参阅 Azure Key Vault 概
述。
定期重新生成帐户密钥 定期轮换帐户密钥可以降低向恶意参与 -
者公开数据的风险。

不允许共享密钥授权 如果你不允许对存储帐户进行共享密钥 -
授权,Azure 存储将拒绝对该帐户的所
有后续请求,这些请求使用帐户访问密
钥获得授权。 仅授权有 Azure AD 的安
全请求将会成功。 有关详细信息,请参
阅 阻止对 Azure 存储帐户进行共享密
钥授权。

向 SAS 分配权限时,请记住最低权限原 创建 SAS 时,请仅指定客户端执行其功 -


则 能所需的权限。 限制对资源的访问有助
于防止意外和恶意滥用数据。

为发布给客户端的任何 SAS 制定吊销 如果 SAS 遭到泄露,需要尽快撤销该 -


计划 SAS。 要撤销用户委托 SAS,请撤销用
户委托密钥,以使与该密钥关联的所有
签名快速失效。 要撤销与存储的访问策
略关联的服务 SAS,可以删除存储的访
问策略,重命名策略或将其到期时间更
改为过去的时间。 有关详细信息,请参
阅使用共享访问签名 (SAS) 授予对
Azure 存储资源的有限访问权限。

如果服务 SAS 与存储的访问策略没有 无法撤销与存储的访问策略没有关联的 -


关联,请将到期时间设置为一小时或更 服务 SAS。 因此,建议限制到期时间,
短 以使 SAS 的有效时间不超过一小时。

禁止对容器和 Blob 的匿名公共读取访 对容器及其 Blob 的匿名公共读取访问 -


问 权限向任何客户端授予对这些资源的只
读访问权限。 除非方案需要,否则请避
免启用公共读取访问权限。 若要了解如
何禁止对存储帐户进行匿名公共访问,
请参阅配置对容器和 blob 的匿名公共
读取访问。

网络

为存储帐户配置所需的传输层安全性 要求客户端使用更安全的 TLS 版本来对 -


(TLS) 最低版本。 Azure 存储帐户发出请求,具体方式是
为该帐户配置最低的 TLS 版本。 有关详
细信息,请参阅为存储帐户配置所需的
传输层安全性 (TLS) 最低版本

在所有存储帐户中启用“需要安全传 启用“需要安全传输”选项时,对存储帐 是
输”选项 户发出的所有请求都必须通过安全连接
进行。 通过 HTTP 发出的任何请求都将
失败。 有关详细信息,请参阅在 Azure
存储中要求安全传输。
启用防火墙规则 配置防火墙规则以将存储帐户的访问权 -
限限制于源自指定的 IP 地址或范围,或
源自 Azure 虚拟网络 (VNet) 中一系列
子网的请求。 有关配置防火墙规则的详
细信息,请参阅配置 Azure 存储防火墙
和虚拟网络。

允许受信任的 Microsoft 服务访问此存 默认情况下,除非请求源自在 Azure 虚 -


储帐户 拟网络 (VNet) 中运行的服务或者源自
允许的公共 IP 地址,否则启用存储帐户
的防火墙规则会阻止数据传入请求。 被
阻止的请求包括来自其他 Azure 服务、
来自 Azure 门户、来自日志记录和指标
服务等的请求。 可以通过添加例外,允
许受信任的 Microsoft 服务访问此存储
帐户,从而允许来自其他 Azure 服务的
请求。 若要详细了解如何为受信任的
Microsoft 服务添加例外,请参阅配置
Azure 存储防火墙和虚拟网络。

使用专用终结点 专用终结点将 Azure 虚拟网络 (VNet) -


中的专用 IP 地址分配给存储帐户。 它
通过专用链接保护 VNet 和存储帐户之
间的所有流量。 有关专用终结点的详细
信息,请参阅 使用 Azure 专用终结点将
专用连接到存储帐户。

使用 VNet 服务标记 服务标记代表给定 Azure 服务中的一组 -


IP 地址前缀。 Microsoft 会管理服务标
记包含的地址前缀,并会在地址发生更
改时自动更新服务标记。 有关 Azure 存
储支持的服务标记的详细信息,请参阅
Azure 服务标记概述。 有关演示如何使
用服务标记创建出站网络规则的教程,
请参阅限制对 PaaS 资源的访问。

限制对特定网络的网络访问 将网络访问限制为托管需要访问的客户 是
端的网络可减少你的资源受到网络攻击
的风险。

配置网络路由首选项 你可以为 Azure 存储帐户配置网络路由 -


首选项,以指定如何使用 Microsoft 全
局网络或 Internet 路由将网络流量从客
户端路由到你的帐户。 有关详细信息,
请参阅 配置 Azure 存储的网络路由首
选项。

日志记录/监视
跟踪请求的授权方式 启用 Azure 存储日志记录以跟踪对 -
Azure 存储发出的每个请求的授权方
式。 日志可指示请求是匿名提出的,还
是使用 OAuth 2.0 令牌、共享密钥或共
享访问签名 (SAS) 提出的。 有关详细信
息,请参阅通过 Azure Monitor 监视
Azure Blob 存储或采用经典监视的
Azure 存储分析日志记录。

在 Azure Monitor 中设置警报 配置日志警报,以便按设置的频率评估 -


资源日志,并根据结果触发警报。 有关
详细信息,请参阅 Azure Monitor 中的
日志警报。

后续步骤
Azure 安全文档
安全开发文档。
Microsoft Azure 客户密码箱
2021/2/9 • • Edit Online

NOTE
若要使用此功能,你的组织必须具有最小 级别的 Azure 支持计划。

Microsoft Azure 客户密码箱提供一个界面供客户查看和批准/拒绝客户数据访问请求。 当 Microsoft 工程师需要


在支持请求期间访问客户数据时,可以使用此功能。

本文介绍如何启动、跟踪和存储客户密码箱请求,以便以后查看和审核。

客户密码箱现已正式发布,当前支持对虚拟机进行远程桌面访问。

预览版中支持的服务和方案
客户密码箱预览版当前支持以下服务:

API 管理
Azure 应用服务
认知服务
容器注册表
Azure Database for MySQL
Azure Databricks
Azure Data Box
Azure 数据资源管理器
Azure 数据工厂
Azure Database for PostgreSQL
Azure Functions
HDInsight
Azure Kubernetes 服务
Azure Monitor
Azure 存储
Azure SQL DB
Azure 订阅传输
Azure Synapse Analytics
虚拟机(现在还包括对内存转储和托管磁盘的访问)

若要为组织的这些预览版提供客户密码箱,请注册 Azure 公共预览版客户密码箱。

公开上市中支持的服务和方案
以下服务和方案目前在客户密码箱公开上市。

对 虚 拟 机的 远 程桌面 访问
客户密码箱现当前支持对虚拟机的远程桌面访问请求。 支持以下工作负载:

平台即服务 (PaaS) - Azure 云服务(Web 角色和辅助角色)


基础结构即服务 (IaaS) - Windows 和 Linux (仅限 Azure 资源管理器)
虚拟机规模集 - Windows 和 Linux

NOTE
客户密码箱不支持 IaaS 经典实例。 如果你的工作负荷在 IaaS 经典实例上运行,我们建议你将其从经典部署模型迁移到资
源管理器部署模型。 有关说明,请参阅平台支持的从经典部署模型到 Azure 资源管理器部署模型的 IaaS 资源迁移概述。

详细审 核日志

对于涉及远程桌面访问的方案,可以使用 Windows 事件日志来查看 Microsoft 工程师执行的操作。 请考虑使用


Azure 安全中心收集事件日志,并将数据复制到工作区进行分析。 有关详细信息,请参阅 Azure 安全中心的数据
收集。

工作流
以下步骤概述了客户密码箱请求的典型工作流。

1. 组织中的某人对其 Azure 工作负荷有问题。

2. 在此人员对问题进行故障排除但无法修复后,他们将从 Azure 门户中打开支持票证。 票证分配给 Azure


客户支持工程师。

3. Azure 支持工程师会查看服务请求,并确定解决此问题的后续步骤。
4. 如果支持工程师无法通过使用标准工具和遥测对问题进行故障排除,则下一步是通过使用实时 (JIT)
access 服务请求提升的权限。 此请求可以来自原始支持工程师。 或者,它可以来自不同的工程师,因为此
问题已上报给 Azure DevOps 团队。

5. Azure 工程师提交访问请求后,实时服务会评估请求,其中包括以下因素:
资源的范围
请求者是隔离标识还是使用多重身份验证
权限级别
此请求还可以基于 JIT 规则,包括来自内部 Microsoft 审批者的批准。 例如,审批者可以是客户支持主管
或 DevOps 经理。

6. 当请求需要直接访问客户数据时,将启动客户密码箱请求。 例如,对客户的虚拟机的远程桌面访问。

请求现在处于 客 户 通知 状态,在授予访问权限前等待客户的批准。

7. 在客户组织中,拥有 Azure 订阅的 所有者角色 的用户将收到来自 Microsoft 的电子邮件,通知他们有关挂


起的访问请求。 对于客户密码箱请求,此人为指定的审批者。

示例电子邮件:
8. 电子邮件通知提供 Azure 门户中 客 户 密 码 箱 边栏选项卡的链接。 使用此链接,指定的审批者可以登录到
Azure 门户,查看其组织为客户密码箱所做的任何挂起的请求:
请求在客户队列中保留四天。 此时间过后,访问请求会自动过期,并且不会向 Microsoft 工程师授予任何
访问权限。

9. 若要获取待定请求的详细信息,指定的审批者可以从 挂起的 请 求 中选择密码箱请求:

10. 指定的审批者还可以选择 服 务请 求 ID ,以查看原始用户创建的支持票证请求。 此信息提供了有关


Microsoft 支持部门的原因以及所报告问题的历史记录的上下文。 例如:

11. 查看请求后,指定的审批者选择 " 批准 " 或 " 拒 绝 ":


作为所选内容的结果:

批准 :向 Microsoft 工程师授予访问权限。 在八小时的默认期限内授予访问权限。


拒 绝 : Microsoft 工程师的提升访问请求被拒绝,无需执行其他操作。

出于审核目的,在此工作流中执行的操作记录在 客户密码箱请求日志中。

审核日志
客户密码箱日志存储在活动日志中。 在 Azure 门户中,选择 " 活 动 日志 " 以查看与客户密码箱请求相关的审核
信息。 可以筛选特定操作,例如:

拒绝密码箱请求
创 建密 码 箱 请 求
批准密 码 箱 请 求
密码箱请求过期

示例:

客户密码箱与 Azure 安全性基准的集成


我们引入了新的基线控件 (3.13) Azure 安全基准,其中包含客户密码箱适用性。 客户现在可以利用基准来查看服
务客户密码箱适用性。

排除项
在以下工程支持情况中不会触发客户密码箱请求:

Microsoft 工程师需要执行超出标准操作过程范围的活动。 例如,在意外或不可预测的情况下恢复或还原


服务。

Microsoft 工程师在故障排除过程中访问 Azure 平台,并且无意中有权访问客户数据。 例如,Azure 网络团


队会执行故障排除,导致在网络设备上捕获数据包。 但是,如果客户在传输数据时对数据进行了加密,则
工程师无法读取该数据。

后续步骤
对于具有最小 开 发 人 员 的 Azure 支持计划的所有客户,客户密码箱自动提供。

如果你具有符合条件的支持计划,则无需执行任何操作即可启用客户密码箱。 如果需要执行此操作来处理从组
织中的某个人中存档的支持票证,则客户密码箱请求将由 Microsoft 工程师发起。
适⽤于 Microsoft Azure 的客户密码箱的 Azure 安
全基线
2021/2/9 • • Edit Online

适用于 Microsoft Azure 的客户密码箱的 Azure 安全基线包含有助于改进部署安全状况的建议。

此服务的基线摘自 Azure 安全基准版本 1.0 ,其中提供了有关如何根据我们的最佳做法指导保护 Azure 上的云解


决方案的建议。

有关详细信息,请参阅 Azure 安全基线概述。

网络安全
有关详细信息,请参阅安全控制:网络安全。

1.1:在虚 拟 网 络 中使用网 络 安全 组 或 Azure 防火 墙 保 护资 源


指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.2: 监视 和 记录 VNet、子网和 NIC 的配置与流量


指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.3:保 护 关 键 Web 应 用程序


指 导 :不适用;此建议适用于 Azure 应用服务或计算资源上运行的 Web 应用程序。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.4:拒 绝 与已知 恶 意的 IP 地址 进 行通信


指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.5: 记录 网 络 数据包和流日志
指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.6:部署基于网 络 的入侵 检测 /入侵防 护 系 统 (IDS/IPS )


指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.7:管理 发 往 Web 应 用程序的流量


指 导 :不适用;此建议适用于 Azure 应用服务或计算资源上运行的 Web 应用程序。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.8:最大程度地降低网 络 安全 规则 的复 杂 性和管理开 销
指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.9: 维护 网 络设备 的 标 准安全配置


指南 :不适用;不能将虚拟网络、子网或网络安全组与 Azure 客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.10: 阐 述流量配置 规则
指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。

Azure 安全中心 监视 :不适用


责 任 :不适用

1.11:使用自 动 化工具来 监视 网 络资 源配置和 检测 更改


指南 :不适用;不能将虚拟网络、子网或网络安全组与客户密码箱相关联。 没有要建立或监视的网络配置。

Azure 安全中心 监视 :不适用


责 任 :不适用

日志记录和监视
有关详细信息,请参阅安全控制:日志记录和监视。

2.1:使用批准的 时间 同步源
指南 :不适用;Microsoft 维护用于客户密码箱资源的时间源。

Azure 安全中心 监视 :不适用


责 任 :不适用

2.2:配置中心安全日志管理
指南 :在 Azure 活动日志中自动启用和维护客户密码箱审核日志。 你可以通过将数据从 Azure 活动日志流式传
输到日志分析工作区来查看此数据,然后,你可以在该工作区中执行研究和分析。

将客户密码箱生成的活动日志载入 Azure Sentinel 或其他 SIEM,以实现中心日志聚合和管理。

客户密码箱的审核日志

如何加入 Azure Sentinel

Azure 安全中心 监视 :是
责 任 :客户
2.3: 为 Azure 资 源启用 审 核日志 记录
指南 :在 Azure 活动日志中自动启用和维护客户密码箱审核日志。 你可以通过将数据从 Azure 活动日志流式传
输到日志分析工作区来查看此数据,然后,你可以在该工作区中执行研究和分析。

客户密码箱的审核日志

如何加入 Azure Sentinel

Azure 安全中心 监视 :是
责 任 :客户

2.4:从操作系 统 收集安全日志
指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

2.5:配置安全日志存 储 保留期
指南 :在 Azure Monitor 中,根据组织的符合性规定,设置与客户密码箱关联 Log Analytics 工作区的日志保持
期。

如何设置日志保留参数

Azure 安全中心 监视 :不适用


责 任 :客户

2.6: 监视 和 审查 日志
指南 :在 Azure 活动日志中自动启用和维护客户密码箱审核日志。 你可以通过将数据从 Azure 活动日志流式传
输到日志分析工作区来查看此数据,然后,你可以在该工作区中执行研究和分析。 分析和监视来自你的客户密码
箱请求异常行为的日志。 使用 Azure Sentinel 工作区中的 "日志" 部分来执行查询,或根据客户密码箱日志创建
警报。

客户密码箱中的审核日志

Azure 安全中心 监视 :不适用


责 任 :客户

2.7: 针对 异常活 动 启用警 报


指南 :在 Azure 活动日志中自动启用和维护客户密码箱审核日志。 你可以通过将数据从 Azure 活动日志流式传
输到日志分析工作区来查看此数据,然后,你可以在该工作区中执行研究和分析。 分析和监视来自你的客户密码
箱请求异常行为的日志。 使用 Azure Sentinel 工作区中的 "日志" 部分来执行查询,或根据客户密码箱日志创建
警报。

客户密码箱中的审核日志

如何针对 Log Analytics 日志数据发出警报

Azure 安全中心 监视 :是
责 任 :客户

2.8:集中管理反 恶 意 软 件日志 记录
指南 :不适用;客户密码箱不会处理或产生与反恶意软件相关的日志。

Azure 安全中心 监视 :不适用


责 任 :不适用
2.9:启用 DNS 查询 日志 记录
指南 :不适用;客户密码箱不会处理或产生与 DNS 相关的日志。

Azure 安全中心 监视 :不适用


责 任 :不适用

2.10:启用命令行 审 核日志 记录
指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

标识和访问控制
有关详细信息,请参阅安全控制:标识和访问控制。

3.1: 维护 管理 帐户 的清 单
指南 :维护对你的客户密码箱请求具有管理访问权限的用户帐户的清单。 可以在 Azure 门户中为你的订阅使
用“标识和访问控制(IAM)”窗格来配置 Azure 基于角色的访问控制 (Azure RBAC)。 这些角色将应用于 Azure
Active Directory 中的用户、组、服务主体和管理标识。
在客户组织中,拥有 Azure 订阅的所有者角色的用户将收到来自 Microsoft 的电子邮件,通知他们有任何挂起的
访问请求。 对于客户密码箱请求,此人为指定的审批者。

了解自定义角色

如何为工作簿配置 Azure RBAC

了解客户密码箱中的访问请求权限

Azure 安全中心 监视 :是
责 任 :客户

3.2:在适用的情况下更改默 认 密 码
指 导 :Azure Active Directory 没有默认密码的概念。 其他需要密码的 Azure 资源会强制创建具有复杂性要求和
最小密码长度的密码,该长度因服务而异。 你对可能使用默认密码的第三方应用程序和市场服务负责。

Azure 安全中心 监视 :不适用


责 任 :客户

3.3:使用 专 用管理 帐户
指南 :围绕专用管理帐户的使用创建标准操作程序。 使用 Azure 安全中心标识和访问管理来监视管理帐户的数
量。

此外,为了帮助你跟踪专用管理帐户,你可以使用 Azure 安全中心或内置 Azure 策略中的建议,例如:

应该为你的订阅分配了多个所有者
应从订阅中删除拥有所有者权限的已弃用帐户
应从订阅中删除拥有所有者权限的外部帐户

如何使用 Azure 安全中心监视标识和访问(预览)

如何使用 Azure Policy

Azure 安全中心 监视 :是
责 任 :客户

3.4:将 单 一登 录 (SSO ) 与 Azure Active Directory 配合使用


指南 :不适用;对客户密码箱的访问是通过 Azure 门户并为具有所有者的租户角色的帐户保留的。 不支持单一登
录。

Azure 安全中心 监视 :不适用


责 任 :客户

3.5: 对 所有基于 Azure Active Directory 的 访问 使用多重身份 验证


指 导 :启用 Azure Active Directory 多重身份验证,并遵循 Azure 安全中心标识和访问管理的建议。

如何在 Azure 中启用 MFA

如何在 Azure 安全中心监视标识和访问

Azure 安全中心 监视 :是
责 任 :客户

3.6: 对 所有管理任 务 使用 专 用 计 算机(特 权访问 工作站)


指南 :将特权访问工作站 (PAW) 与 Azure AD 多重身份验证 (MFA) 一起使用,以便登录和配置客户密码箱请求。

特权访问工作站

规划基于云的 Azure AD 多重身份验证部署

Azure 安全中心 监视 :不适用


责 任 :客户

3.7: 记录 来自管理 帐户 的可疑活 动 并 对 其 发 出警 报


指南 :在环境中发生可疑或不安全活动时,使用 AZURE ACTIVE DIRECTORY PRIVILEGED IDENTITY
MANAGEMENT (PIM) 生成日志和警报。
此外,使用 Azure Active Directory 风险检测来查看警报和报告有风险的用户行为。

如何部署 Privileged Identity Management (PIM)

了解 Azure AD 风险检测

Azure 安全中心 监视 :是
责 任 :客户

3.8: 仅 从批准的位置管理 Azure 资 源


指南 :使用条件访问命名位置,以仅允许从 IP 地址范围或国家/地区的特定逻辑分组访问 Azure 门户。

如何在 Azure 中配置命名位置

Azure 安全中心 监视 :不适用


责 任 :客户

3.9:使用 Azure Active Directory


指南 :使用 Azure Active Directory 作为中心身份验证和授权系统(如果适用)。 Azure Active Directory 通过对静
态数据和传输中的数据使用强加密来保护数据。 还 Azure Active Directory salts、哈希和安全存储用户凭据。

如何创建和配置 Azure Active Directory 实例

Azure 安全中心 监视 :不适用


责 任 :客户

3.10:定期 审查 和 协调 用 户访问
指南 : Azure Active Directory 提供有助于发现陈旧帐户的日志。 此外,还可以使用 Azure Active Directory 访问
评审来有效地管理组成员身份、访问企业应用程序和角色分配。 可以定期评审用户的访问权限,确保只有适当的
用户才持续拥有访问权限。

了解 Azure Active Directory 报告

如何使用 Azure Active Directory 访问评审

Azure 安全中心 监视 :是
责 任 :客户

3.11: 监视尝试访问 已停用 帐户 的行 为


指南 :使用 Azure Active Directory 作为中心身份验证和授权系统(如果适用)。 Azure Active Directory 通过对静
态数据和传输中的数据使用强加密来保护数据。 还 Azure Active Directory salts、哈希和安全存储用户凭据。

你有权访问 Azure Active Directory 登录活动、审核和风险事件日志源,从而允许你与 Azure Sentinel 或第三方


SIEM 集成。
可以通过创建 Azure Active Directory 用户帐户的诊断设置并将审核日志和登录日志发送到 Log Analytics 工作区
来简化此过程。 可以在 Log Analytics 中配置所需的日志警报。

如何将 Azure 活动日志集成到 Azure Monitor 中

如何加入 Azure Sentinel

Azure 安全中心 监视 :不适用


责 任 :客户

3.12: 针对帐户 登 录 行 为 偏差 发 出警 报
指南 :对于控制平面上的帐户登录行为偏差 (例如 Azure 门户) ,请使用 Azure Active Directory 的标识保护和风
险检测功能来配置对检测到的与用户标识相关的可疑操作的自动响应。 还可将数据引入 Azure Sentinel 以做进
一步调查。

如何查看 Azure Active Directory 有风险的登录

如何配置和启用 identity protection 风险策略

如何加入 Azure Sentinel

Azure 安全中心 监视 :目前不可用


责 任 :客户

3.13:在支持 场 合下 为 Microsoft 提供 对 相关客 户 数据的 访问权 限


指南 :此建议不适用于客户密码箱。

Azure 安全中心 监视 :不适用


责 任 :不适用

数据保护
有关详细信息,请参阅安全控制:数据保护。

4.1: 维护 敏感信息的清 单
指南 :此建议不适用于;客户密码箱不支持标记。
Azure 安全中心 监视 :不适用
责 任 :不适用

4.2:隔离存 储 或 处 理敏感信息的系 统
指南 :不适用;将在你要授予访问权限的资源所在的同一订阅中设置客户密码箱。 没有要保护或隔离的公共终结
点。 向在租户级别持有所有者角色的用户授予客户密码箱请求访问权限。

了解客户密码箱工作流

Azure 安全中心 监视 :不适用


责 任 :不适用

4.3: 监视 和阻止未 经 授 权 的敏感信息 传输


指南 : Microsoft 管理客户密码箱的底层基础结构,并实施了严格控制以防止客户数据丢失或泄露。

了解 Azure 中的客户数据保护

Azure 安全中心 监视 :不适用


责 任 :Microsoft

4.4:加密 传输 中的所有敏感信息
指南 :默认情况下,在云服务和客户之间传输数据时,Microsoft 使用 (TLS) 协议的传输层安全性来保护数据。
Microsoft 的数据中心与连接到 Azure 服务的客户端系统协商建立 TLS 连接。 TLS 提供严格的身份验证,消息隐
私性和完整性强(允许检测消息篡改、拦截和伪造),具有良好的互操作性,算法灵活,易于部署和使用。

了解 Azure 传输中的加密

Azure 安全中心 监视 :目前不可用


责 任 :Microsoft

4.5:使用有效的 发现 工具 识别 敏感数据
指南 :不适用;客户密码箱本身不包含任何客户数据。

Azure 安全中心 监视 :不适用


责 任 :不适用

4.6:使用 Azure RBAC 控制 对资 源的 访问


指南 :向在租户级别拥有 "所有者" 角色的用户授予客户密码箱请求批准。

了解客户密码箱工作流

Azure 安全中心 监视 :不适用


责 任 :客户

4.7:使用基于主机的数据 丢 失防 护 来 强 制 实 施 访问 控制
指南 :不适用;此建议适用于计算资源。 Microsoft 管理客户密码箱的底层基础结构,并实施了严格控制来防止客
户数据丢失或泄露。

Azure 客户数据保护
Azure 安全中心 监视 :不适用
责 任 :不适用

4.8:静 态 加密敏感信息
指南 :不适用;客户密码箱本身不包含客户数据。

Azure 安全中心 监视 :不适用


责 任 :不适用

4.9: 记录对 关 键 Azure 资 源的更改并 对 此 类 更改 发 出警 报


指南 :在 Azure 活动日志中自动启用和维护客户密码箱审核日志。 使用 Azure 活动日志监视和检测对 Azure 客
户密码箱资源所做的更改。 在 Azure Monitor 中创建当关键资源发生更改时触发的警报。

如何在客户密码箱中启用审核

如何查看和检索 Azure 活动日志事件

如何在 Azure Monitor 中创建警报

Azure 安全中心 监视 :是
责 任 :客户

漏洞管理
有关详细信息,请参阅安全控制:漏洞管理。

5.1:运行自 动 漏洞 扫 描工具
指南 :不适用;Microsoft 对支持客户密码箱的基础系统执行漏洞管理。

Azure 安全中心 监视 :不适用


责 任 :Microsoft

5.2:部署自 动 操作系 统 修 补 管理解决方案


指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

5.3:部署第三方自 动软 件修 补 管理解决方案
指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

5.4:比 较连续进 行的漏洞 扫 描


指南 :不适用;Microsoft 对支持客户密码箱的基础系统执行漏洞管理。

Azure 安全中心 监视 :不适用


责 任 :不适用

5.5:使用 风险评级过 程来确定已 发现 漏洞的修正措施的 优 先 级


指南 :不适用;Microsoft 对支持客户密码箱的基础系统执行漏洞管理。

Azure 安全中心 监视 :不适用


责 任 :不适用

库存和资产管理
有关详细信息,请参阅安全控制:清单和资产管理。

6.1:使用 Azure 资产发现


指 导 :使用 Azure Resource Graph 查询/发现订阅中的所有资源(例如计算、存储、网络、端口和协议等)。 确保租
户中具有适当的(读取)权限,并枚举所有 Azure 订阅以及订阅中的资源。

尽管可以通过 Azure 资源图发现经典 Azure 资源,但强烈建议你创建和使用 Azure 资源管理器资源。

如何使用 Azure Resource Graph 创建查询

如何查看 Azure 订阅

了解 azure RBAC) 的 Azure 基于角色的访问控制 (

Azure 安全中心 监视 :不适用


责 任 :客户

6.2: 维护资产 元数据


指南 :客户密码箱不支持标记。

Azure 安全中心 监视 :不适用


责 任 :不适用

6.3: 删 除未 经 授 权 的 Azure 资 源
指南 :在适用的情况下,请使用标记、管理组和单独的订阅来组织和跟踪 Azure 资产。 定期核对清单,确保及时
地从订阅中删除未经授权的资源。

此外,在 Azure Policy 中使用以下内置策略定义,对可以在客户订阅中创建的资源类型施加限制:

不允许的资源类型
允许的资源类型

如何创建其他 Azure 订阅

如何创建管理组

如何创建和使用标记

Azure 安全中心 监视 :不适用


责 任 :客户

6.4: 维护 已批准的 Azure 资 源和 软 件 标题 的清 单


指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

6.5: 监视 未批准的 Azure 资 源


指 导 :使用 Azure Policy 对可以在订阅中创建的资源类型施加限制。

使用 Azure Resource Graph 查询/发现订阅中的资源。 确保环境中的所有 Azure 资源均已获得批准。

如何配置和管理 Azure Policy

如何使用 Azure Resource Graph 创建查询

Azure 安全中心 监视 :不适用


责 任 :客户

6.6: 监视计 算 资 源中未批准的 软 件 应 用程序


指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

6.7: 删 除未批准的 Azure 资 源和 软 件 应 用程序


指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

6.8: 仅 使用已批准的 应 用程序


指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

6.9: 仅 使用已批准的 Azure 服 务


指南 :在 Azure Policy 中使用以下内置策略定义,对可以在你的订阅中创建的资源类型施加限制:

不允许的资源类型
允许的资源类型

如何配置和管理 Azure Policy

如何使用 Azure Policy 拒绝特定的资源类型

Azure 安全中心 监视 :不适用


责 任 :客户

6.10: 实 施已批准的 应 用程序列表


指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

6.11:限制用 户 通 过 脚本与 Azure 资 源管理器 进 行交互的功能


指南 :配置 Azure 条件访问,使其通过为“Microsoft Azure 管理”应用配置“阻止访问”,来限制用户与 Azure 资源
管理器进行交互的能力。

如何配置条件访问以阻止访问 Azure 资源管理器

Azure 安全中心 监视 :不适用


责 任 :客户

6.12:限制用 户 在 计 算 资 源中 执 行脚本的功能
指南 :不适用;此建议适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

6.13:以物理或 逻辑 方式隔离高 风险应 用程序


指 导 :不适用;此建议适用于 Azure 应用服务或计算资源上运行的 Web 应用程序。

Azure 安全中心 监视 :不适用


责 任 :不适用

安全配置
有关详细信息,请参阅安全控制:安全配置。

7.1: 为 所有 Azure 资 源建立安全配置


指南 :不适用,客户密码箱没有可配置的安全设置。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.2:建立安全的操作系 统 配置
指 导 :不适用;此项指导适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.3: 维护 安全的 Azure 资 源配置


指南 :不适用,客户密码箱没有可配置的安全设置。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.4: 维护 安全的操作系 统 配置
指 导 :不适用;此项指导适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.5:安全存 储 Azure 资 源的配置


指南 :不适用;客户密码箱没有可配置的安全设置。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.6:安全存 储 自定 义 操作系 统 映像
指 导 :不适用;此项指导适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.7:部署系 统 配置管理工具
指南 :不适用;客户密码箱没有可配置的安全设置。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.8: 为 操作系 统 部署系 统 配置管理工具


指 导 :不适用;此项指导适用于计算资源。
Azure 安全中心 监视 :不适用
责 任 :不适用

7.9: 为 Azure 服 务实 施自 动 配置 监视
指南 :不适用;客户密码箱没有可配置的安全设置。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.10: 为 操作系 统实 施自 动 配置 监视
指 导 :不适用;此项指导适用于计算资源。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.11:安全管理 Azure 机密
指南 :不适用;对客户密码箱请求的访问仅限于容纳资源的 Azure 订阅的所有者。 无需密码、机密或密钥即可访问
以租户所有者身份登录的客户密码箱。

Azure 安全中心 监视 :不适用


责 任 :不适用

7.12:安全自 动 管理 标识
指南 :不适用;客户密码箱不使用托管标识。

支持托管标识的 Azure 服务

Azure 安全中心 监视 :不适用


责 任 :不适用

7.13:消除意外的凭据透露
指南 :实施凭据扫描程序来识别代码中的凭据。 凭据扫描程序还会建议将发现的凭据转移到更安全的位置,例如
Azure Key Vault。
如何设置凭据扫描程序

Azure 安全中心 监视 :不适用


责 任 :客户

恶意软件防护
有关详细信息,请参阅安全控制:恶意软件防护。

8.1:使用集中管理的反 恶 意 软 件
指 导 :不适用;此项指导适用于计算资源。 支持客户密码箱解决方案的底层主机上启用了 Microsoft 反恶意软件。

Azure 安全中心 监视 :不适用


责 任 :不适用

8.2: 预 先 扫 描要上 传 到非 计 算 Azure 资 源的文件


指南 :在支持 Azure 服务的基础主机(如客户密码箱)上启用了 Microsoft 反恶意软件。

你需要负责预先扫描要上传到非计算 Azure 资源的任何内容。 Microsoft 无法访问客户数据,因此无法代表你对


客户内容执行反恶意软件扫描。
Azure 安全中心 监视 :不适用
责 任 :客户

步骤 8.3:确保反 恶 意 软 件和 签 名已更新
指南 :不适用;此建议适用于计算资源。 在支持 Azure 服务的底层主机上已启用 Microsoft Antimalware,但是,
该软件不会针对客户内容运行。

Azure 安全中心 监视 :不适用


责 任 :不适用

数据恢复
有关详细信息,请参阅安全控制:数据恢复。

9.1:确保定期 执 行自 动备 份
指南 :不适用;客户密码箱本身不存储客户数据。

Azure 安全中心 监视 :不适用


责 任 :不适用

9.2: 执 行完整系 统备 份,并 备 份客 户 管理的所有密 钥


指南 :不适用;客户密码箱本身不存储客户数据。

Azure 安全中心 监视 :不适用


责 任 :不适用

9.3: 验证 所有 备 份,包括客 户 管理的密 钥


指南 :不适用;客户密码箱本身不存储客户数据。

Azure 安全中心 监视 :不适用


责 任 :不适用

9.4:确保保 护备 份和客 户 管理的密 钥


指南 :不适用;客户密码箱本身不存储客户数据,也不会使用密钥或密码进行访问。

Azure 安全中心 监视 :不适用


责 任 :不适用

事件响应
有关详细信息,请参阅安全控制:事件响应。

10.1: 创 建事件响 应 指 导
指南 :为组织制定事件响应指南。 确保在书面的事件响应计划中定义人员职责,以及事件处理/管理从检测到事
件后审查的各个阶段。

如何在 Azure 安全中心配置工作流自动化

关于建立自己的安全事件响应流程的指南

Microsoft 安全响应中心事件分析
客户还可以利用 NIST 的“计算机安全事件处理指南”来制定他们自己的事件响应计划

Azure 安全中心 监视 :不适用


责 任 :客户

10.2: 创 建事件 评 分和 优 先 级设 定 过 程
指 导 :安全中心为每条警报分配严重性,以帮助你优先处理应该最先调查的警报。 严重性取决于安全中心在发出
警报时所依据的检测结果和分析结果的置信度,以及导致发出警报的活动的恶意企图的置信度。

此外,请明确标记订阅(例如 生产、非生产),并创建命名系统来对 Azure 资源进行明确标识和分类。

Azure 安全中心 监视 :是
责 任 :客户

10.3: 测试 安全响 应过 程
指 导 :定期执行演练来测试系统的事件响应功能。 识别弱点和差距,并根据需要修改计划。

请参阅 NIST 的刊物:Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities(IT 规划和功
能的测试、培训与演练计划指南)

Azure 安全中心 监视 :不适用


责 任 :客户

10.4:提供安全事件 联 系人 详细 信息,并 针对 安全事件配置警 报 通知


指南 :如果 Microsoft 安全响应中心 (MSRC) 发现非法或未经授权的某方访问了客户的数据,Microsoft 将使用安
全事件联系人信息与你取得联系。 事后审查事件,确保问题得到解决。

如何设置 Azure 安全中心安全联系人

Azure 安全中心 监视 :是
责 任 :客户

10.5:将安全警 报 整合到事件响 应 系 统 中
指 导 :使用连续导出功能导出 Azure 安全中心警报和建议。 使用连续导出可以手动导出或者持续导出警报和建
议。 可以使用 Azure 安全中心数据连接器将警报流式传输到 Azure Sentinel。

如何配置连续导出

如何将警报流式传输到 Azure Sentinel

Azure 安全中心 监视 :不适用


责 任 :客户

10.6:自 动 响 应 安全警 报
指 导 :使用 Azure 安全中心内的工作流自动化功能可以通过“逻辑应用”针对安全警报和建议自动触发响应。

如何配置工作流自动化和逻辑应用

Azure 安全中心 监视 :不适用


责 任 :客户

渗透测试和红队练习
有关详细信息,请参阅安全控制:渗透测试和红队演练。

11.1:定期 对 Azure 资 源 执 行渗透 测试 ,确保在 60 天内修正所有 发现 的关 键 安全 问题


指导:

请遵循 Microsoft 互动规则,确保你的渗透测试不违反 Microsoft 政策


可在此处详细了解如何针对 Microsoft 托管云基础结构、服务和应用程序执行红队测试和实时站点渗透测
试,以及 Microsoft 的相关策略

Azure 安全中心 监视 :不适用


责 任 :共享

后续步骤
请参阅 Azure 安全基准
详细了解 Azure 安全基线
保护 PaaS 部署
2021/2/9 • • Edit Online

参考本文中的信息,可以:

了解云中的托管应用程序的安全优势
评估平台即服务 (PaaS) 相比其他云服务模型的安全优势
将安全重心从以网络为中心的方案转换为以标识为中心的外围安全方案
实施一般的 PaaS 安全最佳实践建议

开发适用 于云的应用程序时,在软件开发生命周期的每个阶段应考虑的安全问题和控制措施是一般的指导。

云的安全优势
请务必了解你与 Microsoft 之间的责任分工。 在本地,拥有整个堆栈,但迁移到云后,某些责任将转移到
Microsoft。
转移到云中可带来一定的安全优势。 在本地环境中,组织的可用资源可能有限,无法尽责在安全措施上投资,使
得攻击者能够利用所有层中的漏洞。

组织可以使用提供商的基于云的安全功能和云智能来改善其威胁检测和响应时间。 通过将责任转移到云提供商,
组织可以扩大安全覆盖范围,为其他优先业务重新调配安全资源与预算。

PaaS 云服务模型的安全优势
让我们来了解一下 Azure PaaS 部署相比本地部署的安全优势。

从堆栈的底部(即物理基础结构)开始,Microsoft 可以消除常见的风险和管理责任。 由于 Microsoft 云受到


Microsoft 的持续监视,因此很难攻破。 攻击者将 Microsoft 云当作攻击目标是不会得逞的。 他们往往会改换目
标,除非他们有大量的金钱和资源。

在堆栈的中间,PaaS 部署与本地之间没有差别。 在应用程序层和帐户与访问管理层,面临的风险是类似的。 本


文的后续步骤部分将提供有关消除或尽量避免这些风险的最佳实践指导。
堆栈的顶层(即数据监管和权限管理)存在一种风险,不过可以使用密钥管理来缓解。 (最佳实践中介绍了密钥管
理。)尽管密钥管理是一个附加的责任,但你不再需要管理 PaaS 部署中的某些区域,因此可将资源转移到密钥管
理。

Azure 平台还使用各种基于网络的技术提供强大的 DDoS 保护。 但是,根据链路和数据中心的不同,所有类型的


基于网络的 DDoS 保护方法都有自身的限制。 为了帮助避免大规模 DDoS 攻击造成的影响,可以利用 Azure 的
核心云功能快速自动扩展,以防御 DDoS 攻击。 在建议的实践文章中,我们将更详细地介绍如何采取这种措施。

革新防御者的思维方式
PaaS 部署为整体安全方案带来了变革。 事必躬亲的局面现在可以改为与 Microsoft 分担责任。
PaaS 与传统本地部署之间的另一个重大差别在于,前者为主要安全边界的界定因素提供了全新的视野。 一直以
来,主要的本地安全边界就是网络,大多数本地安全设计都使用网络作为主要安全枢纽。 在 PaaS 部署中,可将
标识视为主要安全边界,从而改善安全性。

采用标识用作主要安全边界的策略
在云计算的五大基本特征中,一个特征就是网络访问范围广泛,这使得以网络为中心的理念显得有点毫不相干。
许多云计算解决方案的目标是不管用户身居何处,都能允许他们访问资源。 对于大多数用户而言,他们的位置就
是 Internet 上的某个节点。

下图演示了安全边界从网络边界演进成标识边界的过程。 安全性越来越少地与如何保护网络相关,而更多地与
如何保护数据,以及如何管理应用和用户的安全性相关。 两者的关键差别在于如何为公司的重要资产提供更多
的安全保障。

最初,Azure PaaS 服务(例如 Web 角色和 Azure SQL )提供的传统网络边界防护措施很少,或者根本不提供。 开


发人员已认识到,设计元素的目的就是在 Internet 上公开(Web 角色),而身份验证可提供新的边界(例如 BLOB
或 Azure SQL )。
新式安全措施假设入侵者会突破网络边界。 因此,新式防护措施已转移到标识。 组织必须使用强身份验证和授
权保护机制建立基于标识的安全边界(最佳实践)。

网络边界的原理和模式早在几十年前就已建立。 相比之下,行业在使用标识作为主要安全边界的经验相对缺乏。
正因如此,我们累积了足够的经验,乐于提供已在现场得到证实的、适用于几乎所有 PaaS 服务的一些普通建议。

下面是管理标识边界的最佳做法。

最佳做法 :保护密钥和凭据以保护 PaaS 部署。


详细 信息 :丢失密钥和凭据是一个常见问题。 可以使用集中式解决方案,将密钥和机密存储在硬件安全模块
(HSM) 中。 Azure Key Vault 通过使用受 HSM 保护的密钥对身份验证密钥、存储帐户密钥、数据加密密钥、.pfx 文
件和密码进行加密来保护你的密钥和机密。

最佳做法 :不要将凭据和其他机密放入源代码或 GitHub。


详细 信息 :唯一比丢失密钥和凭据更遭糕的事情是让未经授权的一方获取这些密钥和凭据的访问权限。 攻击者
可以利用 bot 技术来查找 GitHub 等代码存储库中存储的密钥和机密。 请不要将密钥和机密放入这些公共代码存
储库。

最佳做法 :通过使用可以直接远程管理这些 VM 的管理接口来保护混合 PaaS 和 IaaS 服务上的 VM 管理接口。


详细 信息 :可以使用远程管理协议,如 SSH、 RDP和 PowerShell 远程处理 。 通常,我们建议不要从 Internet 启用
对 VM 的直接远程访问。

如果可以,请使用替代方法,例如在 Azure 虚拟网络中使用虚拟专用网络。 如果其他方法不可用,请确保使用复


杂的密码和双因素身份验证 (例如 Azure AD 多重身份验证) 。

最佳做法 :使用强身份验证和授权平台。
详细 信息 :在 Azure AD 而不是自定义用户存储中使用联合标识。 使用联合标识时,可以利用基于平台的方法,
将已获授权的标识的管理权限委托给合作伙伴。 如果员工离职后,需要通过多个标识和授权系统反映该信息,则
联合标识方法就特别重要。

使用平台提供的身份验证和授权机制,而不要使用自定义代码。 原因是开发自定义身份验证代码可能很容易出
错。 大部分开发人员都不是安全专家,不太可能会注意到身份验证和授权的细微之处与最新开发情况。 商业代
码(例如 Microsoft 编写的代码)通常会接受广泛的安全性评审。

使用双重身份验证。 双重身份验证是最新的身份验证和授权标准,它避免了用户名与密码类型的身份验证所固
有的安全漏洞。 应将对 Azure 管理 (门户/远程 PowerShell) 接口和面向客户的服务的访问权限设计并配置为使
用 Azure AD 多重身份验证。

使用 OAuth2 和 Kerberos 等标准身份验证协议。 这些协议经过广泛的同行评审,有时可实现为平台库的一部分


用于身份验证和授权。

在应用程序设计期间使用威胁建模
Microsoft 安全开发生命周期指定团队应在设计阶段参与名为威胁建模的过程。 为了帮助简化此过程,Microsoft
已创建 SDL 威胁建模工具。 对应用程序设计进行建模,并在所有信任边界中枚举 STRIDE 威胁可能会及早捕获
设计错误。

下表列出了 STRIDE 威胁,并提供了一些使用 Azure 功能的示例缓解措施。 这些缓解措施并非在每种情况下都起


作用。

A Z URE

欺骗 身份验证 需要 HTTPS 连接。

篡改 完整性 验证 TLS/SSL 证书。

否认性 不可否认性 启用 Azure 监视和诊断。


A Z URE

信息泄露 机密性 使用服务证书加密静态敏感数据。

拒绝服务 可用性 监视潜在拒绝服务条件的性能指标。 实


现连接筛选器。

特权提升 授权 使用特权标识管理。

在 Azure 应用服务上开发
Azure App Service 是一个 PaaS 产品,可创建适用于任何平台或设备的 Web 和移动应用,并可连接到云中或本
地任何位置的数据。 应用服务所包括的 Web 功能和移动功能是以前作为 Azure 网站和 Azure 移动服务单独交付
的。 它还包括各种新功能,可以实现业务流程的自动化,并可托管云 API。 应用服务以单个集成服务的形式为
Web、移动和集成方案提供一组丰富的功能。
下面是使用应用服务的最佳做法。

最佳做法 :通过 Azure Active Directory 进行身份验证。


详细 信息 :应用服务为标识提供者提供 OAuth 2.0 服务。 OAuth 2.0 注重简化客户端开发人员的工作,同时为
Web 应用程序、桌面应用程序和移动电话提供特定的授权流。 Azure AD 使用 OAuth 2.0,可让你授予移动和
Web 应用程序的访问权限。
最佳做法 :根据“需要知道”和“最低权限”安全原则限制访问。
详细 信息 :对于想要实施数据访问安全策略的组织,限制访问是必须要做的事。 可以使用 Azure RBAC 向特定范
围内的用户、组和应用程序分配权限。 若要了解有关向用户授予应用程序访问权限的详细信息,请参阅访问管理
入门。

最佳做法 :保护密钥。
详细 信息 :Azure Key Vault 可帮助保护云应用程序和服务使用的加密密钥和机密。 通过 Key Vault,可以使用受
硬件安全模块 (HSM) 保护的密钥,来加密密钥和机密(例如身份验证密钥、存储帐户密钥、数据加密密钥、.PFX
文件和密码)。 为了提升可靠性,可以在 HSM 中导入或生成密钥。 请参阅 Azure Key Vault 了解详细信息。 还可
以使用 Key Vault 和自动续订来管理 TLS 证书。

最佳做法 :限制传入的源 IP 地址。


详细 信息 :应用服务环境提供虚拟网络集成功能,可帮助你通过网络安全组限制传入的源 IP 地址。 使用虚拟网
络可将 Azure 资源置于可以控制其访问权限但无法通过 Internet 路由的网络中。 若要了解详细信息,请参阅将
应用与 Azure 虚拟网络集成。

最佳做法 :监视应用服务环境的安全状态。
详细 信息 :使用 Azure 安全中心监视应用服务环境。 在安全中心识别潜在的安全漏洞时,它会创建一些建议,这
些建议会指导完成配置所需控件的过程。

NOTE
监视应用服务的功能以预览版提供,仅适用于安全中心的标准层。

安装 Web 应用程序防火墙
Web 应用程序已逐渐成为利用常见已知漏洞的恶意攻击的目标。 这些攻击中最常见的攻击包括 SQL 注入攻击、
跨站点脚本攻击等。 防止应用程序代码中的此类攻击颇具挑战性,可能需要在应用程序拓扑的多个层进行严格
的维护、修补和监视。 集中式 Web 应用程序防火墙有助于大幅简化安全管理,为抵卸威胁或入侵的应用程序管
理员提供更好的保障。 相较保护每个单独的 Web 应用程序,WAF 解决方案还可通过在中央位置修补已知漏洞,
更快地响应安全威胁。 可将现有应用程序网关轻松转换为支持 Web 应用程序防火墙的应用程序网关。
Web 应用程序防火墙 (WAF) 是应用程序网关的功能,可以对 Web 应用程序进行集中保护,避免其受到常见的攻
击和漏洞危害。 WAF 基于 开放 Web 应用程序安全项目 (OWASP) 核心规则集 3.0 或 2.2.9 中的规则。

监视应用程序的性能
监视是一种数据收集和分析操作,用于确定应用程序的性能、运行状况及可用性。 有效的监视策略有助于了解应
用程序组件的详细运行状况, 它有助于向你发送关键情况的通知,让你在这些情况成为问题之前解决它们,从而
提高运行时间。 它还有助于检测可能与安全相关的异常。

使用 Azure Application Insights 监视应用程序的可用性、性能和使用情况,不管其是托管在云中还是在本地。 通


过使用 Application Insights,可以快速确定并诊断应用程序中的错误,而无需等待用户报告这些错误。 利用所收
集的信息,可作出有关应用程序维护和优化的明智抉择。

Application Insights 提供各种可以与所收集的数据交互的工具。 Application Insights 在公用存储库中存储其数


据。 它可以通过 Kusto 查询语言充分利用各种共享功能,例如警报、仪表板和深入分析。

执行安全渗透测试
验证安全防御与测试任何其他功能一样重要。 将渗透测试规定为生成和部署过程的标准组成部分。 针对已部署
应用程序对定期安全测试和漏洞扫描进行计划,并监视打开的端口、终结点和攻击活动。

模糊测试是一种通过将格式错误的输入数据提供给分析并使用此数据的程序接口(入口点)来查找程序故障(代
码错误)的方法。 Microsoft 安全风险检测是一种基于云的工具,可以在将软件部署到 Azure 之前,使用该工具查
找软件中的 bug 和其他安全漏洞。 该工具设计为在部署软件前捕获漏洞,因此你无需在软件发布后修补 bug、处
理崩溃或响应攻击。

后续步骤
本文重点介绍了 Azure PaaS 部署的安全优势以及云应用程序的最佳安全做法。 接下来,请阅读有关使用特定
Azure 服务保护 PaaS Web 和移动解决方案的建议做法。 首先,我们介绍如何保护 Azure 应用服务、Azure SQL
数据库和 Azure Synapse Analytics,以及 Azure 存储。 随着适用于其他 Azure 服务的建议做法文章的发布,我们
会在以下列表中提供相应的链接:

Azure 应用服务
Azure SQL 数据库和 Azure Synapse Analytics
Azure 存储
用于 Redis 的 Azure 缓存
Azure 服务总线
Web 应用程序防火墙
有关在开发适用于云的应用程序时,应在软件开发生命周期的每个阶段中考虑的安全性问题和控件,请参见在
Azure 上开发安全的应用程序。
有关通过 Azure 设计、部署和管理云解决方案时可以使用的更多安全最佳做法,请参阅 Azure 安全最佳做法和模
式。

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

Azure 安全团队博客 - 随时掌握 Azure 安全性的最新信息


Microsoft 安全响应中心 - 可在其中报告 Microsoft 安全漏洞(包括 Azure 问题)或将其通过电子邮件发送到
secure@microsoft.com
使⽤ Azure 应⽤服务保护 PaaS Web 和移动应⽤程
序的最佳做法
2021/2/9 • • Edit Online

本文介绍有关保护 PaaS Web 和移动应用程序的 Azure App Service 安全最佳实践。 这些最佳实践衍生自我们的


Azure 经验和客户经验。
Azure 应用服务是一个平台即服务 (PaaS) 产品,可创建适用于任何平台或设备的 Web 和移动应用,并可连接到
云中或本地任何位置的数据。 应用服务所包括的 Web 功能和移动功能是以前作为 Azure 网站和 Azure 移动服务
单独交付的。 它还包括各种新功能,可以实现业务流程的自动化,并可托管云 API。 应用服务以单个集成服务的
形式为 Web、移动和集成方案提供一组丰富的功能。

通过 Azure Active Directory (AD) 进行身份验证


应用服务为标识提供者提供 OAuth 2.0 服务。 OAuth 2.0 注重简化客户端开发人员的工作,同时为 Web 应用程
序、桌面应用程序和移动电话提供特定的授权流。 Azure AD 使用 OAuth 2.0 ,可让你授予移动和 Web 应用程序
的访问权限。 若要了解详细信息,请参阅 Azure 应用服务中的身份验证和授权。

基于角色限制访问
对于想要实施数据访问安全策略的组织,限制访问是必须要做的事。 可以使用 azure RBAC) (Azure 基于角色的
访问控制,将权限分配给特定范围内的用户、组和应用程序,如需要知道和最低权限安全原则。 若要详细了解如
何向用户授予应用程序访问权限,请参阅什么是 Azure 基于角色的访问控制 (Azure RBAC)。

保护你的密钥
如果丢失了订阅密钥,安全做得再好也无济于事。 Azure 密钥保管库可帮助保护云应用程序和服务使用的加密密
钥和机密。 通过 Key Vault,可以使用受硬件安全模块 (HSM) 保护的密钥,来加密密钥和机密(例如身份验证密
钥、存储帐户密钥、数据加密密钥、.PFX 文件和密码)。 为了提升可靠性,可以在 HSM 中导入或生成密钥。 还可
以使用 Key Vault 和自动续订来管理 TLS 证书。 请参阅 Azure Key Vault 了解详细信息。

限制传入的源 IP 地址
应用服务环境提供虚拟网络集成功能,可帮助你通过网络安全组 (NSG) 限制传入的源 IP 地址。 如果不熟悉
Azure 虚拟网络 (VNET),可使用此功能将多个 Azure 资源放置在可以控制其访问权限但无法通过 Internet 路由
的网络中。 若要了解详细信息,请参阅将应用与 Azure 虚拟网络集成。

对于 Windows 上的应用服务,还可以通过配置 web.config 来动态限制 IP 地址。有关详细信息,请参阅动态 IP 安


全性。

后续步骤
本文介绍了有关保护 PaaS Web 和移动应用程序的一系列应用服务安全最佳实践。 若要了解有关保护 PaaS 部署
的详细信息,请参阅:

保护 PaaS 部署
在 Azure 中保护 PaaS 数据库
使⽤ Azure 存储保护 PaaS Web 和移动应⽤程序的
最佳做法
2021/2/9 • • Edit Online

本文介绍 Azure 存储安全在保护平台即服务 (PaaS) Web 和移动应用程序方面的最佳做法。 这些最佳实践衍生自


我们的 Azure 经验和客户经验。

Azure 可以用本地不易实现的方式来部署并使用存储。 通过 Azure 存储,可用相对较少的工作量达到高水平的可


伸缩性和可用性。 Azure 存储不仅是 Windows 和 Linux Azure 虚拟机的基础,还可以支持大型分布式应用程序。

Azure 存储提供了以下四种服务:Blob 存储、表存储、队列存储和文件存储。 若要了解详细信息,请参阅


Microsoft Azure 存储简介。
Azure 存储安全指南是有关 Azure存储和安全性的详细信息的重要来源。 本篇最佳做法文章高度概括地介绍了安
全指南中的一些概念,并提供了获得详细信息的安全指南及其他来源的链接。

本文将探讨以下最佳做法:

共享访问签名 (SAS)
Azure 基于角色的访问控制 (Azure RBAC)
高价值数据的客户端加密
存储服务加密

使用共享访问签名代替了存储帐户密钥
访问控制是关键。 若要帮助控制对 Azure 存储的访问,当创建存储帐户时,Azure 将生成两个 512 位存储帐户密
钥 (SAK)。 在例程秘钥轮换期间,通过密钥冗余级别可避免服务中断。

存储访问密钥是高优先级的机密,只能由负责存储访问控制的人员访问。 如果不当人员获取访问这些密钥的权
限,他们就能够完全控制存储,并可以替换、删除文件或将文件添加到存储。 这些文件包括恶意内容和可能会危
及组织或客户的其他类型的内容。

但你仍然需要一种方法来提供存储中对象的访问权限。 若要提供更精细的访问权限,可以利用共享访问签名
(SAS)。 通过 SAS ,可以使用特定权限在预定义的时间间隔共享存储中的特定对象。 通过共享访问签名,可定义:
SAS 有效的时间间隔,包括开始时间和到期时间。
SAS 授予的权限。 例如,blob SAS 可能授予用户对 blob 的读取和写入权限,但不是删除权限。
Azure 存储接受 SAS 的可选 IP 地址或 IP 地址范围。 例如,你可能指定属于组织的 IP 地址范围。 这为 SAS 提
供了另一个安全性度量。
Azure 存储接受 SAS 所依据的协议。 可通过此可选参数使用 HTTPS 限制对客户端的访问。
通过 SAS 可以用希望的方式共享内容,而无需分配存储帐户密钥。 在应用程序中始终使用 SAS 可以安全地共享
存储资源,不会危及存储帐户密钥。

若要了解有关共享访问签名的详细信息,请参阅使用共享访问签名。

使用 Azure 基于角色的访问控制
管理访问的另一种方法是使用 Azure 基于角色的访问控制 (Azure RBAC)。 借助 Azure RBAC,你可以专注于根据
需要知道和最低权限安全原则,为员工提供他们所需的确切权限。 权限过多,可能会向攻击者公开帐户。 权限太
少意味着员工无法有效地完成其工作。 Azure RBAC 通过为 Azure 提供精细的访问管理,帮助解决此问题。 对于
想要实施数据访问安全策略的组织,这是必须要做的事。
可以使用 Azure 中的 Azure 内置角色向用户分配权限。 例如,将存储帐户参与者用于需要管理存储帐户的云操
作员,并使用经典存储帐户参与者角色来管理经典存储帐户。 如果云操作员需要管理 VM 但不管理他们连接到
的虚拟网络或存储帐户,则可以将他们添加到虚拟机参与者角色。

不通过使用 Azure RBAC 等功能实施数据访问控制的组织可能会向其用户提供比所需权限更多的特权。 一开始


就允许某些用户访问他们不应有权访问的数据可能会导致数据泄漏。

若要了解有关 Azure RBAC 的详细信息,请参阅:

使用 Azure 门户添加或删除 Azure 角色分配


Azure 内置角色
Azure 存储安全指南

对高价值数据使用客户端加密
通过客户端加密,可在上传到 Azure 存储之前以编程方式加密传输中的数据,并在检索数据时以编程方式解密数
据。 这提供传输中的数据加密,但也提供静态数据加密。 客户端加密是最安全的加密数据方法,但它要求以编程
方式更改应用程序,并将密钥管理程序放在正确的位置。

客户端加密还可以对加密密钥进行单独控制。 可生成和管理自己的加密密钥。 客户端加密使用信封技术,其中


Azure 存储客户端库生成内容加密密钥 (CEK),然后使用密钥加密密钥 (KEK) 包装(加密)密钥。 KEK 由密钥标识
符标识,可以是非对称密钥对或对称密钥,还可以在本地托管或存储在 Azure Key Vault 中。

客户端加密内置于 Java 和 .NET 存储客户端库中。 有关在客户端应用程序中加密数据并生成和管理自己的加密


密钥的信息,请参阅适用于 Microsoft Azure 存储的客户端加密和 Azure Key Vault。

为静态数据启用存储服务加密
当启用文件存储的存储服务加密时,将使用 AES-256 加密自动加密数据。 Microsoft 处理所有加密、解密和密钥
管理。 此功能适用于 LRS 和 GRS 冗余类型。

后续步骤
本文介绍了有关保护 PaaS Web 和移动应用程序的一系列 Azure 存储安全最佳做法。 若要了解有关保护 PaaS 部
署的详细信息,请参阅:

保护 PaaS 部署
使用 Azure 应用服务保护 PaaS Web 和移动应用程序
在 Azure 中保护 PaaS 数据库
在 Azure 中保护 PaaS 数据库的最佳做法
2021/2/9 • • Edit Online

在本文中,我们讨论了 Azure SQL 数据库和 Azure Synapse Analytics 关于保护平台即服务 (PaaS) Web 和移动应
用程序的一组安全最佳做法。 这些最佳实践衍生自我们的 Azure 经验和客户经验。

Azure SQL 数据库和 Azure Synapse Analytics 为基于 Internet 的应用程序提供关系数据库服务。 让我们了解一
下在 PaaS 部署中使用 Azure SQL 数据库和 Azure Synapse Analytics 时可帮助保护应用程序与数据的服务:

Azure Active Directory 身份验证(而不是 SQL Server 身份验证)


Azure SQL 防火墙
透明数据加密 (TDE)

使用集中式标识存储库
可将 Azure SQL 数据库配置为使用以下两种身份验证类型之一:

SQL 身份验证使用用户名和密码。 在为数据库创建服务器时,已指定了一个包含用户名和密码的“服务器


管理员”登录名。 借助这些凭据,可以使用数据库所有者的身份通过服务器上任何数据库的身份验证。

Azure Active Directory 身份验证使用 Azure Active Directory 管理的标识,支持托管域和集成域。 若要使


用 Azure Active Directory 身份验证,必须创建名为“Azure AD 管理员”的另一个服务器管理员,用于管理
Azure AD 用户和组。 此管理员还能执行普通服务器管理员可以执行的所有操作。
Azure Active Directory 身份验证是使用 Azure Active Directory (AD) 中的标识连接到 Azure SQL 数据库和 Azure
Synapse Analytics 的一种机制。 Azure AD 为 SQL Server 身份验证提供一种替代方法,使你可以阻止用户标识在
数据库服务器之间激增。 使用 Azure AD 身份验证可在一个中心位置集中管理数据库用户和其他 Microsoft 服务
的标识。 集中 ID 管理提供一个单一位置来管理数据库用户,并简化权限管理。

与 SQL 身份 验证 相比使用 Azure AD 的好 处


允许在单一位置中轮换密码。
使用外部 Azure AD 组管理数据库权限。
通过启用集成的 Windows 身份验证和 Azure AD 支持的其他形式的身份验证来消除存储密码。
使用包含的数据库用户在数据库级别对标识进行身份验证。
支持对连接到 SQL 数据库的应用程序进行基于令牌的身份验证。
支持使用 Active Directory 联合身份验证服务 (ADFS) 或本机用户/密码身份验证对本地 Azure AD 进行域联
合。
支持从 SQL Server Management Studio 进行连接,后者使用 Active Directory 通用身份验证,其中包括多重
身份验证 (MFA)。 MFA 包括利用一系列简单的验证选项进行的强身份验证,这些选项包括电话、短信、含有
PIN 码的智能卡或移动应用通知。 有关详细信息,请参阅 SQL 数据库和 Azure Synapse Analytics 的通用身份
验证。

若要了解有关 Azure AD 身份验证的详细信息,请参阅:

将 Azure Active Directory 身份验证与 SQL 数据库、托管实例或 Azure Synapse Analytics 结合使用
向 Azure Synapse Analytics 进行身份验证
使用 Azure AD 身份验证对 Azure SQL 数据库提供基于令牌的身份验证支持
NOTE
若要确保 Azure Active Directory 适用于当前环境,请参阅 Azure AD 功能和限制。

基于 IP 地址限制访问
可以创建防火墙规则用于指定可接受的 IP 地址范围。 这些规则可以针对服务器级别和数据库级别。 建议尽量使
用数据库级防火墙规则,以增强安全性并提高数据库的可移植性。 当多个数据库具有相同的访问要求,但你不想
花时间单独配置每个数据库时,管理员最好是使用服务器级防火墙规则。

SQL 数据库的默认源 IP 地址限制允许从任何 Azure 地址(包括其他订阅和租户)进行访问。 可以限制为仅允许从


IP 地址访问实例。 即使使用了 SQL 防火墙和 IP 地址限制,也仍然需要设置强身份验证。 请参阅本文前面提供的
建议。

若要了解有关 Azure SQL 防火墙和 IP 限制的详细信息,请参阅:

Azure SQL 数据库和 Azure Synapse Analytics 访问控制


Azure SQL 数据库和 Azure Synapse Analytics 防火墙规则

静态数据加密
透明数据加密 (TDE) 默认已启用。 TDE 以透明方式加密 SQL Server 、Azure SQL 数据库和 Azure Synapse
Analytics 的数据和日志文件。 TDE 可以防范直接访问文件或其备份所造成的安全威胁。 这样就可以实现静态数
据加密,且无需更改现有应用程序。 应始终保持启用 TDE;不过,这无法阻止攻击者使用普通的访问路径。 使用
TDE 能够符合各个行业制定的许多法律、法规和准则。
Azure SQL 可以管理 TDE 存在的密钥相关问题。 与使用 TDE 时一样,在本地操作以及移动数据库时也必须格外
小心,确保能够恢复。 在更复杂的方案中,可以通过可扩展的密钥管理在 Azure Key Vault 中显式管理密钥。 请
参阅使用 EKM 在 SQL Server 上启用 TDE。 此外,也允许通过 Azure Key Vault BYOK 功能自带密钥 (BYOK)。

Azure SQL 通过 Always Encrypted 为列提供加密。 这样,只有获得授权的应用程序才能访问敏感列。 使用这种


加密可将针对已加密列的 SQL 查询限制为基于相等性的值。

对于某些特定的数据,也应该使用应用程序级加密。 有时,可通过使用保存在适当国家/地区的密钥加密数据,来
消除数据主权忧虑。 这可以防止意外的数据传输导致问题,因为在使用强算法(例如 AES 256 )的情况下,如果没
有该密钥,将无法解密数据。

可以使用其他预防措施来帮助保护数据库,例如,设计安全系统、加密机密资产,以及围绕数据库服务器构建防
火墙。

后续步骤
本文介绍了 SQL 数据库和 Azure Synapse Analytics 有关保护 PaaS Web 和移动应用程序的一组安全最佳做法。
若要了解有关保护 PaaS 部署的详细信息,请参阅:

保护 PaaS 部署
使用 Azure 应用服务保护 PaaS Web 和移动应用程序
Azure Service Fabric 安全性最佳做法
2021/2/9 • • Edit Online

在 Azure 上部署应用程序的过程快速、轻松且经济高效。 将云应用程序部署到生产环境前,请先查看有必要遵照


和建议的最佳做法列表,了解最好应如何在应用程序中实现群集安全性。

Service Fabric 是分布式系统平台,可借助它轻松打包、部署和管理可缩放且可靠的微服务。 Service Fabric 还解


决了开发和管理云应用程序中的重大难题。 开发人员和管理员不仅可以避免复杂的基础结构问题,而且可以专
注于实现可缩放、可靠且可管理的要求苛刻的任务关键型工作负荷。

对于每项最佳做法,本文将说明:

最佳做法是什么。
应遵照最佳做法的具体原因。
如果未遵照最佳做法,会有什么样的后果。
如何学会遵照最佳做法。

建议遵照以下 Azure Service Fabric 安全性最佳做法:

使用 Azure 资源管理器模板和 Service Fabric PowerShell 模块创建安全群集。


使用 X.509 证书。
配置安全策略。
实现 Reliable Actors 安全配置。
为 Azure Service Fabric 配置 TLS 。
将 Azure Service Fabric 与网络隔离和安全功能结合使用。
出于安全考虑,配置 Azure Key Vault。
将用户分配到角色。

保护群集的最佳做法
始终使用安全群集:

使用证书实现群集安全性。
使用 Azure Active Directory (Azure AD) 提供客户端访问权限(管理员访问权限和只读访问权限)。

使用自动部署:

使用脚本生成、部署和滚动更新机密。
将机密存储在 Azure Key Vault 中,并使用 Azure AD 提供其他所有客户端访问权限。
要求必须经过身份验证,才能读取机密。

此外,还请考虑使用以下配置选项:

使用 Azure 网络安全组 (NSG) 创建外围网络(亦称为“隔离区 (DMZ)”和“外围子网”)。


结合使用跳板机和远程桌面连接,访问群集虚拟机 (VM) 或管理群集。

必须保护群集,以防未经授权的用户连接到群集,特别是当群集在生产环境中运行时。 尽管可以创建不安全群
集,但当群集向公共 Internet 公开管理终结点时,匿名用户就可以与它建立连接。

使用各种技术实现群集安全性的方案有三种:

节点到节点安全性:此方案可保护群集中 VM 与计算机之间的通信。 这种安全性可确保只有已获授权加入群


集的计算机,才能在群集中托管应用程序和服务。 在此方案中,Azure 上运行的群集或 Windows 上运行的独
立群集可以使用证书安全性或 Windows 安全性(适用于 Windows Server 计算机)。
客户端到节点安全性:此方案可保护 Service Fabric 客户端与群集中各个节点之间的通信。
Service Fabric 基于角色的访问控制 (Service Fabric RBAC) :此方案对访问群集的每个管理员和用户客户端角
色使用单独的标识, (证书、Azure AD 等) 。 这些角色标识是在创建群集时指定。

NOTE
Azure : 使用 Azure AD 安全性对客户端进行身份验证,并使用证书实现节点到节点安全性。

若要配置 Windows 独立群集,请参阅 Windows 独立群集的配置设置。

使用 Azure 资源管理器模板和 Service Fabric PowerShell 模块创建安全群集。 有关如何使用 Azure 资源管理器


模板创建安全 Service Fabric 群集的分步说明,请参阅创建 Service Fabric 群集。

使用 Azure 资源管理器模板:

使用此模板为 VM 虚拟硬盘 (VHD) 配置托管存储,从而自定义群集。


使用此模板简化配置管理和审核,推动对资源组的更改。

将群集配置视为代码:

仔细检查部署配置。
避免使用隐式命令直接修改资源。

可以对 Service Fabric 应用程序生命周期的许多层面进行自动化。 Service Fabric PowerShell 模块可自动执行常


见任务,包括部署、升级、删除和测试 Azure Service Fabric 应用程序。 此外,还提供了托管 API 和 HTTP API,可
用于管理应用程序。

使用 X.509 证书
始终使用 X.509 证书或 Windows 安全性保护群集。 安全性仅在群集创建时进行配置。 无法在群集创建后启用安
全性。

若要指定 群集证书,请将 ClusterCredentialType 属性的值设置为 X509 。 若要为外部连接指定服务器证书,请


将 Ser verCredentialType 属性的值设置为 X509 。

此外,还请遵照以下做法:

使用正确配置的 Windows Server 证书服务为生产群集创建证书。 也可以从核准证书颁发机构 (CA) 获取证


书。
切勿对生产群集使用通过 MakeCert.exe 或类似工具创建的临时或测试证书。
对测试群集使用自签名证书,但不要对生产群集使用此类证书。

如果是不安全群集,任何人都可以匿名连接到此群集,并执行管理操作。 鉴于此,请务必使用 X.509 证书或


Windows 安全性保护生产群集。
若要详细了解如何使用 X.509 证书,请参阅添加或删除 Service Fabric 群集的证书。

配置安全性策略
Service Fabric 还可保护应用程序使用的资源。 在应用程序部署后,文件、目录和证书等资源都会存储在用户帐
户下。 借助此功能,即使在共享的托管环境中,也可加强对运行中应用程序的保护,防止其相互影响。

使用 Active Directory 域组或用户:使用 Active Directory 用户或组帐户的凭据运行服务。 请务必在域中使


用本地 Active Directory,而不是 Azure Active Directory。 使用域用户或组,访问域中已被授予权限的其他
资源。 例如,文件共享等资源。

为 HTTP 和 HTTPS 终结点分配安全访问策略:指定 SecurityAccessPolicy 属性,在服务清单使用 HTTP


协议声明终结点资源时,向服务应用 RunAs 策略。 分配给 HTTP 终结点的端口是,运行服务所用的
RunAs 用户帐户的正确访问控制列表。 如果未设置此策略,http.sys 将无权访问服务,并且用户也无法从
客户端进行调用。

若要了解如何在 Service Fabric 群集中使用安全策略,请参阅配置应用程序的安全策略。

实现 Reliable Actors 安全配置


Service Fabric Reliable Actors 是执行组件设计模式的实现。 与所有软件设计模式一样,决定是否使用特定模式
时需要考虑,此模式是否适合解决软件问题。

一般来说,使用执行组件设计模式有助于构建解决方案,从而处理以下软件问题或安全方案:

问题空间包含大量(几千或更多)小型、独立的状态和逻辑单元。
使用的是单线程对象,无需与外部组件进行大量交互,包括跨一组执行组件查询状态。
执行组件实例不会发出 I/O 操作指令阻止遇到不可预测延迟的调用方。

在 Service Fabric 中,执行组件是在 Reliable Actors 应用程序框架中实现。 此框架以执行组件模式为依据,在


Service Fabric Reliable Services 的基础之上构建而成。 编写的每个可靠执行组件服务都是一个已分区的有状态
可靠服务。

每个执行组件定义为执行组件类型的一个实例,与 .NET 对象是 .NET 类型的一个实例类同。 例如,用于实现计算


器功能的执行组件类型可能包含此类型的多个执行组件,这些执行组件跨群集中的各个节点进行分布。 分布的
每个执行组件都通过执行组件标识符进行唯一标识。

复制器安全配置用于保护在复制过程中使用的信道的安全。 此配置可阻止服务相互窥探复制流量,并确保可用
性很高的数据安全。 默认情况下,空的安全配置节会影响复制安全。 复制器配置用于配置负责使执行组件状态
提供程序状态高度可靠的复制器。

为 Azure Service Fabric 配置 TLS


服务器身份验证流程向管理客户端验证群集管理终结点。 然后,管理客户端确定它在与真正的群集通信。 此证
书还通过 HTTPS 为 HTTPS 管理 API 和 Service Fabric Explorer 提供 TLS 。 必须获取群集的自定义域名。 从证书
颁发机构请求获取证书时,证书的使用者名称必须与用于群集的自定义域名匹配。

若要为应用程序配置 TLS ,首先需要获取已由 CA 签名的 SSL/TLS 证书。 CA 是受信任的第三方,负责颁发证书,


以提高 TLS 安全性。 如果尚无 SSL/TLS 证书,需要从销售 SSL/TLS 证书的公司购买一个。

该证书必须满足 Azure 中的以下 SSL/TLS 证书要求:

证书必须包含私钥。

必须创建适用于密钥交换的证书,并且证书必须可导出到个人信息交换 (.pfx) 文件中。

证书的使用者名称必须与用于访问云服务的域名匹配。

获取用于访问云服务的自定义域名。
请求从 CA 获取证书,其中使用者名称与服务的自定义域名匹配。 例如,如果自定义域名为
contoso .com,CA 颁发的证书应包含使用者名称 .contoso.com 或 www .contoso.com。

NOTE
无法从 CA 获取 cloudapp .net 域的 SSL/TLS 证书。

证书至少必须使用 2,048 位加密。


HTTP 协议不安全,容易受到窥探攻击威胁。 通过 HTTP 传输的数据在 Web 浏览器到 Web 服务器之间或其他终
结点之间作为纯文本发送。 攻击者可以拦截和查看通过 HTTP 发送的敏感数据,如信用卡详细信息和帐户登录凭
据。 如果数据使用 HTTPS 通过浏览器进行发送或发布,SSL 可确保加密和保护敏感信息,防止其被拦截。

若要详细了解如何使用 SSL/TLS 证书,请参阅为 Azure 中的应用程序配置 TLS 。

将 Azure Service Fabric 与网络隔离和安全功能结合使用


将 Azure 资源管理器模板用作示例,设置 nodetype 属性值为 3 的安全群集。 使用此模板和网络安全组控制入站
和出站网络流量。

此模板为每个虚拟机规模集都提供了一个 NSG,旨在控制规模集的入站和出站流量。 默认情况下,将会把规则


配置为允许模板中指定的系统服务和应用程序端口所需的全部流量进出。 请查看这些规则,并根据需要进行任
意更改,包括为应用程序添加新规则。

有关详细信息,请参阅 Azure Service Fabric 的常见网络方案。

出于安全考虑,设置 Azure Key Vault


Service Fabric 使用证书提供身份验证和加密,从而保护群集及其应用程序。
Service Fabric 使用 X.509 证书保护群集,并提供应用程序安全功能。 Azure Key Vault 用于管理 Azure 中 Service
Fabric 群集的证书。 创建群集的 Azure 资源提供程序从密钥保管库拉取证书。 然后,当群集在 Azure 上部署时,
资源提供程序在 VM 上安装这些证书。

Azure Key Vault、Service Fabric 群集与使用这些证书的资源提供程序之间存在证书关系。 在群集创建后,证书关


系的相关信息会存储在密钥保管库中。

设置密钥保管库有两个基本步骤:

1. 专门为密钥保管库创建一个资源组。

建议将密钥保管库置于它自己的资源组中。 此操作有助于防止在其他资源组(如存储组、计算组或包含群
集的组)遭到删除后丢失密钥和机密。 包含 Key Vault 的资源组必须与正在使用它的群集位于同一区域。

2. 在新建的资源组中创建密钥保管库。

必须启用密钥保管库,才能进行部署。 然后,计算资源提供程序可以从保管库获取证书,并将证书安装在
VM 实例上。
若要详细了解如何设置密钥保管库,请参阅什么是 Azure 密钥保管库?。

将用户分配到角色
创建应用程序以代表群集后,请将用户分配到 Service Fabric 支持的角色,即只读和管理员。可使用 Azure 门户
来分配这些角色。

NOTE
有关在 Service Fabric 中使用角色的详细信息,请参阅 Service Fabric Service Fabric 客户端的基于角色的访问控制。

对于连接到 Service Fabric 群集的客户端,Azure Service Fabric 支持两种类型的访问控制:基于管理员和用户的


访问控制。 群集管理员可以使用访问控制,限制各组用户执行特定的群集操作。 访问控制可提高群集安全性。

后续步骤
Service Fabric 安全性清单
设置 Service Fabric 开发环境。
了解 Service Fabric 支持选项。
Azure 威胁防护
2021/2/9 • • Edit Online

Azure 通过服务(如 Azure Active Directory (Azure AD) 、Azure Monitor 日志和 Azure 安全中心)提供内置的威胁
防护功能。 安全服务和功能的此集合提供了一种简单快速了解 Azure 部署运行状况的方法。

Azure 提供多种安全性配置和自定义选项,以满足应用部署的要求。 本文介绍如何满足这些要求。

Azure Active Directory 标识保护


Azure AD 标识保护是 Azure Active Directory Premium P2 版本中的一项功能,通过它可以全面了解可影响组织
标识的风险事件和潜在漏洞。 标识保护使用现有的 Azure AD 异常情况检测功能(可通过 Azure AD 异常活动报
告获得),并引入了新的可以检测实时异常的风险检测类型。

标识保护使用自适应机器学习算法和启发式规则来检测异常行为以及可能表示标识已遭入侵的风险检测。 标识
保护使用此数据生成报告和警报,以便可以调查这些风险检测并采取相应的补救或缓解措施。

Azure Active Directory 标识保护不只是一个监视和报告工具。 标识保护根据风险检测计算每个用户的用户风险


级别,以便可以配置基于风险的策略来自动保护组织的标识。

除了 Azure Active Directory 与 EMS 提供的其他条件访问控制以外,这些基于风险的策略也可以自动阻止或提供


自适应补救措施,包括重置密码和强制实施多重身份验证。

“标识 保 护 ”功能
Azure Active Directory 标识保护不只是一个监视和报告工具。 若要保护组织的标识,可以配置基于风险的策略,
该策略可在达到指定风险级别时自动响应检测到的问题。 除了 Azure Active Directory 与 EMS 提供的条件访问
控制以外,这些策略也可以自动阻止或启用自适应补救措施,包括重置密码和强制实施多重身份验证。

Azure 标识保护可帮助保护帐户和标识的一些示例包括:
检测风险检测和风险帐户

使用机器学习和启发式规则检测 6 种风险检测类型。
计算用户风险级别。
提供自定义建议,通过突显漏洞来改善整体安全状况。

调查风险检测

针对风险检测发送通知。
使用相关的上下文信息调查风险检测。
提供基本工作流来跟踪调查。
提供轻松使用补救措施,例如密码重置。

基于风险的条件性访问策略

通过阻止登录或要求进行多重身份验证来减少有风险的登录。
阻止或保护有风险的用户帐户。
要求用户注册多重身份验证。

Azure AD 特 权标识 管理
使用 Azure Active Directory Privileged Identity Management (PIM),可以管理、控制和监视组织内的访问。 此功
能包括访问 Azure AD 和其他 Microsoft 联机服务(如 Microsoft 365 或 Microsoft Intune)中的资源。

PIM 可帮助用户进行以下操作:
获取有关 Azure AD 管理员以及对 Microsoft 联机服务(例如 Microsoft 365 和 Intune)的实时 (JIT) 管理访
问的警报和报告。

获取有关管理员访问历史记录以及管理员分配更改的报告。

获取有关访问特权角色的警报。

Azure Monitor 日志
Azure Monitor 日志是 Microsoft 提供的基于云的 IT 管理解决方案,可帮助你管理和保护本地和云基础结构。 因
为 Azure Monitor 日志是作为基于云的服务实现的,因此在基础结构服务上进行极低的投资即可快速使其启动并
运行。 自动提供新增安全功能,从而节省持续维护和升级成本。

除自行提供有价值的服务外,Azure Monitor 日志还可与 System Center Operations Manager 等 System Center


组件集成,将现有安全管理投资扩展到云。 System Center 和 Azure Monitor 日志可协同工作来提供完整的混合
管理体验。
安全性与符合性 总 体情况
Azure 安全中心 提供了组织的 IT 安全状况的综合视图,内置搜索查询需要你关注的重要问题。 它提供计算机安
全状态的高级洞见。 还可以查看过去24 小时、7 天或任何其他自定义时间范围内的所有事件。

Azure Monitor 日志有助于用户快速轻松了解任何环境中的总体安全情况,在 IT 操作的上下文中即可实现,这些


操作包括软件更新评估、反恶意软件评估和配置基线。 可访问现成的安全日志数据,简化安全性和符合性审核过
程。

见 解与分析
Azure Monitor 日志的中心是由 Azure 托管的存储库。

通过配置数据源和向订阅添加解决方案,将连接的源中的数据收集到存储库。

数据源和解决方案分别创建具有自身属性集的单独记录类型,但是用户仍可在对存储库的查询中同时对它们进
行分析。 可以使用相同的工具和方法来处理由不同的源收集的各种数据。

与 Azure Monitor 日志的大部分交互都通过 Azure 门户完成,该门户可在任意浏览器中运行,并提供对配置设置


和多个工具的访问权限,以对收集的数据进行分析和操作。 在门户中,可以使用:

日志搜索,可在其中构造查询以分析收集的数据。
仪表板,可以使用最有价值搜索的图形视图对其进行自定义。
解决方案,可提供其他功能和分析工具。

解决方案向 Azure Monitor 日志添加功能。 解决方案主要在云中运行,并提供对日志分析存储库所收集数据的分


析。 解决方案也可以定义要收集的新记录类型,可使用日志搜索或通过解决方案在日志分析仪表板中提供的其
他用户界面对这些记录类型进行分析。

安全中心就是这些类型的解决方案的一个示例。

自 动 化与控制:安全配置偏移警 报
Azure 自动化通过基于 PowerShell 并在云中运行的 Runbook 自动执行管理流程。 也可在本地数据中心内的服务
器上运行 Runbook 以管理本地资源。 Azure 自动化通过 PowerShell Desired State Configuration (DSC) 提供配置
管理。
可以创建和管理在 Azure 中托管的 DSC 资源,并将其应用到云和本地系统。 完成此操作后,可以定义和自动强
制执行其配置,或获取有关偏移的报告,以确保安全配置保留在策略中。

Azure 安全中心
Azure 安全中心可帮助保护你的混合云环境。 通过对连接的资源执行持续的安全评估,可以为发现的漏洞提供详
细的安全建议。

安全中心的建议基于 Azure 安全性基准 ,这是针对基于公共符合性框架的安全性和符合性最佳做法的 Microsoft


创作的特定于 azure 的指导原则集。 这一广泛遵从的基准是从 中心针对 Internet 安全 (CIS) 和 美国国家标准与
技术研究院 (NIST) ,重点介绍以云为中心的安全性。

安全中心的集成云工作负荷保护平台 (CWPP) , Azure Defender ,提供 azure 和混合资源与工作负荷的高级、


智能、保护。 启用 Azure Defender 会引入一系列附加安全功能 (参阅 Azure Defender) 简介 。 可在你的环境中使
用安全中心的 Azure Defender 仪表板显示和控制 CWP 功能:
Microsoft 安全研究人员始终在不断地寻找威胁。 得益于 Microsoft 在云中和本地的广泛存在,他们可以访问大
量的遥测数据。 由于能够广泛访问和收集各种数据集,Microsoft 可以通过本地消费者产品和企业产品以及联机
服务发现新的攻击模式和趋势。

因此,攻击者发布新的越来越复杂的方式时,安全中心就可以快速更新其检测算法。 此方法可帮助你始终与变化
莫测的威胁环境保持同步。
Azure Defender 会自动从你的资源、网络和连接的合作伙伴解决方案中收集安全信息。 分析该信息(需将多个来
源的信息关联起来)即可确定威胁。

在安全中心对 Azure Defender 警报进行优先级划分,同时提供有关如何修正威胁的建议。

安全中心使用各种高级安全分析,远不止几种基于攻击特征的方法。 大数据和 机器学习 技术的突破用于评估整


个云中的事件。 高级分析可以检测不可能通过手动方法识别的威胁,并预测攻击的演变。 接下来的部分会介绍
这些安全分析类型。

威胁情报
Microsoft 可访问大量的全球威胁情报。
遥测数据的来源包括:Azure、Microsoft 365 、Microsoft CRM Online、Microsoft Dynamics AX、outlook.com 、
MSN.com、Microsoft 数字犯罪部门 (DCU)、Microsoft 安全响应中心 (MSRC)。
研究人员也会收到在主要的云服务提供商之间共享的威胁情报信息,并订阅来自第三方的威胁情报源。 Azure 安
全中心可能会在分析该信息后发出警报,提醒用户注意来自行为不端攻击者的威胁。 示例包括:

利用机器学 习 的力量 :Azure 安全中心有权访问大量有关云网络活动的数据,这些数据可用于检测针对


Azure 部署的威胁。
暴力攻 击检测 :机器学习可用于创建远程访问尝试的历史模式,从而检测针对安全外壳 (SSH)、远程桌面
协议 (RDP) 和 SQL 端口的暴力攻击。

出站 DDoS 和僵尸网 络检测 :针对云资源的攻击的常见目标是使用这些资源的计算能力来执行其他攻


击。

新行 为 分析服 务 器和 VM :服务器或虚拟机受到攻击后,攻击者将使用各种各样的技术在该系统上执行
恶意代码,同时避免检测、确保持久性和避免安全控件。

Azure SQL 数据 库 威 胁检测 :Azure SQL 数据库威胁检测可以识别异常数据库活动,指示企图访问或利


用数据库的异常的潜在有害尝试。

行 为 分析
行为分析是一种技术,该技术会对数据进行分析并将数据与一系列已知模式对比。 不过,这些模式不是简单的特
征, 需要对大型数据集运用复杂的机器学习算法来确定,
模式也由分析专家通过仔细分析恶意行为来确定。 Azure 安全中心可以使用行为分析对虚拟机日志、虚拟网络设
备日志、结构日志、故障转储和其他资源进行分析,确定受攻击的资源。

此外,模式与其他信号关联,以查看是否存在某个广泛传播活动的支持证据。 此关联性也可用于确定那些符合已
确定的攻击特征的事件。

示例包括:

可疑的 进 程 执 行 :为了执行恶意软件而不被检测到,攻击者会运用多种技巧。 例如,攻击者可能会为恶意


软件取一个与合法的系统文件相同的名称,但却将这些文件置于其他位置,可能会使用与正常文件名类似
的名称,或者会掩盖文件的实际扩展名。 安全中心会对进程行为建模,监视进程的执行情况,检测此类异
常行为。

隐 藏 恶 意 软 件和漏洞利用 尝试 :复杂的恶意软件从不向磁盘写入内容,或者会加密存储在磁盘上的软件
组件,借此逃避传统的反恶意软件产品的检测。 但是,此类恶意软件可以通过使用内存分析检测到,因为
恶意软件一运行就必然会在内存中留下踪迹。 当软件故障时,故障转储可捕获故障时的部分内存。 通过
分析故障转储中的内存,Azure 安全中心可以检测到用于利用软件漏洞、访问机密数据以及偷偷存留在受
攻击计算机中而不影响计算机性能的技术。

横向移 动 和内部 侦测 :为了留存在受攻击的网络中以及查找和获取有价值的数据,攻击者通常会尝试从


受攻击的计算机横向移动到同一网络中的其他计算机。 安全中心会监视进程和登录活动,从而发现是否
有人尝试在网络中扩大攻击者据点,例如是否存在远程命令执行、网络探测及帐户枚举。

恶意 PowerShell 脚本 :攻击者出于各种目的,使用 PowerShell 在目标虚拟机上执行恶意代码。 安全中


心会检查 PowerShell 活动中是否存在可疑活动的证据。

传 出攻 击 :攻击者通常会以云资源为目标,目的是使用这些资源发起更多攻击。 例如,可以通过受攻击的
虚拟机对其他虚拟机发起暴力攻击,可以发送垃圾邮件,也可以扫描 Internet 上的开放端口和其他设备。
将机器学习应用到网络流量以后,安全中心即可检测到出站网络通信何时超出标准。 检测到垃圾邮件时,
安全中心还会将异常的电子邮件流量与 Microsoft 365 提供的情报信息关联起来,确定该邮件到底是恶意
邮件,还是合法的电子邮件促销活动。

异常 检测
Azure 安全中心也通过异常检测确定威胁。 与行为分析(依赖于已知的从大型数据集派生的模式)相比,异常检测
更“个性化”,注重特定于用户部署的基线。 运用机器学习确定部署的正常活动,并生成规则,以定义可能表示安
全事件的异常条件。 下面是一个示例:
入站RDP/SSH 暴力破解攻 击 :部署中的有些虚拟机可能很忙,每天需要处理大量的登录,而其他虚拟机可
能只有寥寥数个登录。 Azure 安全中心可以确定这些虚拟机的基线登录活动,并通过机器学习定义正常登录
活动。 如果与为登录相关特性定义的基线之间存在任何差异,则可能会生成警报。 同样,是否具有显著性由
机器学习决定。

连续 威 胁 情 报监视
Azure 安全中心与全世界的安全性研究和数据科学团队合作,持续监视威胁态势的变化情况。 其中包括以下计
划:

威 胁 情 报监视 :威胁情报包括现有的或新出现的威胁的机制、指示器、含义和可操作建议。 此信息在安全


社区共享,Microsoft 会持续监视内部和外部源提供的威胁情报源。

信号共享 :安全团队的见解会跨 Microsoft 的一系列云服务和本地服务、服务器、客户端终结点设备进行


共享和分析。

Microsoft 安全 专 家 :持续接触 Microsoft 的各个工作在专业安全领域(例如取证和 Web 攻击检测)的团


队。

检测优 化 :针对实际的客户数据集运行相关算法,安全研究人员与客户一起验证结果。 通过检出率和误报


率优化机器学习算法。

将这些措施结合起来,形成新的改进型检测方法,让用户能够即时受益。 用户不需采取任何措施。

威胁防护功能:其他 Azure 服务
虚 拟 机: Microsoft 反 恶 意 软 件
适用于 Azure 的 Microsoft 反恶意软件是一个针对应用程序和租户环境所提供的单一代理解决方案,可在后台运
行而无需人工干预。 可以根据应用程序工作负荷的需求,选择默认的基本安全性或高级的自定义配置(包括反恶
意软件监视)来部署保护。 Azure 反恶意软件是为 Azure 虚拟机提供的安全选项,自动安装在所有 Azure PaaS 虚
拟机上。

Microsoft 反 恶 意 软 件核心功能
以下是用于部署和启用应用程序的 Microsoft 反恶意软件的 Azure 功能:

实时 保 护 :监视云服务中和虚拟机上的活动,检测并阻止恶意软件的执行。

计 划的 扫 描 :定期执行有针对性的扫描,检测恶意软件(包括主动运行的程序)。

恶 意 软 件消除 :自动针对检测到的恶意软件采取措施,例如删除或隔离恶意文件以及清除恶意注册表项。

签 名更新 :自动安装最新的保护签名(病毒定义),确保按预定的频率保持最新保护状态。

反 恶 意 软 件引擎更新 :自动更新 Microsoft 反恶意软件引擎。

反 恶 意 软 件平台更新 :自动更新 Microsoft 反恶意软件平台。

主 动 保 护 :将检测到的威胁和可疑资源的遥测元数据报告给 Microsoft Azure,以确保针对不断演变的威


胁局势做出快速响应,并通过 Microsoft 主动保护系统启用实时同步签名传递。

示例 报 告 :将示例提供并报告给 Microsoft 反恶意软件服务,帮助改善服务并实现故障排除。

排除 项 :允许应用程序和服务管理员配置特定的文件、进程以及驱动器,以便出于性能和其他原因将其从
保护和扫描中排除。

反 恶 意 软 件事件收集 :在操作系统事件日志中记录反恶意软件服务的运行状况、可疑活动及采取的补救
措施,并将这些数据收集到客户的 Azure 存储帐户。

Azure SQL 数据 库 威 胁检测


Azure SQL 数据库威胁检测是内置于 Azure SQL 数据库服务的新安全智能功能。 全天候了解、分析及检测异常
数据库活动,Azure SQL 数据库威胁检测可识别针对数据库的潜在威胁。

发生可疑数据库活动时,安全监管员或其他指定的管理员可以获取相关即时通知。 每个通知提供可疑活动的详
细信息,以及如何进一步调查和缓解威胁的建议。

目前,Azure SQL 数据库威胁检测可检测潜在的漏洞和 SQL 注入攻击,以及异常的数据库访问模式。

在收到威胁检测的电子邮件通知后,用户可以通过邮件中的深层链接来导航和查看相关审核记录。 此链接可打
开审核查看器或预配置的审核 Excel 模板,该模板显示发生可疑事件时的相关审核记录,具体如下所示:

具有异常数据库活动的数据库/服务器的审核存储。

用于在事件发生时编写审核日志的相关审核存储表。

事件发生后的审核时间记录。

事件发生时具有类似事件 ID 的审核记录(对于某些检测程序可选)。

SQL 数据库威胁检测程序使用以下检测方法之一:
确定性 检测 :检测 SQL 客户端查询中与已知攻击匹配的可疑模式(基于规则)。 此方法具有高检测率和低
误报率,但是覆盖率有限,因为它属于“原子检测”类别。

行 为检测 :检测异常活动,这些活动是最近 30 天内未显示的数据库中的异常行为。 SQL 客户端异常活动


的示例有失败登录或查询次数激增、提取大量数据、异常的 canonical 查询或访问数据库所用的 IP 地址不
常见。

应 用程序网关 Web 应 用程序防火 墙


Web 应用程序防火墙 (WAF) 是 Azure 应用程序网关的一项功能,它为使用应用程序网关实现标准应用程序传递
控制功能的 Web 应用程序提供保护。 为此,Web 应用程序防火墙保护这些应用程序,免受开放 Web 应用程序
安全计划 (OWASP) 前 10 个常见的 Web 漏洞中大多数漏洞的威胁。

保护包括:

SQL 注入保护。
跨站点脚本保护。

常见 Web 攻击保护,例如命令注入、HTTP 请求走私、HTTP 响应拆分和远程文件包含攻击。


防止 HTTP 协议违反行为的保护。

防止 HTTP 协议异常行为(例如缺少主机用户代理和接受标头)的保护。

防止自动程序、爬网程序和扫描程序。

检测常见应用程序错误配置(即 Apache、IIS 等)。

在应用程序网关配置 WAF 可提供以下优点:

无需修改后端代码即可保护 Web 应用程序免受 Web 漏洞和攻击的威胁。

在应用程序网关背后同时保护多个 Web 应用程序。 应用程序网关支持最多托管 20 个网站。

使用应用程序网关 WAF 日志生成的实时报告,针对攻击监视 Web 应用程序。

有助于满足符合性要求。 某些符合性控件要求 WAF 解决方案保护所有面向 Internet 的终结点。

异常 检测API :使用 Azure 机器学 习 生成


异常情况检测 API 是有助于检测时序数据中的各种异常模式的 API。 API 将异常分数分配给时序中的每个数据
点,这些分数可用于生成警报、通过仪表板进行监视或与出票系统连接。

异常检测 API 可以检测时序数据中以下类型的异常:

峰 值 和低 值 :监视服务中的登录失败次数或电子商务网站中的结账次数时,异常的峰值和低值指示安全攻
击或服务中断。

正 值 和 负值趋势 :监视计算中的内存使用情况时,可用内存逐渐减少表示存在内存泄漏的可能性。 对于
服务队列长度监视,持续上升的趋势表示可能存在软件问题。

级别 更改和 动态值 范 围 的更改 :监视器会监视服务升级后服务延迟中的级别更改或升级后较低级别的异


常。

基于机器学习的 API 支持:

灵活可靠的 检测 :通过异常情况检测模型,用户能配置敏感性设置并在周期性和非周期性数据集中检测
异常。 用户可以调整异常检测模型,以便按照需要调整检测 API 的敏感度。 这意味着可选择使用或不使用
周期模式来检测具有不同可见度的数据异常。

可 缩 放的及 时检测 :对于数百万动态更改数据集,如果使用由专家的专业知识设置的预设置阈值进行监


视的传统方法,成本高且不可缩放。 此 API 中的异常情况检测模型经过学习,并通过历史数据和实时数据
自动优化模型。

可操作的主 动检测 :慢速趋势和级别更改检测可应用于早期异常情况检测。 检测到的早期异常信号可用


于指导人员调查问题区域并对其采取措施。 此外,可基于此异常情况检测 API 服务开发根本原因分析模
型和警报工具。

异常情况检测 API 是针对各种方案(例如服务运行状况和 KPI 监视、IoT、性能监视和网络流量监视)的高效解决


方案。 以下是一些可使用此 API 的常见方案:

IT 部门需要可及时跟踪事件、错误代码、使用情况日志和性能(CPU、内存等)的工具。
在线商务网站需要跟踪客户活动、页面查看次数、点击次数等。

公用事业公司需要跟踪水、天然气、电和其他资源的用量。

设施或建筑管理服务需要监视温度、湿度、人流量等。

IoT/制造商需要使用时序传感器数据监视工作流、质量等。
客户服务中心等服务提供商需要监视服务需求趋势、事件量、等候队列长度等。
业务分析部门需要实时监视业务 KPI(如销售量、客户满意度或定价)的异常变化。

Cloud App Security


Cloud App Security 是 Microsoft Cloud Security 堆栈的一个重要组成部分。 这是一种综合解决方案,可帮助向云
迁移的组织充分利用云应用程序。 通过提升的活动可见性保持掌控能力。 它还有助于增强跨云应用程序的对关
键数据的保护能力。

借助有助于发现影子 IT、评估风险、强制实施策略、调查活动和阻止威胁的工具,组织可以更安全地移到云端,同
时保持对关键数据的控制。

发现 使用 Cloud App Security 发现影子 IT。 通过在云环境中发现


应用、活动、用户、数据和文件,获得可见性。 发现连接到云的
第三方应用。

调查 通过使用云取证工具深入了解网络中的风险应用、特定用户
和文件,从而调查云应用。 从云中收集的数据中查找模式。 生
成报告以监视云。

控制 通过设置策略和警报实现对网络云流量的最大控制,从而降
低风险。 使用 Cloud App Security 将用户迁移到安全的经过
批准的替代云应用。

保护 使用 Cloud App Security 批准或阻止应用程序,强制执行数据


丢失防护、控制权限和共享,以及生成自定义报告和警报。

控制 通过设置策略和警报实现对网络云流量的最大控制,从而降
低风险。 使用 Cloud App Security 将用户迁移到安全的经过
批准的替代云应用。
Cloud App Security 通过以下方式将可见性与云集成:
使用 Cloud Discovery 映射并确定组织使用的云环境和云应用。

批准和禁止云中的应用。

为实现连接到的应用的可见性和管理,使用利用提供程序 API 的、易于部署的应用连接器。

通过设置策略并不断对其进行微调,实现持续控制。

从这些源收集数据时,Cloud App Security 会对其运行复杂的分析。 它会立即向你发出有关异常活动的警报,帮


助你获得对云环境的深度了解。 可以在 Cloud App Security 中配置策略,并使用它来保护云环境中的所有内容。

通过 Azure Marketplace 的第三方威胁防护功能


Web 应 用程序防火 墙
Web 应用程序防火墙会检查入站 Web 流量,并阻止 SQL 注入、跨站点脚本、恶意软件上传和应用程序 DDoS 攻
击及其他针对 Web 应用程序的攻击。 它还会检查后端 Web 服务器的响应,实现针对数据丢失预防 (DLP)。 集成
的访问控制引擎使管理员能够为身份验证、授权和核算 (AAA) 创建精细的访问控制策略,这将增强组织的身份验
证和用户控制。

Web 应用程序防火墙提供以下优点:
检测并阻止 SQL 注入、跨站点脚本、恶意软件上传、应用程序 DDoS 或任何其他针对应用程序的攻击。

身份验证和访问控制。

扫描出站流量以检测敏感数据,并可屏蔽或阻止信息泄露。

使用缓存、压缩和其他流量优化功能,加快 Web 应用程序内容的传送。


有关 Azure 市场中提供的 Web 应用程序防火墙的示例,请参阅 Barracuda WAF、Brocade 虚拟 Web 应用程序防
火墙 (vWAF)、Imperva SecureSphere 和 ThreatSTOP IP 防火墙。

后续步骤
应对当前的威胁:有助于确定以 Azure 资源为目标的活跃威胁,并提供快速响应所需的见解。

Azure SQL 数据库威胁检测:可帮助解决有关数据库潜在威胁的问题。


Azure 安全⽇志记录和审核
2021/2/9 • • Edit Online

Azure 提供多种不同的可配置安全审核和日志记录选项,帮助你识别安全策略和机制方面的差距。 本文介绍如何


生成、收集和分析 Azure 上托管的服务的安全日志。

NOTE
本文中的某些建议可能会导致数据、网络或计算资源使用量增加,还可能导致许可或订阅成本增加。

Azure 中的日志类型
云应用程序很复杂,包含很多移动部件。 日志记录数据可以提供有关应用程序的见解,并帮助你:

排查过去的问题,或避免潜在的问题
提高应用程序性能或可维护性
自动执行本来需要手动干预的操作

Azure 日志划分为以下类型:
控制 / 管理日志 提供有关 Azure 资源管理器 CREATE、UPDATE 和 DELETE 操作的信息。 有关详细信息,请
参阅 Azure 活动日志。

数据平面日志 提供作为 Azure 资源使用情况的一部分引发的事件的相关信息。 此类日志的示例是虚拟


机 (VM) 中的 Windows 事件系统、安全性、应用程序日志以及通过 Azure Monitor 配置的诊断日志。

已 处 理的事件 提供已以用户名义处理的分析事件/警报的相关信息。 此类日志的示例是 Azure 安全中心


警报,Azure 安全中心已处理和分析了订阅,并提供简明的安全警报。

下表列出了 Azure 中最重要的日志类型:

活动日志 Azure 资源管理器资源上的 提供见解,方便用户了解对 Rest API、Azure Monitor


控制平面事件 订阅中的资源执行的操作。

Azure 资源日志 关于订阅中 Azure 资源管理 提供见解,以便深入了解资 Azure Monitor


器资源操作频繁生成的数据 源本身执行的操作。

Azure Active Directory 报告 日志和报告 报告有关用户和组管理的用 图形 API


户登录活动和系统活动信
息。

虚拟机和云服务 Windows 事件日志服务和 在虚拟机上捕获系统数据和 Azure Monitor 中的


Linux Syslog 日志记录数据,并将这些数 Windows(使用 Windows
据传输到所选的存储帐户 Azure 诊断 [WAD] 存储)和
中。 Linux

Azure 存储分析 存储执行日志记录并为存储 提供相关信息,以便深入了 REST API 或客户端库


帐户提供指标数据 解如何跟踪请求、分析使用
情况趋势以及诊断存储帐户
的问题。
网络安全组 (NSG) 流日志 采用 JSON 格式,并根据规 显示有关通过网络安全组的 Azure 网络观察程序
则显示出站和入站流 入口和出口 IP 流量的信息。

Application Insights 日志、异常和自定义诊断 提供多个平台上面向 Web REST API,Power BI


开发人员的应用程序性能监
视 (APM) 服务。

处理数据/安全警报 Azure 安全中心警报、Azure 提供安全信息和警报。 REST API,JSON


Monitor 日志警报

与本地 SIEM 系统进行日志集成


集成安全中心警报介绍如何将安全中心警报以及 Azure 诊断日志和 Azure 审核日志收集的虚拟机安全事件与
Azure Monitor 日志或 SIEM 解决方案同步。

后续步骤
审核和日志记录:通过维护可视性和快速响应及时安全警报来保护数据。

Azure 中的安全日志记录和审核日志收集:实施这些设置可确保 Azure 实例收集正确的安全和审核日志。


配置网站集的审核设置:如果你是网站集管理员,请检索单个用户的操作历史记录,以及在特定日期范围
内执行的操作的历史记录。

在 Microsoft 365 安全中心内搜索审核日志:使用 Microsoft 365 安全中心搜索统一的审核日志,并查看组


织中的用户和管理员活动。
Azure 安全管理和监视概述
2021/2/9 • • Edit Online

本文概述了 Azure 提供的安全功能和服务,以帮助管理和监视 Azure 云服务和虚拟机。

Azure 基于角色的访问控制
Azure 基于角色的访问控制 (Azure RBAC) 为 Azure 资源提供详细的访问管理。 使用 Azure RBAC,可以仅授予用
户执行其作业所需的访问权限。 Azure RBAC 还有助于确保用户离开组织后无法访问云中的资源。

了解详细信息:

有关 Azure RBAC 的 Active Directory 团队博客


Azure 基于角色的访问控制 (Azure RBAC)

反恶意软件
通过 Azure,可使用主要安全厂商(例如 Microsoft、Symantec、Trend Micro、McAfee 和 Kaspersky)的反恶意软
件。 此软件可帮助保护虚拟机免受恶意文件、广告程序和其他威胁的侵害。

适用于 Azure 云服务和虚拟机的 Microsoft 反恶意软件提供了为 PaaS 角色和虚拟机安装反恶意软件代理的能


力。 基于 System Center Endpoint Protection,此功能将经验证的本地安全技术引入到了云。

我们还为 Azure 平台中趋势的 深度安全 和 SecureCloud 产品提供了深度集成。 DeepSecurity 是一个防病毒解决


方案,SecureCloud 是一个加密解决方案。 DeepSecurity 通过扩展模型部署在 VM 内部。 通过 Azure 门户 UI 和
PowerShell,用户可以选择使用即将启动的新 VM 或已部署的现有 VM 内部的 DeepSecurity。
在 Azure 上也支持 Symantec Endpoint Protection (SEP)。 通过门户集成,你能够表明想要在 VM 内使用 SEP。
SEP 可以通过 Azure 门户安装在新的 VM 上,也可以通过 PowerShell 安装在现有 VM 上。
了解详细信息:

在 Azure 虚拟机上部署反恶意软件解决方案
适用于 Azure 云服务和虚拟机的 Microsoft 反恶意软件
如何在 Windows VM 上安装和配置 Trend Micro Deep Security 即服务
如何在 Windows VM 上安装和配置 Symantec Endpoint Protection
New Antimalware Options for Protecting Azure Virtual Machines(用于保护 Azure 虚拟机的新反恶意软件选
项)

多重身份验证
Azure AD 多重身份验证是一种需要使用多种验证方法的身份验证方法。 它为用户登录和事务添加了关键的附加
安全层。

多重身份验证可帮助保护对数据和应用程序的访问,同时可以满足用户对简单登录过程的需求。 它通过各种验
证选项(例如电话、短信、移动应用通知或验证码)和第三方 OATH 令牌来提供强大的身份验证。

了解详细信息:

多重身份验证
什么是 Azure AD 多重身份验证?
Azure AD 多重身份验证的工作原理
ExpressRoute
可使用 Azure ExpressRoute 通过连接服务提供商所提供的专用连接,将本地网络扩展到 Microsoft 云。 使用
ExpressRoute 可与 Azure、Microsoft 365 和 CRM Online 等 Microsoft 云服务建立连接。 连接可以来自:
任意位置之间的 (IP VPN) 网络。
点到点以太网。
通过位于归置设施的连接服务提供商提供的虚拟交叉连接。

ExpressRoute 连接不经过公共 Internet。 它们可提供可靠性、速度、延迟和安全性这几个方面均比基于 Internet


的典型连接更胜一筹的专用连接。

了解详细信息:

ExpressRoute 技术概述

虚拟网络网关
VPN 网关(也称为 Azure 虚拟网络网关)用于在虚拟网络和本地位置之间发送流量。 VPN 网关还用于在 Azure 内
的多个虚拟网络之间发送流量(网络到网络)。 VPN 网关提供 Azure 和基础结构间的安全跨界连接。

了解详细信息:

关于 VPN 网关
Azure 网络安全概述

Privileged Identity Management


用户有时候需要在 Azure 资源或者其他 SaaS 应用程序中执行特权操作。 这通常意味着,组织授予他们永久的
Azure Active Directory (Azure AD) 访问特权。
这会给云托管的资源不断增大安全风险,因为组织无法充分监视这些用户正在使用特权访问执行哪些操作。 此
外,如果有访问特权的用户帐户被泄露,此安全漏洞可能会影响组织的总体云安全性。 Azure AD Privileged
Identity Management 可通过降低特权的暴露时间和加强对使用情况的了解来帮助解决此风险。
Privileged Identity Management 为角色或“及时”管理员访问引入了临时管理员的概念。 这种类型的管理员是需
要为该分配的角色完成激活过程的用户。 激活过程会在指定的时段内将 Azure AD 中的用户角色分配从非活动
更改为活动。

了解详细信息:

Azure AD Privileged Identity Management


Azure AD Privileged Identity Management 入门

标识保护
Azure AD 标识保护提供了可疑登录活动和潜在漏洞的统一视图来帮助保护企业。 “标识保护”根据以下信号检测
用户和特权(管理员)标识的可疑活动:

暴力攻击。
凭据泄漏。
从不熟悉的位置和易感染病毒的设备登录。

通过提供通知和建议的补救措施,标识保护有助于实时降低风险。 它会计算用户风险严重性。 可配置基于风险


的策略,自动保护应用程序访问免受将来的威胁侵害。

了解详细信息:
Azure Active Directory 标识保护
第 9 频道:Azure AD 和标识展示:“标识保护”预览

安全中心
Azure 安全中心可帮助防范、检测和应对威胁。 利用安全中心,你可以更深入地了解 Azure 资源以及混合云环境
中的资源的安全性。

安全中心对已连接的资源执行持续的安全评估,并将其配置和部署与 Azure 安全基准 进行比较,以提供针对你


的环境定制的详细安全建议。

安全中心通过以下方式帮助优化和监视 Azure 资源的安全:

你可根据以下内容为 Azure 订阅资源定义策略:


组织的安全需求。
应用程序的类型或每个订阅中数据的敏感度。
适用于你的订阅的任何行业或法规标准或基准。
监视 Azure 虚拟机、网络和应用程序的状态。
提供按优先级排列的安全警报列表,包括集成的合作伙伴解决方案中的警报。 它还提供了快速调查攻击所需
的信息以及如何修复攻击的建议。

了解详细信息:

Azure 安全中心简介
提高 Azure 安全中心中的安全评分

Intelligent Security Graph


Intelligent Security Graph 在 Microsoft 产品和服务中提供实时威胁防护。 它使用链接大量威胁情报和安全数据
的高级分析,以提供可加强组织安全性的见解。 Microsoft 使用高级分析,每月处理超过 4,500 亿次身份验证、扫
描 4,000 亿封电子邮件是否存在恶意软件和钓鱼,并更新 10 亿台设备,以提供更丰富的见解。 这些见解可帮助
你的组织快速检测并响应攻击。

Intelligent Security Graph

后续步骤
了解共担责任模型、由 Microsoft 处理的安全任务,以及由你处理的任务。

有关安全管理的详细信息,请参阅 Azure 中的安全管理。


Azure 中的安全管理
2021/2/9 • • Edit Online

Azure 订阅者可从多个设备管理他们的云环境,这些设备包括管理工作站、开发人员电脑,甚至是具有特定于任
务的权限的特权最终用户设备。 在某些情况下,可通过基于 Web 的控制台(例如 Azure 门户)来执行管理功能。
在其他情况下,可能存在通过虚拟专用网络 (VPN)、终端服务、客户端应用程序协议或(以编程方式)通过 Azure
服务管理 API (SMAPI) 从本地系统直接连接到 Azure。 此外,客户端终结点(例如平板电脑或智能手机)可以加入
域或者受到隔离且不受管理。

尽管多种访问和管理功能提供了丰富的选项,但这种变化性可能会让云部署承受巨大风险。 可能难以管理、跟踪
和审核管理操作。 这种差异还可能由于用于管理云服务的客户端终结点进行的访问不受管制而带来安全威胁。
使用普通工作站或专用工作站开发和管理基础结构将会打开诸如 Web 浏览(例如水坑攻击)或电子邮件(例如社
交工程和网络钓鱼)等不可预测的威胁媒介。

在这种类型的环境中,发生攻击的可能性将会增加,因为难以构造安全策略和机制来适当管理各种终结点对
Azure 接口(例如 SMAPI)的访问。
远 程管理威 胁
攻击者经常会尝试通过入侵帐户凭据(例如,通过暴力破解密码、网络钓鱼和搜集凭据)或诱骗用户运行有害代码
(例如,从具有偷渡式下载的有害网站或从有害电子邮件的附件)来获取特权访问权限。 远程管理的云环境由于
具有随时随地访问的特性,因此如果帐户遭到入侵,风险会大增。

即使主要管理员帐户受到严格控制,攻击者仍可使用较低级别的用户帐户来利用安全策略中的弱点。 缺乏适当
的安全培训而使帐户信息意外泄漏或曝光,也可能导致数据泄露。

如果用户工作站也用于管理任务,可能会在许多不同的位置遭到入侵。 无论用户是在浏览 Web、使用第三方工


具和开源工具,还是打开包含特洛伊木马的有害文档,都将面临入侵风险。

一般情况下,大多数导致数据泄漏的锁定式攻击,追根究底都是台式机上的浏览器入侵、外挂程序(例如 Flash、
PDF、Java)和鱼叉式网络钓鱼(电子邮件)所造成的。 这些计算机在用于开发或管理其他资产时,可能具有可供访
问运行中服务器或网络设备以执行操作的管理级别权限或服务级别权限。

操作安全性基 础 知 识
为了提升管理和操作的安全性,可以减少可能的入口点数目以尽可能缩小客户端的受攻击面。 这可以通过“职责
分离”和“环境隔离”安全原则来实现。

让敏感功能彼此隔离以降低某个级别的错误导致另一个级别出现数据泄漏的可能性。 示例:

管理任务不应该与可能将造成入侵的活动合并(例如,管理员的电子邮件中有恶意代码,从而感染基础结构服
务器)。
用于高敏感性操作的工作站也不应该是用于高风险用途(例如浏览 Internet)的同一系统。

通过删除不必要的软件来减少系统的受攻击面。 示例:

如果设备的主要用途是管理云服务,则标准的管理、支持或开发工作站都不应该请求安装电子邮件客户端或
其他生产力应用程序。

对基础结构组件拥有管理员访问权限的客户端系统应该尽可能受到严格策略的限制,以降低安全风险。 示例:

安全策略可以包含拒绝设备进行开放访问 Internet 和使用严格防火墙配置的组策略设置。


如果需要直接访问,请使用 Internet 协议安全性 (IPsec) VPN。
配置不同的管理和开发 Active Directory 域。
隔离和筛选管理工作站的网络流量。
使用反恶意软件的软件。
实施多重身份验证以降低凭据失窃的风险。

合并访问资源并消除不受管理的终结点也可以简化管理任务。

为 Azure 远 程管理提供安全性
Azure 提供了安全机制来帮助管理员管理 Azure 云服务和虚拟机。 这些机制包括:
身份验证和 Azure 基于角色的访问控制 (Azure RBAC)。
监视、日志记录和审核。
证书和加密通信。
Web 管理门户。
网络数据包筛选。

借助客户端安全配置和管理网关的数据中心部署,可以限制并监视管理员对于云应用程序和数据的访问。

NOTE
本文中的某些建议可能会导致数据、网络或计算资源使用量增加,从而增加许可或订阅成本。

强化的管理工作站
强化工作站的目标是要去除其他所有功能,只留下其运行所需的最重要功能,尽可能缩小潜在的受攻击面。 系统
强化包括安装最少量的服务和应用程序、限制应用程序执行、限制网络只能访问所需资源,以及让系统随时保持
最新状态。 此外,使用经过强化的管理工作站能够将管理工具和活动与其他最终用户任务隔离开来。

在本地企业环境中,可以通过专用的管理网络、必须用身份卡才能进入的服务器机房以及在受保护的网络区域上
执行的工作站,限制物理基础结构的受攻击面。 在云或混合 IT 模型中,由于无法实际接触到 IT 资源,因此想要
让管理服务保持安全是更复杂的任务。 实现保护解决方案需要小心软件设置、安全为主的处理程序及完善的策
略。

在锁定的工作站中使用仅需最低特权的最少软件使用量来进行云管理(以及应用程序开发),可以通过将远程管
理和开发环境标准化来降低引发安全事件的风险。 强化后的工作站配置可通过关闭恶意代码和入侵程序使用的
许多常见手段,来帮助避免用于管理重要云资源的帐户遭到入侵。 具体而言,可以使用 Windows AppLocker 和
Hyper-V 技术来控制和隔离客户端系统行为并缓解威胁,包括电子邮件或 Internet 浏览。
在强化后的工作站上,管理员将运行标准用户帐户(它将阻止管理级别的执行),关联的应用程序将由允许列表进
行控制。 强化后的工作站的基本要素如下:

活动的扫描和修补。 部署反恶意代码软件,定期执行漏洞扫描,及时使用最新的安全更新来更新所有工作站。
有限的功能。 卸载任何不需要的应用程序,并禁用不必要的(启动)服务。
强化网络。 使用 Windows 防火墙规则,仅允许与 Azure 管理相关的有效 IP 地址、端口和 URL 。 同时确保阻
止工作站的入站远程连接。
执行限制。 仅允许运行一组管理所需的预定义可执行文件(称为“默认拒绝”)。 默认情况下,除非已在允许列
表中明确定义,否则应该拒绝用户运行任何程序的权限。
最低特权。 管理工作站的用户不应该拥有本地计算机本身的任何管理特权。 这样,他们无法更改系统配置或
系统文件(无论是有意或无意)。

通过在 Active Directory 域服务 (AD DS) 中使用 组策略对象 (GPO),并通过(本地)管理域将其应用到所有管理帐


户,可以强制实施上述所有要素。

管理服 务 、 应 用程序和数据
可以在 Azure 门户或 SMAPI 中通过 Windows PowerShell 命令行接口或利用这些 RESTful 接口的自建应用程序
来执行 Azure 云服务配置。 使用这些机制的服务包括 Azure Active Directory (Azure AD)、Azure 存储、Azure 网
站和 Azure 虚拟网络,等等。

虚拟机部署的应用程序将根据需要提供自身的客户端工具和界面(例如 Microsoft Management Console


(MMC))、企业管理控制台(例如 Microsoft System Center 或 Windows Intune)或其他管理应用程序(例如
Microsoft SQL Server Management Studio)。 这些工具通常驻留在企业环境或客户端网络中。 它们可能依赖于
需要直接有状态连接的特定网络协议,例如远程桌面协议 (RDP)。 有些可能包含不应该通过 Internet 公开发布或
访问的具有 Web 功能的接口。

可以使用多重身份验证、X.509 管理证书和防火墙规则来限制访问 Azure 中的基础结构和平台服务管理。 Azure


门户和 SMAPI 需要传输层安全性 (TLS)。 但是,部署到 Azure 的服务和应用程序需要根据应用程序采取适当的保
护措施。 可以通过标准化的强化后工作站配置更轻松地经常启用这些机制。

管理网关
若要集中管理所有管理访问权限并简化监视与日志记录,可以在本地网络中部署连接到 Azure 环境的专用
Remote Desktop Gateway(远程桌面网关)(RD 网关)服务器。
远程桌面网关是基于策略的 RDP 代理服务,可强制实施安全要求。 同时实现 RD 网关与 Windows Server 网络
访问保护 (NAP),可帮助确保只有符合 Active Directory 域服务 (AD DS) 组策略对象 (GPO) 创建的特定安全运行
状况条件的客户端可以连接。 此外:

在 RD 网关上预配 Azure 管理证书,使它成为可以访问 Azure 门户的唯一主机。


将 RD 网关加入管理员工作站所在的同一个管理域。 在具有对 Azure AD 的单向信任的域中使用站点到站点
IPsec VPN 或 ExpressRoute 时,或者要联合本地 AD DS 实例与 Azure AD 之间的凭据时,就必须这样做。
配置客户端连接授权策略,以让 RD 网关验证客户端计算机名称是否有效(已加入域)并可以访问 Azure 门
户。
针对 Azure VPN 使用 IPsec 以进一步防止管理流量遭到窃听和令牌失窃,或考虑使用通过 Azure
ExpressRoute 隔离的 Internet 链接。
启用多重身份验证 (通过 Azure AD 多重身份验证) 或通过 RD 网关登录的管理员的智能卡身份验证。
在 Azure 中配置源 IP 地址限制或网络安全组,将允许的管理终结点数降到最低。

安全指导原则
一般情况下,帮助保护用于云的管理员工作站的做法,与用于任何本地工作站的做法类似 — 例如,最小化生成
和限制权限。 云管理的某些独特之处更类似于远程或带外企业管理。 这些特点包括使用和审核凭据、增强安全
的远程访问以及威胁检测和响应。

身份 验证
可以使用 Azure 登录限制来限制用于访问管理工具的源 IP 地址和审核访问请求。 要帮助 Azure 识别管理客户端
(工作站和/或应用程序),可以同时配置 SMAPI(通过客户开发的工具,例如 Windows PowerShell cmdlet)和
Azure 门户,以要求除 TLS/SSL 证书外,还必须安装客户端管理证书。 我们还建议管理员访问需要经过多重身份
验证。

部署到 Azure 的某些应用程序或服务可能会针对用户和管理员访问拥有自己的身份验证机制,而其他应用程序


或服务则会充分利用 Azure AD。 根据是通过 Active Directory 联合身份验证服务 (AD FS)、使用目录同步还是仅
在云中维护用户帐户来联合凭据,使用 Microsoft Identity Manager (Azure AD 高级版中已随附)可帮助管理资源
之间的标识生命周期。

连接
有多种机制可供帮助保护客户端与 Azure 虚拟网络的连接。 在这些机制中,有两个机制(站点到站点 VPN (S2S)
和点到站点 VPN (P2S))支持使用行业标准 IPsec (S2S) 或安全套接字隧道协议 (SSTP) (P2S) 来进行加密和隧道传
输。 当 Azure 连接到面向公众的 Azure 服务管理(例如 Azure 门户)时,Azure 需要超文本安全传输协议
(HTTPS)。
未通过 RD 网关连接到 Azure 的独立强化工作站应使用基于 SSTP 的点到站点 VPN 来与 Azure 虚拟网络建立初
始连接,并从 VPN 隧道与各个虚拟机建立 RDP 连接。

管理 审 核与策略 强 制 实 施
一般而言,有两种方法可用于帮助保护管理程序:审核和策略强制实施。 同时采用这两种方法可进行全面控制,
但并非所有情况下都能这样做。 此外,每种方法在管理安全时都需要不同程度的风险、成本和精力,特别是当它
涉及到对个人和系统体系结构给予的信任级别时。

监视、日志记录和审核可为跟踪和了解管理活动提供基础,但受限于所生成的数据量,它不一定都能巨细无遗地
审核所有操作。 但是,审核管理策略的效果是最佳做法。

包含严格访问控制的策略强制实施具有可控制管理员操作的编程机制,并可帮助确保使用所有可能的保护措施。
日志记录可提供强制实施的证明,以及什么人在何时从什么地方执行了什么操作的日志。 日志记录还可让你审
核和交叉检查管理员如何遵循策略的相关信息,同时提供活动的证据。

客户端配置
对于强化的工作站,我们提供三种主要配置。 这三者之间最大的差异在于成本、可用性和可访问性,但它们提供
的所有选项都有类似的安全设置文件。 下表简要分析了各种配置的优点与风险。 (请注意,“企业电脑”指的是将
为所有域用户(无论角色为何)部署的标准台式机配置)。

独立的强化工作站 受到严格控制的工作站 增加专用台式机的成本

- 降低应用程序被利用的风险 增加管理工作

- 明确的职责分离 -

将企业电脑用作虚拟机 降低硬件成本 -

- 角色和应用程序隔离 -

必须将强化的工作站用作主机而不是来宾,且主机操作系统与硬件之间没有任何组件。 遵循“干净源原则”(也称
为“安全来源”)意味着主机应该是最可靠的。 否则,强化的工作站(来宾)在其托管所在的系统上容易受到攻击。
可以通过专用系统映像为每一台强化工作站进一步隔离管理功能,使其只具有管理选定的 Azure 和云应用程序
所需的工具和权限,以及用于必要任务的特定本地 AD DS GPO。

对于没有任何本地基础结构的 IT 环境(例如,由于所有服务器都在云端而不能访问 GPO 的本地 AD DS 实


例),Microsoft Intune 等服务可以简化工作站配置的部署和维护任务。

用于管理的独立 强 化工作站
使用独立的强化工作站时,管理员使用一台电脑或膝上型计算机来执行管理任务,并使用另一台不同的电脑或膝
上型计算机来执行非管理任务。 专门负责管理 Azure 服务的工作站不需要安装其他应用程序。 此外,使用的工
作站如果支持受信任的平台模块 (TPM) 或类似的硬件级加密技术,将有助于进行设备身份验证和预防特定攻击。
TPM 还可以使用 BitLocker 驱动器加密来支持系统驱动器的整卷保护。
在独立的强化工作站方案中(如下所示),Windows 防火墙(或非 Microsoft 客户端防火墙)的本地实例将配置为
阻止入站连接,例如 RDP。 管理员可以登录到强化的工作站,并在与 Azure 虚拟网络建立 VPN 连接之后启动连
接到 Azure 的 RDP 会话,但无法登录到企业电脑并使用 RDP 连接到强化的工作站本身。

将企 业电脑 用作虚 拟 机
在部署单个独立强化工作站需要高昂成本或者不方便的情况下,强化的工作站可以托管用于执行非管理任务的
虚拟机。
若要避免使用单一工作站来进行管理和其他日常工作任务所可能引发的诸多安全风险,可以在强化的工作站部
署 Windows Hyper-V 虚拟机。 此虚拟机可用作企业电脑。 企业电脑环境可以与主机保持隔离,以减少其受攻击
面,并使得用户的日常活动(例如电子邮件)不会与机密的管理任务共存。

企业电脑虚拟机在受保护的空间内运行,并提供用户应用程序。 主机仍是“干净源”,并且将在根操作系统中强制
实施严格的网络策略(例如,阻止来自虚拟机的 RDP 访问)。

最佳实践
管理 Azure 中的应用程序和数据时,请注意以下附加指导原则。

准则
不要因为工作站已被锁定,就认为不需要满足其他常见安全要求。 由于管理员帐户通常拥有提升权限的访问级
别,因此潜在风险会提高。 下表显示了风险及其替代安全做法的示例。

不要通过电子邮件发送管理员访问凭据或其他机密(例如 用声音提供帐户名称和密码(但不要将它们存储在语音邮件
TLS/SSL 或管理证书) 中)以保持机密性、远程安装客户端/服务器证书(通过加密会
话)、从受保护的网络共享下载,或通过可移动媒体手动分发。

- 主动管理管理证书生命周期。

不要在应用程序存储中存储未加密或未哈希处理的帐户密码 创建安全管理策略和系统强化策略,并将它们应用到开发环
(例如在电子表格、SharePoint 站点或文件共享中)。 境。

- 使用 Enhanced Mitigation Experience Toolkit 5.5 证书绑定规


则,以确保能够正常访问 Azure SSL/TLS 站点。

不要在管理员之间共享帐户和密码,或在多个用户帐户或服 创建专用的 Microsoft 帐户来管理 Azure 订阅 — 此帐户不用


务之间重复使用密码,特别是用于社交媒体或其他非管理活 于个人电子邮件。
动的帐户或服务。

不要通过电子邮件发送配置文件。 应从受信任的源(例如,加密的 USB 闪存驱动器)而不是从可


轻易入侵的机制(例如电子邮件)安装配置文件和档案。
不要使用弱密码或简单的登录密码。 强制实施强密码策略、过期周期(首次使用时更改)、控制台超
时和自动帐户锁定。 使用客户端密码管理系统配合多重身份
验证来访问密码保管库。

不要在 Internet 上公开管理端口。 锁定 Azure 端口和 IP 地址以限制管理访问权限。 有关详细信


息,请参阅 Azure Network Security (Azure 网络安全性)白皮
书。

- 针对所有管理连接使用防火墙、VPN 和 NAP。

Azure 操作
在 Microsoft 的 Azure 操作中,访问 Azure 的生产系统的操作工程师和支持人员将使用强化的工作站电脑与其中
预配的 VM 来进行内部企业网络访问和运行应用程序(例如电子邮件、Intranet 等)。 所有管理工作站计算机都装
有 TPM,主机启动驱动器已使用 BitLocker 加密,并且已加入 Microsoft 主要企业域中的特殊组织单位 (OU)。

系统强化是通过组策略以集中式软件更新来强制实施的。 为了审核和分析,将从管理工作站收集事件日志(例如
安全性和 AppLocker )并将其保存到中心位置。

此外,使用 Microsoft 网络上需要双重身份验证的专用 Jumpbox 来连接到 Azure 的生产网络。

Azure 安全清单
将管理员在强化的工作站上可以执行的任务数降到最低,有助于尽量降低开发和管理环境中的受攻击面。 请使
用以下技术来帮助保护强化的工作站:

IE 强化。 由于 Internet Explorer 浏览器(或任何类似的 Web 浏览器)将与外部服务器广泛交互,因此是有害代


码的主要入口点。 请查看客户端策略并强制要求在保护模式下运行、禁用附加组件、禁用文件下载,并使用
Microsoft SmartScreen 筛选。 确保显示安全警告。 利用 Internet 区域,并创建已为其配置合理强化的受信任
站点列表。 阻止其他所有站点和浏览器内代码,例如 ActiveX 和 Java。
标准用户。 以标准用户的身份运行有许多好处,最重要的好处是通过恶意代码窃取管理员凭据将变得更困
难。 此外,标准用户帐户对根操作系统没有提升的权限,并且许多配置选项和 API 已按默认锁定。
AppLocker。 可以使用 AppLocker 来限制用户可以运行的程序和脚本。 可以在审核或强制模式下运行
AppLocker。 默认情况下,AppLocker 的允许规则可让具有管理员令牌的用户运行客户端上的所有代码。 设置
此规则是为了避免管理员将自己锁定,并且只应用到提升权限的令牌。 另请参阅 Windows Server 核心安全
性中的“代码完整性”。
代码签名。 为管理员使用的所有工具和脚本进行代码签名可提供方便管理的机制来部署应用程序锁定策略。
哈希不会随着代码的快速更改而做出调整,并且文件路径不会提供高度安全性。 应将 AppLocker 规则与
PowerShell 执行策略合并,此策略只允许执行特定的已签名代码和脚本。
组策略。 创建一个全局管理策略,该策略将应用到任何用于管理的域工作站(并阻止来自其他所有用途的访
问),以及在这些工作站上进行身份验证的用户帐户。
安全性增强的预配。 保护基线强化工作站映像以防遭到篡改。 使用加密和隔离等安全措施来存储映像、虚拟
机和脚本,并限制访问(也许可以使用可审核的签入/签出过程)。
修补。 维护一致的生成(或针对开发、操作和其他管理任务使用不同的映像)、定期扫描更改和恶意代码、让生
成保持最新状态,并且只在需要时才激活计算机。
加密。 确保管理工作站装有 TPM 以便能够更安全地启用加密文件系统 (EFS) 和 BitLocker 。
监管。 使用 AD DS GPO 来控制所有管理员的 Windows 接口,例如文件共享。 将管理工作站纳入审核、监视
和日志记录过程中。 跟踪所有管理员和开发人员的访问和使用活动。

摘要
使用强化的工作站配置来管理 Azure 云服务、虚拟机和应用程序,可帮助避免远程管理关键 IT 基础结构所造成
的众多风险和威胁。 Azure 和 Windows 提供了相关机制来帮助保护和控制通信、身份验证与客户端行为。

后续步骤
除了本文中所提到的特定项以外,以下资源也提供了有关 Azure 及相关 Microsoft 服务的更多常规信息:

保护特权访问 – 获取有关设计和构建安全管理工作站以管理 Azure 的技术详细信息


Microsoft 信任中心 - 了解可保护 Azure 结构以及在 Azure 上运行的工作负荷的 Azure 平台功能
Microsoft 安全响应中心 - 可在其中报告 Microsoft 安全漏洞(包括 Azure 问题)或将其通过电子邮件发送到
secure@microsoft.com
Azure 操作安全性概述
2021/2/9 • • Edit Online

Azure 操作安全性是指用户可用于在 Microsoft Azure 中保护其数据、应用程序和其他资产的服务、控件和功能。


它是一个结合了从各种 Microsoft 独有功能获取的知识的框架。 这些功能包括 Microsoft 安全开发生命周期
(SDL)、Microsoft 安全响应中心计划以及对网络安全威胁态势的深入感知。

Azure 管理服务
IT 运营团队负责管理数据中心基础结构、应用程序和数据,包括这些系统的稳定性和安全性。 但是,若要获得日
益增多的复杂 IT 环境的安全洞察信息,通常需要组织从多个安全性和管理系统收集数据。

Microsoft Azure Monitor 日志是基于云的 IT 管理解决方案,可帮助你管理和保护本地和云基础结构。 其核心功


能由在 Azure 中运行的以下服务提供。 Azure 包含多个服务,这些服务可帮助你管理和保护本地和云基础结构。
每项服务都提供特定的管理功能。 可合并服务,实现不同的管理方案。

Azure Monitor
Azure Monitor 可将来自托管源的数据收集到中央数据存储中。 这些数据可能包括事件、性能数据或通过 API 提
供的自定义数据。 收集数据后,可分析、导出数据或发出警报。

可整合来自各种源的数据,并将 Azure 服务中的数据合并到现有的本地环境。 此外,Azure Monitor 日志还能将


数据收集与针对该数据执行的操作明确区分开来,以便能够针对所有类型的数据执行所有操作。

自动化
借助 Azure 自动化,可自动完成通常要在云环境和企业环境中执行的手动、长时间进行、易出错且重复性高的任
务。 不仅节省了时间,还提高了管理任务的可靠性。 甚至还可以计划定期自动执行这些任务。 可使用 Runbook
实现这些过程的自动化,或者使用 Desired State Configuration 实现配置管理的自动化。

备份
Azure 备份是基于 Azure 的服务,可用于备份(或保护)和还原 Microsoft 云中的数据。 Azure 备份将现有的本地
或异地备份解决方案替换为安全可靠、性价比高的云端解决方案。

Azure 备份提供多个组件,可将其下载并部署到适当计算机、服务器或云端。 依据要保护的内容选择部署的组件


或代理。 无论是保护本地数据还是云端数据,所有 Azure 备份组件均可用于将数据备份到 Azure 中的 Azure 恢
复服务保管库中。

有关详细信息,请参阅 Azure 备份组件表。

Site Recovery
Azure Site Recovery 通过协调本地虚拟机和物理机到 Azure 或辅助站点的复制来提供业务连续性。 如果主站点
不可用,可故障转移到辅助位置,使用户能够继续工作。 系统恢复正常后可故障回复。 使用 Azure 安全中心执行
更智能和更有效的威胁检测。

Azure Active Directory


Azure Active Directory (Azure AD) 是一种综合性的标识服务,该服务可:
启用标识和访问管理 (IAM) 作为云服务。
提供中心访问管理、单一登录 (SSO) 及报告功能。
支持 Azure 市场中数千款应用程序(包括 Salesforce、Google Apps、Box 和 Concur )的集成访问管理。

Azure AD 中还包括了整套标识管理功能,其中包括:
多重身份验证
自助服务密码管理
自助组管理
特权帐户管理
Azure 基于角色的访问控制 (Azure RBAC)
应用程序使用情况监视
多种审核
安全监视和警报

借助 Azure Active Directory,可使为合作伙伴与客户(企业或消费者)发布的所有应用程序都具有相同标识和访


问管理功能。 这可让你大幅降低运营成本。

Azure 安全中心
Azure 安全中心有助于预防、检测和响应威胁,同时增加 Azure 资源安全的可见性和可控性。 它为订阅提供集成
的安全监控和策略管理。 它有助于检测可能会被忽视的威胁,适用于各种安全解决方案生态系统。

通过 Azure 安全中心可查看虚拟机的安全设置和监视威胁,保护 Azure 中的虚拟机 (VM) 数据。 安全中心可对虚


拟机进行以下监视:

包含建议配置规则的操作系统安全设置。
缺少的系统安全更新和关键更新。
终结点保护建议。
磁盘加密验证。
基于网络的攻击。

安全中心使用 Azure 基于角色的访问控制 (Azure RBAC)。 Azure RBAC 提供的内置角色可分配给 Azure 中的用
户、组和服务。

安全中心会评估资源的配置以识别安全问题和漏洞。 只有在分配有资源所属的订阅或资源组的“所有者”、“参与
者”或“读取者”角色时,才会在安全中心看到与资源相关的信息。

NOTE
若要深入了解安全中心中的角色和允许的操作,请参阅 Azure 安全中心中的权限。

安全中心使用 Microsoft Monitoring Agent。 此代理与 Azure Monitor 服务使用的代理相同。 通过此代理收集的


数据存储在与 Azure 订阅关联的现有 Log Analytics 工作区或新工作区中,具体取决于 VM 的地理位置。

Azure Monitor
云应用中的性能问题可能会影响业务。 使用多个互连的组件和频繁发布版本时,性能随时可能会下降。 开发一
款应用后,用户通常会发现其中的问题,而你在测试时却找不到这样的问题。 应该立即发现这些问题,并使用工
具来诊断和解决问题。

Azure Monitor 是用于监视 Azure 中运行的服务的基本工具。 它可以提供有关服务吞吐量和周边环境的基础结构


级数据。 如果在 Azure 中管理所有应用,并想要确定是否需要增加或减少资源,则可使用 Azure Monitor 。

还可以利用监视数据深入了解应用程序的情况。 了解这些情况有助于改进应用程序的性能或可维护性,或者实
现本来需要手动干预的操作的自动化。

Azure Monitor 包括以下组件。


Azure 活 动 日志
Azure 活动日志提供相关信息,方便用户了解对订阅中的资源执行的操作。 Azure 活动日志此前称为“审核日
志”或“操作日志”,因为它报告订阅的控制平面事件。

Azure 诊 断日志
Azure 诊断日志由资源发出,提供与该资源的操作相关的各种频繁生成的数据。 这些日志的内容因资源类型而
异。

Windows 事件系统日志是一种 VM 诊断日志类别。 Blob、表和队列日志是存储帐户的诊断日志类别。


诊断日志与活动日志不同。 活动日志提供针对订阅中的资源执行的操作的深入信息。 诊断日志提供资源本身执
行的操作的深入信息。

指标
Azure Monitor 可提供遥测数据,以便用户了解 Azure 上工作负荷的性能与运行状况。 最重要的 Azure 遥测数据
类型是大多数 Azure 资源发出的指标(也称为性能计数器)。 Azure 监视器提供多种方式来配置和使用这些指标,
以便进行监视与故障排除。

Azure 诊 断
Azure 诊断可在部署的应用程序上启用诊断数据收集功能。 可使用各种源的诊断扩展。 目前支持的有 Azure 云
服务角色、运行 Microsoft Windows 的 Azure 虚拟机,以及 Azure Service Fabric。

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

端到端网络可能具有复杂的配置以及资源间的交互。 这会导致复杂方案需通过 Azure 网络观察程序进行基于方


案的监视。

网络观察程序会简化 Azure 网络的监视和诊断。 可使用网络观察程序中的诊断和可视化工具来:

在 Azure 虚拟机上远程捕获数据包。
使用流日志深入了解网络流量。
诊断 Azure VPN 网关和连接。

网络观察程序目前提供以下功能:

拓扑:提供资源组中网络资源间的各种互连和关联的视图。
可变数据包捕获:捕获传入和传出虚拟机的数据包数据。 高级筛选选项和精细控制(例如设置时间与大小限制
的功能)提供了多样性。 数据包数据可以存储在 Blob 存储中,或者以 .cap 格式存储在本地磁盘上。
IP 流验证:根据流信息的 5 元组数据包参数(目标 IP、源 IP、目标端口、源端口和协议)检查数据包是被允许还
是被拒绝。 如果安全组拒绝数据包,则返回拒绝数据包的规则和组。
下一跃点:确定 Azure 网络结构中路由的数据包的下一跃点,以便诊断任何配置不正确的用户定义的路由。
安全组视图:获取在 VM 上应用的有效安全规则。
网络安全组的 NSG 流日志:用于捕获被组中的安全规则允许或拒绝的流量的相关日志。 流由 5 元组信息(源
IP、目标 IP、源端口、目标端口和协议)定义。
虚拟网络网关和连接故障排除:提供对虚拟网关和连接进行故障排除的功能。
网络订阅限制:用于查看网络资源用量与限制。
诊断日志:提供单个窗格来为资源组中的网络资源启用或禁用诊断日志。

有关详细信息,请参阅配置网络观察程序。

云服务提供程序访问透明度
Microsoft Azure 客户密码箱是集成到 Azure 门户中的一项服务,它允许你在 Microsoft 支持工程师需要访问你的
数据来解决问题时进行显式控制,这种情况极少出现。 在极少数情况下,例如调试远程访问问题时,Microsoft 支
持工程师需要提升的权限来解决此问题。 在这种情况下,Microsoft 工程师使用恰时访问服务,该服务提供有限
的限定了时间范围的授权,且仅限访问相关服务。
虽然 Microsoft 在进行访问时始终征求客户同意,但客户密码箱使你能够从 Azure 门户查看并批准或拒绝这样的
请求。 在你批准请求前,不会向 Microsoft 支持工程师授予访问权限。

标准且合规的部署
通过 Azure 蓝图,云架构师和中心信息技术组同样可以定义一组可重复的 Azure 资源,这些资源实现并遵守组织
的标准、模式和要求。
这使得 DevOps 团队可以快速构建并启动新环境,并有信心使用满足组织合规性的基础设施构建它们。 蓝图提
供了一种声明性方法,用于协调各个资源模板和其他项目的部署,例如:

角色分配
策略分配
Azure 资源管理器模板
资源组

DevOps
在采用 Developer Operations (DevOps) 应用程序开发前,团队需要负责收集软件程序的业务要求和编写代码。
然后由一个单独的 QA 团队在独立的开发环境中测试该程序。 如果满足要求,则 QA 团队发布要部署的操作代
码。 部署团队进一步划分为小组,例如网络小组和数据库小组。 每次将软件程序投放到独立的团队时,就会增加
一些瓶颈。

DevOps 可让团队更快、更经济地交付更安全、更优质的解决方案。 使用软件和服务时,客户期望可以获得动态


可靠的体验。 团队必须快速迭代软件更新并衡量更新的影响。 他们必须快速响应新的开发迭代,以解决问题或
提供更多价值。

Microsoft Azure 等云平台消除了传统的瓶颈,帮助将基础结构商品化。 由于关键的优势以及在营收中的份量,软


件在每家企业中都占据主导地位。 没有任何组织、开发人员或者 IT 工作人员可以或者应该避免 DevOps 的活
动。

成熟的 DevOps 从业者会采用以下多种做法。 这些做法涉及到基于业务方案构建策略的人员。 工具可以帮助自


动完成各种做法。

敏捷的规划和项目管理技巧用于规划工作并将其划分到小组、管理团队效能,以及帮助团队快速适应不断变
化的业务需求。
版本控制(通常使用 Git 实现)可让世界各地的团队共享资源,以及集成用于自动化发行管道的软件开发工
具。
持续集成能够推动代码的持续合并与测试,帮助提前发现缺陷。 其他优势包括减少应对合并问题所浪费的时
间,以及快速获得开发团队的反馈。
向开发和测试环境持续交付软件解决方案可帮助组织快速修复 bug,应对不断变化的业务要求。
运行中应用程序的监视(包括生产环境中应用程序的运行状况)以及客户使用情况信息可帮助组织建立假设,
并快速验证或推翻策略。 以各种日志格式捕获和存储丰富的数据。
基础结构即代码 (IaC) 实务可以自动化并验证网络和虚拟机的创建与解除流程,帮助交付安全、稳定的应用程
序托管平台。
利用微服务体系结构将业务用例隔离到小型可重用的服务。 此体系结构提高了可伸缩性和效率。

后续步骤
若要了解有关安全和审核解决方案的信息,请参阅以下文章:

安全性和符合性
Azure 安全中心
Azure Monitor
Azure 操作安全性最佳做法
2021/2/9 • • Edit Online

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

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


反映这些更改。

定义并部署强大的操作安全做法
Azure 操作安全性是指用户可用于在 Azure 中保护其数据、应用程序和其他资产的服务、控件和功能。 Azure 操
作安全性建立在一个框架上,该框架融合了通过 Microsoft 独有的功能获得的知识,包括 安全开发生命周期
(SDL)、Microsoft 安全响应中心计划以及对网络安全威胁形态的深刻认识。

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

最佳做法 :确保你在云中具有适当级别的密码保护。
详细 信息 :按照 Microsoft 密码指南中的指南进行操作,该指南的适用范围是 Microsoft 标识平台(Azure Active
Directory、Active Directory 和 Microsoft 帐户)的用户。
最佳做法 :监视与用户帐户相关的可疑操作。
详细 信息 :使用 Azure AD 安全报告监视具有 风险的用户 和有风险的 登录 。

最佳做法 :自动检测和修正高风险密码。
详细 信息 : Azure AD Identity Protection 是 Azure AD Premium P2 版本的一项功能,它使你能够:

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

接收来自 Microsoft 的事件通知


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

在 Azure 注册门户中,你可以确保管理员联系信息包含用来进行安全操作通知的详细信息。 联系人详细信息为


电子邮件地址和电话号码。

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

可以在目录中构建管理组和订阅的灵活结构。 为每个目录指定了一个称为根管理组的顶级管理组。 此根管理组


内置在层次结构中,包含其所有下级管理组和订阅。 该根管理组允许在目录级别应用全局策略和 Azure 角色分
配。

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

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

最佳做法 :将顶级管理组与分段策略匹配,以便在每个段中实现控制和策略一致性。
详细 信息 :在根管理组下为每个段创建一个管理组。 请勿在根下创建其他任何管理组。

最佳做法 :限制管理组深度,以避免出现影响操作和安全性的混乱。
详细 信息 :将层次结构限制为三个级别(包括根在内)。

最佳做法 :使用根管理组,仔细选择要应用于整个企业的项。
详细 信息 :确保根管理组元素清楚地需要跨每个资源应用,并且不会对其造成影响。

典型的候选项包括:

具有明确业务影响的法规要求(例如,与数据主权相关的限制)
具有接近零的潜在负面影响操作的要求,例如已认真查看的具有审核效果或 Azure RBAC 权限分配的策略

最佳做法 :在将根管理组应用于企业范围内的所有更改之前,将这些更改应用 (策略、Azure RBAC 模型等) 。


详细 信息 :根管理组中的更改可能会影响 Azure 上的每个资源。 尽管它们提供了一种强大的方法来确保整个企
业中的一致性,但错误或不正确的使用可能会对生产操作产生负面影响。 请在测试实验室或生产试点中测试对
根管理组的所有更改。

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

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

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

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


以及诊断存储帐户的问题。

防范、检测和应对威胁
Azure 安全中心增强了对 Azure 资源安全的可见性和可控性,可帮助你预防、检测和响应威胁。 它提供对 Azure
订阅的集成安全监视和策略管理,帮助检测可能被忽略的威胁,且适用于各种安全解决方案。

安全中心的免费层仅为 Azure 资源提供有限的安全性。 标准层将这些功能扩展到本地和其他云中。 借助安全中


心标准层,可以查找和修复安全漏洞、应用访问控制和应用程序控制来阻止恶意活动、使用分析和智能功能检测
威胁,以及在受到攻击时迅速做出响应。 可以尝试安全中心标准版,头 60 天免费。 建议将 Azure 订阅升级到安
全中心标准层。

使用安全中心,可以通过一个集中化视图查看所有 Azure 资源的安全状态。 一眼就可验证适当的安全控件是否


配置到位且配置正确,还可快速确认任何需要注意的资源。

安全中心还集成了 Microsoft Defender 高级威胁防护 (ATP),后者提供了完善的终结点检测和响应 (EDR) 功能。


使用 Microsoft Defender ATP 集成可以查明异常。 你还可以检测和响应安全中心所监视的服务器终结点上出现
的高级攻击。

几乎所有的企业组织都有一个安全信息和事件管理 (SIEM) 系统,它可以整合来自不同信号收集设备的日志信


息,因此可以识别新出现的威胁。 然后,数据分析系统会分析日志,以帮助确定所有日志收集和分析解决方案中
不可避免的噪音的 "有趣"。

Azure Sentinel 是一种可缩放的云本机、安全信息和事件管理 (SIEM) 和安全业务流程自动响应 (之忠诚度) 解决


方案。 Azure Sentinel 通过警报检测、威胁可见性、主动搜寻和自动威胁响应提供智能安全分析和威胁智能。

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

最佳做法 :使用基于云的 SIEM 提高 SIEM 解决方案的速度和可伸缩性。


详细 信息 :调查 Azure Sentinel 的特性和功能,并将其与你当前在本地使用的功能进行比较。 如果符合组织的
SIEM 要求,请考虑采用 Azure Sentinel。
最佳做法 :找到最严重的安全漏洞,以便确定调查优先级。
详细 信息 :查看你的 Azure 安全评分,了解 Azure 安全中心内置的 Azure 策略和计划所产生的建议。 这些建议有
助于解决顶级风险,例如安全更新、终结点保护、加密、安全配置、WAF 缺失、VM 连接到 Internet 等方面的风
险。

基于 Internet 安全中心 (CIS) 控件的安全分数使你能够根据外部源来基准组织的 Azure 安全性。 外部验证有助于


验证和丰富团队的安全策略。

最佳做法 :监视计算机、网络、存储和数据服务以及应用程序的安全状况,发现潜在的安全问题并确定其优先
级。
详细 信息 :按照安全中心的 安全建议操作,并从优先级最高的项开始。

最佳做法 :将安全中心警报集成到安全信息和事件管理 (SIEM) 解决方案中。


详细 信息 :采用 SIEM 的大多数组织都使用它充当一个中心交换所来处理需要分析师响应的安全警报。 安全中心
生成的事件经过处理后,将被发布到 Azure 活动日志,这是 Azure Monitor 提供的可用日志之一。 Azure Monitor
提供了一个综合管道,可将任何监视数据路由到 SIEM 工具。 有关说明,请参阅将警报流式传输到 SIEM、SOAR
或 IT 服务管理解决方案。 如果使用的是 Azure Sentinel,请参阅 连接 Azure 安全中心。

最佳做法 :将 Azure 日志与你的 SIEM 集成。


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

最佳做法 :通过将终结点检测和响应 (EDR) 功能集成到攻击调查中,加快调查和搜寻过程,并减少误报。


详细 信息 :通过安全中心安全策略 为终结点集成启用 Microsoft Defender 。 考虑使用 Azure Sentinel 进行威胁
搜寻和事件响应。

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

Azure 网络观察程序是一项区域性服务。 其诊断和可视化工具可用于在网络方案级别监视和诊断 Azure 内部以


及传入和传出 Azure 的流量的状态。

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

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

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

最佳做法 :诊断 VPN 连接问题。


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

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


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

最佳做法:自动生成和部署服务。
详细信息:基础结构即代码是一组技术和实践,使 IT 专业人员不再需要日复一日地生成和管理模块化基础结构。
使得 IT 专业人员生成和维护新式服务器环境的方式就像是软件开发人员生成和维护应用程序代码的方式。

Azure 资源管理器允许用户使用声明性模板预配应用程序。 在单个模板中,可以部署多个服务及其依赖项。 在应


用程序生命周期的每个阶段,可使用相同模板重复部署应用程序。

最佳做法:自动生成并部署到 Azure Web 应用或云服务。


详细 信息 :可以将 Azure DevOps Projects 配置为 自动生成并部署 到 Azure web 应用或云服务。 在每次代码签
入后,azure DevOps 会自动部署二进制文件。 包生成过程与 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 公
开的服务终结点。

至关重要的一点是,确保应用程序具有足够的弹性,可应对针对应用程序本身的拒绝服务攻击。 从安全开发生命
周期 (SDL) 开始,安全和隐私就已内置到 Azure 平台中。 SDL 可以解决每个开发阶段的安全性,并确保 Azure 不
断更新,以变得越来越安全。
最佳做法:采用可横向缩放的应用程序设计,以满足放大负载的需求,尤其是防范 DDoS 攻击。 如果应用程序依
赖于服务的单个实例,则会造成单一故障点。 预配多个实例能够提高复原能力和可伸缩性。
详细信息:对于 Azure 应用服务,请选择提供多个实例的应用服务计划。

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

对于 Azure 虚拟机,请确保 VM 体系结构包含多个 VM,并且每个 VM 包含在可用性集中。 建议使用虚拟机规模


集来实现自动缩放功能。

最佳做法:应用程序中的分层安全防御可以减少攻击成功的可能性。 使用 Azure 平台的内置功能对其应用程序实


施安全设计。
详细信息:攻击风险会随着应用程序的规模(外围应用)的增大而增大。 你可以通过使用审批列表来关闭公开的
IP 地址空间,并将负载平衡器上不需要的侦听端口关闭 (Azure 负载平衡器 和 Azure 应用程序网关) ,从而减少
外围应用。

网络安全组是缩小受攻击面的另一种方法。 可以使用服务标记和应用程序安全组来最大程度地简化安全规则的
创建,并将网络安全性配置为应用程序结构的自然扩展。

应尽可能地在虚拟网络中部署 Azure 服务。 这种做法可让服务资源通过专用 IP 地址通信。 来自虚拟网络的


Azure 服务流量默认使用公共 IP 地址作为源 IP 地址。
使用服务终结点时,服务流量会在通过虚拟网络访问 Azure 服务时改用虚拟网络专用地址作为源 IP 地址。

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


要在公共 Internet 上公开本地资源。

Azure 具有两个 DDoS 服务产品,提供网络攻击防护:


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

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

启用 Azure 策略来监视和强制实施组织的书面政策。 这样就可以集中管理混合云工作负荷中的安全策略,确保


符合公司或法规安全要求。 了解如何创建和管理策略以强制实施合规性。 有关策略元素的概述,请参阅 Azure
Policy 定义结构。
下面是在采用 Azure Policy 后要遵循的一些安全性最佳做法:

最佳做法 :Azure Policy 支持多种类型的效果。 可以在 Azure Policy 定义结构中了解相关信息。 拒 绝 效果和 修


正 效果可能会给业务运营带来负面影响,因此请从 审 核 效果开始以限制策略带来的负面影响风险。
详细 信息 :以审核模式开始策略部署,然后推进到 拒 绝 或 修正 。 在推进到 拒 绝 或 修正 之前,请测试并查看审
核效果的结果。

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

最佳做法 :确定负责监视策略违规的角色,并确保快速执行正确的修正操作。
详细 信息 :让已分配的角色通过 Azure 门户或 命令行来监视符合性。

最佳做法 :Azure Policy 是组织的书面策略的技术表示形式。 将所有 Azure 策略定义映射到组织策略,以减少混


乱并增强一致性。
详细 信息 :通过在 策略定义或 计划定义说明中添加对组织策略的引用,在组织的文档中或 Azure Policy 定义本
身中记录映射。

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

后续步骤
有关通过 Azure 设计、部署和管理云解决方案时可以使用的更多安全最佳做法,请参阅 Azure 安全最佳做法和模
式。

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

Azure 安全团队博客 - 随时掌握 Azure 安全性的最新信息


Microsoft 安全响应中心 - 可在其中报告 Microsoft 安全漏洞(包括 Azure 问题)或将其通过电子邮件发送到
secure@microsoft.com
Azure 操作安全性清单
2021/2/9 • • Edit Online

在 Azure 上部署应用程序的过程快速、轻松且经济高效。 在生产环境中部署云应用程序之前,准备好一个清单会


很有用,这样可以根据一份必要和建议的操作安全措施列表来评估应用程序。

简介
Azure 提供一套可用于部署应用程序的基础结构服务。 Azure 操作安全性是指用户可用于在 Microsoft Azure 中
保护其数据、应用程序和其他资产的服务、控件和功能。

为了最大程度地发挥云平台的优势,我们建议利用 Azure 服务并遵循本清单的建议。


在推出应用程序之前投入时间和资源评估应用程序操作就绪性的组织,比不采取这些措施的组织最终收获的
满意度要高得多。 在执行这项工作时,清单可以充当一个极其有效的机制,确保以一致且整体的方式评估应
用程序。
根据组织的云成熟度和应用程序的开发阶段、可用性需求和数据敏感性要求,操作评估级别会有所不同。

清单
此清单的目的是帮助企业在 Azure 上部署复杂的企业应用程序时全盘考虑各种操作安全因素。 此外,它还有助
于为组织构建安全的云迁移和操作策略。

使用 Azure 基于角色的访问控制 (Azure RBAC) 向特


安全角色和访问控制 定范围内的用户、组和应用程序分配权限。

使用 Azure 基于角色的访问控制 (Azure RBAC) 通过


数据收集和存储 管理平面安全性来保护存储帐户。
使用共享访问签名 (SAS) 和存储访问策略通过数据平
面安全性来保护对数据的访问。
使用传输级加密 – 使用 SMB(服务器消息块协议)3.0
对 Azure 文件共享所用的 HTTPS 和加密。
需要专门控制加密密钥时,使用客户端加密来保护发
送到存储帐户的数据。
使用存储服务加密 (SSE) 来自动加密 Azure 存储中的
数据,使用 Azure 磁盘加密 来加密 OS 和数据磁盘的
虚拟机磁盘文件。
使用 Azure 存储分析监视授权类型;像使用 Blob 存储
时一样,可以查看用户使用的是共享访问签名还是存
储帐户密钥。
使用跨域资源共享 (CORS) 访问不同域中的存储资源。

使用 Azure 安全中心部署终结点解决方案。
安全策略和建议 添加 Web 应用程序防火墙 (WAF) 来保护 Web 应用程
序。
使用 Microsoft 合作伙伴的 防火墙 来增强安全保护。
为 Azure 订阅应用安全联系人详细信息;如果
Microsoft 安全响应中心 (MSRC) 发现客户数据被非法
或未授权的一方访问,MSRC 会联系你。
使用 Azure AD 将本地目录与云目录同步。
标识和访问管理 使用单一登录让用户基于他们在 Azure AD 中的组织
帐户访问其 SaaS 应用程序。
使用密码重置注册活动报告来监视正在注册的用户。
为用户启用多重身份验证 (MFA)。
开发人员可对应用使用安全标识功能,例如 Microsoft
安全开发生命周期 (SDL)。
使用 Azure AD Premium 异常报告和 Azure AD 标识
保护功能主动监视可疑活动。

使用恶意软件评估解决方案 Azure Monitor 日志来报


持续安全监视 告基础结构中的反恶意软件保护状态。
使用更新评估确定潜在安全问题的总体风险,以及这
些更新对环境是否重要、有多重要。
标识和访问提供用户的概述,具体信息包括:
用户标识状态;
登录尝试失败次数、
尝试登录期间使用的用户帐户、已锁定的帐户;
密码已更改或重置的帐户;
当前已登录的帐户数目。

使用检测功能识别针对 Microsoft Azure 资源的现行


Azure 安全中心检测功能 威胁。
使用集成威胁情报,利用 Microsoft 产品和服
务、Microsoft 反数字犯罪部门 (DCU)、Microsoft 安全
响应中心 (MSRC) 以及外部源提供的全球威胁情报,
搜寻已知的行为不端的攻击者。
使用行为分析,运用已知模式发现恶意行为。
使用异常检测,利用统计分析构建历史基线。

基础结构即代码 (IaC) 实务可以自动化并验证网络和


开发运营 (DevOps) 虚拟机的创建与解除流程,帮助交付安全、稳定的应用
程序托管平台。
持续集成和部署能够推动代码的持续合并与测试,帮
助提前发现缺陷。
版本管理可通过管道的每个阶段管理自动化部署。
应用程序性能监视:正在运行的应用程序(包括应用程
序运行状况和客户使用情况的生产环境)可帮助组织
形成假设,并快速验证或推翻策略。
使用负载测试和自动缩放可以发现应用中的性能问
题,提高部署质量,确保应用始终保持运行或可用,以
迎合业务需求。

结论
许多组织已在 Azure 中成功部署并运行其云应用程序。 提供的清单强调了几项必备要点,可帮助提高成功部署
和顺畅运营的几率。 我们强烈建议针对 Azure 上的现有应用程序部署和新的部署实施这些操作性和策略性事
项。

后续步骤
若要了解有关安全性的详细信息,请参阅以下文章:
设计和操作安全性
Azure 安全中心规划和操作
Azure 上可⽤的安全服务和技术
2021/2/9 • • Edit Online

在我们与当前和未来 Azure 客户的讨论中,我们经常被问及“你们是否有 Azure 必须提供的所有安全相关服务和


技术的列表?”

了解以下信息有助于评估云服务提供程序选项。 因此,我们提供此列表帮助你入门。

随着时间的推移,此列表会进行更改,并且会不断变大,就像 Azure 一样。 请务必时时查看此页面,了解安全相


关服务和技术的最新内容。

Azure 常规安全性

Azure 安全 中心 一个云工作负荷保护解决方案,可跨混合云工作负荷提供安
全性管理和高级威胁防护。

Azure 密钥保管库 一个安全的机密存储空间,用于存储密码、连接字符串和维持


应用正常工作所需的其他信息。

Azure Monitor 日志 一项监视服务,它收集遥测和其他数据,并且提供查询语言和


分析引擎,以传递应用和资源操作见解。 可单独使用或与其他
服务一同使用(例如安全中心)。

Azure 开发/测试实验室 一项可帮助开发人员和测试人员在 Azure 中快速创建环境,


同时尽量减少浪费并控制成本的服务。

存储安全

Azure 存储 服务 加密 一项安全功能,会自动加密 Azure 存储中的数据。

StorSimple 加密混合存储 一种用于管理本地设备与 Azure 云存储之间的存储任务的集


成存储解决方案。

Azure 客户端加密 一个客户端加密解决方案,它在将数据上传到 Azure 存储前


在客户端应用程序内加密数据,并在下载时解密数据。

Azure 存储共享访问签名 共享访问签名对存储帐户中的资源提供委托访问。

Azure 存储帐户密钥 一种适用于 Azure 存储的访问控制方法,用于在访问存储帐


户时进行身份验证。

带有 SMB 3.0 加密的 Azure 文件共享 一项网络安全技术,它为服务器消息块 (SMB) 文件共享协议


启用自动网络加密。

Azure 存储分析 一项记录和指标生成技术,适用于存储帐户中的数据。


数据库安全

Azure SQL 防火墙 一项网络访问控制功能,对针对数据库的网络攻击进行防护。

Azure SQL 单元格 级别加密 一种提供粒度级别加密的数据库安全技术。

Azure SQL 连接加密 为了确保安全性,SQL 数据库会进行访问控制,即:使用防火


墙规则来限制通过 IP 地址进行的连接,使用身份验证机制来
要求用户证明其身份,并使用授权机制来限制用户执行特定
操作和访问特定数据。

Azure SQL 始终加密 保护 Azure SQL 数据库或 SQL Server 数据库中存储的敏感数


据,如信用卡号或国民身份证号(例如,美国社会安全号码)。

Azure SQL 透明数据加密 一种加密整个数据库存储的数据库安全功能。

Azure SQL 数据库审核 一种跟踪数据库事件并将事件写入 Azure 存储帐户中的审核


日志的数据库审核功能。

标识和访问管理

Azure 基于角色的 访问控制 一项访问控制功能,它基于用户在组织内的角色,仅允许用户


访问其必须访问的内容。

Azure Active Directory 一个基于云的身份验证存储库,它支持基于云的多租户目录


和 Azure 中的多标识管理服务。

Azure Active Directory B2C 一项标识管理服务,帮助控制客户使用基于 Azure 的应用程


序时如何注册、登录和管理其配置文件。

Azure Active Directory 域服务 Active Directory 域服务基于云的托管版本。

Azure AD 多重身份验证 一项安全性设置,它会采用几种形式的身份验证和验证,再允


许访问安全信息。

备份和灾难恢复

Azure 备份 一项基于 Azure 的服务,用于备份和还原 Azure 云中的数据。

Azure Site Recovery 一项联机服务,它可将在物理计算机和虚拟机 (VM) 上运行的


工作负荷从主站点复制到辅助位置,以便在出现故障后恢复
服务。

网络
网络 安全 组 一项基于网络的访问控制功能,它使用 5 元组进行允许或拒
绝决策。

Azure VPN 网关 一种网络设备,用作 VPN 终结点,以允许跨界访问 Azure 虚


拟网络。

Azure 应用程序网关 高级 Web 应用程序负载均衡器,可基于 URL 进行路由并执行


SSL 卸载。

Web 应用程序防火墙 (WAF) 应用程序网关的一项功能,可以对 Web 应用程序进行集中保


护,避免其受到常见的攻击和漏洞危害

Azure 负载均衡器 TCP/UDP 应用程序网络负载均衡器。

Azure ExpressRoute 本地网络和 Azure 虚拟网络之间的专用 WAN 链接。

Azure 流量管理器 一种全局 DNS 负载均衡器。

Azure 应用程序代理 用于保护远程访问本地托管 Web 应用程序的身份验证前端。

Azure 防火墙 是托管的基于云的网络安全服务,可保护 Azure 虚拟网络资


源。

Azure DDoS 防护 与应用程序设计最佳做法相结合,可提供针对 DDoS 攻击的


防御。

虚拟网络服务终结点 可通过直接连接,将 VNet 的虚拟网络专用地址空间和标识扩


展到 Azure 服务。
Azure 安全最佳实践和模式
2021/2/9 • • Edit Online

下列文章介绍了在通过 Azure 设计、部署和管理云解决方案时可以使用的一组安全性最佳做法。 这些最佳做法


来自我们在 Azure 安全性方面的经验以及客户的经验。

这些最佳做法是为 IT 专业人员准备的资源。 这可能包括构建和部署安全的 Azure 解决方案的设计人员、架构


师、开发者和测试人员。

Azure 边界安全最佳实践
Azure 数据库安全性最佳做法
Azure 数据安全与加密最佳实践
Azure 标识管理和访问控制安全最佳做法
Azure 网络安全最佳实践
Azure 操作安全性最佳做法
Azure PaaS 最佳做法
Azure Service Fabric 安全性最佳做法
Azure VM 安全性最佳做法
在 Azure 中实现安全的混合网络体系结构
物联网安全最佳实践
在 Azure 中保护 PaaS 数据库
使用 Azure App Service 保护 PaaS Web 和移动应用程序
使用 Azure 存储保护 PaaS Web 和移动应用程序
Azure 中 IaaS 工作负荷的安全性最佳做法
适用于 Azure 解决方案的白皮书安全最佳做法是在上面列出的文章中找到的安全最佳做法的集合。

下载白皮书
⽹络安全中的 Microsoft 服务
2021/2/9 • • Edit Online

Microsoft 服务提供了一种全面的安全性、标识和网络安全方法。 这包括一系列跨策略、规划、实施以及日常支持


的安全和标识服务。 这些服务可帮助企业客户实施符合其战略目标的安全解决方案。

Microsoft 服务可以创建集成的解决方案,增强产品的最新安全和标识功能,帮助保护你的业务并推动创新。
我们的技术专家团队由训练有素的专家组成,他们提供丰富的安全和标识体验。

了解 Microsoft 服务提供的服务的详细信息:

安全风险评估
动态标识框架评估
Active Directory 服务的脱机评估
增强的安全管理环境
Azure AD 实现服务
防范横向帐户移动
事件响应和恢复

了解更多关于 Microsoft Services Security 咨询服务的信息。


如何记录安全事件⽀持票证
2021/2/9 • • Edit Online

1. 导航到发布者支持并使用 Microsoft 凭据登录。

2. 选择“安全事件”作为问题类型,并在“安全事件”和“漏洞”类别之间做出选择。

3. 选择问题类型和类别后,单击 "启 动请 求 " 按钮。 提供以下信息有助于了解问题。

i. 问题和/或漏洞是什么?
ii. 对于漏洞,请提供 CVE (mitre.org) 或 CVSS3 v3 计算器的已填充
(https://www.first.org/cvss/calculator/3.0) 。
iii. 是否有解决方法或缓解措施? 如果是,请提供补救措施。
iv. 是否需要向客户发送消息? 如果可以,我们将与你共同创建相应的消息。
4. 提交确认 - 提交问题后,我们会在一个工作日内确认接收,并且指定问题的优先级和严重性。

如果需要与我们交流有关问题,请使用所有对应关系中的确认号码。
可在任何时候查看问题解决进度。
5. 接下来会发生什么? 根据具体问题和严重性,可能会采取以下步骤:

我们会将评估结果传达给你。 根据结果,可能会删除或要求修改所提交的信息。 在这种情况下,我们


将与你共同努力,确保将受到影响的客户的干扰降至最低。
我们将与你共同努力,帮助减轻由事件/漏洞对共同客户造成的影响。
渗透测试
2021/2/9 • • Edit Online

使用 Azure 进行应用程序测试和部署的一个优点是可快速创建环境。 不必为请求、获取以及“搭架和堆叠”本地硬


件担心。

快速创建环境非常好,但仍需确保执行正常的安全截止。 你可能想要做的事情之一就是对部署在 Azure 中的应


用程序进行渗透测试。

我们不会对你的应用程序进行渗透测试,但我们知道你需要并且需要在你自己的应用程序上执行测试。 这是好
事,因为改进自己的应用程序的安全性可以加强整个 Azure 生态系统的安全性。

自 2017 年 6 月 15 日起,对于针对 Azure 资源进行的渗透测试,Microsoft 不再要求执行预批准流程。 本流程仅


与 Microsoft Azure 相关,并不适用于任何其他 Microsoft 云服务。

IMPORTANT
虽然参加渗透测试时无需再通知 Microsoft,客户仍须遵守 Microsoft 云统一渗透测试参与规则。

可以执行的标准测试包括:

对终结点进行测试,以发现开放 Web 应用程序安全项目 (OWASP) 的前 10 个漏洞


终结点的模糊测试
终结点的端口扫描

您无法执行的一种笔测试是 (DoS) 攻击的拒绝服务 。 此测试包括:自行发起 DoS 攻击,或者执行相关的测试,以


便确定、演示或模拟任何类型的 DoS 攻击。

NOTE
Mircosoft 已与 BreakingPoint Cloud 合作构建接口,用户可在其中针对已启用 DDoS 保护的公共 IP 地址生成用于模拟的流
量。 若要了解有关 BreakingPoint 云模拟的详细信息,请参阅 通过模拟进行测试。

后续步骤
详细了解渗透测试参与规则。
Azure 域 (的参考列表不全⾯ )
2021/2/9 • • Edit Online

此页是使用中的 Azure 域的部分列表。 其中一些是 REST API 的终结点。

Azure 访问控制服务 (已停用) *.accesscontrol.windows.net

Azure Active Directory . graph.windows.net/. onmicrosoft.com

Azure API 管理 *. azure-api.net

Azure BizTalk 服务 (已停用) *. biztalk.windows.net

Azure Blob 存储 *.blob.core.windows.net

Azure 云服务 和 azure 虚拟机 *.cloudapp.net

Azure 云服务 *. cloudapp.azure.com

Azure 容器注册表 *.azurecr.io

Azure 容器服务 (ACS) (弃用) *. azurecontainer.io

Azure 内容分发网络 (CDN) *. vo.msecnd.net

Azure 文件 *.file.core.windows.net

Azure Front Door *. azurefd.net

Azure 管理服务 *. management.core.windows.net

Azure 媒体服务 *. origin.mediaservices.windows.net

Azure 移动应用 *. azure-mobile.net

Azure 队列存储 *.queue.core.windows.net

Azure 服务总线 *.servicebus.windows.net

Azure SQL 数据库 *.database.windows.net

Azure Stack 边缘 和 Azure IoT Edge *.azureedge.net

Azure 表存储 *.table.core.windows.net

Azure 流量管理器 *. trafficmanager.net


Azure 网站 *.azurewebsites.net

Visual Studio Codespaces *.visualStudio.com

You might also like