📚 课程目录第4章 Schema安全定义

4、Schema安全定义：在数据契约中定义敏感字段

数据契约写好了，字段类型也定了。但有个关键问题——哪些字段是敏感的？

我见过太多团队，契约里全是字段名和类型，安全属性一个都没有。结果数据一流通，PII 泄露了，财务数据被谁拿了都不知道。说白了，Schema 安全定义就是给每个字段贴上“安全标签”。

这一节，我们就把这件事做扎实。

4.1 敏感字段识别：PII、财务数据、业务敏感数据

先搞清楚一件事：哪些字段需要保护？

我个人习惯把敏感字段分成三类：

个人身份信息（PII）：姓名、身份证号、手机号、邮箱、家庭住址、生物特征等。这类字段一旦泄露，直接涉及个人隐私。
财务数据：银行卡号、交易金额、账户余额、支付记录、发票金额等。这类字段是黑产最想拿的。
业务敏感数据：客户名单、定价策略、内部绩效、未公开财报等。这类字段泄露会影响公司竞争力。

我在项目中遇到过一件事：一个订单表，contract 字段存了 PDF 合同全文。开发同学觉得“反正就是个文件路径”，结果里面全是客户签名和身份证复印件。嗯，这就是典型的敏感字段识别遗漏。

我的经验：识别敏感字段时，别只看字段名。字段名叫 user_name 你肯定知道是 PII，但 remark、extra_info、attachment_url 这些“看起来无害”的字段，往往藏着大雷。

4.2 字段级别访问控制标签：Public / Confidential / Restricted

识别出敏感字段后，下一步就是打标签。

我推荐用三级标签体系，简单、清晰、好落地：

标签	含义	示例字段	访问控制策略
Public	公开数据	商品名称、分类、公开日期	全员可读，无需审批
Confidential	内部保密	客户姓名、手机号、邮箱	仅授权角色可读，需脱敏后使用
Restricted	严格受限	身份证号、银行卡号、密码	仅极少数角色可读，需审批+加密

你想想看，这个标签体系一旦嵌入数据契约，安全策略就变成了代码。不再是“安全部门发邮件说这个字段要保护”，而是契约里直接写着 access_level: "Restricted"。

核心原则：标签越少越好。三级足够，不要搞出什么 TopSecret / Secret / Internal / Public / Unclassified 五级，落地时没人分得清。

4.3 数据分类分级标准：如何与国家标准对齐

光有标签还不够，你得有个分类分级标准。不然每个团队都按自己的理解打标签，最后还是一团乱。

我建议直接参考国家标准 GB/T 37988-2019《信息安全技术数据安全能力成熟度模型》和行业监管要求。说白了，合规审计时，你得能拿出依据。

一个实用的分类分级框架：

分类维度：按业务域分，比如用户数据、交易数据、产品数据、财务数据、日志数据。
分级维度：按敏感程度分，比如 L1（公开）、L2（内部）、L3（敏感）、L4（核心）。
映射关系：L1 → Public，L2 → Confidential，L3/L4 → Restricted。

举个例子，用户数据域下的字段分级：

字段	分类	分级	访问标签
user_id	用户数据	L2	Confidential
phone_number	用户数据	L3	Restricted
id_card	用户数据	L4	Restricted
nickname	用户数据	L1	Public

注意：分级标准不是一成不变的。我曾经遇到一个场景，某个字段平时是 L2，但到了财报发布前一周，临时提升到 L4。所以契约里要支持动态调整，别写死。

4.4 在数据契约中定义安全属性

好了，理论讲完，上代码。

下面是一个完整的数据契约示例，包含了安全定义：

schema:
  name: "user_contact"
  version: "1.0.0"
  fields:
    - name: "user_id"
      type: "string"
      description: "用户唯一标识"
      classification: "user_data"
      sensitivity_level: "L2"
      access_level: "Confidential"
      encryption: false
      masking: false
    - name: "phone_number"
      type: "string"
      description: "用户手机号"
      classification: "user_data"
      sensitivity_level: "L3"
      access_level: "Restricted"
      encryption: true
      masking: true
      masking_rule: "保留前3后4"
    - name: "id_card"
      type: "string"
      description: "身份证号"
      classification: "user_data"
      sensitivity_level: "L4"
      access_level: "Restricted"
      encryption: true
      masking: true
      masking_rule: "保留前1后1"
    - name: "nickname"
      type: "string"
      description: "用户昵称"
      classification: "user_data"
      sensitivity_level: "L1"
      access_level: "Public"
      encryption: false
      masking: false

你看，每个字段都带上了分类、分级、访问标签、加密和脱敏策略。这就是数据契约的安全定义。

一个小技巧：我习惯在契约里加一个 security_audit 字段，记录这个安全定义是谁、什么时候定义的。方便追溯。比如：security_audit: { defined_by: "data_governance_team", defined_at: "2024-01-15", last_reviewed: "2024-06-15" }

4.5 整体逻辑：从识别到落地

这一节的内容，其实是一条完整的链路。我画了一张图，帮你理清思路：

这张图把整个流程串起来了。从识别敏感字段开始，到分类分级、打标签，最后写入契约并自动执行策略。每一步都环环相扣。

总结一下：Schema 安全定义不是写一堆文档，而是把安全策略编码化、契约化。字段级别的访问控制标签 + 分类分级标准，就是数据契约的安全骨架。有了这个骨架，后续的加密、脱敏、审计才能精准落地。