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

数据库账号密码是凭据泄露的重灾区。“一个 DBA 账号全公司用、密码三年不换、谁离职了也不知道要改”——这种场景一旦出事就是删库跑路级别。安当 SMS 的破法是**“两层模型”**不让业务长期持有固定高权限账号由 SMS 按需生成短期有效的数据库访问账号通过 TTL / 续约 / 回收降低泄露风险权限控制到库级/表级。本文讲透这套模型的设计与落地。一、核心目标与两个层不让业务长期持有固定 DBA 账号 → 由 SMS 按需生成短期有效的数据库访问账号 → 通过 TTL / 续约 / 回收降低泄露风险 → 权限控制到库级/表级根凭据控制面SMS 托管的高权限凭据是凭据工厂的上游控制面。✅ 只用于创建/授权/回收子凭据❌ 不下发业务使用。子凭据业务面基于根凭据派生的临时账号生命周期短、权限小、面向具体业务发放。⏱️ 到期自动失效或由系统回收。TTL / MaxTTLTTL 单次发放后有效时长“多久处理一次”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。六、小结两层模型的本质是把一个长期 DBA 账号换成一把把随用随发、到期即焚、权限精确、全程留痕的临时钥匙。根凭据只当工厂子凭据只当耗材——泄露面从全公司一把万能钥匙收敛到单个业务几分钟的有效期。关键词数据库凭据 / 动态凭据 / 最小权限 / 凭据回收 / 等保合规 / 安当SMS / 凭据安全 / 凭据管理