「S/MIME導入でメールは安心だね」と聞かれたら？


	エンジニアたるもの、新技術を導入したいのは山々だけれど、もちろんそれは“使うツボ”を押さえてこそ。単に「はやってるんだから、アレやってよ！」と言われては困ってしまう。というわけで、顧客や営業の生半可な質問や注文への「切り返し方」を考えてみる短期集中連載。第2回は、メールやWebサイトなどの「セキュリティ」を取り上げます。（文／川畑英毅　総研スタッフ／根村かやの　イラスト／岡田丈）　作成日:05.11.02

　便利さの陰に落とし穴あり！――IT機器、ネットワークは便利なものだけれど、その半面、サイバー攻撃や情報漏れの危険もつきまとう。さらには個人情報保護が厳しく問われる世の中、「セキュリティ技術」の重要性はますます高まっている。

「セキュリティは緊急の課題！」という危機意識は、ユーザーにも当然もっていてほしい。しかし、だからといって、どこかで聞きつけた新技術を中身もわからずに「特効薬」のように思ったり、逆に「アレはダメなんじゃ？」と生半可な知識で判断されたのでは困りもの。

　使うツボを押さえなければ、せっかくの新技術も生かせない。そこはエンジニアたるもの、顧客や営業が「なるほど」と思える説明をするのも、大事なスキルのうち。というわけで、第2回は「セキュリティ技術編」。
　顧客や自社の他部門からの、「ありがちな質問」と、それに対して当編集部からの「例えばこんなお答えはいかが？」のヒントを、株式会社インターネットイニシアティブ技術本部技術開発部主任・櫻庭秀次氏の監修で、組み立ててみました。

インターネット上の情報のやりとりのセキュリティを向上させるPKI（Public Key Infrastructure：公開鍵基盤）。しかしS/MIMEやSSL・TLSを「導入したらそれでOK」ではなく、継続した努力が必要というアドバイスは忘れずに。

顧客の管理係長

　セキュリティ向上のためにS/MIMEやSSLを導入しろって、上に言われているんだけど、そもそもそれって何？

エンジニア

　S/MIMEもSSLも、インターネット上の情報のセキュリティを高める「PKI」と呼ばれる技術を利用したもの。これには、「発信者が本当にその人か」を証明すること、そして暗号化によって情報を守ることの、2つの側面があります。
　S/MIMEはメールを送る側で暗号化と署名・認証を行います。送受信する双方が対応している必要がありますが、「Outlook」や「Netscape Messenger」などの代表的なメールソフトがS/MIMEに対応しているので、それらを使って受信側はメールの署名を確認することができます。最近では、例えば(株)武富士がフィッシングを防ぐため、社員の発信するメールをすべてS/MIME対応の電子署名付きにするなど、セキュリティと信頼性の向上のために利用する例が増えてきています。
　一方、SSLはWebブラウザとWebサーバー間やWebサーバー同士、あるいはメールサーバー間の通信などで暗号化と認証を行うもので、eコマースサイトなどで一般的に利用されています。SSLは、その後の改良で、現在はTLSという名前で、インターネット関連の国際組織、IETFで標準化されています。

管理係長

　なんだか難しいけれど、セキュリティが向上するってことはわかった。導入すれば安心だね。

エンジニア

　いえ、それだけでは……。
　PKIの技術では、「認証局」と呼ばれる第三者機関が発信者の「身元」を保証する電子証明書を発行。この証明書に組み込まれた「公開鍵」と、発信者の持つ「秘密鍵」とを組み合わせて、双方向の情報の暗号化が行えます。
　自ら認証局を立てるアプリもありますが、もちろん、それでは例えば外のお客さまに出すメールの信頼性向上にはつながりません。一般に認知度が高く、信頼されている外部の「認証局」を利用するのが普通です。認証局を運営する企業と契約して、「身元についての問い合わせがあったとき、証明書を発行してもらう」というサービスを買うわけですね。
　しかし、この契約期間の更新を忘れたりすると、「身元不明です」という返事でかえってお客さまの信頼を損ねる、といった結果にもなりかねません。ですから、いったん導入したらもう大丈夫、というわけではありません。
　いずれにせよ、セキュリティは、継続して取り組んでいかなければならない問題。その体制づくりも含めて、ご相談に乗りますよ。

PGP（Pretty Good Privacy）はPKI同様に暗号化を行うが、全員があらかじめ公開鍵を持っている必要があるので、「閉じたグループ内」での情報のやりとり向け。

顧客の製造部門担当者

　仕様や設計のデータを関係部署内や協力会社さんに送るのに、そのままでは不安。通信を安全にするには「PGP」を使えばって、知ってる技術者に言われたんだけど……。

エンジニア

　暗号化というと、S/MIMEやSSLなど、「PKI」の技術が広く使われていますけれど、これは情報を暗号化するとともに、認証局という「第三者機関」が発信者の正当性を保証します。認証局が出す証明書に鍵が組み込まれているんです。
　PGPの場合は情報を送り受けするメンバーが、あらかじめ鍵を持ち合っていて、暗号化を行います。ですから、認証局という第三者的存在がありません。それぞれにメリット、デメリットがあるんですよ。

顧客の製造部門担当者

　その認証局っていう第三者機関があるかないかで、何が違うワケ？

エンジニア

　だれもがその認証局に（電子的に）問い合わせて、送り手の正当性を確かめられるのがPKIの特徴。ですから、PKIは、不特定多数との通信に向いていると言っていいと思います。
　でも、限られたメンバーの間だけで情報をやりとりし、特に送り手の正当性を問う必要がなく、暗号化だけを行いたい場合には、PGPが簡単。PKIでは外部の認証局を利用するにしろ、自分でそれを構築するにしろ、手間やコストがかかりますからね。
　情報をやりとりする相手が少数で固定されているのか、ある程度流動的なのかによって、PGPが適しているかどうか違ってきます。その点を明確にしていただければ、適切なシステムの提案をしましょう！

受信するスパムの数を減らす即効性はなくとも、発信するメールがスパムと紛れないため、また、企業の社会的責任を果たすために、導入すべきという意義を強調したい。

総務課担当者

　ウチのメールにスパム対策として「Sender ID」を入れるそうだけど、それでウチにくるスパムが減るの？　あれって効かないって話だけど。

社内エンジニア

　まず言っておきたいのは、「Sender ID」はウチにくるスパムを減らす技術ではなくて、こちらから出すメールの正当性を証明することで、メールというもの自体の信頼性を上げるものなんだよ。

「Sender ID」は、発信者のドメインが「正しい」かどうかを示すもの。受け手が「Sender ID」を使ってフィルタリングしても、スパムが正規のドメインから発信されていれば、通してしまう。また、「Sender ID」のもとになった「SPF」では、「正しい」メールでも、転送されると認証に失敗することがあった。「Sender ID」では、ヘッダーに正しく情報を記述すれば技術的には転送時にも認証可能なんだけれど、必ずうまくいくという保証はないんだ。そういう意味では、「Sender ID」には弱点があるんだよね。
　メールの正当性を証明する技術として「Sender ID」と双璧をなすのが「DKIM」で、これは、送信のたびにメールヘッダーに“電子署名”を埋め込む方式。上記の弱点はない。

総務課担当者

　それなら、「Sender ID」より「DKIM」にしたほうがいいんじゃない？

社内エンジニア

　ただ、送り主を偽装したメールが偽装された送り主に戻ってくる「エラーメール」は、「Sender ID」のようにドメインを認証する方式で防げるんだ。フィッシング詐欺のメールも、ほとんどが送信者アドレスを詐称しているから、その場合も有効。それに、特定のドメインがスパムをたくさん発信しているとか、そんなブラックリスト化が進めば、ドメイン認証も力を発揮するんだよ。
　しかも、「Sender ID」は送信者側がDNSに送信ホスト情報を付加するだけなので、比較的簡単に導入できる。一方「DKIM」は、電子署名を生成させるため、メールサーバー（MTA）に対する開発やプラグインのインストールが必要だから、それなりに負荷もコストもかかる。銀行系やeコマースサイトのようなところなら、「DKIM」でしっかり署名ベースの認証を行うべきだろうけれど、ウチならまず「Sender ID」から始めるのがいいと思う。

フィッシングはこれからますます深刻化しそう。情報の送り手が「正しい」ことを証明するだけでなく、「簡単にマネをされない」体制をとる責任があることを、しっかり解説したい。

顧客の販売課長

　顧客管理上、メールで連絡をしたら、正規のメールなのにフィッシングと間違われた。どうにかしてくれ！

エンジニア

　フィッシングかそうでないかを受け手がちゃんと判断できる環境を整えるのも企業の責任ですよ。メールなら、「必ず御社からであることが確認できる」ことが必要。そのためには、電子署名を導入することも方法のひとつです。また、だます手段を埋め込みやすいHTMLメールは、普段からユーザーへのメール形式としては使わず、それをユーザー側にもきちんと通知するなども考える必要があります。

販売課長

「ウチからは怪しいメールは出していません」って言うだけじゃだめなの？

エンジニア

　もちろんダメ。御社から出していなくても、“フィッシャー”がユーザーをだますメールを出す危険性はいつでもありますし、一度信用を失ったら、取り戻すのは大変！　御社自体が、そういう隙を作らないように注意する必要があります。

販売課長

　わかった。でも、いくら注意しても、ウチにそっくりのWebページを作られて、そこに誘導されたら怖いなあ。

エンジニア

　もちろん、SSLなどで御社のページの正当性を証明できることは大切。それだけでなく、本物と紛らわしいドメイン名で「ひっかける」のがフィッシャーの手なのですから、「わが社は○○.comというドメイン名で、それ以外に○○-**.comといった名前を使うことはありません」といった認知を高めることも、ますます重要になっています。
　そういった戦略が定まっていてこそ、最新の技術も威力を発揮するんですよ。

確かにシンクライアントなら、個々のクライアントは単なる「出入力装置」なので、情報管理は万全。とはいえ、クライアントの機能は最低限なので、使い勝手は悪くなりがちだし、システム再構築のコストもかかることを理解してもらおう。

顧客の営業課長

　メンバーそれぞれが使っているクライアントのデータが、しっかり管理されているかどうか心配。「シンクライアント」ならデータが漏れることはないそうだけど、どうなの？

エンジニア

　もともと、クライアント・サーバー・モデルでは、サーバーとクライアントが処理を分け合っているわけですが、データ管理からアプリケーションそのものまでサーバー側に受け持たせて、クライアントにはほとんど出入力の機能しかもたせないのが「サーバー・ベース・コンピューティング」という考え方。これこれなら、システム管理も、情報管理も楽になりますよね。
　その考え方に立って、そもそもハードディスクもなく、出入力の機能しかもっていない――つまり機能的にも外見的にも「薄っぺら（シン）」くした端末が、シンクライアントなんです。

営業課長

　それなら情報はサーバー側ですべて管理しているわけだから、セキュリティ的にも万全だね。ウチでもできるかな？

エンジニア

　ただ、シンクライアントは最低限の機能しかもっていないわけですから、そのぶん、使い勝手は悪くなります。全員が決まったアプリケーションを、決まった場所で使う、という場合はいいんですが、担当者ごとに特別な処理をクライアント側で行いたいといったニーズがある場合には、適しません。
　しかも、システム全体を組み直すわけですから、相応の手間とコストもかかりますし、組織全体での検討が必要ですよ。

営業課長

　うーん、そうなると仕事の体制も変える必要があるか……。

エンジニア

　システム管理の効率化よりも、データ漏洩の防衛策が第一ということであれば、シンクライアント化ではなくて、例えば皆さんがお使いのマシンのHDを暗号化する、といった方法もあります。御社の業務のスタイルも踏まえたうえで、そういった方法も含めて検討してみましょう。　　