Monthly Archive: 四月 2019

《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》读后感

本周这一篇有点略长, 所以拖到了今天才写

一句话概括

ABAC cookbook, 这篇文章事无巨细地把ABAC相关的东西讲清楚了.

一些数字

ABAC的六个阶段:
1. 用户发起请求
2. 获取访问控制policy
3. 获取主体属性
4. 获取对象属性
5. 获取环境信息
6. 完成请求

什么是ABAC?

先翻译定义:
一种根据主体被赋予的属性, 对象被赋予的属性, 环境信息以及由以上属性和信息所声明出来的策略来进行访问控制的方法. 这个方法用于主体申请对对象进行操作时, 依据策略来做出允许/拒绝的回应.

我个人的理解是, ABAC即权限策略中心. 依据主体, 对象, 环境信息来进行权限申请的决策. 决策的过程依赖于预先配置好的策略.

举一个策略的例子:
所有A公司的用户都可以在B软件里属于A公司的表进行操作.
那么这中间:
主体即用户, 有一部分用户被赋予了<A公司的>属性
对象即数据表, 有一部分表被赋予了<属于A公司的>属性
环境信息即<在B软件里>
操作即<>

依据这条规则, 如果有一个用户在B软件里执行了一条select语句, 在执行前我们发现他没有权限, 那么我们就可以根据这条策略对他做自动赋权, 做到用户无感知的情况下把申请-审批-赋权这个流程给做掉.

为什么要ABAC?

如果没有ABAC的话, 我们的流程会是用户执行select -> odps报错无权限 -> 申请权限 -> 我们根据预先配置好的审批策略决定是否需要审批 -> 赋权 -> 用户重新执行select, 并且这个审批策略是无法拓展的, 如果我们需要环境信息, 需要校验用户额外信息比如国籍等, 都需要通过更改代码的方式来实现.

当然ABAC的作用不只于此, 它还天然适用于多法律主体的数据环境. 不同的主体可以定义各自的属性库和策略库, 达到审批策略的去中心化管理, 同时策略里的环境信息也解决了跨主体访问资源时的权限控制问题.

相较于另一种权限访问策略RBAC(Role Based Access Control, 通过角色来赋权), ABAC的优势在于它是RBAC的超集, 它实际上把角色的概念抽象成为了主体的一个属性, 并且通过有层次关系的策略组来优雅地控制审批策略. 再大致翻译一个文中的例子:
RBAC:
某个人在周一到周五是A公司的门卫, 因此他作为门卫这个角色获取了开门的权限, 在周末的时候他又是B公司的清洁工, 并因此获得了使用清洁工具的权限. 虽然他拥有门卫这个角色, 但是并不意味着他能开B公司所有的门, 为了解决这个场景, 我们势必要定义一个角色叫”A公司的门卫”, 又要定一个角色叫”B公司的门卫”来把这两个角色的权限区分开, 清洁工也是同理, 相当于如果每个公司都有同样的职位的话, 我们就需要做公司到职位的笛卡尔积来组成所有的角色列表, 在复杂的场景下角色列表变得难以管理, 这就被称作”role explosion”

ABAC:
ABAC维护一份公司属性: A公司, B公司…, 再维护另一份职务属性: 清洁工, 门卫…, 这些属性只是ABAC的策略元素, 通过组合这些元素, ABAC策略可以方便地完成组合. 同时, 周一到周五这么一个定义也能作为属性的一部分, 进一步灵活地配置策略

为什么不要ABAC

这篇文章在列举了ABAC的种种好处时, 也客观地指出了一些采用ABAC时需要考虑的因素:
1. ABAC的实现方式多样, 即可以内嵌到现有的系统, 也能独立成为一个策略中心, 要综合考虑使用场景来决定具体的实现方式
2. ABAC要求对接系统支持与提供ABAC中的属性与环境信息
3. 相较于普通ACL的信任链(图一), ABAC的信任链(图二)显然要复杂很多, 要考虑到现有实现的迁移成本及后期维护成本, 是否值得
4. 属性列表的维护需要考虑隐私及合规方面的诉求, 例如我们是否需要年薪xx以上这样的属性

(图一)

(图二)

总结

除了之前大致的介绍, 文章还对实现ABAC中需要注意的实现及抽象模型做了定义, 譬如要有元属性(Metaattributes)的定义, 还有元策略(Metapolicy)的定义, 以及如何从人能读懂的自然语言策略(Natural Language Policy) 转换成能用代码表示的数码策略(Digital Policy), 建议在实现时具体参考