利用 SQL Server 2005 提高数据安全性

利用 SQL Server 2005 加密帮助保护数据

下载 利用 SQL Server 2005 提高数据安全性 背景形势 最近出台的联邦、州和国际法律规定了存储个人身份信息的公司应遵从的监管要求，促使 Microsoft IT 对现有数据库安全框架进行了重新评估。 解决方案 • Microsoft SQL Server 中的内置密钥管理及列级加密功能，使 Microsoft IT 可以开发多种不同的加密策略，以提高 Microsoft IT 业务线应用程序领域中敏感数据的安全性。 优点 • Microsoft SQL Server 2005 密钥管理使创建简单易用且稳定可靠的加密密钥管理框架成为可能。 • 内置列级加密功能为应用程序中敏感数据的加密提供了灵活性，不再需要考虑加密整个存储库的开销。 • SQL Server 2005 的内置加密特性允许在视图内进行数据解密，并可方便访问加密的数据。 • SQL Server 2005 中的全功能密钥管理层次结构，提供了创建数字签名的存储过程来简化数据加密的能力。 产品与技术 Microsoft SQL Server 2005

本页内容

	执行摘要
	导言
	应用程序环境
	解决方案：SQL Server 2005 加密
	FeedStore
	工资管理报告系统
	Metropolis
	最佳方法
	结束语
	更多信息
	附录：使用加密的场合

执行摘要

与许多大公司一样，Microsoft 对现有数据库安全框架进行了仔细分析，目的是确保其安全框架符合政府最近提出的监管要求，例如 Sarbanes-Oxley Act of 2002（2002 年的《萨班-奥西利法案》），这些监管要求规定了存储个人身份相关信息的条件。这些要求不仅影响存储在数据库中的数据，而且也影响数据传送机制、数据库授权和访问控制以及数据库审核。

根据上述的数据库分析，Microsoft Information Technology (Microsoft IT) 认识到敏感数据重复存在于整个 Microsoft IT 业务线 (LOB) 应用程序领域。这些数据的重复是由公司日常操作过程中的数据传送和复制造成的。

Microsoft IT 针对此分析结果采取了一定措施，开发了多种用于减少敏感数据的重复和提高 Microsoft IT LOB 应用程序领域中个人身份相关信息安全性的策略。这些策略以 Microsoft® SQL Server™ 2005 含有的新安全特性和功能为基础。

Microsoft IT 下属的 Enterprise Data Services 小组建立了一个名为 FeedStore 的 2 TB 中央信息存储库。该小组开发了一个用于提高通过 FeedStore 传递的个人身份相关信息安全性的试验项目。该项目需要建立一个名为“数字资产存储库”的中央加密存储库，用来存储高敏感度的个人身份相关信息。Enterprise Data Services 设计该“数字资产存储库”的目的是通过使用 SQL Server 2005 中的密钥管理和列级加密功能，在一个中央位置对敏感数据进行加密。该试验项目在业务和功能上具有明确目标，可帮助消除或减少 Microsoft IT LOB 应用程序中的数据重复。

Microsoft IT 下属的 Financial IT 部门建立了“工资管理报告系统”(PCRS) 应用程序。该部门开发了一个安全框架，可通过加密存储在 PCRS 数据仓库中的敏感数据提高数据安全性。另外，Microsoft IT 下属的 Services IT 部门使用 SQL Server 2005 的密钥管理功能和列级加密功能，建立了一个功能强大（可靠而稳定）的加密机制，对 Metropolis LOB 应用程序中的数据进行加密。

本文档将分享 Microsoft IT 在上述安全策略和 SQL Server 2005 加密功能方面的经验。由于目前许多 SQL Server 2005 试验项目正在进行当中，Microsoft IT 在 Microsoft IT LOB 应用程序领域内的数据合并和加密方面获得了许多宝贵经验和最佳方法。由于 Microsoft IT 的要求最具挑战性，因此 Microsoft IT 开发的策略以及其通过部署 SQL Server 2005 获得的经验教训，应该对希望部署基于 SQL Server 2005 的加密和密钥管理框架的公司具有指导意义。

本文档适用于企业业务决策者、技术决策者、IT 架构师、数据库开发人员以及部署管理人员。尽管本文档提供的建议以先行采纳者 Microsoft IT 的经验为基础，但其宗旨并非要提供一个程序性指导。每个企业的环境都具有与众不同的独特性。因此，每个组织都应灵活掌握这些信息，以满足其独特的要求。

注意：出于安全原因，本文样例中使用的内部资源名称、组织名称和内部开发的保密文件的名称，并不代表 Microsoft 内部使用的真实资源名称，它们仅供说明之用。

返回页首

导言

企业决策者经常要求提供有关在 Microsoft 内部使用 Microsoft 产品和技术的经验的信息。Microsoft 内部的 IT 部门不仅提供 IT 服务，还扮演着每个新发布的服务器和业务效率软件的第一个客户。由于 Microsoft IT 的要求在技术上最具挑战性，因此 Microsoft IT 用于部署这些技术的方法以及 Microsoft IT 从这些部署中获得的经验，经常可以为希望部署 Microsoft 产品的其他公司提供有意义的部署和操作指导。

另外，由于 Microsoft IT 使用过 Microsoft 新产品从预发布版本到商用 (RTM) 版本的所有版本，因此 Microsoft IT 在产品的功能和特色方面为 Microsoft 提供了许多宝贵的反馈信息。这些反馈信息促进了其软件产品的改进。这些反馈信息还为 Microsoft 客户和合作伙伴成功部署这些产品和技术提供了帮助。

监管要求概述

与其他公司一样，为确保其安全框架符合当前美国联邦、州和国际法律关于遵从个人安全信息的监管要求的规定，Microsoft 一直在对其当前的安全框架进行重新评估。在美国，这些规定包括以下联邦和州的法律：

另外，国际法规也规定了存储个人身份相关信息的公司应遵从的监管要求。这些规定包括：

存储客户个人信息的组织必须认真理解这些新监管要求的含意。这些监管要求影响以下所有数据库操作：

各公司必须遵守有关个人身份信息的监管要求。要提供高效而经济的数据保护，企业的 IT 部门也许不得不重新考虑如何存储和管理组织的敏感数据。

数据加密概述

在评估安全框架的过程中，企业的 IT 部门可能需要重新评估整个组织的安全性。这些安全措施可包括密码策略、审核策略、数据库服务器隔离以及应用程序验证和授权控制。但是，保护敏感数据的最后一个安全屏障通常是数据加密。

加密是一种帮助保护数据的机制。加密通过将数据打乱，达到只有经过授权的人员才能访问和读取数据的目的，从而帮助提供数据的保密性。当原始数据（称为明文）与称为密钥的值一起经过一个或多个数学公式处理后，数据就完成了加密。此过程使原始数据转为不可读形式。获得的加密数据称为密文。为使此数据重新可读，数据接收方需要使用相反的数学过程以及正确的密钥将数据解密。

然而，此种数据保护方法会增加计算机处理器时间和存储需求方面的成本。较长的加密密钥比较短的加密密钥更有助于提高密文的安全性。不过，较长的加密密钥的加密/解密运算更加复杂，占用的处理器时间也比较短的加密密钥长。另外，加密还会增加目标（加密）数据的大小。

有以下两种主要加密类型：

对称加密

对称加密使用相同的密钥加密和解密数据。对称加密使用的算法比用于非对称加密的算法简单。由于这些算法更简单以及数据的加密和解密都使用同一个密钥，所以对称加密比非对称加密的速度要快得多。因此，对称加密适合大量数据的加密和解密。图 1 显示了对称加密流程。

图 1 对称加密流程

对称加密的主要缺点之一是使用相同的密钥加密和解密数据。因此，所有的数据发送方和接收方都必须知道或可以访问加密密钥。这使得组织必须在其环境中考虑安全管理问题和密钥管理问题。存在安全管理问题的原因是由于组织必须将此加密密钥发送给所有要求访问加密数据的一方。组织必须考虑的密钥管理问题包括密钥生成、分发、备份、重新生成和生命周期。

对称加密提供对加密数据的授权。例如，通过使用对称加密，一个组织可以合理地认为只有能访问共享加密密钥的被授权方才能将密文解密。然而，对称加密不提供认可功能。例如，在有多方可以访问共享加密密钥的情况下，对称加密不能确定数据的具体发送方。对称加密使用的加密算法包括：

非对称加密

非对称加密使用两个具有数学关系的不同密钥加密和解密数据。这两个密钥分别称为私钥和公钥。它们合称为密钥对。非对称加密被认为比对称加密更安全，因为数据的加密密钥与解密密钥不同。但是，由于非对称加密使用的算法比对称加密更复杂，并且还使用了密钥对，因此当组织使用非对称加密时，其加密过程比使用对称加密慢很多。图 2 显示了非对称加密流程。

图 2 非对称加密流程

在非对称加密中，只有一方持有私钥。此方称为主体。所有其他各方都可以访问公钥。通过公钥加密的数据只能通过私钥解密。反之，通过私钥加密的数据只能通过公钥解密。因此，此种加密提供了保密和认可两种功能。

组织可以利用此种加密方法，通过使用公钥加密数据来提供授权。此密钥是公开的。因此，任何人都可以将数据加密。但是，由于只有主体持有私钥，因此该组织可以合理地认为，只有预期的接收方才能解密和查看加密的数据。

组织可以利用此种加密方法，通过使用私钥将数据加密来提供验证。只有主体持有此密钥。不过，任何人都可以将该数据解密，因为将此数据解密的公钥是公开的。因此，如果接收方可以使用公钥将此数据解密，就可以合理地认为只有主体才是将数据加密的一方。非对称加密使用的加密算法包括：

混合加密

混合加密是一种加密方案，在该方案中，数据加密通过对称加密和非对称加密的组合实现。混合加密方法利用了上述两种加密方法的优点，从而帮助确保只有预期的接收方才能读数据。

在混合加密方案中，组织将对称加密与一个随机生成的密钥结合使用来加密数据。此步骤利用了对称加密速度快的优点。然后，该组织通过使用非对称密钥对的公钥，将此对称加密密钥加密。此步骤利用了非对称加密安全性更高的优点。经过加密的数据与经过加密的对称密钥一起发送给数据接收方。图 3 显示了混合加密流程。

图 3 混合加密流程

要将数据解密，接收方首先需要使用非对称密钥对的私钥，将对称加密密钥解密。然后，接收方使用经过解密的对称密钥将数据解密。图 4 说明了混合解密流程。

图 4 混合解密流程

加密注意事项

一个组织在决定是否要将数据加密时，必须考虑执行加密和解密可能增加的处理器负荷。此外，该组织还必须考虑加密后的数据所占用的存储空间。数据占用的存储空间的大小取决于该组织使用的算法、密钥的大小以及组织加密的明文大小。

虽然一个组织实施加密时必须考虑性能问题和存储问题，但最重要的还是密钥管理问题。组织用于将数据加密和解密的加密密钥是其数据安全框架中至关重要的部分。为确保只有经过授权的用户才能查看加密的数据，组织必须采取措施，对加密密钥进行管理、存储、保护和备份。

返回页首

应用程序环境

Microsoft IT 为 Microsoft 提供全球 IT 服务。这些服务包括对 57,000 名员工、200,000 多台个人计算机以及 8,000 多台服务器的支持服务。这些服务涵盖了从服务器和网络操作到软件部署和最终用户技术支持。另外，Microsoft IT 每月还处理 100,000 多个与安全相关的问题。

Microsoft IT 拥有 300 多个 LOB 应用程序，处理公司日常运作中的敏感数据。Microsoft IT 的目标是在整个 LOB 应用程序领域内提供数据在存储、传输、处理或在系统或报告中显示时的数据安全性。因此，Microsoft IT 目前正在将其所有与数据库相关的 LOB 应用程序升级至 SQL Server 2005。此次升级将利用 SQL Server 2005 中与管理、安全和性能有关的新特性和功能。

为满足以下方面的要求，Microsoft IT 对其数据库存储解决方案进行了分析（并在继续分析）：

本文档将讨论 Microsoft IT 为上述分析所涵盖的以下三个数据库系统而开发并在继续开发的加密框架：

由于涉及的数据量、应用程序数量和特定数据库环境的不同，Microsoft IT 中分管上述各数据库系统的 IT 部门必须在分析其管理的特定应用程度环境的过程中，制定不同的加密策略和实施过程。不过，这些策略的共同点是都使用 SQL Server 2005 来实施密钥管理层次结构和列级加密。

返回页首

解决方案：SQL Server 2005 加密

SQL Server 2005 含有许多与安全相关的特性，可以帮助保护组织中的数据。SQL Server 2005 包含密码策略实施、强大的验证功能和精细的层次权限模型。SQL Server 2005 还含有一个内置数据加密功能。此列级加密功能通过一个用来管理加密密钥的集成和分层的基础结构得到增强。内置加密函数以及应用程序编程接口 (API) 使组织可以更容易地建立加密安全框架。

内置加密功能

密钥管理是加密安全框架中最重要的环节。SQL Server 2005 支持三种加密类型。每种类型使用一种不同的密钥，并且具有多个加密算法和密钥强度，如下所述：

加密密钥层次结构

SQL Server 2005 实施的框架可以通过使用加密密钥层次结构帮助保护加密密钥（如图 5 所示）。在此层次结构中，每个层次将对其下面的层次进行加密。

图 5 SQL Server 2005 加密密钥层次结构

“数据保护 API”(DPAPI) 位于此加密密钥层次结构的顶层。DPAPI 是一对函数调用，可为用户和系统进程提供操作系统级的数据保护服务。由于此 API 是 Microsoft Windows® 操作系统的一部分，因此应用程序可以使用 DPAPI 加密数据，但不必使用调用 DPAPI 函数的代码以外的任何加密代码。DPAPI 是一种基于密码的数据保护服务。因此，DPAPI 要求提供密码以加密数据。

注意：这里使用的密码是调用加密函数的帐户的密码。因此，实施加密的开发人员不必指定其他密码。

SQL Server 2005 Service Master Key（服务主密钥）是在管理员安装 SQL Server 2005 时，cryptGenKey 函数自动生成的对称密钥。DPAPI 使用借以运行 SQL Server 2005 的帐户的密码，生成 DPAPI 加密“服务主密钥”时所用的密钥。因此，如果管理员更改了借以运行 SQL Server 2005 的服务帐户，则必须使用原始凭据对该“服务主密钥”进行解密。然后，管理员必须使用新凭据加密该“服务主密钥”。我们强烈建议管理员仅使用 SQL Server 2005 Computer Manager（计算机管理器）工具更改借以运行 SQL Server 2005 的服务帐户。此工具将自动执行必要的步骤将该“服务主密钥”解密，然后再重新将其加密。

注意：如果管理员只是更改服务帐户密码，则不必执行上述操作。仅当借以运行 SQL Server 2005 的实际服务帐户发生更改时，才必须执行上述操作。

“服务主密钥”将 Database Master Key（数据库主密钥）加密。在组织加密数据的每个数据库中，都需要“数据库主密钥”。此密钥提供与“服务主密钥”相同的功能。但是，此功能发生在数据库级，而非 SQL Server 2005 实例级。

“数据库主密钥”是一种对称密钥。该密钥不会在创建新的 SQL Server 2005 数据库时自动创建。因此，开发人员必须明确创建此密钥才能在数据库中实施加密。

“数据库主密钥”加密开发人员创建的用户密钥。这些用户密钥包括证书和非对称密钥。反过来，证书和非对称密钥加密开发人员创建的对称密钥。

注意：开发人员还可以使用证书和非对称密钥直接加密数据。不过，证书和非对称密钥最适合仅加密少量数据的情形。

开发人员可以使用对称密钥将其创建的其他对称密钥加密或将数据加密。在开发人员决定使用何种密钥类型将新建密钥加密时，尤其应重点考虑此加密密钥层次结构。SQL Server 2005 加密密钥框架为开发人员提供了极大的灵活性，可为其创建的每个数据库创建简单或复杂的加密密钥层次结构。但是，我们建议开发人员尽量创建其组织允许的最简单的密钥结构。

注意：开发人员还可以通过指定密码将证书的私钥或对称密钥加密。然而，此方法通常更适合于允许应用程序或最终用户了解所用的加密方法和加密密钥的环境。此方法不太适合希望加密流程对最终用户透明的情况。

加密密钥

加密和解密流程需要以下密钥。

证书

证书是非对称加密的一种使用方式。证书是一个数字签名的安全对象，它将公钥值绑定到持有相应私钥的用户、设备或服务。认证机构 (CA) 颁发和签署证书。SQL Server 2005 创建的证书符合 IETF X.509v3 证书标准。通常情况下，开发人员使用证书加密数据库中其他类型的密钥。

非对称密钥

非对称密钥由一个私钥及相应的公钥组成。这两个密钥中的每个密钥都可以解密用另一个密钥加密的数据。通常情况下，开发人员使用非对称加密方法加密用于数据库存储的对称密钥。在 SQL Server 2005 中，非对称密钥是公钥和私钥对。公钥不像证书具有特定的格式，因此开发人员不能将其导出至文件。

在 SQL Server 2005 中，证书和非对称密钥可以相互代替。开发人员可以使用以下两种方法加密非对称密钥：

对称密钥

对称密钥是既可用于加密也可用于解密的单个密钥。使用对称加密可以快速执行加密和解密操作。因此，对称加密非常适合 SQL Server 2005 中大量数据的加密。

在 SQL Server 2005 中，开发人员可以使用以下一种或多种方法将对称密钥加密：

如果开发人员使用其他对称密钥将对称密钥加密，则必须按正确顺序打开密钥。正确的顺序是在加密层次结构中从上至下打开，每次打开一层。开发人员必须遵循正确的顺序，因为如果没有先打开并解密加密某个对称密钥所用的密钥，就不能打开并解密该特定对称密钥。开发人员在设计数据库中加密密钥的层次结构时，必须谨记这一顺序。

返回页首

FeedStore

FeedStore 是 Enterprise Data Services 小组创建的一个内部应用程序。此应用程序从 39 个内部源提取数据，然后为全球约 500 个订阅应用程序生成数据。FeedStore 使用以下所有方法接收数据：

FeedStore 通过处理此数据来创建标准化数据集，以便提交给分布式服务器。此信息通过以下方法以完整或部分表格的方式传递给订阅应用程序：

Enterprise Data Services 认为在业务进展过程中，敏感数据是在整个 Microsoft IT LOB 应用程序领域内复制的。例如，数据被推入 FeedStore。而 FeedStore 将此数据推至约 500 个订阅者。然后，Microsoft IT LOB 应用程序从这些订阅者那里提取数据。通过此过程，敏感数据的一个副本将驻留在 FeedStore 中，另一个副本将驻留在本地订阅者处。图 6 说明了 Microsoft IT 中跨多个应用程序的数据流。

图 6 Microsoft IT 中跨多个应用程序的数据流

另外，Enterprise Data Services 还注意到数据以下述方式复制：业务相关的数据提交至 SAP、FeedStore 和其他数据库。这些数据库将合并另一数据仓库中的数据，这些数据从该数据仓库中导出至 FeedStore 及其他数据库。许多 LOB 应用程序从 FeedStore 以外的其他数据库访问此数据。另外，FeedStore 还将此数据分发至其他位置。在以上每个过程中，数据存储在多个位置，然后复制到多个位置。数据在 SQL Server 数据库、flat 文件位置及其他专有存储库间移动。批过程、应用程序以及用户可以从这些位置访问此数据。

Enterprise Data Services 认为，相同的数据片段可能由不同的用户组使用，或在系统的任何特定点的一个或多个不同用户帐户下。例如，某个应用程序可能使用受信任子系统访问数据。在此情况下，应用程序可以授权某个用户访问某个特定的数据片段。但是，当用户成功获得授权后，该应用程序实际上使用该特定应用程序借以运行的服务帐户凭据检索相关数据。图 7 说明了此授权流程。

图 7 授权流程示例

FeedStore 策略

Enterprise Data Services 认为，与其他许多企业环境一样，敏感数据在 LOB 应用程序领域的多个位置复制并存储。对此类发现的最初反应可能是将存储这些敏感数据的每个位置加密。此措施将为敏感数据提供高度的安全保护。然而，在每个存储位置加密此数据的全部位所花费的成本将是巨大的。

Enterprise Data Services 认为，在一个单独的存储库中合并和加密敏感数据将是满足政府监管要求和 Microsoft 信息安全要求的最为有效而又节省成本的策略。此策略涉及数据合并和删除。

数据合并

将敏感数据合并到一个中央存储库将有助于减少数据复制。另外，将所有敏感数据集中在一个存储库中可以更容易地对这些数据实施加密框架。将敏感数据集中在一个存储库中后，所有与安全相关的问题（如密钥管理、授权、验证和审核）都可集中在一个位置处理。这样，Microsoft IT 就不必为了在本地加密敏感数据而对处理敏感数据的每个 LOB 应用程序进行主数据库更改。图 8 显示了 Enterprise Data Services 建议的数据流，可帮助在整个 Microsoft IT LOB 应用程序领域内保护敏感数据。

图 8. Microsoft IT 中建议的跨多个应用程序的数据流

数据删除

Microsoft IT 通过查看 LOB 应用程序确定这些应用程序是否需要访问敏感数据。对于不需要访问敏感数据的应用程序，Microsoft IT 将重新配置数据馈送，以删除敏感数据。此流程不仅比数据加密成本低，而且遵循了最低权限这一最佳安全模式，从而确保了敏感数据的按需访问。在 Microsoft IT 内，通过修改某些或全部 Microsoft IT LOB 应用程序以删除某些或全部个人身份信息的流程已经完全展开。

对于需要访问敏感数据的应用程序，Enterprise Data Services 认为，在本地应用程序中加密这些数据的成本高于通过重新配置应用程序从独立的数据存储库中获得敏感数据的成本。然而，在某些情况下，不能通过重新配置特定的应用程序从独立的数据存储库获取敏感数据。在此类情况下，必须重新配置 LOB 应用程序才能本地加密敏感数据。

数据合并策略的难点在于如何能保证始终获得敏感数据。Enterprise Data Services 必须考虑以下所有难题：

数字资产存储库试验

作为更好地遵守监管要求和公司安全要求的一个起点，Enterprise Data Services 开发了一个试验项目，通过使用 SQL Server 2005 加密的新特性和功能建立一个中央加密存储库。Enterprise Data Services 将此中央存储库命名为“数字资产存储库”。“数字资产存储库”服务的宗旨是通过与 FeedStore 应用程序的集成，帮助从 FeedStore 应用程序中删除具有高敏感度的个人身份信息，并在整个 Microsoft IT LOB 应用程序领域内提高敏感数据的安全性。

Enterprise Data Services 认为，即便是测试版产品，SQL Server 2005 也已具有足够的可靠性和其需要的特性和功能，可以满足“数字资产存储库”服务的需要。Enterprise Data Services 发现，现有的定制加密解决方案的成本太高；数以百万计的美元正花费在可复用性有限的定制解决方案中。另外，Enterprise Data Services 认为，现有的第三方加密解决方案在成本、集成、维护和支持方面的开销都太过高昂。

业务要求

在 Enterprise Data Services 小组实施“数字资产存储库”试验前，该小组已建立了一系列业务要求。这些要求列出了 Enterprise Data Services 用于评估“数字资产存储库”试验项目是否成功的目的和目标。Enterprise Data Services 对“数字资产存储库”服务提出了以下具体功能目标：

Enterprise Data Services 还为“数字资产存储库”建立了以下基本业务目标：

为确定要移至“数字资产存储库”的信息，Enterprise Data Services 首先必须根据与安全相关的情况对当前信息进行分类。鉴于迁移和加密数据的成本问题，Microsoft 和其他公司都必须慎重确定哪些信息敏感到需要加密的程度。

建立存储敏感数据的独立加密存储库需要进行认真的规划和监控，以确保敏感数据对发出数据请求的应用程序始终可用。在订阅应用程序通过修改可以从加密存储库获取敏感数据以前，这些敏感数据必须存储在非加密数据仓库中。

注意：在某些情况下，不能为了从加密存储库中获取敏感数据而重新配置特定的应用程序。此时，必须对 LOB 应用程序重新配置，使之可以使用诸如 SQL Server 2005 列级加密等功能，本地加密敏感数据。

实施

Enterprise Data Services 确信 SQL Server 2005 中与安全相关的功能会使“数字资产存储库”试验项目获取成功。要实施“数字资产存储库”，Enterprise Data Services 认为必须在 Microsoft IT LOB 应用程序领域内执行以下与 FeedStore 有关的操作：

要实施“数字资产存储库”服务，Enterprise Data Services 认为必须对数据发布方进行配置，以将敏感数据提交至“数字资产存储库”。但是，发布方会继续将非敏感数据提交给 FeedStore。

FeedStore 通过使用复制，从链接服务器执行 SQL Server 提取操作和从 flat 文件位置执行拾取操作来接收数据馈送。“数字资产存储库”将为其中的空闲数据（未被传输或访问的数据）提供加密。但是，敏感数据还是会驻留在当前用于向“数字资产存储库”提交数据的 flat 文件位置。Enterprise Data Services 认为，在将数据传送至“数字资产存储库”的过程中，flat 文件位置提供一个不可接受的链接。图 9 显示了该 flat 文件在当前 FeedStore 数据馈送结构的位置。

图 9 当前 FeedStore 数据馈送结构

Enterprise Data Services 未选择开发将 flat 文件位置的数据加密的方法，而是决定只允许数据库对数据库的数据传输方法。在此情况下，“数字资产存储库”将使用一种获取较小的单点数据的数据传输机制获取数据，而不是使用向 FeedStore 传输的较大的数据集。图 10 显示了建议的“数字资产存储库”数据馈送结构。

图 10 建议的“数字资产存储库”数据馈送结构

SQL Server 2005 中的加密功能专用于加密空闲数据。存储于“数字资产存储库”中的数据将被加密。应用程序和“数字资产存储库”之间的数据传输的执行方式是通过加密通道传递解密（明文）数据。Microsoft IT 将此方法确定为其推荐的在数据库间传输数据的最佳实践方法。在此方法中，系统间不共享加密密钥。另外，空闲数据通过每个系统中提供的加密框架而被加密。图 11 说明了上述数据传输方法。

图 11 建议的敏感数据传输方法

在图 11 中，明文数据通过加密通道在两台正在运行 SQL Server 2005 的计算机间传输。在此情况下，将发生以下操作：

要使用在 Server 2 上运行的进程执行上述操作，该特定进程必须使用 Key 1 将 Server 1 上的数据解密、将解密后的数据复制到 Server 2，然后使用 Key 2 将 Server 2 上的数据加密。要执行这些操作，借以运行该进程的帐户必须具有以下全部用户权限：

必须对 FeedStore 订阅者进行修改，才能从“数字资产存储库”获取高敏感度个人身份信息。为减少数据复制并遵循最低权限这一最佳安全模式，Enterprise Data Services 认为必须实施一种高性能过程，以便在运行时将敏感数据插入企业对企业数据馈送。因此，Enterprise Data Services 开发了一种称为内联转换的技术。有了这种内联转换技术，可执行以下操作：

例如，某个应用程序可以生成包含社会保障号的数据馈送。此数据馈送将被发送到第三方财务机构。但是，生成此数据馈送的环境可能不需要访问社会保障号。在此情况下，如果社会保障号可以插入到传输至第三方财务机构的数据馈送，则该社会保障号不必存在于生成该馈送的环境中。内联转换可以减少访问、存储和传输敏感数据的实例数。另外，内联转换还使用一个单独的加密存储库存储敏感数据。

数字资产存储库加密流程

Enterprise Data Services 认为“数字资产存储库”应使用混合加密机制。因此，发送至“数字资产存储库”的数据将通过 SQL Server 2005 的内置加密和一个对称密钥加密。然后，SQL Server 2005 将使用基于证书的加密将此对称密钥加密。图 12 显示了 Enterprise Data Services 计划实施的“数字资产存储库”加密流程。

图 12 数字资产存储库加密流程

要将数据从“数字资产存储库”传输到订阅者或订阅者处理，应反向执行此加密流程。SQL Server 2005 使用基于证书的加密方法将该对称密钥加密。然后，SQL Server 2005 使用解密的对称密钥将数据解密。解密后的数据将由订阅者进程处理，然后被驱散（删除），或者该解密数据将通过加密通道发送至某个订阅者。然后，该订阅者会使用内置的 SQL Server 2005 加密功能将此数据加密。图 13 显示了 Enterprise Data Services 计划实施的“数字资产存储库”解密流程。

图 13 数字资产存储库解密流程

“数字资产存储库”试验项目的实施为 Microsoft IT 在 Microsoft IT LOB 应用程序领域内的其他加密和数据合并项目提供了宝贵的实施经验。SQL Server 2005 为 Microsoft IT 提供的验证协议增强、改进的精细权限以及内置的加密机制，为维护敏感数据的保密性和完整性提供了帮助。

返回页首

工资管理报告系统

美国的 Microsoft 员工使用 PCRS 应用程序生成工资核算、工资操作和有关福利的报告。

PCRS 应用程序实质上是一种工资数据仓库。此数据库存有 350 GB 的数据，并含有美国 Microsoft 所有员工的工资信息。PCRS 几乎每天都使用批作业从 FeedStore 和 SAP 获取信息。PCRS 将这些信息存储在一个数据库中，从这些数据计算出值，然后用这些计算出的值填写 PCRS 报告数据库。这些计算的值存储在报告数据库中后，Microsoft 工资操作及核算可以使用 Microsoft Access 或 Microsoft Excel® 等程序创建有关工资的报告。图 14 说明了通过 PCRS 的数据流。

图 14 工资管理报告系统数据流

工资管理报告系统策略

为确保符合政府在有关个人身份相关信息方面的新规定，并满足 Microsoft 的公司的数据安全要求，Financial IT 部门认为必须修改 PCRS 应用程序，使之能使用 SQL Server 2005 加密功能帮助保护敏感数据。另外，由于 PCRS 从多个位置接收敏感数据，而且由于必须对这些敏感数据进行额外处理，Financial IT 认为必须在本地的 PCRS 数据库而不是单独的加密存储库中实施加密。

PCRS 数据库中只有少量列需要加密。但是，Financial IT 的加密策略还涉及创建 SQL Server 2005 密钥管理结构和修改用于访问 PCRS 中加密数据的存储过程。Financial IT 不认为通过修改 PCRS 应用程序而加入 SQL Server 2005 的列级加密功能是一个复杂的过程。但是，Financial IT 关心的是 SQL Server 2005 加密密钥层次结构的备份、还原和持续维护。因此，Financial IT 在生产环境中实施此策略之前，实施了一个试样数据库，以测试并确保 SQL Server 2005 加密密钥的备份、维护和还原成功。另外，由于索引对加密列无效，Financial IT 必须从要求加密的列中找到并删除索引。

工资管理报告系统试验项目

Financial IT 部门设定了一个在 PCRS 应用程序中实施 SQL Server 2005 列级加密的目标日期。但是，Financial IT 在生产环境中实施此加密解决方案以前，创建了一个含有加密样本数据的试样数据库，以确保 SQL Server 2005 加密密钥层次结构可以在生产环境中成功备份、还原和维护。

Financial IT 建立了一个名为 PCRS_Encryption 的样例数据库，用来测试 PCRS 应用程序的加密策略。此数据库含有样本敏感数据及用于向数据库提交敏感数据和从数据库获取敏感数据的存储过程。数据库访问以 SQL Server 2005 基于角色的安全性为基础。图 15 说明了此数据库体系结构。

图 15 工资管理报告系统样例数据库

为实施和测试此数据库配置，Financial IT 使用了以下步骤创建一个简单但稳定可靠的 SQL Server 2005 加密密钥层次结构：

接下来，Financial IT 使用了以下步骤修改用于加密表中敏感数据的数据库模式：

然后，Financial IT 更新了使用 EncryptByKey() 函数和 DecryptByKey() 函数访问加密数据的存储过程。此更新需要执行以下步骤：

注意：有关上述函数的详细信息，请参阅本文档后面的“附录：使用加密的场合”。

Financial IT 在完成前述步骤后，配置了 SQL Server 角色的权限，以便为要求访问加密数据的角色授予访问对称密钥的权限，对不允许访问加密数据的角色拒绝授予访问对称密钥的权限。

Financial IT 在成功配置了支持加密敏感数据的样例数据库后，对“数据库主密钥”、SQL Server 2005 证书以及加密数据使用的对称密钥进行了备份。由于加密数据随后将存储在数据库中，Financial IT 认为需要使用以下过程备份数据库：

当某个组织还原含有加密数据的数据库时，它必须拥有用于加密该存储数据的加密密钥。如果某个组织为满足其组织安全要求而定期更改加密密钥，则该组织必须确保拥有可以解密特定备份中的数据的加密密钥。

要还原含有加密数据的数据库，组织必须执行额外步骤以确保能够解密加密后的数据。数据库还原后，该组织必须将“数据库主密钥”解密。然后，它必须使用“服务主密钥”加密该“数据库主密钥”。为解密“数据库主密钥”，该组织必须使用密码，并且所用密码必须是该组织在使用 SQL Server 2005 Transact-SQL 命令备份密钥时用来加密“数据库主密钥”的密码。

虽然 Financial IT 的具体目标是开发和实施 PCRS 应用程序的加密策略，但该部门还有一个更大的目标。此目标是建立一个 Microsoft IT 下属的其他 IT 部门也能用来在本地 LOB 应用程序中实施加密的规定解决方案。

尽管 Financial IT 只使用了 PCRS_Encryption 数据库中的样本数据，但 PCRS 应用程序与 Microsoft IT 中的其他 LOB 应用程序仍有许多相似性。因此，Financial IT 在许多真实情况下对 PCRS_Encryption 数据库进行了测试，旨在确定该加密备份和还原指导原则是否适用于 Financial IT 以外的其他 IT 部门。在测试过程中，Financial IT 未发现该加密流程或解密流程存在任何性能问题。该加密和解密流程对于使用此样例数据库的 Microsoft 员工而言是透明的。

返回页首

Metropolis

Metropolis 是 Services IT 部门创建的一种客户服务和技术支持应用程序。此应用程序由通过 Microsoft Win32® API 创建的前端工具、基于“扩展标记语言”(XML) 的 Web 服务的第二层和基于 SQL Server 2005 的第三层组成。

Microsoft 支持专业人员使用该前端工具帮助指导和支持“帮助台”呼叫。通过与其他技术支持相关的功能（如创建可获得技术支持的服务请求和查询操作）结合使用，此工具可以使支持人员访问含有敏感数据（如产品密钥和密码）的文件共享和其他位置。

与其他许多公司的 IT 部门一样，Services IT 部门在创建 Metropolis 应用程序时，也必须满足涉及敏感数据（如产品密钥和密码）存储的公司安全要求。通常情况下，敏感数据存储在加密的文件共享或共享位置（在该位置处，访问控制列表被设置为限制用户对敏感数据的访问）。此方法的主要问题是，当一个组织使用密码或秘密信息保护敏感数据时，还必须保护该密码或秘密信息。例如，该组织可能使用口令将信息加密。然后，必须使用另一个密码或秘密信息保护该口令。此方法可能导致密码或加密机制层叠。

Microsoft 公司的安全要求允许使用 DPAPI 作为敏感数据的安全机制。使用此策略的原因之一是，使用 DPAPI 的帐户必须登录至本地计算机。

Services IT 认为，SQL Server 2005 内置密钥管理层次结构不仅可以满足 Microsoft 公司的安全要求，而且可以使 Services IT 创建一个允许访问 Metropolis 数据库中敏感数据的简单机制。因此，Services IT 创建了一个用于存储敏感数据的管理数据库。此管理数据库称为环境数据库。该数据库存储了维护 Metropolis 数据库所需的所有敏感数据，如服务器名称、文件共享位置、凭据和加密密钥。Services IT 对 SQL Server 2005 列级加密功能进行了配置，使其能够加密此数据库中的所有敏感数据。

Services IT 认为，Metropolis 环境数据库必须满足以下条件：

Services IT 部门认为，SQL Server 2005 的加密功能可以使其创建一个同时满足上述两个条件的简单而稳定可靠的安全框架。为创建此加密安全框架，Services IT 创建了如图 16 所示的 SQL Server 2005 混合加密密钥层次结构。

图 16 Metropolis 加密密钥层次结构

通过使用 DPAPI 加密 SQL Server 2005 的“服务主密钥”，Services IT 确保了此加密密钥框架符合 Microsoft 公司的安全要求。另外，由于使用混合加密方案，Services IT 遵循了 Microsoft IT 加密的最佳方法。使用对称密钥加密数据，这利用了对称加密速度快的优点。使用非对称密钥将上述对称密钥加密，这利用了非对称加密比对称加密更安全的优点。

但是，Systems IT 加密框架中引人注意之处在于使用证书对加密数据的存储过程进行数字签名。通过使用 SQL Server 2005 证书的私钥对存储过程进行数字签名，没有证书权限的用户可以使用存储过程将对称密钥解密，然后使用该对称密钥在环境数据库中将数据加密。不过，希望通过解密对称密钥而将环境数据库中的数据解密的用户，必须拥有“密钥主权限”。

通过使用 SQL Server 证书加密对称密钥，以及使用该证书对加密环境数据库中的数据的存储过程进行数字签名，Services IT 就能够配置一个权限框架，在该框架中，任何用户都可以加密数据库中的数据。不过，只有特定用户才能将该数据解密。

Services IT 在生产环境中实施了 Metropolis 加密框架并–得—了巨大成功。加密流程对于使用此系统的专业服务人员是透明的。另外，Services IT 计划将此加密框架的使用范围扩展至 Metropolis LOB 应用程序中的其他数据库。

返回页首

最佳方法

Microsoft IT 在 Microsoft IT LOB 应用程序领域内有许多正在进行中的 SQL Server 2005 加密方面的试验项目。因此，Microsoft IT 在 SQL Server 2005 数据库加密技术方面取得了大量经验。这些经验已归纳为一个最佳方法列表。其他组织可以利用这些最佳方法，帮助简化为符合政府法规及公司安全部门的要求而提高数据库安全性的任务。

密钥管理是加密框架的关键

SQL Server 2005 提供了可以对数据加密和解密而无需处理加密算法细节的特性和功能。但 SQL Server 2005 加密功能的主要优点之一是 SQL Server 2005 可以管理加密密钥。

Microsoft IT 对生成密钥的建议：

Microsoft IT 对密钥使用的建议：

Microsoft IT 对密钥备份的建议：

Microsoft IT 对重新生成密钥的建议：

限制对敏感数据的加密

一个组织在实施 SQL Server 2005 加密功能前，必须考虑加密对性能产生的影响、外部源是否要求访问加密数据以及密文相对明文增加的数据量大小。Microsoft IT 对于使用 SQL Server 2005 加密功能方面有以下指导原则：

返回页首

结束语

Microsoft IT 已开始将其 LOB 应用程序移至 SQL Server 2005，以获得 SQL Server 最新版本在性能和安全方面提供的新功能。Microsoft IT 必须针对政府新出台的有关个人身份相关信息的监管要求以及 Microsoft 对敏感数据安全性的要求采取相应措施。因此，Microsoft IT 对 Microsoft IT LOB 应用程序领域的安全框架进行了重新评估。

Microsoft IT 内部的 FeedStore 应用程序充当了 Microsoft 的中央数据存储库。由于此应用程序处理可能含有个人身份相关信息的数据，因此已经建立了一个用于帮助保护这些数据的牢固的安全框架。尽管如此，Enterprise Data Services 仍决定通过开发一个加密框架和实施“数字资产存储库”试验项目，将 FeedStore 安全框架提高到一个新水平。此“数字资产存储库”试验项目将帮助从 FeedStore 和 Microsoft IT LOB 应用程序领域删除个人身份相关信息。

Financial IT 部门和 Services IT 部门面对着需要在其本地 LOB 应用程序中加密的情况。每个部门都使用 SQL Server 2005 开发一个稳定可靠且易于管理的加密框架。

通过使用 SQL Server 2005 中的内置密钥管理机制和列级加密功能，Microsoft IT 已向提高 Microsoft IT LOB 应用程序领域的数据安全性迈出了第一步。

返回页首

更多信息

有关 Microsoft 产品或服务的更多信息，请拨打 Microsoft 销售信息中心的电话：(800) 426-9400。在加拿大，请拨打 Microsoft 加拿大信息中心的电话：(800) 563-9048。在美国 50 个州和加拿大以外的国家和地区，请联系当地的 Microsoft 子公司。要通过万维网获得信息，请访问：

http://www.microsoft.com

http://www.microsoft.com/itshowcase

http://www.microsoft.com/technet/itshowcase

对本文档有任何疑问、意见或建议，或要获得有关 Microsoft IT Showcase 的其他信息，请发送电子邮件至：

showcase@microsoft.com

返回页首

附录：使用加密的场合

加密空闲数据

要使用 SQL Server 2005 对称加密功能加密空闲数据，请执行以下步骤：

SQL Server 2005 提供了一个可选参数，您可以将其与 EncryptByKey() 函数和 DecryptByKey() 函数结合使用来验证列的完整性。如果您希望确保具有必要权限的用户不会在数据库的行之间交换两个加密值，请使用此参数。例如，数据库表中可能含有加密的工资信息。虽然列级加密可防止读取加密的工资数据，但并不能防止拥有必要权限的用户将某个管理人员的加密工资数据与另一个员工的工资数据交换。

针对此情况，SQL Server 2005 采取了在加密时使用可选参数指定散列值的措施。在加密流程中，您可以指定下面的内容。

Insert into empTable values (emp1id, encryptbykey(Key1Guid, 50000, 
 emp1id))

在解密流程中，您可以指定下面的内容。

Select empID, decryptbykey(salary, empID) from empTable

上述示例对明文值 50000 执行加密，该值与可选的第三个参数的散列连接。在此例中，emp1id 是第三个参数。在解密时，SQL Server 2005 将此第三个参数的散列与存储在加密 BLOB 中的散列进行比较。如果两个散列匹配，则 SQL Server 2005 认为加密值未在数据库的行间移动过。

注意：我们建议您使用主密钥作为EncryptByKey()函数的第三个参数。

通过视图访问加密数据

Microsoft IT 目前存在这样的情况，即视图和函数引用加密的列。SQL Server 2005 提供的 DecryptByKeyAutoCert() 函数可以在视图内解密数据。在数据通过对称密钥加密，而该对称密钥又由证书提供保护的情况下，此函数通过查找由指定证书加密的密钥执行。然后，DecryptByKeyAutoCert() 函数自动打开该对称密钥，将数据解密，再关闭该密钥。

注意： 对于引用加密列的视图和函数，您必须通过修改相应的视图或函数来加入数据加密逻辑。

以下示例脚本说明了如何利用 SQL Server 2005 中的视图访问加密数据。

Create View testview 
as 
Select Convert(varchar(100), 
  decryptbykeyautocert(cert_id('myCert1'), NULL, SSN, 0, Null)) as SSN 
From Customer

DecryptByKeyAutoCert() 函数需要以下参数：

大量插入数据

以下示例脚本说明了如何将数据从一个文件大量插入到表中，然后使用 SQL Server 2005 的加密功能将该数据加密。

注意：以下代码段通过多行显示，以便提高可读性。这些代码应以单行输入。

Create Procedure test_sp 
as 
CREATE TABLE #InsertTemp 
( 
      PN int, 
      SSN varchar(100) 
) 
BULK INSERT #InsertTemp 
   FROM 'C:\test.txt'     
TRUNCATE TABLE BulkInsertTbl 
 
OPEN SYMMETRIC KEY key1AES DECRYPTION BY CERTIFICATE myCert1 
 
INSERT INTO BulkInsertTbl (PersonnelNumber, SSN) 
SELECT Tmp.PN, EncryptByKey(Key_GUID('key1AES'),Tmp.NID) 
FROM #InsertTemp Tmp 
 
DROP TABLE #InsertTemp 
/* Note: The following code is not required. The DecryptByKey  
    function call is not required. The function call appears here to 
test whether the inserted data is encrypted. */ 
SELECT 
      T.PersonnelNumber, 
      convert(varchar(20), decryptbykey(T.SSN)) as SSN 
 FROM BulkInsertTbl T 
CLOSE SYMMETRIC KEY key1AES 
go 
 
/* Script to create the BulkInsertTbl table */ 
CREATE TABLE BulkInsertTest 
( 
      PersonnelNumber int, 
      SSN varbinary(100)     /* Note: The encrypted column data type 
   is varbinary.) */ 
) 
go

在此例中，名为 key1AES 的对称密钥通过名为 myCert1 的证书加密。在执行数据加密以前，必须首先打开 key1AES 密钥。然后，当加密完成时，您必须关闭该密钥。此例不需要使用 DecryptByKey() 函数。加入该函数是为了验证是否已加密插入的数据。

利用证书加密和解密数据

通常情况下，我们建议您使用对称密钥加密数据。此方法利用了对称加密速度快的优点。但是，您也可以使用证书代替对称密钥将数据加密。由于非对称加密比对称加密更安全，因此，当需要在运行 SQL Server 2005 的多台服务器间传输加密密钥的情况下，使用证书加密数据很有用。以下示例脚本说明了如何使用证书加密数据。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Yukon900' 
go 
CREATE CERTIFICATE [cert_name] WITH SUBJECT = 'MyApp - Data 
   encryption' 
go 
INSERT INTO TABLE VALUES (encryptbycert( cert_id(cert_name), data))

要解密此数据，请使用 DecryptByCert() 函数。

返回页首