先週、Japan.internet.comに、「HTMLメールのリスクとWebビーコン」というコラムが出ていた。これは、6月18日の日記の「ルートコミュニケーションズがやってくれるらしい」で、
として紹介した、「プライバシーについての配慮や取り組みについて、メディアやクライアントに説明できているつもりであったが、第三者から指摘されてそれが足りていなかったことに気づいた」とのことで、次の取り組みを進めているそうだ。
「HTMLメールマーケティングガイド」やInternet.com掲載のコラムに、新しい記事として、Webビーコン使用時のプライバシーポリシー記述に関するものを執筆する。
が実現したもののようだ。
内容を拝見すると、
まずは、HTML メールの効果測定を行う際に一般的にどのようなことが行われているか、もう一度確認してみましょう。
として、
図のような仕組みを用意すれば、どの ID を持ったメールが表示（＝開封）されて、どの ID を持ったメールが表示されなかったかを把握することができます。また、上図の f で cookie を発行する場合、これを追跡することで、ユーザーが会員登録した、購買行動を起こした、などの情報を取得することもできます。
というように、Webバグ（Web盗聴器）の仕組みが包み隠さず書かれている。
これまで、こうした追跡の可能性は、傍から見て、原理的にそのようなことが可能なはずで、やっているのではないか？ という疑いに過ぎなかったのだが、メールマガジン配送システムの構築に携わる当事者からこのような説明が出たことは、それがただの疑いではなく、事実であることをはっきりさせた。
また、コラムは、
Web ビーコンはマーケティング的にはきわめて強力な仕組みであり、うまく活用できればメールマーケティング効果を大きく向上できるものですが、その反面、自社顧客の意図を越えてプライバシーに踏み込んでしまう危険性もあります。
と続いている。
私としては、冒頭部分の、
ここ半年で HTML メールの導入事例は一気に増えました。しかし、その一方で送り手側がエンドユーザーにそのリスクを正しく伝えることができていない、または送り手自身それを認識していない、という現状を危ぶむ声も聞かれます。
という点が重要だと思う。
このコラムは次回に続くようなので、今後の展開に期待大だ。
22日の日記の「ドイツのネットバンキング事情」で、
この話を聞いて不思議に思ったのは、日本ではどうしてこう、まやかしの安全システムがまかり通って、ドイツではこうも確かな方法が選択されるのだろうか？ ということだ。どういう文化的相違からくるものなのだろうか。
と書いたが、これについて、山根さんの日記に反応があった。
私見では，ドイツでは第三者専門機関によるセキュリティ評価が義務づけられているからではないかと．たとえばこれは基幹システムの例だが， ドイツでは銀行間のネットワークに加入するにはEAL5が要件と法律で義務づけられている．
だそうだ。続いて、
日本の場合，金融ネットワークのセキュリティ基準を定めた法律はありません． (努力目標は定められていますが．) 国会で決める法律ではなく監督官庁による通達で指導を行うのが日本流です．
とある。
日本のネットバンキングの安全対策について文書化された基準らしきものは、私の知るところでは、日本銀行考査局が2000年4月に出した、「情報セキュリティ対策のチェックポイント ──インターネットを利用した金融サービスを中心に── 」と、財団法人金融情報システムセンターが発行している、「金融機関等コンピュータシステムの安全対策基準」くらいしか思い当たらない。
後者は入手していないので内容がわからない。前者については、「インターネット利用システムにおける情報セキュリティ対策のチェックポイント」という別添資料が付属しているのだが、技術面で挙げられているチェックポイントが、
という内容で、典型的な駄目パターンに陥っている。
インターネット利用システムにおける情報セキュリティ対策のチェックポイント IV．新たな情報セキュリティ対策のポイント
- ファイアウォール
(1)ファイアウォールの導入および運用に当たり、適切な対策を講じているか
(2)ファイアウォールのセキュリティホール等に関する情報を収集し、所要の対策を講じているか
(3)専門家等による侵入テストを実施するなど、ファイアウォールの信頼性を定期的に確認することが望ましい- 暗号
(1)機密性の高い情報を送受信する場合に、情報を暗号化しているか
(2)暗号の利用および管理において、適切な運用ルールを整備し、適切に運用しているか
(3)暗号を利用するに当たっては、適切なセキュリティ評価を行うことが望ましい
(4)公開鍵を使用する場合に、ペアとなる秘密鍵について適切に取り扱っているか- 電子署名
(1)高額な資金移動を伴うなどリスクが極めて大きな場合には、電子認証書等による利用者の認証を行っているか
(2)重要な情報を送受信する場合には、漏洩や改竄等を防止するため、電子署名を利用することが望ましい
(3)独自にＣＡ局（Certification Authority：認証局）を運営する場合には、運営方法に関するルールを整備し、ルールに沿って適切に運用しているか- 業務妨害対策
(1)サーバをダウンさせる目的で短期間にシステムの許容量を超えるアクセスを集中する攻撃を想定し、代替的な業務遂行策を立てているか
(2)組織全体としてウィルス検知体制や同対策に関する運用ルールを整備し、適切に運用しているか
重要なのは、22日の日記に書いた乱数表の使い方の事例のように、個別に設計されたシステムの安全性評価であるが、上の基準では、「セキュリティホール等に関する情報を収集」や「専門家等による侵入テスト」が、ファイアウォールのところに分類されてしまっていることからして、そのことが認識されていないことがわかる。
ただ、これが書かれたのが2000年という、ちょうど日本の省庁でWebサイト改竄事件が連続発生したころで、インターネットを利用したサービスの脅威がようやく世に認識され始めたばかりのときであるから、この程度の脅威しか想像できなかったのもやむを得ないことだとは思う。
しかし、このような、「インターネットのセキュリティと言えば、ファイアウォールと、暗号/署名、そしてウイルス対策だ」で満足してしまうパターンは、今も根強く残っている。
例えば、村岡先生のところで行われていたという「平成14年度 セキュリティ技術者養成センター 実施計画」のシラバスを見てみても、
・情報セキュリティとは
・個人情報保護法と不正アクセス防止法 （※正しくは「禁止法」）
・暗号化技術
・ネットワーク高信頼化技術
・ウィルスとは
・ファイァウォール技術
・その他
・実験・実習： ウィルス検知、ファイァウォール設定、ログ解析など ・暗号技術
・個人認証
・PKI
・ディジタル署名
・ファイァウォール
・Kerberos ・ウィルス
・ログ解析（不正侵入検知）
・セキュァOS
・セキュァネットワーク
・セキュァアーキテクチャ
・その他
という構成になっていて、欠陥の存在への対応や、欠陥を作らない開発という視点が欠けているように見える。（「セキュア○○」のところに含まれているのかもしれないが。）
このような、ステレオタイプ化した「セキュリティ対策」のイメージは、都市伝説のごとくはびこっていて、払拭するのがとても大変だ。ひとつひとつ欠陥事例をおおやけにして、欠陥がそこらじゅうに存在するのだという現実を認識していただくしかないだろう。
ところで、EAL5のような「Common Criteria」で解決するのかということを考えたとき、いまひとつ希望が持てないのは、コストと時間がかかりすぎて敬遠されるのではないかということと、本当に例えば「乱数表をログイン時に使う」という脆弱点を指摘できるのだろうかという疑問だ。ISO 15408には、具体的なセキュリティ対策項目がリストアップされているわけではないと聞く。
日本では政府系のガイドラインが多数ある。
日本にはこうしたガイドラインの方が向いているという気もしないでもない。しかし、このように既存のものは、5年〜15年も前のもので、あまりに古びている。今日の、インターネットで、サービス提供者とユーザとが直接対面するシステムには、対応できていないだろう。