# 丹阳公益婚恋服务平台 # V1.0 安全、隐私、合规与风控体系设计 版本：V1.0 适用地区：中国大陆 适用范围：微信小程序用户端、公益红娘工作台、运营管理后台 设计目标：真实、安全、最小采集、最小权限、全程可追溯、风险可发现、事件可处置 > 本文件属于产品与技术合规设计基线，不替代正式法律意见。上线前应结合实际运营主体、实名认证供应商、服务器部署地点、微信小程序主体及第三方服务商完成最终合规核验。 --- # 第一章 安全体系总体目标 公益婚恋平台处理的数据具有明显的高隐私属性。 平台掌握的数据可能包括： - 身份信息 - 身份证号码 - 手机号码 - 真实照片 - 年龄 - 婚姻状态 - 子女情况 - 职业 - 居住区域 - 婚恋意愿 - 择偶条件 - 聊天信息 - 活动参加记录 - 红娘服务记录 - 举报记录 因此本项目不能只按照普通内容小程序设计。 安全模型必须建立在： > **默认不公开、最小必要、明确授权、分层访问、全程审计。** 个人信息处理应具有明确合理目的，并限制在实现目的的最小范围内；法律同时要求个人信息处理规则公开、透明。 --- # 第二章 V1.0安全体系总架构 ```text 用户安全 │ ├── 身份真实性 │ ├── 微信账号 │ ├── 手机号 │ └── 实名认证 │ ├── 资料真实性 │ └── 人工资料审核 │ ├── 婚恋安全 │ ├── 双向喜欢 │ ├── 举报 │ ├── 拉黑 │ ├── 风险提醒 │ └── 公益红娘 │ ├── 数据安全 │ ├── 数据分级 │ ├── 加密 │ ├── 脱敏 │ ├── 最小权限 │ └── 数据生命周期 │ ├── 平台安全 │ ├── API鉴权 │ ├── 限流 │ ├── 防刷 │ ├── 上传安全 │ └── Web安全 │ └── 运营安全 ├── RBAC ├── 敏感访问审批/理由 ├── 操作日志 ├── 风险处置 └── 安全事件响应 ``` --- # 第三章 合规基线 V1.0至少应按照以下规范建立制度与技术措施： ### 法律层 《中华人民共和国个人信息保护法》 《中华人民共和国数据安全法》 《中华人民共和国网络安全法》 《中华人民共和国反电信网络诈骗法》 《中华人民共和国民法典》 ### 行政法规及监管规则 《网络数据安全管理条例》 《个人信息保护合规审计管理办法》 其中《网络数据安全管理条例》自2025年1月1日起施行；修订后的《网络安全法》自2026年1月1日起施行；个人信息保护合规审计管理办法自2025年5月1日起施行。 --- # 第四章 一个必须明确的年龄边界 当前产品已经确定： > 面向所有成年单身人士。 因此平台账号准入继续按照： > **18周岁及以上。** 但是必须区分两个概念： ```text 成年 ≠ 达到法定结婚年龄 ``` 现行《民法典》规定： > 男不得早于22周岁、女不得早于20周岁登记结婚。 因此V1.0不得出现： > “18岁即可结婚” > “符合结婚登记条件” 等错误表达。 对于尚未达到法定婚龄、但已经成年的用户，可以按照既定产品定位提供成年人交友婚恋服务，但页面不得误导其已经达到法定登记结婚条件。 --- # 第五章 未成年人硬限制 实名认证计算年龄： ```text age < 18 ``` 直接： > 拒绝进入婚恋平台。 后端返回： ```text UNDER_18 ``` 不得允许： - 浏览婚恋用户 - 建立婚恋资料 - 参加婚恋匹配 - 使用聊天 - 报名婚恋活动 并且不能依靠用户自行填写年龄判断。 必须通过实名认证结果判断。 --- # 第六章 身份真实性体系 V1确认采用： ```text 微信登录 + 手机号 + 姓名/身份证实名认证 + 人工资料审核 ``` 前端最终认证标识： ```text 已实名 资料已审核 ``` --- # 第七章 “已实名”意味着什么 平台只能表达： > 用户提供的身份信息已通过实名认证。 不能把“已实名”宣传为： > 婚姻情况100%真实 > 绝对真实可靠 > 平台已验证其所有资料 实名认证只能解决： > 人是谁。 不能自动解决： > 是否真的单身。 > 职业是否完全真实。 > 收入是否真实。 --- # 第八章 婚姻状态真实性边界 这是V1必须特别注意的地方。 目前项目并没有已经确定可合法调用的： > 民政婚姻登记数据库查询能力。 因此V1中的： ```text 未婚 离异 丧偶 ``` 应定义为： > **用户本人申报 + 人工资料审核。** 不得前台标注： > “婚姻状态官方认证” 除非后续确实获得合法、稳定的数据核验能力。 --- # 第九章 婚姻状态展示文案 建议后台明确区分： ```text 实名认证：已验证 婚姻状态：本人填写 ``` 普通用户前台不必反复显示“本人申报”。 但在： > 平台服务规则 / 安全说明 中应明确： > 部分个人婚恋资料由用户本人填写，平台通过实名认证及人工审核提高资料可信度，但不能替代用户在进一步交往中的必要核实。 --- # 第十章 个人信息分类 建议V1建立四级分类。 ## L1 普通公开婚恋信息 例如： - 展示昵称 - 年龄 - 身高 - 丹阳区域 - 学历 - 职业类别 - 兴趣 - 婚恋态度 只在符合平台规则的用户之间展示。 --- ## L2 一般个人信息 例如： - 微信OpenID - 手机号码 - 注册时间 - 活动报名 - 红娘服务记录 普通婚恋用户不可见。 --- ## L3 高敏感数据 例如： - 实名姓名 - 身份证号码 - 实名认证原始结果 - 举报证据 - 风控资料 - 精细位置信息（如果未来收集） 必须严格控制权限。 身份证等能够识别特定身份的信息及部分其他信息在实际处理中具有较高风险；法律对敏感个人信息要求特定目的、充分必要性和严格保护措施，处理敏感个人信息还涉及单独同意及特别告知要求。 --- ## L4 极高隐私业务数据 包括： - 私人聊天正文 - 风控调查材料 - 特殊申诉证据 - 敏感投诉信息 实行： > 默认任何工作人员不可见。 必须经过特定业务权限和访问原因才能访问。 --- # 第十一章 个人信息最小化 必须执行： > 没有必要，不采集。 因此V1不要求用户提供： - 房产证 - 车辆证明 - 银行流水 - 银行卡 - 详细工资 - 精确住宅地址 - 单位完整内部信息 - 家庭成员身份证 - 征信报告 个人信息保护法明确要求处理目的明确、与目的直接相关，并采取对个人权益影响最小的方式，不得过度收集。 --- # 第十二章 不要为了“以后可能用”提前采集 禁止设计： ```text 先把资料收齐 以后也许用得到 ``` 每个新增字段必须说明： ```text 为什么采集？ 用于什么？ 谁能看到？ 保存多久？ 用户能否拒绝？ ``` 回答不了： > 不采集。 --- # 第十三章 隐私政策必须实际对应产品 隐私政策不能复制网上模板。 必须明确： - 谁是个人信息处理者 - 联系方式 - 收集哪些信息 - 为什么收集 - 如何使用 - 保存期限或确定方式 - 是否向第三方提供 - 使用哪些第三方SDK - 用户如何查询 - 如何更正 - 如何删除 - 如何撤回同意 - 如何注销账号 - 如何投诉 《网络数据安全管理条例》要求个人信息处理规则集中公开、易访问、位置醒目，并说明处理目的、方式、种类、敏感信息必要性、保存期限，以及个人查阅、更正、删除、注销、撤回同意等途径。 --- # 第十四章 建议建立“个人信息清单” 不要只写一篇长隐私政策。 建议提供： > 我的 → 隐私设置 → 个人信息收集清单 例如： ```text 手机号 用途： 账号安全、活动必要联系 是否必要： 是 展示给其他用户： 否 ``` --- # 第十五章 第三方信息共享清单 如果接入： - 微信 - 实名认证服务 - 短信服务 - 对象存储 - 地图 - 内容安全服务 必须维护： > 第三方个人信息处理清单。 明确： ```text 第三方是谁 提供什么数据 处理目的 处理方式 隐私政策 ``` --- # 第十六章 实名认证应单独授权 实名认证前不要只用： > “我同意隐私政策” 一揽子处理。 建议增加： ```text 实名认证信息处理说明 ``` 明确： - 姓名 - 身份证号码 - 认证目的 - 第三方认证服务商 - 数据保护方式 - 必要性 - 对权益可能产生的影响 涉及敏感个人信息时，应按照法律要求落实单独同意及特别告知。 --- # 第十七章 同意必须可证明 数据库建议记录： ```text consent_records ``` 字段： ```text user_id consent_type document_version agreed_at client_version ``` 例如： ```text privacy_policy user_agreement real_name_processing activity_rules ``` --- # 第十八章 隐私政策版本 必须版本化： ```text privacy_v1.0 privacy_v1.1 ``` 重大变化后： > 再次提示用户。 不能直接替换网页文本而没有记录。 --- # 第十九章 敏感信息存储 身份证： ```text AES等强加密 ``` 数据库： ```text id_number_enc ``` 另存： ```text id_number_hash ``` 用于： > 查重。 不能明文存储。 --- # 第二十章 手机号码 数据库可以： ```text phone_enc phone_hash ``` 业务展示： ```text 138****1234 ``` 非必要人员永远只看到脱敏版本。 --- # 第二十一章 日志脱敏 绝不能打印： ```text 身份证号码 手机号全文 真实姓名+身份证 密码 Access Token Refresh Token 聊天正文 举报截图URL ``` 例如日志只写： ```text userId=usr_xxx verificationStatus=SUCCESS ``` --- # 第二十二章 用户照片安全 用户照片不能使用： > 永久公开URL。 建议： ```text Private Object Storage + 短时Signed URL ``` 签名URL： > 数分钟/有限时间有效。 --- # 第二十三章 图片授权必须按业务判断 用户A请求： ```text B的生活照片 ``` 后端必须校验： - A是合格用户 - B允许公开 - B账号正常 - 双方不存在Block - 当前场景允许访问 不能： > 只知道URL就永久查看。 --- # 第二十四章 精确位置不要采集 V1没有“附近的人”核心需求。 因此不建议申请： > GPS持续定位。 地区使用： ```text 丹阳市 镇江 区域选择 ``` 即可。 如果未来加入附近匹配： > 必须重新做隐私影响评估。 --- # 第二十五章 不向普通用户展示精确住址 前台： ```text 丹阳 ``` 必要时： ```text 丹阳开发区 ``` 不要： ```text XX小区X幢 ``` --- # 第二十六章 工作单位保护 默认显示： ```text 教师 医疗行业 企业职员 ``` 不要默认： ```text 丹阳市XX学校XX年级 XX医院XX科 XX公司XX部门 ``` 避免通过工作信息快速定位个人。 --- # 第二十七章 聊天隐私原则 系统设计必须明确： > **工作人员默认没有权限查看用户私人聊天。** 数据库有聊天数据： ≠ 运营人员就可以浏览聊天。 --- # 第二十八章 允许访问聊天内容的场景 仅在明确必要情况下，例如： - 用户举报并提交相关会话 - 涉嫌诈骗 - 严重骚扰 - 人身安全风险 - 法律依法要求 - 经授权的风控调查 才允许访问必要范围。 --- # 第二十九章 聊天查看权限 建议权限： ```text message.content.review ``` 普通： ```text 管理员 红娘 审核员 活动人员 ``` 默认全部： > 无。 只有风控专岗/受权管理员拥有。 --- # 第三十章 查询聊天必须填写原因 后台： ```text 查看相关聊天内容 访问原因： [举报调查 ▼] 关联举报： REP-000123 ``` 确认后： > Audit Log。 不能： > 一点击用户详情就把聊天全部展示出来。 --- # 第三十一章 最小范围查看 如果举报对应： > 8月28日某段聊天。 风控人员首先查看： > 相关上下文。 不是： > 一键调取用户三个月全部聊天。 --- # 第三十二章 公益红娘隐私边界 红娘可以看到： - 年龄 - 婚恋资料 - 择偶要求 - 公开照片 - 服务申请 - 跟进记录 不能看到： - 完整身份证 - 完整私人聊天 - 举报证据 - 风控内部调查 - 无关活动隐私 --- # 第三十三章 志愿者权限 志愿者的权限必须更低。 例如活动签到志愿者只看到： ```text 姓名/称呼 手机号尾号 报名状态 签到状态 ``` 绝不能因为： > “是公益志愿者” 就拥有所有用户资料。 --- # 第三十四章 最小权限RBAC 实行： ```text 超级管理员 机构管理员 审核员 公益红娘 活动管理员 风控员 志愿者 ``` 每个角色拆操作权限。 --- # 第三十五章 敏感权限不能随便授权 例如： ```text user.sensitive.view message.content.review risk.evidence.view user.ban permission.manage ``` 只给必要角色。 --- # 第三十六章 权限变更必须审计 所有： - 新增工作人员 - 修改角色 - 增加敏感权限 - 停用账号 - 重置密码 必须进入： ```text audit_logs ``` --- # 第三十七章 后台工作人员账号安全 V1至少执行： - 强密码 - 登录失败限制 - 异常登录记录 - 账号停用立即失效 - Session过期 - 密码Hash 建议后台支持： > MFA/二次验证能力。 敏感角色优先开启。 --- # 第三十八章 禁止共享后台账号 不能： ```text 大家都用 admin / 123456 ``` 工作人员必须： > 一人一账号。 这样才能知道： > 谁看过什么、谁修改了什么。 --- # 第三十九章 API鉴权 所有业务API必须： ```text Token + 当前账号状态 + 资源权限 ``` 三层校验。 不能只检查： > Token是不是合法。 --- # 第四十章 IDOR防护 这是婚恋系统特别重要的问题。 例如： ```text GET /users/usr_123/profile ``` 用户不能把： ```text usr_123 ``` 改成任意ID就访问本不该看的资源。 尤其： - 聊天 - 举报 - 红娘 - 活动隐私 - 实名信息 都必须做对象级权限校验。 --- # 第四十一章 聊天会话权限 访问： ```text /conversations/{id} ``` 服务端必须确认： ```text 当前user ∈ conversation_members ``` 否则： > 403。 --- # 第四十二章 上传安全 图片上传必须检测： - MIME - Magic Number - 文件大小 - 分辨率 - 文件后缀 - 恶意文件风险 不能只判断： ```text .jpg ``` --- # 第四十三章 上传限制建议 头像： ```text ≤ 10MB ``` 生活照片： ```text ≤ 10MB/张 ``` 后端统一压缩转换。 可考虑转换为： > JPEG/WebP安全格式。 去除不必要EXIF信息。 --- # 第四十四章 EXIF隐私 照片EXIF可能包含： > GPS位置。 后台图片处理建议： > 移除EXIF元数据。 特别是位置数据。 --- # 第四十五章 个人简介安全 只允许： > Plain Text。 禁止： - HTML - JS - 富文本脚本 - iframe - 外链代码 避免XSS。 --- # 第四十六章 联系方式引流检测 资料中检测： - 手机号 - 微信号 - QQ - 二维码 - URL - 外部联系方式暗示 命中： > 进入人工审核。 目的： - 防诈骗 - 防营销 - 保持平台安全闭环 --- # 第四十七章 婚恋反诈骗V1规则 V1建立轻量规则引擎。 重点监控风险行为： ```text 投资 理财 博彩 高收益 虚拟币 代充值 借钱 转账 银行卡 贷款 资金周转 刷单 项目投资 ``` 反电信网络诈骗法以预防、遏制和惩治电信网络诈骗、保护公民和组织合法权益为立法目标，并强调依法治理和个人信息保密。 --- # 第四十八章 风险关键词不能等于诈骗 例如用户说： > “我在银行工作。” 出现“银行”不代表诈骗。 所以规则： ```text 关键词命中 ≠ 直接处罚 ``` 只能： > 风险事件 + 提醒/评分。 --- # 第四十九章 风险行为评分 建议V1示例： ```text 多人举报诈骗 +50 多人举报金钱诱导 +40 高频发送联系方式 +15 短时间大量喜欢 +10 被多人拉黑 +10~20 重复复制同一话术 +20 风控人工标记 +可配置 ``` 最终阈值： > 运营后台配置。 --- # 第五十章 风险分不是自动定罪 风险评分用于： > 排序、发现、人工审核。 不能前台展示： > “此人诈骗概率87%”。 --- # 第五十一章 用户侧风险提示 正常聊天顶部： > 请注意保护个人隐私，谨慎涉及转账、借款、投资等资金往来。 高风险关键词命中： > 婚恋交友过程中请谨慎涉及资金往来，不要轻信投资、借款或高收益项目。 --- # 第五十二章 高风险账号 可以进入： ```text normal → watch → high → critical ``` 但RiskLevel与AccountStatus分离。 --- # 第五十三章 自动限制应非常谨慎 V1可自动做： - 消息限频 - 点赞限频 - 登录限频 - 举报刷接口限频 对于： > 真实用户永久封禁 原则上人工复核。 --- # 第五十四章 明显技术攻击例外 例如： - 暴力破解 - 自动脚本 - 恶意扫描 - 高频撞库 - 接口攻击 可以自动： > IP / Session / Account临时限制。 --- # 第五十五章 举报体系 所有： - 用户详情 - 聊天 - Match 必须容易找到： > 举报。 但不必作为主要视觉按钮。 --- # 第五十六章 举报证据保护 举报人身份： > 不向被举报人展示。 被举报人只得到： > 处理结果或账号状态通知。 不能告诉： > “王女士举报了你”。 --- # 第五十七章 举报证据访问 举报截图属于高隐私数据。 只有： ```text risk.evidence.view ``` 可以查看。 每次查看应写Audit。 --- # 第五十八章 拉黑与举报分离 用户选择： > 拉黑 不要求必须举报。 用户举报： 也不强制拉黑。 可以提供： > 举报并拉黑 快捷选项。 --- # 第五十九章 举报恶意滥用 如果发现用户： > 大量无事实举报。 可创建： ```text ABUSE_REPORT ``` 风险事件。 但不能因为一次举报不成立： > 就处罚举报人。 --- # 第六十章 婚恋状态欺诈 这是平台重点风险。 举报类型必须有： > 婚姻状态疑似虚假。 收到此类举报： > 进入人工核实。 可以暂时： > 降低曝光 / 暂停推荐。 但不能在没有依据时公开标记： > “已婚骗子”。 --- # 第六十一章 线下活动安全 活动页必须显示： - 主办方 - 承办方 - 时间 - 地点 - 规则 - 联系方式 - 安全提醒 活动签到仅允许： > 审核通过者。 --- # 第六十二章 活动现场不要公开完整名单 工作人员签到列表可显示： ```text 张先生 手机号后四位1234 ``` 现场大屏/签到表不要公开： - 完整手机 - 身份证 - 精确住所 - 用户择偶条件 --- # 第六十三章 线下互选保护 活动后： A选择B。 B在没有互选前： > 不知道A选择了自己。 双方互选才通知。 避免： - 压力 - 尴尬 - 骚扰 --- # 第六十四章 公益红娘联系边界 红娘帮助A联系B之前： A必须明确： > 申请协助联系。 红娘向B发送： > 系统邀请。 不能直接： > 把B手机号给A。 --- # 第六十五章 用户联系方式交换 V1原则： > 平台不直接向匹配用户公开手机号码。 双方互相喜欢后： > 先平台内聊天。 后续是否自行交换微信或手机号： > 由用户本人决定。 --- # 第六十六章 不允许红娘私自提供联系方式 即使红娘知道手机号： 不能未经本人同意： > 将手机号/微信提供给另一方。 --- # 第六十七章 自动化推荐透明度 V1推荐采用规则匹配。 用户侧： > 为什么推荐给你？ 例如： - 年龄条件符合 - 同城 - 婚恋计划接近 不需要显示复杂算法。 --- # 第六十八章 不允许隐性敏感画像 V1不要基于用户资料推断： - 宗教 - 健康状态 - 政治倾向 - 性生活 - 财富等级 并用于推荐。 特别是用户从未主动提供的信息。 --- # 第六十九章 不做“颜值评分” 不要使用AI对： > 外貌打分。 也不要： > 自动标注“高颜值”。 既没有必要，也容易引发歧视和不必要的数据处理风险。 --- # 第七十章 不做收入信用评分 V1不要产生： ```text 婚恋信用分 92 ``` 或者： ```text 优质用户等级 ``` 实名认证和人工审核只显示： > 已实名 / 已审核。 --- # 第七十一章 用户个人信息权利中心 建议： > 我的 → 隐私与个人信息 包括： ```text 查看我的个人信息 修改资料 修改隐私设置 撤回非必要授权 申请删除 注销账号 查看隐私政策 第三方信息共享清单 联系我们 ``` --- # 第七十二章 查询与更正 用户可以直接修改： - 兴趣 - 生活方式 - 择偶条件 - 隐私设置 敏感资料： > 通过专门流程修改。 --- # 第七十三章 身份信息更正 实名认证核心信息如果错误： 不能普通表单直接改。 需要： > 客服/人工核验流程。 避免身份被替换。 --- # 第七十四章 撤回同意 用户撤回某项非核心授权： 例如： > 不接收活动推荐。 平台必须： > 停止对应处理。 但是： 实名认证如果属于提供核心婚恋服务的必要处理： 撤回可能意味着： > 无法继续使用核心婚恋服务。 页面应说明后果。 --- # 第七十五章 数据删除 个人信息保护制度要求在处理目的已实现、保存期限届满、账号注销、撤回同意等符合条件的情形下落实删除；若法律要求保存或技术上暂时无法删除，应停止除存储和必要安全保护之外的处理。 因此不能设计： > “我们永久保存所有用户数据。” --- # 第七十六章 数据保存期限原则 法律的一般原则是： > 实现处理目的所必要的最短时间。 因此V1需要建立： ```text Data Retention Policy ``` 而不是所有数据： > 永久保存。 --- # 第七十七章 V1建议的数据生命周期分类 具体保存年限最终应在正式合规审查中结合业务和法律义务确定。 产品层先定义四类： ### A. 账号活跃数据 账号存续期间保存。 ### B. 匹配业务数据 账号存续及合理必要期间保存。 ### C. 安全与纠纷数据 按安全、纠纷处理、法律义务所需期限保存。 ### D. 无必要临时数据 尽快清理。 --- # 第七十八章 临时上传文件 例如： - 上传失败图片 - 未提交的举报附件 - 临时上传Token对应文件 应建立自动清理。 例如： > 24小时/7天后清理未绑定业务的数据。 --- # 第七十九章 注销流程 用户： > 我的 → 账号与安全 → 注销账号 必须说明： - 注销后停止推荐 - 资料停止展示 - 聊天停止 - 红娘服务结束 - 未开始活动报名处理方式 - 数据后续处理原则 --- # 第八十章 注销不能故意制造障碍 不能要求： > 打电话 + 邮寄身份证 + 到现场 才能注销。 应该提供： > 在线便捷渠道。 网络数据安全管理规则明确要求个人信息处理规则说明注销账号、撤回同意及查阅、更正、删除等途径。 --- # 第八十一章 注销后二次展示 用户注销后： 其他用户历史会话可以显示： > 用户已注销 不要继续： > 展示其完整公开资料供别人浏览。 --- # 第八十二章 数据出境原则 V1建议： > 用户核心数据优先存储在中国大陆。 实名信息、聊天、用户照片等核心数据： > 不使用境外数据服务，除非完成必要的合规评估和合法路径。 这样能明显降低V1合规复杂度。 --- # 第八十三章 第三方API选型要求 任何第三方服务接入前，建立： ```text Vendor Security Checklist ``` 至少检查： - 公司主体 - 服务协议 - 隐私政策 - 数据存放区域 - 是否转委托 - 删除机制 - 数据安全措施 - 是否会用于自身训练/营销 - 事故通知机制 --- # 第八十四章 第三方不得擅自使用数据 如果实名认证供应商、云服务商等属于受托处理方，应通过合同明确处理目的、期限、方式、数据种类、安全措施和双方责任，并监督其处理活动。个人信息保护法对此类委托处理有明确要求。 --- # 第八十五章 V1第三方依赖尽量少 推荐： ```text 微信 实名认证供应商 短信（如需要） 云数据库 对象存储 ``` 能不用的第三方SDK： > 不用。 尤其避免一次接入十几个广告/统计SDK。 --- # 第八十六章 不接广告SDK 既然平台定位： > 用户永久免费公益婚恋。 V1也不需要： - 广告联盟 - 用户画像广告 - 广告追踪SDK 直接减少隐私风险。 --- # 第八十七章 统计埋点最小化 可以记录： ```text 推荐曝光 查看资料 喜欢 双向匹配 活动报名 ``` 不能埋点： - 身份证 - 聊天内容 - 私人照片内容 - 举报内容 - 用户输入的敏感文本 --- # 第八十八章 Analytics使用匿名业务ID 例如： ```text userIdHash event=like_click ``` 而不是： ```text 张三 138... 身份证... ``` --- # 第八十九章 个人信息保护影响评估 处理敏感个人信息等法定情形需要事前开展个人信息保护影响评估并记录处理情况。 因此在V1上线前应至少对以下场景形成书面评估记录： ```text 实名认证 用户照片 婚恋资料 聊天 举报证据 红娘人工访问 第三方实名认证 数据出境（如存在） ``` --- # 第九十章 PIA评估至少回答 ```text 处理目的是否合法、合理、必要？ 对用户权益有什么影响？ 风险有多大？ 是否有替代方案？ 采取什么保护措施？ 谁可以访问？ 保存多久？ 发生泄露怎么办？ ``` --- # 第九十一章 定期个人信息保护合规审计 2025年5月1日起施行的《个人信息保护合规审计管理办法》要求个人信息处理者定期开展合规审计；处理超过1000万人个人信息的处理者至少每两年一次，其他处理者按自身情况合理确定频次。 本项目早期用户规模较小，也建议： > 至少年度内部检查一次。 --- # 第九十二章 V1年度内部合规检查 检查： - 有没有多采数据 - 隐私政策是否和实际一致 - 第三方SDK有没有变化 - 谁拥有敏感权限 - 有没有异常敏感访问 - 已注销用户数据是否仍公开 - 过期数据是否清理 - 是否发生安全事故 - 风控处置是否存在滥用 --- # 第九十三章 数据泄露应急响应 必须有： ```text Personal Data Incident Response Plan ``` 分为： ```text 发现 ↓ 隔离 ↓ 评估 ↓ 修复 ↓ 记录 ↓ 依法报告/通知 ↓ 复盘 ``` 个人信息保护法要求个人信息处理者制定并组织实施个人信息安全事件应急预案。 --- # 第九十四章 高风险安全事件 例如： - 身份证泄露 - 用户照片批量泄露 - 聊天数据库泄露 - 后台账号被盗 - 大量数据被导出 - 对象存储Bucket公开 - 勒索软件 - 数据库入侵 应立即升级处理。 --- # 第九十五章 安全事件日志 记录： ```text 事件时间 发现人 影响范围 涉及数据 临时措施 修复措施 通知情况 最终原因 后续整改 ``` --- # 第九十六章 数据导出安全 V1后台原则： > 尽量少提供导出。 必要导出： 例如活动签到名单。 只能导出： ```text 姓名/称呼 脱敏手机号 活动状态 ``` 而不是整个User表。 --- # 第九十七章 敏感数据导出 例如实名信息： V1原则： > 默认不提供Excel批量导出。 如果未来确有必要： 必须： - 高权限 - 明确原因 - 水印 - 审计 - 有效期 - 加密文件 --- # 第九十八章 后台截图风险 技术无法完全禁止工作人员截图。 因此核心办法是： - 最少显示 - 权限控制 - 敏感水印 - 操作审计 - 人员制度 敏感页面可加入： ```text 操作者姓名 时间 账号ID ``` 动态水印。 --- # 第九十九章 数据库安全 生产数据库： > 禁止公网直接开放。 建议： ```text 应用内网 ↓ PostgreSQL ``` 管理访问： > VPN / 堡垒机 / 白名单等安全方式。 --- # 第一百章 Redis安全 Redis： - 不暴露公网 - 设置认证 - 网络隔离 - 最小权限 Redis中不要保存： > 长期明文身份证。 --- # 第一百零一章 对象存储安全 必须： ```text Private Bucket ``` 禁止： ```text Public Read ``` 用户照片尤其如此。 --- # 第一百零二章 备份安全 备份： - 加密 - 限制访问 - 与生产权限隔离 - 定期恢复测试 不能数据库很安全： > 备份文件却在公共NAS。 --- # 第一百零三章 开发测试环境 严禁将生产用户真实数据直接复制给开发人员。 如果必须排查： > 脱敏后使用。 --- # 第一百零四章 开发人员权限 开发人员不应日常拥有： > 生产实名数据库查询权限。 生产问题： > 通过日志、监控、脱敏工具排查。 --- # 第一百零五章 密钥管理 不要把： ```text 数据库密码 微信Secret 实名认证Secret JWT Secret 对象存储Secret ``` 写入Git。 使用： - 环境变量 - Secret Manager - 安全配置 --- # 第一百零六章 密钥轮换 必须能够： > 更换密钥而不重新发布全部代码。 人员离职、泄露怀疑： > 立即轮换。 --- # 第一百零七章 密码安全 后台密码： > Argon2 / bcrypt等成熟强哈希。 禁止： - MD5 - SHA1直接Hash - 明文密码 - 可逆加密保存密码 --- # 第一百零八章 登录防护 后台： 连续失败达到阈值： > 临时锁定/验证码/限速。 记录： - IP - 时间 - User Agent 用于识别异常。 --- # 第一百零九章 普通用户防刷 微信登录本身不是万能防护。 接口仍需限流： ```text 实名 Like 聊天 举报 文件上传 活动报名 ``` --- # 第一百一十章 大量点赞检测 例如： > 1分钟喜欢几十人。 系统： - 限速 - 生成RiskEvent 但阈值放后台配置。 --- # 第一百一十一章 批量资料抓取防护 防止有人写爬虫： > 把丹阳所有单身女性资料批量抓走。 措施： - Token访问 - 每日推荐限制 - Discover分页限制 - 高频访问限流 - 图片临时URL - 风险检测 - 不提供全量查询API --- # 第一百一十二章 防通讯录式枚举 API不能允许： ```text /user/1 /user/2 /user/3 ``` 连续猜测全部用户。 使用： > UUID/不可预测ID。 同时仍要做访问权限。 --- # 第一百一十三章 防SQL注入 所有查询： > 参数化。 严禁： ```text "... WHERE name = '" + input + "'" ``` --- # 第一百一十四章 防XSS 用户输入： - 自我介绍 - 红娘说明 - 活动评论 - 举报说明 前端展示必须： > 转义。 后端保存： > 纯文本优先。 --- # 第一百一十五章 CSRF 红娘Web/后台如使用Cookie认证： > 必须CSRF防护。 如果Bearer Token架构： 也需要正确处理： - CORS - Token存储 - XSS --- # 第一百一十六章 CORS 生产： 只允许： > 正式后台域名。 不能： ```text Access-Control-Allow-Origin: * ``` 尤其敏感管理接口。 --- # 第一百一十七章 内容安全人工优先 V1重点场景： - 头像 - 生活照片 - 个人简介 采用： ```text 机器基础检测 + 人工审核 ``` 如果机器审核供应商成本较高： > 人工审核为V1主机制。 --- # 第一百一十八章 资料异常行为 以下进入人工关注： - 图片疑似网图 - 图片多次被拒 - 简介反复写联系方式 - 资料频繁大幅修改 - 年龄/性别异常冲突 - 举报频繁 --- # 第一百一十九章 身份盗用举报 举报： > 冒充他人 风险等级： > 高。 可以先： > 暂停公开资料 再人工调查。 保护被冒用者优先。 --- # 第一百二十章 账号恢复 风险解除以后： 不要简单恢复所有状态。 例如： 封禁前： > searching 解除后： 可以恢复账号正常。 但如果资料存在问题： > 仍需重新审核。 --- # 第一百二十一章 权限优先级 安全判断顺序： ```text 账号安全 > 身份/审核 > 拉黑 > 隐私 > 婚恋状态 > 匹配关系 > 普通业务功能 ``` --- # 第一百二十二章 安全默认值 系统设计遵循： > Default Deny。 如果权限判断异常： > 默认拒绝。 如果图片授权异常： > 默认不返回。 如果用户状态未知： > 默认不进入匹配。 --- # 第一百二十三章 Fail Closed原则 例如： Risk服务暂时失败。 涉及： > 敏感后台操作。 宁可： > 暂时无法查看。 也不要： > 为了可用性自动放开权限。 --- # 第一百二十四章 普通业务可以Fail Soft 例如： 推荐理由服务异常。 可以： > 暂时只展示候选人。 而不是： > 整个平台打不开。 安全与普通功能的降级策略要区分。 --- # 第一百二十五章 安全测试范围 上线前至少完成： ```text 认证绕过测试 IDOR测试 权限越权测试 SQL注入 XSS 文件上传 Token失效 接口重放 暴力登录 高频接口 对象存储权限 敏感信息泄露 日志检查 ``` --- # 第一百二十六章 重点越权测试 模拟： ### 普通用户 尝试： > 获取其他用户手机号。 必须失败。 ### 红娘 尝试： > 查看身份证。 必须失败。 ### 活动管理员 尝试： > 查看聊天内容。 必须失败。 ### 审核员 尝试： > 修改系统权限。 必须失败。 --- # 第一百二十七章 安全验收：“查库问题” 最终验收要问： > 如果开发人员拿到普通业务数据库查询能力，是否能一条SQL导出全部实名+身份证+聊天？ 目标应该是： > 尽量不能轻易做到。 通过： - 敏感分表 - 加密 - 权限隔离 降低风险。 --- # 第一百二十八章 个人信息保护负责人 项目运营早期即使规模不大，也建议明确一名： > 数据与隐私安全负责人。 负责： - 隐私政策 - 权限审批 - 数据事故 - 第三方服务 - 用户信息权利请求 - 定期检查 当个人信息处理达到法律规定的相应规模时，法律对个人信息保护负责人另有明确要求。 --- # 第一百二十九章 安全责任角色 建议内部至少明确： ```text 产品负责人 技术负责人 数据/隐私负责人 风控负责人 机构运营负责人 ``` 一个人可以兼任多个角色。 但责任必须有人承担。 --- # 第一百三十章 合作公益组织的数据权限 妇联、工会、公益服务中心等参与： > 不意味着全部组织自动拥有全部平台数据。 必须明确： ```text 谁是平台运营主体？ 谁是个人信息处理者？ 哪些机构只是活动合作方？ 哪些是受托服务方？ 是否存在共同处理？ ``` 如果多个主体共同决定处理目的和方式，需要明确各自权利义务；法律同时规定这不会影响个人向相关处理者行使个人信息权利。 --- # 第一百三十一章 组织数据隔离 机构管理员： 默认： > 只能看到自己授权范围。 例如： 工会活动管理员： 不能自动看到： > 妇联红娘全部服务对象。 --- # 第一百三十二章 公益不等于免责 即使： > 用户永久免费 > 平台是公益性质 仍然必须承担： - 个人信息保护 - 网络安全 - 数据安全 - 用户安全 公益属性不能降低安全要求。 --- # 第一百三十三章 V1必须具备的安全功能 上线前必须完成： ```text 实名认证 人工资料审核 隐私政策 用户协议 敏感信息单独告知/授权机制 个人信息清单 敏感数据加密 手机号脱敏 身份证脱敏 图片私有存储 RBAC 后台一人一账号 敏感访问日志 后台操作审计 双向喜欢后聊天 举报 拉黑 风险关键词提示 账户限制/封禁 申诉 API鉴权 接口限流 文件安全 日志脱敏 数据库备份 安全事件预案 注销 隐私设置 个人信息更正/删除渠道 ``` --- # 第一百三十四章 V1建议具备 第二优先级： ```text 后台MFA 敏感页面动态水印 异常登录提醒 高级风控规则 图片自动审核 安全监控告警 自动合规检查 ``` --- # 第一百三十五章 V1暂不需要 暂时不建议投入： - 人脸活体认证强制 - 公安级身份核验体系 - AI诈骗模型 - 行为大数据平台 - 设备指纹复杂系统 - SIEM大型平台 - 零信任大型体系 - 区块链身份 - 生物特征匹配 - 全量聊天AI审查 除非实际风险和规模证明有必要。 --- # 第一百三十六章 特别提醒：人脸识别 V1不要为了“显得更安全”就强制做人脸识别。 因为这会进一步增加： > 生物识别信息处理。 属于更高风险的数据处理。 当前： > 实名认证 + 人工照片审核 作为V1更加轻量。 --- # 第一百三十七章 特别提醒：身份证照片 如果实名认证供应商只需要： > 姓名 + 身份证号码 平台自己就不要额外要求： > 上传身份证正反面。 少一份数据： > 少一份风险。 --- # 第一百三十八章 特别提醒：收入与资产 珍爱、佳缘商业产品可能会使用大量： - 收入 - 房产 - 车辆 信息。 本公益平台V1不建议照搬。 真实婚恋的核心不是： > 收集越多越好。 而是： > 够用、真实、愿意填写。 --- # 第一百三十九章 特别提醒：成功案例 用户成功牵手后： 默认： > 不公开。 如果希望展示： > 必须用户主动授权。 并允许： - 匿名 - 隐藏照片 - 隐藏姓名 后续可以撤回。 --- # 第一百四十章 成功案例授权独立 不能写在最初用户协议里： > “注册即同意平台使用成功故事宣传。” 应该在真正分享时： > 单独确认。 --- # 第一百四十一章 运营安全SOP 每天： > 查看高风险举报。 每周： > 查看异常账号。 每月： > 查看敏感访问日志。 每季度： > 复核工作人员权限。 每年： > 完成内部个人信息保护与安全检查。 --- # 第一百四十二章 离职人员 工作人员离开项目： 当日： ```text 停用账号 撤销权限 撤销Token 轮换必要共享Secret ``` 不能账号一直留着。 --- # 第一百四十三章 权限定期复查 每季度检查： > 这个人现在还需要这个权限吗？ 特别是： ```text sensitive.view risk.evidence.view user.ban permission.manage ``` --- # 第一百四十四章 安全监控指标 后台建议统计： ```text 登录失败次数 异常高频API 异常大量Like 举报数量 拉黑数量 高风险用户 敏感信息访问次数 封禁数量 上传失败/恶意文件 ``` --- # 第一百四十五章 风控核心漏斗 ```text 正常用户 ↓ 异常事件 ↓ 风险评分 ↓ 人工核实 ↓ 提醒 / 限制 / 暂停 / 封禁 ↓ 申诉 ↓ 恢复或维持处置 ``` --- # 第一百四十六章 用户安全闭环 ```text 实名认证 ↓ 人工资料审核 ↓ 系统双向匹配 ↓ 双向喜欢 ↓ 安全聊天 ↓ 公益红娘 ↓ 线下活动 ↓ 举报 / 拉黑 ↓ 风控人工处理 ``` --- # 第一百四十七章 平台不能承诺的事情 产品文案不得承诺： ```text 100%真人 100%单身 绝对安全 绝无诈骗 资料完全真实 一定可以找到对象 ``` 这些都无法真正保证。 --- # 第一百四十八章 平台可以承诺的机制 可以明确表达： > 实名认证。 > 人工资料审核。 > 双向喜欢才能聊天。 > 举报和拉黑机制。 > 公益红娘服务。 > 用户隐私保护。 > 异常账号人工处置。 这是平台真正可以控制的部分。 --- # 第一百四十九章 上线前合规验收清单 正式发布前逐项确认： ```text □ 运营主体确定 □ 微信小程序主体确定 □ 隐私政策完成 □ 用户协议完成 □ 公益婚恋服务规则完成 □ 实名认证特别告知完成 □ 第三方处理清单完成 □ SDK清单完成 □ 数据清单完成 □ 保存期限规则完成 □ 注销流程完成 □ 更正/删除渠道完成 □ 敏感数据加密完成 □ RBAC完成 □ 审计日志完成 □ 数据备份完成 □ 安全事件预案完成 □ 举报与申诉完成 □ PIA完成 □ 第三方供应商审查完成 □ 安全测试完成 ``` 任何核心项未完成： > 不建议正式开放真实用户。 --- # 第一百五十章 V1最终安全模型 整个安全体系可以归纳为： ```text 用户不知道的信息 工作人员也不应该默认知道 用户没有授权的处理 平台不应该擅自扩大 业务不需要的信息 系统不应该提前采集 普通工作人员不需要的数据 后台不应该展示 风险没有确认 平台不应该轻易定性 确认存在高风险 平台必须能够立即处置 ``` --- # 第一百五十一章 最终设计原则 丹阳公益婚恋服务平台V1.0必须坚持： > **身份实名，但身份信息不公开。** > **资料审核，但不虚假宣传“全部真实性已验证”。** > **婚姻状态用户申报，在没有合法数据源之前不冒充官方核验。** > **双向喜欢才允许聊天。** > **聊天默认属于用户隐私。** > **红娘只能查看完成服务必要的信息。** > **志愿者拥有最低权限。** > **第三方服务只能获得实现具体目的必要的数据。** > **敏感信息加密、脱敏、分表和审计。** > **用户拥有查询、更正、删除、撤回和注销渠道。** > **安全状态优先于普通业务状态。** > **诈骗和骚扰重点预防，但风控规则不能随意给用户定罪。** > **任何严重后台操作都必须知道是谁、什么时候、为什么做的。** 最终目标不是让用户感受到： > “平台有很多安全功能。” 而是做到： > **即使用户不知道这些安全机制存在，系统仍然在身份、数据、权限、沟通和线下服务的每一个环节持续保护用户。**