IIS Insider

IIS 6 では、[CPU 監視を有効にする] (下記参照) の機能を使用し、CPU が使用するアプリケーション プールを制限することができます。

[何もしない] に設定した場合、アプリケーション プールの CPU 使用率が、指定したしきい値を超えた場合、イベント ビューア メッセージが記録されます。[シャットダウン] に設定した場合、アプリケーション プールは、[CPU の使用数を次の時間ごとに更新する] に指定された時間シャットダウンされます。

これは、限られた状況下では、役立つ可能性がありますが、Windows System Resource Manager (WSRM) (これは Windows Server 2003 Enterprise Edition で利用可能です) を使用して、適切に CPU 使用率を抑えることができます。この機能により、すべてのアプリケーションの CPU の使用率をあらかじめ設定した量に制限できるだけでなく、特定のユーザーおよびグループ向けにこれらの制限のスケジュールを設定し、割り当てることができます。

WSRM の [実行プロセスの追加フォーム] にて W3WP.exe (使用しているアプリケーション プール) のインスタンスなど、実行プロセスを指定することができます。

このようにして、”プロセス一致条件” と呼ばれる規則を定義します。この規則は、WSRM を処理するものを選択する際に使用されます。次に、"リソース割り当てのポリシー” を作成し、”プロセス一致条件” で識別したプロセスに指定した CPU の制限を実行します。

WSRM の機能に関する詳細は、http://www.microsoft.com/japan/windowsserver2003/technologies/management/wsrm/default.mspx をご覧ください。

ユーザーが、サーバーに対して認証をするために使用する Windows のアカウントを持っている場合、アクセスは NTFS を介し、ファイル サーバーを制限する方法と同様に制御されます。これには、すべてのユーザー、ユーザー、認証されたユーザー、ドメイン ユーザー、ネットワーク グループなどの大きなグループで慎重に使用することが必要となります。アクセス許可にこのようなまとまりを使用する場合は常に、匿名ユーザーを含む、認証を行うほとんどのユーザーにアクセス権を割り当てることになります。

まず決める必要があるのは、それぞれのサイトで一意の匿名ユーザーを必要とするかどうかです。これにより、Web サイト間で、最も高いレベルの分離を行うことができるようになりますが、これには管理がより難しくなります。一意の匿名ユーザーでは、１ つの Web サイトで、匿名でコンテンツを参照することが許可されたユーザーが直接、(匿名アカウントのセキュリティ コンテキストで) または間接的に、別の Web サイト上のコンテンツにアクセスできないようしてください。

グループを使用して相互に分離する必要がある Web サイトのアクセス権を管理することを推奨します。Web サイト向けにユーザーの ”クラス” のグループを作成し、そのグループにユーザーを割り当てます。この方法は、ローカル サーバーのアクセス権の管理の最善策の １ つで、単純にグループ メンバを管理することによって、ファイルへのアクセス権を持つユーザーの変更がすることを容易になります。たとえば、Web サイト A ブラウザというグループを作成し、それに静的コンテンツとスクリプトには「読み取り」アクセス権、.dll と .exe プログラムには「読み取りおよび実行」のアクセス権をそれぞれ割り当てます。次に、このグループに全体の Web コンテンツのディレクトリ ツリーへのアクセス権を「書き込み拒否」に設定し、匿名ユーザーが Web サーバーへの書き込みができないようにすることを検討してください。これにより、ユーザー、または認証されたユーザー (両方とも IUSR_<サーバー名> アカウントを含みます) などのグループに「書き込み」アクセス権が割り当てられた場合にもコンピュータが保護されます。もちろん、これにより、Web アプリケーションが Access データベースなどの、匿名ユーザー アカウントを使用して、サーバーに対しコンテンツの書き込みを試行するロケーションへの書き込みができなくなります。したがって、その推奨策を実行した場合、このようなロケーションに「書き込み」アクセス権を明示的に割り当て、「書き込み拒否」アクセス権を削除する必要があります。信頼されないユーザーがアクセスできるロケーションには、くれぐれも「実行」および「書き込み」アクセス権を割り当てないようにしてください。

必要とするセキュリティの程度によって、それぞれの Web サイトに、一意の匿名のユーザー アカウントを作成する必要がある場合があります。Web サイト A ブラウザ グループへの匿名アクセスに使用するアカウントを設定すると、サイトを匿名アクセスのための適切な設定が行われます。この方法でグループのセキュリティを保護するメリットの １ つに、認証されたアカウントがあり、匿名ユーザーのように処理する必要がある場合、Web サイト A ブラウザ グループに追加し、「匿名と同様」にすることができます。

次に、Web サイト A 作成者 グループを作成し、Web サイトに公開する必要があるグループにユーザーを設定します。そのグループに Web サイトのディレクトリ ツリー全体への「書き込み」アクセス権を割り当てます。

最後に、アクセス権を設定するためにローカル グループではなく、ドメイン ローカル グループを使用することを検討する必要があります。この第一の理由は、ローカル ユーザーおよびグループは、他のサーバーにコピーすることができないためです。クリーン インストールまたは Web サイトを移動し、新しいオペレーティング システムにアップグレードする必要がある場合、ユーザー、ローカル グループ、アクセス権を完全に再設定する必要があります。サーバーによっては、このタスクは複雑でエラーが発生する場合があります。ドメイン グループおよびユーザー アカウントに割り当てられたアクセス権が設定されたファイルをコピーする場合、新しいサーバーでは、ドメインまたは信頼されるドメインのメンバであると仮定してこれらのアクセス権が確認されます。これは、障害復旧でも問題となる可能性があります。匿名ユーザーをドメイン ベースのアカウントとすることは、セキュリティの立場からは推奨されないため、これもまた、機能とセキュリティのトレードオフであるといえます。しかし、信頼できるイントラネットまたは DMZ または Web ファームの独立したフォレストなど、設定によっては、ドメイン ベースの匿名ユーザーは、容認可能なリスクであるといえます。

これらの推奨策によって、Web サーバーを管理するに際、サイトのユーザーが他のサイトの特権をもたないようにするためのフレキシビリティが得られます。IIS 6.0 のセキュリティをさらに向上させるためには、一意のアプリケーション プールの ID が必要となる場合があります。高いレベルの分離を行うためには、以下のホワイト ペーパーをご覧ください。

Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0 (英語)
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/appisoa.mspx

IISReset は、IIS 4 で必要とされていたため、net コマンドを使用する IIS 関連のサービスを停止または開始するための別コマンドとして IIS 5 で最初に使用可能となりました。IISReset は、一般的にほとんどの場合で、IIS 5 を再起動するための確実な方法となります。マイクロソフト サポート技術情報 286196 に次のように記載されています。「IISReset コマンド ライン ツールは、サービスの通常のシャットダウンが行われるまで待ってからサービスを再起動します。IISAdmin サービスに依存しているサービスは多数あるため、シャットダウンがタイミングよく発生しないことがあります。」IIS がタイムアウトの前にシャットダウンされなかった場合、そのサービスは終了し、行ったメタベースへの変更が書き込まれない場合があります。そのため、IIS の構成は以前の構成に戻る可能性があります。これは、IIS がハングした場合、またはメタベースが非常に大きな場合にのみ起こります。

その場合の解決策は、/NOFORCE コマンドおよび /TIMEOUT:xxx コマンド (xxx は、IISRESET がリセットの際、待機する秒数を示します。) とともに IISRESET を発行することです。

IIS 6 で IISRESET を使用するのは、ほとんど必要とないことにご注意ください。ほとんどの場合、アプリケーション プールをリサイクルし、同じ結果をアーカイブすることができます。リサイクルは、IISRESET よりも強力で、サーバーで、FTP、SMTP、NNTP などのすべてのアプリケーションがシャットダウンされます。そのため、いつも IISRESET を使用してアプリケーションを再起動している場合、その方法ではなく、スクリプトを再度記述し、アプリケーション プールのリサイクルを行う方法を取るようにしてください。

IIS 6 Resource Guide の IISRESET に関する詳細は、以下のマイクロソフト サポート技術情報をご覧ください。