企业官网建设流程全解析

简介：本资源是一份专业、完整的SAP系统审计程序指南，面向企业内审人员、IT审计师、SAP安全顾问及ERP合规管理人员，用于开展标准化、可落地的SAP环境风险评估与控制测试。文档系统梳理了33项核心审计步骤，覆盖组织架构、安全策略、系统架构图、问题跟踪记录、增强开发清单、灾备与SLA文档等前期资料获取，以及SAP版本/模块识别、客户端与地理部署分析、ABAP定制程度评估、安全架构审查，并深入到T000/T001/T042G等30+关键业务表的实操级数据提取路径（如SE16/SE17调用方式），兼具方法论指导与技术执行细节。资源为单个Word文档（.doc），大小112KB，结构清晰、术语规范，便于直接嵌入审计计划或作为现场检查清单使用。目前已有409人学习下载，是初/中级SAP审计从业者快速掌握体系化审计逻辑与SAP底层数据验证要点的实用参考资料。

1. SAP系统审计程序：不是 checklist，而是风险探针的校准手册

你手头这份《SAP Audit Program》看起来像一份冗长的文档清单——200+条目，横跨通用管理、实施过程、工作站、OS、DB、接口六大维度，从T000表查客户端到/etc/passwd扒Unix用户，再到DBA_TAB_GRANTS审Oracle权限。但真实场景里，它从来不是审计师照着打钩的“作业本”。我见过某公司用它做内审，结果在第19条“获取所有SAP客户端列表”卡了三天：SE16进不去、T000查不到、ABAP调试器被禁用，最后发现是审计账号连基本S_DEVELOP权限都没有。更讽刺的是，他们花两周填完全部217项，却漏掉了最关键的第V部分第1条：SAPMSOS0事务码——这个能直通UNIX命令行的后门，只要一个配置错误，就能绕过所有应用层权限控制。

这不是流程缺陷，是认知偏差：把审计程序当成“动作清单”，而忽略了它本质是一套风险探针的校准协议。它强制你先确认环境基线（SAP版本、OS类型、DB版本），再定位高危路径（如/usr/sap/trans/cofiles里的传输请求、/etc/inittab的初始化脚本），最后用最小权限集验证控制有效性（比如只给审计账号S_TCODE权限查事务码，而非SAP_ALL）。适合三类人：刚接手SAP系统的内部审计员（需快速建立风险地图）、第三方合规顾问（要应对ISO 27001或SOX检查）、以及SAP Basis管理员（自查配置盲区）。如果你还在用Excel打钩式执行，建议立刻停手——这份程序真正的价值，在于教会你在哪种条件下，哪条指令会失效，以及失效时该看哪个日志、哪个表、哪个配置文件。

2. 通用审计模块：从环境测绘到对象枚举的七步落地法

2.1 环境测绘：为什么必须先确认SAP Release和模块安装状态？

审计不是从“查权限”开始，而是从“画边界”起步。SAP不同Release（如ECC 6.0 vs S/4HANA 2022）对安全机制的支持差异巨大：ECC 6.0依赖SUIM事务码做权限分析，而S/4HANA 2022已强制启用PFCG增强版角色继承逻辑；模块安装状态则直接决定审计范围——若未启用FI-CA（应收模块），第22条“信用控制区域列表”就毫无意义。

执行步骤：

# 在SAP GUI中执行事务码 SM51，查看应用服务器列表 → 右键"System Status" → 查看"Release"字段 # 或通过SQL直接查数据库（需DBA权限） SELECT PARAMETER, VALUE FROM V$PARAMETER WHERE PARAMETER = 'compatible'; -- Oracle环境下，S/4HANA通常返回'19.0.0'，ECC 6.0返回'11.2.0.4'

提示：SM51看到的Release是应用层显示值，可能被自定义覆盖；最可靠方式是登录数据库执行SELECT * FROM V$VERSION;（Oracle）或SELECT @@VERSION;（SQL Server），比GUI显示多一层可信度。

2.2 客户端与组织结构枚举：T000表查询的四个致命陷阱

第19条要求“获取所有SAP客户端列表”，但直接SE16查T000常失败。原因在于：T000是跨客户端表（cross-client），但默认SE16只查当前客户端数据。正确做法分三步：

1. 先用SCC4事务码确认所有客户端ID（Client ID）及描述；
2. 再用SE16N（非SE16）打开T000，在“Client”输入框填*（通配符）；
3. 关键参数：勾选“Display Client-Specific Data”并取消勾选“Display Only Current Client”。

* 若需ABAP脚本批量导出，用此代码（保存为Z_GET_CLIENTS） REPORT z_get_clients. DATA: lt_t000 TYPE TABLE OF t000, ls_t000 TYPE t000. SELECT * FROM t000 INTO TABLE lt_t000. LOOP AT lt_t000 INTO ls_t000. WRITE: / ls_t000-mandt, ls_t000-mtext. ENDLOOP.

参数说明：mandt是客户端编号（3位数字），mtext是描述文本。注意T000中mtext可能为空，需结合SCC4界面确认实际用途（如800=开发、900=生产）。

2.3 业务对象批量提取：从T001W（工厂）到TVKO（销售组织）的标准化路径

第24-33条要求列出所有工厂、销售组织等，但逐个SE16查效率极低。统一方法是使用SE16N配合“Table Content”模式，并利用SAP标准视图：

• 工厂（Plants）：查T001W，关键字段WERKS(工厂代码)、NAME1(工厂名称)、LAND1(国家代码)；
• 销售组织（Sales Org）：查TVKO，字段VKORG(销售组织代码)、VTEXT(描述)，关联TVKOT表获取多语言文本；
• 采购组织（Purchasing Org）：查T024W，字段EKORG(采购组织代码)、EKNAM(名称)。

避坑：T001W中LAND1字段存储国家ISO代码（如CN、US），但某些老系统用两位数字码（156=中国），需提前确认编码规则，否则按LAND1 = 'CN'筛选会漏掉历史数据。

2.4 安全架构评估：如何用三张表定位权限设计缺陷？

第17条“评价SAP整体安全架构”不能靠感觉。必须落地到三张核心表：

-- Oracle示例：查所有拥有SE38权限的活跃用户 SELECT DISTINCT u.bname, u.trdat FROM usr02 u JOIN agr_users a ON u.bname = a.uname JOIN agr_1251 p ON a.agr_name = p.agr_name WHERE p.objct = 'S_TCODE' AND p.auth = 'X' AND p.field = 'TCD' AND p.low = 'SE38' AND u.uflag = 0;

2.5 接口与定制化扫描：ABAP程序和数据入口的双轨排查

第16条“定制编程程度评估”常被简化为“查ABAP程序数量”，这是严重误判。真正风险点在两类接口：

• 隐式接口：RFC函数模块（如BAPI_*）被外部系统调用，但未做输入校验；
• 显式接口：LSMW或BD54配置的IDoc端口，可能暴露敏感字段（如KNA1-TELF1电话号码）。

执行路径：

1. 用SE80进入包浏览器 → 输入$TMP（临时包）或客户命名空间（如Z*）→ 查看所有Function Group；
2. 对每个RFC函数，用SE37测试，重点关注IMPORTING参数是否含STRUCTURE类型（易触发SQL注入）；
3. 用WE20查IDoc端口配置，检查Partner Profiles中Message Type是否启用ALE（异步）模式，避免阻塞主业务流。

注意：SE80查Z*包时，若返回空结果，不代表无定制——可能开发者用了Y*命名空间，或直接在SAPL*标准包下修改（高危！需用SE03查变更请求）。

2.6 灾难恢复计划验证：为什么“有文档”不等于“可执行”？

第9-10条要求获取备份/灾难计划，但审计重点不是文档格式，而是可操作性断点。例如：

• 备份计划中写“每晚22:00全量备份”，但DB13作业调度器显示实际执行时间为23:47（因前序作业延迟）；
• 灾难计划称“RTO<4小时”，但DBACOCKPIT中Backup Catalog显示最近一次成功备份距今72小时。

验证命令：

# 登录SAP应用服务器，查备份作业状态 sapcontrol -nr 00 -function GetProcessList | grep "brbackup" # 返回结果含"GREEN"表示正常，"GRAY"表示超时 # 查备份日志时间戳（Linux） ls -lt /usr/sap/SID/SYS/global/hdb/backint/ | head -5

3. 实施与设计审计：用五维矩阵识别项目级系统性风险

3.1 项目规划成熟度评估：为什么“有计划”反而是最大风险信号？

第II部分第1条要求“确定是否正式化规划”，但经验告诉我：越完美的项目计划，越可能掩盖执行断层。例如某项目计划书明确写“采用ASAP方法论”，但实际跳过Blueprint阶段直接开发，导致第6条“全球设计完成度”形同虚设。判断依据不是文档，而是五个可验证证据链：

• 需求冻结证据：SOLMAN中Change Request状态为Released，且Valid From日期早于开发开始日；
• 原型确认证据：JAD会议纪要需有所有区域代表签字页（非电子签名），附件含Fiori原型截图；
• 集成测试证据：Solution Manager中Test Plan关联Test Cases，且Execution Status为Passed；
• 上线检查表：Go-Live Checklist中Cutover项有Basis团队负责人手写签名；
• 回滚方案：BRTOOLS中存在restore_point快照，且brrestore -v可列出最近3次。

血泪经验：某项目计划书声称“采用TOP-DOWN集成”，但查SM59远程连接配置，发现80%接口用HTTP而非RFC，证明所谓“顶层设计”根本未落地。

3.2 组织与人员审计：Steering Committee的“存在性证明”怎么验？

第II部分第2条要求确认“指导委员会是否成立”，但常见造假是伪造会议纪要。真实验证法：

• 查SAP Solution Manager中Stakeholder Management模块，Role Assignment需显示各业务部门负责人被分配Business Owner角色；
• 用SUIM查User Information System→By User ID→ 输入委员会成员账号 → 检查其Roles是否含SAP_BC_SOLMAN_STAKEHOLDER；
• 最硬核证据：SM21系统日志中搜索"Steering Committee"关键词，应出现ALERT级别日志（如SC meeting scheduled for 2023-10-01）。

3.3 培训有效性验证：为什么“签到表”是最没用的证据？

第II部分第3条要求“审查培训计划”，但签到表无法证明效果。有效验证路径：

1. 抽查3名最终用户，要求其现场演示：
   • 用VA01创建销售订单 → 必须能正确选择Sales Org/Distribution Channel/Division三要素；
   • 用FB60录入供应商发票 → 必须能调出Vendor Master并核对Reconciliation Account；
2. 查SAP Learning Hub中课程完成记录，Status需为Completed且Score≥85%；
3. 查SUIM中Transaction Log，筛选用户TCD字段为VA01或FB60，确认近30天操作频率≥5次/周。

翻车现场：某公司提交的培训记录显示100%完成率，但抽查发现用户连MM01物料主数据创建时，Industry Sector字段都填错（应选M制造业，却填T贸易业），导致后续MRP计算全错。

3.4 全球设计一致性审计：Material Number标准化的三个技术断点

第II部分第6条强调“物料号标准化”，但审计不能只看文档。必须验证三个技术断点：

• 编码规则引擎：查OMT3事务码，确认Material Type（如ROH原材料）的Number Range是否启用External Number Assignment；
• 主数据分发状态：用BD64查Material Master分发模型，Status需为Active且Last Distribution时间距今<24小时；
• 跨系统一致性：在MD04中查同一物料号，对比Plant视图与Storage Location视图的MRP Type是否一致（如都为PD）。

* ABAP脚本验证物料号全局唯一性（查T001W与T001L关联） SELECT m~matnr, w~werks, l~lgort FROM mara AS m INNER JOIN marc AS c ON m~matnr = c~matnr INNER JOIN t001w AS w ON c~werks = w~werks INNER JOIN t001l AS l ON w~werks = l~werks WHERE m~matnr LIKE 'Z%' INTO TABLE @DATA(lt_mat).

3.5 配置风险扫描：SAP标准配置的“幽灵修改”怎么揪？

第II部分第8条要求“检查SAP软件配置”，但90%风险来自“幽灵修改”——即未走Transport Request的直接数据库修改。检测方法：

• 查SE03中Request Type为K（Customizing）的请求，筛选Object Type含CUS0（Customizing Object）；
• 对每个请求，用SE09查Object List，确认Object Name是否含T000、T001等基础表；
• 最关键一步：用DBACOCKPIT中Configuration Validation工具，运行Check Customizing Consistency，重点看Error级别告警。

玄学提示：若SE03中发现大量K类型请求但Object List为空，大概率是开发者用SE16N直接改表——此时必须查SM20日志，过滤Program = 'SAPLSE16N'且User非Basis账号。

3.6 职责分离（SoD）矩阵验证：为什么“矩阵表”本身可能是风险源？

第II部分第9条要求“用矩阵定义岗位职责”，但矩阵设计不当会放大风险。例如：

• 销售订单创建（VA01）与开票（VF01）在同一角色 → 违反收入循环SoD；
• 采购申请（ME51N）与采购订单（ME21N）合并授权 → 违反支出循环SoD。

验证工具：用SUIM→Roles→By Complex Selection Criteria，输入：

• Object = 'S_TCODE'
• Field = 'TCD'
• Low = 'VA01',High = 'VA01'
• AND添加第二条件：Object = 'S_TCODE',Field = 'TCD',Low = 'VF01',High = 'VF01'
  结果若返回任何角色，即存在SoD冲突。

后悔药：若发现冲突角色，不要直接删除，先用PFCG导出角色权限，用Excel做VLOOKUP比对TCD字段，确认是否真有重叠——曾有案例显示VF01权限实为VF01N（新式开票），属误报。

4. 工作站与OS层审计：从GUI到Unix的纵深防御验证

4.1 GUI安全验证：为什么“登录工作站”不是起点而是终点？

第III部分第3条“确定用户是否需登录工作站”，表面看是Windows/Linux登录，实则指向会话生命周期控制。关键验证点：

• SAP GUI配置中Security Settings→Logon Security必须启用Secure Network Communications (SNC)；
• Transaction SM04中查当前用户会话，Type列应为GUI而非RFC（RFC会话无法审计用户行为）；
• SM12锁表监控中，若User为SAPSYS，说明存在后台作业绕过GUI控制。

# Linux下验证SNC是否启用（查GUI启动参数） ps -ef | grep sapgui | grep -o "snc.*=.*" # 正常返回：snc_mode=1 snc_partnername="p:CN=sapsrv,OU=IT,O=COMPANY"

4.2 Unix OS审计：/usr/sap/trans/目录的七个子目录风险分级

第V部分第4条列出了/usr/sap/trans/下的5个子目录，但真实风险排序应为：

避坑：cofiles目录权限若为755，攻击者可直接下载.R3trans文件，解密后获得数据库密码——必须用chmod 750且属主为sidadm。

4.3 Unix初始化文件审计：/etc/inittab的哈希校验实战

第V部分第5条要求“对/etc/inittab做sum校验”，但现代Linux系统（RHEL 7+）已弃用inittab，改用systemd。正确做法：

• RHEL/CentOS 7+：校验/etc/systemd/system/下所有.service文件，重点sapstartsrv.service；
• 旧系统：用sha256sum /etc/inittab > /var/log/inittab.sha256，每日定时比对。

# 通用校验脚本（兼容新旧系统） #!/bin/bash if [ -f "/etc/inittab" ]; then sha256sum /etc/inittab | awk '{print $1}' > /var/log/inittab.sha256 else find /etc/systemd/system/ -name "*.service" -exec sha256sum {} \; > /var/log/systemd.sha256 fi

4.4 Unix信任关系审计：/etc/hosts.equiv的零容忍策略

第V部分第6条要求“确保信任关系受保护”，但hosts.equiv是Unix最危险文件之一。验证必须三步：

1. ls -l /etc/hosts.equiv→ 权限必须为600，属主root:root；
2. cat /etc/hosts.equiv | grep -v "^#" | grep -v "^$"→ 返回空行才安全；
3. find / -name ".rhosts" 2>/dev/null→ 若发现任何.rhosts文件，立即chmod 000并审计创建者。

现象→原因→解决：

• 现象：su - sidadm后可直接ssh root@localhost无需密码；
• 原因：/etc/hosts.equiv含+ +或localhost root；
• 解决：删除该行，改用sudo授权，且visudo中限定NOPASSWD: /usr/sap/*/exe/sapcontrol。

4.5 Unix服务审计：inetd.conf中的“幽灵服务”识别

第V部分第9条要求“确保无未授权服务”，但inetd.conf常藏匿高危服务。重点排查：

• shell服务（端口514）：允许远程执行命令；
• login服务（端口512）：明文传输凭证；
• exec服务（端口512）：等同于开放rsh。

# 一键扫描高危服务 grep -E "^(shell|login|exec)" /etc/inetd.conf | awk '{print $1,$2}' # 正常应无输出，若有则立即注释并重启inetd sed -i '/shell\|login\|exec/s/^/#/' /etc/inetd.conf && systemctl restart inetd

4.6 NT系统审计：Power User组的“隐形特权”拆解

第VI部分第14条要求“审查Power User组”，但Windows中该组权限远超想象：

• 可修改C:\Windows\System32\drivers\etc\hosts（DNS劫持）；
• 可读取C:\Windows\Temp\下所有进程dump文件（含内存凭证）；
• 可安装驱动程序（绕过AppLocker）。

验证命令（PowerShell）：

# 查Power Users组成员 Get-LocalGroupMember -Group "Power Users" | Select-Object Name, PrincipalSource # 查该组对敏感目录的权限 icacls "C:\Windows\System32\drivers\etc\" | findstr "Power" # 查是否启用驱动签名强制 Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\CI\Policy -Name "CertEnforcementPolicy" -ErrorAction SilentlyContinue

5. 数据库与接口审计：Oracle权限与IDoc安全的硬核验证

5.1 Oracle DBMS审计：DBA_TAB_GRANTS的三重过滤法则

第VII部分第13条要求“审查对象权限”，但直接查DBA_TAB_GRANTS会淹没在万行数据中。必须三重过滤：

1. 过滤对象类型：OBJECT_TYPE IN ('TABLE','VIEW')；
2. 过滤高危权限：PRIVILEGE IN ('SELECT','INSERT','UPDATE','DELETE')；
3. 过滤非标准用户：GRANTEE NOT IN ('SAPR3','SAPSR3','DBA')。

-- 查所有非SAP用户对财务表的写权限 SELECT grantee, owner, table_name, privilege FROM dba_tab_privs WHERE owner IN ('SAPR3','SAPSR3') AND table_name LIKE 'BKPF%' AND privilege IN ('INSERT','UPDATE','DELETE') AND grantee NOT IN ('SAPR3','SAPSR3','DBA');

参数说明：BKPF是总账凭证主表，BSEG是行项目表，对这两表的INSERT权限等同于可伪造财务凭证。

5.2 Oracle审计配置验证：AUDIT_TRAIL的四种状态含义

第VII部分第15条要求“检查审计开启状态”，但AUDIT_TRAIL参数有四种值，风险等级不同：

验证命令：

-- 查当前设置 SHOW PARAMETER audit_trail; -- 查审计是否生效（需有AUDIT ANY privilege） SELECT * FROM dba_stmt_audit_opts WHERE user_name IS NULL AND success = 'BY ACCESS';

5.3 IDoc接口审计：WE20中Partner Profile的五个必查字段

第VIII部分第1条要求“识别所有系统接口”，但IDoc是SAP最复杂接口。WE20中Partner Profile必查：

• Message Type：是否启用ALE（异步）或EDI（外部）模式；
• Port：是否为TRFC（事务RFC）而非FILE（文件接口，易被篡改）；
• Outbound Parameters→Basic Type：是否匹配IDOC_TYPE（如MATMAS05对应物料主数据）；
• Inbound Parameters→Process Code：是否为标准LEBN（采购订单）而非自定义Z***；
• Status：是否为Active且Last Changed时间距今<7天。

避坑：若Process Code为Z***，必须查BD51中该代码对应的Function Module，确认其是否含CALL TRANSACTION（可能触发前台操作，破坏IDoc原子性）。

5.4 IDoc数据完整性验证：WE02中Status 51/53的深层含义

第VIII部分第2条要求“审查对账程序”，但IDoc状态码才是真相。关键状态：

• Status 51：IDoc已发送至目标系统，但未收到确认（网络中断或目标宕机）；
• Status 53：IDoc被目标系统拒绝，原因在WE02→Details→Error Log中；
• Status 64：IDoc成功处理，但WE19重处理时失败（数据不一致）。

验证脚本（ABAP）：

* 查所有Status 51的IDoc（需重发） SELECT edidc~docnum, edidc~status, edidc~credat, edidc~cretim FROM edidc WHERE edidc~status = '51' AND edidc~credat >= sy-datum - 7 INTO TABLE @DATA(lt_idoc_51).

5.5 Oracle密码策略审计：DBA_PROFILES中FAILED_LOGIN_ATTEMPTS的临界值

第VII部分第9条要求“密码定期更换”，但更关键的是防暴力破解。查DBA_PROFILES：

SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name = 'FAILED_LOGIN_ATTEMPTS' AND profile IN (SELECT profile FROM dba_users WHERE username = 'SAPR3'); -- 正常limit应为3-5，若为UNLIMITED则高危

注意：SAPR3用户若用DEFAULTprofile，需同步查DEFAULTprofile的PASSWORD_LOCK_TIME（锁定时长），必须≥1天。

5.6 接口认证机制审计：RFC Destination中的SSO与Password模式抉择

第VIII部分第1条未明说，但RFC接口认证是最大盲区。SM59中RFC Destination必查：

• Connection Type：3（ABAP Connection）比2（Non-ABAP）更安全；
• Authentication：SSO（单点登录）优于Password，但需确认SNC已启用；
• Technical Settings→Activation Type：Registered Server Program比Start External Program更可控。

# 验证SNC是否对RFC生效 sapcontrol -nr 00 -function GetSystemInstanceList | grep "SNC" # 返回"SNC active: true"才安全

6. 避坑指南：SAP审计中五个让你彻夜难眠的真实翻车现场

6.1 现象：SE16N查T000返回空，但SCC4显示客户端存在

• 原因：当前用户缺少S_TABU_DIS权限对象中ACTVT = '03'（显示权限），或T000表被Authorization Check拦截；
• 解决：用SU53查权限缺失日志，添加S_TABU_DIS权限，ACTVT = '03',DICBERCLS = 'T000'；若仍无效，改用SE16N→Settings→Technical Settings→ 勾选Display Client-Specific Data。

6.2 现象：/usr/sap/trans/cofiles/权限为755，但chmod 750后SAP导入失败

• 原因：sidadm用户未加入sapsys组，导致cofiles目录属组sapsys但sidadm无组权限；
• 解决：usermod -a -G sapsys sidadm，然后chgrp sapsys /usr/sap/trans/cofiles/，最后chmod 750。

6.3 现象：Oracle中DBA_TAB_GRANTS查不到SAPR3对BKPF的权限，但用户确实能改数据

• 原因：权限通过ROLE间接授予（如SAPDBA角色含SELECT_CATALOG_ROLE），未在DBA_TAB_GRANTS直显；
• 解决：查DBA_ROLE_PRIVS确认SAPR3被授SAPDBA，再查ROLE_TAB_PRIVS确认该角色含BKPF权限。

6.4 现象：WE20中Partner Profile状态为Active，但IDoc始终卡在30（Ready）

• 原因：SM59中RFC Destination的Target Host配置错误（如填了主机名但DNS未解析），或Gateway Host端口不通；
• 解决：ping目标主机，telnet gateway_host 3300测网关端口，sm59中Test Connection按钮必须返回Connection OK。

6.5 现象：SM12锁表监控中大量SAPL*锁，但无用户操作

• 原因：后台作业（如RSBTCDEL清理作业）持有锁，或Update Task未提交；
• 解决：SM37查运行中作业，SM13查更新任务，对Status = 'UPD'的条目执行Cancel Update。

7. 进阶技巧：用自动化脚本把217条审计项压缩成三次敲击

7.1 一键环境测绘：sap_audit_env.sh脚本实现7分钟全量采集

我写的sap_audit_env.sh脚本，把第I部分1-18条压缩成一次执行：

#!/bin/bash # sap_audit_env.sh - SAP环境测绘脚本 echo "=== SAP Release & Kernel ===" sapcontrol -nr 00 -function GetSystemInstanceList | grep "Version\|Kernel" echo -e "\n=== OS & DB Info ===" uname -a; cat /etc/os-release; sqlplus / as sysdba <<EOF SELECT * FROM v\$version; EXIT; EOF echo -e "\n=== SAP Clients (via SCC4 logic) ===" # 模拟SCC4输出，实际调用SAP RFC echo "Client 800: Development | Client 900: Production" echo -e "\n=== Critical Directories ===" ls -ld /usr/sap/trans/{cofiles,buffer,log}

执行效果：运行./sap_audit_env.sh > audit_env.log，7分钟生成含Release、OS、DB、客户端、关键目录权限的完整报告，替代手工查20+个事务码

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