朱學(xué)敏222019.07.22 00:07:29字數 2,250閱讀 3,258
對于業(yè)務(wù)復雜或數據龐大的系統，為了方便管理，一定要做權限設計。
權限設計是后臺系統要考慮的一個(gè)授權策略問(wèn)題。直白的說(shuō)，權限設計就是根據公司的業(yè)務(wù)規則，對權限管理系統設置的安全策略。
權限一般分為功能權限，數據權限與菜單權限。
功能權限控制當前賬號可以操作的功能按妞，比如風(fēng)控只能審核標的登記，但不能發(fā)起進(jìn)件申請。
數據權限控制當前賬號可以看到的數據范圍，比如客服A只能看到分配到她名下的出借人的投資數據。
菜單權限控制當前賬號可以看到的頁(yè)面內容，比如催收人員只能看到案件逾期后流轉到催收頁(yè)面的內容。
對于權限設計，關(guān)鍵是理清用戶(hù)、權限、角色三者的關(guān)系。即給誰(shuí)創(chuàng )建賬戶(hù)，分配什么角色，賦予何種權限。
需求背景
權限設計的首要問(wèn)題是明確需求。權限設計牽涉到后臺系統底層架構的業(yè)務(wù)邏輯，在做后臺系統之前，一定要對現有的權限控制和業(yè)務(wù)情況了解清楚，才能避免在權限設計的問(wèn)題上踩坑。
以某車(chē)貸風(fēng)控系統為例，我們通過(guò)相關(guān)業(yè)務(wù)部門(mén)的反饋和當前權限系統的調研，發(fā)現它存在的問(wèn)題有以下幾點(diǎn)：
用戶(hù)的權限歸屬不明確，導致進(jìn)件的申請和審核操作為同一個(gè)人；
敏感數據沒(méi)有做權限控制和脫敏處理，導致用戶(hù)隱私數據被泄露；
角色的分類(lèi)不合理，每個(gè)用戶(hù)只能配置一個(gè)角色，導致工作組和流程節點(diǎn)比較復雜；
對所屬團隊的客戶(hù)經(jīng)理、團隊經(jīng)理和城市經(jīng)理做了三級維護關(guān)系，但人員調動(dòng)和離職率較大，導致管理成本高。
了解完現有需求背景后，我們借鑒釘釘的那套權限維護方式，改進(jìn)了管理系統的權限設計。
一方面收集權限需求，根據部門(mén)需求列一份權限清單，并做好CheckList。在模塊的功能頁(yè)面要放置哪些權限，完全可以根據《操作權限申請表》的業(yè)務(wù)需求，進(jìn)行靈活的權限配置。
另一方面借助UML建模的用例圖，將角色按功能Uc級細分到增刪改查導，方便確認相關(guān)人員的操作權限。
設計過(guò)程
明確需求后，就要選擇合適的權限設計模型。做后臺系統權限設計，我們可以借鑒一些控制模型。
常見(jiàn)的權限設計控制模型有：自主訪(fǎng)問(wèn)控制（DAC）、強制訪(fǎng)問(wèn)控制（MAC）、訪(fǎng)問(wèn)控制列表(ACL)、基于角色的訪(fǎng)問(wèn)控制(RBAC) 、基于任務(wù)和工作流的訪(fǎng)問(wèn)控制(TBAC) 、基于任務(wù)和角色的訪(fǎng)問(wèn)控制(T-RBAC)、基于對象的訪(fǎng)問(wèn)控制（OBAC）、使用控制模型( UCON)、基于屬性的訪(fǎng)問(wèn)控制（ABAC）等。
最常見(jiàn)的權限設計控制模型是RBAC模型。像業(yè)務(wù)復雜且功能龐大的某車(chē)貸風(fēng)控系統，權限設計選擇的就是RBAC模型，主要是方便后續的擴展。
RBAC即基于角色的權限訪(fǎng)問(wèn)控制（Role-Based Access Control），在RBAC模型中，權限與角色相關(guān)聯(lián)，用戶(hù)通過(guò)成為對應角色的成員，從而得到這些角色的權限。即用戶(hù)關(guān)聯(lián)角色，角色關(guān)聯(lián)權限，可實(shí)現系統權限的靈活配置。
訪(fǎng)問(wèn)控制的核心是授權策略。在RBAC模型中，Who、What、How構成了權限控制三要素，也就是Who對What(Which)進(jìn)行How的操作。
RBAC的權限授權其實(shí)就是Who、What、How的問(wèn)題。Who：權限的擁用者，What：權限針對的資源，How：具體的權限。在RBAC中，根據權限設計的復雜程度，可分為RBAC0、RBAC1、RBAC2、RBAC3。
RBAC模型包含用戶(hù)(User)、資源(Resource)、操作(Operation)三個(gè)關(guān)鍵要素。通過(guò)將資源以及資源操作授權給用戶(hù)，而使用戶(hù)獲得對資源進(jìn)行操作的權限，保證了權限分配的實(shí)施。
此外，RBAC模型遵循三條安全原則：最小權限原則，責任分離原則和數據抽象原則，從而簡(jiǎn)化了權限管理。
實(shí)施過(guò)程
選擇RBAC模型后，就要從賬戶(hù)、角色、權限三方面考慮實(shí)施過(guò)程，并滿(mǎn)足不同的用戶(hù)在使用過(guò)程中的不同權限需求。
其中賬戶(hù)和角色關(guān)聯(lián)、角色和權限關(guān)聯(lián)，且都是多對多的關(guān)系。我們可以借助UML建模的類(lèi)圖了解三者之間的關(guān)系。
以某車(chē)貸風(fēng)控系統為案例，我們要為某風(fēng)控A創(chuàng )建一個(gè)管理賬戶(hù)，并分配對應的風(fēng)控人員角色，且在系統擁有訪(fǎng)問(wèn)標的詳情權限和操作標的登記權限。
賬戶(hù)管理
賬戶(hù)管理的入口在系統管理模塊，包括基本的新增賬戶(hù)，編輯賬戶(hù)，刪除賬戶(hù)、查看賬戶(hù)、查詢(xún)賬戶(hù)，以及給賬戶(hù)分配角色。
賬號管理是管理員最常用到的功能，相應字段一般是常用字段和特定字段。常用字段比如用戶(hù)ID，手機號，姓名，角色，狀態(tài)和注冊時(shí)間等，特定字段是公司業(yè)務(wù)需求，比如分配角色，登錄時(shí)間，登錄次數，訪(fǎng)問(wèn)IP，訪(fǎng)問(wèn)設備等。
管理員在新增賬戶(hù)時(shí)，通過(guò)給該賬戶(hù)分配風(fēng)控人員的角色，從而擁有該角色的相關(guān)權限。RBAC模型就是通過(guò)給用戶(hù)分配角色，而取得角色的權限，這樣就簡(jiǎn)化了用戶(hù)權限分配流程。
角色管理
角色管理的入口在系統管理模塊，包括基本的新增角色，編輯角色，刪除角色、查看角色、查詢(xún)角色，以及給角色分配權限。
角色管理是用來(lái)管理公司內部用戶(hù)的角色信息。一個(gè)復雜的后臺會(huì )被分割成很多角色，比如管理員、運營(yíng)人員、客服人員、財務(wù)人員、催收人員等。我們可把具有共同特征的某一類(lèi)人群的身份進(jìn)行歸納，從而為不同的用戶(hù)賦予對應的角色權限。
管理員會(huì )根據公司業(yè)務(wù)需要，新增對應的角色，并給該角色賦予對應的頁(yè)面權限和操作權限。角色是關(guān)聯(lián)用戶(hù)和權限的紐帶，可以為用戶(hù)賦予該角色所集成的相關(guān)權限。我們在權限攔截流程設計時(shí)，就會(huì )限制菜單要根據給用戶(hù)分配的角色填充，只顯示該角色可展示的菜單。
權限管理
權限管理的入口在系統管理模塊，包括基本的新增權限，編輯權限，刪除權限、查看權限，以及給權限狀態(tài)進(jìn)行開(kāi)關(guān)。
任何一個(gè)B/S系統或C/S系統都會(huì )做權限管理。權限管理限制用戶(hù)可以訪(fǎng)問(wèn)而且只能訪(fǎng)問(wèn)自己被授權的內容或數據。
管理員在新增權限時(shí)，會(huì )限定權限性質(zhì)為基本權限或操作權限。比如用戶(hù)沒(méi)有操作權限時(shí)，點(diǎn)擊按鈕會(huì )提示無(wú)權限，或者按鈕置灰不可點(diǎn)擊，或者隱藏該操作按鈕。
權限設計是后臺系統必不可少的一個(gè)環(huán)節?；赗BAC模型的權限設計，能支持業(yè)務(wù)復雜的權限控制，也能滿(mǎn)足平臺運營(yíng)的安全策略，增加了權限管理的靈活性與簡(jiǎn)便化。
本文首發(fā)于微信公眾號 產(chǎn)品經(jīng)理朱學(xué)敏（ID:pm_zhuxuemin），如需轉載，請聯(lián)系原作者。
