★ FEATURED ARTICLE 简介这份SAP系统审计程序资料面向企业内部审计人员、IT合规与风控从业者以及需要了解SAP审计流程的顾问与学习者帮助解决审计准备阶段缺乏系统化清单、难以全面覆盖检查项的问题。资源以英文审计程序清单为主体从组织架构、安全政策、应用架构、问题跟踪、系统增强、开发方法论、服务级别协议、应急与灾难恢复计划等维度展开并延伸到SAP版本确认、模块识别、生产系统接口、客户端数量、地理分布、定制编程程度评估以及整体安全架构、操作系统与数据库环境判断还列出客户端、公司代码、业务区域、信用控制区、科目表、工厂、存储地点、采购组织、销售组织等关键业务对象对应的数据表查询路径便于按图索骥逐项核对。压缩包内共1个doc文件约112KB结构紧凑适合作为审计底稿模板或自查清单使用。目前已有410人学习可作为SAP审计入门与实务对照的参考材料。1. 从一份 SAP 审计清单说起它到底能解决什么问题很多做 SAP 运维或内控的朋友第一次拿到一份完整的 SAP 审计程序清单时反应往往是“这不就是把系统里能查的东西全列了一遍吗”。但真正在项目上跑过一轮的人会知道这份清单的价值不在于“列得全”而在于它把审计动作拆成了可执行、可复现、可留痕的步骤。它解决的核心问题是当你面对一套已经上线运行、模块众多、客户端和操作系统交织在一起的 SAP 系统时如何用一套标准化的程序把安全、合规、变更控制、接口和底层系统这几个维度的风险点逐一确认下来。这份 SAP 审计程序覆盖了从总体信息收集、设计与实施评估、工作站安全、应用支持到 Unix、NT、Oracle 数据库以及接口安全八个部分。它适合三类人一是企业内部审计或内控人员需要按清单逐项取证二是 SAP BASIS 或安全顾问需要对照检查自己的系统配置是否经得起审计三是刚接触 SAP 审计的从业者想找一份能照着走的作业指导。下面我不按原文顺序复述而是把它拆成能落地的几个技术块讲清楚每一步在系统里对应什么操作、参数怎么设、哪里容易翻车。2. 总体信息收集用 SE16 把系统底账翻出来2.1 为什么先查表而不是先访谈审计程序的第一部分列了三十多条其中一大半是“Obtain a listing of…”。很多人习惯先找业务访谈但我的经验是先把系统里的配置表拉出来再拿着数据去问效率完全不一样。SAP 的组织架构、公司代码、工厂、采购组织、销售组织这些信息全部落在标准表里用 SE16 或 SE17 就能直接读。这样做的好处是你拿到的是系统当前的真实配置而不是某个人记忆中的版本。访谈可以确认“为什么这么设”但“设成了什么”必须从表里来。原文里提到的表包括 T000客户端、T001公司代码、T042G集团、TGSB/TGSBT业务领域、T014/T014T信用控制范围、T004/T004T会计科目表、T001W/TVKWZ工厂、T001L存储地点、T024W采购组织、T024采购组、TVKO/TVKOT销售组织、TVTW/TVTWT/TVKOV分销渠道、TSPA/TSPAT/TVKOS产品组、TVTA销售区域、TVBUR/TVKBT/TVKBZ销售办事处、TVKGR/TVBVK/TVGRT销售组。这些表名不需要背但要知道它们分别对应哪类组织单元查的时候才不会漏。2.2 用 SE16 批量导出组织架构的实操步骤下面这段不是代码而是我在项目上常用的操作路径。SAP GUI 里没有脚本化的批量导出但可以按下面的顺序走第一步登录被审计的客户端事务码 SE16输入表名 T000执行。这个表里每一行是一个客户端重点看客户端编号、描述、城市、货币、客户端角色生产、测试、培训。审计时要确认生产客户端是否只有一套测试和培训客户端是否与生产隔离。第二步查 T001看公司代码清单。重点字段是 BUKRS公司代码、BUTXT名称、ORT01城市、WAERS货币。这里要核对的是公司代码数量与组织架构图是否一致有没有已经停用但没标记删除的公司代码。第三步查 T001W看工厂。字段 WERKS工厂、NAME1名称、ORT01城市。工厂通常和后勤模块强相关审计时要确认工厂的分配是否与业务实际相符。第四步查 TVKO看销售组织。字段 VKORG销售组织、VTEXT描述。销售组织往往和公司代码、工厂有交叉这里容易出现“一个销售组织对应多个公司代码”的情况需要结合业务确认是否合理。提示SE16 默认一次最多显示一定数量的行如果表数据量大先用“条目数”限制或者用 SE16N 的导出功能。导出时选“本地文件”格式选电子表格方便后续做核对。2.3 参数怎么改、结果怎么看SE16 的初始界面有几个关键参数最大命中数Max Hits和条目数No. of Entries。如果只是看结构把最大命中数设成 100 就够如果要全量导出把条目数设成 0 表示不限制但要注意系统性能。另外“用户设置”里可以固定一些显示变式比如只显示关键字段避免每次拉出来一堆技术字段看不懂。查出来的数据怎么用我一般会做三件事一是和上一年的审计底稿对比看组织单元有没有增减二是和 HR 提供的组织架构图对比看系统配置和实际管理架构是否脱节三是把关键字段公司代码、工厂、销售组织整理成一张对照表作为后续模块审计的基础。这一步做扎实了后面查权限和接口的时候会省很多事。3. 设计与实施审计从项目文档到配置检查3.1 设计阶段要看的四类文档审计程序的第二部分讲的是设计与实施核心是判断“系统是不是按规矩建起来的”。这里要拿到的文档包括项目计划、组织与人员安排、培训记录、项目控制工具预算、质量、进度。原文里提到几个关键点有没有指导委员会、有没有跨职能的集成团队、每个核心模块配 5 到 7 个人、有没有用问题日志跟踪延迟、有没有在项目初期就建立邮件或协作系统。从审计角度这些文档不是拿来存档的而是用来回答一个问题系统上线前的设计决策有没有留下可追溯的记录。比如“全球设计”这一条要求确认物料号、客户号、会计科目表、公司代码这些关键数据项是否标准化。如果当时没有标准化上线后就会出现同一类数据多个编码的情况查起来非常麻烦。3.2 配置检查组织层级和表结构一致性原文第 8 条提到“SAP 软件是否正确配置”具体包括组织层级是否在初期就建立、有没有对 SAP 标准软件做修改、有没有定期交叉检查表配置、有没有检查各地点表结构一致性。这一条在实操中对应的是 SPRO 里的企业结构配置以及 SE16 查表后的比对。我一般会这样做先用 SPRO 进入“企业结构”下的各个定义节点截图或导出当前配置然后用 SE16 查对应的配置表比如 T001公司代码、T001W工厂、TVKO销售组织把表里的数据和 SPRO 里的配置做交叉核对。如果发现表里有数据但 SPRO 里看不到或者两边不一致就要查是不是有人直接改表绕过了配置路径。注意直接改表在 SAP 里是高风险操作审计时要特别关注有没有这种痕迹。常见做法是查表日志SCU3或者用 CDHDR/CDPOS 查变更历史。3.3 职责分离矩阵怎么落地原文第 9 条提到“用矩阵定义岗位职能和职责分离”。这一条在 SAP 里对应的是权限角色设计。审计时不能只看角色名称要看角色里包含的事务码和授权对象。具体操作是用 SUIM用户信息系统按事务码查角色或者按授权对象查用户。重点看有没有同一个用户既能创建供应商又能付款、既能修改销售订单又能过账发票这类组合。我通常会拉三张表AGR_USERS角色到用户、AGR_TCODES角色到事务码、AGR_1251角色到授权对象。把这三张表关联起来就能看出一个用户实际能执行哪些操作。如果发现关键职责集中在少数人身上就要在审计底稿里标记为高风险。4. 底层系统审计Unix、NT 和 Oracle 的检查点4.1 Unix 层从 SAPMSOS0 到 suid 检查审计程序的第五部分讲 Unix 操作系统安全第一条就是“确定谁有权执行程序 SAPMSOS0”。这个程序可以通过事务码 SM52 运行它能访问 Unix 命令提示符。换句话说能跑这个程序的人理论上可以在操作系统层面执行命令。审计时要查 SM52 的权限给了谁以及这些用户是否真的需要。接下来是几条命令行的检查原文列得很清楚# 查看可以直接登录 Unix 的用户 cat /etc/passwd # 查看用户组和成员 cat /etc/group # 查看 SAP 目录权限 ls -la /usr/sap ls -la /usr/sap/trans/buffer ls -la /usr/sap/trans/cofiles ls -la /usr/sap/trans/log # 查看初始化文件 cat /etc/inittab # 查看信任关系 cat /etc/hosts.equiv cat ~/.rhost # 查看导出文件系统 cat /etc/exports # 查看批处理任务 cat /usr/spool/cron/crontabs/root # 查看服务列表 cat /etc/services cat /etc/inetd.conf # 查找 root 拥有的 suid 和 sgid 程序 find / -user root -perm -4000 -print find / -user root -perm -2000 -print find / -user root -perm -4000 | sum today这些命令的逻辑说明/etc/passwd和/etc/group用来确认有哪些账号和组重点看有没有多余的账号、有没有 uid 为 0 的非 root 账号。/usr/sap/trans下的目录是传输系统的核心buffer 里是待导入的传输请求cofiles 是传输请求的控制文件log 是日志。如果这些目录对普通用户可写传输系统就可能被篡改。/etc/inittab是初始化文件审计要求每天做一次 sum 校验用来发现变更。find命令找的是 suid 和 sgid 程序这些程序在执行时会临时获得 root 权限是提权攻击的常见目标。把结果 sum 后每天对比就能发现新增的可疑程序。参数说明-perm -4000表示 suid 位-perm -2000表示 sgid 位-user root限定属主是 root。sum命令生成校验和diff用来对比两天的结果。如果发现新增的 suid 程序要立刻查来源。4.2 NT 层用户、组和权限的核对第六部分讲 NT 操作系统安全列了 25 条。核心是几件事管理员列表是否精简、用户和组是否有效、默认账号规则和密码规则是否达标、域和工作组的使用是否合理、启动应用是否授权、目录和文件权限是否最小化、Power User 和 Guest 组是否受控、日志脚本是否安全、屏幕保护是否启用、审计事件是否足够、备份是否到位、职责分离是否落实。在实操中这些检查大部分可以通过系统的用户管理工具完成。我一般会先导出管理员列表逐个确认是否真的需要管理员权限然后导出所有用户和组核对有没有已经离职但账号还在的情况接着检查密码策略看最小长度、复杂度、过期时间是否符合内部标准最后看关键目录的权限特别是 SAP 相关的目录和文件确认只有必要的账号有写权限。提示NT 审计里最容易忽略的是“默认账号”。很多系统装完后默认的管理员账号没改名也没禁用这是审计里的常见发现。4.3 Oracle 层INIT.ORA 和审计开关第七部分讲 Oracle 数据库安全第一条是职责分离第二条到第四条是拿数据字典视图。原文提到的视图包括 DBA_OBJECTS、DBA_TAB_COLUMNS、DBA_USERS、DBA_VIEWS。这些视图用来确认数据库里有哪些对象、哪些用户、哪些权限。关键检查点包括默认用户 SYS、SYSTEM、SCOTT、SAPR3 的密码有没有改用户是否需要密码认证密码是否定期更换有哪些角色哪些用户有 Resource 或 DBA 权限对象权限是否只给了授权用户WITH GRANT OPTION 是否被滥用审计有没有打开。审计开关在 INIT.ORA 文件里参数是 AUDIT_TRAIL。如果设成 TRUE表示开启了数据库审计。审计记录可以通过 DBA_SYS_AUDIT_OPTS 和 DBA_TAB_AUDIT_OPTS 查看。审计时要确认AUDIT_TRAIL 是否开启审计记录是否定期查看有没有人负责跟进审计发现。-- 查看数据库用户 SELECT username, account_status, default_tablespace FROM dba_users; -- 查看有 DBA 权限的用户 SELECT * FROM dba_role_privs WHERE granted_role DBA; -- 查看对象权限 SELECT grantee, owner, table_name, privilege FROM dba_tab_privs WHERE grantee NOT IN (SYS,SYSTEM); -- 查看审计选项 SELECT * FROM dba_sys_audit_opts; SELECT * FROM dba_tab_audit_opts;这几条 SQL 的逻辑第一条看有哪些用户、账号状态是否正常第二条看谁有 DBA 权限这个权限过大必须严格控制第三条看对象权限给了谁重点找非系统用户第四条看审计选项确认关键操作有没有被记录。5. 避坑与常见问题审计路上容易翻车的五个点5.1 只查表不查变更日志漏掉历史修改现象审计时查了 T001、T001W 等表数据看起来正常但后来发现有人曾经改过公司代码的货币后来又改回来了。原因SE16 只能看当前值看不到历史变更。解决用 SCU3 查表变更日志或者直接查 CDHDR 和 CDPOS 表按对象类和对象名过滤。常见做法是对关键配置表先查变更日志再查当前值。5.2 权限检查只看角色名不看实际授权现象角色名叫“显示用户”但里面包含了修改权限的事务码。原因角色名是人为起的不能反映实际权限。解决用 SUIM 按事务码反查角色或者直接查 AGR_TCODES 和 AGR_1251。我一般会拉出所有角色的事务码清单逐个核对而不是只看角色描述。5.3 Unix 检查忽略 suid 程序的每日对比现象审计时做了一次 find没发现问题但过了一个月发现多了个 suid 程序。原因没有做每日对比中间的变化没被发现。解决把 find 的结果 sum 后存成文件每天跑一次 diff。这个习惯看起来麻烦但真出问题的时候这是唯一的后悔药。5.4 Oracle 审计开了但没人看现象INIT.ORA 里 AUDIT_TRAIL 设了 TRUE但审计记录从来没被查看过。原因开了审计不等于有人跟进审计记录会一直堆积最后占满空间。解决确认审计记录有定期清理和查看的流程最好指定专人负责。审计时要问最近一次查看审计记录是什么时候发现了什么。5.5 接口对账只做总量不做明细现象接口审计时只核对了总笔数和总金额没核对明细。原因总量对上了但明细可能有错配。解决原文第八部分提到对账程序包括记录数、客户/供应商总数、贷方总额、借方总额、总金额、总量。我一般会再加一步抽一批明细逐条核对源系统和目标系统。常见做法是按日期或凭证号抽样确认每一条都正确。6. 接口安全与进阶技巧把审计做成可复用的检查包接口审计是这份程序里最容易被低估的部分。原文第八部分要求识别所有系统接口审查对账程序确认提交方式和认证方式。在实际项目里SAP 的接口可能包括 IDoc、RFC、BAPI、文件传输、中间件等。审计时不能只看接口清单还要看每个接口的认证方式、传输内容、错误处理和对账机制。我一般会做一个接口检查包包含四张表接口清单接口名称、类型、方向、频率、负责人、认证方式是否用专用账号、密码是否定期更换、是否加密、对账记录对账频率、对账人、最近一次对账结果、异常处理错误日志、重试机制、通知人。这个检查包可以复用到不同的系统审计里每次只需要更新数据。进阶技巧方面我推荐用 SUIM 做权限分析的批量导出。SUIM 里有很多预定义报表比如“按事务码查用户”“按授权对象查用户”“按角色查用户”。把这些报表导出后用电子表格做透视能快速发现权限集中和职责冲突。另一个技巧是把 SE16 的常用查询存成变式下次直接调用不用每次重新输入表名和条件。验证方法上我习惯在审计结束后做一次“反向验证”随机抽几条审计发现回到系统里重新确认一遍。比如审计发现某个用户有 DBA 权限就再查一次 DBA_ROLE_PRIVS确认这个用户确实还在。这样做的好处是避免因为数据导出时间差导致误判。从那以后我每次做 SAP 审计都强制走一遍“查表、查日志、查权限、查接口”这四步不管项目大小一步都不省。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
