导出 CSV 前先回答能否重新识别：用 deident 把脱敏策略、风险报告和密钥边界写进数据流程
把一份生产 CSV 交给测试、分析或外部协作方时，最危险的往往不是“忘了删邮箱”这样显眼的失误，而是把几个看似普通的字段一起留下：年龄、邮编、入院日期、地区、订单时间。它们单独未必指向一个人，组合起来却可能让外部数据集完成重新识别。更麻烦的是，团队常把“用 hash 替换姓名”和“已经匿名化”混为一谈：前者通常仍可关联、也可能可逆；后者需要说明删了什么、泛化了什么，以及剩余风险在哪里。
deident 是一个 Apache-2.0 开源的 Rust CLI，面向 CSV、JSONL/NDJSON、Parquet 和 DICOM 元数据的隐私转换。它用 YAML 策略明确列出字段角色，再分别执行可关联的伪名化（pseudonymize）或移除、分桶、截断等匿名化（anonymize）；同时可产出 JSON 风险报告。它的价值不在于承诺“一键合规”，而在于把数据导出前原本隐含的取舍变成可审查的配置和可复跑的命令。
先区分两种输出：可关联不等于匿名
工具将字段分为直接标识符、准标识符、敏感字段和工具字段。姓名、邮箱、患者 ID 属于直接标识符；年龄、邮编和日期常是准标识符；诊断或薪资可能是敏感字段。分类不是装饰：它决定不同模式下默认应如何处理。
pseudonymize 会为直接标识符生成确定性 token。相同输入在同一策略和密钥域中仍会得到相同 token，因此多张表可以保留 join 能力。这适合需要真实数据结构来调试、但不希望暴露原始身份的内部测试。不过输出依然是个人数据：持有密钥材料的一方可以重建映射，攻击者也可能借助辅助信息关联记录。
anonymize 的目标不同：直接标识符默认移除，准标识符按策略分桶、截断或遮蔽。它会统计等价类和唯一行等风险信号，但 README 明确说明这是风险评估，不是对“绝对匿名”的认证。外部数据、业务语境与字段组合仍会改变风险，所以报告应成为发布审批的输入，而不是盖章文件。
从一份拒绝漏列的策略开始
项目当前要求 Rust 1.96+。克隆仓库后，官方 README 给出的 CLI 安装方式如下：
git clone https://github.com/ikuV/deident-wasm.git cd deident-wasm cargo install --path crates/cli deident --help
关键步骤不是先跑命令，而是写出覆盖所有列的策略。下面的示例来自其策略模型的简化版：on_unlisted: error 让未知列直接失败，避免生产系统后来加了一列 phone 或 email_address 后被原样带出；字段名需要与 CSV 表头精确匹配。
version: 1
dataset: patients-demo
key:
env: DEIDENT_KEY
on_unlisted: error
fields:
- name: patient_id
class: direct_identifier
pseudonymize:
prefix: "pid_"
- name: email
class: direct_identifier
- name: age
class: quasi_identifier
anonymize:
strategy: bucket
width: 10
- name: zip
class: quasi_identifier
anonymize:
strategy: keep_prefix
chars: 3
- name: admission_date
class: quasi_identifier
anonymize:
strategy: date_truncate
granularity: year
- name: diagnosis
class: sensitive
- name: notes
class: utility
这个策略没有把 diagnosis 自动删除，因为“敏感”不等于在所有用途下都不可用；它要求数据负责人按导出目的决定。相反，年龄被分成十年桶、邮编只保留前三位、日期只留年份，目的就是降低准标识符组合的区分度。若下游确实需要更细的维度，应先用风险报告评估，再考虑缩小导出范围或增加受控访问，而不是直接跳过泛化。
密钥不要写进 YAML。示例用环境变量引用密钥名，运行前在受控终端或 CI secret 中设置：
export DEIDENT_KEY='replace-with-a-secret-from-your-secret-manager' deident pseudonymize patients.csv --policy patients.yaml --out patients-pseudo.csv
确定性 token 能帮助保留跨表关联，但也意味着密钥、策略和输出文件必须分开管理。尤其不要把 DEIDENT_KEY、加密映射 vault 与脱敏文件一起上传到同一个临时对象存储桶；那会让“去标识化”退化成一次文件改名。
匿名化时，把风险报告带进检查链
面向培训、分析共享或较低信任边界时，可用不可逆模式生成输出与报告：
deident anonymize patients.csv --policy patients.yaml --out patients-anon.csv --report patients-risk.json
报告会记录行数、标识符处理动作、内容模式发现和等价类统计。这里最值得关注的不是某个漂亮的“通过”状态，而是唯一行和小等价类：如果“年龄桶 + 邮编前缀 + 年份”组合仍只对应一行，说明这些字段的组合仍很尖锐。解决方法可能是进一步扩大年龄桶、减少邮编位数、移除日期，或干脆不把该数据集交付给该接收方；选择取决于具体用途与威胁模型。
运行前也应单独检查策略。lint 用于发现语法上有效但风险较高的配置；需要把警告变成 CI 失败时可使用 --deny：
deident lint patients.yaml --mode anonymize --deny
把这一步放在导出 job 的前面，比事后检查生成文件更稳妥。任何未列出的列、策略字段拼写差异或高风险规则，都应阻断流水线并要求策略审查，而不是由脚本静默“尽力处理”。
自由文本是第二条泄漏通道
列级规则无法覆盖 notes、客服备注或错误日志中嵌入的标识符。deident 提供内容模式规则，可使用内置检测器或自定义正则，对指定列执行发现、遮蔽、token 化或生成格式合法的 mock。例如下面规则扫描备注中的 IBAN，并将匹配内容遮蔽：
patterns:
- name: iban
builtin: iban
fields: [notes]
action: redact
这一步不能替代对业务文本的抽样审查。工具的内置检测器覆盖邮箱、IBAN、卡号、电话、IP、URL、API key 等多种模式，其中部分还会做校验和或结构解析来减少误报；但它不可能理解每个团队自定义的客户号、工单号或自然语言上下文。对高风险字段，应添加项目专属规则，并将命中数量的异常增长纳入发布告警。
如果下游系统必须接受格式合法的测试数据，mock 看似方便，但要知道它仍是带密钥的伪名形式，不是匿名化。README 也特别提示有限格式空间会发生碰撞：需要可靠回溯或稳定主键时，优先使用足够长的 token，不要为“看起来像真实手机号”牺牲映射正确性。
WebAssembly 沙箱解决什么，不能解决什么
deident 可将作业放入 Wasmtime/WASI WebAssembly 沙箱：每个作业是新的实例，只看见一个预打开的工作目录，不提供网络，并可设置内存、超时和 CPU fuel 限制。官方构建步骤如下：
rustup target add wasm32-wasip1 cargo build -p deident-worker --target wasm32-wasip1 --release deident anonymize patients.csv --policy patients.yaml --out patients-anon.csv --engine wasm
这层隔离适合降低处理畸形输入或未来不可信扩展时的影响面，但不是数据治理的替代品：输入仍在宿主机被读取，密钥仍要由调用方保护，输出仍可能因策略过宽而泄漏。还要注意 Parquet 当前不在沙箱 guest 中处理；自动引擎会回退到进程内模式并提示。因此若流程的隔离要求是硬门槛，应该在上线前对实际格式、引擎选择和日志路径做验收，而不是只看到命令成功就默认已经沙箱化。
让策略像代码一样接受审查
一条可落地的导出流程可以是：先由数据负责人维护版本化 YAML；CI 用 deident lint 审核策略；任务以最小权限读取输入和密钥；转换后保留风险报告与仅含元数据的审计记录；最后由接收目的、等价类风险和字段必要性共同决定是否交付。CSV、JSONL 可以流式处理，而 Parquet 需要关注内存消耗，因此大文件也应先在接近生产规模的副本上压测。
最重要的变化是把问题从“我们删掉名字了吗？”改成“哪些字段仍能关联、谁持有密钥、剩余风险是否符合这次交付目的？”deident 不会替团队做这三个判断，但它提供了更可靠的工程载体：可读策略、可复现命令、失败即停止的列覆盖，以及能被复核的风险输出。
实施时还应把转换前后的访问边界分开记录：谁能读取原始文件，谁能读取脱敏结果，谁能使用密钥或映射 vault，报告保存多久，何时销毁临时文件。这样即使某次策略需要例外，也能追溯例外是为哪个业务目的设置、由谁批准、是否在到期后收回。技术转换只是控制链的一环；最小化导出范围、限制接收者权限和保留审计证据，同样决定数据是否真的被安全地使用。