透過的セキュリティ コード
セキュリティは、サンドボックス化、アクセス許可、および適用の 3 つの相互作用を伴います。 サンドボックス化とは、完全に信頼されるコードとして扱われるコードとサンドボックスの許可セットのアクセス許可に制限されるコードが存在する分離ドメインを作成することを示します。 サンドボックスの許可セット内で実行されるアプリケーション コードは、透過的と見なされます。つまり、セキュリティに影響する可能性がある操作は実行できません。 サンドボックスの許可セットは、証拠によって決定されます。 証拠は、どのアクセス許可がサンドボックスで必要か、およびどの種類のサンドボックスを作成できるかを指定します。 適用とは、透過的なコードを許可セット内でのみ実行できるようにすることを示します。
.gif "重要 :") 重要 |
|---|
以前のバージョンの .NET Framework では、セキュリティ ポリシーが主要な要素でした。.NET Framework Version 4 以降では、セキュリティ ポリシーは廃止されました。セキュリティ ポリシーの削除は、透過的セキュリティとは別の変更点です。この変更の影響とその影響を軽減するアドバイスについては、「コード アクセス セキュリティ ポリシーの互換性と移行」を参照してください。 |
ここでは、透過性モデルについて詳しく説明します。 このチュートリアルは、次のセクションで構成されています。
透過性モデルの目的
透過度の指定
透過性の適用
透過性モデルの目的
透過性は、アプリケーションの一部として実行されるコードをインフラストラクチャの一部として実行されるコードから分離する適用機構です。 透過性は、ネイティブ コードの呼び出しなどの特権的な処理を実行できるコード (クリティカル コード) と、そのような処理を実行できないコード (透過的なコード) との間に、障壁を設けます。 透過的なコードでは、コードに適用されたアクセス許可セットの範囲内のコマンドを実行できますが、クリティカル コードを実行することはできません。また、クリティカル コードから派生したりクリティカル コードを含めたりすることもできません。
透過性を適用する主な目的は、特権に基づいてさまざまなコード グループを分離する簡単で効果的な機構を実現することです。 サンドボックス モデルのコンテキストでは、これらの特権グループは完全に信頼されるか (制限がありません) 部分的に信頼されます (サンドボックスに付与されたアクセス許可セットに制限されます)。
| 重要 |
|---|
透過性モデルは、コード アクセス セキュリティよりも優先されます。透過性は JIT (Just-In-Time) コンパイラによって適用され、完全信頼を含むアセンブリの許可セットに関係なく有効になります。 |
透過性は、セキュリティ モデルを簡略化して安全なライブラリやアプリケーションを簡単に作成および配置できるようにするために、.NET Framework Version 2.0 で導入されました。 また、透過的なコードは、部分的に信頼されたアプリケーションを簡単に開発できるようにするために Microsoft Silverlight でも使用されます。
.gif "メモ") メモ |
|---|
部分的に信頼されたアプリケーションを開発する場合は、対象ホストで必要とされるアクセス許可に注意する必要があります。一部のホストで許可されていないリソースを使用するアプリケーションを開発できます。このアプリケーションではコンパイル エラーは発生しませんが、ホストされた環境に読み込まれるときにエラーが発生します。Visual Studio を使用してアプリケーションを開発した場合は、開発環境から、部分信頼または制限されたアクセス許可セットでのデバッグを有効にできます。詳細については、「方法 : アクセス許可が制限された ClickOnce アプリケーションをデバッグする」を参照してください。ClickOnce アプリケーションに対して用意されている "アクセス許可の検出" 機能は、部分的に信頼されたアプリケーションにも使用できます。 |
ページのトップへ
透過度の指定
アセンブリ レベルの SecurityRulesAttribute 属性では、アセンブリが従う SecurityRuleSet 規則が明示的に選択されます。 規則は、レベルが高いほどセキュリティ規則の適用が厳密になる数値レベルのシステムで編成されます。
レベルは次のとおりです。
2 つの透過度の主な相違点は、レベル 1 はアセンブリの外部からの呼び出しに透過性規則を適用せず、互換性を確保するためにのみ使用されるという点です。
| 重要 |
|---|
レベル 1 の透過性は、互換性を確保するためにのみ指定してください。つまり、AllowPartiallyTrustedCallersAttribute 属性を使用するか透過性モデルを使用しない .NET Framework 3.5 以前で開発されたコードに対してのみレベル 1 を指定してください。たとえば、部分的に信頼された呼び出し元からの呼び出しを許可する .NET Framework 2.0 アセンブリ (APTCA) にはレベル 1 の透過性を使用します。.NET Framework 4 用に開発されたコードには、常にレベル 2 の透過性を使用します。 |
レベル 2 の透過性
レベル 2 の透過性は、.NET Framework Version 4 で導入されました。 このモデルには、透過的なコード、セキュリティ セーフ クリティカル コード、およびセキュリティ クリティカル コードの 3 つの基本思想があります。
透過的なコードは、付与されているアクセス許可に関係なく (完全信頼を含む)、他の透過的なコードまたはセキュリティ セーフ クリティカル コードのみを呼び出すことができます。 コードが部分的に信頼されている場合は、ドメインのアクセス許可セットで許可されるアクションのみを実行できます。 透過的なコードでは、次のアクションは実行できません。
特権の Assert 操作または昇格を実行する。
アンセーフ コードまたは検証不可能なコードを含める。
クリティカル コードを直接呼び出す。
ネイティブ コードまたは SuppressUnmanagedCodeSecurityAttribute 属性を持つコードを呼び出す。
LinkDemand によって保護されているメンバーを呼び出す。
クリティカルな型を継承する。
また、透過的メソッドでは、クリティカルな仮想メソッドをオーバーライドしたりクリティカルなインターフェイス メソッドを実装したりすることはできません。
セキュリティ セーフ クリティカル コードは完全に信頼されていますが、透過的なコードから呼び出すことができます。 完全に信頼されているコードの限られた領域しか外部に公開されないようにします。 正確性とセキュリティの検証はセーフ クリティカル コードで実行されます。
セキュリティ クリティカル コードは任意のコードを呼び出すことができ、完全に信頼されていますが、透過的なコードから呼び出すことはできません。
レベル 1 の透過性
レベル 1 の透過性モデルは、開発者がセキュリティ監査の対象になるコードの量を減らすことができるようにするために、.NET Framework Version 2.0 で導入されました。 レベル 1 の透過性は Version 2.0 で一般に公開されましたが、主に Microsoft 内でのみセキュリティ監査を目的として使用されていました。 注釈を付けることで、セキュリティ昇格やその他の信頼されたアクションを実行できる型およびメンバー (セキュリティ クリティカル) と、実行できない型およびメンバー (透過的セキュリティ) を宣言できるようになりました。 透過的なコードでは、高度なセキュリティ監査は不要です。 レベル 1 の透過性は、透過性の適用がアセンブリ内に限定されることを示します。 つまり、セキュリティ クリティカルなパブリック型またはメンバーは、アセンブリ内でのみセキュリティ クリティカルです。 アセンブリの外部から呼び出される場合にこのような型およびメンバーにセキュリティを適用するには、完全な信頼のためのリンク確認要求を使用する必要があります。 使用しないと、パブリックに参照できるセキュリティ クリティカルな型およびメンバーは、セキュリティ セーフ クリティカルとして扱われ、部分的に信頼されているコードによってアセンブリの外部から呼び出すことができます。
レベル 1 の透過性モデルには次の制限があります。
セキュリティ クリティカルなパブリック型およびパブリック メンバーは、透過的セキュリティ コードからアクセスできます。
透過性注釈はアセンブリ内でのみ適用されます。
セキュリティ クリティカルな型およびメンバーでは、アセンブリの外部から呼び出される場合にセキュリティを適用するには、リンク確認要求を使用する必要があります。
継承規則は適用されません。
透過的なコードは、完全に信頼して実行されると危険性をもたらす可能性があります。
ページのトップへ
透過性の適用
透過性規則は、透過性が計算されるまで適用されません。 このとき、透過性規則に違反すると、InvalidOperationException がスローされます。 透過性が計算されるタイミングは、複数の要因によって左右されるので予測できません。 できる限り遅く計算されます。 .NET Framework 4 では、アセンブリ レベルの透過性の計算は、.NET Framework 2.0 よりも早く実行されます。確実なのは、透過性の計算は必要になるときまでには実行されるということだけです。 これは、メソッドがコンパイルされてメソッドのエラーが検出される時点が JIT コンパイラで変更される方法に似ています。 透過性の計算は、コードに透過性エラーがない場合は目に見えません。
ページのトップへ