作者简介
李龙贺, 中通快递安全研发工程师，目前主要负责权限系统开发及支持工作。个人研究方向是大前端，日常爱好心理学，喜欢冬天午后的阳光。
中通快递日均订单两千多万, 旗下拥有几百套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
本文作者：中通SRC
本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/78706.html
必填 您当前尚未登录。 登录？ 注册
必填（保密）