从 ABAP 代码里真正管住权限，聊聊 Checking Authorizations 的设计和落地

今天在看 SAP 授权问题时，很容易碰到一种误会，业务顾问在 PFCG 里已经给角色维护了授权值，开发同事就以为程序天然安全了。实际在 ABAP 里，权限不是自动飘进每一段业务逻辑的。角色、授权对象、授权字段、用户主记录这些东西只是准备好了权限数据，真正到了某个功能能不能执行，还要看程序在关键位置有没有发起检查。Checking Authorizations这个主题讲的就是这件事。一个用户点击按钮、执行事务码、调用 OData 服务、触发 RAP action，系统要判断这个用户是否允许做当前动作。判断的方式不是靠界面上有没有按钮，也不是靠前端有没有隐藏字段，而是在服务端把程序里指定的字段值，与用户主记录里已有的授权值做比较。比较通过，业务继续执行。比较失败，程序就要中断或者返回清晰的错误信息。这件事看起来很传统，其实在 S/4HANA、SAP BTP ABAP environment、RAP、Fiori 和 SAP Gateway 里仍然非常核心。只是在不同技术栈下，权限检查的位置和表达方式变了。On-Premise 时代常见的是事务码、报表、BAPI、增强和 Gateway DPC_EXT。到了 ABAP Cloud 和 RAP，更多会把读权限交给 CDS DCL，把写权限、动作权限、实例权限交给 behavior implementation。原则没有变，业务动作必须在服务端有可信的授权判断。权限检查不是 UI 控制，而是服务端业务保护在 SAP 项目里，很多权限事故不是因为 PFCG 没配，而是因为程序没有检查。一个 Fiori 页面上隐藏了删除按钮，只能说明正常 UI 路径下用户看不到按钮。如果有人通过浏览器调试工具、