当前位置：首页 > news >正文

数据库动态凭据两层模型：根凭据与子凭据实战

news 2026/7/28 19:12:38

数据库账号密码是凭据泄露的重灾区。“一个 DBA 账号全公司用、密码三年不换、谁离职了也不知道要改”——这种场景一旦出事就是删库跑路级别。

安当 SMS 的破法是**“两层模型”**：不让业务长期持有固定高权限账号，由 SMS 按需生成短期有效的数据库访问账号，通过 TTL / 续约 / 回收降低泄露风险，权限控制到库级/表级。本文讲透这套模型的设计与落地。

一、核心目标与两个层

不让业务长期持有固定 DBA 账号 → 由 SMS 按需生成短期有效的数据库访问账号 → 通过 TTL / 续约 / 回收降低泄露风险 → 权限控制到库级/表级

根凭据（控制面）：SMS 托管的高权限凭据，是"凭据工厂"的上游控制面。✅ 只用于创建/授权/回收子凭据；❌ 不下发业务使用。
子凭据（业务面）：基于根凭据派生的临时账号，生命周期短、权限小、面向具体业务发放。⏱️ 到期自动失效或由系统回收。
TTL / MaxTTL：TTL = 单次发放后有效时长（“多久处理一次”）；MaxTTL = 从创建起允许续约的最长上限（“最多能活多久”）。
续约 & 回收：续约在 MaxTTL 范围内延长时间（适合长连接/批处理）；回收是过期后主动撤权并删除用户——必选项。

二、根凭据最佳实践

维度	要求
拆分策略	按环境（开发/测试/预发/生产）、按实例、按租户/业务域拆分。❌ 禁止用单一超级管理员账号覆盖全公司
职责边界	只做控制面、不做业务面；业务与运维排障都不直接使用根凭据连库
权限收敛	“最小可管理集”：创建用户、授予/撤销权限、删除子用户、必要时自身轮转。不授予无关系统/跨实例/超大全局权限
轮转治理	根轮转周期长、子 TTL 周期短；轮转前后均验证管理动作不受影响

一个根凭据对应一个数据库实例或清晰管理边界；一个根凭据下可派生多个子凭据模板/临时账号。不同业务、不同环境不要共用同组子凭据。

三、子凭据最佳实践

维度	要求
⏱️ 有效期	高频在线业务5分钟~1小时；批处理按任务时长 + 缓冲；人工临时访问更短且需审批
🔒 隔离	一个应用 / 一个实例 / 一个任务一个子凭据
📏 权限	优先级：表级（SELECT/INSERT/UPDATE/DELETE）→ 库级 → 全库高权限
🏷️ 命名	至少体现：业务标识 + 环境标识 + 时间片/随机后缀

权限设计上：继承模式（继承根凭据权限）仅适合 PoC / 快速验证 / 权限模型简单场景；生产优先使用自定义授权模板（库级/表级 + 三类标准模板：只读 / 读写 / 管理），表级授权优先。

四、生命周期闭环与"无空窗"切换

生命周期四步：📤 发放 → 🔑 使用 → 🔄 续约 → 🗑️ 回收。

发放：校验根凭据连通性 → 创建子用户 → 授予最小权限 → 写入 TTL/MaxTTL/过期时间 → 记录归属与审计。
使用：SDK / Agent / 文件读取；连接池配置 ≤ 匹配 TTL 节奏；对失效/续约失败有重试降级。
续约：只对确有持续访问需要的子凭据开启；由 Agent 按leadTimeSeconds提前量主动发起；超 MaxTTL 须重新申请。
回收：到期立即撤权或删除；回收失败进补偿队列；残留账号定期巡检二次清理。

当子凭据累计存活逼近 MaxTTL 上限，服务端不再续约旧凭据，Agent 转为**“重新申请”——由 SMS 基于根凭据派生一把全新的子凭据并返回。为避免空窗，新凭据会在旧凭据仍有效时被提前创建（重叠窗口）**，Agent 通过 Hikari 热更新 / 文件重载无缝换入。业务配置自始至终只写一次SMS{his-clinic-reg:username}，无需随轮换改动。

label 这个逻辑引用保持不变，SMS 服务端为每个 label 维护一张状态表：多把物理凭据版本，每把带唯一内部 ID、created_at、TTL/MaxTTL 与状态（active / retiring / decommissioned）；查询时永远返回 active 那把，旧凭据被标记 retiring 并在重叠窗口结束后回收。

五、失败分层处理

故障类型	影响	应对策略
发放失败	无法获取数据库访问凭证	阻断
续约失败	即将失去数据库访问权	告警 + 补偿重试
回收失败	残留账号未清理，存在安全隐患	清理任务 + 高优先级审计事件

业务接入要点：不要缓存过久（支持定时重连、凭据变更后刷新连接池）；长事务/长任务提前设计续约或任务切分；连接池策略配合 TTL，避免连接生命周期 ≫ 凭据 TTL。