安全功能和任务

  • 10 分钟

SQL Server 和 Azure SQL 服务以其对安全性的重视而闻名，特别是作为企业级服务而言。 在本单元中，你将了解与网络安全和访问管理相关的各种安全功能。 在后面的单元中，你将实际体验其中一些功能。

企业级安全性关系图。

网络安全

安全性的第一层涉及网络。 Azure SQL 数据库和 Azure SQL 托管实例之间的网络功能和任务有所不同。 有关 Azure SQL 托管实例网络功能的信息，请参阅 Azure SQL 托管实例的连接体系结构。

Azure SQL 数据库网络安全性

保护 Azure SQL 数据库的网络时，有四种主要选择：

  • 允许访问 Azure 服务
  • 使用防火墙规则
  • 使用虚拟网络规则
  • 使用 Azure 专用链接

除这些主要选择外，还可以阻止所有公共访问（仅使用 Azure 专用链接），以及选择强制执行传输层安全性 (TLS) 最低版本。 最不安全但最易于配置的方法是允许访问 Azure 服务。 最安全的方法是使用专用链接。 以下部分将介绍每个选项的功能，以及如何配置和维护每个选项。

允许访问 Azure 服务

在 Azure SQL 数据库部署期间，可以选择将“允许 Azure 服务和资源访问此服务器”设置为“是”。 如果选择此选项，则表示允许来自任何区域或订阅的任何资源访问你的资源。 借助此选项，可以轻松启动和运行 Azure SQL 数据库并使其连接到其他服务（如 Azure 虚拟机、Azure 应用服务，甚至是 Azure Cloud Shell），因为允许通过 Azure 传递的任何对象进行连接。

允许访问 Azure 服务的关系图。

但是，允许访问 Azure 服务并不允许 Azure 外部（例如，本地环境）的任何对象进行访问。

安全性最高的配置是将“允许 Azure 服务和资源访问此服务器”设置为“否”，这会阻止所有连接和网络，但已使用下一部分中的各种选项显式添加的连接和网络除外。

防火墙规则

下一个选项是应用防火墙规则。 结果可能与“允许 Azure 服务和资源访问此服务器”的结果相似，但对于每个服务（在下图中为虚拟机 [VM]），需要添加唯一的防火墙规则以它进行连接。 防火墙规则还使本地环境能够连接到 Azure SQL 数据库资源，因为可以为本地环境中的计算机和应用程序添加这些规则。

防火墙规则关系图。

要在 Azure 中获得连接，还可以允许访问 Azure 服务，然后仅为本地连接添加防火墙规则。 如前所述，“允许 Azure 服务和资源访问此服务器”并不安全，因为它允许所有 Azure 流量。 建议仅使用防火墙规则。

让我们看看前面配置了防火墙规则的示例。 在支持 Transact-SQL (T-SQL) 的工具（如 SQL Server Management Studio (SSMS)）中，可以从虚拟网络 SQLDBVNET-EUS 中的 Azure VM 运行以下查询：

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

结果将为 203.0.113.1。 这是 Azure VM 的公共 IP 地址。 尽管我们使用防火墙规则，但要建立的所有连接都是公共连接。

虚拟网络规则

如果只想使用防火墙规则，则设置起来可能会很复杂。 只设置防火墙规则意味着必须为所有连接（有时可能具有动态 IP 地址）指定 IP 地址范围。 一种更简单的替代方法是使用虚拟网络规则建立和管理来自包含 VM 或需要访问数据的其他服务的特定网络的访问。

如果使用虚拟网络规则配置来自虚拟网络的访问，则该虚拟网络中的任何资源都可以访问 Azure SQL 数据库逻辑服务器。 这可以简化配置对需要访问数据的所有静态和动态 IP 地址的访问的挑战。 通过使用虚拟网络规则，可以指定一个或多个虚拟网络，包含其中的所有资源。 还可以开始应用虚拟网络技术在 Azure 中和本地跨区域连接网络。

虚拟网络规则关系图。

在此示例中，与上一部分中一样，可以从虚拟网络“SQLDBVNET-EUS”中的 Azure VM 运行相同的查询：

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

结果现在为 10.0.0.2，这是 Azure VM 的专用 IP 地址。 由于资源现在通过虚拟网络进行连接，因此这个结果使你与建立到 Azure SQL 数据库逻辑服务器的专用连接更近一步。

分析连接的另一种常见策略是检查域名系统服务 (DNS) 层次结构。 在同一 Azure VM 中，在命令提示符下，可以运行以下命令：

nslookup aw-server.database.windows.net

通过使用此命令，可以获取与 DNS 基础结构相关的详细信息。 结果如下所示：

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   cr2.eastus1-a.control.database.windows.net
Address:    203.0.113.1
Aliases:    aw-server.database.windows.net
            dataslice2.eastus.database.windows.net

在非权威的答案下，有一些需要注意的重要内容：

  • 名称：以 cr2 开头的终结点是公共 DNS 层次结构的一部分。 我们不会太过深入探讨层次结构，假设 cr2 是“控件环 2”，其下有多个数据“切片”。
  • 地址：此处返回的 IP 地址应与 Azure VM 的公共 IP 地址匹配。 虽然 SSMS 最终跃点等工具可能会通过 VM 的专用 IP 地址传递，但 VM 的公共 IP 地址仍会在某种程度上用于连接。
  • 别名：别名是 DNS 层次结构中的各种点，在本例中为特定数据“切片”和连接到的终结点。

注意

在以上输出块中， 地址：168.63.129.16”是虚拟公共 IP 地址，用于简化到 Azure 平台资源的通信通道。 它应用于所有区域和所有国家云，并且不会更改。

尽管通过 SSMS 建立的连接通过 Azure VM 的专用 IP 地址传递，但最终仍将通过公共终结点进行连接。

你已经了解如何结合使用 Azure SQL 数据库中的数据库和公共终结点配置最安全的网络。 这种保护 SQL 数据库中的数据库的方法已经应用多年。 但在 2019 年，Azure 开始转向专用链接的概念，这更类似于部署 Azure SQL 托管实例的方式。 通过 Azure 专用链接，可以使用专用终结点连接到 SQL 数据库中的数据库和其他一些平台即服务 (PaaS) 产品/服务。 这意味着它在特定的虚拟网络中具有专用 IP 地址。

专用终结点连接关系图。

在前面的示例中，你会注意到，一般网络基础结构并未更改，仍然可以应用虚拟网络规则中的虚拟网络连接策略。 但是，你无需创建虚拟网络规则。 需要连接到数据库服务器的资源必须有权访问终结点所驻留的虚拟网络。 在示例中，终结点为 SQLDBVNet-EUS。 仅通过专用终结点传递的连接才拥有访问权限，所有其他连接（例如，来自 Internet 的连接）都将被拒绝。

继续使用此示例，在虚拟网络 SQLDBVNet-EUS 中的 Azure VM 上，可以再次运行以下 T-SQL 命令：

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

结果现在为 10.0.0.2，在此示例中，这是 Azure VM 的专用 IP 地址。 通过添加来自虚拟网络的访问，从 VM 连接到 Azure SQL 数据库会看起来是通过 VM 的专用 IP 地址进行的。 这与在虚拟网络规则中看到的结果相同。

但是，你可能想要通过以下命令使用命令提示符来查看 DNS 层次结构：

nslookup aw-server.database.windows.net

如果使用前面的命令，配置专用终结点后，结果将略有不同：

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   aw-server.privatelink.database.windows.net
Address:    10.0.0.5
Aliases:    aw-server.database.windows.net

在非权威的答案下，有一些需要注意的重要内容：

  • 名称：请注意，不再指向公共 DNS 层次结构，仅指向专用链接 DNS。 这意味着显示的关于数据库服务器的信息会减少。
  • 地址：对于虚拟网络规则，返回的地址是 VM 的公共 IP 地址，但它现在应该是专用链接层次结构中的一个或多个专用 IP 地址（其中一个是 Azure SQL 数据库的专用终结点）。
  • 别名：与“名称”字段中一样，除仍然可以连接到服务器名称（例如，aw-server.database.windows.net）外，没有与 DNS 层次结构相关的任何内容。

你可能想知道的一件事是：如果要连接到专用终结点，为什么仍要使用相同的服务器名称？在后端，当你仅使用专用链接方法连接到 Azure SQL 数据库（即没有防火墙或虚拟网络规则）时，信息的处理方式如下：

  • aw-server.database.windows.net
    • 通过服务解析到 aw-server.privatelink.database.net
      • 通过服务解析到 10.0.0.5（专用终结点的 IP 地址）

此外，服务将阻止使用 aw-server.database.windows.net 以外的任何信息直接进行连接。

访问管理

解决网络访问问题后，需要考虑的下一层是访问管理。

基于角色的访问控制

Azure SQL 数据库的所有 Azure 类型操作都通过基于角色的访问控制 (RBAC) 进行控制。 RBAC 当前与 Azure SQL 安全分离，但你可以将其视为 SQL 数据库中的数据库之外的安全权限，其范围包括订阅、资源组和资源。 该权限适用于 Azure 门户、Azure CLI 和 Azure PowerShell 中的操作。 RBAC 允许在部署、管理和使用之间分离职责。

内置角色可用于减少对较高级别的 RBAC 角色（如所有者或参与者）的需求。 实际上，可以使用这些角色让特定个人部署 Azure SQL 资源（或管理安全策略），但向其他用户授予使用或管理数据库的实际访问权限。 例如，“SQL Server 参与者”可以部署服务器，并将用户分配为服务器和数据库的管理员。 Azure SQL 数据库的内置角色包括：

  • SQL DB 参与者：可以创建和管理数据库，但不能访问数据库（例如，无法连接和读取数据）
  • SQL 安全管理员：可以管理数据库和实例的安全策略（如审核），但无法进行访问
  • SQL Server 参与者：可以管理服务器和数据库，但不能访问它们。

身份验证

在 Azure SQL 数据库逻辑服务器部署期间，可以指定以下身份验证方法：

  • 仅使用 Microsoft Entra 身份验证
  • 同时使用 SQL 和 Microsoft Entra 身份验证
  • 使用 SQL 身份验证

在部署过程中，需要设置服务器管理员。 对于 Azure SQL 数据库中的数据库，服务器管理员是 Azure SQL 数据库逻辑服务器的服务器级别主体。

如果要迁移需要 Windows 身份验证的工作负载，或者组织使用了 Microsoft Entra ID，则可以使用 Microsoft Entra ID。 可通过使用门户或命令行工具来分配 Microsoft Entra 服务器管理员。

配置新服务器时，仅限 Microsoft Entra 身份验证为默认选项。 引入了服务器登录名以支持 Microsoft Entra 服务器主体，它们是 SQL 数据库的虚拟 master 数据库中的登录名。 可以根据 Microsoft Entra 用户、组和服务主体创建 Microsoft Entra 登录名。 使用仅限 Microsoft Entra 身份验证时，可以创建 SQL 身份验证登录名，而现有登录名将保留。 但只有 Microsoft Entra 身份验证登录名和用户才能连接到逻辑服务器。 若要了解有关仅限 Microsoft Entra 身份验证的详细信息，请参阅使用 Azure SQL 的仅限 Microsoft Entra 身份验证。

设置 Microsoft Entra 管理员的屏幕截图。

根据组织配置 Microsoft Entra 实例的方法，可以使用以下三种方法中的任何一种连接到实例（例如，在 SSMS 中）：

  • Microsoft Entra ID - 已集成：非交互式方法，如果使用来自联合域的 Microsoft Entra 凭据登录到 Windows，则可以使用该方法。

  • Microsoft Entra ID - 密码：一种非交互式方法，支持你使用 Microsoft Entra ID 托管域连接到 Microsoft Entra 主体名称。 文档描述如下：

    这适用于本机或联合 Microsoft Entra 用户。 本机用户是在 Microsoft Entra 中显式创建并使用用户名和密码进行身份验证的用户，而联合用户则是其域与 Microsoft Entra ID 联合的 Windows 用户。 当用户想要使用其 Windows 凭据，但其本地计算机未与域联接（例如，使用远程访问）时，可以使用后一种方法（使用用户名加密码）。 在这种情况下，Windows 用户可以指示其域帐户和密码，并可以使用联合凭据向 SQL 数据库或 Azure Synapse Analytics（以前称为 SQL DW）进行身份验证。

  • Microsoft Entra ID - 通用多重身份验证 (MFA)：一种交互式方法，可以保护对数据的访问，同时通过 Microsoft Entra 多重身份验证满足组织对单一登录过程的需求。

对于 Azure SQL 数据库，有一些细微差别。 可以拥有存在于虚拟 master 数据库、数据库用户，甚至 Microsoft Entra 帐户的包含 数据库用户（推荐）。 虽然 Azure SQL 数据库的服务器管理员实质上具有 sysadmin 权限，但可使用服务器或数据库级别的角色来创建更多受到限制的管理员。 两个数据库级别角色可用于仅存在于虚拟 master 数据库中的 SQL 数据库：

  • loginmanager：数据库级别角色，允许成员为数据库服务器创建登录名
  • dbmanager：数据库级别角色，允许成员为数据库服务器创建和删除数据库

以下是 Azure SQL 数据库中的服务器级别角色列表：

  • ##MS_DatabaseConnector##
  • ##MS_DatabaseManager##
  • ##MS_DefinitionReader##
  • ##MS_LoginManager##
  • ##MS_SecurityDefinitionReader##
  • ##MS_ServerStateReader##
  • ##MS_ServerStateManager##

最后，设置并配置身份验证和授权时，需要遵循以下四个准则：

  • 通过服务器管理员部署
  • 根据需要创建其他管理员
  • 管理员可以创建用户
  • 就像在 SQL Server 中一样授予访问权限

其他功能

在实际体验部分网络和身份验证功能后，本模块的稍后部分将介绍用于数据保护、监视、记录和审核的其他功能（及其相关任务）。

知识检查

1.

保护 Azure SQL 数据库网络的建议的最安全方法是什么？

2.

请考虑本单元中的示例：Azure VM 的公共 IP 地址为 203.0.113.1，Azure VM 的专用 IP 地址为 10.0.0.2。 使用虚拟网络规则配置对 Azure SQL 数据库的网络访问时，SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID; 将返回什么？