透過的セキュリティ コード、レベル 2Security-Transparent Code, Level 2

注意事項

コード アクセス セキュリティと部分的に信頼できるコード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.

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

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

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

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

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

    • ネイティブ コードまたは SuppressUnmanagedCodeSecurityAttribute 属性を持つコードを呼び出す。Call native code or code with 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.

  • セーフ クリティカル コードは完全に信頼されていますが、透過的なコードから呼び出すことができます。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.

このトピックは、次のセクションで構成されています。This topic contains the following sections:

使用例と動作Usage Examples and Behaviors

.NET Framework 4.NET Framework 4 の規則 (レベル 2 の透過性) を指定するには、アセンブリに対して次の注釈を使用します。To specify .NET Framework 4.NET Framework 4 rules (level 2 transparency), use the following annotation for an assembly:

[assembly: SecurityRules(SecurityRuleSet.Level2)]  

.NET Framework 2.0 のルール (レベル 1 の透過性) にロックするには、次の注釈に使用します。To lock into the .NET Framework 2.0 rules (level 1 transparency), use the following annotation:

[assembly: SecurityRules(SecurityRuleSet.Level1)]  

アセンブリに注釈を付けない場合は、既定で、.NET Framework 4.NET Framework 4 の規則が使用されます。If you do not annotate an assembly, the .NET Framework 4.NET Framework 4 rules are used by default. ただし、推奨されるベスト プラクティスは、使用するは、SecurityRulesAttribute属性の既定値の代わりにします。However, the recommended best practice is to use the SecurityRulesAttribute attribute instead of depending on the default.

アセンブリ全体の注釈Assembly-wide Annotation

アセンブリ レベルでの属性の使用には、次の規則が適用されます。The following rules apply to the use of attributes at the assembly level:

  • 属性なし: 属性を指定しない場合は、ランタイムによってすべてのコードがセキュリティ クリティカルとして解釈されます。ただし、セキュリティ クリティカルであると継承規則に違反する場合 (たとえば、透過的な仮想メソッドまたはインターフェイス メソッドをオーバーライドまたは実装する場合) は除きます。No attributes: If you do not specify any attributes, the runtime interprets all code as security-critical, except where being security-critical violates an inheritance rule (for example, when overriding or implementing a transparent virtual or interface method). そのような場合、メソッドはセーフ クリティカルになります。In those cases, the methods are safe-critical. 属性を指定しない場合、透過性規則は共通言語ランタイムによって自動的に判断されます。Specifying no attribute causes the common language runtime to determine the transparency rules for you.

  • SecurityTransparent: すべてのコードが透過的になります。アセンブリ全体で特権の必要な操作や安全でない操作は実行されません。SecurityTransparent: All code is transparent; the entire assembly will not do anything privileged or unsafe.

  • SecurityCritical: このアセンブリ内の型によって導入されるすべてのコードはクリティカルになり、その他のすべてのコードは透過的になります。SecurityCritical: All code that is introduced by types in this assembly is critical; all other code is transparent. このシナリオは属性を指定しない場合に似ていますが、共通言語ランタイムによって透過性規則が自動的に判断されることはありません。This scenario is similar to not specifying any attributes; however, the common language runtime does not automatically determine the transparency rules. たとえば、仮想メソッドまたは抽象メソッドをオーバーライドしたり、インターフェイス メソッドを実装したりする場合、既定では、そのメソッドは透過的になります。For example, if you override a virtual or abstract method or implement an interface method, by default, that method is transparent. そのメソッドには SecurityCritical または SecuritySafeCritical の注釈を明示的に付ける必要があります。そうしないと、読み込み時に TypeLoadException がスローされます。You must explicitly annotate the method as SecurityCritical or SecuritySafeCritical; otherwise, a TypeLoadException will be thrown at load time. この規則は、基底クラスと派生クラスの両方が同じアセンブリ内にある場合にも適用されます。This rule also applies when both the base class and the derived class are in the same assembly.

  • AllowPartiallyTrustedCallers (レベル 2 のみ): すべてのコードが既定で透過的になります。AllowPartiallyTrustedCallers (level 2 only): All code defaults to transparent. ただし、個々の型やメンバーに他の属性を設定することもできます。However, individual types and members can have other attributes.

次の表は、レベル 2 とレベル 1 のアセンブリ レベルの動作を比較します。The following table compares the assembly level behavior for Level 2 with Level 1.

Assembly 属性Assembly attribute レベル 2Level 2 レベル 1Level 1
部分的に信頼されたアセンブリで属性なしNo attribute on a partially trusted assembly 型およびメンバーは既定で透過的になりますが、セキュリティ クリティカルまたはセキュリティ セーフ クリティカルにすることもできます。Types and members are by default transparent, but can be security-critical or security-safe-critical. すべての型およびメンバーは透過的です。All types and members are transparent.
属性なしNo attribute 属性を指定しない場合、透過性規則は共通言語ランタイムによって自動的に判断されます。Specifying no attribute causes the common language runtime to determine the transparency rules for you. すべての型およびメンバーはセキュリティ クリティカルになります (ただし、セキュリティ クリティカルになると継承ルールに違反する場所を除く)。All types and members are security-critical, except where being security-critical violates an inheritance rule. 完全に信頼されたアセンブリ (グローバル アセンブリ キャッシュ内に存在するか、AppDomain で完全に信頼と指定されている) では、すべての型は透過的であり、すべてのメンバーはセキュリティ セーフ クリティカルです。On a fully trusted assembly (in the global assembly cache or identified as full trust in the AppDomain) all types are transparent and all members are security-safe-critical.
SecurityTransparent すべての型およびメンバーは透過的です。All types and members are transparent. すべての型およびメンバーは透過的です。All types and members are transparent.
SecurityCritical(SecurityCriticalScope.Everything) 該当なし。Not applicable. すべての型およびメンバーはセキュリティ クリティカルです。All types and members are security-critical.
SecurityCritical このアセンブリ内の型によって導入されるすべてのコードはクリティカルになり、その他のすべてのコードは透過的になります。All code that is introduced by types in this assembly is critical; all other code is transparent. 仮想メソッドまたは抽象メソッドをオーバーライドしたり、インターフェイス メソッドを実装したりする場合は、メソッドに SecurityCritical または SecuritySafeCritical の注釈を明示的に付ける必要があります。If you override a virtual or abstract method or implement an interface method, you must explicitly annotate the method as SecurityCritical or SecuritySafeCritical. すべてのコードは既定で透過的になります。All code defaults to transparent. ただし、個々の型やメンバーに他の属性を設定することもできます。However, individual types and members can have other attributes.

型およびメンバーの注釈Type and Member Annotation

型に適用されるセキュリティ属性は、その型によって導入されるメンバーにも適用されます。The security attributes that are applied to a type also apply to the members that are introduced by the type. ただし、基底クラスまたはインターフェイスの実装の仮想オーバーライドや抽象オーバーライドには適用されません。However, they do not apply to virtual or abstract overrides of the base class or interface implementations. 型およびメンバーのレベルでの属性の使用には、次の規則が適用されます。The following rules apply to the use of attributes at the type and member level:

  • SecurityCritical: 型またはメンバーはクリティカルで、完全に信頼されているコードからのみ呼び出すことができます。SecurityCritical: The type or member is critical and can be called only by full-trust code. セキュリティ クリティカルな型で導入されるメソッドはクリティカルです。Methods that are introduced in a security-critical type are critical.

    重要

    基底クラスまたはインターフェイスで導入されてセキュリティ クリティカルなクラスでオーバーライドまたは実装される仮想メソッドおよび抽象メソッドは、既定では透過的です。Virtual and abstract methods that are introduced in base classes or interfaces, and overridden or implemented in a security-critical class are transparent by default. これらのメソッドは、SecuritySafeCritical または SecurityCritical のいずれかとして指定する必要があります。They must be identified as either SecuritySafeCritical or SecurityCritical.

  • SecuritySafeCritical: 型またはメンバーはセーフ クリティカルです。SecuritySafeCritical: The type or member is safe-critical. ただし、型またはメンバーは透過的な (部分的に信頼された) コードから呼び出すことができ、機能的に他のクリティカル コードと同等になります。However, the type or member can be called from transparent (partially trusted) code and is as capable as any other critical code. コードはセキュリティ監査を受ける必要があります。The code must be audited for security.

ページのトップへBack to top

オーバーライドのパターンOverride Patterns

レベル 2 の透過性で使用できるメソッドのオーバーライドを次の表に示します。The following table shows the method overrides allowed for level 2 transparency.

基底クラスの仮想/インターフェイス メンバーBase virtual/interface member オーバーライド/インターフェイスOverride/interface
Transparent Transparent
Transparent SafeCritical
SafeCritical Transparent
SafeCritical SafeCritical
Critical Critical

ページのトップへBack to top

継承規則Inheritance Rules

このセクションでは、アクセスおよび機能に基づいて、次の順序が TransparentCritical、および SafeCritical のコードに割り当てられています。In this section, the following order is assigned to Transparent, Critical, and SafeCritical code based on access and capabilities:

Transparent < SafeCritical < Critical

  • 型の規則: 左から右に向かってアクセス制限がより厳しくなります。Rules for types: Going from left to right, access becomes more restrictive. 派生型は、基本型と少なくとも同じ程度に制限する必要があります。Derived types must be at least as restrictive as the base type.

  • メソッドの規則。基底メソッドのアクセシビリティを派生メソッドで変更することはできません。Rules for methods: Derived methods cannot change accessibility from the base method. 既定の動作では、注釈のない派生メソッドはすべて Transparent になります。For default behavior, all derived methods that are not annotated are Transparent. クリティカルな型の派生型では、オーバーライドしたメソッドに SecurityCritical の注釈が明示的に付けられていない場合に、例外がスローされます。Derivatives of critical types cause an exception to be thrown if the overridden method is not explicitly annotated as SecurityCritical.

次の表に、使用できる型の継承パターンを示します。The following table shows the allowed type inheritance patterns.

基底クラスBase class 派生クラスで可能なレベルDerived class can be
Transparent Transparent
Transparent SafeCritical
Transparent Critical
SafeCritical SafeCritical
SafeCritical Critical
Critical Critical

次の表に、使用できない型の継承パターンを示します。The following table shows the disallowed type inheritance patterns.

基底クラスBase class 派生クラスで不可のレベルDerived class cannot be
SafeCritical Transparent
Critical Transparent
Critical SafeCritical

次の表に、使用できるメソッドの継承パターンを示します。The following table shows the allowed method inheritance patterns.

基底メソッドBase method 派生メソッドで可能なレベルDerived method can be
Transparent Transparent
Transparent SafeCritical
SafeCritical Transparent
SafeCritical SafeCritical
Critical Critical

次の表に、使用できないメソッドの継承パターンを示します。The following table shows the disallowed method inheritance patterns.

基底メソッドBase method 派生メソッドで不可のレベルDerived method cannot be
Transparent Critical
SafeCritical Critical
Critical Transparent
Critical SafeCritical

注意

これらの継承規則は、レベル 2 の型およびメンバーに適用されます。These inheritance rules apply to level 2 types and members. レベル 1 アセンブリ内の型は、レベル 2 のセキュリティ クリティカルな型およびメンバーから継承できます。Types in level 1 assemblies can inherit from level 2 security-critical types and members. したがって、レベル 2 の型およびメンバーでは、レベル 1 の継承先に対して個別の継承確認要求が必要です。Therefore, level 2 types and members must have separate inheritance demands for level 1 inheritors.

ページのトップへBack to top

追加情報と規則Additional Information and Rules

LinkDemand のサポートLinkDemand Support

レベル 2 の透過性モデルでは、LinkDemandSecurityCriticalAttribute 属性に置き換えられます。The level 2 transparency model replaces the LinkDemand with the SecurityCriticalAttribute attribute. レガシ (レベル 1) コードでは、LinkDemand は自動的 Demand として扱われます。In legacy (level 1) code, a LinkDemand is automatically treated as a Demand.

リフレクションReflection

クリティカル メソッドを呼び出したりクリティカル フィールドを読み取ったりすると、完全信頼の確認要求がトリガーされます (プライベート メソッドまたはプライベート フィールドを呼び出す場合と同様)。Invoking a critical method or reading a critical field triggers a demand for full trust (just as if you were invoking a private method or field). したがって、完全に信頼されているコードではクリティカル メソッドを呼び出すことができるのに対し、部分的に信頼されたコードでは呼び出すことができません。Therefore, full-trust code can invoke a critical method, whereas partial-trust code cannot.

System.Reflection 名前空間に追加された IsSecurityCriticalIsSecuritySafeCritical、および IsSecurityTransparent の各プロパティを使用すると、型、メソッド、またはフィールドが SecurityCriticalSecuritySafeCritical、または SecurityTransparent のどれであるかを判断できます。The following properties have been added to the System.Reflection namespace to determine whether the type, method, or field is SecurityCritical, SecuritySafeCritical, or SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical, and IsSecurityTransparent. 属性の存在を確認する代わりに、リフレクションを使用して透過性を判断するには、これらのプロパティを使用します。Use these properties to determine transparency by using reflection instead of checking for the presence of the attribute. 透過性の規則は複雑なので、属性のチェックでは不十分なことがあります。The transparency rules are complex, and checking for the attribute may not be sufficient.

注意

ASafeCriticalメソッドを返します。true両方のIsSecurityCriticalIsSecuritySafeCriticalので、SafeCriticalが実際にクリティカルである (クリティカル コードと同じ機能を備えているが、透過的なコードから呼び出すことができます)。A SafeCritical method returns true for both IsSecurityCritical and IsSecuritySafeCritical, because SafeCritical is indeed critical (it has the same capabilities as critical code, but it can be called from transparent code).

動的メソッドは、関連付けられているモジュールの透過性を継承します。型の透過性は継承しません (型に関連付けられている場合)。Dynamic methods inherit the transparency of the modules they are attached to; they do not inherit the transparency of the type (if they are attached to a type).

完全な信頼での検証のスキップSkip Verification in Full Trust

完全に信頼されている透過的なアセンブリの検証をスキップするには、SecurityRulesAttribute 属性の SkipVerificationInFullTrust プロパティを true に設定します。You can skip verification for fully trusted transparent assemblies by setting the SkipVerificationInFullTrust property to true in the SecurityRulesAttribute attribute:

[assembly: SecurityRules(SecurityRuleSet.Level2, SkipVerificationInFullTrust = true)]

SkipVerificationInFullTrust プロパティは既定では false であるため、検証をスキップするにはこのプロパティを true に設定する必要があります。The SkipVerificationInFullTrust property is false by default, so the property must be set to true to skip verification. これをするのは、最適化のためだけにしてください。This should be done for optimization purposes only. 使用して、アセンブリの透過的なコードが検証可能なことを確認、transparentオプション、 PEVerify ツールです。You should ensure that the transparent code in the assembly is verifiable by using the transparent option in the PEVerify tool.

参照See Also

セキュリティ透過的なコード、レベル 1Security-Transparent Code, Level 1
セキュリティの変更Security Changes