3. 数据库安全需求分析与风险评估

数据库安全工程不能从“买什么设备、开什么审计”开始，而应从“我们面对什么威胁、系统哪里薄弱、哪些风险必须优先处理”开始。本节把这一过程拆成四个相互衔接的动作：威胁建模、脆弱性识别、风险矩阵评估、安全需求规格化。它们的关系不是线性流水线，而是一个从“攻击者视角”到“防御者需求”的转换闭环：威胁建模回答“谁会怎么打”，脆弱性识别回答“哪里挡不住”，风险矩阵回答“先修哪个”，安全需求规格化回答“修成什么样才算合格”。

一、威胁建模：先画出攻击者的路径

威胁建模的核心是围绕数据库资产，识别威胁源、攻击路径和可能造成的后果。对数据库而言，常见威胁源包括外部攻击者、拥有部分权限的内部人员、被攻陷的应用服务器、供应链中的第三方运维，以及误操作的管理员。建模时建议以“资产—入口—权限—数据”为主线：资产是库中的敏感表（如用户表、订单表、支付流水）；入口是应用连接串、运维跳板机、备份文件、导出接口；权限是数据库账号、角色和对象授权；数据是最终被读取、篡改或删除的目标。

以某电商订单库为例，可识别出一条典型威胁路径：外部攻击者通过应用层 SQL 注入获得应用账号权限，再利用应用账号对 orders 表的 SELECT 权限批量导出订单数据。这里的关键不是“有注入”，而是“注入后能拿到什么”。因此威胁建模要落到具体对象和权限上，而不是停留在“存在注入风险”的泛化描述。常用方法包括 STRIDE（欺骗、篡改、否认、信息泄露、拒绝服务、权限提升）和攻击树。对数据库场景，STRIDE 中的“信息泄露”和“权限提升”最值得重点展开。

二、脆弱性识别：把“可能被利用”变成“确实存在”

脆弱性是威胁得以实现的客观条件。数据库脆弱性通常分布在五个层面：配置层（如 remote_login_passwordfile 设置不当、监听未限制来源）、账号层（默认账号未禁用、口令策略缺失、权限过大）、对象层（敏感表未加密、视图未做脱敏、存储过程存在动态拼接 SQL）、审计层（未开启审计或审计日志可被普通账号删除）、运维层（备份文件明文存放、导出文件未加密、变更无审批）。

识别脆弱性不能只靠扫描器。建议采用“工具扫描 + 配置核查 + 权限复核 + 代码审计”的组合。例如核查数据库账号时，可直接查询权限视图，找出拥有 DBA 或 SELECT ANY TABLE 的应用账号：

-- 示例：查询拥有高危系统权限的账号（Oracle 语法示意）
SELECT grantee, privilege
FROM dba_sys_privs
WHERE privilege IN ('SELECT ANY TABLE','DELETE ANY TABLE','DROP ANY TABLE')
ORDER BY grantee;

-- 示例：查询对敏感表的直接授权（MySQL 语法示意）
SELECT grantee, table_schema, table_name, privilege_type
FROM information_schema.table_privileges
WHERE table_name IN ('users','orders','payments');

查询结果若显示应用账号拥有 SELECT ANY TABLE，则说明该账号一旦被注入利用，可读取全库数据，属于高严重度脆弱性。脆弱性识别的输出应是一份带位置、证据和影响对象的清单，而不是一句“权限配置不合理”。

三、风险矩阵：用可能性与影响排序

风险 = 威胁利用脆弱性的可能性 × 造成的影响。风险矩阵把这两个维度各分为若干等级，形成可比较的优先级。可能性可依据暴露面、利用难度、已有控制措施判断；影响可依据数据敏感级别、业务中断时长、合规后果判断。下表给出一个可直接套用的五级矩阵示例（数值为风险分值，1 最低、25 最高）：

按示例假设：SQL 注入导致订单数据泄露，可能性评为 4（应用暴露在互联网、已有 WAF 但未做参数化改造），影响评为 5（订单含手机号与地址，属敏感数据且涉及合规），风险分值 20，属于必须优先处置的高风险。而“测试库使用弱口令”可能性 3、影响 2，风险分值 6，可排入后续整改。风险矩阵的价值在于把有限的安全投入集中到高分项，而不是平均用力。

四、安全需求规格化：把风险结论写成可验收的条款

风险矩阵给出优先级后，必须把“高风险”翻译成开发、运维和审计都能执行的安全需求。规格化的关键是三条：可验证、可度量、可追溯。可验证指需求有明确的验收方法；可度量指有阈值或数量；可追溯指每条需求能回溯到具体威胁与脆弱性。例如“加强数据库权限管理”不是需求，而“应用账号仅授予 orders 表指定列的 SELECT，禁止 SELECT ANY TABLE，验收时通过权限视图确认无高危系统权限”才是需求。

规格化时建议为每条需求分配编号，并记录来源风险、责任方、验收条件和验证方式。需求类型通常覆盖：访问控制（最小权限、角色分离）、数据保护（加密、脱敏、备份加密）、审计与监控（操作审计、异常导出告警）、变更与运维（变更审批、跳板机管控）、应急响应（泄露发现与处置时限）。

五、落地要点与常见偏差

实际执行中，最常见的偏差有三类。第一，威胁建模只列威胁不落到资产和权限，导致后续无法验证；第二，脆弱性识别只依赖扫描器，忽略权限复核和代码审计，漏掉“合法权限被滥用”这类问题；第三，风险评分主观随意，同一类风险在不同人手里分值差异大。改进办法是固定评分锚点：例如把“影响=5”定义为“敏感数据泄露且涉及监管通报”，“可能性=4”定义为“已有公开利用方式且目标暴露在互联网”。锚点固定后，评分才具备横向可比性。

另一个关键点是需求规格化必须与现有变更流程结合。安全需求若不能进入需求池、不能排期、不能验收，就只是文档。建议把高风险项直接转为工单，附上验收条件和验证命令，由安全团队在整改后复核。例如权限整改完成后，重新执行权限视图查询，确认应用账号不再拥有 SELECT ANY TABLE，并保留查询结果作为验收证据。这样，风险评估才真正闭环到数据库安全工程的可执行层面。