把未加密檔案直接丟進雲端硬碟，服務商、同步用戶端和秒傳還可能看到什麼

拖進雲端硬碟不是「鎖進保險箱」，是把明文交給下一個系統

很多人把消費級雲端硬碟當成家裡的保險箱：檔案還在自己的帳號裡，別人打不開。拖進去之後，這份位元組已經離開目前磁碟上的那一個資料夾，成為服務商要儲存、同步、去重和（經常）產生預覽的物件。財務報表、身分證掃描檔、SSH 私鑰、資料庫傾印、未遮罩的客戶名單，都屬於不該以明文落入第三方儲存和檢索系統的內容。

HTTPS 只保護傳輸過程中的竊聽。它不決定對方系統把檔案存成什麼形態、鑰匙在誰手裡、同步用戶端在本機快取什麼、分享連結點開後對方拿到的是密文還是解開的原文。上一篇寫過：金鑰貼進模型對話會進紀錄和留存。檔案丟進雲端硬碟是同一類暴露，只是接收方從「模型服務商」換成了「儲存服務商及其同步、預覽和去重通道」。上傳前要處理的，不是「這家雲端聰不聰明」，而是「這一份裡有沒有不該以明文離開目前裝置的內容」。

本文以 AWS S3、Google 雲端硬碟 / Google Cloud 和 iCloud 的公開說明為主，因為分層寫得清楚，也好核對。台灣日常更常碰到的是 Google 備份與同步、iCloud 雲碟、Dropbox 或 OneDrive；消費級產品很少把「鑰匙在誰手裡」寫成同樣直白的句子，但工程模型通常仍是：傳輸用 TLS，落盤用服務商保管鑰匙的靜態加密，再疊加縮圖、全文檢索或秒傳（用內容雜湊比對、已有相同檔就不重傳）。換產品時應對著那一家的安全頁再走一遍，不要把下面的 SSE-S3 或「標準資料保護」直接套到別的品牌上。

HTTPS、靜態加密、零知識：三把鎖不是同一把

把「雲端硬碟有沒有加密」聽成一個是或否，會漏掉至少三層。第一層是傳輸加密。瀏覽器或同步用戶端用 TLS 把位元組送到伺服器，中間網路上看不到明文。這一層幾乎是標配，也是網址列小鎖真正保證的範圍。

第二層是靜態加密，也就是伺服器端加密。AWS 對 S3 伺服器端加密 的定義很直白：資料在目的地由接收它的服務加密；寫入資料中心磁碟時加密，你存取時再解密。自 2023 年 1 月 5 日起，所有新上傳物件預設使用 SSE-S3（Amazon S3 代管金鑰），演算法是 AES-256，每個物件一把獨立金鑰，根金鑰由 AWS 輪替。只要請求通過身分驗證且有權限，「存取加密物件和未加密物件沒有差別」。預先簽署網址對兩者同樣有效。列出物件時，介面也不區分加沒加密。換句話說：這層保護的是磁碟被偷走之後的實體儲存媒體，不是「AWS 解不開你的檔案」。

Google 對雲端硬碟的公開口徑類似：上傳或在文件 / 試算表 / 簡報裡建立的檔案，「傳輸中和靜態都用 AES-256 加密」。額外的保密要靠 Workspace 用戶端加密，而且必須是公司或學校帳號、由管理員開啟。開啟之後，Google 才寫成「無法解密你的檔案」。預設那一層並沒有這句話。Google Cloud 預設靜態加密 更直接：鑰匙由 Google 擁有並管理；你若只用預設加密，接觸不到這些鑰匙，也無法控制輪替。

Apple 把預設和可選拆開寫。iCloud 資料安全性概覽 寫明：標準資料保護是帳號預設設定；資料會加密，鑰匙放在 Apple 資料中心，以便幫你還原；只有部分類別預設端對端加密。安全指南給出數量：預設約 14 個類別端對端加密；開啟可選的進階資料保護後升到約 23 個，包括 iCloud 備份、照片和備忘錄。關掉進階資料保護時，裝置會把所需鑰匙重新上傳到 Apple 伺服器。預設並不是「Apple 也解不開雲碟裡的檔案」。

服務商握著鑰匙時，還能為你做什麼、對誰可見

服務商能解密，並不是一句恐嚇，而是預設產品功能成立的前提。線上預覽 PDF、給照片出縮圖、對文件做 OCR 或全文搜尋、按檔案類型歸類，都要在某台伺服器上看到內容，或至少看到從內容派生出來的明文索引。Google 自己把用戶端加密的代價寫進了說明頁：加密後的文件 / 試算表 / 簡報不能用行動應用程式編輯，不能對雲端硬碟檔案留言，沒有語音輸入和若干附加功能；加密文件上限 100 MB，版本紀錄最多保留 100 個版本。這些限制出現的原因很具體：伺服器端不再拿得到能解出原文的鑰匙。

AWS 把另一面寫得同樣清楚：你用預先簽署網址分享物件時，對方拿到的存取方式和未加密物件相同。SSE-S3 不會把「點開連結的人」擋在明文之外。它擋的是「誰拿走了硬碟」。帳號被盜、分享連結外洩、企業管理員調取、執法調取，走的都是「有權限的存取」這條路，靜態加密預設放行。

消費級雲端硬碟還多一層：同步用戶端。檔案先出現在本機同步資料夾，再上傳。即便雲端後來寫了靜態加密，這台電腦、家裡另一台已登入的電腦、手機裡的離線快取，仍然可能各留一份明文。關掉瀏覽器分頁，清不掉已經寫入同步資料夾的副本。

同步、預覽、秒傳和分享連結是另外幾份副本

把「上傳成功」聽成「只有雲端一份」，會漏掉本機和雲端兩側的副本。第一份是同步用戶端的工作副本：待上傳佇列、失敗重試快取、版本衝突留下的副本。第二份是伺服器端為預覽準備的衍生檔：縮圖、轉碼後的影片、OCR 文字。它們往往和原檔分開存，刪掉原檔不一定立刻帶走衍生檔。

第三份是內容雜湊。不少雲端硬碟用整檔或分塊雜湊做秒傳和去重：本機先算出雜湊，伺服器端若已有相同雜湊就不再傳一遍位元組。這對未加密檔案很方便，也等於公開承認「同一份明文在系統裡只存一份」。你上傳一份未加密的常用安裝套件或公開 PDF，伺服器端用雜湊就能確認你持有它；公司內部的同一份合約被多人上傳，去重後仍是同一份明文。先在本機加密再上傳，每次都會因獨立的 salt 和 IV 得到不同密文，雜湊對不上，秒傳失效。這不是故障，而是「服務商看不到內容」的直接後果。

第四份是分享連結和團隊空間。連結一旦發出，權限模型通常是「誰持有連結誰就能取回檔案」。結合上一節：預設靜態加密不會在下載時改成「只給密文」。對方瀏覽器裡開啟的，仍是解開後的原文。LINE 群裡的「雲端連結」和把檔案本體貼進群，暴露面不同，明文是否離開你的帳號，答案經常一樣。

壓縮檔加密碼為什麼常常不夠

「先打成 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 無法解密」。那是工作區管理員開啟的附加層，不是個人免費雲端硬碟的預設值。自己先加密再上傳，走的是同一條邊界，只是鑰匙完全留在你自己的密碼和裝置上，不依賴某一家雲端有沒有用戶端加密開關。

瀏覽器裡可以核對的做法，是用 Web Crypto 的 AES-GCM，而不是自己拼一套 XOR。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 的井號後面為什麼適合放金鑰，以及什麼時候會失效，以及閱後即焚連結讀完一次後，伺服器還剩什麼。本文只把「未加密檔案進了雲端硬碟之後還可能剩什麼」收成可以寫進結論的範圍。