Chapter 3 Protecting the Data（1）：理解权限

原文出处：http://blog.csdn.net/dba_huangzj/article/details/39548665，专题目录：http://blog.csdn.net/dba_huangzj/article/details/37906349

未经作者同意，任何人不得以“原创”形式发布，也不得已用于商业用途，本人不负责任何法律责任。

        前一篇：http://blog.csdn.net/dba_huangzj/article/details/39496517

 

前言：

 

关系型数据库管理系统（RDBMS），如SQL Server、Oracle、Mysql等，不仅仅需要负责存取数据，也要负责确保数据的一致性和安全性。类似于其他服务器系统，通过授权给一个用户并维护这个用户的会话来控制数据的访问行为。每当尝试读写数据时，SQL Server都会检查这些权限。首先，先了解一些概念：

Permissions：权限，在安全主体层面授权，这些安全主体包含：登录名、数据库用户、角色等。所有这些对象都可以被grant/deny/revok权限。简称GDR(GRANT,DENY,REVOKE)。接受权限的主体称为接受者（Grantee），设置权限的帐号成为授予者（Grantor）。

 

权限可以使用GRANT选项授予，权限属于Data Control Language(DCL)命令，独立于DML/DDL。基本语法如下：

 

<GRANT | REVOKE | DENY> ON <class of securable>::<securable> TO <principal>;

 

权限的3种状态为：

• GRANT: 权限被允许
• DENY:权限被显式拒绝（优先级高于GRANT）
• REVOKE:消除GRANT/DENY的影响，等于移除权限。

 

实现：

 

可以使用下面语句查看可被授予的权限：

-- 所有返回内置权限的完整列表 SELECT * FROM sys.fn_builtin_permissions(DEFAULT); --返回特定类别，如Schema的权限 : SELECT * FROM sys.fn_builtin_permissions('SCHEMA');

本机结果如下：

第一列是安全主体的类别，即权限应用在这个类别上。permission_name和type用于描述权限，type通常是权限的简写。covering_permission_name列，如果不为 NULL，则为该类的权限名称（隐含该类的其他权限）。比如截图中第一行，CREATE TABLE权限意味着需要有ALTER DATABASE权限。parent_class_desc（

如果不为 NULL，则为包含当前类的父类的名称。）和Parent_covering_permission_name（如果不为 NULL，则为父类的权限名称（隐含该类的所有其他权限）。），具体解释可以查看联机丛书。

 

下面是一些GRANT权限的例子：

 

-- 授权给bill这个数据库用户，让其拥有对Accounting.Account 表有SELECT的权限 GRANT SELECT ON object::Accounting.Account TO Bill; -- 授权给bill这个数据库用户，可以执行Accounting架构中的所有存储过程和标量函数 GRANT EXECUTE ON schema::Accounting TO bill; --授权给用户自定义角色AvailabilityManager，让其拥有修改服务器上可用性组的权限 GRANT ALTER ANY AVAILABILITY GROUP TO AvailabilityManager;

如果需要回收权限，可以使用REVOKE命令：

REVOKE SELECT ON object::Accounting.Account TO Fred;

如果需要显式禁止，可以使用DENY命令：

DENY SELECT ON object::Accounting.Account TO Fred;

当deny之后，如果用户需要运行已被deny的操作，会报出229错误，这个错误是对象上的权限被禁止，但是由于其暴露了信息（如xx对象被禁止，意味着xx对象是存在的），给了攻击者一些感兴趣的信息。而错误208表示尝试访问一个不存在的对象。

 

原理：

 

下面是最常用的权限：

权限名 描述 ALTER

修改对象定义的权限

CONNECT 访问数据库或连接端点的权限 DELETE 删除对象的权限 EXECUTE 执行存储过程或函数的权限 IMPERSONATE 等价于EXECUTE AS命令 INSERT 插入数据到表或视图的权限 REFERENCES 在外键定义或者在视图使用了WITH SCHEMABINDING中应用对象的权限 SELECT 能够在对象或者列上执行SELECT命令 TAKE OWNERSHIP 成为对象的拥有者的权限 UPDATE 更新数据的权限 VIEW DEFINITION 查看对象定义的权限

 

例子：

DENY SELECT ON OBJECT::dbo.Contact TO Fred;--禁止Fred查询dbo.contact表的数据 DENY UPDATE ON OBJECT::dbo.Contact TO Fred;--Fred更新dbo.contact表的数据 GRANT SELECT ON OBJECT::dbo.Contact TO Fred;--授权Fred查询dbo.contact表的数据

 

注意，GRANT ALL虽然存在，但是在后续会被弃用。REVOKE命令可以移除GRANT的效果，不要使用DENY命令来移除命令，除非你确定这个用户不在需要访问这个对象。DENY命令会覆盖所有GRANT命令。

登录名可以被GRANT/DENY在架构或者对象级别，比如

DENY SELECT ON Accounting.Account TO dbo;

CONTROL权限包含了安全实体上的其他权限，如果DENY了SELECT权限，然后又GRANT了CONTROL权限，那么deny权限会被回收。由于SQL Server的权限检查算法和复杂，所以最好保持权限策略的简单性。SQL Server对象权限的层级及传输示意图：

 

更多：

 

如果需要测试当前用户的权限，恶意使用HAS_PERMS_BY_NAME函数，如果返回1，则证明权限被授予：

--是否有对dbo架构有select权限？ SELECT HAS_PERMS_BY_NAME('dbo', 'SCHEMA', 'SELECT'); --检查服务器层面的所有权限 SELECT HAS_PERMS_BY_NAME(null, null, 'VIEW SERVER STATE');

使用下面语句获取已授予的权限列表：

-- 当前用户在dbo架构上有什么权限？ SELECT * FROM sys.fn_my_permissions('dbo', 'SCHEMA'); --服务器所有权限 SELECT * FROM sys.fn_my_permissions(null, null);

服务器权限记录在sys.server_permissions系统视图，数据库权限存放在每个数据库的sys.database_permissions系统视图。可以查看dbo.prospect表上的权限集合：

SELECT  grantee.name AS grantee ,         grantor.name ,         dp.permission_name AS permission ,         dp.state_desc AS state FROM    sys.database_permissions dp         JOIN sys.database_principals grantee ON dp.grantee_principal_id = grantee.principal_id         JOIN sys.database_principals grantor ON dp.grantor_principal_id = grantor.principal_id WHERE   dp.major_id = OBJECT_ID('dbo.prospect');

 

WITH GRANT OPTION工作原理：

 

意味着被授权的主体能把相同或者少于当前权限的权限授予给其他主体。比如

GRANT SELECT ON OBJECT::dbo.contact TO fred WITH GRANT OPTION;

这个授予了Fred有两个权限，一个是SELECT，一个是GRANT SELECT，可以回收除了SELECT之外的其他权限：

REVOKE SELECT ON OBJECT::dbo.contact TO fred CASCADE; GRANT SELECT ON OBJECT::dbo.contact TO fred;

这两个语句就是先回收所有权限，然后仅赋予SELECT，加上CASCADE的含义是把Fred曾经授权给其他主体的SELECT权限一并收回。

 

 

REFERENCE权限：

 

这个权限不仅仅作用域表，还可以作用于数据库、架构等主体。REFERENCE在表中允许创建外键约束，在视图中可以用于WITH SCHEMABINDING 所影响的表的引用。

下一篇：http://blog.csdn.net/dba_huangzj/article/details/39577861