同一套政务系统同时对接区级主管部门、街道执行层与第三方运维团队，是政务项目里最常见的角色组合。等保三级把安全要求框定了，但权限模型怎么拆、粒度做到多细，表里没有答案——而它恰恰直接决定了后续每一次组织调整的改造量。
先按「数据可见范围」切，再按「角色」切
权限模型的第一个误区是按人配权限。人的岗位会变、借调会发生，按人配置的权限在半年后就是一本烂账。我们的做法是先按数据可见范围切出边界：区级看全域汇总，街道只看本辖区明细，第三方运维只看技术运行数据、不碰业务数据。范围是相对稳定的，岗位变化只需要调整人与范围的映射。
粒度决定改造量
权限粒度做粗了，后期每一次「某街道想看某个专项数据」的需求都要发版；做细了，配置本身成为运维负担。实践中比较可持续的粒度是三层：功能菜单级（能进哪个页面）、数据行级（能看到哪些条目）、字段级（敏感字段是否脱敏）。三层全部可配置，且配置入口收敛到管理端的一个模块里。
第三方运维的隔离实践
第三方运维的权限隔离最容易被忽略。运维团队需要看服务运行状态、日志与配置，但不需要看业务数据。我们的做法是给运维单独划一层「技术视图」：能看接口健康度、错误日志与部署版本，业务表的数据在技术视图里全部脱敏或不可见。运维交接换厂商时，只需要回收这一层的账号，业务权限一点不受影响。
等保三级的三权分立别省
等保三级要求系统管理员、安全管理员与审计管理员三权分立。很多项目为了省事让一个人兼三个角色，测评时是硬伤，运维时也是风险。我们在权限模型里把三权做成三个内置角色，分别锁定系统配置、权限策略与审计日志的入口，互不可见。这个结构不增加多少开发量，却让测评与日常审计都顺了很多。
写进交付物
权限模型不能只存在于数据库的几张表里。我们把它写成一份随源代码交付的权限矩阵文档：每个角色在每层数据上的可见与可操作项，逐条列明。后续甲方信息化部门换人、运维外包换厂商，这份文档就是权限治理的底账。
延伸：行级权限的性能与维护账
数据行级权限做细之后，性能与维护是两笔隐性成本。性能上，行级过滤依赖组织树的递归查询，街道层级深的区域要提前设计数据冗余或物化视图；维护上，组织架构调整（街道合并、辖区划转）会牵动行级规则，要做成批量迁移而不是逐条手改。这两笔账在权限模型设计阶段就要估进去，否则行级权限上线半年后会变成没人敢动的历史包袱。