そのソースを読んでどう年収診断するのかまるでよくわからない

三井住友銀行などのソースコードが流出　“年収診断”したさにGitHubに公開か【追記あり】
https://news.mixi.jp/view_news.pl?media_id=32&from=diary&id=6394148


前にも7Pay（オムニ7）で開発中のソースコードがpublicで公開していたもんだから漏洩となった件があったが、アレは裁判になったとは聞かないから、違約金をベンダ側で支払ったんだろう、とは思っている。
さすがに、
https://www.itmedia.co.jp/spv/keywords/itsosyo.html
にもストレートな記載はなかった。
画像でさらっと見た感じだと、JavaのよくあるService（ServiceImplとの兼ね合いで書くアレ）だったので、ツイッターのまとめでセキュリティ漏洩で攻撃を受けたらどうすんだ（なんか、そう言っとけば許される、みたいな書き方だったが、考えなしに言っている雑なやつとしか見えない）とか言われていたが、実害があるかというと、そうではないと思っている。
SMBCで開発中のソースが漏洩して一部が変わったとは言え、結局何のシステムに使うものだったかというと、銀行内の事務システムだった。
ネットバンキングとかではない。
銀行内の事務用システムは、接続する必要があるのは銀行内のローカルネットワーク端末であり、L3スイッチとプロキシサーバ、ファイアウォールの設定、サーバ接続用LTEルータのサーバ側のTCP Wrapperの設定等は常識的な設定になっている
（何をいっているのかわからないと思うかたは、情報安全確保支援士（旧セキュリティスペシャリスト）の過去問を見るとだいたいわかる）
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2015h27_1/2015h27h_sc_pm1_qs.pdf
のP10とか。

とすると、ファイアウォールが許すのはプロキシサーバ経由なので、外部から事務システムのURLが仮に分かったとしても、直接接続はファイアウォールにリジェクトされてドロップログに残る。
このシステムで一番漏洩すると大変なのは、顧客データを暗号化・復号する際の共通鍵（AES等の場合）または秘密鍵（RSA等の場合）だが（漏洩した場合、鍵が危胎化する）、銀行内のシステムでわざわざ公開鍵を配る必要はないので、およそopensslで作成した共通鍵をサーバにReadだけ許可したのを置いていると推測できる。
で、DB接続の際に暗号化した接続パスワードなりを共通基盤側のレイヤーで復号して、DBのデータの暗号化バイナリ部分をやはり共通基盤側で復号してから取得する、とかになるとは思う。
で、アプリケーション側の実装者はそんな暗号化復号の処理まで書くか、というと、そんなことはない。みんな使う部品なのだから、共通基盤のような下のレイヤーで開発する。
前はCでこんなこと書かされたもんだから、イヤになった。
https://blogs.itmedia.co.jp/komata/2011/02/caesopensslmcry.html
ということは、アプリケーション側の実装者はそれらを意識しないので、そういうfatalなものが漏洩したわけではないから、SMBC的にはセキュリティ的にfatalな漏洩という認識はないということなんだろう、と推測される。
また、DBに登録するデータの暗号化をハッシュ関数で済ませているような雑なシステムだと、レインボーテーブルでやられるかもしれない。

独自の暗号化を使わないのか、というやつは、ダメなタイプですね。
イノウーは素直にバカにしていますが、みんな心の中でバカにしているので、迂闊にも言わない方がいいです。
https://el.jibun.atmarkit.co.jp/pressenter/2020/09/_19_3.html

「公開鍵方式がなんだかわかってるんですか」
　「それぐらいわかってるわさ」伊牟田課長は反射的に返したが、続く言葉はやや自信なさげだった。「あれだろ、キーを公開しとくやつだろ。言ってみりゃ、自分の家のスペアキーを表札脇にかけとくようなもんじゃろが」
　「はあ？　全然、違いますよ」

（・・・）

公開鍵方式は、鍵配送問題を解決するために考案された画期的な手法だ。世の中に強力な暗号方式はいくつもあるが、それらは全て暗号化と復号に同じキーを用いている。鍵配送問題は、アリスが暗号化に使ったキーを、復号してほしいボブに送るときに生じる問題だ。キーが第三者キャロルに流出した場合、キャロルは暗号化された内容を解読することができてしまう。そのためには、キーは絶対安全な経路でアリスからボブに送る必要がある。だが、そもそも絶対安全な経路があるなら、平文をその経路で送信してしまえばいい。公開鍵方式は、復号のためのキーを「送信しない」という発想で、鍵配送問題を解決している。

・・・

アリスが公開鍵と秘密鍵を生成し、公開鍵は文字通り公開し、逆に秘密鍵は外部からアクセスできない場所に秘匿しておく。ボブは暗号化したい平文を公開鍵で暗号化し、アリスに送信する。送信された暗号文を復号できるのは、アリスが持つ秘密鍵だけだ。秘密鍵は一度も送信されていないので、他の誰にも復号できない。
　「なるほどー」マリは納得したように何度か頷いた。「考えた人、天才ですね。でも、ちょっと疑問なんですけど、公開鍵の15 は誰でも見られるところに置いておくわけですよね。15 がわかってれば、秘密鍵の3 と5 もわかっちゃいませんか？」
　「実際はもっと桁数が大きい数字なんだよ」
　「どれぐらいですか」
　「キーの長さが2048 ビットだと、だいたい600 桁ぐらいだったかな」
　「600 ですか？　それぐらいなら......」言いかけてマリは目を見開いた。「あ、600 "桁"？　え、それっていくつ？」
　事務系のシステムであれば、扱うのはせいぜい8 桁、よくて10桁ぐらいの数字までだろう。そもそも単位として兆ぐらいしか知らない。
　「それでも計算することはできますよね？」
　「もちろん。ただ、今のところ大きな数の素因数分解を高速に行う方法ってないから。2 で割って、3 で割って......って順番に割っていくしかないんだよ。そもそも今のコンピュータって、割り算が苦手だから、600 桁の素因数分解を終わるのに、かなり時間がかかります。スパコン使っても同じです」
　「どれぐらいですか？」
　「正確には知らないけど数千万年ぐらいかな。それが仮に100 年だとしても、実用上は解読できないのと同じだよ」

・・・

　「だからマギさんが作った暗号化システムを使うんですか？」
　「その方が安全だからな」
　「どうして安全だってわかるんですか」
　「だってさ」伊牟田課長はせせら笑った。「公開鍵方式は、仕組みが知れ渡ってるんだろ。そんなの、普通、ありえんだろう。凄腕のハッカーが仕組みを調べて、脆弱性を見つけるかもしれん。マギさんのシステムは、仕様が非公開だからな。調べようがない。どっちが安全か、普通の頭ならわかりそうなもんだろ」
　「仕様が公開されているってことは」ぼくは反論した。「世界中の専門家の目で検証されてるってことです。マギさんのシステムって、何人が検証したんですか。二人ですか。それとも三人？　どっちが信頼できるかなんて、普通の頭ならわかりそうなもんですけどね」