尧图网页设计 
简介针对SAP系统审计场景的检查清单型资料面向企业内审、IT审计师、SAP Basis及合规管理人员帮助快速建立系统审计工作框架。资源共1个doc文件压缩包大小112KB内容以英文审计步骤清单为主并辅以中文要点说明。文档从总体概况切入要求先获取组织架构图、安全策略、应用架构图、问题跟踪记录、待实施系统增强、开发方法论、SLA、应急与灾难恢复计划等并逐步确认SAP版本、模块、生产系统接口、客户端数量与地理分布同时给出通过表T000、T001、TGSB、T024W等查询SAP客户端、公司、业务范围、信用控制区、工厂、采购组织、销售组织等关键主数据的具体路径。后续设计实施部分还覆盖项目规划、团队组织、岗位配置等评估要点。整体可作为SAP内外审的工作底稿或现场核查清单便于逐项对照执行提升安全合规与风险防控审计的完整性和效率。已有408人学习下载。1. 一份真正的SAP审计程序长什么样从系统摸底到接口对账的完整链路接手新客户的SAP系统审计手头最尴尬的往往不是专业知识不够而是只有一份通用IT审计底稿——问组织架构、问安全策略、问变更流程真到系统上却不知道应该敲哪个事务码。这份SAP系统审计程序清单把审计动作落到了具体对象上版本与模块识别、客户端清单、几十张后台表、Unix/NT/Oracle三个平台的检查命令、数据库默认账号与审计开关、接口对账项几乎每一项都能对应到一个事务码、一张表或一个配置文件。它解决的是审计过程中“不知道查什么、不知道在哪儿查”的问题适合做Basis运维、安全合规的人也适合FI/CO或MM顾问在项目上线前拿来做一轮自检。与其说它是审计报告模板不如说是一份SAP系统体检的检查点清单照着一步步走审计范围基本漏不了。2. 摸底阶段先盘家底版本、模块、客户端与主数据表清单怎么拉2.1 版本、模块与客户端摸清系统边界的四个入口SAP审计的第一步不是进系统到处翻而是先把审计范围“砸实”。原文I部分开列的公司组织架构图、安全策略、应用架构图、问题跟踪与事件报告、待实施系统增强清单、应用文档、开发方法论、SLA、应急与灾难恢复计划这些材料大多不在SAP系统里而在IT管理部门和应用支持小组手里。我的习惯是先建一个资料收集清单发给客户约一次系统盘点会议边聊边把下面这些技术点补齐效率比闷头翻系统高得多。版本与模块识别是第一个入口。登录GUI后用“系统→状态”看SAP版本信息或者用事务码SM51看应用服务器清单。老一点的ECC 6.0系统要核对EHP Enhancement Package和SP级别这决定了后面安全补丁审计的检查范围如果是S/4 HANA系统重点就完全不同。模块识别看安装清单常用做法是调用SE38看已存在的程序库或者直接看开发类和传输请求里频繁出现的事务码集中在哪个模块——FI/CO、MM、SD的权限对象和主数据表是完全不同的两套体系。客户端和安全边界是第三个入口。SCC4可以查看客户端角色生产、测试、定制T000表里也有客户端清单。生产系统里客户端数量过多本身就是风险信号尤其是测试客户端与生产客户端混在一个实例上的情况。地理位置分布决定数据流走向跨地域调用RFC时要检查运输层的加密和每个站点的参数文件。最后是接口清单。原文要求“determine the interfaces to the production system”这一步在实操里最容易漏。我一般用SM59拉RFC目标清单再看WE02/WE05里的IDoc记录确认生产系统与外围系统之间的接口都由谁触发、走什么协议。接口少了后面第八部分的对账审计根本无从谈起。2.2 从T000到TVKGR大体量主数据表一次拉全原文在General部分贴出了一张主数据表清单覆盖组织架构、财务、采购、销售的主数据入口。这张清单在审计现场非常有用我把它按模块整理成下面的对照表审计对象入口表对应模块SAP客户端T000系统基础公司代码T001FI集团内公司T042GFI业务范围TGSB / TGSBTFI信用控制范围T014 / T014TFI/CO科目表T004 / T004TFI工厂T001W / TVKWZMM存储地点T001LMM采购组织T024WMM采购组T024MM销售组织TVKO / TVKOTSD分销渠道TVTW / TVTWT / TVKOVSD部门DivisionTSPA / TSPAT / TVKOSSD销售范围TVTASD销售办事处TVBUR / TVKBT / TVKBZSD销售组TVKGR / TVBVK / TVGRTSD读取入口是原文给的路径SYSTEM → SERVICES → TABLE MAINTENANCE对应SM30TOOLS → ABAP/4 WORKBENCH → OVERVIEW → DATA BROWSER → TABLE CONTENTS对应SE16或SE17。审计场景下用SE16看表内容就够了SE16N也可以。这些表大多体量不大执行后能看到客户端、公司代码、销售组织、工厂这些组织元素的清单审计底稿里的“客户环境描述”部分就能直接填满。注意一点T042G在原文里对应“集团内公司”清单但实务里它和特别总账的容差组配置也有关系。我复核时会顺手看表内容是否和公司代码清单一致如果两个清单对不上说明后台配置里存在残余数据这种不一致本身就是一个发现项。2.3 定制化评估ABAP/4程序、数据录入画面与接口清单摸底阶段的最后一项是评估定制化程度。原文问的是“what level of custom programming is ongoing”包括ABAP/4程序和自定义数据录入画面。审计逻辑很简单定制越多运维成本和安全风险越高你越要关心开发变更是否走完了正式的传输流程。我一般用SE93查事务码到程序的映射用SE80看开发类和对象树SE38直接查看ABAP代码。重点判断是标准程序还是Z开头或Y开头的自定义程序数量有多少最近三个月有没有活跃开发。定制程序过多有时候意味着标准功能没有被用起来而自定义画面通常会绕过标准字段检查这是审计报告里值得写一笔的观察项。接口清单要单独立一个台账。生产系统和外围系统之间的接口文件、中间表、RFC调用都算顺序是这样的先把SM59里的RFC目标全部拉出来再看SM37里的后台作业有哪些是周期性往外部系统传数据的最后核对批处理日志。原文第八部分的对账项record counts、借贷总额、处理客户/供应商数能不能做完全取决于这个接口台账是否完整。3. 从项目治理到职责分离SAP ECC实施阶段的配置审计与PFCG权限矩阵3.1 项目规划与组织指导委员会、技术团队与核心模块5-7人原文第二部分叫Design And Implementation内容全是实施阶段的项目治理问题。规划层面问的是有没有明确的功能或地理实施路线有没有采用结构化方法论有没有自上而下的顶层计划来处理系统集成问题计划里有没有考虑SAP版本发布时间和实施完成后的复盘窗口这些问题没有技术性那么强但恰恰是很多项目后期翻车的根源。组织与人员配置的检查点很具体。指导委员会要覆盖所有业务领域企业级标准要提前建立用户要担任关键项目管理岗位而不是只当“业务代表”集成团队要从各功能领域抽人技术团队要独立于功能团队。原文给了一条硬数字每个核心模块5-7人。这个数字在SAP项目里基本是标配少于这个规模后面日常配置、功能测试、知识转移根本忙不过来。我通常会把客户项目组的组织架构图拿来和这条清单对照重点看两件事技术团队向谁汇报、集成团队有没有实权。很多项目里集成团队只是挂个名所有集成决策全靠实施商主导这种治理结构下接口测试做得再好上线后也容易出职责真空。3.2 培训、变更管理与重组流程先达成共识再上线培训这块的检查点看似虚实际上是项目质量最直接的信号。原文要求确认培训方案覆盖所有功能领域、培训方式纳入项目方法论、各级培训时间是否排够。实操里我会去看培训签到表、培训材料版本和考核结果而不只是看培训计划PPT。变更与项目控制方面原文要求看四样东西跨团队的标准沟通工具与文档格式、每周甚至每日的跨团队进度会与月度指导委员会会议、问题日志、以工作包任务和交付物衡量的项目度量方式。原文还提到支持系统要在项目最开始就建立当时写的是Lotus Notes或email现在对应到Teams、Confluence这类协作平台——检查点不变变的只是工具名。重组流程re-engineering的检查点容易被忽略大规模业务重组要在SAP实施前完成否则变更需求应该合并到分析设计阶段处理而且所有重组过程必须正式签字确认。这条的现场表现通常是业务方一边上线SAP一边改组织架构MRP范围和成本中心架构反复变最后配置被改得面目全非。审计时一旦发现重组流程没有正式sign-off就要标记为中等以上风险。3.3 全局设计与集成测试JAD工作坊、关键检查点与跨团队配置核对Global Design不是指画一张架构图而是问几个具体问题全球流程是否与SAP功能对齐、各区域代表是否参与了原型验证和JADJoin Application Develop工作坊、系统关键检查点是否映射到全球设计、关键主数据字段物料号、客户号、科目表、公司代码是否全球统一。这三条放在一起看本质上是在查一个东西是否有人拿业务集成视角审过系统设计。很多项目做集成测试只测技术接口通不通不测端到端业务流程——比如SD发货以后FI凭证能不能按设计生成、MM收货以后CO分配能不能进入正确的成本对象。SAP里的Workflow通常就是在这种集成场景里暴露问题审批流断在某个环节、IDoc状态长时间停在错误码都是审计现场最常撞见的现象。配置审计要落到交叉检查上。原文要求确认是否有周期性的表配置交叉检查、表格和文件结构是否跨地点一致。对应到ECC时代就是拿传输请求清单做分析重点审非标准修改Modifications一个非标准修改至少要能回答三个问题为什么改、谁批的、测试覆盖了什么。配置漂移一旦发生最麻烦的还不是功能异常而是没人说得清楚它什么时候变的。3.4 配置审计与职责分离矩阵从权限对象到PFCG角色职责分离是审计报告中风险等级最高的部分。原文说得很直白“matrixes are used to define job functions and proper separation of duties”。落地到SAP里就是角色和权限对象的组合矩阵。FICO里面常见的危险组合是记账与冲销在同一个角色里物流侧是主数据维护和货物移动混合授权开发侧是SE38/SE37和SCC4配置权限握在一个人手里。ECC时代的落地路径是PFCG建角色、SU01分配用户、SUIM做权限查询。核心权限对象要一个个过S_TCODE控制事务码执行、S_TABU_DIS控制表维护、S_DEVELOP控制开发访问、S_RFC控制远程调用、S_USER_GRP控制用户组维护。用SUIM做交叉查询比如“谁既有F-02过账又有FB08冲销权限”输出报表后逐个人工复核。这里我最常看到的审计发现是角色继承带来的权限蔓延——一个用户挂了三五个复合角色每个角色单独看都合理合在一起就形成了权限过大的情况。4. 三层平台的纵深检查Basis视角下的Unix、NT与Oracle安全审计4.1 Unix层SM52、/usr/sap目录与suid程序Unix层审计最值得警惕的一个点是SAPMSOS0程序。原文说得很清楚这个程序能访问UNIX命令提示符通过事务码SM52运行。它相当于在SAP应用层和操作系统之间开了个通道谁能执行SM52谁就有机会拿到操作系统的shell。这一步的排查方式是用SUIM查哪些角色包含了S_TCODE的SM52授权然后把用户清单过一遍。系统账户层面按顺序查/etc/passwd看能直接登录Unix的用户/etc/group看组归属再核对oraSID和sidadm这类SAP系统账号有没有空密码或者共享密码。接着盯/usr/sap目录的读权限和写权限重点子目录原文都有交代/usr/sap/trans/buffer存放待导入传输/usr/sap/trans/cofiles存放传输请求/usr/sap/trans/sapnames记录用户传输状态/usr/sap/trans/tmp和/usr/sap/trans/log分别是临时数据与本地日志/usr/sap/trans/work是运行时数据。审计口径任何与SAP管理无关的用户都不该对这些目录有写权限。信任关系与网络导出是大坑。/etc/hosts.equiv和.rhost如果配置了信任关系等于把本机登录权限交给了远程主机/etc/exports里有SAP目录被NFS导出等于把系统文件暴露在网络上。我一般对这两个文件的审计态度是出现任何非空的信任配置都标记为高优先发现项然后再逐条评估是否必要。定时任务检查放在/usr/spool/cron/crontabs/root原文特别提到RDDIMPDP——SAP的传输调度程序默认每5分钟把排队队列里的作业传输到生产系统。如果这个作业被停掉传输会堆在buffer目录反过来如果它被篡改成更频繁的调用或指向异常目录就要警惕传输链路被劫持。最后是suid/sgid程序审计命令在下节避坑里细说。4.2 NT层账户清单、组成员、启动项与事件审计NT层审计的顺序从账户开始Administrators组成员逐个确认必要性所有用户和组核对是否有效默认账户规则是否强制所有用户登录密码规则按行业标准检查复杂度、过期期限和失败锁定次数。域与工作组的映射也要做用户和组挂到哪个域就按哪个域的安全策略来管。组权限复核要分三层看。公共用户组的能力是否每个人都需要个人专属组是否仍然必要Power User组、User组、Guest组的成员名单是否干净。Guest组这条我吃过亏后面的避坑章节会专门讲。用户权限分配层面还有一份“用户权利”清单要过谁能备份文件和目录、谁能修改系统时间、谁能从网络访问这台机器这些在NT/Windows里都对应具体的用户权利分配项。系统侧检查点包括用户登录脚本是否包含不安全批处理或映射敏感共享系统配置文件参数是否按基线设置屏幕保护是否启用且带密码设备管理器里介质设备访问是否受限安全警报是否配置了通知目录复制包括后来的DFS复制有没有把敏感数据复制到不受控的远程平台。事件审计要确认安全日志的开启范围、日志大小和覆盖策略最后再看备份程序的恢复演练记录确保应急计划不是纸面的。4.3 Oracle层INIT.ORA、默认账号与对象权限Oracle数据库层审计的第一步是确认职责分离系统DBA和SAP应用DBA不应该由同一批账号混着用。然后拿数据库初始化参数文件INIT.ORA找到关键参数。原文就明确要求查AUDIT_TRAIL是不是TRUE现在Oracle系统里对应的是DB或OS值再配合v$parameter看审计相关的实际运行参数。默认账号是必查项。SYS、SYSTEM、SCOTT是Oracle自带的经典默认账号原文特别写了SAPr3——这个账号在老版本R/3里是SAP数据库的Schema Owner密码如果还是默认的相当于数据库门户大开。需要澄清的是ECC时代常见的Schema Owner账号名是SAPSR3或SAPER3不同版本略有差异。正确做法不是猜名字而是直接从dba_users里把所有账号拉出来逐个检查账户状态、密码过期策略和profile。数据库权限要过三张视图的思路角色层面从dba_role_privs找谁持有DBA、RESOURCE这类大角色对象权限从dba_tab_grants和dba_col_grants看谁对着SAP schema里的表有直接增删改权限再盯WITH GRANT OPTION被赋给了哪些账号这是权限蔓延的经典通道。原文还单独点名了SAPDBA这个账号实务里很多系统直接用它当批处理账号密码长期不换审计时要特别留意。最后检查OSOPER角色和数据导入导出权限EXP_FULL_DATABASE/IMP_FULL_DATABASE以及PUBLIC用户被授予了什么——理论上PUBLIC的权限应当极其有限。4.4 接口对账提交方式、认证机制与数量核对第八部分虽然短但信息密度很高。原文核对表包括记录数、客户/供应商处理总数、借方总额、贷方总额、总金额、总交易量。这套对账项比只看“借贷相等”严格得多借贷相等只能证明总账是平的证明不了中间有没有漏掉批次。模式与认证要确认三件事接口提交方式批处理文件、RFC调用、IDoc、中间文件还是API、认证机制用户名密码还是证书、Token、以及消息失败后的处理流程。这里有个很典型的现场问题接口文件用共享目录扔给对方没有加密文件里的SAP用户名密码是明文。一旦发现这种情况报告里必然是高优先发现项。5. 实务避坑SAP审计中五个高发问题的现场记录5.1 读表和查权限时最容易翻的两个车现象审计员用SE16直接打开MARA、MSEG这种大表全表读取结果生产系统CPU打满被Basis团队紧急叫停审计活动被迫中断。原因SE16不带时间范围和字段过滤全表扫描在数据量上亿的表上会造成灾难性的缓冲压力和CPU消耗。T001、T024这类配置表随便读但业务表绝不能照同样的方式处理。解决读配置表用SE16加上限行数查大表改用DBACOCKPIT或直接连数据库执行只取必要字段的SQL时间窗口限定在业务低峰期。检查表数据量之前先看数据库表存储属性确认预估行数。现象有人把SE17当SE16用想只读表内容结果误入维护模式修改了生产环境的配置表数据。原因SE16/SE16N是数据浏览器SE17是通用表维护工具两者图标类似路径接近新接手审计的人很容易走错。解决只在审计指导手册里写SE16和SE16N两种入口明确要求“只读场景禁止使用SE17”。如果确实要做数据修改验证让客户Basis团队在测试客户端执行并保留传输请求号。5.2 Unix与Oracle检查命令里的经典误判现象原文里的suid命令是find / -name root -perm -4000 -print照抄执行后拿到的结果几乎都是文件名里包含root的文件真正带suid权限的程序反而没有完整列出。原因-name root过滤的是文件名不是属主或权限位。这条命令逻辑本身就是错的但它流传很广很多审计底稿里都还挂着。解决改成find / -perm -4000 -type f 2/dev/null | grep -v ^/proc | sortsgid同理把权限位换成-2000。输出结果先sort再存文件每天和前一天做diff。现象用sum命令每天对/etc/inittab生成校验和几天后发现输出一致就判断文件未被篡改。原因sum是早期Unix的简单校验和算法碰撞率远高于现代哈希攻击者可以构造等价校验和的文件。解决改用sha256sum和md5sum。完整性校验基准值要存到独立的安全位置比如备份服务器或运维堡垒机而不是放在同一台被审计的机器上。现象按老审计清单找Oracle默认账号SAPR3结果系统里查无此账号就在底稿里写“默认账号已处理”实际上没做任何验证。原因不同SAP版本和Oracle版本中schema owner的账号名并不统一。ECC系统里常见的是SAPSR3、SAPER3老清单里的SAPr3不一定存在。解决不看清单猜名字直接执行select username, account_status from dba_users对所有状态为OPEN的账号逐一检查密码策略和角色权限再查dba_role_privs确认没有普通业务账号持有DBA或RESOURCE。5.3 接口对账项里的“金额相等但记录少了”现象接口对账时借贷总额完全相等但两边凭证张数差了几百条最终定位到中间文件有一批订单因为格式校验失败被静默丢弃。原因对账只看总金额漏掉了记录数和交易量维度。两边的数据如果同时少了同一方向的一笔或者多笔一正一负正好抵消总额依然能对上。解决把对账维度拆成四个记录数、客户/供应商处理数、借贷方各自总额、总交易量。每个维度都要独立核对任何一个维度不一致都要追溯到具体批次。再有条件的话按时间窗口和状态码分组核对把失败状态的消息单独拉出来看。6. 把审计清单变成可重复跑的基线脚本、SQL与版本化检查表6.1 Unix端审计命令组合的一次成型把原文Unix部分的检查点整理成一段可直接落地的shell脚本每天生成一份带时间戳的基线第二天跑diff对比变化#!/bin/bash # sap_unix_audit.sh —— 每日Unix安全基线采集 TODAY$(date %F) YESTERDAY$(date -d yesterday %F 2/dev/null || date -v-1d %F) OUT/usr/sap/audit_baseline/$TODAY mkdir -p $OUT cat /etc/passwd $OUT/passwd.txt cat /etc/group $OUT/group.txt cat /etc/services $OUT/services.txt cat /etc/inetd.conf $OUT/inetd.conf.txt 2/dev/null ls -la /usr/sap $OUT/usr_sap_dir.txt find /usr/sap -type f | xargs ls -ld $OUT/usr_sap_files.txt 2/dev/null find / -perm -4000 -type f 2/dev/null | grep -v ^/proc | sort $OUT/suid.txt find / -perm -2000 -type f 2/dev/null | grep -v ^/proc | sort $OUT/sgid.txt cat /etc/inittab 2/dev/null | sha256sum $OUT/inittab.sha256 cat /etc/hosts.equiv $OUT/hosts.equiv.txt 2/dev/null cat /etc/exports $OUT/exports.txt 2/dev/null # 与昨日基线对比diff文件非空则重点关注 if [ -d /usr/sap/audit_baseline/$YESTERDAY ]; then diff $OUT/suid.txt /usr/sap/audit_baseline/$YESTERDAY/suid.txt $OUT/suid_diff.txt diff $OUT/sgid.txt /usr/sap/audit_baseline/$YESTERDAY/sgid.txt $OUT/sgid_diff.txt cat $OUT/suid_diff.txt $OUT/sgid_diff.txt fi脚本把原文的检查点分成了账户、服务、目录权限、suid/sgid、完整性五组核心逻辑是每天留底、次日对比。脚本要放在系统管理员自己维护的路径下输出目录要避开SAP的传输目录避免权限混乱。find命令里的grep -v ^/proc是排除伪文件系统避免干扰。6.2 用SQL一次拉出Oracle侧的权限基线Oracle侧的同类动作可以浓缩成下面这几条SQL每次审计先跑一遍把输出作为底稿附件-- 1. 所有数据库账号、状态与密码策略 SELECT username, profile, account_status, lock_date, expiry_date FROM dba_users ORDER BY username; -- 2. 持有DBA/RESOURCE大角色的用户 SELECT grantee, granted_role, admin_option FROM dba_role_privs WHERE granted_role IN (DBA, RESOURCE, IMP_FULL_DATABASE, EXP_FULL_DATABASE) ORDER BY grantee; -- 3. 对SAP Schema拥有增删改权限的对象授权 SELECT grantee, owner, table_name, privilege, grantable FROM dba_tab_grants WHERE owner SAPSR3 AND privilege IN (INSERT, UPDATE, DELETE) AND grantee ! SAPSR3 ORDER BY grantee, table_name; -- 4. 审计开关当前状态 SELECT name, value FROM v$parameter WHERE name LIKE %audit%;第一条SQL解决默认账号误判问题直接看所有账号现状第二条盯大角色授权第三条查对象级权限第四条确认审计开关。执行时需要DBA账号或SELECT_CATALOG_ROLE权限。四条SQL的输出全部保存成CSV或文本和当天的审计计划编号放在一起这就是检查表的原始依据。6.3 把80项检查点转成版本化检查表最后一步是流程上的习惯每次审计开始前把原文这份清单按章节拆成一张版本化的检查表每行至少包含检查项编号、控制点描述、探查方式、证据来源、风险等级、状态、责任人。用Excel或在线表格都好关键是三个字段不能被省略探查方式必须写到事务码或命令级别证据来源必须能定位到具体截图、脚本输出或访谈记录状态必须是待办/进行中/已完成/不适用四态之一不允许出现“待确认”这种模糊词。我一般会额外加一列“历史发现”把往年审计中这个检查点出过的问题填进去。这样做的好处是第二次审计不用把整个系统翻一遍直接针对历史风险点做回归即可。从那以后我每次启动SAP审计都强制先花二十分钟把这份清单转成带版本号的检查表在入场前把资料收集、技术盘点、平台层检查拆给不同的人分头跑中间对照检查表同步进度。不要在审计现场临时翻原文——翻到的永远是你最熟悉的几条漏掉的往往是T042G和/etc/exports这种角落。希望这份拆解能帮你在下一场SAP审计里少踩几个坑。本文还有配套的精品资源点击获取 SAP系统审计程序清单：从系统摸底到接口对账的完整链路
简介针对SAP系统审计场景的检查清单型资料面向企业内审、IT审计师、SAP Basis及合规管理人员帮助快速建立系统审计工作框架。资源共1个doc文件压缩包大小112KB内容以英文审计步骤清单为主并辅以中文要点说明。文档从总体概况切入要求先获取组织架构图、安全策略、应用架构图、问题跟踪记录、待实施系统增强、开发方法论、SLA、应急与灾难恢复计划等并逐步确认SAP版本、模块、生产系统接口、客户端数量与地理分布同时给出通过表T000、T001、TGSB、T024W等查询SAP客户端、公司、业务范围、信用控制区、工厂、采购组织、销售组织等关键主数据的具体路径。后续设计实施部分还覆盖项目规划、团队组织、岗位配置等评估要点。整体可作为SAP内外审的工作底稿或现场核查清单便于逐项对照执行提升安全合规与风险防控审计的完整性和效率。已有408人学习下载。1. 一份真正的SAP审计程序长什么样从系统摸底到接口对账的完整链路接手新客户的SAP系统审计手头最尴尬的往往不是专业知识不够而是只有一份通用IT审计底稿——问组织架构、问安全策略、问变更流程真到系统上却不知道应该敲哪个事务码。这份SAP系统审计程序清单把审计动作落到了具体对象上版本与模块识别、客户端清单、几十张后台表、Unix/NT/Oracle三个平台的检查命令、数据库默认账号与审计开关、接口对账项几乎每一项都能对应到一个事务码、一张表或一个配置文件。它解决的是审计过程中“不知道查什么、不知道在哪儿查”的问题适合做Basis运维、安全合规的人也适合FI/CO或MM顾问在项目上线前拿来做一轮自检。与其说它是审计报告模板不如说是一份SAP系统体检的检查点清单照着一步步走审计范围基本漏不了。2. 摸底阶段先盘家底版本、模块、客户端与主数据表清单怎么拉2.1 版本、模块与客户端摸清系统边界的四个入口SAP审计的第一步不是进系统到处翻而是先把审计范围“砸实”。原文I部分开列的公司组织架构图、安全策略、应用架构图、问题跟踪与事件报告、待实施系统增强清单、应用文档、开发方法论、SLA、应急与灾难恢复计划这些材料大多不在SAP系统里而在IT管理部门和应用支持小组手里。我的习惯是先建一个资料收集清单发给客户约一次系统盘点会议边聊边把下面这些技术点补齐效率比闷头翻系统高得多。版本与模块识别是第一个入口。登录GUI后用“系统→状态”看SAP版本信息或者用事务码SM51看应用服务器清单。老一点的ECC 6.0系统要核对EHP Enhancement Package和SP级别这决定了后面安全补丁审计的检查范围如果是S/4 HANA系统重点就完全不同。模块识别看安装清单常用做法是调用SE38看已存在的程序库或者直接看开发类和传输请求里频繁出现的事务码集中在哪个模块——FI/CO、MM、SD的权限对象和主数据表是完全不同的两套体系。客户端和安全边界是第三个入口。SCC4可以查看客户端角色生产、测试、定制T000表里也有客户端清单。生产系统里客户端数量过多本身就是风险信号尤其是测试客户端与生产客户端混在一个实例上的情况。地理位置分布决定数据流走向跨地域调用RFC时要检查运输层的加密和每个站点的参数文件。最后是接口清单。原文要求“determine the interfaces to the production system”这一步在实操里最容易漏。我一般用SM59拉RFC目标清单再看WE02/WE05里的IDoc记录确认生产系统与外围系统之间的接口都由谁触发、走什么协议。接口少了后面第八部分的对账审计根本无从谈起。2.2 从T000到TVKGR大体量主数据表一次拉全原文在General部分贴出了一张主数据表清单覆盖组织架构、财务、采购、销售的主数据入口。这张清单在审计现场非常有用我把它按模块整理成下面的对照表审计对象入口表对应模块SAP客户端T000系统基础公司代码T001FI集团内公司T042GFI业务范围TGSB / TGSBTFI信用控制范围T014 / T014TFI/CO科目表T004 / T004TFI工厂T001W / TVKWZMM存储地点T001LMM采购组织T024WMM采购组T024MM销售组织TVKO / TVKOTSD分销渠道TVTW / TVTWT / TVKOVSD部门DivisionTSPA / TSPAT / TVKOSSD销售范围TVTASD销售办事处TVBUR / TVKBT / TVKBZSD销售组TVKGR / TVBVK / TVGRTSD读取入口是原文给的路径SYSTEM → SERVICES → TABLE MAINTENANCE对应SM30TOOLS → ABAP/4 WORKBENCH → OVERVIEW → DATA BROWSER → TABLE CONTENTS对应SE16或SE17。审计场景下用SE16看表内容就够了SE16N也可以。这些表大多体量不大执行后能看到客户端、公司代码、销售组织、工厂这些组织元素的清单审计底稿里的“客户环境描述”部分就能直接填满。注意一点T042G在原文里对应“集团内公司”清单但实务里它和特别总账的容差组配置也有关系。我复核时会顺手看表内容是否和公司代码清单一致如果两个清单对不上说明后台配置里存在残余数据这种不一致本身就是一个发现项。2.3 定制化评估ABAP/4程序、数据录入画面与接口清单摸底阶段的最后一项是评估定制化程度。原文问的是“what level of custom programming is ongoing”包括ABAP/4程序和自定义数据录入画面。审计逻辑很简单定制越多运维成本和安全风险越高你越要关心开发变更是否走完了正式的传输流程。我一般用SE93查事务码到程序的映射用SE80看开发类和对象树SE38直接查看ABAP代码。重点判断是标准程序还是Z开头或Y开头的自定义程序数量有多少最近三个月有没有活跃开发。定制程序过多有时候意味着标准功能没有被用起来而自定义画面通常会绕过标准字段检查这是审计报告里值得写一笔的观察项。接口清单要单独立一个台账。生产系统和外围系统之间的接口文件、中间表、RFC调用都算顺序是这样的先把SM59里的RFC目标全部拉出来再看SM37里的后台作业有哪些是周期性往外部系统传数据的最后核对批处理日志。原文第八部分的对账项record counts、借贷总额、处理客户/供应商数能不能做完全取决于这个接口台账是否完整。3. 从项目治理到职责分离SAP ECC实施阶段的配置审计与PFCG权限矩阵3.1 项目规划与组织指导委员会、技术团队与核心模块5-7人原文第二部分叫Design And Implementation内容全是实施阶段的项目治理问题。规划层面问的是有没有明确的功能或地理实施路线有没有采用结构化方法论有没有自上而下的顶层计划来处理系统集成问题计划里有没有考虑SAP版本发布时间和实施完成后的复盘窗口这些问题没有技术性那么强但恰恰是很多项目后期翻车的根源。组织与人员配置的检查点很具体。指导委员会要覆盖所有业务领域企业级标准要提前建立用户要担任关键项目管理岗位而不是只当“业务代表”集成团队要从各功能领域抽人技术团队要独立于功能团队。原文给了一条硬数字每个核心模块5-7人。这个数字在SAP项目里基本是标配少于这个规模后面日常配置、功能测试、知识转移根本忙不过来。我通常会把客户项目组的组织架构图拿来和这条清单对照重点看两件事技术团队向谁汇报、集成团队有没有实权。很多项目里集成团队只是挂个名所有集成决策全靠实施商主导这种治理结构下接口测试做得再好上线后也容易出职责真空。3.2 培训、变更管理与重组流程先达成共识再上线培训这块的检查点看似虚实际上是项目质量最直接的信号。原文要求确认培训方案覆盖所有功能领域、培训方式纳入项目方法论、各级培训时间是否排够。实操里我会去看培训签到表、培训材料版本和考核结果而不只是看培训计划PPT。变更与项目控制方面原文要求看四样东西跨团队的标准沟通工具与文档格式、每周甚至每日的跨团队进度会与月度指导委员会会议、问题日志、以工作包任务和交付物衡量的项目度量方式。原文还提到支持系统要在项目最开始就建立当时写的是Lotus Notes或email现在对应到Teams、Confluence这类协作平台——检查点不变变的只是工具名。重组流程re-engineering的检查点容易被忽略大规模业务重组要在SAP实施前完成否则变更需求应该合并到分析设计阶段处理而且所有重组过程必须正式签字确认。这条的现场表现通常是业务方一边上线SAP一边改组织架构MRP范围和成本中心架构反复变最后配置被改得面目全非。审计时一旦发现重组流程没有正式sign-off就要标记为中等以上风险。3.3 全局设计与集成测试JAD工作坊、关键检查点与跨团队配置核对Global Design不是指画一张架构图而是问几个具体问题全球流程是否与SAP功能对齐、各区域代表是否参与了原型验证和JADJoin Application Develop工作坊、系统关键检查点是否映射到全球设计、关键主数据字段物料号、客户号、科目表、公司代码是否全球统一。这三条放在一起看本质上是在查一个东西是否有人拿业务集成视角审过系统设计。很多项目做集成测试只测技术接口通不通不测端到端业务流程——比如SD发货以后FI凭证能不能按设计生成、MM收货以后CO分配能不能进入正确的成本对象。SAP里的Workflow通常就是在这种集成场景里暴露问题审批流断在某个环节、IDoc状态长时间停在错误码都是审计现场最常撞见的现象。配置审计要落到交叉检查上。原文要求确认是否有周期性的表配置交叉检查、表格和文件结构是否跨地点一致。对应到ECC时代就是拿传输请求清单做分析重点审非标准修改Modifications一个非标准修改至少要能回答三个问题为什么改、谁批的、测试覆盖了什么。配置漂移一旦发生最麻烦的还不是功能异常而是没人说得清楚它什么时候变的。3.4 配置审计与职责分离矩阵从权限对象到PFCG角色职责分离是审计报告中风险等级最高的部分。原文说得很直白“matrixes are used to define job functions and proper separation of duties”。落地到SAP里就是角色和权限对象的组合矩阵。FICO里面常见的危险组合是记账与冲销在同一个角色里物流侧是主数据维护和货物移动混合授权开发侧是SE38/SE37和SCC4配置权限握在一个人手里。ECC时代的落地路径是PFCG建角色、SU01分配用户、SUIM做权限查询。核心权限对象要一个个过S_TCODE控制事务码执行、S_TABU_DIS控制表维护、S_DEVELOP控制开发访问、S_RFC控制远程调用、S_USER_GRP控制用户组维护。用SUIM做交叉查询比如“谁既有F-02过账又有FB08冲销权限”输出报表后逐个人工复核。这里我最常看到的审计发现是角色继承带来的权限蔓延——一个用户挂了三五个复合角色每个角色单独看都合理合在一起就形成了权限过大的情况。4. 三层平台的纵深检查Basis视角下的Unix、NT与Oracle安全审计4.1 Unix层SM52、/usr/sap目录与suid程序Unix层审计最值得警惕的一个点是SAPMSOS0程序。原文说得很清楚这个程序能访问UNIX命令提示符通过事务码SM52运行。它相当于在SAP应用层和操作系统之间开了个通道谁能执行SM52谁就有机会拿到操作系统的shell。这一步的排查方式是用SUIM查哪些角色包含了S_TCODE的SM52授权然后把用户清单过一遍。系统账户层面按顺序查/etc/passwd看能直接登录Unix的用户/etc/group看组归属再核对oraSID和sidadm这类SAP系统账号有没有空密码或者共享密码。接着盯/usr/sap目录的读权限和写权限重点子目录原文都有交代/usr/sap/trans/buffer存放待导入传输/usr/sap/trans/cofiles存放传输请求/usr/sap/trans/sapnames记录用户传输状态/usr/sap/trans/tmp和/usr/sap/trans/log分别是临时数据与本地日志/usr/sap/trans/work是运行时数据。审计口径任何与SAP管理无关的用户都不该对这些目录有写权限。信任关系与网络导出是大坑。/etc/hosts.equiv和.rhost如果配置了信任关系等于把本机登录权限交给了远程主机/etc/exports里有SAP目录被NFS导出等于把系统文件暴露在网络上。我一般对这两个文件的审计态度是出现任何非空的信任配置都标记为高优先发现项然后再逐条评估是否必要。定时任务检查放在/usr/spool/cron/crontabs/root原文特别提到RDDIMPDP——SAP的传输调度程序默认每5分钟把排队队列里的作业传输到生产系统。如果这个作业被停掉传输会堆在buffer目录反过来如果它被篡改成更频繁的调用或指向异常目录就要警惕传输链路被劫持。最后是suid/sgid程序审计命令在下节避坑里细说。4.2 NT层账户清单、组成员、启动项与事件审计NT层审计的顺序从账户开始Administrators组成员逐个确认必要性所有用户和组核对是否有效默认账户规则是否强制所有用户登录密码规则按行业标准检查复杂度、过期期限和失败锁定次数。域与工作组的映射也要做用户和组挂到哪个域就按哪个域的安全策略来管。组权限复核要分三层看。公共用户组的能力是否每个人都需要个人专属组是否仍然必要Power User组、User组、Guest组的成员名单是否干净。Guest组这条我吃过亏后面的避坑章节会专门讲。用户权限分配层面还有一份“用户权利”清单要过谁能备份文件和目录、谁能修改系统时间、谁能从网络访问这台机器这些在NT/Windows里都对应具体的用户权利分配项。系统侧检查点包括用户登录脚本是否包含不安全批处理或映射敏感共享系统配置文件参数是否按基线设置屏幕保护是否启用且带密码设备管理器里介质设备访问是否受限安全警报是否配置了通知目录复制包括后来的DFS复制有没有把敏感数据复制到不受控的远程平台。事件审计要确认安全日志的开启范围、日志大小和覆盖策略最后再看备份程序的恢复演练记录确保应急计划不是纸面的。4.3 Oracle层INIT.ORA、默认账号与对象权限Oracle数据库层审计的第一步是确认职责分离系统DBA和SAP应用DBA不应该由同一批账号混着用。然后拿数据库初始化参数文件INIT.ORA找到关键参数。原文就明确要求查AUDIT_TRAIL是不是TRUE现在Oracle系统里对应的是DB或OS值再配合v$parameter看审计相关的实际运行参数。默认账号是必查项。SYS、SYSTEM、SCOTT是Oracle自带的经典默认账号原文特别写了SAPr3——这个账号在老版本R/3里是SAP数据库的Schema Owner密码如果还是默认的相当于数据库门户大开。需要澄清的是ECC时代常见的Schema Owner账号名是SAPSR3或SAPER3不同版本略有差异。正确做法不是猜名字而是直接从dba_users里把所有账号拉出来逐个检查账户状态、密码过期策略和profile。数据库权限要过三张视图的思路角色层面从dba_role_privs找谁持有DBA、RESOURCE这类大角色对象权限从dba_tab_grants和dba_col_grants看谁对着SAP schema里的表有直接增删改权限再盯WITH GRANT OPTION被赋给了哪些账号这是权限蔓延的经典通道。原文还单独点名了SAPDBA这个账号实务里很多系统直接用它当批处理账号密码长期不换审计时要特别留意。最后检查OSOPER角色和数据导入导出权限EXP_FULL_DATABASE/IMP_FULL_DATABASE以及PUBLIC用户被授予了什么——理论上PUBLIC的权限应当极其有限。4.4 接口对账提交方式、认证机制与数量核对第八部分虽然短但信息密度很高。原文核对表包括记录数、客户/供应商处理总数、借方总额、贷方总额、总金额、总交易量。这套对账项比只看“借贷相等”严格得多借贷相等只能证明总账是平的证明不了中间有没有漏掉批次。模式与认证要确认三件事接口提交方式批处理文件、RFC调用、IDoc、中间文件还是API、认证机制用户名密码还是证书、Token、以及消息失败后的处理流程。这里有个很典型的现场问题接口文件用共享目录扔给对方没有加密文件里的SAP用户名密码是明文。一旦发现这种情况报告里必然是高优先发现项。5. 实务避坑SAP审计中五个高发问题的现场记录5.1 读表和查权限时最容易翻的两个车现象审计员用SE16直接打开MARA、MSEG这种大表全表读取结果生产系统CPU打满被Basis团队紧急叫停审计活动被迫中断。原因SE16不带时间范围和字段过滤全表扫描在数据量上亿的表上会造成灾难性的缓冲压力和CPU消耗。T001、T024这类配置表随便读但业务表绝不能照同样的方式处理。解决读配置表用SE16加上限行数查大表改用DBACOCKPIT或直接连数据库执行只取必要字段的SQL时间窗口限定在业务低峰期。检查表数据量之前先看数据库表存储属性确认预估行数。现象有人把SE17当SE16用想只读表内容结果误入维护模式修改了生产环境的配置表数据。原因SE16/SE16N是数据浏览器SE17是通用表维护工具两者图标类似路径接近新接手审计的人很容易走错。解决只在审计指导手册里写SE16和SE16N两种入口明确要求“只读场景禁止使用SE17”。如果确实要做数据修改验证让客户Basis团队在测试客户端执行并保留传输请求号。5.2 Unix与Oracle检查命令里的经典误判现象原文里的suid命令是find / -name root -perm -4000 -print照抄执行后拿到的结果几乎都是文件名里包含root的文件真正带suid权限的程序反而没有完整列出。原因-name root过滤的是文件名不是属主或权限位。这条命令逻辑本身就是错的但它流传很广很多审计底稿里都还挂着。解决改成find / -perm -4000 -type f 2/dev/null | grep -v ^/proc | sortsgid同理把权限位换成-2000。输出结果先sort再存文件每天和前一天做diff。现象用sum命令每天对/etc/inittab生成校验和几天后发现输出一致就判断文件未被篡改。原因sum是早期Unix的简单校验和算法碰撞率远高于现代哈希攻击者可以构造等价校验和的文件。解决改用sha256sum和md5sum。完整性校验基准值要存到独立的安全位置比如备份服务器或运维堡垒机而不是放在同一台被审计的机器上。现象按老审计清单找Oracle默认账号SAPR3结果系统里查无此账号就在底稿里写“默认账号已处理”实际上没做任何验证。原因不同SAP版本和Oracle版本中schema owner的账号名并不统一。ECC系统里常见的是SAPSR3、SAPER3老清单里的SAPr3不一定存在。解决不看清单猜名字直接执行select username, account_status from dba_users对所有状态为OPEN的账号逐一检查密码策略和角色权限再查dba_role_privs确认没有普通业务账号持有DBA或RESOURCE。5.3 接口对账项里的“金额相等但记录少了”现象接口对账时借贷总额完全相等但两边凭证张数差了几百条最终定位到中间文件有一批订单因为格式校验失败被静默丢弃。原因对账只看总金额漏掉了记录数和交易量维度。两边的数据如果同时少了同一方向的一笔或者多笔一正一负正好抵消总额依然能对上。解决把对账维度拆成四个记录数、客户/供应商处理数、借贷方各自总额、总交易量。每个维度都要独立核对任何一个维度不一致都要追溯到具体批次。再有条件的话按时间窗口和状态码分组核对把失败状态的消息单独拉出来看。6. 把审计清单变成可重复跑的基线脚本、SQL与版本化检查表6.1 Unix端审计命令组合的一次成型把原文Unix部分的检查点整理成一段可直接落地的shell脚本每天生成一份带时间戳的基线第二天跑diff对比变化#!/bin/bash # sap_unix_audit.sh —— 每日Unix安全基线采集 TODAY$(date %F) YESTERDAY$(date -d yesterday %F 2/dev/null || date -v-1d %F) OUT/usr/sap/audit_baseline/$TODAY mkdir -p $OUT cat /etc/passwd $OUT/passwd.txt cat /etc/group $OUT/group.txt cat /etc/services $OUT/services.txt cat /etc/inetd.conf $OUT/inetd.conf.txt 2/dev/null ls -la /usr/sap $OUT/usr_sap_dir.txt find /usr/sap -type f | xargs ls -ld $OUT/usr_sap_files.txt 2/dev/null find / -perm -4000 -type f 2/dev/null | grep -v ^/proc | sort $OUT/suid.txt find / -perm -2000 -type f 2/dev/null | grep -v ^/proc | sort $OUT/sgid.txt cat /etc/inittab 2/dev/null | sha256sum $OUT/inittab.sha256 cat /etc/hosts.equiv $OUT/hosts.equiv.txt 2/dev/null cat /etc/exports $OUT/exports.txt 2/dev/null # 与昨日基线对比diff文件非空则重点关注 if [ -d /usr/sap/audit_baseline/$YESTERDAY ]; then diff $OUT/suid.txt /usr/sap/audit_baseline/$YESTERDAY/suid.txt $OUT/suid_diff.txt diff $OUT/sgid.txt /usr/sap/audit_baseline/$YESTERDAY/sgid.txt $OUT/sgid_diff.txt cat $OUT/suid_diff.txt $OUT/sgid_diff.txt fi脚本把原文的检查点分成了账户、服务、目录权限、suid/sgid、完整性五组核心逻辑是每天留底、次日对比。脚本要放在系统管理员自己维护的路径下输出目录要避开SAP的传输目录避免权限混乱。find命令里的grep -v ^/proc是排除伪文件系统避免干扰。6.2 用SQL一次拉出Oracle侧的权限基线Oracle侧的同类动作可以浓缩成下面这几条SQL每次审计先跑一遍把输出作为底稿附件-- 1. 所有数据库账号、状态与密码策略 SELECT username, profile, account_status, lock_date, expiry_date FROM dba_users ORDER BY username; -- 2. 持有DBA/RESOURCE大角色的用户 SELECT grantee, granted_role, admin_option FROM dba_role_privs WHERE granted_role IN (DBA, RESOURCE, IMP_FULL_DATABASE, EXP_FULL_DATABASE) ORDER BY grantee; -- 3. 对SAP Schema拥有增删改权限的对象授权 SELECT grantee, owner, table_name, privilege, grantable FROM dba_tab_grants WHERE owner SAPSR3 AND privilege IN (INSERT, UPDATE, DELETE) AND grantee ! SAPSR3 ORDER BY grantee, table_name; -- 4. 审计开关当前状态 SELECT name, value FROM v$parameter WHERE name LIKE %audit%;第一条SQL解决默认账号误判问题直接看所有账号现状第二条盯大角色授权第三条查对象级权限第四条确认审计开关。执行时需要DBA账号或SELECT_CATALOG_ROLE权限。四条SQL的输出全部保存成CSV或文本和当天的审计计划编号放在一起这就是检查表的原始依据。6.3 把80项检查点转成版本化检查表最后一步是流程上的习惯每次审计开始前把原文这份清单按章节拆成一张版本化的检查表每行至少包含检查项编号、控制点描述、探查方式、证据来源、风险等级、状态、责任人。用Excel或在线表格都好关键是三个字段不能被省略探查方式必须写到事务码或命令级别证据来源必须能定位到具体截图、脚本输出或访谈记录状态必须是待办/进行中/已完成/不适用四态之一不允许出现“待确认”这种模糊词。我一般会额外加一列“历史发现”把往年审计中这个检查点出过的问题填进去。这样做的好处是第二次审计不用把整个系统翻一遍直接针对历史风险点做回归即可。从那以后我每次启动SAP审计都强制先花二十分钟把这份清单转成带版本号的检查表在入场前把资料收集、技术盘点、平台层检查拆给不同的人分头跑中间对照检查表同步进度。不要在审计现场临时翻原文——翻到的永远是你最熟悉的几条漏掉的往往是T042G和/etc/exports这种角落。希望这份拆解能帮你在下一场SAP审计里少踩几个坑。本文还有配套的精品资源点击获取