标签:字母 access 使用 dea 操作权限 还需要 影响 user 好的
背景及目的用户认证。
支持 云账号 和 RAM 账号 两种账号体系,对于RAM账号,仅识别账号体系不识别RAM权限体系,即可将主账号自身的任意 RAM 子账号加入 MaxCompute 的某一个项目中,但 MaxCompute 在对该 RAM 子账号做权限验证时,并不会考虑 RAM 中的权限定义。
用户与授权管理。
在MaxCompute Project中对用户添加(add)、移除(remove)、授权(grant)管理。
还可以通过角色(role)管理授权,MaxCompute project默认有admin role。
而授权方式包含ACL和Policy方式,本文只讲ACL方式,Policy方式待后续升级篇中介绍。
ACL即似于 SQL92 定义的 GRANT/REVOKE 语法,它通过简单的授权语句来完成对已存在的项目空间对象的授权或撤销授权。授权语法如下:
grant actions on object to subject
revoke actions on object from subject
标签安全策略
基于标签的安全(LabelSecurity)是项目空间级别的一种强制访问控制策略(Mandatory Access Control, MAC),它的引入是为了让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问。
跨项目空间的资源分享。
Package是一种跨项目空间共享数据及资源的机制,主要用于解决跨项目空间的用户授权问题。即可以分享table、Resource、function等资源给其他项目,但是无需对其他项目的用户进行管理。
项目空间的数据保护。
主要解决“不允许用户将数据转移到项目空间之外”的需求。
对象操作赋权、Role 和 label 关系介绍
上个小节中介绍了MaxCompute体系包含多种策略,而各种策略赋权是权限递增关系。以需要获取一个L4等级表的权限来展开说明这个递增关系,主要进行以下步骤操作:
第一步: 如果用户未有过授权记录,且非本项目用户,首先需要添加一个 USER(用户),这个过程,用户还没有任何实际权限。
第二步: 赋权 USER(用户)对象的操作权限,有以下方式赋权。
1) 可以是单独的操作权限;
2) 通过 policy 方式赋权给用户;
3) 将 ACL 和 policy 赋权给 role 再赋权给用户。 如果资源是没有设置 Label 的,则此时用户已经拥有的该资源的权限。
第三步: 对于拥有 Label 的资源,例如:数据表、打包了数据表的 package,则还需要 赋权 Label 权限。有以下四钟 Label 赋权:
1) 针对某个数据表的字段;
2) 针对某个数据表;
3) 针对某个 package;
4) 给某个 USER(用户)一个批量的 Label 权限,不支持 ROLE。
各权限赋权过程及关系图如下:
数据流程保护机制和 Package 关系介绍
ProjectProtection(数据流出保护机制)是 MaxCompute 防止项目内的数据批量流出的安全功能。 开启数据流程保护后,如果相互之间没有建立“TrustedProject Group” ,与其它 project 的数据赋权就必须通过 Package 方式进行,Package 赋权后,对方 package 可以自主赋权 Package 内的资源给组内用户。
部分资源(例如某些常用表、UDF 等),如想放权给其 Package 管理,也可以通过 Package 的方式,将资源打包后赋权给其他 Project。
ProjectProtection(数据流出保护机制)支持做例外处理,部分特殊的业务场景,可以针 对应用的 IP 地址、产品云账号做 Exception 策略,以满足特殊的数据流出需求。
DataWorks安全模型
DataWorks提供多人协同数据开发工作的平台,其安全模型需要考虑几方面:
企业之间数据的安全隔离。
数据开发即ETL过程中的安全问题,如生产任务如何保障不可随意变更;如哪个成员可以进行代码编辑调试,哪个成员可以进行发布生产任务等。
由于底层MaxCompute有自己的安全模型,项目成员做ETL过程肯定会需要MaxCompute的各种资源(table、Resource、function、instance)的相关权限。
针对第一点,DataWorks的用户认证,DataWorks对接RAM,云账号可作为主账号进行开通并创建DataWorks项目,而项目成员必须为该主账号的RAM子账号不能是其他云账号。
另外,同个主账号创建的项目作为一个组织,项目与项目之间的任务可以进行依赖配置;不同主账号创建的项目之间数据(各种任务)隔离。
针对第二点,DataWorks通过业务划分“开发项目”、“生产项目”进行任务开发调试和稳定生产的隔离;通过成员角色控制哪个成员可以进行任务开发调试,哪个成员可以运维生产任务等。
针对第三点,DataWorks在MaxCompute Project创建成功的同时,在MaxCompute Project里对应DataWorks的角色创建role,并给不同role赋权。
MaxCompute和DataWorks权限关系
从前面介绍的MaxCompute和DataWorks两个小节可以知道,通过MaxCompute的安全模型进行权限控制,并不会影响成员在DataWorks任何界面操作。通过DataWorks的用户角色分配,是有可能影响成员的MaxCompute资源权限。下面我们详细介绍这两个产品之间权限如何交叉关联。
项目关系
通过MaxCompute或DataWorks官网产品页进入的控制台创建的项目,
DataWorks 两种选择:
简单模式的项目实际上是创建了关联绑定好的一个MaxCompute project和一个DataWorks项目空间,同时在MaxCompute 的project里创建对应的几个role,具体role权限后续小节会介绍。
标准模式的项目实际上是创建了关联绑定好的一个开发(dev)MaxCompute project、一个生产(prod)MaxCompute project对应一个DataWorks项目空间。同时在MaxCompute 的project里创建对应的几个role,具体role权限后续小节会介绍。
账号认证
云账号在DataWorks项目中只能是主账号即项目owner,在MaxCompute既可以为owner也可以为普通user。当通过DataWorks项目成员管理添加成员时只能是添加当前项目主账号对应的RAM子账号。而MaxCompute可以通过命令行add user xxx;命令添加其他云账号。
成员角色权限关系
如前面小节(DataWorks安全模型)说的DataWorks为了解决项目成员在ETL过程中需要的MaxCompute相关资源权限,绑定了一些MaxCompute role。具体是指DataWorks项目固定有几个成员角色,同时在对应MaxCompute project上创建了对应几个role。另外MaxCompute project本身除了project owner,也还有一个admin role。
具体权限对应如下表:
由上表可知,DataWorks角色对应的MaxCompute权限是固定的,一旦某个user通过DataWorks角色获取MaxCompute相关role权限后,又通过命令行方式获得MaxCompute的其他权限,会使该user在MaxCompute的权限与在DataWorks上看到的不一致。
用户和权限关系图
一个DataWorks项目空间绑定一个MaxCompute project,此时根据DataWorks的项目管理——MaxCompute设置中的“MaxCompute访问身份”这个属性设置决定DataWorks其他项目成员是否拥有MaxCompute project的权限。
标准模式,一个DataWorks项目空间绑定两个MaxCompute project,此时固定MaxCompute的project一个是开发项目一个是生产项目,DataWorks其他项目成员根据成员角色拥有MaxCompute 开发project对应的role权限,但没有MaxCompute生产project的权限,MaxCompute 任务需要走发布流程发布到生产project后以owner账号提交到MaxCompute执行。
用户与权限管理
用户管理
角色管理
ACL(对象操作)的授权管理
Role授权管理
package授权管理
Label授权管理
安全功能启用
设置 ProjectProtection(数据流出保护机制)
项目空间的数据保护主要解决“不允许用户将数据转移到项目空间之外”的需求。
开启 Label Security(列及安全控制)
基于标签的安全(LabelSecurity)是项目空间级别的一种强制访问控制策略(Mandatory Access Control, MAC),它的引入是为了让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问。
合理设置字段的 Label
设置访问Project的IP白名单
设置禁止DataWorks的select结果下载到本地
如何通过其它云服务提高安全管理
使用MaxCompute过程中,会关联使用到其他的云服务,因此也需要考虑通过其他云服务提高MaxCompute的安全管理。本章节主要介绍通过DataWorks使用MaxCompute时,添加项目成员必须会用到RAM子账号,那么如何在RAM子账号服务上提高安全管理。
前面《MaxCompute安全模型》章节中提到MaxCompute的用户认证“支持 云账号 和 RAM 账号 两种账号体系,对于RAM账号,仅识别账号体系不识别RAM权 限体系,即可将主账号自身的任意 RAM 子账号加入 MaxCompute 的某一个项目中,但 MaxCompute 在对该 RAM 子账号做权限验证时,并不会考虑 RAM 中的权限定义。” 因此,我们只需要从RAM子账号登录验证入手进行安全控制。
子账号密码强度设置
如果您允许子用户更改登录密码,那么应该要求他们创建强密码并且定期轮换。
您可以通过 RAM 控制台设置密码策略,如最短长度、是否需要非字母字符、必须进行轮换的频率等等。
子账号登录掩码设置
通过设置网络掩码决定哪些IP地址会受到登录控制台的影响,子用户必须只能从指定的IP地址进行登录。
及时撤销用户不再需要的权限
当一个子账号对应员工由于工作职责变更而不再使用权限时,应该及时将对应子账号的权限撤销。
标签:字母 access 使用 dea 操作权限 还需要 影响 user 好的
原文地址:http://blog.51cto.com/14031893/2343412