※当サイトの記事には、広告・プロモーションが含まれます。

Credit Card Fraud Prevention and Detectionとは、クレジットカードの不正利用の防止と検出

www.publickey1.jp

⇧ 突き詰めると、お金の問題になりますな...

gigazine.net

なお、ワイズマン氏は「戦闘が激しく行われている地域や、データの供給元であるADS-B Exchangeに対してデータを送信することができる航空機が存在しないなどの理由から、ウクライナやシリアの一部地域では緑や黄色、赤の表示がありません」と述べています。

地球儀を使って「地球上のどこでGPSが妨害されているか」が一目でわかるウェブサイト「GPSJam」 - GIGAZINE

⇧ 戦争や紛争など国や組織が対立しているような状況で、位置情報の特定を妨害している場所(座標)が分かってしまうと、狙い撃ちされてしまうので、悪用されたら危険な気がしますな...

Credit Card Fraud Prevention and Detection (CCFPD)とは

翻訳ツールで英語から日本語に変換してもらったところ、

⇧ というような結果になったのだけど、日本だと、

『クレジットカードの不正利用の防止と検出』

みたいなニュアンスになるんかね?

Credit Card Fraud Prevention and Detection(CCFPD)の分類

まぁ、「クレジットカード」を利用した決済に関するセキュリティの領域の話になると思われるのですが、

⇧ 上記サイト様によりますと、上図のように分類できるらしい。

「電子決済」は『消費者がオンラインで何某かの製品、ないしは、サービスを購入する行為』が起因となると思われるわけですが(その前に諸々の手続きは必要)、「Transaction Level」というのは、『消費者がオンラインで何某かの製品、ないしは、サービスを購入する行為』に関わる処理の単位の話になるのかなと。

「Transaction Level」のイメージとしては、

⇧ 上図のように、1連の処理のことになるかと。

「クレジットカード」を利用した決済は不正利用との闘いと言えそう

「クレジットカード」の黎明期のリアルタイム世代では無いので、よく分からないのですが、「クレジットカード」を利用した決済は、あの手この手で「不正利用」が行われてきたらしいですと。

「クレジットカード」を利用した決済以外でも問題は起きていて、

www.itmedia.co.jp

⇧「コード決済」などでも「情報漏洩」などが起きていたらしく「不正利用」の問題を起こしていたように思われる。

「一般ユーザー」の「個人情報」の「情報漏洩」は無かったとしているけど、「加盟店」に関して「情報漏洩」していたということで、「不正利用」以外の被害も起こり得たと...

何と言うか、

www.itmedia.co.jp

www.itmedia.co.jp

www.itmedia.co.jp

www.itmedia.co.jp

⇧ ちょっと「情報漏洩」が過ぎるので、「PayPay」のセキュリティには疑問が残りますな...

そもそも、合併前の「LINE」「Yahoo」の時にも「情報漏洩」が頻発していたような気がするので不安しかない...

話が脱線しましたが、直近の状況は分からないですが、

paymentnavi.com

⇧ 上記サイト様によりますと、「クレジットカード」を利用した決済に対する「犯罪行為」も「個人」から「組織」で行われるように変わってきていると。

システム開発者の負担は右肩上がりという構図になっていると思われるからして、絶望しかないんだが...

前回、

ts0818.hatenablog.com

⇧ 上記の記事で、「PCI SSC (Payment Card Industry Security Standards Council)」が策定している「クレジットカード」を利用する決済に関するセキュリティ標準などを調べてみましたけど、何か、網羅されていないような気がするんよね...

このあたりの情報が「MECE(Mutually Exclusive, Collectively Exhaustive)」に整備されていないのも問題ではある気がするんよな...

コンサルティング業界特有の用語なのか分かりませんが、

www.komcon.co.jp

⇧ 上記サイト様にあるように、状態を3つに分類できるとして、「電子決済」のシステムを開発する上での要件が分かり辛いんよな...

今回の「電子決済」のセキュリティの話で言うと、「Will」の部分が分からん、つまり、一般的な「電子決済」のセキュリティに関して行うべきことの全量。

ここが不明瞭だから、「Must」について、

  • 「Will」に無いから実現できない
  • 「Can」が満たせていなくて実現できない

のかの判断の仕様がないということになる。

でもって、整備されていなくて散らかっている「Will」を整理することに膨大な工数が取られることになるのであると...

ちなみに、

⇧ というツイートがあって、何故、エンジニアは曖昧な回答をせざるを得ないかというと、おそらく、

⇧ 上記のPDFにあるように、現状の成果物がどうなっているかは、工数をかけて確認するしかないからして、

『〇〇という認識です。』

と答えざるを得ないわけで、実際には、

『〇〇という認識です。ただし、何らかの変更が追加されていたりする場合は、私の知る限りでは無いので、あくまで推測であり、事実と断言できるものではありません。』

という言外の意味が込められていると思われる。

まぁ、要するに、

『現状については分からないので、調査のための工数が発生すると思います。有識者に相談してください。』

っていうのが回答ととしては正解になると思うのだけど、エンジニアは基本的に面倒くさがりなので、我関せずのスタイルが多いような気がするので、ツイートにあるような回答が多そうね。

人間はエスパーでは無いので、言葉にしてくれないと分からないのですが、エンジニアは暗黙知に依存しがちなので、「認識合わせ」が重要になってくるのですが、考え方が千差万別過ぎるのは否めませんと。

こう考えると、「認識合わせ」という行為はかなりの不確実性を伴わざる得ないのですが、とは言え、他に良い方法は無いからして、妥協するしかないわけですと。

ちなみに、

⇧ 上記サイト様が、エンジニアにありがちな発言を図式化しておりますが、システム開発に携わったことがある人なら、何となく共感できそうな感じはあるかと。

普通に考えたら、システム開発って、

  • どこの誰だか知れない者たちが策定した仕様
  • どこの誰だか知れない者たちが発案する要求
  • どこの誰だか知れない者たちが定義する要件
  • どこの誰だか知れない者たちが作成する設計
  • どこの誰だか知れない者たちが作成する実装
  • どこの誰だか知れない者たちが実施する動作検証

⇧ 上記のようなことを行っているわけだから、「成功」する可能性が低くなると考えるのは当然なんですよね。

だから、巨額の予算を投じて「システム開発」が失敗することもあり得るし、「システム障害」が起こらないわけは無いんですよね。

「技術的負債」という言葉が、人口に膾炙してきた感はありますが、そもそもとして、ソフトウェア分野におけるシステム開発の仕組み上、不確実性を排除することはできないので、「ファジー」な状態を許容せざるを得ないからして、このあたりの実情をエンジニア以外にも啓蒙して欲しい気はする。

毎度モヤモヤ感が半端ない...

今回はこのへんで。