方案 1 解决方案 - 架构全局规模和安全访问

  • 10 分钟

在上一单元中，你完成了一个有关内容分发网络的全局规模的方案。 在本单元中，你将查看一种可能的解决方案以及一些需要考虑的事项。

查看时，应将所提供的解决方案与在上一单元中制定的解决方案进行比较。 通常情况下，任何问题都存在不止一种正确的解决方案，但总会有一些权衡取舍。 你的解决方案中的哪些事项与建议的事项不同？ 你的解决方案中是否存在需要重新考虑的内容？ 所提供的解决方案中是否有在你的解决方案中可得到更彻底的解决的内容？

部署选项和配置

首先要考虑的是应选择 Azure SQL 的哪个部署选项。 虽然 Azure 虚拟机 (VM) 中的 SQL Server 可以正常工作，但平台即服务 (PaaS) 产品/服务可能更为适合且管理开销更低。

客户正在使用公共语言运行时 (CLR)，这是一个实例范围功能。 Azure SQL 托管实例是唯一的 PaaS 部署选项，它支持实例范围内的功能（如 CLR、Service Broker 和数据库邮件）。 因此，Azure SQL 托管实例可以使客户移至 PaaS 产品/服务，而不必将 CLR 应用程序重写为与 Azure SQL 数据库兼容的解决方案（例如弹性数据库作业）。

接下来要做的决策涉及到服务层级。 由于客户希望隔离其读取和写入工作负载，因此使用业务关键服务层级是实现这一目标的最简单方法。 业务关键服务层级在后台运行 Always On 可用性组。 其中一个次要副本可用于只读工作负载。

业务关键只是此处用于隔离读取和写入工作负载的配置的一半。 该方案指出，客户需要能够在隔离读取和写入工作负载的同时，在多个查询同时发生的情况下扩展到多个区域。

异地复制和自动故障转移组，这两个选项也许能够应对这一挑战。 但是，Azure SQL 托管实例当前不支持异地复制。 因此，使用自动故障转移组是唯一可帮助此方案获得全局读取规模的选项。

由于客户使用的是自动故障转移组，因此是否需要业务关键服务层级将取决于其分析工作负载所需的只读终结点的数量。 在业务关键服务层中的自动故障转移组中，客户将获得三个可读终结点：

  • 主区域可用性组中的一个次要副本
  • 故障转移组的次要副本（这是次要区域中数据库的主要副本）
  • 次要区域可用性组中的次要副本

如果分析工作负载不需要所有这些可读副本，则使用“常规用途”可能是更为经济高效的解决方案。

选择最适当的身份验证方法

考虑到需要尽可能创建并使用最安全技术，此方案的另一部分涉及到确定每个应用程序或人员连接到解决方案的最佳方式。 如果你将此方案分解，有四个需要访问 Azure SQL 托管实例的单独客户端：

  • 在 Azure VM 上运行的应用程序
  • 加入域的非 Azure 计算机上运行的应用程序
  • 来自未加入域的非 Azure 计算机的 SQL 管理工具（SQL Server Management Studio、Azure Data Studio、PowerShell）的 DBA 或其他用户
  • 在你无法在其中更改驱动程序或连接字符串的非 Azure 计算机上运行的旧版应用程序

让我们从选择身份验证方法以及一些其他注意事项和约束的方面来了解这些客户端。

在 Azure VM 上运行的应用程序

通常情况下，对于在 Azure 虚拟机上运行的应用程序，Azure 资源的托管标识是推荐的无密码身份验证形式。

加入域的非 Azure 计算机上运行的应用程序

对于非 Azure 计算机，则不能选择使用托管标识。 对于在 Azure 之外的已加入域（假设该域已与 Microsoft Entra ID 联合）的计算机上运行的应用，通过 Microsoft Entra ID 的集成身份验证是推荐的身份验证方法。

如果非 Azure 计算机未加入域，则可以：

  1. 在 Microsoft Entra ID 中为应用程序创建应用程序标识。
  2. 将证书与应用程序标识关联。
  3. 通过提供客户端 ID 和证书修改应用程序以获取 Azure SQL 数据库的令牌。

虽然证书必须包含私钥且它必须被部署在托管应用程序的计算机上，但你至少避免了在应用程序代码或配置中对应用程序机密进行硬编码。 （需要使用证书指纹来配置应用。）

未加入域的非 Azure 计算机的 SQL 管理工具的 DBA 或其他用户

对于 Azure 之外的用户，最好尽量避免使用密码。 通过使用 Microsoft Entra 集成身份验证，可以无需使用 SQL 工具的密码。 但是，这些工具必须在加入域的计算机上运行，并且域必须与 Microsoft Entra ID 联合使用，而此场景不符合这种情况。

由于环境不满足集成身份验证的先决条件，建议你将 Microsoft Entra 交互式身份验证与大多数 SQL 工具支持的多重身份验证结合使用。

在你无法在其中更改驱动程序或连接字符串的非 Azure 计算机上运行的旧版应用程序

对于无法更改驱动程序或连接字符串的情况，当前尚不存在用于消除密码使用的选项。 这些旧版应用程序必须继续使用 SQL 身份验证。 你可以考虑更深入地研究这些限制以及如何解除它们，以便使用更安全、更受保护的方法为应用程序进行身份验证。