Server 2008加密的简单实现

Question

我正在考虑使用一些Server 2008's加密。

我阅读了关于MSDN的以下文章：

• http://msdn.microsoft.com/en-us/library/ms179331.aspx

Q1a:主密钥密码是每个DB实例创建的吗？

IF NOT EXISTS 
    (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
    CREATE MASTER KEY ENCRYPTION BY 
    PASSWORD = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
GO

Q1b:如果我在Server1上创建主密钥密码并加密表上的列。当我备份该DB (.bak)时，我将能够将数据库恢复到另一个Server2，还是必须使用相同的密码在Server2上创建一个主密钥？

Q2:如果我想恢复到另一台服务器，我需要备份证书、主密钥还是对称密钥？

CREATE CERTIFICATE HumanResources037
   WITH SUBJECT = 'Employee Social Security Numbers';
GO

CREATE SYMMETRIC KEY SSN_Key_01
    WITH ALGORITHM = AES_256
    ENCRYPTION BY CERTIFICATE HumanResources037;
GO

Q3:什么时候应该打开对称密钥？应该在每个选择之前完成，然后关闭吗？即在存储过程开始时打开，然后关闭。

-- Open the symmetric key with which to encrypt the data.
OPEN SYMMETRIC KEY SSN_Key_01
   DECRYPTION BY CERTIFICATE HumanResources037;

Q4:我应该担心谁能打开和关闭对称密钥吗？我将Server 2008用于ASP.NET web应用程序。数据库托管在WindowsServer2008VPS上，我通常创建一个SysAdmin类型的DB用户，并从web.config文件中提供连接详细信息。我将是唯一能够访问VPS的人，所以我不需要考虑其他开发人员访问DB的问题。但是，如果VPS/Windows安全遭到破坏，攻击者获得了对VPS和/或DB的访问权限。他们能破坏我的数据库和信息吗？

Answer 1

Q1a:主密钥密码是每个DB实例创建的吗？

A1a:假设这个问题真的意味着“主键是为每个DB创建的吗？”那么答案是“是的。每个DB都有一个不同的主键。还有一个叫做服务主键的东西，就是每个Server实例。”

Q1b:当我备份那个DB (.bak)时，我能将DB恢复到另一个Server2吗？

A1b:是的。还原数据库中的主密钥可以使用原始密码打开。然后，可以将Server2服务主密钥加密添加到还原的DB主密钥中。

Q2:如果我想恢复到另一台服务器，我需要备份证书、主密钥还是对称密钥？

A2:没有。所有这些对象都是数据库的一部分，它们与数据库一起被还原。备份单个密钥的特定需求可能来自操作需求(例如。密钥托管)。

Q3:什么时候应该打开对称密钥？

A3:需要打开的键必须在会话中打开。一旦打开，它们将一直打开直到显式关闭或会话断开。“打开”键只有在打开它的会话中才是“打开的”。

Q4:我应该担心谁能打开和关闭对称密钥吗？

A4:这才是真正的问题。您实际上有两种选择，它们对应于两种不同的场景：

场景A:当服务需要访问加密数据而不要求用户提供数据密码时。这是绝大多数案件。在这种情况下，服务需要以某种方式打开密钥。解决方案是: Server使用服务主密钥加密数据库主密钥，数据库主密钥用于加密证书的私钥，私钥用于加密对称密钥，对称密钥加密数据。Server本身可以访问该链中的任何数据，因为它可以访问服务主键。在这种情况下，数据只受到加密保护，以防意外的媒体丢失:丢失的笔记本电脑上有数据库，或者HDD上有备份文件的数据库等等。对于所有其他威胁，数据没有加密保护，只受访问控制的保护:由于SQL Server本身可以解密需要用户密码的数据w/o，任何拥有足够权限的用户都可以访问知道密码的数据w/o。换句话说，受损的ASP应用程序可能允许访问加密的数据。请注意，在这种情况下，加密的根是存储在ASP web应用程序本身上的某个秘密，这只是一个(设计很差)的变体，不会改变任何东西。

场景B:当服务要求用户提供密码时。密码必须来自最终用户。在web应用程序中，用户必须在浏览器中键入表单中的密码，然后通过SSL通道发送给ASP应用程序，ASP应用程序将其传递给SQL会话(同样是在SSL通道上)，现在SQL可以使用此密码解密数据。这种情况对于租户提供数据访问密码的多租户应用程序来说是典型的。在这种情况下，数据被加密保护以防止未经授权的访问，因为SQL Server本身或中间ASP web应用程序根本不知道密码。即使对拥有所有特权的syadmin用户来说，也不可能读取数据。数据可以随意移动，并且仍然是不可预知的，因为它同样只能由在加密链根部具有密码知识的最终用户读取。请注意，在此场景中，密码在中间的某个地方“保存”而不是由最终用户提供的任何“快捷”偏差都会立即退化为第一个场景A。

您必须阅读：加密层次。