blocks|key|284072|text|获取要搜索的属性并通过单向散列(MD5，SHA1)运行它们，将结果存储为单独的列，并对这些列进行索引。然后，当您需要查询值时，通过相同的散列运行输入(未加密)值并搜索散列值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|284073|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Take the attributes you want to search on and run them through a 1-way hash (MD5, SHA1), store the results as individual columns and index those columns. Then when you need to query a value, run the input (unencrypted) value through the same hash and search for the hashed value.

blocks|key|3204216|text|您的场景中的主要问题是加密和索引/搜索的可用性是相互矛盾的参数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204217|这里有一个人为的但简单的问题例子:假设我们在商业电子邮件中寻找“儿童色情”。数据库是加密的，一切都很好。但是，如果在搜索“儿童色情”时发现John给Bill的电子邮件包含这两个词，那么实际内容就不再重要了-儿童色情不应该在电子邮件中讨论。|3204218|因此，如果数据库与索引一起泄漏，对词集的智能分析可以揭示大量信息。例如，发现软件供应商公司50%25的公司邮件中包含"+webos“一词可以揭示一个可能的秘密事实，即该公司正在开发用于webos的软件。|3204219|现在您看到了，这种加密在您的情况下用处有限。更强的数据库整体安全性可能比加密更重要。|3204220|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The main problem in your scenario is that encryption and availability for indexing / search are contradictory parameters. 

Here's the artificial but simple example of the problem: 
Imagine we are looking for "child porn" in business e-mail. The DB is encrypted, everything is fine. But if the search reveals that the e-mail from John to Bill contains both of these words by finding this e-mail when searching for "child porn", then the actual contents don't matter anymore - child porn should not be discussed in e-mail at all. 

So if the DB leaks together with indexes, smart analysis of the word set can reveal plenty of information. For example finding that 50% of corporate mail of software vendor company includes "webos" term can reveal the [possibly secret] fact, that the company works on software for webos. 

Now you see, that encryption has limited usefulness in your case. Stronger overall security of the DB might be more important than encryption.

blocks|key|282085|text|存储加密的blobs，但创建单独的索引表，这些索引表使用加密关系绑定到blobs。例如，下表可以存储您的blob：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|282086|blob(ID,SHA(secret-seed,data))|code-block|syntax|javascript|282087|并且索引可以像这样与blob相关：|282088|word(SHA(secret-seed,blob-ID),value)|282089|现在，当您查询某个blob时，您会这样做：|282090|select+blob+join+word+on+SHA(secret-seed,ID)+=+word-ID+where+query+IN+value|282091|您甚至可以对键和实际的blob数据使用不同的种子。|282092|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Store the encrypted blobs but create separate indexing tables that are tied to the blobs using encrypted relations. For example, the following table could store your blobs:

<pre><code>blob(ID,SHA(secret-seed,data))
</code></pre>

and the indexes could be related to the blob as such:

<pre><code>word(SHA(secret-seed,blob-ID),value)
</code></pre>

Now when you query for some blob you do:

<pre><code>select blob join word on SHA(secret-seed,ID) = word-ID where query IN value
</code></pre>

You could even use different seeds for the keys and actual blob data.

blocks|key|3204254|text|事实是，如果您加密数据，您将不会从索引中受益。你需要接受这个事实。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204255|如果需要索引，则通过删除对DBA帐户上这些列的权限来保护数据。只有应用程序帐户才能查询这些列。安全性在于有限的访问，而不是加密。|3204256|你必须接受权衡。我希望有人能给我一个神奇的答案，证明我错了！|3204257|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The reality is you will not benefit from indexes if you encrypt the data. You need to accept this.

If an index is needed, then protect the data by removing permissions to those columns on the DBA accounts. Only the application account will be able to query these columns. The security is in the limited access rather than encryption. 

You have to accept trade-offs. I hope someone comes in with a wiz bang answer that proves me wrong!

blocks|key|3204324|text|我目前正在寻找解决这个问题的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204325|我发现的最好的想法之一，是来自https://docs.microsoft.com/en-us/archive/blogs/raulga/indexing-encrypted-data的这篇文章。|offset|length|3204326|他建议使用MAC来创建一个可索引的列。该解决方案适用于MS+SQL+Server，但也可以应用于其他系统。|3204327|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/archive/blogs/raulga/indexing-encrypted-data|1|http://en.wikipedia.org/wiki/Message_authentication_code^0|0|F|25|0|0|5|3|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

I'm currently looking for a solution to this same problem. 

One of the best ideas I've found, is this article from Raul García, <a href="https://docs.microsoft.com/en-us/archive/blogs/raulga/indexing-encrypted-data" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/archive/blogs/raulga/indexing-encrypted-data</a>. 

He suggests using a <a href="http://en.wikipedia.org/wiki/Message_authentication_code" rel="nofollow noreferrer">MAC</a>, to create an indexable column. The solution is for MS SQL Server, but it could be applied to another system.

blocks|key|3204332|text|有些数据库确实支持加密索引。我认识的那个人(自从我在公司工作以来)就是UniVerse。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204333|查看安全手册(1)“自动数据加密”部分。也许它会给你一些想法。|3204334|(1)：http://docs.rocketsoftware.com，搜索"UniVerse安全功能“|offset|length|3204335|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.rocketsoftware.com/^0|0|0|4|U|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

There are databases that do support encrypted indexes. The one I know (since I worked for the company) is UniVerse.

Check out the security manual(1) 'Automatic Data Encryption' section. Perhaps it will give you some ideas.

(1): <a href="http://docs.rocketsoftware.com" rel="nofollow">http://docs.rocketsoftware.com</a>, search for "UniVerse Security Features"

blocks|key|284170|text|您需要使用一类新的加密算法，称为格式保留加密(搜索Wiki)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|284171|我会明智地随意使用这样的算法，因为它们对文献来说是相对较新的，并且这是一个经验法则，在您可以将算法用于严肃的目的之前，您需要等待算法经过(比方说)十年的加密分析。我也不确定这种加密格式是否有任何标准。只有2010年提交的标准草案。http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffx/ffx-spec.pdf|offset|length|284172|因此，请考虑明智地使用它。对于需要超过(比方说)5年的保密跨度的信息，不要依赖格式保留加密。|284173|entityMap|0|LINK|mutability|MUTABLE|url|http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffx/ffx-spec.pdf^0|0|37|2B|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

You need to use a new class of encryption algorithms called Format Preserving Encryption (search Wiki). 

I would be judicious in using such algorithms off-hand simply for the reason that they are relatively new to the literature and it is a thumb rule that you wait for an algorithm to be crypt-analyzed for (say) a decade before you can use it for serious purposes. I am also not sure if there are any standards for such encryption formats. There is only a draft for standard that was submitted in 2010. <a href="http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffx/ffx-spec.pdf" rel="nofollow">http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffx/ffx-spec.pdf</a> 

So, consider using it judiciously. Do not rely on format-preserving encryption for information that needs a secrecy span of more than (say) 5 years.

blocks|key|278684|text|更新：您将希望查看CipherSweet，而不是滚动自己的设计。它负责大量的subtle+security+details，并且有一个straightforward+security+argument。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|278685|278686|散列函数不是这里的解决方案。正如公认的答案所暗示的那样，indexing+encrypted+data需要一个“盲目索引”，由MAC促成。|278687|假设你在加密社保号码。当您将它们插入到数据库中时，您可能会执行如下操作：|278688|$ssn_encrypted+=+\Defuse\Crypto\Crypto::encrypt($ssn,+$our_encryption_key);
$ssn_blind_idx+=+\hash_hmac('sha512',+$ssn,+$our_search_key);|code-block|syntax|javascript|278689|然后将这两个值存储在数据库中。当您需要根据SSN输入快速获取一个值时，您可以重新计算HMAC并基于此进行搜索。|278690|数据库永远不会看到SSN，并且您的加密密钥永远不应该签入到源代码控制(SVN、git等)中。|278691|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/paragonie/ciphersweet/|1|https://ciphersweet.paragonie.com/internals|2|https://ciphersweet.paragonie.com/security|3|https://paragonie.com/white-paper/2015-secure-php-data-encryption#index-encrypted-information^0|0|2|9|B|0|12|N|1|1V|X|2|0|0|S|N|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@$9|1A|A|1B|1|1C]|$9|1D|A|1E|1|1F]|$9|1G|A|1H|1|1I]]|E|$]]|$1|F|3|-4|5|6|7|1J|8|@]|D|@]|E|$]]|$1|G|3|H|5|6|7|1K|8|@]|D|@$9|1L|A|1M|1|1N]]|E|$]]|$1|I|3|J|5|6|7|1O|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|1P|8|@]|D|@]|E|$N|O]]|$1|P|3|Q|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1R|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1S|8|@]|D|@]|E|$]]]|U|$V|$5|W|X|Y|E|$Z|10]]|11|$5|W|X|Y|E|$Z|12]]|13|$5|W|X|Y|E|$Z|14]]|15|$5|W|X|Y|E|$Z|16]]]]

Update: You'll want to check out <a href="https://github.com/paragonie/ciphersweet/" rel="nofollow noreferrer">CipherSweet</a> instead of rolling your own design. It takes care of a lot of <a href="https://ciphersweet.paragonie.com/internals" rel="nofollow noreferrer">subtle security details</a> and has a <a href="https://ciphersweet.paragonie.com/security" rel="nofollow noreferrer">straightforward security argument</a>.

<hr>

Hash functions aren't the solution here. As the accepted answer suggests, <a href="https://paragonie.com/white-paper/2015-secure-php-data-encryption#index-encrypted-information" rel="nofollow noreferrer">indexing encrypted data</a> requires a "blind index", facilitated by a MAC.

Let's say you're encrypting social security numbers. When you insert them into the database, you might do something like this:

<pre><code>$ssn_encrypted = \Defuse\Crypto\Crypto::encrypt($ssn, $our_encryption_key);
$ssn_blind_idx = \hash_hmac('sha512', $ssn, $our_search_key);
</code></pre>

And then store both values in the database. When you need to quickly grab a value based on an SSN input, you can recalculate the HMAC and search based on that.

The database never sees the SSN, and your encryption keys should never be checked into source control (SVN, git, etc.).

I'm building an application that needs to store sensitive information, which means the data is encrypted on my database so that a hacker/employee with access to the database cannot decipher the sensitive data. However, it still needs to be searchable (on a certain level).

I understand certain compromises may have to be made. For example, I'm willing to leave some data attributes unencrypted to make them indexable if necessary, but "the main body" must be encrypted. 

What are some best practices and approaches for storing sensitive data that needs to be viewable, searchable, and/or sortable by authorized people?

(I was thinking of extracting non <a href="http://en.wikipedia.org/wiki/Stop_words">stop words</a> from the "body" and putting them in random order in a field before encrypting the body, and then feed that field to a search indexer, I doubt it provides any real security.)

What's the best way to store and yet still index encrypted customer data?

数据加密

SQL Server

数据库

我正在构建一个需要存储敏感信息的应用程序，这意味着我的数据库中的数据是加密的，因此有权访问数据库的黑客/员工无法破译敏感数据。但是，它仍然需要是可搜索的(在一定程度上)。我理解可能需要做出某些妥协。例如，如果有必要，我愿意保留一些未加密的数据属性以使它们可索引，但是“主体”必须是加密的。对于存储需要由授权人员查看、搜索...

问在存储加密的客户数据的同时，最好的方法是什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在存储加密的客户数据的同时，最好的方法是什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在存储加密的客户数据的同时，最好的方法是什么？
EN