2. 云数据库资产梳理与分类分级

云数据库安全治理的第一步不是加密、不是审计，而是"知道自己有什么"。在云环境中，数据库实例可能由不同团队通过控制台、Terraform、Kubernetes Operator 等多种方式创建，实例、库、表、字段的数量和归属随时变化。如果资产底账不清，后续的权限收敛、加密、脱敏、审计都无从落地。本节围绕"资产发现—元数据管理—分类分级标准—敏感数据识别与自动打标"这条主线，讲清每一步该做什么、怎么做、结果如何判断。

一、资产发现：把"看不见的数据库"找出来

云数据库资产发现的目标是形成一份可追溯、可更新的实例清单。实践中通常采用"多源采集 + 交叉比对"的方式，而不是依赖单一来源。常见采集源包括：云厂商的资源配置接口（如 DescribeDBInstances 类 API）、CMDB 或资源标签系统、VPC 流日志与端口扫描结果、以及应用侧的连接串配置。多源比对的价值在于发现"影子数据库"——例如某业务团队自行购买但未登记到 CMDB 的 RDS 实例。

一个可执行的采集流程如下：先通过云 API 拉取账号下所有区域的数据库实例，记录实例 ID、引擎类型、版本、地域/可用区、内网地址、端口、标签、创建时间；再与 CMDB 中的登记记录做差集，差集中"有实例无登记"的即为待确认的影子资产；最后通过 VPC 流日志或轻量端口探测，确认实例是否真实存在活跃连接，避免把已释放但残留记录的实例误判为资产。

# 示例：采集某云账号华东1区 MySQL 实例关键字段（伪代码示意）
instances = cloud_api.describe_db_instances(region="cn-east-1", engine="MySQL")
for ins in instances:
    record = {
        "instance_id": ins.id,
        "engine": ins.engine,
        "version": ins.version,
        "zone": ins.zone,
        "endpoint": ins.connection_string,
        "port": ins.port,
        "tags": ins.tags,          # 用于归属判断
        "created_at": ins.create_time
    }
    asset_db.upsert(record)
# 与 CMDB 比对，输出差集
shadow = asset_db.diff(cmbdb.list_all())

判断资产发现是否达标，可以看三个指标：实例覆盖率（云 API 返回实例数 / 实际应纳管数）、影子资产发现数、以及清单更新时效（从实例创建到进入清单的时间）。一般要求覆盖率不低于 98%，影子资产在发现后 24 小时内完成归属确认。

二、元数据管理：从"实例"下沉到"字段"

仅有实例清单不足以支撑分类分级，因为敏感数据往往藏在具体字段里。元数据管理要把采集粒度下沉到库、表、字段，并记录字段名、数据类型、注释、主键/索引、行数估算、样例值（脱敏后）等。云上常见的采集方式有两种：一是通过数据库自身的信息模式（如 MySQL 的 information_schema、PostgreSQL 的 pg_catalog）批量读取结构；二是通过数据地图类工具（如 DataWorks、DataHub）同步血缘与元数据。

元数据采集需要控制对生产库的影响。建议使用只读账号，限制采集频率（如每日一次全量 + 变更时增量），并对样例值做脱敏后再入库。元数据表本身也应纳入权限管控，因为它可能暴露字段命名规律和业务含义。

三、分类分级标准：先定规则，再谈识别

分类分级标准是敏感数据识别的"标尺"。分类回答"这是什么类型的数据"，分级回答"泄露后影响有多大"。以常见的四级分级为例：L1 公开、L2 内部、L3 敏感、L4 核心。分类可参考行业规范，如个人信息、业务数据、财务数据、运维数据等。标准必须落到"字段级判定规则"，否则无法自动化。

标准制定时要明确"组合判定"规则。例如单独一个"姓名"字段可能是 L2，但"姓名 + 手机号 + 地址"同时出现在一张表中，整体应提升为 L3。这类规则需要在标准文档中写清楚，供识别引擎执行。

四、敏感数据识别与自动化打标实战

识别引擎通常结合三种手段：字段名匹配（正则/关键词）、数据内容采样匹配（正则 + 校验算法）、以及上下文推断（表名、注释、关联字段）。单一手段误报率高，实践中以"字段名 + 内容采样"双条件为主，上下文作为加权。

下面是一个可运行的识别与打标流程示意：对每个字段，先做字段名规则匹配，命中后对样例值做内容校验（如身份证号做校验位验证、手机号做号段验证），两者都通过才打标；仅字段名命中而内容不匹配的，标记为"待人工确认"。

# 示例：字段级敏感识别与打标（伪代码）
rules = {
    "id_card":   {"name_kw": ["id_card","身份证"], "regex": r"^\d{17}[\dXx]$", "level": "L3"},
    "phone":     {"name_kw": ["phone","mobile","手机"], "regex": r"^1[3-9]\d{9}$", "level": "L3"},
    "bank_card": {"name_kw": ["bank","card_no","银行卡"], "regex": r"^\d{16,19}$", "level": "L4"}
}

for col in metadata.columns:
    for tag, rule in rules.items():
        name_hit = any(kw in col.name.lower() for kw in rule["name_kw"])
        if not name_hit:
            continue
        sample = fetch_sample(col, limit=20)          # 脱敏后样例
        content_hit = sum(1 for v in sample if re.match(rule["regex"], v)) / len(sample)
        if content_hit >= 0.8:
            tag_column(col, tag, rule["level"], confidence=content_hit)
        else:
            tag_column(col, tag, "待确认", confidence=content_hit)

打标结果需要可复核。建议输出一张"字段—标签—级别—置信度—证据"的明细表，置信度低于阈值的进入人工复核队列。判断识别效果的核心指标是准确率与召回率：准确率看已打标字段中真正敏感的比例，召回率看真实敏感字段中被识别出的比例。一般要求准确率不低于 95%，召回率不低于 90%，低于阈值时优先调整正则和采样策略，而不是盲目放宽规则。

把上述四步串起来，资产梳理与分类分级就形成了一个可运转的闭环：资产发现解决"有没有"，元数据管理解决"长什么样"，分类分级标准解决"按什么判"，敏感识别与打标解决"自动判、判得准"。这个闭环的输出——字段级敏感标签——正是后续权限收敛、动态脱敏、审计告警的直接输入。