在莆田网站开发服务中,账号权限分级通常按“角色—操作—数据范围”三层来设计:先确定谁是什么角色,再规定这个角色能做哪些操作,最后限定这些操作能作用在哪些数据上。比如编辑只能改自己负责的栏目内容,不能改支付配置;运营能看订单,但不能改服务器参数;管理员能分配权限,但关键操作要留日志。这样分级的目的是让每个人只拿到完成工作所需的最小权限,出问题时能快速定位到具体账号。
检查当前后台账号,重点看三类现象。第一,同一个账号既能发布内容,又能修改用户余额或支付设置,说明操作权限没有拆开。第二,多个岗位共用同一个管理员账号,登录日志里看不出具体是谁操作的。第三,离职人员账号仍处于启用状态,或者权限没有随岗位调整而收回。
这些现象不一定都是安全问题,但如果网站涉及订单、会员、支付或客户资料,一人多权会放大误操作和内部风险。判断标准很简单:问一句“这个账号被误用或泄露后,最坏能造成什么后果”,如果后果超出该岗位职责,就说明权限给多了。
权限分级有两种常见处理方案,适用条件不同。
实际项目中,两种方案经常组合使用:角色决定“能做什么”,数据范围决定“对哪些数据做”。如果团队只有几个人、栏目单一,先做角色分级就够;如果已经出现跨栏目、跨区域管理,就需要补上数据范围这一层。
无论选哪种方案,都可以按下面的顺序执行。
这里给一个假设例子:某网站后台有“文章发布”和“文章删除”两个按钮。编辑角色可以发布和修改自己的文章,但不能删除;主编角色可以删除本栏目文章;管理员可以删除任意文章并恢复回收站内容。这样分级后,误删文章的影响被限制在单个栏目内,恢复也有明确责任人。
权限配置完成后,不要只看设置页面,要用测试账号实际走一遍。检查项包括:用编辑账号登录,确认看不到支付配置菜单;尝试直接访问高权限操作的地址,确认系统返回无权限而不是正常执行;用管理员账号修改一次权限,确认日志里记录了这次变更;停用一个测试账号,确认该账号无法再登录。
如果测试中发现某个角色仍能访问不该访问的功能,先判断是角色权限没配好,还是数据范围没限制住。前者改角色,后者改范围条件。复查通过的标志是:每个账号的权限都能用一句话说清楚,且这句话与岗位职责一致。
下一步建议从现有账号里挑一个权限最大的,按上面的步骤拆成两个角色,再观察一周操作日志,看是否出现权限不足的反馈。如果没有,就继续拆分下一个;如果有,再针对性补权限,而不是直接恢复成管理员。