通过《MaxCompute安全管理-基础篇》了解到MaxCompute和DataWorks的相关安全模型、两个产品安全方面的关联，以及各种安全操作后，本篇主要给出一些安全管理案例，给安全管理的成员作为参考。
项目创建案例
前面了解了MaxCompute和DataWorks的安全模型以及两个产品之间的权限联系，本章节我们以常见2个基础业务需求来介绍项目创建和管理。
基本ETL开发业务项目
场景描述：多人协同开发，成员责任划分明确，需走正常的开发、调试、发布流程，生产数据查看须严格控制。
分析：
- 多人协同开发，DataWorks项目本身就满足这一点。
- 成员责任划分明确，DataWorks的基础成员角色（项目管理、开发、运维、部署、访客）基本可以满足需求。
- 走正常开发、调试、发布流程，生成数据需严格控制，这些通过DataWorks创建的“开发”“生成”项目可以进行控制。
实操：
-
创建项目。主要配置如图：
- 项目模式选“择标准模式（开发跟生产隔离）”。这个模式创建的结果是一个DataWorks项目空间绑定关联两个MaxCompute project（分开发和生产project）。开发环境上进行开发调试，生产环境任务由开发环境走发布流程发布过来进行稳定运行。
- 开发环境“MaxCompute访问身份”为个人账号。项目成员在开发环境做任务开发调试时用个人账号进行操作，这样做的目的在于，每个成员根据业务需求在开发调试过程中需要用到的MaxCompute各种生产资源（table、Resource、function）不同，为了防止权限过大，每个成员自己申请自己所需的权限（主要是生产表权限），同时还可以更好的做后续的安全审计。
- 生产环境“MaxCompute访问身份”为项目负责人账号即project的owner。生产环境要保障稳定和安全生产，正常情况下：不允许成员可以随意提交job，不允许个人账号拥有生产表的删除、修改权限以免通过命令行工具进行操作无法受到更好的控制，个人账号需要读生产表权限必须走申请以便更好的管理数据安全。
-
添加项目成员。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。
- 任务开发调试。开发角色成员在DataWorks的“数据开发”模块（对应MaxCompute开发project）进行任务开发调试，，其间用到的生产project表，可以到DataWorks的“数据管理”模块进行申请。
- 任务发布到生产环境。开发角色成员调试好任务后，进行打包。运维角色成员可以进行代码review（开发角色到运维角色这个流程需要线下通知）后执行发布包将任务发布到生产环境。 这个过程保障任务不能随意发布到生产环境执行。
- 开发成员生产任务测试。任务发布到生产环境后，建议开发成员还是需要到运维中心对生产环境任务测试执行一次，以确保生产任务的可正常执行。若任务执行返回成功状态，还是需要先查看日志判断执行是否正常，进一步验证就需要查询结果表是否有正常的产出，此时一般是在开发界面进行表查询，而个人对生产环境产出的表默认无权限，可以到DataWorks的“数据管理”模块进行申请。
这一整套配置和操作流程走完后，需要注意几点：
- DataWorks-数据开发 模块是多人协同开发，所有本项目的成员都可以查看任务代码，且有编辑权限的成员都可以进行修改编辑，所以对于一些核心的敏感度高的代码将无法很好的进行保密，因此有类似高保密性的任务及数据，目前可以通过单独项目固定成员进行开发。
- 生产环境由于都是通过project的owner访问MaxCompute，因此创建的table、function、Resource的owner都是project owner的账号，会出现“我的任务创建的表owner不是我”、“我的任务创建的表我自己没权限查看”这样的情况。
- 由于开发和生产项目owner都是同一个账号，因为谨防通过发布任务到生产项目将生产项目表读写到开发项目，再通过开发项目获取生产数据。
单项目且每个成员只能操作自己创建的表
场景描述：业务单一，成员角色基本一致，后续业务也不会扩展。如专供取数即不做数据开发，只需要查询下载业务数据（比如运营角色需要获取一些数据进行分析）。
分析：
- 本项目不做数据开发，那么需要分析的数据必定是在其他项目中，同时为了避免不同主账号资源隔离，本项目的owner（主账号）必须与数据开发生产项目的owner同一账号。
- 本项目主要是做数据查询下载，所以需要每个成员用自己的权限进行数据查询下载。因此这个项目的MaxCompute设置中“MaxCompute访问身份”属性为“个人账号”。
- 当项目“MaxCompute访问身份”属性为“个人账号”后，DataWorks中每个项目成员将会被授予对应MaxCompute的role权限，但是需求是每个成员只能操作自己创建的表，因此需要处理好这个默认的role权限。
实操：
- 创建项目。注意主账号必须是需要分析的数据所在的项目主账号。项目配置如下：
-
创建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$主账号:子账号;--给新成员授予自定义角色。
至此，该特殊需求权限管理的项目已经配置好。还需要注意以下几点：
- 该项目的成员若重新操作添加如上描述中的“开发”角色，那么成员又会重新被授予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落地为文件，就意味着数据不可控。所以，必须要尽可能的减少数据落地带来的风险。通过用户角色的详细划分，限制只有一些业务组可以有数据导出的权限。且也不影响日常开发工作。