RBAC（Role-based access control，基于角色的访问控制）是一种基于用户在组织中的角色限制数字资源访问的方式。举个例子，在RBAC模型下，一个企业的会计应该能够接入企业财务记录，但是不能接入用于企业网站升级的内容管理系统；而对企业的网站开发团队而言，访问标准可能正好颠倒过来。
几乎每个企业都会针对自己的数字资产进行某些访问控制——事实上，当今的每个操作系统都会内置一些访问控制。访问控制一般会给予或者限制个体用户或者用户组针对性的访问权限。RBAC和其他访问控制的区别在于，用户是基于他们的角色进行分组，而许可都是基于这些角色决定，而不是针对每个用户的具体的身份决定。
RBAC如何实现
RBAC基本上是基于最小权限原则，意味着任何用户都只有他们需要接入的数据和功能的权限。这个听上去理论上很合理，但是核心问题在于如何实现：我们如何决定哪些是用户需要做的？又如何在不给管理员增加负担的情况下，将权限和限制应施加给用户？
RBAC解决这些问题的方式是基于用户具体做什么，而非他们是谁。相比于提前为每个用户建立一系列的权限，RBAC则是有一些提前定义好的组织内角色，然后每个用户满足其中一个或者多个角色。对于每个角色，会有一系列调整好的权限满足其需求，同时这些权限的配置会被所有满足那个角色的用户共享。如果一个角色的权限需要被改变，这些改变会同样应用到相关用户的配置，从而简化系统管理。
RBAC角色
角色显然是RBAC的核心。但是需要注意的是，角色的定义是一个管理和概念的行为，而非是技术层面的。从系统底层理念来看，每个角色其实不过是一组用户；组织会决定员工角色的合理分配，以及每个人都符合哪些角色，这也是RBAC实现的最重要的流程部分。
因此，角色的设置会因组织大不相同。这就意味着，大部分企业会基于组织自身内部结构建立角色。安全供应商UpGuard在他们自己的博客上给出了一些角色分类的例子，以及不同角色需要接入许可的应用：
-
软件工程：GCP、AWS和GitHub
-
市场：HubSpot、Google Analytics、Facebook Ads、Google Ads
-
财务：Xero和ADP
-
人力资源：Lever和BambooHR
值得注意的是，一个用户完全可以被赋予多个角色。举个例子，可以有一个基础的“员工”等级角色，赋予企业中每个人，确保像电子邮件和日历等组织范围内应用的使用；除此以外，还能有更为专注的角色，可以允许接入部门数据和应用。同样可以有“经理”角色，给某些用户提供各个部门内更多的数据接入权限。
RBAC矩阵
一旦定义了角色，下一步就是确定每个角色应用的权限和限制。一种方法是通过RBAC矩阵实现：以角色为行，不同对象或者行为作为列，构建表格。
David W.Enstrom在其《Unified Architecture Mehtod》中有多个RBAC矩阵的例子。首先，是针对基础架构中特定的数据对象。行代表了用户在组织中抽象的角色，列代表着一个用户可能对被保护对象可以采取的行为。如果一个角色需要有采取某个行为的权限，相关行列交错的单元格就会用X标记。
| 创建 | 读取 | 更新 | 删除 | 执行 | |
| 经理 | X | X | |||
| 作者 | X | X | X | X | |
| 编辑 | X | X | |||
| 发布 | X | X | X |
通过这个矩阵，可以获得颗粒度的细分，发现不同角色的用户被允许以及不被允许做哪些行为。下一个表格会相对不那么抽象。行是基于工作头衔定义的角色，列则是有这些角色的用户可能会交互的对象。每个单元格会包含CRUDE中的字母（C代表了创建，R代表了读取，U代表了更新，D代表了删除，E代表了执行）。
| 订单 | 清单 | 客户 | 员工 | 产品 | |
| 销售副总监 | CRUD | CRUD | CRUD | CRUD | CRUD |
| 销售经理 | CRUDE | CRUD | RU |
R |
R |
| 销售代表 | CRUD | R |
RU |
R |
R |
| 仓库经理 | R |
RU |
这样就能更为直观地感受RBAC如何能够从实践定义个体用户的权限。高层的销售员工可以创建新的清单，而基础的员工只能读取。特定的仓库经理和整个部门的经历可以更新产品记录，但是中层员工只能读取。
再说一遍，这些行列的构建是不需要任何技术支持的。这么做的目的是掌握组织结构和数据接入需求，最终由RBAC具象化。
RBAC最佳实践
如果需要深入了解如何应用RBAC，最好看一下由ANSI制定的RBAC标准，INCITS 359-2021。简单来看的话，MorganFranklin有一个最佳实践的清单，可以作为起点。一些关键建议包括：
-
把RBAC作为一个持续性规划，而非单独项目。不要期望一开始设定的角色和权限是不变的。企业会需要基于RBAC实践效果，以及组织的发展与变化，对RBAC进行修改。
-
清理坏数据。如果数据结构本身很混乱，就很难知道哪些角色能够接入哪些数据。纯净的数据是RBAC规划成功的主要因素。
-
设定一个角色拥有者，作为各个业务侧的代表。谁有每个部门最好的“内部知识”？企业需要在团队里有这批人，来定义组织内的角色。
-
角色循环使用。如果组织中的某个人有一个独一无二的角色，那么这个角色可能不适合通过RBAC进行管理。RBAC失败的一大原因就是“角色暴涨”，指的就是为了抓住每个不同员工职责中每个细微的区别导致增加了大量的角色。在这条路上走得太久，会发现企业对每个员工都有一个独特的角色，那反而抹除了RBAC大部分价值。企业需要尽量将事情简化，避免给IT带来管理上的负担。
RBAC的优劣
希望到这里为止，RBAC的大部分价值都很明确了。RBAC模型为企业提供了落地最小权限原则的一个途径，同时能够降低管理负担，以及为每个个体用户修改权限而导致的潜在风险。这种方式限制权限，能够防范内部攻击，同时阻断账户在外部失陷后进行的权限提升攻击。
除此以外，许多安全和数据安全规范都会明确企业的哪些职业应该以及不应该接入敏感数据。一个详细记录的RBAC规划能够帮助组织满足这些法律要求。
这同时表示，RBAC并非万灵药。就像在看前面的RBAC行列的时候，可能就会感觉将这些东西拼凑到一起是一项巨大的工程。尽管说RBAC会剩下许多的管理精力，但也确实在起步阶段会要投入大量的工作；这从长期来看未必划算，尤其对小型企业而已。与此同时，有许多不同部门的大型企业可能会有需要要建立的角色，意味着RBAC的复杂性会大大增加。
RBAC vs. ACL、ABAC和IAM
既然了解了RBAC一些劣势，那就可能需要考虑一下其他的选项。一个最常见的是ACL（Access Control List，访问控制列表）。如果说RBAC的思路是从用户和角色角度思考权限，那么ACL就是从用户交互的数据或者功能角度思考。ACL只是一个各个数据对象组成的列表，包含具体谁能对该对象进行何种操作的信息。概念上而言这个更简单，而且如果没有许多数据对象要处理，创建的工作量也会相比RBAC少很多。但是，显然ACL并不合适于大型企业。
ABAC（Attribute-based access control，基于属性的访问控制）某种程度上是基于RBAC的。ABAC将重心从用户侧移开，如其名一样，转而注重于系统中各元素的属性，然后将它们集合到布尔规则表里。举个例子，在ABAC样式下，如果某种类型的用户在一天的某个时间对某种类型的对象进行了某种行为，所有的这些属性都会作为考虑因素来决定该行为是否能被许可。可能每个人都能在工作日读取和更新财务记录，但是只有会计部门的经理能够在其他时间段这么做。ABAC显然相比RBAC颗粒度更高，但是同样也会需要更多的管理支持。
还有一个东西也比较类似——IAM（Identity and access management，身份与访问管理）。但是，RBAC和IAM并不对立。IAM定义和管理在云端和本地部署的应用中的网络单独实体的角色和权限。
换句话说，RBAC代表了使用IAM的一种方式，而ABAC和ACL代表了其他方式。这就到了最后的一个问题：从技术上来看，RBAC如何实现？
RBAC工具、解决方案和例子
好消息是，企业不需要从零开始建立RBAC解决方案：企业可以用市面上许多IAM提供的模板来实现RBAC。另外，像亚马逊AWS和微软Azure的主流云厂商也提供RBAC能力。
如果需要了解在实际当中如何实现的例子，可以在像Auth0之类的IAM厂商处发现案例。这些文件可以指导用户如何通过他们的平台实现RBAC，如何基于企业的独特需求自定义位置。
RBAC的使用是一条很长的旅程，但是回报是值得的。
身份与权限的管理始终都是安全工程中重要的一环。尽管说当前来看，相关安全能力在技术层面依然很大的改进空间，但是身份与权限管理的基础依然是从管理上建立良好的模型，才能实现。一味追求强大的安全能力，却忽略了自身安全管理体系的建设，往往会成为安全建设中最大的失败因素。
参考阅读
AI权限管控、内存指令安全与后门发现：第三代安全引擎的三个创新应用
原文始发于微信公众号（数世咨询）：RBAC浅谈
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论