トピック

 モジュールの内容
 目的
 適用対象
 モジュールの使用方法
 コード アクセス セキュリティの説明
 APTCA
 権限コード
 アクセス許可を要求する
 コードを認証する
 リンク要求
 Assert および RevertAssert
 コードを制約する
 ファイル I/O
 イベント ログ
 レジストリ
 データ アクセス
 ディレクトリ サービス
 環境変数
 Web サービス
 ソケットと DNS
 アンマネージ コード
 代理人
 シリアル化
 要約
 その他のリソース

モジュールの内容

コード アクセス セキュリティは、コードがアクセスできるシステム リソースの種類およびコードが実行できる権限操作の種類を制限するように設計されたリソース制約モデルです。これらの制限は、コードまたはコードを実行するユーザー アカウントを呼び出すユーザーに依存しません。モジュールは、コード アクセス セキュリティがどのように機能するのかについての詳しい説明で始まり、コード アクセス セキュリティのアクセス権限のアサート、要求、許可が可能なすべてのリソースの処理例を挙げます。

このモジュールにより、ポリシー評価、ポリシー レベル、APTCA、権限コード、アクセス許可要求、コード認証、リンク要求、およびアサートを含むコード アクセス セキュリティの内部処理について理解できるようになります。

このモジュールでは、コード アクセス セキュリティの 3 つの重要な利点を説明して、次の処理に対するコード アクセス セキュリティの使用方法を示します。

• コードができることを制限する
  たとえば、ファイル I/O を処理するアセンブリを開発する場合、コード アクセス セキュリティを使用して、特定のファイルやディレクトリへのアクセスを制限できます。これにより、攻撃者によって任意のファイルにコードがアクセスする機会が減ります。

• コードを呼び出すコードを制限する
  たとえば、組織で開発された別のコードのみでアセンブリを呼び出す必要がある場合があります。これを行う 1 つの方法は、この種の制限を適用する厳密な名前のアセンブリの公開キー コンポーネントを使用します。これは、悪意のあるコードが使用コードを呼び出すことを防ぐのに役立ちます。

• コードを識別する
  コード アクセス セキュリティ ポリシーを適切に管理してコードが可能な処理を制限するには、コードが識別可能でなければなりません。コード アクセス セキュリティは、アセンブリの厳密な名前や URL、処理されたハッシュなどのエビデンス (証拠) を使用して、コード (アセンブリ) を識別します。

目的

このモジュールの目的は次のとおりです。

• コード アクセス セキュリティがどのように動作するのか、および権限を持つコードがどれであるのかについて学習する。

• ファイル I/O、データ アクセス、イベント ログ、レジストリ、ディレクトリ サービス、環境変数、Web サービス、ソケット、および DNS の実行に必要な制約コードにコード アクセス セキュリティを使用する。

• 安全で効率的に APTCA を適用する。

• アクセス許可を要求して、コードを許可する。

• 権限コードをサンドボックスする。

• リンク要求を使用する場合としない場合を確認する。

• アクセス許可要求をアサートする場合としない場合を確認する。

• アクセス許可要求および要求を効果的に使用する。

• コード アクセス セキュリティを使用し、シリアル化および委任を使用してアンマネージ コードを呼び出すセキュリティを向上させる。

適用対象

このモジュールは、次の製品およびテクノロジに適用されます。

• Microsoft Windows Server 2000 および 2003

• Microsoft .NET Framework 1.1

• ASP.NET 1.1

モジュールの使用方法

このモジュールは、モジュール 7 「セキュリティ保護されたアセンブリを構築する」の続きです。コード アクセス セキュリティを使用してマネージ コードのセキュリティを向上させる方法について説明します。このモジュールから最大限の成果を得るには、次のリソースを参照してください。

• ユーザーまたはコード アクセス セキュリティに対するロールベース セキュリティの概要と比較については、モジュール 6 「.NETセキュリティの概要」を参照してください。モジュール 6 では、このモジュールの背景について説明しています。

• モジュール 7 「セキュリティ保護されたアセンブリを構築する」を参照してください。準備ができていない場合は、モジュール 7 を先に参照してください。

• モジュール 9 「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。このモジュールを終了した後、ASP.NET コード アクセス セキュリティ ポリシーおよび ASP.NET 信頼レベルについて参照する場合は、モジュール 9 を参照してください。

コード アクセス セキュリティの説明

コード アクセス セキュリティを効果的に使用するには、専門用語やポリシーの評価方法などの基本を理解している必要があります。コード アクセス セキュリティの背景の詳細情報については、このモジュールの最後の「その他のリソース」を参照してください。コード アクセス セキュリティについて詳しい知識を持っている場合は、このセクションをとばして、このモジュールの後の「APTCA」(AllowPartiallyTrustedCallersAttribute) に進んでください。

コード アクセス セキュリティは、次の要素で設定されています。

• コード

• エビデンス

• アクセス許可

• ポリシー

• コード グループ

コード

マネージ コードはすべてコード アクセス セキュリティによって決まります。アセンブリが読み込まれると、どのリソースの種類にアクセスできるのかと、どの権限操作を実行できるのかを決めるコード アクセスのアクセス許可のセットが付与されます。Microsoft .NET Framework セキュリティ システムはエビデンスを使用して、アクセス許可を付与するコードを識別します。

注: アセンブリは、コード アクセス セキュリティの設定と信頼の単位です。同一のアセンブリ内のコードにはすべて、同じアクセス許可が付与されるため、信頼のレベルも同じです。

エビデンス

エビデンスは、アセンブリを識別する .NET Framework セキュリティ システムにより使用されます。コード アクセス セキュリティ ポリシーは、適切なアクセス許可を適切なアセンブリに付与するのに役立つエビデンスを使用します。場所関連のエビデンスは次のとおりです。

• URL: アセンブリを取得した URL です。これは、raw 形式のコードベースの URL です。たとえば、http://webserver/vdir/bin/assembly.dll や file://C:/directory1/directory2/assembly.dll です。

• サイト: アセンブリを取得するサイト、たとえば http://webserver などです。そのサイトはコードベース URL から派生しています。

• アプリケーション ディレクトリ: 動作しているアプリケーションのベース ディレクトリです。

• ゾーン: そのゾーンからアセンブリを取得します。たとえば、LocalIntranet やインターネットなどが含まれます。また、ゾーンはコードベース URL から派生します。

作成者関連のエビデンスは次のとおりです。

• 厳密な名前: 厳密な名前を持つアセンブリに適用されます。厳密な名前は、秘密キーを使用してアセンブリをデジタル署名する 1 つの方法です。

• 発行者: 開発組織を現す、署名コードに使用される X.509 証明書に基づいた Authenticode 署名です。

  重要: 発行者証明 (Authenticode 署名) は ASP.NET ホストにより無視されるため、これを使用してサーバー側 Web アプリケーションのコード アクセス セキュリティ ポリシーを設定できません。このエビデンスは、主に Internet Explorer のホストにより使用されます。

• ハッシュ: アセンブリ ハッシュはアセンブリのコンテンツ全体をベースにしており、バージョン番号に依存しない特定のコードのコンパイルを検出できます。これはサード パーティ アセンブリの変更時の検出に便利で、ビルドに対する使用をテストしたり、許可したりしていません。

アクセス許可

アクセス許可とは、コードがセキュリティで保護されたリソースにアクセスしたり、権限操作を実行したりする権限のことです。.NET Framework により、"コード アクセスのアクセス許可" および "コード ID アクセス許可" が提供されます。コード アクセスのアクセス許可は、特定のリソースにアクセスしたり、実行したりする機能をカプセル化します。コード ID アクセス許可を使用して、厳密な名前などの呼び出しコードの ID に基づいてコードへのアクセスを制限します。

管理者によって設定されたコード アクセス セキュリティ ポリシーがコードにアクセス許可を付与します。アセンブリにより、アクセス許可の要求を使用して最終的に付与されるアクセス許可のセットにも影響が及ぼされます。同時に、コード アクセス セキュリティ ポリシーとアクセス許可要求は、コードが何をできるのかを決定します。たとえば、ファイル システムにアクセスするにはコードに FileIOPermission を付与し、レジストリにアクセスするにはコードに RegistryPermission を付与しなければなりません。アクセス許可要求の詳細情報については、後述の「アクセス許可を要求する」を参照してください。

注: アクセス許可のセットをグループ アクセス許可に使用すると、管理が容易になります。

制限付きと制限なしのアクセス許可

アクセス許可は "制限付き" にすることも、"制限なし" にすることも可能です。たとえば、制限なしの状態では、FileIOPermission を使用して、コードはファイル システムの任意の部分の読み込みや書き込みを行うことができます。制限付きの状態では、特定のディレクトリからのみファイルを読み込むことが可能です。

要求

.NET Framework クラス ライブラリからクラスを使用してリソースにアクセスしたり、他の権限操作を実行したりする場合、クラスにより、各自のコードおよびそのコードから呼び出されるコードにリソースにアクセスする権限を付与するアクセス許可要求が発行されます。アクセス許可要求により、スタック内の呼び出しのアクセス許可を検査するときに、コール スタックを通じてバック アップをウォークするランタイムが発生します (スタック フレームごとに)。必要なアクセス許可を持たない任意の呼び出しが発見された場合、SecurityException がスローされます。

リンク要求

リンク要求は完全なスタック ウォークを実行しないで、コール スタックの後ろの1 つのスタック フレーム、即時呼び出しのチェックのみ行います。この結果、リンク要求に関連するセキュリティ リスクが増えます。おとり攻撃に対して特別な機密性が必要です。

注: おとり攻撃により、悪意のあるコードが、中程度に信頼されたアセンブリを介してコードを呼び出すことにより、アセンブリによってさらされるリソースと操作にアクセスします。

リンク要求を正しく使用する方法についての詳細情報は、このモジュールの後の「リンク要求」を参照してください。

Assert、Deny、および PermitOnly メソッド

コード アクセスのアクセス許可のクラスは Assert、Deny、および PermitOnly メソッドをサポートしています。これらのメソッドを使用して、スタック ウォークを要求するアクセス許可の動作を変更できます。それらは、"スタック ウォーク修飾子" といいます。

Assert への呼び出しはアクセス許可の一致のためのスタック ウォークの原因となり、Assert 呼び出しのサイトで停止します。これは、権限コードをサンドボックスするために最も頻繁に使用されます。詳細情報については、このモジュールで後述する「Assert および RevertAssert」を参照してください。

Deny メソッドへの呼び出しが、アクセス許可の一致で到達するスタック ウォークに失敗します。一部の信頼のないコードを呼び出す場合、Deny メソッドを使用して呼び出すコードの機能を制約できます。

PermitOnly メソッドへの呼び出しがスタック ウォークの非対応に失敗します。Deny メソッドのように、あまり頻繁に使用されませんが、これを使用して、呼び出す一部の信頼されていないコードの操作を制約できます。

ポリシー

コード アクセス セキュリティ ポリシーは管理者により設定され、アセンブリに付与されるアクセス許可を決定します。ポリシーは次の 4 レベルで確立できます。

• エンタープライズ: エンタープライズ全体のポリシーに適用するために使用されます。

• マシン: マシンレベルのポリシーに適用するために使用されます。

• ユーザー: ユーザー ポリシーに適用するために使用されます。

• アプリケーション ドメイン: アセンブリが読み込まれるアプリケーション ドメインを設定するために使用されます。

  ASP.NET がアプリケーション Domain Policy を実装すると、Web アプリケーションおよび Web サービスにコード アクセス セキュリティ ポリシーを設定できるようになります。ASP.NET アプリケーション Domain Policy についての詳細情報は、モジュール 9 「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

ポリシーの設定は XML 設定ファイルで維持されます。ポリシーの最初の 3 つのレベル (エンタープライズ、マシン、およびユーザー) は、管理ツールのプログラム グループまたは Caspol.exe コマンド ライン ユーティリティにある .NET Framework 設定ツールを使用して設定されます。ASP.NET アプリケーション ドメイン レベル ポリシーをテキストまたは XML ベースのエディタで編集する必要があります。

ポリシー ファイルと場所に関する詳細情報については、モジュール 19 「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。

コード グループ

各ポリシー ファイルには、コード グループの階層コレクションが含まれています。コード グループを使用して、アセンブリにアクセス許可を割り当てます。コード グループは次の 2 つの要素で設定されています。

• メンバシップの条件: これはエビデンス ベースにしています。たとえばアセンブリのゾーンや厳密な名前などです。

• アクセス許可のセット: アクセス許可のセットに含まれているアクセス許可は、メンバシップの条件に一致するエビデンスを持つアセンブリに付与されます。

動作の様子

図 8.1 はコード アクセス セキュリティの概略を示しています。

図 8.1
コード アクセス セキュリティ – 概略図

次に、図 8.1 の処理を示します。

1. アセンブリが読み込まれます。

   この処理は、アプリケーション ドメイン ホストにより実行されます。Web アプリケーション アセンブリを読み込む Web サーバーでは、これが ASP.NET ホストに該当します。

2. エビデンスは、アセンブリによって収集されたり、ホストによって付与されます。

3. エビデンスは、定義されたセキュリティ ポリシーに照らし合わせて評価されます。

4. セキュリティ ポリシーの評価からの出力は、1 つ以上の名前付きのアクセス許可セットで、このセットによりアセンブリに付与するアクセス許可が定義されます。

   注: アセンブリは、アクセス許可の付与を減らすアクセス許可要求を含むことが可能です。

5. アセンブリ内のコードは、制限されたリソースにアクセスしたり、権限操作を実行したりする前にアクセス許可を要求します。

   .NET Framework は、リソースにアクセスするクラスまたは適切なアクセス許可要求を含む権限操作を実行するクラスのベースになります。たとえば、FileStream クラスは、FileIOPermission、RegistryPermission を要求する Registry クラスなどを要求します。

6. アセンブリ (とその呼び出し) に要求されたアクセス許可が付与されている場合、その処理は実行できます。そうでない場合は、セキュリティ例外が生成されます。

ポリシーの評価方法

ポリシー エンジンを介してエビデンスが実行される場合、出力はアクセス許可セットで、そのセットによりアセンブリに付与されたアクセス許可のセットが定義されます。ポリシーの付与は、次のポリシー階層の各レベルで計算されます。エンタープライズ、マシン、ユーザー、およびアプリケーション ドメイン。各レベルからの結果のポリシー付与は、最終的なポリシー付与を行う共通集合の処理を使用して結合されます。共通集合を使用して、高いレベルによって付与されない低い階層におけるポリシーがアクセス許可を追加できないことが確実になります。これにより、個々のユーザーまたはアプリケーション ドメインに、エンタープライズ管理者によって付与されていないアクセス許可が追加されることを防ぎます。

図 8.2 は、共通集合処理により、どのように結果のアクセス許可の付与がポリシー階層におけるすべてのレベルのポリシーにより決まるのかを示しています。

図 8.2
ポリシー レベルの共通集合

図 8.2 で、共通集合処理により、各レベルによって付与されたアクセス許可が最終的なアクセス許可の一部を設定するようになる様子を参照できます。

アクセス許可要求がポリシー付与に影響を付与する様子

セキュリティ属性をアセンブリに追加して、アクセス許可の要件を指定できます。実行のために、アセンブリに付与するアクセス許可の最小限のセットを指定できます。これらは、アクセス許可の付与に影響を及ぼしません。アセンブリが使用しますが、必須ではないオプションのアクセス許可、およびどのアクセス許可を拒否するのかも指定できます。拒否されたアクセス許可は、たとえセキュリティ ポリシーによって付与されても、アセンブリが決して持たないアクセス許可です。

オプションのアクセス許可を要求する場合、結合されたオプションおよび最小限のアクセス許可がポリシー付与と重なり、さらに減らされます。さらに、明確に拒否されたアクセス許可はポリシー付与から削除されます。これは、PG が管理者からのポリシー付与である次の式で示されます。

アクセス許可の付与の結果 = (PG ∩ (P min U Popt)) - Prefused

アクセス許可要求の使用方法、それらの影響、およびそれらを使用時に関する詳細情報については、このモジュールで後述する「アクセス許可を要求する」を参照してください。

ポリシー レベルでのポリシー評価

特定のレベルの個々のポリシー ファイルは、コード グループの階層的な配置から設定されます。これらのコード グループは、どのアセンブリに適用するのかを決めるために使用されるメンバシップ条件、および一致するアセンブリに付与されるアクセス許可を決定するために使用されるアクセス許可のセットを含んでいます。階層的な構造により、複数のアクセス許可のセットがアセンブリに割り当てられ、セキュリティ ポリシーが簡単な AND と OR のロジックをサポートできるようになります。たとえば、図 8.3 に示されたセキュリティ ポリシーの例について考えます。

図 8.3
1 つのポリシー レベルの階層コード グループ

注: "すべてのコード" コード グループは、すべてのアセンブリに一致する特別なコード グループです。セキュリティ ポリシーのルートを作成し、それ自身にアクセス許可を付与しません。"Nothing" の名前の付いたアクセス許可のセットと関係するからです。

図 8.3 で示されているセキュリティ ポリシーをベースにしたアクセス許可について考えます。

• My_Computer_Zone によって作成された任意のアセンブリ (ローカルにインストールされたアセンブリ) に、"完全な信頼" のアクセス許可のセットによって定義されたアクセス許可を付与します。これは、.NET Framework のインストール時に定義されたビルトインのアクセス許可のセットで、すべてのアクセス許可の制限なしのセットを表しています。

• Company1 によって作成されたアセンブリおよびインターネット ゾーンから作成されたアセンブリに、ビルトイン LocalIntranet_Zone アクセス許可セットとカスタム Comp1PSet アクセス許可セットにより定義されたアクセス許可を付与します。

• Company2 によって作成されたアセンブリに、カスタム Comp2PSet アクセス許可セットにより定義されたアクセス許可を付与します。

• a.b.c.com からダウンロードした任意のアセンブリにカスタム ABCPSet アクセス許可セットにより定義されたアクセス許可を付与します。

注: コード グループのメンバシップ条件が満たされていない場合、その子はだれも評価されません。

排他的なコード グループおよび最終レベルのコード グループ

コード グループ レベルで指定された 2 つの属性を使用して、ポリシー階層の処理とトラバースを微調整できます。この 2 つの属性は、.NET Framework 設定ツールにより設定できます。次のとおりです。

• 排他的
  このコード グループと結合する他の兄弟コード グループがないことを示しています。.NET Framework 設定ツールの [このポリシーレベルはこのコード グループに関連するアクセス許可セットからのアクセス許可のみを持つ] を選択してコード グループを "排他的" としてマークします。

• 最終レベル
  これより低いレベルのポリシーを無視することを示しています。.NET Framework 設定ツールの [このレベル以下のポリシーレベルは評価しない] を選択してコード グループを "最終レベル" としてマークします。たとえば、マシン ポリシーの一致するコード グループを "最終レベル" にマークする場合、ユーザー ポリシー ファイルからのポリシー設定は無視されます。

  注: アプリケーション ドメイン レベル ポリシー、たとえばサーバー側 Web アプリケーションの ASP.NET ポリシーは常に最終レベル設定にかかわらず評価されます。

APTCA

厳密な名前を持つアセンブリは、厳密な名前のアセンブリが次の AllowPartiallyTrustedCallersAttribute (APTCA) を含んでいない場合は、部分的に信頼されたアセンブリ (完全な信頼を付与されていないアセンブリ) で呼び出せません。

[assembly:AllowPartiallyTrustedCallersAttribute()]

これはリスクを軽減する方法で、コードが不注意で部分的に信頼されたコード (悪意のある可能性のある) にさらされないように設計されています。共通言語ランタイムが、厳密な名前のアセンブリの公開アクセス可能メンバーに FullTrust アクセス許可セットのリンク要求をサイレントで追加します。APTCA を含んでいると、このリンク要求は中断されます。

APTCA の使用を避ける

APTCA を使用すると、コードは即座に攻撃を受けやすくなるため、セキュリティの脆弱性についてコードを見直すことが必要になります。本当に必要な場所でのみ、APTCA を使用します。

サーバー側の Web アプリケーションのコンテキストでは、アセンブリが部分的な信頼の呼び出しをサポートする必要のある場合に APTCA を使用します。この状況は、次のような場合に発生します。

• アセンブリが部分的に信頼された Web アプリケーションにより呼び出されます。これらは、<trust> レベルが Full 以外に設定されるアプリケーションです。部分的に信頼された Web アプリケーションおよびこのような場合の APTCA の使用についての詳細情報は、モジュール 9 「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

• アセンブリは、コード アクセス セキュリティ管理者により制限されたアクセス許可を付与する他のアセンブリによって呼び出されます。

• アセンブリは、SecurityAction.RequestRefuse または SecurityAction.RequestOptional を使用して、特定のアクセス許可を拒否する他のアセンブリによって呼び出されます。これらにより、呼び出しアセンブリを部分的に信頼されたアセンブリに設定します。

• アセンブリは、スタック ウォーク修飾子 (Deny や PermitOnly など) を使用してダウンストリーム コードを制約する別のアセンブリによって呼び出されます。

APTCA 問題を診断する

部分的な信頼の Web アプリケーションなどの部分的な信頼のコードから APTCA でマークされていない厳密な名前のアセンブリを呼び出そうとする場合、図 8.4 で示されているものと同じ例外を参照します。例外の詳細によりアクセス許可の詳細が提供されず、必要なアクセス許可 (この場合は FullTrust) が呼び出しアセンブリから取得できないことが簡単に示されることに注意してください。この場合、アプリケーションの <trust> レベルは Full 以外に設定したため、分りにくい説明のテキストはエラーが発生したことを意味しています。

図 8.4
部分的に信頼されたコードが厳密な名前のコードを呼び出した結果

この例外を解決するには、呼び出しコードに FullTrust を付与するか、呼び出されるアセンブリに APTCA でコメントを付ける必要があります。次の例で示されるように、明示的なリンク要求または完全な信頼に対する標準的な要求が含まれるため、APTCA でマークされたアセンブリ内の個々の種類がまだ完全な信頼の呼び出しを必要としていることに注意します。

[PermissionSet(SecurityAction.LinkDemand, Name="FullTrust")]
[PermissionSet(SecurityAction.Demand, Unrestricted=true)]

権限コード

セキュリティで保護されたアセンブリを設計して構築する場合、権限コードを識別できる必要があります。これは、コード アクセス セキュリティに対して重大な影響を付与します。権限コードは、セキュリティで保護されたリソースにアクセスするか、アンマネージ コードの呼び出し、シリアル化の使用、またはリフレクションの使用などの他のセキュリティに関する処理を実行するマネージ コードです。機能できる前にコード アクセス セキュリティが権限コードに特別なアクセス許可を付与する必要があるため、権限コードには privileged です。

権限リソース

表 8.1 に、特別なコード アクセス セキュリティ アクセス許可を必要とする権限リソースが示されます。

表 8.1: セキュリティで保護されたリソースおよび関連アクセス許可

権限操作

権限操作とコードの呼び出しに必要な関連するアクセス許可を表 8.2 に示します。

表 8.2: 権限操作と関連するアクセス許可

アクセス許可を要求する

アセンブリを設計して作成する場合、コードがアクセスするリソースの一覧およびコードが実行する権限操作の一覧を作成します。配置時に、コード アクセス セキュリティ ポリシーを適切に設定するための情報およびセキュリティ関連問題を診断するための情報を管理者が必要とするかもしれません。

コードのアクセス許可要件を伝えるのに最も良いのは、セキュリティ レベルの宣言型セキュリティ属性を使用して最小限のアクセス許可要件を指定する方法です。これらは通常、Assemblyinfo.cs か Assemblyinfo.vb に配置されます。これにより、管理者またはアセンブリのコンシューマが Permview.exe ツールを使用してどのアクセス許可が必要であるのかをチェックできます。

RequestMinimum

宣言型のアクセス許可属性と一緒に SecurityAction.RequestMinimum メソッドを使用して、アセンブリが実行するのに必要なアクセス許可の最小限のセットを指定できます。たとえば、アセンブリがレジストリにアクセスする場合、特定のキーから設定データを取得する以外は、より小さな属性を次に使用します。

[assembly: RegistryPermissionAttribute(
                     SecurityAction.RequestMinimum, 
                     Read=@"HKEY_LOCAL_MACHINE\SOFTWARE\YourApp")]

コードが完全な信頼の環境で動作することと制限なしのアクセス権限の完全なセットをコードに付与することが前もって分っている場合、RequestMinimum を使用することはあまり重要ではありません。しかし、アセンブリのアクセス許可要件を指定しておくのもよい方法です。

注: アクセス許可の属性により、必須のコンストラクタ引数の後のカンマで区切られたプロパティとプロパティ値のリストが承諾されます。これらは、基礎アクセス許可オブジェクトを初期化するために使用されます。サポートされているプロパティ名を見つけ出す迅速な方法は、アクセス許可属性の種類を含むアセンブリで Ildasm.exe を使用する方法です。

RequestOptional

SecurityAction.RequestOptional メソッドを使用する場合、たとえアセンブリがコード アクセス セキュリティのポリシーによりアクセス許可が追加されたとしても、SecurityAction.RequestMinimum および SecurityAction.RequestOptional で指定される以外にはアクセス許可はアセンブリに付与されません。

RequestRefused

SecurityAction.RequestRefuse により、必要のないコード アクセス セキュリティ ポリシーによりアセンブリにアクセス許可を付与することができないようになります。たとえば、アセンブリがアンマネージ コードを呼び出さない場合、次の属性を使用して、コード アクセス セキュリティがアセンブリにアンマネージ コードのアクセス許可を付与しないようにします。

[assembly: SecurityPermissionAttribute(SecurityAction.RequestRefuse, 
                                       UnmanagedCode=true)]

RequestOptional または RequestRefuse の使用の影響

RequestOptional を使用する場合、RequestOptional および RequestMinimum で指定されるアクセス許可のセットが、ポリシーによりアセンブリに付与されるアクセス許可の付与と共通です。これは、RequestOptional および RequestMinimum セットの外側にあるアクセス許可はすべて、アセンブリのアクセス許可の付与から削除されることを意味しています。また、RequestRefuse を使用する場合、拒否されたアクセス許可もアセンブリのアクセス許可の付与から削除されます。

RequestOptional または RequestRefuse を使用する場合、アセンブリは、他のアセンブリを呼び出すときに影響のある部分的に信頼されたアセンブリになります。次の事項を使用して、SecurityAction.RequestOptional または SecurityAction.RequestRefuse を使用すべきかどうかを決定するのに役立てます。

• 呼び出すことができないようになるため、AllowPartiallyTrustedCallersAttribute (APTCA) なしで厳密な名前のアセンブリを直接呼び出す場合は使用しません。

  たくさんの厳密な名前の付けられた .NET Framework アセンブリは、部分的に信頼された呼び出しをサポートしない種類および APTCA を含まない種類を含みます。詳細情報、および部分的に信頼された呼び出しをサポートするアセンブリの一覧については、モジュール 9 「ASP.NET でコード アクセス セキュリティを使用する」の「部分的に信頼された Web アプリケーションを開発する」を参照してください。

  APTCA を持たない厳密な名前の付けられたアセンブリを呼び出す場合、コードをインストールする管理者に、正しく動作するようにコード アクセス セキュリティ ポリシーによりコードに完全な信頼を付与する必要があることを知らせます。

• APTCA アセンブリにアクセスする必要がない場合、アクセス許可要求を追加してアセンブリが必要としないそれらのアクセス許可を拒否します。早い段階でコードをテストして、本当に必要のないそれらのアクセス許可を確認します。

• ダウンストリーム コードが拒否したアクセス許可を必要とする場合、ユーザーとダウンストリーム コード間のメソッドはアクセス許可をアサートすることを必要とします。一方、スタック ウォークがコードに到達すると、SecurityException が生成されます。

コードを認証する

コード アクセス セキュリティにより、アセンブリを呼び出すコードを認証できます。これにより、悪意のあるコードがコードの呼び出しに成功するリスクを減らします。たとえば、ID アクセス許可を使用して、厳密な名前の公開キー要素などの識別エビデンスをベースにしたコードの呼び出しを制限できます。また、明示的なコード アクセスのアクセス許可要求を使用して、リソースにアクセスしたり、アセンブリが公開する権限のある操作を実行したりする必要なアクセス許可をアセンブリの呼び出しコードが持っていることを確認します。

通常、コード アクセス アクセス許可を明示的に要求しません。.NET Framework クラスがこれを行い、複製要求は必要ではありません。しかし、明示的な要求を発行しなければならない場合、たとえば、アンマネージ コードを使用してコードがカスタム リソースを表示する場合、またはコードがキャッシュされたデータにアクセスする場合に機会があります。次の方法でコードを承認できます。

• ユーザーのコードを呼び出すコードを制限します。

• 継承を制限します。

• キャッシュされたデータの保護を考慮します。

• カスタム アクセス許可を使用してカスタム リソースを保護します。

使用コードを呼び出すコードを制限する

[公開] とマークされたメソッドを、現在のアセンブリの外にあるコードにより呼び出すことができます。他のどのコードが方法を呼び出すことができるのかを制限するには、次の例で示されるように、コード アクセス セキュリティ ID アクセス許可要求を使用できます。

public sealed class Utility
{
// SomeOperation() はパブリック メソッドですが、次の 
// アクセス許可要求はアセンブリによってのみ呼び出されることを意味します。
// このアセンブリは公開キーを持っています。 
  [StrongNameIdentityPermission(SecurityAction.LinkDemand, 
                                PublicKey="00240000048...97e85d098615")]
  public static void SomeOperation() {}
}

上記のコードはリンク要求を示しています。これは、即時呼び出しの認証になります。したがって、コードがおとり攻撃に対して無防備である可能性があり、保護されたリソースまたは厳密な名前を持つ信頼された中間アセンブリを通じてアセンブリによって提供された操作に悪意のあるアセンブリがアクセスする可能性があります。

クラスによって提供された機能の特性に応じて、ID ベースのリンク要求の使用に加えてコードの呼び出しを承認する別のアクセス許可を要求する必要があるかもしれません。また、コール スタックのすべてのコードが同じ秘密キーを使用して署名された厳密な名前であることを前提としますが、StrongNameIdentityPermission と組み合わせて完全な要求の使用を検討できます。

注: StrongNameIdentityPermission に対する完全なスタック ウォーク要求の発行は、アセンブリが Web アプリケーションまたは Web サービスにより呼び出される場合は機能しません。これは、ASP.NET Web アプリケーションまたは Web サービスと関連する動的にコンパイルされたクラスに厳密な名前を付けることが不可能だからです。

• アセンブリから公開キーを抽出するには

  • 次のコマンドを実行して、アセンブリから公開キーの 16 進表現を取得します。

    secutil -hex -strongname yourassembly.dll

• キー ペア ファイルから公開キーを抽出するには

継承を制限する

クラスが基本クラスとして設計されていると、次の例で示されるように、StrongNameIdentityPermission と一緒に継承要求を使用して、クラスからの派生が許可される他のコードを制限できます。これにより、要求の公開キーに対応する秘密キーで署名されていない任意のアセンブリからのクラス継承が行われません。

// 次の継承要求により、指定された公開キーを持つアセンブリ内の
// そのコードのみを保護します (アセンブリの厳密な名前は
// サブ クラス SomeRestrictedClass)。
[StrongNameIdentityPermission(SecurityAction.InheritanceDemand,
                              PublicKey="00240000048...97e85d098615")]
public class SomeRestrictedClass
{
}

キャッシュされたデータの保護を考慮する

.NET Framework クラスの 1 つを使用してリソースにアクセスする場合、問題のリソースの種類にふさわしいアクセス許可要求がクラスにより発行されます。パフォーマンス上の理由から引き続きデータをキャッシュする場合、キャッシュ データにアクセスする前にアクセス許可要求にアクセスする明示的なコードの発行について検討します。これにより、コードの呼び出しが承認されて特定の種類のリソースにアクセスすることが確実になります。たとえば、ファイルからデータを読み込んでキャッシュし、コードの読み込みを承認する場合、次の例で示されるように、FileIOPermission 要求を発行します。

// 次の要求は、最初にキャッシュ データが次から取得されたことを前提としています。
// C:\SomeDir\SomeFile.dat
new FileIOPermission(FileIOPermissionAccess.Read, 
                     @"C:\SomeDir\SomeFile.dat").Demand();
// ここで、キャッシュにアクセスしてデータを呼び出し側に返します。

カスタム アクセス許可を使用してカスタム リソースを保護する

アンマネージ コードを使用してリソースまたは操作を公開する場合、ラッパー コードをサンドボックスし、カスタム アクセス許可の要求を考慮してコードの呼び出しを承認します。

アクセス許可の種類が IUnrestrictedPermission インターフェイスに影響を及ぼす限り、完全に信頼された呼び出しにカスタム アクセス許可を自動的に付与します。部分的に信頼された呼び出しは、コード アクセス セキュリティ ポリシーにより明確に付与されていない場合はアクセス許可がありません。これにより、信頼されていないコードが、公開するカスタム リソースにアクセスするアセンブリを呼び出すことができなくなります。また、サンドボックスは、コードを呼び出すことが必要なコードに強力な UnmanagedCodePermission を付与することを要求しないことを意味しています。

アンマネージ コードの呼び出しに関する詳細情報については、このモジュールで後述する「アンマネージ コード」を参照してください。カスタム アクセス許可の実装の例については、このガイドの「How To」の「[HOWTO] 暗号化のカスタム アクセス許可を作成する方法」を参照してください。

リンク要求

リンク要求は、ランタイムが即時呼び出しのみからアクセス許可を要求して完全なスタック ウォークを実行しない点で、標準的なアクセス許可要求とは異なります。リンク要求は JIT コンパイル時間に実行され、宣言型に指定されることのみ可能です。

使用するとセキュリティの脆弱性が簡単に取り入れられてしまうため、リンク要求を使う前に注意深く検討してください。リンク要求を使用する場合、次の点に注意します。

• おとり攻撃

• パフォーマンスとリンク要求

• リンク要求を使用したメソッドの呼び出し

• クラスとメソッド レベル リンク要求の混在

• インターフェイスとリンク要求

• 構造とリンク要求

• 仮想メソッドとリンク要求

おとり攻撃

リンク要求を持つコードを保護する場合、おとり攻撃に対して脆弱です。図 8.5 で示されるように、悪意のあるコードが信頼された中間を介して、コードによって公開されたリソースまたは操作にアクセスします。

図 8.5
リンク要求を使用することによるおとり攻撃の例

図 8.5 では、セキュリティ保護されたリソースにアクセスするアセンブリ X のメソッドは、特定の公開キーのリンク要求で保護されます (StrongNameIdentityPermission を使用)。アセンブリ A、B、および C は、アセンブリ X が信頼する公開キーに該当する秘密キーで署名され、これらのアセンブリはアセンブリ X と呼ぶことができます。アセンブリ A、B、および C は、アセンブリ X に呼び出しを行う前に特定のエビデンスに対する呼び出しをチェックしない場合、おとり攻撃を受けやすくなります。たとえば、アセンブリ D が同じ秘密キーで署名されていない場合、アセンブリ X を直接呼び出せません。しかし、別のリンク要求または完全な要求で A が呼び出しをチェックしない場合、信頼されたアセンブリ A を介してアセンブリ X にアクセスできます。

機能が公開されないようにアセンブリの呼び出しを信頼する場合 (たとえば、呼び出しがアプリケーションでライブラリではない場合)、または ID アクセス許可要求を持つ即時呼び出しの ID を確認することが安全であると分っている場合、アセンブリのリンク要求を使用するのみです。

パフォーマンスとリンク要求

ネットワークの待ち時間やデータベース アクセスのような他の Web アプリケーションのパフォーマンス問題と比較すると、スタック ウォークによる損失は小さくなります。パフォーマンス上の理由のみでリンク要求を使用しないでください。完全な要求により、もっと高いセキュリティが提供されます。

リンク要求を使用したメソッドを呼び出す

保護されたメソッドのリンク要求を呼び出す場合、リンク要求によりコードのみがチェックされます。この状況で、コードが適切な処理を行って呼び出しを許可します。たとえば、アクセス許可を要求します。

クラスとメソッド レベル リンク要求を混在させる

メソッド レベル リンク要求はクラス レベル リンク要求をオーバーライドします。たとえば、次のコード フラグメントで、FileIOPermission に対するリンク要求はメソッド宣言に配置する必要があり、EnvironmentPermission リンク要求はクラス レベル FileIOPermission 要求を配置します。

[FileIOPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public sealed class SomeClass
{
// メソッドが別のリンク要求で装飾される場合、
// 制限なしの FileIOPermission リンク要求はメソッド レベルで再スタートされます。
// それに失敗することは (この例で)、
// EnvironmentPermission リンク要求がクラス レベル FileIOPermission リンク要求をオーバーライドすることを
// 意味しています。
  [FileIOPermission(SecurityAction.LinkDemand, Unrestricted=true)]
  [EnvironmentPermission(SecurityAction.LinkDemand, Read="PATH")]
  public void SomeMethod()
  {
  }
}

インターフェイスとリンク要求

クラスがインターフェイスを実装し、メソッド実装の 1 つがリンク要求を持っていると、インターフェイス定義のメソッド宣言が同じリンク要求を持つことが確実になります。一方、呼び出しは、リンク要求を使用しないインターフェイスを介してメソッドを呼び出す必要があります。次に例を示します。

public interface IMyInterface
{
// 以降のメソッド実装に示されるリンク要求は
// ここに配置されます。
  void Method1();
}

public class MyImplementation : IMyInterface
{
// メソッド実装はリンク要求を持っていますが、インターフェイスは持っていません。
  [SecurityPermission(SecurityAction.LinkDemand, 
            Flags=SecurityPermissionFlag.ControlPrincipal)]
  public void Method1()
  {
  }
}

次のコードで、呼び出しはリンク要求によって決まります。

MyImplementation t = new MyImplementation();
t.Method1();

次のコードで、呼び出しはリンク要求によって決まりません。

IMyInterface i = new MyImplementation();
i.Method1();

構造とリンク要求

リンク要求は、信頼されていない呼び出しによる構造の構築を妨げません。これは、既定のコンストラクタが構造用に自動的に生成されないからです。したがって、明示的なコンストラクタを使用する場合、構造レベル リンク要求のみが適用されます。次に例をあげます。

[SecurityPermission(SecurityAction.LinkDemand, 
           Flags=SecurityPermissionFlag.ControlPrincipal)]
public struct SomeStruct
{
// この明示的なコンストラクタはリンク要求により保護されます。
  public SomeStruct(int i)
  {
    field = i;
  }
  private int field;
}

次の 2 行のコードは両方ともフィールドが 0 に初期化されて新しい構造になります。しかし、明示的なコンストラクタを使用する 1 行目はリンク要求によって変化します。

SomeStruct s = new SomeStruct(0);
SomeStruct s = new SomeStruct();	

2 行目は、既定のコンストラクタが生成されないのでリンク要求によって変化しません。これが構造の代わりにクラスなら、指定されたリンク要求でコメント付けされている既定のコンストラクタをコンパイラが生成します。

仮想メソッドとリンク要求

リンク要求を使用して派生したクラスでメソッドがオーバーライドすることを防ぐ場合、対応する仮想基本クラス メソッドにリンク要求を配置することを確認します。一方、JIT リンク要求が存在しないベース クラスの種類への参照をコンパイラが確認する場合、リンク要求は実行されません。

Assert および RevertAssert

CodeAccessPermission.Assert メソッドを呼び出して、現在のスタック フレームを越えて要求が伝達されることを防ぐことができます。Assert を使用して、コードの呼び出しの信頼性を保証します。おとり攻撃の可能性のために、Assert は警告で使用される必要があります。

Assert は、権限コードをサンドボックスするために最も頻繁に使用されます。Assert を呼び出すコードを開発する場合、コードの呼び出しを承認する場所に代替セキュリティ設定がある必要があります。次はリスクを最小限に抑えるのに役立ちます。

• 要求を使用する/パターンをアサートする

• アサート時間を削減する

要求を使用する/パターンをアサートする

Assert を呼び出す前に特定のアクセス許可を要求するのは、アップストリーム コードを承認する効果的な方法です。コードの呼び出しを認証するビルトイン アクセス許可の種類を要求することができることもあります。

データ保護 API (DPAPI) の呼び出しなどの .NET Framework クラス ライブラリによって提供されない機能をアセンブリが公開している場合、カスタム アクセス許可を開発し、カスタム アクセス許可を要求して呼び出しを承認する必要があります。たとえば、カスタム Encryption アクセス許可を開発して、管理されたラッパー アセンブリに対する呼び出しを承認します。このアクセス許可を要求してアンマネージ コードのアクセス許可をアサートするのは、コードの呼び出しを承認する効果的な方法です。

このアプローチとカスタム権限の開発についての詳細情報は、このガイドの「How To」の「[HOWTO] 暗号化のカスタム アクセス許可を作成する方法」を参照してください。

アサート時間を削減する

Assert を呼び出して、コードが呼び出す 1 つのダウンストリーム メソッドの要求を満たす場合、ダウンストリーム メソッドの呼び出しの前に Assert をすぐに配置します。すぐに RevertAssert を呼び出してアサーション ウィンドウをできるのみ小さく保持し、事実上 Assert が残っているのでメソッドにより呼び出される後のコードが成功しないことを確認します。

通常は、finally ブロックの RevertAssert に呼び出しを配置して、例外のイベントでさえ必ず呼び出されるようにします。

コードを制約する

コードの制約および最新の権限コードの構築は、ユーザーまたはサービス アカウントを設定するときの最低限の権限の使用とよく似ています。コードで使用可能なコード アクセス セキュリティのアクセス許可を制限することにより、コードの悪意のある使用範囲を小さくします。

アクセスできるリソースと実行できる他の権限操作を制限するコードを制約するには、次の 2 つの方法があります。

• ポリシー アクセス許可の付与の使用

• スタック ウォーク装飾子の使用

ポリシー アクセス許可の付与を使用する

コード アクセス セキュリティ ポリシーを設定して、制限されたアクセス許可のセットを特定のアセンブリに付与します。これにより、リソースにアクセスする機能または他の権限操作を実行する機能が制約されます。詳細情報については、このガイドの「How To」の「[HOWTO] アセンブリ制約のためにコード アクセス セキュリティ ポリシーを使用する方法」を参照してください。

スタック ウォーク装飾子を使用する

スタック ウォーク修飾子を使用して、呼び出すコードに特定のアクセス許可のみを使用可能にすることができます。たとえば、SecurityAction.PermitOnly を使用して、呼び出される各自のメソッドおよび任意のメソッドのみが制限されたアクセス許可セットを持つことを保証します。次の例は、厳しく制限されたアクセス許可セットに適用されます。コードは実行するアクセス許可のみを持っています。リソースにアクセスできず、または他の権限操作を実行できません。

[SecurityPermissionAttribute(SecurityAction.PermitOnly, 
                             Flags=SecurityPermissionFlag.Execution)]
public void SomeMethod()
{	
// 現在のメソッドおよびダウンストリームは実行のみ可能です。それらは、
// リソースにアクセスしたり、他の権限操作を実行できません。
  SomeOtherMethod();
}

次のセクションでは、コード アクセス セキュリティを使用して、ファイル I/O、イベント ログ、レジストリ、データ アクセス、ディレクトリ サービス、環境変数、Web サービスおよびソケットを含むリソース アクセスのさまざまな種類を制約する方法を示します。

ファイル I/O

ファイル I/O を実行できるようにするには、コード アクセス セキュリティ ポリシーによりアセンブリが FileIOPermission に付与されます。コードに制限なしの FileIOPermission が付与される場合、Windows セキュリティに保護されているファイル システムのどこからでもファイルにアクセスできます。制限された FileIOPermission を使用して、たとえば、許可されたアクセス権 (読み込み、読み込みと書き込みなど) を指定することにより、ファイル I/O を実行するアセンブリの機能を制約できます。

アプリケーションのコンテキストの範囲内でファイル I/O を制約する

共通の要件は、アプリケーションのディレクトリ階層のような特定のディレクトリにファイル I/O を制限できることです。

注: Web アプリケーションを "中程度の信頼" に設定した場合、アプリケーションの仮想ディレクトリ階層にファイル アクセスは自動的に制限されます。詳細情報については、モジュール 9 「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

アプリケーションを "中程度の信頼" に設定するのは、ファイル I/O を制約する 1 つの方法です。これはまた、他のリソースの種類にアクセスするアプリケーション機能を制約します。コードのファイル I/O 機能を制限できる 2 つの他の方法があります。

• PermitOnly を使用してファイル I/O を制限する

• コード アクセス セキュリティ ポリシーを設定してファイル I/O を制限する

PermitOnly を使用してファイル I/O を制限する

ファイル I/O を制約する次の例で示されるように、SecurityAction.PermitOnly と一緒に宣言型の属性を使用できます。

// c:\YourAppDir からファイルを読み込むのみのコードを許可する
[FileIOPermission(SecurityAction.PermitOnly, Read=@"c:\YourAppDir\")]
[FileIOPermission(SecurityAction.PermitOnly, PathDiscovery=@"c:\YourAppDir\")]
public static string ReadFile(string filename)
{
// Path.GetFilePath() を使用してファイル名を正規化する
// FileStream.OpenRead を使用してファイルを開く
// FileStream.Read を使用してデータにアクセスし、データを返す
}

注: PathDicovery アクセスを指定する 2 番目の属性は、入力ファイル名を正規化するために使用される Path.GetFilePath 関数により必要とされます。

アプリケーションのディレクトリ階層をハード コードしないように、セキュリティ構文を使用し、HttpContext.Current.Request.MapPath(".") を使用して Web アプリケーションのディレクトリをランタイムで取得できます。次の例で示すように、System.Web アセンブリを参照して、対応する using ステートメントを追加します。

using System.Web;

public static string ReadFile(string filename)
{
  string appDir = HttpContext.Current.Request.MapPath(".");
  FileIOPermission f = new FileIOPermission(PermissionState.None);
  f.SetPathList(FileIOPermissionAccess.Read, appDir);
  f.SetPathList(FileIOPermissionAccess.PathDiscovery, appDir);
  f.PermitOnly();

// Path.GetFilePath() を使用してファイル名を正規化する
// FileStream.OpenRead を使用してファイルを開く
// FileStream.Read を使用してデータにアクセスしたり、戻ったりする
}

注: Windows アプリケーションについて、MapPath への呼び出しを Directory.GetCurrentDirectory への呼び出しと置換して、アプリケーションの現在のディレクトリを取得できます。

コード アクセス セキュリティ ポリシーを設定してファイル I/O を制限する

管理者はコード アクセス セキュリティ ポリシーを設定し、アプリケーションの仮想ディレクトリ階層を越えてファイル I/O を実行するためにコードの機能を制限できます。

たとえば、管理者はエンタープライズまたはマシン レベルのコード アクセス セキュリティ ポリシーを設定して、制限付きの FileIOPermission をアセンブリに付与します。管理者がポリシーの設定時にこの暗号化された厳密なエビデンスを使用できるため、アセンブリが厳密な名前を含んでいる場合、最も簡単に行われます。厳密な名前のないアセンブリについて、エビデンスの代替フォームを使用する必要があります。コード アクセス セキュリティを設定してアセンブリのファイル I/O 機能を制限する方法についての詳細情報は、このガイドの「How To」の「[HOWTO] アセンブリ制約のためにコード アクセス セキュリティ ポリシーを使用する方法」を参照してください。

アプリケーションの仮想ディレクトリ ルートを表す $AppDirUrl$ を使用できるため、アセンブリが Web アプリケーションにより呼び出される場合、よりよいアプローチはASP.NET (アプリケーション ドメインレベル) のコード アクセス セキュリティ ポリシーを設定する方法です。ASP.NET アプリケーション ドメイン ポリシーを使用したファイル I/O の制限についての詳細情報は、モジュール 9 の「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

FileIOPermission を要求する

管理者を手伝うには、構築時のアセンブリの厳密なファイル I/O 要件について知っている場合 (たとえば、ディレクトリ名を知っている場合)、次の例に示されるように、宣言型のアクセス許可要求を使用して、アセンブリの FileIOPermission 要件を宣言します。

[assembly: FileIOPermission(SecurityAction.RequestMinimum, Read=@"C:\YourAppDir")]

管理により、permview.exe を使用してこの属性を参照できます。SecurityAction.RequestMinimum を使用する利点は、十分なアクセス許可を付与されていない場合、アセンブリが読み込みに失敗することです。ランタイム セキュリティ例外より好ましいです。

イベント ログ

イベント ログを実行できるようにするには、コード アクセス セキュリティ ポリシーによりアセンブリが EventLogPermission に付与されなければなりません。違う場合、中程度に信頼された Web アプリケーションのコンテキスト内で動作するため、イベント ロギング コードをサンドボックスする必要があります。イベント ログへのアクセスのサンドボックスについての詳細情報は、モジュール 9 「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

イベント ロギング コードを制約する

イベント ログ ラッパー コードの動作を制約する場合、おそらく別の開発者または開発組織により書かれたコードである場合、次の例に示されるように SecurityAction.PermitOnly と一緒に宣言型の属性を使用できます。

次の属性は、WriteToLog メソッドおよびそれが呼び出す任意のメソッドがローカル コンピュータのイベント ログにアクセスのみ可能で、イベント ログやイベント ソースを削除できないことを保証します。これらの操作は EventLogPermissionAccess.Instrument により許可されません。

[EventLogPermission(SecurityAction.PermitOnly, 
                    MachineName=".",
                    PermissionAccess=EventLogPermissionAccess.Instrument)]
public static void WriteToLog( string message )

既存のログへ読み取り専用にするには、EventLogPermissionAccess.Browse を使用します。

EventLogPermission を要求する

コードのアクセス許可要件を記録して、コード アクセス セキュリティ ポリシーにより不十分なイベント ログ アクセスを付与されている場合にアセンブリが読み込めないようにするには、次の例で示すように SecurityAction.RequestMinimum でアセンブリ レベル EventLogPermissionAttribute を追加します。

// この属性により、コードがローカル マシン (".") のみのイベント ログにアクセスする機能を必要としていることが示されます。 
// さらに、計装アクセスが必要です。
// 読み取ったり、既存のログに書き込んだり、新しいイベント ソースとイベント ログを作成したりすることが可能であることを
// 意味します。
[assembly: EventLogPermissionAttribute(SecurityAction.RequestMinimum,
                                       MachineName=".",
                                       PermissionAccess=
                                       EventLogPermissionAccess.Instrument)]

レジストリ

Microsoft.Win32.Registry クラスを使用してレジストリにアクセスするコードは、コード アクセス セキュリティ ポリシーにより、RegistryPermission に付与されます。このアクセス許可の種類を試用して、指定のキーおよびサブ キーにレジストリのアクセスを制約でき、読み込み、書き込み、またはレジストリ キーおよび名前付き値の作成のコードの機能を制御できます。

レジストリ アクセスを制約する

特定のレジストリ キーからデータの読み込みにコードを制約するには、SecurityAction.PermitOnly と共に RegistryPermissionAttribute を使用できます。次の属性により、コードは HKEY_LOCAL_MACHINE\SOFTWARE の下の YourApp キー (および サブキー) からの読み込みのみ可能です。

[RegistryPermissionAttribute(SecurityAction.PermitOnly,
                             Read=@"HKEY_LOCAL_MACHINE\SOFTWARE\YourApp")]
public static string GetConfigurationData( string key, string namedValue )
{
  return (string)Registry.
                 LocalMachine.
                 OpenSubKey(key).
                 GetValue(namedValue);
}

RegistryPermission を要求する

コードのアクセス許可要件を記録して、コード アクセス セキュリティ ポリシーから不十分なレジストリ アクセスを付与されている場合にアセンブリが読み込めないようにするには、次の例で示すように SecurityAction.RequestMinimum でアセンブリ レベル EventLogPermissionAttribute を追加します。

[assembly: RegistryPermissionAttribute(SecurityAction.RequestMinimum,
                                   Read=@"HKEY_LOCAL_MACHINE\SOFTWARE\YourApp")]

データ アクセス

ADO.NET SQL Server データ プロバイダは部分的に信頼された呼び出しをサポートします。OLE DB、Oracle、および ODBC プロバイダを含む他のデータ プロバイダには現在、完全な信頼の呼び出しが必要です。

SQL Server データ プロバイダを使用してSQL Server に接続する場合、データ アクセス コードには SqlClientPermission が必要です。SqlClientPermission を使用して、SqlConnection オブジェクトに渡される接続文字列に使用可能な名前/値 ペアの最大範囲を制約します。次のコードで、CheckProductStockLevel メソッドが追加のセキュリティ チェックで拡張されており、空のパスワードが接続文字列に使用できません。コードが空のパスワードを持つ接続文字列を取得すると、SecurityException がスローされます。

[SqlClientPermissionAttribute(SecurityAction.PermitOnly, 
                              AllowBlankPassword=false)]
public static int CheckProductStockLevel(string productCode)
{
// レジストリから接続文字列を取得する
  string connectionString = GetConnectionString();
  . . .
}

データ アクセス コードをサンドボックスして OLE DB および他のデータ プロバイダが部分的に信頼された Web アプリケーションから使用することを許可する方法についての詳細情報は、モジュール 9 「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

ディレクトリ サービス

現在、Active Directory などのディレクトリ サービスにアクセスする System.DirectoryServices 名前空間からクラスを使用するコードには、完全な信頼が必要です。しかし、DirectoryServicesPermission を使用して、コードが接続できるアクセスの種類および特定のディレクトリ サービスの種類を制約できます。

ディレクトリ サービス アクセスを制約する

コードを制約するには、SecurityAction.PermitOnly と共に DirectoryServicesPermissionAttribute を使用できます。次の属性により、コードが特定の LDAP パスに接続したり、ディレクトリの参照のみを行ったりすることが可能になります。

[DirectoryServicesPermissionAttribute(SecurityAction.PermitOnly, 
                       Path="LDAP://rootDSE",
                       PermissionAccess=DirectoryServicesPermissionAccess.Browse)]
public static string GetNamingContext(string ldapPath)
{
  DirectorySearcher dsSearcher = new DirectorySearcher(ldapPath);
  dsSearcher.PropertiesToLoad.Add("defaultNamingContext");
  dsSearcher.Filter = "";
  SearchResult result = dsSearcher.FindOne();
  return (string)result.Properties["adsPath"][0];
}

DirectoryServicesPermission を要求する

コードのアクセス許可要件を記録して、コード アクセス セキュリティ ポリシーから不十分なディレクトリ サービス アクセスを付与されている場合にアセンブリが読み込めないようにするには、次の例で示すように SecurityAction.RequestMinimum でアセンブリ レベル DirectoryServicesPermissionAttribute を追加します。

[assembly: DirectoryServicesPermissionAttribute(SecurityAction.RequestMinimum, 
                       Path="LDAP://rootDSE",
                       PermissionAccess=DirectoryServicesPermissionAccess.Browse)]

環境変数

System.Environment クラスを使用した環境変数の読み込みと書き込みが必要なコードを、コード アクセス セキュリティ ポリシーにより、EnvironmentPermission に付与する必要があります。このアクセス許可の種類を使用して、特定の名前付き環境変数にアクセスを制約できます。

環境変数アクセスを制約する

特定の環境変数の読み込みのみ可能になるようにコードを制約するには、SecurityAction.PermitOnly と共に nvironmentPermissionAttribute を使用できます。次の属性により、コードは username、userdomain、および temp 変数から読み込みのみ可能になります。

[EnvironmentPermissionAttribute(SecurityAction.PermitOnly, Read="username")]
[EnvironmentPermissionAttribute(SecurityAction.PermitOnly, Read="userdomain")]
[EnvironmentPermissionAttribute(SecurityAction.PermitOnly, Read="temp")]
public static string GetVariable(string name)
{
  return Environment.GetEnvironmentVariable(name);
}

EnvironmentPermission を要求する

コードのアクセス許可要件を記録して、コード アクセス セキュリティ ポリシーから不十分な環境変数 アクセスを付与されている場合にアセンブリが読み込めないようにするには、次の例で示すように SecurityAction.RequestMinimum でアセンブリ レベル EnvironmentPermissionAttribute を追加します。

[assembly: EnvironmentPermissionAttribute(SecurityAction.RequestMinimum,
                                          Read="username"),
           EnvironmentPermissionAttribute(SecurityAction.RequestMinimum,
                                          Read="userdomain"),
           EnvironmentPermissionAttribute(SecurityAction.RequestMinimum,
                                          Read="temp")]

Web サービス

Web サービスを呼び出すコードは、コード アクセス セキュリティ ポリシーにより、WebPermission に付与されなければなりません。WebPermission は実際に、任意の HTTP インターネットベースのリソースへのアクセスを制約します。

Web サービス接続を制約する

コードがアクセスできる Web サービスを制約するには、ecurityAction.PermitOnly と共に ebPermissionAttribute を使用します。たとえば、次のコードにより、PlaceOrder メソッドとそのコードが呼び出すメソッドが http://somehost サイトの Web サービスのみ呼び出すことができるようになります。

[WebPermissionAttribute(SecurityAction.PermitOnly,
                        ConnectPattern=@"http://somehost/.*")]
[EnvironmentPermissionAttribute(SecurityAction.PermitOnly, Read="USERNAME")]
public static void PlaceOrder(XmlDocument order)
{
  PurchaseService.Order svc = new PurchaseService.Order();
// Web サービスが Windows 認証を使用する
  svc.Credentials = System.Net.CredentialCache.DefaultCredentials;
  svc.PlaceOrder(order);
}

前の例では、WebPermissionAttribute クラスの ConnectPattern プロパティを使用します。これにより、接続が確立できるアドレス範囲に一致する正規表現を指定できます。コードが Windows 認証と既定の資格情報を使用するため、前に示した EnvironmentPermissionAttribute が必要です。

次の例により、Connect 属性を使用して特定の Web サービスへの接続を制限する方法が示されます。

[WebPermissionAttribute(SecurityAction.PermitOnly,
                        Connect=@"http://somehost/order.asmx")]

ソケットと DNS

System.Net.Sockets.Socket クラスを使用してソケットを直接使うコードを、コード アクセス セキュリティ ポリシーにより、SocketPermission に付与する必要があります。また、コードが DNS を使用してホスト名を IP アドレスにマップする場合、DnsPermission が必要です。

SocketPermission を使用して、特定のホストの特定のポートへの接続を制約できます。また、接続を受け入れるため、または送信の接続を開始するためにソケットを使用できるかどうかを制限できます。Transmission Control Protocol (TCP) または User Datagram Protocol (UDP) などの転送プロトコルも制限できます。

ソケット アクセスを制約する

制限された方法でソケットのみ使用できるようにコードを制約するには、SecurityAction.PermitOnly と共に SocketPermissionAttribute を使用できます。次の属性により、TCP プロトコルを使用して特定のホストの特定のポートのみにコードが接続できるようになります。また、コードは Dns.Resolve を呼び出してホスト名を解決するため、コードには DnsPermission も必要です。

[SocketPermissionAttribute(SecurityAction.PermitOnly, 
                           Access="Connect", 
                           Host="hostname", 
                           Port="80", 
                           Transport="Tcp")]
[DnsPermissionAttribute(SecurityAction.PermitOnly, Unrestricted=true)]
public string MakeRequest(string hostname, string message)
{
  Socket socket = null;
  IPAddress serverAddress = null;
  IPEndPoint serverEndPoint = null;
  byte[] sendBytes = null, bytesReceived = null;
  int bytesReceivedSize = -1, readSize = 4096;

  serverAddress = Dns.Resolve(hostname).AddressList[0];
  serverEndPoint = new IPEndPoint(serverAddress, 80);
  socket = new Socket(AddressFamily.InterNetwork, 
                      SocketType.Stream, ProtocolType.Tcp);
  bytesReceived = new byte[readSize];
  sendBytes = Encoding.ASCII.GetBytes(message);
  socket.Connect(serverEndPoint);
  socket.Send(sendBytes);
  bytesReceivedSize = socket.Receive(bytesReceived, readSize, 0);
  socket.Close();
  if(-1 != bytesReceivedSize)
  {
    return Encoding.ASCII.GetString(bytesReceived, 0, bytesReceivedSize);
  }
  return "";
}

SocketPermission および DnsPermission を要求する

コードのアクセス許可要件を記録して、コード アクセス セキュリティ ポリシーから不十分なソケットまたは DNS アクセスを付与されている場合にアセンブリが読み込めないようにするには、次の例で示すように SecurityAction.RequestMinimum でアセンブリ レベル SocketPermissionAttribute および DnsPermissionAttribute を追加します。

[assembly: SocketPermissionAttribute(SecurityAction.RequestMinimum, 
                                     Access="Connect", 
                                     Host="hostname", 
                                     Port="80", 
                                     Transport="Tcp")
           DnsPermissionAttribute(SecurityAction.PermitOnly, Unrestricted=true)]

アンマネージ コード

アンマネージ Win32 API または COM コンポーネントを呼び出すコードには、アンマネージ コードのアクセス許可が必要です。これは、信頼性の高いコードのみに付与することをお勧めします。それは、SecurityPermissionFlag.UnmanagedCode に設定されている Flags プロパティを持つ SecurityPermission の種類により定義されます。

アンマネージ コードの呼び出しに関する次のガイドラインは、モジュール 7 「セキュリティ保護されたアセンブリを構築する」で説明されている内容を基にしています。

• 名前付け規則を使用してリスクを示す。

• アンマネージ コードのアクセス許可を要求する。

• アンマネージ API 呼び出しをサンドボックスする。

• 注意して SupressUnmanagedCodeSecurityAttribute を使用する。

名付け規則を使用してリスクを示す

次の名前付け規則を使用して、アンマネージ コードを分類し、アンマネージ API をカプセル化するために使用される種類を前に付けます。

• Safe: これにより、セキュリティで保護されたスレッドの可能性のないコードが認証されます。悪意のある、またはその他の呼び出しのコードに対して無害です。1 つの例は、現在のプロセッサのティック数を返すコードです。完全な信頼に対するコード アクセス セキュリティのアクセス許可要求をオフにする SuppressUnmanagedCode 属性でセーフ クラスの名前を付けることができます。

  [SuppressUnmanagedCode]
  class SafeNativeMethods {
         [DllImport("user32")]
         internal static extern void MessageBox(string text);
  }

• Native: これは、危険なアンマネージ コードである可能性がありますが、アンマネージ コードのアクセス許可に対する完全なスタック ウォーク要求で保護されます。これらは、SupressUnmanagedCode 属性で抑止しない限り、暗黙的に相互運用機能層により作成されます。

  class NativeMethods {
         [DllImport("user32")]
         internal static extern void FormatDrive(string driveLetter);
  }

• Unsafe: これは、危険なアンマネージ コードの可能性があり、そのコードには、抑止された宣言型のアンマネージ コードのアクセス許可に対するセキュリティ要求があります。これらのメソッドは危険性があります。スタック ウォークが実行されないため、これらのメソッドの呼び出しは、安全でセキュリティ保護されていることを保証するために完全なセキュリティ確認を行う必要があります。

  [SuppressUnmanagedCodeSecurity]
  class UnsafeNativeMethods {
         [DllImport("user32")]
         internal static extern void CreateFile(string fileName);
  }

アンマネージ コードのアクセス許可を要求する

厳密な名前

[assembly: SecurityPermission(SecurityAction.RequestMinimum, 
                              UnmanagedCode=true)]

アンマネージ API 呼び出しをサンドボックスする

特定のアセンブリで呼び出しをアンマネージ コードに分離して、アンマネージ コードを最小限に呼び出すアセンブリの数を維持します。さらに、サンドボックスのパターンを使用して、アンマネージ　コードのアクセス許可が選択されたアセンブリに対してのみ付与されるようにします。

• アンマネージ コードを呼び出すマネージ コードをサンドボックスするには

アンマネージ Win32 DPAPI 機能を呼び出す方法を示す完全な例の実装については、このガイドの「How To」の「[HOWTO] 暗号化のカスタム アクセス許可を作成する方法」を参照してください。

注意して SuppressUnmanagedCodeSecurity を使用する

アセンブリが多数の呼び出しをアンマネージ コードに行うと、複数のアンマネージ コード アクセス許可要求と関連するパフォーマンスの最高値が問題になります。

この場合、P/Invoke メソッド宣言の SupressUnmanagedCodeSecurity 属性を使用できます。これは、JIT コンパイル時に発生するリンク要求と置換するアンマネージ アクセス許可に対する完全な要求をもたらします。

リンク要求の使用と共通で、コードはおとり攻撃を受けやすい状態です。リスクを軽減するには、悪意のあるコードが望まない操作を実行することができないように適切な予防策を取る場合、アンマネージ コードのアクセス許可要求を抑える必要があります。適切な予防策の例は、アンマネージ コードにより実行される処理を反映するカスタム アクセス許可をアセンブリが要求する場合です。

P/Invoke で SuppressUnmanagedCodeSecurity を使用する

次のコードで、SuppressUnmanagedCodeSecurity 属性をプラットフォーム起動サービス (P/Invoke) メソッド宣言に適用する方法を示します。

public NativeMethods
{
// ここで SuppressUnmanagedCodeSecurity を使用することにより、FormatMessage のみに適用する
  [DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity]
  private unsafe static extern int FormatMessage(
                                      int dwFlags, 
                                      ref IntPtr lpSource, 
                                      int dwMessageId,
                                      int dwLanguageId, 
                                      ref String lpBuffer, int nSize, 
                                      IntPtr *Arguments);
}

COM 相互運用機能で SuppressUnmanagedCodeSecurity を使用する

次の例で示されるように、COM 相互運用機能の呼び出しについて、属性がインターフェイスのレベルで使用されます。

[SuppressUnmanagedCodeSecurity]
public interface IComInterface
{
}

代理人

起動時に委任メソッドがすることを前もって知る方法はありません。アセンブリが部分的に信頼された呼び出しをサポートする場合、代理人を起動するときに特別な対策が必要です。コード アクセス セキュリティを使用して、セキュリティを向上させます。

• 代理人に対するアクセス許可を制限することを検討する。

• 代理人を呼び出す前にアクセス許可をアサートしない。

代理人のアクセス許可を制限することを検討する

代理人を呼び出すコードに付与されたアクセス許可により、代理人の機能が定義されます。代理人に付与するコードよりたくさんのアクセス許可がコードに含まれている場合、評価済みのアクセス許可を使用したコードを実行する呼び出し方法が提供されます。この問題に対処するには、適切なアクセス許可要求を持つ代理人に渡す時点で外部コードに権限を付与するか、スタック修飾子の拒否または許可を使用して呼び出しを行う前に代理人のアクセス許可を制限するかのどちらかが可能です。たとえば、次のコードは、機能を制約する代理人コード実行のアクセス許可を付与します。

// 代理人の定義
public delegate void SomeDelegate();
. . . 
// 代理人を呼び出す前に実行のみを許可します。これにより、
// 代理人コードがリソースにアクセスしたり、他の権限操作を行ったり
// しません。
new SecurityPermission(SecurityPermissionFlag.Execution).PermitOnly();
// ここで、"制約された" 代理人を呼び出します。
SomeDelegate();
// スタック修飾子のみアクセス許可を元に戻します。
CodeAccessPermission.RevertPermitOnly();

代理人を呼び出す前にアクセス許可をアサートしない

代理人を呼び出す前にアクセス許可をアサートすることは、代理人の起動時に実行されるコードの性質や信頼レベルを知らないので危険です。代理人を渡すコードはコール スタックにあり、適切なセキュリティ要求でチェック可能です。しかし、信頼レベルや代理人コード自身に付与されるアクセス許可を知る方法はありません。

代理人の安全な使用についての詳細なガイドラインは、モジュール 7 「セキュリティ保護されたアセンブリを構築する」の「デリゲート」を参照してください。

シリアル化

シリアル化をサポートするコードは、SerializationFormatter に設定された Flag 属性を持つ SecurityPermission に付与する必要があります。シリアル化をサポートするクラスを開発してコードが部分的に信頼された呼び出しをサポートする場合、追加のアクセス許可要求の使用を考慮して、オブジェクト状態をシリアル化できるコードに制約を配置します。

シリアル化を制限する

オブジェクトをシリアル化できる ISerializable インターフェイスを実装するクラスを作成する場合、ISerializable.GetObjectData 実装にアクセス許可要求を追加して、オブジェクトをシリアル化するコードに権限を付与することができます。これは、コードが部分的に信頼された呼び出しをサポートしている場合に特に重要です。

たとえば、次のコード フラグメントは StrongNameIdentityPermission 要求を使用して、その要求の公開キーに該当する特定の秘密キーで署名されたコードのみがオブジェクト状態をシリアル化できます。

[StrongNameIdentityPermission(SecurityAction.Demand, 
                              PublicKey="00240000048...97e85d098615")]
public override void GetObjectData(SerializationInfo info, 
                                   StreamingContext context)

安全なシリアル化の使用についての詳細なガイドラインは、モジュール 7 「セキュリティ保護されたアセンブリを構築する」の「シリアル化」を参照してください。

要約

コード アクセス セキュリティにより、コードができることを制限したり、コードが呼び出すコードを制限したり、コードを識別したりすることができるようになります。コードと呼び出すコードですべてのアクセス許可の制限なしのセットを持つ完全に信頼された環境では、コード アクセス セキュリティは重要ではありません。

コードが部分的に信頼された呼び出しをサポートする場合、セキュリティのリスクがかなり大きくなります。部分的な信頼のシナリオでは、コード アクセス セキュリティにより、一部の追加リスクを軽減でき、権限コードを制約できます。

その他のリソース

詳細については、次のリソースを参照してください。

• 2002 年 9 月、Don Box による「MSDN Magazine」(英語) の「Security in .NET: The Security Infrastructure of the CLR Provides Evidence, Policy, Permissions, and Enforcement Services」(英語) (http://msdn.microsoft.com/msdnmag)

• 2001 年 2 月、Keith Brown による「MSDN Magazine」(英語) の「Security in .NET: Enforce Code Access Rights with the Common Language Runtime」(英語) (http://msdn.microsoft.com/msdnmag)

• 『.NET Framework Security』LaMacchia、Lange、Lyons、Martin、Price 著 (Addison Wesley 出版)