企业官网建设流程全解析

这些年帮客户应付了不少内外部的 IT 审计，我越来越有一个感受：大多数 ABAP 顾问对 SAIS 这个事务码的认知，基本停留在“听说过、没打开过”的状态。可真到了审计组拍桌子要证据链的时候，很多人还在用 SE03 翻传输请求、用 SUIM 导用户清单、用 SM20 看安全日志，来回折腾半天，交出来的东西还是零散的，审计人员不认。

别再把 SAIS 当成冷门事务码了。在 ABAP 平台上做审计，SAIS（System Audit Information System，系统审计信息系统）才是真正能把“查配置、查权限、查变更、查操作日志”串成一条线的落地工作台。这篇文章我用自己的项目经历，把 SAIS 的运行机制、配置步骤、高频审计场景和踩坑记录完整过一遍，希望能帮你在下次审计来临前，把主动权抓在自己手里。

1. 从一次突击审计说起：为什么 SAIS 才是 ABAP 平台审计的主入口

1.1 SAIS 是什么：它不是冷门报表，是一整套审计工作台

先纠正一个普遍误解。很多人以为 SAIS 就是一个类似于 SUIM 的查询报表，输入几个条件，导出一张清单，结束。实际上 SAIS 的设计思路完全不是这样，它更像是一个带有“审计项目管理”味道的工作台：你可以先定义一个审计区域（Audit Area），针对这次审计要覆盖的范围——比如系统配置、用户权限、传输变更、安全日志——做采集配置，然后再基于这些采集结果去分析、追踪、导出证据。

也就是说，SUIM 是“查一下谁有什么权限”的单一查询工具，而 SAIS 是“从审计目标出发，把多个维度数据收集起来统一分析”的入口。它解决的不是一个查询问题，而是一个审计过程管理的问题。

我最早接触 SAIS 是在一次配合外部审计师做 SOX 合规检查的项目里。对方要求我们提供“过去一年生产环境所有后台配置变更记录、关键用户权限变更记录、以及所有传输请求上线日志”。我当时第一反应是拿 SE03 去查请求、拿 SUIM 去跑用户权限对比，结果搞了两天，数据是凑出来了，但审计师一句话就把我怼回来了：“你这些表格之间没有任何关联逻辑，我怎么知道配置变更和传输请求是不是同一批人操作的？用户权限变更有没有经过授权流程？”

后来 Basis 的老顾问甩给我一个事务码：SAIS。我才发现，SAP 早就把这类跨对象关联查证的能力做成了标准功能，只是一直没被大家重视。

1.2 为什么多数 ABAP 顾问不碰 SAIS：三个误判

我自己总结了三个导致 SAIS 长期被忽视的原因。

第一个误判是“SAIS 和 SUIM 差不多”。真实情况是，SUIM 聚焦用户信息系统的用户与角色授权查询，而 SAIS 的覆盖面更广，它在左侧沿树形结构展开审计领域，比如系统配置、用户管理、变更传输、应用程序数据、安全日志，属于一种审计专用的驾驶舱视图。两者定位完全不同。

第二个误判是“SAIS 打开就查不到数据”。有相当一部分人第一次进入 SAIS，创建了审计区域后跑报表，发现结果为空，就直接判定这个事务码没用。实际上，SAIS 的审计区域有“激活”和“未激活”的区别，而且有些数据采集项需要在后台定期收集，不是即查即有的。

第三个误判是“SAIS 是 Basis 或安全顾问的事情，ABAP 开发用不上”。这个说法放在十年前也许没毛病，但现在的 ABAP 开发者恰恰经常被问到“这个自定义程序谁在跑”“这个增强怎么进的生产”“这个敏感表谁改过数据”，这些都是审计问题。你如果不懂 SAIS，就只能低效地去翻各种孤立日志。

1.3 和 SUIM、SE03、SM20 的边界：一张表说清楚

为避免概念混淆，我把 ABAP 平台上和审计相关的几个常用事务码做了个对比。注意这里不是分优劣，而是讲定位差异：

从这个表能看出来，SAIS 不是要替代这些事务码，而是提供了一条审计线索，让你从审计目标出发，按图索骥地落到具体的日志或配置项上。这也是为什么我说它是一个“工作台”，而不是一个“查询器”。如果你只把它当成查报表，那确实不如 SUIM 顺手；但你一旦开始处理审计项目，就会发现它的组织方式天然匹配审计流程。

2. SAIS 的数据从哪来：先搞懂它的运行机制才不会白查

2.1 审计区域是总开关：不激活等于空转

SAIS 的第一个关键概念叫审计区域（Audit Area）。你可以把它理解成一次审计项目的“配置档”。每次开启新的审计任务，都应该新建或复用对应的审计区域，在里面明确要关注哪些对象、采集哪些数据、保留多长时间。

我这里要强调一个我在实际项目里反复踩的坑：创建了审计区域不等于开始采集数据。SAP 的审计信息系统在默认情况下采集开关是关掉的，即使你把审计区域里的采集项全部勾上，只要没有执行“激活审计区域”的动作（或者按版本不同，没有调度对应的后台采集作业），查询结果就是空的。

在我参与的一个项目里，客户安全管理专员在内部自查时打开 SAIS，发现安全日志分析区域一条记录都没有，一度以为生产系统安全日志没开。我过去看了一下，SM19 里审计级别明明设置了“安全相关”，SM20 也能看到记录，但 SAIS 里就是查不到。最后发现，问题就出在审计区域没有激活，SAIS 的视图根本没有去读安全日志的数据源。这个操作顺序问题，很多顾问一开始都会栽。

2.2 数据源拆解：配置变更、用户授权、传输记录、安全日志分别落在哪里

为了让你不白查，我把 SAIS 常见审计领域背后的数据来源做了个梳理。理解这些来源，有助于你判断查询结果是“实时读表”还是“基于历史采集”。

注意，每个版本的菜单结构和数据源命名会有差异，但底层逻辑基本一致。你如果能记住“SAIS 是审计线索的入口，不是数据仓库本身”，遇到任何查不到数据的情况，沿着这条线索往下游数据源去排查，思路就不会乱。

2.3 SAIS 与安全审计日志（SM19/SM20）的联动逻辑

这里特别说一下安全审计日志和 SAIS 的关系，因为这是最容易混淆的地方。

SM19 是配置安全审计日志的工具，你可以设置审计级别（比如只记录安全相关事件、记录所有事件）和具体审计类别（登录、RFC、事务码、报表、文件访问等）。SM20 是查看这些日志的预览工具，通常负责前端查看和手动删除。

SAIS 里的安全日志分析区域，相当于是把这些底层记录按照审计分析的维度重新聚合展示。举个例子：你在 SM20 里看到某用户在凌晨三点执行了 SE16，这只是一条孤立的事件；但在 SAIS 的安全审计分析里，你可以把“用户 + 时间段 + 事务码 + 客户端 + 终端 IP”放在同一个分析视图里，再结合该用户的权限变更记录，形成一条完整的行为链。审计师真正需要的，恰恰是这种关联视图，而不是一堆孤立日志。

所以，如果客户的生产系统连 SM19 都没有配置，那么 SAIS 里安全日志分析区域当然就是空的。这不是 SAIS 的缺陷，而是上游数据源没有打开。我在检查清单里永远把“SM19 是否已配置、审计级别是否合理”放在第一位。

3. 把 SAIS 真正跑起来：激活审计区域与最小可用配置

这一节直接上实操。以下步骤基于我实际环境中的操作经验，不同 S/4 版本或 NetWeaver 版本菜单名称会略有差异，但流程是通用的。

3.1 第一步：创建并激活审计区域

调用事务码 SAIS，进入系统审计信息系统的树形导航界面。左侧是审计领域目录，右侧是具体功能区域。

创建审计区域的路径一般是：在 SAIS 初始界面找到“审计区域”或“环境设置”相关节点，进入后点击新建。需要维护的信息包括：

• 审计区域名称和描述：建议按项目命名，比如“2024_SOX_AUDIT”，方便后续追溯。
• 有效期间：设置审计窗口的起止日期。
• 采集范围：勾选本次审计关注的领域。

创建之后，最关键的一步是回到审计区域列表，选中刚才创建的区域，点击“激活”或“启用”按钮。部分版本里，激活动作会要求你保存并生成后台作业，用于定时采集审计数据。

提示：激活前后最好都截图留档。审计证据里，“审计系统本身何时开启采集”也是经常被追问的内容。

3.2 第二步：按审计目标勾选采集范围

审计区域激活之后，接下来要维护具体的采集规则。这相当于告诉系统：这次审计我要重点盯谁。

常见配置项包括：

• 关键用户列表：把具有管理员权限、能修改配置或能执行敏感事务码的用户单独圈出来。
• 关键事务码列表：比如 SE16、SE16N、SM30、RZ11、SU01、PFCG 这类涉及数据读取、配置变更和权限维护的事务码。
• 关键表列表：如 USR02、AGR_USERS、TADIR、E070 等敏感表，建议开启表日志（如果你有权申请）。
• 关键传输路径：关注开发到生产、预生产到生产的传输行为。

这里我给一个建议：审计范围不要贪多。采集项越多，后台作业越重，对生产系统的影响也越大。最合理的做法，是结合本次审计的具体目标，优先覆盖高风险区域。比如这次审计的重点是“配置变更管理”，那系统配置和传输管理两个领域必须采集；用户权限管理可以延后做，不需要全上。

3.3 第三步：从审计工作台发起查询并导出结果

配置完成并运行一段时间后，审计区域里就会积累数据。此时，你就可以像使用其他 SAP 报表一样，从 SAIS 的树形导航进入各审计领域，设置查询条件（比如时间范围、客户端、用户组、事务码组），执行查询。

查询结果的输出一般走 ALV 网格，你可以方便地排序、筛选、小计。最关键的是，在 ALV 网格中执行“导出”到本地文件（如 Excel、CSV），或者在支持打印的场景下输出 PDF。我在跑审计证据时，习惯把每个查询结果的文件名规范为“审计领域_查询范围_时间戳”，比如“SecurityLog_2024Q1_20240401.xlsx”，这样做的好处是审计师拿到文件时，不需要你反复解释。

3.4 一个可以直接照抄的最小配置组合

如果你只是想在系统里建立一套可持续运转的轻量审计机制，我建议参考下面这个最小配置组合。它覆盖了日常 IT 审计八成以上的取证需求，同时不会给系统带来明显负担。

这套组合我在两个客户的内部合规项目里实际用过。日常消耗很小，每个月 SM19 产生的安全日志增量在可控范围内，SAIS 侧的后台采集作业每晚跑一次，基本不影响白天业务。

4. 四个高频审计场景的完整拆解：从问题到取证

SAIS 这种工具，光讲配置是没法真正掌握的，必须放到具体审计场景里看。下面四个场景是我接过的审计需求里出现频率最高的，每个场景我都会给出查询路径、关键判断维度和证据整理方法。

4.1 追溯后台配置变更：谁在什么时候改了什么

外审最常问的一句话是：“这个生产系统的后台配置，最近一年有没有未经过变更审批的调整？”

你可以从 SAIS 的系统配置审计区域进入，结合两个维度查：一是表变更日志（SCU3），如果关键配置表开启了日志，可以精确到字段级的前值/新值、修改人和修改时间；二是传输变更记录（E070/TMSQAT），看配置变更是通过传输请求上线，还是直接被人在生产环境手动维护的。

我的判断逻辑是：先看配置表的表日志记录，如果某条配置记录的创建者不是传输用户（比如 DDIC 或某个专门的技术账号），而是普通业务用户，那基本可以断定这是手动修改，审计价值极高。然后顺着修改人去查他的权限变更记录和会话登录日志，构成一条证据链。这个流程在 SAIS 里完成是最顺畅的，因为你不需要在 SCU3、SUIM、SM20 之间反复切换。

4.2 用户与权限合规初筛：职责分离的快速检查

职责分离（Segregation of Duties，SoD）是审计的常规动作。审计师会检查同一用户是否同时具有互相冲突的权限，比如“既能创建供应商，又能维护银行信息”这种。

SAIS 的用户权限审计区域，可以让你按用户组或角色，快速拉出权限对象清单，再和已知的冲突组合规则做对照。我自己通常的做法是先在 SUIM 里按角色批量导出权限对象，再在 SAIS 的审计区域里按用户维度汇总权限，两边一比对，冲突点就出来了。

这里要提醒一句：SAIS 不是专门的 SoD 分析工具，做不了自动的冲突矩阵计算，那需要 GRC 或自开发工具。但它能快速给出“哪个用户拥有哪些敏感权限”的全局视图，这在审计初筛阶段足够用了。真到了需要详细 SoD 矩阵的时候，你可以基于 SAIS 导出的权限清单，再在 Excel 里做二次加工。

4.3 传输请求与代码上线审计：程序从开发到生产的全程

ABAP 开发者最常被审计的就是代码上线。审计师会问：这个自定义程序是谁开发的、在哪个请求里、什么时候传输到生产的、传输人是谁、传输内容有没有经过代码评审。

SAIS 的变更与传输管理审计区域，直接围绕请求/任务（E070/E071）、传输队列（TMSQAT/TMSBUFT）和对象目录（TADIR）做关联展示。你选择一个请求号，系统可以展开出该请求下的所有对象、各阶段传输动作、执行传输的技术账号和时间戳。

我强烈建议开发团队在每次版本发布后，用 SAIS 导出本次发布请求的传输记录，按“发布窗口_请求号_传输日志”的格式归档。半年下来，你会发现审计准备时间从一周缩到半天，因为证据链是持续积累的，不是临时翻出来的。

4.4 异常访问与敏感事务码使用：安全日志的审计视角

第四个高频场景是查“敏感操作”。比如：某个离职员工的账号在离职后是否仍有登录记录？某个正常只能在办公时间操作的用户，为什么凌晨执行了事务码 SE16N 去查薪资表？

在 SAIS 的安全日志审计区域，你可以按用户、时间、客户端、事务码组合筛选安全审计日志。这种多条件组合正是 SM20 这类工具不方便实现的地方，也是 SAIS 作为审计工作台的真正价值所在。

查异常访问时，我一般会结合三个信号综合判断：登录时间是否在业务窗口外、访问的事务码是否属于该岗位正常职责、使用的客户端或终端地址是否符合习惯。三个信号里命中两个以上，就需要拉出完整的用户行为记录交给审计师做进一步判断。这套判断逻辑放在 SAIS 的安全日志视图里非常顺手，因为它天然支持多条件交叉。

5. 落地过程中最容易踩的坑：我的实测记录

这一节我要把实战中见过的坑集中写出来，每一个都是真实发生过的。

5.1 审计区域配了但没激活，报表全是空的

这个坑我在前面提到过，但它值得单独占一个小节，因为太常见了。现象很统一：SAIS 界面里所有查询区域都能点进去，条件也能输入，但执行后就显示“无数据”。

排查步骤记住这个顺序：先看 SM19 安全日志是否有数据，没有就查 SM19 配置；有数据就到 SAIS 的审计区域维护界面，确认审计区域状态是否已经是“已激活”；如果显示草稿或禁用，激活保存后再重新查。

这里还要注意一个细节：修改了审计区域的采集范围后，部分版本要求重新执行一次激活操作，否则新的采集规则不会生效。我见过有人只改了范围忘记重新激活，结果查到的还是旧范围数据，白白浪费了一晚上的分析时间。

5.2 全开审计采集后系统变慢：性能与覆盖范围的取舍

审计需求往往伴随着“能开都开”的想法，尤其在合规压力大的时候。但全量采集对生产系统的性能影响是真实存在的，尤其在大并发环境下，安全审计日志的写入和表日志的记录会明显增加数据库负载。

我的建议是分级采集：核心生产系统优先只开“安全相关”审计级别，不要开“全部事件”；事务码审计只覆盖高风险事务码，不要全系统所有事务码都记；表日志方面，只对高风险主数据表和配置表开启 SCU3 日志，不要对业务流水表启用，因为那会带来灾难性的数据量增长。

在这里给一个性能红线参考：审计日志的磁盘增长率如果超过你日常监控基线的两倍，就有必要回头审视采集范围了。审计是为了发现风险，但如果因为审计把系统拖垮，那等于制造了更大的风险。

5.3 数据保留策略：审计表只增不删会是什么后果

审计数据本身也是数据，而且是只增不删的数据。安全审计日志、表日志、变更记录，这些表会随着时间推移快速增长。如果你配置了审计但没规划保留周期，半年后这些表可能占据以 GB 计的存储空间，甚至会影响系统的备份和恢复时间窗口。

我通常建议建立明确的数据保留与归档策略。安全审计日志保留 12 个月是合规底线，过了 12 个月的按审计要求做归档备份后删除；表日志和变更凭证可以按业务重要性分档保留。归档动作要形成记录，因为审计师审查时不仅看日志内容，还会看日志管理是否规范。

5.4 审计权限本身也要被审计：避免人为删改日志

最后一个坑可能比较隐蔽：谁有权限查看和删除审计日志？如果这个权限分配得很随意，那审计数据的可信度就会受到挑战。审计师只要问一句“谁能保证这些日志没被动过手脚”，你的整个审计证据链就站不住脚了。

在 ABAP 平台里，查看审计日志和分析审计信息的权限需要通过权限对象严格控制，理想情况下应该只授予审计相关的独立账号，不要混在 Basis 日常维护账号里。删除安全日志的权限更要收紧，并且删除动作本身也要留痕。我把这条称为“审计的审计”，它在 SAIS 落地时最容易被忽略，但恰恰是审计师最看重的一点。

6. 把 SAIS 发展成自己的工作台：协同与扩展

6.1 SAIS + SUIM + SM20 的分工组合拳

从我多年的使用经验来看，真正高效的审计支撑体系不是指望某一个事务码解决所有问题，而是让每个工具回到自己的优势位置。

SAIS 承担“审计线索串联”和“跨域分析”的角色，是工作台和主入口；SUIM 负责用户与权限维度的深度查询；SM20 用于快速查看和日常排查安全日志；SE03 在需要追踪请求对象明细时作为补充。

打个比方：SAIS 是总指挥中心，SUIM、SM20 这些是一线执行单元。遇到审计问题时，你先在总指挥中心判断应该查哪个方向，再下钻到具体工具里去取细节数据，最后回到总指挥中心完成证据归档。这个工作方式，我从第一次在项目里用 SAIS 建立审计支持流程后，就再也没回到过“东翻一个事务码、西翻一个事务码”的原始状态。

6.2 二次开发扩展：ALV 导出与自建报表的衔接

如果 SAIS 的标准展示满足不了你的个性化审计报表需求，还可以做二次开发扩展。最常见的方式，是从 SAIS 背后的数据源表里取数，用自建报表按客户要求的格式输出审计台账。

我做过的一个案例是：客户要求每月生成一份“高权限账号权限变化月度报告”，包含用户、角色变动、变更时间、变更操作者、变更来源（手工或传输）。这个需求 SAIS 标准功能能看，但格式不符合内部汇报要求。后来我写了一个 Z 报表，从 USR02、AGR_USERS、CDHDR/CDPOS 取数，按客户格式生成 Excel，再把数据和 SAIS 的查询结果做交叉验证，审计师对此非常认可。

这里想表达的是：SAIS 提供了审计视角的“方法论框架”，而自开发报表是灵活的手指，两者结合，才是真正适配业务环境的审计工作台。

6.3 审计检查单支持：季度合规检查怎么做

最后一个落地建议，是把 SAIS 绑定到周期性的内部审计检查单里，让它从“应付外审”变成“日常管理工具”。

我这边通常建议客户每季度执行一次内部审计自查，检查单包含：审计区域状态是否正常、SM19 安全审计是否还在启用、关键用户权限清单和实际用户是否一致、传输请求归档是否完整、安全日志保留时间是否满足要求。整个自查过程，80% 的环节都可以在 SAIS 工作台内完成。

坚持一个季度后你会发现，外部审计来的时候，你交出来的不再是临时拼凑的截图和报表，而是一套持续运行、有历史轨迹、有管理记录的审计体系。到这个状态，“审计”两个字就不再让人焦虑了。

最后分享一点个人体会：SAIS 这个事务码，表面上解决的是“查得到数据”的问题，本质上解决的是“审计工作怎么组织”的问题。工具本身并不神秘，真正拉开差距的，是你有没有把审计证据链当成一条持续维护的业务线来运营。下次有人再说 SAIS 是冷门事务码，你可以直接把这篇文章转给他，然后用实际的数据和分析结果告诉他：真正好用的审计工作台，早就藏在标准功能里了。