权限管理功能设计

权限管理功能设计（精选9篇）

权限管理功能设计 篇1

著作权属 重庆正睿科技有限公司所有 Copyright© 正睿保留全部权利 本文档仅内部学习交流使用，未经书面许可禁止复制、转载或对外发布

更多资料请访问正睿官方网站

VMware权限管理功能配置

一，权限管理功能配置方法；

1，在清单界面选择“用户和组”，添加一个新用户，输入新用户名和密码，创建。

著作权属 重庆正睿科技有限公司所有 Copyright© 正睿保留全部权利 本文档仅内部学习交流使用，未经书面许可禁止复制、转载或对外发布

更多资料请访问正睿官方网站

著作权属 重庆正睿科技有限公司所有 Copyright© 正睿保留全部权利 本文档仅内部学习交流使用，未经书面许可禁止复制、转载或对外发布

更多资料请访问正睿官方网站

2，在其中一台虚拟机上点左键，在弹出的选项卡中选择“添加权限”。

3，点“添加”，添加指定的用户，授予相应的权限。

著作权属 重庆正睿科技有限公司所有 Copyright© 正睿保留全部权利 本文档仅内部学习交流使用，未经书面许可禁止复制、转载或对外发布

更多资料请访问正睿官方网站

著作权属 重庆正睿科技有限公司所有 Copyright© 正睿保留全部权利 本文档仅内部学习交流使用，未经书面许可禁止复制、转载或对外发布

更多资料请访问正睿官方网站

著作权属 重庆正睿科技有限公司所有 Copyright© 正睿保留全部权利 本文档仅内部学习交流使用，未经书面许可禁止复制、转载或对外发布

更多资料请访问正睿官方网站

4，用新用户登录到ESX Server主机。

5，可以看出，此用户只能管理指定授权的虚拟机。

著作权属 重庆正睿科技有限公司所有 Copyright© 正睿保留全部权利 本文档仅内部学习交流使用，未经书面许可禁止复制、转载或对外发布

更多资料请访问正睿官方网站

权限管理功能设计 篇2

在信息爆炸的今天, 数据可以说是无处不在, 并且发挥着重要的作用, 所以说数据的安全性管理就显得非常重要。本文就系统中数据的权限管理进行探讨和研究。

1 数据权限

在RBAC权限模型中是通过角色给用户分配系统的使用权限, 对数据权限也可以通过角色进行分配[1]。然而不涉及角色时, 对数据权限的管理就不能用RBAC权限模型了。为了方便有效的对数据权限进行管理, 本文将提出一个新的数据权限管理模型, 该模型会通过数据对象对系统资源数据进行管理, 并通过数据对象给用户分配数据的使用权限。对该模型设计一个独立的系统, 在该系统中将提供接口功能, 可以供其他信息系统的调用。

1.1 数据对象

什么是数据对象, 数据对象可以是某一条具体的数据, 也可以是某一类型的数据的集合。数据对象就是一个数据的集合, 这个集合是把数据按照某一性质归成一类, 集合中的元素有多有少。

那么模型中为什么要引入数据对象呢, 如果数据量非常大时, 对数据的权限都是一条一条进行管理, 这个工作量是非常大的, 也非常的繁琐, 效率也非常低。为了有效快捷的管理数据, 本文引入了数据对象, 通过定义不同的数据对象, 不仅方便数据的管理, 还可以对用户分配数据对象的权限, 从而有效的实现对数据的权限控制。

1.2 权限规则

在实际应用中, 数据权限的设定都要依据系统的使用情况和业务需求, 不能说想怎么设置就怎么设置, 它的设置要遵循一定的规则。本文引入一个权限规则的概念, 也就说数据权限的设置都要依据权限规则去完成。

一条权限规则主要有三个组成元素, 分别是控制主体、控制客体和控制客体的操作。在本文中控制主体主要包括:用户和角色;控制客体主要是指系统中的数据对象;控制客体的操作是指对数据对象的各种操作[2]。对于一个数据对象可以定义多条权限规则, 这些规则共同决定了该数据对象的权限控制。

1.3 数据权限的类型

在本文中主要对两种类型数据的权限控制进行研究, 分别是工作流数据和非工作流数据。对工作流数据的权限控制称之为动态的权限控制, 而非工作流数据的权限控制是静态的权限控制[3]。

静态权限控制是一种被动的权限控制, 在这种控制下, 用户对数据的操作权限是按照“先设置后使用”的方式进行。对于非工作流数据来说, 数据被创建后, 就可以对该数据的权限进行设置, 比如说只有它的创建者才可以对其进行修改、查看和删除等操作, 而对于其他人, 则只有能查看和不能查看的权限。

对于工作流数据的动态权限控制, 本文采用“读者-作者”的权限管理模式:对处于工作流的数据, 后台程序会先判断该数据所处的状态以及当前状态下该数据对象的具体使用人员, 则当前状态下数据对象的使用人员就是作者, 可以对该数据对象进行修改、查看等操作, 而其他的使用人员就是读者, 对该数据对象只有查看的权限。对于没参与流程的人员来说, 对工作流中的数据对象只有能查看和不能查看的权限。

2 数据权限模型

对数据的使用权限, 可以从以下几个方面来讨论:①从个人和数据来说, 建立数据的人对该数据有修改、删除和查看权限, 对于其他人则是对该数据是否有查看权限[4]。②这些数据的使用权限是由系统用户当前的角色决定的。③这些数据的使用权限要根据当前人所在的部门机构来决定[5]。根据上述情况可以建立一个新的数据权限模型, 下面图1就是本文所建立的数据权限模型。

在该模型中, 可以通过定义不同的数据对象对系统中的数据资源进行分类, 方便对数据的有效管理;同时还提供两种权限类型, 分别用于对工作流数据和非工作流数据的权限控制;对于数据的使用对象, 可以通过组织机构、角色和用户进行有效的管理。利用该模型, 通过设置用户对数据对象的权限, 从而实现用户对数据的修改、查看和删除等操作的权限控制。

3 数据库和程序的设计

由上文可知本文建立的数据权限管理模型在理论上是可以有效的实现数据的权限控制, 为了更有力的说明这一点, 本文对该模型设计一个独立的系统, 以该系统说明本文提出模型的可行性, 下面是对该系统进行的初步设计。

3.1 数据库的设计根据该数据权限管理模型, 本文设计的数据库的主要表和字段有:

组织机构表 (Organ ID, Organ Name, Parent Organ ID) ;用户表 (User ID, User Name, Login Name, Pass Word, Organ ID) ;角色表 (Role ID, Role Name) ;权限表 (Function ID, Function Name) ;数据对象表 (DObject ID, DObject Name) ;角色用户表 (ID, Role ID User ID) ;数据对象用户表 (ID, DObject ID, User ID) ;数据对象角色表 (ID, DObject ID, Role ID) ;数据对象权限表 (ID, DObject ID, Function ID) 。

3.2 程序的设计类图

根据数据权限管理的模型以及其数据库的设计, 本文对该模型在程序上的实现也做了初步的设计, 该系统提高程序接口[6], 方便其他信息系统的调用。该模型所对应的类图如图2所示。

4 结束语

本文为解决RBAC权限管理模型在数据权限管理方面的不足, 建立了一个新的数据权限管理模型。并对此模型进行了初步的设计, 该系统还提供接口功能, 方便其他信息系统使用该数据权限管理系统。在实际应用中, 如果把该模型和RBAC权限管理模型结合在一起, 那么对系统数据的权限管理会更加的严谨, 系统也更加的安全。

摘要：本文对数据权限进行逐步深入的分析, 提出了利用定义数据对象对系统数据资源进行分类管理, 通过定义数据对象的权限规则确定该数据对象的权限, 把数据分为工作流数据和非工作流数据得出动态和静态权限控制方式, 最后建立了数据权限管理模型。针对该模型的系统实现, 对其数据库进行了设计, 对模型内的类以及类之间的关系进行了初步的设计。

关键词：数据权限,权限规则,静态权限控制,动态权限控制

参考文献

[1]饶文碧, 陈丹丹, 王闯.基于RBAC的权限管理系统的设计与实现[J].计算机与数字工程, 2008, 5:100-103.

[2]王莉娟, 郭培辉.PLM系统中数据权限控制研究[J].电子设计工程, 2011, 19 (3) :131-133.

[3]霍晓丽, 卢正鼎.基于工作流的复合数据安全技术[J].计算机应用, 2005, 25:82-85.

[4]滑雪, 王昊.基于角色的RBAC模型在知识库管理系统中的应用[J].计算机时代, 2007, 11:54-55.

[5]王少华, 施庆平.商业自动化系统的多用户权限控制[J].商场现代化, 2005, 453:21-22.

权限管理功能设计 篇3

关键词:RBAC 角色 权限 C#.NET

中图分类号:G203 文献标识码:B 文章编号:1673-8454(2009)19-0042-02

一、RBAC基本概念和模型

基于角色的访问控制(Role-Based Access Control,简称RBAC)已经成为解决管理信息系统的统一资源访问控制的有效方法,它替代了传统的自主型访问控制和强制访问控制方法。在RBAC中,权限与角色,角色与用户之间通过联结的关系,从而产生用户的权限。这极大地简化了系统的管理权限。RBAC两大特征是:减小授权管理的复杂性,降低管理开销;灵活地支持企业或组织的安全策略,并对系统的变化有很大的伸缩性。

信息系统中的用户、角色、权限及系统资源的基本概念如下:

(1)用户(User):与角色相关,用户要拥有对某种资源的权限,必须通过角色去关联。

(2)角色(Role):可以操作某些资源的权限集合。通过给用户赋予不同的角色,对成员的多职能进行表达,提供约束用户不同权限范围的依据。角色作为用户与权限的代理层,定义权限和用户的关系,所有的授权应该给予角色而不是直接给用户。

(3)权限(Permission):是指与资源相联系的权限。权限是绑定在特定的资源实例上的,比如在内容管理系统(CMS),有“文章的发布权限”,这就表明,该权限是一个发布权限,而且是针对文章这种资源的一种发布权限。权限包括系统定义权限和用户自定义权限。用户自定义权限之间可以指定排斥和包含关系(如:发布、修改、删除、管理四个权限,管理权限包含前三种权限)。

(4)资源(Resource):就是信息系统的资源,比如新闻、文档等各种可以被提供给用户访问的对象。系统资源是一个树形的结构,任何一个节点都是一个资源,一个资源节点可以与若干指定权限类别相关,可定义是否将其权限应用于子节点。

如图1所示,通过一定的约束关系及用户的角色定义、角色的权限赋值,实现用户对数据和资源的访问权限。一个用户是一个人或一个自治的代理(agent),一个角色是一项在组织中的工作功能或工作头衔。而权限是对系统中一个或多个对象(object)的特定访问模式的许可或执行某些动作的特权。如果x≥y,那么角色x就继承了角色y的权限,x的成员也意味着是y的成员。每次会话(session)把一个用户和可能的许多角色联系起来。一个用户可以有一个或多个角色,一个角色可以有许多用户。类似地,一个角色可以有多个权限,同一个权限可以被指派给多个角色。每个会话把一个用户和可能的许多角色联系起来,一个用户在激发他或她所属角色的某些子集时,建立了一个会话,用户可用的权限是当前会话激发的所有角色权限的并集。每个会话和单个用户关联,这个关联在会话的生命期间保持常数。一个用户在同一时间可以打开多个会话,每个会话可以有不同的活动角色。会话的概念相当于传统的访问控制中主体(subject)的标记。

二、RBAC模型的数据库表设计

通过对RBAC模型的分析,可以知道RBAC引入了角色的概念,使得用户和权限分离,从而减少了权限管理的复杂度,可更加灵活地支持安全策略。同时,我们引入资源(Resource)概念,可以对权限进行分门别类,一个资源可以对应多个权限。

在数据库表设计中,我们总共引入了六个表(如图2 所示E-R图)和一个视图,分别是用户表、角色表、权限表、资源表、用户-角色表、角色-权限表及用户-角色-权限视图。

(1)用户表(User):保存用户基本信息,包括用户编号(主键pkid),用户名称,用户密码,用户所在部门等其他信息。

(2)角色表(Role):保存角色编号(主键pkid),角色名称,角色说明等信息。

(3)权限表(Permission):保存权限编号(主键pkid),权限名称,权限说明,权限所在资源等信息。

(4)资源表(Resource):保存资源名称(主键pkid),资源名称等信息。

(5)用户-角色表(User_Role):保存角色编号,角色编号,这两个字段作为表的主键。

(6)角色-权限表(Role_Permission):保存角色编号,权限编号,这两个字段作为表的主键。

(7)用户-角色-权限 (View_U_R_P)视图:创建视图是为了提高表之间的联结查询效率,视图里的一条记录反映了一个用户所对应的一个权限,当用户的角色发生改变时,他所对应的权限也发生改变。

创建视图View_U_R_P的SQL代码:

CREATE VIEW View_R_U_P

AS

SELECTrole.pkid, role.name, user_role.user_pkid, role_ permission.role_pkid, permission.name AS permission_name, role.name AS role_name, permission.resource_pkid, permission.pkid AS permission_pkid, role_permission.permission_range

FROMrole INNER JOIN role_permission ON role.pkid = role_permission.role_pkid INNER JOIN

user_role ON role.pkid=user_role.role_pkid INNER JOIN

permission ON role_permission.permission_pkid = permission.pkid

三、利用C#.NET实现信息管理系统的权限控制

通过对RBAC的模型分析和数据表定义,我们容易得到对用户操作权限进行判断的方法。用户在对信息系统的某个功能模块操作时,首先获取该功能模块所对应的权限编号(permission_pkid)和用户登录系统时创建会话(Session)的user_pkid,利用这两个值判断用户是否有权限操作。下面我们以判断用户是否有权限删除新闻为实例,利用C#.NET实现一个简单的权限控制。在用户点击“删除新闻”按钮时,我们触发服务端控件的事件(Event):

protected void ButtonDelete_Click(object sender, EventArgs e)

{

//判断是否有删除新闻权限

String permission_pkid = "10";//假设删除新闻所对应的permission_pkid为10

String user_pkid = Session[“user_pkid”].ToString;//获取用户登录后的Session中的user_pkid值

bool have_permission = Sql.PubClass.CheckSQL("select * from View_U_R_P where user_pkid=" + user_pkid + " and permission_pkid=" + permission _pkid);

if (have_permission == false)

{

Response.Write(“”);//弹出提示没有权限的对话框

}else

{

//删除新闻操作,代码略去。

}

}

在以上代码中,CheckSQL是数据库操作类SQL.PubClass中的一个成员函数,通过数据访问的封装,很大程度上简化了信息系统编程代码。函数CheckSQL返回的是布尔值(boolean),通过传入sql查询语句,判断是否有

获取到值,如果有则返回值为true,否则为 false。

四、结束语

本文就RBAC的模型进行分析,提出简单实现模型控制的方法。又因权限设计必须考虑多方面的要求,比如角色的继承、权限的互斥等,所以在模型中引入了限制(Constraints),实现一套完整的权限设计方法。

参考文献:

[1]Sandhu R S, Coyne E J, Feinstein H L, et al. Role-based access control models[J].IEEE Computer,1996,29(2):38-47.

[2]Dongwan Shin,Gail-Joon Ahn: Role-based privilege and trust management. Number 6,November 2005.

[3]贾爱华,陈定方.NET平台下基于RBAC模型的用户权限控制[J].湖北工业大学学报,2008(6).

设计师岗位职责与权限 篇4

一、岗位描述

负责业务开拓，完成所洽谈单的全套图纸及预算，做好技术交底及施工质量监督。

二、职责

1、恪守公司服务宗旨，向客户热情耐心提供咨询，充分了解客户须求。

2、编制合理的工程预算。

3、为客户装修风格定位，并签定设计合同及装修合同。

4、协助财务收取设计费或量房服务费。

5、现场勘察，直观掌握现场实况。

6、绘制图纸

7、协助材料核算、施工监理确定材料。

8、就图纸进行施工现场交底。

9、施工技术及所达效果监管。

10、沟通业主并根据客户要求及时修改补充图纸。

11、对客户进行跟踪服务，借助口碑宣传，有意识拓展业务。

三、权限

1、有权要求检查施工工艺及质量，对存在的问题有权提出返工要求。

2、有权制止违章作业。

权限管理功能设计 篇5

问题有点棘手，于是想到去MSDN上查看有哪些可以用的关于的菜单消息，我找到了两

WM_MENUCHAR,WM_MENUSELECT,WM_MENUCHAR是用来判断当有菜单项被选中时，接收到了来自键盘的按键的时候触发，WM_MENUSELECT是在菜单项选中时触发，于是我试了两个消息，发现在映射到WM_MENUSELECT的用户自定义事件中用KEYDOWN判断用户是否按下键根本没用，现在大家明白了，WM_MENUCHAR就是解决问题的关键所在。

WM_MENUCHAR消息是在当用户选中了某个菜单项时(任一个)，只是只要按下键盘上的任一个有效键，通过消息上的CHAR可以看出来，就可以触发该事件了，这样。我可以在选中某个菜单项的时候，在出来这个消息的事件里让这个菜单项的CHECKED属性变化，这样就可以让菜单保持展开状态，实现复选了。

在菜单所在窗口中定义一个用户事件，映射到系统消息PBM_MENUCHAR 叫US_MENUCHAR

在这个事件里写

int li_upper

li_upper=upperbound(myCurMenu.item)

if keydown(keyD!)and li_upper= 0 then //判断D键是否按下和是否还有下一级菜单，但是在这里keydown判断不了是否鼠标右键被按下，是因为这个消息只取键盘按键按下与否的信息，

myCurMenu.checked=not myCurMenu.checked

myCurMenu.enabled=not myCurMenu.enabled

myCurMenu.enabled=not myCurMenu.enabled

end if

myCurMenu是个全局变量，用来存放当前用户选中的菜单项，当然这需要在每个菜单项的SELECTED事件里加上一句

MyCurMenu =this

来获得当前高亮显示的菜单。

当然你也可以用API从WM_MENUCHAR消息带来的菜单句炳等去判断是哪个菜单项按下，我试了，没成功。大家可以自己试!

大致的编码就这么多，比较简单，但是没能实现用鼠标右键点选权限，只能用键盘来控制，还是有那么一点不方便。但是感觉还是比较方便实用的，欢迎大家斧正!谢谢!

飞机概念设计阶段的控制权限评估 篇6

飞机概念设计阶段的控制权限评估

所有的飞机都必须满足可控性要求.军用飞机还有额外的.机动性要求,飞机满足这些要求的能力受到其控制权限的限制.因此,在概念设计阶段的早期对候选方案的控制权限进行评估是必须的.本文给出一组简单的方法,使得设计者在对概念进行深化研究和开展详细的控制系统设计之前能够对其控制权限进行近似的评估.

作 者：张勇 ZHANG Yong 作者单位：沈阳飞机设计研究所,辽宁,沈阳,110035刊 名：飞机设计英文刊名：AIRCRAFT DESIGN年，卷(期)：200828(5)分类号：V221+.8关键词：控制能力 控制权限 概念设计 飞机 评估

权限管理功能设计 篇7

随着Internet网络技术的飞速发展, B/S体系结构因其分布性强、操作方便, 可扩展性好, 被大量应用于各种管理软件, 是当今主流的发展方向。随之而来的B/S结构Web信息系统的安全问题越来越受到人们的重视, 健壮有效的安全管理机制是合法地使用信息, 防止非法获得信息或破坏信息的基本保障。

应用级的安全访问控制策略主要有以下三种:自主访问控制 (DAC) 、强制访问控制 (MAC) 和基于角色的访问控制 (RBAC) [1]。

(1) 自主访问控制 (DAC) :允许主体将其拥有的访问客体的权限授予给其他的主体, 并可自主的收回授权。这种访问控制策略安全级别低, 主体的权限过大, 可能会导致一系列安全问题[2]。

(2) 强制访问控制 (MAC) :系统将主体和客体分级, 当主体访问客体时, 系统对两者的级别进行比较以确定主体是否可以访问客体。MAC规则非常严格, 应用领域比较窄, 一般只用于军事或政府等具有明显等级观念的行业或领域[3]。

(3) 基于角色的访问控制 (RBAC) :是目前最为流行的访问控制策略, 它在用户和权限之间引入“角色”的概念, 使得授权管理变得灵活、简单。

本文针对第三种访问控制策略, 在基于角色的访问控制 (RBAC) 基础上进行通用、动态权限管理模型的设计与实现。

1 模型设计

本文所述的权限管理模型如图1 所示。

图1 所示的权限管理模型中机构部门下面包含人员、账号组、角色。人员与账号关联, 人员只有拥有了账号才能登录系统办理业务, 一个人员可能关联多个账号, 但一个账号只能属于一个具体人员, 人员和账号之间是1 对多的关系。办理业务时记录的是操作人员的账号信息而不是人员信息。

为了更好的管理账号, 模型中把功能类似的账号归结到账号组。一个账号可以属于多个账号组, 一个账号组可以包含多个账号, 账号和账号组之间是多对多的关系。

在账号、账号组和权限之间引入了角色的概念[4], 权限不直接赋予账号或账号组, 而是给每一个账号或账号组分配合适的角色, 为每一个角色分配特定的权限, 账号、账号组与角色对应, 而角色与权限对应, 角色作为一个桥梁, 沟通于账号和权限之间。账号或账号组只有通过角色才能享有该角色所对应的权限, 从而访问相应的权限资源。一个账号或账号组可以被赋予多个角色, 一个角色也可以被赋予多个账号或账号组, 角色与账号、账号组之间是多对多的关系;一旦账号属于了某个账号组, 那么该账号间接的继承了该账号组所拥有的角色。同样, 一个角色可以拥有多项权限, 一个权限可以分配给多个角色, 角色和权限之间是多对多的关系。

模型中权限资源包括菜单权限、动作权限和数据权限。菜单权限指系统拥有的功能模块操作菜单;动作权限指某个页面上的具体操作按钮;数据权限指页面上显示的业务数据。

除此之外, 角色之间、权限之间、角色和权限之间可以定义一些关系, 比如继承等层次性关系。也可以按需要定义各种约束条件, 比如定义两个角色为互斥角色 (即这两个角色不能分配给同一个账号或账号组) 。

上述权限管理模型通过对角色的授权来控制用户对系统资源的访问, 实现了用户与系统权限的逻辑分离, 极大的方便了权限管理[5,6]。例如, 如果一个用户的职位发生了变化, 只要将该用户在该职位拥有的账号从当前的角色中去掉, 加入代表新职务或新任务的角色即可, 角色/权限之间的变化比角色/账号关系之间的变化相对要慢得多[7]。

2 系统设计

2.1 权限管理模型的数据库设计

本模型中采用oracle数据库, 主要涉及机构表、人员表、账号表、账号组表、角色表、权限资源表、数据权限表、账号-账号组关联表、账号-角色关联表、账号组-角色关联表、角色-权限关联表。

(1) 机构表 (Organization) 记录机构的基本信息, 表中机构类型字段记录该机构性质是机构还是部门。

(2) 人员表 (Person) 记录人员的基本信息, 表中有organization_id记录该人员所属的机构。

(3) 账号表 (Account) 记录账号的基本信息, 表中有person_id记录该账号属于哪个具体的人员。

(4) 账号组表 (Account Group) 记录账号组的基本信息。

(5) 角色表 (Role) 记录系统中的角色信息, 根据实际情况, 划分角色。

(6) 权限资源表 (Authority Resource) 记录菜单权限、动作权限、数据权限的基本信息。由于权限之间存在等级关系, 在权限资源表中增加了parent_id字段指向一个权限的父权限, 权限和父权限之间是多对一的关联关系。表中增加了权限类型区分菜单权限、动作权限和数据权限。

(7) 数据规则表 (Data Rule) 记录数据权限的规则信息, 比如数据权限操作的表名、过滤数据where条件等。表中有parent_id字段指向权限资源表中与之对应的数据权限基本信息。

(8) 账号-账号组关联表 (Account_Group) 、账号-角色关联表 (Account_Role) 、账号组-角色关联表 ( Group_Role ) 、 角色- 权限关联表 ( Role_Authority) 分别记录账号与账号组、账号与角色、账号组与角色和角色与权限之间的关联关系。

2.2 功能模块的设计

本模型主要涉及六大模块:

(1) 机构管理模块:完成机构信息的添加、删除、修改。

(2) 人员管理模块:完成人员信息的添加、删除、修改。在添加人员时可以为该人员分配账号。

(3) 账号管理模块:完成账号的添加、删除、修改、为账号分配角色、为账号分配账号组。在添加账号时必须为该账号指定对应的人员。

(4) 账号组管理模块:完成账号组的添加、删除、修改、为账号组分配账号、为账号组分配角色。一旦为账号组分配了角色, 那么账号组包含的账号都继承了这些角色。

(5) 角色管理模块:主要完成角色的添加、删除、修改、为角色分配权限资源。角色包含的账号、账号组可以访问角色所分配的权限资源。

(6) 权限资源管理模块:主要完成菜单权限、动作权限和数据权限的添加、删除、修改。本模型中, 权限是分层次的, 通常以权限资源树的形式存在。初始的权限资源树包括权限根节点、菜单权限、动作权限、数据权限, 这四个节点只能被编辑不能删除, 权限根节点是菜单权限、动作权限、数据权限的父节点, 以后添加的所有权限资源只能作为菜单权限、动作权限和数据权限的子节点。菜单权限、动作权限添加、编辑页面相同, 如图2 所示。

如图2 所示的菜单、动作权限添加页面, 上级资源根据权限资源树中当前选择的节点自动填充;资源编码是由上级资源编码+“.”+当前输入的编码组成分段式的资源编码, 这种格式的编码可以快速判断该权限资源所处的层级;排序号表示该权限资源在权限资源树中显示的顺序;URL表示该权限资源对应的url访问地址, 通常菜单资源才需要填写此属性, 动作资源不需要填写。

数据权限添加页面与菜单权限、动作权限不同, 数据权限添加页面上半部分是数据权限的基本信息区, 下半部分是数据权限规则信息编辑区。如图3所示。

图3 所示数据权限添加页面, 数据权限规则是指sql语句中的where条件, where条件有的复杂有的简单, 所以数据权限规则信息编辑区控件是动态生成的。实体下拉列表框列出了所有hibernate中配置的与数据库表相对应的实体名称;从实体下拉列表框中选择一个实体名称, 属性下拉列表框中列出了该实体包含的所有属性信息, 这些属性信息与数据库表中的字段对应;属性下拉列表框右边是运算符列表框, 包括>、>=、=、<=、<、like等运算符;运算符列表框右边是属性值编辑框, 填写参与数据规则运算的属性值信息;属性值编辑框右边是属性类型框, 属性类型框是只读的, 当属性列表框中选择了一个属性后, 属性所属的类型 (String、Date、Long等) 自动出现在属性类型框中, 确定属性类型是为了方便进行数据规则的计算和属性值的填写;属性类型框右边是关联关系列表框, 包括or、and两种, 用于连接下一个条件的关联关系;点击“加条件”按钮, 规则信息编辑区动态生成一行条件编辑控件;点击“加组”按钮, 页面自动生成组编辑区域, 即图3 中黑线框包括的区域。组内的条件系统自动的用括号括起来。组内还可以继续加组、加条件, 从而形成复杂的数据权限规则。数据权限规则编辑完成后, 点击图3 中的“测试”按钮, 系统根据选择的实体及设置的条件组成hql语句运行, 如果组成的hql语句没有语法错误, 系统能够执行则返回“测试成功”;如果hql语句系统无法执行, 则返回“测试失败”。对于测试成功的数据规则点击页面中的“保存”按钮, 保存数据权限。数据权限分两张表保存, 一张是权限资源表用于保存数据权限的基本信息;一张是数据规则表用来保存数据权限的规则信息, 包括该数据权限涉及的实体中文名、英文名、过滤数据的where条件。过滤数据的where条件格式为:实体名.属性名+计算规则, 图3 中数据权限表记录的where条件:

account.create_time>to_date ('2010-10-10') and (account.name like ' 刘%' or account.update_time<=to_date ('2015-08-20') ) and account.version =1

在过滤数据的where条件中记录实体名.属性名目的是为了方便把数据权限添加到业务查询语句中。通常业务查询语句中为表起别名, 把数据权限中的过滤数据where条件拼接到业务查询语句中, 用业务查询语句中的别名替换数据权限中的实体名轻松实现数据权限与业务查询语句的融合。

3 权限控制技术实现

本模型在Java平台上借助于Hibernate来实现。设计数据库, 在系统中生成持久化类和数据库表之间的映射。

登录系统时根据当前登录账号所属的角色、账号组 (账号可能不是直接属于某个角色, 而是通过属于某些账号组间接属于账号组所属的角色) 获取一级菜单权限、动作权限和数据权限保存在session中。

菜单权限:从session中获取一级菜单权限, 动态生成主页面。点击主页面中的一级菜单进入模块内部操作时, 根据一级菜单ID、角色、账号组获取指定一级菜单下具有访问权限的所有子菜单, 形成具有访问权限的子菜单树。如果登录账号拥有操作某一功能的权限, 该功能菜单就在子菜单树中显示。否则, 该功能菜单不会在子菜单树中显示, 用户也就不能操作没有权限的功能, 从而动态的完成菜单模块级别的权限控制。

动作权限:通过自定义标签来实现。点击子菜单树中的子菜单, 由子菜单的URL进行页面跳转, 根据子菜单ID和session中保存的动作权限由自定义标签动态生成页面上的功能按钮。如果登录账号有此菜单模块下某一功能按钮的操作权限, 则此功能按钮就显示在页面上供用户操作;如果没有某一功能按钮的操作权限, 则此功能按钮就不显示在页面上, 用户也就无法进行该操作, 从而动态的完成页面动作按钮级别的权限控制。

数据权限:通过Hibernate的拦截器来实现。点击子菜单树中的子菜单, 由子菜单的URL进行页面跳转, 根据子菜单ID和session中保存的数据权限, 利用Hibernate的拦截器技术拦截查询当前页面数据的sql, 为sql添加数据权限中的where条件生成页面上的数据信息。用户只能看到自己权限范围内的数据, 从而动态的完成数据级别的权限控制。

对于数据权限的实现比较复杂, 如果直接在每个模块的查询语句中添加, 一方面代码编写工作量太大, 维护性差;另一方面每个模块涉及的查询语句复杂多样, 有的模块使用hql语言编写, 有的模块使用sql语言编写, 用一套添加数据权限的代码无法实现。本模型中使用Hibernate拦截器为各模块的查询语句添加数据权限。定义Hibernate Query Interceptor类继承hibernate的Empty Interceptor, 在Hibernate QueryInterceptor类中重写public String on Prepare Statement (String sql) 方法。此方法的参数sql是hibernate解析后的可以被数据库直接执行的sql语句, 无论在模块中使用的是hql语言还是sql语言, 这里都被hibernate解析成统一格式的sql语句。本模型在on Prepare Statement方法中获取session中保存的数据权限, 如果数据权限中包含的表名与sql中的表名相同, 则获取sql中该表名的别名, 用别名替换数据权限中where条件的实体名, 把数据权限添加到sql中。替换时如果原sql包含where条件, 则直接把数据权限中的where条件添加到原sql中第一个where条件之前, 如果添加到where条件后面需要判断原sql中是否有order排序、group分组等;如果原sql中不包含where条件, 则利用正则表达式分离出原sql中的order排序、group分组把数据权限中的where条件加入sql并拼接上原来的order排序、group分组。注意原sql可能是嵌套的复杂查询语句, 上述判断要逐层进行判断拼接数据权限。On PrepareStatement返回添加了数据权限的新sql语句交给系统执行, 从而达到进行数据权限控制的目的。

4 结语

RBAC是目前公认的解决大型企业统一资源访问控制的有效方法[8]。本文针对B/S结构Web系统特点, 设计了一种基于RBAC的通用、动态权限管理模型。RBAC模型的许多实现方案中权限控制粒度是到页面级别的, 而本文设计的模型权限控制粒度到页面上的功能按钮级别和数据权限级别, 克服了传统的RBAC权限控制的粒度过大, 难以精确地区分不同角色的权限、不方便使用的缺点。本模型中为账号分配角色而不是为实际人员分配角色。为了便于对同类账号进行管理提出了账号组的概念, 有了账号组可以快速的为组内的多个账号分配角色或撤销角色, 进而获取角色具有的权限。模型中的账号、账号组、角色、权限可以根据实际的需要动态的添加和删除, 具有较强的灵活性和动态性。

参考文献

[1]甘剑.基于角色的访问机制的研究及应用[D].中南大学, 2010.

[2]刘晓玲, 郭龙.基于RBAC的用户权限管理的研究与实现[J].电脑知识与技术, 2013, 3 (07) :1487-1490.

[3]杨阳.基于角色的访问控制改进模型研究与应用[D].西安科技大学, 2014.

[4]韩金松.基于角色权限的投票测评系统的设计与实现[J].软件, 2013, 34 (9) :47-48.

[5]赵凯, 汪卫平.数字化校园中基于角色的权限控制[J].软件, 2014, 35 (11) :22-24.

[6]王宇飞.基于Acegi的通用权限框架的设计与实现[J].软件, 2013, 34 (7) :46-50.

权限管理功能设计 篇8

关键词：兼容性；通用性：客户端；安全

0引言

数字版权管理技术(DRaM：Digital Rights Management)是用于管理用户对数字内容(digital content)的使用方式，实现保护数字内容免遭未经授权的使用或复制的方法的整体机制。在2001年1月，美国麻省理工学院在(Technology Review)杂志上将DRM技术评选为改变未来世界的10大创新技术之一。目前DRM的应用研究中，美国的InterTrust是最早进行DRM技术研究和开发的公司。而其它公司如微软、Adobe,RealNetworks等也都提出了较为成熟的投入实际应用的方案。

目前应用的DRM系统从本质上说都属于独立的系统，因为它们都是由各著名软硬件制造商针对自己的某个平台或某个应用而设计的，因而它们之间不能互相兼容，数字信息产品只限于在某个特定环境平台下使用，使得用户不能灵活地合法使用其数字信息产品。

面对这个问题。国际标准组织通过制定统一的数字权限语言如ODRL来实现对数字使用权限的统—描述。但是需要指出的是，ODRL并不能完全解决DRM系统通用性问题，因为面对不同的类型的文件以及同一文件的不同应用软硬件环境，支持ODRL语言的DRM系统仍不具备通用性。为了解决这个问题，本文提出了一种新型的通用数字权限管理客户端模型，它可以解决DRM系统的客户端通用性问题，主要的思路是通过对数字信息使用的监控来实现数字权限的管理。

1数字版权管理技术

1.1DRM系统的架构

目前大多数DRM系统都采用如图1所示的系统架构设计。

从图1中可以看出，DRM系统有四个参与者，分别是：消费者；数字内容提供者：主要是由数字内容的版权所有者组成，他们希望通过DRM系统来保护他们版权；分发者：主要是由网络服务商组成，他们提供不同的数字内容分发渠道。如网上零售和网上影院等，通过这些渠道将数字内容提供者所提供的数字内容分发至消费者；净室：主要是解决涉及到资金处理过程中的事务，如：它负责向消费者收取费用，并将费用按协议分给数字内容提供商和分发者，并在确认消费者已支付费用的情况下，向消费者发放数字使用许可证书。

上述的DRM系统的主要工作过程是，首先由数字内容提供者将其提供的数字内容进行编码和加密后打包，然后提供给分发者，由分发者向消费者提供数字内容的相关信息。当消费者决定购买该数字信息产品后，他通过向净室提出请求并向它支付相关费用；净室在得到消费者支付的费用后，将费用分发至数字内容提供者和分发者，并将数字内容使用许可证发送到消费者；消费者即可凭借许可证合法使用对应的数字信息内容。

1.2DRM系统的关键技术

DRM系统的关键技术一共有以下几种：

(1)DRM信任模型

DRM系统中的信任模型与一般的安全信任模型不同，它不是简单地针对几个参与方进行身份认证和交互的信息加密。DRaM的信任模型必须要保证当消费者获得加密的信息产品和许可证书之后，可以按照证书要求的方式来使用数字信息，因此它的信任模型不仅仅只是对用户身份的认证和数字信息的加密，还必须要实现监控用户对数字信息的合法使用。通常DRM系统是通过硬件技术(可信计算技术)结合软件技术(加密与监控)实现。

(2)加密技术

DRM系统中的加密技术主要有：对称和非对称加密技术。对于数字信息一般采用对称加密技术，以提高数字信息的加密与解密速度；而针对个人身份认证，数字证书等方面一般采用非对称加密技术以确认各参与方的身份。除此之外，还有数字签名和数字论证等加密技术。

(3)应用环境标识与区分

由于DRaM系统对用户使用数字内容的方式有严格的限制，为了监控和防止数字内容被非法使用，数字内容的应用环境标识与区分就显得很重要，只有使用许可证确认的应用环境，数字内容的使用才能得到有效的监控。数字内容的应用环境标识与区分—般采用信任计算技术：采集应用环境特定的参数，生成应用环境标识并在每次使用数字内容时进行识别。

(4)数字水印

数字水印技术是在数字内容内插入数字的相关内容信息以及一些特殊目的的数据，这些数据与数字内容合成—体。用户难以察觉。在DIVl系统中内容提供者使用数字水印技术在提供的数字内容中插入数字内容的相关信息以及版权说明，还有使用许可说明等。

2通用型的数字权限管理客户端模型

由上文所述可知，当前DRM系统不能通用的主要原因并不是在于数字内容的提供与分发，以及许可证发放、收费流程等方面。因为DIeM系统主要的几个参与方都是利用网络进行的，所以这种架构不会造成系统通用性问题。

目前DIeM系统不能通用的主要原因在于消费者客户端。DRM系统的信任模型必须要保证消费者在得到数字内容后，按许可证的要求合法使用数字内容，因此DRM系统需要用户安装专用的客户端，系统通过客户端来监控用户对数字内容的使用。而现有DIVl系统的客户端都是某个公司针对某个应用软件如：Window media pJ，dy，Adobe reader等开发的插件，或者是针对某个类型的文件而开发出来的专用客户端，如索尼的MP3客户端，电子书客户端等。显然这种类型的客户端不仅限制了客户，同时也限制了系统的通用性，使得用户不得不在同一台设备上安装多个DRM系统，这给用户带来了不便，也造成潜在的系统冲突。为了解决通用性问题，本文利用ODP~L语言为基础进行数字权限描述，通过在消费者设备上建立统一的DRM监控进程来完成通用的DRM客户端，达到通用DRM系统的目的。

2.1通用型数字权限管理客户端模型架构

由上文所述，本文的通用型数字权限管理客户端模型如图2所示。

从图2中可以看出，通用型数字权限管理客户端模型主要由三个部分组成：DRM客户端控制进程——该进程主要的功能是对数字内容按许可证进行解码，注册数字内容信息；数字内容注册表——该数据结构主要用于注册数字内容的许可证内容以及其它相关信息；DIeM临时文件容器——主要存放控制进程生成解码后的数字内容临时文件。

通用型数字权限管理客户端模型的工作流程由以下几个步骤组成：

(1)用户将获得的数字内容和许可证提交到客户端控制进程，控制进程通过对数字内容以及许可证的校验，确认许可证

以及数字内容的合法性之后，将数字内容的相关信息和许可证存放到数字内容注册表。

(2)当用户使用数字内容时，向控制进程发出请求，控制进程首先利用注册表信息，进行应用环境识别和用户使用权限确认，然后根据许可证，对数字内容解码，将解码后的数字内容放入DRM临时文件容器。

(3)DRM客户端控制进程利用用户环境中默认的应用软件(或由用户指定)打开临时文件容器内的数字内容。用户可以开始使用数字内容，同时DRM客户端控制进程监控用户按许可证规定的方式使用文件。

2.2控制进程的监控功能实现

在DRM系统中，监控用户使用数字内容的功能十分重要，因为用户可能在打开数字内容时，采用复制等手段危害数字内容的版权。本文设计的数字权限管理客户端模型为了实现通用性，不能采用针对某个软件的插件等方式来监控用户，我们采用监控DRMll临时文件容器的方法实现对用户的监控。其主要实现模块由二个部分组成：

(1)文件系统监控模块

文件系统监控模块用于监控当前系统中打开DRM临时文件容器中的文件所对应的进程。下面以Windows XP系统平台为例加以说明。模块通过Windows内核API函数Nt-QuerySystemlnformation函数返回SYSTEM_HANDLE结构的数组，获得所有句柄，包括：文件句柄。Motex句柄，事件句柄等等。对于Window XP文件对象来说，其旬柄类型值是28，凭此可以获取当前正在打开的文件句柄，代码片断如图3所示。文件系统监控模块由文件句柄即可获得当前打开DRM临时文件容器的应用进程，从而通过对应用进程的监控，保证用户按许可证的要求使用数字内容。

(2)用户使用文件方式控制模块

用户使用文件方式监控模块的主要功能是控制用户按许可证的方式使用数字内容。它的功能实现建立在文件系统监控模块的基础之上：利用Windows钩子程序，在获知使用DRM数字内容的进程情况下，可以很容易地实现该进程对数字内容的使用控制。如禁止另存、复制、文件共享等危害数字内容版权的使用方式；同时也可以对用户使用数字内容的具体细节参数进行统计，并将其存入DRM注册表中。

3应用举例

本文以使用影音文件为例，说明本客户端模型的工作过程。

Avi文件可由Windows自带的播放器打开之外。还可以由RealPlay。影音风景等其它应用工具打开播放。采用本DRM客户端模型，用户首先在获取加密的数字内容和许可证之后，向客户端提交许可证和数字内容进行校验注册，客户端将许可证和数字内容相关信息写入注册表。当用户使用数字内容后，客户端即可根据许可证将数字内容解密后放入DRaM临时文件容器。同时调用系统默认工具(如Windows media play)，也可以由用户选择打开工具。

当用户使用本数字内容时，客户端控制进程即在系统内根据注册的数字内容名监控所有打开和使用当前数字内容的进程，并控制它们对数字内容的使用方式，从而保证用户按许可证的要求使用数字内容。

4结束语

财务支出审批权限管理制度 篇9

为规范*****商会财务管理工作中的审批行为，明确商会财务支出的内部流程及审批权限，完善健全商会内控制度，确保健康持续发展，制订本制度。第一章 审批权限

第一条 商会财务收支实行日常开支由副会长审批，大额支出，单笔支出在30万元（含）以下的，按照审批程序由副会长负责审批；单笔支出在30万元至100万元（含）的，则按照审批程序先由副会长审核，最后由会长负责批准；单笔支出在100万元以上的，由商会副秘书长办公会议决议负责审批。第二章 审批范围

第二条 财务支出具体包括费用借支、费用报帐、办公物品采购及办公室房租物业费支付等。第三章 审批要求

第三条 任何费用在发生之前都应先履行请示义务，非经副会长允许，超时间、超范围发生的费用一概不予报销。第四章 审批程序

第四条 支出审批及报销流程：经办人（填单）→主管或分管负责人签字→财务主管票据复核→副会长审批（超过副会长审批权限的按审批权限流程）→出纳付款→会计报帐。第五章 审批责任

第五条 各项财务收支审核人员应认真审核每一项收支业务，对于与实际情况不相符且违反制度规定，或有超标准、超限额开支，经办手续不齐全等问题的，均不得办理款项收支和相关手续，如遇特殊及重大问题应及时向上级反映情况。

第六条 各财务收支审批人员应在各自的审批范围内行使审批权，不得超范围、超预算审批，也不得化整为零进行审批。财务人员有权对不符合国家财经法规和商会财务制度的开支及报销凭据予以剔除。第七条 各项财务收支的经办、签字、复核和审批人员要认真履行岗位职责，严格环节把关，商会如发现有巧立名目开支，徇私情开支等，将视情节给予责任人相应处罚；如发现有营私舞弊，伪造票据等严重违规情形，对当事人将给予严厉处罚。本制度自2012年11月1日起执行。******************** 财务管理审批权限及操作规程

为规范财务借款、付款、请款和报销管理制度，加强财务管理、提高办事效率，根据国家有关法律、法规及财务制度，结合分公司的具体情况，特制订本制度。

一、暂借款、往来款制度

1、暂借款是指因业务需要的临时借款，包括差旅费及各种临时性借款。

2、往来款是指因业务需要，集团间资金划拨的款项。

3、额度审批权限：

（1）业务需要 万元以内的大额借款必须经分管副总、公司总经理审批； 万

元(含)以上的大额借款应由公司总经理及总部领导审批；个人借款原则控制在其月工资范围之内。

（2）往来性质款项划拨不论金额大小必须经总部领导审批。

4、借款程序：

（1）借款金额小于1万元

借款人应详细填写《借款审批表》，借款时应注明借款时间、事由、金额、还款时间等，部门经理应对借款内容审查证明，经财务审核后报公司总经理审批同意后方可借款。（2）借款金额大于1万元

借款人仅限部门经理以上级别，并填写《借款审批表》，借款时应注明借款时间、事由、金额、还款时间等，经财务审核、公司总经理审批同意后报公司总部加签。

5、所有暂借款必须在前账结清之后方可再借付，确因业务需要而来不及结清前账，必须向财务部经理讲明原因，经同意后方可再借付。

6、经办人必须在事务完毕一个月内凭有效原始票据报销各项暂借款项，超出一个月不结帐者，人事部有权扣发经办人工资抵偿。

二、业务请款制度

1、业务请款是指合同（协议）付款、工程结算付款、材料的采购付款等。

2、额度审批权限：业务请款按照已签订合同项下的工程进度付款及采购款支付经分管副总、公司总经理审批。签订合同的审批权限如下；（1）工程招标及发包合同： 万元以下由公司经营班子审批；万元以上（含 万

元）经公司经营班子审议后，报总部领导审批。

（2）对外采购合同： 万元以下由公司经营班子审批； 万元以上（含 万

元）经公司经营班子审议后，报公司总部审批。

（3）其他合同（设计、广告、企划、代理）： 万元由公司经营班子审批； 万

元以上（含 万元）经公司经营班子审议后，报总部领导审批。（4）对外投资、担保、对外借款合同等均需经总部审批。

3、请款程序：请款人应根据合同、协议、工程预结算书等填制《资金支付单》，经部门经理审核确认，并交预算部、分管副总、财务经理、公司总经理和总部领导审批，财务部门根据合同、发票以及公司的资金计划等情况安排付款。

4、工程的结算除应有合同或协议外，还应包括施工员、预算部、分管副总、总经理等相关人员签字的结算确认书，签字人员对工程结算金额负责。

5、材料发票、工程发票等相关发票的提供，应符合当地税务部门的规定，对不符合到当地税务机关规定的财务部门有权拒绝付款。

三、经营管理费用制度

1、经营管理费用审批权限：

（1）日常经营管理费用1万元以下由公司财务经理和总经理审批； 1万元以上

（含1万元）经公司经营班子审议后，报总部领导审批。

（2）单笔业务招待费 万元以下由公司财务经理和总经理审批；1万元以上

（1 万元）经分公司经营班子审议后，报总经理、董事长审批。（3）对外捐赠、赞助、罚没款2万元（含2万元）由分公司行政副总和常务副

总审批；2万元以上经分公司经营班子审议后，报总经理、董事长审批。

2、费用发票的要求：发票要求是税务的正式发票，内容包括日期、商品名称、单价、数量、金额，并盖有开具发票单位的发票或财务专用章。经办人必须要求开票单位如实填写发票所有内容，发票涂改、大小写不符、假发票以及未盖有财政监制章的收据一律不予报销。

3、报销费用时必须填写统一格式的《费用开支（请款）审批表》，经办人必须在每张发票背面签字确认，所有单据要按性质（如差旅费、招待费、办公费用）分类、分次、分页粘贴填制；差旅费必须分次、按出差地点分开填列，并计算好出差天数，住宿、伙食补助和市内交通费在限额内填报。费用结算单所有报销单据的张数和合计金额必须准确无误填写不得涂改，粘贴要求整齐、美观。

4、办公用品的购置：由各部门根据需要，编制计划报行政部审核汇总，按审批权限批准后，由人事行政部按计划统一购买统一报销，行政部门应建立实物帐，详细登记办公用品的进、出情况。

5、费用的核销应在事务处理完毕后三日内到财务部办理报销手续，部分属月缴费用的最长不得超过15天，费用超过一个月以上未报的原则不予报销。

四、固定资产管理制度

1、固定资产添置、租赁、转让与报废审批权限：5万元以内（含5万元）的分公司经营班子审批；5万元以上的需报董事会审批。

2、固定资产的需求必须由各部门根据实际情况提出申请，说明事由用途、数量及所需资金由部门经理提出申请，报行政部审核汇总后、由行政部负责采购计划的安排与落实。

3、固定资产的购置发票报销时按正常的审批权限和报销程序。固定资产的管理按照分公司的《财产管理制度》执行。

4、低值易耗品的采购报销流程参照固定资产的采购报销流程。一米OA组织权限操作手册 ______________公司授权管理制度

第一章 总 则

第一条、为完善__________公司（以下简称“公司”）的治理结构，强化公司对各部门及分子公司（以下统称为各部门）的统一管理，达到集中决策与适当分权的合理平衡，以满足公司管理及经营的需要，依据《中华人民共和国公司法》、公司章程及相关决议等的规定，制定本制度。第二条、本制度所称的授权，是指由公司董事会代表公司向各部门授权，部门负责人代表其部门接受授权，各部门必须在公司授权范围内依法进行经营管理活动。

第三条、各部门行使授权权限时，必须接受公司的统一领导，遵守公司的各项规章制度。

第二章 授权的范围、类别和形式

第四条、公司授权分为基本授权及特别授权两个类别：

1、基本授权是指对各部门基本业务、财务管理及人事管理的授权，经基本授权产生被授权部门的基本权限。基本授权的期限为 1 年。

2、特别授权是指对超出基本授权范围的某一特定事项或某项特殊业务的临时性授权。经特别授权产生被授权部门的特别权限。特别授权的期限在特别授权书中注明，也可为不定期，但无论定期与否最长不得超过 1 年。

第五条、公司董事会根据经营需要向各部门进行基本授权，除非对该部门的授权管理规定有特殊规定，接受公司基本授权的部门不得再向其所辖机构或个人转授权。

第六条、公司董事会根据经营需要可向各部门进行特别授权，接受特别授权的部门不得再向其所辖机构或其他个人转授权。

第七条、授权的基本形式为：

1、基本授权：由公司董事长代表董事会向各部门签发《_______ 公司对XXX 部门授权管理规定》（“XXX”为被授权部门名称，下同），被授权人为各部门负责人。

2、部门特别授权：由公司董事长代表董事会向该部门签发《_______公司对 XXX 部门特别授权书》，被授权人为各部门负责人。

3、专项事务授权：其规定详见本制度第四章第十九条的规定。

第三章 基本授权的制订、管理和变更程序

第八条、公司基本授权的范围包括：人事授权、财务授权和业务授权，分别产生被授权部门的人事权限、财务权限和业务权限。

第九条、人事授权的具体内容包括：

1、人事任免(财务部长除外)；

2、人员考评、奖惩；

3、组织架构及定岗定编；

4、员工薪酬、福利的确定；

5、人事管理制度的制订。

第十条、财务授权的具体内容包括：

1、预算编制及调整；

2、预算外支出的审批；

3、投融资业务；

4、合同付款计划的制订及审批；

5、财务管理制度的制订。

第十一条、业务授权的具体内容包括：

1、主要经营业务相关经营决策的制订；

2、对外合同的签订。

第十二条、基本授权须经公司董事会批准通过。第十三条、基本授权草案应在每个授权期间开始前 30 天报送向公司董事会，公司董事会应在 15 日内审议定稿。

第十四条、《_______公司授权管理规定》应在基本授权定稿后 5 日内完成，经公司董事长签字后加盖公章，被授权部门总经理应在授权书正本上签字确认，授权书正本由公司人事行政科负责存档保管。

第十五条、公司对各部门的基本授权应与公司各部门的定岗定编相一致。公司行政人力资源中心应制订出明确的各部门岗位职责说明书，该职责说明作为对该部门基本授权书的附件。

第十六条、公司人事行政科应在每个授权期间开始前组织各部门负责人及其他高级管理人员学习本部门的授权。

第十七条、当被授权部门发生下列情况时，公司可变更对该部门的基本授权：

1、部门与授权有关的工作岗位设置发生变更；

2、被授权人发生重大越权行为；

3、因被授权人未能正确履行授权程序造成重大经营风险；

4、其他需要变更的情况。

第十八条、基本授权的变更程序是： 由公司有关部门（工作岗位设置发生变更时为公司人事行政科，其他情况下为公司审计部）根据具体情况提出对授权的变更方案，重大变更方案报公司董事会批准，一般变更方案报公司董事长批准。变更方案批准后由公司人事行政人科据此制作出《_______公司授权变更通知书》，经公司董事长签字后加盖公章，将授权变更通知书复印本下发被授权部门。授权变更通知书作为原授权管理规定的附属文件，与原授权管理规定具有同等效力，随原授权管理规定的终止而终止。

第四章 特别授权的制订、管理和变更程序

第十九条、当公司出现以下情况时，公司总裁可以向各部门签发特别授权：

（1）在公司员工需超出基本授权对外开展业务或订立合同、协议时，经公司员工所在部门负责人申请，公司董事长可向办理该事务的公司员工、律师顾问等人员出具专项事务的《授权委托书》，被授权人为处理前述事宜的公司经办人。

（2）在公司发生诉讼或非诉讼纠纷时，为妥善处理纠纷，经公司法务部申请，公司董事长可向处理该纠纷的公司员工、律师顾问等人员出具专项事务的《授权委托书》，被授权人为处理前述事宜的公司经办人或公司聘请的处理纠纷的律师。

（3）其他需要特别授权的事项由公司董事长在授权范围内决定。

（4）办理本条上述授权时，经办部门应当依照公司制定的《_________公司印章管理办法》履行会签程序。

第二十条、公司董事长有权根据情况变化变更已签发的特别授权。公司办公室应将将授权变更通知书下发被授权部门。授权变更通知书作为原授权书的附属文件，与原授权书具有同等效力，随原授权书的终止而终止。

第二十一条、在特别授权相关事项处理结束后，被授权部门负责人应立即向公司董事长汇报授权的使用情况，该特别授权即行终止。第五章 授权的终止

第二十二条、授权因发生下列情况终止：

1、授权书中规定期限届满，如果公司董事会没有发出授权展期的通知，则授权终止；

2、授权被撤销；

3、被授权机构被撤销；

4、在授权期限内，因变更事项需要重新制发授权书的，自变更后的授权书生效之日起，原授权书终止；

5、其他需要终止的情况。

第六章 授权制度的检查与监督

第二十三条、公司法务部应当定期或不定期对被授权部门行使授权权限的情况进行检查和监督。被授权部门管理部经理有责任定期向公司法务部汇报该部门管理人员行使授权权限的实际情况。

第二十四条、公司法务部在审查中发现被授权部门有一般越权行为的，应督促该部门限期改正；有重大越权行为的，应上报公司董事长决定对其作出处分决定，该重大越权行为给公司造成严重损失的，公司有权追究其相应的经济责任。

第二十五条、前条所称“一般越权行为”是指被授权人超越授权书中的授权权限但未造成严重后果的行为；“重大越权行为”指被授权人实施了授权书中授权人声明禁止转授权的权限，或超越授权权限造成严重后果的行为。

第七章 附则 第二十六条、本制度由公司董事会负责解释。

第二十七条、本制度自董事会审议通过之日起开始实施。__________________________公司 ________年____月____日

在特别授权相关事项处理结束后，被授权部门负责人应立即向公司董事长汇报授权的使用情况，该特别授权即行终止。

授权的终止

授权因发生下列情况终止：

1、授权书中规定期限届满，如果公司董事会没有发出授权展期的通知，则授权终止；

2、授权被撤销；

3、被授权机构被撤销；

4、在授权期限内，因变更事项需要重新制发授权书的，自变更后的授权书生效之日起，原授权书终止；

5、其他需要终止的情况。

授权制度的检查与监督

公司法务部应当定期或不定期对被授权部门行使授权权限的情况进行检查和监督。被授权部门管理部经理有责任定期向公司法务部汇报该部门管理人员行使授权权限的实际情况。

公司法务部在审查中发现被授权部门有一般越权行为的，应督促该部门限期改正；有重大越权行为的，应上报公司董事长决定对其作出处分决定，该重大越权行为给公司造成严重损失的，公司有权追究其相应的经济责任。

前条所称“一般越权行为”是指被授权人超越授权书中的授权权限但未造成严重后果的行为；“重大越权行为”指被授权人实施了授权书中授权人声明禁止转授权的权限，或超越授权权限造成严重后果的行为。

附则

本制度由公司董事会负责解释。

本制度自董事会审议通过之日起开始实施。

赤峰万恒工程机械物资有限责任公司

______年____月____日

第一章 总则

第一条

为完善公司法人治理结构，进一步规范公司各类授权委托书的申请、签发、使用，有效控制授权管理法律风险，切实保障和维护公司法人财产权，根据集团公司《授权管理办法》及公司《章程》，制定本办法。

第二条

本办法作为授权管理工作指引，适用于公司总部各职能部门、各非法人分支机构或相关人员以公司名义从事的经济活动及其他各项民事法律行为的授权管理。

第二章 授权管理的原则、分类、机构

第三条

授权管理应当遵循“分级分类、合法授权，权责明晰，行使规范”的原则。

第四条

本办法所称的授权分为对内管理授权和对外代理开展经济活动的授权。

对内管理的授权由公司各项管理制度具体规定；对项目经理的授权由《项目管理手册》具体规定。

第五条

各职能部门、各非法人分支机构负责人或相关人员（以下简称“被授权人”）以公司名义行使职权或办理事务时，原则上由公司法定代表人（以下简称“授权人”）以书面的授权委托书形式，将其代表公司的权利授权其行使。

第六条

公司办公室（法务）是公司授权管理的归口部 / 16

门，在法定代表人和总法律顾问的领导下，主要履行以下职责：

（一）组织实施公司及所属机构的授权管理工作；

（二）指导公司及所属机构按授权管理工作流程开展工作；

（三）对公司及所属机构向上级单位报批的授权事项进行法律审查；

（四）制作、修订和完善公司标准授权书的格式文本，并积极推行；

（五）对公司及所属机构的授权管理工作进行监督、检查和考核。

第七条

公司总部各职能部门是授权管理的业务主管部门，根据公司部门职责分工及岗位责任说明书的相关规定，牵头组织本系统授权管理工作，主要履行如下职责：

（一）起草本部门主管的授权事项的授权书草案；

（二）按照公司相关规定，对本部门主管的授权事项组织评审，按审批权限和程序报送审批，办理授权手续等；

（三）对公司及下属单位报送审批及需要向上级单位报批的授权事项进行业务审查；

（四）指导所属单位开展本系统业务范围内的授权管理工作。

第三章 授权的分类和形式

第八条

法定代表人的授权原则上采用书面授权委托书的形式。

对于临时性、非重大事项，可以口头形式进行授权。第九条

授权委托书是公司法定代表人授权委托被授权人在授权范围内以公司或法定代表人名义行使职权或办理公司有关事务的法律文件，是被授权人的权利证明。

第十条

未经公司法定代表人授权，公司任何职能部门、各分支机构或个人不得以公司名义进行经济活动。

除特殊情况外，不得授权与公司无合法劳动关系的人员以公司名义对外进行民事活动。

第十一条

授权委托书种类

本规定所称的授权委托书包括综合和单项两类。对外经营、投标、签约等常规授权，根据需要可办理公司法人综合授权委托书（标准格式文本见附件一）。单项授权一般均需办理公司法人单项授权委托书（标准格式文本见附件二），由法定代表人和综合被授权人按相应权限进行审批。

授权委托书从形式上分为标准授权书和指定格式授权书。使用公司标准格式文本的授权书是标准授权书，使用公司以外的其他单位或个人指定的授权书文本是指定格式授权书。

无论是单项授权还是综合授权，被授权人均无转委托权。

第四章 综合授权书审批和管理

第十二条

综合授权书应当使用公司的标准授权书。综合授权书的有效期与被授权人职务任期一致，被授权人应严格按照综合授权书的规定行使权利和履行职责，并不得转委托。

第十三条

综合授权书办理流程

（一）基本流程

（二）授权事项的授权书草案由承办单位起草，授权事项没有直接承办单位的，由业务主管部门代为起草授权书草案。

（三）承办单位负责向公司业务主管部门及相关部门报送授权审批表（附件三），由业务主管部门、办公室（法务）门及其他有审批权限的机构和人员依次出具评审意见，对授权委托书进行修订和完善。公司的业务主管部门应指导承办单位按公司规定进行办理。

（四）评审人员对评审意见提出异议的，承办单位或业务主管部门应及时与原评审人员进行沟通，补充提交证据材料，交原评审人员进行二次评审。因违背法律规定、存在重大风险或其他原因不能通过评审的，不得开具授权书。

第十四条

公司设立下列机构时，根据需要对其第一负责人开具综合授权书:

（一）具有独立法人资格的子公司；

（二）不具有独立法人资格的分公司；

（三）因经营备案需要登记注册的名义分公司或子公司；

（四）根据公司批准依法成立的其它分支机构。

上述机构的变更和终止，其综合授权书相应变更或终止。

第十五条

本规定第十三条所述公司综合授权书的开具、变更或终止，公司办公室（企划）为业务主管部门，所涉机构为承办单位。授权书审批权限按照公司关于分支机构的职责和权限的相关规定执行。

第十六条

本规定第十三条所述机构的第一负责人变更的，应相应变更综合授权书的被授权人。原则上不对分支机构的部门进行单项授权。

第五章 单项授权书审批和管理

第十七条

单项授权书可采用为公司标准格式或指定格式授权书。

单项授权书可以采用固定有效期的单项授权，也可以完成一定事项为有效期的单项授权。

第十八条

单项授权书采取一事一评审、一事一授权的审批制度。单项授权事项变更、被授权人发生变更、授权期限届至以及其它特定事项发生时，应按本规定程序重新办理单项授权审批手续。

第十九条

单项授权办理程序基本流程参照第十二条规定执行。

第二十条

单项授权事项及授权管理业务主管部门

（一）承接工程项目

以公司名义承接工程项目，包括信息跟踪、项目投标、商务谈判和合同签订等，须办理单项授权书。

公司市场营销部是办理工程项目单项授权书（含区域营销授权）的业务主管部门，公司所属机构为承办单位。

该授权书的被授权人原则上应是公司总部部门经理助理级以上人员、二级单位领导班子成员及二级单位部门正职，其它人员的单项授权须经公司法定代表人单独审批。

（二）付款、收款、贷款及利息支付、资金调拨及各类保函

公司或公司所属单位以公司名义对外收款，可以办理单项授权书。

公司财务资金部是办理收款单项授权书的业务主管部门，收款的实施单位为承办单位。收款授权书审批权限适用公司相关制度规定。

收款的单项授权书的被授权人原则上必须是部门副职或项目副经理级以上人员。其它人员的单项授权须经公司法定代表人单独审批。

（三）合同签订、商务谈判、项目结算

公司或所属单位以公司名义对外签订合同和参加谈判，包括但不限于项目承包合同、分包合同、材料采购合同、对外招聘（含岗位职责说明书规定、解聘合同）、劳动合同等的谈判和签约等，可以办理合同签订和谈判的单项授权书。

公司的市场营销部、合约商务部、项目管理部（采购、劳务）和人力资源部是办理合同签订与谈判的单项授权书的业务主管部门，公司所属机构的合同签订与谈判的实施单位为承办单位。合同签订与谈判授权书审批权限适用公司相关制度规定。

合同签订与谈判的被授权人原则上必须是公司部门副职以上人员。其它人员的单项授权须经公司法定代表人单独审批。

（四）诉讼（仲裁）

公司作为当事人处理诉讼（仲裁）案件时，委托代理人代理诉讼（仲裁）的，应当办理诉讼（仲裁）授权委托书。

公司办理诉讼（仲裁）授权委托书的被授权人中至少有一名是诉讼（仲裁）发案单位的法务人员，发案单位没有法务人员的，授权人中至少有一名是发案单位的相关工作人员。

授予特别代理权限的，被授权人必须是公司或公司所属单位的法务人员，其他人员只能给予一般代理权限。

公司办公室（法务）是诉讼（仲裁）授权书的业务主管部门，发案单位是承办单位，授权书由公司法定代表人或总法律顾问进行审批。

（五）重大经济信息、新闻的公开发布

公司办公室、政工部是被授权对外发布重大经济信息、新闻的的业务管理部门。负责对外公开重大经济信息和发布公司经营管理活动重大新闻事项。负责公司突发事件中涉及新闻媒体的应急处理。公开涉及商业秘密的信息数据、关乎公司形象的对外宣传均应获得相应授权，具体内容与程序由公司宣传管理办法规定。

第六章 授权的变更、终止

第二十一条

授权因发生下列情况，法定代表人可变更或撤销授权：

（一）被授权人发生违法、违纪或重大越权行为；

（二）因被授权人的失职造成重大经营风险；

（三）国家进行政策性调整；

（四）公司进行内部调整

（五）授权人认为需要进行撤销或变更授权的其他情形。第二十二条

授权因发生下列情况终止：

（一）授权书中规定期限届满；

（二）授权被撤销；

（三）被授权的相应机构被撤销；

（四）被授权人被解除或辞去职务；

（五）在授权期限内，因变更事项需要重新制发授权书的，自变更后的授权书生效之日起，原授权书终止；

（六）其他需要终止的情况。

第二十三条

公司对一次性职务授权实行动态管理。在授权期限内被授权人工作岗位发生变化或者终止劳动合同时24小时内人力资源部应负责通知财务资金部。

第二十四条

根据工作需要，法定代表人可以随时通知相关业务授权管理部门撤回或部分撤回授权委托。

第二十五条 授权委托书一经撤回，其效力不可恢复，变更、撤回或终止的法定代表人授权委托书应按规定存档。

第七章 授权委托书用印

第二十六条 公司法定代表人出具的书面委托书，须加盖公司印章及法定代表人私章，并履行如下用印程序：

用印申请人填写用印审批单，经部门主管领导签字确认，报公司法定代表人签字批准后，由印章管理人员用印。

非经营性文件资料的报送、代表公司到行政管理机关办理事务等一般性事项，需要加盖公章或开具介绍信，由办公室负责用印。

第八章 授权制度的检查监督

第二十七条 各授权管理的业务主管部门应当定期或不定期对被授权人行使授权权限的情况进行检查和监督。

审计监察部在内部审计过程中若发现被授权人有一般越权行为的，应督促其限期改正；有重大越权行为的，应提交公司法定代表人决定对其作出处罚决定；该重大越权行为给公司造成严重损失的，承担民事赔偿责任。

审计监察部在内部审计过程中若发现相关人员在工作中按照权限进行授权，但不满足形式性要求时，应当督促相关责任人及时完备相应手续。

第二十八条 未按本规定办理授权委托手续的，相关责任人应当承担责任。

办理授权书评审，批准程序不到位的，业务主管部门及承办单位或部门的负责人、经办人承担责任；业务评审有重大过失的，业务部门负责人、经办人承担责任；法律评审意见不合法或遗漏重大法律风险的，办公室（法务）负责人、经办人承担责任；授权书未按规定程序进行评审和批准的，有关领导予以签发的，签发人承担责任；未经领导签发加盖公章及法定代表人章的，办公室印章管理人及经办人承担责任。

第九章 法律责任

第二十九条 被授权人按照授权范围内事项对授权人负责。被授权人必须在授权范围内行使各项权限。

第三十条 被授权人应在代理权限内进行代理活动，超越代理权、没有代理权或代理权终止后的代理行为均属无权代理。未经批准、授权的代理行为，即无权代理行为，公司不承担民事责任，当事人必须承担无权代理的法律后果，并承担由此引起的一切法律责任。

第三十一条 被授权人有下列行为之一的，按公司有关规定追究其经济、行政责任。触犯刑律的，提交司法部门追究其刑事责任：

（一）因失职、渎职给公司造成损失的；

（二）滥用代理权损害公司利益的。滥用代理权是指代理人以被代理人名义同自己订立合同；代理人同时代理两方当事人订立合同；代理人与第三人串通签订合同从中渔利，代理人将公司业务转嫁给其他单位等行为；

（三）在代理活动中的各种舞弊行为。

第十章 附则

第三十二条 公司各项规章制度中有关授权管理的规定与本办法相抵触的，以本办法为准。

第三十三条 本办法由公司办公室（法务）负责解释。第三十四条 本办法自印发之日起实施 附件一：综合授权书

授权委托书

（以下简称本公司），系根据中华人民共和国法律成立并有效存续的公司，其注册地为。

根据本公司做出的决定，谨郑重授权本公司的分支机构[ 名 称

]（以下简称

分公司/经理部）法定代表人[姓名

]（身份证号码：）办理如下事宜：

一、以本公司或者本分公司/经理部名义，负责[

]范围内建筑工程项目的跟踪、经营洽商、资格预审、组织投标和实施。

二、批准、签署投标额以及合同额在[

]元人民币以下（不含本数）的建筑工程投标文件和合同文件，并组织实施。

三、制定本分公司/经理部的规章制度及规范性文件，提出

分公司/经理部组织机构设臵和调整方案，经本公司批准后实施。

四、负责本分公司/经理部日常财务支出，仅限于本公司所批准的预算范围内。

五、本分公司/经理部不得开展融资、投资、贷款和担保业务。

六、经本公司另行授权后，方可以本公司名义处理经营管理过程中发生的各类诉讼或仲裁案件。

本授权委托书中的第二项中签署合同的权利及第四项及第五项中的权利均不得转委托；除此之外的其他权利，代理人可根据经营需要以书面形式将其部分或全部转委托其他人，并有权随时撤销该转委托。被转委托的被授权人不得再行转委托。

本公司郑重声明：对于代理人在本公司上述授权范围内的一切经营、管理活动所产生的后果，本人愿承担法律责任；对于代理人超越上述授权所从事的民事行为，除本公司明确以书面形式确认外，本公司概不承担任何法律责任。

本授权书经本公司法定代表人签署并加盖本公司公章后生效，有效期至二〇一

****年**月**日。本公司有权随时撤销本委托公司（盖章）：

法定代表人： 代理人：

签署日期：

****年**月**日附件二：单项授权书授权委托书

（以下简称“本公司”），系根据中华人民共和国法律设立并存续的公司，其注册地为

根据本公司做出的决定并依据本文件，谨郑重授权姓名：

（其签字真迹如下所示）为本公司正式合法的代理人，该代理人有权代表本公司处理

的相关事宜，具体包括：

（除此不拥有未授权的其它权利）

本授权书经法定代表人签署并加盖本公司公章后生效，代理人转委托他人无效。

本授权书有效期限自

****年**月**日起至

****年**月**日止公司（盖章）： 法定代表人： 代理人： 身份证号：

签署日期：

****年**月**日附件三：

授权书审批表 编号：

附件四：

综合授权管理工作台帐（

/ 16

（五）授权人认为需要进行撤销或变更授权的其他情形。第二十二条

授权因发生下列情况终止：

（一）授权书中规定期限届满；

（二）授权被撤销；

（三）被授权的相应机构被撤销；

（四）被授权人被解除或辞去职务；

（五）在授权期限内，因变更事项需要重新制发授权书的，自变更后的授权书生效之日起，原授权书终止；

（六）其他需要终止的情况。

第二十三条

公司对一次性职务授权实行动态管理。在授权期限内被授权人工作岗位发生变化或者终止劳动合同时24小时内人力资源部应负责通知财务资金部。

第二十四条

根据工作需要，法定代表人可以随时通知相关业务授权管理部门撤回或部分撤回授权委托。

第二十五条

授权委托书一经撤回，其效力不可恢复，变更、撤回或终止的法定代表人授权委托书应按规定存档。

第七章 授权委托书用印

第二十六条 公司法定代表人出具的书面委托书，须加盖公司印章及法定代表人私章，并履行如下用印程序：

用印申请人填写用印审批单，经部门主管领导签字确认，报公司法定代表人签字批准后，由印章管理人员用印。

非经营性文件资料的报送、代表公司到行政管理机关办理事务等一般性事项，需要加盖公章或开具介绍信，由办公室负责用印。

第八章 授权制度的检查监督

/ 16

第二十七条 各授权管理的业务主管部门应当定期或不定期对被授权人行使授权权限的情况进行检查和监督。

审计监察部在内部审计过程中若发现被授权人有一般越权行为的，应督促其限期改正；有重大越权行为的，应提交公司法定代表人决定对其作出处罚决定；该重大越权行为给公司造成严重损失的，承担民事赔偿责任。

审计监察部在内部审计过程中若发现相关人员在工作中按照权限进行授权，但不满足形式性要求时，应当督促相关责任人及时完备相应手续。

第二十八条 未按本规定办理授权委托手续的，相关责任人应当承担责任。

办理授权书评审，批准程序不到位的，业务主管部门及承办单位或部门的负责人、经办人承担责任；业务评审有重大过失的，业务部门负责人、经办人承担责任；法律评审意见不合法或遗漏重大法律风险的，办公室（法务）负责人、经办人承担责任；授权书未按规定程序进行评审和批准的，有关领导予以签发的，签发人承担责任；未经领导签发加盖公章及法定代表人章的，办公室印章管理人及经办人承担责任。

第九章 法律责任

第二十九条 被授权人按照授权范围内事项对授权人负责。被授权人必须在授权范围内行使各项权限。

第三十条 被授权人应在代理权限内进行代理活动，超越代理权、没有代理权或代理权终止后的代理行为均属无权代理。未经批准、授权的代理行为，即无权代理行为，公司不承担民事责任，当事人必须承担无权代理的法律后果，并

/ 16

承担由此引起的一切法律责任。

第三十一条 被授权人有下列行为之一的，按公司有关规定追究其经济、行政责任。触犯刑律的，提交司法部门追究其刑事责任：

（一）因失职、渎职给公司造成损失的；

（二）滥用代理权损害公司利益的。滥用代理权是指代理人以被代理人名义同自己订立合同；代理人同时代理两方当事人订立合同；代理人与第三人串通签订合同从中渔利，代理人将公司业务转嫁给其他单位等行为；

（三）在代理活动中的各种舞弊行为。

第十章 附则

第三十二条 公司各项规章制度中有关授权管理的规定与本办法相抵触的，以本办法为准。