SIerの呪い：JINSから学ぶ〜とある一つの一般論

JINSは2013/05/01に、先日の第三者によるクレジットカード情報の不正抜き取り事件についてのコメントを公開されました。→コメント

そのコメントの中には脆弱性を突かれたこと、何のミドルソフトウェアが狙われたか、脆弱性を突かれて何をされたかが記述されています。

セキュリティの穴を突かれた事案に対してのコメントとしては、かなり異例なパタンだと思います。

一般的には、このようなコメントは、ここまで何がされたかとか何が起きたかなどは公開されないことが多いと思われます。JINSさんは、同様の被害を防ぐために、意を決して公開されたものと思われます。当然、お金や責任の話に重きが置かれていますが、それでも公開されたことは勇気ある行動だと思います。これは、尊敬に値する行動です。

さて、この度のミドルウエアの話について。

ここまで引っ張っておきながらJINSさんとは全く関係ないけど、一般論の話でも始めようか。

古いバージョンのミドルソフトウエアでの開発

古いバージョンのミドルソフトウエアでの開発は、実際に行われているのかという話。

実際は、ままに行われていると思います。特に、オープン系と呼ばれる業界ではそのような方法を取られていることは少なくないのではないでしょうか。

何故古いバージョンか

あるミドルソフトウエアを動かすための最低条件に、「他のミドルソフトウエアのバージョンが古い世代のものであること」、「流用する他案件事例がそのバージョンで構築されており、その資産を流用するため」等があるんじゃないかなと思います。

その様な条件は、「工期短縮のため」や「資金圧縮のため」等という尤もらしい理由で設定されていることは少なくないんじゃないでしょうか。

それに、システムの設計を依頼する顧客側が、バージョンが古いことによる弊害まで把握してることは少ないので、「安いなら/早いならOK」と通してしまうことも少なくないのかもしれません。

契約と人月の呪い

ある一定規模以上のシステム開発になると、ベンダーは協力会社と言う名のｎ次受け会社を投入します。自社社員だけでは人が足りない場合、IT業界ではママに行われる手法です。

バイトではありませんが、ある一定の期間で契約を結び、ベンダーと一緒になってシステムの開発に従事します。

そこに出てくるのが「人月」と言う単位です。

人月とは、IT業界で人件費を計算するときに使用する概念で、「一ヶ月、そいつを動かすから成果に拘らず最低これだけの費用が発生します」と言う請求を行うために用いられます。

この計算方法は、汎用機が一般的な基幹システムで、パソコンではなく電算機と呼ばれていたような時代では実に扱い易かったものと思います。

今となっては、この人月という単位が呪いのようにのし掛かってきます。

例えば、ミドルウエアのバージョンアップ。

脆弱性の改修を含んだバージョンアップだったとしても、構築中のシステムのバージョンアップを行うには、影響範囲の調査から再セットアップ、ドキュメントの書き直し、試験のやり直し等が求められます。

この増えた作業ステップは、人月の増加につながります。

増えた人月は誰が払うのでしょうか？

恐らく、ベンダーと顧客の間の契約書か、その場その場の相談になると思われます。

イントラのシステムで、ネットワークにつながってないような場合、致命的な脆弱性があっても敢えて放置されている件は少なくないのではないでしょうか。

今回のJINSの件はネットワークに接続されたオンラインシステムでした。このあたりは推測で語るべきではありませんが、何かしらが原因で古いバージョンのままGOされた事で今回の攻撃が行われてしまったのではないでしょうか。

SIer/ベンダーはどこまでバージョン管理を行う必要があるのか

理想論は、「契約書に基づく保守契約期間に於いて、一定の保守業務料＋別途改修料を頂き、責任をもってシステムのバージョンアップ/脆弱性対策を行い続ける」ではないでしょうか。

問題はこの「改修料」です。

(何度も書いてますが)憶測で物事を語るべきではないが、一般的にはこの改修料というのは中々予算計上されません。

閑話：XPを更新せず使い続ける方法の模索

話は大幅に逸れますが、XPの話をしましょうか。いや、エクストリーム何とかの話ではないですよ。Windows XPの話ね。

延ばしに延ばし続けたWindows XPのサポートがそろそろ切れようとしています。そのサポート終了が近づくに伴い、巷では阿鼻叫喚の図が……

この状態で未だWindows XPを使い続ける方法を模索している日本企業は少なくないようです。

これが何を意図するか。

Windows XPからWindows 7や8への更新は「機能面での更新」ではなく、「セキュリティ・サポート面での更新」になります。

この「セキュリティ」に中々日本企業は予算が積めません。

特に日本はオブジェクト信仰が強く、物にはお金を出せるのですが、仕組みには中々お金を出す気になれない構造が出来上がっています。セキュリティ対策のような、目に見えた素晴らしい効果が現れにくい部分では、言い出しても上手いことお金がもらえず、工期の延長も望めません。

顧客はどうするべきか（一般論）

先ずは契約書の見直しになるかと思います。そして、予算の計上。これに尽きます。

契約は、保守契約部分の強化。「金は払わんが保証はしろ」ではなく、「金は考えるけど、ちゃんと保証してよね」、「ヤバイと思ったら、ダマで握り込まずに、必ず報告してよね」、「報告を握り込んだ時は、なにか起きたらマジで全責任追わせるからね」のような内容にすると良いかもしれません。

握り込みによる問題の隠蔽にペナルティをかけ、改修が必要ならお金を出すよと言う継続的運用への投資を行うと、一般的には安全かもしれません。

作る側はどうしたらよいか(一般論)

先ず、ダマで握り込む悪しき風習を捨てましょう。なにか起これば、きっと怒られます。それでも、相手も人間なので、余程の事がなければ話し合いが出来るはずです。黙っていた方が、後からもっと怒られます。

作る技術は当然必要ですが、ただ作ってればいい訳でもありません。

相談をすること。話し合いの場を設けることは何よりも重要です。

オープンソースが危ないのか？(一般論)

これも一般論ですが、このようなセキュリティ事案が発生すると必ずこのようなことを言う人がいます。

「これだから、オープンソースって危ないんだよね」

ここは終着地点ではありません。オープンソースへの誤解は古参SIerでは根深いものかと思います。

「オープンソースってことは、誰がバグの責任取るんだよ。お前が取るんか？」
「どこがサポートだよ。あ？お前が一生サポートすんのか？」
「オープンってことは、誰でもコード見れるんだろ？セキュリティ問題だろうが！」
「誰が触ったかわからんコードなんて、一般企業に入れられるか！」

何て罵詈雑言は腐る程言われてきた経験がある私ですが、オープンソースだから危ないという事はありません。当然、開発が活発なパッケージを選ぶべきですし、脆弱性対策が活発なコミュニティが居るミドルウエアの方が良いに決まってますが、お金を払うコードであれば完璧であるという妄想は抱くべきではありません。

オープンソースは自己責任ですし、転んでも泣かないことが条件になりますが、みんなが活発に利用している「思想である」と捉えれば、そんなに悪いものでもないと思います。

プログラミング言語だってオープンソースのものは少なくありません。

使ってて、「信用できない」なんてのは、言うべきではありませんね。

まとめ

完全にJINSさんから話は逸れましたが、一般論の話として頭に引っかかることがありましたので文章化してみました。

当然、JINSさんとは殆ど関係のない話なので、勘違いされないように、ここにちゃんと書いておきます。

JINSさんはクレジットの決済システムを設計思想から変更されたようです。代行会社に決済をさせるというのは、余計にお金がかかりますが、今後の保険という発想では(現時点で)実に良い選択をされたのかも知れません。

昔からよく言われますが、「最強のセキュリティ対策は、セキュリティ情報を持たない/知らない/覚えない事だ」と言う事ですかね。