コード アクセス セキュリティにおける変更内容の概要
.NET Framework Version 4 では、セキュリティ システムを簡略化するために、コード アクセス セキュリティ (CAS) に大幅な変更が加えられています。 以前のバージョンの .NET Framework では、マネージ アプリケーションの権限は、ランタイム設定を確立するためにコンピューター全体で設定されるセキュリティ ポリシー規則によって決定されていました。 .NET Framework 4 以降では、次のようになりました。
セキュリティ ポリシーには効力がなくなりました。 アクセス許可は引き続き使用されています。ポリシー システムのみが削除されました。
アプリケーションのアクセス権は、アクセス許可 (アプリケーション ドメインで確立された許可セット) とその透過性の 2 つの要素によって決まります。 部分信頼アプリケーションはすべて透過的なアプリケーションに分類されます。 透過的なアプリケーションでは、セキュリティについて考慮する必要はありません。 透過性が最初に使用されたのは Microsoft Silverlight で、現在はすべてのホスト環境に普及しています。
デスクトップ アプリケーションおよびローカル イントラネット アプリケーションには完全信頼が与えられます。
.gif "重要 :") 重要 |
|---|
CAS の大幅な変更点は、セキュリティ ポリシーの削除です。CAS 自体は削除されていません。ポリシー (および一部のアクセス許可要求) のみが使用されなくなりました。 |
ここでは、.NET Framework 4 での CAS の変更点の概要について説明します。 詳細については、「.NET Framework 4 におけるセキュリティの変更点」を参照してください。
サンドボックス化とアクセス許可モデル
.NET Framework 4 におけるデスクトップ アプリケーションとホストされたアプリケーションの信頼モデルを以下に示します。 詳細については、「.NET Framework 4 におけるセキュリティの変更点」を参照してください。
デスクトップ アプリケーション。 以前のバージョンの .NET Framework と同様に、デスクトップに存在するマネージ アプリケーション (Web からダウンロードされた場合を除く) には完全信頼が与えられます。 ローカル イントラネットの共有に存在するアプリケーションにも、完全信頼が与えられます。 ポリシーを使用して、ローカル ハード ドライブ上のフォルダーに基づいてアプリケーションのアクセス許可を制限することはできなくなりました。
ホストされたアプリケーション。 サンドボックスで実行するアプリケーション (Silverlight ベースのアプリケーションなど) には、アクセスできるコンピューター リソース (使用できるファイルなど) を決定する限定されたアクセス許可セットが与えられます。 サンドボックスには、サンドボックス内で部分的に信頼されたアセンブリと完全に信頼されたアセンブリを識別する機能があります。 部分信頼アセンブリには、サンドボックスを作成したアプリケーション ドメイン (System.AppDomain) で指定された特定のアクセス許可セットが与えられます。 完全信頼ライブラリの完全信頼コードの中には、部分的に信頼されたコードから呼び出すことができるものもあります。 その信頼されているコードは、コンピューター上の保護されたリソースを呼び出すことができます。 ただし、保護されたリソースを呼び出すことができる、パブリックにアクセス可能な完全信頼の型およびメンバーは、セキュリティ監査を受けている必要があります。 これらのメンバーは、次のセクションで説明するように、セーフ クリティカルに分類されます。 このようなメンバーは部分信頼 (透過的な) コードから呼び出すことができ、クリティカル コードを呼び出すことができます。
セキュリティ透過性
セキュリティ透過性によって、セキュリティに対する配慮が必要なコードとセキュリティに対する配慮が不要なコードが分離されます。 セキュリティ透過性は .NET Framework Version 2.0 で導入され、セキュリティにかかわるアクションの実行が必要なコードにセキュリティ クリティカルとして注釈を付けることで、セキュリティ監査を容易することを目的としていました。 つまり、セキュリティ クリティカルではないコード (透過的なコード) では完全なレビューは不要でした。 ただし、このような以前のバージョンの .NET Framework では、透過性はマイクロソフトのコードでのみ使用されていました。
.NET Framework 4 では、このモデルが拡張されて規則が厳しくなり、セキュリティ透過性が強制モデルになりました。 この強化されたモデルでは、セキュリティに対する配慮が必要で部分信頼アプリケーションから呼び出すことができるコードが、より識別しやすくなっています。 これにより、監査が必要な領域がさらに削減されます。
次の表に、透過性のカテゴリとコードに注釈を付けるための関連する属性を示します。
セキュリティ カテゴリ |
属性 |
説明 |
|---|---|---|
透過的 |
本質的にセキュリティに対する配慮が必要な操作を実行しないコード。 |
|
クリティカル |
どのような操作も実行できるが、部分信頼アプリケーションから呼び出すことはできないコード。 |
|
セーフ クリティカル |
どのような操作も実行でき、部分信頼アプリケーションから呼び出すことができるコード。 これは安全な仲介層で、クリティカル コードを呼び出す前に適切なセキュリティ チェックと検証を実行する目的で使用されます。 |
透過的なコードでは、付与されているアクセス許可にかかわらず、次のような操作は実行できません。
検証不可能なコードを格納する。
プラットフォーム呼び出しを使用する。
Assert 操作を実行する。
クリティカル コードを呼び出す。
クリティカル コードから派生する。
LinkDemand によって保護されているコード (クリティカルと見なされるコード) を呼び出す。
コードがこれらの規則に違反する場合は、(そのコードが完全に信頼されていても) 例外がスローされます。 詳細については、「.NET Framework 4 におけるセキュリティの変更点」を参照してください。
セキュリティに対する配慮が必要かどうかは、共通言語ランタイム (CLR) で透過的なコードに対して禁止されているアクションとして定義されます。 透過性モデルでは、フィールドへのパスワードの格納などのシナリオ固有のセキュリティ違反を防ぐことはできません。
セキュリティ モデルのしくみ
各 AppDomain には、アクセス許可セットが関連付けられています。ホストされているシナリオの場合、これはホストによって定義されます (ホストされていないコードでは、完全信頼のアクセス許可セットになります)。
部分信頼コードは常に透過的です。したがって、部分信頼コードでは、透過的なコードに対して禁止されているアクションを実行することはできません (「セキュリティ透過性」を参照)。
既定では、完全信頼コードは、透過的なコードとしてマークされていない限りクリティカルです。 デスクトップ アプリケーションが透過的とマークされている場合、そのアプリケーションは、完全に信頼されていてもクリティカル コードを呼び出すことができません。
ライブラリは、ホストと .NET Framework の両方によって部分信頼コードに公開される場合があります。 このようなライブラリには、透過的なコード、クリティカル コード、およびセーフ クリティカルなコードが混在しています。
セーフ クリティカルなコードは、重要な機能を使用する前に適切なアクセス許可を要求する必要があります。 たとえば、File.Open メソッドは、ファイルを開く前に FileIOPermission を要求します。
セーフ クリティカルなコードは、重要な機能を呼び出す前後にその他のチェックと検証を実行する必要もあります。 たとえば、例外とメッセージは、部分的に信頼されたコードに渡す前にフィルター処理が必要である場合があります。
クリティカル コードは、部分信頼コードでは実行できない操作を実行する場合があるため、部分信頼コードからの呼び出し時に必要なアクセス許可をアサートする必要があります。
参照
概念
.NET Framework 4 におけるセキュリティの変更点