浅谈SAP权限设计

浅谈SAP权限管理
——基于安徽电力权限设计SAP R/3 系统是基于ERP（企业资源计划）技术的一个成熟产品，在国内外大中企业中广为使用。

该系统主要包括财务管理、物资管理、项目管理、人力资源等多个功能模块。

其中，权限ERP初上线时，企业比较注重系统的流程设计、系统的稳定运行，而对权限设计不够重视。

并且绝大多数权限设计是在系统建设时期，一方面由于当时对SAP权限管理缺乏全局意识，另一方面建设人员对于实际业务没有充分的认识，因此设计的权限难免会存在问题和风险。

本文将结合安徽电力SAP权限设计来阐述权限设计常存在的问题及解决方案。

一、企业用户权限存在问题
（1）没有一套清晰明确的授权规则。

企业用户量比较大，随着系统应用的深入，各种功能增加，用户都要求给自己增加权限。

这样对于权限管理人员来说，面对大量的申请似乎并不能找到一个明确的标准。

于是部门主管审批便成了一个最为有效的解决方案；
（2）用户权限有被逐渐放大甚至失控的危险。

SAP系统内的权限管理是以“角色”这一概念展开的，一个“角色”上分配了体现功能权限的一组功能事务码（T-Code）和体现限制的授权参数文件（profile）。

假如，在SAP 系统中给每位用户建立一个角色，并且此角色只分配给一个用户，那么某一角色内的某一个权限的变动也就不会对其他用户的权限产生任何影响。

但是，企业一
般都不会这样做，因为如果用户数量多的话，系统中角色体系就会过于庞杂。

而且同类型的用户角色之间的差异可能很小，这会导致数据的冗余变得很大。

一般的做法是在系统建立一套通用角色、复合角色、单一角色所构成的角色体系来进行授权。

也就是说，一个系统角色可分配给多个系统用户，这样就会出现某用户的需求而改动某一角色的权限，从而影响到此角色所对应的其他用户权限。

即此角色所对应的所有用户都会同时增大或减少权限；
（3）职责分离体系不能被有效建立和执行。

用户权限不仅决定谁有权做什么，而且还体现了权限之间的相互制约关系。

例如：有“价格主数据管理”权限的用户就不能同时拥有“票输入”权限，否则用户就可以随意修改发票上的价格信息如果同时给了这两个权限与同
一个用户就违背了“职责分离”原则；
（4）角色设计稿与实际系统的不一致的现象愈来愈严重。

在角色设计实现时，如发现需对角色进行修正，往往会直在系统中修改功能，并将此功能的权限赋予相关人员，而往忽略了同步修正角色设计稿。

久而久之，系统中真实角色就成了谁也说不清楚的“黑箱”。

这种“黑箱”情况对于系统的权限管理、内控管理、风险管理都会造成极大的问题。

二、解决方案
（1）在对用户进行授权时，应根据需求导向及最小授权原则。

对于用户的权限，以其实际工作需要为依据且仅应当授予其能够完成工作任务的最小权限。

用户的访问权限是指用户能够访问哪些资源或
执行哪些任务(或功能)的范围，从控制的角度考虑用户在系统中所拥有的权限是否超出了其工作需要。

而职责分离是把一个业务(子) 流程的工作内容分为几个职责不相容的部分并由不同的人来完成，避免因一个人拥有操作不相容业务的权限而产生舞弊风险，例如人力资源的整个流程可分为组织、人事、薪酬，人员的部门岗位数据由劳动组织专责维护，人事数据由人员管理专责维护，薪酬核算过账由薪酬专责维护，各阶段严格划分。

确立不相容岗位在正确设置用户ERP 系统岗位前，必须先理清企业用户实际岗位的不相容性。

一般按业务类型整理出如下一些普遍的不相容岗位。

如采购业务的不相容岗位、销售业务的不相容岗位、工程项目管理的不相容岗位、生产的不相容岗位、修理的不相容岗位、财务不相容岗位。

同时要通过建立不相容事务代码表，明晰哪些事务码之间会造成权限的职责不分离。

2.3 确定系统的关键权限
SAP 的关键权限也就是重要权限的事务码，用户拥有这些事务码的权限意味可以对系统做一些重要操作。

在这里有必要说明一下关于系统中几个关键权限的使用。

（1）se38 的控制。

这个权限可以允许用户在系统中直接运行程序。

虽然大多数自开发程序和报表都可以使用SE93 建立事务代码，但有时又确实需要se38 来运行一些特殊程序，如：sap的一些排错程序；生产系统做业务交易时出现ABAP 错误或其他莫名错误，通常对此种特定异常问题程序员最佳最便捷的手段是使用se38 对错
误进行跟踪；还有就是自定义的增强、函数或业务复杂的报表，必须有生产机上的业务数据才能判断，需要跟踪时用到SE38 权限。

为此我们需要在SE38 授权中，对权限对象s_develop 中作业字段只给予03 显示权限，对象名称字段限制用户使用的程序，对象类型只允许跟踪（DEBUG）和自开发程序（PROG）；
（2）谨慎开放SE16/SM30/se16n 权限。

SAP 中所有业务数据最终都保存在表格中，有了这两个表格查询权限，系统中包括敏感数据在内的所有业务数据都一览无遗。

SE16 用来查看表格，SM30 用来查看视图、se16n可以修改表数据。

若用户要对生产系统中自定义表进行维护，必须从开发机传输或做成事务代码进行维护。

2.4 正确设置用户岗位
对使用SAP 系统的企业来说，应先建立一套基于业务活动的系统权限管理规则。

对于某一用户，究竟应该拥有什么样的权限，首先取决于其在系统业务流程中所承担的角色及从事的业务活动。

而用户的岗位我们可以理解为某一类角色组合，即复合角色。

例如对于物流的用户，我们可以划分物流信息查询、物料主数据维护、供应商主数据维护、油罐主数据维护、库站预留管理、采购订单管理等岗位，一般分四步完成对用户岗位的设定。

（1）建立模块角色事务码对应表，也就是通用角色。

包含
的项目有：通用角色、角色描述、事务码、事务码描述等；
（2）根据通用角色建立模块本地角色。

包含的项目有：本地角色名称、本地角色名称描述、组织级别等；
（3）最后我们就可以按岗位给用户分配权限，即建立用户与岗位对照表。

给用户分配权限时，我们首先确定用户所属分公司，根据上面第三步建立的分公司岗位对照表，给用户分配相应岗位权限。

同时，建立SAP 系统用户清单，清单包含的项目有：用户SAP 帐号、用户姓名、所在公司、所属部门、工作职责描述、岗位编码等。

2.5 设立正确的审批流程
（1）权限的申请流程必须形成一个闭环，由用户填写申请表格开始经过审批到最后在系统内维护完毕，通知到申请者结束；
（2）用户填写申请表格时需描述清楚自己需要的权限和对应的系统岗位；
（3）权限的申请必须要得到用户部门负责人审批，一般部
门负责人结合上面建立的岗位对照表来审核用户权限申请是否合理；如果是新增的事务代码不存在之前建立的岗位对照表里或是需要修改角色的申请，还需要相关模块关键用户进行审核，以确定是否新增或修改角色、岗位等；
（4）不仅仅是新增权限需要审批，更改、删除权限也需要
审批；
（5）权限管理员在系统内的一切权限操作以用户申请表
为依据，这些申请文件需要妥善保存，因为IT 稽核的时候会
用到；
（6）权限管理员在系统给用户赋权限后，需要维护用户权
限清单，若角色或岗位有修改的，还需维护通用角色对照表、本地角色对照表、岗位与通用角色对照表等。

三、结语
通过对企业ERP 用户权限存在问题的分析，提出了一系列解决方案，并针对人工处理这些问题要花费大的工作量，设计了一个权限管理系统初步模型，以减少权限管理失控的风险。