两种常见的访问控制模型

那就是ACL(Access-control list,访问控制列表)和RBAC(Role-based access control,基于角色的访问控制)。

如果我们现场来做一个访问控制,会怎么做呢?最简单的就是,像门卫一样,把每个人和每个对象做一行记录,比如:

张三 -> 电表:可读
李四 -> 电表:可写
王二麻子 -> 电表:可读可写

张三 -> 水表:可读可写

这种模型简单粗暴,谁有权限,就记录下来。在文件系统中,这种模式还挺好用的,因为UNIX的经典权限模型常见情况下都够用, ACL做一个扩充,够了。

但是在实际业务系统中,这样就有一点点小麻烦。如果一个公司有几千号人、几万人甚至数十万人,而要做权限控制的东西也很多, 那就是 MxN 的复杂度,这个列表维护起来似乎并不简单。

没有什么问题是加一个中间层解决不了的,如果有,就加两个。

所以我们要加一个中间层,把人和对象中间加一个东西:角色。比如:

我们把电表的权限分为:

  • 可读(抄表员角色)
  • 可写(维修员角色)
  • 读写(电表管理员)

水表的权限分为:

  • 可读(抄表员角色)
  • 可写(维修员角色)
  • 读写(水表管理员)

此时电表、水表只与何种角色有关,我们再将角色与人关联起来,就可以实现访问控制,比如上述ACL可以设置为:

张三:电表的抄表员,水表的管理员
李四:电表的维修员
王二麻子:电表的管理员

正是因为在实际业务场景中,很多权限其实都是重复的,因此我们可以将重复的东西抽象出来,使用角色,分别和人、物绑定,这就 产生了基于角色的访问控制。


参考资料:


微信公众号
关注公众号,获得及时更新

更多文章
  • 容器时代的日志处理
  • Golang和Thrift
  • 折腾Kubernetes
  • 协程(coroutine)简介 - 什么是协程?
  • goroutine 切换的时候发生了什么?
  • Prometheus 数据类型
  • Gin源码阅读与分析
  • 如何面试-作为面试官得到的经验
  • 自己写一个容器
  • Golang(Go语言)中实现典型的fork调用
  • 软件开发之禅---大事化小,各个击破
  • 程序员的自我修养:链接,装载与库 阅读笔记
  • Redis源码阅读与分析三:哈希表
  • Redis源码阅读与分析一:sds
  • Redis源码阅读与分析二:双链表