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