平台网站的用户角色和权限边界应该怎么确认？

很多项目直到上线前才发现，页面上的按钮虽然分开了，接口却没有分开；租户管理员能看到别家数据；编辑和审核落在同一个账号上；外包人员项目结束后仍能登录。这些并不是“后台再配一下”就能解决的小问题。权限一旦和业务责任没有对齐，系统越往后改，牵动的数据、流程和接口就越多。

先确认谁对结果负责，不要让开发替业务拍板

红数科技参与这类权限梳理时，会先把决定权分开。业务负责人最清楚谁该做决定、谁承担后果；产品人员负责把流程和页面动作说清楚；安全、合规或数据负责人判断哪些数据和操作需要额外限制；开发把规则落实到页面、接口和数据查询；测试人员用正向和反向用例验证；最后由客户方指定的权限负责人确认。

服务方可以指出风险、整理矩阵、给出实现建议，但不能替客户决定“谁可以导出全部客户资料”或者“谁能跳过审核直接发布”。这类决定背后是管理责任，不只是软件设置。

在第一次权限会上，先把参与方和确认人定下来，通常比马上讨论角色名称更省时间。至少要明确：每条业务线谁说了算，涉及个人信息或重要业务数据时谁复核，技术实现由谁解释，测试结果由谁接受。没有明确确认人，权限表很容易在群里转一圈，最后默认按开发理解上线。

角色不是职位名称，而是一组稳定的工作责任

“运营”“客服”“管理员”都太宽。两名运营人员可能一个只编辑内容，另一个可以发布、下架和批量导出；同样叫客服，总部客服与入驻商家的客服能看到的数据范围完全不同。直接拿组织架构当角色表，往往会把岗位名称相同、责任不同的人绑在一起。

更稳妥的做法，是先把一项业务从开始到结束走一遍。谁创建，谁修改，谁提交，谁复核，谁执行，谁能撤回，出了问题谁查看记录。重复出现、长期稳定的责任，可以沉淀成角色；只在某个项目或某几天需要的权限，更适合做临时授权，不要为一个人永久增加角色。

角色太少，一个“管理员”会包揽所有敏感动作；角色太多，名称相近、长期无人维护，授权时又只能靠猜。判断是否需要拆分，可以看数据范围和业务后果。只要其中一项明显不同，就不宜强行合并。

一项权限至少要把五件事说清

只写“订单管理：有”是不够的。这里的“有”，可能只是看列表，也可能包括改价、退款、删除、导出和查看完整个人信息。真正可开发、可测试的权限描述，至少包含下面五项：

• ‎对象：内容、用户、订单、合同、报表、配置、日志，具体是哪一类数据或资源。
• ‎动作：查看、新建、编辑、提交、审核、发布、删除、导出、授权，不能笼统写“管理”。
• ‎数据范围：本人、本部门、本机构、本租户、指定项目，还是全平台。
• ‎生效条件：数据处于什么状态、金额或敏感程度是否达到复核条件、是否只能在指定环境或设备上操作。
• ‎有效时间：长期、项目期内、当班期间，还是审批后的几小时。

这五项放在一起，权限边界才不会停留在菜单层。比如“内容编辑”可以创建和修改本人负责栏目中的草稿，但不能直接发布；“内容审核”可以查看待审稿件并通过或退回，却不能悄悄改掉原稿；“租户管理员”可以停用本租户账号、分配平台预先允许的角色，但不能创建全平台角色，也不能跨租户查人。

一张早期权限矩阵可以先写到这个程度：

这只是用于讨论的起始表，让业务方先看到边界长什么样，再按自己的流程逐项修改。定稿时仍要落到具体资源、接口和数据范围，不能只停在栏目名称上。

高风险动作要单独拿出来谈

平台网站里，有些权限平时用得不多，一旦误用，影响却很难撤回。常见的包括批量导出、永久删除、直接发布、退款或资金操作、修改结算规则、重置他人身份凭据、分配管理员角色、关闭安全策略，以及跨租户查看数据。

这些动作不适合随着一个宽泛角色顺手发放。要逐项确认是否需要二次验证、两人复核、限定数据范围、限制有效期，以及能否撤销。尤其是给别人授权的权限，它决定的不是一个页面能不能打开，而是谁可以继续扩大权限。平台最高权限账号也不宜作为日常工作账号使用，应当单独保管，只在紧急处置时启用，并完整记录启用原因、操作人和结束时间。

职责分离也要落到系统里。经办与复核、配置修改与审批、业务操作与审计，哪些必须由不同账号完成，不能只靠制度提醒。系统如果允许同一个人先提交、再换个角色自己通过，流程表面完整，控制其实没有成立。

页面看不见，不等于没有权限

权限验收不能只看界面。把按钮隐藏，只能减少误操作，不能阻止有人直接调用接口。真正的权限判断应在服务端完成，而且每次请求都要判断当前账号能否对当前对象执行当前动作。

测试时要故意做两类尝试。第一类是横向越权：把地址或请求里的订单编号、用户编号、租户编号换成另一个，看看能不能读到或修改不属于自己的数据。第二类是纵向越权：普通账号直接请求管理员接口，或者绕过页面去调用导出、审核、删除等功能。OWASP 在 API 安全风险中分别把对象级授权失效和功能级授权失效列为重点问题，这正是平台项目中不能只验页面的原因。

还有一个很实用的原则：没有明确允许，就拒绝。新功能、新接口、新角色上线时，不应自动继承一大片权限，再等出问题后收紧。权限校验失败也不能只返回“操作失败”，后台需要留下足够记录，方便判断是正常拦截、配置错误，还是有人在尝试越权。

权限不是上线前确认一次就结束

账号从开通到停用，至少会经历入职或入驻、岗位调整、临时支援、长期不用、离职或合作结束。权限管理要跟着这个过程走。谁申请、谁批准、何时生效、何时复核、何时自动到期，都应在方案里写清楚。

临时权限尤其容易被忘掉。更换岗位后沿用旧角色，常常形成“权限只增不减”；共享账号则让日志失去责任人。比较可靠的做法是账号一人一用，临时授权必须带到期时间，岗位变化触发重新审核，离职或合作终止时同步停用账号、会话和访问密钥。长期不用的账号也要定期清理，而不是等到安全检查时才发现。

审计日志需要回答几件朴素的事：谁在什么时间，从哪里，对哪条数据做了什么，操作前后发生了什么变化，结果是否成功。权限新增、角色变更、批量导出、删除、发布、审批和安全配置修改通常都应留痕。日志由谁能看、保存多久、能否删除，同样属于权限边界，不能留到上线后再决定。

项目验收时，至少应拿到这些成果

权限讨论如果只留下会议纪要，开发和验收仍然会各自理解。较完整的交付通常包括：

• 一份角色清单，写明每个角色的责任、适用人员和互斥角色。
• 一份权限矩阵，细到资源、动作、数据范围、条件和有效期。
• 一份高风险操作清单，写明二次验证、复核、撤销和留痕要求。
• 一套账号全周期规则，覆盖开通、变更、临时授权、定期复核和停用。
• 一组权限测试用例，既测允许的操作，也测横向越权、纵向越权和跨租户访问。
• 一份审计日志字段与查询权限说明，确保出了问题能查清，不让日志本身变成新的泄露入口。

验收时不要只问“这个角色能不能用”，还要问“它不该做的事，系统是否真的拦住了”。用业务账号逐项走流程，再直接检查接口和数据范围；修改角色配置后重新跑一遍关键用例；随机抽取权限变更和敏感操作，确认日志能对应到具体账号。做到这一步，权限矩阵才从文档变成系统里的真实边界。

我国现行规则已经把这件事说得很清楚。《个人信息保护法》第五十一条要求个人信息处理者合理确定操作权限；自 2025 年 1 月 1 日起施行的《网络数据安全管理条例》也明确提出访问控制、安全认证等措施。对平台网站来说，这并不意味着套一份固定模板就算合规。真正需要确认的是：系统里哪些人会接触哪些数据，为什么需要接触，能做到哪一步，超过边界时由谁复核，事后能不能查清。

角色会随着业务调整，权限表也会变。把确认责任、变更流程和验证方法留下来，以后新增业务线、接入租户或开放接口时，团队才知道该找谁确认，也能证明这项权限没有放大到不该去的地方。

核验依据

• 《中华人民共和国个人信息保护法》，重点参见第六条、第五十一条。
• 《网络数据安全管理条例》，2025 年 1 月 1 日起施行。
• NIST SP 800-53 Rev. 5，重点参见账户管理、访问控制、职责分离、最小权限与审计相关控制项。
• OWASP Authorization Cheat Sheet，包括最小权限、默认拒绝、逐次请求校验和授权测试建议。
• OWASP API Security Top 10 – 2023，重点参见对象级授权失效与功能级授权失效。
• 国家标准全文公开系统，可检索 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》。