アプリケーション プール ID
公開日: 2009 年 3 月 24 日 (作業者: thomad (英語))
更新日: 2009 年 5 月 27 日 (作業者: thomad (英語))
はじめに
IIS は、Windows Server 2008 Service Pack 2 および Windows Vista Service Pack 2 の新しいセキュリティ機能を導入しています。 この機能は、アプリケーション プール ID と呼ばれます。 アプリケーション プール ID を使用すると、ドメイン アカウントまたはローカル アカウントを作成、管理することなく、一意のアカウントの下でアプリケーション プールを実行することができます。 アプリケーション プール アカウントの名前は、アプリケーション プールの名前に対応します。 次の図は、DefaultAppPool という ID で実行されている IIS ワーカー プロセス (w3wp.exe) を示すものです。
.png "Ee886292.appPoolid2(ja-jp,TechNet.10).png")
アプリケーション プール ID アカウント
既定では、IIS 6 および IIS 7 のワーカー プロセスは NETWORKSERVICE アカウントによって実行されます。 NETWORKSERVICE は組み込みの Windows ID です。 この ID にはパスワードが不要であり、ユーザー権限のみ、つまり、比較的低い権限が付与されています。 権限が低いアカウントで実行すると、悪意のあるユーザーがソフトウェアの不具合を利用してシステム全体を支配することができなくなるため、セキュリティ上の効果があります。
ただし、時の経過と共に NETWORKSERVICE として実行を開始する Windows システム サービスが増大し、NETWORKSERVICE として実行されたサービスが、同じ ID で実行されている他のサービスに干渉する可能性が生じるという問題があります。 IIS ワーカー プロセスは既定でサードパーティのコード (クラシック ASP、ASP.NET、PHP コード) を実行することから、IIS ワーカー プロセスを他の Windows システム サービスから分離し、IIS ワーカー プロセスを一意の ID の下で実行するほうが良いとの判断が下されました。Windows オペレーティング システムには、IIS が各アプリケーション プールに一意の ID を作成できるように「仮想アカウント」と呼ばれる機能が用意されています。 仮想アカウントの詳細については、サービス アカウントに関するステップバイステップ ガイド (英語)を参照してください。
新しいアプリケーション プールが作成されるたびに、IIS 管理プロセスにより、アプリケーション プール自体の名前を表すセキュリティ識別子 (SID) が作成されます。つまり、"MyNewAppPool" という名前のアプリケーション プールを作成すると、Windows セキュリティ システムには "MyNewAppPool" という名前のセキュリティ識別子が作成されるということです。 これ以降は、この ID を使用してリソースをセキュリティ保護することができます。 ただし、この ID は実在のユーザー アカウントではなく、Windows のユーザー管理コンソールにユーザーとして表示されません。
Windows エクスプローラーでファイルを選択し、"DefaultAppPool" という ID をアクセス制御リスト (ACL) に追加することによって、このことを試すことができます。
- Windows エクスプローラーを開きます。
- ファイルまたはディレクトリを選択します。
- ファイルを右クリックし、[プロパティ] を選択します。
- [セキュリティ] タブを選択します。
- [編集] をクリックし、[追加] ボタンをクリックします。
- [場所] ボタンをクリックし、お使いのコンピューターを選択していることを確認します。
- [選択するオブジェクト名を入力してください] テキスト ボックスに「IIS AppPool\DefaultAppPool」と入力します。
- [名前の確認] ボタンをクリックし、[OK] をクリックします。
これで、選択したファイルまたはディレクトリも "DefaultAppPool" ID によるアクセスを許可するようになります。
.png "Ee886292.aclui(ja-jp,TechNet.10).png")
この設定は、コマンド ラインで ICACLS ツールを使用して行うことができます。 次の例では、"DefaultAppPool" ID にフル アクセスが付与されます。
ICACLS test.txt /grant "IIS AppPool\DefaultAppPool":F
Windows 7 および Windows Server 2008 R2 では、既定でこのセキュリティ識別子、つまりアプリケーション プール ID でアプリケーション プールを実行するように設定されています。 この機能を実装するため、"AppPoolIdentity" という名前の新しい ID の種類が導入されました。 ID の種類として "AppPoolIdentity" が選択されている場合 (Windows 7 および Windows Server 2008 R2 では既定の選択)、IIS はアプリケーション プール ID でワーカー プロセスを実行します。 その他すべての ID の種類については、プロセスのアクセス トークンにセキュリティ識別子が挿入されるだけです。 識別子が挿入される場合、コンテンツへのアクセスをアプリケーション プール ID に対する ACL によって制御することもできますが、トークンの所有者は一意でない可能性があります。 記事「IIS 7 の新機能 - アプリケーション プールの分離 (英語)」では、この概念が説明されています。
ネットワークへのアクセス
ドメイン環境で NETWORKSERVICE アカウントを使用することには大きなメリットがあります。NETWORKSERVICE で実行されるワーカー プロセスはコンピューター アカウントとしてネットワークにアクセスします。 コンピューター アカウントはコンピューターがドメインに参加すると生成され、 次のような形式で表されます。
<domainname>\<machinename>$
次に例を示します。
mydomain\machine1$
この方法の優れた点は、ファイル共有や SQL Server データベースなどのネットワーク リソースを ACL で保護し、このコンピューター アカウントに対してアクセスを許可できることです。
アプリケーション プール ID の場合
アプリケーション プール ID の場合も、コンピューター アカウントを使用してネットワーク リソースにアクセスすることができます。 変更を加える必要はありません。
アプリケーション プール ID の互換性の問題
指針となるドキュメント
アプリケーション プール ID の互換性に関する最大の問題は、IIS 6.0 および IIS 7.0 の DefaultAppPool の既定 ID である NETWORKSERVICE を、指針となるドキュメントで ACL リソースに対する推奨事項として明示的に提示していることです。 IIS 7.5 で実行する場合はユーザーのスクリプトを変更し、ACL に "IIS AppPool\DefaultAppPool" が設定されるようにする必要があります (この方法については、上の例を参照してください)。
ユーザー プロファイル
IIS では Windows ユーザー プロファイルの読み込みを行いませんが、特定のアプリケーションでは、たとえば一時的なデータの格納場所などとして利用する可能性があります。 このようなアプリケーションの例に SQL Express があります。 ただし、一時データをプロファイル ディレクトリまたはレジストリ ハイブに格納するには、ユーザー プロファイルを作成する必要があります。 従来の方法では、NETWORKSERVICE アカウント用のユーザー プロファイルがシステムによって作成され、常に使用可能でしたが、 一意のアプリケーション プール ID への切り替えを行う場合は、システムによってユーザー プロファイルは作成されません。 標準のアプリケーション プール (DefaultAppPool および Classic .NET AppPool) のみがディスクにユーザー プロファイルを保持しています。管理者が新たなアプリケーション プールを作成する場合、ユーザー プロファイルは作成されません。
[loadUserProfile] を "true" に設定することによって、ユーザー プロファイルを読み込むように IIS アプリケーション プールを構成できます。
まとめ
アプリケーション プール ID は、Windows Server 2008、Windows Vista、Windows 7 および Windows Server 2008 R2 向けに新たに導入された効果的な分離機能です。 IIS アプリケーション実行時の安全性と信頼性がさらに向上します。