中通统一权限安全管控系统实践

中通快递日均订单两千多万, 旗下拥有几百套IT应用，早在 2017 年, 中通信息安全部开发的 IAM 平台中的 SSO 服务已基本完成了所有中通 IT 应用的接入工作, 完成了 IAM 中的统一用户认证(Authentication), 下一步就是用户权限(Authorization)的集中管控了。越权漏洞是较为常见的漏洞类型, 且其危害等级往往极高, 本文将与各位分享中通的统一权限安全管控系统实践。

问题和挑战

• 数百个IT系统的个性化权限需求

• 权限统一管控入口

• 开发友好性, 降低开发者的使用难度

• 满足安全审计需求 

• 授权操作的易用性

权限模型设计

目前常见的权限模型有 ACL、 RBAC 和 ABAC, 下面我们来比较一下三者的优劣势。

ACL(Access Control List) 即为每个资源维护一个有权限访问的用户列表。

优势: 

• 易于检查某个用户是否有权限访问某个资源

劣势: 

• 需要维护大量的访问权限列表, 数据存储量大

• 难于为用户批量授权, 当新员工入职时, 几乎无法完成

RBAC(Role-Based Access Control)  基于角色的访问控制, 在用户和权限之间加入角色这一层, 实现用户和权限的分离, 用户只有通过激活角色才能获得访问权限 。

优势:  

• 易用和高效的授权方式, 用户在进行授权时只需对角色进行授权, 之后将相应的角色分配给用户即可

• 简便和高效的授权模型维护

劣势: 

• 无法满足某一角色下的个别用户需要进行特别的权限定制, 在 RBAC 模型下, 只能新建一个角色以适配需求, 长久来看最终会导致应用角色失控 

• 复杂的权限校验, 在进行权限校验时, 需要不断遍历合并权限 

ABAC(Attribute-based access control) 基于属性的访问控制, 也称为基于策略的访问控制，定义了访问控制范例，通过将属性组合在一起的策略向用户授予访问权限。策略可以使用任何类型的属性(用户属性，资源属性，对象，环境属性等)， k8s 1.6 之前的版本基于此控制，之后也引入了 RBAC 。

优势:

• 动态，细粒度的访问控制

• 可扩展性

• 易于风险控制

• 易于管理

劣势:

• 属性需要专门配置和维护

• 属性数量易失控, 难以维护

• 不便于分析用户所有的可访问资源

中通结合自身业务需求, 最终实现的权限模型为 RBAC 加强版, 在 RBAC 的基础上, 允许单独个性化变更用户某个权限值, 避免了 RBAC 中仅可通过角色变更权限导致角色的管理失控问题。

中通统一权限安全管控系统特色

• 将所有权限集中管理, 所有应用权限统一由安全管控系统管理配置, 无需进入各个应用单独授权。

• 扩展了权限的控制类型, 通常的权限只能代表某个人是否有权限进行操作, 但无法满足如用户能进行多少次次操作等需求, 故我们增加了数字和字符串类型, 数字类型。

• 增加了权限范围概念, 在中通的 IT 业务场景下, 需要管控的不只是用户是否有权限访问某个资源, 更需要限制用户的可访问范围, 如上海的网点财务人员, 无法查看到浙江某网点的财务信息 。

• 权限管控以应用维度划分, 每个应用拥有独立的权限项列表与角色列表 。

• 增加平台级全局角色概念, 根据员工的岗位身份, 整理归纳出所有应用共享的角色, 并映射至所有应用下, 简化了新入职员工的授权操作流程。

• 权限互斥功能, 如用户不应同时拥有提交工单权限与审核工单权限。

• 应用菜单管理, 为简化前端同学的开发工作, 我们在权限之上增加了菜单配置功能, 可以将权限与菜单直接绑定, 开发同学仅需一个 API 即可获取到当前用户被授权的树形菜单列表。

• 权限拷贝功能, 支持将某用户权限与角色配置批量赋予其他人, 提升了权限分配效率。

• 与 UED 部门共同开发定制前端组件, 如地区选择组件, 其中仅呈现当前用户有权限的地区。

如下图, 即为中通IAM平台下, 应用的权限属性图。

图1. 应用权限属性

那么最终是如何判断用户是否有权限访问某一资源呢, 步骤如下:

1.用户登录认证完成后, 获取 SSO Token

2.通过 REST API, 请求权限管控系统

3.权限管控系统将以下几组数据合并

a.个性化权限

b.用户被授予的角色

c.权限默认值

4.判定用户是否有权限

用户场景

下面我们以中通统一权限管控系统的三大用户群体视角逐一讲解。 

• 应用开发者: 包含产品经理, 项目经理, 后端开发, 前端开发等 

• 权限授权者: 包含网点管理员, 总部系统支持人员等 

• 审计者: 系统权限审计人员 

1.首先需要定义应用的功能点, 并将功能点按需整理为权限项, 如常见的权限为: 是否允许访问系统, 是否允许查看某一页面, 是否允许点击某个菜单。

图2. 权限列表

2.对权限项进行归纳, 整理成为角色, 如下图为一个已配置完成的角色明细。

图3. 角色

3.菜单配置: 开发者根据需求完成树形菜单后, 将菜单与权限进行映射。

图4. 菜单

4.将权限配置注入代码, 如后端 Java 应用仅需增加注解即可, 代码如下，

图5.代码

5.同时 QA 与安全测试人员也可通过应用的权限配置更快了解应用的权限结构。

在接收到线上或者线下权限申请单时, 授权者仅需通过权限系统或移动端 App 为员工分配角色或某一权限。

图6. 添加角色

图7. 操作权限

1.可通过系统查看某一用户在所有应用下的权限情况, 如下图展示了某用户摘要信息。

图8. 用户权限概览

2.查询拥有某权限或角色的用户。

图9. 根据角色或权限查询用户

3.通过权限互斥矩阵查看权限设计是否符合 SOD(职责分离) 原则。

图10. 权限矩阵

技术架构

权限安全管控系统整体技术栈如下:

• Web前端: React + Dva + Antd

• 移动端: React Native 

• 后端开发语言: Golang, 并使用 Go-kit 实现各个微服务组件

• 持久化存储: PostgreSQL, 充分利用PostgreSQL中JSONB类型实现个性化字段需求

• 缓存: Redis

• 消息队列: Kafka

整体架构图如下:

图11. 业务架构

未来展望

• 用户组策略

权限的集合是角色, 用户的集合即为用户组, 增加用户组管理功能, 可大大降低新员工入职时的授权工作

• 越权漏洞检测

基于大数据分析与自研安全扫描系统实现用户越权行为告警, 及时找出开发者的代码或配置问题造成的越权漏洞

• 安全风控中集成权限校验

在安全风控中,  自动实现 API 层权限校验功能, 应用开发者仅需在 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