暗号化せずクラウドへ上げたファイルを、事業者・同期クライアント・内容ハッシュはまだ何を見られるか

ドライブへ落とすことは、金庫に入れることではなく、次の系へ平文を渡すこと

消費向けクラウドストレージは、家の中の金庫に見えやすいです。ファイルは自分のアカウントに残っているので、他人は開けない、と思いがちです。ドラッグしたあと、そのバイトは今のディスク上のフォルダを離れています。事業者が保存し、同期し、重複排除し、しばしばプレビュー用に索引するオブジェクトになります。確定申告、身分証のスキャン、SSH 秘密鍵、データベースのダンプ、伏せていない顧客表は、いずれも第三者の保管と検索の系へ、平文のまま入れてよい内容ではありません。

HTTPS が守るのは、経路上の盗聴だけです。相手の系がファイルをどの形で置くか、鍵を誰が持つか、同期クライアントがこの端末に何をキャッシュするか、共有リンクを開いた相手が暗号文を取るか解いた原文を取るかは、決めません。前のノートは近い受け渡しを書いています。モデルの会話へ貼った鍵は、履歴と保持へ入ります。暗号化せずクラウドへ上げたファイルは、同じ種類の露出です。受け手がモデル事業者から、ストレージ事業者とその同期、プレビュー、重複排除の通路へ変わるだけです。上げる前に問うのは『このドライブは賢いか』ではありません。『この複製に、平文のままこの端末を出してはいけないものが入っているか』です。

本稿は AWS S3、Google ドライブ / Google Cloud、iCloud に留めます。層を公開文で確かめられるからです。消費向けストレージが『誰が鍵を持つか』を同じ一文で書くことは少ないです。工学モデルはたいてい同じです。線上は TLS、保存時は事業者が鍵を持つ暗号化、その上にサムネイル、全文検索、同一ファイルの再送省略が乗ります。製品を変えたら、その社のセキュリティページをやり直してください。SSE-S3 や『標準データ保護』を、別ブランドへ貼り付けないでください。

HTTPS、保存時暗号化、ゼロ知識は、三つの別の錠

『クラウドは暗号化されているか』を Yes / No で聞くと、少なくとも三層が落ちます。第一は転送中の暗号化です。ブラウザや同期クライアントは TLS でバイトを送ります。途中の網は平文を見ません。この層はほぼ常に入り、アドレスバーの錠が実際に約束する範囲もここだけです。

第二は保存時暗号化、つまりサーバー側暗号化です。AWS の S3 サーバー側暗号化 の定義は率直です。データは受け取った先のサービスが、到着地点で暗号化します。S3 は AWS データセンターのディスクへ書くときに暗号化し、アクセス時に復号します。2023年1月5日以降、新規アップロードは既定で SSE-S3（Amazon S3 管理鍵）です。アルゴリズムは AES-256、オブジェクトごとに独立した鍵、ルート鍵は AWS がローテーションします。認証済みで権限のある要求なら、『暗号化オブジェクトと未暗号化オブジェクトのアクセス方法に差はない』と書いてあります。署名付き URL も両方に同じように効きます。一覧も、暗号化の有無を分けません。つまりこの層が守るのは、盗まれたディスクです。『AWS がファイルを開けない』ではありません。

Google ドライブの公開文も近いです。アップロードしたファイル、Docs / Sheets / Slides で作ったファイルは、『転送中も保存時も AES-256 で暗号化する』とあります。追加の秘匿は Workspace の クライアントサイド暗号化 が要り、仕事用または学校用アカウントで、管理者がオンにしたときだけです。そのスイッチのあと、Google は初めて『Google はファイルを復号できない』と書きます。既定の層にはその文はありません。Google Cloud の既定の保存時暗号化 はさらに直接です。既定暗号化で使う鍵は Google が所有し、管理します。既定のままでは、それらの鍵をあなたは持てず、ローテーションも制御できません。

Apple は既定と任意を分けて書いています。iCloud データのセキュリティ概要（2026年1月5日公開）は、標準データ保護がアカウントの既定だと述べます。データは暗号化され、鍵は Apple のデータセンターにあり、復旧を助けるためです。既定でエンドツーエンドになるのは一部の種類だけです。常時エンドツーエンドは 15 種類で、ヘルスケアと iCloud キーチェーンを含みます。任意の高度なデータ保護を入れると 25 種類へ増え、iCloud バックアップ、写真、メモ、iCloud ドライブが加わります。高度なデータ保護を切ると、端末は『必要な暗号鍵を Apple のサーバーへ安全にアップロード』します。既定は『Apple も iCloud ドライブのファイルを開けない』ではありません。

事業者が鍵を持っているとき、まだ何ができ、誰に見えるか

事業者が復号できることは、脅しではありません。既定の製品機能が立つ前提です。PDF のオンラインプレビュー、写真のサムネイル、OCR、全文検索、『種類で並べる』は、どこかのサーバーが内容を見るか、少なくとも内容から作った平文索引を見る必要があります。Google はクライアントサイド暗号化の代償を、同じヘルプに書いています。暗号化した Docs / Sheets / Slides はモバイルアプリで編集できず、ドライブのコメントも使えず、音声入力といくつかのアドオンが落ちます。暗号化ドキュメントは 100 MB まで、版履歴は最大 100 版です。制限が出る理由は具体的です。サーバーが、原文を開ける鍵を持たなくなるからです。

AWS は反対側も同じだけはっきり書いています。署名付き URL でオブジェクトを共有すると、相手のアクセスは未暗号化オブジェクトと同じです。SSE-S3 は『リンクを開いた人』を『暗号文だけ』には変えません。止めるのは『ディスクを持って出た人』です。盗まれたアカウント、漏れた共有リンク、企業管理者の取り出し、法令に基づく請求は、いずれも『権限のあるアクセス』の道を通ります。既定の保存時暗号化は、その道を通します。

消費向けストレージには、もう一層あります。同期クライアントです。ファイルは先に端末の同期フォルダへ現れ、それから上がります。クラウドが後から保存時暗号化を書いても、このパソコン、家の別のログイン済みパソコン、スマホのオフラインキャッシュは、それぞれ平文の複製を持てます。ブラウザのタブを閉じても、すでに同期フォルダへ書いた複製は消えません。

同期キャッシュ、プレビュー、内容ハッシュ、共有リンクは、別の複製

『アップロード完了』を『クラウドに一通だけ』と聞くと、端末側とクラウド側の複製が落ちます。第一は同期クライアントの作業複製です。送信待ち、再試行キャッシュ、版の衝突で残った副本です。第二は、サーバーがプレビュー用に作る派生ファイルです。サムネイル、変換した動画、OCR テキストです。元ファイルとは別に置くことが多く、元を消しても派生が同時に消えるとは限りません。

第三は内容ハッシュです。多くのストレージはファイル全体、または塊ごとにハッシュを取り、同一ファイルの再送省略と重複排除に使います。クライアントが先にハッシュを送り、サーバーがすでに持っていれば、バイトはもう一度渡りません。暗号化していないファイルには便利です。同時に、『同じ平文は系の中に一通だけ置かれる』と認めることでもあります。暗号化していないインストーラや公開 PDF を上げると、サーバーはハッシュだけで、あなたがそれを持っていると確認できます。社内の同じ契約を複数の机から上げても、重複排除のあとは同じ平文オブジェクトです。この端末で先に暗号化すると、毎回別の salt と IV を使うので暗号文のハッシュは合わず、再送省略は外れます。故障ではありません。『事業者が中身を見られない』ことの直接の結果です。

Apple は高度なデータ保護の下でも、この種の指紋を公開しています。同じ iCloud 概要は、一部のメタデータが標準データ保護のままだと書いています。『ファイルと写真データのチェックサムは、iCloud とデバイスのストレージを重複排除し、最適化するために使う』。iCloud ドライブでは、『ファイル内容の生バイトのチェックサムとファイル名』を含みます。本体のエンドツーエンド暗号化は、『Apple がバイトの指紋を決して見ない』ことではありません。どの社の『すでにクラウドにある』表示も同じです。ハッシュの一致は、アカウントだけでなく、内容についての陳述です。

第四は共有リンクとチーム領域です。リンクが出たあと、権限モデルはたいてい『リンクを持つ人がファイルを取れる』です。前節と合わせると、既定の保存時暗号化はダウンロードを『暗号文だけ』には書き換えません。相手のブラウザで開くのは、解いた原文です。チャットの『ドライブのリンク』と、ファイル本体を添付することは、面は違います。平文があなたのアカウントを出たかは、答えが同じことが多いです。

パスワード付きZIPが、クライアントサイド暗号化にならないことが多い理由

日本の事務では、『ZIP にパスワードを掛け、次のメールでパスワードを送る』が長く使われてきました。クラウドへ上げる前の一手としても、同じ習慣が残りやすいです。ただし、使っている ZIP 暗号化がどれかを先に聞いてください。従来の PKWARE 暗号化（ZipCrypto）はストリーム暗号です。1994年、Eli Biham と Paul Kocher は A Known Plaintext Attack on the PKZIP Stream Cipher で、この暗号は弱く、価値のあるデータを守るべきではないと書きました。圧縮済み既知平文がおよそ 13 から 40 バイト、または未圧縮なら先頭およそ 30 から 200 バイトで、当時のパソコンでも数時間以内に内部鍵表現を戻せました。いまの実装はさらに低いです。bkcrack は、既知平文が少なくとも 12 バイト（うち少なくとも 8 バイト連続）あれば内部状態を復元し、同じパスワードで暗号化した他の項目まで開けると書いています。パスワードの長さは、この攻撃では助けになりません。狙うのは鍵ストリームの状態であり、パスフレーズの総当たりではありません。

圧縮ツールが AES に切り替えても、ZIP はファイル名、ディレクトリ構造、暗号化していない項目コメントを、アーカイブ先頭に平文で残すことがあります。ストレージのファイル一覧、検索、『種類』フィルタが読むのは、そのメタデータです。『アーカイブにパスワードがある』を『クラウドは乱数だけを見る』と読むと、ヘッダと弱い算法の二層が落ちます。

運用でより多い取り違えは、暗号化した圧縮と、パスワードを書いた readme.txt を同じフォルダへ置き、一緒に同期することです。錠と鍵が同じ保管者へ渡ります。保存時暗号化も ZIP パスワードも、この場合は救えません。パスワードを次のメールで送る習慣も、両方を同じドライブへ置いた瞬間に崩れます。

この端末で先に暗号化すると、変わる層

クライアントサイド暗号化の検査は狭いです。平文が端末を出る前に暗号文になること。鍵を導くパスフレーズをストレージ事業者へ送らないこと。通常運用で事業者が開けないこと。Google は Workspace のクライアントサイド暗号化を『エンドツーエンドで、クライアント間』と書き、『Google はファイルを復号できない』と名指しします。管理者が入れる追加の層です。個人向け無料ドライブの既定ではありません。自分で暗号化してから上げることは、同じ境界を歩きます。鍵はパスフレーズと端末に残り、特定のドライブがクライアントサイド暗号化のスイッチを持つかに依存しません。

ブラウザで確かめられる経路は、自作の XOR ではなく Web Crypto の AES-GCM です。MDN の AesGcmParams は NIST SP 800-38D と揃っています。一つの鍵の下では、IV は毎回一意でなければなりません。仕様が勧める IV は 96 ビット（12 バイト）です。IV は秘匿不要で、暗号文の隣に平文で置けます。NIST は一意性を重く書いています。同じ鍵で IV を再利用すると偽造が許され、その要件は鍵そのものを秘匿することにほぼ等しいです。認証タグの既定は 128 ビット（16 バイト）です。誤ったパスフレーズや改ざんされた暗号文は、欠けた平文を吐かず、失敗で閉じるべきです。

MakePwd のファイル暗号化は、この境界で実装しています。今のタブで AES-256-GCM を塊ごとにかけ、パスフレーズは PBKDF2-HMAC-SHA256、100,000 回で伸ばします。ファイルごとに独立した 16 バイト salt、塊ごとに独立した 12 バイト IV、出力は IV + 暗号文 + 16 バイトタグ です。単一ファイルは 5 GB まで。既定の塊は 1 MB で、ファイル全体を一度にメモリへ読みません。出力は .lock または .enc で、バイナリ形式は同じです。ファイルとパスフレーズはアップロードしません。どのツールも開いてすぐ使え、アカウントはなく、パスフレーズを預かるパスワード保管庫もありません。答えるのは『ブラウザを出る前に暗号文へ変えられるか』であり、『特定のクラウドへ代行で上げる』ではありません。

その場で確かめる：カナリア平文は送信待ちに入らず、Network には暗号文だけ

『アップロードしない』という標語は、それ自体では証明になりません。検査は二段に分けます。先に、暗号化そのものが平文を業務データとして出していないかを確認します。次に、ストレージへ渡すオブジェクトが暗号文かを確認します。

1. 本物の業務には出ない一文を書いたテキストを作ります。例は canary-cloud-20260902-only-once です。ファイル名にもカナリアを入れて構いません。パスフレーズは一度きりの長い文にし、使い回しのパスワードは使わないでください。
2. ブラウザでファイル暗号化を開き、開発者ツールを出して Network に切り替え、Preserve log を入れます。ファイルを選び、パスフレーズを入れ、.lock をダウンロードします。フィルタにカナリアを貼ります。リクエスト行、本文、分析送信に原文は出てはいけません。パスフレーズも出てはいけません。
3. ダウンロードした .lock を十六進ビューアかエディタで開きます。先頭は固定のマジックナンバーであり、さっきのカナリア文ではありません。誤ったパスフレーズは失敗し、欠けた平文ファイルを書いてはいけません。
4. 暗号文を自分のストレージへ退避するなら、上げるのは .lock であり、元ファイルではありません。上げ終わったらプレビューを探してください。読める本文は出てはいけません。パスフレーズを同じ同期フォルダへ置かないでください。

前半、リクエスト行、本文、分析送信は、ブラウザで暗号化するなら、平文が端末を出ていないことをその場で確かめる と同じ検査です。本稿が足すのは第四歩です。オブジェクトがブラウザを出たあと、層は『端末の Web Crypto』から『ストレージがこれを平文として扱うか』へ移ります。カナリアは、自分で残した元ファイルにだけあるべきです。プレビューや『すでにクラウドにある』表示に出たら、まだ暗号化していない複製を上げています。

開いてすぐ使えるファイル暗号化で、境界を馴染ませる

欲しいのが『先に暗号文へ変え、行き先は自分で決める』なら、登録は不要です。ファイルを MakePwd へ渡す必要もありません。ファイル暗号化 を開き、捨てられる小さなファイルを選び、長いランダムなパスフレーズで暗号化し、.lock をダウンロードし、上のとおり Network を探してください。人が覚えたり受け取ったりするパスフレーズが要るときは、パスワードジェネレーター で 6–128 文字のランダム列を引き（既定は 16。8 未満は弱いと出ます）、暗号文と同じドライブフォルダへ置かず、ワンタイムリンク で一度送ることを検討してください。ワンタイムリンクの鍵は URL の # フラグメントにあります。閲覧ページは受け手に公開です。

ファイル暗号化は、各ドライブが持つクライアントサイド暗号化のスイッチの代わりにはなりません。暗号文を相手の製品がマルウェア検査するか、ファイル名を見るかも約束しません。.lock の先頭には元のファイル名が残るので、ストレージ側は名前を見られることがあります。名前そのものを隠したいなら、暗号化する前に意味のない名前へ変えてください。忘れたパスフレーズは暗号文から戻せません。自分の管理下に別に書いてください。

よくある質問

ストレージが『暗号化済み』と書いていても、事業者はファイルを開けますか？

既定の保存時暗号化では、たいてい開けます。AWS は、サーバー側暗号化はディスクへ書くときに暗号化し、アクセス時に復号すると書いています。権限のある要求では、暗号化オブジェクトと未暗号化オブジェクトの扱いに差はありません。Google の既定暗号化は鍵を自社で保管します。Apple の標準データ保護は、復旧できるように大半の鍵を自社データセンターに置きます。『事業者が解けない』とは別の層です。

パスワード付きZIPにしてから上げれば足りますか？

従来の ZipCrypto では足りません。1994年、Biham と Kocher は、十数バイト程度の既知平文で内部鍵状態を復元できると示しました。パスワードの長さは助けになりません。AES の圧縮でも、ファイル名などのメタデータは平文のまま残ることがあります。ストレージ側に暗号文だけを見せたいなら、この端末で認証付き暗号化を終えてから上げてください。

先に暗号化すると、重複排除とオンラインプレビューは使えますか？

原文に対しては、たいてい使えません。重複排除は内容ハッシュを比べます。同じ平文でも、毎回別の salt と IV で暗号化するとハッシュは変わります。プレビュー、サムネイル、OCR は原文が要ります。これは想定どおりの代償です。事業者が中身を見られなければ、プレビューも作れません。

パスフレーズを .lock と同じクラウドフォルダに置いてよいですか？

置かないでください。暗号文とパスフレーズを同じアカウント、同じ同期フォルダに置くと、錠と鍵を同じ保管者へ渡すことになります。パスフレーズはパスワードマネージャーへ、またはワンタイムリンクで一度だけ送ってください。忘れたパスフレーズは .lock から戻せません。ゼロ知識バックアップの境界であり、欠陥ではありません。

次に上げる前に、覚えておく三つのこと

第一に、アドレスバーの錠と『暗号化済み』が覆うのは経路と盗まれたディスクです。事業者、管理者、共有リンクを持つ人は覆いません。第二に、同期キャッシュ、プレビューの派生、内容ハッシュ、共有リンクは、それぞれ複製を持てます。暗号化せず上げると、平文がこれらの通路へ入ります。第三に、ストレージ側に不透明なバイトだけを見せたいなら、この端末で AES-256-GCM の .lock / .enc にし、パスフレーズは別経路で送り、Network とプレビューでカナリアを探してください。

暗号化の過程が平文を業務データとして出していないかを続けるなら、ブラウザで暗号化するなら、平文が端末を出ていないことをその場で確かめる を読んでください。暗号文を開けるパスフレーズを人へ渡す必要があるときは、URLのハッシュ記号の後ろに鍵を置ける理由と、その保護が効かなくなるとき と、ワンタイムリンクを一度開いたあと、サーバーに残るのは何か を読んでください。本稿が扱うのは、『暗号化せずクラウドへ入ったファイルのあと、まだ何が残るか』を、結論に書ける範囲へ落とすことだけです。