网站权限设置

去年秋天，网站一个做独立博客的权限朋友急吼吼地找我，说他的设置网站被搜索引擎标记了“危险”。我打开一看，网站首页被挂了一段博彩链接。权限问题出在哪？设置他给一个“友情链接交换”的临时编辑账号开了管理员权限，对方转手就把权限卖了。网站这事不新鲜，权限但每次遇到都让人觉得可惜——网站权限设置，设置多数人不是网站不懂，是权限懒得细想。

权限的设置本质就一句话：谁，能在什么条件下，网站对哪些资源，权限做什么操作。设置四个要素缺一个，漏洞就来了。我见过最离谱的案例，一家小电商的后台，所有客服账号共用同一个“客服”角色，但这个角色居然有删除订单的权限。问技术负责人为什么，他说“方便，不用一个个配”。后来一个离职客服登录旧账号，删了三百多笔已发货订单，理由是“心情不好”。

最小权限原则被说烂了，但真正执行的人不多。我的做法很直接：任何新账号，先给只读权限。观察一周，看这个人实际需要点什么按钮、进哪些页面，再逐项加。听起来麻烦？其实比事后擦屁股省事得多。有个做SaaS的朋友更绝，他把权限申请做成了内部工单系统，每加一项权限都要填理由和有效期。结果半年后统计，80%的临时权限到期后没人续期——说明那些权限本来就不该长期持有。

角色设计是另一个容易翻车的地方。很多后台默认给几个固定角色：管理员、编辑、作者、访客。现实业务哪有这么干净？比如一个内容团队，有人只管写稿不能发布，有人能发布但不能改别人的稿，有人能改所有稿但不能碰用户数据。硬塞进“编辑”一个角色里，要么权限不够用，要么给多了。我的建议是：按“动作+对象”来拆角色。比如“文章-创建”“文章-审核”“用户-查看手机号”，每个角色只绑定一个具体动作。角色数量会变多，但边界清晰，出问题能精准定位。

数据库层面的权限常被忽略。前端按钮灰了，不代表后端接口安全。我做过一次渗透测试，某个网站前端隐藏了“删除用户”按钮，但直接调API照样能删。原因就是后端只检查了“是否登录”，没检查“是否有删除权限”。所以权限校验必须落在服务端，每个接口入口都要过一遍。别信前端，别信前端，别信前端。

日志和审计是权限系统的保险绳。谁在什么时候改了谁的权限，谁用某个权限做了什么敏感操作，这些记录平时看着烦，出事时就是救命稻草。我习惯把权限变更日志单独存一张表，保留至少180天。有一次客户坚称数据没被内部人动过，我拉出日志，显示某账号在凌晨3点连续导出了两次全量用户表。对方没话说了。

最后说个反直觉的点：权限设置不是越细越好。我见过一个系统，把权限拆到了“按钮级”，结果管理员配一个新人账号花了四十分钟，还配错了。细粒度要配合自动化工具，否则就是给自己挖坑。小团队用“角色+少量例外”就够了，大团队再上ABAC（基于属性的访问控制）。别为了技术正确而牺牲可操作性。

回到开头那个博客朋友。后来我帮他重建了权限体系：编辑账号只能改文章，不能碰主题和插件；临时合作者给有时效的“作者”角色，到期自动降权。三个月后他说，终于敢把后台地址发到群里了。权限这事，做的时候嫌烦，不做的时候更烦——只是烦的时间点不同。