保护 SQL Server 2008R2 数据库

Question

我们将开发一个ASP.NET应用程序。它将在SQL Server 2008 R2安装中存储数据。大部分数据都是敏感的，因此安全性是首要考虑因素。

我们将在共享环境中托管此应用程序，并且设计目标是在发生盗窃时数据应该是不可读的。

我考虑以下设置： 使用TDE加密整个数据库。用户创建在SQL Server用户表中，并在用户通过Web界面登录时进行身份验证。 意图是如果有人接触到数据库，他们将无法使用数据。而且不需要在web.config文件中存储带有用户凭据的连接字符串。

您是否看到此方法的任何缺点？并且按照所述方式进行SQL Server身份验证会有多容易？

- Martin Wiboe

Answer 1

我认为在共享环境中使用TDE不是一个好主意。整个想法是使用内部加密主密钥（或证书的私钥）使加密/解密对外部用户透明，并防止在没有该密钥的情况下将加密数据库恢复到另一台服务器上。但共享托管服务器不是您的服务器，您无法控制对它的访问甚至不能经常更改或编写系统文件夹/文件或数据库。您应该与您的托管服务商咨询此事。但如果一个共享托管客户端被允许，则会有另一个相应的客户端，可以访问公共系统受限功能和区域。无论如何，托管服务提供商的任何人员都将可以访问您的数据库以及您的主密钥，以便在另一台服务器上进行恢复和读取。然后，TDE是SQL Server企业版的功能，而共享托管通常提供Express Editions。在共享企业版服务器上没有多大意义。

更新：@Martin Wiboe，我不确定您的意图和问题所在。数据库加密密钥使用服务主密钥进行加密（后者由Windows DPAPI保护），但在共享环境中没有意义，因为内存中和线路上传输的数据未加密，主服务密钥是实例（服务器）的密钥，因此应该在共享托管上共享。您无法“锁定”/“解锁”密钥，因为这是透明数据加密！请注意，如果其中一个数据库被TDE，则tempdb系统数据库将被加密。这对于共享托管来说没有多大意义。

1）软件生成的密钥可以被破解，只是时间门槛的问题。真正的安全性只能通过硬件生成和硬件存储的密钥来保证。因此，共享托管不予考虑 2）您可能希望考虑放弃DBMS加密并在客户端对数据进行加密。尽管此方法有缺点，即您无法在服务器端使用SQL Server进行搜索、优化传输、处理等。那么，在这样的DBMS中有什么意义呢？

最终，所有这些都归结为在共享托管服务器上使用没有多大意义。

- Gennady Vanin Геннадий Ванин

---

谢谢您的回答 :) 这很有道理 - 如果私钥存储在机器上，那么窃取机器的人将可以访问数据 - 无论是共享还是专用托管。是否没有办法以加密形式保留TDE密钥，只能由授权用户的密码解锁？这样即使对于有物理访问权限的人也需要密码？ - Martin Wiboe

谢谢您的解释。我认为最合理的做法是审查安全要求并找到一个明智的折衷方案。 - Martin Wiboe

Answer 2

这里有一个明显的问题。你的应用程序需要能够读取和理解数据。因此，如果有人能够干扰你的应用程序（嗅探它的通信、反编译它等），他可以使用同样的方法访问数据库。
即使你使用某些外部存储器来存储关键数据（如Windows数据保护API），你仍然需要以某种方式进行身份验证。因此，如果有人能够控制认证机制（例如Windows域），就可以获得相同的访问权限。

基本上，如果对手完全控制了环境（如果你使用共享主机并试图保护数据免受其工作人员的侵害，他们确实会这样做），那么你无法阻止他们想做任何事情。

这里有一些关于SQL Server加密的好概述：了解透明数据加密(TDE), 加密层次结构。无论如何，你仍然需要一种方式来存储对手无法访问的“最终启动密钥”，但仍然能够在你的应用程序中使用这个密钥。

- VladV

---

有没有办法通过 SQL Server 用户密码对此密钥进行加密？这样，只有在提供正确的用户凭据时，应用程序才能使用数据库。 - Martin Wiboe

是的，但您仍然需要将此密钥传递给应用程序。为了安全地执行此操作，您需要使用加密（以防止明文嗅探）、双端身份验证（以防止中间人攻击）和一致性验证（以防止代码注入）进行传输。即使如此，对手仍有可能通过内存转储来查找密钥。 - VladV

底线是，安全很难。我相信，支付合租或专用服务器的费用比开发和维护一个可以在共享环境中安全运行的应用程序更便宜、更安全。毕竟，如果你买不起服务器，可能没有那么多有价值的数据。 - VladV

Answer 3

我们将开发一个ASP.NET应用程序。它将在SQL Server 2008 R2安装中存储数据。大部分数据都是敏感的，因此安全性是首要考虑因素。我们将在共享环境中托管它，并且设计目标是在被盗情况下数据应该无法读取。

好的，我停止笑了。基本上你试图制作素食牛排。

要么安全是您的首要考虑因素，那么您不应使用共享托管方案，而应在经过认证的数据中心中运行，放在单独的锁定机架中，主机商没有管理访问权限。在这种情况下，您将使用更高版本的SQL Server，并使用磁盘加密+安全系统（TPM芯片）来确保在盗窃后数据在磁盘上是无法读取的。就是这样。

或者安全不是您关心的问题，那么您可以使用共享托管提供商。

其他任何东西都是胡说八道。这种“不，水刑不是酷刑，因为它不会造成身体伤害”的论证水平。

您的问题是：您无法阻止对数据的访问。因为您的应用程序必须能够读取未加密的数据，从而可以访问用于加密的密钥...任何闯入您的应用程序的人都可以访问这些密钥（这就是TPM的好处所在- 这是安全硬件，无法访问密钥）。

您可以围绕这个事实玩耍，提出各种有趣的论点，但如果数据被盗，这些论点在任何法律讨论中都不成立。而且您会因此显得很糟糕。

用户在SQL Server用户表中创建， 并且当用户通过Web界面登录时进行身份验证。 希望的是，如果有人到达数据库， 他们将无法使用数据。 而且无需在web.config文件中存储带有用户凭据的连接字符串。

好的，所以 - 我窃取了数据库。我还窃取了您的身份验证机制。您到底实现了什么？除了杀死您的搜索功能外？由于我拥有数据库，我拥有用户表并且可以以某种方式进行身份验证。如果我还窃取了应用程序，我几乎可以获取所有东西，甚至是代码。

除非您有特殊情况，例如没有应用程序密钥（如LastPass等不知道如何在服务器端自行解密数据的工具）。共享托管环境只不过是缺乏这种硬件水平。

- TomTom

---

谢谢你的回复，TomTom。我仍然认为你忽略了这个方面：假设数据库使用某些对称密钥K进行加密。对于每个用户，此密钥都存储在以用户密码加密的状态下。每个用户都能解锁数据库，但是没有帐户的对手只会得到加密密钥列表。 这种解决方案可能更容易受到密码分析攻击，但我认为它在密码学上是安全的。 良好的加密是基于只有授权方知道的某些秘密 - 而不是通过硬件模糊信息来隐藏信息。不过如果你还想笑，尽管笑吧。 - Martin Wiboe