SQL Server 权限管理

标签：SQL SERVER/MSSQL SERVER/数据库/DBA/权限控制/管理/分配/登入名/数据库用户/角色

概述

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

你是否会有这种需求：

1. 给某个用户查询全部数据库的权限
2. 给某个用户仅仅有备份数据库的权限
3. 给一个用户仅仅有指定数据库的权限
4. 给一个用户仅仅有某个表的权限
5. 给一个用户仅仅有查看某些对象（比如：视图）的权限
6. 给一个用户仅仅有运行一些存储过程的权限

 

文件夹

•  元素
  •  登入名
  •  角色
  •  用户
  •  架构
•  权限分配
  •  新建登入名
  •  给用户分配数据库查看权限
  •  给用户查询某个对象的权限
  •  授予用户架构的权限
•  查询权限
•  回收权限
•  总结

元素

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

登入名

仅仅有拥有了登入名才干訪问实例（sql server）.

角色

角色是一类权限的组合。

• 数据库角色的拥有者能够是用户也能够是数据库角色本身。管理员能够创建数据库角色，也能够勉强将数据库角色理解为一组同样权限的用户。为什么这么说呢。由于数据库角色和数据库用户不同意存在同名。

   

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

• server角色的拥有者仅仅有登入名，server角色是固定的。用户无法创建server角色。

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

用户

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

架构

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

用户创建的架构和角色仅仅能作用于当前库。

 

 理解了这些概念之后接下来就能够实践了,接下来我们測试的都是server角色选择public,仅仅測试对数据库权限的控制。

权限分配

新建登入名

新建一个登入名person,仅仅给登入名server角色分配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 
  
  /*假设将当前数据库还原到还有一台server实例上,刚好那台server上也存在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

总结

      所以假设你想对某个用户某个数据库的权限进行细分。你能够通过GRANT来授予详细的对象给用户（当然你也能够revoke回收权限），也能够通过加入某个架构的权限给用户那么用户就拥有该类架构的权限。 

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

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

 

假设我们有一个帮助文章。我希望你可以给个好评，谢谢！。！