周志明的软件架构课
周志明
博士,远光软件研究院院长,《深入理解 Java 虚拟机》《凤凰架构》等书作者
51443 人已学习
免费领取
课程目录
已完结/共 74 讲
架构师的视角 (24讲)
周志明的软件架构课
15
15
1.0x
00:00/00:00
登录|注册

25 | 授权(下):系统如何确保授权的结果可控?

你好,我是周志明。今天,我们接着上一讲的话题,继续来探究关于授权的第二个核心问题:系统如何确保授权的结果可控?
在上节课的开篇,我提到了授权的结果是用于对程序功能或者资源的访问控制(Access Control),并且也给你介绍了一种最为常用的权限控制模型 RBAC(基于角色的访问控制,Role-Based Access Control)。
那么这节课,我就来和你聊聊这种访问控制模型的概念、原理和一些要注意的问题。希望你能在理解了 RBAC 是如何运作的之后,将其灵活运用在自己实际工作中关于功能、数据权限的管理上,而且这也是为后面学习 Kubernetes 的权限控制、服务安全等内容提前做的铺垫工作。
好,接下来,我们就从 RBAC 的几个基础概念开始学起吧。

RBAC 的基础概念

首先,我们要明确,所有的访问控制模型,实质上都是在解决同一个问题:谁(User)拥有什么权限(Authority)去操作(Operation)哪些资源(Resource)。
这个问题初看起来并不太难,一种直观的解决方案就是在用户对象上设定一些权限,当用户使用资源时,检查是否有对应的操作权限即可。很多著名的安全框架,比如 Spring Security 的访问控制,本质上就是支持这么做的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该试读文章来自《周志明的软件架构课》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(15)

  • 最新
  • 精选
  • Helios
    用过k8s中的rbac,如果有应用想访问k8s中的资源,需要有一个account,还要有一个role,role里面包含了对哪些数据能够操作的权限。 Account和role没有耦合关系,是相对独立的。他们通过rolebinding进行结合,达到绑定的目的。 如果应用想更换权限,可以操作对应的role也可以改account 。 这样不能在创建一个新role的时候进行继承,这个account可能会对应多个role。个人感觉有一些鸡肋的地方就是对数据的操作力度的定义,如果太细吧,可能会创建很多,如果再粗一点,可能某个role多一个权限或者少一个权限没法补。

    作者回复: kubernetes的RBAC贴近于基础的RBAC0模型,不能直接做到你所期望的继承,且在kubernetes中verbs也就那么些,其实也并不太需要继承。 不过在其他系统中,权限可能很多,继承有可能有必要,所以在RBAC1是允许继承的。话说RBAC要不要支持继承这个话题业界一直都有争论。

    1
  • Empty
    我们做的大部分信息系统都是使用RBAC的权限控制,一般有:用户、角色、菜单。用户隶属于角色、角色会赋予能看到的菜单。这大概是最简单最常用的RBAC实现了吧。

    作者回复: 是的,算RBAC思想的运用

    1
  • zhanyd
    角色是为了解耦用户和权限之间的多对多关系,比如有100个用户他们的权限都是一样的,如果每个用户都设一遍权限这就太麻烦了,而且还很容易出错。这时候设置一个角色,把对应的权限配置到角色上,然后这100个用户加到这个角色中就行了。 角色还有一个好处,如果角色的权限变了,所有角色中用户的权限也会同时变更,不用一个个用户去设置了。 许可是为了解耦操作与资源之间的多对多关系,比如有新增用户,编辑用户,删除用户的三种操作,通常都是一起的,要么都能操作,要么都不能操作,这时候就可以把这三种操作打包成一个用户维护许可,用许可和角色关联更简洁。 关于Spring Security中的Role和Authority我是这么理解的: Role就是普通的角色,拥有一组许可,这个角色下的所有用户的权限都是一样的。 但是如果一个角色中的一些用户,有个性化的需求,比如销售助理角色,本来没有查看客户的权限,但是某个销售助理比较特殊,需要查看客户的信息。 这时如果是单角色的系统(我现在设计的系统就是这样子,说多了都是泪),就需要新增一个“销售助理可查看客户角色”,这样很容易导致角色数量爆炸。 有了Authority,就可以满足这种个性化需求,只要把查看客户的权限加到Authority中赋予用户就行了。
    1
    41
  • andy
    关于数据权限的抽象,是不是有一种常用的方案可以抽象为以下几种情况: 1. 仅允许修改自己的数据 2. 允许修改自己及同部门的数据 3. 允许修改自己及同部门及下级部门的数据 4. 允许修改全部数据 5. 自定义,默认自己的数据可以修改,勾选其他可修改的部门。 然后上述五种情况,可以与角色挂钩,也可以与用户直接挂钩。
    2
    11
  • neohope
    功能权限主要是用Spring。 数据权限确实很多时候只能系统自己处理,很难跨行业通用,甚至同一行业不同机构也不尽相同。比如两个看似比较通用的场景: 1、当机构架构分为多级时,上级机构能看到下级哪些数据,平级之间能看到那些数据,下级机构能看到什么数据,各行业各类组织互不相同。如果只用功能权限的思路去解决这个问题,容易将功能权限弄得十分复杂。 2、此外就是用户情况比较复杂,比如除了组织架构、岗位、职级外,还有职业证书相关权限控制、客户业务办理关系、项目组组成、项目组轮班,加上审核、稽核、多级质控等功能,仅是功能权限也是力有不逮。 而且,近些年来,各公司对数据权限和数据安全的要求都越来越高、越来越严格了。
    6
  • 李皮皮皮皮皮
    一般使用casbin,它提供了各种语言的库。除了RBAC还支持其他各种访问控制模型。
    4
  • 有铭
    关于那个数据权限的问题,很久以前我就观察到windows的系统权限应该就是典型的RBAC模型,但是windows能把某个文件的某些权限直接授予给特定用户,并禁止其它用户使用这些权限的功能。但是挺震撼的,因为我想了很久,没想出来如何比较方便的实现这个功能
    3
  • 大力水手Jerry
    “角色为的是解耦用户与权限之间的多对多关系,而许可为的是解耦操作与资源之间的多对多关系。”,我觉得这个描述不太准确,有为解耦而解耦的感觉。用户与权限之间是多对多,用户与角色之间同样是多对多,可以说解耦用户与权限,但不能说解耦“多对多关系”。实际上,铁打的营盘流水的兵,基于角色来描述组织结构是顺理成章,角色并不是为了解耦用户和权限而生造出来的概念;基于角色管理权限,提升了管理的粒度,因此降低了管理的复杂度,提高了管理的效率。我觉得这才是角色存在的理由。另一方面,许可本质上是一种资格,比如员工可以在餐厅吃饭,也可以不吃,总经理可以在餐厅举办宴会,也可以不举办。如果我们把餐厅当成一种资源,那么吃和举办宴会就是操作,许可并没有解耦操作与资源,而是通过绑定操作和资源,为权限给出具体的定义。
    2
    1
  • Zhi Liu
    Aws 的权限设计包含role permission和resource permission. 通过resource permission就可以限制可以修改资源的role或者user. 例子是。S3 bucket
    归属地:美国
  • Andrew陈海越
    对RBAC多了几点认识。1. permission 许可 解耦了操作与资源的关系,更细粒度地控制。 2. Contrains 约束 保证了不同角色、不同许可之间 满足互斥条件,比如出纳和会计不能给同一个人,否则财务账目可能出问题。
    归属地:湖南
收起评论
显示
设置
留言
15
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部