SQL Server 2016 - Always Encrypted
2.71/5 (3投票s)
SQL Server 2016 - 安全功能 - Always Encrypted
背景
数据库安全是任何应用程序最重要的方面之一。传统上，数据的安全性和访问权限一直通过应用程序接口限制给最终用户，即应用程序内置逻辑来验证最终用户并提供数据访问权限。
但存储在服务器上的数据库内容传统上可被IT管理员、开发人员和数据库管理员等访问。SQL Server或任何数据库都可以通过用户和角色管理来限制对数据库的访问，并记录数据库操作。但一旦授予用户访问权限，表的内容等就可以被任何有权访问数据库的人访问。这也包括访问所有敏感和非敏感数据。
以下是一些已实现的数据库安全方法：
数据库用户/角色管理——通过创建数据库用户并限制用户执行的操作来限制数据库访问。此外，还可以监控所有任务的日志。
透明数据加密 (TDE)——也称为静态加密（Encryption at Rest）。顾名思义，这种方法有助于保护物理介质（数据库文件、备份文件等）免遭盗窃或被未经授权的人复制。TDE对数据库和日志文件执行实时加密/解密。存储在数据库物理文件中的数据被加密后存储。因此，未经授权的个人将无法恢复数据库，除非他们拥有密钥/证书。
SQL Server 2016 - 新的数据库安全功能
随着SQL Server 2016的发布，微软引入了两项新的数据库安全功能，即：
- 始终加密
- 动态数据屏蔽
始终加密
Always Encrypted 是新引入的一项功能，用于保护敏感数据在静态（物理存储在数据库表中）和传输中（从数据库服务器到应用程序）的安全。Always Encrypted 允许加密特定列的值。
在给定的表中，大部分数据可能是非敏感的或公众已知的，如名字、姓氏等。但给定表中的某些信息，如社会安全号码 (SSN)、薪水和出生日期等，是非常敏感的数据。Always Encrypted 允许应用程序加密列并将其存储在数据库中。因此，即使IT管理员、SQL管理员或开发人员有权访问数据库，他们也无法以其原始形式查看内容，因为它已被加密。
Always Encryption 如何工作？
定义加密列
在定义数据库表结构时，我们通过指定加密算法和加密密钥来定义加密列。
数据库引擎不存储加密密钥。
访问数据库和表
- 要访问加密列的值，应用程序需要通过Always Encrypted数据库驱动程序（ADO.NET）访问数据库，并指定解密密钥。
- 加密列无法在数据库端解密。
- 这限制了DB管理员查看列值。他们可以查询数据库，但由于值已被加密，因此是安全的。
Always Encryption 的好处
客户端数据加密——数据仅在客户端进行加密和解密，从而有助于防止DBA、IT管理员或任何有权访问数据库的人查看敏感数据。
Always Encryptions 的局限性
- 无法对加密列执行范围类操作
- 不能使用大于/小于运算符
- 不能使用模式匹配的“LIKE”操作符
- 对列进行索引的限制
- 目前仅 .NET 4.6 支持 Always Encryption，因此需要迁移到 .NET 4.6。
迁移到 Always Encryption
- 数据库端
- 需要创建一个新的独立数据库，其中包含加密列的定义和主密钥创建。
- 数据迁移
- 需要将整个数据库从现有数据库（非加密数据库）迁移到新的 Always Encrypted 数据库。
- 修改应用程序以使用 .NET 4.6 ADO 进行数据加密
- 修改现有应用程序流程和逻辑，使用 Always Encrypted 的数据库驱动程序。
- 修改存储加密列值的存储过程，并进行必要的更改。
结论
总而言之，Always Encrypted 是 SQL Server 在加密和存储服务器上的数据并保护敏感信息免遭IT团队、DBA、数据库用户侵害方面迈出的重要一步。在某种程度上，业务用户现在可以确信数据不会泄露，也不会被不应该查看它的人看到。
但从开发人员或开发团队的角度来看，测试和验证数据在数据库层面是否正确存储可能会很困难。目前，开发人员可以轻松地查看存储的数据并确认存储的值。随着 Always Encrypted 的实施，我们将无法从前端查看数据。
一旦项目开始利用这项功能，我们肯定会知道开发团队和业务用户的接受程度。在那之前，拭目以待……看看这个新功能将如何被开发界所接受……
研究参考和鸣谢
历史
- 2016年8月20日：初始版本