「キャッシュレス決済って便利だけど、本当に安全なの?」
「自分のスマホ決済も、知らないうちに不正利用されていたらどうしよう……」
こうした不安を抱えながら、キャッシュレス決済を使っている方は少なくありません。
実際に2019年、日本で大きな話題となった事件があります。
セブン&アイ・ホールディングス傘下の株式会社セブン・ペイが提供したモバイル決済サービス「7pay」が、開始わずか2日で不正アクセス事件を引き起こし、最終的にサービス廃止に追い込まれたのです。
7pay事件って聞いたことありましゅけど、どんな事件だったんでしゅか?
単純なパスワード管理の問題だと思っているなら、それは大きな誤解だ。認証設計の根本的な欠陥が招いた、教訓に満ちた事件なんだよ
この記事では、7pay不正アクセス事件の詳細を解説し、セキュリティエンジニアが学ぶべき教訓をまとめます。
- 7pay事件の具体的な経緯と被害の実態
- パスワードリセット機能の設計上の問題点
- リスト型攻撃(クレデンシャルスタッフィング)への対策方法
- 認証設計で絶対に守るべき基本原則
キャッシュレス決済が急速に普及する現代において、認証設計の重要性を理解することはセキュリティエンジニアとして欠かせないスキルです。
7pay事件は「他山の石」ではなく、あなたが関わるシステムのどこにでも起きうる問題なのです。
目次
7payとは何か——開始2日で起きた不正アクセス事件
2019年7月1日、株式会社セブン・ペイはモバイル決済サービス「7pay(セブンペイ)」のサービスを開始しました。
7payはセブン-イレブンのアプリと連携し、コンビニでの支払いをスマートフォン一つで完結させる決済サービスでした。
日本のキャッシュレス化が加速する中、大手コンビニグループが満を持して投入した注目のサービスでした。
ところがサービス開始翌日の7月2日、7payを利用した不正アクセスが発覚します。
悪意ある第三者が他人のアカウントに不正ログインし、登録されたクレジットカードやデビットカードからチャージして電子マネーを不正に使用するという手口でした。
被害が広がる中、7月3日にクレジットカード・デビットカードによるチャージを停止し、7月4日には現金チャージと新規会員登録も停止しました。
その後、セキュリティ対策プロジェクトによる調査が行われ、2019年8月1日にサービス廃止が決定、同年9月30日をもってサービスは終了しました。
開始から廃止まで3ヶ月もかからなかったんでしゅね……
そうだ。まさにデジタルサービスの失敗例として、セキュリティ業界では今も語り継がれている事件だよ
なぜ破られたのか——確認された攻撃と設計上の問題点
7pay事件の原因を公式調査の視点から整理すると、確認された主な攻撃手法と、それを可能にした設計上の問題点に分けて理解できます。
セキュリティ対策プロジェクトの調査では、認証レベル・開発体制・システムリスク管理体制の3つが被害を防げなかった主な要因として挙げられました。
パスワードリセット機能の設計上の問題点
7payの認証システムには、パスワードリセット機能に深刻な設計上の問題がありました。
通常、パスワードリセットはSMSや登録済みメールアドレスに確認コードを送り、本人確認をおこないます。
しかし7payでは、リセット先として登録時とは異なるメールアドレスを指定できる仕様になっていました。
なお、セキュリティ対策プロジェクトの公式調査では、パスワードリセット機能が不正アクセスの直接の原因となった事例は確認されていません。
それでも、この仕様はアカウント乗っ取りのリスクをはらむ設計として、セキュリティ専門家から問題視されました。
設計上の問題点は以下の通りです。
- 生年月日・電話番号・登録メールアドレスを入力するだけで、任意のメールアドレスへパスワードリセットメールを送付できた
- 攻撃者が別の手段でこれらの情報を入手していれば、本人のメールアドレスを知らなくても乗っ取りが理論上可能だった
- リセット先のメールアドレスに対する本人確認(SMS認証・メール確認)が一切おこなわれていなかった
- 二段階認証(2FA)もサービス全体として導入されていなかった
生年月日と電話番号なんて、SNSや名簿サイトで手に入ることもあるでしゅよね……
そうだ。本人確認として弱い情報を使い、しかもリセット先を任意変更できる設計は、アカウント乗っ取りへの扉を開くリスクがある。二段階認証が導入されていなかったことも、防御の薄さを示していたな
リスト型攻撃(クレデンシャルスタッフィング)——主な不正アクセス手法
7pay事件で公式調査が主な攻撃手法として確認したのが、リスト型攻撃(クレデンシャルスタッフィング)です。
リスト型攻撃とは、他のウェブサービスから流出したメールアドレスとパスワードの組み合わせを使い、別のサービスへのログインを試みる攻撃手法です。
多くのユーザーが複数のサービスで同じパスワードを使い回している現実を悪用します。
7payがリスト型攻撃に脆弱だった理由を整理すると、次のような問題が浮かび上がります。
| 問題点 |
内容 |
| 二段階認証なし |
ログイン時に追加の本人確認をおこなっていなかった |
| 大量アクセスの検知不足 |
短時間に大量のログイン試行があっても検知・遮断できていなかった |
| パスワードポリシーの甘さ |
強固なパスワードを強制する仕組みが十分でなかった |
| 異常ログインの通知なし |
新しい端末からのログイン時にユーザーへ通知する機能がなかった |
他のサービスで流出したパスワードで別のサービスに入られてしまうんでしゅか?
そうだ。「パスワードの使い回し」はユーザー側の問題でもあるが、サービス側が多要素認証や異常検知で補う設計をしないと、この攻撃は防げない。7payはそのいずれも不十分だったんだ
被害の全貌と事件の経緯
7pay事件の被害は、数字で見ると非常に深刻なものでした。
また、事件発覚後の対応にも問題があり、被害の拡大につながりました。
808人・約3,861万円の被害
セブン&アイ・ホールディングスの公表によると、7pay事件の被害は以下の規模に及びました(2019年7月31日17:00時点)。
- 被害者数: 808人
- 被害総額: 約3,861万円(38,615,473円)
- 集計時点: 2019年7月31日17:00(セブン&アイ・ホールディングス公表)
攻撃者はサービス開始と同時に不正ログインを試み、決済機能を悪用して電子マネーを詐取しました。
被害を受けたユーザーからは「アプリを開いたら残高がゼロになっていた」「身に覚えのない決済履歴があった」という声が多数寄せられました。
808人という被害者数は、攻撃の組織性と準備の周到さを物語っています。
サービス廃止という最悪の結末
7payは被害発覚後、段階的に機能を停止していきました。
事件の主な経緯をたどると、以下のような流れになります。
STEP
2019年7月1日: サービス開始
スマートフォンでのバーコード決済サービスとして正式リリース。
多くのメディアが注目した。
STEP
2019年7月2日: 不正アクセス発覚
複数のユーザーから「見知らぬ購入履歴がある」との報告が殺到。
不正アクセスが明らかになる。
STEP
2019年7月3日: クレジットカード・デビットカードチャージ停止
被害拡大を防ぐため、クレジットカード・デビットカードによるチャージ機能を停止。
既存残高での支払いは継続。
STEP
2019年7月4日: 現金チャージ・新規会員登録を停止
現金によるチャージと新規会員登録もあわせて停止した。
STEP
2019年7月5日: セキュリティ対策プロジェクト設置
弁護士を中心とする検証チームを含むセキュリティ対策プロジェクトを設置し、原因究明を開始。
STEP
2019年8月1日: サービス廃止を正式決定
セキュリティ上の問題を根本的に解決することが困難と判断し、サービス全面廃止を正式発表。
STEP
2019年9月30日: サービス終了
7payのサービスが完全に終了。
開始からわずか3ヶ月での幕切れとなった。
サービス開始からわずか3ヶ月でサービスが廃止になってしまったんでしゅね……
そうだ。セキュリティの問題は、一度失った信頼を取り戻すのが極めて難しい。特に決済サービスのように金銭を扱う場合、信頼失墜はそのままサービス廃止につながりうる。非常に高い代償だったな
セキュリティエンジニアへの教訓
7pay事件は、現代のシステム設計に重要な教訓をもたらしました。
技術的な問題だけでなく、組織的な問題や開発プロセスの問題も浮き彫りになった事件です。
認証設計で守るべき基本原則
7pay事件を踏まえ、認証設計において絶対に守るべき原則を整理します。
認証設計の基本原則は以下の通りです。
- 多要素認証(MFA)の実装: パスワード単体に依存せず、SMS・認証アプリ・生体認証などを組み合わせる
- パスワードリセットフローの厳格化: リセット先アドレスの変更を禁止するか、変更時に旧アドレスへの確認通知を必ず送る
- 本人確認情報の適切な選択: 生年月日・電話番号のような「知られうる情報」を認証の根拠にしない
- 異常ログインの検知と通知: 新規端末・海外IPからのログイン時にリアルタイム通知をおこなう
- セッション管理の強化: ログイン履歴の可視化、不審なセッションの強制ログアウト機能を設ける
二段階認証を入れるだけで、かなりの攻撃を防げるんでしゅね!
そうだ。多要素認証は実装コストに対して防御効果が非常に高い。特に決済サービスのように金銭を扱うシステムでは、最初から設計に組み込むべき必須要件だよ
リスト型攻撃への多層防御
リスト型攻撃はパスワードを直接破るのではなく、他のサービスから流出した情報を使います。
そのため、パスワードを強化するだけでは不十分で、複数の防御層を組み合わせる必要があります。
リスト型攻撃に対する多層防御策を以下に示します。
- レートリミット(試行回数制限): 短時間に複数のログイン失敗があった場合、一時的にアカウントをロック
- IPアドレスの評価: 不正アクセスで知られるIPや、短時間に大量のリクエストを送るIPを遮断
- CAPTCHA・ボット検出: 自動化ツールによる大量試行を検知し、人間であることの確認を求める
- pwned passwords照合: HaveIBeenPwnedのAPIなどを活用し、既知の流出パスワードの使用を禁止する
- 異常検知システム: 通常の利用パターンと異なるアクセスをリアルタイムで検出・遮断する
これだけ重ねれば、リスト型攻撃はほぼ無効化できるんでしゅか?
完全な防御は難しいが、攻撃のコストを大幅に高くして攻撃者をあきらめさせる効果は十分にある。セキュリティは「絶対安全」より、攻撃を割に合わなくさせることが現実的な目標だよ
まとめ
7pay不正アクセス事件は、認証設計の甘さがいかに深刻な被害をもたらすかを、日本中に知らしめた出来事でした。
サービス開始直後に発覚し、その後確認された808人・約3,861万円の被害、そしてわずか3ヶ月でのサービス廃止は、セキュリティ設計を後回しにしたことの代償を如実に示しています。
この事件から学ぶべき教訓を、最後に整理します。
- 多要素認証は決済サービスの必須要件——金銭を扱うシステムでパスワード単体認証は論外
- パスワードリセットフローは慎重に設計する——リセット先変更を無制限に許可してはならない
- リスト型攻撃への防御は多層的に——レートリミット・異常検知・CAPTCHAを組み合わせる
- セキュリティはリリース後の追加ではなく、設計段階から組み込む
7pay事件は他人事じゃないでしゅね。自分が関わるシステムでも、同じような設計ミスをしていないか確認しなきゃでしゅ!
その気づきが大切だ。セキュリティエンジニアとして、「認証は後からでいい」という考え方を絶対に持たないことだよ。7payの悲劇を繰り返さないために、今日からすぐに自分のシステムを見直してみよう
セキュリティエンジニアとしてのキャリアを磨きながら、こうした重大な脆弱性に向き合うスキルを身に付けたい方は、ぜひセキュリティプロ・フリーランスにご登録ください。