關於產品賬號&許可權設計的一些事

應該說幾乎所有的B端產品，在根據業務模型設計完主幹功能架構之後，產品經理都會考慮同一個問題，那就是賬號和許可權角色應該怎樣設計，在保證滿足既有需求的基礎上，又能有更好的拓展性。

筆者也設計過或者看到過很多的賬號&許可權結構，這裡也做一下總結，同時把每種結構使用的場景也做簡單描述。

1、關於許可權、角色、賬號之間的關係

三者直接的關係，我做了一個簡單的示意圖，如下：

許可權：是指產品中的操作許可權，比如對數據的增刪改查看許可權、某個頁面的入口許可權等等。許可權並非是越細越好，如果產品的操作邏輯或者業務對許可權控制要求沒有那麼細的話，許可權相應的可以粗粒度一些，比如某些頁面只設置入口許可權，頁面中的操作按鈕不再單獨進行控制，這樣可以減少前期的開發成本和後續的角色設置繁瑣度。

角色：一個或者多個許可權項可以組成一個角色，比如將產品的數據報告查看許可權組合起來，命名為「數據分析員」，這樣後期在賦予賬號許可權時會更加方便直觀，不同角色之間的許可權是可以交叉的。

賬號：對應自然人，不同產品在處理賬號結構時有不同的做法，後面會詳細來講。

2、關於許可權、角色的靈活性

前文講到了，許可權設置並不是越細越好，同樣的，角色設置管理的部分也並不是越靈活越好，因為設置越靈活，對於用戶的學習成本也就越高。

很多產品在提供給用戶的時候，直接固化了幾種角色，比如管理員角色、經理角色、專員角色，每種角色對應固定的許可權，不允許用戶再去修改，這樣的好處是用戶不需要了解許可權與角色的關係是怎樣的，直接按已劃分好的角色去使用即可，但是靈活性就相對較差，這種結構適用於不會經常發生變動的操作場景，比如財務系統，財務主管該幹什麼、出納該幹什麼，都是固定的。

相對的，比較靈活的做法是允許用戶根據實際情況自定義角色，自主設置每個角色對應哪些許可權，角色管理的許可權，一般僅限於管理員或者高級別賬號。這種方式因為開發了角色管理，相應的學習成本、開發成本會隨之增加，適用於業務場景變化較多的情況。

3、關於賬號設置

對安全性要求不高的產品，在產品賬號管理模塊，由管理員直接創建賬號（用戶名、密碼），然後交付給實際使用人，賬號和自然人之間沒有固定的關係，員工離職了還是可以由接任者繼續使用，這種方式的最大問題是一旦發生數據泄露，因為用戶名和密碼和自然人沒有對應關係，給問題定位帶來困難；

更為常用的方式是，賬號直接使用員工的企業郵箱，和公司的郵箱系統打通，員工使用郵箱和郵箱密碼登錄系統，因為企業郵箱的安全係數較高，對比上一種方式，在安全性上能夠有較好的保障。

4、賬號和角色直接的關係

從上文可以看出來，一個產品使用的開始是角色的設置（固定角色或者自定義設置角色），然後將角色賦予給賬號，實際使用人使用賬號登錄系統，從而完成整改過程。賬號和角色之間必須建立關聯關係，在實際的使用場景中，賬號和角色的關聯關係也有兩種做法，如下：

a、一個賬號關聯多個角色

一個人在系統中僅允許有一個賬號，但是賬號可以對應多個角色，這時賬號擁有的許可權，是所關聯角色許可權的並集，比如張三這個賬號既關聯了數據查看的角色，又關聯了數據修改的角色，那麼登錄後張三既能查看數據又能修改數據，是兩個角色許可權的並集。

b、一個賬號僅允許關聯一個角色，但允許一個人有多個賬號

這種情況適用於賬號上下級彙報關係比較明確的產品系統，比如賬號層級分為經理、主管、專員三層，不同的專員要彙報給不同的主管，這種情況下就不能允許主管A看到主管B及其下屬專員的數據了。對應到賬號和角色的關係，如果採用上一種方式，同時賦予一個人經理和主管的角色（比如某些部分經理兼容主管），那麼在賬號層級上就會出現混亂，作為經理他可以看到下屬數據，但是作為主管又不能看到某些數據，更為重要的是賬號嚴格的層級關係也會被打破。為了適應這種情況，允許一個人有多個賬號，分別賦予經理、主管角色，通過賬號切換的方式來進行管理，整個賬號邏輯就會清晰明了很多，賬號仍然與郵箱對應，不同賬號使用不同的ID區分。

總之，產品的賬號&許可權設計，一定是和具體的使用場景來契合的，沒有一定之規，只要能符合實際需要同時有滿足一定的拓展性要求，就是合理的。