SQL Server 中加密数据须知
类别: MSSQL教程 
日前，有多条新闻提到了有人可以从外部访问数据库――通常是应该受到保护的商业解决方案――发现数据库中的敏感信息，例如用户姓名、密码、信用卡号或者地址都是以明文存储的，这种事情已经太多了。因此，大多数人创建数据库驱动的解决方案的第一条设计决策就是如何加密存储数据，以便于保证它的安全，免受窥探。
SQL Server 中有哪一种支持可以用于加密对象和数据?从一开始就讨论一下SQL Server 欠缺什么是明智的，或者是对于SQL Server中的加密部分你不应该做什么。
首先，SQL Server有两个内置的密码函数――即，pwdencrypt() 和 pwdcompare()。同时，还有两个SQL Server用来管理密码哈希的没有正式记录的函数:pwdencrypt() 将密码哈希过后进行存储;pwdcompare()将提供的字符串与哈希后的字符串进行比较。不幸的是，这个哈希函数不是非常安全，它可以通过字典攻击算法被破解(类似命令行应用程序!)。
这些函数随着SQL Server的版本发展而不断进行修改，这也是另一个没有使用它们的原因。早期版本的SQL Server对密码进行的哈希，在后来的版本中无法解密，所以如果你依赖一个版本中的函数，那么当升级的时候，所有你的加密数据就都没有用了，除非你可以首先对其解密――这也就违背了加密的最初的目的。
第二，你可能会尝试去创建一个针对你的数据库的自制的加密解决方案，但是有以下三个理由说明你不要这样做:
除非你是加密专家，否则胡乱编写的加密系统只会提供非常低级的价值不高的保护。新鲜的是，单向密码哈希或者\"ROTx\"形式的加密几乎不需要费事就可以被轻松打败。
如果由于你自己的能力的缺乏而导致加密被破解，那么你的数据就完蛋了。你需要将所有的东西进行没有加密的备份，是吗?(即使你加密了，那里有没有安全漏洞?)
当市面上提供有专业级别的，具有工业强度的加密解决方案的时候，你就不值得花费时间去自己做。把你的时间用于构建一个好的，坚固的数据库，而不是再重新发明一次车轮。
那么，什么才是好的加密数据的方式呢?
对于新手，微软提供了一个自己生成的加密解决方案，CryptoAPI 。对于轻量级的加密，军用级别的安全就不在考虑范围之内，它具有相对容易实现的优势:管理员可以安装一个名为CAPICOM 的ActiveX 控制，它可以在T-SQL存储过程中提供CryptoAPI 功能。CAPICOM 支持各种类型的双向加密和单向哈希算法，所以管理员可以挑选最适合应用程序的问题的部分。
如果你对使用微软的解决方案不感兴趣，还有一些很好的第三方的方案可以使用。一家名为ActiveCrypt 的软件有限责任公司制造了XP_CRYPT ，它是SQL Server的插件，可以在视图、程序和触发器中通过扩展存储过程和用户自定义函数(在SQL Server 2000中)来完成加密。你可以下载一个支持无线的MD5,DES ，以及SHA1哈希的免费版本的应用程序;其他的加密模型就是在比特深度上进行的。(完全版本是无限的。)在你自己的代码中，你可以使用XP_CRYPT，与ActiveX 控制一样(在受限的免费版本中)。对于ASP程序员来说，一个名为AspEncrypt 的组件提供了一种将高级加密整合到你的代码中的简单方式。
对数据库文件自身进行加密或者提供传输层上的安全保护怎么样?对于前者，你可以在Windows系统中持续使用加密文件系统。然而，你必须保存加密密钥的备份，在出现问题的时候，这个数据有可能会丢失。对于后者，有IPSec和SQL Server自己的SSL加密，都是SQL Server和Windows自带的。你主要精力应该放在避免以明文存储敏感数据，因为从数据库中抽取没有加密的数据也是最容易受到攻击的地方。
SQL Server 中有哪一种支持可以用于加密对象和数据?从一开始就讨论一下SQL Server 欠缺什么是明智的，或者是对于SQL Server中的加密部分你不应该做什么。
首先，SQL Server有两个内置的密码函数――即，pwdencrypt() 和 pwdcompare()。同时，还有两个SQL Server用来管理密码哈希的没有正式记录的函数:pwdencrypt() 将密码哈希过后进行存储;pwdcompare()将提供的字符串与哈希后的字符串进行比较。不幸的是，这个哈希函数不是非常安全，它可以通过字典攻击算法被破解(类似命令行应用程序!)。
这些函数随着SQL Server的版本发展而不断进行修改，这也是另一个没有使用它们的原因。早期版本的SQL Server对密码进行的哈希，在后来的版本中无法解密，所以如果你依赖一个版本中的函数，那么当升级的时候，所有你的加密数据就都没有用了，除非你可以首先对其解密――这也就违背了加密的最初的目的。
第二，你可能会尝试去创建一个针对你的数据库的自制的加密解决方案，但是有以下三个理由说明你不要这样做:
除非你是加密专家，否则胡乱编写的加密系统只会提供非常低级的价值不高的保护。新鲜的是，单向密码哈希或者\"ROTx\"形式的加密几乎不需要费事就可以被轻松打败。
如果由于你自己的能力的缺乏而导致加密被破解，那么你的数据就完蛋了。你需要将所有的东西进行没有加密的备份，是吗?(即使你加密了，那里有没有安全漏洞?)
当市面上提供有专业级别的，具有工业强度的加密解决方案的时候，你就不值得花费时间去自己做。把你的时间用于构建一个好的，坚固的数据库，而不是再重新发明一次车轮。
那么，什么才是好的加密数据的方式呢?
对于新手，微软提供了一个自己生成的加密解决方案，CryptoAPI 。对于轻量级的加密，军用级别的安全就不在考虑范围之内，它具有相对容易实现的优势:管理员可以安装一个名为CAPICOM 的ActiveX 控制，它可以在T-SQL存储过程中提供CryptoAPI 功能。CAPICOM 支持各种类型的双向加密和单向哈希算法，所以管理员可以挑选最适合应用程序的问题的部分。
如果你对使用微软的解决方案不感兴趣，还有一些很好的第三方的方案可以使用。一家名为ActiveCrypt 的软件有限责任公司制造了XP_CRYPT ，它是SQL Server的插件，可以在视图、程序和触发器中通过扩展存储过程和用户自定义函数(在SQL Server 2000中)来完成加密。你可以下载一个支持无线的MD5,DES ，以及SHA1哈希的免费版本的应用程序;其他的加密模型就是在比特深度上进行的。(完全版本是无限的。)在你自己的代码中，你可以使用XP_CRYPT，与ActiveX 控制一样(在受限的免费版本中)。对于ASP程序员来说，一个名为AspEncrypt 的组件提供了一种将高级加密整合到你的代码中的简单方式。
对数据库文件自身进行加密或者提供传输层上的安全保护怎么样?对于前者，你可以在Windows系统中持续使用加密文件系统。然而，你必须保存加密密钥的备份，在出现问题的时候，这个数据有可能会丢失。对于后者，有IPSec和SQL Server自己的SSL加密，都是SQL Server和Windows自带的。你主要精力应该放在避免以明文存储敏感数据，因为从数据库中抽取没有加密的数据也是最容易受到攻击的地方。
- 上一篇: SQL SERVER备份和恢复措施
- 下一篇: 如何快速建立数据字典
