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

2018-11-03 11,285

作者简介 

李龙贺, 中通快递安全研发工程师,目前主要负责权限系统开发及支持工作。个人研究方向是大前端,日常爱好心理学,喜欢冬天午后的阳光。


中通快递日均订单两千多万, 旗下拥有几百套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平台下, 应用的权限属性图。


image.png

图1. 应用权限属性


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

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

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

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

a.个性化权限

b.用户被授予的角色

c.权限默认值

4.判定用户是否有权限

用户场景

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

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

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

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


应用开发者

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

图片2.png


图2. 权限列表


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


图片3.png

图3. 角色


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


图片4.png

图4. 菜单



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

图片5.png

图5.代码


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


权限授权者

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


ezgif.com-video-to-gif (2).gif

图6. 添加角色


ezgif.com-video-to-gif (1).gif


图7. 操作权限



审计者

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


图片8.png


图8. 用户权限概览


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

图片9.png

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

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


图片10.png

图10. 权限矩阵


技术架构

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

  • Web前端: React + Dva + Antd

  • 移动端: React Native 

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

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

  • 缓存: Redis

  • 消息队列: Kafka


整体架构图如下:


image.png

图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

Tags:
评论  (0)
快来写下你的想法吧!

中通SRC

文章数:8 积分: 3

中通快递高薪诚招各路安全人才~ 更多原创文章、招聘详情关注中通SRC公众号:ZSRC

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号