RBAC应部署于哪个层级？各层级可扩展性优劣及行业标准解析

RBAC可以部署在你提到的所有层级，甚至还能扩展到中间件/API网关层，下面逐个拆解各层级的可扩展性优缺点，以及行业主流的最佳实践：

1. 数据库层级（行/列级访问控制） #

优点 #

• 直接在数据存储层做校验，不管请求来自哪里，都得经过这层过滤，能从根源避免应用层逻辑遗漏导致的数据泄露
• 批量数据操作（比如批量查询、统计）的性能开销相对可控，毕竟数据库原生支持这类过滤逻辑

缺点 #

• 可扩展性极差：权限规则变更就得改SQL或者数据库的访问控制策略，碰到多租户、复杂权限场景，SQL会塞满各种过滤条件，难写难维护还拖慢查询
• 耦合度太高：权限逻辑和数据查询绑定死了，换数据库的时候，得重新适配不同数据库的行级控制语法（比如PostgreSQL的RLS和MySQL的实现差异很大）
• 玩不转复杂业务权限：比如基于时间、用户行为的动态权限判断，数据库层根本没法实现

2. 应用程序层级（代码嵌入逻辑） #

优点 #

• 灵活性拉满：能实现任意复杂的权限逻辑，包括结合业务规则的动态判断
• 低耦合（设计合理的话）：要是能把权限逻辑抽成独立的服务或模块，和业务代码解耦开，后续改规则、扩展都很方便
• 适配多种存储：不管是关系型数据库还是MongoDB这类文档存储，都能通过应用层逻辑统一处理权限

缺点 #

• 容易漏校验：开发人员一不小心就可能漏掉某些接口的权限判断，导致数据泄露
• 大数据场景性能拉胯：如果要查大量数据，应用层得先拿全量数据再过滤，数据量一大性能就崩（不过可以和数据库层配合，把部分过滤逻辑下推到数据库优化）
• 跨应用一致性差：如果多个应用访问同一数据源，每个应用都得单独写一套权限逻辑，很容易出现规则不一致的情况

3. 其他层级：中间件/API网关层 #

这是你没提到但很常用的层级，补充说明下：

优点 #

• 集中管控：所有API请求都走网关，权限校验逻辑统一维护，不用每个应用重复开发
• 无侵入：不用改现有应用代码，对老系统改造友好
• 扩展性好：能快速加新的权限规则，还能搭配统一的权限配置中心管理

缺点 #

• 只能管粗粒度权限：没法实现行/列级的细粒度控制，针对具体数据条目的权限判断做不了
• 依赖网关性能：网关要是成了瓶颈，整个系统的可用性都受影响
• 管不了应用内部调用：比如应用内部服务之间的调用，网关层碰不到，没法管控

行业黄金标准 #

目前行业里的黄金做法是分层落地RBAC，兼顾粗粒度和细粒度控制：

1. 用API网关/中间件层处理粗粒度权限：比如判断用户能不能访问某个API、某个服务
2. 应用层实现细粒度的业务相关权限：比如判断用户能不能编辑自己创建的文档、查看部门专属数据
3. 数据库层做最后一道防线：实现基础的行/列级访问控制，防止有人绕过应用层直接访问数据库
   同时，建议把权限逻辑抽成独立的权限服务，用统一接口给应用层、网关层调用，实现权限规则的集中管理，既降低耦合度，又提升可扩展性。

内容的提问来源于stack exchange，提问作者bodhihammer