SAP 场景化授权检查设计，如何用 CL_SACF 在不打断业务的前提下补强 ABAP 安全控制

最近在看一段老的 ABAP 代码，感触挺深。业务已经上线多年，前台是 SAP GUI，也有一部分功能被 Fiori 或外部系统通过 RFC、OData 调起来。代码里有一些AUTHORITY-CHECK，但检查粒度明显是当年按事务码和组织字段设计的。现在业务变了，接口开放了，合规要求也提高了，原来的授权检查不能说完全没用，但它已经覆盖不了所有入口。这种系统里最麻烦的地方不在于补一个授权检查有多难，而在于补上以后会不会马上把生产业务打断。一个看似正确的AUTHORITY-CHECK，如果直接放进核心代码路径，可能第二天就有大量用户报错，因为角色还没准备好，PFCG 里的对象值还没维护完，测试系统里的用户样本又不能代表生产系统。SAP 的 Scenario-based Authorization Checks，就是为这种尴尬场景准备的。它不是用来取代所有AUTHORITY-CHECK的，更不是让开发人员绕开传统授权对象模型。更准确地说，它给了 ABAP 开发和 Basis 安全团队一个缓冲层，让新的授权检查可以按场景交付、按系统状态启用、按测试结果调整，避免把一个安全修复变成一次生产事故。从一个老 RFC 函数的授权补洞说起我们在很多企业系统里都能看到类似情况，一个自开发 RFC 函数早年只给内部系统使用，函数入口没有显式检查业务授权，只在事务码层面依赖 S_TCODE，或者在调用方菜单层做了控制。几年之后，ESB、中台、RPA、外部 Portal 都开始调用这个函数，原来所谓的内部入口变成了共享 API。假设这个函数读取客户信用数据，早期调用场景只有财务