アカウント名:
パスワード:
いつもこういう話を聞く度に思うのは、クレジットカードなどの情報そのものをインターネットから直接アクセスできないようなところに分離できないか、ということ。
インターネットから分離して、カード番号その他をいれて、例えば、RS-232Cで接続する別のデータベースサーバに問い合わせて、結果のyesかnoかだけ、答えをもらうようなシステム。これならば、クレジットカード番号が網羅的に抜かれることはない。パスワードだって、そのようにすれば、shadowすら抜かれることもない。
毎回入れるようになるだけだよ。それがみんな面倒だと思ってるから、サーバに残しちゃってるわけで。
分離したデータベースサーバにパスワードとともにクレジットカード番号などを格納しておいて、パスワードとセットでないと、番号を参照できないようにすれば、うまくいくような気がします。
あるいは、クレジットカード番号はフロントエンドのサーバからは設定できても、参照できないようにするか。
いずれにしても、網羅的に20万人分とか抜かれなければ、たまたま、一人だけ、パスワードが当てられて抜かれてもそれは、そのユーザのパスワード管理が悪いか、強度が弱いか、運が悪かったで済む。
こういう大規模な流出を防ぐことは技術的に解決できそうな気がします。
いやいやいやｗ別にそんなめんどくさい話じゃなくて、単純に「入力されたカード情報は決済代行会社に投げるだけで、ショッピングサイト側には保存しない」とすれば解決する話です。というか今時そうせず、自前でカード情報を保存しているのが既に狂気の沙汰なんです。
そりゃショッピングサイトへのカード情報の入力を全てロギングするようなプログラムを仕込まれたらおしまいですが、決済代行会社側のカード情報入力画面を使うような作りにすれば、それも回避できます。# だいたいどこの決済代行会社もそういう仕組みを用意しています。
基本的に、決済代行会社はショッピングサイトへカード情報を全部は公開しませんので（下4桁だけ、など）、仮にショッピングサイトが完全に乗っ取られたとしても、フルのカード情報が全部漏洩するなんてことにはなりません。# 決済代行会社によっては有料のオプション契約でカード番号をショッピングサイトの運用者が確認できるようにする、なんてのもありますが。
よく言われる「2度目以降のカード決済ではカード情報の入力をスキップさせたい」なんてのも、だいたいどこの決済代行会社も「このトークンで○○円の注文を入れる」みたいなAPIを備えていますので、ショッピングサイト側にカード情報を保存する必要なんて無いんです。5年前ぐらいには既に多くの決済代行会社のシステムにそのような仕組みが出来ていたと記憶してますので、2012年にもなって自前でカード番号を保存しているなんてのは、ショッピングサイトのシステム担当者の怠慢以外の何者でもありません。
おっしゃるとおり、クレジットカードについてはカード会社に投げるのが安全でしょう。
しかし、網羅的に抜かれたら問題になる情報はクレジットカードだけではありません。そのような情報も分離したデータベースサーバに置けば安全性は高まる、のではないか、という話です。
> おっしゃるとおり、クレジットカードについてはカード会社に投げるのが安全でしょう。違います。カード会社ではなく、決済代行会社です。業態が全く別です。
> しかし、網羅的に抜かれたら問題になる情報はクレジットカードだけではありません。> そのような情報も分離したデータベースサーバに置けば安全性は高まる、のではないか、という話です。はい。それはわかりますが、カード情報をどうのこうの、書かれていましたので。どうも文面からはカード情報とそれ以外の個人情報、これらの漏洩リスク対策を同列に考えているように見受けられますが、全く別であることを理解していますか?
何か勘違いしていますね。
そこから流出するとすればそれはショッピングサイト側ではなく決済代行会社側から流出したことになるのですからショッピングサイト側には何の落ち度もありませんが。逆にショッピングサイト側が不正アクセスを受けたとしてもクレジット情報自体は別会社の別サーバーにあるのですから流出しようがないという話だと思いますけど。
決済代行会社が信用出来ないのならクレジットカード自体の利用をやめるべきでしょうね。
> 何か勘違いしていますね。> そこから流出するとすればそれはショッピングサイト側ではなく決済代行会社側から流出したことになるのですからショッピングサイト側には何の落ち度もありませんが。だから自社(=ショッピングサイト)の責任になることは回避できると言っているのでまったく同じことを言っているように思うのですが、何を勘違いしているのですか?>> カード情報の入力を全てロギングするようなプログラムを仕込まれた状況でカード番号の漏えいを防げるとか、決済代行会社は魔法でも使ってるんですか?
別に大掛かりなシステムを店舗側に求めなくても、カード会社側で、支払先ごとに、別のセキュリティコード（あるいは別のカード番号）を振り出し可能なシステムにして、支払先店名が合致している場合のみ決済が通るようにしておけば、流出起因で別の店舗で不正利用される必要もないし、流出元も特定できるし、同じ店舗で買い物する限りは、再入力する必要もないし、具合がいいと思うのですが。
ちなみに、現行でも、カード会社側の不正利用検出システムは結構、充実しているみたいで、不正利用者がいざ、カード番号を入手した場合も、不正利用検出システムに引っ掛かって承認NGになって使えない場合は多いそうです。
そうですね。クレジットカードに関してはカード会社の対応などにより、だんだんと安全性は高まってきているとは思います。
しかし、その他の個人情報についてはデータベースをうまく分離しないと、網羅的に抜かれるような事件はなくならないのではないかな。以前、女性向けのサイトで本名、体のスリーサイズや電話番号などが抜かれたことがあったような気がします。クレジットカード情報だけが重要な情報ではありません。
スリーサイズや電話番号が知られると、生命や財産の危機になるとか？
>別に大掛かりなシステムを店舗側に求めなくても、カード会社側で、>支払先ごとに、別のセキュリティコード（あるいは別のカード番号）を振り出し可能な>システムにして、支払先店名が合致している場合のみ決済が通るようにしておけば、>流出起因で別の店舗で不正利用される必要もないし、流出元も特定できるし、>同じ店舗で買い物する限りは、再入力する必要もないし、具合がいいと思うのですが。
その「支払先との対応リスト」が結局利用されてクラックされるだけです。
カード決済では、たとえばベクターは結局のところカード会社に請求を回す必要があり、ここではどうしても
で、その分離したデータベースサーバの両方にアクセスできるアプリケーションサーバあって、それがハクられた上で両方から引っ張られるというオチはどうやって回避しましょうか？
ていうか、この手のデータ盗難はデータベースサーバに侵入されるよりも、アプリケーションサーバに侵入されて、そこから通常の許可されたルートでデータを引っ張って盗んでいくのが多いんですから、そっちをなんとかしないとね。
アプリケーションサーバからデータベースへはクレジットカードの情報はINSERT/UPDATEはできても、SELECTはできないという処置はいいかもしれない。ただし、ユーザが自分でカード情報を変更するインターフェースがあるところは工夫が必要ですね。
基本的なコンセプトとしては、すでに- クレジットカード認証はカード会社に投げる、- パスワードはopenIDのような認証サーバに任せる、というように、まさにフロントサーバとは分離したデータベースサーバという形態をとっているわけです。
それ以外の情報もできるだけ分離できれば安全性は高まるでしょう。- 情報をとりださない、- 取り出すとしても一度に網羅的にとりだせない- 個々の認証が成立しなければとりだせないというようにうまく組めれば、分離したサーバから一度に流出することはなくなると思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
クレジットカード情報などをインターネットから分離はできないのか (スコア:1)
いつもこういう話を聞く度に思うのは、クレジットカードなどの情報そのものをインターネットから直接アクセスできないようなところに分離できないか、ということ。
インターネットから分離して、カード番号その他をいれて、例えば、RS-232Cで接続する別のデータベースサーバに問い合わせて、結果のyesかnoかだけ、答えをもらうようなシステム。これならば、クレジットカード番号が網羅的に抜かれることはない。パスワードだって、そのようにすれば、shadowすら抜かれることもない。
Re: (スコア:0)
毎回入れるようになるだけだよ。
それがみんな面倒だと思ってるから、サーバに残しちゃってるわけで。
Re:クレジットカード情報などをインターネットから分離はできないのか (スコア:1)
分離したデータベースサーバにパスワードとともにクレジットカード番号などを格納しておいて、パスワードとセットでないと、番号を参照できないようにすれば、うまくいくような気がします。
あるいは、クレジットカード番号はフロントエンドのサーバからは設定できても、参照できないようにするか。
いずれにしても、網羅的に20万人分とか抜かれなければ、たまたま、一人だけ、パスワードが当てられて抜かれてもそれは、そのユーザのパスワード管理が悪いか、強度が弱いか、運が悪かったで済む。
こういう大規模な流出を防ぐことは技術的に解決できそうな気がします。
Re:クレジットカード情報などをインターネットから分離はできないのか (スコア:5, 参考になる)
いやいやいやｗ
別にそんなめんどくさい話じゃなくて、単純に
「入力されたカード情報は決済代行会社に投げるだけで、ショッピングサイト側には保存しない」
とすれば解決する話です。というか今時そうせず、自前でカード情報を保存しているのが既に狂気の沙汰なんです。
そりゃショッピングサイトへのカード情報の入力を全てロギングするようなプログラムを仕込まれたらおしまいですが、
決済代行会社側のカード情報入力画面を使うような作りにすれば、それも回避できます。
# だいたいどこの決済代行会社もそういう仕組みを用意しています。
基本的に、決済代行会社はショッピングサイトへカード情報を全部は公開しませんので（下4桁だけ、など）、
仮にショッピングサイトが完全に乗っ取られたとしても、フルのカード情報が全部漏洩するなんてことにはなりません。
# 決済代行会社によっては有料のオプション契約でカード番号をショッピングサイトの運用者が確認できるようにする、なんてのもありますが。
よく言われる「2度目以降のカード決済ではカード情報の入力をスキップさせたい」なんてのも、
だいたいどこの決済代行会社も「このトークンで○○円の注文を入れる」みたいなAPIを備えていますので、
ショッピングサイト側にカード情報を保存する必要なんて無いんです。
5年前ぐらいには既に多くの決済代行会社のシステムにそのような仕組みが出来ていたと記憶してますので、
2012年にもなって自前でカード番号を保存しているなんてのは、ショッピングサイトのシステム担当者の怠慢以外の何者でもありません。
Re:クレジットカード情報などをインターネットから分離はできないのか (スコア:1)
おっしゃるとおり、クレジットカードについてはカード会社に投げるのが安全でしょう。
しかし、網羅的に抜かれたら問題になる情報はクレジットカードだけではありません。そのような情報も分離したデータベースサーバに置けば安全性は高まる、のではないか、という話です。
Re: (スコア:0)
> おっしゃるとおり、クレジットカードについてはカード会社に投げるのが安全でしょう。
違います。カード会社ではなく、決済代行会社です。業態が全く別です。
> しかし、網羅的に抜かれたら問題になる情報はクレジットカードだけではありません。
> そのような情報も分離したデータベースサーバに置けば安全性は高まる、のではないか、という話です。
はい。それはわかりますが、カード情報をどうのこうの、書かれていましたので。
どうも文面からはカード情報とそれ以外の個人情報、これらの漏洩リスク対策を同列に考えているように見受けられますが、
全く別であることを理解していますか?
Re: (スコア:0)
何か勘違いしていますね。
そこから流出するとすればそれはショッピングサイト側ではなく決済代行会社側から流出したことになるのですからショッピングサイト側には何の落ち度もありませんが。
逆にショッピングサイト側が不正アクセスを受けたとしてもクレジット情報自体は別会社の別サーバーにあるのですから流出しようがないという話だと思いますけど。
決済代行会社が信用出来ないのならクレジットカード自体の利用をやめるべきでしょうね。
Re: (スコア:0)
> 何か勘違いしていますね。
> そこから流出するとすればそれはショッピングサイト側ではなく決済代行会社側から流出したことになるのですからショッピングサイト側には何の落ち度もありませんが。
だから自社(=ショッピングサイト)の責任になることは回避できると言っているのでまったく同じことを言っているように思うのですが、何を勘違いしているのですか?
>> カード情報の入力を全てロギングするようなプログラムを仕込まれた
状況でカード番号の漏えいを防げるとか、決済代行会社は魔法でも使ってるんですか?
Re:クレジットカード情報などをインターネットから分離はできないのか (スコア:2)
別に大掛かりなシステムを店舗側に求めなくても、カード会社側で、
支払先ごとに、別のセキュリティコード（あるいは別のカード番号）を振り出し可能な
システムにして、支払先店名が合致している場合のみ決済が通るようにしておけば、
流出起因で別の店舗で不正利用される必要もないし、流出元も特定できるし、
同じ店舗で買い物する限りは、再入力する必要もないし、具合がいいと思うのですが。
ちなみに、現行でも、カード会社側の不正利用検出システムは結構、充実しているみたいで、
不正利用者がいざ、カード番号を入手した場合も、不正利用検出システムに引っ掛かって
承認NGになって使えない場合は多いそうです。
Re:クレジットカード情報などをインターネットから分離はできないのか (スコア:1)
そうですね。クレジットカードに関してはカード会社の対応などにより、だんだんと安全性は高まってきているとは思います。
しかし、その他の個人情報についてはデータベースをうまく分離しないと、網羅的に抜かれるような事件はなくならないのではないかな。以前、女性向けのサイトで本名、体のスリーサイズや電話番号などが抜かれたことがあったような気がします。クレジットカード情報だけが重要な情報ではありません。
Re: (スコア:0)
スリーサイズや電話番号が知られると、生命や財産の危機になるとか？
Re: (スコア:0)
>別に大掛かりなシステムを店舗側に求めなくても、カード会社側で、
>支払先ごとに、別のセキュリティコード（あるいは別のカード番号）を振り出し可能な
>システムにして、支払先店名が合致している場合のみ決済が通るようにしておけば、
>流出起因で別の店舗で不正利用される必要もないし、流出元も特定できるし、
>同じ店舗で買い物する限りは、再入力する必要もないし、具合がいいと思うのですが。
その「支払先との対応リスト」が結局利用されてクラックされるだけです。
カード決済では、たとえばベクターは結局のところカード会社に請求を回す必要があり、
ここではどうしても
Re: (スコア:0)
で、その分離したデータベースサーバの両方にアクセスできるアプリケーションサーバあって、それがハクられた上で両方から引っ張られるというオチはどうやって回避しましょうか？
ていうか、この手のデータ盗難はデータベースサーバに侵入されるよりも、アプリケーションサーバに侵入されて、そこから通常の許可されたルートでデータを引っ張って盗んでいくのが多いんですから、そっちをなんとかしないとね。
アプリケーションサーバからデータベースへはクレジットカードの情報はINSERT/UPDATEはできても、SELECTはできないという処置はいいかもしれない。
ただし、ユーザが自分でカード情報を変更するインターフェースがあるところは工夫が必要ですね。
Re:クレジットカード情報などをインターネットから分離はできないのか (スコア:1)
基本的なコンセプトとしては、すでに
- クレジットカード認証はカード会社に投げる、
- パスワードはopenIDのような認証サーバに任せる、
というように、まさにフロントサーバとは分離したデータベースサーバという形態をとっているわけです。
それ以外の情報もできるだけ分離できれば安全性は高まるでしょう。
- 情報をとりださない、
- 取り出すとしても一度に網羅的にとりだせない
- 個々の認証が成立しなければとりだせない
というようにうまく組めれば、分離したサーバから一度に流出することはなくなると思います。