密钥mysql_MySQL加密和密钥管理

实际上没有任何内置的MySQL功能可用于处理复杂的加密密钥设置.您需要在自己的PHP和/或浏览器端(javascript？)代码中实现大量加密逻辑.

但是您所陈述的问题有点奇怪：您似乎唯一真正关心的是从远程客户端桌面/笔记本电脑工作站进行SQL注入或暴力攻击(猜测密码,我猜)攻击.这让我怀疑你已经计划了一些其他未提及的安全措施,并且你已经分析了可能的妥协途径.

>首先,我假设您有防火墙规则保护MySQL / PHP主机免受来自未批准的远程客户端IP的任何类型的访问.如果我是正确的,那么你只关心受到攻击的用户工作站的攻击是有道理的.

>此外,我假设您了解如果远程客户端主机上的攻击者可以升级到root / Admin privs,或者直接破坏真实用户自己的帐户,那么无论加密或任何其他安全措施如何,该客户端的数据都不会受到任何保护. (攻击者可以从磁盘上保存的任何地方读取密钥,或者在真实用户登录时输入密钥,密钥导致数据.)

从这两个假设开始,我们可以得出结论,只有两个相关的威胁是A)暴力密码猜测,以及B)SQL注入尝试：

>如果攻击者没有获得真实用户的密钥,或者他想要访问的不仅仅是真实用户的数据,他可以尝试为真实用户或其他帐户强制登录信用. (理论上,您可以将每个帐户锁定到特定的远程客户端IP,这也有助于划分风险.)

>如果攻击者确实获得了真实用户的有效密钥,那么他就有一条通过登录屏幕的大道(大概足够安全),这可能是潜在错误的应用程序代码的软肋.从真实用户的上下文中成功注入SQL也可以让他访问其他客户端数据.

现在,我们来谈谈服务器端加密如何应用于这些情况：

>服务器端加密肯定有助于抵御SQL注入威胁.如果行值在DB表中加密,则攻击者只能看到属于其他帐户的数据的乱码密文.威胁被包含,分隔.

但是,强制密码猜测对于面临服务器端加密的攻击者来说并没有那么难.无论用户的密钥是存储在服务器上还是通过密码在现场生成,唯一重要的是您是否拥有正确的密码.服务器决定让您使用有效的存储密钥,因为它会检查您的密码是否正确,或者它为您计算有效密钥,因为您的密码是生成该密钥的正确输入.

另一方面,客户端加密实际上使暴力密码攻击无关紧要.你不能强行使用正确构造的密钥.客户端加密与基于服务器端加密的SQL注入基本保持相同的保护级别.客户端可以在登录时将密钥传递给服务器,将副本保留在内存中直到会话结束,这会将加密CPU负担放在服务器上.或者,客户端可以在浏览器中自行处理加密/解密.这两种技术都有起伏不定：

>将其密钥传递到服务器更容易编码和管理,并且通常由于更优化的加密代码(可能是编译的C)而更快.

>纯客户端方法提供额外的安全性,因为即使攻击者在服务器上获得root权限,他仍然无法读取加密数据,并且他永远无法读取它.唯一可能的攻击媒介是危害远程客户端工作站.

最后,我要指出,加密数据库中的数据有一些巨大的操作缺点.由于加密数据表示基本上是随机模式,因此基本数据库功能(如索引,连接等)不起作用.客户端承担了巨大的逻辑负担,并且可能会失去数据库功能通常带来的许多好处.