SQL Server 2008 列加密答案

【问题标题】：SQL Server 2008 Column EncryptionSQL Server 2008 列加密
【发布时间】：2011-06-05 09:53:41
【问题描述】：

我一直在尝试找出一种加密数据库中敏感列的好方法。我认为 SQL Server 的内置加密机制可以解决问题，但要么我遗漏了什么，要么做错了。

最初的计划是创建一个表，其中包含使用对称密钥加密的列，并让视图从未加密的表中选择数据。但是，我无法弄清楚如何在视图选择语句中使用 DecryptByKey 方法。另外，我突然想到，数据在视图中往返都是未加密的，所以除非连接是安全的，否则它将毫无意义。

然后我想把所有的加密/解密都带到我的应用程序中。我想到了

因此，我的应用程序为需要加密的每一列都“硬编码”了 IV 和密钥。它将加密信息发送到数据库，并从数据库接收加密信息。这只是为了打扰您，我知道我必须将 IV 和密钥放在其他地方……它们在应用程序代码中根本不安全。

我在想这个疯狂的想法：

客户端应用程序将包含一个密钥和 IV。服务器将在单个表中包含所有加密列的密钥/IV。但是，密钥/IV 的值将使用客户端应用程序持有的密钥/IV 进行加密。

在启动时，客户端应用程序会将所有密钥/IV 从数据库加载到内存中，并根据需要对其进行解密以查看从服务器中选择的数据。

也可能存在一种关系，该关系将用户与他们被允许使用的密钥连接起来。因此，该应用只会解密用户有权查看的列。

你认为这个想法是胜利还是失败？在给定客户端应用程序/SQL Server 场景的情况下，你们中的一些人是如何实现加密的？

【问题讨论】：

【解决方案1】：

你松了。观点。没有机会使用索引等。

如果您想要安全，请将其放在安全的服务器上并加载企业版并使用数据库文件加密。

【讨论】：

真的会这样吗？该计划是加密敏感的“仅数据”列，例如社会安全号码、电话号码、信用卡号码等。我通常不会索引的列。
那么好吧，你只会让处理数据变得很痛苦。喜欢报道。最好的是恕我直言，仍然在应用程序级别处理安全性，通过具有 TPM 的服务器和提供的机制（即磁盘加密选项）来处理数据安全。

【解决方案2】：

考虑放置一个中间层来为您处理加密/解密。假设您可以将它放在服务器上，您可以保持对位的控制，而不必担心客户端应用程序（可能有点超出您的控制）被反编译（并暴露密钥）。

【讨论】：