Azure 云管理实用指南（二）

原文：annas-archive.org/md5/649587b180cdb9f8a1b502e61a720011

译者：飞龙

协议：CC BY-NC-SA 4.0

第六章：Azure Storage、备份和站点恢复 - 将数据迁移到 Azure

本章将重点讨论将数据迁移到 Azure。我们将从 Azure Storage 开始，因为它是 Azure 中最重要的服务之一。一切从 Storage 开始，了解它的使用非常重要。我们将讨论如何使用 Azure Storage 进行备份，以及如何将工作负载迁移到云端。此外，我们还将讨论如何使用Azure 备份和Azure 站点恢复（ASR）加快迁移过程，并将数据迁移到 Azure。

本章将涵盖以下主题：

• Azure Storage

• Azure 备份

• Azure 站点恢复

创建高可用性的 Azure SQL 数据库

创建 SQL Server 高可用性解决方案可能会非常复杂，配置困难，维护和管理起来更是困难重重。而 Azure SQL 数据库的高可用性则容易得多，几乎不需要维护。

我们需要从 Geo-Replication 开始。地理复制刀片显示了世界地图，并标示了当前数据库所在的以及所有可供复制的数据中心。当前数据库所在的数据中心用蓝色标记。建议用于复制的数据中心用紫色标记（这是离当前数据中心最近的数据中心），其他所有可用数据中心用绿色标记。在地图上，您可以看到有关当前数据库的信息，该数据库将是我们的主数据库。以下是地理复制刀片的示意图：

要创建新的数据库副本，我们可以在地图上选择任何数据中心来启动新的刀片。将打开“创建辅助刀片”，在其中我们需要提供目标 SQL Server（如果选定位置没有该服务器，则创建新服务器）。数据库名称将与原始名称相同，并且数据库将处于只读模式。定价层次将与原始相同，但您可以将层次更改为另一个值。创建辅助数据库所需的设置示例如下所示：

部署完成后，地图会发生变化，显示主数据库和辅助数据库之间的连接。部署时间取决于数据库的大小。

在部署过程中，空数据库会在辅助数据中心创建，然后数据从主数据库复制到辅助数据库。以下是实施复制后的地图示例：

然而，请注意，这只是创建主数据库的可读副本。在灾难发生或主数据库不可用的情况下，辅助数据库必须手动从只读模式切换为读/写模式，并且所有连接字符串必须手动更改。这实际上并不能算作高可用性解决方案，因此我们需要通过创建故障切换组来采取额外的步骤。

在故障转移组面板中，我们需要提供主服务器、备用服务器、故障转移组名称、读/写故障转移策略以及读/写宽限期（小时）。故障转移组名称必须唯一，这将成为连接到数据库的新端点。连接到故障转移组名称时，只要主服务器可用，连接将自动指向主服务器。

如果主服务器不可用，所有指向故障转移组名称的连接将会自动指向备用服务器。所有故障转移和故障恢复过程都将自动进行，无需用户操作。这里展示了故障转移组选项的截图：

如您所见，创建 Azure SQL 数据库高可用性解决方案简单快捷。创建后无需用户操作，故障转移和故障恢复都会自动进行。如果您曾在本地环境中创建过类似的解决方案，您可能知道故障恢复过程有多复杂。

Azure SQL 数据库安全

对于数据而言，安全性非常重要（并非其他资源可以忽视安全性）。在 Azure SQL 数据库面板下，我们有一组与安全性相关的选项。安全选项包括高级威胁保护、审计、动态数据掩码和透明数据加密。高级威胁保护和审计可以在服务器级别（针对该服务器上的所有数据库）或单个数据库上应用。

高级威胁保护包含三个子部分：

• 数据发现与分类（预览）

• 漏洞评估

• 威胁检测

数据发现与分类（预览）功能仍处于测试阶段，但非常有用。数据库将进行扫描，并提供建议，指出哪些列应标记为分类数据。在考虑需要遵守通用数据保护条例（GDPR）时，这尤其有用。

漏洞评估将进行安全扫描，并为您的数据库提供安全建议。例如，建议跟踪防火墙规则或分类敏感数据。

威胁检测将机器学习应用于您的安全性。此功能分析正常行为，并提醒您任何异常操作。例如，如果某个 SQL 登录帐户通常只在工作时间访问数据库，而突然在其他时间尝试登录，您将收到警报。或者，如果某个登录帐户始终来自特定 IP 地址，但尝试从世界另一端访问数据库，系统也会检测到并提醒您。

这里展示了高级威胁保护的截图：

审计功能允许我们跟踪事件并将其记录到存储帐户中。我们可以定义日志保留期，以及是否在数据库或服务器级别记录事件。由于审计通常是许多组织的要求，特别是为了符合不同的标准，这个选项允许您满足这一要求。以下是审计日志的截图：

在继续进行动态数据屏蔽之前，让我们先运行一个简单的查询。在表 SalesLT.Customers 中选择前 100 行将返回该表中前 100 个客户的所有信息。这里有各种类型的数据，我们可能不希望所有有数据库访问权限的人都能看到这些信息。我们以电话号码为例。请注意，在以下截图中，我们可以看到运行查询会返回电话列：

动态数据屏蔽面板将提供有关当前应用的所有屏蔽规则的信息，并建议您可能想要考虑用于屏蔽的其他规则。请注意，SQL 管理员不受数据屏蔽影响，您可以添加额外的用户来排除在外。以下是动态数据屏蔽的截图：

要添加新的规则，我们需要提供架构、表、列和屏蔽字段格式。屏蔽字段格式将允许您控制查询结果中屏蔽数据的显示方式。下面是如何为数据屏蔽添加电话列的示例：

一旦应用了数据屏蔽规则，我们可以再次运行查询。如以下截图所示，应用屏蔽规则后，结果将会不同，电话列的所有值都会返回xxx：

使用动态数据屏蔽，我们可以控制用户对数据的访问，防止他们查看机密信息。例如，如果我们在同一张表中有账单信息和联系信息，我们可能希望为不同的用户提供对该表的访问权限，但允许他们查看不同的信息。我们可以允许销售部门查看电子邮件或电话号码，但希望防止他们查看信用卡信息。另一方面，我们不希望阻止所有人查看信用卡信息，并希望允许财务部门访问这些信息。动态数据屏蔽非常适合这种场景，其中用户可以访问相同的表格，但查看不同的信息集。

透明数据加密（TDE）用于加密处于静态状态的数据库。此功能适用于本地版本的 SQL Server，但实现起来并不简单。对于 Azure SQL 数据库，创建的新数据库会自动开启此功能。以前并非如此，对于旧数据库，可以通过简单地开启 TDE 选项来启用此功能。就是这么简单，数据库（以及所有备份）都会在静态状态下被加密。下面的截图展示了透明数据库加密的界面：

监控和故障排除 Azure SQL 数据库

Azure SQL 数据库的监控选项与其他 Azure 资源的选项非常相似。监控选项包括警报（经典）、度量（预览）和诊断设置。所有这些功能也适用于 Azure 虚拟机和 Azure Web 应用程序，这些内容在前几章中已有介绍。

支持 + 故障排除选项为我们提供了一些特定于 Azure SQL 数据库的功能。功能包括资源健康和新支持请求，和其他 Azure 资源类似。新功能包括性能概述、性能推荐、查询性能洞察和自动调优。

性能概述为我们提供了查询性能的概览。在这里，我们可以查看查询的资源消耗情况。概述为我们提供了按资源类型聚合的查询消耗情况。资源类型包括 DTU、CPU 和 IOPS。此聚合会显示消耗最大资源的查询，但由于这是聚合消耗，可能是查询频繁执行的结果，而不是单次执行时消耗大量资源。我们可以在“长时间运行的查询”选项卡下查看执行时间较长的查询列表。这些信息可以帮助我们提高性能，因为经常执行的查询和执行时间较长的查询消耗了大量资源。优化这些查询可以提高性能，并在长期内节省成本。以下图表展示了性能概述中 CPU 消耗的情况：

在性能列表下，我们可以看到根据数据库的性能历史记录提供的推荐事项。它会给出推荐的列表，并提供自动应用这些建议的选项。在性能推荐面板中，我们可以看到新的推荐事项以及已应用的推荐，如下所示：

查询性能洞察提供了与性能概览非常相似的选项。不同之处在于，你可以在查询性能洞察中自定义和编辑图表与仪表板。你可以更改显示的不同指标和时间段，帮助你在更长时间内观察性能。查询性能洞察的默认界面如下所示：

自动调优选项是所有数据库管理员的梦想成真。此选项将使用内置的智能，观察性能随时间的变化，并应用机器学习解决方案来提高数据库性能。此选项可以在服务器或订阅级别自动启用。此外，还可以为单个数据库启用或禁用该选项。自动调优可用的设置包括 FORCE PLAN、CREATE INDEX 和 DROP INDEX。如果启用，自动调优将分析性能并自动应用有助于提高性能的更改。以下是自动调优设置的示例：

Azure SQL 数据库备份

对任何数据库管理员来说，备份是非常重要的任务。此选项在 Azure SQL 数据库中默认启用。当创建新的数据库时，会在过程中创建地理冗余存储，并在此存储中执行备份。此功能是自动提供的，且免费。对于 Azure SQL 数据库，使用 SQL Server 备份技术来创建完整、差异和事务备份。事务备份每 12 小时执行一次，差异备份则根据数据库大小和活动，每 5 至 10 分钟执行一次。这使得我们能够通过恢复所选时间点之前的最后一次完整备份、完整备份和所选时间点之间的所有差异备份，最后还原最后一次差异备份和所选时间点之间的所有事务备份，从而实现时间点恢复。

备份的保留期限取决于数据库层级，可从 7 天至 35 天不等。还可以启用长期保留备份（LTRB）选项，保留备份最长可达 10 年。默认备份是提供的无额外费用的选项，但 LTRB 使用额外的存储，且需要额外收费。然而，在某些情况下，我们需要长时间保留备份，这时此选项非常有用。此外，存储费用较低，因此不会对账单产生较大的影响。

另一个与备份直接相关的选项是数据库导出。此功能允许你将数据库的额外副本保存在独立存储中。此备份可以用于在新服务器或另一个订阅中恢复数据库。导出将创建一个包含模式和数据的 BACPAC 文件。

Azure 中的其他数据服务

虚拟机中的 SQL Server 和 Azure SQL 数据库仅是 Azure 数据平台的一部分。

当我们谈论 IaaS 中的 RDBMS 时，其实我们没有任何限制。我们可以创建任何类型的虚拟机，安装多种不同的操作系统，安装任何我们想要的软件，比如 Oracle、MySQL、PostgreSQL 等。也有许多包含预装该软件的镜像。同样，NoSQL 数据库也是如此：我们可以在虚拟机上安装任何东西，或者选择一个已经包含 MongoDB、CouchDB 等的镜像。

当谈论 PaaS 模型中的 RDBMS 时，我们也有不同的选项，如 MySQL、PostgreSQL、SQL 数据仓库等。作为 PaaS 运行 NoSQL 也提供了不同的选项，包括 Azure Cosmos DB 或 MongoDB。

Azure 数据平台通过 Azure 的分析服务得到扩展，这些服务在 IaaS 或 PaaS 模型中都有多种选择。

总的来说，Microsoft Azure 为数据和分析提供了不同的选项，无论你是迁移现有解决方案还是构建新的云解决方案。你可以在不同的 IaaS 和 PaaS 服务之间进行选择，并结合它们为特定场景提供最佳的结果。

以下是显示 Azure 中一些数据库和分析选项的截图：

摘要

Azure 数据平台在选择同时使用 IaaS 和 PaaS 时提供了多种选项。在 IaaS 中运行数据库提供了更多的控制，但也需要更多的维护和管理。DaaS 具有许多使数据库管理员生活更轻松的功能，但它不支持运行某些功能和遗留应用程序。最重要的是，我们需要决定如何继续，并根据我们解决方案所需的选项以及不同数据服务提供的选项来评估理想的选择。

一旦数据进入云端，Azure 提供了许多分析选项，这些选项可以帮助我们扩展我们的解决方案。同样，我们可以在不同的 IaaS 和 PaaS 服务中进行选择，挑选最适合我们的服务。

在前几章中，我们讨论了如何在 Azure 中设置应用程序和数据。创建和设计新应用程序是很棒的，但并不总是可行的。在大多数情况下，旅程从将现有解决方案从本地迁移到云开始。在下一章中，我们将解释迁移现有应用程序和数据库到 Azure 的可用选项。

问题

1. 在 Azure 中，数据库可以运行为…

   1. IaaS

   2. PaaS

   3. 两者

2. 带有 SQL 的 Azure 虚拟机与不带 SQL 的虚拟机不同，因为…

   1. SQL 服务器配置

   2. 内存和 CPU 的数量

   3. 它的名称

3. Azure SQL 数据库也叫做…

   1. 数据库即服务

   2. SQL 即服务

   3. 数据即服务

4. Azure SQL 数据库的层级可以以…来衡量

   1. DTU

   2. vCores

   3. 两者

5. 你可以在 Azure SQL 数据库上运行查询，使用…

   1. SQL Server 管理工作室

   2. Azure 门户中的查询编辑器

   3. 两者

6. 要连接到 Azure SQL 数据库，你需要…

   1. 向防火墙规则添加 IP 地址

   2. 在 VNet 中允许 IP

   3. 在主数据库中允许 IP

7. 要创建 Azure SQL 数据库副本，您可以使用…

   1. 数据库备份

   2. 数据库导出

   3. 地理复制

8. 要创建一个高度可用的 Azure SQL 数据库，您需要创建一个…

   1. 故障切换组

   2. 故障切换集群

   3. 常开

9. 要在 Azure SQL 数据库中遮蔽列，您可以使用…

   1. 透明数据加密

   2. 动态数据遮蔽

   3. 数据分类

10. 为了检测数据库的潜在威胁，您可以使用…

    1. 漏洞评估

    2. 高级威胁防护

    3. 两者

技术要求

本章所需内容：

• 一个 Azure 订阅

• 一个运行 Windows Server 2012 R2 或更高版本的本地服务器

• 一个 Hyper-V 服务器

• 一个本地的 SQL Server 2012 或更高版本实例

Azure 存储

Azure 存储是 Microsoft Azure 中一个非常重要的服务。几乎所有 Azure 服务都以某种形式使用存储。在某些情况下，存储的使用是显而易见的，而在其他情况下，它则是一个我们未曾察觉、默默运行的后台服务。

例如，如果我们创建一个新的虚拟机，虚拟磁盘将在此过程中创建。这些磁盘会存储在 Azure 存储中。如果使用托管磁盘，存储会在后台创建且不可见。如果我们不使用托管磁盘，创建过程中产生的存储将显示在资源中，因为当没有使用托管磁盘时，存储的管理由我们负责。

类似地，当任何 PaaS 资源被创建时，存储会在后台创建。在大多数 PaaS 案例中，存储不可直接看到，但我们可以在资源面板中看到可用和使用的存储量。例如，Azure SQL 数据库或 Azure 应用服务计划会根据不同的层级提供一定数量的资源。我们没有直接访问存储管理的权限，但可以看到关于存储空间的信息。

但 Azure 存储也可以作为独立服务使用并进行独立管理。为了说明这个服务，我们先从创建一个新的 Azure 存储账户开始。

Azure 恢复服务

另一个帮助迁移到云的服务是 Azure 恢复服务。这个服务包含一些功能，能够帮助我们将数据迁移到云端：

• Azure 备份

• Azure 站点恢复

这两项服务不仅用于将数据迁移到云端，还用于保护 Azure 和本地资源。它们的主要目的是保护资源，但一旦我们将数据存储在云中，这些数据也可以用于迁移操作。

创建恢复服务保管库

为了开始使用 Azure 恢复服务，我们必须创建一个恢复服务保管库。需要提供所有常规参数：名称、订阅、资源组和位置。请注意，如果您想保护 Azure 资源，位置非常重要。您将无法保护与恢复服务保管库位于同一位置的资源。下面是一个示例截图，展示了恢复服务保管库的参数设置：

创建一个 Azure 存储账户

为了创建 Azure 存储账户，我们需要提供名称、部署模型、账户类型、位置、复制策略、性能、安全传输要求、订阅和资源组。订阅、位置和资源组是所有 Azure 资源所需的常见设置。

存储账户名称必须在 Azure 中唯一，因为它用于构建存储账户的 URL。URL 是通过将存储账户名称加在标准 DNS 后缀前面构成的。例如，将存储账户命名为 packtdemo 会创建 URL packtdemo.core.windows.net，因此存储账户名称必须唯一。

部署模型允许我们在资源管理器和经典模型之间进行选择。由于经典模型已过时，推荐使用资源管理器，因此每次创建新资源时，我建议你选择资源管理器。

性能选项让我们可以在标准存储和高级存储之间进行选择。这基本上是选择 HDD 和 SSD，但也会影响存储的价格。高级存储采用 SSD，提供显著更好的性能，但价格上涨同样显著。

安全传输要求让我们选择启用或禁用此选项。启用时，所有传入的请求都必须通过 HTTPS 完成，并自动阻止任何通过 HTTP 的请求。此功能类似于 Azure Web 应用中的“仅允许 HTTPS”。由于此功能与安全性相关，我建议启用此选项。

这里显示了一张带有 Azure 存储账户选项的截图：

接下来，我们将介绍一些仅与 Azure 存储账户相关的设置。尽管性能选项也直接与存储相关，我们还可以在其他服务中看到选择存储性能的选项，例如虚拟机或某些 PaaS 资源。仅与存储账户相关的选项有账户类型和复制策略。

账户类型 让我们在三种选项之间进行选择：

• 存储（通用目的 v1）

• 存储 V2（通用目的 v2）

• Blob 存储

通用目的 v2 存储支持所有通用目的 v1 支持的功能，并带来了一些更新的功能。特别是如果你想使用最新的 API 和功能，比如访问层，推荐使用通用目的 v2 存储，这样你可以使用热存储和冷存储。

热存储和冷存储让你可以根据存储的数据选择你想要使用的访问层。热存储每 GB 存储的费用较高，但存储事务的费用较低。冷存储每 GB 存储的费用较低，但存储事务的费用较高。因此，冷存储更适合用于归档，而热存储则适用于活跃的存储。这个功能的优势在于，你可以随时在不同的访问层之间切换，进行更改。

从通用目的 v1 升级到通用目的 v2 可以在任何时候进行（但不能反向操作），如果您已经拥有 v1 存储帐户并希望受益于 v2 的功能。然而，在某些情况下，您需要使用 v1 作为唯一选项。例如，当需要经典部署时（通用目的 v2 仅在资源管理器中受支持），或者当您需要使用较旧的存储服务 REST API 时。

Blob 存储帐户在处理块 Blob 时，支持与通用目的 v2 相同的功能，但仅限于块 Blob，不支持页面 Blob。由于价格非常相似，建议使用通用目的 v2 存储，因为它具有相同的价格但更多的选项。

帐户类型的选项如下图所示：

复制有三种选项，这些选项与帐户类型相同。我们可以在以下选项中进行选择：

• 本地冗余存储（LRS）

• 地理冗余存储（GRS）

• 只读访问地理冗余存储（RA-GRS）

LRS 基于类似于虚拟机的可用性集和可用性区域的策略。数据的额外副本保存在 Azure 数据中心中，以在硬件故障或更新时提供持久性和冗余。它旨在提供 99.999999999%（11 个 9）的 SLA。所有数据都保存在单一的数据中心内，并且可能的故障切换会自动触发。

GRS 的设计方式与 LRS 非常相似，不同之处在于副本存储在不同的 Azure 数据中心，这些数据中心距离原始数据中心数千英里。由于这一点，增加了持久性，SLA 为 99.99999999999999%（16 个 9）。冗余副本仅在自动故障切换触发时可供访问。

RA-GRS 与 GRS 的设计方式相同，不同之处在于即使未激活故障切换，冗余副本也可以进行读取。

复制选项如下截图所示：

Azure 存储帐户的其他选项包括虚拟网络和数据湖存储 v2。

如果我们启用虚拟网络，我们可以选择现有的虚拟网络（或创建一个新网络）并选择子网。这样，我们的存储将加入到选定虚拟网络上的子网，并为我们的存储分配一个私有 IP 地址，允许我们通过私有网络而不是互联网访问存储。数据湖存储 v2 目前是预览版，仅在满足一些要求的情况下可以启用。我们需要选择通用目的 v2 存储，它仅在有限数量的 Azure 数据中心中可用，并且预览版必须经过预批准。以下截图展示了这些选项：

请注意，帐户类型、复制和性能会影响 Azure 存储的价格。位置也是一个因素，因为并非所有资源在所有 Azure 数据中心的费用相同，但这对价格的影响不如其他三个选项重要。

Azure 存储帐户的部署非常迅速，通常在一分钟内完成。

Azure 存储设置

创建 Azure 存储帐户后，我们可以使用不同的选项来管理它。一些选项与其他 Azure 资源的选项相似，因此我们将重点关注 Azure 存储帐户的独特选项。

设置中的第一个选项是访问密钥。访问密钥用于验证对 Azure 存储帐户的访问。它们通常用于启用应用程序访问，因此你可以在这里找到连接字符串和访问密钥。共有两个访问密钥，如果你认为原始密钥已被窃取或泄露，可以重新生成它们。

跨源资源共享（CORS）允许你定义受信任的域。Web 浏览器实施安全限制，防止应用程序调用来自不同域的 API。CORS 提供了原始域安全访问来自其他域的 API 的方式。

配置允许我们更改一些在创建存储帐户时可用的设置。在此选项下，我们可以将存储从通用目的 v1 升级到 v2，修改性能和复制设置，启用或禁用安全传输要求。

Azure 存储会自动加密并保护静态数据。自动加密使用 Microsoft 管理密钥对 Azure 的 Blob、表、文件和队列进行加密。然而，加密选项允许我们使用自定义密钥进行加密。

共享访问签名（SAS）提供了一个有限时长的访问密钥。我们可以使用这个密钥为存储提供临时访问，并定义访问持续的时间。密钥过期后，无法再次使用。

在防火墙和虚拟网络设置下，我们可以更改存储的网络和访问设置。我们可以将存储附加到虚拟网络（VNet）和子网，或者更改它所关联的虚拟网络。通过防火墙，我们可以阻止来自不受信任 IP 地址的存储访问。我们可以将本地 IP 地址或其他受信任的 IP 地址列入白名单，只允许这些地址访问 Azure 存储，并防止其他人访问。

属性、锁定和自动化脚本是所有 Azure 资源的可用选项。

下一组选项与 Blob 服务相关。这里有 Blobs、定制域、软删除、Azure CDN 和 Azure 搜索。

Blob 允许您查看存储帐户中当前的 Blob 列表，并执行如创建新 Blob 或删除现有 Blob 等操作。此外，您可以访问 Blob 并查看其中的文件列表，并对文件执行操作，如下载或删除。

自定义域名允许您为存储帐户使用自定义域名。您可以设置 CNAME 记录，将其指向您的存储帐户，从而开始使用自定义域名，而无需使用提供的 DNS。

软删除允许您为存储设置保留策略。如果启用，默认的保留策略是七天，但可以更改为最长 365 天。软删除使您能够恢复任何已删除的 Blob。这也适用于由于覆盖而删除的 Blob，因此您可以恢复已删除的 Blob 或 Blob 的旧版本。

Azure CDN 和 Azure 搜索是将这些 Azure 服务链接到您的存储帐户的选项。Azure CDN 用于缓存存储内容，从而提高性能并减少延迟。Azure 搜索是一个完全托管的云搜索服务，提供更好的用户体验。

以下选项允许我们管理文件服务、表服务和队列服务。对于这些服务中的每一个，我们可以看到存储帐户中现有文件服务的列表，并且可以执行不同的操作，如删除现有服务、创建新服务或设置访问策略。

将数据库迁移到云端

一旦我们拥有存储帐户，就可以开始加载数据。这可以是任何类型的文件，我们可以将存储用作暂存阶段，在此阶段我们准备上传的文件，之后这些文件将被实际使用，或者我们可以上传直接由应用程序使用的文件。

多年来，我看到许多组织使用 Azure 存储作为本地 SQL 数据库的备份位置。这是一种便捷的方式，可以让我们开始云端之旅，因为它提供了相对便宜、离线且加密的存储。

一旦数据库存储到云端，下一步将是使用备份恢复 Azure 中的数据库，并开始将其作为 IaaS 或 PaaS 使用。

让我们看看如何直接将数据库备份到 Azure 存储。

将数据库备份到存储

为了将数据库备份到 Azure 存储，首先需要打开SQL Server Management Studio（SSMS），选择要备份的数据库，然后选择任务 | 备份… 第一步在此截图中显示：

新窗口将打开，提供选项以选择数据库（如果在第一步中选择了正确的数据库，则该选项已经被选中，但可以更改，或者我们可以选择多个数据库）、备份类型（通常推荐全量备份）以及最后的目标位置。默认选项是磁盘，我们需要将其更改为 URL。以下是这些选项的截图：

选择 URL 作为目标后，我们必须选择添加，以提供路径。这将打开一个新窗口，我们需要提供 Azure 帐户信息以访问 Azure 订阅。完成后，我们可以从 SSMS 访问 Azure 订阅，并选择存储账户和 Blob 来存储备份。由于备份是通过 共享访问签名（SAS）执行的，因此我们必须创建一个新的 SAS 并提供过期日期。设置备份目标的过程如以下截图所示：

最后，我们点击确定，执行备份。备份所需的时间取决于带宽、数据库大小和存储类型。在此案例中，存储类型通常是标准存储，因为将备份存储到高级存储是多余的，并且我们为存档付费的服务是高端的。备份完成后，我们可以在 Azure 门户中看到存储账户下所选 Blob 中的文件信息。以下是 Azure 门户中文件信息的示例：

备份完成后，我们可以使用该备份在 Azure 中恢复数据库。然而，完整备份只能恢复到运行在 Azure 虚拟机（IaaS）上的 SQL Server 中。为了在 Azure SQL 数据库（PaaS）中恢复备份，我们必须使用 BACPAC。BACPAC 包含 SQL 数据库的 数据和元数据。将 BACPAC 备份到 Azure 存储的过程与创建数据库完整备份的过程类似。

将数据库迁移到 Azure SQL

创建备份并恢复并不是迁移数据库到 Azure 的唯一选项。此过程可以在不使用备份的情况下，直接将数据库迁移到 Azure。

为了实现这一目标，第一步是选择数据库，点击加粗的任务（Tasks）并选择在 SSMS 中将数据库部署到 Microsoft Azure SQL 数据库的选项。第一步如以下截图所示：

第二步是连接到你的 Azure SQL Server。为此，我们需要在选择第一步中的选项后，选择新窗口中的连接…。此窗口如以下截图所示：

为了连接到 Azure SQL 数据库，我们需要提供服务器 URL、用户名和密码。确保你的服务器的公共 IP 地址已添加到 Azure SQL Server 的防火墙规则中，否则将无法连接。以下是连接选项的示例：

连接建立后，我们回到上一步的窗口。最后，我们必须提供将用于迁移的 Azure SQL 数据库的数据库层（将创建一个新数据库）。以下是数据库大小选项的示例：

处理完成后，我们将收到关于任务成功的消息。完成迁移所需的时间可能会受到多个因素的影响，如数据库大小、带宽和 Azure SQL 数据库层级。请注意，选择过小的层级（如果我们迁移的是大型数据库）将导致错误，因为目标数据库的性能可能不足以处理迁移大型数据库所需的工作负载。成功迁移的截图如下所示：

迁移完成后，我们可以使用 SSMS 连接到 Azure SQL 服务器，并找到已迁移的数据库，如下所示：

在某些情况下，即使选择了正确的 Azure SQL 数据库层级，迁移仍然会失败。这是由于数据库与 Azure SQL 数据库不兼容。例如，在使用 Azure SQL 数据库时，需要有聚集索引（对于本地部署的数据库推荐）。如果迁移的数据库没有聚集索引，迁移将会失败。幸运的是，有一个工具可以帮助我们进行评估，告诉我们数据库中可能存在的问题和问题。

数据库评估

要创建我们数据库的评估并确保它准备好进行迁移，我们可以使用 Microsoft 数据迁移助手。这个工具是免费的，可以从 Microsoft 下载中心下载。

安装此工具后，您可以开始一个新项目。选择评估，提供项目名称，源服务器类型和目标服务器类型。对于源，选择 SQL Server，对于目标，选择 Azure SQL 数据库。新项目的示例如下所示：

第二步是选择评估选项。您可以选择检查兼容性和功能一致性。兼容性将检查您的数据库功能，并提供是否存在任何阻止迁移的问题或已弃用的功能。功能一致性将检查是否有任何不受支持的功能或功能。例如，Azure SQL 数据库不支持 SQL Server Reporting Service (SSRS)，因此如果您的应用程序正在使用 SSRS，这可能会导致问题。我建议选择这两个选项，如下所示：

选择要检查的内容后，我们需要提供将要检查的源。为了进行评估，工具需要访问数据库，因此我们必须提供 SQL Server、凭据和数据库。选定的数据库将与 SQL Server 版本一起显示在列表中，如下所示：

执行评估所需的时间取决于数据库的大小和复杂性，可能需要几分钟到几个小时不等。评估完成后，我们将收到两个报告。第一个报告是关于功能兼容性的，以下是示例：

第二个报告是关于数据库兼容性的。如果运气好，而且数据库的维护定期进行，你将得到以下示例中的报告，显示没有兼容性问题，允许你将数据库迁移到 Azure SQL 数据库：

可能的兼容性问题之一是聚集索引。建议为数据库中的每个表都有一个聚集索引，但在 Azure SQL 数据库中，这是一个要求。另一个例子是 CLR 函数，它在 Azure SQL 数据库中不被支持。

可以使用评估工具进行评估，不仅适用于迁移到 Azure SQL 数据库，还适用于其他版本的 SQL Server。所以，如果你计划将数据库迁移到新版 SQL Server（无论是在 Azure 还是本地部署），该工具也能对这些迁移进行评估。

Microsoft 数据迁移助手也可以用于执行数据库迁移。请注意，使用此迁移与通过 SSMS 迁移的区别在于，这里必须先创建 Azure SQL 数据库（空的 Azure SQL 数据库），然后才能进行迁移。

作为第三种迁移选项，Azure 数据库迁移服务也可以使用。实际上，这个迁移是一种数据同步选项，因为在运行此服务之前，必须先存在数据库和架构。Azure 数据库迁移服务允许你链接源数据库和目标数据库，将数据从源复制到目标，适用于整个数据库或选择的表。

启用 Azure 备份

一旦恢复服务库创建完成，我们就可以开始配置。如前所述，我们有两种不同的服务，且两种服务都可以用于保护 Azure 和本地资源。

让我们从在 Azure 资源上启用 Azure 备份开始。如果我们选择保护 Azure 中的工作负载，Azure 备份配置中可选的保护项有：虚拟机、Azure 文件共享（预览版）和 SQL Server 在 Azure VM 中（预览版）。我们选择虚拟机并继续。Azure 备份的 Azure 资源示例如下：

可用资源的列表将自动提供。选择虚拟机时，这将是一个包含 Azure 虚拟机的列表。如果选择的是 Azure 文件共享（预览版），那么将是一个包含文件共享的 Azure 存储帐户列表。我们选择要备份的虚拟机，如下截图所示：

启用备份后，我们可以在备份项下查看受保护虚拟机的列表。该列表还将显示状态、受保护资源的类型以及其他有用信息，如下所示：

备份本地资源

使用 Azure 备份保护本地资源需要多做一些工作。在 Azure 备份配置中选择本地资源后，我们会看到一个与选择 Azure 资源时不同的列表。我们可以选择文件和文件夹、Hyper-V 虚拟机、VMware 虚拟机、Microsoft SQL Server、Microsoft SharePoint、Microsoft Exchange、系统状态和裸机恢复。

在 Azure 门户进行配置后，我们需要安装恢复服务代理，它将允许我们在恢复服务库中注册本地资源。下面是恢复服务代理的截图：

为了继续注册，我们必须提供库凭证。库凭证以文件的形式提供，可以从恢复服务库下载。提供库凭证后，恢复服务代理将自动加载备份库信息，如下所示：

下一步是提供用于加密和解密备份的密码短语。密码短语必须至少包含 16 个字符，并将存储在您选择的位置。确保您知道密码短语存储的位置。否则，您将无法在需要时恢复任何备份。创建密码短语的过程如下所示：

一旦服务器在恢复服务库中注册，我们可以在目标服务器（也可以安装在客户端操作系统上）上使用 Microsoft Azure Backup 软件，配置备份的内容和时间。我们可以查看当前任务的状态并执行其他操作，如下所示：

要配置备份任务，我们需要提供备份的内容。我们可以选择整个驱动器，或选择特定的文件和文件夹，如下所示：

选择备份内容后，我们需要定义备份的时间和计划。我们可以选择每周或每天备份（最多一天三次）。以下是一个计划示例：

在设置了计划后，我们需要提供保留策略。保留策略定义了我们的备份将保持可用的时间，并可以按周、月和年进行配置。默认的保留策略如下所示：

最后的选项是配置初始备份将如何执行。由于初始备份通常意味着将备份大量数据，我们需要定义是通过网络直接执行备份（可能会产生过载），还是通过分阶段将数据部分复制到 Azure 存储，然后再复制到恢复库。下面显示了一个选项示例：

执行初始备份的时间取决于数据的大小和网络带宽。初始备份后，备份会以增量的形式执行（仅复制更改），并且完成时间不应很长。再次强调，保存密码短语非常重要，因为备份是加密的，如果没有用于加密的密码短语，您将无法恢复任何数据。

Azure 站点恢复

ASR 不是一个备份解决方案，而是一个灾难恢复（DR）站点，位于云中。拥有一个 DR 站点从未像在 Azure 中那样变得更容易且更便宜。大多数传统的 DR 站点涉及与受保护站点相同（或至少非常相似）的设备，成本约为原站点价格的 80%。另一方面，ASR 按受保护节点和存储数据的存储收费，因此非常便宜。如果在 Azure 中启用恢复，那么还会按虚拟机的计算价格收费。通过这种方式，您只需在发生故障转移时支付保护和计算费用。如果我们创建本地 DR 站点，我们即使在没有发生故障转移时，也必须支付用于运行 DR 所需的硬件费用，但仅作为保护使用。

ASR 还可以用于将虚拟机从本地迁移到云端。由于保护 Azure 虚拟机相对简单，我们将跳过保护 Azure 虚拟机的部分，直接演示如何保护本地虚拟机资源并使用 ASR 进行迁移。

配置 ASR 以保护本地资源

要开始在 Azure 中创建灾难恢复，我们必须首先在恢复服务库中配置 ASR。涉及三个步骤：

1. 准备基础设施

2. 复制应用程序

3. 管理恢复计划

选择准备基础设施后，会打开一个新页面。在这里，我们有几个选项需要定义。首先，我们需要选择是否要保护 Azure 或本地资源。由于我想演示如何使用 ASR 进行迁移，我将选择本地资源。下一个选项是定义我们希望将资源复制到哪里，提供的选项是 Azure 或其他站点。

我们需要定义我们要保护的基础设施是否是虚拟化的，如果是，我们选择 Hyper-V 或 VMware。如果我们使用 Hyper-V，则需要定义是否使用 SC VMM。下面是保护目标页面的截图：

第二步将引导您进行部署规划。在此，我们可以下载工具来估算本地基础架构中 ASR 的要求。此步骤不是必须的，但建议执行，因为容量不足可能导致复制问题。可以直接从 Azure 门户下载部署规划工具，如下所示：

如果容量没问题，我们可以继续进行源准备。我们需要创建一个 Hyper-V 站点并注册一个应包含在复制中的 Hyper-V 服务器，如下所示：

在创建新站点后，我们需要在所有希望在该站点上保护的 Hyper-V 主机上下载并安装代理程序。此代理的安装类似于备份代理（我们需要从恢复服务保险库中下载的保险库凭据），完成安装后，Hyper-V 主机将显示在我们站点下。请注意，安装完成后，可能需要 15 到 30 分钟才能在 Azure 门户中看到 Hyper-V 主机。以下是成功注册的站点和主机的示例：

在设置完源环境后，我们还需要准备目标环境。我们需要选择 Azure 订阅和部署模型，并准备 Azure 基础架构。在基础架构下，我们需要为目标环境提供至少一个存储帐户和一个 VNet。存储帐户用于虚拟机磁盘，而 VNet 用于灾难恢复时，如果必须将虚拟机恢复到 Azure，虚拟机必须连接到 VNet。以下是目标配置的示例：

基础架构准备的最后一步是创建复制策略。我们需要定义频率、恢复点保留以及一些其他设置的规则。我建议保留所有默认设置，除了可能基于受保护服务器的角色更改的复制频率外。您还可以创建多个策略并根据需要应用它们。您可能不需要像数据库或文件服务器那样频繁地复制 Web 服务器，可以根据受保护服务器的角色使用不同的复制策略。以下是默认复制策略的示例：

基于前面的步骤，我们可以将多个源添加到单个密钥保险库。在同一个密钥保险库中，我们可以注册 Azure 资源、多个 Hyper-V 站点、VMware 站点或物理服务器。

在为 ASR 准备好基础架构后，我们需要定义要复制的内容及其时间。我们需要选择一个源（Azure 或本地）并选择在恢复服务保险库中注册的适当位置。以下是源选择的示例：

选择源后，我们还需要选择目标。必需的参数包括 Azure 订阅、资源组、部署模型、存储和网络设置。资源组将作为故障转移时虚拟机创建的位置。

虚拟网络也是如此，只有在发生故障转移并且需要在 Azure 中创建虚拟机时才会使用。存储用于放置虚拟机磁盘（VHD），即使没有故障转移，它也会被使用，因为即使虚拟机没有运行，数据也必须存储。目标设置的示例如下所示：

源和目标已经设置完毕，现在我们需要选择要保护的内容。这分为两步。第一步是选择我们希望保护的虚拟机，它们位于之前选择的站点中，如下所示：

在选择要保护的虚拟机后，我们必须为这些虚拟机提供其他设置。所需的设置包括虚拟机的操作系统和我们希望复制的磁盘。示例如下所示：

最后的步骤之一是选择要应用的复制策略。由于我们可以创建多个策略，因此可以分配一个最适合受保护虚拟机角色和设置的策略。复制设置的示例如下所示：

最后，一切就绪，点击“确定”后，我们可以启用复制并开始保护我们的虚拟机。最后一步如下所示：

使用 ASR 作为迁移工具

复制完成后，您可以在恢复服务保管库中的“受保护项”下查看已复制虚拟机的状态。您可以使用相同的面板来监视复制过程，并查看已复制项的百分比。完成初始复制所需的时间取决于网络带宽、存储设置和要复制的数据大小。成功复制的示例如下所示：

如果我们选择任何已复制项下的虚拟机，我们可以找到有关健康状态、事件以及故障转移选项（计划故障转移、故障转移和测试故障转移）的额外信息，如下所示：

不同的故障转移方式以及它们对主虚拟机的影响是不同的。例如，测试故障转移将在 Azure 中创建一个虚拟机实例，但不会对本地（主）虚拟机产生任何影响。另一方面，计划故障转移和故障转移会在 Azure 中创建一个新的虚拟机实例，将其声明为主虚拟机，甚至可以关闭本地虚拟机。

此窗格中还可以找到一个包含基础设施图的示意图，展示了在过程中涉及的所有组件如何连接。Hyper-V 站点的示意图如下所示：

故障切换和迁移虚拟机

由于我们复制虚拟机的目的是将其迁移到云端，让我们继续并展示如何执行此任务。

首先，我们需要执行虚拟机的故障切换。这里我们需要选择一个恢复点作为使用的恢复点，因为我们有多个恢复点。完成故障切换所需的时间取决于将要创建的虚拟机的大小、磁盘的数量以及这些磁盘上的数据大小。故障切换设置的示例如下所示：

故障切换完成后，虚拟机将会在 Azure 中运行，你可以像管理其他 Azure 虚拟机一样进行管理。请注意，这个虚拟机不会使用托管磁盘。这是因为 ASR 会将磁盘复制到存储中，并创建本地 VHD 的副本。当故障切换发生时，VHD 会用于我们的虚拟机并附加到虚拟机上，但因此这些磁盘没有托管。不过，您可以在需要时将迁移到托管磁盘。如果你计划完全迁移该虚拟机，我强烈建议执行迁移到托管磁盘。故障切换后的虚拟机如下所示：

完成故障切换后，虚拟机将在 Azure 中运行，但仍然与本地虚拟机相连。我们可以随时执行故障恢复操作，虚拟机会在恢复服务库中的复制项下列出。要完成迁移并仅在 Azure 中运行虚拟机，我们需要执行完整的迁移步骤。这将移除虚拟机与本地虚拟机以及恢复服务库的关联，如下所示：

其他选项

最终，我们的虚拟机已迁移到云端并在 Azure 中运行。使用 ASR 进行迁移可以最小化服务的停机时间，但这并不是唯一的选项。

AzCopy 也允许我们将数据从本地复制到云端，并可以作为所有类型文件的迁移工具。另一种选择是使用 PowerShell 将 VHD 上传到 Azure 并利用它们部署 Azure 虚拟机。

Azure 导入/导出作业用于将大量数据传输到 Azure。假设你有 4 TB 数据的磁盘，若通过互联网复制这些数据会耗费大量时间。使用 Azure 导入/导出作业，你可以在 Azure 中创建一个作业，将数据复制到物理磁盘上并将其运送到 Azure 数据中心。然后，磁盘将会在 Azure 门户中对你可用，你可以在云中使用这些数据。该过程也可以反向进行，你可以将数据从 Azure 导出并运送回自己。

总结

在我们介绍了基本的 Azure 服务，包括 IaaS 和 PaaS 后，我们讲解了将数据迁移到 Azure 的过程。微软提供了多种评估数据是否适合迁移到云端的选项，并且提供了多个工具来帮助将数据从本地迁移到 Azure。由于传入流量费用为 0，且只有从 Azure 输出的流量才会收费，因此我们可以看到微软希望数据去向何处。

Azure 之旅的下一步是混合云，它将帮助我们利用已有的本地资源，并结合云端的所有好处进行扩展。对于大多数公司来说，这种情形已经成为现实，因为大多数公司已经投资于本地资源。忽视现有资源并非一种选择，我们可以通过使用混合云扩展现有资源，从而利用 Azure 提供的服务。在第七章，《混合云与 Azure - 将本地工作负载扩展到云端》中，我们将讨论如何在 Azure 与本地基础设施之间创建安全连接，并将 Azure 用作混合云。

问题

1. Azure 存储帐户可以部署为…

   1. 资源管理器

   2. 经典

   3. 两者

2. 为了获得最佳的服务级别协议（SLA），存储帐户应为…

   1. 本地冗余

   2. 地理冗余

   3. 两者

3. 存储帐户层级可以是…

   1. 标准

   2. 高级

   3. 两者

4. 本地数据库能否备份到 Azure 存储帐户？

   1. 是的

   2. 不是

5. 本地数据库能否直接部署到 Azure SQL 数据库？

   1. 是的

   2. 不是

6. 要使用 ASR，您需要创建…

   1. Azure 存储帐户

   2. 恢复服务保管库

   3. Azure 备份

7. 使用 Azure 备份，您可以保护…

   1. Azure 资源

   2. 本地资源

   3. 两者

8. 使用 ASR，您可以保护…

   1. Azure 虚拟机

   2. 本地虚拟机

   3. 两者

9. 为了将受 ASR 保护的虚拟机迁移到云端，您必须…

   1. 复制虚拟机

   2. 执行故障转移

   3. 启动 Azure 中的虚拟机

10. 为了将大量数据迁移到 Azure，必须使用…

    1. AzCopy

    2. PowerShell

    3. Azure 导入/导出作业

第七章：Azure 的混合云 - 将本地工作负载扩展到云端

混合云是云计算旅程中的一个重要组成部分，它帮助我们将 Azure（或任何其他云）与本地资源结合。在本章中，我们将讨论如何配置环境以及如何设置 Azure 和本地基础设施之间的连接，以便充分利用本地和云基础设施的优势。

本章将涵盖以下主题：

• 混合云

• 将虚拟网络连接到本地环境

• 本地数据网关

• Azure Stack

技术要求

本章所需的内容：

• 一个 Azure 订阅

• 运行 Windows Server 2012 R2 或更高版本的本地服务器

• 支持 S2S 连接的 VPN（防火墙）设备

混合云

对于许多组织来说，完全迁移到云端并不是一个选择。尽管云提供了多种好处，但仍然有很多场景需要考虑。

例如，如果一家公司已经投资了本地基础设施，那么仅仅放弃所有投资并将所有内容迁移到云端是困难的。在创建本地数据中心时，我们需要投资服务器机房、网络、服务器、存储和软件许可证。没有商业理由放弃所有投资并开始在云上投资。

另一种场景是我们无法迁移特定服务的情况。在这种情况下，法律合规性可能会阻止我们将某些内容从本地数据中心迁移出去。例如，某些国家/地区不允许将用户的个人信息存储在该国之外。如果您所在地区没有 Azure 数据中心，这可能成为一个障碍，您可能需要将数据保留在本地数据中心。

在这两种情况下，当某些因素使我们无法使用云的所有服务时，我们可以通过设置混合云来利用云所提供的服务。这使我们能够将云服务与本地基础设施结合使用，创造出本地和云基础设施的最佳组合。

例如，我们可以在本地数据中心设置数据库（如果我们不能迁移数据库或有全新的数据库服务器），并设置会在后台使用本地数据库的云服务。这尤其适用于 Azure 数据分析平台，它提供多个强大的服务，可以为您提供快速的数据处理，并且仍然保留本地数据。

还有一种第三种场景，您可以使用来自多个云提供商的服务，并从每个提供商所提供的服务中受益。同样，我们需要设置混合云场景，以确保在您使用每个云中的服务之间的通信安全，并交换资源。

在混合云中设置安全性并确保数据安全的最佳方式是创建 Azure 与本地基础设施之间的直接连接。

连接本地网络和 Azure 虚拟网络

为了连接本地基础设施和 Azure，我们需要在本地网络和 Azure 虚拟网络之间创建一个连接。这个连接可以是点对站点（P2S）或者站点对站点（S2S）。由于 P2S 允许单个计算机访问 Azure 虚拟网络，它并不适合真正的混合云应用，更适合作为远程工作人员的访问点。

要建立真正的混合云，我们需要创建一个 S2S 连接，使得我们的本地网络和 Azure 虚拟网络之间可以进行全面的通信。通过这样做，我们将本地网络扩展到 Azure，并能够像访问本地环境中的资源一样访问 Azure 中的资源。

创建 S2S 连接有两种方式：使用 VPN 和使用 ExpressRoute。VPN 将提供两个网络之间的通信加密，而 ExpressRoute 更进一步，提供本地网络和 Azure 虚拟网络之间的专用连接。专用连接提供了更高的可靠性、更快的速度、更低的延迟和更高的安全性，但它必须作为由 ISP 提供的单独服务购买。

在本地网络和 Azure 虚拟网络之间建立连接是一个两步过程。首先，我们需要创建和配置 Azure 资源，第二步则需要配置我们的本地防火墙。在本地环境中，我们需要一个支持创建 S2S 连接并具备公网 IP 地址的 VPN（防火墙）设备。请注意，带有 S2S 选项的所有设备不都支持与 Azure 建立 S2S 连接。

创建 S2S 连接

要在 Azure 虚拟网络和本地网络之间创建 S2S 连接，首先我们必须创建两个 Azure 资源：虚拟网络网关和本地网络网关。

创建虚拟网络网关是在一个面板中完成的。我们需要提供的信息包括：名称、网关类型、VPN 类型、SKU、虚拟网络、网关子网地址范围、公网 IP 地址、订阅和位置。名称、订阅和位置是常规参数。

第一个选项是选择网关类型。可以选择 VPN 或 ExpressRoute（如前所述）。如果选择 VPN，则需要选择 VPN 类型是基于策略还是基于路由。（这个选项可能取决于您本地网络的设置。）下一步是选择一个 SKU，决定可用的带宽和连接数。可以启用或禁用活动-活动模式。此模式允许您创建冗余连接，从流量的角度来看，它们将被视为一个连接。换句话说，您需要在本地设备上创建两个 S2S 连接，这两个连接将流量路由到同一个虚拟网络。除非其中一个连接不可用，否则流量将通过两个连接路由，如果一个连接不可用，流量将通过仍然可用的 S2S 连接路由。

活动-活动模式不仅用于高可用性连接，还用于更好的性能。您需要选择一个可用的虚拟网络。可用的网络将取决于选择的订阅和位置。选择虚拟网络后，您需要为网关子网提供一个地址范围。如果该子网不存在，将自动创建（除非网络上没有空闲地址空间，否则该过程将失败）。请注意，不需要资源组。虚拟网络网关将在虚拟网络所在的同一资源组中创建。

接下来，您需要创建或选择一个现有的公共 IP 地址，该地址将用于连接。此 IP 地址用于与本地网络建立连接，并将在本地防火墙的配置中使用，以接受来自 Azure 的连接。我建议使用静态 IP 地址，以免 IP 地址发生变化时，您需要重新配置。

接下来是虚拟网络网关配置的示例：

创建虚拟网络网关需要 30 到 90 分钟。这是 Azure 中部署时间最长的资源之一。

Azure 虚拟网络网关部署的 ARM 模板在这里提供：

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"sku": {
"type": "string"
},
"gatewayType": {
"type": "string",
"defaultValue": "Vpn",
"allowedValues": [
"Vpn",
"ExpressRoute"
]
},
"vpnType": {
"type": "string",
"defaultValue": "RouteBased",
"allowedValues": [
"RouteBased",
"PolicyBased"
]
},
"existingVirtualNetworkName": {
"type": "string"
},
"newSubnetName": {
"type": "string"
},
"subnetAddressPrefix": {
"type": "string"
},
"newPublicIpAddressName": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2017-06-01",
"name": "[parameters('name')]",
"type": "Microsoft.Network/virtualNetworkGateways",
"location": "[parameters('location')]",
"dependsOn": [
"Microsoft.Network/virtualNetworks/PacktVnet/subnets/GatewaySubnet",
"[concat('Microsoft.Network/publicIPAddresses/', parameters('newPublicIpAddressName'))]"
],
"properties": {
"gatewayType": "[parameters('gatewayType')]",
"ipConfigurations": [
{
"name": "default",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"subnet": {
"id": "[resourceId('PacktIaaS', 'Microsoft.Network/virtualNetworks/subnets', parameters('existingVirtualNetworkName'), parameters('newSubnetName'))]"
},
"publicIpAddress": {
"id": "[resourceId('PacktIaaS', 'Microsoft.Network/publicIPAddresses', parameters('newPublicIpAddressName'))]"
}
}
}
],
"vpnType": "[parameters('vpnType')]",
"sku": {
"name": "[parameters('sku')]",
"tier": "[parameters('sku')]"
}
}
},
{
"apiVersion": "2018-04-01",
"type": "Microsoft.Network/virtualNetworks/subnets",
"name": "[concat(parameters('existingVirtualNetworkName'), '/', parameters('newSubnetName'))]",
"location": "[parameters('location')]",
"properties": {
"addressPrefix": "[parameters('subnetAddressPrefix')]"
}
},
{
"apiVersion": "2017-08-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[parameters('newPublicIpAddressName')]",
"location": "[parameters('location')]",
"properties": {
"publicIPAllocationMethod": "Dynamic"
}
}
]
}

在虚拟网络网关部署完成后，我们可以继续创建本地网络网关。本地网络网关用于输入本地防火墙和网络的信息。您需要提供本地防火墙的公共 IP 地址以及本地网络的地址空间（或者根据防火墙，提供本地网络的网关子网）。您还需要提供订阅、位置和资源组。位置应与虚拟网络网关和虚拟网络使用的相同。我建议将它们放在同一资源组中，以便于管理。以下是本地网络网关的示例设置：

本地网络网关部署的 ARM 模板在这里提供：

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"localNetworkGatewayName": {
"type": "string"
},
"location": {
"type": "string"
},
"gatewayIpAddress": {
"type": "string"
},
"addressPrefixes": {
"type": "array"
}
},
"resources": [
{
"name": "[parameters('localNetworkGatewayName')]",
"type": "Microsoft.Network/localNetworkGateways",
"apiVersion": "2017-06-01",
"location": "[parameters('location')]",
"properties": {
"localNetworkAddressSpace": {
"addressPrefixes": "[parameters('addressPrefixes')]"
},
"gatewayIpAddress": "[parameters('gatewayIpAddress')]"
}
}
]
}

与虚拟网络网关相比，部署本地网络网关相对较快，部署应在 5 分钟内完成。

配置 Azure 的 S2S 设置

在虚拟网络网关和本地网络网关创建后，我们可以继续进行配置。在虚拟网络网关中，我们在设置下选择连接类型选项。您将看到设置中有配置、连接和点对站点连接的选项。

由于我们将专注于 S2S 连接，因此我们只使用连接面板并添加一个新连接。我们需要像往常一样提供一个名称。虚拟网络网关、订阅、资源组和位置的选项是锁定的，无法更改，因为它们取决于用于创建连接的虚拟网络网关。我们需要提供的参数是连接类型和共享密钥（PSK）。连接类型的选项有 VNet 到 VNet、站点到站点（IPsec）和 ExpressRoute。由于我们希望连接到本地网络，因此选择站点到站点（IPsec）选项。对于共享密钥（PSK），我建议它尽可能复杂，因为安全性可能依赖于此。新连接的示例设置如下：

创建连接只是第一步；我们还需要为本地网络配置设置。在初步创建后，连接的状态将显示为未知，如下图所示：

配置本地防火墙以支持 S2S

本地防火墙的配置取决于供应商和设备类型。在已创建的连接下，有一个选项可以下载某些设备的配置。您可以选择不同的供应商（例如，Cisco 和 Juniper），并且还可以根据设备供应商、设备系列和固件版本下载特定的配置。只有少数设备可以直接从 Azure 门户下载。您可以在微软的文档中找到更多设备，有些供应商在其网站上有关于 Azure S2S 配置的部分。以下是配置下载过程的截图：

在双方配置完连接后，状态将更改为已连接，如下所示：

这将允许您通过安全的、私有的连接直接从本地网络连接到 Azure 虚拟网络中的任何资源。在某些情况下，您可能不希望将资源公开供公共访问，因此这是连接到资源的唯一方法。

在其他情况下，通常最常见的做法是服务公开访问，但管理是在私有网络上进行的。例如，允许通过互联网以 HTTP 或 HTTPS 访问网站，但仅允许通过私有网络访问数据库或 RDP 连接到虚拟机。

配置混合环境中的服务

一旦我们在本地网络和 Azure 之间建立了连接，我们就可以开始使用这两个环境中的服务，就像它们是一个单一站点或网络一样。然而，有一些事情需要我们牢记。

如果我们在本地环境中已设置了一个域，并希望在云端使用相同的域，那么在 Azure 虚拟网络中运行一个域控制器是一个不错的选择。即使我们已经建立了 S2S 连接，也可能会出现偶尔的连接中断。通过在云端运行一个 DC，我们可以确保 Azure 中的服务能够在中断发生时使用所有功能并独立运行。

当运行 SQL Server 并使用 Always On 可用性组时，你可以使用 Azure 扩展服务并在云端添加一个副本。如前所述，运行 Azure 有两种模式：资源管理器和经典模式。经典模式支持通过向导在 Azure 中添加副本，并且相对容易设置。

资源管理器需要使用 T-SQL 命令在 Azure 资源管理器模式下添加副本，但这稍微有些复杂。不过，由于资源管理器是推荐的模式，我建议使用资源管理器，因为经典模式迟早会被淘汰，最终你还是需要设置资源管理器。

另一个需要考虑的因素是 Azure 混合权益（Azure Hybrid Benefit），它允许你在 Azure 中使用现有的本地许可证。通过软件保证，你可以使用 Windows Server 和 SQL Server 的许可证，并以显著的折扣部署 Azure 资源。

在建立本地网络与 Azure 之间的连接时，数据中心的位置非常重要。如果你位于一个大陆，而 Azure 数据中心（虚拟网络部署所在的数据中心）位于另一个大陆，你将会遇到网络延迟和滞后。选择离你最近的地理位置是最佳的选择。

如果你遇到网络延迟和滞后问题或性能问题，可以考虑使用 ExpressRoute 服务。虽然这需要付费，但它提供了企业级的连接，具有最佳的可靠性、速度和安全性。

跨 Azure 连接虚拟网络

虚拟网络网关可用于连接不同的 Azure 虚拟网络。但因为你需要为虚拟网络网关付费，我建议采用另一种方法。要将 Azure 虚拟网络连接到另一个 Azure 虚拟网络，我们可以使用对等连接。通常，对等连接是将独立的网络互联以交换流量。对等连接的选项可以在虚拟网络面板的设置下找到。如果我们选择创建一个新的对等连接，需要提供一个名称，并选择是连接到资源管理器还是经典虚拟网络。由于推荐使用资源管理器，我们将在这里解释该过程。如果选择了资源管理器，我们可以提供一个资源 ID，或者使用下拉菜单选择我们的 Azure 订阅和要连接的虚拟网络。

如果需要，还可以提供一些额外的选项来转发流量和配置远程网关。以下截图展示了一个示例对等连接设置：

本地数据网关

在某些情况下，创建到 Azure 的 S2S 连接所需的所有要求未满足，但我们仍然需要连接到本地资源。例如，我们需要连接到本地数据库，但我们本地的 VPN 设备不支持与 Azure 的连接。

在这种情况下，我们可以使用本地数据网关，使 Azure 服务能够以安全的方式访问本地数据库。

本地数据网关充当桥梁，允许我们通过 Azure 服务访问本地数据。目前支持的服务包括 Power BI、Microsoft Flow、PowerApps、Azure 分析服务和 Azure Logic Apps。Logic Apps 也可以用来将数据传递到其他服务。

支持的连接器有：

• BizTalk Server 2016

• 文件系统

• IBM DB2

• IBM Informix

• IBM MQ

• MySQL

• Oracle Database

• PostgreSQL

• SAP 应用服务器

• SAP Message Server

• SharePoint Server

• SQL Server

• Teradata

设置本地数据网关是一个两步过程；我们需要先在本地安装代理，然后在 Azure 中配置网关。

本地安装

要开始安装过程，我们需要使用具有 Azure 订阅访问权限的账户进行登录。通常，要访问 Azure 订阅，您需要使用 Microsoft Live 账户或工作/学校/O365/AAD 账户。在此情况下，我们无法使用 Microsoft Live 账户，因为仅允许使用工作账户。登录表单如下所示：

在完成登录过程后，我们需要提供一个新的本地数据网关名称和一个恢复密钥（至少 8 个字符）。恢复密钥在您需要重启服务或更改其配置时使用：

部署完成后，您将看到一个状态页面和一些额外的配置。您可以更改服务设置、网络设置和连接器，或者如果遇到服务问题，可以启动诊断。为了再次访问这些设置，您需要使用恢复密钥：

云服务

本地服务器安装完成后，我们还需要在 Azure 中配置网关。我们需要提供的参数包括资源名称、订阅、资源组和位置。根据其他信息，可用的网关将可以在安装名称下选择：

部署完成后，我们可以使用本地数据网关将 Azure 与本地服务器连接。可以使用这种连接的服务数量有限，但我们可以使用逻辑应用扩展连接到其他服务。配置逻辑应用以使用本地数据网关，使我们能够在单个逻辑应用流程中扩展连接到其他服务，并访问相同的数据。连接虽然有限，但它能在 S2S 不是选项的某些场景下提供帮助。

Azure Stack

微软可能是唯一一个提供真正混合云选项的云服务商。大多数云服务商都提供某种形式的混合云，允许你将本地服务和云服务结合起来。在大多数情况下，通过 IaaS，我们可以轻松地将所有本地资源运行在云端，几乎不需要任何努力。将本地资源迁移到云端是每个云服务商都在提供的选项。

Azure Stack 是唯一一个允许你将云服务在本地数据中心运行的选项。使用 Azure Stack，你可以在自己的环境中运行 IaaS 甚至 PaaS。基本上，Azure Stack 是 Azure 在本地环境中的扩展，它使用与公有版 Azure 相同的架构，但规模要小得多。它以预配置的盒子形式提供，必须从授权供应商处购买，并使用与公有版 Azure 相同的“真实”架构。它支持与公有版 Azure 相同的模型和部署工具。在 Azure 中部署的所有应用和服务都可以在 Azure Stack 中运行，而在 Azure Stack 中部署的所有应用和服务也能在 Azure 中运行。该模型一次开发，随时可以部署到任何地方。

在一些场景中，Azure Stack 可能是一个值得考虑的选择。第一个场景是我们在讨论混合云选项时已经提到的：当我们有法规要求必须将数据保留在本地数据中心或本国境内时。即使是混合云，在这种情况下我们也必须使用 SQL Server。而使用 Azure Stack，这个问题就不存在了；我们可以使用 Azure SQL 数据库，并且即使将数据库保留在本地，也能享受 PaaS 的优势。

在处理大数据集时，延迟和连接性可能成为问题。Azure Stack 是一个解决方案，可以让我们在本地处理数据，然后将其聚合到 Azure 中进行进一步分析，同时在两者之间共享通用的应用逻辑。

另一个例子是那些断开连接或部分断开连接的系统，这些系统偶尔能连接到互联网。使用 Azure Stack，我们可以在飞机或船只等没有持续互联网连接的环境中提供云应用。航空公司可以为客户创建云应用，客户可以在飞机离线时访问该应用。一旦建立互联网连接，就可以进行数据同步，并更新所有内容。

在某些场景下，公司可能拥有多个位置，并且其中一些位置可能需要离线。在这种情况下，云应用程序之前无法作为选项，但通过 Azure Stack，即使在使用云的情况下，所有位置也可以使用相同的应用程序。有些位置可能使用公共 Azure 中的应用程序，而有些可能使用 Azure Stack，但它们具有相同的功能和能力。

Azure Stack 可能是微软合作伙伴的一个有趣选择，这些合作伙伴可能希望在他们的数据中心托管 Azure Stack，并在他们的国家提供 Azure 服务。如果公司或政府机构需要将数据保存在本国，托管服务提供商可以使用 Azure Stack 在该国为这些组织提供 Azure 服务。

架构、模型和部署工具不仅是 Azure 和 Azure Stack 共享的东西。Azure 门户也是两者非常相似的一项内容。Azure Stack 提供了两个版本的门户：用户版和管理版。用户版用于消耗和创建资源，类似于我们在公共 Azure 门户中看到的内容，之后用于配置配额和限制。门户的管理部分对于那些决定使用 Azure Stack 在本地托管 Azure 服务并将其提供给他人的人尤其重要，因为这将使他们能够控制每个客户的限制和支出。

您可以通过接下来的两个截图对比 Azure 和 Azure Stack 门户的设计，第一个是公共 Azure，第二个是Azure Stack。如您所见，设计非常相似，区别在于左上角的名称：

总结

如前所述，混合云已成为大多数组织的现实，无论是因为法规要求，还是投资于本地基础设施。我们已经讨论了如何迁移或将服务扩展到云，管理云中的身份是这一过程的一个非常重要部分。数据很重要，但管理谁可以访问这些数据同样重要。在将本地基础设施扩展到云时，我们可以设置域控制器的副本，并使用 Active Directory 来管理身份和委派访问权限，但这仅限于 IaaS。

要使用 PaaS 管理此项服务，我们必须使用 Azure Active Directory，通常称为身份即服务。在下一章中，我们将讨论 Azure Active Directory，如何使用它，甚至如何将本地身份扩展到 Azure Active Directory。

问题

1. 混合云通常仅仅是一个选择，因为…

   1. 法规

   2. 投资

   3. 两者

2. 我们可以使用…连接本地网络和 Azure。

   1. 站点到站点

   2. ExpressRoute

   3. 两者

3. 为 S2S 所需的 Azure 资源…

   1. 虚拟网络网关

   2. 本地数据网关

   3. 两者

4. 本地网络网关包含…

   1. 虚拟网络

   2. 本地网络

   3. 两者

5. VPN 设备配置可以从 Azure 门户下载。

   1. 正确

   2. 正确，但仅限少数设备

   3. 错误

6. S2S 连接的推荐模式是…

   1. 资源管理器

   2. 经典版

   3. 两者

7. 为确保在混合云中可以使用本地身份，必须部署…

   1. 灾难恢复中的域控制器

   2. Azure 中的域控制器

   3. 始终在线可用性组

8. 本地数据网关可以与…

   1. 所有 Azure 服务

   2. 限量提供的 Azure 服务

   3. 单一的 Azure 服务

9. Azure Stack 是…

   1. 在本地数据中心扩展 Azure

   2. Azure 中本地数据中心的扩展

   3. 在另一个公共云中扩展 Azure

10. Azure Stack 提供…

    1. IaaS

    2. PaaS

    3. 两者

第八章：Azure Active Directory - 云中的身份

我们已经在 Azure 中有了应用程序和数据，本地网络与 Azure 之间的连接也已建立。但是身份验证和授权怎么办？我们如何管理用户的权限和访问？所有这些问题的答案是 Azure Active Directory (AAD)，它允许我们设置基于云的身份认证，并且结合 Azure 基于角色的访问控制 (RBAC)，可以进行用户身份验证并允许他们访问特定资源。

本章将涵盖以下主题：

• Azure Active Directory

• 将本地 AD 与 AAD 同步

• 在 AAD 中管理用户和应用程序

技术要求

本章需要以下内容：

• 一个 Azure 订阅

• 一台运行 Windows Server 2012 R2 或更高版本的本地服务器，已安装域控制器角色

Azure Active Directory

AAD 是一种基于云的目录和身份管理服务，提供应用访问管理和身份保护。它通常被称为 IaaS（基础设施即服务）。

我们已经提到过这个，但还是要再回顾一下。AAD 处于 Azure 管理链的最上层，并且直接与租户相关联。在租户下，我们可以拥有多个订阅，每个订阅下有多个资源组，每个资源组下有多个资源。

单个帐户可以访问多个租户，但每个租户都是隔离的。当用户登录时，会选择默认目录和租户。仅可访问该租户下订阅中的资源。若要管理其他租户中的资源，我们必须切换目录。

AAD 有四个版本：

• Azure Active Directory 免费版

• Azure Active Directory 基本版

• Azure Active Directory Premium P1

• Azure Active Directory Premium P2

Azure Active Directory 基本版提供基于云的应用访问和自助身份管理解决方案，包括基于组的访问管理、云应用的自助密码重置以及 AAD 应用代理。

高级版本提供了额外的功能和企业级管理工具，如动态组、自助组管理和 Microsoft 身份管理（P1），或身份保护和特权身份管理（P2）。Azure Active Directory Premium P2 包含所有 P1 的功能，并增加了身份保护和特权身份管理。

在这里，我们将重点关注由 Azure Active Directory 免费版提供的功能。免费版的目录对象数量限制为 500,000，支持的功能集较为有限，但允许进行用户/组管理、将本地目录同步到 Azure 以及基本的安全报告。它足以提供一般性的图像并介绍 AAD。涵盖所有 AAD 版本提供的功能可能会导致一本单独的书籍，且讨论 Azure 管理时会过于冗长。

创建新目录

即使 AAD 在 Azure 订阅存在的情况下可能已经存在，还是从创建一个新的 AAD（一个新的租户）开始吧。

要创建一个新目录，我们需要提供组织名称、初始域名和国家或地区。请注意，初始域名将用于创建一个初始域名，格式为yourdomain.onmicrosoft.com。域名必须是唯一的，之后可以为您的自定义域名进行自定义。以下截图显示了设置的示例：

创建一个新目录大约需要 1 分钟。新目录创建后，您需要切换目录才能进行管理。请注意，目录名称位于您的个人资料下方。要更改目录，请点击个人资料左侧的“目录”菜单，并从列表中选择目录；它将会打开，如下所示：

在切换目录后，您将进入一个新租户。如果您创建了一个新的目录，该租户将是空的，并且不会分配任何订阅。要开始创建 Azure 资源，您必须在此租户下创建一个新订阅。在空的租户中，您唯一可以管理的是 AAD。Azure Active Directory Free 的概览和管理选项如以下截图所示：

自定义您的域名

我们需要自定义的第一件事是域名。为了将自定义域添加到您的目录，您需要输入一个自定义域名，它实际上是您拥有的公共域名。例如，我将使用我的域名，azuresecurity.cloud：

在添加自定义域名后，需要验证该域名，或者更准确地说，需要验证域名的所有权。为了验证域名所有权，您需要在域名注册商中输入 TXT 或 MX 记录。TXT 记录的示例如下：

在输入记录并点击“验证”按钮后，您可能会收到错误。DNS 记录可能需要最多 72 小时才能传播更改。传播时间取决于您使用的 DNS，但通常不会超过 30 分钟。如果更改尚未传播，您将收到错误，如下图所示：

在变更传播并且验证通过后，您将收到一条消息，说明验证已通过。系统会提供两个额外选项——将此域设为主域，并下载 Azure AD Connect。我们现在忽略 Azure AD Connect，但我建议将自定义域设为主域。这样，自定义域将成为主域并成为首选域后缀。默认的用户名 username@yourdomain.onmicrosoft.com 将变成 username@yourdomain.com。如前面的示例所示，username@azuresecuritycloud.onmicrosoft.com 将变为 username@azuresecurity.cloud。下面是验证过的自定义域截图：

同步 AAD 与本地 AD

我们已经建立了一个新的目录，现在可以开始添加用户并为他们分配访问权限。但很可能我们已经在本地环境中有一个身份解决方案，并且用户已经有了一个身份。如果为用户提供额外的身份可能会导致问题和混淆。用户将遇到问题，无法确定何时使用哪个账户，如果创建了相同或相似的账户，用户会开始输入错误账户的密码……

幸运的是，通过 AAD，我们可以使用 Azure AD Connect，这将允许我们将账户从本地 AD 同步到 Azure，并让用户使用相同的账户进行一切操作。这将使每个人的工作变得更轻松；用户不必再考虑使用哪个账户（因为是同一个账户），管理员也会减少解决问题的数量（账户更少，用户因错误密码尝试而锁定账户的情况也减少）。

此外，通过 Azure AD Connect，我们可以实现单点登录（SSO），这样用户可以通过单次登录过程访问 Azure 和本地资源。用户只需输入一次凭据，相同的凭据就可以用来访问所有他们有权限访问的内容。

为了开始与本地 AD 同步，我们需要进入 Azure AD Connect 面板。在这里，我们可以查看当前的同步状态。如果同步尚未启用，您还会看到 Azure AD Connect 客户端的下载链接，正如您在这里所看到的：

安装 Azure AD Connect

Azure AD Connect 必须安装在本地环境中的一台服务器上。建议您使用一台没有域控制器角色但可以访问域控制器的服务器。安装 Azure AD Connect 的服务器必须能够连接互联网，因为它需要通过互联网同步本地 AD 和 AAD 之间的信息。所有通过 Azure AD Connect 传输的流量都是加密和安全的。

安装向导非常直观，并解释了每个步骤；您只需要按照指南操作（并理解本地 AD 结构）。以下截图展示了安装过程中的第一个屏幕，解释了工具将执行的操作：

您需要做出的第一个选择是是否使用快速设置或自定义设置。如果选择使用快速设置，所有功能都会预先确定。安装将使用默认的安装路径，安装 SQL Express，并使用默认的同步选项，如密码哈希同步、同步所有属性或跨 AD 林同步所有身份。

这里展示了 Azure AD Connect 快速设置的示例：

如果选择使用“自定义”选项，您可以设置一些功能，如安装路径、SQL Server 实例和同步组。例如，您可以使用现有的 SQL Server 实例，或选择只同步特定的用户组。另外，将为同步过程创建一个新的服务帐户，并使用快速设置；在自定义设置中，您可以选择使用现有的服务帐户。以下截图展示了自定义设置的示例：

选择设置后，您需要提供可以启用同步的帐户。首先，您需要提供具有全局管理权限的 AAD 凭据。建议为此创建一个单独的帐户，而不是将其与个人帐户绑定。如果管理员离职，该帐户很可能会被停用，导致同步停止。以下是输入 AAD 帐户的截图：

您需要提供的第二个帐户是 AD DS 企业管理员帐户。对于本地帐户和 Azure 帐户，情况相同：建议使用专门为此服务创建的服务帐户，而不是个人管理员帐户。输入 AD DS 帐户的截图如下所示：

最后，您将进入一个确认安装的屏幕。此屏幕将再次列出所有将要执行的操作，并允许您在配置完成后启用同步过程的启动。您可以在以下截图中看到确认屏幕：

安装完成后，系统会提供一个状态报告，并给出建议，告诉你还需要做些什么。例如，在我的域中，未启用 Active Directory 回收站。此过程将检测到这一设置，并建议你启用它，如下图所示：

在 Azure 门户中，在 Azure AD Connect 选项卡下，您将看到新的状态。Azure AD Connect 的链接消失了，您可以看到同步已启用，并且最后同步是不到 1 小时前。根据本地环境，您还可以配置联合身份验证、单点登录（SSO）和一些其他设置。以下截图展示了一个已同步目录的示例：

管理 AAD

同步完成后，所有同步的用户将出现在 AAD 中。在 AAD 中，帐户可以来自两个不同的来源：AAD 和 Windows 服务 AD。来自 Windows Server AD 来源的帐户是已从本地 Active Directory 同步的帐户。AAD 帐户仅存在于 AAD 中，这些帐户是在 Azure 中创建的。还有第三种类型的帐户，即 Microsoft 帐户。这些帐户实际上是 Microsoft Live 帐户，可以添加到您的 AAD 中。

AAD 中的用户类型可以是Member或Guest。成员是 AAD 中的帐户（带有您的域名），而访客是来自其他 AAD 或 Microsoft Live 帐户的帐户。唯一的例外是，当 Microsoft Live 帐户用于创建 AAD 时，该帐户可以是您的 AAD 成员。外部 AAD 帐户（来自您租户外部的 AAD 帐户）也是如此；这些帐户只能在用于创建新租户时具有成员身份。以下截图展示了一个成员列表的示例：

创建新用户

来自 AAD 来源的帐户是已在 Azure 中创建的帐户。我提到过，对于 Azure AD Connect，您应该使用服务帐户进行同步。请注意，该帐户必须具有全局管理员角色。以下是如何创建此类帐户的示例：

创建新 AAD 用户时，默认的用户角色是“用户”。在创建过程中或创建后，您可以将此选项更改为管理员。

管理用户选项和权限

创建用户后，您可以管理该用户并分配不同的角色和权限。除了管理选项外，您还可以在活动部分监视和审计用户的活动。以下截图展示了一个用户资料的示例：

最重要的管理选项之一是角色分配。在“目录角色”下，您可以选择可以分配给用户的多个预定义角色。每个角色都有相应的说明，如下所示：

用户可以被添加到组中以简化管理。例如，我们可以将多个角色分配给组，通过将用户分配给某个组，用户将自动获得该组中所有分配给该组的角色。组可以被分配并同步，类似于帐户。分配的组起源于 AAD，并通过 Windows Server AD 进行同步。以下是分配给 AAD 用户的组的示例：

在 AAD 中注册应用程序

为了使用 AAD 作为应用程序的认证方法，您需要在 AAD 中注册该应用程序。这将创建两个对象：一个应用程序对象和一个服务主体。

要注册一个新的应用程序，我们需要进入 AAD 面板中的应用程序注册，并选择“新建应用程序注册”。我们需要提供的信息包括应用程序名称、应用程序类型（Web 应用程序 / API 或本地应用）以及登录 URL（这里我使用本地主机作为示例）：

创建应用程序只是第一步，因为你还需要额外的配置才能使用这个注册。在应用程序创建后打开的第一个屏幕中，有两个非常重要的部分：应用程序 ID 和对象 ID。这些将在稍后用于通过 AAD 来识别应用程序。换句话说，应用程序使用 ID 来联系 AAD 并获取有关用户是否被授权访问该应用程序的信息。用于认证的 ID、应用程序或对象取决于认证方法。以下是一个示例：

为了为已注册的应用程序提供访问权限，我们需要配置权限和密钥。要为应用程序提供权限，我们必须在设置面板中的所需权限下设置所需的权限。在这里你需要非常小心，因为使用过多权限可能会让你陷入陷阱。

我常常看到人们给只需要基本认证的应用程序授予所有可能的权限。如果分配了太多权限，这可能会被利用，并且会带来很高的安全风险。以下截图展示了一个示例权限面板：

一旦我们拥有了 ID 和权限，最后缺少的是密钥。应用程序将使用 ID 和密钥来授权访问 AAD。要添加一个新的密钥，我们必须提供一个描述、过期时间（EXPIRES）和密钥的值（VALUE）。过期时间可以设为 1 年、2 年或永不过期。我强烈建议不要使用永不过期，因为这又是一个可能的安全风险。密钥的值并不是实际的密钥；该值将被加密，然后提供一个新的值。在输入所有值后，点击保存。以下是添加新密钥的示例：

保存后，将提供密钥的新值。确保复制此值，因为这是你唯一能获取它的时机。一旦离开这个控制面板，你将无法重新获取此值。以下截图显示了一个生成的密钥示例（请注意控制面板顶部的警告）：

使用在 AAD 中注册的 ID 和密钥的应用程序将能够与 AAD 进行通信。这些应用程序不必托管在 Azure 中；它们可以用于本地应用程序或其他云中的应用程序。

请注意，当使用 Azure Web 应用程序时，你可以通过在 Web 应用程序控制面板中使用身份验证/授权来实现类似的目标。这个选项会自动创建所有必要的对象，并为 Web 应用程序提供一个 ID 和密钥。会创建最小的权限，这是一件好事，但如果你需要为应用程序提供更多权限，则需要手动操作。

我们已经提到，在这个过程中将会创建两个对象：一个应用程序对象和一个服务主体。

现在是讨论多租户概念的好时机。多租户应用程序允许来自多个租户的用户使用相同的应用程序和资源。例如，我们可以为客户开发一个应用程序，并将其托管在我们的订阅中（以及我们的租户）。然后，我们可以为多个客户设置应用程序的访问权限，并允许他们使用自己的 AAD 进行身份验证和授权。在这个概念中，来自多个租户的用户使用相同的应用程序和相同的资源。如果使用多租户方法，应用程序将在主租户中拥有一个应用程序对象，并为每个目录提供多个服务主体。基本上，一个应用程序对象与应用程序之间是“一对一”的关系，与服务主体之间是“一对多”的关系。

基于角色的访问控制

我们已经提到过 RBAC 以及它如何帮助管理和维护云资源。RBAC 允许你使用 AAD 帐户在 Azure 租户的不同级别上设置不同的角色和权限。为了提供租户中的用户管理权限，我们必须使用 AAD 控制面板。这些权限不会被进一步传递。在租户下，我们可以有多个订阅，并且每个订阅的参与是单独进行的。

将用户分配为管理员（或其他角色）将自动为他们在该订阅下的所有资源组和资源提供相同的角色。如果我们在资源组级别为用户分配角色，该角色将自动为该资源组中的所有资源提供权限。将角色访问权限授予单个资源，将仅给予用户对该资源的访问权限。

在为这些级别（订阅、资源组、资源）分配权限的过程中，我们使用相同的选项：访问控制（IAM）。在这里，我们选择角色、分配类型和用户。您也可以使用组或服务主体代替用户。以下截图展示了如何将新贡献者添加到订阅/资源组/资源：

您可以选择多个预定义角色，创建自定义角色，或将用户分配到多个角色。如果用户被分配多个冲突的角色，将应用最高权限角色。

例如，Reader 角色只允许您查看资源的信息，不能进行任何更改。如果同时分配了 Reader 角色和 Contributor 角色（允许您进行更改），则将应用 Contributor 角色。

下面是可用角色的截图：

如前所述，组可以在任何级别分配角色。在这种情况下，所有属于该组的用户将自动被分配该角色。

服务主体通常用于为需要更改或创建某些内容的应用程序设置访问权限。例如，服务主体常用于允许 Azure DevOps 在发布过程中访问您的订阅，并创建或编辑部署所需的资源。

总结

AAD 提供 Azure 中的身份验证和授权。与 RBAC 一起，它允许您控制谁可以做什么以及在哪里做。这些工具是您管理和保护云资源时的第一道防线。

现在，我们将集中讨论在 Azure 中还需要保护哪些内容以及如何保护我们的数据和其他资源。保护 Azure 与保护我们本地基础设施不同，且需要不同的思维方式。在 第九章 Azure 安全性与管理 中，我们将讨论如何加固 Azure 安全性以及有哪些可用的工具来保护我们。

问题

1. AAD 位于…

   1. 租户

   2. 订阅

   3. 资源组

2. 一个帐户可以属于多个租户：

   1. 是的

   2. 不是

3. AAD 可以包含 Microsoft Live 账户：

   1. 是的

   2. 不是

4. AAD 可以与 Windows Server AD 同步：

   1. 是的

   2. 不是

5. Azure Active Directory 免费版的限制为…

   1. 5,000 个对象

   2. 500,000 个对象

   3. 5,000,000 个对象

6. 要设置自定义域…

   1. 您可以选择任何域

   2. 您必须拥有该域

   3. 您必须使用 .onmicrosoft.com

7. 要验证您的自定义域，您必须使用…

   1. MX 记录

   2. TXT 记录

   3. 任意

   4. 两者

8. 使用 RBAC，您可以为…分配角色

   1. 订阅

   2. 资源组

   3. 一个资源

   4. 上述所有内容

9. 角色可以分配给…

   1. 用户

   2. 组

   3. 两者

10. 要从应用程序设置 AAD 登录，您必须…

    1. 在 AAD 中注册应用程序

    2. 为应用程序创建一个 AAD 组

    3. 两者

第九章：Azure 安全性与管理

安全性常常是许多组织推迟迁移到云端的主要原因之一。原因在于存在太多未知因素；人们不理解安全性是如何设置的，且往往不信任任何人管理他们的数据。我常年听到的一句话是：“如果它离开了我们的数据中心，我就不知道它发生了什么。”

事实上，你的数据在 Azure 中可能比在本地数据中心更为安全。在本章中，我将尽力解释 Azure 安全性是如何设置的，并消除关于云安全的疑虑。

本章将涵盖以下主题：

• Azure Active Directory 多重身份验证

• Azure 网络安全

• Azure 防火墙

• 数据加密

• Azure 密钥保管库

• Azure 安全中心

• 高级威胁防护

• 按需访问

技术要求

本章需要以下内容：

• 一个 Azure 订阅

• PowerShell

• Azure PowerShell

揭开云安全的面纱

那么，Azure 真的有多安全呢？我们可以从非常安全开始说起。

微软正在大力投资 Azure，特别是在 Azure 安全性方面。Azure 提供了广泛的合规性服务，包括 HIPAA、FFIEC、PCI DSS、ISO 9001 和 ISO 27001，仅举几例。

Azure 安全性始于物理安全。数据中心有专门的安全人员全天候值守；所有区域都被摄像头和报警系统覆盖，且有多个外围检查层级。

要进入 Azure 数据中心，你需要通过多个检查点并提供有效的身份验证和授权。身份验证采用多因素认证，除了提供 PIN 或密码外，你还必须通过生物识别和卡片读取器检查。

数据中心内的所有内容都经过加密和保护。所有数据在静态时都被加密，即便有人设法偷走了含有你数据的磁盘，它也是无法使用的。所有数据传输也都按照行业标准进行加密。

数据安全的另一个重要方面是冗余，以确保数据永远不会丢失。Azure 默认的冗余级别是 3（三个）。例如，当你创建一个新的资源，像是 Azure 虚拟机时，系统会创建一个有三个副本的磁盘。这保证了数据始终可用，即使其中一个磁盘发生故障，仍然有两个额外的副本。冗余 3 同样适用于备份发电机；如果一个发生故障，还有两个备份。

即使微软也深度参与了 Azure 安全性，但仅仅将数据放入 Azure 并不足以确保它的安全。与微软的合作负责安全的一部分，并提供各种工具和服务来帮助你保持安全。然而，如何实施这些工具并将它们投入使用，仍然由你负责。

保护你的身份

保护你的身份是 IT 安全中非常重要的一部分。大多数数据泄露是由于社会工程学或钓鱼攻击所致。因此，在大多数情况下，泄露的凭证是导致数据泄露的主要原因。

Azure Active Directory 提供了一些工具来提高安全性，其中最突出的一个是多重身份验证（MFA）。MFA 要求用户在登录后提供额外的安全身份验证。用户提供用户名和密码后，还需要进行额外的操作来证明身份。可以使用许多不同的工具进行附加检查，如生物识别读卡器或卡片读卡器，但最常用的工具是移动设备。登录后，用户会在移动设备上收到通知，并需要提供额外的确认。通知可以通过电话（用户需要在通话中提供代码）、短信（用户收到需要在登录时提供的代码）或应用程序（与用户账户连接，并需要确认用户正在尝试登录）进行。

启用 MFA 后，泄露的凭据不再那么令人担忧，因为窃取用户名和密码已不足以访问数据。需要访问用户的移动设备以授权你的登录尝试，这使得数据泄露变得更加困难。

启用多重身份验证

在 Azure Active Directory 中启用 MFA 非常简单和快速。在 Azure Active Directory 中，在用户管理下需要选择多重身份验证。截图中展示了一个示例：

一个新窗口会打开，在其中完成所有的 MFA 设置。你可以为单个用户设置个性化的设置，或者批量更新多个用户。在服务设置下，你还可以编辑 MFA 可用的选项，并选择电话、短信、移动应用或令牌。要启用单个用户的 MFA，选择该用户并在右侧的设置中点击启用，如下所示：

拥有全局管理员角色的用户可以免费使用 MFA。因此，对于管理员来说，没有理由不添加额外的安全层，因为泄露的管理员账户可能造成的损害远超过普通用户。然而，如果你想为所有用户启用 MFA，则需要额外的许可证。MFA 随 Azure Active Directory Premium 提供，但也可以按用户或每次登录为独立服务进行授权。

其他身份安全选项

Azure Active Directory 还提供其他可以帮助你增强安全性的服务。

其他服务如条件访问或特权身份管理可以帮助我们提高安全性并防止未经授权的访问。我们可以使用审计日志和风险性登录来查看谁尝试访问服务和数据以及何时访问。Azure Active Directory 提供了大量的日志，可以用于审计。大部分这些功能都需要 AAD Premium，并且在基础版或免费版许可证中不可用。

保护网络

保持安全的下一步是保护我们的网络资源。如果网络没有保护，可能会导致数据泄露或服务拒绝。即使 Azure 网络堆栈提供了许多安全功能，例如默认的 DDOS 保护或网络安全组，有时这些也不够，我们需要采取额外的措施。

Azure Firewall

Azure Firewall 是一个托管的、基于云的网络安全服务，保护 Azure 虚拟网络资源。它是一个作为服务提供的防火墙，内置高可用性和可扩展性。

使用 Azure Firewall，您可以创建、执行和记录应用程序及网络连接策略。为虚拟网络资源分配的静态公共 IP 地址可以让外部防火墙识别来自您的虚拟网络的流量。该服务与 Azure Monitor 集成，用于日志记录和分析。

准备环境

Azure Firewall 要求连接到一个名为 AzureFirewallSubnet 的子网。我们可以在创建新的 Azure Firewall 过程中创建一个新的 Azure VNet 和子网。但由于我已经有了想要使用的 VNet，我将向之前创建的PackVnet中添加一个新的子网。

以下截图展示了如何为 Azure Firewall 添加新子网的示例：

创建 Azure Firewall

要创建一个新的 Azure Firewall，我们需要提供订阅、资源组、名称和位置。此外，还需要提供虚拟网络和公共 IP 地址。在这两种情况下，我们可以选择使用现有资源或创建新资源。请注意，对于现有虚拟网络，必须存在AzureFirewallSubnet。示例参数如截图所示：

部署完成后，Azure Firewall 已准备好使用，我们可以开始配置。此时，请注意私有 IP 地址（记住它或写下来），因为我们将在接下来的几个步骤中使用它。

以下是 Azure Firewall 面板的截图：

我们也可以使用 ARM 模板来部署 Azure Firewall。

以下是部署新 Azure Firewall 的 ARM 模板：

{
    "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "location": {
            "type": "string"
        },
        "resourceGroup": {
           "type": "string"
        },
        "azureFirewallName": {
            "type": "string"
        },
        "vnetName": {
            "type": "string"
        },
        "vnetAddressSpace": {
            "type": "string"
        },
        "subnetAddressSpace": {
            "type": "string"
        },
        "publicIpAddressName": {
            "type": "string"
        },
        "subnetId": {
            "type": "string"
        }
    },
    "variables": {
        "networkApiVersion": "?api-version=2018-08-01"
    },
    "resources": [
        {
            "apiVersion": "2018-08-01",
            "type": "Microsoft.Network/publicIpAddresses",
            "name": "[parameters('publicIpAddressName')]",
            "location": "[parameters('location')]",
            "sku": {
                "name": "Standard"
            },
            "properties": {
                "publicIPAllocationMethod": "Static"
            },
            "tags": {}
        },
        {
            "apiVersion": "2018-07-01",
            "type": "Microsoft.Network/azureFirewalls",
            "name": "[parameters('azureFirewallName')]",
            "location": "[parameters('location')]",
            "dependsOn": [
                "[resourceId(parameters('resourceGroup'), 'Microsoft.Network/publicIpAddresses', parameters('publicIpAddressName'))]"
            ],
            "properties": {
                "ipConfigurations": [
                    {
                        "name": "IpConf",
                        "properties": {
                            "subnet": {
                                "id": "[parameters('subnetId')]"
                            },
                            "publicIPAddress": {
                                "id": "[resourceId(parameters('resourceGroup'), 'Microsoft.Network/publicIpAddresses', parameters('publicIpAddressName'))]"
                            }
                        }
                    }
                ]
            },
            "tags": {}
        }
    ]
}

Azure Route Table

现在我们要创建一个路由表，将所有流量通过 Azure Firewall。要创建一个新的 Azure 路由表，我们需要提供名称、订阅、资源组和位置。我们还可以选择启用或禁用 BGP 路由传播。以下截图展示了如何创建新的路由表：

在创建路由表后，我们需要将其与子网关联并创建路由。在路由表面板的子网选项下，选择“关联”，如图所示：

要将路由表与子网关联，我们需要提供虚拟网络和该网络中的子网。在以下示例中，选择了虚拟网络 PacktVnet，子网为默认子网：

最后，我们需要添加一条路由。我们需要提供路由名称、地址前缀、下一跳类型和下一跳地址。对于下一跳类型，我们需要选择虚拟设备。Azure 防火墙作为服务（Firewall as a Service），但仍属于这一类别。为了实现类似效果，我们可以使用任何虚拟设备，在其中使用 IaaS 模式的第三方防火墙。在下一跳地址下，我们输入 Azure 防火墙的私有 IP 地址（我之前提到过，您需要记住这个地址）。路由设置的示例如下所示：

来自PacktVnet虚拟网络默认子网的所有流量现在都被路由到我们的 Azure 防火墙。我们可以继续并创建规则，决定允许或拒绝的内容。

配置 Azure 防火墙

在 Azure 防火墙面板中的规则下，我们有三个选项：NAT 规则集合、网络规则集合和应用规则集合。根据我们的需求，可以使用 NAT 规则重写源地址。我们可以使用网络规则定义允许哪些源流量到达哪些目标，或者通过应用规则定义允许或拒绝的 FQDN。Azure 防火墙中规则面板的示例如下所示：

让我们创建一条规则，允许默认子网的流量访问 VSTS。首先，我们需要提供名称、优先级和动作（允许或拒绝）。然后，我们需要定义源地址、协议：端口和目标 FQDN。可选地，我们可以为规则添加标签。对于源地址，我将添加一个子网，因为我希望从子网中的任何地方都能访问 VSTS。如果您希望限制 FQDN 的访问来源，可以使用更小范围的 IP 地址。

协议将是 HTTP 和 HTTPS，目标 FQDN 为 *.visualstudio.com。新的应用规则示例如下所示：

请注意，您可以在一个集合中拥有多个规则，并且可以将适用于特定服务的所有规则创建在一个集合中。这使得管理和维护 Azure 防火墙规则变得更加容易。

如果一切配置正确，您可以进入位于默认子网中的虚拟机（VM），并打开任何浏览器。您应该能够访问任何 VSTS 集合，但其他任何内容都将被禁止访问。

其他网络安全选项

除了使用默认的 Azure 组件，如 NSG、路由表，甚至 Azure 防火墙之外，还有许多作为虚拟设备提供的第三方防火墙。虚拟设备作为 Azure 虚拟机（VM）设置，网络安全领域的大多数行业领导者都可以在 Azure 上使用。管理虚拟设备包括两个部分：管理 Azure 虚拟机和管理防火墙。我们已经讨论过如何管理 Azure 虚拟机，至于防火墙的管理则取决于制造商，和在本地管理这些防火墙没有什么不同。

除此之外，我们可以通过 Azure Monitor 和 Log Analytics 收集网络资源的日志，帮助我们审核和故障排除 Azure 网络。还有一个工具可以帮助我们监控 Azure 网络，它被称为 Network Watcher。Azure Network Watcher 提供了监控、诊断、查看指标并启用或禁用虚拟网络资源日志的工具。

使用 Azure Network Watcher，我们可以监控端点、网络流量、跳数、VPN 和其他一切与网络相关的内容。它是一个非常棒的工具，因为它允许我们以图形方式显示网络架构，并更轻松地定位问题。

加密

安全中的另一个重要步骤是加密。我们希望我们的数据始终保持加密——无论是在静态存储时还是在传输中。一切都具有冗余性，确保没有数据丢失，即使有三份加密的副本，我们也可以选择使用地理复制和其他设置来创建额外的冗余。

默认情况下，Azure 中的所有资源在静态存储时都会进行加密。但有时我们需要额外的安全性来确保数据得到更好的保护。例如，我们的 Azure 虚拟机磁盘在 Azure 数据中心内是加密的，即使磁盘未经授权访问，也没人能够读取磁盘上的数据。但如果磁盘被下载呢？在这种情况下，磁盘是可以被使用的。数据可以被读取或附加到另一个虚拟机，或者可以使用该磁盘创建一个虚拟机。

我们可以通过使用Azure Key Vault来应用额外的加密并使我们的资源更加安全。

Azure Key Vault

Azure Key Vault 用于存储机密、密钥和证书。它是一个集中式管理解决方案，用于保存、分发和控制机密、密钥和证书。在部署过程中可以调用 Azure Key Vault 中的机密，以防止密码以明文形式显示。密钥可以用来加密存储和磁盘。你可以在 Azure Key Vault 中使用证书，并在部署过程中将其分配给服务以保障 SSL 和 TLS 安全。

Azure Key Vault 大大减少了机密被意外泄露的可能性，通过使用密钥加密增加了资源静态存储时的安全性，并通过分配证书增加了传输过程中的安全性。

创建 Azure Key Vault

创建新的密钥库时，我们需要提供名称、订阅、资源组和位置。我们还可以选择更改定价层、分配访问策略，并提供虚拟网络访问。定价层有两个选项：标准和高级。唯一的区别是高级支持硬件安全模块（HSM）。默认分配的策略是授予创建密钥库的人员所有访问权限。您还可以在创建过程中或之后随时添加策略。虚拟网络访问默认授予您订阅中的所有网络，但您可以编辑此设置，只授予特定网络访问权限。这里显示了默认设置的示例：

创建 Azure 密钥库相对快速，应该在一分钟内完成。请注意 DNS 名称，因为稍后会用到它。以下截图显示了一个 Azure 密钥库页面的示例：

要部署 Azure 密钥库，您可以使用以下 ARM 模板：

{
    "$schema": "http://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "name": {
            "type": "String"
        },
        "location": {
            "type": "String"
        },
        "sku": {
            "defaultValue": "Standard",
            "allowedValues": [
                "Standard",
                "standard",
                "Premium",
                "premium"
            ],
            "type": "String",
            "metadata": {
                "description": "SKU for the vault"
            }
        },
        "accessPolicies": {
            "defaultValue": [],
            "type": "Array",
            "metadata": {
                "description": "The access policies defined for this vault."
            }
        },
        "tenant": {
            "type": "String"
        },
        "enabledForDeployment": {
            "type": "Bool"
        },
        "enabledForTemplateDeployment": {
            "type": "Bool"
        },
        "enabledForDiskEncryption": {
            "type": "Bool"
        },
        "networkAcls": {
            "type": "Object",
            "metadata": {
                "description": "The network firewall defined for this vault."
            }
        }
    },
    "resources": [
        {
            "type": "Microsoft.KeyVault/vaults",
            "name": "[parameters('name')]",
            "apiVersion": "2016-10-01",
            "location": "[parameters('location')]",
            "properties": {
                "enabledForDeployment": "[parameters('enabledForDeployment')]",
                "enabledForTemplateDeployment": "[parameters('enabledForTemplateDeployment')]",
                "enabledForDiskEncryption": "[parameters('enabledForDiskEncryption')]",
                "accessPolicies": "[parameters('accessPolicies')]",
                "tenantId": "[parameters('tenant')]",
                "sku": {
                    "name": "[parameters('sku')]",
                    "family": "A"
                },
                "networkAcls": "[parameters('networkAcls')]"
            }
        }
    ]
}

添加密钥和机密

密钥库创建完成后，我们可以添加机密和密钥。

首先，我们添加一个密钥，以便稍后用于加密。密钥可以生成、导入或从备份中恢复。如何添加新密钥的示例如下：

密钥库中的密钥可以用来提供创建资源时需要的密码。在使用 ARM 模板创建资源时，您需要提供密码。为了防止密码以明文显示，您可以使用密钥库中的机密提供密码的值，防止密码泄露。机密可以手动创建或从证书中导入。以下示例展示了如何手动添加新的机密：

与这两个示例类似，您可以添加证书。证书可以生成或导入。请注意，如果您想将这些证书用于公开的应用程序，必须使用由公认证机构颁发的有效证书。

加密存储账户

如前所述，大多数资源默认是加密的，Azure 存储账户也不例外。然而，您可以选择使用自己的密钥来加密存储。要使用自己的密钥，您必须选择“使用您自己的密钥”，这将允许您选择将用于加密的密钥库和密钥。以下截图显示了一个示例：

加密存储的时间取决于存储账户中的数据量。对于较小的存储，几秒钟就能完成，但对于大型存储账户，可能需要几个小时才能完成加密过程。如果您在生产环境中加密大型存储账户，请尽量在非工作时间进行，因为这可能会影响性能。

加密数据库

Azure SQL 数据库使用 TDE 进行加密。在创建新的 Azure SQL 数据库时，默认启用此选项。如果您有更早创建的数据库，可以将此选项更改为启用并保存。Azure SQL 数据库窗口中的透明数据库加密选项如下所示：

当 Azure SQL 数据库启用 TDE 时，数据和备份在静止状态下被加密。但如果您下载或导出备份，则情况会有所不同。为了确保数据库在离开 Azure 数据中心后仍然加密，我们可以使用自己的密钥进行加密。为此，我们需要使用 Azure PowerShell。

安装 Azure PowerShell

PowerShell 是基于 .NET Framework 的命令行外壳和脚本语言。系统管理员使用它来自动化任务和管理操作系统。

Azure PowerShell 是一个 PowerShell 模块，允许我们自动化和管理 Azure 资源。

要安装 Azure PowerShell，我们需要先安装 Windows PowerShell。幸运的是，Windows PowerShell 从 Windows 7（客户端操作系统）和 Windows Server 2012 R2（服务器操作系统）开始，微软的操作系统就已经预装了 Windows PowerShell。

要安装 Azure PowerShell，我们需要运行以下命令：

Install-Module -Name AzureRM

接下来，我们需要导入模块：

Import-Module AzureRM

如果模块已安装，我们可以使用以下命令更新它：

Update-Module -Name AzureRM

成功导入模块后，我们可以使用以下命令连接到 Azure：

Connect-AzureRmAccount

使用您自己的密钥进行 Azure SQL 数据库加密

要使用自己的密钥进行 Azure SQL 数据库 TDE，我们必须执行几个命令。

首先，我们需要将我们的 Azure Active Directory 身份登录到 Azure SQL 服务器：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$server = Set-AzureRmSqlServer -ResourceGroupName $dbRG -ServerName $dbServer -AssignIdentity

其次，我们必须授予服务器对 Key Vault 的权限：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$KeyVaultName = 'PacktKV';
Set-AzureRmKeyVaultAccessPolicy -VaultName $KeyVaultName -ObjectId $server.Identity.PrincipalId -PermissionsToKeys get, wrapKey, unwrapKey

第三，我们将 Key Vault 密钥添加到服务器并设置 TDE 保护级别：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$rgName = 'PacktKeyVault';
$KeyVaultName = 'PacktKV';
$keyEncryptionKeyName = 'MyKey';
$keyEncryptionKeyUrl = (Get-AzureKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;

<# Add the key from Key Vault to the server #>
Add-AzureRmSqlServerKeyVaultKey -ResourceGroupName $dbRG -ServerName $dbServer -KeyId $keyEncryptionKeyUrl
<# Set the key as the TDE protector for all resources under the server #>
Set-AzureRmSqlServerTransparentDataEncryptionProtector -ResourceGroupName $dbRG -ServerName $dbServer -Type AzureKeyVault -KeyId $keyEncryptionKeyUrl
<# To confirm that the TDE protector was configured as intended: #>
Get-AzureRmSqlServerTransparentDataEncryptionProtector -ResourceGroupName $dbRG -ServerName $dbServer

最后，我们启用 TDE：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$dbName = 'Demo'
Set-AzureRMSqlDatabaseTransparentDataEncryption -ResourceGroupName $dbRG -ServerName $dbServer -DatabaseName $dbName -State "Enabled"

Azure PowerShell 脚本中的所有参数都可以编辑。要在任何 Azure SQL 数据库中使用任何 Key Vault 执行此操作，请相应地更改参数的名称。

加密虚拟机（VM）磁盘

同样的操作也适用于 Azure 虚拟机（VM）。磁盘默认加密，并且数据在静止状态下受到保护。但正如前面所提到的，当磁盘被导出或下载时，它将不再受到保护。通过使用 Key Vault，我们可以为 Azure VM 磁盘设置额外的加密保护，确保任何情况下的数据安全。如果我们查看任何 Azure VM 中的磁盘，我们会看到磁盘未加密，如下所示：

要启用磁盘加密，我们首先必须启用用于磁盘加密的 Key Vault：

Set-AzureRmKeyVaultAccessPolicy -VaultName 'PacktKV' -ResourceGroupName 'PacktKeyVault' -EnabledForDiskEncryption

现在我们可以启用磁盘加密：

$VMRG = 'PacktIaaS';
$VMname= 'DBserver';
$rgName = 'PacktKeyVault';
$KeyVaultName = 'PacktKV';
$KeyVault = Get-AzureRmKeyVault -VaultName $KeyVaultName -ResourceGroupName $rgname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;

 Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $VMRG -VMName $vmName -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId;

该命令将在 5 到 15 分钟内运行，具体时间取决于磁盘的大小。收到完成消息后，我们可以再次检查磁盘状态，查看加密是否已启用：

Azure 安全中心

Azure 安全中心提供了一个集中式的安全管理和高级威胁防护平台，涵盖 Azure 和混合云环境。通过安全中心，我们可以在工作负载中应用安全策略，限制对威胁的暴露，并检测和响应攻击。它分为两个层级：免费版和标准版。免费版默认启用，提供安全策略、持续的安全评估以及可操作的安全建议，以保护 Azure 资源。标准版扩展到私有或混合云工作负载，并增加了高级威胁检测。高级威胁检测使用内置的行为分析和机器学习技术来识别攻击和零日漏洞，减少暴露于任何类型的攻击。

Azure 安全中心概述

Azure 安全中心概览仪表板提供了您 Azure 和非 Azure 工作负载的安全状态的即时总结，使您能够发现并评估工作负载的安全性，识别和减轻风险。我们可以看到不同的指标，这些指标使我们能够立即识别任何安全风险，并根据最佳实践看到需要改进的推荐事项。Azure 安全中心中的概览仪表板示例如下图所示：

Azure 安全中心是一个功能复杂的服务，提供了很多选项。与许多其他服务一样，它值得一本专书，而很难在一个章节中涵盖所有选项。我们将专注于一些最重要的选项，这些选项将帮助您立即提升安全性。

Azure 安全中心推荐

Azure 安全中心分析您的安全设置并将其与最佳实践进行对比。基于此，您可以看到在安全中心 - 推荐中需要实施的建议变更。建议分为四类——计算与应用、数据与存储、网络、以及身份与访问（预览）。所有资源可以有三种状态：绿色、橙色和红色。绿色表示所有安全最佳实践已启用，并且资源是安全的；橙色表示应实施但不关键的建议；红色表示存在高安全风险的建议，应该立即实施。我们还可以看到基于已实施和待解决的内容，可能存在的安全风险的安全得分。安全中心 - 推荐仪表板如下图所示：

以“计算”部分为例。在这里，我们可以找到与计算资源（虚拟机和计算机、应用服务（预览）以及云服务）相关的所有安全问题列表。在这些推荐列表中，我们可以看到问题描述以及这些问题影响了多少资源。在此示例中，我们可以看到列表顶部列出，8 个虚拟机中有 10 个没有启用端点保护，并且被标记为红色：

启用端点保护

作为示例，让我们点击这个推荐并解决它。会打开一个新窗口，列出没有启用端点保护的虚拟机（VM）。我们可以选择特定的虚拟机或所有虚拟机，并选择安装端点保护。安装将开始，完成后我们会看到推荐已解决：

类似这样，我们可以解决大多数安全中心的推荐。我们点击推荐并按照步骤操作。然而，有些推荐无法通过这种方式解决，需要额外的步骤。在这种情况下，你将被引导到文档中，描述该问题并提供解决步骤。

Azure 安全中心警报

警报是 Azure 安全中心的另一部分；这些警报非常有用，可以帮助你检测潜在问题。安全警报部分可以让你追踪并查看何时有未授权访问你的资源的尝试。在 Azure 安全中心的警报概览中，你可以看到可能的资源攻击列表，并且能查看它们发生的时间，如下图所示：

如果我们选择任何警报，我们会看到更多信息，如日期、使用了什么凭证、登录尝试次数以及其他信息。在“地理和威胁情报信息”下，我们可以看到攻击发生的地点，提供了详细的地理位置信息。根据登录信息和地理位置，我们可以判断这是否是合法用户，还是对资源进行的暴力破解攻击。如果有一个有效用户在已知地点尝试了三次，我们可以推测这可能是用户忘记了密码。

如果我们有 50 次来自未知用户的登录尝试，且来自未知地点，我们可以推测这是一次暴力破解攻击。在“修复步骤”下，我们会有如何防止未来类似攻击的说明。这里展示了一个可疑的认证活动示例：

在底部，我们有两个附加操作——“调查”（Investigate）和“查看操作手册”（View playbooks）。调查允许我们查看事件的详细信息。查看操作手册允许我们创建（或使用现有的）逻辑应用程序，如果将来发生类似事件，它将采取相应措施。通过逻辑应用程序，我们可以设计步骤和操作来防止攻击。例如，如果尝试使用无效用户登录超过三次，它将添加一个 NSG 规则，阻止访问资源 48 小时。调查详情的示例如下所示：

即时访问

Azure 安全中心的最佳功能之一就是即时访问。即时访问可以防止访问 Azure 虚拟机，除非该访问已被特别请求。默认情况下，所有管理端口都被关闭，您需要从特定的 IP 地址请求访问，并且仅在短时间内启用此访问。

要在 Azure 虚拟机上设置即时访问，请进入安全中心的即时访问面板并从列表中选择一个或多个虚拟机，如下所示：

在选择要启用即时访问的虚拟机后，将会打开一个新面板。在这里，我们必须定义默认关闭且仅在请求时启用的端口。默认端口包括 SSH（22）、RDP（3389）和 WinRM（5985和5986），但您可以删除和添加任何您需要的端口。以下截图显示了默认设置的示例：

启用即时访问后，连接虚拟机的选项将不可用。要访问虚拟机，您必须在 Azure 安全中心请求访问。在这里，您需要定义要打开的端口、允许从哪些 IP 地址连接以及允许连接的时长（1 到 3 小时）。以下是请求面板的示例，您可以看到如何从当前 IP 地址打开 RDP 端口一小时：

通过即时访问（Just-in-Time access），您可以控制谁可以访问您的虚拟机（VM）、何时访问以及从哪里访问。未经授权的访问降到最低，您的虚拟机得到了保护。另一个令人惊叹的功能是，在标准层的 Azure 安全中心中，您可以注册并保护私有和混合云中的资源。此选项不仅仅限于 Azure 虚拟机，还可以为本地虚拟机启用。

总结

微软非常重视 Azure 安全。采取了许多步骤来确保您的资源在 Azure 中得到保护和安全。除此之外，微软还提供了许多额外的服务，帮助我们进一步提高安全性。为了确保安全并实现最大化保护，需要微软和我们的共同努力，我们需要利用 Azure 提供的安全服务，除了微软已经在保护我们的数据和服务之外。此外，除了被声明为安全服务的安全功能（例如密钥保管库或安全中心），还有很多服务内置的安全功能（例如 Azure SQL 防火墙或网络安全组）。

随着我们逐渐接近尾声，我们将回顾我们所学的内容。在最后一章，我们将讨论我们之前讨论过的服务以及使用它们的最佳实践。基础设施即代码（Infrastructure-as-Code）是云计算中非常重要的一部分，我们将讨论一些工具，这些工具可以通过自动化任务帮助我们与 Azure 进行工作。使用 Azure 门户是了解 Azure 的一个很好的方式，但如果你想充分利用它，基础设施即代码是你需要使用的工具。

问题

1. Azure 中的一切都是冗余的，拥有多少份副本？

   1. 一

   2. 两个

   3. 三个

2. 大多数数据泄露是由…引起的

   1. 暴力破解攻击

   2. 泄露的凭证

   3. 病毒

3. MFA 代表…

   1. 多因素认证

   2. 多因素授权

   3. 多因素激活

4. 多因素认证（MFA）可以配置为使用：

   1. 电话呼叫

   2. 短信

   3. 移动应用程序

   4. 以上所有

5. Azure 防火墙是…

   1. 基础设施即服务

   2. 防火墙即服务

   3. 两者

6. Azure 资源可以使用…进行加密

   1. Azure 提供的密钥

   2. 自定义密钥

   3. 两者

7. 要使用自定义密钥，我们必须使用…

   1. Azure 安全中心

   2. Azure 密钥保管库

   3. 两者

8. Azure 安全中心提供…

   1. 安全管理

   2. 高级威胁防护

   3. 两者

9. Azure 安全中心可以用于保护…

   1. Azure 资源

   2. 本地资源

   3. 两者

10. 即时访问提供…

    1. 我们对虚拟机（VM）管理访问的控制

    2. 实时监控虚拟机的访问

    3. 两者

第十章：最佳实践

在这最后一章中，我们将回顾到目前为止所学到的内容，并强调一些最佳实践。一些简单的技巧可以帮助您从一开始就正确设置，并为以后节省大量麻烦。最佳实践将帮助您在管理和故障排除中更好地跟踪事物并注意到错误。我们将添加一些安全提示以及如何避免最常见的错误。我们将使用基础设施即代码（IaC）作为工具，帮助我们在 Azure 中的日常任务中取得成功。使用 Azure 门户简单且有助于学习，但要充分利用 Azure，我们必须使用 ARM 模板、Azure PowerShell 或 Azure CLI。最后，为了扩展 IaC，我们将讨论配置即代码，并介绍期望状态配置（DSC）和 Azure 自动化。

本章将涵盖以下主题：

• Azure 最佳实践

• 基础设施即代码

• ARM 模板

• Azure PowerShell

• Azure CLI

• 配置即代码

• 期望状态配置

• Azure 自动化

技术要求

对于本章，您将需要以下内容：

• Azure 订阅

• PowerShell

• Azure PowerShell

• Azure CLI

Azure 最佳实践

有许多细小的事项需要注意，否则可能会在长期内出现问题。当您管理单个订阅和少量资源时，可能看起来很简单，不重要去创建一些基本规则。但随着订阅和资源数量的增加，您可能会遇到混乱，此时纠正错误可能为时已晚。在这些情况下，纠正错误和回到正确的轨道将会很困难。

命名约定

对于订阅、资源组和资源设置命名约定非常重要。您的第一个订阅可能会有类似Pay-as-you-go的名称。如果您只有一个订阅，这并不重要。但如果您最终拥有 5 个、10 个或 100 个订阅，并且它们都命名为Pay-as-you-go，情况将会变得混乱。这些订阅将具有不同的订阅 ID，您可以利用此信息对它们进行区分，但这可能会很困惑。订阅可以重新命名，您应该利用此选项。您可以以不同的方式组织订阅，具体取决于您的需求，如基于部门、应用程序、环境等等。

例如，您可以每个部门拥有多个订阅。这将帮助您分离成本和消耗，并查看每个部门在资源上的支出情况。在这种情况下，您可能希望将订阅重命名为类似HumanResources、Finances、IT等。如果每个部门都有不同的生产、测试和开发环境，您可以在订阅名称中添加环境，并类似于HumanResources-prod、HumanResources-test和HumanResources-dev。

你可以根据需求将类似的原则应用于资源组的命名。假设我们使用一个单一的订阅，并希望将部门、环境或应用程序添加到资源组的名称中。在这种情况下，资源组的名称可能是IT-helpdesk-prod。或者，如果我们为每个部门分配一个订阅，资源组的名称可能是helpdesk-prod。

但是，当你有多个订阅，并且所有订阅都列在资源组视图中时，如果一些资源有相似的名称，可能会造成混淆，因此最好在资源组名称中包含订阅名称。例如，你可能有Finance和HR两个订阅，它们各自都有一个名为Employees的应用程序。如果你只是使用产品和环境来命名资源组，那么这两个生产环境的资源组将会被命名为Employees-prod。它们虽然在不同的订阅中，但当所有订阅中的资源组列出时，可能会造成混乱。在这种情况下，将完整路径包含在资源组名称中，将订阅名称作为资源组名称的前缀，是一个有益的做法。

对于资源，最好也有一定的命名规范。设计可能依赖于不同的因素，但我建议使用所有可用的变量，以避免混淆。例如，假设我们的 IT 部门有自己的订阅，并使用一个名为helpdesk的应用程序。该应用程序需要两个虚拟机（Web 和数据库服务器），并且有生产、开发和测试环境。在这种情况下，我们会有六个虚拟机被同一个应用程序使用，用于不同的目的和环境。在这种情况下，使用诸如订阅、环境、产品、资源类型和资源用途等参数会很有帮助。因此，生产环境中的虚拟机名称可能是it-helpdesk-prod-VM-web和it-helpdesk-prod-VM-db。还有一种情况是你有多个虚拟机具有相同的角色，比如负载均衡器后面的多个 Web 服务器。在这种情况下，最好在名称中添加数字，像这样it-helpdesk-prod-VM-web-01、it-helpdesk-prod-VM-web-02，依此类推。

公共端点

通常，如果没有必要，避免暴露公共端点是一个好主意，尤其是当我们谈论管理和行政时。暴露你的 Web 应用的端点是你可能希望做的事情，但为什么要暴露数据库呢？这只会带来额外的安全风险，并增加你的数据被泄露的可能性。管理方面也是如此；应该避免暴露 RDP、SSH 或任何其他可以用来管理和行政资源的端口。

如果我们使用 IaaS 中的数据库，最佳实践是只允许通过端口 1433 在 Azure Vnet 内访问数据库，或者甚至限制访问到特定的子网。使用 NSG 和 应用程序安全组（ASG）来设置访问权限，并仅在需要时允许访问。例如，我们可以使用 NSG 和 ASG 设置对数据库的访问，但仅当流量来自特定子网（使用 NSG）并且来自属于 Web 服务器组的服务器时（使用 ASG）。这一方法不限于端口 1433 和 MS SQL Server；您可以将这种方法应用于 IaaS 中使用的任何其他数据库以及这些数据库使用的任何端口，如 Oracle 的 1521、IBM DB2 的 50000、MySQL 的 3306，或任何您定义的自定义端口。

PaaS 中的数据库、Azure SQL 数据库以及其他数据库 PaaS 选项提供了防火墙保护。通过防火墙保护，您可以限制能够连接到数据库的 IP 地址。请确保保持防火墙的更新，并移除任何不必要的 IP 地址。此外，Azure SQL 数据库防火墙中有一个选项可能会带来额外的风险。该选项允许 Azure 服务访问您的 Azure SQL 数据库，如下所示：

默认情况下，此选项是开启的，看起来似乎启用它是有道理的。大多数人会认为：“是的，我希望我的 Azure 服务能够连接到我的数据库。”但这个选项只检查连接是否来自 Azure；它并没有检查连接是否来自您的订阅或租户。如果保持此选项开启，就允许任何人创建一个 Azure 账户并尝试访问您的数据库，因为如果连接来自 Azure，则防火墙规则将不再适用。

连接到数据库仍然需要用户名和密码，但这为攻击者提供了机会。在这种情况下，微软要求在创建试用订阅时提供信用卡信息，这对于我们来说是非常有利的，因为任何账户都可以追踪到其所有者。如果有人通过这种方式成功访问数据库，那么该人是可以被追踪的，但您可能想要禁用此选项，以防止任何未经授权的访问。

对于其他不应公开暴露的后端服务，也可以采用类似的方法。这些服务可以是数据库、不同的连接器、业务逻辑以及各种 API 等。不要暴露任何不需要暴露的内容。在 IaaS 场景中，可以使用 NSG 和 ASG 来限制访问。当使用 PaaS 时，也有不同的策略可以采用。如我们之前提到过，Azure SQL 数据库具有防火墙。对于 Web 应用程序，我们可以使用隔离的应用服务计划，只允许通过 Azure 虚拟网络访问。类似地，大多数 PaaS 服务都可以连接到 Azure VNet，并且我们可以设置从 Azure 虚拟网络内部访问服务。然后，NSG 和 ASG 规则也可以应用于这些服务。

限制对 Azure 虚拟机管理端口的访问是我们需要注意的另一个事项。例如，公开 RDP 访问到虚拟机的互联网可能会带来严重后果。我测试了将默认的 RDP 端口开放，并通过 Azure 安全中心跟踪访问尝试。在一个月内，有超过 150,000 次未授权的访问尝试。这些尝试大部分使用的是管理员、admin、sysadmin 和 root（超过 80%的尝试使用了这四个用户名），所以幸运的是 Azure 虚拟机不允许使用这些名字。

有几种方法可以限制对 Azure 虚拟机管理的访问：

• 禁用管理端口的公共访问，并通过安全连接管理 Azure 虚拟机。这可以是 P2S、S2S 或 Azure ExpressRoute。通过使用安全连接，您将管理访问限制为来自可信位置的授权用户。

• 如果无法使用安全连接，限制对可信公共 IP 地址的访问。使用 NSG 来限制对仅能通过预先允许的 IP 地址访问的 Azure 虚拟机的访问。以下截图展示了如何使用 NSG 限制访问的示例：

• 使用即时访问（Just in Time Access）来访问 Azure 虚拟机。在 Azure 中设置即时访问简单快捷。启用此选项时，您需要创建一个来自预定 IP 地址并且只限于一段时间的访问请求。这样，除非创建了特定的请求来允许管理访问，否则访问将被阻止。以下是一个示例，展示了如何为用户当前的 IP 地址开放 RDP 端口一个小时的请求：

其他需要考虑的事项

除了命名标准或端点安全性，我们还需要注意很多细节：

• 尽可能使用 PaaS。Microsoft Azure 提供了多种选择，但 IaaS 通常会更昂贵。在某些情况下，您别无选择，但使用 PaaS 可以降低订阅成本。

• 使用监控和日志记录服务。每个 Azure 服务都有某种形式的日志记录、监控和警报功能。尝试通过 Azure Monitor、Azure Network Watcher 或 Log Analytics 等服务扩展这些功能。这些工具可以帮助你跟踪问题和性能变化。

• 使用 Azure Advisor 应用一些最佳实践。Azure Advisor 会分析订阅中的资源，比较设置与最佳实践，并提供需要实施的建议，以提高性能或降低成本。

• 类似于 Azure Advisor，Azure Security Center 提供增强资源安全性的建议。Security Center 会比较你当前的安全设置，并结合安全事件，生成增加安全性的建议。

• 加密数据。尽管大多数 Azure 服务默认启用了加密，但那是静态加密。为了在导出或备份后保护我们的数据，我们需要应用额外的加密。

• 加密连接并使用 HTTPS。如果数据在传输过程中暴露，那么安全性就没有意义，因此我们也需要考虑这一点。

• 如果遇到问题，检查 Azure 服务健康状态。这可以节省你数小时的故障排除时间。你将能够发现性能问题，或者查看某个服务是否不可用，并自动连接到 Azure 查看出什么问题。这可能是 Azure 在全球或数据中心级别的问题，作为第一步检查是否是这种情况，可以节省大量时间。

• 在可能的情况下配置自动扩展。Azure 提供的一个优势是你只需为实际使用的资源付费。如果正确设置，自动扩展可以在负载增加时增加实例的规模/数量，而在负载减少时减少规模。这可以随着时间的推移节省大量费用。

• 尽可能使用 Azure Active Directory 认证。大多数服务可以设置为使用不同的认证方式，或者仅为特定服务创建本地账户。这种方式很难审计或跟踪访问情况。使用 AAD 账户可以提供更多的洞察，并使跟踪变得更加容易。

• 启用服务的审计功能。一些服务，例如 Azure SQL，内置了审计功能。在可能的情况下启用此功能，或者使用 Log Analytics 记录所有内容。

• 尽可能设计为具有韧性。拥有冗余服务可能会花费大量资金，在某些情况下甚至会使我们的成本翻倍。然而，将冗余服务部署在另一个 Azure 数据中心可以提高服务的可用性。如果服务出现问题，不论是你的服务问题还是 Azure 数据中心级别的问题，你都可以切换到冗余副本。

• 始终为故障做好规划。这不仅仅是 Azure 或云相关的最佳实践——为故障做规划是 IT 的最佳实践。尝试预测不同的场景以及如果服务失败会发生什么。然后，尽量修复可能的问题并防止故障发生。

• 尝试启用多因素认证。由于这可能增加成本，因此并非总是可行，预算也可能会阻止你实现这一目标。在这种情况下，至少为管理员启用 MFA；管理员的 MFA 是免费的。

• 在 Azure 虚拟机上安装端点保护。端点保护将提供实时保护，防止恶意或不需要的软件被安装，并可能对你的系统造成损害。

• 安装 Azure 虚拟机的最新补丁。定期安装补丁有双重效果：安全补丁能提高安全性，其他更新可以提高性能。

• 定期分析性能。仅仅拥有自动扩展有时并不足够。尽量在可能的情况下手动监控资源的性能。你可以发现性能问题，或者看到某些服务没有被充分利用。你可以使你的服务表现得更好，并节省成本。

基础设施即代码

基础设施即代码（IaC）是 Azure 最佳实践中的一个非常重要的部分。使用 Azure 门户简单且非常适合创建单一资源并学习，但如果我们要创建复杂的环境，IaC 是我们想要使用的工具。例如，创建一个 Azure 虚拟机时，Azure 门户是一个不错的选择。只需 3-5 分钟即可完成新的虚拟机向导并完成所有步骤。但如果我们每天都需要创建新的虚拟机，或者创建数十个甚至数百个虚拟机呢？在这种情况下，我们可能希望使用某种自动化来简化工作，这正是 IaC 的作用所在。为了在 Azure 上工作，我们有几种可用的选项：

• ARM 模板

• Azure PowerShell

• Azure CLI

我们已经提到过 ARM 模板。ARM 模板是存储 Azure 资源信息的 JSON 文件，可以用于部署（或编辑/更新现有资源）。

要回答 Azure PowerShell 是什么，我们首先需要回答 PowerShell 是什么。PowerShell 是一种基于 .NET 框架的任务驱动型命令行脚本语言。它用于自动化任务并通过命令行管理操作系统和进程。Azure PowerShell 是一个 PowerShell 模块，提供了一组 cmdlet（命令），允许我们管理 Azure 资源。

Azure CLI，或称 Azure 命令行界面 (CLI)，是微软的跨平台命令行工具，用于管理 Azure 资源。它支持 macOS、Linux 和 Windows，并且无论选择哪个平台，都能提供相同的体验。Azure CLI 1.0 的第一个版本也叫做 X-Plat CLI，是用 JavaScript 编写的。最初，它是为了支持 Azure 服务管理 API 而创建的，后来才添加了 Azure 资源管理支持。Azure CLI 2.0 从一开始就为 ARM 架构而构建，并且是用 Python 编写的。

安装工具

在本节中，我们将讨论各种工具，通过这些工具你可以开始不同的安装过程。

ARM 模板

ARM 模板实际上不需要任何特殊要求，但您可以使用各种工具来帮助管理它们。由于它们是 JSON 文件，您可以使用任何文本编辑器创建一个，但使用集成开发环境（IDE）会更方便。我的推荐是使用 Visual Studio 或 Visual Studio Code。通过使用 Visual Studio 或 Visual Studio Code，您可以连接到代码库并设置版本控制，从而跟踪模板随时间的变化。然而，我们也可以使用 ARM 模板进行部署，通过调用 API 或直接从 Azure 门户进行，无需任何额外的工具。

Azure PowerShell

要安装 Azure PowerShell，首先需要安装 Windows PowerShell。幸运的是，在客户端操作系统中，Windows 7 及更高版本已经预装了该工具，服务器操作系统则在 Windows Server 2008 R2 及更高版本中预装。因此，我们缺少的只是 Azure PowerShell 模块。要安装该模块，我们需要运行 PowerShell 并执行以下命令：

Install-Module -Name AzureRM

您将收到一条消息，要求您从PSGallery安装模块，选择“是”或“全部是”。安装模块后，我们需要使用以下命令导入它：

Import-Module AzureRM

最后，我们可以使用以下命令登录：

Connect-AzureRmAccount

这将打开一个窗口，您需要在其中输入凭据并授权访问我们的订阅。

由于 Azure PowerShell 每三周发布一个新版本，您需要保持它的更新。要安装最新版本，我们需要运行以下命令：

Update-Module -Name AzureRM

Azure CLI

安装 Azure CLI 取决于我们使用的平台。

对于 Windows，我们需要从aka.ms/installazurecliwindows下载安装程序，并像这样运行安装程序：

要在 macOS 上安装，我们需要运行以下命令：

brew update && brew install azure-cli

在 Linux 上的安装依赖于发行版。例如，在使用yum的发行版（如 RHEL 或 CentOS）上，我们需要运行三条命令。

首先，我们导入 Microsoft 仓库密钥：

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

其次，我们创建仓库信息：

sudo sh -c 'echo -e "[azure-cli]\nname=Azure CLI\nbaseurl=https://packages.microsoft.com/yumrepos/azure-cli\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/azure-cli.repo'

最后，我们运行安装：

sudo yum install azure-cli

安装过程可能会依赖于平台，但完成安装过程后，在所有平台上运行 Azure CLI 命令是相同的。要使用 Azure CLI 登录 Azure，我们需要运行以下命令：

az login

这将显示一条消息（如下所示），并打开一个新的浏览器会话，您需要授权访问 Azure：

所有 Azure CLI 的命令都以az开头。要获取更多信息，可以运行以下命令：

az --help

您将看到以下输出：

您可以将--help与列表中的任何命令结合使用，以获取有关特定命令的更多信息。

使用基础设施即代码（IaC）创建 Azure 资源

为了更好地理解 ARM 模板、Azure PowerShell 和 Azure CLI 如何工作，我们来看一个简单的例子，并使用每个工具创建一个 Azure Web 应用。

使用 ARM 模板创建 Azure Web 应用

使用 ARM 模板，我们需要两个 JSON 文件。第一个文件定义了需要创建的内容，第二个文件包含在部署过程中定义的参数。因此，基本上，第一个文件包含了需要创建的内容（在我们的示例中是应用服务计划和 Web 应用），而第二个文件包含了服务的部署位置、大小、名称等信息。

这是模板文件：

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"webAppName": {
"type": "string",
"metadata": {
"description": "Base name of the resource such as web app name and app service plan "
},
"minLength": 2
},
"sku":{
"type": "string",
"defaultValue" : "S1",
"metadata": {
"description": "The SKU of App Service Plan, by defaut is standard S1"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {
"webAppPortalName": "[concat(parameters('webAppName'))]",
"appServicePlanName": "[concat( parameters('webAppName'),'-AppServicePlan')]"
},
"resources": [
{
"apiVersion": "2017-08-01",
"type": "Microsoft.Web/serverfarms",
"kind": "app",
"name": "[variables('appServicePlanName')]",
"location": "[parameters('location')]",
"comments": "This app service plan is used for the web app and slots.",
"properties": {},
"dependsOn": [],
"sku": {
"name": "[parameters('sku')]"
}
},
{
"apiVersion": "2016-08-01",
"type": "Microsoft.Web/sites",
"kind": "app",
"name": "[variables('webAppPortalName')]",
"location": "[parameters('location')]",
"comments": "This is the web app, also the default 'nameless' slot.",
"properties": {
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]"
},
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]"
]
}
]
}

这是参数文件：

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"webAppName": {
"value": "packt-demo-arm-webapp-01"
},
"sku": {
"value": "S1"
},
"location": {
"value": "[resourceGroup().location]"
}
}
}

保存这两个文件。现在，让我们创建一个资源组来进行部署。创建一个名为 packt-demo-arm 的新空资源组。打开模板部署并选择自定义模板。在编辑模板下，加载模板文件，在编辑参数下，加载参数文件。选择订阅和资源组 packt-demo-arm（如果您之前没有创建，您可以在此处创建）。所有其他字段应自动从参数文件加载，如此示例所示（记得接受条款和条件）：

部署完成后，您应该能找到应用服务计划和 Web 应用，如下图所示：

我们可以使用相同的 ARM 模板来部署新的 Web 应用，只需更改参数文件中的资源名称或层级；我们不需要在每次部署时都通过 Azure 门户的部署向导。这可以节省大量时间，特别是当我们需要部署多个 Web 应用时。

使用 Azure PowerShell 创建 Azure Web 应用

要使用 Azure PowerShell 创建相同的资源，我们需要执行一个脚本，该脚本将创建资源组、应用服务计划和 Web 应用。脚本以参数开始，然后执行三个 cmdlets 来创建我们所需的所有部署内容。请确保您已经连接到 Azure 的 Azure PowerShell：

$ResourceGroupName = "packt-demo-ps"
$webappname="packt-demo-ps-webapp-01"
$location="West Europe"
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $location
New-AzureRmAppServicePlan -Name $webappname -Location $location -ResourceGroupName $ResourceGroupName -Tier Free
New-AzureRmWebApp -Name $webappname -Location $location -AppServicePlan $webappname -ResourceGroupName $ResourceGroupName

执行脚本后，您应该会收到以下输出：

如果我们进入 Azure 门户，我们应该能找到一个新的资源组及其中的新项目：

要启动新的部署，我们只需更改参数值并再次执行。我们可以通过仅更改 Web 应用的名称并在同一资源组中部署站点来快速部署多个网站。例如，如果我需要在同一资源组中部署四个相同网站的实例，我可以仅更改 $webappname 的值，并将末尾的数字更改为 packt-demo-ps-webapp-01、packt-demo-ps-webapp-02、packt-demo-ps-webapp-03 和 packt-demo-ps-webapp-04。这样，我就可以通过修改一个值来运行脚本，而不需要每次都经过 Azure 门户的向导。

要清理部署，您可以执行一个命令，删除资源组及其中所有资源：

$ResourceGroupName = "packt-demo-ps"

Remove-AzureRmResourceGroup -Name $ResourceGroupName -Force

您应该会收到如下输出，并可以在 Azure 门户中验证资源组是否已经不存在：

使用 Azure CLI 创建 Azure Web 应用程序

现在，让我们使用 Azure CLI 重复相同的过程。 您可以看到 Azure CLI 脚本结构与 Azure PowerShell 非常相似：

$webappname='packt-demo-cli-webapp-01'
$ResourceGroupName ='packt-demo-cli'
az group create --location westeurope --name $ResourceGroupName
az appservice plan create --name $webappname --resource-group $ResourceGroupName --sku Free
az webapp create --name $webappname --resource-group $ResourceGroupName --plan $webappname

执行脚本后，您应该会收到一个以此结尾的长输出：

如果我们转到 Azure 门户，应该会找到新的资源组及其中的新项：

与 Azure PowerShell 类似，要重新部署，只需编辑参数值。 要清理部署，您可以执行一个命令，该命令将删除资源组以及资源组中的所有资源：

$ResourceGroupName ='packt-demo-cli'
az group delete --name $ResourceGroupName

您应该收到命令完成的输出消息，并在 Azure Portal 中验证资源组不再存在。

部署多个资源

每种部署方法都可以用来在单个脚本中部署多个资源。 我个人最喜欢的工具肯定是 Azure PowerShell，但这可能是因为我的系统工程背景。 多年来，我一直在使用 Windows PowerShell，并发现 Azure PowerShell 最易于使用。 这并不意味着 ARM 模板或 Azure CLI 比 Azure PowerShell 落后，我认为开发人员会觉得这些其他工具更为熟悉。

例如，为了尽可能简单地部署多个资源，我将创建一个 Azure PowerShell 脚本，该脚本将在单次运行中部署多个网站。 您也可以使用其他工具做类似的事情：

$ResourceGroupName = "packt-demo-ps-multiple"
$webappname="packt-demo-ps-webapp"
$location="West Europe"
$NumberOfWebApps= 4

New-AzureRmResourceGroup -Name $ResourceGroupName -Location $locationNew-AzureRmAppServicePlan -Name $webappname -Location $location -ResourceGroupName $ResourceGroupName -Tier Standard

$i=1

Do

{

New-AzureRmWebApp -Name $webappname'-0'$i -Location $location -AppServicePlan $webappname -ResourceGroupName $ResourceGroupName

} While (($i=$I+1) -le $NumberOfWebApps)

在上述输出中，您将收到每个创建的资源的消息，并且可以在 Azure 门户中验证部署。 如果脚本执行成功，您应该能看到所有资源，如下所示：

要清理部署，您可以使用我们之前使用的相同命令：

$ResourceGroupName = "packt-demo-ps-multiple"
Remove-AzureRmResourceGroup -Name $ResourceGroupName -Force

我们可以在 Azure 中部署任何类型的资源时使用类似的方法； 例如，我们可以部署多个 Azure VM。 让我们执行一个类似的脚本，这次部署两台 Web 服务器：

$ResourceGroupName = "packt-demo"
$location = "westeurope"
$vmName = "packtdemoVM"
$NumberOfServers= 2

New-AzureRmResourceGroup -Name $ResourceGroupName -Location $location

$i=1

Do

{

New-AzureRmVm -ResourceGroupName $ResourceGroupName -Name $vmName"-0"$i -Location $location -VirtualNetworkName $vmName"-Vnet" -SubnetName $vmName"-subnet" -SecurityGroupName $vmName"-nsg" -PublicIpAddressName $vmName"-IP-"$i -OpenPorts 80,443,3389

} While (($i=$I+1) -le $NumberOfServers)

该脚本应该部署一个虚拟网络、一个子网和一个 NSG。 这些资源将在 VM 之间共享。 我们不希望创建不必要的资源，因为这将使 VM 能够通信。 对于每个 VM，我们将创建一个 NIC 和一个磁盘。 此处显示了脚本为两台服务器创建的资源示例：

现在，我们可以编辑此脚本以部署更多服务器，部署到新的资源组或新的子网，或更改任意数量的参数以影响部署结果。

因此，使用此脚本，我可以部署 1 到 100 台甚至更多服务器。 现在，想象一下，您需要在 Azure Portal 中使用向导部署 100 个 VM。 哪个任务需要更多时间？ 我认为我们可以认识到使用 IaC 进行部署具有多重好处，并且可以显著简化我们的工作。

代码配置

IaC 仅仅是自动化的第一步。在我们使用代码部署服务器后，仍然需要对其进行配置。手动配置服务器可能比部署它们还要花费更多时间。幸运的是，存在作为代码的配置选项，可以完成配置步骤。有很多不同的配置工具，但我们将探讨 Azure 自动化，作为 Azure 原生的配置即代码工具。

Azure 自动化可用于自动化和调度不同的任务。谈到作为代码的配置时，Azure 自动化使用 DSC。DSC 是 PowerShell 中的声明式管理平台，用于系统的配置、部署和管理。

使用 Azure 自动化应用 DSC

要创建一个新的 Azure 自动化帐户，我们需要提供帐户的名称、订阅、资源组和位置。另一种选择是创建“以管理员身份运行帐户”。以管理员身份运行帐户是一个服务主体，用于通过 Azure 自动化管理 Azure 资源时进行身份验证。我强烈建议您创建这个帐户，这样在有了帐户的情况下管理会更轻松。以下是创建 Azure 自动化帐户的示例：

使用 Azure 自动化，您可以执行各种操作、调度和运行脚本、管理资源等等。值得一提的是，您可以管理 Azure 和本地资源，以及其他云中的资源。在这里，我们将专注于将 DSC 应用于 Azure 虚拟机。

在 Azure 自动化中管理 DSC 是通过“状态配置（DSC）”来完成的。在这里，我们可以管理节点、配置、已编译的配置，并访问画廊。我们将会看到这些设置中的每一项，除了画廊。画廊包含一些可以使用或编辑的 DSC 脚本，您可以根据自己的需求进行修改。以下是状态配置（DSC）窗格的示例：

DSC 使用一个脚本，该脚本应用于选定的节点。节点可以是虚拟机（VM）或虚拟机组。这些虚拟机可以是 Azure 虚拟机或本地虚拟机。

要开始新的配置，我们需要一个 DSC 脚本。我们将使用的脚本确保服务器上安装了 IIS 角色。将脚本保存在本地，并确保文件名与配置的名称相同。在我们的示例中，名称应该是 webserverDSC：

configuration webserverDSC {
   Node WebServer {
      WindowsFeature IIS {
         Ensure = 'Present'
         Name = 'Web-Server'
         IncludeAllSubFeature = $true
      }
   }
}

在“配置”下，选择“新建配置”，并导入之前保存的脚本：

导入脚本后，需要编译它才能继续。选择已导入的脚本，新的窗口将会打开。选择“编译”，并等待编译完成。编译时间将取决于脚本的大小，但在这种情况下，应该不会超过 2-3 分钟。以下是配置窗格的示例：

在脚本编译完成后，我们可以继续并将配置应用到节点。进入节点页面，选择“新建”，将打开一个新的面板。在虚拟机列表中，我们可以选择希望应用 DSC 的虚拟机。我将选择我在本章中使用上一个脚本创建的虚拟机 packtdemoVM-01。

在注册页面下，我们可以选择几个选项。我们可以选择将使用哪个注册密钥、节点配置名称、刷新频率、配置模式频率、配置模式、是否允许模块覆盖或在需要时重新启动节点，以及重新启动后的操作。我将选择我们刚刚创建的新配置，并将其余设置保持为默认。以下是节点注册的示例：

注册完成后，我们需要等待初步检查并确保配置已应用到我们的服务器。这可能需要一些时间，具体取决于所选的频率以及我们想要应用的 DSC 配置的复杂性。如果你监控节点面板，添加的节点将从待处理状态变为进行中，直到最终达到合规状态。以下截图显示了一个已应用配置的节点：

在节点合规后，我们可以验证配置是否已应用。进入我们在节点注册时使用的虚拟机面板，找到公共 IP 地址。打开浏览器，尝试访问 http://'youripaddress'。你应该能看到默认的 IIS 页面，这将确认 IIS 已经在服务器上安装：

总结

微软 Azure 是一个拥有众多服务和选项的云平台。将这些服务结合在一起，产生了无限的可能性。我们提到了一些最佳实践，它们可以指导你创建高效且安全的云环境。基于这些，你可以根据自己的服务和需求扩展并创建你自己的规则和实践。

尽管我们已经完成了本书的内容，但我们所覆盖的仅仅是 Azure 提供的一小部分。涵盖所有可用的服务在一本书中几乎是不可能的，如果我们想要深入探讨每个服务，可能最终每个服务都会成为一本单独的书。本书旨在帮助你理解云设计、云服务以及云中的最佳实践，以便为你提供坚实的基础，帮助你开始云之旅，并在此基础上构建更多的知识。

学习 Azure 是一个持续的过程，因为每天都会添加新的服务和选项。我使用 Azure 已经很长时间了，几乎每次打开 Azure 门户时，我都会发现新的东西。但是，如果你掌握了云计算模式和最佳实践，理解新服务就不是问题。如果你理解了当前使用的服务，理解新功能和服务就不成问题，并且你会很快找到将它们运用到实际中的方法。

希望你喜欢这本书，并至少从中学到了一些知识！

问题

1. 资源的名称应包含…

   1. 尽可能多的信息

   2. 尽可能少的信息

   3. 基本信息

2. 公共终端节点应当是…

   1. 始终暴露于互联网访问

   2. 仅在需要时暴露于互联网访问

   3. 永不暴露于互联网访问

3. 要控制对 Azure 虚拟机的管理访问权限，您可以使用…

   1. 网络安全组（NSGs）

   2. 随时访问权限

   3. 两者

4. 多因素认证是…

   1. 所有用户免费

   2. 管理员免费

   3. 所有用户收费

   4. 管理员收费

5. IaC 代表…

   1. 基础设施即代码（IaC）

   2. 基础设施即配置

   3. 信息即代码

6. ARM 模板是一个…

   1. 脚本

   2. JSON 文件

   3. TXT 文件

7. Azure 命令行工具是…

   1. Azure PowerShell

   2. Azure CLI

   3. 两者

8. 使用 IaC，我们可以…

   1. 部署单个资源

   2. 部署多个资源

   3. 仅部署相同类型的资源

9. DSC 代表…

   1. 所需状态配置（DSC）

   2. 数字签名配置

   3. 所需的扩展配置

10. 在 Azure 自动化中应用 DSC 的步骤是…

    1. 导入脚本、编译脚本并注册节点

    2. 注册脚本、应用到节点并编译配置

    3. 注册节点、编译脚本并应用配置