精通-Azure-安全-全-

精通 Azure 安全（全）

原文：annas-archive.org/md5/e28739afb6eb8314bc7789c09ec83f5b

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

安全始终是云平台的一部分，这使得用户放松警惕，认为云安全是理所当然的。云计算带来了新的安全挑战，但你可以通过 Microsoft Azure 的共享责任模型克服这些挑战。

掌握 Azure 安全介绍了 Microsoft 提供的最新安全功能，以识别不同的威胁并使用创新技术保护你的 Azure 云。 本书带你深入了解 Azure 提供的内建安全控制和多层次的安全功能，用于保护跨应用程序和网络的云工作负载。你将学习如何使用 Azure 安全中心进行统一的安全管理，在 Azure 上构建安全的应用程序，保护云免受 DDoS 攻击，通过 Azure Key Vault 保护敏感信息等等。此外，本书还涵盖了 Azure Sentinel、监控和审计、Azure 安全与治理最佳实践以及安全资源部署等内容。

到本书结束时，你将建立起扎实的云端网络安全基础，能够在 Microsoft Azure 中设计安全的解决方案。

本书适合谁阅读？

本书适合 Azure 云计算专业人员、Azure 架构师和希望利用 Azure 安全中心以及其他 Azure 安全功能来实施安全云服务的安全专家。对安全概念的基本理解以及对 Azure 云的先前接触将有助于理解本书中介绍的关键概念。

本书内容概述

第一章，Azure 安全概述，介绍了云计算如何改变 IT 的概念，安全性也不例外。网络安全在云端需要采用不同的方式，我们需要理解这些差异、新的威胁，以及如何应对它们。

第二章，治理与安全，讲解了如何在 Microsoft Azure 中创建政策和规则，以便制定标准、执行这些政策和规则，并保持质量水平。

第三章，管理云身份，解释了为什么身份是安全中最重要的部分之一。在云端，身份的表现比以往任何时候都更加重要。你将学习如何在 Microsoft Azure 中保持身份安全，如何跟踪访问权限并监控用户行为中的任何异常。

第四章，Azure 网络安全，介绍了网络在任何环境中都是第一道防线。确保资源安全且不易被攻击者接触是安全性的一个重要方面。你将学习如何通过 Microsoft Azure 的内建工具或自定义工具实现这一目标。

第五章，Azure KeyVault，解释了如何在 Azure 中管理机密和证书，并以安全的方式通过基础设施即代码（Infrastructure as Code）将资源部署到 Microsoft Azure。

第六章，数据安全，介绍了如何使用 Microsoft 或自己的加密密钥对云中的数据进行额外加密来保护数据。

第七章，Azure 安全中心，解释了如何使用 ASC 检测 Microsoft Azure 中的威胁，以及如何查看评估、报告和建议，以增强 Azure 租户的安全性。它还探讨了通过启用即时访问来提高虚拟机安全性。

第八章，Azure Sentinel，介绍了如何使用 Azure Sentinel 来监控 Azure 及本地资源的安全，包括在威胁发生前进行检测，并使用人工智能分析和调查威胁。还介绍了如何利用 Azure Sentinel 自动化响应安全威胁并立即加以阻止。

第九章，安全最佳实践，介绍了 Azure 安全的最佳实践，包括如何设置一个坚不可摧的 Azure 环境，找到 Azure 中隐藏的安全功能，以及其他可能帮助你提高 Microsoft Azure 安全性的工具。

为了最大限度地发挥本书的作用

你需要以下软件，这些软件是开源并且免费使用的，除了 Microsoft Azure，它是基于订阅的，按使用时长收费。然而，即使是 Microsoft Azure，也可以使用试用订阅。

如果你正在使用本书的数字版，我们建议你自己输入代码或通过 GitHub 仓库访问代码（链接将在下一节提供）。这样可以帮助你避免与复制/粘贴代码相关的潜在错误。

下载示例代码文件

你可以通过访问www.packt.com来从你的账户下载本书的示例代码文件。如果你是从其他地方购买的本书，可以访问www.packtpub.com/support并注册，文件会直接通过电子邮件发送给你。

你可以通过以下步骤下载代码文件：

1. 登录或在www.packt.com注册。

2. 选择支持选项卡。

3. 点击代码下载。

4. 在搜索框中输入书名，并按照屏幕上的说明操作。

下载文件后，请确保使用以下最新版本的工具解压或提取文件夹：

• WinRAR/7-Zip for Windows

• Zipeg/iZip/UnRarX for Mac

• 7-Zip/PeaZip for Linux

本书的代码包也托管在 GitHub 上：github.com/PacktPublishing/Mastering-Azure-Security。如果代码有更新，现有的 GitHub 仓库会进行更新。

我们还提供其他来自丰富目录的书籍和视频的代码包，您可以在github.com/PacktPublishing/查看。

下载彩色图像

我们还提供了一个包含本书中使用的截图/图表的彩色图像的 PDF 文件。您可以在这里下载：www.packtpub.com/sites/default/files/downloads/9781839218996_ColorImages.pdf。

使用的约定

本书中使用了多种文本约定。

文本中的代码：表示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入以及 Twitter 用户名。以下是一个示例：“如何创建一个规则以拒绝通过端口 22 的流量”

一段代码如下所示：

"policyRule": {
"if": {
      	"not": {
                	"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": {
      	"effect": "deny"
}
}

任何命令行输入或输出均按如下方式编写：

New-AzResourceGroup -Name "Packt-Security" -Location ` "westeurope"

粗体：表示新术语、重要词汇或您在屏幕上看到的词汇。例如，菜单或对话框中的词汇在文本中会以这种方式出现。以下是一个示例：“转到子网部分下的NSG并选择关联。”

提示或重要说明

看起来是这样的。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果您对本书的任何内容有疑问，请在邮件主题中提到书名，并通过邮件联系我们：customercare@packtpub.com。

勘误：虽然我们已尽一切努力确保内容的准确性，但错误仍然可能发生。如果您在本书中发现任何错误，我们将非常感激您能向我们报告。请访问www.packtpub.com/support/errata，选择您的书籍，点击“勘误提交表格”链接并输入详细信息。

盗版：如果您在互联网上遇到我们作品的任何非法复制品，我们将感激您提供其位置地址或网站名称。请通过版权@packt.com 与我们联系，并提供该材料的链接。

如果您有兴趣成为作者：如果您在某个领域有专长，并且有兴趣写书或参与书籍的编写，请访问authors.packtpub.com。

评论

请留下评论。当您阅读并使用完本书后，为什么不在您购买书籍的网站上留下评论呢？潜在读者可以看到并利用您的公正意见做出购买决策，我们在 Packt 能够了解您对我们产品的看法，而我们的作者也能看到您对其书籍的反馈。谢谢！

欲了解更多关于 Packt 的信息，请访问 packt.com。

第一部分：身份与治理

在本节中，你将学习如何在 Azure 中创建和执行策略，如何管理和保护 Azure 中的身份，以及什么是云中的网络安全。

本节包含以下章节：

第一章，Azure 安全简介

第二章，治理与安全

第三章，云身份管理

第一章：第一章: Azure 安全概述

当云计算成为讨论话题时，安全通常是最主要的议题。当数据离开本地数据中心时，许多人会担心它会发生什么。我们习惯于对所有事物拥有完全控制权，从物理服务器、网络、虚拟机管理程序，到应用程序和数据。然后，突然间，我们需要将这些控制权转交给他人。刚开始时自然会感到一些紧张和不信任，但如果深入思考，我们会发现云计算实际上能为我们提供比我们自己做得更好的安全性。

Microsoft Azure 是通过 Microsoft 管理的数据中心提供的云计算服务，这些数据中心分布在全球各地。Azure 数据中心建设符合行业顶级标准，并遵守所有相关认证机构的要求，如 ISO/IEC 27001:2013 和 NIST SP 800-53 等。这些标准保证了 Microsoft Azure 的安全性和可靠性。

本章我们将学习 Azure 安全概念，以及 Microsoft Azure 数据中心中的安全结构，涵盖以下主题：

• 探索共享责任模型

• 物理安全

• Azure 网络

• Azure 基础设施的可用性

• Azure 基础设施的完整性

• Azure 基础设施监控

• 理解 Azure 安全基础

探索共享责任模型

虽然 Microsoft Azure 非常安全，但构建安全环境的责任并不单单由 Microsoft 承担。其共享责任模型将责任分配给 Microsoft 和其客户。

在我们讨论哪个方负责安全的哪个方面之前，我们需要先了解云服务模型。基本的模型有三种：

• 基础设施即服务 (IaaS)

• 平台即服务 (PaaS)

• 软件即服务 (SaaS)

这些模型在 Microsoft 和客户控制的内容上有所不同。可以从以下图示中看到一般的分配情况：

图 1.1 – 基本云服务模型

让我们更详细地看一下这些服务：

本地环境

在本地环境中，我们作为用户需要负责所有事项：网络、物理服务器、存储等等。我们需要设置虚拟化堆栈（如果使用的话），配置和维护服务器，安装和维护软件，管理数据库等。最重要的是，所有安全相关的事宜都由我们负责：物理安全、网络安全、主机和操作系统安全，以及运行在我们服务器上的应用程序安全。

基础设施即服务

在 IaaS 模型下，Microsoft 承担了部分责任。我们只需要负责数据、运行时、应用程序以及一些安全方面的内容，稍后我们会进一步讨论。Microsoft Azure 中的一个 IaaS 产品示例是 Azure 虚拟机 (VM)。

平台即服务

PaaS（平台即服务）将更多责任交给微软。我们只负责管理我们的应用程序。然而，这仍然意味着我们需要照管一部分安全内容。微软 Azure 中的一些 PaaS 示例包括 Azure SQL 数据库和 Web 应用。

软件即服务

SaaS（软件即服务）将大量控制权交给客户，而我们管理的非常少，包括部分安全方面。在微软的生态系统中，SaaS 的一个常见例子是 Office365；然而，我们在本书中不会讨论这一点。

现在我们对共享责任有了基本的了解，接下来让我们理解如何分配安全责任。

共享责任模型中的安全划分

共享责任模型将安全划分为三个区域：

• 始终由客户控制

• 始终由微软控制

• 根据服务类型而异

无论采用何种云服务模型，客户始终会保留以下安全责任：

• 数据治理与权限管理

• 终端

• 账户和访问管理

同样，微软始终负责以下安全事务，无论其云服务模型是什么：

• 物理数据中心

• 物理网络

• 物理主机

最后，根据云服务模型，会有一些安全责任的分配：

• 身份与目录基础设施

• 应用程序

• 网络

• 操作系统

不同云服务模型下的责任分配，如下图所示：

图 1.2 – 不同云服务模型下客户与服务提供商的责任分配（图片来源：微软，许可证：MIT）

现在我们了解了安全是如何划分的，接下来让我们专注于其中一个特定方面：微软管理的物理安全。这个部分很重要，因为我们在接下来的章节中不会详细讨论它。

物理安全

一切始于物理安全。无论我们采取何种措施来保护数据免受来自网络外部的攻击，如果有人进入数据中心或服务器机房，拿走我们服务器上的硬盘，那么一切都会是徒劳的。微软非常重视物理安全，以减少未经授权访问数据和数据中心资源的风险。

只有通过严格定义的接入点才能访问 Azure 数据中心。设施的外围被钢筋混凝土的高围栏保护。为了进入 Azure 数据中心，个人需要经过至少两个检查点：首先进入设施的外围，其次进入大楼。这两个检查点都由专业的训练有素的安保人员值守。除了接入点外，安保人员还会巡逻设施的外围。该设施及其建筑物都受到视频监控，且由安保人员进行监控。

进入大楼后，需要进行带有生物识别的双重身份验证才能访问数据中心内部。如果身份验证通过，个人只能访问已批准的部分区域。批准不仅定义了可以访问的区域，还定义了可以在这些区域内停留的时间。它还严格规定了是否可以单独访问这些区域，或者是否需要由他人陪同。

在进入数据中心内部的每个区域之前，必须进行金属探测器检查。为了防止未经授权的数据进出数据中心，只允许使用批准的设备。此外，所有服务器机架都会通过视频监控对前后进行监控。当离开数据中心区域时，还需要进行额外的金属探测器筛查。这有助于微软确保没有未经授权的物品被带入或从数据中心中取出，从而危及其数据的安全。

所有设施都会定期进行物理安全审查，确保始终满足所有的安全要求。

设备达到使用寿命后，会以安全的方式处置，并有严格的数据和硬件处置政策。在处置过程中，微软工作人员会确保数据不被不可信的第三方获取。所有数据设备要么被清除（如果可能），要么被物理摧毁，以确保无法恢复任何信息。

所有微软 Azure 数据中心的设计、建设和运营都符合行业最高标准，如 ISO 27001、HIPAA、FedRAMP、SOC 1 和 SOC 2 等。此外，许多情况下还会遵循特定地区或国家的标准，如澳大利亚 IRAP、英国 GCloud 和新加坡 MTCS 等。

作为额外的预防措施，所有微软 Azure 数据中心中的数据在静止状态下都会进行加密。即使有人设法获取了包含客户数据的磁盘（虽然所有的安全措施几乎让这种情况不可能发生），要解密任何数据也需要巨大的努力（无论是从财务还是时间的角度来看）。

但是在云时代，网络安全和物理安全同样重要，甚至可能更重要。大多数服务是通过互联网访问的，即便是隔离的服务也依赖于网络层。因此，接下来我们需要了解 Azure 网络架构。

Azure 网络

Azure 网络可以分为两部分：微软管理的部分和我们管理的部分。在本节中，我们将讨论微软管理的网络部分。了解这一部分的架构、可靠性和安全设置非常重要，这为我们后续讨论需要管理的网络安全部分提供了更多背景信息。

与 Azure 数据中心通常的做法一样，Azure 网络遵循行业标准，采用三个不同的模型/层级：

• 核心

• 分发

• 访问

三种模型使用不同的硬件，以便完全分离所有层级。核心层使用数据中心路由器，分发层使用接入路由器和 L2 聚合（此层将 L3 路由与 L2 交换分开），接入层使用 L2 交换机。

Azure 网络架构包括两个层次的 L2 交换机：

• 第一层：聚合流量

• 第二层：循环以纳入冗余

这种方法提供了更大的灵活性和更好的端口扩展能力。另一个好处是，L2 和 L3 完全分开，这使得每一层可以使用不同的硬件。不同的硬件减少了一个层级出现故障时影响到其他层的可能性。使用 trunk 允许资源共享，以实现更好的连接性。

Azure 数据中心内部的网络被分为多个集群，以便更好地进行控制、扩展和容错。每个 Azure 集群中的网络由以下设备组成：

• 路由器

• 交换机

• 数字 CMs

• 配电单元

路由器可以分为三组：数据中心路由器、接入路由器和边缘叶路由器。交换机是聚合交换机或机架顶端交换机。

需要特别提到的是，Azure 数据中心有两种不同的网络架构 —— 默认局域网架构 (DLA) 和 量子 10 架构 (Q10)。

DLA 被一些现有客户和共享服务使用，主要在一些较早的 Azure 区域。Q10 用于较新的 Azure 数据中心和虚拟客户。DLA 使用经典的树形设计，配有主动/被动接入路由器。Q10 使用紧凑的网状设计。这些架构之间的主要区别在于 访问控制 列表 (ACLs) 的应用方式。在 DLA 中，ACLs 被直接应用到接入路由器上。Q10 不在路由层应用 ACLs，而是在其下一级，使用软件定义网络 (SDN)，结合 软件 负载 均衡 (SLBs) 和软件定义 VLANs。

Q10 的主要优势在于其更强的能力和扩展现有基础设施的能力。Q10 的另一个优势是软件定义网络能够处理一些安全特性，例如 网络 地址 转换 (NAT)。

以下图表展示了 DLA 和 Q10 两种架构：

图 1.3 – DLA 和量子 10 架构（图像来自 Microsoft，许可：MIT）

Azure 网络是基于每个 Azure 数据中心内高度冗余的基础设施构建的。实施的冗余为需求加一（N+1）或更好，并且在 Azure 数据中心内外具有完整的故障转移功能。完整的故障转移容忍度确保了持续的网络和服务可用性。从外部看，Azure 数据中心通过专用的高带宽网络电路互联，这些电路冗余地连接到全球超过 1,200 个互联网服务提供商（ISP）。网络的边缘容量超过 2,000 GBps，展现了巨大的网络潜力。

分布式拒绝服务（DDoS）正成为服务可用性方面的一个重大问题。随着云服务数量的增加，DDoS 攻击变得更加有针对性且复杂。借助地理分布和快速检测，微软可以帮助您缓解这些 DDoS 攻击并最小化其影响。让我们更详细地了解这一点。

Azure 基础设施的可用性

Azure 的设计、建设和运营旨在提供高可用性和可靠性的基础设施。持续实施改进，以提高可用性和可靠性，同时提升效率和可扩展性。提供更安全、更可信的云服务始终是优先事项。

不间断电源和大量电池组确保在短期电力中断的情况下，电力流保持不中断。在长期电力中断的情况下，应急发电机可以提供数天的备用电力。应急发电机用于长时间停电或计划性维护的情况下。在自然灾害发生时，当外部电力供应长时间无法提供时，每个 Azure 数据中心都备有现场燃料储备。

强大且高速的光纤网络将数据中心连接到主要枢纽。重要的是，除了通过主要枢纽连接外，数据中心之间也需要直接互联。所有内容都分布到节点中，这些节点托管更靠近用户的工作负载，以减少延迟、提供地理冗余并增强弹性。

Azure 中的数据可以放置在两个不同的位置：主位置和次位置。客户可以选择主位置和次位置的位置。次位置是备用站点。在每个位置，无论是主位置还是次位置，Azure 始终保持三个健康的数据副本。这意味着数据在任何时候都有六个副本。如果任何数据副本在任何时候变得不可用，它会立即被声明为无效，创建一个新副本，并销毁旧副本。

微软通过持续的监控、事件响应和服务支持来确保高可用性和可靠性。每个 Azure 数据中心全天候运营，确保一切正常运行，所有服务随时可用。当然，“随时可用”是一个目标，最终是无法完全实现的。有很多因素可能影响正常运行时间，有时无法控制所有这些因素。实际上，目标是实现最佳的服务水平协议（SLA），并确保潜在的停机时间尽可能小。SLA 可以根据多个因素变化，并且每个服务和配置的 SLA 都不同。如果我们考虑到所有可以控制的因素，那么我们可以达到的最佳 SLA 为 99.99%，也就是所谓的“四个九”。

与基础设施可用性密切相关的是基础设施完整性。完整性影响部署的可用性条款，所有步骤必须从不同角度进行验证。新的部署不能引起任何停机或以任何方式影响现有服务。

Azure 基础设施完整性

所有安装在 Azure 环境中的软件组件都是定制构建的。这当然指的是由微软作为 Azure 服务架构一部分安装和管理的软件。定制软件是使用微软的安全 开发 生命周期（SDL）过程构建的，包括操作系统镜像和 SQL 数据库。所有软件部署都在严格定义的变更管理和发布管理过程中进行。所有节点和 Fabric 控制器都使用定制版本的 Windows Server 2012。禁止安装任何未经授权的软件。

在 Azure 中运行的虚拟机（VM）被分组到集群中。每个集群包含大约 1,000 个虚拟机。所有虚拟机都由Fabric Controller（FC）进行管理。FC 是可扩展且冗余的。每个 FC 负责其所在集群中应用程序的生命周期管理。这包括该集群硬件的配置和监控。如果任何服务器发生故障，FC 会自动重建该服务器的新实例。

每个 Azure 软件组件都经过构建过程（作为发布管理过程的一部分），其中包括使用终端保护杀毒工具进行病毒扫描。在每个软件组件经过此过程时，只有通过清洁的病毒扫描后，才会进入生产环境。在发布管理过程中，所有组件都要经过构建过程。在此过程中，会执行一次病毒扫描。每次病毒扫描都会在构建目录中生成日志，如果检测到任何问题，该组件的过程将被冻结。对于检测到问题的软件组件，微软安全团队会进行检查，以确定具体问题。

Azure 是一个封闭且受限的环境。所有节点和虚拟机的默认 Windows 管理员账户都已被禁用。也不会在任何节点或虚拟机上直接创建用户账户。只有在获得适当授权的情况下，Azure 支持的管理员才能连接到它们，进行维护任务和紧急修复。

尽管采取了所有预防措施以确保最大程度的可用性和安全性，事件仍然可能会发生。为了尽早检测并减轻这些问题，Microsoft 实施了监控和事件管理。

Azure 基础设施监控

Azure 数据中心的所有硬件、软件和网络设备都会不断进行审查和更新。审查和更新至少每年强制执行一次，但根据需要会进行额外的审查和更新。任何更改（硬件、软件或网络）都必须通过发布管理流程，且需要在开发和测试环境中开发、测试并批准后才能发布到生产环境。在此过程中，所有更改必须经过 Azure 安全和合规团队的审查和批准。

所有 Azure 数据中心都使用集成的部署系统来分发和安装 Microsoft 提供的所有软件的安全更新。如果使用第三方软件，客户或软件制造商负责安全更新，具体取决于软件的提供和使用方式。例如，如果第三方软件是通过 Azure Marketplace 安装的，则制造商负责提供更新。如果软件是手动安装的，则由具体软件决定。对于 Microsoft 软件，Microsoft 内部有一个专门的团队——Microsoft 安全响应中心，负责 24/7/365 全天候监控和识别任何安全事件。此外，任何事件必须在最短的时间内解决。

Azure 基础设施（服务器、数据库和网络）每季度至少进行一次漏洞扫描。如果出现特定问题或事件，漏洞扫描的频率会更高。Microsoft 进行渗透测试，还聘请独立顾问进行渗透测试。这确保没有任何问题被遗漏。一旦发现安全问题，立即处理，以提高安全性并阻止任何漏洞被利用。

如果发生任何安全问题，Microsoft 已经设立了事件管理机制。如果 Microsoft 发现安全问题，它将采取以下措施：

1. 客户会被通知该事件。

2. 将立即启动调查，以提供有关安全事件的详细信息。

3. 采取措施减轻安全事件的影响，并尽量减少损失。

事件管理有明确的定义，以便及时管理、升级和解决所有安全事件。

了解 Azure 安全基础

总的来说，我们可以看到，通过微软 Azure，云计算可以是非常安全的。但理解共享责任模型也非常重要。仅仅将应用程序和数据放入云中，并不能使其变得安全。微软提供了部分安全措施，并确保物理和网络安全到位。客户必须承担部分责任，并确保在自己这一方采取正确的措施。

比如说，假设我们将数据库和应用程序放在微软 Azure 中，但我们的应用程序容易受到 SQL 注入攻击（这仍然是一种非常常见的数据泄露方式）。如果我们的数据被泄露，我们能怪微软吗？

假设更加极端一点，我们公开暴露了端点，且忘记实施任何形式的身份验证。这是微软的责任吗？

如果我们看看微软在 Azure 数据中心提供的物理和网络安全水平，没有多少组织能说他们在本地数据中心具备同样的水平。更多时候，物理安全完全被忽视。服务器机房不安全，访问控制不到位，很多时候甚至没有专门的服务器机房，而只是一些服务器架子放在某个角落或走廊里。即使有服务器机房上了锁，也没有任何管理变更措施，没人控制或审查谁进入了服务器机房以及为什么进入。另一方面，微软在他们的数据中心实施了顶级的安全措施。所有一切都在持续监控中，任何访问都需要批准和审查。即使有些事情被遗漏，所有数据依然被加密并且额外安全保护。根据我的经验，这也是大多数组织不会去做的事情。

网络安全方面也可以说类似的事情。在大多数组织中，防火墙后几乎所有的网络安全措施都没有了。网络通常没有进行分段，内部没有流量控制，等等。路由和流量转发是基础的，或者根本不存在。微软 Azure 很好地解决了这些问题，帮助我们为我们的资源提供安全的网络。

但是，即使微软处理了所有安全组件，这也只是一个开始。通过使用微软 Azure，我们可以实现比本地数据中心更好的物理和网络安全，并且我们可以集中精力处理其他事情。

共享责任模型在不同的云服务模型中有不同的责任，且有时并不清晰需要做什么。幸运的是，即使这些安全部分不是微软的责任，Azure 中仍然有许多安全服务可用。许多 Azure 服务的唯一目的是解决安全问题，帮助我们保护 Azure 数据中心中的数据和资源。再者，事情并不止步于此。即使这些服务与安全无关，Azure 的大多数服务也内置了某种安全功能。微软非常重视安全，并使我们能够使用许多不同的工具来保障资源的安全。

可用的工具各不相同，从通过启用多个选项帮助我们增加安全性的工具，到有大量配置选项帮助我们设计安全性的工具，再到监控我们 Azure 资源并提供我们需要实施的安全建议的工具。某些 Azure 工具使用机器学习帮助我们实时检测安全事件，甚至在事件发生之前就能发现。

本书将涵盖微软 Azure 安全性的各个方面，从治理和身份，到网络和数据保护，再到高级工具。最终目标是理解云安全，学习如何结合不同的工具最大化安全性，最终掌握 Azure 安全！

总结

本章最重要的教训是理解 Azure 中的共享责任模型。微软负责一些安全部分，特别是在物理安全方面，但我们需要负责其余部分。

在 Azure 网络、完整性、可用性和监控方面，我们没有影响力，无法做出任何更改（至少在我们讨论的部分是如此）。然而，这些内容非常重要，因为我们可以在可管理的安全部分应用许多东西。它们还将提供更多背景信息，帮助我们更好地理解 Azure 中完整的安全设置。

在下一章中，我们将讨论身份，它是安全性最重要的支柱之一。在 Azure 中，身份甚至更为重要，因为大多数服务是通过互联网进行管理和访问的。因此，我们需要采取额外的步骤，确保身份和访问的安全，做到万无一失。

问题

1. 在云中，谁负责安全？

   A. 用户

   B. 云服务提供商

   C. 责任是共享的

2. 根据共享责任模型，谁负责物理主机的安全？

   A. 用户

   B. 云服务提供商

   C. 两者皆是

3. 根据共享责任模型，谁负责物理网络？

   A. 用户

   B. 云服务提供商

   C. 取决于服务模型

4. 根据共享责任模型，谁负责网络控制？

   A. 用户

   B. 云服务提供商

   C. 取决于服务模型

5. 根据共享责任模型，谁负责数据治理？

   A. 用户

   B. 云服务提供商

   C. 取决于服务模型

6. Azure 网络使用的是哪种架构？

   A. DLA

   B. Quantum 10 (Q10)

   C. 两者都可以，但 DLA 正在替代 Q10

   D. 两者都可以，但 Q10 正在替代 DLA

7. 在发生安全事件时，第一步是什么？

   A. 立即调查

   B. 缓解

   C. 通知客户

第二章：第二章: 治理与安全

在深入研究帮助保护和保障 Azure 云环境的技术特性之前，我们首先需要停下来，反思、规划并据此行动。治理至关重要，云中需要有护栏。谈到云计算时，客户往往会表现出一种 开始行动 的心态。这很好，但在云中，也需要有规则。除此之外，你当然不希望最后得到一个完全不适合你公司需求的云构架，对吧？

本章旨在帮助你设计一个安全的云战略基础，并根据你的计划采取行动，我们将引导你通过以下主题：

• 理解 Azure 中的治理

• 运用常识避免错误

• 使用管理锁

• 使用管理组进行治理

• 理解 Azure 策略

• 定义 Azure 蓝图

• Azure 资源图

理解 Azure 中的治理

如果我们深入研究治理的实际含义，我们可以在在线商业词典中找到一个很好的定义。这个定义的第一部分如下：

由组织治理机构成员制定政策，并持续监控其正确实施。

要阅读完整定义，请访问以下链接：www.businessdictionary.com/definition/governance.html

这个定义中最重要的词是 政策、监控 和 实施。如果你将 实施 换成 部署，你会得到三个对安全至关重要的方面。所以，你可以说治理对安全至关重要！

现实生活中适用的规则，在 IT 领域也是适用的。我说的是规则。规则只有在通过 政策 强制执行时才会真正有效。你可以告诉管理员他们不能做什么。但如果他们能够做不该做的事，依然有可能不小心违反你的规则。所以，你需要定义一些政策，帮助你执行或监控公司规则。

监控 是安全中第二个重要的部分。如果你看不到发生了什么，就没有机会做出反应或做出正确的决策。这就是为什么监控如此重要且不可避免的原因。在后续章节中，我们将介绍一些适用于 Azure 的监控最佳实践，帮助你获取适量的信息以应对环境的需求。

最后是实施。你可以使用 Azure 门户手动部署 Azure 资源。然而，采用这种方法时，你肯定需要一套严格的策略来执行你的规则，确保手动部署不会破坏这些规则。如果你希望确保所有环境都严格遵守你的规则，自动化部署是你应该采用的方式。通过制定强有力的治理计划、实施策略和基于角色的访问控制（RBAC），并通过像 Azure DevOps 这样的 DevOps 管道进行部署，你可以确保你的部署和目标环境的一致性。然后，如果你确保环境中的所有更改只能通过你的 DevOps 管道工具进行，而不能通过 Azure 门户手动进行，你就能保护你的环境免受意外更改的影响。你可以使用 PowerShell 进行命令式部署，使用 Azure 资源管理器（ARM）模板和 Terraform 进行声明式部署。无论哪个最适合你的需求，使用它！

重要说明：不同的部署模型

如果你使用像 PowerShell 这样的命令式脚本语言来部署资源，你需要明确描述为了获取所需的基础设施，应该做哪些事情。你需要按正确的顺序定义步骤。而对于像 ARM 模板或 Terraform 这样的声明式语言，你只需描述需要部署到目标环境的资源，因此这里关注的不是如何做，而是做什么。本书稍后会提供这些语言的示例。

使用 Azure 和云计算时，我们需要在安全性和管理方面采用新的方法，一方面，另一方面，仍然有一些传统的、已有数十年历史的行业原则是有效的。其中就有最小权限原则（POLP）。该原则规定程序或用户应只拥有完成任务所必需的最少权限。

职责分离（SoD）是一个即使在云时代依然有效的原则。SoD 是指完成某项任务需要不止一个人的概念。例如，你可能有一个团队负责在 Azure Active Directory 中创建和管理帐户，但另一个团队负责 Office 365 管理，因此也负责创建用户邮箱。第三个团队可能负责管理 Azure 资源。在这个资源团队中，有管理员负责管理数据库，其他人负责管理网络，还有一些虚拟机专家专注于计算资源的管理。SoD 也是多步审批的一部分。例如，当你的管理员申请他们有资格获得的角色时，必须由其他人批准该请求：

图 2.1 – 先规划，后执行 – 定义可能的 Azure 层级结构

在开始使用 Microsoft Azure 云服务时，首先要做的是规划你的 Azure 层次结构，这描述了 Azure 订阅、租户和目录在企业环境中是如何相互依赖的。目的是为一个企业拥有一个合同，但有多个 Azure 订阅。每个 Azure 订阅都与一个 Azure Active Directory 租户绑定（理想情况下，你应该只有一个！）。你可能想按位置划分公司，例如欧洲和北美。或者，你可能希望按部门划分公司，例如 IT 部门和财务部门。你也可以选择两者都做——甚至可以选择其他层次结构。无论什么最适合你的需求，都应该在实际开始之前完成。高层次的层次结构模式有三种：职能型，即基于企业部门（如 IT 和会计）创建订阅；业务单元型，可以用来区分业务单元，如航空航天和汽车行业；以及地理型，即根据公司地理位置创建订阅。你选择的层次结构应该与你企业的管理需求和地理位置相匹配，以便在根据公司需求授予访问权限和计费时提供支持。

现在你已经知道了治理是什么以及它为何重要，让我们继续看看有哪些工具可以帮助我们简化治理和安全方面的工作。

运用常识避免错误

我常常被问到，如何确保 Azure 管理员不会不小心删除云中的生产资源。除了下一节将要讨论的技术功能之外，答案是常识非常有帮助！你不会不小心走进本地数据中心，把你的服务器从机架上拉出来并把它扔出窗外，对吧？你通常不会对 Hyper-V 农场运行一个一键清除脚本，然后等到当天稍后才意识到所有虚拟机都不见了吧？而且你肯定不会不小心删除你的生产 SAN！在 Azure 中，你不可能不小心删除一个资源组。

嗯，如果你不小心确认了“你确定吗？”对话框，然后不小心将资源组的名称输入到提示框中，那么是可以的。资源甚至更容易被删除——无论是偶然还是故意的。因此，我们需要一些方法来帮助我们减少事故的风险。常识和良好的谨慎态度是云治理成功的第一步。

然而，即使小心谨慎，您仍然可能不小心删除不该删除的东西。例如，您可能会不小心删除单个资源，如存储账户、密钥保管库或其他任何资源。我记得大约 10 年前的一个夏日下午，我在一块小型硬件主板上运行 Linux 防火墙发行版，它和今天的 Raspberry Pi 类似。我将这块小硬件作为我的家庭防火墙解决方案，它做得非常出色。它有三个局域网连接，连接到三个不同的网络，甚至还有一个 Wi-Fi 模块，并且操作系统安装在 CF 卡上。只有 RAM 是有限的，由于 CF 卡专门用于操作系统安装，所有日志都写入了 RAM 磁盘。因此，我必须定期从 /var/log/* 目录中删除日志文件。我不想启用日志轮转，而是希望将日志导出到我环境中的另一台 Linux 服务器。好吧，长话短说，我可以告诉你，运行以下命令时，拥有提升权限的情况下效果相当不错——即使你没有将工作目录切换到预期的目录：

rm -rf *

所以，我又有一个星期六下午重新安装和重新配置防火墙。下次，行动之前要三思而后行！教训得到了。

在下一节中，我们将探讨一个技术功能，用于防止管理员不小心删除 Azure 资源。

使用管理锁

当然，也有一个技术功能可以防止您不小心删除 Azure 上的任何内容——一个叫做 管理锁 的功能。Azure 中有两种不同类型的锁：

• 删除锁确保没有人能够不小心或故意删除您 Azure 订阅中的资源。授权用户仍然可以读取和修改资源，但他们不再能够删除它。

• 只读锁确保只有授权用户能够读取资源，同时确保他们无法修改或删除资源。

在我创建的每个订阅中，我通常使用一个核心资源组，将跨多个资源组使用的资源部署到该资源组中。例如，如果我有一个虚拟网络，它被整个订阅中的多个服务使用，或者我有一个密钥保管库，用于存储作为机密的管理员凭证，那么这些资源就会被创建在我的核心资源组之一中。正如您所想象的那样，那里的资源非常重要，因此我总是在这个核心资源组的范围内使用删除锁。

在本章讨论范围时，我们讨论的是管理层次结构。锁、策略和访问权限始终应用于特定的范围，并且它们始终是从上到下应用的：

图 2.2 – 从上到下的 Azure 范围：管理组、订阅，

资源组和单个资源

如果在订阅级别创建锁定，它将适用于该订阅下的所有资源组以及所有资源。如果在资源组级别创建锁定，它只会应用于该资源组内的资源：

图 2.3 – Azure 资源组的管理锁定

为了演示，我在我的核心资源组之一中创建了一个存储账户 masteringazuresecurity。如果你在左侧管理窗格中选择了 锁定，你会看到有人在资源组级别创建了一个名为 MasteringAzSecDemo 的 删除 锁定。当你尝试删除该存储账户时，以下消息将会显示：

图 2.4 – 尝试删除被锁定资源时的警告消息

重要提示：

只有在你具有 Microsoft.Authorization/* 或 Microsoft.Authorization/locks/* 管理操作的访问权限时，才能创建或删除管理锁。在 Azure 中有几个内置角色，其中只有 所有者 和 用户访问管理员 才被授予这些特定的管理操作权限。

现在你已经了解了如何在 Azure 中使用管理锁定以及可以用来创建它们的范围。在下一节中，我们将探讨如何使用管理组，这是最重要的范围层次之一，以及如何利用它们来定义你的云治理。

使用管理组进行治理

如前所述，在治理、护栏、规则和政策方面，制定计划并遵守计划是至关重要的。使用多个订阅的组织需要一种高效的方式来管理所有订阅的访问、策略和合规规则。通过 Azure 管理组，我们可以在订阅级别之上提供一个范围层次：

图 2.5 – 管理组层级结构示例

通过管理组，我们可以配置不同的管理范围，使我们能够轻松地管理所有治理设置，且无需太多精力。前面的图示展示了一个可能的管理组层级结构。如图所示，一个管理组可以包含多个订阅和其他管理组。该示例显示了一个层级结构，其中已创建并附加到不同管理组的几种类型的订阅。你可以在同一租户中拥有 按需付费（PAYG）订阅、企业协议（EA）订阅和开发/测试订阅，并将它们附加到任何管理组。

也许您希望确保在 Azure 中为生产环境创建的所有资源仅存储在欧洲的两个 Azure 区域，West Europe 和 North Europe。在这种情况下，您可以创建一个包含所有生产订阅的管理组，然后将策略应用于该管理组，以限制资源仅能在这些区域创建。管理组的另一个使用场景可能是为多个 Azure 订阅一次性提供用户访问权限，而不是为每个订阅单独管理访问权限。

每个 Azure AD 目录都有一个顶级管理组，称为根管理组。为该 Azure 租户创建的所有订阅和管理组都属于此根组。根管理组使客户能够创建适用于 Azure 租户范围内所有 Azure 订阅的全局策略和角色分配。

根组的默认显示名称是租户根组。以下是关于租户根组的一些重要信息，您应该了解：

• 只有在租户根组上被分配了所有者或贡献者角色的用户账户才能更改其显示名称。

• 根组不能被删除或移动到其他管理组。

• 在 Azure 层次结构中，所有订阅和管理组都归属于各自目录中的一个租户根组。每个目录只有一个租户根组，而所有其他管理组、订阅和资源都是此租户根组的子对象。换句话说，所有订阅中的所有资源都归属于租户根组以进行全局管理。新订阅在创建时会自动附加到租户根组。

• 没有任何人被默认赋予租户根组的访问权限。只有 Azure AD 全局管理员有权提升自己的权限以获取访问权限并在必要时进行更改。

您可能希望将安全管理员赋予对在 Azure AD 租户范围内创建的所有资源的只读访问权限，因为他们需要查看所有订阅和管理组。或者，您可能希望为所有 Azure 订阅提供应用程序访问权限；例如，自动部署资源或收集计费信息的能力。因此，您可能希望更改租户根组的某些设置，以便您只需管理一次访问权限。由于默认情况下没有人能够访问租户根组，您首先需要为 Azure AD 全局管理员提升访问权限。

当为 Azure AD 全局管理员提升访问权限时，在 Azure 中根范围（/）下为该账户分配了用户访问管理角色。在根范围下，此角色允许账户查看所有资源，并分配访问权限到整个目录下的任何订阅或管理组！

要提升访问权限，请执行以下步骤：

1. 作为全局管理员登录到 Azure 门户或 Azure Active Directory 管理中心。

2. 点击Azure Active Directory，然后在导航列表中点击属性：

   图 2.6 – Azure Active Directory – 属性

3. 在Azure 资源的访问管理下，将切换按钮设置为是：

图 2.7 – 启用所有 Azure 资源的访问管理

提示

访问权限应始终尽可能严格，并且应仅在需要时授予。因此，在你对租户根组进行更改后，一定要移除提升的访问权限。

要移除提升的访问权限，可以将切换按钮从根范围的 用户访问管理员 角色分配恢复：

Remove-AzRoleAssignment -SignInName <username@example.com> `
  -RoleDefinitionName "User Access Administrator" -Scope "/"

重要提示：

为了能够执行此 PowerShell 命令，你需要安装最新版本的 Az PowerShell 模块。由于不能同时安装旧版的 AzureRM 和新版的 Az PowerShell 模块，你需要首先卸载 AzureRM 模块。有关更多信息，请参阅 docs.microsoft.com/en-us/powershell/azure。

你刚刚学习了如何使用管理组进行治理。在接下来的章节中，我们将介绍 Azure Policy，它是一个强制执行规则的服务。

了解 Azure Policy

规则很重要，但为了确保它们不被违反，你需要监控它们的应用，或者强制执行它们。通过 Azure Policy，你可以使用一个服务来实现这两者。Azure Policy 允许你创建、分配和管理策略。你定义的策略强制执行在策略范围内创建的资源的不同规则。

Azure Policy 服务会评估资源是否违反已分配的策略，然后执行定义的操作。例如，你可能只希望允许 Azure 管理员在北欧和西欧的 Azure 区域中创建 Azure 资源，或者你可能只希望在某个 Azure 订阅中使用某一特定的 VM SKU 尺寸。在这些情况下，你可以创建一个策略。一旦这个策略被创建并激活，新的和现有的资源将会被评估是否符合政策要求。如果不符合要求，新的资源将被禁止创建，现有资源也可以根据需要进行合规性调整。

你可以为你的策略定义四种不同的效果类型：

• 禁用在测试新的策略定义效果时非常有用，或者当你只想禁用特定策略定义的一个分配，而不是所有分配时。

• 附加用于在资源创建或更新过程中向请求的资源添加额外字段。使用附加策略时，你可以例如为资源添加标签，如resourceOwner或costCenter。

• 拒绝 用于拒绝不符合你的合规标准的资源请求。评估后，资源请求将失败。使用拒绝策略，你可以例如防止管理员在不允许的 Azure 区域创建资源，或防止他们部署未经批准的虚拟机 SKU 大小。

• 审核 用于在评估不合规资源时在活动日志中创建警告事件。资源请求不会被停止，但你会收到不合规的通知。

在使用 Azure 策略时，你可能需要创建自定义策略定义或使用 Azure 自带的某些内置策略定义，例如以下几种：

• 允许的位置： 此策略定义限制了新资源可用的位置。它用于执行你的地理合规要求。

• 审核未使用托管磁盘的虚拟机： 此策略审核未使用托管磁盘的虚拟机。每个虚拟机会在活动日志中生成一个警告事件。

• 允许的虚拟机 SKU： 此定义指定了可以部署的虚拟机 SKU 集。

策略定义描述了资源合规性以及当资源不合规或变得不合规时应使用的效果。策略定义的架构文档请参见 schema.management.azure.com/schemas/2018-05-01/policyDefinition.json。策略定义是以 JSON 格式创建的。

策略定义包含以下元素：

• 模式

• 参数

• 显示名称（在 Azure 门户或 CLI 中的显示方式）

• 描述（此策略的实际作用，何时使用等）

• 策略规则（规则定义）

• 逻辑评估：资源合规性的条件是什么？

• 效果：如果资源不合规，会发生什么？

模式

策略模式决定了政策评估哪些资源类型。支持两种模式：

• all：评估所有资源组和资源类型。

• indexed：仅评估支持标签和位置的资源类型。

如果你通过 Azure 门户创建策略，则模式始终设置为 Apply。如果使用 PowerShell 或 Azure CLI，则可以手动指定模式参数。

重要说明：

如果你的自定义策略定义不包含模式值，则在 PowerShell 中默认设置为 all，在 Azure CLI 中默认设置为 null。null 值等同于出于向后兼容的原因使用 indexed。

参数

策略定义中的参数有助于减少策略定义的数量。你可以将它们视为表单中的字段，例如名字、姓氏和街道地址。参数始终保持不变；只有根据填写表单的人不同，其值才会变化。通过在策略定义中包含参数，你可以重复使用该策略，并相应地更改值。

参数属性

参数具有以下属性：

• name：你的参数的名称。

• type：参数类型可以是string、array、object、boolean、integer、float或datetime。

• metadata：Azure 门户使用的参数子属性，用于显示参数的用户友好信息。

• description：对参数用途的说明。

• display name：在 Azure 门户中显示的参数的友好名称。

• strongType：（可选）此属性在通过 Azure 门户分配策略时使用。目前支持的strongType选项列表可以在docs.microsoft.com/en-us/azure/governance/policy/concepts/definition-structure#strongtype找到。

• assignPermissions：（可选）如果此值设置为true，Azure 门户将在策略分配过程中创建角色分配。如果你想在策略分配范围之外分配权限，此选项可能会很有用。

• defaultValue：（可选）如果在策略分配时未指定值，则使用此值。如果你更新一个已分配的现有策略定义，则defaultValue是必需的。

• allowedValues：（可选）此属性提供一个值的数组，参数在策略分配期间将接受这些值。

你可能希望将 Azure 资源的创建限制在少数几个 Azure 区域。在一个仅允许在欧洲 Azure 区域创建资源的策略中，你可以定义一个名为allowedLocations的参数。在每次策略分配时，都会使用并评估此参数。定义了strongType值后，在 Azure 门户中分配策略时会出现一个额外字段：

"parameters": {
    "allowedLocations": {
        "type": "array",
        "metadata": {
            "description": "The list of allowed locations for resources.",
            "displayName": "Allowed locations",
            "strongType": "location"
        },
        "defaultValue": [ "westeurope" ],
        "allowedValues": [
            "northeurope",
            "westeurope"
        ]
    }
}

上述代码展示了 Azure 策略定义中的参数定义部分。在这种情况下，allowedLocations参数是一个数组，包含两个允许的值，northeurope和westeurope。默认值设置为westeurope，这意味着如果你未将参数设置为其他值，系统将默认选择此位置。然后，在策略规则中，参数的引用如下：

"policyRule": {
"if": {
      	"not": {
                	"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": {
      	"effect": "deny"
}
}

为此目的，整个策略定义可能如下所示：

{
    "properties": {
        "mode": "all",
        "parameters": {
            "allowedLocations": {
                "type": "array",
                "metadata": {
                    "description": "The list of locations that can be specified when deploying resources",
                    "strongType": "location",
                    "displayName": "Allowed locations"
                },
                "defaultValue": [ "westeurope " ]
                "allowedValues": [
            "northeurope",
      		      "westeurope"
        	    ]
            }
        },
        "displayName": "Allowed locations",
        "description": "With this policy you can restrict resource creation to Azure regions your organization allows.",
        "policyRule": {
            "if": {
                "not": {
                    "field": "location",
                    "in": "[parameters('allowedLocations')]"
                }
            },
            "then": {
                "effect": "deny"
            }
        }
    }
}

策略分配

在创建策略定义时，您需要将其分配到特定的作用域，以使策略生效。这就是微软所称的策略分配。策略分配的作用域可以是从管理组、订阅到资源组的任何内容。策略分配会从父资源传递到子资源。因此，分配给管理组或订阅的策略也会应用于该作用域内的所有下游资源。但您也可以将某个子作用域排除在策略分配之外。例如，假设您想防止管理员在欧洲以外的地方创建资源。然而，您有一个资源组需要在欧洲以外的地方创建物联网资源。在这种情况下，您可以创建一个策略定义，仅允许在某个欧洲 Azure 区域内创建资源。此策略被分配到管理组，因此将应用于该作用域内的所有订阅、资源组和资源。然后，您将排除该资源组的策略分配，因此该策略不会应用于该组。

启动定义

策略用于强制执行一条规则。启动是几个相关规则的集合。例如，Azure 安全中心自带的一个预配置启动定义。在这个启动定义中，您将找到所有的审计策略，这些策略将在 Azure 安全中心的建议部分中显示，这部分内容将在本书后面介绍。启动用于简化策略分配。使用启动，您无需分配多个策略。只需分配一个启动并将相应的策略添加到其中。

启动分配

与策略一样，启动也需要分配到特定作用域才能生效。启动分配的作用域与策略分配的作用域相同。

策略最佳实践

在策略方面，有一些最佳实践是您应该牢记的：

• 在管理组级别定义策略和启动。通过这样做，您可以将它们分配给所有子订阅和资源组，而无需重新定义它们。如果在订阅级别定义策略和启动，您只能将它们分配给该单个订阅。因此，简而言之，定义应在管理组级别创建，而分配可以在管理、订阅或资源组级别进行。

• 像往常一样，在阻止用户工作之前，您应该首先测试您的新策略。您可以通过定义审计策略，而不是直接使用拒绝策略来做到这一点。通过审计效果，您可以感受您的策略定义会产生的影响。拒绝策略可能会破坏您的 DevOps 部署链，而通过审计效果，您可以了解您的策略在以后会产生什么影响。

• 即使你只想创建一个单一的策略定义，创建计划定义也是一个好主意。如果你有了计划，你可以在以后轻松地添加更多策略，前提是你需要这么做。

• 在评估计划定义时，会评估该计划中的所有策略。如果你有某个特定的策略不希望在该上下文中进行评估，你应该将其从定义中移除，并单独进行分配。

在前面的部分中，你已经了解了治理的基本概念、范围、策略和锁定。接下来的部分，你将学习如何通过定义 Azure 蓝图将这些内容整合起来。

定义 Azure 蓝图

现在你已经知道如何定义 Azure 层次结构以及如何使用锁定和策略，你可能希望创建一个适用于所有订阅和未来创建的订阅的模板。使用 Azure 蓝图服务，你可以为此目的获得正是你需要的东西。在这种情况下，蓝图是一个可重复使用的模板，你只需定义一次，然后在未来所有 Azure 订阅的创建过程中使用它。这里的好处是，你可以定义组织规则集，并自动将它们应用到所有订阅，同时加速部署过程。借助 Azure 蓝图，你可以声明式地将 Azure 资源和工件部署到所有订阅中，例如以下内容：

• 角色分配

• 策略分配

• ARM 模板

• 资源组

• 锁定

在本章关于管理锁定的部分中，我提到我通常在所有订阅和客户订阅中拥有一个核心资源组。这些资源组通常会被锁定，以防止意外删除。在较大的组织中，你可能希望为开发人员或专业部门提供创建自己环境的选项，而不破坏你的规则。无论是什么情况，只要你想要自动化复杂的标准化 Azure 环境部署，Azure 蓝图就是你首选的服务！

蓝图定义

Azure 蓝图是通过所谓的工件定义的。当前，工件可以是以下之一：

• 资源组：由蓝图创建的资源组可以被蓝图范围内的其他工件使用。例如，你可以在蓝图中创建一个资源组，然后将一个 ARM 模板引用到这个新的资源组。

• 策略分配：你可以将现有策略分配给一个已分配蓝图的订阅或资源组。例如，你可以将本书前几章中的“仅限欧洲 Azure 位置”策略分配给一个订阅。

• 角色分配：你可以为分配给此蓝图的订阅分配管理权限。例如，你可以为基础设施管理员的新订阅自动分配贡献者权限。

• ARM 模板：使用 ARM 模板，你可以声明式地部署复杂的 Azure 环境。ARM 模板可以在 Azure 蓝图的范围内使用。例如，你可以在蓝图范围内自动在核心资源组中创建一个新的 Log Analytics 工作区。

  重要提示：

  蓝图定义可以保存到管理组或订阅中。如果你在管理组级别创建蓝图定义，你可以在此特定管理组范围内对所有子订阅使用该蓝图进行分配。

蓝图发布

每个新创建的蓝图最初都处于 草稿 模式。完成所有配置后，蓝图需要被 发布。发布蓝图时，你需要定义一个 版本 字符串，并可以选择性地添加更改说明。当对该蓝图进行额外更改时，已发布的版本仍然存在，而更改将在草稿模式下进行。

当修改蓝图（并保存更改）时，同一个蓝图会存在多个版本，以确保你仍然可以分配旧版本，并且在应用更改时不会影响已发布的版本。

你可以通过创建一个新的空白蓝图或从 Azure 门户选择一个蓝图示例来开始。例如，有些蓝图定义会分配必要的策略，以满足特定的 NIST SP 800-53 R4 或 ISO 27001 控制要求：

图 2.8 – 创建蓝图定义时，你可以选择一个预定义的示例蓝图

要开始创建蓝图定义，请执行以下操作：

1. 导航到 所有服务 -> 蓝图。

2. 选择 创建。

3. 当向导出现时，你需要为你的蓝图命名，然后选择保存蓝图定义的位置。在下面的截图中，我决定将蓝图保存在我的 Tenant Root Group 中，以便在所有当前或将来可能附加到我的 Azure AD 租户的订阅中使用该蓝图：

   图 2.9 – 创建蓝图 – 基本信息

   我决定使用 ISO 27001 蓝图示例进行本演示。在第二个标签页 工件 标签页中，你可以根据需要添加、移除或编辑工件。你可以随时保存草稿，稍后再回来修改、添加或移除任何内容：

   

   图 2.10 – 保存蓝图到草稿模式后的上下文对话框

4. 完成后，你需要将蓝图定义发布为新版本。版本基本上是一个自定义文本字段，你需要定义它。选择版本号是有意义的，这样你可以轻松地迭代版本。然而，你可以使用任何适合你需求的蓝图版本名称。我决定将蓝图版本命名为0.1：

   图 2.11 – 发布新蓝图后显示的上下文对话框

   发布蓝图后，上下文对话框会发生变化，并为你提供一个新菜单选项，分配蓝图。

5. 现在，你可以将新的蓝图分配给任何现有的订阅，或者直接从对话框中选择创建一个新的订阅：

图 2.12 – 新蓝图分配

一旦你分配了蓝图，蓝图定义中定义的策略将被应用，同时资源组和资源也会被创建。你还可以在分配蓝图时分配锁定。如果你在蓝图分配时应用了锁定，则只有在取消分配蓝图时才能移除它。

重要提示：

你可以在将蓝图分配给订阅时分配管理锁定。但是，如果你这样做，锁定不能仅由订阅所有者移除，而只能在取消从订阅中分配蓝图时移除。

你需要为蓝图分配定义一个位置。这是因为蓝图使用托管身份（MI）来部署你在蓝图定义中定义的工件，如资源和资源组。你可以使用系统分配的 MI，也可以选择使用用户分配的 MI。如果你使用系统分配的 MI（默认设置），该 MI 将临时被授予在蓝图分配范围内的订阅的所有者权限。需要拥有者权限，以确保蓝图服务能够正确创建和设置所有的工件和锁定。当蓝图分配过程完成后，系统分配的 MI 的拥有者权限会自动从你的订阅中移除。

根据你在蓝图定义中定义的工件，你可能需要在分配过程中定义工件参数：

图 2.13 – 在蓝图分配期间配置工件参数

在我们的例子中，我们从 ISO 27001 蓝图示例开始。这个蓝图定义包含多个政策，比如限制资源部署仅限于少数 Azure 区域，或者将 Azure Log Analytics 代理部署到 Windows 和 Linux 虚拟机。所有这些政策的参数本应已经在蓝图定义中进行定义。然而，如果我们这样做了，所有参数对于所有订阅都会相同，且无法根据你分配蓝图的订阅来定义。这对需要在每个系统环境中强制执行的公司限制可能非常有用，但这也会限制蓝图/政策的灵活性。

在这种情况下，最佳实践是定义所有在蓝图定义中永远不能更改的参数。例如，如果公司资源仅允许部署在某些 Azure 区域，这将非常有用。但对于 Log Analytics，最好在每个 Azure 区域部署一个单独的工作区，以避免因跨区域网络流量而产生费用。这应该在蓝图分配时定义。

提示

最佳实践：在蓝图定义中定义适用于所有订阅的工件参数。在蓝图分配过程中定义仅适用于特定订阅的工件参数。

现在你已经了解如何定义治理概念，以及我们今天所拥有的所有功能如何协同工作，我们将深入了解 Azure 资源图，这是一个帮助你收集在 Azure 租户范围内创建的所有资源信息的引擎。

Azure 资源图

你是否曾尝试获取所有部署在欧洲以外的 Azure 资源的信息？或者，如何列出你所有订阅中的所有 Azure 虚拟机（VM）？在理解 Azure 中的治理部分，我提到过监控对于安全至关重要，如果没有有效的监控实践，你就像一头瞎子。现在，如果你尝试获取类似我们在讲解Azure 资源管理器（ARM）时讨论的信息，你可能会一直等待。你甚至可能没有能力一次性获取所需的所有信息。

Azure 资源图（Azure Resource Graph）是一个相对较新的服务，帮助你收集所有租户的 Azure 订阅中的资源信息。听起来很棒，对吧？确实，它非常棒。

你可以把 Azure Resource Graph 看作是一个大型的索引数据库，包含所有资源，可以使用Kusto 查询语言（KQL）进行查询。每当你创建或更新资源时，ARM 会通知 Azure Resource Graph 这一变化，Azure Resource Graph 数据库会进行更新。为了确保没有漏掉任何通知，并且在你在 ARM 之外更新资源时，Azure Resource Graph 会定期进行全扫描，除了接收通知外，这样数据库能够保持最新。

为了能够使用 Azure Resource Graph 查询你的资源，你需要至少具有查询资源的读取权限。换句话说，你只能看到你有权限查看的资源。因此，查询结果始终取决于当前登录 Azure 门户、Azure CLI、PowerShell 或 REST API 的帐户。

使用 PowerShell 查询 Azure Resource Graph

如果你想使用 PowerShell 查询 Azure Resource Graph，请按照以下步骤操作：

1. 使用以下命令安装 Az.resourcegraph PowerShell 模块。

   First, install the PowerShell module for Azure Resource Graph:
   install-module Az.resourcegraph
   

   然后，将模块导入到当前的 PowerShell 会话中：

   import-module Az.resourcegraph
   

2. 使用以下 PowerShell 命令来确保模块已正确安装：

   get-command -module Az.resourcegraph
   

   你应该看到以下输出：

   

图 2.14 – Az.ResourceGraph 模块已成功安装并导入

目前，Az.ResourceGraph PowerShell 模块在线包含一个 cmdlet，即 Search-AzGraph。将来可能会有所变化，所以请确保始终使用最新版本的 PowerShell 模块。

现在，你可以开始使用 PowerShell 查询 Azure Resource Graph。例如，我们想获取所有资源名称中包含“core”一词的 Azure 资源列表，并限制输出为五个结果。现在，有趣的地方是，Search-AzGraph cmdlet 已经为你提供了需要查询的数据库列，所以在查询时，你只需要定义你的过滤逻辑。

一个 KQL 查询通常是这样的：

database |
where <filter logic> |
project columnname1, columname2 |
limit n

由于数据库名称是由 Search-AzGraph 给出的，我们只需要定义过滤逻辑。因此，对于刚才描述的结果，你的 PowerShell 命令，包括查询，可能如下所示：

Search-AzGraph -Query 'project name, type | where name contains "core" | limit 5'

该命令将为你提供最多五个结果，这些结果的资源名称中包含“core”一词：

图 2.15 – 你的第一次 Azure Resource Graph 查询结果（使用 PowerShell）

你现在已经学会了如何使用 PowerShell 查询 Azure Resource Graph。在接下来的章节中，你将学习如何使用 Azure CLI 获取相同的查询结果。

使用 Azure CLI 查询 Azure Resource Graph

如你从前面的截图中可能已经看到的，我在 macOS 的 Bash 终端中使用 PowerShell Core。这完全没有问题，因为我既喜欢 PowerShell 又喜欢 macOS，对我来说这是个不错的选择。然而，使用 Azure CLI（基于 Python 的命令行界面，可以在 Windows、macOS 和 Linux 上运行），你也可以轻松查询 Azure Resource Graph。如果你已经安装了最新版本的 Azure CLI，你只需通过以下命令进行交互式登录：

az login

接下来，系统会提醒你，浏览器窗口已打开，你可以在其中输入凭据，完成多重身份验证挑战，并处理所有与 Azure AD 相关的其他安全事务（这些内容将在本书的下一章讨论）。登录后，Azure CLI 会显示你账户所拥有访问权限的所有订阅概况：

图 2.16 – Azure CLI – 交互式登录成功

如果你现在尝试获取 az graph 的帮助（这是访问 Azure Resource Graph 的起始命令），你将看到一条错误信息，因为需要先将图形扩展添加到你的 Azure CLI 环境中：

图 2.17 – 当 Azure Resource Graph 扩展尚未启用时，Azure CLI 中的错误信息

所以，让我们添加图形扩展：

1. 在 Bash 会话中输入以下命令：

   az extension add --name resource-graph
   

2. 你现在可以运行在 PowerShell 中运行的相同查询（但使用 Azure CLI 语法）：

   az graph query -q "project name, type | where name contains 'core' | limit 5"
   

运行此查询将返回以下输出：

图 2.18 – 你的第一个 Azure Resource Graph 查询结果（使用 Azure CLI）

所以，查询本身将保持不变。它只是被包装在 Azure CLI 语法中，而不是 PowerShell。

高级查询

现在你已经知道如何在 Azure CLI 和 PowerShell 中运行查询了，或许你有兴趣运行一些高级查询，对吧？那么，这里是相关查询。你在这里找到的查询可以在 Azure CLI 和 PowerShell 中运行。

首先，让我们尝试获取更多关于资源的信息——不仅仅是名称和类型，并且不限制输出结果的数量；让我们筛选特定的订阅。查询可能如下所示：

where subscriptionId == 'your subscription ID' and name contains 'core'

Azure CLI 的命令如下：

az graph query -q "where subscriptionId == 'your subscription ID' and name contains 'core'"

对于 PowerShell，你输入以下命令：

Search-AzGraph -Query "where subscriptionId == 'your subscription ID' and name contains 'core'"

你将看到，根据你的访问权限和资源类型，你的查询结果将为你提供大量信息。在我的环境中，作为查询结果出现的单个资源——一个虚拟网络——的截图大约会占用本书的两页。幸运的是，即使你的查询返回了很多资源，由于你查询的是 Azure 资源图数据库而不是 Azure 资源管理器，你的结果也会接近实时返回，而 Azure 资源管理器必须“与”每个资源先进行通信。

总结

在本章中，你已经了解了为什么治理对安全至关重要，以及 Azure 提供了哪些功能来帮助你为公司建立治理概念。你已经学会了如何分组和组织订阅和资源，如何执行策略，以及所有最佳实践，以确保你有效且不破坏系统地进行操作，并创建一致且可重复的环境。我们知道，在这片选择的丛林中找到一条出路并不容易，但当你停下来、思考、计划、行动并重复时，你将走上发现最适合你需求的道路。

在下一章中，你将不仅学习如何通过管理云身份来跟踪访问权限并监控用户行为中的任何异常，还将学习保护身份的策略，以及如何减少特权账户的攻击面。

问题

1. 治理中最重要的部分是什么？

   A. 策略

   B. 监控

   C. 实施

   D. 以上所有

2. 在部署问题中，治理中需要定义什么？

   A. 我们需要定义可以部署的内容

   B. 我们需要定义部署步骤

   C. 我们需要定义“什么”和“如何”

   D. 这取决于部署方法

3. 哪个功能可以防止意外删除资源？

   A. 资源锁定

   B. 删除锁定

   C. 管理锁定

4. 群组层级的最高级别是什么？

   A. 租户

   B. 管理组

   C. 订阅

   D. 资源组

5. Azure 蓝图应用在哪个级别？

   A. 资源

   B. 订阅

   C. 资源组

6. 我们可以用 Azure 蓝图定义什么？

   A. 角色分配

   B. 策略分配

   C. 以上两者

   D. 以上都不是

7. 什么是 Azure 资源图？

   A. 控制部署的服务

   B. 一个收集信息的服务

   C. 以上两者

   D. 以上都不是

第三章：第三章：管理云身份

在过去，IT 安全几乎等同于阻挡网络流量，那时的生活非常简单。你可以确信你的物理围墙构建了你的边界，因此你只需要保护你的边界。然而，今天，仅靠网络端点已经不足以保障你的边界。如今，我们看到越来越多针对企业环境的钓鱼攻击和凭证窃取攻击。我们正处于一个企业数据逐渐脱离其安全企业网络环境的时代。这是云服务时代，例如 Office 365，因此传统的安全策略不足以保护数据，因为数据已经在安全围墙之外。我们需要在传统方法的基础上增加新的方法。这种新方法就是“身份是新的边界”。这使得身份成为我们比以往任何时候都更需要保护的内容。当然，这并不意味着我们必须放弃保护网络的旧方法，我们将在第四章《网络安全》中探讨这一点。

一般来说，为了避免随机攻击，你需要提高门槛，并让攻击尝试对攻击者来说尽可能昂贵。这就像保护你的家一样：如果你用更高的抗性等级（RC）保护前门，在窗户前安装格栅，使用自动照明系统照亮你的财产，而你的邻居没有这样做，那么寻找随机目标的窃贼很可能根本不会尝试攻击你的家。这是因为对你的家进行攻击可能会非常耗时，或者被发现的概率太高；因此，从攻击者的角度来看，代价太高。如果你遭受的是针对你的家或身份的精心策划、针对性的攻击（没有绝对的安全！），那么这种方法就不起作用，但它有助于抵御所有随机的攻击尝试。

本章不仅将介绍保护身份的策略，还将帮助你了解如何减少特权账户的攻击面。我们将讨论的主题如下：

• 探讨密码和密码短语

• 理解多因素认证（MFA）

• 使用条件访问

• 介绍Azure Active Directory (Azure AD) 身份保护

• 理解基于角色的访问控制（RBAC）

• 使用 Azure AD 特权身份管理（PIM）保护管理员账户

• 混合认证和单点登录（SSO）

• 理解无密码认证

• 许可证考虑

探讨密码和密码短语

在谈论身份安全时，有一个原则你必须始终记住：假设已经被攻破。问题不在于你的账户是否被攻击，而在于你是否知道这一点以及你是否能防止攻击者成功。我们已经可以看到，每天都有许多成功攻击云身份的案例。没有单一的解决方案能保护你的身份，但你需要利用更广泛的工具集，以应对身份攻击。

重要提示

问题不在于你的云身份是否受到攻击，而在于你是否能确保攻击者不会成功。

如果我们从密码谈起，你可以说没有人喜欢它们。嗯，攻击者倒是喜欢，因为它们常常为攻击者提供了进行后续以身份为中心的攻击的契机。鉴于人们往往根据自己的生活经历创建密码，攻击者通常需要擅长收集有关特定用户的背景信息，以猜测其密码。当然，这意味着攻击者需要付出一些努力，而这通常会在针对高价值目标的复杂攻击中进行。你可以看到，密码并不是保护账户的好方法。

此外，密码还可能导致拒绝服务（DoS）攻击。在 Windows Server 的Active Directory 域服务（AD DS）中，许多公司使用相应的安全策略，在多次登录失败后，锁定用户账户一定时间（或无限期）。问题在于，已认证的用户——即那些能够登录到 Active Directory 的用户——能够读取这个安全策略，并且他们能够列出 AD 中的用户账户。已认证的用户可以是任何员工（内部攻击者），也可以是某个试图从外部攻击公司并且能够获取一组登录凭证的人（外部攻击者）。利用 PowerShell，攻击者可以轻松地：

• 了解当前的安全政策

• 列出所有用户账户

• 尝试使用错误密码登录，锁定所有用户账户

• 每隔X分钟重复此脚本。

如果有人这么做，本目录中的任何人都将无法再登录，因此公司将遭受拒绝服务（DoS）攻击。也就是说，你不应该实施这种锁定策略，而是应监控登录尝试，并在出现异常情况时做出明智决策。请留意 Windows 服务器上的安全事件日志，或 Linux 上的 syslog/auth 日志域。

字典攻击与密码保护

字典攻击，例如暴力破解和密码喷洒攻击，仍然每天都会成功。在字典攻击中，攻击者尝试将用户名和常见的、经常使用的密码组合用于身份验证服务。暴力破解攻击比较显眼且更容易被识别。在暴力破解攻击中，攻击者会对一个用户帐户尝试多个密码，希望其中一个攻击能够成功。在后端，你会看到大量失败的登录尝试，因此你可以轻松地作出反应。然而，密码喷洒攻击则更加隐蔽，因为攻击者只会对多个用户帐户使用少量的密码。如果攻击非常缓慢且分散，那么就很难发现攻击。为了避免在云中，尤其是在 Azure AD 中，密码喷洒和暴力破解攻击的成功发生，可以采用一些简单的最佳实践：

• 鼓励用户使用密码短语而不是传统密码

• 阻止在你的环境中不应该使用的密码或模式

目前，你可以在 Azure AD 中使用最多 256 个字符的密码或密码短语。即使你仅使用所有大写和小写字母中的 26 个字母，这也意味着 (2x26)²⁵⁶ 共有 256 种可能性，结果几乎接近无穷大。

话虽如此，考虑到你不仅可以使用大写和小写字母，还可以在密码短语中使用数字和其他字符，这会产生大量的组合。你看，绝对应该启用并鼓励用户使用包含大量字母的密码短语。

对于你不希望在组织中使用的密码，还有另一种选项可以启用。默认情况下，Microsoft 不允许使用可以在密码列表中找到的、已知会被字典攻击使用的密码或密码模式。例如，一个不被允许的模式是你的用户名或其中的任何一部分。此外，可能对你的公司有意义的是避免使用容易与企业相关的密码。这可能包括著名的营销词汇、公司缩写等。在 Azure AD 中，你可以创建一个自定义禁止密码列表，既可以用来审计，也可以强制使用安全密码。你甚至可以使用这个自定义列表为本地 Windows Server AD 启用密码保护，通过安装并启用本地代理。

自定义禁止密码列表最多可以包含 1,000 个区分大小写的词条，长度介于 4 到 16 个字符之间。一个很棒的特点是，字符替代（例如“e”与“3”或“o”与“0”）也会被考虑在内。

图 3.1 - 在 Azure AD 中配置自定义禁止密码列表

要配置自定义的禁止密码列表，你需要在 Azure 门户中导航至Azure Active Directory -> 身份验证方法 -> 密码保护，如图 3.1所示。在该屏幕上，你还会找到自定义智能锁定功能的配置选项。如前所述，你可能会发现本地 AD 安全策略在一定次数的登录失败后强制锁定账户。这是一种开关决策，你可以轻松通过使用相同的密码增加锁定计数器，从而强制账户锁定。记住，这也是为什么你应该禁用本地 AD 中的此类策略并监控登录尝试的原因。

然而，在 Azure AD 中，智能锁定是结合了两全其美的特性：让用户在不被不必要地阻塞的情况下工作，同时防止攻击者猜测你的密码。为了实现这一目标，智能锁定提供了一些有趣的功能：

• 用户并不应该被阻止工作。智能锁定能够识别攻击尝试和有效用户的登录尝试。攻击尝试会被区别对待，因此合法用户仍然可以正常工作，而攻击者则会被阻止。

• 智能锁定会存储最后三个错误密码的哈希值。通过这种方式，你不能仅仅通过多次使用相同的错误密码来增加锁定计数器，从而实施拒绝服务攻击。

• 默认的锁定阈值是 10 次错误尝试，锁定持续时间为 60 秒。智能锁定始终开启在 Azure AD 中；然而，它并不保证合法的用户账户永远不会被锁定。该服务会通过比较熟悉与不熟悉的位置来尝试判断登录尝试是否来自恶意行为者或真正的用户。然而，仍然存在用户被阻止登录的概率。一个重要的点是，服务并不一定能保护你免受高度敏感的密码喷洒攻击。这并不是因为服务本身存在问题，而是因为这类攻击可能会变得非常难以发现。

• 假设攻击者有一份包含九个密码的列表，并且他们利用广泛分布的机器人网络在几周的时间内攻击一个自定义域中的成千上万个用户账户。在这种情况下，有几个事实需要注意：

  每个用户账户的登录尝试次数不会超过默认阈值。

  通过使用多个广泛分布的主机系统来执行攻击，很难发现一个登录尝试是有效的还是恶意的。然而，微软也会考虑登录尝试是否来自已知的恶意 IP 地址或不熟悉的位置。

所以，在这种情况下，该服务可能不会阻止攻击者。当然，列表中的九个密码需要足够复杂才能被接受。然而，攻击者猜测你的密码仍然有成功的概率。

现在您知道了密码不足以保护您的账户，接下来我们进一步了解 MFA 如何为您的账户增加一层额外的安全防护。

了解多因素认证（MFA）

很少有技术功能能比使用 MFA 更好地保护您的账户。通过 MFA，知道用户名和密码是不够的；您还需要通过其他认证因素来证明您的身份。通过 MFA，通常需要能够通过以下方式登录：

• 您的身份信息，例如您的用户账户名或生物识别属性

• 您知道的东西，例如密码

• 您拥有的东西，例如额外的认证因素（智能卡、智能手机应用或安全密钥）。

鉴于 MFA 挑战只有在登录尝试成功后才会触发，它仍然依赖于不容易猜测的密码。换句话说：如果触发了 MFA 挑战，相应的用户名/密码组合已经成功验证。

图 3.2 - 在用户凭证成功验证后，触发 MFA 挑战

如今，Azure AD 提供了多种使用 MFA 的选项：

• 来自 Microsoft Authenticator 智能手机应用的推送消息

• 来自 Microsoft Authenticator 智能手机应用的 一次性密码 (OTP)

• 通过短信发送到您移动设备的 OTP 代码

• 致认证电话的电话

• 一个安全密钥或令牌

如果您正确设置了 MFA，您可以通过这些选项的组合应对所有情况。如果您无法访问移动数据或 Wi-Fi，您可以使用短信中的 OTP 代码或智能手机应用中的 OTP。如果您把智能手机忘在家里，您可以接到办公室电话（或者您在配置过程中定义的其他认证电话）。

重要提示

需要注意的是，由于显而易见的原因，您不应将手机号码作为身份验证电话。如果您丢失了手机或将手机忘在家里，您将没有太多可选项。

在第二章《治理与安全》中，您学习了职责分离和最小权限原则。帐户只获得完成任务所需的访问权限。然而，重要的是要防止意外被锁定在 Azure AD 环境之外。因此，仍然需要具有更高权限的帐户，如订阅所有者或全局管理员访问权限。这就是为什么您需要创建至少两个管理员紧急访问帐户的原因。部分这些紧急访问或备用解锁帐户也需要通过 MFA 进行保护。现在，单一智能手机似乎并不是这些帐户的好选择，因为根据墨菲定律，事情总会出错；当您需要它们时，智能手机的拥有者总是度假、病倒或因为其他原因无法使用。值得知道的是，您可以将最多五个身份验证因素连接到一个帐户。例如，您可以将三个安全密钥、一个智能手机应用和一个电话号码与一个帐户关联，以确保始终有至少一种方法可以用来完成 MFA 挑战。

在 Azure AD 中启用 MFA

从管理员的角度来看，在 Azure AD 中启用 MFA 非常简单：

1. 在 Azure 门户中，导航到Azure Active Directory，并选择用户导航窗格。在右上角，导航到•••更多，然后选择多重身份验证，如下图所示：

   图 3.3 - 在 Azure 门户中启用 MFA

   您将被重定向到 windowsazure.com 域的复古风格门户，在那里您可以启用或禁用单个用户的 MFA，或者通过选择多个帐户或使用 CSV 文件批量更新它们，方法是在用户选项卡中进行操作。

2. 在启用用户帐户的 MFA 之前，首先从用户选项卡切换到服务设置选项卡，以配置一些适合您环境的自定义设置，如下截图所示：

   图 3.4 - MFA - 服务设置

   第一个选项是允许或不允许用户为不支持 MFA 的传统非浏览器应用程序创建应用程序密码。Outlook 曾经是这样的应用程序；然而，现如今，大多数应用程序应该能够通过 MFA 进行身份验证。

   您还可以定义可信 IP 地址，从而跳过 MFA。例如，如果您的用户从公司办公室进行身份验证，并且您已经在此处定义了外部 IP 范围，则可以定义只有当某人从公司大楼外部进行身份验证时，才会触发 MFA 挑战。您还可以启用或禁用单一验证选项，如果它们不适合贵公司的需求。最后一个设置是允许用户记住他们（但不是您作为公司！）信任的设备上的 MFA。如果启用此选项，则在特定设备上，用户在给定的时间段（1 到 60 天之间）内不会再次被提示进行 MFA 挑战。

3. 现在，回到在用户选项卡上启用用户帐户 MFA。当您在选择一个或多个用户帐户后，点击右侧的启用链接时，系统会提示您阅读在线部署指南，然后点击启用多因素身份验证。从管理员的角度来看，这就是所有操作。很简单吧？确实是。

图 3.5 - 为一个或多个用户帐户启用 MFA

启用 MFA 的用户在下次登录尝试后必须配置所有个性化设置。帐户的电话号码将从已经存储在 Azure AD 中的信息中获取。然而，用户可以在下次登录时出现的向导中更新这些号码。

从用户的角度来看启用 MFA

在为 John 强制启用 MFA 后，他下一次成功登录时将会弹出一个新窗口，告诉他组织需要更多信息来保护他的帐户，具体如以下截图所示：

图 3.6 - 启用 MFA 后第一次登录时的窗口

现在，John 只有两个选项：使用不同帐户登录或点击下一步继续执行 MFA 激活过程。也就是说，在激活 MFA 之前，您应该提前通知您的用户，让他们知道将会发生什么，并减少支持票的数量！

让我们看看如果 John 决定完成此过程会发生什么：

John 决定继续并点击下一步按钮。在接下来的屏幕上，他可以决定哪种方式将成为他的主要身份验证选项。John 的办公室电话号码已经从他在 Azure AD 用户帐户中存储的信息中自动填充，且无法更改。然而，身份验证电话号码可以单独配置。

图 3.7 - 办公电话不能单独更改，而是从 Azure AD 用户帐户中存储的值填充

如果 John 决定使用认证电话作为他的主要 MFA 选项，他必须配置号码，然后选择是否希望接收包含 OTP 的电话或短信：

图 3.8 - 认证电话 - 单独配置号码并选择联系方式

第三个选项是让 John 使用 Microsoft Authenticator 应用，该应用可以在所有主要智能手机操作系统的应用商店中找到。在这里，他有两个选择：要么通过推送通知接收信息，要么使用来自应用的验证码，验证码是每 30 秒更换一次的 OTP（一次性密码）。

图 3.9 - 移动应用 - 选择主要的 MFA 验证选项

John 决定使用移动应用，因此必须点击 设置 按钮。他已经在智能手机上安装了 Microsoft Authenticator 应用，因此现在可以轻松继续。一个新窗口会打开，显示给 John 一个 快速响应（QR） 代码，用移动应用扫描，如下图所示：

图 3.10 - 移动应用配置窗口

在他的应用中，John 点击 + 符号并选择添加新的 工作或学校帐户 选项。在智能手机应用中打开的二维码扫描器中，John 扫描屏幕上的二维码，帐户将立即添加到应用的帐户列表中，如下图所示：

图 3.11 - John's 账户已添加到他智能手机应用的账户列表中

在电脑上，John 点击 下一步，这样应用和后台服务会同步。配置移动应用 窗口将再次消失，John 然后可以点击 下一步 按钮。系统会触发推送通知到智能手机应用，随后可以批准或拒绝，如下图所示：

图 3.12 - Microsoft Authenticator 应用中的推送通知

接下来，John 被要求输入他的认证电话号码，以便 Microsoft 确保即使 John 无法访问移动应用，他也能进行身份验证登录。

步骤 4会向 John 展示他需要使用的应用密码，而不是他自己的用户账户密码。在当前不支持基于电话的 MFA 的应用程序中，该密码只显示一次，因此用户需要复制并保存它，以便在需要时使用。如果应用密码没有安全存储，用户可以稍后创建新的应用密码，但同样，密码只在创建时显示一次。之后，MFA 配置完成，John 将被注销。再次登录时，John 必须接受 MFA 挑战。

MFA 结合强密码可以保护账户免受 95%以上的攻击，而且考虑到 Azure MFA 在默认配置下可以免费使用，完全没有理由不启用它。

现在你已经了解了如何从管理员和用户的角度配置 MFA，让我们更进一步，了解如何根据公司的业务需求使用条件访问来微调 MFA 过程。

使用条件访问

MFA，我们在上一节中讨论的功能，是更好地保护云身份的完美选择。但它仍然是一个开关式的决策。你要么启用 MFA 用户账户，要么不启用。难道不是很棒，能够动态地响应身份验证尝试，然后决定是否需要 MFA 挑战吗？有了条件访问，我们可以定义认证条件，从而在认证过程中要求更多或更少的挑战。

条件访问为客户提供了多种选择，可以在策略中包括或排除。例如，你可以强制指定目录角色使用 MFA，比如 Azure AD 全局管理员，并且要求登录必须在公司拥有的设备上进行。或者，你可以将“正常”的 Office 365 员工从 MFA 挑战中排除，但仅当他们在公司办公室工作时。只要其中一个人试图从火车站、移动设备、家庭办公室等地方登录，就会触发 MFA 挑战。你看，选择非常多，我们将在这一节中详细介绍。

图 3.13 - Azure AD 中的条件访问

你会在 Azure 门户中的Azure Active Directory > 条件访问下找到所有与条件访问相关的设置：

图 3.14 - 条件访问概览页面

现在出现的主要部分是策略部分。条件访问策略根据多个条件定义并强制执行身份验证的复杂性。策略可以依赖于身份验证请求的来源位置、用户和登录风险、设备、应用程序，或这些因素的组合。你可以使用条件访问策略来决定何时以及为谁允许或阻止访问你的云环境。因此，通过使用条件访问策略，你可以确保在需要时施加适当的安全措施，以保持环境安全，并避免在不需要时对用户进行不必要的挑战。

在我们更深入地了解如何在条件访问策略中定义所有这些条件之前，让我们先来看看可以在这些策略中使用的命名位置。

命名位置

有一个管理区域，用于定义可以在条件访问策略中使用的自定义设置。首先要提到的是命名位置。对于命名位置，有两个不同的选项可以选择。第一个选项是配置 MFA 受信任的 IP 地址，这将把你重定向到你从前一部分已经知道的传统门户中的服务设置。你可以使用这个选项定义应始终排除在 MFA 挑战之外的 IP 地址范围。

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig._3.15.jpg)

图 3.15 - 条件访问 - 命名位置

第二个选项是+ 新位置，你可以使用它来定义 IP 范围，甚至是国家和地理区域，以便在自定义条件访问策略中使用它们。如果你为某个 IP 范围选择标记为受信任位置，那么当来自该位置的身份验证请求时，用户的登录风险将降低。

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig._3.16.jpg)

图 3.16 - 创建一个受信任的命名位置

登录风险对于 Azure AD 身份保护很重要，这是我们在介绍 Azure AD 身份保护部分中讨论的功能。

自定义控制

使用自定义控制，你可以在身份验证过程中将用户重定向到外部兼容服务，以满足 Azure AD 之外的进一步身份验证要求。用户的浏览器窗口将被重定向到一个第三方服务，在那里用户需要执行任何进一步的身份验证要求，才能获得访问云资源的权限。自定义控制依赖于第三方应用程序。例如，你可以将第三方 MFA 提供商集成到身份验证工作流中，而不是依赖 Azure AD 的 MFA 服务。

使用条款

你可以定义用户在访问某些云应用程序之前需要接受的自定义使用条款。例如，你可以允许用户使用自己的设备访问你的环境，但前提是他们接受你的使用条款。

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig._3.17.jpg)

图 3.17 - 使用条款

要配置自定义的使用条款，你需要为每种语言上传一个 PDF 文件。在保存后，使用条款将在创建新条件访问策略时显示在授权控制列表中。

条件访问策略

如前所述，条件访问策略帮助你始终为每个身份验证情况应用适当的安全性，而无需在不需要时不必要地阻止或挑战用户。因此，可以按原样查看它们。

条件访问策略由分配和访问控制组成。分配定义了谁将受此条件访问策略的影响，以及在哪种情况下。访问控制定义了是否阻止访问或允许访问，如果允许访问，则定义哪些条件。

分配

在分配部分，你可以选择在条件访问策略中包含或排除的用户和组、云应用或用户操作以及条件，如下图所示：

图 3.18 - 用户和组 - 选择哪些用户和组要在条件访问策略中包含或排除

你可以选择在条件访问策略中包含或排除 无、所有用户，或定义的用户和组的子集。你还可以选择排除所有来宾和外部用户、目录角色（如全局管理员）或在条件访问策略中定义的用户和组的子集。

重要说明

当选择所有用户并使用此策略阻止访问时，这也会影响所有管理员帐户。也就是说，启用此策略时可能会将自己锁定在外。因此，建议先将策略应用于少数用户，以确保其按预期工作！

你还可以在条件访问策略中包含或排除云应用或用户操作。同样，你可以选择无、所有应用或选择包含的应用，或者定义从策略中豁免的应用。

重要说明

在选择包含在策略中的所有云应用时，这也会影响 Azure 门户。确保不要只先对少数用户启用该策略，以免将自己锁定在外，从而确保它按预期工作！

在用户操作部分，你可以选择此策略是否影响用户的安全信息注册。这意味着在进行 MFA 注册过程时，策略对用户有效。

要包含在分配中的条件包括登录风险、设备平台、位置、客户端应用程序和设备状态。登录风险由 Azure AD 身份保护计算。你可以选择该策略适用的登录风险级别，无风险/低风险/中风险/高风险。可以包含或排除设备平台。你可以选择在策略中包含任何设备平台，或者选择包含或排除以下一个或多个：

• Android

• iOS

• Windows Phone

• Windows

• macOS

你可以选择任何位置，或选择包括或排除所有信任的位置，或者你在之前步骤中已经定义的选定位置。

客户端应用程序可以是浏览器、移动应用程序和桌面客户端，包括现代认证客户端、Exchange ActiveSync 客户端或其他客户端（旧版 Office 客户端或其他邮件协议）。

你可以在策略中包括所有设备状态，或者排除混合 Azure AD 加入的设备或在 Intune 中标记为符合要求的设备。

访问控制

在 访问控制 部分，你可以根据之前所做的选择定义是否阻止或授予访问权限。如果你希望授予访问权限，可以选择无条件授予，也可以要求强制执行以下一个或多个控制：

• 要求多因素认证：当你在策略中定义的条件得到满足时，用户响应 MFA 挑战后，将授予用户访问权限。

• 要求设备标记为符合要求：在 Intune 中，你可以定义设备合规性策略。例如，只有当设备为公司所有并且已经打上补丁时，才能将其标记为符合要求。

• 要求混合 Azure AD 加入的设备：混合 Azure AD 加入的设备由组织拥有。它们同时存在于云端和本地，这意味着它们既加入 Windows Server AD，又加入 Azure AD。

• 要求批准的客户端应用程序：仅当使用其中一个批准的客户端应用程序访问公司信息时，才会授予访问权限。目前，批准的客户端应用程序可以是与 Microsoft 365 相关的 25 多个应用程序之一，包括但不限于 Microsoft Azure 信息保护、Microsoft Excel、Microsoft Edge、Microsoft Intune 管理浏览器、Microsoft Teams 和 Microsoft Outlook。

• 要求应用保护策略：你可以使用 Intune 为 Microsoft Cortana、Microsoft Outlook、Microsoft OneDrive 和 Microsoft Planner 定义应用保护策略。通过此设置，你可以在授予公司信息访问权限之前，强制要求应用保护策略存在，如下截图所示：

图 3.19 - 使用条件访问授予访问权限的条件

现在你已经知道了如何在理论上配置条件访问策略，接下来我们再进一步，尝试为一些行为定义设置。

例如，你可以创建一个策略，阻止所有未混合 Azure AD 连接的设备访问。然而，这个策略不应该影响属于特定管理员组的用户。适合你需求的策略可能包括以下内容：

1. 包括所有用户，排除特定的管理员组。

2. 排除混合 Azure AD 连接的设备。

3. 阻止访问。

你可能还希望在身份验证尝试不是来自可信位置，或用户没有使用公司拥有的设备时强制执行多重身份验证（MFA）。该策略将会：

1. 包括所有用户。

2. 包括所有位置，排除所有可信位置。

3. 授予访问权限并要求 MFA。

   重要提示

   最佳实践是不在条件访问策略中包括所有用户，除非有例外。因为这样会有锁定自己无法访问云环境的风险。

你的组织可能会要求用户在办公地点完成 MFA 注册。通过这种方式，组织可以确保即使用户的凭证被泄露，攻击者也需要在你的网络边界内才能配置 MFA。强制执行该策略的条件访问策略可以这样配置：

1. 包括所有用户，排除特权角色或包含管理员帐户的特定用户组。

2. 启用注册安全信息用户操作。

3. 包括定义办公位置的选定位置。

4. 阻止访问。

使用条件访问，你可以细化定义何时以及如何授予或拒绝访问云环境。在本节内容中，我们已经介绍了 Azure AD 身份保护。现在，让我们进入下一部分，你将了解 Azure AD 身份保护到底是什么，以及如何使用它。

引入 Azure AD 身份保护

如前所述，安全方面的一个重要目标是尽可能增加攻击者尝试攻击的成本。换句话说，重要的是提高安全门槛，并采用几种互补的技术，为你的安全防护增加额外的价值。另一方面，你还需要确保不会阻止合法用户的身份验证，以免对用户的登录体验产生负面影响。微软已经保护云端身份超过 10 年，借助 Azure AD 身份保护系统，他们可以帮助你使用其保护机制来保护身份。

偷窃用户帐户的凭证，即使它们没有很高的权限，仍然是获取公司资源的好方法。多年来，攻击者已经学会了利用第三方泄露或高度复杂的钓鱼攻击来获取公司凭证。即使攻击者获得了低权限的用户帐户，他们也能相对容易地通过横向移动提升权限级别或访问重要的公司资源。

因此，我们需要做的是以下几步：

• 保护所有级别特权的身份

• 防止被泄露的身份访问企业资源

现在，第二步更加困难，因为您首先需要弄清楚一个身份是否已经被泄露。这时，Azure AD 身份保护就发挥作用了。

Azure AD 身份保护概览

Azure AD 在确定用户帐户身份验证中的异常和可疑行为时，利用的是自适应机器学习算法和启发式方法。通过这些数据，Azure AD 身份保护可以生成报告和警报，帮助客户评估最近的登录情况。此外，Azure AD 身份保护还能计算用户和登录的风险等级，并可用于基于风险的条件访问策略。例如，您可以决定在登录尝试的风险等级被计算为中等或更高时强制使用 MFA，或者基于风险计算来阻止登录尝试。

图 3.20 - 一个登录尝试被 Azure AD 身份保护阻止

在前面的截图中，您可以看到一个登录尝试被阻止，因为无法验证用户的身份。原因是 John 在此可疑的登录活动被检测到之前没有配置 MFA。当然，现在试图登录并被阻止的人员无法在此阶段配置 MFA，因为那样会让攻击者根据他们的需求来配置该服务。

图 3.21 - Azure AD 身份保护概览仪表盘

Azure AD 使用多种类型的风险检测，实时检测（5-10 分钟）和离线检测（2-4 小时）。一旦检测到与帐户登录相关的风险，该检测会被添加到一个逻辑概念中，称为 高风险登录。高风险登录表示一个可能是攻击者进行的登录尝试，而非合法帐户所有者的操作。基于这些检测，会计算出登录由恶意行为者执行的概率，并反映在 登录风险等级 中。您可以使用登录风险等级（低，中，高）来定义 登录风险策略。登录风险策略是根据指定的登录风险等级自动响应的策略，用来阻止访问您的资源或要求用户在获得访问权限之前通过 MFA 挑战。

除了登录风险，Azure AD 还会检测用户账户是否被泄露的可能性。这种行为被称为用户风险检测。所有已经检测到并且尚未解决的风险检测都被称为活动风险检测。与用户相关的所有活动风险检测定义了该用户的风险。根据用户风险，Azure AD 会计算用户账户被泄露的概率（低、中、高）。这个概率被称为用户风险等级。例如，如果检测到一个高风险的登录行为，但多重身份验证（MFA）挑战通过，则该用户没有任何活动风险检测。因此，在这种情况下，用户风险等级将保持在低水平。你可以定义一个用户风险策略，作为对特定用户风险等级的自动响应。通过此策略，你可以选择阻止访问企业资源，或强制要求用户更改密码，以恢复用户的清洁状态。

风险检测

在 Azure AD 中，目前有六种不同类型的风险检测：

1. 凭证泄露的用户： 凭证泄露是由于网络犯罪分子大规模窃取凭证并公开发布，特别是在暗网上。微软积极监控这些渠道，并将泄露的用户名和密码配对与现有用户进行比较，以识别那些有凭证泄露的账户。

2. 来自匿名 IP 地址的登录： 匿名 IP 地址是那些希望隐藏设备真实 IP 地址的用户所使用的。使用这些 IP 地址可能有多种原因，其中一些可能具有恶意性质。微软会检查来自先前被识别为匿名 IP 地址的登录请求。

3. 不可能的旅行到非典型位置 是指从地理上相距遥远的地点进行的登录。至少一个位置需要是根据用户的登录行为判定的非典型位置。例如，用户第一次去美国出差并从那里登录。除了这一点，底层的机器学习算法还会考虑登录之间的时间，以及用户从一个位置移动到另一个位置所需的时间。微软尽量忽略明显的误报，比如虚拟专用网络（VPN） 连接，或者在同一组织中的其他用户账户所知的熟悉位置。此类风险检测需要 14 天的用户行为分析，才能计算出用户账户的风险。

4. 来自感染设备的登录： 这种风险检测方法依赖于微软追踪已知与僵尸网络服务器通信的 IP 地址。微软会将所有连接到服务的 IP 地址与这些已知的恶意 IP 地址进行匹配，以判断是否存在来自感染设备的登录。此类风险检测还会针对简单的攻击方法，如密码喷射攻击。

5. 来自具有可疑活动的 IP 地址的登录： 在这种检测方法中，微软会检查 IP 地址是否存在可疑活动。主要的指示器是 IP 地址在相对短的时间内发生大量失败的登录尝试。这可能表明一个不良行为者正在尝试通过暴力破解或密码喷洒等简单攻击方法猜测密码。

6. 来自不熟悉位置的登录： 这种风险检测方法涉及微软维护一个用户常用 IP 地址的历史记录。系统会检测请求是否来自一个以前未曾使用过的 IP 地址。系统至少需要 30 天的时间来创建一个可用的熟悉与不熟悉位置的历史记录。

创建登录风险或用户风险策略

策略创建是 Azure AD 条件访问中最简单的部分。要创建登录风险策略，您只需在 Azure 门户中导航至Azure AD 身份保护 -> 登录风险策略。在这里，您定义条件（登录风险级别 - 低及以上、中及以上或高），访问控制（阻止访问或使用 MFA 挑战用户），并选择启用策略的用户或组。就这么简单。

图 3.22 - 创建登录风险策略

对于新的用户风险策略，您可以导航至Azure AD 身份保护 -> 用户风险策略并定义相应的参数。与登录风险策略的不同之处在于，您可以选择阻止访问或强制风险用户更改密码。

图 3.23 - 创建用户风险策略

现在您已经了解了 Azure AD 身份保护的工作原理以及如何使用计算出的用户和登录风险级别来保护您的帐户。接下来，我们将继续关注特权用户帐户。

理解 RBAC

在 第二章 治理与安全性 中，我们提到了安全原则，如职务分离和最小特权原则。通过 RBAC，我们拥有了在 Azure AD 中实施这些原则的技术特性。RBAC 是管理所有 Azure 资源访问的方式，也包括 Azure AD 和 Office 365 的访问管理。

如前所述，Azure 提供了几个作用域级别，可以用于授予帐户的访问权限。此外，还有若干角色，如所有者、Azure Sentinel 贡献者或阅读者，如下图所示：

图 3.24 - Microsoft Azure 中的 RBAC 角色分配

创建角色分配需要三个不同的实体：

• 安全主体，可以是用户、组或服务主体中的任意一个。

• 一个角色，描述了一组管理权限。例如，贡献者角色包含所有操作，除了与授权相关的权限。因此，贡献者可以管理给定范围内的所有方面，而无需授予访问资源的权限。

• 一个设置访问权限的范围，从管理组级别到单个资源。

如果这三者结合起来，这就是我们所说的 RBAC 角色分配。

重要提示

你需要被授予 Microsoft.Authorization/roleAssignments/write 和 Microsoft.Authorization/roleAssignments/delete 权限，才能创建或删除角色分配。默认情况下，这些权限会授予 RBAC 角色“用户访问管理员”和“所有者”。

你可以在 Azure 的所有管理范围内编辑角色分配。需要注意的是，角色分配是从上到下继承的。这意味着，如果你在资源组级别配置角色分配，则该访问权限也适用于该资源组中的所有资源；如果你在管理组级别配置角色分配，则它会被继承到该范围内的所有订阅、资源组和资源。

在 Azure 门户中，有一个访问控制（IAM）面板，用于管理 RBAC 的各个方面。你可以检查特定帐户的访问权限，了解显式和继承的角色以及拒绝分配，并查看给定范围内存在的内置或自定义角色。

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig._3.25.jpg)

图 3.25 - Azure 门户中的 RBAC 管理面板

要创建新的角色分配，你需要点击+ 添加，然后选择添加角色分配。

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig._3.26.jpg)

图 3.26 - 添加角色分配

然后选择你想要授予访问权限的角色和安全主体，并保存你的选择。完成。

实施 RBAC 是相当直接的，但在规划你环境中的访问权限时可能会变得更加具有挑战性。这就是为什么在定义治理概念时你应该提前规划 RBAC 角色。

重要提示

在创建治理概念时，定义你在环境中需要的 RBAC 角色。这样，你将对需要哪些访问权限（角色）以及需要授予谁（哪个安全主体）访问权限有一个清晰的了解。这样，稍后创建角色分配时会更容易。

在接下来的部分中，我们将展示如何创建自定义的 RBAC 角色，以便你可以根据需要更细粒度地使用角色。

创建自定义 RBAC 角色

当内置角色不能完全满足贵公司在云环境访问权限方面的需求时，便需要使用自定义 RBAC 角色。如前所述，角色基本上是一组管理权限，然后应用到用户或组的角色分配中。自定义 Azure AD RBAC 角色和自定义 Azure 资源 RBAC 角色之间存在差异。如果您想创建一个自定义的 Azure AD RBAC 角色，您需要遵循以下步骤：

1. 进入Azure Active Directory -> 角色和管理员，然后点击 Azure 门户中的+新建自定义角色按钮，如以下截图所示：

   图 3.27 - 创建新的自定义角色

2. 输入名称，并可选择性地为您的自定义角色输入描述。您可以选择从头开始，或选择从自定义角色克隆来继续创建您的自定义角色。在以下示例中，我们选择了从头开始：

   图 3.28 - 定义基本信息

3. 在权限选项卡上，选择您以后希望授予身份的所有权限。

4. 在查看 + 创建选项卡上，您可以最终确认您的设置，点击创建按钮后，您的自定义 Azure AD RBAC 角色就会创建，如以下截图所示：

图 3.29 - 审查并创建您的自定义 Azure AD RBAC 角色

Azure 资源的自定义 RBAC 角色不能通过 Azure 门户进行创建。您需要使用 PowerShell、Azure命令行界面(CLI)或 Azure表述性状态传输(REST)API。在本示例中，我们将通过 PowerShell 创建一个自定义 RBAC 角色。

要创建自定义的 RBAC 角色，您需要定义哪些资源提供程序的资源操作必须被允许，以满足您的目标。因此，您应该首先了解有哪些资源提供程序操作。您可以通过使用Get-AzProviderOperation cmdlet 来实现，如以下代码块所示：

Get-AzProviderOperation <operation> | FT OperationName, Operation, Description -autosize

例如，如果您想查找Microsoft.Compute/VirtualMachines/*资源提供程序的所有资源操作，命令和结果可能如下所示：

图 3.30 - Azure 虚拟机的资源提供程序操作

前述截图中列出的资源提供程序操作都是与虚拟机(VM)相关的操作，您可以将这些操作的访问权限授予用户、组或服务主体。如果您想了解某个特定 RBAC 角色绑定了哪些资源提供程序操作，您可以使用以下命令来查询：

(Get-AzRoleDefinition <role name>).actions

例如，如果您想了解虚拟机贡献者 RBAC 角色允许哪些操作，命令如下：

(Get-AzRoleDefinition "Virtual Machine Contributor").actions

当你知道存在哪些资源提供者操作时，你可以开始创建自定义 RBAC 角色。你可以从头开始创建新角色，或者使用现有角色作为模板，根据你的需要进行修改。你将会在本书的 GitHub 仓库中找到有关为 Azure 资源创建自定义 RBAC 角色的示例。

现在你已经了解了 RBAC 及如何利用它，我们将为你介绍另一项服务——Azure AD 特权身份管理（Azure AD PIM），这项服务专注于保护特权用户账户。让我们继续吧！

使用 Azure AD PIM 保护管理员账户

在 第二章**，《治理与安全》中，我们讨论了我们经常看到的客户环境，其中管理员拥有大量他们不一定需要的特权。我们还讨论了职责分离（SoD）以及任何人都不应该拥有超过完成特定工作所需的权限。现在，如果你能将这一权限集缩减到某一特定时间点或时间范围呢？或者，如果你需要批准流程来授予特权访问权限呢？也许你想监控特权角色的使用情况，或者想决定某个人是否仍然需要特权访问权限？

Azure AD PIM 是一项服务，提供多个功能，帮助你进一步保护特权账户，其中一些功能包括：

• 即时和时间限制的特权访问

• 批准以激活特权角色

• 访问审查以确保角色仍然需要

• 强制实施多重身份验证（MFA）以激活角色

通过 Azure AD PIM，你可以——但不必——无限期地授予特权用户访问权限；你只需要将他们设置为“有资格”申请访问权限。因此，用户只有在真正需要时才会被授予访问权限。访问权限可以在用户请求访问后自动批准，或者通过手动批准。一个好的地方是，你可以通过 Azure AD PIM 管理 Azure AD 和 Azure 资源角色。

提示

在开始使用 PIM 之前，确保你在组织中已经实施了最小特权原则。

启用 PIM

在使用 PIM 之前，你必须为你的目录启用此服务。你可以通过以目录的全局管理员身份登录 Azure 门户，然后导航到 Azure AD 特权身份管理 来执行此操作。进入后，你将看到同意 PIM选项，如下图所示：

图 3.31 - 同意 PIM

然后点击验证我的身份以通过 MFA 验证身份。如果你还没有这么做，你将被要求为你的账户启用 MFA，如本章的了解多因素认证（MFA）部分所述。身份验证完成后，你可以点击同意按钮，并点击是以确认对话框，如下图所示：

图 3.32 - 确认 PIM 同意

现在你已经为目录启用了 PIM，你需要注册 PIM 来管理你的 Azure AD 角色。你可以通过导航到 Azure AD PIM 仪表板的Azure AD 角色部分并点击注册来完成注册。一旦注册完成，Azure AD 选项将被启用。

管理 Azure AD 角色在 PIM 中

在Azure AD 角色视图中，你可以管理所有 Azure AD 角色的 PIM 行为，还可以访问与 Azure AD 角色相关的任务，如访问审查、批准或你自己的角色和访问请求，如下图所示：

图 3.33 - 在 PIM 中管理 Azure AD 角色

管理部分提供了所有 Azure AD PIM 配置选项，用于管理你的 Azure AD 目录。角色部分让你可以查看所有 Azure AD 角色，并使你能够将成员添加到特定角色中。在成员部分，你可以看到所有符合条件或是永久成员的特权角色账户概览。这是一个快速查看你目录中所有具有提升权限用户的视图。警报部分展示了需要审查的问题。例如，你会看到没有使用其特权角色的管理员（因此可以取消分配）。你还可以创建定期的访问审查，以确定特定账户是否仍然需要成为角色成员。在相应的部分，你可以找到一个配置向导来创建这些定期审查。相应部分中的向导会引导你完成一个过程，将已有永久角色分配的用户转为符合条件的用户。最后，在设置中，你可以为 Azure AD 角色、警报和访问审查配置全局设置。

提示

你可以要求对角色激活进行批准。此要求是角色的设置，而不是用户账户的设置。也就是说，当你配置此要求时，它适用于所有有资格申请访问此特定角色的用户。

一旦一个账户被标记为合格，它的拥有者需要在执行任务之前请求访问。我们来举个例子：John 在帮助台团队工作，这个团队负责管理用户账户。因此，我们将 John 的账户标记为 用户管理员 角色。当 John 登录到 Azure 门户并想要管理 Azure AD 中的用户设置时，他将只能看到普通用户账户能够看到的内容；他无法管理任何账户。于是，John 导航到 Azure AD PIM 仪表板，看到自己需要先激活角色。

图 3.34 - 用户可选角色

John 可以在之前配置的 1 小时内激活角色。除此之外，我们还强制要求输入一个理由，之后可以在审计历史中查看：

图 3.35 - 激活角色

John 还可以设置自定义激活开始时间。例如，当 John 知道他当天稍后需要访问时，他可以手动设置未来的激活时间。点击 激活 后，会提交一个激活请求，并在激活完成后进行验证。然后，John 登出并重新登录后，他将拥有用户管理员角色，持续 1 小时。

图 3.36 - 成功激活角色

所以，用户的流程非常简单。请求访问；登出并重新登录；然后开始工作。当然，每个激活请求都会被记录，同时每个用户在拥有提升权限时进行的配置更改也会被记录。如前所述，监控至关重要，因此没有办法绕过它。

使用 PIM 管理 Azure 资源

你不仅可以使用 PIM 来管理 Azure AD 角色，还可以基于 RBAC 管理 Azure 资源。你首先需要将 Azure 订阅加入 PIM，才能使用它来管理基于资源的访问权限。为此，你需要在 Azure AD PIM 仪表板中导航到 Azure 资源，然后选择 发现资源。接着，你过滤出未管理的资源，并选择 管理资源，如下面的截图所示：

图 3.37 - 将 Azure 订阅加入 PIM

你也可以选择一个管理组来加入 PIM。PIM 在加入后会自动管理所选范围内所有子资源的角色分配。配置选项与 Azure AD 管理的 PIM 相似。唯一的区别是，你需要输入角色分配的开始和结束日期。结束日期后，用户将无法再请求访问。最大时长为 1 年。

举个例子。在作为“Mastering Azure Security”项目的项目负责人时，John 需要管理为此项目创建的特定资源组中的所有资源。然而，他不应该能够将其他用户或组的访问权限授予该资源组，因此，访问“贡献者”角色将是最合适的选择。

图 3.38 - John 通过 PIM 成为贡献者角色成员

如果 John 登录到 Azure 门户，他将看不到任何资源或资源组，因为他没有对 Azure 资源的永久访问权限。然后，他再次导航到 Azure AD PIM 仪表板，选择 Azure 资源，激活他的角色。注销后重新登录，John 就能够管理他在MasteringAzSec资源组中的资源。

提示

PIM 总是将角色激活 1 小时或更长时间，即使访问仅需要 10 分钟。因此，用户可以找到一个选项，在完成任务后通过导航到我的角色，然后在Azure AD 角色和Azure 资源部分的活动角色中停用角色。

现在，您已经学习了如何通过使用 Azure AD PIM 进一步减少特权帐户的攻击面。

混合身份验证和单一登录（SSO）

组织在从本地 IT 基础设施转向基于云的软件即服务（SaaS）应用程序（如 Microsoft Office 365）时，已经走了很长一段路。用户通常不想跟踪多个帐户，因为他们已经拥有基于 Windows Server AD 的公司帐户，并且通常希望也能将该帐户用于基于云的身份验证。这时，Azure AD Connect 就发挥了作用。

Azure AD Connect 是一个目录复制服务，帮助您将现有的本地 Windows Server AD 用户帐户与 Azure AD 同步。这是一个必要步骤，因为您只能为 Azure AD 中的云身份授予访问权限和许可证，而不能为本地帐户授予。

使用 Azure AD Connect，您可以提供多种选项来为用户提供单一登录体验。在下图中，您可以看到一个决策树，帮助您决定哪种方式最适合您的组织：

图 3.39 - Azure AD Connect 身份验证决策树

密码哈希同步 + 无缝单一登录（SSO）是最简单的方法。通过此方法，本地的密码哈希将被复制到相应的云身份中，因此用户可以在所有登录环境中使用相同的用户名和密码。无缝 SSO 可以消除用户登录时不必要的提示。

如果你有更强的要求，例如在登录时应强制执行的用户级 AD 安全策略，你可以选择 Pass-through Auth + Seamless SSO。在此方案中，你需要在一个或多个本地服务器上安装软件代理。这些服务器可以通过建立一个安全隧道，直接验证用户凭证，进而实现基于云的登录验证。

与 Active Directory 联邦服务（AD FS） 或其他联邦服务的联邦身份验证是最复杂的身份验证方法。它应在 Azure AD 原生不支持登录功能的场景中使用。这些功能包括以下内容：

• 使用智能卡或证书进行登录。

• 使用本地 MFA 服务器进行登录。

• 使用第三方身份验证解决方案进行登录。

• 多站点本地身份验证解决方案。

  提示

  我们建议始终在 Azure AD Connect 中启用密码哈希同步。通过这样做，当你的本地身份验证平台无法正常工作时，你将有一个备用方案，并且可以使用 Azure AD Identity Protection 获取泄露凭证报告。此外，当启用密码哈希同步时，你可以启用 自助密码重置（SSPR）。

使用 SSPR，可以有效减少用户的非工作时间和帮助台团队的支持工作量。SSPR 为用户提供了一个有效的手段，如果他们忘记密码，可以解锁他们的公司账户。为了使用 SSPR，用户必须提供一种二次身份验证方法。当他们失去对公司密码的访问权限时，用户需要验证他们之前注册的备用身份验证方法以证明身份。之后，用户可以输入新密码。如果这是一个混合用户账户，意味着该账户通过 Azure AD Connect 进行了复制，则新密码将被写回到本地 Active Directory。在这种情况下，你需要在 Azure AD Connect 中启用的功能是 密码回写。

当前，SSPR 和 MFA 的联合注册提供了一个新的用户安全注册体验，正在预览阶段。

图 3.40 - SSPR 和 MFA 的联合注册

今天，你可以通过导航至 Azure Active Directory -> 用户设置 -> 管理用户功能预览设置 来为你的 Azure AD 租户启用此功能。你可以为所有用户或选择的组启用预览功能，如以下截图所示：

图 3.41 - 在租户中启用 SSPR 和 MFA 的联合注册

之后，适用此设置的用户可以在 myprofile.microsoft.com/ 上使用新的体验。

图 3.42 - 新的结合体验

将本地身份集成到 Azure AD 是提升混合组织登录体验的绝佳方式，你刚刚了解了在开始混合之旅前需要注意的事项。在探索密码和密码短语部分，你了解到密码不足以保护帐户。所以，让我们继续讨论 Azure AD 中的无密码登录。

了解无密码身份验证

在密码已不足以保护身份的世界中，我们需要另一种更安全的方式来进一步保护身份。密码可能被猜测或通过钓鱼攻击获取，即使没有物理访问用户设备或存储的权限。而通过无密码身份验证，Azure AD 提供了两种不同的方法来登录到基于云的用户帐户，无需密码。

你可以使用Microsoft Authenticator 应用，这款应用你在了解 MFA部分已经熟悉了。使用这种方法时，你只需在 Authenticator 应用中点击一个数字以批准登录，如下图所示：

图 3.43 - 基于手机的无密码身份验证

用户只需将该应用注册为 MFA 选项，然后在智能手机应用中从下拉菜单中选择启用手机登录。按照应用中的说明操作后，用户可以无需输入密码登录应用。

第二种选择是使用FIDO2 安全密钥对 Azure AD 进行登录。基于 FIDO2 的无密码身份验证目前处于预览阶段，仅在 Windows 10 和 Microsoft Edge 浏览器中受支持。

图 3.44 - FIDO2 安全密钥

使用这种方法时，用户需要在身份验证过程中拥有物理访问安全密钥的权限。用户需要启用增强安全性注册预览功能，这样才能访问myprofile.microsoft.com/门户，如混合身份验证和单点登录部分所述。要使用安全密钥，必须将其添加到用户的安全信息中，如下图所示：

图 3.45 - 将安全密钥与用户的个人资料关联

按照说明操作后，用户将能够在不输入密码的情况下对 Azure AD 进行身份验证。

全局设置

在你能为每个用户启用无密码身份验证之前，必须首先为 Azure AD 租户启用此功能。相关设置可以在 Azure AD 门户中的Azure AD -> 安全性 -> 身份验证方法下找到，如下图所示：

图 3.46 - 为 Azure AD 租户启用无密码认证

你现在已经学习了如何为用户启用无密码认证。在下一节中，你将学习关于 Azure AD 中安全功能的许可。

许可考虑

Azure AD 许可在安全功能方面可能会变得有些复杂。因此，我们决定比较不同的许可，并解释每个功能需要哪个许可。Azure AD 始终按每用户许可模式授权，因此你需要为每个用户提供相应的许可。对于本章讨论的所有安全功能，你将需要 Azure AD Premium P1 或 Azure AD Premium P2 许可。这些许可也是 Microsoft 365 和企业流动性与安全性（EMS）许可包的一部分。

• Microsoft 365 E3 包含 EMS E3，其中包括 Azure AD Premium P1 的功能。

• Microsoft 365 E5 包含 EMS E5，其中包括 Azure AD Premium P2 的功能。

• 对于以下功能，你将需要 Azure AD Premium P2 许可证：

• Azure AD PIM

• Azure AD 身份保护

• 基于风险的条件访问策略

对于以下功能，Azure AD Premium P1 许可证已足够：

• Azure MFA

• 基于组、位置和设备状态的条件访问

• 自助密码重置

摘要

身份是新的边界，因此在云中正确保护用户和管理员账户至关重要。在本章中，你已经了解了为什么密码不足以保护账户，以及如何通过 MFA、Azure AD 身份保护和无密码认证来保护账户。从现在开始，你可以减少特权账户的攻击面，并将 Azure AD 集成到现有环境中。

在下一章中，你将学习如何保护 Azure 上的网络基础设施资源，以及为了实现更好的安全态势你需要哪些平台服务。

问题

1. 在云中，身份是…

   A. 更容易受到攻击

   B. 更少暴露于攻击

   C. 同样容易受到攻击

2. 我们可以通过…控制密码设置

   A. Azure AD 保护

   B. 账户保护

   C. 密码保护

3. 我们可以通过…提高账户安全性

   A. 更复杂的密码

   B. 更频繁的密码更改

   C. 多因素认证（MFA）

   D. 双重身份验证（2FA）

4. 你可以控制需要 MFA 的操作。

   A. 是

   B. 否

   C. 仅针对某些操作

5. 在风险检测中哪个报告不可用？

   A. 泄露凭证的用户

   B. 不可能的旅行

   C. 被感染的用户

   D. 被感染的设备

6. 具有特权身份管理（PIM）角色的用户拥有…

   A. 更多特权

   B. 更少的特权

   C. 激活特权

7. 最安全的身份验证是…

   A. 强密码

   B. MFA

   C. 无密码

第二部分：云基础设施安全

本节将教你如何以安全的方式部署基础设施，以及如何在 Microsoft Azure 中管理机密和证书。你还将学习如何保护云中的网络资源和数据。

本节包含以下章节：

第四章，网络安全

第五章，Azure 密钥保管库

第六章，数据安全

第四章：第四章：Azure 网络安全

在 第一章，《Azure 安全性简介》中，我们简要讨论了 Azure 中的网络安全，但仅讨论了 Microsoft 如何在 Azure 数据中心内处理网络安全。由于网络也属于共享责任模型，在本章中，我们将从用户的角度讨论网络安全，并探讨我们负责的安全处理方式。

本章将涵盖以下主题：

• 理解 Azure 虚拟网络

• 考虑其他虚拟网络的安全性

• 理解 Azure 应用程序网关

• 理解 Azure Front Door

理解 Azure 虚拟网络

从本地环境过渡到云的第一步是 基础设施即服务 (IaaS)。IaaS 的一个关键要素是 虚拟网络 (VNets)。虚拟网络是我们本地网络的虚拟表示，包含 IP 地址范围、子网及所有我们在本地基础设施中找到的其他网络组件。最近，我们也看到许多云网络组件被引入到本地网络中，尤其是 软件定义网络 (SDN) 在 Windows Server 2016 操作系统中的引入。

在我们开始研究虚拟网络安全之前，让我们记住，命名标准应适用于所有 Azure 资源，网络也不例外。随着环境的扩大，这将帮助你更好地控制环境，简化管理，并对安全态势有更多洞察。

我们创建的每个虚拟网络都是 Azure 中完全隔离的网络。我们可以在一个订阅中创建多个虚拟网络，甚至在一个区域内创建多个虚拟网络。即使是在同一个订阅或区域内创建的虚拟网络之间也没有直接通信，除非另行配置。配置虚拟网络时，首先需要配置 IP 地址范围。接下来，我们需要一个具有自己范围的子网。一个虚拟网络可以有多个子网。每个子网必须在虚拟网络的 IP 地址范围内有自己的 IP 地址范围，并且不能与同一虚拟网络中的其他子网重叠。

在定义 IP 地址范围时，我们需要考虑的一点是，范围不能与我们使用的其他虚拟网络重叠。即使最初没有要求在不同虚拟网络之间建立连接，这也可能在未来成为需求。

重要提示

拥有重叠 IP 范围的虚拟网络将无法进行连接。

虚拟网络（VNet）用于通过私有 IP 地址在 Azure 资源之间进行通信。主要用于 Azure 虚拟机（VMs）之间的通信，但其他资源也可以配置为使用私有 IP 地址进行通信。

Azure 虚拟机之间的通信通过网络接口卡（NIC）进行。每个虚拟机可以根据大小分配一个或多个 NIC。较大的虚拟机允许更多的 NIC 关联。每个 NIC 可以分配私有 IP 地址和公共 IP 地址。私有 IP 地址是必需的，公共 IP 地址是可选的。由于 NIC 必须有一个私有 IP 地址，因此它必须与同一虚拟网络（VNet）和子网关联。

作为第一道防线，我们可以使用网络安全组（NSG）来控制 Azure 虚拟机（VM）的流量。NSG 可以用于控制入站和出站流量。在创建 NSG 时会自动创建默认的入站和出站规则，但我们可以根据需求修改（或删除）这些规则并创建其他规则。默认的入站规则如图所示：

图 4.1 – 入站安全规则

默认的入站规则将允许来自虚拟网络（VNet）内的任何流量以及从 Azure 负载均衡器转发的任何流量。所有其他流量将被阻止。

相反，默认的出站规则将允许几乎所有的出站流量。默认规则将允许任何流向 VNet 或互联网的出站流量，如下图所示：

图 4.2 – 出站安全规则

要添加新的入站规则，我们需要定义源、源端口范围、目标、目标端口范围、协议、动作、优先级和名称。可选地，我们可以添加一个描述，帮助我们理解创建此规则的原因。以下图展示了如何创建一个允许通过端口443（HTTPS）的流量规则：

图 4.3 – 添加新的入站安全规则

或者，我们可以使用 Azure PowerShell 创建相同的规则：

1. 首先，我们需要创建一个资源组来部署资源：

   New-AzResourceGroup -Name "Packt-Security" -Location ` "westeurope"
   

2. 接下来，我们需要部署虚拟网络（VNet）：

   New-AzVirtualNetwork -Name "Packt-VNet" -ResourceGroupName ` "Packt-Security" -Location  "westeurope" -AddressPrefix ` 10.11.0.0/16
   

3. 最后，我们部署 NSG 并创建规则：

   New-AzNetworkSecurityGroup -Name "nsg1" -ResourceGroupName ` "Packt-Security" -Location "westeurope"

   $nsg=Get-AzNetworkSecurityGroup -Name 'nsg1' `
   -ResourceGroupName 'Packt-Security'
   $nsg | Add-AzNetworkSecurityRuleConfig -Name 'Allow_HTTPS' `
   -Description 'Allow_HTTPS' -Access Allow -Protocol Tcp `
   -Direction Inbound -Priority 100 -SourceAddressPrefix Internet `
   -SourcePortRange * -DestinationAddressPrefix * `
   -DestinationPortRange 443 | Set-AzNetworkSecurityGroup 
   

要添加新的出站规则，我们需要定义与入站规则相同的选项。以下图展示了如何创建一个拒绝通过端口22的流量规则：

图 4.4 – 添加新的出站安全规则

请注意，优先级在网络安全组（NSG）中起着非常重要的作用。数字越小表示优先级越高，数字越大表示优先级越低。如果我们有两个规则相互冲突，优先级较低的规则将优先执行。例如，如果我们创建了一个优先级为100的允许通过端口443的流量规则，而另一个优先级为400的规则拒绝通过端口443的流量，流量将被允许，因为允许规则的优先级更高。

同样，我们可以使用 Azure PowerShell 来创建规则：

$nsg | Add-AzNetworkSecurityRuleConfig -Name 'Allow_SSH' `
-Description 'Allow_SSH' `
-Access Allow -Protocol Tcp `
-Direction Outbound -Priority 100 `
-SourceAddressPrefix VirtualNetwork  -SourcePortRange * `
-DestinationAddressPrefix * -DestinationPortRange 22 `
| Set-AzNetworkSecurityGroup 

一个 NSG 可以与子网和 NIC 关联。与子网级别关联的 NSG 会将所有规则应用于该子网中所有关联的设备。当 NSG 与 NIC 关联时，规则只会应用于该 NIC。建议将 NSG 与子网关联，而不是与 NIC 关联，以便更简单的管理。当虚拟机数量较少时，管理 NIC 级别的流量比较简单。但当虚拟机数量达到几十、几百甚至几千时，管理 NIC 级别的流量就变得非常困难。将具有相似要求的虚拟机在子网级别关联会更好。

要将 NSG 与子网关联，请按以下步骤操作：

1. 转到 NSG1 下的 子网 部分，选择 关联，如下图所示：

   图 4.5 – NSG 子网面板

2. 接下来，我们选择虚拟网络，如下截图所示：

   图 4.6 – VNet 与 NSG 的关联

3. 最后，我们选择子网并确认：

图 4.7 – 子网与 NSG 的关联

现在，所有添加到该子网中的 Azure 虚拟机将立即应用所有 NSG 规则。

将 NSG 与子网关联的 Azure PowerShell 脚本如下：

$vnet = Get-AzVirtualNetwork -Name 'Packt-VNet' `
-ResourceGroupName 'Packt-Security'
Add-AzVirtualNetworkSubnetConfig -Name FrontEnd `
-AddressPrefix 10.11.0.0/24 -VirtualNetwork $vnet
$subnet = Get-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $vnet -Name FrontEnd
$nsg = Get-AzNetworkSecurityGroup `
-ResourceGroupName 'Packt-Security' -Name 'nsg1'
$subnet.NetworkSecurityGroup = $nsg
Set-AzVirtualNetwork -VirtualNetwork $vnet 

以一个简单的三层应用架构为例。在这里，我们将有可以从外部访问的虚拟机（通过互联网），这些虚拟机应该放置在 DMZ 子网中，并与一个允许此类流量的 NSG 关联。接下来，我们将有一个应用层，它允许内部 VNet 中的流量，但不允许直接通过互联网访问。

应用层将与适当的子网关联，使用子网级别的 NSG 将拒绝互联网流量，但允许来自 DMZ 的任何流量。最后，我们将有一个数据库层，它只允许来自应用层的流量，使用与子网级别关联的 NSG。这样，任何请求都可以到达 DMZ 层。一旦请求被验证，它可以传递到应用层，然后再到达数据库层。DMZ 层与数据库层之间不允许直接通信，并且不允许从互联网直接请求访问应用层或数据库层。

为了更安全，资源可以与应用程序组关联。通过使用 NSG 和应用程序组，我们可以创建具有更多网络过滤选项的附加安全规则。

现在我们将讨论如何将本地网络与 Azure 连接。

将本地网络与 Azure 连接

在大多数情况下，我们已经有某种本地基础设施，并希望将云作为混合模式，将云和本地资源结合起来。在这种情况下，我们需要考虑如何从本地网络访问 Azure 虚拟网络（VNet）。

有三个可用选项：

• 点对站连接（P2S）通常用于管理。它使你能够从单个本地计算机创建到 Azure VNet 的连接。它有一个安全连接，但并不是最可靠的，不应用于生产环境，只能用于执行管理和维护任务。

• 站点到站点连接（S2S） 是一种更稳定的连接，它启用网络到网络的连接。在这种情况下，就是从本地网络到 VNet，在这种方式下，所有本地设备都可以连接到 Azure 资源，反之亦然。使用 S2S 使你能够将本地基础设施扩展到 Azure，使用混合云，并利用本地和云网络所能提供的最佳功能。

• ExpressRoute 是从本地数据中心到 Azure 的直接连接。它不经过互联网，提供更好的连接。与 S2S 连接相比，ExpressRoute 提供更高的可靠性和速度，并具有更低的网络延迟。

接下来，我们将查看如何创建 S2S 连接。

创建 S2S 连接

为了创建 S2S 连接，必须创建多个资源。首先，我们需要创建一个 虚拟网络网关（VNG）。在创建 VNG 的过程中，我们需要定义订阅、VNG 的名称、创建的区域，并且必须选择一个 VNet。

可以选择的 VNet 限制于 VNG 将创建的区域。必须定义一个单独的网关子网，因此我们可以选择现有的子网，或者如果所选 VNet 上不存在该子网，则自动创建。

在同一部分，我们需要定义公共 IP 地址（创建一个新的或选择现有的）并选择启用（或禁用）主动-主动模式或 BGP。示例如下图所示。

需要填写以下详细信息：

• 订阅

• 实例详细信息

• 公共 IP 地址

你可以在下图中看到一个示例：

图 4.8 – 创建 VNG

另一个需要创建的资源是 本地网络网关（LNG）。创建 LNG 时，我们需要定义以下内容：

• 名称

• IP 地址

• 地址 空间

• 订阅

• 资源 组

• 位置

• BGP 设置

BGP 设置是可选的。我们需要定义的 IP 地址是我们 VPN 设备的公共 IP 地址，地址范围是我们本地网络的地址范围。示例如下图所示：

图 4.9 – 创建 LNG

在创建 VNG 和 LNG 后，我们需要在 VNet 中创建连接：

1. 在VNet面板中的连接设置下，添加一个新连接。

2. 需要定义以下参数：名称、连接 类型、虚拟 网络 网关、本地 网络 网关、共享密钥（PSK）和IKE 协议。

3. 订阅、资源 组和位置将被锁定，并将使用与选定 VNet 相同的选项：

图 4.10 – 创建 VPN 连接

在 Azure 创建连接后，我们仍然需要在本地 VPN 设备上创建连接。强烈建议仅使用受支持的设备（大多数行业领导者的设备都支持，如 Cisco、Palo Alto 和 Juniper 等）。在本地 VPN 设备上配置连接时，我们需要考虑 Azure 端使用的所有参数。

一旦两边都配置了连接，隧道就会建立，我们应该能够从本地网络访问 Azure 资源，也可以从 Azure 访问本地网络。当然，我们可以控制流量的流动、什么可以访问什么、如何访问以及在什么条件下访问。

我们现在已经了解了如何在 Azure VNet 和本地网络之间创建连接。但我们经常需要连接一个 VNet 到另一个 VNet。当然，即使一切都在 Azure 内部，保持相同的安全级别仍然很重要。在下一部分中，我们将讨论如何在这种情况下连接网络。

连接一个 VNet 到另一个 VNet

在 Azure 中有多个 VNet 的情况下，我们可能需要在它们之间创建连接，以便允许服务在网络之间进行通信。我们可以通过两种方式来实现这一目标：

• 第一个步骤是创建 VNets 之间的 S2S 连接。在这种情况下，过程与创建 VNet 和本地网络之间的 S2S 非常相似。我们需要为两个 VNet 创建 VNG，但不需要 LNG。创建连接时，我们需要在连接类型中选择VNet 到 VNet，并选择适当的 VNG。

另一个选项是创建 VNet 对等连接。S2S 连接是安全且加密的，但它通过互联网传输。对等连接则使用 Azure 的骨干网络来路由流量，并且流量不会离开 Azure。这使得对等连接更加安全。

要在 VNets 之间创建对等连接，我们需要执行以下步骤：

1. 进入 VNet 面板中的对等连接部分，添加一个新的对等连接。

2. 我们需要定义名称和我们想要建立连接的 VNet。

3. 还有其他设置，例如是否允许双向连接，或者是否允许转发流量。

以下图示例展示了一个对等连接：

图 4.11 – 创建 VNet 到 VNet 的对等连接

理解 VNet 对等连接中的附加安全设置及其如何影响网络流量非常重要。

网络访问设置将定义从一个 VNet 到另一个 VNet 的流量访问。例如，我们可能希望启用从 VNet A 到 VNet B 的访问。但是，由于安全设置，我们希望阻止从 VNet B 到 VNet A 的访问。这样，VNet A 中的资源可以访问 VNet B 中的资源，但 VNet B 中的资源无法访问 VNet A 中的资源：

图 4.12 – VNet 对等连接

在下一节中，我们将定义如何处理转发的流量。假设 VNet A 连接到 VNet B 和 VNet C，并且 VNet B 和 VNet C 之间没有连接。在这些设置下，我们定义是否希望允许 VNet B 的流量通过 VNet A 到达 VNet C。反过来也可以进行相同的定义：

图 4.13 – 多个 VNet 的 VNet 对等连接

网关中继设置允许我们控制是否希望当前连接能够使用与另一个网络的其他连接。例如，VNet A 连接到 VNet B，且 VNet B 连接到本地网络（或另一个 VNet）。此设置将定义 VNet A 的流量是否能够到达本地网络。在这种情况下，VNet 中的一个将被本地网络替换。如果存在本地网络与 VNet A 之间的连接，并且 VNet A 与 VNet B 之间也存在连接，网关中继将决定是否允许 VNet B 的流量访问本地网络。

在下一节中，我们将讨论与安全性相关的最重要的内容，即 VNets 中的服务终结点。

VNet 服务终结点

VNet 服务终结点使我们能够扩展一些平台即服务（PaaS）服务，以使用私有地址空间。通过服务终结点，我们可以将服务（默认情况下没有此选项的）连接到我们的 VNet，从而使服务能够通过私有 IP 地址进行通信。这样，流量永远不会公开暴露，数据交换会通过 Microsoft Azure 骨干网络进行。

仅某些 Azure 服务支持此功能：

• Azure 应用服务

• Azure 容器注册表

• Azure Cosmos DB

• Azure 数据湖

• Azure MariaDB 数据库

• Azure MySQL 数据库

• Azure PostgreSQL 数据库

• Azure 事件中心

• Azure 密钥保管库

• Azure 服务总线

• Azure 存储

• Azure SQL 数据库

• Azure SQL 数据仓库

使用服务端点的第一个安全好处显然是数据永远不会离开私有空间。假设我们有 Azure 应用服务和 Azure SQL 数据库，它们通过服务端点连接到 VNet。在这种情况下，应用服务上的 Web 应用程序与 Azure SQL 数据库上的数据库之间的所有通信都将通过 VNet 安全地进行。没有数据会公开暴露，正如没有使用端点时使用相同服务的情况一样。

如果没有此功能，两个服务将只有公共 IP 地址，且它们之间的通信将通过互联网进行。虽然也有办法保证这种通信的安全性，例如通过 HTTPS 加密发送通信，但使用服务端点可以在一定程度上消除这种通信的安全风险。

但是，使用服务端点的安全性好处不仅仅止步于此。由于连接到 VNet 且使用服务端点的服务会从特定子网分配私有 IP 地址，所有与此子网相关的安全规则也会应用到我们的服务上。如果 NSG 阻止了子网上的特定流量，PaaS 服务的相同流量也会被阻止。

我们可以在创建 VNet 时，或者稍后启用 VNet 上的服务端点。服务端点是在子网级别启用的，可以在 VNet 或子网配置中进行此操作。按照以下步骤启用 VNet 中的服务端点：

1. 转到 VNet 配置页面，选择服务端点。点击添加，然后选择你想使用的子网和服务，如下图所示：

   ](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig_4.14.jpg)

   图 4.14 – 添加 PaaS 服务端点

2. 转到子网配置，选择服务，如下图所示：

图 4.15 – 在子网上启用服务端点

在 VNet 和子网上启用服务端点只是工作的一半。我们还需要在 PaaS 服务中启用设置，才能使服务端点生效。当在服务设置中启用服务端点时，只有启用了服务端点的子网会显示出来。

使用服务端点后，我们完成了 Azure VNet 设置中直接可用的网络部分。但在网络安全方面，还有其他需要考虑的因素。让我们看看在 Azure 中增加网络安全性还有哪些其他可用的功能。

考虑其他虚拟网络的安全性

为了增强安全性和流量控制，可以使用网络虚拟设备（NVA）。NVA 可以通过 Azure Marketplace 部署。部署后，你会发现 NVA 实际上是一个安装了第三方防火墙的 Azure 虚拟机。大多数行业领导者都在 Azure Marketplace 中提供解决方案，我们可以部署我们在本地环境中习惯的防火墙解决方案。需要提到的是，我们不必在 NSG 和 NVA 之间做出选择；这两者可以结合使用，以提供额外的安全性。

使用 Azure 防火墙还可以实现额外的网络安全。Azure 防火墙是一种作为服务提供的防火墙。它比 NSG 提供更好的网络控制，在许多方面可以与 NVA 解决方案进行比较。但与 NVA 相比，Azure 防火墙也有一些优势，如内置高可用性、可以部署到多个可用区的选项以及不受限制的云扩展性。这意味着无需负载均衡器。我们可以将 Azure 防火墙跨多个可用区部署（并实现 99.99% 的 SLA），并且扩展配置可以自动适应网络流量的任何变化。支持的选项包括：应用程序过滤、网络流量过滤、FQDN 标签、服务标签、出站 SNAT 支持、入站 DNAT 支持以及多个公共 IP 地址。通过这些选项，我们可以对 VNet 中的网络流量进行完全控制。需要注意的是，Azure 防火墙符合许多安全标准，如 SOC 1 Type 2、SOC 2 Type 2、SOC 3、PCI DSS 和 ISO 27001、27018、20000-1、22301、9001 和 27017。

接下来，我们将查看如何通过 Azure 门户部署和配置 Azure 防火墙。

Azure 防火墙的部署和配置

本示例——部署和配置 Azure 防火墙——需要使用 Azure PowerShell。但是，也可以通过 Azure 门户配置和部署 Azure 防火墙。

Azure 防火墙的部署

为了部署 Azure 防火墙，我们需要设置所需的网络和基础设施：

1. 首先，我们需要创建子网，创建一个 VNet，并将子网与 VNet 关联：

   $FWsub = New-AzVirtualNetworkSubnetConfig -Name ` AzureFirewallSubnet -AddressPrefix 10.0.1.0/26
   $Worksub = New-AzVirtualNetworkSubnetConfig -Name Workload-SN ` -AddressPrefix 10.0.2.0/24
   $Jumpsub = New-AzVirtualNetworkSubnetConfig -Name Jump-SN `  
   -AddressPrefix 10.0.3.0/24 
   $testVnet = New-AzVirtualNetwork -Name Packt-VNet `
   -ResourceGroupName Packt-Security -Location "westeurope" `
   -AddressPrefix 10.0.0.0/16 -Subnet $FWsub, $Worksub, $Jumpsub 
   

2. 接下来，我们需要部署 Azure 虚拟机（VM），该虚拟机将用作跳跃盒子（我们连接到该虚拟机以便对网络中的其他虚拟机执行管理任务；我们不会直接连接到其他虚拟机，而是通过跳跃盒子进行连接）：

   New-AzVm -ResourceGroupName Packt-Security -Name "Srv-Jump" `
   -Location "westeurope" -VirtualNetworkName Packt-VNet `
   -SubnetName Jump-SN -OpenPorts 3389 -Size "Standard_DS2" 
   

3. 在跳跃盒子之后，我们创建一个测试虚拟机（VM）：

   $NIC = New-AzNetworkInterface -Name Srv-work `
   -ResourceGroupName Packt-Security -Location "westeurope" `
   -Subnetid $testVnet.Subnets[1].Id
   $VirtualMachine = New-AzVMConfig -VMName Srv-Work -VMSize ` "Standard_DS2"
   $VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine `
   -Windows -ComputerName Srv-Work -ProvisionVMAgent `
   -EnableAutoUpdate
   $VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine ` -Id $NIC.Id
   $VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine `
   -PublisherName 'MicrosoftWindowsServer' -Offer 'WindowsServer' ` -Skus '2016-Datacenter' -Version latest
   New-AzVM -ResourceGroupName Packt-Security -Location ` "westeurope" -VM $VirtualMachine -Verbose 
   

4. 最后，我们部署 Azure 防火墙：

   $FWpip = New-AzPublicIpAddress -Name "fw-pip" `
   -ResourceGroupName  Packt-Security -Location "westeurope" `
   -AllocationMethod Static -Sku Standard
   $Azfw = New-AzFirewall -Name Test-FW01 -ResourceGroupName `
   Packt-Security -Location "westeurope" -VirtualNetworkName ` Packt-VNet -PublicIpName fw-pip
   $AzfwPrivateIP = $Azfw.IpConfigurations.privateipaddress 
   

5. 接下来，我们将查看 Azure 防火墙的配置。

Azure 防火墙的配置

部署 Azure 防火墙后，它实际上什么也不做。我们需要创建配置和规则，以使 Azure 防火墙生效：

1. 首先，我们将创建一个新的路由表，并禁用 BGP 传播：

   $routeTableDG = New-AzRouteTable -Name Firewall-rt-table `
   -ResourceGroupName Packt-Security -location "westeurope" `
   -DisableBgpRoutePropagation
   Add-AzRouteConfig -Name "DG-Route" -RouteTable $routeTableDG `
   -AddressPrefix 0.0.0.0/0 -NextHopType "VirtualAppliance" `
   -NextHopIpAddress $AzfwPrivateIP | Set-AzRouteTable
   Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $testVnet `
   -Name Workload-SN -AddressPrefix 10.0.2.0/24 `
   -RouteTable $routeTableDG | Set-AzVirtualNetwork 
   

2. 接下来，我们创建一个应用程序规则，允许访问 www.google.com 的出站流量：

   $AppRule1 = New-AzFirewallApplicationRule -Name Allow-Google `
   -SourceAddress 10.0.2.0/24 -Protocol http, https `
   -TargetFqdn www.google.com
   $AppRuleCollection = New-AzFirewallApplicationRuleCollection `
   -Name App-Coll01 -Priority 200 -ActionType Allow -Rule $AppRule1
   $Azfw.ApplicationRuleCollections = $AppRuleCollection
   Set-AzFirewall -AzureFirewall $Azfw 
   

3. 然后，我们创建一个规则，允许在端口 53 上进行 DNS 访问：

   $NetRule1 = New-AzFirewallNetworkRule -Name "Allow-DNS" `
   -Protocol UDP -SourceAddress 10.0.2.0/24 `
   -DestinationAddress 209.244.0.3,209.244.0.4 -DestinationPort 53
   $NetRuleCollection = New-AzFirewallNetworkRuleCollection `
   -Name RCNet01 -Priority 200 -Rule $NetRule1 -ActionType "Allow"
   $Azfw.NetworkRuleCollections = $NetRuleCollection
   Set-AzFirewall -AzureFirewall $Azfw 
   

4. 然后，我们需要为网络接口卡（NIC）分配一个 DNS：

   $NIC.DnsSettings.DnsServers.Add("209.244.0.3")
   $NIC.DnsSettings.DnsServers.Add("209.244.0.4")
   $NIC | Set-AzNetworkInterface
   

尝试连接到跳跃盒子，然后通过跳跃盒子测试虚拟机。从测试虚拟机尝试解析多个 URL。只有 www.google.com 应该成功，因为除非我们创建了明确的允许规则，否则所有出站流量都会被拒绝。

让我们继续了解 PaaS 中的网络，并查看除了使用服务端点保护 PaaS 外，还有哪些可用的选项。即使服务端点公开可用，我们也能更好地控制网络并防止不需要的流量。

了解 Azure 应用程序网关

下一个可以帮助增加安全性的 Azure 服务是应用网关。应用网关是一个用于 Web 应用程序的流量负载均衡器，能够管理 Web 应用程序的流量。它作为第 7 层（L-7或应用层）负载均衡器运行。这意味着它支持基于 URL 的路由，并可以根据 URI 路径或主机头路由请求。

应用网关支持安全套接字层（SSL/TSL）终止网关。网关之后，流量以未加密形式流向后端服务器，后端服务器无需承担加密和解密的开销。但是，如果因为安全、合规性或其他要求而不选择此选项，则还支持全端到端加密。

应用网关还支持可伸缩性和区域冗余。可伸缩性允许根据流量负载进行自动扩展，而区域冗余允许将服务部署到多个可用区，以提供更好的故障容错性，并消除手动部署到多个区域的需求。

总体而言，Azure 应用网关是一个 L-7 负载均衡器，如果排除 SSL/TSL 终止，我们可以质疑其安全方面，因为这更多是可靠性和可用性的问题。但是，应用网关具有一个称为 Azure Web 应用防火墙（WAF）的出色安全功能。WAF 保护 Web 应用程序免受常见的攻击和漏洞。

WAF 基于开放式 Web 应用安全项目（OWASP），并更新以解决最新的漏洞。由于它是平台即服务（PaaS），所有更新都会自动完成，无需用户配置。从策略的角度来看，我们可以创建多个自定义策略，并将不同的策略集应用于不同的 Web 应用程序。

两种模式可供选择：检测模式和预防模式。在检测模式下，WAF 将检测所有可疑请求，但不会阻止它们，只会记录下来。需要强调的是，WAF 可以与不同的日志工具集成，因此日志可以用于审计目的。在预防模式下，WAF 还将阻止任何恶意请求，返回403 unauthorized access异常，并关闭连接。预防模式也会记录所有攻击。

攻击按四个严重级别分类：

• 严重（5）

• 错误（4）

• 警告（3）

• 注意（2）

每个级别都有一个严重性值，阻止的阈值为5。因此，单个严重问题足以阻止值为5的会话，但至少需要 2 个错误问题才能阻止会话，因为一个值为4的错误低于阈值。

WAF 在应用网关之前起到过滤器的作用 - 它会处理请求，决定其是否有效，并根据此决定允许请求继续传递到应用网关或拒绝请求。一旦 WAF 允许请求通过，应用网关则作为正常的 L-7 负载均衡器运行，就好像 WAF 已关闭一样。您可以在以下图中看到这一点：

图 4.16 – 应用网关流量流动

下面列出了一些可以通过 WAF 检测并防止的攻击：

• SQL 注入

• 跨站脚本攻击

• 命令注入

• 请求走私

• 响应分割

• HTTP 协议违反和异常

• 防护爬虫和扫描器

• 地理过滤流量

应用网关上的 WAF 支持将日志选项传输到 Azure Monitor、诊断日志存储到存储账户，并与安全工具如 Azure Security Center 或 Azure Sentinel 集成。

了解 Azure Front Door

Azure Front Door 与应用网关的工作方式非常相似，但它位于不同的层级。像应用网关一样，它是一个具有 SSL 卸载的 L-7 负载均衡器。不同之处在于，应用网关只与单一区域中的服务协作，而 Azure Front Door 允许我们在全球范围内定义、管理和监控路由。通过 Azure Front Door，我们可以通过全球分发确保最高的可用性。使用 Azure Traffic Manager 也能实现类似的全球分发功能，但该服务不具备 L-7 负载均衡和 SSL 卸载功能。

Azure Front Door 提供的功能实际上结合了应用网关和流量管理器，以实现具有全球分发的 L-7 负载均衡器。还需要提到的是，Azure Front Door 上还可以使用 WAF。通过在 Azure Front Door 上使用 WAF，我们可以为全球分布的应用程序提供 Web 应用保护。

总结

本章我们讨论了网络安全，之前我们还讨论了如何管理云身份。我们需要记住，网络安全不仅仅止步于 IaaS 和 VNets。网络安全的基础通常与 VNets 和 NSGs 相关。但即使是在 IaaS 中，也不止于此，我们可以通过 NVA 或 Azure 防火墙来扩展安全性。在 PaaS 中，我们可以利用 VNet 的服务端点，并通过应用网关或 Azure Front Door 等服务进一步扩展安全性。

但是，尽管有许多限制我们访问资源的前提条件，如谁、如何、何时以及从哪里获取资源，我们仍然需要处理敏感信息和数据。下一章将讲解如何使用 Azure Key Vault 管理证书、机密、密码和连接字符串。

问题

1. 我们可以通过……控制虚拟网络中的流量

   A. 网络接口

   B. 网络安全组（NSG）

   C. 访问控制列表（ACL）

2. 与本地网络连接可用的类型是什么？

   A. 点到站点

   B. 站点到站点

   C. VNet 对 VNet

3. 虚拟网络之间的连接可以通过……

   A. VNet 对 VNet

   B. VNet 对等连接

   C. 以上两项

   D. 以上都不正确

4. 哪个功能允许我们将 PaaS 服务连接到虚拟网络？

   A. 服务连接

   B. 服务端点

   C. ExpressRoute

5. 当涉及多个网络时……

   A. 我们可以定义路由

   B. 默认情况下，流量被阻止

   C. 默认情况下，流量允许

   D. A 和 B 正确

   E. A 和 C 正确

6. 在应用程序网关中，哪个功能可以增加额外的安全性？

   A. 开放网络应用安全项目（OWASP）

   B. 网络应用防火墙（WAF）

   C. 安全套接字层（SSL）/ 传输层安全协议（TSL）

7. 什么类型的攻击无法通过应用程序网关进行阻止？

   A. SQL 注入（SQLi）

   B. 跨站脚本攻击（XSS）

   C. 分布式拒绝服务攻击（DDoS）

   D. HTTP 协议违规

第五章：第五章：Azure 密钥保管库

谈到云计算时，讨论往往集中在数据保护、加密、合规性、数据丢失（和数据丢失预防）、信任和其他围绕相同主题的流行词。它们的共同点是需要一个可信的服务，帮助它们在不让云供应商访问您的数据和相应加密密钥的情况下保护云数据。假设您想创建一个 Azure 资源，如虚拟机，需要管理员凭据。在这种情况下，您不希望在部署脚本或模板中硬编码用户名和密码，对吧？这就是 Azure 密钥保管库发挥作用的场景。在本章中，我们将涵盖以下主题：

• 理解 Azure 密钥保管库

• 理解服务对服务的身份验证

• 在部署场景中使用 Azure 密钥保管库

理解 Azure 密钥保管库

Azure 密钥保管库是用于密钥、秘密和证书的安全云存储解决方案。令牌、密码、证书、API 密钥和其他秘密可安全存储，并且可以使用 Azure 密钥保管库精细控制对它们的访问。该服务还可用作密钥管理解决方案。Azure 密钥保管库可以轻松创建和控制用于加密数据的加密密钥。另一个使用场景是安全套接字层/传输层安全性 (SSL/TLS) 证书的注册和管理。您可以使用 Azure 密钥保管库管理 Azure 和内部连接资源的证书生命周期管理。存储在 Azure 密钥保管库中的秘密和密钥可以通过软件或已通过 FIPS 140-2 Level 2 验证的 HSM（硬件安全模块）进行保护。

正如您已经了解的那样，您可以使用 Azure 密钥保管库来管理密钥、秘密和证书。

• 加密密钥用于数据加密。Azure 密钥保管库将密钥表示为JSON Web Key（JWK）对象，它们声明为软密钥或硬密钥。硬密钥在硬件安全模块（HSM）中处理，而软密钥由 Azure 密钥保管库在软件中处理。软密钥仍然在静态状态下使用存储在 HSM 中的硬密钥进行加密。客户端可以请求 Azure 密钥保管库生成密钥或导入现有的 RSA 或椭圆曲线（EC）密钥。RSA 和 EC 是 Azure 密钥保管库支持的算法。

• Azure 密钥保管库是在 Azure Key Vault 中加密和存储的字符串。秘密可用于安全存储密码、存储帐户密钥和其他高价值字符串。

• Azure Key Vault 中的证书是由 公钥基础设施（PKI）颁发的 x509 证书。你可以让 Azure Key Vault 向支持的公 认证机构（CA）请求证书，目前支持的认证机构有 DigiCert 和 GlobalSign，或者你可以在 Azure Key Vault 中创建 证书签名请求（CSR），然后手动让你选择的任何公认证机构签署该 CSR。

本章将教你如何操作密钥库实体。但在此之前，我们先来看看 Azure Key Vault 中的服务到服务认证，这是在部署或资源管理操作中使其他 Azure 服务能够利用 Azure Key Vault 所需的认证方式。

访问 Azure Key Vault 是通过 RBAC（角色基础访问控制）授予的。也就是说，你需要拥有一个 Azure AD 账户才能访问该服务，这意味着你可以使用所有在第三章中讨论的交互式身份验证保护选项，管理云身份。此外，访问 Azure Key Vault 保护的项目可以限制为仅访问 Azure Key Vault 的单个方面。例如，可以只授予某个账户访问机密的权限，而不授予访问密钥或证书的权限，或者你可以只授予某个账户部分权限，但允许其访问密钥库中存储的所有实体。这种细粒度的权限管理，除了 RBAC 只能授予对 Azure Key Vault（作为 Azure 资源）的访问外，是通过访问策略实现的。接下来的部分将更详细地讨论这些策略。

理解访问策略

通过访问策略，你可以精细地定义谁可以获得 Azure Key Vault 单个实例的哪些级别的访问权限：

图 5.1 – Azure Key Vault 访问策略

如前面的截图所示，名为 Tom 的用户账户被授予了在 Azure Key Vault MasteringAzSec 部分的 访问策略 设置中访问密钥、机密和证书的多个权限。除此之外，你还可以为 Azure 虚拟机、ARM 和 Azure 磁盘加密启用密钥和机密的访问权限。如果你希望在虚拟机部署期间允许你租户中的 Azure 虚拟机读取机密（以便在部署时检索），或者希望允许 Azure 资源管理器检索机密以便在模板部署中使用，那么这些选项是必要的。第三个选项指定是否允许 Azure 磁盘加密服务——该服务使用 BitLocker 或 dm-crypt（根据 Azure 虚拟机中使用的操作系统）对虚拟机的磁盘进行加密——从 Azure Key Vault 检索机密并解密存储在密钥中的值。

在我们继续学习如何使用 Azure Key Vault 实现服务到服务的认证之前，首先让我们更深入地了解一下 Azure Key Vault 中的各个单独实体。

理解服务到服务认证

正如我们之前提到的，访问 Azure 密钥库及其实体通常是按用户授予的。也就是说，为了启用服务到服务的身份验证，您可以创建一个 Azure AD 应用及其凭证，并使用此服务主体为您的应用获取访问令牌。这是一个非常简单的过程：

1. 转到 Azure Active Directory | 应用注册，在 Azure 门户中选择 新建注册 以启动向导：

   ](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig_5.2.jpg)

   图 5.2 – 创建新的应用注册

2. 输入名称并确认您的选择。

3. 通过导航到应用注册中的证书与密钥选项，然后选择新建客户端密钥来创建客户端密钥：

   ](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig_5.3.jpg)

   图 5.3 – 创建新的客户端密钥

4. 输入描述并决定密钥是将在 1 年或 2 年后过期，还是始终有效。确认选择并退出向导后，系统将显示新的客户端密钥及其值，您可以复制该值并用于身份验证：

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig_5.4.jpg)

图 5.4 – 您的客户端密钥

一种更快捷的方法是使用 Azure CLI。通过以下命令，您可以轻松创建一个名为 MasteringAzSecSP 的新服务主体：

Az ad sp create-for-rbac --name MasteringAzSecSP

引擎将使用默认设置进行账户创建，完成后，您将在 CLI 窗口中找到用户名 appId 和客户端密钥密码，如下截图所示：

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig_5.5.jpg)

图 5.5 – 使用 Azure CLI 创建新的服务主体

服务主体在访问管理方面类似于用户账户，这意味着您可以将用户名（应用或客户端 ID）作为主体，在授予对密钥库及其实体的访问权限时使用。

尽管这种方法效果很好，但也有两个缺点：

• 在创建应用凭据时，您将获得应用 ID 和客户端密钥，这些通常是硬编码在源代码中的。这是一个两难问题，因为您无法将这些凭据存储在 Azure 密钥库中，因为在授予对密钥库的访问权限之前需要进行身份验证。

• 应用凭证会过期，续订过程可能会导致应用停机。您不希望使用一个永不过期并且硬编码在源代码中的客户端密钥。

因此，对于自动化部署，我们需要另一种方法，这就是Azure 资源的托管标识服务的作用所在。那么，让我们进一步了解此服务如何解决这一难题。

理解 Azure 资源的托管标识

经常会遇到需要凭据才能访问服务的常见问题。Azure Key Vault 是应用程序设计的重要组成部分，因为您可以使用它安全地存储和管理其他服务的凭据。但是 Azure Key Vault 本身是一个在授予权限之前需要进行身份验证的服务。通过 Azure 资源的托管身份，Azure Active Directory 的一个免费功能，您可以解决这个困境。该服务为其他 Azure 服务提供在 Azure AD 中自动管理的身份。

服务中有两种不同类型的托管身份：

• 系统分配的托管身份直接启用在 Azure 服务实例上。启用托管身份时，Azure AD 自动在 Azure AD 中为特定服务创建一个身份，该身份自动由创建服务实例的 Azure 订阅信任。身份创建后，凭据将自动提供给服务实例。身份的生命周期直接与服务的生命周期相关联，这意味着当服务被删除时，系统分配的托管身份将自动从 Azure AD 中删除。

• 用户分配的托管身份是手动创建的 Azure 资源。创建用户分配的托管身份时，Azure AD 将在 Azure AD 租户中创建一个服务主体，该主体由当前使用的 Azure 订阅信任。创建身份后，可以将其分配给一个或多个 Azure 服务实例。用户分配的托管身份的生命周期与分配给身份的服务的生命周期分开管理。换句话说，当具有用户分配的托管身份的 Azure 资源被删除时，托管身份不会自动从 Azure AD 中删除。

系统分配的托管身份与 Azure 资源之间的关系是 1:1，这意味着一个 Azure 资源只能有一个系统分配的托管身份，并且此身份只能由其创建的特定服务使用。

用户分配的托管身份与 Azure 资源之间的关系是 n:n，这意味着您可以同时使用多个用户分配的托管身份与一个 Azure 资源，并且一个单独的用户分配的托管身份可以被多个不同的 Azure 资源使用。

重要说明

Microsoft 提供了一个 Azure 服务列表，当前支持系统分配、用户分配或两种类型的托管身份，详见 docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities.

在 Azure 门户中创建系统分配的托管身份的过程非常简单。所有当前支持托管身份的 Azure 资源，在资源的设置部分都会有一个身份选项：

图 5.6 – 为 Azure 虚拟机激活系统分配的托管身份

以下步骤展示了如何为 Azure 虚拟机激活系统分配的托管身份：

1. 在设置页面，你可以选择是要激活系统分配的托管身份，还是要分配用户分配的托管身份。要激活系统分配的托管身份，你只需将状态切换按钮设置为开启，然后保存你的选择，如前面的截图所示。

2. 然后你将被告知，一旦你确认此配置，你的资源的托管身份将会注册到 Azure AD，且一旦该过程完成，你可以授予该托管身份权限。在前面的示例中，我已为名为 DC01 的 Azure 虚拟机启用了系统分配的托管身份。

3. 在创建新的密钥库访问策略时，我们现在可以选择具有相同名称的身份，授予其访问密钥库实体的权限。

如果你想创建一个新的用户分配的托管身份，你需要在 Azure 门户中导航到托管身份服务：

1. 为此，请前往所有资源，然后搜索托管身份。

2. 一旦找到对话框，你可以选择创建一个新的用户分配的托管身份。如前所述，这是一个新的 Azure 资源，因此需要在 Azure 订阅中创建并存储在 Azure 资源组中：

   图 5.7 – 创建用户分配的托管身份

3. 一旦用户分配的托管身份创建完成，你可以将其分配给你的 Azure 资源，就像我们在前述场景中使用的虚拟机一样。

托管身份还可以用于 Azure DevOps 或 Terraform 对你的 Azure 环境进行身份验证。

重要提示

你也可以使用 Azure CLI、PowerShell、ARM 模板和 Terraform 来在 Azure 中创建托管身份。你可以在为本书创建的 GitHub 仓库中找到这些方法的示例，地址为 github.com/PacktPublishing/Mastering-Azure-Security。

假设你只想通过 DevOps 管道来允许创建 Azure 资源，并包括所有相关的过程，比如拉取请求、编写等。从技术角度来看，Azure DevOps 无非是一个需要被授权访问 Azure 订阅（或管理组）的应用程序。因此，Azure DevOps 需要一个服务主体，可以手动管理为应用程序注册，并承担所有缺点，或者可以通过托管身份进行自动管理。同样适用于 Terraform，它也只是一个需要在 Azure 环境中具有权限的应用程序。

重要提示

你可以使用托管身份进行 Terraform 身份验证以访问 Azure AD；然而，在这种情况下，托管身份是为 Azure 虚拟机创建的，而 Terraform 需要从虚拟机内部启动，以便可以使用该身份。

现在你已经了解了托管身份的工作原理，以及服务间身份验证的选项，让我们向前迈进一步，看看如何在部署场景中使用 Azure Key Vault。

在部署场景中使用 Azure Key Vault

Azure Key Vault 是一个很好的服务，用于安全地存储和检索在资源创建过程中需要的凭据。它还帮助你使用自己的加密密钥对 Azure 资源（如 Azure 存储账户或虚拟机磁盘）进行加密。

在本节中，我们将介绍几种在部署场景中使用 Azure Key Vault 的选项。你将找到 PowerShell、ARM 模板和 Terraform 的示例，因为这些是创建 Azure 资源时最常见的部署工具。

重要提示

你需要经历的第一步是通过一个在 Azure 环境中已经分配了适当访问权限的主体进行 Azure AD 身份验证，具体取决于你要执行的任务和受其影响的资源。

你准备好了吗？那么我们从创建一个新的 Azure 密钥保管库开始，并创建一个可以在接下来的虚拟机部署场景中使用的机密。

创建 Azure 密钥保管库和机密

和所有 Azure 资源一样，你可以使用 Azure 门户来创建和管理 Azure 密钥保管库。尽管通过门户点击操作可能很方便，但使用脚本或模板语言来做这件事会是更好的选择。Azure Key Vault 是自动化部署中的一个关键资源。现在，还没有办法在同一个密钥保管库中对相同类型的单个项授予细粒度的访问权限。你可以管理密钥、机密和证书的访问级别，但只能在密钥保管库级别管理，而不能在项级别管理。因此，你可能希望在同一个 Azure 订阅中创建多个密钥保管库。通过使用部署自动化，你可以确保环境中的所有密钥保管库都遵循你定义的规则和策略。

在 PowerShell 中创建密钥保管库

由于 PowerShell 是一种命令式脚本语言，你需要按正确的顺序定义所有必要的步骤：

1. 首先，你需要使用具有适当访问权限的帐户登录，以便在你的 Azure 订阅中创建一个新的资源组和 Azure 密钥保管库实例：

   # Login to your Azure subscription
   Login-AzAccount
   

2. 然后，你将被提示输入 Azure 登录凭据，PowerShell 将使用这些凭据执行后续步骤。登录后，你可以创建一个新的资源组，或引用一个现有的资源组。

3. 现在我们假设将使用以下代码片段创建一个新的资源组。在此之前，先定义所有变量的值，然后再在后续脚本部分中使用：

   # Define variable values
   $rgName = "myResourceGroup"
   $azRegion= "WestEurope"
   $kvName = "myAzKeyVault"
   $secretName = "localAdmin"
   $localAdminUsername = "myLocalAdmin"
   # Create a new resource group in your Azure suscription
   $resourceGroup = New-AzResourceGroup `
   -Name $rgName `
   -Location $azRegion
   

4. 现在，你可以继续创建一个新的 Azure 密钥保管库：

   VaultName defines the name of the Azure key vault. We are using the $kvName variable, which is defined at the beginning of the script.
   

5. ResourceGroupName 定义了密钥保管库将要创建的 Azure 资源组。

6. Location 定义了密钥保管库将要创建的 Azure 区域。

还有一些可选参数，在前面的部分中已经定义：

• EnabledForDeployment 使 Microsoft.Compute 资源提供者能够在资源创建过程中从 Azure 密钥保管库中检索机密——例如，在部署新虚拟机时。

• EnabledForTemplateDeployment 使 Azure 资源管理器（ARM）能够在模板部署中引用 Azure 密钥保管库时获取机密，例如，在使用 ARM 或 Terraform 时。

• EnabledForDiskEncryption 使 Azure 磁盘加密 服务能够从 Azure 密钥保管库获取机密并解开密钥，以便在磁盘加密过程中使用。

• SKU 定义了 Azure 密钥保管库的 SKU（标准或高级）。

1. 在 Azure 密钥保管库创建完成后，你需要创建一个访问策略。在以下示例中，我们为当前登录的用户帐户授予对新 Azure 密钥保管库中机密的访问权限：

   # Grant your user account access rights to Azure Key Vault secrets
   Set-AzKeyVaultAccessPolicy `
   	-VaultName $kvName `
   	-ResourceGroupName $rgName `
   	-UserPrincipalName (Get-AzContext).account.id `
   	-PermissionsToSecrets get, set
   

2. 然后，你可以创建一个新的密钥保管库机密。在以下代码片段中，你将在 PowerShell 会话中将机密作为安全字符串输入：

   # Create a new Azure Key Vault secret
   $password = read-host -assecurestring
   Set-AzKeyVaultSecret ` 
   	-VaultName $kvName `
   	-Name $secretName `
   	-SecretValue $password
   

恭喜！你刚刚使用 PowerShell 创建了你的第一个 Azure 密钥保管库和一个机密。现在，你已经了解了如何为你的部署场景创建 Azure 密钥保管库和密钥保管库机密，我们可以进入下一部分——Azure 虚拟机部署，在这里你将学习如何在更复杂的场景中使用你刚创建的资源。

Azure 虚拟机部署

在部署 Azure 虚拟机时，你总是需要在部署过程中传递本地管理员凭据。通过 Azure 门户部署虚拟机的缺点是，你需要手动输入相应的本地管理员凭据，而不是使用存储在 Azure 密钥保管库中的机密。这只是基础设施即代码部署在企业环境中显得特别有意义的原因之一。在本节中，你将学习如何引用存储在 Azure 密钥保管库中的凭据，而不是将信息硬编码在部署脚本或模板中。

我们将从使用 PowerShell 引用虚拟机部署的密钥保管库机密开始。

使用 PowerShell 部署虚拟机

你可以通过 PowerShell 轻松访问 Azure 密钥保管库中的机密，也可以通过 ARM 模板和 Terraform 进行访问。接下来，我们将通过以下步骤演示如何做到这一点：

1. 在你获取到机密后，需要创建一个新的 PSCredential 对象，该对象可以在虚拟机部署中使用，如下所示：

   # retrieve an Azure Key Vault secret
   $secret = Get-AzKeyVaultSecret `	-VaultName $kvName `
   	-Name $secretName
   # Create a new PSCredential object
   $cred = [PSCredential]::new($localAdminUsername,$secret.SecretValue)
   

2. 后续，你可以在部署中相应的位置使用这个 PSCredential 对象。它看起来类似于以下代码片段：

   $myVM = Set-AzVMOperatingSystem ` 
   	-VM $myVM `
   	-Windows `
   	-ComputerName $vmName `
   	-Credential $cred `
   	[…]
   

在 PowerShell 脚本中使用变量总是一个好主意。通过这样做，你可以在脚本的开头创建一个变量部分，在其中定义根据需求和脚本所用环境而变化的值。

提示

由于完整的 PowerShell 虚拟机部署脚本包含近 200 行，我们没有在书中打印出来，而是将其发布在了本书的 GitHub 仓库中。

PowerShell 是一种很好的部署 Azure 资源的方式，但由于它是一种命令式脚本语言，因此并不适合在 DevOps/CI/CD 场景中使用。这就是为什么我们将在下一节中解释如何在 Terraform 中引用密钥保管库机密。

在 Terraform 中引用密钥保管库机密

在 Terraform 中，你可以通过数据源引用现有的 Azure 对象。对于密钥保管库机密，数据源被称为 azurerm_key_vault_secret：

# Azure Key Vault data source to access local admin password
data "azurerm_key_vault_secret" "mySecret" {
	name = "secretName"
	key_vault_id = "/subscriptions/GUID/resourceGroups/RGName/providers/Microsoft.KeyVault/vaults/VaultName"
}

然后，可以在 Terraform 部署模板的 os_profile 部分引用该对象，如下图所示：

os_profile {
	computer_name = "myVM"
	admin_username = "myLocalAdminUserName"
	admin_password = "$(data.azurerm_key_vault_secret.mySecret.value)"
}

Terraform 是一种相对简单的 Azure 资源部署和引用方式。如前面的例子所示，你只需定义一个数据源，然后在部署模板的相应资源部分引用它。

提示

我们在本书的 GitHub 仓库中发布了一个完整的 Terraform 虚拟机部署示例：github.com/PacktPublishing/Mastering-Azure-Security

ARM 模板是微软在 DevOps 管道中使用自动 Azure 资源部署的方式。这个例子将在以下章节中详细描述。

在 ARM 模板中引用密钥保管库机密

ARM 模板可能是引用密钥保管库机密的最复杂方式，因为在这种情况下需要使用链接模板。也就是说，你需要有两个不同的模板文件，分别用于不同的目的。

主要模板作为引用现有 Azure 资源的参考，例如 Azure 密钥保管库及其机密。在其中，有一个 parameters 部分，包含的值可以直接在主模板中定义，或者通过外部调用（如 Azure CLI 或 PowerShell 调用）传递到模板中，然后直接传递给链接模板。

如果 parameters 部分由管道输入填充，它将只包含参数的定义：

"parameters": {
	"vaultName": {
		"type": "string"
	},
	"vaultResourceGroup": {
		"type": "string"
	},
	"secretName": {
		"type": "string"
	}
}

如果参数值在主模板中定义，那么这一部分将如下所示：

"parameters": {
	"vaultName": {
		"type": "string",
		"defaultValue": "<default-value-of-parameter>"
	},
	"vaultResourceGroup": {
		"type": "string",
		"defaultValue": "<default-value-of-parameter>"
	},
	"secretName": {
		"type": "string",
		"defaultValue": "<default-value-of-parameter>"
	}
}

在 parameters 部分之后，有一个 resource 部分，其中定义了密钥保管库的引用：

"parameters": {
	"adminPassword": {
		"reference": {
			"keyVault": {
				"id": "[resourceId(subscription().subscriptionId,  parameters('VaultResourceGroup'), 'Microsoft.KeyVault/vaults', parameters('vaultName'))]"
			},
			"secretName": "[parameters('secretName')]"
		}
	}
}

链接模板 用于实际的资源部署。在这个文件中，定义了本地管理员用户名，但密码值是从主模板传递过来的，具体如下：

"resources": {
"parameters": {
		"adminUsername": {
			"type": "string",
			"defaultValue": "localAdminUsername",
			"metadata": {
				"description": ""
			}
		},
		"adminPassword": {
			"type": "securestring"
		}
}
}

使用 ARM 模板引用密钥保管库的秘密稍微复杂一些，但在 DevOps 管道中也能很好地工作。

提示

我们在本书的 GitHub 仓库中发布了一个完整的 VM 部署示例，使用了 ARM 模板：github.com/PacktPublishing/Mastering-Azure-Security

你现在已经学会了如何在自动化的 Azure 资源部署中使用 Azure 密钥保管库和密钥保管库的秘密，包括使用 PowerShell、Terraform 和 ARM 模板。请务必查看本书的 GitHub 仓库，那里有我们在本章中概述的步骤示例，供你参考。

总结

Azure Key Vault 是 Azure 中许多被低估但在安全方面非常有价值的服务之一。在这一章中，你学习了如何通过 Azure 门户、脚本和部署语言创建 Azure 密钥保管库及其实体。现在你知道如何为个人用户和 Azure 资源授予对 Azure 密钥保管库的访问权限，并且知道如何引用已安全存储在密钥保管库中的项目。

在下一章中，我们将讨论数据安全和加密这两个高度依赖 Azure Key Vault 的主题，因此在继续阅读之前，请确保你已阅读并理解了本章内容。

问题

1. Azure Key Vault 用于保护……

   A. 密钥

   B. 秘密

   C. 证书

   D. 以上所有

   E. 以上都不是

2. 我们如何控制谁可以访问 Azure Key Vault 信息？

   A. 密钥保管库权限

   B. 访问策略

   C. 条件访问

3. 服务到服务的认证是通过……

   A. 服务主体

   B. 证书

   C. 直接链接

4. 为了使用 Azure Key Vault 进行 启用部署

   B. 启用模板部署

   C. 启用磁盘加密

5. 为了使用 Azure Key Vault 进行 启用部署

   B. 启用模板部署

   C. 启用磁盘加密

6. 为了使用 Azure Key Vault 进行虚拟机加密，我们需要启用哪个选项？

   A. 启用部署

   B. 启用模板部署

   C. 启用磁盘加密

7. 为了在部署过程中保护秘密，我们需要……

   A. 提供密码

   B. 加密密码

   C. 引用 Azure 密钥保管库

第六章：第六章：数据安全

像其他一切一样，云中的数据必须与本地环境中的数据不同对待。由于数据离开了我们的本地环境，并通常可以通过互联网访问，我们需要格外小心。我们已经提到过，所有数据在静态时都进行了加密，大多数通信也通过 HTTPS（超文本传输协议安全套接字层）进行，并在传输过程中加密。然而，我们可以采取多种措施来确保额外的安全性，并满足合规性和不同的安全要求。

在本章中，我们将广泛使用 Azure Key Vault。我们已经看到 Azure Key Vault 如何用于机密和密码管理，但我们还将看到它如何用于增强数据安全性。

本章将涵盖以下主题：

• 理解 Azure 存储

• 理解 Azure 虚拟机磁盘

• 在 Azure SQL 数据库上工作

技术要求

本章需要以下内容：

• Windows 上的 PowerShell 5.1 或更高版本（或在任何其他平台上，包括 Windows 的 PowerShell Core 6.x 及更高版本）

• Azure PowerShell 模块

• Visual Studio Code

• 一个 Azure 订阅

理解 Azure 存储

Azure 存储是微软的云存储服务，具有高可用性、安全性和可扩展性，此外，它还支持多种编程语言。通常，当用户开始使用 Azure 时，Azure 存储是他们首先接触到的数据服务。

所有 Azure 数据中心内部的通信都通过 HTTPS 进行，但当我们从外部访问数据时会发生什么呢？根据共享责任模型（在第一章，Azure 安全简介中有解释），这属于用户的责任。由于不同用户的需求，微软默认不强制要求流量通过 HTTPS，但用户可以启用一个选项，强制要求流量加密。

在 配置 下，有一个选项叫做 要求安全传输。为了确保所有流量都加密并通过 HTTPS 进行，我们需要启用此选项，如下图所示：

图 6.1 – Azure 存储安全传输

当启用 要求安全传输 时，所有不是通过 HTTPS 的请求将被拒绝，即使它们具有有效的访问参数（如访问签名或令牌）。这通过仅允许通过安全连接发起的请求来增强传输安全性。

重要提示

需要记住的是，Azure 存储不支持自定义域名的 HTTPS，因此在使用自定义域名时此选项不适用。

我们还需要考虑的是，当文件被意外删除时会发生什么。这可能有多种原因，例如用户错误地删除了文件，或者多个应用程序使用相同的 Azure 存储，导致一个应用程序删除了另一个应用程序需要的文件。当然，这种情况也可能是恶意攻击所致，旨在造成损害。为了避免此类情况，我们可以在数据保护设置中启用Blob 软删除选项。

以下截图展示了一个示例：

图 6.2 – Blob 软删除

7天和365天。除了恢复已删除的文件外，Blob 软删除还使我们能够恢复文件的以前版本。如果文件被意外修改，或者我们因其他原因需要文件的先前版本，Blob 软删除可以帮助我们将文件恢复到任何时间点，只要它在有效保留期的时间范围内。

重要说明

Blob 软删除和保留期限从设置的那一刻起生效，并且无法追溯使用。例如，如果我们发现丢失了文件，然后启用此选项，它将无法帮助我们恢复丢失的文件。为了能够恢复文件，我们需要在事件发生之前就启用此选项。

Azure 中的数据是静态加密的，Azure 存储也不例外。但数据是使用 Microsoft 管理的密钥进行加密的，这在某些情况下可能不可接受。由于合规性和安全要求，我们必须控制用于加密的密钥。为了解决这些需求，微软启用了使用您自己的密钥（BYOK）选项。您可以在加密选项下启用使用您自己的密钥，如下图所示：

图 6.3 – Azure 存储加密选项

通过使用 Azure 密钥库启用 BYOK，其中用于存储加密的密钥存储在密钥库中。

一旦我们启用使用您自己的密钥，新的设置将会出现，我们需要提供密钥库信息。以下截图展示了一个示例：

图 6.4 – 使用自定义密钥的存储加密

我们可以提供一个统一资源标识符（URI），该 URI 包含有关将用于加密的密钥库和密钥的信息，或者我们可以使用第二个选项，允许我们从列表中选择可用的密钥库和密钥。这两种选项的结果是相同的，存储将会被加密。任何新增的文件将自动加密。任何现有的文件将通过后台加密过程进行追溯加密，但这个过程不会立即完成，现有数据的加密过程需要一些时间。

在 Azure 密钥库中可以轻松创建密钥，但我们也可以从硬件安全模块（HSM）导入现有密钥。这是为了进一步的安全性和合规性要求，并启用最终的密钥管理，其中加密密钥由专用的加密处理器保护。

Azure 存储中的加密不仅可以通过 Azure 门户提供，还可以通过使用 Azure PowerShell 实现。以下脚本将创建一个新的 Azure 存储帐户、密钥库和密钥，然后使用所有提供的资源来加密刚刚创建的 Azure 存储帐户：

New-AzResourceGroup -Name 'Packt-Encrypt' -Location 'EastUS'
$storageAccount = Set-AzStorageAccount -ResourceGroupName 'Packt-Encrypt' `
    -Name packtstorageencryption `
    -AssignIdentity
New-AzKeyvault -name 'Pact-KV-01' -ResourceGroupName 'Packt-Encrypt' `
-Location 'EastUS' `
-EnabledForDiskEncryption `
-EnableSoftDelete `
-EnablePurgeProtection
$KeyVault = Get-AzKeyVault -VaultName 'Pact-KV-01' -ResourceGroupName 'Packt-Encrypt'
Set-AzKeyVaultAccessPolicy `
    -VaultName $keyVault.VaultName `
    -ObjectId $storageAccount.Identity.PrincipalId `
    -PermissionsToKeys wrapkey,unwrapkey,get,recover
$key = Add-AzKeyVaultKey -VaultName $keyVault.VaultName -Name 'MyKey' -Destination 'Software'
Set-AzStorageAccount -ResourceGroupName $storageAccount.ResourceGroupName `
    -AccountName $storageAccount.StorageAccountName `
    -KeyvaultEncryption `
    -KeyName $key.Name `
    -KeyVersion $key.Version `
    -KeyVaultUri $keyVault.VaultUri 

另一个需要考虑的 Azure 存储问题是高级威胁保护（ATP）。此选项在高级安全性下启用，它将我们的安全性提升到一个新的水平。它利用安全智能来检测任何对我们数据的威胁，并提供建议以提高安全性。

存储帐户下的高级威胁保护刀片示例如下图所示：

图 6.5 – Azure 存储 ATP

ATP 将我们的安全设置与推荐的基准进行比较，并为我们提供可以实施的额外安全选项。第二部分是检测异常和潜在有害的访问或利用 Azure 存储的尝试。ATP 与 Azure 安全中心紧密相关，Azure 安全中心将在第七章中讨论，Azure 安全中心。但存储帐户并不是唯一与存储相关的 Azure 服务，几乎所有 Azure 服务都使用某种形式的存储。在这些服务中，我们有 Azure 虚拟机（VM）磁盘，接下来我们看看如何使这些更加安全。

理解 Azure 虚拟机磁盘

Azure 虚拟机是微软基础设施即服务（IaaS）的一部分，是很多用户在云端旅程初期遇到的服务。当用户需要对环境进行更多控制时，通常会选择 Azure 虚拟机，而其他服务无法提供如此控制。但更多的控制也意味着更多的责任。

除了在第四章中讨论的网络管理，Azure 网络安全，我们还需要解决如何处理 Azure VM 中的数据，主要是指磁盘。与所有其他数据一样，Azure 虚拟机的磁盘在静态时会进行加密，并且虚拟机使用 Azure 服务结构来安全访问这些磁盘上存储的内容。

但如果我们决定下载或导出这些机器使用的磁盘会发生什么呢？一旦磁盘离开 Azure，它将处于未加密状态，并且可以被任何方式使用。这就暴露了某些需要解决的安全漏洞。如果有人获得 Azure 访问权限（但没有虚拟机的访问权限）并下载磁盘会怎么样？如果有人决定将所有磁盘备份到不安全的地方呢？这些只是可能导致未经授权和恶意访问 Azure 虚拟机磁盘的一些情景。

幸运的是，我们可以选择使用 Azure 密钥库并启用进一步的磁盘加密。以这种方式加密的磁盘即使在导出、下载或以任何方式离开 Azure 数据中心后，依然保持加密状态。

如果我们进入 Azure 虚拟机并查看我们的磁盘，我们可以看到，默认情况下，磁盘加密没有启用。下面的截图展示了一个示例：

图 6.6 – Azure 虚拟机磁盘加密选项

我们需要使用 Azure 密钥库，并且需要将密钥存储在密钥库中。

我们可以使用 Azure PowerShell 启用 Azure 虚拟机磁盘的加密。这里提供了一个示例脚本：

New-AzResourceGroup -Name "Packt-Encrypt" -Location "EastUS"
$cred = Get-Credential 
New-AzVM -Name 'Packt-VM-01' `
-Credential $cred `
-ResourceGroupName 'Packt-Encrypt' `
-Image win2016datacenter `
-Size Standard_D2S_V3
New-AzKeyvault -name 'Pact-KV-01' `
-ResourceGroupName 'Packt-Encrypt' `
-Location EastUS `
-EnabledForDiskEncryption `
-EnableSoftDelete `
-EnablePurgeProtection
$KeyVault = Get-AzKeyVault -VaultName 'Pact-KV-01' -ResourceGroupName 'Packt-Encrypt'
Set-AzVMDiskEncryptionExtension -ResourceGroupName 'Packt-Encrypt' `
-VMName 'Packt-VM-01' `
-DiskEncryptionKeyVaultUrl $KeyVault.VaultUri `
-DiskEncryptionKeyVaultId $KeyVault.ResourceId
Get-AzVmDiskEncryptionStatus -VMName Packt-VM-01 -ResourceGroupName Packt-Encrypt 

该脚本创建了一个新的 Azure 虚拟机（VM）、一个新的密钥库以及一个新的密钥。创建的资源随后用于为刚创建的 Azure 虚拟机启用磁盘加密。最后，我们可以检查磁盘的状态，并验证它是否已成功加密。我们可以在 Azure 门户中验证磁盘是否已加密，如下图所示：

图 6.7– Azure 虚拟机门户

Azure 虚拟机的磁盘未加密：可以访问该磁盘，用于创建新的虚拟机（无论是 Azure 还是本地 Hyper-V），或者将其附加到现有的虚拟机。加密磁盘将阻止这种访问，除非用户可以访问在加密过程中使用的密钥库。

在 Azure SQL 数据库上工作

Azure SQL 数据库是微软的关系数据库云服务，属于平台即服务（PaaS）模型，通常被称为数据库即服务（DBaaS）。它具有高可用性并提供高性能的数据存储层。正因为如此，它通常是选择云数据库时的首选。

Azure SQL 数据库的设置中有一整节与安全性相关的功能。有四个不同的选项：

• 高级数据安全性

• 审计

• 动态数据掩码

• 透明数据加密

如果我们启用高级数据安全性，我们将获得一些优势：

• 漏洞评估设置

• 高级威胁防护设置

• 数据发现与分类

启用高级数据安全性的选项显示在以下截图中：

图 6.8 – Azure SQL 数据库高级数据安全性

这些选项中的每一个都有额外的配置，我们需要在使用高级数据安全性之前进行设置：

1. 漏洞评估设置需要 Azure 存储，数据将保存在此处，并根据当前状态提供安全建议。评估将手动执行，我们可以选择报告是否发送给特定用户，或者发送给所有管理员和订阅所有者。评估报告的格式如下：

   图 6.9 – Azure SQL 数据库评估结果

   漏洞评估将我们当前的设置与基准进行比较，并提供未满足的检查项列表。它还根据风险级别对检查项进行分类：高风险、中风险和低风险。

2. 高级威胁防护设置与 Azure 存储中的此选项非常相似：它能够检测任何异常和潜在的有害因素。与 Azure 存储相比，我们有一些额外的设置：我们可以选择要检测的威胁类型，并定义在检测到威胁时通知的对象。

   我们可以监控的威胁列表如下图所示：

   

   图 6.10 – Azure SQL 数据库高级威胁防护设置

   类似于漏洞评估设置，关于威胁的通知可以发送给特定用户或所有管理员和订阅所有者。

3. 高级数据安全性下的最终选项是数据发现与分类。此选项进行数据评估，并对任何应该保密的数据提供分类。评估是根据各种合规性和安全要求进行的，数据根据一个或多个标准被分类为保密。例如，我们可能有一些用户信息，需要根据通用数据保护条例（GDPR）进行分类。但在用户信息中，我们可能有社会安全号码或信用卡号码，这些信息根据许多其他合规性要求进行分类。数据发现与分类仅提供有关分类数据类型的信息，但由用户决定如何处理以及如何进行。

这引出了 Azure SQL 数据库中的下一个安全设置——动态数据屏蔽。过去，我们可以根据不同的层级，如数据库、模式、表或行，提供用户访问权限。但我们无法根据列提供访问权限。动态数据屏蔽改变了这一点，使我们可以为用户提供对表的访问权限，同时屏蔽用户不应访问的某些列。

例如，假设我们希望提供对客户表的访问权限，但用户不应能够访问客户的电子邮件地址。我们可以在电子邮件列上创建数据掩码，用户将能够看到所有信息，除了被掩码的列，该列将显示为掩码（对于常见数据类型有默认的掩码，但也可以创建自定义掩码）。对于被掩码的列，我们可以排除某些用户。所有管理员默认被排除，并且无法排除。下面的截图展示了动态数据掩码的一个示例：

图 6.11 – 动态数据掩码

动态数据掩码与数据发现与分类相连接。用户将根据数据发现与分类提供的信息获得数据掩码建议。

审计选项使我们能够定义各种日志的存储位置。有三个不同的选项可用：

• 存储

• 日志分析

• 事件中心

由于许多法规和安全合规标准要求存储访问和事件日志，这个选项使我们不仅能够保留审计日志，还能在需要时帮助我们理解和追踪事件。审计可以针对单个数据库或服务器级别启用。如果启用了服务器级审计，日志将会为该服务器上的所有数据库保留。

Azure SQL 数据库的最后一个安全设置是透明数据库加密（TDE）。TDE 是一种对静态数据进行加密的方法，它在页面级别对数据和日志文件进行实时加密和解密。它使用数据库加密密钥（DEK）对数据、相关备份和事务日志进行加密。

对于较旧的数据库，此设置未启用，TDE 状态为关闭，加密 状态为未加密。下面的截图展示了一个示例：

图 6.12 – Azure SQL 数据库 TDE 设置

对于较新的数据库，TDE 已经启用，且加密状态为加密，如下图所示：

图 6.13 – 使用 TDE 加密的 Azure SQL 数据库

我们可以通过为较旧的数据库开启 TDE 达到相同的效果。然而，这种方法使用 Microsoft 提供的密钥进行加密。如果我们需要遵循法规和安全合规标准，并且自行管理密钥，我们必须再次转向 Azure 密钥保管库。要使用来自 Azure 密钥保管库的自定义密钥启用 TDE，我们必须在服务器级别启用此设置。在 TDE 设置下，服务器下，我们可以开启使用您自己的密钥，如以下截图所示：

图 6.14 – 使用自定义密钥进行 TDE

一旦启用此选项，我们需要提供将使用的密钥保管库和密钥。可选地，我们可以将所选密钥设置为默认的 TDE 保护器。

启用使用来自密钥保管库的密钥来进行 TDE 不会在选定服务器上的每个数据库上启用 TDE。必须为每个数据库单独启用 TDE。如果服务器上未设置此选项，则启用数据库上的 TDE 将使用微软管理的密钥。如果在服务器级别启用此选项，则在数据库上启用 TDE 时，将使用已定义的来自密钥保管库的密钥。

可以使用 Azure PowerShell 设置加密，如以下示例脚本所示：

1. 我们需要定义执行的参数。这些参数将在整个脚本中使用，基本上在每一条执行的命令中都会用到：

   $RGName = 'Packt-Encrypt'$servername = 'packtSQL'$DBName = 'test'
   

2. 接下来我们需要登录到我们的 Azure 订阅：

   $cred = Get-Credential 
   

3. 我们将创建资源组、Azure SQL 服务器和 Azure SQL 数据库。

   $RG = New-AzResourceGroup -Name $RGName -Location 'EastUS'
   $server = Set-AzSqlServer -ResourceGroupName $RG.ResourceGroupName `
   -ServerName $servername `
   -AssignIdentity
   $server = New-AzSqlServer -ResourceGroupName $RG.ResourceGroupName  `
   -Location 'EastUS' `
   -ServerName $server.ServerName `
   -ServerVersion "12.0" `
   -SqlAdministratorCredentials $cred `
   -AssignIdentity
   $database = New-AzSqlDatabase  -ResourceGroupName $RG.ResourceGroupName `
   -ServerName $server.ServerName `
   -DatabaseName $DBName `
   -RequestedServiceObjectiveName "S0" `
   -SampleName "AdventureWorksLT"
   

4. 接下来，我们需要创建 Azure 密钥保管库，该密钥保管库将在数据加密过程中使用：

   New-AzKeyvault -name 'Pact-KV-01' -ResourceGroupName $RG.ResourceGroupName`
   -Location 'EastUS' `
   -EnabledForDiskEncryption `
   -EnableSoftDelete `
   -EnablePurgeProtection
   $KeyVault = Get-AzKeyVault -VaultName 'Pact-KV-01' `
   -ResourceGroupName $RG.ResourceGroupName
   

5. 现在我们需要设置密钥保管库访问策略，以启用加密并添加将用于加密数据的密钥：

   Set-AzKeyVaultAccessPolicy `
   -VaultName $keyVault.VaultName `
   -ObjectId $storageAccount.Identity.PrincipalId `
   -PermissionsToKeys wrapkey,unwrapkey,get,recover
   $key = Add-AzKeyVaultKey -VaultName $keyVault.VaultName `
   -Name 'MyKey' `
   -Destination 'Software'
   

6. 最后，我们将向 Azure SQL 服务器分配一个密钥，使用来自密钥保管库的自定义密钥启用 TDE，并使用该密钥加密数据库：

   Add-AzSqlServerKeyVaultKey -ResourceGroupName $RG.ResourceGroupName  `
   -ServerName $server.ServerName `
   -KeyId $key.Id
   Set-AzSqlServerTransparentDataEncryptionProtector -ResourceGroupName $RG.ResourceGroupName  `
   -ServerName $server.ServerName `
   -Type AzureKeyVault `
   -KeyId $key.Id
   Get-AzSqlServerTransparentDataEncryptionProtector -ResourceGroupName $RG.ResourceGroupName  `
   -ServerName $server.ServerName
   Set-AzSqlDatabaseTransparentDataEncryption -ResourceGroupName -ResourceGroupName $RG.ResourceGroupName  `
   -ServerName $server.ServerName `
   -DatabaseName $database.DatabaseName `
   -State "Enabled" 
   

如果数据库启用了 TDE，且使用的是 Microsoft 管理的密钥，那么在服务器级别启用我们自己的密钥时，系统不会自动将加密从 Microsoft 管理的密钥转移到我们自己的密钥。我们必须执行解密操作，并重新启用加密，以便使用来自密钥保管库的密钥。

总结

在完成网络和身份验证层的所有工作后，我们仍然需要做更多的工作并加密我们的云数据。但这就足够了吗？通常来说，这还不够，随后我们会发现自己需要做更多的事情。威胁变得越来越复杂，我们需要找到提升安全性的方式。在本章中，我们简要提到了 Azure 安全中心。它可能是能帮助我们创建安全云环境并在威胁和攻击发生之前将其阻止的唯一工具。

在下一章中，我们将讨论 Azure 安全中心如何利用安全智能成为 Azure 中的中央安全防护。

问题

1. Secure transfer required 选项会做什么？

   A. 强制数据加密

   B. 强制 HTTPS

   C. 强制 FTPS

2. 为了保护数据免于意外删除，需要启用什么？

   A. 数据保护

   B. 回收站

   C. Blob 软删除

3. Azure 存储中的数据是否默认加密？

   A. 是

   B. 否

4. Azure 虚拟机（VM）磁盘是否默认加密？

   A. 是

   B. 否

5. Azure SQL 数据库是否默认启用加密？

   A. 是

   B. 否

6. Azure 中的数据可以通过以下方式加密……

   A. 微软提供的密钥

   B. 用户提供的密钥

   C. 以上两者

7. Azure SQL 数据库中的数据可以通过以下方式进行限制……

   A. 数据分类

   B. 动态数据屏蔽

   C. 透明数据库加密（TDE）

第三章：安全管理

在本章中，你将学习如何监控 Microsoft Azure 的安全性，应用推荐措施，并在威胁发生之前进行检测。

本章包含以下章节：

第七章，Azure 安全中心

第八章，Azure Sentinel

第九章，技巧与窍门

第八章：第七章：Azure 安全中心

Azure 安全中心旨在成为一款工具，提供您混合云环境当前安全配置的统一概览，并告知您有关当前威胁和攻击的信息。

在本章中，我们将覆盖以下主题：

• 介绍 Azure 安全中心

• 安全评分和建议

• 自动化响应

• Azure 虚拟机的及时访问

• 高级云防御

介绍 Azure 安全中心

随着云计算成为现代 IT 世界的主要范式，许多好处伴随着这种新工作方式而来。IT 不再是目的本身，员工的生产力远远超过过去。但在保护现代 IT 环境方面，也出现了新的挑战。

在第三章，管理云身份，我们已经讨论了高级身份保护，并指出仅仅保护网络边界已不再足够，然而，云计算带来的一些其他主要安全挑战也值得关注。

如何确保保护您不断变化的云服务和应用程序？这是云计算的价值主张之一，实际上，可能最大的好处就是您可以轻松地在云环境中进行变更和适应。无论是定义缩略语连续集成（CI）/持续交付（CD），虚拟机（VM），还是定义缩略语扩展，或服务退役，云环境都在动态变化。但同时，主要挑战之一是跟踪这些变化，并确保公司服务始终符合其安全基准。

威胁态势正在演变，攻击变得愈发复杂。攻击者正在使用攻击自动化和规避技术，同时，他们利用帮助其在网络攻击链条上实施攻击的工具。因此，他们不再需要成为高度训练的技术专家，这导致了越来越多复杂的攻击，其中一些是网络钓鱼和凭证盗窃攻击。此外，攻击者还利用被劫持的计算机，通过机器人网络发起广泛传播的密码喷射攻击，这种攻击可能很难识别。

我们需要人类的专业知识、创造力和适应能力来对抗人类威胁行为者。问题是，安全技能短缺。目前，全球网络安全领域大约有 300 万个空缺职位，并且这一数字还在增加。这不仅包括网络威胁猎人，还包括专注于管理内部 IT 系统的安全工程师和管理员。

Azure 安全中心是一个提供两大主要解决方案的服务：

1. 作为云安全态势管理（CSPM）解决方案，Azure 安全中心不断提供关于所有云资源当前配置状态的信息，以避免安全方面的错误配置。

2. 作为云工作负载保护平台（CWPP），Azure 安全中心提供针对服务器的网络威胁防护，无论这些服务器运行在 Microsoft Azure、内网，还是其他云平台，同时也保护您在 Azure 中的云原生工作负载，例如密钥库、存储账户、SQL 数据库等，免受威胁：

图 7.1 – Azure 安全中心概览仪表板

中央 Azure 安全中心概览仪表板分为三个不同的区域：

• 政策与合规性

• 资源安全卫生

• 威胁防护

在政策与合规性部分，您将找到有关合规性和治理的所有信息。例如，订阅覆盖范围为您提供关于所有订阅中 Azure 安全中心注册状态的洞察。换句话说，您可以查看您的租户中是否存在未受 Azure 安全中心覆盖的 Azure 订阅。您还将看到您的总体安全评分，这是一个反映您环境保护状况的数字，表示保护得有多好（或多差）。最后，法规合规性是 Azure 安全中心的一部分，它将帮助您确保您的云环境符合诸如Azure CIS 1.1.0和ISO27001等法规。

Azure 安全中心的第二部分，资源安全卫生，是一个展示当前安全配置建议的区域。通过持续评估您的环境配置，Azure 安全中心会向您提供有关安全最佳实践的建议，帮助您保护环境。

在威胁防护部分，作为三个主要部分中的最后一部分，Azure 安全中心向您展示当前的安全警报与事件（这些是多个警报的累积，已结合背景呈现）：

图 7.2 – 安全警报与事件

您可以选择一个事件或警报，以获取更多关于背景信息以及每个警报的修复步骤，并可以触发一个 Azure 逻辑应用作为响应。例如，您可以创建一个逻辑应用，发送电子邮件或发布到 Microsoft Teams 频道。

注意：

Azure 安全中心是为负责保护（混合）企业基础设施的安全工程师和管理员设计的工具。它有助于实施安全最佳实践并提供安全概览。对于威胁狩猎和深入挖掘警报及事件，您最好使用 Azure Sentinel，这是一种 SIEM/SOAR 解决方案，我们将在第八章中讨论，Azure Sentinel。

现在，您已经对 Azure 安全中心及其概览仪表板有了一个快速的了解，让我们更深入地探讨一下它是如何在技术上运作的。

启用 Azure 安全中心

在利用 Azure 安全中心的第一步中，我们必须启用此服务并提供初始配置参数。在开始之前，有几个关键组件需要考虑。

Azure 安全中心基本上依赖于 Azure 日志分析及其相关工作区、智能安全图和 Azure 策略：

• 日志分析工作区用于存储各种日志信息，例如 Windows Server 安全事件日志或 Linux 服务器的 syslog 条目，也用于存储安全警报和其他信息。

• 智能安全图是一个基于 AI/ML 的后台，用于通过评估 Microsoft 产品和服务每天生成的数十亿个威胁信号来识别攻击和威胁。Azure 安全中心威胁防护部分中的警报和事件基本上是通过智能安全图生成的（以及依赖它并集成到 Azure 安全中心中的工具，如 Microsoft Defender ATP）。

• Azure 策略，我们在第二章中已经介绍过的服务，治理与安全，是 Azure 安全中心中的建议所依赖的。

Azure 安全中心有两种不同的定价层级：

• 免费

• 标准

使用 Azure 安全中心的免费层，您可以访问 Azure 安全评分，并持续评估当前配置以及为 Azure 资源提供安全建议。如果您还希望保护本地服务器或运行在其他公共云平台上的虚拟机，或者如果您想利用其他功能，如按需虚拟机访问、适应性应用控制和网络硬化、合规性仪表板、威胁防护等，您需要启用 Azure 安全中心的标准层。

标准层定价取决于您保护的资源，并按以下方式计算：

• 虚拟机和服务器：每个节点每月 $15

• Azure 应用服务：每个实例每月 $15

• PaaS SQL 服务器：每个服务器每月 $15

• 存储帐户：每 10,000 次存储事务 $0.02

• 虚拟机上的 SQL 服务器：免费（预览期间）

• 容器注册表：每个容器镜像 $0.29（预览定价）

• Azure K8s 服务：每个虚拟机核心每月 $2（预览定价）

  重要提示

  即使是 Azure 安全中心的免费层，Azure 日志分析的定价仍然适用。对于 Azure 安全中心的标准层也是如此，日志分析的定价将在 ASC 标准层费用的基础上计算。预览定价在相关服务正式发布后可能会发生变化（GA）。

在开始使用 Azure 安全中心之前，你必须定义每个 Azure 订阅所需的定价层，并将 Azure 安全中心连接到一个日志分析工作区。你可以通过导航到 Azure 安全中心门户，选择 定价与设置，在这里你可以为每个 Azure 订阅定义定价层和其他全局设置：

图 7.3 – 选择 Azure 安全中心定价层

在自动配置中，它启用 Microsoft 监控代理的自动安装：

图 7.4 – 启用自动配置

你还需要定义是否希望使用由 Azure 安全中心自动创建的默认日志分析工作区，或者是否希望使用现有的工作区：

图 7.5 – 选择你的日志分析工作区配置

在这一部分，你需要做的最后一个决定是关于你希望提交到配置的日志分析工作区的安全性和 AppLocker 事件日志文件的数量。你可以在以下选项之间进行选择：

• 无

• 最小

• 常见

• 所有事件

启用 Azure 安全中心后，我们可以开始享受它所提供的所有优势，并使 Azure 安全性变得更好。但 Azure 安全中心不仅限于云资源，还可以扩展到本地资源。接下来，我们将查看 Azure 安全中心提供的工具，这些工具使我们能够提高我们的安全态势。

Azure 安全评分与建议

像其他一些 Microsoft 企业云服务一样，例如 Azure AD 和 Office 365，Azure 安全中心现在也提供一个安全游戏化选项——Azure 安全评分。其思想是展示你在当前部署的 Azure 资源上可以达到的最大分数，以及你当前的安全评分是多少。得分越高，安全态势就越好。这就像是把云安全的复杂性简化成了一个简单的游戏：

图 7.6 – Azure 安全评分仪表板

安全得分仪表板为您提供了当前整体安全得分和按类别划分的安全得分的概览。如果您点击某个安全得分类别，您将看到该类别内的建议及其相应的安全得分影响。建议的安全得分影响越大，修复相应配置错误的优先级就越高。

提示

安全得分并不反映行业标准的安全基准；例如，超过 700 分（满分 1000 分）是安全的，低于 300 分则极为不安全。安全得分仅计算您可以根据当前已部署资源和已满足的建议所能获得的分数，就像玩游戏一样。

两个 Azure 环境的安全得分是无法直接比较的。您只能说，得分越高越好。如果您比较图 7.1：Azure 安全中心概览仪表板和图 7.6：Azure 安全得分仪表板，您会发现整体安全得分不一致（393/655 与 350/640）。这些截图显示的是相同的 Azure 环境，之间相隔 6 天。在此期间，有一些资源被删除，但没有其他配置更改。Azure 安全得分可以用于比较同一环境在不同时间点的安全水平。您的云配置的每一个变化都会影响整体安全得分，而 Azure 安全得分直接与建议相关。因此，您满足的建议越多，您的安全得分就会越高。现在，让我们继续查看建议，看看那里提供了什么。

与建议合作

在第二章，《治理与安全》中，您已经学习了监控在安全方面的重要性，以及如何利用策略为您的 Azure 环境创建保护措施。Azure 安全中心的一个优点是，一旦您访问 Azure 门户中的Azure 安全中心仪表板，其免费层会自动启用，安全策略、持续的安全评估和帮助您保护 Azure 资源的建议会自动包含在内。这些建议是安全最佳实践，可以在您的安全策略中启用或禁用，该策略依赖于您在第二章《治理与安全》中学习到的 Azure 策略服务。每个建议都涉及一个审核策略，如果某个资源未能遵守特定政策，建议仪表板将反映此失败资源：

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig_7.7.jpg)

图 7.7 – Azure 安全中心建议仪表板中的失败资源

单击建议之一时，您将看到该建议保护的描述和威胁。根据建议，您可以直接从 Azure 安全中心补救，或者您将获得有关手动补救步骤的信息。从前面截图中的 快速修复！ 按钮可以使几个建议的单击修复生效，其中之一是禁用所有存储帐户的不安全连接。

Azure 安全中心社区

此部分在 Azure 安全中心 (ASC) 刀片中包含一些非常有用的链接，可以帮助您扩展对 Azure 安全中心的使用。在社区论坛中，您可以查看各种公告、提问问题或查找先前发布的问题。社区博客提供了一些关于某些主题的详细描述和操作指南。用户声音为您提供了请求新功能或改进的机会。

Azure 安全中心社区部分中的一个有用链接是 Azure 安全中心 GitHub 仓库。该仓库包含仍在预览中的安全建议、Azure 策略自定义定义以进行规模管理、用于自动响应（警报或自动修复）的逻辑应用模板，以及以编程方式工具和 PowerShell 脚本形式的安全修复。这是一个社区仓库，因此每个人都有机会贡献。如果您撰写了模板、脚本或其他有用的内容，并认为它们可能对他人有帮助，请随时提交。

Azure 安全中心中的工作流自动化和部分

在开始工作流自动化之前，我们需要快速解释一下逻辑应用是什么。

Azure 逻辑应用 是一种云服务，帮助您安排、自动化和编排不同的任务、流程和工作流。它还提供与组织中不同应用程序、数据集、系统和服务集成的能力。这使得它在多种场景中非常有用，无论您是想创建重复的自动化任务，根据条件触发操作，还是连接不同的系统。

在使用逻辑应用与 Azure 安全中心时，我们可以利用工作流自动化来设置逻辑应用以响应 Azure 安全中心的警报。警报可以分为组、威胁和建议。根据警报，我们可以根据严重性和类型定义自动响应。

例如，我们可以设置一个逻辑应用，以便在 Azure 安全中心检测到暴力攻击时自动触发。我们需要创建一个工作流，根据检测到的威胁自动触发逻辑应用，如下图所示：

图 7.8 – 在工作流自动化中配置逻辑应用触发器

这只会为指定的逻辑应用程序设置一个触发器。我们仍然需要为响应配置一个逻辑应用程序。例如，我们可以发送一个通知，告知检测到暴力破解攻击。逻辑应用程序配置了许多连接器，我们可以设置其中一个或多个。常见的选项包括发送电子邮件通知或在 Teams 小组中发布消息：

图 7.9 – 配置警报以发布到 Teams 频道

这只是自动响应的一个示例。我们可以设置许多自定义操作，例如暂时禁用对受攻击资源的访问，或阻止来自攻击源的 IP 地址的访问。Azure 安全中心 GitHub 仓库提供了许多可用于自动化响应的模板和脚本。

政策与合规性

涵盖政策和合规性部分包含四个子部分：

• 覆盖范围

• 安全分数

• 安全策略

• 合规性要求

覆盖范围和安全分数部分提供了每个订阅的安全概况。覆盖范围部分显示了每个订阅启用的 Azure 安全中心计划，以及每个订阅覆盖的资源数量。安全分数部分可以在主仪表板上看到，但这次它提供了每个订阅的信息，显示每个订阅的分数。

安全策略部分帮助您定义 Azure 安全中心将发送何种类型的安全建议。默认情况下，建议将基于最常见的合规性标准和自定义 Azure CIS 进行。此设置可以在订阅级别进行，我们可以为不同的订阅设置不同的配置。

默认设置的示例如下图所示：

图 7.10 – 默认策略设置

默认启用的标准策略包括 Azure CIS 1.1.0、PCI DSS 3.2.1、ISO 27001 和 SOC TSP。还可以使用的额外行业和监管标准包括 NIST SP 800-53 R4、英国官方和英国 NHS、加拿大联邦 PBMM 以及 SWIFT CSP CSCF v2020。

除了行业和法规标准外，我们还可以创建适用于我们组织的自定义策略。通过自定义策略，我们可以根据特殊需求跟踪 Azure 环境中的事件。要创建自定义策略，我们需要定义一个应用此策略的订阅，并选择我们希望跟踪的定义。例如，我们可以设置一个策略，跟踪 SQL 托管实例是否启用了透明数据加密（TDE）并使用自定义密钥，或是否启用了 Azure 虚拟机的 Azure 备份。Azure 安全中心将跟踪定义订阅中的资源，并在策略未应用时发送通知。需要提到的是，这只会跟踪并发送通知，指出资源未符合政策要求。我们需要根据建议采取行动并进行更改，才能真正改变资源的状态并确保符合要求。

以下截图显示了自定义策略的示例：

图 7.11 – 创建自定义安全策略

通过安全策略，我们可以定义希望符合的行业标准（如果有的话）。在法规合规性下，我们可以看到在每个标准的评估中，我们的订阅情况如何。目前有四个标准可用：Azure CIS 1.1.0、PCI DSS 3.2.1、ISO 27001 和 SOC TSP。每个标准都有控制项，我们可以看到哪些控制项通过了，哪些失败了。总共有 330 个控制项在标准之间进行干预。法规合规性部分提供了所有控制项的概览，以及每个单独标准的控制项，如下图所示：

图 7.12 – 法规合规性概览

对于每个可用的标准，我们可以查看一个更详细的报告，包含通过和失败的控制项信息。与建议类似，我们也有一个需要采取的行动列表，以通过控制项测试。和建议一样，行动可以以我们需要手动执行的指令形式呈现，或者可以提供一个快速修复方案来解决问题。

以下截图显示了失败的控制项示例：

图 7.13 – 法规合规性概览

控制项仅作为指导，不能自动固定。失败的控制项列表是提醒我们需要解决和修复的问题，以便通过控制项测试。

资源安全卫生

本节提供了 Azure 安全中心建议的不同视图。该部分分为以下子部分：

• 建议

• 计算与应用

• 网络

• 物联网中心与资源

• 数据与存储

• 身份与访问

• 安全解决方案

推荐部分提供了与概述中相同的信息，其余子部分根据类型提供了子类别。例如，网络子部分仅提供与 Azure 网络服务相关的推荐，如网络安全组、网络接口、虚拟网络等。

最后的子部分，安全解决方案，启用了将第三方工具与 Azure Security Center 集成的功能。我们可以将非 Azure 服务器添加到 Azure Security Center 进行监控，将 Azure Security Center 日志发送到 SIEM，或添加 Web 应用防火墙或下一代防火墙。

许多公司和组织需要一个集中日志解决方案——SIEM（安全信息和事件管理）。所有具有自定义日志记录功能的产品和系统，以及能够帮助你识别整个组织中事件的集中解决方案，都是非常有用的。因此，将 Azure Security Center 收集的信息和日志发送出去的能力可能是一个非常重要的要求，尤其是对于大型组织和企业。一些可能与 Azure Security Center 集成的 SIEM 解决方案包括 IBM QRadar、Splunk、SumoLogic、ArcSight、Syslog 服务器、LogRhythm 和 Logz.io。

将非 Azure 虚拟机添加到 Azure Security Center 的选项实现了真正的混合云能力。Azure Security Center 为 Azure 虚拟机启用的安全增强功能可以扩展到几乎任何其他服务器，不论是在本地数据中心还是在其他云中运行。这使得我们可以在整个环境中进行高级威胁检测、警报和事件调查。

高级云防御

高级云防御提供了用于增强威胁缓解的附加工具。提供了四种附加工具：

• 自适应应用程序控制

• 即时虚拟机访问

• 自适应网络加固

• 文件完整性监控

自适应应用程序控制使您可以控制哪些应用程序可以在由 Azure Security Center 保护的服务器上运行。这适用于 Azure 虚拟机和非 Azure 虚拟机及服务器。我们可以通过仅允许特定的应用程序或类型的应用程序运行来控制服务器上可以运行的内容，并防止任何恶意或未经授权的软件运行。我们可以创建不同的组，以根据位置、操作系统和环境类型跟踪文件类型保护。服务器可以被添加到多个组，以跟踪不同的保护模式。以下截图展示了一个组的例子，用于保护位于美国区域的 Azure Windows 虚拟机，并为任何 EXE、MSI 或脚本启用审核选项：

图 7.14 – 自适应应用程序控制组设置

Azure 虚拟机管理是另一个需要非常认真对待的话题。最佳实践是只通过安全连接执行任何管理任务，使用 P2S 或 S2S 连接。另一种方法是使用一台虚拟机作为跳板，然后从该虚拟机进行管理。但即使在这种情况下，连接也必须是安全的。

即时虚拟机访问

Azure 虚拟机的即时访问（Just-in-Time，简称 JIT）用于阻止传入流量访问虚拟机，直到特定流量被暂时允许。这种方法通过缩小攻击面并启用访问来减少虚拟机的暴露风险。启用 即时访问（JIT）将阻止所有通常用于管理的端口上的传入流量，如 RDP、SSH 或 WinRM。用户必须明确请求访问，该访问将在指定时间内被授予，但仅限于已知的 IP 地址。这种方法与 特权身份管理（PIM）的使用方式相同，在 PIM 中，拥有权限并不意味着我们可以随时使用它们；我们必须激活/请求这些权限才能在一段时间内使用。

重要提示

Azure 虚拟机的 JIT 访问仅支持通过 ARM（Azure Resource Manager）部署的虚拟机。它不适用于非 Azure 虚拟机或通过 Azure 服务管理（ASR）部署的 Azure 虚拟机。

可以通过 Azure 安全中心或 Azure 虚拟机面板配置 JIT。为 Azure 虚拟机配置 JIT 需要定义一些参数，例如我们希望使用哪些端口、是否希望允许来自特定 IP 地址或 无类域间路由（CIDR）格式的 IP 范围的访问，以及访问可用的最大时间。

配置 JIT 的示例如下图所示：

图 7.15 – 配置 JIT 访问

默认情况下，我们可以使用最常见的管理端口。我们可以编辑这些端口的规则、删除规则或添加自定义规则。除了端口外，我们还可以更改协议、允许的来源以及最大请求时间（可以在 1 小时到 24 小时之间）。

一旦配置了 JIT，每次访问虚拟机时都需要请求访问。这同样可以通过 Azure 安全中心或 Azure 虚拟机面板进行。在请求时，我们可以要求打开特定（或多个）端口，指定是否希望从当前 IP 地址或 IP 范围启用访问，最后，我们需要定义时间范围。时间范围取决于配置。默认情况下，时间范围为 1 至 3 小时，但可以配置为最长 24 小时。

请求 JIT 访问的示例如下图所示：

图 7.16 – 请求 JIT 访问

JIT 使用 网络安全组（NSG）控制允许或阻止的流量。当 JIT 为 Azure 虚拟机配置时，会创建 NSG 规则来阻止通过配置端口的访问。未为 JIT 配置的端口应自动被阻止，除非另行配置。当请求 JIT 访问时，将临时创建另一个 NSG，允许在请求的端口上访问。新的 NSG 规则将具有更高的优先级，覆盖阻止规则以启用访问。一旦请求的时间到期，允许规则将被删除，访问将再次被阻止。

重要提示

如果正在使用 JIT，则不应手动创建管理端口的 NSG 规则。Azure 安全中心应该始终控制这些端口。如果我们手动创建规则，可能会覆盖 JIT 规则，或者我们可能会创建一个规则，始终允许某个管理端口的访问，同时对其余管理端口使用 JIT。这两种情况都会使 JIT 失去意义。

高级网络强化分析我们的流量通信模式。通过分析，判断 NSG 规则是否过于宽松，从而增加了攻击面并造成威胁。跟踪三种潜在威胁：恶意内部人员、数据泄露和数据外泄。Azure 安全中心报告所有威胁，并评估当前规则，以确定是否需要更改 NSG 规则，并提供增强安全性的建议。

文件完整性监控用于验证操作系统和应用软件的文件及注册表。它跟踪文件的更改，并将当前的文件校验和与上次扫描的相同文件进行比较，以检查是否有不同。该信息可用于判断更改是否有效或是恶意修改的结果。

威胁防护

威胁防护提供有关检测到的威胁的信息和报告。了解我们的资源情况以及是否有人对我们进行攻击是非常有用的。

重要提示

威胁防护不会自动执行任何操作；本部分仅提供信息。要对检测到的威胁采取行动，我们需要设置工作流自动化。

在威胁防护部分提供的信息可能会让人眼界大开。你可能并非目标对象，但仍然会因为成为机会的受害者或一时疏忽而被攻击。

举个例子，我们创建了一个实验，部署了五个 Azure 虚拟机，并将 RDP 端口通过私有 IP 地址暴露。这五个虚拟机都是空白的，没有数据，也没有任何特别之处。实际情况是，“坏人”扫描公共 IP 地址，希望能发现开放的端口。一旦检测到类似的情况，就会开始“暴力破解”攻击。暴力破解攻击使用最常见的用户名和密码组合尝试连接。这五个 Azure 虚拟机运行了一个月，每台虚拟机大约遭遇了 20,000 次攻击。

所有这些攻击都可以在 Azure 安全中心的威胁防护部分中进行追踪和查看。以下截图显示了一个报告的示例：

图 7.17 – 强力攻击检测到

在这些报告中，我们可以找到关于哪些用户名在攻击中被使用、攻击来源地以及身份验证尝试的次数等信息。我们还可以看到关于攻击来源地和攻击发生位置的更多信息，如下图所示：

图 7.18 – 强力攻击来源

总结

Azure 安全中心通过多种方式帮助我们保护云环境，从提供关于需要改进的建议，到在威胁发生时进行检测，再到自动响应可能的威胁。通过不同的设置和策略，我们可以定义我们的重点，跟踪资源健康状况，并创建更安全的基础设施。

本章中，我们讨论了 Azure 安全中心作为 云安全姿态管理（CSPM）和 云工作负载保护平台（CWPP）工具的重要性。下一章将重点介绍 Azure Sentinel，这是微软基于云的 SIEM/SOAR 解决方案。

问题

1. Azure 安全中心将数据存储在哪里？

   A. Azure 存储

   B. Azure SQL 数据库

   C. 日志分析工作区

2. Azure 安全中心具有以下哪些定价层？

   A. 免费

   B. 标准

   C. 高级

   D. 以上所有

   E. 仅限 1 和 2

   F. 仅限 2 和 3

3. 提供有关如何提高 Azure 安全性的信息的形式是？

   A. 修复

   B. 推荐

   C. 建议

4. 我们可以通过什么自动化响应 Azure 安全中心的警报？

   A. 日志分析

   B. 逻辑应用

   C. PowerShell

5. 不能通过自适应应用控制来控制的文件类型是？

   A. EXE

   B. JAR

   C. MSI

6. 当在 Azure 虚拟机上启用 JIT 时，用户会做什么？

   A. 具有相同的访问权限

   B. 访问权限较少

   C. 具有更多访问权限

   D. 必须请求访问权限

7. 使用高级威胁防护（ATP），当发生攻击时会发生什么？

   A. 它将被自动阻止。

   B. 用户需要对攻击创建响应。

   C. 一些攻击会被自动阻止，用户需要为不支持的攻击创建自定义响应。

第九章：第八章：Azure Sentinel

安全信息与事件管理（SIEM）结合了之前是分开的两个解决方案，安全信息管理（SIM）和安全事件管理（SEM）。

我们已经提到，大型组织依赖于 SIEM 解决方案。而微软的云端 SIEM 解决方案是 Microsoft Azure Sentinel。但首先，让我们回顾一下 SIEM 是什么，以及它应该具备哪些功能。

本章将涵盖以下主题：

• SIEM 简介

• 什么是 Azure Sentinel？

• 创建工作簿

• 使用威胁狩猎和笔记本

SIEM 简介

许多安全合规标准要求长期存储，其中与安全相关的日志应长期保存。这在不同的合规标准之间有所不同，可能是从 1 到 10 年的任意时间段。这就是 SIM 发挥作用的地方：长期存储所有与安全相关的日志，以便进行分析和报告。

当我们谈到 SEM 时，我们往往是在讨论实时数据流而不是长期事件追踪。SEM 的重点是实时监控；它的目标是通过通知和仪表板来关联事件。当我们将这两者结合时，我们就得到了 SIEM，它试图实时流式传输所有与安全相关的日志并进行长期保存。通过这种方法，我们可以在一个解决方案中实现实时监控和报告工具。

在讨论所需功能时，我们有一些 SIEM 必须勾选的检查项：

• 数据聚合：将不同系统中的日志集中存放在一个地方。这可以包括网络、应用、服务器和数据库日志等。

• 仪表板：所有聚合数据都可以用来创建图表。这些图表可以帮助我们直观地检测模式或异常。

• 警报：聚合数据会自动进行分析，任何检测到的异常都会成为警报。然后，警报会发送给需要了解或采取行动的个人或团队。

• 关联：SIEM 的职责之一是为常见的属性和事件提供有意义的关联。这也是数据聚合发挥作用的地方，因为它有助于识别不同日志类型之间的关联事件。数据库日志中的一行可能没有太多意义，但如果与网络和应用程序的日志结合，它可以帮助我们防止灾难发生。

• 保留：如前所述，合规要求之一是将数据保存较长时间。但这也有助于我们在较长时间内建立模式，并更容易检测异常。

• 取证分析：一旦我们意识到安全问题，SIEM 就会被用来分析事件，检测问题发生的方式和原因。这有助于我们消除损害并防止问题重复发生。

总结来说，SIEM 应具备实时接收不同类型数据的能力，能为接收到的数据提供意义，并能长期存储这些数据。接收到的数据将被分析以发现模式、检测异常，并帮助我们预防或解决安全问题。

那么，让我们看看 Azure Sentinel 如何满足这些需求。

开始使用 Azure Sentinel

Azure Sentinel 是微软的云端 SIEM 解决方案。随着云计算继续改变我们使用 IT 的方式，SIEM 必须进化，以应对 IT 变革带来的新挑战。Azure Sentinel 是一个可扩展的云解决方案，提供智能安全和威胁分析。除此之外，Azure Sentinel 还提供威胁可见性和警报功能，以及主动的威胁追踪和响应。

所以，如果我们仔细查看，所有的 SIEM 复选框都已勾选。

Azure Sentinel 的定价模型有两种选择：

• 按需付费：在按需付费模式下，计费是根据接收的每 GB 数据进行的。

  重要提示

  在撰写时，按需付费模型下每接收一个 GB 的价格为 $2.60。

• 容量预留：容量预留提供不同的层级和不同数量的预留数据。预留创建了一个承诺，即使我们没有使用预留容量，也会按照每个层级进行计费。然而，预留提供了接收数据的折扣，是预期会接收大量数据的组织的一个不错选择。

以下图表显示了在撰写时，Azure Sentinel 的容量预留定价：

图 8.1 – Azure Sentinel 定价

如果接收的数据超过了预留限额，超出部分将按照按需付费模型进行计费。例如，如果我们预留了 100 GB 的容量，但接收了 112 GB 数据，我们将按预留容量的层级价格支付前 100 GB，并为超过预留容量的额外 12 GB 支付费用。

启用 Azure Sentinel 时，我们需要定义一个用于存储数据的日志分析工作区。我们可以创建一个新的日志分析工作区，也可以使用现有的工作区。

Azure Sentinel 使用日志分析来存储数据。Azure Sentinel 的定价不包括日志分析的费用。

重要提示

对接收的数据将收取额外的日志分析费用。有关定价的信息，请访问 azure.microsoft.com/en-us/pricing/details/monitor/。

在以下截图中，我们可以看到在撰写时，Azure Sentinel 的所有定价选项：

图 8.2 – 更改 Azure Sentinel 定价层级

现在，让我们看看 Azure Sentinel 如何实现 SIEM 应该具备的所有功能。我们将逐一分析所有要求，看看它们如何通过 Azure Sentinel 得到满足。

让我们从数据连接器和数据保留配置开始，配置数据连接器和数据保留

SIEM 的要求之一是数据聚合。然而，数据聚合不仅仅是收集数据，还意味着能够从多个来源收集数据。Azure Sentinel 在这方面做得非常好，并且拥有许多集成的连接器。目前（并且不断有更多连接器被引入），共有 32 个连接器可用。大多数连接器是针对不同的 Microsoft 源，如 Azure Active Directory、Azure Active Directory Identity Protection、Azure Security Center、Microsoft Cloud App Security 或 Office365，仅举几例。但也有用于 Microsoft 生态系统外的数据源的连接器，如 Amazon Web Services、Barracuda 防火墙、Cisco、Citrix 和 Palo Alto Networks。

重要提示

有关连接器的更多信息，请参阅以下链接：docs.microsoft.com/en-us/azure/sentinel/connect-data-sources

数据连接器页面在以下截图中显示：

图 8.3 – Azure Sentinel 数据连接器

所有数据连接器都包括逐步说明，解释如何配置数据源以发送数据。值得一提的是，所有数据都存储在 Log Analytics 中。不同数据源的配置说明有所不同。大多数 Microsoft 数据源可以通过启用一个服务与另一个服务之间的连接来添加。其他数据源则需要安装代理或编辑端点配置。

Azure Sentinel 中有许多默认的连接器。除了显而易见的与 Azure 和 Office365 服务相关的 Microsoft 连接器外，我们还有许多用于本地服务的连接器。但这并不止步于此，还有许多其他连接器可用，如 Amazon Web Services、Barracuda、Cisco、Palo Alto、F5 和 Symantec。

一旦数据导入到 Log Analytics 并准备好在 Azure Sentinel 中使用，真正的工作就开始了。

使用 Azure Sentinel 仪表盘

在数据收集之后，下一步是使用各种仪表盘来展示数据。仪表盘通过关键绩效指标（KPIs）、指标和关键数据点来直观展示数据，以便监控安全事件。通过可视化展示数据有助于建立基准模式并检测异常。

下图显示了随着时间推移的事件和警报：

图 8.4 – 事件和警报仪表盘

在此截图中，我们可以看到基准是如何建立的。随着时间的推移，事件的数量保持相似。任何突然的增减都将被视为异常，需要进一步调查。

时间轴事件仪表盘使用指标来显示数据。但我们也可以使用关键绩效指标（KPIs）来创建不同类型的仪表盘。下图显示了数据源中的异常：

图 8.5 – 异常仪表板

这两个示例代表了启用 Azure Sentinel 后可用的默认仪表板。我们还可以根据要求和定义的关键绩效指标（KPI）创建自定义仪表板。

然而，这只是检测异常的第一步。我们还需要额外的步骤来自动化该过程。

设置规则和警报

仪表板的唯一问题是，它们只有在有人监视时才有用。数据以视觉形式展示，只有在我们时刻监控仪表板时，才能发现问题。但当没有人在监视时，会发生什么呢？对于这些情况，我们定义规则和警报。

使用规则，我们可以定义基线，并在任何类型的异常出现时发送通知（甚至自动响应）。在 Azure Sentinel 中，我们可以在分析面板上创建自定义规则，提供两种类型的规则：

• 第一类规则是Microsoft 事件创建规则，在此我们可以从一系列预定义的分析规则中进行选择。这里的规则包括Microsoft Cloud App Security、Azure Security Center、Azure Advanced Threat protection、Azure Active Directory Identity Protection和Microsoft Defender Advanced Threat Protection。唯一的其他选项是选择将要跟踪的事件的严重性。

• 第二类规则是计划查询规则。这里我们有更多的选项，可以定义几乎任何跟踪规则。我们唯一的限制是我们的数据。数据越多，我们可以跟踪的内容就越多。使用Kusto 查询语言，我们可以创建自定义规则并检查任何类型的信息，只要数据已经存在于日志分析工作区中。

要创建自定义查询规则，需要执行以下步骤：

1. 我们需要定义一个名称，选择战术，并设置我们想要检测的严重性。我们可以选择几种战术选项：初始访问、执行、持久性、特权升级、防御规避、凭证访问、发现、横向移动、收集、外泄、指挥与控制、以及影响。

   可选地，我们可以添加描述。建议添加描述，因为它可以帮助我们跟踪规则并检测它们的用途。以下截图展示了一个示例：

   

   let GetAllHostsbyAccount = (v_Account_Name:string){
     SigninLogs
     | extend v_Account_Name = case(
     v_Account_Name has '@', tostring(split(v_Account_Name, '@')[0]),
     v_Account_Name has '\\', tostring(split(v_Account_Name, '\\')[1]),
     v_Account_Name
     )
     | where UserPrincipalName contains v_Account_Name
     | extend RemoteHost = tolower(tostring(parsejson(DeviceDetail.['displayName'])))
     | extend OS = DeviceDetail.operatingSystem, Browser = DeviceDetail.browser
     | extend StatusCode = tostring(Status.errorCode), StatusDetails = tostring(Status.additionalDetails)
     | extend State = tostring(LocationDetails.state), City = tostring(LocationDetails.city)
     | extend info = pack('UserDisplayName', UserDisplayName, 'UserPrincipalName', UserPrincipalName, 'AppDisplayName', AppDisplayName, 'ClientAppUsed', ClientAppUsed, 'Browser', tostring(Browser), 'IPAddress', IPAddress, 'ResultType', ResultType, 'ResultDescription', ResultDescription, 'Location', Location, 'State', State, 'City', City, 'StatusCode', StatusCode, 'StatusDetails', StatusDetails)
     | summarize min(TimeGenerated), max(TimeGenerated), Host_Aux_info = makeset(info) by RemoteHost , tostring(OS)
     | project min_TimeGenerated, max_TimeGenerated, RemoteHost, OS, Host_Aux_info
     | top 10 by min_TimeGenerated desc nulls last 
     | project-rename Host_UnstructuredName=RemoteHost, Host_OSVersion=OS
     };
     // change <Name> value below
     GetAllHostsbyAccount('<Name>')
   

2. 一旦查询定义完成，我们需要创建计划。计划定义了查询的执行频率和执行所针对的数据。我们还定义了事件成为警报的阈值。例如，登录失败尝试只是一个事件。但如果该事件随着时间的推移重复出现，那么它就变成了警报。

   以下截图展示了一个计划和阈值的示例：

   

   图 8.8 – 分析规则调度

3. 在最后一步，我们可以定义当警报被触发时将会发生什么。类似于 Azure 安全中心中的工作流自动化（参见第七章，Azure 安全中心），逻辑应用被用于创建自动化响应。这些响应可以是通知（发送给用户或用户组）或自动化反应，能够阻止或防止威胁发生。

   创建新逻辑应用的示例如下图所示：

图 8.9 – 使用逻辑应用的自动化响应

但在现代网络安全中，这可能还不够。我们需要在几秒钟内做出响应，并且需要能够追踪与安全相关的特定事件。

创建工作簿

在 Azure Sentinel 中，我们可以使用工作簿定义我们想要监控的内容以及如何进行监控。类似于警报规则，我们可以选择使用预定义模板或创建自定义警报。与警报规则不同，使用工作簿时，我们创建仪表板以实时监控数据。

目前有 39 个模板可用，这个列表与数据连接器的列表非常相似。基本上，每个数据连接器至少有一个工作簿模板。我们可以选择以下屏幕截图中显示的任何模板：

图 8.10 – Azure Sentinel 工作簿模板

每个模板将启用一个额外的仪表板，用于定制监控特定的数据源。在下图中，我们可以看到 Azure 活动的仪表板：

图 8.11 – Azure 活动模板

故事并未就此结束。在 Azure Sentinel 中，我们可以利用机器学习并将智能嵌入到我们的安全层中。

使用威胁狩猎和笔记本

在 Azure Sentinel 中，借助仪表板和警报，我们可以查找异常和问题，但在现代 IT 中，我们需要更多的功能。网络威胁变得越来越复杂，传统的检测问题和威胁的方法已经不足够。等我们发现问题时，可能已经太晚了。我们需要采取主动，寻找潜在问题，并在威胁发生之前将其阻止。

对于威胁狩猎，Azure Sentinel 中有一个独立的部分。它允许我们创建自定义查询，同时也提供了一份广泛的预创建查询列表来帮助我们入手。主动威胁狩猎的一些查询包括高反向 DNS 计数、与 WannaCry 勒索病毒相关的域、失败的登录尝试、新登录的主机，以及异常登录等。以下屏幕截图中显示了部分可用查询列表：

图 8.12 – 威胁狩猎查询

我们还可以切换视图到实时流，并用它实时监控某些事件。实时流提供了图形化的视图，以帮助我们直观地监控威胁。

狩猎部分的另一个选项是书签。当我们在探索数据和寻找威胁时，可能会遇到一些不确定的事件。有些事件看起来无害，但与其他事件结合起来，可能会证明非常危险。书签允许我们保存某些查询的结果，以便稍后再次查看。我们可能希望在接下来的几天里检查相同的内容并比较结果，或者检查其他日志，看看是否能提供更多信息。

主动狩猎不仅仅停留在此。Azure Sentinel 还有一个叫做笔记本的功能。Azure Sentinel 是一个数据存储库，利用强大的查询和扩展性分析海量数据。笔记本更进一步，通过常用的 API，允许使用 Jupyter Notebooks 和 Python。这些工具扩展了我们在 Azure Sentinel 中存储数据的应用，使我们可以利用大量的机器学习、可视化和复杂分析库。

同样，我们已经有一些可用的笔记本，可以立即开始使用。可用查询的列表如下所示：

图 8.13 – Azure Sentinel 笔记本

Azure Sentinel 不仅仅是一个拥有有限选项的工具，它也非常可定制。可以通过多种方式调整 Azure Sentinel 以满足你的具体需求和要求。还有许多外部资源可以使用或进一步调整。

使用社区资源

Azure Sentinel 的强大功能由其社区进一步扩展。在 github.com/Azure/Azure-Sentinel 上有一个 Git 仓库。在这里，我们可以找到许多可以使用的附加资源。由社区开发的资源提供了新的仪表盘、狩猎查询、探索查询、自动响应的操作手册等，还有更多功能。

社区资源库是一个非常有用的资源集合，我们可以用它来扩展 Azure Sentinel 的功能，进一步提高安全性。

总结

Azure Sentinel 满足 SIEM 所有要求。不仅如此，它还通过主动威胁狩猎、机器学习和预测算法等额外工具增强了功能。结合我们已覆盖的其他资源，现代安全的各个方面已经涵盖，从身份与治理，到网络与数据保护，再到健康监控、问题检测和威胁预防。

但安全性不仅仅止步于此。几乎所有 Azure 资源都启用了某些安全选项。这些选项可以帮助我们进一步提高安全性。考虑到今天周围的网络安全威胁，我们需要采取一切可用的预防措施。

在最后一章中，我们将讨论安全最佳实践以及如何利用每个安全选项来为我们服务。

问题

1. Azure Sentinel 是…

   A. 安全事件管理（SEM）

   B. 安全信息管理（SIM）

   C. 安全信息事件管理（SIEM）

2. Azure Sentinel 存储数据在…

   A. Azure 存储

   B. Azure SQL 数据库

   C. 一个日志分析工作区

3. Azure Sentinel 支持哪些数据连接器？

   A. Microsoft 数据连接器

   B. 云数据连接器

   C. 来自不同供应商的多种数据连接器

4. 在 Azure Sentinel 中使用的是哪种查询语言？

   A. SQL

   B. GraphQL

   C. Kusto

5. Azure Sentinel 中的仪表板用于…

   A. 问题的可视化检测

   B. 持续监控

   C. 威胁预防

6. Azure Sentinel 中的规则和警报用于…

   A. 问题的可视化检测

   B. 持续监控

   C. 威胁预防

7. 威胁狩猎是由…执行的

   A. 监控仪表板

   B. 使用 Kusto 查询

   C. 使用 Jupyter Notebook 分析数据

第十章：第九章：安全最佳实践

本书已经涵盖了关于 Azure 安全的最重要话题，从治理与监控到身份、网络和数据保护，再到具体工具如 Azure 安全中心和 Azure Sentinel。在本章最后，你将找到一些作者在项目中定期使用的技巧和窍门。

我们将在接下来的部分中讨论以下主题：

• 日志分析设计考虑因素

• 了解 Azure SQL 数据库的安全功能

• Azure 应用服务的安全性

日志分析设计考虑因素

你已经学到 Azure 安全中心和 Azure Sentinel 在很大程度上依赖于 Azure 日志分析。但在开始你的云安全监控之旅之前，有一些重要的事项需要考虑。

在这个背景下，最重要的两个范式是：

• 尽可能使用最少的日志分析工作区

• 使用区域性工作区以避免 Azure 带宽费用

从技术角度来看，最好的做法是只使用一个单一的中央工作区，这样所有数据都集中在一个地方。拥有一个单一工作区，你可以轻松、高效、快速地将数据关联起来，从而获得相应的洞察。同时，你只需要关注这个工作区的基于角色的访问控制（RBAC）模型。然而，细粒度的 RBAC 模型需要更多的努力。

然而，从财务角度来看，如果你在不同的 Azure 区域使用 Azure 资源，你应该规划区域性工作区，而不是中央工作区。对于本地服务器来说，规划布局并不重要，因为所有进入网络流量（ingress）进入 Azure 区域是免费的。Microsoft Monitoring Agent 会将数据发送到 Azure，但并没有定期的数据从 Azure 传输到本地服务器。问题是，你需要为出去的流量（egress）支付费用。如果你使用一个单一的中央日志分析工作区，并且在不同的 Azure 区域部署了 Azure 虚拟机（VMs），那么这些虚拟机到工作区的外出数据传输将产生流量费用。

为了将这两种范式结合起来，最好的做法是在每个使用的 Azure 区域创建一个单一的工作区，这不仅可以避免定期的流量费用，还能坚持尽可能少使用工作区的理念。

如果你使用多个工作区，则无法再在 Azure 安全中心使用自动配置。由于自动化过程，每个订阅只能配置一个工作区。由于 Azure 订阅可以包含来自所有或至少几个 Azure 区域的资源，因此根据你的策略，你需要另一种方式来自动部署 Microsoft 监控代理到你的 Azure 虚拟机。这时，基础设施即代码（IaC）就派上用场了。通过 Azure 资源管理器（ARM）模板、Terraform 或 PowerShell，你可以同时部署 Azure 虚拟机并安装日志分析虚拟机扩展。日志分析虚拟机扩展通过 ARM 进行部署和管理，并且完全支持 DevOps 场景中的 CI/CD 管道。也就是说，当你在 DevOps 场景中使用 IaC 部署虚拟机时，你还可以通过管道更新、管理和配置代理。如果你还配置了策略、蓝图以及在第二章《治理与安全》中学习到的所有其他治理功能，你就能轻松遵循企业的安全策略，并同时利用自动化。

接下来，我们将查看其他 Azure 服务的安全功能以及它们如何帮助我们增强安全性。

了解 Azure SQL 数据库的安全功能

有关 Azure SQL 数据库的一些安全功能在第六章《数据安全》一节中提到，我们讨论了数据安全。但是，还有其他额外的功能可以帮助我们增强安全性。

当谈到 Azure SQL 数据库时，第一个特点和防线就是防火墙。这个内置工具默认会阻止来自任何未预授权（白名单）的 IP 地址访问数据库。值得一提的是，防火墙设置是在 Azure SQL 服务器级别进行的，并且会继承到该服务器上的所有数据库。如果我们需要允许某个 IP 地址访问单一数据库，我们可能需要重新考虑我们的资源策略。允许一个 IP 地址访问单一数据库将会允许该 IP 地址访问同一服务器上的所有数据库。因此，我们需要考虑将仅由相同应用程序或相同用户组使用的数据库放在同一服务器上。

允许新的 IP 地址连接到 Azure SQL 服务器可以通过 Azure SQL 服务器防火墙设置进行。我们可以选择添加一个单独的 IP 地址（起始和结束 IP 地址相同），或者添加一段 IP 地址范围（从起始 IP 到结束 IP）。如果我们想允许当前的 IP 地址，有一个方便的添加客户端 IP按钮。这个按钮会自动检测我们当前的 IP 地址，并添加一个新的规则来允许该 IP 地址。添加任何规则后，我们需要保存更改才能使其生效。

以下图展示了防火墙设置的一个示例：

图 9.1 – Azure SQL 服务器防火墙设置

在 防火墙 设置 下，有两个额外的选项可供使用：

• 允许 Azure 服务和资源访问此服务器

• 来自 VNET/Subnet 的连接

允许 Azure 服务的选项看起来很有吸引力，但我们需要非常小心。乍一看，这个选项似乎很有帮助，大多数人可能会认为应该允许 Azure 服务连接。当我们不必担心 Web 应用如何连接到数据库时，生活会变得更轻松。但这个选项并不是只允许你的 Azure 服务连接，它允许任何 Azure 服务连接。允许 Azure 服务和资源连接仅会检查连接是否来自 Azure 数据中心，而不会将连接限制在你的订阅或租户内。允许此选项将使 Azure SQL 数据库更加脆弱，我建议你保持此选项关闭。

重要提示

允许 Azure 服务和资源访问此服务器 默认设置为 关闭，但之前并非如此。以前，该设置是默认启用的。如果你已经创建了 Azure SQL 数据库，请确保禁用此设置。

从 VNET/Subnet 的连接允许我们通过让特定的 VNET（或仅限子网）连接到 Azure SQL 数据库来创建 VNET 集成。这种方法更加安全，因为数据库无需通过互联网公开，所有通信都在安全的私有网络上进行。

但 Azure SQL 数据库只是服务级别内置安全功能的一个例子。几乎每个服务都有一些服务特定的安全功能。Azure 应用服务是另一个很好的例子，提供了许多可用的安全选项，接下来我们将讨论这些选项。

Azure 应用服务中的安全性

Azure 应用服务是一个基于 HTTP 的服务，用于托管 Web 应用程序和 API，支持多种编程语言。它也是 Azure 服务的另一个很好的示例，内置了多种安全功能。我们可以控制访问、协议、证书和许多其他事项。

我们需要解决的第一个问题是身份验证。应用服务允许我们基于几个不同的提供者设置身份验证：Azure Active Directory（Azure AD）、Microsoft（或 Live）帐户、Facebook、Google 和 Twitter。显然，最佳的集成方式是使用 Azure AD，因为它是本地的，并且还允许通过 Azure AD 工具和功能进行进一步控制。

为了为应用服务设置 Azure AD 身份验证，我们需要执行以下操作：

1. 在 应用服务身份验证 刀片中，我们需要选择 Azure Active Directory，如以下图所示：

   图 9.2 – Azure 应用服务身份验证

2. 在身份验证设置中，我们有两个选项。如果选择Express，这将自动为我们创建一个服务主体和所有所需的权限。如果选择高级设置，我们需要自己提供服务主体并创建权限。下图展示了Express设置的示例：

   图 9.3 – 应用服务 Azure AD 身份验证

3. 配置完成后，我们需要确保用户必须使用Azure Active Directory 登录才能访问应用程序，如下图所示：

   图 9.4 – 强制执行 Azure AD 登录

4. 访问应用程序时，用户将被提示使用其 Azure AD 账户登录以继续，如下图所示：

图 9.5 – 用户需要登录才能访问应用程序

Azure 应用服务的另一组安全特性是协议 设置。在这里，我们可以强制应用程序仅使用 HTTPS，控制最小的 TLS 版本，或者是否需要传入的客户端证书。我们还可以配置TLS/SSL 绑定，以指定在响应特定主机名请求时使用的证书。可以使用公有和私有证书：

图 9.6 – 应用服务协议设置

私有证书可以从应用服务导入（到特定的 Web 应用），上传，或从 Azure Key Vault 导入，或者我们可以创建一个新的应用服务管理证书。

注意

应用服务管理证书适用于应用服务上的所有 Web 应用，而不仅仅是它创建时所在的 Web 应用。

在下图中，我们可以看到私钥证书设置：

图 9.7 – 应用服务私钥证书

公钥证书要求由受信任的证书授权机构（CA）签发的证书。此证书通常用于公开访问的 Web 应用，并作为网站可信的证明：

图 9.8 – 公钥证书

在应用服务的网络设置下，我们有多个选项。大多数选项与安全连接和 Web 应用与私有网络的集成相关。此前在第四章《Azure 网络安全》中，我们已经讨论过网络安全。我们可以通过 VNET 集成和混合连接来实现这一点。此外，本节还包括启用 Azure Front Door（作为全球分布式应用程序的 Web 应用防火墙）和内容分发网络（CDN）等服务的选项。网络设置下的最后一个选项是访问限制。与 Azure 应用服务相关的所有网络设置如下面的图所示：

图 9.9 – Azure 应用服务网络设置

访问 限制是Azure 应用服务设置中的一个非常有用的功能。通过使用访问 限制，我们可以阻止来自特定 IP 地址的访问，或仅允许来自白名单 IP 地址的访问。实际上，访问限制的工作方式与网络安全组（NSGs）非常相似，通过创建规则并为其分配优先级。然而，访问限制专注于公共访问，而 NSGs 则控制更广泛的网络，包括公共和私有网络规则。在下图中，我们可以看到创建阻止规则的示例：

图 9.10 – 应用服务访问限制

要创建一个阻止规则，我们需要提供以下信息：

• 名称

• 操作（允许或拒绝访问）

• 优先级

• 描述

• 类型（IPv4 或 IPv6）

• IP 地址块

在前面的示例中，创建了一个规则来阻止来自 IP 地址块208.130.0.0/16的访问。如果有人尝试从指定 IP 地址范围内的任何 IP 地址访问应用程序，请求将被阻止，用户将无法访问该 Web 应用程序。

由于我们可以使用优先级，我们也可以采用不同的方法，仅允许来自白名单 IP 地址的访问。在这种情况下，我们将创建一个阻止规则，阻止任何人访问应用程序，并为其分配200。另一个规则将被创建，允许来自特定 IP 地址范围的访问，并为其分配100（这可以是200以下的任何值）。允许指定 IP 地址的规则将覆盖阻止规则，因为其优先级较高。但它仍然会阻止其他任何人访问应用程序。

我们在云环境中面临的另一个挑战是密钥管理。我们需要小心如何使用机密、连接字符串和其他敏感信息，并确保这些信息不会暴露。如本书中许多已讨论的情况一样，Azure Key Vault 可以提供帮助。类似于使用 IaC 传递机密（如在第五章中讨论的，Azure Key Vault），或者管理密钥和证书（在第六章中讨论的，数据安全），Azure Key Vault 可以用来保护 Azure App Service 所需的任何敏感信息。我们不需要将敏感信息存储在 Web 配置文件或 App Service 配置中（虽然信息会被隐藏，但如果用户有足够权限，仍然可能会暴露），而是可以使用托管身份来访问 Azure Key Vault，在那里敏感信息以安全的方式存储。以下是 App Service 中身份设置的示例：

](https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/ms-az-sec/img/Fig_9.11.jpg)

图 9.11 – Azure App Service 中的托管身份

如我们所见，可以设置两种类型的托管身份：系统分配和用户分配。系统分配将生成一个托管身份并设置必要的选项。而在用户分配中，我们需要自己创建托管身份，并创建任何必要的权限和设置。如果我们需要为一个服务使用多个托管身份，就必须使用用户分配的托管身份，因为一个服务只能拥有一个系统分配的托管身份。

系统分配的托管身份与资源生命周期相关，一旦资源被移除，托管身份也会被移除。该托管身份是为了服务而生成的，并且不会被其他任何服务使用。而用户分配的托管身份则不同，因为多个资源可以使用同一个托管身份。

总结

在本书的最后，我们已经涵盖了 Microsoft Azure 安全性的各个方面。从共享责任模型到高级安全功能，我们已经讲解完毕。需要记住的是，云环境不断变化，越来越多的服务可以帮助我们提高安全性。

让我们专注于本书中最重要的要点：

• 使用一切可用的手段确保你的身份和机密安全。

• 在访问控制方面，采取两种方法：足够的管理权限（JEA）和及时管理（JIT 管理）。

• 如果没有必要，任何东西都不应该暴露给公共访问，特别是管理和安全访问。

• 数据应该始终加密。

• 所有通信和流量都应加密（通过 HTTPS）并尽可能在安全（私有）网络上进行。

• Azure 安全中心和 Azure Sentinel 可以帮助你进行分析、检测和推荐，以保持对云安全的掌控，并确保 Azure 资源的安全。

• 除了专注于安全的服务外，所有 Azure 服务都具有自己的安全功能。使用这些功能来增强安全性。

Microsoft Azure 时刻在变化；新功能几乎每天都会添加，现有功能也在不断更新。因此，未来选项可能会发生变化，但这些选项现在是为了展示如何处理云安全的问题。这七个关键点是我们需要关注的；我们完成这些任务的方式并不重要。

问题

1. 什么是 Log Analytics 的最佳实践？

   A. 使用单一工作区

   B. 使用区域工作区

   C. 为每个区域和每个服务使用多个工作区

2. 我们可以通过…控制对 Azure SQL 数据库的访问

   A. 访问列表

   B. 防火墙

   C. 条件访问

3. 在 Azure 应用服务中支持哪种类型的证书？

   A. 私有

   B. 公共

   C. 通配符

   D. 以上所有

   E. 仅 1 和 2

   F. 仅 2 和 3

4. 我们可以通过…控制对 Azure 应用服务的访问

   A. 访问限制

   B. 防火墙

   C. 条件访问

5. 用于启用 App Service 与其他 Azure 服务通信的是什么？

   A. 服务主体

   B. 托管身份

   C. Azure 密钥保管库

6. Azure 应用服务支持与…的身份验证

   A. Azure Active Directory (Azure AD)

   B. Microsoft 帐户

   C. Twitter

   D. 以上所有

   E. 仅 1 和 2

   F. 仅 2 和 3

7. 可以从…设置 Azure 的安全性

   A. Azure 安全中心

   B. Azure Sentinel

   C. 不同的服务和功能

   D. Azure AD

进一步阅读

• 《Hands-On Cloud Administration in Azure》 由 Mustafa Toroman 编著: www.packtpub.com/virtualization-and-cloud/hands-cloud-administration-azure。

• 《Azure 管理手册》 由 Kamil Mrzyglod 编著: www.packtpub.com/cloud-networking/azure-administration-cookbook。

• 《Active Directory 管理手册》 由 Sander Berkouwer 编著: www.packtpub.com/virtualization-and-cloud/active-directory-administration-cookbook。

• 《Azure 网络管理手册》 由 Mustafa Toroman 编著: www.packtpub.com/virtualization-and-cloud/azure-networking-cookbook。

• 《Hands-On Azure for Developers》 由 Kamil Mrzyglod 编著: www.packtpub.com/virtualization-and-cloud/hands-azure-developers。

第十一章：评估

第一章：Azure 安全简介

以下是本章中问题的示例答案：

1. 答案 C. 责任是共享的

2. 答案 B. 云提供商

3. 答案 B. 云提供商

4. 答案 C. 取决于服务模型

5. 答案 A. 用户

6. 答案 D. 两者都对，但 Q10 正在替换 DLA

7. 答案 C. 客户会收到通知

第二章：治理和安全

以下是本章中问题的示例答案：

1. 答案 D. 以上所有

2. 答案 D. 取决于部署方法

3. 答案 C. 管理锁

4. 答案 B. 管理组

5. 答案 B. 订阅

6. 答案 C. 以上两者都对

7. 答案 B. 用于收集信息的服务

第三章：治理和安全

以下是本章中问题的示例答案：

1. 答案 A. 更容易受到攻击

2. 答案 C. 密码保护

3. 答案 C. 多重身份验证（MFA）

4. 答案 A. 是

5. 答案 C. 受感染用户

6. 答案 C. 启用权限

7. 答案 C. 无密码

第四章：Azure 网络安全

以下是本章中问题的示例答案：

1. 答案 B. 网络安全组（NSG）

2. 答案 B. 站点到站点

3. 答案 C. 以上两者都对

4. 答案 B. 服务端点

5. 答案 E. 1 和 3 是正确的

6. 答案 B. Web 应用防火墙（WAF）

7. 答案 C. 分布式拒绝服务（DDoS）

第五章：Azure Key Vault

以下是本章中问题的示例答案：

1. 答案 D. 以上所有

2. 答案 B. 访问策略

3. 答案 A. 服务主体

4. 答案 A. EnabledForDeployment

5. 答案 B. EnabledForTemplateDeployment

6. 答案 C. EnabledForDiskEncryption

7. 答案 C. 引用 Azure Key Vault

第六章：数据安全

以下是本章中问题的示例答案：

1. 答案 B. 强制启用 HTTPS

2. 答案 C. Blob 软删除

3. 答案 A. 是

4. 答案 B. 否

5. 答案 B. 否

6. 答案 C. 以上两者都对

7. 答案 C. 透明数据库加密（TDE）

第七章：Azure 安全中心

以下是本章中问题的示例答案：

1. 答案 C. Log Analytics 工作区

2. 答案 E. 只有 1 和 2

3. 答案 B. 推荐

4. 答案 B. 逻辑应用

5. 答案 B. JAR

6. 答案 D. 必须请求访问

7. 答案 B. 用户必须创建对攻击的响应

第八章：Azure Sentinel

以下是本章中问题的示例答案：

1. 答案 C. 安全信息事件管理（SIEM）

2. 答案 C. 一个 Log Analytics 工作区

3. 答案 C. 来自不同供应商的多种数据连接器

4. 答案 C. Kusto

5. 答案 A. 直观地检测问题

6. 答案 B. 持续监控

7. 答案 C. 使用 Jupyter Notebook 分析数据

第九章：安全最佳实践

以下是本章中问题的示例答案：

1. 答案 B. 使用区域工作区

2. 答案 B. 防火墙

3. 答案 D. 以上所有

4. 答案 A. 访问限制

5. 答案 B. 管理身份

6. 答案 D. 以上所有

7. 答案 C. 不同的服务和功能

第十二章：你可能喜欢的其他书籍

如果你喜欢这本书，你可能对 Packt 出版的其他书籍感兴趣：

![掌握 Adobe Photoshop Elements

](https://www.packtpub.com/virtualization-and-cloud/azure-networking-cookbook)

Azure 网络烹饪书

穆斯塔法·托罗曼

ISBN: 978-1-7898-002-27

• 学习如何创建 Azure 网络服务

• 理解如何创建并操作混合连接

• 配置和管理 Azure 网络服务

• 学习如何在 Azure 中设计高可用性网络解决方案

• 探索如何监控和故障排除 Azure 网络资源

• 学习将本地网络连接到 Azure 虚拟网络的不同方法

Azure 云管理实战

穆斯塔法·托罗曼

ISBN: 978-1-78913-496-4

• 理解 IaaS 和 PaaS 的概念

• 学习 Azure 解决方案的设计模式

• 在 Azure 中设计数据解决方案

• 探索 Azure 中混合云的概念

• 在云中实现 Azure 安全

• 使用基于脚本的工具创建和管理 Azure 资源

留下评论 - 让其他读者了解你的想法

请通过在购买书籍的网站上留下评论与他人分享你对本书的想法。如果你是从亚马逊购买的，请在该书的亚马逊页面上给我们留下真实的评论。这对于其他潜在读者来说非常重要，他们可以通过你的公正意见做出购买决策，我们也可以了解客户对我们产品的反馈，作者们也能看到你对他们与 Packt 合作创作的书籍的反馈。只需几分钟时间，但对其他潜在客户、我们的作者和 Packt 都有很大价值。感谢你！