ファイル システム ACL を介した IIS のコンテンツのセキュリティ保護
作成者 : Nazim Lala
発行日 : 2009 年 3 月 10 日 (作業者 : naziml(英語))
更新日 : 2009 年 3 月 18 日 (作業者 : naziml(英語))
1 ACL の説明
ACL (アクセス制御リスト) は、オブジェクトに関連付けられているアクセス許可の一覧です。これらのアクセス許可エントリはそれぞれ ACE (アクセス制御エントリ) と呼ばれ、特定の ID の特定のオブジェクトに関連付けられたアクセス許可を含みます。この場合は、ファイル システム オブジェクトが関係するため、ACL は NTFS ファイル システム上のファイルまたはディレクトリに設定できます。ACE で対象となる最も一般的なアクセス許可は、読み取り、書き込み、実行、およびフォルダーの内容の一覧表示です。
1.1 読み取り/書き込みアクセス許可
読み取りおよび書き込みアクセス許可は、ファイルシステム オブジェクトにそれぞれ読み取りおよび書き込みのアクセス許可を付与します。
1.2 フォルダーの内容の一覧表示アクセス許可
フォルダーの内容の一覧表示アクセス許可は、フォルダーの内容の表示に使用され、ディレクトリのファイル変更通知の登録に必要です。
1.3 実行アクセス許可
実行アクセス許可は、OS が特定のアプリケーションを指定ユーザーとして実行する必要があるかどうかを指定するために使用されます。これは、PHP や ASP.NET のような動的なアプリケーション シナリオには対応しません。.php または .aspx ファイルを呼び出すときはコードを実行しますが、オペレーティング システム側からではありません。実行アクセス許可を設定する代わりに、セクション 1.5 のスクリプト/実行アクセス許可を使用して調べる必要があります。
1.4 フル コントロール
フル コントロール アクセス許可では、ファイル システム オブジェクトに対してすべてのアクセス権が付与されます。この種のアクセス許可は使用しないようにしてください。より細かい読み取り/書き込みのアクセス許可を使用することが普通です。
1.5 IIS スクリプト/実行アクセス許可
.php ファイルや .aspx ファイルのような動的コンテンツでは、スクリプト アクセス許可が機能している必要があります。しかし、ファイル システムで ACL を調べると、Execute フラグは見つかりますが、Script フラグはまったく見つかりません。これは IIS の特殊な構成によるためです。IIS は特定のファイルが動的コンテンツかどうかを示し、これをファイル システムの ACL の外側の IIS 構成に保存します。スクリプトまたは実行アクセス許可と言う場合、これはこの IIS 構成を指し、ファイル システムの実行アクセス許可ではありません。
1.6 オブジェクトの継承
通常、ファイル システムの ACL は親から継承されます。親ディレクトリがかなりゆるい ACL を設定していることもあります。適切にコンテンツをロックするためにはこれを子レベルで上書きする必要があります。ただし、ホスティングされているシナリオでは、これは問題とならないと思われます。ルートでのアクセス許可はほとんどないためです。
2 一般的な IIS ID
ACL を介して特定の ID に対するアクセス許可を許可、または拒否することで、コンテンツのセキュリティを確保することができます。そのため、ACL について詳しく検討する前に、IIS で一般的に使用されている ID の一覧を確認することが重要です。一般的に、2 つの ID が関係します。1 つ目はプロセス ID です。IIS ワーカー プロセスはこの ID で起動します。2 つ目は、要求の認証によって取得される要求ハンドラー ID です。
2.1 ワーカー プロセス ID (WPI)
ワーカー プロセス ID とは、IIS ワーカー プロセスが実行時に使用する IDです。このプロセス ID は、IIS のアプリケーション プールの構成設定を介して構成できます。Windows Server 2003 の IIS 6.0 と Windows Server 2008 の IIS 7.0 には、既定の WPI として NETWORK SERVICE が使われます。ただし、Windows Server 2008 R2 では、既定の WPI としてアプリケーション プール ID を使用します (下記を参照してください)。アプリケーションが認証し、代理で処理した場合、要求ハンドラー ID が認証されたユーザー ID となります。PHP については、php.ini ファイルで fcgi.impersonate が true に設定されている場合 (IIS には推奨)、PHP プロセスは認証されたユーザーとして動作します。匿名認証の場合、認証されたユーザーは、構成済み匿名ユーザーとなります (詳細はセクション 2.3 を参照してください)。
2.2 IIS_IUSRS
これは、サーバー上のすべてのワーカー プロセス ID (WPI) のコンテナーであるビルトイン ID グループです。IIS は自動的にすべてのワーカー プロセス ユーザー ID をこのグループに含めるため、手動で追加する必要はありません。IIS 6 (Windows Server 2003) では、このグループを IIS_WPG と呼びます。これはすべてのワーカー プロセス ID を含む包括的なグループであるため、コンテンツの隔離に使用するグループとしては好ましくありません。いずれかのアプリケーション プールで動作するアプリケーションはすべて、このグループが含む ID で実行することになります。そのため、このグループに読み取りアクセス許可を付与すると、すべてのアプリケーションがコンテンツを読み取ることができるようになります。
2.3 IUSR /匿名ユーザー ID
IUSR アカウントは既定のビルトイン ID であり、匿名認証を使用しているユーザーのユーザー ID を表すために使用されます。匿名ユーザー ID を構成して、このビルトイン ID 以外の ID に設定できます。実際には、匿名ユーザー アカウントに対してカスタム アカウントを構成し、ビルトイン アカウントは使用しないようにする必要があります。IIS では、匿名ユーザーであるから認証されたユーザーではないと考えることはできません。むしろ、認証されたユーザーが匿名ユーザー ID である場合の要求が匿名要求であると考える必要があります。
2.4 アプリケーション プール ID
これは、特定のアプリケーション プールに関連付けられた仮想 ID です。ユーザーがアプリケーション プールを作成するたびにプール内に仮想 ID (セキュリティ ID、つまり SID) が作成され、この ID は IIS ワーカー プロセス内に挿入されます。これによって、このアプリケーション プール下で動作するワーカー プロセスは、この仮想 ID にアクセス許可がロックされているコンテンツに対してアクセス権を持ちます。Windows Server 2008 SP2+ では、管理者はこの仮想 ID で自身のワーカー プロセスを作成できます。これは、アプリケーション プール ID タイプとして IIS アプリケーション プールの構成設定に構成でき、Windows Server 2008 R2 の既定の WPI ID タイプです。この変更の理由は、この ID がこの ID を作成したアプリケーション プールに固有であることから、この ID を使用してサーバー上のコンテンツを効率的にアプリケーション プールに分離できるということにありました。
2.5 認証されたユーザー ID
アプリケーションがいずれかの認証形式 (匿名認証を含む) を使用している場合、それが認証されたユーザーの ID です。匿名認証の場合は、この ID は構成済みの匿名ユーザー ID となります (2.3 を参照してください)。
3 IIS 実行パイプライン
どの段階でどの ID を適用できるかという基本を把握するには、IIS 実行パイプランの基礎を理解することが重要です。ここでは要求パイプラインの全段階を掘り下げて調べるのではなく、重要なパイプラインの 2 つの段階を取り上げることにします。
3.1 認証
認証されたユーザー コンテキストは、認証前は不明なユーザー コンテキストです。したがって、この時点では、IIS ワーカー プロセスはすべて WPI として実行しています。このことに留意する必要があります。というのは、要求が認証される前にコンテンツにアクセスしようとしている PHP 要求がある場合、WPI でそのコンテンツにアクセスする必要があるためです。このシナリオは、URL 書き換えモジュールのグローバル ルールを使用する場合に関係します。URL の書き換えは IIS パイプラインのグローバルな開始前要求段階で実行されますが、これは認証のかなり前です。URL 書き換えモジュールでは、アクセス先のリソースがファイルかディレクトリかに応じて、異なる方法でルールを処理できます。これを評価するために、ファイルシステムへのアクセスが必要となり、その実行パイプラインでの位置が原因で、このアクセス要求は WPI で実行することになります。
認証後に、認証されたユーザーのコンテキストが設定されますが、要求がハンドラーにマッピングされるまでは必ずしも代理処理しているとは限りません。認証からハンドラー マッピングまでの間の段階については、WPI として実行している可能性が高くなります。
3.2 ハンドラー マッピング
実行パイプラインのこの段階で、要求がハンドラーにマッピングされます。たとえば、*.php への要求は FastCGI ハンドラーにマッピングされます。このマッピングが発生して代理処理が有効化された後、ハンドラー ID は認証されたユーザーとなり、この段階でのリソース アクセスはすべて認証されたユーザーの ID を使用して実行されます。
4 どの ID を使用するべきでしょうか
アクセス許可をどのアカウントに付与するべきかは、アプリケーションのプロファイルと重要なリソースによって異なります。主に検討することは、どんなアクセス許可を付与するか、そして自身が認証されたユーザーかどうかという点です。
4.1 正しいアクセス許可の付与
ユーザーによってアップロードされないものはすべて、ファイル システムの読み取りアクセス権のみ必要です。ただし、この例外が PHP アプリケーションや ASP.NET アプリケーションなどの動的コンテンツです。.php や .aspx ファイルなどではすべて IIS スクリプト アクセス許可も必要となります。実行が必要な実行可能ファイルがある場合、これらのファイルは IIS 実行アクセス許可を必要とし、CGI 制限一覧で適切に構成されている必要があります。
ユーザーによってアップロードされるコンテンツは、別のフォルダーに入れて、このフォルダーに書き込みアクセス権を付与する必要があります。ただし、このフォルダーに IIS 実行アクセス許可やスクリプト アクセス許可を付与しないことが重要です。付与してしまうと、ユーザーが悪意のあるコードをアップロードして実行できるようになってしまいます。
一般に、アプリケーションが正しく動作するためには、WPI にすべてのコンテンツに対する読み取りアクセス権が必要です。
4.2 認証を必要とするアプリケーション
認証済みアクセスの場合は、認証されたユーザーすべてを含むグループに対するすべてのリソースをロックダウンするのが理想的です。さまざまなカテゴリのユーザー (管理者および管理者以外) がいる場合は、グループを分けて、それに応じたアクセス権を付与する必要があります。たとえば、アプリケーションに管理スクリプトを含む管理ディレクトリがある場合は、管理グループだけにこのディレクトリを読み取るアクセス許可を与えます。アプリケーションが代理で処理している場合は、ハンドラー ID が認証されたユーザーとなります。代理で処理していない場合は WPI が認証されたユーザーとなります。php.ini ファイルで fcgi.impersonate を true に設定している場合、fcgi プロセスの ID が認証されたユーザー ID となります。true に設定していない場合、WPI と同じ ID が認証されたユーザー ID となります。この情報を利用することで、管理者はコンテンツに正しい ACL を設定することができます。
4.3 匿名で実行するアプリケーション
IIS では、匿名で実行するということは、匿名ユーザー ID として認証されていることを意味します。この場合、理想的には、アプリケーション プール ID とカスタム構成の匿名 ID のいずれかに対してリソースをロックダウンしたいものです。この場合は、匿名 ID ではなくアプリケーション プール ID にアクセス権を付与することをお勧めします。コンテンツに IIS_IUSRS グループ アクセス権を付与した場合、これはあらゆるアプリケーション プールで実行しているアプリケーションがコンテンツへのアクセス権を持つことを意味します。匿名ユーザーにファイルのアップロードを許可する場合は、匿名ユーザーがアップロードできるコンテンツの種類をアプリケーションで細かく確認できるようにして、サーバーのセキュリティを確保する必要があります。
5 ACL を設定する方法
icacls.exe などのコマンドライン ツールを含め、ACL はシェルを介して何通りかの方法で設定できます。このドキュメントでは、ACL の設定に使用する Web 配置ツール マニフェスト (XML) メカニズムについて説明します。これは、Web 配置ツールまたは Web プラットフォーム インストーラーを使用してアプリケーションをインストールした場合に適用されるメカニズムです。
ユーザー Foo に対して、MyApp ファイル システム ディレクトリに対する読み取り、実行、および書き込みアクセス許可を付与する場合は、manifest.xml ファイルに次の行を追加します。
<setAcl path="MyApp" setAclAccess="ReadAndExecute, Write" setAclUser="Foo" />
MyApp/Upload パスに ACL を設定して、匿名ユーザーがコンテンツをアップロードできるようにするには、manifest.xml ファイルに次の行を追加します。
<setAcl path="MyApp/Upload" setAclAccess="Write" setAclUser="anonymousAuthenticationUser" />
anonymousAuthenticationUser は、構成済みの匿名認証 ID まで解決する特殊なトークンです。
アプリケーション プール ID に対して MyApp\Data フォルダーへの読み取りアクセス権を付与する場合は、manifest.xml ファイルに次の行を追加する必要があります。
<setAcl path="MyApp/Data" setAclAccess="Read" />
ここでは setAclUser は使用しませんでした。この既定の値は、アプリケーション プール ID であるため、この場合は省くことにしました。
6 リンク
IIS 7.0 での組み込みユーザーとグループ アカウントとは