「简单的权限适用于小系统，上下文感知的权限才能支撑企业级系统。」这是权限架构演进中最常被引用的一句话，也是无数工程师踩过坑后的共识。

大多数应用起步时，权限设计都很朴素：管理员拥有全部权限，编辑者能修改内容，访客只能浏览。这种基于角色的访问控制（RBAC）在初期运转良好。但随着系统扩张，需求迅速变得刁钻——部门经理只能编辑本部门数据，客服代表仅在工作时段可访问工单，用户只能从受信任设备下载报表，项目到期后承包商权限自动失效。传统RBAC面对这些动态条件时捉襟见肘，属性访问控制（ABAC）由此成为必需品。

打开网易新闻 查看精彩图片

两者的核心差异在于提问方式。RBAC问的是「用户是什么角色」，ABAC问的是「这个特定用户在这些条件下，能否对这个资源执行此操作」。这一转变彻底改变了权限设计的逻辑。

RBAC在企业级场景中失效的根本原因是权限爆炸。为应对细分需求，团队不断创建新角色：区域管理员、区域经理、区域经理只读版、财务经理、欧盟财务经理、美国财务经理、一级客服、二级客服……很快陷入角色泛滥、权限重复、业务逻辑硬编码、异常处理复杂、审计困难的泥潭。业内有种说法：每个特殊角色背后，通常都藏着一个架构设计问题。

ABAC通过四类属性解决这一困境。用户属性定义「谁」——部门、区域、雇佣类型、安全级别；资源属性定义「对什么」——文档所有者、所属区域、密级；操作属性定义「做什么」——读、写、删、审批、导出；环境属性定义「在什么情况下」——当前时间、IP地址、设备类型、地理位置。四者组合，形成动态判断依据。

现代权限架构遵循两项原则。一是集中化授权，禁止权限检查代码散落各处。将判断逻辑收拢到统一服务，如authorizationService.can(user, 'delete', project)，而非在业务代码里写死角色判断。二是策略驱动设计，权限应以策略形式定义，便于维护与审计。

企业级SaaS的权限系统还需应对多租户隔离、实时授权决策、缓存与性能优化等挑战。策略引擎的架构设计、属性建模策略、前后端各自的权限执行模式、审计日志与合规要求，共同构成完整的权限工程体系。最终目标是一致的：让权限判断从静态标签，进化为能够理解业务上下文的动态决策能力。