特集　Windows Server 2003完全ガイド アーキテクチャを一新した新世代アプリケーション・サーバ 2．動作状態の監視とセキュリティ機能 田口景介 2003/02/27

WWW Service Administration and Monitoring Component

　ワーカー・プロセス分離モードとHTTP.SYSは、信頼性を損ねるような異常動作を構造的に予防する仕組みだが、信頼性の向上を目的としたもう1つのコンポーネントであるWWW Service Administration and Monitoring Componentは、ワーカー・プロセスの異常動作を検出し、修復するための仕組みである。

　このコンポーネントはワーカー・プロセスの状態を逐一監視し、異常を検出すると、ただちにワーカー・プロセスを再起動するなど、正常化に向けたアクションを実行する。もっとも、外部から見て、プロセスが正しく処理されていない、と判断できる基準はそれほど多くはない。WSAが異常として検出できるのは、次の表に示すように、過剰にメモリが確保されたときや、過剰にCPUタイムが消費されたときなど、特定のアプリケーションに依存することなく異常と判断できる状態に限られている。

監視項目	判断	デフォルト値
メモリ	指定値以上にメモリが使用された	仮想メモリを500Mbytes以上消費
CPU	指定した期間に、指定値以上のCPU使用率が継続された	5分間CPU使用率が100％になった
ping	定期的に実行されるpingにプロセスが反応しなかった	30秒おき
プロセス・エラー	指定した期間に、指定回数以上のエラーが発生した	5分間に5回
ヘルス・モニタリング
メモリやCPUの使用状態やpingへの応答状態などを外部から連続的に監視することにより、プロセスに異常が起こったかどうかを判断し、必要な措置（ワーカー・プロセスの再起動など）を行う。

■メモリ・リークの検出例
　以下は、アプリケーションがメモリ・リークを起こしていることを検出する場合の設定例である。メモリの使用量があらかじめ決められた量を超えると、プロセスを再起動する。これをIIS 6.0では、「メモリのリサイクル」と呼んでいる。

メモリのリサイクルの設定

アプリケーション・プールの設定で、メモリを大量に消費した場合にワーカー・プロセスを再起動させるかどうかを設定することができる。メモリ・リークを起こすようなコードが含まれている場合に有効な手段である。

このチェックボックをオンにすると、指定された量の仮想メモリ・サイズになった場合に、プロセスが再起動される。 　 仮想メモリのサイズの制限値。仮想メモリ（これはシステム全体で共通に利用される）の使用サイズがこの値を超えると、プロセスが再起動される。 　 このチェックボックをオンにすると、指定された量のワーカー・プロセス・サイズになった場合に、プロセスが再起動される。 　 ワーカー･プロセスのメモリの制限値。プロセスのメモリ・サイズがこの値を超えると、プロセスが再起動される。

　以下に、メモリのリサイクルの例を示す。ここでは仮想メモリの使用サイズ（タスク マネージャの［ページ ファイル使用量の履歴］参照）がある値を超えると、プロセスがリサイクルされ、使用サイズが元に戻っている。

メモリのリサイクルの例

過剰なメモリ・リークが検出され、リサイクルされた様子。

だんだんメモリの使用量が増えてくる。 　 あらかじめ決められた最大メモリ使用量を超えると、プロセスが停止され、再起動させられる。

■過剰なCPU使用率の検出例
　以下は、CPUの使用率がずっと連続して高くなっていることを検出する場合の設定例である。CPUの使用率がある決められた時間以上、連続して高くなっていると、プロセスを終了させることができる。

CPU監視の設定

ある決められた値以上のCPU使用率が続く場合は、それをログに記録したり、ワーカー・プロセスを終了させたりする。

CPU監視機能を有効にする場合には、これをオンにする。 　 ここで指定された値以上のCPU使用率が続くかどうかを監視する。 　 CPU使用率を監視する期間。この時間以上継続すると、次のアクションを起こす。 　 実行するアクションの指定。［何もしない］ならばイベント・ログに記録を残すだけだが、［シャットダウン］を選ぶとプロセスを終了させることができる。

　以下は、アプリケーションのCPU使用率がずっと連続して高くなった場合の検出例である。CPU使用率がある一定限度を超え、その状態が一定時間以上続くと、イベントログに記録し、ワーカー・プロセスを終了させる。

CPU監視の例

過剰にCPUタイムが消費されているため、リサイクルされた様子。

CPU使用率が100%の状態が長く続く。 　 プロセスが終了させられ、CPU使用率が元に戻る。

　ワーカー・プロセスに異常が検出されると、ただちに終了させられ、別に起動されたワーカー・プロセスが処理を引き継ぐことになるが、ごく短期間のうちにワーカー・プロセスのリサイクルが何度も行われたときは、もはや回復不能と判断され、エラーを多発したアプリケーション・プールは停止される。この「ラピッド・フェール保護（rapid-fail protection。ラピッドは速いという意味）」と呼ばれる機能によって、ヘルス・モニタリング自身がシステムに過大な負荷をかけないように配慮されている。

ラピッド・フェール保護の設定

短い時間内に何度もワーカー･プロセスのリサイクルが行われた場合は、アプリケーション・プールを停止し、それ以上システムに負担をかけないようにする。

ラピッド・フェール保護を有効にするには、これをオンにする。 　 回数の指定。指定された時間以内にこの回数以上リサイクルが発生すると、アプリケーション・プールを停止する。 　 時間の指定。この時間以内に連続してリサイクルが発生すると、アプリケーション・プールを停止する。

IIS 6.0のセキュリティ機能

　IIS 5.0が犯した最も単純で、最大の失敗は、Windows OSのインストール時に無条件でインストールされてしまうようになっていたことだろう。その結果、管理されていない状態のIISが大量に稼働し、ワームの温床になってしまった。

　そういった経験があっては当然のことだが、Windows Server 2003ではIISがデフォルトでインストールされることはなくなった（Web Server Editionは除く）。これで恐らく、数字上のシェアを落とすことになるだろうが、IISを必要としない環境にIISのようなサービスがインストールされ、あまつさえデフォルトで自動起動されるなど、そちらの方が不自然だったのだ。これで、ワームの温床になってしまうような、管理意識の低いサイトが激減することは間違いない。

■ロックダウン・ツール
　また、IIS 6.0を明示的にインストールしても、以前のようにいきなり全機能が有効になった状態で稼働し始めることはない。IIS 6.0には、IIS 4.0／5.0用に公開されていたロックダウン・ツール（IISの不要な機能や当面使わない機能などを選択的に無効にするツール）が「Webサービス拡張」という名前でIISに組み込まれ、デフォルトでは静的なWebページを配信することしかできない状態に設定されている。asp.netとFrontPage Server Extensionだけは、IISのインストール時に有効化できるが、それ以外のISAPIエクステンションやCGI、それにASPなど、これまで数々のセキュリティホールを生み出してきた拡張インターフェイスは、いずれも明示的に有効化しなければ機能しない。

Webサービス拡張

ここで各種機能をロックダウンできる。ASP.NETとFrontPage Extension 2002はIISのインストール時に可否を設定できるが、それ以外は必ず禁止された状態でインストールされる。

Webサーバの機能は、この［Webサービス拡張（Web service extensions）］で制御する。デフォルトで有効化する機能、無効化する機能を明示的に選択する。 　 デフォルトではこの2つのみが有効になっており、そのほかのものは管理者が明示的に許可しない限り、有効にはならない。 　 許可と禁止はここで制御する。

　ただし、このロックダウン・ツールには、多少物足りないところもある。例えば、ISAPIエクステンションにしろ、CGIにしろ、サイト全体で許可／禁止の設定をすることしかできず、個々のISAPIエクステンションを個別に許可することはできないのである。個別にはできなくても、せめてアプリケーション・プール単位で設定できれば、より安心して利用できたであろうことを考えると残念だ。

■Network Serviceアカウント
　従来IISのようなサービスは、「Local System」と呼ばれる特殊なアカウントで実行されるのが一般的であったが、Local SystemはAdministratorsグループに所属する強力なアカウントであるため、セキュリティホールを突かれたとき、被害が深刻化しやすいという点が問題視されていた。そこで、Windows Server 2003では、より制限されたシステム・アカウントである「Local Service」アカウントと「Network Service」アカウントが新設され、これをサービスの実行ユーザーとして指定できるようになっている。両アカウントはUsersグループのメンバーと同等の権利しか備えていないので、万一システムへの侵入を許してしまったとしても、被害を最小限に留めておけるはずだ。

　IIS 6.0では、このNetwork Serviceアカウントがワーカー・プロセスの実行ユーザーとして利用される。ワーカー・プロセスによって起動されるアプリケーションは、やはりNetwork Serviceアカウントのセキュリティ・コンテキストで実行されるため、ごく限定的なユーザー権限の元で処理されることになる。ただし、Network Serviceアカウントのセキュリティ・コンテキストでは、リモート・リソースへのアクセスにコンピュータ・アカウントが利用されるため、特定のユーザーアカウントが要求されるリソースへのアクセスが拒否されてしまう場合があり得る。こうしたときは、指定したセキュリティ・アカウントで実行するよう設定を変更することも可能だ。このセキュリティ・アカウントの情報は、アプリケーション・プールごとに独立して管理されるため、必要ならばアプリケーションごとに個別のセキュリティ・アカウントを指定することもできる。

セキュリティ・アカウント

ワーカー・プロセスのセキュリティ・アカウントには、Usersグループと同等のアクセス権を持つNetwork Serviceが使われるが、アプリケーション・プールごとに任意のアカウントを指定することも可能。

システムに組み込まれているアカウントを使用する場合はこちらを選択する。 　 デフォルトでは「Network Service」というアカウントが使用されている。 　 そのほかのアカウントを利用する場合はこちらを選択する。

　このようにIIS 6.0のセキュリティモデルは、IIS 5.0から大きく変更されているため、十分に理解しておく必要がある。例えば、IIS 5.0の環境では、ASPならば「IUSR_＜コンピュータ名＞」が（匿名アクセス時）、ASP.NETならば「ASPNET」がそれぞれ実行ユーザーとして利用されていたが、IIS 6.0ではセキュリティ・コンテキストの管理がIISと統合されているため、どちらもアプリケーション・プールで指定したセキュリティ・アカウント、つまりデフォルトではNetwork Serviceアカウントで実行されるように変更されている。すると、いままではASPNETアカウントにアクセス権を与えておけば動作したアプリケーションが、IIS 6.0上では動作しなくなる、ということが起こりうるのである。

INDEX
	［特集］Windows .NET Server 2003完全ガイド
	IIS 6.0の機能の詳細
	1．信頼性を向上させるアプリケーション・プール
	2．動作状態の監視とセキュリティ機能
	3．IIS 6.0の管理
	4．そのほかの機能

　

Windows Server 2003完全ガイド

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）