見出し画像

【誰にでも分かりやすく】マネーフォワード情報流出事件。つまりどういうこと?

こんばんは。

最近、インターネット上の「セキュリティ」について何かと騒がしい毎日ですね。

でも、「セキュリティ」って、いったい、どういうところから、破られていくのでしょう。

現実の世界では、「財布をうっかり、リュックの取り出しやすいところに入れていた」とか、「スマホを見ながら歩いていて周囲に注意を払っていなかった」なんてことがあると、「隙があったんだ」なんて言われますよね。

犯罪を犯す人が悪いとしても、「隙」自体が責められるのが現実です。

世間を驚かせるような情報流出事件も、こんな風に、私たちが身近にやらかしがちな「ミス」が色んなところで起きているのが原因だとしたら、どう思いますか? 


先日、フォロワーの高月志保さんが、ご自身の記事で、とても気になっているとおっしゃっていた「マネーフォワードの個人情報流出」事件

私も気になりました。

今年5月1日に発表されたばかりの、マネーフォワードという会社が起こした個人情報流出事件です。

マネーフォワードとは、個人向けに、資産管理・家計簿サービスなどを展開している会社です。

私のお金は常にどんぶり勘定なので、特に利用していませんが、聞いたことがある方も多いと思います。

2012年からある会社なので、こういうクラウドサービス(SaaS)としてはそろそろ中堅でしょうか。

今日はこの事件について、現時点(2026/5/16)に公開されている情報と、システム開発者の端くれに居る私自身の経験から、エンジニア外の方にも分かりやすく「なんでこんなことが起きるのか」について考察していこうと思います。


これまでの時系列です。

5月1日(第一報)
不正アクセス公表、銀行連携を停止

5月11日(第二報)
詳細調査の結果、本番データベースに格納されたお客さま情報の漏えいや、本件に起因する不正利用の被害がないこと、本番データベースに対する侵害や改ざんがないことを確認。現時点でパスワード変更等の対応をお願いする事項はないと報告

5月12日(第三報)
銀行連携を順次再開開始

情報元:
『GitHub』への不正アクセス発生に関するお知らせとお詫び(第一報)
『GitHub』への不正アクセスに関する調査進捗および銀行口座連携再開に向けた経過のご報告(第二報)
銀行口座連携の順次再開に関するお知らせ(第三報)

何が流出したのか? 

・「マネーフォワード ビジネスカード」に関わる370件の「カード保持者名(アルファベット)」および「カード番号の下4桁」

だそうです。

流出したのは一般ユーザーというより、ビジネスカードを利用していた方。つまり、法人・個人事業主の方が被害に遭われていると思います。

お金を管理する会社なのに、カード情報の一部が漏洩するなんて、ちょっと怖いですよね。

なぜ、クレジットカードの下4桁?

というか、そもそも。

なんでそんな中途半端な部分が漏洩するのでしょうか? クレジットカードの下4桁なんて。

それは、決済システムの仕組みが関わっています。

私たちのnoteでも、クレジットカードを登録した場合は、このように、カード番号の下4桁と有効期限、カード保持者名などが表示されますよね。

こんな風に、一般的なWebシステムでは、「下4桁+名義+(多くの場合)トークン化された参照ID」なんかを保持しておいて、決済の詳細なプロセスは別途決済システムを担う会社に委託するのが普通です。

つまり、サービスを提供する会社(例えばnoteやマネーフォワード)

決済システム会社(StripeとかPayPalとか)

に情報を渡して、私たちのクレジットカードへ決済を行います。

クレジットカードの決済自体は非常にプライベートで厳格な管理手順が求められますので、多くの場合は自社だけで決済プロセスを行うことはほとんどありません。

でも、サービスを提供する会社でも、上記のように、識別などのため、カード番号末尾や名義は表示してあげる必要がありますよね。

そしてそのクレジットカードが、「どれ」なのかを決済時に識別する情報(さっき言ったトークン)も必要です。

このような仕組みであるため、

サービスを提供する会社(例えばnoteやマネーフォワード)が持っている情報:
「下4桁+名義+(多くの場合)トークン化された参照ID」だけ。

決済会社(例えば、StripeとかPayPalとか)が持っている情報:
「トークン化された参照IDに紐づいた、クレジットカード番号本体、その他決済に必要なその他もろもろ」全部。

という感じになるのが普通です。

つまり、そもそもシステムが必要としたデータがそれだけだったのでしょう。だから流出したのもそれだけだった。と考えるのが自然です。

※マネーフォワード ビジネスカードは、カード発行基盤はインフキュリオンのXardという別会社のサービスみたいですが、おおよその仕組みとしてはこんなイメージだと思います。

(でも:私は名義や下4桁を保存・表示するのをやめてほしい派です。セキュリティリスクが上がるし、最低限下4桁で十分だし)

なぜ、銀行連携が止まるのか?

でも、聞いているとなんだか変な話ですよね。

カード番号などの流出が起きたという事件なのに、なぜ銀行連携を止めたのでしょうか?

それは、「実際には何が」流出したのかということに関わってきます。

流出したのは「ソースコード」を保管する「箱」(リポジトリと呼ばれるもの)です。

ソースコードというのは、プログラムを動かすためのコンピューターへの指示書。

そこには、「銀行とどうやって連携するか」といった「指示」が書かれています。

例えば銀行の裏口に入るための「手順」が書かれている指示書を想像してみてください。

裏口に入るための「鍵」自体がなくても、裏口がどこにあるのか、どうすれば開くのか、どのように裏口が管理され、監視されているのか……といった情報は、指示書から推測が可能ですよね。

同じようにシステムで実際に銀行と連携するために何らかのアクセスキーが必要だったとしても、

ハッカー:「マネーフォワードはこういう風に銀行と取引しているのだから、ここを書き換えれば、マネーフォワードになりすましてアクセスできるかもしれない」

と、銀行システムそのものに対するハッキングの「手がかり」になる可能性があります。

だから銀行は「漏洩した情報で自社のシステムへのハッキングが可能かどうか、また可能だとしたら銀行側のシステム改修や認証情報の破棄などが必要になるかもしれない。精査したい」ので、連携を停止しているのが実情ではないでしょうか。

(注:マネーフォワード自身は「電子決済等代行業者として各提携金融機関との安全性確認のため」と説明しています)

さらには、『GitHub』への不正アクセス発生に関するお知らせとお詫び(第一報)をよく見ると、以下のような記述があります。

・ソースコードに含まれる各種認証キー・パスワードの無効化と再発行の実施(概ね完了)

つまり、各種認証キーやパスワードを、ソースコードに直に書いていたということなのでしょう。

開発者なら「え!?」となる部分かもしれません。
そうでなければ「それがどうしたの?」という感じでしょうか。

あのですね、ソースコードというのは、先ほど言った通り「コンピューターへの指示」なんです。

動かすためにパスワードや認証キーが必要だったとしても、それはソースコードとは別のところに置き、できれば、暗号化したりしておくのが普通です。

ソースコード自体は、関わる様々な開発者が見るものです。

例えば、適当な会議室にボンボンと色んな部屋へのカギが放置されていたら、「え!?」ってなるじゃないですか。

そのビルやフロア自体に入れる人が制限されているとしても、「え!?」は変わらないですよね。

セキュリティは、「必要な人が」、「必要な時にだけ」情報にアクセスできるよう管理するのが基本です。

実際に今回のような事件になりましたし。

ましてや、「実際のユーザーのクレジットカード情報」をソースコードを管理するべき箱に混ぜてしまうのは、本当にあり得ないことです。

もし私がこのチームのメンバーだったら、認証情報の直書きやソースコードの汚染に気づいた瞬間に

「何してるの? 嘘でしょ? 信じられない。やめて」

と発狂して、即座に会議を招集すると思われます。

リーダーだったら……。
うーん。
考えたくない。

現時点で分かっているずさんポイント2点

まとめると、以下の2点です。

ずさんさ①なぜか実際のユーザーのクレジットカード情報の一部をGitHubに上げてしまった

ずさんさ②さらにはソースコードに各種認証キー・パスワードを直接書いていた

ここで、「GitHub」ってなんぞやということを少し補足しておきますね。

そもそも開発界隈では、「開発する時には、Git(ギット)という仕組みを使う」というのがスタンダードになっています。

「Git(ギット)」というのは、ざっくり言うと「いつ、だれが、何の目的で、どのファイルを書き換えたか」を完璧に追えるようにする仕組みです。

それって、なんで必要なんでしょうか。

一般的な事務の仕事でも、複数の人が同じファイルを使う場合、「いつ誰がなぜ書き換えたのか」記録が残らないと、不便なことがありますよね。

「何コレ! 私が書いたところ消えてるじゃん!」
とか。
「このファイル誰かが更新するって言ってたけど、されてないじゃん!」
とか。

まぁExcelとかなら履歴を残すことができますね。

でも、ソースコードは単体ではふつうのテキストファイルに近い存在なので、Gitが無いと、いつどこが変わったのかは闇の中。

ファイルの更新日時と最終更新者を見たって、15時にAさんが書き替えた、16時にBさんが書き換えた、みたいな履歴はさっぱり分かりません。

さらにはAさんとBさんが同時に編集しようとして、どっちかの作業は消えるかもしれません。

「この1文は、いつ誰が何の目的で書いたの?」

と意図が分からず困惑した経験がある方は多いはず。

それじゃまともにチームで作業できませんよね。
だからGitという「履歴を完全に追跡できるファイル管理の仕組み」が必要です。

その上で、GitHubというのは、かなりポピュラーなオンラインのGit管理サービスの一つでしかありません。

「Gitを便利に使えるWebサービス=GitHub」です。

困ったことにオンラインなので、このGitHubの認証情報が漏れた結果、ハッカーがソースコードと、入り混じったクレジットカードの情報を見ることができた。

認証情報の漏えい自体は、起こりうる事態です。

漏洩の経路は明らかになっていませんが、世の中の全ての認証情報は、誰かのミスや勘違い、あるいはウイルスなどでいつでも漏洩しうるんです。それを完璧に防ぐのは難しい。

でも、マネーフォワードの運用体制が悪くて、実際のユーザーのクレジットカード情報の一部をGitHubに上げてしまっていた。

ソースコードにクレジットカード情報なんて、本来は不要であるにも関わらず。

さらにはソースコードに各種認証キー・パスワードを直接書いていた。

だからこそ、さらに大きな問題になっている。

では、実運用をする上で、なんでこういうミスが起きるのか……。
自分の経験から推測をまじえて書いていこうと思いましたが、かなり長くなってしまったので、次回に回します。

続きをお楽しみに。

まとめ

今回は、マネーフォワードの個人情報流出事件を、エンジニア外の方にも分かりやすく説明してみました。

現在明らかになっている情報から、業界標準で見てもかなり「ずさん」な開発体制だったのだと分かります。
(とはいえ、スタートアップではあるあるですけどね)

問題を公表してからの対応(警察への届け出、銀行連携の停止、システム的な再発防止策の策定など)は妥当だと思います。

しかし、一体、いつから開発体制に問題があって、なぜそれが起き、いつ発覚し、いつ公表し、対応したのか……という詳細な時系列が分からないので、現時点での評価は差し控えます。

ただ、マネーフォワードは以下のように報告しています。

本件に関する当社グループにおける詳細な調査の結果、現時点において、本番データベースに格納されたお客さま情報の漏えいや、本件に起因する情報の不正利用等の被害がないことを確認しております。本番データベースに対する侵害や改ざんがないことも併せて確認しており、お客さまの資産や認証に影響を及ぼすものは確認されておりません。

「GitHub」への不正アクセスに関する調査進捗および銀行口座連携再開に向けた経過のご報告(第二報)より引用)

この報告があるため、今すぐ使われていた方が何か対応しなければならない、ということはないと思います。

利用者さんが、少しでも安心できれば良いのですが。

もっと深刻な情報漏えいに発展していた恐れもありますので、ここで問題に気づけたのは、むしろ良かったかもしれません。

そして、本当は「なぜこういうことが起きるのか」を一般論に広げて書きたかったのですが、誰にでも分かりやすく書こうとしたら、それだけで記事が長くなってしまいました……。

まぁ、そんなこともありますよね。

続きはこちらです。

最後まで読んでくださり、ありがとうございます。


#YeKu
#マネーフォワード
#個人情報流出
#セキュリティ対策
#システム開発
#非エンジニア向け

いいなと思ったら応援しよう!

YeKu@「知る」を優しさに。 最後までお読みいただき、ありがとうございます! 「役に立った」「読んでよかったな」と思っていただけたら、無理がない範囲で応援いただけると嬉しいです。 いつも、皆様のあたたかいお気持ちで活動できています😊