セキュリティ・インシデント

気になった事故について、時々レポートする。

インシデント概要

MoneyForward関連サービス・システムのソースコードに個人情報の一部が混入し、同社の採用するコードリポジトリであるGitHubにソースコードの一部として登録されてしまっていた(←社内ルールを逸脱した誤処理)

GitHubの認証情報が漏えいし、第三者がソースコードを入手可能となっていた(改変は不可)

対応

銀行連携サービスの停止(証券会社やカード会社との連携も一部停止)

GitHub保全(認証情報更新)その他対策強化

その他(続報をまとめるつもりがないため、初動のみ記載)

所感

個人情報漏えいなどのインシデントは個人情報保護委員会への報告義務があるために、インシデント発生元の企業は、規模に関わらず、事前に用意したフローに従い、顧客に対して、誠実かつ冷静な対応が可能だ。

ソースコードに個人情報その他の秘密情報を登録しないことは基本中の基本だが、登録できないようにするにはかなりの工夫が必要で、今であれば、AIを活用して自動検知させる？　サービス停止期間を考えると、開発コストアップは致し方なしか？開発サイドからすると、どの程度コストが相場なのか気になるところ。

今後、銀行に、正しく対処したと理解を得ることが出来れば、MoneForwardは通常のネットワークサービス会社より信頼できるといえるのだが、果たしてどうなることやら。

5/12: サービス再開第一号は三井住友銀行系。その日のうちに、他にも続々と再開報告あり。

旧都市銀行系から再開させたいのはよく分かるし、私も望んでいたことです。

旧都市銀行系では、三井住友が迅速調査できる銀行??(今回のインシデント対応速度以外知らないので、あてずっぽうに近いです。でも、関係業者側の対応能力ベンチマークにもなりそう、インシデントへの対応結果が。)

晩にかけて続々と対応完了して、私の契約先ではPayPay銀行だけAPI連携してない状況で、ほぼ復旧した感じとなった。

というかほとんどの銀行が復旧している現状からすると、PayPay銀行には何か問題があるのかも知れない。PayPay銀行の提供するAPIにセキュリティ上の不備があるのか、運用上の問題があるのか。詳細が明らかになることは無さそうだが、今後の預金方針を検討するに値する情報だ。

5/28にPayPay銀行への接続の復旧。断トツ対応が遅かったことを心に留めておこう。

それにして、Moneyforwardの復旧サービス一覧は