セブンペイ問題の本質(だと個人的に思うこと)


日本のシステム開発の縮図のような気がしてきた。

はじめに

先日起きたセブンペイの不正利用騒動がまだ尾を引いているそうです。

私は、不正利用が発覚した時点では、どうせIDとパスワードを使いまわしている人が被害にあったんだろう的なノリで記事を書いてしまったのですが、どうやらそうではないらしく(すみません)、その後続々とセキュリティ上の不備が指摘されて、大炎上となっています。

ただ、このセブンペイ問題、キャッシュレス決済が今話題ということもあり、テレビなどでさかんに取り上げられていますが、まあ、マスコミの人もどうやら全然わかってないような気がします。

特に、セブンペイのセキュリティ上の脆弱性は盛んにネットで取り上げられていますが、犯人たちがそこを利用したという証拠はありません。

現状で被害者1500人、被害総額約3千万円らしいですが、その手口が分かっていない点こそ大事な気がします。

そして、最近になって、最初に指摘されていた点とは、別の脆弱性が浮かび上がってきています。

その新たな指摘を見ていくと、ちょっと背筋が凍る思いがしたので、自分の経験を含めて書いてみます。

なお、犯行手口に関して、開発段階から内部に悪い中華系の人が入り込んでた説には触れません(ないと言えないところが怖いですが)。

最初の指摘

セブンペイ騒動が起きた日、すぐにいくつかセキュリティ上の不備が指摘され始めました。

大きく3つあります。

1.二段階認証が導入されていなかった。
これが無いと、登録した端末とは別の端末でアカウントが利用されてしまうことになり、犯人が自分のスマホにダウンロードしたアプリでも、他人のIDとパスワードが分かっていればその人に成りすましてログインして、被害者のふりしてチャージしたりセブンペイを利用したりすることができます。

しかし、成りすますためには他人のIDとパスワードを知っている必要があります。

2.パスワードリセットの送付先が登録外のメールアドレスから出来た。
これはちょっとわかりにくいですが、何らかのサービスにログインするときに「パスワードを忘れた方はこちら」みたいなリンクが用意されているのが通常です。

そこで、電話番号と生年月日を入力すると、パスワードがリセットされて、新たなパスワードが自分のメールアドレスに送られてくるという仕組みなわけですが、セブンペイの場合、その新パスワードの送付先メールアドレスという入力欄があって、つまり、登録していたものとは別のメアドに新パスワードを送付できるという仕組みになっていました。

さらに、iPhoneだと登録時に生年月日の登録が必須となっていなかったため、電話番号だけでパスワードリセットが可能になっていました。

つまり、上記1だと、犯人が被害者に成りすますには、被害者のIDとパスワードが必要だったわけですが、この2.の影響でIDと電話番号さえわかれば、他人が勝手にパスワードリセットすることが可能で、しかも、新パスワードは登録済みメアドに送られるのが通常の設計であるのに、犯人(第三者)が自分のメアドに新パスワードを送付できるようになっていたということです。

犯人は、メアドと電話番号(と生年月日)があれば、自分の端末から他人のアカウントのパスワードをリセットして、その新パスワードを使って成りすますことができたことになります。

3.回数制限がなかった
これは、Paypayの時も話題になりましたが、パスワードの入力などで、何回間違えてもロックされない設計になっていて、いわゆる総当たり攻撃という、コンピュータを使って、ランダムなパスワードを当たるまで総当たりしていくという、思想的には古典的ですが、実行するという点では最新の攻撃手法への対策がなされていませんでした。

現状、上記の3つの点が指摘されて、ネットでは大炎上しています。

しかし、最低限メアドと電話番号の組み合わせはもともと流出している必要があるとも言えます。

新たな指摘

上記3つが脆弱性であることは間違いないとはいえ、犯人がどういった手口で不正利用したのかはまだ分かっていません。

メアドと生年月日と電話番号(場合によっては生年月日不要)だけでパスワードリセットが可能だったので、犯人が他人のパスワードを勝手にリセットしてログインし、さらに、クレジットカードチャージ用のパスワードは、総当たり攻撃で突破。

それが、上記の脆弱性を突いた突破方法。

しかし、そこまで普及してないサービス開始直後に、本当にこんな手口で1500人も被害者がでたのでしょうか。

そんなにメアドと生年月日と電話番号の組み合わせなんて出回ってるのだろうか?(まあ、あやしいリストが出回っていても驚きはしませんが)。

また、総当たり攻撃というのはそんなに簡単に利用可能なの?

確かPaypay騒動の時も、同じ指摘がありながら結局総当たり攻撃など受けてなかったし。

もしそうだとしたら、オンラインサービスなんて、知らないところでハッキングされまくってんじゃないかと思うのは私だけでしょうか。

なんて考えていたら、別の情報が出てきました。

というのも、セブンペイは、不正利用発覚から3日後に、外部ID連携を止めました。

そして、この外部ID連携に問題あったという指摘がされています。

[独自記事]7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明

この外部ID連携というのは、最近流行りで、ソーシャルログインなんて言ったりします。

様々なネット上のサービスを利用するとき、新たにIDやパスワードを登録するのが一番面倒ですが、最近では、Facebookアカウントでログインするとか、LINEアカウントでログインするとかが選択できるサービスが増えていて、新しく登録しなくても、別のサービスのアカウントとパスワードで会員登録ができるというものです。

セブンペイもその機能を実装していたらしく、そこら辺の設計に不備があったらしいです。

具体的に2つの不備が指摘されています。

1.外部IDとの連携で成りすまし防止対策が実装されていなかった。
ここら辺難しくてよくわからないのですが、記事を読む限り、TwitterのIDやLINEのIDでもログインできるようにしていた反面、そこら辺の作りが甘くて、TwitterやLINEのIDだけでログインできる状態になっていたらしいです。

要するに、詳しい人達が裏口から他人に成りすまそうとする場合、メアドやTwitter IDだけで十分で、パスワードすら不要な状況になっていたようです。

2.7iDのOpen IDとしてのAPIがガバガバ
正直この話はさっぱり分からない。脆弱性なの?

しかし、記事を読むと、悪い人がちょっと裏側で操作すると、セブン側のユーザーデータベースから、メアド、生年月日、電話番号などのユーザー情報が抜き放題だったらしい。

それがわかれば、なりすましログインやパスワードリセットも思いのままです。これが本当だとしたら騒動ヤバいですね。

この2つ、セブンペイの不正利用が報告された直後に、一部の専門家たちが見つけていたらしいですが、セブンが一週間後に外部ID連携機能を停止するまでネット上などで一切口外してなかったのはさすがですね。

この二つの指摘は、専門的過ぎて私にはよくわからないのですが、自分達のサービスを最先端なものにしようと、外部IDとの連携をした結果、脆弱性が生まれていた可能性があります。

まだ、結論は分かりませんが、犯人が利用したのはこっちなんじゃないだろうか。

個人的な経験

私は、前職では某大手金融機関でシステム開発に従事していました。

プロジェクト内では、ビジネスリードという非常に珍しい役職をしていて、プロジェクトマネージャーの下のポジションですが、開発チームを束ねるITリードのカウンター(右大臣と左大臣みたいな?)でした。

ユーザー側の人間なのに、プロジェクト内部に正式に所属していて、一緒に働いていたシステムコンサルの人達から、初めて見るポジションと珍しがられていました。

なんだかよくわからないと思いますが、社内で使うシステムの開発だったので、ユーザー(社員)の要望を集めてシステムをデザインして、設計書をまとめて、実際に開発します。

その時に、ユーザーからの要望をまとめて仕様書(要件定義書という)を作り、これで行きますよという承認をもらう役割で、それが終わると、仕事は技術者たちを中心にした開発チームに渡るわけですが、そこで出来上がるものを常にチェックしたり、完成品に対するユーザーテストをまとめたり、ユーザーが期待しているものが出来上がるかを最初から最後まで通じて確認する仕事でした。

まず、「こういう機能がほしい」といったユーザー(社員)の要望を聞いて回ってシステムをデザインします。

そして、パワーポイントとかエクセルとかに、画面のイメージをかいて、こんな感じの画面で、ここのボタンを押すとこういう画面が出てきて、気になったところをダブルクリックすると明細が出てくるといいな、みたいな勝手なデザインをして、ITチームに見せます。

すると、ITチームから、この予算と期間でそんな機能は実装できないとか、その機能とその機能を両立させるのは、システムの裏側が複雑になりすぎるのでやめてほしいとか、そういった話を聞いて、ユーザー側のところに戻ります。

そして、こういう事情があるので、今回はこの機能は妥協してもらえませんかなどと交渉して、システムデザインの最終案をまとめて、これで開発進めてよろしいですかねと、仕様書に各部署の責任者から承認をもらう担当でした。

そして、仕様書を開発チームに渡すと、開発チームの方で、もう少し技術的に落とし込んだ仕様書を作るのですが、それもチェックして、こう作っちゃうと、要件を満たすかもしれないけど、ユーザーのイメージとだいぶ違うから直してほしいなどと修正してもらったりする。

しかし、実際の仕事は通訳に近い。

ユーザーの要望がそのまま実現できる個所など何の問題もありません。

問題は、技術的な問題が発生するとき。

ユーザーの要望が技術的な理由で出来ないことは多々あるのですが、その理由を理解するのがとにかく大変。

言い方悪いけど、もともとコミュ障気味の人も多いし、すぐ知らない用語が飛び交うし、結構大変でした。

しかし、私は理系出身で、何より情報科学の授業で、プログラミングが苦手という現実を突きつけられた経験の持ち主。

課題のプログラムを頑張って書き、よし出来たぞと提出するのですが、私が書いた1000行くらいのプログラムは、動くことは動くのですが、無駄が多いらしく、優秀な連中は同じプログラムを10分の1の100行くらいで書く。

スポンサーリンク

周りから、お前の場合分けは無駄が多いとか、これとこれ入り口は違っても途中から処理同じだから重複してるとか、センスがないとか、散々指摘され、自分の頭の悪さを実感しました。

その経験故に、プログラマーの人達を結構尊敬しています。

しかも、じっくりを腰を据えて聞くと筋道通ってるし、理解できると「なるほど」と腑に落ちるし、最終的に彼らの言っていることが間違っていたことがほとんどなく、言うとおりになる。

だから、プロジェクト内の位置づけとして、本来私は、ユーザーの要望を実現するための役職だったのですが、開発チームの肩を持つ人間として、ユーザーからは反感を買われていました。

デザイン段階や開発途中にいろいろ問題が出てくるわけですが、開発者たちが難色を示した箇所なんかは、ユーザー側から見れば、「そこを何とかするのがお前らSEの仕事だろ!」と発破をかけることが期待されているのでしょうが、私は彼らの意見を尊重して、ちょっと技術的に難しいことが判明したので、そこはユーザー側で我慢してもらえませんかねと、ユーザーに妥協を迫る交渉に行くことがほとんどでした。

しかし、稼働している現行のシステム図を見る限り、私のような担当は珍しく、多くの場合、「いいから要求通り作れや」というユーザーに押されて、リフォームにリフォームを重ねた上にプレハブで増設したような迷路みたいなシステムが出来上がって、そのせいで、ユーザーもIT側もみんな困っています。

その現状を知っていることもあり、「そんな機能が無いのに、よく次世代システムとか言えるなあ」とか「使いづらいうえに、できないことばっかりじゃないか」などと文句を言われることはありましたが、ユーザーの要望をそのまま聞いてITサイドに押し付け、結果としてバイパスだらけのピタゴラ装置みたいなシステムを作って、稼働後も毎日のようにバグやエラーが発生してメンテナンスチームが徹夜で処理し、ユーザー側が、「うちの会社はIT部署が弱くて本当困っちゃう」なんて偉そうに愚痴るような最悪の事態は避けようと思っていました。

なんだか、遠回しの自画自賛の自分語り(しかも事後的に粉飾しすぎ)が長引きそうなので止めますが、結論は何かというと、システム開発というのは、末端で作りこむSE達の上に、その管理者や発注者など、必ずしもプログラミングという、実際の作業を分かっていない人間がたくさん登場するということです。

そして、上流に行くほど、こういうシステムがほしいけど裏側は分からないという人が、予算管理やスケジュール管理を行い、色んな妥協が求められる場面が来ても、その妥協が上手くいかず、裏側がぐちゃぐちゃになるのです。

セブンペイの場合

セブンペイの失敗については、大きな視点から2つの原因が挙げられます。

1.セブンイレブンアプリ内の一機能としてセブンペイを実装した。
2.上述のように、外部IDとの連携を実装した。

まず、1番。

セブンペイは、独立のアプリではなく、既存のセブンイレブンアプリ内に無理やり組み込まれる形で開発されました。

これは、発注者がキャッシュレス決済の動向をよく勉強している人なんだと思います。

私も他の記事で書いてるように、決済というのは客が企業のサービスにチェックインしてからチェックアウトするまでの途中の1場面でしかない。

したがって、ペイメントだけに注目してサービスを設計するのは視野が狭い。

セブンが頑張って普及させたnanacoを捨ててまで、セブンペイを普及させようとし、しかも、セブンイレブンアプリの一機能として実装したのには意味があります。

単にモノを売るだけでなく、様々なサービスのハブになり、さらには地域コミュニティのハブにもなる可能性のあるコンビニ。

そういった可能性を追求して、次世代型のコンビニとなるために、通販サイトで買った商品を自分の都合に合わせてコンビニ受取にしたり、美術館やコンサートのチケットをネットで買ってコンビニで発見したり、なんらかの地域活動の拠点になったり、様々なサービスを実現する窓口としてのコンビニを裏側から支える、総合的なサービスアプリとしてのセブンイレブンアプリを作りたかったのだと思います。

毎日セブンイレブンを利用する人は、毎日スマホのセブンアプリを利用するような状況。

セブンイレブンを利用する人のスマホにはだれでもセブンアプリが入っていて、様々なサービスを利用できるだけでなく、その利用時に支払いはアプリ内のセブンペイで出来る。

そういった未来を描いていたからこそ、決済だけに特化した独立のセブンペイアプリを作るのではなく、セブンアプリ内のあくまで1機能としてセブンペイを実装したのだと思います。

そうすると、外部ID連携も見えてきます。

最新鋭の総合サービスアプリとしての未来を見据えれば、当然、ユーザーの利便性の観点から、最近流行りの外部ID連携も実装して、余計な会員登録の手間を省いて、少しでも多くの人に使ってもらおうとしたのだと思います。

そして、外部ID連携の肝は、セブンアプリにLINE IDやTwitter IDでログインできるだけでなく、7iDもそういった外部連携したIDの仲間入りしたということです。

つまり、セブンイレブンアプリを使っている人が、他のサービスにログインするときに、LINEでログイン、Facebookでログインなどと同じように、7iDでログインできるようになったわけです。

野心的試みです。

まとめると、セブンイレブンは、単にモノを売るだけでなく、様々なサービスの窓口となる次世代型のコンビニの開発を進めていく中で、それを裏側から支える総合サービスアプリを設計しようとしていたのだと思います。

とすれば、決済を独立させずにその一部として設計して、リアルとネットをまたがり、チェックインからチェックアウトまで決済を含む一連のサービスを一気通貫でデザインするというのはこれからの時代に不可欠な発想。

(おそらく担当者たちは相当アマゾンを研究してる)

そして、そういった最新鋭のシステムを作るのであれば外部ID連携は必須だし、また、今後のユーザー行動の収集という観点からも、7iDが他のサービスのログインに利用され、セブン側で会員の他のサービスの利用状況を把握するのは必須。

こう考えると、アマゾンなどをよく勉強し、これからのコンビニ論やアプリ論を意識した、未来志向なシステム設計で、経営学部のゼミなんかでは満点じゃないかな。

しかし、LINE PayやPaypayを認めざるを得なくなって、なんとしても速やかにセブンペイをリリースしなくてはいけないという厳しい時間的プレッシャーがあった。

そして、あるべき理想の次世代型アプリの設計と、QRコード決済の導入の時間的制約について、妥協ができなかった。

あるべき姿を仕様書にまとめて開発チームに渡して、少ない予算と厳しい日程の突貫工事で作らせたんでしょう。

美味しい餅の絵を書いて、技術者(外部ベンダー)に渡せば、その通りできるかと言えばそんなことは無いです。

プログラマーがプログラムを書けばなんでもできるような気がしますが、ビルや橋の建設と同じで、現場では様々なトラブルが起きていろいろ大変。

これが、やったことない人には想像がつかない。

特に、一定以上裏側を複雑にすると、手に負えなくなって、エラーやバグが頻発するというのが、やったことない人には分からなくて、現場の手抜きのように感じてしまう。

家やビルの設計は、3次元の図面がありますから、「柱が重なってますね」なんてあるわけないのですが、プログラムの場合は、文字列でどんどん足していき、現実の最終形は頭の中に描くしかないため、どこで何が起きるかどんどん把握できなくなってくるので、事後的なバグやエラーはある程度仕方ないのですが、やったことない人にはそれがどうしても理解されない。

また、この業界には、キャリアアップのために「大手コンビニチェーンの決済系システム開発にプロジェクトリーダーとして従事」なんて職務経歴書に書きたいだけのような輩も跋扈している。

そういった連中が安請け合いして、現場に無理をさせて、突貫工事をさせる。

そして、現場が破裂寸前になりながら開発に取り組み、最後の最後で、「ボルトが合わない」みたいなトラブルが発生したときに、今さらスケジュールもずらせないし、「よーし、接着剤で止めよう」みたいな話になる。

そして、地震が起きると、屋根が落ちてきたりする。

発注側も、役所の監査役と対して変わらず、表側の、要求通りの機能が実装されているかばかりチェックして、裏側に関しては、「強度計算は大丈夫か」とか「安全性テストはしたか」とか、表面的なことしか聞かないしわからない。

考えてみれば、外部ID連携なんて、簡単に言いますが、各種SNSサービスと連携するなんて言うのは、裏側が相当複雑でぐちゃぐちゃなんだと思いますが、それを無理やり仕上げた結果、セキュリティ上、穴だらけになったんじゃないかな。

なんか、日系企業のシステム開発の縮図をここに見ることができると思うのは私だけでしょうか。

おわりに

今回のセブンペイ騒動、犯行手口はまだ分かっていませんが、セキュリティ上の不備が、外部ID連携という野心的な部分に由来していたら、システム開発に上流側で関与したことがある人にとっては対岸の火事ではないでしょうね。

上流側で、新システムをああしようこうしようと、コンセプトベースの話で盛り上がることは多く、話が最先端になるほど、これからの時代のシステムはどうのこうのと、意識高い系の設計者は熱くなるのですが、裏側の仕組みをちゃんと理解している人は上流にはほとんどいない(特に大企業)。

会計の世界史を読んで、現代会計の本質を学んだとかいたく感動してる連中の多くが、簿記検定の問題を出したらほとんど解けないのと同じ。

かと言って、開発サイドの声を一生懸命聞いて理解しようとする姿勢の人も少ないし、いつの間にか上流と下流の間に大きな断絶点が生まれる。

その一方で、「その予算と期間でなんとかします」と安請け合いする、ブラック企業的なITベンダーの管理職が登場して、部下に鞭打って突貫工事で無理やり仕上げる。

そういった開発体制が引き起こした事態な気がしたので書いてみました。

開発した末端のSEには、この設計まずいだろなんてぶつぶつ言いながら仕事してた若者も多いんじゃないだろうか。

独立した7Payアプリを作って、それでしか使えない7Pay IDと専用パスワードを要求する閉じたシステムにしてれば、最初に指摘された3つの脆弱性があっても、不正利用なんて起きてなかったりして。

まあ、本当のところは分かりませんけどね。

全然違っていたらすみません。

第1報の記事で、どうせリテラシー低いユーザーがIDとパスワード使いまわししてたんだろと決めつけてしまったので保険としてあらかじめ謝罪しておきます。