SAP ERP系统用户权限实施与管理浅谈.docVIP

SAP ERP系统用户权限实施与管理浅谈 　　SAP系统用户权限管理或称授权管理是SAP 8ASIS的重要职责，因其工作量大且相对复杂，细致，在SAP系统中通常作为一个相对独立的部分来实施。国内常见的更多是权限技术配置方面的内容，少见整体阐释SAP系统实施和管理的文章。本文尝试从权限的基本概念、架构设计、系统实施以及运维以至用户安全审计等方面对SAP系统授权管理作一个相对系统、全面的介绍和探讨。 　　 　　一、sAP系统权限的概念 　　 　　SAP系统用户要完成某项工作需要运行相应的事务码，不同的事务码可以在系统中进行不同的动作。而权限问题的产生，是基于系统权限检查的机制：即用户在SAP系统中进行事务操作时，系统将会检查用户相应事务的权限。 　　SAP系统的权限控制是基于事务码(Transaction／Menu)和授权对象的，其中，通常所说的授权对象则是权限控制的最小单位。 　　换言之，一个事务码看似具有多种功能，但用户拥有某一事务码并不意味着拥有该事务码的所有功能权限，其权限大小受制于授权对象，因为权限对象(autho rization object)用于事务中详细的权限控制。以用户权限管理的事务码SU01为例，该事务码是用于用户主记录维护(transaction code SU01)的事务码，但通过控制授权对象S_USER_GRP不同赋值可以限制管理员用相应的权限进行的活动。比如赋予01，02值，可以用于用户的创建／更改：如果只赋予D3，则只可用于用户的显示，如果赋值D5，则可赋予冻结，解冻权限。完全由SU01所包含的权限对象控制。如果在企业拥有多个用户管理员的情况下，该权限对象还可以维护用户组的值，可以给不同的用户管理员配置不同的用户组维护权限，而未配置用户组的用户，所有用户管理员均可以加以维护。这一点对于集团企业不同层次用户管理权限的分配十分有用。 　　角色是SAP系统中权限的集合，可能包含一个或数个事务码，也可能包含一个或数个权限对象。同一类工作使用SAP的目的和常用的功能都是类似的，当我们把某类工作需要的权限都归到一个集合中 这个权限集合就是“角色”(Role)。 　　在SAP4.0版本以前，没有角色概念，只有参数文件(即Profile)，目前在授权管理的实践中已不再??行重点处理。为便于管理操作，就引进了角色。4.0以后开始用角色来做权限了。 　　SAP系统另一重要特点即权限是累加的。 　　用户可以拥有多个SAP角色，所有角色的权限累加在一起成为用户的最终权限。 比如，如果你拥有的角色中，其中一个角色有事务“角色管理PFCG”的显示权限，另一个角色有事务“用户管理PFCG”的更改权限。那么你总的就拥有角色显示和更改的权限。 　　 　　二、权限的设计架构及各类角色定义 　　 　　权限设计架构或称为角色的设计模式是SAP ERP系统权限管理的基础。相对完整的权限设计架构一般为三层架构模式。具体见下图： 　　 　　各层角色定义说明如下： 　　①公共角色(common RoLe)：也被称作通用角色，其中被赋予了相关的事务代码与操作权限，但是没有任何组织级别限制的角色。主要用来作为角色模板，被本地角色继承。 　　②本地角色(LocaL Role)：从通用角色继承而来，根据用户业务实际要求，限制在一定组织级别范围内使用的权限；特殊角色(Special Role)：指根据业务需要从所有其他角色中抽取出特定的权限对象单独加以赋值形成的角色。一般与其他角色组合生成特定的权限。 　　③岗位角色(Positlon Role)：指SAP系统的复合角色，是一系列本地角色以及特殊本地角色的集合，同HR的岗位相似。某类特定岗位的所有事务权限包含其中。在实践中往往结合企业的实际给予用户一个岗位角色或者多个岗位角色的权限。 　　由上述可知，公共角色是SAP系统权限的基本模板，是权限大厦的基石，由此继承派生的本地角色除了限制相应的组织级别外，权限功能点基本成形，一般不会有大的变化。而岗位角色在技术上看是对本地角色的打包，从管理上则尽量要求岗位角色所含权限的不可再分割性，这样，在实际授权时就可通过不可再分割的岗位角色组合完成，从而避免本地角色组合方式过多使授权混乱乃至不可操作。 　　权限设计架构是企业整体权限实施的核心，将贯穿SAP系统实施乃至后期运维工作的整个系统生命周期。如果不能牢固把握并坚持这一点，势必造成权限管理的混乱。 　　基于上述架构，在授权实践中，尤其在层次复杂的集团型企业，至少需要把握以下几点基本要求： 　　①各类角色设计须建立统一的编码规则，便于分类查询和系统管理； 　　②授权中系统不支持将事务码直接分配给用户的操作； 　　③一般情况下，只将岗位角色分配给用户，而不是本地角色或通