用于解决 Azure SQL 数据库和 Azure SQL 托管实例常见安全要求的 playbookPlaybook for addressing common security requirements with Azure SQL Database and Azure SQL Managed Instance

适用于: Azure SQL 数据库 Azure SQL 托管实例

本文提供了有关如何解决常见安全要求的最佳做法。This article provides best practices on how to solve common security requirements. 并非所有要求都适用于所有环境,你应该向数据库和安全团队咨询要实现哪些功能。Not all requirements are applicable to all environments, and you should consult your database and security team on which features to implement.

解决常见的安全要求Solving common security requirements

本文档提供有关如何解决使用 Azure SQL 数据库和 Azure SQL 托管实例的新应用程序或现有应用程序的常见安全要求的指导。This document provides guidance on how to solve common security requirements for new or existing applications using Azure SQL Database and Azure SQL Managed Instance. 本文档的内容已从较高层面按照安全考虑因素进行组织。It's organized by high-level security areas. 若要解决特定的威胁,请参阅常见安全威胁和潜在缓解措施部分。For addressing specific threats, refer to the Common security threats and potential mitigations section. 提供的某些建议在将应用程序从本地迁移到 Azure 时适用,不过,本文档不会重点说明迁移方案。Although some of the presented recommendations are applicable when migrating applications from on-premises to Azure, migration scenarios are not the focus of this document.

本指南涉及的 Azure SQL 数据库部署产品/服务Azure SQL Database deployment offers covered in this guide

本指南不涉及的部署产品/服务Deployment offers not covered in this guide

  • Azure Synapse AnalyticsAzure Synapse Analytics
  • Azure SQL VM (IaaS)Azure SQL VMs (IaaS)
  • SQL ServerSQL Server


本指南的目标读者是在保护 Azure SQL 数据库时遇到问题的客户。The intended audiences for this guide are customers facing questions on how to secure Azure SQL Database. 对本最佳做法文章感兴趣的角色包括但不限于:The roles interested in this best practice article include, but not limited to:

  • 安全架构师Security Architects
  • 安全经理Security Managers
  • 合规性主管Compliance Officers
  • 隐私主管Privacy Officers
  • 安全工程师Security Engineers

使用本指南Using this guide

本文档旨在用作现有 Azure SQL 数据库安全性文档的配套资源。This document is intended as a companion to our existing Azure SQL Database security documentation.

除非另有说明,否则我们建议遵循每个部分中列出的所有最佳做法,以实现相关的目标或要求。Unless otherwise stated, we recommend you follow all best practices listed in each section to achieve the respective goal or requirement. 为了帮助客户满足特定的安全合规标准或最佳做法,在适用的情况下,“要求或目标”部分下面会列出重要的法规控制措施。To meet specific security compliance standards or best practices, important regulatory compliance controls are listed under the Requirements or Goals section wherever applicable. 本文参考了以下安全标准和法规:These are the security standards and regulations that are referenced in this paper:

我们计划持续更新本文列出的建议和最佳做法。We plan on continuing to update the recommendations and best practices listed here.


身份验证是证明用户所声明身份的过程。Authentication is the process of proving the user is who they claim to be. Azure SQL 数据库和 SQL 托管实例支持两种类型的身份验证:Azure SQL Database and SQL Managed Instance support two types of authentication:

  • SQL 身份验证SQL authentication
  • Azure Active Directory 身份验证Azure Active Directory authentication


并非所有工具和第三方应用程序都支持 Azure Active Directory 身份验证。Azure Active Directory authentication may not be supported for all tools and 3rd party applications.

标识的集中管理Central management for identities

集中式标识管理提供以下优势:Central identity management offers the following benefits:

  • 管理组帐户并控制用户权限,而无需跨服务器、数据库和托管实例重复登录。Manage group accounts and control user permissions without duplicating logins across servers, databases and managed instances.
  • 简化且灵活的权限管理。Simplified and flexible permission management.
  • 应用程序的大规模管理。Management of applications at scale.

如何实现How to implement:

  • 使用 Azure Active Directory (Azure AD) 身份验证实现集中式标识管理。Use Azure Active Directory (Azure AD) authentication for centralized identity management.

最佳做法Best practices:


  • Azure AD 身份验证记录在 Azure SQL 审核日志中,而不是记录在 Azure AD 登录日志中。Azure AD authentication is recorded in Azure SQL audit logs, but not in Azure AD sign-in logs.
  • 在 Azure 中授予的 Azure RBAC 权限不适用于 Azure SQL 数据库或 SQL 托管实例权限。Azure RBAC permissions granted in Azure do not apply to Azure SQL Database or SQL Managed Instance permissions. 必须使用现有的 SQL 权限手动创建/映射此类权限。Such permissions must be created/mapped manually using existing SQL permissions.
  • 在客户端上,Azure AD 身份验证需要访问 Internet,或通过用户定义的路由 (UDR) 访问虚拟网络。On the client-side, Azure AD authentication needs access to the internet or via User Defined Route (UDR) to a virtual network.

Azure AD 多重身份验证Azure AD Multi-Factor Authentication

内容来源:OSA 做法 #2,ISO 访问控制 (AC)Mentioned in: OSA Practice #2, ISO Access Control (AC)

Azure AD 多重身份验证要求完成多种形式的身份验证,因而有助于提高安全性。Azure AD Multi-Factor Authentication helps provides additional security by requiring more than one form of authentication.

如何实现How to implement:

  • 使用条件访问在 Azure AD 中启用多重身份验证,并使用交互式身份验证。Enable Multi-Factor Authentication in Azure AD using Conditional Access and use interactive authentication.

  • 或者,为整个 Azure AD 或 AD 域启用多重身份验证。The alternative is to enable Multi-Factor Authentication for the entire Azure AD or AD domain.

最佳做法Best practices:

尽量减少对用户使用基于密码的身份验证Minimize the use of password-based authentication for users

内容来源:OSA 做法 #4,ISO 访问控制 (AC)Mentioned in: OSA Practice #4, ISO Access Control (AC)

基于密码的身份验证方法是较弱的身份验证形式。Password-based authentication methods are a weaker form of authentication. 凭据可能会透露或者被错误地丢弃。Credentials can be compromised or mistakenly given away.

如何实现How to implement:

  • 使用 Azure AD 集成身份验证,此方法可消除密码的使用。Use an Azure AD integrated authentication that eliminates the use of passwords.

最佳做法Best practices:

  • 使用 Windows 凭据进行单一登录身份验证。Use single sign-on authentication using Windows credentials. 将本地 AD 域与 Azure AD 相联合,并使用 Windows 集成身份验证(适用于 Azure AD 中已加入域的计算机)。Federate the on-premises AD domain with Azure AD and use Integrated Windows authentication (for domain-joined machines with Azure AD).

尽量减少对应用程序使用基于密码的身份验证Minimize the use of password-based authentication for applications

内容来源:OSA 做法 #4,ISO 访问控制 (AC)Mentioned in: OSA Practice #4, ISO Access Control (AC)

如何实现How to implement:

  • 启用 Azure 托管标识。Enable Azure Managed Identity. 还可以使用集成式或基于证书的身份验证。You can also use integrated or certificate-based authentication.

最佳做法Best practices:

保护密码和机密Protect passwords and secrets

如果不可避免地需要使用密码,请确保密码受到保护。For cases when passwords aren't avoidable, make sure they're secured.

如何实现How to implement:

  • 使用 Azure Key Vault 存储密码和机密。Use Azure Key Vault to store passwords and secrets. 在适用的情况下,请对 Azure AD 用户使用 Azure SQL 数据库的多重身份验证。Whenever applicable, use Multi-Factor Authentication for Azure SQL Database with Azure AD users.

最佳做法Best practices:

  • 如果无法避免密码或机密的使用,请在 Azure Key Vault 中存储用户密码和应用程序机密,并通过 Key Vault 访问策略管理访问权限。If avoiding passwords or secrets aren't possible, store user passwords and application secrets in Azure Key Vault and manage access through Key Vault access policies.

  • 各种应用开发框架还可能提供框架特定的机制来保护应用中的机密。Various app development frameworks may also offer framework-specific mechanisms for protecting secrets in the app. 例如:ASP.NET Core 应用For example: ASP.NET core app.

对旧式应用程序使用 SQL 身份验证Use SQL authentication for legacy applications

SQL 身份验证是指使用用户名和密码连接到 Azure SQL 数据库或 SQL 托管实例时对用户进行身份验证。SQL authentication refers to the authentication of a user when connecting to Azure SQL Database or SQL Managed Instance using username and password. 需要在每个服务器或托管实例中创建一个登录名,并在每个数据库中创建一个用户。A login will need to be created in each server or managed instance, and a user created in each database.

如何实现How to implement:

  • 使用 SQL 身份验证。Use SQL authentication.

最佳做法Best practices:

访问管理Access management

访问管理(也称为授权)是控制和管理已授权用户对 Azure SQL 数据库或 SQL 托管实例的访问权限与特权的过程。Access management (also called Authorization) is the process of controlling and managing authorized users' access and privileges to Azure SQL Database or SQL Managed Instance.

实施最低特权原则Implement principle of least privilege

内容来源:FedRamp 控制措施 AC-06,NIST:AC-6,OSA 做法 #3Mentioned in: FedRamp controls AC-06, NIST: AC-6, OSA Practice #3

最低特权原则指出,用户拥有的特权不应超过他们完成任务所需的特权。The principle of least privilege states that users shouldn't have more privileges than needed to complete their tasks. 有关详细信息,请参阅 Just Enough Administration 一文。For more information, see the article Just enough administration.

如何实现How to implement:

仅分配完成所需任务而需要的权限Assign only the necessary permissions to complete the required tasks:

最佳做法Best practices:

以下最佳做法是可选的,但可以改善安全策略的易管理性和支持性:The following best practices are optional but will result in better manageability and supportability of your security strategy:

  • 如果可能,请从尽可能低的权限集开始,并在有实际需要(和理由)时逐个添加权限 - 而不要采用相反的方法:逐步去除权限。If possible, start with the least possible set of permissions and start adding permissions one by one if there's a real necessity (and justification) – as opposed to the opposite approach: taking permissions away step by step.

  • 避免将权限分配给单个用户。Refrain from assigning permissions to individual users. 改为以一致的方式使用角色(数据库角色或服务器角色)。Use roles (database or server roles) consistently instead. 角色能够为报告权限和排查权限问题提供很大的帮助。Roles helps greatly with reporting and troubleshooting permissions. (Azure RBAC 仅支持通过角色分配权限。)(Azure RBAC only supports permission assignment via roles.)

  • 创建和使用具有所需确切权限的自定义角色。Create and use custom roles with the exact permissions needed. 实践中使用的典型角色:Typical roles that are used in practice:

    • 安全部署Security deployment
    • 管理员Administrator
    • 开发人员Developer
    • 支持人员Support personnel
    • 审核员Auditor
    • 自动化过程Automated processes
    • 最终用户End user
  • 只有当角色的权限与用户所需的权限完全匹配时,才使用内置角色。Use built-in roles only when the permissions of the roles match exactly the needed permissions for the user. 可将用户分配到多个角色。You can assign users to multiple roles.

  • 请记住,数据库引擎中的权限可以在以下范围内应用(范围越小,授予的权限的影响越小):Remember that permissions in the database engine can be applied within the following scopes (the smaller the scope, the smaller the impact of the granted permissions):


    不建议在对象级别应用权限,因为此级别会给整个实现带来不必要的复杂性。It is not recommended to apply permissions on the object level because this level adds unnecessary complexity to the overall implementation. 如果决定使用对象级权限,应明确阐述这些权限。If you decide to use object-level permissions, those should be clearly documented. 这同样适用于列级权限,出于相同的原因,我们更不建议应用此类权限The same applies to column-level-permissions, which are even less recommendable for the same reasons. 另请注意,默认情况下,表级 DENY 不会覆盖列级授权。Also be aware that by default a table-level DENY does not override a column-level GRANT. 这需要激活通用标准合规性服务器配置This would require the common criteria compliance Server Configuration to be activated.

  • 使用漏洞评估 (VA) 执行定期检查,以测试权限是否过多。Perform regular checks using Vulnerability Assessment (VA) to test for too many permissions.

实现职责分离Implement Separation of Duties

内容来源:FedRamp:AC-04,NIST:AC-5,ISO:6.1.2、PCI 6.4.2,SOC:CM-3、SDL-3Mentioned in: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

“职责分离”描述将敏感任务拆分为要分配给不同用户的多个任务的要求。Separation of Duties, also called Segregation of Duties describes the requirement to split sensitive tasks into multiple tasks that are assigned to different users. 职责分离有助于防止数据违规。Separation of Duties helps prevent data breaches.

如何实现How to implement:

  • 识别所需的职责分离级别。Identify the required level of Separation of Duties. 示例:Examples:

    • 在开发/测试环境与生产环境之间Between Development/Test and Production environments
    • 安全相关的任务、数据库管理员 (DBA) 管理级别任务与开发人员任务。Security-wise sensitive tasks vs Database Administrator (DBA) management level tasks vs developer tasks.
      • 示例:审核员为角色级安全性 (RLS) 创建安全策略,并使用 DDL 权限实现 SQL 数据库对象。Examples: Auditor, creation of security policy for Role-level Security (RLS), Implementing SQL Database objects with DDL-permissions.
  • 识别有权访问系统的用户(和自动化过程)的综合层次结构。Identify a comprehensive hierarchy of users (and automated processes) that access the system.

  • 根据所需的用户组创建角色,并将权限分配给角色。Create roles according to the needed user-groups and assign permissions to roles.

    • 对于通过 Azure 门户或 PowerShell 自动化完成的管理级任务,请使用 Azure 角色。For management-level tasks in Azure portal or via PowerShell-automation use Azure roles. 查找符合要求的内置角色,或者使用可用权限创建 Azure 自定义角色Either find a built-in role matching the requirement, or create an Azure custom role using the available permissions
    • 在托管实例中为服务器范围的任务(创建新的登录名和数据库)创建服务器角色。Create Server roles for server-wide tasks (creating new logins, databases) in a managed instance.
    • 为数据库级任务创建数据库角色。Create Database Roles for database-level tasks.
  • 对于某些敏感任务,考虑创建由证书签名的特殊存储过程,以代表用户执行这些任务。For certain sensitive tasks, consider creating special stored procedures signed by a certificate to execute the tasks on behalf of the users. 数字签名存储过程的一个重要优点是,如果更改了该过程,则会立即删除授予该过程的旧版本的权限。One important advantage of digitally signed stored procedures is that if the procedure is changed, the permissions that were granted to the previous version of the procedure are immediately removed.

  • 使用 Azure Key Vault 中客户管理的密钥实现透明数据加密 (TDE),以便在数据所有者与安全所有者之间实现职责分离。Implement Transparent Data Encryption (TDE) with customer-managed keys in Azure Key Vault to enable Separation of Duties between data owner and security owner.

  • 为了确保 DBA 无法看到高度敏感的数据但仍可执行 DBA 任务,可将 Always Encrypted 与角色分离配合使用。To ensure that a DBA can't see data that is considered highly sensitive and can still do DBA tasks, you can use Always Encrypted with role separation.

  • 如果使用 Always Encrypted 不可行(最起码在不付出极大成本和工作量的情况下做不到这一点,但如果付出,甚至可能会导致系统几乎不可用),可以通过补偿性的控制措施来采取折衷办法,例如:In cases where the use of Always Encrypted isn't feasible, or at least not without major costs and efforts that may even render the system near unusable, compromises can be made and mitigated through the use of compensating controls such as:

最佳做法Best practices:

  • 确保将不同的帐户用于开发/测试环境和生产环境。Make sure that different accounts are used for Development/Test and Production environments. 不同的帐户有助于满足测试和生产系统分离的原则。Different accounts help to comply with separation of Test and Production systems.

  • 避免将权限分配给单个用户。Refrain from assigning permissions to individual users. 改为以一致的方式使用角色(数据库角色或服务器角色)。Use roles (database or server roles) consistently instead. 使用角色能够为报告权限和排查权限问题提供很大的帮助。Having roles helps greatly with reporting and troubleshooting permissions.

  • 当权限与所需权限完全匹配时使用内置角色 – 如果多个内置角色的所有权限的联合导致 100% 匹配,则还可以同时分配多个角色。Use built-in roles when the permissions match exactly the needed permissions – if the union of all permissions from multiple built-in roles leads to a 100% match, you can assign multiple roles concurrently as well.

  • 当内置角色授予的权限过多或不足时,创建并使用用户定义的角色。Create and use user-defined roles when built-in roles grant too many permissions or insufficient permissions.

  • 还可以通过 T-SQL 的 SQL 代理作业步骤或适用于 Azure 角色的 Azure PIM 暂时执行角色分配(也称为动态职责分离 (DSD))。Role assignments can also be done temporarily, also known as Dynamic Separation of Duties (DSD), either within SQL Agent Job steps in T-SQL or using Azure PIM for Azure roles.

  • 确保 DBA 无权访问加密密钥或密钥存储,而有权访问密钥的安全管理员无权访问数据库。Make sure that DBAs don't have access to the encryption keys or key stores, and that Security Administrators with access to the keys have no access to the database in turn.

  • 始终确保针对安全相关的操作提供审核线索。Always make sure to have an Audit trail for security-related actions.

  • 可以检索 Azure 内置角色的定义以查看所用的权限,并通过 PowerShell 根据这些信息的摘录和累积创建自定义角色。You can retrieve the definition of the Azure built-in roles to see the permissions used and create a custom role based on excerpts and cumulations of these via PowerShell.

  • 由于 db_owner 数据库角色的任何成员都可以更改透明数据加密 (TDE) 等安全设置或更改 SLO,因此,应谨慎地授予此成员身份。Because any member of the db_owner database role can change security settings like Transparent Data Encryption (TDE), or change the SLO, this membership should be granted with care. 但是,许多任务要求使用 db_owner 特权。However, there are many tasks that require db_owner privileges. 例如,更改数据库选项等任何数据库设置的任务。Task like changing any database setting such as changing DB options. 在任何解决方案中,审核都发挥着关键的作用。Auditing plays a key role in any solution.

  • 无法限制 db_owner 的权限,因此应阻止管理帐户查看用户数据。It is not possible to restrict permissions of a db_owner, and therefore prevent an administrative account from viewing user data. 如果数据库中包含高度敏感的数据,可以使用 Always Encrypted 来安全阻止 db_owners 或任何其他 DBA 查看这些数据。If there's highly sensitive data in a database, Always Encrypted can be used to safely prevent db_owners or any other DBA from viewing it.


对安全相关的任务或故障排除任务实现职责分离 (SoD) 会有难度。Achieving Separation of Duties (SoD) is challenging for security-related or troubleshooting tasks. 其他方面(例如开发和最终用户角色)更易于分离。Other areas like development and end-user roles are easier to segregate. 当其他解决方案不可行时,大多数合规性相关的控制措施允许使用替代的控制功能,例如审核。Most compliance related controls allow the use of alternate control functions such as Auditing when other solutions aren't practical.

对于想要深入了解 SoD 的读者,建议阅读以下资源:For the readers that want to dive deeper into SoD, we recommend the following resources:

执行定期代码评审Perform regular code reviews

内容来源:PCI:6.3.2,SOC:SDL-3Mentioned in: PCI: 6.3.2, SOC: SDL-3

职责分离不局限于数据库中的数据,它还包括应用程序代码。Separation of Duties is not limited to the data in a database, but includes application code. 恶意代码可能会绕过安全控制。Malicious code can potentially circumvent security controls. 在将自定义代码部署到生产环境之前,必须评审要部署的内容,这一点至关重要。Before deploying custom code to production, it is essential to review what's being deployed.

如何实现How to implement:

  • 使用支持源代码管理的数据库工具,例如 Azure Data Studio。Use a database tool like Azure Data Studio that supports source control.

  • 实现分离的代码部署过程。Implement a segregated code deployment process.

  • 在提交到主分支之前,必须由某个人员(代码本身的作者除外)检查代码是否存在提升特权的风险,以及是否存在恶意的数据修改,以防止出现欺诈和恶意访问。Before committing to main branch, a person (other than the author of the code itself) has to inspect the code for potential elevation of privileges risks as well as malicious data modifications to protect against fraud and rogue access. 可以使用源代码管理机制实现此目的。This can be done using source control mechanisms.

最佳做法Best practices:

  • 标准化:实现每次更新代码时都要遵循的标准过程会很有帮助。Standardization: It helps to implement a standard procedure that is to be followed for any code updates.

  • 漏洞评估中的规则可以检查是否存在过多的权限、是否使用了旧加密算法,以及数据库架构中是否存在其他安全问题。Vulnerability Assessment contains rules that check for excessive permissions, the use of old encryption algorithms, and other security problems within a database schema.

  • 可以在 QA 或测试环境中使用高级威胁防护来执行更多的检查,此技术将扫描容易受到 SQL 注入攻击的代码。Further checks can be done in a QA or test environment using Advanced Threat Protection that scans for code that is vulnerable to SQL-injection.

  • 要注意的方面的示例:Examples of what to look out for:

    • 从自动化 SQL 代码更新部署内部创建用户或更改安全设置。Creation of a user or changing security settings from within an automated SQL-code-update deployment.
    • 某个存储过程根据提供的参数以不一致的方式更新单元格中的货币值。A stored procedure, which, depending on the parameters provided, updates a monetary value in a cell in a non-conforming way.
  • 确保执行评审的人员是除原始代码作者以外的个人,且熟悉代码评审和安全编码。Make sure the person conducting the review is an individual other than the originating code author and knowledgeable in code-reviews and secure coding.

  • 确保知道所有代码更改来源。Be sure to know all sources of code-changes. 代码可能位于 T-SQL 脚本中。Code can be in T-SQL Scripts. 它可能是要以视图、函数、触发器和存储过程形式执行或部署的临时命令。It can be ad-hoc commands to be executed or be deployed in forms of Views, Functions, Triggers, and Stored Procedures. 它可能是 SQL 代理作业定义(步骤)的一部分。It can be part of SQL Agent Job definitions (Steps). 它还可能从 SSIS 包、Azure 数据工厂和其他服务的内部执行。It can also be executed from within SSIS packages, Azure Data Factory, and other services.

数据保护Data protection

数据保护是通过加密或模糊处理来防止重要信息遭到透露的一组功能。Data protection is a set of capabilities for safeguarding important information from compromise by encryption or obfuscation.


Microsoft 的 Azure SQL 数据库和 SQL 托管实例已通过 FIPS 140-2 级别 1 合规认证。Microsoft attests to Azure SQL Database and SQL Managed Instance as being FIPS 140-2 Level 1 compliant. 认证过程中已确认它严格使用 FIPS 140-2 级别 1 可接受的算法,以及这些算法的、经 FIPS 140-2 级别 1 验证的实例,包括符合所需密钥长度、密钥管理、密钥生成和密钥存储的要求。This is done after verifying the strict use of FIPS 140-2 Level 1 acceptable algorithms and FIPS 140-2 Level 1 validated instances of those algorithms including consistency with required key lengths, key management, key generation, and key storage. 此项认证意味着,我们的客户在处理数据或者交付系统或应用程序的过程中,可以满足使用 FIPS 140-2 级别 1 验证实例的需求或要求。This attestation is meant to allow our customers to respond to the need or requirement for the use of FIPS 140-2 Level 1 validated instances in the processing of data or delivery of systems or applications.

加密传输中的数据Encrypt data in transit

内容来源:OSA 做法 #6,ISO 控制系列:CryptographyMentioned in: OSA Practice #6, ISO Control Family: Cryptography

当数据在客户端与服务器之间移动时为其提供保护。Protects your data while data moves between your client and server. 请参阅网络安全性Refer to Network Security.

静态数据加密Encrypt data at rest

内容来源:OSA 做法 #6,ISO 控制系列:CryptographyMentioned in: OSA Practice #6, ISO Control Family: Cryptography

静态加密是指对数据库、日志和备份文件中保存的数据进行加密保护。Encryption at rest is the cryptographic protection of data when it is persisted in database, log, and backup files.

如何实现How to implement:

  • 对于 2017 年后在 Azure SQL 数据库和 SQL 托管实例中创建的任何数据库,默认将启用通过服务托管的密钥进行透明数据库加密 (TDE)Transparent Database Encryption (TDE) with service managed keys are enabled by default for any databases created after 2017 in Azure SQL Database and SQL Managed Instance.
  • 在托管实例中,如果数据库是使用本地服务器从还原操作创建的,则会遵循原始数据库的 TDE 设置。In a managed instance, if the database is created from a restore operation using an on-premises server, the TDE setting of the original database will be honored. 如果未为原始数据库启用 TDE,则我们建议手动为托管实例启用 TDE。If the original database doesn't have TDE enabled, we recommend that TDE be manually turned on for the managed instance.

最佳做法Best practices:

  • 不要将需要静态加密的数据存储在 master 数据库中。Don't store data that requires encryption-at-rest in the master database. 无法使用 TDE 加密 master 数据库。The master database can't be encrypted with TDE.

  • 如果需要提高透明度并精细控制 TDE 保护,请使用 Azure Key Vault 中客户管理的密钥。Use customer-managed keys in Azure Key Vault if you need increased transparency and granular control over the TDE protection. Azure Key Vault 允许随时撤销权限,使数据库不可访问。Azure Key Vault allows the ability to revoke permissions at any time to render the database inaccessible. 可以集中管理 TDE 保护器及其他密钥,或使用 Azure Key Vault 按自己的计划轮换 TDE 保护器。You can centrally manage TDE protectors along with other keys, or rotate the TDE protector at your own schedule using Azure Key Vault.

  • 如果使用 Azure Key Vault 中客户管理的密钥,请参阅文章有关使用 Azure Key Vault 配置 TDE 的指导原则如何使用 Azure Key Vault 配置异地灾难恢复If you're using customer-managed keys in Azure Key Vault, follow the articles, Guidelines for configuring TDE with Azure Key Vault and How to configure Geo-DR with Azure Key Vault.

防止未经授权的高特权用户查看使用中的敏感数据Protect sensitive data in use from high-privileged, unauthorized users

使用中的数据是指在执行 SQL 查询期间存储在数据库系统内存中的数据。Data in use is the data stored in memory of the database system during the execution of SQL queries. 如果数据库存储敏感数据,则组织可能需要确保防止高特权用户查看数据库中的敏感数据。If your database stores sensitive data, your organization may be required to ensure that high-privileged users are prevented from viewing sensitive data in your database. 高特权用户(例如组织中的 Microsoft 操作员或 DBA)应该能够管理数据库,但不能通过查询数据库来查看并潜在地透露 SQL 进程内存中的敏感数据。High-privilege users, such as Microsoft operators or DBAs in your organization should be able to manage the database, but prevented from viewing and potentially exfiltrating sensitive data from the memory of the SQL process or by querying the database.

需要确定哪些数据是敏感的,以及敏感数据是否必须在内存中加密并且不可供管理员以明文形式访问,用于确定这些事项的策略特定于你的组织以及你需要遵守的合规性规定。The policies that determine which data is sensitive and whether the sensitive data must be encrypted in memory and not accessible to administrators in plaintext, are specific to your organization and compliance regulations you need to adhere to. 请参阅相关要求:识别并标记敏感数据Please see the related requirement: Identify and tag sensitive data.

如何实现How to implement:

  • 使用 Always Encrypted 来确保不会以纯文本形式公开 Azure SQL 数据库或 SQL 托管实例中的敏感数据,即使是内存中/使用中的数据。Use Always Encrypted to ensure sensitive data isn't exposed in plaintext in Azure SQL Database or SQL Managed Instance, even in memory/in use. Always Encrypted 可以防止数据库管理员 (DBA) 和云管理员(或者可以仿冒未经授权的高特权用户的恶意行动者)查看数据,并使你能够以更高的力度控制谁可以访问数据。Always Encrypted protects the data from Database Administrators (DBAs) and cloud admins (or bad actors who can impersonate high-privileged but unauthorized users) and gives you more control over who can access your data.

最佳做法Best practices:

  • Always Encrypted 不能取代静态数据加密 (TDE) 或传输中数据加密 (SSL/TLS)。Always Encrypted isn't a substitute to encrypt data at rest (TDE) or in transit (SSL/TLS). 为了尽量减轻对性能和功能的影响,请不要将 Always Encrypted 用于非敏感数据。Always Encrypted shouldn't be used for non-sensitive data to minimize performance and functionality impact. 建议将 Always Encrypted 与 TDE 和传输层安全性 (TLS) 结合使用,以全面保护静态数据、传输中的数据和使用中的数据。Using Always Encrypted in conjunction with TDE and Transport Layer Security (TLS) is recommended for comprehensive protection of data at-rest, in-transit, and in-use.

  • 在生产数据库中部署 Always Encrypted 之前,请先评估对所识别出的敏感数据列进行加密会带来的影响。Assess the impact of encrypting the identified sensitive data columns before you deploy Always Encrypted in a production database. 通常情况下,Always Encrypted 会降低对加密列的查询功能,并具有其他限制,如 Always Encrypted - 功能详细信息中所列。In general, Always Encrypted reduces the functionality of queries on encrypted columns and has other limitations, listed in Always Encrypted - Feature Details. 因此,你可能需要在客户端重构你的应用程序来重新实现查询不支持的功能,或者/并且重构你的数据库架构,包括存储过程、函数、视图和触发器的定义。Therefore, you may need to rearchitect your application to re-implement the functionality, a query does not support, on the client side or/and refactor your database schema, including the definitions of stored procedures, functions, views and triggers. 如果现有应用程序未遵守 Always Encrypted 的限制,则可能无法使用加密列。Existing applications may not work with encrypted columns if they do not adhere to the restrictions and limitations of Always Encrypted. 虽然支持 Always Encrypted 的 Microsoft 工具、产品和服务的生态系统在不断增长,但它们中还是有许多不能使用加密列。While the ecosystem of Microsoft tools, products and services supporting Always Encrypted is growing, a number of them do not work with encrypted columns. 加密列还可能会影响查询性能,具体取决于工作负荷的特征。Encrypting a column may also impact query performance, depending on the characteristics of your workload.

  • 如果使用 Always Encrypted 来防止恶意 DBA 查看数据,请通过角色分离来管理 Always Encrypted 密钥。Manage Always Encrypted keys with role separation if you're using Always Encrypted to protect data from malicious DBAs. 安全管理员可以使用角色分离来创建物理密钥。With role separation, a security admin creates the physical keys. DBA 在数据库中创建用于描述物理密钥的列主密钥和列加密密钥元数据对象。The DBA creates the column master key and column encryption key metadata objects describing the physical keys in the database. 在此过程中,安全管理员不需要访问数据库,且 DBA 不需要访问纯文本形式的物理密钥。During this process, the security admin doesn't need access to the database, and the DBA doesn't need access to the physical keys in plaintext.

  • 将列主密钥存储在 Azure Key Vault 中,以方便管理。Store your column master keys in Azure Key Vault for ease of management. 避免使用会使密钥管理变得困难的 Windows 证书存储(以及一般的分布式密钥存储解决方案,而不是集中式密钥管理解决方案)。Avoid using Windows Certificate Store (and in general, distributed key store solutions, as opposed central key management solutions) that make key management hard.

  • 仔细考虑使用多个密钥(列主密钥或列加密密钥)的利弊。Think carefully through the tradeoffs of using multiple keys (column master key or column encryption keys). 保留少量的密钥以减小密钥管理成本。Keep the number of keys small to reduce key management cost. 在稳定态的环境中(而不是在密钥轮换的中途),为每个数据库准备一个列主密钥和一个列加密密钥通常已足够。One column master key and one column encryption key per database is typically sufficient in steady-state environments (not in the middle of a key rotation). 如果有不同的用户组,而每个组使用不同的密钥并访问不同的数据,则可能需要更多的密钥。You may need additional keys if you have different user groups, each using different keys and accessing different data.

  • 根据合规要求轮换列主密钥。Rotate column master keys per your compliance requirements. 如果还需要轮换列加密密钥,请考虑使用在线加密来尽量减少应用程序停机时间。If you also need to rotate column encryption keys, consider using online encryption to minimize application downtime.

  • 如果需要支持数据计算(相等性),请使用确定性加密。Use deterministic encryption if computations (equality) on data need to be supported. 否则请使用随机加密。Otherwise, use randomized encryption. 避免将确定性加密用于低熵数据集或采用众所周知分布形式的数据集。Avoid using deterministic encryption for low-entropy data sets, or data sets with publicly known distribution.

  • 如果你担心第三方在未经你同意的情况下以合法方式访问你的数据,请确保有权访问纯文本形式的密钥和数据的所有应用程序与工具都在 Azure 云外部运行。If you're concerned about third parties accessing your data legally without your consent, ensure that all application and tools that have access to the keys and data in plaintext run outside of Azure Cloud. 如果第三方无权访问密钥,则除非绕过加密,否则他们无法解密数据。Without access to the keys, the third party will have no way of decrypting the data unless they bypass the encryption.

  • Always Encrypted 无法轻松支持授予对密钥(和受保护数据)的临时访问权限。Always Encrypted doesn't easily support granting temporary access to the keys (and the protected data). 例如,如果需要与 DBA 共享密钥,使 DBA 能够对敏感数据和加密的数据执行一些清理操作。For example, if you need to share the keys with a DBA to allow the DBA to do some cleansing operations on sensitive and encrypted data. 可靠撤销 DBA 的数据访问权限的唯一方法是,同时轮换用于保护数据的列加密密钥和列主密钥,而这是一项开销较高的操作。The only way to reliability revoke the access to the data from the DBA will be to rotate both the column encryption keys and the column master keys protecting the data, which is an expensive operation.

  • 若要访问已加密列中的纯文本值,用户需要有权访问用于保护列的列主密钥 (CMK)(在保存 CMK 的密钥存储中进行配置)。To access the plaintext values in encrypted columns, a user needs to have access to the Column Master Key (CMK) that protects columns, which is configured in the key store holding the CMK. 用户还需要拥有“查看任何列主密钥定义”和“查看任何列加密密钥定义”数据库权限。 The user also needs to have the VIEW ANY COLUMN MASTER KEY DEFINITION and VIEW ANY COLUMN ENCRYPTION KEY DEFINITION database permissions.

通过加密控制应用程序用户对敏感数据的访问Control access of application users to sensitive data through encryption

可以使用加密来确保只有有权访问加密密钥的特定应用程序用户才能查看或更新数据。Encryption can be used as a way to ensure that only specific application users who have access to cryptographic keys can view or update the data.

如何实现How to implement:

  • 使用单元级加密 (CLE)。Use Cell-level Encryption (CLE). 有关详细信息,请参阅加密数据列一文。See the article, Encrypt a Column of Data for details.
  • 使用 Always Encrypted,但要注意其限制。Use Always Encrypted, but be aware of its limitation. 下面列出了限制。The limitations are listed below.

最佳实践Best practices

使用 CLE 时:When using CLE:

  • 通过 SQL 权限和角色控制对密钥的访问。Control access to keys through SQL permissions and roles.

  • 使用 AES (推荐 AES 256) 进行数据加密。Use AES (AES 256 recommended) for data encryption. 由于存在已知漏洞,RC4、DES 和 TripleDES 等算法已遭弃用,请不要使用它们。Algorithms, such RC4, DES and TripleDES, are deprecated and shouldn't be used because of known vulnerabilities.

  • 使用非对称密钥/证书(而不是密码)来保护对称密钥,以避免使用 3DES。Protect symmetric keys with asymmetric keys/certificates (not passwords) to avoid using 3DES.

  • 通过导出/导入(bacpac 文件)使用单元级加密迁移数据库时请小心。Be careful when migrating a database using Cell-Level Encryption via export/import (bacpac files).

请记住,Always Encrypted 主要用于防止 Azure SQL 数据库的高特权用户(云操作员、DBA)查看使用中的敏感数据 - 请参阅防止防止未经授权的高特权用户查看使用中的敏感数据Keep in mind that Always Encrypted is primarily designed to protect sensitive data in use from high-privilege users of Azure SQL Database (cloud operators, DBAs) - see Protect sensitive data in use from high-privileged, unauthorized users. 使用 Always Encrypted 防止应用程序用户查看数据时,请注意以下难点:Be aware of the following challenges when using Always Encrypted to protect data from application users:

  • 默认情况下,支持 Always Encrypted 的所有 Microsoft 客户端驱动程序都会维护列加密密钥的全局缓存(每个应用程序一个缓存)。By default, all Microsoft client drivers supporting Always Encrypted maintain a global (one per application) cache of column encryption keys. 在客户端驱动程序通过联系保存列主密钥的密钥存储获取纯文本列加密密钥后,将会缓存纯文本列加密密钥。Once a client driver acquires a plaintext column encryption key by contacting a key store holding a column master key, the plaintext column encryption key is cached. 这使得将数据与多用户应用程序的用户相隔离变得困难。This makes isolating data from users of a multi-user application challenging. 如果应用程序在与密钥存储交互(例如 Azure Key Vault)时模拟最终用户,则在用户的查询使用列加密密钥填充缓存之后,需要同一个密钥但由其他用户触发的后续查询将使用缓存的密钥。If your application impersonates end users when interacting with a key store (such as Azure Key Vault), after a user's query populates the cache with a column encryption key, a subsequent query that requires the same key but is triggered by another user will use the cached key. 驱动程序不会调用密钥存储,也不会检查第二个用户是否有权访问列加密密钥。The driver won't call the key store and it won't check if the second user has a permission to access the column encryption key. 因此,即使用户无权访问密钥,也可以查看加密的数据。As a result, the user can see the encrypted data even if the user doesn't have access to the keys. 若要在多用户应用程序中实现用户隔离,可以禁用列加密密钥缓存。To achieve the isolation of users within a multi-user application, you can disable column encryption key caching. 禁用缓存会导致性能开销增大,因为驱动程序需要联系密钥存储来完成每个数据加密或解密操作。Disabling caching will cause additional performance overheads, as the driver will need to contact the key store for each data encryption or decryption operation.

在保留数据格式的同时防止应用程序用户在未经授权的情况下查看数据Protect data against unauthorized viewing by application users while preserving data format

防止未经授权的用户查看数据的另一种方法是对数据进行模糊处理或掩码,同时保留数据类型和格式,以确保用户应用程序可以继续处理和显示数据。Another technique for preventing unauthorized users from viewing data is to obfuscate or mask the data while preserving data types and formats to ensure that user applications can continue handle and display the data.

如何实现How to implement:


Always Encrypted 不能与动态数据掩码配合工作。Always Encrypted does not work with Dynamic Data Masking. 无法加密和掩码同一个列,这意味着,需确定是要优先保护使用中的数据,还是通过动态数据掩码来对应用用户掩码数据。It is not possible to encrypt and mask the same column, which implies that you need to prioritize protecting data in use vs. masking the data for your app users via Dynamic Data Masking.

最佳做法Best practices:


动态数据掩码不可用于防止高特权用户查看数据。Dynamic Data Masking cannot be used to protect data from high-privilege users. 掩码策略不适用于拥有管理访问权限的用户,例如 db_owner。Masking policies do not apply to users with administrative access like db_owner.

  • 不要允许应用用户运行临时查询(因为他们也许可以克服动态数据掩码)。Don't permit app users to run ad-hoc queries (as they may be able to work around Dynamic Data Masking).

  • 使用适当的访问控制策略(通过 SQL 权限、角色、RLS)来限制用户在掩码列中进行更新的权限。Use a proper access control policy (via SQL permissions, roles, RLS) to limit user permissions to make updates in the masked columns. 对列进行掩码不会阻止对该列进行更新。Creating a mask on a column doesn't prevent updates to that column. 如果查询掩码列时收到掩码数据的用户拥有写入权限,则他们可以更新这些数据。Users that receive masked data when querying the masked column, can update the data if they have write-permissions.

  • 动态数据掩码不会保留掩码值的统计属性。Dynamic Data Masking doesn't preserve the statistical properties of the masked values. 这可能会影响查询结果(例如,包含筛选谓词的查询或者对掩码数据的联接)。This may impact query results (for example, queries containing filtering predicates or joins on the masked data).

网络安全性Network security

网络安全性是指用于保护传输到 Azure SQL 数据库的数据的访问控制和最佳做法。Network security refers to access controls and best practices to secure your data in transit to Azure SQL Database.

配置客户端以安全连接到 SQL 数据库/SQL 托管实例Configure my client to connect securely to SQL Database/SQL Managed Instance

有关如何防范存在已知漏洞(例如,使用早期 TLS 协议和密码套件)的客户端计算机和应用程序连接到 Azure SQL 数据库和 SQL 托管实例的最佳做法。Best practices on how to prevent client machines and applications with well-known vulnerabilities (for example, using older TLS protocols and cipher suites) from connecting to Azure SQL Database and SQL Managed Instance.

如何实现How to implement:

最佳做法Best practices:

  • 配置所有应用和工具以连接到启用了加密的 SQL 数据库Configure all your apps and tools to connect to SQL Database with encryption enabled

    • Encrypt = On,TrustServerCertificate = Off(或者在非 Microsoft 驱动程序中配置相应的设置)。Encrypt = On, TrustServerCertificate = Off (or equivalent with non-Microsoft drivers).
  • 如果应用使用的驱动程序不支持 TLS 或者支持早期版本的 TLS,请尽可能地更换驱动程序。If your app uses a driver that doesn't support TLS or supports an older version of TLS, replace the driver, if possible. 如果无法做到这一点,请认真评估安全风险。If not possible, carefully evaluate the security risks.

  • 减少通过 SSL 2.0、SSL 3.0、TLS 1.0 和 TLS 1.1 中的漏洞发起的攻击途径:根据传输层安全性 (TLS) 注册表设置,在连接到 Azure SQL 数据库的客户端计算机上禁用相关的途径。Reduce attack vectors via vulnerabilities in SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 by disabling them on client machines connecting to Azure SQL Database per Transport Layer Security (TLS) registry settings.

  • 检查客户端上的密码套件:TLS/SSL (Schannel SSP) 中的密码套件Check cipher suites available on the client: Cipher Suites in TLS/SSL (Schannel SSP). 具体而言,根据配置 TLS 密码套件顺序禁用 3DES。Specifically, disable 3DES per Configuring TLS Cipher Suite Order.

  • 对于 Azure SQL 数据库和 SQL 托管实例,将对“代理”和“重定向”连接类型强制加密。For Azure SQL Database and SQL Managed Instance, encryption is enforced for both Proxy and Redirect connection types. 对于 Azure SQL 托管实例,请使用“代理”连接类型(默认设置),因为这可以强制在服务器端加密。For Azure SQL Managed Instance, use the Proxy connection type (default) as this enforces encryption from the server side. “重定向”连接类型目前不支持加密强制,仅在专用 IP 连接上可用。The Redirect connection type currently doesn't support encryption enforcement and is only available on private IP connections.

  • 有关详细信息,请参阅 Azure SQL 数据库连接体系结构 - 连接策略For more information, see Azure SQL Database Connectivity Architecture - Connection policy.

尽量减少受攻击面Minimize attack surface

尽量减少恶意用户可以攻击的特征数。Minimize the number of features that can be attacked by a malicious user. 对 Azure SQL 数据库实现网络访问控制。Implement network access controls for Azure SQL Database.

内容来源:OSA 做法 #5Mentioned in: OSA Practice #5

如何实现How to implement:

在 SQL 数据库中:In SQL Database:

  • 在服务器级别将“允许访问 Azure 服务”设置为“关闭”Set Allow Access to Azure services to OFF at the server-level
  • 使用 VNet 服务终结点和 VNet 防火墙规则。Use VNet Service endpoints and VNet Firewall Rules.
  • 使用专用链接(预览)。Use Private Link (preview).

在 SQL 托管实例中:In SQL Managed Instance:

最佳做法Best practices:

  • 通过连接到专用终结点(例如,使用专用数据路径)来限制对 Azure SQL 数据库和 SQL 托管实例的访问:Restricting access to Azure SQL Database and SQL Managed Instance by connecting on a private endpoint (for example, using a private data path):

    • 可将托管实例隔离在虚拟网络内,防止外部访问。A managed instance can be isolated inside a virtual network to prevent external access. 位于同一区域的相同或对等虚拟网络中的应用程序和工具可以直接访问它。Applications and tools that are in the same or peered virtual network in the same region could access it directly. 位于不同区域的应用程序和工具可使用虚拟网络到虚拟网络连接,或使用 ExpressRoute 线路对等互连来建立连接。Applications and tools that are in different region could use virtual-network-to-virtual-network connection or ExpressRoute circuit peering to establish connection. 客户应使用网络安全组 (NSG) 来仅限通过端口 1433 访问需要访问托管实例的资源。Customer should use Network Security Groups (NSG) to restrict access over port 1433 only to resources that require access to a managed instance.
    • 对于 SQL 数据库,请使用专用链接功能,该功能可为虚拟网络中的服务器提供专用 IP。For a SQL Database, use the Private Link feature that provides a dedicated private IP for the server inside your virtual network. 还可使用配置了虚拟网络防火墙规则的虚拟网络服务终结点来限制对服务器的访问。You can also use Virtual network service endpoints with virtual network firewall rules to restrict access to your servers.
    • 移动用户应使用点到站点 VPN 连接,通过数据路径进行连接。Mobile users should use point-to-site VPN connections to connect over the data path.
    • 连接到本地网络的用户应使用站点到站点 VPN 连接或 ExpressRoute,通过数据路径进行连接。Users connected to their on-premises network should use site-to-site VPN connection or ExpressRoute to connect over the data path.
  • 可以通过连接到公共终结点(例如,使用公共数据路径)来访问 Azure SQL 数据库和 SQL 托管实例。You can access Azure SQL Database and SQL Managed Instance by connecting to a public endpoint (for example, using a public data path). 应考虑以下最佳做法:The following best practices should be considered:


SQL 托管实例公共终结点默认未启用,必须显式启用它。The SQL Managed Instance public endpoint is not enabled by default and it and must be explicitly enabled. 如果公司政策禁止使用公共终结点,请首先使用 Azure Policy 来防止启用公共终结点。If company policy disallows the use of public endpoints, use Azure Policy to prevent enabling public endpoints in the first place.

配置 Power BI 以安全连接到 SQL 数据库/SQL 托管实例Configure Power BI for secure connections to SQL Database/SQL Managed Instance

最佳做法Best practices:

配置应用服务以安全连接到 SQL 数据库/SQL 托管实例Configure App Service for secure connections to SQL Database/SQL Managed Instance

最佳做法Best practices:

配置 Azure 虚拟机以安全连接到 SQL 数据库/SQL 托管实例Configure Azure virtual machine hosting for secure connections to SQL Database/SQL Managed Instance

最佳做法Best practices:

  • 在 Azure 虚拟机的 NSG 中结合使用“允许”和“拒绝”规则,以控制可从 VM 访问哪些区域。Use a combination of Allow and Deny rules on the NSGs of Azure virtual machines to control which regions can be accessed from the VM.

  • 确保 VM 根据 Azure 中 IaaS 工作负载的安全性最佳做法一文进行了配置。Ensure that your VM is configured per the article, Security best practices for IaaS workloads in Azure.

  • 确保所有 VM 与特定的虚拟网络和子网相关联。Ensure that all VMs are associated with a specific virtual network and subnet.

  • 根据关于强制隧道中的指导,评估是否需要默认路由。Evaluate if you need the default route per the guidance at about forced tunneling.

    • 如果需要(例如在前端子网中),请保留默认路由。If yes – for example, front-end subnet - then keep the default route.
    • 如果不需要(例如在中间层或后端子网中),请启用强制隧道,使流量不会通过 Internet 抵达本地(即跨界)。If no – for example, middle tier or back-end subnet – then enable force tunneling so no traffic goes over Internet to reach on-premises (a.k.a cross-premises).
  • 如果使用对等互连或者连接到本地,请实现可选默认路由Implement optional default routes if you're using peering or connecting to on-premises.

  • 如果需要将虚拟网络中的所有流量发送到网络虚拟设备进行数据包检查,请实现用户定义的路由Implement User Defined Routes if you need to send all traffic in the virtual network to a Network Virtual Appliance for packet inspection.

  • 使用虚拟网络服务终结点通过 Azure 主干网络安全访问 Azure 存储等 PaaS 服务。Use virtual network service endpoints for secure access to PaaS services like Azure Storage via the Azure backbone network.

监视、日志记录和审核Monitoring, Logging, and Auditing

本部分所述的功能可帮助你检测异常活动,这些活动指示非同寻常或者潜在有害的访问或恶意利用数据库的企图。This section refers to capabilities to help you detect anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. 本部分还将提供有关配置数据库审核来跟踪和捕获数据库事件的最佳做法。It also describes best practices to configure database auditing to track and capture database events.

防范数据库遭到攻击Protect databases against attacks

高级威胁防护可在发生异常活动时提供安全警报,让我们检测潜在威胁并做出响应。Advanced threat protection enables you to detect and respond to potential threats as they occur by providing security alerts on anomalous activities.

如何实现How to implement:

  • 使用适用于 SQL 的高级威胁防护来检测非同寻常或者潜在有害的访问或恶意利用数据库的企图,包括:Use Advanced Threat Protection for SQL to detect unusual and potentially harmful attempts to access or exploit databases, including:
    • SQL 注入攻击。SQL injection attack.
    • 凭据盗窃/泄露。Credentials theft/leak.
    • 特权滥用。Privilege abuse.
    • 数据透露。Data exfiltration.

最佳做法Best practices:

  • 为特定服务器或托管实例配置 Azure Defender for SQL 。Configure Azure Defender for SQL for a specific server or a managed instance. 还可以通过切换到 Azure 安全中心标准层,为订阅中的所有服务器和托管实例配置 Azure Defender for SQL。You can also configure Azure Defender for SQL for all servers and managed instances in a subscription by switching to Azure Security Center Standard tier.

  • 若要获得完整的调查体验,建议启用  SQL 数据库审核For a full investigation experience, it's recommended to enable SQL Database Auditing. 使用审核可以跟踪数据库事件,并将这些事件写入到 Azure 存储帐户或 Azure Log Analytics 工作区中的审核日志。With auditing, you can track database events and write them to an audit log in an Azure Storage account or Azure Log Analytics workspace.

审核关键安全事件Audit critical security events

跟踪数据库事件有助于了解数据库活动。Tracking of database events helps you understand database activity. 可以洞察可能指示业务关注点或可疑安全违规的差异与异常。You can gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations. 此措施还有助于遵守法规标准。It also enables and facilitates adherence to compliance standards.

如何实现How to implement:

  • 启用  SQL 数据库审核托管实例审核以跟踪数据库事件,并将这些事件写入到 Azure 存储帐户、Log Analytics 工作区(预览版)或事件中心(预览版)中的审核日志。Enable SQL Database Auditing or Managed Instance Auditing to track database events and write them to an audit log in your Azure Storage account, Log Analytics workspace (preview), or Event Hubs (preview).

  • 可将审核日志写入 Azure 存储帐户、写入 Log Analytics 工作区(供 Azure Monitor 日志使用),或写入事件中心(供事件中心使用)。Audit logs can be written to an Azure Storage account, to a Log Analytics workspace for consumption by Azure Monitor logs, or to event hub for consumption using event hub. 可以将这些选项随意组合起来进行配置,审核日志会写入到每一个之中。You can configure any combination of these options, and audit logs will be written to each.

最佳做法Best practices:

  • 在服务器上配置 SQL 数据库审核或配置托管实例审核以审核事件后,该服务器上所有现有的和新建的数据库都会被审核。By configuring SQL Database Auditing on your server or Managed Instance Auditing to audit events, all existing and newly created databases on that server will be audited.
  • 审核策略默认包括对数据库执行的所有操作(查询、存储过程,以及成功和失败的登录),这可能会导致生成大量的审核日志。By default auditing policy includes all actions (queries, stored procedures and successful and failed logins) against the databases, which may result in high volume of audit logs. 建议客户使用 PowerShell 对不同类型的操作和操作组配置审核It's recommended for customers to configure auditing for different types of actions and action groups using PowerShell. 此项配置有助于控制审核的操作数量,并将事件丢失的风险降到最低。Configuring this will help control the number of audited actions, and minimize the risk of event loss. 自定义审核配置可让客户仅捕获所需的审核数据。Custom audit configurations allow customers to capture only the audit data that is needed.
  • 可以在 Azure 门户中直接使用审核日志,或者从配置的存储位置使用。Audit logs can be consumed directly in the Azure portal, or from the storage location that was configured.


启用在 Log Analytics 中进行审核会根据引入速率产生成本。Enabling auditing to Log Analytics will incur cost based on ingestion rates. 请注意,使用此选项会产生相关的成本;或者,可以考虑将审核日志存储在 Azure 存储帐户中。Please be aware of the associated cost with using this option, or consider storing the audit logs in an Azure storage account.

其他资源Further resources:

保护审核日志Secure audit logs

限制对存储帐户的访问,以支持职责分离,并将 DBA 与审核员区分开来。Restrict access to the storage account to support Separation of Duties and to separate DBA from Auditors.

如何实现How to implement:

  • 将审核日志保存到 Azure 存储时,请确保按照最低安全原则来限制对存储帐户的访问。When saving Audit logs to Azure Storage, make sure that access to the Storage Account is restricted to the minimal security principles. 控制谁有权访问存储帐户。Control who has access to the storage account.
  • 有关详细信息,请参阅授权访问 Azure 存储For more information, see Authorizing access to Azure Storage.

最佳做法Best practices:

安全管理Security Management

本部分介绍有关管理数据库安全态势的各个方面和最佳做法。This section describes the different aspects and best practices for managing your databases security posture. 其中提供了有关确保根据安全标准配置数据库、发现漏洞,以及分类和跟踪对数据库中潜在敏感数据的访问的最佳做法。It includes best practices for ensuring your databases are configured to meet security standards, for discovering and for classifying and tracking access to potentially sensitive data in your databases.

确保根据安全最佳做法配置数据库Ensure that the databases are configured to meet security best practices

通过发现并修正潜在数据库漏洞来主动改善数据库的安全性。Proactively improve your database security by discovering and remediating potential database vulnerabilities.

如何实现How to implement:

  • 启用 SQL 漏洞评估 (VA) 来扫描数据库的安全问题,并使其定期对数据库自动运行。Enable SQL Vulnerability Assessment (VA) to scan your database for security issues, and to automatically run periodically on your databases.

最佳做法Best practices:

  • 对数据库运行首次 VA,在补救不符合安全最佳做法的失败检查后反复运行 VA。Initially, run VA on your databases and iterate by remediating failing checks that oppose security best practices. 设置可接受配置的基线,直到扫描结果全部正常,或所有检查均已通过。Set up baselines for acceptable configurations until the scan comes out clean, or all checks has passed.

  • 将定期的重复扫描配置为每周运行一次,并配置相关人员来接收摘要电子邮件。Configure periodic recurring scans to run once a week and configure the relevant person to receive summary emails.

  • 完成每周扫描后查看 VA 摘要。Review the VA summary following each weekly scan. 对于发现的任何漏洞,评估与前一次扫描结果的偏差,并确定是否应解决本次检查发现的问题。For any vulnerabilities found, evaluate the drift from the previous scan result and determine if the check should be resolved. 查看配置发生更改是否有合理的原因。Review if there's a legitimate reason for the change in configuration.

  • 解决检查发现的问题并更新相关的基线。Resolve checks and update baselines where relevant. 为解决措施创建票证项,并在解决问题之前跟踪这些项。Create ticket items for resolving actions and track these until they're resolved.

其他资源Further resources:

识别并标记敏感数据Identify and tag sensitive data

发现可能包含敏感数据的列。Discover columns that potentially contain sensitive data. 什么数据是敏感数据在很大程度上取决于客户、合规性规定等,并且需要由负责该数据的用户进行评估。What is considered sensitive data heavily depends on the customer, compliance regulation, etc., and needs to be evaluated by the users in charge of that data. 将列分类以使用基于敏感性的高级审核和保护方案。Classify the columns to use advanced sensitivity-based auditing and protection scenarios.

如何实现How to implement:

  • 使用 SQL 数据发现和分类来发现、分类、标记和保护数据库中的敏感数据。Use SQL Data Discovery and Classification to discover, classify, label, and protect the sensitive data in your databases.
    • 在 SQL 数据发现和分类仪表板中查看自动发现创建的分类建议。View the classification recommendations that are created by the automated discovery in the SQL Data Discovery and Classification dashboard. 接受相关的分类,以使用分类标签来持久标记敏感数据。Accept the relevant classifications, such that your sensitive data is persistently tagged with classification labels.
    • 对于未被自动机制发现的任何其他敏感数据字段,请手动添加分类。Manually add classifications for any additional sensitive data fields that were not discovered by the automated mechanism.
  • 有关详细信息,请参与 SQL 数据发现和分类For more information, see SQL Data Discovery and Classification.

最佳做法Best practices:

  • 定期监视分类仪表板,以准确评估数据库的分类状态。Monitor the classification dashboard on a regular basis for an accurate assessment of the database's classification state. 可以导出或打印有关数据库分类状态的报告,以使在合规与审核措施中共享。A report on the database classification state can be exported or printed to share for compliance and auditing purposes.

  • 持续监视 SQL 漏洞评估中建议的敏感数据的状态。Continuously monitor the status of recommended sensitive data in SQL Vulnerability Assessment. 跟踪敏感数据发现规则,识别建议列中的任何分类偏差。Track the sensitive data discovery rule and identify any drift in the recommended columns for classification.

跟踪对敏感数据的访问Track access to sensitive data

在审核日志中监视谁访问了敏感数据,并捕获对敏感数据运行的查询。Monitor who accesses sensitive data and capture queries on sensitive data in audit logs.

如何实现How to implement:

最佳做法Best practices:

可视化安全性与合规性状态Visualize security and compliance status

使用统一的基础结构安全管理系统来增强数据中心(包括 SQL 数据库中的数据库)的安全态势。Use a unified infrastructure security management system that strengthens the security posture of your data centers (including databases in SQL Database). 查看有关数据库安全性与合规性状态的建议列表。View a list of recommendations concerning the security of your databases and compliance status.

如何实现How to implement:

常见安全威胁和潜在缓解措施Common security threats and potential mitigations

本部分帮助你找到用于防范特定攻击途径的安全措施。This section helps you find security measures to protect against certain attack vectors. 遵循上述一条或多条安全指导原则预期可以实现大部分缓解措施。It's expected that most mitigations can be achieved by following one or more of the security guidelines above.

安全威胁:数据透露Security threat: Data exfiltration

Data 透露是指在未经授权的情况下,从计算机或服务器复制、传输或检索数据。Data exfiltration is the unauthorized copying, transfer, or retrieval of data from a computer or server. 查看维基百科中的数据透露定义。See a definition for data exfiltration on Wikipedia.

通过公共终结点连接到服务器会带来数据透露的风险,因为这需要客户向公共 IP 打开其防火墙。Connecting to server over a public endpoint presents a data exfiltration risk as it requires customers open their firewalls to public IPs.

场景 1:Azure VM 上的某个应用程序连接到 Azure SQL 数据库中的某个数据库。Scenario 1: An application on an Azure VM connects to a database in Azure SQL Database. 恶意行动者获取 VM 的访问权限并入侵到其中。A rogue actor gets access to the VM and compromises it. 在此场景中,数据透露表示使用恶意 VM 的外部实体连接到数据库,复制个人数据,并将这些数据存储在 Blob 存储中或者不同订阅内的不同 SQL 数据库中。In this scenario, data exfiltration means that an external entity using the rogue VM connects to the database, copies personal data, and stores it in a blob storage or a different SQL Database in a different subscription.

场景 2:恶意 DBA。Scenario 2: A Rouge DBA. 这种场景通常出现在受管制行业的安全敏感型客户那里。This scenario is often raised by security sensitive customers from regulated industries. 在此场景中,高特权用户可将 Azure SQL 数据库中的数据复制到不受数据所有者控制的其他订阅。In this scenario, a high privilege user might copy data from Azure SQL Database to another subscription not controlled by the data owner.

潜在缓解措施Potential mitigations:

Azure SQL 数据库和 SQL 托管实例目前提供以下技术来缓解数据透露威胁:Today, Azure SQL Database and SQL Managed Instance offers the following techniques for mitigating data exfiltration threats:

  • 在 Azure VM 的 NSG 中结合使用“允许”和“拒绝”规则,以控制可从 VM 访问哪些区域。Use a combination of Allow and Deny rules on the NSGs of Azure VMs to control which regions can be accessed from the VM.
  • 如果在 SQL 数据库中使用服务器,请设置以下选项:If using a server in SQL Database, set the following options:
    • 将“允许 Azure 服务”设置为“关闭”。Allow Azure Services to OFF.
    • 设置 VNet 防火墙规则,仅允许来自包含你的 Azure VM 的子网的流量。Only allow traffic from the subnet containing your Azure VM by setting up a VNet Firewall rule.
  • 对于 SQL 托管实例,使用专用 IP 访问默认可以解决恶意 VM 的首要数据透露隐患。For SQL Managed Instance, using private IP access by default addresses the first data exfiltration concern of a rogue VM. 在子网中启用子网委托功能,以在 SQL 托管实例子网中自动设置最严格的策略。Turn on the subnet delegation feature on a subnet to automatically set the most restrictive policy on a SQL Managed Instance subnet.
  • 恶意 DBA 隐患主要出现在 SQL 托管实例上,因为 SQL 托管实例的受攻击面较大,而网络要求对客户是可见的。The Rogue DBA concern is more exposed with SQL Managed Instance as it has a larger surface area and networking requirements are visible to customers. 此问题的最佳缓解措施是首先应用本安全指南中的所有做法,以防止出现恶意 DBA 的情景(不仅可以解决数据透露)。The best mitigation for this is applying all of the practices in this security guide to prevent the Rogue DBA scenario in the first place (not only for data exfiltration). Always Encrypted 是保护敏感数据的一种方法,它可以加密敏感数据,并使 DBA 无法访问密钥。Always Encrypted is one method to protect sensitive data by encrypting it and keeping the key inaccessible for the DBA.

业务连续性和可用性的安全性方面Security aspects of business continuity and availability

大多数安全标准在操作连续性方面解决数据可用性问题,实现此效果的方式是实施冗余和故障转移功能来避免单一故障点。Most security standards address data availability in terms of operational continuity, achieved by implementing redundancy and fail-over capabilities to avoid single points of failure. 对于灾难恢复方案,常见的做法是保留数据和日志文件的备份。For disaster scenarios, it's a common practice to keep backups of Data and Log files. 以下部分概述了 Azure 中内置的功能。 The following section provides a high-level overview of the capabilities that are built-into Azure. 此外,提供了可根据具体需求进行配置的其他选项:It also provides additional options that can be configured to meet specific needs:

后续步骤Next steps