IIS Insider

「アクセス権をどのように設定する必要があるか」という質問の答えは、「必要なアクセス権を考慮し、最小限のアクセス権を設定する」ということです。静的なコンテンツおよびスクリプトを配信するためには、IIS では NTFS 読み取りアクセス権のみが必要となります。そのほか追加するアクセス権はすべて、ユーザーのビジネス上の要件によって異なります。

上記のリストは、FrontPage 2002 をインストールした IIS 6 サーバーのクリーン インストールの場合のように見えます。サービスまたは製品を追加する際は常に、必要なアクセス権が、また時によってはユーザーおよびグループがサーバー上で変更されることに注意してください。まず、FrontPage Server Extensions がインストールされていない Windows Server 2003 上の IIS 6 の既定のインストールで wwwroot に割り当てられたアクセス権を確認してみましょう。

Administrators - Full Control
System - Full Control
IIS_WPG - List Folder Content, Read & Execute, Read
Users - List Folder Content, Read & Execute, Read
Internet Guest Account - Deny Write

私が例としてあげた IIS 6 の既定のアクセス権とあなたの IIS のアクセス権の相違点は、あなたのサーバーには、FrontPage Server Extensions (FPSE) 2002 がインストールされているという点です。お分かりのように、そのアクセス権は、まったく異なります。FPSE には以下のアクセス権が追加されます。

Network -  List Folder Contents
Network Service - List Folder Contents
Interactive – List Folder Contents
OWS_<suffix> - List and special permissions according to role.
Internet Guest Account – List Folder Contents

これらの設定にいくつかの重複した設定がされているというのは間違っていません。最も大きな変更の 1 つは、Internet Guest Account のアクセス権の変更です。

書き込みの拒否が削除され、フォルダの内容の一覧の表示が追加されます。そのため、匿名の Web ユーザーはネットワークおよびインタラクティブ グループと同じアクセス権を所有することになります。IUSR アカウントは、常にネットワークまたはインタラクティブ グループのいずれかのメンバの一部となり、IUSR アカウントの一覧は、正確には必要ではありません。また、ネットワーク サービス グループは IIS_WPG のメンバとなるため、それは特に呼び出されません。

FPSE がアクセス権を使用する方法は、わかりにくいかも知れません。FPSE は、ユーザーが最初にユーザーアカウントで Web サイトに認証され、NTFS のみを介して匿名アクセスを許可する、ほかのコンテンツを参照する際に起こる問題を回避することを意図しています。この場合、コンテンツの読み取りを許可したい場合に、そのユーザーのアクセスを拒否することができます。幸い、Windows Server 2003 では、ビルトインネットワークおよびインタラクティブグループではなく、ユーザーグループのアクセス権を検索するようにFSPE を設定することができます。詳細は、http://www.microsoft.com/technet/prodtechnol/sppt/sharepnt/proddocs/admindoc/owsj03.mspx (英語) および http://www.microsoft.com/serviceproviders/busresources/bizreswp.mspx (英語) をご覧ください。

最後に、ASPNet ユーザーは、既定で IIS 6 サーバーには存在せず、ASP.net をインストールすると呼び出されます。ASPNet ユーザーは、IIS 5 の互換性のためにワーカー プロセス分離モードで ASP.net を実行しない限り使用されません。それ以外の場合、アプリケーションは既定でネットワーク サービス アカウントで実行されます。ASP.net および IIS 6 に関する詳細は、http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx にて IIS 6 リソース ガイド (英語) をご覧ください。

アプリケーション プールを作成する際、IIS 6 が Web サイトのコンテンツおよびそのアプリケーション プールに割り当てられるファイルおよびフォルダを配信するためのワーカー プロセスを作成するように指定します。アプリケーション プールを構成し、拡張性が得られる場合がある、単一のワーカー プロセスではなく、複数のワーカー プロセスを開始することができます。これは、Web ガーデンと呼ばれる機能で、"Web ファーム" の概念の小規模なバージョンです。同一のコンテンツを配信する複数のコンピュータを配置のではなく、同じコンテンツを配信する複数のプロセスを処理する単一のコンピュータを使用するものです。

IIS 6 アプリケーションプールを Web ガーデンとして構成する場合、アプリケーション プール プロパティの [パフォーマンス] タブの [最大ワーカープロセス数] の設定で、単に複数のワーカー プロセスを指定します。1 以上の値を設定すると、それぞれのリクエストにより、指定した最大数に達するまでワーカー プロセスの新たなインスタンスが開始されます。その後のリクエストがラウンド ロビン方式で、ワーカー プロセスに送信されます。

Web ガーデンは、何らかの方法でリソースが制限されているアプリケーションを使用している状況で、非常に役立ちます。たとえば、データベースへの接続が遅い場合、複数のワーカー プロセスを使用して、ユーザーへのスループットを増加させ、次にデータベースへの接続の数を増加させることができます。

Web ガーデンは非常に有益な場合がありますが、それぞれのワーカー プロセスのセッション情報は一意であることにご注意ください。リクエストは、ラウンド ロビン方式でアプリケーション プール ワーカー プロセスにルートされるため、Web ガーデンは、セッション情報がプロセスに保存されるアプリケーションでは役に立たない可能性があります。

同じアプリケーションを実行する複数のワーカープロセスを使用すると、リソースの競合が起こる場合があります。たとえば、ワーカー プロセスが、ログファイルへ情報を記録しようとする場合、または、リソースを使用する場合、複数の、同時アクセス向けに設計されていない場合の使用では、リソースの競合が起こる場合があります。

これらの競合が起こらない場合、Web ガーデンがあなたが正に必要としている機能で、真の利益となる可能性があります。

これは一見、統合 Windows 認証が資格情報を記憶しないという問題のように見えますが、そうではありません。サイトまたはサーバーのセキュリティ保護におけるこの問題の要点は、機能およびセキュリティの間のバランスの問題があります。基本認証は、ローカルログオン タイプ (「対話的な」ログオンとも呼ばれています) となります。この種類の資格情報は別のサーバーに委任することができます。そのため、リモート コンピュータへのアクセスは基本認証によって取得された資格情報によって実行することができます。これと同じことが、SQL サーバーへのアクセスにも当てはまります。基本認証を使用して、クライアントに認証を行い、SQL サーバーが SQL 認証を使用するように構成した資格情報を転送することができます。しかし、統合 Windows を使用して IIS サーバーに認証を行う場合、その結果、"ネットワーク" ログオンとよばれるログオンの種類となります。この種のログオンは、基本認証よりもはるかにセキュアですが、イントラネットで Kerberos を使用していない限り、資格情報をほかのサーバーに転送することができません。Kerberos が使用されている場合、(適切に構成されている場合) ユーザーの資格情報をフォレスト内で委任することができます。(マイクロソフト サポート技術情報 326089 をご覧ください。)

使用される認証の種類に関わらず、リモート コンテンツにアクセスするための便利で信頼性の高い方法を使用するために、リモート コンテンツにアクセスするための仮想ディレクトリを構成した場合、IIS サーバーおよびリモート サーバーの両方で有効なユーザー名とパスワードを入力するかどうかを確認するメッセージが表示されます。次に、仮想ディレクトリにアクセスする際に、そのリクエストはその特定のユーザーに変更されます。次に、ユーザーを認証する方法に関わらず、リモート コンテンツにアクセスできるようになります。

Kerberos を使用することができない場合、マップされたドライブよりも標準の仮想ディレクトリを使用して、アプリケーションを変更することをお勧めします。これにより、リモート クライアントへ安定したアクセスをすることができます。また、マップされたドライブは、そのマッピングを作成するユーザー プロファイルの一部であるため、使用することを推奨しません。ほかのユーザーが IIS サーバーにログオンする場合、マップされたドライブは存在せず、アプリケーションへの接続が切断されます。