服务器敏感配置文件必须加密传输、最小权限访问且全程可审计：强制使用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 字段做掩码（如 ***），且禁止将完整配置写入构建产物