トピックモジュールの内容このモジュールでは、パッチ管理の概要と、パッチ管理が企業システムに不可欠である理由について説明します。また、一般的な脆弱性や脅威の種類についての説明と共に、セキュリティの専門用語についても紹介します。またこのモジュールでは、ソフトウェアの更新プログラムを開発し、リリースするために Microsoft® 内で使用されているプロセスについても説明し、これらのプロセスが、プロアクティブな (予防的) セキュリティ パッチ管理のために実行する必要のある処理にどのように関連するかも示します。最後に、推奨する 4 段階アプローチのパッチ管理プロセスを紹介します。この詳細については、後続のモジュールで詳しく説明します。 このモジュールの目的は、Microsoft Windows® オペレーティング システムベースの環境でのパッチ管理の重要な問題を紹介し、このタスクをサポートするために推奨する主なツール、テクノロジ、およびプロセスについて説明することです。 目的このモジュールの目的 | • | 安全な IT 管理とセキュリティのコスト上の弱点についてレビューする。 | | • | "パッチ管理" という用語と主要なセキュリティの専門用語について理解する。 | | • | 主要な脆弱性、およびこれらの脆弱性が Microsoft 深刻度評価、脅威の分類、存在する脅威の媒介物の種類にどのように関連するかについて分析する。 | | • | リリース後に Microsoft がソフトウェアを修正する方法、およびソフトウェアの更新に関する Microsoft の用語について確認する。 | | • | プロアクティブな (予防的) セキュリティ パッチ管理の重要性についての例を参照する。 | | • | 環境に最適なパッチ管理ツールおよびテクノロジについて判断する。 | | • | パッチ管理の 4 段階アプローチの基本要素について説明する。 |
適用対象このモジュールは、すべての Microsoft 製品およびテクノロジに適用されます。 モジュールの使用方法このモジュールでは、セキュリティ パッチ管理 (主要な用語、概念、ツール、テクノロジ、および推奨する 4 段階のパッチ管理プロセスの概要) を紹介します。また、過去の攻撃の例を示し、プロアクティブな (予防的) セキュリティ パッチ管理が実行されていた場合の回避方法についても説明します。 このモジュールから最大限の成果を得るには、以下を参照してください。 パッチ管理の概要パッチ管理は、運用環境への暫定的なソフトウェア リリースの展開と保守の管理を提供するプロセスです。このプロセスは、運用効果と運用効率を維持し、セキュリティの脆弱性を解消し、運用環境の安定性の維持に役立ちます。 組織が、オペレーティング システムやアプリケーション ソフトウェアの既知の信頼レベルの判断や管理ができない場合は、多くのセキュリティの脆弱性を持つ可能性があり、これを悪用されると、収益や知的財産の損失につながる可能性があります。この脅威を最小限に抑えるには、システムを適切に構成し、最新のソフトウェアを使用し、推奨されるソフトウェアの更新をインストールする必要があります。 不完全なパッチ管理が原因で発生する可能性のある、財務に対する影響を特定する場合に考慮する項目は、次のとおりです。 | • | ダウンタイム:
使用している環境内でのコンピュータのダウンタイムのコストはどうなるでしょうか。基幹ビジネス システムが中断された場合はどうなるでしょうか。エンド ユーザーの生産性が損なわれた場合、基幹システムのトランザクションが失われた場合、ある事件によってビジネスの損失が発生した場合の機会コストを判断します。大部分の攻撃によってダウンタイムが生じます。攻撃そのものがダウンタイムの原因となる場合もあれば、復旧に必要な回復処理がダウンタイムの原因になることもあります。過去の攻撃では、数日間コンピュータがダウン状態のままになったこともありました。 | | • | 問題回復時間:
使用している環境で幅広い問題の解決を行なうためのコストはどの程度でしょうか。コンピュータを再インストールするためのコストはどの程度でしょうか。すべてのコンピュータを再インストールする必要がある場合はどうなりますか。多くのセキュリティ攻撃は、攻撃によるバック ドア (将来のセキュリティ突破口となる) が残っていないことを確実にするために完全な再インストールを必要とします。 | | • | 不確かなデータの完全性:
攻撃によってデータの完全性が損傷を受けた場合、最新のバックアップからデータを復旧するコスト、またはユーザーやパートナーと共にデータの正統性を確認するためのコストはどの程度になりますか。 | | • | 信頼の喪失:
ユーザーの信頼を失った場合のコストはどの程度でしょうか。複数のユーザーを失った場合のコストはどの程度でしょうか。 | | • | 否定的な評判:
否定的な評判による組織への影響はどの程度でしょうか。ビジネスを行なう上で信用できない企業と判断されてしまった場合、株価や企業価値はどの程度下落するでしょうか。クレジット カード番号など、顧客の個人情報が漏れてしまった場合の影響はどの程度でしょうか。 | | • | 法的防御:
攻撃を受けた後に他者から訴訟を起こされた際にかかるコストはどの程度になるでしょうか。他者に重要なサービスを提供している組織では、パッチ管理プロセス (またはその欠如) が訴訟の対象になります。 | | • | 知的財産の盗難:
組織の知的財産が盗難にあった、または破壊された場合のコストはどの程度になるでしょうか。 |
また、適切に定義されたパッチ管理プログラムを使用して、ネットワーク環境におけるソフトウェアの整合性を査定し、保守することも、コンピュータへの物理的なアクセスの制限の種類にかかわらず、情報セキュリティを成功させるための重要な第一歩と言えます。 セキュリティの専門用語ここでは、セキュリティ パッチ管理プロセスに関わるときに理解しておくべき専門用語を紹介します。表 1 に、これらのモジュールで使用される主要なセキュリティ用語を示します。 表 1: 重要なセキュリティ用語 脆弱性 | 攻撃中に弱点として悪用される可能性があるソフトウェア、ハードウェア、手続き上の弱点、機能、または構成。暴露 (Exposure) とも呼ばれます。 | 攻撃 | 脅威の媒介物が望ましくない目的に脆弱性を利用しようとすること。 | 対応策 | コンピュータ環境でリスクを軽減するためのソフトウェア構成、ハードウェア、または処理手順。防護措置または緩和措置とも呼ばれます。 | 脅威 | 危険の源。 | 脅威の媒介物 | ユーザーのセキュリティ ポリシーに違反する方法で、脆弱性を利用してシステムを攻撃する人またはプロセス。 |
脆弱性ソフトウェアが攻撃に対して脆弱になる可能性のあるさまざまな方法があります。表 2 に、いくつかの代表的なソフトウェアの脆弱性を示します。 表 2: ソフトウェアの脆弱性 バッファ オーバーラン | プログラム コードに新しいデータを上書きできる、プログラム内の確認されないバッファ。プログラム コードが新しい実行可能なコードで上書きされた場合、アタッカーの指示どおりにプログラムの動作を変更する効果があります。 | 特権の昇格 | 特定の状況で、ユーザーや攻撃者がより高い特権を得ることを許可します。 | 検証の欠陥 | 無効なデータで予期しない結果をもたらすことができます。 |
MSRC による脆弱性の深刻度評価Microsoft Security Response Center (MSRC) では、脆弱性や関連ソフトウェアの更新の緊急度を判断するのを支援するために、深刻度評価を使用します。表 3 に、脆弱性の深刻度を分類するために、MSRC によって使用される評価を示します。 表 3: 脆弱性の深刻度評価 緊急 (Critical) | この脆弱性が悪用された場合、インターネット ワームがユーザーの操作なしで蔓延する可能性があります。 | 重要 (Important) | この脆弱性が悪用された場合、ユーザー データの機密性、完全性または可用性が侵害される可能性があります。または、処理中のリソースの完全性または可用性が侵害される可能性があります。 | 警告 (Moderate) | この脆弱性が悪用された場合、既定の構成、監査または悪用が困難であることなどの要素により、悪用される可能性は大幅に緩和されます。 | 注意 (Low) | この脆弱性の悪用は非常に困難です。または影響はわずかです。 |
MSRC の脆弱性の深刻度評価の詳細については、Web サイト http://www.microsoft.com/japan/technet/security/bulletin/rating.mspx の 「Microsoft Security Response Center マイクロソフト セキュリティ情報の深刻度評価システム」を参照してください。 脅威の分類Microsoft は、ソフトウェアの脅威を分類するために、STRIDE モデルを開発しました。このモデルの概要を表 4 に示します。Microsoft セキュリティ情報では、セキュリティの脆弱性の性質を記述するために、これらの分類が頻繁に使用されています。 表 4: 脅威の分類の STRIDE モデル なりすまし (Spoofing identity) | 不正にアクセス権を取得して、別のユーザーの認証情報 (ユーザー名とパスワードなど) を使用すること。 | データの改ざん (Tampering with data) | データに悪意のある変更を行うこと。 | 否認 (Repudiation) | ユーザーがある操作を実行することを拒否されることで、そのことを他人に証明する手段がない状態のこと ("否認防止" は、否認の脅威に対抗するシステムの能力を指します。小包を受け取ったときに署名するようなことで、小包の受け取り手はこれを証拠として使用できます)。 | 情報漏洩 (Information disclosure) | 情報へのアクセス権を持たない個人に情報が公開されること。たとえば、適切な権利なしにファイルにアクセスすること。 | サービス拒否 (Denial of service) | 正当なユーザーがサービスやシステムを使用できないようにする、意図的な試み。 | 権限の不正取得 (Elevation of privilege) | 権限を持たないユーザーがアクセス権を獲得すること。権限の不正取得の一例には、権限のないユーザーを Administrators グループに追加する手段を考案することなどがあります。 |
注: STRIDE モデルの詳細や Microsoft がどのように開発者に安全なコードの書き方を教育しているかについては、Michael Howard と David LeBlanc の共著による『Writing Secure Code, Second Edition』 (Redmond, WA: Microsoft Press, 2002、英語) (http://www.microsoft.com/mspress/books/5957.aspx) を参照してください。 脅威の媒介物悪意のある脅威とは、組織に危害を加えたり、混乱を生じさせたりする意図を持つネットワーク内外からの攻撃のことです。悪意のない脅威とは、通常、セキュリティ脅威や脆弱性に気づいていない、教育されていない従業員が引き起こすものです。表 5 に、悪意のある脅威の媒介物をいくつか示します。 表 5: 脅威の媒介物 ウイルス | 自己複製するコードを挿入し、重要なファイルを削除することによって、システムに変更を加えたり、コンピュータ上のデータまたはコンピュータ自体に危害を加えたりする原因となる何らかの操作を実行する、コンピュータ ファイルに感染する攻撃プログラム。ウイルスは、自分自身をホスト プログラムに添付します。 | ワーム | 多くの場合、ウイルスのような悪意のある自己複製プログラムで、最初にファイルに感染しなくても、コンピュータからコンピュータへと増殖できます。 | トロイの木馬 | 役に立ち、悪意の無いことを装うが、実際には破壊的な目的を実行するか、攻撃者にアクセスを提供するソフトウェアや電子メール。 | メール爆弾 | 疑いを持たない受信者に送信される悪意のある電子メール。受信者が電子メールを開くか、添付されたプログラムを実行すると、メール爆弾がそのコンピュータで悪意のある操作を実行します。 | 攻撃者 | 攻撃を実行する人物または組織。 |
注: 特定の脆弱性を利用するウイルスのように自動化された脅威が作成されているだけでなく、ユーザーの組織を対象とする攻撃者には限りがありません。攻撃者は、使用可能なあらゆる手段を使って、環境に危害を加えようとしています。 目的を持った攻撃はローカルでもリモートでも実行される可能性があります。さらに、そのような攻撃には、ソフトウェアの脆弱性、脆弱なパスワード、脆弱なセキュリティ構成、セキュリティ ポリシーの脆弱性、教育の脆弱性など、多くの可能性のある脆弱性の 1 つを徹底的に検索することも含まれます。 リリース後に Microsoft がソフトウェアを修正する方法Microsoft は、セキュリティの脆弱性からユーザーを保護することを約束しています。Microsoft はこの作業の一環として、使用可能なソフトウェアの更新プログラムを定期的にリリースしています。この作業の詳細については、http://download.microsoft.com/download/a/f/2/af22fd56-7f19-47aa-8167-4b1d73cd3c57/twc_mundie.doc のホワイト ペーパー「Trustworthy Computing」 (英語) を参照してください。 すべての Microsoft の製品グループには、それを支えるエンジニアリング チームがあり、ソフトウェアのリリース後に問題が発見されたときにソフトウェアの更新を開発しています。 Microsoft がセキュリティの脆弱性を認識した場合、その問題点は MSRC および適切な製品グループによって評価され、確認されます。MSRC が脆弱性の報告者と共に作業を行い、セキュリティ更新プログラムの詳細を含むセキュリティ情報の形式で、公開情報のリリースを調整する一方で、製品を支えるエンジニアリング チームは、その問題を解決するセキュリティ更新プログラムを作成し、テストを行います。 その後、ソフトウェアの更新プログラムが、Microsoft ダウンロード センターや次のサービスによって配信されます。 | • | Microsoft Windows Update | | • | Microsoft Office Update | | • | Microsoft Software Update Services (SUS) | | • | SUS Feature Pack を適用した Microsoft Systems Management Server (SMS) 2.0 | | • | Microsoft Systems Management Server (SMS) 2003 |
MSRC は、ソフトウェアの更新プログラムがリリースされると同時に、関連するセキュリティ情報を発信します。 注: セキュリティ更新プログラムは、オペレーティング システムやアプリケーションの複数のバージョンに対して開発されます。異なるバージョンのソフトウェアで期待できるサポート レベルを理解するには、Web サイト http://support.microsoft.com/lifecycle/ で Microsoft プロダクト サポート ライフサイクル ポリシーについて参照してください。 通常、セキュリティ更新プログラムは、サポートされている製品の現在の Service Pack だけでなく 1 つ前の Service Pack でも利用できるようになっていますが、必ずしもこのことが当てはまらない場合があるので、お使いの製品のプロダクト サポート ライフサイクル ポリシーを確認してください。 ソフトウェアの更新の用語表 6 に、2003 年 6 月 30 日より Microsoft がソフトウェアの更新の標準用語として使用する用語を示します。Microsoft は、それ以降、ソフトウェアの更新プログラムを説明するときに、"パッチ" という用語を使用しなくなることに注意してください。ただし、"パッチ管理" のプロセスを説明している場合は除きます (これは、これらの用語がソフトウェア業界で十分に理解されているためです)。 表 6: ソフトウェアの更新に関する Microsoft の用語 セキュリティ更新プログラム (Security patch) | 特定の製品に対し、広範にリリースされる更新プログラムで、セキュリティの脆弱性を解決します。セキュリティ更新プログラムは、多くの場合、"深刻度" と共に表現されます。深刻度は、実際には、セキュリティ更新プログラムが対処する脆弱性の MSRC 深刻度評価を表します。 | 重要な更新プログラム (Critical update) | セキュリティ関連以外の重大なバグを解決する、特定の問題に対する広範にリリースされる修正。 | 更新プログラム (Update) | セキュリティ関連以外の重大ではないバグを解決する、特定の問題に対する広範にリリースされる修正。 | 修正プログラム (Hotfix) | 製品の問題を解決するために使用される 1 つまたは複数のファイルにより構成される単一の累積的なパッケージ。修正プログラムは特定のユーザーの状況を解決します。Microsoft の書面による法的な同意がなければ、そのユーザーの組織外に修正プログラムを配布できません。以前は QFE (Quick Fix Engineering update)、パッチ、更新という用語が修正プログラムの同義語として使用されていました。 | 更新プログラムのロールアップ (Update rollup) | セキュリティ更新プログラム、重要な更新プログラム、更新プログラム、および修正プログラムの累積的なコレクション。ロールアップは Microsoft Internet Information Services (IIS) や Microsoft Internet Explorer などの単一の製品コンポーネントを対象にしています。複数のソフトウェアの更新を容易に展開できます。 | Service Pack | 製品のリリース後のすべての修正プログラム、セキュリティ更新プログラム、重要な更新プログラム、更新プログラム、およびその他のすべてのソフトウェアの更新プログラムで使用できなかった多くの問題点の解決を含む累積的なセット。Service Pack はユーザーから要望のあった限定された数のデザイン変更や機能を含む場合もあります。Service Pack は、Microsoft により、他のすべてのソフトウェアの更新プログラムよりも、広範にテストされ、配布されます。 | 統合 Service Pack | 製品と Service Pack を 1 つのパッケージに組み合わせたもの。 | Feature Pack | 製品に機能を追加する新しい機能のリリース。通常は、製品の次期リリースに組み込まれます。 |
注: これらは新しい定義のため、一部の既存のリソースやツールでは、前述の表で定義した用語通りに使用されていない場合があります。 プロアクティブな (予防的) セキュリティ パッチ管理の重要性Microsoft ソフトウェアに関連して、いくつかの攻撃や脆弱性が広く公表されてきました。プロアクティブな (予防的) セキュリティ パッチ管理を行っている多くの組織は、Microsoft が攻撃に先立って使用可能にした情報に従って行動したため、このような攻撃による影響を受けませんでした。 表 7 に、過去に確認された攻撃の一部を、その攻撃の日付と共に示します。いずれの場合も、MSRC のセキュリティ情報が脆弱性が認識される以前にリリースされ、(ソフトウェアの更新プログラムとその他の対策によって) その後の悪用をどのように防ぐかを述べています。表の最後の列の "攻撃までの日数" に、組織が MSRC の推奨事項を実装し、その後の攻撃を避けるために必要な日数を示します。 表 7: 過去の攻撃例と関連する MSRC セキュリティ情報 Trojan.Kaht | 2003 年 5 月 5 日 | 緊急 (Critical) | MS03-007 | 2003 年 3 月 17 日 | 49 | SQL Slammer | 2003 年 1 月 24 日 | 緊急 (Critical) | MS02-039 | 2002 年 7 月 24 日 | 184 | Klez-E | 2002 年 1 月 17 日 | * | MS01-020 | 2001 年 3 月 29 日 | 294 | Nimda | 2001 年 9 月 18 日 | * | MS00-078 | 2000 年 10 月 17 日 | 336 | Code Red | 2001 年 7 月 16 日 | * | MS01-033 | 2001 年 6 月 18 日 | 28 |
* このセキュリティ情報は、MSRC 深刻度が設定される前にリリースされました。 これらのモジュールは、これから起こるこのような攻撃を防ぐ手助けをするために、特に表中の "攻撃までの日数" に注目して執筆されました。 注: プロアクティブな (予防的) セキュリティ パッチ管理が、既知のソフトウェア脆弱性を対象とする攻撃を制限する効果的な方法を示すものです。前述の表は、犯罪の意図を持ってセキュリティの脆弱性を利用した対象組織内外の人々によって、故意に実行された攻撃を示したものではありません。 MSRC セキュリティ情報と、セキュリティで保護された環境を希望する組織にセキュリティ情報が与える機会をより適切に理解できるように、次のセクションでは、次の過去の 2 つの攻撃について簡単に説明します。 | • | Code Red | | • | SQL Slammer ワーム |
攻撃の回避例 1: Code RedCode Red は、非常に迅速に広がり、大きな影響を与える可能性を持っていたワームです。2001 年の 7 月 16 日に、最初の Code Red ワームはわずか 9 時間以内に 250,000 台のコンピュータに広がりました。このワームは、インターネットの速度を低下させ、Web ページを停止および破損させ、電子メールや E コマースのような、ビジネス アプリケーションや個人アプリケーションを混乱させるというさまざまな影響を与えました。 Code Red は、Web サーバー上でコードを実行するために、IIS 内部のバッファ オーバーランの脆弱性を悪用しました。IIS は、Microsoft Windows Server 2000 と共に既定でインストールされ、多くのアプリケーションで使用されています。 一部の組織は、MS01-033 の指示に従って、Code Red を回避しました。この MSRC セキュリティ情報は、Code Red がリリースされる 28 日前の、2001 年 6 月 18 日に公表されました。 技術的な側面と対策を含んだ、このセキュリティ情報の詳細については、次の Web サイトを参照してください。http://www.microsoft.com/japan/technet/security/bulletin/MS01-033.mspx 攻撃の回避例 2: SQL SlammerSQL Slammer (またはSapphire) は、Microsoft SQL Server 2000 と Microsoft Data Engine (MSDE) 2000 システムを対象としたワームで、インターネットや社内のプライベート ネットワークの両方に大量のネットワーク トラフィックをもたらし、効果的なサービス拒否攻撃として動作します (場合によっては意図的でないものもあります)。 SQL Slammer は、2003 年 1 月 24 日金曜日のおよそ午後 9 時 30 分 (PST) にネットワーク トラフィックの劇的な増加を世界中にもたらしました。SQL Slammer ワームの分析を次に示します。 | • | このワームは、世界中に広がるまで、ほぼ 10 分間しか要しませんでした。これは、これまでで圧倒的に最速のワームです。 | | • | 初期段階では、危害を受けたホストの数が 8.5 秒間ごとに倍増しました。 | | • | ピーク時 (ワームがリリースされた後約 3 分間で達しました) には、ネット上のインターネット プロトコル (IP) アドレスが 1 秒間に 5,500 万個スキャンされました。 | | • | このワームは、少なくとも 75,000、おそらくそれ以上のサーバーに感染しました。 |
SQL Slammer は、バッファ オーバーランの脆弱性を悪用していました。これは、Microsoft セキュリティ情報 MS02-039 (2002 年 7 月) によって、攻撃の 184 日前に最初に確認されていました。その後、セキュリティ情報 MS02-061 で再度確認されました。それぞれのセキュリティ情報では、セキュリティ更新プログラムが適切な対策と共に提供されていました。 技術的な側面と対策を含んだ、このセキュリティ情報の詳細については、次の Web サイトを参照してください。http://www.microsoft.com/japan/technet/security/bulletin/MS02-039.mspx SQL Slammer の教訓 SQL Slammer を回避することで組織が直面した課題の 1 つは、MSDE や SQL Server が多くの他の製品によってインストールされ、使用されるため、これらの製品がいたるところに存在するという性質でした。 SQL Slammer 攻撃は、セキュリティの脆弱性の性質における 3 つの重要な点に焦点を当てました。 | • | 環境に存在するすべてのコンピュータ、製品、およびテクノロジを正確に意識しておくことが、パッチ管理を成功させるための重要な前提条件です。 | | • | 効果的な攻撃は、高価な資産の脆弱性を必要としません。SQL Slammer は、同じネットワーク上の価値の低い、脆弱なコンピュータを使って、基幹業務を効果的に中断しました。 | | • | セキュリティ更新プログラムを一度展開しただけでは、脆弱性を除去するには十分ではないかもしれません。定期的に脆弱性の再発を調べ、認識し、それに対処する緊急対応管理を結び付けることも同じように重要です。 |
適切にパッチ管理を行うための必要条件パッチ管理は、組織に展開するソフトウェアの更新プログラムの制御を組織に提供するようにデザインされているため、組織の運用環境に更新プログラムを適用しようと計画しているすべての組織では、次の項目を確認してください。 | • | 担当者が役割と職務を理解していることなど、運用が効果的かどうか。 | | • | ツールとテクノロジが効果的なパッチ管理にとって最も適切かどうか。 | | • | プロジェクト管理プロセスが効果的かどうか。 |
効果的な運用MOF、MOF プロセス モデル、MOF サービス管理機能 (SMF)、および MOF チーム モデルでは、効果的な IT 運用のガイダンスを提供します。SMF の 3 つの要素である変更管理、構成管理、およびリリース管理は、パッチ管理にとって特に重要になります。 ツールとテクノロジここでは、すべての規模の組織でソフトウェアの更新プログラムのインストールを管理および制御するために使用できる、自動化されたツールを確認します。Windows ベース システムの企業のパッチ管理に使用できる、次の 2 つの主要な Microsoft テクノロジがあります。 | • | Software Update Services 1.0 Service Pack 1 | | • | Systems Management Server 2003 |
Software Update Services 1.0 Service Pack 1SUS は、Microsoft Windows Update Web サイト (http://windowsupdate.microsoft.com/) に重要な更新プログラム、セキュリティの更新プログラム、および Service Pack が掲載されたときに、そのような更新プログラム、Service Pack をすべてダウンロードするサービスをインストールできる無料のツールです。 これらの更新プログラムを許可すると、SUS は、Microsoft Windows Server 2003、Windows 2000 を実行しているすべての事前に構成されたサーバーに対して、また、Windows XP Professional、および Windows 2000 Professional を実行しているデスクトップに対して、これらの更新プログラムを自動的に使用可能にします。SUS は、オペレーティング システムやオペレーティング システムに含まれるコンポーネントに適用する重要な更新プログラムやセキュリティの更新プログラム (Service Pack を含む) のみをサポートしています。アプリケーション用などの、その他のソフトウェアの更新プログラムは、すべて異なるメカニズムで処理する必要があります。 セキュリティの更新プログラムの優先順位は、Microsoft Security Response Center (MSRC) によって定められています。MSRC の概要および意思決定プロセスの規則のセットについては、http://www.microsoft.com/japan/security/msrc/default.mspx を参照してください。 SUS には次の機能が含まれています。 | • | ソフトウェアの更新プログラムは、各 SUS サーバー上で独自に承認可能です。企業全体での段階的な展開や分離した環境でのテストが可能になります。 | | • | ソフトウェアの更新を、SUS を使用して配布できます (共有インターネット接続の帯域幅を節約します)。また、Windows Update からソフトウェアの更新プログラムをダウンロードするように、SUS クライアントを構成できます。 | | • | SUS は、インターネットにアクセスできないコンピュータに、Windows Update のソフトウェアの更新プログラムを提供できます。 | | • | SUS サーバーのアーキテクチャは、単純な親子関係から成り、大規模環境に対応可能です。各 SUS サーバーは 15,000 クライアントまでサポート可能です。 | | • | ソフトウェアの更新プログラムは、CD-ROM を使用して、インターネットに接続された SUS サーバーから、インターネットにアクセスできない SUS サーバー アーキテクチャへのコピーが可能です。 |
SUS サーバーは、Microsoft Windows Server 2003 オペレーティング システムまたは Windows 2000 Server、Internet Information Services 、および SUS クライアントとの通信にポート 80 を必要とします。すべての SUS サーバーは、環境の保守方法の柔軟性を実現しながら、SUS の親サーバーから、ソフトウェアの更新プログラム パッケージや承認を、手動で、または自動的に同期するように構成できます。 SUS クライアントは自動更新クライアント (Windows Update でも使用されている) を使用しています。クライアントは特定のサーバーに接続するように構成されており、ソフトウェアの更新プログラムの自動インストールやエンド ユーザーへの確認を構成できます。 注: SUS は、Windows Update から使用可能なセキュリティ更新プログラムの、重要な更新プログラム、更新プログラム、更新プログラムのロールアップ、および Service Pack のみを提供します。SUS を使用したデバイス ドライバの更新プログラムは提供されません。 SUS の現在のリリース (SUS 1.0 Service Pack 1) にはスキャン機能および監査機能が提供されていないため、SUS ベースのパッチ管理ソリューションでは、Microsoft Baseline Security Analyzer ツールも使用する必要があります。 SMS の詳細については、http://www.microsoft.com/japan/windowsserversystem/sus/default.mspx を参照してください。 SUS および MBSA を使用して、パッチ管理をサポートする方法に関する概要情報は、次のモジュールに記載されています。 SUS および MBSA を使用してパッチ管理をサポートする方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。 Microsoft Baseline Security Analyzer v1.1.1SUS により使用可能にした更新プログラムをインストールできなかったコンピュータが存在するかどうかを特定するには、定期的に Microsoft Baseline Security Analyzer (MBSA) を実行する必要があります。 MBSA は、不足しているセキュリティの更新プログラムをスキャンし、任意のコンピュータの一般的なセキュリティの推奨事例への準拠程度を報告し、そのコンピュータをセキュリティの脆弱性にさらす可能性のある構成オプションを特定します。また、SUS サーバーで許可済みで、まだインストールされていない更新プログラムをレポートするように構成することもできます。 MBSA はドメインやサブネット レベルの特定のコンピュータをセキュリティで保護するための要件を特定する機能を提供しますが、このようなコンピュータに更新プログラムを配布したり、コンピュータを構成する方法は提供しません。このため、MBSA はパッチ管理ソリューションを提供するために、SUS と組み合わせて使用する必要があります。ただし、MBSA は、技術情報の文書やホワイト ペーパーへのリンクなど、発見された脆弱性の修正方法に関する情報は提供しています。 MBSA は Windows Server 2003、Windows XP、および Windows 2000 システム上で実行され、複数台のコンピュータに対して、一般的なセキュリティの脆弱性やセキュリティの更新プログラムの不足を、次の表に従ってスキャンします。 表 8: MSBA 1.1.1 スキャン機能 Windows NT® 4.0 | あり | あり | Windows 2000 | あり | あり | Windows XP | あり | あり | Windows Server 2003 | あり | あり | Internet Information Services 4.0、5.0、および 6.0 | あり | あり | SQL Server 7.0 と SQL Server 2000 | あり | あり | Internet Explorer 5.01 以降 | あり | あり | Exchange Server 5.5 および 2000 | | あり | Windows Media Player 6.4 以降 | | あり | Office 2000 と Office XP | あり | * |
* MBSA 1.2 および Office の情報については、次の注意を参照してください。 MBSA は、各コンピュータに対して生成されたレポートを表示するためのグラフィカル インターフェイスおよびコマンド ライン スクリプトを提供します。MBSA は、セキュリティ関連の新しいソフトウェアの更新プログラムに関する査定詳細の現在の一覧を確認するために、Microsoft ダウンロード センターに格納されている XML ファイルをコピーします。 注: MBSA 1.2 には、Office 更新インベントリ ツールの Office アップデートのスキャン機能が含まれています。 MBSA の詳細については、http://www.microsoft.com/japan/technet/security/tools/mbsahome.mspx を参照してください。 Systems Management Server 2003 Microsoft Systems Management Server (SMS) 2003 は、大量のクライアントにソフトウェア更新の配布を展開し、管理するのに適したメカニズムです。SMS が提供する展開を正常に実行するための重要な機能は、次のとおりです。 | • | 展開されているコンピュータの台数を判断し、その場所および役割を識別するためのインベントリ機能。 | | • | インストールされているソフトウェア アプリケーションやソフトウェアの更新プログラム、および展開されているコンピュータにインストールする必要があるソフトウェア アプリケーションやソフトウェアの更新プログラムを識別するためのインベントリ機能。 | | • | 組織が通常の勤務時間外、またはビジネス運用への影響が最も少ない時間帯に、ソフトウェアの更新プログラムを展開できるスケジューリング機能。 | | • | 管理者がインストールの進捗状況を監視できるステータス レポート機能。 |
SMS 2003 インベントリ スキャン プログラムは、ソフトウェアの更新プログラムを効果的に管理するために不可欠です。これらのプログラムは、検出ロジックの自動化されたソースを使用して、各クライアント コンピュータに適用可能なインストール済みの更新プログラムのインベントリを作成するために使用されます。結果のデータは、Systems Management Server インベントリに含められ、Web ベースのレポート機能を使用してステータスの包括的なビューが提供されます。通常は、インベントリ データはセキュリティ情報として Microsoft によってリリースされるデータ項目に制限されます。 SMS 2003 には、次のツール (SMS 2.0 Software Update Services Feature Pack でも利用可能) が含まれています。 | • | セキュリティ更新インベントリ ツール | | • | Microsoft Office 更新インベントリ ツール | | • | ソフトウェア更新の配布ウィザード |
セキュリティ更新インベントリツール セキュリティ更新インベントリ ツールは、SMS インベントリ機能に基づいてビルドされており、セキュリティ更新プログラムのために各クライアントをスキャンするときに、MBSA を使用します。結果データは SMS インベントリに含められ、Web ベースのレポートを使用して包括的な状態が提供されます。このツールは、既定では SMS サイトにはインストールされませんが、SMS 2003 Software Update Scanning Tools の一部で、http://www.microsoft.com/japan/smserver/downloads/2003/default.mspx からダウンロードできます。 Microsoft Office 更新インベントリツール Microsoft Office 更新インベントリ ツールは、既存の Microsoft Office Inventory Tool を使用して、SMS クライアントでインストール済みまたは適用可能な Office アップデートの自動化された継続的なスキャンを実行します。スキャンされたデータは変換して SMS インベントリに格納され、Web ベースのレポートでも表示できます。このツールは、既定では SMS サイトにはインストールされませんが、SMS 2003 Software Update Scanning Tools の一部で、http://www.microsoft.com/japan/smserver/downloads/2003/default.mspx からダウンロードできます。 ソフトウェア更新の配布ウィザード ソフトウェア更新の配布ウィザードは、利用可能な更新プログラムとクライアント コンピュータのインベントリを比較し、不足している更新や、インストール済みの更新を判断します。必要な更新のみがインストールされ、冗長もしくは不要な更新は無視されるか延期され、システムのオーバーヘッドを軽減します。 ソフトウェア更新の配布ウィザードは、次の機能を提供します。 | • | 新しいセキュリティの更新情報に基づいて、すべてのクライアントのソフトウェア更新プログラムの状態をインベントリへ追加。 | | • | 不足していると識別された更新のレビューと承認。 | | • | 各更新プログラムまたは更新プログラムのセットにパッケージと提供情報を合わせる。 | | • | SMS ソフトウェア配布機能を使用したコンピュータへの提供情報の更新の配布。 | | • | Window Update 形式の通知、および豊富なユーザー エクスペリエンス。 | | • | アプリケーションを保存して閉じることを可能にするタイマの使用、オプションでユーザーが更新を延期したり、コンピュータを再起動しないことを選択できる機能。 |
SMS 2003 の詳細については、http://www.microsoft.com/japan/smserver/ を参照してください。 SMS 2003 を使用して、パッチ管理をサポートする方法に関する概要情報は、次のモジュールに記載されています。 SMS 2003 を使用してパッチ管理をサポートする方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。 ツールとテクノロジの比較表 9 に、SMS 2003 および SUS 1.0 with Service Pack 1 で提供される機能の比較を示します。 表 9: パッチ管理機能 - SUS 1.0 with SP1 対 SMS 2003 内容に対してサポートされるプラットフォーム | Windows 2000、Windows Server 2003、Windows XP | Windows NT 4.0、Windows 2000、Windows Server 2003、Windows XP、Windows 98 | サポートされている内容の種類 | 前述のプラットフォームの場合、セキュリティおよびセキュリティロールアップ更新プログラム、重要な更新プログラム、および対応する Service Pack のみ | 前述のプラットフォームの場合、すべての修正プログラム、Service Pack および更新プログラム。Microsoft およびその他のアプリケーションの場合、修正プログラム、更新プログラム、およびアプリケーションのインストールもサポートしています。 | システムを対象とする内容 | なし | あり | ネットワーク帯域幅の最適化 | あり、更新プログラムの展開用 | あり、更新プログラムの展開とサーバーの同期用 | 更新プログラムの配布制御 | 基本 | 詳細 | 更新プログラムのインストールとスケジューリングの柔軟性 | 管理者による制御 (自動)、またはユーザーによる制御 (手動) | 細かなスケジューリング機能を使用した管理者制御 | 更新プログラム インストールのステータス レポート | 制限付き: クライアント インストールの履歴およびサーバーベースのインストール ログ | 包括的: インストール ステータス、結果、および準拠の詳細 | 展開計画 | 適用なし | あり | インベントリ管理 | 適用なし | あり | 準拠監査 | 適用なし | あり |
効果的なプロジェクト管理プロセス最大の成果を得るためには、効果的なプロジェクト管理プロセスを使用して、プロジェクトとしてこのモジュールで説明されているパッチ管理プロセスを使用する必要があります。 大規模な組織には独自の方法があり、そのすべてがこのモジュールで提供されるガイダンスと互換性がある必要があります。プロジェクト管理ガイダンスには Microsoft Solutions Framework (MSF) を使用することをお勧めします。MSF に関する詳細については、http://www.microsoft.com/msf (英語) を参照してください。 パッチ管理への 4 段階のアプローチMicrosoft がお勧めするパッチ管理プロセスには、ソフトウェアの更新を管理するための 4 段階のアプローチがあり、運用環境への暫定的なソフトウェア リリースの展開と保守の制御を組織に提供するようにデザインされています。 次の 4 段階があります。 査定このプロセスは、運用環境に何が実装されているか、直面する可能性のあるセキュリティの脅威や脆弱性、および組織が新しいソフトウェアの更新プログラムに対応するように準備されるかどうかの査定から開始されます。 査定段階に関する詳細については、モジュール「パッチ管理フェーズ 1 - 査定」を参照してください。 識別識別段階中の目標は、新しいソフトウェアの更新プログラムを信頼できる方法で発見し、それが運用環境に関連しているかどうか、更新プログラムが通常の変更か緊急の変更であるかどうかを判断することです。 識別段階に関する詳細については、モジュール「パッチ管理フェーズ 2 - 識別」を参照してください。 評価と計画評価および計画段階中の目標は、ソフトウェアの更新プログラムを展開するかどうかを決定し、その展開に何が必要であるか判断し、運用環境に類似した環境でソフトウェアの更新プログラムをテストして、ビジネスの基幹システムおよびアプリケーションが侵害されないことを確認することです。 評価および計画段階に関する詳細については、モジュール「パッチ管理フェーズ 3 - 評価と計画」を参照してください。 展開展開段階中の目標は、展開のサービス品質保証制度 (SLA) の必要条件のすべてを満たすように、承認されたソフトウェアの更新プログラムを運用環境に正しく公開することです。 展開段階に関する詳細については、モジュール「パッチ管理フェーズ 4 - 展開」を参照してください。 図 1 に、プロセスと 4 つのフェーズを示します。  この 4 段階のプロセスは、MOF 変更管理、リリース管理、および構成管理サービス管理機能 (SMF) に基づいています。これらの詳細については、http://www.microsoft.com/technet/itsolutions/cits/mo/default.mspx (英語) を参照してください。
| 
