由于上周发现了一个SQL注入漏洞，我的一些建议正在进行中。我们最近重新提交了一份应用程序，该应用程序存储了可能导致身份盗用的个人身份信息。虽然我们定期阅读一些数据，但受限制的数据我们每年只需要几次，然后只有两名员工需要它。
我已经阅读了SQL Server 2008的加密功能，但我不相信这是我想要的路线。我的问题最终归结为我们要么使用对称密钥，要么使用由对称密钥加密的不对称密钥。因此，似乎SQL注入攻击可能导致数据泄露。我意识到权限应该防止这种情况，权限也应该首先防止泄漏。
在我看来，更好的方法是对Web应用程序中的数据进行非对称加密。然后将私钥存储离线并拥有一个胖客户端，他们可以每年运行几次访问受限数据所需的数据，以便在客户端上解密数据。这样，如果服务器遭到入侵，我们不会泄漏旧数据，尽管取决于他们做什么，我们可能会泄漏未来的数据。我认为最大的缺点是需要重新编写Web应用程序并创建一个新的胖应用程序（以提取受限数据）。由于最近的问题，我可能会分配时间，所以现在是提出建议的适当时机。
你有更好的建议吗？你会推荐哪种方法？更重要的是为什么？
答案 0 :(得分：3)
SQL中的加密实际上只对保护服务器上的数据有好处，尽管这并不意味着它不重要。当你提到主要问题是注入攻击或类似问题时，我担心的是数据库是否使用单个帐户（SQL或其他）连接到数据库，这对于公共互联网站点来说是常见的。如果使用集成身份验证，或使用提供给应用程序的相同凭据连接到SQL，则SQL的加密可能正常。
但是，如果您使用单一登录，则SQL的加密将根据您的登录信息为您管理加密和解密数据。因此，如果您的应用程序遭到破坏，SQL可能无法为您保护该数据，因为它隐式解密它并且不知道任何错误。
您可能希望按照建议加密/解密应用程序中的数据，并将其作为字节存储在数据库中。这样您可以控制谁可以解密数据以及何时（例如，您可以将密钥分配给解密此数据的密钥给您提到的具有特定角色的少数员工）。您可以查看Microsoft的安全应用程序块或Bouncy Castle等，以获得良好的加密实用程序。请注意如何管理密钥。
<强>更新：
虽然您可能使用两个连接字符串：一个是普通的，没有加密数据的权限，另一个是拥有密钥和数据权限的连接字符串。然后让您的应用程序在用户拥有权限时使用适当的连接。当然，这很蹩脚。
答案 1 :(得分：1)
我们遵循的一些做法：
永远不要使用动态sql。这完全没必要。
无论＃1如何，始终参数化您的查询。仅这一点就可以摆脱sql注入，但还有很多其他入口点。
使用您可以访问数据库服务器的最低权限帐户。这通常意味着帐户不应该具有运行即席查询的能力（参见＃1）。它还意味着它不应该有权运行任何DDL语句（create，drop，..）。
不信任Web应用程序，更不用说从浏览器收到的任何输入。消毒一切。 Web App服务器会定期破解。
我们还处理了很多PII，并且对于如何访问数据以及由谁进行访问都非常严格（至于偏执）。记录通过服务器的所有内容。为确保发生这种情况，我们只允许通过存储过程访问数据库。 procs总是测试以查看用户帐户是否甚至被授权执行查询。他们进一步记录何时，谁和什么。我们根本没有任何批量删除查询。
我们的ID完全不可猜测。这适用于系统中的每个表。
我们不使用ORM工具。他们通常需要过多访问数据库服务器才能正常工作，我们对此并不满意。
我们每6个月对DBA和其他生产支持人员进行背景调查。严格控制和积极监控生产。我们不允许承包商出于任何原因访问生产，并且在允许进入代码库之前，所有内容都经过代码审查。
对于加密数据，允许特定用户访问解密密钥。经常更换这些密钥，如果可能的话每月更换一次。
计算机之间的所有数据传输都已加密。服务器和桌面之间的Kerberos; IIS和浏览器之间的SSL。
认识并构建大量数据窃取来自内部员工的事实。通过主动攻击系统，主动授予未授权用户访问权限，或通过在其计算机上安装垃圾（如IE 6）被动地进行操作。猜猜Google是如何被黑客入侵的。
您的情况中的主要问题是确定需要访问PII的所有部分。
信息如何进入您的系统？这里的主要内容是初始加密密钥存储在哪里？
答案 2 :(得分：0)
您的问题是密钥管理。无论你解决问题的方式有多少，你最终都会得到一个简单的基本事实：服务进程需要访问密钥来加密数据（这很重要，因为这意味着它无法获得根服务每当需要时，从人类输入的密码获取加密层次结构密钥）。因此，过程的妥协导致密钥的妥协。有一些方法可以混淆这个问题，但没有办法真正隐藏它。尽管如此，只考虑SQL Server进程本身的妥协可能会暴露这个问题，这比SQL注入漏洞要高得多。
您试图通过依赖公钥/私钥不对称来解决此问题，并使用公钥来加密数据，以便它只能由私钥的所有者解密。这样服务就不需要访问私钥，因此如果被破坏，它就不能用于解密数据。不幸的是，这仅在理论上有效。在现实世界中，RSA加密非常慢，不能用于批量数据。这就是常见的基于RSA的加密方案使用对称密钥加密数据并使用RSA密钥加密对称密钥的原因。
我的建议是坚持使用久经考验的方法。使用对称密钥加密数据。使用RSA密钥加密对称密钥。让SQL Server拥有并控制RSA私钥。使用权限层次结构来保护RSA私钥（实际上，没有什么比这更好的了）。使用module signing授予对加密过程的访问权限。这样ASP服务本身甚至没有加密数据的权限，它只能通过签名加密程序来实现。你的同事会冒很大的“创造性”管理/编码错误来妥协这样的方案，这远远不仅仅是“操作员错误”。系统管理员可以拥有更简单的路径，但任何旨在规避系统管理员的解决方案都将注定失败。