SQL Server 2005的XML支持机制和安全机制(1)
发布时间：2015-11-23 00:00 来源：未知
Internet：我用最XML的方式支持你
SQL Server对XML支持
Internet平台应用除了通信部分与其他应用有本质区别外，作为基本的应用组成没有实质区别，无非是处理逻辑和业务数据模型。在HTTP为基础的Internet上，XML数据通过自描述性、可扩展能力和跨平台优势，获得了包括微软在内的数据厂商的支持，因此作为微软整个.Net计划的中心产品——SQL Server 2005也要顺应应用趋势，面向XML尤其是XML Web Service提供存储、发布、交换和整合的支持。
SQL Server 2000的时候已经增加了对XML的支持，而且可以通过HTTP访问获得XML数据，相应的开发也通过SQLXML单独安装开发包，不过在SQL Server 2005中对XML数据访问的支持有了大幅度增强。
对XML支持的增强特性
（1）增加了专门的XML数据类型。
（2）提供了对XQuery的全面支持，可以通过XQuery在关系数据库的基础上，通过查询引擎把二维的关系数据结果组织成层次型的XML数据。
（3）不仅提供查询，SQL Server 2005还一并提供了XML DML，可以通过INSERT、UPDATE、DELETE完成对XML数据片段的修改。
（4）与以往关系数据库索引不同，新的数据库引擎还提供面向XML数据的层次性索引，统一XML索引解决了以往开发人员对于在已知Schema上批量数据快速查询的支持。
（5）通过增强分布式查询的OPENROWSET的功能，提高同构甚至异构系统间批量XML数据的处理效率。
（6） 此外，对于SQL Server 2000引入的FOR XML子句和OPENXML()提供更好的支持。
全新的面向XML的存储体系
在新的平台上，普遍的开发技术组合是 ADO.Net 2.0 + XML + SQL Server。即便在国内这种开发模式已经非常普遍，已经用于在建的很多项目，况且在微软的家族内部报表服务、集成服务、数据分析服务已经全面支持XML，而且在开发领域.Net的配置文件也是XML，甚至ADO.Net用户交换的DataSet和DataTable都是完全可以XML化的。但是，以往的SQL Server产品没有办法解决存储上的冲突，层次结构的XML虽然被保存到了关系数据库里面。由于一般采用BLOB方式，因此只能以高前端程序讨论XSD或者DTD进行验证。而且由于以前没有配备XML索引，因此进行检索需要逐个把BLOB中的数据提取出来之后，再进行比较，这样效率非常低。为了提高效率以往还采用拆分XML文件，通过XML View借助关系数据库的查询优化来减少这种批量检索的性能损失。总而言之，SQL Server 2000处理XML到处都感觉比较“别扭”。
有了SQL Server 2005的混合存储之后，笔者认为新的体系对XML使用有如下好处：
（1）对于商业应用要求而言，关系数据与XML数据都有了事务性的保证。
（2）面对专门的XML数据对象，可以通过配置XSD或者DTD验证数据。
（3） 对于应用开发而言，提供了与ADO.Net同样的模式。
（4）可以在混合结构上通过索引进行快速检索。
（5）对于管理员而言，可以进行统一的备份/恢复、授权、访问控制、复制、数据集成调度。
是你吗？不管怎么说我的数据我做主
作为您或者您的企业的关键数据的中心载体，进行必要的安全保护将是保证业务系统正常运转的必要条件，当然实现这个目标需要开发和运行维护团队人员根据数据库的功能特性进行集成和配置。
SQL Server认证机制的安全性改进
图1：SQL Server的认证机制
如上图，SQL Server认证同时提供SQL Server本地账号与Windows继承认证两种方式，以往在企业环境中相信读者可以通过配置活动目录的密码策略来控制诸如下面一些策略：
（1）是否采用强密码
（2）密码长度
（3）密码过期时间
（4）验证错误锁定次数
（5） 账号是否Enable
而在SQL Server 以往的版本中本地账号上这些控制似乎很弱。在SQL Server 2005中，所有的Login不仅可以通过“用户名/密码”方式进行认证，还可以通过证书方式进行，这对于具有异构操作系统平台的企业CA环境而言，提供了最为便捷的方式。对于Login Policy的配置可以通过内值函数LOGINPROPERTY获得，了解相关的配置策略信息。
图2：配置Login的密码策略
代码示例1：通过LOGINPROPERTY获得Login的安全策略
示例1．确认用户是否需要修改密码
示例2：确认Login是否已经被锁定
分级的数据库访问实体机制 在以往的SQL Server中，SQL Server采用的是SQL Server Instance层次的Login和数据库层次的Role、User，总而言是从SQL Server自身的角度确认那些访问实体（用户或者是应用程序）可以访问数据库。SQL Server2005 按照访问的范围把访问实体化分为三大类Principal：Windows级、SQL Server级和Database级。具体包括如下。 Windows-级的Principal：Windows Domain login、Windows Local login SQL Server 2005中增加了一个新的概念——Securable，它代表由数据库引擎控制访问的各种数据库资源。根据三层访问实体的划分，对应的在每个层次也出现了不同的Securable对象，如下说明。 数据库服务器范围内的：EndPoint、Login、Database 数据库范围内的：User、Role、Application role、Assembly 、Message Type、Route、Service 、Remote Service Binding、Fulltext Catalog、Certificate、Asymmetric Key 、Symmetric Key 、Contract、Schema 而在Schema范围内：Type 、XML Schema Collection 、Object Object他包括如下几类：Aggregate、Constraint、Function 、Procedure、Queue、Statistic、Synonym 、Table、View 因此，在明确了Principal、Securable和Object三者关系之后，每一个Principal对于SQL Server的访问控制就可以通过如下关系获得：
图3：配置Principal、Securable与Securable的关系 在明确上文分层的Principal和分层的Securable之后，相信读者自然而然会发现其实在SQL Server 2005的设计中，权限（Permission）本身也是具有层次性的，可以用DCL语言（GRANT、DENY、REVOKE）来管理与配置它们。下图是一个完整的SQL Server 2005Principal、Securable和Permission的层次嵌套关系：
图4：Principal、Securable和Permission层次嵌套关系 在Management Studio中的配置界面如下：
图5：配置Principal对Securable访问权限的过程 借助CLR控制.Net Assembly的执行过程 如上文所说，SQL Server 2005继承了CLR，同时也就将CLR对于.Net Assembly的控制集成到了他的安全体系之中，目的是要确保功能强大的.Net代码不至于伤害到SQL Server或者是他的运行环境。默认情况下SQL Server 2005提供了Safe（安全访问SQL Server内部数据）、External_Access（以托管方式可以访问SQL Server内部或部分外部资源）和Unsafe（非托管方式，可以直接访问系统平台接口和本地Windows 32 API）三个代码执行范围等级。通过对.Net Assembly配置执行范围等级，可以粗略的控制代码访问范围。不过笔者更建议读者通过配置.Net Framework Configuration完成，这样做的主要好处是一方面可以很容易的通过域策略将配置好的模版作分发，对于整个企业运行环境进行集中管理有很大好处。 “看我七十二变的”的上下文定义特性 相信以往信息上线的时候，数据库应用开发人员与数据库管理人员可能会因为应用需要过多的执行能力发生争执，作为数据库管理员（DBA）一般都是按照最小化原则配置访问权限，并且希望应用的执行账号（企业应用中常常会采用代理账号访问数据库）尽量限制在其自己的Schema内部，尤其不要访问注册表、活动目录、媒体资料库等敏感的系统资源。但是，应用规模大了难免出现个别特例，万般无奈之下数据库管理员只得为应用的账号配置一个BUILDIN / Administrators或者Domain Admins级别的权限。这样，假如一旦出现代码注入等问题的时候，威胁的不仅仅是数据库本身，甚至是下层的Windows运行环境。 SQL Server 2005的Executing Context提供了“七十二变”的办法，可以为调用链中的某个执行步骤配置不同的用户身份，这样即便出现个别系统敏感访问的时候，也只需要为这些步骤配置单独的执行账号。
图6：执行过程中交换Context的示例 相关阅读推荐阅读最新资讯 |
