2. 数据库漏洞来源与分类

数据库漏洞治理的第一步不是“打补丁”，而是把漏洞的来源和类型分清楚。同一个数据库实例上出现的问题，可能来自产品自身代码、第三方组件、部署配置、业务 SQL 写法，也可能来自账号权限设计。来源不同，处置路径完全不同：产品缺陷要等厂商补丁或升级版本，配置缺陷可以立即修正，代码缺陷需要改应用，权限滥用则要重新设计授权模型。本节围绕 CVE、CNVD、厂商补丁、配置缺陷、代码缺陷、权限滥用六类来源展开，并给出可落地的分类判断方法。

一、漏洞来源的六个入口

CVE（Common Vulnerabilities and Exposures）是国际通用的漏洞编号体系，由 MITRE 维护，每个编号对应一个已公开披露的安全缺陷。例如 MySQL 的 CVE-2016-6662 涉及配置文件提权，Oracle 数据库的 CVE-2021-2294 涉及 Java VM 组件。CVE 的价值在于“可检索、可关联”：拿到一个 CVE 编号，就能查到受影响版本、CVSS 评分、修复版本和参考链接。但 CVE 只覆盖已公开披露的部分，未公开或厂商内部修复的缺陷不会出现在其中。

CNVD（国家信息安全漏洞共享平台）是国内漏洞收录与通报平台，除收录国际 CVE 外，还收录大量国产数据库、中间件和行业软件的漏洞，并提供中文描述和影响范围。对于使用达梦、人大金仓、GBase 等国产数据库的场景，CNVD 往往是比 CVE 更直接的来源。CNVD 编号通常以 CNVD-年份-序号 形式出现，部分条目会标注危害级别和修复建议。

厂商补丁是数据库原厂发布的安全修复，包括 Oracle 的 Critical Patch Update（CPU）、MySQL 的 Oracle Critical Patch Update、SQL Server 的 Security Update、PostgreSQL 的小版本更新等。厂商补丁的特点是“精准但滞后”：它针对具体缺陷给出修复，但从缺陷发现到补丁发布存在时间差，且部分补丁需要停机或重启实例。

配置缺陷不来自代码，而来自部署和运维选择。典型如：监听地址绑定 0.0.0.0 且未限制来源、默认账号未改密码、开启 xp_cmdshell、允许 LOAD DATA LOCAL INFILE、未启用 SSL/TLS、审计日志关闭、备份文件权限过宽。这类问题往往比 CVE 更常见，也更容易被利用。

代码缺陷指业务应用与数据库交互时引入的问题，最典型的是 SQL 注入：应用把用户输入直接拼接进 SQL 语句，导致攻击者可以改变查询语义。此外还包括存储过程权限过大、动态 SQL 未参数化、错误信息回显数据库结构等。代码缺陷的修复点在应用侧，而不是数据库侧。

权限滥用指账号被授予了超出业务需要的权限，或权限被攻击者利用。例如应用账号拥有 DBA 权限、普通用户可访问其他 schema、账号共享导致无法追溯、离职人员账号未回收。权限滥用本身不一定是“漏洞”，但它会显著放大其他漏洞的影响。

二、成因分析：为什么这些漏洞会存在

产品缺陷的成因通常是代码实现中的边界条件、内存管理、权限校验或协议解析问题。以 MySQL 的 CVE-2016-6662 为例，攻击者可以通过具有 FILE 权限的账号写入配置文件，再借助重启触发提权。这类缺陷的根因在数据库内核或组件代码，用户无法通过配置完全规避，只能升级或限制相关权限。

配置缺陷的成因多来自“默认值优先”和“可用性优先”的部署习惯。安装数据库时，为了快速连通，运维常把监听地址设为 0.0.0.0、保留默认端口 3306/1521/1433、使用弱口令、开启远程 root 登录。这些选择在开发环境无伤大雅，在生产环境就是暴露面。配置缺陷的另一个来源是“复制粘贴”：从旧环境复制配置，把测试用的宽松策略带到了生产。

代码缺陷的成因集中在应用开发环节。以 SQL 注入为例，问题不在于数据库，而在于应用把 username 直接拼进查询字符串。下面是一段存在缺陷的示例代码：

String sql = "SELECT * FROM users WHERE name = '" + name + "' AND pwd = '" + pwd + "'";
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql);

当 name 传入 ' OR '1'='1 时，查询条件被改变，攻击者可以绕过认证。修复方式是使用参数化查询：

String sql = "SELECT * FROM users WHERE name = ? AND pwd = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, name);
ps.setString(2, pwd);
ResultSet rs = ps.executeQuery();

参数化查询让数据库把输入当作数据而不是 SQL 语法，从机制上消除注入。这是代码缺陷修复的典型路径：不改数据库，改应用。

权限滥用的成因通常来自“图省事”的授权习惯。应用连接数据库时直接使用 root 或 sa，开发人员为了方便查询被授予 DBA，多个业务共用同一个数据库账号。这些做法在初期降低了沟通成本，但一旦账号泄露，攻击者就获得了远超业务需要的权限。权限滥用的治理核心是“最小权限 + 账号隔离 + 定期复核”。

三、分类判断的实操方法

面对一个具体问题，可以按以下顺序判断归属：

1. 先看是否有公开编号。用数据库版本号在 CVE 或 CNVD 检索，确认是否存在已知漏洞。例如 MySQL 5.7.20 之前的版本存在多个已披露问题，检索结果会直接给出修复版本。
2. 再看配置基线。对照安全基线检查监听地址、默认账号、远程访问、审计日志、加密传输、文件权限等项。配置类问题通常可以立即修正，不需要等补丁。
3. 然后看应用代码。检查是否存在字符串拼接 SQL、动态 SQL 未参数化、错误信息回显、存储过程权限过大等。代码缺陷的修复周期取决于应用发布流程。
4. 最后看权限矩阵。列出所有数据库账号、所属业务、授予权限、最近使用时间。重点检查是否有账号拥有 DBA、FILE、SUPER 等高危权限，以及是否存在共享账号和离职未回收账号。

四、分类结果如何落到加固动作

把漏洞归入六类之后，加固动作就有了明确方向。产品缺陷对应“版本升级或补丁管理”，配置缺陷对应“基线核查与修正”，代码缺陷对应“安全编码与代码审计”，权限滥用对应“最小权限与账号治理”。CVE 和 CNVD 是信息来源，厂商补丁是修复手段，三者共同构成“发现—评估—修复”的闭环。

在实际工作中，建议维护一张漏洞台账，字段至少包括：漏洞编号（CVE/CNVD/内部编号）、来源分类、影响资产、数据库版本、危害级别、修复方式、修复期限、验证结果。台账的作用不是记录，而是驱动修复：每一条漏洞都必须有明确的归属分类和责任人，否则就会停留在“知道有问题”但“不知道谁来修”的状态。

总结来看，数据库漏洞治理需要同时关注“外部披露”和“内部引入”两条线：CVE、CNVD、厂商补丁属于外部披露线，配置缺陷、代码缺陷、权限滥用属于内部引入线。前者靠情报跟踪和补丁管理，后者靠基线、审计和权限治理。两条线都覆盖，漏洞治理才完整。