三井住友銀行（SMBC）の業務システムのプログラムソースコードの一部が流出してGitHubに公開されていたということで、ネット上で大騒ぎになっております。NTTデータ子会社のコードも公開されているという情報もあります。
今回の流出では顧客情報の流出はなく、セキュリティに影響はないと三井住友銀行は説明しているようですが、今回の事件の闇の深さを考えてみたいと思います。
事件の概要
事の経緯としては、Twitter上であるユーザー同士が煽り合いとなったことから、そのうちの1人の過去ツイートからGitHubアカウントが特定され、そこに公開されていたソースコードの中に「SMBC」の文字が発見されたという経緯のようです。
その後、該当のGitHubアカウントの持ち主本人が、年収診断サービスにアップするためにGitHubに公開したことを認めたという流れです。
そしてSMBCのソースコードを流出させた人は、SMBCの人間ではなく「委託先」の人だそうです。
委託先とは？
委託先の人と言っても、IT業界の場合は「客先常駐」の開発スタイルが多くのプロジェクトで採用されております。銀行のシステムとなれば、ほぼ間違いなくこの委託先の人はSMBCの開発現場へ入場して開発を行っていたと考えられます。
IT業界では客先常駐型の多重下請け構造が昔から一般的に行われてきております。
多重下請け構造という言葉自体はそれを聞けば誰でも理解できると思います。発注元のSMBCがあって、そこから元請け企業に開発の仕事が発注され、以下ピラミッドのように下請けに仕事が流れていきます。
これだけ見ると多重下請けの末端の会社がSMBCのまったく預かり知らないところでコードを流出させたようにも見えますが、IT業界では「客先常駐」が昔から行われてきているスタイルですから、末端の下請け企業のオフィス内で開発が行われていたのではなく、末端の下請け企業の従業員がSMBCが用意したプロジェクト現場に派遣されて、そこで開発は行われていたと推測されます。
何らかの方法でソースコードが持ち出された現場も、末端の下請け企業のオフィスではなくてSMBCの現場からだったと、IT業界の人間であれば誰でも思うはずです。
流出させたのはどこの誰なのか？
それではソースコードを流出させたのは一体どこの誰だったのでしょうか？もちろん情報として公になっていないため我々にはそれを知る方法は無いわけですが、SMBCとしても流出させた人間がどこの誰であったのかわからないと思われます。
SMBCとしては元請けとなる企業にシステム開発の仕事を依頼しているわけですが、元請け企業の人間が開発していたとも限りませんし、元請け企業からはピラミッドのように多重下請け構造で商流が組まれているわけです。
不思議な話ですが客先常駐スタイルの開発現場では、その現場で同じプロジェクトメンバーとして一緒に仕事をしている人達が、実際にどこの会社に所属しているのかということは、お互いにわからなかったりします。隣の席にいた元請け企業の社員さんだと思っていた人が、実はどこかの零細企業の社長さんだった、みたいなことが普通によくある話です。
どこの会社にも所属していないフリーランスの人も開発現場にはたくさんいます。IT業界の外の人からすると、銀行のシステムの開発くらいになればさすがにそんなことはないだろうと思われるかもしれませんが、そんなことはありません。大手銀行の開発現場にもフリーランスの人はたくさん紛れ込んでいます。
しかも実際の所属会社を偽って現場に入ることなど日常茶飯事ですから、仲良くなって一緒に酒を飲みに行く仲にでもならない限りは、お互いに本当の所属がわかることも中々ありません。
よって今回ソースコードを流出させた人間についても「多重下請け構造のどこかに存在した人」ということしかわかりません。SMBCが本気になって流出させた人の所属を調べようとしても、所属が判明しない可能性も普通にあります。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
多重下請け構造のリスク
多重下請け構造には大きなセキュリティリスクがあります。上述の通り「どこの誰かもわからない人間」が機密情報に溢れた現場に入ってきてしまうからです。
過去にはベネッセのシステムで顧客情報が流出した事件がありましたが、その時も流出させた犯人は現場に常駐していた外部の人間でした。
単にモノを作るだけであれば納品されてくる物の品質が担保されていれば、どこの誰が作っているのかはあまり重要ではないかもしれません。しかしシステム開発においては顧客情報等の機密情報を取り扱うことも頻繁にありますし、開発するプログラムそのものが機密情報となることが普通です。
そんな機密情報に溢れた現場に「どこの誰かもわからない人間」が当たり前に自由に出入りしている状況が大きなリスクだと私は考えています。
しかも顧客企業も元請け企業も、開発を担っているプロジェクトメンバーの本当の所属は誰も把握していない状態。
銀行のようなセキュリティを重視する開発であればなおさらのこと、長年に渡って多重下請け構造のリスクが放置されてきたことには疑問を感じざるを得ません。
「リモートワークはセキュリティのリスクがあるから禁止だ」とか言い張る前に、多重下請け構造のリスクにももっと真剣に向き合うべきでしょう。
去年に1回目の緊急事態宣言が出た時くらいの私のツイートが悲しく響きます。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
ソースコードを外部に持ち出した手段
多重下請け構造のリスクを放置してきたようなセキュリティの緩さはあるにせよ、銀行のシステム開発プロジェクトともなればインターネットに接続することもできないなど、現場のセキュリティは強固なイメージがあります。これは実際強固だと思われます。
ではどうやってソースコードを外部に持ち出せたのでしょうか？
これについては具体的に書いてしまうと問題がありそうなので詳細は割愛させていただきますが、実際にはソースコードを外部に持ち出す方法は色々とあります。全部を完璧に防ぐことは極めて困難かもしれません。
ひどい現場になると、開発の進捗が芳しくない時に自宅で仕事ができるようにするために、開発に必要な情報を外部に持ち出せるように”穴”があらかじめ用意されているようなこともあります。
全ての情報漏えいを完璧に防止しようと思ったら、インターネット含む外部との接触を全てシャットアウトして、メンバーをプロジェクト現場に軟禁して閉じ込めておくくらいしか方法はないかもしれません。
そのような非現実的な方法を考えるよりは、危険な人物は開発メンバーに加えないようにする、当然メンバーの身元はしっかり確認する、メンバーには損害賠償を含めた機密保持に同意させるなどの施策が必要と考えます。
GitHubは禁止するべきなのか
もし今回の事件をふまえて「GitHubは禁止するべきだ」という話がどこかで持ち上がっているようであれば、その考え方はナンセンスだと言わざるを得ません。リスクのあるものを一々全部禁止してしまっては何もできなくなってしまいます。
どんな道具も使い方次第です。包丁を使った殺傷事件が起きてしまったからと言って「料理で包丁を使用することは禁止」とはなりませんよね。それと同じことです。
大事なことは、間違った使い方をすれば怪我をするかもしれないから、正しい包丁の使い方を学ぶことです。
そして今回の事例でいえば、包丁を振り回すような危険な人（勝手にGitHubにコードをアップさせてしまうような人）を現場に紛れ込ませないことも必要でしょう。
今回の事件の全容はまだ明らかになっていない部分も多いと思いますが、”IT業界の闇”と呼ばれる部分も深く関係しているかもしれません。
