2. SaaS数据分类与资产盘点

SaaS 环境中的数据治理有一个显著特点：数据不在自己的机房里，而是分散在几十甚至上百个应用租户空间中，由业务人员自行创建、共享和导出。如果连“有哪些数据、在哪里、属于什么级别、谁在访问”都说不清，后续的加密、脱敏、权限收敛、审计告警都无从落地。本节围绕四件事展开：分级分类方法、敏感数据识别、数据地图构建，以及一份可直接使用的 SaaS 数据资产清单。

一、分级分类：先定“维度”，再定“级别”

分类和分级是两个不同动作。分类回答“这是什么数据”，按业务属性划分，例如客户身份数据、交易数据、合同文档、研发代码、运营日志、员工人事数据。分级回答“它有多重要”，按泄露、篡改、滥用后的影响程度划分。实践中推荐“先分类、后分级、再定标签”的顺序，因为同一业务类别在不同场景下级别可能不同。

分级维度建议至少覆盖三项：影响对象（个人、企业、监管）、影响类型（隐私、财务、合规、声誉）、影响程度（轻微、严重、灾难性）。据此可形成四级模型：

• L1 公开：官网文案、公开产品文档，泄露无实质影响。
• L2 内部：内部流程文档、非敏感运营报表，仅限员工访问。
• L3 机密：客户名单、合同金额、未公开财务数据，泄露造成业务损失。
• L4 绝密：身份证号、银行卡号、生物特征、核心源代码、密钥，泄露触发合规处罚或重大安全事件。

分级不是一次性标签，而应绑定“处理规则”。例如 L4 数据在 SaaS 中应满足：禁止明文导出、字段级加密或令牌化、访问需二次审批、操作全量留痕。级别与规则绑定后，分级才有执行力。

二、敏感数据识别：规则 + 上下文双通道

敏感数据识别不能只靠字段名匹配。SaaS 中常见字段名如 user_id、contact、remark，字面看不出敏感度，但内容可能是手机号或身份证号。因此建议采用“内容正则 + 上下文判断”双通道。

内容通道用正则和校验算法识别结构化敏感值，例如：

手机号（中国大陆）：^1[3-9]\d{9}$
身份证号：^\d{17}[\dXx]$
银行卡号：^\d{16,19}$ 且通过 Luhn 校验
邮箱：^[\w.+-]+@[\w-]+\.[\w.]+$

上下文通道判断“这个字段出现在哪张表、被谁访问、是否被共享到外部”。同一个手机号，出现在内部客服工单表与出现在对外营销导出文件中，风险等级不同。识别结果应输出三要素：数据对象、敏感类型、置信度。置信度低于阈值的进入人工复核队列，避免误报淹没告警。

三、数据地图：把“数据—应用—人—流向”连起来

数据地图不是一张静态表格，而是一张关系网络。它要回答四个问题：数据存在哪个 SaaS 应用、由哪个业务系统写入、被哪些角色访问、是否流向外部。构建步骤通常是：

1. 接入 SaaS 应用清单，获取租户、对象、字段元数据；
2. 对字段做分类分级打标，形成“字段—级别”映射；
3. 关联访问日志与共享记录，标注“谁在访问、共享给谁”；
4. 识别跨应用流转，例如 CRM 导出到网盘、工单系统同步到数据仓库；
5. 输出可视化地图，支持按级别、应用、责任人筛选。

下面这张图展示了一个典型 SaaS 数据地图的核心结构：左侧是数据源应用，中间是数据对象与级别，右侧是访问主体与外部流向。它把“数据在哪里、有多敏感、流向何处”压缩在一张关系图中，便于快速定位高风险链路。

四、SaaS 数据资产清单实战

数据地图偏宏观，资产清单偏落地。一份可执行的 SaaS 数据资产清单，应至少包含以下字段，并明确每个字段的填写口径：

填写时有两个常见坑。第一，把“应用”当成“资产”，一个 CRM 里可能有几十张敏感表，必须拆到对象级。第二，只填技术字段不填责任人，导致后续整改无人认领。建议每个 L3/L4 资产必须同时有业务责任人和数据安全责任人，双签确认。

五、从清单到治理动作

清单和地图的价值在于驱动动作。拿到一份标注了 L4 的资产清单后，可以按优先级推进：先处理“对外共享 + L4”的组合，这是最高风险；再处理“内部大范围访问 + L3”的组合，收敛权限；最后处理“无责任人 + L3/L4”的资产，补齐归属。每一步都应记录处理前后状态，例如共享链接从“公开”改为“仅指定人员”，访问角色从 8 个收敛到 3 个，这些变化本身就是治理成效的度量。

把分级分类、敏感识别、数据地图和资产清单串起来，SaaS 数据治理才从“知道有风险”走到“知道风险在哪、由谁负责、怎么处理”。这也是后续访问控制、审计告警和合规报告的基础。