HotFix Briefings特別編 HotFix管理の勘所―― 効率的なHotFix管理を実施するための知識とテクニック ―― 第2回 修正プログラムに関する情報収集のポイント1.TechNetセキュリティ情報の活用法デジタルアドバンテージ2003/11/12 |
|
|
前回「第1回 日常的情報収集のススメ」では、日ごろからセキュリティ・ホールなどに関する情報を収集することの重要性と、その情報入手先について解説した。今回は、修正プログラムがリリースされた後の情報収集について解説していく。
修正プログラム提供開始後の情報収集はTechNetセキュリティ情報から
マイクロソフトは、新しいセキュリティ施策として、セキュリティ関連の修正プログラムを毎月第2水曜日(米国では第2回火曜日)の毎月1回にまとめてリリースすることに決めた。マイクロソフトの説明によれば、これによりWindowsネットワーク管理者は、計画的に修正プログラムの適用が行えるようになる、としている。しかし、緊急性の高い修正プログラムは、例外的に第2水曜日以外の日にリリースする可能性もあるともしている。また、修正プログラム提供後に、何らかの不具合が見つかり、修正プログラムが再リリースされることも少なくない。例えば、10月16日にリリースされた「TechNetセキュリティ:MS03-042/043/045」は、修正プログラムのインストーラに不具合があったため、10月30日に再リリースされている。こうしたこともあるので、普段からの情報収集はやはり怠れない。
さて、マイクロソフトから修正プログラムがリリースされたら、まずその修正プログラムに関する情報を集めて評価を行う。修正プログラムの深刻度や、対象となるOS/アプリケーション、修正プログラムを適用する以外のセキュリティ・ホールの回避策などを、主にマイクロソフトのTechNetセキュリティ情報から入手する。
■深刻度は自分で判断する
TechNetセキュリティ情報には、「最大深刻度」としてセキュリティ・ホールの危険度が「緊急」「重要」「警告」「注意」の4段階で示されている。各深刻度の意味合いは下表のとおりである。
深刻度 | 意味 |
緊急 | インターネット・ワームがユーザーの操作なしで蔓延する可能性のあるセキュリティ・ホール |
重要 | ユーザーのデータの機密性、完全性または可用性が侵害される可能性のあるセキュリティ・ホール |
警告 | 既定の構成や脆弱性の悪用が困難であることなどにより、危険性が大幅に緩和されるセキュリティ・ホール |
注意 | 悪用が非常に困難で影響がわずかなセキュリティ・ホール |
ただし、コンピュータの利用環境やそのほかのセキュリティ対策の状況によって、この深刻度は変わってくる。例えば、インターネットに直接接続されているようなサーバでは、深刻度が「重要」とされているセキュリティ・ホールであっても危険度は高い。逆に、「緊急」とされているものでも、インターネットから完全に隔離されている環境で利用されているコンピュータであれば、危険度はそれほど高くないだろう。従ってマイクロソフトから提供されるこの深刻度の情報は、あくまでも目安として用い、最終的な自システムへの影響については、利用環境などから自分で判断することが重要だ。この判断の材料として、TechNetセキュリティ情報の「技術的な説明」や「よく寄せられる質問」が参考になる。
ただし、なるべく最悪な状態を想定して、安全方向に振って対策を考えるべきだ。つまり、「警告」「注意」とされているセキュリティ・ホールに対しても、修正プログラムの適用はもちろんのこと、ファイアウォールを厳しく設定したり、不要なサービスを止めたりするなどの対策をとるように心がけたい。
■対象となるOSに要注意
TechNetセキュリティ情報では、セキュリティ・ホールが存在し、修正プログラムの適用対象となるOSやアプリケーションが「影響を受けるソフトウェア」として示されている。しかし、本来はセキュリティ・ホールが存在するにもかかわらず、マイクロソフトのライフサイクル・ガイドラインに従ってサポートが終了してしまっている製品もある。
例えば、Windows NT Service Pack 6a(SP6a)やWindows 2000 Service Pack 2(SP2)より前のService Packを適用したOSは、ライフサイクル・ガイドラインによってサポート対象外となっている。つまり、対象外の古いバージョンでは、たとえセキュリティ・ホールが存在したとしても、修正プログラムは提供されない。従って、例えばWindows 2000 SP1などのように、セキュリティ・ホールがあると思われるのに、修正プログラムが提供されないような場合は、まずはService Packを適用してサポート対象の状態にするか、回避策によってセキュリティ・ホールの影響を受けないようにしなければならない。
特に注意が必要なのは、Internet Explorer(IE)のセキュリティ・ホールである。IEとOSのバージョンの組み合わせによって、修正プログラムが提供されない場合があるからだ。
■関連する修正プログラムを調査する
セキュリティ・ホールが完全に解消できなかったり、修正プログラムに不具合があったりして、同じファイルを置き換える修正プログラムが再リリースされることがある。こうした修正プログラムの場合、TechNetセキュリティ情報の「修正プログラムに含まれる過去の修正」の欄にTechNetセキュリティ番号が記載される。このような修正プログラムの場合、過去のTechNetセキュリティ情報も読み、それが新たなセキュリティ・ホールに対する再リリースなのか、不具合の修正によるものなのかを調べたい。「TechNetセキュリティ情報:MS03-039(RPCSS サービスのバッファ オーバーランによりコードが実行される)」のRPC DCOMのように、同じモジュールでセキュリティ・ホール(MS03-026など)が何度も見つかり、修正プログラムがリリースされているような場合は、修正プログラムの適用とともに、別の対策を講じた方がより安全だからだ。また、不具合が修正された場合は、同様の修正プログラムでも同じような不具合が現れる可能性があるので、その点に注意して検証を行った方がよい。
そのほか、修正プログラムの中には、適用後に別の修正プログラムを適用するのが望ましいものがある。例えば、「TechNetセキュリティ情報:MS03-040(Internet Explorer用の累積的な修正プログラム)」では、適用によりHTMLヘルプ機能が動作しないように設定される。このHTMLヘルプ機能を利用するには、更新されたHTMLヘルプコントロールを追加インストールする必要がある。このようなタイプの修正プログラムはそれほど多くないが、TechNetセキュリティ情報をよく読み、目的の修正プログラムと同時に検証作業を行う必要がある。
上記のように、別の修正プログラムと関連のある修正プログラムの場合、適用順序が問題になる場合もある。適用順序を守らないと、一方の修正プログラムに含まれる更新ファイルが上書きされて無効になってしまうことがあるからだ。これもTechNetセキュリティ情報をよく読み、順序よく適用しよう。通常はリリースされた順に適用すればよい場合がほとんどだが、再リリースされた修正プログラムについては逆順になることもあるので注意が必要である。
■深刻度と回避策の有無で適用時期を検討する
セキュリティ・ホールの対象となるソフトウェアを利用していた場合、修正プログラムの適用が必要になる。だが、ここでWindowsネットワーク管理者は、重要な判断を迫られることになる。
特に「緊急」とされる修正プログラムは、すぐにでも適用すべきだが、適用することによって不具合が発生することもある。そこで、自社の環境に合わせたテスト用PCで、修正プログラムの適用を試してみることが重要だ(これについては、回をあらためて詳細を解説する)。さらに、すでに修正プログラムを適用した人が不具合に遭遇していないかどうかを、前回紹介したセキュリティ関連のメーリング・リストや掲示板などで調べたい。もし、不具合の報告があれば、その内容によっては修正プログラムの適用を延期(ないしは中止)した方がよいかもしれない。
ただ多くの不具合情報は、修正プログラムがリリースされてから、数日から1週間程度後になることが多い。そのため、修正プログラムの適用テストと並行し、これらの情報収集に当たるとよい。大量のクライアントに対して、本格的な適用を行うのは、できれば1週間程度待ちたいところだ。しかしその間、システムの脆弱性は放置され、危険性が高い状態に置かれることになる。すでに「ゼロデイ・アタック」がいつ現実化してもおかしくない状態にある。修正プログラムの適用を延期する場合には、それ以外の回避策を使って、できるだけ危険を回避するように配慮しなければならない。
ゼロデイ・アタック 修正プログラムの提供前に脆弱性に対して行われる攻撃のこと。 セキュリティ専門家などが脆弱性を発見した場合、その存在を公表する前にソフトウェア・メーカーと連絡を取り、修正プログラムの作成時間を確保するのが一般的だ。しかし、クラッカーなどが脆弱性を発見したり、セキュリティ専門家がメーカーに連絡する前に脆弱性を公表したりした場合、修正プログラムが用意される前に攻撃が行われる可能性がある。このようにユーザー側で防御の準備ができない状態で、脆弱性の発見からごく短時間で行われる攻撃を「ゼロデイ・アタック」と呼ぶ。 |
Windowsネットワーク管理者は、セキュリティ・ホールの危険性と修正プログラムを適用することによる不具合発生のリスクを秤にかけて、修正プログラムをいつ適用するのかを決断しなければならない。だが、TechNetセキュリティ情報に回避策が示されていたならば、回避策を実行することで、不具合の発生に関する情報収集のための時間稼ぎを行うのも1つの手だ。とはいえ、いつまでも時間稼ぎはできないので、適用テストと情報収集を行い、ある時点では決断が必要になる。
セキュリティ・ホールと不具合発生のリスクを秤にかけて適用の判断を行う
残念ながら、修正プログラムによる不具合発生のリスクをなくすことはできない。修正プログラムは、セキュリティ・ホールや不具合を修正するものだが、多様なアプリケーションや周辺機器と組み合わされて利用されるWindows環境では、100%確実ということはないからだ。例えばマイクロソフトの「TechNetセキュリティ情報:MS03-013(Windows カーネル メッセージ処理のバッファ オーバーランにより、権限が昇格する)」で提供された修正プログラムをWindows XP Service Pack 1(SP1)に適用すると、特定のウイルス対策ソフトウェアとの組み合わせにおいて、性能が著しく低下するという障害が発生した。こうした特定のアプリケーションとの組み合わせによって生じる問題は、マイクロソフトとしても検証しきれないため、ユーザーのもとで初めて障害が発生・露見することになる。
このような障害がある修正プログラムを事前に検証せずに、SUS(Software Update Services)やHotFix管理ソフトウェア、資産管理ソフトウェアなどを利用して、管理している大量のクライアントに適用してしまったら、修正プログラムをアンインストールするまで業務が止まってしまうことになる。修正プログラムをクライアントに自動的に配布するソフトウェアはいろいろとあるが、残念ながら自動的にアンインストールを行うような機能を持つものはない。つまり、アンインストールは手作業によって、各クライアント上で行わなければならないわけだ。修正プログラムによっては、オプションを設定することで、資産管理ソフトウェアなどでアンインストールが可能だが、アンインストールが失敗するとシステムが破壊される恐れもあるのでおすすめしない。ツールを使って100台のクライアントに修正プログラムを適用するのは数分だが、手作業で100台のクライアントからアンインストールするのは1台5分としても、8時間以上(500分)かかる。最悪の場合、数日というオーダーで業務が止まることも覚悟しなければならないわけだ。
こうした最悪の事態を未然に防ぐには、修正プログラムを調べ、自社のシステム(業務アプリケーションやウイルス対策ソフトウェアをインストールしたクライアント)で修正プログラムの適用テストを十分に行うことだ。だが、いろいろな形態で利用されるクライアントを常に網羅的にテストするのは非常に手間も時間もかかるため現実的ではない。そこで、修正プログラムの中身を調べ、テスト範囲を絞り込むことで省力化を行うようにしたい。
では、修正プログラムの何を調べればよいのだろうか。まず、修正プログラムがリリースされたら、修正プログラムをダウンロードし、修正プログラムのインストーラの種類、置き換わるファイルとそのバージョン、書き換わるレジストリ・キーの値など、修正プログラムの中身について解析を行うという手順になる。
修正プログラムのダウンロード先は、TechNetセキュリティ情報に記載されている。しかし、ここでも注意が必要だ。もし、修正プログラムの適用をWindows Updateの自動更新機能やSUSを利用して行うならば、TechNetセキュリティ情報に記載されているダウンロード・センターからではなく、Windows Updateカタログから必ず入手するようにしたい。これは、現在のところダウンロード・センターとWindows Updateカタログ(Windows Updateの自動更新機能やSUSのダウンロード先)は、別々に運営されており、ごくまれではあるが異なるバージョンの修正プログラムが登録されることがあるからだ。つまり、ダウンロード・センターの修正プログラムで試して問題がなくても、Windows Updateカタログの修正プログラムでは問題が発生するという可能性がある*1。これは、主にマイクロソフトの運用ミスであるが、こうした事実がある以上、リスクを軽減するために適用を行う先から必ず入手するようにしよう。
*1 この問題は、TechNetセキュリティ情報:MS03-013(Windowsカーネル メッセージ処理の脆弱性により攻撃者のコードが実行可能になる危険性)で発生している。SUS/自動更新/Windows Updateカタログから入手したMS03-013の修正プログラムをWindows 2000 SP2に適用すると、ブルースクリーン(Windowsカーネルの暴走)が発生する障害が起きた。一方、ダウンロード・センターから入手した修正プログラムにこの不具合は存在していない。 |
INDEX | ||
HotFix管理の勘所 | ||
第2回 修正プログラムに関する情報収集のポイント | ||
1.TechNetセキュリティ情報の活用法 | ||
2.修正プログラムの入手法 | ||
Windows HotFix Briefings |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|