世界での同意には時間がかかるだろうが、、、

　ある日、営業部から問い合わせがある。

「お客様のところにメールが送れなくなったんだけど、、、」

　普通だと、「メールが送れない、業務に支障が！」と騒ぐ人たちが、なんか歯切れが悪い。とりあえず、サーバの状況を見るが、サーバは正常に動いている。この辺が、歯切れが悪かった理由なのだろう。あるお客様だけがおかしいということ。いずれにしても、現場見なければわからない。確認に向かう。

　確かに特定のお客様宛のメールだけが届かない。エラーを見て、愕然とした。

　お客様側がTLSでしか通信ができない設定になっていた。普通は、TLS対応にしていても、非対応なサーバへの送受信のために、平文にも対応するように設定するが、平文を捨ててしまうとは、随分思い切ったことをする。

　が、安岩産業がまだ、TLS非対応だったのは事実で、検証は進んでいて、ほぼGOが出せる状況であったので、即実装する方向にすることにし、営業部の田中に状況と対応の説明をすると、「実は、、、」と追加情報が伝えられた。

「ちょっと前に、お客様から通達があったんだよね。セキュリティーポリシーの強化の方針が実装に移され、社内ネットワークへの出入りパケットはすべて暗号化を求める、ということでした」

　牛尾は、驚きながらも

「そういう連絡は、すぐにお伝えいただかないと。。」

　すると田中は、バツが悪そうな顔をしながらも

「でも、通達の一番最後のところ、みてみなよ。『多くの組織では、通常対応される設定であり、追加の設定となるケースは少ないと思われます』ってあるじゃん。なんでうちは、対応してなかったのさ？」

　牛尾は返す言葉がなかった。ただ、多くの組織、と言う一言は気になった。

　即日、TLS設定を行い、そのまましばらくの時間のトラフィックを監視し、インバウンドメールセッションを一通り確認してみた。その結果、驚くべきことがわかった。

　業務関係のお客様・業者からのメールは、100%、TLSで来ていたことがわかった。数多いメールトラフィックの中に、わずかに平文メールがふくまれているが、これは、業者からの広告メールなど、基本的にはspamに分類しても間違い無いと言っても過言ではなかった。

　その為、極論を言えば、spamフィルターをかけるのではなく、全部STARTTLSにしてしまう、というのももしかしたら手なのかもしれない。今回のお客様は、大手上場企業。かなりのリスク分析を経た上での結論のはずである。なるほど、と目から鱗の思いであった。

　とはいえ、流石に「一気に平文禁止」というわけにもいかず、しばらくはいまの運用するとしても、将来、リスクの要素を減らす一つのオプションであることは間違い無いだろう。それでも抜け道は出てくるのだろうが。

　今は、年に数回、IT担当者を集めた会議を設定しており、その席で、今回の顛末の説明を行った。

「今回、インターネットメールの送受信で、暗号化通信に対応しました」

　牛尾は続けて背景を述べる。

「インターネットメールは、送信にあたってはもともとは平文で、認証もありませんでした。認証や暗号化も議論はされていましたが、そもそも必要とされていませんでした。しかしながら、これだけインターネットが普及し、クラッカーと呼ばれる悪意ある利用者が、いたずらや、まぁそれだけならまだいいかもしれませんが、サーバをダウンさせたり、のっとったり、果ては脅迫材料に使ったりと悪用をするために、虎視眈々と狙っているような状況である現在、自衛のためには認証・暗号化は避けられない時代になって来た、ということです。もともと、認証も暗号化もなくてもつかえている中で、一気に移行をしてしまうと、不具合がどこからでるかわからないので、移行期間、というか並行運用期間を設けてソフトランディングさせるべきと考えられます」

　ユーザにはどこまで伝わるか、わからないが、議事録で残すという意図もあり、簡単なリスクの可能性についての説明を加えた。

「電子メールのコンピュータ間のセキュリティーについては、大きく分けて２つの考え方があります。先ほどから何度かすでに申し上げていますが、一つは、認められた人からの送信しか認めない、認証。もう一つは、通信途中での覗き見での情報遺漏を避けるための暗号化です。

　認証では、ウイルスを含む迷惑メールを受け付けないようにする方策としては有効です。

　皆さんも、個人のプロバイダのメール設定で、メール送信時に認証をする、という設定をしているのではないでしょうか？昔は、そもそもそのような仕組みもなく、誰でも送信ができました。その結果、悪い奴らが、迷惑メールをいくらでも送ることができたんです。どのIPアドレスからの送信かは記録には残りますが、そもそもIP spoofing、つまりIP偽装することで、匿名性はかなり高まりました」

　斎藤が手をあげる。

「要点を言ってくれ。関係あるのか？」

　牛尾は皆を見回しながら

「ご指摘の通り、今回の暗号化の件と、今お話している認証は直接関係はありません。しかし、今回の件も含め、『なぜそういう対策が必要なのか』を、この機会にトータルで理解いただくことは意味があると考えているます」

　別の参加者から声が上がる。

「早く進めて早くすませてよ」

　やはりユーザは、直接自分が困らなければ興味もなく、理解もしようとしないんだな、と思い知らされながらも、少しでも理解されるだけでもセキュリティリスクの軽減には大きな効果があると信じて続けた。

「失礼しました、できるだけ簡潔にしようとおもいます」

　と言いながら、予定通りの話をするつもりだ。

「えーと、認証がなければ、迷惑メールが発信しやすい、という話からでしたよね。ですので、『送る側の倫理』として、送るメールが本当に『正しいユーザによる発信なのか』を確認するのが認証です。サーバ間の通信では、IDパスワード認証は、あまり現実的ではないです。でも、メールサーバが由緒正しいことを確認することはできます。技術的な詳細は省きますが。

　いずれにしても、なんで面倒な設定が必要になったのか、、、その理由は、迷惑メール撲滅のため、と考えていただければ、ご納得いただけるのでは無いかと思います」

　斎藤が遮る。

「でも、迷惑メールは全然なくならないじゃ無いか」

　牛尾はすぐに反応。調子が出てきた。

「はい、元々の『限られた人だけの性善説での仕様』であるSMTPがベースになっていますから。今でもなりすましメールというのは可能なんですよ。認証していても、送信したい、というイベントを許可するだけで、実際のメールの送信者として表示される情報は、いくらでもいじることができるんです。信じられない人は、実際にやってみせますので、お声がけください。斎藤さんは覚えてますよね？私が社長の名前を騙って送信できることを実証してみせたこと。つまり、メールが誰からきたか、は、残念ながら疑ってかかるしか無いんですよ。こればかりはどうしようもありません。

　すべての仕様をスクラッチから設定し直せば、完全に撲滅も夢では無いでしょう。でも、すでに動いている中で、それを止めずに安全策を上に被せていく、という運用しかできない以上、ある程度は仕方がないのです。ハードルは上げますが、乗り越えられないわけでは無いので。それでも、無いよりはあった方が、リスクを減らせることは事実です。だからやるんです」

　田中が控えめに発言する。

「差出人って、信じられないんですか？そうなると、メールを使ってのビジネス自体が、根底から崩れるように思うんですが。。」

　当然の疑問ではあるが、明快な答えはない。

「おっしゃる懸念はわかります。ですので、繰り返し『メールは100%ではない』と、また『正しく怖がってください』と訴えさせていただいているわけです。リスクフリーはあり得ません。よく、危機管理の研修で、日本の問題点として、問題が起きた時の謝罪会見で『あってはならないこと』ということが槍玉に上げられますよね。あってはならない、はあり得ない。どんなリスクだって『ありうる』ということを、まずは受け止めることから始まります。

　ですので、メールでも、リスクの可能性と、その重要性を常に天秤に図るようにしてください。IT屋は、得られた情報全てを嘗め回して、真偽の判断をしますが、あまりそれはオススメしません。障壁が高いこともありますが、正直、ログとかも都合よく改竄できたりしますので。それよりも、アナログな方法が何より一番です」

　質問者の田中をはじめ、反応がないことを鑑み、牛尾は結論を急いだ。

「簡単な一手間で、ほぼリスクフリーを実現できるんです。まず、大事なメールは必ず裏をとること。例えば、お礼を伝える体で電話をかけて、さりげなく要点の確認をしてみてください。最近の若い人は、『メール送ったでしょ』といいますが、これってどうでしょうね？ひどい時は、隣の人に、メールで話しかけます。なんで首をちょっと右に向けて話しかけるだけのことができないのか、、私の部署では、声が届く範囲の人に、メールを送って送りっぱなしにするとペナルティー、というルールを設けています。メールは便利です。そのまま記録にもなりますし。でも、何より大事なのは、コミュニケーションです。メールだけでいいんですか？なによりも、信頼性が確保できないツールだけではダメです」

　斎藤が突っ込む。

「信頼性がないツールを記録に使うって、あり得んだろ」

　牛尾は答える。

「ここで、信頼性の問題が出た時は、情報システム部の出番ですから、遠慮なく相談にお越しください。まずは、皆さんが、裏を取られた、という前提でお話しします。その場合、そのメールを記録として用いた場合、もし、その真贋が議論になった場合は、ログの組み合わせで、正当性を証明するお手伝いをします。皆様には、まずは『メール一本でことが終わらない』ということをご理解いただければ結構です。

　繰り返しますが、メールは、確実なツールではないです。必ず届く保証はないですし、届いても、確実に内容が伝わる保証はありません。なりすましもあります。ですので、まず裏を取りましょう。電話確認って、電話するならメール不要でしょ？っていうひとがいますが、それが記録です。電話で時間の約束すると、必ずメモりますよね。であれば、メールで送る、電話で確認する。いままでと手間は変わりません。しかも、1時と7時、聞き間違え問題とかもありましたが、メールで、その可能性が激減するわけで、同じ手間でリスクが減る、と考えてください。

　確認電話しづらいケースももちろんあると思います。そんなときは、メールの返事だけはしてください。これだけでも、リスク軽減に効果がありますので」

　だいぶ横道に逸れたか。

　牛尾は話を元に戻す。

「すみません、話を戻しますね。

　認証については、必要性はおわかりいただけたと思います。

　では、もう一つのセキュリティー話題である、暗号化についてです。

　今一度、基本の原理原則の話を最初にさせてください。インターネットの通信は、不特定のサーバを経由して、目的のサーバまでたどり着きます。ですので、その間のサーバなどでは、データを見ることができます。もちろん、意図的に見ようとしたら、の話ですが、通信途中での覗き見が可能かどうか、ということを言えば、可能、ということになるわけです。意図的でなければ、と言いましたが、意図的、という言葉には、悪意の有無にはかかわりません。例えば、パケットの監視を行うことは普通に実施します。ウイルスや不正アクセスをキャッチして、それらによる影響を防ぐためです。安岩の社内ネットワークももちろん、全パケットを監視しています。ある特定のパターンを検出して、ウイルス感染などのリスクを防ぐためです。このようなツールでは、悪意がなくても、ログに通信の内容が記録される設定になっていることがほとんどですので、そこがセキュリティー上は好ましくないと言えるわけです。そのため、通信を暗号化することが求められたわけです。今回、あるお客様からの要請で、実装を急いだわけですが、実際にほとんどのビジネスメールは、すでに暗号化が実装されています。今回の設定変更により、従来の通信に影響が出ないように、十分配慮はいたしますが、何か違和感等、感じられる場合はご連絡ください。基本的には皆様には、何も考えずにご利用いただいて差し支えありません。本日のアナウンスは、あくまでも、皆様に見えない部分で、設定変更がされたことをお知らせする意図です。その設定が、時代の流れで普遍的な設定であることをご理解いただければ結構です」

　斎藤がまた横槍を入れる。

「送る時に、暗号化をするように選べないんだろ。それじゃ意味がないだろうが」

　牛尾は丁寧に、を心がけて返答する。

「選ぶことはできません。あくまでも、お客様のポリシー次第です。暗号化をされていない相手先があれば、平文で送ります。逆に、お客様ポリシーで、平文を一切受け付けない設定にしているところがあり、それが今回設定を急いだ背景なのです」

　斎藤は食い下がる。

「全部暗号化すればいいじゃないか。メールソフトには暗号化機能があるんだから、通信の途中を、人任せで暗号化しても、確実じゃないだろ。最初から暗号化しておく方がいいに決まっているじゃないか」

　牛尾は、どうすれば引き下がるか、を考えたが、妙案はなく、直球勝負で

「今のインターネット常時接続に移行する時に、何度か説明会でご説明したことがありますが、インターネットは互助組織みたいなもので、一定のルール決めはしているものの、実装方法の違いとかにより、通信に不具合が出ることがあります。暗号化もしかりです。送信者も受信者も、同じ環境であれば何も心配は要りません。しかし、相手の環境がわからないと、最悪、相手が暗号化メール非対応のメールソフトの可能性も否定できないわけです。となると、メール送信時に暗号化をする、という選択肢は、相手を考えない独りよがりの策、となってしまいます。今回のように、サーバ間通信で、暗号化が『可能であれば』暗号化を、そうでなければ従来通りの平文通信、という設定であれば、安全策が取れる時はとれる、ということで、世界中のユーザの皆さんに、なんら影響を与えず、ベストエフォートの安全策がとれる、ということになるわけです」

　牛尾はそこで、ふと思い出した。引き下がってもらうには、相手を立てること。すぐに

「ご指摘の通り、最大の安全は、送受信者の間で、暗号のプロトコルの同意をとって、暗号化して送ることです。実は、この仕組みを使うと、電子署名もできるんです。先ほど話した『なりすまし』も防げるんです。これが可能であれば、ぜひそのようにしてください。今回は、ご指摘の方法に比べると、リスクが高いのは事実です。そのなかで、できる範囲での安全確保努力をしました、ということだとご理解ください。スクラッチから設定できるのがベスト、と申し上げましたが、送受信側で同意をとった暗号化、というのは、その一つの方策と言えます」

　斎藤は鼻で笑いながら

「俺はとっくにそうしてるよ」

　牛尾はツッコミはせず、それを受けて

「暗号化は、今後も増えてきますが、基本的にはユーザの方が意識しないでもできるような環境を提供できるようにしていきたいと思います。

　ただ、関連して一つ、皆様にお願いがあります」

　終わると思って、ちょっとざわつき始めた会場が、再度静かになる。

「インターネットのWebでも、今回のメールと同じ暗号化が使われています。むしろ、そちらの方が皆さん、身近にかんじられていますよね、多分。アドレスにhttpsがついている時は、同様の暗号化が行われているんです。

　通常お使いになる時は、特に意識しなくても結構です。今では普通の検索サイトもhttpsですから。でも、今ではインターネットコマースをはじめとして、口座番号とか、重要な個人情報の入力を求めるサービスも増えています。くどいようですが、インターネットで100%の安全はありません。ですので、リスクがいやであれば、使わなければよい、ということです。実際、私自身は信用していないので使っていません」

　ちょっとざわつく会場。構わず牛尾は続ける。

「余り不要な心配はしなくてもよいでしょう。私が使わないのは、私がポリシーとして、どうしても受け入れられない部分がある、というだけで、私の問題で、httpsの問題ではありません。ただ、なんども申し上げている、『正しく怖がる』を思い出してください。正しい理解があれば、リスクがなにか、それに対してどのように対処されているか、を、まず理解する努力をお願いしたいのです。先ほど、ユーザの皆様が意識しなくても使える環境を、と申し上げていながらも、使う以上は安全性を確認することだけは、お使いになる皆様にお願いしなければならないことなのです。その一環で、ぜひ覚えておいていただきたいことがあります。

　皆さんはご自宅で、外出する時に鍵をかけますよね。庭に出る時、ベランダに出る時にはわざわざ鍵をかけたりしなくても、外出の時は一手間、施錠する作業を厭いませんよね。それと同じことを、インターネットに個人情報を流す時には、必ずやっていただきたいのです」

　会場はきょとんとしているが、かまわず

「前置きが長くなりましたが、こちらから情報を入力して送る時には、送るボタンを押す前に、必ず、『必ず』証明書の確認をする癖をつけてください。お使いの環境にもよりますが、大抵はアドレスの近くに、南京錠のアイコンがあります。httpだと、解錠アイコンですが、httpsだと施錠アイコンになっています。ここをクリックすると、証明書の内容が確認できます。

　なお、証明書があることが、信頼できる、ということではない、ということをご理解ください。よく、『httpsだから安心』という人がいますが、httpsにより確保されるのは、あくまで『通信上のデータの覗き見や改竄』です。でも、受け取った先が、悪意あるサイトであったら、途中経路をどうしようが、元も子もない、ということです」

　斎藤がすかさず

「そんなの、見たってわかんないだろ？何を信じていいのかなんて」

　牛尾は

「その通りです。それでもお願いしています。

　まず、httpsの認証の仕組みを、かなりざっくりですが、ご説明します。

　httpsのセッションの開始にあたり、まず、使用する暗号化のために、公開鍵が含まれた証明書を使います。その時に、この証明書が正しいかどうかを、ブラウザは確認してくれます。通常は、その時にアラートが出なければ、証明書の登録自体は正しいと考えていただいて結構です。

　通常出るエラーは、『認証局で素性を確認できない』か、『期限切れ』です。いずれのケースでも、基本的には信用すべきではありません。時折、ちゃんとしたサイトでも期限切れがあります。でも、これをスルーしてしまうなら、それこそ何を信じるべきか、わからなくなります。いわゆる『オレオレ証明書』と言われるものです。これは、通信途上は暗号化されていますが、そのデータを復号するのが、インチキの証明書を渡した悪い輩なので、意味がないです。

　つまり、httpsでのリスク回避策としては

　　証明書が正しいことを確認し、データを渡す先が正しいことを確保します

　　　ここには、証明書が公的認証されていることと

　　　登録申請した母体が、正しいだろうことを確認すること

　　その上で正しい証明書で暗号化し、送信途中での覗き見改竄を防ぐ

　ということになります。送信途上の暗号化は、まずは大丈夫です。問題は、証明書の素性ですね。

　証明書が正しい、って、どうやって確認したらよいか、が、先ほどお願いした手順です。

　まず、アラートが出ていないこと。これにより、正しい手順で登録されたと判断、と申し上げました。それを保証するのが、ルート認証局というものです。そこで登録されている証明書は、正しい手順で登録された、と信じていただいて構いません。

　ただし、ルート認証局は、登録要請に対して答えるもので、この保証というのは、『正しい手続きを経て登録されています』という保証にしかなりません。悪意ある組織が、登録申請しても、普通に通ります。

　ですので、次に、登録した母体が、本当にデータを渡そうとしている団体か、を確認します。実を言うと、ここだけは推定を入れるしかありません。通常は登録段階で、この『登録内容』をつかって郵便などでやり取りする過程で信用することになります。ですので、申請者の名前と住所。これを確認してみてください。これがリーズナブルであること、ここまでは必ず確認するようにしてください」

　斎藤が遮る。

「お前、そんなこといつもやってるのかよ」

　牛尾は即答する

「もちろんやっています。先ほど申し上げた通りで、ほんの一手間です。ただし、登録者の情報は、裏どりまでしませんけどね。本当にクリティカルなデータの時は、あらゆる情報から、証明書の正しさの確認をしますが、流石にそこまでするくらいなら、使わない方がよい、ということで、私は通常はインターネットコマースをしていない、と申し上げたわけです。でも、https自体、使うことは多くあり、こちらからデータを送る時は、必ず確認をしていますよ。

　斎藤さん、ありがとうございます、一つ大事なことを忘れていました。

　私がネットバンキングをやらない理由は、実は、ほとんどの銀行のサイトは、認証とかの際に、アドレスバーを隠した新しいウインドウを出してきます。つまり、今ご説明した『証明書が正しいかの確認』を『わざとさせない、させたくない』というスタンスなんです。そのため、これらが解消されなければ、私としては怖くて使いたくないんです。迷惑メールのフィッシングでも、銀行を装うものが多いのもうなづけます。この辺への対処は、また機会を見てやりたいと思います。

　実はそのほか、あるタブレット環境でも証明書確認ができない仕様だったりします。そのため、私からは、そういうタブレットで重要な情報を送信することは避けるようにしています。これは、私からの推奨でなく、私はそうしている、ってだけであり、ルールではありません。皆さんがご自身で判断してください。あくまで皆様の良心に委ねられるところです。是非、『正しく怖がり』適切な対応をお願いします」