MeshLaw 安全白皮书

1. 系统构成

托管: Vultr 首尔区域 — 数据驻留于韩国。运营 SSH: 仅密钥认证（已禁用密码）。

2. 租户隔离

2.1 PostgreSQL Row-Level Security

所有领域表均启用 FORCE ROW LEVEL SECURITY:

• 直接隔离（team_id 列）: matters, clients, advisories, audit_log, notifications, llm_usage, team_token_quota, messages, device_tokens, stripe_webhook_events, invoice_receipts
• JOIN 隔离（matter_id → matters.team_id）: matter_events, invoices, timesheet_entries, writs, approvals, matter_refs, vault_files, matter_acl, deadlines

策略: team_id = app_current_team_id()（USING + WITH CHECK）。app_current_team_id() 读取事务 GUC app.team_id。

2.2 NOSUPERUSER ROLE 分离

运营网关以 meshlaw_app（NOSUPERUSER · NOBYPASSRLS）ROLE 连接数据库。dev / 迁移工具分离为独立的 superuser — 日常运营流量中不会混入具备 BYPASSRLS 的用户。2026-05-05 起应用。

2.3 事务 GUC 注入

sql.begin(async (tx) => 
  await tx`select set_config('app.team_id', ${teamId}, true)`
  await tx`select set_config('app.user_id', ${userId}, true)`
  return fn(tx)

由于是 SET LOCAL，事务结束时会自动释放。50/50 的领域操作均应用了该 wrap。其余 7 处为有意保留的 raw，例如 auth.signup/login 中的 password_hash 查询 — 不存在数据泄露路径。

2.4 JWT → ctx.meta.user 映射

网关的 onBeforeCall 验证 JWT → 注入 ctx.meta.user = { id, team, role }。所有领域路由都包含在 AUTH_REQUIRED_PREFIXES 中，没有令牌则返回 401。

2.5 回归保护

租户隔离在每次部署前都会在 e2e §7（RLS）中进行回归测试:

• 未认证调用 → 401
• 无效 JWT → 401
• 有效 JWT 仅能访问本 team 数据 → 200

3. 个人信息保护（PII）

3.1 身份证号

存储: 使用 pgp_sym_encrypt 加密（BYTEA rrn_encrypted）+ 末尾 4 位（rrn_last4）。展示: 客户端 UI 通过 maskRRN() 强制脱敏 → XXXXXX-XXX{last4}。格式不符时返回空字符串（阻断 raw 展示）。8 项单元测试回归。

3.2 密码

以 bcrypt 哈希存储。客户端在输入时实时展示 4 项规则（8 位 / 字母 / 数字 / 特殊字符）。仅 HTTPS — iOS Release 构建未设置 NSAllowsArbitraryLoads。

3.3 令牌管理

• JWT: 短 TTL（默认 30 分钟），HS256
• Refresh: rotation + 重用检测。明文仅向用户下发一次，数据库仅存 bcrypt 哈希。检测到重用时会 revoke 整条 chain

3.4 案件级 ACL

在 RLS 的 team 范围之上，还有案件级的额外隔离（matter_acl）。4 种角色（owner ⊃ editor ⊃ viewer）。消息功能 v0.1.6 采用 — 查看案件频道列表需 viewer 及以上，写入需 editor 及以上。

4. 审计日志

自动记录到 audit_log 表的操作:

• 案件 CRUD、ACL grant/revoke
• 审批的通过/驳回/要求修改（status_before/after, comment）
• 账单开具、收款 receipt（delta_won, total）
• 用量 → invoice/timesheet 汇总
• 参考文档 CRUD

每行: actor_name, target_kind, target_id, http_status, matter_id, meta(JSONB), created_at。已应用 RLS — 无法查询其他租户的审计记录。

5. 权限控制

5.1 审批（matter approvals）

服务端 actor 守卫 — computeApprovalChainAdvance(steps, status, currentUserId)。仅与当前活动步骤的 approver_id 匹配的用户才能操作。不匹配则返回 403 NOT_APPROVER。桌面端与移动端使用同一守卫。7 项单元测试。

5.2 RBAC（系统角色）

users.role_id → roles 表（admin/partner/associate/staff）。auth.invite 负责授予角色（仅 admin 可签发）。

6. 数据处理

6.1 AI 模型调用

自托管 vLLM（Tailscale 内网）— 无外部 API 出站。LLM 请求正文（案件上下文·文档）不会离开本组织。在 llm_usage 表中记录调用的令牌与费用（RLS team 范围）。

6.2 文件（Vault）

• 存储: 服务器磁盘（storage_directory 按案件分离）
• 元数据: vault_files 表（file_name, mime, size_bytes, text_content）
• 索引: 提取文本后存入 text_content → ⌘K 统一搜索（应用 RLS）
• PDF 多模态: 用 mupdf 将页面转为 JPEG → vLLM 视觉编码器（不外发）

6.3 邮件

Resend 域名 meshlaw.ai（已验证 DKIM/SPF/DMARC）。内容: 仅注册·邀请·密码重置 — 不含案件内容。

7. 基础设施安全

7.1 传输

网关: 仅 HTTPS（Caddy）。iOS Release / Android Release 均仅使用 prod URL（仅 Debug 使用 localhost）。

7.2 移动推送

• APNs JWT (.p8) — Apple Developer Team ID + Key ID
• FCM HTTP v1 — Firebase service account JSON
• 推送正文仅为元数据（title/body + data.type 路由 hint）— 不含案件正文
• 设备令牌: device_tokens 表（RLS team 范围）

7.3 运营访问

• SSH 访问: 基于密钥的认证（运营推荐）
• 数据库: docker-compose 将其绑定到 127.0.0.1:54322，即 仅 localhost 绑定 — 不暴露于外部互联网。仅主机内的网关容器可访问（network_mode: host）
• 备份: /var/backups/meshlaw-db-*.sql.gz（目前手动，计划自动化）
• 应用迁移前必须先备份（运营纪律）

7.4 Stripe 支付

Webhook 签名验证 + 幂等性守卫（stripe_webhook_events）。卡信息保存在 Stripe Vault — 本方不存储（最小化 PCI 范围）。

8. 合规态势

⚠️ ISMS-P / KISA 标识处于评估阶段。认证标识的使用仅在取得后方可进行。

9. 事件响应

9.1 令牌泄露

检测到 refresh 重用时，自动 revoke 该用户的整条 chain。调用 /auth/logout 或更改密码 → revoke 全部 refresh。

9.2 数据暴露

发现后立即执行 docker-compose 回滚 + 数据库备份恢复。

9.3 用户通知

政策目标: 在 72 小时内告知影响范围·恢复流程·用户需采取的操作（个人信息保护法 §34 建议级别）。目前尚无自动化 — 发生时由运营人员手动计算影响范围并批量发送邮件。

10. 数据迁移与删除

• 导出: 用户可将本 team 数据导出为 JSON（计划于 v0.2）
• 删除: 通过 UI 直接删除 + 账户删除通过邮件申请 → 30 天宽限期 → cascade
• 保留: 默认无限期。法定强制保留（如所得税法 5 年等）由用户负责

11. 验证请求

如需对本白皮书进行事实验证或尽职调查配合，请通过联系页面或销售负责人的邮箱提出请求 — 我们将提供代码路径（行号）· 迁移 SQL 副本 · 渗透测试结果（执行后）。

专用安全邮箱（如 compliance@meshlaw.ai）将在域名验证及运营准备完成后另行公告。