halite/document vs mysql aes\u加密:安全性/性能

jaql4c8m  于 2021-06-21  发布在  Mysql
关注(0)|答案(1)|浏览(316)

我有一个web应用程序(symfony4),它需要符合hipaa标准,这意味着我需要加密数据。最初我只是打算通过halite在php中加密数据并将其保存在数据库中,但是有些字段(姓、名、电话号码)我无法加密,因为它们将用于搜索字段,因此我需要(?)mysql能够使用where子句。
所以我打算用 AES_ENCRYPT 并将mysql连接设置为通过本地端口转发隧道通过ssh,这样连接将是安全的,没有人能够获得密码短语。
尽管如此,我还是不断看到文章 AES_ENCRYPT 这是个坏主意,应该用php来保护这些东西。如果我这样做了,我需要把所有的记录都取下来,解密,然后用php搜索-当然没有mysql能做的那么快(?)。此表可能有数千个条目。
对此有什么建议吗?我是不是想得太多了?如果我通过ssh进行连接,那么通过mysql进行连接会有什么风险?
网上有太多的建议,很难知道什么是对的!

uelo1irk

uelo1irk1#

如果您愿意使用精确的查找,那么可以在没有性能开销的情况下实现对加密字段的查找。您肯定应该在php代码中实现加密逻辑。
如果您当前有自己的table,请说:

(id, first_name, last_name, email)

我们首先为要加密的字段添加额外的列,这样我们的表就变成

(id, first_name, first_name_lu, last_name, last_name_lu, email)

更新或插入行时,我们会做两件事:
使用第一个对称密钥,我们加密所需的字段。这个结果放在原始列中。
使用第二个对称密钥,我们hmac了所需字段。这个结果在 *_lu 列。
当我们要执行查找时,我们:
使用第二个对称密钥,hmac执行搜索查询,然后查找 *_lu 基于结果的列。
如果找到匹配项,则原始列中的加密值就是我们搜索的值。
你可能想知道为什么hmac是必要的,为什么我们不能重新加密和比较呢?我们可以这样做,但这也意味着我们必须使用ecb模式进行加密,这是一个很大的安全漏洞。应改用gcm或cbc。这就是hmac的必要性。

相关问题