用于解决 Azure SQL 数据库和 Azure SQL 托管实例常见

小提示：您能找到这篇{用于解决 Azure SQL 数据库和 Azure SQL 托管实例常见}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的用于解决 Azure SQL 数据库和 Azure SQL 托管实例常见内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">适用于：Azure SQL数据库、Azure SQL托管实例

< ">本文提供了有关如何解决常见安全要求的最佳做法。并非所有要求都适用于所有环境，你应该向数据库和安全团队咨询要实现哪些功能。

< ">解决常见的安全要求

< ">本文档提供有关如何解决使用Azure SQL数据库和Azure SQL托管实例的新应用程序或现有应用程序的常见安全要求的指导。本文档的内容已从较高层面按照安全考虑因素进行组织。若要解决特定的威胁，请参阅常见安全威胁和潜在缓解措施部分。提供的某些建议在将应用程序从本地迁移到Azure时适用，不过，本文档不会重点说明迁移方案。

< ">本指南涉及的Azure SQL数据库部署产品/服务

< ">Azure SQL数据库：服务器中的单一数据库和弹性池

< ">Azure SQL托管实例

< ">本指南不涉及的部署产品/服务

< ">Azure Synapse Analytics

< ">Azure SQL VM(IaaS)

< ">SQL Server

< ">目标受众

< ">本文档旨在用作现有Azure SQL数据库安全性文档的配套资源。

< ">除非另有说明，否则我们建议遵循每个部分中列出的所有最佳做法，以实现相关的目标或要求。为了帮助客户满足特定的安全合规标准或最佳做法，在适用的情况下，“要求或目标”部分下面会列出重要的法规控制措施。本文参考了以下安全标准和法规：

< ">FedRAMP：AC-04、AC-06

< ">SOC：CM-3、SDL-3

< ">ISO/IEC 27001：访问控制、加密

< ">Microsoft操作安全保障(OSA)做法：做法#1-6和#9

< ">NIST专刊800-53安全控制：AC-5、AC-6

< ">PCI DSS：6.3.2、6.4.2

< ">我们计划持续更新本文列出的建议和最佳做法。使用本文底部的"反馈"链接提供对此文档的输入或任何更正。

< ">身份验证

< ">身份验证是证明用户所声明身份的过程。Azure SQL数据库和SQL托管实例支持两种类型的身份验证：

< ">SQL身份验证

< ">Azure Active Directory身份验证

< ">备注

< ">并非所有工具和第三方应用程序都支持Azure Active Directory身份验证。

< ">标识的集中管理

< ">集中式标识管理提供以下优势：

< ">管理组帐户并控制用户权限，而无需跨服务器、数据库和托管实例重复登录。

< ">简化且灵活的权限管理。

< ">应用程序的大规模管理。

< ">如何实现：

< ">使用Azure Active Directory(Azure AD)身份验证实现集中式标识管理。

< ">最佳做法：

< ">创建Azure AD租户，创建用户来表示人类用户，并创建服务主体来表示应用、服务和自动化工具。服务主体相当于Windows和Linux中的服务帐户。

< ">通过组分配向Azure AD主体分配资源访问权限：创建Azure AD组，向组授予访问权限，并将各个成员添加到组中。在数据库中，创建包含的数据库用户用于映射Azure AD组。若要在数据库中分配权限，请将与Azure AD组关联的用户置于具有适当权限的数据库角色中。

< ">备注

< ">在SQL托管实例中，还可以创建映射到master数据库中的Azure AD主体的登录名。请参阅CREATE LOGIN(Transact-SQL)。

< ">使用Azure AD组可以简化权限管理，组所有者和资源所有者都可以在组中添加/删除成员。

< ">为每个服务器或托管实例创建单独的Azure AD管理员组。

< ">请参阅为服务器预配Azure Active Directory管理员一文。

< ">使用Azure AD审核活动报告监视Azure AD组成员身份的更改。

< ">对于托管实例，需要执行一个单独的步骤来创建Azure AD管理员。

< ">请参阅为托管实例预配Azure Active Directory管理员一文。

< ">备注

< ">Azure AD身份验证记录在Azure SQL审核日志中，而不是记录在Azure AD登录日志中。

< ">Azure中授予的azure RBAC权限不适用于Azure SQL数据库或SQL托管实例权限。必须使用现有的SQL权限手动创建/映射此类权限。

< ">在客户端上，Azure AD身份验证需要访问Internet，或通过用户定义的路由(UDR)访问虚拟网络。

< ">Azure AD访问令牌缓存在客户端，其生存期取决于令牌配置。请参阅Azure Active Directory中可配置的令牌生存期一文

< ">Azure AD多重身份验证

< ">内容来源：OSA做法#2，ISO访问控制(AC)

< ">Azure AD多重身份验证通过要求多种形式的身份验证提供额外的安全性。

< ">如何实现：

< ">使用条件访问在Azure AD中启用多重身份验证，并使用交互式身份验证。

< ">或者，为整个Azure AD或AD域启用多重身份验证。

< ">最佳做法：

< ">Azure AD(需要高级订阅)中激活条件性访问。

< ">创建Azure AD组，并使用Azure AD条件访问为选定的组启用多重身份验证策略。

< ">可为整个Azure AD或者与Azure AD联合的整个Active Directory启用多重身份验证。

< ">对以交互方式请求密码的Azure SQL数据库和Azure SQL托管实例使用Azure AD交互式身份验证模式，然后启用多重身份验证：

< ">在SSMS中使用通用身份验证。请参阅在Azure SQL数据库、SQL托管实例和Azure Synapse Analytics中使用多重Azure AD身份验证（SSMS对多重身份验证的支持）一文。

< ">使用SQL Server Data Tools(SSDT)中支持的交互式身份验证。请参阅SQL Server Data Tools(SSDT)中的Azure Active Directory支持。

< ">使用其他支持多重身份验证的SQL工具。

< ">SSMS向导对导出/提取/部署数据库操作的支持

< ">sqlpackage.exe：选项“/ua”

< ">sqlcmd实用工具：选项-G（交互式）

< ">bcp实用工具：选项-G（交互式）

< ">实现你的应用程序，以使用支持多重身份验证的交互式身份验证连接到Azure SQL数据库或Azure SQL托管实例。

< ">备注

< ">此身份验证模式需要使用基于用户的标识。如果使用的受信任标识模型会绕过个体Azure AD用户身份验证（例如，使用Azure资源的托管标识），则不会应用多重身份验证。

< ">尽量减少对用户使用基于密码的身份验证

< ">内容来源：OSA做法#4，ISO访问控制(AC)

< ">基于密码的身份验证方法是较弱的身份验证形式。凭据可能会透露或者被错误地丢弃。

< ">如何实现：

< ">使用Azure AD集成身份验证，此方法可消除密码的使用。

< ">最佳做法：

< ">使用Windows凭据进行单一登录身份验证。将本地AD域与Azure AD相联合，并使用Windows集成身份验证（适用于Azure AD中已加入域的计算机）。

< ">尽量减少对应用程序使用基于密码的身份验证

< ">内容来源：OSA做法#4，ISO访问控制(AC)

< ">如何实现：

< ">启用Azure托管标识。还可以使用集成式或基于证书的身份验证。

< ">最佳做法：

< ">使用Azure资源的托管标识。

< ">系统分配的托管标识

< ">用户分配的托管标识

< ">从具有托管标识的Azure应用服务使用Azure SQL数据库（无需更改代码）

< ">对应用程序使用基于证书的身份验证。

< ">请参阅此代码示例。

< ">对集成的联合域和已加入域的计算机使用Azure AD身份验证（参阅上一部分）。

< ">请参阅集成身份验证的示例应用程序。

< ">保护密码和机密

< ">如果不可避免地需要使用密码，请确保密码受到保护。

< ">如何实现：

< ">使用Azure Key Vault存储密码和机密。在适用的情况下，请对Azure AD用户使用Azure SQL数据库的多重身份验证。

< ">最佳做法：

< ">如果无法避免密码或机密的使用，请在Azure Key Vault中存储用户密码和应用程序机密，并通过Key Vault访问策略管理访问权限。

< ">各种应用开发框架还可能提供框架特定的机制来保护应用中的机密。例如：ASP.NET Core应用。

< ">对旧式应用程序使用SQL身份验证

< ">SQL身份验证是指使用用户名和密码连接到Azure SQL数据库或SQL托管实例时对用户进行身份验证。需要在每个服务器或托管实例中创建一个登录名，并在每个数据库中创建一个用户。

< ">如何实现：

< ">使用SQL身份验证。

< ">最佳做法：

< ">以服务器或实例管理员的身份创建登录名和用户。除非将包含的数据库用户与密码配合使用，否则所有密码将存储在master数据库中。

< ">请参阅控制和授予对SQL数据库、SQL托管实例和Azure Synapse Analytics的数据库访问权限一文。

< ">访问管理

< ">访问管理（也称为授权）是控制和管理已授权用户对Azure SQL数据库或SQL托管实例的访问权限与特权的过程。

< ">实施最低特权原则

< ">内容来源：FedRamp控制措施AC-06，NIST：AC-6，OSA做法#3

< ">最低特权原则指出，用户拥有的特权不应超过他们完成任务所需的特权。有关详细信息，请参阅Just Enough Administration一文。

< ">如何实现：

< ">仅分配完成所需任务而需要的权限：

< ">在SQL数据库中：

< ">使用粒度权限和用户定义的数据库角色（或托管实例中的服务器角色）：

< ">创建所需的角色

< ">CREATE ROLE

< ">CREATE SERVER ROLE

< ">创建所需的用户

< ">CREATE USER

< ">将用户作为成员添加到角色

< ">ALTER ROLE

< ">ALTER SERVER ROLE

< ">然后将权限分配给角色。

< ">GRANT

< ">确保不要将用户分配到不必要的角色。

< ">在Azure资源管理器中：

< ">使用内置角色（如果可用）或Azure自定义角色，并分配所需的权限。

< ">Azure内置角色

< ">Azure自定义角色

< ">最佳做法：

< ">以下最佳做法是可选的，但可以改善安全策略的易管理性和支持性：

< ">如果可能，请从尽可能低的权限集开始，并在有实际需要（和理由）时逐个添加权限-而不要采用相反的方法：逐步去除权限。

< ">避免将权限分配给单个用户。改为以一致的方式使用角色（数据库角色或服务器角色）。角色能够为报告权限和排查权限问题提供很大的帮助。（Azure RBAC仅支持通过角色分配权限。）

< ">创建和使用具有所需确切权限的自定义角色。实践中使用的典型角色：

< ">安全部署

< ">管理员

< ">开发人员

< ">支持人员

< ">审核员

< ">自动化过程

< ">最终用户

< ">只有当角色的权限与用户所需的权限完全匹配时，才使用内置角色。可将用户分配到多个角色。

< ">请记住，数据库引擎中的权限可以在以下范围内应用（范围越小，授予的权限的影响越小）：

< ">Azure中的服务器（master数据库中的特殊角色）

< ">数据库

< ">架构

< ">最佳做法是使用架构在数据库中授予权限。（另请参阅：架构设计：有关架构设计的建议和安全注意事项）

< ">对象（表、视图、过程等）

< ">备注

< ">不建议在对象级别应用权限，因为此级别会给整个实现带来不必要的复杂性。如果决定使用对象级权限，应明确阐述这些权限。这同样适用于列级权限，出于相同的原因，我们更不建议应用此类权限另请注意，默认情况下，表级DENY不会覆盖列级授权。这需要激活通用标准合规性服务器配置。

< ">使用漏洞评估(VA)执行定期检查，以测试权限是否过多。

< ">实现职责分离

< ">内容来源：FedRamp：AC-04，NIST：AC-5，ISO：6.1.2、PCI 6.4.2，SOC：CM-3、SDL-3

< ">“职责分离”描述将敏感任务拆分为要分配给不同用户的多个任务的要求。职责分离有助于防止数据违规。

< ">如何实现：

< ">识别所需的职责分离级别。示例:

< ">在开发/测试环境与生产环境之间

< ">安全相关的任务、数据库管理员(DBA)管理级别任务与开发人员任务。

< ">示例:审核员为角色级安全性(RLS)创建安全策略，并使用DDL权限实现SQL数据库对象。

< ">识别有权访问系统的用户（和自动化过程）的综合层次结构。

< ">根据所需的用户组创建角色，并将权限分配给角色。

< ">对于通过Azure门户或PowerShell自动化完成的管理级任务，请使用Azure角色。查找符合要求的内置角色，或者使用可用权限创建Azure自定义角色

< ">在托管实例中为服务器范围的任务（创建新的登录名和数据库）创建服务器角色。

< ">为数据库级任务创建数据库角色。

< ">对于某些敏感任务，考虑创建由证书签名的特殊存储过程，以代表用户执行这些任务。数字签名存储过程的一个重要优点是，如果更改了该过程，则会立即删除授予该过程的旧版本的权限。

< ">示例：教程：使用证书为存储过程签名

< ">使用Azure Key Vault中客户管理的密钥实现透明数据加密(TDE)，以便在数据所有者与安全所有者之间实现职责分离。

< ">为了确保DBA无法看到高度敏感的数据但仍可执行DBA任务，可将Always Encrypted与角色分离配合使用。

< ">如果使用Always Encrypted不可行（最起码在不付出极大成本和工作量的情况下做不到这一点，但如果付出，甚至可能会导致系统几乎不可用），可以通过补偿性的控制措施来采取折衷办法，例如：

< ">在过程中进行人工干预。

< ">审核线索–有关审核的详细信息，请参阅审核关键安全事件。

< ">最佳做法：

< ">确保将不同的帐户用于开发/测试环境和生产环境。不同的帐户有助于满足测试和生产系统分离的原则。

< ">避免将权限分配给单个用户。改为以一致的方式使用角色（数据库角色或服务器角色）。使用角色能够为报告权限和排查权限问题提供很大的帮助。

< ">当权限与所需权限完全匹配时使用内置角色–如果多个内置角色的所有权限的联合导致100%匹配，则还可以同时分配多个角色。

< ">当内置角色授予的权限过多或不足时，创建并使用用户定义的角色。

< ">还可以通过T-SQL的SQL代理作业步骤或适用于Azure角色的Azure PIM暂时执行角色分配（也称为动态职责分离(DSD)）。

< ">确保DBA无权访问加密密钥或密钥存储，而有权访问密钥的安全管理员无权访问数据库。(EKM)使用可扩展的密钥管理可以使此分离更容易实现。Azure Key Vault可用于实现EKM。

< ">始终确保针对安全相关的操作提供审核线索。

< ">可以检索Azure内置角色的定义以查看所用的权限，并通过PowerShell根据这些信息的摘录和累积创建自定义角色。

< ">由于db_owner数据库角色的任何成员都可以更改透明数据加密(TDE)等安全设置或更改SLO，因此，应谨慎地授予此成员身份。但是，许多任务要求使用db_owner特权。例如，更改数据库选项等任何数据库设置的任务。在任何解决方案中，审核都发挥着关键的作用。

< ">无法限制db_owner的权限，因此应阻止管理帐户查看用户数据。如果数据库中包含高度敏感的数据，可以使用Always Encrypted来安全阻止db_owners或任何其他DBA查看这些数据。

< ">备注

< ">对安全相关的任务或故障排除任务实现职责分离(SoD)会有难度。其他方面（例如开发和最终用户角色）更易于分离。当其他解决方案不可行时，大多数合规性相关的控制措施允许使用替代的控制功能，例如审核。

< ">执行定期代码评审

< ">内容来源：PCI：6.3.2，SOC：SDL-3

< ">职责分离不局限于数据库中的数据，它还包括应用程序代码。恶意代码可能会绕过安全控制。在将自定义代码部署到生产环境之前，必须评审要部署的内容，这一点至关重要。

< ">如何实现：

< ">使用支持源代码管理的数据库工具，例如Azure Data Studio。

< ">实现分离的代码部署过程。

< ">在提交到主分支之前，必须由某个人员（代码本身的作者除外）检查代码是否存在提升特权的风险，以及是否存在恶意的数据修改，以防止出现欺诈和恶意访问。可以使用源代码管理机制实现此目的。

< ">最佳做法：

< ">标准化：实现每次更新代码时都要遵循的标准过程会很有帮助。

< ">漏洞评估中的规则可以检查是否存在过多的权限、是否使用了旧加密算法，以及数据库架构中是否存在其他安全问题。

< ">可以在QA或测试环境中使用高级威胁防护来执行更多的检查，此技术将扫描容易受到SQL注入攻击的代码。

< ">要注意的方面的示例：

< ">从自动化SQL代码更新部署内部创建用户或更改安全设置。

< ">某个存储过程根据提供的参数以不一致的方式更新单元格中的货币值。

< ">确保执行评审的人员是除原始代码作者以外的个人，且熟悉代码评审和安全编码。

< ">确保知道所有代码更改来源。代码可能位于T-SQL脚本中。它可能是要以视图、函数、触发器和存储过程形式执行或部署的临时命令。它可能是SQL代理作业定义（步骤）的一部分。它还可能从SSIS包、Azure数据工厂和其他服务的内部执行。

< ">数据保护

< ">数据保护是通过加密或模糊处理来防止重要信息遭到透露的一组功能。

< ">备注

< ">Microsoft的Azure SQL数据库和SQL托管实例已通过FIPS 140-2级别1合规认证。认证过程中已确认它严格使用FIPS 140-2级别1可接受的算法，以及这些算法的、经FIPS 140-2级别1验证的实例，包括符合所需密钥长度、密钥管理、密钥生成和密钥存储的要求。此项认证意味着，我们的客户在处理数据或者交付系统或应用程序的过程中，可以满足使用FIPS 140-2级别1验证实例的需求或要求。我们定义了上述语句中使用的术语"FIPS 140-2 Level 1相容"和"FIPS 140-2 Level 1相容性"，以演示其对美国和加拿大政府使用不同术语"FIPS 140-2 Level 1验证"的预期适用性。

< ">加密传输中的数据

< ">内容来源：OSA做法#6，ISO控制系列：Cryptography

< ">当数据在客户端与服务器之间移动时为其提供保护。请参阅网络安全性。

< ">静态数据加密

< ">内容来源：OSA做法#6，ISO控制系列：Cryptography

< ">静态加密是指对数据库、日志和备份文件中保存的数据进行加密保护。

< ">如何实现：

< ">对于2017年后在Azure SQL数据库和SQL托管实例中创建的任何数据库，默认将启用通过服务托管的密钥进行透明数据库加密(TDE)。

< ">在托管实例中，如果数据库是使用本地服务器从还原操作创建的，则会遵循原始数据库的TDE设置。如果未为原始数据库启用TDE，则我们建议手动为托管实例启用TDE。

< ">最佳做法：

< ">不要将需要静态加密的数据存储在master数据库中。无法使用TDE加密master数据库。

< ">如果需要提高透明度并精细控制TDE保护，请使用Azure Key Vault中客户管理的密钥。Azure Key Vault允许随时撤销权限，使数据库不可访问。可以集中管理TDE保护器及其他密钥，或使用Azure Key Vault按自己的计划轮换TDE保护器。

< ">如果使用Azure Key Vault中客户管理的密钥，请参阅文章有关使用Azure Key Vault配置TDE的指导原则和如何使用Azure Key Vault配置异地灾难恢复。

< ">防止未经授权的高特权用户查看使用中的敏感数据

< ">使用中的数据是指在执行SQL查询期间存储在数据库系统内存中的数据。如果数据库存储敏感数据，则组织可能需要确保防止高特权用户查看数据库中的敏感数据。高特权用户（例如组织中的Microsoft操作员或DBA）应该能够管理数据库，但不能通过查询数据库来查看并潜在地透露SQL进程内存中的敏感数据。

< ">需要确定哪些数据是敏感的，以及敏感数据是否必须在内存中加密并且不可供管理员以明文形式访问，用于确定这些事项的策略特定于你的组织以及你需要遵守的合规性规定。请参阅相关要求：识别并标记敏感数据。

< ">如何实现：

< ">使用Always Encrypted来确保不会以纯文本形式公开Azure SQL数据库或SQL托管实例中的敏感数据，即使是内存中/使用中的数据。Always Encrypted可以防止数据库管理员(DBA)和云管理员（或者可以仿冒未经授权的高特权用户的恶意行动者）查看数据，并使你能够以更高的力度控制谁可以访问数据。

< ">最佳做法：

< ">Always Encrypted不能取代静态数据加密(TDE)或传输中数据加密(SSL/TLS)。为了尽量减轻对性能和功能的影响，请不要将Always Encrypted用于非敏感数据。建议将Always Encrypted与TDE和传输层安全性(TLS)结合使用，以全面保护静态数据、传输中的数据和使用中的数据。

< ">在生产数据库中部署Always Encrypted之前，请先评估对所识别出的敏感数据列进行加密会带来的影响。通常情况下，Always Encrypted会降低对加密列的查询功能，并具有其他限制，如Always Encrypted-功能详细信息中所列。因此，你可能需要在客户端重构你的应用程序来重新实现查询不支持的功能，或者/并且重构你的数据库架构，包括存储过程、函数、视图和触发器的定义。如果现有应用程序未遵守Always Encrypted的限制，则可能无法使用加密列。虽然支持Always Encrypted的Microsoft工具、产品和服务的生态系统在不断增长，但它们中还是有许多不能使用加密列。加密列还可能会影响查询性能，具体取决于工作负荷的特征。

< ">如果使用Always Encrypted来防止恶意DBA查看数据，请通过角色分离来管理Always Encrypted密钥。安全管理员可以使用角色分离来创建物理密钥。DBA在数据库中创建用于描述物理密钥的列主密钥和列加密密钥元数据对象。在此过程中，安全管理员不需要访问数据库，且DBA不需要访问纯文本形式的物理密钥。

< ">将列主密钥存储在Azure Key Vault中，以方便管理。避免使用会使密钥管理变得困难的Windows证书存储（以及一般的分布式密钥存储解决方案，而不是集中式密钥管理解决方案）。

< ">仔细考虑使用多个密钥（列主密钥或列加密密钥）的利弊。保留少量的密钥以减小密钥管理成本。在稳定态的环境中（而不是在密钥轮换的中途），为每个数据库准备一个列主密钥和一个列加密密钥通常已足够。如果有不同的用户组，而每个组使用不同的密钥并访问不同的数据，则可能需要更多的密钥。

< ">根据合规要求轮换列主密钥。如果还需要轮换列加密密钥，请考虑使用在线加密来尽量减少应用程序停机时间。

< ">如果需要支持数据计算（相等性），请使用确定性加密。否则请使用随机加密。避免将确定性加密用于低熵数据集或采用众所周知分布形式的数据集。

< ">如果你担心第三方在合法的情况下访问你的数据，请确保能够以纯文本形式访问密钥和数据的所有应用程序和工具在Microsoft Azure云的外部运行。如果第三方无权访问密钥，则除非绕过加密，否则他们无法解密数据。

< ">Always Encrypted无法轻松支持授予对密钥（和受保护数据）的临时访问权限。例如，如果需要与DBA共享密钥，使DBA能够对敏感数据和加密的数据执行一些清理操作。可靠撤销DBA的数据访问权限的唯一方法是，同时轮换用于保护数据的列加密密钥和列主密钥，而这是一项开销较高的操作。

< ">若要访问已加密列中的纯文本值，用户需要有权访问用于保护列的列主密钥(CMK)（在保存CMK的密钥存储中进行配置）。用户还需要拥有“查看任何列主密钥定义”和“查看任何列加密密钥定义”数据库权限。

< ">通过加密控制应用程序用户对敏感数据的访问

< ">可以使用加密来确保只有有权访问加密密钥的特定应用程序用户才能查看或更新数据。

< ">如何实现：

< ">使用单元级加密(CLE)。有关详细信息，请参阅加密数据列一文。

< ">使用Always Encrypted，但要注意其限制。下面列出了限制。

< ">最佳实践

< ">使用CLE时：

< ">通过SQL权限和角色控制对密钥的访问。

< ">使用AES(推荐AES 256)进行数据加密。由于存在已知漏洞，RC4、DES和TripleDES等算法已遭弃用，请不要使用它们。

< ">使用非对称密钥/证书（而不是密码）来保护对称密钥，以避免使用3DES。

< ">通过导出/导入（bacpac文件）使用单元级加密迁移数据库时请小心。

< ">有关在迁移数据时如何防止丢失密钥以及其他最佳做法指导，请参阅有关在Azure SQL数据库中使用单元级加密的建议。

< ">请记住，Always Encrypted主要用于防止Azure SQL数据库的高特权用户（云操作员、DBA）查看使用中的敏感数据-请参阅防止防止未经授权的高特权用户查看使用中的敏感数据。使用Always Encrypted防止应用程序用户查看数据时，请注意以下难点：

< ">默认情况下，支持Always Encrypted的所有Microsoft客户端驱动程序都会维护列加密密钥的全局缓存（每个应用程序一个缓存）。在客户端驱动程序通过联系保存列主密钥的密钥存储获取纯文本列加密密钥后，将会缓存纯文本列加密密钥。这使得将数据与多用户应用程序的用户相隔离变得困难。如果应用程序在与密钥存储交互（例如Azure Key Vault）时模拟最终用户，则在用户的查询使用列加密密钥填充缓存之后，需要同一个密钥但由其他用户触发的后续查询将使用缓存的密钥。驱动程序不会调用密钥存储，也不会检查第二个用户是否有权访问列加密密钥。因此，即使用户无权访问密钥，也可以查看加密的数据。若要在多用户应用程序中实现用户隔离，可以禁用列加密密钥缓存。禁用缓存会导致性能开销增大，因为驱动程序需要联系密钥存储来完成每个数据加密或解密操作。

< ">在保留数据格式的同时防止应用程序用户在未经授权的情况下查看数据

< ">防止未经授权的用户查看数据的另一种方法是对数据进行模糊处理或掩码，同时保留数据类型和格式，以确保用户应用程序可以继续处理和显示数据。

< ">如何实现：

< ">使用动态数据掩码来模糊处理表列。

< ">备注

< ">Always Encrypted不能与动态数据掩码配合工作。无法加密和掩码同一个列，这意味着，需确定是要优先保护使用中的数据，还是通过动态数据掩码来对应用用户掩码数据。

< ">最佳做法：

< ">备注

< ">动态数据掩码不可用于防止高特权用户查看数据。掩码策略不适用于拥有管理访问权限的用户，例如db_owner。

< ">不要允许应用用户运行临时查询（因为他们也许可以克服动态数据掩码）。

< ">有关详细信息，请参阅使用推理或暴力破解技术绕过掩码一文。

< ">使用适当的访问控制策略（通过SQL权限、角色、RLS）来限制用户在掩码列中进行更新的权限。对列进行掩码不会阻止对该列进行更新。如果查询掩码列时收到掩码数据的用户拥有写入权限，则他们可以更新这些数据。

< ">动态数据掩码不会保留掩码值的统计属性。这可能会影响查询结果（例如，包含筛选谓词的查询或者对掩码数据的联接）。

< ">网络安全性

< ">网络安全性是指用于保护传输到Azure SQL数据库的数据的访问控制和最佳做法。

< ">配置客户端以安全连接到SQL数据库/SQL托管实例

< ">有关如何防范存在已知漏洞（例如，使用早期TLS协议和密码套件）的客户端计算机和应用程序连接到Azure SQL数据库和SQL托管实例的最佳做法。

< ">如何实现：

< ">确保连接到Azure SQL数据库和SQL托管实例的客户端计算机使用传输层安全性(TLS)。

< ">最佳做法：

< ">配置所有应用和工具以连接到启用了加密的SQL数据库

< ">Encrypt=On，TrustServerCertificate=Off（或者在非Microsoft驱动程序中配置相应的设置）。

< ">如果应用使用的驱动程序不支持TLS或者支持早期版本的TLS，请尽可能地更换驱动程序。如果无法做到这一点，请认真评估安全风险。

< ">减少通过SSL 2.0、SSL 3.0、TLS 1.0和TLS 1.1中的漏洞发起的攻击途径：根据传输层安全性(TLS)注册表设置，在连接到Azure SQL数据库的客户端计算机上禁用相关的途径。

< ">检查客户端上的密码套件：TLS/SSL(Schannel SSP)中的密码套件。具体而言，根据配置TLS密码套件顺序禁用3DES。

< ">对于Azure SQL数据库和SQL托管实例，将对“代理”和“重定向”连接类型强制加密。对于Azure SQL托管实例，请使用“代理”连接类型（默认设置），因为这可以强制在服务器端加密。“重定向”连接类型目前不支持加密强制，仅在专用IP连接上可用。

< ">尽量减少受攻击面

< ">尽量减少恶意用户可以攻击的特征数。对Azure SQL数据库实现网络访问控制。

< ">内容来源：OSA做法#5

< ">如何实现：

< ">在SQL数据库中：

< ">在服务器级别将“允许访问Azure服务”设置为“关闭”

< ">使用VNet服务终结点和VNet防火墙规则。

< ">使用专用链接（预览）。

< ">在SQL托管实例中：

< ">遵循网络要求中的指导原则。

< ">最佳做法：

< ">通过连接到专用终结点（例如，使用专用数据路径）来限制对Azure SQL数据库和SQL托管实例的访问：

< ">可将托管实例隔离在虚拟网络内，防止外部访问。位于同一区域的相同或对等虚拟网络中的应用程序和工具可以直接访问它。位于不同区域的应用程序和工具可使用虚拟网络到虚拟网络连接，或使用ExpressRoute线路对等互连来建立连接。客户应使用网络安全组(NSG)来仅限通过端口1433访问需要访问托管实例的资源。

< ">对于SQL数据库，请使用专用链接功能，该功能为虚拟网络中的服务器提供专用专用IP。还可使用配置了虚拟网络防火墙规则的虚拟网络服务终结点来限制对服务器的访问。

< ">移动用户应使用点到站点VPN连接，通过数据路径进行连接。

< ">连接到本地网络的用户应使用站点到站点VPN连接或ExpressRoute，通过数据路径进行连接。

< ">可以通过连接到公共终结点（例如，使用公共数据路径）来访问Azure SQL数据库和SQL托管实例。应考虑以下最佳做法：

< ">对于SQL数据库中的服务器，请使用IP防火墙规则，仅限访问已授权的IP地址。

< ">对于SQL托管实例，请使用网络安全组(NSG)，仅限通过端口3342访问所需的资源。有关详细信息，请参阅在公共终结点中安全使用托管实例。

< ">备注

< ">SQL托管实例公共终结点默认未启用，必须显式启用它。如果公司政策禁止使用公共终结点，请首先使用Azure Policy来防止启用公共终结点。

< ">设置Azure网络组件：

< ">按照Azure网络安全最佳做法进行操作。

< ">根据Azure虚拟网络常见问题解答(FAQ)和计划中所述的最佳做法规划虚拟网络配置。

< ">将虚拟网络划分为多个子网，并将类似角色的资源（例如，前端与后端资源）分配到同一子网。

< ">使用网络安全组(NSG)来控制Azure虚拟网络边界范围内子网之间的流量。

< ">为订阅启用Azure网络观察程序，以监视入站和出站网络流量。

< ">配置Power BI以安全连接到SQL数据库/SQL托管实例

< ">最佳做法：

< ">对于Power BI Desktop，请尽可能地使用专用数据路径。

< ">根据传输层安全性(TLS)注册表设置在客户端计算机上设置注册表项，确保Power BI Desktop使用TLS1.2进行连接。

< ">通过Power BI行级安全性(RLS)限制特定用户的数据访问权限。

< ">对于Power BI服务，请使用本地数据网关，同时请记住限制和注意事项。

< ">配置应用服务以安全连接到SQL数据库/SQL托管实例

< ">最佳做法：

< ">对于简单的Web应用，通过公共终结点进行连接需要将“允许Azure服务”设置为“打开”。

< ">将应用与Azure虚拟网络集成，以通过专用数据路径连接到托管实例。（可选）还可以部署采用应用服务环境(ASE)的Web应用。

< ">对于连接到SQL数据库中的数据库的、采用ASE的Web应用或者与虚拟网络集成的Web应用，可以使用虚拟网络服务终结点和虚拟网络防火墙规则来限制从特定虚拟网络和子网的访问。然后，将“允许Azure服务”设置为“关闭”。还可以通过专用数据路径将ASE连接到SQL托管实例中的托管实例。

< ">确保Web应用按照使用Azure应用服务保护平台即服务(PaaS)Web和移动应用程序的最佳做法一文进行了配置。

< ">安装Web应用程序防火墙(WAF)，以防止Web应用遭到常见的恶意利用和出现漏洞。

< ">配置Azure虚拟机以安全连接到SQL数据库/SQL托管实例

< ">最佳做法：

< ">在Azure虚拟机的NSG中结合使用“允许”和“拒绝”规则，以控制可从VM访问哪些区域。

< ">确保VM根据Azure中IaaS工作负载的安全性最佳做法一文进行了配置。

< ">确保所有VM与特定的虚拟网络和子网相关联。

< ">根据关于强制隧道中的指导，评估是否需要默认路由0.0.0.0/Internet。

< ">如果需要（例如在前端子网中），请保留默认路由。

< ">如果不需要（例如在中间层或后端子网中），请启用强制隧道，使流量不会通过Internet抵达本地（即跨界）。

< ">如果使用对等互连或者连接到本地，请实现可选默认路由。

< ">如果需要将虚拟网络中的所有流量发送到网络虚拟设备进行数据包检查，请实现用户定义的路由。

< ">使用虚拟网络服务终结点通过Azure主干网络安全访问Azure存储等PaaS服务。

< ">防范分布式拒绝服务(DDoS)攻击

< ">分布式拒绝服务(DDoS)攻击由恶意用户尝试向Azure SQL数据库发送大量网络流量，目的是使Azure基础结构成为惊人，并导致其拒绝有效登录和工作负荷。

< ">中提到的：OSA实践#9

< ">如何实现：

< ">在Azure平台中，会自动启用DDoS保护。它包括always on流量监视和对公共终结点上网络级别攻击的实时缓解。

< ">使用Azure DDoS防护来监视与虚拟网络中部署的资源关联的公共IP地址。

< ">使用AZURE SQL数据库的高级威胁防护来检测对数据库的拒绝服务(DoS)攻击。

< ">最佳做法：

< ">遵循最小化攻击面中所述的做法有助于最大程度地减少DDoS攻击威胁。

< ">高级威胁防护强力强制SQL凭据警报有助于检测暴力破解攻击。在某些情况下，警报甚至可以区分渗透测试工作负荷。

< ">对于托管连接到SQL数据库的应用程序的Azure VM：

< ">遵循建议，在Azure安全中心中通过面向Internet的终结点限制访问。

< ">使用虚拟机规模集在Azure Vm上运行应用程序的多个实例。

< ">禁用来自Internet的RDP和SSH，以防止强力攻击。

< ">监视、日志记录和审核

< ">本部分所述的功能可帮助你检测异常活动，这些活动指示非同寻常或者潜在有害的访问或恶意利用数据库的企图。本部分还将提供有关配置数据库审核来跟踪和捕获数据库事件的最佳做法。

< ">防范数据库遭到攻击

< ">高级威胁防护可在发生异常活动时提供安全警报，让我们检测潜在威胁并做出响应。

< ">如何实现：

< ">使用适用于SQL的高级威胁防护来检测非同寻常或者潜在有害的访问或恶意利用数据库的企图，包括：

< ">SQL注入攻击。

< ">凭据盗窃/泄露。

< ">特权滥用。

< ">数据透露。

< ">最佳做法：

< ">为特定服务器或托管实例配置Azure Defender for SQL。还可以通过切换到Azure安全中心标准层，为订阅中的所有服务器和托管实例配置Azure Defender for SQL。

< ">若要获得完整的调查体验，建议启用SQL数据库审核。使用审核可以跟踪数据库事件，并将这些事件写入到Azure存储帐户或Azure Log Analytics工作区中的审核日志。

< ">审核关键安全事件

< ">跟踪数据库事件有助于了解数据库活动。可以洞察可能指示业务关注点或可疑安全违规的差异与异常。此措施还有助于遵守法规标准。

< ">如何实现：

< ">启用SQL数据库审核或托管实例审核以跟踪数据库事件，并将这些事件写入到Azure存储帐户、Log Analytics工作区（预览版）或事件中心（预览版）中的审核日志。

< ">可将审核日志写入Azure存储帐户、写入Log Analytics工作区（供Azure Monitor日志使用），或写入事件中心（供事件中心使用）。可以将这些选项随意组合起来进行配置，审核日志会写入到每一个之中。

< ">最佳做法：

< ">在服务器上配置SQL数据库审核或配置托管实例审核以审核事件后，该服务器上所有现有的和新建的数据库都会被审核。

< ">审核策略默认包括对数据库执行的所有操作（查询、存储过程，以及成功和失败的登录），这可能会导致生成大量的审核日志。建议客户使用PowerShell对不同类型的操作和操作组配置审核。此项配置有助于控制审核的操作数量，并将事件丢失的风险降到最低。自定义审核配置可让客户仅捕获所需的审核数据。

< ">可以在Azure门户中直接使用审核日志，或者从配置的存储位置使用。

< ">备注

< ">启用在Log Analytics中进行审核会根据引入速率产生成本。请注意，使用此选项会产生相关的成本；或者，可以考虑将审核日志存储在Azur厦门网络公关公司e存储帐户中。

< ">其他资源：

< ">SQL数据库审核

< ">SQL Server审核

< ">保护审核日志

< ">限制对存储帐户的访问，以支持职责分离，并将DBA与审核员区分开来。

< ">如何实现：

< ">将审核日志保存到Azure存储时，请确保按照最低安全原则来限制对存储帐户的访问。控制谁有权访问存储帐户。

< ">有关详细信息，请参阅授权访问Azure存储。

< ">最佳做法：

< ">控制对审核目标的访问是将DBA与审核员相区分时使用的重要概念。

< ">审核对敏感数据的访问时，请考虑使用数据加密来保护数据，以免向审核员透露信息。有关详细信息，请参阅防止未经授权的高特权用户查看使用中的敏感数据部分。

< ">安全管理

< ">本部分介绍有关管理数据库安全态势的各个方面和最佳做法。其中提供了有关确保根据安全标准配置数据库、发现漏洞，以及分类和跟踪对数据库中潜在敏感数据的访问的最佳做法。

< ">确保根据安全最佳做法配置数据库

< ">通过发现并修正潜在数据库漏洞来主动改善数据库的安全性。

< ">如何实现：

< ">启用SQL漏洞评估(VA)来扫描数据库的安全问题，并使其定期对数据库自动运行。

< ">最佳做法：

< ">对数据库运行首次VA，在补救不符合安全最佳做法的失败检查后反复运行VA。设置可接受配置的基线，直到扫描结果全部正常，或所有检查均已通过。

< ">将定期的重复扫描配置为每周运行一次，并配置相关人员来接收摘要电子邮件。

< ">完成电视冠名广告每周扫描后查看VA摘要。对于发现的任何漏洞，评估与前一次扫描结果的偏差，并确定是否应解决本次检查发现的问题。查看配置发生更改是否有合理的原因。

< ">解决检查发现的问题并更新相关的基线。为解决措施创建票证项，并在解决问题之前跟踪这些项。

< ">其他资源：

< ">SQL漏洞评估

< ">SQL漏洞评估服务有助于识别数据库漏洞

< ">识别并标记敏感数据

< ">发现可能包含敏感数据的列。什么数据是敏感数据在很大程度上取决于客户、合规性规定等，并且需要由负责该数据的用户进行评估。将列分类以使用基于敏感性的高级审核和保护方案。

< ">如何实现：

< ">使用SQL数据发现和分类来发现、分类、标记和保护数据库中的敏感数据。

< ">在SQL数据发现和分类仪表板中查看自动发现创建的分类建议。接受相关的分类，以使用分类标签来持久标记敏感数据。

< ">对于未被自动机制发现的任何其他敏感数据字段，请手动添加分类。

< ">有关详细信息，请参与SQL数据发现和分类。

< ">最佳做法：

< ">定期监视分类仪表板，准确评估数据库的分类状态。可以导出或打印有关数据库分类状态的报告，以使在合规与审核措施中共享。

< ">持续监视SQL漏洞评估中建议的敏感数据的状态。跟踪敏感数据发现规则，识别建议列中的任何分类偏差。

< ">使用根据你的组织的特定需求定制的方式使用分类。在Azure安全中心的SQL信息保护策略中，自定义信息保护策略(敏感度标签、信息类型、发现逻辑)。

< ">跟踪对敏感数据的访问

< ">在审核日志中监视谁访问了敏感数据，并捕获对敏感数据运行的查询。

< ">如何实现：

< ">结合使用SQL审核和数据分类。

< ">在SQL数据库审核日志中，可以专门跟踪对敏感数据的访问。还可以查看访问的数据及其敏感性标签等信息。有关详细信息，请参阅数据发现和分类和审核对敏感数据的访问。

< ">最佳做法：

< ">参阅有关审核和数据分类的最佳做法部分：

< ">审核关键安全事件

< ">识别并标记敏感数据

< ">可视化安全性与合规性状态

< ">使用统一的基础结构安全管理系统来增强数据中心（包括SQL数据库中的数据库）的安全态势。查看有关数据库安全性与合规性状态的建议列表。

< ">如何实现：

< ">在Azure安全中心监视SQL相关的安全建议与正在进行的威胁。

< ">常见安全威胁和潜在缓解措施

< ">本部分帮助你找到用于防范特定攻击途径的安全措施。遵循上述一条或多条安全指导原则预期可以实现大部分缓解措施。

< ">安全威胁：数据透露

< ">Data透露是指在未经授权的情况下，从计算机或服务器复制、传输或检索数据。查看维基百科中的数据透露定义。

< ">通过公共终结点连接到服务器会带来数据透露的风险，因为这需要客户向公共IP打开其防火墙。

< ">场景1：Azure VM上的某个应用程序连接到Azure SQL数据库中的某个数据库。恶意行动者获取VM的访问权限并入侵到其中。在此场景中，数据透露表示使用恶意VM的外部实体连接到数据库，复制个人数据，并将这些数据存储在Blob存储中或者不同订阅内的不同SQL数据库中。

< ">场景2：恶意DBA。这种场景通常出现在受管制行业的安全敏感型客户那里。在此场景中，高特权用户可将Azure SQL数据库中的数据复制到不受数据所有者控制的其他订阅。

< ">潜在缓解措施：

< ">Azure SQL数据库和SQL托管实例目前提供以下技术来缓解数据透露威胁：

< ">在Azure VM的NSG中结合使用“允许”和“拒绝”规则，以控制可从VM访问哪些区域。

< ">如果在SQL数据库中使用服务器，请设置以下选项：

< ">将“允许Azure服务”设置为“关闭”。

< ">设置VNet防火墙规则，仅允许来自包含你的Azure VM的子网的流量。

< ">使用专用链接

< ">对于SQL托管实例，使用专用IP访问默认可以解决恶意VM的首要数据透露隐患。在子网中启用子网委托功能，以在SQL托管实例子网中自动设置最严格的策略。

< ">恶意DBA隐患主要出现在SQL托管实例上，因为SQL托管实例的受攻击面较大，而网络要求对客户是可见的。此问题的最佳缓解措施是首先应用本安全指南中的所有做法，以防止出现恶意DBA的情景（不仅可以解决数据透露）。Always Encrypted是保护敏感数据的一种方法，它可以加密敏感数据，并使DBA无法访问密钥。

< ">业务连续性和可用性的安全性方面

< ">大多数安全标准在操作连续性方面解决数据可用性问题，实现此效果的方式是实施冗余和故障转移功能来避免单一故障点。对于灾难恢复方案，常见的做法是保留数据和日志文件的备份。以下部分概述了Azure中内置的功能。此外，提供了可根据具体需求进行配置的其他选项：

< ">Azure提供内置的高可用性：SQL数据库和SQL托管实例的高可用性

< ">“业务关键”层包括故障转移组、完整和差异日志备份，以及默认已启用的时间点还原备份：

< ">自动备份

< ">使用自动数据库备份恢复数据库-时间点还原

< ">可以配置其他业务连续性功能，如跨不同Azure地域的区域冗余配置和自动故障转移组：

< ">高级&业务关键服务层的高可用性区域冗余配置

< ">常规用途服务层的高可用性区域冗余配置

< ">业务连续性概述