ABAC - 基于属性的访问控制 - 复杂场景下访问控制解决之道

引言

引言

在一个典型的软件开发场景中，你作为一名开发人员加入到某个项目后，假设是“超人组”，你往往需要访问这个项目的代码库然后才能开始工作。当你的 Team Lead 将你加入 Git Organization 后，你自然可以访问到“超人组”的代码仓库，然后就可以愉快的进行开发工作了。但是，当你的任务完成后，可能你需要参与另一个项目，你自然就没有权利去访问“超人组”的代码库，所以你的 TL 会将你移出。这是一个典型的访问控制场景，我们所控制的对象是工程师，资源则是代码仓库。

对于软件工程师来说，类似的场景十分常见，可以说任何一个系统都存在访问控制机制，从操作系统到复杂的云上应用，我们也发明了很多名词、技术来实现类似的功能，但是核心都是为了控制人或者其他对象，能否访问资源。

Access Control Mechanism (ACM): The logical component that serves to receive the access request from the subject, to decide, and to enforce the access decision.

RBAC 的缺憾

对于访问控制模型，大家最熟悉、或者实现最多的就是 RBAC Role Based Access Control，我们通过赋予不同 role 的不同权限来进行访问控制。对于一个主体（往往是组织内的人员或者某个客户端），他可以拥有多个 role 以应对多种不同的操作权限。RBAC 的流行很重要很大程度上是贴近现实生活，方便大家理解与使用，例如老王是销售经理，同时也是技术委员会的成员，我们很自然就给他两个 role：Sales Manager 与 Technology Group Member，而这两个 role 对应的权限也很清晰明确，Sales Manager 可以查看所有的销售数据，并进行修改等，而 Technology Group Member 只能查看技术上的文献，不论是在系统设计还是在运营时，这些名词都与我们的 title 相对应，对于管理人员来说，只是修改不同的 role 对应的权限而已。 当老王专心去做技术研究之后，我们就移除他的 Sales Manager Role，这样他就无法访问销售上的数据了。

RBAC 在很多时候是管用的，比如我们的系统是面向销售公司或者学校这种组织架构很严整的地方，但是在复杂场景下，RBAC 渐渐就不够用了，它会产生很多虚无的 role 而且在管理和控制上更难：在某个医疗机构中，我们想要控制一个科室内，护士只能访问自己所负责的病人资料时，我们就无法直接使用 nurse 这个 role，我们需要更细粒度的 role 去划分病人老张还是老王，这就会产生和现实不对应的 role，例如：老张的护士，老王的护士。在医院这种病人流动性很大的场景下，频繁的创建和销毁 role 是很容易出问题，我们的确要求很频繁，但是与现实不 match 的虚无的 role 很难管理。

另一种情况是，如果管理者考虑医疗数据的安全性与隐私性，不希望护士在离开医院后能够访问到病人资料，我们会更加难办，常见的策略要么是在底层网络层进行处理，直接禁止在院外的一切访问，但是很多企业的需求往往是，使用 VPN 我依旧可以访问内部的资源，但是我还是希望基于所在地进行精确的控制，比如看邮件是可以的，但是看财务数据是不行的。在 RBAC 下，我们也可以通过虚拟的 role 来控制，比如下班后给与其 Out of Office 的 role，然后给与这个 role 最小的权限，这自然又需要虚拟的 role 与大量的动态控制。