ASP.NET 4 アプリケーションのコード アクセス セキュリティ
コード アクセス セキュリティ (CAS) は、コード実行機能に制約を適用するために ASP.NET によって使用される .NET Framework のセキュリティ機構 ("サンドボックス") です。 ASP.NET では、ASP.NET 1.1 以降、信頼レベルという概念を使用して CAS を実装しています。
このトピックでは、ASP.NET 4 における CAS の機能について、旧バージョンからの変更点を中心に説明します。 ASP.NET を初めて使用するユーザーの方にとって、これらの変更点は特に重要な関心事ではないかもしれません。 しかし、このトピックには、現在のバージョンの ASP.NET における CAS の機能という、新規アプリケーションの設計方法に影響を与えうる情報も記載されています。
このトピックでは、次の項目について説明します。
CAS ポリシー レベルがなぜ使用されなくなったか、そして、部分信頼 ASP.NET アプリケーションを UNC 共有から実行できるようにするなどの一般的なシナリオにこのことがどのように影響するか
ASP.NET 4 における CAS の動作をカスタマイズする方法
信頼されるコードを ASP.NET 4 で CAS と連動させる場合に生じる互換性に関する問題
このトピックは、.NET Framework CAS と ASP.NET の信頼レベルを理解していることを前提としています。 これらのトピックの詳細については、次のドキュメントを参照してください。
このトピックは、次の内容で構成されています。
ASP.NET 4 コード アクセス セキュリティ モデルの概要
同種アプリケーション ドメイン
条件 APTCA
セキュリティ透過性と ASP.NET 4 におけるその機能
ASP.NET 4 コード アクセス セキュリティ モデルの概要
ASP.NET 4 では、ASP.NET 3.5 以前のバージョンと根本的に異なる変更点が CAS に加えられています。次にその例を示します。
既定では、ASP.NET 部分信頼アプリケーション ドメインは同種です。 これにより、部分信頼アプリケーション ドメインで実行中のコードで使用できるアクセス許可セットが制約されることになります。 また、これは、アプリケーション ドメインの信頼境界自体が、部分信頼許可セットと関連付けられていることを意味します。 同種アプリケーション ドメインでは、セキュリティ ポリシーがコンピューター レベル、ユーザー レベル、またはエンタープライズ レベルの CAS ポリシーと交差することはありません。
注意
新しい同種アプリケーション ドメイン モデルでは、旧バージョンの ASP.NET で使用されていたポリシー ファイルとは多少異なる、宣言 ASP.NET 信頼ポリシー ファイルのセットが必要となります。その結果、ASP.NET 4 をインストールすると、コンピューターには、ASP.NET 部分信頼ポリシー ファイルのセットが 2 つ格納されます。新しい CAS モデルは一方のセットを使用し、もう一方のセットは、ASP.NET 4 よりも前のバージョンの CAS モデルを使用するようにアプリケーションが構成されている場合に使用されます。
旧バージョンの ASP.NET では、ASP.NET 型が Web 部分信頼環境以外の ASP.NET 環境で使用されるのを防ぐために、ASP.NET 関連のほとんどすべてのパブリック クラスに対して AspNetHostingPermission 属性が使用されていました。 たとえば、AspNetHostingPermission 属性を使用すると、大半の ASP.NET クラスが部分信頼 ClickOnce アプリケーションで使用されないようにすることができました (ClickOnce アプリケーションにおける CAS の詳細については、「ClickOnce アプリケーションのコード アクセス セキュリティ」を参照してください)。 ASP.NET 4 では、これと同じ結果を得るために、(AllowPartiallyTrustedCallersAttribute 型に基づく) 条件付き APTCA と呼ばれる別の CAS テクノロジが AspNetHostingPermission 属性の代わりに使用されます。 その結果、AspNetHostingPermission 属性は、大半の ASP.NET 型とそのメンバーから削除されました。
ASP.NET 4 では、システム アセンブリの多くが更新され、CLR セキュリティ透過性モデルを使用するようになっています。 ASP.NET 4 の透過性モデルは、Silverlight で使用されている透過性モデルとよく似ています。 コードの透過性の詳細については、「透過的セキュリティ コード」を参照してください。
これらの変更点の影響に気付くのは、caspol.exe などのツールを使用して作成されたカスタム CLR CAS ポリシーに依存していた場合です。 また、ASP.NET または .NET Framework のコードしか呼び出し履歴でアクティブになっていない場合に、GAC に配置されているアセンブリを使用しないと特権を必要とする操作を実行できない部分信頼 Web アプリケーションも、これらの変更点の影響を受けます。 次の各セクションでは、CAS の変更点について説明します。
同種アプリケーション ドメイン
ここでは、同種アプリケーション ドメインについて説明します。 具体的には、同種アプリケーション ドメインが導入される原因となった、ASP.NET 2.0 以降に加えられた動作面での変更点について説明します。 また、同種アプリケーション ドメインでコードを実行するために設定および追加できる互換性関連のオプションとコード変更についてもそれぞれ説明します。
想定されるアクセス許可セットの数の削減
同種アプリケーション ドメインは、コードを実行するための共有アクセス許可セットを定義する部分信頼アプリケーション ドメインです。 ASP.NET 4 でホストされている同種アプリケーション ドメインでは、読み込むことができるコードは、2 つのアクセス許可セットのうちの 1 つに関連付けられています。 コードは、完全信頼を使用して実行されるか (GAC コードは常に完全信頼で実行されます)、または、現在の trustLevel 設定で定義されている部分信頼アクセス許可セットを使用して実行されます (詳細については、「securityPolicy の trustLevel 要素 (ASP.NET 設定スキーマ)」を参照してください)。
注意
ASP.NET 4 アプリケーション ドメインは既定で完全信頼に設定されます。ASP.NET 4 で同種の動作を有効にするには、trustLevel 要素の name 属性を Full 以外の値に設定する必要があります。
この動作は、旧バージョンの ASP.NET における部分信頼アプリケーションとは異なります。 旧バージョンでは、付与セットとメンバーシップ条件がそれぞれ異なる複数のアクセス許可セットを作成できました。 このようなアクセス許可の混在を処理することが困難であったことから、.NET Framework 4 では、同種アプリケーション ドメインが導入されました。 コードの実行に使用される可能性があるすべての条件を考慮したうえで、アクセス許可レベルがそれぞれ異なる複数のアクセス許可セットを作成し、各アクセス許可レベルが実際に適用されていることを証明することは、非常に困難でした。 たとえば、コードがリフレクションを使用して実行されたり、完全信頼コードが部分信頼の呼び出し元に代わって他の完全信頼コードを実行したりするなど、コード実行の条件はさまざまです。 アクセス許可セットの作成では、これらの条件をすべて考慮しなければなりませんでした。 同種アプリケーション ドメインは、想定されるコード実行結果の数を減らすことによって CAS の決定方法を大幅に簡略化します。 コードは完全信頼になるか、正しく定義された部分信頼アクセス許可セットを 1 つだけ持つかのいずれかになります。 ASP.NET の場合、正しく定義された部分信頼アクセス許可セットとは、指定された ASP.NET 信頼レベルに該当するアクセス許可セットのことです。
同種アプリケーション ドメインで読み込みを試行するコードには、上記の 2 つ以外にも、もう 1 つの状態があります (この状態は CLR によって個別のアクセス許可セットと見なされません)。 3 番目のアクセス許可セットは空のアクセス許可セットです。これは、ASP.NET のすべての部分信頼構成ファイルで Nothing アクセス許可セットとして定義されます。 Nothing アクセス許可セットとして評価されるすべてのコードは、読み込み不可と見なされます。 その結果、Nothing アクセス許可セットを持つアセンブリを同種アプリケーション ドメインに読み込もうとすると、SecurityException 例外が必ず発生します。
ASP.NET 部分信頼ポリシーのみの適用
同種アプリケーション ドメインの部分信頼アクセス許可セットは、そのアプリケーション ドメインの作成を担当するホストによってのみ作成されます。 つまり、ASP.NET 4 では、.NET Framework インストールの CONFIG サブディレクトリに保存されている部分信頼構成ファイルの内容によってのみ部分信頼アクセス許可セットが定義されます。 既定で、ASP.NET 4 部分信頼アプリケーション ドメインの ASP.NET ポリシー情報は、エンタープライズ レベル、コンピューター レベル、またはユーザー レベルの CAS ポリシー設定と重ならなくなりました。
グローバル CAS ポリシー (開発者が caspol.exe や Mscorcfg.msc MMC 構成ツールなどを使用して以前に管理していたポリシー) の情報が ASP.NET 4 同種アプリケーション ドメインに影響を与えることはもうありません (以前の CAS モデルを使用するように ASP.NET を構成すると、ASP.NET 設定をエンタープライズ ポリシー、コンピューター ポリシー、およびユーザー ポリシーと交差させることができます。 このレガシの動作については後のセクションで説明します)。
この変更点が特に顕著に表れているのは、UNC によってホストされる部分信頼 ASP.NET 4 アプリケーションです。 以前のリリースでは、ASP.NET 部分信頼ポリシーを有効にするために、caspol.exe を使用して UNC 共有を完全信頼に昇格させる必要がありました。 これは、旧バージョンの ASP.NET で最初に有効になるのが、既定のコンピューター レベルの CLR CAS ポリシーであったためです。 その結果、UNC によってホストされるアプリケーションのアクセス許可セットは制約され、イントラネット ゾーンに関連付けられていました。 ASP.NET 4 部分信頼アプリケーション ドメインは、ASP.NET ポリシー ファイルからしかポリシーを作成しません。そのため、Web アプリケーションの物理的な位置は、部分信頼アプリケーションに関連付けられているアクセス許可セットにまったく影響しなくなりました。
この変更の副次的な影響として、管理者は、Web サーバーをロック ダウンして、実行アクセス許可をすべてのマネージ コードに対して既定で拒否してから、選択した ASP.NET アプリケーションにのみ実行アクセス許可を付与するという操作を簡単に行えるようになりました。 旧バージョンの ASP.NET では、サポート技術情報の「FIX: Error message when you try to run an ASP.NET 2.0 Web application if you do not associate the My_Computer_Zone code group with the "full trust" permission set: "Server Application Unavailable (修正: My_Computer_Zone コード グループを "完全信頼" アクセス許可セットと関連付けない場合に、ASP.NET 2.0 Web アプリケーションを実行しようとすると表示されるエラー メッセージ: "サーバー アプリケーションを使用できません")」で説明する、あまりよく知られていない代替手段に頼る必要がありました。 ASP.NET 4 では、管理者は Web サーバーをロック ダウンして、次の手順に従って実行アクセス許可を拒否または付与できます。
すべてのコードを Nothing アクセス許可セット (空のアクセス許可セット) にマッピングするポリシー ファイルを持つ、カスタム ASP.NET 信頼レベルを作成してから、その信頼レベルを既定で使用するようにすべての ASP.NET アプリケーションを設定します (これは ルートにある Web.config ファイルで行われます)。
実行アクセス許可 (および他の必要なアクセス許可) をマネージ コードに付与する組み込みまたはカスタム信頼レベルに個々の ASP.NET アプリケーションを選択的に関連付けます。 コンピューター全体に適用する場合は、ルートにある Web.config ファイルの location 要素を使用して、信頼レベルを選択的に割り当てることができます。
信頼ポリシー ファイルの場所と名前付け規則
CAS ポリシー ファイルの場所と名前付け規則は、旧バージョンの ASP.NET と同じです。 既定の信頼レベルは Full、High、Medium、Low、および Minimal です。 High から Minimal までの部分信頼アクセス許可セットを定義するポリシー ファイルはすべて、.NET Framework インストール ディレクトリの CONFIG サブディレクトリにあります。
ポリシー ファイルには次のパターンの名前が付いています。
web_[trustlevelname]trust.config
たとえば、Medium 信頼の部分信頼アクセス許可セットは、web_mediumtrust.config という名前のファイルにあります。
ASP.NET 4 の信頼ポリシー ファイルにおける変更点
ASP.NET 4 CAS ポリシー ファイル内の情報は、以前のリリースのポリシー ファイルに含まれている情報とほとんど同じです。 ただし、.NET Framework 3.5 と .NET Framework 4 の両方に軽微な追加機能が加えられています。 同種アプリケーション ドメインに関連付けられている部分信頼アクセス許可セットの名前は ASP.Net です。 また、既定では、Web アプリケーション ディレクトリ構造またはコード生成ディレクトリ構造に含まれているすべてのコードに、名前付き ASP.Net アクセス許可セットからのアクセス許可が付与されます。
旧バージョンの部分信頼ポリシー ファイルからの変更点は次の 2 つです。
Microsoft 署名キーと ECMA 署名キーに完全信頼をマッピングする CodeGroup 要素が、各 ASP.NET 4 CAS ポリシー ファイルの末尾から削除されました。 これらのエントリは、GAC が完全信頼を持つものと暗黙的に仮定されるとは限らなかった旧バージョンからのレガシ要素であるため、ASP.NET 4 では削除されています。
SecurityPermission 属性の Assertion 部分は、どの ASP.NET 4 CAS ポリシー ファイルからも削除されました。 .NET Framework 4 で CLR によって加えられた根本的な変更点は、部分信頼コードがアクセス許可をアサートできなくなったことです。 これは、部分信頼コードが既に持っているアクセス許可をアサートしようとしただけでも、その部分信頼コードでエラーが発生することを意味します。
部分信頼のスコープ
同種アプリケーション ドメインとは、ASP.NET 4 アプリケーション ドメインの境界が部分的に信頼されていることを意味します。 アプリケーションが部分信頼で実行されている場合、セキュリティ確認要求はスタック ウォークの原因となります。 スタック上のすべてのコードが、確認要求の対象となっているアクセス許可として評価されます。 ASP.NET 3.5 以前のバージョンのアプリケーション ドメインでは、コード パスがアプリケーション ドメインの境界に至るまでのスタック ウォークの原因となることが珍しくありませんでした。 旧バージョンの ASP.NET 4 では、アプリケーション ドメインの境界が暗黙的に完全信頼であったため、コード パスによってはスタック ウォークが正常に処理される場合がありました。 ASP.NET 4 の同種アプリケーション ドメインでは、アプリケーション ドメインの境界に達したスタック ウォークはすべて、そのアプリケーション ドメインに対して現在有効になっている部分信頼アクセス許可セットを使用して評価されます。
アプリケーション ドメインの境界自体が部分信頼になったことが CAS の変更点のうちで最も一般的なものであり、ASP.NET 4 で正常に機能させるためには完全信頼コードの変更が必要となります。 たとえば、ASP.NET 開発チームがセキュリティ確認要求を抑制して、これらの要求がアプリケーション ドメインの境界まで膨れ上がることを防ぐには、対象のセキュリティ アサートを多数の内部コード パスに追加しなければなりませんでした。 開発チームがこれを行っていないと、ページ コンパイルなどの基本的な操作のセキュリティ確認要求 (コンパイルのファイル I/O アクセス許可など) は、Medium などの信頼レベルの部分信頼アクセス許可セットと比較された場合に失敗するため、これらの操作でエラーが発生していました。
ASP.NET の内部には、スタック上に ASP.NET コードしかない場合に完全信頼コードが読み込まれ、実行される原因となる拡張ポイントがあります。 このような状況では、拡張ポイントを実装するカスタム型が ASP.NET によって呼び出されたときに最初にスタックに存在するのは、ASP.NET コードだけです。 このカスタム型が完全に信頼されている場合 (型が GAC に配置されている場合にのみ起こります) は、呼び出し履歴全体が完全信頼コードで構成されるようになります。 同種アプリケーション ドメインでは、完全に信頼された拡張型がセキュリティ確認要求を発生させた場合、その要求は最終的にアプリケーション ドメインの境界に達します。 その後、この要求は、セキュリティ チェックが部分信頼アクセス許可セットに対して行われると失敗します。
次のリストは、こうした状況が起こりうる ASP.NET 拡張ポイントの例を示したものです。
カスタム HTTP ハンドラー。 カスタム ハンドラーは、パイプラインのハンドラー実行フェーズで呼び出されます。
カスタム HTTP モジュール。 カスタム HTTP モジュールは、そのモジュールが登録されているパイプライン イベントが起こるたびに呼び出されます。
カスタム ビルド プロバイダーと式ビルダー。 これらの型は、.aspx ファイルなどの実行可能コンテンツを解析およびコンパイルするときに ASP.NET によって呼び出されます。
ロール マネージャー プロバイダー。 カスタム プロバイダーは、パイプラインの AuthorizeRequest イベントの実行中に呼び出されることがあります。
プロファイル プロバイダー。 カスタム プロバイダーは、EndRequest イベントの実行中にプロファイル データを自動的に保存するために呼び出されることがあります。
状態監視プロバイダー。 カスタム プロバイダーは、蓄積された状態監視データを格納するために随時呼び出されることがあります。
カスタム HTTP ハンドラーの簡単な例で、CAS の動作の変更点を説明することができます。 次の例では、C:\ ドライブのルートにあるテキスト ファイルの読み取りがハンドラー コードによって試行されます。
Public Class CustomHandler
Implements IHttpHandler
Public Sub ProcessRequest(ByVal context As HttpContext)
Dim data As String = File.ReadAllText("c:\testfile.txt")
context.Response.Write(data)
End Sub
Public Sub New()
End Sub
Public ReadOnly Property IsReusable() As Boolean
Get
Return False
End Get
End Property
End Class
public class CustomHandler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
string data = File.ReadAllText("c:\\testfile.txt");
context.Response.Write(data);
}
public CustomHandler() { }
public bool IsReusable { get { return false; } }
}
ハンドラーが署名されて、AllowPartiallyTrustedCallersAttribute 属性でマークされ、GAC に配置されている場合に、このハンドラーが ASP.NET 3.5 以前のバージョンの Medium 信頼アプリケーションで使用されると、コードは成功します。 この例では Medium 信頼が選択されています。これは、Medium 信頼では、部分信頼アクセス許可セットがアプリケーションのディレクトリ構造に対する読み取り/書き込みファイル I/O しか許可しないからです。 この例のハンドラーのように完全に信頼されたコードは、ASP.NET 3.5 以前のバージョンの他のファイルの場所にアクセスできます。 これは、ハンドラーが実行されると、完全に信頼されたコードのみがスタックに存在し、アプリケーション ドメインの境界自体が完全に信頼されるためです。 その結果、ReadAllText 呼び出しからのファイル I/O 要求は、アプリケーション ドメインの境界が完全信頼レベルであることによって暗黙的に満たされます。
ただし、これと同じハンドラー コードが Medium 信頼の ASP.NET 4 アプリケーションで使用されている場合、ReadAllText に対する呼び出しはテキスト ファイルへの読み取りアクセスのファイル I/O 要求の原因となるため、コードは失敗します。 このファイル I/O 要求の結果、最終的にアプリケーション ドメインの境界に達するスタック ウォークが生じます。 ASP.NET 4 では、アプリケーション ドメインの境界は Medium 信頼アクセス許可セットに関連付けられており、そのアクセス許可セットは C:\ ドライブのルートへのアクセス許可を付与しません。 そのため、ファイル I/O 要求は失敗します。
ASP.NET 4 の場合は、スタック ウォークを抑制する必要があります。 これを行うには、FileIOPermission 属性の SecurityAction.Assert 属性を ProcessRequest メソッドに対して使用します。 FileIOPermission 属性をこの目的で使用する方法の例を次に示します。
[Visual Basic]
Public Class CustomHandler
Implements IHttpHandler
<FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _
Public Sub ProcessRequest(ByVal context As HttpContext)
Dim data As String = File.ReadAllText("c:\testfile.txt")
context.Response.Write(data)
End Sub
Public Sub New()
End Sub
Public ReadOnly Property IsReusable() As Boolean
Get
Return False
End Get
End Property
End Class
[C#]
public class CustomHandler : IHttpHandler
{
[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]
public void ProcessRequest(HttpContext context)
{
string data = File.ReadAllText("c:\\testfile.txt");
context.Response.Write(data);
}
public CustomHandler() { }
public bool IsReusable { get { return false; } }
}
(この例で示すように) 宣言的なアサートまたはプログラムによるアサートを使用できます。 この場合のベスト プラクティスは、コードのブロックを機能させるために必要な、最も狭い範囲のアクセス許可を宣言的にアサートすることです。 無制限のセキュリティ アサートをあらゆる場所に追加することは、単純な解決策のように思えるかもしれませんが、このアプローチに従ってはいけません。 新しい同種アプリケーション ドメインの動作に起因するセキュリティ エラーが起きた場合は、完全信頼コードを分析し、その完全信頼コードがどの特権操作を必要とするかを理解しなければなりません。 その後で、完全信頼コードを再び有効にするために必要な、最も狭い範囲のアクセス許可セットを選択的にアサートできます。
ASP.NET 4 アプリケーションを構成することによる ASP.NET 2.0 CAS モデルの使用
ASP.NET 1.0 および ASP.NET 2.0 の CAS の動作を使用するように、ASP.NET 4 アプリケーションを構成できます。 ASP.NET 4 では、trust 要素の新しい legacyCasModel 属性は既定で false に設定されています。 この属性を true に設定すると、旧バージョンからのほとんどの (すべてではありません) ASP.NET CAS の動作を使用するように ASP.NET 4 アプリケーションが構成されます。
LegacyCasModel 属性が true に設定されている場合は、次の動作が起こります。
部分信頼アプリケーション ドメインの境界が完全信頼を使用します。 つまり、完全信頼コードがスタック上の完全信頼コードだけを使用して実行されるため、セキュリティ確認要求を抑制するためにアサートを使用する必要がありません。
エンタープライズ、コンピューター、およびユーザー レベルの CAS ポリシーの設定のうち、.NET Framework 4 について定義されているものが ASP.NET CAS ポリシーと交差します。 つまり、.NET Framework 4 の caspol.exe または Mscorcfg.msc を使用して作成されたカスタム アクセス許可がすべて有効になります。
注意
.NET Framework 4 の基本セキュリティ ポリシー ファイルと caspol.exe ツールは、.NET Framework 2.0 のそれとは異なるディレクトリにあるため、.NET Framework 4 版の caspol.exe を使用して、.NET Framework 2.0 用に作成されたカスタム セキュリティ ポリシーを .NET Framework 4 用に再作成する必要があります。
異なるアセンブリに適用される複数のカスタム アクセス許可セットを指定できます。
CAS 関連の次の動作はレガシ CAS モードでも変化しません。
ASP. NET 4 アセンブリは、以前と同様に条件付き APTCA としてマークされます (条件付き APTCA については、このトピックの後の項で説明します)。 大半のパブリック ASP.NET 4 API から AspNetHostingPermission 属性を削除する必要があるため、条件付き APTCA をレガシ モードに戻すことはできません。 ASP.NET パブリック API がレガシ CAS モードで実行されているときにアクセス許可を適用して、アセンブリが新しい CAS モデルで実行されているときに適用しないようにするための効率的な方法はありません。
部分信頼コードでは、アクセス許可をアサートできなくなりました。 以前に部分信頼を付与されているコードは、Assert メソッドを呼び出して、部分信頼コードに既に付与されているアクセス許可を正常にアサートできます。 .NET Framework 4 では、ASP.NET アプリケーションについて有効な CAS モデルであるかどうかにかかわらず、部分信頼コードではセキュリティ アサートを実行できなくなりました。
レガシ CAS モデルに適用されるアクセス許可セットと新しい CAS モデルに適用される単一のアクセス許可セットを区別するため、trust 要素の LegacyCasModel 属性が true に設定されている場合、ASP.NET 4 は別の部分信頼構成ファイルのセットから CAS ポリシーを読み取ります。 ASP.NET 組み込み信頼レベルについて存在する信頼ポリシー ファイルごとに、2 つのバージョンのファイルが存在します。 ASP.NET は、一方のバージョンを新しい CAS モデル用に読み取り、もう一方のバージョンをレガシ CAS モデル用に読み取ります。 たとえば、Medium 信頼の場合は、ASP.NET 4 がレガシ モードで実行されると、legacy.web_mediumtrust.config という名前のポリシー ファイルが読み取られます。 ファイル名の始まりが "legacy" になっていることに注目してください。 ASP.NET 4 は、組み込み ASP.NET 信頼レベルの場合と同じ名前付け規則をどの CAS ポリシー ファイルに対しても使用します。 レガシと非レガシの CAS ポリシー ファイル間の最大の違いは、Microsoft 署名キーと ECMA 署名キーを参照する CodeGroup 定義がレガシ ファイルに含まれていることです。
古い CAS モデルを使用するようにアプリケーションを設定できるため、既存のアプリケーションについては、LegacyCasModel オプションを true に設定することによって、変更を一切加えないようにすることができます。 ただし、レガシ オプションの主な目的は、既存のアプリケーションの ASP.NET 4 CAS モデルへの移行を容易にすることであることを把握しておくことが重要です。 今後は、CLR チームと ASP.NET チームの両方が、新しい CAS モデルを使用した設計とコーディングに重点を置くようになります。
Silverlight 2 は、新しいモデルに移行した最初の .NET Framework の機能領域です。 .NET Framework の目標は、デスクトップとサーバーのすべての部分信頼シナリオを移行して、新しい CAS モデルで実行されるようにすることです。 そのため、マイクロソフトでは、アプリケーションを CAS モデルで再度機能させるための投資を行うことをお勧めしています。 同様に、以前に caspol.exe と Mscorcfg.msc を使用していた管理者は、ASP.NET の部分信頼ポリシー ファイルとアクセス許可の割り当てをカスタマイズすることに切り替える必要があります。
ASP.NET 4 CAS モデルにおけるアクセス許可セット割り当てのカスタマイズ
ASP.NET 同種アプリケーション ドメインでは、完全信頼または ASP.NET 部分信頼名前付きアクセス許可セットにコードが制約されますが、開発者と管理者は、アクセス許可セットをアセンブリに関連付けるプロセスに影響を与えることができます。 次のアプローチに従うと、アクセス許可セットを実行中のコードに関連付けるプロセスをカスタマイズできます。
部分信頼ポリシー ファイルは信頼レベルごとにカスタマイズできます (このアプローチは旧バージョンの ASP.NET でも可能でした)。
ASP.NET 4 完全信頼アセンブリは静的に構成できます。
ASP.NET 4 の HostSecurityPolicyResolver 型を使用すると、CLR HostSecurityManager クラスの機能に制約に基づいてアクセスできます。
最初の 2 つのアプローチでは、宣言的にカスタマイズを行うことができ、3 番目のアプローチでは、コードを使用してカスタマイズを行うことができます。
ポリシー ファイルの信頼レベルをカスタマイズ
ASP.NET 部分信頼ポリシー ファイルを編集するための最初のアプローチは、旧バージョンの ASP.NET でのアプローチと同じです。つまり、ASP.NET 名前付きアクセス許可セットに含まれているアクセス許可セットを編集できます。 また、カスタム メンバーシップ条件を持つ CodeGroup 定義を追加することもできます。 前述のように、新しい CAS のカスタマイズは、web_mediumtrust.config などの部分信頼ポリシー ファイルで行う必要があります。 ファイル名が "legacy" で始まるファイルは、trust 要素の LegacyCasModel 属性が true に設定されている場合に解析され、使用されます。
ASP.NET 4 では、すべてのカスタム CodeGroup 定義を、3 つの有効なアクセス許可セット FullTrust、ASP.Net (部分信頼アクセス許可セット)、または Nothing にマッピングする必要があります。 ASP.NET 4 部分信頼アプリケーション ドメインは既定で同種であるため、カスタム ポリシーのエントリは、制約された数のアクセス許可セットとして評価される必要があります。 ASP.NET 4 の CAS モデルを使用すると、さまざまな名前付きアクセス許可セットを定義できるように思えるかもしれませんが、FullTrust、ASP.Net、または Nothing 以外のアクセス許可セットとして評価されるコードは、ランタイム例外 SecurityException を必ず返します。 これは、評価されたアクセス許可セットが CLR によって認識されなかったことを示します。
FullTrust アクセス許可セットは、コードが完全信頼で実行されることを示します。 ASP.Net アクセス許可セットは、部分信頼アプリケーション ドメイン用に一般的に使用される、名前付き部分信頼アクセス許可セットです。 前述のように、Nothing は、CLR によって認識される実際のアクセス許可セットではなく、空のアクセス許可セットです。 アセンブリが空のアクセス許可セットに関連付けられていることが CLR によって判断された場合、CLR は SecurityException 例外をスローし、このアセンブリを読み込みません。
また、ASP.NET 4 では、trust 要素の PermissionSetName 属性を使用して、ASP.Net アクセス許可セットの名前を変更することもできます。 PermissionSetName 属性に別の名前を設定できます。 実行時に、ASP.NET 4 は、同じ名前の PermissionSet 要素を部分信頼ポリシー ファイルで検索します。 その後、この名前付きアクセス許可セットは、同種アプリケーション ドメインの部分信頼アクセス許可セットとして使用されます。 この操作が必要になることはめったにありません。 しかし、ASP.NET の既定のアクセス許可セットとは異なる独自の名前付きアクセス許可セットをエンティティとして定義する、SharePoint などのホスティング環境に対応するため、部分信頼アクセス許可セットの名前を ASP.Net 以外の値に変更する機能が追加されました (新しい CAS モデルでは、部分信頼アクセス許可を定義する名前付きアクセス許可セットを複数作成できなくなりました)。 部分信頼アクセス許可セットの名前を ASP.Net 以外の値に変更できても、アプリケーションごとに 1 つの部分信頼アクセス許可セットしか有効にできないことに変わりはありません。
完全信頼を付与されるアセンブリの指定
2 番目の宣言的なポリシーのカスタマイズは、ASP.NET 4 の新機能です。この機能を使用すると、完全信頼が常に付与されるアセンブリ ID のリストを明示的に作成できます。 securityPolicy 構成には、新しい子 fullTrustAssemblies 構成セクションが含まれています。 FullTrustAssembliesSection セクションは、追加、削除、および消去操作をサポートする標準のコレクションであり、実行時に完全信頼が付与される 1 つまたは複数のアセンブリ ID を指定できます。 次の例は fullTrustAssemblies 構成セクションを示します。
<system.web>
<securityPolicy>
<fullTrustAssemblies>
<add assemblyName="MyCustomAssembly"
version="1.0.0.0"
publicKey="a 320 hex character representation
of the public key blob used with a
signed assembly"
/>
</fullTrustAssemblies>
</securityPolicy>
</system.web>
fullTrustAssemblies 要素の各エントリは、アセンブリ名、アセンブリ バージョン、および署名キーのうち公開される方のキーの 16 進文字表現である 320 文字の文字列でアセンブリを識別します。
注意
今後、新しい .NET Framework アセンブリでは、2048 ビットの署名キーが使用される可能性があります。2048 ビットの署名キーを使用する新しいアセンブリがリリースされた場合は、長さが 576 文字の 16 進文字列が生じます。
アセンブリの場所は定義では指定されません。 アセンブリを検索して読み込む方法は、個々のホスト環境 (ASP.NET 4 など) によって異なります。 読み込まれたアセンブリが fullTrustAssemblies の add 要素のいずれかに含まれている情報と一致している場合は、完全信頼が付与されます。
GAC に配置されていないが、常に完全信頼で実行するように設計されたアセンブリに対しては、fullTrustAssemblies を使用する必要があります。 fullTrustAssemblies にリストされるアセンブリは、構成階層内の (ルートの Web.config ファイルからアプリケーション レベルの個々の Web.config ファイルに至るまでの) 任意のポイントでカスタマイズできます。そのため、部分信頼ポリシー ファイルのメンバーシップ条件とコード グループを使用するよりも、この設定を使用した方が、完全信頼の付与を簡単かつ柔軟に行うことができます。 アプリケーションごとに異なる情報を指定することにより、個々のアプリケーションの fullTrustAssemblies リストをカスタマイズできます。 この操作を行うには、アプリケーション レベルの Web.config ファイルを使用するか、または、ルートの Web.config ファイルで location 要素を使用します。
完全信頼アセンブリのセットは、部分信頼アプリケーション ドメインが作成されるとすぐに確立されます。 そのため、部分信頼ポリシー ファイルに含まれている情報が原因で、fullTrustAssemblies 要素にリストされているアセンブリに対して別の付与セットが生じる場合、その情報は無視され、アセンブリに完全信頼が付与されます。
プログラムによるアクセス許可のカスタマイズ
ASP.NET 4 HostSecurityPolicyResolver 型のカスタム実装を作成すると、アクセス許可セットとアセンブリの関連付けをプログラムによって変更することもできます。 実行時に、ASP.NET 4 は CLR HostSecurityManager 型の独自の実装を使用します。 アセンブリが読み込まれるたびに、HostSecurityManager オブジェクトが CLR によって呼び出されます。 HostSecurityManager プロパティの機能の 1 つに、指定されたアセンブリに関連付ける必要がある PermissionSet オブジェクトを証拠のために返す機能があります。 ASP.NET 4 では、CLR がアクセス許可セットの決定を ASP.NET 4 に要求するたびに、カスタム HostSecurityPolicyResolver オブジェクトを呼び出すことによって、このプロセスをカスタマイズできます。
trust 要素の HostSecurityPolicyResolverType 属性を使用すると、カスタム HostSecurityPolicyResolver オブジェクトを設定できます。 ASP.NET 4 は、カスタム HostSecurityPolicyResolver オブジェクトがアプリケーション用に設定されているものと判断した場合、CLR からアクセス許可セットの決定を求められるたびに、カスタム リゾルバーの ResolvePolicy メソッドを呼び出します。 ただし、HostSecurityManager オブジェクトと異なり、HostSecurityPolicyResolver オブジェクトが ASP.NET 4 に返すことができるのは、想定される決定のうち限られた部分だけです。 ResolvePolicy メソッドの戻り値は、HostSecurityPolicyResults 列挙型からの次のいずれかの値でなければなりません。
DefaultPolicy. これは、ASP.NET 4 がアセンブリの適切なアクセス許可セットを決定するために独自のロジックを使用する必要があることを示しています。 アセンブリのアクセス許可セットに関する決定を HostSecurityPolicyResolver オブジェクトに行わせたくない場合は、DefaultPolicy を返す必要があります。 DefaultPolicy を返すと、ASP.NET は、現在の ASP.NET 信頼レベルに対して部分信頼ポリシー ファイルで定義されている宣言的コード グループとメンバーシップ条件に基づいてアセンブリのアクセス許可付与セットを決定するようになります。
FullTrust. このアセンブリには完全信頼を付与する必要があります。
AppDomainTrust. このアセンブリには、アプリケーション ドメインと関連付けられている部分信頼アクセス許可セットを付与する必要があります。 通常、これは、名前付き ASP.Net アクセス許可セットで定義されているアクセス許可がアセンブリに付与されることを意味します。
None. このアセンブリのアクセス許可セットは、Nothing アクセス許可セットに設定されます。
基本 HostSecurityPolicyResolver クラスには、無制限のセキュリティ アクセス許可に対する継承確認要求があり、カスタム HostSecurityPolicyResolver オブジェクトは、完全信頼を確立するための別の HostSecurityPolicyResolver オブジェクトを必要とせずに読み込む必要があります。そのため、必ず HostSecurityPolicyResolver クラスの具体的な実装に署名して GAC に配置する必要があります。
次の例は、特定のディレクトリから読み込まれるすべてのアセンブリに完全信頼を付与するカスタム HostSecurityPolicyResolver オブジェクトを示しています。 このシナリオは、コンパイルされたアセンブリを (GAC ではなく) ディスク上の特定の場所に追加して、その場所のすべてのファイルを完全信頼で自動的に実行する必要がある組織に当てはまります。 ASP.NET アプリケーションが Web アプリケーションのディレクトリ構造の外部からアセンブリを読み込めるようになるには、アセンブリの ID を別の物理ディスクの場所と関連付ける明示的なアセンブリ バインディング リダイレクトを追加する必要があります。
[Visual Basic]
Public Class MyCustomResolver
Inherits HostSecurityPolicyResolver
Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
As Evidence) As HostSecurityPolicyResults
Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)()
If (urlEvidence IsNot Nothing) AndAlso _
(urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then
Return HostSecurityPolicyResults.FullTrust
End If
' Specify that ASP.NET should perform its own logic.
Return HostSecurityPolicyResults.DefaultPolicy
End Function
End Class
public class MyCustomResolver : HostSecurityPolicyResolver
{
public override HostSecurityPolicyResults
ResolvePolicy(Evidence evidence)
{
Url urlEvidence = evidence.GetHostEvidence<Url>();
if ( (urlEvidence != null) &&
(urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
)
return HostSecurityPolicyResults.FullTrust;
// Specify that ASP.NET should perform its own logic.
return HostSecurityPolicyResults.DefaultPolicy;
}
}
条件 APTCA
バージョンが 4 より前の .NET Framework では、完全に信頼されたアセンブリの多く (ASP.NET アセンブリを含む) が AllowPartiallyTrustedCallersAttribute (APTCA) 属性でマークされていました。 この属性は、このようにマークされたアセンブリで定義されているパブリック型とメンバーへのアクセス権を部分信頼の呼び出し元に与えます。 .NET Framework 4 では、条件付き APTCA と呼ばれる種類の APTCA が CLR に含まれています (条件付き APTCA の略記は C-APTCA です)。 条件付き APTCA を使用すると、APTCA 属性でマークされているアセンブリが特定のホスト環境でのみ APTCA 特性を保持できます。 そのため、条件付き APTCA を使用すると、どの部分信頼ホスト環境で部分信頼呼び出し元がパブリックの ASP.NET 4 API を正常に呼び出すことができるかを、ASP.NET 4 で正確に制御する操作を簡略化できます。
条件付き APTCA の機能
部分信頼ホスト環境と完全信頼アセンブリはいずれも、条件付き APTCA を機能させるうえで重要な役割を果たします。 アクセス許可セットが重要となる部分信頼ホスト環境は、APTCA 設定を常に有効にする必要があるアセンブリのリストを CLR に提供できます。 APTCA 特性を特定のホスト環境でしか有効にする必要がない完全信頼アセンブリは、アセンブリ レベルの次の APTCA 属性を使用してそのことを示します。
[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]
実行時に、条件付き APTCA としてマークされているアセンブリを読み込むように CLR が求められると、CLR はホスト環境から提供された有効な条件付き APTCA アセンブリのリストをチェックします。 要求されたアセンブリがリストに含まれている場合は、そのアセンブリが旧バージョンの .NET Framework で APTCA 属性でマークされているかのように、アセンブリ内のすべての公開されたコードが処理されます。
条件付き APTCA アセンブリが、APTCA として処理する必要があるアセンブリのホスト環境上のリストに含まれていない場合でも、そのアセンブリは読み込まれますが、APTCA 特性は読み込まれません。 このようなアセンブリにおいてパブリック API が部分信頼ユーザー コードで実際に使用できるかどうかは、アセンブリが完全にセキュリティ透過的であるかどうかによって決まります。 つまり、そのアセンブリがアセンブリ レベルの SecurityTransparentAttribute 属性でマークされているかどうかによって決まります (ASP.NET 4 のセキュリティ透過性については、このトピックの後のセクションで説明します)。
ASP.NET 4 におけるパブリック API の動作をまとめると、次のいずれかになります。
ほとんどの ASP.NET アセンブリの場合、いずれのパブリック API も部分信頼呼び出し元に対して利用不可になります。 これにより、ASP.NET 4 のパブリック API の大半が Web アプリケーション以外の部分信頼環境で使用されないようにすることができます。
完全にセキュリティ透過的としてマークされている ASP.NET アセンブリの中にも、部分信頼呼び出し元から呼び出すことができるものがあります。 ただし、これらのアセンブリのコード パスが ASP.NET コードベースの残りの部分に最終的に達した場合、呼び出しは失敗します。 その結果、ASP.NET 4 の API 呼び出しの方がさらに進行してから失敗するという小さな違いを除き、旧バージョンの ASP.NET リリースとほぼ同じ動作になります。
セキュリティ透過的としてマークされているアセンブリについては、以下の点に留意してください。
アセンブリ レベルでセキュリティ透過的であるとマークされている ASP.NET アセンブリは、System.Web.DynamicData.dll と System.Web.RegularExpressions.dll の 2 つだけです。
System.Web.Routing.dll は、ASP.NET 4 において完全にセキュリティ透過的ではありません。これは、旧バージョンの ASP.NET においてそのアセンブリで定義されていたすべての型が System.Web.dll に移動されたためです。 実際、ASP.NET 4 では、System.Web.Routing.dll はメタデータ専用のアセンブリになっています。
ASP.NET 4 では、別の種類の条件付き APTCA 属性が次のアセンブリで使用されています。
System.Web.dll
System.Web.Extensions.dll
System.Web.DynamicData.dll
System.Web.DataVisualization.dll
System.ComponentModel.DataAnnotations.dll
System.Web.ApplicationServices.dll。 このアセンブリは ASP.NET 4 の新機能です。
System.Web.Abstractions.dll。 このアセンブリの型は ASP.NET 4 の System.Web.dll に移動されました。
System.Web.Routing.dll。 このアセンブリの型は ASP.NET 4 の System.Web.dll に移動されました。
条件付き APTCA と ASP.NET ホスティング アクセス許可属性
条件付き APTCA を使用すると、ASP.NET 4 の 99% のパブリック API から AspNetHostingPermission 属性を効率的に削除できます。 AspNetHostingPermission 属性は ASP.NET 4 の一部でも引き続き使用されていますが、それは、アクセス許可の意図が理にかなっていない箇所に限られます。 それ以外の箇所では、AspNetHostingPermission 属性の次の 2 つの用法は廃止されています。
<AspNetHostingPermission(SecurityAction.LinkDemand,
Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
Level=AspNetHostingPermissionLevel.Minimal)>
[AspNetHostingPermission(SecurityAction.LinkDemand,
Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
Level=AspNetHostingPermissionLevel.Minimal)]
これらのアクセス許可定義は、ASP.NET アセンブリが Web 以外の部分信頼環境に読み込まれるのを防ぐ目的で旧バージョンの ASP.NET で使用されていました。 最も注意する必要がある環境は、Microsoft Internet Explorer や Mozilla Firefox などのブラウザーに読み込まれる部分信頼のマネージ コントロールとマネージ アプリケーションでした。 条件付き APTCA を使用すると、実質上同じ保護が適用されます。これは、ClickOnce アプリケーションとブラウザー ベースのマネージ コントロールでは、完全 APTCA として処理するための条件付き APTCA アセンブリが一切定義されないためです。
ASP.NET 4 条件付き APTCA リストのカスタマイズ
前述のように、個々のホスト環境は、APTCA 特性を有効にする必要がある条件付き APTCA アセンブリのリストを CLR に提供します。 ASP.NET 4 は、ハードコーディングされたすべての ASP.NET 4 アセンブリのリストを CLR に提供します。 ASP.NET 4 によってこのリストが提供されなかった場合、ASP.NET 内部コードの最初の行が部分信頼アプリケーション ドメインで実行されると、Web アプリケーションは即座に失敗します。
.NET Framework 4 では、条件付き APTCA は新しい CAS 概念であり、.NET Framework の他の部分にはまだ実装されていません。 そのため、今後のバージョンの .NET Framework では、条件付き APTCA アセンブリがさらに追加される見込みです。 また、条件付き APTCA についての知識を深め、独自の完全信頼アセンブリにそれを応用するようになるにつれ、条件付き APTCA アセンブリの数は今後増えていきます。 想定される条件付き APTCA アセンブリすべてを ASP.NET 4 が事前に把握することは不可能です。そのため、ASP.NET 4 には、条件付き APTCA アセンブリを追加できる構成セクションが用意されています。
既存の securityPolicy セクションには、partialTrustVisibleAssemblies という名前の子構成セクションがあります。 このセクションは、追加、削除、およびクリアの各操作をサポートする標準コレクションであり、(条件付き APTCA としてもマークされている場合に) APTCA として処理する必要がある 1 つまたは複数のアセンブリ ID を指定するときに使用できます。 次の例に partialTrustVisibleAssemblies セクションを示します。
<system.web>
<securityPolicy>
<partialTrustVisibleAssemblies>
<add assemblyName="MyCustomAssembly"
publicKey="a 320 hex character representation
of the public key blob used with a
signed assembly"
/>
</partialTrustVisibleAssemblies>
</securityPolicy>
</system.web>
partialTrustVisibleAssemblies セクションの各エントリはアセンブリ名でアセンブリを識別します。 各エントリは、条件付き APTCA 属性付きアセンブリで使用される署名キーの公開される方のキーの 16 進数文字表現である 320 文字の文字列 (0x03FA4D... など) でも識別されます。 バージョン属性を指定する必要はありません。 CLR で要求されるのは、アセンブリ名と公開キー トークンのみです。
条件付き APTCA アセンブリを有効にする場合にパフォーマンスに関連して注意すべき点は、条件付き APTCA アセンブリの推移的閉包も有効にする必要があるということです。 たとえば、条件付き ATPCA アセンブリ A が ATPCA アセンブリ B に依存しており、ATPCA アセンブリ B が条件付き ATPCA アセンブリ C に依存している場合に A の条件付き ATPCA を有効にしたら、C の条件付き ATPCA も有効にする必要があります。 そうしないと、アプリケーションのパフォーマンスが低下する可能性があります。 たとえば、条件付き ATPCA の完全なクロージャが有効になっていない場合、コード共有と NGen イメージは無効になります。
条件付き APTCA が Web 以外の部分信頼アプリケーションに与える影響
ASP.NET 4 より前のバージョンの ASP.NET では、一部の型と名前空間が AspNetHostingPermission 属性でマークされていませんでした。 このため、ClickOnce アプリケーションなどの ASP.NET 以外の部分信頼環境からこれらの型を呼び出すことができました。 この方法で呼び出すことができた型と名前空間は次のとおりです。
System.Web.ClientServices 名前空間の型。
HttpUtility 型。
System.Web.ClientServices 型は、ClickOnce などの .NET Framework 4 の部分信頼環境では使用できません。 コンテナー アセンブリ (System.Web.Extensions.dll) は条件付き APTCA としてマークされている ASP.NET 4 アセンブリであり、ClickOnce では条件付き APTCA アセンブリに対して APTCA を使用できないため、部分信頼 ClickOnce アプリケーションから呼び出すことができるクライアント サービスの型はありません。
この動作には次のようないくつかの理由があります。 まず、.NET Framework 4 はクライアントと拡張 SKU に分離され、多くの ClickOnce アプリケーションがクライアント SKU を対象にするものと仮定されています。 そのため、ASP.NET クライアント サービス型をクライアント SKU にリファクターするには、多大な労力が必要となります。
次に、必要な条件付き APTCA 境界を維持しながらクライアント型をリファクターする方法を決定することは容易ではありません。 そのため、.NET Framework 4 では、クライアント サービス型を使用できるのが ASP.NET 以外の完全信頼環境のみに限定されています。これには、拡張 .NET Framework 4 SKU を使用して完全信頼で実行されるように構成されている ClickOnce アプリケーションが含まれます。
HttpUtility 型の場合、条件付き APTCA の影響は、どのメソッドを使用しているかによって次のように異なります。
部分信頼コードが WebUtility クラスの HtmlEncode メソッドまたは HtmlDecode メソッドを呼び出していたとします。 WebUtility 型には、ASP.NET の HTML エンコードおよびデコードの実装が含まれていますが、これらはリファクターされて System.Net 名前空間に移動されており、この名前空間は System.dll に含まれています。 System.dll は部分信頼のどのホスト環境でも使用できるため、WebUtility 型のメソッドは ASP.NET 以外の部分信頼アプリケーションに問題なくアクセスできます。
部分信頼コードが WebUtility クラスの上記以外のメソッドを呼び出していたとします。 クライアント サービス型について前述した問題は、この場合にも当てはまります。 つまり、WebUtility は、.NET Framework 4 の ASP.NET 以外の完全信頼呼び出し元しか使用できません。
ASP.NET 4 のセキュリティ透過性
セキュリティ透過性を使用すると、セキュリティに対する配慮が必要な操作をコード ブロックによって実行するかどうかを CLR に対して示すことができます。 透過的なコードでは、アクセス許可のアサート、リンク確認要求への対応、検証できないコードの格納、ネイティブ コードの呼び出し、セキュリティ上重要なコードの呼び出しなどの操作を行うことはできません。 このことは、透過的コードが完全に信頼されているか (GAC の場合など)、部分的に信頼されているかどうかにかかわらず当てはまります。
セキュリティ透過性は、ASP.NET をはじめとした .NET Framework の要素に備わった強力な機能の 1 つです。 この機能を使用すると、ASP.NET は、ASP.NET コードの一部がアクセス許可をアサートしないことや、セキュリティに対する配慮が必要な操作 (ネイティブ コードに対する PInvoke 呼び出しなど) がコードによって実装または実行されないことを、CLR に対して示すことができます。 これにより、完全に信頼された GAC に .NET Framework コードが配置されている場合でも、パブリックおよび内部の多数の API がセキュリティ リスクにさらされる危険性を大幅に緩和できるようになります。
セキュリティ透過性は、アセンブリ全体に適用するか、アセンブリ内のコードのサブセットのみに適用できます。 セキュリティ透過性でアセンブリ全体をマークすることは理想的ですが、.NET Framework コードの中には、セキュリティに対する配慮が必要な操作を実行することを正当な要件として持つものがあります。 完全にセキュリティ透過的なコードを含んでいるアセンブリは、アセンブリ レベルの SecurityTransparentAttribute 属性を使用してマークされます。
透過的なコードと非透過的なコードが混在したアセンブリは、アセンブリ レベルの透過性属性を持ちません。 その代わり、SecuritySafeCriticalAttributel 属性または SecurityCriticalAttribute 属性を使用して、アセンブリ内の個々のクラスにマークが付けられます。
属性のないクラスの動作は複雑です。 ただし、単純な条件の下では、ASP.NET 4 アセンブリの型のうち、属性を持たないが、新しい透過性モデルを採用している型がセキュリティ透過的であると見なされます。 ASP.NET 4 アセンブリの型のうち、属性を持たず、新しい透過性モデルを採用していない型は、セキュリティ セーフ クリティカルであると見なされます。
セキュリティ透過性の実際とセキュリティ規則セット
ASP.NET 4 コード ベースの大部分が System.Web.dll に含まれているため、ASP.NET 4 のすべてのコードを新しい透過性モデルに変換することは実践的ではありませんでした。 その代わり、ASP.NET 4 コードは次のカテゴリに分類できます。
新しい透過性モデルを採用しなかったコード。次のアセンブリのコードが含まれます。
System.Web.dll
System.Web.ApplicationServices.dll
System.Web.Mobile.dll。 このアセンブリの型は、ASP.NET 4 では互換性確保のために残されています。 このアセンブリは引き続き提供されていますが、アセンブリの型をいずれは使用しなくなるようにしてください。
新しい透過性モデルを使用するコード。次のアセンブリのコードが含まれます。
System.Web.Extensions.dll
System.Web.DynamicData.dll (完全にセキュリティ透過的)
System.Web.RegularExpressions.dll (完全にセキュリティ透過的)
System.ComponentModel.DataAnnotations.dll
System.Web.DataVisualization.dll
型が別の ASP.NET アセンブリに移動されたメタデータのみのアセンブリ。次のアセンブリが含まれます。
System.Web.Abstractions.dll。 旧バージョンの ASP.NET のこのアセンブリに含まれていた型は、System.Web.dll に移動されました。 その結果、Sytem.Web.Abstractions.dll は、ASP.NET 4 ではメタデータ専用のアセンブリになっています。
System.Web.Routing.dll。 旧バージョンの ASP.NET のこのアセンブリに含まれていた型は、System.Web.dll に移動されました。 その結果、System.Web.Routing.dll は、ASP.NET 4 ではメタデータ専用のアセンブリになっています。
.NET Framework 4 では、セキュリティ規則セットと呼ばれる新しい概念が CLR によって導入されました。 SecurityRuleSet 設定には、レベル 1 とレベル 2 という 2 つのレベルがあります。 どの型の SecurityRuleSet 設定も、アセンブリ レベルの SecurityRulesAttribute 属性を使用して指定されます。 新しい透過性モデルを採用している ASP.NET 4 アセンブリには、次のアセンブリ レベル属性を使用したマークが付けられます。
System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)
.NET Framework 2.0 からの透過性モデルを使用する ASP.NET 4 アセンブリには、次のアセンブリ レベル属性を使用したマークが付けられます (ASP.NET 4 より前のバージョンの ASP.NET は透過性の概念をまったく使用しなかったため、実質的に透過性がないことを意味します)。
System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)
新しい透過性モデルを採用している ASP.NET アセンブリ (およびそれらのアセンブリに含まれているパブリック型) では、大半のコードがセキュリティ透過的であると見なされます。 これらのアセンブリに含まれているごく一部のコードは、セキュリティに対する配慮が必要な操作を実行するため、セーフ クリティカルまたはクリティカルなコードとしてマークされます。
新しい透過性モデルを採用していない ASP.NET アセンブリ (互換性確保の目的で残されているアセンブリや型リダイレクト アセンブリを除く) の場合は、すべてのパブリック API を部分信頼ユーザー コードから呼び出すことができ、セキュリティに対する配慮が必要な操作を内部で実行できます。 部分信頼呼び出し元に対するアクセスが可能であり、かつセキュリティに対する配慮が必要な操作が実行される可能性があることから、古い ASP.NET 4 コードは厳密に検査する必要があります。 ただし、ASP.NET の新機能のほとんどは、System.Web.Extensions.dll や System.Web.DynamicData.dll などの新しいアセンブリで実装されているか、ASP.NET MVC などの別のリリースで実装されています。そのため、ASP.NET の新しいコードの大半がセキュリティ透過的であり、古いコードより既定で安全性が高くなっています。
既定で、SecurityRuleSet.Level1 としてマークされている ASP.NET 4 アセンブリのパブリック API は、ホスティング環境がその APTCA 属性を有効にしていれば、CLR によってセーフ クリティカルとして処理されます (SecuritySafeCriticalAttribute 属性でマークされることに相当)。 APTCA が有効になっていない場合、CLR は完全信頼のリンク確認要求を発生させます。この要求は、部分信頼ユーザー コードがスタック上にある場合に失敗します。 言い換えれば、SecurityRuleSet.Level1 としてマークされている ASP.NET アセンブリに対して APTCA が有効になっていない場合に、APTCA 属性でマークされていない完全信頼アセンブリを部分信頼コードが呼び出そうとすると、.NET Framework の動作は以前のリリースと同じになります。
既定で、SecurityRuleSet.Level2 としてマークされている ASP.NET 4 アセンブリのパブリック API は、ホスティング環境がその APTCA 属性を有効にしていれば、CLR によってセキュリティ透過的として処理されます (SecurityTransparentAttribute 属性でマークされることに相当)。 それ以外の場合の動作は次のように定義されます。
APTCA が有効になっておらず、Level2 としてマークされているアセンブリが完全にセキュリティ透過的ではない場合、パブリック アクセス機能は CLR によってセキュリティ クリティカルとして処理されます。 そのため、部分信頼呼び出し元がこのパブリック アクセス機能を使用しようと試みると、エラーが発生し、MethodAccessException、TypeAccessException、または FieldAccessException の例外が発生する可能性があります。
APTCA が有効になっておらず、Level2 としてマークされているアセンブリが完全にセキュリティ透過的である場合、部分信頼呼び出し元はこのアセンブリの任意のパブリック API を正常に呼び出すことができます。 これは、完全にセキュリティ透過的なアセンブリが、完全にセキュリティ透過的ではないレベル 1 の ASP.NET アセンブリまたはレベル 2 の ASP.NET アセンブリを後で呼び出したときに、コール パスで SecurityException 例外が発生することを意味します。
透過性と ASP.NET のコンパイル
ASP.NET 4 が新しい CAS モデルと新しいセキュリティ透過性モデルの両方を採用したことは、ASP.NET コンパイル システムによって作成される出力にも影響を与えています。 影響を受ける箇所としては、ページ アセンブリ、プリコンパイル アセンブリ、App_Code ディレクトリのコンパイル結果などが挙げられます。 コンパイル システムの動作は、trust 要素の LegacyCasModel 属性の設定によって異なります。
次の表では、レガシの CAS モデルと新しい CAS モデルの両方でコンパイル対象オブジェクトがどのように動的にマークされるかを説明しています。
legacyCasModel 属性の設定 |
Web サイトの信頼レベル |
コンパイル対象アセンブリに適用される属性 |
|---|---|---|
False (新しい CAS モデル) |
完全信頼 |
SecurityRules(SecurityRuleSet.Level2) |
High 以下の信頼 |
SecurityRules(SecurityRuleSet.Level2) |
|
SecurityRules(SecurityRuleSet.Level2) |
||
True (古い CAS モデル) |
完全信頼 |
SecurityRules(SecurityRuleSet.Level1) |
High 以下の信頼 |
SecurityRules(SecurityRuleSet.Level1) |
ASP.NET 4 のコンパイル システムの動作は、trust 要素の LegacyCasModel 属性の設定によって決まります。そのため、複数の部分信頼 ASP.NET 4 アプリケーションにわたってコンパイル済みコードを共有する方法には、いくつかの制約が課されることがあります。 通常、アプリケーションの動作は変わりません。 ただし、部分信頼アプリケーションの LegacyCasModel 属性が false に設定されている場合 (つまり、新しい CAS モデルを使用する場合)、このアプリケーションから作成されたコンパイル済み成果物は、他のアプリケーションと共に使用するときに予想どおりに機能しないことがあります。 そのため、コンパイル済み .ascx コントロールが署名され、ATPCA の属性を設定されて、GAC に配置された状態で共有ライブラリに収録されている場合などの一部の状況では、Level2 を使用してこのライブラリにマークを付けるときに、セーフ クリティカル属性とクリティカル属性を一部のコードに明示的に適用することが必要となる可能性があります。