もう各所でかなり話題になっておりますが、「イモトのWi-Fi」と銘打って海外用モバイルWi-Fiルーターレンタルサービスを展開しているGLOBALDATAのWebサーバーに不正アクセスがあったんで調査してみたら最大146,701件のクレジットカード情報を含む個人情報を お漏らし 情報漏えいしていたという、なかなかド派手なカード番号流出事件があったようです。
お客様情報を保持していたサーバーには、最大146,701件のクレジットカード情報があり、同件数のお客様情報（①カード名義人名、②カード番号、③カード有効期限、④セキュリティコード、⑤お申込者住所）がありました。不正取得により流出しました件数はうち109,112件になり当該情報は、平成23年3月7日～平成25年4月23日にお申し込み頂きました、お客様の情報が対象となります。
アタックから顧客対応までの時間がかかり過ぎとか色々叩かれる面もあるようですが、僕は本サービスのことを使ったことはありませんし、当事者ではないので、そういった点には本エントリでは触れませんです。
それよりも、ECサイトの決済まわりについて日々考えている僕としては、このWebサイトの決済まわりやDBを設計した人というのは、なぜこんな作りにしてしまったのだろうという点について思うところが色々ありますので、それを書こうと思います。
（この事件に引っかけてエントリ書くのは火事場見物みたいで下品ですが、この会社を叩く意図ではありません）
とりあえず、僕がこのエントリで語りたいのは、この２点あたりです。
■カード番号を自前DBサーバへ保管する必要について
■セキュリティコード保存したらアカンて国際基準で決まってる
というわけで語りますお。
カード番号を自前DBサーバーへ保管する必要はあったのか？
通常、サイトでカード番号を入力すると、カードの利用限度額以内か・利用可能な状態であるかを確認するための「オーソリ」という処理をして、そのあと売上確定の処理をしたら請求がいくという仕組みになっています（例外はありますが）。
カード番号をサービス提供側が保管することで、そのサイトの会員はカード番号の入力をしなくても気軽に利用（決済）をすることができるようになります。
サーバーに保管されているカード番号を使ってオーソリ処理が行えるからですね。
（wi-fiレンタルなどのサービスではなく一般的なＥＣの話として）予約してから納品までが長い商品などではオーソリの期限が切れてしまうのですが、再オーソリすることができたりします（カード期限が切れる問題もあるんですけど）
毎月課金するなどの定期決済を自前で実装したい場合なども、毎月オーソリ→売上確定という処理をすることになりますからカード番号を保管したくなる気持ちはわかります。
また、一般的にカード決済は売上確定後に金額変更ができない場合が多く、金額変更をするには、以前に確定した売上を取消して、新たに変更後の金額でオーソリからやりなおす必要があり、オペレーションのイケてないＥＣなんかだと経理部の人が泣きながら銀行振り込みで人力対応していたりする場合があります。
そんなわけで、ここらへんの処理を自動化するために自前でカード番号を保管したくなる気持ちは理解できるところであります。
うん、気持ちは、わかる。
とはいえ、それ決済代行会社を変えれば（多分）できるよ？
特定の決済代行会社をオススメするつもりはないので、どことは言いませんので調べてくださいな。
決済代行というのは、カード発行会社とショップの間にたってクレジットカード決済の処理システムやら何やらを提供してくれる存在です。
会社によって色々な違いがあり、自前でカード番号を保管しなくても、セキュリティも国際基準にそってちゃんとしている決済代行サービスで再オーソリできるような仕組みを提供しているところがあるですよ！
具体的には会員や受注ごとにキーを発行して、同じサイトからなら、そのキーを使って（カード番号がなくても決済代行サービスのサーバー側にはあるので）再オーソリできる、みたいな感じになっております（正確な仕組みとは違うかもしれないけどカード番号を保管しないで再オーソリできるイメージってことで）
ってわけで、発注側も開発側も、この手のやつは自分の提供したサービスに合った決済サービスを探して使うのがカンタンで最強の解決策なんです。
システム開発会社さん側が、そういうところを使わないで開発してしまうのは、そういうサービスを提供している決済代行会社があるって知らないという知識不足だったり、開発が楽だから「使ったことある決済代行会社にしよう」ってなってしまうとか、まあそういう理由があるわけですが、発注する側も、言われたままに受け入れるのではなく、ちゃんとそういうのツッコミ入れられるようにしておきたいところですね（まあ提案側がちゃんとしてれば一番いいんですけどね
セキュリティコード保存したらアカンて国際基準で決まってる
（合ってますよね？＞専門家の方）
PCI DSSってのは、VISA 、MasterCard 、JCB、AMEX、Discoverが共同で策定した、クレジット業界におけるセキュリティの国際基準ですな。強制力はありませんが、ある程度これに倣っておくべきものだと思います。
カード番号の流出事故・事件が起きた時にPCI DSSで重要になる（のに、そうなっていない）のは、下記の点です。
■カード番号は保管するなら（暗号化とか）判読不能にしる！！
■セキュリティコードは、たとえ暗号化しても保存したら絶対にダメ！
GLOBALDATA さん (ノ∀｀)アチャー
サーバーにアタックされた方も被害者ではあるけど、セキュリティコードを保管してたのはアカンと思いますですぞ（カード番号も暗号化してなかったっぽいですしね）
これも、開発側にそういう正しい知識がなかったんだろうなって感じです。
想像ですが、オーソリ時にセキュリティコードが必要な決済代行サービスを使っていたんだと思います。
そのシステムで再オーソリするためにはセキュリティコードまで保存する必要があったんではないかと。
ちなみに、そういうときは、公開側でお客様が決済するときはセキュリティコード必須、管理システム側から決済するときはセキュリティコードなしで決済を通せるような決済代行サービスがありますので、そういうサービスを探して使うといいですよっと。
最後にまとめ。
文中に書きましたが、大抵のことは自前実装しなくても、探せば安全でやりたいことできる決済代行サービスがあるはずです。
料率が安いとか、そういうのも無視できないかとは思いますが、「使ったことある」とか「提案されたから」とか、そういう理由で安易に決めて、サービス開発すると痛い目に遭うかもしれませんよ？
「ウチのサイトやばいかもー」ってWeb担当者の方とか、過去に受託で開発したECサイトの決済まわりが危ないかもって思ってるエンジニアの方は早急にアレコレされることをおすすめ致します。
どーでもいいけど、ＥＣの決済が複雑な絡んだ経理のシステムとか、返品交換の赤伝処理のシステムとか大好物なので（通常、弊社は受託業務やってないんで、そんな機会はないかもですが）関わってみたいですな。
