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

問題和挑戰(zhàn)

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

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

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

• 滿足安全審計(jì)需求 

• 授權(quán)操作的易用性

權(quán)限模型設(shè)計(jì)

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

ACL(Access Control List) 即為每個(gè)資源維護(hù)一個(gè)有權(quán)限訪問的用戶列表。

優(yōu)勢(shì): 

• 易于檢查某個(gè)用戶是否有權(quán)限訪問某個(gè)資源

劣勢(shì): 

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

• 難于為用戶批量授權(quán), 當(dāng)新員工入職時(shí), 幾乎無法完成

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

優(yōu)勢(shì):  

• 易用和高效的授權(quán)方式, 用戶在進(jìn)行授權(quán)時(shí)只需對(duì)角色進(jìn)行授權(quán), 之后將相應(yīng)的角色分配給用戶即可

• 簡(jiǎn)便和高效的授權(quán)模型維護(hù)

劣勢(shì): 

• 無法滿足某一角色下的個(gè)別用戶需要進(jìn)行特別的權(quán)限定制, 在 RBAC 模型下, 只能新建一個(gè)角色以適配需求, 長(zhǎng)久來看最終會(huì)導(dǎo)致應(yīng)用角色失控 

• 復(fù)雜的權(quán)限校驗(yàn), 在進(jìn)行權(quán)限校驗(yàn)時(shí), 需要不斷遍歷合并權(quán)限 

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

優(yōu)勢(shì):

• 動(dòng)態(tài)，細(xì)粒度的訪問控制

• 可擴(kuò)展性

• 易于風(fēng)險(xiǎn)控制

• 易于管理

劣勢(shì):

• 屬性需要專門配置和維護(hù)

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

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

中通結(jié)合自身業(yè)務(wù)需求, 最終實(shí)現(xiàn)的權(quán)限模型為 RBAC 加強(qiáng)版, 在 RBAC 的基礎(chǔ)上, 允許單獨(dú)個(gè)性化變更用戶某個(gè)權(quán)限值, 避免了 RBAC 中僅可通過角色變更權(quán)限導(dǎo)致角色的管理失控問題。

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

• 將所有權(quán)限集中管理, 所有應(yīng)用權(quán)限統(tǒng)一由安全管控系統(tǒng)管理配置, 無需進(jìn)入各個(gè)應(yīng)用單獨(dú)授權(quán)。

• 擴(kuò)展了權(quán)限的控制類型, 通常的權(quán)限只能代表某個(gè)人是否有權(quán)限進(jìn)行操作, 但無法滿足如用戶能進(jìn)行多少次次操作等需求, 故我們?cè)黾恿藬?shù)字和字符串類型, 數(shù)字類型。

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

• 權(quán)限管控以應(yīng)用維度劃分, 每個(gè)應(yīng)用擁有獨(dú)立的權(quán)限項(xiàng)列表與角色列表 。

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

• 權(quán)限互斥功能, 如用戶不應(yīng)同時(shí)擁有提交工單權(quán)限與審核工單權(quán)限。

• 應(yīng)用菜單管理, 為簡(jiǎn)化前端同學(xué)的開發(fā)工作, 我們?cè)跈?quán)限之上增加了菜單配置功能, 可以將權(quán)限與菜單直接綁定, 開發(fā)同學(xué)僅需一個(gè) API 即可獲取到當(dāng)前用戶被授權(quán)的樹形菜單列表。

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

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

如下圖, 即為中通IAM平臺(tái)下, 應(yīng)用的權(quán)限屬性圖。

圖1. 應(yīng)用權(quán)限屬性

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

1.用戶登錄認(rèn)證完成后, 獲取 SSO Token

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

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

a.個(gè)性化權(quán)限

b.用戶被授予的角色

c.權(quán)限默認(rèn)值

4.判定用戶是否有權(quán)限

用戶場(chǎng)景

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

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

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

• 審計(jì)者: 系統(tǒng)權(quán)限審計(jì)人員 

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

圖2. 權(quán)限列表

2.對(duì)權(quán)限項(xiàng)進(jìn)行歸納, 整理成為角色, 如下圖為一個(gè)已配置完成的角色明細(xì)。

圖3. 角色

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

圖4. 菜單

4.將權(quán)限配置注入代碼, 如后端 Java 應(yīng)用僅需增加注解即可, 代碼如下，

圖5.代碼

5.同時(shí) QA 與安全測(cè)試人員也可通過應(yīng)用的權(quán)限配置更快了解應(yīng)用的權(quán)限結(jié)構(gòu)。

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

圖6. 添加角色

圖7. 操作權(quán)限

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

圖8. 用戶權(quán)限概覽

2.查詢擁有某權(quán)限或角色的用戶。

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

3.通過權(quán)限互斥矩陣查看權(quán)限設(shè)計(jì)是否符合 SOD(職責(zé)分離) 原則。

圖10. 權(quán)限矩陣

技術(shù)架構(gòu)

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

• Web前端: React + Dva + Antd

• 移動(dòng)端: React Native 

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

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

• 緩存: Redis

• 消息隊(duì)列: Kafka

整體架構(gòu)圖如下:

圖11. 業(yè)務(wù)架構(gòu)

未來展望

• 用戶組策略

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

• 越權(quán)漏洞檢測(cè)

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

• 安全風(fēng)控中集成權(quán)限校驗(yàn)

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

參考鏈接：

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