基于角色管理的系统访问控制

答案：1. 引言（Introduction）
 
1.1. 关键词定义（Definitions）
有关定义说明如下：

安全管理：计算机技术安全管理的范围很广，可以包括网络安全性、数据安全性、操作系统安全性以及应用程序安全性等。很多方面的安全性管理大都已经有成熟的产品了，我们只需根据自己需要有选择性的使用就可达到自己的目的了。本文中有关关涉及"安全管理"一词均只针对本公司推出的应用中有关对象与数据而言范围有限。

主体：即可以象应用系统发出应用请求任何实体，包括各种用户、其它与本系统有接口的应用程序、非法入侵者。系统必须具有识别主体的能力，接口实际上也是由用户登记的，故主要问题是校验用户身份的合法性，系统应建立用户鉴别机构以验证用户身份。

用户：用户就是一个可以独立访问计算机系统中的数据或者用数据表示的其它资源的主体，我们用USERS表示一个用户集合。用户在一般情况下是指人。

权限：权限是对计算机系统中的数据或者用数据表示的其它资源进行访问的许可。我们用PERMISSION表示一个权限集合。可分为对象访问控制和数据访问控制两种。

对象访问控制：用一个二元组来表示：（控制对象，访问类型）。其中的控制对象表示系统中一切需要进行访问控制的资源。我们将引入一套完整的资源表示方法来对系统中出现的各类资源进行定义和引用（详见后述）。访问类型是指对于相应的受控对象的访问控制，如：读取、修改、删除等等。

数据访问控制：如果不对数据访问加以控制，系统的安全性是得不到保证的，容易发生数据泄密事件。所以在权限中必须对对象可访问的数据进行按不同的等级给予加密保护。我们同样用一个二元组来表示：（控制对象，谓词）。

权限最终可以组合成如下形式：（控制对象，访问类型，谓词）。

角色：角色是指一个组织或任务中的工作或位置，它代表了一种资格、权利和责任。我们用ROLES表示一个角色集合。

用户委派：用户委派是USERS与ROLES之间的一个二元关系，我们用（u,r）来表示用户u被委派了一个角色r。

权限配置：权限配置是ROLES与PERMISSION之间的一个二元关系，我们用（r,p）来表示角色r拥有一个权限p。

2. 需求分析
根据我们在本行业多年积累下来的经验，参考了其它同行的成功经验整合了先进的思想，我们有能力为我们自己的应用系统开发一套功能完善而且又灵活方便的安全管理系统。使开发人员从权限管理重复劳动的负担中解放出来,专心致力于应用程序的功能上的开发。通过收集公司从事MIS项目开发经验丰富的软件工程师对在各种情况下的对应系统的安性提出的需求做出了如下的总结。

本系统在安全管理方面要考虑如下几个方面问题。

2.1. 角色与用户
需求：角色由用户(这个用户与下一行的"用户"应该不是同一个定义,"客户"好像合适一些?不错，此处的用户确是有些偏于指向我们合同意义的客户,但是我认为与下面定义的"用户"不存在什么本质上的区别,因为客户最终也是以在系统中登记的用户身份来使用本系统，用户所能完成的功能也就是客户的需求。两者之间的细微区别读者可自己通过上下文加区分)自行定义，根据业务岗位不同可以定义多个角色。

登录系统，首先需要向系统申请注册，同一个用户只能在系统中登记一次。

用户是登录系统的楔子，角色是用户权限的基础。用户可以扮演多个角色。

将某一角色授予某一用户时，权限不能超越该角色权限，但可以小于该角色权限。

用户口令与数据库访问口令加密

分析说明



每个用户在系统中由一个唯的USERID标识。 

用户通过系统登录界面登录系统,系统通过加密算法验证用户身份和判断用户是否已经登录系统。如果登录成功通知Application preference service和安全管理系统保存用户登录信息。 

角色由用户根据自己的设想的组织机构进行添加设置，提供一个专门的模块用来设置组织机构，用户通过组织机构(定义?部门机构还是后面提到的"机构是实现和执行各种策略的功能的集合")方便地进行角色管理。例如：用户可以通过部门机构来进行角色的管理，部门采用编号分层的方式,编号的每两位为一个层次。例如一级部门编号为两位，二级部门编号为四位依此类推下去直到将全厂部门机构建立树状结构图。这类数据仅为方便用户管理角色而存在，在系统的其他方面不存在任何意义。 

每个角色在系统中也是由一个唯一角色编号来标识，同时必须保存用户所设置的机构信息，一般来说每个角色只需要保存自己所在机构的代码即可。 
2.2. 菜单控制需求此菜单乃系统业务功能菜单。由业务功能模块列表和用户菜单定制共同组成。每个用户可以拥有自己的菜单，也可以直接采用角色缺省菜单（当用户同时充当多个角色并且权限重复时，重复的权限仅一次有效）

分析说明



为了方便用户进行权限组织管理，需要在系统中建立一张业务功能模块列表，在用户界面上表示为树状分层结构。 

业务功能模块以用户定制菜单来体现，仍然采用编号分层方式，编号的每两位为一个层次。并标明一个层次是子菜单还是业务模块，子菜单只有一种可否被访问的权限设置，业务模块权限由系统管理员或授权用户进行设置。对每个业务模块设置它的对象控制、记录增删改控制和记录集控制。当用户拥有对业务模块的某一权限时，必需对处于它上级的子菜单有可被访问的权限。删除某一个级子菜单时将提示用户他的下级菜单与功能模块都将被删除掉。 

当用户同时充当多个角色并且权限重复时，重复的权限仅一次有效，用户拥有他充当的所有角色的权限的并集。 

用户与角色拥有的系统权限查询时以业务功能模块列表的树状结构显示出来。 


2.3. 对象控制
需求对象是指应用系统窗口中的可视对象，如菜单项、按钮、下拉列表框、数据编辑控件及数据编辑控件的字段等。对象控制通过角色与用户授权来实现。

对象控制包括对对象属性的控制可对数据编辑控件中的数据记录的维护权限：



对象属性：使能/禁止、可视/屏蔽 

记录维护：增加、删除、修改的组合 
分析说明



将每个业务模块可进行属性设置的对象由程序员事先设定或由售后技术支持工程师指导用户加入。 

在系统管理员或授权用户进行设置业务模块的每种权限时，设置用户在拥有该业务模块这种权限时的对象属性。没有设置属性的对象在保存对象信息的时候，用户权限信息中不被保存。 
2.4. 记录集控制
需求记录集的控制是通过条件设置来实现，因此，需要控制记录集的数据库表需要设置专门的记录集筛选字段，而筛选条件由用户根据岗位自进定义，建立过滤表，统一管理。

分析说明



在对用户设置业务模块权限时，同时在过滤表中设置本模块的数据编辑控件的数据筛选条件，筛选条件是组成SQL语句的WHERE条件子句迫使当前访问的模块根据筛选条件对数据编辑控件的SQL语句进行重组，并检索数据。 

当存在需要从数据库中多个表取数据的情况时，过滤表中存在多条记录，每一条记录记录一个数据编辑控件取数的筛选条件。 

SQL语句的WHERE子句的生成与校验可以通过的SQL语法分析服务，利用对象所提供的函数分析SQL语句，截取WHERE条件子句，校验新组合的SQL语句的合法性。 


2.5. 权限分布管理
需求上述提到的权限管理内容应该满足既可集中管理，也可分散管理的目标。

分析说明



权限管理由系统管理员集中管理，系统管理员工作负担过大，难对所有岗位的分工有全面和具体的了解，对权限作出标准细致的划分，对于大型的管理系统适合于把一部分设置权限的交由一些比较高级的用户来进行，有利于各岗位细致协调的工作。这就是权限的分散管理。 

要实现权限的分散管理，就须对授权模块进行一些授权管理，这要求整个系统的授权安全管理工作要做到细致，不要出现权限的漏洞使一些高级用户拥有过大的权限。 
3. 方案设计
3.1. 安全保护策略
从上面各方面的需求分析来看，我们需要一套既行之有效，又方便灵活的安全管理方案。要采用各种控制机构和密码保护技术。安全保护策略是设计安全可靠系统的准则，通常涉及下列几个方面：



区分安全策略与安全机构。 

策略是信息安全性的高级指导，策略出自对用户要求，设备环境、机构规则、法律约束等方面的详细研究。策略重要性在于指导作用。而机构是实现和执行各种策略的功能的集合。完善的机构是实施正确安全策略的物质基础。故一般要求机构能实现不同的策略，以便策略变动时无需要更换安全机构。

安全策略：企业信息管理系统是一个大型的分布式数据资源管理系统，它包括信息量巨大以及不同程度的信息敏感度，各种有访问需求的用户，使得其安全管理非常复杂。基于角色的系统安全控制模型是目前国际上流行的先进的安全管理控制方法。我们的安全管理系统也根据自身的需要有选择性的吸收其部分思想。其特点是通过分配和取消角色来完成用户权限的授予和取消，并且提供了角色分配规则和操作检查规则。安全管理人员根据需要定义各种角色，并设置合适的访问权限，而用户根据其责任和资历再被指派为不同的角色。这样，整个访问控制过程就分成两个部分，即访问权限与角色相关联，角色再与用户关联，从而实现了用户与访问权限的逻辑分离，如下图所示，角色可以看成是一个表达访问控控制策略的语义结构，它可以表示承担特定工作的资格。





由于实现了用户与访问权限的逻辑分离，基于角色的策略极大的方便了权限管理。例如，如果一个用户的职位发生变化，只要将用户当前的角色去掉，加入代表新职务或新任务的角色即可。研究表明，角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，并且委派用户到角色不需要很多技术，可以由行政管理人员来执行，而配置权限到角

上一个：摘IIS 6 常见问题解答
下一个：在Windows 2003下面使用调试ASP程序的常见错误以及解决方案（一）