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落地爲文件，就意味着數據不可控。因此，必需要儘量的減小數據落地帶來的風險。經過用戶角色的詳細劃分，限制只有一些業務組能夠有數據導出的權限。且也不影響平常開發工做。