パッチ適用と安定稼働の両立を実現 管理者の二律背反を解決する仮想パッチ製品 「PatchPoint」

　「サーバの脆弱性を修正しようとすると、サービスの稼働時間に影響がでる。かといって、セキュリティホールを放置しておけば、不正アクセスの危険性が高まる。あちらを立てればこちらが立たず……そんな管理者を助けるバーチャルパッチアプライアンスが登場した。

	どっちにしても責められる……こんな理不尽ってあり？

　システム管理者にとって、ダウンタイムなくサービスを提供し続けることは至上命題だ。だが「いうはやすし……」のことわざどおり、サーバの安定稼働はそう簡単なことではない。

　特に難しい課題の1つは、セキュリティパッチの適用だ。セキュリティパッチの適用時には、安定稼働しているサーバのライブラリを入れ替えることになり、場合によってはリブートが必要となる。パッチ適用時のダウンタイム、パッチ適用による不具合によるサービスの停止などを考慮すると、これは、システム管理者だけでなく経営者としてもリスクとして把握すべき課題である。

　また、ソフトウェアからバグを完全になくすことが困難なのと同じように、脆弱性を修正するセキュリティパッチも、残念ながらバグや不具合がゼロというわけにはいかない。その上、サーバの環境はさまざまで、動作するアプリケーションも千差万別だ。となると、たとえベンダ側でリリース前にパッチの検証を行っていても、環境によってはサービス提供に障害が生じることもある。

　事実、マイクロソフトが2007年5月にリリースしたInternet Explorer（IE）向けの累積パッチでは、適用するとCPU使用率が100％近くに達し、応答が極端に遅くなるという不具合が生じてしまった。同じことがサーバ側で発生してしまったらどうなるだろう。業務を担うアプリケーションが止まってしまえば、管理者の責任が問われることになる。

　では、十分に時間をかけてセキュリティパッチの検証作業を行い、既存のアプリケーションに何ら不具合が生じないことが分かってから初めて適用すればいいのかというと、そうもいかない。

図1　パッチ公開に対する攻撃コード開発期間

　住商情報システムが実施した、脆弱性とエクスプロイト（攻撃コード）の傾向分析によると、セキュリティパッチが公開され、脆弱性の存在が明らかになってから、それを悪用する攻撃コードが公開されるまでの時間はどんどん短くなっている。パッチ公開から1カ月以内にエクスプロイトが公開された割合はなんと7割。1週間以内に限っても5割という結果だ。つまり、サーバに数カ月もパッチを当てずにおくのは、みすみす攻撃者に入り口を与えるようなもの。パッチを当てるまでの期間が長くなればなるほど、危険にさらされる時間は増え、ワーム感染や不正アクセスなどのリスクが高まってしまう。

　迅速なセキュリティ対応を重視してパッチを適用した結果、システムに不具合が生じると、ユーザーから「アプリケーションが使えない」と突き上げを食らうのは管理者。アプリケーションの稼働を重視してパッチの検証にじっくり時間をかけ、その間に侵入を受けてしまうと、責任を問われるのはやはり管理者。サーバ管理者はこんな理不尽な状況に置かれているのだ。

	発想の転換でサーバに触れずにパッチ適用

　ここで発想を180度転換してみよう。そもそもパッチというのは、不正な処理が行われないようにシステムの動きに何らかの変更を加えるものだ。では、これと同じことをサーバそのものには手を加えず、その手前で実現してしまえばいいのではないか――。

　米Blue Lane Technologiesが開発したバーチャルパッチアプライアンス「PatchPoint」は、こうした考えを具現化した製品だ。パッチの動きを外側で仮想的にエミュレートし、サーバ自体には一切手を加えることなく、パッチを適用したのと同じ効果を得ることができる。

図2　サーバに直接手を加えることなく、外側で仮想的に防御するPatchPoint

　システムは、パッチプロキシの「PatchPointゲートウェイ」と、その設定や管理を行う「PatchPointマネージャー」から構成されている。PatchPointゲートウェイにはアプリケーションプロキシが組み込まれており、トラフィックを詳細にチェックする。もしその中に脆弱性を狙う不審なトラフィックが含まれていた場合は、データの書き換えや破棄など必要に応じた処理を加え、無害化したデータを渡してサーバを保護する。

図3　PatchPointゲートウェイのアーキテクチャ

　最大の特徴は、ウイルスや不正アクセスといった「攻撃」ではなく、「脆弱性」そのものに着目していることだ。PatchPointでは、根本的な脆弱性を修正するためにパッチがどのように動作しているのかを把握し、「あるべき動き」「正しい動き」を取る。

　そのためにBlue Laneでは、MicrosoftやOracleといったベンダのほか、オープンソースコミュニティから提供されるセキュリティパッチをリバースエンジニアリングを通じて解析し、その動作を把握。分析結果に基づき、PatchPoint用の独自パッチ「Inline Patch」を作成する。サーバに直接パッチを適用する代わりに、Inline Patchがアプライアンス側で実質的にパッチの役割を果たしているというわけだ。

	「ゼロデイ」の時間をゼロに

　だからといって、PatchPointを導入すれば、ベンダから提供される正規のパッチを適用する必要がなくなるわけではない。PatchPointが着目しているのはあくまで、セキュリティ上の問題のみ。不具合修正や細かな機能強化などを考慮すると、やはりパッチを適用しないわけにはいかない。

　重要なのは、その作業によって既存のシステムに不具合が生じないかどうかをじっくり見極めるための「時間」を稼ぐことができる点だ。特に現場で「安定稼働」と「セキュリティ」の両立に頭を悩ませているエンジニアにとって有効になるだろう。なお住商情報システムでは、既にPatch Pointの検証作業を1年にわたって実施してきたが、その間、攻撃の誤検出などのトラブルは「ゼロ」だったという。

仮想的なパッチの役割を実現するアプライアンス製品「Patch Point」

　サーバに直接手を加えない仮想パッチゆえのメリットとして、サポート対象外となった古いOSも保護できることが挙げられる。たとえベンダ製のパッチが入手できなくなっても、古いOSが稼働しているレガシーシステムに、正規のパッチと同じ保護機能を提供できるのだ。

　システム管理者にとって、サーバの安定稼働は至上命題。PatchPointを活用すれば、不正アクセスによってそれが妨げられるリスクを抑えるとともに、パッチ適用という日々の運用作業によって生じる停止時間も最小限に抑えることができる。