有什么本地技术可以加密数据库中的字符串以读入单个应用程序？答案

【问题标题】：What native technology exists to encrypt a string in the database for reading into a single application?有什么本地技术可以加密数据库中的字符串以读入单个应用程序？
【发布时间】：2014-04-08 22:47:54
【问题描述】：

存在哪些本地技术可以加密/解密数据库中的字符串以读取到单个应用程序中？

场景：

我有一组连接字符串，我需要使用它们来安全地访问一组生产服务器，用于轮询应用程序。我想将它们存储在数据库中的表中，并在需要时通过服务将它们取出。这将使我能够让少数用户（具有权限）编辑/添加这些条目。

我使用此应用程序的目标受众都是开发人员，这些服务器用于监控我们的生产和暂存环境中的某些特定 SQL 缺陷，我可能需要稍后修复这些缺陷。这是一个 devops 应用程序。

知道我的目标受众是开发人员，并且这些是生产服务器，我想“锁上门”以防止人们主动看到生产密码/用户帐户，除非他们需要它们（审计目的）。我意识到一把锁只和门框一样好，只是为了让诚实的人和小偷远离，任何有奉献精神的人最终都可以通过我尝试设置的任何安全措施。

问题：

在 C# 中存在什么技术来保护这些信息，并且仍然允许我动态添加/更改连接字符串，但仍然保持数据库中的数据相当安全？我愿意对 machine.config 等进行一些更改，但我也需要积极开发应用程序，所以希望它可以在 machine.config¹ 或 web 中完成。配置，以允许在部署到 devops 服务器之前进行本地开发。

我了解我的一些替代建议是：

使用强数据库密码将他人拒之门外
使用强大的架构组织将人们拒之门外
相信开发人员，他们为您的组织工作（请参阅“审计跟踪”。我需要努力确保生产凭据的安全）
不要让人们访问服务器并将它们存储在 web.config 中（首先已经计划好了）

理想情况下：

理想情况下，我会在应用程序服务器上使用私钥进行加密/解密，但我不完全知道执行此操作的最安全方法，而不是 base64。我知道这不是加密。

.NET 本机堆栈中有哪些技术可以安全地加密/解密单个应用程序中可能包含特殊字符的字符串，以及该技术的示例用法是什么？

如果我知道名字和技术，我就不会问这个问题了。

¹_{使用 machine.config/web.config 来表示 .NET 堆栈中固有的内容。我愿意接受任何建议。}

【问题讨论】：

你检查过System.Security.Cryptography吗？这是Sample
别忘了数据库可能也有一些加密和解密的方法。
数据库加密！=有线加密，对吧？我不关心数据如何存储在磁盘上，我关心 select * 说什么......

标签： c# .net encryption

【解决方案1】：

在数据库表中保存连接信息总是不安全的。在某些时候，您将不得不解密密码，并将其发送到服务器。开发人员往往足够聪明，可以找出任何“隐蔽安全”的方法，并在某个时候得到密码。即使您在数据库中加密密码（不太难），只要您在某个时候将其传递给SqlConnection，您仍然需要在用户（开发人员）端的某处对其进行解密。

相反，安全地执行此操作的唯一方法是确保密码实际上永远不会接近开发人员（或其他任何人）。有几种方法可以解决这个问题：

使用外部安全提供程序，例如 Windows 身份验证。这意味着您根本不必使用任何用户名或密码。
创建某种隧道来发送任何所需的 SQL。如果您的开发人员只需要运行 SQL 命令，这非常容易，如果他们想使用像 Management Studio 这样的生产力工具，那就有点棘手了；然而，即使这是可行的——SQL 可以在 TCP 上正常运行，您应该能够很容易地模拟它。只有隧道服务器可以访问实际的凭据，您的开发人员只能拥有隧道服务器的凭据（并且仅限于此）。
使用链接服务器功能。这允许您将本地用户（您的开发人员）链接到远程用户（目标服务器上的 su 或其他）。它应该适用于所有常用的安全设置。

在这些中，我认为链接服务器可能是最好的。它们非常易于使用，可以由少数人管理，并且根本不发布密码。您还可以通过这种方式进行跨服务器的查询 - 对于维护工具来说非常方便:)

Windows 身份验证非常有用，但通常只在 LAN 上，因为我们谈论的是在一个域中拥有所有数据库服务器。 VPN 可以提供帮助，但这涉及到复杂的领域。

使用隧道并不一定是个坏主意，尽管我假设您会遇到一些问题，然后才能使其 100% 正常工作。最后，这就是链接服务器免费为您做的事情，那么为什么不使用它呢？

现在，如果您确实想采用加密理念，您可以从大量 .NET 支持的加密方案中进行选择。 AES 应该可以正常工作 - 它是不对称的，因此知道加密密钥并不意味着您可以解密数据（解密/私钥应该只存储在安全位置和维护应用程序服务器上，除了应用程序之外没有人本身可以访问；请注意，管理员可以访问任何内容，因此如果您的人员具有管理员权限，这将不起作用）。

例如，请参阅System.Security.Cryptography 中的AesManaged 类 - http://msdn.microsoft.com/en-us/library/system.security.cryptography.aesmanaged(v=vs.110).aspx

【讨论】：

因此，在与一些 DBA 讨论链接服务器时，他们都非常反对将链接服务器设置为不需要的生产服务器，因为跨链接的一个事务实际上可以停止您的生产如果出现问题，服务器，并且由于我将从开发环境连接以监控生产，因此我不想冒这个风险。
至于“它必须在某个时候解密，他们可以对此进行调试”，这要求他们能够拥有解密的密钥，并且如果我将密钥存储在外面应用程序，正如我在问题中提到的machine.config 所指出的那样，我不必担心他们知道密钥，因此他们无法调试并找到值。因此，我可以将这个特定应用程序的开发限制在少数获得解密密钥的人身上。
如果他们没有权限在服务器上运行 devenv，并且防火墙不允许连接到调试端口，那么他们将如何解密连接字符串中的内容？
@jcolebrand 关于远程交易足够公平。如果您只是进行合理的查询，我很确定这不是问题，但我可以理解这种不情愿。至于其余的，只要您信任的开发人员以外的任何人都可以在维护服务器（解密密钥所在的位置）上运行任何东西，您的方法就可以很好地工作。当然，只要您的维护应用程序中没有安全问题。您需要格外小心机器上运行的任何服务。
@jcolebrand 但无论如何，千万不要认为您可以将其隐藏在维护应用程序的开发人员面前。你必须信任某人。

【解决方案2】：

大多数应用程序只需要一个数据库，但您可以使用管理器创建任意数量的数据库。多个数据库相互独立。如果您的应用程序支持在多个用户之间切换，每个用户都有自己独立的内容和设置，您应该考虑为每个用户使用一个数据库。否则，通常最好坚持使用一个数据库。

【讨论】：

欢迎来到 StackOverflow！恐怕这不是一个真正的答案，而应该发表评论。尤其是考虑到它为 2014 年提出和回答的问题增加了什么价值。