ドコモ口座不正出金事件から学ぶ本人確認と二要素認証の重要性

「気づいたら銀行口座からお金が消えていた」
「ドコモを使っていないのになぜ被害に遭うの？」

チップス

ドコモを使ってないのに被害に遭うなんてあるんでしゅか？
銀行に確認したら、知らないサービスに口座が連携されてたって言われて、怖くなりましたでしゅ……。

ボス

そうだ。これはドコモのサービスの問題でもあるが、本質は「本人確認の甘さ」と銀行との連携設計にある。
2020年9月に発覚したドコモ口座不正出金事件は、セキュリティエンジニアとして必ず知っておくべき事件だな。

2020年9月、日本中に衝撃が走りました。
NTTドコモが提供する電子決済サービス「ドコモ口座」を悪用した不正出金が全国の地方銀行で相次ぎ、被害者の多くはドコモユーザーですらありませんでした。
自分が開設した覚えのないサービスによって、銀行口座から資金が奪われるという前代未聞の事態は、本人確認と二要素認証の重要性を社会全体に突きつけました。

この記事では、ドコモ口座不正出金事件の全容と仕組みを解説し、セキュリティエンジニアが設計段階から取り入れるべき認証の考え方を学びます。

ドコモ口座不正出金事件とはどんな事件だったのか

2020年9月、突然の残高消失から全国に広がった事件の概要と、被害の実態を見ていきましょう。

2020年9月、突然の残高消失から始まった

2020年9月、仙台銀行や七十七銀行など複数の地方銀行から「不正な引き落とし被害が発生している」との報告が相次ぎました。
被害者の多くに共通していたのは、「ドコモ口座を開設した覚えがない」という点です。
実態が明らかになるにつれ、犯人が被害者名義でドコモ口座を不正開設し、連携銀行から資金を引き出していたことが判明しました。

事件の主な経緯は以下の通りです。

ボス

重要なのは、被害者の大半がドコモのユーザーですらなかった点だ。
自分が使っていないサービスで被害に遭うというのは、当時の人々にとって衝撃的だっただろうな。

チップス

え、ドコモユーザーじゃなくても被害に遭ったんでしゅか？！

被害の実態 ── 計128件・約2,885万円の損害

NTTドコモが公表した被害状況によると、被害件数は計128件、被害金額は約2,885万円に上りました。
最終的に35行がドコモ口座への銀行口座の新規登録を停止する事態となり、被害は地方銀行を中心に広範囲に及びました。

被害の主な特徴をまとめると、以下の通りです。

ボス

これだけ広範に影響が出た背景には、各銀行が同じ仕組み「Web口振受付サービス」でドコモ口座と連携していたという構造的な問題がある。
一つの設計の欠陥が、複数の銀行を横断して被害をもたらしたのだな。

不正出金を可能にした「本人確認の抜け穴」

なぜ他人名義でドコモ口座を開設し、銀行口座と連携できたのか。事件の核心にある脆弱性を分析します。

メールアドレスのみで開設できたドコモ口座

事件当時、ドコモ口座はドコモ回線を持たないユーザーでも、メールアドレスだけで開設できる仕様になっていました。
本人確認書類の提出も、顔写真の照合も不要でした。
これが根本的な問題の一つです。本人確認が不十分なサービスは、第三者が「なりすまし」で利用できる余地が生まれます。

問題となった設計の欠陥をまとめると、以下の通りです。

ボス

コンビニのポイントカードと、銀行口座に接続するサービスでは、求めるべき本人確認のレベルが根本から違う。
リスクに応じた認証設計ができていなかったことが、事件の出発点だな。

チップス

金融サービスに連携するのに、確認がメールアドレスだけなんて……確かに危なすぎましゅね。

銀行のWeb口振受付サービスの脆弱性

もう一つの問題は、銀行側の「Web口振受付サービス」にありました。
このサービスでは、口座番号や暗証番号などで銀行口座をドコモ口座に連携できる仕組みでした。
犯人は何らかの手段（フィッシング詐欺・情報漏えいデータの悪用など）で入手した他人の口座番号と暗証番号を使い、他人名義のドコモ口座を開設した上で銀行口座と連携。その後、連携した銀行口座から資金をドコモ口座へ移動させ、電子マネーとして使用しました。

犯行の流れを整理すると、以下の通りです。

ボス

特に問題だったのは、一部の銀行では口座連携の認証が口座番号と暗証番号のみの一要素認証で完了してしまう設計だった点だ。
二要素認証があれば、口座番号と暗証番号を知っていても、連携自体を防げた可能性が高い。

チップス

暗証番号を知られただけで、知らないところで連携が完了してしまうんでしゅね……！

二要素認証がなければ何も守れない

この事件は、認証設計の甘さが致命的な被害を生むことを示しました。
認証の基礎を改めて整理します。

4桁の暗証番号だけでは不十分な理由

暗証番号（PIN）は古くから使われる認証手段ですが、単体では限界があります。
「知識情報」だけに頼る認証は、情報が漏えいした瞬間に無力化されます。
金融サービスでは、国際標準として次の「認証3要素」のうち2つ以上を組み合わせることが推奨されています。

ボス

ドコモ口座の問題で被害が出たのは、口座連携の認証がキャッシュカードの暗証番号だけで済んでしまう銀行だった。
所持情報（スマートフォンへのSMSワンタイムパスワード等）が必要だったなら、攻撃者は口座番号と暗証番号を知っていても連携できなかっただろうな。

チップス

SMSで確認コードが来るやつでしゅよね。あれがあれば防げてたんでしゅね。

eKYCがもたらすセキュリティ強化

事件後、金融庁は銀行と資金移動業者に対し、口座連携の手続きに脆弱性がないかを確かめ、多要素認証の導入や本人確認（取引時確認）の強化などを検討するよう求めました（出典：金融庁 報道発表資料（2020年9月15日））。
NTTドコモも再発防止策の一つとして、eKYC（Electronic Know Your Customer）を導入しています（出典：NTTドコモ 報道発表資料（2021年1月29日））。
eKYCとは、スマートフォン等を使ってオンライン上で本人確認を行う仕組みです。

eKYCで確認できる主な項目は、以下の通りです。

eKYCが義務化されていれば、「メールアドレスのみで口座開設」という事態は起きませんでした。
なりすましによる不正開設を防ぐ最初のゲートとして機能するからです。
犯罪収益移転防止法の改正などにより、金融サービスと連携するサービスでは本人確認が強化されています。
マイナンバーカードを使ったeKYCの普及も進んでいますが、完全な普及にはまだ時間がかかっているのが現状です。

ボス

eKYCがあれば、最初の「なりすましで口座開設」の段階でブロックできるんだな。
本人確認は入口で締めなければ意味がない、という教訓でもある。

セキュリティエンジニアへの提言

この事件から、設計段階で取り入れるべきセキュリティ原則を整理します。

外部API連携設計における原則

決済サービスや銀行口座との連携を設計するエンジニアにとって、この事件は重要な教科書です。
「便利さ」と「セキュリティ」のバランスをいかに取るかが問われます。
API連携設計で実装すべき主なセキュリティ要件は、以下の通りです。

ボス

連携操作が発生したとき、本人の知らないところで処理が完了してしまう設計は危険だ。
たとえ不正であっても、本人が気づいた時点で止める手段を与えることが重要だな。

リスクに応じた認証レベルの設計

すべての操作に最高レベルの認証を求めると、利便性が著しく損なわれます。
一方で、低リスクの操作に使う認証を高リスク操作に流用すると、この事件のような問題が起きます。
適切な設計として、リスクに応じて認証レベルを変える「リスクベース認証」が有効です。

ボス

特に外部サービスとの口座連携は「高リスク」操作に分類し、複数の認証ステップを踏むべきだ。
ここを中リスク並みに扱ったことが、ドコモ口座事件を招いた要因の一つだな。

チップス

設計の最初からリスクを見極めないといけないんでしゅね……勉強になりましたでしゅ。

ボス

そうだ。セキュリティは後付けでは難しい。
どの操作がどのリスクを持つかを設計の最初から整理し、それに合った認証を選ぶ。
それが「セキュアバイデザイン」の考え方だな。

まとめ

ドコモ口座不正出金事件は、「本人確認の甘さ」と「認証設計の不備」が招いた事件です。
被害者の多くはドコモユーザーですらなく、自分の知らないところで口座が連携され、資金を奪われました。

この事件が示した教訓は明確です。
金融サービスと連携するシステムは、設計段階から最高水準のセキュリティが求められます。
なりすましを防ぐeKYC、不正連携を阻止する二要素認証、異常を即時に伝えるリアルタイム通知、そして不審なアクセスを止める異常検知を組み合わせることで、被害を未然に防げます。

ボス

「このケースは大丈夫だろう」という思い込みが、最大の脆弱性になる。
ドコモも連携銀行も、それぞれの責任の境界を意識するあまり、全体のセキュリティを誰も担保していなかった。

チップス

全体を見る視点が大事なんでしゅね。勉強になりましたでしゅ。

ボス

この事件以降、多くのサービスで二要素認証が強化されている。
過去の失敗から学ぶことが、セキュリティエンジニアの基本だな。

この事件を教訓に、認証設計を見直すきっかけにしていただければ幸いです。