你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Tip
Microsoft Fabric Data Warehouse是数据湖基础上的企业规模关系仓库，具有未来就绪的体系结构、内置 AI 和新功能。 如果不熟悉数据仓库，请从Fabric Data Warehouse开始。 现有的指定 SQL 池工作负荷可以升级到 Fabric，以跨数据科学、实时分析和报告访问新功能。
本文将引导你了解保护专用 SQL 池（以前称为 SQL DW）的基础知识。 具体而言，本文首先介绍了如何使用专用 SQL 池（以前为 SQL DW）限制访问、保护数据和监视活动的资源。
连接安全性
连接安全性是指如何使用防火墙规则和连接加密来限制和安全与数据库的连接。
逻辑 SQL 服务器及其数据库都使用防火墙规则来拒绝未显式批准的 IP 地址的连接尝试。 若要允许来自应用程序或客户端计算机的公共 IP 地址的连接，必须先使用 Azure 门户、REST API 或 PowerShell 创建服务器级防火墙规则。
最佳做法是，应尽可能多地限制通过服务器级防火墙允许的 IP 地址范围。 若要从本地计算机访问专用 SQL 池（以前为 SQL DW），请确保网络上的防火墙和本地计算机允许 TCP 端口 1433 上的传出通信。
专用 SQL 池（前 SQL DW）使用服务器级 IP 防火墙规则。 不支持数据库级 IP 防火墙规则。 有关详细信息，请参阅 Azure SQL 数据库防火墙规则
与专用 SQL 池（以前为 SQL DW）的连接默认加密。 将忽略修改连接设置以禁用加密。
Authentication
身份验证是指在连接到数据库时如何证明身份。 专用 SQL 池（以前为 SQL DW）目前支持使用用户名和密码以及Microsoft Entra ID 的 SQL Server 身份验证。
为数据库创建服务器时，使用用户名和密码指定了“服务器管理员”登录名。 使用这些凭据，可以通过 SQL Server 身份验证以数据库所有者（或“dbo”）的身份在该服务器对任何数据库进行验证。
但是，最佳做法是，组织的用户应使用不同的帐户进行身份验证。 这样，便可以限制授予应用程序的权限，并降低恶意活动的风险，以防应用程序代码容易受到 SQL 注入攻击。
若要创建经过身份验证的 SQL Server 用户，请使用服务器管理员登录名连接到服务器上的 master 数据库，并创建新的服务器登录名。 最好在 master 数据库中创建用户。 在 master 中创建用户允许用户使用 SSMS 等工具登录，而无需指定数据库名称。 它还允许他们使用对象资源管理器查看服务器上的所有数据库。
-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;
然后，使用服务器管理员登录名连接到 专用 SQL 池（以前为 SQL DW）， 并根据创建的服务器登录名创建数据库用户。
-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;
若要授予用户执行其他操作（例如创建登录名或创建新数据库）的权限，请将用户分配到 master 数据库中的 Loginmanager 和 dbmanager 角色。
有关这些附加角色和对 SQL 数据库进行身份验证的详细信息，请参阅 管理 Azure SQL 数据库中的数据库和登录名。 有关使用 Microsoft Entra ID 进行连接的详细信息，请参阅 使用 Microsoft Entra 身份验证进行连接。
Authorization
授权是指在身份验证和连接后，你能在数据库中执行的操作。 授权权限由角色成员身份和权限决定。 作为最佳实践，应向用户授予所需的最低权限。 若要管理角色，可以使用以下存储过程：
EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data
要连接的服务器管理员帐户是“db_owner”角色的成员，该角色拥有在数据库中执行任何操作的权限。 保存此帐户以部署架构升级和其他管理作。 使用具有更有限权限的“ApplicationUser”帐户，通过应用程序所需的最低权限从应用程序连接到数据库。
可通过多种方式进一步限制用户可以在数据库中执行的作：
- 精细的权限允许你控制可以在数据库中的各个列、表、视图、架构、过程和其他对象上执行的操作。 使用精细权限以拥有最大程度的控制，并授予必要的最低权限。
- 除db_datareader和db_datawriter以外的数据库角色可用于创建更强大的应用程序用户帐户或不太强大的管理帐户。 内置的固定数据库角色提供了一种授予权限的简单方法，但可能会导致授予比必要权限更多的权限。
- 存储过程 可用于限制可对数据库执行的操作。
以下示例授予对用户定义的架构的读取访问权限。
--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser
从 Azure 门户或使用 Azure 资源管理器 API 管理数据库和服务器由门户用户帐户的角色分配控制。 有关详细信息，请参阅使用 Azure 门户分配 Azure 角色。
行级安全性
Row-Level 安全性使你能够基于执行查询的用户的特征（例如组成员身份或执行上下文）来控制对数据库表中行的访问。 使用行级安全性来实现基于标签的自定义安全概念。 有关详细信息，请参阅行级别安全性。
Encryption
透明数据加密（TDE）通过加密和解密静态数据来帮助防范恶意活动的威胁。 加密数据库时，将加密关联的备份和事务日志文件，而无需对应用程序进行任何更改。 TDE 使用称为数据库加密密钥的对称密钥来加密整个数据库的存储。
在 SQL 数据库中，数据库加密密钥受内置服务器证书的保护。 对于每个服务器，内置服务器证书是唯一的。 Microsoft至少每 90 天自动轮换这些证书。 使用的加密算法是 AES-256。 有关 TDE 的一般说明，请参阅 透明数据加密。
使用客户管理的密钥进行透明数据加密（静态加密）
如果需要对加密密钥进行更严格的控制，Azure Synapse Analytics 的透明数据加密支持客户管理的密钥 (CMK)。 此 CMK 与逻辑服务器关联，并包装该服务器内所有数据库的数据库加密密钥。 通过管理 CMK，可以控制密钥轮换、吊销和审核，这通常是合规性或严格的安全策略所必需的。
传输层安全性（传输中加密）
Azure Synapse Analytics 使用传输层安全性 (TLS) 对传输中的数据进行加密，从而保护客户数据。 Azure Synapse Analytics 始终强制执行 TLS 加密连接，以确保客户端与服务器之间的传输中所有数据均加密。
具体来说，Azure Synapse Analytics 会将配置标志 ForceEncryption 设置为 Yes。 客户端和驱动程序必须支持加密连接才能连接该服务。 可连接的 TDS 协议的最低版本为 TDS 7.1。
最佳做法是，如果你有支持 TDS 8.0 的 SQL 驱动程序，请使用 严格连接加密。
如果驱动程序不支持 TDS 8.0，请使用强制加密，并且不信任服务器证书。 例如，使用 ADO.NET 驱动程序时，请在连接字符串中使用 Encrypt=True 和 TrustServerCertificate=False 来实现这一目标。 从 Azure 门户获取的连接字符串已使用这些值进行配置。
避免在生产环境中将参数 TrustServerCertificate 设置为 True 使用。
TrustServerCertificate=True 太宽松了，不能防范中间人攻击。 相反，如果客户端需要服务器证书中的其他域名，请使用 HostNameInCertificate 参数提供正确的域名进行验证。
Important
某些非Microsoft驱动程序在默认情况下可能不会使用 TLS，或者可能依赖于较旧版本的 TLS（早于 1.2）才能正常运行。 在这种情况下，服务器仍允许连接到数据库。 然而，要评估允许这些驱动程序和应用程序连接的安全风险，尤其是当你存储敏感数据时。
后续步骤
有关使用不同协议连接到仓库的详细信息和示例，请参阅“连接到专用 SQL 池”（以前为 SQL DW）。