05 · 架构 · 导出与权限
能看见一家店，不代表能导出全部会员
安全架构师把越权导出、权限继承和审计写成约束，先写禁止再写允许。他写应该怎样，安全测试证明没有旁路。
| 动作 | 允许 | 留下 |
|---|---|---|
| 按门店查询会员 | 该门店运营 | 查询人、时间、条件 |
| 导出手机号 | 单独授权，且有期限 | 文件水印、条数、审批单 |
| 总部看全量 | 不默认开放 | 每次申请的原因和范围 |
| 接口批量拉取 | 与页面同一条权限 | 拒绝记录，不能只藏按钮 |
安全架构师把便利需求翻译成失控后果
业务系统里最常见的安全事故不是外部入侵，是内部账号能导出不该导出的数据。安全架构师的特点是在设计阶段写约束：最小权限、权限不继承到导出、服务端强制、审计可追溯。只在前端藏起导出按钮，接口仍可用脚本拉全表，这种设计会被他退回。岗位不替代安全测试。他写应该怎样，测试证明实现没有旁路。
他也看身份生命周期是否被方案落地。离职账号、共用账号、实施期间的临时管理员，都要有到期日。没有到期日的管理员是项目结束后最大的洞。临时方便如果成为永久角色，他会在上线检查里单列，不并进「已知问题」。
导出为什么要单独授权
查询和导出的伤害不同。查询一次看到一页，导出一次带走全库。安全架构师要求导出是另一项权限，带审批、条数上限和水印。水印含导出人，便于泄露后追溯。审批不能是申请人自己。总部角色不自动拥有所有门店的导出，否则一个总部实习生等于全部会员。
审计字段至少有人、时间、条件、条数、结果是成功还是拒绝。没有拒绝记录，以后无法知道谁在试。日志保留期按客户的合规要求写进方案，不写「日志看看再说」。
会员导出被当成日常按钮的那次
门店运营需要给一批会员发券，开发把导出放进了列表页，权限等于能看列表的人。安全架构师在评审用一个门店账号调了接口，去掉分页后返回了其他门店的手机号，因为查询条件只在页面上选了门店，服务端没校验。设计被改成：服务端按账号的门店范围过滤；导出必须走审批；单次上限五千并打水印；接口与页面同一策略。安全测试后来用脚本复测无分页参数，确认越权不再返回数据。
运营觉得多了一步审批。这一步是故意的。发券的名单可以在审批后的文件里完成，不需要每个店员永久拥有全库下载权。导出文件的保存位置他也写进约束。文件只能进审批过的目录，不能由个人邮箱转发出去。转发一旦发生，水印仍能追溯，但审批链已经断了。他要求邮件网关或操作说明至少挡住一种最常见的转法，并在演练里试一次。测试用的生产数据也要审批，不能把会员表拷进开发库只因为查问题方便。查问题需要多少行就取多少行，脱敏规则写清楚，调试结束删除。
实施期间的管理员账号，安全架构师要求写上关闭日期，并放进上线检查。日期到了还在使用，视为未完成，而不是遗留优化。共用账号「实施」如果继续留在生产，审计里所有危险操作都会变成同一个人，出事无法追到班次。