3. 数据分类分级与敏感数据发现

数据分类分级不是一次性的合规动作，而是企业数据治理的“底账工程”。在 AWS 上，它通常由三条能力线协同完成：Amazon Macie 负责在 S3 中自动发现敏感数据并给出敏感度信号；AWS Glue DataBrew 负责对结构化与半结构化数据做可视化探查、模式识别和列级画像；标签策略（Tag Policies）与资源标签负责把分类分级结果固化为可被策略、权限、审计和成本系统共同识别的元数据。三者组合，才能把“发现—判定—标注—持续校验”串成闭环。

一、分类分级的基本模型

企业落地时，建议先定义两个正交维度：数据类别（它是什么业务数据）与敏感级别（泄露后影响多大）。类别回答“属于客户、财务、员工、设备还是公开信息”，级别回答“公开、内部、机密、绝密”。两者组合成矩阵，避免只按业务系统命名而无法跨系统比较。

一个可执行的示例分级如下（示例参数，非实测结果）：

级别一旦确定，就要映射到具体控制动作：L3 以上默认加密、禁止跨区域复制、访问需审批；L4 还需启用 Macie 持续监控、限制导出并记录数据访问事件。分级不是标签本身，而是标签触发的策略行为。

二、用 Amazon Macie 发现 S3 中的敏感数据

Macie 通过敏感数据发现任务扫描 S3 对象，使用内置或自定义的敏感数据标识符（managed data identifiers）识别 PII、凭证、金融信息等。典型操作路径是：先启用 Macie，再创建“定期任务”或“一次性任务”，指定桶、扫描范围、采样比例和自定义标识符，最后在发现结果中查看敏感类型、对象路径与严重级别。

关键参数需要结合成本与覆盖度权衡。例如对日志桶设置每周一次、采样 20%；对客户主数据桶设置每日一次、全量扫描。自定义标识符适合企业内部工号、订单号等正则模式，例如：

{
  "customDataIdentifier": {
    "name": "CN-ID-Card",
    "regex": "\\b[1-9]\\d{5}(19|20)\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])\\d{3}[0-9Xx]\\b",
    "keywords": ["身份证", "idcard"],
    "maximumMatchDistance": 50
  }
}

Macie 的发现结果会给出敏感类型与置信度，但不会自动替你决定业务级别。因此需要把 Macie 的 finding 与资产清单关联：若某对象命中“银行卡号 + 姓名”，通常应判为 L4；若仅命中“邮箱”，可判为 L3。这个映射规则应写入治理规范，而不是每次人工判断。

三、用 Glue DataBrew 做列级画像与模式识别

Macie 擅长对象级发现，DataBrew 则适合在数据准备阶段做列级画像。通过 DataBrew 的数据集连接 S3、Glue 数据目录或 JDBC 源，运行“数据剖析（profile）”任务，可以得到每列的数据类型、缺失率、唯一值数量、最小/最大值、频繁值以及疑似 PII 的统计。例如对客户表剖析后，发现 phone 列唯一值占比 98%、平均长度 11、匹配手机号模式，即可判定为 L3；id_card 列若匹配身份证正则且无空值，应升级为 L4。

DataBrew 的价值在于把“敏感数据发现”从对象级推进到字段级，并生成可复用的转换配方（recipe）。例如对 phone 列应用“掩码”或“哈希”转换，对 email 列做部分遮蔽，再把配方保存为治理资产。这样分类分级结果不仅能标注，还能直接驱动脱敏处理。

四、标签策略：把分级结果变成可执行元数据

标签是分类分级落地的“最后一公里”。建议至少定义四类标签：data-class（级别）、data-category（类别）、owner（责任团队）、retention（保留期）。通过 AWS Organizations 的标签策略，可以强制要求特定 OU 下的 S3 桶必须带 data-class，并限制取值只能来自 L1–L4 枚举。这样，未标注或错标的资源会在合规检查中暴露出来。

标签策略本身不直接阻止操作，但可与 SCP、IAM 条件键、Config 规则联动。例如：SCP 拒绝 s3:PutObject 到未标记 data-class=restricted 的桶；Config 规则检查所有桶是否具备合法标签；KMS 密钥策略按标签限制解密权限。这样分级就从“文档里的定义”变成了“运行时强制”。

五、资产盘点闭环与常见排障

完整闭环是：资产发现（Config 列出所有 S3 桶与 Glue 表）→ 敏感发现（Macie + DataBrew）→ 分级判定（规则引擎）→ 标签写入（API/自动化）→ 策略生效（SCP/IAM/KMS）→ 持续校验（Macie 周期任务 + Config）。每一步都要有责任人、频率和异常处理。

常见问题有三类：一是 Macie 任务范围过大导致成本上升，应按桶的重要性和数据量分层设置采样率；二是 DataBrew 画像只覆盖抽样数据，结论需标注置信度，不能直接当作全量结论；三是标签被手工修改导致级别漂移，应通过 Config 规则和定期对账发现并回写。建议每月输出一份“未标注/错标资源清单”，作为治理例会的输入。