简介这份SAP系统审计程序资料面向企业内部审计人员、IT合规与风控从业者以及需要了解SAP审计流程的顾问与学习者帮助解决审计准备阶段缺乏系统化清单、难以界定审计范围与取证对象的问题。资源以英文审计程序清单为主体从组织架构、安全政策、应用架构、问题跟踪记录、系统增强队列、开发方法论、服务级别协议、应急与灾难恢复计划等维度展开并延伸到SAP版本与模块识别、生产系统接口、客户端数量、地理部署、定制编程程度评估以及整体安全架构、操作系统与数据库环境核查还列出客户端、公司代码、业务区域、信用控制区、科目表、工厂、存储地点、采购组织与采购组等关键业务对象对应的数据表查询路径便于按图索骥完成取证。压缩包内共1个doc文档约112KB结构紧凑适合作为审计底稿模板或自查清单直接套用。目前已有410人学习可作为SAP审计入门与实务对照的参考材料。1. 审计 SAP 系统为什么拿到组织架构图比拿到 Root 密码更关键很多开发者第一次接触 SAP 审计脑子里蹦出来的第一个念头是这不就是查权限、看配置、翻日志吗但真正做过一轮完整审计的人会告诉你最难的从来不是技术手段而是搞清楚“谁在什么位置、能碰什么数据、这些权限到底该不该给”。SAP 审计程序的第一章不是去翻代码而是去要组织架构图、安全政策文档、应用架构图、事件报告、待实施增强清单——这些看起来像行政流程的东西恰恰是整个审计链条里最不能跳过的一环。原因很直接SAP 是一个把业务流程和权限控制深度耦合的系统一个公司代码对应一个法人实体一个采购组织对应一条供应链一个工厂对应一个物理地点。你如果不先搞清楚这些组织单元怎么划分、谁对谁负责后面看任何一张表、任何一个权限对象都会失去参照系。换句话说审计 SAP 的第一步不是“查系统”而是“查组织”因为系统里的每一行配置都是组织意图的投影。这也是为什么审计程序把“获取公司组织架构图”放在第一条——它决定了后面所有技术检查的边界和优先级。2. 组织单元与配置表SAP 审计的底层数据模型是怎么映射业务的2.1 从 T000 到 T001客户端与公司代码的层级关系SAP 审计程序里有一组非常具体的表清单比如 T000 存客户端、T001 存公司代码、T042G 存集团、TGSB 和 TGSBT 存业务领域、T014 和 T014T 存信用控制范围、T004 和 T004T 存会计科目表、T001W 和 TVKWZ 存工厂、T001L 存存储地点、T024W 存采购组织、T024 存采购组、TVKO 和 TVKOT 存销售组织、TVTW 和 TVTWT 存分销渠道、TSPA 和 TSPAT 存产品组、TVTA 存销售区域、TVBUR 和 TVKBT 存销售办公室、TVKGR 和 TVBVK 存销售组。这些表名不是随便列的它们构成了 SAP 组织架构的骨架。审计员拿到这些表的数据实际上是在还原一个企业的业务拓扑哪些公司代码在同一个客户端下运行、哪些工厂属于同一个采购组织、哪些销售组织覆盖了哪些分销渠道。这个拓扑决定了权限设计的粒度——比如一个采购组只能看到自己负责的采购组织下的采购订单一个销售办公室只能访问自己所属销售区域内的客户主数据。如果这些表的数据和实际业务不符比如某个工厂被错误地挂到了另一个采购组织下那么基于这个错误配置建立的所有权限控制都会失效。常见的实现思路是审计员会先用 SE16 或 SE17 把这些表导出来然后和业务部门提供的组织架构图做交叉比对重点看有没有“表里有但图上没有”或者“图上有但表里没有”的实体。这种差异往往就是配置漂移或者权限越界的信号。2.2 权限对象与角色SAP 授权机制的核心逻辑SAP 的权限控制不是简单的“用户-菜单”映射而是通过权限对象、权限字段、活动值三层结构来实现的。一个权限对象比如 M_BEST_BSA 控制采购订单的创建它包含字段如 ACTVT活动比如 01 创建、02 修改、03 显示、BSART订单类型、WERKS工厂。一个角色把若干权限对象组合起来分配给用户。审计员要检查的是这个角色的权限字段值是不是过宽比如一个采购员角色如果给了 WERKS *那就意味着他可以在所有工厂下创建采购订单这显然违反了最小权限原则。更隐蔽的问题是“权限对象之间的组合爆炸”——SAP 允许通过参数文件生成器Profile Generator自动生成角色但如果组织级别字段没有正确限制自动生成的角色可能包含大量冗余权限。审计程序里提到的“评估 SAP 整体安全架构”和“确定矩阵是否用于定义岗位职能和职责分离”本质上就是在检查这个权限模型有没有被正确落地。一个常见的翻车场景是某公司为了赶上线进度直接给所有财务用户分配了 SAP_ALL 参数文件然后打算“后面再细化”。结果三年过去了这个参数文件还在审计员一查发现一个应付会计能过账总账、能修改供应商主数据、还能跑薪资报表。这种问题不是技术漏洞而是权限治理的缺失但它的根因往往可以追溯到组织架构和职责分离设计阶段就没有做好。2.3 定制开发与接口审计范围如何被 ABAP 程序改变SAP 审计程序里有一条很关键确定正在进行的 ABAP/4 程序和数据录入屏幕的定制编程程度。为什么这条重要因为标准 SAP 的权限控制是经过验证的但一旦你写了自定义 ABAP 程序就可能绕过标准权限检查。比如一个自定义的报表程序如果用了AUTHORITY-CHECK语句但写错了权限对象或者干脆没写那么任何能执行这个程序的用户都能看到本不该看到的数据。更常见的是自定义数据录入屏幕——它们可能直接写数据库表跳过了 SAP 的更新任务和权限校验逻辑。审计员需要拿到所有自定义程序的清单然后重点看那些涉及敏感操作比如修改财务凭证、读取客户主数据、调用外部接口的程序。常见的实现思路是用 SE38 或 SE80 搜索 Z 开头和 Y 开头的程序然后结合代码扫描工具检查有没有缺失的权限检查。接口方面SAP 和外部系统的数据交换通常通过 RFC、IDoc、BAPI 或者文件接口实现。审计员要确认这些接口有没有做认证、有没有做数据校验、有没有记录日志。一个典型的踩坑案例是某公司用 RFC 把 SAP 的客户主数据同步到 CRM 系统但 RFC 目标系统配置里用了默认的 SAP 用户和密码而且这个用户有 SAP_ALL 权限。结果任何能访问 CRM 服务器的人都能通过 RFC 调用 SAP 的 BAPI 修改客户数据。这种问题在审计程序里对应的是“确定与生产系统的接口”和“评估中间件连接的安全性”。3. 操作系统与数据库层为什么 SAP 审计必须穿透到 Unix 和 Oracle3.1 SAPMSOS0 与 Unix 命令提示符一个程序如何打开后门SAP 审计程序第五章第一条就点了一个非常具体的程序SAPMSOS0。这个程序可以通过事务 SM52 运行它的作用是访问 Unix 命令提示符。换句话说任何能执行这个程序的用户实际上就拿到了操作系统的 shell。审计员要做的第一件事就是确定谁有权限执行 SAPMSOS0。在标准 SAP 里这个程序通常只应该给系统管理员或者 Basis 团队但实际环境中经常发现它被分配给了开发人员甚至业务用户原因往往是“为了方便排查问题”。更危险的是如果这个程序被分配给了权限过宽的角色而该角色又通过 RFC 暴露给了外部系统那么攻击者就可以从外部系统一路穿透到操作系统。审计程序里还提到要检查/usr/sap目录的读写权限特别是/usr/sap/trans下的子目录buffer 存待导入的传输请求、cofiles 存传输请求信息、sapnames 存传输请求状态、tmp 存临时数据、log 存本地系统日志、work 存运行时数据。这些目录如果对非 SAP 管理员可写攻击者就可以篡改传输请求把恶意代码从开发系统一路传到生产系统。常见的实现思路是审计员会先跑cat /etc/passwd和cat /etc/group看有哪些系统用户和组然后检查/etc/inittab有没有做完整性校验比如每天跑一次 sum 命令再检查/etc/hosts.equiv和.rhost有没有配置信任关系最后用find / -name root -perm -4000 -print和find / -name root -perm -2000 -print找出所有 suid 和 sgid 程序用 sum 和 diff 做每日比对。这套流程的核心逻辑是SAP 的安全边界不止在 SAP 本身操作系统层的任何松动都会让 SAP 的权限控制形同虚设。3.2 Oracle 的 INIT.ORA 与审计开关数据库层审计的起点SAP 审计程序第七章专门针对 Oracle DBMS。第一条就是确定 DBA 职责有没有分离——这听起来像管理问题但它的技术后果很直接如果一个 DBA 既能修改数据又能修改审计日志那么审计日志就失去了证据价值。接下来要拿到 INIT.ORA 文件检查AUDIT_TRAIL参数有没有设为 TRUE。这个参数控制 Oracle 的审计功能是否开启。如果没开那么所有数据库层的操作都不会被记录审计员只能看到 SAP 应用层的日志而应用层日志是可以被有权限的用户删除或篡改的。审计程序还要求拿到 DBA_OBJECTS、DBA_TAB_COLUMNS、DBA_USERS、DBA_VIEWS 这些数据字典视图以及 DBA_TAB_GRANTS 和 DBA_COL_GRANTS 来检查对象权限。重点看WITH GRANT OPTION有没有被滥用——如果一个普通用户拿到了某个表的 WITH GRANT OPTION他就可以把这个表的访问权限转授给其他人从而绕过 DBA 的权限管理。还有一个经常被忽略的点默认用户和密码。审计程序明确列出了 SYS、SYSTEM、SCOTT、SAPR3 这几个默认账户要求确认它们的默认密码已经被修改。在实际环境中SAPR3 这个账户的密码经常被设成和用户名一样因为它通常被用来做数据库连接池的认证改了密码就要改配置很多人嫌麻烦就不改。但这就意味着任何知道 SAPR3 密码的人都能直接连到数据库绕过 SAP 应用层的所有权限检查。审计员还会检查OSOPER角色有没有分配给无效用户以及Public角色的权限有没有被严格限制——Oracle 的 Public 角色默认给所有用户如果它被授予了敏感权限那就等于所有用户都有了这个权限。3.3 NT 与 Unix 的权限模型差异审计程序为什么要分开写SAP 审计程序把 Unix 和 NT 的审查分开写这不是凑字数而是因为两个操作系统的权限模型有本质差异。Unix 用 uid/gid、文件权限位rwx、suid/sgid 来控制访问审计员可以用find和sum做精确的完整性比对。NTWindows用用户账户、组、域、访问控制列表ACL来控制审计员要检查 Administrators 组的成员、默认账户规则、密码策略、域和工作组的划分、用户组和 Power User 组的成员、Guest 组的权限、登录脚本、屏幕保护密码、设备安全设置、目录复制、事件审计策略。NT 审计里有一条特别值得注意检查启动应用程序确保只有授权应用被访问。这是因为 Windows 的启动文件夹和注册表 Run 键经常被恶意软件利用如果审计员不检查攻击者就可以通过一个看似正常的启动项来执行未授权程序。Unix 审计里对应的是检查/etc/services和/etc/inetd.conf确保没有不安全的服务在运行。两个系统的审计逻辑是一样的——确认只有授权的主体能访问授权的客体但实现手段和检查点完全不同。审计员如果只懂 Unix 不懂 NT或者反过来就会在另一个平台上留下盲区。4. 避坑与排查SAP 审计中最容易翻车的五个场景4.1 只查 SAP 层不查操作系统结果被一个 suid 程序打穿现象审计报告说 SAP 权限配置符合最小权限原则但渗透测试时攻击者通过一个 suid 程序拿到了 root shell然后直接读走了 Oracle 的数据文件。原因审计员只检查了 SAP 的角色和权限对象没有跑find / -perm -4000去查 suid 程序也没有检查/usr/sap/trans目录的写权限。解决每次审计必须包含操作系统层的 suid/sgid 扫描和关键目录权限检查并且用 sum 和 diff 做每日基线比对。4.2 默认密码没改SAPR3 成了万能钥匙现象SAP 应用层权限看起来很严但有人用 SAPR3 账户直接连数据库绕过了所有 SAP 权限检查。原因SAPR3 是 SAP 安装时创建的默认数据库用户很多管理员为了省事不改密码或者改了之后没有同步更新连接池配置。解决审计时必须检查所有默认账户的密码状态包括 SYS、SYSTEM、SCOTT、SAPR3并且确认密码策略强制要求定期更换。4.3 自定义 ABAP 程序缺少 AUTHORITY-CHECK权限控制形同虚设现象标准事务码的权限控制没问题但用户通过一个自定义报表看到了全公司的薪资数据。原因开发人员在写自定义 ABAP 程序时没有加AUTHORITY-CHECK语句或者加错了权限对象。解决审计时要拿到所有 Z 开头和 Y 开头的程序清单用代码扫描工具检查权限检查语句重点看涉及敏感数据读取的程序。4.4 审计日志没开出了事查不到是谁干的现象发现数据被篡改但查遍 SAP 日志和数据库日志都找不到操作记录。原因Oracle 的AUDIT_TRAIL参数没设为 TRUE或者 SAP 的审计日志SM19/SM20没有激活。解决审计时必须检查INIT.ORA里的AUDIT_TRAIL设置以及 SAP 的审计配置确保关键操作比如修改财务凭证、修改权限、执行 SAPMSOS0都被记录。4.5 接口认证用默认账户外部系统成了跳板现象SAP 本身权限没问题但攻击者通过 CRM 系统的 RFC 连接调用了 SAP 的 BAPI修改了客户主数据。原因RFC 目标系统配置里用了默认的 SAP 用户和密码而且这个用户权限过大。解决审计时要检查所有 RFC 目标系统的认证配置确认没有使用默认账户并且每个接口用户都遵循最小权限原则。5. 审计程序的设计取舍为什么它不直接给你一个自动化脚本SAP 审计程序从头到尾没有给你一个可以一键运行的脚本而是列了八章、上百条检查项从组织架构图要到 Oracle 的INIT.ORA从 Unix 的 suid 扫描要到 NT 的域用户映射。这种设计看起来很低效但它背后有一个很现实的取舍SAP 环境的高度定制化决定了没有一套通用的自动化脚本能覆盖所有场景。一个公司可能只上了 FI 和 CO 模块另一个公司上了 FI、CO、MM、SD、PP、QM、PM、HR 全套两者的审计范围完全不同。一个公司可能把所有系统都放在一个客户端下另一个公司有几十个客户端分布在不同的地理区域审计的复杂度差了一个数量级。审计程序选择用“检查项清单”而不是“自动化工具”的形式是为了让审计员根据实际情况判断每一条是否适用、适用到什么程度。比如“确定运行的客户端数量”这一条在一个只有单一客户端的公司里可能只需要看一眼 T000 表但在一个多客户端的集团里就需要检查每个客户端的配置差异、权限差异、传输路径差异。这种判断力是脚本给不了的。另一个取舍是审计程序把大量篇幅放在了“获取文档”和“访谈”上而不是纯技术检查。这是因为 SAP 的很多控制是流程控制不是技术控制。比如“确定是否进行了适当的培训”这一条你没法用代码检查一个用户有没有真正理解他的权限边界你只能看培训记录、访谈用户、观察操作行为。技术检查能发现配置错误但发现不了“配置正确但执行走样”的问题。我一般会这么理解这份审计程序的价值不在于它列了多少条而在于它强迫审计员在动手查表之前先把业务背景、组织架构、流程设计、技术架构这四个层面都过一遍。从那以后我每次做 SAP 审计都会先把组织架构图和 T000/T001 的数据对一遍再去看权限角色最后才碰操作系统和数据库。这个顺序不能反反了就会陷入“查了一堆表但不知道这些表代表什么业务含义”的困境。希望帮到你。本文还有配套的精品资源点击获取
简介这份SAP系统审计程序资料面向企业内部审计人员、IT合规与风控从业者以及需要了解SAP审计流程的顾问与学习者帮助解决审计准备阶段缺乏系统化清单、难以界定审计范围与取证对象的问题。资源以英文审计程序清单为主体从组织架构、安全政策、应用架构、问题跟踪记录、系统增强队列、开发方法论、服务级别协议、应急与灾难恢复计划等维度展开并延伸到SAP版本与模块识别、生产系统接口、客户端数量、地理部署、定制编程程度评估以及整体安全架构、操作系统与数据库环境核查还列出客户端、公司代码、业务区域、信用控制区、科目表、工厂、存储地点、采购组织与采购组等关键业务对象对应的数据表查询路径便于按图索骥完成取证。压缩包内共1个doc文档约112KB结构紧凑适合作为审计底稿模板或自查清单直接套用。目前已有410人学习可作为SAP审计入门与实务对照的参考材料。1. 审计 SAP 系统为什么拿到组织架构图比拿到 Root 密码更关键很多开发者第一次接触 SAP 审计脑子里蹦出来的第一个念头是这不就是查权限、看配置、翻日志吗但真正做过一轮完整审计的人会告诉你最难的从来不是技术手段而是搞清楚“谁在什么位置、能碰什么数据、这些权限到底该不该给”。SAP 审计程序的第一章不是去翻代码而是去要组织架构图、安全政策文档、应用架构图、事件报告、待实施增强清单——这些看起来像行政流程的东西恰恰是整个审计链条里最不能跳过的一环。原因很直接SAP 是一个把业务流程和权限控制深度耦合的系统一个公司代码对应一个法人实体一个采购组织对应一条供应链一个工厂对应一个物理地点。你如果不先搞清楚这些组织单元怎么划分、谁对谁负责后面看任何一张表、任何一个权限对象都会失去参照系。换句话说审计 SAP 的第一步不是“查系统”而是“查组织”因为系统里的每一行配置都是组织意图的投影。这也是为什么审计程序把“获取公司组织架构图”放在第一条——它决定了后面所有技术检查的边界和优先级。2. 组织单元与配置表SAP 审计的底层数据模型是怎么映射业务的2.1 从 T000 到 T001客户端与公司代码的层级关系SAP 审计程序里有一组非常具体的表清单比如 T000 存客户端、T001 存公司代码、T042G 存集团、TGSB 和 TGSBT 存业务领域、T014 和 T014T 存信用控制范围、T004 和 T004T 存会计科目表、T001W 和 TVKWZ 存工厂、T001L 存存储地点、T024W 存采购组织、T024 存采购组、TVKO 和 TVKOT 存销售组织、TVTW 和 TVTWT 存分销渠道、TSPA 和 TSPAT 存产品组、TVTA 存销售区域、TVBUR 和 TVKBT 存销售办公室、TVKGR 和 TVBVK 存销售组。这些表名不是随便列的它们构成了 SAP 组织架构的骨架。审计员拿到这些表的数据实际上是在还原一个企业的业务拓扑哪些公司代码在同一个客户端下运行、哪些工厂属于同一个采购组织、哪些销售组织覆盖了哪些分销渠道。这个拓扑决定了权限设计的粒度——比如一个采购组只能看到自己负责的采购组织下的采购订单一个销售办公室只能访问自己所属销售区域内的客户主数据。如果这些表的数据和实际业务不符比如某个工厂被错误地挂到了另一个采购组织下那么基于这个错误配置建立的所有权限控制都会失效。常见的实现思路是审计员会先用 SE16 或 SE17 把这些表导出来然后和业务部门提供的组织架构图做交叉比对重点看有没有“表里有但图上没有”或者“图上有但表里没有”的实体。这种差异往往就是配置漂移或者权限越界的信号。2.2 权限对象与角色SAP 授权机制的核心逻辑SAP 的权限控制不是简单的“用户-菜单”映射而是通过权限对象、权限字段、活动值三层结构来实现的。一个权限对象比如 M_BEST_BSA 控制采购订单的创建它包含字段如 ACTVT活动比如 01 创建、02 修改、03 显示、BSART订单类型、WERKS工厂。一个角色把若干权限对象组合起来分配给用户。审计员要检查的是这个角色的权限字段值是不是过宽比如一个采购员角色如果给了 WERKS *那就意味着他可以在所有工厂下创建采购订单这显然违反了最小权限原则。更隐蔽的问题是“权限对象之间的组合爆炸”——SAP 允许通过参数文件生成器Profile Generator自动生成角色但如果组织级别字段没有正确限制自动生成的角色可能包含大量冗余权限。审计程序里提到的“评估 SAP 整体安全架构”和“确定矩阵是否用于定义岗位职能和职责分离”本质上就是在检查这个权限模型有没有被正确落地。一个常见的翻车场景是某公司为了赶上线进度直接给所有财务用户分配了 SAP_ALL 参数文件然后打算“后面再细化”。结果三年过去了这个参数文件还在审计员一查发现一个应付会计能过账总账、能修改供应商主数据、还能跑薪资报表。这种问题不是技术漏洞而是权限治理的缺失但它的根因往往可以追溯到组织架构和职责分离设计阶段就没有做好。2.3 定制开发与接口审计范围如何被 ABAP 程序改变SAP 审计程序里有一条很关键确定正在进行的 ABAP/4 程序和数据录入屏幕的定制编程程度。为什么这条重要因为标准 SAP 的权限控制是经过验证的但一旦你写了自定义 ABAP 程序就可能绕过标准权限检查。比如一个自定义的报表程序如果用了AUTHORITY-CHECK语句但写错了权限对象或者干脆没写那么任何能执行这个程序的用户都能看到本不该看到的数据。更常见的是自定义数据录入屏幕——它们可能直接写数据库表跳过了 SAP 的更新任务和权限校验逻辑。审计员需要拿到所有自定义程序的清单然后重点看那些涉及敏感操作比如修改财务凭证、读取客户主数据、调用外部接口的程序。常见的实现思路是用 SE38 或 SE80 搜索 Z 开头和 Y 开头的程序然后结合代码扫描工具检查有没有缺失的权限检查。接口方面SAP 和外部系统的数据交换通常通过 RFC、IDoc、BAPI 或者文件接口实现。审计员要确认这些接口有没有做认证、有没有做数据校验、有没有记录日志。一个典型的踩坑案例是某公司用 RFC 把 SAP 的客户主数据同步到 CRM 系统但 RFC 目标系统配置里用了默认的 SAP 用户和密码而且这个用户有 SAP_ALL 权限。结果任何能访问 CRM 服务器的人都能通过 RFC 调用 SAP 的 BAPI 修改客户数据。这种问题在审计程序里对应的是“确定与生产系统的接口”和“评估中间件连接的安全性”。3. 操作系统与数据库层为什么 SAP 审计必须穿透到 Unix 和 Oracle3.1 SAPMSOS0 与 Unix 命令提示符一个程序如何打开后门SAP 审计程序第五章第一条就点了一个非常具体的程序SAPMSOS0。这个程序可以通过事务 SM52 运行它的作用是访问 Unix 命令提示符。换句话说任何能执行这个程序的用户实际上就拿到了操作系统的 shell。审计员要做的第一件事就是确定谁有权限执行 SAPMSOS0。在标准 SAP 里这个程序通常只应该给系统管理员或者 Basis 团队但实际环境中经常发现它被分配给了开发人员甚至业务用户原因往往是“为了方便排查问题”。更危险的是如果这个程序被分配给了权限过宽的角色而该角色又通过 RFC 暴露给了外部系统那么攻击者就可以从外部系统一路穿透到操作系统。审计程序里还提到要检查/usr/sap目录的读写权限特别是/usr/sap/trans下的子目录buffer 存待导入的传输请求、cofiles 存传输请求信息、sapnames 存传输请求状态、tmp 存临时数据、log 存本地系统日志、work 存运行时数据。这些目录如果对非 SAP 管理员可写攻击者就可以篡改传输请求把恶意代码从开发系统一路传到生产系统。常见的实现思路是审计员会先跑cat /etc/passwd和cat /etc/group看有哪些系统用户和组然后检查/etc/inittab有没有做完整性校验比如每天跑一次 sum 命令再检查/etc/hosts.equiv和.rhost有没有配置信任关系最后用find / -name root -perm -4000 -print和find / -name root -perm -2000 -print找出所有 suid 和 sgid 程序用 sum 和 diff 做每日比对。这套流程的核心逻辑是SAP 的安全边界不止在 SAP 本身操作系统层的任何松动都会让 SAP 的权限控制形同虚设。3.2 Oracle 的 INIT.ORA 与审计开关数据库层审计的起点SAP 审计程序第七章专门针对 Oracle DBMS。第一条就是确定 DBA 职责有没有分离——这听起来像管理问题但它的技术后果很直接如果一个 DBA 既能修改数据又能修改审计日志那么审计日志就失去了证据价值。接下来要拿到 INIT.ORA 文件检查AUDIT_TRAIL参数有没有设为 TRUE。这个参数控制 Oracle 的审计功能是否开启。如果没开那么所有数据库层的操作都不会被记录审计员只能看到 SAP 应用层的日志而应用层日志是可以被有权限的用户删除或篡改的。审计程序还要求拿到 DBA_OBJECTS、DBA_TAB_COLUMNS、DBA_USERS、DBA_VIEWS 这些数据字典视图以及 DBA_TAB_GRANTS 和 DBA_COL_GRANTS 来检查对象权限。重点看WITH GRANT OPTION有没有被滥用——如果一个普通用户拿到了某个表的 WITH GRANT OPTION他就可以把这个表的访问权限转授给其他人从而绕过 DBA 的权限管理。还有一个经常被忽略的点默认用户和密码。审计程序明确列出了 SYS、SYSTEM、SCOTT、SAPR3 这几个默认账户要求确认它们的默认密码已经被修改。在实际环境中SAPR3 这个账户的密码经常被设成和用户名一样因为它通常被用来做数据库连接池的认证改了密码就要改配置很多人嫌麻烦就不改。但这就意味着任何知道 SAPR3 密码的人都能直接连到数据库绕过 SAP 应用层的所有权限检查。审计员还会检查OSOPER角色有没有分配给无效用户以及Public角色的权限有没有被严格限制——Oracle 的 Public 角色默认给所有用户如果它被授予了敏感权限那就等于所有用户都有了这个权限。3.3 NT 与 Unix 的权限模型差异审计程序为什么要分开写SAP 审计程序把 Unix 和 NT 的审查分开写这不是凑字数而是因为两个操作系统的权限模型有本质差异。Unix 用 uid/gid、文件权限位rwx、suid/sgid 来控制访问审计员可以用find和sum做精确的完整性比对。NTWindows用用户账户、组、域、访问控制列表ACL来控制审计员要检查 Administrators 组的成员、默认账户规则、密码策略、域和工作组的划分、用户组和 Power User 组的成员、Guest 组的权限、登录脚本、屏幕保护密码、设备安全设置、目录复制、事件审计策略。NT 审计里有一条特别值得注意检查启动应用程序确保只有授权应用被访问。这是因为 Windows 的启动文件夹和注册表 Run 键经常被恶意软件利用如果审计员不检查攻击者就可以通过一个看似正常的启动项来执行未授权程序。Unix 审计里对应的是检查/etc/services和/etc/inetd.conf确保没有不安全的服务在运行。两个系统的审计逻辑是一样的——确认只有授权的主体能访问授权的客体但实现手段和检查点完全不同。审计员如果只懂 Unix 不懂 NT或者反过来就会在另一个平台上留下盲区。4. 避坑与排查SAP 审计中最容易翻车的五个场景4.1 只查 SAP 层不查操作系统结果被一个 suid 程序打穿现象审计报告说 SAP 权限配置符合最小权限原则但渗透测试时攻击者通过一个 suid 程序拿到了 root shell然后直接读走了 Oracle 的数据文件。原因审计员只检查了 SAP 的角色和权限对象没有跑find / -perm -4000去查 suid 程序也没有检查/usr/sap/trans目录的写权限。解决每次审计必须包含操作系统层的 suid/sgid 扫描和关键目录权限检查并且用 sum 和 diff 做每日基线比对。4.2 默认密码没改SAPR3 成了万能钥匙现象SAP 应用层权限看起来很严但有人用 SAPR3 账户直接连数据库绕过了所有 SAP 权限检查。原因SAPR3 是 SAP 安装时创建的默认数据库用户很多管理员为了省事不改密码或者改了之后没有同步更新连接池配置。解决审计时必须检查所有默认账户的密码状态包括 SYS、SYSTEM、SCOTT、SAPR3并且确认密码策略强制要求定期更换。4.3 自定义 ABAP 程序缺少 AUTHORITY-CHECK权限控制形同虚设现象标准事务码的权限控制没问题但用户通过一个自定义报表看到了全公司的薪资数据。原因开发人员在写自定义 ABAP 程序时没有加AUTHORITY-CHECK语句或者加错了权限对象。解决审计时要拿到所有 Z 开头和 Y 开头的程序清单用代码扫描工具检查权限检查语句重点看涉及敏感数据读取的程序。4.4 审计日志没开出了事查不到是谁干的现象发现数据被篡改但查遍 SAP 日志和数据库日志都找不到操作记录。原因Oracle 的AUDIT_TRAIL参数没设为 TRUE或者 SAP 的审计日志SM19/SM20没有激活。解决审计时必须检查INIT.ORA里的AUDIT_TRAIL设置以及 SAP 的审计配置确保关键操作比如修改财务凭证、修改权限、执行 SAPMSOS0都被记录。4.5 接口认证用默认账户外部系统成了跳板现象SAP 本身权限没问题但攻击者通过 CRM 系统的 RFC 连接调用了 SAP 的 BAPI修改了客户主数据。原因RFC 目标系统配置里用了默认的 SAP 用户和密码而且这个用户权限过大。解决审计时要检查所有 RFC 目标系统的认证配置确认没有使用默认账户并且每个接口用户都遵循最小权限原则。5. 审计程序的设计取舍为什么它不直接给你一个自动化脚本SAP 审计程序从头到尾没有给你一个可以一键运行的脚本而是列了八章、上百条检查项从组织架构图要到 Oracle 的INIT.ORA从 Unix 的 suid 扫描要到 NT 的域用户映射。这种设计看起来很低效但它背后有一个很现实的取舍SAP 环境的高度定制化决定了没有一套通用的自动化脚本能覆盖所有场景。一个公司可能只上了 FI 和 CO 模块另一个公司上了 FI、CO、MM、SD、PP、QM、PM、HR 全套两者的审计范围完全不同。一个公司可能把所有系统都放在一个客户端下另一个公司有几十个客户端分布在不同的地理区域审计的复杂度差了一个数量级。审计程序选择用“检查项清单”而不是“自动化工具”的形式是为了让审计员根据实际情况判断每一条是否适用、适用到什么程度。比如“确定运行的客户端数量”这一条在一个只有单一客户端的公司里可能只需要看一眼 T000 表但在一个多客户端的集团里就需要检查每个客户端的配置差异、权限差异、传输路径差异。这种判断力是脚本给不了的。另一个取舍是审计程序把大量篇幅放在了“获取文档”和“访谈”上而不是纯技术检查。这是因为 SAP 的很多控制是流程控制不是技术控制。比如“确定是否进行了适当的培训”这一条你没法用代码检查一个用户有没有真正理解他的权限边界你只能看培训记录、访谈用户、观察操作行为。技术检查能发现配置错误但发现不了“配置正确但执行走样”的问题。我一般会这么理解这份审计程序的价值不在于它列了多少条而在于它强迫审计员在动手查表之前先把业务背景、组织架构、流程设计、技术架构这四个层面都过一遍。从那以后我每次做 SAP 审计都会先把组织架构图和 T000/T001 的数据对一遍再去看权限角色最后才碰操作系统和数据库。这个顺序不能反反了就会陷入“查了一堆表但不知道这些表代表什么业务含义”的困境。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
