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

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. 安全保护策略
  从上面各方面的需求分析来看,我们需要一套既行之有效,又方便灵活的安全管理方案。要采用各种控制机构和密码保护技术。安全保护策略是设计安全可靠系统的准则,通常涉及下列几个方面:

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

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

  由于实现了用户与访问权限的逻辑分离,基于角色的策略极大的方便了权限管理。例如,如果一个用户的职位发生变化,只要将用户当前的角色去掉,加入代表新职务或新任务的角色即可。研究表明,角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多,并且委派用户到角色不需要很多技术,可以由行政管理人员来执行,而配置权限到角色的工作比较复杂,需要一定的技术,可以由专门的技术人员来承担,但是不给他们委派用户的权限,这与现实中情况正好一致。除了方便权限管理之外,基于角色的访问控制方法还可以很好的地描述角色层次关系,实现最少权限原则和职责分离的原则。

  安全保护机构:本系统的安全保护机构基本上是于上面的安全策略相互适应的,系统保护的总体结构示意如下:
                20056132024431077802.gif
  保护机构应负责阻止一切物理破坏和用户可能的操作破坏,后者归结为主体可用何种方式访问哪些对象。主体、访问类型、对象是我们  要讨论的保护机构主要成分 
  安全管理的职责:安全管理有集中管理与分散管理两种。前者意指一切权利都由负责系统安全工作的专职人员或小组组掌握,他(们)决定用户的访问权利,控制系统安全一切方面。后者是指不同的管理员控制着系统安全的不同方面,管理系统的不同部分,决定不同用户的访问权利,甚至允许对象所有者转让访问对象的权利,集中管理,安全可靠但不灵活;分散管理则应考虑避免漏洞和协调一致的问题。本系统因是针对大的集团企业管理的产品权限分配比较复杂,故采用了集中管理与分散管理相结合的形式。 
  访问控制策略。它提供决定用户访问权利的依据。其中最重要的一个普遍的原则是"需者方知策略"(the need-to-know)。也就是说,只有一个工作需要的,才是他应该知道的。它从原则上限制了用户不必要的访问权利,从而堵截了许多破坏与泄露数据信息的途经。按照这一原则授予用户的权利,是用户能完成工作的最小权利集合,故也称之为"最少特权策略"。 
  信息流动控制。只限制用户的访问权利而不考虑数据流动是极其危险的。例如,在考勤时各部门的主管只能为自己部门的职员考勤,人事部可以提取全部数据,因此在提取数据时一定要加以限制。控制数据流动以防止无权用户在数据流动后获得访问权利。 
密码变换。对于非常机密数据可变换为密码存贮,使得不知道密码的入侵者无法破译所得到的数据密码。密码变换能防止泄密,但不能保护数据信息不被破坏。 
  软硬结合保护。这是安全保护的基本策略,许多硬保护功能是软件难以实现的,有些即使能实现,效率也不高。 
  对安全遭到破坏的响应。各种保护机构都有可能遭到破坏,因此系统必须制订检测破坏手段与处置措施。 
  3.2. 安全管理机构分析
  3.2.1. 功能框架示意图

  内部总体功能框架图
                   20056132024432077803.gif
  外调用的功能框架示意图
                       20056132024433077804.gif
  3.2.2. 主要功能组件的职责
   3.2.2.1. 对象定义工具与权限定义工具

  对象定义工具。
  对象是指系统中各种功能模块、数据、界面元素(包括菜单、按钮等各种界面上能控制的控件)等,它们是主体能访问的各种对象。由于对象的机密程度不等,受到的保护程度亦有差别。系统中的对象均由程序员通过系统提供的对象定义工具事先定义好系统要控制的对象。系统也只能控制这些事先已定义好的对象,因此,对象定义是整个系统的核心步骤直接影响后面的各个安全控制环节。建议由开发程序员进行初始化配置。对象定义的包括如下几步: 
  功能模块定义:系统中除部分公用的界面、公用功能模块外,其它均为业务功能模块是用户完成各自不同的业务功能的主要算途径,也是我们安全管理要保护的重点对象,所以我们必须对业务功能模块定义。有定义的功能模块对象我们就有可能组织权限根据用户需要完成的工作配置用户业务功能菜单,这也符合"最少特权策略"。 
  界面元素控制:除了功能菜单要受到控制外,如要控制功能模块的界面元素其功能模块界面元素也需定义,大部分界面元素均包含有相关的业务功能操作,所以对相应操作的界面元素是进行定义是有必要的。 
  数据信息控制:业务功能模块的大部分界面元素是显示和操作数据内容的基础,也是用户对读取数据和操作数据的主要途径,为了数据信息的安全有必要对这界面元素的操作数据予以采取安全保密措施。这就需要对这些界面元素定义相关的数据约束条件。 
  对象定义(流程) 流程图如下
                        20056132024434077805.gif
  权限定义工具。
  在定义好系统对象的前提下,定义对象的在不同情况的的访问类型,希望对象在不同情况下具有不同的访问类型,这就需要定义对象的权限。定义权限就是是定义对象访问控制和数据访问控制。为了表述方便我们对权限用一个三元组符号来表示P(o,t,p),其中o 表示访问对象;t 表示访问类型;p 表示谓词。表示在谓词p为真时对于对象o可进行t类型的访问。权限定义系统安全管理基础步骤之一,只有给各种对象定义好访问的权限,才能给角色配置权限,基于角色管理才能成为可能。系统提供定义权限工具,请程序员根据实际需求定义对象的权限。定义权限的流程图如下:
                           20056132024435077806.gif      
   3.2.2.2. 角色定义与权限配置

  角色定义。
  基于角色的访问控制方法的思想就是把对用户的授权分成两部份,用角色来充当用户行驶权限的中介。这样,用户与角色之间以及角色与权限之间就形成了两个多对多的关系。系统提供角色定义工具允许用户根据自己的需要(职权、职位以及分担的权利和责任)定义相应的角色。角色之间有相应继承的关系,当一个角色r1继承另一个角色r2时,r1就自动拥有了r2的访问权限(表示r1->r2)。角色继承关系自然的反映了一个组织内部权利和责任的关系,为方便权限管理提供了帮助。角色继承关系提供了对已有角色的扩充和分类的手段,使定义新的角色可以在已有角色的基础上进行,扩充就是通过增加父角色的权限去定义子角色,分类通过不同子角色继承同一父角色来体现。另外还允许多继承,即一个角色继承多个父角色,多继承体现对角色的综合能力。角色定义示流程图如下:
                          20056132024436077807.gif
  权限配置。
  角色是一组访问权限的集合,一个用户可以是很多角色的成员,一个角色也可以有很多个权限,而一个权限也可以重复配置于多个角色。权限配置工作是组织角色的权限的工作步骤之一,只有角色具有相应的权限后用户委派才能具有实际意义。权限配置流程图如下:
                         20056132024437077808.gif
   3.2.2.3. 用户、用户组定义

  用户定义。
  系统的最终使用者是用户,因此必须建立用户的鉴别机构,登记用户的身份信息。在系统中定义可登录的用户操作系统是系统安全管理所必须步骤,也是人与系统的接口。 
  用户组定义。
  为了本系统适用于分散式权限管理,加入了用户组的概念,是指一群用户的集合。方便权限管理用户组也可以委派角色,当用户被加入用户组时自动对用户的所在用户组拥有的角色进行了委派。为了便于分散式权限管理系统同时还支持对部分组的权限进行下发方式处理,授权特定的用户对用户组的用户权限进行管理。 
   3.2.2.4. 权限审查
  在授权完成后可检查登录用户所的拥有的能力表信息,审查给用户的权限是合适,如不合适可重新进行用户委派和收回部分权限的处理。目前系统只能以对用户组管理的模式对一个用户组内的用户可进行部分权限收回处理。

   3.2.2.5. 用户鉴别机构
  安全保护的首要问题是鉴别用户身份。目前有三种方法可用:第一、利用用户的物理特征(声波、指纹、相貌、签名)。这在理论是最可靠的,但由于物理特征可能随时间变化且记录尚欠成熟等原因,使该方法未能广泛应用。第二、利用用户特有的证件,如身份证、机器可读卡先考片,其缺点是证件可能被别人复制或冒用。第三、利用用户知道的某件能证明其身份的约定(如口令)。这是当前较为常用的方法。本系统采用第三种方法。

转载于:https://www.cnblogs.com/wskaihd/archive/2006/08/23/484748.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值