ファイルシステム ACL を使用して IIS のコンテンツをセキュリティで保護する

2024-03-13

はじめに

アクセス制御リスト (ACL) は、オブジェクトに関連付けられているアクセス許可の一覧です。これらの各アクセス許可エントリは、アクセス制御エントリ (ACE) と呼ばれます。ACE には、特定の ID の特定のオブジェクトに関連付けられたアクセス許可が含まれています。たとえば、ファイルシステムオブジェクトについては、NTFS ファイルシステム上のファイル/ディレクトリに ACL を設定できます。

グラフィカルユーザーインターフェイス (GUI) ツール (マイコンピューターや Windows® エクスプローラーなど) を使用して、ACL を設定または編集できます。これらのツールのいずれで任意のファイルまたはフォルダーリソースを右クリックし、[プロパティ] を選択して、[セキュリティ] タブをクリックするだけで、選択したリソースの ACL がグラフィカルに表示されます。このダイアログボックスでは、ファイルやフォルダーなどのシステムリソースに対するグループまたはユーザーのアクセス許可を適用または削除できます。コマンドラインユーティリティ Cacl.exe を使用して、ファイル ACL を表示または変更することもできます。

ACL の基本

ACL の基本から始めると便利です。

一般的な IIS アクセス許可

ACE で最も一般的なアクセス許可は、フォルダーの内容の読み取り、書き込み、実行、および一覧表示です。

読み取り/書き込みアクセス許可。 読み取りアクセス許可と書き込みアクセス許可は、それぞれファイルシステムオブジェクトへの読み取りと書き込みのアクセスを許可します。
フォルダーコンテンツの一覧表示アクセス許可。 フォルダーコンテンツの一覧表示アクセス許可は、フォルダーの内容を表示するために使用され、ディレクトリにファイル変更通知を登録するために必要です。
実行アクセス許可。 実行アクセス許可は、オペレーティングシステムが指定されたユーザーとして特定のアプリケーションを実行する必要があるかどうかを指定するために使用されます。これは、PHP (または Microsoft® ASP.NET) などの動的なアプリケーションシナリオには対応していません。 .php や .aspx ファイルを呼び出すとコードを実行していることになりますが、オペレーティングシステムから見るとそうではありません。実行アクセス許可を設定する代わりに、スクリプト/実行アクセス許可の使用を検討する必要があります。
フルコントロール。 フルコントロールアクセス許可は、ファイルシステムオブジェクトにすべてのアクセスを付与します。完全なコントロールを避け、より細分化された読み取り/書き込みアクセス許可を使用します。
IIS スクリプト/実行アクセス許可。 .php (または.aspx) ファイルなどの動的コンテンツを含むファイルには、機能するためのスクリプトアクセス許可が必要です。ただし、ファイルシステムの ACL には実行フラグがありますが、スクリプトには何もないことに注意してください。これは、インターネットインフォメーションサービス 7 以降 (IIS 7 以降) には、特定のファイルに動的コンテンツがあるかどうかを示す特別な構成があるためです。この構成は、ファイルシステム ACL の外部にある IIS 構成に格納されます。スクリプトまたは実行のアクセス許可について言及されるとき、それは実際にはファイルシステムの実行アクセス許可ではなく、IIS 構成です。
オブジェクトの継承。 通常、ファイルシステム ACL は継承されます。場合によっては、親ディレクトリの ACL が非常に緩いことがあり、コンテンツを適切にロックするために、子ディレクトリの ACL をオーバーライドする必要があります。ルートにアクセス許可がほとんどないため、ホストされているシナリオでこれが問題になることはほとんどありません。

一般的な IIS ID

ACL を介して特定の ID に対するアクセス許可を許可または拒否して、コンテンツをセキュリティで保護することができます。 ID には、プロセス ID (IIS ワーカープロセスが起動される ID) と要求ハンドラー ID (要求の認証からの ID) の 2 種類があります。

ワーカープロセス ID (WPI)。 IIS ワーカープロセスは WPI として実行されます。WPI は、IIS のアプリケーションプール構成設定を使用して構成できます。 Windows Server® 2003 上の IIS 6.0 と Windows Server® 2008 上の IIS 7 以降では、既定の WPI として "ネットワークサービス" ID があります。ただし、Windows Server® 2008 R2 では、既定の WPI としてアプリケーションプール ID が使用されます。アプリケーションが認証と偽装を行う場合、要求ハンドラー ID は認証済みユーザー ID です。
Php.iniで fcgi.impersonate が "true" (IIS に推奨) に設定されている場合、PHP プロセスは認証済みユーザーとして実行されています。匿名認証の場合、認証済みユーザーは構成済みの匿名ユーザーであることに注意してください。
IIS_IUSRS。 これは、サーバー上のすべてのワーカープロセス ID (WPI) のコンテナーである組み込み ID グループです。 IIS には、このグループ内のすべての WPI が自動的に含まれます (手動で追加する必要はありません)。
Windows Server 2003 の IIS 6.0 では、このグループは IIS_WPG と呼ばれます。これは、すべての WPI を含む包括的なグループであるため、コンテンツを分離するための適切な候補ではありません。任意のアプリケーションプールで実行されているアプリケーションは、このグループに含まれる ID として実行されるため、このグループに読み取りアクセスを付与すると、すべてのアプリケーションがコンテンツを読み取ることができることになります。
IUSR/匿名ユーザー ID。 組み込み IUSR アカウントは、匿名認証を使用するすべてのユーザーのユーザー ID を示すために使用される既定値です。匿名ユーザー ID は構成可能であり、この組み込みの既定値以外の ID に設定できます。
実際には、匿名ユーザーアカウントのカスタムアカウントを構成する必要があり、組み込みアカウントは使用しないでください。 IIS では、匿名ユーザーは認証済みユーザーの不在を意味しないと理解することが重要です。むしろ、匿名要求は、認証済みユーザーが匿名ユーザー IDである場合の要求とみなす必要があります。
アプリケーションプール ID。 これは、特定のアプリケーションプールに関連付けられている仮想 ID です。ユーザーがアプリケーションプールを作成するたびに、仮想 ID (セキュリティ識別子または SID) が作成されます。この ID は IIS ワーカープロセスに挿入されるため、このアプリケーションプールで実行されているワーカープロセスは、この仮想 ID にロックされたアクセス許可を持つコンテンツにアクセスできるようになります。 Windows Server 2008 Service Pack 2 (SP2) では、管理者はこの仮想 ID を使用してワーカープロセスを作成できます。これは、IIS アプリケーションプールの構成設定で "アプリケーションプール ID" の種類として構成でき、Windows Server 2008 R2 では既定の WPI ID の種類です。 (ID は、それを作成したアプリケーションプールに固有であるため、サーバー上のコンテンツをより効果的にアプリケーションプールに分離するために使用できます。)
認証済みユーザーの ID。 アプリケーションで任意の形式の認証 (匿名認証を含む) を使用する場合、これは認証済みユーザーの ID です。匿名認証の場合、この ID は構成済みの匿名ユーザー ID になります。

IIS 実行パイプライン

どの段階でどの ID が適用されるかを理解するには、IIS 実行パイプラインの基本を理解すると便利です。最も適用しやすいパイプラインの 2 つの部分は、認証とハンドラーのマッピングです。

[認証] 。 認証前は、認証済みユーザーコンテキストは不明で、すべての IIS ワーカープロセスが WPI として実行されています。要求が認証される前にコンテンツにアクセスしようとしている PHP 要求がある場合、WPI はコンテンツにアクセスする必要があります。このシナリオは、認証前に発生する IIS パイプラインのグローバルな開始前要求フェーズで実行される URL リライターのグローバルルールを使用する場合に発生します。 URL リライターには、アクセスするリソースがファイルかディレクトリかに基づいて、ルールを異なる方法で処理する機能があります。これを評価するには、ファイルシステムアクセスが発生する必要があり、実行パイプラインでの位置の関係上、このアクセス要求は WPI として発生します。

認証後に、認証済みユーザーコンテキストが設定されますが、要求がハンドラーにマップされるまで、必ずしも偽装状態ではありません。認証とハンドラーマッピングの間のフェーズでは、WPI として実行されている可能性が最も高くなります。
ハンドラーマッピング。 実行パイプラインのこのフェーズでは、要求がハンドラーにマップされます。たとえば、*.php への要求は FastCGI ハンドラーにマップされます。このマッピングが発生し、偽装が有効になった後に、ハンドラー ID は認証済みユーザーとなり、このフェーズのすべてのリソースアクセスは、認証済みユーザー ID を使用して行われます。

ID の選択

アクセス許可を付与する適切なアカウントの把握は、アプリケーションのプロファイルと重要なリソースに応じて異なります。主な考慮事項は、付与するアクセス許可と、あなたが認証済みかどうかです。

適切なアクセス許可の付与。 PHP や ASP.NET アプリケーションなどの動的コンテンツには、IIS スクリプトのアクセス許可と読み取りアクセスが必要です。実行可能ファイルを実行する必要がある場合は、IIS の実行アクセス許可が必要であり、CGI 制限リストで適切に構成する必要があります。ユーザーがアップロードしていないものは、ファイルシステムでの読み取りアクセスだけが必要です。
ユーザーがアップロードするコンテンツは、書き込みアクセスを割り当てる別のフォルダーに配置する必要があります。ユーザーが悪意のあるコードをアップロードして実行できないように、このフォルダーに IIS の実行許可またはスクリプトのアクセス許可を付与しないことが重要です。
一般に、WPI は、アプリケーションが正常に動作するために、すべてのコンテンツへの読み取りアクセスを持っている必要があります。
認証を必要とするアプリケーション。 認証が必要なアプリケーションの場合は、すべてのリソースを、すべての認証済みユーザーを含むグループにロックダウンします。ユーザーのカテゴリ (管理者と管理者以外) が異なる場合は、個別のグループを作成し、それに応じてアクセスを付与します。たとえば、アプリケーションに管理スクリプトを含む管理ディレクトリがある場合は、このディレクトリを読み取るアクセス許可を管理者グループのみに付与します。アプリケーションが偽装している場合、ハンドラー ID は認証済みユーザーです。それ以外の場合は、あなたのWPI です。 Php.ini ファイルで fcgi.impersonate を "true" に設定した場合、fcgi プロセス ID は認証済みユーザー ID になります。それ以外の場合は WPI です。この情報を使用すると、管理者はコンテンツに配置する ACL の適切なセットを決定できます。
匿名で実行されるアプリケーション。 IIS で匿名で実行することは、匿名ユーザー ID として認証されることを意味します。この場合は、アプリケーションプール ID またはカスタム構成の匿名 ID のいずれかにリソースをロックダウンし、匿名 ID 経由でアプリケーションプール ID にアクセスできるようにします。 IIS_IUSRSグループにコンテンツへのアクセスを付与すると、任意のアプリケーションプールで実行されているアプリケーションがコンテンツにアクセスできるようになります。匿名ユーザーにファイルのアップロードを許可する場合は、サーバーのセキュリティを維持するために、アプリケーションはこれらのユーザーがアップロードできるコンテンツの種類の種類をさらにチェックする必要があります。

ACL を設定する方法

Icacls.exe などのコマンドラインツールなど、シェルを使用して ACL を設定する方法はいくつかあります。この記事では、ACL の設定に使用できる Web 配置ツールマニフェスト (XML) メカニズムについて説明します。これは、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 です)。

詳細情報のリンク

IIS7 以降の組み込みユーザーアカウントとグループアカウントについて