MaxCompute数据权限控制详情

DataWorks空间级预设角色默认可以访问开发环境引擎项目权限，但无法直接访问生产环境引擎项目。即可以直接访问开发表、资源、函数，但无法直接访问生产表、资源、函数。

为了保障生产数据安全，在标准模式工作空间下，DataWorks对RAM用户（子账号）访问MaxCompute表的操作进行了管控。

• 获得开发项目权限过程（自动获得）：

  • 工作空间成员被授予预设角色的同时获得引擎项目权限，详情请参见场景一：空间级预设角色授权过程。

  • 工作空间成员被授予自定义角色的同时获得引擎项目权限，详情请参见场景二：空间自定义角色授权过程。

• 获得生产项目权限（需要人为申请）：需要进入安全中心申请，使用场景如下表所示，更多关于安全中心的使用详情参见MaxCompute数据访问权限控制。

  场景	说明
  同工作空间内，开发环境用户访问生产环境表	当DataWorks的子账号未被添加为生产环境计算引擎访问身份时，默认该账号无法在数据开发界面直接操作本工作空间的生产表，如果子账号需要拥有生产表权限，需要在安全中心发起申请，待审批通过后，便可在数据开发界面对表进行相关操作。
  开发或生产环境用户访问跨工作空间的开发或生产环境表	默认不在工作空间下的子账号无法在数据开发界面跨项目访问开发表或生产表。如果需要跨项目操作开发表或生产表，子账号需要在安全中心发起申请，待审批通过后，便可在数据开发界面对表进行相关操作。

RAM用户（子账号）若需要访问生产数据，需要进行流程审批，管理员可对生产环境权限进行管控。

1. 安全中心内置审批流程可进行生产表权限审批。

2. 审批中心支持自定义审批流程。

您可以在MaxCompute_SQL任务中，执行如下语句，查询自己的权限信息。

• show grants：查看当前用户自己的访问权限。

• show grants for <username>：查看指定用户的访问权限，仅空间管理员才有执行权限。

完成添加成员操作后，在DataWorks层面和MaxCompute引擎层面均有了部分权限，此RAM用户可在DataWorks层面和MaxCompute引擎层面进行的操作权限详情如下。

• DataWorks层面：给RAM用户授予开发角色后，该用户可以在DataWorks开发代码并且提交，但是不能将代码直接发布到生产环境，发布生产的操作需要有运维权限（项目所有者、管理员、运维这几类角色拥有此权限）。

• MaxCompute引擎层面：给RAM用户授予开发角色后，在MaxCompute引擎层面同时为这个RAM用户授予了一个Role_Project_Dev这个角色，这个角色会被赋予部分MaxCompute引擎开发项目的表和项目的权限。

  说明

  • 当授予阿里云RAM用户预设管理员角色，其拥有的DataWorks功能权限较多，但同样不能直接访问生产表。

  • 此处说明的RAM用户特指，未被指定为非调度引擎访问身份（未被指定为生产项目MaxCompute访问身份）的子账号。

场景示例：某个RAM用户被一个拥有空间管理员权限的用户添加为工作空间成员，并授予DataWorks工作空间自定义角色权限。新建DataWorks空间自定义角色时，您可以指定此角色是否与MaxCompute引擎的某个角色做映射，角色新建完成后，可以在添加成员时关联此自定义角色，完成后，被添加为成员的RAM用户在DataWorks层面和MaxCompute引擎层面均有了部分权限，此RAM用户可在DataWorks层面和MaxCompute引擎层面进行的操作权限详情如下。

• DataWorks层面：DataWorks上给一个RAM用户授予DataWorks自定义角色，该用户只能访问自定义角色所赋予的模块权限。

• MaxCompute引擎层面：

  • 如果该DataWorks自定义角色未设置引擎权限映射，那么RAM用户没有MaxCompute引擎的操作权限，无法通过命令进行引擎查询等相关操作。

  • 如果该DataWorks自定义角色设置了引擎权限映射，那么RAM用户有自定义角色所映射的引擎权限，所拥有的操作权限与映射的MaxCompute引擎的角色一致。