保护代码中的数据库连接字符串和其他敏感设置

本文假定读者熟悉 C# 和 Visual Basic .NET

摘要

保护应用程序机密（如数据库连接字符串和密码）要求仔细考虑许多相关因素，如数据的敏感程度、可以获得访问权限的人以及如何在安全性、性能和可维护性之间获得平衡，等等。本文解释了数据保护的基础知识，并比较了几种可用于保护应用程序设置的技术。作者探讨了要避免的事项，如在源代码中隐藏密钥，以及使用“本地安全机构”。此外，他还提出了一些有效的解决方案，如数据保护 API。

本页内容

在开发人员新闻组和在线论坛上，经常讨论有关保护数据库连接字符串、密码和其他敏感应用程序设置的问题。尽管大多数专业安全人员都同意使用软件无法隐藏机密的看法，但仍然有某些已知技术可以为大多数类型的应用程序提供充足的保护。所有的现有数据保护方法都基于三种基本技术：隐藏、访问控制和加密。这些技术可以单独使用，也可以结合使用。不管您决定是选择一种现有技术、还是构建自己的数据保护机制来保护应用程序机密，您的基本选择都局限于这三种方法。

在本文中，我将探讨数据保护的基础知识，并比较几种能够帮助您更好地管理机密数据的技术。我将指出适合使用这些技术的情况，以及应该避免使用这些技术的情况。我还将提供可以帮助您实现数据保护机制的代码示例、工具和 API 的参考。

数据隐藏

数据隐藏有时称为隐藏式保全。如果依赖这种技术，您就假设了只有您知道敏感信息存储的地方，并希望其他人都无法找到这些信息。此处的忠告是，应用程序也必须知道如何访问数据，因此是否能够保证机密的安全将在很大程度上取决于应用程序保护这种知识的能力。

最常见的隐藏敏感应用程序设置的地方包括应用程序源代码、配置文件和 Windows? 注册表。数据也可以存储在诸如 IIS 元数据库、通用数据链接 (UDL) 文件、自定义文件之类的怪异位置。

简单地隐藏数据通常只能提供很少的（如果存在）安全性。大多数情况下，黑客非常容易发现您的机密。例如，通过监视正在运行的应用程序所执行的系统更改（请参见图 1），入侵者可能会发现数据的位置。这可以通过实用工具（如 上的 regmon、fileman 和 diskmon）来实现。

如果您在应用程序中定义密钥，那么除了将程序集模糊处理以外，请不要试图在源代码中存储实际的密钥字节。相反，应使用持久的特征来实现密钥生成逻辑，如加密算法、密钥大小、通行码、初始化向量以及 salt（请参阅 中的示例）。这将引入一个附加的间接层，这样就不能通过简单地将符号从应用程序二进制代码中转储出来以得到密钥。只要不更改密钥生成逻辑和密钥特征，生成的密钥保证是相同的。不将静态字符串作为密钥生成特征可能也是个不错的想法，但还是稍逊于即时构建它们。还有一个建议是，用对待数据存储的方式来对待程序集，也就是应用合适的 ACL。只有当其他数据保护技术都不起作用，并且唯一的备选方法是不加密敏感数据时，才可以将该选项作为最后的解决办法。

独立存储

独立存储有时被认为是保护数据的方法。它可让您限制对应用程序程序集的数据访问。虽然该选项能有些帮助，但是由于独立存储不使用加密，因此不建议使用它来保护敏感数据；它更适于存储用户特定的应用程序设置。要存储用户特定的敏感应用程序数据，请将 DPAPI 和独立存储结合使用。

小结

对于保护敏感应用程序数据来说，没有完美的解决方案。现有的软件技术都不能保证绝对的安全。我们的目标是，在那些对应用程序有效并符合安全要求的方案中挑选出最好的、或者“危害最小”的选项。理解各种技术和技巧如何提供数据保护，将有助于您评估安全漏洞并防止您错误地产生安全感。

无论您是决定构建还是购买数据保护解决方案，请确保它使用强加密算法、为加密密钥提供合理的保护，以及限制对加密数据的访问。尽管没有软件解决方案可以保证应用程序数据的绝对安全，但是正确的方法可以帮助您避免最常见的安全隐患类型。