基于角色的访问控制（Role-Based Access Control，简称 RBAC）是按岗位角色管理系统权限的方法：先定义“销售”“财务”“系统管理员”等角色，确定每个角色能查看和操作哪些内容，再把员工分配到角色中，而不是逐个给人设置权限。员工入职、转岗或离职时，只需调整其角色，不必从头重新配置访问权限。
从网站 CMS、ERP 到定制的管理后台，大多数业务软件都采用某种形式的 RBAC。了解它的原理，既有助于规划新系统，也便于管好现有系统。
RBAC 的原理：用户、角色和权限
RBAC 由三个部分组成：
- 权限：对某类数据执行的具体操作，例如“查看订单”“办理退款”“修改商品价格”“导出客户名单”。
- 角色：一组带名称的权限，对应实际岗位，例如“客服”或“门店经理”。
- 用户：员工的实际账号。每个用户被分配一个或多个角色，并获得这些角色包含的权限。
以下示例仅用于说明：在网店管理后台中，“客服”角色可以查看订单、更新配送备注；“门店经理”角色还可以修改价格、审批退款；只有“系统管理员”角色能创建新账号或更改系统设置。新入职的客服只要分配到这个角色，第一天就能拿到合适的权限。
RBAC 对成长型企业的意义
- 最小权限原则：每个人只拿到工作所需的权限。即使账号被滥用或密码被盗，影响范围也更小。
- 入职和离职处理更快：分配或移除一个角色，比逐项勾选几十个设置更快，也更不容易出错。
- 减少误操作：员工无法修改或删除本不该接触的数据。
- 便于核查：查一查“谁有财务角色”，比逐个账号检查简单得多。
RBAC 的常见误区
- 人人都是管理员：小团队里很常见的省事做法，会让 RBAC 的大部分保护作用失效。
- 角色越建越多：每遇到一个例外就新建一个角色，最后谁也看不懂角色列表。角色数量应尽量少，并与真实岗位对应。
- 共用账号：多人共用一个登录账号，就无法分清是谁做了什么操作。
- 权限只增不减：员工转岗后，旧权限仍然保留，又叠加了新权限。
- 忘记清理离职人员和供应商：前员工、外包人员或以前合作的代理公司，账号依然可以登录。
- 只在界面上做限制：按钮在界面上被隐藏了，但后台服务器或 API 并没有校验权限，有人仍然可以直接触发该操作。
为新系统规划角色
如果你准备委托开发网站、App 或内部平台，最好在设计页面之前就把角色定下来：
- 列出会使用系统的人员和团队，包括代理商、加盟商、供应商等外部人员。
- 列出敏感操作，例如审批付款、办理退款、导出个人数据、修改价格、删除记录。
- 做一张简单的表格，行是角色，列是操作，标明谁可以做什么。
- 确定由谁分配角色，以及敏感操作是否需要第二人审批。
- 要求系统为关键操作和角色变更保留审计日志。
- 在用户验收测试（UAT）阶段逐个测试每个角色，包括确认角色无法执行不该执行的操作。
RBAC 与 SSO、MFA、零信任的关系
这几个概念相互关联，但解决的问题不同。单点登录（SSO）和多重身份验证（MFA）解决的是“你是谁”；RBAC 解决的是登录后“你能做什么”。零信任是更宏观的安全思路，针对每项资源评估访问请求，角色通常是其中一个判断依据。
RBAC 也有局限。如果规则取决于门店、记录负责人或时间段等细节，系统通常会在角色之外再加上基于属性的规则；这些规则同样需要写进文档。
持续管好角色
- 根据风险定期复核角色分配，员工转岗时也要及时复核。
- 员工或供应商离开后，尽快收回其访问权限。
- 系统管理员账号要少，必须实名，并启用 MFA。
technine.io 在业务系统与云平台项目中会一并规划权限、身份认证和审计日志，也可以通过网络安全与合规服务检查访问控制。
常见问题
RBAC 只适合大公司吗？
不是。即使只有五个人的团队，把负责更新网站内容的人和能修改支付设置的人分开，也有实际好处。小型系统可能只需要三四个角色。
一个人可以同时拥有多个角色吗？
大多数系统都支持。用户的权限通常是所有角色权限的合集，所以要检查角色组合是否冲突，例如同一个人既能创建又能审批同一笔付款。
现有系统能加上 RBAC 吗？
很多情况下可以，但取决于系统的开发方式。如果系统从未在服务器端校验权限，加入 RBAC 可能需要修改应用代码和 API，而不只是新增配置。确定方案前，应先请开发人员评估。
多久复核一次访问权限比较合适？
没有统一标准。不少企业会定期复核，并在有人入职、转岗或离职时再检查。存有支付数据或个人数据的系统，通常值得更频繁地检查。