保存時暗号化 vs 転送時暗号化：セキュリティに両方重要

転送時暗号化はブラウザとサーバー間など、2点間を移動するデータを TLS 1.3（AES-256-GCM または ChaCha20-Poly1305）で保護します。保存時暗号化は、ディスク上に静置するデータを、フルディスク暗号化には AES-256-XTS、ファイル単位では AES-256-GCM で保護します。どちらか一方だけでは不十分です。TLS はネットワーク盗聴は防ぎますが、サーバーで復号されます。保存時暗号化は保存データを保護しますが、鍵が暗号文と同じ場所にあれば無意味です。真のセキュリティは両者を重ねることで実現します。理想的にはクライアントサイド（エンドツーエンド）暗号化も加え、サーバーが平文を一切見ない構成にすることです。

二つの異なる脅威、二つの異なる対策

データの場所によって脅威の形が変わります。

転送時（ネットワーク経路）：カフェのパケットスニッファー・侵害された ISP ルーター・海底ケーブルを傍受する国家機関などが脅威です。2013年の Snowden 文書は、NSA の MUSCULAR プログラムが Google の内部ファイバー回線を盗聴していた事実を明らかにしました。対策は TLS 1.3、アプリ向けには証明書ピン留めの追加です。

保存時（ストレージ）：盗まれたラップトップ・漏洩したバックアップテープ・設定ミスの S3 バケット・ディスクにアクセスできる悪意ある社員などが脅威です。2017年の Equifax 侵害は、データが暗号化されずに保存されていたことが一因で1億4,700万件の個人情報が流出しました。対策は、ディスク向けに LUKS・BitLocker・FileVault、ファイル・ブロック単位では AES-256-GCM または AES-256-XTS です。

よくある誤りは、どちらか一方を他方の代替として扱うことです。TLS はデータベースダンプを保護しません。ディスク暗号化は中間者攻撃を防ぎません。

TLS 1.3 が転送時データを保護する仕組み

RFC 8446（2018年）で標準化された TLS 1.3 は現代のデフォルトです。その特徴は以下のとおりです。

デフォルトの前方秘匿性：一時的な ECDHE 鍵交換により、長期鍵が漏洩しても過去のセッションは保護されます。
AEAD 暗号のみ：AES-128-GCM・AES-256-GCM・ChaCha20-Poly1305 を使用。旧来の CBC モードや RC4 は排除されました。
1往復のハンドシェイク（1-RTT）、再開時はゼロ往復（0-RTT）。
暗号化されたハンドシェイク：受動的な観測者に証明書チェーンが見えません。

WeTransfer・SwissTransfer・Tresorit・Proton Drive・HexaTransfer などの信頼できるファイル転送サービスはすべて、少なくとも12か月間 HTTPS を強制する HSTS ヘッダーとともに TLS 1.3 を使用しています。SSL Labs の testssl ツールで確認でき、A- 未満であれば設定に問題があります。

サーバーでの保存時暗号化の仕組み

ファイルが届いて TLS が終端すると、保存時暗号化が引き継ぎます。いくつかの層があります。

ブロックレベル（フルディスク）：LUKS（Linux）・BitLocker（Windows）・FileVault（macOS）・AWS EBS 暗号化などのクラウドプロバイダー相当品での AES-256-XTS。ディスク盗難から守ります。
ファイルシステムレベル：ext4/F2FS 上の eCryptfs・Fscrypt。ユーザーごとに個別の鍵でファイルを暗号化します。
オブジェクトストレージレベル：AWS S3 SSE-KMS・Azure Blob のストレージサービス暗号化・顧客管理鍵を使用した Google Cloud Storage。各オブジェクトは AES-256-GCM で暗号化されます。
アプリケーションレベル：サービスがストレージに書き込む前に、自身のコードで各ファイルを暗号化します。鍵は KMS または HSM に保管されます。

アプリケーションレベルが最も強力です。ストレージシステムが暗号化されたデータだけを受け取るからです。AWS KMS はキーあたり月1ドル、リクエスト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 Security Rule 45 CFR § 164.312：ePHI の転送時と保存時の両方の暗号化を要求します。
PCI DSS 4.0 要件3・4：「保存カード会員データの保護」（保存時）と「強力な暗号化による送信時の保護」（転送時）を分けて規定しています。
FIPS 140-3：両方のコンテキストで使用される暗号モジュールの検証に適用されます。

どちらか一方だけでは、セキュリティ上の問題になる前にコンプライアンス違反になります。

正しいレイヤー構成

実際に機能するパターンは以下のとおりです。

ブラウザがランダムな AES-256-GCM 鍵でファイルを暗号化する（クライアントサイド）。
暗号文が TLS 1.3 でサーバーに転送される（転送時）。
サーバーが AES-256 暗号化されたストレージに暗号文を保存する（保存時）。
復号鍵は共有 URL フラグメントにのみ存在し、サーバーには送信されない。

3つの独立した層があります。1つが破られても残りが機能します。HexaTransfer・Tresorit Send・Proton Drive 共有リンク・SwissTransfer の E2EE モードが採用している設計です。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。