通過《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方式配置了一個查詢軟體，並提供多人進行查詢，這種多人共用一個賬號需要整改。
  複製程式碼

• 資料下載統計（可以工單申請推送元倉資料進行分析統計）。統計各個專案的資料下載請求任務，分析規劃可下載專案。

調整要點

• 賬號以及全新合理分配。調整原則：每個工作成員都使用自己的個人賬戶。

  針對不同人員所在的的不同業務開發小組和角色給出不同的資料訪問許可權，禁止相互借用他人的賬戶使用。避免因為使用者許可權過大導致的資料安全風險。
  如，按資料開發過程的業務分組進行賬號分配。分組如管理組、資料整合組、資料模型組、演算法組、分析組、運維組、安全組等。
  複製程式碼

• 資料流動控制。
  限制部分專案的資料匯出，控制部分人員的許可權。資料隨意在各個專案之間流動，不但會導致雲平臺資料架構混亂，同樣也會導致資料洩露的風險。所以，針對大部分專案做出了資料流動的限制。

如通過MaxCompute層面限制資料只能流動到指定的專案或者指定的位置，從而規避未知資料流動帶來的風險。
複製程式碼

• 資料匯出限制。

  資料一旦從MaxCompute落地為檔案，就意味著資料不可控。所以，必須要儘可能的減少資料落地帶來的風險。通過使用者角色的詳細劃分，限制只有一些業務組可以有資料匯出的許可權。且也不影響日常開發工作。
  複製程式碼

更