セキュリティ管理 ‐ 2004 年 4 月

更新プログラムが嫌われる理由

トピック

	はじめに
	更新プログラムとは
	セキュリティ更新プログラムのテスト
	セキュリティ更新プログラムの管理ツール
	高度なヒントとテクニック
	まとめ

はじめに

セキュリティ管理者が最も嫌いなものが悪質なハッカーであるとすれば、次に嫌うものは更新プログラムに違いありません (以下、"更新プログラム" とある場合、主にセキュリティ更新プログラムを指します)。更新プログラムほど感情的になるものはありません。更新プログラムは、それを作成する開発者、リリースするソフトウェア製造元、導入する管理者などのすべての関係者から疎まれています。おそらく、更新プログラムに好意を抱いているのは、3 つのグループだけではないでしょうか。つまり、パッチ管理ソリューションを販売しているソフトウェア製造元、更新プログラムを導入するコンサルタント、マーケティング ツールとして脆弱性評価を利用するセキュリティ研究者です。

私も、更新プログラムが好きではありません。更新プログラムは、通常の業務を妨害し、保守作業を強要します。だれでも何かを修復する作業には抵抗があります。修復するものが壊れているように見えなければなおさらです。問題は、ネットワークに更新プログラムをすぐに適用しておかないと、実際にどのように壊れているかを攻撃者が十二分に証明してくれるということです。

完全な修復プログラムが存在するとすれば、何の問題もなく適用され、一瞬のダウンタイムも起こさず、どのアプリケーションを破壊することもないでしょう。この時点で、既に夢のような話です。修復プログラムは、攻撃者が悪用可能な特定の脆弱性を解消するために公開されます。その性質上、通常の製品リリースの場合よりもずっと厳しいスケジュールに基づいて公開されるのが一般的です。ベータ プログラムや広範な互換性テストに費やすための時間はありません。通常の製品リリースほどの徹底したテストを受けることができません。これが、更新プログラムによる問題がしばしば発生する理由です。ソフトウェアは、人間がこれまで創造したもののうちで最も複雑なものです。これほどまでに相互関係が錯綜し、その影響が広範囲に及ぶものはありませんでした。あるコンポーネントでの小さな、一見何の害もないような変更箇所が、ソフトウェアの別の部分に巧妙に問題を引き起こすことがあります。この問題は、他のソフトウェアをアップグレードした場合と同様に、更新プログラムを適用した場合に発生することがあります。残念ですが、これは事実です。

本質的な解決策は、最初から更新プログラムを適用する必要性を抑えることです。これは、セキュリティ管理者とソフトウェア製造元の両方に関係する話です。将来のコラムでは、ネットワークを保護するために実施できることと、(できれば) インストールする更新プログラムの数を極力少なくするということについて検討する予定です。ベンダ側に関しては、マイクロソフトの Trustworthy Computing Initiative (信頼できるコンピューティング活動) の主要な努力が、ソフトウェアの品質を向上し、より簡素で堅牢な実装を実現することに向けられています。これらの努力は、実際に実を結んでいます。Windows Server 2003 は、Windows 2000 と比較すると関連する更新プログラムの数がずっと少なく、その深刻度も低くなっています。Windows 2000 の場合、リリース後の最初の 180 日間に 32 の更新プログラムがリリースされ、そのうち 5 つの更新プログラムの深刻度が緊急レベルでした。Windows Server 2003 では、同じ期間に 13 の更新プログラムがリリースされ、深刻度が緊急レベルであったのはそのうち 2 つだけでした。ただし、何らかの理由で Windows Server 2003 を実装していない場合には、これも意味のない話であり、1 つの更新プログラムでさえ余分です。1 つの更新プログラムがあるだけでも、安定性に問題が生じ、作業の妨げになる可能性があります。

更新プログラムが問題の原因となる場合があることから、安定性を優先して更新プログラムをインストールしないという話もよく聞きます。さて、更新プログラムが公開されるそもそもの理由を思い出してください。更新プログラムは、セキュリティ問題を悪用されないために公開されます。システム管理者が更新プログラムを適用するとシステムの安定性を損なうと考えてインストールしない場合に、そのシステムがハッキングを受けるとどうなるでしょう。悪質なハッカーの大部分は、上品なシステム管理者ではありません。ハッカーがシステムの安定性を保ってくれるのであれば、初めから更新プログラムは必要ありません。ハッカーをシステムから一掃するためにかかる労力については、言うまでもないことです。ハッキングを受けたと考えられる場合に必要な対処の内容については、次のコラムで検討する予定です。

ページのトップへ

更新プログラムとは

更新プログラムとは何でしょう。これに対する答えは、たくさん考えられます。マイクロソフトでは、更新プログラムという用語を特殊な意味で使用しています。詳細については、マイクロソフト サポート技術情報 (Knowledge Base) の文書 824684 を参照してください。セキュリティ管理者が "更新プログラム" に言及する場合、実際は "セキュリティ更新プログラム" を指しているのが一般的です。更新プログラムには、セキュリティとは関係のないものもありますが、このコラムは、セキュリティに焦点を当てているため、主にセキュリティ更新プログラムを対象とします。

セキュリティ更新プログラムの公式定義は、システムへの侵入に悪用される可能性のある一部のセキュリティ問題を解決するために公開される更新プログラムです。セキュリティ問題とは、悪用できることが発見された問題、既に一般に知られている問題、または近日中に公表される問題です。最初のカテゴリのセキュリティ更新プログラムは、最も深刻なものです。脆弱性の中には、ベンダが問題を通知される前に攻撃者がその脆弱性の悪用を開始する、いわゆる "zero-day (ゼロデイ)" の脆弱性が存在します。幸いなことに、これらの問題が起こることはまれであり、UNIX や Linux 環境よりも Windows 環境の方がさらにまれです。とは言え、発生しないわけではありません。私の知る限りでは、Windows プラットフォームでこれらの問題が発生したことはほとんどありません。2 番目のカテゴリは、先にベンダに通知される前に、何らかの公開フォーラムに投稿された問題を含みます。ベンダが対策を講ずる前に、潜在的犯罪者がこれらの問題を悪用するということが何度かありました。そのため、発見者がその内容を公表する前に、ベンダが問題に対処できるような "責任ある開示" を求める動きが活発になりました。残念なことに、どういうわけか一部のアプリケーション セキュリティ分析者は、正しい行為として推奨されるこれらの社会的規範に従わないため、顧客は危険な状態に置かれ、ベンダは慎重に開発してテストされたサービス パックより品質的に劣る可能性のあるセキュリティ更新プログラムを次々に公開しています。リコールおよびリリースされたセキュリティ更新プログラムのほとんどが、このカテゴリに分類されます。これとは対照的に、セキュリティ更新プログラムの 3 番目のカテゴリは、発見者がベンダに問題を報告し、ベンダが十分な時間を取って適切に問題に対処した後で発見内容が公表される場合です。

このカテゴリ一覧とは明らかに異なる例は、ベンダにより発見された脆弱性に対する更新プログラムです。まれに、ある種の問題が外部に知られていると確信されるか、見つけられる可能性が高い状況で、ベンダが内部で発見したセキュリティ問題に対する更新プログラムをリリースすることがあります。つまり、外部で発見されたセキュリティ問題に対する更新プログラムを開発している間に、そのコンポーネントの脆弱性が内部でも発見される場合です。この場合、セキュリティ更新プログラムにより、すべての問題が解決されるのが普通です。しかし、内部で発見された一部の脆弱性に対する更新プログラムは、サービス パックまで保留されます。サービス パックは、一般にセキュリティ更新プログラムより厳密にテストされており、安定性を損なう可能性は大幅に低くなっています。また、サービス パックのみをインストールする顧客が多いため、サービス パックの導入率は、通常、セキュリティ更新プログラムよりもずっと高くなります。顧客に対するリスクが低いと考えられる限り、一部の更新プログラムは、サービス パックまで保留するのが一般には適切です。ところが、ベンダはセキュリティ更新プログラムに関する情報をすべて公開する必要があり、そのうえで更新プログラムを適用するかどうかを判断したいという顧客の主張を、これまで私は何度も聞いてきました。しかし、ハイゼンベルクの不確定性原理を適用すると、この主張には無理があることがわかります。何かを (この場合はリスクを) 測定しようとすると、その測定対象が変化します。リスクとは何でしょうか。リスクは、次の関係式で求められます。

リスク = 被害の影響度 × 被害の可能性

顧客がリスクを判定するには、ベンダによってセキュリティ問題に関する情報が開示される必要があります。一方で、この情報が公開されると、脆弱性を使用してシステムを攻撃しようとしている人物も、その情報を手に入れることになります。これにより、悪意ある人物が問題を悪用する方法を正確に見つけ出す可能性が高まり、リスクが増大します。前に述べたとおり、Windows プラットフォームの脆弱性のうち、これまでベンダがセキュリティ更新プログラムをリリースする前に悪用されたことがあるのは、ごくわずかな部分だけです。このことは、セキュリティ問題に関して利用できる情報が増加すると、潜在的犯罪者がその問題を悪用する可能性も高まるという主張の根拠になります。この説は、今後は変化する可能性もありますが、今のところ依然として有効です。

ベンダは、ユーザーに迷惑をかけるためにセキュリティ更新プログラムを公開しているのではないと認識することが大切です。顧客がセキュリティ更新プログラムを管理するために相当なコストをかけている一方で、ベンダもコストと信頼性の両方の点で多大な犠牲を払っています。つまり、セキュリティ更新プログラムのリリースを軽く考えることはできません。セキュリティ更新プログラムがリリースされたら、それを適用するかどうかと、適用時期についてすぐに評価する必要があります。これは、管理業務の一端です。更新プログラム適用のためのリソースの確保が困難だと感じた場合は、その作業がセキュリティ管理における当然の業務である、と経営者を説得してください。私は、将来のコラムで経営者にセキュリティを "売り込む" 方法について執筆したいと考えています。これに関して何か良い提案があれば、ご連絡ください。職業柄、我々システム管理者は経営者へのセキュリティの売り込みが得意ではありません。売り込み方をご存知の方、うまくいった経験のある方は、どうぞお知らせください。

セキュリティ更新プログラムをどれほど迅速に導入する必要があるかを判断するための目安として、マイクロソフトを含む一部のベンダは、セキュリティ更新プログラムが対応する個別の脆弱性に対して深刻度を設定しています。マイクロソフトにおける深刻度と、関連する更新プログラムの推奨適用時期を次の表に示します。

セキュリティ更新プログラムの公開方法には、次の 3 つがあります。1 番目は、単一コンポーネントの 1 つ以上の脆弱性に対する更新プログラムとして、"セキュリティ情報" と共に公開される方法です。セキュリティ情報は、http://www.microsoft.com/japan/technet/security/current.aspx に公開されています。このセキュリティ情報の通知サービスに登録していない場合は、http://www.microsoft.com/japan/technet/security/bulletin/notify.mspx にアクセスして、登録してください。

2 番目は、"更新のロールアップ" を通じてセキュリティ更新プログラムを入手する方法です。更新のロールアップは、セキュリティ更新プログラムを集めたもので、通常は他の更新プログラムも含まれます。セキュリティ情報と共に公開される更新プログラムは、実際には更新のロールアップであることがよくあります。たとえば、インターネット インフォメーション サービス (IIS) のすべてのセキュリティ更新プログラムは、現在、以前のすべての問題の更新プログラムも含む更新のロールアップです。

3 番目は、"サービス パック" でセキュリティ更新プログラムを入手する方法です。サービス パックは、すべての更新プログラム、セキュリティ更新プログラム、重要な更新プログラム、およびその他の更新プログラムの累積的なテスト済みのセットです。サービス パックには、その作成中に マイクロソフト内部で発見された問題に対するセキュリティ更新プログラムが含まれる場合もあります。サービス パックが公開されると、マイクロソフト内部で発見されたものを含め、すべての更新プログラムの内容がマイクロソフト サポート技術情報の文書に掲載されます。

これらの方法で公開される内容は同等であり、十分にテストされ、広範囲のベータ プログラムを経ていることから、セキュリティ更新プログラムの導入にはサービス パックが推奨されます。ただし、セキュリティ更新プログラムも、厳しいテストを受けています。

ページのトップへ

セキュリティ更新プログラムのテスト

セキュリティ更新プログラムをインストールするよう推奨される場合は、いつも "本稼働環境にロールアウトする前に必ずご利用の環境で更新プログラムをテストしてください" という言葉で締めくくられます。セキュリティ更新プログラムには、よくテストされていないため障害の原因になるという良くないうわさがあります。実際のところ、セキュリティ更新プログラムに関連してインストール後に安定性の問題が発生することは、ほとんどありません。ただし、少数ですが発生することもあり、深刻な影響を受けることもあります。例を挙げて計算してみましょう。2,000 万台のコンピュータ (Windows のように広く普及しているプラットフォームではそれほど大きな数ではありません) に更新プログラムがインストールされ、そのうち 0.01% に更新上の問題があるとすると、問題の発生するコンピュータは 2,000 台になります。この数が、セキュリティ更新プログラムに関する問題をよく耳にする根拠となっています。システムのごくわずかな部分で問題が発生するだけでも、メディアの関心を刺激するには十分です。

セキュリティ更新プログラムに固有の問題が存在することもありますが、比較的まれなケースです。セキュリティ更新プログラムに関連して発生する問題の大部分は、サード パーティ製アプリケーションか、既定の構成設定の変更に起因します。これが、"ご利用の環境でテストしてください" という文言の背景です。極端な異種環境向けコンピュータ ソフトウェアを導入する場合は、テスト パスにすべての導入パターンを含めることは不可能です。たとえば、セキュリティ更新プログラムがテストで問題を起こさなかったからといって、Windows NT 4.0 Workstation の稼働するガソリン ポンプに更新プログラムを適用したときに問題は起こらないでしょうか。Windows XP Professional が稼働するレジの場合はどうでしょう。これらを知ることは不可能です。しかし、テスト パスを減らすための経験則はいくつか存在します。

すべてのセキュリティ更新プログラムを一般的な構成セットでテストするのは、適切な方法です。たとえば、Windows オペレーティング システム (OS) のセキュリティ更新プログラム (特にサービス パック) は、Microsoft Office のサポートされるバージョンと組み合わせてテストされている場合、通常は安全です。また、セキュリティ更新プログラムが安全であれば、これらの構成に適用できます。アプリケーションのセキュリティ更新プログラムは、そのアプリケーションの稼働するすぺてのプラットフォームでテストされている場合は安全です。また、更新プログラムがテストされており、Windows ハードウェア互換性リストに登録されているハードウェア (更新プログラムを適用する OS の Windows ロゴが表示されているハードウェア) で正常に動作する場合も安全です。

では、それほど普及していないサード パーティ製の他のソフトウェアの場合はどうでしょうか。SQL Server のセキュリティ更新プログラムは、SAP、PeopleSoft、または Siebel が実行されるシステムでテストされるでしょうか。IIS のセキュリティ更新プログラムは、サーバーが再起動したときに PC スピーカーからヤンキー ドゥードゥル ダンディの曲を流す例の素敵なシェアウェアと組み合わせてテストされるでしょうか。一般的に言えば、セキュリティ更新プログラムがこれらの製品と組み合わせてテストされるかどうかは、その製品を作成するサード パーティ ベンダ (ISV) しだいです。また、ベンダ側に、サービス パック レベルを含む特定の設定で構成されたプラットフォーム上で実行される場合に限り自社製品をサポートするという固有の更新プログラム ポリシーが存在する場合もあります。その場合、更新プログラムをインストールすることで、製品サポートを受けられなくなるリスクが生じます。どうすればよいでしょうか。

行動方針は、対象となるセキュリティ更新プログラムによって異なります。緊急のセキュリティ更新プログラムの場合は、以下の 4 つの選択肢があります。

解答は、見かけほど明快ではありません。選択肢 1 に従うと、ハッキングを受ける可能性が高くなります。選択肢 2 は、すべてを失うことがあるため、ややリスクがあります。ただし、特に選択肢 4 と組み合わせるのであれば、最善の選択肢です。セキュリティ更新プログラムへの対応が相当に遅れる ISV は、多く存在します。正直なところ、認定されたプラットフォームで一部の製品のみを実行したならば、ハッカーによってあっという間に操作を止められるのは間違いありません。

本稼働システムとほぼ同じテスト用の複製システムを手に入れる新しい方法があります。Microsoft Virtual PC 2004 を使用すると、既存のハード ディスクを基盤として新しい仮想ディスクを作成できます。この機能を使用して、本稼働システム (通常、クライアントに現在サービスを提供しているシステムとは別のシステム) に Virtual PC をインストールし、そのディスクの複製を作成します。次に、そのディスク イメージを別のコンピュータにコピーします。その別のコンピュータに Virtual PC をインストールし、作成したディスク イメージに基づく新しい仮想コンピュータを作成します。最初の起動時に、仮想コンピュータから Virtual PC を削除します。状況によっていくつかのドライバをインストールする必要があります。ただし、これによりディスクをやり直し可能モードでセットアップし、新しいセキュリティ更新プログラムをテストするための本稼働システムのコピーを用意できます。Virtual PC でエミュレートされない特定のハードウェアでのテストなど、利用できない種類のテストがあることも事実ですが、ソフトウェアの相互運用性をテストするにはまったく問題ありません。Virtual PC は 15,000 円程度で入手できるため、コストの点からも追加のハードウェアを購入して管理するよりはるかに有益です。

ページのトップへ

セキュリティ更新プログラムの管理ツール

更新プログラムの管理に関するコラムなので、更新プログラムを管理するための有益なツールについて触れないわけにはいきません。一般的に、マイクロソフトでは、パッチ管理ツールに料金を課していません。ここで紹介するツールも、特に言及してある場合を除きすべて無料です。

MBSA

Microsoft Baseline Security Analyzer (MBSA) は、セキュリティ更新プログラムの適用漏れやその他の潜在的な脆弱性をシステムで検出するための無償のツールです。このツールは、http://www.microsoft.com/japan/technet/security/tools/mbsahome.mspx から入手できます。

MBSA は、更新プログラム スキャナであり、言葉の真の意味での脆弱性スキャナではありません。この 2 つを区別する理由は、更新プログラム スキャナは、セキュリティ更新プログラムがインストールされているかどうかを対象として機能するものであり、セキュリティ更新プログラムの未適用が必ずしも実際のセキュリティ問題につながるとは限らないためです。たとえば、Windows Server 2003 の稼働する Web サーバーを使用している場合は、情報の漏洩につながる可能性のある NetBIOS のセキュリティ問題を解消するセキュリティ更新プログラムがインストールされていないと通知されることがあります。しかし、指摘を受けた Web サーバーが、ファイアウォールの背後にあり、NetBIOS を使用していない場合、セキュリティ更新プログラムが存在しないというこの通知は、それほど問題になりません。この区別とは別に、更新プログラム スキャナでは、管理者権限に加え、スキャンするターゲット上で稼働する特定のサービスが必要です。たとえば、MBSA では、スキャンするターゲット上で Server サービスが稼働している必要があります。

真の意味での脆弱性スキャナ (ISS Internet Scanner など) は、攻撃者がシステムに侵入する際に悪用する可能性のある実際のセキュリティ問題を検出します。そのため、脆弱性スキャナでは、ターゲット システムの権限を必要としないのが一般的です。代わりに、攻撃者の視点から見たシステムの状態を評価します。

2004 年 1 月 15 日に MBSA Version 1.2 がリリースされました。このバージョンでは、前のバージョンに以下の新機能が追加されています。

エンドユーザー向けソリューション : 自動更新

エンド ユーザーにとって、セキュリティ更新プログラムについて気にする必要のない状態が、最善であるといえます。Windows Update (WU) の自動更新 (AU) サービスは、そのような環境のために設計されました。AU を使用すると、新しい Windows セキュリティ更新プログラムが公開されると通知され、その更新を自動的にダウンロードしてインストールするようにシステムを構成することもできます。自動的にダウンロードするモードは、管理者のログオンなしでも機能するため、ソリューションとして優れています。ただし、セキュリティ更新プログラムが再起動を必要とする場合、自動的にシステムが再起動されることに注意してください。この機能があるので、AU は特にサーバーには不向きです。

小規模および中規模ネットワーク向けソリューション : Software Update Service と AU

小規模ネットワークの場合、すべてのクライアントで AU を使用可能にし、サーバーを手動で更新するのが最善であると考えられます。しかし、ネットワーク全体にロールアウトする前に更新の影響をテストする必要のあるカスタム アプリケーションやあまり普及していないアプリケーションがある場合はどうすればよいでしょうか。この場合、Software Update Service (SUS) を利用します。SUS は、マイクロソフトから無料でダウンロードできるツールで、基本機能として独自の WU サーバーを構築できます。WU がユーザーに利用可能なすべてのセキュリティ更新プログラムを提示するのに対し、SUS は管理者が推奨する更新プログラムのみを提示するという違いがあります。AU は、一般に、WU で公開されたセキュリティ更新プログラムを基準にシステムをスキャンします。しかし、SUS サーバーを設置すると、WU の代わりに SUS サーバーを基準にスキャンするように AU を構成できるので、すべてのクライアントは管理者の推奨する OS の更新のみを導入し、その他の更新を無視することができます。

エンタープライズ向けソリューション : Systems Management Server

既に Microsoft Systems Management Server (SMS)、Tivoli、CA Unicenter などのエンタープライズ管理システム (EMS) を導入している場合、それらのシステムを使用して、セキュリティ更新プログラムを配布します。SUS と同じ柔軟性を SMS で実現する無料の SMS Software Update Services Feature Pack も用意されており、高性能な EMS の能力がさらに充実します。SMS にコストがかかるのは事実ですが、そのインフラストラクチャを導入すると、Feature Pack によって SMS を介してずっと簡単にセキュリティ更新プログラムを配布できます。

最適な選択

更新対象のクライアントが 500 以下で管理ソリューションが特に存在しない場合は、一般に、SUS と自動更新を採択するのが最適なソリューションであると考えられます。クライアントが 500 を超える場合は、更新以外の機能も考慮して、SMS などのエンタープライズ管理ソリューションの導入を検討する必要があります。EMS が既にある場合は、更新にそのシステムを使用できないかどうかを調査します。中央管理システムを必要としない非常に小さなネットワークの場合は、既定で Windows Update を問い合わせるように構成した自動更新サービスの使用を検討します。詳細については、マイクロソフト Web サイトの「セキュリティ アップデート マネジメント ソリューションの選択」を参照してください。詳細な技術ガイダンスについては、パッチ管理するための Microsoft ソリューションに関するドキュメント (英語) を参照してください。

アプリケーションの更新

SUS、AU、WU の各機能では、現在、オペレーティング システムのセキュリティ更新プログラムを配布しています。では、アプリケーションの更新はどうすればよいでしょうか。マイクロソフトでは、更新配布ソリューションの統合を目指して努力していますが、現在の段階では、アプリケーションの更新を個別に配布しています。配布場所のいくつかは、以下のとおりです。

ページのトップへ

高度なヒントとテクニック

それでは、サーバーについてはどうでしょうか。前に挙げたすべてのソリューションは、基本的にはクライアント向けです。サーバーを更新するには、どうすればよいでしょうか。まずは、更新プログラムを見つけることから始めます。すべての マイクロソフト セキュリティ更新プログラムは、TechNet Web サイトにあります。次に、それらの更新プログラムを適用する必要があります。これにはいくつかのテクニックがあります。これから紹介するのは、高度なテクニックであることに注意してください。これらの方法は、テクニック、対象のアプリケーション、および更新プログラムに関して慎重に調査し、実践を積んだ熟練者が利用することをお勧めします。これらのテクニックは、エンド ユーザー向けではありません。

マイクロソフトは、より適切な更新プログラム インストーラを作成するために努力を続けています。(マイクロソフトにとって) 新しいテクニックの 1 つに、実行中のコードをメモリ内で更新するホット パッチがあります。ホット パッチは、サービスやアプリケーションがシャットダウンされた後に、ディスク上の実際の実行プログラムを置換しません。置換は、通常、次回の再起動時に行われます。ただし、このテクニックでは、更新プログラムをインストールするユーザーが "Debug Programs" 特権を保持している必要があります。たとえば、Administrators からこの特権が削除されている場合、少なくとも更新プログラムをインストールするアカウントにその特権を与え直す必要があります。残念ながら、ホット パッチにはコストがかかります。ホット パッチは、スリップ ストリームを使用してインストール ポイントに統合できません。

新しいインストーラに組み込まれているもう 1 つのテクニックは、ウォーム パッチです。この場合、更新プログラム インストーラは、更新対象となるファイルを使用している (複数の) アプリケーションを、更新ファイルのインストール前にシャットダウンしようとします。これは重要な処理です。一般にシステムでは、更新プログラムの適用後、使用中だったファイルを更新するため再起動が必要になります。更新プログラムの適用前にサービスをシャットダウンすることで、更新プログラムのインストール後にシステムを再起動する必要がなくなります。これは、システム全体を再起動するよりも明らかに速い方法です。ただし、ウォーム パッチとホット パッチは、すべてのセキュリティ更新プログラムで使用できるわけではなく、一部のセキュリティ更新プログラムでは機能しません。しかし、状況によっては手動で同じ効果を再現できます。

慎重な調査による再起動の最少化

ウォーム パッチの効果を手動で再現する方法の 1 つとして、セキュリティ更新プログラムを慎重に調べた後に、更新対象ファイルを使用しているアイテムをオフにする方法があります。たとえば、大規模なサーバー ファームに IIS のセキュリティ更新プログラムを適用するとします。最初に、更新プログラム自体を解凍し、更新プログラムに含まれるファイル一覧を取得します。これには、更新プログラムを /x スイッチ付きで実行するか、WinZip などのツールを使用します。これで、更新に使用するファイルを含むディレクトリを得ることができます。更新プログラムの種類によっては、update.exe、update.inf、および更新プログラムのルート ディレクトリに存在する残りのファイルの大部分を無視できます。これらのファイルは、更新プログラム インストーラの一部であり、実際にはインストールされません。次に、更新対象ファイルを開いているアプリケーションを特定します。まずは、ファイル一覧を作成することから始めます。System Internals の優れた製品である Process Explorer (http://www.systeminternals.com) をダウンロードします。Process Explorer は、Windows のタスク マネージャに似ていますが、強力な機能があります。Process Explorer は、実行中のプログラムを表示するだけではありません。そのプログラムが開いているハンドルも表示します。ここでの "ハンドル" は、プログラムが何らかのオブジェクトを開いていることを意味します。たとえば、IIS のセキュリティ更新プログラムに、w3svc.dll が含まれているとします。[Find] メニューの [Find DLL] をクリックし、「w3svc.dll」と入力して Enter キーを押します。inetinfo.exe が一覧に表示されます。結果ウィンドウの inetinfo.exe をダブルクリックします。これにより、メイン ウィンドウが DLL ビューに切り替わり (Ctrl キーを押しながら D キーを押して、手動で DLL ビューに変更することもできます)、w3svc.dll だけでなく、inetinfo.exe プロセスで読み込まれているすべての DLL が表示されます。任意の DLL をダブルクリックすると、ファイルのさまざまな情報を確認できる詳細なプロパティ ダイアログが表示されます。Process Explorer での作業を終える前に、更新対象のバイナリ ファイルを開いているすべてのプロセスを記録しておきます。

ここで、再起動を避けることが可能であるかどうかを判断する必要があります。実際、この段階で判断するのは簡単ではありませんが、更新プログラムを適用するサーバーが多い場合は、テストを実施する価値があります。一般に、更新されるファイルを使用しているプロセスをシャットダウンできれば、再起動を避けることができます。ただし、Windows Management Instrumentation (WMI) などの一部のサービスは、単純に終了しようとすると自動的に再起動されることに注意してください。したがって、更新プログラムのインストールに使用するカスタム スクリプトでは、(サービス側が回避する可能性のある) 正常なシャットダウンを実行するか、最初にサービスを無効にしてからサービスを終了します。スクリプトでサービスを管理するには、sc.exe コマンド ライン ツールを使用できます。停止する必要のあるサービスを判断したら、最後に以下の操作の一部または全部を実行するスクリプトを記述します。

この作業でも若干のダウンタイムが発生しますが、完全な再起動よりはずっと優れています。

負荷分散環境では、通常、ピーク時以外の時間帯にコンピュータを 1 つずつオフラインにし、更新プログラムを適用してから再びオンラインに戻します。クラスタ環境では、一時的にクラスタ内の別のシステムにサービスをフェールオーバーすることで、この作業を実行します。何らかの理由でこの作業を実行できない場合でも、前に挙げたような類似テクニックを使用することで、システム構成要素すべてを使用できない時間を最小限に抑えることができます。クラスタや負荷分散を使用してダウンタイムを最小化することは、比較的複雑な作業であり、実行前に慎重に計画を立てる必要があります。

更新プログラムのインストールをバッチ処理することで、複数の更新プログラムを一度にインストールできます。この場合、複数回の再起動もなくなるため、ダウンタイムを最小化できます。ほとんどの Windows セキュリティ更新プログラム (および他の一部の更新プログラム) には、バッチ ファイルで使用できるさまざまなコマンド ライン スイッチがあります。たとえば、標準の Windows セキュリティ更新プログラムの /z スイッチは、更新プログラムの適用後にシステムを再起動しないことを意味します。したがって、/z スイッチ付きで複数のセキュリティ更新プログラムをインストールするバッチ ファイルを作成し、後から再起動することができます。Windows セキュリティ更新プログラムで使用する update.exe ツールに設定可能なスイッチは、以下のとおりです。

スイッチ説明 
------ -----------  
/f     シャットダウン時に他のプログラムを終了します。
/n     更新プログラムの削除に使用するバックアップ ファイルを作成しません。 
/z     インストールの完了後にコンピュータを再起動しません。 
/q     Quiet モードを使用します (ユーザー入力を必要としません)。  
/m     無人セットアップ モードを使用します (Windows 2000 の場合)。   
/u     無人セットアップ モードを使用します (Windows XP の場合)。  
/l     インストールされている更新プログラムの一覧を表示します。 

すべての更新プログラムでこのインストーラが使用されるわけではないことに注意してください。たとえば、Windows Media と一部の Internet Explorer のセキュリティ更新プログラムでは異なる構文が使用され、/z スイッチと同等のスイッチは実装していません。不明な場合は、/? スイッチ付きで更新プログラムを実行することで、構文をチェックできます。

複数のセキュリティ更新プログラムにより、同じファイルが更新される場合もあります。この場合、インストール順序が正しいかどうかを確認することが重要です。これには、qchain ツールを使用します。このツールの説明は、マイクロソフト サポート技術情報の文書 296861 にあります。ただし、一般に、2002 年 12 月より後にリリースされた更新プログラムや修正プログラムには qchain 機能が組み込まれているため、qchain ツールは必要ありません。詳細については、マイクロソフト サポート技術情報の文書を参照してください。

セキュリティ更新プログラムとサービス パックがあらかじめ組み込まれたカスタム インストール ソースを作成することもできます。"スリップ ストリーム" として知られるこのプロセスは、あまり経験を積んでいないユーザーには不向きであり、この長いコラムでは取り上げませんが、マイクロソフト サポート技術情報の文書とリソース キットで詳細を確認できます。

ページのトップへ

まとめ

更新プログラムは、システム管理者にとっての必要悪です。すべてのシステムには、セキュリティ更新プログラムがある程度必要であり、セキュリティ更新プログラムの管理は必須業務です。ただし、更新プログラムの管理は、単純で楽な作業ではありません。このコラムでは、パッチ管理に関する基本事項に加え、データセンター環境のダウンタイムを最小化するための高度なテクニックをいくつか紹介しました。セキュリティ更新プログラムの管理に使用するテクニックは環境によって変化しますが、その管理方法を検討する必要があるという事実は変わりません。

最後に、読者に話しておきたい 2 つのことがあります。1 つは、このコラムのすべての内容は、読者の属する組織の情報セキュリティ ポリシーの制約を受けるということです。情報セキュリティ ポリシーによる裏付けなしでパッチ管理戦略を構築することはできません。このことは、更新プログラム適用のため、あるいは問題が発生したためにサーバーを停止しなければならなかった場合の、自分自身の防護という観点できわめて重要です。問題が発生した場合に、提示可能な CEO の署名付き情報セキュリティ ポリシーを保持しているかどうかで、単に余分な仕事が増えるだけとなるか、履歴書を作成する事態に陥るかの違いが生じる可能性があります。

もう 1 つは、セキュリティにおけるパッチ管理の影響を考慮することです。すべてのセキュリティ更新プログラムを適用していれば、常に安全でしょうか。そうではありません。セキュリティ管理は、現在も進行中のプロセスです。セキュリティ更新プログラムをインストールしないと、ハッキングを受ける危険性が大幅に高まります。一方で、常に最新のセキュリティ更新プログラムを適用しておくことで、使用する製品の脆弱性とは関係のないセキュリティ問題により関心を持つことができます。セキュリティ更新プログラムをインストールしておけば、ネットワーク運用上のセキュリティ管理に関する複雑で興味深い問題に重点を置き、複雑なセキュリティ管理を高いレベルで検討できるようになります。今後の一連のコラムでは、このプロセスのさまざまな側面について説明する予定です。

ページのトップへ