2019年も残すところ半年となった7月1日にコンビニ最大手のセブンイレブンが発表した7pay(セブンペイ)
下半期のはじめから大きな事件に発展しましたね。
セキュリティの観点からもエンジニアとしては見逃せないこの事件。
大きな波紋を残す事は間違いないのですが、改めて今回の7payの問題点を洗い出してみようと思います。
7pay騒動の問題発生の流れ
まず今回の7pay騒動の被害の概要や問題発生の経緯について振り返っていきます。
7pay騒動の被害概要
7payの900名の登録者に対し不正アクセスが発生した事により、約5500万円の不正利用が発覚。(7/4 6時時点)
被害者に対しては全額保証される事が発表されているが、保証時期は未定。
7payの登録者数は2019/7/3時点で約150万人と発表されており、現在は新規登録や新規チャージが停止されています。
発生に至るまでの経緯
| 発生日時 | 事象 |
| 2019/7/1 | 7pay(セブンペイ) サービス開始 |
| 2019/7/2 | 利用客より「身に覚えのない取引があったようだ」との問い合わせ（第一報） |
| 7/2夜間 | SNS上に7payの不正利用被害がアップされはじめる。 |
| 2019/7/3 10:30 | 7payに対する海外からのアクセスを遮断 |
| 2019/7/3 午前中 | ・社内調査の結果、不正利用が発覚 ・お客様サポートセンター緊急ダイヤルを設置 ・7payホームページの「重要なお知らせ」にID・パスワード管理の注意喚起を掲載 |
| 7/3 16:00以降 | 7payに対するクレジットカード、デビットカードによるチャージ入金を一時停止 |
| 2019/7/4 14:00 | 緊急会見を実施し、「二段階認証」への理解のなさや「一定のセキュリティレベル」審査を実施していて問題なかったと判断した旨を発表。 取材に対し「今後のことは、状況次第ですが、お客さまの利便性を考えてサービスを継続しました」と広報担当者からの発表。 公式HPの「一部アカウントへの不正アクセス発生による チャージ機能の一時停止について」における発表においても、店頭やnanacoからのチャージと7payへの新規登録は停止したものの、既にチャージした金額は利用できると発表。 |
| 7/4 14:00 以降 | 7payに対する全てのチャージ入金停止を実施。 |
| 7/4 18:00 以降 | 7payへの新規登録停止対応を実施。 |
| 2019/7/5 | 「7pay（セブンペイ）」に対する不正アクセスの件（第3報）」が発表され、プロジェクト体制、二段階認証の導入、チャージ1回あたりの上限額見直し、セキュリティ設計、評価の見直しが発表される。 |
SNSはじめ世間から指摘されている問題点
7payを実際に利用した人たちから指摘されている問題点は以下の通り。
- 新規登録時に求められる情報が基本情報のみで「秘密の質問」や「プライバシーに関わる情報」がなかった
- iOS版の7payにおいては生年月日が未入力でも登録可能だった
- 新規登録時にSMS認証を求めたりアカウントの開始許可を求めるといった二段階認証が実装されていなかった
- パスワードリセットメールが登録されていないメールアドレスにもリセットメール送信が可能だった為、誰でもリセット可能な状態だった
- パスワードリセットの試行回数に制限がなく、回数を重ねる事でパスワードリセットが誰でも可能な状態だった
二段階認証が設定されていない事や登録していないメールアドレスにもパスワードリセットメール送付可能だった事など、近年のセキュリティに関する問題を甘く見ていたとしか思えない対応が発覚しました。
ましてや2018年末～2019年はじめに発生したpaypayの不正利用においても二段階認証をしていたものの試行回数が無制限だった事による問題が発生していました。
にも関わらず同じ轍を踏むという失態を演じたというのは大企業としての責任以前にキャッシュレス決済プロジェクトに臨む責任が欠如していたと言わざるを得ません。結局、他プロジェクトの失態を顧みずにプロジェクトを進めていたという事が明るみになったわけです。
2018年のはじめに発生したコインチェックのXEM(ネム）流出問題もさる事ながら、セキュリティに対する大きな問題を何度繰り返せば気が済むのかと言わざるを得ない形となってしまいました。
提示された一時対応は？適切な対応がなされているとは思えない？
今回の7payの不正アクセス問題についてはその対応の遅さも不信感をぬぐえぬ結果となっています。
まずお客様からの第一報があったのが7月2日だったわけですが、
チャージ停止までには1日、新規登録停止までに実に2日と時間が経過しています。
結果的に1日かけた事で被害が増大している感はぬぐえませんし、
「不正アクセス」を調査する前に第一報があった時点でサービス停止する措置をとれなかったのか？
という点は疑問点でしかありません。
例えばAmazonや楽天でも不正利用や不正ログインだと思われる時点でメール通知をしていたり、アカウント停止まで1時間もかけずに対応しれたりと様々な対応がなされています。
これらの対応策がなされていなかった時点で一時サービス停止を即刻踏み切っていれば被害がここまで大きなものにならなかったと思われます。
今回の不正利用に対するセキュリティ以上に根本的な問題点とは？(私見)
さて、今回の7payの問題ですが、IT業界に長く従事する私から見ても
「セキュリティに対する理解」以上にもっと根本的な問題があるの
は言うまでもありません。
そもそもセキュリティ面で
「二段階認証が備えられていなかった事」や
「パスワードリセットが違うメールアドレスでもできてしまう」なんていう話は
プロジェクトに関わったメンツ全てに責任があるとしか言いようがないですし、
ちゃんと他社の決済サービスと比較して作ったのか？としか言いようがありません。
「ちゃんと他社のサービス見てればわかるだろ？」
という話です。
しかし、このような状態になったという事はもっと根本的な問題点があるはずです。
そこでSI業界を見てきた筆者としては以下のような3点の問題点があったのではないか？と推測しています。
- 一定のセキュリティレベルの基準の低さに気づけなかった開発力
- セキュリティの脆弱性を良しとしたプロジェクト運営
- 問題発生時のリスク管理の甘さ
一定のセキュリティレベルの基準の低さに気づけなかった開発力
7payの問題が発生した際の緊急会見で「一定のセキュリティレベルに対応していた」という旨の発言をしています。
この「一定のセキュリティレベル」というのが個人情報やパスワードの話を指しているのであれば、
非常に低いセキュリティレベルであったと言うしかありません。
普通、プロジェクトにおいてセキュリティレベルを確認するなら共通のチェック項目を持っているはずで、
それらの項目のレベルがそもそも現代のセキュリティ基準に見合っていないという事が考えられます。
しかし、決済サービス専門の新会社であるセブンペイ株式会社を立ち上げて臨んでいるプロジェクトである事から、
セキュリティ基準についても再考した上で臨んでいるはずなのです。
しかし、それらが一切及んでいない基準になってしまったというのが今回の騒動の顛末でしょう。
SNS上では「古い体質の開発会社が云云かんぬん」という形でSIerと呼ばれる会社が古い技術の考え方のまま臨んだ結果だという意見も出ていますが、SIerだったとしても決してセキュリティを甘く見る事はありませんし、何なら銀行系のシステムを作っているような所ならセキュリティ面には万全を期すはずです。
金融庁のチェックも厳しいですし、生半可なシステムなど作りようがないにも関わらず
セブン銀行を持つセブン&アイホールディングス系統のプロジェクトにおいて
セキュリティレベルの基準が低いというのはどういう事でしょうか？
筆者としては、今回の7payの顛末から考えると
開発に関する十分な予算が得られておらず十分な開発ができていなかったのではないか？
と考えています。
開発に対する予算を潤沢に用意しないまま、
よくわからないメンバーに任せ自社開発をしてしまったのではないのか？という事です。
結果、十分な知見もないままプロジェクトが進み、本番運用に入ってしまい今回の事件が発生したと考えるとつじつまがあいます。
後ほどの発表でセキュリティの専門家を今から入れて見直す旨を発表していた事から、社内にセキュリティの専門家がいなかった事は明らかですし、思った以上に体制がずさんだったのではないかと思われます。
セキュリティの脆弱性を良しとしたプロジェクト運営
セキュリティの脆弱性を良しとしたまま進んだプロジェクト運営に大きな穴があったのではないか？
との想定がつきます。
と言うのも、7payはいくつかの協力会社で開発したとの話がありますが、
外部からの接続を伴う決済サービス開発においてセキュリティの話が出てこないはずがなく、
どちらかと言うと要件定義や設計段階で話が出ていた事が容易に想像できるからです。
ウォーターフォールによる開発でもアジャイルによる開発でも
外部接続を伴う決済サービスにセキュリティという設計項目は必ず存在します。
「ユーザー登録」「パスワードリセット」「認証方式」といった項目を順番に設計していく事はシステム開発においては当たり前と言っても過言ではありません。
それらの項目に触れずして決済サービスのシステム開発プロジェクトを進めていたとしても、
株式会社セブンペイを筆頭に協力会社やベンダーも含めて開発を進めていたのなら、
プロジェクトに関わっているメンバーのどこかから指摘があってもおかしくないわけです。
よって、今回セブンペイの仕様については以下のようなプロジェクト運営における問題点があったと想定できます。
- セキュリティの脆弱性そのものがプロジェクト内で指摘されなかった
⇒プロジェクトメンバーのセキュリティ知見のなさが問題 - セキュリティの脆弱性については懸念されていたが、プロジェクト内で指摘する人がいなかった
⇒プロジェクトの風通しが悪くもみ消される体質が問題 - セキュリティの脆弱性について懸念され、検討にも及んだが採用しなかった
⇒セキュリティリスクに対するプロジェクト全体の認識の甘さが問題
どのような状態であったとしても、プロジェクト体制の一新が求められますし、運営メンバーにセキュリティの知見がないなら専門家を入れた所で全面的に言う事を聞かなければ問題は再発するでしょう。
今後、専門家を入れるとしたら専門家を全面的に信じた上での
問題発生に対するリスク管理の甘さ
会見では対応に遅れはなかったという話がありましたが、
問題発生に対するリスク管理にも甘さがあった点がぬぐいきれません。
そもそも2018年はコインチェックのXEM不正流出事件にはじまり、paypayの不正アクセスなど決済機能を持ったアプリに関して様々な問題が発生した年でした。
それらの問題を知る機会が多くあったにも関わらず、今回のずさんなセキュリティ機能しか実装しないままプロジェクトが進んでいたわけです。
もしこれらのニュースが報道された時点で「7payは大丈夫か？」と言う観点でのチェックがなされていれば、今回のような問題は発生しなかったはずです。
しかし、実際にそれらよりもかなり程度が低い実装のまま7payの運用がはじまり問題が発生してしまいました。
そして発生後もサービス全面停止という決断を下すのに2日という日数をかけてしまっています。
本来であれば「身に覚えのない決済がある」とお客様から連絡があった時点で一時的にサービス停止という決断がなされていなければなりません。
にも関わらずサービスを継続したまま原因追及を進め、その間に被害を広げてしまった。
このように対応が後手後手になってしまっている状況から、問題発生に対するリスク管理が一切なされていなかったと言わざるを得ない状況となってしまいました。
本番サービスを開始する前にリスク管理については検討しておくべきですし、「お客様から不正利用の連絡を受けた」時点で「一時サービス停止を実施する」という対応策をリスク管理として唱えておくべきだったわけです。
サービス運用が始まってしまったら停止しにくいというビジネス上の問題以上に、セキュリティ脆弱性をついた被害なんてものは少しの判断の遅れで被害の拡大が甚大ではないという事をもっと自覚してリスク管理を実施すべきだったと結論付ける事ができるでしょう。
今後の展開は？
7/5にはセキュリティ対策を目的とした新組織を発足したとの発表がありました。
しかしプロジェクトリーダーには「二段階認証」すら知らないだろう会見に出ていた経営陣が据えられていた事から、世間からは冷ややかな目で見られています。
加えてセキュリティ面に触れたものの「7payのサービス自体をどのような扱いにするのか？」について触れられていませんでした。
7payのサービス再開について触れられていない以上、今後のスケジュールを明確にしてほしいものですね。
まとめ
セキュリティ以上に根本的な問題を抱えていたであろう7payプロジェクト。
つらつらと私見を書き連ねましたが、今後のプロジェクトの展開にも注目していきたいところです。