解説 インサイド .NET Framework ［改訂版］ 第10回　ロールベース・セキュリティ 吉松 史彰 2003/09/10

---

WebアプリケーションとNTFSアクセス制御

　.NET Frameworkには、Webアプリケーションでのアクセス制御機構が2つ用意されている。1つは上述のUrlAuthorizationModuleで、web.config構成ファイルのauthorization要素の中身を利用する。もう1つは、FileAuthorizationModuleで、NTFSファイル・システムのアクセス制御機構を利用する。FileAuthorizationModuleは、Windowsから認証を受けたユーザーに対して機能するため、ASP.NETでWindows認証を利用しているときにしか動作しない。その仕組みは、単にWindows認証されたユーザー（WindowsPrincipal.Identity）に対して、NTFSのセキュリティを適用するだけだ。

　ところが、ASP.NETには、Windows認証以外にフォーム認証もPassport認証もあるため、話が少しややこしくなることがある。FileAuthorizationModuleの仕事は、あくまでもaspxファイルやasmxファイルなど、ユーザーがWebサーバに送信したHTTPリクエストに対応するファイルに対して、そのユーザーにアクセス権限があるのかどうかをチェックするだけだ。しかし、例えばそのaspxファイルに次のようなコードが含まれていた場合、C:\Inetpub\wwwroot\log.txtファイルにNTFSアクセス権限が設定されている可能性がある。このとき、log.txtにアクセスするユーザーは誰だろうか。

  System.IO.FileStream fs
          = System.IO.File.OpenRead(@"c:\inetpub\wwwroot\log.txt");

　ASP.NETでWindows認証を使っていれば、アクセスするのは認証を受けたユーザーであろう。だが、フォーム認証を使っていた場合、log.txtには誰がアクセスするのだろうか。フォーム認証で認証されたユーザーは、たいていの場合Windowsユーザーではない。例えば、フォーム認証を受けたユーザーがNTFSによるアクセス制御の結果、Webフォームへのアクセスを拒否されることがあるのだろうか。

　実は、このときlog.txtにアクセスするユーザーは、Windows上で稼働しているASP.NETというアプリケーション（aspnet_wp.exe）の中で、いまそのHTTPリクエストを処理しているスレッドに割り付けられているWindowsユーザーになる。このユーザー（アイデンティティ）は、WindowsIdentityクラスのGetCurrentメソッドで取得できる。GetCurrentはstatic（Shared）メソッドなので、次のように型名.メソッド名と書けば、インスタンスを持っていなくても呼び出せる。

  WindowsIdentity winUser = WindowsIdentity.GetCurrent();

　ASP.NETにおいてHTTPリクエストの処理を行うスレッドを実行しているWindowsユーザーは、デフォルトではそのマシン上に作成されているASPNETというユーザーになる。従って、次のように記述されたaspxを実行すると、結果は以下のようにコンピュータ名\ASPNETになる（なお、Windows Server 2003上の新しいIIS 6.0ではNT AUTHORITY\NETWORK SERVICEになる）。

<%@Page Language="C#"%> <%@Import Namespace="System.Security.Principal"%> <%   WindowsIdentity winUser = WindowsIdentity.GetCurrent();   Response.Write(winUser.Name); %>

HTTPリクエストを処理しているユーザー（アイデンティティ）を表示するASP.NETプログラム

　

上記プログラムの実行結果例

　つまり、aspx以外のファイルに関してNTFSのアクセス制御を受けるのは、ASPNETというユーザーであって、ログイン・ページで認証したフォーム認証のユーザーではない。Windowsのエクスプローラなどを使って、今回の場合のlog.txtのようなファイルにセキュリティをかけている場合は、デフォルトではASPNETがそのチェックを受けることになる。

　もっとも、ASPNETというユーザーは、ASP.NETというサービスを稼働させるためのユーザーであって、1つ1つのアプリケーションで独自のアクセス制御ロジックを適用するために使うユーザーではないし、そのように利用することは好ましくもない。通常は、実際にIISで認証を受けたユーザー（または匿名ユーザーのIUSR_コンピュータ名）でアクセスが制御されなければならない。そこで、web.config構成ファイルに次のように記述すると、ASPNETではなくIISで認証を受けた実際のWindowsユーザーがNTFSアクセス制御の対象になる。上記のaspxファイルは変更せずに、web.configを以下のように書き換えてidentity要素を設定し、再度aspxファイルを実行してみると、「コンピュータ名\IUSR_コンピュータ名」が表示されるはずだ。

<configuration>   <system.web>     <authentication mode="None"/>     <identity impersonate="true" />   </system.web> </configuration>

「ASPNET」ではなく、IISで認証を受けた実際のWindowsユーザーがNTFSアクセス制御の対象となるようにするためのweb.configファイル設定

　ここでは簡単にするためにauthentication要素のmode属性をNoneに設定したが、FormsでもPassportでもこの動作は変わらない。Windows認証以外の認証方式でWebアプリケーションを構成している場合でも、NTFSによるアクセス制御は必ずWindowsユーザーに対して行われるため、このようにIISで認証を受けたユーザーを代わりに利用しなければならないわけだ。上記の場合は、log.txtに対して「IUSR_コンピュータ名」ユーザーが読み取りアクセス権を持っていなければ、アクセスは拒否されてしまう。

　この動作はNTFSに限らず、ASP.NETのWebアプリケーションから呼び出されるもので、しかもWindowsベースのセキュリティを要求するすべての機能に適用される。例えば、DCOMを利用したCOMオブジェクトの呼び出し（EXEベースのCOMサーバを利用する場合や、ほかのマシン上で稼働しているCOM+コンポーネントへのアクセス）や、Windows認証を行っているSQL Serverに対しても、やはりデフォルトではASPNET、identity要素の設定によってはIUSR_コンピュータ名やそのほかのWindowsユーザーがアクセスを行うことになる。このとき、フォーム認証を受けたユーザーは、このプロセスには全く関与できない。

　つまり、web.config構成ファイルのidentity要素の設定や、ASPNET、SYSTEM、NETWORK SERVICEというユーザーは、ASP.NETの認証や承認のメカニズムとは関係がない。ASP.NET上で稼働するアプリケーションからWindows上で稼働するほかのサービス（ファイル・システム、DCOM／COM+、SQL Serverなど）を呼び出したときにだけ関係する。

今回のまとめ

　ロールベース・セキュリティはこれまでもこれからも、アプリケーションでアクセス制御を行うときに必ず使われるだろう。.NET Frameworkには非常に柔軟なロールベース・セキュリティの仕組みが用意されている。柔軟すぎて少し書かなければならないコードもあるので注意が必要だ。また、Windows認証ならWindowsのグループが使えるが、そうでなければロールとユーザーとの対応付けを行うツールも作らなければならない。ロールベース・セキュリティは一般的な機能だが、.NET Frameworkが持つほかの機能に比べると、書かなければならないコードはまだまだ多い。また、web.config構成ファイルの内容もややこしい設定がいろいろとあるので、運用時に困らないようにきちんと内容を理解しておく必要がある。

INDEX
	解説 インサイド .NET Framework ［改訂版］
	第10回　ロールベース・セキュリティ
	1．アイデンティティとプリンシパル
	2．ロールベース・セキュリティの適用
	3．Webアプリケーションとロールベース・セキュリティ
	4．WebアプリケーションとNTFSアクセス制御

　

「解説：インサイド .NET Framework ［改訂版］」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）