ABAC 还是 RBAC ?
Role Based Access Control 是从 1970 年发起的，被行业很好的接受并成为业内标准。然而伴随着 Attribute Based Access Control 的到来，许多公司将注意力转移到 ABAC 上来，因为他们体会到了这种粒度更加细致的权限分配所带来的优势。
在深入了解 ABAC 之前，让我们先分别了解一下他们。
RBAC
基于角色的权限分配：将用户分组为各种角色，然后分配权限。
典型的权限是对一种资源的行为控制： 例如，创建文档、更新用户信息。任何人一旦被分配到一种角色，那么他就拥有该角色的一系列权限。
因此， RBAC 是一种基于角色的权限系统，由于其简单的理念被应用于超多的系统。然而，当系统不断成长进化，管理员需要更细粒度的权限时，这时问题就产生了： 更细的粒度的权限会衍生出更多的角色（角色爆炸，与类爆炸类似）。 另外， 随着新角色的创建，势必要适应每个对应的应用场景，系统的安全性可能变得难以管理甚至更难以测试。 这将会在系统中留下未知的漏洞。
ABAC
ABAC 就是基于 RBAC 的痛点进化出的一种解决方案： 允许您根据系统可访问的任何属性强制执行安全决策，而不仅仅是用户的角色。 这可以是用户（领域）的属性、 用户正在执行的操作、 他们尝试操作或检索的资源的值、甚至是环境变量。 这几个方面的组合允许设置与您期望的一样细粒度的策略。
ABAC 通过以下主要组件实现了这种灵活性：
- Policy Decision Point (PDP): 系统的”大脑”。 PDP 接收 XACML 格式的请求并处理请求，返回用户是否能够继续的决定。
- Policy Information Point (PIP): PDP 利用 PIP 提取做出决定所需的任何信息。 PIP 可以与活动目录或数据库通信以查找用户详细信息， 甚至可以调用外部 API 来获取有助于做出决定的数据。
- Policy Enforcement Point (PEP): 系统的”网关”， 它拦截请求并调用 PDP 以确保用户可以继续。 如果 PDP 显示 “DENY”，则 PEP 将执行该决定。
- Policy Administration Point (PAP): 大多数开箱即用的解决方案都有一个用户界面来帮助用户配置他们的策略。
看起来 ABAC KO RBAC，你觉得呢 ?
ABAC 听起来像是一种更好的方法(因为强大，因为灵活，因为粒度更加细致！), 但我们依然有正当理由认为这种方法可能不适合所有需求，或者仅仅是矫枉过正。
- KISS，有时候，less is more! 如果你可以让所有用户都适合3个角色，那就太好了, RABC 就已经足够！ 除非当你有一系列更加细致的权限策略需要被定制（比角色xy可拥有a,b,c三种行为更加细致的策略）。 以下是一些在尝试实施 ABAC 可能有用的示例：
- 只有创建记录的用户才能删除记录。
- 用户只能查看他们所在州或国家/地区的文档。
- 管理员只能编辑低于他一级的个人的用户信息。
- 强大的力量带来极大的复杂性。 如果没有对系统强制执行的策略进行良好管理，(“属性爆炸”)可能会比”角色爆炸”更糟糕。
- 由于 ABAC 系统的体系结构以及使其运行所需的组件数量， 因此构建成本高。
- 随着所有新事物的到来需要更多更新的相关培训。 如果 RBAC 系统已经运行良好，为什么要花钱培训人员来构建，管理和支持新的ABAC系统嘞？
- 组合的方法可能比将一种解决方案套入另一种解决方案更好。 也许对于系统的某些部分，适合构建 RBAC，但对于另一部分，ABAC 对于满足业务需求将会显得至关重要。 在这些需求之间保持清晰的划分可以实现成功的整体的安全的解决方案！
所以，做适合自己的选择吧！ 嗷呜~
本文译自：ABAC or RBAC