安全的加密数据库设计

Question

我有一个基于web的(perl/MySQL) CRM系统，我需要一个人力资源部门，以添加有关纪律处分和工资的细节。

我们存储在数据库中的所有这些信息都需要加密，以便我们开发人员看不到它。

我在考虑使用AES加密，但是我应该使用什么作为密钥呢？如果我使用人力资源经理的密码，那么如果她忘记了密码，我们将丢失所有人力资源信息。如果她更改了密码，那么我们必须解密所有信息并使用新密码重新加密，这似乎效率低下，而且很危险，如果在过程中出现错误，可能会出现可怕的错误。

我的想法是，我可以拥有一个加密密钥来加密所有信息，并使用HR经理的密码来加密该密钥。然后她可以随心所欲地更改密码，我们只需要重新加密密钥。(没有人力资源经理的密码，数据是安全的)

但是仍然存在多用户访问加密数据的问题。

我可以在场外保存密钥的“明文”副本，并使用每个新HR人员的密码对其进行加密。但是我知道了万能钥匙，这看起来并不理想。

以前有没有人尝试过，并取得了成功？

Answer 1

GnuPG允许使用多个公钥对文档进行加密，并使用任何一个相应的私钥对文档进行解密。这样，您就可以允许使用HR部门中每个人的公钥对数据进行加密。任何拥有私钥之一的人都可以执行解密。解密将要求系统知道私钥和保护密钥的口令两者。私钥可以保存在系统内，并且口令短语可以从用户处请求。

使用大量密钥的GnuPG可能会使数据变得非常臃肿:它必须为有效负载创建一个会话密钥，然后使用每个公钥对该密钥进行加密。加密的密钥与数据一起存储。

系统的薄弱部分在于私钥需要对系统可用(即，不在用户的控制下)，并且口令短语将不得不通过系统，因此可能被损害(即，被不可靠的代码记录和窃取)。最终，原始数据也会通过系统，所以不可靠的代码可能会损害这一点，而不必担心键。良好的代码审查和发布控制对于维护安全性至关重要。

最好避免使用MySQL的内置加密函数:这些函数记录在复制日志、慢查询日志或查询日志中，并且可以在进程列表中看到-因此，任何有权访问日志和进程列表的人都可以访问这些数据。

Answer 2

为什么不在一般情况下限制对数据库或表的访问。这看起来容易多了。如果开发人员有权查询产品，就没有办法阻止他们在一天结束时看到数据b/c，UI必须解密/显示数据。

根据我的经验，实现“开发人员根本看不到生产数据”所需的工作量是巨大的，几乎是不可能的。归根结底，如果开发人员必须支持系统，这将很难实现。如果您必须调试生产问题，那么不允许一些开发人员访问生产数据是不可能的。另一种方法是创建大量级别和组的支持、备份、测试数据等。

它可以工作，但并不像企业主想象的那么容易。

Answer 3

另一种方法是使用存储在数据库中的单个系统范围的密钥-可能具有唯一的id，以便可以定期添加新的密钥。使用计数器模式，可以使用标准的MySQL高级加密标准，而无需直接将明文暴露给数据库，并且加密数据的大小将与明文的大小完全相同。算法的草图：

1. 应用产品为记录生成唯一的初始计数器值。这可能基于记录的某些唯一属性，或者您可以为此生成并存储唯一值。
2. 应用产品将根据初始计数器值为记录生成计数器块流。计数器流的大小必须与明文相同或最多比明文大1个块。
3. 应用程序确定要使用的密钥。如果密钥是定期轮换的，那么应该使用最近的密钥。
4. 计数器流被发送到数据库进行加密:如下所示

select aes_encrypt( ' counter '，key ) from hrkeys key_id =‘id’；

• 生成的加密计数器值被修整为明文的长度，XORed与明文一起生成加密文本。

• the encrypted text is hrkey与应用于加密文本的过程完全相同。

这样做的好处是明文永远不会出现在数据库附近的任何地方，因此管理员无法看到敏感数据。但是，您将面临阻止管理员访问加密的计数器值或密钥的问题。第一个可以通过在应用程序和数据库之间使用SSL连接进行加密操作来实现。第二个问题可以通过访问控制来缓解，确保键永远不会出现在数据库转储中，将键存储在内存表中，这样就不会通过使用“跳过授权”重新启动数据库来破坏访问控制。最终，消除这种威胁的唯一方法是使用防篡改设备(HSM)来执行加密。您要求的安全性越高，您在数据库中存储密钥的可能性就越小。

请参阅Wikipedia - Counter Mode