组织身份与权限审计

明·如归 · 宿舍管理白皮书 ｜ 第二篇 能力篇

上一章管的是数据的来路，现在管的是人的去处：谁能看哪栋楼、谁能批哪类单、谁在什么时候动过哪条记录。宿舍系统的权限设计有一处别的业务少有的难处——它要同时围着两棵树转：一棵是学校的人，一棵是学校的楼。

8.1 从一次越界查岗说起

某校有过这样的事：一位辅导员想查自己所带班级里住五号楼那几个学生的晚归记录，系统却让他看见了整栋楼四百人的作息——不是漏洞，是当初配权限的人想省事，给他开了"五号楼查看全部"。反过来那位管三栋楼的宿管，因为不属于任何学院，名单一个都看不到。

权限的错，一半是给多了，一半是给错了形状。 宿舍场景里这两半常常同时发生，因为人的组织归属和楼的空间归属根本不是一棵树上长出来的。

8.2 两棵树的交叉：数据范围怎么裁

系统里的数据可见范围由两组条件交叉裁出来：一组沿组织树走——学校、校区、学院、专业、班级，六级，学生和教师各有一棵；一组沿宿舍树走——校区、楼栋、楼层、房间。用户挂在哪一层，就看到那一层子树内的数据；负责宿管岗位的人，范围跟着楼走；带班的人，范围跟着班级走；两种范围可以并存，按"或"合并——这正好复现了开头那位辅导员真正该有的范围：本班学生 ∩ 全部楼栋。

这个模型不值一句"灵活"的夸奖，它值的是另一句话：新来一位楼长，不需要开发，不需要工单，管理员在组织树里把他挂对位置，他的世界就对了。 权限要人找代码，组织一调整权限就失真——多数学校的现状正是如此。

8.3 五十五道闸：每个动作单独过一遍

看得到，和做得动，是两件事。系统把后者拆成五十五个权限码，覆盖在控制器动作上——查是查、导是导、批是批、改是改，各过各的闸。

有三条纪律比清单本身更要紧。第一，前端隐藏按钮不能代替后端校验：菜单和按钮按权限渲染不假，但真正的把门在每个接口动作上独立发生——绕过页面直接提交，同样被五十五道闸之一拦下。第二，写操作从严于读操作：导入、删除、启用这类动作的权限码单独设置，不与查看共用；往他人床位打卡这种"身份冒用"，不是靠权限码，是靠业务规则在接口里当场拒绝（第十章细谈）。第三，角色继承有天花板：管理员、管理人员、校领导、宿管、宿舍长、学生，六级角色各有各的端，学生端永远进不了管理端的路由——不是界面不给看，是接口根本不认。

权限设计的好恶，一看越权的成本，二看收权的成本。 给一个人收紧范围，应该和给他放宽一样只是拖拽树节点的动作；做不到，说明权限是焊死的，不是配置的。

8.4 登录：不让学校为身份再造一个账号

宿舍系统不该逼师生再记一套密码。系统内置十二条认证链可选：本地的账号口令作保底，标准协议接校园统一身份（CAS、OIDC 两类），平台侧接企业微信、微信与几家主流校园 App 的票据体系。一个学生从哪个入口进宿舍服务，就该带着那个入口已经确认过的身份——这是接入层的事，不该推给用户的记忆。

依赖第三方登录的部分，边界也说清：票据校验、账号映射、首登建号在服务端完成，第三方站点故障时保底口令入口仍在。统一的身份，不统一的风险。

8.5 看得见之外：不留影子的权限等于没有

权限解决了"谁可以"，审计回答的是"谁真的做了"。宿舍数据里的敏感项不需要讨论要不要留痕——家长手机号、健康备注、作息轨迹，任何一条被谁看过、导出过，都必须有答案。

系统的留痕分三层。操作层：登录、增删改、导入导出进操作日志，写库前对内容做快照——事后不仅能知道"改过"，还能还原"改成什么样、之前是什么"。展示层：敏感字段按角色脱敏——同一条记录，宿管看到的家长号码和处长看到的不是一张脸；页面输入统一清洗，防的是最古板的注入招数。限流层：登录每分钟十次、导入每分钟五次——既防撞库，也防误操作把系统当脚本刷。

有一层常被漏掉：导出要留名单。 谁在什么时间导出了哪栋楼的联系方式，行数可以复盘、字段可以复盘、事由将来也要能问得出来。宿舍数据出事，十有八九不是被黑，是被导出。

8.6 权限矩阵：把"不敢给"变成可讨论的问题

权限与审计做齐，最终要服务的其实是一个管理学问题：宿管该不该看到学生家长的电话？ 大多数学校的真实答案是含糊的——"看情况"。含糊的代价是每次出事先查人。

系统给的回答方式是把含糊变成明细：字段级可见性配置（自定义字段可指定哪些角色可见）、导出与查看分码、每一次"看"都留痕。有了这三样，后勤处长可以安心给宿管开电话权限——因为他知道谁会看、看了有账；没有这三样，他只能全员不给，然后深夜让王师傅拿座机挨个打。

权限设计水平的分水岭就在这里：低水平的系统在"全给"和"全不给"之间摇摆，高水平的系统把决策拆成可配置、可追溯的小格。

8.7 一张表：权限与审计能力清单

能力	当前状态	要点
两棵树交叉裁范围	已投产	组织六级 + 宿舍四级
多范围按“或”合并	已投产	带班又管楼时自然合并
55 个权限码	已投产	读与写分开、导入与删除单设
后端独立校验	已投产	前端隐藏不代替后端把门
六级角色天花板	已投产	学生端进不了管理端接口
12 条认证链	已投产	本地保底 + 外部多链
字段级脱敏	已投产	同条记录不同角色不同列
三层留痕	已投产	操作 + 展示 + 限流
导出名单留底	已投产	行数、字段、操作人全部入日志
自定义字段可见性	已投产	健康备注仅校医可看
二步验证	未投产	高敏感操作可接短信
自动定岗定权限	不做	岗位调整永远由人确认

8.8 三条关于权限的常见误解

误解一：权限代码写完就安全。代码层只保证“他能不能”，不保证“他该不该”。后者需要业务规则（学生不能代打卡）与审计日志（他确实只查了自己该看的）共同成立。安全不是一门技术、是一门“接口 + 规则 + 日志”三层都硬的管理能力。

误解二：管理员不需要审计。恰恰相反——管理员的日志要记得更详，因为他们的权限最大、失控代价最高。系统里所有管理员行为、尤其是“看原值”、“导出”、“重置口令”三类，均入日志且不对他们本人隐藏。

误解三：菜单不展示等同于无权限。前端把按钮隐藏后，用户直接接口提交依然能动手——真正的把门一定在后端。系统里每一个写接口都在服务层重新判断一次权限、不依赖前端传递的任何“他能看到什么”的信号。

8.9 收口：给学校的一件事

落点不需要采购任何新东西：下学期开学前，把本校宿舍系统的账号按两棵树各核一遍——每个账号问两个问题：他管的楼和他管的人在范围里都齐吗；他做的每一件事，出了错能不能在日志里还原到秒。 两个问题答不上来的账号，宁可先收一半权限，再让厂商补功能。

人是各安其位了。下一件事是这套系统里最不能出错的那张表——床。