概略
大泰司 章氏が提唱した PPAPという問題提起からおよそ5年の月日が流れました。官公庁や一般企業にも脱PPAPの流れは強く影響を与え、現在ではPPAP以外の方法でのファイル共有がなされることも増えてきたと思います。
また、10月16日はインターネットの発展に多大な功績を残したジョナサン・ポステル(Jon Postel)氏の命日でした。氏は多くのインターネット標準として RFCの作成に貢献した人物であり、その中には電子メールの基盤となるSMTP(RFC821)やインターネットのメッセージ形式を定めたRFC822が含まれます。この機会に、改めて電子メールにおける安全なデータ送受信について考えてみたいと思います。
本稿に記載した内容は、個人的な見解を示したものであり、筆者の所属する企業・団体の公式見解ではありません。
PPAPとは
PPAPとは、Password付きZipファイルをメールで送信し、その後に別メールでPasswordを送信する運用方法を指します。一見すると「暗号化した安全な送付方法」に思われがちですが、実際には問題があります。
問題点1: 盗聴リスク
PPAPの最大の問題点は、暗号化ファイルとパスワードが同一の経路で配送されることによって、実質的な秘匿性が確保できないという点にあります。
たとえ添付ファイルをZipで暗号化したとしても、数分後に同じメール経路を通じてパスワードを送信すれば、攻撃者は両方を入手できる可能性があります。仮に通信経路がTLSで暗号化されていても、受信者のメールボックスが侵害された場合には暗号化ファイルとパスワードの両方が同時に流出する危険が残ります。さらに、誤送信や自動転送などがあれば、パスワードと暗号化ファイルがセットで第三者に届いてしまい、いかなる意味でも暗号化の効力が失われることになります。このように、時間差や「別メールで送る」という工夫は、根本的なリスク低減にはつながりません。
問題点2: パスワード管理の手間
PPAPは人手によるオペレーションに大きく依存しているため、実務上の負担が大きい点も深刻です。
送信者はファイルごとにパスワードを生成し、それを誤りなく伝達し、受信者は入力して展開する必要があります。現場では入力ミスや展開・復号環境の違いによるトラブルが頻発し、再送や問い合わせの手間が重なります。さらに、業務効率を優先するあまり、毎回同じパスワードを使い回したり、パスワードを台帳にまとめて共有したりするなど、本来のセキュリティ強化を目的とした仕組みが、逆に弱点を増やす方向へと傾きやすくなります。結果的に、パスワード管理の負担が大きくなるほど、組織は危険な近道に頼り、形骸化したセキュリティ対策に陥ってしまうのです。
問題点3: マルウェア検知の阻害
さらに重大なのは、パスワード付きZipファイルがセキュリティゲートウェイでの検査を回避してしまう点です。
通常、メールゲートウェイやサンドボックスは添付ファイルを展開し、ウイルススキャンやマルウェア解析を行います。しかし、暗号化された添付ファイルはその中身を確認できず、結果として検査が素通りされてしまいます。そのため、攻撃者にとってはマルウェアを確実に届けるための有効な手段となり得ます。また、受信側だけでなく送信側においても同じことが起きます。組織外に機微情報が持ち出されても、パスワード付きZipであれば情報漏えい検知システム(DLP)が働かず、気づかれないまま送信されてしまう可能性があります。
このように、PPAPは安全対策どころか、むしろ既存のセキュリティ技術を無力化し、攻撃や情報漏えいの温床を作り出してしまう仕組みとなっているのです。
これらの背景から、情報漏えいやマルウェア感染の危険を高める「形骸化したセキュリティ対策」として、官民で廃止の方向が強まっています。
電子メール暗号化の歴史と方式の発展
電子メールは誕生以来、その利便性から世界的に普及してきました。しかし同時に、盗聴や改ざんといったリスクに常にさらされてきた技術でもあります。初期のSMTP(Simple Mail Transfer Protocol)は暗号化を考慮しておらず、平文での通信が標準でした。そのため、機密情報を安全にやり取りするためには、メッセージそのものを暗号化する仕組みが求められるようになりました。
脱PPAPを考えるうえで、その歴史を紐解くことはとても重要です。
PGPの登場と輸出規制
1991年に登場した「PGP(Pretty Good Privacy)」は、フィリップ・ジマーマン(Phil Zimmermann)氏によって開発されました。PGPは公開鍵暗号方式を用いた、個人でも利用できる実用的な暗号化ツールとして広まりました。テキストデータを送信する電子メールにおいてもPGPの仕組みは応用が効くため、活用されました。しかし当時の米国では暗号技術が軍需品に準じて扱われ、強力な暗号の国外輸出は「武器輸出」と同等に規制されていました。そのため、PGPを自由に国外に広めることは法的に制限されていたのです。
ジマーマン氏はこの規制を回避するため、PGPのソースコードを書籍という形で出版しました1。書籍は米国憲法修正第1条による「言論の自由」の保護を受けるため、結果的にソースコードは海外でも合法的に入手可能となり、これを基に国際版PGPが作られ世界へと広がっていきました。この出来事は、暗号技術の普及と規制のあり方を巡る重要な論点を世に問うこととなり、「暗号は兵器か、それとも言論か」という議論を呼び起こしました。
電子メールへのPGP活用
当初のPGPは、電子メールに暗号化したテキストをそのまま貼り付ける形で利用されていました。暗号化・署名もプレーンテキストを対象とした単純な方式で、メールソフトとの統合度は低かったといえます。しかし、インターネット標準として普及していたMIME(Multipurpose Internet Mail Extensions)形式に対応するため、PGP/MIMEと呼ばれる方式が開発されました。これにより、本文や添付ファイルを含む複雑なメール構造全体を暗号化・署名できるようになり、実用性は大きく向上しました。
こうした流れを受け、IETFにおいてPGPの標準化作業が進められ、「OpenPGP(RFC3156)」として仕様がまとめられることになりました。OpenPGPはベンダーやソフトウェアに依存せず、相互運用可能な暗号化基盤として整備された点で大きな意義がありました。米国の規制も緩和されRFC9580ではより強固なアルゴリズムが定められています。
その後、PGP社の買収や製品化の流れの中で、商用版PGPは企業向けソフトウェアとして提供される一方、オープンソース実装であるGNU Privacy Guard(GnuPG、通称GPG)が登場しました。GPGはLinuxをはじめとするオープンソース環境で広く普及しました。
S/MIMEの策定と標準化の流れ
PGPと並んで電子メールの暗号化を支えてきたのが「S/MIME(Secure/Multipurpose Internet Mail Extensions)」です。S/MIMEは1995年にRSA Data Security社のローレンス・ロー(Lawrence E. “Larry” Lo)氏やジム・ガルビン(James M. Galvin)氏らの尽力により提案され、1999年にIETFで標準化が始まりました。最初のIETF標準仕様はRFC2633、その後RFC3851、RFC5751、そして最新のRFC8551へと発展しています。
S/MIMEはその名の通りMIMEに対応したメール暗号化方式で、公開鍵基盤(PKI)をベースにしています。信頼できる認証局(CA)が発行する証明書を用いることで、送信者の身元を保証し、電子署名によって「確かにこの人から送られたメールである」と検証可能にしました。電子商取引の拡大や電子文書の法的有効性に対応するため、企業や官公庁における「真正性」と「不可否認性」の確保が求められていたことも背景にあったかと思います。
S/MIMEはマイクロソフトのOutlookやIBM Notesといった商用クライアントに早くから実装され、中央集権的な認証局モデルに基づくため、組織管理の面で有利であり、商用利用に適した暗号化方式として発展してきました。
TLSの登場と限界
1990年代半ばになると、電子メールサーバ間の通信を保護する仕組みとしてSSL(Secure Sockets Layer)が登場し、その後改良版であるTLS(Transport Layer Security)が普及しました。
電子メールの世界では、SMTPにおけるTLS利用の方法として二つのアプローチがありました。一つは「SMTPS」と呼ばれる方式で、TCPの465番ポートでSMTP通信を最初から暗号化するものです。これは事実上のデファクトスタンダードとして利用されましたが、IETFによる正式標準化は遅れ、後に「非推奨」とされた時期もあります。もう一つは、通常のSMTP(ポート25や587)で接続した後、STARTTLSコマンドで暗号化を開始する方式です。これはRFC2487で定義され、現在の標準的な実装となっています。
その後、混乱を整理するためにIETFはRFC8314を勧告し、SMTPS(ポート465)の再定義を行いました。これにより、クライアントとサーバの間での安全なメール送信手段として、465番ポートを利用した暗号化済みセッションの開始が正式に認められました。結果的に、現在はSTARTTLSとSMTPSの両方が併用されており、TLSの導入によって経路上の盗聴リスクは大幅に低減しました。
しかし、TLSやSMTPSはいずれも「通信経路の暗号化」に過ぎず、メールサーバに到達した後の保存状態は平文のままです。プロバイダーや管理者がアクセス可能である以上、メッセージの機密性は完全には担保されません。そのため、TLSは安全性を高める重要な基盤であるものの、エンドツーエンド(E2E)での暗号化、すなわち送信者から受信者まで一貫して暗号化が維持される仕組みが不可欠なのです。
信頼のモデル ― PGPとS/MIME
PGPとS/MIMEの大きな違いは「信頼のモデル」にあります。PGPは「Web of Trust(信頼の輪)」という仕組みを採用しており、ユーザー同士が相互に鍵を署名し合うことで信頼関係を広げていきます。これは分散的で柔軟ですが、ユーザー自身の判断に依存するため、組織での利用や大規模運用にはやや不向きです。
一方、S/MIMEは認証局(CA)が発行するデジタル証明書に基づいて相手の身元を保証します。これは中央集権的なモデルですが、組織や企業にとっては管理しやすく、商取引に必要な「法的証拠能力」を担保しやすいという強みがあります。
PGPやS/MIMEの現状
PGPやS/MIMEは電子メールの暗号化方式として長い歴史を持ち、それぞれ一定の成功を収めてきました。これらは添付ファイルの暗号化だけでなく、メール本文を含めた暗号化と改ざん検知が行え、非常に協力な仕組みが出来上がります。しかし現実には、これらが広範に普及して「当たり前の仕組み」になっているとは言い難いのが実情です。
まずPGPは、その運用が利用者のスキルやセキュリティリテラシーに大きく依存します。公開鍵と秘密鍵の管理、署名と暗号化の違いの理解、鍵の有効期限や失効の扱い、信頼の輪(Web of Trust)に基づく署名の判断など、利用者に高度な判断と操作を求めます。そのため、セキュリティに強い関心を持つ技術者や研究者の間では活用されてきましたが、一般ユーザーにとってはハードルが高いものでした。
一方S/MIMEは、認証局(CA)が発行する証明書を利用するため、相手の真正性を客観的に保証できるという強みを持ちます。しかし、その証明書取得にはコストが伴い、さらに証明書の期限管理や再発行といった運用負担も避けられません。また、送信側と受信側の双方が同じ仕組みをサポートしていなければならないという制約があるため、利用範囲が広がりにくいという問題があります。
こうしたことから、すでに電子メールの暗号化方法として確立した手法があるにも関わらず PPAPという方法で安全に気を配っているポーズを取ることが広まっていったのだと考えています。
脱PPAPの実装と実態
PPAPの問題点が広く認識されるようになったことで、多くの組織が「脱PPAP」を掲げ、添付ファイルを直接メールに付けず、別の方法で受け渡す仕組みを導入しています。代表的な実装としては、添付ファイルを一旦サーバーに保管し、そのダウンロード用のURLをメールで送信し、続けて別メールや別手段でURLのパスワードを伝える方式です。表面上は「ファイルを直接メールに添付しない」という点でPPAPから脱却したように見えますが、実態としては「ZIPファイルがURLに置き換わっただけ」と言わざるを得ません。
この仕組みでは、結局ファイルへのリンクとパスワードが同一経路でやり取りされる場合が多く、暗号化の本質的な課題は解決されていません。特にメールが誤送信されたり、受信者のメールボックスが不正アクセスを受けたりすれば、リンクとパスワードの両方が漏洩し、従来のPPAPと同じく秘匿性は確保されません。さらに、ユーザー体験の面でもURLとパスワードを使ったアクセスの手間が増える一方で、セキュリティ上の優位性が薄いため、「形だけの脱PPAP」となってしまうのです。
本来、脱PPAPの目的は「利便性と安全性を両立しつつ、セキュリティ上の実効性を高める」ことにあります。したがって、単にファイルを添付からURLに置き換えるだけでは不十分であり、アクセス時に本人確認を伴う認証、リンクの有効期限やアクセス制御、利用ログの記録、さらには送信者側でのファイル失効や削除の制御ができることが求められます。実際の「脱PPAP」は、単なる仕組みの置き換えではなく、ゼロトラストの考え方を前提に「真正な相手だけに届ける」体制を整えることこそが肝心なのです。
近年では「そもそも電子メールでファイルをやり取りする必要性が薄れてきている」という大きな変化も無視できません。Microsoft Teams、Slackといったコラボレーションツールの普及により、メッセージングとファイル共有が統合された安全な環境が提供されるようになりました。これらのサービスは既に認証・アクセス制御・監査ログといった仕組みを備えており、暗号化通信が標準で行われるため、PPAPのような「見せかけの暗号化」をわざわざ利用する必要はありません。
「脱PPAP」の議論は単なるメールの添付方法にとどまらず、そもそも電子メールを主たる手段とすべきかどうか、という問いに直結しているとも言えます。
情報漏洩防止(DLP)とIRM/DRMの組み合わせ
別の方策としてDLPの活用があります。
DLP(Data Loss Prevention) は、電子メールやファイル共有において「個人情報」「マイナンバー」「顧客データ」「設計図面」などの機微情報を自動的に検出し、必要に応じて送信をブロックしたり暗号化したりする技術です。メールゲートウェイやエンドポイントに導入されることが多く、送信者の意図しない誤送信や内部不正による情報流出を防ぐ仕組みとして企業で広く利用されています。
一方で IRM(Information Rights Management)／DRM(Digital Rights Management) は、ファイルそのものに利用権限を付与し、受信者がどのように扱えるかを制御する技術です。閲覧は可能だが保存や印刷は禁止、あるいは有効期限を過ぎたら自動的に開けなくする、といった制御が可能になります。
この二つを組み合わせると、次のような強固な仕組みが実現します。
- 送信前検知(DLP)
- 機微情報を含む場合は自動的に暗号化を要求、あるいはIRMポリシーを強制適用。
- 受信後制御(IRM/DRM)
- ファイルを開いた後も、閲覧範囲・コピー・転送・印刷・スクリーンショット取得などを制御可能。
- 後追い制御
- 誤送信が判明した場合でも、IRM/DRMによって「後からアクセス権を失効」できる。
つまり、従来のPPAPが「メール送信の時点だけ」を形式的に守っていたのに対し、DLP＋IRM/DRMは「送信前→送信時→送信後」というライフサイクル全体で情報を守る仕組みだといえます。
最後に
本稿では、PPAPの問題点、PGPやS/MIMEといった暗号化方式の歴史的経緯、TLSやSMTPSの発展、そして「脱PPAP」の現実について整理しました。暗号技術は長年にわたり進化してきましたが、現実の利用においては「運用負担」「普及の難しさ」「技術と利便性のバランス」といった課題が常に伴ってきました。電子メールが依然として主要な通信手段である一方で、TeamsやSlackといった新しいコラボレーション基盤が普及し、より安全で効率的なファイル授受の仕組みが広がりつつあります。
ポステル氏の功績は計り知れないものであり、私たちが今もなお電子メールという技術を使い続けられているのは、氏が残した土台のおかげにほかなりません。しかし同時に、氏が遺した仕組みに固執し続けることが本意ではないはずです。ポステル氏の精神は、常にインターネットを前進させ、よりよい形に進化させていくところにありました。
したがって、私たちが今なすべきことは、氏の築いたものを大切にしながらも、それを超えて新たなステージに進むことです。より安全で、より使いやすく、現代の脅威に対応できる情報のやり取りの仕組みを模索することこそが、ポステル氏の理念を真に継承する道なのではないでしょうか。
-
Author's preface to the book: "PGP Source Code and Internals" (1994, Philip Zimmermann) ↩