座談会「社会からPPAP をなくすには？」Part3　～PPAP に代わる安全な方式その2～

2020年10月15日 06:12

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

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

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

Part2に続いて．

クラウド共有

上原：ただ，そういうクラウドはだれか分からない管理者が見ているかしれないから信用しないというのは分からんでもない．その意味で面白いのはFirefox Send．クラウドに確かに保管されるのだが，まずアップロードのところで暗号化される．Firefox Send 管理者には中身は見えない．鍵はURL に含まれた状態で相手に送られる．相手がメールを開いて，Firefox Send のサーバにアクセスしにきた瞬間に鍵が届いて，解きながらダウンロードされる．すごくよくできているなと思うのです．
　ただ，惜しむらくは，URL に鍵が含まれているので，最後の瞬間に鍵がサーバにいっている．あと一歩end-to-end 暗号化に足りない．
　ただ，よく考えたら，そのFirefox Send を運営する立場からすると，自分のところにあるストレージは全部暗号化されているので，たとえば，それこそ捜査機関がやってきて，お前，出せと言われても，いや知りませんと言えるというのが一番の実はメリットなのではないかなと思いながらあれを見ていたのですね．
崎村：Firefox Send みたいなのはどのカテゴリですかね．
楠：あれはクラウド共有の一種類なのかな．end-toend encryption までやっているとちょっと違いますけれどもね．Firefox Send，好きすぎて，会社用に立てましたよ（笑）．
上原：いや，会社用に自分でFirefox Send を立てるというのが一番安全でいと思うのですよね．Firefox Send のもう1 つの欠点は送信者の認証がないこと．メールが送信者認証されていればいいのですけれども．Firefox Send を自ドメインで運営すれば，少なくともその組織からきたというのが分かる．
楠：はい．
崎村：わたしは，Firefox Send じゃないけど，NextCloud を自分のドメインで立てて，そこからリンクを共有するとかやってます．結局この手のものというのはあれですよね，送信者認証，受信者認証，メッセージ認証，この３つと，それに基づく認可に尽きるのですよね．
上原：そうですね．はい．
楠：それで今，Firefox Send をまず立ててみて，銀行の業務要件に従ってそういうファイル受け渡しツールとかをつくれたらPPAP の代わりに売れないかなとか検討したのですが（笑），結局endto-end encryptionしている瞬間，ウイルススキャンをかけるみたいな要件を満たせなくてつらいみたいな．
上原：いや，だから，Firefox Send の受け取り手順に1 枚かませて，受信側組織はファイルをダウンロードしてウイルスチェックをしてからエンドユーザに渡すみたいなソリューションとセットでやればいいかと思っているのですよ．
楠：それはそういうサーバ立てて復号するのですよね．
上原：ええ．だからまあそういうのをちゃんと動かすサーバをつくらなければいけないんですけど．
楠：ああ，受ける側でそれをインターセプトしてというのはなんかだんだん何のために何をやりたいのかが分からなく．
上原：まあでも自分の組織の中で閉じてできるのなら，たとえばその受け取ったFirefox Send のURL を社内のあるWeb Form に突っ込むと，sanitize してから送ってくれるみたいなソリューションでもいいと思っていて．
楠：受け手のソリューションを別に用意するという．
上原：そうそう．そうです．
楠：代わりにファイルをダウンロードして，無効化なり，アンチウイルスなり，チェックをかける．
上原：そうそう．それでそのあとメールでエンドユーザに送ったら元の木阿弥かもしれないので，たとえば，共有フォルダにぽこんとその人の権限で置いてくれみたいな．
楠：ではそういうFirefox Send にSelenium かなんかでアクセスをして，ひと通りのことをやってくれるやつを端末側で用意をしてやる．
上原：そうです．はい．
楠：なるほどな．なんかそこまで立てるのだったら，もうちょっと素敵なプロトコルにしたくなるな（笑）．
上原：まあそれはそうですね．はい．

組織超えグループウェア

楠：でもFirefox Send って，若干関心が高まったのというのはやはりみんな宅ふぁいる便難民になったときだと思うのですけれども．あの宅ふぁいる便がリスク管理部門をクリアしていたというのは一体何だったのかなと．
大泰司：あとなくなってしまったのですけれども，サイボウズLive を使っている時期がありましたね．会社をまたいでグループをつくるとき，よく使われていましたね．
上原：組織越えのグループウェアみたいなものですよね．
崎村：そうそう．
大泰司：今，その人たちはだいたいSlack にいったんですよね．でも，SlacKに移れないおじさんが結構，残ってしまいました（笑）．そういう人たちはいまFacebook に流れ込んでいる．
楠：でも，メッセンジャーでは置き換えにならない．業務で使うのだったら，どちらかと言うとSlack などのビジネスチャットなのかなと．
上原：システム管理部門にすごく力があれば，一番いい逃げ先は今，Teamsだと思う．だけど，テナントデザインがすごい難しい．
楠：それはActive Directory の運用の細かいところが．
上原：いや，そもそもチームをつくるという権限をだれに与えるかとかですね．あと，チームでつくると，グループウェアとしてファイル共有ができたりするのですが，その仕組みが，あの上にあるのですよ，何だっけ．
楠：SharePoint．
上原：SharePoint の上にあるのですよ．その連携が，いろいろ気持ち悪いのですよね．
楠：SharePoint をパーツっぽく使っているおかげで，Teams でごにょごにょやっているといつの間にかSharePoint 側に不思議な枝が生えていきますよね．
上原：そうそうそう．不思議なファイルがSharePointにできるのですよね．それもなんか気色悪くて．
楠：しかもそれもみんな検索の対象とかにいつの間にかなっている．
上原：そうそうそう．それで，ある大学の先生から聞いてびっくりしたのですが，Teams でフォルダを掘るときに，最初，適当な名前で付けておいて，あとでちゃんとした名前に変えても，SharePoint にできるフォルダが，その最初の名前のまま（笑）．
楠：リソース名だけ変わる．
上原：リソース名だけ変わるので（笑），最初「ほげほげ」で作ると，「ほげほげ」というフォルダがSharePoint側にできて，ずっとそのまま（笑），ひどいシステムだということが分かった．
楠：なかなか切ないものがありますね．
上原：びっくりしましたね．
大泰司：だから今そんな感じでプロジェクトごとに使うツールが別々でものすごい大変．

ビジネスチャット

楠：それで言うと，我々はもはや電子メールではなくてLINEとか，Telegramとか，素晴らしいend-toend encryption ソリューションを持っているわけで，メールが残っているのは法人の問題ですよね．業務で使えるのだったら，どちらかと言うと，Slack とか，ビジネスチャット系なのかなというふうに．
上原：まあ電子メールがいいのはインターオペラビリティがちゃんと確保されていること．あと，これはもう文化の問題ですが，仕事の依頼をLINE で送るとは何事だと怒り出す人がいる（笑）．
崎村：昔はメールだって怒られたのですけれどもね．
上原：そうそうそう（笑）．
大泰司：昔ね，メールで怒られていましたよ（笑）．
上原：今はメールも，マナーと流儀と仁義を切ればちゃんと認められるようになった．だからインスタントメッセージングでも，インターオペラビリティあるかたちで標準のものが出てきてくれればいいのですが，ちょっと望み薄なので，しばらくはメールの地位は揺るがないという気はしているのですよね．
楠：そうなのでしょうね，XMPP（Extensible Messaging and Presence Protocol）とか，一時期，インスタントメッセージングプロトコルの標準化の議論もだいぶあって，iMessage などオープンな仕組みにつながったりしましたが，あまり流行らなかったですね．
上原：結局，まだまだメッセージングの世界は囲い込みをしないことには競えないのですよね，きっと．
楠：あとは結局，ことごとくUX にかかわるものが規格に響いてきてしまうから，標準に乗った瞬間に中途半端なものしか出せないというのはある気がしますね．
上原：なるほどね．それはそうですね．
楠：やはり鍵のハンドリングというのは，最後，一番，プロプラで残りそうな部分というか，PKIX WG（PKIの標準化を議論するIETF のワーキンググループ）がうまくいかなかったことによって，オープンでやってうまくいった動きはあまり少ない．

業務システム

大泰司：電子契約というのはここ1 ～ 2 年でどんどん入ってきている．調達や営業部門では，見積書がPPAP できて，イラッとするところですが．でも，これはもう電子契約にどんどん移っていきますね．
崎村：定型業務は電子契約やCRM（Customer Relationship Management）にどんどん移っていくという話ですね．
楠：そう，寄せていくのが大事．ツールがないところだと，添付ファイルのようななんでも送れる仕組みを使って，その結果問題を起こしたりする．要りもしない実行ファイルとかも送れるようになっていて．
　上原先生ともよく話しているのですが，電話にしても，メールにしても，好きに入力した文字列で指定した相手に自由にものを送れる仕組みはやはり限界がある．社内コミュニケーションなど密度の高いやりとりは，Slack やTeams など，決まった相手とのやりとりに限定したものに寄せていく．それで電子メールの使い道をできるだけ日々の業務から減らしていく．大代表のメールに入れると，セールスフォースでCRM で反応するみたいな，汎用メーラーを使わないようにしていくのが本当はいいのだろうなと．
上原：そうですね．
崎村：だから業務で，いわゆる電子メールを使うのは本来間違っていると思うのですね．これは金融機関のコンサルをやっていたときにも強く言って，ネットワークの分離などではなく，本来は顧客向けのメールだったらちゃんとCRM から出せと．そうすると文面のコンプライアンスも何もかも全部入るわけですよね．EUC (End User Computing) をやるなと．電子メールなんていうのはEUC の最たるものだろうと．
楠：しかもメールボックスというのは個人単位なので，人事異動があったときに管理できなくなる．社外とのやりとりは全部CRM でいいんじゃないかなと．
上原：メールがいろんなものの非効率を生んでいる．組織内でも添付ファイルをつくって，ご査収くださいとかいうのを組織内でぐるぐる回しながら，いろんなバージョンのファイルが散逸していく．リスクも増えていくし，バージョン管理もできない．あの状況を何とかしないといけないという意味でも，メールはもうなくしてしまったほうがいいと思っていますね．
大泰司：オンラインストレージを使うのがいいと思います．現実にもうかなりそうなっている．PPAP の誤送信防止ソリューションのベンダも，大手は設定1 つでオンラインストレージを使うようになっている．
楠：なんか明らかに異なる文化圏があって，VDI（Virtual Desktop Infrastructure）が入っていて，フィルタリングソフトで主要なクラウドサービスはみんなフィルタリングしている一連の会社や役所がある．あの文化圏の人たちは，在宅勤務のサポートに苦慮しているような感じになっていますが，これからどうするのでしょうかね．

Part4に続く．

（「情報処理」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/）