企业官网建设流程全解析

简介：针对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区分了对话用户（USTYP='A'的通常是Dialog用户）、服务用户（USTYP='S'是System用户），把它们排除在外，只统计真实的人用账号。逻辑说明：用户类型字段USTYP在SAP里区分对话、系统、服务和参考用户，如果不过滤，查出来的数字会混入大量服务账号和后台作业账号。参数说明：这里的排除条件可以按需调整，比如很多客户希望把服务用户也纳入审查范围，那就去掉WHERE条件里的过滤，改成只排除参考用户。这个动作的价值在于帮你建立"基线数字"，后面跑任何自定义程序，先跟这个数字对一遍再继续。

2.2 标准事务代码的组合用法：SU01、SUIM、SE93、SM19

标准事务代码里，最常用的是SUIM（User 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 手动执行与输出比对：跑完不是结束

手动执行阶段，重点不是跑程序本身，而是把每次执行的结果存下来，与上一次执行的结果做比对。SA38（ABAP程序执行）或者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审计程序的价值不在于代码写得多精巧，而在于你把审计结论做成了可对比、可追溯、可解释的东西。权限审计不是一次性清点，持续检查的习惯比程序本身值钱得多。希望这套落地方案和踩坑记录能帮到你，少走我当年走过的弯路。

本文还有配套的精品资源，点击获取