背景：用户在使用MaxCompute与DataWorks这两种权限模型不清楚，并且对于相关MaxCompute的权限执行语句也不太熟悉，以至于在自己的实际操作中不能建立完整的权限策略，导致权限控制的混乱，甚至在开发过程中时常遇到权限问题的错误，导致延误业务的推动进展，该篇文档集主要的权限知识点与一体，常用的MaxCompute权限语句，以及经典的开发环境和生产环境之间的赋权示例给大家做出做出介绍。

一、MaxCompute的安全模型

二、DataWorks安全模型

三、子账户添加的限制

四、MaxCompute的授权管理图

五、授权场景和注意事项

六、移除用户的注意事项

七、成员管理的相关语句

查看成员：

Project owner或admin命令行执行
List users;   --查看成员列表
Show grants for <username>; -- 查看某成员权限

添加成员：

1.DataWorks添加RAM子账号；
2.Project owner或admin命令行方式执行
add user <username>   --可为RAM子账户或其他云账户

删除成员：

1.DataWorks删除RAM子账号；
2.Project owner或admin命令行方式执行：
remove user <username>

八、角色管理的相关语句：

查看角色：

查看role列表：List roles;
查看role中的权限：describe role <role_name>
查看某用户在什么role中:show grants for <username>
查看某个role都指派给那些user：目前不支持！

创建角色：

创建role：Create role <role_name>;
给角色授权：grant actions on object to <role_name>
添加用户到角色：grant <roleName> TO <full_username>

删除角色：

删除角色中的用户：REVOKE <roleName> FROM <full_usename>;
撤销对角色的授权：revoke <privList> on <objType> <objName> from role <rolename>
删除角色: DROP ROLE <roleName>

九、policy授权介绍

Policy授权则是⼀种基于主体的授权。通过Policy授权的权限数据（即访问策略）被看做是授权主体的⼀种 ⼦资源。只有当主体（⽤户或⻆⾊）存在时才能进⾏Policy授权操作。当主体被删除时，通过Policy授权的 权限数据会被⾃动删除。 Policy授权使⽤MaxCompute⾃定义的⼀种访问策略语⾔来进⾏授权，允许或 禁⽌主体对项⽬空间对象的访问权限。 

Policy授权机制，主要解决ACL授权机制⽆法解决的⼀些复杂授权场景，⽐如：

• ⼀次操作对⼀组对象进⾏授权，如所有的函数、所有以 “taobao” 开头的表
• 带限制条件的授权，如授权只会在指定的时段内才会⽣效、当请求者从指定的IP地址发起请求时授权才 会⽣效、或者只允许⽤户使⽤SQL（⽽不允许其它类型的Task）来访问某张表。

Policy授权语句格式如下：

GET POLICY; --读取项目空间的Policy 
PUT POLICY <policyFile>; --设置（覆盖）项目空间的Policy 
GET POLICY ON ROLE <roleName>; --读取项目空间中某个角色的Policy 
PUT POLICY <policyFile> ON ROLE <roleName>; --设置（覆盖）项目空间中某个角色的Policy 

policy基本术语

• 主体(Principal) 主体(Principal)是指访问策略中的权限被指派的对象。⽐如，访问策略”允许张三在 2011年12⽉31⽇之前对资源SampleBucket执⾏CreateObject操作”中的主体是”张三”。
• 操作(Action) 操作(Action)是指主体对资源的访问⽅法。⽐如，访问策略”允许张三在2011年12⽉ 31⽇之前对资源SampleBucket执⾏CreateObject操作”中的操作是”CreateObject”。
• 资源(Resource) 资源(Resource)是指主体请求访问的对象。⽐如，访问策略”允许张三在2011年12 ⽉31⽇之前对资源SampleBucket执⾏CreateObject操作”中的资源是”SampleBucket”。
• 访问限制(Access Restriction) 访问限制(Access Restriction)是指权限⽣效的限制条件。⽐如，访 问策略”允许张三在2011年12⽉31⽇之前对资源SampleBucket执⾏CreateObject操作”中的限制 条件是”在2011年12⽉31⽇之前”。
• 效⼒(Effect) 授权效⼒包括两个⽅⾯：允许操作（Allow）和拒绝操作（Deny）。通常，Deny有更⾼ 的效⼒，在权限检查时会优先使⽤。 注意：“拒绝操作”和”撤销授权”是完全独⽴的两个概念，撤销授 权通常包括撤销对Allow和Deny这两种不同效⼒的授权，⽐如传统数据库⼀般⽀持Revoke和Revoke Deny两种操作

授权语句(Statement)结构

• Effect: 指明该条语句的权限类型，取值必须为Allow或Deny。
• Principal: 如果Policy在授权时是与⽤户或⻆⾊绑定，那么就不允许再指定Principal，⽐如 MaxCompute的Role Policy。 如果Policy在授权时是与项⽬空间或项⽬空间内的对象绑定，那么必 须指Principal，⽐如MaxCompute的Project Policy。
• Action: 它表示授权操作，可以是⼀个或多个操作名，可⽀持通配符号” ” 和 ” ? ” 。 例 如 ， A c t i o n = “ ” 表示所有的操作。
• Resource: 它表示授权对象，可以是⼀个或多个对象名，可⽀持通配符号” ” 和 ” ? ” 。 例 如 R e s o u r c e = “ ” 表示所有的对象。
• Condition Block: 条件块是该条授权语句所述权限得以⽣效的条件。条件块结构请参⻅下节的描述。

十、Policy的实际使用授权案例

基于以前的经验，我们在odps项目中创建了两个基本的角色，分别是开发角色dev、查询角色adhoc。

create role dev;
create role adhoc;

我们对于角色的权限要求大概分如下两类：

• A开发权限：不能修改project属性但可以读取project信息，有建表、建资源、建Job等各种常用权限；可以修改、删除自己在开发库中创建的表，但对于其他同学创建的表则只有读取权限。
• B查询权限：只能读取project信息，不能建表、建资源、建Job；只能读取表，但没有任何修改、删除权限。

我们的安全策略大致是这样的：

• 开发库上，给所有开发同学赋予A开发权限。
• 生产库上，给所有开发同学赋予B查询权限。

原文链接

本文为阿里云内容，未经允许不得转载。