Q&A
ご回答ありがとうございます。
私もこの記事(https://www.j-credit.or.jp/security/understanding/member-store.html)を読んで混乱していて。
- カード非保持化というのが法律で決められているらしい（2018年3月から施行,罰則付き）
- 森永はシステムからカード情報が漏洩している(2018年5月)
いったいどういうことなんだろうかと
概要
クレジットカードの番号、名義、有効期限をシステムで保存するのは何のためなのでしょうか。
詳細
健康食品通販サイトにおけるお客さま情報の流出に関するお詫びと調査結果のお知らせ | ニュースリリース | 森永乳業株式会社
こちらの事件ではクレジットカード情報が流出し、カード情報が不正に使用されるという被害（不正請求）があったそうです。
調査の結果、カード情報※1およびカード情報以外の個人情報※2が流出したと考えられるお客さまは最大29,773名でした。また、カード情報以外の個人情報※2のみが流出した可能性のあるお客さまは最大63,049名でした。
※1：カード情報
番号、名義、有効期限 ※セキュリティコードは含まれていないことが確認できました
※2：カード情報以外の個人情報
氏名、住所、電話番号、ＦＡＸ番号、メールアドレス、性別、職業、生年月日、お届け先情報、受注情報
この**「セキュリティコードは含まれていない」**という文章を見て、コードがなければ決済できないのではないのか？と疑問を持ちました。
調べてみると 「クレジットカードのサインレス決済ができるできないの違いって何？｜クレジットカードの三井住友VISAカード」 に書かれているように、特定の条件内ならばセキュリティコードなしでも決済できるということを知りました。
「セキュリティコードを保存してはいけない」というのはよく聞くのですが、「番号、名義、有効期限を保存してはいけない」というのは聞いたことがありません。
しかし「番号、名義、有効期限」だけでも決済ができてしまうならば、これらも保存するべきではないのではないかと思いつきました。
それでもクレジットカードの情報流出というのはよく聞くので、何かシステムで保存せざるを得ない理由があるのではないだろうかと思っています。
クレジットカード決済に関わったことがなく基本的な知識もないため、変な質問になっているかもしれませんがよろしくお願いいたします。
回答5件
0
ベストアンサー
当該サイトがクレジットカード情報を保存していた、という想定での質問のようですが、おそらく当該サイトはクレジットカード情報を保存していないと思います。
参照されているリリースには以下の文があります。
（１）カード情報およびカード情報以外の個人情報
2015年1月7日～2017年10月16日に、当該サイトでカード情報を入力して商品をご注文されたお客さま 最大29,773名
「2015年1月7日～2017年10月16日に、当該サイトでカード情報を入力して商品をご注文」という箇所がポイントです。これは、入力フォームからカード情報が漏洩したものと推測されます。
詳しくは以下のブログ記事をお読みください。
決済代行を使っていてもクレジットカード情報が漏洩するフォーム改ざんに注意
つまり、カード情報入力フォームにJavaScriptを追加するような改ざんをして、そのJavaScriptがフォームの情報を外部に漏洩させたのだと思います。
すでに他の方が指摘されているように、ECサイト側は原則としてカード情報非保持になるので、ECサイト側でカード情報を保存するケースは例外的（PCI DSSを取得していれば可能ですが）になるでしょう。
投稿2018/06/05 14:31
総合スコア11705
0
投稿2018/06/04 14:42
退会済みユーザー
総合スコア0
2017年の夏あたりから
J-CREDIT : こういう事故を避けるために非保持化しましょう、2018年3月までに完了してね
そこ：対応してなかったため流出
なるほどそうなんですね。
ちなみにpepperleaf様、otn様とのコメント欄に書いているのですが、カード情報がないのに「再入力を省く」「定期購入するために毎月入力しない」を行うことは可能なのでしょうか。？
もう少し詳しく言えば
過去水準：ECサイト、決済業者
現在水準：決済業者
というように決済も行わないのになんでECサイトで保持してんだよてこと。
※ 決済業者側で保持に対するスキームは昔からあります。
横からすいません。「安全管理措置の義務化」らしいですよー。非保持化はその手段の一つでしょう。http://www.meti.go.jp/policy/economy/consumer/credit/1141hayawakarikaiseikappuhanbaihou.html#n09
うん、「義務＝法律上または道徳上、人や団体がしなくてはならない、また、してはならないこと。」
> 非保持化はその手段の一つでしょう
これは「非保持化」はOPTIONALなもので、必須ではないということでしょうか？
まあ徳丸先生が時期に降臨してくれるじゃろうて
(他人のコメント欄で失礼しています)非保持化自体は必須・任意の軸ではないです。必須は「安全管理措置の実施」(という理解)です。これ以上は聞かれても責任を持って答えられないので、予め了解してください。
YouheiSakurai様
いいえ、ご回答いただけて大変ありがたいです。
こういう業務的な知識・ノウハウはその重要さに反して、プログラミングのそれと比べて圧倒的に少ないので。
u28epGUskさん、
> こういう業務的な知識・ノウハウは
回答にも書きましたが、ここはプログラミングが主体と思っているので、これらの問題に適切な回答を求めるのは、ちょっと違うのでは無いかと思っています。セキュリティって経営とか、管理者視点が重要と思っています。
pepperleaf様
> 回答にも書きましたが、ここはプログラミングが主体と思っているので、これらの問題に適切な回答を求めるのは、ちょっと違うのでは無いかと思っています。
なるほど、業務的な知識はプログラミングに含まれないということですね。
私は"プログラミング"とは要求分析(Requirements analysis)の工程も含むものだと認識しています。
例 https://en.wikipedia.org/wiki/Computer_programming
> Programming involves tasks such as analysis, generating algorithms, profiling algorithms' accuracy and resource consumption, and the implementation of algorithms in a chosen programming language
そのためこの質問に関してはプログラミングに含まれるのではないかと思っています。
あくまで私がそう思っているということですので、御気分を害されてしまいましたら申し訳ございません。
u28epGUskさん、
あまり気にしないでください。ただ、プログラムに関連しない話題では適切な回答が得られないと思いました。(プログラム以外の事がより重要) セキュリティ関係は、責任の所在がより、重要になるので、素人意見は注意と思っています。(詳しい方の登場があったので良かった) 要求分析は大切ですが、立ち位置の違いも大きいです。
また、いけないと思ったら、そもそもコメントしていません。
@pepperleaf
セキュリティ関連は徳丸先生が降臨するからその限りではないんだよね
0
リスクリワードのリワード(報酬、つまり良い事)があるからです。
よくセキュリティ的に「XXXはサーバ側に保存すべきではない」と考えがちですが、パスワードやセキュリティコード等の秘匿情報ですら、サーバ側に保管して利便性を提供するサービスがあります。ので、情報を保管するというリスク(の評価結果)がリワードを上回ったと考えるとスッキリすると思います。
投稿2018/06/04 13:24
総合スコア6149
ご回答ありがとうございます。
> リスクリワードのリワード(報酬、つまり良い事)があるからです。
リワードとは具体的にどのようなものがあるのでしょうか？
「再入力を省くことができる」「定期購入するために毎月入力しなくて済む」以外でなにかあるのでしょうか？
作りが簡単になる、難しい事を考えなくて良くなる、顧客満足度が上がる、UXが向上する、他と横並びになる、他の商売に広げやすくなる、等々、いろいろ想像する事はできますが、具体的に何がリワードにあたるのかは当事者以外には分かりません。
法令遵守、社会貢献、等々も想像の対象から外してはいけませんね。企業なので。
> 当事者以外には分かりません
そうですよね。森永の事業・システムの事情などもあり正確に知ることはできず想像でしかないですが。
「やばいと思っていたが修正が間に合わなかった」だけというオチだって有りうる。。。
なるほど、その場合は改修や変更にかかるコストを他に回す事ができるという良い事がありますね。
0
決済が完了した後までも、保存せざるを得ないと言うことは無いでしょう。
おそらく「次の買い物の時に、カード情報入力を省略できる」という機能を実現したいのでしょう。
もしくは定期購入機能とか。
「カード情報が流出したら、会社が倒産してもやむを得ない」くらいの覚悟で保存して欲しいものです。
お書きのサイトのケースだと、説明の文言からだけでは、セキュリティコードは保存してなかったのか、保存してあったが他のデータと別の保存方法であったので運良く被害が及ばなかったのか、どちらか不明です。
次の買い物のために保存する場合でも、インターネットからアクセス出来る状態で保存する必要ないですね。
よく見かけるのが、番号の下4桁だけ、インターネットからアクセス出来るサーバーで保存してユーザーに見せて、他の情報は奥の方のサーバーに保存。まあ、これとて内部者の犯行での流出は防げませんが。
投稿2018/06/04 13:06
総合スコア86295
ご回答ありがとうございます。
> おそらく「次の買い物の時に、カード情報入力を省略できる」という機能を実現したいのでしょう。
もしくは定期購入機能とか。
「再入力を省くため」「定期購入機能のため」に保存しているということですね。
※pepperleaf様、otn様へのご質問と同じなのですが
逆に言うと「再入力を省くため」「定期購入機能のため」を実現するためには「番号、名義、有効期限」を保存することは必須なのでしょうか？
二回目の買い物で、決済に必要な情報を、
・前回のときに保存して再利用する
・再度入力させる
の2択だと思いますが。
"クレジットカード情報の非保持"というワードを見かけていたので、なくても決済できるのかと思っていました。 (この記事などです https://www.j-credit.or.jp/security/understanding/member-store.html)
非保持なのに「番号、名義、有効期限」を保存しておかないと「再入力を省く」「定期購入するために毎月入力しない」が実現できないというのが矛盾しているように思えて。
再入力を省く機能を実装しないのなら、非保持でいいのでは？
一応 [GMO ペイメント] で例をあげるが
https://www.gmo-pg.com/service/mulpay/credit-card/
のようにある決済業者の保持を利用すればいいだけなのだが
なんとなく整理できてきたような
- 加盟店、決済代行業者、クレジットカード会社の3者がいる
- 決済代行業者のシステムを経由して決済を行うことも、経由しないで直接クレジットカード会社のシステムと決済することも可能
- 決済代行業者を使用すれば「再入力を省く」「定期購入するために毎月入力しない」を,加盟店が「番号、名義、有効期限」を保存すること無しで実現できる
- 再入力や定期購入 = 定期的な決済を行うためには番号、名義、有効期限等が必要なので、それは決済代行業者が保持している
- 森永は決済代行業者を使用していなかったため？、「番号、名義、有効期限」を保存していた？
決済業者が保持していれば全体としては同じでは？
まあ、局所になるってことじゃろうね
うちがよくみるのは決済業者に保持させろなんで
決済業者が保持していれば、加盟店の責任は(形式上) 無くなります。
0
ここで、質問すべき内容とは思えませんが、、、コメントに書く内容でも無いので。
カード情報は、セキュリティ上、システムで保存すべき内容では無いと思います。
その一方、使う立場になってみると、(特にセキュリティを気にしない方々)
毎回、入力するのは大変でしょう。そして、売る方からすれば、何度も来て欲しい。 という、双方の利害の一致では無いかと思っています。
実際に、カード情報を保存するかオプション付きのサイトもあります。その一方、退会したにも関わらず、保存するところもあるようです。
投稿2018/06/04 13:04
総合スコア6385
ご回答ありがとうございます。
> その一方、使う立場になってみると、(特にセキュリティを気にしない方々)
> 毎回、入力するのは大変でしょう。そして、売る方からすれば、何度も来て欲しい。 という、双方の利害の一致では無いかと思っています。
「再入力を省くために保存している」ということですね。
※pepperleaf様、otn様へのご質問と同じなのですが
逆に言うと「再入力を省くため」「定期購入機能のため」を実現するためには「番号、名義、有効期限」を保存することは必須なのでしょうか？
あと、一部の経営者(?)は、顧客情報を必要以上に集める傾向があるようです。
情報流出リスクを減らす有効な方法の一つして、不要な情報は持たないというのがあります。(持っていない情報は流出しない)
>「番号、名義、有効期限」を保存することは必須なのでしょうか？
必須では無いですが、保存してあれば、再入力の手間は省けます。(ただし、情報流出のリスクは増える)
セキュリティコードが必要なサイトとそうでないサイトがありますが、その違いは知りません。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2018/06/06 14:52