運用 HotFix管理を始めよう 1．HotFix管理の必要性と混迷 デジタルアドバンテージ 2003/07/04

Windows 9x／Meクライアントの問題点

　まずは企業のWindowsクライアント環境について振り返ってみよう。

　現時点でも、多くの企業でWindows 9x（Windows 95／98／98 SE）やWindows Meがクライアント・コンピュータとして利用されている。メールやビジネス・アプリケーションを利用するという機能面では、これらのクライアント・コンピュータでもまだ現役で十分機能するが、セキュリティ管理という面で見ると非常に問題が多い。

　これら16bit Windowsと呼ばれるWindows OSは（カーネルの一部に16bitコードが残されているためにこう呼ばれる）、本来、個人向けPC用OSとして開発されたもので、コンピュータやユーザーを組織的に管理することを前提としていない。よくも悪くも、「個人が自由に何でもできるパソコン用OS」である。具体的には、これらのOSでは、管理者には迷惑な次のような操作が可能である。

• ESCキー入力でログオン・ダイアログを無視できる（匿名ユーザーでも自由にコンピュータにアクセス可能）。

• ユーザーが自由にローカル資源の共有設定を行える（共有フォルダや共有プリンタなどを公開できる）。

• コンピュータに対するパスワード・ベースのアクセス制限をユーザーが自由に設定可能（ネットワーク管理者の預かり知らないところで、コンピュータの利用が制限される）。

• 自由にアプリケーションをインストールできる。

• 自由に設定変更できる。

• ファイルなども自由に消去できる（FATにはアクセス制限機能がない）。

　システム・ポリシーを組み込めば、ある程度の制御（ログオンの強制、パスワード・キャッシュの無効化など）は可能だが、これも完全とはいえない。またWindows 2000／Windows Server 2003のActive Directory環境では、グループ・ポリシー（GP）を利用した集中管理が行えるが、これら16bit Windows OSでは、GPが利用できない。

　つまりこれらは、管理者の預かり知らないところで何が起こるか分からない、管理困難なOSということだ。

　結論からいって、安全なクライアント環境を整えるには、こうした16bit Windows OSは排除していくしかない。クライアントOSをWindows 2000やWindows XPに移行し、アクセス権の設定機能があるNTFSファイル・システムを利用し、Active Directory環境を構築して、GPを利用してクライアントの管理を強化する必要がある。少なからぬ出費がかかることや、独自の業務アプリケーションを利用している場合にはその移行作業などもあり簡単ではないが、クライアント管理の第一歩として検討する必要があるだろう。以下では、Windows 2000およびWindows XPを対象としたセキュリティ管理について解説する。

HotFix管理の必要性

　企業のセキュリティ管理のポイントを大ざっぱにいえば、次の3点がある。

セキュリティ管理のポイント

大ざっぱにいえば、セキュリティ管理のポイントとしては、外部からの不正アクセスを遮断するファイア・ウォール、サーバ、クライアントの3点がある。このうちクライアント管理は、作業が煩雑で、これまでに重大な攻撃もなかったことから、おざなりになりがちだ。

　まず第1点は、外部からの不正な攻撃を遮断するためのファイア・ウォールである。いまや、ファイア・ウォールを設置せずに、社内LANをインターネットに接続することはありえないだろう。製品によって機能には差があるが、ファイア・ウォールの基本はパケット・フィルタリング機能である。これにより、主に社外から社内への不正パケットをブロックする。

　第2点は、ファイル・サーバなどのサーバ群のHotFix管理である。Code RedやNimda、SQL Slammerは、いずれもIIS（Webサーバ）やSQL Server（データベース）といったサーバ・ソフトウェアのセキュリティ・ホールをターゲットとするワームだった。このためサーバ側のHotFix管理に対する認識は比較的高いようである。可用性の問題などもあるが、クライアントに比較すると、サーバは台数も少ないので、適用作業が比較的簡単という理由もあるだろう。

　そして3番目がクライアント・コンピュータのHotFix管理である。一部のコンピュータ・ウイルスの中には、クライアント・コンピュータにあるセキュリティ・ホールを攻撃するものがあるが、これについてはウイルス対策ソフトを導入することで、感染を防止することができる。しかしその場合でも、セキュリティ・ホールが解消されたわけではない。

　例えばMS03-008として公開されたセキュリティ・ホールでは、Windowsのスクリプト・エンジンであるJScriptのバッファ・オーバーフローの問題があり、攻撃を受けるとコンピュータが乗っ取られるという問題があった（詳細はHotFix Briefings「Windowsスクリプト・エンジン『JScript』にバッファ・オーバーフローの脆弱性（MS03-008）」を参照）。この場合、攻撃者がセキュリティ・ホールを攻撃するサイトを作り、クライアントからのアクセスを誘導することで、クライアント・コンピュータを乗っ取ることができる。これは、ファイア・ウォールからは通常のWebアクセスに見えるので、ファイア・ウォールのレベルで攻撃を遮断することは難しい。ウイルス対策ソフトで発見することも困難だろう。

セキュリティ・ホールを悪用した攻撃

クライアントのセキュリティ・ホールが放置されている場合には、ファイア・ウォールやウイルス対策ソフトをすり抜けて攻撃を加えることが可能である。

　クライアントのHotFix管理は、台数も多く大変な作業だが、これも正しく行っておかないと、攻撃の対象となってしまう。安全なネットワークを維持するには、トータルなセキュリティ管理が必要だということだ。

混迷極めるHotFix事情

　正しくHotFixを適用して、セキュリティ・ホールをふさぐのが重要であることが分かった。基本的には、マイクロソフトから公開されるセキュリティ情報に目を光らせ、関係のあるセキュリティ・ホールが見つかったときには、HotFixをダウンロードして適用すればよい。

　しかし現実には、そう簡単にはいかない。これには主に次のような理由による。

■提供方法が複雑
　単独のHotFixだけでなく、複数のHotFixをまとめた累積的な修正プログラムやSecurity Rollup Package（SRP）、Service Pack（SP）など、さまざまな方法でHotFixが提供される。管理者はこれら複数の提供方法を把握しておく必要がある。

　これまでは、システムのセキュリティ・ホールをふさぐパッチのことをHotFixと呼んできたが、マイクロソフトはセキュリティ・ホール向けのパッチを「セキュリティ修正プログラム」と呼んで区別している。Windows Updateなどでは、次のようにHotFixが分類されている。

• 重要な更新：主にセキュリティ修正プログラム

• 推奨される更新：そのほか（.NET Framework、DirectX 9など）

• ドライバの更新：新しいデバイス・ドライバ

• QFE（Quick Fix Engineering）：スポット対応。特定の目的のみに限定的に提供されるもの。

　個別のHotFixだけでなく、複数のHotFixがひとまとめにされて提供される場合もある。このうち代表的なのはService Packだろう。Service Packは、過去に公開されたHotFixをまとめて、それらをいっぺんに適用できるようにしたパッケージである。もはやソフトウェア・バージョンの一部といってもよい。アプリケーションの中には、「Windows 2000 SP3以上に対応」など、動作要件にSPを明記するものも多い。

　これ以外にも、複数のセキュリティ修正プログラムをまとめたSecurity Rollup Package（SRP）や、「累積的な修正プログラム」（IE向けなどによく提供される）などがある。

　セキュリティ修正プログラムなどは前出のセキュリティ情報ページからもダウンロードできるが、マイクロソフトから提供される公開ファイルは（ドライバの更新やアドイン・ツールなど、セキュリティ修正プログラム以外のファイルも含む）、基本的にすべてMicrosoftダウンロード・センターに登録され、ここからもダウンロードできる。日本向けだけでも、1500種類を超えるファイルが登録されている。

• Microsoftダウンロード・センター

　このように、HotFixの種類や提供方法には実に多くのバリエーションがある。Service Packや累積的な修正プログラムなど、異なる複数の提供方法において、同じHotFixが含まれる場合もある。場合によっては、適用順序を間違えると、ファイルのバージョン・ダウンが発生することがあるので注意が必要だ（この具体例についてはコラム「HotFixの適用によってもたらされたトラブルの例」を参照）。

■適用による副作用
　多くの場合、HotFixを適用すると、システム・ファイルが置き換えられる。これによってセキュリティ・ホールはふさがれるわけだが、従来使えていたソフトウェアが正しく動作しなくなったり、システム性能が大幅に落ち込んだりするなどの問題が生じる場合がある。

　またHotFixの適用順序によっては、新しいファイルが古いファイルで上書きされてしまう（ファイルのバージョン・ダウンが発生する）場合がある。これを図示すれば次のようなケースである。

バージョン・ダウンが発生する例

この例ではまず、HotFix1で「A.DLL」「C.EXE」「D.DLL」という3つのシステム・ファイルを更新する。しかし次に適用したHotFix2に、HotFix1に含まれるものよりも古い「D.DLL」が含まれていたとする。この場合HotFix2を適用すると、「D.DLL」のバージョン・ダウンが発生する。本来ならばHotFix2のD.DLLはバージョンが古いので上書きされないはずだが、HotFixの作り方（パッケージング）の問題により、バージョンを確認せずに常に上書きしてしまうものがある。このようなHotFixを適用すると、バージョン・ダウンが発生する可能性がある。

　これらの問題が発生した最近の具体例について、コラム「HotFixの適用によってもたらされたトラブルの例」にまとめた。これをお読みいただければ、こうしたトラブルの発生も決して特別なケースではないことが分かるだろう。

■HotFixの調査が煩雑
　前述のような問題が発生する危険があることから、公開されたHotFixを右から左に適用するわけにはいかない。まず、自身が管理するシステムに関係するものかどうかを判断しなければならない。この際、基本的には、マイクロソフトが公開するセキュリティ情報を参照することになるが、必ずしも読みやすいとはいえないし、HotFixの適用によって更新されるファイル・リストの情報が完全には提供されないなど、情報が不足するケースもある。

　最終的には、HotFixの内容（含まれるファイル・リストなど）を自分で確かめる必要に迫られるかもしれない。特に、適用後に何らかの障害が発生した場合などは、どのファイル更新が原因かを調査するために、これが必要になるときがある。具体的には、ファイルの依存関係や、前提となるソフトウェア・コンポーネントやService Pack、HotFixの確認、適用時の再起動の必要性、手作業でインストールする場合のオプション設定、無人インストール用オプション設定などである。しかしHotFixのパッケージには、インストーラごとにいくつかの種類があるなど、専門知識なしではなかなか手を付けにくいのが実情である。

INDEX
	［運用］HotFix管理を始めよう
	1．HotFix管理の必要性と混迷
	2．HotFix管理支援ツール
	コラム：HotFixの適用によってもたらされたトラブルの例

　

運用

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）