小村軟體有限公司
日本語 English 한국어 繁體中文 العربية
聯絡我們
選單

為什麼郵件安全裡 PPAP 行不通？正確的做法是什麼？

· · 郵件安全, PPAP, 資訊外洩對策, B2B, 既有資產活用

「用加密 ZIP 寄出，再用另一封郵件寄密碼的做法真的安全嗎？」 這個疑問到現在仍常被提出。表面上看起來有加密，似乎安全，但在實務中這正是陷阱所在。

先說結論：所謂的 PPAP，在 抵禦竊聽上並不夠強、對寄錯對象的防護也不足，更會 干擾郵件傳輸路徑上的檢查，在當今的郵件安全中是很難推薦的做法。1234

本文會依據至 2026 年 4 月時點可確認的公開資料與第一手資訊，整理 PPAP 的問題，以及在實務上該如何替換比較自然。12536748910

1. 先下結論

停用 PPAP，不是要停止「加密」這件事。 要停止的是 「把附件壓成有密碼的 ZIP，再用同一條郵件路徑之後補上密碼」 這種設計。

相對地，應該考慮的是下列 3 件事：

  1. 一般業務郵件，以 TLS / STARTTLS 這類傳輸通道保護為前提。710
  2. 若需要郵件本身的真實性或加密，採用 S/MIME 這類機制。536
  3. 機密檔案的交付，不走附件，而改為附帶驗證的下載或附有存取控制的共享。489

換句話說，重點是 不要試圖用 ZIP 密碼解決所有郵件上的安全問題。

2. PPAP 到底是什麼

本文所指的 PPAP，一般是下列流程：

  1. 把檔案壓縮成有密碼的 ZIP
  2. 第一封郵件送出 ZIP
  3. 第二封郵件送出密碼

這種做法常被理解成「沒有以明文傳送，所以安全」。 但實際上它真正能守住的範圍相當有限。

觀點 PPAP 是否足夠 實際評價
通訊路徑上的秘密性 弱 同一條郵件路徑分開送，效果有限
寄錯對象的防護 不足 一旦收件者寫錯就很容易直接釀成事故
惡意程式對策 反而不利 容易阻礙路徑上的檢查
寄件者真實性 無法保證 對冒名沒有防護
存取控制 無法保證 難以控制誰能看到

乍看萬用，但實際上 「看起來大概安全」，真正該守住的地方卻沒有守住，這就是 PPAP 的問題。

3. PPAP 為什麼行不通

3.1 抵禦竊聽不夠強

日本內閣府整理指出，透過與 ZIP 相同的路徑自動傳送密碼的做法並不妥當。1 重點是，不只是有沒有把檔案加密，連金鑰如何交付都要一起設計，不然意義會大打折扣。

因為在同一個郵件環境、同一個收件匣、同一位對象之後再送一次密碼，能看到 ZIP 的人與能看到密碼的人幾乎是同一群。 這樣只留下「有加密」這個事實，實質上的秘密性並不強。

3.2 對寄錯對象的防護不足

也有人把 PPAP 當成寄錯對象時的防護，但這一點同樣很弱。

IPA 公開的應用資訊技術者考試解答範例中指出，PPAP 的問題之一是：本文郵件一旦寄錯，解壓用密碼也會一併寄到同一個錯誤對象。3 日本數位廳的資料中也寫到：「用另一封郵件寄給對方時，還是寄給了同一個對象，所以作為控制措施並不成立」。4

也就是說，一旦把 ZIP 寄到錯誤對象之後習慣性地把密碼也一起寄出去，這場事故就直接成立了。 真正需要的，是可以對收件者確認、審批、寄前審閱、寄後可撤回或失效的交付方式。

3.3 阻礙惡意程式檢查

這一點在 PPAP 的問題中特別重要。

IPA 就 Emotet 攻擊中附帶加密 ZIP 的郵件提出警示：由於附件已加密，它很容易繞過郵件傳輸路徑上的安全產品檢查與隔離，直接抵達收件者手上。2

寄件方「自以為加密過就安全了」，但從收件端或中繼端來看，這就變成 難以檢查內容的附件。 從這個角度看，PPAP 也和現今的郵件防禦並不相容。

3.4 無法保證真實性與存取控制

PPAP 並不能證明寄件者是真正的本人。 而且，對於誰何時下載、事後能否撤銷、能否對不同對象設不同權限等，幾乎沒有存取控制能力。

另一方面，IPA 提供 S/MIME 這類電子簽章郵件的說明，從脈絡上也可以視為 PPAP 的替代方案。56 IPA 的 Web 安全資料中則整理到：處理非公開資訊的網站需要驗證與存取控制。8

把這兩件事放在一起看，答案相當清楚：

  • 想要郵件的真實性與防止竄改 → S/MIME
  • 想要檔案的存取權限與失效管理 → 附帶驗證的下載

ZIP 密碼另外寄送，對這兩個需求都沒有給出乾淨的回答。

4. 正確做法是「依目的分開」

「想要安全地寄出去」這個需求，實際上不是單一種類。 如果不分開看，就會全部想用 PPAP 一手包辦，設計反而會崩掉。

4.1 一般業務郵件

一般業務郵件，首先要以 TLS / STARTTLS 這類傳輸通道保護為前提。710 在此之上，如果還需要寄件者的真實性、防止竄改、郵件內文本身的加密，就合理考慮 S/MIME。536

4.2 機密檔案的交付

想只把檔案交給對方本人、想控制觀看權限、想事後撤銷。 這類需求更適合改用附帶驗證的下載或附有存取控制的共享，比附件更自然。489

例如下列需求，交由網站端管理比走附件更好處理：

  • 登入後才能下載
  • 可做成有期限的連結
  • 對不同對象分配不同權限
  • 需要時可留下紀錄

4.3 非得用附件不可的情況

有時對方狀況讓你只能走附件。 這時依內閣府的整理，至少底線是：檔案與密碼走完全不同的路徑傳遞。1

不過這只是暫行做法，不是最終型。 與其把它固定為每次的標準運用，不如把未來改走附驗證共享當作前提。

5. 中小企業的替換步驟

中小企業要停用 PPAP 時，比起一開始就導入複雜機制，先把分類劃清楚通常更有效。

5.1 先停下來的

  • 自動 ZIP 加密
  • 同一條郵件路徑下自動寄出密碼
  • 「重要檔案一律走 PPAP」的劃一規則

5.2 接著要決定的

  • 什麼可以用一般郵件寄
  • 什麼要禁用附件
  • 什麼要改走附帶驗證的下載
  • 例外情況下要走附件時的審批流程

5.3 最小組合的思路

一開始分成下面 2 條路線就已經夠用：

  1. 一般郵件
    • 業務聯絡
    • 視需要採用 S/MIME
  2. 機密檔案
    • 附帶驗證的下載
    • 權限設定
    • 有期限的共享

如果這邊模糊不清，現場最後還是會回到「先用 PPAP 頂著」。

6. 判斷流程

flowchart TD
    A[想交給對方什麼東西] --> B{是否為高機密檔案}
    B -- 否 --> C[一般業務郵件]
    C --> C1[以 TLS / STARTTLS 為前提寄出]
    C --> C2[若真實性或加密重要就採 S/MIME]

    B -- 是 --> D{對方能否登入接收}
    D -- 是 --> E[附帶驗證的下載 / 附存取控制的共享]
    E --> E1[視需要設定權限、期限、失效]

    D -- 否 --> F{是否真的非附件不可}
    F -- 是 --> G[加密檔案 + 另一條路徑的手動密碼]
    F -- 否 --> E

這張圖的重點是：不要把 PPAP 當作萬用的中間方案。 把郵件與檔案交付分開看，設計會更順。

7. 常見誤解

7.1 「ZIP 有加密所以就安全」

就算加密，金鑰交付方式弱就不夠。 而且有密碼的 ZIP 還可能阻礙路徑上的檢查。12

7.2 「分兩封郵件寄就夠了」

對同一位對象、沿著同一條郵件路徑補寄密碼，構不成強的控制。14

7.3 「停用 PPAP 就不能寄附件」

並非如此。 只要把一般郵件、S/MIME、附帶驗證的下載、特例時的另一條路徑密碼，分場景搭配使用即可。

7.4 「S/MIME 是大企業專用，實務上不可行」

雖然還得看對方那邊的支援狀況，但至少比 PPAP 更能回答「你到底想守住什麼」。 另外，對於不適合 S/MIME 的對象，還有附帶驗證的下載這條替代路徑。

8. 結語

PPAP 之所以行不通，關鍵在於「明明有加密」，所以很容易錯覺已經安全了。 但實際上仍有這些問題：

  • 同一條郵件路徑的分寄，秘密性弱
  • 對寄錯對象的防護不足
  • 有密碼的 ZIP 會阻礙路徑上的檢查
  • 無法保證寄件者的真實性或存取控制

1234

因此，該做的不是把 PPAP 風的運用稍微改一下來繼續苟延殘喘， 而是 把郵件當郵件守，把檔案交付當檔案交付來設計。

一句話整理：

停用 PPAP，不是停止加密，而是停止錯誤的控制，換成符合目的的控制。

相關文章

參考資料

  1. 日本內閣府, 平井內閣府特命擔當大臣記者會見要旨 令和 2 年 11 月 24 日 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. IPA, 諮詢暴增／使用加密 ZIP 的攻擊案例（2020 年 9 月 2 日） ↩ ↩2 ↩3 ↩4 ↩5

  3. IPA, 令和 5 年度 秋季 應用資訊技術者考試 解答範例 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. 日本數位廳, 面向數位改革的多利害關係人模型運用（處分通知等的數位化）・意見概要 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. IPA, 令和 5 年度 秋季 應用資訊技術者考試 評閱講評 ↩ ↩2 ↩3 ↩4

  6. IPA, 關於電子簽章 ↩ ↩2 ↩3 ↩4

  7. IPA, 中小企業的資訊安全對策指引 第 4.0 版 ↩ ↩2 ↩3

  8. IPA, 安全網站的製作方法 - 1.11 存取控制或授權控制的缺漏 ↩ ↩2 ↩3 ↩4

  9. NIST, Security Considerations for Exchanging Files Over the Internet ↩ ↩2 ↩3

  10. IPA, CPG（CISA Cross-Sector Cybersecurity Performance Goals）日文版 ↩ ↩2 ↩3

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

不被特定服務綁住的中小企業群發郵件設計方式

本文以中小企業為對象，整理在不導入專用 EDM 服務的前提下，如何用既有網域與官網建立小型派送平台：個別寄送、訂閱與抑制名單、自動退訂動線，以及 SPF／DKIM／DMARC 與 PTR、TLS 等寄件者認證的最低要求，幫助讀者在數十至數百封規模長期穩定不出事地持續發信。

閱讀文章

偽隨機數與真正隨機數的差異 - 如何區分的整理

本文整理偽隨機數與真正的隨機數差異，重點不在輸出外觀而在產生器結構：一般 PRNG 重視可重現性、CSPRNG / DRBG 主打不可預測性、NRBG 則以物理熵源為基礎。文中說明 seed 與 reseed、health test 的角色，並給出資安、模擬、抽籤等用途的選...

閱讀文章

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽