📚 课程目录第4章安全基石

4、安全基石：TLS/SSL传输加密、数据存储加密、密钥管理最佳实践

身份同步这件事，说白了就是在不同设备之间传递「你是谁」这个证据。如果传输通道是裸的，存储是明文的，密钥是随便放的——那这个同步方案就是个筛子。我见过太多团队把精力花在同步协议上，结果安全层面一碰就碎。

这一章，我们聚焦三个核心问题：数据在路上的安全、数据在库里的安全、钥匙怎么管。这三件事做好了，你的同步方案才算有了地基。

核心原则：传输加密防窃听，存储加密防泄露，密钥管理防滥用。三者缺一不可。

4.1 传输加密：别让数据裸奔

身份同步最容易被忽视的环节就是传输层。我见过一个项目，设备之间用 WebSocket 直连，数据包是 JSON 明文——抓个包就能看到用户的 token 和密钥。这跟把密码写在明信片上寄出去有什么区别？

正确的做法是：所有设备间的通信必须走 TLS。不管是 REST API、WebSocket 还是 gRPC，底层都要有 TLS 保护。

4.1.1 TLS 版本选择

我个人习惯直接上 TLS 1.3。为什么？

握手更快：1-RTT 完成，比 TLS 1.2 少一次往返
更安全：移除了有问题的加密套件，强制前向安全
配置简单：不需要纠结 cipher suite 列表

避坑指南：我曾经在项目中遇到 TLS 1.2 的「降级攻击」——攻击者强制客户端和服务端使用弱加密套件。升级到 TLS 1.3 后，这个问题从根本上解决了。

4.1.2 双向 TLS（mTLS）

普通的 TLS 只验证服务端证书，客户端是匿名的。但在设备身份同步场景下，我们需要双向认证——设备也要出示自己的证书。

为什么？因为你要确保连接过来的确实是你的设备，而不是某个伪造的客户端。mTLS 让每台设备都有一个唯一的身份凭证。

// 服务端 mTLS 配置示例（Go）
tlsConfig := &tls.Config{
    ClientAuth: tls.RequireAndVerifyClientCert,
    ClientCAs:  clientCertPool,
    MinVersion: tls.VersionTLS13,
}

注意：mTLS 的证书管理成本不低。每台设备需要签发、分发、轮换证书。建议使用自动化的 CA 系统，比如 cert-manager 或 Vault PKI。

4.2 存储加密：数据在库里也要穿衣服

传输加密解决了「路上」的问题，但数据到了设备本地呢？如果设备丢失、被 root、或者数据库文件被拖走，明文存储的同步数据就是灾难。

我个人的原则是：能加密的绝不存明文。尤其是身份同步中的 token、密钥、设备 ID 这些敏感字段。

4.2.1 全盘加密 vs 应用层加密

方案	优点	缺点	适用场景
全盘加密（FDE）	系统级保护，透明无侵入	设备解锁后数据可读，无法防御进程级攻击	移动设备、笔记本
应用层加密	字段级控制，密钥与应用隔离	需要自行管理密钥，性能开销	身份同步数据、token 存储
数据库透明加密（TDE）	数据库层面自动加密	密钥管理依赖数据库厂商	服务端数据库

我的建议是：全盘加密 + 应用层加密叠加使用。全盘加密防物理丢失，应用层加密防进程级泄露。

4.2.2 字段级加密实践

对于身份同步中的敏感字段，我习惯用 AES-256-GCM 做字段级加密。GCM 模式自带认证，能防篡改。

// 字段级加密示例（Go）
import (
    "crypto/aes"
    "crypto/cipher"
    "crypto/rand"
)

func encryptField(plaintext []byte, key []byte) ([]byte, error) {
    block, _ := aes.NewCipher(key)
    gcm, _ := cipher.NewGCM(block)
    nonce := make([]byte, gcm.NonceSize())
    rand.Read(nonce)
    return gcm.Seal(nonce, nonce, plaintext, nil), nil
}

个人经验：nonce 一定要随机生成，不要复用。我曾经见过一个项目用固定 nonce，结果相同的明文加密出相同的密文——攻击者直接能看出数据模式。

4.3 密钥管理：最容易被忽视的环节

加密算法再强，密钥泄露了等于白干。我见过太多团队把密钥硬编码在代码里、放在配置文件里、甚至写在日志里。嗯，这些都是真实踩过的坑。

4.3.1 密钥从哪里来

密钥不能靠「拍脑袋」生成。要用密码学安全的随机数生成器。

// 生成 256 位密钥
key := make([]byte, 32)
rand.Read(key)

但生成只是第一步。关键是：密钥存在哪？

硬件安全模块（HSM）：最安全，但成本高
安全飞地（Secure Enclave）：iOS/Android 设备内置，适合移动端
密钥管理服务（KMS）：云厂商提供，适合服务端
操作系统密钥链（Keychain/Keystore）：适合桌面和移动应用

4.3.2 密钥轮换策略

密钥不能「一次生成，用到天荒地老」。我建议的轮换策略：

密钥类型	轮换周期	轮换方式
传输层密钥（TLS 证书）	90 天	自动续签（ACME 协议）
存储加密密钥（DEK）	180 天	重新加密数据
密钥加密密钥（KEK）	365 天	仅换 KEK，不解密数据
设备身份证书	按设备生命周期	吊销 + 重新签发

我曾经踩过的坑：轮换密钥时忘了处理旧数据。结果旧数据用旧密钥加密，新数据用新密钥加密——系统里同时存在两套密钥，管理复杂度翻倍。建议用「密钥版本号」机制，每个密文都带上版本标识。

4.3.3 最小权限原则

密钥的访问权限要严格控制。不是所有组件都需要访问所有密钥。

传输加密密钥：仅网络层可访问
存储加密密钥：仅持久化层可访问
设备身份私钥：仅安全飞地可访问

说白了，就是谁用谁拿，用完即弃。不要搞一个「万能密钥」到处用。

4.4 实战：身份同步的安全架构

把上面三块拼起来，一个完整的身份同步安全架构应该是这样的：

设备 A 通过 mTLS 连接到同步服务，双方验证证书
同步服务将身份数据用 AES-256-GCM 加密后存储
存储密钥由 KMS 管理，服务本身不接触明文密钥
设备 B 同样通过 mTLS 拉取数据，在本地安全飞地中解密
所有密钥每 90 天自动轮换，旧密钥保留用于解密历史数据

一句话总结：传输用 mTLS，存储用 AES-256-GCM，密钥用 HSM/KMS 管。三层防护，缺一不可。

嗯，这一章的内容就到这里。安全这件事，没有「差不多就行」。你想想看，身份同步一旦出安全问题，泄露的不是普通数据，而是用户的数字身份——这个代价，谁都承担不起。