古いRHELを使い続けるリスクを理解していますか？― RHEL 4/5サポート終了まであと僅か
「Software is eating the world」とマーク・アンドリーセンが発言し、実際に多くのビジネスがソフトウェアによる革新によって既成概念が壊される時代になった。よく引き合いに出されるUberやAirbnbのような企業がこれまでの業界の常識をぶち壊すことが行えるのもソフトウェアとインターネット、スマートフォンなどによる革新的なソリューションに依るところが大きい。そしてそのソフトウェアの革新の主な勢力はLinuxを中心としたオープンソースソフトウェアであると言っていいだろう。あのマイクロソフトでさえ「Microsoft loves Linux」というキャッチコピーを使うほどだ。オープンソースソフトウェアはWindowsに対して敵対するのではなく補完しあう相手として認められる存在になったのだ。
オープンソースソフトウェアの光と影
世界中のプログラマーやアーキテクトが問題を解決するために企業や組織の枠、国籍や言語の壁を超えて協力し、開発されたソフトウェアは無償、誰がどのような目的で使うのか自己責任として自分の意志で決定することができる。これまでのベンダーにお任せという時代から顧客にイニシャティブが移ったと言えば、美化しすぎているかもしれない。つまるところオープンソースソフトウェアにおける「自由」と「自己責任」は「光」と「影」の存在とも言える。
より現実的なポイントに戻して考えてみれば、「誰もが自由に開発できる」オープンソースソフトウェアは「誰もがいつでも開発を止めることができる」ソフトウェアでもある。
OSSのリスク「コードのサポートは誰の責任？」
基本的にソフトウェアは完璧ではなく常にバグによる不具合の可能性を孕んでいる。そこで企業はサポートと称してそのソフトウェアに対して瑕疵の保証を与える。つまりなにかバグがあれば修正しますという約束だ。それは営利企業であればごくごく自然な経済活動といえるが、オープンソースソフトウェアにもそれを求められるだろうか？ 法的な責任も無いコミュニティのメンバーにそれを強制するのは酷というものだろう。
しかしそれを企業の主軸の活動として捉え、最大級に成功しているのがレッドハットだ。レッドハットは本来、無償のオープンソースソフトウェアにバグの修正という「サポート」を提供することで価値を生み出しているのだ。しかし如何にレッドハットといえどもいつかサポートが終わる時が来る。企業の業務を担うIT資産をクルマに例えてみれば、新車で買ったクルマをメンテナンスしながら乗っていたとしても、いつかパーツが無くなる時が来るし、これまで修理してくれたエンジニアが他のクルマの担当に移ってしまえば、愛車のメンテナンスをやるのは自分しかいないということだ。
古いバージョンのサポートの実態
具体的に見てみよう。Red Hat Enterprise Linux（以下、RHEL）の古いバージョン、RHEL4がリリースされた日は2005年2月15日、通常サポートはすでに2012年に終了しており、延長サポートであるELS（延長ライフサイクルサポート）が終了する日付は2017年3月31日だ。RHEL5はリリース日が2007年3月15日、通常のサポートが終了するのは2017年3月31日。RHEL4のELS終了と同じ日である。なおRHEL5のELSの終了は2020年11月30日だ。つまり来年の年度末にはRHEL4が、来る東京オリンピックの年の秋にはRHEL5がレッドハットからのいかなるサポートも受けられなくなる。
実はOSだけではなくコミュニティからサポートが受けられなくなったソフトウェアについてもレッドハットはサポートを続けているという事実がある。一つの例としてPHP4がRHEL4に同梱されていた関係で、PHPコニュニティのサポートが2007年12月31日に終了を宣言された後も重大な脆弱性に関してはレッドハットがパッチを作っていたことをご存知だろうか。
実例を挙げよう。CVE-2014-8626という脆弱性がある。これはPHPが特定のデータをパース時にバッファーオーバーフローを起こしてしまう脆弱性で、アプリケーションのクラッシュもしくは悪意のあるコードを実行できてしまうという重大なものだった。これが発見されたのが2014年の10月なので、もちろんコミュニティのサポート対象外になる。しかしレッドハットはすぐさまパッチを発行し、顧客はその脆弱性を修正することができたのだ。実にコミュニティのサポート終了から7年後である。
このようにオープンソースとは言えども企業が使うシステムであれば期間を延長してサポートを続けるのがレッドハット流の価値という一例ではないだろうか。
アプリの書き換えかOSのアップグレードか
では、RHEL4やRHEL5で稼働している現存のシステムについてどうしたら良いのか、その時に選択肢は2つしかない。脆弱性のリスクや自社でメンテナンスするコストを考えてそのシステムを捨てる。その場合は同じ機能を果たすアプリケーションを開発するか、別のシステムでその機能を肩代わりする。もうひとつはアプリケーションを最新のOSに載せ替えるか、だ。
当然、10年以上前にリリースされたOSで動いているアプリケーションを完全に書き換えるのは、相当な時間とコストを要するだろう。いまのビジネス状況を考えれば本来的ではないかもしれないが、現実的な選択肢は「最新のOSに載せ替える」ことだろう。
最新のRHEL7は脆弱性への迅速な対応だけではなく、性能が格段に向上し、パフォーマンスを向上させるためのツールも用意されている。同時にOSのセキュリティ機能も大幅に強化されている。アプリケーションを完全に書き換えるコストを考えれば、OSを最新にアップグレードし、そこにアプリケーションを移行するほうが現実的だ。RHEL7ではDockerがサポートされ、アプリケーションを容易に隔離することもできる。
しかしなによりも最新のOSのサポートサービスに加入していれば、脆弱性が発見されたとしてもレッドハットから修正リリースされることは確実だ。古いOSをリスクを承知の上で使い続けることは、壊れても直せないことが分かっていながらそのクルマに乗り続けることに他ならない。企業のコンプライアンスとしても到底受け入れられるものではないだろう。
なおいくつかのシステムインテグレーターは古いRHELからの移行サービスを準備しているという。具体的に移行を始める時には大きなアシストをしてくれるだろう。企業のコンプライアンスを揺るがしかねない古いOSを使い続けるリスクを理解した上で、2017年3月という目の前のデッドラインに向けて適切な対処を取るべきだ。
