前阵子陪客户做年度IT合规审计的准备工作审计老师翻了半天系统后问了一个很直白的问题“你们SAP里的Support User都是怎么用的谁在哪个时间通过哪个客户端登录进来做了什么审批和回收记录在哪里”当时我们这套系统部署在云主机上顾问团队横跨好几个项目组还有外部实施商远程接入。Support User的申请、使用、停用链路基本靠群聊通知现场一下子就安静了。从那天起我开始认真研究SAP Support User Request Log这套思路也把它落地成了审计真正能“点头”的日志机制。这篇文章就把这段经验完整拆开聊一聊为什么需要它、日志模型怎么设计、标准审计和自定义补充怎么配合以及上云之后会踩到哪些坑。1. 先搞清楚为什么要为 Support User 单独建一份请求日志1.1 所谓的“Support User”到底指哪些人SAP系统里的用户不止我们日常登录用的Dialog用户。按用户类型来分有Dialog、System、Communication、Service还有Reference类别。其中Service用户就是典型的Support User它通常用于外部支持顾问、内部运维团队做配置、传输和排障。云环境下情况更复杂S/4HANA Cloud的扩展租户里经常出现临时授权给SAP官方支持工程师的访问用户这种用户往往生命周期短、权限大偏偏最容易被忽略。很多企业还有一个“共用支持账号”的习惯运维组五个人共用一个SAP_ALL权限账号谁需要谁登录登录密码在内部共享文档里。这种账号哪怕在技术上没问题审计视角下就是重大缺陷。我并不是说这种习惯一定出事而是当审计老师询问“这个账号的请求记录在哪”时你根本拿不出一份能自洽的说明文档问题就变成合规缺陷了。所以Support User Request Log这个机制的核心不是要求你禁止使用Support User而是要求每个Support User从申请到注销全生命周期都有据可查。这个“有据可查”分为两个层面第一是行政层面谁在哪个工单里申请了账号直属负责人是谁使用周期多长第二是技术层面系统里记录了哪些会话、哪些关键操作、哪些权限变更。行政记录靠流程技术记录靠系统两面对得上审计才算闭环。1.2 审计场景里最让人头疼的四个问题我复盘了这几年帮客户整理SAP审计材料时的高频问题基本固定在四类。典型问题审计隐患常见根因几个人共用一个Support账号无法定位具体责任人操作无法追溯账号预算少或申请流程太慢临时授权账号过期后仍在用权限超出授权周期越权访问资产没有定时复核机制账号未被回收支持顾问远程接入无人知晓生产系统被外部人员操作无感知未接入审计日志也未开启登录通知只保存了登录记录没记录操作内容出问题时无法还原操作路径只靠标准对话日志未做补充日志每一个问题背后其实都是“请求日志缺失”或者“日志链路断裂”。举个例子外部顾问在一个月前被要求在测试机做一轮紧急处理当时远程连接进来跑了三个事务码。如果系统里只开了登录日志你只能看到他登录和退出中间那三个事务码做了什么都没留痕。而如果开启了安全审计日志并把关键对象纳入审计策略就能还原他在哪个事务码里改了什么字段、从哪个屏幕执行了什么功能。审计并不是要找谁“背锅”而是要确认“能不能还原”。Support User Request Log把还原能力补上了审计工作自然就好配合。1.3 “请求日志”和“系统日志”不是一回事刚接触这个话题的朋友容易混淆三样东西。第一是应用日志用SLG0/SLG1管理记录的是应用程序运行过程中产生的错误和警告比如某个业务程序报错、接口同步失败第二是安全审计日志用SM19配置、SM20查看它更像是系统级监控记录用户登录、事务启动、RFC调用、表访问等敏感动作第三是这里说的Support User Request Log它更像一种业务审计档案强调的是“支持用户请求”这条业务链。我习惯打个比方应用日志像是电梯的故障报警电梯坏了它才响安全审计日志像是楼道里的摄像头一直在录Support User Request Log则像是访客登记本每个访客进来要登记、离开要销账。这三个内容各管一段缺了哪一个都做不到完整的审计闭环。所以在设计阶段就要想清楚Support User Request Log不是单纯把SM20日志导出到Excel就完了它需要包含账号申请、授权变更、登录会话、回收注销这些环节的统一视图。这也是为什么我们要单独做一套日志表和管理报表而不是在标准审计日志里翻查找零散记录。2. 设计一套审计友好的日志模型从需求到表结构2.1 先画圈哪些操作必须进日志开始设计之前我建议先列一份“观察清单”把Support User涉及的敏感行为一条条列出来再决定日志策略。不需要把系统的每个动作都记录下来记录得越多存储越大查询越慢审计老师也不会因为数据量大就认为更安全。参考我的实践以下操作至少需要落在日志体系里Support User账号的主数据变更创建、调整角色、加解锁、密码重置、失效日期变更账号生命周期事件申请、审批通过、账号激活、账号过期、提前回收登录与会话事件登录成功、登录失败、会话空闲超时、断开连接敏感事务码调用例如直接操作表数据的事务码SE16N、调试事务码SE37/SE80、后台作业管理SM36/SM37、传输管理STMS远程连接相关RFC目的地创建与变更、外部系统登录目标调用客户端配置相关SCC4里的客户端属性调整、后台作业跨客户端执行生产数据访问当Support User在工作台中使用SA38直接执行报表、用SE16N查看生产表内容等这一步画完圈之后很多决策就顺了。以“查询生产数据”为例如果支持顾问日常有合理需求要查一张配置表你不一定完全禁止但可以让查询动作本身进入日志。一旦审计要求说明“两周前谁用SE16N查看过SBOOK表”你直接交出一条带时间戳的记录简洁有力。我记得在某个项目上还遇到过一种情况支持顾问通过一个远程函数调用接口做数据校验这个RFC调用在应用端没有留下任何业务记录只靠系统底层日志又查不到业务着落点。后来我们把这个RFC调用目的地纳入Support User日志的监控范围每次调用自动在日志表里追加一条“调用方、被调程序、传入参数摘要、返回码”三个月后排查问题时特别管用。2.2 表结构怎么设计自定义日志表是整套机制的落地基础。我通常会用透明表存业务记录并尽量让表结构对ABAP开发者友好因为后面还要写查询报表。我们项目里用的核心表叫ZSUPLOG_TRACE字段大致如下字段类型用途说明MANDTCLNT客户端保留分组维度LOGIDCHAR32日志唯一编号USERNAMECHAR12Support User的账号REF_NAMECHAR40申请人、审批人或操作对象名称REQ_TYPECHAR4请求类型CREATE/MODIFY/GRANT/REVOKE/LOGON等ACTION_TCCHAR20关联事务码如SU01、SE16N、STMSOBJ_NAMECHAR60操作对象如角色、表名、程序名BEG_TIMEDEC15开始时间戳UTC时间END_TIMEDEC15结束时间戳UTC时间IP_ADDRCHAR20来源IP或云主机出口IPSESSION_IDCHAR30会话ID方便关联前后动作STATUSCHAR1成功、失败、超时、拒绝CHG_TEXTCHAR255简要说明记录变更前后摘要CREATED_BYCHAR12日志写入程序标识设计的时候我始终坚持两个原则第一个原则是不在日志表里存业务大文本只存“摘要”。真正的详细内容可以放独立明细表或者直接引用安全审计日志记录编号这样每年归档的时候不会让主表膨胀过快第二个原则是每条记录都带UTC时间戳夹杂时区信息因为跨团队协作时本地时间和服务器时间经常对不上审计举证最怕因为时区问题被挑战。如果不想做重开发也有轻量替代方案利用标准日志表USH02用户主数据历史表查询用户变更历史再用USR41当前活动会话表和SM20日志组合。但这种方案胜在快速上线缺点也明显它没有一个业务化视图审计人员查起来不够直观。所以正式体系还是建议用自定义日志表标准表作为兜底。为了让日志表始终有底可查我还会同时启用标准的表日志功能Table Logging。比如RZ04这样的实例参数表、SCC4客户端表、权限相关表即使不做自定义写入也会被标准日志记录下来。Table Logging的开关用SE03配置选择需要监控的表这样即使有人直接改表数据也会留下痕迹。2.3 从审计举证角度反推字段这里分享一个比较“反常识”的设计技巧不要先想“系统里有什么字段”而是想象审计老师下个季度会问哪三个问题。最常被问的通常是“请说明过去90天内Support User账号的申请和使用情况”“这个顾问为什么在生产系统执行了传输导入”“某个已离职顾问的账号为什么还在活动会话列表里”。你会发现回答这些问题需要的数据维度正好对应工程上常用的“生命周期、动作、对象、时间、人”。所以我最终把日志模型定义成“五个W”Who谁操作、When时间范围、Where客户端、IP、云主机区域、What事务码、对象、字段前值后值、Why关联工单号、申请单号、备注。日志表里多放一个工单号字段实际配合审计时价值非常高因为能从业务侧解释技术动作的来龙去脉。有些项目为了省事不做这个字段后面审计问“你为什么授权这个账号”时技术日志回答不了还得回去翻工单系统一来一回至少多花两周时间。3. 实操从开启标准审计到落地自定义请求日志3.1 标准审计配置SM19 和 SM20标准审计日志是绕不开的底座哪怕你开发了再漂亮的自定义日志表底层的登录和事务控制事件依然由安全审计负责。SAP里用SM19做审计配置SM20查看审计日志。SM19配置时可以在“静态审计级别”里选择“无审计”“低级别”“中级别”“高级别”等档位也可以针对特定用户和事件进行细节勾选。我建议至少开启“登录/注销”“事务启动”“RFC调用”“用户主数据变更”“权限检查失败”这几类事件。有几个关键参数在这里提一下rsau/enable总开关设为1后审计功能生效rsau/max_entries缓存日志记录条数上限超过之后会触发写入数据库或滚动覆盖需根据系统负载合理设置rsau/security/audit_policy云版本或较高版本里的策略化配置实际操作时也要注意性能问题。如果所有用户所有事务都开启高级审计生产系统会变得非常卡日志表膨胀也快。合理做法是采用“白名单用户”方式只对Support User这个账号组开启高等级审计。我记得有个客户一开始全库开启审计数据库增长量每天好几个G后来改成按账号组筛选存储压力立刻降下来了该审计的内容一条都没少。SM20里面可以按时间、用户、事件类型筛选日志结果可以导出为HTML或TXT存档。但它毕竟不是给业务审计用的系统筛选功能有限所以我们要在其之上再搭一层自定义查询。正确关系是SM20管原始事件自定义报表管业务视图。3.2 通过增强实现 Support User 请求日志的自动落库自定义日志表不能只靠ABAP程序员手动往里插数据必须挂到业务事件上自动落库。我实践中最常用的落库时机有三个用户主数据变更时、登录成功时、执行事务码时。用户主数据变更通常挂用户维护的BAdI或增强点。一旦SU01有人修改了Support User的角色、有效期、密码状态自动读取出变更前后的内容写入ZSUPLOG_TRACE。这个环节要特别注意“谁在改”要用SAP系统用户字段读出实际操作者别用语法里硬编码的当前登录账号因为后台批量变更时容易错位。登录事件落库有两个选择一个是靠标准审计日志读出来再同步另一个是在登录增强点里写自定义记录。前者实现简单但需要定期抽取同步后者实时性好可要小心登录并发场景下的性能损耗。如果系统有多个应用服务器还要记得写日志时的数据一致性处理不能各自本地文件里打点最后汇总困难。事务码启动事件的记录比较微妙。理想情况是想知道Support User进入SE16N后做了哪些操作但标准机制很难覆盖“进入事务码之后的每一个点击”。我的妥协方案是在事务码启动时记录一次再配合系统级TABLE LOGGING记录具体数据变更。实践下来发现审计真正关心的是“是否有人进入敏感事务码操作”对屏幕内每个点击并没有那么强的举证需求。如果团队里有ABAP开发资源推荐用类CL_CLIENT_TRACE或自带日志框架这样生成的记录格式统一、带包名后期做增强接口也方便。没有开发资源时最低成本方案是做成一个“每日自动抓取审计日志写入自定义表的后台作业”但实时性会差一天紧急排查时不够顺手。3.3 云环境的考量SAP BTP 与 S/4HANA Cloud上云之后很多经典GUI里的操作路径发生了变化这是最容易被老顾问忽视的地方。在S/4HANA Cloud环境里系统本身没有传统意义上的后台配置权限Support User的授权通常通过“维护临时访问”流程发起。SAP支持工程师发起请求后客户侧用户在工作台右下角的待办审批里批准系统再自动生成凭证和访问窗口。这个过程中的请求日志确实会生成但很多企业根本不知道去哪个菜单查看或者不知道怎么导出给审计人员。BTP环境下更要注意Audit Log Service是平台侧提供的日志能力通过API可以导出租户内的用户登录、服务绑定、权限变更等记录。如果你的Support User出于扩展应用运维需要访问BTP子账户记得提前接通这个服务的API否则云厂商只会保留有限时间的日志超过后便无法追溯。跟经典地部署系统相比云端的日志策略更像“推责任到平台”。我的经验是不要指望一套日志走天下一定要分清楚平台层日志靠云服务商应用层日志靠SAP系统业务层日志靠业务工单系统。三层之间的时间戳和对象ID统一对应审计时才不会出现SAP系统显示有登录但云平台日志里找不到对应会话的尴尬情况。这里也提醒一句上云前把SAP GUI的版本整理清楚。很多后补的Support User排查还要靠GUI连接系统查看SM20和AL08新版的操作习惯跟老版本差异不小。不要等到出问题时才发现运维手里连一个可用的SAP GUI 760安装包都没有那就真被动了。4. 日志的查询、归档与审计配合4.1 做一个审计查询报表自定义日志表建好数据也写入接下来要能给审计老师一个友好入口。我不建议直接丢一张数据库表让审计人员自己掏SQL毕竟大多数审计人员不熟悉SAP表结构。我习惯用SE38写一个简单的报表在界面上提供日期范围、账号、请求类型等选择条件查询结果用ALV输出。再通过SE93挂一个事务码比如ZSUPLOG授权给需要查日志的合规或审计角色。这种做法开发量不大但使用体验比每次都找ABAPer帮忙导出SQL结果集要强太多。核心逻辑非常简单写好查询条件后直接SELECT对应字段最后调用REUSE_ALV_GRID_DISPLAY输出。如果现场环境已经启用了Fiori可以再基于CDS视图做一个图表展示版但前期不需要追求这种复杂度。先把“能查、能筛、能导出”这三件事做扎实。报表名称和事务码的权限也需要管控。审计查询用的账号只开放给特定角色不能给运维组同一套权限否则“能写日志的人还能改日志视图”就变得没有说服力。关于权限划分我在第5节会专门展开。4.2 归档策略与保留期限日志表如果不归档数据膨胀只是时间问题。生产系统上Support User数量通常不多但事务启动记录和登录记录可能每天产生成百上千条。加上云环境的Report Log和审计API数据三个月不处理查询报表就会明显变慢。关于保留期限我参考过多家金融机构和制造企业的做法最低保留两年常见要求是三到五年。实际操作中我们按年度归档把上一自然年的数据从活动表迁移到归档表或者直接导出为可检索的离线文件。系统表ZSUPLOG_ARCH保留同样结构只是加了一个唯一索引避免覆盖。归档作业用SM36做成每月自动执行后台作业成功与否还要留TBTCO日志这样归档动作本身也可审计。云环境的日志保留不太一样。S/4HANA Cloud标准日志在系统侧保留时间有限建议定期通过API把审计数据同步到自建对象存储中保存周期按企业合规策略执行不要依赖云厂商的默认周期。发生过不止一次“客户以为云端会自动留三年日志结果六个月后想导出就发现已经滚动清除”的教训。4.3 审计时怎么快速配合给出举证链等到真审计的时候Support User Request Log的角色是提供一条完整举证链。需要准备的材料通常包括当前所有Support User的清单账号、负责人、开通日期、过期日期近一个审计周期内的申请审批记录工单号、申请人、审批人、授权期限登录会话记录时间、IP地址、来源客户端、登录类型敏感操作记录事务码、对象、变更前后值、结果代码账号回收记录停用时间、最后一个会话时间、回收确认人我们准备审计材料时有一份“快速应答模板”审计问账号相关问题时按固定的四层逻辑回答业务侧这账号是为什么开、技术侧这账号有哪些权限、实际使用情况有哪些会话和操作记录、当前状态是否还在有效期。这套模板用起来以后审计配合效率提高很多基本不需要临时翻系统找数据。比较容易被问到的还有“日志是否有被篡改的风险”。严谨回答方式是说明底层安全审计日志由系统SAU机制生成自定义日志表只允许特定写入程序插入业务侧查询角色只有读取权限没有修改删除权限。如果合规要求特别高可以定期把日志表的哈希摘要异机保存需要时再做一致性校验。5. 常见问题与排查记录5.1 Support User 已停用但仍提示活动会话这是运维中频率最高的一个“假警报”。账号明明已经在SU01里锁定或设置过期但SM04或AL08仍然能看到该用户的会话。原因多半是这个会话是在账号停用之前建立的SAP不会因为账号被锁就把已经建立的连接踢下线。处理方法是记录会话ID后在SM04中手动结束该会话或者执行系统级AL08的Delete Session操作。这类情况在云系统远程访问时更容易出现。远程桌面断开并不等于SAP会话结束经常有顾问关掉笔记本系统里还挂着两三个僵尸会话。我在运维规范里会加一条Support User每次远程工作结束必须主动用“/NEX”退出SAP不直接点右上角关闭窗口。看似很小的习惯却能从源头减少大量无效活动会话记录。5.2 日志表无限膨胀怎么控制前面提过日志表按时间归档是正路但还有两个容易被忽略的细节。第一个是不要在日志表上建过多索引尤其是不要给每个文本字段都建索引写入性能会下降存储也会额外膨胀第二个是定期做表重组SAP应用服务器上可以用SM14维护表历史也可以让数据库管理员配合做分区表迁移。如果日志表本身设计合理正常Support User规模的系统一个月增量不会太大。某个客户曾因为把“所有访问逻辑的所有表”都加入Table Logging日志表每天增长超过4G数据库磁盘直接报警。后来回退到只保留敏感权限相关表和自定义日志表数据量下降了90%以上审计要求也没受到影响。这里给的排查建议是做日志机制调整后至少观察两个完整业务周期用SM20和数据库表的空间辅助信息对比增量曲线。如果发现某类事件数量极不正常优先在日志写入端加过滤条件而不是扩容数据库硬扛。5.3 审计日志和传输日志STMS混在一起的问题STMS是传输控制系统很多运维人员在排查问题时习惯把“谁用STMS导入了什么请求”也当成审计日志的内容。这两者必须分开。STMS日志关注的是传输请求号、目标系统、导入队列和返回状态它可以帮助还原一次变更部署的全过程安全审计日志关注的是用户动作本身比如谁启动了事务码STMS从哪个客户端进入。互补关系最合理的用法是先看安全审计日志确认有用户启动了STMS再进STMS传输目录查看具体导入的请求号和时间最后去请求文档里找到对应的业务变更单。这样一条线串下来从“什么人”到“干什么事”再到“为什么干”就全链路闭环了。如果只看STMS你只能知道传输发生了不能有效证明是哪个人触发的。5.4 权限控制审计员该看什么运维不该能改日志最后这块是我这次最想强调的。Support User日志机制做得再好如果权限管控不严日志本身的公信力就是零。审计查询角色只能授权给合规、内审或指定的安全管理员。这些账号拥有对ZSUPLOG_TRACE的读取权限、对报表事务码的执行权限但不拥有对表结构的修改权限也不能访问SU01去修改Support User本身。运维组保留账号操作权限但不能看到审计查询事务码系统管理员拥有比较高权限不过操作日志写入程序时要保留清晰ABAP审计痕迹。比较严谨的做法是给敏感表加“写保护”。通过SAP权限对象S_TABU_DIS控制特定用户组对自定义日志表的写操作。就算有高权限账号误入SE16N想修改ZSUPLOG_TRACE系统侧也会拦截并触发安全审计事件。这个防护层级虽然不是绝对无法绕过但已经足够让审计老师理解“日志是可信数据源”。行动上也建议运维人员不要常年保留SAP_ALL“临时使用”。哪怕为了方便安装了SAP GUI 760日常做排查也尽量用最小权限账号登录真正需要高权限操作时再临时申请Support User并全程留痕用完之后立即回收。这样“Support User有日志”和“普通用户最小权限”就是两套互相咬合的安全机制审计逻辑也能自洽。我在实际项目里最大的体会是Support User Request Log不是一锤子买卖不要等审计前突击搭。哪怕刚开始只记录Support User的登录和账号变更也比什么都不记好得多。随着系统规模变大还可以把MOM与SAP接口的调用记录、CPI中间件的流转日志一起吸纳进来形成一个更完整的审计视图。做这个机制时也别太纠结“一步到位”先把数据源头堵住后面补工具、补报表永远来得及。但如果源头都没有后面再强的分析能力也只能对着空表叹气。