SQL Server 2005的XML支持机制和安全机制

核心提示： 图3：配置Principal、Securable与Securable的关系在明确上文分层的Principal和分层的Securable之后，相信读者自然而然会发现其实在SQL Server 2005的设计中，SQL Server 2005的XML支持机制和安全机制(5)，权限（Permis

图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的示例