权限设计要回答两个问题，能做什么和能看什么。前者叫功能权限，后者叫数据权限。很多系统只做了前者，结果同一个功能，不同人看到的数据范围是一样的，该看的看不到，不该看的全看到了。
把两类分开设计，思路会清楚很多。
一、功能权限的几种模型
最简单的是按人配权限，谁需要什么就给什么。人少的时候能用，人一多就没法维护，因为同样的岗位要重复配置很多次。
常见的是按角色配权限。把权限打包成角色，人员通过分配角色获得权限。角色可以按岗位设，也可以按职能设。按职能设更灵活，因为一个人在系统里可能同时承担几个职能。
更细的一种是按操作配。把功能拆到具体动作，查看、新增、修改、删除、审核、导出各自独立。配置起来工作量大，但控制最精确。重要的功能值得拆细，一般功能合并成一组即可。
二、数据权限怎么表达
常见的数据范围有几种。全部数据、本部门及下级部门的数据、本部门的数据、本人负责的数据、仅本人的数据。这几种覆盖了大部分管理场景。
多级单位的场景要特别注意。如果系统给多个单位用，数据范围要能按单位授权，而不是只能按部门。上级单位的人要能看下级的，下级看不到上级和其他下级的。
还有一种更灵活的表达方式，按规则组合。比如某个人能看本部门的数据加上自己参与过的跨部门项目。这类需求用固定的几种范围表达不了，需要支持自定义规则。做之前先确认业务上有没有这种需求，没有就不必增加复杂度。
三、几个容易留坑的地方
导出的权限。同一个列表，能看和能导出是两回事。全部导出到表格里，等于绕过了所有页面上的权限控制。导出功能要单独设权限，全量导出更要限制。
统计和报表的权限。报表往往汇总了数据，容易忽略权限过滤。一个人没有权限看某个部门的数据，但在汇总报表里看到了这个部门的数字，也是越权。
权限变更的生效时间。用户权限改了，要立刻生效还是下次登录生效。涉及敏感数据时应该立刻生效，做法是每次请求都校验权限，而不是登录时校验一次然后一直有效。
还有一点，权限要有默认值。新用户创建之后没有任何权限，需要什么开什么。反过来默认给全部权限再收，很容易漏掉，最后人人都是管理员。
四、维护上的安排
权限配置要有界面，不能只能改数据库。业务变化时，管理员应该能自己调整，不用每次都找开发。
要有权限查看功能。给定一个人，能看到他有哪些权限；给定一个角色，能看到哪些人有这个角色。出问题时排查起来快。
定期做权限盘点。每半年拉一份清单，看有没有权限明显不匹配的账号，有没有长期不登录却握着高权限的账号。这类账号是安全隐患的主要来源。
权限的所有变更都要记日志。谁在什么时候给谁加了什么权限、为什么加，这些记录在出现数据泄露之类的事件时，是追溯的依据。
上一篇数据大屏从需求到落地