|
８月に入り、IPA や
METI
からいろいろ勧告が出ていますが、
その前に、Cookie 自体のお話をします。
そもそも Cookie とは、サーバからブラウザへ、
サーバ側の識別子や有効期間などと共にある任意の文字列を書き込み、
サーバが閲覧・修正できる機能だと思います。
一応仕様により、サーバ側が設定した識別子(ドメイン名・ホスト名)によるアクセス制限で、
第三者(他のドメイン・ホスト)からは閲覧・修正できないようになっているかと思います。
もともと Cookie 自体はブラウザなどのアプリケーションを識別するものであり、
直接的に個人情報を収集・利用するものではないと思います。
ただ、ID／パスワードなど、別の情報とマッピングされれば
“代理的に”ユーザ認証を行うことになります。
よって、Cookie 情報と個人情報を間接的に 結びつけることができれば、
Cookie 自体も個人情報として扱わなければならないと考えます。
個人情報保護法 では、
個人情報を構成する個々の情報を「個人データ」と別に定義されているようです。
だから、正確には、Cookie は「個人データ」の範疇に入るでしょう。
また、プライバシーマーク制度上では、
Cookie や１ピクセル画像なども含めた
いわゆる“ウェブバグ(ウェブビーコン)”の使用は制限していませんが、
これらウェブバグを使用する場合には、個人情報とのリンクの有無に関わらず、
個人情報保護方針、またはウェブサーバのプライバシーポリシーにその旨を記述し、
消費者に事前の告知と同意が必要となるかと思います。
消費者の間では、Cookie は個人情報と考えて、
使用を OFF にする場合もあるので、
個人情報とリンクさせない場合でも、使用しない場合の不利益など、
個人情報保護方針の安全管理に関する項目、またはウェブサーバのポリシーに
掲載すべきことであると考えます。
ページのコンテンツを見る前に、
Cookie などのウェブバグを取得されてしまう場合も多いかと思いますので、
なかなか“事前に”同意させることは難しいかと思います。
そういう意味でも、個人情報保護方針やプライバシーポリシーのページへのリンクなど、
“閲覧しやすい措置”を取らなければならないかと思います。
１ピクセルや空白の画像データを使用したウェブバグ(ウェブビーコン)については、
現時点では HTML メールがまだ主流のようですが、
事業者としては、以前の Cookie 同様、
アフィリエイト広告 などウェブの視聴率的に、
重要な技術かもしれません。
消費者の立場でアフィリエイト広告を考えると、
割引や特典などのために「どこのサイトからリンクで来た」
というのは消費者のベネフィットにもなるかと思うので、
消費者の中には、個人情報として、まだまだ気にしてない方も多いようです。
しかし、近い将来 Cookie 同様に消費者の認知度が高まってくれば、
メーラーやブラウザ側で対策が取られるようになるかもしれません。
その時には“事前に”同意を求めるなどの工夫が必要になってくるかもしれません。
※その内 Cookie 同様、他のサイトの画像データを表示するための ON/OFF
機能が付くでしょうし．．．
さて、最初の話のセキュリティ的なことですが、
そもそもどれくらい盗聴されうるか、というのは個人的にはよくわかりません。
ニュースや噂話でも聞いたことはありませんが、
例えば、サイトのネットワーク管理者やプロキシーサーバなど、
まったく盗聴されないとは言い切れない部分もあります。
「/secure モード」で Cookie を SSL 化すれば大丈夫かという話でもなく、
「日付＋時刻」など、簡単に推測されうるセッションキーを使っていれば、
SSL をしていても、簡単になりすまされる可能性も大きいかと思います。
個人的には、どちらかというと、
IPA や
METI
の勧告にある「/secure モード」よりも、
簡単なセッションキーで成り済まされるリスクの方が高いようにも思います。
併せて、タイムアウトを不必要に長くとらず、
例え Cookie 情報がなりすまされたり、
ブルートフォース的に攻撃された場合でも、
漏えいのリスクを少なくする対処も必要であるかと思います。
セッションキーのランダム性が高ければ、
SSL で暗号しなくてもいいというわけではありません。
多重にセキュリティをかければ、安全性は増すはずです。
最近では、申請から24時間以内に、３〜４万円で
SSL サーバ証明書が取得できるようですから、
導入は容易であるかと思います。
というわけで、パスワードなどの認証情報を Cookie で扱う場合には、
以下のような確認をした方がいいかと思います。
- ID(キー) のランダム性を高くする(ハッシュ、パディング、...)
- 有効期限(タイムアウト)を可能な限り短くする
- Cookie のサーバ名やドメイン、path を適切に設定する
- 極力 SSL で使うようにする
本当は「/secure モード」での使用が望ましいのですが、
コードの修正や「http://」と「https://」とでサーバを分けるなど、
すぐには対処できないことも多いかと思いますが、
少なくとも“残存リスク”として認識し、
移行計画を進めるなどの対策は取り始めるべきでしょう。
|