c# - 数据库的跨平台加密

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访问。
我可以遵循身份验证路径，直到企业内的每个用户（该大学的小型ish项目，可能措辞不好）都有一个拥有合理设置的授权的数据库用户。但是，使用php的外部用户只发送要存储在数据库中的数据（理想情况下是与一个具有相应授权集的公共但独立的数据库用户一起），而从不检索（他们自己的）数据。使用身份验证意味着他们首先必须创建一个帐户（这是不需要的），他们如何验证自己创建不需要的帐户？

Answer 1

在实现解决方案之前询问这些问题是很好的，密码学很难正确理解，在开始之前需要有一个良好的理解。
我会先快速回答你的问题，但更重要的是接下来的内容。
不是真的。见下文。
是的，在大多数情况下，只要可能，密钥应该保存在创建它们的设备上。
如果你的API服务器上没有数据库的话，这是不太可能的。
对。
对。
对。但不要以64为基数。浪费空间和处理能力没有好处。
你问错了问题。算法不是“为”语言。您只需要根据需要选择正确的算法/块模式/填充。
在很大程度上，你所问的问题是无关紧要的。信不信由你，你的问题更多的是与身份验证有关，而不是与加密有关。
首先，您需要了解的是，服务器漏洞就是服务器漏洞。不管你用多少加密技术，坏事情总会发生的。但我们可以尽可能减少损失。
您的数据库软件应该运行在一个单独的服务器/实例/任何API服务器上。加密/解密只应在您的API服务器上进行。这样做的好处是，为了解密数据（访问密钥），必须同时破坏API服务器和数据库服务器。如何在API服务器上存储密钥并不那么重要，只要它们不在webroot或类似的愚蠢的东西中。
过去的一切都是认证。您需要一个强大的身份验证系统来确定谁可以向您发送信息以及谁可以从您检索信息。与API服务器之间的通信显然应该始终使用TLS加密。您可以考虑使用TLS client authentication来确保向您请求数据的实体是他们所说的实体。通常客户端身份验证不能真正在web上使用，但是如果您以更私密的方式与“企业”交互，那么客户端身份验证是一个很好的选择。
总而言之：
将API服务器与数据库服务器分离。加密密钥应该只在API服务器上。有关从PHP到几乎任何其他语言的加密示例的集合，请参见this repository。
使用TLS进行所有输入和输出通信。
关注身份验证。TLS客户端身份验证是一个不错的选择。