# 丹阳公益婚恋服务平台 # V1.0 运营管理后台与组织权限体系详细设计 版本：V1.0 适用范围：平台管理员、妇联、工会、公益服务中心、公益红娘、审核员、活动管理员、风控员、志愿者 核心目标：统一后台、统一账号、按角色授权、按组织隔离、敏感权限最小化、关键操作可审计 --- # 第一章 设计目标 V1.0后台不是单纯的数据管理工具。 它必须同时承担： - 用户管理 - 资料审核 - 匹配规则管理 - 公益红娘管理 - 活动管理 - 举报风控 - 组织管理 - 工作人员管理 - 权限管理 - 数据统计 - 安全审计 后台设计必须解决以下核心问题： 1. 谁可以登录 2. 谁可以看到哪些菜单 3. 谁可以看到哪些用户 4. 谁可以处理哪些任务 5. 谁可以查看敏感信息 6. 不同组织之间如何隔离 7. 多角色人员如何授权 8. 工作人员离职如何立即失效 9. 重大操作如何审计 10. 如何避免“一个管理员什么都能看” 核心原则： > **一个后台，一套账号，多角色、多权限、多组织数据范围。** --- # 第二章 V1后台总体架构建议 推荐： > **公益红娘工作台、运营管理后台、平台管理后台使用同一个响应式Web应用。** 通过： ```text 账号 + 角色 + 权限 + 数据范围 ``` 决定用户看到什么。 而不是开发三套完全独立后台。 --- # 第三章 为什么推荐统一后台 统一后台可以减少： - 三套登录 - 三套用户体系 - 三套权限代码 - 三套组件 - 三套部署 - 三套维护 技术上统一。 业务上： > 不同角色看到不同工作界面。 --- # 第四章 后台入口 统一： ```text /admin ``` 或正式域名： ```text https://admin.example.com ``` 登录后根据权限进入对应首页。 --- # 第五章 Operator统一账号模型 所有工作人员统一： ```text operators ``` 包括： - 平台管理员 - 机构管理员 - 审核员 - 公益红娘 - 活动管理员 - 风控员 - 志愿者 不要为红娘、管理员、志愿者分别做独立账号表。 --- # 第六章 Operator基本属性 至少包含： ```text operatorId name organizationId status roles permissions lastLoginAt ``` --- # 第七章 OperatorStatus 建议： ```text active disabled locked expired ``` 含义： ### active 正常。 ### disabled 人工停用。 ### locked 安全锁定。 ### expired 临时账号已到期。 --- # 第八章 一个Operator可以拥有多个角色 例如： 某公益服务中心负责人： ```text organization_admin + activity_manager ``` 某工作人员： ```text matchmaker + activity_manager ``` 允许。 但权限最终取： > 已授权角色的权限合集 + 数据范围限制。 --- # 第九章 角色与权限必须分离 角色： ```text matchmaker ``` 是一组权限模板。 权限： ```text matchmaker.service.view ``` 才是真正的操作能力。 不要在代码里写： ```text if role == matchmaker ``` 决定所有行为。 --- # 第十章 V1默认角色 建议： ```text super_admin platform_admin organization_admin reviewer matchmaker activity_manager risk_operator volunteer data_viewer ``` --- # 第十一章 super_admin 定位： > 平台最高技术/系统管理权限。 权限包括： - 系统配置 - 组织管理 - 权限管理 - 高级安全管理 不建议日常运营人员使用此账号。 --- # 第十二章 platform_admin 负责平台日常运营。 可管理： - 用户 - 审核 - 红娘 - 活动 - 风控 - 统计 但是否有： > 完整身份证查看 仍应单独授权。 --- # 第十三章 organization_admin 负责某一个参与组织。 例如： - 妇联 - 工会 - 公益服务中心 只能管理： > 本组织授权范围内的数据和工作人员。 --- # 第十四章 reviewer 负责： > 用户资料审核。 可以： - 查看审核资料 - 领取审核 - 通过 - 退回 - 拒绝 不能： - 修改平台权限 - 查看聊天 - 任意封禁用户 - 管理其他机构 --- # 第十五章 matchmaker 负责： - 红娘服务 - 查看服务用户必要资料 - 系统候选 - 人工推荐 - 跟进 - 活动推荐 不能： - 查看身份证 - 查看聊天 - 直接封禁 - 修改匹配算法 - 管理权限 --- # 第十六章 activity_manager 负责： - 创建活动 - 编辑活动 - 报名审核 - 签到管理 - 活动统计 - 现场异常上报 不能： - 查看聊天 - 查看身份证 - 修改用户匹配关系 - 修改平台权限 --- # 第十七章 risk_operator 负责： - 举报 - 风险事件 - 用户风险分析 - 风控处置 - 申诉处理 根据权限可以： - 限制 - 暂停 - 封禁 敏感聊天访问： > 仍应独立权限控制。 --- # 第十八章 volunteer 最低权限角色。 用于： - 活动签到 - 简单现场辅助 只应看到： > 当前活动必要信息。 --- # 第十九章 data_viewer 用于： > 只读统计。 例如机构负责人只看运营数据。 不能： - 修改用户 - 审核 - 封禁 - 查看敏感资料 --- # 第二十章 权限模型 建议采用： ```text RBAC + Data Scope + Sensitive Permission ``` 三层。 --- # 第二十一章 第一层：RBAC 决定： > 能不能做某类操作。 例如： ```text activity.create ``` --- # 第二十二章 第二层：Data Scope 决定： > 可以对哪些数据做。 例如同样拥有： ```text activity.view ``` 平台管理员： > 全平台。 机构管理员： > 本机构。 --- # 第二十三章 第三层：Sensitive Permission 决定： > 是否允许查看高敏感字段。 例如： ```text user.sensitive.identity.view ``` 必须单独授权。 --- # 第二十四章 数据范围枚举 建议： ```text platform organization assigned self activity_scope ``` --- # 第二十五章 platform范围 可以访问： > 全平台符合权限的资源。 主要： - super_admin - platform_admin - 特定risk_operator --- # 第二十六章 organization范围 只能访问： ```text resource.organization_id = operator.organization_id ``` --- # 第二十七章 assigned范围 只访问： > 明确分配给自己的任务。 例如红娘： ```text service.assigned_operator_id = currentOperator ``` --- # 第二十八章 self范围 只管理： > 自己账号相关数据。 --- # 第二十九章 activity_scope 用于临时工作人员。 例如： 志愿者账号只允许： ```text activity_id IN operator_activity_assignments ``` --- # 第三十章 Data Scope不能靠前端实现 错误： 前端不显示其他组织。 正确： 服务端SQL/Service就必须加范围。 否则用户手工改URL仍可能访问。 --- # 第三十一章 组织模型 组织表： ```text organizations ``` 类型： ```text platform women_federation trade_union charity_center volunteer_team civil_affairs_partner other ``` --- # 第三十二章 组织层级 V1建议： > 最多支持简单父子组织。 例如： ```text 平台运营主体 │ ├── 妇联 ├── 工会 └── 公益服务中心 ``` 不建设复杂无限级政府组织树。 --- # 第三十三章 organization字段建议 ```text id parent_id name type status contact created_at ``` --- # 第三十四章 OrganizationStatus ```text active disabled ``` disabled后： - 组织人员不能继续新业务 - 现有服务进入转交 - 数据不删除 --- # 第三十五章 跨组织用户数据问题 用户属于： > 平台用户。 而不是天然属于某个妇联/工会。 因此： > 不建议给User加唯一organization_owner。 --- # 第三十六章 组织和用户的关系 应该通过： - MatchmakerService - ActivityRegistration - ReviewTask分配 - Organization授权 建立业务关系。 而不是： ```text user.organization_id ``` 直接把用户“归属”某组织。 --- # 第三十七章 为什么用户不应归属组织 一个用户可能： - 参加工会活动 - 接受公益服务中心红娘帮助 - 被平台统一审核 因此用户是： > 平台主体数据。 组织只有： > 特定服务访问权。 --- # 第三十八章 后台一级菜单 统一建议： ```text 工作台 用户管理 资料审核 匹配管理 公益红娘 活动管理 举报风控 数据统计 组织人员 权限管理 系统设置 审计日志 ``` --- # 第三十九章 菜单动态生成 根据： ```text currentOperator.permissions ``` 动态显示。 没有： ```text risk.report.view ``` 就不显示： > 举报风控。 --- # 第四十章 工作台按角色变化 同一个： ```text /dashboard ``` 根据角色显示不同卡片。 --- # 第四十一章 Reviewer工作台 显示： ```text 待审核 已领取 今日已完成 退回待复审 ``` --- # 第四十二章 Matchmaker工作台 显示： ```text 新服务 待首次处理 今日待跟进 等待用户 服务中 ``` --- # 第四十三章 Activity Manager工作台 显示： ```text 报名中活动 待审核报名 今日活动 待签到 近期活动 ``` --- # 第四十四章 Risk Operator工作台 显示： ```text 高风险举报 待处理举报 风险用户 待处理申诉 ``` --- # 第四十五章 Platform Admin工作台 显示： ```text 待审核资料 待处理举报 红娘待分配 活动报名待审核 异常账号 ``` 不做炫酷大屏。 --- # 第四十六章 用户管理模块权限 建议： ```text user.list.view user.detail.view user.status.change user.sensitive.view user.relationship.summary.view user.activity.summary.view user.matchmaker.summary.view ``` --- # 第四十七章 用户列表默认字段 显示： ```text 用户ID 展示名 性别 年龄 区域 实名认证 资料审核 婚恋状态 账号状态 注册时间 ``` 不显示： - 完整手机号 - 身份证 - 聊天 - 举报详情 --- # 第四十八章 用户列表搜索 支持： ```text 用户ID 展示名 脱敏手机号/授权手机号搜索 ``` 手机号搜索： > 仅授权人员。 --- # 第四十九章 用户详情Tab 建议： ```text 基础信息 婚恋资料 审核记录 匹配摘要 活动摘要 红娘服务 账号状态 ``` 风险信息： > 有权限才出现。 --- # 第五十章 用户详情不展示完整聊天 明确禁止普通用户管理页面加： > 聊天记录Tab。 聊天只能在风控案件场景下按权限访问。 --- # 第五十一章 敏感身份入口 独立： ```text 查看实名信息 ``` 点击： > 权限校验 + 访问原因 + 审计。 --- # 第五十二章 默认脱敏 显示： ```text 姓名：张** 身份证：320***********1234 手机号：138****1234 ``` --- # 第五十三章 查看完整身份 只有： ```text user.sensitive.identity.full ``` 权限允许。 V1建议极少授权。 --- # 第五十四章 资料审核菜单 权限： ```text review.list.view review.claim review.process review.reject review.history.view ``` --- # 第五十五章 Reviewer只能处理审核 不能因为能看审核页： > 就拥有user.status.change。 --- # 第五十六章 审核任务数据范围 平台统一审核时： ```text platform ``` 如果未来机构自行审核： 可以按： > assigned / organization 控制。 V1建议核心实名资料审核由平台统一标准管理。 --- # 第五十七章 匹配管理菜单 权限： ```text match.stats.view match.list.view match.rule.view match.rule.manage match.rule.activate ``` --- # 第五十八章 普通管理员不需要看所有用户匹配详情 匹配详情属于较高隐私业务数据。 默认后台重点看： - 聚合统计 - 规则 - 异常 不是： > 谁喜欢了谁的全部流水。 --- # 第五十九章 查看特定Match 只在： - 用户投诉 - 风控 - 服务处理 等必要场景开放。 --- # 第六十章 Match Rule权限 只有少数平台角色： ```text match.rule.manage ``` 可以修改。 机构管理员不能修改全局算法。 --- # 第六十一章 公益红娘模块权限 ```text matchmaker.service.list matchmaker.service.view matchmaker.service.assign matchmaker.service.claim matchmaker.service.followup matchmaker.candidate.view matchmaker.recommend matchmaker.service.complete ``` --- # 第六十二章 红娘管理员 organization_admin若负责红娘： 可以： - 看本机构服务 - 分配本机构红娘 - 看工作量 不能： > 看其他机构服务。 --- # 第六十三章 活动管理权限 ```text activity.list activity.view activity.create activity.edit activity.publish activity.cancel activity.registration.view activity.registration.review activity.checkin activity.feedback.view activity.stats.view ``` --- # 第六十四章 发布和编辑分离 可以允许工作人员： > 创建活动草稿。 但只有负责人： ```text activity.publish ``` 可以正式发布。 降低误操作风险。 --- # 第六十五章 取消活动属于高风险权限 ```text activity.cancel ``` 必须： - 二次确认 - 原因 - 审计 --- # 第六十六章 志愿者只给 ```text activity.checkin ``` 和必要： ```text activity.registration.basic_view ``` 即可。 --- # 第六十七章 举报风控权限 建议细拆： ```text risk.report.list risk.report.view risk.report.process risk.user.view risk.user.warning risk.user.limit risk.user.suspend risk.user.ban risk.appeal.view risk.appeal.process risk.evidence.view message.content.review ``` --- # 第六十八章 为什么风控要细拆 “查看举报”和“永久封禁”不是一个风险等级。 例如初级风控员： 可以： - 查看 - 处理普通举报 但不一定拥有： > ban。 --- # 第六十九章 用户封禁建议双重保护 V1建议： 永久ban操作： - 二次确认 - 填写原因 - Audit 是否需要双人复核： > 初期可作为P1建议。 严重高风险时至少由高权限角色操作。 --- # 第七十章 聊天查看权限单独存在 ```text message.content.review ``` 不能因为： ```text risk.report.process ``` 就自动获得全部聊天读取。 --- # 第七十一章 风控聊天读取必须案件关联 正确： ```text Report ↓ Conversation Context ``` 错误： ```text 用户详情 ↓ 所有聊天 ``` --- # 第七十二章 组织人员菜单 权限： ```text organization.list organization.view organization.create organization.edit operator.list operator.create operator.edit operator.disable operator.role.assign ``` --- # 第七十三章 organization_admin人员权限 只能管理： ```text operators.organization_id = currentOrg ``` 不能新增平台管理员。 --- # 第七十四章 机构管理员不能给自己越权 例如本机构最大允许： ```text matchmaker activity_manager volunteer ``` 机构管理员不能通过角色接口： > 给自己super_admin。 服务端需要： > Role Assignment Boundary。 --- # 第七十五章 角色分配边界 每个管理角色定义： ```text assignable_roles ``` 例如： organization_admin可分配： ```text matchmaker activity_manager volunteer data_viewer ``` 不能分： ```text platform_admin super_admin ``` --- # 第七十六章 权限管理菜单 只对： ```text permission.manage ``` 开放。 建议V1只有： - super_admin - 指定platform_admin 拥有。 --- # 第七十七章 系统角色 默认角色： ```text system_role = true ``` 不允许删除。 可以： > 克隆后创建自定义角色。 --- # 第七十八章 自定义角色 例如： ```text 工会活动负责人 ``` 可以从： ```text activity_manager ``` 复制后精简权限。 --- # 第七十九章 不建议V1做复杂ABAC 不要建设： - 表达式权限引擎 - 策略语言 - 动态属性规则系统 RBAC + 数据范围足够。 --- # 第八十章 权限命名规范 统一： ```text module.resource.action ``` 例如： ```text user.detail.view activity.registration.review risk.user.ban match.rule.manage ``` --- # 第八十一章 权限不能按按钮命名 错误： ```text button_123 ``` 正确： > 表达业务能力。 --- # 第八十二章 权限后端统一注解/中间件 例如： ```text @RequirePermission("activity.publish") ``` 或框架对应机制。 避免Controller手写大量： ```text if role... ``` --- # 第八十三章 数据范围服务 建议独立： ```text DataScopeService ``` 输入： ```text operator resourceType ``` 输出可访问条件。 --- # 第八十四章 示例：红娘服务查询 红娘： ```text assigned_operator_id = me ``` 机构管理员： ```text organization_id = myOrg ``` 平台管理员： > 无组织限制。 --- # 第八十五章 示例：活动列表 志愿者： > 只看被分配活动。 活动管理员： > 本组织活动。 平台管理员： > 全部。 --- # 第八十六章 用户数据访问不能简单按机构过滤 再次强调： 用户是平台用户。 机构只能通过： > 具体服务关系 获取必要资料。 --- # 第八十七章 OrganizationAccessGrant建议 为未来跨组织协作，可预留： ```text organization_access_grants ``` 但V1如果业务简单： > 暂不必建复杂授权表。 先通过业务对象关联授权。 --- # 第八十八章 用户与红娘的数据范围 红娘可看用户完整Matchmaker DTO的前提： ```text 存在有效service AND service.assigned_operator = currentOperator ``` --- # 第八十九章 用户与活动管理员的数据范围 活动管理员可看报名必要资料的前提： ```text user registered activity AND activity belongs to currentOrg / authorized ``` --- # 第九十章 用户与审核员的数据范围 审核员可以看： > 当前审核任务必要资料。 不能因此浏览用户全部红娘、活动、聊天历史。 --- # 第九十一章 用户与风控员的数据范围 风控员基于： - Report - RiskEvent - Appeal 访问必要资料。 --- # 第九十二章 Data Minimization必须在后台体现 不是只有用户端隐私。 后台也应做到： > 每个角色只看完成任务所需要的信息。 --- # 第九十三章 后台顶部Header 显示： ```text 当前组织 当前用户 通知 退出 ``` 不需要： - 天气 - 时间大屏 - 欢迎词大Banner --- # 第九十四章 Sidebar 宽度： ```text 220～240px ``` 折叠： > 可选。 桌面V1优先1280+。 --- # 第九十五章 后台页面统一结构 ```text PageHeader ↓ FilterBar ↓ Content ↓ Pagination ``` --- # 第九十六章 表格原则 默认： ```text 20条/页 ``` 可选择： ```text 20 50 ``` 100可作为技术支持但不必前台突出。 该分页属于UX配置，不是业务硬规则。 --- # 第九十七章 表格操作 每行最多： ```text 查看 处理 更多 ``` 不要一行放8个按钮。 --- # 第九十八章 高风险按钮 例如： ```text 封禁 取消活动 停用工作人员 ``` 放： > 更多 或详情页。 并二次确认。 --- # 第九十九章 后台状态色 统一使用： - 正常：绿色 - 待处理：橙色 - 风险：红色 - 普通：蓝/灰 不能所有异常都一片大红。 --- # 第一百章 数据统计模块权限 ```text analytics.overview.view analytics.user.view analytics.match.view analytics.activity.view analytics.matchmaker.view analytics.risk.view ``` --- # 第一百零一章 机构统计范围 机构管理员只能看： > 本机构参与产生的运营数据。 例如： - 本机构活动 - 本机构红娘服务 不能看全平台完整用户数据。 --- # 第一百零二章 平台统计 platform_admin可看： - 用户 - 匹配 - 活动 - 红娘 - 风控 全平台汇总。 --- # 第一百零三章 数据导出权限 建议： ```text data.export ``` 单独权限。 不要： > 能看列表就能导出。 --- # 第一百零四章 为什么导出单独授权 Web页面： > 有访问控制。 Excel下载后： > 很难继续控制传播。 因此导出风险更高。 --- # 第一百零五章 V1限制导出范围 优先支持： - 活动执行脱敏名单 - 必要运营统计 不提供： > 全量用户数据库导出。 --- # 第一百零六章 导出内容必须脱敏 例如活动： ```text 活动编号 展示名 手机号后四位 报名状态 签到状态 ``` --- # 第一百零七章 导出审计 记录： ```text operator export_type filters row_count time ``` 敏感导出建议： > 水印。 --- # 第一百零八章 Audit模块菜单 权限： ```text audit.view audit.sensitive.view audit.export ``` --- # 第一百零九章 普通管理员是否看Audit 可以看： > 自己组织的普通操作日志。 高敏感日志： > 平台安全角色。 --- # 第一百一十章 Audit记录操作 至少： ```text 登录 审核 用户状态修改 红娘分配 活动发布/取消 举报处理 风控处置 权限变更 工作人员创建/停用 敏感数据访问 系统配置修改 ``` --- # 第一百一十一章 Audit不可由普通后台删除 审计日志： > 不提供删除按钮。 --- # 第一百一十二章 SensitiveAccessLog 与普通Audit分开。 记录： ```text 谁 查看谁 什么敏感数据 为什么 什么时候 ``` --- # 第一百一十三章 敏感访问理由 可使用标准： ```text 身份异常核验 举报调查 申诉处理 依法配合 其他 ``` 其他需要填写说明。 --- # 第一百一十四章 工作人员登录安全 V1至少： ```text 账号+密码 强密码 登录限频 失败锁定 Session超时 停用实时失效 ``` --- # 第一百一十五章 MFA 建议优先给： ```text super_admin platform_admin risk_operator（高权限） ``` 启用。 如果V1研发周期紧： > P1。 但架构预留。 --- # 第一百一十六章 Session有效期 工作人员后台建议： > 比普通小程序更严格。 例如： ```text 空闲一定时间重新认证 ``` 具体时长待安全配置确定。 不要在业务代码写死。 --- # 第一百一十七章 高敏感操作再认证 P1可考虑： > 查看完整身份证 / 修改权限 / 永久封禁 要求再次输入密码或MFA。 --- # 第一百一十八章 临时志愿者账号 支持： ```text expires_at ``` 活动结束后： > 自动expired。 --- # 第一百一十九章 离职流程 工作人员离职： ```text operator.status = disabled ↓ 撤销所有Session ↓ 停止API权限 ↓ 转交服务 ↓ 审计 ``` --- # 第一百二十章 红娘离职服务转交 系统提示： > 当前仍有18个未完成服务。 必须先： - 批量重新分配 - 或管理员接管 不能只停账号。 --- # 第一百二十一章 机构人员停用 机构管理员可以停： > 本机构普通人员。 不能停： > 平台管理员。 --- # 第一百二十二章 平台管理员停用机构管理员 平台权限允许。 停用后： > 该组织需重新指定负责人。 --- # 第一百二十三章 后台通知中心 工作人员通知： ```text 新审核任务 新举报 红娘任务分配 活动报名待审核 用户风险变化 权限/账号安全 ``` --- # 第一百二十四章 通知按职责发送 不要： > 每个管理员都收到所有消息。 例如： 活动报名： > 活动管理员。 举报： > 风控员。 审核： > 审核员。 --- # 第一百二十五章 工作人员个人待办 建议： ```text GET /operator/tasks ``` 统一返回： ```text review matchmaker activity risk ``` 属于自己的待办。 --- # 第一百二十六章 是否建设通用工单系统 V1不需要。 各业务有自己的Task实体。 Dashboard统一聚合即可。 --- # 第一百二十七章 平台超级管理员红线 即使是super_admin： > 也不应该默认在普通页面看全部私人聊天。 技术超级权限： ≠ 日常业务合理权限。 --- # 第一百二十八章 Break Glass机制建议 未来针对极特殊安全事件，可以有： > 紧急访问。 例如高级安全负责人临时访问某敏感数据。 必须： - 填写原因 - 强审计 - 可复核 V1可先预留理念，不一定做复杂系统。 --- # 第一百二十九章 系统设置权限 ```text system.config.view system.config.manage ``` 可配置： - 推荐数量 - 活动功能开关 - 红娘功能开关 - 图片上限 - 风控基础配置 --- # 第一百三十章 不允许普通运营修改技术Secret 后台系统设置不要暴露： - 数据库密码 - 微信Secret - JWT Secret - 云密钥 这些属于部署Secret。 不是运营配置。 --- # 第一百三十一章 Feature Flag 后台可见： ```text 活动服务 红娘服务 图片聊天 ``` 等业务开关。 --- # 第一百三十二章 系统维护模式 只有高权限人员： ```text system.maintenance.manage ``` 可开启。 开启： > 用户端进入维护页。 必须二次确认。 --- # 第一百三十三章 用户账号状态修改 普通后台不能随意： ```text normal → banned ``` 必须走： > RiskAction。 用户管理页可以提供： > 查看状态 但封禁动作进入风控流程。 --- # 第一百三十四章 为什么不能User页面直接改状态 这样能保证： - 有原因 - 有风控记录 - 可申诉 - 可审计 不会出现管理员随手改数据库状态。 --- # 第一百三十五章 用户资料人工修改 V1后台原则： > 工作人员不直接替用户修改婚恋资料。 审核员只能： - 通过 - 退回 用户本人修改。 --- # 第一百三十六章 特殊代录场景 如果未来服务老年/特殊用户需要工作人员代录： 必须独立： > Assisted Entry流程。 V1普通后台不提供。 --- # 第一百三十七章 系统内部用户备注 是否允许管理员随意写“内部备注”？ 建议非常谨慎。 只允许业务模块已有： - 审核备注 - 红娘跟进 - 风控记录 - 活动异常 不要增加一个： > 所有人都能写的“用户备注”。 容易形成不当标签。 --- # 第一百三十八章 组织权限矩阵概览 | 功能 | 平台管理员 | 机构管理员 | 审核员 | 红娘 | 活动管理员 | 风控员 | 志愿者 | |---|---:|---:|---:|---:|---:|---:|---:| | 用户基本列表 | 是 | 有限 | 审核相关 | 服务相关 | 报名相关 | 风控相关 | 否 | | 实名敏感信息 | 单独权限 | 否 | 必要脱敏 | 否 | 否 | 单独权限 | 否 | | 资料审核 | 可 | 按授权 | 是 | 否 | 否 | 否 | 否 | | 红娘服务 | 管理 | 本机构 | 否 | 是 | 否 | 必要摘要 | 否 | | 活动管理 | 管理 | 本机构 | 否 | 推荐活动 | 是 | 必要摘要 | 签到 | | 举报风控 | 管理 | 默认否 | 否 | 转交 | 转交 | 是 | 转交 | | 聊天正文 | 默认否 | 否 | 否 | 否 | 否 | 案件授权 | 否 | | 权限管理 | 指定 | 有限 | 否 | 否 | 否 | 否 | 否 | | 统计 | 全平台 | 本机构 | 自身工作 | 自身服务 | 本机构活动 | 风控 | 否 | --- # 第一百三十九章 机构管理员的数据范围 核心： > 本组织产生/被授权处理的业务。 例如： ```text 本机构活动 本机构红娘服务 本机构工作人员 ``` 不自动获得： > 全平台婚恋用户库。 --- # 第一百四十章 平台管理员的数据范围 平台管理需要全局运营能力。 但敏感字段仍： > 单独权限。 --- # 第一百四十一章 审核员的数据范围 审核任务。 不是： > 全平台自由搜索用户。 --- # 第一百四十二章 风控员的数据范围 风险案件。 可以根据案件扩大必要上下文。 但每一步仍遵守： > 最小必要。 --- # 第一百四十三章 跨机构红娘服务 如果用户申请平台统一红娘服务： 管理员可把Service分配给某合作机构。 此时： > 该机构只获得该Service必要的数据访问。 --- # 第一百四十四章 Service结束后访问权限 服务完成后： 红娘是否无限期继续查看用户？ 建议： > 不应。 完成后保留服务历史摘要，但对完整婚恋资料的实时访问应按业务需要收缩。 V1可以先做到： > 已完成服务只读。 未来再进一步做访问期限。 --- # 第一百四十五章 活动结束后志愿者权限 活动结束： > 临时账号过期。 不能继续查看历史报名名单。 --- # 第一百四十六章 数据访问期限思想 权限不仅是： > “有没有”。 未来还应考虑： > “什么时候还有”。 V1重点先覆盖临时活动账号。 --- # 第一百四十七章 后台列表URL状态 筛选写Query： ```text /reviews?status=pending&page=2 ``` 便于刷新恢复。 --- # 第一百四十八章 详情页必须URL可恢复 例如： ```text /admin/users/{id} /admin/reviews/{id} /admin/reports/{id} ``` 刷新后重新请求。 不能靠上一页传对象。 --- # 第一百四十九章 后台401 Session过期： > 回登录。 如果页面有未保存表单： 优先保存非敏感草稿或提示。 --- # 第一百五十章 后台403 显示： > 你没有访问该功能的权限。 不要： > 白屏。 --- # 第一百五十一章 数据范围403 例如机构管理员手改其他组织activityId： 返回： ```text ORGANIZATION_SCOPE_DENIED ``` --- # 第一百五十二章 敏感权限403 返回： ```text SENSITIVE_ACCESS_DENIED ``` --- # 第一百五十三章 Operator账号异常 disabled： > 当前账号已停用，请联系管理员。 locked： > 当前账号因安全原因暂时锁定。 --- # 第一百五十四章 机构停用 组织被停用： 其Operator不能继续普通业务。 服务端登录/请求检查： ```text organization.status ``` --- # 第一百五十五章 组织停用后的在途任务 管理员必须处理： - 红娘服务转交 - 活动负责人调整 - 未完成工作 不能直接删除组织。 --- # 第一百五十六章 组织删除原则 不物理删除已有业务组织。 采用： ```text disabled ``` 历史Audit和活动仍能关联。 --- # 第一百五十七章 角色删除原则 系统角色： > 不删除。 自定义角色如果已有人使用： > 先解除关联或禁用。 建议roles增加： ```text status ``` --- # 第一百五十八章 权限变更实时生效 管理员撤销某Operator： ```text risk.user.ban ``` 下一次请求： > 立即不能使用。 不要等重新登录。 --- # 第一百五十九章 权限缓存 可以Redis缓存： ```text operator_permissions:{id} ``` 权限修改后： > 立即失效。 --- # 第一百六十章 Session与权限分离 Token不建议把全部权限永久写死到长周期JWT中。 否则权限改了： > 老Token还有效。 可： - 短Token - 权限版本 - Redis Session 确保及时生效。 --- # 第一百六十一章 Operator权限版本 可增加： ```text permission_version ``` 角色变化： ```text version +1 ``` Token/Session发现版本不一致： > 重新加载权限。 --- # 第一百六十二章 登录日志 建议： ```text operator_login_logs ``` 记录： - operator - IP - User Agent - 成功/失败 - 时间 也可纳入Security Log。 --- # 第一百六十三章 异常登录提醒 P1： 如果： - 新设备 - 异常IP - 短时间多次失败 提醒管理员或本人。 --- # 第一百六十四章 Admin Header当前组织切换 如果某平台工作人员被授权多个组织： 可以： > 切换工作上下文。 普通机构人员： > 固定组织。 V1如无多组织Operator需求，可暂不做切换。 --- # 第一百六十五章 组织切换不能改变实际权限 切换只是： > 数据上下文。 不能通过切组织获得未授权范围。 --- # 第一百六十六章 后台搜索全局能力 不建议做一个： > 全局搜人/手机号/聊天/举报 超级搜索。 风险太高。 各业务模块： > 在本模块内搜索。 --- # 第一百六十七章 用户搜索手机号 只有特定权限： ```text user.phone.search ``` 才能使用。 返回结果仍脱敏。 --- # 第一百六十八章 身份证搜索 V1原则： > 普通后台不提供。 确因实名认证异常需要： 使用Identity模块受控查询。 --- # 第一百六十九章 统计匿名化 统计页尽量用： > 聚合数据。 不需要显示具体用户。 --- # 第一百七十章 小样本隐私 如果某机构某条件只有1人： 后台统计也应避免为了图表直接暴露个体敏感信息。 V1可以先不做过细交叉分析。 --- # 第一百七十一章 后台批量操作 V1只谨慎支持： - 批量活动报名审核（建议后期） - 批量任务分配 不支持： > 批量封禁用户 作为普通功能。 --- # 第一百七十二章 批量敏感操作风险 任何批量状态变化： 必须： - 预览 - 二次确认 - Audit --- # 第一百七十三章 用户封禁不支持普通批量 除非技术攻击场景由安全系统处理。 人工运营不需要： > 选100人一键封禁。 --- # 第一百七十四章 后台操作Undo 高风险操作不要依赖： > Toast后5秒撤销。 应该通过正式： - revoke - appeal - restore 流程。 --- # 第一百七十五章 资料审核支持快捷操作 可以： ```text 通过 需修改 ``` 降低工作人员操作量。 严重拒绝： 放“更多”。 --- # 第一百七十六章 审核原因标准化 使用： > review_reasons字典。 减少审核员每次自由发挥。 可以补充： > 备注。 --- # 第一百七十七章 风控原因标准化 同样使用： > resultCode / actionType。 便于统计和复核。 --- # 第一百七十八章 权限变更审计样例 例如： ```text 2026-08-28 14:32 管理员：李某 操作：修改张某角色 原角色：matchmaker 新角色：matchmaker + activity_manager ``` --- # 第一百七十九章 敏感访问审计样例 ```text 2026-08-28 15:10 操作员：王某 查看：USR-xxx 实名信息 原因：身份异常核验 ``` --- # 第一百八十章 后台权限测试矩阵 每个API至少测试： ```text 无Token 普通用户Token 错误Operator角色 正确角色错误组织 正确角色正确组织 敏感权限缺失 账号disabled ``` --- # 第一百八十一章 重点越权测试一 红娘手工请求： ```text GET /admin/users/{id}/sensitive-identity ``` 结果： > 403。 --- # 第一百八十二章 重点越权测试二 志愿者请求： ```text GET /admin/activities/other-activity/registrations ``` 非授权活动： > 403。 --- # 第一百八十三章 重点越权测试三 机构管理员请求： > 其他机构红娘服务。 结果： > ORGANIZATION_SCOPE_DENIED。 --- # 第一百八十四章 重点越权测试四 审核员请求： ```text POST /admin/risk/users/{id}/actions ``` 结果： > PERMISSION_DENIED。 --- # 第一百八十五章 重点越权测试五 风控员无： ```text message.content.review ``` 访问聊天： > 403。 --- # 第一百八十六章 重点越权测试六 机构管理员给自己分配： ```text super_admin ``` 必须： > 拒绝。 --- # 第一百八十七章 重点实时权限测试 管理员把红娘账号disabled。 该红娘即使页面没刷新： 下一次API： > ACCOUNT_DISABLED。 Session失效。 --- # 第一百八十八章 后台数据审计验收 必须能回答： ```text 谁审核了这个用户？ 谁封禁了这个账号？ 谁取消了这场活动？ 谁看过这个用户的敏感身份？ 谁给这个工作人员加了权限？ ``` 如果回答不了： > 审计设计不合格。 --- # 第一百八十九章 后台UX验收 工作人员登录后5秒内应该知道： > 今天有什么需要处理。 审核员不需要在： > 用户管理 → 搜索 → 打开 → 找审核 才能工作。 直接： > 工作台 → 待审核。 --- # 第一百九十章 后台安全UX原则 安全不能完全依赖培训。 界面本身必须减少错误： - 危险按钮不突出 - 高风险操作二次确认 - 敏感字段默认脱敏 - 无权限入口不显示 - 数据范围自动限制 --- # 第一百九十一章 后台P0模块 ```text 统一登录 Dashboard 用户管理 资料审核 红娘服务 活动管理 举报风控 组织人员 RBAC 审计 ``` --- # 第一百九十二章 P1模块 ```text 高级统计 敏感动态水印 MFA 临时活动账号 登录异常提醒 细化数据导出 权限复核 ``` --- # 第一百九十三章 P2模块 ```text 跨机构高级协同 审批式权限申请 Break Glass 自动权限到期 更高级合规审计 ``` --- # 第一百九十四章 推荐后台代码模块 ```text admin/ auth/ dashboard/ users/ reviews/ matches/ matchmaker/ activities/ risk/ analytics/ organizations/ operators/ roles/ permissions/ audit/ configs/ ``` --- # 第一百九十五章 后端权限模块建议 ```text OperatorAuthService PermissionService RoleService DataScopeService OrganizationService SensitiveAccessService AuditService ``` --- # 第一百九十六章 权限判断标准流程 ```text 请求 ↓ Operator认证 ↓ 账号是否active ↓ Organization是否active ↓ 是否拥有permission ↓ DataScope是否允许resource ↓ 是否涉及sensitive permission ↓ 允许业务Service执行 ↓ 必要时Audit ``` --- # 第一百九十七章 后台设计最终红线 严禁： 1. 所有工作人员共用一个admin账号 2. 红娘拥有全部用户资料权限 3. 普通管理员能浏览私人聊天 4. 志愿者看到身份证 5. 机构管理员看到其他机构全部数据 6. 前端隐藏按钮代替后端权限 7. 可以随意导出全量用户 8. 权限修改没有审计 9. 离职人员账号继续可用 10. 用户封禁可以无原因直接修改数据库状态 --- # 第一百九十八章 最终组织模型 ```text 平台运营主体 │ ┌─────────────┼─────────────┐ │ │ │ 妇联 工会 公益服务中心 │ │ │ ┌────┴───┐ ┌───┴───┐ ┌───┴────┐ │ │ │ │ │ │ 活动管理员 红娘 活动人员 负责人 红娘 志愿者 平台层： 审核员 风控员 平台管理员 ``` 具体实际组织结构可调整，但权限模型保持一致。 --- # 第一百九十九章 最终权限模型 ```text Operator │ ├── Organization │ ├── Roles │ ↓ │ Permissions │ ├── Data Scope │ └── Sensitive Permissions ↓ Audit Log ``` --- # 第二百章 最终设计原则 整个运营管理后台必须坚持： > **后台统一，权限分开。** > **用户属于平台，不属于某个工作人员或某个组织的私人资源。** > **角色决定能做什么，数据范围决定能对谁做。** > **敏感信息永远需要额外权限。** > **红娘、审核员、活动人员、风控员职责必须分离。** > **志愿者始终使用最低权限。** > **机构合作不等于数据全共享。** > **工作人员离职，权限必须立即消失。** > **任何高风险操作必须可追溯。** > **任何权限设计都必须同时在服务端执行，不能只靠前端隐藏。** 最终后台不是为了让管理员“什么都能看到”，而是为了做到： > **每个人只看到完成自己工作所需要的内容，只能做自己被授权做的事情，而且做过的关键事情都能被追溯。** 这才是公益婚恋平台能够由多个组织、多个工作人员长期共同运营，而不会随着人员增加逐渐失控的基础。