WHERE 子句中的 SQL 加密列

发布于 2024-09-16 00:27:03 字数 492 浏览 9 评论 0原文

我希望使用对称密钥应用 SQL 列级加密。创建数据库主密钥、证书和对称密钥所需的初始步骤似乎很简单,我已经成功测试了使用对称密钥加密/解密数据。

然而,一旦数据被加密,我不知道如何最好地查询它。例如

SELECT PlainTextA, PlainTextB, PlainTextC 
WHERE CONVERT(varchar, DECRYPTBYKEY(EncyptedColumn)) = @SearchTerm

肯定会导致全表扫描?

我认为可能有效的另一个选择是首先对搜索条件进行加密,

SELECT PlainTextA, PlainTextB, PlainTextC 
WHERE EncyptedColumn = ENCRYPTBYKEY(KEY_GUID('KeyName'), @SearchTerm)

但这不起作用,因为生成的加密值总是不同的。

任何建议将不胜感激。

I am looking to apply SQL column level encryption using symmetric keys. The initial steps needed to create the Database Master Key, Certificates and Symmetric Keys seems straight forward and I have tested encrypting/decrypting data using Symmetric Keys successfully.

However, once the data is encrypted I don't know how best to query it. E.g.

SELECT PlainTextA, PlainTextB, PlainTextC 
WHERE CONVERT(varchar, DECRYPTBYKEY(EncyptedColumn)) = @SearchTerm

would surely result in a full table scan?

Another option I thought might work is encrypting the search criteria first e.g.

SELECT PlainTextA, PlainTextB, PlainTextC 
WHERE EncyptedColumn = ENCRYPTBYKEY(KEY_GUID('KeyName'), @SearchTerm)

but this doesn't work as the encrypted value generated is always different.

Any suggestions would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

打小就很酷 2024-09-23 00:27:03

典型的方法是存储加密值和该值的单向哈希值。当您寻找特定值时,您会寻找哈希值。通过这种方式,您可以高效地查询,而不必解密每一行来找到您感兴趣的值:

create table Table (
EncryptedColumn varbinary(max),
HashValue binary(20),
PlainA int,
PlainB varchar(256),
PlainC Datetime);

create index ndxTableHash on Table(HashValue);

select PlainA, plainB, PlainC
from table
where HashValue = HashBytes('SHA1', @searchTerm);

理论上,您可能会遇到一次哈希冲突,偏执狂安全您对解密列添加双重检查:

select PlainA, plainB, PlainC
from table
where HashValue = HashBytes('SHA1', @searchTerm)
and DecryptByKey(..., EncryptedColumn) = @searchTerm;

另请参阅 对加密数据建立索引SQL Server 2005 :搜索加密数据

The typical way is to store both the encrypted value and a one-way hash of the value. When you seek a specific value, you would seek the hash. This way you can query efficiently, w/o having to decrypt every row in order to find the value you're interested:

create table Table (
EncryptedColumn varbinary(max),
HashValue binary(20),
PlainA int,
PlainB varchar(256),
PlainC Datetime);

create index ndxTableHash on Table(HashValue);

select PlainA, plainB, PlainC
from table
where HashValue = HashBytes('SHA1', @searchTerm);

In theory, you can have a hash conflict once in a blue moon, to be paranoid-safe you add a double check on the decrypted column:

select PlainA, plainB, PlainC
from table
where HashValue = HashBytes('SHA1', @searchTerm)
and DecryptByKey(..., EncryptedColumn) = @searchTerm;

Also see Indexing encrypted data and SQL Server 2005: searching encrypted data.

余生一个溪 2024-09-23 00:27:03

您可以选择的一种选择是向表中添加一列(或者使用一个包含计算列的 WITH SCHEMABINDING 视图,并为其建立索引),并使用搜索值的单向哈希值。它不必是强哈希 - 像 CHECKSUM 这样简单的东西就可以工作。然后,您对查找中的搜索值进行散列,并通过已索引的散列对其进行过滤。这样,您就可以公开可搜索和可索引的内容,而无需实际公开值本身。

但是,如果有另一种方法可以直接执行此操作,我很想知道它是什么:)

One option you have is add a new column to the table (or have a WITH SCHEMABINDING view with a calculated column in it, and index that) with a one-way HASH of the search value. It doens't have to be a strong hash - something as simple as CHECKSUM will work. Then you hash the search value in your lookup and filter it by the hash, which is indexed. That way, you can expose something searchable and indexable, without actually exposing the value itself.

However, if there's another way to do this directly, I'd love to know what it is :)

路弥 2024-09-23 00:27:03

另一种选择是使用包含解密值列的视图并根据它查找记录。

SELECT PlainTextA, PlainTextB, PlainTextC from TheView 
WHERE DecryptedColumn = @SearchTerm

Another option is to use a View which contains a column of decrypted value and find records according to it.

SELECT PlainTextA, PlainTextB, PlainTextC from TheView 
WHERE DecryptedColumn = @SearchTerm
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文