安全性管理的途径物业

当在服务器上运行SQL Server 时，我们总是要想方设法去使SQL Server 免遭非法用户的侵入，拒绝其访问数据库，保证数据的安全性。SQL Server 提供了强大的内置的安全性和数据保护，来帮助实现这种理所当然的要求。从前面的介绍中我们可以看出SQL Server 提供了从操作系统，SQL ServerE， 数据库到对象的多级别的安全保护。其中也涉及到角色、数据库用户、权限等多个与安全性有关的概念。现在我们面临的问题就是如何在SQL Server 内把这些不同的与安全性有关的组件结合起来，充分地利用各种组件的优点，考虑到其可能存在的缺点来扬长避短，制定可靠的安全策略。使SQL Server 更健壮，更为“不可侵犯”。

下面我们将介绍几种安全性管理策略，您应该做的就是看懂并理解这些策略方法，然后将它们简单地结合到一起就可以了。

1 使用视图作为安全机制

在游标和视图一章我们已经提到视图可以做为一种安全机制的主要原因在于视图是一张虚表,而且它是由查询语句来定义的,是一个数据结果集，通过视图，用户仅能查询修改他所能看到的数据，其它的数据库或表对于该用户既不可见也无法访问。通过视图的权限设置，用户只具有相应的访问视图的权限，但并不具有访问视图所引用的基本表的相应权限。

通过使用不同的视图并对用户授予不同的权限，不同的用户可以看到不同的结果集，可以实现行级或列级的数据安全性。下面的几个例子说明了视图是如何实现数据安全性。

2 使用了行级、列级别安全性的视图

例： 在该例中某一销售点只能查看它自己的销售信息。我们使用pubs 数据库中的sales 表。

首先创建视图

498)this.style.width=498;\">

3 视图与权限结合

如果将访问视图的权限授予给用户，这样即使该用户不具有访问视图所引用的基本表的权限，但其仍可以从中查看相应的数据信息。

而且还真的盗掘了一座明代古墓葬。近日 视图与权限相结合究竟能带来什么好处呢？下面我们举一个例子来进行说明。首先假设用户A 对sales 表的payterms 列没有SELECT 权限，对其它列有且仅有SELECT 权限，如果要查看其它销售信息不能使用这样的语句：

select * from sales

而必须指出其余列的列名。这就要求用户了解表的结构，通常来说让用户了解表结构是一件很不聪明的事，那么如何解决这一问题呢？

很简单如果创建一个视图view1， 该视图包含除payterms 列外的所有列，并且将 SELECT 权限授予用户A， 这样用户A 就可以执行语句：select * from view1， 从而查看到销售信息。

4 使用存储过程作为安全机制

如果用户不具有访问视图和表的权限，那么通过存储过程仍能够让其查询相应的数据信息，实现的方法很简单，只要让该用户具有存储过程的EXEC 权限就可以了。当然要确保该存储过程中包含了查询语句。比如可创建下面的存储过程：

create procedure selsales as

select * from sales

然后将存储过程的EXEC 权限授予用户，当用户执行该存储过程时就可以查看到相应信息。

使用存储过程的优点在于不必对视图和表的访问权限进行分配。

小结

本文主要讨论了SQL Server 的安全性管理问题。涉及到数据库用户、角色、权限等作为一名系统管理员或安全管理员，在进行安全属性配置前，首先要确定应使用哪种身份认证模式。要注意恰当地使用guest 用户和public 角色，并深刻了解应用角色对于实现数据查询和处理的可控性所展示出的优点。

查看本文来源