Sql 权限设计记录

sql2005权限  

     SQL Server2005中权限管理的主要对象包括服务器登录名、服务器角色、数据库用户(User)、数据库角色(Role)、数据库架构(Schema),搞清楚这些对象间的关系,对于理解SQL Server2005的权限管理有很大帮助。比如为大型企业设计数据库的时候必然考虑到角色划分、权限划分的问题。本文主要以AdventureWorks为样本数据库进行分析,该数据可以从微软官网下载,安装非常方便。

首先谈论一下服务器级别的两个对象,服务器登陆名和服务器角色。

服务器登陆名即登录服务器时所用的用户名,依靠这个服务器登陆名对象,数据库系统才能根据对象间的关系获取相应的数据库操作权限,因此可以把该对象看作权限树的根部和起点。SQL Server支持两种方式的登录:Windows身份认证和SQL Server身份认证。SQL Server2005默认的是Windows身份认证,集成Windows系统的验证模式,登录过程中登录名是确定的,不需要输入密码。SQL Server身份认证需要输入登陆名和相应密码,系统自动带有一个具有高级权限的登录名对象sa,其他对象可以通过TSQL语句创建。例如:create login Kelvin with Password = 'password' 执行后,数据库中即产生了名为Kelvin的服务器登录名对象。 

sql2005权限 - cruelchen - 请重启您的计算........

 

 

上图中选中的为Windows身份方式登录的用户名,默认的登陆名一般是服务器名称。

服务器角色:SQL Server提供一组固定的服务器角色,比如sysadmin、securityadmin等,通过将这些固定的服务器角色赋予不同的服务器登陆名对象,可以是实现服务器级别的权限管理。将服务器角色赋予登陆名对象的语句如下: exec sp_addsrvrolemember Kelvin, sysadmin ; exec sp_dropsrvrolemember Kelvin, sysadmin; 一个服务器登录名对象可以拥有多个固定服务器角色权限,但是固定服务器角色不能被修改、添加和删除。

sql2005权限 - cruelchen - 请重启您的计算........

值得注意的是,服务器角色主要是控制服务器端对请求数据库资源的访问权限,他允许或拒绝服务器登陆名的访问操作,但是在设置具体数据库的管理和操作权限方面,服务器对象的权限设置粒度过大,因此要依靠数据库级别的对象:数据库用户(User)、数据角色(Role)、数据库架构(Schema),这三个对象是针对每一个数据库实例的,因此可以对单个数据库实例进行细化权限划分。

对于拥有服务器角色sysadmin的登陆名对象,它可以SQL Server2005中做任何操作(由此可见服务器角色权限粒度之大)。但对那些没有sysadmin角色的登陆名对象,它需要拥有一个能访问特定数据库实例的数据库用户名(User)以实现对该数据库的操作。比如说为登陆名Kelvin想要访问AdventureWorks数据库,但不具备sysadmin的服务器角色。那么则在AdventureWorks数据库中中创建一个名为user_Kelvin的数据库用户。TSQL:USE AdventureWorks; GO; create user user_Kelvin for login Kelvin; 执行之后,用Kelvin登陆名登录的用户与AdventureWorks下的user_Kelvin用户建立起了关联。

sql2005权限 - cruelchen - 请重启您的计算........

而数据库用户(User)的权限来源则是下面的两个对象:数据库角色(Role)和数据库架构(Schema)。通过在用户中选定相应的角色和架构,我们可以较为方便的实现数据库中数据的分离、存取权限的分离等权限管理。

数据库角色分为固定数据库角色和用户创建的数据库角色。固定数据库角色是系统默认用于组织数据库用户权限的角色,包括db_datareader、db_ddladmin、db_owner等,这些角色都包含与其名称相同的数据库架构(Schema),比如db_datareader就默认只拥有名为db_datareader的架构。用户可以创建角色,并让角色获取相应的架构,最后将角色(Role)与数据库用户(User)建立起联系即可。 比如: Use AdventureWorks; exec sp_addrolemember db_datareader, user_Kelvin; 执行后user_Kelvin就拥有了读取数据的权限(该权限为db_datareader角色拥有)。

数据库的架构应该是最小粒度的权限设置,既包括固定数据库角色对应的数据库架构,又可包括用户自身定义的架构。固定数据库角色对应架构主要涉及数据存取权限,比如db_datareader是允许读取该数据库中所有数据内容,db_datawriter即允许update、insert、delete语句等;用户自定义的架构主要用于分离数据,比如AdventureWorks数据库中拥有下列表:

sql2005权限 - cruelchen - 请重启您的计算........

对于只拥有Production架构的数据库用户来说,登录Adventure数据库只能看到前缀为Production.的表,其他前缀的表隶属于其他架构,对当前用户就不可见了(除非拥有其他架构)。

综上,服务器登陆名对象分别与服务器角色和数据库用户直接关联,而数据库用户与数据库角色和数据库架构直接联系,从而形成了整个数据库结构的权限管理。

 
  本文引用
 
 
 
 
 
------------------------------总结和补充一下自己的东东 方便以后查阅
 1 将新建的用户增加表的操作权限
    exec sp_addrolemember db_datareader,‘账号’
 2 将新建的表移到某某某架构中
   ALTER schema ‘架构名称’ TRANSFER ‘表’, 如果需要批量生成表的话  那么使用下面3的方式先设置用户的默认架构 然后 执行sql语句
 
 3 怎么设置用户的默认架构
    用超级用户登录 点击 ‘安全性’----‘登录名’-----‘右击您需要设置的用户’-----‘属性’----‘用户映射’
 
 ???有个后续问题  当我把用户分配到db_datareader角色的时候 他可以访问任意架构下面的表。当分配到db_ddladmin角色下面的时候 这个用户就只能访问指定架构下面的表。求解..........
原文地址:https://www.cnblogs.com/sxmny/p/2881838.html