目标

我想将加密数据存储在数据库中。

约束

应用程序级加密（在发送到数据库之前加密）对于我的用例来说不是一个合理的选择。
我正在考虑的数据库提供商不允许我以我将支付的价格创建多个用户/管理权限。这意味着分离日志与读取和写入的权限不是一种选择。

选项

允许 MySQLaes_encrypt/decrypt为我处理 AES 加密（通过）（我知道 ECB 块问题以及如果未正确配置 MySQL 以纯文本形式记录敏感数据的事实）
使用提供静态加密的数据库提供程序（透明发生的那种——自动加密SET和解密SELECT）

问题

问题 1

为什么我会选择这种类型的静态加密aes_encrypt呢？（作为说明，我没有存储信用卡信息或其他任何会鼓励我合法地进行静态加密的东西）。

据我了解，加密数据库中的数据的目的是面对发生数据库泄露的现实。考虑到这一点，如果有人可以访问我的数据库（意味着他们可以执行查询），这种类型的静态加密不会真正帮助他们，因为它只会在他们解密数据时简单地解密数据SELECT吗？在我看来，它在不增加安全性的情况下减慢了查询速度。

aes_decrypt另一方面，它要求入侵者可以访问存储在不同凭据后面的不同机器上的密钥。那不是更安全吗？

问题2

在我在问题 1 中描述的场景中，攻击者获得了对数据库的查询访问权限。如果是这种情况，难道他们也不能只启用日志记录并检索纯文本 AES 密钥，从而aes_encrypt也变得无用吗？

（请记住此处的第 2 个约束条件。）

问题 3

SELECT排除 sql 注入，是否存在其他情况，攻击者可以在不执行 a并因此不触发透明的静态解密的情况下查看我的数据库中的内容？

建议？

如果您有任何适合我的限制的建议，请告诉我。谢谢！

1个回答

透明与手动加密

透明加密可以更容易、更安全，因为提供者负责密钥管理。对他们来说，这只是另一个操作职责，还有备份、监控和复制等等。

搞砸密钥管理非常容易——从挑选坏密钥到丢失它们到暴露它们到未能正确旋转它们——就像很容易搞砸其他操作活动一样。与备份一样，如果密钥丢失，则数据也会丢失。人们想花时间解决哪些问题？

在攻击场景方面，有很多需要考虑——攻击者可以被动地监控应用程序和数据库之间的网络流量；能够从应用程序或数据库文件系统中读取数据；可以访问物理磁盘；可以访问帐户凭据；可以在应用程序中运行 webshell。在大多数情况下，透明加密和手动加密同样容易受到攻击。

攻击者当然有可能访问数据库凭据，但不能访问应用程序，因此在手动加密情况下，他们可能需要克服一些额外的障碍。但是进行手动加密的人必须做很多正确的事情，并且能够访问加密数据的坚定攻击者有很多潜在的前进路径。据报道，数据已被加密或散列但随后被暴露的数据泄露数量不可计数。
查询访问和查询记录

对数据库的查询访问与管理访问不同，后者通常是启用日志记录所必需的。但是，当专门讨论提供者产品时，查询访问凭据可能也可用于从提供者配置某些控制面板，这可能允许启用某种查询日志记录。

但是退后一步——在一般情况下，攻击者实现对数据库的访问，尤其是写访问的影响不会因数据是否加密而改变。从勒索软件攻击中获取页面，他们可以运行自己的“UPDATE $table SET $encrypted_column = aes_encrypt(encrypted_column, 'attacker-key');” 并要求受害者的解密密钥，或者只是金钱，来归还加密数据的保管权。
访问 sql 注入或查询引擎之外的数据

如上所述，在许多情况下，攻击者可能无需通过查询引擎即可查看数据库中的内容。有人可能在网络上有可见性。有人可能会看到数据库正在使用的数据文件。有人可能会在物理磁盘停止服务时访问它们。有人可能能够进行备份。所有这些事情每天都在发生。

建议：没有对静态加密的要求以及必须防御并需要特殊处理或考虑的特定场景，只需让提供商运行即可。

其它你可能感兴趣的问题

上一篇启动顺序内的 Android 验证启动下一篇检查打印机是否保留打印文档的历史记录