静态加密 vs 传输中加密：两者对安全性都重要

传输中加密保护在两点之间移动的数据——例如你的浏览器与服务器之间的通信——使用 TLS 1.3 配合 AES-256-GCM 或 ChaCha20-Poly1305。静态加密保护存储在磁盘上的数据，通常使用全盘加密的 AES-256-XTS 或单文件加密的 AES-256-GCM。两者单独使用都不够：TLS 防止网络窃听，但在服务器端解密；静态加密保护已存储的数据，但如果密钥和密文放在一起则毫无意义。真正的安全性来自将两者叠加，最好再加上客户端（端到端）加密，使服务器从不看到明文。

两种不同的威胁，两种不同的防御

威胁的样貌取决于数据所处的位置：

传输中（网络路径）：咖啡馆里运行数据包嗅探器的攻击者、遭到攻陷的 ISP 路由器、针对海底电缆的国家级监听。2013 年斯诺登文件揭示了 NSA 的 MUSCULAR 项目，该项目直接监听 Google 内部光纤链路。防御手段：TLS 1.3，对应用程序可加用证书固定。

静态（存储）：被盗的笔记本、泄露的备份磁带、配置错误的 S3 存储桶、拥有磁盘访问权限的恶意数据中心员工。2017 年 Equifax 数据泄露暴露了 1.47 亿条记录，部分原因正是数据以明文存储。防御手段：磁盘层面使用 LUKS、BitLocker、FileVault；文件或数据块层面使用 AES-256-GCM 或 AES-256-XTS。

常见错误是把一种当作另一种的替代品。TLS 无法保护数据库转储。磁盘加密无法阻止中间人攻击。

TLS 1.3 如何保护传输中的数据

TLS 1.3 于 2018 年在 RFC 8446 中标准化，是现代默认协议。它的特点包括：

默认前向保密，通过临时 ECDHE 密钥交换实现。即使服务器长期密钥泄露，历史会话数据仍受保护。
仅使用 AEAD 密码——AES-128-GCM、AES-256-GCM 或 ChaCha20-Poly1305。旧的 CBC 模式和 RC4 已被彻底移除。
单次往返握手（1-RTT），或恢复时零次往返（0-RTT）。
加密握手，使被动观察者无法看到证书链。

所有知名文件传输服务——WeTransfer、SwissTransfer、Tresorit、Proton Drive、HexaTransfer——都运行 TLS 1.3 并设置 HSTS 头，强制 HTTPS 至少持续 12 个月。你可以通过 SSL Labs 的 testssl 工具验证；评分低于 A- 的服务存在配置问题。

服务器端的静态加密机制

文件到达并经 TLS 解密后，静态加密接管。共有几个层次：

块级（全盘）：Linux 上的 LUKS、Windows 上的 BitLocker、macOS 上的 FileVault，或云端等价物如 AWS EBS 加密，均使用 AES-256-XTS。防止磁盘被盗后数据泄露。
文件系统级：eCryptfs、ext4/F2FS 上的 Fscrypt。每个用户的文件用独立密钥加密。
对象存储级：AWS S3 SSE-KMS、Azure Blob 存储服务加密、Google Cloud Storage 客户管理密钥。每个对象以 AES-256-GCM 加密。
应用层：服务在自己的代码中对每个文件加密后再写入存储，密钥存放在 KMS 或 HSM 中。

应用层最安全，因为加密发生在任何存储系统看到数据之前。AWS KMS 每个密钥每月收费约 1 美元加上每万次请求 0.03 美元——足够廉价，以至于严肃的服务可以对每个文件使用独立密钥。

"密钥与密文同址"的陷阱

静态加密常见的失效场景：如果密钥与密文存储在同一台服务器上，攻击者攻陷服务器后即可同时获得两者。服务商可以在合规文件中勾选"静态加密"选项，却对服务器被攻破几乎毫无防护。

良好的架构分离了这两个关注点：

密文存储在 S3 或类似的对象存储中。
加密密钥存储在 AWS KMS、Google Cloud KMS、Azure Key Vault 或专用 HSM 中。
密钥访问通过短期 IAM 凭据和审计日志进行控制。

更好的架构走得更远：密钥从不存在于服务器。客户端加密（E2EE）意味着用户浏览器生成密钥、加密文件、并持有密钥；服务器只存储密文，没有任何可泄露的东西。

加密盲区出现在哪里

即使两种控制都已到位，数据在以下几处仍会短暂以明文形式存在：

服务器内存中，在上传处理、病毒扫描或缩略图生成期间。在此窗口期的内存转储会泄露明文。
访问日志中，如果文件名或内容片段被记录用于调试。
备份磁带中，如果备份没有继承相同的加密配置。
压缩或转码期间，服务需要处理文件内容时。
下载后的浏览器缓存中，用户未清除缓存时。

这些盲区正是零知识（客户端）加密的意义所在。当文件在上传前就在浏览器中加密时，服务端的这些盲区变得无关紧要——服务器始终只见到密文。

主流服务的实际做法

基于公开文档的粗略分类：

Google Drive、Dropbox、OneDrive：传输中使用 TLS 1.3，静态使用 AES-256 配合服务商持有的密钥。非零知识——服务商能读取你的文件。
WeTransfer（免费档）：TLS 1.3，在 AWS S3 上静态 AES-256，服务商持有密钥。
Box Enterprise：TLS 1.3，静态 AES-256-GCM，可选客户管理密钥（Box KeySafe）。
Tresorit、Proton Drive、SwissTransfer E2EE 档、HexaTransfer：传输中 TLS 1.3，静态 AES-256-GCM，但每个文件的密钥由客户端生成，从不到达服务器。实质上是零知识。

对于敏感数据，只有最后一类能有效抵御内部威胁和合法数据请求。

合规要求与"纵深防御"

监管机构明确要求两者兼备：

GDPR 第 32 条要求对个人数据进行"假名化和加密"，未限制数据所处的状态。
HIPAA 安全规则 45 CFR § 164.312要求对电子受保护健康信息（ePHI）在传输中和静态时都进行加密。
PCI DSS 4.0 要求 3 和 4分别针对"保护存储的持卡人数据"（静态）和"传输中使用强加密保护持卡人数据"（传输中）。
FIPS 140-3 验证适用于这两种场景中的加密模块。

仅满足其中之一在合规层面就已失败，更不用说安全层面了。

如何验证两者均已启用

对任何文件传输服务进行五项快速检查：

运行 testssl.sh https://provider.com，确认仅使用 TLS 1.3 和强密码套件。
检查 HSTS 头，max-age 应至少为 31,536,000（一年）。
阅读安全白皮书，查找明确提及 AES-256-GCM 或 AES-256-XTS 静态加密的内容。
确认密钥存储在 KMS 或 HSM 中，而非应用数据库中。
查找 SOC 2 Type II 或 ISO 27001 认证——两者都要求记录静态和传输中加密控制措施。

加分项：检查客户端加密是否作为可选功能提供。如果有，对任何敏感内容都应开启。

正确的叠加方式

真正有效的方案如下：

浏览器使用随机 AES-256-GCM 密钥在本地加密文件（客户端加密）。
密文通过 TLS 1.3 传输到服务器（传输中加密）。
服务器将密文存储在 AES-256 加密存储上（静态加密）。
解密密钥只存在于分享链接的 URL 片段中，从不发送给服务器。

三层独立保护，攻破其中一层，其余两层仍然有效。这正是 HexaTransfer 以及 Tresorit Send、Proton Drive 分享链接和 SwissTransfer E2EE 模式所采用的设计。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。