★ FEATURED ARTICLE 简介针对SAP系统实施与运维场景的审计程序清单适合IT审计师、SAP安全顾问及企业内控人员使用帮助建立系统化的SAP审计检查步骤。内容以结构化清单覆盖全流程先获取组织架构图、安全策略、应用架构图、问题追踪记录、待实施增强清单、开发方法论、服务级别协议、备份与灾难恢复计划接着确认SAP版本、已装模块、生产系统接口、客户端数量、地理分布与自定义开发程度并评估整体安全架构、操作系统及数据库环境。后续还要求提取公司、业务范围、信贷控制区、科目表、工厂、库存地点、采购与销售组织等主数据表清单并列出T000、T001、T042G等常用表路径涵盖制度审阅、环境确认与数据核查三大方面可帮助审计人员快速搭建工作底稿、避免遗漏关键控制点。资源仅含1个doc文档文件大小112KB已有410人参与学习。1. SAP审计程序是干什么的它不是写个ABAP那么简单在SAP系统里做审计最容易出现的误区是把审计程序等同于写一个ABAP报表。其实你真正要解决的是三件事权限能不能对得上、配置变更有没有留痕、职责分离有没有失效。很多刚接手SAP合规审计的开发者第一个需求往往是帮我把所有用户的权限拉出来看看——这确实是个审计动作但它只是最小的一步。把SAP系统审计程序做完整意味着你能在需要的时候拿出一份可解释、可留痕、可追溯的权限与变更证据链而不是靠OLR操作日志报告截图应付检查。本文从一个最务实的角度切入先用标准事务代码建立审计基线再写自定义程序覆盖标准程序的盲区最后把执行、调度、留痕和踩坑串成一套能长期跑下去的落地流程。适合刚接手SAP安全审计、被合规部门追着要权限报表或者准备做季度例行审计检查的开发者和系统管理员。2. 审计基线的第一步先用标准事务代码把事实捞出来很多人一上来就写自定义程序结果发现连用户主数据、角色权限的数据源头都没理清。SAP系统审计程序虽然叫程序但成熟的做法是先把手头能用的标准工具用透让标准输出替你验证自定义程序的正确性。我做SAP审计项目的习惯是先用标准事务代码拉出原始清单再针对清单里的疑点写自定义程序深挖。2.1 审计该看哪几张表核心数据源先记牢SAP权限审计绕不开几张标准表。USR02是用户主数据表记录登录账号、用户类型、失效日期、密码状态AGR_USERS存角色到用户的分配关系AGR_1252存角色里的权限对象授权对象明细USRGRP_USER是用户组与用户的关联。配置变更审计的重点则在TADIR对象目录、CDHDR/CDPOS变更文档抬头和明细、VBDATA业务数据变更之间。我自己在审计项目里常用的做法是先跑一段SQL确认基础数据量避免直接在未知环境里翻表。比如查一下USR02里有多少个用户这个数字如果异常比如比公司员工数还大得多后面所有审计结论都要打个问号。SELECT COUNT(*) AS USER_COUNT FROM USR02 WHERE USR02.USTYP A AND USR02.USTYP S;这段SQL区分了对话用户USTYPA的通常是Dialog用户、服务用户USTYPS是System用户把它们排除在外只统计真实的人用账号。逻辑说明用户类型字段USTYP在SAP里区分对话、系统、服务和参考用户如果不过滤查出来的数字会混入大量服务账号和后台作业账号。参数说明这里的排除条件可以按需调整比如很多客户希望把服务用户也纳入审查范围那就去掉WHERE条件里的过滤改成只排除参考用户。这个动作的价值在于帮你建立基线数字后面跑任何自定义程序先跟这个数字对一遍再继续。2.2 标准事务代码的组合用法SU01、SUIM、SE93、SM19标准事务代码里最常用的是SUIMUser Information System。它是个权限查询入口可以按用户、角色、权限对象、事务代码四种维度去查权限分配情况。SUIM比SU01好用在你不需要挨个用户去点开看直接在初始界面选Users by Complex Criteria或者Roles by Complex Criteria就能批量导出清单导出格式支持电子表格方便做二次加工。SU01是用户维护事务代码通常用来查单个用户的详细主数据比如密码过期时间、用户组、有效期。SE93是事务代码维护工具审计时用它核对某个敏感事务代码比如SE38、SE16N被分配给了哪些角色也用来反查某个角色名下有没有不该出现的事务代码。SM19和SM20是审计日志配置与分析的搭档SM19配置需要记录哪些审计类比如对话登录、RFC调用、事务开始SM20查看审计日志。很多新手不知道SM19默认是不开启的等收到审计要求时才想起来结果历史日志空白这个坑后文专门说。做季度审计时我的标准动作是先SUIM导出角色权限矩阵再用SE93抽查敏感事务代码的权限分配最后用SM20导出违规登录记录。这三样组合起来基本能覆盖管理层对SAP权限审计的八成诉求。2.3 标准输出的局限为什么还要写自定义程序标准程序能回答谁有什么权限但回答不了谁的权限越界了。比如一个采购员同时拥有采购和应付账款过账的权限这在职责分离上就是危险组合SUIM不会自动帮你判断这个组合是否违规。再比如角色被修改后旧版本权限和当前版本权限的差异对比标准报表也难做到按字段级输出。这时候自定义程序的价值就出现了把标准报表当成事实源用自己的ABAP程序跑出规则检查的结果两者比对决定最终审计结论。我用一句话总结这个阶段的工作标准事务代码负责捞数据自定义程序负责下结论。前者是黑匣子要相信它后者是你自己的逻辑要反复验证它。3. 自定义审计程序两个最常用的ABAP检查脚本当你明确知道标准程序的能力边界后就可以开始写自己的审计检查程序了。以下两个ABAP程序是我在权限审计项目里反复用到的原型它们不复杂但覆盖了SAP系统审计里最容易被查的两个方向权限重叠和配置变更留存。3.1 脚本一跨角色权限重叠检查这个程序解决的是一个用户通过多个角色累积了敏感权限的问题。SAP的权限校验是基于用户所有有效角色的并集所以单个角色可能看起来没问题但角色叠加后可能覆盖了不该有的权限对象。程序逻辑分三步先按用户汇总所有角色再按角色析出权限对象最后做权限对象的并集去重。REPORT z_audit_overlap. TYPES: BEGIN OF ty_usr_role, bname TYPE usr02-bname, agr_name TYPE agt_agrs-agr_name, END OF ty_usr_role. DATA: lt_usr_role TYPE STANDARD TABLE OF ty_usr_role, ls_usr_role TYPE ty_usr_role. DATA: lt_auth TYPE STANDARD TABLE OF agr_1252, ls_auth TYPE agr_1252. DATA: lt_result TYPE TABLE OF zaudit_result_line, ls_result LIKE LINE OF lt_result. SELECT u.bname, a.agr_name INTO CORRESPONDING FIELDS OF TABLE lt_usr_role FROM usr02 AS u INNER JOIN agt_agrs AS a ON a.uname u.bname WHERE u.ustyp IN (A,S). LOOP AT lt_usr_role INTO ls_usr_role. SELECT object_name INTO CORRESPONDING FIELDS OF TABLE lt_auth FROM agr_1252 WHERE agr_name ls_usr_role-agr_name. LOOP AT lt_auth INTO ls_auth. ls_result-bname ls_usr_role-bname. ls_result-agr_name ls_usr_role-agr_name. ls_result-object_name ls_auth-object_name. COLLECT ls_result INTO lt_result. ENDLOOP. CLEAR lt_auth. ENDLOOP.逻辑说明程序把用户和角色的关系拆开针对每个角色去AGR_1252表里取它拥有的权限对象授权对象。COLLECT语句在这里的作用是按用户、角色、权限对象进行去重累加最终输出一个用户在不同角色下到底叠加了哪些权限对象。参数说明这里的USER_TYPE过滤条件USTYP IN A,S保留对话用户和服务用户是因为它们都在实际业务里使用如果你只审计人用账号把S去掉即可。实际运行后把结果导出到电子表格用透视表按用户分组看权限对象出现的次数。出现两次以上不一定有问题但同一个权限对象在三个不同采购角色里都出现就说明这个用户的权限来源分散存在职责分离失效的风险。3.2 脚本二配置变更日志读取SAP配置变更记录分散在CDHDR变更抬头和CDPOS变更项目两张表里。CDHDR记录变更时间、变更用户、对象类、变更事务代码CDPOS记录具体字段的旧值和新值。第二个脚本做的事是指定一个时间段和一个对象类型把这段时间内的所有变更明细拉出来。REPORT z_audit_changelog. PARAMETERS: p_cdobj TYPE cdhdr-objectcl OBLIGATORY, p_date1 TYPE sy-datum DEFAULT sy-datum - 30, p_date2 TYPE sy-datum DEFAULT sy-datum. DATA: lt_hdr TYPE STANDARD TABLE OF cdhdr, lt_pos TYPE STANDARD TABLE OF cdpos. SELECT * INTO CORRESPONDING FIELDS OF TABLE lt_hdr FROM cdhdr WHERE objectcl p_cdobj AND udate BETWEEN p_date1 AND p_date2. IF lt_hdr IS NOT INITIAL. SELECT * INTO CORRESPONDING FIELDS OF TABLE lt_pos FROM cdpos WHERE objectcl p_cdobj AND udate BETWEEN p_date1 AND p_date2. ENDIF.逻辑说明CDHDR和CDPOS通过对象类型、对象ID和变更编号关联。先取抬头主表再取项目明细表是为了先确认这段时间确实有变更记录避免直接扫CDPOS在数据量大时性能失控。参数说明P_CDOBJ是对象类型例如R3TR是ABAP仓库对象VIMD是视图维护、SDIF是数据字典P_DATE1和P_DATE2是审计时间窗的起止日期默认查最近30天。这个脚本的输出在审计报告里非常直观某用户在某个时间点用某个事务代码改了什么配置字段、旧值是什么、新值是什么。有了它你就不再需要手工翻阅SAP系统的后台日志也避免了SM19只记录登录不记录配置变更的盲区。3.3 程序参数与复核逻辑跑出来的数据怎么判断可信自定义程序的输出必须做交叉验证不要直接当结论用。我一般对比三组数据程序输出结果、SUIM导出的角色权限清单、SE93查到的敏感事务代码分配情况。三者一致度在95%以上才会把结果放进审计报告。另一个复核逻辑是把程序中用到的表和字段一个一个确认。例如上面的第一个程序用到了AGT_AGRS表这个表在ECC和S/4里都存在但字段名在不同版本有差异第二个程序用到的CDPOS在数据量大时容易遇到归档问题如果系统做了日志归档CDPOS里查不到旧数据必须加上归档访问逻辑。初学者最容易踩的坑是拿标准文档里的字段名直接跑结果生产系统语法检查就报错所以我的习惯是在开发机先跑一遍确认字段和表都有效再上生产。4. 审计程序的执行、调度与留痕从手工查变成周期性跑写好了程序不等于审计流程建立起来了。很多团队在审计季来临前才手动跑一跑程序过了审计季就丢在一边。实际上SAP审计程序要发挥作用必须解决执行和调度的问题——谁在什么时候跑、结果放哪里、被谁看到了。4.1 手动执行与输出比对跑完不是结束手动执行阶段重点不是跑程序本身而是把每次执行的结果存下来与上一次执行的结果做比对。SA38ABAP程序执行或者SE38里直接执行你的审计程序后我建议立刻把输出另存为电子表格以系统日期为文件名存档。这样做的好处是下次审计时你能说出上次审计时这个权限是昨天新增的这种有过程性结论的话而不是只给出一堆截图。输出比对时我常用两个维度一是权限数据量变化用户数、角色数、权限对象数有没有明显波动二是敏感权限分布变化比如某个财务角色多出来一个删除会计凭证的事务代码。第一种波动可能来自正常的入职离职第二种波动基本一定有问题需要单独看变更记录是谁做的、有没有审批。4.2 后台作业调度定期把审计程序跑起来如果系统比较大手动跑程序容易影响性能也容易被人遗忘。常见做法是把审计程序放进后台作业SM36创建作业按周或按月定期执行。权限重叠检查我建议每月一次配置变更日志读取建议每周或每两周一次。调度作业时要注意一个时间参数不要在月末关账期间跑大数据量的审计程序SAP系统在月结时资源极度紧张审计程序跑挂是常态还会被财务团队投诉。调度作业的关键参数是输出设备。后台跑出来的列表不能直接看必须配置输出设备为电子表格邮件推送或者在程序里增加将结果写回自建日志表的逻辑。我的做法是程序里直接写一张自定义的审计结果表字段包括运行日期、运行用户、结果类型、结果内容摘要。这样后台作业跑完只需要查表就能看到历次审计结果。4.3 审计留痕日志、存根表与报表归档审计程序本身也需要留痕。这里的留痕有两层一是程序运行日志包括谁在什么时候执行了审计程序二是审计结论的存根即每次审计程序输出的结果不能被随意覆盖。SAP的ABAP程序运行记录在系统日志里能查到但不够直观我会在自定义审计程序里主动写一条运行记录表记录执行者、执行时间、执行参数和结果状态。报表归档方面我常用的做法是把每次程序输出压缩成文本存为SAP报表树节点SE54其实常见做法是直接用SAVE TEXT存到表里或者在文件服务器上按月份建目录归档。归档目录的命名统一用审计周期加系统环境例如audit_202501_prod避免一年后连自己也找不到之前的审计结果。档案至少保留两个完整审计周期这是为了应对合规复查。5. SAP审计程序落地避坑五类高频翻车现场这一章专门写踩坑记录。每一个都是我在项目里真实遇到或者帮别人排查过的典型问题按现象→原因→解决来写。5.1 权限组被改了但审计没抓到现象审计报告显示某个角色的权限没有变化但业务人员确实反映无法再做某个操作了最后发现角色名没变权限对象也没变但权限对象里面的组织级别值变了比如公司代码从1000改成了2000。原因审计程序只对比了AGR_1252里的对象名称没有对比具体字段值LOW/HIGH字段。AGR_1252存的是授权对象名真正的细节在AGR_1251里如果程序没抓这一层等于只看了角色壳子。解决把授权对象的字段级明细也加入对比权限变化判断要基于对象名字段名从值到值这四项组合。5.2 CDPOS数据缺失导致配置审计全是空白现象配置变更审计脚本一跑几十个对象类型全部无记录但系统里明明有人改过后台配置。原因CDHDR/CDPOS是物理表但很多系统启用了归档策略超过一定期限的日志被归档到了归档文件里普通SELECT查不到另一个常见原因是审计对象类填错。解决在程序里不只读在线表还要查归档信息结构例如用ARC_GET_TABLE或者直接把审计周期缩短到归档策略允许的范围内。更稳妥的办法是改用SAP标准的审计日志SM19/SM20来做配置审计但注意SM19默认也没开启需要提前配置好审计类。5.3 后台作业跑一半挂掉下次执行数据错乱现象月度权限重合审计作业跑了两个小时第二天发现作业状态异常重新执行时发现结果表里出现了重复数据审计结论被污染。原因程序没有做执行前清理每次运行前没有删除上一轮的结果数据而作业取消时数据只写入了一部分导致新旧数据混在一起。解决在程序开头加清理逻辑每次执行先把属于同一审计周期和同一运行标识的旧结果删掉再跑新数据。同时增加运行标识字段每次作业用一个随机编号或者时间戳区分。5.4 把开发系统当审计数据源生产数据对不上现象审计人员在开发环境模拟项目X环境跑了权限重叠检查发现生产系统的重要角色缺失向上汇报后被业务部门驳斥。原因开发系统和生产系统的角色分配、用户数据不同步而且很多开发系统里只有测试用户或者角色对象不完整。解决凡是涉及权限的审计程序必须连接生产系统PRD执行。开发环境只用来调试代码正式审计结果一律以生产系统为准并且在报告里明确标注数据来源系统实例。5.5 审计程序本身权限太大成了安全漏洞现象审计程序是给安全团队用的但开发时为了方便直接把SAP_ALL分配给了执行者结果程序运行用户拥有全部权限变成了比审计对象还危险的账号。原因没有按最小权限原则设计程序授权也没有考虑审计程序账号被滥用的风险。解决为审计程序单独建专用账号只给查询相关表的权限不给修改、删除权限。程序里禁止使用动态生成并执行ABAP语句的方式拼接SQL——这在审计程序里是禁忌别人可以通过注入参数扩大权限。6. 进阶把审计程序沉淀成可持续检查的自动化套路到了这个阶段程序本身已经稳定了真正需要的是把审计从一次性的项目变成周期性的流程。我通常会在自建审计表里加一个规则字段。比如权限重叠检查-财务这条规则每次运行的输出结果里出现新的重叠组合就自动标记为待复核。这样月复一月你手里会沉淀出属于你们系统的权限风险基线而不是每次审计都在查重复的问题。某个权限重叠组合连续三个月出现且一直没被处理基本可以判断它背后有合理的业务原因也方便下次审计时向管理层解释。另一个实用技巧是为审计程序加上异常通知。后台作业结束后用SAP Mail发给审计联系人邮件正文只放摘要本次检查用户总数、权限对象重叠数、配置变更条目数、与上次相比的增量。这样不需要登录系统就能知道审计状态这也是把程序变成体系的关键一步。我更想强调的一点是SAP审计程序的价值不在于代码写得多精巧而在于你把审计结论做成了可对比、可追溯、可解释的东西。权限审计不是一次性清点持续检查的习惯比程序本身值钱得多。希望这套落地方案和踩坑记录能帮到你少走我当年走过的弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
