当您需要存储 CC 或 SSN 等敏感数据时，您会：
1) 在应用程序中构建自己的加密例程，在配置文件的某处定义密钥，然后手动加密/解密进入数据库的数据。
2) 将所有问题推送到数据库，使用内置的数据库功能（我认为大多数供应商称之为透明数据库加密）。
您为自己的解决方案找到了哪些权衡取舍？与 TDE 相比，编写自己的例程是否表现不佳？是代码可维护性，还是相反的数据库供应商锁定问题？
【问题讨论】：
标签： asp.net database security encryption tde
我使用了多种加密技术，并且我相信使用经过验证的加密例程（即 .NET 库）在应用程序端进行加密更容易且更安全。
如果您对数据库进行加密，这意味着数据以未加密的形式传入和传出数据库。这可能允许在应用程序和数据库上的加密例程之间进行窥探/篡改。即使您将密钥存储在应用程序端，仍然需要在数据库端执行加密。如果数据库遭到破坏，您的数据将面临严重风险（想象一下有人在您的应用程序运行时运行分析器）。
如果您在应用程序中加密/解密，敏感数据（包括密钥）永远不会在应用程序服务器之外泄露。有人必须同时破坏 Web 服务器和数据库服务器才能访问您的所有数据。
另外，我强烈建议您不要使用自己的加密程序。您可能会犯一个会降低解决方案整体安全性的错误。
编辑：
还想添加另一个会影响您的决定的因素。您是否需要查询该加密数据？如果您在应用程序级别加密，则需要将数据带到应用程序、解密并从那里工作。随着数据集变得越来越大，这变得令人望而却步——而通过数据库加密，您可以在将数据发送回应用程序之前对其进行过滤。
【讨论】：
当您加密敏感数据时，您实际上是在限制有权访问密钥的人访问。然后问题就变成了密钥管理问题：确保只有授权的人/系统才能访问解密数据所需的密钥。
您当然应该使用标准的加密算法，现在已经很容易了，但您需要考虑的是您要防御哪些威胁，您将如何控制对密钥的访问，以及如何您可以控制对服务器的物理访问。
使用 TDE 可确保数据库的内容及其备份是加密的，对数据库的授权用户的影响最小。因此，任何可以使用有效凭据访问数据库服务器的人都可以看到未加密的数据。此外，任何 DBA 通常都可以访问密钥并能够看到未加密的数据。但是，获得异地备份的第三方将无法访问数据 - 这对于遵守法规要求非常重要。
另一方面，如果您在应用层进行加密，则可以使用只有应用服务器管理员才能访问的密钥。这可能会为您提供更多安全性，例如，如果数据库服务器和应用程序服务器管理员分开（例如不同组织的成员）。无权访问应用服务器密钥的 DBA 将无法查看数据。
在您原来的帖子中，您谈到在应用服务器的配置文件中隐藏密钥。从表面上看，这听起来就像把前门钥匙藏在门垫下面一样安全。如果您这样做，您需要考虑如何确保未经授权的人无法访问密钥。
【讨论】：
我同意 Mayo，但数据库中的加密可以简化整个系统的维护。
应用程序级别的加密需要您管理密钥、密钥的身份验证和授权阶段以及数据的可视化（根据 Mayo 编写的内容）。
如果您选择应用程序加密，您不仅要在开发阶段担心算法的正确性，还要在维护阶段担心算法的正确性。您必须实施单元测试以实现无回归。你必须管理加密算法的变化，因为也许你想要一个不同的更好的算法。
并且您必须确保加密数据将始终被解密。这不是一件显而易见的事情，因为软件有错误等等。 丢失的数据比清除的数据更糟糕 ;-)
当然，您可以使用知名的加密库，但剩下的所有事情对您来说都是一项艰巨的工作。
对 DB 的加密仅在 DB 中保护，但您可以考虑使用某种 SSL 与 DB 通信。我认为（但我不确定）TDE 实现了这种安全通信。
应用程序来自用户，一个不受信任的实体。您必须考虑应用程序中的数据丢失。为什么？如果我想从在应用程序级别或数据库级别实现数据加密的系统中窃取数据，使用相机来获取数据就足够了！很简单！
您必须考虑系统的安全性，但也要考虑功能。更多的是安全，更少的是功能。我希望我的考虑对你有用。
【讨论】：
符合 PCI-DSS 并不会免除您的法律责任...
目前只有两个州提供此类豁免： 华盛顿和明尼苏达...
DBA 将 TDE 推广为 PCI-DSS 解决方案 当心！
TDE 仅保护静态数据，而不保护传输中的数据或内存中的数据... 任何具有读取权限的人都可以使用任何工具读取所有数据...
恕我直言，TDE 与强大的应用程序级加密解决方案结合使用时效果很好... 作为单独使用 TDE 的独立解决方案，PCI QSA 将其购买为符合 PCI-DSS 的独立解决方案却不幸未能注意到……等到律师掌握了这个基本缺陷...
任何安全专家都会告诉你安全层是最好的方法....
【讨论】：