2. SAP S/4HANA权限模型核心对象

SAP S/4HANA 的权限体系并不是“给用户勾几个事务代码”这么简单，它是一条从业务操作入口一路收敛到最小授权粒度的链式结构。理解这条链，是后续做职责分离（SoD）分析、角色设计与权限审计的基础。本节把六个核心对象——用户主数据、角色（单一角色/复合角色）、参数文件、授权对象、授权字段、事务代码——放在同一张层级图中，并说明它们之间的继承与传递逻辑。

一、六个核心对象各自是什么

用户主数据（User Master Record）是权限的最终承载者。在事务代码 SU01 中维护，关键字段包括用户名、用户类型（对话用户、系统用户、通信用户等）、有效期、用户组，以及最关键的“角色（Roles）”和“参数文件（Profiles）”两个页签。用户本身不直接持有权限，它通过被分配角色或参数文件来间接获得权限。

角色（Role）是权限的“业务包装”。它把一组与某个岗位或业务场景相关的授权对象和字段值组织在一起，并赋予一个可读的角色名，例如“应付会计-发票录入”。角色分为两类：单一角色（Single Role）是最小可维护单元，直接包含菜单和授权数据；复合角色（Composite Role）本身不直接包含授权数据，它只是把多个单一角色聚合在一起，方便批量分配。复合角色可以嵌套复合角色，但最终叶子节点一定是单一角色。

参数文件（Profile）是角色在生成时自动产生的技术载体。当你在 PFCG 中点击“生成”后，系统会把角色的授权数据编译成一个或多个参数文件，命名通常为 SAP_ALL、SAP_NEW 或自定义的 Z* 参数文件。参数文件才是真正被用户主数据“挂载”的对象，角色与参数文件之间是一对多的生成关系。

授权对象（Authorization Object）是权限检查的最小逻辑单元，由 SAP 预定义或自定义，例如 F_BKPF_BUK（会计凭证：公司代码）、M_BEST_BSA（采购订单：凭证类型）。每个授权对象包含若干授权字段（Authorization Field），例如 BUKRS（公司代码）、ACTVT（活动）。字段值可以是单值、区间、通配符或变量。

事务代码（T-Code）是用户操作的入口。用户在命令框输入事务代码，系统执行程序，程序在运行过程中调用 AUTHORITY-CHECK 语句，对特定授权对象和字段值进行校验。事务代码本身不“拥有”权限，它只是触发权限检查的起点。

二、层级关系与继承逻辑

这六个对象构成一条自上而下的“授权传递链”：

1. 用户 → 角色/参数文件：用户主数据中分配角色，系统在用户登录时把角色对应的参数文件加载进用户缓冲区。
2. 复合角色 → 单一角色：复合角色展开后，其包含的所有单一角色一并生效，权限是并集关系。
3. 单一角色 → 参数文件：单一角色生成时，授权数据被写入参数文件；一个单一角色可生成多个参数文件（如按组织级别拆分）。
4. 参数文件 → 授权对象：参数文件内部按授权对象组织，每个授权对象下记录字段值。
5. 授权对象 → 授权字段：字段值决定“在什么范围内允许什么活动”。
6. 事务代码 → 授权对象：事务代码执行时触发权限检查，检查的是授权对象和字段值，而不是事务代码本身。

继承逻辑的关键在于：权限是并集，不是交集。如果用户被分配了多个角色，只要任一角色对某授权对象和字段值放行，该操作就通过。这也是 SoD 风险产生的根源——两个本应互斥的权限，可能因为被分配给同一用户而同时生效。

三、用一张图看清层级与传递

下图把六个对象按“用户侧 → 角色侧 → 技术侧 → 检查侧”排列，箭头表示授权传递方向。注意复合角色到单一角色是聚合关系，单一角色到参数文件是生成关系，参数文件到授权对象是包含关系，事务代码到授权对象是触发关系。

四、一个具体的传递示例

假设某企业要设计一个“应付会计”岗位，允许其在公司代码 1000 和 2000 中录入发票（活动 01 创建、02 修改）。设计过程如下：

1. 在 PFCG 中创建单一角色 Z_AP_INVOICE，菜单中挂入事务代码 FB60（录入供应商发票）。
2. 在“授权”页签中，系统根据菜单自动带出相关授权对象，例如 F_BKPF_BUK，字段 BUKRS 填 1000,2000，ACTVT 填 01,02。
3. 点击“生成”，系统创建参数文件 Z_AP_INVOICE，并把上述字段值写入。
4. 创建复合角色 Z_AP_CLERK，把 Z_AP_INVOICE 加入其中。
5. 在 SU01 中把 Z_AP_CLERK 分配给用户 ZHANGSA。

当 ZHANGSA 执行 FB60 并保存到公司代码 1000 时，程序调用 AUTHORITY-CHECK OBJECT 'F_BKPF_BUK' ID 'BUKRS' FIELD '1000' ID 'ACTVT' FIELD '01'，系统在用户缓冲区中查找参数文件 Z_AP_INVOICE，发现 BUKRS 包含 1000、ACTVT 包含 01，检查通过。若尝试保存到公司代码 3000，则检查失败，返回“没有授权”消息。

五、几个容易混淆的要点

• 角色与参数文件不是一一对应：一个单一角色可能生成多个参数文件（例如按组织级别拆分），复合角色本身不生成参数文件。
• 事务代码不是权限对象：T-Code 只是入口，真正被检查的是授权对象和字段值。同一个授权对象可能被多个 T-Code 触发。
• 授权字段的值决定“范围”：ACTVT 决定“能做什么”，BUKRS、WERKS 等组织字段决定“在哪个范围做”。两者必须同时满足。
• 用户缓冲区：用户登录时，系统把参数文件加载到内存缓冲区；角色变更后需要重新登录或执行 SU53 检查才能生效。

掌握这条“用户 → 角色 → 参数文件 → 授权对象 → 授权字段 ← 事务代码”的链式关系，后续做角色设计、权限比较（SUIM）、SoD 规则建模时，就能准确判断“权限从哪里来、在哪里被检查、为什么会被放大”。