https://yuqiuwen.github.io/tags/acl/Recent content in ACL on yuqiuwenHugo -- gohugo.iozh-cnSat, 08 Aug 2026 00:00:00 +0000https://yuqiuwen.github.io/p/rbac/Sat, 08 Aug 2026 00:00:00 +0000https://yuqiuwen.github.io/p/rbac/<hr/> <p><img class="gallery-image" data-flex-basis="549px" data-flex-grow="229" height="1426" loading="lazy" sizes="(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px" src="https://yuqiuwen.github.io/p/rbac/rbac.png" srcset="https://yuqiuwen.github.io/p/rbac/rbac_hu_dd9f15cf37c2a2ad.png 800w, https://yuqiuwen.github.io/p/rbac/rbac_hu_6737bef67738f746.png 1600w, https://yuqiuwen.github.io/p/rbac/rbac_hu_c0dfcdf77aac9a01.png 2400w, https://yuqiuwen.github.io/p/rbac/rbac.png 3266w" width="3266"></p> <p>权限模型</p> <ul> <li>RBAC（Role-Based Access Control） ○ 按“角色→权限”授权，用户绑定角色，角色拥有权限。 ○ 例：财务角色可查看对账；运营角色可编辑商品。</li> <li>ABAC（Attribute-Based Access Control） ○ 按“属性表达式”授权：主体（用户）属性、资源属性、动作、环境（时间/地点/设备）等组成策略。 ○ 例：用户部门=资源部门 且 当前时间在工作时段 才能读。</li> <li>ACL（Access Control List） ○ 每个资源上维护“可访问主体列表及其权限”。 ○ 例：文档 A 允许 user_1 读写，允许 group_sales 只读。</li> </ul> <h2 id="核心差异"><a href="#%e6%a0%b8%e5%bf%83%e5%b7%ae%e5%bc%82" class="header-anchor"></a>核心差异 </h2><table> <thead> <tr> <th>维度</th> <th>RBAC</th> <th>ABAC</th> <th>ACL</th> </tr> </thead> <tbody> <tr> <td>授权粒度</td> <td>角色级（中等）</td> <td>条件级（最细，灵活）</td> <td>资源级（细，但分散）</td> </tr> <tr> <td>维护方式</td> <td>维护角色和权限映射</td> <td>维护策略表达式与属性字典</td> <td>每个对象维护名单</td> </tr> <tr> <td>动态场景</td> <td>一般，需要建很多角色适配</td> <td>强，天然支持时间/地点/级别等</td> <td>一般，需逐对象改列表</td> </tr> <tr> <td>可审计性</td> <td>强，审计角色→权限清晰</td> <td>中，需要记录策略判定依据</td> <td>弱/中，分散在对象上</td> </tr> <tr> <td>扩展到行/列级</td> <td>需配合数据权限或 ABAC</td> <td>原生支持（属性即行/列条件）</td> <td>可做，但运维成本高</td> </tr> <tr> <td>典型应用</td> <td>企业后台、SaaS 多角色</td> <td>安全/合规/多维条件场景</td> <td>文件共享、按对象授权</td> </tr> </tbody> </table> <h2 id="优缺点对比"><a href="#%e4%bc%98%e7%bc%ba%e7%82%b9%e5%af%b9%e6%af%94" class="header-anchor"></a>优缺点对比 </h2><table> <thead> <tr> <th>权限模型</th> <th>适用场景</th> <th>优点</th> <th>缺点</th> </tr> </thead> <tbody> <tr> <td><strong>RBAC</strong>（基于角色的访问控制）</td> <td>角色稳定、权限边界清晰的后台系统；SaaS 的租户内角色管理</td> <td>易理解、易审计、运维成本低；菜单与接口权限映射自然</td> <td>面对细粒度、多条件权限需求时，容易出现<strong>角色爆炸</strong>（成百上千个角色）</td> </tr> <tr> <td><strong>ABAC</strong>（基于属性的访问控制）</td> <td>基于用户、资源、环境等多维条件进行权限判定；适用于租户、部门、属地等数据隔离，以及合规、零信任、行级/列级权限控制</td> <td>灵活性高，单条策略可覆盖大量场景；天然支持动态上下文</td> <td>策略设计与属性治理复杂；可解释性和排障难度较高；评估链路较长，通常需要缓存优化</td> </tr> <tr> <td><strong>ACL</strong>（访问控制列表）</td> <td>针对特定对象的临时分享与协作，如文档、文件、相册、项目权限</td> <td>符合“分享给谁”的直觉；支持极细粒度的对象级权限控制</td> <td>对象数量较多时管理复杂；权限审计与回收成本高；难以表达批量授权策略</td> </tr> </tbody> </table> <h2 id="如何选择"><a href="#%e5%a6%82%e4%bd%95%e9%80%89%e6%8b%a9" class="header-anchor"></a>如何选择 </h2><ul> <li> <p>只需角色分权（管理员/运营/财务等），且权限不复杂 → 选 RBAC。</p> </li> <li> <p>需要数据级别的隔离或动态约束（部门/地域/级别/时间/设备） → 选 ABAC，或 RBAC + ABAC 组合。</p> </li> <li> <p>需要按单个对象分享给具体人（文档/仪表盘/工单） → 选 ACL，或在 RBAC/ABAC 之上对特定资源叠加 ACL。</p> </li> <li> <p>多租户 SaaS 常见组合：</p> </li> <li> <p>租户边界/行级隔离：ABAC（tenant_id 必须相等等条件）</p> </li> <li> <p>租户内功能授权：RBAC（角色→权限）</p> </li> <li> <p>文档/报告临时共享：ACL</p> </li> </ul> <h2 id="简单示例"><a href="#%e7%ae%80%e5%8d%95%e7%a4%ba%e4%be%8b" class="header-anchor"></a>简单示例 </h2><ul> <li> <p>RBAC（权限点）</p> </li> <li> <p>权限命名：order:read、order:approve</p> </li> <li> <p>角色映射：manager → [order:read, order:approve]</p> </li> <li> <p>判断：user.roles 含 manager 且 action=order:approve → allow</p> </li> <li> <p>ABAC（属性表达式）</p> </li> <li> <p>allow if user.dept == order.dept and user.level &gt;= 3 and env.time in [09:00–18:00] and action == &ldquo;read&rdquo;</p> </li> <li> <p>ACL（对象名单）</p> </li> <li> <p>order/123: { allow: [user:alice:read, group:ops:read, user:bob:write] }</p> </li> </ul> <h2 id="常见坑与规避"><a href="#%e5%b8%b8%e8%a7%81%e5%9d%91%e4%b8%8e%e8%a7%84%e9%81%bf" class="header-anchor"></a>常见坑与规避 </h2><ul> <li>RBAC 角色爆炸：用角色层级/权限聚合，别把数据维度塞进角色；把数据条件交给 ABAC。</li> <li>ABAC 属性失真：属性字典不统一、来源不可信；先做属性治理（来源、口径、更新、授权）。</li> <li>ACL 权限漂移：对象多且多人维护，定期做“可见性审计/分享过期回收”。</li> <li></li> </ul>