标签:角色 因此 数据安全 .com 分组 部署 list object pre
通过《MaxCompute安全管理-基础篇》了解到MaxCompute和DataWorks的相关安全模型、两个产品安全方面的关联,以及各种安全操作后,本篇主要给出一些安全管理案例,给安全管理的成员作为参考。
前面了解了MaxCompute和DataWorks的安全模型以及两个产品之间的权限联系,本章节我们以常见2个基础业务需求来介绍项目创建和管理。
场景描述:多人协同开发,成员责任划分明确,需走正常的开发、调试、发布流程,生产数据查看须严格控制。
分析:
实操:
创建项目。主要配置如图:
添加项目成员。DataWorks上添加RAM子账号为项目成员,按需分配角色,同时,对应开发project会将对应的role授权给子账号(各个role拥有的权限请看前面《基础篇之MaxCompute和DataWorks权限关系》章节):
这一整套配置和操作流程走完后,需要注意几点:
场景描述:业务单一,成员角色基本一致,后续业务也不会扩展。如专供取数即不做数据开发,只需要查询下载业务数据(比如运营角色需要获取一些数据进行分析)。
分析:
实操:
创建MaxCompute自定义role并授权。主账号通过console进行操作:
create role custom_dev;--创建自定义role
grant List, CreateInstance,CreateTable,CreateFunction,CreateResource on project prj_name to role custom_dev;--给自定义role赋权
MaxCompute的project设置“允许对象创建者默认拥有访问权限”。主账号通过console操作:
set ObjectCreatorHasAccessPermission=true; --实际上这个flag默认已经为true,可以通过如下命令查看
show SecurityConfiguration;
也可以在DataWorks的‘项目管理——MaxCompute设置’中进行配置。
添加项目成员。DataWorks上添加子账号为新成员,如添加成员时角色为“开发”,添加成功后,在对应MaxCompute的project里该成员对应的role是role_project_dev,主账号通过consle命令行查看如:
show grants for ram$主账号:子账号;
修改新成员的MaxCompute权限。主账号通过consle操作:
revoke role_project_dev from ram$主账号:子账号;--将新成员从默认授予的role中移除。注意,如果后期又通过DataWorks成员管理页面在操作授予成员角色,那么也会重新授予该MaxCompute role。
grant custom_dev to ram$主账号:子账号;--给新成员授予自定义角色。
至此,该特殊需求权限管理的项目已经配置好。还需要注意以下几点:
该项目成员需要查询的表的权限需要自己走正常的权限申请流程(可在DataWorks的数据管理中申请),或者通过package授权方式,把其他生产项目的表加到package中,再将package安装到该项目并授权给成员,具体可以参考《基础篇之package授权管理》章节。
场景:业务分析人员需要查生产表,但是不允许查看生产任务代码,需要将多个生产项目的部分表开放给业务分析人员。
场景分析:需要查生产表但是又不能查看生产任务,那么需要单独给创建一个项目。可以通过在多个生产项目创建package把需要开放的表加到package中,在分析项目中安装package并授权给分析人员,如此可以 减少成员管理成本无需在所有生产项目中add 分析人员,同时保证这些分析人员只能在分析项目中查看package中的表。
操作步骤:
1) 生产项目中创建Package:
CREATE PACKAGE PACKAGE_NAME;
如:
CREATE PACKAGE prj_prod2bi;
2) 生产项目中向Package中添加需要分享的资源:
ADD table TO PACKAGE [包名称];
如:
ADD table adl_test_table TO PACKAGE prj_prod2bi;
3) 生产项目许可分析项目空间使用Package
ALLOW PROJECT [允许安装的 project] TO INSTALL PACKAGE [包名称];
如:
ALLOW PRJ_BI TO INSTALL PACKAGE prj_prod2bi;
4) 分析项目安装 package:
INSTALL PACKAGE [应用名].[包名称];
如:
INSTALL PACKAGE prj_prod.prj_prod2bi;
5) package赋权给使用者:
赋权给user:
GRANT read on package prj_prod2bi TO USER [云账号];
赋权给role:
GRANT read on package prj_prod2bi TO ROLE [rolename];
场景:项目初期为了加快进度,一些用户和权限管理就相对宽松,当项目工作进入了一个相对稳定发展阶段后,数据安全将成为管理方面越来越重要的点。此时需要对数据安全进行自查分析,生成一个方案并落地。
本案例主要通过介绍某客户进行数据安全自查后重点调整的方向给出数据安全调整思路。
自查思路
存量账号数量及权限统计。
废弃账号及权限统计:对于已在MaxCompute或DateWorks项目中拥有角色的RAM子账号,请在删除子账号之前解除子账号在项目的角色并在项目空间中删除子账号。否则子账号会在项目空间中残留,显示为“ p4_xxxxxxxxxxxxxxxxxxxx”且无法在项目空间中移除(不影响项目空间正常功能使用)。
但若是因职位发生变化的账号及遗留权限,需要回收。建议有些不是长期使用的成员账户,有些申请了但是长期不用的账户,可以在通过通知、调研,把这部分账户清理。做到有的放矢,权限在用的时候再申请,用完后,可以再收回。
个人账号调查分析(可以工单申请推送元仓数据进行分析统计)。通过调查个人账号最近3个月在开发阶段提交的查询(提交的数据检索、计算任务,主要是以SQL任务为主。),统计topN用户,并选取代表性账号分析其日常任务。
如,账号对应成员主要工作的项目空间为算法开发项目,日常工作主要执行的任务是SQL任务,执行的SQL任务主要是开发环境的查询和写表操作。算法任务、MR任务相对SQL任务数量较少,但是都有分布。这也符合数据开发的实际情况,能用SQL处理,一般优先使用SQL处理数据。
又如,有个账号提交的任务非常多,经了解其将自己的ak通过adk方式配置了一个查询软件,并提供多人进行查询,这种多人共用一个账号需要整改。
调整要点
账号以及全新合理分配。调整原则:每个工作成员都使用自己的个人账户。
针对不同人员所在的的不同业务开发小组和角色给出不同的数据访问权限,禁止相互借用他人的账户使用。避免因为用户权限过大导致的数据安全风险。
如,按数据开发过程的业务分组进行账号分配。分组如管理组、数据集成组、数据模型组、算法组、分析组、运维组、安全组等。
业务小组 | 账户数 | ||
---|---|---|---|
管理组 | N | ||
…… | …… | ||
-- | -- | -- | -- |
管理组 | project1 | powner@aliyun.com:user1 | 管理员 |
管理组 | project2 | powner@aliyun.com:user1 | 管理员 |
…… | …… | …… | …… |
如通过MaxCompute层面限制数据只能流动到指定的项目或者指定的位置,从而规避未知数据流动带来的风险。
数据导出限制。
数据一旦从MaxCompute落地为文件,就意味着数据不可控。所以,必须要尽可能的减少数据落地带来的风险。通过用户角色的详细划分,限制只有一些业务组可以有数据导出的权限。且也不影响日常开发工作。
标签:角色 因此 数据安全 .com 分组 部署 list object pre
原文地址:https://www.cnblogs.com/zhaowei121/p/10276843.html