Day37-21｜18.6.1 数据库安全设计的评价标准：从“能防”到“可证明、可运行”

对应教材目录：第 18 章 安全架构设计理论与实践 → 18.6 数据库系统的安全设计 → 18.6.1 数据库安全设计的评价标准

学习目标：理解数据库安全评价不能只看是否加密；掌握数据库安全的机密性、完整性、可用性、可审计性、可管理性和合规性指标；能够从架构、技术、流程和验证四个层面评价数据库安全方案。

一、为什么数据库安全需要评价标准

数据库集中保存业务系统最有价值的信息，一旦发生泄露、篡改或不可用，影响通常会同时扩散到多个业务域。数据库安全设计不能只凭“部署了防火墙”“启用了密码”或“做了备份”来判断是否合格，而应建立可以检查、比较和验证的评价标准。

评价标准的作用有三点：第一，把抽象的安全目标转换成可测量的设计要求；第二，在安全、性能、可用性和成本发生冲突时提供决策依据；第三，为上线验收、持续运营、审计和事故复盘提供共同语言。

业务目标
   -> 数据分类分级
   -> 威胁与风险分析
   -> 安全控制设计
   -> 指标与验证用例
   -> 上线验收
   -> 持续监测与改进

二、数据库安全评价的核心属性

1. 机密性

机密性评价关注未授权主体能否读取数据库内容，以及授权主体是否只能看到完成任务所需的数据。检查范围包括数据库账号、应用账号、管理员、备份操作员、开发测试人员、云平台运维人员和第三方接口。

评价要点包括：传输链路是否加密；数据文件、日志、备份和快照是否保护；敏感字段是否采用字段级加密或令牌化；查询结果是否脱敏；跨租户查询是否隔离；导出和复制是否可控；密钥是否独立于数据库保存。

2. 完整性

完整性评价关注数据能否被未授权修改，以及合法修改是否符合业务规则。数据库约束、事务、并发控制、审批流程、审计记录和备份校验都与完整性有关。

重点检查主键、唯一、非空、外键和检查约束；高并发场景是否防止覆盖更新；关键状态是否禁止非法跳转；批量修复是否经过审批；管理员修改是否有双人复核；日志是否能发现高风险变更。

3. 可用性

数据库安全措施不能严重破坏正常业务。评价内容包括故障切换时间、恢复点目标、恢复时间目标、备份恢复成功率、密钥服务故障影响、权限服务不可用时的降级策略和高峰期加密开销。

可用性不是无限追求“永远在线”，而是把不同数据和业务分级。核心交易库可能需要高可用和多副本，低价值分析库可以延迟恢复；权限变更可以短暂排队，高风险操作不能因为组件故障而默认放行。

4. 可审计性

数据库安全事件必须能够被发现、定位和追溯。应记录登录、失败登录、权限变更、敏感表访问、批量查询、导出、DDL、备份恢复和管理员操作。审计日志应包括主体、来源、动作、对象、结果、时间、请求标识和关联业务单号。

审计评价还要看日志是否集中保存、是否防篡改、保留期限是否满足要求、是否能检索和告警、时间是否同步、是否存在日志盲区。日志过多而无法分析，也不等于审计能力强。

5. 可管理性

安全机制必须能够被稳定运维。评价项包括账号全生命周期管理、权限申请审批、定期复核、离职回收、密钥轮换、策略版本、配置变更、例外管理和应急授权。

如果一个系统只能由少数专家手工维护，或者权限规则写在多个应用代码中无法统一修改，长期运行风险很高。可管理性要求控制集中、职责分离、操作可回滚、结果可验证。

6. 可扩展性与兼容性

数据库安全设计应适应业务增长、分库分表、微服务、云迁移和异构数据库。评价时要考虑新节点如何获得最小权限，数据副本如何继承安全策略，跨库查询和数据同步如何保护，旧应用升级时如何兼容加密字段、审计接口和权限模型。

三、从威胁模型评价数据库方案

数据库评价不能脱离威胁主体。常见主体包括外部攻击者、被盗账号、恶意内部人员、误操作管理员、存在漏洞的应用、供应链组件和云平台配置错误。

威胁主体 -> 入口 -> 数据对象 -> 影响
外部攻击者 -> SQL注入/API -> 业务表 -> 泄露或篡改
内部账号 -> 直连数据库 -> 敏感字段 -> 越权查询
管理员 -> 运维工具 -> 权限/配置 -> 持久化后门
云配置错误 -> 备份/对象存储 -> 全量数据 -> 批量泄露
应用漏洞 -> 高权限账号 -> 多租户数据 -> 横向越权

评价方案时要问：控制是否覆盖真实入口？控制失败时是否有第二道防线？是否能及时发现？事故后是否能恢复和追责？例如只在应用层做租户过滤，但应用账号拥有全库权限，那么应用漏洞可能直接绕过业务授权；还应结合数据库行级策略、独立数据访问层和审计进行纵深防御。

四、数据库安全控制的评价层次

1. 设施与边界

包括网络分区、数据库子网、堡垒机、访问白名单、端口暴露、主备链路和管理面隔离。设施边界降低攻击面，但不能假设内网绝对可信。

2. 平台与实例

包括操作系统加固、数据库版本、补丁、默认账号、监听配置、加密插件、审计开关和资源隔离。需要建立基线，并持续检测偏离。

3. 数据与对象

包括库、表、视图、字段、行、索引、存储过程、日志、备份和临时表。敏感数据需要分类分级，设置不同授权和保留期限。

4. 应用与业务

包括参数化查询、输入校验、事务、幂等、业务授权、数据脱敏、接口限流和导出审批。数据库本身不能替代应用的业务规则。

5. 人员与流程

包括账号申请、权限审批、定期复核、应急访问、操作培训、变更评审、日志调查和事故响应。技术控制没有流程闭环，容易在日常运维中被绕开。

五、常见评价指标

评价指标要与业务风险结合，下面是适合架构设计和案例答题的指标类型：

指标不是越多越好。应优先选择能反映核心风险和可持续运营的指标，并明确数据来源、统计周期、目标值和异常处理动作。

六、数据库安全评价方法

1. 基线检查

根据组织标准和数据库类型建立配置基线，检查默认账号、弱口令、开放端口、补丁、审计、备份、加密和权限。基线适合发现共性问题，但无法替代业务风险分析。

2. 权限审计

梳理用户、角色、组、服务账号和直接授权关系，识别长期未使用权限、共享账号、超级账号、跨租户权限和开发人员生产权限。将实际权限与岗位职责和业务流程进行比对。

3. 渗透与验证测试

从应用接口、管理端、备份下载、数据库直连、消息同步和灾备切换等路径验证控制是否真的生效。测试应包含正常、越权、异常、重放、并发、故障和恢复场景。

4. 数据流和攻击路径分析

把敏感数据从产生到销毁的流转画出来，检查每个副本、缓存和接口是否继承控制。结合攻击树或数据流图识别单点失守后的影响范围。

5. 演练与复盘

通过备份恢复、主备切换、密钥服务故障、账号泄露、批量导出和日志平台故障演练验证方案。演练后要记录发现时间、处置时间、业务影响和改进项。

七、案例分析：多租户数据库的安全评价

某 SaaS 平台采用共享数据库和共享表保存多个租户数据，要求满足租户隔离、敏感字段保护、管理员运维可审计和故障可恢复。

评价时至少检查：

1. 应用是否从可信身份获得 tenantId，而不是直接信任请求参数。
2. 所有查询、更新、删除和导出路径是否强制增加租户条件。
3. 数据库账号是否按服务和环境拆分，是否存在全库超级账号。
4. 是否有数据库行级安全策略或独立访问层作为第二道隔离。
5. 敏感字段、日志、缓存、备份和搜索副本是否采用同等级保护。
6. 跨租户统计是否通过聚合视图，是否禁止返回明细。
7. 租户管理员是否只能管理本租户用户和资源。
8. 权限变更、直连、导出和批量查询是否留痕并告警。
9. 主库、备库、灾备库和备份恢复是否验证租户隔离。
10. 在应用漏洞、策略服务故障和数据库主备切换时，是否仍然默认拒绝高风险访问。

八、论文和案例题答题模板

可以围绕“目标—范围—指标—控制—验证”展开：

1. 明确数据库承载的核心业务和数据敏感等级。
2. 从机密性、完整性、可用性、审计性和可管理性设定目标。
3. 按网络、实例、数据、应用、人员流程划分控制层次。
4. 设计身份、权限、加密、审计、备份、恢复和变更管理机制。
5. 为每个目标给出可验证指标，如 RTO、RPO、权限回收时间和审计覆盖率。
6. 通过基线检查、权限审计、渗透测试、恢复演练和持续监控验证。
7. 说明安全措施对性能、成本和可用性的影响及权衡。

九、课后练习

练习 1

为什么“数据库启用密码和防火墙”不能证明数据库安全？

参考答案：密码和防火墙只覆盖身份和网络边界，不能解决应用越权、内部人员查询、敏感字段泄露、备份暴露、业务数据篡改、日志审计和灾备恢复等问题。数据库安全需要纵深防御和可验证指标。

练习 2

请为核心交易数据库列出至少六个评价指标。

参考答案：关键数据加密覆盖率、越权拦截率、敏感操作审计完整率、RTO、RPO、备份恢复成功率、权限回收时间、主备切换时间、异常告警时延和对账差异发现时延。

练习 3

某公司允许所有开发人员使用同一个生产数据库账号，问题是什么？

参考答案：无法区分操作责任，权限过大，离职无法单独回收，密码泄露影响面大，审计无法关联真实人员。应采用个人身份、服务账号分离、最小权限、堡垒机、临时授权和操作审计。

练习 4

论文题：论“云环境下数据库安全设计与评价”。请按五个维度组织正文。

参考答案要点：机密性、完整性、可用性、审计性、可管理性；结合云网络隔离、密钥管理、数据库权限、备份、快照、灾备、监控、合规和恢复演练展开，并给出指标和验证方法。

十、今日复盘

• 我能否用五个以上维度评价数据库安全，而不是只谈加密？
• 我是否能把指标与真实业务风险对应起来？
• 我能否区分基线检查、权限审计、渗透验证和恢复演练？
• 我是否考虑了数据库副本、备份、缓存、搜索和灾备环境？
• 我能否说明安全、性能、可用性和运维成本的权衡？
• 我能否按“目标—范围—指标—控制—验证”组织案例答案？

数据库安全评价的核心结论是：安全设计必须能够被检查、被度量、被验证和被持续运营。高级架构师不仅要提出控制措施，还要说明控制覆盖什么风险、如何证明它有效、失败时如何发现，以及如何在业务连续性的约束下恢复系统。