关于数据库的安全性，或者说关于安全性的缺失问题时常见诸报端。几乎每个月都不只一次看到关于大企业或政府机构由于数据库安全性问题而捅出大娄 子的报道。这些问题中的一部分是可以通过加密与散列技术得到缓解的，但由于这一过程很乏味，因此开发者通常只会对最敏感的数据应用这种技术，例如密码等 等。
SQL Server 2016将通过新的 全程加密 （Always Encrypted）特性让加密工作变得更简单，这项特性提供了某种方式，以确保在数据库中不会看到敏感列中的未加密值，并且无需对应用进行重写。为了维持合理的性能，非敏感的列 —— 例如主键列仍将保持未加密。
实际的数据加密与解密过程是由数据库driver这一层处理的，数据库本身只能看到加密后的值，而应用程序代码仅仅是与未加密的数据打交道。在 执行某个查询时，driver会自动在Windows Certificate Store（或其它取决于操作系统中的位置）中查找主密钥。该主密钥将用于将对应于某一列的密钥进行解密，随后再用解密后的密钥对字段及参数进行加密与解 密。
微软给出了使用全程加密的三种场景。
SQL Server提供了两种加密模式：确定型加密与随机型加密。确定型加密能够确保对某个值加密后的结果是始终相同的，这就允许使用者对该数据列进行等值比较、连接及分组操作。
确定型加密的缺点在于，它“允许未授权的用户通过对加密列的模式进行分析，从而猜测加密值的相关信息”。在取值范围较小的情况下，这一点会体现得尤为明显。
为了提高安全性，应当使用随机型加密。就像 对密码进行salt 操作一样，它能够保证某个给定值在任意两次加密后的结果总是不同的，从而杜绝了猜出原值的可能性。微软进一步说明道：
如果某个列被加密，那么所有的范围型操作都会被禁止，例如大于/小于或使用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