FDE W6D5 学习手册 · 数据脱敏 · 租户隔离 · Human Approval · 安全审计与 OWASP

W6 Day5 · [A][B][C] 级（合规与安全的工程落地）· 4h · 学完能讲清"特药理赔 Agent 如何在合规前提下不泄露 PII、不串租户、不误触高风险动作"

一、数据脱敏的本质：什么是 PII，为什么要脱敏

PII（Personally Identifiable Information，个人可识别信息）指能直接或间接定位到某个自然人的数据。在特药理赔场景里，典型的 PII 包括：

• 直接标识符：身份证号、手机号、姓名、病历号、保单号、银行卡号、人脸/基因。
• 准标识符（quasi-identifier）：出生日期 + 性别 + 投保城市 + 病种组合，单独不算、组合可重识别（re-identification）。
• 敏感数据：诊断结果、用药记录、理赔金额、拒赔原因——即便去掉姓名，结合背景也能识别个人。

脱敏（Data Masking / De-identification）的目标：在保留数据可用性的前提下，把"能识别个人"的能力降到合规可接受的水平。它不是加密（加密可还原、仍属敏感数据），而是让数据本身不再直接指向个人。

二、PII 脱敏必须在哪些环节做（全链路）

一个理赔 Agent 的请求链路：用户->网关->API 服务->提示词拼接->LLM->结果解析->业务系统->日志/Trace/前端。PII 可能在每一个环节泄漏，所以要在多个点做脱敏：

三、三种脱敏技术：掩码 / 哈希 / 令牌化

3.1 掩码（Masking）

保留字段结构但隐藏部分内容：110101********1234。最简单，可逆性差（通常设计成不可逆），适合展示层和日志。

3.2 哈希（Hashing）

用单向哈希（SHA-256 + 盐）把 PII 变成定长字符串。适合去重/关联（同一身份证哈希值相同，可跨系统关联而不暴露原文），但注意黑客彩虹表攻击——低熵数据（如手机号）直接哈希可被反查，必须加盐（salted hash）或 HMAC。

3.3 令牌化（Tokenization）

用令牌库（vault）把真实 PII 换成一个无意义的 token（如 tk_a91f），真实值存在受控的令牌库里。需要还原时凭 token 换回。这是最安全、最灵活的方案，适合需要精确检索/回写业务系统的场景。

四、工程含义：脱敏落地的真实难点

• 可用性 vs 隐私的拉扯：检索"张伟的理赔记录"需要姓名，但脱敏后姓名没了就检索不了。解法：用 token 检索（用 token 索引，原文在令牌库）。
• 准标识符重识别：去掉姓名仍可能通过"性别+年龄+城市+病种"锁定到唯一人。需做 k-匿名（k-anonymity）评估。
• 脱敏一致性：同一条身份证在日志、Trace、数据库里要脱成同一个 token，否则无法关联调试。
• 模型仍可能"记"：即使 prompt 里是 token，模型可能从上下文推理出身份；输出后处理是最后一道闸。
• 合规跨境/留存期：原始 PII 存多久？过期删除（对应 W6D6 的 Memory 删除）。

五、租户隔离的本质：多客户数据不能串

如果 Agent 服务多个保险公司/多个企业客户（多租户），租户 A 的理赔数据绝不能被租户 B 看到。这是安全（防越权）也是合规（数据不出域）的双重要求。

• 逻辑隔离：同一套系统、同一数据库，靠 tenant_id 字段区分，所有查询强制带租户过滤条件。
• 物理隔离：每个租户独立库/独立向量库/独立部署，最彻底但成本高。
• 混合：共享计算、隔离存储（最常见）。

六、RAG 中的 Chunk 级 ACL 与 Agent 层隔离

在 W3/W4 的 RAG 里我们讲了分块（Chunk）与向量检索。当知识库是多租户共享但权限不同时，需要给每个 Chunk 打 ACL 标签：

• Chunk 级 ACL 是 RAG 隔离的最小单元：比"整库隔离"更细，支持"同一租户内、不同角色看不同文档"。
• 检索后过滤（post-filter）最常见：先向量召回，再按 ACL 裁掉无权限的；注意要"召回数 > 最终数"，避免过滤后不够用。
• 检索前过滤（pre-filter）：向量库支持 metadata 过滤（如 Milvus/Weaviate 的 filter 表达式），在召回阶段就带上 tenant_id + 角色条件，更安全也更省 token。

七、隔离的工程实现：向量库 namespace / RBAC / 行级过滤

八、Human Approval：高风险动作必须人工确认

Agent 能自主决策，但有些动作一旦执行不可逆或影响重大，必须"先让人点确认"：

• 资金类：自动退款、放款、赔付转账。
• 拒赔/拒保决策：直接影响用户权益，监管要求可追溯。
• 外部调用：发短信/发邮件给客户、调用第三方 API 产生费用或副作用。
• 删除/覆盖数据、发布新版本（见 W6D7）。

Human Approval 的模式：

九、Human Approval 与 W4 HITL 的关系

一句话：HITL 是"大哲学"，Human Approval 是它里面对"高风险动作"的具体安全实现。面试时能把两者关系讲清，会显得你对"人机协同"有体系化理解，而不是只背概念。

十、安全审计：全链路留痕

审计（Audit Logging）回答"谁、在何时、基于什么、做了什么、结果如何"。对保险场景，这是合规底线（可追溯、可追责）。

• 不可篡改：审计日志写 WORM 存储或区块链式追加，防内部篡改。
• 与 Trace 联动：每条审计记录带 trace_id，可回溯到完整 LLM 调用链（Langfuse）。
• 全链路：不只是"最后拒赔了"，而是从检索到决策到执行的每一步都留痕。
• 敏感字段脱敏：审计日志本身也不能存明文 PII（呼应 s2）。

十一、OWASP LLM Top 10 总览

OWASP 发布的 LLM Top 10（genai.owasp.org/llm-top-10）是当前最权威的 LLM 应用安全风险清单。面试要能说出关键几条并对应到你的工程实践：

十二、OWASP Agentic 安全风险对照表

OWASP 后续又出了 Agentic Security Initiative（面向 Agent 的专项风险），相对 LLM Top 10 更聚焦"Agent 自主行动"带来的新风险。对照如下：

十三、面试达标线①：PII 脱敏在哪些环节做、为什么

十四、面试达标线②：租户隔离怎么实现、和 Chunk ACL 的关系

1. 数据库层：行级安全或统一拦截器强制 tenant_id 过滤，防漏写。
2. 向量库层：namespace/partition 按租户，检索用 filter 表达式带 tenant_id + role（pre-filter 最安全）。
3. Chunk 级 ACL：是 RAG 知识库层的最小隔离单元，比整库隔离更细，支持同租户内按角色区分可见文档；可 pre-filter 也可 post-filter，推荐 pre-filter。
4. 延伸到 Agent 层：Agent 的工具调用、记忆读写、拼装上下文都带租户/权限标签并强制校验——这是 Chunk ACL 在 Agent 时代的升级。
5. 运行时透传：JWT 带 tenant claim，全程透传并在每层的服务端校验，不信任客户端传入的租户参数。

十五、W6D5 自测清单

十六、高频面试题速记卡