三井住友銀行のソースコード流出はなぜ起きたか？

2021年1月29日、三井住友銀行が使っている業務システムのソースコードが、一部GitHubに公開されていることが明らかになりました。

GitHub上に三井住友銀の一部コードが流出、「事実だがセキュリティーに影響せず」

過去に三井住友銀行の行内で使う業務システムの開発に関わった開発者が、なぜかソースコードを保持しており、個人のGitHubアカウントで公開していたとみられています。僕のYouTubeチャンネルでも、主に「ソースコードが漏れるとどうなるの？」とか「GitHubって何？」という人向けに動画を出しました。

今回のようなクラウドサービスが直接の情報流出先になるようなケースでよくある展開として、「これだからクラウドサービスは危険である」という風潮が広がることがあります。これは全く本質的じゃないし、こんなことで日本はこれから大丈夫なのかという鬱々とした気持ちになってしまいます。この辺りの憂いを、さくらインターネット田中社長が的確に表現していました。

車はたくさんの人が事故で亡くなってるけど有益性が勝る、電車は人身事故で何人も人亡くなってるけど有益性が勝る。
githubは誰も殺してないけど、委託先のおもらしで、有益なのに禁止される。
ソフトウェアへの無理解がこんだけ強いのは、ほんとまずいと思う。
安全に使うにはと考えよう！

— 田中邦裕@さくらインターネット社長 (@kunihirotanaka) January 30, 2021

今回の件では今のところ、実際に表立って「GitHubを禁止しよう」と表明した会社はいないようです。このまま杞憂に終わればいいのですが、過去には「何となく不安だから安全っぽい方向に倒しておこう」という実態とズレた意思決定は何度となくされてきたように思います。たとえば有効性が以前から疑問視されているパスワード付きzipファイルのメール添付（いわゆるPPAP）などはその最たる例です。

セキュリティ問題に対するこうした場当たり的な（しかも的はずれな）対処は、よくわかっていない人へのアピールとしては有効かもしれませんが、長期的な課題解決にはつながりません。今回はこの事件を題材に、「組織の構造的な問題を、ある表面的な問題にすり替えてしまうこと」について考えたいと思います。

GitHubは悪の手先か？

今回の事件を目にした人がGitHubについてよく知らない場合、「GitHubというサービスは企業内部のシステムのソースコードを暴露するために使われている？」という誤解をする可能性があります。GitHubの利用を従業員に禁止するという対策を取ることは最も表面的で愚かな対処なので、まずはその点についてフォローしたいと思います。

GitHubとはソフトウェア開発者向けのプラットフォームです。最もコアの機能はソースコードを管理することであり、個人から大企業まで広く使われ、大小様々なソフトウェアのソースコードがGitHubで管理されています。ソースコードは企業内の権限がある人しか見られないようにもできますし、オープンに世界に公開することもできます。

少し理解が難しいのは、「ソースコードを公開することなんてあるの？どんなメリットがあるの？」という部分です。実際、自分が書いたソースコードを一般に公開するというのは、ソフトウェアエンジニアの間ではよくあることです。わかりやすいメリットは、エンジニアとしての実績づくりになることです。もちろん業務で書いたソースコードを公開するようなことは（特別な場合を除いて）あまり無いでしょう。ただし、エンジニアとは仕事でも趣味でもプログラミングをする珍しい生き物なので、趣味で書いたソースコードを一般公開して「僕こんなプログラム書けますよ」というアピールにつなげる、ということが普通にあります。

さらに別の話として、ソースコードをオープンにしながらソフトウェア開発を進めるという「オープンソースソフトウェア（OSS）開発」という手法もあります。広く一般に使われる汎用的なソフトウェアや公共性が高いソフトウェアは、企業内で利用されるソフトウェアのソースコードであっても一般公開されているというケースがあったりします。先日noteにも書いた「東京都 新型コロナウイルス感染症対策サイト」のソースコードがGitHubに公開されていたように、GitHubにはオープンソース開発のためのプラットフォームとしても広く使われています。

何度も繰り返すように世の中のほとんどの「業務で書かれるソースコード」は、たとえGitHub上にある場合でもクローズドで管理されます。もちろんGitHubというサービス自体に悪意や脆弱性があれば禁止されて然るべきですが、セキュリティの専門家を含む世界中のエンジニアに愛されているサービスであり、今のところその懸念は無さそうです。それでもまだ不安な人は、GitHubが2018年にマイクロソフトに買収されていること、グローバルの導入事例にAmerican AirlinesやFordなどのエンタープライズ企業が並んでいることなどを知っておくと安心材料になるかもしれません。

クラウドサービスはセキュリティ問題の巣窟か？

GitHubとは、ものすごく単純化していえばファイル管理用のクラウドサービスです。その意味では、他のストレージ系クラウドサービスと構造上は何も変わりません。サービス特性の違いはあれど、たとえばGoogle DriveやDropboxでも三井住友銀行のソースコードを公開することはできたわけで、GitHubだけが情報流出に使われるリスクがあるというものではありません。

一方、「そもそもクラウドサービスはインターネット経由で使うからセキュリティリスクが高いのでは？」という不安もあると思います。この辺りもちゃんと説明しようとすると長くなるので詳しくは別の機会に譲りたいですが、そもそもインターネットに全く接続できない状態で仕事をするということはほとんどの仕事において不可能になっています。取引先にメールを一通送るのだって、インターネット回線を介しています。その前提に立てば、インターネットに接続された状態で仕事を進めるとしてどうすればセキュリティを最大限担保できるのか、というのが現代における建設的なセキュリティの議論になるはずです。

もちろん、「イントラネット内のファイル共有サーバーとExcelがあれば良くね？」という人を説得するには、クラウドサービスの方が有利な理由を説明する必要があります。ここも説明すると長くなるので過去のnoteを見て欲しいですが、ビジネスモデルやシステム・アーキテクチャなど構造上の理由から、クラウドサービスの方が圧倒的に利便性の高いサービスが生まれやすい状況になっています。

世界中の企業がクラウドシフトしていること、セキュリティに対する十分なコストを払えばそれを補って余りある利便性が得られることについては、嫌というほど伝えていかなければいけないと感じています。

組織の構造的な問題を、別の表面的な問題にすり替えていないか？

他方、セキュリティインシデントに対する企業の対策を見ていると、構造的な問題を棚に上げて、表面的な対策でお茶を濁しているケースが多いと感じます。

銀行など古くからある業界のシステムは、一般に外部のITベンダーに開発が外注されます。特に大規模な開発になると、多くの開発会社がプロジェクトに関わる多重下請け構造を取ることが多いです。今回の三井住友銀行のケースでも、多重下請け構造からくるガバナンスの欠如が根本的な原因ではないかという指摘があります。これについては、全くの同意見です。

GitHubではなくて、ガバナンスが効かない多重下請構造が問題。たまたまソースコード流出が問題になっているが、経産省のDXレポートにも書かれていたように、ノウハウももはやどこにあるかわからなくなっている可能性があることを示唆している。

— 及川卓也 / Takuya Oikawa (@takoratta) January 30, 2021

今回の事件がユニークなのは、実際にソースコードを流出させた本人の発言がTwitterに公開されていた点です。Tweetの内容を信じるのであれば、一般的な感覚からすると、流出に関わった人物は天下の三井住友銀行のシステム開発に関わるにはあまりにもセキュリティ意識が欠けているように見えます。

話題のSMBCのコードをGitHubにpushしてしまった年収300万の人、まだ発言残ってるな。
GitHubが何かもご理解されていないと思われる。 pic.twitter.com/lpxvC071jt

— かと卯 / NAGOYA WITH MEIKO (@hiro32kato) January 28, 2021

多重下請け構造については、あまりイメージが付きにくいかもしれないので少し補足します。大規模なシステム開発になると、一度に数百人を超えるような人数を集める必要が出ることもあります。システム開発を受注した外部ITベンダーとしても、自社の正社員だけで数百人の開発者を確保することは難しいので、人が足りない部分は下請けの会社から補充していきます。僕が実際に聞いたことがある範囲で、「七次請けの会社の社員として開発プロジェクトに関わったことがあります」という人もいました。こうした多重下請け構造型のプロジェクトの場合、そのプロジェクトにいる個々のメンバーがいったいどこの会社のどんな人なのかを把握することがとても難しくなります。

逆に、ある人が七次請けの会社の社員としてプロジェクトに関わる場合を考えてみましょう。開発しているシステムを実際に使う顧客企業とその開発者が所属する会社の間には、実に6つの会社が関わっています。そんな状態では、「顧客企業のためにセキュリティに十分配慮して良いシステムを開発しよう」という気にならない方が自然です。そんな状態でガバナンスを効かせようと思ってもかなり難しいでしょう。

スターバックスでは、アルバイトであっても自発的にスターバックスの価値を体現すべく振る舞います。大規模システム開発では色々事情も異なるでしょうが、少なくともベンダー丸投げの多重下請け構造では発注者が開発者全員に良い振る舞いを自然と促すのは難しいでしょう。Employee Experience（EX）の重要性に注目が集まっていますが、少なくとも従業員を歯車として扱うのではなく一個人としてきちんと向き合うことが、最終的にはリスク回避にもつながるよなーという気がしています。

じゃあ具体的にどうすればいいか？

会社によって課題や状況は異なるので唯一絶対の正解はありませんが、一般にこういう方向で対処した方がよさそう、という意見を最後にまとめます。

究極の理想論は、優秀なITエンジニアを自社の正社員として大量に採用し、開発をすべて自社内で回すということです。それも社内受発注のような関係になってはあまり意味がないので、一定の裁量を持った自己組織的な開発組織が理想です。

しかし、一足飛びにその状態に至ることはまず無理なので、段階的に組織やシステムの構造を変えていくようなアプローチが現実的な選択肢になりそうです。先ほど引用したTweetの主である及川卓也さんが書いた『ソフトウェア・ファースト』では、重要な技術に主導権を持って自社の武器に変えていくことを「手の内化」と表現しています。そこでは必ずしも全てを内製する必要は無く、外注先とタッグを組みながら、あくまでも主導権を手放さないことが重要です。

システム開発を外注しつつもうまくガバナンスを効かせるためには、大きく2つの戦略があると思います。

1つは、開発組織とシステム全体のアーキテクチャ設計ができる人を自社内に抱えるということです。できれば優秀なCTOを採用し、CTOを中心に目指す開発組織やシステムのあり方についての共通認識を作ることができれば、開発に関わる多くのメンバーが目指すべき指針になります。

2つ目は、なるべく小さなシステムに分割しながら、徐々に新しいやり方に移行していくということです。エンタープライズ向けの業務システムは、ともすると「〇〇系システムリプレース○億円！」みたいに超巨大プロジェクトになりがちです。しかし、プロジェクトが大きくなり関わる人が増えるほど、不確実性が増しコントロールが効かなくなります。うまくシステムを分割しながら、少ない人数で小回りがきく開発ができるようなアーキテクチャに変えていくことで、ガバナンスに関わる問題を軽減できるはずです。

今回取り上げたような構造的な問題の多くは組織の問題であり、根本的な解決には大規模な組織変革が必要です。それにはかなりの数の従業員の働き方を変える必要があり、痛みを伴います。しかし、表面的な問題に逃げず、根の深い組織の問題に立ち向うことでしか、セキュリティへの不安に怯え続ける状態から抜け出す方法はないと僕は思います。ぜひ三井住友銀行を始めとする日本の大企業には頑張って欲しいし、僕もnoteやYouTubeで声を上げることで応援していきます。