安全加密数据库设计

Question

我有一个基于网络（perl / MySQL）的CRM系统，我需要一个HR部分来添加有关纪律处分和工资的详细信息。

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

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

我认为我可以使用加密密钥加密所有信息，并使用HR管理员的密码加密密钥。然后她可以随意更改密码，我们只需要重新加密密钥。 （没有人力资源经理的密码，数据是安全的）

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

我可以保留关键网站的“明文”副本，并使用每个新的HR人员密码对其进行加密。但后来我知道主密钥，这似乎并不理想。

以前是否有人尝试过此操作并成功了？

Answer 1

GnuPG允许使用多个公钥加密文档，并使用任何一个相应的私钥进行解密。通过这种方式，您可以使用HR部门中每个人的公钥来加密数据。解密可以由具有私钥之一的任何人执行。解密将需要私钥和保护密钥的密码短语才能为系统所知。私钥可以保存在系统中，密码从用户那里征求。

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

系统的薄弱环节是私钥需要系统可用（即不受用户控制），密码必须通过系统，因此可能会受到损害（即通过狡猾的代码记录，被盗。最终，原始数据也会通过系统，因此狡猾的代码可以在不担心密钥的情况下妥协。良好的代码审查和发布控制对于维护安全性至关重要。

最好避免使用MySQL的内置加密功能：这些功能会记录在复制，慢速或查询日志中，并且可以在流程列表中显示 - 因此任何有权访问日志和进程列表的人都可以访问数据

Answer 2

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

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

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

Answer 3

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

1. 应用程序为记录生成唯一的初始计数器值。这可能基于记录的某些唯一属性，或者您可以为此目的生成并存储唯一值。
2. 应用程序根据初始计数器值为记录生成计数器块流。计数器流的大小必须相同或比明文大1个块。
3. 应用程序确定要使用的密钥。如果定期旋转键，则应使用最新的键。

4. 将计数器流发送到要加密的数据库：类似

   从hrkeys中选择aes_encrypt（'counter'，key），其中key_id ='id';

5. 将生成的加密计数器值修剪为明文的长度，并使用明文进行异或运算以生成加密文本。

6. 存储加密文本。
7. 解密与加密文本应用的过程完全相同。

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

请参阅Wikipedia - Counter Mode

Answer 4

我只是在大声思考。

这似乎要求公钥/私钥机制。该信息将使用HR公钥加密存储，并且只有拥有相关私钥的人才能查看。

对我而言，这似乎排除了基于Web的界面来查看这些机密数据（通过Web界面输入它们当然是可行的）。

鉴于个人来去，将钥匙绑在特定人的账户上似乎是不可行的。相反，必须单独处理密钥分发，并且有一种机制可以让某人更改所使用的密钥对（并重新加密数据库 - 再次不使用Web界面），以防当前的HR管理器被其他人替换。当然，在更换密钥之前，没有什么能阻止HR管理员在离开之前转储所有数据。

Answer 5

我不确定这是当前有多可行，或者当前稳定的数据库系统对此有何支持，但数据库级别的备用身份验证机制可能有所帮助。例如，Drizzle，一个MySQL代码库的重构，支持（或旨在？）完全可插入的身份验证，不允许auth，服务器封装auth，或通过PAM或其他机制auth，这意味着你可以使用LDAP。

如果您根据数据库连接有不同的访问级别，并且应用程序登录还指定了您可以在数据库中实际访问的内容，理论上您可以构建一个无法访问机密数据库信息的系统，除非使用具有特定访问权限的帐户，无论应用程序本身的权限升级尝试如何。

只要设置用户帐户访问权限的人可以信任，或者他们自己可以查看机密信息，这应该是相当安全的。

P.S。对于“常规”应用程序信息使用通用DB连接可能是有用的，但是当尝试访问机密信息时，则尝试特定的DB连接。假设大多数用户没有查看机密信息，这允许少数数据库连接来处理大多数请求。否则，每个用户单独的数据库连接可能会对数据库造成负担。