我们将开发一个ASP.NET应用程序。它将数据存储在SQL Server 2008 R2安装中。大多数数据都很敏感，因此安全性是首要考虑因素 我们将在共享环境中托管它，并且设计目标是在盗窃的情况下数据应该是不可读的。
我正在考虑以下设置：
使用TDE加密整个数据库。用户在SQL Server用户表中创建，当用户通过Web界面登录时，我们会对此进行身份验证
目的是如果有人进入数据库，他们将无法使用数据。并且不需要将具有用户凭据的连接字符串存储在web.config文件中。
你觉得这种方法有什么缺点吗？如上所述，对SQL Server进行身份验证有多容易？
答案 0 :(得分：3)
我不认为在共享环境中使用TDE是个好主意。
它的全部想法是使用您的INTERNAL上的加密主密钥（或证书的私钥）对外部用户进行加密/解密TRANSPARENT，由您，服务器保护并防止将加密数据库恢复到另一个没有那把钥匙的服务器 但共享托管服务器不是您的服务器，您无法控制对它的访问，甚至更频繁地甚至更改或写入系统文件夹/文件或数据库。你应该咨询你的主机 但是，如果一个共享主机客户端将被给予例外，那么将有另一个，分别访问共同系统受限功能和区域。
无论如何，来自hoster sysadmins或roundabout worker的任何人都可以使用您的主密钥访问您的数据库，以便在另一台服务器上恢复和读取它。
然后，TDE是SQL Server企业版的功能，共享主机通常提供Express Editions。分享Enterprise Ed没有多大意义。服务器
更新： @Martin Wiboe，
我不确定我是否遵循了您的目标和您所询问的内容。
数据库加密密钥使用服务主密钥加密（后者受Windows DPAPI保护）但在碎片环境中没有任何意义，因为内存和线路上的数据未加密且主服务密钥是一个例如（服务器）。
因此，它应该在共享主机上的所有用户之间共享
您无法“锁定”/“解锁”密钥，因为它是透明数据加密！
请注意，如果其中一个数据库是TDE-ed，那么tempdb系统数据库将被加密。这对共享主机没有多大意义。
1）
软件生成的密钥是可破解的，这只是持久性/期望与时间阈值的关系。
只有硬件生成和硬件存储密钥才能确保真正的安全性。因此，共享主机是不考虑的
2）
您可能需要考虑放弃DBMS加密并在客户端加密数据
虽然这种方法的缺点是您无法使用SQL Server进行搜索，优化服务器端的传输，处理等。那么，这样的DBMS有什么意义呢？
最终，这一切都归结为使用共享托管服务器
没有多大意义答案 1 :(得分：3)
这是一个明显的问题。您的应用程序需要能够读取和理解数据。因此，如果有人能够弄乱你的应用程序（嗅探它的通信，反编译它等等），他可以用同样的方式访问数据库。
即使您使用某些外部存储来存储关键数据（如Windows Data Protection API），您仍需要以某种方式对此存储进行身份验证。因此，如果任何人都能够控制身份验证机制（例如，Windows域），则可以获得相同的访问权限。
基本上，如果对手完全控制了环境（并且如果你使用共享主机并尝试保护你的员工的数据），你就无法阻止他们做任何他们想做的事情。
以下是SQL Server中加密的一些很好的概述：Understanding Transparent Data Encryption (TDE)，Encryption Hierarchy。在任何情况下，您仍然需要一种方法来存储对手无法访问的“终极开始键”，但仍然可以在您的应用中使用此键。
答案 2 :(得分：0)
我们将开发一个ASP.NET 应用。它将数据存储在 SQL Server 2008 R2安装。最 数据是敏感的，所以安全性 是一个主要问题。我们将成为 在共享环境中托管这个， 这是数据的设计目标 在这种情况下应该是不可读的 盗窃。
好的，我在这里停止了笑。基本上你会尝试制作素食牛排。
安全性是您的首要考虑因素，因此您不应使用共享主机方案，而应在经过认证的数据中心中运行，该数据中心位于密码锁定的机架中，且无需管理员访问。在这种情况下，您将使用更高版本的SQL Server并使用光盘加密+安全系统（TPM芯片）来确保在被盗后数据在光盘上不可读。点。
或者您不关心安全性，然后您可以使用共享托管服务提供商。
其他任何事情都是h .. “不，水刑不是折磨，因为它不会造成物理损害”的论证类型。
您的问题是：您无法停止访问数据。由于您的应用程序必须能够读取未加密的数据，因此可以访问使用tp加密的密钥...任何进入您的应用程序的人都可以访问密钥（这就是为什么TPM非常好 - 这是安全的硬件，没办法获取密钥的权限。）
你可以利用各种有趣的论点来解决这个问题，但是如果数据被盗，参数将不会在任何法律讨论中出现。而且你会看起来很糟糕。
用户是在SQL Server中创建的 用户表，我们进行身份验证 当用户登录时反对 网络界面。意图是 如果有人进入数据库， 他们将无法使用这些数据。 并且没有与用户的连接字符串 凭证将需要存储在 web.config文件。
好的，所以 - 我偷了数据库。我也窃取了你的身份验证机制。你究竟取得了什么？杀死你的搜索功能？正如我在数据库iH ave the users表中，我可以以某种方式作为用户进行身份验证。如果我也窃取应用程序，我会得到所有的东西，甚至是代码。
除非你有一个特殊情况，你没有应用程序密钥（像LastPass这样的东西不知道如何在服务器端解密你的数据）。共享托管环境没有适合的硬件级别。