数据库的跨平台加密

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所在的网络服务器？这确实应该与数据库服务器分开。两台服务器都托管在大学的网络中，但可以从互联网访问。

我可以遵循身份验证路径，直到企业内部的每个用户（上述大学的小型项目，可能是一个错误的措辞选择）都有一个具有合理设置授权的数据库用户。但是使用 php 的外部用户只发送要存储在数据库中的数据（理想情况下，使用一个通用但独立的数据库用户并相应地设置授权），并且永远不会检索（他们自己的）数据。使用身份验证意味着他们首先必须创建一个帐户（这不是必需的），他们如何验证自己以创建不需要的帐户？

Answer 1

在实施解决方案之前问这些问题很好，密码学很难正确理解，在开始之前需要充分理解。

我会先快速回答你的问题，但更重要的是接下来的部分。

• 并非如此。见下文。
• 是的，在大多数情况下，应尽可能将密钥保存在创建它们的设备上。
• 如果您的 API 服务器上没有数据库，则相对不太可能。
• 是的。
• 是的。
• 是的。但不要对它们进行base64。浪费空间和处理能力没有任何好处。
• 你问错问题了。算法不是“为”一种语言的。您只需要根据需要选择正确的算法/块模式/填充。

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

您需要了解的第一件事是，服务器违规就是服务器违规。不管你投入多少密码学，坏事都会发生。但我们可以尽可能减少损坏。

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

在此之后的一切都是身份验证。您需要一个强大的身份验证系统来确定谁可以向您发送信息以及谁可以从您那里检索信息。与您的 API 服务器的通信显然应该始终使用 TLS 加密。您可能会将TLS client authentication 视为一种确保向您请求数据的实体是他们所说的人的一种方式。通常客户端身份验证不能真正在网络上使用，但如果您以更私密的方式与“企业”交互，那么客户端身份验证是一个很好的选择。

总结：

• 将 API 服务器与数据库服务器分开。加密密钥应该只在 API 服务器上。请参阅this repository 获取从 PHP 到几乎任何其他语言的加密示例集合。

• 使用 TLS 进行所有传入和传出通信。

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