5483人阅读
1.&&&&&概念
访问控制技术是由美国国防部（Department of Defense, DoD）资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主访问控制（Discretionary Access Control, DAC）和强制访问控制（Mandatory Access Control, MAC）。最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。
自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授权和取消访问其控制之下的任何客体（object），换句话说，用户就是他们控制下的客体的拥有者。对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。
强制访问控制，在美国国防部&Trusted Computer Security Evaluation Criteria (TCSEC)&中定义如下：“一种限制访问客体的手段，它以包含在这些客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息（如清除）为基础”。
什么是基于角色访问控制（Role-Based Access Control, RBAC）？NIST&有如下定义。
访问是一种利用计算机资源去做某件事情的的能力，访问控制是一种手段，通过它这种能力在某些情况下被允许或者受限制（通常是通过物理上和基于系统的控制）。基于计算机的访问控制不仅可规定是“谁”或某个操作有权使用特定系统资源，而且也能规定被允许的访问类型。这些控制方式可在计算机系统或者外部设备中实现。
就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色（比如医生、护士、出纳、经理）。定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。
访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个医院系统中，医生角色可能包括进行诊断、开据处方、指示实验室化验等；而研究员的角色则被限制在收集用于研究的匿名临床信息工作上。
&&&&控制访问角色的运用可能是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。
2.&&&&&核心对象模型设计（RBAC0）
根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、控制对象（Resource Class）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：
1.&&&&&&&&控制对象：是系统所要保护的资源（Resource Class），可以被访问的对象。资源的定义需要注意以下两个问题：
a)&&&&&&&&资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。
b)&&&&&&&&这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑：
&&&&&&&&&&&&&&&&&&&&&&&&&i.&&&&&&&&&&&&&&一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。&例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。
&&&&&&&&&&&&&&&&&&&&&&&ii.&&&&&&&&&&&&&&另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。
2.&&&&&&&&操作（权限）：完成资源的类别和访问策略之间的绑定。
3.&&&&&&&&用户：权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。
4.&&&&&&&&用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。
5.&&&&&&&&角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。
6.&&&&&&&&分配角色权限PA：实现操作和角色之间的关联关系映射。
7.&&&&&&&&分配用户角色UA：实现用户和角色之间的关联关系映射。
3.&&&&&HR数据权限模型设计初稿
3.1.&&&访问主体
在本系统中访问主体是员工和用户组。
如图3.1.1中每个主体都有多个角色。每个角色又可能同时属于多个主体。
公司、部门、职位一定有对应的一个用户组，但用户组不一定是公司、部门、职位当中一个，也可能是虚拟出来的一个组，比如：工会组织、公司篮球队等等。
（图3.1.1）
3.2.&&&分配用户角色（Users Assignmen）
如图3.1.1这里的Users指的是所有访问主体。用户组、员工。
用户组是可以无限制扩充的。
无论添加几个主体到最后都会映射到角色（roles）表中，成为多个角色。
然后对角色分配访问权限控制。
3.3.&&&&&操作
操作（权限）=访问模式+资源（resource class）
如图3.3.1，比如：页面A有个查询员工信息的功能，我们在这里把他看成一个“访问客体”，被权限控制的资源（resource class）。再假设访问模式中有个“运行”模式，那么两者组合起来就是有个有效的操作（权限），然后把这个权限赋予角色，就OK了。
（图3.3.1）
3.4.&&&&&分配角色权限（Permission Assignment）
3.3节中提到，根据资源和访问模式、我们这里就有了很多操作，也就是权限。
那么我们只需要把这些权限分配到角色就可以了。如图3.4.1
（图3.4.1）
3.5.&&&&&资源类别（Resources Class）
根据以上的描述可以看出来，在本模型中主体是可以无限制扩充的。那么客体呢？我们可以看到，不管你有多少客体，到最后也都是分解成了多个资源类别（和主体一样，把每个主体都分解成了多个角色），然后和访问模式组成了操作（权限），最后赋给角色。
我们再分析下资源类别模型。
我认为我们系统的资源类别可以分为2个方向，页面功能和流程。
比如：员工资料查询，这个页面上就有查询这个客体资源类别。
而员工转正流程中又有直接主管审批这个资源。
那么我们把资源类别（resources class）设计成如图3.5.1
（图3.5.1）
功能模块表中存放“流程”或“页面功能”。
“功能模块类别”用来区分，这条记录是“页面功能”还是“流程”。
一个流程有多个审批操作。我们可以放到资源类别中。
页面功能同理。
4.&&&&&小结
该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。如表4.1
查看自己部门员工通讯录
查看自己部门员工全部资料
查看自己公司员工通讯录
查看自己公司员工全部资料
档案管理员
图4.1为整个权限模型。
5.&&&&&思考
5.1.&&&相对角色
在很多时候我们都会用到相对角色这个概念。比如：员工转正流程中就有个直接主管审批，那么这个直接主管这个角色就是一个相对角色。这个相对角色在数据库权限模型中其实也是一个角色，只用添加到角色表中给这个角色赋权限（操作）就可以了，但在开发过程中一定要注意相对角色的设定，特别是设定方法，公式。
5.2.&&&用户组的联想
用户组可以是组织架构中的实体单位。同时也可以是虚拟的，由用户自己添加、配置的一个角色的集合。角色又是权限的集合。
那么我们可以这么做，添加一个系统管理员组，然后通过角色为这个组，分配好应有的权限。以后如果有新的系统管理员，我们只需要放到这个组里面去就可以，没必要再重新配置一个用户。
这样就完全可以实现windows的权限管理了。
5.3.&&&角色的继承
给角色分配权限（操作）其实也是件比较复杂的工作。如果角色间存在一定的关系，可以直接把另外一个角色的权限直接复制过来，然后再添加自己需要的其他权限，这样不是会方便很多吗？
继承可分为两种方式，一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系（不能继承自己的子类），允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构（单继承）。
5.4.&&&资源实例（Resource Instance）
场景1：有一个功能页面，查询员工资料。可访问角色有“人事专员”和“部门经理”。“人事专员”进入可以查出全公司的所有员工资料。“部门经理”进入后，只能查出自己部门的员工资料。
场景1的解决方案：
1.&&&&&&&&在功能模块（functionmodule）表中添加“查询员工资料”这个功能。
2.&&&&&&&&在功能资源（functionresource）表中添加这个“查询员工资料”的两个资源，“部门经理查询”和“人事专员查询”。
3.&&&&&&&&抽象成资源类别（resourcesclass）。
4.&&&&&&&&资源类别（resourcesclass）和访问模式（accessmode）组合成2个操作（权限）。
5.&&&&&&&&把这两个权限分别赋予部门经理组所拥有的角色和人事专员组所拥有的角色。
6.&&&&&&&&在开发过程中就可以根据两个不同的资源，在这个页面做查询条件的处理。
场景2：有一个功能页面，部门花名册。可访问角色有“部门经理”和任何登录后的员工。根据员工部门自动显示所在部门的花名册。如果是“部门经理”，就显示一些“部门经理”可以看到的敏感信息。比如，工资。
场景2的解决方案：
1.&&&&&&&&在功能模块（functionmodule）表中添加“部门花名册”这个功能。
2.&&&&&&&&在功能资源（functionresource）表中添加这个“部门花名册”的一个资源，“部门经理花名册”。
3.&&&&&&&&抽象成资源类别（resourcesclass）。
4.&&&&&&&&资源类别（resourcesclass）和访问模式（accessmode）组合成1个操作（权限）。
5.&&&&&&&&把这个权限赋予部门经理组所拥有的角色。
6.&&&&&&&&在开发过程中进入这个功能页面，没有这个权限的显示一般花名册。有这个权限的显示部门经理花名册。
资源实例让我们在按钮级权限的基础上，加上了对记录和字段的控制。当然，你也可以把场景1和场景2结合起来。记录、字段一起控制，这个肯定是可以的。
再扩展下。场景二中，如果有一天部门经理所能看到的东西改变了，加一项或少一项，怎么办呢？难道去改代码？
其实在很多情况下，都是可以做死的。比如场景二中大家都只能看到自己部门的花名册。肯定不会有一天要看公司的花名册，如果真有这个需求，那么就应该再做个功能页面。叫做“公司花名册”。
但也有些情况，是要可以调整的。同样是场景二，部门经理能看到的东西。哪天公司想变变，这个也是有可能的。
其实这个功能实现起来也非常简单。如图5.4.1。
无论什么，到最后都会变成资源类别，我们直接给这个类别记录一些属性。到时候你只要根据这些属性显示就可以了，要变的时候把这些属性变了就行了。只要愿意，完全可以做个维护页面。
表资源设置（resourcesetting）记录一些访问条件。比如，这个资源按部门查询。如果需要你可以把他改成按公司查询。
表字段设置（fieldsetting）记录的是这个资源的字段信息。比如，部门经理可以看到“部门花名册”的字段。
（图5.4.1）
6.&&&&&总结
本模型的主要设计思想是把所有访问主体，包括部门、职位、公司、人等等。全部分解成一个或多个角色。
把所有访问控制客体全部分解成一个和多个资源类别（Resources Class）。
把资源类别加上访问模式（读、写、删、运行等）成为一个操作，也就是权限。
然后把这个权限赋予到角色。
这个模型支持页面级权限、按钮级权限、记录级权限、字段级权限和这几种权限的任意组合。
在角色的分配上。他本身是支持一个客体有多个角色，一个角色属于多个客体。支持用户组角色、角色继承、相对角色等。特别是用户组这个设计。部门、职位、公司这些组织都可以抽象成一个用户组，直接给这个组分配权限就可以了。但用户组不仅仅只有抽象实体组织这功能，他还可以无限制的扩展。比如可以添加一个虚拟的系统管理员组。他本身就是一个员工的集合，你可以以任何形式去组合人员。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：215539次
积分：2522
积分：2522
排名：第11421名
原创：52篇
转载：65篇
评论：25条
(4)(4)(1)(2)(1)(2)(6)(13)(1)(1)(1)(1)(1)(3)(1)(3)(1)(2)(4)(6)(1)(3)(2)(4)(8)(2)(5)(3)(2)(2)(3)(4)(7)(5)(5)(3)您现在的位置：常见问题&&&频道功能&&&公会管理 &&&问题内容
如何单独设置频道管理权限？
OW或VP打开公会管理，点击左侧权限管理，然后选择要设置权限的成员身份、具体人员。选择后，点击要设置权限的房间后面的编辑图标开始设置（如图）。勾选要赋予给该人员的哪些权限，然后保存就设置成功了。&
其他相关问题权限控制管理在企业环境中是非常重要的安全问题，企业中的权限控制意味着控制用户对系统资源的读写权限，限制对关键资源的访问，防止非法用户的入侵或者不合法用户的不慎操作所造成的破坏。目前国内外的权限管理体系有如下几种：
（1） Discretionary Access Control (DAC)自主访问控制方案：在这个方案里，用户给予访问资源的权限，目标资源根据用户的权限属性来判断他是否有权限执行请求的操作。在该模型中，同一用户对不同的资源对象有不同权限；不同的用户对用一资源对象有不同的权限；用户能自主地将自己拥有的权限授予其他用户。
缺点：由于DAC模型可以任意传递权限，用户能间接获得本不具有的访问权限，因此DAC模型的安全性较低，不能给系统充分的数据保护。
（2）Mandatory Access Control(MAC)强制访问控制方案：广泛用于军事系统的授权方案，在MAC方案中，每个目标由安全标签分级，分级列表指定哪种类型的分级目标对象是可以访问的。访问时，系统先对用户的访问许可级别和资源对象的密级进行比较，再决定用户是否可以访问资源对象。用户不能改变自身和资源对象的安全级别，只有系统管理员或管理程序才能控制资源对象和用户的级别。
优点：用户权限的层次结构良好，存取控制相当严格
缺点：灵活性比较差
（3）Role-Based Access Control(RBAC)基于角色的访问控制方案：在简单的RBAC模型中，定义了大量的角色。通常，他们代表组织中的某种角色，每个角色都给予一组权限，也就是在一定目标上执行一定的操作。每当访问一个目标的时候，用户持有他的角色和目标读取策略判断这个角色是否可以执行操作。
从企业的角度实现管理访问控制信息的研究包括了建立和更新RBAC的信息、设定角色、构建RH
（Role Hierarchy）、URA（User-Role Assignment）和PRA（Permission-Role Assignment），通过判断用户的访问权限允许或者阻止用户访问公司的信息，访问权限与分配给用户的合适的角色相关。一般的RBAC模型如下图所示：
优点：易于理解、方便管理、责任分散和权限继承等
1）这些访问控制模型都是从系统的角度出发保护资源，这样的控制原理没有将操作所处的环境考虑在内，是被动的安全模型，不能记录主体对客体权限的使用。
2）在角色继承方面，支持角色的全部继承，使得复杂系统中角色粒度小、角色分配复杂、角色很难与实际的岗位职责相对应。
3）在模型动态性方面，不包含角色时间约束，使得模型很难适应随实际动态变化的需求。
4）在权限控制算法方面，大型企业中角色众多，系统中用户角色的分配工作往往由管理员一人承担，这必然造成权限控制的实现算法复杂、管理员负担重、用户角色的变更不够灵活。
&（4）Task Based Access Control（TBAC）基于任务的访问控制方案：
DAC、MAC和RBAC模型关注系统的静态权限控制，从系统的角度（控制环境是静态的）出发保护资源。其授权一般用三元组（S、O、P）表示，其中S表示主体，O表示客体，P表示许可。如果存在元组（S、O、P），则表明S可再O上执行P/许可。否则，S对O无任何操作许可。三元组均预先定义，并静态地存放在系统中，且始终有效。它们是被动安全模型，不能记录主体对客体权限的使用，权限没有时间限制。这类模型不能满足时间应用中随实际变化的动态权限需求，容易造成安全隐患。
TBAC模型从应用出发，基于工作流建模。工作流是为完成某一目标而由多个相关人物（活动）构成的业务流程。数据在工作中流动时，执行操作的用户改变，用户的权限也改变。
TBAC模型的授权一般用五元组（S、O、P、L、AS）来表示，其中S、O、P的意义同上，L表示生命周期，AS表示授权步。P是授权步AS所激活的权限，而L则是授权步AS的存活期限。在授权步AS被触发时，其委托执行者开始拥有执行者许可集中的权限，同时其L开始倒计时。在生命期中，五元组有效。当生命期终止，既授权步AS被定为无效时，五元组无效，委托执行者所拥有的权限被回收。
优点：根据任务和任务状态的不同，对权限进行动态管理，资源对象的访问权限随着执行任务的上下文环境发生变化。
缺点：管理系统中角色是一个非常重要的概念，TBAC模型不支持角色的层次等级。
（5）Task-Role Based Access Control (T-RBAC)基于任务和角色的访问控制方案：
如前所述，RBAC模型未将任务从角色众抽离，缺乏动态性，无法操控任务的前后权责和时间。TBAC模型忽略角色，不能体现组织结构和职权关系。
在大型企业系统中通常有着大量的角色、用户和信息资源，管理这些角色、用户、信息资源和它们之间的相互关系对于安全管理员来说是非常困难的。现在的企业，特别是IT企业，用户通常是围绕一个项目进行任务分配，一旦项目结束，任务也告结束，在新的项目中重新分配权限给新的任务，这就要保证模型有动态授权的功能。
T-RBAC是一种新的访问控制模型，是从基于任务的角度来实现访问控制的，从任务的角度来建立安全模型和实现安全机制，在任务处理的过程中提供动态实时的安全管理。
在这个模型中，权限分配给任务，任务再分配给角色，因为任务是商务活动的最小单位。
一般的T-RBAC模型如下图所示：
&主要思想：根据企业的层次结构和职权抽象角色，由系统管理员或管理程序关联用户与角色。从角色出发统一调度，分析企业活动中的工作流。对于与工作流无关的静态权限，利用图形化工具将资源对象授予角色，支持角色的全部和部分继承。针对动态权限，则采用工作流引擎将任务推送给角色。
优点：（1）实现动态访问控制
&& & &&（2）简化授权管理
&& & &&（3）支持权限的全继承和部分继承，同时支持被动和主动的访问控制。
&& & &&（4）通过管理程序，它实现了大量用户和访问客体角色的分配。
&& & &&（5）能完成静态权限和动态权限的分配
RBAC与T-RBAC之间的比较：
（1） T-RBAC中访问权限分配给任务，而RBAC中将访问权限分配给角色。
&&&&& 因为在现实的企业环境中，用户需要有权限执行任务，因此分配访问权限给任务是可行的，只有在执行任务时访问权限被绑定和激活。
（2） 在T-RBAC模型中，权限分配给相关的任务，任务分配给相关的角色，因此T-RBAC中的PTA和TRA就相当于T-RBAC中PRA。T-RBAC模型中的管理员就比较容易知道相对于特定任务的信息对象。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：34067次
排名：千里之外
转载：78篇
(11)(6)(3)(6)(24)(33)管理权限模型设计_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
管理权限模型设计
上传于||文档简介
&&管​理​权​限​模​型​设​计
大小：19.00KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢