在本文中,我们将讨论 Azure SQL 数据库 和 Azure Synapse Analytics 安全最佳做法的集合,这些最佳做法用于保护平台即服务 (PaaS) Web 和移动应用程序。 这些最佳实践衍生自我们的 Azure 经验和客户经验。
Azure SQL 数据库和 Azure Synapse Analytics 为基于 Internet 的应用程序提供关系数据库服务。 让我们看看在 PaaS 部署中使用 Azure SQL 数据库和 Azure Synapse Analytics 时帮助保护应用程序和数据的服务:
- Microsoft Entra 身份验证(而不是 SQL Server 身份验证)
- Azure SQL 防火墙
- 透明数据加密 (TDE)
使用集中式标识存储库
可将 Azure SQL 数据库配置为使用两种类型的身份验证之一:
SQL 身份验证 使用用户名和密码。 为数据库创建服务器时,使用用户名和密码指定了“服务器管理员”登录名。 使用这些凭据,您可以以数据库所有者的身份在该服务器上对任何数据库进行身份验证。
Microsoft Entra 身份验证 使用由 Microsoft Entra ID 管理的标识,并且受托管域和集成域的支持。 若要使用 Microsoft Entra 身份验证,必须创建另一个名为“Microsoft Entra 管理员”的服务器管理员,该管理员允许管理Microsoft Entra 用户和组。 此管理员还能执行普通服务器管理员可以执行的所有操作。
Microsoft Entra 身份验证 是一种使用 entra ID Microsoft 中的标识连接到 Azure SQL 数据库和 Azure Synapse Analytics 的机制。 Microsoft Entra ID 提供了 SQL Server 身份验证的替代方法,因此可以停止跨数据库服务器的用户标识激增。 Microsoft Entra 身份验证使你能够在一个中心位置集中管理数据库用户和其他Microsoft服务的标识。 集中 ID 管理提供一个单一位置来管理数据库用户,并简化权限管理。
使用 Microsoft Entra ID 而不是 SQL 身份验证的好处
- 允许在单一位置中轮换密码。
- 使用外部Microsoft Entra 组管理数据库权限。
- 通过启用集成的 Windows 身份验证和 Microsoft Entra ID 支持的其他形式的身份验证来消除存储密码。
- 使用包含的数据库用户在数据库级别对标识进行身份验证。
- 为连接到 SQL 数据库的应用程序支持基于令牌的身份验证。
- 支持使用 Active Directory 联合身份验证服务 (ADFS) 或本机用户/密码身份验证对本地 Microsoft Entra ID 进行域联合。
- 支持使用 Active Directory 通用身份验证的 SQL Server Management Studio 的连接,其中包括多重身份验证(MFA)。 MFA 包括具有一系列简单验证选项的强身份验证。 验证选项包括电话呼叫、短信、带有 pin 或移动应用通知的智能卡。 有关详细信息,请参阅 使用 SQL 数据库和 Azure Synapse Analytics 进行通用身份验证。
若要详细了解 Microsoft Entra 身份验证,请参阅:
- 使用 Microsoft Entra 身份验证通过 SQL 数据库、托管实例或 Azure Synapse Analytics 进行身份验证
- 向 Azure Synapse Analytics 进行身份验证
- 使用 Microsoft Entra 身份验证对 Azure SQL 数据库提供基于令牌的身份验证支持
注释
若要确保 Microsoft Entra ID 非常适合你的环境,请参阅 Microsoft Entra 功能和限制。
基于 IP 地址限制访问
可以创建指定可接受的 IP 地址范围的防火墙规则。 这些规则可以同时针对服务器和数据库级别。 我们建议尽可能使用数据库级防火墙规则来增强安全性,并使数据库更易于移植。 服务器级防火墙规则最适合管理员,如果有多个数据库具有相同的访问要求,但不想花时间单独配置每个数据库。
SQL 数据库默认源 IP 地址限制允许从任何 Azure 地址(包括其他订阅和租户)进行访问。 可以将访问限制为仅允许您的 IP 地址访问实例。 即使存在 SQL 防火墙和 IP 地址限制,仍需要强身份验证。 请参阅本文前面的建议。
若要详细了解 Azure SQL 防火墙和 IP 限制,请参阅:
静态数据加密
默认启用透明数据加密(TDE)。 TDE 以透明方式加密 SQL Server、Azure SQL 数据库和 Azure Synapse Analytics 数据和日志文件。 TDE 可防止文件或其备份被不当访问。 这样,便可以在不更改现有应用程序的情况下加密静态数据。 TDE 应始终保持启用状态;但是,这不会阻止攻击者使用正常的访问路径。 TDE 提供遵守各种行业制定的许多法律、法规和准则的能力。
Azure SQL 管理 TDE 的关键相关问题。 与 TDE 一样,在本地环境中,必须特别注意确保数据库的可恢复性以及在移动数据库时的安全。 在更复杂的方案中,可以通过可扩展的密钥管理在 Azure 密钥保管库中显式管理密钥。 请参阅 使用 EKM 在 SQL Server 上启用 TDE。 这还允许通过 Azure Key Vault 的 BYOK 功能使用自带密钥(BYOK)。
Azure SQL 通过 Always Encrypted 为列提供加密。 这仅允许授权的应用程序访问敏感列。 使用此类加密将加密列的 SQL 查询限制为基于相等的值。
应用程序级别加密还应用于选择性数据。 有时可以通过使用保存在正确国家/地区的密钥加密数据来缓解数据主权问题。 这可以防止意外数据传输导致问题,因为不可能解密没有密钥的数据,假设使用了强算法(如 AES 256)。
可以使用其他预防措施来帮助保护数据库,例如设计安全系统、加密机密资产以及围绕数据库服务器构建防火墙。
后续步骤
本文介绍了有关保护 PaaS Web 和移动应用程序的 SQL 数据库和 Azure Synapse Analytics 安全最佳做法的集合。 若要了解有关保护 PaaS 部署的详细信息,请参阅: