MaxCompute安全管理指南-案例篇

经过《MaxCompute安全管理-基础篇》了解到MaxCompute和DataWorks的相关安全模型、两个产品安全方面的关联，以及各类安全操做后，本篇主要给出一些安全管理案例，给安全管理的成员做为参考。

项目建立案例

前面了解了MaxCompute和DataWorks的安全模型以及两个产品之间的权限联系，本章节咱们以常见2个基础业务需求来介绍项目建立和管理。

基本ETL开发业务项目

场景描述：多人协同开发，成员责任划分明确，需走正常的开发、调试、发布流程，生产数据查看须严格控制。

分析：

• 多人协同开发，DataWorks项目自己就知足这一点。
• 成员责任划分明确，DataWorks的基础成员角色（项目管理、开发、运维、部署、访客）基本能够知足需求。
• 走正常开发、调试、发布流程，生成数据需严格控制，这些经过DataWorks建立的“开发”“生成”项目能够进行控制。

实操：

1. 建立项目。主要配置如图： 
   

   • 项目模式选“择标准模式（开发跟生产隔离）”。这个模式建立的结果是一个DataWorks项目空间绑定关联两个MaxCompute project（分开发和生产project）。开发环境上进行开发调试，生产环境任务由开发环境走发布流程发布过来进行稳定运行。
   • 开发环境“MaxCompute访问身份”为我的帐号。项目成员在开发环境作任务开发调试时用我的帐号进行操做，这样作的目的在于，每一个成员根据业务需求在开发调试过程当中须要用到的MaxCompute各类生产资源（table、Resource、function）不一样，为了防止权限过大，每一个成员本身申请本身所需的权限（主要是生产表权限），同时还能够更好的作后续的安全审计。
   • 生产环境“MaxCompute访问身份”为项目负责人帐号即project的owner。生产环境要保障稳定和安全生产，正常状况下：不容许成员能够随意提交job，不容许我的帐号拥有生产表的删除、修改权限以避免经过命令行工具进行操做没法受到更好的控制，我的帐号须要读生产表权限必须走申请以便更好的管理数据安全。

2. 添加项目成员。DataWorks上添加RAM子帐号为项目成员，按需分配角色，同时，对应开发project会将对应的role受权给子帐号（各个role拥有的权限请看前面《基础篇之MaxCompute和DataWorks权限关系》章节）：

   • 项目管理员：除拥有开发角色和运维角色所有权限外，还能够进行添加/移出项目成员并授予角色建立自定义资源组等项目级别的操做。同时拥有MaxCompute 开发project的role_project_admin这个role。
   • 开发：负责数据开发页面设计和维护工做流。同时拥有MaxCompute开发project的role_project_dev这个role。
   • 运维：负责在运维中心页面管理所有任务的运行状况并作相应处理。同时拥有MaxCompute开发project的role_project_pe这个role。
   • 部署：仅在多项目模式时审核任务代码并决定是否提交运维。同时拥有MaxCompute开发project的role_project_deploy这个role。
   • 访客：仅有只读权限，可查看数据开发页面的工做流设计和代码内容。同时拥有MaxCompute开发project的role_project_guest这个role。
   • 安全管理员：仅有数据保护伞模块的操做权限，无其余模块权限。同时拥有MaxCompute开发project的role_project_security这个role。
3. 任务开发调试。开发角色成员在DataWorks的“数据开发”模块（对应MaxCompute开发project）进行任务开发调试，，其间用到的生产project表，能够到DataWorks的“数据管理”模块进行申请。
4. 任务发布到生产环境。开发角色成员调试好任务后，进行打包。运维角色成员能够进行代码review（开发角色到运维角色这个流程须要线下通知）后执行发布包将任务发布到生产环境。 这个过程保障任务不能随意发布到生产环境执行。
5. 开发成员生产任务测试。任务发布到生产环境后，建议开发成员仍是须要到运维中心对生产环境任务测试执行一次，以确保生产任务的可正常执行。若任务执行返回成功状态，仍是须要先查看日志判断执行是否正常，进一步验证就须要查询结果表是否有正常的产出，此时通常是在开发界面进行表查询，而我的对生产环境产出的表默认无权限，能够到DataWorks的“数据管理”模块进行申请。

这一整套配置和操做流程走完后，须要注意几点：

• DataWorks-数据开发 模块是多人协同开发，全部本项目的成员均可以查看任务代码，且有编辑权限的成员均可以进行修改编辑，因此对于一些核心的敏感度高的代码将没法很好的进行保密，所以有相似高保密性的任务及数据，目前能够经过单独项目固定成员进行开发。
• 生产环境因为都是经过project的owner访问MaxCompute，所以建立的table、function、Resource的owner都是project owner的帐号，会出现“个人任务建立的表owner不是我”、“个人任务建立的表我本身没权限查看”这样的状况。
• 因为开发和生产项目owner都是同一个帐号，由于谨防经过发布任务到生产项目将生产项目表读写到开发项目，再经过开发项目获取生产数据。

单项目且每一个成员只能操做本身建立的表

场景描述：业务单一，成员角色基本一致，后续业务也不会扩展。如专供取数即不作数据开发，只须要查询下载业务数据（好比运营角色须要获取一些数据进行分析）。

分析：

• 本项目不作数据开发，那么须要分析的数据一定是在其余项目中，同时为了不不一样主帐号资源隔离，本项目的owner（主帐号）必须与数据开发生产项目的owner同一帐号。
• 本项目主要是作数据查询下载，因此须要每一个成员用本身的权限进行数据查询下载。所以这个项目的MaxCompute设置中“MaxCompute访问身份”属性为“我的帐号”。
• 当项目“MaxCompute访问身份”属性为“我的帐号”后，DataWorks中每一个项目成员将会被授予对应MaxCompute的role权限，可是需求是每一个成员只能操做本身建立的表，所以须要处理好这个默认的role权限。

实操：

1. 建立项目。注意主帐号必须是须要分析的数据所在的项目主帐号。项目配置以下：
   

2. 建立MaxCompute自定义role并受权。主帐号经过console进行操做：

   create role custom_dev;--建立自定义role
   grant List, CreateInstance,CreateTable,CreateFunction,CreateResource on project prj_name to role custom_dev;--给自定义role赋权

3. MaxCompute的project设置“容许对象建立者默认拥有访问权限”。主帐号经过console操做：

   set ObjectCreatorHasAccessPermission=true;    --实际上这个flag默认已经为true，能够经过以下命令查看
   show SecurityConfiguration;

   也能够在DataWorks的‘项目管理——MaxCompute设置’中进行配置。

4. 添加项目成员。DataWorks上添加子帐号为新成员，如添加成员时角色为“开发”，添加成功后，在对应MaxCompute的project里该成员对应的role是role_project_dev，主帐号经过consle命令行查看如：

   show grants for ram$主帐号:子帐号;

5. 修改新成员的MaxCompute权限。主帐号经过consle操做：

   revoke role_project_dev from ram$主帐号:子帐号;--将新成员从默认授予的role中移除。注意，若是后期又经过DataWorks成员管理页面在操做授予成员角色，那么也会从新授予该MaxCompute role。
   grant custom_dev to ram$主帐号:子帐号;--给新成员授予自定义角色。

至此，该特殊需求权限管理的项目已经配置好。还须要注意如下几点：

• 该项目的成员若从新操做添加如上描述中的“开发”角色，那么成员又会从新被授予role_project_dev 这个role。
• 该项目如此配置后只能作到每一个成员能够查看本身建立的表（对象），可是作不到每一个成员只能看到本身建立的任务。

• 该项目成员须要查询的表的权限须要本身走正常的权限申请流程（可在DataWorks的数据管理中申请），或者经过package受权方式，把其余生产项目的表加到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];

数据安全自查案例

场景：项目初期为了加快进度，一些用户和权限管理就相对宽松，当项目工做进入了一个相对稳定发展阶段后，数据安全将成为管理方面愈来愈重要的点。此时须要对数据安全进行自查分析，生成一个方案并落地。

本案例主要经过介绍某客户进行数据安全自查后重点调整的方向给出数据安全调整思路。

自查思路

• 帐号数量统计。统计DataWorks项目的成员和MaxCompute project user，确认每一个成员拥有且只拥有一个工做帐号，便于责任追责和管理。

• 存量帐号数量及权限统计。

  废弃帐号及权限统计：对于已在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落地为文件，就意味着数据不可控。因此，必需要尽量的减小数据落地带来的风险。经过用户角色的详细划分，限制只有一些业务组能够有数据导出的权限。且也不影响平常开发工做。