简介面向SAP系统审计的专业检查表适合IT审计人员、内控合规专员及SAP安全顾问参考使用。文档以标准审计流程为基础系统梳理了前期准备阶段的通用步骤从获取公司组织架构图、安全策略与程序、SAP应用架构图、问题记录、SLA到应急与灾难恢复计划再到确认SAP版本、已装模块、生产接口、客户端数量、地理位置及定制编程程度等完整覆盖系统安全与合规审查的关键切入点同时列出通过SE16/SE17查询T000、T001、T014、T024等系统表获取公司、信用控制区、工厂、采购组织、销售组织等业务对象清单的方法便于审计人员快速搭建可复用的审计底稿。整个压缩包内共包含1个doc文档包体大小112KB条件编号规范、结构清晰适合打印或导入审计工作平台。当前已有408人学习浏览说明该清单在实务中具有一定参考价值。对于计划建立SAP审计体系、开展合规评估或内部风险检查的团队这份程序清单能辅助减少遗漏环节、明确核查顺序提升审计工作的系统性和效率。1. SAP 审计程序到底是什么值不值得做审计这个词在 SAP 项目里出现大多数人第一反应是权限报表、登录日志或者是外部审计要的那张用户清单。其实这套叫“审计信息系统Audit Information System”的东西是一堆藏在 SE38/SA38 里的标准报表程序配合事务码 SUIM、STMS、SE01 一起用能回答三个很难缠的问题谁在生产系统里做了什么、改配置之前有没有经过变更流程、职责分离有没有被打破。SAP 审计程序不是单个事务码是一套“拿程序去读系统状态和日志”的方法集合。适合三类人内部审计和 IT 合规岗位、SAP Basis、还有被外部审计追着要证据的 FICO 和权限顾问。本文讲的方案不依赖额外授权和第三方工具标准系统就能跑。2. 先拿标准审计信息系统开刀SA38 跑通核心审计报表与参数2.1 审计信息系统里的报表哪里找SUIM 与 SA38 的衔接SAP 把审计相关的标准报表统一挂在事务码 SUIM用户信息系统下面路径是“用户和角色 → 信息系统”。这个地方不是用来直接跑程序的它更像一个报表目录和启动器选好你要的审计主题它会自动带出对应的报表名称然后你把报表名抄下来到 SA38 里跑。为什么强调 SA38 而不是 SE38SA38 是“执行报表”专用事务码SE38 是“查看 ABAP 程序源码”用的。很多刚开始做审计的顾问一进 SE38 就蒙了看到一堆源码不敢动其实跑审计程序根本不需要看源码SA38 直接输入程序名就行。我个人的习惯是先在 SUIM 定位报表把报表名单截图存档然后用 SA38 变式跑这样交付材料里既有“用了哪个报表”的截图也有执行结果。核心报表清单建议先记住这几个报表程序用途关键输入RSUMP105系统审计日志客户端、日期、用户RSUSR002密码与锁定日志分析用户、日期范围RSUSR003权限对象失效分析用户/角色权限对象RSUSR003D角色权限比对报告角色名称USMMCOLL权限升级比对升级前后系统、日期这些都是标准程序不是自开发只要事务码有权限就能跑。有些报表有变式变式就是一组保存好的选择屏幕参数建议第一次先不要套变式把参数输在屏幕上看默认输出长什么样再决定保存什么变式。2.2 锁定日志泄露了什么RSUSR002 的最小用法生产系统里用户被锁多数情况是多次输错密码或者管理员手工锁的但审计视角下RSUSR002 要回答的是“锁得太频繁的用户是不是在撞库”。RSUSR002 的输入界面不长需要特别注意“最近登录日期”和“锁定日期”这两个生命周期的字段。运行界面如下程序RSUSR002 客户端800 用户留空表示全部用户 锁定日期从/到留空表示不限 最近登录日期从/到建议填半年内的区间运行后输出是一张 ALV 列表字段包括用户、锁定次数、最后锁定时间、最后登录时间和解锁人。这段报表输出要重点看两个维度一个是锁定次数异常多的用户另一个是“最后锁定时间”和“最后登录时间”落在凌晨的账号。前者代表疑似暴力破解后者代表管理员半夜还在做权限调整如果系统里没有对应的变更请求就值得展开查。这里有个容易被忽略的地方RSUSR002 不是把所有锁定历史都列出来了它读的是表 USR41 和 USR02 的快照。USR41 存的是登录尝试失败的记录USR02 是用户主记录。也就是说这个报表只能看到“现在还有印象”的记录如果你发现锁定数据被周期性清理过需要提前把报告归档成文件否则下个月再跑可能什么都查不到。2.3 谁动了权限对象RSUSR003 与 RSUSR003D 参数对照RSUSR003 是权限审计里出场率最高的报表它能扫出“某个权限对象在用户/角色上的值”来判断敏感权限是不是分给了不该拿的人。输入界面有“权限对象”输入框比如你想查 S_TCODE事务码执行权限可以把参数这样填权限对象S_TCODE 事务代码SE01、SE09、SE38、SA38 用户名留空 角色留空这段填法会输出所有能执行这几个事务码的用户和角色审计目标很明确SE38/SA38 是程序和报表入口SE01/SE09 是传输请求管理入口能把这几个事务码同时握在手里的人相当于拿到了生产系统的改动权在职责分离里应该被标红。RSUSR003D 是带角色对比的变体它会列出“角色应有权限”和“实际有效权限”的差异一般用于月度权限复核。跑的时候建议把“显示失效权限对象”勾上因为历史角色里经常会残留已被删除的权限对象这些是标准程序在升级后最常见的权限漏洞来源。2.4 三个你迟早要会的参数变式、后台执行与输出格式审计程序跑得多了就会发现每次都要重新填一堆日期和用户条件而且 ALV 结果直接展示在屏幕上数据量一大就容易超时。标准做法是给报表建变式再放到后台作业里跑。创建变式的方法是在 SA38 输入程序名之后选择“执行 后台执行”系统会先进选择屏幕界面填完参数后点“保存变式”按钮变式名建议用 Z 开头并带有审计语义。变式名Z_AUDIT_USR002_MONTH 描述每月权限锁定用户列表 参数客户端800、日期区间为上月1日至上月最后一天后台执行前还有一个输出格式的坑ALV 报表后台跑完只有生成 ABAP 列表和 E-mail 两个出口。如果你选了 ABAP 列表结果会以文本形式存在 SP01 输出控制器里导出时会有字段挤在一起的问题。更干净的做法是在输出格式里选“电子表格格式”系统会生成一个可以被前端下载的 .XLS 文件审计日志归档起来字段分列清晰后续筛选也方便。后台作业的调度和结果查看放在第 6 章统一说但这里先记住一个原则审计报表尽量不要在白天在线跑尤其是 RSUSR003 扫全库权限时生产系统高峰期跑它纯属给自己找麻烦。3. 权限审计与职责分离用 SUIM 把风险用户捞出来3.1 SUIM 是权限审计的主入口不只是报表列表前文说了 SUIM 是报表目录但它同时也是权限分析工作台。进入 SUIM 之后左侧有“用户”、“角色”、“权限对象”、“复合角色”等入口审计顾问的日常工作顺序通常是这样的第一步用“用户 → 按权限对象查询用户”查敏感权限第二步用“角色 → 按事务码查询角色”查某个事务码在哪几个角色里第三步把结果导出成清单和业务岗位表做比对。SUIM 的检索逻辑基于表 USR02、AGR_* 系列权限表所以它查出来的不是“声称的权限”而是“权限参数表里实际存在的权限”这是它比手动维护的权限台账可信的原因。实操里我习惯先把 SUIM 里“权限对象分配”的报表名单抄到本地S_TCODE 事务码权限 S_USER_GRP 用户组维护权限 S_TABU_DIS 表维护权限SE16N/SE11 S_DEVELOP 开发对象权限 S_PROGRAM ABAP 程序执行权限只要这个清单在手上外部审计问“你们怎么控制生产机改动”的时候你能立刻说清楚查这些对象就能知道谁有开发事务码、谁有传输请求管理、谁有表维护权。这三个权限合在一起就是生产系统“能改配置、能传输、能直接改表”的三把钥匙职责分离审计的核心就是保证三把钥匙不在同一个人手里。3.2 角色比对自开发角色与标准角色的权限差很多项目出问题是出在角色套拷贝顾问拿着 Z 开头自开发角色直接复制一个 Z_COPY_YEAR再改个描述就给人赋上从来不看权限范围有没有被放大。SUIM 的“角色 → 角色比较”功能能解决这个它能对比两个角色的事务码差异。操作路径SUIM → 用户和角色 → 信息系统 → 角色 → 按事务码比较角色。比较结果是一张差分表左边角色、右边角色、中间是差异项。这个场景在审计报告中特别有说服力因为外部审计要的不是“我们权限很规范”而是“这三个月里每个人的权限变化记录”角色差分表正好补上这个空档。如果甲方环境里自开发角色特别多比较页面里可以勾选“仅显示差异”优先处理那些只改了一个 Z 前缀的衍生角色。这时候你会频繁遇到一个边界某个角色多了一个 S_TABU_DIS 里对表 ZT001 的授权看起来人畜无害但如果 ZT001 里存的是采购价格这就在职责分离上踩线了。因此 SUIM 差分结果最好导入 Excel 后人工过一遍“敏感表清单”不要指望报表直接告诉你安全还是不安全。3.3 职责分离冲突矩阵三个最经典的组合职责分离SoD是所有权限审计里最让人头疼的部分。标准审计程序不直接给出“这俩人职责冲突”的结论它只给原始权限数据冲突与否需要你自己建矩阵。常见做法是建一张冲突矩阵表将采购、应付、总账三个模块的权力点拆开编号高风险组合对应事务码风险描述01创建供应商 过账应付发票FK01 FB60虚设供应商并付款02维护物料价格 创建物料主数据MR21 MM01人为抬高成本03创建用户 维护角色SU01 PFCG造账号并授重权用 SUIM 按事务码查询每个组合对应的用户数然后把两个集合交叉交叉出来的用户就去人工确认岗位。这里要提醒一句不要凭 S_TCODE 一个对象就下“职责冲突”结论。比如 SU01 和 PFCG 同时有但公司里用户账号由 IT 部管、角色申请流程有 OA 审批只是同一个人执行了创建和授权两步物理上是同一个人操作的这种情况最好加一个“是否有独立审批记录”的补充说明否则报告里会出现一大堆假阳性冲突。ABAP 顾问这时候可以用简单取数逻辑把明显的冲突拉出来SELECT a.bname, COUNT(DISTINCT a.tcode) FROM usr12 a JOIN agr_users b ON a.mandt b.mandt AND a.bname b.uname WHERE a.tcode IN (SU01,PFCG,FK01,FB60) GROUP BY a.bname HAVING COUNT(DISTINCT a.tcode) 2这段 SQL 的含义是从权限表 USR12 里找出同时拥有两本敏感事务码的用户结果会帮我们缩小排查范围。注意 USR12 直接查事务码权限是有缺陷的因为权限可能是通过更细的权限对象控制的它只能作为初筛不能作为最终审计证据。最终交付还是要以 SUIM 的标准报表为准。3.4 把权限报表导出成可交付的清单到这里你已经拿到了三份东西SUIM 按权限对象查出的用户清单、角色差分结果、SoD 交叉用户清单。下一步是导出成可交付物。SUIM 报表输出到 ALV 之后路径是“列表 → 导出 → 电子表格”或者用“本地文件”直接存 CSV。这里有个血泪经验导出的 Excel 里中文注释乱码原因是 SAP 的 CSV 默认用系统代码页导出Excel 打开时按 UTF-8 或 GBK 猜编码十次有两次对不上。解决乱码的办法是导出时选择“电子表格格式”而不是“本地文件”或者在导出界面里手动改代码页为 4103UTF-8。如果不是特别大的清单建议优先用“电子表格格式”它会生成一个带格式的表格文件字段对齐也比 CSV 好。交付件建议命名成带审计周期的例如权限审计_20250701_用户权限矩阵.xlsx里面至少放四张工作表敏感对象用户清单、角色差异明细、SoD 冲突清单、程序运行日志含报表名、变式号、运行时间。第四张表最容易被忽略但在外部审计追查“你这个结论是哪来的”的时候程序运行日志就是你的后悔药。4. 传输与变更审计追到请求头、跑完的表和配置4.1 传输请求的审计入口SE01/SE09 与 TMS 日志权限审计管的是“账号和权限”变更审计管的是“代码和配置有没有走合法通道进生产”。SAP 里每个变更都要落在一个传输请求上运输到生产系统后STMS 会有导入记录。这块审计绕不开两个界面SE01变更和传输组织器、STMS传输管理系统。外部审计一般直接问三件事谁创建了请求内容是什么什么时候导入到生产。SE01 上能看到请求头和任务头里的创建者用户名、创建日期、目标系统双击任务能看到对象列表程序、表、配置条目。如果你只需要简单抽查用 SE01 的搜索功能可以按用户、按日期、按请求状态过滤出一段时间的请求清单然后挑几个重点请求去看对象明细。但注意一个边界SE01 看到的是在线内容真正的“什么时候成功导入到生产”要去 STMS 里看。STMS 的界面路径是传输系统概览 → 系统 → 导入历史。导入历史里每一行都有传输请求号、导入时间、导入用户、返回码。审计取证时这两张截图要成对使用只有请求没有导入记录等于这个变更停在了半路上。4.2 用 STMS 看导入历史的字段怎么判断成功还是失败STMS 导入历史界面的关键字段包括请求号、状态已完成/出错/部分完成、返回码、定向导入时间、导入者。外部审计盯得最多的就是返回码返回码含义审计含义0导入成功变更已生效4有警告功能可能有偏差要复核8有错误导入失败或部分失败12致命错误目标系统可能受影响返回码 4 最容易翻车因为 SAP 把警告也算作“黄色”状态很多 Basis 就认为“好像过去了”其实里面的配置条目可能被跳过。审计时如果发现批量导入后有多个 4最好展开请求内容逐个查看每个对象的处理结果不能只看请求头。有的环境里 Basis 会把导入历史日志定期归档到应用服务器上路径类似 /usr/sap/trans/log/。这个目录下的日志文件保留着早期导入细节是 STMS 界面被清理之后仍然存在的底层证据。审计顾问如果能拿到文件系统访问权优先把传输日志目录整个拷贝下来做长期留档。4.3 表历史记录查 TST01/TST02 定位变更对象传输请求的元数据存在表 TST01请求头和 TST02请求任务里。当 SE01 界面因为权限或缓存问题打不开时审计可以退一步直接查表。用 SE16 打开 TST01按照请求号、创建者、创建日期查询。SELECT * FROM tst01 WHERE trfunction K AND trstatus IN (D,L) AND tsdate BETWEEN 20250501 AND 20250630这段取数的含义TRFUNCTION K 表示配置请求TRSTATUS D 表示已完成、L 表示已释放Release 导出。查出这段时间内完成的配置类请求就能拿到一个“到底多少人直接改了配置还没传输”的审计起点。如果查出有请求状态是“可编辑”而日期在一个月前这说明它一直没导出也可能是传输路径卡住了这类请求要重点看是不是被遗忘了。TST02 是任务层一个请求头下挂多个任务。审计口径是谁创建的任务多谁就是这段时间生产变更的高频操作者。取数方式相同按任务创建者分组统计SELECT AS4USER, COUNT(*) FROM tst02 WHERE trkorr IN (SELECT trkorr FROM tst01 WHERE tsdate BETWEEN 20250501 AND 20250630) GROUP BY AS4USER ORDER BY COUNT(*) DESC这两段 SQL 在任何系统里都能跑不需要额外权限只要 SE16 能看到 TST01/TST02 即可。配合 STMS 导入历史就能织出一张时间线谁在什么时候从哪个开发系统导了什么什么时候进的生产。4.4 从请求号反查变更对象一个可抄的查法审计报告里最常写的一句话是“此事经核实变更已通过请求号 XXXX 导入生产”。要支撑这句话需要把请求里的对象清单也列出来尤其是配置条目。传输请求中的配置条目并不直接存在某个屋里人一眼能看的表里它们分布在各个配置表上因此更稳妥的做法是去 TSTOB请求对象表里查。TSTOB 的字段包含请求号TRKORR、对象类型OBJTYPE、对象名OBJNAME。例如要查请求号 C10K900001 里带哪些表SELECT * FROM tstob WHERE trkorr C10K900001 AND objtype TABUOBJTYPE TABU 表示表/视图维护条目配置条目这是权限审计和配置审计最关心的类型。这个查询结果出来后你再去 SE11/SE16 看那条配置具体是什么内容前后对比一下值变动就能写进审计发现里。注意一点传输请求对象表有了之后不代表配置一定生效生效与否还是要以目标系统的 STMS 导入返回码为准所以这串取数路径要完整走下来。5. 审计程序的四个经典坑现象、原因与解法5.1 审计报表没数据先查参数别急着提工单现象RSUMP105系统审计日志跑出来结果为空一张空 ALV 摆在那看起来像报表坏了。原因系统审计日志默认在客户端级别是关闭的参数 rsau/enable 为 NO或者 AUDIT 相关参数没有打开所以日志里本来就没东西。解决到 RZ11 里检查参数 rsau/enable 和 rsau/audit_level生产系统要打开审计日志建议先把参数写到实例配置文件里而不是用 RZ11 在线改在线改在重启后会丢。改完后让业务系统重新产生几条记录再跑报表验证。5.2 SUIM 查角色超时换后台不是换系统现象SUIM 里查“按事务码角色对比”点执行后前端一直转圈最后报出“RFC 超时”或“内存资源不足”。原因这个报表要跨 AGR_1251、AGR_1252、AGR_USERS 等多张权限表做全表关联角色一到几千个在线查询扛不住。解决不要在 SUIM 里硬等按前文的方式从 SUIM 里抄报表名到 SA38 里用变式加后台执行跑完的作业结果在 SM37 里看既拿到结果又不卡界面。另外一个减少数据量的办法是把日期过滤范围缩小到只查最近三个月变动的角色。5.3 日志中文乱码和导出错位的落差现象RSUSR002 导出的 Excel 里用户全名显示成乱码叫“张伟”变成“寮犱集”。原因导出时 CSV 使用 SAP 系统代码页默认编码而系统代码页跟 Excel 预期不符合。解决导出时用“电子表格格式”而不是“本地文件”如果一定要 CSV在导出对话框里选择代码页 8400Unicode或者导出后在本地用 UTF-8 重新保存成 xlsx。乱码问题在中文项目里太常见了几乎每个审计周期都会碰到一次养成导出后先开一个小窗口抽查内容再转存的习惯。5.4 权限对象被删日志跟着失踪现象RSUSR003 跑出来有历史用户但点进个人信息里某些权限对象报“对象不在权限表中”接着整条记录消失。原因标准 SAP 版本升级或权限对象清理时删掉了系统里已无定义的权限对象而历史角色还在引用。解决先把 RSUSR003 的输出全部导成 Excel 再做透视不要依赖在线 ALV 的二次展开同时在报告中单独列一节“失效权限对象的数量”告诉业务方这是升级残留不是有人恶意删权限。5.5 传输请求被物理删除的追溯现象SE01 里查某月请求发现最早的请求已经被归档或者被物理删除屏幕上只留一团空白审计线索中断。原因SAP 默认保留请求没有时长限制但如果做了传输请求压缩或手工删除历史就被清掉了。解决优先用 STMS 的导入历史日志和 /usr/sap/trans/log/ 目录下的文件作为备胎这些文件系统日志不会跟随 SE01 的删除而消失。如果文件系统也没有那就只能按配置表的值变更时间来反推比如查 CDHDR 变更凭证里的时间和用户名再对照考勤记录人工核实。提示查 CDHDR 只能看到开了 Table Logging 的表不是每条配置都有变更凭证。审计取证时先确认表有没有开日志没开就用 STMS 日志兜底。6. 把审计程序变成定期作业变式、后台调度与验证6.1 先确定审计范围程序矩阵 表清单任何自动化之前先别急着排作业先确定“这个系统审计程序到底覆盖什么范围”。常见做法是把程序矩阵表列出来每一条对应一个审计目标、一个报表程序、一个变式、一个调度周期。例如 RSUSR002 每月跑一次RSUSR003 每季度跑一次传输请求抓取每周跑一次。另外把直接查表获取证据的 SQL 也保存成脚本或查询变式如 SE16 的视图变式。这个矩阵本身就是审计制度的一部分交付时比一堆临时报告更有说服力。6.2 用变式做定期作业的配置步骤调度作业用 SM36 建步骤很固定。先定义作业名如 Z_AUDIT_RSUSR003_Q然后把 SA38 的变式作为作业第一步放进去变式和报表程序都要对应正确。作业建好后用 SM37 监控运行状态。我通常会把作业步骤写成这样的注释清单放在交付目录里SM36 作业名Z_AUDIT_QUATER 第一步ABAP 程序 RSUSR003变式 Z_AUDIT_R003_Q1 第二步ABAP 程序 RSUSR003D变式 Z_AUDIT_R003D_Q1 作业周期每季度的最后一天 22:00 执行调度的周期设置建议避开月末结账和月结批处理时间审计作业是读数据的活跟月结抢资源容易把生产过程拖缓。执行结果如果不满意可以直接在 SM37 里重跑同一变式不需要重新建作业。6.3 验证审计程序抓到的东西对不对自动化之后最关键的是验证不要跑完就发。验证方法很简单故意做一个触发器。比如在测试客户端或开发系统里用某个审计账号创建一个新用户并赋角色然后跑一遍 RSUSR003看报表能不能抓到这次变化。再比如改一条配置表的记录跑 TST01/TST02 取数看能不能看到对应请求头。只有触发器能被报表抓回来整个链路才算通。外部审计来的时候给他们现场演示“刚才建了一个用户点一下报表立即出现”这个过程比任何书面承诺都有力。我个人的习惯是每次审计周期都保留一张“验证日志”表记录验证日期、验证动作、对应报表、是否匹配。这张表看着麻烦但在一次次外部审计里帮我省了很多解释的口舌。这几年做下来最大的教训是审计程序跑得再多不如把每一次跑的变式、导出文件、验证记录和证据表存得整整齐齐。数据会过期人也会记错但一份带时间戳、带变式号、带返回码的取证链谁都推翻不了。希望这篇 SAP 系统审计程序的拆解能帮你在下一次审计里少走点弯路把手上的报表真正用起来。本文还有配套的精品资源点击获取