ドコモ口座や銀行口座で何が起こっているのか#1

「不正利用をした犯人が悪いんです」

責任の分析にそんな綺麗事は聞きたくねえ!

ということで、システムで利益を得ている企業や銀行がセキュリティの問題をほっぽらかしってどうなの?という視点で考えたい。

散々、色々なニュースが出ており、何がどうなっているのか分からない状態なので、整理しよう。

ステークホルダー#1~#3の整理

今回の事件の登場人物を考える。なお、犯人は一人とは限らない。というか、全く関係ないいろいろな人間が試みていると考えた方が自然だろう。


2)ドコモ口座を
開設
2)ドコモ口座を 開設
3a)ドコモ口座と
銀行口座を連携する
3a)ドコモ口座と...
不正利用者
不正利用者
もともと
開設済
もともと 開設済
利用者
利用者
1)口座情報を
不正に入手
1)口座情報を 不正に入手
4a)ドコモ口座にチャージする
4a)ドコモ口座にチャージする
利用者の
銀行口座
利用者の 銀行口座
5)d払いで換金性の
高い商品を購入
5)d払いで換金性の...
3b)連携のとき、
Web口振サービスで認証する
3b)連携のとき、...
不正利用者の
ドコモ口座
(メールアドレスのみで開設)
不正利用者のドコモ口座(メールアドレスのみで開設)...
ドコモ(企業)の
銀行口座
ドコモ(企業)の 銀行口座
銀行
銀行
«システム»
Web口座振替サービス
«システム»...
4b)ドコモ口座
に実質的に振替
4b)ドコモ口座...
6)商品を換金する
などして現金化
6)商品を換金する...
1.ドコモの脆弱性
1.ドコモの脆弱性
2.銀行の脆弱性
2.銀行の脆弱性
3.利用者の脆弱性
3.利用者の脆弱性
Viewer does not support full SVG 1.1

  1. 企業
    • NTTdocomo(以下ドコモ)
      • ドコモ口座を運営している。
  2. 銀行
    • ドコモ口座対応銀行35行(以下、銀行)
      • 被害者のように思われるが、今回使われたと思われる手口は彼らのシステムに対する脆弱性が大きい。
      • 気に留めておきたいのはセキュリティ上今回の手口の対象とならないようなセキュリティ対策に問題ない銀行もある。
      • つまり銀行次第なのである。
  3. 利用者(および被害者になり得る対象)
    • ドコモ口座対応銀行35行を利用する全口座の利用者

手口の整理

手口は以下のとおり

  1. 犯人は何らかの方法(先の脆弱性2)により不正に口座情報を得る
  2. 犯人はドコモ口座に適当なアドレス(先の脆弱性1)で口座を開設する
  3. 犯人はドコモ口座と銀行口座を結びつける
  4. 銀行口座からドコモ口座にチャージを行う
  5. チャージした額で何らかの換金性の高い商品を購入し、その商品を現金に変える

なお、チャージ額は月額最大30万である。ドコモの会見によると発覚から2月に及ぶ被害者もいたので最大で60万の被害を被った被害者もいるということである。 2020年9月10日時点でドコモから報告された被害内容、被害額は1800万円、対象は11行66件に及ぶ。 なお、被害は拡大傾向にある見込み(これについても後述する)。

参照:ドコモ口座、現金の不正引き出し被害が拡大 被害額は1990万円に - ITmedia NEWS

ドコモの脆弱性

今回は、まず「ドコモの脆弱性」について述べる。

ドコモの脆弱性はドコモ口座開設時に本人確認をしていなかったことにある。

メールアドレス一本のみで開設することができ、容易になりすまし、捨て口座を作ることができた。

これにより不正利用者に対して、不正引出のための「入り口」を作ってしまったことが功罪である。

なぜ無限に匿名で登録できるようになったのか

ドコモ口座にはdアカウントというものが必要である。 これは。もともとNTTdocomoの回線契約者に限ったアカウントであった。つまり、もともとはドコモの責任範疇でちゃんと本人確認できていた

ドコモ口座というサービスの原型自体2011年というだいぶ古いサービスである。もっとも当時はドコモ契約者同士であるということが条件だったようだ。

それが2013年からNTTdocomo回線を利用しなくても誰でもアカウントを作れるようにした。 これはあくまで筆者の想像だが、その背景には、QRコード決済として「d払い」などの利用者拡大や、顧客情報の集約化などが目的にあったのだろう。

問題は、この時点でdアカウント(同時にドコモ口座)と本人との結びつけ唯一性がなくなったことである。

Image from Gyazo

つまり、このドコモの脆弱性の生じた正体は、サービスの改修時にセキュリティの再評価を行っていなかったことにある

これは、経営側の問題である。むろんシステム開発側でも検討されただろうが、ドコモほどの大企業であれば経営層にもセキュリティに関する評価はするような仕組みがあって然るべきだし、そもそもあっただろう。どちらにせよ、その再評価を怠ったことに原因および責任の一端がある。

なお、dアカウント利用時には二段階認証をできるなどあるが、あくまで利用時のセキュリティ対策であり、本人確認には一切関係ない。

事前に防ぐことはできたか

結論からいえばできたともいえるしできなかったともいえる。

利用者が被害を被ったのは、全体の構造を踏まえなければ判断できないからだ。そも、

  • 可能性を懸念し
  • 最初から銀行とその点を協議し
  • もしもを想定した入口・出口対策を打てていたか

ということには議論の余地がある。

ただ、ここで確実に言える問題点は、登録時の本人確認の責任所在をないがしろにしていたことだ。

脆弱性を作っていることをドコモの経営層は理解していなかった。あるいは「銀行口座の引き落としまで含めたサイクル全体の本人確認の責任は銀行側にあると考えていた」と推測される。何にせよ「ドコモ口座の本人確認」の所在は曖昧にされており、正当化される理由にはならない。

もう1点明らかなことは、この脆弱性はあくまで被害発生の入り口だけであり、真に「日本金融業界のパンドラの箱を開けた」ことだ。

脆弱性への対策

まず、1点目として、ドコモは全額補償を打ち出した。被害額として、3000万円に満たない額であり、今年度営業利益が8800億円に及ぶ大企業にとって、当然するべき行動だろう

むしろ、なぜ保障の枠組みを作っていなかったのか? 補償に関するサービスデスクはもともとなかったし、認識の甘さが垣間見える。

社会的な問題提起として、資金決済業者に利用者への補償の枠組みをあらかじめ設けておくことを法律で強制するべきではないだろうか。

難しい話ではない。クレジットカード会社が行っていること-すぐにカード利用を止めたり、不正利用の補償を行ったりなど-を同様にしろ、というだけである。

次に2点目、ドコモは脆弱性の本質的な対策として、eKYCの導入を行うとのことだ。

eKYCを簡単に言えば、最近のサービスで良く使われる運転免許証などの本人確認書類をスマホで提出するアレである。

この対策の評価は一旦差し控える。これで解決するかと問われれば、被害サイクルにおける脆弱性のすべてを補うものとは言い切れないからだ。

実際、ドコモ口座以外での被害が確認され始めている。

そのため、銀行の脆弱性に触れなければならない。

次回予告:銀行の脆弱性

話が飛ぶが、類似の事件として、PayPayのクレジットカード不正登録事件が記憶に新しい。これは、PayPayのアカウントに誰のクレジットカードでも結びつけができた事件だった。

どちらの事件も「利用者が知らぬ間に自分の財産を取られてしまう」という共通点がある。

相違点は「銀行口座」と「クレジットカード」の違いである。何が異なるのか?

これこそが銀行側の脆弱性に繋がる話であり、問題構造の根幹でもある真の脆弱性である。そして、今ドコモ口座事件は、その領域を飛び出し他のキャッシュレス決済サービスで同様の事件が起こっている。

これはそう簡単に解決できない根深い問題である。

では、これについて次回に述べたい。

コメント

このブログの人気の投稿

リモートワークをLogicoolのマウスとキーボードで複数PC切り替えて優勝した

VBAでのInterfaceやキャスト

SUPERHOTがいかにSUPERHOTか語りたい