最近在梳理一套 SAP S/4HANA 自开发应用的权限方案时，一个很容易被低估的问题又冒出来了，业务顾问只说了一句，销售订单查询页面要按销售组织和活动类型控制权限。听起来很简单，开发同事在 ABAP 里加一段 AUTHORITY-CHECK，安全顾问在 PFCG 里补一个角色，好像就能交差。真到系统里动手，问题就会变得很具体，我们到底复用标准授权对象，还是创建 Z 开头的自定义授权对象，授权字段放几个，ACTVT 要不要放，SU21 里 Criticality 选 C 还是 N，SU24 里默认值怎么维护，后续升级时 SAP_NEW 又会不会受影响。
这些问题不是安全顾问一个人的事，也不是 ABAP 开发一个人的事。授权对象是 ABAP 程序、角色生成器、业务角色、审计合规之间的接口。SU21 里随手建一个对象，后面 PFCG 角色生成、SU53 排错、STAUTHTRACE 分析、Clean Core 审查都会跟着受影响。权限设计不严谨，轻的时候表现为用户到处报无权限，重的时候表现为权限边界过宽，审计时发现一堆用户拿到了不该拿的数据。
授权对象不是一个字段集合，而是一份访问契约
在 SAP AS ABAP 的权限体系里，授权对象 Authorization Object 用来描述一类访问检查。它由若干个 Authorization Field 组成，系统在检查时会把这些字段按照 AND 关系组合起来。也就是说，一个对象里放了 ACTVT、VKORG、VTWEG 三个字段，用户必须同时满足活动类型、销售组织、分销渠道这三项条件，检查才可能通过。
这点很关键。很多团队刚接触 SAP 授权时，会把授权对象理解成数据库表字段的简单投影。实际项目里更合理的理解是，授权对象是一份
