我正在尝试提高将包含敏感数据的MySQL数据库的安全性。我正在努力掌握一些术语。可以让我知道我是否正确理解了这种情况：
静态加密 -似乎我可以在表级别启用它。使用密钥对表中的所有数据进行加密。如果有人持有备份文件或对服务器具有物理访问权限，则数据将受到保护。当然，这假定密钥存储在其他位置。
AES_ENCRYPT- 在向表中插入/更新数据时，可以使用AES_ENCRYPT('data', 'password')。通过SELECT查询数据时，我使用AES_DECRYPT
AES_ENCRYPT('data', 'password')
AES_DECRYPT
假设我只是 在静止状态下 使用 加密， 那么我需要在PHP代码中执行其他操作来查询数据吗？我的PHP代码是否需要通过PDO请求将密钥发送到数据库？还是可以使用普通代码查询数据库并自动处理解密？
还是我误解了静态加密的作用，而我又需要使用AES_ENCRYPT/
AES_ENCRYPT
静态加密是指不使用/访问或更新数据库时的数据。移动中的加密就像TLS是将数据（ 来自数据库 ）从服务器传输到服务器到浏览器，再到服务器，再到浏览器等。在大多数情况下，如果认真处理并以 您 认为正确的态度处理TLS，则TLS是非常好的 选择需要做更多的事情，而不是最低限度的东西 才能真正实现它的真实性。
TLS
一个典型的例子是人们在自己的域上从LetsEncrypt获得TLS证书，然后突然觉得他们所有的东西都是安全的。但是 他们不加密会话或Cookie， 因此在防御中留下了巨大的潜在漏洞。
我对此压力还不够。MySQL中的内置加密系统不适用于实际的安全数据保护。
请在详细信息中阅读我对一个非常类似问题的回答（ 我不想简单地复制/粘贴 ）。
好吧，那么，因为您坚持....在这里：
我一直都理解 不要使用 MySQL内置的加密功能，因为静态数据加密（在SQL中）的重点是，如果服务器受到威胁，则数据的风险不会那么大。 MySQL内置功能的问题在于，它不适用于数据从“ 静止 ”状态传入/传出的 时间 ，因此任何数据的纯文本都可以记录在MySQL日志（以及存储系统中的其他位置）中，例如查询查询未加密，因此您可以从众多查询中获得count结果，并在加密之前/之内推断出列值。您可以在此处了解更多信息。 关于加密，您应该使用一些经过考验的库，例如defuse / php- encryption。 从我自己对此主题的研究中所读到的内容来看，Magnus提供的去碎片化/ php加密的链接是防止MySQL曾经导致您破坏数据的最佳方法之一，因为它永远不会让MySQL程序/服务器曾经看到过数据的纯文本值。
我一直都理解 不要使用 MySQL内置的加密功能，因为静态数据加密（在SQL中）的重点是，如果服务器受到威胁，则数据的风险不会那么大。
MySQL内置功能的问题在于，它不适用于数据从“ 静止 ”状态传入/传出的 时间 ，因此任何数据的纯文本都可以记录在MySQL日志（以及存储系统中的其他位置）中，例如查询查询未加密，因此您可以从众多查询中获得count结果，并在加密之前/之内推断出列值。您可以在此处了解更多信息。
count
关于加密，您应该使用一些经过考验的库，例如defuse / php- encryption。
从我自己对此主题的研究中所读到的内容来看，Magnus提供的去碎片化/ php加密的链接是防止MySQL曾经导致您破坏数据的最佳方法之一，因为它永远不会让MySQL程序/服务器曾经看到过数据的纯文本值。
-答案于2017年5月7日发布。
此外比尔Karwin的回答同样的问题，提出了一些有价值的额外的见解：
+1为Martin的答案，但我会添加一些有关其价值的信息。 MySQL 5.7已经为InnoDB表空间实现了静态加密（https://dev.mysql.com/doc/refman/5.7/en/innodb- tablespace-encryption.html）。 据报道，MySQL 8.0还将对InnoDB重做日志和撤消日志文件（https://dev.mysql.com/doc/refman/8.0/en/innodb- tablespace-encryption.html）进行静态加密。 这仍然留下未加密的查询日志和二进制日志。为此，我们将不得不等待将来的MySQL版本。 为什么要花这么长时间？MySQL安全工程负责人在上个月[2017年4月]在Percona Live会议上的一次飞鸟式会议上表示，他们非常谨慎地实施加密权。这意味着既要实现加密功能，又要实现密钥安全性和密钥轮换以及其他用途。要做到这一点非常复杂，他们不希望实现某些东西会变得过时并且会使每个人的加密数据库无效。
+1为Martin的答案，但我会添加一些有关其价值的信息。
MySQL 5.7已经为InnoDB表空间实现了静态加密（https://dev.mysql.com/doc/refman/5.7/en/innodb- tablespace-encryption.html）。
据报道，MySQL 8.0还将对InnoDB重做日志和撤消日志文件（https://dev.mysql.com/doc/refman/8.0/en/innodb- tablespace-encryption.html）进行静态加密。
这仍然留下未加密的查询日志和二进制日志。为此，我们将不得不等待将来的MySQL版本。
为什么要花这么长时间？MySQL安全工程负责人在上个月[2017年4月]在Percona Live会议上的一次飞鸟式会议上表示，他们非常谨慎地实施加密权。这意味着既要实现加密功能，又要实现密钥安全性和密钥轮换以及其他用途。要做到这一点非常复杂，他们不希望实现某些东西会变得过时并且会使每个人的加密数据库无效。
安全性很复杂。如果您想正确地进行操作并对洋葱皮有信心，那么您需要做很多事情（请参见下面的项目符号）；但您需要做的第一件事是：
说真的 对于那些想要窃取您的纯文本名称和地址的人，想要接管您的服务器的人，以及仅仅因为垃圾数据而要浪费数据的人，您需要采取不同的策略。您可以一直保护自己不受所有人的迷惑，从概念上讲，这是不可能的*；因此，您需要定义最可能的攻击者，然后确定如何最好地减轻攻击者的攻击。
对于MySQL而言，有一些明确的建议：
将SQL和PHP保留在同一服务器上。不要远程访问MySQL数据。
排除对SQL的外部访问（因此localhost）
localhost
混淆表名和列名；如果有人闯入您的数据并且您HDTBJ^BTUETHNUYT位于该列下，username那么他们知道此乱码可能是用户名，因此他们在尝试破坏您的加密方面有一个很好的开始。
HDTBJ^BTUETHNUYT
username
重要提示 ：真正锁定表访问；设置许多MySQL用户，每个用户只有最基本的特权即可执行所需的工作；您希望用户读取表（ 仅 ），并且仅读取某些表；用户写入某些表，但无权访问其他表。它是关注点分离，因此，如果MySQL上的任何一个用户受到威胁，都将受到影响。您并不会自动丢失其中的所有数据。
使用PHP加密服务。将加密密钥存储在完全独立的位置；例如，有一台仅用于备份的服务器，您只能访问该服务器以获取加密密钥，因此，如果您的PHP / MySQL服务器受到威胁，则有一定的空间可以切断并锁定Key服务器，这样您就可以限制损害。如果密钥服务器也有备份，那么实际上您并不会受到严重影响（ 取决于具体情况 ）。
设置许多观察程序和电子邮件通知程序，以准确告诉您某些进程何时运行以及哪些服务器用户（不是人员而是程序）在做什么。因此，您可以了解为什么意外的进程在凌晨5点开始运行，以尝试测量MySQL表的大小。WTF？
即使您的MySQL AES_ENCRYPT数据不在数据库中处于静止状态，也很有可能“嗅探”您的数据，但是如果网站受到威胁（或更糟糕的是，PHP代码不安全），那么定时攻击就可以解决通过定时查询查找获得数据内容，并返回数据包。
安全是一个黑洞。在某些时候，您可能会想“做完了，我做够了”。没有人拥有全面的安全性，一些非常敬业的组织拥有 足够的 安全性。您需要先确定自己愿意走多远，然后再走远。
