用户权限管理

用户权限管理（精选9篇）

用户权限管理 篇1

在现有的大多数业务软件管理系统中, 用户权限管理是其中最基本的模块之一, 它可以隔离不同业务级别的用户群体, 从而实现并联工作, 责任分明, 互不干扰。为了提高开发效率方便移植, 开发人员对通用模块都有一个较为固定的功能模式, 通过多年的实际开发, 对该模块提出了较为实用的设计思路, 它在满足基本用户信息管理的同时, 还能以组管理的模式对用户权限进行动态调整, 在系统资源与权限的有效关联上也提出了自己的设计方法。代码实现以Delphi为开发环境, 工作于windows平台之上, 数据库以SQL Server为例[1]。

1 总体思路

用户权限管理是由用户、组、用户与组的关系、资源、组资源权限关系这五个对象关联而成。组中包含用户, 因此权限的分配则是以组为对象与系统资源进行实际关联 (如图) 。所有功能的实现都将围绕这五个对象来进行。

2 数据库设计

数据库的设计是模块化设计的关键, 库中包含五个表分别对应上述五个对象。

2.1 用户。用户是系统使用人员, 它可以根据具体的软件系统来扩充其对应的属性。

2.2 组。

组是指具有相同业务级别的群体, 比如超市的POS收银人员、财务人员。我们可以设置好一个组后, 将用户简单的加入或者移除即可。所有的权限操作只针对组, 这样就省去了相同级别人员的重复权限设置。

2.3 用户与组关系。

用户与组是多对多的关系, 权限上则是使用最大化为原则, 如果一个用户分属不同组的权限, 则其权限是这两个权限的累加。

2.4 资源。

对用户权限的设置也就是对访问资源方式的设置。大多数资源是指窗口、菜单, 在delphi中, 比较好的可控对象是TAction, 它有一个资源标识Tag属性, 只需要将资源的Tag记录下来就可以加以识别。

2.5 组资源权限关系。

组与资源的权限关系 (组权限) 分为可用、不可用、隐藏三种, 在表数据中可以用11、01、00来标识。

3 具体实现

实现上主要分为以下几个环节:资源管理、人员管理、组管理、组权限分配以及按照指定好的组资源权限关系执行权限分配。

3.1 资源管理。

对于需要管理的资源, 它的资源标识在软件设计时应区分开来, 资源管理大多数在软件分发前就已经完成。

3.2 人员管理、组管理、人员入组。

这些只需要简单的应用Insert into、Delete、Update三个SQL标准语句来增加、删除、修改即可[2]。组删除的时候要在一个事务中同时删除所属的用户和对应的组权限。

3.3 组权限分配。

组的权限分配操作会大量使用Update语句。增加一个新组后, 随即就应该将d Sysres中每个资源与组的默认权限Insert into到表Jaccess中。

3.4 权限分配的执行。

这是一个比较重要并且较为复杂的环节, 它发生在合法用户成功登录以后。具体实现是循环访系统的每一个资源, 并在组end;权限表里寻找其对应权限, 然后Disable, Enable, Invisible该资源, 主要代码片断如下:

//通过在Actioni List中循环访问每一个Action, 然后在查找用户的权限[3]

当然, 在设计出一个好的用户权限管理模块时, 需要特别注意的是用户权限设计还应该与应用系统的需求结合起来, 比如有的系统需要用户有分级授权的能力, 那么系统就需要在本模块之上再作进一步的扩展升级。

摘要：用户权限动态管理实际上是对用户、组、资源以及权限控制这几个对象进行有序控制, 并嵌入具体业务系统最终实现安全有效的资源访问, 因此模块化的设计思想是实现用户权限管理的有效途径。

关键词：用户,权限,动态管理,Delphi

参考文献

[1]Bill Todd.如何选用数据库[A].国际技术期刊合集编委会.Delphi lnformant2002-2003中文精华合集 (第一辑) [C].北京:电子工业出版社, 2004:186.

[2]方盈.SQL Server7.0从入门到精通[M].北京:中国铁道出版社, 1999:270-273.

[3]陈省.Delphi深度探索[M].第二版.北京:电子工业出版社, 2004:286.

用户权限管理 篇2

1.命令权限

Create Database

Create Table

Create View

Create Procedure

Create Rule

Create default

命令权限授权与收权：

Grant 命令权限组合 to 组名|用户名|角色

Revoke 命令权限组合 from 组名|用户名|角色

2.对象权限

Select

Update

Insert

Delete

Reference

Execute

对象权限授权与收权：

Grant 对象权限组合 on 数据库对象 to public|组名|用户名|角色

[With Grant Option]

Revoke 对象权限组合 on 数据库对象 to public|组名|用户名|角色

From public public|组名|用户名|角色

[Cascade]

授权与收权举例：

◇Grant Insert,Delete on Employee

to user_1,Group_1

◇Grant Execute on Pro_culculate

to public

◇Grant Select on Employee(emp_id,emp_name)

to user_3

◇Grant All on Employee

to user_4

◇Revoke update on Employee(emp_id,emp_name)

from user_5

◇Revoke Create Table,Create Rule

用户权限管理 篇3

Android操作系统的安全机制:

Android系统由于基本采用的是Linux内核, 因此它继承Linux系统基本的安全机制1 - 2, 如采用用户和用户组进行对文件的访问权限的控制等。同时, Android还有其自身的安全机制设计。

应用沙箱机制

应用沙箱是Android系统安全的基础, 每个应用程序都会被授予一个唯一的用户标识 (UID) , 通过这个用户标识来访问属于其自身的资源。每个应用在安装时都会让用户来选择通过该应用的所能拥有的权限, 如读取联系人信息、访问摄像头、访问网络等等。

签名机制

安装到Android系统中每一个应用都会有一个数字证书, 该数字证书用来对应用程序的唯一完整性进行认证。数字证书一般采用非对称加密算法, 私钥掌握在应用程序的开发者手中。

组件封装

Android系统中的应用程序一般有活动、服务、内容提供和广播接收四个类型的组件, 每个组件都可以设定公开或者私有属性来控制访问权限。其中, 公开组件是可以被其他应用访问的。

Android安全机制不足

Android系统虽然具有上文所述的安全机制, 但依然存在着不足和缺陷, 沙箱机制无法防范那些通过漏洞获得特权的应用, 组件封装机制则可以通过应用间的代理绕过, 签名机制没有统一的颁发机构, 比较容易伪造。此外, 应用间通信的权限提升问题也是一个比较明显的安全问题。

用户可视化权限管理监控

用户可视化权限管理是通过收集系统中各个应用程序所拥有的权限列表, 然后可视化的呈现给用户, 然后定义一些危险权限集合, 如读取联系人权限和访问网络权限组合为危险权限组合。在进程组件交互时判定是否存在危险权限集合, 如果存在则预警用户, 同时将访问记录、如组件名称、时间、权限等信息记录在可视化管理权限日志中, 方便用户查询。

应用程序权限列表

Android系统中每个应用程序都有它自身的应用权限集合, 获得每个应用的权限列表主要是通过Package Manager对象来实现, 首先通过get Package Info方法获得包名信息, 然后再通过应用包名信息对象Package Info中requested Permissions方法来获得该应用的权限列表。

危险权限集合定义

危险权限集合主要是指那些有可能让用户个人信息隐私和关键信息泄露的操作权限。比如, 读取联系人信息权限和访问网络权限等。这些危险权限集合的定义是后续判定预警用户的基础。

预警判定

危险权限的判定主要涉及到Android权限提升攻击的问题, 所谓权限提升是指一个应用并不具备某一个权限, 但通过另外一个应用的访问来获得该权限的访问权。如图1 所示。

如图1, 假设应用A拥有访问网络的权限, 却没有读取用户联系人信息的权限。应用B具有读取用户联系人信息的权限。此外, 应用A还拥有应用B组件接口的权限, 而这个接口组件恰好能访问到联系人信息, 这样的话应用A便能通过应用B的组件接口来获得联系人的信息, 再通过自身所拥有的访问网络的权限将用户联系人信息泄露, 这便是一个Android系统中权限提升的例子。

为了防止权限提升的问题, 及时预警用户, 采用危险权限集合在应用间进程交互时对这类型的隐私易泄露的危险情况做出及时处理。预警判定时机如图2 所示。

预警用户与记录信息

当预定判定进程间交互式存在危险权限集合时则通过对话框的形式来预警用户, 并应用进程的信息、权限信息和当前时间记录在权限管理日志中方便用户查询。

结语

Android系统安全问题是极为重要的问题, 用户对Android安全问题应该得到提升。本文提出可视化的用户权限管理监控方案能使用户提高安全意识和对安全问题做出更好的管理操作。

公司信息化系统用户权限管理制度 篇4

网络资源管理制度

第一章 总 则

第一条 为了规范公司信息化系统的权限及电脑网络资源的管理工作，明确系统用户权限的管理职责，结合公司实际情况，特制定本制度。

第二条 本办法相关名词解释

信息化系统:是指公司支撑系统，人力资源系统、餐厅系统、会员管理系统、OA系统、等相关IT运行管理系统。

电脑及网络资源：是指公司所有属于信息系统类的相关设备，如：办公电脑、打印机、服务器、网络交换机等。

权限：是指在信息化系统中用户所能够执行的操作及访问的数据。

第三条 本制度的适用范围为公司部门、子公司。其相关的权限变更，或资产调拨按照集团公司申请流程提报。

第二章 管理职责与分工

第四条 信息化系统用户权限、办公电脑及网络资源的归口管理部门，主要负责各系统内用户权限、的命名、审批、上报、配置、监控、删除、通知和培训等管理工作。负责电脑及网络设备的统一调配、维护及管理。

第五条 各相关部门、子公司仅能在自己的授权范围内

进行系统的收集、申请、反馈、数据查询等业务操作；超出集团公司授权的数据查询申请要由第一责任人向集团公司提出申请。

第六条 各部门及子公司在集团公司固定资产管理要求下负责本单位内部电脑及网络设施设备的保管及维护工作。各部门及子公司不能在没有授权的情况下对相关设备进行搬动、拆解、调整及更换。

第三章 系统用户权限管理

第七条 用户权限的申请

集团全部信息系统采用一账通管理模式，并与人力资源系统衔接，对应人员入职岗位就享有与之岗位相匹配的管理、操作及查询权限。不得私自使用他人权限进行系统查询及操作。每级用户权限需要严格管理，并定期修改密码。用户要保护好自己的系统权限，发生密码泄漏事件，及时上系统进行密码更改。用户不得随意将自己的密码告诉他人，在特殊情况由于工作需要的，必须经集团公司申请同意后，备案后才可授权给他人使用。

第八条 用户权限的申请审批

如果需要超出自己的岗位权限的系统权限需向上级或集团公司申请，由公司调整增加。信息系统用户权限新增（变更）申请需有本部门或子公司第一责任人在公司OA系统中由申请，按照集团公司申请流程进行审批。

第九条 ERP系统授权原则

二线管理部门仅各部门第一责任人能查询集团整体销售、成本数据。其他岗位将不整体开放业务数据查询，仅根据工作需要开启某一方面业务数据的查询。

第四章 电脑及相关网络设备的管理

第十条 员工办公电脑的应用

员工办公电脑是公司根据岗位工作需要，分配给员工日常办公使用的电脑，属于公司资产，员工是办公电脑的使用，日常保管责任人，应爱护管理好办公电脑。

公司负责员工电脑的分配与调整，有权根据工作需要调整分配办公电脑，任何个人未经准许不得私自更换，调整，搬动电脑，严禁对电脑主机拆机，违反以上规定，视情况按公司奖惩制度执行，擅自拆机损坏电脑、拷贝集团公司数据者将给予辞退处理。

部门间电脑调整，应按照集团公司固定资产调拨管理固定执行。公司不允许员工私自把个人笔记本带到公司使用，如发现公司将提出警告出发。如果确实因移动办公需要的岗位，需填写申请单，经集团公司批准后方可使用。

员工电脑办公软件统一安装维护，分配管理。员工个人不得自行安装软件，如发现公司将提出警告处罚，如需增加安装的软件工具，需填写申请集团公司批复后由融达协助安

装。

如若员工离职，需由第一责任人通知融达公司，由公司管理员及第一责任人现场做好电脑设备及数据文件交接工作。若离职人员未交接好电脑及文件便办理了离职手续，由其所在部门直接领导承担相关责任。

第十一条 员工上网行为的管理

员工不得利用公司网络资源将公司机密的数据泄露或做出其他有损公司利益以及违反国家法律法规的行为，如有违反，将视情节轻重，按公司《奖惩管理制度》处罚或移交司法机关处理。

第十二条 员工应按公司管理要求正确使用办公电脑，严禁未经保管人同意私自使用他人电脑。

第五章 附 则

用户权限管理 篇5

一、SAP系统权限的概念

SAP系统用户要完成某项工作需要运行相应的事务码, 不同的事务码可以在系统中进行不同的动作。而权限问题的产生, 是基于系统权限检查的机制:即用户在SAP系统中进行事务操作时, 系统将会检查用户相应事务的权限。

SAP系统的权限控制是基于事务码 (Transaction/Menu) 和授权对象的, 其中, 通常所说的授权对象则是权限控制的最小单位。

换言之, 一个事务码看似具有多种功能, 但用户拥有某一事务码并不意味着拥有该事务码的所有功能权限, 其权限大小受制于授权对象, 因为权限对象 (authorization object) 用于事务中详细的权限控制。以用户权限管理的事务码SU01为例, 该事务码是用于用户主记录维护 (transaction code SU01) 的事务码, 但通过控制授权对象S_USER_GRP不同赋值可以限制管理员用相应的权限进行的活动。比如赋予01、02值, 可以用于用户的创建/更改;如果只赋予03, 则只可用于用户的显示;如果赋值05, 则可赋予冻结, 解冻权限。完全由SU01所包含的权限对象控制。如果在企业拥有多个用户管理员的情况下, 该权限对象还可以维护用户组的值, 可以给不同的用户管理员配置不同的用户组维护权限, 而未配置用户组的用户, 所有用户管理员均可以加以维护。这一点对于集团企业不同层次用户管理权限的分配十分有用。

角色是SAP系统中权限的集合, 可能包含一个或数个事务码, 也可能包含一个或数个权限对象。同一类工作使用SAP的目的和常用的功能都是类似的, 当我们把某类工作需要的权限都归到一个集合中这个权限集合就是“角色” (Role) 。

在SAP4.0版本以前, 没有角色概念, 只有参数文件 (即Profile) , 目前在授权管理的实践中已不再进行重点处理。为便于管理操作, 就引进了角色。4.0以后开始用角色来做权限了。

SAP系统另一重要特点即权限是累加的。

用户可以拥有多个SAP角色, 所有角色的权限累加在一起成为用户的最终权限。比如, 如果你拥有的角色中, 其中一个角色有事务“角色管理PFCG”的显示权限, 另一个角色有事务“用户管理PFCG”的更改权限。那么你总的就拥有角色显示和更改的权限。

二、权限的设计架构及各类角色定义

权限设计架构或称为角色的设计模式是SAP ERP系统权限管理的基础。相对完整的权限设计架构一般为三层架构模式。具体见下图:

各层角色定义说明如下:

(1) 公共角色 (Common Role) :也被称作通用角色, 其中被赋予了相关的事务代码与操作权限, 但是没有任何组织级别限制的角色。主要用来作为角色模板, 被本地角色继承。

(2) 本地角色 (Local Role) :从通用角色继承而来, 根据用户业务实际要求, 限制在一定组织级别范围内使用的权限;特殊角色 (Special Role) :指根据业务需要从所有其他角色中抽取出特定的权限对象单独加以赋值形成的角色。一般与其他角色组合生成特定的权限。

(3) 岗位角色 (Position Role) :指SAP系统的复合角色, 是一系列本地角色以及特殊本地角色的集合, 同HR的岗位相似。某类特定岗位的所有事务权限包含其中。在实践中往往结合企业的实际给予用户一个岗位角色或者多个岗位角色的权限。

由上述可知, 公共角色是SAP系统权限的基本模板, 是权限大厦的基石, 由此继承派生的本地角色除了限制相应的组织级别外, 权限功能点基本成形, 一般不会有大的变化。而岗位角色在技术上看是对本地角色的打包, 从管理上则尽量要求岗位角色所含权限的不可再分割性, 这样, 在实际授权时就可通过不可再分割的岗位角色组合完成, 从而避免本地角色组合方式过多使授权混乱乃至不可操作。

权限设计架构是企业整体权限实施的核心, 将贯穿SAP系统实施乃至后期运维工作的整个系统生命周期。如果不能牢固把握并坚持这一点, 势必造成权限管理的混乱。

基于上述架构, 在授权实践中, 尤其在层次复杂的集团型企业, 至少需要把握以下几点基本要求:

(1) 各类角色设计须建立统一的编码规则, 便于分类查询和系统管理;

(2) 授权中系统不支持将事务码直接分配给用户的操作;

(3) 一般情况下, 只将岗位角色分配给用户, 而不是本地角色或通用角色, 以限制企业集团环境下授权的随意化, 保障授权的可操作性;

(4) 在进行权限变更时, 不可直接修改本地角色, 否则由于本地角色与通用角色之间的继承关系, 会被通用角色所覆盖, 使本地角色修改无效;

三、权限实施的职责分工及流程要点

从授权实践来看, 授权管理绝不仅仅是局限于权限管理员的技术活, 而是一个充满互动的系统工程, 需要企业用户、系统各模块顾问、技术 (权限管理) 等多个部门参与, 甚至发挥主导的作用。

(一) 权限设计的职责分工

公共角色:由SAP系统核心组集中进行控制, 公共角色由中央组集中设计, 包含了每个公司几乎所有要用到的“工作任务”。

核心组业务顾问设计, 权限顾问加以配置实施。

本地角色:公司特有的本地角色是从公共角色继承得到的。从公用角色, 针对不同的公司代码和工厂可以继承得到几套本地角色, 它们可能包含同样的事务代码和权限对象, 唯一的不同是组织层级数据 (例如, 工厂、公司代码、采购组织) 。

本地角色是本地项目顾问设计。

岗位角色:岗位角色由本地关键用户根据公司具体的业务流程设计, 在本地岗位角色中只能包括本公司特有的本地角色, 以避免不同公司之间数据边界重复。

岗位角色由企业本地关键用户设计。

(二) 权限实施各环节主要工作

SAP系统权限实施的全部流程包括岗位信息收集和分析、各层次角色设计与创建、用户清单及权限分配、权限配置、权限测试、角色传输、上线支持等阶段。以下以集团型企业为例对权限实施各阶段的主要工作内容加以阐述。

(1) 通用角色的设计与创建:权限顾问负责下发岗位信息模板, 由人力资源部门负责提供, 集团核心组模块顾问负责提供通用角色设计文档。

(2) 本地角色和特殊角色的设计与创建:ERP项目实施站点企业模块顾问根据通用角色模板, 提交本地角色设计文档和特殊角色设计文档的提交。

(3) 岗位角色的设计与创建:各站点企业关键用户提交岗位角色设计和用户权限分配文档。

(4) 用户账号的创建与权限测试:权限顾问实施完成权限配置后, 关键用户在顾问指导下进行权限测试, 如有问题, 填报权限测试文档反馈给权限顾问进行分析并修改完善。

(5) 角色传输:权限测试通过后, 将在测试系统中创建的角色传输至生产系统, 开始上线投入使用。

(6) 运维支持阶段:在上线期结束后系统进入运行维护阶段, 此期间站点企业最终用户在业务操作过程中发现权限问题, 通过填写权限变更申请表提交问题, 根据权限变更流程进行处理。

四、用户权限安全审计

因为SAP ERP系统是已实施企业的核心业务系统, 所以已经被越来越多纳入企业审计工作的范畴。除延请外部机构进行的审计外, 企业内部也会定期对系统进行用户安全和权限审计, 以发现不再合适的授权、不再合理的权限设计, 从而达到持续优化、控制风险的目的。这里从用户安全参数、各类用户基本审计、用户安全审计等方面加以阐述。

(一) 用户安全参数

SAP系统通过对一整套用户安全参数的灵活设置对用户访问进行安全控制。常用的参数主要包括最小密码长度、密码的最小个数、密码中字母的最小个数、口令更新时间间隔、密码历史次数、用户登录系统失败退出次数、用户登录系统失败锁定次数、是否激活硬代码SAP*账户、最大用户断开空闲时间、密码中的排除列表等等, 这些参数尽可能考虑了用户访问控制失密的各种可能性。而在审计时会通过对参数设置情况的检查, 评估企业用户访问控制规划的完整性, 找出系统用户安全保护的隐患。而且这些密码策略在系统中配置后需要系统重新启动后才能生效。

(二) 标准用户及拥有超级用户权限的用户审计

标准用户和超级用户因其拥有超级权限是用户审计不能忽略的。

标准用户指系统安装后自动生成的用户。可使用事务码“RSUSR003”检查标准用户安全状态。具体见下表:

审计可以查看上述信息, 并需要更改以上所有密码。例如:DDIC的密码是系统默认的19920706, 这样的密码是广为人知的, 很不安全, 根据此报告反馈的结果, 就需要修改这些不安全的密码;还有, SAP*用户通常检查是不存在的, 此时任何人可以用SAP*, 密码pass登录系统。我们就需要创建SAP*用户, 并设置密码。

此外, 需要审计拥有SAP_ALL超级用户权限的账号, 可用事务码“S_BCE_68001421”, 查出相关用户列表, 评估这些用户拥有超级权限的可行性。

需要注意的是, 因为工作需要, 系统实施时往往会创建一些拥有较大权限的用户, 也应适时予以评估调整, 以规避系统风险。

(三) 最终用户权限审计

最终用户指真正在系统中进行业务处理的用户。对于这类用户权限的审计一般包括用户账号清单、用户权限匹配、未登录用户等三方面的内容, 由企业相关业务管理部门负责审核。

1. 用户账号

按用户组导出每个企业的用户清单, 可用事务码SU10。

2. 用户权限匹配

目的是保证用户信息的有效性和准确性。重点关注三项内容: (1) 用户权限对照表, 审计权限与用户的匹配; (2) 岗位角色与本地角色的对照, 审计岗位角色的合理性; (3) 审计长时间没有登录的有效对话用户。此项可运用事务码:RSUSR200。

(四) 用户安全审计

用户安全审计通常根据管理需要, 由系统管理部门在既定的审计策略下, 分解和确定需要跟踪分析的client、事件类别、具体事件, 然后在系统后台加以配置。

SAP自带的审计功能有两个, 首先是事件型态的审计日志 (audit log) , 通过参数rsau/enable=1开启该功能;其次事务码SM19配置要审计的事件, SM20来做审计日志分析 (audit log analysis) 。

SM20审计查询的选项一般有client、时间区间、审计类别、具体事件等, 据此可以查询指定用户有关登录情况、系统操作等信息, 包括系统管理员的动作列表。

鉴于审计日志在操作系统上以文件形式存储的, 因此没有sap_all权限却有操作系统ROOT权限的一样可以删除日志。如果实施了上述监控的话, 即使有SAP_ALL的人员在SAP上删除了审计日志, 但这个删除动作是可以被SAP系统记录下来的, 所以审计日志依然可以起作用, 对于系统安全监控和追溯分析具有一定价值。

用户权限管理 篇6

作为国家电网公司信息化建设及应用的核心组成部分,ERP系统在公司生产经营管理中发挥着重要作用。随着国家电网公司ERP系统建设的不断推进和应用的逐步深化,ERP系统运行维护工作的重要性日益突显。2009年3月以来,湖北电力公司各单位陆续完成ERP系统建设并转入运维,高级应用项目也已建成并投入运行,人资管控、审计系统等项目也在紧锣密鼓的实施中。这种用户使用覆盖面广、业务种类繁多、系统集成性高、运行维护与项目实施并存的现状无疑对ERP系统运维工作提出了更高要求,而其中各类用户的运维和管理才是运维工作和项目实施中的重中之重。

1 用户及权限模型设计

湖北电力ERP项目的实施范围广,外围系统的接口繁多,并且运维和实施工作同步进行。种种因素造成系统用户数量大、种类多的现状,各个实施厂商对用户的命名缺乏规范,对用户的使用缺乏管理,对项目实施期间需要的用户权限也没有统一标准。因此,需要根据用户的不同类型来分组管理(见图1),并根据用户的岗位和功能需求进行权限设计。

1.1 用户类型

ERP系统中的用户可依据不同的权限范围分为五大类:分别是最终用户、接口用户、支持用户、救火员用户和超级管理员用户。

1)最终用户是业务操作的执行者,涉及人资、财务、项目、物资、设备五大业务模块,权限范围涉及五大模块中所有业务查询、操作和执行的功能,是ERP系统中用户的主体。

2)接口用户主要是外围系统与ERP系统集成时进行数据交换的连接用户,如财务、人资、物资模块的管控系统与ERP系统的各类RFC用户,用户类型为通信用户,有别于其他对话用户,权限范围仅涉及外部RFC连接访问的功能。

3)支持用户则是实施顾问和运维团队为最终用户提供业务或技术支持时使用的,权限范围涉及五大模块中所有的业务查询和权限追踪功能,但不具备操作和执行。

4)救火员用户是当遇到突发事件时通过执行紧急流程审核后,分配给实施顾问或运维团队人员,用以对系统中业务数据或后台配置进行修改或操作,权限范围综合了最终用户和支持用户。

5)超级管理员用户即系统管理员,由ERP运维部内部人员担任,拥有SAP ALL权限,可以在相关制度约束范围内进行所有操作。

1.2 用户分组

在SAP系统中通过事物代码SUGR可对用户进行分组,意义在于方便系统管理员对不同组别的用户进行管理。同时还可满足分级管理的需求。基于用户类别的不同,可以对系统中所有用户划分为多个用户组以便于权限管理。如最终用户根据其利润中心划分为多个用户组,命名同利润中心:L15F000001、L15J000003。通过用户分组,可以使管理员拥有既定组别里用户的管理权限。避免了权限过于集中,减轻了管理员的压力,同时也提高了管理的灵活性。

1.3 权限及角色设计

SAP系统的权限控制是基于事物代码(TCODE/Menu)和授权对象(Authorization Object)的,其中授权对象是权限控制的最小单位。当用户拥有某个事物代码的权限并不意味着可以实现该事物代码的所有功能。这是由于授权对象的设置决定了功能实现的范围。

而单一角色是SAP系统中权限的集合,可以包含一个或多个事物代码,也可以包含一个或多个授权对象,多个单一角色的集合则称为复合角色。湖北公司SAP系统中对用户权限设计的原则基于模型化的思路(见图2),以用户每个具体操作为权限的基本单位设置本地角色,再根据同类型业务操作将本地角色组合后的复合角色作为用户的岗位权限。其特点是将每个岗位的业务操作形成粒度极细的本地角色,可以灵活的配置、组合,提供给不同需求的岗位角色。并且单一的业务操作角色测试工作简单,不重复,为运维工作带来了方便。

在权限设计理念的基础上,实际权限分配过程中还应注意以下几点:

1)制定角色命名统一规范,方便管理和查询;

2)一般情况下,用户只能分配岗位角色,不能直接添加事物代码或本地角色;

3)当权限变更时,不应直接修改本地角色,由于本地角色和模板角色之间的继承关系会使修改无效。

2 用户及权限管理模式

随着ERP系统的运行和应用逐渐顺畅和深入,用户对系统的依赖不断加强,对业务的应用不断提高。例如,用户会不断的提出新的业务需求,对新增的业务功能点要求开通相应的功能权限等。当系统管理员面对大量增加权限的申请时,如何判断是否合理,或依据何种标准来判断。

2.1 最终用户权限管理模式

最终用户的权限通过需求分析、蓝图设计和差异调研后已经形成明确的岗位需求和设计依据。通过制定模板角色、本地角色和岗位角色间的对应关系表,可以很容易的找到某个岗位应该分配何种角色。并且最终用户的权限范围仅涉及业务操作,管理起来相对简单。而最终用户的创建和权限分配则通过用户变更流程来完成。

2.2 支持用户权限管理模式

而对于湖北公司ERP系统运维工作和项目实施并存的特殊现状,还需对系统中的支持用户进行管理。支持用户又分为顾问用户和运维用户,虽然用户量很少,但管理起来比较复杂。主要原因是此类用户的权限设计系统层面较多,如用户权限查看、程序运行检查、数据库表浏览等。如果管理不善可能会对系统或敏感信息的安全造成威胁。

对于此类用户的权限分配由顾问或运维人员提出需求,如需要的权限不在角色关系对应表中,可以通过SAP提供的角色模板来设计角色。需要注意的是生产系统中应遵循权限分配最小化的原则,即赋给用户的角色应小于或刚好等于用户的权限需求,通常是将授权对象中不必要的功能屏蔽。如果用户在测试过程中发现没有权限操作,再利用事物代码SU53来追踪缺少的权限并填加。

3 用户及权限运维流程

遵循“分级审批、集中维护”的原则,湖北公司制定了ERP系统用户从问题提出、受理到解决与反馈的闭环管理流程。

根据用户需求的不同,大致可将ERP系统中用户及权限的管理流程分为:用户新增管理流程、权限变更管理流程、密码及解锁管理流程、批量加解锁管理流程。其中权限变更管理流程是针对系统中权限调整而制定的,其余则是针对最终用户。

3.1 用户新增管理流程

新增用户管理流程(省公司本部)如图3所示,详细说明如下。

1)提出申请。省公司最终用户有新增用户需求时,首先提交申请。

2)归口管理部门审批。由省公司关键用户收集填写用户账号及权限申请表,报省公司归口管理部门进行审批并签字盖章。

3)受理申请。由省公司关键用户将审批通过的申请单递交电话服务热线。电话服务热线受理申请,在网上问题受理系统中记录申请信息,并将该申请调度分配给技术支持组。

4)用户创建。运维团队创建用户,并根据用户岗位设计用户角色,然后将用户名反馈给用户。

5)关闭问题。电话热线负责对用户回访,并在网上问题受理系统中完结申请。

3.2 权限变更管理流程

权限变更管理流程(适用于地市单位)如图4所示,详细说明如下。

1)提出申请。省公司二级单位最终用户提出权限变更申请,提交省公司二级单位本部关键用户。

2)审批申请。省公司二级单位本部关键用户判断是否涉及业务流程变更,若涉及业务变更,转入功能变更流程。若不涉及业务流程变更,由关键用户填写用户权限申请表,省公司二级单位本部归口管理部门审核通过后,由关键用户将纸质申请单提交给运维团队电话服务热线。

3)受理申请。运维团队电话服务热线受理申请后,在网上问题受理系统中记录申请,并将申请分派给运维团队业务支持组。运维团队业务支持组受理后,判断该权限变更是否需要跨部门审批,若不需要跨部门审批,则提交运维技术支持组;若需要跨部门审批,则提交省公司二级单位ERP项目办公室(PMO),由省公司二级单位ERP项目办公室组织相关部门进行审批,审批通过后提交运维技术支持组。

4)权限维护。运维技术支持组负责测试系统中进行权限变更维护。

5)权限测试。变更完成后,由关键用户进行测试。

6)权限传输。关键用户测试通过后,由运维团队业务支持组提交传输申请,运维团队技术支持组负责将权限变更传输至生产环境。

7)更新文档。由运维技术支持组更新权限文档。

8)反馈用户。运维业务支持组负责反馈用户。

9)关闭问题。运维团队电话服务热线负责回访处理结果,并在问题受理系统中关闭问题。

3.3 流程及质量管控

为保证流程的流转效率和执行力,还依靠问题管理系统和SolutionManager等软件平台来进行流程闭环管理的质量控制。为每个流程制定了相应的表单,如用户账号及权限申请表、用户加解锁及密码初始化申请表、权限变更传输申请表等。同时,为规范流程中的每个节点,实行阶段控制,分级审批机制。还将用户变更类流程大致分为需求提出、需求受理、需求变更、需求测试、信息反馈等5个环节。

根据每个环节节点的需求内容和审批机制来设计对应的申请表单,相应的审批通过后才能进入流程的下个环节,而所有表单的流转和管理均在SolutionManager里实现。如此一来,不但可以集中建立和管理各个流程的文档和表单,更是实现变更流程管理、控制和监督的唯一可见方式。

为更好的进行流程管理,还设置管理专责进行流程管控。主要内容为:督导运维流程执行、负责资料归档、记录和管理用户投诉、定期进行满意度调查、负责用户运维工作的统计分析、提出流程优化方案。

通过这些举措将管理节点前移,加强关键节点管控,实现流程精细化闭环管理。

4 安全审计

ERP系统的五大核心业务涉及大量生产、经营机密数据。为保证此类数据的安全,定期对系统进行用户安全和权限审计是极为必要的。通过审计发现不合理的权限设计和用户授权,从而达到控制风险、持续优化的目的。

4.1 账号安全

SAP系统中可以通过系统参数设置对用户访问进行安全控制。如密码长度、密码的组合方式、密码更新周期、用户密码错误几次后会被锁定、最大用户断开的空闲时长等。通过对这些参数的组合设置,形成一套较强的安全策略,尽可能的考虑用户访问控制的便捷性和安全性。

4.2 用户审计

1)超级用户。SAP系统中的超级用户是指SAP*和DDIC。系统安装之后这2个用户自动就会在系统中存在,密码可以在安装的时候指定,安装之后也可以进行修改。这2个用户的权限也是最大的,拥有SAP_ALL权限。DDIC是在系统初始化时进行配置使用的用户。SAP*则是系统的初始用户,拥有所有权限。但通过用户检查是看不到的,所以可以创建一个新的SAP*用户来覆盖原用户,并通过设定参数将SAP*禁用来保证此用户的安全。

2)最终用户。对于此类用户的审计从用户账号清理、用户权限匹配、敏感权限查询和安全审计几方面着手。

定期将系统中所有用户清单导出,审计系统中没有登录的用户,制定相应策略。比如将3个月内未登录过系统的用户锁定,半年内仍未登录的用户报上级有关部门审批后删除。

对于用户权限审计应重点关注用户权限对应表,审计用户与岗位角色的匹配;而岗位角色与本地角色的对应表,则应重点审计岗位角色设计是否遵循业务部门的岗位设置及其合理性。

敏感权限查询可通过事物代码SUIM中用户匹配参数文件来查找系统中是否有用户拥有过大权限或是敏感权限。

安全审计通常根据管理需要制定相应的审计策略,并在系统后台配置后通过设定参数开启SAP自身的审计功能。操作时通过事物代码SM20进入,设置集团、时间区间、审计类别等参数后可以查询指定用户的所有情况,包括对话登录、执行事物代码、主数据更改等。另外一种办法则通过事物代码STAD进入,设置集团、时间区间、事物代码等参数后可以查询指定用户的对话登录终端信息、事物代码执行时对应的系统性能以及更多的参数细节。

5 结语

ERP系统在企业经营、生产的运作过程中扮演着愈来愈重要的角色,任何数据、后台配置、系统参数的更改,或者企业机密、敏感信息的透露都会对整个企业的数据流、业务流和信息安全产生很大的影响。因此,对于ERP系统上线以后的用户出口一定要制定严格的策略进行管控。随着国家电网公司对信息化建设的不断深入,日益严苛的合规性要求和企业控制风险的需求,使ERP系统的用户管理日趋复杂和严格。如何结合ERP系统应用现状,积极探索适合自己的运维管理模式,是今后追求和探索的方向。

摘要：文章阐述了SAPERP用户及权限运维管理涉及的主要问题。通过用户分组、权限控制以及相应的管理流程和审计功能对系统中各类用户和权限进行严格管理和控制,从而达到在为授权用户提供尽可能方便、同时保障重要数据和敏感信息安全的目的。

关键词：ERP,运维,用户,管理

参考文献

[1]王坚.SAP ERP系统用户权限实施和管理浅谈[J].化工管理,2010(5):54-57.

[2]何发武.ERP动态权限管理与实现[J].电脑开发与应用,2004,17(11):2-4.HE Fa-wu.ERP Dynamic Authotity Man aement and Implementation[J].Computer Development&Applications,2004,17(11):2-4.

用户权限管理 篇7

近年来, 随着城市轨道交通的高速发展, 综合监控系统 (ISCS) 应用日益广泛, 其各项技术细节也愈受重视。ISCS集成有多个子系统和互联系统, 这就意味着所有子系统的报警信息均需要ISCS进行统一协调、管理。

ISCS通常采用通用的工控软件平台, 如CI-TECT、IFIX、WINCC等, 通常这类软件平台提供的用户、权限以及报警管理功能单一, 界面不友好, 无法满足ISCS多站点、多专业、多层级、多用户的管理需求[1]。

针对这一差异化需求, 设计开发了基于用户权限的综合监控系统报警管理功能, 实现了用户权限与报警信息的统一、集中管理, 并取得了很好的应用效果, 大大提高了综合监控系统的可靠性和扩展性。

2 用户和权限

ISCS涉及到数十个车站的子系统及互联系统专业设备, 兼顾多种用户及多个控制层级的安全管理, 因此用户权限管理十分复杂。

ISCS通过用户编码、密码识别并分配操作权限来实现系统安全管理, 只有授权用户才能执行相关设备的监视和控制[2]。

ISCS控制层级通常可分为四类, 按照优先级高至低分为:就地—IBP—车站—中心。

ISCS用户操作权限类别一般分为三大类:系统管理级 (1-3级) 、运营操作级 (4-7级) 和浏览级 (8-10级) , 如表1所示。

由于地铁运营部门对各级操作员的划分非常严格, 每个操作类别中的用户又可以分别按照不同的专业、不同的监控层级区分管理职能。系统管理员作为最高管理权限的存在, 软件管理员、系统工程师、调度和设备维修员等均根据专业细分管理职能, 站长、车站值班员、中心浏览、车站浏览、WEB浏览按照监控层级区分。

3 报警功能

ISCS按功能分为中心、车站、车辆段、停车场ISCS。中心ISCS是系统监视和控制的核心, 负责全线各车站、车辆段、停车场所有关联设备;各车站、车辆段、停车场ISCS负责本区域所有关联设备。各区域ISCS集成的子系统通常一样, 包括环境与设备监控系统 (BAS) 、火灾报警系统 (FAS) 、电力监控系统 (PSCADA) ;而互联系统的包含种类与区域功能有关, 通常包括屏蔽门系统 (PSD) 、自动售检票系统 (AFC) 、乘客信息显示系统 (PIS) 、广播系统 (PA) 、信号系统 (SIG) 和综合安防系统 (ISDS) 等[2]。

综合监控系统报警具备系统实时报警记录和总览报警记录、报警过滤等功能, 可以查询当前ISCS中定义的报警和事件动作情况以及历史报警记录, 有利于查找故障原因。

报警内容涵盖了所有的集成子系统和互联系统。为区分重要和不太重要的报警事件, 每个报警都有相关“严重度”。严重度是一个指示报警关键程度的数字;每个严重度对应不同的颜色和声音, 操作员能很容易的区分它们。一般报警内容分3-4级, 依次对应着报警的级别, 即报警内容的严重程度:紧急 (级别1) ;报警 (级别2) ;警告 (级别3) 。

报警事件保存在事件列表中以供查询。系统采用不同的颜色来显示不同的报警级别, 使得操作员能集中精神于具体操作上。报警通过如下形式被通知:

报警信息出现在HMI的报警条上;

报警信息出现在报警摘要中;

声音报警 (可被操作员禁止, 系统管理员可配置不同的声音对应不同的报警级别) ;

报警信息在报警/事件打印机上打印;

HMI上相对应的设备图标闪烁。

ISCS提供的报警可监控全部设备的动态状态。典型的颜色包括:红闪——未确认的一级报警状态;黄闪——未确认的二级报警状态;蓝闪——未确认的三级警告状态;绿闪:已关闭未确认的报警状态。

对于每个级别的运营操作员来说, 特别是在晚间隧道作业或者测试等比较频繁产生报警信息的时候, 根据同级报警时间优先原则, 所关注的最新报警信息被同级别非关注类型报警信息压到显示页面之后, 大大增加信息查看工作量, 而且容易遗漏查看报警信息, 导致事故。因此, 设计了基于用户权限的系统报警管理机制来解决这个问题。

4 基于用户权限的系统报警管理

基于用户权限的综合监控系统报警管理, 核心思想是通过角色控制来实现用户与权限之间的逻辑隔离, 从而优化对报警的管理, 满足用户的实际需求[3]。如何将操作员、控制权限与报警管理联系起来, 为此以深圳地铁五号线ISCS为例, 将用户角色、报警区、操作权限三种属性结合来实现。

4.1 用户管理

采用网络和本地相结合身份验证方式, 在OCC的两台历史服务器上, 以文件的方式存放所有的用户帐户信息, 作为验证数据的权威来源。两服务器上的文件保持最新, 互为备份。开发了专用的用户管理工具进行用户权限编辑, 编辑界面见图1所示。在该工具上, 工程师可以建立用户帐号, 建立身份角色, 建立操作区域, 建立对角色区域的权限的有无, 并可以把配置信息实时下发到各个车站。

4.2 报警管理

4.2.1 报警区

报警区, 即报警区域, 按专业、逻辑或子系统定义划分。报警区决定着用户角色对本区域报警信息的一个读写权限, 它是包含于用户操作权中的一个特殊集合。只有当用户拥有与之匹配的角色权限分配表中某一个报警区的浏览权, 该用户才可以监视这一报警区的报警信息, 否则, 该报警区的所有数据对此用户屏蔽不可见或不可操作。在实际工程中, 每个报警区使用唯一编号, ISCS系统内不重复。

同时, 将报警区域的操作权限进行划分, 与报警区域号组成二维数组自由组合。当用户具备某一个报警区的某类操作权时, 才可以进行该类权限对应的报警信息浏览或者确认操作, 否则该类报警信息的对该用户自动屏蔽不可见。

以深圳地铁5号线ISCS系统为例, 报警区规划表和操作权限表分别如表2、3所示。

根据用户操作级别及内部岗位分工, 深圳地铁五号线环控调度操作员的报警操作权限分配表如图2所示。

4.2.2 权限验证

地铁ISCS对用户报警操作权限的验证步骤如下:用户登录成功后, 角色控件将收到身份验证服务器发来的登录成功消息和用户的身份信息。然后角色控件根据身份信息搜索本地的权限文件, 取出该用户的报警操作权限分配表, 以字符串的方式传给ISCS软件, 然后关闭登录窗口。ISCS软件根据用户权限表建立一系列判断后, 对显示的报警相关页面进行自动过滤, 显示其预设置的报警信息, 或者限制预设置报警信息的操作确认权限, 以此减轻操作员的负担并更快的响应本职事件。流程如图3所示。

5 总结

在城市轨道交通运营前或者运营初期, ISCS软件设计未必能考虑到报警管理这方面的问题。但是面对用户精细化的管理需求, 软件开发人员需要及时做出反应, 结合自身软件的技术特性, 采用优化的解决机制, 对软件功能进行改进, 从而获得良好的用户满意度。

摘要：针对综合监控系统中人机界面用户权限和报警管理的差异化需求, 设计并完成了基于用户权限的报警管理功能, 实现了用户权限与报警信息的集中管理, 并取得了良好的应用效果。

关键词：综合监控系统,用户权限,报警管理

参考文献

[1]程朋胜, 李剑波.地铁综合监控系统之用户和权限管理[J].机电工程技术, 2011 (12) :34-37.

[2]王凯杰.城市轨道交通综合监控系统的设计思路[J].现代城市轨道交通, 2011 (01) :29-31.

用户权限管理 篇8

近年来, 中国电力工业发展极其迅猛。2005年底中国电力装机500 GW, 到2011年底增至1 050GW, 年均增长91GW, 预计2020年全网电力装机容量将达到1 900GW。电网规模和电厂数量的迅速增加导致省、地、县调和电厂间耦合程度越来越高, 各级调度机构间信息传输和数据管理变得越来越复杂, 如何有效实现调度机构间的数据统一管理, 避免信息孤岛, 是目前电网管理系统研发面临的关键问题。传统管理模式中, 各调度机构均通过自身的信息管理系统实现业务操作, 其信息数据相对独立, 相互间的信息协调通过报表、邮件或电话方式沟通实现, 无法及时对信息进行共享和交互。

以省地县一体化管理模式[1,2,3]为支撑的电网管理系统可以有效地整合各级调度机构信息, 全面部署各项应用业务, 使省级电网和地县区电网数据形成一个有机的整体, 达到信息全面共享, 实现电网统一调度、管理与监控[4,5]。该模式将调度机构按职能和调度关系从上至下分为3级:省调机构、地调机构和县调机构。下级调度机构负责维护自身数据、上报和管理生产数据信息, 而上级调度机构可以查询下级机构的报表、生产数据信息, 并审核下级机构的计划调度方案, 但不干涉其管理方式。以此模式为基础构建的省地县一体化电力调度管理系统 (以下简称一体化管理系统) 需保证各级调度机构独立管理自身生产信息, 同时需确保上下级调度机构间信息和操作流程的协调配合, 实现系统的安全运行和信息资料的有序管理。因此, 一体化管理系统中大量数据信息和操作流程必须面向各级调度机构赋予不同级别的访问权限以实现差异化访问控制, 这给权限设计实现带来了极大的困难。

本文提出了以改进的基于角色的访问控制 (RBAC) 模型为基础的分级用户权限方案, 对一体化管理系统进行权限控制。首先, 以角色作为授权主体, 并增加特殊用户 (和部分角色权限集仅有细微差异) 直接授权方式, 简化授权过程的同时解决了同级用户职权存在细微差异引起的“角色泛滥”问题;其次, 针对分级调度机构业务特点, 引入“用户—角色—页面—权限”权限描述方式, 通过页面整合业务权限以细化权限粒度, 进一步简化不同级别用户的授权过程;最后, 分级授权过程采用上级分配直属下级的管理员角色和用户, 下级管理员再在自己权限范围进行角色和用户的授权, 保证授权过程及数据的安全性。该方案在云南电网小电省地县一体化调度管理系统中得到成功应用。

1 分级用户权限方案总体设计

一体化管理系统中各级调度机构间的数据信息和业务流程既有相似性, 又存在差异。如报表管理业务中, 县调和地调都需要审核所管辖范围内的电站上报的计划和报表, 并上报给上级调度机构, 而省调只需要审核地调的上报结果, 但需要查询地调、县调及各级电站的报表数据。这种特点一方面要求权限设计的灵活性和可扩展性, 另一方面需要考虑权限授权过程的灵活性和管理的安全性。

1.1 开放式可扩展权限设计

权限可扩展性是衡量权限管理优劣的重要标准。一体化管理系统中不同角色对各业务模块的操作方式各不相同, 并且其操作方式可能会随着需求变化而改变, 为此需要实现权限自动扩展。系统中权限可以抽象为两大类:查看权限和修改权限。查看是指能否进入该模块或功能页面, 此外的所有操作统一定义为修改, 包括数据修改、流程审核审批、报表导入导出、信息保存等。形式化描述为:

式中:SysS和EditS分别为系统权限集和修改权限集;enterp和editp[i]分别为查看和修改权限元素。

系统授权或新增修改权限时实现预定义的权限抽象方法即可完成权限的自动扩展。形式化描述为:

即用户u对应的角色r所拥有的执行op操作的权限通过实现可执行op操作的editp[i]权限或enterp权限获得。R[u]表示用户u的角色集合;OP[r]表示角色r的可执行的操作集。这种权限扩展方式对于没有指定角色的特殊用户同样适用, 只需将用户本身作为授权主体即可。

将权限分为查看和修改两类, 通过修改权限集的开放式设计实现权限的广度扩展, 可降低权限的深度控制, 简化系统设计、流程控制及用户授权过程。

1.2 改进的RBAC模型

一体化管理系统由大量业务功能模块构成, 这些模块大多以不同的功能页面形式展现给各级用户。各级用户在实际操作时通过进入相应模块的页面进行操作, 但是他们对页面中的权限存在着较大差异, 为避免RBAC模型授权管理中存在对业务模块的权限控制粒度大、难以细化的弊端[6,7,8,9], 本文引入了页面层, 采用“用户—角色—页面—权限”控制方式。用户通过所属角色获得对模块的操作权限后, 可以进一步为其分配操作从属于该模块的页面的权限, 实现了权限的进一步细化。如果用户无权操作某模块, 则无需为其分配操作该模块下页面的权限, 简化了授权过程。改进的RBAC模型如图1所示。图中:“页面X-Y”表示模块X的第Y个页面;“用户”和“角色”间连线表示二者间从属关系;“角色”或“用户”与“模块—页面”间连线表示该角色或用户对指定页面的控制权限, 是满足用户最大需求的权限集的最小子集。

改进的RBAC模型引入页面作为权限载体, 细化了权限控制粒度, 简化了授权过程, 增加了授权的灵活性。该模型主要采用角色授权方式, 同时对与现有角色权限集存在细微差异的用户采用用户直接授权方式, 有效解决了“角色泛滥”问题。

1.3 分级用户授权策略

一体化管理系统涉及多级用户, 各级用户的业务范围和操作流程必须通过权限进行精细化控制, 这需要灵活安全的分级用户授权策略。系统中上级用户可通过创建、授权、维护等方式管理下级用户, 具有较高权限, 为此本文采用“上级分配策略”实现分级用户授权管理。该策略在构建系统时预先创建具有最大权限集的省调管理员, 由其管理本级用户和下级地调管理员, 并将自身权限按需分配给新用户, 地调、县调、电厂等用户以此类推, 逐级授权, 即上级调度机构设置单个具有最大权限集的管理员, 系统通过该管理员进行同级用户或下级管理员授权。这种方式的特点是授权方式一致, 上级权限集大于等于下级权限集。一方面可以保证授权过程的有序性和完整性, 另一方面可以保证系统添加或更新模块时, 各级用户均通过统一入口获得操作权限。

2 关键技术实现

作为一体化管理系统的中心线, 权限管理和控制的实现取决于控制流程设计和基础数据支持设计等关键环节, 下面从数据库、数据结构、可扩展性及数据缓存等环节重点阐述权限设计实现的关键技术。

2.1 一体化权限管理数据库表设计

一体化管理系统分级用户权限方案以角色和特殊用户为载体给用户分配操作页面的权限, 由此可以抽象出数据库设计[10,11]的4个实体 (数据库表) :用户、角色、权限、页面。4个实体两两间均存在多对多关系, 附设一个权限映射实体完成它们之间的交互。分级用户权限方案主要数据表实体—联系 (E-R) 图见图2。图中:PK为主键;FK为外键;m∶n为实体间联系 (一对一、一对多、多对多) 。

2.2 采用邻接表存储调度机构信息

省地县一体化管理模式中电厂并网方式和调度关系复杂, 如何存储调度机构间的关系以快速索引和遍历上下级调度机构, 灵活处理辖区范围数据信息和生产业务, 是分级用户权限方案实现高效流程控制和信息统一管理的基础。

省地县一体化管理模式中各调度机构 (除省调) 都受控于一个直接上级调度机构, 同时管理多个下级调度机构 (除电厂) , 调度关系呈一对多的层次特点。由此, 以各调度机构为结点将该模式抽象为倒置的树形结构。其中, 省调是顶级调度机构, 是树的根结点, 其下级调度机构地调和县调分别是根结点的一级和二级子树, 电厂没有下级, 是树的叶结点。

为快速索引和遍历上下级调度机构信息, 降低调度关系变更和扩展的复杂度, 采用邻接表存储树形调度机构信息, 实现方式如图3所示。邻接表为省地县一体化管理模式树中每个调度机构分别建立一个单链表, 各单链表以对应调度机构信息为头结点, 下级调度机构信息为表结点组建。最后邻接表将各单链表的头结点顺序存入可变长数组中, 以实现快速遍历和检索。

应用过程中用户通过邻接表头结点中的链域 (UpDept) 和后续表结点获取上下级调度机构信息, 便于提高索引和遍历速度;新增调度机构时只需在数组尾部添加新结点, 并设置下级调度机构链表即可, 为调度关系的变更和扩展提供了有效支持。

2.3 通用权限预定义方式实现权限自动扩展设计

一体化管理系统中, 不同的业务模块所包含的操作方式和操作层次各不相同, 如生产数据采集模块包含查看、修改、保存操作, 基础资料管理模块包含资料查询、修改、审核和保存操作, 而计划管理模块包含计划查看、制作、上传、审核、审批等操作, 同时这些模块的操作方式可能会随着需求变化发生改变, 因此需要系统设计过程中保证权限的自动扩展[12,13]。

采用权限预定义方式实现权限的统一操作和自动扩展, 根据1.1节中的内容将功能模块的操作分为两类:查看和修改。系统实现时直接定义canEnter () 方法表示查看权限, 而通过预定义canEdit1 () , canEdit2 () , …, canEditn () 等多个抽象方法, 对应于不同的修改操作, 授权或新增权限时各功能模块只需根据自身需求依次实现相关修改业务即可达到权限控制的自动扩展, 如图4所示。该设计方式将修改操作抽象成统一的表现形式, 使授权建立在抽象的权限分类基础上, 便于应用时通过统一的方法进行权限控制, 从而实现了权限的自动扩展。

2.4 面向频繁更新的用户权限缓存同步机制

新电厂或设备的不断投产、新功能的不断投入、调度机构人员职能调整、电厂人员的频繁流动等会导致用户信息和权限分配结果的频繁更新, 采用缓存方式可以降低数据库访问“瓶颈”限制, 提高一体化管理系统运行速度, 然而需保持缓存与数据库一致。本文系统借鉴经典的读者写者模型[14]实现面向频繁更新的用户权限缓存同步机制。

系统运行时, 一方面多个客户端可通过数据读取进程同时读取缓存, 另一方面服务器端缓存更新进程执行缓存写操作, 将更新的用户权限信息写入缓存。客户端数据读取进程和服务器端缓存更新进程可分别抽象为读者写者模型中的读者和写者。为避免读者过多时写者长期等待, 要求读者和写者按时间段轮转方式互斥访问缓存。实现方式如下。

步骤1:启动服务器, 自动加载缓存, 开启计时器。

步骤2:计时器到达T前, 数据读取进程申请读写互斥锁读取缓存, 读写进程计数器Cread统计访问缓存的数据读取进程个数, 此时缓存更新进程被锁定。

步骤3:计时器达到T后, 禁止启动新的数据读取进程, Cread为0时释放读写互斥锁。

步骤4:缓存更新进程申请读写互斥锁更新缓存;更新完成后重新开始计时。

步骤5:重复步骤2至4, 即可实现缓存同步。

缓存更新同步机制的伪代码如图5所示。

3 工程应用

分级用户权限方案已成功应用到云南电网小电省地县一体化调度管理系统中, 其设计见图6。

该系统是云南电网科技革新的重点项目, 主要实现全网省地县电源结构的动态分类统计、电站年月日计划整合、实时数据信息采集等管理工作, 包含对16个地调122个县区所辖范围内1 600多座电厂的分级管理。各级调度机构和电厂用户均通过该系统实现数据交互和信息沟通, 如图6所示。方案引入角色和页面进行授权管理, 同时允许特殊用户直接授权, 既解决了潜在的“角色泛滥”问题, 又细化了权限控制粒度;另外, 采用分级方式管理用户权限和调度机构信息, 有效保障了授权管理的有序性和系统信息的安全性。系统自2010年投运以来, 经历了多次业务功能扩展和调度关系重组, 本文分级用户权限方案以其灵活的扩展方式、方便的管理和分配方式、安全的流程控制有效保障了系统的安全运行。

4 结语

VDP系统用户角色与权限设计 篇9

本项目即“新疆维吾尔自治区职业学校数据信息平台 (简称VDP) , 由新疆维吾尔自治区职教办职业教育协调处根据业务工作的迫切需要而提出, 旨在使我区职业院校与政府职教管理部门能摆脱半手工操作模式, 提高工作效率[1];信息管理条理化、科学化, 方便管理部门快速实现准确的查询与统计;经过规范工作流程与信息的不断积累, 为我区职业教育管理工作提供数据基础, 辅助领导决策[4]。

2 角色与类的设计

角色访问控制 (Role—Based Access Control, RBAC) 模型指出, 角色是中介, 将权限授予角色, 用户通过分配角色, 从而得到对客体资源的操作权限授权[3]。而在本系统中, 系统管理员具有系统最高级别的权限, 实行信息的全局管理与数据维护工作。普通用户由系统管理员分配权限, 在角色权限范围内进行访问与操作。

2.1 角色设计

角色是一组用户的集合, 具有指定的权限完成特定的资源访问与操作行为。为对有相似权限的用户进行分类管理, 定义了系统管理员、管理员、用户、访客等角色。角色具有上下级关系, 系统管理员通过角色授权分配权限资源, 那么, 下级角色的权限范围只能在上级权限范围实行进行授权操作。

角色从属于编码级别, 角色管理两个部分, 一个是菜单功能权限, 和报表内容权限。角色报表权限不同于编码内定权限, 一旦赋予角色相关报表的权限, 则本角色可以跨越编码级别对属于本角色的报表直接管理。但系统会给出提示, 并记录日志。

本系统初步要求建立几个以下角色并赋予相关功能和报表管理范围。根据实际情况予以改变这些默认的角色。

2.2 类的设计

角色控制Role Controller依据需求设计相应功能方法, 主要代码如下所示:

3 权限设计与实现

3.1 权限要求

本系统的权限要求分为资源和功能两个部分, 资源采用管理具体到报表方式, 而功能则根据菜单来定义, 关于审批的要求具体如下:

A1A2根级权限, 可以统计查询属于它之下的所有编码范围报表信息。

B1B2B3B4属于教育管理机构级别, 可以查询统计属于本编码范围之下的任何学校报表信息。

C1C2C3C4C5C6属于终端级权限, 只可查询审批统计本学校内的所有报表信息。

3.2 权限设计

根据访问控制[2]要求, 在数据库中设计模块表、功能表和角色表等三类表。本系统按照组织机构、角色、权限三个部分设计如下:

(1) 组织机构:根据新疆的行政区划, 涉及15个地州、200多所职业院校。

(2) 角色:超级管理员、数据审核员 (自治区级) 、地州管理员、院校领导、院校管理员、院校填报员。

(3) 权限:对报表的下发、填写、功能菜单的选择等。

设计原理:首先创建根节点组织结构名称, 然后添加子节点为各个院校名称, 再把相关角色的用户分配到组织机构, 并为每个用户指定角色, 由角色和组织机构来确定用户的操作权限。

3.3 用户角色权限实现

权限控制Manage Controller依据需求设计相应功能方法如下:

实现后的主要页面如图1—图4所示。

4 结语

本文介绍了通过组织机构节点控制, 分配角色的用户分配到组织机构, 并为每个用户指定角色, 最后由角色和组织机构来确定用户的操作权限设计方法[5]。最终实现了系统管理员、教师用户、院校管理员、领导用户、地州管理员、数据审核员等几种角色的编码及菜单权限分配。符合VDP系统角色与权限的设计需求, 为整个系统的设计实现奠定了基础。

摘要：针对VDP系统中的用户、角色、权限访问控制的问题, 提出了一种基于编码的角色访问控制和用户权限设计的方法。利用角色访问控制技术可以有效地实现用户访问权限的动态管理, 取得了较好的效果。

关键词：角色,权限,设计

参考文献

[1]李忠雄, 唐雪梅.基于C#.NET的学生信息管理系统设计与实现[J].电脑与电信, 2011, 7:52-53.

[2]张锐, 张建林, 孙国忠.多业务系统的统一认证授权研究与设计[J].计算机工程与设计, 2009, 30 (8) :1826-1828.

[3]朱一群.基于用户信任的动态多级访问控制模型[J].计算机工程, 2011, 37 (23) :129-130.

[4]柳胜.性能测试从零开始:loadrunner入门[M].电子工业出版社, 2008:16-34