如果您接触了SQL Server 2008，那就可能知道其新的加密功能：透明数据加密(TDE)。第一眼看上去TDE给人的感觉就像是数据库加密的圣杯 – 所有人都在期待的加密解决方案。

　　虽然说没有一种单独的安全控制机制可以保护好一切，但是TDE的诞生已经是近乎完美了。

　　采用透明数据加密，整个数据库(MDFs，tempdb，等等)对磁盘的读取和写入都作了解密/加密的处理，而不需要重写应用程序或生成自定义的加密和解密的代码。在许多情况下，开发人员没有利用数据库加密特性来修改应用程序的选择，，因此TDE有可能会开辟一个全新的领域。

　　透明数据加密的另外一个优点是，由于数据库已经被加密过了，因此数据库备份也就自动的被加密了。在风险缓解方面，这也是一种优势。但是，这种方式会增加对存储空间的需求，因为对加密数据的压缩还不能够达到理想的程度。如果把数据提供给在线备份的访问接口，可能会遇到额外的打击。虽然这不是一个大问题，但也需要做一些考虑。

　　在SQL Server 2008中另外一个不错的增强功能是可扩展的密钥管理;它将使您能够使用已存在的第三方密钥管理应用程序去帮助SQL Server在企业级进行适当配置。

　　在这一层面上处理安全问题，系统发生故障时就会引入数据恢复的风险。而且，SQL Server 2008存储数据库加密密钥(DEK)在系统的引导记录里面，可以使用该数据库服务主密钥或硬件安全模块(HSM)如智能卡或USB存储设备进行后续恢复。

　　所以，我们是否应该把目光放到去利用SQL Server 2008这些新功能的优势上和那些已被采用的、先进的数据库加密技术上呢?这当然是值得考虑的——尤其是对于那些小部门，他们进行升级和推出新方案的负担较小。但不要冒失地选择SQL Server的加密。这是常识 – 连微软也承认 – SQL Server 2008数据库加密会给服务器增加很多处理开销。不幸的是，我认为正是这个事情让很多DBA在加密的道路上走了很多弯路，甚至让我们停滞不前。不过，如果你用了正确的方式，这将不会有什么问题;所以要提前做好计划和功课。

　　我认为，我们已经把数据库加密的野马打倒在地。业务所面对的威胁，应该说已经提供了充足的理由去加密你们在业务上最为珍视的财富。火上浇油的行为在国家法律上是不被允许的，在这方面加密数据却被常常的赦免。这些法律的内在和它的本身应该作为一个巨大的动力去加密那些让人感觉合情合理的地方。

　　SQL Server 2008的数据库加密技术虽然不是传说中的万灵丹，但是当其它的防护措施都失效的时候，它却提供了一个强壮的保护层。 它是真正值得考虑的，现在还不去做，还要等到什么时候呢?