エンタープライズ:ニュース 2003/02/22 02:34:00 更新


マイクロソフトの次の取り組みは「パッチ精度の向上」

マイクロソフトはプレス向けに行った定例セミナーの中で、Slammerが及ぼした影響と対策について説明した。今後は、パッチ公開プロセスの改善やパッチ精度の向上を図るほか、可逆的な、つまりアンインストール可能なサービスパックの実現にも取り組むという。

 マイクロソフトは2月20日、セキュリティに関するプレス向け定例セミナーを開催した。あの「Slammer」ワーム登場後初の開催だったこともあり、話題はそこに集中した。

 マイクロソフト社内のテスト用マシンにさえ感染したというSlammer。ほぼ1年前に示されたビル・ゲイツ氏による「セキュリティ重視」の方針に沿って、「Trustworthy Computing(信頼できるコンピューティング)」に取り組んできた同社にとっては、最大のインパクトを与えた事件だったという。特に、SlammerがSQL Serverだけでなく、「便利に使ってほしい」という意図で配布してきたMSDEまでもがターゲットになったのは、正直言って予想外だったということだ。

 CodeRedやNimdaによる大きな被害を背景に、Trustworthy Computingに取り組み始めて以来、同社は広範囲なセキュリティ対策を実行してきた。1つは、「情報が分かりにくい」という声に応えての情報伝達面での改善で、電子メールによる日本語セキュリティ情報の配布、Webサイトでの情報提供や専用窓口の設置といった対策が取られてきた。

 またシステム的にも、Windows 98以降搭載された「Windows Update」を強化し、Windows XPでは「自動更新」機能が搭載された。それまで、「パッチ適用という煩雑な作業をエンドユーザーに強いるのは困難だ」という意見があったわけだが、Windows Updateにより、クライアントサイドではかなりの程度、パッチ適用作業の自動化が実現できてきた。

 しかしながらSlammerの蔓延は、これらの対策を講じてもなお、限界があることを露呈させた。

 1つは、OS以外の部分に関する対策だ。Windows Updateで更新できるのは、Windows OSそのものと、これに密接に関連したInternet Explorer関連の修正ファイルなど。クライアントで広く利用されているOfficeスイートのほか、企業システムで広範に導入されている開発ツール、それにSlammerがターゲットとしたSQL Serverといったアプリケーションについては、対象外である。

 そもそも、「SQL Serverは(関連知識を備え、セキュリティ意識の高い)サーバ管理者が運用するものだという思いがあった」(同社セキュリティレスポンスチームの奥天陽司氏)こともあって、SQL ServerはWindows Updateの対象外であり、自動的なパッチ適用はできない状態にあった。そのうえ、「どのシステムに適用できるのか」「どうやって適用するのか」といった基本的な情報が整理されていなかった(整理されていたのかもしれないが、分かりにくかった)だけでなく、実際の適用作業も、ファイルの置き換えを必要とするなど煩雑なものとなっていた。

 マイクロソフトでは、Slammerによる被害を受けて専用対策ツールを配布したが、タイミング的には遅きに失した感がある。

 こうした状況を踏まえ、同社ではWindows Updateの適用範囲を拡大する方向で検討を進めているという。具体的にはまず、OfficeとSQL ServerをWindows Updateの対象に含め、ゆくゆくはそれ以外の全製品についても、同様の仕組みに取り込んでいきたいという。

 だがここで、さらに大きな問題が立ちふさがる。パッチが与える「悪影響」をどうやって回避するかだ。パッチ適用を自動化しながら、それによる悪影響の回避を両立させるというのは、非常に困難な課題だといえるだろう。

パッチが及ぼす悪影響

 Slammerが悪用したMS02-061に限らず、マイクロソフトが提供するパッチを当てることで、かえって新たな問題が発生するというケースは、これまでもたびたび指摘されてきた。

 例えば最近のトラブルとしては、フィックス前のパッチが誤ってWeb上に公開されてしまったり、また改めて公開された正しいパッチを適用すると、今度はOutlook Expressの動作に問題が生じるというMS03-004の例が挙げられる。こうした状況では、たとえSlammerのような悪質なワームが登場しても、ダウンタイムの発生を避けたいあまり、根本的対策となるパッチ適用に二の足を踏むユーザーがいてもおかしくはない。

 同社も一連の問題を認識しており、まず作業面では、ベータ段階の修正プログラムが公開されることのないよう、認証プロセスも含め、ルーチンを改めて見直していくという。同時に、「テストの工数を増やして問題を事前に見つけ、修正プログラムの精度を上げていきたい」(奥天氏)としている。

 しかしながら、例えばMS02-071で生じた、Windows NT 4.0でシステムが突然停止することがあるという問題は、「社内でも、またベータユーザーサイトでもテストを行ったが、そのときには問題が発見されなかった。パッチを公開し、運用していくうちに問題の報告が増えた」ものだという。

 いくら事前にテストを行っても、環境やアプリケーションの組み合わせは千差万別。どんな環境でもうまく動作するパッチ、というのは、バグのないプログラムと同様、おそらく存在しないだろう。結局のところ自衛策としてできることは、組織としてあらかじめパッチ適用に関するルールを定めておき、それに沿ってテストを行った上で適用すること。あとは祈るだけだ。

事前のテストがますます重要に

 奥天氏も、パッチによる悪影響を回避する方法の1つとして、事前のテストを挙げている。

 だがその前に、「まずは、マイクロソフトのサイトなどを定期的に見て、セキュリティ情報を把握してほしい。そして、運用しているサーバでそのパッチが本当に必要かどうか、セキュリティ情報に記載されている“問題を緩和する要素”を参照しながら、判断してほしい」という。

 つまり、あらゆるサーバにパッチを当てるのではなく、必要最低限のマシンにだけパッチを適用することによって、運用に及ぼす影響を最小限にとどめるやり方も「あり」というわけだ。奥天氏はその例として、MS02-070を挙げた。この問題は、Windows 2000では「ドメインコントローラとして使用している場合」にのみ影響がある。逆に言えば、ドメインコントローラとして利用していなければ、当面はパッチを適用せずとも問題はないし、サービスを停止することで問題を回避することもできる。こうすれば顕在的なリスクは存在しない、と見なせるわけだ(もちろん、根本的な対策ではないため、潜在的なリスク――未知の問題――までは回避できない)。

 また、「問題を緩和する要素」には、当面の回避策が記載されていることもある。Slammerの場合はそれに該当する策が「ポートのフィルタリング」だったわけだが、これでも水際で攻撃をしのぐことは可能だ。ただし、こうした一時的な対策が別の副作用を及ぼす可能性を頭に入れておく必要もある。事実、Slammer対策として行われたフィルタリングがDNSサーバ(BIND)に影響を与えたケースもある。

 奥天氏はさらに、個別のパッチを適用する代わりに、サービスパックを待つというやり方もあるという。サービスパックの場合、長時間にわたる事前テストが行われているため、トラブルが起こる確率は低くなるということだ。

 もう1つの対策が、繰り返しになるが、自社環境に合わせた事前テストである。重要なシステムであればあるほど、この作業は不可欠なものであり、あらかじめ検証用の環境を作り上げておくことも有効だ。

 ただ、テストを行うとなると、問題が起きたときに備え、元の状態に戻せるような仕組みが必要になるのだが、現状では、別途バックアップソフトを導入するなどして対応するしかない。特に、個別のパッチならば削除はできても、サービスパックとなると、元の状態に戻すことは困難であり、最悪の場合ははじめからインストールし直すことにもなりかねない。マイクロソフトではこうした状況を踏まえ、サービスパックをアンインストールできる機能を実現すべく、取り組んでいるという。

 また、今回の説明会では少ししか触れられなかったが、「Software Update Service(SUS)」や「Systems Management Server(SMS)」を組み合わせることで、パッチ適用作業全般の効率を向上させられるはずだ。中でもSMSには、パッチ適用作業の成功/失敗を確認できる機能が付属しているが、この機能がさらに他の製品にも広がり、イベント履歴を確認したり、監査作業を行えるようになることを期待したい。

 それでもなお残るのが、システムや技術では解決できない問題だ。仮に新しいパッチについて自社環境でテストを行い、問題が生じたとして、その責任と対処にともなう負担はどこが担うべきだろう? マイクロソフトだろうか、サードパーティだろうか、あるいはユーザー自身だろうか。この部分については、「残念ながら、まだ明確は答えは見えていない」(奥天氏)という。改めて、幅広い層による議論の必要を感じる。

関連記事
▼管理者を悩ませるパッチ適用作業を支援する「SUS」と「SMS」
▼Windows Server 2003には自動アップデートサービスを導入
▼Slammer対策に意外な落とし穴
▼Slammerが残した真の問題点と教訓

関連リンク
▼マイクロソフト

[高橋睦美,ITmedia]