皆さんの組織でも、重要な情報を含むファイルをメールで外部に送付する際に、その漏洩防止等のため、何らかのルールを設けておられるところが多いのではないかと思います。その中で非常によく見かける方式に、このようなものがあります。1添付するファイルをあるパスワードを使って暗号化zipファイルにする。2そのファイルをメール添付して送信する。3続いてそのパスワードをメール送信する。私が見聞きする限り、多くの日本企業や組織がこのようなファイル送信法をセキュリティ強化策と信じて」内規で義務づけたり、自動化システムを導入したりしています。この種のメール、少し考えるだけでセキュリティの観点からは効果がないことは明らかです。同一経路でファイルとパスワードを送っているのですから、仮に攻撃者がいれば片方が入手できれば他方も入手できるはずです。この種のメールは受信者にとっては煩わしいだけの、大変やっかいな、大きく言えば生産性を阻害する要因にしかなっていないと感じます。このようなファイル送信方式は、一部では(揶揄して)PPAP方式と呼ばれています。曰く、Passwordつきzip暗号化ファイルを送りますPasswordを送りますAん号化(暗号化)Protocolの略だそうです。(JIPDEC)の大泰司章さんです。最近では(一財)日本インターネットプロバイダー協会(JAIPA)のイベントでこんな講演をされていました。くたばれPPAP!~メールにファイルを添付する習慣を変えるところから始める働き方改革~それにしても何故PPAP方式という無意味な手法が広がってしまったのでしょう。メールの使われ方についてシステム管理者としてずっと関心を持ってきた経験からすると、このPPAP方式が普及するまでには次のような経緯があったように感じています。(a)インターネット上での通信は暗号化されてこなかった歴史がある。セキュリティ上の脅威が認識されるにつれ、インターネット上のどこかでの盗聴の脅威に備えて何らかの暗号化が必要であるという認識は広まった。(b)そんな中、公開鍵暗号の普及がありインターネットプロトコル全般への適用が進んでいった。TELNET、FTPやHTTPといった当時の主要プロトコルは送受信者間の通信が直接TCPで行われるため、そのTCP通信そのもの、又はその1つ上のレイヤを公開鍵暗号で暗号化するプロトコルが生まれ、普及を迎えた。SFTPそしてHTTPSなどが広く使われるに至った。(c)しかしメールは1つのTCPセッションで送受信されるわけではないため、このような対処では通信全体が暗号化できない。現在ではメールは以下のような手順で送信者から受信者に届けられる。(ア)送信者のメールクライアント(MUA)から、まず所属組織のメールサーバ(MTA)にSMTP、またはTLSで暗号化されたSMTPSを用いて送信される。(イ)送信者側のMTAは受信者に向けて多くの場合はいくつかのMTA間をバケツリレーのように何度かSMTP(運が良ければSMTPS)で転送されてから、受信先の組織のMTAに届く。(ウ)受信者がその組織のMTAのメールボックス内のメールを読む。この際多くの場合、その認証情報であるユーザ名とパスワードを保護する必要から暗号化されたプロトコル(POP3SやIMAP4S、HTTPSなど)が用いられる。この手順の随所にメール盗聴のリスクはあるが、特に(イ)におけるMTA間の転送が暗号化されるとは限らないことが大きなリスクとして残っている。送信者にとってMTA間通信の暗号化は強制できないし、暗号化されるかどうか事前に確認する術もない。同一組織内でメールが送受信されるのでない限りは、受信者の手元に届くまでの間に暗号化されない通信が残りうる。(d)この問題の解決には、メール本文や添付ファイルを暗号化する必要がある。提案され規格化された。HTTPSなどの通信路暗号化方式がサーバ側に公開鍵と秘密鍵のペアを持ちさえすればよいのに比べ、メールの場合は全ての利用者がそのメールアドレスに対応する公開鍵と秘密鍵を個別に持って管理する必要がある。この鍵の管理の煩雑さやコスト(特にS/MIME用の電子証明書コスト)がネックになって、メールの標準的な暗号化は普及しなかった(現在もこの状況は改善していない)。(e)そこで苦肉の策として、パスワード付zipなど共通鍵方式で暗号化したファイルを送り、文書やFAXなどの別の手段でパスワードを事前に共有したり、後から送付する手法が広まった(この前後には専用ツールによるファイル暗号化や、暗号化された自己解凍ファイルの送付が一部で広まった時期もあったが、汎用性の無さから廃れた)。折しも、Pマーク認証などの取得に際して「メール送信時の個人情報を含む添付ファイルに対するセキュリティ対策」が必要な審査項目に入り、パスワード付zipファイルにした上での送信をセキュリティ対策として認める動きが広がった。して急速に添付ファイルのパスワード付zipファイル化がセキュリティ対策として標準的地位を得るようになった。(f)しかしこのパスワードの伝達を電子メール以外の手段で行うことは極めて煩雑なので、結局「別メールならパスワードをメールで送って良い」という規定で運用する組織や企業が現れ、PPAP方式が誕生した。これがPマーク等の審査時にセキュリティ対策として認められてしまったことと、「メールによる情報漏えいの主なリスクは盗聴ではなく誤送信であり、その対策としてPPAP方式は一定の効果がある」という理屈が捻り出されたことにより、一気に普及が加速して現在に至っている。こんな経緯ではないでしょうか。それにしても、おそらくPマーク認証等の要請から生まれたパスワード付zipファイルでの添付ファイル送信が、PPAP方式に劣化するに至ってもまだ審査に通ってしまうのは困ったものです。一般にデータの暗号化というのは「データのアクセス制御問題を暗号鍵の管理問題に置き換える」手続きと見なすことが出来ます。パスワード付zipファイルにおいては、その暗号鍵がパスワードにあたるわけですから、重要なファイルの送信問題はパスワードの管理問題に置き換わっているのであり、そのリスク評価は不可欠です。単純に考えれば、そのままメール送信してはいけないとされるデータが暗号化されている場合に、その暗号鍵がそのままメール送信されていたのでは何もリスク軽減になっていません。「PPAPが自動化」されているソリューションでは、それにセキュリティ的な意味を見いだすのは困難です。受信者が添付ファイルを暗号化したまま保存しておいてくれることが期待できる、とか、そのファイルを重要なものと送信者が考えているというメッセージになるとか、その程度のものではないかと思います。PPAP方式が「誤送信対策として一定の効果がある」かどうかも怪しいものです。誤送信は1通目のメールの送信後、手作業で2目のパスワード送信する前に誤送信に気づくということが期待されているのですが、どのような作業手順なら誤送信が高い確率で気づけるのかよく分かりません。仮にそれが成り立ったとしても、パスワード付PPAPは、パスワードが十分に予測不能な複雑さと長さを持たない限り、暗号化されたデータ本体がオフラインでの総当たり攻撃によって復号できる可能性は高いので、既に誤送付されてしまったパスワード暗号化zipファイルは情報が既に漏洩したと見なさなくてはならないと思います。最近のパソコンはGPUと十分高速に総当たり攻撃が行えるので、古いZipCrypt方式(しかし今でもよく使われています)で暗号化されたファイルなら英数字8字程度のパスワードの総当たりには1台のパソコンでも5分とかかりません。パスワードに記号を入れたり文字数を伸ばすことで総当たりが困難にできますが、今度はパスワードの管理の煩雑さが増してしまいます。このようにPPAP方式は煩雑であって労働生産性に少なからぬ悪影響を与えていると思われる割に、普通の平文メールに比べてセキュリティ的なリスクが下がっているか疑わしい手法であります。現在のメールを用いた業務で最も注意すべき標的型メール攻撃に対して、暗号化されたzipファイルは受信側MTA前後でのマルウェア対策を無効化してしまうため、かえって受信者のセキュリティリスクを高めている恐れすらあります。メールを起点に考えたときにファイルはどのように送付するべきなのでしょうか。私はこのように考えています。(1)いっそ何もせずそのまま添付ファイルでメールする。何を言い出すのだと思われるかもしれませんが、私は大真面目にそう思っています。PPAP方式ではセキュリティリスクが下がらないどころか、受信者に作業負担とセキュリティリスクを上積みさせてしまう恐れがあります。それなら、そのままメールで送った方がましです。そもそも、メールの「暗号化」とやらは上記の(c)、(イ)つまりMTA間転送での暗号化が行われていない恐れがあることを根拠に求められていたのだろうと思うのですが、現在はメールの転送トポロジは単純になってきていますので、転送に関わるMTAが送信側と受信側いずれかの管理下にない第三者であるということはあまりありません(あるとしても大抵はどちらかと契約したISPです)。Security)という規格の普及も始まっています。SMTPが暗号化していなかったことに起因するメール盗聴リスクはほとんどなくなってしまっていると思われるのです。注意するべきは経路上のMTAが不正アクセスを受けて中継メールが読み取られているリスクですが、これこそPPAP方式では全く対抗できません。DriveやOneDrive、Dropboxといったクラウドストレージだと、やり方によっては受信者を確実に指定できますし、ファイル伝送路での暗号化も保証できます。仮に受信者を間違って指定してしまったら、気づいた時点でファイルの共有を無効にすれば、それが運良くファイルダウンロード前なら情報の漏洩も防ぐことが出来るでしょう。受信者側の立場からしても、システムにもよりますがファイル送信者(この場合にはファイル共有元)がメールよりは詐称しにくい場合が多く、標的型攻撃に逢うリスクも下がります。問題は双方が同じサービスを利用しておかねばならないことですが、その対策として一部サービスではURLを認証代わりにして、そのシステムにアカウントがなくてもファイルをダウンロードできるシステムがあります。この場合にはそのURLをメールで送ることになるため、メール盗聴での情報漏えいリスクがありますが、これも本来受信するべき相手がファイルを入手したことを確認した時点でURLを無効にすれば、単純なメールへのファイル添付よりはリスクが軽減できます。sendで、URLでの送信に特化する代わりに、ダウンロード回数と有効期限を必ず指定することになっているため、手軽に「通常のメールへのファイル添付よりは漏洩リスクの少ない」ファイル送信が行えるので、最近愛用しています。他にリスクとして残っているのは、これらのクラウドストレージが実はファイルの中身をインフラ側で見ているのではないか?という問題です。それをリスクに感じるならそれこそ、パスワード付きzipにしてしまい、パスワードはメールで送れば良いのだと思います。長く複雑なパスワードにして。Workといったビジネスチャットが広く使われるようになったので、これが使えるのであれば送受信者がお互いに相手を確認しながら暗号化状態でファイルを送受信できます。これも厳密にはE2Eの暗号化ではないので、必要ならパスワード付きzipにして送り、パスワードだけメールで送るなどの対応をすることになるのでしょう。一般のSNSのファイル送信機能も同様に利用可能ですが、業務の上でこれらのSNSを使うことはポリシーの上でも許されない場合が多いかもしれません。本来はS/MIMEやPGPの普及を促すべきなのでしょうが、とりあえず脱PPAPを目指すことは、メールのセキュリティをもう少し本質的に考え直すよい機会でもあります。少なくとも、現在メールのリスクを下げる上では、標的型メール攻撃を防ぐためのなりすましメール防止策と添付ファイルのマルウェア対策と、ビジネスメール詐欺を防ぐためのメールアカウントへの不正アクセス防止策の方がずっと優先度が高く、また誤送信防止はもう少し別のシステム的な対策が必要なように思っています。いずれにせよ、PPAP方式ではほとんどリスクが軽減されておらず、生産性低下だけが起きていることはもう少し認知が広がっても良いのではないかと思います。皆さん、「くたばれPPAP!」ですよ。追伸:PPAPに加えて、PHSというのも撲滅したいのですが、それは稿を改めて。キャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。%d人のブロガーが「いいね」をつけました。