mysql - 静态和/或AES_ENCRYPT加密

Question

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

静态加密-似乎我可以在表级别启用它。使用密钥对表中的所有数据进行加密。如果有人持有备份文件或对服务器具有物理访问权限，则数据将受到保护。当然，这假定密钥存储在其他位置。

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


假设我只是在静态使用加密，那么我是否需要在PHP代码中执行其他操作来查询数据？我的PHP代码是否需要通过我的PDO请求将密钥发送到数据库？还是可以使用普通代码查询数据库并自动处理解密？
还是我误解了静态加密的作用，而我也需要使用AES_ENCRYPT

Answer 1

静态加密

静态加密是不使用/访问或更新时数据库中的数据。移动中的加密就像TLS这样，其中（数据库中的）数据（从数据库）从服务器传输到服务器，浏览器，再到服务器，再到浏览器等。如果在使用TLS并经过仔细处理和处理后，TLS在大多数情况下都是非常好的。您需要采取的措施远不止最低限度，实际上要使其切实可行。

一个典型的例子是人们在自己的域上从LetsEncrypt获得TLS证书，然后突然认为他们所有的东西都是安全的。但他们不加密会话或Cookie，因此在防御中留下了巨大的潜在漏洞。

不要使用MySQL的内置加密系统。

我对此压力还不够。 MySQL中的内置加密系统不适用于实际的安全数据保护。

请阅读my answer to a very similar question here有关详细信息（我不想简单地复制/粘贴）。

好吧，因为您坚持要.....




  我一直都理解不要使用MySQL内置的加密功能，因为静态数据加密（在SQL中）的重点是，如果服务器受到威胁，则数据的风险不会太大。
  
  MySQL内置功能的问题在于它不适用于数据从“静止”状态传入/传出的时间，因此任何数据的纯文本都可以记录在MySQL日志（以及存储系统中的其他位置）中，例如查询查询未加密，因此您可以从许多查询中及其count结果推断出加密前/加密后的列值。 You can read more about this here。
  
  
    关于加密，您应该使用一些经过测试的库，例如defuse/php-encryption。
  
  
  从我自己对此主题的研究中所读的内容来看，Magnus提供的与defuse/php-encryption的链接是防止MySQL导致您破坏数据的最佳方法之一，因为它永远不会让MySQL程序/服务器看到数据的纯文本值。


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



另外，Bill Karwin's answer to the same question还提供了一些有价值的其他见解：


  +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的安全工程负责人在上个月的Percona Live会议上的一次雀跃会议上说，他们非常谨慎地实施加密权。这意味着既要实现加密功能，又要实现密钥安全性和密钥轮换以及其他用途。要做到这一点是非常复杂的，他们不想实现不赞成使用的东西，并使每个人的加密数据库无效。


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

收盘点：

安全性很复杂。如果您想正确地进行操作并且对保护性洋葱皮有信心，那么您需要做很多事情（请参见下面的项目符号）；但您需要做的第一件事是：

定义要防范的对象

说真的对于那些想要窃取您的纯文本名称和地址的人，想要接管您的服务器的人，以及仅仅因为垃圾数据而仅仅想要破坏数据的人，您需要采取不同的策略。您可以一直保护自己免受所有人侵扰是一个神话，从概念上讲，这是不可能的*；因此，您需要定义最可能的攻击者，然后确定如何最好地减轻攻击者的攻击。

对于MySQL而言，有一些明确的建议：


将SQL和PHP保留在同一服务器上。不要远程访问MySQL数据。
排除对SQL的外部访问（因此仅localhost）
混淆您的表名和列名；如果有人闯入您的数据并且您在%$HDTBJ^BTUETHNUYT列下有username，那么他们知道此乱码可能是用户名，因此他们在尝试破坏您的加密方面有一个很好的开始。
重要提示：真正锁定表访问；设置许多MySQL用户，每个用户只有最低限度的特权即可执行所需的工作；您希望用户仅读取表并且仅读取某些表；用户写入某些表，但无权访问其他表。它是关注点分离，因此，如果MySQL上的任何一个用户受到威胁，都将受到影响。您并不会自动丢失其中的所有数据。
使用PHP加密服务。将加密密钥存储在完全独立的位置；例如，有一台仅用于备份的服务器，您只能访问该服务器以获取加密密钥，因此，如果您的PHP / MySQL服务器受到威胁，则有一定的空间可以切断并锁定Key服务器，这样您就可以限制损害。如果密钥服务器也有备份，那么实际上您不会受到严重损害（取决于情况）
设置大量监视和电子邮件通知程序，以准确告诉您某些进程何时运行以及哪些服务器用户（不是人员而是程序）在做什么。因此，您可以看到为什么一个意外进程在凌晨5点开始运行以尝试测量MySQL表的大小。 WTF？
即使您的MySQL AES_ENCRYPT数据不在数据库中处于静止状态，也很有可能“嗅探”您的数据，但是如果网站受到威胁（或更糟糕的是，PHP代码不安全），那么定时攻击就可以解决通过定时查询查找获得数据内容，并返回数据包。
安全是一个黑洞。在某个或另一个时刻，您会认为“已经做好了，我已经做好了”。没有人拥有全面的安全性，一些非常敬业的组织拥有足够的安全性。您需要先确定自己愿意走多远，然后再走远。




*为什么不可能？因为要始终保护您的数据不受所有威胁的影响，它就必须像哈希一样不可读，不可用。哈希始终不受所有人的保护。但是哈希永远不会散列。