3. 安全工程基础与合规约束

跨机构联合计算的安全工程，第一步不是选框架、搭集群，而是把“哪些数据能碰、能碰多少、能用来干什么、干完留下什么痕迹”这四件事说清楚。它们分别对应合规要求中的合法性基础、最小必要、目的限制与审计追溯。本节从法规约束出发，落到可执行的工程原则，并给出一个可复用的合规约束映射表。

一、三部法规的约束焦点不同，但共同指向“可控可证”

《数据安全法》的核心是数据分类分级保护与数据处理活动的全流程安全。它要求建立数据分类分级制度，对重要数据实行更严格的管理，并在数据出境、委托处理、开放共享等场景中明确安全义务。对联合计算而言，最直接的影响是：参与方必须先判定各自输入数据的级别，重要数据原则上不出域，一般数据也需在受控环境中使用。

《个人信息保护法》聚焦个人信息处理规则，强调告知同意、单独同意、最小必要、目的限制、可携带权与删除权。联合计算中若涉及个人信息，必须回答：是否取得了个人的有效同意？同意范围是否覆盖本次联合计算的目的？计算完成后原始数据与中间结果如何删除？特别地，若联合计算涉及“向其他处理者提供个人信息”，需履行告知并取得单独同意，除非符合法定豁免情形。

GDPR 的约束逻辑与 PIPL 高度相似，但更强调数据主体的权利、数据保护影响评估（DPIA）、数据保护官（DPO）参与、跨境传输的充分性认定或适当保障措施。对于跨境联合计算，GDPR 要求传输前完成合法性评估，并采用标准合同条款（SCC）或约束性公司规则（BCR）等工具。三部法规的共同底线是：处理活动必须有合法性基础，处理范围必须可控，处理过程必须可证明。

二、四项工程原则：把法规语言翻译成系统约束

最小必要不是“少拿点数据”，而是“只取完成目标所需的最小字段、最小粒度、最小时间窗口”。工程上可落为字段白名单、行级过滤、时间窗口裁剪和采样率上限。例如，联合风控场景中，若只需判断“近 90 天是否有逾期”，则不应传输完整还款流水，而应传输“逾期标签 + 时间戳”或经本地聚合后的布尔值。

目的限制要求数据用途与收集时的目的保持一致。工程上通过“目的标签”绑定数据与计算任务：每个数据集携带 purpose_id，计算任务提交时声明 purpose_id，调度器校验二者匹配才允许执行。这样可防止数据被二次用于未授权目的。

审计追溯要求每一次数据访问、每一次计算、每一次结果输出都可回溯到主体、时间、目的和授权依据。工程上需要记录：谁在何时、以什么目的、访问了哪些数据、执行了什么算子、输出了什么结果、结果被谁取走。日志本身也要防篡改，通常采用哈希链或写入不可变存储。

数据最小化与去标识化是上述原则的技术支撑。联合计算中常用的手段包括：本地差分隐私、安全聚合、k-匿名、假名化。需要强调的是，去标识化不等于匿名化；若仍可结合辅助信息重识别，仍属个人信息，仍受 PIPL 与 GDPR 约束。

三、合规约束映射表：从条款到可执行字段

把法规要求落到系统，最有效的方式是建立一张“约束—控制—验证”映射表。下表给出一个可参考的示例结构，字段可根据实际项目裁剪。

四、一个可执行的合规检查清单

在联合计算任务上线前，建议按以下清单逐项确认。清单不是形式，而是把“合规”从法务文档变成工程门禁。

1. 合法性基础确认：本次联合计算涉及的个人信息，是否已取得告知同意或单独同意？若依赖合同履行、法定义务等其它合法性基础，是否有对应依据？
2. 数据级别判定：各参与方输入数据是否已完成分类分级？是否包含重要数据？若包含，是否满足不出域要求？
3. 最小必要审查：所需字段是否逐项列出并说明必要性？是否可用聚合值、标签值替代原始明细？时间窗口是否已裁剪到最小？
4. 目的绑定检查：数据集是否已绑定 purpose_id？任务提交时是否声明用途？调度器是否已配置校验规则？
5. 去标识化与隐私预算：是否采用差分隐私、k-匿名或安全聚合？ε 预算、k 阈值、输出行数下限是否已设定并记录？
6. 审计日志完整性：访问、计算、输出三类日志是否齐全？日志是否防篡改？留存期限是否明确？
7. 删除与留存：计算完成后原始数据、中间结果、日志的删除或留存策略是否明确？删除证明如何生成与保存？
8. 跨境传输评估：若涉及跨境，是否已完成出境安全评估或采用 SCC/BCR？是否完成 DPIA？

五、工程落地中的参数示例

以下参数为教学示例，用于说明如何把原则量化为可配置项，并非实测结果。实际项目应根据数据敏感度、业务需求和监管要求调整。

# 联合计算任务合规配置示例（教学用）
task:
  purpose_id: "credit_risk_2024Q3"
  data_fields:
    - user_id_hash        # 假名化后的用户标识
    - overdue_flag_90d    # 近90天逾期标签，布尔值
    - apply_count_30d     # 近30天申请次数，整数
  row_filter: "apply_count_30d > 0"
  time_window: "2024-07-01 ~ 2024-09-30"
  privacy:
    method: "differential_privacy"
    epsilon: 1.0          # 隐私预算，越小越安全但可用性下降
    min_output_rows: 50   # 输出结果最小行数，防止小群体推断
  audit:
    log_access: true
    log_compute: true
    log_output: true
    hash_chain: true
  retention:
    raw_data_days: 0      # 计算完成后立即删除
    intermediate_days: 7  # 中间结果保留7天用于排障
    audit_log_days: 365   # 审计日志保留1年

这份配置中，epsilon=1.0 表示在差分隐私下允许的隐私损失预算，数值越小隐私保护越强，但统计结果的可用性会下降；min_output_rows=50 用于防止输出结果过细导致个体被推断；raw_data_days=0 表示计算完成后原始数据立即删除，只保留审计日志和删除证明。这些参数需要在任务提交时由合规负责人与数据负责人共同确认，并写入任务审批记录。

合规不是一次性的文档工作，而是贯穿数据接入、任务执行、结果输出、生命周期终结的持续控制。把法规条款翻译成系统字段和校验规则，把原则固化为配置项和日志证据，才能让跨机构联合计算在“可用”与“可控”之间取得平衡。