SQL Server 2016：全程加密

关于数据库的安全性，或者说关于安全性的缺失问题时常见诸报端。几乎每个月都不只一次看到关于大企业或政府机构由于数据库安全性问题而捅出大娄子的报道。这些问题中的一部分是可以通过加密与散列技术得到缓解的，但由于这一过程很乏味，因此开发者通常只会对最敏感的数据应用这种技术，例如密码等等。

SQL Server 2016 将通过新的全程加密（Always Encrypted）特性让加密工作变得更简单，这项特性提供了某种方式，以确保在数据库中不会看到敏感列中的未加密值，并且无需对应用进行重写。为了维持合理的性能，非敏感的列 —— 例如主键列仍将保持未加密。

实际的数据加密与解密过程是由数据库 driver 这一层处理的，数据库本身只能看到加密后的值，而应用程序代码仅仅是与未加密的数据打交道。在执行某个查询时，driver 会自动在 Windows Certificate Store（或其它取决于操作系统中的位置）中查找主密钥。该主密钥将用于将对应于某一列的密钥进行解密，随后再用解密后的密钥对字段及参数进行加密与解密。

场景

微软给出了使用全程加密的三种场景。

本地客户端与数据

某客户的客户端应用与 SQL Server 都运行于本地的自有企业场所，他打算雇用一位外部人士进行 SQL Server 的管理。为了保护 SQL Server 中所存储的机密数据，该客户应用了全程加密这一特性，以确保数据库管理员与应用程序管理员的职责分离。客户将全程加密的密钥以明文值的方式存储在某个可信的密钥存储系统中，这个系统是客户端应用程序能够访问的，而 SQL Server 的管理员无法访问这些密钥，因此也无法解密存储在 SQL Server 中的机密数据。

本地客户端与 Azure**** 平台中的数据

某客户的客户端应用运行在本地的自有企业场所中，该应用需要操作运行于 Azure 平台上的某个数据库（例如在 Microsoft Azure 的虚拟机中运行的 SQL Server 实例）中的机密数据。客户利用了全程加密特性，将全程加密的密钥存储在一个可信的本地存储系统中，以保证微软云管理员无法访问机密数据。

客户端与数据都运行在 Azure**** 平台

某客户的客户端应用运行在 Microsoft Azure 平台上（例如某个在 worker role 或 web role 中运行），它需要操作同样存储在 Microsoft Azure 平台上的机密数据。客户利用全程加密特性以减少遭受安全攻击的表面面积（机密数据在数据库与运行该数据库的机器中都保持全程加密）。

加密类型

SQL Server 提供了两种加密模式：确定型加密与随机型加密。确定型加密能够确保对某个值加密后的结果是始终相同的，这就允许使用者对该数据列进行等值比较、连接及分组操作。

确定型加密的缺点在于，它“允许未授权的用户通过对加密列的模式进行分析，从而猜测加密值的相关信息”。在取值范围较小的情况下，这一点会体现得尤为明显。

为了提高安全性，应当使用随机型加密。就像对密码进行 salt 操作一样，它能够保证某个给定值在任意两次加密后的结果总是不同的，从而杜绝了猜出原值的可能性。微软进一步说明道：

对于会被当作搜索或分组参数的列应使用确定型加密，例如某个行政机构的 ID 值。而对于诸如机密研究的注解等数据应使用随机型加密，这种数据不会用于与其它记录进行分组，也不会用于表的连接。

通用的限制

如果某个列被加密，那么所有的范围型操作都会被禁止，例如大于 / 小于或使用 LIKE 进行模式匹配等等。此外，你无法将加密的值传递给用户自定义函数或其它函数，因为数据库无法访问未加密的值。

只有使用确定型加密的列才能够进行等值比较。

只有使用确定型加密的列才能够应用索引。

如果要对两个列进行连接操作，那么这两个列必须使用相同的列加密密钥。

对应加密列的常量表达式是不允许的，打个比方，不可以编写 WHERE SSN = '111-11-1111’这样的语句，但可以写成 WHERE SSN = @SSN。这是因为 SQL Server 驱动需要与 SqlParameter 类配合，才能够处理加密方面的需求。

不支持加密的数据类型包括：xml、rowversion、image、ntext、text、sql_variant、hierarchyid、geography、geometry 以及用户自定义类型。

截至目前，.NET 4.6 是唯一一个支持该特性的 SQL Server driver。

查看英文原文： SQL Server 2016: Always Encrypted