3. 云数据库选型安全对比
云数据库选型不是“哪个性能好就用哪个”，而是一次把安全责任、合规边界、数据形态与运维能力同时纳入的工程决策。同一份业务数据，放在托管关系型数据库、云原生分布式数据库、Serverless 数据库或自建数据库上，云厂商承担的安全责任范围完全不同。选型阶段若只看功能清单，迁移后往往出现“以为云平台会管、实际要自己管”的加密、审计或网络隔离缺口。
一、责任共担模型：先划清“谁管什么”
责任共担模型是云数据库安全选型的第一性框架。它的核心不是一句“云厂商负责云的安全，客户负责云中的安全”，而是随服务形态（IaaS / PaaS / DBaaS / Serverless）逐层移动的责任分界线。
- 云厂商始终负责：物理机房、宿主机、存储介质、网络基础设施、虚拟化层，以及托管服务自身的补丁、高可用切换、备份基础设施。
- 随托管程度上移而转移给厂商：数据库引擎版本升级、参数基线、主备复制、部分审计日志采集。
- 始终由客户负责：数据分类分级、账号与权限模型、敏感字段加密策略、访问审计的留存与告警、密钥生命周期、SQL 层面的越权防护。
以三种典型形态为例：在 IaaS 自建数据库上，客户要负责 OS 加固、引擎补丁、备份脚本；在 DBaaS 托管实例上，这些上移到厂商，但账号权限、数据加密、审计策略仍归客户；在 Serverless 数据库上，连容量与连接池都由平台管理，客户责任进一步收缩到“数据本身与访问策略”。选型时必须把这条分界线画出来，否则会出现责任真空。
二、安全能力矩阵：用统一维度横向对比
把候选服务放进同一张矩阵，才能避免被单点宣传语带偏。建议固定以下维度：网络隔离能力、静态与传输加密、密钥管理方式（BYOK / 平台托管）、身份与权限模型（IAM 集成、行级/列级权限）、审计日志粒度与留存、数据脱敏与动态掩码、备份加密与恢复验证、合规认证覆盖（等保、ISO 27001、SOC 2、金融行业规范）、漏洞响应与补丁 SLA。
下面这张图把“责任分界”和“能力矩阵”合并表达：左侧是三类服务形态，右侧是各层安全能力由谁承担，颜色区分厂商责任与客户责任，便于在选型会上直接对照。
从矩阵可以读出一条规律：托管程度越高，蓝色（厂商）区域越大，但橙色（客户）区域不会消失。网络隔离、身份权限、加密密钥、审计脱敏这四层，在任何形态下都归客户。这正是选型时最容易被忽略、也最容易出事故的地方。
三、选型安全评估方法：从需求到打分
评估方法建议分四步落地，而不是直接看厂商白皮书。
- 数据分级先行：把待迁移数据分为公开、内部、敏感、核心四级。核心级（如身份证号、银行卡、生物特征）必须要求 BYOK 加密、行级权限、全量审计三项硬指标。
- 映射责任清单：对每个候选服务，逐条填写上图中七层能力的承担方，标出“客户承担但团队无能力承担”的项，这些就是迁移风险点。
- 加权打分：按业务权重给维度赋分。例如金融场景可设：加密与密钥 25%、审计 20%、网络隔离 20%、权限模型 15%、合规认证 10%、补丁 SLA 10%。
- 验证而非采信：对高分项做实测，如尝试用非授权账号访问、检查审计日志是否记录到具体 SQL、验证密钥轮换后旧数据是否仍可解。
四、决策要点与常见误区
决策时抓住四个要点：责任边界是否可接受、密钥是否自主可控、审计是否可追溯、退出是否可迁移。前三点决定安全底线，第四点决定被锁定后的议价与合规能力。
最后给出一份可直接使用的选型安全评估表字段，供评审会逐项填写：服务名称、服务形态、数据分级、七层责任归属、BYOK 支持、审计留存天数、行级权限、合规认证、补丁 SLA、备份加密、恢复验证结果、加权总分、遗留风险与缓解措施。把这张表填完，选型结论自然浮现，而不是靠印象拍板。