安全访问 - 第3章 RBAC模型
3.1 概念
Role-Based Access Control (基于角色的访问控制)，简称RBAC。是一种基于角色并使用角色中预先定义的策略(Policy)对主体操作对象进行验证的访问控制方式。NIST于1992年发表论文对RBAC标准进行了定义。
什么是角色？在企业中访问控制的范围通常取决于员工所扮演的角色，角色中包含企业已确认的职责、责任和资格的规范，例如：软件公司中的角色包括工程师、设计师、商务人员 等，每一种角色根据其包含的职责通常有不同的访问范围。
主体是指用户或组织。
对象是系统资源，如⽂件、设备、程序、网络等。
操作是主体请求对对象执⾏的功能。例如文件操作，包括对文件的读、写、编辑、删除、复制、执⾏和修改等。
策略(Policy)是一组访问规则。用于定义角色对对象可以执行某种操作。例如策略：允许商务人员对文件"客户资料.xlsx"执行读操作，这里商务人员是一个角色，"客户资料.xlsx"是对象，读是操作。
3.2 工作原理
下图展示了基于RBAC访问控制机制下，主体（小明）访问对象的工作原理：
-
主体请求访问对象。
-
RBAC访问控制机制首先获取主体的角色，然后根据角色中的策略对该请求进行授权验证。
-
如果验证通过，则可以访问对象。
在现实世界的例子：
”我作为一名管理员，希望授权小明(商务人员)，读取文件“客户资料.xlsx”。
访问主体是“小明”，主体的角色是商务人员。
对象是 “客户资料.xlsx”。
实现方式
-
新建一个角色为“商务人员”。
-
假如角色的策略定义格式为：allow {角色} {对象} {操作}，则定义以下策略：
allow {商务人员} {客户资料.xlsx} {读取} -
设置“小明”的角色为“商务人员角色”。
在满足以上条件后，当“小明” 读取文件“客户资料.xlsx”时，RBAC访问控制机制就可以根据主体角色，使用管理员预先定义的策略(Policy)对这次访问进行验证，如果验证结果通过，就可以读取。对于其他新增商务人员的授权也只需要设置角色为“商务人员”即可访问商务人员对应的文件，如果有人员离职，也只需要将离职人员移除角色即可，这样就通过角色实现了人员和访问资源的解耦，提高了权限配置的效率。
3.2 数学描述
为了阐明概念，我们对RBAC给出⼀个简单的数学描述。这里的主体s指“用户”，例如"小明"。事务t是指操作+对象，例如：读取文件“客户资料.xlsx”。
主体s的活动角色，活动角色是主体当前正在使用的角色：
主体s的授权角色，每个主体可以授权多个角色：
每个⻆⾊都可以被授权执⾏⼀个或多个事务：
主体执⾏事务，当且仅当主体(if and only if)主体s可以在当前时间执⾏事务t ，函数exec(s,t)为真，否则为假：
三个基本原则
数学符号解释
∀ 任意，相当于every。当∀后面跟有以x为变量的公式时，写作(∀x)，读作“任意x”。例如，(∀a)a≥6表示所有的a都不小于6。
⇒ 推出，A⇒B意味着如果A为真，则B也为真；如果A为假，则对B没有任何影响。
≠ 不等于。
Ø[fai] 空集， 指不含任何元素的集合。
⊆ 包含于，表示一个集合中的元素全部是另一个集合里的元素。
-
⻆⾊分配：只有当主体选择或分配了⻆⾊时，主体才能执⾏事务。系统上的所有其他⽤⼾活动都是通过事务进⾏的，因此所有活跃⽤⼾都需要有⼀些活跃的⻆⾊。
公式解释：执行事务成功 only if 活动角色不为空。
-
⻆⾊授权：⼀个主体的活动⻆⾊一定是已授权的角色：
公式解释：活动角色是已授权角色的子集。
-
事务授权：只有当事务被授权为主体的活动⻆⾊时，主体才能执⾏该事务：
公式解释：执行事务成功 only if 事务包含已授权的活动角色。
对于 (1) 和 (2)确保⽤⼾只能执⾏他们被授权的事务。请注意，因为条件是“only if”，所以允许对事务执⾏施加额外限制的可能性。也就是说，不能仅仅因为它在TA(AR(s))中就保证事务是可执⾏的，TA(AR(s))是主体的活动⻆⾊可以执⾏的事务。例如，主管⻆⾊的实习⽣可能被分配“主管”⻆⾊，但对其⽤⼾⻆⾊施加了限制，将可访问的事务限制为主管⻆⾊通常允许的事务的⼦集。
-
强制控制⽤⼾必须通过某种验证函数访问对象的模式：
公式解释：执行事务成功 only if access(AR(s),f,o, x)
access(AR(s),f,o, x) 表示是否允许活动⻆⾊中的主体使⽤函数f对对象o执行x操作 ，其中x指某些模式集，例如：读r、写w、执行x。
例如，在医院环境中，使⽤这条策略可能是合适的。可以为医⽣提供对处⽅⽂件的读/写权限，⽽药剂师只有读权限。 （回想⼀下，单独使⽤前4个原则需要绑定事务中的f和o，并且只控制对事务的访问。） 使⽤ (4)可能有助于强制执⾏机密性要求。
RBAC 的另⼀个⽤途是⽀持完整性。完整性已以多种⽅式定义，但完整性的⼀个⽅⾯要求数据和流程只能由授权⽤⼾以授权⽅式进⾏修改。对于许多实际系统来说，这似乎是⼀个合理的安全⽬标，并且 RBAC 应该适⽤于此类系统。
通常，确定数据是否仅以授权⽅式修改的问题可能与进⾏修改的事务⼀样复杂。出于这个原 因，实际的⽅法是对事务进⾏认证和信任。如果必须信任事务，则可以将访问控制直接合并到每个事务中。
要求系统通过 (4) 中使⽤的访问函数来控制事务程序对对象的访问可能是⼀种有⽤的冗余形式，但它可能会涉及⼤量开销，从⽽在执⾏完整性要求时获得有限的好处。
因此，在 RBAC 中包含对对象访问控制功能的事务将在某些应⽤程序中有⽤。
3.2 与DAC比较
在多数企业中，员工通常并不拥有其允许访问文件的“所有权”，而是仅拥有基于自己的角色的文件的“访问控制权”。
DAC模型允许系统用户访问拥有权限的任意文件，并能够将其现有的访问权限直接(或者间接)传递给任何其他用户，而无需系统管理员干预，这是不安全的。
RBAC模型的系统⽤⼾不能⾃⾏决定将权限传递给其他⽤⼾，这是 RBAC 和 DAC 之间的根本区别。
3.3 使⽤ RBAC 集中管理安全性
RBAC 是灵活的，因为它可以在策略和结构⽅⾯具有组织特征。 RBAC 最⼤的优点之⼀是它⽀持的管理功能。
⼀旦⻆⾊的事务在系统中建⽴，这些事务往往会保持相对恒定或随时间缓慢变化。管理任务包括授予和 撤销系统内指定命名⻆⾊集的成员资格。
当新⼈进⼊组织时，管理员只需将成员资格授予现有⻆⾊。当⼀个⼈在组织内的职能发⽣变化时，可以 轻松删除其现有⻆⾊的⽤⼾成员资格并授予新⻆⾊。最后，当⼀个⼈离开组织时，所有⻆⾊的所有成员资格都将被删除。对于经历⼤量⼈员流动的组织，RBAC是唯⼀合乎逻辑的选择。
此外，⻆⾊可以由多个子⻆⾊组成。例如，医院里有 治疗师、实习生 和 医生⻆⾊。图2描述了这种关系的 ⼀个⽰例。
通过授予成员医⽣⻆⾊，这意味着可以访问实习⽣和治疗师定义的所有事务，以及医⽣的事务。通过授予成员实习⽣⻆⾊，意味着实习⽣和治疗师⽽不是医⽣的事务。但是，通过授予成员治疗师⻆⾊，则仅允许访问治疗师⻆⾊下允许的资源。
3.4 最⼩特权原则
最⼩特权原则已被描述为对于满⾜完整性⽬标很重要。最⼩权限原则要求⽤⼾获得的权限不超过执⾏⼯作所需的权限。确保最低权限需要确定⽤⼾的⼯作是什么，确定执⾏该⼯作所需的最低权限集，并将⽤⼾限制在具有这些权限的域中。
3.5 职责分离
系统管理员可以使⽤ RBAC 机制来执⾏职责分离策略。职责分离在阻⽌欺诈⽅⾯被认为是有 价值的，因为如果存在各种与⼯作相关的能⼒之间的协作机会，就会发⽣欺诈。职责分离要求对于特定的事务集，不允许单个个⼈执⾏该集中的所有事务。最常⽤的⽰例是启动⽀付和授权⽀付所需的单独事务。任何⼀个⼈都不应该能够同时执⾏这两项事务。
职责分离是实际系统中的⼀个重要考虑因素。在实际情况下，只有某些事务需要根据职责分离要求进⾏限制。例如，我们希望“授权⽀付”的事务受到限制，但“向管理员提交建议”的事务不会受到限制。
职责分离可以是静态的或动态的。可以简单地通过将个⼈分配给⻆⾊并将事务分配给⻆⾊来确定是否符合静态分离要求。更困难的情况是动态职责分离，只有在系统运⾏期间才能确定是否符合要求。动态职责分离背后的⽬标是在操作中提供更⼤的灵活性。考虑发起和授权付款的情况。静态策略可能要求任何可以作为⽀付发起⼈的个⼈也不能作为⽀付授权⼈。这可以通过确保执⾏发起者⻆⾊的⼈也可以执⾏授权者⻆⾊来实现。这样的策略对于商业⽤途来说可能过于僵化，使得安全成本⼤于没有安全的预期损失。
3.6 总结和结论
在⼯业界和⺠间政府的许多组织中，最终⽤⼾并不“拥有”他们被允许访问的信息。对于这些组织，公司或机 构是系统对象的实际“所有者”，DAC可能不合适。基于⻆⾊的访问控制 (RBAC) 是⼀种⾮⾃主访问控制机制，它允许并促进对组织特定安全策略的集中管理。
访问控制决策通常基于个⼈⽤⼾作为组织的⼀部分所承担的⻆⾊。⻆⾊指定⼀个⽤⼾或⼀组⽤⼾可以在组织的上下⽂中执⾏的⼀组事务。 RBAC 提供了⼀种命名和描述个⼈与权利之间关系的⽅法，提供了⼀种满⾜许多商业和⺠间政府组织的安全处理需求的⽅法。
已经描述了各种形式的基于⻆⾊的访问控制，其中⼀些在当今的商业系统中使⽤，但是没有普遍接受的 定义或包含 RBAC 的正式标准。因此，这些系统的评估和测试程序尚未像符合可信计算机安全评估标准 的系统那样建⽴。本⽂提出的 RBAC 的要求和访问控制策略可以作为基于⽤⼾⻆ ⾊的访问控制的通⽤定义的基础。