Asp.net 数据库加密还是应用程序级加密？

当您需要存储敏感数据（如CCs或SSN）时，您是否：

1） 在应用程序中构建自己的加密例程，在配置文件中的某个位置定义一个密钥，然后手动加密/解密进入数据库的数据

2） 使用内置的数据库功能（我认为大多数供应商称之为透明数据库加密），将所有问题推到数据库上

---

您为您的解决方案找到了哪些折衷方案？与TDE相比，编写自己的例程是否表现不佳？代码的可维护性，或者反过来说DB供应商的锁定是一个问题吗？

我使用了各种加密技术，我相信使用经验证的加密例程（即网络库）在应用程序端进行加密更容易、更安全

如果对数据库进行加密，则表示数据以未加密的形式发送到数据库或从数据库发送。这可能允许在应用程序和数据库上的加密例程之间进行窥探/篡改。即使将密钥存储在应用程序端，也需要在数据库端执行加密。如果数据库受损，您的数据将面临严重风险（想象一下，当您的应用程序运行时，有人正在运行探查器）

如果在应用程序中加密/解密，则敏感数据（包括密钥）永远不会显示在应用程序服务器之外。要访问您的所有数据，必须有人同时破坏Web服务器和数据库服务器

另外，我强烈建议您不要使用自己的加密例程。您可能会犯一个会降低解决方案总体安全性的错误

编辑：

---

还想添加另一个影响您的决定的因素。你需要查询加密数据吗？如果在应用程序级别进行加密，则需要将数据带到应用程序中，然后进行解密，然后从那里开始工作。随着数据集变得越来越大，这就变得越来越禁止了——而使用数据库加密，您可以在数据发送回应用程序之前对其进行过滤。

我同意Mayo，但数据库中的加密可以简化整个系统的维护

应用程序级别的加密需要您管理密钥、密钥的身份验证和授权阶段以及数据的可视化（根据Mayo编写的内容）

如果选择应用程序加密，不仅在开发阶段，而且在维护阶段，都必须担心算法的正确性。您必须实现无回归的单元测试。您必须管理加密算法的更改，因为您可能需要一个不同的更好的算法

你必须确保加密的数据总是被解密的。这不是一件显而易见的事情，因为软件有漏洞等等丢失的数据比清除的数据更糟糕；-）

当然，你可以使用一个著名的加密库，但所有剩余的东西都是一个巨大的工作要为你做

加密到数据库中只保护在数据库中，但您可以考虑使用某种类型的SSL与DB通信。我认为（但我不确定）TDE实现了这种安全通信

应用程序是从用户（不受信任的实体）使用的。您必须考虑应用程序中的数据丢失。为什么？如果我想从一个在应用程序级或数据库级实现数据加密的系统中窃取数据，使用照相/摄像机获取数据就足够了！非常简单

---

你必须考虑系统的安全性，但也要考虑其功能性。安全性越高，功能性越差。我希望我的考虑将对您有所帮助。

当您加密敏感数据时，实际上是将访问权限限制在有权访问密钥的人。然后，问题就变成了密钥管理：确保只有经过授权的人员/系统才能访问解密数据所需的密钥

当然，您应该使用标准的加密算法，这在现在已经很容易了，但您需要考虑的是您要防范什么样的威胁，如何控制对密钥的访问，以及如何控制对服务器的物理访问

使用TDE可以确保对数据库及其备份的内容进行加密，对数据库的授权用户的影响最小。因此，任何可以使用有效凭据访问数据库服务器的人都可以看到未加密的数据。此外，任何DBA通常都可以访问密钥，并能够查看未加密的数据。但是，如果第三方持有异地备份，则将无法访问数据，这对于遵守法规要求非常重要

另一方面，如果在应用层加密，则可以使用仅由应用服务器管理员访问的密钥。例如，如果数据库服务器和应用程序服务器管理员分开（例如，不同组织的成员），这可能会给您带来更多的安全性。无权访问应用程序服务器密钥的DBA将无法查看数据

---

在最初的帖子中，您谈到了在应用服务器上的配置文件中隐藏密钥。从表面上看，这听起来像是把前门钥匙藏在门垫下的安全措施。如果您这样做，您需要考虑如何确保未经授权的人无法访问密钥。

遵守PCI-DSS并不能免除您的法律责任

目前只有两个国家提供这种豁免： 华盛顿和明尼苏达

DBA正在推广TDE作为PCI-DSS解决方案，当心

TDE只保护静止的数据，不保护传输中的数据或内存中的数据。。。 任何具有读取权限的人都可以使用任何工具读取所有数据

当我和你结合在一起时，我觉得你很好