mysql - 静态加密和/或 AES_ENCRYPT

Question

我正在尝试提高包含敏感数据的 MySQL 数据库的安全性。我正在努力掌握一些术语。有人可以让我知道我是否正确理解了情况:

静态加密 - 似乎我可以在表级别启用此功能。表中的所有数据都使用 key 加密。如果有人掌握了备份文件或获得了对服务器的物理访问权限，那么数据将受到保护。当然，这假设 key 存储在其他地方。

AES_ENCRYPT - 在我的表中插入/更新数据时，我可以使用 AES_ENCRYPT('data', 'password') .通过 SELECT 查询数据时，我使用 AES_DECRYPT

假设我只是在休息时使用加密，那么我是否需要在我的 PHP 代码中做任何不同的事情来查询数据？我的 PHP 代码是否需要通过我的 PDO 请求将 key 发送到数据库？或者我可以使用我的普通代码查询数据库并自动处理解密吗？

或者我误解了静态加密的作用，我需要使用 AES_ENCRYPT代替/以及

Answer 1

静态加密
静态加密是数据库中未使用/访问或更新时的数据。移动中的加密类似于 TLS数据(来自数据库)从服务器传输到服务器到浏览器，再到服务器，再到浏览器等。如果小心处理并以 的态度接近，TLS 在大多数情况下是非常好的。您需要做的不仅仅是最低限度的使其真正安全。
一个典型的例子是人们在他们的域上放置了 LetsEncrypt 的 TLS 证书，然后突然认为他们所有的东西都是安全的；但他们不加密他们的 session 或他们的 cookie，因此在他们的防御中留下了巨大的潜在漏洞。
不要使用 MySQL 的内置加密系统。
我再怎么强调也不为过； MySQL 内置的加密系统不适合实际的安全数据保护。
请阅读 my answer to a very similar question here至于细节(我不想简单地复制/粘贴)。
好吧，那么，因为你坚持......在这里:

I have always understood NOT TO USE MySQL's built in encryption fuctionality because the point of encryption of data at rest (in the SQL) is that if the server is compromised, the data is not at [as much] risk.

The problem with the MySQL built in functionality is that it doesn't apply to when the data is passed to and from the "at rest" state, so the plaintext of any data can be recorded in MySQL logs (and elsewhere on the storage system, such as query lookups are not encrypted so you can from numerous lookups and their count results deduce column values) before/as it is encrypted. You can read more about this here.

Regarding encryption, you should use some tried and tested library like defuse/php-encryption.

根据我在自己关于该主题的研究中所读到的内容，Magnus 提供的链接指向 defuse/php-encryption是防止 MySQL 导致您破坏数据的最佳方法之一，永远不要让 MySQL 程序/服务器看到您数据的明文值。

-- 2017 年 5 月 7 日发布的答案。

还有 Bill Karwin's answer to the same question提供了一些有值(value)的额外见解:

+1 to Martin's answer, but I'll add some info for what it's worth.

MySQL 5.7 has implemented encryption at rest for InnoDB tablespaces (https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html).

MySQL 8.0 will reportedly also implement encryption at rest for InnoDB redo log and undo log files (https://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-encryption.html).

This still leaves unencrypted the query logs and the binary log. We'll have to wait for some future version of MySQL for that.

Why does it take so long? The head of the security engineering for MySQL said at a bird-of-feather session at the Percona Live conference last month [April 2017] that they are being very careful to implement encryption right. This means implementing features for encryption, but also key security and key rotation, and other usage. It's very complex to get this right, and they don't want to implement something that will become deprecated and make everyone's encrypted databases invalid.

-- 2017 年 5 月 7 日发布的答案。
收尾点:
安全性很复杂。如果你想正确地做这件事并对你的洋葱皮有信心，那么你需要做很多事情(见下面的项目符号)；但你需要做的第一件事是:

定义您要保护的对象

严重地。对于想要窃取您的明文名称和地址的人、想要接管您的服务器的人以及仅仅因为只是想破坏数据的人，您需要不同的策略。您可以一直保护自己免受所有人侵害，这是一个神话，从概念上讲，这是不可能的*；所以你需要定义最有可能的攻击者，然后找出如何最好地缓解他们的进步。
具体到 MySQL，一些明确的建议:

将 SQL 和 PHP 保持在同一台服务器上。不要远程访问 MySQL 数据。

排除对 SQL 的外部访问(所以只有 localhost)

混淆你的表名和列名；如果有人闯入您的数据而您拥有 HDTBJ^BTUETHNUYT栏目下username然后他们知道这个乱码可能是一个用户名，因此他们在尝试破解您的加密方面有一个很好的开端。

重要信息 :真正锁定您的表访问权限；设置大量 MySQL 用户，每个用户都只有最低限度的权限来做他们需要的事情；您希望用户阅读表格( 仅 )并且只阅读某些表格；用户写入某些表但无权访问其他表。如果MySQL 上的任何一个用户受到威胁，这是一个令人关注的问题；您并没有自动丢失那里的所有数据。

使用 PHP 加密服务。将加密 key 存储在一个完全独立的地方；例如，有另一台仅用于备份的服务器，您可以访问该服务器仅用于获取加密 key ，因此，如果您的 PHP/MySQL 服务器受到威胁，您有一些空间可以切断并锁定 key 服务器，这样您就可以限制伤害。如果 key 服务器也有备份，那么您实际上并没有受到太大的损害(视情况而定)。

设置大量观察者和电子邮件通知者，以准确告诉您某些进程何时运行以及哪些服务器用户(不是人，而是程序)在做什么。因此，您可以看到为什么在凌晨 5 点开始运行一个意外的进程来尝试测量 MySQL 表的大小。跆拳道？

即使您的 MySQL AES_ENCRYPT 数据不在数据库中静止，也有很大可能“嗅探”它，但如果网站受到威胁(或者更糟的是，PHP 代码不安全)，那么定时攻击就可以解决数据内容通过定时查询查找和数据包返回。

安全是一个黑洞；在某些时候，您会想“该死的，我已经做的够多了”。没有人拥有完全的安全性，一些非常敬业的组织拥有足够的安全性。在走完距离之前，您需要计算出您愿意走多远。

* 为什么不可能？因为要始终保护您的数据免受所有威胁，它需要像哈希一样不可读、不可用。哈希始终受到保护，不受任何人的影响。但是散列永远不会被取消散列。