为什么邮件安全领域中PPAP不可行？正确做法是什么？

“把带密码的ZIP发出去，再用另一封邮件发送密码的做法，真的安全吗？” 这个疑问至今仍常被提出。表面上看起来已经加密，似乎安全，但在实务中，这恰恰是陷阱所在。

所谓PPAP，作为窃听对策较弱、作为误发对策也不充分，而且容易妨碍邮件路径上的检测，在当今的邮件安全实践中，是一种很难推荐的方式。¹²³⁴

本文将基于截至2026年4月能够确认的公开资料与一次信息，梳理PPAP的问题所在，以及在实务中该如何进行替换才更自然。^12536748910

1. 先说结论

停用PPAP，并不意味着停止”加密”这件事。 应该停止的，是“把附件压缩为带密码的ZIP，再通过同一条邮件路径事后发送密码”这种设计。

取而代之，应该考虑以下3点。

1. 普通业务邮件，以TLS / STARTTLS这类通信路径保护为前提。⁷¹⁰
2. 如果需要邮件本身的真实性或加密，则使用S/MIME这类机制。⁵³⁶
3. 机密文件的交付不走附件，而是改用带身份验证的下载或带访问控制的共享方式。⁴⁸⁹

归根结底，不要试图仅凭ZIP密码解决邮件上的所有安全问题，这一点很重要。

2. PPAP到底是什么

这里所说的PPAP，通常指以下流程。

1. 把文件压缩成带密码的ZIP
2. 用第一封邮件发送ZIP
3. 用第二封邮件发送密码

这种做法容易被理解为”没有以明文发送，所以安全”。 但实际上，它真正能守住的范围相当有限。

看似万能，但实际上“看起来大概安全”，却没能守住真正关键的部分，这正是PPAP的问题所在。

3. 为什么PPAP不可行

3.1 作为窃听对策较弱

日本内阁府整理指出，通过与ZIP相同的路径自动发送密码的方式并不妥当。¹ 关键在于，不仅要看是否对文件进行了加密，密钥如何传递也必须一并纳入设计，否则意义会大打折扣。

因为在同一个邮件环境、同一个收件箱、同一个对象之后再补发一次密码，能看到ZIP的人和能看到密码的人几乎是同一批人。 这样一来，只剩下”已加密”这一事实，实质上的保密性并不强。

3.2 作为误发对策不充分

也有人把PPAP当作误发对策来看待，但这一点同样很薄弱。

IPA公开的应用信息技术者考试解答示例中指出，PPAP的问题之一在于：一旦正文邮件被误发，解密用的密码也会一并送达同一个错误的对象。³ 日本数字厅的资料中也提到类似观点：”用另一封邮件发送给同一个对象，作为控制手段并不成立”。⁴

也就是说，只要把ZIP误发给错误对象后，习惯性地把密码也照样发出去，这场事故就已经成立。 真正需要的，是能够进行收件人确认、审批、发送前复核、发送后可撤回或失效的交付方式。

3.3 妨碍恶意软件检测

这是PPAP的问题中尤其不能忽视的一点。

IPA针对带有密码保护ZIP附件的Emotet攻击邮件发出警示：由于附件已被加密，很容易绕开邮件传输路径上安全产品的检测与隔离，从而以较高概率送达收件人手中。²

发信方或许”以为加密了就安全了”，但从收件方或中转方的角度来看，这反而变成了难以检测内容的附件。 从这个角度看，PPAP与当今的邮件防护体系并不兼容。

3.4 无法保证真实性和访问控制

PPAP并不能证明发信人的身份真实。 此外，谁在何时下载了文件、之后能否失效、能否按对象区分不同权限，这类访问控制几乎都无法实现。

另一方面，IPA也介绍了S/MIME这类带电子签名的邮件方式，在语境上可以视为PPAP的替代方案之一。⁵⁶ IPA的网站安全资料中还指出，处理非公开信息的网站需要具备身份验证和访问控制功能。⁸

把这两点结合起来看，答案已经相当清晰。

• 如果需要邮件的真实性和防篡改检测，应使用S/MIME
• 如果需要文件的查看权限和失效管理，应使用带身份验证的下载

而ZIP密码另行发送的方式，对这两个需求都没有给出清晰的回答。

4. 正确的做法是”按目的分开处理”

“想要安全地发送”这一需求，实际上并不是单一的一种。 如果不加以区分，试图用PPAP一并解决所有问题，设计就会崩溃。

4.1 普通业务邮件

对于普通业务邮件，首先应以TLS / STARTTLS这类通信路径保护为前提。⁷¹⁰ 在此基础上，如果还需要发信人的真实性、防篡改检测、邮件正文本身的加密，则应考虑使用S/MIME。⁵³⁶

4.2 机密文件的交付

如果只想把文件交给本人、想控制查看权限、想在事后失效，这类需求更适合采用带身份验证的下载或带访问控制的共享方式，而不是附件。⁴⁸⁹

例如以下这些需求，交由网站端管理会比走附件更容易处理。

• 登录后才能下载
• 可以设置为限时链接
• 可以按对象分配不同权限
• 需要时可以留存记录

4.3 无论如何都必须使用附件的情况

有时会因为对方的情况而不得不使用附件。 这种情况下，正如日本内阁府整理所指出的，最低限度的做法是让文件和密码通过完全不同的渠道传递。¹

不过，这只是权宜之计，而不是最终形态。 与其把它固定为每次的标准流程，更应把将来转向带身份验证的共享方式作为前提来考虑。

5. 中小企业的替换步骤

中小企业停用PPAP时，与一开始就引入庞大的机制相比，先把分类厘清楚往往更有效。

5.1 首先应该停止的事项

• 自动ZIP加密
• 通过同一条邮件路径自动发送密码
• “重要文件一律使用PPAP”的一刀切规则

5.2 接下来应该决定的事项

• 哪些内容可以用普通邮件发送
• 哪些内容应禁止作为附件
• 哪些内容应改为带身份验证的下载
• 例外情况下需要使用附件时的审批流程

5.3 最小组成的思路

一开始只需分成以下两条线，就已经足够。

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有时还会妨碍路径上的检测。¹²

7.2 “分两封邮件发送就够了”

对同一个对象、通过同一条邮件路径事后补发，构不成强有力的控制手段。¹⁴

7.3 “停用PPAP就意味着不能发附件了”

并非如此。 只需要把普通邮件、S/MIME、带身份验证的下载，以及例外情况下走另一渠道传递密码这几种方式区分使用即可。

7.4 “S/MIME只适合大企业，实务上不现实”

虽然要视对方的支持情况而定，但至少比PPAP更能清晰地回答”到底想守住什么”这个问题。 此外，对于不适合使用S/MIME的对象，还有带身份验证的下载这条替代路径。

8. 总结

PPAP之所以不可行，在于它明明已经加密，却容易让人产生”已经安全”的错觉。 实际上，仍然存在以下问题。

• 通过同一条邮件路径分开发送，保密性较弱
• 作为误发对策并不充分
• 带密码的ZIP会妨碍路径上的检测
• 无法保证发信人的真实性和访问控制

¹²³⁴

因此，真正该做的不是把PPAP式的运用稍加改动继续延续下去， 而是把邮件当作邮件来守护，把文件交付当作文件交付来设计。

一句话概括：

停用PPAP，不是停止加密，而是停止错误的控制方式，换成符合目的的正确控制方式。

相关文章

• 不依赖特定服务的中小企业群发邮件设计方法
• 文章与服务页面该如何衔接 - 内部链接设计的基本原则
• 服务页面该如何搭建 - 面向技术型、B2B业务的整理步骤

参考资料

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

PPAP是什么？

指把文件压缩成带密码的ZIP，用第一封邮件发送ZIP、再用第二封邮件发送密码的做法。由于没有以明文发送，看起来似乎安全，但实际上能守住的范围相当有限。通信路径上的保密性较弱，作为误发对策也不充分，同时也无法保证发信人的真实性和访问控制。

为什么PPAP存在风险？

主要问题有4个。第一，即使用另一封邮件单独发送密码，由于走的是同一条邮件路径，能看到ZIP的人和能看到密码的人几乎是同一批人，作为窃听对策很薄弱。第二，一旦发错收件人，解密用的密码也会送达同一个错误对象，作为误发对策并不充分。第三，带密码的ZIP由于已被加密，很容易绕开邮件传输路径上安全产品的检测与隔离，实际上已被用于Emotet之类的攻击邮件中。第四，PPAP无法保证发信人的真实性，也无法实现访问控制。

停用PPAP之后应该用什么替代？

基本思路是按目的分成3类。普通业务邮件以TLS / STARTTLS这类通信路径保护为前提，如果需要邮件本身的真实性或加密，则使用S/MIME。机密文件的交付不走附件，而是改用带身份验证的下载或带访问控制的共享方式，这样可以处理权限设置、限时链接、失效管理等需求。重要的是不要试图仅凭ZIP密码解决邮件安全的所有问题。

如果无论如何都必须用附件发送该怎么办？

如果因对方的情况而不得不使用附件，最低限度的做法是让加密文件和密码通过完全不同的渠道传递。不过，这只是权宜之计而非完成形态。不应把它固定为每次的标准流程，更安全的思路是将来逐步转向带身份验证的共享方式。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。