第4回 パッチ検証の必要性を考える：特集：効率的なパッチ適用、管理の実現に向けて（2/2 ページ）

[磯 貴浩（ラック），ITmedia]

　今回の記事ではWindows環境を前提に話を進めているが、こうした不具合は、LinuxやSolarisといった他のOSや、OS以外の商用アプリケーションなどのセキュリティパッチでも起こりうる問題である。したがってWindows以外の環境でも、テスト環境の用意とパッチの検証といった手順を踏むのが望ましい。

セキュリティパッチ検証の方法

　さて、こういった不具合の可能性を踏まえると、パッチが公開されたからといって、社内で使用されているPCに直接、いきなりセキュリティパッチを適用するべきではない。

　まず、社内で使用されているPCと同様の環境を備えたテスト用PCを用意しておき、そのPCにセキュリティパッチを適用する。社内に複数のOSやバージョンが混在している場合、すべての環境を用意して検証を行う必要がある（図2）。また、クライアント／サーバ型の業務アプリケーションを使用している場合は、サーバとクライアント両方の環境を用意し、どちらにおいてもその業務アプリケーションが正常に動作するか検証することも必要である。

図2●社内に複数のOSやバージョン、アプリケーションが混在している場合は、それらすべてのパターンについて検証環境を用意しておくことが望ましい

　ちなみに、検証が必要な環境の分だけPCがそろえられない場合は、VirtualPCやVMWareなど、1台のPC上で複数の仮想マシンを稼動させることができるソフトウェアを使用するのも一つの手だ。物理的なPCは1台でも、各仮想マシン上に社内の環境を作成することで、効率的に検証できる。

　Windows UpdateやWindowsの自動更新機能を使用せずに複数のセキュリティパッチを適用する際は、適用する順番についても考慮する必要がある。適用する順番を間違えた場合、セキュリティホール対策前の古いファイルが残ってしまう場合があるし、システムファイルの依存関係によってはシステムが動作しなくなる可能性もあるからだ。

　適用後は、システムや業務で使用しているアプリケーションに問題が発生せず、通常運用が可能であることを確認する。また、セキュリティパッチ適用によって障害が発生した場合のことも考慮し、適用前の状態に復旧できる方法も検証する必要がある。

　この際、事前に検証項目を洗い出しておき、洗い出した項目に沿って検証を行うと効率的だ。検証項目としては、業務に関連するOSやアプリケーションの機能すべてを洗い出し、動作を検証するのがベストだが、時間的にそうもいかない場合もあるだろう。だが最低でも、OSの起動／終了はもちろん、業務で使用しているアプリケーションならば業務に関連する重要な機能について確認しておく必要がある。

　こうして検証の結果特に問題がなければ、第2回や第3回で紹介した方法に沿って、全社的に通知、配布する手順を準備する。

　ただし、セキュリティパッチがリリースされてからセキュリティホールを突くコードやウイルスが発生するまでの期間は、徐々に短くなってきている。このような状況を考慮すると、検証は正確に、しかも迅速に行わなければならない。

パッチの重要度を見極める

　しかし、ベンダーからリリースされるセキュリティパッチすべてを検証することは、大変手間のかかる作業である。検証に時間をかけ過ぎて、その間ずっとセキュリティホールが放置されたままになっていたり、逆に、検証を行うことなく直接パッチ適用を行っている管理者も多いのではないだろうか。

　このような場合にはまず、いくつかの要素を考慮して、セキュリティパッチを適用するか、それともしないかの意思決定を下すことが有効だ。それには、セキュリティパッチの検証や適用に要する作業工数、セキュリティパッチの対象環境と、社内のPC資産の情報、パッチを適用しないことによりセキュリティホールが放置されることによって生じるリスクといった事柄がからんでくる。

　また、マイクロソフトが公開するセキュリティパッチの場合、同社が示す「最大深刻度」（表3）を参考にし、それを元に社内のPCに適用する／しないの判断を下す、といったセキュリティポリシーを策定してもよい。例えば、「緊急／重要のステータスのセキュリティパッチならば最優先で検証を行い、しかる後に適用する。それ以外のステータスのセキュリティパッチは、以後リリースされるサービスパックの適用で対応する」といった運用も可能だ。脆弱性情報提供サービスの中には、こうした深刻度を加えたうえで、情報を配信してくれるものもある。

表3■マイクロソフトのセキュリティパッチの深刻度の基準

深刻度 判断基準 緊急 このセキュリティホールが悪用された場合、ワームがユーザーの操作なしで蔓延する可能性がある 重要 このセキュリティホールが悪用された場合、ユーザーのデータの機密性、完全性または可用性が侵害される可能性がある。または、処理中のリソースの完全性または可用性が侵害される可能性がある 警告 このセキュリティホールは既定の構成、監査または悪用が困難であることなどの要素により、悪用される可能性は大幅に緩和される 注意 このセキュリティホールの悪用は非常に困難である。または影響はわずかである

アプリケーションに不具合が発生したら？

　もしパッチ適用が原因となって、システムや業務で使用しているアプリケーションに支障をきたす恐れがある場合は、セキュリティパッチ適用を見合わせ、アプリケーションのベンダーと不具合の対策を協議する必要がある。

　その間の対策として、セキュリティホールの内容によっては、パッチが影響を及ぼす特定のポートをファイアウォールなどでふさぐ、パケットフィルタリングを行うといった手立てを取ることによって、外部からの攻撃を回避できる場合もある。また、業務上必要がなければ、セキュリティホールが存在するサービスを停止するなどの対策を取ることでも、パッチを無理に適用せずともセキュリティホールに対応できる。こういった「代替策」「回避策」は、パッチのリリースとともにベンダーから情報が公開されることも多いので、同時にチェックしておくべきだろう。