数据治理与隐私运营

本文说明 IMCore Ultimate 提供的数据治理控制：经代码审查的数据清单、访问/导出与删除请求流程、法律保留、可配置保留期限、审计证据，以及默认关闭的破坏性执行模式。

本文是能力与运维指南，不是认证或法律意见。私有化部署方通常决定其部署中的处理目的与方式，仍须自行负责告知、处理依据、请求人身份核验、处理者协议、跨境传输、保留期限、事件响应和当地法律审查。

能力清单

领域 用途 主要存储 主体定位 内置动作
用户资料与通讯录 展示身份、企业通讯录 chat_user_profiles、enterprise_members user_id 导出、删除
社交关系 好友、拉黑、白名单、群/社区成员 关系、群组、社区相关表 参与者/用户字段 导出、删除
消息 单聊、房间、群聊、社区投递与历史 消息相关表 已索引的发送者字段 导出本人发送记录、发送者假名化
设备投递 推送与重试 push_devices、push_tasks user_id 脱敏导出、删除、定期清理
内容治理 安全决策与事件复核 chat_moderation_logs user_id、target_user_id 导出、删除、定期清理
AI 使用 消息/工具审计与用户记忆 AI 审计/记忆表 user_id 导出、删除、定期清理
管理员证据 问责与事件调查 admin_audit_logs 目标元数据 定期清理
治理证据 主体请求、法律保留、清理运行 data_subject_requests、data_legal_holds、data_retention_runs subject_user_id 案件与运行证据

管理台“系统 → 数据治理”展示同一份代码审查清单。部署方还必须把 IMCore 无法发现的系统纳入盘点：对象存储桶、CDN 缓存、数据库副本、备份、日志平台、分析仓库、客服工具和下游处理者。

安全部署

  1. 通过迁移工具应用 20260710_create_data_governance.sql 与 20260818_complete_data_governance.sql：

    make migrate
bin/migrate -status
bin/migrate

    完成迁移会创建按范围的消息保留策略、归档清单、抹除标记、法律保留范围，以及不可变审计链状态与触发器。请按数据库类型应用 migrations/mysql/ 或 migrations/postgres/ 中对应文件。

    该迁移会回填历史 DM 以及两份房间历史的发送者索引。消息表较大时应先备份、评估锁表与耗时并安排维护窗口；默认 10 分钟迁移超时不足时，使用 bin/migrate -timeout 1h（或经评审的值）显式延长。

  2. governance:read 只授予审查人员，governance:write 只授予获授权的隐私/安全运营人员。内置超级管理员拥有两项权限，运维角色不会自动获得。

  3. 在保留策略和操作手册通过审查前，保持破坏性执行关闭：

    governance:
  execution_enabled: false
  pseudonym_salt: ""
  requests:
    default_due_days: 30
  retention:
    scheduler_enabled: false
    interval_hours: 24
    batch_size: 1000

  4. 将稳定的假名化密钥保存在源码之外，例如 IMCORE_GOVERNANCE_PSEUDONYM_SALT。丢失或随意变更会导致假名不一致，泄露会削弱隔离效果。应按生产密钥备份，只有在经过审查的迁移计划中轮换。

  5. 先运行保留清理预览，抽样核对记录，验证恢复与下游删除流程，并获得策略/法务批准。

  6. 之后才设置 IMCORE_GOVERNANCE_EXECUTION_ENABLED=true。人工执行验收后，再单独启用 IMCORE_GOVERNANCE_RETENTION_SCHEDULER_ENABLED=true。

删除与保留清理都采用失败关闭。删除要求执行开关与假名化密钥同时配置；定时清理要求调度与执行开关同时开启；调度器不会在服务启动时立即运行。

数据主体请求流程

  1. 受理与身份核验： 在 IMCore 之外核验请求人；登记 access（访问/导出）或 erasure（删除）案件，填写来源、原因与期限。不要把身份证件放入自由文本原因字段。
  2. 审核： 确认范围、身份、处理依据/审批授权、例外和争议。批准时必须填写处理依据/授权，驳回时必须填写审核说明。
  3. 法律保留检查： 如果涉及诉讼、调查、欺诈、安全或其他保存义务，应先创建主体法律保留。有效且未到期的保留会阻止删除，并把主体相关记录排除在保留清理之外。
  4. 执行： 先停用来源业务账号并撤销客户端令牌，防止数据被重新创建，再输入完全一致的数据主体用户 ID。访问请求生成新的结构化 JSON 导出；删除请求强制登出当前 IMCore 会话、移除直接归属数据，并对为其他参与者保留的消息发送者与会话标识做确定性假名化。
  5. 交付与关闭： 通过 IMCore 之外的已认证、限时通道交付导出，在组织的案件系统中记录交付、决定函和残留系统处理结果。

导出响应设置 Cache-Control: no-store，遮蔽推送凭证，并包含不带签名 URL 的附件清单（object_key、thumbnail）。导出接口本身仍是敏感面：反向代理、浏览器下载和运营人员终端都要落实相应控制。

删除边界

内置删除覆盖数据清单中的数据库表，会为发现的附件写入持久化 data_erasure_markers，通过对象存储删除对象，并尽力清理 Redis 缓存。对象删除失败时可使用 governance -command replay-erasure 重放。系统不会在自由文本消息中做字符串替换，因为这可能破坏其他参与者的记录并产生误匹配。

关闭案件前，还要单独处理：

  • S3/OSS/MinIO/本地对象存储中的附件、缩略图和录音；
  • 数据库副本、搜索索引、数据仓库、分析系统与日志/SIEM；
  • 消息队列、死信队列和离线导出；
  • 备份与快照，包括数据何时自然到期、恢复后如何重放删除标记；
  • 下游处理者、集成系统和客户业务系统；
  • 外部身份/账号系统，以及任何可重新连接并重建主体数据的凭证；
  • 其他人在自由文本中提到该主体的内容；
  • 基于法定或合同例外继续保留的记录。

可行的备份策略通常包括：删除后不再允许日常访问；按已公布的备份周期自然淘汰；恢复只用于获授权的事件；恢复后立即重新执行已批准的删除标记。

保留策略

消息保留、归档与恢复

消息策略范围为 version、session 或 group，scene 可限定为单聊、房间、群组、社区或全部消息。当前版本由 governance.message_retention.version（默认 default）选择；匹配的会话/群策略优先于版本策略。超过 hot_days 的记录会先以 JSON 写入对象存储 governance/message-archives/，生成 SHA-256 清单后才从热库删除。执行必须打开 governance.archive.enabled=true，archive.storage_class 控制对象存储冷热层级。v2 归档同时包含群受众、社区提及和消息回执。

可使用 governance -command retention 输出 JSON 证据，使用 governance -command restore-archive -archive-id <id> 执行受控恢复。

示例默认值只是部署模板，不是法律建议：

策略键 默认值 范围
admin_audit_days 365 天 管理员审计日志
moderation_logs_days 180 天 内容治理证据
ai_message_audit_days 180 天 AI 消息审计
ai_tool_audit_days 90 天 AI 工具调用审计
push_tasks_days 30 天 推送任务历史
governance_requests_days 1095 天 已完结的数据主体请求证据
legal_holds_days 1095 天 已解除或已到期的法律保留证据；有效保留永不进入清理范围
retention_runs_days 1095 天 已完成的保留清理运行证据

设为 0 可关闭某项策略。每次人工或定时运行都会在 data_retention_runs 记录策略快照、模式、状态、摘要、操作者与时间。策略或 schema 变化后必须先预览。法律保留只能保护配置了主体字段的策略；全局基础设施审计证据可能还需要独立的案件标记与保存流程。

API 与审计面

管理端 JWT 与 RBAC 保护的接口位于 /admin/api/governance：

  • GET /overview
  • GET|POST /requests、GET /requests/{id}
  • POST /requests/{id}/review、POST /requests/{id}/execute、GET /requests/{id}/export
  • GET|POST /legal-holds、POST /legal-holds/{id}/release
  • POST /retention/run
  • GET|PUT /message-retention-policies、DELETE /message-retention-policies/{id}
  • GET /message-archives、POST /message-archives/{id}/restore

审计完整性可通过 GET /admin/api/audit-logs/integrity 或 governance -command verify-audit 校验，结果包含签名、历史未签名和链异常记录；数据库触发器会拒绝审计记录 UPDATE/DELETE。

完整请求/响应契约在 controllers/openapi/service.openapi.yaml，服务通过 /openapi.yaml 和 /openapi.json 提供。变更操作和主体导出都会进入管理审计。人员条件允许时，应把审计查看与请求执行职责分离。

法规能力映射

以下映射只帮助审查人员定位产品控制，不判断法规是否适用，也不证明合规。

  • 《个人信息保护法》第四十五至五十条涉及查阅/复制、更正、删除和便捷的请求机制。IMCore 的访问导出、审核后删除、处理期限和证据流程支持其中的访问与删除环节；更正仍需在部署方案件流程下使用既有资料/业务系统 API。参见国家网信办官方文本。
  • GDPR 第 5 条包含数据最小化、存储期限限制与问责原则；数据清单、保留预览和运行证据可支持这些运营原则。参见官方第 5 条。
  • GDPR 第 15 条涉及访问与副本，结构化导出可用于支持响应。参见官方第 15 条。
  • GDPR 第 17 条规定删除权及其例外；审核、法律保留与假名化流程可支持实施，但不会替部署方判断是否必须批准。参见官方第 17 条。

发布与事件检查表

  • 新增数据表、消息字段、存储提供商或处理者时，更新并复核数据清单。
  • 执行 make secret-check；真实密钥不得进入被跟踪文件或构建产物。
  • 任何曾提交到仓库的凭证都必须轮换。仅从当前文件删除不会撤销凭证，也不会清除 Git 历史；历史重写属于另一个需要协调的操作。
  • 使用合成用户在类生产环境测试访问、保留、删除和定期清理。
  • 验证权限、审计、TLS、代理缓存、下载处理与运营终端安全。
  • 记录备份淘汰、恢复后删除标记重放、处理者通知和事件负责人。
  • 每个部署的最终期限、告知和例外处理都应由法务/隐私审查人员批准。