ZIP暗号化が普及した背景

セキュリティ界隈におけるPPAP問題とは、簡潔にまとめてしまえば「ZIP暗号化」という方法の是非が問われた問題だと言える。岡庭が次のように解説する。

「メールの添付ファイルにZIP暗号化が使われ始めたのは今から約18年前、個人情報保護法の制定と前後します。2005年の全面施行で個人情報を取り扱う事業者への罰則が規定されたことにより、個人情報の取り扱いについての対策が加速することになりました。個人情報の漏えいを予防するための対策として、当時のJIPDECの研修資料では、個人情報は漏えい時を考慮して暗号化することが推奨されています。この資料には、パスワードを別手段で送ることも明記されていました。

この一連の手順が個人情報にとどまらず、機密情報へも適用されることになりました。さらには、一律で『添付ファイルは暗号化する』というように適用範囲が拡大されていったのです。その背景には、個人情報や機密情報かどうか判断しづらい内容を逐一判断するのが難しいという考えもあったのではないでしょうか。また、当時は情報漏えいにおいて、メールの誤送信が原因の一つとして言われていた点も関係していると思われます。」

個々の業務に丁寧さを求める日本人らしい変遷と言えるかもしれない。折しもその頃は某通信会社による数百万件に及ぶ顧客リストの流出なども発生。自治体や金融機関などでも流出事件が相次いだこともあり、個人情報漏えいに対する世論の目が厳しくなっていったという背景もあるだろう。いつしか添付ファイルをZIP暗号化し、パスワードを別送するという方法は、企業・組織などでデファクトスタンダードの位置を獲得することとなった。また、当時ISMSを取得した企業でメール誤送信が原因で情報漏えいが起こった場合、是正措置としてメールの添付ファイルをZIP暗号化するという対策を採用するケースが少なくなく、そのような潮流もこうした動きに拍車をかけたと思われる。当時、その動きに対応するソリューションも数多く登場していた。

メール通信経路での盗聴対策としての利用

ここで、本稿で取り上げた「PPAP」という言葉を説明しておこう。PPAPとは図1のように、ZIP暗号化した添付ファイルの送付プロセスの頭文字をもとに作り出された造語のことだ。

図1: ZIP暗号化ファイルの送付プロセスの頭文字をとったPPAP

このPPAPと呼ばれるファイル送付のプロセスがデファクトスタンダードとなった理由は先述の通りだが、この方法が利用されていたのには「盗聴対策」と「誤送信対策」の二つの理由が存在する。まず、盗聴対策としての利用について、岡庭が説明を続ける。

「盗聴対策としての利用についてですが、ファイルを添付したメールは通信経路上で盗聴されるリスクが少なからずあるというのがその前提にあります。万一盗聴された場合でも、ファイルを暗号化しておけば、情報漏えいのリスクは低減される、という考えです。しかし、インターネット普及初期の頃のように、UUCP^*1 を通信プロトコルとして利用していた時代から移り変わり、現在では多くの場合、送信元組織のメールサーバーと送信先組織のメールサーバーの間で直接SMTPセッションを張っています。そのため、悪意あるMTA（メール中継サーバー）がメール通信を中継することがなく、悪意ある第三者によって通信経路を流れるデータを盗聴されることは起こりづらくなりました。というのも、メールサーバー間の通信で中間者攻撃されることは、通信事業者の設備が悪意ある第三者に侵入されることを意味します。さらに、最近ではSTARTTLS等でSMTPの通信が暗号化されている場合が少なくないため、メールが通信経路の盗聴によって漏えいする可能性は極めて低いといえます。すなわち、昨今のメール送受信のシステム環境を考慮すると、通信経路上で盗聴されるリスクは非常に低いのではないでしょうか。

強いて挙げるとするならば、フリーWi-Fiなど信頼性の低いネットワークを使用した場合の盗聴リスクが考えられます。しかしここ最近、多くの企業では社内ネットワークへの接続においてVPN経由で通信を行うことによってセキュリティを確保しています。また、クラウドサービスなどのWebメールの場合でも、原則としてHTTPS化されるため、メールの送受信時において盗聴による情報漏えいリスクは極めて低いと言えます。従って、盗聴対策としてメールの添付ファイルをZIP暗号化することは、あまり意味がなくなってきているといえるかもしれません。」

^*1「Unix to Unix Copy Protocol」の略称。TCP/IPが標準として利用されるようになる前のインターネット普及初期の頃に利用されていた通信プロトコル。

誤送信対策としての利用が抱える3つの問題

ここまでの解説を踏まえると、盗聴対策としてZIP暗号化を現状のまま利用することはあまりメリットがないように思える。また、次に解説する誤送信対策としての利用においても、ZIP暗号化という方法はいくつかの問題を抱えていると岡庭は述べる。

「誤送信対策としての利用について前提となるのは、仮にファイルを誤送信してしまっても、パスワードが届かなければ情報漏えいは起こらないという考え方です。メール送信時に送信を一時的に保留する遅延送信機能も重宝されるなど、2回の手順に分け、送信までのタイムラグを意図的に発生させることで、誤った送信先に気づき、解凍用のパスワードを送らなければ、そこから情報漏えいを止める可能性が上がることが期待できます。その効果の大小はさておき、一定の意味はあるということです。しかし、この利用方法は図2のように、3つの問題をはらんでいます。」

図2： 誤送信対策としての利用における3つの問題

１）受信者の作業負荷の増大

「添付ファイルをZIP暗号化してパスワードを別送するというのは、極端に言えば情報漏えいを防ぎたい送り手側の勝手な都合です。メールの受信側は別途受け取ったパスワードを入力するという手間が要求されることになります。また、ある程度時間が経過した後にファイル開封を試みるような場合、パスワードが記載されたメールを受信ボックスから探すという手間も発生します。このように、受信側に負担を強いるという点が問題となっているのです。」

２）利用可能なデバイスの限定

「次に、添付ファイルとは別のメールで送付されるパスワードをその都度入力するという手順はパソコンではまだしも、スマートフォンやタブレットなどでは非常に使い勝手が悪いということです。また、OS標準の機能ではパスワード付ZIPファイルの解凍ができない不具合も生じています。実際に、iOS 13では不具合が生じていたことが確認されています。OS側が安全性を高めるために、このような利便性を犠牲にする問題が発生しているのです。また、暗号の強度で対応可能なデバイスが異なるという点もあります。多くのOSで利用されているZipCryptoは多くのデバイスが対応しているものの、暗号強度が低い。一方で、AES-256は暗号強度が高いものの、標準では解凍できないデバイスがある、といった具合です。」

３）マルウェア攻撃への悪用

「そして、添付ファイルが暗号化されていると、ゲートウェイ型のウイルス対策が機能しないという問題があります。というのも、暗号化されたファイルだと、ウイルス対策もその中身を検査できないため、危険なファイルかどうかを判別できないからです。そのため、マルウェアが潜むファイルが含まれていても、ネットワークの出入口となるゲートウェイで検出することができません。ただし、仮にマルウェアが仕込まれたファイルを受信した場合でも、解凍して開かない限り、デバイスに被害をもたらすことはないでしょう。

一般的に、マルウェアはファイルを開いた時点で動作を開始します。例えば、エンドポイントにインストールされたESETの場合、ウイルスチェックはそのファイルを開いた時点で行われます。そのため、悪意のある動作を検出した場合はその時点で隔離されます。しかし最近では、PowerShellを悪用するものや、ダウンローダーを利用してマルウェアを別途ダウンロードさせるような巧妙なものが増えてきており、すべてを検出することが難しくなっています。

さらに最近では、Emotetのように他人のメールを引用し、違和感のない文面に仕立てる巧妙な手口が増えていることがこの問題に拍車をかけています。例えば、ZIP暗号化されたファイルのほとんどが業務に関連するものと捉える習慣がある人の場合、文面に違和感がなければ疑いもなくファイルを解凍して開いてしまうものです。Emotetが世界的に大きな被害をもたらしたのは、こうした人間の習慣化するクセを巧みに利用したためです。

この問題に対して、米国のCISA（Cybersecurity and Infrastructure Security Agency）では回避策を行うことを推奨しています。その方法とは、そもそもウイルス対策がスキャンできないZIPファイル自体を受信しないというもの。結局のところ、ウイルスチェックができないため、暗号化されたファイルそのものを受信しなければ、安全は確保されるというロジックです。」

ファイル送付で考えられる二つの安全な方法

暗号化されたファイルには、マルウェアが潜む可能性があるからそもそも受信しない、というのは極端な方法ではあるが、極めて合理的でもある。ただ、これまで是としてきた方法をすぐに転換することは、さまざまな事情を考慮すると難しいというのが現実かもしれない。それでは、ファイルを送付する方法として、どのような方法が考えられるだろうか。岡庭は2つの方法を提言する。

１）添付ファイルをWebブラウザー経由で受け渡す

「この方法では送信側のメール送付方法はこれまでと大きく変わりません。送ったメールの添付ファイルを自動的にメールから切り離して、一時的にWeb上へファイルをアップロードし、受信者はWebブラウザー（HTTPS）でダウンロードして取得することになります。」

２）クラウドストレージ経由でファイルを共有する

「クラウドストレージにファイルをアップロードして共有するこの方法は、従来からのメールに組み込む形で利用できるものもあります。チャットツールなどはまだまだ馴染みが薄い企業も少なくないかもしれませんが、こうした方法であれば既存のメールシステムと連携して利用することが可能です。ただし、企業・組織によっては、クラウドストレージへのアクセスがブラックリスト登録されて禁止されているケースもあります。」

ZIP暗号化という方法も含めたトライ＆エラーを

今回紹介した二つの代替策については、これがベストプラクティスと言い切ることはできない。それぞれの商慣習や取引先、既存の方法を変更するためのコスト面においての現実性、あるいは従業員のITリテラシーなどさまざまな要素を考慮した上で、自らの組織に最適な方法を模索していく必要があるのではないだろうか。また、ZIP暗号化という方法自体も状況によっては使い分けていくことを考慮すべきだ。トライ＆エラーを繰り返し、新しい方法を模索していくというスタンスこそがベストプラクティスといえるかもしれない。

今回岡庭が紹介した2つの方法において、いずれの方法でも受信側に一定の負担を強いるという問題は解消されていないことにお気づきだろうか。これは裏返すと、ファイルの共有には送受信側の双方で一定の負担を強いられることを示唆しているとも言えないだろうか。個人情報、機密情報を問わず重要な情報に関するファイルは本来、慎重に取り扱いされるべきだ。しかし、業務で頻繁に利用していると、その重要性に対する意識がいつしか薄れてしまいがちだ。このPPAP問題の本質は、その必要性を今一度見つめ直す時期に来ているのではないでしょうか。

話を聞いた社員：
キヤノンITソリューションズ株式会社 ITプラットフォーム技術統括本部 サイバーセキュリティ技術開発本部 サイバーセキュリティラボ　岡庭 素之