GUiLZ Project Personal & Experimental Blog

過去記事

はてなダイアリー時代の過去記事

■ [その他] バースデーの俺

ファッキンバースデー俺! ウツダシノウ! ウツダシノウ!(男気溢れる声でお読み下さい)

そんなこんなでまた一つ年を取ることになりまして鬱な私ですが、皆様いかがお過ごしでしょうか。ちなみに「みどりの日」は来年から「昭和の日」になるそうですよ。つまりアレですか、この日に産まれた人間は産まれながらにレガシー(旧世代の遺物) 扱いってことですか? 平成生まれでも誕生日は昭和。どこのダブルスタンダードだそりゃ(くりゅえるは頭が錯乱しています)。

あー、ちなみに自分は昭和生まれなので昭和の日でも問題はないんですが(何に?)、みどりの日じゃなくなるのはちょっと寂しい気もしますね。……って、今年入って2回目の日記がこんな内容だけというのもアレなので、ちょっとしたネタを交えつつ少し。

■ひとつめ。

この低頻度更新ですから、読む人なんて最近いないし困らないと思うので、閉鎖した方がいいのかなー、とか考えてたり。理由はというと、

某ゲームメーカーに落ちたから

とか、

しかも履歴書にこの日記URIを書いてしまったから

なんて理由だったりはしません。ええ、多分、きっと。

……内容的には落ちて当然だったと自分でも思うが、この日記のURIまで書くんじゃなかったな……。あのときの俺はどうかしていたんだ、ママン。

■ふたつめ。

今さらながらSLAXがアツい。ここ数日、某所でお勤めしていたときに作ったLinuxファイルサーバーのシステムがお亡くなりになったとヘルプを頼まれたので、どうせならシステムをCDブートで作れば、データ用HDDはともかくシステムは安心だよなーって考えて、それを実行していたり。

SLAXのServer Edition日本語版を落としてきて、それにSambaモジュールを追加し(ServerなのにSambaが入ってないってのは、多分外向けサービスが主目的だからなんだろう)、向こうの環境に合わせて /rootcopy にファイル追加して、実機で変更したファイルはモジュール形式で保存し、/modules に追加してCDを焼き直せばOKと、楽しいし簡単。

ただ、自分で作ったのにどんな構成だったか思い出せなかったせいで、結構時間は取られたけども。今回はVMWareのおかけで大助かり。いやあ、仮想マシンは偉大だなあ。あとは今動かしている自分のサーバーもこれにしたいけど、ちょっと特殊な設定で動いてるから難しいかな。いざとなれば同じSlackwareだから、パッケージ作ってモジュールにコンバートすればいいけど。

……ということで、毒にも薬にもならない日記をお送りしました。で、その某ゲームメーカーに落ちたシナリオやゲーム風ノベル(落ちた=駄作ですけどね) は、そのままの形じゃないにしろ公開します。非常に恥ずかしいけどな(自分でもダメダメと思ってるものだし)。

恥ずかしいならやめろと思われるでしょうが、ネタのためですから!! ネタのためなら親でも茹でると語ったのはG=ヒコロウ先生ですが、激しく同感ですよ!!

……ただし、ここじゃなくて、もう一つ持ってる別ブログでね☆(オイ)

だってここは一応ネタと技術系話の場であってー。もう一つの方は小説ネタとか文章ネタの場として作ってるからー。やっぱり、カラーは使い分けないとね? ということで、興味ある人はいないでしょうけど、ゲームメーカーに送って落ちるシナリオはどういうものなのか、見てみたい人は探してください(笑)。公開したら一応こちらでも告知します。

あ、ちなみに応募したのは、えっちなゲームを作っている大人のメーカーさんです。昔から好きなメーカーさんだったんですが、まあ好きなだけでは届かないものも多いですよね、ということで。

■ [考察] 楽天ポイント問題について考える

ここ最近話題となっている楽天ポイント問題。その経緯は各所で述べられているため、詳細は省くが、下記のような状況であるらしい。

楽天がポイントプレゼントキャンペーンで約3000p取得可能に

(ポイントはお金と同価値で利用できる)

但し、条件に該当しない人は対象外。だが!誰でも取れた。

複数のアカウントを作って、アカウントx3000p(円)で買い物

(規約に複数アカウント禁止とは「書いてない」)

要するにポイント内の買い物を実質無料でできる。

100アカウントなら、300,000円分(但し、アカウント同士合算できない)

今回、不正に取得したポイントを無効にして

買い物した分は請求する発表がなされた。

(以上、Mixiコミュニティより転載)

Mixiでもこの問題に関するコミュニティができており、活況を呈しているが、この事例をどう考えるべきだろうか。

まずはユーザー。本来自分が得られないはずのポイントを得られたからといって、それを使用することはやはり正しいことではない。しかし、それが正しくないことだと知らずにポイントを得てしまったユーザーもおり(どうやら特価情報サイトに一時掲載されていたリンクからポイントを得たユーザーも多いらしい)、一概に責められない事情がある。もちろん、この機を逃すなと多数のIDを使って買い物をしたユーザーの行動は責められてしかるべきであろう。

次に楽天。一律これらポイントを一部でも得たことのある全ユーザーの獲得ポイントを抹消し、のちに正規ポイント取得者のみ回復するという発表と通告をした。しかし、それはこのポイント取得方法が広く知られるようになってから10日近くが過ぎた後に為されたことであり、対応の遅れを指摘されても仕方がない。また、そもそも特定の資格者のみに配布するポイントであるなら、何らかの認証手段を用いてアクセス制限をするのが当然であり、システム面での不備もあった。

これらを踏まえて、今回楽天は、それらポイントを取得したユーザーのポイント剥奪・支払い請求という行動に踏み切ったわけだが、その行動自体の賛否や正当性についての議論もあるだろう。しかしこの考察では、楽天が正当にポイントを受け取ったとするユーザーと、不当に受け取ったとされるユーザーをどのように振り分けるのか、それを考えてみたい。

楽天はこのようなルールで正・不正を決定します、という基準が公開されていない以上、推測で書かざるを得ないが、現時点で既にポイント返却が行われているユーザーを見てみると、そのヒントが掴めるかもしれない。

現時点でポイントが戻ってきているユーザーは、

ANAマイレージカードを作成し、その会員番号と楽天ポイント通帳を楽天に登録し、ポイントを得たユーザー

であるようだ。調べていくうちに分かったのだが、今回の件で得られたポイントというのは、

・アクセスしてリンク先に飛べば、誰でもポイントを得られたもの

・ANAマイレージクラブの会員番号を登録する必要があったもの

・携帯からアクセスする必要があったもの

という3パターン存在したらしい。そのうち、ANAマイレージクラブの会員番号を用いて得られるポイントを取得していたかどうか、またその取得方法が正当なものであったかそうでないかが重要であったようだ。(ANAマイレージクラブの登録には住所などの登録が必須のため、本人確認が容易であるからと考えられる。楽天のIDは、取得だけなら住所記入の必要はない)

ANAマイレージクラブのポイント取得方法が正当なものかそうでないものか、と書いたが、このマイレージクラブの会員番号を利用しないと取得できないはずのポイントは、直接URLを入力することでマイレージクラブの会員番号を入力しなくても得られるものであったようだ(もしくは適当な会員番号でも取得が可能だったとも聞く)。則ちこの手法で得たポイントを持っているユーザーは、不正ユーザーと見なされると考えられる。

しかしそれ以外のユーザー、つまりANA関係のポイントを取得せず、他のポイントだけ得たユーザーはどんな基準で正・不正とするのか。また例えば、一人で複数、それぞれ架空の氏名などを用いて登録し、ANA関係以外のポイントしか得なかったユーザーIDは、正・不正どちらなのか。

もちろん普通に考えれば後者は不正だ。しかし、それを見分ける術はないに等しい。架空の人間を架空と見分けるためにも、それなりの労力を必要とする。今回の出来事で新規IDが大幅に増えたと予測されるが、その一つ一つに対して真偽を判断するのは容易ではない。人的リソースとコストから考えれば不可能といえる。

では楽天が今後取る対応はどうなるだろう。一番確度が高いのは、そのようなIDは軒並みポイントを失効させるだろうということだ。まとめると次のようになるだろうか。

・ANAに正規登録したユーザーで、同じANA会員番号で複数のIDのポイントを得ていない

ポイント復活(既に行われている)

・ANAに正規登録したユーザーで、同じANA会員番号で複数のIDのポイントを得ている(多重登録)

ポイント失効

・ANAに正規登録したユーザーで、別名(家族名など)・同一住所でANA会員番号を複数取得し、それぞれで複数IDのポイントを得ている

ポイント復活(既に行われたとの報告あり)

・ANAに正規登録したユーザーで、同一氏名・同一住所でANA会員番号を複数取得し、それぞれで複数IDのポイントを得ている

ポイント失効

・ANAに正規登録せず、ANAのポイントだけ得たID(ID数・期間問わず)

ポイント失効

・ANAのポイントを得ず、それ以外のポイントのみ得たIDで、登録されてからの期間が長いID

ポイント復活

・ANAのポイントを得ず、それ以外のポイントのみ得たIDで、登録されてからの期間が短い(先月末から今月取得した) ID

ポイント失効

これが現実的に一番ありそうな気がする。

システムの不備や対処の遅れ、不誠実な対応など責められるべき点が楽天に多いのは確かだ。しかし現実問題として、楽天の考える正規利用者でないユーザーに罰則が課せられるのも確かだろう。

かといって楽天を擁護することはできない。正規ポイント取得者とそうでないものという楽天側の考える基準を一切公開せず、独断で正規ユーザーかもしれないユーザーまで不正ユーザーとして切り捨てる可能性があるからだ。

また、まずは全ポイント取得者を悪とみなし、それらのポイントを没収してから正規ユーザーだけに戻すというやり方も誉められたものではない。このような場合、まずは確実に不正とみなされるユーザーを罰していく、Allow-Deny が正しいのであって、Deny-Allow というルールを用いた今回のケースでは、様々な反発が起こるのは当然だ。誰だって自分が犯罪者扱いされては気分のいいものではない。特に今回、何も知らずにポイントを取得してしまったユーザーが特にその思いを強くしているだろう。

今回のポイント取得問題は、正規と不正という枠が曖昧で、それを厳密に適用するとなると各所に歪みを起こしかねないものである。そうなったそもそもの原因は楽天のシステムの問題であり、それによる問題をユーザーに転嫁させたと言われても仕方ない。楽天としても損害を出さないよう、またユーザーにも誠実であろうとする苦肉の策であったのだろうが、初動の遅れと対応の悪さは、多くのアンチ楽天を作り出してしまったようだ。

今後楽天には、さらなるシステムの改良と、ユーザーに対してより誠実な企業となるよう努力していただきたいものである。

■ [PC] OpenVPN 2.05 のインストールと設定をしてみた

SoftEther 2.0 RC2を入れてVPN環境を構築したりしてみたけれど、Paketix 2.0 の正式版からは、フリー版は60日ごとに個人利用規程への同意とキー発行作業が必要になるらしいので、乗り換えすることに決定。友人知人へのリモートメンテくらいにしか使わないのに、そんな手間をかけられるかっての。

それに自分だけならまだしも、PCに詳しくない友人知人にキー発行作業を2ヶ月ごとに強いるのは無理だろって事で、ほぼ同様の仮想HUBシステムを構築できるOpenVPNへ乗り換えてみた。

(29日注:SoftEtherのサイトリニューアル後に確認したところ、2ヶ月ごとの更新作業が必要なのは、Server のみのようです。クライアント版はフリーソフトとのことでした)

で、接続方式はSoftEtherの代わりとして使うため、1対多の接続が可能なマルチモードに設定。UDPを使うようにしたためか、SoftEtherよりレスポンスがいい気がする。設定がやや手間ではあるけど、フリーな実装ってのはいいな。

インストールには下記のサイト様の内容を参考にさせていただきました。

http://www.remus.dti.ne.jp/%7Egrn/openvpn.html

http://www.senryu.biz/linux/openvpn/openvpn1.htm

http://degas.is.utsunomiya-u.ac.jp/member/zhao/freesw/ovpn2_howto_ja.html

■ [メモ] daemontools で OpenVPN 2.05 Server を動かすメモ

SoftEtherの時と同様に、

su –

mkdir /service/.openvpn

vi /service/.openvpn/run

????? runスクリプトの内容 ?????

#!/bin/sh

exec 2>&1

/usr/local/sbin/openvpn –config /etc/openvpn.conf

????? runスクリプトの内容 ?????

chmod 700 /service/.openvpn/run

mv /service/.openvpn /service/openvpn

こんな感じで登録。問題なく自動起動と再起動を確認。OpenVPNの場合は、SoftEtherと違って、設定ファイルに

ifconfig 192.168.100.100 255.255.255.0

みたいに書いておけば、プロセスが再起動したとしても自動でIPアドレス設定してくれるので便利。

■ [その他] 萌えコンがまた出るみたい

既に知れ渡っている話かもしれないけど、萌えコン(モエコン)の第3弾が今月29日に登場する模様。今度は「UNiSONSHIFT 百瀬玉カスタムモデル」とのこと。

http://fastcorp.ocnk.net/product-list/19

どうせならクリスマスに登場すればよかったのにね・・・とか考えてみるが、クリスマスプレゼントがてらに買う人もいないか。

今年も俺は一人きり。

( ´ー`)フゥー…

■ [その他] アキバ系SNS 「Filn」 に対しての注意喚起

アキバ系SNSとして登場した、「Filn」だが、ご多分に漏れず自分も登録してみた。のはいいが、ちょっと致命的な問題が発生している。これは自分の環境的な問題ではなさそうなので、注意喚起として公開する。なお、この件に関しては本日付でFiln事務局へ報告済みである。

起こりうる事態:

個人情報の漏洩、日記などが書き換えられる可能性がある

対処方法:

当面の間、非公開設定にしていても、個人情報を登録しない

発生環境:

Windows XP+Mozilla Firefox 1.07

ただし、全ユーザーの個人情報の搾取が可能であるとか、何でもかんでも書き換えられるといったものではない。また、自分の場合は偶然そのような事態に巻き込まれたため、具体的に攻撃として成立はしづらいと思われる。しかし、愉快犯による他人のページ書き換えが起こる可能性はあるだろう。

自分の乏しい知識からはどうしてそのような事が起こるのか分からないが、セッション管理が不十分で、プログラム内部でセッションが重複し、こんな問題が起こっているのかもしれない。

少なくとも、自分の身に1日2回もこのような問題が発生した事を考えると、多くのユーザーにも同様の問題が発生している可能性がある。メールアドレスは仕方ないにしても、個人情報の登録などはしばらく控えた方がいいだろう。

■ [メモ] daemontools で SoftEther 2.0 Server (Linux版 RC1) を動かすメモ 2

昨日の日記で書いたdaemontoolsからのSoftEther Server起動では、tapデバイスとハブをブリッジしたら、SoftEtherプロセスがdaemontoolsによって再起動した場合、tapデバイスに設定したIPアドレスも初期化される事に気づいた(はじめから気づけよ俺)。

runスクリプトに色々書いてもうまくいかなかったので(勉強不足)、下のようなスクリプトを書いてcronで数分おきに回すことにした。数回テストしたが、とりあえず問題ない模様。

#!/bin/sh

# SoftEther Server 再起動チェックスクリプト

PATH=/sbin:/usr/bin:/bin:/usr/local/bin:/usr/local/sbin

# $tap_check の初期化

tap_check=0

# 現在のtapデバイスのIPアドレスを確認し、$tap_check へ出力

ifconfig tap_test | fgrep “inet addr” > $tap_check

# $tap_check の内容確認

if [ -s $tap_check ]

then

# 内容が空でなければ何もせず終了

exit 0

else

# 内容が空であれば以下のコマンドを実行

# IPアドレス設定

ifconfig tap_test 192.168.100.100 broadcast 192.168.0.255 netmask 255.255.255.0

fi

exit 0

■ [メモ] daemontools で SoftEther 2.0 Server (Linux版 RC1) を動かすメモ

1.0の記事は発見したけど、2.0は見つからなかったので試してみた。2.0はサービス動作のため、fghack が必要かなと思ったけど、単純に

/SoftEther 2.0 のインストールディレクトリ/vpnserver execsvc

みたいな感じでrunスクリプトに書けば動作した。接続も問題ない模様。

自分の環境だと、こんな作業手順。

su –

mkdir /service/.softether2

vi /service/.softether2/run

????? runスクリプトの内容 ?????

#!/bin/sh

exec 2>&1

/usr/local/softether2/vpnserver execsvc

????? runスクリプトの内容 ?????

chmod 700 /service/.softether2/run

mv /service/.softether2 /service/softether2

これで自動的にSoftEtherが立ち上がってくれる。

■ [メモ] SoftEther 2.0 でローカルブリッジを使い、Sambaと接続する

上記内容に引き続いてSoftEther 2.0の話。現在、サーバーはLinuxルーター兼サーバーとなっており、内部でSambaが動作している。これにSoftEther 2.0 Server(RC1)を入れ、外部からアクセスするためのメモ。

1. まずはServer Managerから適当なハブを作る。面倒ならデフォルトで。

2. [ローカル ブリッジ設定] ボタンを押して、ローカルブリッジ設定画面へ。

3. 下記のように設定する。

[新しいローカル ブリッジの定義]

作ったハブを指定

[作成する種類]

新しい tap デバイスとのブリッジ接続

[新しい tap デバイス名]

適当に。今回の例では 「test」 とする

4. tapデバイスの作成に成功し、動作中と表示されたら、Linuxにログインして、下記のように設定。

su –

ifconfig tap_test 192.168.100.100 broadcast 192.168.0.255 netmask 255.255.255.0

(この例では 192.168.100.100 を指定した)

5. Sambaとiptablesなどのフィルタリングルールに問題がなければ、クライアント側の仮想LANカードのIPアドレスを、192.168.100.200 とでも設定して接続。

■ [メモ] 個人的 iptabls メモ

tapデバイスは仮想LANカードのようなものなので、それに対してルール設定をしておかないとnetbiosは通らない(自分の環境だと、基本はDROPなので)。

今回の例だと、

iptables -A INPUT -i tap_test -s 192.168.100.0/24 -d 192.168.100.0/24 -j ACCEPT

iptables -A OUTPUT -o tap_test -s 192.168.100.0/24 -d 192.168.100.0/24 -j ACCEPT

こんなルールを追加し、接続可能となった。

■ [その他] 田舎の市町村Webページの内情

最近面白いことも書いてなかったので、ここでちょっとした話でも書いておこうかと。実は私、ここ最近某お役所のWebページ作成業務に関わっていたんです。で、少しその内情ってヤツを書いてみたいと思います。身元が割れない程度にこそっと。

まずお役所Webサイトのセキュリティに関してですが、例えば id:mgisystem 様が、ご実家である香川県丸亀市のWebページに色々と問題があるというお話を何度か書かれておられます。それを踏まえてのお話ですが、

田 舎 の お 役 所 は ど こ も そ ん な 感 じ で す 。

基本的にWebページに載せてる内容は、市や町が発行するガイドブックとか市民・町民情報誌に載っている内容のまんまコピーって場合が多いようです。それプラスWebから行政サービスの受付をやろうと、ちょっと進んだ人が考えたとしても、どうしてもお役所仕事の延長で考えてしまうためかセキュリティまで頭が回らない。そんな展開でしょう。

かくいう自分が関わったサイトでも、丸亀市のような水道使用受付などという事まではやっていませんが、住所氏名電話番号その他の記載が必須な、役所へのお問い合わせフォームにSSLが使われていません。例えばプライベートな税金問題や土地問題などを相談しようと思った場合、自分なら絶対Webからの相談はしたくないですね。

せっかく普段仕事で忙しい人でも相談しやすいようにと、Webにフォームを設けているのなら、その辺にまで気を遣って欲しいと思いました。・・・といってもまあ、サーバーの管理は別会社で、自分たちはWebページのコンテンツ制作と更新、管理だけですから、SSLを入れる権限はないんですけどね。都会はどうか知りませんが、田舎だと地縁血縁でいろんな業者が入り乱れて一つのシステムを作ったりって事がままあって、その辺りでトラブることもあります。

あとは制作会社の能力というか、お役所の考え方にもよるのでしょうが、知られるとマズいセキュリティホールが残っている場合もあります。簡単なところだと、httpdのバナーをのぞいてみれば、相当古いバージョンが使われているとか。OpenSSLのバージョンが古いままとか。しかも使っているのはTelnetにftpとか(OpenSSL入れるなら普通SSH、scp、sftp辺りを使いますけどねぇ)。

もっと本質的なところまでいくと、コンテンツ管理システムにパスワード制限がかかってなくて、外部から誰でもアクセスしてデータの書き換えが可能とか。そういう事例があることも確かです(自分が手がけたシステムではなく、聞いた話ですが)。そういうコンテンツ管理システムの中にはPHPとSQLを使って構築されたものもあるようなのですが、そのうちのいくつかは入力のサニタイズが不十分で、色々とつつかれるとヤバそうなお役所サイトがあるとかないとか。伝聞ですから信憑性は謎ですが、真実とすれば恐ろしい話です。

田舎は都会より優秀な技術者が少なく、セキュリティ意識が低い技術者がサーバー構築・サイト構築に関わっている例も少なくありません。また納期の関係上、動作させることが最優先でセキュリティが疎かになることもあるでしょう。そしてそうやって作られたサイトは、コンテンツの更新はされてもセキュリティホールの修正が入ることはあまりありません(保守契約結んでなかったり、多数の業者が入っているとどこがそれをするのかという問題もあるため。それら契約内容の取り決めが甘いこともあるようです)。

少なくとも田舎では、そんな感じで運営されているお役所サイトが結構あるというのが実情です。まあ私の知る限り、自分たちが手がけたサイトには個人情報やそれに類する情報は納められていないため、仮に攻撃を受けても住民の皆さんには直接被害を与えないだけまだマシなのですが・・・(もちろん、メール送信フォームを悪用されたり他のサーバーまで乗っ取られれば個人情報が漏れることもあり得ますし、踏み台にされたら色々なところに迷惑を掛けてしまいますが)。

っていうか、予算無いのかも知れないけど、ペネトレーションテストくらいやらないのかなぁ、田舎のお役所は。ツール回して簡単なテストするだけなら、俺でもできるんだけど。そのデータを活かしてセキュアにできるかどうかは別問題だけどな。

■ [その他] 今日のネタ

2ヶ月近くぶりにこちらにも日記を書くわけですが。どうもmixiに引きこもって内輪向けな日記ばかり書いてると、公開向けコンテンツに手を伸ばすのが億劫になりますね・・・。一応一般公開向けな話もmixiには書いてるんですが。

話は変わりますが、以前に頂いていたコメントがどうも消えているような気が。消した覚えはないのですけど。スパムコメント消したときに全消去しちゃったのかな。書いていただいた方にはすみません。

本題。24インチワイドモニターが激安だったり、SC420・430というサーバー機が超特価だったりと、しょっちゅうお祭り価格が出ている気がするDELL社ですが、ご多分に漏れず自分も色々と買っちゃいまして。24インチモニターとかサーバー機とか。

こんな自分のことを表現する言葉として、以下のような造語を作ってみました。キーワード登録するほどの言葉ではない気がするので、ここでひっそり公開しておきます。もし気が向いた人がいたら、勝手に登録でもなんでもしちゃってください(笑)。

[ D’ ELLANGER (デルアンジェ)]

もともとは D’ ERLANGER(デランジェ。フランス語で「淫らな誘惑」の意) から派生した造語。DELL社が時折行うクーポンによるPCの格安販売や、特価価格とクーポンの組み合わせで、通称「祭り」と呼ばれる超低価格での商品販売(誘惑)が行われてきたことから。

「DELL社の巻き起こす淫らな(ついつい買いたくなる) 誘惑(激安価格での販売)」、転じてDELL社及びその販売戦略を指す言葉としても用いられる。この誘惑に誘われて、何台ものDELL製品を所有することとなったユーザーも数知れず。ちなみに筆者もその一人である。orz

用法:

(1)

A「今回のDELLの液晶モニターってさ、D’ ELLANGER だと思う?」

B「ちょっと D’ ELLANGER には弱いな。月末あたりにもっといいクーポン来るんじゃないかな」

(2)

A「しかしDELLは、こんなに D’ ELLANGER やってばっかりで大丈夫なのかな」

B「世界規模で生産と流通やってるから大丈夫なんじゃない?」

以上、本日はどうでもいい駄ネタでお送りしました。

に日記を書いて……って、別に1ヶ月ずつ期間を延ばしているわけでもないのですが(笑)。次は5ヶ月後ですかね?(笑えない)

■ [考察] 楽天の情報流出について考えてみる

楽天市場の店舗での取引に係る個人情報の流出について

http://www.rakuten.co.jp/com/faq/information/20050723.html

このニュース、一番初めに情報が出たのは23日だったようですが、俺が知ったのは昨日でした(遅すぎ)。で、まあ、ご多分に漏れず自分も楽天でクレジットカードを使ったショッピングを数回(最後に買ったのは去年だったと思いますが) 行っており、他人事ではなく……。ちょっと((((;゜Д゜)))ガクガクブルブル していたりします(笑)。

今回流出したのは、楽天に参加している企業の中の一店舗である、「株式会社センターロード」 だけのデータということになっていますが、これはイマイチ信用できません。

その根拠としては、こういうクレジットカードのデータは一度楽天のサーバーに蓄えられ、その後各社に転送されると考えられますが、その際に中継したクレジットカードのデータを、楽天側がきちんと消去しているかどうかという点が疑わしいからです。

前に一度、楽天でのショップ注文をキャンセルしたことがありますが、その際、楽天側から以下のようなキャンセルメールが届きました。

———————————————————————

本メールはショップにて行ったご注文のキャンセルが楽天市場のサーバに

到達した時点で送信される、自動配信メールです。

———————————————————————

くりゅえる 様

この度、楽天市場内のショップ「XXX」のご注文キャンセル手続きが

完了しましたのでご連絡させていただきます。

このキャンセル処理は、下記のような理由によりおこなっております。

(キャンセル理由の例)

 ・お客様からキャンセルのご連絡があったため

 ・期限内のご入金がなくキャンセル扱いとしたため

 ・返品のお申し出があったため

 ・二重注文により、ひとつをキャンセル処理したため

※この度のキャンセルについてご不明な点がございましたら

 ショップまでお問い合わせください。

なお、恐縮ではございますが、楽天会員登録を利用してご注文された

お客様には、今回のご注文で付与されていた楽天スーパーポイント分

は取消しさせていただきますので、ご注意ください。

なお、今回のご注文で利用された楽天スーパーポイントにつきましては、

返還(プラス)とさせていただきます。

ご不明な点がございましたら、ショップ「XXX」まで

お問い合わせください。

ここで気になる点は、注文処理がキャンセルされると、使用した楽天のポイント分は返還され、注文で得たポイントは失効するという事実です。もちろん当然のことではありますが、この加算されるポイントは、則ち購入金額によって増減するわけです。そしてこのメールは、下記のような流れで送られていると考えられます。

客が注文のキャンセルを店に依頼

   ↓

店が受諾し、注文内容を破棄すると共に、楽天に対しキャンセル処理を行う

   ↓

楽天はそのキャンセル処理を受諾し、自動的にメールを送る(上記のメール)

この流れからすると、楽天がキャンセルメールを自動的に送るためには、その注文のデータを楽天側が持っている必要があります。かつ、そのデータには購入金額、使用したポイント、付加されるポイントのデータが含まれます(上記メールの内容から)。

その場合、どういう事が考えられるでしょう。そうです、注文した内容のデータをそのまま持っておいたとすれば、楽天側に個人情報はまるまる残っているわけですね(少なくとも注文処理が全て完了するまでは残っていると考えられる)。そして今回のデータがそこから流出したとすれば、その被害は報道で言われていた、最大10万件などという数字では済まないことになるでしょう。

……もちろんこれは最悪のシナリオで、楽天側のサーバーに残しているのは、購入者の楽天ID、注文番号、購入金額、ポイントの使用履歴と付加ポイント数だけかもしれません(これだけ残していれば、十分上記の処理は可能です)。その場合は自分も安心していられるのですが、楽天に注文した時どのようなデータが楽天側に残されるのか、楽天から詳しい説明は一切無いままです。これでは安心して楽天を使うのは難しいでしょう。こういうショッピングモールでは、注文後、サーバーにどこまでの個人情報をどの程度の期間蓄積するのか、プライバシーポリシーに明記してもらいたいものですね。(現在のポリシーには提供の範囲などには触れていても、その保管期間や注文時におけるデータの蓄積・消去については触れられていないようです)

単一の店舗だと、途中のサーバーに蓄積されるということはないため(途中でsniffされるとかスパイウェア云々ということは考えません)、情報が保存されるのは1ヶ所だけでしょう。しかし楽天のようなモール形式だと、楽天とショップ両方に情報が残る可能性もあり、単独の店舗を利用するときよりそのセキュリティリスクは高いといえそうですね。なので、なおさら上記データ蓄積期間に対する説明が欲しいのですが。

……こんなことを書くと、「考えすぎだよ」 などと言われるかも知れませんが、米国でのマスターカード番号大量流出(これもサーバー内に一時保存された後、すぐ消去されなければいけないはずのデータが残っていたのが原因) の一件もあります。用心に超したことはありません。価格.com事件のように、大手だから安心などという神話は通用しないのですから。

少なくとも、インターネット上では。

スポンサードリンク

Twitter
利用中のサービス

GUiLZ Project では、以下のサービスを利用しています。


関連サイト
巡回先サイト様
アーカイブ