（1.3.3）权限控制

　　概述：登录身份验证仅限于控制是否可以访问sql server实例。当用户完成登录后，用户所能实现的操作通过权限控制进行约束。

1.权限控制体系概述

　　sql server的权限体系由主体和安全对象两部分构成。

　　【1】主体是资源访问的请求者。它是请求访问sql server资源的实体，每个主体都具有一个安全标识符（SID）。主体的影响范围取决于主体定义的范围（windows、服务器或数据库）以及主体是否不可分或是一个集合（例如，windows登录名不是一个可分的主体，而windows组则是一个集合主体）

　　【2】安全对象是被访问者，它被主体请求访问。在安全对象中，最突出的是服务器与数据库，更细的级别可以是数据库中的表、数据列或者其他对象。

　　　　　　　　　　　　　　　　sql server 权限层次结构图　　

　　简单的理解sql server权限层次结构，用公司管理体系来比喻。它由两大部分组成：控制和推动公司运作的员工以及公司的各种资源。在公司的运作中（公司等于sql server实例），员工使用资源，因此员工是主体；而资源是否可以被调用，取决于请求此资源的员工是否被授权，因此，资源是安全对象。进一步理解，公司是由若干个部门组成，每个部门完成不同的功能，这些部门相当于sql server实例下的数据库；而部门下面可能又分成不同的组，这些就相当于数据库中的对象（表、视图等）。

　　在公司的管理中心，除了对员工进行单独授权外，更多的是安排员工的职位，职位决定了再此职位上的员工可以使用公司的哪些资源，这体现在 sql server中，对应的就是角色。职位有公司级的，也有部门级的，所以对应于sql server中，也就有服务器角色和数据库角色之分；而又的职位（权限）仅仅在需要时被临时授予，这样的职位对应到 sql server中就是应用程序角色。

--临时授权
execute as是用来定义模块的执行上下文
EXECUTE AS { CALLER | SELF | OWNER | 'user_name' }
其中CALLER指模块调用方，SELF指创建或更改模块的用户，OWNER指模块的当前所有者， ‘user_name’ 则是指定的用户。

--示例
USE Sales; GO
CREATE PROCEDURE dbo.usp_Demo 
WITH EXECUTE AS 'CompanyDomain\SqlUser1' 
AS SELECT user_name(); GO

2.sql server权限管理

转载自：https://www.cnblogs.com/chenmh/p/4080420.html#%E7%99%BB%E5%85%A5%E5%90%8D

概述

对数据库系统而言，保证数据的安全性永远都是最重要的问题之一。一个好的数据库环境，必须明确每个用户的职责，并分配其对应的权限。同时出现问题了也可以找到根源。

你是否会有这样的需求：

给某个用户查询所有数据库的权限
给某个用户只有备份数据库的权限
给一个用户只有指定数据库的权限
给一个用户只有某个表的权限
给一个用户只有查看某些对象（例如：视图）的权限
给一个用户只有执行一些存储过程的权限

元素

文章可能会有些枯燥，还望耐心，相信应该有你想要的。

登入名

只有拥有了登入名才能访问实例（sql server）.

角色

角色是一类权限的组合。

数据库角色的拥有者可以是用户也可以是数据库角色本身，管理员可以创建数据库角色，也可以勉强将数据库角色理解为一组相同权限的用户，为什么这么说呢，因为数据库角色和数据库用户不允许存在同名。

注意：不要将用户创建的数据库角色添加到固定的服务器数据库角色当中去，否则将导致固定的数据库角色的权限升级。

服务器角色的拥有者只有登入名，服务器角色是固定的，用户无法创建服务器角色。

注意：一般不建议给用户直接分配服务器角色，因为服务器角色是全局的，也就是说你拥有了服务器级别的权限，一般建议给用户分配数据库，然后给对应的数据库分配数据库角色权限。

用户

用户是数据库级的概念，数据库用户必须绑定具体的登入名，你也可以在新建登入名的时候绑定此登入名拥有的数据库，当你绑定登入名数据库后，数据库默认就创建了此登入名同名的数据库用户，登入名与数据库用户之间就存在关联关系，数据库用户是架构和数据库角色的拥有者，即你可以将某个架构分配给用户那么该用户就拥有了该架构所包含的对象，你也可以将某个数据库角色分配给用户，此用户就拥有该数据库角色的权限。

架构

架构是对象的拥有者，架构本身无权限，架构包含数据库对象：如表、视图、存储过程和函数等，平时最常见的默认架构dbo.,如果没指定架构默认创建数据库对象都是以dbo.开头，架构的拥有者是数据库用户、数据库角色、应用程序角色。用户创建的架构和角色只能作用于当前库。

理解了这些概念之后接下来就可以实践了,接下来我们测试的都是服务器角色选择public,只测试对数据库权限的控制。

权限分配

新建登入名

新建一个登入名person,只给登入名服务器角色分配public权限，不分配数据库

接下来用person登入实例，person用户无法访问任何数据库，由于我们未给用户分配任何数据库。

给用户分配数据库查看权限

只允许用户查看AdventureWorks2008R2数据库

此时用户可以查询所有对象，但无法修改对象。

给用户查询某个对象的权限

如果觉得给用户查看权限太大了，将da_datareader数据库角色权限回收，你会发现用户可以访问数据库，但是看不到任何对象。

只给用户查看Person.Address表

USE AdventureWorks2008R2;
GRANT SELECT ON OBJECT::Person.Address TO person;
--或者使用
USE AdventureWorks2008R2;
GRANT SELECT ON Person.Address TO RosaQdM;
GO

扩展功能

--以下都是赋予用户对表的dml权限

---授予用户person对表Person.Address的修改权限
USE AdventureWorks2008R2;
GRANT UPDATE ON Person.Address TO person;
GO

---授予用户person对表Person.Address的插入权限
USE AdventureWorks2008R2;
GRANT INSERT ON Person.Address TO person;
GO

---授予用户person对表Person.Address的删除权限
USE AdventureWorks2008R2;
GRANT DELETE ON Person.Address TO person;

--授予用户存储过程dbo.prc_errorlog的执行权限
GRANT EXECUTE ON dbo.prc_errorlog TO person

标量函数权限：EXECUTE、REFERENCES。

表值函数权限：DELETE、INSERT、REFERENCES、SELECT、UPDATE。

存储过程权限：EXECUTE。

表权限：DELETE、INSERT、REFERENCES、SELECT、UPDATE。

视图权限：DELETE、INSERT、REFERENCES、SELECT、UPDATE。

授予用户架构的权限

新建数据库角色db_persons

新增架构

数据库-安全性-架构

架构包含数据库对象

创建架构persons表

---创建架构persons的表
CREATE TABLE Persons.sutdent
(id int not null)

你会发现用户同时有了Persons.sutdent表的查看权限，因为用户是数据库角色db_person的所有者，而db_person又是架构persons的所有者。

创建一些persons架构的视图，存储过程

---创建视图
USE AdventureWorks2008R2
GO
CREATE VIEW Persons.vwsutdent
AS
SELECT * FROM Persons.sutdent

GO
USE AdventureWorks2008R2
GO
---创建存储过程
CREATE PROCEDURE Persons.SP_sutdent
(@OPTION NVARCHAR(50))
AS
BEGIN
    SET NOCOUNT ON
    IF @OPTION='Select'
    BEGIN
    SELECT * FROM Persons.sutdent
    END
END

详细的GRANT功能可以查询2008r2连接丛书:

ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.zh-CHS/s10de_6tsql/html/a760c16a-4d2d-43f2-be81-ae9315f38185.htm

查询权限

  ---登入名表
  select * from master.sys.syslogins 
  ---登入名与服务器角色关联表
  select * from sys.server_role_members
  ---服务器角色表
  select * from sys.server_principals
  ----查询登入名拥有的服务器角色
  select SrvRole = g.name, MemberName = u.name, MemberSID = u.sid
  from sys.server_role_members m  inner join sys.server_principals g on  g.principal_id = m.role_principal_id 
  inner join sys.server_principals u on u.principal_id = m.member_principal_id

  ---数据库用户表
  select * from sysusers
  ---数据库用户表角色关联表
  select * from sysmembers 
  ---数据库角色表
  select * from sys.database_principals
  ----查询数据库用户拥有的角色
  select ta.name as username,tc.name as databaserole  from sysusers ta inner join sysmembers tb on ta.uid=tb.memberuid
  inner join  sys.database_principals tc on tb.groupuid=tc.principal_id

查询登入名与数据库用户之间的关系

--查询当前数据库用户关联的登入名
  use AdventureWorks2008R2
  select ta.name as loginname,tb.name as databaseusername from master.sys.syslogins ta inner join sysusers tb on ta.sid=tb.sid 
  
  /*如果将当前数据库还原到另一台服务器实例上,刚好那台服务器上也存在person登入用户，你会发现二者的sid不一样，
  由于sid不一样,所以登入用户不具有当前数据库的访问权限,我们要想办法将二者关联起来。
  */
  ---关联登入名与数据库用户（将数据库用户的sid刷成登入名的sid）
    use AdventureWorks2008R2
    EXEC sp_change_users_login 'Update_One', 'person', 'person'
    Go

查询数据库用户被授予的权限

exec sp_helprotect @username = 'person'

查询person数据库用户权限会发现，数据库用户拥有的权限都是前面使用GRANT赋予的权限，而后面给用户分配的架构对象不在这个里面显示，上面显示的只是被授予的权限，而架构是数据库用户所拥有的权限。

回收权限

如果安全对象是数据库，对应 BACKUP DATABASE、BACKUP LOG、CREATE DATABASE、CREATE DEFAULT、CREATE FUNCTION、CREATE PROCEDURE、CREATE RULE、CREATE TABLE 和 CREATE VIEW。

如果安全对象是标量函数，对应 EXECUTE 和 REFERENCES。

如果安全对象是表值函数，对应 DELETE、INSERT、REFERENCES、SELECT 和 UPDATE。

如果安全对象是存储过程，表示 EXECUTE。

如果安全对象是表，对应 DELETE、INSERT、REFERENCES、SELECT 和 UPDATE。

如果安全对象是视图，对应 DELETE、INSERT、REFERENCES、SELECT 和 UPDATE。

回收dbo.prc_errorlog存储过程的执行权限

USE AdventureWorks2008R2;
REVOKE EXECUTE ON dbo.prc_errorlog    FROM person;

回收Person.Address表的查询，修改，删除权限

--回收修改
USE AdventureWorks2008R2;
REVOKE update ON   Person.Address FROM person;

USE AdventureWorks2008R2;
REVOKE alter ON   Person.Address FROM person;

--回收删除
USE AdventureWorks2008R2;
REVOKE delete ON   Person.Address FROM person;

--回收查询
USE AdventureWorks2008R2;
REVOKE select ON   Person.Address FROM person;

最后剩下owner为‘.’的是数据库级的权限

最后回收数据库的权限

USE AdventureWorks2008R2;
REVOKE CREATE TABLE FROM person;
GO

CONNECT权限是用户访问数据库的权限，将此权限回收后用户将无法访问数据库
--USE AdventureWorks2008R2;
--REVOKE CONNECT FROM person;
--GO

再执行exec sp_helprotect @username = 'person'，就剩下action=connect的数据库访问权限

将权限回收后，数据库用户还剩下架构Persons的权限，如果还需要将该权限回收，只需要用户取消关联对应的db_person数据库角色权限。

详细的revoke权限回收请参考2008r2联机丛书：

ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.zh-CHS/s10de_6tsql/html/9d31d3e7-0883-45cd-bf0e-f0361bbb0956.htm

补充

针对生产数据库服务器创建一个应用程序访问的用户最常见的是授予用户某个数据库：“查询”、“删除”、“修改”、“插入”、“执行”的权限，用SQL语句实现如下（用户：person,数据库：news）：

USE [master]
GO
---创建登入名
CREATE LOGIN [person] WITH PASSWORD=N'person', DEFAULT_DATABASE=[news], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE [news]
GO
---在指定的数据库下创建和登入名相关联的数据库用户
CREATE USER [person] FOR LOGIN [person]
GO
USE [news]
GO
---在指定的数据库下授予用户SELECT,DELETE,UPDATE,INSERT,EXECUTE权限。
GRANT SELECT,DELETE,UPDATE,INSERT,EXECUTE TO person;

注意：创建登入名在master数据库下，创建数据库用户和授予数据库权限都是在具体的数据库下操作。

其它相关权限授予

---授予Profile权限
USE master
GO
GRANT ALTER TRACE TO person
GO
---授予活动监视器权限
USE master
GO
GRANT VIEW SERVER STATE TO person
GO

总结

所以如果你想对某个用户某个数据库的权限进行细分，你可以通过GRANT来授予具体的对象给用户（当然你也可以revoke回收权限），也可以通过添加某个架构的权限给用户那么用户就拥有该类架构的权限。

用户拥有什么权限取决于角色，而拥有哪些对象取决于拥有包含这些对象的架构，架构的拥有者可以是数据库用户也可以是数据库角色也可以是应用程序角色，明白了这个道理你对权限的管理也就很清晰了。

虽然心有余但是还是无法将整个知识点给讲透，写文章之前虽然把整个框架给整理了，但是在写的过程中发现要写的内容太多了，比如GRANT权限里面就涉及了表、数据库、应用程序角色、函数、证书、角色、架构、存储过程、同义词还有很多；同时表有可以精确到给具体的某个字段的权限，所以太多了，接下来的REVOKE也同样是这么多。本文可以起到一个引领的作用，让你了解有这些功能，了解权限的功能细分；如果有兴趣的朋友可以更深入的去钻研，这篇文章写下来还是挺累的,写完这篇文章看一下时间已经是凌晨二点钟，主要是思维不想被中断所以一口气给写完了，希望能给大家有所帮助。

备注：

作者：pursuer.chen

博客：http://www.cnblogs.com/chenmh

本站点所有随笔都是原创，欢迎大家转载；但转载时必须注明文章来源，且在文章开头明显处给明链接，否则保留追究责任的权利。

《欢迎交流讨论》

好文要顶关注我收藏该文

posted @ 2018-06-12 19:53 郭大侠1 阅读(401) 评论(0) 编辑收藏举报

刷新页面返回顶部