170 likes | 387 Views
安全策略约束之. 职责分离 SoD : Separation of duty. 鲁剑锋 2009 年 3 月 2 日 星期一. 内容. SoD 简介 SoD 分类 SoD 执行方法 研究展望. SoD 简介. The concept of SoD has long existed in the physical world, sometimes under the name “ the two-man rule ”, for example, in the banking industry and the military .
E N D
安全策略约束之 职责分离SoD:Separation of duty 鲁剑锋 2009年3月2日 星期一
内容 • SoD简介 • SoD分类 • SoD执行方法 • 研究展望
SoD简介 • The concept of SoD has long existed in the physical world, sometimes under the name “the two-man rule”, for example, in the banking industry and the military. • 1975: In the information security literature the notion of SoD first appeared in Saltzer and Schroeder under the name “separation-of privilege”. • 1992:In one of the earliest papers on RBAC, Ferraiolo and Kuhn used the terms static and dynamic SoD to refer to static and dynamic enforcement of SoD. • 1995:Ferraiolo et al. defined static SoD as: “A user is authorized as a member of a role only if that role is not mutually exclusive with any of the other roles for which the user already possesses membership.”
SoD简介 • ssoddefinition • smerdefinition
SoD简介 • The dangers with equating SMER constraints with SoD policies is • A danger with equating SMER constraints with SoD policies is that the SMER constraints may be specified without a clear specification of what objectives they are intended to meet; consequently, it is unclear whether the higher-level objectives are met by the constraints or not. • Another danger with equating SMER constraints with SoD policies is that even though when SMER constraints are specified there exist a clear understanding of what SoD policies are desired, when the assignment of permissions to roles changes, the SMER constraints may no longer be adequate for enforcing the desired SSoD policies. • Low level of access control granularity. (permission vs role)
SoD分类 • Static separation of duty typically constrains the assignment of users and permissions to roles. • Dynamic separation of duty typically constrains the activation of roles and invocation of permissions in the run-time environment. • Historical separation of duty typically constrains the invocation of permissions over the course of time
SoD分类->ssod • ssod分类(in RBAC) • User-based separation of duty • Role-based separation of duty • Permission-based separation of duty • Object-based separation of duty
SoD分类->ssod->user-based • 限定对象是UA,即限定角色与用户之间的指派关系。 • 最简单形式:< {u1,u2},{r1}>,r1不能同时指派给用户u1和u2. • 四种类型: • 一个user一个role: <{u1},{r1}> • 一个user多个role: <{u1},{r1,…,rn}> • 多个user一个role: <{u1 ,…,um},{r1}> • 多个user多个role: <{u1 ,…,um},{r1,…,rn},k> 一般抽象形式: smeu-r<{u1 ,…,um},{r1,…,rn},k> (1≤k ≤m, 1 ≤n) 表示任意{r1,…,rn}中的角色不能指派给{u1 ,…,um}中超过k个用户。 严厉抽象形式: smeu<{u1 ,…,um}, k> (1≤k ≤m)
SoD分类->ssod->role-based • 限定对象也是UA,即限定角色与用户之间的指派关系。 • 最简单形式:< {r1,r2},{u1}>,u1不能同时被赋予角色r1和r2. • 四种类型: • 一个role一个user : <{r1},{u1}> • 一个role多个user : <{r1},{u1,…,un}> • 多个role一个user: <{r1 ,…,rm},{u1}> • 多个role多个user: <{r1 ,…,rm},{u1,…,un},k> 一般抽象形式: smer-u<{r1,…,rm},{u1 ,…,un},k> (1≤k ≤m, 1 ≤n) 表示任意{u1,…,un}中的用户不能指派给{r1 ,…,rm}中超过k个角色。 严厉抽象形式: smer<{r1 ,…,rm}, k> (1≤k ≤m)
探讨:smeu与smer的关系 • smeu-r<{u1 ,…,um},{r1,…,rn},k> (1≤k ≤m, 1 ≤n) • smer-u<{r1,…,rm},{u1 ,…,un},k> (1≤k ≤m, 1 ≤n) • 情形1:UA({u1},{r1}) 1-1-1smeu-r等价于1-1-1smer-u • 情形2: UA({u1},{r1,…,rx}) x-1-ksmer-u包含于1-x-1smeu-r(k=0) • 情形3: UA({u1,…,ux},{r1}) x-1-ksmeu-r包含于1-x-1smer-u(k=0) • 情形4: UA({u1,…,ux},{r1,…,ry}) 非包含关系??? 结论:smeu-r与smer-u是两种不同类型的约束,尽管它们的约束对象均为UA。
SoD分类->ssod->permission-based • 限定对象是PA,即限定角色与权限之间的指派关系。 • 最简单形式:< {p1,p2},{r1}>,p1与p2不能同时指派给角色r1. 一般抽象形式: smep-r<{p1,…,pm},{r1 ,…,rn},k> (1≤k ≤m, 1 ≤n) 表示任意{u1,…,un}中的用户不能指派给{r1 ,…,rm}中超过k个角色。 严厉抽象形式: smep<{p1 ,…,pm}, k> (1≤k ≤m)
SoD分类->ssod->permission-based • 如果限定对象是User-Permission,即限定用户与权限之间的指派关系。 • 最简单形式:< {p1,p2},{u1}>,p1与p2不能同时指派给用户u1. 一般抽象形式: smep-u<{p1,…,pm},{u1 ,…,un},k> (1≤k ≤m, 1 ≤n) 表示任意{u1,…,un}中的用户不能指派给{r1 ,…,rm}中超过k个角色。 严厉抽象形式: smep<{p1 ,…,pm}, k> (1≤k ≤m) 在RBAC模型中,user通过role间接获取permission,故其限定对象应为PA而非UA(UA为最终目标)。
SoD分类->ssod->object-based • 保护对象为客体object。 • 类型1:限定object-user smeo-u<{o1 ,…,om},{u1,…,un},k> (1≤k ≤m, 1 ≤n) 任何来自{u1,…,un}中的用户不能访问超过k个来自 {o1 ,…,om}的客体。 • 类型2:限定object-role smeo-r<{o1 ,…,om},{r1,…,rn},k> (1≤k ≤m, 1 ≤n) 该约束比smeo-u弱,例如可以将o1,o2分别与r1,r2关联,但是r1,r2同时指派给u1 • 类型3:限定object-permission 同理,该约束比smeo-r更弱
SoD分类: dsod • dsod抽象目标 dsod<{p1,…,pm},k> (1≤k ≤m) 与ssod分类相似: • dmeu-r<{u1 ,…,um},{r1,…,rn},k> (1≤k ≤m, 1 ≤n) • dmer-u<{r1 ,…,rm},{u1,…,un},k> (1≤k ≤m, 1 ≤n) • dmep-r<{p1 ,…,pm},{r1,…,rn},k> (1≤k ≤m, 1 ≤n) • dmeo-u<{o1 ,…,om},{u1,…,un},k> (1≤k ≤m, 1 ≤n) • dmeo-r<{o1 ,…,om},{r1,…,rn},k> (1≤k ≤m, 1 ≤n) • dmeo-p<{o1 ,…,om},{p1,…,pn},k> (1≤k ≤m, 1 ≤n) • ssod是访问前预判,dsod是访问过程中判断。可以将ssod作为dsod的先决条件 ssod => dsod
SoD分类: hsod • 与具体的执行步骤有关:如order(订货)的用户必须得payment(结帐),但是不能goods(提货)和invoice(开发票)。 • Sandhu [1988, 1990] presented transaction control expressions, a history based mechanism for dynamically enforcing SoD policies. Nash and Poland
SoD执行方法 • 直接在用户-权限级别判断RBAC系统状态是否执行SSoD是NP完全问题 • 执行SMER是P问题 • ssod执行方法: • 设计先决条件,不满足先决条件的UA,RR(包括角色映射),PA关联将被撤销。 • 将SSoD从用户权限级别转换到用户角色级别 ssod->smer
研究展望 • ssod <{p1 ,…,pm}, k> (1≤k ≤m)是否能够完全满足静态职责分离要求? • smeu-r,smer-u,smep-u,smep-r,smeo-u,smeo-p,smeo-r均是P问题,是否可借鉴ssod->smer。 • 域间角色转换的通用ssod研究 • 各sod策略的内部关联关系和整合策略