中通快遞日均訂單兩千多萬, 旗下?lián)碛袔装偬譏T應用，早在 2017 年, 中通信息安全部開發(fā)的 IAM 平臺中的 SSO 服務已基本完成了所有中通 IT 應用的接入工作, 完成了 IAM 中的統(tǒng)一用戶認證(Authentication), 下一步就是用戶權限(Authorization)的集中管控了。越權漏洞是較為常見的漏洞類型, 且其危害等級往往極高, 本文將與各位分享中通的統(tǒng)一權限安全管控系統(tǒng)實踐。

問題和挑戰(zhàn)

• 數(shù)百個IT系統(tǒng)的個性化權限需求

• 權限統(tǒng)一管控入口

• 開發(fā)友好性, 降低開發(fā)者的使用難度

• 滿足安全審計需求 

• 授權操作的易用性

權限模型設計

目前常見的權限模型有 ACL、 RBAC 和 ABAC, 下面我們來比較一下三者的優(yōu)劣勢。

ACL(Access Control List) 即為每個資源維護一個有權限訪問的用戶列表。

優(yōu)勢: 

• 易于檢查某個用戶是否有權限訪問某個資源

劣勢: 

• 需要維護大量的訪問權限列表, 數(shù)據(jù)存儲量大

• 難于為用戶批量授權, 當新員工入職時, 幾乎無法完成

RBAC(Role-Based Access Control)  基于角色的訪問控制, 在用戶和權限之間加入角色這一層, 實現(xiàn)用戶和權限的分離, 用戶只有通過激活角色才能獲得訪問權限 。

優(yōu)勢:  

• 易用和高效的授權方式, 用戶在進行授權時只需對角色進行授權, 之后將相應的角色分配給用戶即可

• 簡便和高效的授權模型維護

劣勢: 

• 無法滿足某一角色下的個別用戶需要進行特別的權限定制, 在 RBAC 模型下, 只能新建一個角色以適配需求, 長久來看最終會導致應用角色失控 

• 復雜的權限校驗, 在進行權限校驗時, 需要不斷遍歷合并權限 

ABAC(Attribute-based access control) 基于屬性的訪問控制, 也稱為基于策略的訪問控制，定義了訪問控制范例，通過將屬性組合在一起的策略向用戶授予訪問權限。策略可以使用任何類型的屬性(用戶屬性，資源屬性，對象，環(huán)境屬性等)， k8s 1.6 之前的版本基于此控制，之后也引入了 RBAC 。

優(yōu)勢:

• 動態(tài)，細粒度的訪問控制

• 可擴展性

• 易于風險控制

• 易于管理

劣勢:

• 屬性需要專門配置和維護

• 屬性數(shù)量易失控, 難以維護

• 不便于分析用戶所有的可訪問資源

中通結合自身業(yè)務需求, 最終實現(xiàn)的權限模型為 RBAC 加強版, 在 RBAC 的基礎上, 允許單獨個性化變更用戶某個權限值, 避免了 RBAC 中僅可通過角色變更權限導致角色的管理失控問題。

中通統(tǒng)一權限安全管控系統(tǒng)特色

• 將所有權限集中管理, 所有應用權限統(tǒng)一由安全管控系統(tǒng)管理配置, 無需進入各個應用單獨授權。

• 擴展了權限的控制類型, 通常的權限只能代表某個人是否有權限進行操作, 但無法滿足如用戶能進行多少次次操作等需求, 故我們增加了數(shù)字和字符串類型, 數(shù)字類型。

• 增加了權限范圍概念, 在中通的 IT 業(yè)務場景下, 需要管控的不只是用戶是否有權限訪問某個資源, 更需要限制用戶的可訪問范圍, 如上海的網(wǎng)點財務人員, 無法查看到浙江某網(wǎng)點的財務信息 。

• 權限管控以應用維度劃分, 每個應用擁有獨立的權限項列表與角色列表 。

• 增加平臺級全局角色概念, 根據(jù)員工的崗位身份, 整理歸納出所有應用共享的角色, 并映射至所有應用下, 簡化了新入職員工的授權操作流程。

• 權限互斥功能, 如用戶不應同時擁有提交工單權限與審核工單權限。

• 應用菜單管理, 為簡化前端同學的開發(fā)工作, 我們在權限之上增加了菜單配置功能, 可以將權限與菜單直接綁定, 開發(fā)同學僅需一個 API 即可獲取到當前用戶被授權的樹形菜單列表。

• 權限拷貝功能, 支持將某用戶權限與角色配置批量賦予其他人, 提升了權限分配效率。

• 與 UED 部門共同開發(fā)定制前端組件, 如地區(qū)選擇組件, 其中僅呈現(xiàn)當前用戶有權限的地區(qū)。

如下圖, 即為中通IAM平臺下, 應用的權限屬性圖。

圖1. 應用權限屬性

那么最終是如何判斷用戶是否有權限訪問某一資源呢, 步驟如下:

1.用戶登錄認證完成后, 獲取 SSO Token

2.通過 REST API, 請求權限管控系統(tǒng)

3.權限管控系統(tǒng)將以下幾組數(shù)據(jù)合并

a.個性化權限

b.用戶被授予的角色

c.權限默認值

4.判定用戶是否有權限

用戶場景

下面我們以中通統(tǒng)一權限管控系統(tǒng)的三大用戶群體視角逐一講解。 

• 應用開發(fā)者: 包含產(chǎn)品經(jīng)理, 項目經(jīng)理, 后端開發(fā), 前端開發(fā)等 

• 權限授權者: 包含網(wǎng)點管理員, 總部系統(tǒng)支持人員等 

• 審計者: 系統(tǒng)權限審計人員 

1.首先需要定義應用的功能點, 并將功能點按需整理為權限項, 如常見的權限為: 是否允許訪問系統(tǒng), 是否允許查看某一頁面, 是否允許點擊某個菜單。

圖2. 權限列表

2.對權限項進行歸納, 整理成為角色, 如下圖為一個已配置完成的角色明細。

圖3. 角色

3.菜單配置: 開發(fā)者根據(jù)需求完成樹形菜單后, 將菜單與權限進行映射。

圖4. 菜單

4.將權限配置注入代碼, 如后端 Java 應用僅需增加注解即可, 代碼如下，

圖5.代碼

5.同時 QA 與安全測試人員也可通過應用的權限配置更快了解應用的權限結構。

在接收到線上或者線下權限申請單時, 授權者僅需通過權限系統(tǒng)或移動端 App 為員工分配角色或某一權限。

圖6. 添加角色

圖7. 操作權限

1.可通過系統(tǒng)查看某一用戶在所有應用下的權限情況, 如下圖展示了某用戶摘要信息。

圖8. 用戶權限概覽

2.查詢擁有某權限或角色的用戶。

圖9. 根據(jù)角色或權限查詢用戶

3.通過權限互斥矩陣查看權限設計是否符合 SOD(職責分離) 原則。

圖10. 權限矩陣

技術架構

權限安全管控系統(tǒng)整體技術棧如下:

• Web前端: React + Dva + Antd

• 移動端: React Native 

• 后端開發(fā)語言: Golang, 并使用 Go-kit 實現(xiàn)各個微服務組件

• 持久化存儲: PostgreSQL, 充分利用PostgreSQL中JSONB類型實現(xiàn)個性化字段需求

• 緩存: Redis

• 消息隊列: Kafka

整體架構圖如下:

圖11. 業(yè)務架構

未來展望

• 用戶組策略

權限的集合是角色, 用戶的集合即為用戶組, 增加用戶組管理功能, 可大大降低新員工入職時的授權工作

• 越權漏洞檢測

基于大數(shù)據(jù)分析與自研安全掃描系統(tǒng)實現(xiàn)用戶越權行為告警, 及時找出開發(fā)者的代碼或配置問題造成的越權漏洞

• 安全風控中集成權限校驗

在安全風控中,  自動實現(xiàn) API 層權限校驗功能, 應用開發(fā)者僅需在 Web 界面中定義權限, 而無需修改應用代碼

參考鏈接：

RBAC：https://zh.wikipedia.org/wiki/%E4%BB%A5%E8%A7%92%E8%89%B2%E7%82%BA%E5%9F%BA%E7%A4%8E%E7%9A%84%E5%AD%98%E5%8F%96%E6%8E%A7%E5%88%B6

ABAC：

https://en.wikipedia.org/wiki/Attribute-based_access_control

SOD：

https://en.wikipedia.org/wiki/Separation_of_duties