密钥传输在防什么
私钥、对称密钥、CA 材料在生成环境与使用环境之间转移时，最容易出事的环节不是算法而是「路上」。要求有四条：走受控通道、传输前加密封装、随附可校验的来源与完整性凭据、接收方验证后按最小权限落盘并清理中转副本。全过程还要留痕——密钥一旦泄露，分发记录是唯一能把排查范围收敛到具体环境和时间的线索。
基本信息
| 适用平台 | Linux、Windows 运维环境与 CI/CD 流水线 |
|---|---|
| 封装方式 | 信封加密（接收方公钥）或对称加密 + 独立口令通道 |
| 完整性 | 随附摘要或签名，接收方解密后逐项核对 |
| 通道要求 | 受控文件传输、跳板机或密钥管理系统；不用聊天工具与明文邮件 |
| 接收端 | 校验通过后收起权限（如 600、属主为服务账号）再落盘 |
| 事后处理 | 清理中转副本，记录交接时间、经手人与文件哈希 |
典型使用场景
- 把 CA 签发的证书与私钥从生成主机搬到业务服务器
- CI/CD 把发布签名密钥注入构建节点，供流水线批量使用
- 跨数据中心或跨云搬运 TLS 私钥，同步已有节点配置
- 运维职责交接时移交密钥材料与使用说明
- 应急轮换时向多台主机批量下发新密钥并回收旧密钥
加密封装与校验示例
加密封装与校验示例
# 用接收方证书做信封加密，只有持有对应私钥的一方能解开
openssl smime -encrypt -aes256 -in key.pem -out key.pem.enc recipient.crt
# 同时生成摘要，接收方解密后比对，确认途中未被替换
sha256sum key.pem > key.pem.sha256
ssh transfer@target 'mkdir -p ~/incoming' # 先约定落地目录，避免随手放 /tmp
scp key.pem.enc key.pem.sha256 transfer@target:~/incoming/ # 经受控通道传输
ssh transfer@target 'cd ~/incoming && openssl smime -decrypt -in key.pem.enc \
-recip recipient.crt -inkey recipient.key -out key.pem && sha256sum -c key.pem.sha256'传输方式对照
| 方式 | 适合场景 | 风险点 |
|---|---|---|
| 信封加密 + 文件传输 | 跨组织、异步交接 | 口令或接收方私钥管理不当，封装形同虚设 |
| 密钥管理系统下发 | 大规模、频繁轮换 | 依赖管理系统自身的权限模型与审计能力 |
| 带外分片传递 | 高敏感密钥 | 流程复杂易出错，恢复时对不上片段 |
| SSH/SCP 直传 | 同一信任域内 | 通道加密了，但目标目录权限与留痕常被忽略 |
| 即时通讯或邮件附件 | 不适用 | 明文落在第三方服务器与本地客户端缓存中 |
对称口令不要和被加密的密钥走同一条通道：口令改用电话、工单或密钥管理系统单独传递，两者分路才构成真正意义上的一次性交付，否则拿到封装文件的人往往也拿得到口令。
接收方落盘后顺手做三件事：确认权限与属主最小化、确认只有服务账号能读、把文件哈希与时间写进交接记录。这三步几乎零成本，却是事后定位的唯一起点。
应急轮换别只发新密钥：先定好旧密钥的下线口径（哪些系统已切换、是否吊销、是否仍需保留用于验签），新旧长期并存会让审计与排查都失去边界。