SQLServer 角色与权限管理
安全性是所有数据库管理系统的一个重要特征。理解安全性问题是理解数据库管理系统安全性机制的前提。
1.第一个安全性问题：当用户登录数据库系统时，如何确保只有合法的用户才能登录到系统中？这是一个最基本的安全性问题，也是数据库管理系统提供的基本功能。
在Microsoft SQL Server 2008系统中，通过身份验证模式和主体解决这个问题。
1）身份验证模式
Microsoft SQL Server 2008系统提供了两种身份验证模式：Windows身份验证模式和混合模式。
Windows身份验证模式：
在该模式中，用户通过Windows用户账户连接SQL Server时，使用Windows操作系统中的账户名和密码。
混合模式：
在混合模式中，当客户端连接到服务器时，既可能采取Windows身份验证，也可能采取SQL Server身份验证。
主体是可以请求系统资源的个体或组合过程。例如，数据库用户是一种主体，可以按照自己的权限在数据库中执行操作和使用相应的数据。
2）主体
主体是可以请求系统资源的个体或组合过程。例如，数据库用户是一种主体，可以按照自己的权限在数据库中执行操作和使用相应的数据。
Microsoft SQL Server 2008系统有多种不同的主体，不同主体之间的关系是典型的层次结构关系，位于不同层次上的主体其在系统中影响的范围也不同。位于层次比较高的主体，其作用范围比较大；位于层次比较低的主体，其作用范围比较小。
2.第二个安全性问题：当用户登录到系统中，他可以执行哪些操作、使用哪些对象和资源？
在Microsoft SQL Server 2008系统中，通过安全对象和权限设置来解决这个问题。
3.第三个安全性问题：数据库中的对象由谁所有？如果是由用户所有，那么当用户被删除时，其所拥有的对象怎么办，难道数据库对象可以成为没有所有者的“孤儿”吗？
在Microsoft SQL Server 2008系统中，这个问题是通过用户和架构分离来解决的。
安全机制的5个等级：
客户机安全机制
网络传输的安全机制
实例级别安全机制
数据库级别安全机制
对象级别安全机制
四.角色
1.固定服务器角色
v固定服务器角色是服务器级别的主体，它们的作用范围是整个服务器。
v固定服务器角色已经具备了执行指定操作的权限，可以把其他登录名作为成员添加到固定服务器角色中，这样该登录名可以继承固定服务器角色的权限。
固定服务器角色的特点
v在Microsoft SQL Server系统中，可以把登录名添加到固定服务器角色中，使登录名作为固定服务器角色的成员继承固定服务器角色的权限。
v对于登录名来说，可以选择其是否成为某个固定服务器角色的成员
按照从最低级别的角色（bulkadmin）到最高级别的角色（sysadmin）的顺序进行描述：Bulkadmin：这个服务器角色的成员可以运行BULK INSERT语句。这条语句允许从文本文件中将数据导入到SQL Server 2008数据库中，为需要执行大容量插入到数据库的域账户而设计。
Dbcreator：这个服务器角色的成员可以创建、更改、删除和还原任何数据库。这不仅是适合助理DBA的角色，也可能是适合开发人员的角色。
Diskadmin：这个服务器角色用于管理磁盘文件，比如镜像数据库和添加备份设备。它适合助理DBA。
Processadmin：SQL Server 2008能够多任务化，也就是说可以通过执行多个进程做多个事件。例如，SQL Server 2008可以生成一个进程用于向高速缓存写数据，同时生成另一个进
程用于从高速缓存中读取数据。这个角色的成员可以结束（在SQL Server 2008中称为删除）进程。
Securityadmin：这个服务器角色的成员将管理登录名及其属性。他们可以授权、拒绝和撤销服务器级权限。也可以授权、拒绝和撤销数据库级权限。另外，它们可以重置SQL Server 2008登录名的密码。
Serveradmin：这个服务器角色的成员可以更改服务器范围的配置选项和关闭服务器。例如SQL Server 2008可以使用多大内存或监视通过网络发送多少信息，或者关闭服务器，这个角色可以减轻管理员的一些管理负担。
Setupadmin：为需要管理链接服务器和控制启动的存储过程的用户而设计。这个角色的成员能添加到setupadmin，能增加、删除和配置链接服务器，并能控制启动过程。Sysadmin：这个服务器角色的成员有权在SQL Server 2008中执行任何任务。
Public:有两大特点，第一，初始状态时没有权限；第二，所有的数据库用户都是它的成员。
2.数据库角色
三种类型的数据库角色:
固定数据库角色：微软提供的作为系统一部分的角色；
用户定义的标准数据库角色：你自己定义的角色，将Windows用户以一组自定义的权限分组；应用程序角色：用来授予应用程序专门的权限，而非授予用户组或者单独用户。
1）固定数据库角色
微软提供了9个内置的角色，以便于在数据库级别授予用户特殊的权限集合
db_owner:该角色的用户可以在数据库中执行任何操作。
db_accessadmin:该角色的成员可以从数据库中增加或者删除用户。
db_backupopperator:该角色的成员允许备份数据库。
db_datareader:该角色的成员允许从任何表读取任何数据。
db_datawriter:该角色的成员允许往任何表写入数据。
db_ddladmin：该角色的成员允许在数据库中增加、修改或者删除任何对象（即可以执行任何DDL语句）。
db_denydatareader:该角色的成员被拒绝查看数据库中的任何数据，但是他们仍然可以通过存储过程来查看。
db_denydatawriter: 像db_denydatareader角色，该角色的成员被拒绝修改数据库中的任何数据，但是他们仍然可以通过存储过程来修改。
db_securityadmin:该角色的成员可以更改数据库中的权限和角色。
public：在SQL Server 2008中每个数据库用户都属于public数据库角色。当尚未对某个用户授予或者拒绝对安全对象的特定权限时，这该用户将据称授予该安全对象的public角色的权限，这个数据库角色不能被删除
2）用户自定义数据库角色
3）应用程序角色
应用程序角色允许用户为特定的应用程序创建密码保护的角色。
五.权限
1.常用的权限
安全
常用权限
对象
数据库CREATE DATABASE、CREATE DEFAULT、CREATE FUNCTION、CREATE PROCEDURE、CREATE VIEW、CREATE TABLE、CREATE RULE、BACKUP DATABASE、BACKUP LOG
表SELECT、DELETE、INSERT、UPDATE、REFERENCES
表值
函数
SELECT、DELETE、INSERT、UPDATE、REFERENCES
视图SELECT、DELETE、INSERT、UPDATE、REFERENCES
存储
过程
EXECUTE、SYNONYM
标量
函数
EXECUTE、REFERENCES
9.6.4 操作权限
权限分为3种状态：授予、拒绝、撤销，可以使用如下的语句来修改权限的状态。
授予权限（GRANT）：授予权限以执行相关的操作。通过角色，所有该角色的成员继承此权限。
撤销权限（REVOKE）：撤销授予的权限，但不会显示阻止用户或角色执行操作。用户或角色仍然能继承其他角色的GRANT权限。
拒绝权限（DENY）：显式拒绝执行操作的权限，并阻止用户或角色继承权限，该语句优先于其他授予的权限。
1.授予权限
本语法格式：
GRANT
{ALL|statement[,..n] }
TO security_account[,..n]
ALL：表示希望给该类型的对象授予所有可用的权限。不推荐使用此选项，保留些选项仅用于向后兼容。授予ALL参数相当于授予以下权限：
如果安全对象为数据库，则ALL表示CREATE DATABASE、CREATE DEFAULT、CREATE FUNCTION、CREATE PROCEDURE、CREATE VIEW、CREATE TABLE、CREATE RULE等权限。
如果安全对象为标量函数，则ALL表示EXECUTE和REFERENCES。
如果安全对象为表值函数，则ALL表示SELECT、DELETE、INSERT、UPDATE、REFERENCES。如果安全对象为存储过程，则ALL表示EXECUTE、SYNONYM。
如果安全对象为表，则ALL表示SELECT、DELETE、INSERT、UPDATE、REFERENCES。
如果安全对象为视图，则ALL表示SELECT、DELETE、INSERT、UPDATE、REFERENCES。Statement:表示可以授予权限的命令，例如，CREATE DATABASE。
security_account:表示定义被授予权限的用户单位。security_account可以是SQL Server 的数据库用户，可以是SQL Server的角色，也可以是Windows的用户或工作组
信息系统用户帐号与角色权限管理流程 一、目的 碧桂园的信息系统已经在集团下下各公司推广应用，为了确保公司各应用信息系统安全、有序、稳定运行，我们需要对应用信息系统用户帐号和用户权限申请与审批进行规范化管理,特制定本管理规定。 二、适用范围 适用于公司应用信息系统和信息服务，包括ERP系统、协同办公系统、各类业务应用系统、电子邮箱及互联网服务、数据管理平台等。 三、术语和定义 用户：被授权使用或负责维护应用信息系统的人员。 用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、单位、联系方式等基本信息内容。 权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。 角色：应用信息系统中用于描述用户权限特征的权限类别名称。 四、用户管理 （一）用户分类 1.系统管理员：系统管理员主要负责应用信息系统中的系统参数配置，用户帐号开通与维护管理、设定角 色与权限关系，维护公司组织机构代码和物品编码等基础资料。 2.普通用户：指由系统管理员在应用信息系统中创建并授权的非系统管理员类用户，拥有在被授权范围内 登陆和使用应用信息系统的权限。 （二）用户角色与权限关系 1.应用信息系统中对用户操作权限的控制是通过建立一套角色与权限对应关系，对用户帐号授予某个角色 或多个角色的组合来实现的，一个角色对应一定的权限（即应用信息系统中允许操作某功能点或功能点 集合的权力），一个用户帐号可通过被授予多个角色而获得多种操作权限。 2.由于不同的应用信息系统在具体的功能点设计和搭配使用上各不相同，因此对角色的设置以及同样的角 色在不同应用信息系统中所匹配的具体权限范围可能存在差异，所以每个应用信息系统都需要在遵循《应 用信息系统角色与权限设置规范》基础上，分别制定适用于本系统的《碧桂园应用信息系统角色与权限
OA系统权限管理设计方案 l 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 l 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 l 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。
角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A. 通过职位 a) 在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限不可继承。 b) 实例中：如前台这个职位，对于考勤查询有权限，则可以通过对前台这个职位设置考勤查询的浏览权，使他们有使用这个对象的权限，然后再设置个，考勤查询权（当然也可以不设置，默认能进此模块的就能查询），则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中，项目成员的权限来自于所在项目的权限，他们同样不能继承下级项目的权限，而对于项目组长，他对项目有全权，对下级项目也一样。 b) 实例中：在项目中，项目成员可以对项目中上传文档，查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口，这样每个成员能访问这个项目了，再加上项目文档的上传权和查看文档权即可。
角色权限模块说明 一、何为权限 通常登录一个系统在页面左边部分能看到相关操作菜单，鼠标点击相应菜单会进入相关操作页面，页面里面展示当前登录用户能查看的相关数据及对数据可进行的操作按钮；通过以上描述，我们可以用相对专业点的术语描述：当前登录用户有该菜单功能的操作权限，并且该用户只能查看自己拥有权限查看的数据，数据的操作按钮也可能不是全部操作按钮，比如可以新增但是不可以删除，而管理员登录后进入该页面这可以看到删除按钮并且可以进行删除操作等；以上文字描述了菜单权限，数据权限，按钮权限等三种权限概念； 二、何为角色 如果管理员为系统每个用户各自选择可以操作的权限，这样不仅效率低下而且用户体验相当不好，每新建一个用户就要为该用户单独选择可操作的权限，即使该用户的权限和之前的用户是一模一样的可还是要重新选择，有没有好的解决方案呢？我们可以将权限相似的用户所拥有的权限进行分组，将用户加入该分组，那么用户就拥有该分组里面的权限，分组名称就是角色，这样只要我们为用户分配相应的角色该用户就一次性的获得了多个可操作的权限。 三、权限分配 通常角色拥有的权限及用户所属的角色会根据需求进行变化，比如部门重组或者人员调离，该部门人员的职责不同了，那么其拥有的权限和所属角色也会发生相应的变化，通常管理员会根据实际情况新增或取消某个角色拥有的权限或者新建新的角色亦或者删除过期的角色等，这些操作我们称之为权限分配。 四、新系统权限管理说明 新系统后台权限分为三种即菜单权限，数据权限，按钮权限。新系统默认有个超级管理员角色(superadmin)及该角色下用户名为superadmin的用户，该角色默认拥有系统全部资源的操作权限(新功能开发时由开发人员进行配置)，并且在权限分配时只有该角色里面的用户才能看到所有权限并对其进行分配，其他任何角色里面的用户都不能对其进行修改和重新分配权限，该角色仅限公司内部开发人员，维护人员及测试人员使用，其中菜单管理，系统配置管理，定时器配置管理，系统词典管理，demo功能原型等功能为该角色独有的权限(业务逻辑上如此规定，如超级管理员将这些权限分配给其他角色则其他角色里面的用户也是可以对其进行操作的)。 超级系统管理员可以创建其他的角色，创建角色时分配该角色拥有的权限，如果将权限分配权限也分配给新角色，那么新角色在创建其他新角色并对其进行权限分配时只能看到自
对EMS权限管理模块设计 1.权限设计概述 1.1引言 随着Web 服务的复杂度增加以及用户数量和种类的增多，安全问题在理论及工程上都 是一个必须考虑的问题，而权限管理是安全问题中一个很重要的方面。因此本文针对权限做 了一个分析。 权限可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的 逻辑表达式是否为真。 1.2意义 ?用户管理及权限管理一直是应用系统中不可缺少的一个部分 ?系统用户很多，系统功能也很多 ?不同用户对系统功能的需求不同 ?出于安全等考虑，关键的、重要的系统功能需限制部分用户的使用 ?出于方便性考虑，系统功能需要根据不同的用户而定制 1.3目标 直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要， 除了功能的必须，更主要的就是因为它足够直观。 简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解 决所有的权限问题是不现实的。设计中将变化的“定制”特点比较强的部分判断为业务逻辑， 而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 扩展，采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组 方式定义的同时有效避免了权限的重复定义。 2.基于角色的权限管理设计（Role-Based Access Control,RBAC）2.1权限管理用例图
2.2用例图描述 超级管理员：系统中默认的角色，它是系统中拥有最高权限的角色，它不仅能够管理其他的管理员和用户，而且还可以对系统中每个模块的任一功能进行操作、维护。 普通管理员：它是由超级管理员创建的，并授予权限，它能够管理系统部分的功能，它可以查看所有普通管理员、普通用户的信息，它只能对由它自己创建的用户进行编辑、删除操作，和管理拥有权限的模块。 普通用户：它是系统中最低权限的角色，它只能对自己拥有的权限进行操作，一般情况下，它的权限是对信息的浏览和对自己信息的录入，修改。 登陆系统：根据用户拥有的权限不同，用户所能操作的功能多少就不同，所以在登陆系统的时候就要对用户的权限进行判断。
实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。 就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构： 首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
系统设置说明书 系统设置包括基础配置和流程配置，点击主菜单的系统设置，点击左菜单的基础配置 1、添加部门和删除部门 点击主菜单的系统设置---点击左菜单的基础配置---点击做菜单的人事管理，在中间的组织部门上弹鼠标右键，选择新增下级部门，出现的编辑页面如下： 在这里，部门名称和部门编码为必填字段，用蓝色标识。 如果你想删除部门，点击主菜单的系统设置---点击左菜单的基础配置---点击左菜单的人事管理，在需删除的部门上弹鼠标右键，选择删除当前部门，点击确定即可。
2、添加人员 左击主菜单的系统配置-----左击左菜单的基础配置---点击人事管理-----选择部门-----在人员信息维护栏点新增，出现的页面如下：
用户代号（即用户登陆的账号）和姓名为蓝色，必填，同时用户代号至少为3个以上字母或数字。建议在维护人员基本资料时，尽可能填写详细，特别是手机号、email、办公电话、QQ，这样为以后的消息通知提供方便。点击保存后，出现页面如下： 保存后，用户的初始化密码和用户代号相同。 如果人员发生调动，比如从一个部门调到另一部门，双击部门输入框，弹出的页面如下：
选择他现在的新部门，点击“确定”即可 3、给新增的人员配权限 1、先配置基本的权限 左击主菜单的系统配置-----左击左菜单的基础配置---点击角色权限管理-在角色下点击一般用户 在人员信息下点新增，选择刚才添加的人员------点确定。这时该用户有了基本的权限，可以进入系统浏览各模块。 3、配置不走流程的模块的权限
比如设备台帐， 点击左菜单的基础配置---点击角色权限管理-----在角色下找到设备台帐管理人员，点击它----在人员信息下点新增---在弹出的人员选择页面中选择部门-----选择人员-----点确定. 注意设备台帐有一点不同，他还需要配置每个部门可以管理哪些设备 点击主菜单的设备管理----点击部门所辖位置，点击需要配权限的部门，点击新增弹出选择位置的页面， 勾选位置后，点确定，提示：
实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便 的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致 的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套 管理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统 之间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构： 首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
admin超级管理员的意思 简单的说：Admin是Administrator的简写形式，其中文意思就是“系统管理员”。 Admin与账套主管的区别 ADMIN是系统初始化时默认的用户，可以增加、修改、删除操作员及员工档案等基础数据维护，建立账套管用户为各用户授权、还有对同步打印模块的设置和维护，但不可以查询报表等操作账套主管的权限最大，拥有ADMIN的所有权限（除同步打印模块维护指定ADMIN外）、日常业务、基础数据维护、报表查询等 admin 是系统初始化时默认的用户 可以登陆软件的系统管理中增加、修改、删除操作员及员工档案等基础数据维护建立新的账套，指定操作员为某账套的账套主管 为新账套操作员用户授权 备份、恢复已存在所有的账套数据，清除异常任务 admin不参与具体的账务日常业务操作，只在系统管理中使用 账套主管 针对某个账套的权限最大，拥有账套操作的所有权限、日常业务、基础数据维护、 报表查询等 登陆系统管理可以对操作员授权 做年度账套新建、结转年初数 2010-04-13 08:34
用友软件系统管理员admin和账套主管的权限区别 系统管理员admin和账套主管的权限区别2009年07月18日星期六14:54 用友软件系统管理员admin和账套主管的权限区别 从前面的介绍中，可以看到在系统管理中，有些操作需要系统管理员admin来注册，而有些操作需要账套主管来登陆。现在就把这两个操作员的权限区别列示如下： 功能操作员建立账套备份、恢复账套角色操作用户操作权限操作修改账套清除异常任务和单据锁定年度账管理结转上年数据系统管理员admin 系统管理概述 用友ERP-U8软件产品是由多个产品组成，各个产品之间相互联系、数据共享，完全实现财务业务一体化的管理。对于企业资金流、物流、信息流的统一管理提供了有效的方法和工具。系统管理包括新建账套、新建年度账、账套修改和删除、账套备份，根据企业经营管理中的不同岗位职能建立不同角色，新建操作员和权限的分配等功能。系统管理的使用者为企业的信息管理人员：系统管理员Admin、安全管理员admin、管理员用户和账套主管。 系统管理模块主要能够实现如下功能： ?对账套的统一管理，包括建立、修改、引入和输出(恢复备份和备份)。 ?对操作员及其功能权限实行统一管理，设立统一的安全机制，包括用户、角色和权限设置。 ?允许设置自动备份计划，系统根据这些设置定期进行自动备份处理，实现账套的自动备份。 ?对年度账的管理，包括建立、引入、输出年度账，结转上年数据，清空年度数据。 ?对系统任务的管理，包括查看当前运行任务、清除指定任务、清退站点等。
应用系统的角色、权限分配管理制度 第一条、用户权限管理 一、用户类型 1．系统管理员： 为应用系统建立账号及分配权限的用户 2．高级用户： 具有对应用系统内的数据进行查询和修改的用户 3．普通用户： 只对系统内数据有查询功能的用户 二、用户建立 1．建立的原则 （1）不同类型用户的建立应遵循满足其工作需要的原则，而用户的权限分配则应以保障数据直报的高效、准确、安全为原则。 （2）用户的权限分配应尽量使用系统提供的角色划分。如需特殊的操作权限，应在准确理解其各项操作内容的基础上，尽量避免和减少权限相互抵触、交叉及嵌套情况的发生，经调试成功后，再创建相应的角色赋予本级用户或直报用户。 （3）通过对用户进行角色划分，分配报告用户权限，合理限制对个案数据的修改权限，将数据报告与数据利用剥离，即原始数据报告与统计加工后信息利用分开。 （4）系统内所有涉及报告数据的帐户信息均必须采用真实信息，即
实名制登记。 2．建立的程序 （1）用户申请 可由使用部门使用人填写应用系统用户申请表，经单位领导签字批准后，向本单位负责应用的相关部门提出申请。 （2）用户创建 负责应用系统的相关部门在收到用户申请表后，系统管理员根据用户申请的内容和实际的工作范围，为其建立用户帐号并授予相应的角色，再填写用户申请回执表，经部门主管领导签字批准后，反馈给申请单位。 创建用户的步骤：①建立用户帐号；②创建角色；③为角色配置权限； ④将角色授予用户。 第二条、用户安全 一、系统安全 1.用户必须遵守国家法律、单位规章制度，不得参加任何非法组织和发布任何反动言论；严守单位机密，不得对外散布、传播本系统内部信息；不得有诋毁、诽谤、破坏本系统声誉的行为。 2.用户必须按“传染病监测信息应用工作与技术指南”对系统进行操作，尽量做到专人、专机运行使用本系统，并避免使用公共场所（如网吧）的计算机使用应用系统。 3.用户应在运行本系统的计算机上安装杀毒软件、防火墙，定期杀毒；禁止在运行本系统的计算机上安装、运行含有病毒、恶意代码、木马
用户管理模块设计 用户管理模块提供对用户信息的管理，包括用户注册、用户登录、用户权限管理、用户信息修改以及用户等级修改。 1、用户注册 根据用户表，设计相应的注册页面，注册页面包括用户名、密码、邮箱、部门、电话等信息，当用户进行注册时，填写这些信息，用户名是不能与已注册的用户名相同，填写完成后，提交注册请求，后台相应的Action会响应该动作，首先获取到页面发来的参数，然后将这些参数通过Session 对象写入到数据库中，最后向用户提示注册成功与否。 2、用户登录 用户注册之后，就可以通过账户和密码登陆至平台。当用户提交登陆请求，后台相应的Action 会响应该动作，首先获取到页面发来的用户名和密码，然后通过Query对象查询该用户是否存在且密码正确，最后将根据结果给用户发送跳转页面，如果用户存在且密码正确，则可进入平台主页面，否则，提示登陆错误信息。 3、用户权限管理 用户权限管理将用户分为普通用户和管理员，他们具有不同的权限，他们各自的权限如表1所示。此平台首次使用时，会内置一个超级管理员，有修改用户等级的权限。 表1 不同用户权限授权
定义一个权限拦截器，它的功能是用来检验用户类型，对每一个需要管理权限的操作均进行拦截，同时检验用户类型，判断该用户类型是否可执行该操作，即可达到权限管理的作用。如果某操作在当前用户等级对应的操作范围内，则可正常访问，否则跳转到提示页面，提示用户权限不足。 4、用户信息修改 用户管理模块提供用户修改自己信息的功能。当进入信息修改界面，首先会获取Session中当前用户信息，供用户在当前信息基础上进行信息修改。当用户填写完修改信息，并发送修改请求后，后台将响应用户的请求，首先得到所有用户修改参数，然后将修改的信息设置到该对象中，最后更新数据库，将更新结果发送给用户。 青山埋白骨，绿水吊忠魂。
OA系统权限管理设计方案7 OA系统权限管理设计方案 数据库2010-02-2310:09:25阅读13评论0字号：大中小 OA系统权限管理设计方案 l不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 l可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 l权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 l满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限
在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A.通过职位 a)在职位中，职位成员的权限继承当前所在职位的权限，对
OA系统权限管理设计方案 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的 功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组” 进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进 行重新开发。 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源 权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中， 用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。
一个用户权限管理模块的设计思路： 1. 权限资源（功能资源） 系统的所有权限信息。权限具有上下级关系，是一个树状的结构。如下： 系统管理 单位管理 查看单位 添加单位 修改单位 删除单位 部门管理 查看部门 添加部门 修改单位 删除单位 对于每个权限，又存在两种情况：1可访问；2可授权，部分表中采用拥有类型做判断(0可访问，1即可访问也可授权) 2. 用户 系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n 个组。他的权限集是自身具有的权限+所属的各角色具有的权限+所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对拥有相似权限的用户进行分类管理，因此定义角色，例如：超级管理员，一般管理员、一般用户等角色。在这里同时也让角色具有上下级关系，形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。 4. 组 为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际应用中，我们知道，组也可以具有自己的角色信息、权限信息。 就好比是javaeye中的圈子，一个圈子可以拥有多个会员，同时一个会员也可以加入多个圈子，对于不同的圈子又有不同的权限信息。(组的解释：例如一个公司中，不同的部门即可划分不同的组来进行权限的分配) 针对以上描述，结构关系如下： 整个模块分为组权限管理、角色权限管理、用户权限管理。 其中组权限管理：组权限 = 所属角色的权限合集 + 组自身的权限。
角色权限管理：角色权限 = 角色自身权限。 用户权限管理：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。 注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。 欢迎大家拍砖，给点建议。
XX医院 应用信息系统用户帐号与角色权限管理办法 （讨论版） 新津县妇幼保健院信息科 二○一五年四月
目录 1 目的 (3) 2 适用范围 (3) 3 术语和定义 (3) 4 用户管理 (3) 4.1用户分级 (3) 4.2用户分类 (3) 4.3用户角色与权限关系 (4) 4.4用户帐号实名制注册管理 (5) 5 用户帐号申请与审批 (8) 5.1帐号申请 (8) 5.2帐号审批和开通 (8) 6 安全管理 (8) 6.1帐号安全 (8) 6.2密码安全 (9) 6.3信息安全 (9) 7 档案管理 (9) 附表1 应用信息系统角色与权限关系对照表（表样） (10) 附表2 用户帐号申请单 (12) 附表3 用户帐号批量申请单 (13) 附表4 用户帐号管理工作登记表 (15)
1目的 为加强新津县妇幼保健院信息科计算机中心（以下简称：中心）应用信息系统用户帐号和用户权限申请与审批的规范化管理, 确保中心各应用信息系统安全、有序、稳定运行，特制定本管理办法。 2适用范围 适用于中心开发、建设和管理的各项应用信息系统，包括HIS系统、EMR系统、LIS系统、PACS 系统、医保接口系统、网络直报系统、网站门户等管理系统。 3术语和定义 用户：被授权使用或负责维护应用信息系统的人员。 用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、科室、职务或职称等基本信息内容。 权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。 角色：应用信息系统中用于描述用户权限特征的权限类别名称。 4用户管理 4.1用户分级 中心各应用信息系统的用户根据各相关业务的信息管理工作要求，涉及行政、后勤、临床、医院门户四个方面。因此中心应用信息系统用户分为4个类（级）别，即：院领导级、部门负责人级、职能部门管理人员级、医师护士职称分级。 4.2用户分类 4.2.1系统管理员 系统管理员主要负责应用信息系统中的系统参数配置，用户帐号开通与维护管理、设定角色与权限关系，维护科室、项目等数据字典，系统日志管理以及数据管理等系统运行维护工作。 按照上述用户分级，系统管理员分为一级系统管理员、二级系统管理员二个等级，分别相应的应用信息系统日常运行维护管理工作。不同等级的系统管理员拥有不同等级的系统管理权限，当在一个应用信息系统中存在两个等级的系统管理员时，上级系统管理员对下级系统管理员拥有授权和监督管
1.1.1 权限管理 1、用户(User)可以拥有多个角色(Role)，角色可以被分配给多个用户 2、权限的意思就是对某个资源的某个操作，现在规定： a) 所谓资源，即系统的模块 b) 所谓操作，包括：增加、删除、修改、查询等操作 3、权限管理系统的总体功能分为：授权与认证 4、授权，指将权限授予角色或用户 a) 如果用户A拥有角色B、角色C，那么，缺省的情况下，用户A将拥有被分配给角色 A和角色C的所有权限（即默认情况下，用户A继承其拥有的角色所具有的所有权限） b) 如果用户拥有多个角色，那么用户的权限是这些角色权限的合集 c) 如果用户拥有多个角色，而且角色之间的授权有冲突（比如对同一个资源的同一个操 作，一个角色为“允许”，另外一个角色为“不允许”），将以优先级别高的角色为 准（所谓优先级别，也就是对于这个用户所拥有的角色而言，是有顺序的，同一个角 色在不同的用户那里可能拥有不同的优先级） d) 除了可以对角色进行授权外，也可以针对用户进行授权，也就是说，将权限授予用户。 针对某个资源的所有操作，我们可以设置这些权限对用户来说是“继承”或“不继承” i. 继承：意思是这些权限将使用其（即用户）所拥有的角色的权限，而不使用其（即 用户）单独设置的权限 ii. 不继承：意思是这些权限将使用其单独设置的权限，而不使用其所拥有的角色的权限 5、认证，指用户访问资源的某些操作时，根据授权，判断是否允许用户的访问 a) 在用户访问的时候，需要进行即时的判断（是否有权访问） b) 应该提供查询的功能，可以查询某个用户所拥有的所有权限 总体上，可分为模块管理、角色管理和用户管理模块： 模块管理： 模块管理主界面参考：
软件需求分析报告目录 1．引言 1.1 项目简介 本文档对通用用户权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。 1.2 编写说明 1．3参考资料 《通用权限管理系统需求规格说明书》 《通用权限管理系统数据库设计说明书》
2．目标 2.1概述 权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。 本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。2.2系统目标 系统的目标包括如下三点： （1）对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控； （2）完善用户、角色、组织、资源、操作的管理功能，其中的组织管理模块只提供组织视图，不参与权限的控制管理。 （3）开发人员开发新的系统功能，通过资源和角色模块进行操作管理。使用系统管理员身份登陆，直接将访问路径作对角色资源授权给操作，实现资源访问控制管理。 2.2.1 总目标 本系统提供一个调用简单、可复用性高、满足一般需求的权限管理模块，并为需要对权限管理的系统节省开发本。 2.2.2 性能目标 1、要求下载和安装速度快，响应时间快。
2、要求系统可适用于不同操作平台。 3、要求系统的可维护性和实用性强。 4、要求系统有一定的检错能力。 5、要求系统支持多用户同时操作，但管理者与用户不能同时操作。 2.2.3 功能目标 本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。 2.3 目标说明 3.结构 3.1系统需求结构 系统采用B/S架构模式，基于 BNFW开发，服务封装了对后台数据操纵的细节，并提供安全调用接口. WEB 应用程序通过接口访问系统服务，执行用户操作并返回结果。系统采用SQL SERVER数据库和tomcat web应用服务器开发，部署在 Linux和windows服务器下运行。 3.2 需求结构的说明 用户权限管理系统概貌如图所示：
扩展RBAC用户角色权限设计方案 RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图） 角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可
管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。 当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）
请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。 这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。 这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。 到这里，RBAC权限模型的扩展模型的完整设计图如下：
角色管理 主要功能 1.1添加角色信息 定义角色基本信息：角色名称，状态，角色描述 Action: 方法名：addRoleInfo() 返回值：String（Success/Error） 参数：无 方法功能：对界面传过来的RoleInfoDTO进行空值判断，如果非空，做RoleInfoDTO 和RoleInfo的相互转换，并调用RoleService中的saveRoleInfo（RoleInfo ri）方法； 如果为空，给出错误提示。 备注：在添加完角色名称后应该先检查是否有重名的角色，调用的Action是 findRoleBByName，如果有给出提示并制空名称重新填入。 Service： 方法名：saveRoleInfo（RoleInfo ri） 返回值：boolean 参数：RoleInfo对象 方法功能：调用RoleInfoDAO中的save（RoleInfo ri）方法。 1.2删除角色信息 根据角色ID删除一条角色信息 Action: 方法名：removeRoleById() 返回值：String(Success/Error) 参数：无 方法功能：对界面传过来的RoleInfoDTO.rid进行空值判断，如果非空，调用 RoleService中的removeRoleById(String rid)方法;如果为空，给出错误提示。 Service: 方法名：removeRoleById(String rid) 返回值：boolean 参数：rid(角色rid) 方法功能：修改RoleInfo的rstatus为“废弃”，调用RoleInfoDAO中的updateRoleById(RoleInfo ri)方法。 1.3编辑（修改）角色信息 根据角色ID修改一条角色信息 Action: 方法名：editRoleById() 返回值：String(Success/Error) 参数：无 方法功能：对界面传过来的RoleInfoDTO对象进行空值判断，如果非空，做 RoleInfoDTO和RoleInfo的相互转换，调用RoleService中的editRoleById(String rid) 方法;如果为空，给出错误提示。 Service:
权限管理模块设计说明书 摘要 权限管理分为两个部分，操作权限管理和资源权限管理。针对我们的系统，分别进行说明。 一、操作权限管理即为允许用户使用那些功能，进行哪些操作。有两个地方需要处理， 1、对用户隐藏没有授权的功能。如“LOG管理”功能没有对用户A授权，则用户A是看不见“LOG 管理”这个功能菜单的。 2、在功能所在的页面进行权限验证，防止没有授权的用户通过输入URL进入功能所在页面。 如“LOG管理”功能没有对用户A授权，则用户A是即使是手动输入“LOG管理”功能所在的页面，他也无法使用这个功能。 在实现方式上可以通过”角色”和”功能”来实现，一个”角色”对应多个”功能”，”用户”与”角色”是多对多的关系。当用户登录时通过 (用户->角色->功能)查询出该用户可以使用的功能列表并显示，无权使用的功能将被隐藏。并且在功能所在页面进行权限验证，避免没有权限的用户通过特殊方法进入页面。 二、资源权限管理的意思是限制用户对资源的访问和操作。 1、省级的用户可以查看和操作全省的数据。但不能查看和操作外省的数据。 2、市级的用户可以查看和操作全市的数据，但不能查看和操作该市以外的数据。 3、全国级的用户可以查看和操作全国的数据。
目录 1概述 (3) 1.1目的 (3) 2模块结构描述 (3) 3模块功能描述 (3) 3.1权限管理 (3) 3.1.1功能菜单管理 (3) 3.1.2用户管理 (4) 3.1.3角色管理 (4) 3.2操作权限验证 (4) 3.2.1登录验证 (5) 3.2.2页面载入验证 (5) 3.2.3页面操作权限验证 (5) 3.3资源权限验证 (6) 4数据库设计ER图 (6)
龙源期刊网 https://www.doczj.com/doc/cc6851175.html, 基于岗位抽象的角色权限控制模型设计与实现 作者：王伟全张学平 来源：《软件导刊》2012年第01期 摘要：通过对传统访问控制技术及其局限性的探讨，提出了全新的基于岗位抽象的角色 权限控制模型，画出了新模型的图示，介绍了新模型中“用户定岗”和“岗位授权”两个主要关系，阐述了新模型的优点。详细地阐述了实现新模型的关键技术，给出了新模型的总体结构图和总体类图，并对总体类图中的各个类及其关系进行了详细的说明。最后，总结了新模型的实用性及其推广应用价值。 关键词：RBAC；岗位；岗位互斥；定岗；授权 中图分类号：TP311.52 文献标识码：A 文章编号：1672-7800（2012）001-0107- 1 传统访问控制技术及其局限性 访问控制实质上是对资源使用的限制，决定主体是否被授权客体或资源执行某种操作,是 保障系统安全不可或缺的重要组成部分。目前，主要有3种不同类型的访问控制：自主访问控制（DAC）、强制访问控制（MAC）和基于角色的访问控制（RBAC）。 自主访问控制（DAC）是目前计算机系统中实现最多的访问控制机制，如Windows操作系统。强制访问控制（MAC）是强加给访问主体的，即系统强制主体服从既定的访问控制策略，主要应用于军事方面。这两种访问控制方式都只适用于特定的领域，具有一定的局限性。基于角色的访问控制（RBAC）引入了角色的概念，在授权主体和客体之间增加的角色这个中间层，实现了主客体的逻辑分离，具有一定的通用性。但RBAC在实际的应用中仍然存在一 些问题，如：角色的继承机制有缺陷，会造成某些角色的权限过大；权限定义较模糊、笼统，不够清晰；无法满足“同角色不同人员不同权限”的需求。基于上述原因，本文提出一种扩展的 RBAC新模型，引入了“岗位”概念，有效地弥补了传统RBAC的不足。 2 基于岗位抽象的角色权限控制模型 2.1 模型定义 新模型是在传统RBAC模型基础上引入“岗位”概念，模拟现实中的岗位管理制。其基本思想是：机构与角色结合形成岗位，模块与操作结合形成权限，先将权限赋给岗位（授权），再将人员指派到岗位（定岗），实现对系统资源的细粒度访问控制。如图1所示：