3. 数据库资产发现与清点

数据库资产发现与清点，是数据库漏洞治理的起点。如果连“有哪些数据库、跑在哪里、谁在用、里面有什么数据”都说不清，后续的漏洞扫描、权限收敛、补丁加固都会失去准确的作用对象。本节要解决的核心问题，是把分散、动态、可能被人为隐藏的数据库资产，转化为一份可查询、可追溯、可更新的资产台账。

一、资产发现要采集哪些字段

资产发现不是简单地“扫出一个 IP 列表”，而是要围绕数据库实例建立多维属性。一个可用的资产台账，至少应覆盖以下信息：

• 实例标识：实例名、实例类型（单机、主从、集群、云托管）、所属业务系统、责任人。
• 网络位置：IP 地址、监听端口、协议（MySQL 3306、PostgreSQL 5432、SQL Server 1433、Oracle 1521、Redis 6379、MongoDB 27017 等）。
• 版本信息：数据库产品与精确版本号，例如 MySQL 5.7.38、PostgreSQL 13.7、Oracle 11.2.0.4，用于判断已知漏洞影响范围。
• 服务与运行状态：是否在线、启动时间、连接数、是否开启远程访问、是否启用 TLS。
• 账号信息：账号名、认证方式、权限范围、是否为空口令、是否为默认账号。
• 敏感数据分布：库、表、字段中是否包含身份证号、手机号、银行卡号、地址等敏感数据，以及数据量级。

这些字段共同构成资产台账的“最小可用集”。缺少版本，就无法做漏洞匹配；缺少账号，就无法做权限审计；缺少敏感数据分布，就无法确定加固优先级。

二、自动发现的技术路径

自动发现通常采用“主动探测 + 被动流量识别 + 配置采集”三种方式结合。主动探测适合发现开放端口和可连接实例；被动流量识别适合发现未开放扫描但实际在通信的数据库；配置采集则从 CMDB、云平台 API、容器编排平台中拉取实例元数据。

以主动探测为例，一个典型的发现流程是：先对目标网段做端口扫描，识别常见数据库端口；再对开放端口发送协议握手包，根据返回的 banner 或错误码判断数据库类型与版本；最后尝试用只读账号连接，读取实例元数据。下面是一段示例性的探测命令，用于说明思路，实际执行需在授权范围内进行：

# 示例：使用 nmap 识别常见数据库端口与服务
nmap -sV -p 3306,5432,1433,1521,6379,27017 10.10.20.0/24

# 示例：MySQL 版本探测（只读账号）
mysql -h 10.10.20.15 -P 3306 -u audit_ro -p -e "SELECT VERSION();"

# 示例：PostgreSQL 版本探测
psql -h 10.10.20.16 -p 5432 -U audit_ro -c "SELECT version();"

被动流量识别则通过镜像流量或数据库审计设备，解析数据库协议中的登录请求、SQL 语句和返回结果，从中提取实例 IP、端口、账号、库表访问关系。这种方式对“影子数据库”尤其有效——那些未登记在 CMDB 中、但实际承载业务流量的实例，往往只能通过流量发现。

三、敏感数据分布识别

发现实例之后，下一步是识别敏感数据分布。常见做法是：先采集库表结构，再对字段名和字段注释做规则匹配，最后对疑似字段做采样验证。例如，字段名为 id_card、phone、bank_no 时，可初步判定为敏感字段；再抽取少量数据，用正则表达式验证是否符合身份证号、手机号格式。

敏感数据识别结果应记录到资产台账中，形成“实例—库—表—字段—敏感类型—数据量”的层级关系。这样在后续漏洞治理中，就能优先处理承载敏感数据的实例，而不是平均用力。

四、建立资产台账的落地要点

资产台账不是一次性表格，而是一个持续更新的数据集合。落地时要注意三点：

1. 唯一标识：每个实例用“IP + 端口 + 实例名”作为唯一键，避免同一实例因多次扫描产生重复记录。
2. 变更追踪：记录每次发现的时间戳和变更内容，例如版本升级、端口变更、账号新增，便于回溯。
3. 与漏洞库联动：台账中的版本字段应能直接匹配 CVE 或厂商安全公告，自动标记“存在已知高危漏洞”的实例。

五、一个可参考的资产台账字段示例

下表给出一个简化的资产台账字段示例，实际使用时可根据组织规模扩展。表中数据为教学示例，非真实环境实测结果。

有了这份台账，后续的漏洞扫描就可以按“版本 + 端口 + 账号”精准匹配，权限收敛可以按“账号数 + 敏感字段”确定优先级，补丁加固也可以按“风险标记”排序。资产发现与清点的价值，正在于把模糊的“我们有很多数据库”变成清晰的“每个实例的状态、风险和责任人”。