服务器敏感配置文件必须加密传输、最小权限访问且全程可审计:强制使用sftp/scp或https(tls 1.2+)、mtls/jwt分发;敏感字段应用层加密(如sops+age),密钥独立托管;传输限ci/cd自动注入、mfa认证与操作留痕;传输后清理缓存、日志脱敏。

服务器敏感配置文件(如数据库密码、API密钥、私钥等)绝不能以明文形式在网络中传输。核心原则是:加密传输 + 最小权限 + 传输过程可审计。
使用加密通道强制传输
所有配置文件的网络传输必须走端到端加密协议,禁止使用 FTP、HTTP、Telnet 等明文协议。
- 优先使用 SFTP(基于 SSH)或 SCP 替代 FTP,确保传输层和身份认证双重加密
- 通过 HTTPS(TLS 1.2+)上传/下载配置时,确认服务端证书有效且域名匹配,避免中间人劫持
- 若需 API 方式分发(如 GitOps 场景),使用双向 TLS(mTLS)或短期访问令牌(JWT),并绑定 IP 和时效
传输前对配置内容做针对性脱敏与加密
即使走加密通道,也建议对真正敏感字段做应用层保护,降低密钥泄露或通道被绕过的风险。
- 用工具(如 sops + Age 或 GPG)对 YAML/JSON 配置中的 password、private_key 等字段单独加密,其余保持可读便于审计
- 避免整文件 AES 加密后传输——密钥管理复杂,且无法做字段级权限控制
- 加密密钥不随配置文件存放,应从独立凭证服务(如 HashiCorp Vault、AWS Secrets Manager)动态获取
限制传输行为本身:谁、何时、何地、用何方式
不是“能不能传”,而是“该不该传”——很多场景下,配置本就不该离开可信环境。
- 禁止开发人员直接上传配置到生产服务器;应通过 CI/CD 流水线自动注入,且流水线节点需隔离、日志全量留存
- 配置文件传输操作必须绑定多因素认证(MFA),并记录操作者、源 IP、目标主机、文件哈希、时间戳
- 对临时传输任务(如紧急修复),启用一次性传输链接(带 TTL 和单次访问限制),超时自动失效
传输完成后立即清理残留痕迹
传输完成不等于风险结束,缓存、日志、临时文件都可能暴露敏感信息。
- 禁用 SFTP/SCP 服务的上传目录自动保留历史版本功能;传输后自动删除源端临时副本
- 确保系统日志(如 bash history、auditd、rsyslog)不记录含敏感值的命令参数(例如避免 scp config.yaml user@prod:/etc/app/ 中的路径暴露用途)
- CI/CD 日志需过滤变量输出,对 secrets 字段做掩码(如 ***),且禁止将完整配置写入构建产物










