上传数据安全：对称加密、非对称加密、签名与重放防护
上传数据安全：对称加密、非对称加密、签名与重放防护
“上传数据怎么保证安全"这个问题，不能只回答"用加密”。加密只是手段之一，真正要保护的是传输过程、数据内容、调用身份、请求完整性和重放风险。
一句话概括：普通业务优先使用 HTTPS 保护传输通道；敏感字段可以额外加密；大数据适合对称加密，小数据和密钥交换适合非对称加密；接口还要配合签名、时间戳、随机数和权限校验。
一、先分清要防什么
上传数据安全通常要防这几类问题：
| 风险 | 说明 | 常见手段 |
|---|---|---|
| 窃听 | 数据在网络中被看到 | HTTPS、字段加密 |
| 篡改 | 请求内容被改掉 | 签名、摘要 |
| 冒充 | 非法客户端伪造请求 | Token、证书、AK/SK |
| 重放 | 把旧请求重复发送 | 时间戳、nonce、幂等 |
| 泄漏 | 服务端存储不当 | 脱敏、加密存储、权限控制 |
如果只说"前端用公钥加密，后端用私钥解密"，其实只覆盖了其中一小部分。
二、HTTPS 是基础
很多敏感数据上传场景，第一层保护应该是 HTTPS。
HTTPS 通过 TLS 建立加密通道，可以保护传输过程中的机密性和完整性，避免明文数据在网络链路上被直接截获。
所以回答上传安全时，建议先说：
接口必须走 HTTPS，不能让账号、密码、身份证、支付信息等敏感数据明文传输。
然后再说是否需要业务层额外加密。
三、对称加密
对称加密指加密和解密使用同一把密钥。
| 特点 | 说明 |
|---|---|
| 加密速度 | 快 |
| 适合数据量 | 大 |
| 关键风险 | 密钥分发和保管 |
| 常见算法 | AES |
适用场景
- 文件上传前先用 AES 加密。
- 服务端拿到密文后用同一密钥解密。
- 密钥通过更安全的方式协商或下发。
PPT 里常会说"对称加密相对不太安全，不要保存敏感信息"，这句话容易让人误解。更准确的说法是：对称加密本身可以保护敏感数据，但安全性高度依赖密钥管理。如果密钥和密文放在同一个系统里、密钥硬编码在代码里、长期不轮换，那再强的算法也救不了。
注意：不要把密钥硬编码在前端代码里。前端代码天然容易被逆向，硬编码密钥等于把钥匙贴在门上。
四、非对称加密
非对称加密有一对密钥：公钥和私钥。
常见用法是公钥加密，私钥解密。也可以反过来用私钥签名、公钥验签，但那解决的是身份和完整性，不是保密。
| 特点 | 说明 |
|---|---|
| 安全性 | 密钥分发更安全 |
| 性能 | 比对称加密慢 |
| 适合数据量 | 小 |
| 常见算法 | RSA、ECC |
非对称加密适合加密少量敏感字段，或者用于交换对称密钥。大文件不适合全部用非对称加密，性能会很差。
五、混合加密更常见
真实系统里，经常是对称加密和非对称加密结合使用。
客户端生成随机 AES 密钥 → 用 AES 加密大数据 → 用服务端公钥加密 AES 密钥 服务端用私钥解密出 AES 密钥 → 用 AES 密钥解密数据这样既利用了对称加密的性能，也解决了对称密钥传输的问题。
如果已经使用标准 HTTPS，其实 TLS 握手内部也有类似"非对称能力协商密钥、对称密钥加密数据"的思路。业务层再做混合加密，一般是为了满足更高的合规要求、端到端字段保护，或者防止日志、代理、内部链路误暴露敏感字段，而不是替代 HTTPS。
六、签名解决什么问题
加密解决"别人看不看得到"，签名解决"数据有没有被改过，以及是谁发的"。
常见签名流程
签名常见字段
| 字段 | 作用 |
|---|---|
| appId | 标识调用方 |
| timestamp | 判断请求时间 |
| nonce | 随机数，防止重放 |
| bodyHash | 请求体摘要 |
| sign | 签名结果 |
签名算法分类
- 共享密钥生成的 HMAC（如 HMAC-SHA256）：适合 AK/SK 这类服务端到服务端接口。
- 私钥签名、公钥验签（如 SHA256withRSA、ECDSA）：适合调用方持有私钥、服务端只保存公钥的场景。
不要自己发明签名算法，字段规范、排序规则、编码规则必须固定，否则调用方和服务端很容易算出不同签名。
七、重放防护
重放攻击指攻击者不理解请求内容，也不需要解密，只是把一段旧请求再次发送。如果没有时间戳和 nonce，服务端可能会重复处理。
防护策略
- 请求时间戳不能和服务器时间相差太大。
- nonce 在有效期内只能使用一次。
- 关键业务再加幂等号，避免重复下单或重复支付。
八、密码不要"加密存储"
还有一个非常容易误答的点：用户密码不要用可逆加密存储。
密码存储应该使用慢哈希算法，并加盐，例如 Argon2id、BCrypt、PBKDF2。这样即使数据库泄漏，也不能直接解密出原密码，只能离线暴力猜测，而慢哈希的目的就是提高猜测成本。
登录时不是解密密码，而是把用户输入密码用同样规则计算哈希，再和数据库里的哈希比较。
所以不要说"密码用 AES 加密保存"。AES 是可逆的，一旦密钥泄漏，全部密码都会暴露。密码校验只需要判断"用户输入是否和原密码一致"，不需要拿回原文，这就是密码应该哈希而不是加密的根本原因。
九、面试怎么说
可以这样回答：
上传数据安全我会分层处理。
第一，传输层必须走 HTTPS，避免敏感数据明文传输。
第二，如果业务要求对字段做额外保护，可以对敏感字段加密。大文件或大报文适合用 AES 这类对称加密，速度快，但核心是密钥不能硬编码、不能和密文放在一起、要有轮换机制；少量敏感数据或密钥交换可以用 RSA、ECC 这类非对称加密。实际系统里也可以用混合加密，客户端生成随机 AES 密钥加密数据，再用服务端公钥加密 AES 密钥。
第三，为了防篡改和防伪造，请求要做签名，签名里带时间戳、nonce 和请求体摘要，算法用 HMAC 或标准非对称签名，不自己造规则。
第四，防重放要校验时间窗口，nonce 只能用一次，关键业务再做幂等。
密码这类数据不能可逆加密保存，应该用 Argon2id、BCrypt、PBKDF2 这类加盐慢哈希。
十、小结
上传安全不能只记"对称加密快，非对称加密安全"。
更完整的思路是：
HTTPS 保通道，加密保内容，签名防篡改，时间戳和 nonce 防重放，后端权限和存储策略兜底。
这套回答既能覆盖普通上传，也能自然延伸到支付、开放接口和敏感数据传输。