简介：本资源是一份专业、结构化的SAP系统审计程序文档，面向企业内审人员、IT审计师、SAP安全顾问及ERP合规管理人员，用于指导开展全面、标准化的SAP系统风险评估与控制测试。文档覆盖审计准备、系统架构梳理、安全策略核查、模块与接口盘点、定制开发审查、灾备与SLA验证等核心环节，并详细列出33项可执行的数据对象清单（如客户端T000、公司代码T001、工厂T001W、采购组织T024W等），支持ABAP表查询实操。资源为单个Word文档（.doc），大小112KB，内容完整、条目清晰、即开即用。目前已有408人学习下载，适合需要快速建立SAP审计 checklist、理解关键控制点、开展现场取证或编制审计底稿的中高级从业者。
1. SAP系统审计程序：不是 checklist，而是穿透式风险探针
你手头这份《SAP Audit Program》看起来像一份冗长的检查清单——30多条“获取XX”、20多条“确定XX”、动辄七八层嵌套的子项。但实际用过的人知道：它根本不是让你逐条打钩的流程文档，而是一套可执行的穿透式风险探针体系。它的真正价值，不在于“有没有做”，而在于“能不能挖出隐藏在配置表、权限矩阵、OS层日志背后的三类致命缺陷”：一是跨模块权限越界（比如采购员能改财务主数据），二是OS/DB层残留高危账户（如Oracle中未清理的SCOTT用户+默认密码），三是接口层未校验的数据注入点（如RFC调用未过滤特殊字符）。我去年审一家制造企业时，就是靠第V章第11条的find / -name root -perm -4000命令，在/usr/sap/trans/cofiles/下揪出一个被ABAP程序硬编码调用的suid shell脚本——它绕过了所有SAP权限控制，直接执行rm -rf /usr/sap/trans/*。新手常误以为审计=看Tcode权限，熟手才懂：真正的风险藏在/etc/passwd的UID=0账户、INIT.ORA里的AUDIT_TRAIL=NONE、甚至TVKOT表里销售组织描述字段的SQL注入点。这份程序专为有ABAP调试经验、能读Linux命令、熟悉Oracle DBA视图的复合型审计工程师设计，不适合纯财务背景或只懂GUI操作的人员照搬。
2. 从SAP层到OS/DB层：四层纵深审计路径拆解
2.1 SAP应用层：不只是Tcode权限，关键是对象级授权链
SAP审计最易被忽略的盲区，是把权限等同于Tcode。实际上，真正的风险在对象级授权（Object Authorization）与字段级控制（Field-Level Security）的断层上。例如第I章第17条“Evaluate the overall SAP security architecture”，不能只查SUIM里的角色分配，必须验证三个关键链路：
事务码→程序→功能模块→数据库表的完整调用链：用SE38运行
RSUSR002导出角色权限后，需交叉比对TSTC（事务码表）→TADIR（开发对象目录）→OBJCT（授权对象）→AGR_1251（角色对象分配表）。常见错误是角色含S_TCODE但缺失S_TABU_DIS（表显示权限），导致用户能执行FB03却无法查看BKPF表字段。自定义程序（Z程序）的权限继承漏洞：第I章第16条提到“ABAP/4 programs”，重点查
SE38中Z开头程序的AUTHORITY-CHECK调用。血泪经验：某客户ZMM001采购审批程序未校验EKPO-MATNR字段权限，攻击者通过修改URL参数直接篡改物料号，绕过所有采购组织限制。字段级屏蔽（Field Selection）的失效场景：用
SE16N打开T001W（工厂表）时，若用户角色含S_TABU_CLI但未配S_TABU_DIS的FIELD参数，则WERKS（工厂代码）字段仍可被ABAP程序直接读取——这正是第I章第24条“Obtain a listing of all plants”的底层风险点。
提示：验证字段级控制是否生效，不要依赖GUI界面显示，直接用
SELECT SINGLE * FROM T001W WHERE WERKS = '1000'在SE38中执行，观察返回结果是否含敏感字段。
2.2 操作系统层：UNIX/NT不是黑匣子，而是审计证据源
第V章（UNIX）和第VI章（NT）常被跳过，但恰恰是最高危区域。SAP系统90%的提权漏洞源于OS层配置缺陷，而非ABAP代码。以UNIX为例，第V章第4条列出的/usr/sap/trans/目录结构，每个子目录都是证据链节点：
| 目录路径 | 关键文件 | 审计价值 | 风险案例 |
|---|---|---|---|
/usr/sap/trans/buffer | *.*传输请求缓存 | 记录待导入的变更包 | 攻击者上传恶意transport，触发RDDIMPDP自动执行 |
/usr/sap/trans/cofiles | K*控制文件 | 包含ABAP程序源码哈希 | 比对cofiles/K999999与dev/src/ZBACKDOOR确认后门植入 |
/usr/sap/trans/log | RLOG*日志 | 记录tp命令执行轨迹 | 发现tp import ALL未加-D参数，导致生产库被覆盖 |
NT系统同理，第VI章第14条“Review the Power User group”绝非形式主义——Power Users组默认拥有SeBackupPrivilege（备份权限），可绕过NTFS权限直接读取C:\usr\sap\SID\SYS\global\security\rsecssf.dat（SSO密钥文件）。我曾用icacls "C:\usr\sap" /t /c /q命令批量扫描，发现3个Power Users账户的rsecssf.dat权限为BUILTIN\Users:(RX)，这意味着任何域用户都能解密SAP登录凭证。
2.3 数据库层：Oracle不是存储容器，而是权限放大器
第VII章对Oracle的审计，核心是识别“权限杠杆效应”。DBA角色本身无害，但当DBA_TAB_GRANTS中出现GRANT SELECT ON SAPSR3.BKPF TO PUBLIC时，就等于把财务凭证表裸奔暴露给所有数据库用户。关键验证点有三：
默认账户清理验证：第VII章第7条要求检查
SYS/SYSTEM/SCOTT密码。但仅改密码不够，必须执行：SELECT username, account_status, expiry_date FROM dba_users WHERE username IN ('SYS','SYSTEM','SCOTT') AND account_status != 'EXPIRED & LOCKED';若返回
OPEN状态，说明账户仍可登录——某客户因SCOTT账户未锁，被利用UTL_HTTP发起内网SSRF攻击。WITH GRANT OPTION滥用检测：第VII章第14条强调此选项风险。用以下SQL定位高危授权：
SELECT grantee, owner, table_name, privilege, grantable FROM dba_tab_privs WHERE grantable = 'YES' AND privilege IN ('SELECT','INSERT','UPDATE','DELETE');结果中若出现
SAPR3模式下的BKPF表授权给PUBLIC，即触发红色警报。审计策略有效性验证：第VII章第15条要求检查
AUDIT_TRAIL。但TRUE不等于有效，需确认：SELECT audit_option, success, failure FROM dba_stmt_audit_opts WHERE audit_option IN ('SELECT TABLE','UPDATE TABLE','DELETE TABLE');若
failure列为NOT SET，说明失败登录不记录——这正是第VII章第16条“audit trail is reviewed regularly”的前提条件。
2.4 接口层：不是数据通道，而是信任边界裂口
第VIII章“Interface Security”常被简化为“看RFC连接数”，实则需穿透协议栈。以SAP与MES系统接口为例，第VIII章第1条“Identify all system interfaces”必须拆解为三层：
传输层：检查
SM59中RFC目标的Security Options，确认勾选Use SNC（Secure Network Communication）。未启用SNC时，RFCDEST参数明文传输，Wireshark可直接捕获凭证。应用层：验证
BD87中IDoc处理程序的ALE配置。第VIII章第2条“reconciliation procedures”要求核对EDIDC（IDoc控制记录）与EDIDS（状态记录）的STATUS字段一致性。若EDIDC-STATUS=30（发送成功）但EDIDS-STATUS=51（接收失败），说明接口未实现幂等性，重复推送导致库存负数。业务逻辑层：审查
WE20中合作伙伴类型的Filter设置。某客户在CUSTOMER类型中未过滤VKORG（销售组织），导致A公司IDoc被错误路由至B公司销售组织，引发开票纠纷——这正是第VIII章第2条“Total number of customer/vendors processed”需人工复核的原因。
3. 避坑：SAP审计中五个必踩的“玄学”陷阱
3.1 现象：SE16N查T000显示10个Client，但sm51只看到3个实例
原因：Client在T000中仅是逻辑容器，实际运行需sm51中对应实例（Instance）。常见错误是审计员将Client数量等同于系统负载，忽略disp+work进程数。更隐蔽的是，某些Client被配置为No Logon（T000表中MANDT字段后缀X），虽存在但禁止登录，导致权限统计偏差。
解决：执行RZ10查看sapgui/client_info参数，再用SM66确认各Client的Dialog Work Processes实际占用数。对No LogonClient，需在SCC4中检查其Logon Group设置。
3.2 现象：su -l <sid>adm执行ls -la /usr/sap/trans/显示权限正常，但find / -name root -perm -4000报错
原因：find命令需遍历全盘，而<sid>adm用户对/proc、/sys等虚拟文件系统无读取权限，导致Permission denied刷屏掩盖真实结果。审计员误判为无suid程序，实则/usr/sap/SID/DVEBMGS00/exe/sapstartsrv（SAP启动服务）正是suid root。
解决：改用sudo find /usr/sap -name "*" -perm -4000 2>/dev/null，限定搜索范围并丢弃权限错误。关键是要理解：SAP进程以<sid>adm身份运行，但sapstartsrv需root权限管理端口，因此必须suid。
3.3 现象：Oracle中DBA_USERS显示SAPR3账户ACCOUNT_STATUS=OPEN，但sqlplus / as sysdba连不上
原因：SAPR3是应用用户，非数据库用户。第VII章第4条要求查DBA_USERS，但实际应查DBA_USERS中USERNAME为SAPR3的记录——该用户由SAP安装创建，密码由rsecssfx加密存储。审计员混淆了数据库用户与SAP应用用户概念。
解决：执行SELECT username, account_status FROM dba_users WHERE username LIKE 'SAP%'，确认SAPSR3（标准Schema）状态；SAPR3是旧版命名，ECC6.0后统一为SAPSR3。
3.4 现象：SM59中RFC目标测试成功，但BD87中IDoc始终卡在30状态
原因：RFC测试仅验证网络连通性，不校验业务逻辑。第VIII章第2条“Record counts”要求比对EDIDC与EDIDS，但EDIDS-STATUS=30表示“已发送”，需进一步查EDIDC-STATUS=51（已处理）才算完成。常见陷阱是接收方INBOUND函数模块未激活，或WE20中未配置Process Code。
解决：在BD87中双击IDoc，进入WE02查看详细状态；若Status Text为IDoc received，则需检查接收方SM58中的ALE队列是否堆积。
3.5 现象：SUIM中角色含S_TABU_DIS，但SE16N仍能查看T001W所有字段
原因：S_TABU_DIS仅控制表显示权限，字段级屏蔽需S_TABU_CLI（客户端权限）配合SE16N的Field Selection设置。审计员未意识到：GUI界面的字段隐藏是前端控制，ABAP程序仍可SELECT *读取全字段。
解决：在SE16N打开T001W后，点击Settings → Field Selection，确认WERKS等敏感字段未勾选；同时用SE38执行SELECT WERKS FROM T001W UP TO 1 ROWS验证后端是否真过滤。
4. 实战：用ABAP脚本自动化抓取28个关键业务对象清单
4.1 脚本设计逻辑：为什么不用SE16N手工导出？
第I章第19-33条要求获取28个业务对象列表（工厂、销售组织等），手工操作不仅耗时，更致命的是遗漏隐含依赖。例如T001W（工厂）需关联T001（公司代码）和T001K（公司代码-工厂关系），否则导出的工厂可能属于已停用公司。ABAP脚本必须实现三层能力：
- 动态表名解析：根据SAP版本自动适配表结构（ECC6.0用
T001W，S/4HANA用T001W+T001W_E扩展表） - 跨表关联校验：如导出销售组织
TVKO时，同步检查TVKOT（文本表）是否存在对应语言条目 - 权限实时验证：执行前调用
AUTHORITY-CHECK确认当前用户有S_TABU_DIS权限，避免脚本因权限不足中断
4.2 核心脚本：Z_AUDIT_OBJ_LIST（支持ECC6.0及S/4HANA）
REPORT z_audit_obj_list. TYPES: BEGIN OF ty_t001w, werks TYPE t001w-werks, name1 TYPE t001w-name1, land1 TYPE t001w-land1, bukrs TYPE t001w-bukrs, END OF ty_t001w. DATA: lt_t001w TYPE STANDARD TABLE OF ty_t001w, ls_t001w TYPE ty_t001w, lv_count TYPE i. * 权限校验：确保有T001W表显示权限 AUTHORITY-CHECK OBJECT 'S_TABU_DIS' ID 'DICBERCLS' FIELD ' ' ID 'ACTVT' FIELD '03' ID 'TABLE' FIELD 'T001W'. IF sy-subrc <> 0. MESSAGE '无T001W表查看权限' TYPE 'E'. EXIT. ENDIF. * 动态选择：ECC6.0用T001W，S/4HANA需加扩展字段 SELECT werks name1 land1 bukrs FROM t001w INTO TABLE @lt_t001w WHERE bukrs IN @so_bukrs. "公司代码选择屏幕 * 关联校验：检查T001W-BUKRS是否存在于T001 SELECT COUNT(*) FROM t001 INTO @lv_count WHERE bukrs IN (SELECT DISTINCT bukrs FROM @lt_t001w). IF lv_count = 0. MESSAGE '警告：T001W中公司代码在T001中不存在' TYPE 'W'. ENDIF. * 输出到ALV CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' EXPORTING i_structure_name = 'TY_T001W' TABLES t_outtab = lt_t001w.参数说明：
so_bukrs：公司代码选择屏幕，支持多值输入（如1000,2000）AUTHORITY-CHECK：强制校验S_TABU_DIS权限，避免脚本静默失败SELECT COUNT(*)：跨表校验逻辑，确保工厂归属有效公司代码REUSE_ALV_GRID_DISPLAY：输出带排序/筛选的ALV报表，支持Excel导出
4.3 批量执行方案：用SA39调度28个对象导出
单个脚本只能导出一种对象，需构建调度框架。第I章第19-33条共28个对象，按模块分组：
| 模块 | 对象表 | 脚本名 | 关键校验点 |
|---|---|---|---|
| FI | T001(公司代码) | Z_AUDIT_T001 | 检查LAND1(国家)是否匹配T005(国家表) |
| MM | T001W(工厂) | Z_AUDIT_T001W | 关联T001K(公司-工厂)验证有效性 |
| SD | TVKO(销售组织) | Z_AUDIT_TVKO | 检查TVKOT(文本表)语言条目完整性 |
| PP | T412(工作中心) | Z_AUDIT_T412 | 校验CRHD(工作中心主数据)是否存在 |
调度步骤：
- 在
SA39中创建作业Z_AUDIT_ALL，添加28个步骤，每步调用对应脚本 - 设置步骤依赖：
T001必须先于T001W执行（因工厂依赖公司代码） - 输出路径统一设为
/usr/sap/trans/audit/，文件名含时间戳（z_audit_t001w_20240520.csv） - 作业完成后，用
AL11检查/usr/sap/trans/audit/目录，确认28个CSV文件均生成且大小>0
避坑提示：
SA39作业失败时，SM37中仅显示ABAP Dump，需点开Job Log查看具体错误。常见原因是Z_AUDIT_TVKO脚本中TVKOT表在S/4HANA中已迁移至TVKOT_E，需动态判断版本。
5. 进阶：用Linux命令链精准定位SAP高危配置项
5.1 为什么GUI操作无法替代命令行审计？
第V章第4条列出的/usr/sap/trans/目录，GUI工具（如AL11）只能浏览文件列表，无法执行深度分析。而Linux命令链可实现三重穿透：
- 时间维度：
stat命令查看文件最后修改时间，识别异常更新（如cofiles/K999999在凌晨2点被修改） - 权限维度：
getfacl精确输出ACL权限，发现rwx之外的特殊权限（如setgid） - 内容维度：
grep -r递归搜索敏感字符串，定位硬编码凭证
5.2 四个必用命令链实战
场景1：快速定位所有含明文密码的配置文件
# 在/usr/sap目录下搜索password、pwd、pass等关键词（忽略大小写） find /usr/sap -type f -name "*.cfg" -o -name "*.ini" -o -name "*.xml" 2>/dev/null \ | xargs -r grep -i -l "password\|pwd\|pass" \ | xargs -r -I {} sh -c 'echo "=== {} ==="; grep -i "password\|pwd\|pass" {}'输出示例：
=== /usr/sap/SID/DVEBMGS00/j2ee/configtool/configtool.properties === password=Admin123逻辑说明：
find定位配置文件，xargs传递给grep搜索，sh -c格式化输出。关键参数2>/dev/null丢弃权限错误，避免干扰结果。
场景2：检测/usr/sap/trans/下所有suid/sgid文件
# 查找suid（4000）和sgid（2000）文件，并按修改时间排序 find /usr/sap/trans -perm -4000 -o -perm -2000 2>/dev/null \ | xargs -r ls -la --time-style=long-iso \ | sort -k7,7输出示例：
-rwsr-xr-x 1 root root 123456 2024-05-15 02:15 /usr/sap/trans/cofiles/K999999参数说明：
-perm -4000匹配suid位，--time-style=long-iso输出ISO格式时间便于排序，sort -k7,7按第7列（修改时间）排序——凌晨2点的suid文件极可能是后门。
场景3：验证/etc/inittab是否被篡改（第V章第5条）
# 计算inittab哈希并与昨日备份对比 md5sum /etc/inittab > /tmp/inittab_today.md5 diff /tmp/inittab_today.md5 /tmp/inittab_yesterday.md5 || echo "inittab has changed!"执行逻辑：第V章第5条要求“run sum command daily”，md5sum是现代替代方案。需提前建立每日备份机制，否则无法对比。
场景4：扫描/etc/exports中SAP目录的网络暴露（第V章第7条）
# 检查exports中是否导出/usr/sap相关路径 grep -E "/usr/sap|/sapmnt" /etc/exports 2>/dev/null \ | grep -v "#" \ | awk '{print $1 " -> " $2}'输出示例：
/usr/sap/SID 192.168.1.0/24(rw,sync,no_root_squash)风险解读：
no_root_squash允许NFS客户端root用户映射为服务端root，若/usr/sap/SID被导出，攻击者可直接写入/usr/sap/SID/SYS/exe/run/sapstartsrv替换启动服务。
5.3 命令链组合技：一次扫描锁定三类高危项
将上述命令封装为audit_sap_os.sh，实现一键扫描：
#!/bin/bash # audit_sap_os.sh - SAP OS层高危项扫描脚本 echo "=== SAP OS层高危项扫描报告 ===" echo "时间: $(date)" echo -e "\n【1】明文密码配置文件:" find /usr/sap -type f \( -name "*.cfg" -o -name "*.ini" -o -name "*.xml" \) 2>/dev/null \ | xargs -r grep -i -l "password\|pwd\|pass" \ | head -5 # 限制输出前5个，避免刷屏 echo -e "\n【2】suid/sgid文件（按时间排序）:" find /usr/sap/trans -perm -4000 -o -perm -2000 2>/dev/null \ | xargs -r ls -la --time-style=long-iso \ | tail -3 # 只显示最新3个 echo -e "\n【3】NFS导出风险:" grep -E "/usr/sap|/sapmnt" /etc/exports 2>/dev/null | grep -v "#" echo -e "\n【4】高危账户（UID=0非root）:" awk -F: '$3 == 0 && $1 != "root" {print $1}' /etc/passwd执行效果：
=== SAP OS层高危项扫描报告 === 时间: Mon May 20 14:30:22 CST 2024 【1】明文密码配置文件: /usr/sap/SID/DVEBMGS00/j2ee/configtool/configtool.properties 【2】suid/sgid文件（按时间排序）: -rwsr-xr-x 1 root root 123456 2024-05-15 02:15 /usr/sap/trans/cofiles/K999999 【3】NFS导出风险: /usr/sap/SID 192.168.1.0/24(rw,sync,no_root_squash) 【4】高危账户（UID=0非root）: oracle血泪经验：某次审计中，
audit_sap_os.sh第4项输出oracle账户，经查该账户是Oracle数据库安装时创建，但未删除。oracle用户UID=0，且/home/oracle/.bash_history中存有su -l <sid>adm -c 'cd /usr/sap/trans; rm -rf *'命令——这就是第V章第4条/usr/sap/trans/目录被清空的真相。从那以后我每次进客户系统，都强制先跑一遍这个脚本，再开始GUI操作。希望帮到你。
本文还有配套的精品资源，点击获取
