Insider's Eye Windows .NET Serverを支えるIIS 6.0（2） ――　再設計で信頼性とセキュリティが向上　――
Michael Cherry 2002/07/26 Copyright(C) 2002, Redmond Communications Inc. and Mediaselect Inc.

---

新しいIISアーキテクチャ

　MicrosoftはIIS 6.0のコンポーネント化を慎重に進め、アプリケーションレベルのコードの信頼性およびパフォーマンスの改善と、Webサーバのコアタスク（HTTPリクエストの処理）のパフォーマンス向上を図った。IIS 5.0は比較的モノリシックな（一体化された）プログラムで、大多数のHTTPリクエストと管理プロセスをWebサーバのコンポーネント内で処理する仕組みだった（新アーキテクチャについては次の図を参照）。

IIS6のアーキテクチャとリクエスト処理

IIS 6.0はカーネルモードでHTTPリクエストを受け取り、それらをアプリケーションの隔離されたワーカープロセスに渡す。

カーネルモードのHTTP Listener（図下のHTTP.sys）にHTTPリクエストが届くと、HTTP Listenerはまずリクエストの有効性をチェックする。リクエストが無効なら、要求者にHTTPエラーを返す。リクエストが有効なら、HTTP.sysはそのリクエストがキャッシュで処理できるかどうかを確認する。レスポンスがキャッシュにあれば、HTTP.sysはそれをただちに送り、なければリクエストをワーカープロセス（アプリケーション）向けの個別のリクエストキューに置く。

もし必要なワーカープロセスがリクエストキューをリスニングしていなければ、HTTP.sysはWeb Administration Service（WAS）にシグナルを送り、メタベースにXML形式で格納されたコンフィギュレーション情報に基づいて、ワーカープロセスの起動とコンフィギュレーションを行うよう命じる。

1つのワーカープロセス、あるいはワーカープロセスのグループ（Webガーデンと呼ばれる）がすでに起動中で、リクエストキューに接続されている場合、ワーカープロセスはリクエストをキューから取り出し、任意のISAPIフィルタもしくはISAPIエクステンションとWebアプリケーションコードで処理し、レスポンスをHTTP.sysと要求者に返す。

WASはまた、ワーカープロセスの状態を監視し、プロセスが応答しなかったり、稼働時間や処理するリクエスト数などが限界値を超えたりした場合、HTTP Listenerと調整してリクエストをキューにホールドしながら、ワーカープロセスを停止、再起動する。

　IIS 6.0の主要なサービスとプロセスは以下の通り。

■HTTP Listener
　IIS 6.0 HTTPドライバ（HTTP.sys）はHTTPリクエスト（Webページや画像のリクエストなど）を受け取り、しかるべきWebアプリケーションに渡す。HTTP.sysはカーネルモード・ドライバだ。つまり、Windows .NET Serverエグゼクティブ（メモリ、I／O、オブジェクトマネジャーなど、カーネル・コンポーネントの集合）の一部として動作する。

　カーネルモードで動作することで、HTTP.sysは隔離され、パフォーマンスが向上し、ユーザーが記述したリクエスト処理用アプリケーションコードのエラーから守られる。

　HTTPリクエストを処理するサービスを別に持つメリットの1つは、IISから切り離すことでほかのOSサービスやサーバ・アプリケーションから利用しやすくなることだ。

■ワーカープロセス
　IIS 6.0はWebアプリケーション・プールごとに個別の“ワーカー”プロセス（W3WP.EXE）を起動して、ユーザー記述のアプリケーションコードをさらに隔離する。例えば、2つの異なるASP.NET Webアプリケーションが動作している場合、両者はそれぞれ独自にASP.NETエンジン（Internet Server Application Programming Interface［ISAPI］エクステンション）と、独自のCommon Language Runtime（CLR）、ユーザー記述の任意のアプリケーションコードで構成されるワーカープロセスを備えている。

　IIS 5.0ではアプリケーションコードをメインのIISプロセス（INETINFO.EXE）と一緒に実行したり、アプリケーションの一部を別のプロセス（DLLHOST.EXE）に分離したりすることは可能だが、Webアプリケーション同士を完全に隔離することはできなかった。

　IIS 6.0では、特定のアプリケーション専用に複数のワーカープロセスのグループも作成できる。こうした“Webガーデン”の各プロセスは、個別のプロセッサで実行でき、アプリケーションはマルチプロセッサ・サーバの能力をフルに活用することができる。

　IIS 6.0サーバ上のアプリケーションやWebサイトを独自のプロセスでホスティングすれば、サイト管理者はアプリケーションに割り当てられたリソースを細かくコントロールすることができる。また、なんらかの問題があって不具合を起こしたアプリケーションやWebサイトを再起動する場合も、ほかのワーカープロセスに影響が及ぶことはない。

■Web Administration Service
　IIS 6.0には、サーバとワーカープロセスのコンフィギュレーションに用いる新しいWeb Administration Service（WAS）が用意されている。WASはコンフィギュレーションを管理するほか、Webアプリケーションに対するリクエストが発生するまで、ワーカープロセスを起動しないように管理し、リソースの消費を抑える。WASはワーカープロセスの状態を監視して、メモリリークなどの問題を起こした場合、ユーザーに影響を及ぼさないよう自動的に再起動させる。

■XMLメタベース
　Webサイトとアプリケーションのコンフィギュレーション情報を格納するメタベースは、IIS 6.0ではXMLファイル形式を採用している。従来のIISメタベースは、プロプライエタリな（独自の）バイナリ形式を使用していた。管理者やほかのプログラム（Application Centerなど）にとって、XML形式の方がメタベースの変更やバージョンの管理、バックアップ、リストア、メタベースのエクスポート（追加されたIISサーバのコンフィギュレーションや導入のため）が容易になる。

　パフォーマンスや信頼性の向上を実現するために、（複数台のWebサーバを使う）冗長なWebサーバ“ファーム”を利用している組織にとって、この点は特に重要だ。XMLメタベースファイルは、ファームの全メンバーが簡単に複製できる。

■IIS Admin Service
　IIS 6.0では、Webサーバとワーカープロセスに対するIIS Admin Service（INETINFO.EXE）の重要性は低い。しかし、それでもMicrosoft Management Console（MMC）やコマンドラインスクリプト、サードパーティ製のツールなどで、IISサーバの管理を容易にする一連のIIS Administration Base Objects（ABO）を用意している。このサービスは、File Transfer Protocol（FTP）、Simple Mail Transfer Protocol（SMTP）、ニュースグループのNetwork News Transfer Protocol（NNTP）の各サービスもホストする。

セキュリティの強化

　IISの安全性に対する懸念を払拭するため、Microsoftは“Trustworthy Computing”（Directions on Microsoft日本語版 2002年3月15日号「セキュリティ開発のためWindows .NET Serverの開発を一時中断」を参照）の一環としてコードを見直すとともに、デフォルトでサーバをロックダウンし、IISを（やはりデフォルトで）特権の少ないアカウントとして実行するなど、セキュリティ強化を図るいくつかの処置を講じた。

　サーバのロックダウンは、管理者が必ず認識する最大の変更点だ。従来、IISのデフォルトの設定では、ASPやインターネット・プリンティングなどのサービスは、たとえユーザーが使用しない可能性があってもオンになっていた。おかげでこれらのサービスは発見しやすく、簡単に選択できたが、管理者の不注意でオンのままに放置しておくと、邪悪なコードの侵入を許す危険性があった。

　新方式では、デフォルトでIISをWindows .NET Serverにインストールしない。インストール時には機能を“ロックダウン”、つまりオフにして、管理者がASPやASP.NET、FrontPage Server Extensionsなどのサービスを追加するまでは、サーバが比較的安全な静的Webページしか提供できないようにしている。

　管理者はWeb Services Extension（旧称Lockdown Wizard）を用いて、簡単にIIS機能を有効にできる（概要については次の画面を参照）。

Web Services Extension

IIS Web Services Extension（Lockdown Wizard）では、IIS 6.0サーバの機能を選択的に有効にすることができる。例えば、WebサイトでASP.NETや .NET開発プラットフォームをベースにページを構築、提供する場合、管理者はASP.NETなどのプログラミング・インターフェースを有効にしなければならない。

　セキュリティ関連のもう1つの大きな変更は、個々のIISワーカープロセスを“NetworkService”として動作させることだ。NetworkServiceは新たに設定された特権の非常に少ないビルトイン・アカウントで、特権が少ないため、セキュリティ侵犯が発生した場合の影響を最小限に抑制できる。例えば、不正侵入したハッカーがサーバの管理特権を入手するのを防止することが可能だ。

　管理者はIISの機能を選択的にオンにしなければならず、またIISは最低限の特権で動作するため、脆弱性があらわになる可能性は大幅に減少する。

互換性と成熟の問題

　IIS 6.0の再設計によって生じる最大の欠点は、アーキテクチャの変更が既存アプリケーションに打撃を与える可能性があることだ。例えば、2002年2月にリリースされたばかりのASP.NET向けアプリケーションさえ影響を受けかねない。製品に占める新規コードの量から、安定性に関する疑問も浮上している。

INDEX
	Insider's Eye
	Windows .NET Serverを支えるIIS 6.0（1）
	Windows .NET Serverを支えるIIS 6.0（2）
	Windows .NET Serverを支えるIIS 6.0（3）

　

「Insider's Eye」

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