安当SMS凭据管理部署最佳实践：四要素与两层模型

安当SMS凭据管理部署最佳实践四要素与两层模型关键词凭据管理、密钥管理、动态凭据、静态凭据、最小权限、等保合规、安当SMS、凭据安全把密码换个地方存一下并不是凭据管理的终点。真正的安全是把散落在配置文件、脚本、代码仓库、人工传递中的机密统一收口实现可托管、可授权、可轮换、可审计、可回退的治理闭环。本文基于安当 SMSSecret Management System凭据管理系统的部署实践从架构、设计原则、凭据模型、接入场景到安全红线给出一套可落地的部署最佳实践。一、SMS 整体架构SMS 分为三层向上承接业务接入向下对接凭据存储① 业务接入层Jenkins 插件、Java Spring Boot Starter、KubernetesAgent/Sidecar、代理环境变量注入黑盒应用、LDAP、RabbitMQ 六类场景。② SMS 核心平台统一托管、动态取密、权限控制、全程审计。③ 凭据存储层静态凭据长期/半长期机密四要素治理 数据库动态凭据根凭据子凭据两层模型。覆盖两类凭据静态凭据密码 / API Key / Token 等、数据库动态凭据短期临时账号覆盖六类接入场景。二、8 条核心设计原则强制基线不管用哪种接入方式以下原则为强制要求职责分离业务侧只消费凭据SMS 负责托管业务保存的是定位信息 接入配置而非长期明文密码。运行时动态获取凭据运行时动态拉取而非提前手工同步到本地或镜像层。绝不落盘、绝不打印明文禁止写入 git / 镜像 / 配置文件 / 日志排障日志只允许打印是否命中、命中的 key不含值、错误码。最小权限调用账号只能访问其需要的label/version业务账号不持有高权限。最小暴露、最小输出凭据以存在性 / 长度 / 连接是否成功摘要验证而非明文回显。全程审计创建、查看、轮换、切换版本、废弃、导出均留痕。可轮换、可回退轮换基于版本切换必须能回退到上一版本。生产启用 TLS联调可临时关 TLS 校验快速打通生产必须启用且用受信任证书禁止长期关闭。三、静态凭据“四要素模型”静态凭据治理对应 SMS 创建表单的 4 个关键字段建议创建时就填好后续查询、审计、应急回收都依赖这些信息要素字段典型值凭据对象凭据类型数据库密码 / API Key / OAuth Token / SSH 私钥 / 证书归属边界标签业务线:订单服务 / 环境:生产-A区 / 负责人:运维团队用途边界说明仅限订单库 SELECT / 禁止写入 / 仅 Jenkins 构建任务使用生命周期审计日志手动更换新值 / 变更时间操作人自动留痕 / 紧急回收处置一句话四要素分别映射到凭据类型 → 标签 → 说明 → 审计日志这是静态凭据可治理的基础。四、数据库动态凭据“两层模型”动态凭据的核心目标不让业务长期持有固定 DBA 账号由 SMS 按需生成短期有效的数据库访问账号。根凭据控制面高权限账号只用于创建/授权/回收子凭据不下发业务使用相当于凭据工厂。一个根凭据对应一个数据库实例或清晰管理边界。子凭据业务面基于根凭据派生的临时账号生命周期短、权限小、面向具体业务发放到期自动失效或回收。关键设计TTL / MaxTTLTTL 单次发放后有效时长MaxTTL 从创建起允许续约的最长上限。高频在线业务 5 分钟~1 小时批处理按任务时长 缓冲。续约 回收MaxTTL 范围内可续约适合长连接 / 批处理过期后主动撤权并删除用户——回收是必选项否则退化为伪动态。权限设计生产优先自定义授权模板库级 / 表级 只读 / 读写 / 管理三类标准模板表级授权优先于继承模式。label 稳定性重新派生时变的是底层物理凭据用户名/密码label这个逻辑引用保持不变。业务配置只写一次SMS{his-clinic-reg:username}SMS 服务端维护多把物理凭据版本查询永远返回active那把旧凭据标记retiring并在重叠窗口结束后回收。五、六种接入场景选型4.1 Jenkins 插件构建时动态取密定位Jenkins 负责构建SMS 负责托管职责分离。配置分层全局配置只放连接与认证参数Base URL / Domain / App ID / App Secret / 客户端私钥 PEM / TLS 校验单条动态凭据只放远端定位信息Jenkins ID / SMS Label / Version / 凭据类型。命名规范mysql-prod-app、ldap-test-admin、rabbitmq-prod-publisher、api-token-release禁止 UUID 当长期业务 ID。Pipeline先做注入验证再做业务验证最小验证只校验用户名存在、密码长度、连接成功不回显明文。4.2 Java Spring Boot Starter启动自动解密注入application.yml中用SMS{...}标记敏感配置不落盘明文启动时自动解密注入 Spring Environment业务代码零改造ksp:sms:enabled:trueurl:https://ksp-sms-hostdomain:1appKey:${KSP_SMS_APP_KEY}# 仅来自环境变量/启动参数appSecret:${KSP_SMS_APP_SECRET}cipherPrefix:SMS{jsonKey:valuespring:datasource:username:SMS{mysql00:username}password:SMS{mysql00:password}解密失败策略强安全场景fail-fast解密失败直接终止启动兼容场景允许启动但必须告警。运行期轮转刷新可选refresh.enabledtrueHikari 连接池热更新更新用户名/密码并逐步淘汰旧连接validateOnRotatetrue避免切到无效凭据。4.3 Kubernetes 对接两种注入方案方案实现适用场景方案一显式注入业务在 YAML 显式加入sms-agent静态 init 模式拉一次 / 动态 sidecar 模式持续刷新首次 PoC、单业务试点方案二自动注入平台部署注入器基于 MutatingAdmissionWebhook 自动补齐容器/卷/挂载多业务多命名空间、平台化治理统一架构原则身份统一固定 ServiceAccount按namespace serviceAccountName绑定角色、凭据消费统一优先读/sms/secrets的bundle.json、密钥管理统一RSA 私钥走 K8S Secret、交付边界统一平台侧 / 集群管理员 / 业务团队各司其职。推荐三步走单业务验证取密/解密/文件输出 → 验证文件读取与动态重载 → 推广到统一模板或自动注入模式。4.4 代理环境变量注入黑盒 / 不可改造应用通过sms-cli 启动脚本在进程启动前注入不修改业务代码与 JAR。交付包含sms-launcher.sh/sms-config.yaml和.sms-cache.enc首次成功后自动生成的加密缓存AES-GCM灾备回退。安全禁止命令行参数传明文密码Linux 用临时文件 source且umask 077用后删除缓存密钥SMS_CACHE_KEY由客户侧定义并环境变量注入建议 ≥32 位强随机串。4.5 LDAP 接入统一优先创建专用技术账号 平台托管密码生命周期。根凭据必须使用客户侧专用服务账号仅用于查询用户、改密、读组信息不得用目录超级管理员代替。轮转生产 30 天、测试 7 天异常事件离职 / 疑泄露 / 异常登录立即手动轮转账号纳入平台后改密必须统一通过平台。4.6 RabbitMQ 接入统一专用业务账号 最小权限分发 生产消费分离。权限红线禁止.*全通配、全量配置权限、管理员角色、生产消费共用同一账号、多系统共用同一业务账号。标准权限模型仅两类——仅发布 / 仅消费。六、10 条安全红线强制业务系统不长期持有固定高权限账号统一通过 SMS 动态/托管获取。任何环境明文凭据不得写入 git / 镜像 / 配置文件 / 日志 / 邮件 / 代码仓库。绝不回显明文密码、Token、私钥、密文。运行型凭据与管理型凭据严格分离禁止管理员账号作业务运行账号。多个系统/环境不共用同一份凭据测试与生产账号隔离。高敏凭据私钥、管理员密码限制导出避免明文散落。轮换基于版本且可回退禁止直接覆盖旧值。生产环境启用 TLS 校验不长期依赖关闭 TLS 校验。不绕开平台直接改密且不回填平台。日志/报表/截图/工单中不得暴露真实密码或密钥内容。七、实施路线建议整体节奏先梳理边界 → 再定义模型与模板 → 接通生命周期链路 → 最后推动业务适配与规模化治理。第 1 步 静态凭据 / 接入治理先行先完成机密收口统一通过 SMS 获取解决明文散落与权限混乱再演进到动态模式。第 2 步 数据库动态凭据四步推进梳理数据库类型/环境/实例/业务边界 → 定义根凭据拆分与标准权限模板 → 接入子凭据 TTL/续约/回收链路 → 推动业务连接池与配置适配。第 3 步 K8s 三步走单业务验证 → 文件读取与动态重载 → 统一模板或自动注入。核心理念先收口再动态、单点验证后推广、三步走取密 → 重载 → 规模化。八、常见误区误区正解把 Jenkins / 业务系统当长期秘密存储只保存定位信息与接入配置真实秘密来自 SMS日志打印真实密码做验证用存在性 / 长度 / 真实连接验证不依赖日志脱敏联调成功后长期关闭 TLS 校验联调可暂关生产恢复证书校验数据库只发不收强制启用回收与残留账号巡检否则退化为伪动态静态凭据永久不轮换按风险分级建立轮换计划与提醒RabbitMQ 配.*全通配权限标准仅发布 / 仅消费两类禁止全通配与管理员角色多个系统共用同一份凭据按系统 / 环境 / 用途拆分独立账号独立责任总结SMS 部署最佳实践的核心是让各接入方以标准、稳定、安全的方式成为 SMS 的动态凭据消费端——统一托管、统一治理、动态取密、更易轮换、更易审计从而把密码托管真正升级为最小权限的动态访问控制与统一机密治理能力。对正在做等保合规、凭据安全改造的团队来说先把静态凭据四要素填好、把数据库动态凭据两层模型接通结合本文的 10 条红线与实施路线基本可以避开 90% 的落地坑。