見出し画像

座談会 「社会からPPAP をなくすには?」Part1 ~定義と賛成の論拠への反論~

小特集「さようなら,意味のない暗号化ZIP添付メール」より

崎村夏彦(NAT コンサルティング)
大泰司章(PPAP 総研)
楠 正憲(国際大学Glocom) 
上原哲太郎(立命館大学)

背景はこちらの記事をご参照ください.

PPAP の定義

崎村:さて,本日は「社会からPPAP をなくすには?」というテーマで座談会を行いたいと思います.アジェンダですが,PPAP の定義,PPAP 賛成の論拠への反論,より良い方策を議論します.まずPPAP の定義ですが,オフラインで鍵を共有するのもPPAP だと思っている方もいらっしゃるようなのですけれども,それは違いますよね.
大泰司:1 通目にZIP を暗号化して添付ファイルを送って,2 通目でパスワードを送るというやり方です.2 つの軸があって,パスワードを同じ経路を送るか,違った経路で送るか.もう1 つは,すべての添付ファイルを暗号化するか,自分で判断して特定のファイルだけ暗号化するか.自動で添付ファイルを暗号化して送るソリューションを使うと,すべての添付ファイルを暗号化し,同じ経路でパスワードも送信することになる.これを,この議論ではPPAPと呼びたいと思います.
上原:この議論では,暗号化ZIP が送られて,すぐそのあとにパスワードが追いかけていくスタイルに限るということですよね.

PPAP 賛成の論拠への反論

誤送信防止

崎村: PPAP の定義は分かったので,PPAP 賛成の論拠への反論を挙げていきたいと思います.
上原:PPAP 賛成派の意見には何があるのでしたっけ.大泰司:手動で送って,2 通目までの間に間違えたなと気が付くケースがあるというものです.
上原:それだけを論拠に頑張っているんですかね.自動の場合はまったく意味がないですよね.
大泰司:ないですね.ただ,多くの場合はこのソリューションを誤送信防止ツールと銘打って売ってます.送る前に,本当にこの宛先でいいですかとダイアログが出てきて,OK,OK,OKとクリックしないと送信されない.大体この機能が入っています.
上原:それは,添付ファイル暗号化とは関係ないよね(笑).送信前にメーラーでメールアドレスを確認する機能を付ければいい.
:この問題は根深くて,本当にいちいちOKを押さなければいけないし,そのあと保留され,さらにメール上,リンクを組んでどこかのページで挿入をするみたいなフローが入っていたりする.
 あとは,会社によっては,上司をCC に入れないと添付ファイルを送れずに,自分だけで送ろうとすると自動的に止まるとか,いろんなバリエーションがある.
上原:上司の承認を得るために,上司をCC に入れ,CC に入っている上司がOKを押さないとメールが出ていかないというのは,それはそれでガバナンス上,意味はなくはない.だけど,それは添付ファイルとは関係ない気がします.
崎村:添付ファイルあるなしでリスクが異なるというのはあり得ます.だから上司がもう1 回,その添付ファイルが正しいかどうかを確認するのはありかもしれない.
 以前,知っているケースでは,ちゃんとPDF にした見積書を提出しなければいけないのに,Excel をそのまま添付してしまって,中のコスト構造やなんかが全部ばれてしまった.上司が確認したくなるというのも分からんでもない.でも,PPAPとはまったく関係ないですよね.
上原:そうだと思うのですよ.だから少なくともZIP で暗号化するのというのは相手にコストをかけているだけなので,まったくセキュリティ上の意味はないですよね.
崎村:ないと思います.あと,誤送信防止ということだと,僕,実は2005 年ぐらいに社内のR&D でプロトタイプをつくったことがあります.実際には運用されなかったのですけど.まず,メールの最初の3 行に相手の所属と会社名と名前を入れる.メールを送信するとゲートウェイがその最初の3 行を読んで,会社名とドメインとをマッチさせ,マッチしないと本人にメールがきて,ドメインがマッチしないけど本当にいいですか?と確認をとるというものです.
大泰司:それと同じようなシステムについて,誤送信防止システムを出しているベンダさんから相談がありました.それで,日本のすべての会社のドメインリストを提供してくれないかと言われたのだけど,それはできなかった.
崎村:大きな会社だと大抵取引先登録をしているので,そこからドメインを引っ張ってくればいいと思ったのですよね.あと上場企業だったら当然引っ張れるし.技術的には可能で,メールを送れなくするわけではなくて,本当にドメインがマッチしないけどいいんですかと確認するだけだから.いや違っていてもいいんだといってやれば,それはそれで問題ない.
上原:誤送信で一番多いパターンというのは,たとえば,メーラーがアドレス補完機能を持っていて,立命館大学の上原にメールを出すときに,宛先にueharaまで打ち込んだら補完されて,そこでエイヤーと出してしまうと,実は全然違うコンプリーションしていて,まったく違う人に送信してしまうパターンなのではないですか.誤送信防止の人たちが主張しているのはほかにどんなパターンがあるのですかね.

画像1

■座談会の様子 左上:楠 正憲 左下:上原哲太郎 右上:大泰司章 右下:崎村夏彦


:たとえば,ルール上,組織以外は全部BCC に入れなければいけないのに,CC に入れて,個人情報漏洩になってしまうケースとか.
上原:でもそれもPPAPと関係ないね.CC をチェックすればいいわけですよね.
:そういう機能も入っていたりします.
崎村:アドレスの補完機能があるからこそ誤送信が減ると考える人たちもいるわけですね.ただ,皆さん失敗からしか学ばないので,補完機能で誤送信したということがあると,3 カ月後ぐらいに補完機能が使用禁止になったりする.
 間違ったPDCA(Plan-Do-Check-Action)が日本中をまわっていて,基本的にその機能がなくしたミスというのはミスとしてカウントされない.あらかじめ登録してある,相手が分かっている,謝れば済む相手しか補完されないはずなのに,その補完機能をオフにしていると全然訳の分からない人に送られてしまうというのがある.
 取引先として登録してある人だったら,もう面が割れて,たぶん知っている人だから,間違って送ってしまった,ごめんなさい,で済んでしまうわけですよね.しかし,まったく面識のない人に送られてしまって事件になるリスクを考えると,後者の方が実はリスクの度合いとしては大きいような気がするのですけれども.

ISMS やP マークが要件としているという都市伝説

上原:やはり,こう,納得感がある理由がないのに何でこんなに使われているのですかね.
崎村:人によっては,ISMS(Information Security Management System)が要求するからとか,P マーク(プライバシーマーク)が要求するからとか,そういう都市伝説があって,その都市伝説に従って実装している人たちも結構いるみたいです.
上原:P マーク説は結構あちこちで聞きますよね.それで,大泰司さんは結局その犯人捜しはしたんでしたっけ.
大泰司:犯人捜しして,見つからなかったのですよ.
上原:やはり見つからなかった.
大泰司:ただ,誤送信防止のソリューションを出しているベンダがP マークの審査基準がこう改定されているから,これに対応しなければいけませんというようなことは書いていますね.では本当にP マーク審査の現場でどうなっているのか聞いてもらったけれども,分からなかったです.
 それで,JIPDEC(一般財団法人日本情報経済社会推進協会)の中に教育用・研修用資料としてガイドラインのようなものがあったのですが,それを見たら,個人情報は暗号化しましょう,そのファイルを送ったときにはパスワードは別の手段で送りましょうと書いてある.
上原:別の手段とは書いてありますね.
:うん.正しい.
上原:別の手段だったら正しいのですけれども,別の手段というのが同じ手段のメールにいつの間にか化けているということですかね.
大泰司:うん.そうですね.
崎村:審査基準の中に,個人情報を送るときは暗号化,安全管理措置をとることとは書いてある.でも,キーを同時に送っていたら安全管理措置として崩壊している.
:ただ,そこまで中身を見ない,チェックリスト式のセキュリティの人たちというのは,自分の頭でリスク評価をできない人が多くて.対策しているかどうかと,その方法は社会で使われている実績ある方法かという,この2つを気にしている.確かにPPAP はこれを非常によく満たすいいソリューションなんですよね.
上原:本当に広く,セキュリティを売りにしておられる大上場企業さまがお使いなので困ってしまう.
:たまによく訓練された日経BP の編集者なんかだと,ZIP はメールで送ってきて,パスワードはSMSかFacebook メッセージで送ってくる人はいますね.
崎村:それは正しい.
上原:まあ,正しいは正しいですね.
崎村:だから僕がもしパスワード付きZIP をやるのだったら,頻繁にやりとりする相手だったら,あらかじめ両者で秘密鍵を決めておいて,それで送るようにすればいいですよね.
:私の働いている保秘を大事にする某所ではまさにそのやり方を使っているのですが,プロジェクトの数だけ約束事があると,最終的に破綻するのですよ.もうね,何カ月かおきに同僚に頼んでポストイットに書いてもらうという儀式が(笑).
崎村:ただね,PPAP のほうが相対的に楽というのは,なぜかというと効果がないから.

Part2に続く.

(「情報処理」2020年7月号掲載)

■崎村夏彦(正会員) nat@nat.consulting
 本会SC 27/WG 5 主査.OpenID Foundation 理事長.ディジタル・アイデンティティとプライバシに関する国際標準化が専門.著した規格にOpenID Connect, JWS, JWT など.

■大泰司章 otaishi@gmail.com
 三菱電機,日本電子計算,JIPDEC を経て,PPAP 総研設立.電子契約,電子署名,メールやWeb のなりすまし対策を普及.PPAP やハンコ等の非効率な取引慣行を変えて,真の働き方改革を目指すIT コンサルとして活動中.

■楠 正憲(正会員) masanork@gmail.com
 マイクロソフト,ヤフーなどを経て2017 年からJapan Digital Design CTO.内閣官房 政府CIO 補佐官としてマイナンバー制度を支える情報システム等の構築に従事.

■上原哲太郎(正会員) t-uehara@fc.ritsumei.ac.jp
 和歌山大学,京都大学,総務省を経て2013 年より立命館大学情報理工学部教授.専門はサイバーセキュリティ,システム管理,ディジタル・フォレンジック.入力しにくいだけのExcel 帳票や無駄な押印の撲滅にも興味を持つ.

※本小特集記事(全体)を入手するには以下の方法がございます。ぜひご利用ください。
1)情報処理学会会員になり(http://www.ipsj.or.jp/nyukai.html)、電子図書館(https://ipsj.ixsq.nii.ac.jp/ej/)に登録する。
2)fujisanで購入する。
 - 特集別刷(https://www.fujisan.co.jp/product/1281702304/
 -「情報処理」本体(https://www.fujisan.co.jp/product/1377/b/1986578/
3)Kindleで購入する。(https://www.amazon.co.jp/dp/B089N3VX86/

この記事が気に入ったらサポートをしてみませんか?