<前の日記(2003年07月22日) 次の日記(2003年07月26日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2592   昨日: 1295

2003年07月25日

HTMLメールのリスクとWebビーコン

先週、Japan.internet.comに、「HTMLメールのリスクとWebビーコン」というコラムが出ていた。これは、6月18日の日記の「ルートコミュニケーションズがやってくれるらしい」で、

「プライバシーについての配慮や取り組みについて、メディアやクライアントに説明できているつもりであったが、第三者から指摘されてそれが足りていなかったことに気づいた」とのことで、次の取り組みを進めているそうだ。

として紹介した、
「HTMLメールマーケティングガイド」やInternet.com掲載のコラムに、新しい記事として、Webビーコン使用時のプライバシーポリシー記述に関するものを執筆する。

が実現したもののようだ。

内容を拝見すると、

まずは、HTML メールの効果測定を行う際に一般的にどのようなことが行われているか、もう一度確認してみましょう。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

として、

図のような仕組みを用意すれば、どの ID を持ったメールが表示(=開封)されて、どの ID を持ったメールが表示されなかったかを把握することができます。また、上図の f で cookie を発行する場合、これを追跡することで、ユーザーが会員登録した、購買行動を起こした、などの情報を取得することもできます。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

というように、Webバグ(Web盗聴器)の仕組みが包み隠さず書かれている。

これまで、こうした追跡の可能性は、傍から見て、原理的にそのようなことが可能なはずで、やっているのではないか? という疑いに過ぎなかったのだが、メールマガジン配送システムの構築に携わる当事者からこのような説明が出たことは、それがただの疑いではなく、事実であることをはっきりさせた。

また、コラムは、

Web ビーコンはマーケティング的にはきわめて強力な仕組みであり、うまく活用できればメールマーケティング効果を大きく向上できるものですが、その反面、自社顧客の意図を越えてプライバシーに踏み込んでしまう危険性もあります。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

と続いている。

私としては、冒頭部分の、

ここ半年で HTML メールの導入事例は一気に増えました。しかし、その一方で送り手側がエンドユーザーにそのリスクを正しく伝えることができていない、または送り手自身それを認識していない、という現状を危ぶむ声も聞かれます。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

という点が重要だと思う。

このコラムは次回に続くようなので、今後の展開に期待大だ。

日本の銀行には安全基準がない?

22日の日記の「ドイツのネットバンキング事情」で、

この話を聞いて不思議に思ったのは、日本ではどうしてこう、まやかしの安全システムがまかり通って、ドイツではこうも確かな方法が選択されるのだろうか? ということだ。どういう文化的相違からくるものなのだろうか。

と書いたが、これについて、山根さんの日記に反応があった。

私見では,ドイツでは第三者専門機関によるセキュリティ評価が義務づけられているからではないかと.たとえばこれは基幹システムの例だが, ドイツでは銀行間のネットワークに加入するにはEAL5が要件と法律で義務づけられている.

だそうだ。続いて、

日本の場合,金融ネットワークのセキュリティ基準を定めた法律はありません. (努力目標は定められていますが.) 国会で決める法律ではなく監督官庁による通達で指導を行うのが日本流です.

とある。

日本のネットバンキングの安全対策について文書化された基準らしきものは、私の知るところでは、日本銀行考査局が2000年4月に出した、「情報セキュリティ対策のチェックポイント ──インターネットを利用した金融サービスを中心に── 」と、財団法人金融情報システムセンターが発行している、「金融機関等コンピュータシステムの安全対策基準」くらいしか思い当たらない。

後者は入手していないので内容がわからない。前者については、「インターネット利用システムにおける情報セキュリティ対策のチェックポイント」という別添資料が付属しているのだが、技術面で挙げられているチェックポイントが、

  1. ファイアウォール
    (1)ファイアウォールの導入および運用に当たり、適切な対策を講じているか
    (2)ファイアウォールのセキュリティホール等に関する情報を収集し、所要の対策を講じているか
    (3)専門家等による侵入テストを実施するなど、ファイアウォールの信頼性を定期的に確認することが望ましい
  2. 暗号
    (1)機密性の高い情報を送受信する場合に、情報を暗号化しているか
    (2)暗号の利用および管理において、適切な運用ルールを整備し、適切に運用しているか
    (3)暗号を利用するに当たっては、適切なセキュリティ評価を行うことが望ましい
    (4)公開鍵を使用する場合に、ペアとなる秘密鍵について適切に取り扱っているか
  3. 電子署名
    (1)高額な資金移動を伴うなどリスクが極めて大きな場合には、電子認証書等による利用者の認証を行っているか
    (2)重要な情報を送受信する場合には、漏洩や改竄等を防止するため、電子署名を利用することが望ましい
    (3)独自にCA局(Certification Authority:認証局)を運営する場合には、運営方法に関するルールを整備し、ルールに沿って適切に運用しているか
  4. 業務妨害対策
    (1)サーバをダウンさせる目的で短期間にシステムの許容量を超えるアクセスを集中する攻撃を想定し、代替的な業務遂行策を立てているか
    (2)組織全体としてウィルス検知体制や同対策に関する運用ルールを整備し、適切に運用しているか
インターネット利用システムにおける情報セキュリティ対策のチェックポイント IV.新たな情報セキュリティ対策のポイント
という内容で、典型的な駄目パターンに陥っている。

重要なのは、22日の日記に書いた乱数表の使い方の事例のように、個別に設計されたシステムの安全性評価であるが、上の基準では、「セキュリティホール等に関する情報を収集」や「専門家等による侵入テスト」が、ファイアウォールのところに分類されてしまっていることからして、そのことが認識されていないことがわかる。

ただ、これが書かれたのが2000年という、ちょうど日本の省庁でWebサイト改竄事件が連続発生したころで、インターネットを利用したサービスの脅威がようやく世に認識され始めたばかりのときであるから、この程度の脅威しか想像できなかったのもやむを得ないことだとは思う。

しかし、このような、「インターネットのセキュリティと言えば、ファイアウォールと、暗号/署名、そしてウイルス対策だ」で満足してしまうパターンは、今も根強く残っている。

例えば、村岡先生のところで行われていたという「平成14年度 セキュリティ技術者養成センター 実施計画」のシラバスを見てみても、

・情報セキュリティとは
・個人情報保護法と不正アクセス防止法 (※正しくは「禁止法」)
・暗号化技術
・ネットワーク高信頼化技術
・ウィルスとは
・ファイァウォール技術
・その他
・実験・実習: ウィルス検知、ファイァウォール設定、ログ解析など ・暗号技術
・個人認証
・PKI
・ディジタル署名
・ファイァウォール
・Kerberos
・ウィルス
・ログ解析(不正侵入検知)
・セキュァOS
・セキュァネットワーク
・セキュァアーキテクチャ
・その他

という構成になっていて、欠陥の存在への対応や、欠陥を作らない開発という視点が欠けているように見える。(「セキュア○○」のところに含まれているのかもしれないが。)

このような、ステレオタイプ化した「セキュリティ対策」のイメージは、都市伝説のごとくはびこっていて、払拭するのがとても大変だ。ひとつひとつ欠陥事例をおおやけにして、欠陥がそこらじゅうに存在するのだという現実を認識していただくしかないだろう。

ところで、EAL5のような「Common Criteria」で解決するのかということを考えたとき、いまひとつ希望が持てないのは、コストと時間がかかりすぎて敬遠されるのではないかということと、本当に例えば「乱数表をログイン時に使う」という脆弱点を指摘できるのだろうかという疑問だ。ISO 15408には、具体的なセキュリティ対策項目がリストアップされているわけではないと聞く。

日本では政府系のガイドラインが多数ある。

日本にはこうしたガイドラインの方が向いているという気もしないでもない。しかし、このように既存のものは、5年〜15年も前のもので、あまりに古びている。今日の、インターネットで、サービス提供者とユーザとが直接対面するシステムには、対応できていないだろう。

検索

<前の日記(2003年07月22日) 次の日記(2003年07月26日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2003年07月22日) 次の日記(2003年07月26日)> 最新 編集