起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識一個實例：基于RBAC理論的訪問控制實踐
基于角色的訪問控制（RBAC）是目前公認的解決大型企業的統一資源訪問控制的有效方法。訪問控制實際是復雜的，解決方式也是多樣的。不用一味追求完善，在有限的資源內選擇最合適自己的更重要。
基于角色的訪問控制（RBAC）是目前公認的解決大型企業的統一資源訪問控制的有效方法，傳統的訪問控制中我們直接將權限賦予用戶，而在基于角色訪問控制中先將權限賦予角色，再通過角色與用戶連接。
一個實例
這里跳過對理論模型的解釋，以最近的一個項目為例，談下實際項目中的應用。首先交代背景：
（1）簡易電商后臺版本，意思就是很小不需要什么復雜權限，開始也沒考慮權限。
（2）有一個管理員賬號運營和開發都在用，一個財務賬號給財務導數據，新建供應商同時生成商家賬號，給商家上架商品發貨這些。
（3）需要增加權限的契機就是隨著業務擴大，功能變得復雜了些，再不做就要亂了。
功能模塊
權限的功能模塊分為三個部分：
用戶管理就是給用戶添加登錄賬號，讓用戶能夠登錄系統；
角色是告訴你我在這個身份下能在系統干什么；
權限配置是對權限功能的管理，讓系統管理員或開發人員更清楚靈活管理配置系統頁面權限、功能權限，反正就是普通用戶用不著那種。
角色管理
首先是添加角色。
字段非常簡單，只要寫好角色名稱和描述角色是做什么的就可以。
其次是分配權限。
很多系統做法是直接在編輯或者添加頁面一起把權限分配做了。我更偏好是一個動作下只做一件事，會比較清晰些。所以這里做了兩個步驟，就是角色信息和權限分配獨立開。
在頁面交互上，這里并沒有使用純樹形，而是結合菜單+頁面形式：左邊展示導航菜單，右邊展示對應頁面功能。
這種對于頁面層級不深的其實是非常直觀的，但是如果在該頁面下某些二級入口甚至三級入口權限控制就會略顯混亂，會比較建議使用樹形結構處理。
順便提一句，后臺設計盡量不要讓頁面層次太深了，這對用戶使用并不友好。如果這么做，那么使用多級菜單導航或者關閉式標簽導航可能是一種解決方式。
有一些需要注意的點：
1. 超級管理員
為了便于管理，在當前系統中配置了一個超級管理員角色，就是這個角色系統里面什么都能干；這個角色下通常只有一個超管，只有這個超管才能做權限管理，其他角色是不可的。
這一點在不復雜的系統中，是一種便捷管理方式。更復雜系統需要考慮不同層級管理員、考慮角色互斥、角色繼承這些問題。
2. 角色禁用啟用以及刪除
禁用啟用都會影響到這個角色下所有用戶的使用，這點需要注意。在處理這些敏感的操作時候，一定要做二次確認。
在刪除時，還需要判斷下當前角色有用戶時是否能夠刪除。能刪除則用戶怎么處理，不能刪除怎么提示。
一種做法是，可以刪除但刪除后如果用戶賦予的角色會為空，再登錄時候會對應提示；另外一種做法是要先清空用戶才能刪除角色。
3. 單角色
RBAC告訴我們一個用戶可以有多個角色，但是我這里處理為一個用戶只有一個角色。實際上可以做多個角色，但是沒有必要，因為我們的業務是單線的，每個角色各司其職。
如果是多角色，從我做過系統看，一個是做好角色的互斥，比如說某項業務的申請和審批不要分配到同一個人上；一個是一次只能獲取一個角色，登錄進入系統，第一個就是要選擇角色。
如果處理更好那就首次登錄選擇，再次登錄記住上次即可，并且支持在個人設置中自由切換。
4. 默認角色
這里商家其實是默認角色，它不可刪除。這么做是因為商家某些頁面字段顯示與其他角色是不一樣的，屬于數據權限范疇。但是如果單獨細化數據權限到字段，投入產出比那真的是劃不著，所以直接在角色中寫死了。在實際場景中，角色和身份是可以是對等的，比如做校園自然就有教師、學生、家長角色，這一類角色實際是是可以作為默認固定角色而不需要再創建。
用戶管理
添加角色以后，我們就可以去用戶管理中管理用戶，頁面如下：
在添加或編輯用戶時候我們就會給用戶設置角色。這里可能需要注意點有：
（1）用戶名
根據實際需求去規定用戶名，可以是郵箱可以是手機號，也可以是正常的字母+數字的組合。
當前系統使用是數字+字母的賬號，那么在你忘記密碼時候，如果不綁定手機號或郵箱還是無法自己找回的。在當前業務條件下，登錄頁直接給了個聯系管理員的提示，由管理員重置密碼。
（2）密碼
通常會有個初始密碼，為了保證系統安全性，最好首次進入強制修改。如果忘記密碼需要管理員重置，那需要一個重置的功能，點擊二次確認后重置為初始密碼。也可以是帶輸入框彈窗，輸入為任意符合規則的密碼。
（3）關聯商家
可以理解為這是對數據權限的控制手段。在實際的后臺權限管理中，有些數據權限是根據組織架構做了限制，有些角色去配置，有些根據用戶組，而有些則是根據賬號單獨去配置。所以在做數據權限時候，要具體問題具體分析，而不是別人的一定合適。
在當前系統中，實際默認有兩類用戶，一個是平臺的，如平臺運營、財務；一個是供應商（商家），那么平臺對應的數據范圍是全部數據，而商家對應的數據范圍是自己的。
在做權限之前，在商戶管理中，添加商戶時候默認會添加一個商戶賬號，實際已經做了數據隔離，但是統一權限管理后，添加用戶并且配了商家角色，實際上并不知道這個用戶管理的是哪個商家，那就需要用戶和商家中做個鏈接。
（4）投放限制
是某種特殊的數據限制，進一步說明對單個賬號配置必要性。
比如如果做廣告，只允許某用戶投放某些區域；再比如做校園管理系統中，指派班級學生助理對特定班級成員的管理（也可以通過組織架構做數據權限控制，如果有下篇可以討論下）。
我做的是社區電商后臺，是自帶社區限制屬性的，有些商家只能投放一個社區，有些商家則能投放多個社區。
權限配置
更準確的說，是菜單和規則的配置。不是必須的，但是建議能夠在前端頁面中配置。
我負責的系統是php寫的，權限是后面增加，所以開發在修改時候，每個功能按鈕都做了個if判斷，還好頁面和功能不多，不然開發估計要哭。
所以這個并不是合理方式。
在其他系統中，則采用的是通過url結合api做的頁面和功能控制，有優點也有缺點，本文不進行深入討論。
當然我也無力探究不同的語言如何實現權限管理，因為我聽不懂。不過理解下正在做的系統如何實現的對于非技術出身產品經理而言，則是一種有益學習過程。
通過權限配置，我們能夠比較靈活的調整菜單或者功能，比如調整個菜單位置配置個菜單icon，不需要讓開發的伙伴去動下代碼，能讓他們少掉幾根頭發。
此外，操作日志是一個必不可少的模塊，它是對訪問控制一個補充，記錄了整體系統中所有的行為。特別是在角色中沒有控制“只能操作自己內容”時，就會變得尤為重要。
我現在處理這個系統權限問題時候，并沒有在角色的維度上去控制數據權限，而是根據實際業務在用戶的維度去控制了數據權限。舉一個例子，比如說，AB都是商家角色，都能對某個商家進行管理。如果二者數據權限做了控制，那么A只能編輯自己錄入商品，B只能編輯自己錄入商品。如果沒有控制，那么AB都可以編輯彼此錄入商品，要是誤操作這就不知道是誰干的了。在這種情況下，有日志就能知道誰進行了對應的操作，避免無法追溯問題源頭。
理論溯源
理論是實踐的基礎。雖然枯燥，還是有必要提一下整個RBAC模型的發展脈絡。
產品經理社區乃至各大技術社區對于RBAC的介紹和說明已經有很多，挑了以下兩篇我覺得說的很清楚文章，看完就基本知道RBAC是整個模型是什么了，感謝二位分享。
RBAC權限管理模型：基本模型及角色模型解析及舉例??http://www.aharts.cn/pd/440765.html
總結：SAAS后臺權限設計案例分析??http://www.aharts.cn/pd/2310691.html
同時我也結合了自己了解和理解資料，做了一個理論梳理。特別是最上面訪問控制技術發展有興趣的可以進一步探索下，就不貼什么枯燥的概念解釋了。實在能力有限，有些是真的看不太懂。
值得一提的是，人們習慣用百度谷歌等搜索引擎去獲取專業信息，而很多學術論文中的一些整體解決方案往往被忽視。
學術上這種理論與實踐結合研究可能滯后于現實發展的（因為新的實踐提升到理論的視角是需要時間積累），但是對于從未接觸過人群，這類論文卻提供了一種方法論的思路。
是的，你們找不到答案的時候不妨查一下CNKI?！獑T外
結束語
1. 權限管理是系統的基礎功能，在最初規劃時候就要考慮到每個行為都能找到是誰干的。
2. 訪問控制實際是復雜的，解決方式也是多樣的。不用一味追求完善，在有限的資源內選擇最合適自己的更重要。
最后，如有不足或者錯誤地方歡迎指正。計劃是能由簡單到復雜復盤下自己做訪問控制踩過的坑，希望有下一篇，立個flag
本文由 @員外丁 原創發布于人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基于CC0協議
是的，你們找不到答案的時候不妨查一下CNKI。——員外，這句話真妙哈哈哈