我正在尝试改进包含敏感数据的MySQL数据库的安全性.我正在努力掌握一些术语.如果我理解了这种情况,有人可以告诉我：
静态加密 – 似乎我可以在表级启用它.表中的所有数据都使用密钥加密.如果某人掌握了备份文件或获得了对服务器的物理访问权限,那么数据将受到保护.当然,这假定密钥存储在别处.
AES_ENCRYPT – 在我的表中插入/更新数据时,我可以使用AES_ENCRYPT(‘data’,’password’).通过SELECT查询数据时,我使用AES_DECRYPT
>假设我只是在休息时使用加密,那么我需要在我的PHP代码中做任何不同的事情来查询数据吗？我的PHP代码是否需要通过我的PDO请求将密钥发送到数据库？或者我可以使用我的常规代码查询数据库并自动处理解密？
>或者我误解了静态加密,我需要使用AES_ENCRYPT代替/
静态加密是数据库中未使用/访问或更新的数据.移动中的加密就像TLS,其中数据(来自数据库)从服务器传输到服务器到浏览器,到服务器,再到浏览器等.如果经过仔细处理并以一种态度接近,TLS在大多数情况下都是完美的.你需要做的不仅仅是最低限度,才能真正实现安全.
一个典型的例子就是人们在他们的域名上从LetsEncrypt那里获得了TLS证书,并认为突然他们所有的东西都是安全的;但是他们没有加密他们的会话或他们的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
countresults deduce column values) before/as it is encrypted. 07001.Regarding encryption,you should use some tried and tested library like 07002.
从我在自己对这个主题的研究中所看到的,Magnus提供给defuse/php-encryption的链接是阻止MysqL导致你破坏数据的最佳方法之一,从不让MysqL程序/服务器看到明文您的数据的价值.– 2017年5月7日发布的答案.
Bill Karwin’s answer to the same question还提供了一些有价值的额外见解：
+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 (07005).
MysqL 8.0 will reportedly also implement encryption at rest for InnoDB redo log and undo log files (07006).
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 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日发布的答案.
结束点：
安全性很复杂.如果你想要正确地做到并对你的保护性洋葱皮有信心,那么你需要做很多事情(见下面的子弹);但你需要做的第一件事是：
定义您要保护的人
认真.对于想要窃取您的明文名称和地址的人,与需要接管您的服务器的人相比,您需要采取不同的策略,而不是仅仅因为想要删除数据的人.这是一个神话,你可以一直保护所有人,按概念这是不可能的*;因此,您需要定义最可能的agressors,然后找出如何最好地减轻他们的进步.
对于MysqL,有一些明确的建议：
>将sql和PHP保存在同一台服务器上.不要远程访问MysqL数据.
>排除对sql的外部访问(因此它只是localhost)
>模糊您的表名和列名;如果有人闯入您的数据并且您在列@R_301_473@下有％$HDTBJ ^ BTUETHNUYT,那么他们知道这个乱码可能是一个@R_301_473@,因此他们在尝试破解加密方面有一个很好的开端.
>重要提示：真正锁定您的桌面访问权限;建立了许多MysqL用户,每个用户只有最低限度的特权来做他们需要的事情;你希望用户只读取表格,只读取某些表格;用户写入某些表但无权访问其他表.如果MysqL上的任何一个用户遭到攻击,那么这是一个令人担忧的问题.你没有自动丢失那里的每一个数据.
>使用PHP加密服务.将加密密钥存储在完全独立的位置;例如,你有另一个服务器,你只能用于备份,你可以访问它只是为了获取加密密钥,因此,如果你的PHP / MysqL服务器被泄露,你有一些空间来切断和锁定密钥服务器,所以你可以限制伤害.如果密钥服务器也有备份,那么你真的不会受到太多损害(取决于情况)
>设置大量手表和电子邮件告密者,以准确告诉您某些进程何时运行以及哪些服务器用户(不是人员而是程序)正在做什么.因此,您可以看到为什么意外的进程在凌晨5点开始运行以尝试测量MysqL表的大小. WTF？
>即使数据库没有静止,你的MysqL AES_ENCRYPT数据也很有可能被“嗅探”,但如果网站遭到入侵(或者更糟糕的是,PHP代码不安全),那么定时攻击可以起作用通过定时查询查找和数据包返回来输出数据内容.
>安全是一个黑洞;在某些时候,你会想到“Sod this,我已经做得足够多了”.没有人有完全的安全性,一些非常专注的组织有足够的安全性.你需要知道在离开远方之前你愿意走多远.*为什么不可能？因为要始终保护您的数据免受所有威胁,所以它需要是不可读的,不可用的,就像哈希一样.哈希始终受到所有人的保护.但哈希永远不会被散乱.