世間を騒がせたJINS PCのクレカ情報流出事故の報告が発表されたようです。
不正アクセス（JINSオンラインショップ）に関する調査結果（最終報告）
これをうけて、エンジニアの方々のエントリーがいくつかあるようです。
また、発表されたStruts2の不具合については下記の通り報告があるようです。
- Apache Strutsソフトウェアの脆弱性を利用した攻撃の危険性 - NRIセキュアテクノロジーズ
- Apache Struts のException Delegatorにおける入力値処理の不備により任意のJavaコードが実行される脆弱性 (CVE-2012-0391)に関する検証レポート - NTTデータ先端技術株式会社
まあ、技術的な側面での考えはだいたいこんなもんかなとおもいます。
で？
技術的な側面に向けての記事書いたって、
もう二番煎じだし、
技術が優れている人がJava6以前使うなとかRuby1.9以前使うなとか
いろいろ発言されているので、
技術がない僕としては自分の興味にそってなんか書こうと思います。
で、僕はまあ、精神的にアレな人なので、
人間のもっと暗黒面というか、
どろくさい部分に目を向けたいと思います。
再発防止策から読み解いてみよう
JINSでは再発防止策を下記の通り発表しています。
- PCI DSS(Payment Card Industry Data Security Standard)への準拠
- 外部の決済代行サイトの利用
というわけで、JINSでは内部でカード決済の機能を使わないように、
システムの仕様を変更するということですね。
じゃ、なんで最初から決済代行サイトを採用していなかったのかな…(´・ω・｀)
理由はいろいろと考えられます。
- 決済代行サービスの利用料が高かったのでカード決済の機能を作成したかった
- カード決済機能に実績のあるベンダーから自前で機能を抱えることを提案された
いいにおいがプンプンする所で、
事故の根本原因(と考えられるもの)が
前者だとユーザー側にあって、後者だとユーザー側にないということになりますね。
実際にどういう経緯があったかはわかりませんが、
まあ、事故のあとの報告としては後者の方に倒したいところですね。
言葉遊び・数字あそび
ところでITシステムにおいて、tabula rasaなるユーザーにおいては、
システム開発のプロフェッショナルたるシステム開発会社にアドバイスをもとめるわけで、
先の理由の部分、いくらでも書き換えられます。
- 決済代行サービスの利用料が高かいとベンダーから報告を受けたので、自前で開発することを決定した
- カード決済機能に実績のあるベンダーから自前で機能を抱えることを提案された
こうなってくると、もうベンダーの方は完全に負け戦になります。
特にこういう提案資料とかの金額の部分って、いくらでもごまかせます。
こういった類の本が売られているほど、
数字というのはうそをつけるし、
数字によって騙されやすいもののようです。
まあ、企画提案書とかどうなっていたのかわからないから、
推測の域を出ませんけど、
もしかしたら、
スクラッチで開発する方が、外部の決済代行サービスを利用するよりも安くなるような
資料があるかもしれません。
だって
システムを開発する会社からすれば、
開発機能を増やして、
売上を高くしたいですからね…
(利益を高くするでないところに注意)
人間的、あまりに人間的
人間、一度成功を体験すると、
- もっと挑戦をして、成功を体験したい
- 同じ手法にて成功を増やしたい
こんな欲望が発生するかもしれません。
まあ、純粋に技術者だったら前者ですが、
企業としては確実に成功を狙いたいですから、
後者のほうを選ぶことが多いかもしれません。
ということで、Struts2のバージョンが云々とありますが、
その古いStruts2のバージョンでの成功の経験がある
リーダーないし、プロジェクトマネージャーないし、アーキテクトがいたので、
その古いStruts2を採用した可能性は否めません。
で、後者の方を選択する人の常として、
最新情報に疎いことが往々にしてあります。
といったわけでセキュリティイシューを見逃していたことは否定出来ないと思います。
で、笑えない話
ところで、JINSの発表を受けて僕がした適当なツイート、
結構リツイート頂いたようです。
ベンダー「Struts2のバージョンを上げたい」JINS「それ、何が変わるの？いくらかかるの？」ベンダー「機能は変わりません。セキュリティが向上します。～百万円です。」JINS「機能増えないんだ。じゃ、やらなくていい」#システム開発会社として善良なる管理者
— hotchemiさん (@mike_neck) 2013年5月1日JINSさん美味しいネタ提供ありがとうございました。
じゃなかった、
以前、僕が務めていた会社で、
システムを更改する案件があった時に、
お客さんに更改する旨伝えて、お金をいただくわけですが、
なんで機能が増えないのに、お金を支払わないとイケないわけ？
と文句を言われたことがありました。
システムの更改は、ハードウェアの故障率の増加とか、
ミドルウェア、ハードウェアの保守期限が切れるために
行わざるを得ないのですが、
ユーザーからすればベンダーの都合によりお金をとられるのは割にあわないと
感じているようです。
ハードウェア、ミドルウェアの保守期限が切れているため、
壊れてしまえば、もうどうすることもできなくなるのですが、
人間、壊れていないときに、壊れた時の話をしても
ピンときません。
だから更改の提案をするときは本当に嫌がられます。
で、僕のあの適当なツイートはあながち笑い事ではないです。
とりとめのない文章になって来ましたがマトメ
システムの開発・運用って、やっぱり人間的な
ドロドロしたものがあるので、
なんか、もう、アレですね。
(アレ＝適当に察して下さい)
というか、タイトルほとんど関係あらへんがな(´・ω・｀)
0 件のコメント:
コメントを投稿