2. Azure 数据资产发现与分类

数据治理的第一个现实问题不是“怎么管”,而是“我到底有哪些数据、它们在哪里、哪些是敏感的”。如果连资产清单都不完整,后续的权限收敛、脱敏、留存、审计都无从谈起。Microsoft Purview 的价值就在于把分散在 Azure、本地和多云环境中的数据源统一接入,自动扫描元数据,识别敏感信息类型,并把这些结果沉淀为可检索、可追溯的企业数据地图。

一、Purview 的三层能力:从接入到地图

理解 Purview 的数据资产发现,可以把它拆成三个连续层次:数据源注册与扫描、分类与敏感度标记、数据地图与资产目录。注册解决“连得上”,扫描解决“看得见”,分类解决“认得准”,地图解决“找得到、看得懂、能追溯”。

数据源注册时,Purview 通过托管身份或服务主体访问源系统。以 Azure Data Lake Storage Gen2 为例,通常需要为 Purview 托管身份授予存储账户的 Storage Blob Data Reader 角色;对 Azure SQL Database,则通过 Purview 托管身份在数据库内创建用户并授予 db_datareader。扫描集(Scan Rule Set)决定扫描范围、文件类型和采样方式,例如只扫描 .csv、.json、.parquet,并设置最大采样行数。扫描不是全量读取数据,而是按规则抽样推断结构,因此对生产系统的影响可控。

Microsoft Purview 数据资产发现与分类链路 数据源 ADLS Gen2 Azure SQL Database Synapse / 本地 SQL 托管身份 / 服务主体 扫描与分类引擎 扫描规则集 系统分类规则 自定义分类规则 抽样推断,非全量读取 数据地图与目录 资产实体与血缘 分类与敏感度标签 业务术语表 搜索、浏览、追溯 消费方 数据治理员 安全团队 数据工程师 审计与合规 分类结果示例:从原始字段到敏感度判定 源字段 命中分类 敏感度 建议动作 customer_id 无(非敏感标识) 公开 纳入目录,正常共享 id_card_no 中国居民身份证号 高度机密 脱敏、限制访问、审计 email 电子邮件地址 机密 按需共享,记录访问 bank_account 银行账号 高度机密 加密存储、最小权限

二、自动分类:系统规则与自定义规则如何配合

Purview 内置了 200 多种敏感信息类型(Sensitive Information Type,SIT),覆盖身份证号、银行卡号、邮箱、电话号码、护照号、IP 地址等。系统分类规则基于正则表达式、校验位算法和关键字上下文进行匹配。例如中国居民身份证号使用 18 位正则加校验位验证,银行卡号使用 Luhn 算法校验,这能显著降低误报。

但系统规则不可能覆盖企业特有的敏感字段。比如内部员工编号格式为 EMP- 加 8 位数字,或者客户合同编号以 CTR- 开头。这时需要创建自定义分类规则。在 Purview 中,自定义 SIT 由三部分组成:模式(正则表达式)、辅助证据(附近关键字,如“员工编号”“合同号”)、置信度(低/中/高)。置信度越高,误报越少,但漏报可能增加。建议对高敏感字段使用“高置信度 + 辅助证据”,对一般字段使用“中置信度”。

分类结果会写入数据地图中的资产实体。每个资产会显示“分类”列表,并可通过敏感度标签(如“公开”“一般”“机密”“高度机密”)进行标记。敏感度标签可以与 Microsoft Purview 信息保护、DLP 策略联动,实现从“发现”到“保护”的闭环。

三、建立企业数据地图:从扫描结果到可运营资产

扫描完成后,Purview 数据地图会自动生成资产实体、列级结构和分类信息。但“有地图”不等于“地图可用”。要让数据地图真正服务治理,需要做三件事:

  • 业务术语表绑定:把技术字段(如 cust_id)映射到业务术语(如“客户唯一标识”),让业务人员能看懂。
  • 资产负责人和专家指定:每个资产指定负责人(Owner)和专家(Expert),明确谁对数据质量、权限和分类准确性负责。
  • 血缘关系补充:Purview 可自动解析 Azure Data Factory、Synapse 管道的血缘,但手工维护的 ETL 或外部系统需要手动补充,否则影响分析无法追溯。

一个可运营的数据地图,应该能回答四个问题:这个数据在哪里?它是什么?谁负责?谁可以访问? 如果只能回答前两个,说明地图还停留在“目录”阶段,没有进入“治理”阶段。

四、实操示例:扫描 Azure SQL 并识别敏感列

假设有一个 Azure SQL Database salesdb,其中 dbo.Customers 表包含 CustomerID、FullName、IDNumber、Email、Phone、BankAccount 六列。目标是扫描并确认哪些列被自动分类为敏感。

第一步,在 Purview 中注册数据源,选择 Azure SQL Database,填入服务器名和数据库名,选择 Purview 托管身份。第二步,在数据库内执行授权:

CREATE USER [Purview-ManagedIdentity] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [Purview-ManagedIdentity];

第三步,创建扫描,选择默认扫描规则集,设置扫描频率为每周一次。扫描完成后,在 Purview 资产目录中搜索 dbo.Customers,查看“分类”页签。预期结果:IDNumber 命中“中国居民身份证号”,Email 命中“电子邮件地址”,Phone 命中“中国手机号码”,BankAccount 命中“银行账号”,FullName 可能命中“人名”,CustomerID 通常不命中敏感分类。

如果 IDNumber 未被识别,需要检查两点:一是列名是否包含辅助关键字(如“身份证”),二是数据样本是否符合 18 位格式。若数据本身是脱敏后的掩码值(如 110***********1234),系统规则可能无法命中,此时应创建自定义规则,匹配掩码模式并设置中置信度。

扫描频率建议:核心敏感库每周一次,一般业务库每月一次,归档库每季度一次。扫描本身不修改数据,但会读取元数据和抽样数据,需确保 Purview 托管身份只有只读权限。

五、常见问题与判断依据

实际落地中,最常见的三个问题是:扫描失败、分类误报、地图信息过期。扫描失败通常由网络或权限引起,检查 Purview 托管身份是否被防火墙放行、是否具备读取权限。分类误报多发生在数字型字段,如 order_id 被误判为电话号码,此时应降低该分类的置信度或增加辅助关键字排除。地图信息过期则是因为扫描频率过低或数据源结构变更后未重新扫描,建议在 CI/CD 流程中加入“结构变更后触发扫描”的步骤。

判断数据地图是否达到可用标准,可以看一个指标:敏感资产覆盖率。即已识别敏感资产数除以实际敏感资产数。如果覆盖率低于 90%,说明还有敏感数据未被发现,后续的权限和脱敏策略都会存在盲区。建议每季度做一次覆盖率复核,用抽样人工核查的方式验证自动分类的准确性。

Purview 的数据资产发现不是一次性任务,而是持续运营过程。注册、扫描、分类、地图、复核形成闭环,才能让企业真正掌握自己的数据资产,并为后续的权限治理、数据脱敏和合规审计提供可靠基础。