解説

インサイド .NET Framework [改訂版]

第10回 ロールベース・セキュリティ

吉松 史彰
2003/09/10
Page1 Page2 Page3 Page4

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構成ファイルの内容もややこしい設定がいろいろとあるので、運用時に困らないようにきちんと内容を理解しておく必要がある。End of Article

 

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


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間