MaxCompute产品架构

MaxCompute由四部分组成，分别是客户端、接入层、逻辑层及计算层，每一层均可平行扩展。

MaxCompute客户端

MaxCompute的客户端有以下几种形式：

• API：以RESTful API的方式提供离线数据处理服务。
• SDK：对RESTful API的封装，目前有Java等版本的实现。
• CLT（Command Line Tool）：运行在Windows/Linux下的客户端工具，通过CLT可以提交命令完成Project管理、DDL、DML等操作。
• DataWorks：提供了上层可视化ETL/BI工具，用户可以基于DataWorks完成数据同步、任务调度、报表生成等常见操作。

MaxCompute接入层

MaxCompute接入层提供HTTP（HTTPS）服务、Load Balance、用户认证和服务层面的访问控制。

MaxCompute逻辑层

MaxCcompute逻辑层是核心部分，实现用户空间和对象的管理、命令的解析与执行逻辑、数据对象的访问控制与授权等功能。
逻辑层包括两个集群：

• 调度集群：调度集群主要负责用户空间和对象的管理、Query和命令的解析与启动、数据对象的访问控制与授权等功能。
• 计算集群：主要负责Task的执行。

控制集群和计算集群均可根据规模平行扩展。

在调度集群中有Worker、Scheduler和Executor三个角色，其中：

• Worker处理所有RESTful请求：包括用户空间（project）管理操作、资源（resource）管理操作、作业管理等，对于SQL、MapReduce、Graph等启动Fuxi任务的作业，会提交Scheduler进一步处理。
• Scheduler负责instance的调度：包括将instance分解为task**、对等待提交的task进行排序、以及向计算集群的Fuxi master询问资源占用情况**以进行流控（Fuxi slot满的时候，停止响应Executor的task申请）。
• Executor负责启动SQL/MR task：向计算集群的Fuxi master提交Fuxi任务，并监控这些任务的运行。

当用户提交一个作业请求时，接入层的Web服务器查询获取已注册的Worker的IP地址，并随机选择某些Worker发送API请求。Worker将请求发送给Scheduler，由其负责调度和流控。Executor会主动轮询Scheduler的队列，若资源满足条件，则开始执行任务，并将任务执行状态反馈给Scheduler。

MaxCompute作业中涉及到的相关概念如下所示：

• MaxCompute instance：代表一个MaxCompute job（没有定义job就是匿名job）的实例。一个MaxCompute job可以包含多个MaxCompute task，所以一个MaxCompute instance可以提交多个sql或者mr，并执行是并行执行还是串行执行。由于job不常用，因此这种用法也比较少，绝大多数情况下是一个instance包含一个task。
• MaxCompute task：代表一个具体的任务，目前有sql/mr/admin/lot/xlib等近20种类型，每个类型任务执行的逻辑差别很大。同一个instance下不同的task根据task_name进行区分。MaxCompute task是在控制集群上运行的，对于较为简单的修改meta的操作，在控制集群上可以完成整个的生命周期；对于计算任务，则需要向计算集群提交fuxi job。
• Fuxi job：是任务调度系统模块提供的一种计算模型（与之对应的是fuxi service），表示能执行完成的任务（service表示常驻进程）。
  • Fuxi job支持DAG调度，每一个job都会有一个对应的job master，用于进行这个job下资源的调度。
  • 对于sql来说，fuxi job又分为offline job和online job（由service mode演变而来）。其中，online job也被称为准实时任务，进程是常驻系统的，有任务时就执行，可以减少启停时间，提高处理速度。
  • MaxCompute的task可以向多个计算集群提交任务，fuxi job的主键是cluster name+job name。
  • 任务调度系统提交job的json plan以及任务结束后的jobstatus会被保存在飞天分布式文件系统上。
• Fuxi task：是fuxi job下的一个概念，与MaxCompute task类似，不同的task代表不同的执行逻辑。fuxi的task之间可以链接成pipes，共同完成一段复杂的逻辑。
• Fuxi instance：指的是fuxi task的instance，是任务调度系统调度的最小单位。一个task在实际执行过程中，会被切分为许多逻辑单元并行处理，提高处理速度。不同的instance的执行逻辑是相同的，但输入输出数据不同。
• Fuxi worker：是任务调度系统底层的一个概念，一个worker代表一个操作系统的进程，多个fuxiinstance可以复用一个worker，一个worker同时只能处理一个instance。

说明：

• InstanceID：MaxCompute作业的唯一标识，在调查问题时非常常用，根据Project name和InstanceID可以构造当前instance的logview。
• Service master/Job master：负责资源申请和调度，为worker创建工作计划并监控worker的生命周期。

MaxCompute存储与计算层

MaxCompute存储于计算层为阿里云自主知识产权的云计算平台的核心构件，是飞天操作系统内核，运行在和控制集群独立的计算集群上。

MaxCompute安全解决方案

概述

MaxCompute安全体系包含多种策略 ，而各种策略赋权是权限递增关系。下面以获取一个L4等级表权限的具体步骤来举例说明权限递增关系：

1. 如果用户未有过授权记录，且非本项目用户，首先需要将该用户添加至此项目中。这个过程中，用户还没有任何实际权限。
2. 授权用户对象的操作权限。方式如下：
   • 直接将操作权限赋予给用户。
   • 将ACL赋权给角色，再将角色赋权给用户。 如果资源没有设置Label，那么此时用户已经拥有该资源的权限。
3. 对于拥有Label的资源（例如数据表、打包了数据表的Package），还需要为用户赋予Label权限。方式如下：
   • 针对某个数据表的字段授权。
   • 针对某个数据表授权（暂不支持）。
   • 针对某个Package授权。
   • 针对指定用户进行批量的Label授权，不支持对角色进行Label授权。

用户认证

用户认证（Authentication）的主要功能是检查请求（Request）发送者的真实身份。一般包括如下两个方面：

• 正确验证消息发送方的真实身份。
• 正确验证接收到的消息在途中是否被篡改。

**

项目空间的用户及授权管理

概述

项目空间（Project）是MaxCompute实现多租户体系的基础，是用户管理数据和计算的基本单位。当用户申请创建一个项目空间之后，该用户就是这个空间的所有者（Owner）。也就是说，这个项目空间内的所有对象（表、实例、资源、UDF等）都属于该用户。除了Owner之外，任何人都无权访问此项目空间内的对象，除非有Owner的的授权许可。

用户管理

添加用户

当项目空间的Owner Alice决定对另一个用户授权时，Alice需要先将该用户添加到自己的项目空间中来。只有添加到项目空间中的用户才能够被授权。
添加用户的命令如下：

--在当前项目空间中添加用户
add user <full_username>

移除用户

当一个用户离开此项目团队时，Alice需要将该用户从项目空间中移除。用户一旦从项目空间中被移除，该用户将不再拥有任何访问项目空间资源的权限。
移除用户的命令如下：

--在项目空间中移除用户
remove user <full_username>

说明

• 当一个用户被移除后，该用户不再拥有访问该项目空间资源的任何权限。
• 移除一个用户之前，如果该用户已被赋予某些角色，则需要先撤销该用户的所有角色。
• 当一个用户被移除后，与该用户有关的ACL授权仍然会被保留，但Role级别的Policy授权会失效，项目空间级别的会被保留。一旦该用户被再添加到该项目空间时，该用户的历史的ACL授权访问权限将被重新激活。
• MaxCompute目前不支持在项目空间中彻底移除一个用户及其权限数据。

角色管理

角色（Role）是一组访问权限的集合。当需要对一组用户赋予相同的权限时，可以使用角色来授权。基于角色的授权可以大大简化授权流程，降低授权管理成本。当需要对用户授权时，应当优先考虑是否应该使用角色来完成。
每一个项目空间在创建时，会自动创建一个admin的角色，并且为该角色授予了确定的权限：能访问项目空间内的所有对象，能进行用户与角色管理，能对用户或角色进行授权。与项目空间Owner相比，admin角色不能将admin权限指派给用户，不能设定项目空间的安全配置，不能修改项目空间的鉴权模型。Admin角色所对应的权限不能被修改。
**
角色管理的相关命令如下：

--创建角色
create role <rolename>

--删除角色
drop role <rolename>

--给用户指派某种角色
grane <rolename> to <username>

--撤销角色指派
revoke <rolename> from <username>

删除一个角色时，MaxCompute会检查该角色内是否还存在其他用户。若存在，则删除该角色失败。只有在该角色的所有用户都被撤销时，删除角色才会成功。

ACL授权操作

授权操作一般涉及到三个要素：主体（Subject）、客体（Object）和操作（Action）。在MaxCompute中，主体是指用户，客体是指项目空间中的各种类型对象，操作则与特定对象类型有关，不同类型的对象支持的操作也不尽相同。

说明：
上述权限描述中，Project类型对象的CreateTable权限操作，Table类型对象的Select、Alter、Update、Drop权限操作需要与Project对象的CreateInstance权限操作配合使用。单独使用上述几种权限而没有指派CreateInstance权限是无法完成对应操作的。

在添加用户或创建角色之后需要对用户或角色进行授权。MaxCompute ACL授权是一种基于对象的授权，通过授权的权限数据（即访问控制列表，Access Control List）被看做是该对象的一种子资源，只有当对象已经存在时，才能进行授权操作。当对象被删除时，通过授权的权限数据会被自动删除。

MaxCompute ACL支持的授权方法是采用类似SQL92定义的GRANT/REVOKE命令进行授权。通过对应的授权命令来完成对已存在的项目空间对象的授权或撤销授权。

命令格式：

grant actions on object to subject
revoke actions on object from subject
actions ::= action_item1, action_item2, ...
object ::= project project_name | table schema_name | instance inst_name | function func_name | resource res_name
subject ::= user full_username | role role_name

MaxCompute ACL的授权命令并不支持[WITH GRANT OPTION]授权参数。即当用户A授权用户B访问某个对象时，用户B无法将权限进一步授权给用户C。因此，所有的授权操作都必须由具有如下三种身份之一的用户完成：

• 项目空间Owner。
• 项目空间中拥有admin角色的用户。
• 项目空间中对象创建者。

权限查看

--查看当前用户自己的访问权限
show grants

--查看指定用户的访问权限，仅Project Owner和Admin可以操作
show grants for <username>

--查看指定角色的权限
describe role <rolename>

--查看指定对象的授权列表
show acl for <objectName> [on type <objectType>]
--当省略[on type <objectType>]时，默认的type为Table。

在展现用户权限或角色权限时，MaxCompute使用了如下的标记字符：A、C、D、G，含义如下：

• A：表示Allow，即允许访问。
• D：表示Deny，即拒绝访问。
• C：表示with Condition，即为带条件的授权，只出现在policy授权体系中。
• G：表示with Grant option，即可以对object进行授权。

标签安全策略（LabelSecurity）

MaxCompute通过基于标签的安全策略（LabelSecurity）实现用户对列级别敏感数据的访问。LabelSecurity是项目级别的一种强制访问控制策略。

DAC与MAC

自主访问控制策略DAC（Discretionary Access Control）：由客体的属主对自己的客体进行管理，由属主决定是否将自己的客体访问权或部分访问权授予其他主体，这种控制方式是自主的。即在自主访问控制下，用户可以按自己的意愿，有选择地将权限授予给其他用户。
强制访问控制策略MAC（Mandatory Access Control）：一种由系统约束的访问控制，目标是限制主体对对象执行某种操作的能力。
在MaxCompute中，强制访问控制机制MAC独立于自主访问控制机制DAC。

数据的敏感等级分类

LabelSecurity需要将数据和访问数据的人进行安全等级划分。
在政府和金融机构，通常将数据的敏感度标记（Label）分为四类，0级（不保密，Unclassified）、1级（秘密，Confidential）、2级（机密，Sensitive）、3级（高度机密，Highly Sensitive）。
MaxCompute也遵循这一分类方法。项目所有者（Project Owner）需要定义明确的数据敏感等级和访问许可等级划分标准。默认情况下所有用户的访问许可等级为0级，数据安全级别为0级。
LabelSecurity对敏感数据的支持如下：

• 最小支持粒度为列级别。
• 支持管理员对表的任何列设置敏感度标记，一张表可以由不同敏感等级的数据列构成。
• 支持管理员对视图设置敏感度标记。视图的等级和它对应的基表的敏感度标记等级是独立的。视图创建时，默认的等级也是0。

默认安全策略

在对数据和用户分别设置安全等级标记之后，基于标签的默认安全策略如下：

• No-ReadUp：不允许用户读取敏感等级高于用户等级的数据，除非有显式授权。
• Trusted-User：允许用户写任意等级的数据，新创建的数据默认为0级（不保密）。

项目中的LabelSecurity安全机制默认是关闭的，Project Owner可以自行开启。LabelSecurity安全机制一旦开启，上述的默认安全策略将被强制执行。当用户访问数据表时，除了必须拥有SELECT权限外，还必须获得读取敏感数据的相应许可**等级**。

LabelSecurity操作

• 开启LabelSecurity安全机制，默认情况下为False。该操作必须由Project Owner完成。

  Set LabelSecurity=true|false;
  

• 为用户设置安全许可标签。

该操作只能由Project Owner或Admin角色完成。number取值范围为[0, 9]。

SET LABEL <number> TO [USER|ROLE] <name>;

• 给数据设置敏感等级标签。

该操作只能由Project Owner或Admin角色完成。number取值范围为[0, 9]。

SET LABEL <number> TO TABLE tablename;
SET LABEL <number> TO TABLE tablename(column_list);

注意：显式地对列设置的标签会覆盖对表设置的标签，与标签设置的顺序以及敏感等级的高低无关。

• 显式授权低级别用户访问高敏感级数据表。

  • 授权低级别用户访问高敏感级数据表。 不指定WITH EXP 时，默认过期时间是180天。

    GRANT LABEL <number> ON TABLE <tablename>[(column_list)] TO [USER|ROLE] <name> [WITH EXP <days>];
    

  • 撤销授权。取消用户对表的label权限，会同时取消该用户对表字段的label的权限。

    REVOKE LABEL ON TABLE <tablename>[(column_list)] FROM [USER|ROLE] <name>;
    

  • 清理过期的授权。

    CLEAR EXPIRED GRANTS;
    

• 查看指定用户可以访问的敏感数据集。

  SHOW LABEL [<level>] GRANTS [FOR USER <username>];
  

  参数说明：

  • FOR USER ：指定查询用户。省略此参数时，默认查看当前用户所能访问的敏感数据集。
  • ：指定查询等级。省略此参数时，将显示所有label等级的授权；如果指定此参数，则只显示指定等级的授权。

• 查看允许访问指定敏感数据表的用户。

  SHOW LABEL [<level>] GRANTS ON TABLE <tablename>;
  

• 查看指定用户对一个数据表的所有列级别的Label权限。

  SHOW LABEL [<level>] GRANTS ON TABLE <tablename> FOR USER <username>;
  

• 查看一个表中所有列的敏感等级。

  DESCRIBE <tablename>;
  

• 控制Package安装者对Package中敏感资源的许可访问级别。 此命令需要Package创建者执行。

  ALLOW PROJECT <prjName> TO INSTALL PACKAGE <pkgName> [USING LABEL <number>];
  

  命令说明如下：

  • [USING LABEL ]：指定访问数据敏感等级。不指定时，默认为0级，即只可以访问非敏感数据。
  • 跨项目访问敏感数据时，package安装者所在项目中的所有用户都将使用此命令中许可的访问级别。

跨项目空间的资源分享

概述

Package是一种跨项目空间共享数据及资源的机制，主要用于解决跨项目空间的用户授权问题。使用Package后，项目空间A的管理员可以对另一个项目空间B的成员需要使用的对象进行打包授权（也就是创建一个Package），然后项目空间B的管理员安装该Package之后，就可以自行管理Package是否需要进一步授权给自己Project下的用户。

Package的使用涉及到两个主体：Package创建者和Package使用者。Package创建者项目空间是资源提供方，它将需要分享的资源及其访问权限进行打包，然后许可Package使用方来安装使用。Package使用者项目空间是资源使用方，它在安装资源提供方提供的Package之后，便可以直接跨项目空间访问资源。

Package使用方法

Package创建者相关操作

--创建Package
create package <pkgname>

--删除Package
delete package <pkgname>

--将需要分享的资源添加到Package
add project_object to package package_name [with privileges <privileges>]
remove project_object from package package_name
project_object ::= table table_name | instance inst_name | function func_name | resource res_name
privileges ::= action_item1, action_item2

--许可其他项目空间使用Package
allow project <prjname> to install package <pkgname> [using label <number>]

--撤销其他项目空间使用Package的许可
disallow project <prjname> to install package <pkgname>

--查看已创建及安装的Package列表
show packages

--查看Package详细信息
describe package <pkgname>

说明：

• 目前支持的对象类型不包括Project类型，也就是不允许通过Package在其他Project中创建对象。
• 添加到Package中的不仅仅是对象本身，还包括相应的操作权限。当没有通过[with privileges privileges]来指定操作权限时，默认为只读权限，即Read/Describe/Select。“对象及其权限”被看作一个整体，package内的资源可以添加和删除，一旦添加和删除后，原先授予的权限也会被回收掉。

Package使用者相关操作

被安装的Package是一种独立的MaxCompute对象类型。若要访问Package里的资源（即其他项目空间分享给用户的资源），用户必须拥有对该Package的Read权限。如果请求者没有Read权限，则需要向Project Owner或Admin申请。Project Owner或Admin可以通过ACL授权或Policy授权机制来完成。

--通过ACL授权允许云账号用户odps_test@aliyun.com访问Package里的资源
use prj2 security
install package prj1.testpkg
grant read on package prj1.testpackage to user aliyun$odps_test@aliyun.com

--通过Policy授权允许项目空间prj2中的任何用户都可以访问Package里的资源
use prj2
install package prj1.testpkg
put policy /tmp/policy.txt

--policy.txt内容如下
{
  "Version": "1", "Statement": [{
  "Effect":"Allow",
  "Principal":"*",
  "Action":"odps:Read", "Resource":"acs:odps:*:projects/prj2/packages/prj1.testpkg"
}]
}

--安装Package
install package <projectName>.<packageName>;

--卸载Package
uninstall package <projectName>.<packageName>;

--查看已创建和已安装的package列表。
show packages

--查看package详细信息
describe package <pkgname>

项目空间的数据保护

作为MaxCompute项目空间管理员，如果用户对项目空间中的数据非常敏感，绝对不允许流出到其他项目空间中去，希望MaxCompute能将所有可能导致数据流出的操作禁止掉，则需要进行如下的相关设置及操作。

概述

数据保护机制

MaxCompute提供的项目空间保护机制可以将所有可能导致数据流出的操作禁止掉。用户只需要在其项目空间中做如下设置：

--设置ProjectProtection规则：数据只能流入、不能流出，默认为False
set security.ProjectProtection=true

设置ProjectProtection后，用户的项目空间中的数据流向就会得到控制，即数据只能流入，不能流出。

开启数据保护后的数据流出方法

在ProjectProtection被设置之后的两种数据到存储途径

设置ExceptionPolicy

Project Owner在设置ProjectProtection时可以附带一个exception策略，命令如下：

SET ProjectProtection=true WITH EXCEPTION <policyFile>

上述这种policy不同于Policy授权（尽管与Policy授权语法完全一样），它只是对项目空间保护机制的例外情况的一种描述，即所有符合policy中所描述的访问情形都可以打破ProjectProtection规则。

下面给出一个exception policy的示例。
假设，允许云账号Alice@aliyun.com可以通过SQL任务对表alipay.table_test执行Select操作时将数据流出到alipay项目之外。

{"Version": "1", "Statement": [{
"Effect":"Allow", "Principal":"ALIYUN$Alice@aliyun.com",
"Action":["odps:Select"],
"Resource":"acs:odps:*:projects/alipay/tables/table_test",
"Condition":{
"StringEquals": { "odps:TaskType":["DT", "SQL"]
}}
}]
}

说明

• Exception policy并不是一种普通的授权。如果云账号Alice并没有对表alipay.table_test的Select操作权限，即使设置了上述exception policy，Alice仍然是无法导出数据。ProjectProtection是一种数据流向的控制，而不是访问控制。只有在用户能访问数据的前提下，控制数据流向才是有意义的。
• TOC2TOU（time-of-check to time-of-use）数据泄露问题（又称Race Condition问题）。问题描述如下：
  1. 【TOC阶段】用户A向Project Owner申请将t1导出，Project Owner对t1的数据敏感程度进行评估，Pass后通过exception policy授权A可以导出t1。
  2. 恶意用户修改了t1的内容，将敏感数据写入到t1。
  3. 【TOU阶段】用户A将t1的内容导出。此时导出的t1已经不是Project Owner审查的那个t1了。

防止TOC2TOU问题的建议：对于用户申请导出的表，Project Owner需要确保没有任何其他用户（含admin）能对该表进行更新（Update）操作或重建同名表操作（Drop+CreateTable）。对于TOC2TOU问题描述中的场景，建议Project Owner在第一步中以Project Owner身份创建t1的一个snapshot，设置exception policy时使用这个snapshot，并且不要授予admin角色给任何用户。

设置TrustedProject

若当前项目空间处于受保护状态，如果将数据流出的目标空间设置为当前空间的TrustedProject，那么向目标项目空间的数据流向将不会视为触犯ProjectProtection规则。如果多个项目空间之间两两互相设置为TrustedProject，那么这些项目空间就形成了一个TrustedProject Group，数据可以在这个Project Group内流动，但禁止流出到Project Group之外。

管理TrustedProject的命令如下：

--查看当前project中的所有TrustedProjects
list trustedprojects
--在当前project中添加一个TrustedProjects
add trustedprojects
--在当前project中移除一个TrustedProjects
remove trustedprojects

资源分享与数据保护

在MaxCompute中，基于package的资源分享机制与项目空间的数据保护机制是正交的两种安全机制，但在功能上却是相互制约的。
MaxCompute规定：资源分享优先于数据保护。即如果一个数据对象是通过资源分享方式授予其他项目空间的用户访问，那么该数据对象将不受ProjectProtection规则的限制。
如果要防止数据从项目空间的流出，在设置ProjectProtection=true之后，还需检查如下配置：

• 确保没有添加trustedproject，如果有设置，则需要评估可能的风险。
• 确保没有设置exception policy，如果有设置，则需要评估可能的风险，尤其要考虑TOC2TOU数据泄露风险。
• 确保没有使用package数据分析，如果有设置，则需要确保package中没有敏感数据。

项目空间的安全配置

MaxCompute支持多种正交的授权机制，但并非所有用户都需要使用这些安全机制，用户可以根据自己的业务安全需求或使用习惯，合理设置本项目空间的鉴权模型。

--查看项目空间的安全配置
show SecurityConfiguration

--激活/冻结ACL授权机制，默认为true
set security.CheckPermissionUsingACL=true/false

--激活/冻结Policy授权机制，默认为true
set security.CheckPermissionUsingPolicy=true/false

--允许/禁止对象创建者默认拥有访问权限，默认为true
set security.ObjectCreatorHasAccessPermission=true/false

--允许/禁止对象创建者默认拥有授权权限，默认为true
set security.ObjectCreatorHasGrantPermission=true/false

--开启/关闭LabelSecurity安全策略
set security.LabelSecurity=true/false

--开启/关闭项目空间的数据保护机制，禁止/允许数据流出项目空间
set security.ProjectProtection=true/false

Policy权限策略

Policy概况

Policy授权是一种基于主体的授权。通过Policy授权的权限数据（即访问策略）被看做是授权主体的一种子资源。只有当主体（用户或角色）存在时，才能进行Policy授权操作。当主体被删除时，通过Policy授权的权限数据会被自动删除。Policy授权使用MaxCompute自定义的一种访问策略语言来进行授权，允许或禁止主体对项目空间对象的访问权限。

Policy授权主要解决ACL授权机制无法解决的一些复杂授权场景，例如：

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

Policy授权命令格式如下：

--读取项目空间的Policy。
GET POLICY; 

--设置（覆盖）项目空间的Policy。
PUT POLICY <policyFile>;

--读取项目空间中某个角色的Policy。
GET POLICY ON ROLE <roleName>; 

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

MaxCompute目前支持的Policy类型有Project Policy和Role Policy。Project Policy对Project中的所有用户有效，而Role Policy只对已赋予角色的用户有效。在Policy格式上，Project Policy必须指定Principal（用户），而Role Policy则不能指定Pricipal（因为用户与角色的指派关系已经存在）。

Policy样例如下，详细编写语法见专有云手册

{"Version": "1", "Statement": [{
"Effect":"Allow", "Principal":"ALIYUN$alice@aliyun.com",
"Action":["odps:CreateTable","odps:CreateInstance","odps:List"], 
"Resource":"acs:odps:*:projects/test_project",
"Condition":{ "DateLessThan": {
"acs:CurrentTime":"2017-11-11T23:59:59Z"
},
"IpAddress": { "acs:SourceIp":"10.32.180.0/23" }}
},
{"Effect":"Deny", "Principal":"ALIYUN$alice@aliyun.com", "Action":"odps:Drop", "
Resource":"acs:odps:*:projects/test_project/tables/*"
}]
}

每种Policy只支持一个Policy文件，由于Put Policy操作会覆盖已有的Policy，当用户需要修改Policy时，应按如下顺序分布操作：

1. Get Policy。
2. 用户自己Merge Policy Statements。
3. Put Policy。

Policy基本术语

权限（Permission）是访问控制的一个基本概念，它表示允许或拒绝一个请求者（Requester）对资源（Resource）执行某种操作（Action）。用语句（Statement）来表示单个权限的形式化描述，而用策略（Policy）来表示语句的集合。
访问策略（Access Policy）主要包括如下的访问控制元素：主体（Principal）、操作（Action）、资源（Resource）、访问限制（Access Restriction）和效力（Effect）。

主体

主体是指访问策略中的权限被指派的对象。

操作

操作是指主体对资源的访问方法。

资源

资源是指主体请求访问的对象。

访问限制

访问限制是指权限生效的限制条件。

效力

授权效力包括两个方面：允许操作（Allow）和拒绝操作（Deny），通常，Deny有更高的效力，在权限检查时会优先使用。

注意：
拒绝操作和撤销授权是完全独立的两个概念，撤销授权通常包括撤销对Allow和Deny这两种不同效力的授权。例如传统数据库一般支持Revoke和Revoke Deny两种操作。

访问策略语言结构

详见专有云手册 用户指南 1.20.8.3

访问策略语言规范

详见专有云手册 用户指南 1.20.8.4

Policy与ACL的区别

ACL授权的特点：

• 授权或撤销授权时，要求:Grantee（如User或Role）和Object （如Table）必须已经存在。这点与Oracle授权特性相似，可以避免删除并重建同名对象所带来的安全风险。
• 删除一个对象时，自动撤销与该对象关联的所有授权。
• 仅支持Allow（白名单）授权，不支持Deny（黑名单）授权。
• 使用经典的Grant/Revoke授权命令进行授权。命令简单，使用时不易出错。不支持带限制条件的授权。
• 适合于简单的授权需求：授权不带限制条件，不需要Deny，并只需要对已存在对象进行授权。

Policy授权的特点：

• 授权或撤销授权时，不关心Grantee或Object存在与否。授权对象可以支持以通配符””来表达，例 如，projects/tbproj/tables/taobao，它表示项目空间tbproj中所有以taobao开头的表。这点
• 与Mysql授权特性相似，它允许对不存在的对象授权，授权者应考虑到删除并重建同名对象所带来的安全风险。
• 删除一个对象时，与该对象关联的Policy授权不会被删除。
• 同时支持Allow（白名单）和Deny（黑名单）授权。当Allow和Deny授权同时存在时，遵循Deny优先原则。
• 支持带限制条件的授权。授权者可以对Allow或Deny授权施加条件限制（目前支持20种条件操作）。例如，允许请求者的IP为指定的IP地址范围，同时访问时间必须在2017-11-11 23:59:59之前。
• 适合于相对复杂的授权需求：带授权限制条件，有Deny授权需求，希望支持对未来的对象授权。
• 使用Policy授权命令进行授权，命令较为复杂。

应用限制

详见专有云手册 用户指南 1.20.8.6