安全性透明的程式碼,層級 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 中的程式碼存取安全性不應該用作一種機制,以根據程式碼來源或其他身分識別層面的來強制安全性界限。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 中引進。Level 2 transparency was introduced in the .NET Framework 4. 此模型的三個原則是透明程式碼、安全性安全關鍵程式碼和安全性關鍵程式碼。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:

    此外,透明方法無法覆寫關鍵虛擬方法或實作關鍵介面方法。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.

使用範例和行為Usage Examples and Behaviors

若要指定 .NET Framework 4 規則(層級2透明度),請針對元件使用下列注釋:To specify .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 規則。If you do not annotate an assembly, the .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. 不指定屬性會導致 Common Language Runtime 為您決定透明度規則。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. 這個案例與不指定任何屬性很相似;不過,Common Language Runtime 不會自動決定透明度規則。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. 您必須明確將此方法加註為 SecurityCriticalSecuritySafeCritical;否則,系統將在載入時擲回 TypeLoadExceptionYou 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 不指定屬性會導致 Common Language Runtime 為您決定透明度規則。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. 如果您覆寫虛擬或抽象方法,或是實作介面方法,就必須明確將此方法加註為 SecurityCriticalSecuritySafeCriticalIf 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. 它們必須識別為 SecuritySafeCriticalSecurityCriticalThey 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.

覆寫模式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

繼承規則Inheritance Rules

在本節中,下列順序是根據存取和功能指派給 TransparentCriticalSafeCritical 程式碼: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. 就預設行為而言,沒有加上附註的所有衍生方法都是 TransparentFor 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.

其他資訊和規則Additional Information and Rules

LinkDemand 支援LinkDemand Support

層級 2 透明度模型會將 LinkDemand 取代成 SecurityCriticalAttribute 屬性。The level 2 transparency model replaces the LinkDemand with the SecurityCriticalAttribute attribute. 在舊版 (層級 1) 程式碼中,LinkDemand 可自動視為 DemandIn 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 命名空間來識別類型、方法或欄位是否為 SecurityCriticalSecuritySafeCritical,或 SecurityTransparentIsSecurityCriticalIsSecuritySafeCriticalIsSecurityTransparentThe 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.

注意

SafeCritical 方法會傳回 IsSecurityCriticalIsSecuritySafeCriticaltrue,因為 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. 您應該使用PEVerify 工具中的 [transparent] 選項,確保元件中的透明程式碼是可驗證的。You should ensure that the transparent code in the assembly is verifiable by using the transparent option in the PEVerify tool.

請參閱See also