2. 企业数据库资产梳理与分类分级
数据库安全治理的第一步不是买设备、也不是配策略，而是把"我们到底有哪些数据库、里面装了什么"这件事说清楚。资产梳理与分类分级是后续访问控制、加密、审计、脱敏、防泄漏等所有工作的输入。如果资产台账不准、敏感数据位置不清，后面所有安全策略都会建立在错误的地基上。本节围绕四个动作展开：识别数据库实例、发现敏感数据、打标、分级，并给出可落地的判断依据与示例。
一、识别数据库实例：从"看得见"到"管得住"
数据库实例识别要解决三个问题：有哪些实例、它们在哪里、由谁负责。企业环境里常见的数据库形态包括：物理机或虚拟机上自建的关系型数据库（MySQL、PostgreSQL、Oracle、SQL Server）、云上托管数据库（RDS、PolarDB、GaussDB 等）、数据仓库（ClickHouse、Doris、Hive/Spark 元数据）、NoSQL（Redis、MongoDB、Elasticsearch）以及文件型数据源（CSV、Excel、共享盘）。识别手段通常有三类：
- 主动扫描：在授权网段内按端口与协议探测，例如 MySQL 默认 3306、PostgreSQL 5432、Oracle 1521、SQL Server 1433、Redis 6379、MongoDB 27017、Elasticsearch 9200。扫描结果需与业务确认，避免误报。
- 被动流量分析：通过镜像流量或数据库审计设备识别真实连接关系，能发现扫描不到的实例（如非标端口、内网隔离区）。
- 配置与台账采集：从 CMDB、云平台 API、Kubernetes 配置、应用配置文件（如 application.yml、.env）中提取连接串，反推实例清单。
识别结果应形成实例台账，至少包含：实例标识、数据库类型与版本、部署位置（IP/端口/云区域）、所属业务系统、负责人、数据量级、是否对外、备份情况。台账不是一次性工作，应随发布、扩容、下线持续更新。示例：某电商企业通过扫描与流量分析，发现 3 个未登记的自建 MySQL 实例，其中 1 个存放了用户手机号与收货地址，属于典型"影子数据库"，必须纳入管理。
二、敏感数据发现：定位字段级敏感信息
敏感数据发现的目标是回答"哪些库、哪些表、哪些字段包含敏感信息"。常见敏感类型包括：个人身份信息（姓名、身份证号、手机号、邮箱、地址）、账号凭证（用户名、密码哈希、Token）、金融信息（银行卡号、交易金额）、生物特征、健康医疗信息，以及企业商业秘密（客户名单、报价、合同）。
发现方法分为三类，实践中通常组合使用：
- 元数据匹配：依据字段名、表名、注释做规则匹配，如字段名含 id_card、mobile、phone、email、bank_card、password 等。优点是快，缺点是命名不规范时漏报。
- 内容采样识别：对字段抽样读取，用正则或校验算法判断。例如身份证号可用 18 位加权校验，手机号用
^1[3-9]\d{9}$，银行卡号用 Luhn 算法。采样需控制频率与范围，避免影响生产库性能。 - 分类模型辅助：对自由文本、备注、日志类字段，用规则加模型判断是否含敏感内容，适合非结构化程度高的场景。
发现结果要落到字段级清单，并记录证据（命中规则、样本脱敏展示、置信度）。示例：对 user_profile 表扫描后，发现 mobile 命中手机号正则、id_no 通过身份证校验、addr 命中地址关键词，置信度分别为高、高、中，需人工复核 addr。
三、打标：把发现结果变成可执行标签
打标是把敏感发现结果固化为可被策略引擎识别的标签。标签应包含维度：敏感类型（个人信息/金融/凭证）、敏感级别（L1–L4）、所属业务、数据主体、是否可对外、脱敏要求。打标对象可以是实例、库、表、字段四级，字段级最细也最有用。
打标方式有两种：自动打标（由发现引擎按规则写入）与人工确认（业务与安全共同复核）。建议对高置信度自动通过，中低置信度进入复核队列。标签要能随数据变化更新，例如新增字段、字段含义变更时重新评估。示例标签：PII.MOBILE / L3 / 用户中心 / 需脱敏 / 禁止出境。
四、分级策略：从标签到管控强度
分级决定管控强度。常见做法是四级：L1 公开、L2 内部、L3 敏感、L4 核心。分级依据可综合数据敏感类型、影响范围、泄露后果、合规要求（如个人信息保护法、数据出境规定）。分级不是给数据"贴个颜色"，而是要绑定具体管控动作：
| 级别 | 典型数据 | 访问控制 | 加密/脱敏 | 审计 |
|---|---|---|---|---|
| L1 公开 | 产品目录、公开文档 | 常规账号 | 无需 | 基础日志 |
| L2 内部 | 内部报表、运营指标 | 按角色授权 | 传输加密 | 操作审计 |
| L3 敏感 | 手机号、地址、交易记录 | 最小权限+审批 | 存储加密+查询脱敏 | 全量审计+告警 |
| L4 核心 | 身份证、银行卡、密码哈希 | 专人专权+双人复核 | 强加密+动态脱敏+禁止导出 | 实时审计+阻断 |
分级策略要落到具体规则，例如：L3 字段默认对普通账号返回脱敏值（手机号显示 138****1234），L4 字段禁止批量导出，导出需审批并记录。分级结果应定期复核，业务变化、合规要求更新时同步调整。
五、落地要点与常见问题
实践中容易踩的坑有三类。第一，只扫端口不核业务，导致台账里一堆"僵尸实例"或漏掉影子库；应把扫描结果与业务负责人逐一确认。第二，敏感发现只靠字段名，遇到 f1、col_a 这类命名就失效；应补充内容采样与校验算法。第三，分级只停留在文档，没有绑定到数据库账号权限、脱敏规则和审计策略；分级必须能落到具体配置，否则等于没做。
建议的推进节奏是：先完成核心业务库的实例识别与字段级敏感发现，形成最小可用台账；再对 L3、L4 数据打标并绑定管控；最后扩展到全量实例与定期复核。整个过程需要安全、DBA、业务三方共同参与，安全定规则、DBA 提供实例与权限信息、业务确认数据含义与级别。只有三方对齐，分类分级结果才可信、可执行、可持续。