SQL Server 2008 加密的简单实现

Question

我正在考虑使用一些 SQL Server 2008 的加密。

我在 MSDN 上阅读了以下文章：

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

Q1a：是否为每个数据库实例创建了主密钥密码？

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

Q1b：如果我在 Server1 上创建主密钥密码并加密表中的列。当我备份该数据库 (.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 : 我应该担心谁可以打开和关闭对称密钥？我将 SQL Server 2008 用于 ASP.NET Web 应用程序。数据库托管在 Windows Server 2008 VPS 上。我通常会创建一个 SysAdmin 类型的数据库用户，并从 web.config 文件中提供连接详细信息。我将是唯一可以访问 VPS 的人，所以我不需要考虑其他开发人员访问数据库。但是，如果 VPS/Windows 安全被破坏并且攻击者获得了对 VPS 和/或数据库的访问权限。他们会破坏我的数据库和信息吗？

Answer 1

Q1a：是否为每个数据库实例创建了主密钥密码？

A1a：假设问题的真正意思是“主密钥是按 DB 创建的吗？” " 那么答案是肯定的。每个数据库都有一个不同的主密钥。还有一个叫做服务主密钥的东西，它是每个 SQL Server 实例。

Q1b：当我备份那个数据库 (.bak) 时，我能将数据库还原到另一个 Server2 吗？

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

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

A2：不可以。所有这些对象都是数据库的一部分，它们与数据库一起恢复。备份单个密钥的特定需求可能源于操作要求（例如密钥托管）。

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

A3：需要打开的键必须在会话中打开。一旦打开，它们将保持打开状态，直到明确关闭或会话断开连接。“打开”键仅在打开它的会话中是“打开”的。

Q4：我是否应该担心谁可以打开和关闭对称密钥？...

A4：现在这是真正的问题。您确实有两种选择，它们对应于两种不同的情况：

场景 A：当服务需要访问加密数据而不要求用户提供数据密码时。这是绝大多数情况。在这种情况下，服务需要以某种方式打开密钥。解决方案是SQL Server使用服务主密钥加密数据库主密钥，数据库主密钥用于加密证书的私钥，私钥用于加密对称密钥，对称密钥加密数据。SQL Server本身可以访问此链之后的任何数据，因为它可以访问服务主密钥。在这种情况下，数据仅受到加密保护，以防意外媒体丢失：丢失的带有数据库的笔记本电脑，或带有备份文件数据库的未正确处置的 HDD 等。对于所有其他威胁，数据不受加密保护，仅受访问控制保护：因为 SQL Server 本身可以无需用户密码即可解密数据，任何具有足够权限的用户都可以在不知道密码的情况下访问数据。换句话说，受感染的 ASP 应用程序可能允许访问加密数据。需要注意的是，加密的根是存储在 ASP Web 应用程序本身上的一些秘密的场景只是对此的一个（设计糟糕的）变体，不会改变任何东西。

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

您必读的内容：加密层次结构。