数据库的跨平台加密

Question

假设我有一个MySQL数据库，用户可以在其中通过php网站输入一些个人数据，例如邮政地址。 用户无法登录该站点以以后验证他们输入的内容。 他们为其输入数据的企业（当然是自愿的）然后可以使用该数据向用户发送实际的邮件（您知道，邮政服务等）或电子邮件（当然，用户事先同意他们要接收电子邮件） 。 数据库仅用作数据存储，我希望它有点安全。 如果有人闯入数据库，则检索电子邮件地址以及实际的名字和姓氏（无论如何，许多电子邮件地址都包含两者）可能不会造成太大的伤害，但是知道人们的住处可能是一件大事。

企业正在通过C＃前端访问数据库，该前端将数据库中的存储过程作为目标来处理事务，包括根据用户的电子邮件地址搜索用户。

通过搜索收集的信息，我可以想到以下过程以更安全的方式处理个人数据（比将它们另存为数据库中的纯文本）

• 在将敏感信息提交给存储过程之前，纯文本在仍然位于php中的同时使用密钥进行了加密，因此所有MySQL服务器日志中看到的都是加密数据
• 前端使用相同的密钥将数据显示给企业用户时再次使人可读（他们需要访问此私人信息，并且用户对企业感到满意，这就是此方案的重点）

我的思路是：这些不是存储的密码，因此我不需要所有密码哈希技巧（据我所知，在将密码安全地保存在数据库中时，您使用的是单向算法，因此永远直接从数据库对密码进行反向工程，但必须对想要尝试的每个密码进行哈希处理，并根据所需的数据库条目对其进行测试，以查看是否选择了正确的密码），但是可以选择简单的加密/解密，因为我不会希望将每个地址都强行从数据库中删除。

有一些粗糙的地方让我感到担忧：

• 我需要以某种方式提供要加密到php的密钥。 通常，这是通过库或外部php文档完成的，就像您在单独的php文件中提供数据库连接信息一样，该文件位于无法从Web访问的服务器上的文件夹中（如果您尝试访问） 这是一个好习惯吗，我可以确定这个密钥文件真的很安全吗？
• 我还需要提供前端的密钥。 这应该在前端的（可能是加密的？）配置文件中单独完成。 尽管对于两个不同的系统，将密钥放在两个位置是否明智？ 密钥永远不能更改，否则部分数据将丢失！
• 我以某种方式感到，如果有人知道如何访问数据库，他/她可能会弄清楚连接数据在哪里以及如何访问它。 哦，看，这是一个加密密钥，我不知道该怎么做。 如果数据库访问遭到破坏，那么加密密钥公开的可能性有多大，并且使所有为用户提供一点额外隐私的工作都变得无效了？
• 如果我想再增加一点“额外的安全性”并同时对电子邮件地址进行加密，那我就必须对要从php或前端搜索的每个电子邮件地址进行加密，对吗？
• 使用“ RLIKE”进行搜索的过程会破坏加密字段，不是吗？ 因此，要保留搜索电子邮件地址的一部分，我无法加密电子邮件条目，对吗？
• 我将不得不将数据库字段更改为二进制以容纳加密数据，或者将它们增大并进行base64编码，不是吗？
• PHP 7.0.7和C＃中是否已准备好使用加密/解密算法？ （我对C＃不必太担心）一种在不将我的小文本膨胀到大量二进制文件的情况下相当安全的工具？ 我不知道这是否有任何影响，但是例如 ， 如果我使用256位密钥，则为32字节。 如果地址的街道部分短于32个字符，加密将起作用吗？ 会涉及繁琐的填充吗？

总而言之，与我必须在我的php文件以及前端代码中采取的措施相比，我认为安全性提升是微不足道的。 可以感觉到的安全收益可能更大（“哇！他们正在加密加密保存我们的数据！他们肯定知道自己在做什么！”）。 对某些类型的用户具有严格和限制性的特权（例如，撤消“ SELECT”命令）应该更有用，不是吗？

为@Luke Joshua Park编辑：

感谢您的详细回答。 我想API服务器是指我的php驻留在Web服务器上吗？ 这确实应该与数据库服务器分开。 两台服务器都托管在大学的网络中，但可以从Internet访问。

我可以遵循身份验证的路径，以至于企业中的每个用户（在所说的大学里项目不多，也许是措辞上的错误选择）都拥有一个数据库用户，并且该用户具有合理的设置权限。 但是从外部使用php的用户仅发送要存储在数据库中的数据（理想情况下，将使用一个普通但独立的数据库用户，并为其设置了相应的授权），并且永远不会获取（自己的）数据。 使用身份验证意味着他们首先必须创建一个帐户（不需要），并且他们如何对自己进行身份验证以创建不需要的帐户？

Answer 1

在实施解决方案之前 ，您最好问这些问题，加密很难正确进行，并且在开始之前需要有充分的了解。

我将首先快速回答您的问题，但更重要的部分是后续内容。

• 并不是的。 见下文。
• 是的，在大多数情况下，密钥应尽可能保留在创建它们的设备上。
• 如果您的API服务器上也没有数据库，则相对不太可能。
• 是。
• 是。
• 是。 但是请不要使用base64。 浪费空间和处理能力毫无益处。
• 您在问错问题。 算法不是针对语言的。 您只需要根据需要选择正确的算法/块模式/填充。

在大多数情况下，您所提出的问题是无关紧要的。 信不信由你，您的问题更多的是与身份验证有关，而不是与加密有关。

您需要了解的第一件事是服务器违规就是服务器违规。 不管您使用多少加密技术，坏东西都会发生。 但是我们会尽可能减少损害。

您的数据库软件应该在与API服务器不同的服务器/实例/上运行。 加密/解密只能在您的API服务器上进行。 这样的好处是您的API服务器和数据库服务器都必须被破坏才能解密数据（访问密钥）。 如果密钥不在您的webroot或类似的东西中，那么如何将密钥存储在API服务器上并不重要。

过去的一切都是验证。 您需要一个强大的身份验证系统来确定谁可以向您发送信息以及谁可以从您那里检索信息。 与API服务器之间的通讯显然应该始终使用TLS加密。 您可能会考虑使用TLS客户端身份验证 ，以确保从您那里请求数据的实体就是他们所说的身份。 通常，客户端身份验证不能真正在Web上使用，但是如果您以更私密的方式与“企业”进行交互，则客户端身份验证是一个不错的选择。

综上所述：

• 将您的API服务器与数据库服务器分开。 加密密钥仅应位于API服务器上。 请参阅此存储库 ，以获取从PHP到几乎所有其他语言的加密示例的集合。

• 将TLS用于所有传入和传出通信。

• 专注于身份验证。 TLS客户端身份验证是一个不错的选择。