最佳实践:在ASP.NET / SQL Server2008环境中保护个人身份数据

Question

由于上周发现了一个SQL注入漏洞，我的一些建议正在进行调查。我们最近重新开发了一个存储个人身份信息的应用程序，该应用程序的泄露可能会导致身份被盗。虽然我们定期读取一些数据，但受限的数据我们一年只需要几次，然后只有两个员工需要它。

我已经了解了SQL Server2008的加密功能，但我不相信这是我想要走的路。我的问题最终归结为我们要么使用对称密钥，要么使用由对称密钥加密的非对称密钥。因此，SQL注入攻击似乎会导致数据泄漏。我意识到权限应该防止这一点，首先权限也应该防止泄漏。

在我看来，更好的方法是对web应用程序中的数据进行非对称加密。然后离线存储私钥，并有一个胖客户端，他们可以在一年中运行访问受限数据所需的几次，以便可以在客户端上解密数据。这样，如果服务器被攻破，我们不会泄露旧数据，尽管根据他们所做的事情，我们可能会泄露未来的数据。我认为最大的缺点是这将需要重新编写web应用程序并创建一个新的fat应用程序(以提取受限制的数据)。由于最近的问题，我可能可以得到分配的时间，所以现在是提出建议的合适时机。

你有更好的建议吗？你会推荐哪种方法？更重要的是为什么？

Answer 1

SQL中的加密实际上只对保护驻留在服务器上的数据有好处，尽管这并不意味着它不重要。当您提到主要关注的是注入攻击或类似攻击时，我关注的是数据库是否使用单个帐户(SQL或其他)连接到数据库，这对于公共互联网站点来说是很常见的。如果您使用集成身份验证，或者使用提供给应用程序的相同凭据连接到SQL，那么SQL的加密可能工作得很好。

但是，如果您使用的是单点登录，SQL的加密会根据您的登录为您管理数据的加密和解密。因此，如果您的应用程序遭到破坏，SQL可能无法为您保护这些数据，因为它会隐式解密这些数据，并且不知道有什么问题。

您可能希望按照您的建议对应用程序中的数据进行加密/解密，并以字节的形式存储在数据库中。这样，您就可以控制谁可以解密数据以及何时解密数据(例如，您可以将解密数据的密钥分配给您提到的少数几个担任特定角色的员工)。您可以查看Microsoft的安全应用程序块或Bouncy Castle等，以获得良好的加密实用程序。只需小心您如何管理密钥。

更新

尽管您可能会使用两个连接字符串:一个是普通的，没有加密数据的权限，另一个是具有密钥和数据权限的连接字符串。然后，当用户拥有相应权限时，让您的应用程序使用适当的连接。当然，这是相当笨拙的。

Answer 2

我们遵循的一些实践：

1. 从不使用动态sql。它完全是#1的unnecessary.
2. Regardless，总是参数化你的查询。仅此一项就可以消除sql注入，但还有许多其他入口点。
3. 使用您可以访问数据库服务器的最低特权帐户。这通常意味着该帐户不应该具有运行即席查询的能力(参见#1)。这也意味着它不应该拥有运行任何DDL语句(create、drop、..)的权限。
4. 不信任web应用程序，更不用说从浏览器收到的任何输入了。清理所有东西。Web App服务器经常被破解。
5. 我们也要处理大量的个人信息安全问题，并且对数据的访问方式和访问者都非常严格(甚至偏执)。通过服务器传入的所有内容都会被记录下来。为了确保这种情况发生，我们只允许通过存储过程访问数据库。procs总是测试用户帐户是否被授权执行查询。此外，它们还记录了何时、谁和什么。我们根本没有任何批量删除查询。
6. 我们的ID是完全不可猜测的。这适用于系统中的每个表。
7. 我们不使用ORM工具。它们通常需要对数据库服务器进行过多的访问才能正常工作，我们对此并不满意。
8. 我们每6个月对数据库管理员和其他生产支持人员进行一次背景调查。对生产的访问受到严格控制和积极监控。我们不允许承包商以任何理由访问产品，并且在允许进入代码库之前，所有内容都经过代码审查。
9. 对于加密的数据，允许特定用户访问解密密钥。经常更改这些密钥，如果机器之间的possible.
10. ALL数据传输是加密的，则每月更改一次。服务器和桌面之间的Kerberos；IIS和browsers.
11. Recognize之间的SSL；以及架构师之间的SSL，因为许多数据失窃来自内部员工。通过主动入侵系统，主动授予未经授权的用户访问权限，或者被动地在他们的计算机上安装垃圾程序(如IE6)。猜猜谷歌是怎么被黑客入侵的。

在您的情况下，主要问题是确定需要访问PII的所有部件。

比如信息是如何进入你的系统的？这里的主要问题是初始加密密钥存储在哪里？

Answer 3

您的问题是密钥管理。不管你用多少方法来解决这个问题，你最终都会得到一个简单的基本事实:服务进程需要访问密钥来加密数据(这是一个重要的后台服务，因为这意味着无论何时需要，它都不能从人工输入的密码中获得加密层次密钥的根)。因此，过程的折衷导致密钥的折衷。有办法混淆这个问题，但没有办法真正隐藏它。然而，为了正确地看待这个问题，只有SQL Server进程本身的危害才能暴露这个问题，这个问题比SQL注入漏洞的门槛要高得多。

您试图通过依赖公钥/私钥不对称来规避此问题，并使用公钥对数据进行加密，使其只能由私钥的所有者解密。因此，该服务不需要访问私钥，因此，如果私钥被泄露，则该私钥不能用于解密数据。不幸的是，这只在理论上有效。在现实世界中，RSA加密速度太慢，不能用于批量数据。这就是为什么常见的基于RSA的加密方案使用对称密钥来加密数据，并使用RSA密钥加密对称密钥。

我的建议是坚持使用久经考验的方法。使用对称密钥对数据进行加密。使用RSA密钥加密对称密钥。让SQL Server拥有和控制RSA私钥。使用权限层次结构来保护RSA私钥(实际上，没有比这更好的方法了)。使用module signing授予对加密过程的访问权限。这样，ASP服务本身甚至没有加密数据的特权，它只能通过签名的加密过程来做到这一点。你的同事会犯下重大的“创造性的”管理/编码错误来折衷这样的方案，这比单纯的“操作员错误”要严重得多。系统管理员会有一条更容易的途径，但任何旨在绕过系统管理员的解决方案都是注定要失败的。