资讯详情

资讯详情

SAP审计程序实战:权限日志、ABAP实现与配置避坑指南

简介SAP系统审计程序参考文档面向IT审计师、内控合规人员及SAP运维管理者用于系统安全、合规与风险控制的结构化检查。资源为单份doc格式Word文档压缩包仅112KB清单式编排便于打印或导入审计底稿目前在CSDN已有410人学习。文档以审计程序清单形式覆盖完整流程从前期资料收集组织架构图、安全策略、架构图、问题跟踪报告、SLA、备份与灾难恢复计划等到确认SAP版本、模块、接口与客户端数量再到核查公司代码、业务范围、信贷控制区、工厂、采购组织、销售组织等核心对象并附T001、T024、TVKO等常用表名供系统查询同时延伸至整体安全架构评价及设计与实施阶段的控制评估。可帮助审计人员快速搭建全面审计框架按图索骥识别关键风险点也可依据企业实际裁剪形成自有SAP审计程序模板。1. SAP系统审计程序到底是什么从一场失败的内审说起SAP系统审计程序说穿了就是把SAP系统里留下的安全日志、权限数据和变更记录整理成审计证据的一套做法。曾有一家企业做年度IT审计内审组要查“上季度有没有人绕过物料主数据审批改价格”结果标准日志只能证明有人登录过却证明不了谁改了什么字段再导出全量高风险权限账号光核对就花了三天最后审计意见只能写“无法证实”。这正是SAP系统审计程序要解决的问题它不只告诉你“系统里发生过什么”更要把“谁有敏感权限、谁动过关键数据、权限是否彼此冲突”这些审计问题变成一张能直接进报告的取证表。这篇文章写给三类人给内部审计和合规岗位解决“怎么让SAP系统开口说话”给SAP Basis和安全顾问解决“配置哪些开关审计日志才能用”给ABAP开发人员解决“标准报表不够用时怎么自己写审计程序”。内容从标准配置讲起一路落到代码和参数最后把项目里最容易翻车的几个坑点一次说透。2. SAP审计程序的实现路径选型决定后面累不累2.1 安全审计日志SM19/SM20先确认系统“在记录”SAP自带的“安全审计日志”是审计程序最常用的数据源。它按事件记录系统行为包括用户登录成功/失败、权限检查失败、事务码启动、RFC调用、用户主记录变更等。配置入口是事务码SM19分析入口是SM20/SM20N。很多项目开了日志却查不到东西第一步就要回到这里排查配置。常见做法是在SM19里做“静态审计”配置勾选需要记录的事件保存并激活。操作路径大致如下进入事务码SM19系统会列出审计配置目录。在配置里勾选静态审计事件常见事件有登录成功、登录失败、权限检查失败、事务码启动、程序启动、RFC调用、用户主数据变更。保存配置系统提示该设置只对后续会话生效。进入SM20/SM20N按时间段、用户名、事件类型过滤查看审计日志。这里有一个容易混淆的概念静态审计与动态审计。静态审计在SM19里按事件勾选配置简单但开关一开就是全量记录动态审计通过实例参数控制审计级别粒度更细但要改参数文件并重启实例。生产环境下一般两者结合用静态审计保住关键事件动态审计控制记录的详细程度。安全审计日志的级别参数建议如下表生产环境至少开到3级参数值记录范围适用场景1仅失败的登录尝试低风险环境不推荐2成功与失败的登录内网低敏系统3所有安全相关事件推荐的生产配置4所有可审计事件开发测试系统或合规强管控环境2.2 权限审计与变更审计SUIM、SU53、CDHDR/CDPOS把“谁有权限”和“谁改过数据”钉死权限审计一般从SUIM用户信息系统入手。它按用户、角色、权限对象、事务码等维度提供标准查询比如按权限对象查所有拥有“用户主数据维护”权限的账号。SU53则是另一个实用工具用户被权限拦截后SUIM太宽SU53可以看到最近一次权限检查失败的具体对象和字段值排障时非常有用。数据变更审计依赖变更文档机制记录集中在CDHDR变更头和CDPOS变更明细两张表。CDHDR记录“谁在什么时间通过哪个事务码改了哪个业务对象”CDPOS记录“哪张表的哪个字段旧值是什么、新值是什么”。查询模板大致是这样SELECT ch~username ch~udate ch~utime ch~tcode cp~tabname cp~fname cp~oldvalue cp~newvalue FROM cdhdr AS ch INNER JOIN cdpos AS cp ON cp~changenumber ch~changenumber AND cp~objectclas ch~objectclas AND cp~objectid ch~objectid INTO TABLE gt_changes WHERE ch~udate p_begda AND ch~udate p_endda AND cp~tabname p_tab.这段SQL的逻辑是以变更头表为主表内连接变更明细表条件是变更编号、对象类、对象ID三键对齐再按日期和表名过滤。p_begda和p_endda是审计起止日期p_tab是要追查的业务表名。注意不写日期范围直接查CDPOS在数据量大的系统里就是灾难几亿行的表全表扫描很可能几分钟都出不来结果。我一般建议先跑count确认数据量在可控范围内再执行全量明细查询。另一个必须面对的现实不是所有表都有变更文档。标准业务对象如物料、供应商、客户大多已接入但很多自定义表和增强字段天生不带留痕功能。审计程序再快源头没有记录结果也是空的。2.3 自定义ABAP审计程序标准工具覆盖不到的边角标准工具能回答“谁有某权限”却回答不了“谁同时既有创建用户权限又有分配角色权限”这种组合问题SM20能看单条事件却没法把用户主数据状态和角色分配表关联起来做交叉比对。当审计目标变成“多条件组合、跨表关联、定期跑批取证”时就该写自定义ABAP审计程序了。我一般会先问自己三个问题再决定要不要写代码SUIM加变式导Excel能不能完成SM20导出后在Excel里做透视表能不能完成一条SQL能完成的需求值不值得做成一个永久程序如果答案是“需要反复跑、口径要固定、证据要留痕”才动手写。自定义审计程序的核心价值不是替代标准报表而是把企业自己的审计规则固化下来让每一次跑批结果都使用同一套判定逻辑。3. 手写一个可交付的SAP权限审计程序代码、参数与输出3.1 先把审计规则写成可执行的口径写审计程序的第一步不是打开SE38建报表而是把审计目标翻译成“表字段条件”。以“找出拥有创建用户权限的账号”为例规则是权限对象为S_USER_GRP活动字段ACTVT的授权值为01创建或02变更数据来源是角色用户分配表与角色授权值表同时要排除已锁定账号并考虑角色有效期。把这条规则写成一张需求卡片后续代码就是它的翻译。下面这张表是权限类审计最常见的规则落点可以直接拿来当设计模板审计目标关联表关键字段判定条件谁可以创建用户AGR_USERS、AGR_1251S_USER_GRP / ACTVT授权值含01或02谁可以执行敏感事务码AGR_USERS、AGR_1251S_TCODE / TCD事务码不在白名单谁改过关键表数据CDHDR、CDPOS表名字段名时间窗日期落在审计区间内谁有“建用户授权”组合AGR_USERS、AGR_1251S_USER_GRP S_TCODE同一用户命中多条高风险规则规则卡片确认后再决定查询范围只看角色授权还是也看直接授权给用户的权限对象。后者藏在USR04表里很多初版审计程序都会漏掉它。3.2 可复用的ABAP权限审计代码块授权值全量比对下面这段代码按权限对象筛选用户并输出实际具备目标活动值的授权行。它在SE38里可以直接建报表运行。REPORT zaudit_user_auth_check. TYPES: BEGIN OF ty_result, uname TYPE agr_users-uname, 用户名 role_name TYPE agr_1251-role_name, 角色名 object TYPE agr_1251-object, 权限对象 field TYPE agr_1251-field, 权限字段 sign TYPE agr_1251-sign, I包含 E排除 option TYPE agr_1251-option, EQ等于 BT区间 low TYPE agr_1251-low, 授权低值 high TYPE agr_1251-high, 授权高值 END OF ty_result. DATA: gt_result TYPE TABLE OF ty_result, gs_result TYPE ty_result. PARAMETERS: p_object TYPE agr_1251-object DEFAULT S_USER_GRP, p_field TYPE agr_1251-field DEFAULT ACTVT, p_actvt TYPE agr_1251-low DEFAULT 01. START-OF-SELECTION. SELECT au~uname ar~role_name ar~object ar~field ar~sign ar~option ar~low ar~high FROM agr_users AS au INNER JOIN agr_1251 AS ar ON ar~role_name au~role_name INTO CORRESPONDING FIELDS OF TABLE gt_result WHERE ar~object p_object AND ar~field p_field. IF gt_result IS INITIAL. WRITE: / 未发现该权限对象的授权记录请检查参数. RETURN. ENDIF. SORT gt_result BY uname role_name. LOOP AT gt_result INTO gs_result. 只输出实际具备目标活动值的授权行 IF ( gs_result-sign I ) AND ( ( gs_result-option EQ AND gs_result-low p_actvt ) OR ( gs_result-option BT AND gs_result-low p_actvt AND gs_result-high p_actvt ) ). WRITE: / gs_result-uname, gs_result-role_name, gs_result-object, gs_result-field, gs_result-low, gs_result-high. ENDIF. ENDLOOP.逻辑说明这条程序先把角色的全部授权值行取到内表再在内存里判断是否包含目标活动值。没有直接在SQL的WHERE里写“LOW等于某值”是因为SAP授权值本身带有SIGN和OPTION字段存在包含、排除、区间等多种写法直接拼SQL条件很容易漏掉区间授权和排除授权。把数据取回内存后统一判断规则公开透明出问题时也方便解释。参数说明p_object默认S_USER_GRPp_field默认ACTVTp_actvt为目标活动值。审计“创建用户”时用01审计“修改用户”时用02审计“显示用户”时用03。要查事务码权限时把p_object换成S_TCODEp_field换成TCD。注意输出用的WRITE语句在字段多时可能被截断正式交付建议换成ALV网格输出或导出到本地表格这段代码主要用于验证逻辑。这段代码还有一个边界它输出的是“包含”关系没有做排除权限的最终扣减。若某用户同时存在排除“创建用户”的授权行严格来说最终权限结果是不包含创建用户的。实际项目中我建议先跑完包含行再单独跑排除行两边对照后人工确认等业务确认完再在代码里加入完整的权限计算规则不要一上来就写复杂规则引擎。3.3 审计报表的参数化时间窗口、阈值、输出与留痕一个能交付的审计程序至少要带三类参数。第一是审计期间用起止日期限定数据范围否则每次跑批都是全表扫描第二是风险阈值比如“同一个用户命中两条以上高风险规则才输出”把业务判断变成可调数字第三是输出模式开发期用WRITE看明细交付期用ALV或导出文件。三组参数到位程序才能从“自己能跑”变成“别人也能跑”。更专业一点的做法是给报表增加审计编号参数。每次跑批时输入一个编号报表头部显示编号、查询人、查询日期、筛选条件。这个习惯在外部审计检查时价值极大因为审计证据最怕“说不清这份报告是什么条件下跑出来的”。4. 决定审计程序成败的配置参数日志级别、保留期与变更开关4.1 安全审计日志的三个关键参数审计级别、文件上限、落盘延迟安全审计日志不是配置一次就一劳永逸。实例参数文件里最核心的三个参数是审计级别、审计文件大小上限、日志落盘延迟。它们直接决定日志“有没有、全不全、找得到”。参数名设置位置作用建议值rsau/audit_level实例参数文件审计级别控制记录范围生产3开发测试4rsau/audit_maxsize实例参数文件单个审计文件大小上限超过后切换新文件10到20MBrsau/audit_delay实例参数文件日志从内存落盘的延迟时间默认0或1到2秒审计级别设为1时只记录失败登录系统一旦被多次尝试登录日志里只有错误记录缺少成功会话的上下文。生产我一般直接上3把权限检查失败、事务码启动都纳入。audit_maxsize设太小会导致审计文件频繁切换SM20查询时经常遇到“这段日志怎么读不全”的玄学问题多半是文件切到下一段了设太大会导致单文件读取缓慢10到20MB是比较稳的区间。audit_delay是很多审计项目忽略的点。默认情况下日志即时落盘设了延迟后如果遇到宕机最多会丢延迟时间内的日志。安全要求严格的场景我建议不要设延迟磁盘IO承受不了再调。4.2 变更文档的启用开关不是建了表就自动留痕很多审计需求最后都卡在同一个问题上CDHDR/CDPOS里查不到自定义表的变更记录。原因通常是这些表压根没有接入变更文档机制。标准业务对象如供应商、客户、物料主数据系统默认集成了变更文档自定义表和增强字段要自己接入。常见做法有两种。对标准业务对象先确认表对应的业务配置里变更文档是否激活多数情况是默认开的不需要额外操作。对自定义表在SE11打开表的技术设置勾选“日志数据更改”保存后激活激活后系统会对该表的数据插入、更新、删除做记录。这里提醒一句启用日志数据更改会带来明显的存储开销建议只对真正需要审计的高敏字段或高敏表开启不要全库无差别打开。启用后必须做一次实测找一个测试账号修改一条目标数据然后查CDHDR/CDPOS是否有记录。没有记录就说明没启用成功改完表直接激活往往不够还要看后台表是否有日志存储表生成。这一步验证做完再谈审计程序覆盖度才有意义。4.3 审计数据的保留与归档合规要求与磁盘成本如何平衡安全审计日志有两种形态应用服务器上的审计文件和数据库表。SM20能读到多长的历史取决于文件保留策略和数据库表清理机制。企业SAP审计日志一般保留一年起步金融和上市类企业按各自合规要求留存两到三年。我一般会做一个简单的容量评估统计日均审计事件量单条事件按约200字节估算乘以保留天数得出审计文件的存储预估。比如日均5万条事件保留两年大约占用7GB量级这对现代服务器不算大但加上变更文档和表日志的增长数据库侧的压力要单独看。归档操作上常见做法是通过后台作业定期把审计文件复制到独立归档目录并按月份分文件夹存放在线审计文件则按保留窗口清理。归档前务必确认SM20能直接读取归档后的文件格式否则“存了一堆打不开”等于没存。建议每年做一次归档恢复演练真到审计组要数据时再发现打不开就彻底晚了。5. SAP审计程序避坑五条高频翻车记录5.1 现象SM20里一条登录日志都没有原因通常有三个SM19静态审计事件没保存激活审计级别设成1而系统里没人输错过密码改了参数文件后实例没重启动态审计根本没生效。曾经遇到一个项目安全顾问在参数文件里写了audit_level3但实例大半年没重启一直以为日志开着。解决路径先到SM19检查静态审计事件是否激活再通过RZ11查看当前实例实际生效的audit_level值确认参数是3还是1要让修改生效安排变更窗口重启SAP实例重启后立刻用一个测试账号登录一次回SM20看是否出现对应日志。5.2 现象自定义审计程序与SUIM查询结果对不上最常见的原因是数据来源覆盖不完整。SUIM查询底层考虑了角色授权、直接授权和其他授权来源自己写的程序如果只查AGR_1251就会漏掉用户通过USR04获得的直接权限授权以及复合角色在AGR_1252里的授权。两边结果不一致时绝大多数是漏了数据源不是SUIM算错。解决做法把自定义程序的查询范围扩展到AGR_1252和USR04复杂角色解析别省略同时在程序输出里加上“数据来源”字段区分结果来自角色分配、复合角色还是直接授权。每一次跑批保留数据来源标记后续对账能省一天时间。5.3 现象权限对象授权值明明存在程序却没输出结果一个典型场景用户权限里有一条S_USER_GRP的授权行OPTION是BTLOW为01HIGH为02。程序用“LOW 01”精确过滤这条行能被查出来但如果用“LOW入参”直接等值比较就会漏。更隐蔽的坑是授权行为SIGN等于E排除按包含逻辑输出时这条行被过滤掉程序却没有任何提示。解决做法先按SIGN和OPTION把授权值完整取出内存里做包含与排除的合并计算再输出结论。复杂场景建议先与SUIM逐条核对五到十个样本账号确认程序口径无误后再全量跑批。5.4 现象审计报表里的时间与用户实际操作系统时间差了8小时SAP在后台大量使用UTC时间存储自定义程序直接读CDHDR的UDATE/UTIME字段时输出的是UTC而用户界面显示的是本地时间。审计组拿到报表后按本地时间核对发现时间对不上第一反应就是数据有问题。解决做法在程序里把UTC时间按目标时区做转换同时报表头部明确标注“本报表时间为服务器本地时间UTCX”。最怕的是报表不写时区说明审计证据到了外部就失去效力。SM20标准展示已经处理了时区展示自定义程序必须自己处理。5.5 现象职责分离审计误报“有人既能创建用户又能分配权限”权限继承是这类误报的根源。用户可能通过三个不同角色共同获得两个不相容权限单看每个角色内部都不构成冲突合并到用户维度后冲突才暴露。反过来程序只做了角色级合并但没正确处理排除权限又会出现“实际无冲突却报冲突”的假阳性。解决做法职责分离审计必须按用户维度合并全部授权值生成该用户的“有效权限集合”再拿集合去匹配SoD规则。规则本身也要维护新权限对象上线、角色调整时规则列表要同步更新否则审计程序跑得再准规则错了结论也是错的。6. 审计程序的进阶用法从一次性取证到持续监控6.1 把审计程序挂上后台调度定时跑、对比基线、异常告警一次性审计只能回答问题持续监控才能发现问题。常见做法是把写好的ABAP审计程序挂到SM36后台作业里每月或每周固定跑一次使用变式固定参数输出结果到应用服务器或发送邮件给安全负责人。关键不是“跑”而是跑完之后的对比第一次跑出来的结果与业务确认后把它存成基线后续每次只输出新增和消失的差异审计人员只需要处理差异部分工作量瞬间降下来。我习惯在代码里保留一个“全量模式/增量模式”的开关全量模式用于季度大审增量模式用于月度监控。增量模式的输出要和上次快照做对账否则漏一条差异都是大事。6.2 证据链设计每个报表都自带不可抵赖信息审计报表交付时最忌讳只有一张数据表。报表头部至少要有运行时间、运行账号、程序版本、筛选条件、审计编号。导出文件后建议加一个校验值重要审计项把原始导出文件与校验值一并归档并定期检查归档目录可读性。早年我写审计程序只关心SQL对不对后来一次外部审计问“这份报表的筛选条件是谁定的、跑的时候是哪个版本”我答不上来才意识到审计程序交付的核心是过程可追溯而不只是查询结果。现在凡是我交付的审计报表都会把运行上下文写进输出页并保留一份归档。这个习惯希望帮到你。本文还有配套的精品资源点击获取
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →