權限管理是數據產品必備的要素，也是數據安全的一道重要屏障。尤其是對于數據可視化決策分析等基于數據要素加工形成的數據產品，沒有權限控制，就無法讓業務使用。

在數據產品權限的設計邏輯中，RBAC的原則是一個典型的權限管理的方法論，來源于B端后臺工具產品，即：Role-Based Access Control)，基于角色的訪問控制。

一、數據產品權限管控的需求

數據產品除了頁面、功能權限外，還要多一層數據的權限，權限粒度經常會到指標和維度，比如針對銷售人員設計的銷售業績統計報表，系統層面會把不同銷售的數據在一個頁面內展示，通過權限管理來控制能看到負責區域或者商家的數據，這個時候，對于同一個交易額的指標，就要控制到省份/城市，或者銷售人員維度。同樣，不同用戶群體能夠看到的指標可能也是不一樣的，比如管理層要看到能夠衡量業務整體表現情況的流量、訂單、成本、服務等各個視角的指標，而某一具體的業務人員，如客服，原則上只應看到服務相關的指標。

權限設計要求

足夠精細化，可以滿足不同崗位、不同人員查看自己責任范圍內數據

權限調整方便，組織架構調整是非常頻繁的事情，架構調整權限如何快速隨之變動（自動或者手動批量）

二、權限設計原則

1.傳統權限管理方法

傳統權限管理的做法是給用戶賦權，即每個用戶綁定對應的頁面、功能按鈕和數據的權限，這種方法的主要的問題是維護繁瑣，人員組織變動，需要重新綁定資源，如果幾百個人，光加權限就要搞個一天。

2.RBAC原則

權限設計最常用的是RBAC原則，即：Role-Based Access Control)，基于角色的訪問控制。基本思想是通過角色來管控權限，角色綁定資源，用戶授權角色，用戶不可以直接和資源綁定，沒有角色的用戶無法訪問平臺的資源。RBAC對訪問權限的授權由管理員統一管理，管理員根據用戶在組織內所處的角色作出訪問授權與控制，授權規定是強加給用戶的，用戶不能自主地將訪問權限傳給他人，這是一種非自主型集中式訪問控制方式。

在RBAC模型中，Who對What(Which)進行How的操作，

Who：權限擁有的主體，如User、Group、Role、Actor

What：權限針對的對象或資源（Resource、Class）。

How：具體的權限，頁面查看、編輯、刪除等操作

Role：角色，用戶權限的載體，目的建立User與Resource的映射關系，減少千人千面的人與資源的強耦合關系

Group：用戶組，權限分配的單位與載體。權限不考慮分配給特定的用戶而給組。組可以包括組(以實現權限的繼承)，也可以包含用戶，組內用戶繼承組的權限。User與Group是多對多的關系。Group可以層次化，以滿足不同層級權限控制的要求

3.RBAC原則優缺點

RBAC的優點：

權限調整只需對角色調整，可以快速進行批量的權限操作

支持部門與角色綁定，新人入職、離職轉崗，權限動態更新，無需手動操作

資源、平臺管理，實現資源的配置化管理，新上線平臺或新增資源時，只需平臺內綁定注冊，無需單獨開發權限模塊，節省開發人力

RBAC的缺點：

資源綁定需要管理員介入，業務權限劃分要求粒度更細時，角色數量暴增，管理和維護成本高

單個用戶的權限靈活度低，只能針對一個角色下的一類用戶操作，想單獨操作時，需要專門創建一個角色

對于UGC內容多的場景，適用度低，因為資源由用戶生產，權限管控在平臺側就非常不便

三、數據產品權限設計思路

基于RBAC原則設計的權限管理，主要會包括用戶管理、角色管理、資源管理、平臺管理等主要功能模塊：

用戶管理：包括用戶列表和部門列表，提供用戶查詢和權限操作功能，一般是從企業內部OA拉取人員信息，同時支持部門調整、角色綁定、權限禁用(黑名單)等操作

角色管理：角色增刪改查列表，可以對角色進行資源綁定、用戶管理

資源管理：分為頁面資源、按鈕資源、數據資源、指標維度資源等

平臺管理：數據中臺部門有多個平臺，平臺權限統一管理，減少各個系統獨立開發權限管理模塊，提高復用性。同時，也可以針對新入職或離職人員進行多個平臺權限的批量開通和移交。

如何自動化處理數據權限，減少手動維護成本？

對于負責部門、負責商品等數據維度權限管理，如果每次都需要手動建立部門角色，用戶綁定部門，管理員工作量還是很大的，所以怎樣既實現系統自動化處理的便捷性，同時支持管理員手動配置的靈活性呢？

常用的做法是基于維度表維護人和部門、區域或商品等常見維度的關系，用戶訪問時，判斷是否符合對應的關系。以部門權限為例，可以先由系統自動基于部門信息創建部門角色，并賦予對應部門的數據權限。用戶基于SSO登錄后，獲取到部門信息與角色進行匹配，能匹配上則可以直接查看相應功能，無需聯系管理員或者提工單申請權限，就可以做到不需要管理員手動綁定用戶／部門與角色關系了。