Insider's EyeMicrosoft社内の事例に学ぶクライアント・パッチ管理術Chris Alliegro 2004/02/03 Copyright(C) 2004, Redmond Communications Inc. and Mediaselect Inc. |
本記事は、(株)メディアセレクトが発行する月刊誌『Directions on Microsoft日本語版』 2004年1月15日号 p.38の「Microsoft社内事例に学ぶクライアント・パッチ管理」を、許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。 |
セキュリティ問題の影響を受けるすべての企業の中で、Microsoft自身ほど事態を深刻に受け止めている企業はないだろう。Microsoftでは、社内システムを保護するため、Systems Management Server(SMS)、Windows Update、電子メール、およびログオン・スクリプトを使用して社内ネットワークのクライアントに緊急のパッチを配布、インストールし、クライアントPCが常に最新のソフトウェアで実行されるようにしている。
MicrosoftのITグループが直面しているのは、ソフトウェア開発企業に特有の問題だが(開発ラボには標準構成以外のクライアント・ソフトウェアを実行する環境がある)、このグループがクライアントPCの保護に使用する処理と技術は、ほかの企業が同様の問題に対処する際の基準として利用できる。また、MicrosoftがどのようにSMS 2003を社内に配置するかを理解することによって、ほかのIT専門家がこの製品に関するそれぞれの配置計画を評価する場合に役立つだろう。
Microsoftにおけるクライアント・セキュリティ対策
MicrosoftのIT組織の中では、2つのグループがクライアントPCのセキュリティ保護を担当している。CorpSecIT(コーポレート・セキュリティ)グループは脆弱性の潜在的な影響を追跡し、評価する。ここでの脆弱性とは、ワームやウイルスなどの攻略手段にシステムをさらすソフトウェアのバグを示す。もう一方のGCS(グローバル・クライアント・ソフトウェア)グループは、脆弱性を修正するコードであるパッチをテストし、配布する(パッチ関係の用語と概念については、「セキュリティ問題のカテゴリ:脆弱性、攻略、パッチ」を参照)。
セキュリティ問題のカテゴリ:脆弱性、攻略、パッチ 通常、Microsoft製品の脆弱性は、SQL Serverを使用している顧客や独立したセキュリティ監視グループなど、外部の情報源から指摘される。セキュリティ監視グループとしては、SQL Slammerによる攻略の標的となった脆弱性を発見した「狂乱の最終段階(The Last Stage of Delirium)」という奇妙な名前のグループなどがある。ユーザーまたはグループは、脆弱性を見つけると、Microsoft Security Resource Center(MSRC)に警告を発する。MSRCは、脆弱性に関連した潜在的な危険性を評価し、Microsoftの該当する開発組織に警告する。その開発組織は脆弱性を知らされると、基になるコードの脆弱性に対処する。脆弱性の脅威が大きいと判断された場合、MicrosoftはMSRCを通じてパッチをすぐにリリースする。脆弱性がそれほど重大ではないと判断された場合、修正は製品の次のService Packに組み入れられることが多い。Microsoftは製品のバグ修正や以前リリースしたパッチを集めたものを定期的にService Packとしてリリースしている。 一般に、Microsoftは脆弱性を公式に発表すると同時にその脆弱性に対処するパッチもリリースする。この時点で競争が始まる。ハッカーは、先を争って脆弱性を標的とする攻略コードを作成しようとする一方、企業のIT部門は脆弱性を調べ、パッチをテストし、パッチの適用によりネットワークとクライアントを攻略の危険性から保護する作業を開始する。脆弱性が一般に知られてからその脆弱性を標的とする攻略が現れるまでの時間は着実に短くなっており、2003年12月の時点で2〜3週間になっている。例えば、2003年8月、Blasterワームは対応する脆弱性が公表されてから約17日後に現れた。一方、2001年7月のCode Redワームは、脆弱性が発表されてから数カ月後に現れた。脆弱性が知られるとすぐに行われる攻略を意味する「ゼロデイ・アタック」も、実現される可能性が高まっている。 いずれの場合も、IT部門の目標は、公表されている脆弱性の攻略が出現する前に、脆弱な企業クライアントにパッチを100%適用することである。 |
これら2つのグループは共同でユーザーが社内のパッチ要求に従っているかどうかを調べ、従っていない場合は処置を施す。2つのグループは社内で高い地位に置かれており、CIO(最高情報責任者)のリック・デヴェヌーティ(Rick Devenuti)氏の直属となっている。
Microsoftの大口顧客や大規模な競合企業と同様、これらのグループはMicrosoftのデスクトップ・ソフトウェア製品やサーバ・ソフトウェア製品に必要なパッチを頻繁に適用していくという、やっかいな作業に直面している。Microsoftの事業規模とその性質を考慮に入れると、問題はさらに深刻だ。Microsoftでは、世界中の約400カ所で5万5000人以上が働いている。こうした社内ユーザーは30万台以上のコンピュータをネットワークに接続している。その多くは公式の企業ドメインには結合されておらず、管理が難しい。
社内パッチを管理するグループが直面する難題により、Microsoft開発チームは実際の場面でこの問題に直接向き合うことになった。このことは、主に2つの成果につながっている。第1に、SMSのパッチ管理機能など、製品の要件と機能を特定することに役立っている。第2に、ITグループが製品から負わされている労力を製品グループが認識し、最小限にするよう対策を立てることだ。例えば、顧客からのフィードバックとMicrosoftのIT組織からの直接フィードバックに基づいて、Microsoftはパッチ配布スケジュールを週1回から月1回に変更した(MicrosoftがPCをパッチするプロセスの概要については、図「緊急パッチの処理プロセス」を参照)。
緊急パッチの処理プロセス |
MicrosoftのCorpSecIT(コーポレート・セキュリティ)グループとGCS(グローバル・クライアント・ソフトウェア)グループは、MicrosoftのクライアントPCに最新の緊急パッチが適用されているように共同で作業している。CorpSecITグループは、外部(ウイルス対策ソフトウェアのベンダ・サイトなど)やMicrosoftの情報源を監視し、セキュリティ上の警告やソフトウェアの脆弱性に関する情報がないかを調べる。また、MicrosoftのWindows Updateサイトも監視し、パッチが利用できるかどうかもチェックしている。CorpSecITは脆弱性の脅威レベルを決定し、緊急と判断した脅威に対してはクライアントのパッチの実施ガイドライン(クライアントが自発的にパッチをインストールする期間など)を設定し、GCSグループに通知する。 GCSグループは、緊急の脅威を通知されると、約72時間で対応するパッチをテストし、脅威についてクライアントに警告し、パッチを配布する。この際、「マネージド・クライアント」にはSMS 2003を使用してアクセスし、「アンマネージド・クライアント」(製品開発のためのラボ用ドメインで管理されているPCなど)には電子メールで通知を行う。パッチの配布後、GCSは、パッチ・インストールがCorpSecITチームにより設定されたガイドラインに従って適用されるかどうかを監視する。適用の期限は、脅威の性質に従って0〜14日になる。自発的なパッチ・インストールの期限が過ぎると、GCSとCorpSecITはマネージド・クライアント・マシンにパッチを強制インストールし、未適用のアンマネージド・クライアントを企業ネットワークから除去する。 CorpSecITグループは、パッチの一般リリースに際しての品質保証の役割も担う。CorpSecITがパッチの有効性を検証し、その安定性をテストした後、Windows Updateサイトやほかの顧客向け社外セキュリティ資源を担当するグループであるMicrosoft Security Resource Center(MSRC)がパッチを一般リリースする。ただし、このテスト機能を除けば、CorpSecITはMicrosoftの開発部門から特別な扱いを受けず、この初期段階の情報に基づいてMicrosoftの社内パッチ処理プロセスを開始することもない。脆弱性とパッチが公表された時点で、初めてMicrosoftの社内パッチ処理プロセスは開始される。 |
■脅威の追跡と評価
CorpSecITグループは、新しい脆弱性についてほかのITセキュリティ企業と同じ方法で学ぶ。つまり、ウイルス対策ソフトウェアのベンダ・サイト、CERT Coordination Center(CERT/CC)、Microsoft自体のセキュリティ関連サイトなど、複数の情報源を監視して、セキュリティ上の警告や脆弱性、パッチの可用性について調べるのである。脅威の原因がMicrosoft製品の欠陥にはない場合(電子メールで広まる一部のウイルスなど)、グループは是正手段を検討評価し、実施する(例えば、企業クライアントにウイルス定義ファイルを更新するよう通知する)。Microsoft製品の脆弱性について、グループはその脆弱性を狙った攻略がもたらす可能性がある影響を検討評価し、脅威のレベルを「緊急」「警告」「注意」の3つに分類する。
●緊急レベル
緊急の脆弱性が攻略された場合、Microsoftの社内セキュリティは大きな危険にさらされる可能性がある。このような攻略は、Microsoftが3つのEと呼ぶものの1つに関係している。
-
特権の昇格(Escalation):マシンの管理特権を自己に付与できるコードなど。
-
スコープの拡張(Expansion):ほかのコンピュータに感染できるウイルスなど。
-
機密データの露出(Exposure):Windowsのソース・コード、Microsoftの財務実績といった機密データの露出。
Blasterワームは緊急の脅威の一例である。このワームは異なるホスト間で自己コピーを渡すことができるため、被害が拡大していく恐れがある。
●警告レベル
攻略対象が個々のマシンまたはそのマシンのデータに限られているか、あまり普及していないアプリケーションを対象としている場合、一般に警告レベルの脅威と考えることができる。このような脅威はサービスの低下や拒否につながることがあるが、自己増殖したり、企業セキュリティに脅威を与えたりする可能性は少ない。最近の脆弱性「TechNetセキュリティ情報:MS03-038」は、サイト利用者のマシンで特定のMicrosoft Accessコンポーネントが実行された場合にそのマシンでハッカーがコードを実行できるようにするものだが、CorpSecITはこの脆弱性を警告レベルの脅威と判断した。
●注意レベル
注意レベルの脅威は、企業セキュリティや個々のマシンのパフォーマンスやデータに対して、まったくといっていいほど危険性がない。一般に、このレベルに指定される脆弱性は製品のバグにすぎない。
■パッチ適用の警告と猶予期間の設定
Microsoftの脆弱性に対する社内対応は、指定された脅威レベルによって決まる。ユーザーの注意をすぐに引く必要があるのは、緊急の脅威のみである。緊急の脅威の場合、パッチを積極的に告知、配布し、インストールの適用期限を設定する。期限前には、社内ユーザーが自発的にパッチを適用する機会が与えられる。期限を過ぎると、グループは、未適用のクライアントにパッチを強制インストールする。
CorpSecITグループは、潜在的な攻略の大きさとそのような攻略が表立って現れる可能性を考慮に入れて緊急のパッチの適用期限を判断する。ほとんどの場合、期限は2週間に設定されるが、危険性が大きい場合は期限が短縮される。また、CorpSecITグループは、間近に脅威が迫った危険度の高い攻略が予想される場合に備えて、緊急処置を取る手順も用意している。
例えば、CorpSecITは、社内クライアントがBlasterワーム用のパッチを自発的にインストールするために8日間を用意し、期限が過ぎた後、強制インストールを始めた。また、8日間の期限が切れるまでに、自発的なパッチ適用を99%にする目標を設定した。
通常、警告/注意レベルの脅威と判断された脆弱性のパッチは個々のユーザーに任される。そのような脆弱性のパッチは告知されることはあっても、ユーザーは一定のスケジュールに従ってパッチを適用するように強制されることはない。ほとんどの場合、警告/注意レベルの脅威に対する処置は、Microsoft製品チームが社内・社外両用に定期的にリリースする累積的なパッチの集合であるService Packで入手できるようになる。
■パッチのテストと配布、パッチ適用の管理
CorpSecITグループが、特定の脆弱性が緊急の脅威を示していると判断し、対応するパッチの適用ガイドラインを設定すると、GCSグループに通知される。GCSグループは関連パッチを短時間で検証する(通常、緊急の脅威の場合、わずか数時間)。このテスト・パスはGCSチームのメンバーと社内外の少数のボランティアによって実行される。これは、インストールや安定性の問題がないことを確認するには十分な範囲のユーザーでテストした後、パッチを広範なユーザーに公開するという考え方に基づいている。
GCSは複数の機構を使用してパッチを配布し、適用を実施する。ユーザーは大きく2種類に分類される。MicrosoftのIT組織が管理するドメインに結合されているすべてのPCは、「マネージド・クライアント」と呼ばれる。マネージド・クライアントはSMSを実行する必要があり、企業全体のグループ・ポリシーの影響を受ける。MicrosoftのIT組織が管理するドメインに属さないPCは(例えば、製品開発テスト・チームは独自のドメインを管理することがある)、「アンマネージド・クライアント」と呼ばれる。GCSでは、アンマネージド・クライアントがSMSまたは自動更新クライアントを実行しているかどうか保証できない。
●マネージド・クライアント
パッチ・テストに続いて、GCSはSMSを使用してマネージド・クライアントにパッチを配布する。GCSでは、緊急のパッチをテストし、ユーザーに配布するまでに約72時間を見込んでいる。SMS 2003のパッチ管理機能を利用してクライアント・マシンのパッチを詳しく調べ、パッチのインストールを報告し、未適用のクライアントにパッチを強制インストールするようになった。告知された適用期限が過ぎた段階で、SMSは未適用のクライアントに緊急のパッチを自動インストールする。
また、Microsoftでは、グループ・ポリシーにより、マネージド・クライアントが4時間ごとにWindows Updateで更新があるかどうかを調べるように設定している。更新が利用できる場合はダウンロードされるが、自動的にはインストールされない。サイトからダウンロードされたパッチまたは更新をインストールする作業はユーザーに任される。
●アンマネージド・クライアント
アンマネージド・クライアントに緊急の脆弱性を知らせるため、GCSは脆弱性、対応するパッチへの社内リンク、およびパッチ適用期限に関する情報が入った電子メールを全社に送る。この通知はMicrosoftの社内ネットワークの全ユーザー(マネージド・クライアントおよびアンマネージド・クライアント)にブロードキャストされるため、マネージド・クライアントには余分な通知となる。
CorpSecITグループは毎日数回、1組の社内ツールを使用してMicrosoftの社内ネットワークをスキャンし、パッチが適用されていないクライアントがないか調べる。このツールは既知の脆弱性の攻略をまね、アンマネージド・クライアントのパッチ適用状況を調べることができる。緊急のパッチの実施期限が過ぎると、CorpSecITは未適用のアンマネージド・クライアントに電子メールで最終警告を送る。クライアントは15分以内にもう一度検査され、まだ脆弱であることが見つかると、ネットワークから強制的に除去される(例えば、接続されているネットワーク・ポートを閉じるなど)。
Microsoftでは、製品のService Packリリースの合間に発表されるすべての緊急のパッチ更新について、マネージド・クライアントとアンマネージド・クライアントのパッチ適用状況を監視し続ける。Service Packがリリースされると、CorpSecITグループとGCSグループはService Packが利用できることを告知し、緊急のパッチの場合と同様のプロセスを使用してアップグレード適用を追跡し、実施する(ただし、Service Pack更新の適用期限は通常21日間であり、緊急のパッチの適用期限より長い)。
特殊なケース:切迫した脅威への対応
極端な場合には、緊急の脆弱性が「切迫した脅威」の状態にまで発展することがある。例えば、切迫した脅威は、既存のワームやウイルスが標的とする緊急の脆弱性を表すことがある。
切迫した脅威が見つかると、告知された期限は無効となり、クライアントが自己のシステムに対して、自発的にパッチを適用する期限が新たに決められる。ネットワークに接続されているマネージド・クライアントはSMS経由ですぐに自動アップグレードされる。アンマネージド・クライアントには、15分以内にアップグレードすること、さもなければネットワークから強制切断されることを知らせる電子メールが送られる。
接続されていないユーザーについては、そのマシンが次回ドメインへログオンしようとしたときにログオン・スクリプトがマシンを検査し、パッチがまだ適用されていない場合はすぐにアップグレードを実施する。また、Windows Server 2003にはRAS Quarantine Service(RQS。Quarantineは検疫という意味)と呼ばれる機能が実装されている。RQSは、リモート・クライアント(家庭から企業ネットワークにトンネル処理で接続するクライアントなど)がMicrosoftの社内ネットワークに接続する前に、そのクライアントに対して同様の検査を行う。
さらに踏み込んだ対応策
MicrosoftのCorpSecITグループとGCSグループは、社内ネットワークのクライアントを常に最新パッチが適用された状態にするプロセスをさらに改善するため、以下のことを重点的に行う。
●マネージド・クライアントとアンマネージド・クライアントの分離
Microsoftでは、IPセキュリティ・プロトコル(IPSec)を使用し、社内ネットワークをマネージド・クライアントの安全なグループとアンマネージド・クライアントの別グループに論理的に分離する。この分離によって、アンマネージド・クライアント側からマネージド・クライアントにネットワーク接続はできなくなる。アンマネージド・クライアントは重要ではないイントラネット・サイトにアクセスすることはできても、重要な事業データを格納したシステム(例えば、MicrosoftのSAPシステム)や製品開発ソース・コードにはアクセスできなくなる。
●SMS 2003への一本化
現在、Microsoftでは脆弱性の存在を告知し、マネージド・クライアントに対応するパッチを配布する場合に、Windows UpdateとSMSの両方を使用している。Windows Updateは、接続頻度が少ないリモート・クライアントを最新の更新状態に保つことに役立ち、社内ネットワークに接続されているクライアントには代替方法を提供している。しかし、同じパッチがWindows UpdateとSMSの両方でユーザーに配布されるため、多くのユーザーにとって両機構の稼働は混乱のもとであり、煩わしいだけでなく、ネットワークの効率も低下する。SMS 2003を展開したことにより、Microsoftはマネージド・クライアントに対するWindows Updateの使用を段階的に廃止することになった。ただし、アンマネージド・クライアントへの連絡やマネージド・クライアントへの重複した通知方法として、電子メールは引き続き使用される。Microsoftでは、SMS 2003の向上したソフトウェア配布機能や適用管理機能、そしてクライアント設定検査とRQSがもたらす境界領域セキュリティの向上を組み合わせれば、マネージド・クライアントのパッチ処理にWindows Updateを使用する必要はないと判断した。
●パッチ適用への時間短縮
ウイルスやワームの作成者の技法が巧妙になるにつれ、脆弱性の発見からその脆弱性を狙ったコードの作成までにかかる時間は着実に短くなっている。この短くなる期間に対抗するため、MicrosoftのITグループはパッチのテストと配布の時間を短縮し、社内ネットワーク・ユーザーの自発的パッチ適用がさらに迅速で完全になるよう努力を続けている。Blasterワームの場合、8日間でネットワーク・ユーザーの99%にパッチを適用させることができたが、将来、同様の脅威が発生した場合は、5日間で99%の適用を達成しようとしている。また、パッチのテストと配布にかかる時間を現在の72時間から2004年末までには24〜48時間に減らす予定である。
参考資料
-
セキュリティ情報ページ(マイクロソフト)
Microsoftのセキュリティ情報ページは、セキュリティの最新ニュースとパッチへのリンクを含め、セキュリティに関する情報源として中心的な位置にある。 -
セキュリティ・ツール(マイクロソフト)
パッチ管理に関するMicrosoftの製品、ツール、および手順については、以下を参照のこと -
Microsoftのセキュリティ対策(マイクロソフト)
Microsoftの社内IT方法と実践のケース・スタディについては、以下を参照のこと
参考リンク | ||
Windows
HotFix Briefings(Windows Server Insider) Windows関連の脆弱性情報、ホットフィックス適用による不具合情報など |
||
HotFix管理を始めよう(Windows Server Insider) | ||
HotFix管理の勘所(Windows
Server Insider) 効率的なHotFix管理を実施するための知識とテクニック |
||
Service PackのサポートをはじめたSUS(Windows Server Insider) | ||
Microsoft Software Update Servicesの実力を探る(Windows Server Insider) | ||
Directions
on Microsoft日本語版 本記事は、(株)メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。 |
「Insider's Eye」 |
- 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をインストールしてみる
|
|