起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識后臺產品的基石：權限管理體系設計
文章作者主要講解了一些關于后臺產品權限設計體系，來文中看看~
什么是后臺產品？
簡而言之，我們日常使用的互聯網應用，有一些需要做數據/信息的呈現，管理維護這些數據/信息的產品，就是后臺產品。
舉個例子：在音樂app中有很多的歌曲、專輯、歌手等的內容，這些內容都需要在曲庫后臺中進行上傳、信息關聯等操作，這里的曲庫后臺就是一個后臺產品。
后臺產品為什么要做權限管理？
后臺產品中有大量的數據，需要較多的人員來對這些數據進行管理，不同人分別負責管理自己的數據。且不同的人，在整個數據管理流程中，需要進行的操作不同。那么此時，我們就需要對這些人員的權限進行不同的定義，具體人員可以看什么，不可以看什么，從而確保數據的穩定性，降低數據泄露的風險。
同樣用曲庫后臺舉例子，有的人負責維護華語音樂，有的人負責英語音樂，那么負責話語音樂的人，不可以操作英語音樂的數據。在負責華語音樂的人中，有的人負責上傳歌曲源，有的人負責整理音樂，打包成歌單呈現給用戶，那么負責上傳歌曲源的人，不可以去進行歌單的編輯。
權限管理的基礎：組織結構
人員層級的劃分是做權限管理的基礎，幾乎稍有規模的公司，都會有人員管理層級的劃分，我們稱之為組織結構，在組織結構中，明確指定人員的匯報關系、負責的業務模塊、人員的崗位等等。
組織結構的一個簡單示意圖如下，節點用于對業務模塊、工作范疇進行劃分。在一個業務模塊內，不同職能的人員，用崗位來進行區分，例如研發進行功能的開發，QA進行功能的驗證測試。
權限管理體系如何搭建
權限管理體系可以劃分為三個層級：功能權限、數據權限、按鈕/字段權限。
- 功能權限：定義人員是否可以訪問某個頁面。例如曲庫后臺，曲庫資源的管理人員，可以訪問曲庫資源的管理頁面，不可以訪問歌單資源的管理頁面。
- 數據權限：定義人員在頁面中，可查看的數據的范圍。例如曲庫后臺，曲庫資源的管理人員中，華語音樂管理員可查看華語音樂，不可查看英語音樂。
- 按鈕/字段權限：定義人員針對查看到的數據，可以進行的操作，或可查看的字段。例如曲庫后臺有歌曲的上傳和刪除的操作，曲庫資源的管理人員中，上傳資源的人員只能看到上傳按鈕，不可查看歌曲的刪除按鈕。只可查看歌曲的基礎信息，不可查看歌曲的定價信息。
從上圖和上面的描述舉例中，可以看出來，這三層權限控制是逐漸遞進的關系，從最基本頁面訪問，到具體數據信息操作，對于權限的粒度管理越來越細致。
那么基于這個理論基礎，在設計上如何實現呢？
- 功能權限：頁面是具體功能的一個實現，而功能的使用與人員的職能相關，結合我們前面講的組織結構可以得出，功能權限與崗位密切相關。因此我們做權限配置時，可以考慮將崗位與頁面權限綁定，這樣在崗位人員更替的過程中，只要崗位職能不變，那么我們對崗位和頁面權限的綁定就是無需變更的。例如編輯人員擁有曲庫編輯頁的權限，運營人員擁有歌單編輯頁的權限。
- 數據權限：同崗位的人員負責不同范圍的數據，那我們可以通過定義人員可查看自己負責標簽范疇內的數據來實現數據權限的管控。如果數據量特別大，同崗位的人員也需拆分給不同的管理人員來管理，甚至管理人員還是多層級的，那么此時就需要借助組織節點一起定義數據權限，最末級節點人員查看自己標簽范疇內的數據，上級節點的人員查看自己下級節點人員的數據匯總。
- 按鈕/字段權限：按鈕/字段權限本質上還是對一個功能的控制，只是這個功能內嵌于頁面內，比頁面的顆粒度更細，所以按鈕/字段權限可以和功能權限一樣，與崗位綁定。
權限管理體系的豐富拓展
上述的三層權限體系可以滿足我們基礎的權限控制的需求了，但是在一些特殊的情況下，有一些上述體系不能滿足需求的情況，該怎么去拓展這個權限控制體系呢？
以下列舉了一些：
場景一：同崗位的員工，進一步進行了工作模塊的劃分，希望他們可以擁有不同的功能權限
對于崗位通用的權限，我們可以用崗位與權限綁定來配置。若同崗位員工的工作模塊不同，有一些權限不可直接賦予崗位，而是與具體人員關聯時，可以抽象出一層虛擬角色，這些角色集成一個工作模塊的特殊權限，然后將角色直接賦予具體的人員。
這樣可以用虛擬角色來進行權限的規范管理，同時又能滿足同崗位人員需要配置特殊權限的情況。
場景二：某些員工臨時支援他人工作，需要臨時擁有一些功能和數據權限，但是組織結構不可調整
組織結構中的崗位和節點上下級關系，定義好了人員的全部權限。當對象的組織崗位關系不可調整，但是需要添加對象的各項權限時，我們可以通過加成權限來實現。加成權限就是指人員擁有自身所在組織崗位的權限，同時還可以擁有特殊配置的權限。
這個特殊配置的權限怎么配呢？
這個配置的基礎結構時，配置對象在某些系統中擁有某些節點崗位的全部權限。我們把配置對象、某些系統、某些節點崗位拆開描述如下。
- 配置對象：這個要臨時添加權限的對象，可能是員工，可能是某組織節點全部人員，甚至某崗位全部人員，因此這個配置對象可以根據需求去拓展，支持多選。
- 某些系統：一個大的后臺中可以進一步拆分系統，如果需要限制是這個加成權限只在部分系統生效，那我們可以增加生效系統的配置。
- 某些節點崗位：這個就是配置對象具體需要什么節點崗位的權限，在某些節點崗位這一環節中配置。
場景三：某些非頂級節點的員工，需要擁有全部數據的權限；某些有問題的員工，不可擁有任何數據的權限
這個是最簡單的，可以通過添加人員的白名單和黑名單來解決。白名單中的員工，默認賦予全部數據的權限。黑名單中的員工，默認不擁有任何數據的權限。
白名單和黑名單的賦予，支持給通過節點、崗位、人員來配置，操作更靈活方便。
以上是我對后臺產品權限設計體系的一些分享，希望對進行后臺產品設計的初級同學有一些幫助，歡迎留言一起交流。
作者：張三，5年互聯網產品經理經驗，同時主導過C端和后臺多項產品設計。
本文@張三 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
感覺換個說法「模塊權限-數據權限-功能權限」這樣子可能會比較清晰一點
剛了解這塊 學習一下
我想請教一下，數據權限有辦法可配置化嘛，還是寫死在崗位上面的？
數據權限里包含字段權限，所以正確的從下而上的順序：數據權限、功能權限，這兩個里頭再細分
話說這個功能、數據、按鈕/字段權限的劃分是否會有重復？我現在做的都是按菜單、頁面(包含字段、按鈕)、數據權限來，實際應用上感覺更清晰。
這個劃分本質上是對權限從粗到細的的一個劃分框架，每個權限都對應一個數據對象，所以沒有重復
“數據權限：同崗位的人員負責不同范圍的數據，那我們可以通過定義人員可查看自己負責標簽范疇內的數據來實現數據權限的管控。”
請問這個節點的標簽范圍以什么作為區分?
節點標簽范圍的區分要看具體的業務場景。例如在曲庫的后臺管理系統中，可以用音樂的語言來作為標簽，將標簽作為資源添加至組織節點崗位，甚至到人員，從而達成對人員細分數據權限的管控
節點標簽范圍的區分要看具體的業務場景。例如在曲庫的后臺管理系統中，可以用音樂的語言來作為標簽，將標簽作為資源添加至組織節點崗位，甚至到人員，從而達成對人員細分數據權限的管控
我的理解是這個就是字段
文中我所提的字段，一般是一條數據的字段信息，例如一首歌的作曲者、專輯、歌手等等
音樂的語言和歌的作者/專輯/歌手我看來是同一個維度的字段，如果是這個產品沒必要再分出一個數據權限，通過字段控制就可以了?？赡苁抢斫獾慕嵌炔煌惴值们寰蚾k
不對，數據權限還是要分出包含在字段下面，這樣層級會比較清晰
目前我也在做cms配置系統管理，組織機構存在多級，涉及賬號與權限管理，方便加個微信溝通下嗎？我的微信1152481807
因為有這樣的需求：經常會加入臨時的賬號，而且該賬號的權限也是待定的，就比較棘手。把權限掛載在每個角色下面，又會因為有上百個角色，操作太麻煩了。
這種情況下，建議先做需求的梳理。針對經常性的臨時賬號和臨時權限賦予，梳理一個清晰的業務流程，將臨時賬號統一在一起管理，同時對臨時賬號的權限做規范化的管理，而不是來一個賬號，加一次個性化權限。權限規范化管理可以考慮把系統角色再打包，建立申請、審批、自動配置流程
如果總是有臨時賬號權限待定的話，那建議先梳理需求，看看歷史臨時賬號的使用場景和需求情況，將臨時賬號和賬號的權限規范化管理
關于后臺復雜權限設計有一套RBAC的體系，可以參考。
對是的，RABC權限體系適用于功能權限和按鈕/字段權限的管理，這塊在場景一中略有提及，未展開??
如果用戶體系過于龐大而繁雜，那權限管理模塊應該單獨做出來？還是掛載在用戶管理模塊下，即給每個用戶分配權限？
你的用戶管理應該不是指OA里用戶信息的管理，如果是本文中所述的用戶管理，本身就是為了權限而設置，應該包含在【權限管理】里面，一般權限管理下有用戶和角色管理兩項就夠用了，而且用戶龐大的情況下就需要分開角色和用戶，單純的只設置用戶并賦權限只適合用戶少且人員穩定的系統
應該單獨做出來，因為給用戶單獨配權限需要耗費人力資源。單獨做出來，抽象崗位或虛擬角色可以把很多權限處理操作做成自動的
是的，我的做法是把權限與角色綁定，然后在角色下新建用戶的時候就不用配權限了，但是我的項目有上百個角色（政府項目，所以有上百個部門），而且不同角色的權限要求也不同，請問怎么做優化呢？（有人建議我在角色的基礎上再抽象一層，叫“角色類”，形成角色類——角色——用戶的體系，然后依據每個層級的共性賦予默認權限，有點像電商類目的屬性繼承。這樣可以嗎？）
角色的設定也是一次性工作，政府的角色非常的固定，如果后續不會大幅度變動的話，將所有角色統一初始化會是一個比較簡單的方法，后續也只需增加用戶并將用戶和角色掛鉤就可以了。
即使再增加一層，角色類，也只是用于在初始化角色的時候比較方便而已
雖然知道場景二是針對某個人員賬號增加功能，但是沒有想到好的體現形式。不知道能否具像一下？
舉個例子：歌單編輯人員人手不夠，需要抽調幾位歌曲資源編輯人員，協助進行歌單編輯。那么我們需要一個場景二中描述的系統，這個系統給歌曲資源編輯人員（配置對象）配置，在曲庫后臺的歌單管理模塊（系統），擁有某歌單編輯崗位的權限（某節點崗位）。從而達到使歌曲資源編輯人員在指定系統擁有歌單編輯的權限。
權限模塊化，然后人工增加臨時權限？