評価とレビュー : Systems Management Server の使用

ステップ 1 : 適切な対応を決定する

適切な対応を決定する

RFC (変更要求) では、運用環境で必要とされる変更の種類 (たとえば、ソフトウェア更新プログラムの展開、脆弱性を改善する対策の適用、またはその両方) が決定され、対策を実施するための必要な変更が記述されます。

評価と計画の最初のステップは、RFC を確認し、ソフトウェアの脆弱性や脅威に対する最も適切な対応を決定することです。これには、次の対応が含まれます。

•	ソフトウェア更新プログラムの優先順位とカテゴリを決定します。
•	ソフトウェア更新プログラムを展開するための承認を取得します。

ソフトウェア更新プログラムの優先順位とカテゴリを決定する

ソフトウェア更新プログラムの承認を受ける前に、その優先順位とカテゴリを決定する必要があります。優先順位とカテゴリは最初に変更イニシエータによって割り当てられ、RFC に含まれていますが、それらの割り当ては変更要求が承認される前に、見直され合意または変更されることが必要です。

ソフトウェア更新プログラムの優先順位を決定する

優先順位のレベルは、ソフトウェア更新プログラムが変更プロセスで処理される速度を決定するため、特に重要です。ソフトウェア更新プログラムの優先順位レベルを決定する際には、以下の点を考慮します。

•	重要なビジネス資産が何であるかを明確にし、それらの資産がソフトウェア更新プログラムがインストールされないと、潜在的なセキュリティ侵害やシステムの不安定な動作の危険性にさらされることになるかどうかを判断します。高価値資産に更新プログラムを適用または適用しない場合の影響に基づいて、変更要求の優先順位を決定します。
•	過去に攻撃対象となったことのあるビジネスに不可欠なサービス (基幹業務 (LOB) アプリケーションなど) を実行しているシステムにソフトウェア更新プログラムを適用する場合、これが変更要求の優先順位を上げる正当な理由となります。
•	特定のセキュリティの脆弱性に対する脅威を最小限に抑える対策が展開された場合、このことは変更要求の優先順位を下げる理由となります。変更要求の優先順位が低い場合でも、脆弱性を改善するためにソフトウェア更新プログラムを運用環境に展開することが妥当な場合があります。
•	運用環境に対する脆弱性の脅威が何であるかを明確にします。多くのセキュリティ情報と関連するソフトウェア更新プログラムが、環境内の少数のコンピュータのみに適用されるものである場合があります。脆弱性の脅威が小さい場合、変更要求の優先順位は下げられる可能性があります。

次の表は、変更要求の優先順位を他の変更要求と比較して判断する際に役立ちます。最初の表は、優先順位レベルと推奨期限および最低限の推奨期限の対応を示します。

表 2.1

優先順位	推奨期限	最低限の推奨期限
緊急	24 時間以内	2 週間以内
高	1 か月以内	2 か月以内
中	可用性に応じて、新しいサービスパックや脆弱性に対する修正を含む更新プログラムのロールアップを、4 か月以内に展開します。	ソフトウェア更新プログラムを、6 か月以内に展開します。
低	可用性に応じて、新しいサービスパックや脆弱性に対する修正を含む更新プログラムのロールアップを、1 年以内に展開します。	ソフトウェア更新プログラムを 1 年以内に展開するか、またはまったく展開しないことにします。

2 番目の表は、優先順位に影響を与える可能性のある要因の例を示します。

表 2.2

環境/組織の要因	優先順位の調整
価値が高いまたは攻撃を受ける確率が大きい資産	上げる
過去に攻撃対象となった資産	上げる
緩和要因の実施 (脅威を軽減する対策など)	下げる
価値が低いまたは攻撃を受ける確率が小さい資産	下げる

緊急変更要求

セキュリティ更新プログラムで対処する脆弱性が既に悪用されているかまたは悪用されそうになっている場合、または運用環境で発生しているシステムの不安定な動作が更新プログラムによって修正される場合は、状況に応じて要求を "緊急" と分類し、運用環境内で行われるその他のすべての変更よりもこの要求の優先順位を上げる必要があります。

ソフトウェア更新プログラムのカテゴリを決定する

ソフトウェア更新プログラムのカテゴリは重要です。変更確認者が運用環境内のシステムとサービスへの影響を把握するのに役立つためです。変更要求のカテゴリ (または影響) を確定するには、次の点を判断する必要があります。

•	ソフトウェア更新プログラムをインストールする必要があるコンピュータと、それらのコンピュータの役割 (ビジネス上の重要度)。たとえば、ビジネスに不可欠なコンピュータの再起動が必要なソフトウェア更新プログラムは、再起動を必要としないソフトウェア更新プログラムよりも、大きな影響を及ぼします。
•	ソフトウェア更新プログラムの展開をサポートする追加の変更の必要性。たとえば、ソフトウェア更新プログラムを現在のサービスパックのみに適用する場合は、そのサービスパックがある特定の運用システムにインストールされていないと、それらのシステムを特定のセキュリティ脆弱性から保護できない可能性があります。この場合は、サービスパックとソフトウェア更新プログラムの両方を展開する必要があるため、変更要求の影響は大きく、そのためカテゴリも高くなります。
•	いったんインストールしたソフトウェア更新プログラムをアンインストールできるかどうか。アンインストールできない場合、アンインストールできるソフトウェア更新プログラムの場合と比較して、運用環境に対するリスクが大きくなります。そのようなソフトウェア更新プログラムを展開して、特定のセキュリティ脆弱性から保護したり、特定のシステムの不安定性に対処したりすることが必要になる場合があり、変更要求のカテゴリにこの点を反映させる必要があります。
•	ネットワークインフラストラクチャに対する影響。同時に多数のコンピュータに対して大規模なソフトウェア更新プログラムを展開すると、ネットワークパフォーマンスが低下し、環境全体の適切な運用に悪影響を及ぼす可能性があります。すべてのソフトウェア更新プログラムのドキュメントを詳細に見直し、ソフトウェア更新プログラムの規模とソフトウェア更新プログラムを適用するコンピュータ数を把握しておく必要があります。この情報は、リリースのスケジュールを適切に設定する際に役立ちます。
•	インストール中に特定のサービスを停止したり、一時停止したり、閉じたりする必要性。これは、組織の重要なサービスに影響を及ぼす可能性があります。インストール中にエンドユーザーがコンピュータを操作できなくなる場合もあります。

ソフトウェア更新プログラムを展開するための承認を取得する

変更要求の優先順位とカテゴリを決定したら、ソフトウェア更新プログラムを運用環境に展開する前に、変更要求が確認され、承認を受けることが必要です。変更要求が承認されるには、次のことが必要です。

•	意思決定プロセスに関与する者を決定する。
•	変更要求を確認し、ソフトウェア更新プログラムを展開した場合のリスクと結果を評価して、最適な行動方針を選択する。
•	影響を受けるすべてのシステムにソフトウェア更新プログラムを展開する担当者を特定する。

関与者を決定する

ソフトウェア更新プログラムを運用環境に展開するのに、その確認と承認に関与する者を決定することが重要です。緊急以外の更新プログラムの場合は、影響を受けるビジネスの全領域の代表者で構成された変更諮問委員会 (CAB) が確認と承認を行います。変更マネージャは、通常、提出された RFC の承認に責任を負います。この承認は、リスク、影響、および優先順位を把握するのに有効なさまざまな情報源を利用して行います。変更の承認のほかに、変更マネージャは適切な人材のグループを編成して、実装を成功させるためにすべてのリスクが識別され軽減されることを保証する責任があります。つまり、そのための適切な人材を CAB に出席させます。

パッチ管理の成功にとって、さまざまなサポートチームが結集して導入する更新プログラムに関連したリスクを判断することが重要です。理想的には、すべてのパッチ管理に対する要求は自動化されたシステムに提出され、サポートチームへ通知が送信され、変更会議で説明と確認が行われるようにします。更新プログラムは環境内のさまざまな構成要素に影響を与える可能性があるため、次の Microsoft Operations Framework (MOF) チームモデルの役割クラスタを参考にして、パッチ管理の CAB に出席する代表者を構成することをお勧めします。

表 2.3

役割	組織での職種名	職務内容
セキュリティ	セキュリティチーム	新しい更新プログラムが環境のセキュリティを侵害しないことを保証する
サポート	ヘルプデスク、DBA、ネットワークエンジニア、サーバー/Exchange/SMS 管理者	エンドユーザーとの通信、および問題発生時の迅速な解決を保証する
運用	DBA、ネットワークエンジニア、サーバー/Exchange/SMS 管理者	配慮が必要な技術上の依存関係の識別を支援する
リリース	変更/リリース/構成管理、変更実装チーム (DBA、ネットワークエンジニア、サーバー/Exchange/SMS 管理者から構成)	変更の承認、スケジューリング、テスト、および実装作業を支援する
パートナー	ベンダ (TAM)、サードパーティサポート、サービスレベルマネージャ	さまざまなソフトウェアまたはハードウェアコンポーネントに関する更新プログラムの相互運用性を確認する

メモこれらは定義の例です。実際のニーズに合わせてこれらの定義を確立する必要があります。

この代表者グループを編成することで、パッチ管理の下で変更のカテゴリを決定できる状況になります。優先順位と影響は以前の推奨事項から判断される定義に基づいて割り当てられ、すべてのチームが今回の更新プログラムのリリースについて熟知します。

緊急の変更

ベストプラクティスに次のような指摘があります。迅速に対応された承認を除いて、その他の変更プロセスは 1 つの例外を除いて皆同じである。時間が許す場合はテストが推奨されるが、緊急の変更が実施されるまでは必要とされない。緊急の変更が実施される前にテストを行うことができない場合は、変更が環境に適合していることを確認するために後でテストを行うことをお勧めします。大部分の組織では、緊急の変更が運用環境に導入された後で問題が何も起こらなければ、変更は適切だったはずだということを仮定しています。慎重な組織では、導入後であっても緊急の変更をテストして、長期的に運用環境に悪影響を与えるリスクがほとんどないことを確認します。

緊急の変更のモデルには、次の手順を含めます。

1.	RFC を提出します。
2.	変更マネージャが管理する CAB の下位グループを編成します。
3.	必要に応じて、RFC 承認のために CAB/EC にエスカレーションします。
4.	RFC を作成し、(時間が許せば) テストします。
5.	承認された RFC を運用環境に導入します。
6.	失敗した変更を元に戻します (該当するものがある場合)。
7.	完了した RFC を閉じます。
8.	導入後レビューを実行します。
9.	新しい変更を開いて、標準の期限に従います。これにより、期限の短縮が運用環境に悪影響を与えないことを保証できます。

以上のプロセスは通常の変更プロセスとほとんど同じです。緊急の変更は通常の変更と同じプロセスに従いますが、特定のステップが迅速に行われるようにします。たとえば、業務に影響を与えないように変更の実装をすばやく行う目的のためのテストなどです。

CAB とその編成方法の詳細については、http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx (英語) から変更管理 SMF に関する情報にアクセスしてください。

変更要求を確認する

適切な人材を招集したら、運用環境に対するソフトウェア更新プログラムのリスクと影響を評価して、展開するかどうかを決定する必要があります。この決定を行うには、次の点を検討する必要があります。

•	運用環境でどんな問題が派生するか。
•	ソフトウェア更新プログラムを適用する場合としない場合で、どのような影響があるか。
•	ソフトウェア更新プログラムを展開する場合としない場合に予想されるコストはどのくらいか。
•	ソフトウェア更新プログラムの展開時に、セキュリティの脆弱性またはシステムの不安定性に対する脅威を軽減するために適用できる手順はあるか。
•	コンピュータのダウンタイムに対して、どのような影響があるか。ソフトウェア更新プログラムの展開を延期することのリスクと、環境へソフトウェア更新プログラムを展開した結果コンピュータのダウンタイムが生じることのリスクを比較検討する必要があります。
•	ソフトウェア更新プログラムを展開する最も適切で効果的なメカニズムは何か。
•	ソフトウェア更新プログラムに伴う既知の問題や副次的な影響があるか、また、システムの再起動は必要か。
•	ソフトウェア更新プログラムを展開したり、展開中に発生する問題に対処したりするためのリソースは十分に確保されているか。
•	ソフトウェア更新プログラムを展開する前に解決する必要がある依存関係や前提条件に対して、どう対処するか。

ソフトウェアの脆弱性に対する最良の対応策は、ソフトウェア更新プログラムを展開して問題を解決することですが、運用環境内のシステムにソフトウェア更新プログラムを展開している間は、ネットワークポートを閉じたり、システムへの外部からのアクセスを停止したりするなど、短期的な対策を実施することが望ましい場合があります。このような対策を実施すると、次のようなメリットがあります。

•

ほとんどのソフトウェア更新プログラムでは、インストールを完了してコンピュータを保護するには、インストール後に対象のコンピュータを再起動する必要がありますコンピュータの再起動が特定のメンテナンスの時間帯に制限され、ソフトウェア更新プログラムを環境にすぐに展開できない場合は、推奨する対策を講じることにより、ソフトウェア更新プログラムを展開するまでコンピュータを効果的に保護できます。

•

この対策は、ソフトウェア更新プログラムの場合よりも、リスクが小さく、短時間で適用でき、またテスト時間も短くて済みます。たとえば、ネットワークポートを無効化したり、特定のセキュリティ脆弱性にさらされるサービスやシステムを停止したりして、後からソフトウェア更新プログラムを適用した方がはるかに簡単な場合があります。

コンピュータを強化する対策を実施すると、多くの場合、多数の一般的なセキュリティ脆弱性からコンピュータを保護できます。効果的にコンピュータを保護する代表的な対策の例として、特定のネットワークポートをブロックする方法と、使用されていないサービスを無効にする方法があります。コンピュータを強化する対策の詳細については、「The Threats and Countermeasures Guide」(http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=1b6acf93-147a-4481-9346-f93a4081eea8) (英語) を参照してください。

メモ対策を展開してセキュリティの脆弱性にさらされるリスクを軽減する場合でも、セキュリティ更新プログラムの展開スケジュールを確立する必要があります。

たとえば、システムに更新プログラムをまだ適用していない状態で、ワームやウイルスに感染したコンピュータをネットワークに導入すると、保護されていない全システムに感染が一気に広がる可能性があります。対策を展開すると、ソフトウェアを更新する必要がなくなるのではなく、単に変更要求の優先順位が下がるだけです。

ソフトウェア更新プログラムの展開責任者を決定する

ソフトウェア更新プログラムを展開し、必要に応じて何らかの対策を使用するという合意に達したら、これらの変更を確実に実施するための責任者を決定する必要があります。この責任者は、以下の手順を実行する必要があります。

•	必要な変更を行うための計画を作成します。
•	必要なリソースを決定して取得します。
•	変更を展開するのに必要なスクリプト、ツール、およびドキュメントの開発を手配します。
•	十分なテストが確実に実施されるようにします。
•	変更が運用環境に確実に展開されるようにします。
•	展開の成功または失敗を評価します。

上記の活動を監督する責任者がいないと、ソフトウェア更新プログラムが展開されないリスクを負うことになります。通常、指定された責任者は、http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx (英語) から参照できるリリース管理 SMF に関する情報の中で説明されているリリースマネージャの役割を担います。