敏感信息安全方案 V2
mingzaily / 2025-09-04
一、方案架构设计（Vault 原生加密模式）
1. 整体架构
核心为 “业务服务 + Vault 服务 + 存储层” 的协作架构，Vault 承担敏感信息存储与加密核心职责，业务服务专注业务逻辑，组件职责清晰且解耦
2. 核心组件说明
| 组件 | 核心职责 | 关键交互逻辑 |
| 业务服务集群 | 1. 接收用户 / 运营端请求；2. 读写业务数据库（获取 Vault 路径 / 特征值）；3. 调用 Vault API 处理敏感信息；4. 返回业务结果并记录日志 | 1. 通过 Vault SDK 调用 Vault API；2. 执行 SQL 操作业务数据库 |
| Vault 服务集群 | 1. 提供 KV 引擎存储敏感信息（自动 AES-256-GCM 加密）；2. 基于 K8s SA 实现身份认证；3. 记录敏感信息访问审计日志；4. 支持主密钥自动轮换 | 1. 响应业务服务的 KV 读写请求；2. 输出审计日志至指定存储 |
| 业务数据库 | 1. 存储 “Vault 路径 + 特征值字段”；2. 无任何敏感信息（含加密后数据） | 仅接收业务服务的 SQL 操作，拒绝其他直接访问 |
| 审计日志存储 | 存储 Vault 审计日志（敏感信息访问记录）与业务日志，支撑合规审计与问题追溯 | 1. Vault 自动写入审计日志；2. 业务服务写入业务日志 |
二、核心设计细节
1. 数据库字段拆分规则（零敏感信息落地）
业务数据库仅存储 “Vault 路径 + 特征值”，彻底杜绝敏感信息落地，字段设计如下：
（1）身份证号关联表设计（user_idcard）
| 字段名 | 类型 | 长度 | 用途说明 | 安全属性 |
|---|---|---|---|---|
| id | BIGINT | - | 自增主键 | 非敏感 |
| user_id | VARCHAR | 50 | 用户唯一标识（关联用户表） | 非敏感 |
| vault_path | VARCHAR | 100 | 敏感信息在 Vault 中的存储路径（如 id-cards/user_123） | 非敏感（无密钥无法访问） |
| id_card_feature | VARCHAR | 20 | 身份证号特征值（前 6 位行政区划码 + 后 4 位）；用于模糊查询 | 非敏感（公开信息） |
（2）银行卡号关联表设计（user_bankcard）
| 字段名 | 类型 | 长度 | 用途说明 | 安全属性 |
|---|---|---|---|---|
| id | BIGINT | - | 自增主键 | 非敏感 |
| user_id | VARCHAR | 50 | 用户唯一标识（关联用户表） | 非敏感 |
| vault_path | VARCHAR | 100 | 敏感信息在 Vault 中的存储路径（如 bank-cards/user_123_6226） | 非敏感（无密钥无法访问） |
| bankcard_feature | VARCHAR | 20 | 银行卡号特征值（前 6 位 BIN 码 + 后 4 位）；用于模糊查询与卡类型识别 | 非敏感（公开信息） |
设计原则：
- Vault 路径（vault_path）：唯一关联 Vault 中的敏感信息，业务服务需通过该路径 + Vault 认证获取数据；
- 特征值（xxx_feature）：仅存非敏感公开信息，支撑模糊查询，即使数据库泄露也无安全风险；
- 无加密字段：敏感信息全量由 Vault 托管，避免 “加密字段泄露 + 密钥泄露” 的双重风险。
备注：Vault 路径需包含用户唯一标识（如 user_id），确保路径唯一性；特征值需根据业务查询需求提前定义，避免后期修改导致历史数据不兼容。
2. Vault 核心配置与能力（原生加密赋能）
Vault 是 V2 方案的安全核心，无需业务服务关注加密细节，仅需配置 KV 引擎与认证策略：
（1）Vault KV 引擎配置
# 1. 启用KV v2引擎（支持版本控制，便于数据回滚），路径按敏感信息类型拆分
# 存储身份证号
vault secrets enable -version=2 -path=id-cards kv
# 存储银行卡号
vault secrets enable -version=2 -path=bank-cards kv
# 2. 配置KV引擎数据保留策略（保留3个版本，超期自动清理）
vault write id-cards/config max_versions=3
vault write bank-cards/config max_versions=3
（2）Vault 身份认证与权限控制
基于 K8s ServiceAccount 实现业务服务无密钥认证，权限按 “业务模块” 拆分：
| 业务服务角色 | Vault 权限范围 | 说明 |
|---|---|---|
| 用户认证服务 | create:id-cards/, create:bank-cards/ | 仅允许写入敏感信息（用户注册时存储） |
| 业务查询服务 | read:id-cards/, read:bank-cards/ | 仅允许读取敏感信息（业务查询时获取） |
| 审计服务 | read:sys/audit/* | 仅允许读取 Vault 审计日志，无数据访问权限 |
权限配置示例（用户认证服务 Policy）：
path "id-cards/*" {
capabilities = ["create", "update"] # 允许写入/更新身份证号
}
path "bank-cards/*" {
capabilities = ["create", "update"] # 允许写入/更新银行卡号
}
path "sys/audit/*" {
capabilities = ["deny"] # 拒绝访问审计日志
}
（3）Vault 审计日志配置
开启文件审计日志，记录所有敏感信息访问行为：
# 启用文件审计日志，存储路径/var/log/vault/audit.log，日志格式JSON
vault audit enable file file_path=/var/log/vault/audit.log log_raw=false format=json
备注：Vault 审计日志包含 “调用方 SA、访问时间、Vault 路径、操作类型、IP 地址” 等完整上下文，日志不可篡改，满足等保 “操作可追溯” 要求；主密钥可托管至第三方 KMS（如阿里云 KMS），支持自动轮换，无需人工干预。
四、安全与运维设计
1. 权限管控（纵深防御）
- Vault 角色权限：按 “最小权限” 原则配置 Policy，禁止跨业务模块访问（如查询服务无法写入数据）；
- K8s SA 隔离：每个业务服务使用独立 K8s ServiceAccount，Vault 绑定 SA 与角色，避免权限混用；
- 数据库权限：仅开放业务服务的 “应用账号” 访问关联表，运维 / 开发人员需通过 “多级审批” 获取临时权限，且查询结果隐藏 vault_path 字段（显示为 ***）。
备注：临时权限有效期不得超过 1 小时，操作全程记录审计日志；vault_path 字段泄露无风险（需 Vault 认证 + 权限才能访问数据），但仍建议隐藏，减少信息暴露面。
2. 高可用保障
- Vault 集群：部署 3 节点 Vault 集群，基于 Raft 协议实现数据同步，单个节点故障不影响服务可用性；
- 业务服务：通过 Vault SDK 实现 “失败重试 + 超时控制”（重试次数 3 次，超时时间 500ms），避免 Vault 短暂不可用导致业务失败；
- 数据库：采用主从架构 + 读写分离，主库写入关联表，从库支撑查询请求，提升并发能力。
备注：Vault 集群需配置 “密封 / 解封” 机制，主密钥分片存储（如 3 个管理员各持 1 片，2 片即可解封），避免单管理员泄露主密钥；建议定期（每季度）演练 Vault 集群故障切换，确保高可用能力有效。
3. 合规性落地（等保 2.0 适配）
- 敏感信息零落地：业务数据库无任何敏感信息，Vault 存储满足 “数据加密存储” 要求；
- 主密钥轮换：通过 vault operator rekey 命令或 KMS 自动轮换主密钥，轮换周期 3 个月，满足等保 “密钥定期更换” 要求；
- 审计日志留存：Vault 审计日志留存 6 个月，业务日志留存 1 年，支持按 “时间、用户、操作类型” 多维度查询，满足合规审计需求；
- 应急响应：Vault 故障时，业务服务自动降级（返回 “系统维护中”），敏感信息查询功能暂停；数据库泄露时，因无敏感信息，仅需排查 vault_path 是否泄露（无权限仍无法访问数据）。
备注：主密钥轮换过程业务无感知，Vault 自动完成 “旧密钥解密 SEK→ 新密钥加密 SEK”，历史数据正常读取；建议每半年进行一次合规自查，验证权限管控、日志完整性、密钥轮换有效性。
五、常用问题解答（FAQ）
1. Vault 主密钥轮换后，历史敏感数据能正常读取吗？
能。Vault 采用 “分层密钥架构”：主密钥仅加密 “存储加密密钥（SEK）”，不直接加密敏感信息；轮换时，Vault 用旧主密钥解密 SEK，再用新主密钥重新加密 SEK，敏感信息（加密后）完全不变，因此历史数据可正常读取。
备注：主密钥轮换前需确保旧主密钥可用（如 KMS 未删除旧密钥版本），轮换过程 Vault 服务不中断，业务无感知。
六、方案优势与适用场景
1. 核心优势
- 安全等级更高：敏感信息零落地，Vault 加密与权限管控经过工业级验证，比 V1 版自研加密更可靠；
- 合规能力更强：支持主密钥自动轮换、审计日志不可篡改，满足等保 2.0、金融行业合规要求；
- 业务无感知：加密 / 解密由 Vault 自动处理，业务服务无需关注安全细节，开发效率比 V1 版提升 50%；
- 扩展性更好：新增敏感信息类型（如护照号），仅需在 Vault 新增 KV 引擎 + 数据库关联表，无需修改业务逻辑。
2. 适用场景
- 中大型项目或金融、政务类高合规需求场景；
- 需支持动态模糊查询（如身份证任意位数模糊匹配）；
- 团队已采用 K8s 架构，有能力维护 Vault 集群；
- 合规要求严格（需等保 2.0 三级及以上、密钥自动轮换）。