透過的セキュリティ コードSecurity-Transparent Code

注意事項

コード アクセス セキュリティと部分的に信頼できるコードCode Access Security and Partially Trusted Code

.NET Framework には、コード アクセス セキュリティ (CAS) と呼ばれる、同一アプリケーションで実行される各種コードにさまざまな信頼レベルを強制的に適用するメカニズムが備わっています。The .NET Framework provides a mechanism for the enforcement of varying levels of trust on different code running in the same application called Code Access Security (CAS). .NET Framework のコード アクセス セキュリティは、コードの実行元や他の ID 情報に基づいてセキュリティ境界を適用するメカニズムとして使用しないでください。Code Access Security in .NET Framework should not be used as a mechanism for enforcing security boundaries based on code origination or other identity aspects. 現在、部分的に信頼されるコード (特に実行元が不明なコード) では、コード アクセス セキュリティと透過的セキュリティ コードがセキュリティ境界としてサポートされないように、ガイダンスを更新しています。We are updating our guidance to reflect that Code Access Security and Security-Transparent Code will not be supported as a security boundary with partially trusted code, especially code of unknown origin. 発生元の不明なコードの読み込みと実行に関しては、他のセキュリティ対策を適切に導入することなく行わないようにしてください。We advise against loading and executing code of unknown origins without putting alternative security measures in place.

このポリシーは .NET Framework のすべてのバージョンに適用されますが、Silverlight に含まれる .NET Framework には適用されません。This policy applies to all versions of .NET Framework, but does not apply to the .NET Framework included in Silverlight.

セキュリティは、サンドボックス化、アクセス許可、および適用の 3 つの相互作用を伴います。Security involves three interacting pieces: sandboxing, permissions, and enforcement. サンドボックス化とは、完全に信頼されるコードとして扱われるコードとサンドボックスの許可セットのアクセス許可に制限されるコードが存在する分離ドメインを作成することを示します。Sandboxing refers to the practice of creating isolated domains where some code is treated as fully trusted and other code is restricted to the permissions in the grant set for the sandbox. サンドボックスの許可セット内で実行されるアプリケーション コードは、透過的と見なされます。つまり、セキュリティに影響する可能性がある操作は実行できません。The application code that runs within the grant set of the sandbox is considered to be transparent; that is, it cannot perform any operations that can affect security. サンドボックスの許可セットは、証拠 (Evidence クラス) によって決定されます。The grant set for the sandbox is determined by evidence (Evidence class). 証拠は、どのアクセス許可がサンドボックスで必要か、およびどの種類のサンドボックスを作成できるかを指定します。Evidence identifies what specific permissions are required by sandboxes, and what kinds of sandboxes can be created. 適用とは、透過的なコードを許可セット内でのみ実行できるようにすることを示します。Enforcement refers to allowing transparent code to execute only within its grant set.

重要

以前のバージョンの .NET Framework では、セキュリティ ポリシーが主要な要素でした。Security policy was a key element in previous versions of the .NET Framework. .NET Framework 4 以降では、セキュリティポリシーは廃止されています。Starting with the .NET Framework 4, security policy is obsolete. セキュリティ ポリシーの削除は、透過的セキュリティとは別の変更点です。The elimination of security policy is separate from security transparency. この変更の影響の詳細については、「コードアクセスセキュリティポリシーの互換性と移行」を参照してください。For information about the effects of this change, see Code Access Security Policy Compatibility and Migration.

透過性モデルの目的Purpose of the Transparency Model

透過性は、アプリケーションの一部として実行されるコードをインフラストラクチャの一部として実行されるコードから分離する適用機構です。Transparency is an enforcement mechanism that separates code that runs as part of the application from code that runs as part of the infrastructure. 透過性は、ネイティブ コードの呼び出しなどの特権的な処理を実行できるコード (クリティカル コード) と、そのような処理を実行できないコード (透過的なコード) との間に、障壁を設けます。Transparency draws a barrier between code that can do privileged things (critical code), such as calling native code, and code that cannot (transparent code). 透過的なコードでは、コードに適用されたアクセス許可セットの範囲内のコマンドを実行できますが、クリティカル コードを実行することはできません。また、クリティカル コードから派生したりクリティカル コードを含めたりすることもできません。Transparent code can execute commands within the bounds of the permission set it is operating in, but cannot execute, derive from, or contain critical code.

透過性を適用する主な目的は、特権に基づいてさまざまなコード グループを分離する簡単で効果的な機構を実現することです。The primary goal of transparency enforcement is to provide a simple, effective mechanism for isolating different groups of code based on privilege. サンドボックス モデルのコンテキストでは、これらの特権グループは完全に信頼されるか (制限がありません) 部分的に信頼されます (サンドボックスに付与されたアクセス許可セットに制限されます)。Within the context of the sandboxing model, these privilege groups are either fully trusted (that is, not restricted) or partially trusted (that is, restricted to the permission set granted to the sandbox).

重要

透過性モデルは、コード アクセス セキュリティよりも優先されます。The transparency model transcends code access security. 透過性は JIT (Just-In-Time) コンパイラによって適用され、完全信頼を含むアセンブリの許可セットに関係なく有効になります。Transparency is enforced by the just-in-time compiler and remains in effect regardless of the grant set for an assembly, including full trust.

透過性は、セキュリティ モデルを簡略化して安全なライブラリやアプリケーションを簡単に作成および配置できるようにするために、.NET Framework Version 2.0 で導入されました。Transparency was introduced in the .NET Framework version 2.0 to simplify the security model, and to make it easier to write and deploy secure libraries and applications. また、透過的なコードは、部分的に信頼されたアプリケーションを簡単に開発できるようにするために Microsoft Silverlight でも使用されます。Transparent code is also used in Microsoft Silverlight, to simplify the development of partially trusted applications.

注意

部分的に信頼されたアプリケーションを開発する場合は、対象ホストで必要とされるアクセス許可に注意する必要があります。When you develop a partially trusted application, you have to be aware of the permission requirements for your target hosts. 一部のホストで許可されていないリソースを使用するアプリケーションを開発できます。You can develop an application that uses resources that are not allowed by some hosts. このアプリケーションではコンパイル エラーは発生しませんが、ホストされた環境に読み込まれるときにエラーが発生します。This application will compile without error, but will fail when it is loaded into the hosted environment. Visual Studio を使用してアプリケーションを開発した場合は、開発環境から、部分信頼または制限されたアクセス許可セットでのデバッグを有効にできます。If you have developed your application using Visual Studio, you can enable debugging in partial trust or in a restricted permission set from the development environment. 詳細については、「 How to: Debug a ClickOnce Application with Restricted Permissions」を参照してください。For more information, see How to: Debug a ClickOnce Application with Restricted Permissions. ClickOnce アプリケーションに対して用意されている "アクセス許可の検出" 機能は、部分的に信頼されたアプリケーションにも使用できます。The Calculate Permissions feature provided for ClickOnce applications is also available for any partially trusted application.

透過度の指定Specifying the Transparency Level

アセンブリ レベルの SecurityRulesAttribute 属性では、アセンブリが従う SecurityRuleSet 規則が明示的に選択されます。The assembly-level SecurityRulesAttribute attribute explicitly selects the SecurityRuleSet rules that the assembly will follow. 規則は、レベルが高いほどセキュリティ規則の適用が厳密になる数値レベルのシステムで編成されます。The rules are organized under a numeric level system, where higher levels mean tighter enforcement of security rules.

レベルは次のとおりです。The levels are as follows:

  • レベル 2 (Level2) – .NET Framework 4 つの透過性規則。Level 2 (Level2) – the .NET Framework 4 transparency rules.

  • レベル 1 (Level1) – .NET Framework 2.0 の透過性規則。Level 1 (Level1) – the .NET Framework 2.0 transparency rules.

2 つの透過度の主な相違点は、レベル 1 はアセンブリの外部からの呼び出しに透過性規則を適用せず、互換性を確保するためにのみ使用されるという点です。The primary difference between the two transparency levels is that level 1 does not enforce transparency rules for calls from outside the assembly and is intended only for compatibility.

重要

レベル 1 の透過性は、互換性を確保するためにのみ指定してください。つまり、AllowPartiallyTrustedCallersAttribute 属性を使用するか透過性モデルを使用しない .NET Framework 3.5 以前で開発されたコードに対してのみレベル 1 を指定してください。You should specify level 1 transparency for compatibility only; that is, specify level 1 only for code that was developed with the .NET Framework 3.5 or earlier that uses the AllowPartiallyTrustedCallersAttribute attribute or does not use the transparency model. たとえば、部分的に信頼された呼び出し元からの呼び出しを許可する .NET Framework 2.0 アセンブリ (APTCA) にはレベル 1 の透過性を使用します。For example, use level 1 transparency for .NET Framework 2.0 assemblies that allow calls from partially trusted callers (APTCA). .NET Framework 4 用に開発されたコードでは、常にレベル2の透過性を使用します。For code that is developed for the .NET Framework 4, always use level 2 transparency.

レベル 2 の透過性Level 2 Transparency

レベル2の透過性は .NET Framework 4 で導入されました。Level 2 transparency was introduced in the .NET Framework 4. このモデルには、透過的なコード、セキュリティ セーフ クリティカル コード、およびセキュリティ クリティカル コードの 3 つの基本思想があります。The three tenets of this model are transparent code, security-safe-critical code, and security-critical code.

  • 透過的なコードは、付与されているアクセス許可に関係なく (完全信頼を含む)、他の透過的なコードまたはセキュリティ セーフ クリティカル コードのみを呼び出すことができます。Transparent code, regardless of the permissions it is granted (including full trust), can call only other transparent code or security-safe-critical code. コードが部分的に信頼されている場合は、ドメインのアクセス許可セットで許可されるアクションのみを実行できます。If the code is partially trusted, it can only perform actions that are allowed by the domain’s permission set. 透過的なコードでは、次のアクションは実行できません。Transparent code cannot do the following:

    • 特権の Assert 操作または昇格を実行する。Perform an Assert operation or elevation of privilege.

    • アンセーフ コードまたは検証不可能なコードを含める。Contain unsafe or unverifiable code.

    • クリティカル コードを直接呼び出す。Directly call critical code.

    • ネイティブ コードまたは SuppressUnmanagedCodeSecurityAttribute 属性を持つコードを呼び出す。Call native code or code that has the SuppressUnmanagedCodeSecurityAttribute attribute.

    • LinkDemand によって保護されているメンバーを呼び出す。Call a member that is protected by a LinkDemand.

    • クリティカルな型を継承する。Inherit from critical types.

      また、透過的メソッドでは、クリティカルな仮想メソッドをオーバーライドしたりクリティカルなインターフェイス メソッドを実装したりすることはできません。In addition, transparent methods cannot override critical virtual methods or implement critical interface methods.

  • セキュリティ セーフ クリティカル コードは完全に信頼されていますが、透過的なコードから呼び出すことができます。Security-safe-critical code is fully trusted but is callable by transparent code. 完全に信頼されているコードの限られた領域しか外部に公開されないようにします。It exposes a limited surface area of full-trust code. 正確性とセキュリティの検証はセーフ クリティカル コードで実行されます。Correctness and security verifications happen in safe-critical code.

  • セキュリティ クリティカル コードは任意のコードを呼び出すことができ、完全に信頼されていますが、透過的なコードから呼び出すことはできません。Security-critical code can call any code and is fully trusted, but it cannot be called by transparent code.

レベル 1 の透過性Level 1 Transparency

レベル 1 の透過性モデルは、開発者がセキュリティ監査の対象になるコードの量を減らすことができるようにするために、.NET Framework Version 2.0 で導入されました。The level 1 transparency model was introduced in the .NET Framework version 2.0 to enable developers to reduce the amount of code that is subject to a security audit. レベル 1 の透過性は Version 2.0 で一般に公開されましたが、主に Microsoft 内でのみセキュリティ監査を目的として使用されていました。Although level 1 transparency was publicly available in version 2.0, it was primarily used only within Microsoft for security auditing purposes. 注釈を付けることで、セキュリティ昇格やその他の信頼されたアクションを実行できる型およびメンバー (セキュリティ クリティカル) と、実行できない型およびメンバー (透過的セキュリティ) を宣言できるようになりました。Through annotations, developers are able to declare which types and members can perform security elevations and other trusted actions (security-critical) and which cannot (security-transparent). 透過的なコードでは、高度なセキュリティ監査は不要です。Code that is identified as transparent does not require a high degree of security auditing. レベル 1 の透過性は、透過性の適用がアセンブリ内に限定されることを示します。Level 1 transparency states that the transparency enforcement is limited to within the assembly. つまり、セキュリティ クリティカルなパブリック型またはメンバーは、アセンブリ内でのみセキュリティ クリティカルです。In other words, any public types or members that are identified as security-critical are security-critical only within the assembly. アセンブリの外部から呼び出される場合にこのような型およびメンバーにセキュリティを適用するには、完全な信頼のためのリンク確認要求を使用する必要があります。If you want to enforce security for those types and members when they are called from outside the assembly, you must use link demands for full trust. 使用しないと、パブリックに参照できるセキュリティ クリティカルな型およびメンバーは、セキュリティ セーフ クリティカルとして扱われ、部分的に信頼されているコードによってアセンブリの外部から呼び出すことができます。If you do not, publicly visible security-critical types and members are treated as security-safe-critical and can be called by partially trusted code outside the assembly.

レベル 1 の透過性モデルには次の制限があります。The level 1 transparency model has the following limitations:

  • セキュリティ クリティカルなパブリック型およびパブリック メンバーは、透過的セキュリティ コードからアクセスできます。Security-critical types and members that are public are accessible from security-transparent code.

  • 透過性注釈はアセンブリ内でのみ適用されます。The transparency annotations are enforced only within an assembly.

  • セキュリティ クリティカルな型およびメンバーでは、アセンブリの外部から呼び出される場合にセキュリティを適用するには、リンク確認要求を使用する必要があります。Security-critical types and members must use link demands to enforce security for calls from outside the assembly.

  • 継承規則は適用されません。Inheritance rules are not enforced.

  • 透過的なコードは、完全に信頼して実行されると危険性をもたらす可能性があります。The potential exists for transparent code to do harmful things when run in full trust.

透過性の適用Transparency Enforcement

透過性規則は、透過性が計算されるまで適用されません。Transparency rules are not enforced until transparency is calculated. このとき、透過性規則に違反すると、InvalidOperationException がスローされます。At that time, an InvalidOperationException is thrown if a transparency rule is violated. 透過性が計算されるタイミングは、複数の要因によって左右されるので予測できません。The time that transparency is calculated depends on multiple factors and cannot be predicted. できる限り遅く計算されます。It is calculated as late as possible. .NET Framework 4 では、アセンブリレベルの透過性の計算は、.NET Framework 2.0 の場合よりも早く行われます。In the .NET Framework 4, assembly-level transparency calculation occurs sooner than it does in the .NET Framework 2.0. 保証されるのは、必要になるまでに透過性の計算が行われるということだけです。The only guarantee is that transparency calculation will occur by the time it is needed. これは、メソッドがコンパイルされてメソッドのエラーが検出される時点が JIT コンパイラで変更される方法に似ています。This is similar to how the just-in-time (JIT) compiler can change the point when a method is compiled and any errors in that method are detected. 透過性の計算は、コードに透過性エラーがない場合は目に見えません。Transparency calculation is invisible if your code does not have any transparency errors.

関連項目See also