第三章：权限需求的业务问题拆解
在任意中大型系统中，权限模块往往是技术债务积累最快、业务投诉最密集的区域。本章围绕三个核心视角——当前权限痛点、缺失权限带来的风险、业务目标与权限约束的平衡——展开结构化拆解，帮助产品经理在PRD阶段系统性暴露问题，而非等到线上故障或合规审计时才被动响应。
核心观点：权限需求的产品化拆解不是安全工程师的事，而是业务价值与风险控制的联合校验。拆解不彻底，会导致RICE评估失真、验收标准无效。
3.1 当前系统中的权限痛点——从业务场景中定位问题
实际工作中最常见的权限痛点往往不是“没有权限”，而是权限设置与业务流矛盾。以下三个典型场景几乎贯穿所有B端产品：
- 角色颗粒度过粗：一个“管理员”角色同时拥有订单审批、系统配置、数据导出权限，导致敏感操作无法隔离。
- 权限变更滞后：员工转岗后原角色未回收，新人无法立即获得必要权限，依靠临时“密码共享”维持工作。
- 无临时授权机制：跨部门协作时只能通过管理员手动授予高危权限，事后忘记回收，形成长期后门。
这些痛点不解决，产品功能越多，权限失控风险越高。产品经理应在PRD的“业务场景”章节中前置记录上述场景，并标注影响用户量和发生频次。
常见弯路：产品经理把权限痛点直接写成“需要RBAC模型”或“需要AOP切面”。这些是技术方案，不是业务问题拆解。正确的做法是描述“某人无法在合理时间内做完某件事”或“某人可以越权做本不该做的事情”。
3.2 缺失权限带来的风险——业务与合规的双向打击
权限缺失或设计缺陷引发的风险可分为三个层次，产品经理需要用风险矩阵量化评估：
| 风险层 | 典型表现 | 潜在损失（示例） |
|---|---|---|
| 业务运营 | 员工越权修改订单价格、误删客户数据 | 订单损失￥50K+，客服赔付 |
| 合规审计 | 违反GDPR或等保三级，无法通过年报审计 | 罚款￥200K~￥2M，停业整顿 |
| 品牌信任 | 用户数据泄露，媒体负面报道 | 市值波动，客户流失率＞15% |
建议产品经理在PRD中使用风险矩阵模板（如下），将每个缺失的权限点映射到影响等级：
权限缺失点：销售代表可导出全部客户电话
影响等级：严重（可导致批量骚扰投诉）
发生概率：高（每天约200次导出请求）
风险暴露值 = 严重程度 × 概率 = 4×5 = 20（>15需本周修复）
实战贴士：风险暴露值超过15时，建议将该权限需求标记为P0（阻塞发布），并优先进入RICE评估的Reach和Impact计算。
3.3 业务目标与权限约束的平衡——从“全有或全无”到“最小够用”
过度约束会扼杀业务效率，过度开放会带来风险。平衡的关键是建立分级授权规则，而非一刀切的“允许/拒绝”。下表对比了三种常见平衡策略：
- 基于上下文的授权：同一角色在不同时段、IP、操作频次下拥有不同权限（如：凌晨禁止批量删除）。
- 审批式临时授权：允许普通员工申请“提升权限4小时”，由直属上级审批，到期自动回收。
- 数据脱敏与限流：保持查询权限开放，但对敏感字段进行脱敏，且限制单次导出行数。
产品经理在PRD中应针对每个权限需求明确写出业务目标权重与约束边界。例如：
权限点：客服支持“查看用户身份证号”
业务目标权重：高（影响首次响应时长，目标降低30%）
约束边界：仅限工单状态为“已实名认证”时显示最后4位，全号需二级审批
拆解成果输出示例：经过本章拆解，可在PRD中形成一张《权限业务问题清单表》，包含：痛点ID、场景描述、影响用户数、风险等级、建议平衡策略。这个清单将直接用于第4章的RICE优先级评估。