SQL Server 加密详解：TDE、列级加密及更多

数据保护对于确保您的组织符合诸如 GDPR 之类的监管合规标准，并满足客户和业务合作伙伴的期望至关重要。 数据泄露 不仅可能导致巨额罚款，声誉方面的损失同样可能非常严重。为此，Microsoft SQL Server 提供 5 种不同的加密方式来保护数据。本文将解释其中每一种，并说明应在何处使用。

SSL 传输加密

就像用于保护浏览器与服务器之间通信的安全网站一样，SQL Server 也可以配置为使用安全套接字层（Secure Sockets Layer，SSL），以加密服务器实例与客户端应用程序之间传输的通信。此外，客户端还可以使用服务器证书来验证服务器身份。SSL 仅在数据通过网络传输时提供保护，但与大多数其他 SQL Server 加密形式不同的是，SSL 在所有受支持版本的 SQL Server 以及所有版本中都可用。

在启用 SSL 之前，您需要在 SQL Server 上安装证书。最好的做法是从您自己的企业证书颁发机构（CA）请求证书。Windows Server 可以配置为 CA，并且您可以设置客户端，让它们信任该 CA 颁发的证书。或者，也可以使用自签名证书，不过自签名证书更适用于测试环境。

SQL Server 透明数据加密（TDE）

SQL Server 中的 Transparent Data Encryption (TDE) 通过对磁盘上的数据库数据和日志文件进行加密来保护静态数据。它对客户端现有应用程序是透明的，因此在启用 TDE 时无需更改应用程序。TDE 在页级别使用实时加密：在页面写入磁盘之前先进行加密，不会增加数据和日志文件的大小；当页面读取到内存中时再进行解密。TDE 仅在 SQL Server 的企业版中提供。它也适用于 Azure SQL Database、Azure SQL Data Warehouse 和 Parallel Data Warehouse。

TDE 加密具有分层结构：Windows Data Protection API (DPAPI) 位于层级的最上方，用于加密服务主密钥（service master key，SMK）。你可以使用 SMK 来加密凭据、链接服务器密码以及位于不同数据库中的数据库主密钥（database master keys，DMK）。SQL DMK 是一种对称密钥，用于保护存储在数据库中的证书私钥和非对称密钥。

SQL Server 可以为 TDE 生成自签名证书，または CA（更常见的做法）から证书を要求することもできます。若要启用 TDE，必须备份与该证书关联的证书及其私钥。需要在另一台 SQL Server 上进行数据库还原或挂载（attach）。如果在其他任何 SQL Server 数据库上启用 TDE，则 tempdb 系统数据库也会被加密。如果禁用 TDE，应保留证书和私钥，因为在你执行完整备份之前，事务日志的部分内容可能会保持加密状态。

TDE 还需要一个数据库加密密钥（database encryption key，DEK）。该密钥可以是受主数据库中存储的证书保护的对称密钥，也可以是由使用可扩展密钥管理（Extensible Key Management，EKM）的服务（例如 Microsoft Azure Key Vault）保护的非对称密钥。启用 TDE 的数据库的备份文件会使用 DEK 进行加密，因此在执行还原操作时，必须提供用于保护 DEK 的证书。

对称密钥使用相同的口令来加密和解密数据。非对称密钥使用一个口令来加密数据（公钥），并使用另一个口令来解密数据（私钥）。你可以使用 CREATE CERTIFICATE 命令来创建证书，并使用 CREATE SYMMETRIC KEY 和 CREATE ASYMMETRIC KEY 的 Transact-SQL 命令来创建数据库加密密钥。

备份加密

备份加密的工作方式类似于 TDE，但它会加密 SQL 备份，而不是加密当前数据和日志文件。备份加密在 SQL Server 2014 及更高版本中可用。你可以指定 AES 128、AES 192、AES 256 或 Triple DES 加密，并使用存储在 EKM 中的证书或非对称密钥。除此之外，还可以同时启用 TDE 和备份加密，不过应使用不同的证书或密钥。

与 TDE 一样，如果启用备份加密，你还必须备份证书或密钥。没有密钥或证书，备份文件就无法用于还原数据。使用 SQL Server 托管备份到 Microsoft Azure 时，备份也可以加密。

需要注意的是：如果你使用证书来加密备份，在还原数据时必须拥有原始证书。这意味着证书的指纹（thumbprint）必须与创建备份时的指纹相同。更新证书或以任何方式更改证书，都可能导致指纹发生变化。

列/单元格级加密

在 SQL Server 的所有版本中都可用，可在包含敏感数据的列上启用按单元格级别加密。数据会在磁盘上被加密，并在使用 DECRYPTBYKEY 函数对其进行解密之前一直保持在内存中的加密状态。因此，尽管 SQL 数据已加密，但仅仅通过在用户上下文中使用某个函数来解密并不足以提供超出该范围的安全性。此外，由于需要函数来解密数据，必须修改客户端应用程序以配合单元格级别加密。

加密密钥管理

与 TDE 类似，在使用单元格级别加密之前，需要先创建主密钥（DMK）。使用单元格级别加密对信息进行加密有四种选项：

• 您可以使用口令（passphrase）对数据进行加密和解密，但必须加密存储过程和函数；否则，口令可能会在元数据中被访问。
• 非对称密钥提供较强的安全性，但可能会对性能产生影响。
• 对称密钥通常足够强，能够在安全性和性能之间取得良好的平衡。
• 证书同样能在安全性和性能之间提供良好的平衡，并且可以与数据库用户关联。

Always Encrypted

Always Encrypted 会在客户端应用程序中加密敏感数据，而不会向数据库引擎公开加密密钥，从而在数据所有者和数据管理者之间实现分离。例如，启用 Always Encrypted 后，你可以确保数据库管理员无法读取敏感数据。顾名思义，数据会在静态时加密；如果在第三方系统（例如 Azure）中使用，也同样保持加密。

Always Encrypted 可以为各个数据库列进行配置。使用两种类型的密钥：列加密密钥和列主密钥。列加密密钥用于保护列中的数据，而列主密钥是“密钥保护密钥”，用于加密一个或多个列加密密钥。列主密钥存储在外部可信的密钥存储区中，例如 Azure Key Vault。

加密过程对客户端应用程序是透明的，但需要在客户端计算机上安装专用驱动程序。Always Encrypted 在 SQL Server 2016 及更高版本中可用，但仅限 Enterprise 版本。由于存在额外的客户端侧要求，Always Encrypted 最适合于数据所有者与管理者必须分离这一点是首要需求的场景。