微软SQL Server透明数据TDE加密及破解分析（下）

一般的数据加密

大家都认为加密是好事，但是没有考虑特定的攻击场景，这种想法已经成为了一种趋势，但是加密的确是必要的，并且非常能说明问题。

举个例子，下面是一些常见的攻击场景和细节展示TDE如何在这些情况下进行帮助。为了便于比较，下面我们会描述每个场景下基于加密保护的应用。

我们可以看到，在实践中TDE并不能为多数真实世界中的攻击场景提供帮助，但是也不比其他方式的安全性差。

我应该安装TDE吗？

TDE的弱点不能简单说是bug或者微软的错误，这个问题更加基本，并且在SQL Server中非比寻常。任何其他的数据库都必须规避相同的逻辑。这是人们只苛求功能，但不理解他们想要什么的结果。微软知道TDE并不安全，你甚至可以从微软文档的语言中看出这一点。它的目的是满足政治压力而不是解决实际安全问题。

人们还缺乏理解，这种理解延续并贯穿管理最佳实践。人们想要静态加密、还想要自动boot和传统数据库系统，但是不想更改应用程序。结果就是系统变得不那么安全。但是人们还是为自己的安全列表打勾了。

TDE并没有为你提供任何增强安全性的功能：

1、性能降低

根据你的架构和使用模式，性能会降低2%到12%

https://www.databasejournal.com/features/mssql/article.php/3815501/Performance-Testing-SQL-2008146s-Transparent-Data-Encryption.htm

但是，这种写入数据很重、有大规模数据需要扫描到的系统遭受的影响会达到15%甚至更多。

重负载下的系统也可能会降低非线性。

2、不可压缩备份

由于加密发生在备份压缩前，加密的数据是不能被压缩的，备份数据会非常大。这样造成了直接的影响。传统的备份系统是在加密前压缩的，就可以避免这个问题。

3、安全的错觉

有些情况下，TDE是无效的。除非非常小心，采取措施避免让用户暴露敏感信息，这些敏感信息应该使用更佳直接的安全方法来保护。

TDE几乎没有任何好处。鉴于它的缺点这么多，多是情况下它并不能成为有实际作用的非常好的安全方法。

但是另一方面，使用TDE还存在争议：“使用了总比没使用好。”不，事实并不是这样的，因为它会：

1）让你的系统跑起来更慢，且消耗更多的资源。其他的传统安全实践面对同样的威胁更有效并且对系统性能没有影响。

2）“还有一个特殊层呢。”这层根本没用，并且有明显的缺点。它会增加系统成本且没有合理依据增加这层。

3）“静态加密数据是当前的最佳实践且很多产业中需要PCI等安全承诺。”这是一种政策而不是论证。并且，TDE不只是一种静态加密方法，他的问题太多了，而其他的方法问题都比较少。

“假设一个攻击者拥有了管理权限，那就意味着假设不合理。我妈想要保护低等级的攻击。”低权限的用户不能拿到你的数据库。攻击者一旦拿到管理员权限，全盘皆输是没错的。但是还有很多可怕的事情。管理员用户可以完全绕过TDE随时访问SQL Server。

我们只展示能够访问文件就足够了，但是不代表这里没有其他漏洞。对于任何合理配置的SQL服务器而言，除SQL用户和本地管理员之外的Windows用户甚至应该不存在。文件权限也是如此：用户不应该拥有权限读取SQL数据文件，即使不小心访问了服务区也不可以。SQL数据文件对普通用户来说通常是不可读读，因为这些数据在使用时被锁住了。

唯一能够真实读取数据库文件对用户应该是服务器的管理员，他们可以读取所有文件。但是还很重要的一点是，在一些情况下，备份文件的位置，如硬盘、服务器被偷，或者攻击者因为某些原因获得了存储器的访问权限，数据还是会被读取。

所以，我们是否应该安装TDE呢？答案可能是，不使用！只有你被强迫使用TDE时才能只用。如果你不用就会丢掉工作，那你用吧。

做最坏的准备（无论如何，使用TDE）

如果你不管它的缺点，因为政策压力必须安装TDE：

1、确保数据库备份与系统备份物理隔离或者最好使用其他的备份软件加密工具进行独立的加密备份（没有TDE面临的问题的工具）。这样有点违背TDE的目的，但是至少避免暴露自己。

2、为减轻性能损失或为密钥存储使用硬件支持（见下文），但是这样做会导致成本显著增加并且安全性帮助不大。

3、了解这些情况是不会有帮助的，利用其他策略来解决问题。它们能有效的使TDE变的多余，但是至少保证安全。

硬件支持

令人费解的是，SQL服务器似乎并不支持Intel AES－NI加速，而AED－NI会大幅减少性能的影响。

还有乳Thales，Townsend和SafeNet公司会提供应急哪安全模型（HSMs），而这些模型能与SQL Server兼容。这样做的好处是硬件加速加密和密钥保护。

如果你*使用TDE，那么硬件加速会是非常棒的选择。它会显著降低性能影响。

安全性是值得怀疑的。我试图得到一些信息，但很不幸没有得到回复。但使用硬件模型有一个基本的问题即应用层一体化（应用层位于OS的低层）。

HSM存储加密密钥、保证所有的加密都不在主内存中且不通过CPU。如果没有审计，我妈就没有方法知道对于攻击者来说从这些设备中恢复密钥有多难。但是更重要的是，没有什么能够阻止攻击者要求设备进行解密。一个攻击者可以发送一个完全有效的请求个给HSM要求其解密一个数据库块，然后进一步解密整个数据库。

你可能会说，HSM应该只接受来自SQL server的请求。虽然目前并不清楚HSM是否这么做了，但是任何情况下，为了做到这点，SQL服务器需要向HSM进行验证。在某些涉及一个迷药的时候，它也需要位置进行存储，我们在这点上进展缓慢。

使用HSM的一个好处是它防止SQL服务器在你的硬盘上存储密钥。这就意味着密钥不会在你的备份中。但是在实践中没有任何好处，因为传统的备份加密解决同样的问题是不需要使用任何硬件或者开销的（如前面所提，保证备份足够小）。

因此HSM是你在*使用TDE时合理的加速选择，但是别骗自己，它真的不会对安全性有所提高。

如果不使用TDE，那我们还能怎么做呢？

基于静态数据加密的应用（列级）是TDE的代替品。它能够避免一些缺陷，但是需要应用开发者的支持并且可能对于现存系统来说非常昂贵。

大家应该对服务器的访问和文件权限非常关注。未经授权的用户应该被完全禁止访问数据库文件。拥有权限的用户能够解密并读取加密的数据，所以不要过多纠缠这一点。唯一一件你几乎能做的事情就是保证未经授权的用户无法触及文件并阻止用户升级权限。添加TDE真的不会有任何帮助，因为即使没有权限的用户已经没法获得数据了，授权的用户可以读取文件。

备份应该使用独立的加密系统进行加密并整合进备份系统。

你的权限和其他访问控制应该被自动并频繁的审核，这样如果发生了一偶然的变化，它可以通过之前的利用立即修复。